False-positive-hygiëne bij sanctiescreening

Vraag een complianceanalist wat er mis is met hun screeningtool, en het antwoord is zelden "we missen dingen." Het is bijna altijd "we krijgen te veel alarmen, en de meeste stellen niets voor." Die klacht klinkt als een efficiëntieprobleem. Het is eigenlijk een risicoprobleem: OFAC's sanctie-aansprakelijkheid is strict — opzet en kennis zijn geen verweer — en een programma dat honderden laagwaardige alarmen per dag genereert, traint zijn eigen analisten om dingen snel af te doen, en dat is precies de conditie waaronder een echte match wordt doorgewuifd. False-positive-hygiëne is geen UX-leuktje. Het is een beheersmaatregel die bepaalt of de echte positieven in de stapel daadwerkelijk worden opgemerkt.

Waarom false positives ontstaan

De meeste false positives zijn terug te voeren op een klein aantal grondoorzaken, en die versterken elkaar:

• Veelvoorkomende namen. Namen in de trant van "Mohammed Ahmed" of "John Smith" leveren matches op tegen een aanzienlijk deel van elk klantenbestand, ongeacht enige echte connectie met het gesanctioneerde individu.
• Transliteratievariantie. Namen die vanuit het Arabisch, Cyrillisch of Chinees schrift naar Latijnse tekens zijn getranslitereerd, hebben meerdere geldige romaniseringen — "Gaddafi," "Qaddafi," en "Kadhafi" zijn dezelfde naam. Een matchingalgoritme dat is afgestemd op typefouten in Latijns schrift gaat hier anders mee om dan een algoritme dat is gebouwd voor variantie tussen schriftsystemen, en het verkeerde algoritme mist ofwel de echte variant, ofwel behandelt elke romaniseringskeuze als een near-match met alles.
• Zwakke of ontbrekende secundaire identifiers. Een hit die uitsluitend op naam is gebaseerd, zonder geboortedatum, nationaliteit, of nationaal ID-nummer om het veld te versmallen, kan het gesanctioneerde individu niet onderscheiden van een niet-verwante persoon die toevallig dezelfde naam draagt.
• Alias-wildgroei zonder sterkte-signaal. Aangewezen entiteiten dragen vaak tien of meer bekende aliassen — volledige naamsvarianten, eenwoordsbijnamen, eerdere bedrijfsnamen. Een dunne, eenwoordsaka met hetzelfde matchinggewicht behandelen als een sterke, unieke alias verhoogt het aantal hits tegen iedereen wiens naam toevallig dat fragment bevat.

De spanning, in gewone taal

Elke hefboom die false positives vermindert, kan ook false negatives verminderen als hij te ver wordt doorgetrokken. Dat is de hele moeilijkheid van dit probleem: een fuzzy-matchingdrempel die strak genoeg is aangedraaid om te stoppen met het flaggen van "John Smith" tegen elke klant die John Smith heet, is ook een drempel die een echte, net gemiste transliteratie ongeflagd kan doorlaten. Afstemmen op een rustige wachtrij en afstemmen op verdedigbare dekking zijn niet hetzelfde doel, en een programma dat alleen meet dat "alarmen per dag" daalt, heeft geen manier om te bepalen welk van de twee het daadwerkelijk heeft bereikt. Elke inspanning om false positives te verminderen moet aantonen — en kunnen bewijzen — dat de recall op echte matches niet is veranderd.

Concrete technieken

1. Match op meer dan de naam. De enkele verandering met de hoogste hefboomwerking is het gebruiken van elke identifier die een bron daadwerkelijk publiceert — geboortedatum, geboorteplaats, nationaliteit, paspoort- of nationaal ID-nummer, en voor schepen, het IMO-nummer, dat veel onderscheidender is dan een scheepsnaam. Een match op naam alleen tegen een veelvoorkomende naam is nauwelijks bruikbaar; dezelfde naam plus een geboortedatum versmalt het veld met ordes van grootte, in beide richtingen — het zuivert niet-verwante naamgenoten en verhoogt het vertrouwen bij een echte match. Dit is waarom de bronnencatalogus precies vermeldt welke identifiers elke lijst publiceert: twee bronnen met dezelfde nominale dekking kunnen zeer verschillende matchbaarheid hebben, afhankelijk van welke velden de uitgevende autoriteit daadwerkelijk openbaar maakt.

2. Behandel aliassen als hebbend verschillende sterktes, niet als één ongedifferentieerde lijst. Een volledige alternatieve spelling van de wettelijke naam en een eenwoordsbijnaam zijn niet even diagnostisch. Programma's die elke aka identiek scoren, erven het false-positive-percentage van hun zwakste alias. Waar een bron sterke en zwakke aliassen onderscheidt, neem dat onderscheid mee in de matchinglogica in plaats van het plat te slaan.

3. Gebruik een matchingalgoritme dat past bij het schrift en de taal, niet één generieke edit-distance-functie. Cyrillische en Arabische transliteratievariantie is een bekend, begrensd probleem — fonetische en transliteratiebewuste matching gaat er merkbaar beter mee om dan ruwe string-edit-distance-drempels die zijn afgestemd op typefouten in Latijnse tekst. Eén enkele globale drempel, uniform toegepast over alle naamsoorsprongen, is een veelvoorkomende en vermijdbare bron van beide soorten fouten tegelijk.

4. Houd dispositiegeschiedenis bij — zonder ooit de screening te onderdrukken. Wanneer een analist een hit afdoet als "beoordeeld, geen match" voor een specifieke klant, voorkomt het vastleggen van die beoordeling dat dezelfde laagwaardige alarm elke screeningcyclus opnieuw wordt behandeld. De discipline die hier telt: dit vermindert herhaalde ruis op een gedocumenteerde non-match, niet de onderliggende screening. De lijst wordt nog steeds elke keer gecontroleerd; alleen de alarmmoeheidskosten van een reeds opgeloste beoordeling dalen. Een naam stilzwijgend uitsluiten van toekomstige screening is een wezenlijk andere, veel risicovollere beslissing, en mag nooit een bijeffect zijn van ruisreductie.

5. Gebruik bronherkomst om analisten te helpen triëren, niet alleen om achteraf te auditeren. Weten van welke autoriteit, welk programma en welke lijst een hit afkomstig is, stelt een beoordelaar in staat om snel de plausibiliteit te toetsen — een hit tegen een sanctieprogramma voor de Democratische Republiek Congo heeft voor een klant zonder Afrikaanse zakelijke connectie andere priors dan een hit tegen een OFAC Rusland-programma-vermelding voor een klant met Russische tegenpartijen. Dit is een direct, praktisch voordeel van dezelfde bron-transparantiehouding die ten grondslag ligt aan onze datacatalogus: herkomst is niet alleen voor het controlespoor, het is een triagesignaal op het moment zelf.

De regelgevende achtergrond

OFAC's eigen Framework for Compliance Commitments behandelt screeningkwaliteit — dekking, actualiteit, kalibratie van fuzzy matching, en het oplossen van de eigendomsketens van de 50 Percent Rule — als een gedocumenteerde beheersmaatregel waar toezichthouders naar zoeken, niet als een intern implementatiedetail dat aan het inzicht van de leverancier wordt overgelaten. Een programma dat niet kan uitleggen waarom zijn matchdrempels zijn ingesteld zoals ze zijn ingesteld, en niet kan aantonen dat een false-positive-reductie geen recall heeft gekost, heeft geen verdedigbare beheersmaatregel — het heeft een wachtrij die toevallig korter is.

Waar je je eigen matching kunt controleren

Doorblader de bronnencatalogus om te zien welke identifiers en aliasstructuren elke lijst daadwerkelijk publiceert, doorblader het volledige corpus om echte aliasdichtheid en identifierdekking record voor record te zien, en zie onze AML/CFT-jurisdictiegidsen voor hoe elke toezichthouder screeningkwaliteitsverwachtingen in zijn eigen toezichttaal formuleert.