Sanctions Screening / Learning brief
Secondary identifiers and match confidence
Your notes
In simple terms / 01
What this means in plain language
A name similarity only opens a question. Dates of birth, nationalities, and document numbers are the evidence that closes it, strengthening a genuine hit or supporting the release of an innocent namesake, always on the record.
When a screening filter compares a customer or a payment against a sanctions list, a close name is only the start. Names are common, and many innocent people share one with a listed person. Secondary identifiers, meaning date of birth, place of birth, nationality, and identification-document numbers such as a passport or company registration number, are the details that turn a weak alert into a confident decision. They work in both directions: a matching document number makes a hit far stronger, while a firm mismatch on date of birth can support releasing a namesake for a documented reason. Confidence is uneven, though. A match on a unique number is close to decisive, whereas a mismatch must be weighed carefully, because list entries sometimes carry approximate or several possible birthdates. Missing data settles nothing, an absent birthdate only records that the comparison could not be made, which is itself worth noting.
Complete lesson / 02
Understand the full idea, step by step
If a stranger says their name is the same as a wanted person's, you do not arrest them — you ask for a date of birth, a photo, a passport. The name raised the question; the other facts answer it. A sanctions reviewer works exactly this way, and the facts they reach for have a name of their own.
Secondary identifiers
Secondary identifiers are the facts attached to a party beyond the name: date and place of birth, nationality, passport and national-identity numbers, company registration numbers, and addresses. A matching engine treats a close name as a question — an alert that something needs checking — and the reviewer compares these identifiers across the two sides. When they line up, the concern deepens; when they clearly diverge, the reviewer can set the alert aside with a documented reason.
The evidence runs in both directions
This is the point learners most often miss: identifiers do not only confirm hits, they also release innocent ones. A decisive mismatch is legitimate, recorded evidence for clearing a namesake — not a loophole, but the control reaching the right answer. The name narrows millions of records down to one candidate worth examining; the identifiers decide what that candidate actually is. Every conclusion is documented, never a quiet assumption.
Kabir's comparison in the scenario
- Name
- 'Maria Santos' on both sides — the match that raised the alert
- Date of birth
- List entry 1969 · beneficiary 1988 — a decisive divergence
- Nationality
- List entry Venezuelan · beneficiary Portuguese
- Disposition
- Released as a false positive, with the mismatch recorded as the reason
Are matches and mismatches equally trustworthy?
No — confidence is not symmetric. A match on a genuinely unique identifier, such as a specific passport or company-registration number, is close to decisive, because such numbers are not shared by chance. A mismatch has to be handled more carefully. Sanctions-list entries are compiled from imperfect intelligence, so one entry may carry an approximate birth year, several possible dates, or an address years out of date. A date of birth differing by a single day might be a transcription error, not a different person. Which mismatches may set an alert aside is documented, institution-specific policy — not a reviewer's private judgement.
COMMON CONFUSION
“If the payment message carries no date of birth, the absence itself helps clear an alert quickly.”
Missing data proves nothing. If a payment carries no birthdate, its absence cannot clear anyone — it only records that the comparison could not be made, which is itself worth logging. An alert resolved on absent evidence is not resolved; it is deferred until the missing fact can be obtained, often by asking another bank.
| Customer screening | Transaction screening | |
|---|---|---|
| Data available | The KYC file: verified documents, confirmed birthdate, nationality | Often just a name and account number in the message |
| Typical resolution | Frequently decisive, before an account is used | Thinner evidence; may need a request to another bank |
| Timing | Calm — during onboarding | Against the rail's clock, with the payment held |
STRICTLY SPEAKING
Strictly speaking, because transaction screening sees so much less, data-quality work is really screening work: every customer record missing a birthdate is a future alert that cannot be discounted quickly. Automation can pre-classify alerts — for instance discounting a hit when a verified date of birth differs decisively from every date on the list entry — but only under rules the institution has approved, tested, and revalidates on a schedule. An automatic discount is a decision never to show certain matches to a person, so it carries the same governance weight as any change to the filter.
FOR NOW, REMEMBER
- A close name opens a question; secondary identifiers — DOB, nationality, ID and registration numbers, addresses — answer it.
- Identifiers work both ways: they strengthen a genuine hit and support the release of an innocent namesake.
- Confidence is asymmetric: a unique-number match is near-decisive, while a mismatch needs care because list data can be imperfect.
- Missing data clears no one; it only records that the comparison could not be made — richer customer data means faster, safer resolutions.
TRY IT YOURSELF
A transaction alert fires on a beneficiary named the same as a designated person. The list entry shows a passport number; the payment message carries a name and account number but no passport number and no date of birth. What is the sound next step?
You have seen how a reviewer weighs the parties. But which parts of a payment message put a name in front of the filter in the first place? The next lesson reads the message field by field.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
A close name only raises a question; secondary identifiers such as date of birth and document numbers are what answer it.
- 02
Confidence is asymmetric: a matching unique identifier is near-decisive, while a mismatch must be weighed against approximate or multiple list values.
- 03
Missing identifiers clear no one; an absent birthdate records only that the comparison could not be made.
Practical use cases / 04
Where you would use this
A screening analyst compares an alerted customer's verified date of birth and passport number against the list entry to decide whether to release or escalate, and records exactly which fields matched.
A data-quality team treats every customer record missing a birthdate as a future alert that cannot be discounted quickly, and prioritises backfilling verified identifiers.
A sanctions compliance lead approves documented rules for which identifier mismatches may automatically discount an alert, then has them tested and periodically revalidated.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Meridian Trust, screens an incoming payment to a customer named Yulia Petrova. The filter raises an alert against a fictional list entry, PETROVA, Yuliya, on the invented Programme HELIOS, scored at 0.88 against a 0.85 threshold. The list entry records a date of birth of 3 February 1971, nationality Elbonian, and passport number X-4471. The bank's verified know-your-customer file shows its customer was born 19 September 1990, holds a different nationality, and carries passport number M-8820. Three independent identifiers mismatch decisively, so the analyst releases the payment as a false positive and records each comparison. Had the passport number instead read X-4471, the same alert would have hardened into an escalation to sanctions compliance within the same review.
Evidence & review / 07
Evidence & review
Alert investigation using secondary identifiers in customer and transaction screening; disposition policy is institution-specific.
What this brief simplifies: Uses a single clean mismatch to show the principle. Real cases weigh several corroborating and contradicting identifiers together under documented policy.
Sources for this brief3
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group
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
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.