Adaptive Fraud Detection for Online Payments: Architecting the Feedback Loop, Not Just the Model
Static rules are easy to criticise and hard to retire. A threshold written after last quarter's loss blocks the next legitimate customer who travels or changes phone, while a patient fraudster learns where the line sits and stays under it. Moving to machine learning is the obvious answer, but many teams discover that swapping the scoring engine barely changes outcomes. What changes outcomes is how quickly the whole system learns what actually happened, and how safely it acts on that learning. This article sets out an architecture for adaptive fraud detection in online payments, written for UK product, engineering and risk leaders, with the trade-offs stated plainly.
One note on scope. We reviewed October 2026 market intelligence for UK-relevant evidence on fraud and payments. It contained no published fraud-loss statistics we can attribute, and nothing on UK reimbursement rules or card-scheme fraud requirements that we would want to rely on, so this article does not address them. It is architectural analysis, with a few dated developments marked and hedged where the evidence is thin.
Why static rules decay
A rules engine encodes yesterday's understanding of fraud. It has three weaknesses that compound.
It is slow to adapt. Every change needs an analyst to spot a pattern, write a rule, test it and release it. Fraud tactics change faster than that cycle, so rules lag, and the lag is a standing exposure.
It is blunt. Fixed thresholds treat legitimate variation as suspicious: a new device, an unusual basket, a trip abroad. The customer pays the cost in friction, support calls and abandoned payments, while the business absorbs the lost revenue and the operational load of reviewing alerts that were never fraud.
It is predictable. Anyone who probes a rule set can map it. A model that weighs many signals at once is harder to probe than a hard limit, though not impossible.
We would not recommend abandoning rules altogether. Hard limits, sanctions checks and regulatory controls belong in rules because they must be deterministic and explainable. The design question is where rules end and learned scoring begins, and how the two are combined.
Separate the decision layer from the models
The most useful architectural move is to stop thinking of the fraud system as "a model" and to treat it as five layers.
- Signal collection. Transaction metadata, device and session signals, behavioural signals such as interaction patterns, and relationship data linking accounts, devices and merchants.
- Feature layer. The calculation of features from those signals, built once and used identically in training and in live scoring. Differences between the two are a frequent, quiet cause of models that look good in testing and decay in production.
- Model layer. Typically more than one model: supervised models trained on labelled history for known patterns, and unsupervised anomaly detection for unfamiliar behaviour, perhaps with graph analytics for linked accounts.
- Decision layer. A policy engine that takes model scores plus business rules and chooses an action: approve, step up authentication, send to review, decline.
- Feedback layer. Case management and outcome capture, which return labels to the models and the policy.
The decision layer is the point to emphasise. If thresholds and actions live inside the model code, every adjustment is a model release. Keeping policy separate lets risk teams change thresholds, add step-up rules for a campaign or tighten limits during an attack, without retraining. It also gives each decision a reason code that analysts, customers and auditors can read, which a bare score does not.
Why not one model?
A single model is simpler to run, but different techniques fail differently. Supervised models are strong on patterns seen before and weak on new ones. Anomaly detectors can spot novelty but produce more false positives and need careful tuning. Graph features can reveal linked accounts but depend on up-to-date relationship data and can cause cascading false positives if an erroneous link spreads. Combining them behind a decision layer costs engineering effort and latency. We think that cost is usually justified for a payments platform with meaningful volume, but a smaller business may reasonably start with one supervised model plus rules and add layers as data accumulates.
The feedback loop is where adaptation happens
"Adaptive" is often sold as a property of the algorithm. In practice it is a property of the loop around it, and the loop has awkward features that deserve design attention. Production AI engineering, including monitoring, retraining and rollback, is the work here, and it is the part that models rarely come with. Our own AI and ML delivery work includes it.
Labels arrive late. The true outcome of a transaction may only be known when a customer disputes it or an investigation concludes, which can be long after the decision. A model retrained on recent data sees only the outcomes that have already resolved, so the newest fraud tactics are underrepresented exactly when they matter most.
Labels are biased. You learn the outcome only of transactions you approved. Declined transactions never reveal whether they were fraudulent. If the model keeps blocking a pattern, it never learns it was wrong. Controlled sampling, in which a small share of borderline cases is allowed through under tight limits, is one way to recover some of that information, but it has a cost and needs risk sign-off.
Analysts are a label source. Review decisions from fraud analysts are a faster signal than disputes. They are also subjective and inconsistent, so capture the reasoning and measure agreement between analysts before treating them as ground truth.
Three mechanisms keep the loop honest:
- Champion and challenger. Run a candidate model alongside the live one in shadow mode and compare decisions before promoting it.
- Drift monitoring. Watch input distributions, score distributions and decline rates for movement that suggests either a changed attack pattern or a broken upstream feed.
- Delayed-label evaluation. Measure performance on cohorts once their outcomes are known, and report the lag openly so nobody mistakes immature data for good news.
Latency, load and failure: the checkout budget
Fraud scoring sits in the payment path, so it competes with the customer's patience. Every millisecond is a design constraint.
Decide what must be synchronous. Scoring that determines whether to authorise has to complete within the checkout budget. Heavier work, such as graph updates, retrospective rescoring and network analysis, can run asynchronously and feed the next decision rather than this one.
Precompute where you can. Features that change slowly, such as account history, can be prepared in advance and served from a feature store, leaving only fast features to compute live.
Plan for load spikes. A fraud attack and a legitimate demand surge can look alike at the infrastructure level. The system must degrade predictably, not time out unpredictably.
Define the fallback. If scoring is unavailable, what happens? The options are approving everything, declining everything or reverting to a conservative rules-and-limits mode. Only the last is usually defensible, and it should be tested regularly, because a fallback never exercised cannot be trusted. This is the same discipline as any resilience design, and fraud scoring is one of the dependencies a platform's operational resilience planning should cover.
The trade-off is plain. More signals and more models improve detection but add latency and failure surfaces. The practical approach is to measure the marginal value of each signal against its latency and operational cost, and drop those that do not pay their way.
Humans, explainability and the regulator
Adaptive systems still need people. Analysts review uncertain cases, handle appeals and notice patterns that metrics miss. The design should make their work easier: show the reason codes, the contributing signals and the customer's history in one view, and record their decisions in a way that feeds back into the loop.
On 19 October 2026 the FCA published a speech on AI in finance. According to the industry intelligence we reviewed, it described the regulator as applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than creating new rules for agents, and it set out good and poor practice. We have not summarised the detail and readers should consult the primary text.
The following is our interpretation, not regulatory guidance. A fraud system's false positives are a customer outcome as well as an operational cost. A declined legitimate payment, a frozen account or a failed step-up can leave a customer without access to money. Treating false-positive rate, appeal handling time and the customer groups most affected as monitored measures is consistent with the direction of the Consumer Duty. Equally, a named senior person should be able to explain how automated decisions are made. This section requires a compliance read before it informs any firm's policy.
What is changing: agents, stablecoins and new signals
Three October 2026 developments suggest that the signal set will keep widening. Each is reported by third parties, and we flag the confidence level.
Agent-initiated payments. The industry intelligence we reviewed, dated 20 October 2026, reports a vendor ecosystem forming around agent identity, delegated authority and fraud decisioning, with no single standard yet. The confidence is medium. If an AI agent initiates a payment on a customer's behalf, the fraud system must ask a new question: has this agent been authorised by this person for this purpose? That is an input to model and policy design for agent-initiated payments that few current fraud stacks represent.
Stablecoin rails. Mastercard announced Stablecoin Security on 19 October 2026, adding payment and blockchain intelligence to stablecoin risk screening. Our source is LinkedIn company-page material, so treat it as an announcement, not a verified description of the product. The relevance is that risk screening is being built into new rails as they scale.
Fraud and financial crime inside the bank's core. Finextra and FF News reported on 20 October 2026 that Starling Bank had deployed an agentic financial-crime investigator inside its core and trained a transactional model on UK sovereign cloud. The 17-second investigation time quoted in the coverage is Starling's own claim, and we do not rely on it. The relevant point for architects is that data ownership and hosting were stated design principles. Fraud features are drawn from sensitive customer data, so where the data lives and who can reach it should be settled before models are trained.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses build AI-native products, modernise their technology stack and launch fintech products, designing compliance in from the start.
For fraud detection, the relevant work is usually the engineering around the model: the feature layer, the decision engine, the monitoring and the fallback, built so that risk and compliance teams can inspect it. That work sits within our AI / ML Development practice, and for teams preparing for agent-initiated payments the related design questions are covered in our Agentic Commerce and Payments work. We do not give regulatory advice, and your compliance team should own regulatory interpretation.
FAQ
What is adaptive fraud detection?
Adaptive fraud detection is a system that updates its understanding of fraud as outcomes become known, rather than relying on fixed rules. It combines learned models, a policy layer that decides the action and a feedback loop that returns confirmed outcomes. Adaptation depends on that loop at least as much as on the algorithm.
How is AI fraud detection different from rules-based detection?
Rules apply fixed conditions, so they are predictable, explainable and slow to change. AI models weigh many signals and can score unfamiliar patterns, but they need data, monitoring and retraining. Most production systems use both: rules for hard limits and regulatory controls, models for scoring, and a decision layer to combine them.
How do you reduce false positives without missing fraud?
Measure false positives as a customer outcome, then tune policy rather than only the model. Use step-up authentication for uncertain cases instead of outright declines, review analyst decisions for consistency and test changes against a challenger model in shadow mode. Accept that the balance between fraud caught and customers inconvenienced is a business decision, not a technical constant.
How do you keep a fraud model from decaying?
Monitor input and score distributions for drift, evaluate performance on cohorts once their outcomes are known, and retrain on a schedule agreed with risk. Keep the feature code identical in training and live scoring, and have a tested rollback. Late and biased labels mean the model's newest blind spots are the hardest to see.
Which UK regulation applies to AI fraud detection?
The FCA has said it applies existing frameworks, including Consumer Duty and senior-manager accountability, to AI. The detail for a given firm depends on its permissions and products, so take compliance advice. This article does not cover UK reimbursement rules or card-scheme requirements, which need separate, current guidance.
Conclusion
Adaptive fraud detection is an architecture problem more than a modelling one. Separating the decision layer from the models, closing the feedback loop with honest labels, budgeting latency and testing the fallback matter more than the choice of algorithm. Keep people in the loop, treat false positives as a customer outcome and settle data location early. As agent-initiated payments and new rails arrive, the signal set will widen, so build the loop to absorb new inputs without a rewrite.
