Real-Time Fraud Detection Architecture for FinTech: Rules, ML, and Human Review

Introduction

Fraud detection is a latency-sensitive decision system with asymmetric error costs.

Block a legitimate transaction → customer churns and complains on social media. Approve a fraudulent one → chargebacks, regulatory scrutiny, and direct losses. The architecture must score risk in under 100ms on the payment hot path while supporting deep investigation on the slow path.

Most early-stage FinTech stacks start with hardcoded rules. That works until attack patterns evolve daily and rules become an unmaintainable nest of if statements. The production pattern is a layered risk engine: fast rules → ML score → action → async enrichment → analyst review.

Section 1: The Decision Pipeline

Payment request
  → Feature fetch (< 20ms)
  → Rules engine (< 10ms)
  → ML model score (< 50ms)
  → Action: approve | challenge | decline
  → Async: enrich case, notify analyst if needed

Actions

Approve: proceed to payment provider,
Challenge: step-up auth (3DS, OTP, device verification),
Decline: block with reason code (logged, not always shown to attacker),
Review: allow with hold (payout products) or queue for manual decision.

Section 2: Feature Engineering

Real-time features from:

velocity (transactions per hour per card/device),
device fingerprint and session age,
geolocation vs billing address distance,
merchant category risk,
historical chargeback rate for merchant or user segment.

Feature store

Pre-compute rolling aggregates (Redis, DynamoDB) updated on each event. Payment path reads features—does not compute heavy aggregations synchronously.

Section 3: Rules vs ML

Layer	Strength	Weakness
Rules	Explainable, fast to deploy for known attacks	Brittle, high maintenance
ML	Adapts to patterns	Needs labels, harder to explain to regulators

Production systems use both: rules catch known fraud rings instantly; ML catches novel patterns. Document model versions and feature sets for audit.

Section 4: Analyst Workflow

High-risk cases need a case management UI:

timeline of user actions and device signals,
linked accounts (graph analysis),
action buttons: confirm fraud, whitelist, escalate,
immutable audit of analyst decisions.

Engineering must support feedback loops: analyst labels become training data.

Section 5: Observability and Tuning

Track:

false positive rate (challenged/declined legitimate users),
false negative rate (fraudulent approved—via chargebacks),
p95 decision latency,
rule hit rate (which rules fire most),
model score distribution drift.

Review weekly with risk team. A rule firing 40% of traffic is probably too aggressive.

Section 6: PCI and Data Boundaries

Keep card PAN out of your fraud feature pipeline where possible—use tokenized references from payment provider. Scope fraud infrastructure separately from card data environment when PCI segmentation applies.

Conclusion

Fraud architecture is a real-time decision system with a human backstop. Separate the hot path (milliseconds) from investigation (minutes to hours), and measure false positives as seriously as fraud losses.