Design Stripe-style Fraud Detection

Fraud detection is the most latency-sensitive data pipeline most engineers will ever build, and it has a cruel twist: you must decide instantly, but you find out whether you were right months later. A card is swiped, and in under a tenth of a second you have to approve it or decline it, standing between a real customer's checkout and a criminal's stolen number. Then, thirty to ninety days on, a chargeback tells you the truth about a decision you made in milliseconds.

Stripe scores card payments in real time for exactly this. Raj, a data engineer there, gets the prompt: "design the data pipeline behind our fraud model." Not the model itself, the pipeline: how transactions flow in, how features are computed fast enough to matter, how the decision gets made inside the payment's latency budget, and how the slow drip of chargebacks becomes training data without corrupting it.

The two hard parts pull in opposite directions. The scoring path is brutally synchronous and fast. The learning path is glacially slow and, if you are not careful, biased by your own past decisions. This chapter is both.

Step 1 - Understand the Problem and Establish Design Scope

"Detect fraud" hides several systems. The clarifying questions separate the inline decision from the offline learning, and pin down the constraint that dictates everything: the latency budget.

Candidate: Is the fraud decision on the payment's critical path, or after the fact?

Interviewer: On the critical path. The score has to come back before we authorize the payment, so the customer is waiting on it. That is the defining constraint.

Candidate: What is the latency budget for the score?

Interviewer: The whole authorization has a tight budget, and fraud is one step in it. Assume you get under 100 milliseconds, p99, end to end for the fraud decision, including any feature lookups.

Candidate: What features does the model need, and how fresh?

Interviewer: A lot of them are behavioral and time-windowed: how many transactions this card made in the last minute, hour, and day; the amount versus its usual; distance from the last swipe; whether the device is new. Velocity features have to reflect the transaction that happened two seconds ago, or they miss exactly the burst that signals fraud.

Candidate: How do we learn whether a decision was correct?

Interviewer: Chargebacks, mostly. And they lag. A fraudulent charge might not be disputed for 30 to 90 days. So ground truth arrives months after the decision.

Candidate: What is the fraud rate? I ask because class imbalance shapes the whole learning side.

Interviewer: Well under 1% of transactions are fraud. Deeply imbalanced.

Candidate: Two things I want to confirm are in scope: what we do when a feature lookup is slow or missing at decision time, and making sure a retried payment does not get scored twice differently.

Interviewer: Both in scope. You never get to stall the payment waiting for a feature, and a transaction must get exactly one decision.

With that, the requirements are clear.

Functional requirements

• Score every card transaction for fraud risk inline, returning an approve/decline (or step-up) decision on the payment path.
• Compute behavioral, time-windowed features (velocity, recency, amount deviation, device newness) that reflect events from seconds ago.
• Make a decision even when a feature is slow or unavailable; never block the payment on a lagging lookup.
• Ingest delayed labels (chargebacks, confirmed fraud, disputes) and assemble training data from them.
• Feed decision outcomes back into model retraining.