Fraud Detection: The Model Is the Moat

A fraud detection model trained on your own loss curves is the only durable moat in payments. Generic fraud APIs are useful for a single merchant under nine figures of volume. At portfolio scale they become a tax on revenue that you cannot tune and cannot inspect. This post is about why that happens, and what the alternative looks like when you operate it yourself.

What generic fraud APIs are actually optimizing for

Stripe Radar, Sift, Riskified, and the rest of the category are good products. They are not bad. The problem is structural. A vendor fraud API is optimizing for an aggregate metric across thousands of merchants. Your traffic is one input among many, and the model weights are tuned to minimize loss across the entire customer base.

That works fine when your traffic looks like the average. It stops working the moment your traffic stops looking average, which happens to every consumer business that grows past a certain size. Your customer base develops a personality. Your buying patterns drift away from the median merchant. The model that protects everybody equally well stops protecting you specifically.

The false-positive cost

Fraud teams talk about chargeback rate. They almost never talk about false-positive rate, because the customers you wrongly decline do not file complaints with you. They go to a competitor. The cost shows up in conversion rate dashboards owned by a different team, who blame the checkout flow.

A two percent false-positive rate on a $400M book is $8M of declined revenue from customers who would have paid. Even if you recover half of those through retry flows, you have left $4M on the table to prevent a smaller amount of fraud loss. The math only works if your fraud loss prevented exceeds your false positives plus your operational overhead. Generic APIs cannot show you this number for your specific traffic, because they do not measure it the way you would.

What changes when the model is yours

First-party signals dominate

A vendor fraud API sees the transaction. Your own model sees the transaction plus everything that happened before it. Time on the product page. Cart edits. Login behavior across the client's product surface. Whether this customer has interacted with related properties in the prior months. Device fingerprint patterns across products that share infrastructure but not a brand.

These first-party signals carry more predictive weight than any single transactional feature. The reason vendor APIs cannot use them is not technical. It is structural. They do not have permission to see what the operator's other surfaces see, and the operator would not give it to them if they asked. The shared signal across the client's own surface is the asset that cannot be rented.

Consortium data is real, and incomplete

Consortium data, where merchants share negative signals about known bad actors, is genuinely useful. It is also incomplete. The fraud rings that target consumer subscription businesses adapt within weeks of being added to a consortium list. Adversarial fraud is a moving target. There is a reasonable body of academic work on this, including a useful overview at arxiv.org on adversarial machine learning in fraud detection, which lays out why static rule sets degrade quickly against motivated attackers.

The right way to use consortium data is as one feature among many. It is not the model. The model is the part that knows what your good customers look like.

Loss curves train themselves

Every chargeback you receive is a labeled training example. Every successful authorization is also a labeled example. A model trained on your own labels, refreshed continuously, gets better at your specific traffic in a way no vendor model can match, because the vendor is averaging across labels that are not yours.

This is the part that compounds. After three years of running our own model, the marginal value of each new training example is small but the model is unrecognizable from where it started. After ten years, the model is the moat. A new entrant in your category can buy a Sift subscription on day one and be roughly competitive with where you were on day one. They cannot buy your last decade of labeled traffic.

Where vendors still win

Honest operators acknowledge what they cannot do alone. A vendor fraud API sees fraud rings before you do, because the same actor hits twenty merchants in a week and the vendor sees all twenty. Your own model only sees the one transaction that hit you. For genuinely novel attack patterns, the vendor wins on detection time.

We address this by running a hybrid. Our own model owns the decision. Vendor signals feed in as features. When a vendor flags a transaction we do not, we log the disagreement and review it in batch. Over time the disagreements get rarer, because our model learns from the cases where the vendor was right. The hybrid approach is more expensive than either pure option, and worth it.

How Hitpixel engineers this

The fraud stack we build for clients runs as part of the payment gateway described on our technology page. It scores every authorization in under 40 milliseconds, draws on transactional history across the client's product surface, and feeds back chargeback labels nightly. The model is retrained weekly. Specific architecture details are not public for obvious reasons, but the principle is simple. The decision that determines who is allowed to pay should not be outsourced to a vendor with no skin in the game.

The opinion: if your fraud strategy is "we use Stripe Radar and it is fine," you are at a stage where that is the correct answer. If your fraud strategy is the same answer at a $200M book, you are leaking money in two directions and you cannot see either of them. The model has to be yours, eventually. The question is whether you start building before or after the leak gets large enough to fund the team that fixes it.