|  CASE STUDY · ENTITETSOPLØSNING · MATCH PÅ TVÆRS AF SILOER

Hvordan en svindelenhed holder op med at miste den samme mistænkte på tværs af fem forskellige journaler

Et forsikringsselskabs SIU-enhed sammenkører kunde-, skades- og sagsjournaler spredt på tværs af tegning, skadebehandling og tidligere undersøgelser. KnowledgeHub ligger som et semantisk lag ovenpå, der matcher entiteter på baggrund af dokumentation i stedet for eksakte tekststrenge. Hvert match kan spores tilbage til sin kilde.

01

Den samme person, fem gange

En SIU-efterforsker åbner en ny skadesag og kører standardtjekkene. Intet slår ud. Den skadelidtes navn er stavet en anelse anderledes i tegningsfilen. Adressen har to cifre byttet om i det ene system, men ikke det andet. En delt bankkonto ligger tre systemer væk, i en sag, der blev lukket for to år siden.

Intet af dette er skjult. Det er blot spredt ud over et policeadministrationssystem, en skadeplatform, et CRM og en mappe med tidligere undersøgelsesrapporter — hvert af dem sikkert i sin egen journal, uden kendskab til de andre.

Eksakte opslag fanger det ikke. En efterforsker, der vil fange det, skal allerede mistænke en forbindelse og derefter lede efter den system for system. De fleste har ikke tiden. Nogle forbindelser bliver aldrig fundet, før et mønster dukker op et andet sted, måneder senere.

Prisen er ikke kun overset svindel. Det er en svindelenhed, der ikke kan dokumentere, hvorfor to sager blev (eller ikke blev) behandlet som forbundne.

02

Arbejdsgangen gentænkt

Spørgsmålet er ikke, om dataene findes. Det er, om platformen kan vise, at det er den samme entitet, uden at nogen på forhånd skal vide det.

KnowledgeHub implementeres oven på de eksisterende systemer — policeadministration, skadebehandling, CRM og tidligere sagsakter bliver præcis, hvor de er. Hver kilde indlæses med lineage bevaret på journalniveau. En versioneret ontologi definerer, hvad der tæller som et match: delte identifikatorer, adresseoverlap, enheds-fingeraftryk, modpartsrelationer og tidligere skadehistorik.

Agenter får en snæver opgave: foreslå kandidatmatch, rangeret efter dokumentation, og hvert stykke understøttende dokumentation skal henvise til sin kildejournal. De sammenlægger ikke noget selv. En efterforsker gennemgår dokumentationen og godkender eller afviser matchet, før det bliver en del af sagsgrafen.

03

Efterforskerens hverdag

En ny sag kommer ind. Systemet har allerede kørt den mod entitetsgrafen, før efterforskeren åbner filen.

Tre kandidatmatch venter, hver rangeret efter styrken af dokumentationen: en lukket sag med en delt bankkonto, en åben police med en overlappende adresse og en tidligere undersøgelse, der nævner en relateret part. Hvert kandidatmatch viser præcis, hvilke felter der matchede, hvilke der ikke gjorde, og hvor sikkert systemet er.

Efterforskerens opgave er ikke at lede efter forbindelsen. Den er allerede fremdraget, med sin dokumentation vedhæftet. Opgaven er at veje den — er dette reelt den samme person, eller en tilfældighed, systemet havde ret i at markere, men tog fejl i at konkludere?

Bekræftede match kommer straks ind i sagsgrafen, synlige for enhver, der åbner den sag næste gang. Afviste match logges også, med begrundelsen, så det samme kandidatmatch ikke markeres igen uden ny dokumentation.

04

Hvad der ændrede sig

Færre oversete forbindelser er den synlige gevinst. En forsvarlig begrundelse for hver forbindelse, hvad enten den blev oprettet eller afvist, er den strukturelle.

Efterforskere bruger mindre tid på manuelt at krydstjekke systemer, der aldrig selv ville have foreslået et match. Supervisorer, der gennemgår en afsluttet sag, ser ikke kun udfaldet, men evidenssporet bag hver entitet, der blev koblet sammen.

Når en tilsynsmyndighed eller revisor spørger, hvorfor to sager blev behandlet som forbundne eller hvorfor de ikke blev, er svaret et specifikt stykke dokumentation og et tidsstempel, ikke en efterforskers erindring om en fornemmelse.

|  Mere fra denne branche

Relaterede use cases

|  Næste skridt

Let at gå i gang. Sikkert at stoppe.

Piloten kører til fast pris: Vi kortlægger arbejdsgangen, deployer i jeres miljø og beviser det på jeres egne sager. Derefter beslutter I.

Fast pris · Fast tidsramme

  1. 01

    Kortlæg arbejdsgangen

    To uger sammen med jeres medarbejdere, hvor vi dokumenterer, hvad der sker i dag. Også de dele, som ingen har skrevet ned.

  2. 02

    Deploy i jeres miljø

    Inde i jeres tenant, på jeres vilkår for dataplacering, uden eksport og uden at noget forlader systemet ad bagvejen.

  3. 03

    Bevis det under revision

    Kontrolleret evaluering op imod jeres egne sager, hvor compliance og procesejeren godkender, før løsningen går i drift.

  4. 04

    Kør i produktion

    Vi fortsætter med genoplæring, rapportering og løbende tilsyn, så længe arbejdsgangen er i drift.

Fast pris, Fast tidsramme. 8–12 ugers pilot: Fortsæt (Udvid, når I ved, at det virker) / Stop.