Design Fraud Detection
Fraud detection decides, during a payment, whether a transaction is honest or stolen. Wrong answers lose money in both directions.
The ask
A payment arrives and needs an answer at once. The service must allow it, decline it, or flag it for a person to check.
A risk score is a number that estimates how likely a transaction is fraudulent. Higher numbers mean higher risk.
The score must arrive while the buyer waits. A slow answer loses honest sales.
Both errors cost money. A missed fraud steals funds, and a false decline insults an honest buyer.
Estimate the scale
The service checks 100,000,000 transactions a day.
100,000,000 รท 86,400 = 1,157 transactions per second.
The decision budget is about 100 milliseconds. Feature lookup, scoring and the answer share that budget.
Fraud is rare. Suppose 1 transaction in 1,000 is fraudulent.
100,000,000 รท 1,000 = 100,000 fraudulent transactions a day.
Honest transactions still dominate the data. That imbalance shapes training and evaluation alike.
Data and features
Some features describe the transaction. Examples are amount, currency, merchant and time of day.
Other features describe the buyer and the card. Examples are account age, usual spending place and recent purchase count.
Behaviour features describe how the purchase was made. Examples are device, typing rhythm and the speed of the checkout steps.
Labels come from confirmed fraud reports. A confirmed case may surface weeks after the purchase.
A chargeback is a payment reversed after the card owner disputes it. The merchant loses the money and often the goods as well.
Chargebacks supply strong labels. They arrive late, so recent training data stays incomplete because of delayed labels.
High-level design
A transaction enters through the payment service. The fraud service is asked for a decision before money moves.
A feature lookup gathers stored facts about the card and the account. The lookup must finish inside the budget.
The model returns a risk score. Rules then map the score to allow, decline or flag.
Low scores pass at once. High scores are declined at once.
Middle scores are flagged for a person to check. That person can ask the buyer for proof before deciding.
Every decision is logged with its features and score. The log becomes training data when outcomes arrive.
Training the model
Training data joins transactions with later outcomes. A transaction waits until its dispute window has passed.
Fraud patterns change quickly. Criminals probe the defences and move to whatever passes.
Retraining runs often on recent complete data. Old patterns fade as new attacks replace them.
Rare fraud makes plain accuracy misleading. A model that allows everything looks accurate and catches nothing.
Training therefore weighs fraud cases heavily. Missing a fraud costs far more than one extra check.
Serving predictions
Serving keeps the model close to the payment path. Each extra network hop eats the decision budget.
Features are precomputed where possible. Counts of recent purchases wait in a fast store before any transaction arrives.
A fallback rule set covers model outages. Simple limits on amount and rate still block crude attacks.
The answer carries the score and the main reasons. Reasons help the person who checks a flagged case.
Deep dive: bot detection
Bot detection hunts automated buyers rather than stolen cards. Bots buy limited goods fast and resell them at a markup.
The same risk-scoring spine applies. The features change, and the decision changes with them.
Behaviour signals feed the score. Examples are typing rhythm, pointer movement, request timing and repeated device traits.
A high score earns a challenge instead of a decline. The challenge asks for a task that people pass easily and scripts fail.
An honest person who fails once can try again. A bot that fails at scale loses its speed advantage.
Evaluation and trade-offs
Offline evaluation counts fraud caught at a fixed false decline rate. Catching more by declining everyone is not progress.
The flag rate is set by review capacity. 1% of transactions are flagged for a person to check.
100,000,000 รท 100 = 1,000,000 reviews a day.
One reviewer clears 100 reviews a day.
1,000,000 รท 100 = 10,000 reviewers.
Strictness pulls against honest sales. Every tightened threshold catches some fraud and turns away some buyers.
Scale at a glance
| Measure | Value |
|---|---|
| Transactions a day | 100,000,000 |
| Transactions per second | 1,157 |
| Decision budget | about 100 milliseconds |
| Flagged a day | 1,000,000 |
| Reviewers needed | 10,000 |
Exercise
Why does a model that allows every transaction still look accurate?