How Stripe's Fraud Detection (Radar) Actually Works — And Why You Can't Just Clone It
A technical breakdown of Stripe Radar's fraud detection stack, why the ML model isn't the hard part, and what it would really take to compete with it.
The part everyone gets wrong: it's not the model
Every engineer who looks at Stripe Radar assumes the hard part is the gradient-boosted model scoring transactions 0-100 for fraud risk. It isn't. Gradient boosting on tabular data is a solved problem — you could stand up an XGBoost pipeline in an afternoon with public libraries. Stripe has published enough about Radar to know the model family isn't exotic: it's mostly boosted trees, some deep learning for specific signals, trained on labeled outcomes (chargebacks, disputes, confirmed fraud).
The hard part is the data the model eats. A model is only as good as its features, and Radar's features come from a network Stripe has been building since 2011: hundreds of thousands of merchants, billions of transactions, and — critically — the labels that come back weeks or months later when a chargeback finally posts. You cannot clone a fraud model. You can only clone the shape of one. Cloning the data pipeline underneath it is a different order of problem entirely.
Where the signal actually comes from
Radar's edge is cross-merchant pattern matching. A card that just got declined for velocity abuse on a sneaker resale site five minutes ago is a red flag on a SaaS checkout page you've never seen before — and Radar knows this because it sees both transactions. This is the network effect in its purest form: every merchant on Stripe makes every other merchant's fraud detection better, and a new entrant starts with zero of that signal.
Beyond network-level card and device fingerprints, Radar leans on things a solo integration will never have: BIN (bank identification number) data licensed from card networks, device and browser fingerprinting via Stripe.js that runs before you even submit a payment, IP and geolocation heuristics, behavioral signals (typing cadence, mouse movement, how fast a form got filled), and historical merchant-category risk baked in from Stripe's underwriting data. None of this is a single clever algorithm — it's a decade of plumbing connecting dozens of data sources into one feature store.
The label problem: fraud has a 60-90 day delay
This is the detail that kills most fraud-detection side projects. Chargebacks don't arrive instantly — a cardholder disputes a charge weeks after it happened, the issuing bank takes its time, and Stripe often doesn't get a confirmed 'this was fraud' label until 60-90 days after the transaction. That means your training data is always stale, and you need infrastructure specifically built to handle delayed, partial, and sometimes contradictory labels (a chargeback reversed on appeal, a 'friendly fraud' claim that isn't really fraud).
Stripe solves this with a labeling pipeline that continuously backfills ground truth into training sets, re-weights recent transactions differently than confirmed ones, and runs shadow models against live traffic before anything gets promoted to production. If you're prototyping fraud detection with a Kaggle dataset and a weekend, you are not solving the problem Stripe solves — you're solving a toy version with clean, already-labeled data. Real fraud data is messy, adversarial, and lagged, and building the pipeline to handle that lag is 80% of the actual engineering effort.
Adversarial dynamics: the model has to keep moving
Fraud isn't a static classification problem — it's a moving target where the other side is actively trying to beat your model. Card testing rings automate thousands of small transactions to find live numbers; carders rotate through geolocations and device fingerprints; bad actors A/B test which merchant categories slip past which risk thresholds. A static model trained once and left alone degrades within weeks because attackers reverse-engineer its blind spots by trial and error, at scale, for free.
This means Radar isn't one model — it's a system of models retrained continuously, with rules layered on top for known attack patterns that don't yet have enough labeled data to be learned statistically, plus a team of humans watching aggregate metrics and hand-writing new detection rules when a new attack pattern emerges. This operational loop — detect, label, retrain, deploy, monitor, repeat, forever — is infrastructure and headcount, not a model file you download once.
What's actually cloneable here (and what isn't)
If you're evaluating this the way oneprompt does — technical cloneability versus business moat — fraud detection splits cleanly into two very different halves. The scoring pipeline, the API surface, the dashboard showing risk scores and lets you set custom rules — that's all buildable by a competent team with an AI coding tool in a reasonable timeframe. It's CRUD, a model-serving endpoint, and a UI. Nothing about Stripe.js device fingerprinting or a rules engine is conceptually novel; you could prompt your way to a working version in days.
What's not cloneable is the thing that makes the scores accurate: the network of merchants generating cross-pollinated signal, the years of labeled outcome data, the licensing relationships with card networks for BIN data, and the continuous adversarial arms race that only makes sense to run at Stripe's transaction volume. A fraud model trained on your own 10,000 transactions will be meaningfully worse than one trained on billions, structurally, no matter how good your engineers are. This is why fraud detection is one of the strongest moats in the payments stack — it's not defended by a patent or a trade secret algorithm, it's defended by data gravity that compounds with scale.
The honest verdict: build the shell, rent the brain
If you're building a payments product and think 'I'll just clone Radar,' the correct move is almost never to build your own fraud model from scratch. It's to use Stripe Radar, or a specialized fraud vendor like Sift or Signifyd, and spend your engineering time on the parts of your product that actually differentiate you. Rebuilding fraud detection in-house only makes sense once you have enough transaction volume and enough labeled fraud outcomes to out-data the incumbents — which for most companies is never.
This is the general pattern worth internalizing for any 'can I clone this' question: when a feature's value comes from an algorithm, it's cloneable. When its value comes from a dataset that only exists because of scale, and that dataset actively improves the algorithm's accuracy in a feedback loop, you're not looking at a feature — you're looking at a moat. Fraud detection is maybe the cleanest example of that distinction in the entire software industry.
Want the same teardown for any site?
Analyze a site →