Method and system to improve risk assessments in fraud detection systems using machine identifiers

A computing system obtains data for a transaction pertaining to access to an application. The transaction data includes a machine identifier of a machine that is associated with the transaction. The computing system determines a percentile that is assigned to the machine identifier of the transaction based on cross-user transaction data for a plurality of transactions associated with a plurality of users. The percentile represents a number of machine identifiers from the cross-user transaction data that satisfy a count threshold that is associated with the machine identifier. The computing system modifies a user-level risk evaluation of the transaction based on the percentile assigned to the machine identifier and determines whether to intervene in the transaction based on the modified risk evaluation.

TECHNICAL FIELD

Embodiments of the present invention relate to fraud detection. Specifically, the embodiments of the present invention relate to improving risk assessments in fraud detection systems using machine identifiers

BACKGROUND

Identity theft and on-line fraud have become widespread problems in the United States. Each year, many adults in the U.S. have their identities stolen and numerous accounts are compromised, leading to significant losses as a result of identity theft. Weak authentication has led to Internet identity theft, phishing, and on-line financial fraud. As more consumers use computers and mobile devices for shopping, managing their finances, and accessing health care information, the risk of fraud and identity theft increases. Because of the impact of identity theft and on-line fraud on on-line businesses, more and more enterprises are evaluating authentication and security options for their on-line consumer base. The Federal Financial Institutions Examination Council (FFIEC) Guidance of 2005, which was updated in 2011, requires online financial institutions to apply strong authentication. Many fraud detection systems use a rules engine and a behavioral engine to assess the level of risk associated with an online transaction. Typical fraud detection systems analyze transactions at a user-level in that a behavioral engine learns how a consumer uses the system to dynamically identify risk. The fraud detection system responds when consumer behavior changes, even if the change does not break a general rule. For example, a behavioral engine goes on alert when a consumer who always logs on from home suddenly logs in from another country.

On average, 5% of a consumer's activity is unusual, but legitimate behavior, resulting in a high volume of transactions being falsely flagged as suspicious transactions in fraud detection systems. The level of the false positive rate is a large concern to enterprises using such fraud detection systems because a high level of false alerts can lead to enterprises unnecessarily investigating or intervening in a large number of transactions. Unwarranted investigations and interventions are costly for an enterprise. In addition, a high level of false alerts can detract from the true risky transactions. Traditionally, fraud detection systems have reduced the number of false positives by raising the risk threshold, such that transactions with lower risk scores would not be intervened or investigated. Such conventional solutions, however, miss the detection of real fraud transactions.

SUMMARY

In one embodiment, a system for improving a risk assessment for a transaction using percentiles assigned to machine identifiers is described. An exemplary system may include a memory and a processing device that is coupled to the memory. In one embodiment, the system obtains data for a transaction pertaining to access to an application. The transaction data includes a machine identifier of a machine associated with the transaction. The system determines a percentile that is assigned to the machine identifier of the transaction based on cross-user transaction data for transactions across multiple users. The percentile represents a number of machine identifiers from the cross-user transaction data that satisfy a count threshold that is associated with the machine identifier. The system modifies a user-level risk evaluation of the transaction based on the percentile assigned to the machine identifier and determines whether to intervene in the transaction based on the modified risk evaluation.

In one embodiment, the count threshold is a number of transactions per machine identifier or a number of distinct users per machine identifier. In some embodiments of the exemplary system, the system generates the user-level risk score for the transaction based on user behavior data and modifies the user-level risk score based on the assigned percentile. In one embodiment, the system modifies the user-level risk score by determining that the assigned percentile satisfies a percentile threshold, and decreases or increases the user-level risk score.

In one embodiment, the system further collects the cross-user transaction data for transactions across multiple users, wherein the transaction data includes a machine identifier and a user for each transaction, determines a number of transactions for each machine identifier using the transaction data and/or a number of distinct users for each machine identifier using the transaction data, creates a distribution of the machine identifiers based on the number of transactions for each machine identifier and/or the number of distinct users for each machine identifier, assigns a percentile to each machine identifier based on the distribution, and stores the percentile assignments of the machine identifiers in a data store that is coupled to the computing system. In one embodiment, the system determines a percentile that is assigned to the machine identifier of the transaction by searching the percentile assignments in the data store for a machine identifier that matches the machine identifier of the transaction.

In addition, a non-transitory computer readable storage medium for improving a risk assessment for a transaction using percentiles assigned to machine identifiers is described. An exemplary non-transitory computer readable storage medium includes instructions that will cause a processor to obtain data for a transaction pertaining to access to an application, determine a percentile that is assigned to a machine identifier of the transaction based on cross-user transaction data for transaction across multiple users, modify a user-level risk evaluation of the transaction based on the percentile assigned to the machine identifier, and determine whether to intervene in the transaction based on the modified risk evaluation.

Further, a method for improving a risk assessment for a transaction using percentiles assigned to machine identifiers is described. In one embodiment, a method comprises obtaining data for a transaction pertaining to access to an application, determining a percentile that is assigned to a machine identifier of the transaction based on cross-user transaction data for transaction across multiple users, modifying a user-level risk evaluation of the transaction based on the percentile assigned to the machine identifier, and determining whether to intervene in the transaction based on the modified risk evaluation.

DETAILED DESCRIPTION

Embodiments of the invention are directed to a method and system for improving risk assessments of transactions using machine identifiers. A computing system obtains data for a transaction pertaining to access to an application. The transaction data includes a machine identifier of a machine associated with the transaction. The computing system determines a percentile that is assigned to the machine identifier of the transaction based on cross-user transaction data for transactions across multiple users. The percentile represents a number of machine identifiers from the cross-user transaction data that satisfy a count threshold that is associated with the machine identifier. The computing system modifies a user-level risk evaluation of the transaction based on the percentile that is assigned to the machine identifier and determines whether to intervene in the transaction based on the modified risk evaluation.

Embodiments of the present invention can reduce the number of transactions being falsely flagged as suspicious transactions in fraud detection systems and can help enterprises avoid costs related to investigating and intervening in the flagged transactions. Embodiments of the present invention can speed up the time taken to perform risk analyses of transactions by quickly identifying whether a machine identifier for a transaction is a frequently used or rarely used machine identifier as compared to other machine identifiers that have been monitored by the fraud detection system. Embodiments of the present invention can improve a risk analysis by using dynamic data, such as a periodic sample of most current cross-user transaction data.

FIG. 1is an exemplary network architecture100in which embodiments of the present invention can be implemented. The network architecture100can include an enterprise environment160including one or more application servers180communicating with one or more fraud detections servers190and one or more clients130via a network120. The network120can be a local area network (LAN), a wireless network, a mobile communications network, a wide area network (WAN), such as the Internet, or similar communication system.

The enterprise environment160can include one or more application servers180to host applications163. An application163can be any type of application including, for example, a web application, a desktop application, a database management application, etc. A server180can be hosted by any type of computing device including server computers, gateway computers, desktop computers, laptop computers, hand-held computers or similar computing device. A client130can host a web browser140, or similar application, to access an application163. A client130can be hosted by any type of computing device including server computers, gateway computers, desktop computers, laptop computers, mobile communications devices, cell phones, smart phones, hand-held computers, or similar computing device.

A fraud detection server190can provide a real-time, fraud detection and monitoring service of applications163. The fraud detection service can be a risk-based user and transaction monitoring service. In one embodiment, the service can be implemented as a cloud101to provide solutions to enterprises using cloud computing such as software as a service (SaaS) model in which software and services can be distributed on a subscription basis. The cloud101can include one or more fraud detection servers190to implement the SaaS model. A server190can be hosted by any type of computing device including server computers, gateway computers, desktop computers, laptop computers, hand-held computers or similar computing device. In another embodiment, the enterprise environment160can include one or more fraud detection servers190.

A website user103may initiate a transaction using an application163website being monitored by a fraud detection server190. Examples of types of transactions can include, and are not limited to, a log in, a purchase transaction using a credit card, an ATM transaction, a stock trade, electronic money movement, wire transfer, etc. The website user103can enter transaction data via the website, such as login credentials and/or credit card credentials, which the application server180can provide to the fraud detection server190. The transaction data can include additional client, browser, operating system, and machine information. The fraud detection server190can perform a fraud analysis at the user-level by learning how the website user103accesses the application163website to dynamically identify risk. The fraud detection server190can generate a risk score using the transaction data to determine at the user-level whether the transaction is within the realm of what is considered “usual and customary” for this particular user103. For example, if a user103living in Wisconsin travels infrequently, a transaction initiated from Utah can affect the risk score assigned to the transaction at the user-level. In another example, if a user103makes the majority of their purchases at retail online store sites, a transaction from an adult video site can also affect the transaction risk score at the user-level. The fraud detection server190can use the risk score assigned to the transaction at the user-level to categorize a transaction, for example, as low risk, medium risk, or high risk.

The fraud detection server190can include a risk analyzer161to dynamically improve the user-level risk assessment of a transaction being evaluated by analyzing risk of the transaction at an enterprise-level. An “enterprise-level” risk analysis includes the risk analyzer161using cross-user transaction data, which is the transaction data for multiple users being monitored by the fraud detection server190. The risk analyzer161can modify the risk score that was generated at the user-level by analyzing the particular transaction relative to the cross-user transaction data at the enterprise-level. For example, the risk analyzer161can determine a machine identifier of a machine related to the transaction, such as a machine initiating the transaction, and determine whether the machine identifier is a frequently used machine identifier compared to the other machine identifiers being tracked by the fraud detection server190. An example of a machine identifier can include, and is not limited to, an Internet Protocol (IP) address. The risk analyzer161can further refine the risk score created at the user-level based on the enterprise-level analysis. For instance, the risk analyzer161can analyze an IP address of the client130that initiated a transaction at the enterprise-level and increase or decrease a risk score based on the enterprise-level analysis. The risk analyzer161may determine that the particular IP address is a frequently used IP address based on historical cross-user transaction data that is collected by the fraud detection server190and may reduce the risk score to indicate that the transaction is not a high risk. Decreasing risk scores can reduce false positives in the fraud detection service. In another example, the risk analyzer161can improve the risk assessment of a transaction by increasing a risk score of a transaction. The risk analyzer161may determine that a particular IP address is an infrequently used IP address based on historical cross-user transaction data and may increase a risk score to indicate that the transaction is a high risk.

The fraud detection server190can use a modified risk score to determine whether a transaction should complete or whether the fraud detection server190should intervene in the transaction, such as requesting further authentication from the user103. For instance, the fraud detection server190can send a challenge question or a response-required email to the user103. An incorrect response from the user103can cause the transaction to fail. The fraud detection server can create a case for a high risk transaction to be investigated and/or to be intervened. The fraud detection server can send an alert identifying a risky transaction to one or more users, such as an enterprise security administrator105and/or a website user103.

FIG. 2is a block diagram of one embodiment of a risk analyzer200for improving risk assessments of transactions using machine identifiers. The risk analyzer200may be the same as the risk analyzer161hosted by a fraud detection server190inFIG. 1. The risk analyzer200includes a percentile assigner210, a machine identifier213, and a risk modifier215. The components can be combined together or separated in further sub-components, according to a particular embodiment.

The risk analyzer200is coupled to a data store250that stores cross-user transaction data251. The fraud detection server continually collects data for transactions associated with a number of users being monitored by the fraud detection server. In one embodiment, the fraud detection server receives transaction data for a transaction from an application server and adds the transaction data to the cross-user transaction data251. In another embodiment, the fraud detection server receives the transaction data for a transaction from the machine initiating the transaction, such as a client computing machine, and adds the transaction data to the cross-user transaction data251. The transactions can include previous successful transactions associated with multiple users and previous transactions associated with multiple users that have failed. The transactions can include current transactions associated with multiple users.

The cross-user transaction data251can include, without limitation, information related to each user (e.g., user credentials), the operating system used for each transaction, the browser type (e.g., Internet Explorer, Firefox, Chrome, or the like) for each transaction, the browser version for each transaction, the machine identifier (e.g., IP address) associated with each transaction, the geographical location of the machine identifier, date, time, or the like. The operating system and browser properties are derivatives of the User-Agent and the geographical location and connection are derivatives of the machine identifier (e.g., IP address). Information extracted from the IP address can be categorized as geographical location (e.g., country, city, state, longitude, latitude, or the like) and connection information (e.g., carrier, second level domain (SLD), organization, routing type, connection type, or the like). User-Agent derivatives (e.g., operating system, browser, or the like) and machine identifier (e.g., IP) derivatives (e.g., location, connection) can also be included. For money transfer transactions, information for the transaction can include, without limitation, the amount, the destination institution name, the destination institution country, and the transfer category.

In one embodiment, the percentile assigner210can periodically take a sample of the cross-user transaction data251and analyze the sample of the cross-user transaction data251to generate and/or update percentile assignment data253. In one embodiment, the percentile assigner210can periodically analyze all of the cross-user transaction data251to generate and/or update percentile assignment data253. The percentile assignment data253can be stored in the data store250. One embodiment of generating and/or updating percentile assignment data253is described in greater detail below in conjunction withFIG. 6. The percentile assignment data253can include percentiles that are assigned to machine identifiers, such as IP addresses, that are associated with the transactions across multiple users. The percentile assigner210can determine a count for all of the machine identifiers in the cross-user transaction data251and assign a percentile rank to the machine identifiers by arranging the counts, for example, from lowest to highest. One embodiment of determining a percentile is described in greater detail below in conjunction withFIG. 6. In one embodiment, the count used to assign a percentile to the machine identifiers is a number of transactions per machine identifier. In another embodiment, the count is a number of distinct users per machine identifier. The percentiles that are assigned to the machine identifiers represent a percentile rank, which can be, in one embodiment, a number between 0 and 100 indicating a number of machine identifiers based on the cross-user transaction data251that satisfy a count threshold, such as have a count that is equal to or less than the count threshold. The count threshold can be specific to each machine identifier. The count threshold can be the count for the particular machine identifier. For example, the cross-user transaction data251includes data for 150 IP addresses. The percentile assigner210determines a count of a number of transactions per IP address for each of the 150 IP addresses within the system based on the cross-user transaction data251. One of the IP addresses, 217.35.123.8, may have a count of 87 transactions. The count threshold for the IP address 217.35.123.8 is 87. The percentile assigner210determines that 113 of the 150 IP addresses have a count that is equal or less than 87. The percentile assigner210may determine that the percentile rank for IP address 217.35.123.85 is 75%.

In one embodiment, the percentile assigner210does not assign a zero percentile rank and uses the lowest count as the first percentile. In one embodiment, the percentile assigner210does not assign a 100thpercentile rank and uses the highest count as the 99th percentile.

In one embodiment, the percentile assignment data253includes assignments for all of the machine identifiers that have been analyzed by the fraud detection system. For example, the percentile assignment data253includes assignments for machine identifiers from the first percentile to the 99thpercentile. In another embodiment, the percentile assigner210creates a copy of a subset of the percentile assignment data253and stores the subset in the data store250. For example, the subset may be the top percentile of the assignments. The top percentile can be a pre-defined and/or configurable range. The top percentile can be configured by a user, such as a system administrator. In one embodiment, the top percentile is configured as ninety-five percentile and above. In another example, the subset may be the bottom percentile of the assignments. The bottom percentile can be a pre-defined and/or configurable range. The bottom percentile can be configured by a user, such as a system administrator. In one embodiment, the bottom percentile is configured as five percentile and below.

In one embodiment, the fraud detection server includes a behavioral engine217that is coupled to the risk analyzer200and the data store250to perform a real-time risk assessment of transactions at a user-level as they occur. The behavioral engine217can monitor patterns of user behavior during on-line transactions and generate user behavior data259to reflect the patterns and a user-level analysis. For example, the behavioral engine217tracks characteristics of a user log-in from a location such as Mountain View, Calif., using the Firefox® browser and the Windows® operating system. For this transaction (a log-in transaction), several properties are associated with the transaction including the browser type, the operating system, and the like. The user behavior data259for patterns associated with financial transactions, such as a money transfer, can include a periodicity and a range of amount transferred. Using information related to the behavioral patterns in the user behavior data259, the behavioral engine217can construct a user pattern and identify anomalies in the behavior, which can suggest that a transaction is suspicious if it does not follow the typical behavioral pattern for a particular user.

The behavioral engine217can form a risk score at a user-level for a given transaction utilizing the user behavior data259and both business logic rules and behavioral analysis. In one embodiment, the behavioral engine217includes and/or is coupled to a rules-based engine (not shown). The data store250can store policies and rules255that are pre-defined and/or configurable, for example, by an enterprise. The behavioral engine217can analyze various aspects of the transaction at a user-level, triggering one or more rules that result in the generation of alerts. The risk analyzer200and behavioral engine217can be coupled to an intervention engine219that generates alerts. For example, rules that could result in alerts include identification of a high risk IP address or an IP address associated with a risky country. Based on an analysis at the user-level, if a user has a previous transaction from a first location and the location of the current transaction is so far from the first location, such that travel between the first and current location is impossible, then the intervention engine219can generate an alert based on violation of a travel time rule. The intervention engine219can generate alerts based on rules and other analytical techniques in response to a transaction. For example, the intervention engine219can generate alerts if a transaction is categorized as an anomaly, if the transaction is performed at a time that is not a regular activity time for the user, or the like. The intervention engine219generates a variety of different alerts in response to violation of rules or outputs from the behavioral analysis for a transaction.

The behavioral engine217can aggregate the alerts into intermediate alerts, and in turn, can aggregate the intermediate alerts to create a risk score for the transaction at the user-level.

The machine identifier213accesses the cross-user transaction data251for a current transaction and identifies a machine identifier, such as an IP address, associated with the transaction, such as for a machine initiating the transaction. The risk modifier215compares the machine identifier that is associated with the current transaction and compares it to the percentile assignment data253to determine a percentile that is assigned to the machine identifier of the transaction.

The risk modifier215can search the percentile assignment data253for a machine identifier that matches the machine identifier associated with the transaction. In one embodiment, if there is not a matching machine identifier in the percentile assignment data253, the risk modifier215assigns the first percentile to the machine identifier of the transaction. The risk modifier215modifies the current risk score (e.g., risk score generated at a user-level) for the transaction based on the assigned percentile from the analysis at the enterprise-level. For instance, the risk modifier215can increase or decrease the user-level risk score. The risk modifier215can apply one or more rules255that specify how to modify the user-level risk score using an assigned percentile. A rule can specify a percentile threshold and a corresponding risk score modification action for the risk modifier215to take. One embodiment for modifying a risk score based on an assigned percentile is described in greater detail below in conjunction withFIG. 4.

The intervention engine219that can determine whether the modified risk score satisfies a risk threshold to determine whether or not to intervene in the transaction. The risk threshold can be a pre-defined and/or a configurable value. The intervention engine219can intervene in the transaction, for example, by creating a case to investigate the transaction, sending a request for feedback to a user, etc. Examples of a request for feedback can include, and are not limited to, sending a challenge question, sending a response-required email, etc.

The intervention engine219can receive a feedback response from a user and determine whether the response is a valid response to allow the transaction to continue. The intervention engine219can use feedback data257that is stored in the data store250to determine whether the feedback response is valid to allow the transaction to continue. Feedback data257can include data used to validate the response, such as keys, algorithms, authorization codes, fingerprints, etc. An incorrect response from the user can cause the transaction to fail. The intervention engine219can send a message to the application server to allow the transaction to continue or to terminate the transaction.

The behavioral engine217can update the user behavior data259that is stored in the data store250based on the feedback response. A subsequent transaction using the same machine identifier may result in a lower risk score based on the updated user behavior data259.

A data store250can be a persistent storage unit. A persistent storage unit can be a local storage unit or a remote storage unit. Persistent storage units can be a magnetic storage unit, optical storage unit, solid state storage unit, electronic storage units (main memory), or similar storage unit. Persistent storage units can be a monolithic device or a distributed set of devices. A ‘set’, as used herein, refers to any positive whole number of items.

FIG. 3is a flow diagram of an embodiment of a method300for improving risk assessments of transactions by analyzing machine identifiers at the enterprise-level. Method300can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one embodiment, method300is performed by a risk analyzer161hosted by a fraud detection server190inFIG. 1. At block301, processing logic obtains transaction data for a particular transaction pertaining to access to an application. The transaction data can be received from an application server, and/or received from a machine initiating the transaction. The transaction data can include a machine identifier, such as an IP address, of the machine associated with the transaction. At block303, processing logic identifies a machine identifier associated with the transaction.

At block305, processing logic determines a percentile that is assigned to the machine identifier of the transaction based on an enterprise-level analysis. One embodiment of performing an enterprise-level analysis to assign percentiles to machine identifiers is described in greater detail below in conjunction withFIG. 6. Processing logic can search percentile assignment data that is stored in a data store that is coupled to the risk analyzer for a machine identifier that matches the machine identifier associated with the transaction. The percentile represents a number of machine identifiers that satisfy (e.g., have a count that is equal to or less than) a count threshold that is associated with the machine identifier. In one embodiment, the percentile is based on a number of transactions per machine identifier. In another embodiment, the percentile is based on a number of distinct users per machine identifier. For example, an IP address, 217.35.123.8, has a count of 87 transactions. The count threshold for this particular IP address is 87. The percentile assignment data includes a 75% rank that is assigned to the IP address 217.35.123.8. The 75% percentile rank represents the number of machine identifiers that have counts that are equal to or less than 87. Processing logic may search percentile assignment data and find a machine identifier that matches the machine identifier associated with the transaction. The matching machine identifier has a 75% percentile rank. In one embodiment, if there is not a matching machine identifier in the percentile assignment data, processing logic assigns a first percentile to the machine identifier of the transaction.

At block307, processing logic modifies a user-level risk evaluation of the transaction based on the assigned percentile. Processing logic may have previously generated a user-level risk score for the transaction from conducting a user-level analysis using user behavior data for the transaction. Processing logic can increase or decrease the user-level risk score. One embodiment of increasing or decreasing a user-level risk score is described in greater detail below in conjunction withFIG. 4.

At block309, processing logic determines whether to intervene in the transaction based on the modified risk evaluation. The percentile can be an indication of a risk of fraud that is associated with the machine identifier. Processing logic can improve the risk assessment by reducing the amount of time taken to perform risk analyses of transactions by quickly identifying whether a machine identifier for a transaction is a frequently used or rarely used machine identifier. For example, a machine identifier that is assigned a high percentile (e.g., 95%) can represent a frequently used machine identifier and indicate a low risk of fraud for the transaction for a specific website. Studies of website traffic have shown that 70% of a website's transactions originate from 5% of the IP addresses connecting to the website. A majority of a website's traffic falls within the IP addresses in the ninety-five percentile and above. A particular study analyzing online banking websites reveal the same results. Most of online banking logins result from frequently used IP addresses. The studies indicate that very few fraud attempts are generated from the top 5% of IP addresses that access a website.

In another example, a machine identifier that is assigned a low percentile (e.g., 5%) can represent a rarely used machine identifier and indicate a high risk of fraud for the transaction. Studies have shown that fraudsters would rarely connect to a website using IP addresses that frequently connect to the website. The studies reveal that IP addresses that scarcely access a website are riskier than IP addresses that frequently access a website. One embodiment of determining whether to intervene in the transaction is described in greater detail below in conjunction withFIG. 4.

FIG. 4is a flow diagram of an embodiment of a method400for improving a risk assessment for a transaction using percentiles assigned to machine identifiers from an enterprise-level analysis. Method400can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one embodiment, method400is performed by a risk analyzer161hosted by a fraud detection server190inFIG. 1.

At block401, processing logic identifies a machine identifier (e.g., IP address) from the transaction data for a transaction that is being analyzed and determines a percentile that is assigned to the machine identifier at block403. Processing logic can search percentile assignment data that is generated from an enterprise level analysis and stored in a data store that is coupled to the risk analyzer for a machine identifier that matches the machine identifier associated with the transaction. In one embodiment, processing logic searches a copy of a subset of the percentile assignment data that is stored in the data store. For example, the subset may be the top percentile of the assignments, such as a ninety-five percentile and above. One embodiment of assessing risk using a subset of percentile assignment data representing a top percentile is described in greater detail below in conjunction withFIG. 5. In another example, the subset may be the bottom percentile of the assignments, such as a five percentile and below. In another embodiment, processing logic searches all of the percentile assignments from the lowest to the highest percentile for a machine identifier that matches the machine identifier associated with the transaction. Processing logic can locate a matching machine identifier and identify the percentile that is assigned to the matching machine identifier. In one embodiment, if there is not a matching machine identifier in the percentile assignment data, processing logic assigns the first percentile to the machine identifier of the transaction.

At block405, processing logic modifies a user-level risk score based on the assigned percentile and policies and/or rules that are stored in the data store. A policy and/or rule can specify a percentile threshold and a corresponding risk score modification action to be taken. For example, a policy may specify that when an assigned percentile is in the top percentile (e.g., ninety-five percentile and above), processing logic can change the user-level risk score for the transaction to a zero risk score. A zero risk score can indicate that there is no risk associated with the transaction. In another example, a policy may specify that when an assigned percentile is in the top percentile, processing logic reduce the user-level risk score for the transaction by a pre-defined value and/or configurable value. In another example, a policy may specify that when an assigned percentile is in the bottom percentile (e.g., five percentile and below), processing logic increases the user-level risk score for the transaction by a pre-defined and/or configurable value.

At block407, processing logic determines whether the modified risk score satisfies a risk threshold to determine whether or not to intervene in the transaction. For example, on a risk scale of 0 to 100, a case creation or risk threshold can be set at 50. Processing logic can create a case and/or intervene in any transaction that has accumulated a risk score of 50.

If the determination is to not intervene in the transaction (block407), processing logic can allow the transaction to continue at block415. If the determination is to intervene in the transaction (block407), processing logic can intervene in the transaction by sending a request for feedback to a user at block409. For example, processing logic can send a request for a secondary authorization of the transaction to a website user, such as sending a challenge question or a response-required email. In another example of intervention, processing logic can generate an alert and send the alert to one or more users, such as an enterprise system administrator, a website user, etc., and processing logic can wait for a response to the alert from a user.

At block411, processing logic receives a feedback response from at least one user and determines whether the feedback response is valid to allow the transaction to continue at block413. For example, processing logic receives a challenge answer from a website user. In another example, processing logic receives second-factor authentication credentials (e.g., authorization code, pin, virtual token, physical token, one-time password, fingerprint, etc.) from a website user. Processing logic can use feedback data that is stored in the data store to determine whether the feedback response is valid to allow the transaction to continue. If the response is valid (block413), processing logic allows the transaction to continue at block415. In one embodiment, processing logic can send a message to the application server to allow the transaction to continue. If the response is not valid (block413), processing logic can cause the transaction to fail at block417. In one embodiment, processing logic can send a message to the application server to terminate the transaction.

At block419, processing logic updates the user behavior data that is stored in the data store based on the feedback response. The updates can indicate the risk analysis results and actions taken in response to this particular machine identifier. For example, processing logic determines that the IP address of the transaction does not have an assigned percentile that is ninety-five percentile or above and sends a request to a user for a virtual token. Processing logic successfully validates the virtual token, allows the transaction to continue, and updates the user behavior data to indicate that the transaction was allowed for this particular machine identifier. A subsequent transaction using the same machine identifier may result in a lower risk score based on the updated user behavior data.

FIG. 5is a flow diagram of an embodiment of a method500for assessing risk using a subset of percentile assignment data representing a top percentile. Method500can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one embodiment, method500is performed by a risk analyzer161hosted by a fraud detection server190inFIG. 1. In one embodiment, processing logic has previously generated percentile assignment data that assigns a percentile to machine identifiers associated with previous transactions. The percentile assignment data can be re-populated periodically or upon request to maintain up-to-date information. One embodiment of generating percentile assignment data is described in greater detail below in conjunction withFIG. 6. In one embodiment, processing logic has created a copy of a subset of the percentile assignments. The copy of the subset of percentile assignments can be re-populated periodically or upon request to maintain up-to-date information. In one embodiment, the copy is of the top percentile assignments. In one embodiment, the top percentile is configured as ninety-five percentile and above. The copy of the top percentile assignments includes the machine identifiers assigned to the top percentile. Processing logic can store the copy of the top percentile, for example, in a file in a data store that is coupled to the risk analyzer.

At block501, processing logic obtains transaction data for a transaction and identifies a machine identifier, such as an IP address, of the machine associated with the transaction from the transaction data at block503. At block505, processing logic determines whether the machine identifier associated with the transaction matches a machine identifier in the top percentile. A match in the top percentile (e.g., ninety-five percentile and above) can represent that the machine identifier used for the transaction is a frequently used machine identifier and that there is a low risk of fraud, if any, that is associated with the transaction.

In one embodiment, if there is a match (block505), processing logic speeds up the process by allowing the transaction to continue at block507, and the method ends without processing logic updating user behavior data (block513) stored in a data to reflect the transaction. In another embodiment, processing logic allows the transaction to continue at block507and updates the user behavior data stored in a data store to reflect the transaction at block513. In another embodiment, processing logic allows the transaction to continue at block507and reduces a current risk score (if any) for the transaction. The updates can indicate the risk analysis results and actions taken in response to this particular machine identifier.

If there is not a match in the subset of percentile assignment data (block505), processing logic generates a risk score for the transaction at block509. Processing logic can generate a risk score based on both a user-level analysis and a enterprise-level analysis. At block511, processing logic determines whether to allow the transaction to continue based on the risk score. At block513, processing logic updates user behavior data stored in a data store that is coupled to the risk analyzer to reflect the transaction.

FIG. 6is a flow diagram of an embodiment of a method600for generating and/or updating percentile assignment data. Method600can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one embodiment, method600is performed by a risk analyzer161hosted by a fraud detection server190inFIG. 1.

At block601, the processing logic collects and stores cross-user transaction data for transactions associated with multiple users and periodically takes a sample of the cross-user transaction data at block603. The period can be pre-defined and configurable. For example, the sample may be taken once a month. The size of the sample can be pre-defined and configurable. A sample can be of part of the data for a time period. For example, the sample size may be some of the data for the previous three months. A sample can also be all of the data for a time period. For example, the sample size may be all of the data for the previous three months. At block605, processing logic determines a count per machine identifier using the sampled data. The count can be a number of transactions per machine identifier or a number of distinct users per machine identifier. In one embodiment, processing logic calculates both a number of transactions per machine identifier and a number of distinct users per machine identifier to create to sets of percentile assignments. At block607, processing logic sorts the machines identifiers, for example, in order from lowest to highest count per machine identifier. For instance, processing logic sorts the machine identifiers from lowest to highest number of transactions per machine identifier. In another example, processing logic sorts the machine identifiers from lowest to highest number of distinct users per machine identifier

At block609, processing logic creates a distribution of the machine identifiers by calculating the percentile of each machine identifier based on the count (e.g., number of transactions per machine identifier and/or number of distinct users per machine identifier). For example, processing logic determines that an IP address 217.35.123.8 has a count of 87 for a number of transactions. In this example, there is a total of 150 IP addresses. In one embodiment, the formula used to assign a percentile to each machine identifier based on the distribution is L/N(100)=P, where L is the number of machine identifiers with a number of transactions less than the count (e.g., count of 87), N is the total number of machine identifiers (e.g., 150 IP addresses) and P is the percentile. Processing logic counts the total number of machine identifiers that have transactions that are less than 87. For example, processing logic counts 113 machine identifiers having less than 87 transactions. In this example, L=113 and N=150. Processing logic divides L by N to get a decimal equivalent (e.g., 113/150=0.753). Processing logic multiples the result (e.g., result of L divided by N) by 100 (e.g., 0.753(100)=75.3). Processing logic can discard the digits to the right of the decimal point (e.g., 75.3 becomes 75) to represent the percentile rank of 75% for the IP address 217.35.123.8. At block611, processing logic stores the percentiles assigned to the machine identifiers. In one embodiment, processing logic stores the percentile assignment for all of the machine identifiers in the data store. In another embodiment, processing logic stores a copy of the data of the top percentile in the data store. In another embodiment, processing logic stores a copy of the data of the bottom percentile in the data store. Storing a copy of a subset of percentile assignment can reduce the memory resources used to perform the risk analysis.

Method600can be a recursive method, such that processing logic can re-populate the percentile assignment data periodically or upon request to maintain up-to-date information.

FIG. 7is a diagram of one embodiment of a computer system for improving a risk assessment for a transaction using percentiles assigned to machine identifiers. Within the computer system700is a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine can operate in the capacity of a server or a client machine (e.g., a client computer executing the browser and the server computer executing the automated task delegation and project management) in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a console device or set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines (e.g., computers) that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The exemplary computer system700includes a processing device702, a main memory704(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory706(e.g., flash memory, static random access memory (SRAM), etc.), and a secondary memory716(e.g., a data storage device in the form of a drive unit, which may include fixed or removable computer-readable storage medium), which communicate with each other via a bus708.

The computer system700may further include a network interface device722. The computer system700also may include a video display unit710(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)) connected to the computer system through a graphics port and graphics chipset, an alphanumeric input device712(e.g., a keyboard), a cursor control device714(e.g., a mouse), and a signal generation device720(e.g., a speaker).

The secondary memory716may include a machine-readable storage medium (or more specifically a computer-readable storage medium)724on which is stored one or more sets of instructions726embodying any one or more of the methodologies or functions described herein. The instructions726may also reside, completely or at least partially, within the main memory704and/or within the processing device702during execution thereof by the computer system700, the main memory704and the processing device702also constituting machine-readable storage media. The instructions726may further be transmitted or received over a network718via the network interface device722.

The instructions726, components and other features described herein (for example in relation toFIG. 2) can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, the instructions726can be implemented as firmware or functional circuitry within hardware devices. Further, the instructions726can be implemented in any combination hardware devices and software components.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “obtaining,” “determining,” “generating,” “modifying,” “decreasing,” “increasing,” “collecting,” “creating,” “assigning,” “storing,” “searching,” or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Embodiments of the invention also relate to an apparatus for performing the operations herein. This apparatus can be specially constructed for the required purposes, or it can comprise a general purpose computer system specifically programmed by a computer program stored in the computer system. Such a computer program can be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems can be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method steps. The structure for a variety of these systems will appear from the description below. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of embodiments of the invention as described herein.

A computer-readable storage medium can include any mechanism for storing information in a form readable by a machine (e.g., a computer), but is not limited to, optical disks, Compact Disc, Read-Only Memory (CD-ROMs), and magneto-optical disks, Read-Only Memory (ROMs), Random Access Memory (RAM), Erasable Programmable Read-Only memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), magnetic or optical cards, flash memory, or the like.