Sanctions Screening / Learning brief
Identifiers and data quality in screening
Your notes
In simple terms / 01
What this means in plain language
Strong secondary identifiers, such as dates of birth, passport numbers, and places, let a screening system confirm or clear a party with confidence. This article explains how good data cuts false positives and what weak data costs.
A name on its own is a weak way to identify a party, because many people and companies share names and spellings vary. Secondary identifiers make the difference. A date of birth, a passport or national identity number, a company registration number, and a place of birth each add a field that can confirm a real match or clear a coincidence. When both the sanctions entry and the customer record hold the same strong identifier, a screening system can raise or resolve an alert with confidence, and an analyst can document exactly why. When those fields are missing or wrong, the system falls back to name comparison alone, which produces far more alerts, most of them false positives, and each is slower and harder to clear. Investing in accurate identifiers on customer records is therefore one of the most direct ways to reduce screening noise while keeping the control strong.
Complete lesson / 02
Understand the full idea, step by step
Two contacts in your phone are both saved as "Priya". When one of them calls, the name alone tells you nothing useful — you rely on the number, the photo, the last thing you talked about. Add those details and the ambiguity vanishes. Take them away and every call becomes a guess. A screening system lives with the same problem, at scale.
Why a name is not enough
Screening begins with names, but names are among the weakest identifiers available. Common names are shared by thousands of unrelated people; spelling and word order vary between languages; and transliteration from other scripts multiplies the forms of a single name. So the engine compares names fuzzily and accepts near agreement as partial evidence. The unavoidable result is many alerts, most of them coincidences. That is not a fault — it is the correct, cautious behaviour when only a weak field is available. The cost is that every name-only alert must be reviewed by a person who has almost nothing to compare.
Secondary identifiers — specific fields beyond the name
Secondary identifiers are the fields that pin a name to a particular party: a date of birth, a national identity number, a passport number, a company registration number, a place of birth, a nationality. Because they are far more specific than a name, they let both the engine and the reviewer separate two parties who happen to share one — turning a slow, uncertain review into a quick, documented decision.
You might ask: is better matching software the way to cut false positives?
It helps, but it is the smaller lever. The larger lever is data quality. A strong identifier does two jobs. As a confirmer, a shared passport or registration number turns a probable name match into a near-certain one, so a true hit is caught with clear evidence. As an eliminator, a clear mismatch is strong evidence that a name agreement is a coincidence. But an identifier only works if both sides carry it — the list entry and the firm's own record. Clever matching cannot compare a field that is not there.
What strong data does to a review
- VALIDATION
The engine can set a higher-confidence threshold, because a name plus a matching identifier is far more specific than a name alone.
- VALIDATION
Fewer low-value alerts reach the queue, so analysts spend their time on the alerts that genuinely need judgement.
- VALIDATION
On each remaining alert, the reviewer has a strong field to confirm or clear against, and can write a short, factual note.
- VALIDATION
When a strong field is genuinely unavailable, that fact is recorded too, so a later reviewer understands why an alert stayed thin.
| Rich customer data | Thin customer data | |
|---|---|---|
| Fallback | Name plus identifiers | Name comparison only |
| Alert volume | Lower | Higher |
| Queue and delay | Shorter | Longer for everyone behind it |
| Risk of error | Lower on both sides | Wrongly clearing, or wrongly holding, a party |
WHAT IF — A customer record reaches screening with no date of birth and no identity number
What happens: Every run falls back to name comparison, alert volume climbs, and each alert is the hardest kind to resolve — a name agreement with no strong field to check against.
How it is handled: The remedy is not to weaken screening but to strengthen the data feeding it. Operations measure the share of records carrying an identifier, target the gaps at onboarding through customer due diligence, verify values rather than storing whatever was typed, and record where a strong field is truly unavailable so a thin alert is understood, not mistaken for negligence.
COMMON CONFUSION
“Poor data quality makes screening safer, because a vague record raises more alerts and therefore misses less.”
More alerts is not more safety. A flood of thin, name-only alerts buries the ones that matter, lengthens queues, and raises the chance of both errors — clearing something that deserved escalation, or holding a legitimate customer too long. Strong data lowers noise and concentrates skilled review where judgement is actually needed.
STRICTLY SPEAKING
Strictly speaking, an operation's accuracy depends partly on the list and partly on its own data, and real regimes and vendors populate identifier fields to different degrees. So a firm cannot assume the identifier it collected will have a counterpart on every listing — it confirms field coverage on both sides rather than assuming symmetry.
FOR NOW, REMEMBER
- Names are weak identifiers, so name-only screening is cautious by design and noisy by consequence.
- Secondary identifiers work as both confirmers and eliminators — but only when both the list and the firm's record carry them.
- Data quality, more than matching cleverness, is the main lever on screening accuracy.
- Weak data raises volume, lengthens queues, and makes both false clears and false holds more likely.
TRY IT YOURSELF
An operation buys a more advanced matching engine but keeps onboarding customer records that hold only names. What is the most likely outcome for alert volume and review quality?
Good identifiers only help if the list carrying them is current. Next: how sanctions lists reach a screening system, how they change, and why loading each update promptly is itself a control.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Names alone are weak identifiers; dates of birth, numbers, and places make matches confident.
- 02
Strong shared identifiers let an analyst confirm or clear an alert with a short, factual note.
- 03
Missing or wrong identifier data raises false positives and slows every review.
Practical use cases / 04
Where you would use this
An onboarding team collects and verifies dates of birth and identity numbers so later screening has strong fields to compare.
A screening analyst uses a matching or mismatching identifier to resolve an alert and document the reason.
A data-quality function measures how many customer records carry a date of birth or identifier and targets the gaps.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Meridian Trust, screens 50,000 customers against a list. Records that hold only a name generate 1,200 alerts, of which 1,150 are false positives cleared by hand. After the bank adds verified dates of birth to 40,000 of those records, the same screening run produces 300 alerts, because an exact date-of-birth mismatch clears most name coincidences, subject to a documented review step. The 900 fewer manual reviews free analysts to spend more time on the alerts that genuinely need judgement.
Evidence & review / 07
Evidence & review
Sanctions and name screening generally, across jurisdictions. Not legal advice; specific data and matching obligations depend on a firm's regulators and the lists it screens against.
What this brief simplifies: Describes confirmer/eliminator behaviour at a conceptual level and omits vendor-specific scoring and threshold mechanics.
Sources for this brief3
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Data quality, secondary identifiers, false-positive reduction
Wolfsberg guidance is industry market practice, not law; institutions vary in how they apply it.
- Official requirement
OFAC Frequently Asked Questions ↗ — US Department of the Treasury, Office of Foreign Assets Control · Use of identifying information when assessing a possible match
FAQs are added, amended, and renumbered over time; always check the live page for current numbering and text.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.