Global sanctions lists: choose the coverage your check needs

Start with the authorities your process requires

Global coverage helps only if it contains the sources your check needs. In SanctionsKit, use datasets and coverage to learn what each source covers. Then check whether it is available to your request. A directory entry tells you what the source is, not that it can be used now.

Open New screening in the dashboard, choose the subject type and select a policy or available sources. An app uses GET /api/v1/sources. It returns current states under data. Check availability and capabilities, then rightsStatus, qualification, fresh and currentVersion. Those fields answer different questions about whether the source can support your check.

Use source IDs without assuming they are active

The registry uses ofac-sdn and ofac-non-sdn for OFAC, us-csl for the U.S. Consolidated Screening List and uk-sanctions for the UK Sanctions List. EU and UN consolidated lists use eu-consolidated and un-consolidated. Canada autonomous sanctions uses ca-autonomous; Australia's consolidated list uses au-consolidated.

These names identify the contract, not current access. Check the authenticated response in your environment and handle a later screening-time failure. If a source is disabled, resolve the gap. Replacing it with another list needs an approved scope decision, not a quiet retry with fewer sources.

Send and retain the chosen scope

POST /api/v1/screenings accepts exactly one of sources, with explicit IDs, or package, with a documented version. Add the published policy reference when required and include its required sources for the subject type. Keep this choice unchanged when retrying the same operation.

The server checks required coverage again and does not silently shrink it. Save data.coverage and data.versions from a successful result. They let a later reviewer identify what was used. Follow the API quickstart in Sandbox before working in an authorized Production workspace.

Read the underlying authority during review

Open each candidate's authority, list, source record and original link. A CSL entry needs its underlying list context; it is not automatically an OFAC SDN result. Overlapping records may repeat one designation rather than provide independent evidence.

Use the official references below to inspect the source. The EU Node guide and UN Node guide use the same availability-first API flow. The service maintains source files; your integration does not need a separate importer.

Review coverage when the business scope changes

When your needs change, review the sources and policy. Publish the new policy version deliberately and update monitors with the right subject and sources. Keep earlier results tied to the versions they used. Adding a list today does not mean it was checked last month.

Use the freshness guide to tell an active source version from a later failed import. If required coverage is unavailable, the check is incomplete. Follow the escalation process. Do not describe that party as screened globally.

Record overlaps and gaps as well as list names

Map relevant jurisdictions, parties and activities to actual sources. A large worldwide list count does not show whether a needed measure or subject type is included. Record the scope in terms another reviewer can check.

A consolidated feed may repeat another authority's records, while a global label can still omit a needed list. Keep those overlaps and gaps visible. Ownership, goods, services and geographic restrictions can require work beyond the direct name search.

For example, suppose your policy requires three lists and only two are available. Two successful searches do not finish the three-list task. Record the missing source and give the gap to the person who can resolve it. Keep the original scope with the result.

Frequently asked questions