Entity Registry
One card per sanctioned actor. Built from all sources simultaneously.
Beta version. Sanctions lists are subject to change by their issuing authorities.
The Problem With List-Per-List Screening
Eight lists. Eight independent files. Eight inconsistent records for the same person.
Eight official sources. Eight independent files. The same sanctioned person appears under different transliterations on each one — with different aliases, different biographical data, sometimes different entity types.
A system that screens each list independently produces a different result for the same query depending on which source it checks first. That is not compliance. That is coincidence.
Three-Tier Data Model
Entity, Listing, Version — three layers that separate identity from designation from history.
The registry is structured around three tiers. Each tier has a distinct role. Together they answer three separate questions: who is this person, how are they designated, and what changed?
The Three Tiers Explained
- Entity: One record per real-world actor. Canonical name, entity type, name variants, known aliases, lifecycle status. This is the identity card — source-neutral and deduplicated across all lists.
- Listing: One record per source designation. Programme code, legal basis, source identifier, source-specific properties. Multiple listings per entity. The EU, OFAC, and UN designations of the same person are three separate listings linked to one entity card.
- Version: One record per content change. Complete properties snapshot, content hash, field-level diff, effective date. Nothing overwritten. Nothing lost. When OFAC adds an alias, a new version is created — the previous version remains intact and queryable.
How Names Enter the Registry
Six deterministic steps per source, per night.
Every nightly import follows the same pipeline. The steps are sequential and atomic. A failure at any step is logged with full context — no silent data loss.
The Six-Step Import Pipeline
- 1. Download & Integrity Check: SHA-256 hash compared against previous import. Unchanged: skip. This prevents unnecessary processing and preserves the version chain integrity.
- 2. Parsing: Names classified as primary, spelling variant, or alias. Entity types mapped to shared taxonomy covering persons, organisations, vessels, aircraft, and more.
- 3. Intra-Source Lookup: Source-unique identifier checked first. If listing exists: resolved instantly, no name matching required. This is the fast path — used for the majority of entries on every update.
- 4. Cross-Source Resolution: New entries matched against all other sources using the scoring pipeline. See Entity Resolution for the guard logic that prevents false merges.
- 5. Version Management: Content hash determines whether entry changed. Only real changes create new versions — metadata updates do not trigger version inflation.
- 6. Name Enrichment: Aliases from incoming source merged into entity card, subject to contamination guard. A name that identifies a different entity on a different source is rejected.
Version Chain
Every field change preserved. Nothing overwritten. History queryable at any date.
Every field change preserved. Field categories span the full scope of sanctions data: identity (names, aliases), biographical (DOB, POB, nationality), documentary (passport, LEI, IMO), geographic (addresses), legal (programme, regulation), financial (listing reason), vessel (IMO, tonnage, build date).
The version chain is the foundation for the entity timeline view, alias propagation, and the entity connections engine.
What the Version Chain Enables
- Point-in-Time Queries: Reconstruct the exact state of any entity on any date. Audit a screening decision made six months ago against the list data that existed at the time.
- Field-Level Diff: The change between two consecutive versions is stored as a structured diff. Added aliases, removed addresses, changed DOB — all visible at a glance.
- Delisting Detection: When an entry disappears from a source file, the listing is marked delisted with an effective date. Not deleted. The designation history remains intact.
- Alias Propagation: Aliases added by one source become searchable via entity cards originally created from other sources.
Sanctions Screening Built to Be Audited.
Beta access is free and includes full screening functionality across all official sources, the complete review workflow, and audit-ready exports.
Login / Register