Real-Time Fraud Detection Architecture for Fintech: A Build Guide

Fraud detection is one of the few systems in a fintech stack where the cost of a wrong decision cuts both ways. Miss a fraudulent transaction and you eat the loss and, eventually, the chargeback. Block a legitimate one and you have taught a good customer that your product is unreliable. The engineering problem is not "catch fraud." It is "decide, in the auth path, in single-digit milliseconds, with an explanation you can defend to a regulator."

This post is the fraud-detection guide under our pillar on AI engineering for fintech. It is aimed at founders and CTOs about to build or rebuild a fraud system who want to understand the moving parts before committing to an architecture. The engineering-services view lives at AI fraud detection development; this is the how-it-fits-together version.

Why real-time is the hard constraint

A batch fraud model that scores yesterday's transactions overnight is a useful analytics tool and a useless control. By the time the batch runs, the money has moved. Real-time detection means the decision has to happen inside the transaction lifecycle, ideally at authorisation before the transaction is captured, which imposes constraints that shape every downstream choice:

• Latency budget. If your scoring engine adds more than a few tens of milliseconds to the auth path, it degrades conversion for every good customer to catch the small fraction who are fraudulent. Sub-100ms end to end is a reasonable target for a card-present-style flow.
• Availability. A fraud engine that goes down cannot take payments down with it. You need a defined fail-open or fail-closed posture per transaction type, and it should be a product decision, not an accident of how the timeout was configured.
• Feature freshness. The most predictive signals (velocity, device reputation, behavioural patterns) are only useful if they reflect the last few seconds, not the last few hours. That pushes you toward a streaming architecture rather than periodic feature recomputation.

The reference architecture

The shape that works in production is a streaming pipeline with a fast scoring layer in front and an investigation layer behind. Reduced to its stages, it looks like this:

Transaction Stream → Real-time Scoring Engine → Decision (allow / review / block) → Investigator UI → Audit Log → Regulator Reporting

1. The transaction stream

Transactions land on a durable, replayable log: Kafka, Kinesis, or Pub/Sub. Durability matters for two reasons beyond throughput: you can replay the stream to backfill features when you add a new signal, and you have an ordered record of what the system saw, which is the foundation of a defensible audit trail. Do not let the scoring path read from your primary transactional database; couple through the stream so a scoring outage never contends with your ledger.

2. The scoring engine: rules and ML, not rules or ML

The most common mistake here is treating this as a religious choice. Rules and models solve different problems and belong together:

• Rules encode known-bad patterns and hard policy: sanctioned countries, velocity thresholds, block-lists. They are instant, auditable, and changeable by a risk analyst without a retrain. They also fail in predictable ways, which regulators like.
• Models catch the patterns nobody has written a rule for yet: the subtle combinations of device, behaviour, and network signals that separate a real customer from a well-prepared fraudster.

A hybrid engine runs rules first (cheap, deterministic, can short-circuit) and passes anything that survives to a model that produces a calibrated risk score. The output is not a binary; it's a score plus the reasons that drove it.

3. The three-way decision

The single most valuable design decision is refusing to make fraud a binary allow/block. A three-way outcome, allow, step-up/review, block, lets you route ambiguous transactions into a friction layer (a step-up challenge, a hold, a manual review) instead of forcing a false accept or a false decline. Most of your fraud lift comes from getting the middle bucket right.

4. Feature engineering that survives production

Features are where fraud models earn their keep, and where they quietly rot. A few principles that hold up:

• Compute velocity and aggregate features in the stream, not at query time. "Transactions from this device in the last 60 seconds" needs to be a value you look up, not a query you run inside your latency budget.
• Separate the feature store from the model so you can add a signal (a new device-fingerprint provider, a new behavioural feature) without retraining from scratch.
• Version your features. When a decision is questioned six months later, you need to know exactly which feature values produced it.

5. Case management and the investigator UI

Every transaction routed to review needs somewhere to go. The investigator UI is a product in its own right: a queue, the full context behind each held transaction, connected-entity views for spotting mule networks, and a way for the analyst's decision to feed back as a label for the next model iteration. An investigation tool that does not capture the analyst's verdict in a training-usable form is throwing away your best data.

Explainability is an architectural requirement, not a feature

If your fraud system can block a customer's transaction, at some point a regulator, a partner bank, or the customer will ask why. "The model said so" is not an answer that survives that conversation. Build per-decision explainability in from the start:

• Each decision carries per-feature importance (SHAP or an equivalent) and a human-readable rationale.
• Every decision (allow, review, or block) writes an immutable audit-log entry: the inputs, the score, the model version, the rules that fired, and the outcome.

This is the same discipline that adverse-action reasoning requires on the lending side, and it is a running theme across fintech AI: the explanation is a first-class output of the decision, not documentation you add later. Pressure-test whether your logging holds up with our audit trail validator.

Handling drift before it costs you

Fraud is adversarial. The distribution of attacks shifts the moment attackers notice a control, so a model that was accurate at launch degrades on a timescale of weeks. Bake in:

• Drift detection on both feature and score distributions, alerting when today's traffic stops looking like the training data.
• Scheduled retraining pipelines rather than heroic manual retrains.
• Shadow / A-B evaluation of any new model against the current production control before promotion; you never swap the model guarding live money on a hunch.

Where compliance intersects

Two standards touch almost every fraud build. Card data handling falls under PCI DSS: architect so raw card data never lands where it does not need to. And because you are profiling and making automated decisions about people, GDPR / UK GDPR obligations around lawful basis, retention, and automated-decision rights apply to your scoring signals and case records. Fraud detection also lives next door to KYC/AML: the sanctions screening, identity signals, and SAR data collection often share infrastructure, so design the two together rather than bolting them on later.

How to sequence the build

If you're starting from zero, resist the urge to lead with a sophisticated model. A pragmatic order:

1. Stand up the stream and the three-way decision path with a rules-only engine. This alone stops a meaningful share of obvious fraud and gives you labelled data.
2. Build the investigator UI and start capturing analyst verdicts.
3. Introduce a model trained on the labels you've now accumulated, running in shadow first.
4. Add drift monitoring and retraining once the model is live.

This ordering means you have a working, auditable control in production early, and every later stage is trained on data your own system generated rather than a borrowed dataset that doesn't match your traffic.

Talk to us

We've built the real-time scoring, investigator tooling, and audit trails that fintech fraud teams run in production. If you're standing up a new system, an embedded squad can ship alongside your team as attack patterns evolve; if you have an existing system you're unsure about, a tech audit is a focused diagnostic of its architecture, model health, latency, and audit-readiness. Either way, start on the AI fraud detection development page.