How a fraud unit stops losing the same suspect across five separate records
A Nordic insurer's SIU resolves customer, claim, and case records scattered across underwriting, claims, and prior investigations. KnowledgeHub sits above them as a semantic layer that matches entities on evidence, not exact-string matches, with every match traceable to its source.
The same person, five times
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. A 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.
Re-architecting the workflow
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.
Inside the investigator's day
A new claim comes in. The system has already run it against the resolution graph before the investigator opens the file.
Three candidate matches are waiting, each ranked by strength of evidence: a closed claim with a shared bank account, an open policy with an overlapping address, and a prior investigation naming a related party. Each candidate shows exactly which fields matched, which didn't, and how confident the system is.
The investigator's job isn't to go looking for the connection. It's already surfaced, with its evidence attached. The job is to weigh it — is this genuinely the same person, or a coincidence the system was right to flag but wrong to conclude?
Confirmed matches join the case graph immediately, visible to anyone who opens that claim next. Rejected matches are logged too, with the reason, so the same candidate isn't re-flagged without new evidence.
What changed
Fewer missed connections is the visible benefit. A defensible reason for every connection — made or rejected — is the structural one.
Investigators spend less time manually cross-referencing systems that were never going to volunteer a match on their own. Supervisors reviewing a closed case see not just the outcome but the evidence trail behind every entity that was linked.
When a regulator or an auditor asks why two claims were treated as related, or why they weren't, the answer is a specific piece of evidence and a timestamp, not a investigator's recollection of a hunch.
“We stopped relying on someone remembering a name from six months ago. Now the connection is there, or it isn't, and we can show why.”
See how it works for your organisation
Request a confidential briefing — we show traceable retrieval and governance without exposing your data.