Why static fraud rules fail, and what replaces them
UK payment fraud losses reached £1.28 billion in 2025, up four per cent on the previous year, across more than four million reported cases. That is close to eight cases of fraud every minute, and case volumes have risen thirty-one per cent since 2023.1
What makes those numbers interesting is not the headline. It is the divergence underneath it. Unauthorised fraud losses actually fell five per cent to £703.4 million, while the number of unauthorised cases rose eleven per cent to 3.81 million.1 Detection is working on value and losing on volume. Criminals have shifted to high-frequency, lower-value attacks precisely because that is where rule-based systems are weakest.
Almost every fraud function I have worked with has the same architecture underneath it. A set of static rules, written at different times by different people, each one added after an incident nobody wanted to repeat. Amount over a threshold. Transaction from a new country. Velocity above some number per hour.
Individually every rule was reasonable when it was written. Collectively they produce three problems that compound.
Failure mode one: the false positive economy
This is the cost nobody puts in the business case, and it is larger than the fraud itself.
Research by Javelin Strategy & Research put the value of falsely declined transactions in the US at $118 billion annually, against roughly $9 billion in actual card fraud losses.2 The system designed to prevent loss was destroying an order of magnitude more value than the loss it prevented.
The damage is not confined to the declined transaction. The same research found that 26 per cent of shoppers reduced their spending with a merchant after a false decline, and 32 per cent stopped entirely.2 A false positive is not a one-off cost. It is customer attrition with a long tail.
Merchant Risk Council survey data indicates the typical online retailer declines around 2.6 per cent of orders, of which at least ten per cent should have been accepted.3 And each of those blocked transactions carries an operational cost of somewhere between €1.50 and €5.00 to handle, depending on the intervention.3
Failure mode two: rules cannot see combinations
This is the technically important one.
A new email address on its own carries a moderate fraud rate. A new IP address on its own, similar. But the two together are not additive, they are multiplicative, because they point to the same underlying event: someone other than the genuine customer is operating the account.
In a transaction dataset I analysed recently, the pattern was stark. Transactions with no new identifiers ran at roughly four per cent fraud. One new identifier, nineteen per cent. Two new identifiers, thirty-three per cent. A rule engine evaluating each flag independently would never surface that relationship, because the signal does not exist in any single dimension.
This is precisely the gap that account takeover fraud exploits, and it maps directly to what the industry is now seeing: UK Finance reports banks facing sustained problems with criminals harvesting one-time passcodes to register digital wallets, a pattern that produces exactly this multi-signal novelty profile.1
Failure mode three: static logic in an adversarial domain
Fraudsters adapt. Rules do not.
UK Finance's own framing of the 2025 data makes the point: closing one vulnerability in isolation leads criminals to adapt and exploit others.4 APP fraud losses fell in 2024 after heavy industry investment, and remote purchase fraud rose in its place. The estate does not converge on a solution. It plays whack-a-mole, and the gap widens every month until someone notices the loss numbers and writes another rule.
Start with the rules that actually work
The instinct at this point is to replace the rule estate with a model. That is usually the wrong first move.
Before building anything, look for deterministic patterns: not "elevated fraud rate", but thresholds above which every observed case is fraudulent. They exist more often than people expect. In recent work, transactions above a particular quantity were fraudulent without exception, as were transactions above a specific absolute value. Two simple rules, zero false positives, catching a meaningful share of total fraud, deployable in an afternoon with no model, no validation cycle and no monitoring overhead.
This matters commercially rather than technically. It gives the risk function a demonstrable win in week one while the model work is still in discovery, and it buys the credibility needed for the harder conversation later.
One caveat worth stating plainly to any Head of Risk: a deterministic rule identified in a sample of a few dozen observations needs validating against a longer history before it becomes permanent policy. Deterministic in the sample is not the same as deterministic in the world.
Then use a model for what rules cannot do
The model's job is not to replace the rules. It is to handle what the rules cannot see: the transaction just below threshold, with one novelty flag, on an unusual device, at an odd hour. The probabilistic middle ground where no single signal is damning but the combination is.
What makes this work is feature engineering that captures interactions rather than individual signals. In practice the most predictive features are almost always combinations: amount multiplied by quantity, novelty count multiplied by transaction size. Individually weak, together decisive. Published work on reducing false positives in card fraud has demonstrated the same principle, with automated feature synthesis cutting false positive cost by close to an order of magnitude against an incumbent bank system.2
A note on evaluation. With fraud rates typically in low single-digit percentages, ROC-AUC will flatter almost any model, because the false positive rate has a denominator large enough to absorb a great many mistakes. Precision-recall is the metric that reflects what the review team will actually experience.
Turn scores into operational decisions
A risk score on its own does nothing. The system has to convert it into an action, and the action has to respect the fact that review capacity is a hard constraint.
A three-tier structure works well:
- Automatic block above a high-confidence threshold, where precision is sufficient that customer friction is acceptable
- Manual review in the uncertain band, with the score, the contributing factors and customer history presented together
- Pass with passive monitoring below the lower threshold
The thresholds between those tiers are not a statistical question. They are a commercial decision about how much fraud loss to accept against available review capacity and tolerable customer friction. Given the Javelin asymmetry between false decline cost and fraud cost, the honest analysis often argues for a less aggressive threshold than risk teams instinctively choose.2
My job is to present that trade-off at every threshold, not to choose on the client's behalf.
What good looks like
The end state is layered. Deterministic rules catch the obvious cases at perfect precision and near-zero cost. A model handles the ambiguous majority. Reviewers see a prioritised queue rather than an undifferentiated alert list. And the whole system is monitored for drift, because fraud patterns move and an unwatched model quietly stops working.
None of that requires exotic technology. It requires honesty about what the current estate does and does not catch, and discipline about deploying the cheap wins before the expensive ones.