FRAUD DETECTION SYSTEM, METHOD, AND DEVICE

Abstract

The present invention provides a method of authenticating a transaction, the method having: responsive to receiving a request for authenticating a transaction involving a first device and including first device information defining at least one first device characteristic of the first device, obtaining second device information defining at least one second device characteristic of a second device associated with the transaction; determining a level of correlation between the first device information and the second device information; and authenticating the transaction based on the level of correlation between the first device information and the second device information, wherein the transaction is authenticated when the level of correlation between the first device information and the second device information is above a pre-determined threshold.

Description

FIELD OF THE INVENTION

The present disclosure relates to a system, method and device for fraud detection in transactions over communications networks.

BACKGROUND

Credit card fraud costs banks time, money and has become an increased problem with cyber-crime, phishing schemes, and other programs designed to take advantage of fraudulent credit cards or means for payment.

Additionally, due to the scale of card fraud, issuing banks tend to implement quite aggressive strategies in order to combat the problem. This, however, leads to high false positive rates that cause extreme inconveniences to cardholders and merchants resulting in high operational costs (including resolution management) to the issuer. As an additional consequence, high volumes of false positives may also prevent the issuer from declining further transactions, leading to additional losses.

Existing risk-engine strategies do not have the benefit of information on user generated information (including online complaints regarding merchants, hidden charges, billing errors) and the real-time status of the cardholder, they are not well suited to cross-border transactions where behavioral and historical patterns do not fit the norm.

Moreover, without verification in real time at the point of sale between the various players in the ecosystem (e.g., banks, card companies, merchants, consumers), real-time fraud detection/prevention has been challenging, to enable effectively.

Therefore, there is a need for a new solution whereby all parties to the financial ecosystem may benefit from user generated information and real time verification.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a fraud detection system, method, and device. In accordance with an aspect of the present invention, there is provided a method of authenticating a transaction, the method having: responsive to receiving a request for authenticating a transaction involving a first device and including first device information defining at least one first device characteristic of the first device, obtaining second device information defining at least one second device characteristic of a second device associated with the transaction; determining a level of correlation between the first device information and the second device information; and authenticating the transaction based on the level of correlation between the first device information and the second device information, wherein the transaction is authenticated when the level of correlation between the first device information and the second device information is above a pre-determined threshold.

In accordance with another aspect of the present invention, there is provided an authentication device having: a communications interface for receiving requests for authenticating transactions involving a first device, each request comprising a first device and including first device information defining at least one first device characteristic of the first device, and obtaining second device information defining at least one second device characteristic of a second device associated with the transaction; an authentication system having a first authentication unit for, for each request: means for obtaining second device information defining at least one second device characteristic of a second device; means for determining a level of correlation between the first device information and the second device information; and, means for authenticating the transaction based on the level of correlation between the first device information and the second device information, wherein the transaction is authenticated when the level of correlation between the first device information and the second device information is above a pre-determined threshold.

In accordance with yet another aspect of the present invention, there is provided a method of fraudulence verification of a transaction being conducted over a communications network, the transaction having associated transaction information, the method having: comparing the transaction information with database information stored in a database to determine whether a transaction is potentially fraudulent; sending a request to a second device associated with the transaction requesting confirmation information on whether the transaction is fraudulent; and, responsive to receiving a response with the confirmation information, authenticating the transaction using the confirmation information.

In accordance with yet another aspect of the present invention, there is provided a method of providing an alert having: checking database information stored in a database relating to one of an entity associated with a first device and an entity associated with a second device; and, sending an alert notice to the other of an entity associated with a first device and entity associated with a second device relating to the database information.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a network communications system in which implemented is a fraud prevention system for transactions, in accordance with an embodiment;

FIG. 2 is flow chart of one example of a method of authenticating a transaction in the fraud prevention system based on location criteria;

FIG. 3A is a block diagram of an example of one variety of an authentication device;

FIG. 3B is block diagram of an example of one variety of a user device;

FIG. 4A is a messaging flow diagram for one embodiment of authentication of a transaction in the network communications system for a case when authentication of a transaction succeeds;

FIG. 4B is a messaging flow diagram for one embodiment for authentication of a transaction in the network communications system for a case when authentication of a transaction originally fails;

FIG. 4C is another messaging flow diagram for one embodiment of authentication of a transaction in the network communications system for a case when authentication of a transaction originally fails;

FIG. 5 is a block diagram of an example of user device suitable for use with the fraud prevention system;

FIG. 6A is a messaging flow diagram for one embodiment of authentication of a transaction in the network communications system in a push system for a case when verification of fraudulence of a transaction shows fraudulence;

FIG. 6B is a messaging flow diagram for one embodiment of authentication of a transaction in the network communications system in a push system for a case when verification of fraudulence of a transaction shows no fraudulence;

FIG. 7 represents a flow diagram of one implementation of the fraud detection unit method;

FIG. 8 represents a flow diagram of another implementation of the fraud detection unit method;

DETAILED DESCRIPTION OF THE INVENTION

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

The present invention provides a fraud detection and resolution management system, method, system, and device which analyze a variety of dynamic characteristics to authorize financial transactions.

System Overview

Referring to FIG. 1, shown is a network communications system in which implemented is a fraud prevention system for transactions, in accordance with an embodiment. The network communications system may include communications service provider sites, banking institution sites, fraud reporting centers, LANs (Local Area Networks), transaction sites, and wireless user devices coupled to a network. Only two communications service provider sites, two banking institution sites, two fraud reporting centers, two LANs, two transaction sites, and two wireless user devices are shown for illustrative purposes.

More generally, the network communications system has one or more communications service provider sites, one or more banking institution sites, one or more fraud reporting centers, one or more LANs, one or more transaction sites, and one or more wireless user devices. In some implementations, one or more of the banking institution sites includes a fraud reporting center. Each banking institution site includes a fraud prevention system having a transaction server, an authentication device and a call agent. Each fraud reporting center includes a database and a fraud reporting unit. Each LAN includes a plurality of user device and an access point. Each communications service provider site has a location information server. Each transaction site includes a server. The network allows communications between the wireless user devices, the transaction servers, the authentication devices, and the call agents at the fraud prevention systems, the location information servers at the communications service provider sites, the user devices and access points at the LANs, the servers at the transaction sites, and the fraud reporting units of the fraud detection centers to communicate with each other through wired and wireless communications.

The network includes a combination of one or more cellular networks and one or more wired telephony networks and the Internet, for example.

User Devices and User Specific Information

The user devices are used to perform transactions, such as online banking transactions, credit card and debit card, ATM, PoS (Point-of-Sale), eCommerce, and remote access transactions for example. Such transactions are carried out by the servers at the transaction sites. More generally, the transactions include transactions requiring security such as transactions for commerce and payments, for example.

A user device may be any device capable of network access. This device may be either wired or wireless. In some embodiments, the device may include a personal computer, tablet, mobile device, mobile phone, television, music player, personal organizer, or any similar electronic network enabled device. In some embodiments, the user device may be wearable technology including, but not limited to, jewelry (e.g., earrings, bracelets, bands, necklaces), piercings (e.g., subcutaneous or not, in essentially any part of the body), watches, glasses, hats, clothing (e.g., underwear male and female, pants, dresses, shirts, sweater, jacket), shoes, socks—essentially anything that is placed on or in a person can potentially include electronics and network enablement. In some embodiments, the user device may include an interface for accepting credit card payment or debit payments at a business for example.

A user using one of the user devices or wireless user devices may initiate a transaction, and the transaction is initiated through one of the fraud prevention systems. More particularly, the fraud prevention system makes use of user specific information. User specific information includes and identifiable characteristic of the user. User specific information includes, but is not limited to, location of the user relative to the server (e.g., GPS on mobile devices may be utilized to extract location data), user behavioral analytics of mobile device (e.g., keystroke frequency, application tendency, call history), biometric analytics (e.g., voice verification, fingerprint verification, retina verification), device contextual checks, network intelligence (e.g., detection of call forwarding, phone type, post-paid/pre-paid, landline, VOIP, spoofing, SIM swaps, VPN, proxy), and information extracted from crowdsourced information (e.g., scouring social media feeds such as FourSquare® or Twitter® to search for locational information or general commentary, complaints, peer-to-peer interactions).

Each of the previously mentioned characteristics may be used in any combination thereof to combine information in order to generate a higher probability of confirming the identity of the user at the point of transaction. For example, location based information may be used with behavioral monitoring to raise a flag that user has not been in a certain store for the last 12 months yet wishes to purchase from this specific location. These characteristics are used at the authentication stage in a process utilizing dynamic weights assigned to each of the user specific characteristics to determine whether the sum weighted score meets the threshold required in order to achieve valid authentication and process the financial transaction.

With respect to the location user specific information, a user's location may be extracted from user's mobile GPS, user's IP address, carrier API, cellular triangulations, social network data mining, CCTV surveillance, satellite monitoring, among other location based identifiers.

In some embodiments, location analysis may be multi-faceted and implemented as follows: retrieving first location of transaction (e.g., merchant), retrieving second location of User's mobile, retrieving third location of user's tweet (via Twitter® API) based on time/age, retrieving forth location of user's Facebook® status update based on time/age, retrieving fifth location of user's Foursquare® checking based on time/age, retrieving sixth location of users on CCTV and other real-time public databases, retrieving other location sources from mining the web and social media sites. These different characteristics are combined and put into the dynamic weighting analysis stage where a dynamic weighting factor is assigned to each user specific characteristic. The dynamic weighing is received from a dynamic database assigning values for each factor. It should be noted that the weights change depending on the user information received from the user.

In some embodiments, the user specific information used is the first location information of the user device provided by the user device and second location information of another user device provided by the location information server of a respective one of the communications service providers that provides communication capabilities to the user. The other user device is the user's mobile phone or any other portable device carried by the user for example. Authentication of the transaction relies on a correlation between the first and second location to validate the transaction. In some embodiments, transactions are carried out via the server at one at one of the transaction sites. Furthermore, in some implementations, the user device is located at the transaction site as the case may be in an ATM or credit/debit card payment system.

In some embodiments, the first and second devices can be the same device. Particularly, the means for payment and the mobile device may be one in the same. In some embodiments, a mobile device may be configured with credit card authorization. This may be accomplished by any means including “mobile wallet” technology where a mobile device has one or more payments means (including credit cards embedded) which is utilized with the first device location. In some embodiments, applications and operations performed using Near-Field Communication (NFC) may be considered as having the first device and second device in the same device. In some embodiments, the first device and second device may be considered mobile browser based commerce operated from the mobile device of the user. In some embodiments, it is contemplated that SIM based credit may be used on a user's mobile device for commerce. In some embodiments, it is contemplated that Peer-to-Peer transactions may be enabled over the user's device.

In other implementations the first and second devices are different devices. As mentioned previously, this is where the authenticating device and the user device exist in two discrete devices, for example a merchant credit card module and a user's mobile phone, or a retina scanner and a user's eye.

The user may be referred to as an entity and therefore may refer to the customer or the merchant.

Authentication

The authentication stage is where all the user specific information is evaluated to determine whether further verification is required, or the transaction may proceed to processing. The authentication stage may vary depending on application in terms of complexity and the number of factors taken into consideration.

Authentication may be provided such that the characteristics used for verification may be implemented at the authentication stage in order to produce a higher degree of security taking into account more information; or conversely, for simplicity, the additional characteristics may be left for verification if the initial characteristics does not meet the specified threshold.

In some embodiments, location may be used as the sole initial characteristic required for authentication. Referring to FIG. 2, shown is flow chart of a method of authenticating a transaction in the fraud prevention system of FIG. 1. In some embodiments, the method is implemented by the authentication device at any one of the banking institution sites. At step 201, in response to receiving a request for authenticating a transaction involving a first device at first location second information on the location of a second device associated with the transaction is obtained. The request includes the first location information, and at step 202 a level of correlation between the first location and the second location is determined. The location information includes an IP address, latitude and longitude coordinates or a postal or ZIP code, for example. At step 203, the transaction is authenticated based on the level of correlation between the first location and the second location. The correlation must be within a defined threshold representative of the accurate distance of a mobile phone to a credit card. This threshold will vary depending on application.

If the authentication is valid at step 204, the authentication is continued at step 205 by requesting credentials from the user and processing the transaction downstream. If the user device is a mobile phone step 205 involves a call to the user device requesting user identification information and a PIN (Personal Identification Number), password, or unconstrained finger swipe for example. If the user device is a debit/credit card device at a merchant for example, the credential involve user and account information, together with an unconstrained finger swipe/PIN/password and allowing/blocking/flagging the transaction for example.

The request received at step 201 includes a phone number or a unique identifier of an entity corresponding to the user device or other device, such as a mobile phone or home phone for example, or an identifier of the user. If the authentication fails at step 204, in one embodiment, at step 206 a call between the call agent and the entity is established using the phone number or secure 2-way messaging. In some implementations, at step 206 the authentication device sends a call request to the call agent and the call agent sets up a call with the user device or other user device for further verification. The verification can use rich push notifications, an automated phone, two-way SMS (Short Message Service) messaging, voice biometric requests, or mobile phone based ‘Secure Elements’, such as SIM (Subscriber Identity Module) cards, SD (Storage Device) cards, or chip based cards for example.

With reference to FIG. 1 and FIG. 2, at step 201 the second location includes information obtained from the location information server at a respective one of the communications service provider sites responsible for providing communications to the second device requesting the transaction. Alternatively, in other implementations, user devices periodically registers their positions and/or changes therein with respective fraud prevention systems, and location information is obtained by retrieving relevant information from the databases at the fraud prevention systems.

In some embodiments, the authentication involves having the authentication device send information to the user device confirming the authentication. In some embodiments, GPS on the user device may provide location based information constantly, or at a specified interval. In some embodiments, retina scanners implementing biometrics at a location may scan the user's physical eye to authenticate identity and associate a user with a location. In some embodiments, the user device is measured relative to other device in close proximity, whether the other device is the authentication device or a third party device interacting with the system.

In some embodiments, the request received at step 201 includes one or more first characteristics associated with the user device other than the second location information.

Multi-Characteristic Authentication

Authentication may comprise the analysis of multiple characteristics to verify the identity of the individual and enable fraud detection. Each of the characteristics has a dynamic weighting such, based on circumstance such that the weighting may change in the calculation with respect to pre-defined rules. Therefore, one characteristic may have a high weighting (e.g., location obtained from IP), however, if this characteristic is in disagreement with other characteristics which are analyzed, the threshold level required for passing valid authentication may not be allowed without further scrutiny in the verification stage.

As mentioned previously, these additional characteristics include the velocity of the user device, a characteristic of environment in which the user device is in, the gait of the user, the keying speed of keys being typed in the user device, biometrics, behavioral analytics, for example. In such embodiments, at step 201 for each first characteristic a respective second characteristic associated with the user device is obtained. At step 202 for each first characteristic a respective level of correlation between the first characteristic and the respective second characteristic is determined. At step 203 the transaction is authenticated based on the respective level of correlation between each of the first characteristic and the respective second characteristic. More specifically, in some implementations the authentication fails if any one or more correlation is below a respective threshold value. However, it is to be clearly understood that other implementations are possible. For example, in some implementations the authentication fails if any N or more correlations are below respective threshold values, where N is an integer with N≧1. In other implementations the authentication fails if any M or more correlations are below respective threshold values, where M is an integer with M≧2, or if anyone or more of a subset of the correlations are below respective threshold values. It is contemplated that further subsequent characteristics may be implemented in the comparison analysis, and analysis is not limited to two characteristics.

With respect to dynamic weighing, the general operations are implemented as follows. A pre-set weighting is given to each characteristic in a database. Said database is utilized for each authentication where unless a set of programmed weighted factors are assigned to each user specific characteristic are applied into the database. For example, if location by GPS specifies a certain address, however the location via IP specifies a different address, the location authentication may reduce in weighing as different sources are in disagreement. However if there is an additional verification for location using fingerprint scanning at a credit card terminal, this may be enough to outweigh the previous ambiguity of location based on IP and GPS. This set of exhaustive combinations is held within a data-base and the rules of such may be adjusted as required.

In some implementations, some transactions do not need authentication using credentials and step 205 is not required for authentication for such transactions.

Authentication and Communication Interface

Further details of the structure and operation of the authentication device and the user device will now be described with reference to FIG. 3A and FIG. 3B.

A block diagram of an example of the implementation of the authentication device of FIG. 1 is shown in FIG. 3A. The authentication device has a communications interface and an authentication system having an authentication unit and a call activation authentication unit. The communications interface provides the authentication device with the capability of communicating with other devices for purposes of receiving requests for authenticating transactions, obtaining location information from location information servers, confirming authentication, and requesting calls through a third party for verification; a call agent, for example. For each request received, the authentication unit obtains second location information defining a second location of another user device associated with the transaction. The authentication unit also determines a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location. When authentication fails the authentication unit makes a request to the call activation unit for a call to be established between the third party (e.g., call agent) and the first or second device so that failure of authentication can be reported and to resolve the problem, if possible.

In FIG. 3A, the functionality of each of the communications interface and the authentication system and its authentication unit and call activation unit can be implemented using any suitable combination of software, hardware, and firmware.

Referring to FIG. 3B, shown is block diagram of a user device of FIG. 1. The user device has a number of features well suited for use in a wireless user device such as a mobile phone for example, and it is to be clearly understood that some of the features described below are optional. The user device has a graphical user interface, a transaction authentication information unit, a communication interface, a GPS (Global Positioning System) unit, an environment unit, a key login speed unit, a gyroscope, and an accelerometer. The user interface provides the user with the ability to enter and view information and includes a keyboard and display for example.

The communications interface allows the user device to communicate with other devices and servers in a network communications system. In some embodiments, the GPS unit provides position and velocity information for use in the authentication process. The environment unit may provide information on environmental conditions such as temperature and wind speed and/or velocity, for example. The key login speed unit monitors the speed at which login information is keyed in. The transaction authentication unit communicates with the GPS unit to receive location and/or speed information on the user device. The transaction authentication unit communicates with the environment unit to receive information on environmental conditions at the location of the user device. In addition, the transaction authentication unit communicates with the key login speed unit to receive information on the speed of key logins in order to differentiate between manual and automated logins. The transaction authentication unit communicates with the gyroscope and the accelerometer to receive information for determining gaiting of the user and acceleration of the user/device. The transaction authentication unit also communicates with the graphical user interface to provide a GUI (Graphical User Interface) for displaying information relevant to the authentication process and for user input of information required for input by the user.

In FIG. 3B, the functionality of each of the graphical user interface, the transaction authentication unit, the communications interface, the GPS unit, the environment unit and the key login speed unit can be implemented using any suitable combination of suitable software, hardware, and firmware.

Valid Authentication—No Verification

Referring to FIG. 4A shown is a messaging flow diagram for an example of authentication of a transaction in the network communications system of FIG. 1 for a case when authentication of a transaction is deemed valid. A transaction between a transaction server and a server at a transaction site initiated by a user at a first user device is established. User specific information utilizing various characteristics is analyzed.

In the following example, one of the primary characteristics analyzed is location. During initiation of the transaction the user device provides first location information on the location of the first user device, and the server at the transaction site transmits transaction information necessary for the transaction to the transaction server. The information includes, among other information, the first location information on the user device, together with a phone number of the user, for example. As discussed above, in some implementations the information includes additional characteristic information related to the first user device. The transaction server calls an authentication device and the authentication device requests second location information defining the location of a second user device associated with the transaction from location information servers 1 to N, each at one of N communications service provider sites where N is an integer with N≧1. The location information server of the communications service provider that provides communications services to the second user device provides a response containing the second location information. In some implementations the authentication device is provided with an identification of the communications service provider that provides communications services to the second user device and the query is sent only to one location information server. In some embodiments, the fraud prevention system includes a fraud prevention unit, a database, as well as authentication device, third party interface (e.g., call agent), and transaction server.

Responsive to receiving the second location information, the authentication server performs location authentication by determining a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location. For example, in one implementation the authentication is valid if the distance between the first and second locations is less than 50 km; otherwise, it fails. A verification request is sent to the second user device in response to the location authentication requesting user credentials. In some implementations the user credentials include a PIN (Personal Identification Number), implicit information, or biometric information, for example. Responsive to receiving the authentication request the user credentials are entered and a reply containing the user credentials is transmitted to the authentication device. The user credentials are authenticated and the authentication device transmits a message to the second user device indicating that the authentication has been verified.

In some embodiments, the authentication is done locally on the first or second device and not transmitted; only the authentication success/failure information is transmitted.

As discussed above, in some implementations for some transactions there is no need for authentication using user credentials and in such cases there is no verification of user credentials when authentication based on location or other invisible correlation information succeeds.

In the exemplary scenario of FIG. 4A authentication of the transaction succeeds and further verification need not be applied.

Authentication Fails—Verification Required

A different scenario in which the location authentication transaction originally fails will now be described with reference to FIG. 48.

In FIG. 4B, the signaling process is similar to that of FIG. 4A up to the point where location authentication is performed. In this case the correlation between the first and second locations is not sufficiently high and results in a failed authentication during the location authentication step. In response to the failed authentication, the fraud detection server sends a response to the user device with information on the failed authentication.

At this point verification may be implemented to verify the identity of the individual. In some embodiments, verification includes a person to person interaction to identify an individual. In some embodiments, verification includes utilizing one or more user based characteristics not initially used for authentication.

Continuing in FIG. 4B this example implements a person to person verification by means of a call agent. The fraud detection server sends a request to a call agent for establishing a call between the call agent and the first user device. The call agent picks up the call and sends a response to the fraud detection server indicating that the call has been picked up. The fraud detection server also sends a request to the first user device for the call. The first user device picks up the call. The request contains information necessary for the first user device to establish the call with the call agent, communicates with the call agent, and the call is established. A user at the first user device and the call agent can communicate with each other to perform authentication.

It is contemplated that multi-party third party verification may occur. For example, in a family setting, if the husband has the mobile device but the wife is using the credit card at a separate location, the third party agent may verify the authorization with both parties with consent of the cardholder.

In some embodiments, the user at the first user device may be required to provide additional authentication information so that the transaction can be allowed. The additional authentication may include any of the user specific characteristics listed previously. Additionally, the information may include any one or more of the user's mother's maiden name, the user's birth date, and the name of the user's preferred pet, for example. If the user cannot provide the correct additional authentication information the transaction is refused.

In FIG. 48 the request for a call is initiated by the fraud detection server by sending requests to both the call agent and the first user device. However, it is to be clearly understood that implementations are not limited to this particular implementation. For example, in another implementation the fraud detection server informs the call agent that a call is to be established between the call agent and the second user device, and the call agent initiates the call by sending a request to the second user device.

As discussed above, the first user device at which a transaction is initiated may be a mobile phone, a personal computer, or a debit/credit card reader for example. In the case of a personal computer or a debit/credit card reader, for example, the call may be established with the user's user call device such as a mobile phone, home phone, VOIP phone, for example.

Furthermore, in some cases a transaction with the transaction server may be initiated by the user device through one or more servers. For example, a user may be at a PC (Personal Computer) and making a purchase and payment on the Internet. The servers might be controlled by merchants for example or by entities that offer Internet payment services, such as PayPal® for example. In such a case, the transaction may be conducted between a server and the transaction server. The user device communicates with the server and the server relays location information on the first user device to the transaction server.

Referring to FIG. 4C, shown is another messaging flow diagram for authentication of a transaction in the network communications system of FIG. 1 for a case when authentication of a transaction originally fails. The messaging flow diagram of FIG. 4C is similar to that of FIG. 4B except that in this case upon a failed authentication, a call is established between a second user device and the call agent instead of between the first user device and the call agent.

For example, the second user device may be a bank's landline phone system, a lending instruction's VOIP service, or an investment firm agent's mobile phone.

More particularly, in response to the failed authentication the fraud detection server sends a response to the server with information on the failed authentication. The fraud detection server also sends a request to the call agent for establishing a call between the call agent and the second user device. The call agent picks up the call and sends a response to the fraud detection server indicating that the call has been picked up. The fraud detection server also sends a request to the second user device for the call. The second user device picks up the call. The request contains information necessary for the second user device to establish the call with the call agent. The second user device communicates with the call agent and the call is established. The user at the second user device and the call agent can communicate with each other to perform authentication. For example, the user at the second user device may be required to provide additional authentication information so that the transaction can be allowed, as described above with reference to FIG. 48.

Fraud Prevention Communication System utilizing Aggregate User Data

An additional embodiment to the invention includes the utilization of the one or more user specific characteristics to notify users of the system that certain merchants and/or specific goods or services may be suspect given previous transaction history. In this way, the system may implement a preventative fraud protection scheme. In some embodiments, the aggregation of user based transaction related data history is used as one of the specific characteristics.

Flagging Transactions at Point of Sale

An additional fraud prevention mechanism which uses a notification system can also be implemented by confirming transactions with client/user when they are underway. More particularly, the mechanism involves a method of verifying whether a transaction being conducted over a communications network is fraudulent. The transaction has associated with it transaction information and a user device for fraudulence verification.

The method involves comparing the transaction information with other information in a database to determine whether a transaction is potentially fraudulent. A request is sent to a user device requesting user credentials and confirmation information on whether the transaction is fraudulent or not. In response to receiving a response with the user credentials and the confirmation information, a determination of whether the user credentials allow access to the transaction is made and the transaction is authenticated using the confirmation information only if the user credentials allow access to the transaction. Such a mechanism will now be described in more detail with reference to FIG. 5, FIG. 6A, and FIG. 6B.

The user may flag the transaction utilizing various degrees of concern. In some embodiments, the user may flag the current transaction as “concerned” which lets the transaction through but flags the transaction for a follow up check at a later time. Alternatively, the user may flag the current transaction as “suspected fraud” where a third party (e.g., a call agent) is contacted to initiate further verification. Additionally, the user may flag the current transaction as “definitely fraud” where the transaction is blocked from proceeding and third party authorities are notified.

In some embodiments, the notifications with respect to a specific merchant or vendor are stored in a database where each of the previous flags assigned per transaction at the merchant by users of the system are saved. In this way, when a new user visits a merchant which has questionable credentials based on the database analytics within the fraud detection unit, the database will send a summary of the previous transaction flagging history to the user currently processing a transaction such that the user may take this information into account prior to proceeding with the processing of the transaction.

In some embodiments, the threshold for calculating the tolerance for suspicious activity changes with volume of transactions. Furthermore, the threshold may be set manually by the system administrator or dynamically but process given input from various data inputs (e.g., transaction information).

Fraud Prevention System Implementation

Referring to FIG. 5, shown is a block diagram of another user device suitable for use with the fraud prevention system of FIG. 1. The user device is similar to the user device of FIG. 3B except that it includes a fraud confirming unit. In FIG. 5, the functionality of each of the graphical user interface, the transaction authentication unit, the communications interface, the GPS unit, the environment unit, the key login speed unit, the gyroscope, the accelerometer, and the fraud confirming unit can be implemented using any suitable combination of software, hardware, and firmware.

The transaction authentication unit communicates with the fraud confirming unit to collectively provide a mechanism for responding to requests for verification that has been recently carried out, and on-going transactions are indeed non-fraudulent transactions and for flagging fraudulent transactions.

Such a mechanism will now be described in more detail with reference to FIG. 6A, which is a messaging flow diagram for authentication of a transaction in the network communications system of FIG. 1 in a push system for a case when verification of fraudulence of a transaction shows fraudulence. In this messaging flow a transaction is underway between a server at a transaction site and an authentication, and the authentication device sends a VERIFY message to a fraud reporting unit containing information regarding the transaction. The fraud reporting unit may be located at a fraud reporting center that contains a database, such as the fraud reporting centers of FIG. 1.

The information contained in the VERIFY message includes information suitable for identifying a fraudulent user, such as a fraudulent merchant for example. For example, the information may include but is not limited to any one or more of the location of the user device requesting the transaction, identification of the user device, identification of the user of the user device, the number of transactions of a particular merchant, user, or other entity, which have been identified as fraudulent and/or the number of transactions of a particular merchant, user, or other entity, which have been identified as potentially fraudulent, and any user specific information.

The fraud reporting unit verifies its database to determine whether the received information matches any entry in the database that would confirm that the transaction is potentially fraudulent.

For example, the database might contain an entry for a particular merchant called “BadBuy” for example, with the entry indicating five fraudulent transactions in the last three days. As such, in some implementations any transaction from this merchant would be identified a potentially fraudulent. The fraud reporting unit replies to the authentication device with a REPLY message indicating whether the transaction is potentially fraudulent or not. The authentication device verifies whether the message indicates a potentially fraudulent transaction or not, and in this case the transaction is potentially fraudulent. The authentication device sends a VERIFICATION message to the user device indicating that a potentially fraudulent transaction is underway and requesting user credentials and confirmation of whether the transaction is indeed fraudulent or not.

The user provides input of the credentials and in this case the user confirms that the transaction is indeed fraudulent by sending a REPLY message to the authentication device. The REPLY message contains information confirming that the transaction is fraudulent together with the user credentials. The authentication device verifies that the user credentials are correct and determines that the transaction is fraudulent based on the information contained in the REPLY message.

In this example, the authentication device then sends a notification message to a call agent containing information related to the transaction. For example, the information includes any one or more of the location of the user device requesting the transaction, identification of the user device, identification of the user of the user device, and any user, merchant, or other entity's or transaction specific information. The call agent looks up which fraud reporting units are to be notified and relays the received NOTIFICATION message to the fraud reporting units.

In some embodiments, this may lead to a block being applied on the user's card or transactions so that further transactions are not allowed, until the issue is resolved.

Responsive to receiving the NOTIFICATION messages, the fraud reporting units update their respective databases with the information contained in the NOTIFICATION messages. The fraud reporting unit that receives the VERIFY message also looks up its database to identify other user devices that should be notified for potentially fraudulent transactions.

For example, the fraud detection unit may look through transactions in its database which have occurred in the last sixty days together with on-going transactions and identify transactions from a particular user device. Alternatively, the fraud detection unit may look in its database for transactions which have occurred in the last sixty days, together with on-going transactions, and identify potentially fraudulent transactions involving a specific amount from a particular merchant. The fraud reporting unit then sends a NOTIFICATION REQUEST containing call information for calling other user devices associated with the identified potentially fraudulent transactions, together with information on the potentially fraudulent transactions. Responsive to receiving the NOTIFICATION REQUEST, the call agent sends NOTIFICATION to the other user call devices.

The notification may be in any format for which can be received on a user device. In some embodiments, the notification is in the form of a rich push notifications including, but not limited to, an email, an SMS, instant message, VOIP call, or a phone call, and other medium of electronic messaging. Furthermore, each notification includes information for identifying a respective transaction and allowing the user to determine whether the transaction is indeed fraudulent.

Fraud Detection Unit Analytics

As mentioned previously, the fraud detection unit monitors various aspects of the transaction and takes into circumstances into the weighted decision. Analysis includes clustering merchants and transactions by their characteristics (e.g., location, type of business, ownership, item purchased) and comparing those clusters with clusters of individuals making the purchase (e.g., gender, age, purchase history, known interests). These multidimensional cluster comparisons are performed to estimate the a-priori probability of a given transaction.

Further characteristics may be populated for the fraud detection unit including mining for online consumer complaints on transactions and merchants, mining location and update time information from web posts and social media sites, and analyzing mobile user flagged transactions. This type of information is analyzed and adapted to the database to provide better analysis and notifications without involving third parties and direct user interaction requiring responses.

The database also takes into consideration authentication history. This includes the number of failed authentications for a particular device. The device may be for a merchant or a customer. Each time a device tries to authenticate with a device for a transaction, the database is updated to with another entry of data to populate. In this fashion, the authentication success rate may be utilized as an indicator of whether a particular device is suspicious of illegitimate conduct based on the number of failed authentication attempts and secondly how contemporaneously the failed authentication occurred.

An example of the system implementation can be seen in FIG. 7. The user authenticates with the system implicitly (701), at which point the fraud detection unit retrieves any relevant and related user specific information related to the specific merchant. Said information may be flagged within the system, or as mentioned previously, information may include consumer complaints in forums and social media sites(702), for example. This information is analyzed to verify whether the information in aggregate meets a pre-determined threshold to alter behavior or require a notification to be sent to the user before the transaction, at the point of sale (703), or post-transaction.

In situations where the threshold is met, the transaction is flagged (704) and a third party may be involved for further verification (705). Said system provides a fraud detection system and fraud resolution management (post transaction) for consumers (706) or users of the system.

For example, if the transaction is at a coffee shop, the characteristics analyzed will be with respect to coffee shops or other merchants with coffee shop like characteristics. Therefore the analytics by the fraud detection unit are targeted to the specific transaction and allow for a more accurate notification given to the user.

In the embodiment of FIG. 6A, the user must enter the proper credentials before confirmation of whether a transaction is fraudulent is accepted. However, in other implementations the confirmation is accepted without the need for credentials.

Referring to FIG. 6B, shown is a messaging flow diagram for authentication of a transaction in the network communications system of FIG. 1 in a push system for a case when verification of fraudulence of a transaction shows no fraudulence. In this messaging flow a transaction is underway between a server at a transaction site and an authentication device. The authentication device sends a VERIFY message to a fraud reporting unit containing information regarding the transaction.

The information contained in the VERIFY message includes information suitable for identifying a fraudulent user. The fraud reporting unit verifies its database to determine whether the received information matches any entry in the database that would confirm that the transaction is potentially fraudulent. The fraud reporting unit replies to the authentication device with a REPLY message indicating whether the transaction is potentially fraudulent or not. The authentication device verifies whether the message indicates a potentially fraudulent transaction or not, and in this case the transaction is not fraudulent.

The authentication device sends a VERIFICATION message to a user device associated with the transaction indicating that a transaction is underway and that the transaction does not appear to be fraudulent. Nonetheless, the VERIFICATION message is used for requesting user credentials and confirmation of whether the transaction is indeed fraudulent or not.

The user provides input of the credentials and in this case the user confirms that the transaction is not fraudulent by sending a REPLY message to the authentication device. The REPLY message contains information confirming that the transaction is not fraudulent together with the user credentials. The authentication device verifies that the user credentials are correct and determines that the transaction is not fraudulent based on the information contained in the REPLY message. During verification the authentication unit determines that the transaction is not fraudulent and the transaction process continues.

In FIG. 6A and FIG. 6B, in some instances the transaction is being performed in real-time and the transaction cannot continue unless the user confirms that the transaction is not fraudulent. In other instances, the transaction is being initiated by a third party such as a merchant entering credit card information for a related purchase for example, and the transaction is put on hold until the user has had a chance to confirm whether the transaction is fraudulent or not. In some implementations, when a transaction has been identified as having no potential threat of fraudulence by the fraud reporting unit the transaction continues without any further verification with the user at the user device.

In FIG. 6A and FIG. 6B, in some implementations if the user credentials are incorrect, the user is asked to re-enter the credentials until the correct credentials are entered or until a maximum number of attempts is reached. When the maximum number of attempts is reached the authentication device contacts a third party to establish a call with the user's user call device.

The third party may be any third party required to verify the identity of the user conducting the transaction. In some embodiments, the third party is a call agent. The third party may be any party required from merchants, banks, consumers, and others in the ecosystem required to identify the user.

The messaging between the user device and the authentication device can be implemented using any suitable protocol. This may include mobile platform such as those used in Apple® iOS, Google® Android, BlackBerry®, Microsoft Windows Phone 8®, and other smartphones. Alternatively, with reference to FIG. 5, in some embodiments, the fraud confirming unit, the transaction authentication information unit, and the graphical user interface can be can be used to present the user with a request for confirmation of whether a transaction is fraudulent by presenting the user with an interface for entering the credentials and also with selectable buttons for confirming whether or not the transaction is fraudulent.

A number of mechanisms used for performing authentication have been described. In some embodiments, these mechanisms are used together to provide secure transactions. For example, in some embodiments, a transaction associated with a user is initiated at a server at a transaction site.

In some embodiments, a first authentication step is conducted based on a correlation between the location of the server and the location of a user device associated with the user. If the authentication succeeds then there is no need for verification with the user through the user device. However, if the authentication fails then verification is made via a push notification, a phone call, or 2-way SMS, for example, requesting user input at the user device.

If further verification is required, authentication is also made using other characteristics such as speed, acceleration, and key login in speed for example. Furthermore, communications are made with a detection unit so that it can retrieve information from the database to identify whether the transaction is potentially fraudulent.

After the above verifications, if it is deemed that the user needs to be informed, a verification message is sent to a user device associated with the user, where the user is prompted to enter user credentials and validate the transaction, reject/decline the transaction, and/or flag the transaction as fraudulent or non-fraudulent. If the transaction is flagged fraudulent, an entry is made into the database of the appropriate fraud prevention system. As mentioned previously, in some embodiments, this flagged information is verified by analyzing social media analytics such as web forums, posts, social media sites, and other private/public databases to determine reliability.

As discussed above, the database in the fraud prevention system is used to look at historical transactions of all users to check for potential fraud, and then appropriate users are notified/alerted of potential fraudulent transactions on their account, via rich push notifications, email, phone, or SMS for example.

An example of the implementation of the fraud detection system and resolution management system can be seen in FIG. 8. In this example, a third party payment gateway is integrated with the system to enable credit processing. In some embodiments, the payment gateway may be part of the fraud verification and resolution management system.

The user logins in (1) to the system (payment gateway) using a mobile device as their device (1a) and registers with the system server (Fraud Detection Unit). The user sets their preferences regarding notifications and financial security with the system server (2).

These settings are passed on to the payment gateway authentication database of the payment gateway (3).

If a transaction is flagged by the payment gateway, a notification is sent to the Fraud Detection Unit utilizing an application programming interface (4). In some embodiments, the flag is stored on the payment gateway database (4a) prior to the flag being pushed to the fraud detection unit (4b).

The fraud detection unit, receiving the flag from the payment gateway, pushes the flag to the user via rich push notifications (5). The user device receives the notification (6) and the transaction information is downloaded or viewed on the user device (7).

The user may input a secondary password to authenticate (8), and the corresponding user selected action (e.g., allow/prevent/flag) is pushed to the fraud detection unit. This response is sent from the Fraud Detection Unit to the payment gateway (10a) and recorded in the database within the payment gateway (10b).

Providing Alerts

In some embodiments, a rich push notification may be sent to a user device after checking database information for various transaction information related to one or more devices. Rich push notifications include, but not limited to, an email, an SMS, instant message, VOIP call, or a phone call (automated or conventional), and other medium of electronic messaging.

For example, these alerts may be used to alert a first user device of a suspicious second user device when a first user device enters the proximity of the second user device. This may include a customer walking into a merchant's store where the customer receives an instant message on their mobile device informing the customer that the current merchant store has a transaction history including a high rate of invalid authentication.

In another example, a merchant may be alerted of a potential customer having a high level of invalid authentication with respect to a specific credit card.

In some embodiments, the alert is proximity based by a pre-determined threshold when the first user device meets the threshold relative to a second user device.

In some embodiments, the alert is given once the transaction history in the database reaches a pre-determined threshold. For example, if the number of invalid authentications for a merchant device totals 10 per month, an alert is sent to a number of user devices on the system which frequently conduct transactions at the company, utilizing the merchant device.

It is obvious that the foregoing embodiments of the invention are examples and can be varied in many ways. Such present or future variations are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.

Claims

1. A method of authenticating a transaction, the method comprising:

responsive to receiving a request for authenticating a transaction involving a first device and including first device information defining at least one first device characteristic of the first device,

obtaining second device information defining at least one second device characteristic of a second device associated with the transaction;

determining a level of correlation between the first device information and the second device information; and

authenticating the transaction based on the level of correlation between the first device information and the second device information, wherein the transaction is authenticated when the level of correlation between the first device information and the second device information is above a pre-determined threshold.

2. A method according to claim 1 wherein, determining a level of correlation between the first device information and the second device information comprises:

obtaining a dynamic weighting factor corresponding to each the at least first device characteristic and the at least one second device characteristic;

applying the dynamic weighting factor to the first device information and the second device information; and

generating a sum correlation total, where the sum correction total comprises the calculation of dynamic weighting factors to each of the first device information and the second device information.

3. A method according to claim 1 wherein, the first device and the second device are the same device.

4. A method according to claim 1 wherein, the method further comprises establishing a call between a third party and an entity in response to a determination that the level of correlation between the first device information and the second device information is below a pre-determined threshold for authentication, the entity being associated with at least one of the first device and the second device.

5. A method according to claim 4 wherein, the request comprises a phone number of the entity, the call between the third party and the entity being established using the phone number.

6. A method according to claim 1 wherein, the method further comprises obtaining further user specific characteristics in response to a determination that the level of correlation between the first device information and the second device information is below a threshold for authentication.

7. An authentication device comprising:

a communications interface for receiving requests for authenticating transactions involving a first device, each request comprising a first device and including first device information defining at least one first device characteristic of the first device, and obtaining second device information defining at least one second device characteristic of a second device associated with the transaction;

an authentication system having a first authentication unit for, for each request:

means for obtaining second device information defining at least one second device characteristic of a second device;

means for determining a level of correlation between the first device information and the second device information; and,

means for authenticating the transaction based on the level of correlation between the first device information and the second device information, wherein the transaction is authenticated when the level of correlation between the first device information and the second device information is above a pre-determined threshold.

8. A device according to claim 7 wherein, determining a level of correlation between the first device information and the second device information comprises:

obtaining a dynamic weighting factor corresponding to each the at least first device characteristic and the at least one second device characteristic;

applying the dynamic weighting factor to the first device information and the second device information; and

generating a sum correlation total, where the sum correction total comprises the calculation of dynamic weighting factors to each of the first device information and the second device information.

9. A device according to claim 7 wherein, the authentication device further comprises a call activation unit for establishing a call between a third party and an entity in response to a determination that the level of correlation between the first device information and the second device information is below a pre-determined threshold for authentication, the entity being associated with at least one of the first device and the second device.

10. A device according to claim 9 wherein, the request comprises a phone number of the entity, the call between the third party and the entity being established using the phone number.

11. A device according to claim 7 wherein, the device is further configured to obtain further user specific characteristics in response to a determination that the level of correlation between the first device information and the second device information is below a threshold for authentication.

12-23. (canceled)