Stripe Radar: the anti-fraud neural network decides in under 100 ms and wrongly blocks just 0.1% of legitimate payments

• How we built it: Stripe Radar — Stripe Engineering Blog (Ryan Drapeau), 2023-03-29
• A primer on machine learning for fraud detection (стоимость фрода >$20 млрд, precision/recall, +20% YoY, retrain +0,5 п.п./мес) — Stripe (официальный гайд)
• Stripe Radar — Payment and Credit Card Fraud Detection ($1,9 трлн/год, 197 стран, 92% карт знакомы сети, −32% фрода) — Stripe (страница продукта)

Background

Stripe is payments infrastructure for millions of businesses: per the product page, the Stripe network processes more than $1.9 trillion in payments a year across 197 countries. Radar is its ML fraud-protection system embedded directly in the payment flow: it scores the risk of every transaction before it is confirmed and requires neither a separate integration nor an in-house anti-fraud team from the merchant.

Radar's key structural advantage is the data network effect. Card fraud is a game of incomplete information: an individual online store sees only its own transactions and knows almost nothing about a card appearing for the first time. The Stripe network sees hundreds of billions of dollars in payments annually, so an 'unfamiliar' card usually turns out to be familiar: Stripe's ML anti-fraud guide cited an estimate of 90% of cards having been seen by the network before, while the current product page says 92%. For the model this means a rich signal history where a standalone merchant faces a cold start.

In March 2023 Radar engineer Ryan Drapeau published 'How we built it: Stripe Radar' on the Stripe engineering blog — an unusually candid account of a production ML system's evolution over almost seven years: from logistic regression to a pure deep neural network, with specific numbers on accuracy, latency, the cost of errors, and training time. That post is the case's primary source; we supplement it with Stripe's official machine-learning-for-fraud guide and the Radar product page.

Problem

Roughly 1 in 1,000 payment attempts is fraudulent. That sounds small, but the economics of errors here is asymmetric and painful in both directions. Missed fraud turns into a chargeback: the merchant loses the transaction amount, pays a dispute fee, and with a rising dispute rate faces higher network fees and operational costs; per the estimate in Stripe's guide, fraud costs businesses more than $20 billion annually.

The opposite error — falsely blocking an honest buyer — hits not the 'fraud losses' line but revenue and loyalty: in a survey Stripe cites, 33% of consumers said they would not shop with a business again after a false payment decline. An anti-fraud system that blocks 'just in case' quietly strangles its customers' sales — which is why precision (what share of what you block is actually fraud) matters as much as recall (what share of fraud you catch).

The execution context adds hard constraints. The decision must be made at checkout, inside the payment flow, in a fraction of a second — without adding friction for the buyer. And the adversary adapts: fraud patterns shift constantly, with attackers deliberately probing the model's weaknesses. A model retrained once a day by an overnight job chronically lags the attackers by a day — and in anti-fraud a day can be expensive. Hence the system's second, less obvious quality metric: iteration speed — how fast the team can train, validate, and ship a new model version.

Solution

Radar evaluates more than 1,000 characteristics of every transaction — from the card's country and the number of countries it was used in over the past day to the IP address and merchant embeddings — drawing on signals from the whole Stripe network. The architecture evolved in steps, each answering a specific limitation of the previous one.

It started with logistic regression — simple, fast, interpretable. Then came decision trees and gradient boosting: XGBoost is good at 'memorizing' specific fraud patterns. The next step was a Wide & Deep ensemble — XGBoost (responsible for memorization) combined with a deep neural network (for generalization). That hybrid ran in production for several years, but it had a ceiling: XGBoost scales and parallelizes poorly, slowing both training and experimentation.

Since mid-2022 Radar has run on a pure deep neural network with no XGBoost — a multi-branch structure inspired by the ResNeXt architecture from computer vision. An honest detail from the post: XGBoost could not simply be dropped — that would have cost 1.5% of fraud recall. The team offset the dip by scaling: an experiment with a 10x increase in training transaction data delivered a significant quality gain, and at publication time a 100x version was in the works. Additional directions include transfer learning, embeddings, and multi-task learning.

The new architecture's main operational win is iteration speed: model training time fell by over 85%, to under two hours. Instead of an overnight job, the team can retrain and ship the model several times a day, responding to new attack patterns the same day. Per Stripe's guide, even plain regular retraining on fresh data adds up to half a percentage point of recall per month — over time one of the cheapest sources of quality.

A separate track is interpretability. Deep neural networks are 'black boxes' to a greater degree than trees, and for a payment system that is a trust problem: merchants need to understand why a payment was blocked. Back in 2020 Stripe shipped risk insights — a feature showing which transaction factors drove the risk score. A rules layer runs on top of the scoring: merchants can set their own thresholds and logic (for example, block when P(fraud) exceeds a threshold), combining the ML score with business policies.

Result

Radar makes a decision on every payment in less than 100 milliseconds — inside the payment flow, before the transaction is confirmed. Out of billions of legitimate payments on Stripe, the system incorrectly blocks just 0.1% — the key product guarantee: anti-fraud that does not strangle honest customers' revenue. Each architecture jump (regression → trees → the Wide & Deep ensemble → a pure DNN) brought a significant lift in detection quality, and the DNN migration cut training time by over 85%, to under two hours, turning retraining from an overnight job into a several-times-a-day operation.

The effect keeps compounding: per Stripe's guide, new models improve Radar's ML performance by more than 20% year over year, and the current product page claims an average 32% fraud reduction for customers and training on over a trillion dollars of annual payment volume. Note the bounds: 0.1% false blocks and <100 ms are figures from the March 2023 engineering post; 92% 'familiar' cards and −32% fraud are marketing data from the 2026 product page; none of these values are independently audited, and the methodology behind the 'average fraud reduction' is not disclosed.

In our view, the case's main value is its honestly displayed engineering economics of trade-offs. Deciding to drop the ensemble for iteration speed, knowing it costs 1.5% recall, and offsetting the loss with data scale is mature ML engineering: the team evidently judged that the ability to answer attackers the same day is worth more over time than a fixed percentage of recall. In anti-fraud, where the adversary adapts, the system's learning speed is not an operational metric but a combat characteristic.

Our second observation: the case demonstrates the power of an infrastructure position. The data network effect (92% of cards already known to the network) is an advantage that an individual merchant or a niche anti-fraud vendor cannot replicate in principle. The same fact argues for caution when reading the numbers: a payments aggregator has both the motivation and the means to present statistics in the most favorable light, so product percentages should be read as orders of magnitude, not audited reporting.

Lessons learned

1. The key anti-fraud metric is not just fraud caught but false blocks: a 0.1% false positive rate protects customers' revenue; 33% of buyers never return after a false decline.
2. Iteration speed is quality in itself: cutting training from an overnight job to under 2 hours lets you answer new attacks the same day.
3. Simplifying the architecture (dropping the ensemble for a pure DNN) is acceptable only if the quality dip (−1.5% recall) is offset by scaling data and the model.
4. Regular retraining is the cheapest source of quality: per Stripe, fresh data adds up to 0.5 pp of recall per month with no architecture change.
5. The data network effect is the competitive edge of ML anti-fraud: 92% of cards are already known to the Stripe network — a standalone merchant can never assemble that history.
6. Explainability is a product requirement, not a luxury: risk insights exist precisely because merchants must understand why a payment was blocked.
7. An engineering blog with specifics (latency, recall, training time) is the gold standard of evidence for an ML system — but read marketing percentages from product pages as orders of magnitude.

Frequently asked questions