Real-time vs batch fraud detection

Teams evaluating fraud-detection systems often start by asking which is "better" — real-time scoring or batch analysis. The better question is which one matches how quickly your business can and must act.

What real-time scoring actually requires

Real-time fraud scoring means a decision — approve, decline, or queue for review — happens within the transaction's request-response cycle, typically under a few hundred milliseconds. That constraint shapes the whole architecture:

• Features have to be pre-computed or computable fast enough to fit the latency budget. You cannot run an expensive aggregation query against transaction history at request time.

• Models need to be simple enough, or served efficiently enough, to score within the time budget — this often rules out very large ensembles unless they are heavily optimised for inference speed.

• The system needs a fallback: if the scoring service is slow or unavailable, does the transaction fail closed (blocked) or fail open (approved)? That decision has to be made deliberately, not by default.

The payoff is that real-time scoring can stop fraud before it completes — declining a transaction, not just flagging it afterward.

What batch analysis is better at

Batch fraud analysis runs on a schedule — hourly, daily — over larger windows of data. It can afford more expensive computation: graph analysis to find linked accounts and devices, comparisons against longer transaction histories, and models that would be too slow to run inline. Batch is also where most new pattern discovery happens: analysts reviewing flagged clusters, unsupervised models surfacing anomalies that don't fit existing rules, and the results feeding back into what the real-time system should watch for next.

Most production systems use both

In practice, we rarely build a purely real-time or purely batch system. A typical architecture:

1. Real-time layer — hybrid rules and a fast model score every event as it happens, producing a risk score and reason codes within the transaction path.

2. Near-real-time enrichment — a slightly slower process (seconds, not milliseconds) adds context that was too expensive to compute inline, refining borderline cases before they reach an analyst queue.

3. Batch layer — periodic deeper analysis surfaces new patterns, evaluates model drift, and retrains or adjusts thresholds based on outcomes recorded since the last cycle.

The question that actually matters

Before choosing an architecture, we ask: what does the business do differently if a decision arrives in 200 milliseconds versus 20 minutes? For payment authorization, the answer is usually "stop the transaction" — which demands real time. For account-takeover investigation across a customer's history, the answer is usually "an analyst reviews it before acting" — which batch analysis serves well, and more cheaply. Building real-time infrastructure for a decision that doesn't need it adds cost and operational complexity without a corresponding benefit.