Zentrales Sanktionsregister
Eine Karte pro sanktioniertem Akteur, aufgebaut aus allen Quellen.
Sanktionslisten können von den ausstellenden Behörden geändert werden.
Das Problem mit listenweisem Screening
Zehn Listen, zehn unabhängige Dateien, zehn inkonsistente Datensätze für dieselbe Person.
Zehn offizielle Quellen, zehn unabhängige Dateien. Dieselbe sanktionierte Person erscheint in jeder unter unterschiedlichen Transliterationen — mit verschiedenen Aliasnamen, anderen biografischen Daten, teils anderen Entitätstypen.
Ein System, das jede Liste einzeln prüft, liefert für dieselbe Abfrage unterschiedliche Ergebnisse — je nachdem, welche Quelle zuerst läuft. Das ist Zufall, nicht Compliance.
Dreistufiges Datenmodell
Entity, Listing, Version — drei Ebenen, die Identität von Designation von Historie trennen.
Das Register hat drei Ebenen, jede beantwortet eine eigene Frage: 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. Properties-Snapshot, Inhalts-Prüfsumme, Feldebenen-Vergleich, Gültigkeitsdatum. Nichts wird überschrieben, nichts geht verloren. Wenn OFAC einen Alias ergänzt, entsteht eine neue Version — die vorherige bleibt intakt und abfragbar.
Wie Namen in das Registry gelangen
Deterministische, mehrstufige Verarbeitungskette pro Quelle und Nacht.
Jeder nächtliche Import läuft dieselbe mehrstufige Sequenz. Jeder Schritt ist atomar. Ein Fehler wird mit vollem Kontext protokolliert — kein stiller Datenverlust.
Die mehrstufige 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. Die Historie ist zu jedem Stichtag abfragbar.
Die Feldkategorien decken die gesamte Sanktionsakte ab: Identität (Namen, Aliasnamen), biografisch (Geburtsdatum, Geburtsort, Nationalität), Dokumente (Reisepass, LEI, IMO), Geografie (Adressen), Recht (Programm, Verordnung), Finanzen (Listungsgrund), Schiff (IMO, Tonnage, Baujahr).
Die Versionskette speist die Zeitleistenansicht, 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-Erkennung: Wenn ein Eintrag aus einer Quelldatei verschwindet, wird das Listing mit Stichtag 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.
Kostenlos nutzbar: vollständiges Screening über alle offiziellen Quellen, der komplette Prüfprozess und revisionssichere Exporte.
Anmelden / Registrieren