The first client fraud log I audited had cleared eleven transactions in under five minutes. Each one sat precisely below the velocity threshold. The system had not failed. It had been studied. Most teams are not built to find that, and that is the more dangerous failure.
In this contributed article, Zia Ullah, a technical writer and software developer at ValueAdd Solution Scandinavia AB, argues that rules-based fraud systems fail not because they are badly written, but because they are legible to the people they are meant to stop.
When the UK rolled out chip and PIN in the mid-2000s, card-present fraud fell sharply. Card-not-present fraud rose just as sharply over the following period, a shift the industry’s own figures tracked at the time. The industry had not reduced fraud. It had moved it. The same pattern has repeated with every significant control upgrade since, and it is playing out again now.
The map you keep handing attackers
A fraud rule is an instruction manual for the people it is meant to stop. Fixed transaction limits, velocity checks, device fingerprints and geographic flags each tell an attacker precisely where the edge is. Professional fraud operations, with their own testing environments, quality assurance and shift patterns, find that edge and work inside it for as long as it stays profitable.
The European Central Bank and the European Banking Authority put total payment fraud across the European Economic Area at 4.3 billion euros in 2022, spread across cards, credit transfers and other instruments. The rules are not failing because they are poorly written. They are failing because they are legible.
What the models actually do differently
There is a great deal of noise about artificial intelligence in fraud detection, much of it from vendors who have rebranded logistic regression. The technology worth attention is gradient- boosted trees, neural-network ensembles and behavioural analytics, all mature and well understood. What separates them from rules is not sophistication. It is the question they ask. A rules engine asks whether a transaction breaks a known constraint. A model asks whether a transaction looks like this customer.
I have watched stolen credentials clear every check a platform had. The device was registered, the location plausible, the amount ordinary. The session behaviour was not: the typing cadence, the navigation pattern and the precise way the form was completed belonged to someone else. A model trained on session-level data caught it inside the authorisation window. A rules engine never would have. Behavioural biometrics follow from a simple insight: credentials can be stolen, but behaviour is genuinely hard to replicate at scale.
The gap between the model and the money
A card authorisation window is about 300 milliseconds. The network does not wait. I have reviewed fraud systems that scored 94 per cent accuracy in controlled testing and prevented almost nothing in production, because the serving infrastructure added 800 milliseconds of latency. By the time the score came back, the transaction had already cleared on a timeout. That is an impressive figure in a quarterly review and an irrelevance in practice.
Real-time fraud detection is as much an infrastructure problem as a modelling one. Without pre-computed features, a streaming pipeline and sub-100-millisecond scoring, you are not running fraud detection. You are running fraud documentation.
What you own when you buy someone else’s model
Most fintech software platforms are not building fraud infrastructure from scratch. They sit on a payment provider’s risk APIs, layer their own rules on top and treat the combination as a strategy. The harder question is who fixes the model when it starts missing things. A third- party model trained on a different portfolio degrades on yours as fraud patterns and your customer base shift. Without a feedback loop that retrains on your own false positives and false negatives, you are running last year’s fraud system.
UK regulation sharpens the point. Firms are increasingly expected to explain automated decisions that affect customers, and a risk score without a reasoning path satisfies neither a compliance team nor a regulator. Explainability is an obligation, not a preference.
Where the investment belongs
The organisations that manage fraud well treat it as a data problem, not a security or technology problem. In practice that means three things. Audit feature null rates before training, because anything above 10 per cent in a high-signal feature is a structural problem rather than a quirk to work around. Monitor for feature drift, because if average session duration or device age is shifting month on month, the model is quietly compensating for something it should be flagging. And close the feedback loop quickly, so that chargebacks
and confirmed fraud are labelled and returned to training within days rather than batched into a quarterly review.
I have seen teams spend eighteen months on a new machine-learning platform only to find that 30 per cent of their training features were unreliable. The model was accurate on the data it had. The data was wrong. The rules engine gets you in the door. The rest of the work keeps you there.
About the author
Zia Ullah is a technical writer and software developer at ValueAdd Solution Scandinavia AB, working with SaaS teams across fintech, healthcare and logistics. His work has appeared in freeCodeCamp, DevOps.com and StackAbuse.
The post The Fraud Pattern Your Rules Engine will Never Catch appeared first on The Fintech Times.
