Fraud detection is a race measured in milliseconds, and in 2026 the architecture that wins it is conversational, real-time, and grounded in governed data. In this second part of our series on real-time fraud detection architectures, we look at how financial institutions are moving from batch scoring to streaming decisioning, what the architecture actually looks like in production, and why the fastest systems are also the most explainable.
What does "real-time" actually require in fraud detection?
In fraud detection, "real-time" is not a single number — it is three different deadlines attached to three different decisions, and conflating them is the most common architectural mistake in the domain.
The first deadline is authorisation scoring: the decision on whether to let a payment or transaction proceed. This is hard-bounded by the payment rail, typically 50 to 300 milliseconds end to end, including network transit. Miss it and the transaction times out, which is itself a business decision — usually a decline, with the customer consequences that follow.
The second is step-up and intervention: deciding whether to challenge the customer with an additional factor, hold the transaction for review, or contact them. This has seconds to minutes, and it is where most of the achievable loss reduction actually lives, because it allows a decision better than the binary approve-or-decline.
The third is investigation and feedback: confirming whether an alert was genuine, feeding confirmed fraud labels back into the model, and updating entity-level risk. This has hours to days, and it is the one most organisations under-invest in — which is why models degrade even when the architecture is sound.
Designing for one deadline and hoping it covers the other two produces a system that is simultaneously too slow for authorisation and too shallow for investigation. The correct approach is three decoupled paths sharing a common feature store and a common entity graph, each optimised for its own latency budget.
How fast is fast enough?
The instinct is to minimise latency everywhere. That is usually the wrong objective, because the marginal value of speed is highly uneven across the decision surface.
For authorisation, the budget is set externally. The useful question is not "how fast can we go?" but "how much of our budget is spent on what?" A typical breakdown: 10–20 ms on network and serialisation, 10–30 ms on feature retrieval, 10–50 ms on model inference, and the remainder on rules evaluation and decision assembly. The largest controllable cost is usually feature retrieval, which is why the feature store design matters more than model choice.
For step-up decisions, speed matters less than decision quality. An extra two seconds to run a richer model, query a device-intelligence provider, or check a consortium signal is nearly always worth it if it avoids a false decline. False declines are expensive in a way that is easy to underestimate: industry estimates consistently put the cost of a wrongly declined transaction at several times the value of the transaction itself, once lost future revenue and support cost are included.
For investigation, speed matters least and quality matters most. This is where you can afford graph analysis across the full entity network, analyst tooling, and human review. Optimising this path for latency is wasted effort; optimising it for analyst throughput and label quality is not.
A practical heuristic: measure the 99th percentile, not the mean. A mean latency of 40 ms with a p99 of 900 ms will breach the authorisation budget on exactly the traffic you can least afford to fail — peak volumes, when fraud attacks also tend to cluster.
Why is the feature pipeline harder than the model?
Teams consistently underestimate the feature layer and overestimate the model. In practice, moving from a gradient-boosted baseline to a more sophisticated architecture typically yields a single-digit percentage improvement in detection at constant false-positive rate, whereas fixing feature freshness or consistency commonly yields more.
The core difficulty is the training-serving skew. Features computed in batch for training, then recomputed slightly differently at serving time, produce a model that behaves differently in production than in validation. The divergence is often subtle — a window boundary off by a few seconds, a null handled differently, a timezone applied inconsistently — and it manifests as unexplained degradation months later. The only reliable defence is computing features with the same code path in both contexts, which in practice means a feature store with shared transformation logic.
The second difficulty is temporal correctness. Fraud features are almost all aggregates over time windows — count of transactions in the last hour, sum of value in the last 24 hours, time since last device change. If the aggregate includes events that occurred after the scoring moment, you have introduced label leakage that will produce spectacular offline results and disappointing production performance. Point-in-time correctness is not optional, and it is not something most general-purpose data tools provide by default.
The third difficulty is entity resolution. Fraud is committed by networks, not by accounts. Effective features require linking accounts to shared devices, addresses, payment instruments, and counterparties — and maintaining that graph with low latency as new events arrive. This is a graph problem, not a table problem, and it is where much of the real engineering effort in mature systems ends up.
How should scoring, rules, and machine learning be combined?
The framing "rules versus machine learning" is a false choice. Production fraud systems use both, in a layered design, because they fail in complementary ways.
Rules are precise, explainable, and immediately adjustable. They are the right tool for hard constraints — regulatory blocks, known-bad lists, velocity limits that must never be exceeded — and for responding within hours to a newly identified attack pattern. Their weakness is that they are brittle: attackers reverse-engineer thresholds, and rule sets accumulate until they contradict each other.
Models generalise, capture interactions that no analyst would hand-code, and degrade gracefully. Their weakness is latency, opacity, and the fact that they cannot be patched quickly when a novel attack appears.
The standard production pattern is: rules first for hard blocks; then a model score; then a decision layer that combines the score with business policy, risk appetite, and customer value into an action — approve, step-up, hold, or decline. Then a rules layer after the model to catch policy overrides and to implement the emergency responses that cannot wait for a retrain.
Two design details matter more than they appear to. First, score calibration: a raw model score is not a probability of fraud, and treating it as one produces incoherent thresholds. Calibrate, and recalibrate regularly, because the base rate drifts. Second, champion–challenger: always run the candidate model in shadow alongside the incumbent, scoring live traffic without acting on it, so that you can compare on the same distribution before switching.
What does a reference architecture look like?
A workable reference architecture has six components, and the boundaries between them matter more than the specific technologies.
Event ingestion. A durable, ordered log of every transaction and customer event, retained long enough to rebuild features. This is the system of record for everything downstream, and it should be append-only.
Streaming feature computation. Incrementally maintained aggregates over sliding windows, written to a low-latency online store. This is what makes sub-100 ms scoring possible without recomputing history at request time.
Offline feature store and training pipeline. The same transformations applied to historical data with point-in-time correctness, producing training sets that match what the online path will compute.
Entity graph service. Maintains and queries relationships between accounts, devices, instruments, and counterparties, and exposes graph-derived features — cluster size, distance to a known-bad entity, shared-attribute counts.
Scoring service. Stateless, horizontally scalable, with the model loaded in-process and a hard latency budget enforced by timeout. It must degrade safely: if a feature is unavailable, the system should fall back to a documented default rather than fail open.
Decision and case management layer. Turns scores into actions using business policy, routes holds to analysts, and — critically — captures analyst outcomes as labels that flow back into training.
The failure mode to design against is a missing feedback path. Systems that capture decisions but not outcomes accumulate no labels, and a fraud model without fresh labels is a model that is quietly becoming obsolete from the day it is deployed.
How do you handle model drift and adversarial adaptation?
Fraud is adversarial, which makes it categorically different from most machine learning domains. In a recommender system, drift is a nuisance. In fraud, drift is the opponent's strategy.
Attackers probe. They test small transactions to find thresholds, they shift to new channels when one is locked down, and they adapt to whatever signal the model relies on most heavily. This means two things operationally. First, monitor for adaptation, not just degradation: watch the distribution of scores near the decision boundary, watch for clustering in feature space, and watch for a rising rate of transactions that are just below threshold. Those are fingerprints of probing.
Second, retrain on a cadence short enough to matter. Quarterly retraining is too slow against an adaptive opponent; weekly or continuous retraining with recent confirmed labels is the norm in mature systems. This is only possible if the label pipeline is fast, which brings the argument back to investigation throughput — the constraint on model freshness is usually how quickly analysts confirm cases, not how quickly you can train.
There is also a strategic dimension worth naming. Because a model's weak points are discoverable, diversity of signal is a defence. Systems that rely heavily on one strong feature — device fingerprint, velocity, behavioural biometrics — are brittle in a way that systems combining many moderate signals are not. Deliberately maintaining signal diversity, and occasionally acting on a weaker signal so that attackers receive misleading feedback, is a real technique rather than a theoretical one.
How do you measure whether the system is working?
Fraud metrics are unusually easy to game, including unintentionally. A system that declines everything has perfect detection and zero value. Measure the set, never a single number.
The core operating metrics are detection rate at a fixed false-positive rate, false-positive rate measured as alerts per thousand transactions, false-decline rate on legitimate customers, and fraud loss rate as a share of transaction value. Track the first two together, because improving one in isolation is trivial and meaningless.
The economic metric that actually matters is net value: fraud prevented, minus fraud losses realised, minus the cost of false declines, minus operating cost including analyst time. Optimising detection alone reliably reduces net value, because the marginal transaction declined to catch one more fraudster is almost always a legitimate customer.
Two secondary metrics catch problems early. Alert precision — the share of alerts that turn out to be genuine fraud — tells you whether analysts are wasting time, and low precision is the leading cause of analyst attrition in fraud operations. And time-to-detection for a new attack pattern tells you how adaptive your system really is; it is the number that distinguishes a system that works from one that used to work.
Report these segmented by channel, product, and customer cohort. Aggregate numbers hide the fact that a model performing well overall is performing badly for a specific segment, which is both a fraud exposure and a fairness exposure.
What are the most common implementation mistakes?
Optimising the model before the features. Teams spend months on architecture search and weeks on feature engineering, which is close to the inverse of where the value is.
Leaking the future. Aggregate features computed over windows that include events after the scoring moment. This produces a model that looks excellent offline and underperforms in production, and it is often discovered only after deployment.
Treating the model as the product. Building sophisticated scoring and neglecting case management, label capture, and analyst tooling. The result is a system that cannot learn, because nothing feeds confirmed outcomes back into it.
Declining instead of stepping up. Using a two-action design when a four-action one is available. Step-up authentication and holds recover a substantial share of transactions that a binary system simply loses.
Failing open. When a feature service times out, defaulting to approve. The correct behaviour is a documented, tested fallback that errs toward the action the business can absorb — and for high-value transactions, that is rarely a silent approval.
No adversarial testing before launch. Deploying without simulating an attacker who has partial knowledge of the system. Red-teaming a fraud model before release, including attempts to reverse-engineer thresholds, is cheap relative to the first month of live exploitation.
What Are the Key Takeaways on Real-Time Fraud Detection?
Real-time fraud detection is three deadlines, not one — authorisation, intervention, and investigation — and they need decoupled paths over shared features and a shared entity graph.
- Design to the p99 latency your payment rail allows, and spend the budget where it is controllable: feature retrieval, not model inference.
- Invest in the feature layer before the model: shared training/serving code paths, point-in-time correctness, and entity resolution are where the returns are.
- Combine rules and models in layers — rules for hard constraints and emergency response, models for generalisation, policy for the final action.
- Treat drift as adversarial: monitor for probing near the decision boundary, retrain on recent labels, and keep signal diversity deliberately.
- Measure net value, not detection rate, and always pair detection with false-positive and false-decline rates.
- Close the feedback loop: capture analyst outcomes as labels, or the model starts decaying the day it ships.
