Patent Application
20180025356
The present invention relates to a computer device for monitoring for fraudulent activity.
The complete payment industry is transforming from analog to digital. As a result of this process, payment cards (such as credit cards, debit cards and prepaid cards) are being digitized and stored on mobile devices.
Mobile devices typically includes a number of user authentication procedures employed when accessing services (such as digital wallets, websites, networks, applications, etc) and devices (such as smartphones, computers, etc.). Commonly deployed authentication methods include:
Each of the above-mentioned authentication procedures has its relative strengths and weaknesses for security, reliability and/or implementation.
The above authentication procedures provide a basic means of authenticating procedures. However, these techniques may not provide the means to monitor multiple sources of information to determine a risk level (also referred to as a confidence level) associated with a current authentication procedure. For example, the above authentication procedures may not necessarily take into account that the present situation in which an authentication request has been made has a heightened risk level as a result of circumstances extraneous to the transaction itself. As such, current authentication techniques may allow the user to use an authentication procedure that has a lower inherent security level.
Security flaws in mobile products can lead:
It is generally desirable to reduce or mitigate fraud in financial transactions and to enhance user experience.
It is generally desirable to assess a risk level associated with an authentication procedure before proceeding with the authentication procedure.
It is generally desirable to overcome or ameliorate one or more of the above described difficulties, or to at least provide a useful alternative.
In accordance with the invention, there is also provided, a computer device for monitoring for fraudulent activity, including:
Preferably, the step of monitoring connected devices includes the steps of determining if a separate device is in communication with the computer device, then decrementing the confidence level if there is a reduction of the quality of the signals received from the separate device.
Preferably, the step of monitoring user behaviour includes the step of decrementing the confidence level if the user is not following normal behaviour patterns.
In accordance with the invention, there is also provided a method for monitoring for fraudulent activity on a computer device, including:
Preferably, the step of monitoring connected devices includes the steps of determining if a separate device is in communication with the computer device, then decrementing the confidence level if there is a reduction of the quality of the signals received from the separate device.
In accordance with the invention there is also provided a computer device for effecting an authentication procedure associated with a computer device for effecting an authentication procedure associated with a service provider or an application, including:
Preferably, each authentication procedure on the device has an associated confidence level.
Preferably, the step of determining the confidence level includes the steps of:
Preferably, if the authentication procedure relates to an in App purchase, then the step of determining the confidence level includes the steps of determining if the procedure is being effected from secure location and, if so, incrementing the confidence level.
Preferably, if the authentication procedure relates to an in Store purchase, then the step of determining the confidence level includes the steps of incrementing the confidence level if the procedure relates to a repeat purchase.
Preferably, the step of determining the confidence level is determined based on device security level. Alternatively, the step of determining the confidence level is determined based on user behaviour.
In accordance with the invention, there is also provided a method for effecting an authentication procedure associated with a service provider or an application, including the steps of:
Preferably, each authentication procedure on the device has an associated confidence level.
Preferably, the step of determining the confidence level includes the steps of:
Preferably, if the authentication procedure relates to an in App purchase, then the step of determining the confidence level includes the steps of determining if the procedure is being effected from secure location and, if so, incrementing the confidence level.
Preferably, if the authentication procedure relates to an in Store purchase, then the step of determining the confidence level includes the steps of incrementing the confidence level if the procedure relates to a repeat purchase.
Preferably, the step of determining the confidence level is determined based on device security level. Alternatively, the step of determining the confidence level is determined based on user behaviour.
Advantageously, the above-described method cause the computer device to select an authentication procedure that matches the current confidence level of the transaction.
Preferred embodiments of the invention are hereafter described, by way of non-limiting example only, with reference to the accompanying drawings, in which:
As shown, the device 10 includes the following components in electronic communication via a bus 100:
Although the components depicted in
The display 102 generally operates to provide a presentation of content to a user, and may be realized by any of a variety of displays (e.g., CRT, LCD, HDMI, micro-projector and OLED displays). In general, the non-volatile data storage 104 (also referred to as non-volatile memory) functions to store (e.g., persistently store) data and executable code including code that is associated with the functional components of an Authentication Application 116 that executes the processes 200 set out in
In some embodiments for example, the non-volatile memory 104 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation of one or more portions of the Authentication Application 116 and the Fraud Engine 118 as well as other components, well known to those of ordinary skill in the art, that are not depicted nor described for simplicity.
In many implementations, the non-volatile memory 104 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from the non-volatile memory 104, the executable code in the non-volatile memory 104 is typically loaded into RAM 108 and executed by one or more of the N processing components 110.
The N processing components 110 in connection with RAM 108 generally operate to execute the instructions stored in non-volatile memory 104. As one of ordinarily skill in the art will appreciate, the N processing components 110 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components.
The transceiver component 112 includes N transceiver chains, which may be used for communicating with external devices via wireless networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme. For example, each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS networks), and other types of communication networks.
It should be recognized that
The device 10 also includes one or more of the sensors 120 in electronic communication with the CPU 110 via a bus 100. In the example shown, the device 10 includes the following:
Although not shown in
An exemplary embodiment of the device 10 is shown in
With reference to
As will be described below in further detail, the step, 202, of determining the Confidence Level includes the steps of:
The confidence level represents a relative risk of fraudulent activity.
If the authentication was successful, at step 208, then the process 200 includes the step 210 of recording data on the successful authentication.
Further, the process 200 includes a check, at step 212, to see if there are any separate devices connected to the mobile device 10. Such devices may include:
Alternatively, the other device may be any other device connected to the mobile device 10 at that time.
If connection to a separate device is detected, at step 212, then the following processing steps are performed:
The device 10 includes the following authentication processes:
Individually, each of the above authentications processes is known in the art and specific operations are not described here in further detail. Of course, it is envisaged that the invention can be used with any other suitable authentication process that can be used with the mobile device 10.
Each authentication process used by the mobile device 10 includes an associated Confidence Level.
The Confidence Level is measured as a number, or a non-numerical value selectable from an ordered set of elements (such as {“low”, “medium”, “high”}), associated with the authentication procedure being effected. The Confidence Level may be a floating point number (positive, non-negative, non-positive or negative) or a counter. For example, the Confidence Level may be a probability.
As shown in
The Fraud Engine 118 can be part of:
The processes executed by the Fraud Engine 118 are described below in further detail.
The Engine 118 waits, at 402, for an authentication request. If an authentication request is received, at 402, then the Engine 118, at step 404, rests the Confidence Level to zero or other null value.
The Engine 118 then checks, at 406, to see if the “device connected” flag has been set. As will be described in further detail below, this flag is set where:
The separate device can be:
Alternatively, the separate device may be any other device connected to the mobile device 10 at that time.
The additional devices can provide additional authentication ways and can help with Confidence Level.
In the event that the flag has been set, then the Engine 118 checks, at 408, to see if the device currently connected to the mobile device 10 is the same as the one that set the flag. If so, then the Engine 118 checks, at step 410, the quality of the connection. If the quality of the connection is good, then the Engine 118 returns, at step 412, a value of Confidence Level=“High”. For example:
If a user is wearing a watch or a wrist band connected to the device whilst performing an In-App or e-commerce purchase, then the user is authenticated continually until the user disconnects the device. The confidence level in these transactions is high.
If a user is wearing a heartrate monitor connected to the device whilst performing an In-App or e-commerce purchase, then the user is authenticated continually until the user disconnects the device. The confidence level in these transactions is high.
If the user is wearing virtual reality head gear whilst performing an In-App or e-commerce purchase, then the user is authenticated continually until the user disconnects the device. The confidence level in these transactions is high.
If the quality of the connection is not good, then the Fraud Engine 118, at step 414, decrements the Confidence Level and continues its processing steps. Typically, devices are connected by Bluetooth™ low energy. A Bluetooth™ low energy connection loss or lower received signal strength indication (RSSI) can indicate the possible loss or misuse of the device 10.
Otherwise, if the device currently connected to the mobile device 10 is not the same as the one that set the flag, then the Fraud Engine 118 resets, at step 416, the “wearable device flag” to a zero or null value.
If the Fraud Engine 118 deems, at 418, that the authentication procedure is not associated with a purchase, then the Fraud Engine 118 returns, at step 420, the value of the Confidence Level.
Otherwise, if the Fraud Engine 118 deems, at 418, that the authentication is associated with a purchase, then the Fraud Engine 118 executes the steps 422 shown in
In-App or e-Commerce Purchase?
If the Fraud Engine 118 determines, at step 500, that the authentication is associated with an in-App purchase, then the Fraud Engine 118 generates, at step 502, the current location of the device 10 and determines, 504, if the current location falls within a set of secure locations. If so, then the Fraud Engine 118 increments, at step 506, the Confidence Level. For example, safe locations include:
The mobile device 10 has the capability to determine its current location using:
If the Fraud Engine 118 determines, at step 508, that the user has previously made a successful purchase with the same merchant, then the Fraud Engine 118 increments, at step 510, the Confidence Level. Further, the Fraud Engine 118 checks, at 512, to determine if the repeat purchase was recently made. If so, then the Fraud Engine 118 increments, at step 514, the Confidence Level.
A set of successful purchases/authentications is developed over time by recording details of each successful transaction, including:
The Fraud Engine 118 checks, at step 516, to see if the site where the purchase is being made is suspicious. If found to be suspicious, then the Fraud Engine 118 decrements, at step 518, the Confidence Level.
If the Fraud Engine 118 determined, at step 500, that the purchase was not an in-App purchase, and the Fraud Engine 118 determines, at 520, that the purchase is an in-store purchase, then the Fraud Engine, at step 522, generates the current location of the device 10. If the Fraud Engine 118 determines, at step 524, that the user has previously made a successful purchase with the same merchant, then the Fraud Engine 118 increments, at step 526, the Confidence Level counter. Further, the Fraud Engine 118 checks, at 528, to determine if the repeat purchase was recently made. For example, if the purchase was made with in the last 10 minutes. If so, then the Fraud Engine increments, at step 530, the Confidence Level.
As above-mentioned, a set of successful purchases/authentications is developed over time by recording details of each successful transaction, including:
The Fraud Engine 118 checks, at step 532, to see if the purchase is high value. For example, if the purchase price is greater than $1000. If so, then the Fraud Engine 118 decrements, at step 534, the Confidence Level.
The Fraud Engine 118 checks, at step 536, to see if the country where the purchase is being made is new. If so, then the Fraud Engine 118 decrements, at step 538, the Confidence Level.
Different configurations on the mobile device 10 exist (Device Identification), including:
User behavior can also be tracked, such as:
All such data can help in determining the ODCVM priority, Confidence Level and access type.
As shown in
The Fraud Engine 118 determines, at step 704, how secure the Mobile Payment Application is. If so the MPA is secure, then the Fraud Engine 118 increments, at step 706, the Confidence Level.
The Fraud Engine 118 determines, at step 708, the number “A” of authentication methods that are available on the device 10. If “A” is greater than a predetermined number “P”, such as 6, then the Fraud Engine 118 increments, at step 710, the Confidence Level.
The Fraud Engine 118 also keeps track of the last device unlock status and the authentication method used. If the last authentication method used had an associated low Confidence Level, at step 712, then the Fraud Engine 118 decrements, at step 714, the Confidence Level.
Advantageously, the Fraud Engine 118 also monitors, at step 716, other user behaviour to assist in determining Confidence Level. For example, the Fraud Engine 118 determines whether the user is not following the normal behavior of access email/calls/messaging or other APP usage. In such circumstances, the Confidence Level is decremented, at step 718. Similarly, the Fraud Engine 118 determines, at step 720, whether the user is performing unusual touch on the screens or invalid activities on the screen (for example, Mobile device kept in pocket or a child using the Mobile device). If unusual activity is determined, then the Confidence Level is decremented, at step 722.
The Fraud Engine 118 is able to use the benefit of past authentication challenges to influence the Confidence Level. For example, while taking fingerprint, due to dirt or moisture, the prints are not clear. The matching score would be low or no sufficient matching points will be available. Possible output scenario:
In case the outcome is indecisive (result (d)), the Fraud Engine 118 might set the Confidence Level to “Low”.
In view of the above, the Fraud Engine 118 executes the process 426 shown in
The Fraud Engine 118 checks, at step 902, to see if Fingerprint authentication had previously been used. If used, then the Fraud Engine checks, at step 904, to see if it was used successfully and, if so, then the Fraud Engine 118 decrements, at step 906, the Confidence Level.
The Fraud Engine 118 checks, at step 908, to see if Facial authentication had previously been used. If used, then the Fraud Engine checks, at step 910, to see if it was used successfully and, if so, then the Fraud Engine 118 decrements, at step 912, the Confidence Level.
The Fraud Engine 118 checks, at step 914, to see if Voice authentication had previously been used. If used, then the Fraud Engine 118 checks, at step 916, to see if it was used successfully and, if so, then the Fraud Engine 118 decrements, at step 918, the Confidence Level.
The Fraud Engine 118 checks, at step 920, to see if Iris authentication had previously been used. If used, then the Fraud Engine checks, at step 922, to see if it was used successfully and, if so, then the Fraud Engine 118 decrements, at step 924, the Confidence Level.
The Fraud Engine 118 checks, at step 926, to see if Vein authentication had previously been used. If used, then the Fraud Engine checks, at step 928, to see if it was used successfully and, if so, then the Fraud Engine 118 decrements, at step 930, the Confidence Level.
The Confidence Level generated by the Fraud Engine 118 can be fed into a network as additional data along with the transaction details. Low Confidence Level data can help a network to either decline the transaction or to send a request for additional authentication from the user.
Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention.
The reference to any prior art in this specification is not, and should not be taken as, an acknowledgment or any form of suggestion that the prior art forms part of the common general knowledge.
In this specification and the claims that follow, unless stated otherwise, the word “comprise” and its variations, such as “comprises” and “comprising”, imply the inclusion of a stated integer, step, or group of integers or steps, but not the exclusion of any other integer or step or group of integers or steps.
References in this specification to any prior publication, information derived from any said prior publication, or any known matter are not and should not be taken as an acknowledgement, admission or suggestion that said prior publication, or any information derived from this prior publication or known matter forms part of the common general knowledge in the field of endeavour to which the specification relates.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10201606033Y | Jul 2016 | SG | national |
