Documentation · Data model

Identifiers and deduplication

Every record in our data has an ID, and records we believe describe the same party carry a shared entity ID. This page explains both, how the grouping is done today and where it falls short, and how to keep references in your own systems current.

Not about passport or tax numbers. This page is about the IDs we give to records and entities. Identifiers that publishers print about a person or company, such as passport, tax or IMO numbers, are properties; see the data dictionary.

The short version

Record ID crown-<number>: one listing of one party in one register, for example crown-379759982. It is the id in our files and the id in /api/entity?id= (without the prefix).
Entity ID crown-e-<uuid>: the group of records we believe describe the same party across registers. It is canonical_id in our files and entity_id in the API. Not every record has one.
Referents, a list of earlier IDs for the same entity, are part of the format but always empty today.
Store the record ID for every match you act on, and the entity ID next to it when there is one.

Storing references in your own system

When a screening match leads to a decision, keep:

the record ID, which tells you exactly which listing you saw;
the entity ID, if present, so you can find the same party’s other listings later (/api/entity?entity_id=<uuid> on the API);
the register name and the date you checked, because the publisher’s record is the authority.

On each refresh, look your stored record IDs up again. A record that is no longer returned has been removed by its publisher or retired by us. The API guide covers this in more detail under keeping stored IDs current.

How long retired IDs keep working

Record IDs are row numbers in our register. When a publisher removes a listing, the record is kept with its removal date but is no longer served by search or in the bulk files (see Corrections and de-listing).

To be provided: how long a retired record ID or entity ID can still be looked up, and whether a retired entity ID will point to its replacement. This is a commitment to customers and needs an owner decision.

How changes show up in delta files

Delta files compare each record with the previous build. When records are grouped under a new entity ID, or moved to another, the canonical_id of each record changes, so each one appears as a MOD entry. A record removed by its publisher appears as DEL. Record IDs themselves do not change when grouping changes. See Delta files.

Record IDs and sources

Our record IDs are numbers from our own register, not the publisher’s reference. The number alone does not tell you the source; the datasets field does, and the publisher’s own reference, where given, is in notes (for example Ref: RUS0251 on the UK list). Record IDs are the same in every collection and in per-register downloads, so a record has one ID wherever you find it.

How records are merged today

We group records into an entity when they have the same cleaned name and the same birth date. Names are compared after removing punctuation, spacing and case. That is the only method in use: every entity in our register today was formed this way, and the method is recorded with each entity.

An example: SULTAN AZIZ AZAM, designated by the UN Security Council (reference QDi.435), appears on many national lists. Seven records that give the same name and the birth year 1985 share one entity ID:

Record	Register
crown-379778607	UK FCDO consolidated list
crown-379881005	Ukraine SFMS terrorist list
crown-379914418	EU travel bans
crown-379926571	Moldova terrorist list
crown-379945296	Indonesia DTTOT
crown-379753618	France Trésor asset freezes
crown-379759982	Monaco SICCFIN asset freezes

Records of the same person that were not grouped, from the same build:

Record	Register	Why it was not grouped
crown-380825813	UN consolidated list	No birth date in our record
crown-380783289	OFAC SDN	Name written surname first; no birth date
crown-380710263	EU financial sanctions	No birth date in our record
crown-379784941	Japan MOF asset freezes	Birth year only in notes, not parsed

This shows the limits plainly:

Records without a birth date are never grouped. That excludes almost all companies, vessels and organizations, and most politically exposed persons.
A different word order (AZAM, SULTAN AZIZ) or script prevents a group.
Two different people with the same name and birth year can be grouped together, especially for single-word names given with a year only.

Because of this, our “distinct entities” figures count records that share a name and birth date. They are a rough measure, not a count of real-world parties. The register currently holds 286,047 grouped entities.

Planned work. Grouping records without a birth date, using the same or a missing birth date together with a compatible type and nationality, with a recorded method for each group (data backlog item 2); publishing distinct-entity figures from that grouping (item 3); and indexing names in other scripts so that transliterated spellings can be compared (item 26).

To be provided: whether any human review of groupings will be offered, and how a customer can ask for two records to be split or joined. Until then, report a wrong grouping to [email protected].

When grouping runs

New records are searchable as soon as their source has been loaded. Grouping is a separate step, so a new record may appear without an entity ID until it next runs.

To be provided: the schedule on which grouping runs after each refresh. The refresh job itself is being restarted (data backlog item 1).

How grouped records are combined

We do not build a single combined profile from a group. Each record keeps its own names, dates and listing exactly as its register published them; the entity ID only links them. Search results and record pages show the other records of the same entity as separate listings. Rules for choosing a best name or the most precise date across a group would come with the improved grouping above.

Field-level provenance

In statements.csv, entity_id is the record and canonical_id is the entity, so you can regroup or ungroup the values yourself. See Statement data model.

Source pages for the registers in the example and others: Canada consolidated autonomous sanctions, OFAC SDN, EU consolidated financial sanctions, UN Security Council consolidated list.

Last updated 2026-10-04