How a fraud unit stops losing the same suspect across five separate records

An SIU investigator opens a new claim and runs the standard checks. Nothing flags. The claimant's name is spelled slightly differently in the underwriting file. The address has a transposed digit in one system and not the other. A shared bank account sits three systems away, in a claim closed two years ago.

None of this is hidden. It is simply spread across a policy admin system, a claims platform, a CRM, and a folder of prior investigation reports — each one confident in its own record, none of them aware of the others.

Exact-match lookups don't catch it. An investigator who wants to catch it has to already suspect a connection exists, then go looking for it system by system. Most don't have the time. Some connections are never found until a pattern shows up somewhere else, months later.

The cost isn't just missed fraud. It's a fraud unit that can't say, with evidence, why two claims were or weren't treated as connected.

The question isn't whether the data exists. It's whether the platform can tell you it's the same entity without asking you to already know that.

KnowledgeHub is deployed above the existing systems — policy admin, claims, CRM, and prior case files stay exactly where they are. Each source is ingested with lineage preserved at the record level. A versioned ontology defines what counts as a match: shared identifiers, address overlap, device fingerprints, counterparty relationships, and prior claim history.

Agents are given a narrow task: propose candidate matches, ranked by evidence, with each piece of supporting evidence cited back to its source record. They do not merge anything. An investigator reviews the evidence and approves or rejects the match before it becomes part of the case graph.