US insurance fraud alone is estimated at $308.6 billion a year. The engineering lesson from two decades of fighting it: detection quality is set by the data you join, not the model you pick.
The Coalition Against Insurance Fraud estimates fraud costs the United States $308.6 billion every year — a figure so large it works out to a four-digit annual tax on the average family's premiums. Numbers at that scale attract vendors, and vendors attract model-first thinking: buy the classifier, catch the fraud. Two decades of deployments say the causality runs the other way. The teams that catch fraud are the ones that solved their data problem first; the model on top is almost interchangeable.
Know what you are detecting
"Fraud" is at least four different engineering problems wearing one name.
- Application fraud: lying at purchase — a mismatched address, a hidden driver, a misdeclared business activity. Detected at quote time, in milliseconds.
- Claims exaggeration: a real loss, inflated. Detected at claim time with document and pricing analysis.
- Organised fraud: staged accidents, provider rings, ghost brokers. Detected across claims, via networks, over months.
- Distribution fraud: fake policies, commission gaming, premium diversion in the sales channel itself.
Each has different data, different latency budgets and different costs of being wrong. A roadmap that says "add AI fraud detection" without naming which of these it means is not a roadmap.
The unglamorous core: entity resolution
Organised fraud is invisible at the level of a single claim and obvious at the level of a graph — the same phone number across nine claimants, the same workshop behind fourteen repairs, the same device fingerprint opening accounts. Building that graph means resolving entities across systems that spell names differently, storing histories long enough to matter, and joining data under privacy rules that were written for good reasons. This is 80% of the engineering and 0% of the conference talks. Skip it and the fanciest model sees only isolated, innocent-looking dots.
Precision is a customer-experience budget
Every false positive is a legitimate customer investigated, delayed or declined. At insurance volumes, a model that flags 2% of claims with 20% precision buries investigators and punishes honest claimants. The operational discipline that works: models score and route — a high score buys a human look, never an automatic decline — and thresholds are set by investigation capacity, not by the ROC curve's vanity point. Fairness follows the same pipe: score distributions need monitoring across customer segments, because proxies for geography and income creep into fraud features with ease.
What embedded distribution changes
Embedded journeys shrink the space for application fraud — identity is verified by the platform, and the insured asset comes from transaction data rather than self-declaration; you cannot misdeclare the car when the marketplace sold you the car. The risk moves to the seams: synthetic accounts on the platform side, and distribution-level gaming where volume incentives exist. Which returns to the thesis — the defence is joined data. A platform's account-age, device and transaction signals joined to policy and claims history is a fraud dataset neither side owns alone, and building the lawful, minimal version of that join is exactly the kind of dull, decisive engineering this discipline rewards.
If you are building this
Start with one typology and one metric (money recovered or loss avoided, not "flags raised"). Spend your first quarter on identifiers, joins and history — not on models. Put a human in every loop that touches a customer outcome. And when a vendor demo opens with the model, ask to see the entity resolution instead. The answer will tell you everything.