System Design

Fraud Detection

Design a real-time fraud detection system for payments like Stripe Radar.

Functional requirements

• For every payment attempt, the payment service calls the fraud service synchronously with the transaction details (amount, card token, IP, device fingerprint, merchant, email) and receives a decision: allow, block, or challenge (e.g., require 3-D Secure).
• Decisions combine a machine learning risk score with merchant-configurable rules (e.g., block if the card was used from more than 3 countries in the last hour, or always allow a trusted customer list).
• The service maintains velocity features over sliding windows, such as attempts and total amount per card, IP, device, and email over the last 1 minute, 1 hour, and 24 hours.
• Chargebacks and merchant-reported fraud arrive days to weeks later and are attached to the original decision as labels, so model and rule performance can be measured and new models trained.
• Merchants can review any decision with its score, the rules that fired, and the top contributing features, and can override it (allow a blocked payment, or refund one and mark it as fraud).

Non-functional requirements

• The decision is on the payment path: p99 under 100ms for the whole scoring call, with a hard timeout of 150ms after which the payment service applies a fallback.
• Availability of the payment path comes first: the fraud service must never make a payment fail because it is slow or down; a degraded decision (rules only, or a default) is returned instead, and every degraded decision is logged and measurable.
• Feature freshness: velocity aggregates reflect attempts made up to 2 seconds earlier for the same card or device (a fraudster's second attempt must see the first); during a partition features may be undercounted but never over-counted in a way that blocks a good customer.
• Every decision, the features it saw, the model version, and the rules that fired are logged durably and immutably for 7 years, so a decision can be reproduced when a chargeback arrives.
• Cost stance: a false positive (blocking a good payment) costs ~$100 in lost revenue and trust, while a missed fraud costs the chargeback amount plus fees (~$120 on average), so the block threshold is a per-merchant tunable, not a fixed value.

Scaling & constraints

• Peak of 20,000 payment attempts per second during sales events, ~4,000/sec average, across 500,000 merchants.
• Each decision reads ~200 features (~50 velocity aggregates across 4 entity types and 3 windows, plus ~150 slow-changing features about the card, merchant, and customer); a decision record with its features is ~4 KB, so ~1.4 TB of decision logs per day.
• Velocity counters are keyed by ~150M distinct cards, ~60M IPs, and ~120M device fingerprints seen in the last 24 hours; the hottest keys (a shared corporate IP, a bot's card list) see up to 500 attempts per second.
• Fraud is rare and delayed: ~0.2% of attempts are fraudulent, chargebacks arrive with a median lag of 25 days and a tail of 120 days, and ~20% of labels are noisy (friendly fraud).
• Models are retrained weekly and deployed several times a week; a model artifact is ~2 GB and inference takes ~5ms on a warm host.
• The service is called from 6 regions; a cross-region round trip is ~80ms, so a single centralized feature store cannot sit on the synchronous path for every call.

Out of scope

• Model training pipelines, feature engineering research, and label quality tooling.
• Chargeback dispute filing with card networks and representment.
• Identity verification and account takeover detection outside the payment path.
• The payment processing system itself (assume it calls this service once per attempt and honors the decision).