How an Online Feature Store Works for Real-Time Fraud Scoring

The component that eats the latency budget

Score a transaction for fraud before it completes, and most of your few-hundred-millisecond budget goes to one place: fetching the features. That's why a feature store is the centre of a real-time fraud detection design — it exists to serve behavioural and velocity features in single-digit milliseconds and to guarantee that training and serving compute them the same way.

What a "feature" is here

The signals that actually catch fraud are rolling-window aggregates over recent history, keyed by entity:

• Transactions attempted on this card in the last 1 / 10 / 60 minutes.
• Distinct cardholders this device fingerprint has been seen with this week.
• Geo-velocity — is the implied travel speed between the last two transactions physically possible?
• "Seen before" flags for the card, device, IP, shipping address.

None of these can be computed from the single transaction in front of you. They need history, pre-aggregated and ready to read.

Offline and online: one definition, two paths

A feature store defines each feature transformation once and serves it two ways:

• Offline store — for building training sets. Large historical joins, run in batch, with point-in-time correctness: each label joins to feature values as they were at that moment, not as they are now.
• Online store — for live scoring. The same features, keyed by entity, served from an in-memory store (Redis-style) in single-digit milliseconds.

The streaming path

The online store stays current from a streaming pipeline: the transaction event log feeds a streaming aggregation layer that updates the online store keyed by card, device, account, IP. On our fintech fraud-scoring project that event log is also retained for compliance replay and future retraining — the same stream serving multiple consumers rather than each one getting its own feed.

Train/serve consistency is the point, not the speed

The failure this design prevents is subtle and expensive: the model learns on one definition of "24-hour velocity" in training and scores against a slightly different one in production. The result is a model that validates well and behaves worse live, and it's notoriously hard to diagnose after the fact. A feature store closes that gap by construction — training-time and serving-time features come from the same definition.

Why fraud specifically needs freshness

Fraud is shaped to exploit the gap between a batch snapshot and the live transaction. A card-testing script against a stolen card list generates a burst in minutes; a velocity feature refreshed nightly has been irrelevant for the whole attack window by the time it updates. Features reflecting live behaviour, not a snapshot, is close to the entire reason for adding behavioural signals.

Staleness tolerance, on purpose

Plan for the online store being slow. A sensible design accepts features up to N seconds old, flagged as stale, rather than blocking the score on a fresh read. A slightly stale feature is usually better than a timeout in the authorization path.

Where this stops being right

• You may not need real-time at all. If your flow allows review-and-clawback — some marketplace payouts, some payment types — an asynchronous scoring pipeline is far cheaper than a streaming stack and an online store.
• Low volume. Query-time joins against live tables, or a managed feature store, beat building one for a few thousand transactions a day.
• Multi-region. Replicating an online store across regions with acceptable consistency is its own project — scope it separately.
• Outgrowing the in-memory store. Very high throughput or feature counts push you toward a dedicated, horizontally scaled feature-serving platform.

FAQ

Do we need a dedicated feature-store product? Not necessarily. You need the properties — fast online reads, and identical training/serving computation. A managed platform gives you those; so can a well-built pipeline over infrastructure you already run.

Redis or a "real" feature store? An in-memory store like Redis is a common backing for the online layer because of its read latency. The feature-store layer on top is what gives you train/serve consistency.

How fresh is fresh enough? Fresh enough that a card-testing burst updates velocity features within seconds, not hours. Exact tolerance depends on your attack profile.

ISTRALLEN builds real-time feature pipelines for fintech fraud teams — streaming aggregation, online serving, and train/serve consistency as one system; see AI for Fintech.