AU2022279370A1 - System and method to mitigate fraud in transactions - Google Patents

Abstract

The present invention provides a system (and associated method) configured to mitigate fraud in transactions, the system comprising a server having a processor and a memory, the system being configured to, in use: receive information relating to a proposed transaction involving an account, including at least an identity and contact details of an account-holder of the account and details of the proposed transaction; communicate with an electronic device of the account holder to obtain a confirmation of the identity of the account-holder; determine whether the confirmation of the identity of the account-holder matches the identity of the account-holder initially received by the system; preferably send to the account-holder at least a portion of the details of the proposed transaction, along with a request for the account-holder to indicate whether they consent to the proposed transaction being made and obtain from the account holder an indication of whether they consent to the proposed transaction being made; and output said determination of the match and/or said indication of consent from the account-holder. The invention thereby combats / mitigates different kinds of fraud (by illicit third parties and by account-holders themselves); utilizes multiple different kinds of authentication / security techniques to verify both account-holder identity and authenticity of the proposed transaction details; and thereby protects numerous stakeholders from fraud, notably both the account-holder and the intermediary (such as a financial institution). 26 FIGURE 2B [Fund name] and SuperGuard 302 protect Australian superannuation from fraud To process your [transaction type], we need to validate your identity and confirm the transaction details 304 This will take less than 2 minutes. Please have the following items before continuing: 1.dentity document (Drivers Licence or passport) 306 2. Bank account details 200 3/4

Description

FIGURE 2B

[Fund name] and SuperGuard 302 protect Australian superannuation from fraud

To process your [transaction type], we need to validate your identity and confirm the transaction details 304 This will take less than 2 minutes.

Please have the following items before continuing:

1.dentity document (Drivers Licence or passport) 306 2. Bank account details

200

3/4

System and method to mitigatefraud in transactions

FIELD OF THE INVENTION

The present invention relates to a system and method to mitigate fraud in transactions. The invention has particular application to financial transactions and other transactions, including but not limited to "rollover requests" in relation to self-managed superannuation funds. However, the invention may also have various other applications.

BACKGROUND

Fraud in financial contexts has always been a problem, and is becoming more ubiquitous as the financial world (and commerce generally) moves online and opportunities for fraudsters become greater.

Financial fraud can assume different forms. A fraudster may illicitly obtain a victim's bank account details and then seek to login and transfer funds from the victim's account to the fraudster's account. A related scenario is where a fraudster obtains sufficient information about the account-holder to be able to fabricate a "transfer request" purporting to be by the account-holder. Many banks tend to require, for example, a certified copy of a driver's license, basic personal information (name, address, date of birth), and a signature, as security measures. All of these are relatively easy for a fraudster to obtain and / or forge, enabling them to falsify a "transfer request" from the victim's account to the fraudster's account. With this type of fraud, not only the account-holder but also the bank are victims, as both stand to suffer a financial loss as well as disruption and time spent rectifying the situation.

Verification of a person's identity solely by validating the details on an identity document is becoming increasingly risky, especially in the context of data breaches where a person's identity document details may no longer be secure. In this case, verification using only identity document information enables a potential fraudster to pass verification if they have access to the original or a copy of the identity document and/or identity document information. Even in cases where a certified copy of the identity document is required or signatures are checked in order to further verify the authenticity of an identity document, there can be fraud because certification on certified copies are unable to be independently verified and signatures are not checked by handwriting experts.

Multi-factor authentication / transaction confirmation is one means that has been developed to combat this: when an account-holder initiates a payment, they receive, and usually must reply to (or take some action in response to), a message via a separate channel (such as a text message, email or phone call) to confirm they are the genuine account-holder; the idea being that a fraudster is unlikely to have gotten hold of (or hacked into) multiple of the account-holder's devices or means of communication at once. However, multi-factor authentication / transaction confirmation is an imperfect solution, precisely because there is a risk that a fraudster may in fact get hold of not just a victim's account details but also their mobile device, their email login, et cetera, or the fraudster may have managed to fraudulently change these details in the records of the financial institution; particularly if the fraudster is acquainted with the victim. This commonly occurs in situations of elder abuse for example. Sometimes financial institutions may take further security measures, such as requiring the account-holder to provide information like their date of birth, address, or to answer personal questions, to confirm their identity. However, again this is information which a fraudster may get hold of relatively readily.

A further shortcoming of multi-factor identification / transaction confirmation is that it may itself be perceived as a scam by the account-holder, leading them to ignore it. Some types of multi-factor identification / transaction confirmation consist of a message telling the account-holder to take action if they did not request the transaction referred to. Thus, if the account-holder mistakenly dismisses the message as spam and takes no action, the fraudulent transaction will proceed.

Then there is fraud that relies not on the fraudster directly hacking the victim's bank account, but rather on the victim believing the fraudster is a legitimate payee when in fact they are not. For instance, the fraudster may call or email the victim pretending to be a creditor, such as an electricity company or Internet provider, claiming moneys are owing and threatening to cut off service unless payment is made to a nominated bank account (which of course is that of the fraudster, not of the legitimate service provider.) With this type of fraud, the fraudster's hope, all too often correct, is that the victim won't notice that the nominated payee account details do not reconcile with those of the legitimate payee. After all, account details are simply a string of numbers which the payer tends to mechanistically enter in (or copy and paste in) without much thought.

This kind of fraud may be high- or low-tech. Email scams of this nature are well known. Increasingly sophisticated variants of these are emerging, for instance scams whereby a fraudster is able to detect when a consumer has made an online purchase, and soon afterward sends the consumer a notification purporting to be from, for example, customs, claiming import duty must be paid to a particular account number before the item can be released. In fact, of course, no such payment is owing and the account number is actually that of the scammer.

Low-tech versions of this type of scam are also common - for example a fraudster (impersonating a financial advisor or other trusted figure) persuading the victim to sign blank bank transfer documents or other documents such a payment forms, which they then fill in with their own, fraudulent, bank account details as the "payee". A variant of this is the fraudster simply persuading the victim to sign bank transfer documents populated with fraudulent bank account details (i.e. those of the fraudster), again relying on the victim not noticing this; or the fraudster obtaining bank transfer documents populated with legitimate payee account details and then fraudulently amending them, replacing the payee account number originally entered (or approved) by the payer with the fraudster's own bank account details.

With this type of fraud, multi-factor authentication / transaction confirmation alone will often not help if the payer (i.e. the victim) is genuine, albeit misled. Multi-factor authentication / transaction confirmation (whether via a text message / email or via a confirmatory phone call from the bank) in effect only asks if the account-holder really is who they say they are, and really intends to make the transfer - which in such cases they are, and do. In addition, as noted above, there is the risk that it is in fact thefraudsterreplying / confirming, if they have also gotten hold of the account-holder's mobile device, email login, et cetera.

Yet another type of fraud is that perpetrated by the account-holder themselves, namely the account-holder making a transfer to another account and then falsely claiming that the transfer was fraudulent, with the aim of being reimbursed by their bank for the "fraud". It can be difficult or impossible for banks to determine whether or not the account-holder is telling the truth, so they may be compelled to give the account-holder the benefit of the doubt and reimburse them. This may be the case even if multi-factor authentication /

transaction confirmation measures were employed at the time, due to the above-discussed shortcomings of such measures and hence the account-holder's ability to falsely claim that any such "confirmation / authentication" was given by a fraudster, not by the account-holder.

The above-noted types of fraud are not limited only to financial transactions. They may also affect a variety of other types of transactions, such as where an account-holder's details (e.g. personal details, contact details, login details) are fraudulently altered.

It is accordingly an object of the present invention to provide a system that ameliorates one or more of the above-noted problems with the prior art. At the very least, it is an object of the invention to provide the public with a useful choice.

STATEMENTS OF THE INVENTION

According to one aspect of the invention, there is provided a system configured to mitigate fraud in transactions, the system comprising a server having a processor and a memory, the system being configured to, in use:

receive information relating to a proposed transaction involving an account, including at least one identifier and contact information of an account-holder of the account and details of the proposed transaction;

communicate with an electronic device owned or used by the account-holder to obtain a confirmation of the identifier of the account-holder;

determine whether the confirmation of the identifier of the account-holder matches the identifier of the account-holder initially received by the system;

optionally send to the account-holder at least a portion of the details of the proposed transaction, along with a request for the account-holder to indicate whether they consent to the proposed transaction being made and obtain from the account-holder an indication of whether they consent to the proposed transaction being made; and

output said determination of the match and/or said indication of consent from the account-holder.

Preferably, the system receives the information relating to the proposed transaction from an intermediary associated with the account, and outputs said determination of the match and/or said indication of consent from the account-holder to the intermediary. Alternatively, the system may receive the information relating to the proposed transaction directly rather than from an intermediary.

Preferably, the system is integral with the intermediary. Alternatively, the system is distinct from the intermediary.

Preferably, the intermediary automatically sends said information relating to the proposed transaction to the system. Alternatively, the intermediary logs in to the system and enters said information into the system. Alternatively, the system receives said details via email from the intermediary.

Preferably, the system communicates directly with the electronic device owned or used by the account-holder to obtain the confirmation of the identifier of the account-holder. Alternatively, at least a portion of said communication may be through the intermediary.

Preferably, the electronic device is a mobile phone. Alternatively, the electronic device may be a laptop, personal computer, tablet, or other suitable device.

Preferably, communicating with said electronic device comprises sending a message, such as a text message, email, or pop-up notification, to said electronic device.

Preferably, said message comprises a link, such as a URL or QR code, via which said confirmation of the identifier of the account-holder will be effected.

Preferably, obtaining the confirmation of the identifier of the account-holder comprises utilizing multi-factor authentication and / or transaction confirmation techniques.

Preferably, obtaining the confirmation of the identifier of the account-holder comprises utilizing biometric authentication technology.

More preferably, obtaining the confirmation of the identifier of the account-holder comprises utilizing facial authentication technology.

Even more preferably, utilizing said facial authentication technology comprises obtaining a real-time image, images and/or video of a face of the account-holder and comparing said real-time image to an image of the face of the account-holder in an official photo-identity document, such as a government-issued photo-identity document, to determine if there is a match between the respective images and thus if the confirmation of the identifier of the account-holder matches the identifier of the account-holder initially received by the system.

Preferably, utilizing said facial authentication technology further comprises prompting the account-holder to input details of said official photo-identity document, to enable the system to access said official photo-identity document from a repository.

Preferably, said inputting of said details of said official photo-identity document comprises typing said details into the system. Alternatively, said inputting said details of said official photo-identity document comprises enabling said details to be read by an optical character recognition / reader (OCR) facility associated with the system.

Preferably, once the account-holder has inputted said details (such as via typing said details into the system, or enabling said details to be read by said OCR facility), the system displays the inputted details and prompts the account-holder to confirm the inputted details.

Alternatively, utilizing said facial authentication technology comprises comparing said obtained real-time image of the face of the account-holder to a previously-obtained image (or data relating thereto) of the face of the account-holder which was determined to match an image of the face of the account-holder in an official photo-identity document.

Preferably, the system is configured to, if the confirmation of the identifier of the account holder matches the identifier of the account-holder indicated by the intermediary but one or more anomalies is detected, associate a warning indication or message with the proposed transaction.

Preferably, the system only sends to the account-holder the at least a portion of the details of the proposed transaction and the request for the account-holder to indicate whether they consent to the proposed transaction being made if the confirmation of the identifier of the account-holder matches or passes an acceptable threshold of probability of a match to the identifier of the account-holder initially received by the system.

Alternatively, the system may be configured to send to the account-holder said portion of the details of the proposed transaction and said request even if the confirmation of the identifier of the account-holder does not match the identifier of the account-holder initially received by the system.

Preferably, said at least a portion of the details of the proposed transaction and said request for the account-holder to indicate whether they consent to the proposed transaction being made are sent to the electronic device used by the account-holder. More preferably, said indication from the account-holder of whether they consent to the proposed transaction being made is also obtained via the electronic device owned or used by the account-holder.

Preferably, a message is displayed to the account-holder together with the at least a portion of the details of the proposed transaction, said message warning about fraud risk and urging the account-holder to take steps to verify that the proposed transaction is legitimate.

Preferably, the indication of whether the account-holder consents to the proposed transaction being made is obtained via a manual input from the account-holder, for example via the use of selectable buttons or check-boxes / tick-boxes, wherein the account-holder selects either an affirmative or a negative response.

Alternatively, said indication of whether the account-holder consents to the proposed transaction being made is obtained by detecting via video and/or audio whether the account holder indicates an affirmative or a negative response.

Preferably, said detecting via video includes using facial authentication technology to confirm that the account-holder has not changed during the authentication process, and is looking at a portion of the account-holder's screen on which the at least a portion of the details of the proposed transaction is displayed.

Preferably, said detecting via audio includes using voice recognition technology to confirm the identity of the account-holder during the authentication process. Preferably, in this case, the response of the account-holder is recorded and stored for future reference.

Preferably, said detecting via video and/or audio technology includes using this technology to confirm that the account-holder is not being guided through the authentication process by another person, and/or does not show indicator(s) of uncertainty regarding the transaction. Preferably, in addition to outputting said determination of the match and/or said indication of consent from the account-holder, the system also outputs any warning indications or messages associated with the transaction.

Preferably, said outputting is automatic. Alternatively, said outputting occurs via said determination of the match and/or said indication of consent and optionally any warning indications or messages being stored in the system, for selective retrieval from the system at a later time.

Preferably, the intermediary only proceeds with the proposed transaction if said determination of the match and/or indication of consent comprises an affirmative response or a response that passes an acceptable threshold of probability of an affirmative response as determined by the intermediary.

More preferably, the intermediary only proceeds with the proposed transaction if said determination of the match and/or indication of consent comprises an affirmative response and there are no warning indications or messages associated with the transaction.

Preferably, the system is further configured to store in the memory of the server said indication of consent from the account-holder.

Preferably, the proposed transaction is a financial transaction between a payer, being the account-holder, and a payee; wherein the at least a portion of the details of the proposed transaction sent to the payer comprises at least a portion of a payee account number. Alternatively, the proposed transaction may be a non-financial transaction, such as a change of an account-holder's personal details or login details.

Preferably, the intermediary is a bank or financial institution. The intermediary may be a trustee, manager, administrator or service provider of a superannuation fund. Alternatively, the intermediary could be any other organisation that wishes to ensure the legitimacy or accuracy of a request or transaction.

Preferably, the details relating to the proposed financial transaction further include one or more of: a BSB (Bank State Branch) number (or equivalent) associated with the payee account number; an identity of the payee; and / or a transaction amount.

Preferably, in the case of a transaction involving a rollover between superannuation funds, the details relating to the proposed transaction further include one or more of: a destination superannuation fund; a transaction type (for example, full rollover or partial rollover) and/or a transaction amount.

Preferably, the at least a portion of the payee account number sent to the payer comprises at least the final four digits of the account number.

Preferably, the system further sends to the payer the BSB number, or equivalent.

Preferably, the system further sends to the payer the identity of the payee.

Preferably, the system further sends to the payer the transaction amount.

According to another aspect of the invention, there is provided a method of mitigating fraud in transactions, the method comprising the steps of:

receiving information relating to a proposed transaction involving an account, including at least an identifier and contact details of an account-holder of the account and details of the proposed transaction;

communicating with an electronic device owned or used by the account-holder to obtain a confirmation of the identifier of the account-holder;

determining whether the confirmation of the identifier of the account-holder matches the identifier of the account-holder initially received by the system;

optionally sending to the account-holder at least a portion of the details of the proposed transaction, along with a request for the account-holder to indicate whether they consent to the proposed transaction being made and obtaining from the account holder an indication of whether they consent to the proposed transaction being made; and

outputting said determination of the match and/or said indication of consent from the account-holder.

Preferably, the method is effected utilizing a system substantially as described above.

The term "identifier" as used herein means one or more pieces of information relating to the identity of the account-holder, such as one or more of a name, date of birth, address, telephone number, photograph, passport document, passport number, birth certificate document, birth certificate number, driver's license, driver's license number, tax file number, social security number, previously recorded and stored biometric information such as face, retinal, fingerprint and/or voice biometrics, or any other information specific to the identity of the account-holder.

The term "account-holder" as used herein means an individual named as the account-holder or an authorised representative of an entity other than an individual that is named as the account-holder.

The present invention provides a number of realizable advantages over the prior art, including, providing a system and method that:

- provides a highly secure system that combats / mitigates multiple types of fraud by requiring authentication / verification not just of the account-holder's and/or payer's identity, but also of the proposed transaction details; - thereby both providing the account-holder and/or payer with improved security and protection against fraud, and also providing intermediaries (such as financial institutions) with improved protection against "account-holder fraud" by documenting and recording the account-holder's and/or payer's consent to the proposed transaction taking place; - more specifically, providing a system that combines multiple kinds of authentication / verification techniques, including confirming the identity of the account-holder (preferably via biometrics such as facial authentication, retinal scanning, finger print authentication, or voice recognition and authentication technology) and also confirming / verifying the proposed transaction details, including recording of transaction confirmation.

At the very least, the present invention provides the public with a useful choice.

BRIEF DESCRIPTION OF FIGURES

Further aspects and advantages of the invention will become apparent with reference to the accompanying Figures, which are given by way of example only and in which:

FIGURE 1 is a schematic representing the system according to a preferred exemplary embodiment of the present invention;

FIGURE 2A & 2B are schematic screen-views showing the system communicating with the electronic device of the account-holder to obtain a confirmation

of the identifier of the account-holder; and

FIGURE 3 is a schematic screen-view showing the system sending to the account-holder the proposed transaction details, along with a request for the account-holder to indicate whether they consent to the proposed transaction being made.

DETAILED DESCRIPTION OF FIGURES

Figure 1 is a schematic showing the system (generally indicated by 100) according to a preferred exemplary embodiment of the present invention.

The system (100) comprises a server having a processor and a memory (generally indicated by 106 - also referred to herein as the "system"), the server being communicative with an intermediary (104) and an account-holder (102).

In this embodiment, the proposed transaction is a financial transaction between a payer (being the account-holder (102)) and a payee. For expedience, reference will be made throughout this section to the proposed transaction being a financial transaction. However, this is not intended to be limiting. The transaction can be of a variety of other types, besides the transfer of money. For instance, the transaction might relate to the correction

/ amendment /updating of an account-holder's personal details or login details; or for instance a request to change beneficiaries on a superannuation account.

In this embodiment, the intermediary (104) is a bank or financial institution. This could include, but is not limited to, a trustee, manager, administrator or a service provider of a superannuation fund. However, the intermediary might also be another entity having involvement with financial transactions, such as an online retailer. For transactions of other kinds, the intermediary may be any entity requiring verification of a proposed transaction pertaining to one of its account-holders / customers.

In this embodiment the server / system (106) is depicted as being distinct from the intermediary (104). However, it is within the scope of the invention for the server / system (106) to be integrated with the intermediary (104), for instance to be used in-house by the bank and be integrated with the bank's computer architecture. It should also be noted that there may be additional third parties (not shown) participating in the system - for instance, an administrator (such as an outsourced superannuation fund administrator acting as an agent for the superannuation fund) who receives an initial request from the payer (102) and relays this to the intermediary (104) or processes the initial request on behalf of the intermediary (104).

In use, the payer (102) makes a request (120) to the intermediary (104) relating to a proposed financial transaction.

The intermediary (104), wishing to verify the identity of the payer (102) and the authenticity of the proposed financial transaction generally, provides (122) to the system (106) information and details relating to the proposed financial transaction. Said information and details include at least one identifier, for example a name, date of birth, or other identifier, and contact details of the payer, and a payee account number (i.e. the account number to which the payer has indicated they wish to transfer funds), or at least a portion of the payee account number; and preferably also include other details, notably the BSB, the identity of the payee, a transaction amount, and/or a transaction type. Generally speaking, the more information / detail is provided, the greater the accuracy with which the system will be able to verify the authenticity of the transaction.

Preferably, the intermediary (104) is configured to automatically convey (122) said details to the system (106). This may be achieved via system integration and APIs (whether the system (106) is distinct from, or integrated with, the intermediary (104) network). However, it is also within the scope of the invention for said details to be entered in to the system (106) on a case-by-case basis, such as via the intermediary (104) logging in to the system (106) using a pre-established user account. Said provision (122) may also be achieved via, for instance, the intermediary (104) (i.e. an employee / administrator of same) emailing or otherwise communicating via any channel said details to the system (106) (i.e. an employee / administrator of same).

Using the contact details provided, the system (106) communicates (124) with an electronic device owned or used by the payer (102), which in this embodiment is a mobile phone /

smartphone, but which may also be a laptop, personal computer, tablet, or other suitable device. The purpose of said communication (124) is to obtain confirmation of the identity of the payer (102); and, later on in the process, to obtain and document the payer's (102) consent for the proposed transaction to proceed (as discussed below).

In this embodiment, said communication (124) occurs directly between the system (106) and the payer (102). However, in other embodiments, at least a portion of the communication (such as an initial message) may instead be sent by the intermediary (104), for instance where the intermediary (104) prefers to handle communication with account-holders (102) directly. In such a case, the relevant message / communication (or the relevant portion thereof) may first be relayed, or otherwise made available, by the system (106) to the intermediary (104) for on-sending to the payer (102), for example by the intermediary (104) embedding it within their own communication, composed and arranged according to their preferences.

In this embodiment, said communication (124) comprises a message (202 in Figure 2A) displayed on the payer's phone, the message (202) including a URL (204) for the payer (102) to click on to proceed with the process. On clicking on the URL (204), the payer (102) is taken to the page shown in Figure 2B. While a URL is used in this example, other means for the payer to proceed with the authentication process could be used, such as a QR code, a pop-up notification or similar.

In this example, the first portions (302, 304) of the page shown at Figure 2B include an important message, namely, at (302), alerting the payer to fraud risk generally, and at (304) specifically referring to the need for the payer to confirm their identity and also confirm the transaction details. As such, the message puts the payer on notice of fraud risk per se, and also specifically draws their attention to the importance of checking that the transaction details (i.e. payee account details) are in fact genuine. This is not an essential feature of the invention however, and in some cases no messages of this type may be provided.

The second portion (306) of the message informs the payer of the information they will need to have on hand to proceed: in this embodiment, an official photo-identity document and the relevant bank account details - the latter being a preferred item of information to request from the payer for extra security, though in some embodiments it may be omitted. (In this embodiment the payer will also need to be able to activate a camera functionality on their device, as discussed below).

The system then leads the payer through the applicable identity-confirmation process. In this embodiment, the identity-confirmation process is provided by facial authentication technology. This is preferred due to being highly secure, reliable and resistant to fraud. However, it is within the scope of the invention for other types of biometric authentication to be used, for instance voice authentication, retinal scanning, or fingerprint authentication.

More particularly, in this embodiment, the system obtains (at 126) from the payer a real time image (photograph or video) of the payer's face, and compares this (or causes it to be compared) - directly or indirectly - with an image on an official (e.g. government-issued) photo-identity document of the payer, such as a passport or driver's license, using comparison algorithms of the facial authentication technology, to determine if there is a match between the respective images. By "match" is meant that the system determines that there is a sufficiently high probability score (relative to a pre-programmed threshold probability or confidence score of the facial authentication technology, or relative to a pre determined threshold of probability or confidence score set by the system) that the respective images are of the same individual.

As indicated by (108), the repository containing the official photo-identity document is external to the system (106), for instance it may be a government-administered repository which the system (106) accesses (128) at this stage. Specifically, once the payer (102) inputs (also at 126) the unique number of their passport or driver's license, the system (106) may query (128) the repository (108) for an electronic version of that document, including the payer's image associated with the document. The system may also query the repository (108) for key information from the identity document such as driver's license number or passport number, name, address, or date of birth such that the system returns positive or negative matches and provides an "overall" pass or fail response. Querying/ accessing (128) the repository (108) may be done directly by the system (106), or indirectly by a third-party service provider (not shown). Alternatively, it is also within the scope of the invention for the payer to directly upload the official photo-identity document to the system (106) - e.g. a scan or photograph of same - concurrently with uploading the other information such as the real-time image of their face, i.e. at step (126).

Reference to the payer (102) "inputting" the unique number of their passport or driver's license (or other official photo-identity document) may refer to different things in different embodiments. For instance, a user may type this information in directly. Alternatively, the system (106) may be configured with, or associated with, optical character recognition

/ reader (OCR) technology, such that, when the document is held up to the camera of the user's phone, the OCR technology is able to read the relevant information from the document. In any event, once inputted, the information is preferably displayed back to the user, and the user is asked to confirm that it is correct.

As indicated by (110), the facial authentication technology may be provided by a third-party service, and may be selectively called (129) by the system (106) to undertake the facial authentication process and determine if there is a match between the respective images (thus allowing a determination of whether the confirmation of the identity of the payer matches the identity of the payer indicated by the intermediary). However, this is not intended to be limiting, and it is within the scope of the invention for the facial authentication technology (110) or other biometric authentication technology to be integral with the system (106) itself.

The inventors envisage that there may also be ancillary steps at this stage of the process, particularly if the payer (102) has directly uploaded the official photo-identity document to the system (106). Notably, further steps may be taken to verify that the official photo-identity document is authentic by, for example, running hologram checks and checks to detect any tampering, and / or by comparing the details on the official photo-identity document against those in the repository (108), or in a further repository or database.

As noted above, the comparison of the real-time image may be directly or indirectly with the image on the official photo-identity document. Specifically, where the payer is a first time user of the system (106), their official photo-identity document will need to be cross referenced to, via one of the above-discussed means, and the real-time image uploaded by the payer will be compared directly against this. However, where the payer has previously used the system, and a previously-uploaded image of the payer's face which was deemed authentic at that time is already stored in the system, the real-time image may instead be compared to the previously-uploaded image (or to data relating to that image), rather than requiring the payer to provide their official photo-identity document again.

For instance, and without limitation, the inventors envisage that this may be achieved by using the previously-uploaded image (where said image comprises a sequence of two dimensional frames) to obtain a three-dimensional "face-map" documenting key characteristics of the payer's face. Matching algorithms could then be used to compare this

"face-map" to a subsequent "face-map" derived from a subsequently-uploaded image of the payer (again where said image comprises a sequence of two-dimensional frames). A "face map" of this kind would tend to be highly secure, and in particular resistant to being reverse engineered for fraud / impersonation purposes. Existing "face-map" technologies may be employed to effect this, with suitable adaptations / modifications if needed to incorporate them into the system of the invention.

The facial authentication technology (110) determines whether a match exists between the respective images, that is to say, it assesses the probability (relative to the pre-programmed threshold probability of the facial authentication technology) that the payer's face (per the real-time image) matches the image derived (directly or indirectly) from the official photo identity document; and conveys the result (or determination of the match) to the system (106). In this way, the system (106) obtains confirmation as to whether the identity of the payer (102) matches that indicated by the intermediary (104) or not.

In this embodiment, the system (106) is configured to detect any anomalies associated with a payer or the proposed financial transaction, and associate a warning indication or message with the transaction accordingly. Such anomalies may arise as a consequence of a close but imperfect "match" (e.g. one just failing to meet the pre-programmed threshold probability score) having been obtained between the respective images of the payer's face. However, such anomalies may also arise where a "match" has been obtained, but there are other indicators or circumstances to suggest the transaction may nonetheless be untoward. For instance, the electronic device ID, the payer's face, the payer's official photo-identity document, or the payer or payee bank details, may be flagged in the system (or in a related database to which the system has access) as having previously been involved in fraudulent transactions, or as having previously been used in transactions involving different parties (suggesting a single set of details is being used multiple times). Another indicator may be that the payer has used an excessive number of attempts to pass the "facial authentication" test (i.e. uploaded an excessive number of real-time images that have been rejected).

Any such warning indication or message indicating an anomaly can be passed on to the intermediary (104) at the end of the process, to warn them of potential fraud so they can investigate and decide how to deal with the transaction. Alternatively, in such cases the system (106) may be configured to abort the process at that stage, and inform the intermediary (104) that the transaction ought not to be completed. These steps may be automated to a greater or lesser degree, as discussed below.

Following the identity-confirmation portion of the process, the system (106) is then preferably configured to send (130) to the payer (102) at least a portion of the payee account number and/or payment details, such as a BSB or equivalent, or an account name, along with a request for the payer (102) to indicate whether they consent to payment being made to the payee account number. In cases of transactions relating to a rollover of superannuation funds, where there is unlikely to be a payee account number involved, the system is preferably configured to send to the account-holder at least one or more of the following details: destination superannuation fund (payee name), transaction type (for example whether it is a full or partial rollover) and/or transaction amount.

It should be noted that, in some embodiments, the system (106) may be configured to only send this information if the identity of the payer (102) has been determined to match the identity indicated by the intermediary (104). However, in other embodiments the information may be sent even if a "match" has not been achieved - this is because the failure to achieve a "match" will have already been stored against the proposed transaction at this point, and thus will be able to ultimately invalidate the transaction in appropriate cases, regardless of subsequent input to the system. Thus, even if a fraudster were to "accept" the transaction details in the below-discussed stages of the process, their failure to achieve an identity "match" at the preceding stage would still stand to invalidate the transaction.

In this embodiment, as shown in Figure 3, the entire account number is shown. This may be advantageous to the extent that it enables the payer (102) to determine with full certainty whether this is the correct / legitimate account number of the payee. However, it is within the scope of the invention for only a portion of the payee account number to be shown, with the rest obscured; e.g. for privacy or other reasons. This in turn may be advantageous in embodiments where the system proceeds to this step regardless of whether an identity "match" has been achieved, since displaying only a portion of the account number minimises the risk of a nefarious or unauthorised actor gaining access to the full account number. In this case, the portion shown to the payer (102) must be sufficient to allow them to determine with reasonable certainty that the account is the correct one. For instance, the final 4 digits of the payee account number, along with the BSB or similar, might be displayed to the payer (102).

In this embodiment, also displayed is the transaction amount (404) - "Full Rollover", i.e. the entire amount in the payer's account - and the type of transaction (406) - "SMSF Rollover application" (in this example the transaction type is a full rollover rather than a partial rollover). The identity of the payee might also be displayed. The more information that is displayed to the payer (102), the greater the level of certainty with which the payer (102) can affirmatively confirm that the payee identity and details are legitimate.

In this embodiment a message is also displayed together with these details, at the top of the screen (408). This message again brings to the payer's attention fraud risk, and urges the payer to verify the accuracy of the displayed payee details. The message also makes clear that it is the payer's responsibility to do this. An additional message (409) further cautions/ advises the payee to "Reject the transaction if any of [the displayed] details are incorrect".

The messages (408), (409) are not essential aspects of the invention, but they may be helpful in mitigating those types of fraud reliant upon the fraudster impersonating a legitimate entity seeking payment from the payer (to a fraudulent account). In urging the payer (102) to check the validity of the payee details, the system helps to prevent a common oversight made by fraud victims, namely the failure to cross-check the purported payee's details against those of the legitimate entity they think they are dealing with. This step of the process prompts the payer (102) to cross-reference to any earlier bank statements or other materials where the legitimate entity's account details can be found, and to confirm that the purported payee's details accord with these. Alternatively, or in addition, the payer might contact the legitimate entity directly, to confirm that the payment request has indeed come from them. For example, where a payee has been approached by their "electricity company" requesting payment to a particular account number, the payee might, firstly, cross-reference to previous payments made to the electricity company to confirm that the now-nominated account number is the same as the account number to which they previously sent payment to the electricity company; and / or they might place a call to the electricity company to confirm whether the approach (requesting payment) is actually coming from them.

In this embodiment, the indication (132) from the payer (102) as to whether they consent to payment being made to the payee account number is provided via selectable buttons (410) - "Reject" and "Accept" - respectively indicating a negative and affirmative response (check-boxes and the like might also be used).

However, in other embodiments the indication of consent (132) may instead be provided by the payer (102) via video and/or audio technology or functionality, such as by the system

detecting whether the payer (102) is nodding or shaking their head. Such an embodiment might also incorporate facial authentication technology configured (for example, by the video capturing images and/or videos) to detect whether, at the time of giving the indication, the payer (102) has not changed during the process, and is in fact looking at the portion of their screen on which the payee account number is displayed. Alternatively, or additionally, voice / speech authentication / recognition might also be used to detect and assess the payer's (102) response; this might be part of the video functionality since that may be configured to capture sounds and/or speech as well as images; or it might be augmented by the system (106) requiring the payer (102) to read out the displayed information relating to the transaction - further confirmation that the payer (102) is cognisant of the specific payee account details at the time of consenting (or not consenting) to the proposed transaction.

A further advantage of using video and/or audio technology is that it can also be used to confirm that the account-holder or payer (102) is not being guided through the authentication process by another person. It can also assist with capturing any indication(s) of uncertainty of the account-holder or payer (102) regarding the transaction. This can be particularly useful in detecting situations where there may be elder abuse occurring, or situations where the account-holder or payer (102) is under some control or duress by a third party.

Having received the determination of the match and optionally the payer's indication of consent (132), the system (106) conveys or outputs this information (134) to the intermediary (104). As noted above, at this stage the system (106) preferably also conveys or outputs to the intermediary (104) any warning indications or messages associated with the proposed financial transaction. Said conveying or outputting (134) may take place in a number of ways, depending on how the system (106) is configured. It may take place automatically, i.e. be automatically transmitted / outputted to the intermediary (104) upon completion of the process; this may be the case whether the system (106) is distinct from the intermediary (104) or integrated with it. Alternatively, the system (106) may store its analysis / results relating to a given transaction, for selective retrieval by the intermediary (104) at a given time, such as via the intermediary (104) logging in to their account on a portal of the system (106); or the analysis / results may be manually conveyed to the intermediary (104), such as via email or other communication from the system (106) to the intermediary (104) (i.e. an administrator / employee of the system and intermediary, respectively).

The intermediary (104) then proceeds accordingly - that is to say, they may complete the transaction if there are no indications of fraudulent activity or if they are otherwise satisfied with the analysis / results in respect of the transaction, whereas if the system has returned a negative match or the payer (102) has returned a negative indication of consent, or if any other anomalies have been detected in respect of the transaction, the intermediary (104) may either refuse to complete the transaction and / or may take other investigative measures, depending on what they see fit. This aspect of the process, too, may be automated to a greater or lesser degree, depending on the preference and needs of the intermediary (104). For instance, transactions which are a "clear" candidate for acceptance or rejection (or which are above some predetermined threshold or confidence score set by the intermediary or the system in these respects) might be automatically completed or aborted, as the case may be; while borderline / questionable / ambiguous cases may be flagged as requiring further follow-up by the intermediary (104).

The system (106) also stores in the memory the payer's (102) indication of consent in respect of the payee account number. In this way, there is documentary evidence of the payer (102) having consented to the proposed financial transaction to that account number. This evidence is available in case the payer (102) subsequently alleges that the transaction was fraudulent. The payer's (102) documented consent, particularly in light of the messages displayed by the system warning of fraud risk and in particular urging the payer (102) to verify the payee account number, will provide the intermediary (bank) (104) with valuable evidence to combat false claims of "fraudulent transactions" by customers.

It will accordingly be appreciated that the present invention provides a system (and corresponding method) that is highly secure, and uses multiple layers of authentication /

verification to verify a proposed financial transaction from multiple different perspectives (and document / record said verification). In doing so, the invention combats / mitigates multiple different types of fraud - fraud involving impersonation of a payer; fraud involving impersonation of a payee; situations involving elder abuse; and fraud perpetrated by the payer themselves.

As noted above, while in this section the invention has described with reference to a financial transaction, the invention may be applied in a range of different contexts / applications, to a variety of different types of transaction.

It will of course be realized that while the foregoing has been given by way of illustrative example of this invention, all such and other modifications and variations thereto as would be apparent to persons skilled in the art are deemed to fall within the broad scope and ambit of this invention as is hereinbefore described.

If any reference numeral(s) is/are used in a claim or claims then such reference numeral(s) should not be considered as limiting the scope of that respective claim or claims(s) to any particular embodiment of the drawings.

It is acknowledged that the term 'comprise' may, under varying jurisdictions, be attributed with either an exclusive or an inclusive meaning. For the purpose of this specification, and unless otherwise noted, the term 'comprise' shall have an inclusive meaning - i.e., it will be taken to mean an inclusion of not only the listed components it directly references, but also other non-specified components or elements. This rationale will also be used when the term 'comprised' or'comprising' is used in relation to one or more steps in a method or process.

Claims (19)

1. A system configured to mitigate fraud in transactions, the system comprising a server having a processor and a memory, the system being configured to, in use: receive information relating to a proposed transaction involving an account, including at least one identifier and contact information of an account-holder of the account and details of the proposed transaction; communicate with an electronic device owned or used by the account-holder to obtain a confirmation of the identifier of the account-holder; determine whether the confirmation of the identifier of the account-holder matches the identifier of the account-holder initially received by the system; optionally send to the account-holder at least a portion of the details of the proposed transaction, along with a request for the account-holder to indicate whether they consent to the proposed transaction being made and obtain from the account-holder an indication of whether they consent to the proposed transaction being made; and output the determination of the match and/or said indication of consent from the account-holder.

2. A system as claimed in claim 1 wherein the system receives the information relating to the proposed transaction from an intermediary associated with the account, and outputs said determination of the match and/or said indication of consent from the account holder to the intermediary.

3. A system as claimed in claim 2 wherein the system is integral with the intermediary.

4. A system as claimed in claim 2 wherein the intermediary automatically sends said information relating to the proposed transaction to the system.

5. A system as claimed in any one of the previous claims wherein the system communicates directly, or indirectly via communication with the intermediary, with the electronic device owned or used by the account-holder to obtain the confirmation of the identifier of the account-holder.

6. A system as claimed in any one of the previous claims wherein the communicating with said electronic device comprises sending a message, such as a text message, email, or pop-up notification, to said electronic device, wherein the message comprises a link, such as a URL or QR code, via which said confirmation of the identifier of the account holder will be effected.

7. A system as claimed in any one of the previous claims wherein obtaining the confirmation of the identifier of the account-holder comprises utilizing biometric authentication technology.

8. A system as claimed in claim 7 wherein the biometric authentication technology is facial authentication technology.

9. A system as claimed in claim 8 comprising obtaining a real-time image of a face of the account-holder and comparing said real-time image to an image of a face of the account holder in an official photo-identity document, such as a government-issued photo identity document, to determine if there is a match between the respective images and thus if the confirmation of the identifier of the account-holder matches the identifier of the account-holder initially received by the system.

10. A system as claimed in claim 8 or 9 wherein the system further comprises prompting the account-holder to input or scan the details of said official photo-identity document, to enable the system to access said official photo-identity document from a repository.

11. A system as claimed in any one of the previous claims wherein the system is configured to, if the confirmation of the identifier of the account-holder matches the identifier of the account-holder indicated by the intermediary but one or more anomalies is detected, associate a warning indication or message with the proposed transaction.

12. A system as claimed in any one of the previous claims wherein the system only sends to the account-holder the at least a portion of the details of the proposed transaction and the request for the account-holder to indicate whether they consent to the proposed transaction being made, if the confirmation of the identifier of the account-holder matches or passes an acceptable threshold of probability of a match to the identifier of the account-holder initially received by the system.

13. A system as claimed in any one of the previous claims wherein the indication of whether the account-holder consents to the proposed transaction being made is obtained via a manual input from the account-holder of an affirmative or negative response, or by detecting via video and/or audio whether the account-holder indicates an affirmative or a negative response.

14. A system as claimed in claim 13 wherein said detecting via video includes using facial authentication technology to confirm that the account-holder is looking at a portion of the account-holder's screen on which the at least a portion of the details of the proposed transaction is displayed.

15. A system as claimed in claim 13 wherein said detecting via audio includes using voice recognition and authentication technology to confirm the identity of the account-holder.

16. A system as claimed in any one of the previous claims wherein in addition to outputting said indication from the account-holder, the system also outputs any warning indications or messages associated with the transaction.

17. A system as claimed in any one of claims 2 - 16 wherein the intermediary only proceeds with the proposed transaction if said determination of the match and/or said indication of consent comprises an affirmative response or a response that passes an acceptable threshold of probability of an affirmative response as determined by the intermediary.

18. A system as claimed in any one of the previous claims wherein the system is further configured to store in the memory of the server said indication of consent from the account-holder.

19. A method of mitigating fraud in transactions, utilizing the system as claimed in any one of claims 1 - 18, wherein the method comprises the steps of: receiving information relating to a proposed transaction involving an account, including at least one identifier and contact information of an account-holder of the account and the details of the proposed transaction; communicating with an electronic device owned or used by the account-holder to obtain a confirmation of the identifier of the account-holder; determining whether the confirmation of the identifier of the account-holder matches the identifier of the account-holder initially received by the system; optionally sending to the account-holder at least a portion of the details of the proposed transaction, along with a request for the account-holder to indicate whether they consent to the proposed transaction being made and obtaining from the account holder an indication of whether they consent to the proposed transaction being made; and outputting said determination of the match and/or said indication of consent from the account-holder.