Why Insurance Fraud Rings Are a Graph Problem (And Your SQL Database Can't See Them)

Your fraud team is good at catching individuals. A claimant whose story shifts, a receipt that looks altered, someone who files a bit too often. That's what the rules were built for, and they work.

They're nearly blind to organised fraud — and organised fraud is where the money goes.

The reason isn't that your team lacks skill or your rules lack sophistication. It's that you're asking a question your database structurally cannot answer.

What a fraud ring actually looks like

A ring isn't one bad claimant. It's a network: a handful of claimants, a couple of "witnesses", a repair shop, a medical clinic, a few bank accounts, some phone numbers, and a device or two — recombined across dozens of claims over months.

Take any single claim from that ring and it looks fine. The claimant has no history. The damage is plausible. The repair estimate is in range. Nothing trips a rule, because the rule is examining one claim in isolation, and in isolation the claim is clean.

The fraud is only visible in the relationships between claims. And relationships are precisely what your claims database is worst at.

Why SQL can't see it

Relational databases are superb at aggregates. "How many claims over ₹5 lakh in Maharashtra last quarter?" — trivial.

Now ask: "Show me every entity within four hops of this claimant — shared phone numbers, shared bank accounts, shared repair shops, shared devices, shared addresses — and tell me if that cluster has an abnormal claim density."

In SQL that's a self-join, four deep, across several tables, with no idea in advance which path matters. It's brutal to write, slower still to run, and you have to guess the depth ahead of time. So nobody runs it — not because it's forbidden, but because it's impractical enough that it never gets prioritised.

Meanwhile that same question is a single, fast traversal in a graph database. It's not that graphs are magic; it's that connectedness is a first-class citizen instead of an expensive afterthought.

The economics that make rings visible

Here's the insight the whole approach rests on, and it's about fraudster economics rather than technology.

Fraudsters reuse infrastructure, because not reusing it is expensive.

Fabricating a claim is cheap — especially now that generative AI produces convincing damage photos in seconds. But a genuinely fresh identity every time? A new bank account, new phone, new device, new complicit repair shop, per claim? That's costly and slow. So they don't. They recycle.

That recycling is the signature. You cannot see it in the claim — the claim is designed to look clean. You see it in the graph, where the same bank account quietly appears across nine unrelated claimants.

This is also why graph analysis holds up as image fakery improves. A deepfaked photo defeats a pixel inspector. It does not fabricate a plausible four-hop network of corroborating relationships. Carriers deploying graph-based detection well report fraud detection improving by over 30% — that's the mechanism behind the number.

What you need to build one

1. Entities, not rows. A graph needs nodes: person, policy, claim, vehicle, property, phone, email, bank account, device, repair shop, clinic. Most carriers have these scattered as columns across systems, never as things in their own right. Extracting them is most of the work.

2. Entity resolution — again. Yes, again. If "R. Kumar" and "Rajesh Kumar" are two nodes, your graph is disconnected exactly where the fraud lives. Everything comes back to the customer key.

3. Edges from real signals. Shared phone. Shared account. Same device fingerprint. Same address. Named as witness. Serviced by the same shop. The edges *are* the product; get them wrong and you'll surface noise.

4. Population-level baselines. A cluster of five claims sharing a repair shop is meaningless if that shop handles 4,000 claims a year. Interest lives in abnormal density, which means you need the normal to compare against.

5. Real-time at FNOL. A ring detected after payout is expensive analytics. The traversal has to run while the claim is being triaged — which means the graph must be fed continuously, not rebuilt monthly.

The honest caveats

Graphs surface leads, not verdicts. A dense cluster is a reason to investigate, never a reason to deny. Two neighbours sharing a repair shop after the same hailstorm is a cluster and entirely innocent. Treat output as a queue for humans.

False positives are the risk. Small towns, family households, and popular garages all create legitimate density. Tune against real investigated cases or you'll bury your SIU in noise and they'll stop trusting the tool.

It's a data project first. You don't buy a graph database and get fraud detection. You get an empty graph. The work is the entity extraction, the resolution, and the pipeline feeding it — the database is the last 10%.

Where to start

Don't model your whole business. Pick one line — bodily injury or auto is where organised fraud concentrates — and build a graph with five node types and four edge types. Run it against last year's known fraud cases. If the rings light up in data you already have, you have your business case and your tuning set at once.

Your fraud team isn't missing rings because they're not looking. They're missing them because you've handed them a tool that can only see one claim at a time — and rings, by definition, don't live in one claim.

We build the entity resolution, graph pipelines, and real-time data foundations behind insurance fraud detection. More at IntelliBooks.