Payment fraud: How Machine Learning strengthens fraud detection

Fraud Payment in the UK: trends and statistics 2022

Unauthorised financial fraud losses across payment cards, remote banking and cheques totalled £609.8 million in the first half of this 2022, according to UK Finance's latest report. Banks and card companies prevented £584 million from being stolen. This represents incidents that were detected and prevented by firms and is equivalent to £6.18 in every £10 of attempted fraud fraud being stopped.

In addition to this, UK Finance members reported 95,219 incidents of Authorised Push Payment (APP) scams in in the first half of 2022 with gross losses of £249.1 million.

Unauthorised payment is the bigger issue in terms of volume in the UK with £360 million stolen in H1 2022 alone, UK Finance states.

What does payment fraud look like?

Simply put, there are two main types of payment fraud:

• Those that produce a direct victim (identity fraud, hacking, supplier frauds, invoice frauds, company director frauds)
• Those that produce an indirect victim: banks, states, and/or systems (money laundering, AC Scams)

There are sometimes a combination of these two types of fraud, with AC Scams prompting victims to be misled about how their accounts will be used to cipher money from them. Small businesses are the most common target for payment fraud. Fintechs and other financial innovators can also be targeted in so-called "multi-vector attacks" that target a range of financial actors, however.

At what point in the payment process is security most vulnerable?

Payment fraud attacks will often target processes like the onboarding of new customers, request-to-pay and invoicing, and initiation or execution of payment.

Let's take account payable for instance. Typically, AP teams will go through the following steps when making a payment:

1. Validation of the source when requesting the payment
2. Validation of the payment requisition
3. Validation of the transaction

While there are vulnerabilities at each stage of the payment process, the greatest risk comes in Steps 2 and 3. For example, fraud perpetrated at the invoicing stage often results in an Authorised Push Payment (APP), as fraudulent invoicing can prompt an unsuspecting payer to initiate payments to criminals.

Fortunately, there are numerous steps companies can take to both identify payments fraud and then prevent it from happening.

Create a more secure environment through data

Data is the fuel for machine learning models. This is why one of the first steps should be to set-up a data warehouse that will be used as a source of information during training. This means extracting the relevant fields and creating a rich database table with the attributes necessary to learn from your data.

Libeo is a fully integrated and automated business-to-business payments platform, bridging the gap between invoices, payments, reconciliation and accounting. The solution synchronises with most accounting software and banks on the market. It is therefore not surprising that one of its major concerns is to provide a secure end-to-end payment operations, especially considering the large volume of payments and sensitive data processed by the platform every day.

Moreover, it is Libeo's full responsibility to meet its customers' needs in terms of payment security. Therefore, as well as traditional security measures such as secure gateways and two-factor authentication that are required for any payment platform, we developed an advanced data-based solution.

As a startup, you don’t have historical data, let alone historical fraud data. Therefore, you need to get creative!

Create your own anti-fraud team

Payment fraud cannot be tackled by data team members alone. This is why it is important to build a fraud team from day one with a rather heterogeneous composition. Following this principle, Libeo's anti-fraud team is composed of two Data Analysts, a Data Scientist, a Product Manager, and two Customer Success Managers.

First, as we had no prior fraud case to base our alert system on, we had to imagine different fraud scenarios and group them into different types of payment fraud risks based on expertise and market practices.

Later on, we verified which types of risks could be identified based on data collected on a daily basis. This exercise allowed us to anticipate what new data we need to track and explore in order to cover more risks. The product manager’s essential role is to challenge whether or not the considered properties cover each corresponding risk. The product manager also examined adequate preventive actions for every type of risk.

Last but not least, the customer success managers, who are more customer-facing, played a central role in the testing phase and usage of the model. More on that below.

A significant advantage of having a heterogeneous fraud team is that you get both the data and the customer-facing teams involved. Every team’s representative has a responsibility in understanding how it’s done and should play their role to ensure that we inhibit fraudulent transactions.

Let’s get a bit technical.

Build solid assumptions

We began by building a score-based alerting system that automatically assesses the level of suspiciousness of every transaction and flags those whose scores exceed a certain threshold.

A transaction is never instantaneous. The transaction takes a certain amount of time to be processed and that constitutes our only window to react. One challenge is to stay proactive in order to detect and block potential frauds without prolonging payment request processing time. We based the model on the following assumptions:

• Fraudulent transactions should be detected and prevented. If a transaction is missed, the system should learn from the mistake and become more vigilant in the future.
• Increase vigilance on new users
• Need to earn the trust of the model through a positive history of transactions checkmarks
• Don't assume that every new behavior is malicious. But be wary of transactions that seem unusual in any way.

Let’s zoom in on the scoring system

All of the previous assumptions have a common thread: they all require a reference on which to base an assessment and scoring.

• Build a set of nominal behaviors enabling the recognition of new users, positive histories of transactions, known frauds and suspicious activities.
• Compare each transaction to nominal behavior by applying a set of interactive comparison rules. Prescriptive rules add argumentation, so that you can evaluate the model with more confidence. It is a valuable tool — it allows us to respond to situations that have not yet occurred.
• Identify whether new or odd behavior is malicious or benign, not only to reduce false positives in the alerting system but also to make scoring refinement easier. Remember that it is better to have false alarms about secure transactions than to have no alarms at all. At least that way, you're making sure that you are on the alert for fraud. Bottom line: it is ok to be strict on suspicious behavior in the beginning
• Establish the difference between detecting/alerting and taking preventive action. It is essential to understand the different workflows and consequences

We at Libeo are committed to using attributes in our work that are actionable, or that can be transformed into action.

It is a known fact that automated actions can lead to blocking of legitimate transactions or spamming users with alarming emails. Thus, the fraud team makes the final decision about any action to take. Yet it is important to assist decision-making by creating a catalog of recommended preventive actions for each fraud risk scenario.

Micro iterations for continuous improvement

We believe that learning by doing is a core value at Libeo, and that it is a key enabler of our strong growth on all levels. The team quickly put the model in production and:

• Iterated on a daily basis. It's not a problem if you make quick adjustments! All we had to do was share a document and spend 15 minutes each day writing down our observations.
• Refined the score in line with everybody’s feedback, starting with the customer success managers.
• Built on observations over time to validate or reject initial assumptions. We always kept in mind that we could challenge anything if it was proven wrong with time.

The final result: a secure, smooth and efficient payment process

You'll be surprised by what a scoring system can do for you:

• For users, a B2B payment experience that is secure and swift!
• A warning system that alerts us when we're off-track!
• For our Data team, a record of historical transactions with their corresponding scores, types of risk and potential preventive actions. This dataset is used to train an ML model that predicts the type of risk on a suspicious transaction and recommends an appropriate preventive action.