Knowledge Graphs Beyond Fraud

When insurers talk about knowledge graphs, the conversation almost always turns to fraud — connecting claimants, devices, and repair shops to surface rings. That's a genuine and valuable use, and it's the one everyone reaches for first.

But it undersells what a graph is for. Fraud is one application of a much broader capability: representing the fact that everything in insurance is connected to everything else, and being able to reason about those connections. Most insurers are leaving the larger prize on the table because they filed "knowledge graph" under "fraud tool."

Why insurance is a naturally connected domain

Step back and look at what an insurer actually manages. A customer holds multiple policies. Each policy covers people, vehicles, or properties. Policies are sold through brokers, who belong to brokerages. Claims connect to policies, to third parties, to repair shops and medical providers. Reinsurance treaties connect to the policies they cover. Products relate to other products, coverages to exclusions, endorsements to base policies.

It's a dense web of relationships. And relational databases — which is what nearly everything runs on — are structurally poor at relationships. They're built for rows in tables, and every relationship is a join you have to know to write in advance. Ask a question that traverses several relationships and it becomes a query nobody wants to write and the database struggles to run.

A knowledge graph makes the relationships first-class. Connections are the primary thing, not an afterthought reconstructed through joins.

Applications well beyond fraud

The real customer 360. A graph naturally represents a customer connected to all their policies, claims, interactions, and relationships — including household and business connections. "Show me everything about this person and everyone connected to them" is a graph's native question, and it's the customer view insurers keep failing to build in relational systems.

Aggregate risk and accumulation. Your true exposure to a single event depends on how risks connect — properties in one area, businesses in one supply chain, lives in one location. A graph traverses these connections to reveal accumulations that are invisible when risks sit in separate rows. This is a graph problem that most insurers currently answer with spreadsheets and hope.

Product and coverage modelling. The relationships between products, coverages, exclusions, endorsements, and regulatory requirements are exactly that — relationships. A graph can model coverage logic and answer "what exactly is covered in this specific situation?" in a way tangled relational structures make painful.

Distribution intelligence. Brokers, agents, agencies, and their production and performance form a network. Graph analysis reveals patterns in distribution — influence, concentration, relationships — that flat reporting misses.

Subrogation and recovery. Recovery is fundamentally about relationships between parties, liability, and claims. A graph surfaces recovery opportunities and connections a claim-by-claim view can't see.

Reinsurance and treaty management. Which treaties cover which policies, how recoveries flow, where the connections run — naturally graph-shaped, and painful in tables.

Why it's underused

It's pigeonholed as a fraud tool. The first success was fraud, so it got categorised there, and the broader applications never got sponsored.

It requires the same foundation as everything else. A graph is only as good as the entities and relationships in it. If you can't resolve that two records are the same customer, your graph is disconnected exactly where it matters. Entity resolution — the recurring prerequisite — is doubly critical here, because a graph makes the cost of unresolved identity visible as a broken connection.

It's a different skillset. Graph databases, query languages, and modelling differ from the relational world most insurance data teams live in. That learning curve slows adoption.

The value needs imagination. Fraud has an obvious dollar value. "Model your business as a connected whole" requires seeing the applications, which is harder to put in a business case even though the payoff is larger.

How to think about it

You don't replace your relational systems with a graph. You add a graph layer for the questions that are fundamentally about relationships — and route the right questions to the right tool. Aggregations, transactions, and reporting stay relational. Connection-traversal questions — accumulation, customer networks, coverage logic, recovery, distribution — go to the graph.

Start where the relationship value is highest and the data is most available. For many, that's still fraud — fine, start there. But build it as a general graph of your business, not a single-purpose fraud tool, so the same investment extends to accumulation, customer 360, and the rest.

The bigger point

Insurance is one of the most connected businesses there is — people to policies to claims to third parties to providers to reinsurers, all interlinked. Running it on technology that treats relationships as an expensive afterthought means a whole class of questions stays effectively unanswerable, and gets answered instead with spreadsheets, tribal knowledge, and guesses.

Knowledge graphs aren't a fraud feature. They're a way to model your business as what it actually is: a network. Fraud was just the first place the network paid off.

We build knowledge graphs, entity resolution, and the connected data foundations behind them. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Straight-Through Processing: From 10% to 90%

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more