Fraud Detection 101

You swipe your card at a coffee shop. The terminal thinks for a second. Approved.

In that second, the card network routed your transaction to your bank, your bank pulled your purchase history, ran it through a scoring model, compared the merchant against known fraud patterns, checked your device fingerprint, and returned an approve or decline decision. The entire process typically finishes in under 100 milliseconds, often closer to 45.

If you've ever wondered how that decision gets made, and why your card occasionally gets declined at a restaurant you visit every week, this is where the engineering starts.

The constraint that shapes everything

A fraud detection system has one job: decide whether a transaction is legitimate before the money moves. After settlement, getting money back is slow, expensive, and sometimes impossible. So the system has to be right before the card terminal times out.

The full authorization round trip, from terminal to network to issuer and back, takes one to three seconds. But the issuer's decision window within that round trip is roughly 30 to 100 milliseconds depending on the payment rail. Network transit and routing consume the rest.

In that window, you need to retrieve information about the cardholder, run a model, and return a verdict. You can't query a data warehouse, you can't run a deep learning model with billions of parameters, and you can't wait for a human to review anything. The latency budget eliminates most of what you'd do with unlimited time.

This constraint is why fraud detection architecture looks the way it does. Every design decision, from how features are stored to which models are used to how thresholds are set, traces back to the fact that you have less time than a hummingbird's wing beat to decide.

Rules first, then models

The first fraud detection systems were entirely rule-based. An analyst would write conditions like "if the transaction exceeds $5,000 and the device is new and the merchant is in a high-risk country, decline it."

Rules work well for known fraud patterns. They're fast to deploy, easy to audit, and simple to explain to a regulator. When you know exactly what you're looking for, a rule catches it reliably every time.

But fraud evolves. A rule written for last quarter's attack pattern doesn't catch this quarter's variant. Fraudsters test rules by running small transactions until they map the boundaries, then stay just inside them. A $4,999 transaction from a known device in a low-risk country sails through the rule above.

Machine learning models address this by learning patterns from historical data rather than relying on manually specified conditions. You give the model a dataset of past transactions labeled as fraudulent or legitimate, and it learns the statistical patterns that separate the two. A subtle shift in transaction timing, an unusual sequence of balance checks before a large transfer, a device fingerprint that appeared on three other accounts last week. These patterns are invisible to rules because no analyst thought to write a condition for them.

Most production systems use both. Rules act as guardrails for high-confidence fraud, like a transaction from a sanctioned country or a stolen card number on a known blocklist. ML models handle everything else, scoring each transaction on a continuum from clearly legitimate to probably fraudulent.

The class imbalance problem

In a typical payment system, roughly 6 out of every 10,000 transactions are fraudulent. That's a fraud rate of about 0.06%, or 6 basis points of transaction volume.

A model that labels every single transaction as legitimate would be 99.94% accurate. It would also catch zero fraud.

Your training data contains overwhelmingly more examples of legitimate behavior than fraud. The model has thousands of examples of what normal looks like and a handful of examples of what fraud looks like.

Think of it like a restaurant kitchen where the head chef is training a new cook to spot spoiled ingredients. The kitchen processes 10,000 ingredients per day. Six of them are spoiled.

The new cook can pass the test by approving everything, because 9,994 out of 10,000 times, the ingredient really is fine. But those six spoiled items make people sick.

Teams address class imbalance through several techniques: oversampling fraudulent examples in the training data, undersampling legitimate ones, using cost-sensitive loss functions that penalize missed fraud more heavily than false alarms, and continuous manual review that generates more labeled fraud data over time. None of these fully solve the problem. They just make the model pay attention to the rare class.

Features are the real work

A fraud model is only as good as the data it receives. The raw transaction, amount, merchant, timestamp, tells you almost nothing on its own. A $500 purchase at an electronics store could be fraud or a birthday gift. Without context, the model can't tell the difference.

Features are the context. They transform raw transaction data into signals the model can learn from. How many transactions has this card made in the last hour? What is the distance between this transaction's location and the last one?

How does this transaction amount compare to this cardholder's 90-day average? Each of these questions becomes a numeric input the model can weigh.

The features that matter most in fraud detection measure deviation from a specific customer's baseline. A $200 transaction at a gas station is normal for someone who drives to work every day. The same transaction is unusual for someone who lives in Manhattan and hasn't bought gas in two years.

Building these features under a latency constraint is the hardest engineering problem in fraud detection. You need the cardholder's behavioral history available in single-digit milliseconds, which means precomputing and storing it in a feature store that serves queries at cache speed. The feature computation pipeline runs in near real-time, ingesting events as they happen and updating each customer's profile continuously.

If the features your model sees in production differ from the features it trained on, even slightly, your model's accuracy silently degrades. This is called training-serving skew, and it's the most common source of fraud model failure in production.

False positives cost more than fraud

Every fraud system makes two kinds of mistakes. A false negative lets fraud through, while a false positive blocks a legitimate transaction.

False negatives are obvious and costly. You lose the money, you eat the chargeback, and the customer has a terrible experience. But false positives are worse at scale, and they're harder to see.

Roughly 2 to 3 percent of all card transactions are declined on suspicion of fraud. About 30 percent of those declines are false positives, legitimate purchases caught by an overly aggressive system. A Javelin study found that the number of consumers affected by false declines is three times greater than those affected by actual card fraud.

The downstream impact compounds. About two-thirds of cardholders who experience a false decline reduce or stop their patronage of the merchant. They don't complain to the fraud team. They just leave.

So the fraud team is playing a tradeoff game. Tighten the model and you catch more fraud but block more good customers. Loosen it and you let more customers through but miss more fraud.

The optimal threshold depends on the business. A luxury retailer with high margins can tolerate more fraud to avoid losing a $10,000 customer. A prepaid debit card with thin margins can't absorb the losses.

This tradeoff is why accuracy is the wrong metric for fraud models. Precision (what fraction of your declines are actually fraud) and recall (what fraction of actual fraud you catch) tell you how the model is spending its error budget. A model with 95% recall and 10% precision catches almost all fraud but blocks ten legitimate transactions for every fraudulent one it stops. A model with 60% recall and 80% precision misses more fraud but barely touches good customers.

Real-time versus batch

Not all fraud detection happens in the authorization window. Some patterns are invisible at the individual transaction level and only emerge when you look at a day's worth of data at once.

Real-time scoring happens during authorization. Each transaction gets a fraud score before the payment completes. This is where the latency budget matters and where the feature store earns its cost.

Batch analysis runs on a schedule, usually overnight. It looks across the day's transactions for patterns that single-transaction scoring can't catch: a network of accounts that all transferred money to the same destination, a slow account takeover where small test transactions preceded a large fraudulent one, or a shift in a customer's spending pattern that only becomes visible over several days.

Production systems use both. Real-time scoring handles the authorization decision. Batch analysis catches organized fraud, updates the risk profiles that the real-time models consume, and generates the labeled data the models need for retraining.

The boundary between the two is blurring. Streaming architectures that process events as they arrive can detect multi-transaction patterns in near real-time instead of waiting for the nightly batch. But the core tension remains: the faster you need to decide, the less information you have when you decide.

Where this gets deeper

This article covers the fundamentals, but the constraints compound from here. Latency budgets force you to choose between model accuracy and response time. AML monitoring generates thousands of alerts per month, 95% of which are false positives, and compliance teams spend more time closing noise than catching crime.

Every layer adds constraints, and the engineering challenge is building systems that work under all of them at once.