Name screening matches a party's name against sanctions, PEP, and other watchlists to catch prohibited or high-risk people and entities. It runs at onboarding and continuously after, because names are the most common identifier you have, but also the noisiest.
What is name screening, in plain English?
Name screening takes the name of a party you deal with, a customer, a beneficial owner, a counterparty, and checks it against watchlists: sanctions lists, politically exposed person lists, and other risk lists. If the name is close to a listed one, it produces an alert for review. The goal is to catch prohibited or high-risk people and entities before or during your relationship with them.
It runs at two moments. At onboarding, you screen a party before taking them on. Then continuously after, you rescreen against updated lists so that a newly designated party, or one you missed, gets caught. Screening once at signup is not enough, because lists change and relationships persist.
The hard part is that names are the most common identifier available and also the noisiest. Names are non-unique and vary by spelling and script, so name screening leans heavily on fuzzy, phonetic, and transliteration matching, plus secondary identifiers, to tell one person from another.
Name screening vs transaction screening
What changes | Transaction screening | Name screening |
What it checks | Payment message content and fields. | A party's name against watchlists. |
When | At the time of a payment. | At onboarding and continuously after. |
Catches | Prohibited parties or terms in a transaction. | Listed people and entities you deal with. |
Both together | Strong programs run both, not one or the other. |
When it runs
Stage | What name screening does |
Onboarding | Screens a new customer and related parties before the relationship starts. |
Ongoing rescreening | Rechecks the existing book against updated lists so new designations get caught. |
Trigger events | Rescreens when key data changes or a new designation lands that affects existing parties. |
Related parties | Screens beneficial owners, directors, and counterparties, not just the account holder. |
What it looks like in practice
In practice
A new customer applies, and onboarding screening matches their name to a sanctions entry. The name is common, so rather than block or clear on the raw match, an analyst pulls the date of birth and nationality and finds they do not line up with the entry. The alert is a false positive and is cleared with the reasoning documented.
Months later, a new designation names a party who turns out to be a beneficial owner of an existing corporate customer. Continuous rescreening catches it, even though the customer was clean at onboarding. Screening only at signup would have missed the exposure entirely.
Why it matters to operators
Name screening is often the first and broadest line of defense, but it is inherently noisy because names are non-unique and vary by spelling and script. That is why it depends on fuzzy, phonetic, and transliteration matching plus secondary identifiers to separate people, and why acting on a raw name match without disambiguating is a mistake in both directions: it either floods analysts or clears genuine hits.
It also differs from transaction screening, which checks payment-message content rather than party names. The two are complementary, not substitutes. Strong programs run both and confirm any hit with additional data before deciding, treating a name match as a lead to investigate rather than a verdict.
What to watch in the data
- Disambiguate before acting. A raw name match is a lead; confirm with date of birth, nationality, or address before you block or clear.
- Screen continuously. Onboarding alone is not enough; rescreen the book against updated lists to catch new designations.
- Related parties. Screen beneficial owners, directors, and counterparties, not just the named account holder.
- Variant coverage. Fuzzy, phonetic, and transliteration logic are essential because names vary by spelling and script.
- Run both types. Pair name screening with transaction screening; each catches what the other cannot.
Quick questions
How is name screening different from transaction screening?
Name screening checks a party's name against watchlists, usually at onboarding and continuously after. Transaction screening checks the content of a payment message at the time of the payment. They catch different things, so strong programs run both.
Why is name screening so noisy?
Because names are non-unique and vary by spelling and script. Common names collide with list entries constantly, so screening leans on fuzzy, phonetic, and transliteration matching plus secondary identifiers to tell people apart, which still generates many false positives.
Should you act on a raw name match?
No. A name match is a lead, not a decision. Acting on it without disambiguating either floods analysts with needless work or risks clearing a real hit. Confirm with additional data like date of birth or nationality before deciding.
Why screen continuously and not just at onboarding?
Because lists change and relationships persist. A customer clean at signup can be designated later, or turn out to be linked to a newly listed party. Ongoing rescreening against updated lists catches exposure that onboarding alone would miss.
Does name screening cover PEPs too?
Yes. Name screening typically checks sanctions lists, PEP lists, and other watchlists together. A PEP hit is a risk flag calling for enhanced due diligence rather than an automatic block, so it is handled differently from a sanctions match.
Go deeper
- OFAC, US Treasury ↗ — Administers US sanctions programs, the SDN list, and licensing.
- European Banking Authority ↗ — EU banking regulator. Strong Customer Authentication under PSD2 and AML guidance.