Een sanctielijst diffen: hoe doe je dat

Elk sanctiescreeningprogramma stelt vroeg of laat dezelfde vraag: "is er iets veranderd sinds de laatste keer dat we deze lijst hebben opgehaald?" Het naïeve antwoord — vergelijk het bestand van vandaag met dat van gisteren, regel voor regel — werkt in de praktijk niet, om redenen die niets te maken hebben met inspanning en alles met hoe uitgevende autoriteiten hun lijsten daadwerkelijk publiceren en herzien. Een sanctielijst correct diffen is een specifieke, aan te leren discipline, en het verkeerd doen levert twee tegengestelde faalmodi op: gemiste nieuwe aanwijzingen, en verouderde true-positive-signalen op personen of entiteiten die maanden geleden al zijn verwijderd.

Waarom een naïeve tekst-diff faalt

Sanctielijsten zijn geen append-only logs. Tussen twee momentopnamen kunnen records:

• Toegevoegd worden — een nieuwe aanwijzing.
• Verwijderd worden — een delisting, vergunning, of gerechtelijke uitspraak.
• Ter plekke gewijzigd worden — een gecorrigeerde geboortedatum, een nieuw bekendgemaakte alias, een herclassificatie van programma — zonder dat de onderliggende persoon of entiteit op enige manier verandert.
• Hernummerd of opnieuw geïdentificeerd worden — dezelfde entiteit uit de echte wereld krijgt een nieuw record-ID omdat de uitgevende autoriteit van systeem is gewisseld, haar lijst heeft geherstructureerd, of twee oudere lijsten heeft samengevoegd tot één.

Een regel-voor-regel tekst-diff gooit al deze vier op één hoop. Hij rapporteert een wijziging als een verwijdering-plus-toevoeging, mist een hernummering volledig (of erger, rapporteert die als zowel een verwijdering als een gloednieuwe toevoeging voor een entiteit die nooit daadwerkelijk is gedelist), en geeft geen enkel signaal over welke wijzigingen urgent zijn.

Het identificatieprobleem is het eigenlijke probleem

Het moeilijkste onderdeel van diffen is niet het detecteren dat er iets is veranderd — het is bewijzen dat record A in de momentopname van gisteren en record B in die van vandaag (niet) dezelfde entiteit uit de echte wereld zijn. De meeste uitgevende autoriteiten kennen elk record een persistente identifier toe, specifiek zodat downstream-gebruikers het over revisies heen kunnen volgen, maar die identifier is niet gegarandeerd bestand tegen een platformmigratie.

Het VK is hiervan een actueel voorbeeld. Financiële-sanctieaanwijzingen zijn op 28 januari 2026 verhuisd van OFSI's oude Consolidated List naar de door de FCDO gepubliceerde UK Sanctions List, en nieuw aangewezen personen krijgen nu een "Unique ID" toegewezen in plaats van het oude "OFSI Group ID" (GOV.UK-richtlijn). Een screeningpijplijn die zijn matchgeschiedenis koppelde aan het OFSI Group ID en geen rekening hield met de wijziging van het identificatieschema, loopt het risico elke reeds bestaande VK-aanwijzing te behandelen als een nieuwe entiteit op de dag dat hij de opvolgerlijst opnieuw inleest — een vals signaal op precies het moment dat het onderliggende regime feitelijk niet is veranderd. De omgekeerde vergissing is net zo reëel: oude ID's stilzwijgend koppelen aan nieuwe zonder de continuïteit van het referent te verifiëren, kan net zo makkelijk twee daadwerkelijk verschillende entiteiten samenvoegen.

Wat je moet diffen — vier categorieën, niet één

Behandel elke lijstvernieuwing als iets dat vier afzonderlijke outputs oplevert, niet één "gewijzigd"-bak:

1. Echte toevoegingen. Een record zonder plausibele match in de vorige momentopname. Dit is het geval waar iedereen op bouwt — het is ook het makkelijkst om goed te doen, omdat er niets te reconciliëren valt.
2. Verwijderingen (delistings). Een record dat aanwezig was in de vorige momentopname, afwezig in de huidige, zonder opvolgerrecord. Dit is de categorie die screeningprogramma's het vaakst onderbouwen. Onze eigen juni-handhavingsdigest behandelde een concreet voorbeeld: OFAC verwijderde op 24 juni 2026 een reeks Rusland-gerelateerde SDN-aanwijzingen, in dezelfde maand waarin het nieuwe toevoegde. Een pijplijn die alleen toevoegingen inleest en nooit delistings verwerkt, hoopt verouderde true-positive-signalen op — klanten die maanden geleden al van hun sanctie-exposure zijn verlost, blijven alarmen uitlokken, wat het vertrouwen in het hele screeningprogramma ondermijnt en de alarmen begraaft die nog wél actueel zijn.
3. Wijzigingen ter plekke. Zelfde identifier, zelfde entiteit, gewijzigde velden — een gecorrigeerde alias, een toegevoegde identifier, een aanpassing van de programmatag. Deze vereisen een diff op veldniveau, niet op recordniveau, omdat de betekenis varieert: een correctie van een alias is informatief, maar een herclassificatie van programma (zeg, van een sectorale lijst naar een volledige blokkeringsaanwijzing) kan veranderen wat juridisch vereist is van een tegenpartij die die naam in haar boeken heeft staan.
4. Identifier-remapping. De VK-casus hierboven — de entiteit is continu, maar haar persistente ID is veranderd vanwege een upstream platform- of lijststructuurwijziging. Deze categorie is onzichtbaar voor zowel een naïeve diff als een pure identifier-matchdiff; ze vereist het verifiëren van continuïteit via secundaire signalen (naam, andere identifiers, aanwijzingsdatum) wanneer de primaire ID verandert.

Een bruikbaar patroon

De betrouwbare aanpak behandelt elke lijst als een corpus met versiebeheer, niet als een bestand om te overschrijven:

• Bewaar elke historische momentopname, elk voorzien van zijn peildatum en (waar de autoriteit er een publiceert) zijn eigen versie-identifier.
• Diff op veldniveau binnen een gematchte identifier, niet alleen op recordniveau, zodat een wijziging leesbaar is als "wat er is veranderd" in plaats van een verwijder-en-herschep.
• Wanneer een identifier verdwijnt, controleer actief op een opvolger voordat je die registreert als verwijdering — een naam-en-attribuutmatch tegen de nieuwe momentopname, niet alleen een afwezigheidscontrole.
• Log verwijderingen als volwaardige delist-events met een tijdstempel, niet als stille verwijderingen — de verwijdering zelf is onderdeel van het controlespoor dat een complianceteam nodig heeft om uit te leggen waarom een naam die vroeger een hit was, dat nu niet meer is.

Dat laatste punt is de verbindende draad terug naar waarom dit er überhaupt toe doet: een screeninghit is alleen zo verdedigbaar als zijn herkomst — welke autoriteit, welke lijst, welke versie, per wanneer. Dezelfde discipline geldt omgekeerd voor een non-hit die vroeger wél een hit was. Als je niet kunt aantonen wanneer en waarom een naam is gestopt met matchen, is "we screenen daar niet meer tegen" geen antwoord dat een toezichthouder op goed vertrouwen zal accepteren.

Zie het in de praktijk

Onze tijdlijn van recente aanwijzingen toont toevoegingen zodra ze binnenkomen, per bron, met data. Verschillende bronnen hebben ook hun eigen tijdlijnweergave per bron om de activiteit van één lijst te isoleren. De bronnencatalogus documenteert de uitgevende autoriteit, het formaat en de updatefrequentie van elke lijst — de startfeiten die je nodig hebt voordat je een diffpijplijn ertegen bouwt. En een bron direct doorbladeren toont de huidige staat waartegen je diffed, record voor record.