Fraud Detection — Notes

Functional

• Real-time score for payments, logins, signups.
• Step-up auth on risky flows.
• Manual review queue.
• Feedback loop from chargebacks.

Non-functional

• p99 < 100 ms decision time.
• False positive rate watched closely (each FP is friction).
• Models retrained at least daily.

Capacity

• 10k+ events/s peak.
• Feature store reads: ~10× per event.

Data model

• events(id, user_id, type, amount, device, ip, ts)
• features(user_id, k, v, window) Redis / FS
• decisions(event_id, score, action, reason_codes[])
• labels(event_id, label, source, ts) ground truth

Trade-offs

• Rule engine vs ML: rules are explainable + fast to add; ML is more accurate. Combine.
• Latency budget forces feature pre-compute & caching.
• Bias / fairness matters for high-impact decisions.

Refs

• Stripe Radar architecture talks.
• Uber's fraud detection blog.
• "Feature stores at scale" (Tecton, Feast).
• ByteByteGo "Design fraud detection".