Zentrales Sanktionsregister
Eine Karte pro sanktioniertem Akteur. Aus allen Quellen gleichzeitig aufgebaut.
Early Access. Sanktionslisten können von den ausstellenden Behörden geändert werden.
Das Problem mit listenweisem Screening
Neun Listen. Neun unabhängige Dateien. Neun inkonsistente Datensätze für dieselbe Person.
Neun offizielle Quellen. Neun unabhängige Dateien. Dieselbe sanktionierte Person erscheint in jeder unter unterschiedlichen Transliterationen — mit verschiedenen Aliasnamen, unterschiedlichen biografischen Daten, manchmal unterschiedlichen Entity-Typen.
Ein System, das jede Liste einzeln screent, liefert für dieselbe Abfrage unterschiedliche Ergebnisse — je nachdem, welche Quelle zuerst geprüft wird. Das ist keine Compliance. Das ist Zufall.
Dreistufiges Datenmodell
Entity, Listing, Version — drei Ebenen, die Identität von Designation von Historie trennen.
Das Registry ist in drei Ebenen gegliedert. Jede Ebene hat eine bestimmte Funktion. Zusammen beantworten sie drei separate Fragen: Wer ist diese Person, wie ist sie gelistet und was hat sich geändert?
Die drei Ebenen erklärt
- Entity: Ein Datensatz pro realem Akteur. Kanonischer Name, Entity-Typ, Namensvarianten, bekannte Aliase, Lifecycle-Status. Die Identitätskarte — quellneutral und über alle Listen hinweg dedupliziert.
- Listing: Ein Datensatz pro Quellen-Designation. Programmcode, Rechtsgrundlage, Quellen-ID, quellenspezifische Eigenschaften. Mehrere Listings pro Entity. Die EU-, OFAC- und UN-Designierungen derselben Person sind drei separate Listings, verknüpft mit einer Entity-Karte.
- Version: Ein Datensatz pro Inhaltsänderung. Vollständiger Properties-Snapshot, Inhalts-Prüfsumme, Feldebenen-Vergleich, Gültigkeitsdatum. Nichts wird überschrieben. Nichts geht verloren. Wenn OFAC einen Alias hinzufügt, entsteht eine neue Version — die vorherige Version bleibt intakt und abfragbar.
Wie Namen in das Registry gelangen
Sechs deterministische Schritte pro Quelle und Nacht.
Jeder nächtliche Import folgt dem gleichen Ablauf. Die Schritte sind sequenziell und atomar. Ein Fehler in einem beliebigen Schritt wird mit vollständigem Kontext protokolliert — kein stiller Datenverlust.
Die sechsstufige Import-Verarbeitungskette
- 1. Download & Integritätsprüfung: SHA-256-Hash wird mit dem vorherigen Import verglichen. Unverändert: überspringen. Das verhindert unnötige Verarbeitung und bewahrt die Integrität der Versionskette.
- 2. Parsing: Namen werden als primär, Rechtschreibvariante oder Alias klassifiziert. Entitätstypen werden einer gemeinsamen Taxonomie zugeordnet, die Personen, Organisationen, Schiffe, Flugzeuge und mehr umfasst.
- 3. Intra-Source Lookup: Zuerst wird die quelleigene ID geprüft. Wenn ein Listing existiert: sofortige Auflösung, kein Name Matching nötig. Der schnelle Pfad — genutzt für die Mehrheit der Einträge bei jedem Update.
- 4. Cross-Source Resolution: Neue Einträge werden über die Bewertungskette gegen alle anderen Quellen abgeglichen. Siehe quellenübergreifende Zusammenführung für die Schutzregellogik, die falsche Zusammenführungen verhindert.
- 5. Version Management: Der Content-Hash bestimmt, ob sich ein Eintrag geändert hat. Nur echte Änderungen erzeugen neue Versionen — Metadaten-Updates lösen keine Versionsinflation aus.
- 6. Name Enrichment: Aliase aus eingehenden Quellen werden in die Entity-Karte gemergt, vorbehaltlich des Kontaminationsschutzes. Ein Name, der eine andere Entity in einer anderen Quelle identifiziert, wird abgelehnt.
Versionskette
Jede Feldänderung bleibt erhalten. Nichts wird überschrieben. Die Historie ist zu jedem Datum abfragbar.
Jede Feldänderung wird beibehalten. Die Feldkategorien umfassen den gesamten Umfang der Sanktionsdaten: Identität (Namen, Aliasnamen), biografische Daten (Geburtsdatum, Geburtsort, Nationalität), Dokumente (Reisepass, LEI, IMO), geografische Daten (Adressen), rechtliche Daten (Programm, Verordnung), finanzielle Daten (Grund für die Aufnahme in die Liste), Schiff (IMO, Tonnage, Baujahr).
Die Versionskette ist die Grundlage für die Zeitleistenansicht einer Entität, die Alias-Weitergabe und die Verbindungserkennung.
Was die Versionskette ermöglicht
- Point-in-Time Queries: Rekonstruieren Sie den exakten Zustand jeder Entity zu jedem Datum. Prüfen Sie eine vor sechs Monaten getroffene Screening-Entscheidung gegen die damals gültigen Listendaten.
- Feldebenen-Vergleich: Die Änderung zwischen zwei aufeinanderfolgenden Versionen wird als strukturierter Diff gespeichert. Hinzugefügte Aliase, entfernte Adressen, geändertes Geburtsdatum — alles auf einen Blick sichtbar.
- Delisting Detection: Wenn ein Eintrag aus einer Quelldatei verschwindet, wird das Listing mit einem Effective Date als delisted markiert. Nicht gelöscht. Die Designation-Historie bleibt intakt.
- Alias-Weitergabe: Aliase, die von einer Quelle hinzugefügt werden, sind über Entity-Karten suchbar, die ursprünglich aus anderen Quellen erstellt wurden.
Sanktionsprüfung — Für Audits konzipiert.
Der Early-Access-Zugang ist kostenlos und umfasst die vollständige Screening-Funktionalität für alle offiziellen Quellen, den kompletten Prüfprozess und audit-fertige Exporte.
Anmelden / Registrieren