Sanctions and PEP screening

In short

Governments and international bodies publish sanctions lists: people, companies, ships and aircraft that nobody may do business with, or whose assets must be frozen. A financial institution has to check its customers, and the people its customers pay, against those lists. That check is called screening.

SpeculaPro screens the names it already holds:

It keeps the official lists up to date for you, fetching each one from its publisher several times a day and storing every version.
It compares every customer and counterparty (the other side of a transaction) with the lists you chose, using a name-matching engine that copes with spelling variants, transliteration, titles and word order.
It records every likely match as a potential match (a hit), with a score and a plain explanation of why it scored that way.
It screens again by itself when a customer’s details change, when a new counterparty appears, and when a list changes.
Your reviewers work the potential matches on the Screening page, clearing false positives and confirming true matches. A confirmed match flags the party, opens a case and, for a sanctions match, changes what the real-time decision answers.

Words used on these pages

Word	Meaning
Sanctions list	An official list of people and organisations under financial sanctions, for example the UN Security Council Consolidated List
PEP (politically exposed person)	Someone who holds, or recently held, a prominent public position, and their close family and associates. PEPs are not banned; they need closer attention. No government publishes a complete PEP list, so PEP data comes from a commercial or open provider
Subject	Whoever is being screened: a customer or a counterparty
Potential match (hit)	A subject and a list entry that look like the same person or organisation. It is a question for a person to answer, not a finding
False positive	A potential match that turns out to be someone else with a similar name. Most potential matches are false positives
Match threshold	The score, from 0.50 to 0.99, at or above which a candidate becomes a potential match. The default is 0.85
List version	One fetched or imported copy of a list. SpeculaPro keeps every version, so you can show which list was in force when someone was screened
Installation list	A list kept once for the whole installation and the same for every workspace: the official lists, the national lists the operator imports, and provider feeds
Workspace list	A watch list of your own, named `import:<name>`. Only your workspace sees it and screens against it
Re-screen	Screening people again: everyone, or only those a list change could affect

What is built, and what is not

Part	State
Official lists fetched automatically: UN, OFAC (two lists), EU, UK, and on request South Africa, Canada, Australia and Kenya	Built. See Sanctions lists
Your own watch lists (`import:<name>`), loaded from a file and seen by your workspace only	Built, in the app (Settings → Screening → Import a list) and through the API, on self-hosted installations and on the hosted service. See Importing a list
Lists with no machine-readable publication (Nigeria, Ghana, UEMOA), loaded from a file for the whole installation	Built, by the operator from the command line. See Screening lists for operators
Signed list bundles for networks with no internet connection	Built (command line, and the API on self-hosted installations). See Screening lists for operators
Name matching with an explanation for every score	Built. See How matching works
Automatic screening of new and changed customers, new counterparties, and after every list change	Built
Settings → Screening: what is screened, the threshold, the lists and their versions, re-screens	Built. See Screening settings
Providers for PEP and enhanced data: OpenSanctions, ComplyAdvantage, LSEG World-Check One	Built, set up in the app (Settings → Screening → Connect a provider) or through the API; a provider for the whole installation is set up by the operator from the command line. See Providers
Providers: Dow Jones Risk & Compliance, LexisNexis Bridger Insight XG, Moody’s Grid	Not available. They are listed, but every call to them fails until the connection is written
Screening one name on demand	Built, through the API only. See Screening API
The Screening page: a queue of potential matches, the customer and the list entry side by side, assigning, comments and a timeline	Built. See Reviewing a potential match
Clearing a false positive, remembered so the same pair doesn’t come back	Built
Confirming a true match: a designation and a case	Built
A second person’s approval for true matches and for clearing sanctions matches	Built, on by default. See When a second person has to approve
Sanctions matches in the real-time decision: a confirmed match blocks, an open one is reviewed, both adjustable	Built. See Real-time decisions
Checking a counterparty’s name against the lists during a real-time decision, when nothing is stored for them yet (the first payment to them)	Built, against the lists only: providers are not called from a decision. See A counterparty seen for the first time
Checking a customer’s name during a real-time decision	Not built. A decision reads the matches already recorded for the customer
A notification when a colleague assigns a match to you	Built: email, text message or WhatsApp, as you chose under Settings → Notifications. See Notifications

How it fits together

 publishers (UN, OFAC, EU, UK …)    the operator's files and bundles    your own watch lists
            │ fetched by the worker            │                          │ imported by you
            ▼                                  ▼                          ▼
      the installation's lists, the same for every workspace      your workspace's lists
            │                                                             │
            ▼                                                             ▼
   your workspace's choice of lists  ──►  matching engine  ◄──  customers and counterparties
                                               │    ▲
                                               ▼    └── providers (optional)
                               potential matches, with score and explanation

The installation’s lists are the same for everyone. An official list is public data, so it is fetched and stored once. Only the installation writes it: the worker, the operator’s command line, or a signed list bundle. No workspace can change it for the others.
Your own lists are yours alone. A list you import as import:<name> belongs to your workspace. No other workspace sees it, its versions or the matches against it.
Choices belong to the workspace. Each workspace chooses which of those lists it screens against, and its own threshold.
The worker does the work. List fetching, automatic screening and re-screens run in the background worker. The web app only shows the outcome.
Nothing slows your data feed. Screening happens after a customer or transaction is saved, never while it is being accepted.

What is screened, and when

Who	What is compared	When
Customers	Name; date of birth; nationality (for a business, its country); the national ID number	When the customer is created, and again whenever any of those details change
Counterparties	Name and country	When the counterparty’s record is first written, and again whenever its name, country or type changes
Everyone already screened	The same	When a list you screen against gets a new version (only the people the change could affect), when you change your lists or threshold, and when someone selects Re-screen everyone

A new or changed customer is picked up within about a minute: the worker looks every 30 seconds by default, and leaves a record alone for its first 15 seconds so that it is complete.

Customers and counterparties without a name are not screened.

The first time a workspace is screened, everyone in it is screened once.

When a provider can’t be reached

A person is never quietly left half screened. If a provider can’t be asked about someone, that person is screened against your lists, recorded as not fully screened, and the worker asks the provider again: after one minute, then two, four and so on up to every six hours, for as long as the provider stays set up. See Providers: when a provider can’t be reached.

Who can do what

Permission	What it allows	Roles that have it by default
`screening.view`	See the Screening page and read potential matches; see the Screening settings, the lists and their versions, re-screens and providers; screen a name on demand against the lists (not the providers)	Analyst, Senior analyst, L2 investigator, MLRO, Administrator, Auditor
`screening.review`	Take, assign and comment on potential matches, and resolve them as a true match or a false positive	Analyst, Senior analyst, L2 investigator, MLRO
`screening.manage`	Change what is screened, the lists and the threshold; set up providers; import your own lists; start a re-screen; screen one customer or counterparty on demand; send a name to your providers on demand	MLRO, Administrator
`screening.approve`	Approve a screening change, or a decision on a potential match, that someone else proposed. While a second person’s approval for sanctions matches is not in effect, also the permission needed to confirm or clear a match against a sanctions list	MLRO
`screening.accept_removal`	Import a signed list bundle through the API although it removes more of a list than a bundle may by itself (self-hosted)	MLRO, Administrator

Screening appears in the side menu for anyone with screening.view or screening.review; reading the queue itself needs screening.view, so give a custom reviewer role both. The Screening tab appears under Settings for anyone with screening.view or screening.manage. (Through the API, settings.view is also enough to read the settings, lists, re-screens and providers.)

Changing the lists, the threshold or a provider, importing a list, and importing a signed list bundle through the API, can need a second person’s approval. See Approvals for screening changes. So can a decision on a potential match: see When a second person has to approve.

Known limits

An open potential match holds its customer’s records. That customer is not purged or erased until someone clears or confirms the match, or it closes by itself. See Potential matches: what is kept.
A real-time decision screens only a counterparty it has nothing stored for, by name, against the lists and never against a provider. A counterparty sent without a name is not screened there, and a customer never is: the decision reads the matches already recorded. See A counterparty seen for the first time.
During an outage, confirmed sanctions matches still apply; open ones don’t. A decision that can’t finish in time still applies your Confirmed sanctions match setting, from a copy of your confirmed matches each decision process keeps in memory and re-reads every few seconds (up to 100,000 parties per workspace; above that, the most recently confirmed). A match confirmed in the last few seconds may be missed, and an open potential match is never applied to such a decision, including one that screening a new counterparty’s name inside the decision found or would have found: the failure policy answers alone, and Fail open allows the payment. See When the checks can’t finish in time.
Only sanctions matches change a real-time decision directly. A confirmed PEP or adverse-media match acts through the designation it sets and the rules that read it.
Notifications go by email, text message or WhatsApp only. There is no inbox in the app, and nobody is told when a new match arrives unassigned: reviewers watch the queue.
A match with several kinds sets only the gravest designation when confirmed.
PEPs need a provider. The built-in lists are sanctions lists. Without a provider, nobody is identified as a PEP by screening.
Importing a list and setting up a provider have no page in the app yet. Both are done through the API.
On the hosted service, the official lists are managed by SpeculaPro. A workspace there imports its own import:<name> lists, but cannot import a signed bundle or change a list every workspace shares.
The Nigeria, Ghana and UEMOA lists screen nothing until the operator has imported them. A workspace in those jurisdictions has them ticked by default; they show Not loaded yet until then. See Sanctions lists.
A workspace keeps at most 20 lists of its own.