Scaling Fraud Scoring From Thousands to Millions of Transactions a Day

What breaks first

Not the decision logic — the infrastructure underneath it. As volume climbs from thousands to millions of transactions a day, the first thing to strain is the feature store's read latency under load, then the throughput of whatever streams feature updates in, then the analyst review queue overflowing if the soft-hold band doesn't shrink relative to volume. The three-tier decision shape — auto-allow, auto-block, soft-hold — holds; what has to scale is what serves each tier.

The feature store scaling path

A single Redis instance handles a serious amount of real-time feature serving, but there's a real crossover point where entity-keyed sharding, and eventually a dedicated horizontally-scaled feature-serving layer, becomes necessary rather than optional. That's a named trigger — sustained read latency creeping toward your decision budget under peak load — not a guess about when to invest.

The event log rarely bottlenecks first

An event-streaming platform like the one behind our fraud-scoring project has enormous throughput headroom — publicly cited benchmarks put a small cluster's write capacity in the millions of events per second — so the durable log is usually not what limits you. It's almost always the consumers reading off it that strain first: the feature-update jobs, the retraining pipeline, the audit-reconstruction queries.

The LLM layer becomes a cost line, not just a latency one

Running a reasoning-layer call on every single transaction is a cost that scales linearly with volume. At real scale, that line item gets large enough that invoking it only on the grey-band cases — where the boosted-tree baseline is genuinely uncertain — becomes a real requirement, even in a deployment that could afford to run it on everything at lower volume.

The analyst queue has to shrink as a percentage

If the soft-hold band stays a fixed percentage of transactions as volume grows, headcount grows linearly with the business — an unsustainable scaling path. This is where model calibration and confidence-threshold tuning stop being purely an accuracy exercise and become a scaling lever: a better-calibrated model needs a narrower uncertain band to hit the same false-positive rate, which is a direct headcount saving.

A worked example

A business growing from two hundred thousand to twenty million transactions a month notices its soft-hold review queue backing up — the percentage of transactions landing in the ambiguous band hasn't changed, but the absolute volume has grown thirty-fold and the review team hasn't. Recalibrating the model's confidence thresholds narrows the soft-hold band enough to cut the queue back to a manageable size at the new volume, without materially changing the false-positive or fraud-catch rate — the fix is in the threshold, not in adding headcount at the same pace as the business.

What doesn't need to change

The core decision architecture — score, route to one of three tiers, log the outcome, feed it back into training — holds from thousands of transactions a day to millions. What scales is the infrastructure serving each stage, not the shape of the decision itself. That stability is worth designing for early, even at low volume, so the growth path is an infrastructure problem later rather than a rearchitecture.

Where this stops being right

• A business that will never scale past moderate volume — the infrastructure investment described here isn't worth making preemptively.
• A workload with very different peak patterns (extreme seasonal spikes rather than steady growth) needs capacity planning around the peak, not just the average.
• Real numbers matter more than these examples — the exact latency and throughput figures cited here are industry-reported benchmarks for illustration, not a guarantee for any specific deployment; validate against your own load.

FAQ

What's the first thing that breaks as fraud-scoring volume grows? Usually the feature store's read latency under load, before the event log or the core decision logic become the bottleneck.

Does the three-tier routing architecture need to change at scale? No — the decision shape holds. What scales is the infrastructure serving each tier, particularly the feature store and the analyst queue capacity.

Why does the LLM reasoning layer need selective invocation at scale? Because its cost scales linearly with volume — running it on every transaction is affordable at low volume but becomes a real cost line at millions of transactions a day, which is why grey-band-only invocation becomes necessary.

ISTRALLEN designs fraud-scoring architectures that scale from thousands to millions of transactions without a rearchitecture — see AI for Fintech.