TECHNICAL FIELD

The subject matter described herein relates to fraud detection, and more particularly to high resolution transaction-level fraud detection for payment cards in a potential state of fraud.

BACKGROUND

Conventional fraud detection technology, such as the Falcon fraud detection technology developed by Fair Isaac Corporation, is designed to detect fraudulent financial payment cards and accounts. In the case of payment cards, entity transaction profiles contain recursively updated fraud feature detectors for the card based on the card history to enable real-time updates of variable estimates and the production of a neural network score that determines the likelihood that the card is in a state of fraud. In one example, Falcon models by design detect accounts in a state of fraud, and focus less on specific transactions that are fraudulent. In today's digital world, it is desirable for cards that are in a state of highly probable fraud to identify specific transactions that are most likely perpetrated by the fraudster versus the true customer. These digital systems enable automation of decline or reverse of specific transactions deemed likely not performed by the cardholder.

FIG. 1illustrates a Falcon model, which takes the transaction and the entity profiles associated with the card to maintain a recursive set of input features. These feature detectors are updated with each transaction and are used in a neural network model to determine a probability that the card is in a state of fraud. In other words, Falcon models use profiles to keep a snapshot of an account's recent behavior and fraud feature detectors as demonstrated inFIG. 1. The Falcon model uses these stored profile feature detectors in the neural network training to produce a score reflecting the likelihood that the card is in a state of fraud.

The Falcon score directly depends on the state of these profiles. If the feature detectors focus on producing features that point to changes at the card level that are inconsistent with the cardholder or consistent with global fraudulent behaviors, then when a card has unusual transactions, it scores high. During this period, there can be both legitimate and fraudulent transactions when the account is in a probable fraudulent state. On average, about 60% of transactions inside a fraud window are legitimate transactions by the real cardholder. Many banks choose to block future transactions based on knowledge of the card account being in a state of fraud.

Falcon had substantially defined the payment fraud detection analytics state-of-the art for the past two decades. One key to Falcon is that the model detects cards in a state of fraud. These highly refined transactions enable analysts to review cards that may be in a state of fraud. Now with the increase in digital notification SMS, TXT, Apps that allow customers to triage legitimate vs. non-legitimate transactions coupled with the expectation that banks ‘understand’ customer behaviors requires a new transaction classification model to be applied on top of Falcon.

However, while blocking all transactions when the card account is in a state of fraud is a prudent practice, some banks want to determine which transactions are likely still legitimate and allow them to continue. Accordingly, what is needed is a system and method for high-resolution transaction-level fraud detection for payment cards in a potential state of fraud, in order to allow legitimate transactions to be executed.

SUMMARY

This document describes an analytic system and method to distinguish fraudulent transactions from a legitimate transaction, predicated on the notion that the card is considered likely to be in state of fraud. In other words, the disclosed system and method can be activated as soon as an account has suspicious activity that causes a high score for potential fraud, but before a bank either can or needs to confirm fraud. The system or method is able to pinpoint the actual fraudulent transactions inside a window of potential fraudulent activity, using a specialized model hereafter referred to as the “pinpoint model.” This new analytic is better suited to automation of transaction reporting to customers for confirmation and/or reversal.

By training on the transaction data inside the fraud window, the pinpoint model is able to learn specific population dynamics unique to cards in a fraud episode. These include completely different fraud/non-fraud risk factors, fraud rates, and specific fraud tactics associated with fraudsters. The pinpoint model is a cascade model which focuses on cascade population characteristics to learn to differentiate between cardholder transactions vs. fraudster transactions. Examples of fraudster characteristics could include differing transaction values, ATM-cash behaviors/rates, predominance of certain merchant category codes compared to the legitimate cardholder, and others.

Beyond differences between fraud and legitimate transactions in this cascade region, the pinpoint model needs to very specifically understand typical behaviors of legitimate card holders—during these fraud episodes cardholders will have an expectation that the bank would understand their recurrent and typical behaviors. We will discuss technology to address this challenge.

In some aspects, a system, method and computer program product for scoring the legitimacy of specific and subsequent transactions by a payment card that is likely in a state of fraud are presented. The system, method and computer execute a process to receive transaction data for a transaction by a payment card associated with a fraud score indicating the payment card is likely in a state of fraud, the fraud score being generated by a fraud detection computing system in communication with the pinpoint processor, the transaction data including one or more attributes. The process further includes accessing, from a card profile associated with the payment card, a token table having an indexed table of n most frequent tokens associated with the payment card, a frequency table of pseudo-frequencies of the corresponding n most frequent tokens and linked with the token table by a common index, and a ranking table that provides a ranking of the tokens.

The process further includes executing a look-up of the token table based on the one or more attributes in the transaction data to determine a frequency and a rank of each of the one or more attributes that correspond with a token, and calculating one or more variables based on the frequency and the rank of each of the one or more attributes. The process further includes generating, using a pinpoint model, a score that represents a likelihood of the transaction being legitimate.

The process further includes updating the token table, the frequency table, and the ranking table based on the transaction data for access by the pinpoint processor for the subsequent transactions. In some aspects, the pinpoint model employs a Recursive Frequency List (RFL) to summarize a transaction history of the payment card and associated cardholder, as described in further detail below.

Implementations of the current subject matter can include, but are not limited to, systems and methods, as well as articles that comprise a tangibly embodied machine-readable medium operable to cause one or more machines (e.g., computers, etc.) to result in operations described herein. Similarly, computer systems are also described that may include one or more processors and one or more memories coupled to the one or more processors. A memory, which can include a computer-readable storage medium, may include, encode, store, or the like one or more programs that cause one or more processors to perform one or more of the operations described herein. Computer implemented methods consistent with one or more implementations of the current subject matter can be implemented by one or more data processors residing in a single computing system or multiple computing systems. Such multiple computing systems can be connected and can exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g. the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc.

The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims. While certain features of the currently disclosed subject matter are described for illustrative purposes in relation to an enterprise resource software system or other business software solution or architecture, it should be readily understood that such features are not intended to be limiting. The claims that follow this disclosure are intended to define the scope of the protected subject matter.

