How sanctions and PEP screening works

Nexiel Screen checks a name against sanctions and politically-exposed-person data, then routes anything uncertain to a human reviewer instead of guessing. This page covers what that checks for, where the underlying data comes from, how the matching approach works conceptually, and why a possible match never gets resolved by a machine alone.

What screening checks for

A sanctioned entity is an individual, organization, vessel, or aircraft that a government or international body has formally designated for restrictions: frozen assets, a travel ban, an arms embargo, or a prohibition on doing business with them. Dealing with a sanctioned party without authorization is itself a legal violation in most jurisdictions, independent of anything else about the transaction.

A politically exposed person (PEP) is someone entrusted with a prominent public function: a head of state, a senior politician, a senior civil servant, a judge, a senior military officer, or a close family member or known associate of one of these. PEP status is not an accusation. It is a risk category: people in these positions are statistically more exposed to bribery and corruption risk, so AML rules require closer scrutiny of transactions and relationships involving them. They do not require automatic refusal.

Regulated businesses, banks, payment firms, fintechs, law firms, accountants, real estate agents, and crypto asset service providers among them, are legally required to screen customers against sanctions and PEP data before establishing a business relationship and periodically afterward. EU AML Directives (and equivalent regimes elsewhere) make this an obligation on the business itself: failing to screen is a compliance failure regardless of whether a match is ever found.

Where the data comes from

Nexiel's sanctions coverage today draws on four regimes, refreshed daily:

• OFAC SDN(the US Treasury's Specially Designated Nationals list): US sanctions designations, relevant wherever a client transacts with US persons, US dollars, or the US financial system.
• UN Security Council Consolidated List: sanctions adopted by the UN Security Council. Every UN member state is expected to implement these, which makes it the closest thing to a genuinely global sanctions list among the four.
• EU FISMA(the EU's Financial Sanctions Database): the EU's own consolidated sanctions list, binding across all EU member states.
• HMT UK(the UK Treasury's Office of Financial Sanctions Implementation list): the UK's consolidated financial sanctions list.

Together, these cover the sanctions regimes most EU, UK, and US-facing regulated businesses rely on as a baseline. They do not cover every country's own domestic list. If your program needs a specific additional national list, check that separately against your own obligations.

PEP coverage layers a broad, continuously-updated aggregated dataset, OpenSanctions' global PEP data, with a set of direct primary-source integrations refreshed on the same daily cycle: the European Parliament's own membership register, the European Commission's College of Commissioners, the European Council, and live feeds from the national parliaments or equivalent legislative registries of Austria, Bulgaria, Croatia, Czechia, Denmark, Estonia, Finland, France, Germany, Ireland, Italy, Latvia, Lithuania, Luxembourg, Netherlands, Poland, Portugal, Slovakia, Slovenia, Spain, and Sweden. This direct-integration list is EU-weighted today and growing. It supplements the global OpenSanctions dataset rather than replacing it, and EU AML Directives require checking both a person's home country and any foreign PEP exposure, so the global dataset stays the base layer for anyone outside that country list.

One further source fills in historical breadth rather than live current status: a one-time snapshot of political office-holders across roughly 245 legislatures worldwide, compiled by the (now-dormant) EveryPolitician project. It is not continuously refreshed, so Nexiel uses it as supplementary historical context only. It does not reflect live current PEP status for any country it covers.

The matching approach: four layers today, a fifth on the way

A name rarely arrives in exactly the form it appears on a sanctions or PEP list. Transliteration, typos, missing middle names, and aliases all mean that a single matching technique misses real matches or drowns reviewers in false ones. Nexiel runs a hybrid of several techniques over every screening request, self-hosted end to end with no third-party screening API in the decision path:

• Exact match. Normalized name, date of birth, and nationality equality. Catches the straightforward case: a query name that matches a list entry exactly.
• Full-text search. A search index across every known name and alias for each list entry. Catches cases where the sanctioned or exposed person is more commonly known by an alias or alternate spelling than by whatever name a query happens to use.
• Levenshtein fuzzy match. Measures how many single-character edits separate two names. Catches typos, reordered name components, and minor transliteration drift, cases where the strings are close but not identical, so exact match and full-text search alone would miss them.
• Double Metaphone phonetic match. Encodes a name by how it sounds rather than how it is spelled. Catches cases where two spellings of the same name sound alike but share few letters in common, common when a name is transliterated from Arabic, Cyrillic, or another script into Latin characters by different sources.

Every candidate match also runs through a date-of-birth and nationality cross-reference: a name match on its own does not automatically confirm identity, so a perfect name match against a clearly contradicted date of birth is treated differently than one where the available biographical detail agrees. A fifth layer, a fine-tuned multilingual embedding model compared by vector similarity directly inside Postgres (no separate vector database), runs in shadow mode today, scored on every request ahead of joining the live classification. All of the layers above combine into a single weighted score, tuned and validated against Nexiel's own benchmark suite. The exact weighting is not published.

Three tiers, and why a human always reviews the middle one

Every screen resolves to one of three tiers:

ClearPossible matchConfirmed match

• Clear. No meaningful correspondence found against sanctions or PEP data.
• Possible match. Real correspondence found, but not conclusive enough to resolve on its own. Always routed to a human reviewer. Never auto-cleared.
• Confirmed match. Correspondence strong enough, for example an exact name, date of birth, and nationality match, that the system resolves it without ambiguity.

The exact score boundaries between these tiers are tuned against Nexiel's benchmark suite and are not published.

A possible match is never rendered as a softer or less serious state than a confirmed match anywhere in Nexiel's own interface. That is a deliberate design choice, not an oversight: under the EU AI Act, an AI-assisted screening decision with real consequences for a person, opening a bank account, getting hired, completing a transaction, requires human oversight before an adverse or ambiguous outcome is acted on. Two different people can share a name. A possible match exists precisely because the automated layer cannot responsibly tell them apart on its own, and resolving that ambiguity is a judgment call for a person to make, not a probability for a model to round off. See the legal disclaimer for what a Nexiel screening result does and does not mean for your own compliance obligations.

Where this fits

This matching engine is shared infrastructure behind both Nexiel Verify and Nexiel Screen. To run a request against it directly, start with the Screen API quickstart.