|  CASE STUDY · AML · ESKALERING PÅ NIVEAU 2

Hvordan en AML-afdeling holder op med at briefe tilsynet med screenshots

En stor finansiel virksomhed samler AML-eskaleringer på tværs af systemer, der ikke taler sammen. KnowledgeHub ligger oven på dem som et semantisk lag, hvor alle søgeresultater har kildehenvisning, og hvor et menneske godkender hvert udkast.

01

Videnskløften

Dokumentationen findes. Problemet er at finde den og bevise den.

En AML-afdeling i en stor nordisk finansiel virksomhed har en proces, der virker — indtil den ikke gør. Reviewerne på niveau 2 er dygtige. Logikken bag alerts er solid. Risikotypologierne er velkendte.

Det, der svigter, er sammenstillingen.

Hver sagspakke til en alert kræver, at en reviewer åbner fire eller fem forskellige systemer: en platform til transaktionsovervågning, et CRM, et sagsbehandlingsværktøj, en sanktionsliste og et fællesdrev med PDF'er fra tidligere undersøgelser. De relevante passager er der. Men det tager timers manuelt arbejde pr. alert at samle dem til en sammenhængende fremstilling med kildehenvisninger — en fremstilling, som en supervisor kan godkende, og som en tilsynsmyndighed kan efterprøve.

Det dybere problem er herkomsten. Når en analytiker henviser til en kilde, bliver det ikke systematisk registreret, hvilken version af en politik eller et typologibibliotek der lå til grund for beslutningen. I dokumentationen kan en gennemgang foretaget under én ontologiversion ikke skelnes fra en gennemgang foretaget under en senere revision. Supervisorerne godkender beslutninger, de ikke fuldt ud kan spore.

02

Arbejdsgangen gentænkt

Spørgsmålet er ikke, hvordan arbejdet kan automatiseres. Det er, hvordan det kan gøres forsvarligt.

KnowledgeHub er implementeret som et semantisk lag oven på virksomhedens eksisterende systemer. Intet bliver udskiftet. Platformen til transaktionsovervågning, CRM'et og dokumentarkiverne bliver, hvor de er. Det, der ændrer sig, er fundamentet, der forbinder dem.

Hvert godkendt korpus — sanktionslister, tidligere sagsakter, politikdokumenter, uddrag fra CRM — indlæses med lineage bevaret på passageniveau. En versioneret ontologi definerer de semantiske relationer mellem entiteter, risikoindikatorer og regulatoriske begreber. Når ontologien opdateres, fordi en typologi ændrer sig, eller fordi en vejledning fra myndighederne bliver revideret, bliver ændringen logget, tidsstemplet og gjort sporbar.

Agenterne får konkrete, afgrænsede opgaver: at hente de relevante passager om en markeret entitet, at finde forbindelser til tidligere sager og at skrive udkast til sagspakkens beskrivende afsnit. Analytikerne gennemgår og godkender hvert udkast, før det går videre. Agenterne træffer ingen beslutninger. De samler dokumentationen og viser, hvordan de er nået frem til den.

03

Analytikerens hverdag

Alerten kommer ind. Søgningen går i gang med det samme.

Når en alert eskaleres til niveau 2, gennemløber systemet vidensgrafen: relationer mellem entiteter, transaktionsmønstre, tidligere SAR-indberetninger, sanktionseksponering og noter fra CRM. Resultatet er en rangordnet liste af passager med kildehenvisning, hver især mærket med kildedokument, tidspunkt for indlæsning og den ontologiversion, der klassificerede den.

Analytikerens opgave er ikke at finde dokumentationen. Den er allerede fundet, tilskrevet sin kilde og ordnet efter relevans. Opgaven er at vurdere den, rette den, hvor det er nødvendigt, og godkende.

Den sagspakke, der forlader analytikerens bord, har alle kildehenvisninger intakte. Supervisoren ser ikke kun fremstillingen, men også datasporet bag den. Compliance-funktionen kan genskabe retrieval-grafen måneder senere — samme forespørgsel, samme ontologiversion, samme resultat.

Det er det, forsvarligt betyder i praksis.

04

Hvad der ændrede sig

Hastigheden er den synlige gevinst. Herkomsten er den strukturelle.

Overdragelserne mellem teams fungerer bedre, fordi analytikerne vedhæfter en sammenhængende fremstilling med kildehenvisninger, når de overdrager en sag, i stedet for en note, hvor der står "se vedhæftede filer". Supervisorerne gennemgår sagspakkerne i stedet for at genskabe dem. Compliance-funktionen får en ny ressource: reproducerbar dokumentation af hver eneste retrieval-beslutning, knyttet til en bestemt ontologiversion.

Organisationen forbereder nu eskaleringer med retrieval-grafer, ikke med slides. Når en ekstern inspektør spørger, hvorfor en bestemt beslutning blev truffet, er svaret en kæde af kildehenvisninger. Ikke en samtale om, hvad nogen tror, de kan huske.

|  Udfald

Resultater i drift

Estimeret antal tværgående henvisninger med herkomst
621

pr. kvartal

Estimeret tid til første redegørelse med kildehenvisninger
113

dage

Estimeret antal dokumenter afstemt pr. reviewer-time
824

filer

|  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.