Entity Registry
Eine Karte pro sanktioniertem Akteur. Aus allen Quellen gleichzeitig aufgebaut.
Beta-Version. Sanktionslisten können von den ausstellenden Behörden geändert werden.
Das Problem mit listenweisem Screening
Acht Listen. Acht unabhängige Dateien. Acht inkonsistente Datensätze für dieselbe Person.
Acht offizielle Quellen. Acht unabhängige Dateien. The same sanctioned person appears under different transliterations on each one — with different aliases, different biographical data, sometimes different entity types.
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, Content-Hash, Field-Level Diff, Effective Date. 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. A failure at any step is logged with full context — no silent data loss.
Die sechsstufige Import-Pipeline
- 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 Scoring-Pipeline gegen alle anderen Quellen abgeglichen. Siehe Entity Resolution für die Guard-Logik, die falsche Merges 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 Contamination Guard. 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 Entity-Timeline-Ansicht, die Alias-Propagation und die Entity Connections Engine.
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.
- Field-Level Diff: 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-Propagation: Aliase, die von einer Quelle hinzugefügt werden, sind über Entity-Karten suchbar, die ursprünglich aus anderen Quellen erstellt wurden.
Sanctions Screening Built to Be Audited.
Der Beta-Zugang ist kostenlos und umfasst die vollständige Screening-Funktionalität für alle offiziellen Quellen, den kompletten Review-Workflow und audit-fertige Exporte.
Anmelden / Registrieren