Sanctions screening, explained.

Sanctions screening is the process of checking that a person or entity you transact with is not on a government, supranational or law-enforcement list of designated parties. The objective is to ensure your organisation does not provide funds, goods or services — directly or indirectly — to anyone subject to financial restrictions under applicable law.

Why sanctions screening matters

Sanctions are public-policy tools. Governments use them to disrupt terror financing, deter aggression, punish human-rights violations and contain criminal networks. Penalties for breach are severe: fines into the hundreds of millions, criminal liability for officers, and the kind of reputational damage that ends banking relationships.

Crucially, sanctions are strict liability in most jurisdictions. Intent does not matter. If you settle a transaction for a sanctioned party, you have breached — even if you had no idea.

The lists you have to cover

The unavoidable global core, which any compliance programme must screen against, is short:

Beyond the core, your screening programme should cover all national regimes you operate in — Switzerland (SECO), Australia (DFAT), Canada (OSFI/SEMA), Japan (METI), and so on. ScreeningHub covers 30+ of these national lists in addition to the global core.

Types of sanctions screening

• Customer screening at onboarding and at every status change.
• Ongoing customer monitoring: re-running existing customers against every list update so you catch new designations within minutes.
• Transaction screening: real-time checks of payee/payer names in payment messages (SWIFT, SEPA, FPS, etc.).
• Counterparty / vendor screening: applies the same logic to suppliers, brokers, agents, distributors.

The first two are the focus of name-screening APIs like ScreeningHub. The third typically lives inside the payment rail itself or in a dedicated transaction-screening engine.

How matching actually works

Sanctions data comes in many shapes — full names, aliases, transliterations, weak romanisations, abbreviated patronymics, name with title, name with suffix, name with date of birth, name with date of birth and a passport number. A modern matching engine therefore does not test for string equality. It runs a layered pipeline:

1. Normalisation: strip accents, casing, punctuation; expand abbreviations.
2. Tokenisation: split into name parts; handle eastern-name conventions.
3. Phonetic and edit-distance scoring: Soundex, Metaphone, Jaro-Winkler, weighted Levenshtein.
4. Transliteration: map across scripts (Cyrillic ↔ Latin, Arabic ↔ Latin, etc.).
5. Disambiguation: combine with date of birth, country of birth, nationality.
6. Confidence score: 0.00 → 1.00, threshold-driven decisioning.

Pass / review / hit decisioning

The output of a screening call is a decision, not raw data:

• pass — no relevant matches above the configured threshold.
• review — possible match, requires analyst attention.
• hit — strong match; the record returned is the source of truth for the EDD or block decision.

Thresholds should be configurable per use case. A retail BNPL flow can run looser than a private-banking onboarding because the false-negative cost differs.

Reducing false positives

False positives are the single biggest pain in any sanctions programme. The levers that actually move the needle:

• Pass more identity context: date of birth, country, gender, document number when available.
• Tune thresholds by use case rather than a single global setting.
• Keep an analyst feedback loop: when an analyst dismisses a match, that decision should reduce the score on identical future matches for the same customer.
• Use list-tier filtering: not every list applies in every jurisdiction or use case. Switch off lists you are not legally bound to screen against.

What auditors will ask for

The most common findings in regulatory examinations are not "you missed a hit" — they are documentation gaps. A robust audit trail should answer, for any historical screen:

• Who or what was screened (full payload).
• Which list versions were used, with checksums.
• What the match logic returned, including confidence score.
• What the analyst decided and why.
• Who approved an EDD or block decision.

If you cannot produce that within an afternoon, your programme has a documentation problem regardless of how good the matching is.

How ScreeningHub does it

ScreeningHub exposes a single REST endpoint for sanctions, PEP and adverse-media screening. Every call returns a clear decision, the matched records with sources and list versions, and an audit_id resolving to a tamper-proof log. Lists are refreshed within minutes of upstream publication. Match thresholds are configurable per API key. Ongoing monitoring (Growth and Enterprise) re-screens previously-cleared profiles automatically and fires a webhook on any status change.

Read the parallel PEP screening guide for the lifecycle on PEP data, browse the AML glossary, or jump to pricing to size a plan.