Secondary identifiers and confidence
A name similarity opens a question; birthdates, documents, and addresses are what close it — in either direction, with evidence.
L0 Explain simply
An everyday analogy: the gate check has two steps. Step one asks, is the name close enough to a poster to look twice? Step two compares everything else: the poster says born 1958 in one country, carrying a specific passport; the visitor's papers say born 1991 in another country, different document entirely. Now the gatekeeper can release the visitor with confidence and write down exactly why. If instead the birthdate and birthplace line up too, the hold hardens into an escalation. The name opened the question; the other details answered it. A poster with rich details makes both outcomes fast — a poster with nothing but a common name leaves the gatekeeper stuck either way.
L1 Core concepts
Secondary identifiers — date and place of birth, nationality, passport and registration numbers, addresses — are what convert a name score into a decision. They work in both directions: a matching document number strengthens a hit dramatically, while a firm mismatch on date of birth can support releasing a namesake. Confidence is asymmetric, though. A match on a unique identifier is near-decisive; a mismatch must be weighed more carefully, because list entries can carry approximate or multiple birthdates and stale addresses. And missing data proves nothing: if the customer record has no birthdate, the absence cannot clear anyone — it just means the comparison could not be made, which is itself worth recording. Rules for what may be discounted automatically are documented policy, not investigator preference.
L2 Practitioner view
In practice, identifier quality on the bank's own side decides how well this works. Customer screening usually has the richer picture: the know-your-customer file holds verified documents and birthdates, so alerts can often be resolved decisively. Payment messages carry far less — sometimes only a name and an account — so transaction alerts are frequently decided on thinner evidence or need an information request to another bank before they can be closed. This is why data quality programmes are screening programmes in disguise: every customer record missing a birthdate is a future alert that cannot be discounted quickly. Investigators record which identifiers they compared and what each showed, so the release rationale survives audit; the linked scenario walks exactly that documentation discipline.
L3 Technical details
Automation enters carefully. Structured identifier comparison can pre-classify alerts — for example, automatically discounting a hit when the customer's verified date of birth differs decisively from every birthdate on the list entry, under rules the institution has approved, tested, and periodically revalidated. The governance stakes equal any threshold change: an auto-discount rule is a decision to never show certain matches to a human, so it needs documented rationale, test evidence, and review when list schemas or data sources change. Institutions differ on how far they let this go — some only re-rank alert queues, others close whole alert classes automatically. What does not vary is the principle: the logic must be explainable, its assumptions inspectable, and its misses measurable through sampling below the line.
Sources & standards1
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Alert quality, suppression rules, and risk-based exclusion criteria
Wolfsberg guidance is industry market practice, not law; institutions vary in how they apply it.
Sources for this topic2
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Alert generation and handling
Wolfsberg guidance is industry market practice, not law; institutions vary in how they apply it.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The two-step gate model separates name matching from identifier comparison more cleanly than real engines do, and which mismatches may discount an alert is institution-specific policy. All identifiers and parties in examples and the linked scenario are fictional.
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.
Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.