Clearing the Fog around Fraud Systems and Payment Data
Financial fraud detection and payment risk systems have been around in various forms since the early 1970’s. Over the years systems have been introduced which all take different approaches to fraud detection, although the most popular involve fraud rules.
Rules based systems are extremely popular due to their ‘white box’ nature, meaning fraud analysts can easily see why a rule was broken and whether they deem the behaviour normal or not. Rules also have the advantage of being added, tweaked, and changed depending on the current fraud problem. However, rules also have a disadvantage due to their simplicity that can be exploited easily by fraudsters changing only a single part of their strategy to get past the system and continue their fraud run.
Innovations in machine learning and the ‘big data’ revolution lends itself to the payments industry due to the huge volume of daily payments, but other approaches are becoming more commonly accepted. The customer still tends to put these systems through vigorous testing to ensure their system is not going to suffer any adverse effects before using them in production. This same level of testing is applied whenever a new machine learning model is placed into production. Some fraud detection systems have a staging area where new fraud strategies can be experimented with, without affecting the live system.
In a commercial system, there are several fraud rules, which act as a ‘backbone’ and are generally simple rules intended to detect the most obvious frauds. More advanced rules are built on top of these which usually incorporate spending sequences and more extreme card usage behaviour changes intended to stop more experimental fraudsters. Machine learning (ML) is a natural fit to complement rules-based systems because machines can analyse millions of authorisations and learn trends much faster than any human can. In a real time world ML is the only technology that can keep pace.
Commercial Fraud Systems
Traditionally, fraud systems are applied at the Issuer (Bank) and Merchant level, where payments are processed online. The systems were purely rules based, whereby fraud managers were required to write rules which would describe suspicious behaviour. The fraud managers did not have many, if any, tools for data analysis beyond a database engine, with analysis typically taking more than 2 weeks, so writing rules for new fraud patterns required an enormous amount of manual effort.
Very often, by the time this activity has completed, new fraud trends have emerged, and more fraud analysts are required to develop rules and review rule breaks. This has been slowly changing over the last few years; there have been many start-up businesses disrupting the industry with new technology, due in part to the emergence of more powerful machines, as well as cloud services, capable of processing the huge volume of payments of today.
The main technology to really make an impact is the use of machine learning to predict fraud and almost all start-ups use this to some degree. The attitude of the customer has also changed. Most customers require fast and efficient fraud risk processing, such that risk can be analysed during the payment process such that fraud loss can be largely reduced.
Customers are also now looking for simple integrations into third party fraud systems and prefer not to have to pay for extremely expensive inhouse hardware, as they are aware they will need to continue to do this as authorisation volumes increase and their current hardware is unable to keep up. Because of this, most fraud products are offered as a cloud product/service, which provides advantages to both the customer and supplier.
Many machine learning algorithms have been successfully utilised, some of the first used decision trees and basic neural networks which were created by teams of data scientists and used for long periods, often up to a year before performing a refresh.
This changing behaviour is leading to innovations of fraud detection at many places in the payment process. For instance, merchants are beginning to implement simple fraud detection systems to stop specific fraud cases. Payment gateways traditionally have not performed any fraud detection, leaving this to the merchant and issuer, however there is a case for it due to the large amount of available data that is very different to what is usually available at the card issuer. Gateway data can also help to discover fraudsters with a handful of cards attempting to discover which ones are active.
The below example illustrates how performing fraud detection at a payment gateway level is beneficial for many reasons. Including the ability to stop a transaction before it reaches the bank, meaning the fraudsters move elsewhere – no easy pickings, and a pre-warning is triggered, meaning the goods are not shipped.
The image reflects a real-life case where a fraudster had several stolen cards and was attempting to use them to make payments. When one card did not work, they would try the next one, until eventually one was successful. Fraud detection would have been simple since each authorisation here has an IP address associated (which was the same), the target was consistent and the name used to make the payment was also the same, as well as each authorisation attempt being within minutes of each other.
If a fraud system had been implemented here, not only would it have been possible to contact the issuers of the compromised cards to reduce further fraud loss, but this would have been stopped sooner with the possibility of catching the fraudster in the act with the local police force.
It is critical to constantly improve any fraud system, as older approaches become less effective as time goes by. Fraud systems can be applied to all areas of the payment process, traditionally fraud detection is performed at the card issuer after the basic checks are performed but this is now changing and more advanced fraud checks can be done at any stage. This gives businesses more protection against fraud whilst allowing more genuine customers to purchase goods.
At the start of the payment cycle the payment must start at a merchant, this is where fraud detection begins. In a website environment where customers are required to have an account to make payments, this basic fraud detection can take place utilising pattern detection rules for such situations where if a customer is exhibiting very different behaviour than usual the retailer can infer that the payment is probably fraudulent. There is not much more the retailer can do here until further information is retrieved back from the acquirer and issuer. An exception is made in the case of a mobile payment where data from the device’s sensors can be utilised for more enhanced fraud detection.
For instance, location data can be utilised in the same way as when using a payment card at a terminal. This type of information is rarely used at the time of writing; however, it is expected this information will be used heavily in future systems.
After this, the payment is sent to the card Acquirer and then on to the card Issuer, where some in-depth checks are performed such as CV2 as well as passing through a fraud detection system. This is where most of the commercial systems are aimed due to the abundance of data available. The payment is returned to the Acquirer, where some more fraud detection takes place, then back to the payment switch where the final fraud detection pass is made, then finally back to the retailer for approval.
It might sound complicated, but I hope this piece has cleared some of the fog surrounding around fraud systems and payment data. The next time your bank queries, or even declines, a transaction it might be helpful to understand the technology and reasons behind it.