Name matching checkpoint
Check that you can read a sanctions list entry, explain why screening engines match name variants, use secondary identifiers to resolve hits, and tell customer screening apart from transaction screening.
QUESTIONS AS TEXT
Q1. What does a typical entry on a major sanctions list contain?
Answer: B: A primary name plus, where known, aliases, date and place of birth, nationality, addresses, identity-document numbers, and a reference to the program the entry belongs to.
A list entry is a structured record: a primary name, known aliases, and whatever secondary identifiers the authority could establish — dates of birth, nationalities, addresses, document numbers, and the program reference. Coverage is uneven: many entries lack some identifiers, and some lists flag lower-quality aliases separately. The richer the entry, the easier it is to confirm or eliminate a match against it.
Q2. Why do screening engines match name variants — different spellings, word orders, and transliterations — instead of requiring an exact string match?
Answer: A: Because the same name is legitimately written many ways: names transliterated from other scripts have multiple accepted spellings, word order and titles vary, and the lists themselves record aliases — an exact-match engine would miss entries that refer to the same person.
Names carry natural variation. A name written in another script can have several accepted romanizations, diacritics get dropped, given and family names swap order, and lists record known aliases precisely because one person appears under several names. Fuzzy matching exists to recognize the same identity written differently — the price is more false positives, which is why calibration and analyst capacity are planned together.
Q3. Order the stages of a single transaction-screening pass, from the payment arriving to a decision.
Answer: 1. The payment message arrives and the relevant fields — party names, addresses, free text — are extracted and normalized (Screening is only as good as its inputs — extraction and normalization prepare the message data before any comparison can happen.) 2. The matching engine compares the extracted data against the screening list data (The engine compares prepared data against list data; comparing raw unnormalized text would miss trivial spelling variations.) 3. The engine finds no credible match and releases the payment, or generates an alert and holds it (The engine's only two honest outputs are release (no credible match) or hold-and-alert — a machine never convicts anyone.) 4. An analyst investigates the alert, comparing the message data with the list entry (Human investigation begins only where the engine could not rule the match out; the analyst works the alert, not every payment.) 5. The alert is dispositioned: released as a false positive, or escalated as a potential true match (Disposition is the recorded end state — released as a false positive or escalated as a potential true match — and it can only follow investigation.)
Most payments travel this pipeline in milliseconds and never pause: extract, compare, release. The human part of the lifecycle only begins when the engine cannot rule a match out on its own — then the payment waits while an analyst turns a potential match into a documented decision. Everything downstream (customer impact, cut-off risk) depends on how quickly and how well that happens.
Q4. A customer-screening alert shows a strong name match, but the list entry's date of birth is 1954 while the customer's verified date of birth is 1991, and nationality and address do not align either. What role do these secondary identifiers play?
Answer: A: They let the analyst distinguish the customer from the listed person: consistent mismatches on verified identifiers are documented as evidence that the alert is a name collision, and the alert is closed under the institution's elimination criteria.
Name similarity generates candidates; secondary identifiers resolve them. A decades-wide gap on a verified date of birth, combined with non-matching nationality and address, is strong evidence of a name collision — provided the analyst records what was compared and why it eliminates the match. This is also why the quality of the bank's own customer data matters: you can only compare identifiers you reliably hold.
Q5. Nordbank screens its full customer file every night and also screens every cross-border payment as it flows through the payment engine. What is the difference between these two controls?
Answer: A: Customer screening checks who the bank has a relationship with — at onboarding and again when lists or customer data change; transaction screening checks the parties and text of individual payments in flight, including parties who are not the bank's customers.
The two controls are different lenses on the same obligation. Customer screening runs on a slower cadence with richer data — verified dates of birth, identity documents — so matches are easier to resolve. Transaction screening runs in real time on whatever the message happens to carry, which is thinner and messier. That asymmetry is why payment data quality and transparency have direct screening consequences.