Developers prioritizing fraud management in a large stream of financial transactions is a difficult task, but instead of thinking about this from the needle perspective ("needle in a haystack"), allow us to flip the context and discuss the grass growing in the field prior to being cut, baled, and stacked. There is much to be learned from the environment that created a transaction that has already led to interesting fraud detection techniques.
In recently released data from Juniper Research they report that retailers will lose $71 billion in CNP (card not present) fraud over the next 5 years. That amount should make even the most optimistic payment professional pause and reflect on how we as an industry can wrap our heads around this challenging ecosystem.
In this article we attempt a fraud perspective shift. Instead of thinking a transaction is either fraudulent or not fraudulent we consider the implications of a set of continua (did you know the plural of continuum is continua?) from highly likely to commit fraud to very unlikely to commit fraud, across a set of reputations.
While many of the examples below have been implemented in fraud prevention systems, in this article, the goal is a high level theoretical conversation. However, if you are interested in concrete details, please feel free to read about the advanced fraud toolkit provided by the Vantiv eComm platform that implements some of the ideas below.
"It takes many good deeds to build a good reputation, and only one bad one to lose it." -- Benjamin Franklin
Essentially, there are four primary targets where reputation can be used towards better fraud management by developers:
- Reputation of the card/account
- Reputation of the “device” that is initiating the payment
- Reputation of the person presenting the card/account and using the device (this person is not necessarily the person that is authorized to use the card/account).
- Reputation of the merchant processing the transaction
Consider the plastic on which the card account is imprinted and what happens if the account (or track) data transitions is written to a piece of paper, or the account/track data is stolen in transit and imprinted on another card. All of the physical cards that come to represent this specific account and all of the locations of data that originated from the card all have a reputation. Good reputation or bad reputation is not the point; rather, each iteration of the card/account has a distinct reputation.
Imagine a card typically used to purchase day-to-day items like groceries and fuel in a card present swiped form and then one day the card is used to purchase shoes from an eCommerce store as card not present. Was this fraud? Or simply a change in the reputation of the card? Monetary values the card submits are also a portion of the card’s reputation. If the average use of a card is $100.00 per transaction, then an outlier suggests either fraud and/or a change in reputation.
A card reputation split occurs when the original plastic is used for a card not present transaction or when track data is stolen or tokenized. Each of these splits generates a reputation birth that can be linked to, or unlinked from, the original reputation. For example, when one gives their credit card number to a utility for monthly billing, the card data (or hopefully token) stored at the utility company retains its own reputation while also being linked to the original card from which it was born.
The device that processes the card (or card data) also forms a reputation over time and device fingerprinting is an excellent source of reputation data. Below we consider both card present and card not present environments.
Card Present Environment
Consider the device that processes transactions in a brick and mortar store. It is typically either a pin pad connected directly to an IP connection or a pin pad connected to a computer (connected to an IP connection). In both cases the reputation of the device is stable both physically and from an IP viewpoint. The device is eventually going to provide a fingerprint of average ticket, physical location, Internet location, day and time of use, etc. If there is a steady stream of $50 tickets flowing through the device and then a $1000 ticket flows through, we can question the reputation of the device. Another scenario is seeing transactions flowing through for a year only on business days but then seeing a transaction for $60.00 on December 25th. Those amounts and days might not reflect poorly from a card reputation perspective, but they might trip a device reputation alert.
Card Not Present Environment
In CNP processing, the consumer and card data are typically flowing through the consumer’s personal device(or in some cases, a publicly accessible computer at a library or kiosk). From a CNP fraud perspective the reputation of the device is critical. Imagine making a payment from your personal smart phone. The smart phone, like the payment terminal above, is going to quickly create its own reputation. Purchases are made on certain websites, at certain times of day, for specific amounts, at specific geo locations, and for specific products. Now consider the view from the eComm site’s owner. They love and seek out device reputations like the one described above. If however, the website owner detects a transaction inbound from a device located in France, for example, and that website owner knows they do not do business in France, then it is easy to stop fraud based on, in this case, the geo location of device.
The consumer, or person presenting the card (or card data) is typically identified as the fraudster, but as indicated above, there is more of a reputation continuum from highly unlikely to commit fraud to very likely to commit fraud. Even if the consumer is deemed highly unlikely to commit fraud we still might want to decline a transaction based on a device that is highly likely or card data that is highly likely to commit fraud.
There are some excellent techniques for validating consumer reputation. To keep things simple, assume the same card data reputation and same device reputation are being used. How would the reputation of the consumer be judged? Imagine the ability to detect how fast the consumer types the card data during an eComm checkout and in what manner the keys on the keyboard or smartphone are being tapped. Or with a smartphone leveraging the accelerometer to detect how the device is being held while the data is being entered. There have even been applications built around authenticating a consumer to smart phones by leveraging gait analysis with the accelerometer. In addition to these scenarios there are the obvious differentiators such as products purchased, day/times of purchase, amounts, etc. All of these examples create the cardholder or consumer reputation. Social media is also becoming an important consideration in establishing the reputation of a consumer.
The final piece of the reputation puzzle is the merchant: either eCommerce, brick and mortar, or both. The processing environment and merchant metadata are critical to establishing the processing reputation. The vertical that the merchant processes in the number of years in business, average ticket, business hours, and volume are all excellent indicators that help to establish a merchant’s reputation. Taking this a step further, and differentiating from device reputation, consider a virus infecting a merchant’s back office computer but payment processing occurring from a dedicated payment terminal. The device fingerprint, having no virus, might be highly unlikely to commit fraud but from a holistic merchant perspective having a virus on any computer or device within the merchant environment degrades the merchant's reputation score. As with other properties discussed above each merchant property will be assigned a weight so that the reputation score does not over emphasize smaller attributes. For example a fraud scoring algorithm might weight the number of years in business and average ticket higher than business hours.
"Bad boys, bad boys Whatcha gonna do, whatcha gonna do, When they come for you"
There is no doubt that fraud occurs on a daily basis and if the data is correct, it is going to get worse before it gets better. However, there is no reason to stick our heads in the sand. There are tools out there for developers to manage fraud and leveraging the notion of reputation is an intriguing way to approach the issue. We enjoy participating in the discourse from both theoretical and concrete approaches so please feel free to leave comments, or better yet, write an article on VantivONE to share with your peers engaging in the fraud conversation. As always we look forward to hearing from you.