Design a Fraud Analytics Engine

Problem statement

Design a fraud analytics engine that ingests payment transactions and behavioral events from many sources, computes risk in flight, returns an allow, hold, review, or decline decision inside the authorization window, and simultaneously preserves every fact needed to train better models tomorrow. The brief requires multi-source ingestion, real-time risk scoring and decisioning, historical data for offline training, and feedback loops with manual review. It also demands low-latency classification, scalability to millions of transactions daily, explainable audit trails for regulators, and thresholds that adapt as fraud patterns shift.

The defining tension is speed versus learning. The inline path has roughly 100 milliseconds to assemble hundreds of features and score a transaction while the card network waits. The learning path has days to months: chargebacks arrive 30 to 120 days after the transaction, analyst verdicts arrive in hours, and models must be retrained, evaluated, and promoted without regressions. A weak design treats these as one pipeline; a strong design separates the decision plane, the analytics plane, and the learning plane, and defines exactly how labels, features, and thresholds flow between them.

Why this is a big-data problem, not just an ML problem

Fraud is a needle in a haystack where the needle fights back. Base rates are 0.1 to 1 percent of volume, labels are delayed and noisy, adversaries adapt within days of a new rule shipping, and a single hot card or compromised merchant can generate correlated bursts. The engine therefore needs: a replayable event backbone; streaming feature computation with exactly-once semantics; a low-latency feature store; a model and rule ensemble with champion-challenger governance; graph analytics for fraud rings; a case management and label pipeline; and an immutable audit trail because regulators will ask, months later, why transaction T was declined.

Public operating baseline versus design assumptions

Public evidence shows the category is real and huge. Visa reports on the order of two hundred billion payment transactions per fiscal year and advertises VisaNet capacity near 65,000 transactions per second, with Visa Advanced Authorization scoring transactions inside the authorization round trip. PayPal has publicly reported roughly 1.5 to 1.6 trillion dollars of annual payment volume and tens of billions of payment transactions, with fraud losses historically around a third of a percent of volume. Feedzai and Featurespace publish that they score billions of interactions per year for banks at sub-100ms budgets. These are company-reported figures, not requirements for our fictional platform.

For capacity planning this answer explicitly assumes: 40 million payment transactions per day, 400 million behavioral events per day, a 5x peak multiplier, 250 million tracked entities, a 100ms p99 inline budget, and 13-month event retention. Unless a number is tied to a citation, it is a stated design assumption.

The three architectural planes

1. Decision plane: ingestion, streaming features, online feature store, rule engine, model ensemble, decision orchestrator, and the synchronous verdict API.
2. Analytics plane: case management, investigator workbench, graph ring detection, dashboards, and regulator-grade audit and explainability exports.
3. Learning plane: label reconciliation with delayed chargebacks, point-in-time correct training sets, model training, evaluation, champion-challenger promotion, threshold adaptation, and drift monitoring.

A strong interview answer keeps these planes separate, lets the analytics plane degrade without slowing the decision plane, and never lets the learning plane silently change production behavior without gated promotion.