With the extensive use of e-commerce, credit card fraud has become a major issue that every bank, payment processing platform or web-shop site is facing. Big loss in business is not only related to fraudulent transactions, but also in denying legit transactions (false positives) which are deemed to be fraudulent leading to additional loss in revenues, high levels of customer dissatisfaction and on occasion posing a risk to customers traveling across states and internationally. 

‍

The financial losses due to fraud affects not only merchants and banks (e.g., reimbursements), but also individual clients as well. If the bank loses money, customers eventually pay as well through higher interest rates, higher membership fees, etc. Fraud may also affect the reputation and image of a merchant. Most traditional banks today are in a hurtling rush to compete with the new kids on the block who have been built from the bottom up to be agile online centric entities, so any brand dissonance their wavering customer base may experience hastens the loss of traditionally loyal and profitable customers.

 

So, the most important question to ask is what is the root cause in the approach taken by humans and software to mitigate payments fraud in the first place:

‍

The majority of detection methods combine a variety of fraud detection cues in order to deduct whether a payment is fraudulent or not. This decision often considers the location of the transaction (IP address, geolocation, device identification), source of the transaction (internet, ATM etc.), historic transaction patterns, even the social score of a user, combined with the actual transaction information. In practice, this means that merchants and issuers must apply a set of business rules and analytical algorithms in order to detect fraud.

‍

Some examples of credit card fraud are listed below:

  •  eCommerce website fraud: paying or linking the credit card to unauthorized or entrusted websites
  • Swipe machine fraud
  • Credit card cloning
  • Credit card theft
  • Leaking card information on telephone
  • Giving card to another person to handle

‍

Conventional Fraud Detection

Conventional fraud detection approach is to set up rules which are executed against every transaction. These rules are “hand crafted” — it often takes an enormous amount of time and expertise to configure and tweak them. They are meant to find fraud activities and patterns based on historical records and expert knowledge, but they are often hard to change and adjust to new fraud patterns. Still, they are easy to verify and interpret and have been used and deployed over decades.

‍

In addition to being rather rigid (rules configuration and definitions), these classical rules-based systems are often implemented either by decision tables or decision trees which makes them very hard to extend with third party APIs or with machine learning models.

‍

Fraud Detection with a Machine Learning Approach

As fraud patterns are changing rapidly novel fraud detection methods are needed — moving from a reactive to a proactive approach. In recent years, machine learning has gained a lot of popularity in many different fields such as image/video analysis, natural language processing, speech recognition etc. In this regard, implementation of efficient fraud detection algorithms using machine learning techniques is a rather straightforward idea. Such an approach enables a system to adapt to new, unknown fraud patterns in real time. Fraud detection using machine learning implies deploying a model that is applied to real time transitions (data stream), which was trained on the historical dataset. Performances of these models require constant observation and retraining in order to capture new payment patterns. One example of this system is depicted in the figure below:

‍

‍

When ML Models are Not Enough

Even though this looks as the best approach in dealing with fraud detection, we argue that this approach alone is not ideal in fact some of the world’s largest fintech Software innovators have arrived at the same conclusion as Waylay:

‍

ML Models on their own are not enough to eradicate the persistent problems associated with Fraud Payment Prevention software and operations

‍

Such approach, for instance, doesn’t allow easy addition of fraudulent IP addresses as a source of transitions, since hijacking of the machines can happen in real time, and by the time this is discovered in the historical data set, it might be too late. There are many SAAS providers that allow us to use this information in real time, like for example:

‍

 

The same can be said about a user’s credit and social score services (not to get confused with the Chinese social score system — which is used as a means to control and enforce social obedience). Multiple entities, such as various insurance companies around the world, have announced or deployed systems that would allow its operators to effectively gather information about people’s behavior for use in important decisions. Then to follow the same can be said about compromised email addresses, cards or even merchant sources, all of which would require dynamic filtering and adjustment in real time.

‍

One issue that is often overlooked is that we don’t necessarily need to run ML models on every single transaction. If transitions are rather small, or in cases things are rather obvious (whether to deny or let transactions pass), running ML models is both expensive and time consuming. For instance, if the payment processing requires execution of millions of transactions per day, soon the cost of running ML models can skyrocket.

‍

ML models are also often hard to interpret. Even for some rather trivial decisions, looking at the confidence score doesn’t yield to anything obvious. Moreover, all ML techniques result in the confidence score (value between 0 and 1), where at the end of a day, someone needs to put a threshold on whether a transaction should be let through or not. What if one wants that threshold settings to be set depending on the transaction amount (e.g., higher amounts requiring higher confidence level)?

‍

Another problem arises when different models perform better for different types of transactions. Who and when decides which model to trigger?

‍

A live use case on a fraudulent card payment validation check with Waylay In this video, we will use Waylay orchestration engine to verify if the fraudulent payment has been attempted.

‍

So, what’s the potential solution?

All these shortcomings can be addressed today by Waylay automation technology which has been designed to combine the best of two worlds. On one hand, Waylay can easily add many predefined filtering criteria, which enables easy addition of multiple sources of information that are carried in every transaction, including information about the user, merchant, transaction amount and type, while delegating most demanding and complex transactions intelligently to suites of different ML models. On top of that, Waylay can be set to intervene and adjust confidence threshold settings after the ML model is executed, taking into account other information such as transaction amount, source of transaction etc.

‍

‍

Conclusion

In this paper, we have tried to outline the main differences in building fraud detection applications by using rules engines or machine learning models. As stated above, we argue that the best approach should be a hybrid solution — and that a truly modern approach to fraud detection belongs to machine learning, complemented by rules-based systems.

‍

About the author

Veselin Pizurica is COO and co-founder of Waylay. Veselin holds 12 patents in domain of artificial intelligence, xDSL, home networks and cloud computing.