Sanctions lists

Ce contenu n’est pas encore disponible dans votre langue.

In short

SpeculaPro has twelve built-in list sources. Nine are published by their owners as a file at a web address, so SpeculaPro fetches them by itself. Three are published only as web pages, PDFs or gazette notices, so the operator of the installation types them into a file and imports it. Your workspace can also import its own watch lists.

Every fetch or import that changes a list is stored as a new version, with the publisher’s date, a fingerprint of the file, and a count of what was added, changed and removed. Old versions are kept.

Whose list is it

There are two kinds of list, and the difference decides who can change one.

	The installation’s lists	Your workspace’s own lists
Which	The nine fetched lists; `ng-nigsac`, `gh-domestic` and `uemoa-gel`; lists the operator imports as `import:<name>`; provider feeds (`provider:<key>`)	Lists you import as `import:<name>`
Who sees it	Every workspace on the installation	Your workspace only: the list, its versions and the matches against it
Who writes it	Only the installation: the worker (fetches), the operator’s command line, or a signed list bundle	Your workspace, in the app or through the API, with `screening.manage`
Shown under Settings → Screening as	fetched automatically or imported	imported · this workspace’s own list

A workspace cannot change one of the installation’s lists. An import under ng-nigsac or any other installation key through the API is refused with 403.
Another workspace can have a list with the same key as yours, for example import:internal-watchlist. It is a different list. Neither workspace sees the other’s.
The installation cannot import under a key a workspace already uses for its own list.
The database enforces this, not only the application: row-level security lets the role the API connects with read the installation’s lists and your own, and write only your own. The one exception is a signed list bundle sent through the API on a self-hosted installation, whose signature is verified first.

The built-in lists

Fetched automatically

List	Key	Publisher	Screened by default	Checked every
UN Security Council Consolidated List	`un-sc`	United Nations Security Council	Yes	6 hours
OFAC Specially Designated Nationals (SDN)	`us-ofac-sdn`	US Treasury, OFAC	Yes	6 hours
OFAC Consolidated (non-SDN) lists	`us-ofac-cons`	US Treasury, OFAC	Yes	6 hours
EU Financial Sanctions (consolidated list)	`eu-fsf`	European Commission	Yes	6 hours
UK Sanctions List	`gb-uksl`	UK Foreign, Commonwealth & Development Office	Yes	6 hours
South Africa Targeted Financial Sanctions list	`za-fic`	Financial Intelligence Centre	No	12 hours
Consolidated Canadian Autonomous Sanctions List	`ca-sema`	Global Affairs Canada	No	12 hours
Australian Consolidated Sanctions List	`au-dfat`	Department of Foreign Affairs and Trade	No	12 hours
Kenya domestic list (UNSCR 1373)	`ke-frc`	Financial Reporting Centre	No	24 hours

Screened by default means it is in the baseline every workspace screens against until it saves a choice of its own; see Default lists by jurisdiction. The other four are not fetched at all until some workspace on the installation selects them; the first fetch then happens at the worker’s next pass.

Notes on individual lists:

UK. The UK Sanctions List is the only source of UK designations since the OFSI Consolidated List closed on 28 January 2026.
South Africa and Canada. These files carry no publication date, so a version is dated by the web server’s Last-Modified date when it gives one. The Canadian file has no reference numbers either, so entries are identified by regime, schedule and item number.
Kenya. The FRC publishes each new list at a new, dated web address, so the address built into a SpeculaPro release goes stale when a new list comes out, and the fetch then keeps returning the old file or fails. The operator points the list at its new address without waiting for a release; see When a publisher moves a list. Because the address changes by hand, compare each new version with the FRC’s own publication before relying on it.

Imported by the operator

List	Key	Why it is imported
Nigeria Sanctions List (NIGSAC)	`ng-nigsac`	Published as web pages and PDF notices only
Ghana domestic designations	`gh-domestic`	No consolidated machine-readable list: designations appear in the Gazette and FIC notices
UEMOA / BCEAO asset-freezing lists	`uemoa-gel`	The regulation and national freezing orders are published as PDFs and in official journals
Any other list for the whole installation	`import:<name>`	A list every workspace should be able to screen against

These are the installation’s lists. The operator loads them, from the command line (speculapro screening import-list) or in a signed list bundle. See Screening lists for operators. On the hosted service, SpeculaPro operations do this.

They show Imported, no feed and Not loaded yet until the operator has imported a file. Until then, a workspace that has one ticked screens nothing against it.

Your own lists

A workspace imports its own watch lists as import:<name>, with Import a list under Settings → Screening or through the API, in the same file format. Only that workspace sees the list. A workspace keeps at most 20 lists of its own. See Importing a list.

Lists from a provider

A provider can also supply a whole dataset as a list, shown with the key provider:<key>, for example provider:opensanctions. This works for OpenSanctions on self-hosted installations: the operator sets the provider up for the whole installation with its data feed switched on, and the worker loads the feed every six hours. See Screening lists for operators.

Default lists by jurisdiction

Until someone saves a choice under Settings → Screening, a workspace screens against the lists of its jurisdiction:

Jurisdiction	Lists screened by default
Any country without a definition of its own (the global baseline)	`un-sc`, `us-ofac-sdn`, `us-ofac-cons`, `eu-fsf`, `gb-uksl`
Ghana	The baseline, plus `gh-domestic`
Nigeria	The baseline, plus `ng-nigsac`
The UEMOA states (Benin, Burkina Faso, Côte d’Ivoire, Guinea-Bissau, Mali, Niger, Sénégal, Togo)	The baseline, plus `uemoa-gel`
Sierra Leone, Liberia, The Gambia, Guinea, Kenya	The baseline only. Kenya’s `ke-frc` is not a default: tick it under Settings → Screening if you need it

The defaults follow the jurisdiction. If the workspace’s jurisdiction changes before a choice is saved, its default lists change with it, and open potential matches on a list that is no longer screened are closed. See Potential matches.
A workspace that never picked a jurisdiction gets its country’s lists, whatever its base currency. This differs from reporting and rule packs, where a country’s definition applies only in its own currency: a US-dollar workspace in Ghana follows Other country for reporting but still screens against gh-domestic by default.
Once someone saves the Sanctions lists panel, the workspace screens against exactly what was saved, and the jurisdiction no longer changes it.
gh-domestic, ng-nigsac and uemoa-gel only screen once the operator has imported them. Until then they are ticked and show Not loaded yet.

What a list entry holds

Whatever the publisher’s format, every entry is read into the same shape:

Field	Meaning
Key	The publisher’s own reference, so an entry stays the same entry from one version to the next
Kind	`person`, `organization`, `vessel`, `aircraft` or `unknown`
Names	The main name first, then every alias and former name
Dates of birth	A full date, a year and month, or only a year. Lists often give several, or a range
Nationalities	Two-letter country codes
ID numbers	Passports, national IDs, tax numbers, company registration numbers, ship IMO numbers
Programmes	The sanctions regime or programme the entry is listed under
Listed on, remarks	The date of listing and the publisher’s notes

Entries with no key or no name are dropped. An entry that repeats an earlier key is dropped too.

Versions

Each time SpeculaPro fetches a feed, it compares the entries with the current version:

Nothing changed: no version is stored. The list shows No change and the time.
Something changed: a new version is stored with the next number (1, 2, 3 …), and the list shows Updated.
The publisher’s file is older than the version held: no version is stored. The list shows Newer version kept. See A list never goes back in time.
The fetch failed: the list shows Failed (hover for the reason) and SpeculaPro tries again after a quarter of the usual interval. The previous version stays in use.
The new file would remove a large part of the list: no version is stored, and the list shows Failed with the counts. See A list is never emptied by a fetch.

A version records:

Field	Meaning
Version	Its number for this list
Published	The publisher’s own date, when the file gives one
Stored	When SpeculaPro fetched or imported it
Entries	How many entries the list has
Changes	Entries added (`+`), changed (`~`) and removed (`−`) since the previous version
Origin	Fetched, Imported, Signed bundle or Provider feed
File hash	The SHA-256 fingerprint of the file exactly as published. You can compare it with the publisher’s file to show nothing was altered

To see them, select Versions next to a list under Settings → Screening. See Screening settings.

Old versions and the entries they contained are kept, so each potential match can point to the version it was found in.

A list never goes back in time

A fetched list can get a version from two places: a fetch from its publisher, and a signed list bundle the operator loads. SpeculaPro keeps whichever was published last, so an old file never replaces a newer one.

What arrives	Stored when
A signed bundle	Its list was published after the current version. The date used is the list’s publication date in the bundle, or the bundle’s creation date when the list has none. If the current version has no publication date (a file the operator imported that states none), the bundle is compared by when it was made: its creation date must be after the moment that version was stored
A fetched file that states its publication date	Its date is the same as or later than the current version’s. On the same date the publisher’s file wins, as a same-day correction
A fetched file with no date of its own (South Africa FIC, Canada SEMA)	Always. It is the publisher’s answer now
Anything with the same entries as the current version	Never. It is reported as unchanged

When a fetch is turned down because the version held is newer, the list shows Newer version kept under Settings → Screening, with the note The publisher’s file is older than the version the installation has; the newer version stays until the publisher catches up. Nothing needs doing.

For example: the operator loads a bundle with the UN list published on 9 October. The publisher’s server still serves the file of 7 October for a few hours. The fetch shows Newer version kept and the 9 October version stays. When the publisher’s server serves a file dated 9 October or later, it is stored as usual.

A file the operator imports with speculapro screening import-list, and a list you import for your own workspace, are not compared by date: an import is an explicit decision by a person, and always becomes the new version unless its entries are unchanged.

A list is never emptied by a fetch

A publisher’s mistake, or a tampered copy of its file, can produce a file that reads correctly but has lost most of its entries. Stored as the new version, it would end screening against the missing entries in every workspace and mark the open potential matches on them delisted.

So a fetched file or a signed bundle that would remove more than 20% of the current version’s entries is refused when the current version has 50 entries or more:

Nothing is stored. The current version stays in use.
For a fetch, the list shows Failed under Settings → Screening. The reason gives the numbers, for example: the new un-sc would remove 600 of the current version’s 1012 entries (59%) and leave 412. The current version (5) stays.
SpeculaPro tries the fetch again at the usual retry time, and refuses again for as long as the publisher’s file is the same.

If the publisher really removed that many entries, the operator accepts the new version from the command line after checking it against the publisher’s own announcement. See When a list loses many entries. Nobody can accept it from the web app or the API.

What is not checked this way:

A file the operator imports with speculapro screening import-list, and a list you import for your own workspace. An import is a person’s explicit decision.
A provider’s feed, which applies the provider’s own removals.
A list whose current version has fewer than 50 entries.

On a self-hosted installation the operator can change both numbers: see Configuration.

When a list changes

When a list you screen against gets a new version, the worker applies it to your workspace at its next pass:

Removed entries. Open potential matches on an entry that has left the list are marked delisted, with the reason entry_delisted and the time.
Added and changed entries. Each one is looked up against all your customers and counterparties. Anyone who might match is screened again in full, against all your lists.
The work is recorded as a List change re-screen, with how many people were screened and how many potential matches they have.

Only the people a change could affect are screened again, so a list update does not mean screening your whole customer base.

Limits

A workspace can’t change a built-in list’s web address. The operator can, when a publisher moves a file. See When a publisher moves a list.
You can’t fetch a list on demand from the app or the API. A feed is fetched when its interval comes round.
Nobody can import a file over a fetched list. A list with a feed accepts only its publisher’s file or a signed bundle.
A workspace can’t import one of the installation’s lists. ng-nigsac, gh-domestic, uemoa-gel and every other installation key are the operator’s to load. A workspace imports its own lists as import:<name>.
At most 20 lists of your own per workspace.
No fetch on an air-gapped installation. With SP_SCREENING_AIR_GAPPED=true nothing is fetched; lists come from signed bundles and imports. See Screening lists for operators.