(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisbon
Fraud detection with machine learning: a practical guide
Artificial Intelligence

Fraud detection with machine learning: a practical guide

João Barros 06/07/2026 7 min

Fraud is not a new problem, but the scale at which it now happens is. Every online payment, account sign-up or refund request is an opportunity for someone trying to game the system — and the fixed rules that for years stopped the most obvious schemes are no longer enough. Fraudsters adapt quickly, probe limits and hide among millions of legitimate transactions.

This is where machine learning comes in. Instead of relying on a list of hand-written rules — block if the amount is above X — a model learns from history what separates a normal operation from a suspicious one, and keeps adjusting as patterns change. Done well, it catches schemes no rule would anticipate; done badly, it blocks legitimate customers and lets the real fraudsters through.

This guide walks through the decisions that separate a useful fraud detection system from one that only generates noise: which type of model to use, which data feeds the decision, how to deal with the fact that fraud is rare, and how to know whether the model is actually helping.

Why fraud is so hard to catch

Before choosing an algorithm, it is worth understanding what we are up against. Fraud detection has four characteristics that make it different from an ordinary prediction problem.

Fraud detection with machine learning: a practical guide
  • It is rare. In many businesses, fewer than 1% of transactions are fraudulent. A model that always says "this is legitimate" is right 99% of the time and, even so, completely useless.
  • The adversary adapts. Unlike forecasting sales, here there is someone on the other side changing tactics as soon as they notice a path has been closed.
  • The cost of being wrong is asymmetric. Letting fraud through costs money; blocking a legitimate customer costs trust and, often, the customer itself. They rarely weigh the same.
  • The decision is urgent. A payment has to be approved or declined in milliseconds, not the next day.

Any serious approach to fraud has to answer these four pressures at once. That is why copying a model from another context rarely works.

Supervised vs unsupervised learning

There are two broad paths, and the best systems usually combine both.

In supervised learning, we train the model on past cases already labelled as fraud or not fraud. Models such as gradient boosting (for example, XGBoost or LightGBM) or random forests work well when there is a reliable history of confirmed fraud. The limitation is obvious: they only learn to recognise what we have already seen.

In unsupervised learning, the model receives no labels — it simply looks for what departs from normal. Techniques such as isolation forest, autoencoders or clustering flag anomalous behaviour, even if it has never been seen. It is the best defence against new schemes, but it generates more false alarms, because "strange" is not the same as "fraudulent".

In practice, many teams use a supervised model for known patterns and an unsupervised layer to catch what is genuinely new, leaving the most ambiguous cases for human review.

The features that make the difference

A fraud model is only as good as the data it receives. And, almost always, the value is not in the isolated transaction but in the context in which it happens. The most useful features are usually built from behaviour over time:

  • Velocity: how many transactions came from this card, device or IP in the last hour? A sudden spike is a classic signal.
  • Deviation from habit: does this customer usually buy at this time, in this country, at this amount? Comparing against their own history is worth more than any absolute threshold.
  • Shared links: is this device associated with dozens of different accounts? Do several cards point to the same address?
  • Time friction: how long passed between creating the account and the first high-value purchase?

Notice that none of these features is the purchase amount itself. It is feature engineering — turning raw data into meaningful signals — that separates a mediocre model from a good one.

The problem of imbalanced data

Let us return to the fact that fraud is rare. If we train a model on data where 99.5% of cases are legitimate, it quickly learns that the safest bet is to always say "legitimate". Overall accuracy looks great and the model detects nothing.

There are several ways around this: resample the data (reduce the legitimate cases or over-represent the fraudulent ones, with techniques such as SMOTE), assign more weight to fraud errors during training, or — most importantly — stop looking at accuracy and choose metrics that reflect what matters.

Precision, recall and the cost of being wrong

Two metrics dominate the conversation in fraud, and it is essential to understand the tension between them.

  • Recall (sensitivity): of all the fraud that happened, how much did the model catch? A low recall means money leaking out of the door.
  • Precision: of all the alerts the model raised, how many were actually fraud? Low precision means legitimate customers blocked and a review team drowning in false alarms.

Raising one almost always lowers the other. Where to set the decision threshold is not a technical question — it is a business one. How much does an undetected fraud cost? And a customer annoyed at seeing their card declined over lunch? The answer defines the balance point, and that is why the precision-recall curve says far more than a single accuracy percentage.

Real time vs batch analysis

Not all fraud needs the same response speed. Authorising a card payment requires a decision in real time, in a few tens of milliseconds — which imposes limits on the model and the infrastructure. Detecting fake accounts created en masse, or collusion rings, can instead be done in batch, running heavier analyses hourly or overnight.

Many systems combine the two layers: a fast decision in the moment, followed by a deeper analysis that reviews, confirms or reverses cases and, above all, feeds the model with new examples.

When the model starts to fail

A fraud model is not a project you deliver and forget. Because the adversary adapts, performance naturally degrades over time — this is known as concept drift. What was a strong fraud signal six months ago may be perfectly normal behaviour today.

That is why monitoring the model in production is as important as training it. It is worth tracking the alert rate, the precision confirmed by the review team and how features evolve over time. A subtle but critical point: the fraud the model blocks never gets confirmed as fraud, which can distort the metrics. Without a control sample and without feedback from those who investigate the cases, the model becomes blind to its own error.

Mini-case: catching more fraud without annoying customers

An online payments company relied on a set of fixed rules: it blocked purchases above a certain amount, or coming from certain countries. It caught around 60% of fraud, but at the cost of declining many legitimate purchases — the false-positive rate was around 5%, and customer support was full of complaints.

The team introduced a gradient boosting model fed by velocity and deviation-from-habit features, keeping the old rules only as a safety net for the obvious cases. They set the threshold not to maximise detection, but to keep false positives below 1%. After three months, fraud detection rose to nearly 85% and declined legitimate purchases fell to less than half. The gain did not come from a magic algorithm, but from better features and a threshold chosen with the business in mind, not just the statistics.

In practice

Detecting fraud with machine learning is not about buying the most sophisticated model, it is about designing a system that respects the nature of the problem: the rarity of the cases, the adversary that adapts and the real cost of each type of error. Start with the right features, choose metrics that reflect the business — precision and recall, not accuracy — combine supervised and unsupervised models, and treat monitoring as part of the product, not an extra.

And do not dismiss rules: the best defences combine the speed of a simple rule for the obvious with the subtlety of a model for the rest. The goal is never to catch 100% of fraud at any cost — it is to find the balance where you lose less money without driving away those who, in the end, sustain the business: the good-faith customers.

← Back to insights
Let's talk?

Ready to transform your data?

Book a free 30-minute meeting and find out how we can help your team make better decisions.

Book a Free Meeting
bConcepts