Why Fraud Detection Still Fails in 2026

In 2026, banks are running complex deep learning models on every single transaction with fraud scoring happening in milliseconds. There are entire teams and entire budgets built around stopping this.

And yet, UK Finance's own annual report puts the damage at £1.3 billion a year. So the obvious question is: if the models are that advanced, why is so much fraud still getting through?

More complex technology hasn't solved this on its own. What's actually starting to move the needle is a different approach entirely. Stepping back from treating fraud as a linear, row-by-row problem, and starting to treat it as a connection problem instead.

That's what this post is about: how changing the way you look at your data can change what you're even able to catch.

What is a fraud ring?

Fraud rings are organized groups of cybercriminals that work together to carry out coordinated attacks. They rarely show up as isolated events. Instead, they leave traces in shared accounts, devices, and payment paths, which means the problem is not just scoring individual transactions, but uncovering the network behind them.

Traditional fraud models are good at scoring individual rows and spotting unusual behaviour, but they are much weaker when the activity is distributed across a connected network. One account may look harmless and one payment path may appear normal. Taken together, though, those same elements can point to coordinated fraud.

That's on purpose because the real challenge is that this fraud isn't high-value in any single transaction. It's spread thin on purpose, like smurfing in money laundering, where criminals break larger amounts into lots of smaller transactions to stay under the radar and avoid detection so by the time it's visible as a pattern, the damage is already done.

This also explains why false positives become such a problem. If the model can only see local behaviour, it can react to small deviations without understanding the broader pattern underneath. Investigators end up chasing alerts that go nowhere, while legitimate customers are caught in the friction.

image of a phone alert with a SCAM message

Why fraud gets harder to trace?

The false positives are usually a sign that the feature space is too flat for the problem you are trying to solve. This flatness doesn't just limit detection accuracy today, it becomes a bigger liability as the fraud ring itself grows. A model that can't see relationships between rows has no way to track how a network is expanding.

The problem becomes more complex very quickly. A ten-person ring isn't just ten times harder to trace than a single fraud case, the difficulty grows combinatorially, not linearly. 

Add one more person, and it doesn’t just create one new relationship, it can connect to every existing person in the ring. So the total number of possible links grows much faster than the number of entities themselves. That kind of growth is what we call on the order of n².

For example, take a ten-person bust-out ring. Together, they build 100 synthetic identities, and each of those identities opens accounts at multiple institutions. What happens next: instead of pushing one big, obvious transaction, they spread activity across those accounts in smaller amounts, keeping transfers low enough to avoid easy detection. With just three accounts per identity and a £5,000 limit on each, the direct exposure alone can reach about £1.5 million. 

The combinatorial exposure is larger still: 3 financial instruments per synthetic identity, across 100 synthetic identities, gives you 300 nodes that translate into tens of thousands of potential pairwise links, before shared devices or payment routes add further hops. Ten human actors sit at the center of a network two to three orders of magnitude larger than their headcount suggests.

That gap, between what the ring looks like and what it actually is, is exactly what a row-by-row model can't see. It's also why fraud is not just a classification problem. It is a structure problem.

a table of transactions row by row

How graph databases help fraud cases?

Once you start seeing it that way, the work changes. You are no longer only asking whether a transaction is suspicious. You are asking which entities are connected, how close they are to known bad actors, whether they sit inside dense clusters, and whether the surrounding network resembles patterns you have seen before.

Graph databases store relationships directly. You're not forcing everything into tables and stitching it back together with expensive joins. Which accounts share a device? Which identities converge on the same payout path? Which customers sit one or two hops from a known fraud case? Natural questions for a graph. 

It also changed the way we think about feature engineering, instead of building signals from a single row, you can build them from degree, centrality, path length, shared neighbours, and community membership. Does this node sit inside a suspicious cluster? Does it connect to multiple flagged entities? Does it fit a pattern you've seen before in fraud cases?

Fraud rings often hide in the structure of the network, not in the size of any one transaction. A graph is what makes that hidden structure visible.

This does not just help after the fact. It can be used at multiple points in the customer lifecycle.

At onboarding, graph queries can flag linked identities before the account becomes active. During an investigation, they can surface hidden relationships that never appeared in the alert queue. As balances rise or checks bounce, the same graph logic can show whether the account belongs to a broader bust-out pattern.

So the graph becomes part of the operational pipeline.

PayPal has published exactly this. One pattern they track is what they call "ABABA", two accounts sending money back and forth at least four times in a short window. On a relational database, spotting means joining the same transaction table over and over just to reconstruct the shape. On a graph, it's already there as a path.

They also look at accounts that suddenly share a device, IP, or address with something else, since ordinary accounts stay consistent on those details and a takeover tends to disturb them. And they cluster accounts by how tightly they connect to one another. Most of an account-transaction graph sits loose and scattered, but real fraud rings show up as a dense knot — accounts tied to each other far more than the rest of the graph. That density itself is a signal, before you've even looked at a single transaction.

image showing the difference between a Normal Graph Vs a Fraud Ring


Seeing the Fraud Ring, Not Just the Transaction

Graph databases help a data scientist in a few ways. It changes what counts as a useful signal, how features are designed, how models get evaluated, and what fraud can actually be found.

A row-level model can still be valuable, but if the fraud is coordinated, the graph often carries the better signal. It hands the model far more structure to work with than a single row ever could.

Fraud does not always look like one bad transaction. More often, it looks like a pattern spread across many small connections. Graph thinking helps data scientists capture the structure behind the fraud, rather than just the symptoms it leaves on the surface.

If you only ask which transaction looks strange, you will miss a lot. If you ask which entities belong to the same hidden network, you start seeing the ring. And once you can see the ring, you are no longer just reacting to fraud after the loss appears. You are building systems that can find it earlier, trace it faster, and understand it at the level where it actually lives.

Banks have plenty of models running in 2026. What most of them are missing is the right unit of analysis to point those models at. The next leap comes from building on a better structure — one where you go from isolated transactions to connected networks, and from guessing at fraud to actually seeing the ring behind it.

Our closed beta is now Live. Sign up via the link below and keep being Evil

https://www.evilworks.com/evil-lair

Next
Next

Stop Losing Days to Model Debugging