Sanctions Screening / Learning brief
Investigating a screening alert
Your notes
In simple terms / 01
What this means in plain language
A screening alert flags a payment or customer whose name or identifiers resemble a sanctions-list entry. This article explains how an analyst weighs evidence to clear a false positive or escalate a likely match, and why each decision is recorded.
A sanctions screening system compares the parties in a payment against official lists of sanctioned people, organisations, and places. Because names are spelled many ways and shared by many people, the system matches approximately, so most alerts are not real. An alert is therefore a question, not a verdict: it asks an analyst to look closer. The analyst compares what is known about the payment party — full name, date of birth, nationality, address, and any identifiers — against the details recorded for the listed entry. Where the evidence points away from the listed party, the alert is cleared as a false positive. Where it points toward a genuine match, the payment is held and escalated for a stronger review. The hold is the control working as intended. Every comparison and conclusion is written down, because a later reader must be able to see exactly why the decision was made.
Complete lesson / 02
Understand the full idea, step by step
A payment stops. Not because anything is wrong with it, but because a name on it resembles a name on a sanctions list. Someone now has to decide whether that resemblance is a coincidence or a real match — and to do it without either waving a designated party through or blocking an ordinary customer. That decision is the work of an alert investigation.
The alert at a glance
- Payment party
- Ravi Anand — beneficiary of Asha Traders' payment
- List entry that fired
- R. Anandov — synthetic training list entry
- Why it fired
- Approximate name match above the configured threshold
- Payment status
- Held pending review — not blocked, not released
- Reviewer
- Kabir, first-line sanctions investigator
An alert is a question, not an accusation
Screening matching is deliberately approximate. The same name can be transliterated from another script, shortened, reordered, or misspelled, so the system is tuned to catch a genuine target even when the spelling is imperfect. The price of that caution is volume: a large share of alerts — often the clear majority — describe ordinary parties who merely share part of a listed name. So Kabir treats the alert as a question about this party, not a verdict on Asha Traders. Holding the payment while he answers it is the control working exactly as designed.
False positive — an alert that turns out not to be the listed party
A false positive is an alert raised on a party who is not, in fact, the sanctioned entity — the names were close, but the person is someone else. False positives cost analyst time but are caught in review. Their opposite, a false negative, is a genuine match the system never flags; it passes silently and defeats the control. Investigation exists to separate the two, alert by alert.
How Kabir works the alert
- VALIDATION
He reads why the system fired: which list entry matched, on what fields, and how strongly against the configured threshold.
- VALIDATION
He compares strong, discriminating identifiers — date of birth, place of birth, nationality, passport or registration number — between the payment party and the list entry, not just the names.
- VALIDATION
He weighs context: the customer he knows, the counterparties, the countries in the payment path, and the stated purpose of the payment.
- VALIDATION
He reaches a disposition — clear as a false positive, or escalate as a likely match — and records the evidence that pointed each way.
- NOTIFICATION
Under a maker-checker arrangement a second reviewer confirms the decision before the payment is released or the match is acted on.
| Signal | Weight in the decision | Why |
|---|---|---|
| Name similarity | Low on its own | Lists deliberately include aliases, variants, and partial forms, so names rarely settle it |
| Two or more strong identifiers pointing away | High | A birth year decades apart or a different nationality shows the resemblance is coincidental |
| Strong identifiers lining up | High | Matching date of birth, nationality, and document number move confidence toward a true match |
| Missing or weak identifiers | Escalate, do not guess | Thin evidence is a reason for a stronger review, not a quick clearance |
COMMON CONFUSION
“An alert means the customer has done something wrong.”
It means a name crossed a similarity threshold. The system is designed to over-flag and let human review narrow the field. Most alerts clear as false positives. Nothing about the alert itself implies wrongdoing by Asha Traders or the beneficiary.
WHAT IF — The strong identifiers are missing, contradictory, or the match cannot be resolved with confidence
What happens: Kabir does not clear the alert on thin evidence and does not guess. The case moves to a stronger review or escalation.
How it is handled: Where an alert is escalated to a confirmed match, the trail supports the freeze and the report the institution must make to the relevant authority — a process that varies by jurisdiction. The payment stays held while questions are answered; a held payment is the system operating correctly, not a failure.
STRICTLY SPEAKING
Strictly speaking, a cleared or escalated alert is only as good as the record it leaves. A sound decision trail captures the list entry that fired, the match score against the threshold, the identifiers compared, the evidence each way, the conclusion, and the names and timestamps of everyone involved — including the maker-checker (four-eyes) confirmation. Preserving the reasoning, not just the outcome, is what lets a supervisor or auditor later confirm the decision was reasonable on the evidence available.
FOR NOW, REMEMBER
- Screening matches names approximately, so most alerts are false positives — ordinary parties who share part of a listed name.
- The review compares strong identifiers and context, not names alone; two strong identifiers pointing away usually clear a false positive.
- Where identifiers are missing or the match is uncertain, the alert is escalated rather than cleared on thin evidence.
- Every disposition is documented and confirmed under maker-checker so the decision is defensible later.
TRY IT YOURSELF
Kabir compares the beneficiary with the list entry. The date of birth is fourteen years apart, the nationality is different, and the passport numbers do not match. Only the surnames are similar. What is the sound disposition?
Kabir could clear that alert because the programme around him defined the lists, the threshold, and the record he had to keep. The next lesson steps back to that framework: who owns the screening programme, and how an institution defends its choices to an auditor.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Most screening alerts are false positives caused by approximate name matching, not confirmed sanctions hits.
- 02
Analysts clear or escalate an alert by comparing identifiers and context, not names alone.
- 03
The decision trail — evidence, reasoning, and reviewer — is preserved so the outcome can be re-examined.
Practical use cases / 04
Where you would use this
A first-line analyst reviews an alert queue and clears well-evidenced false positives so genuine risks receive attention.
A senior reviewer re-checks escalated alerts before a payment is held or a match is confirmed to an authority.
An auditor or supervisor reads a past decision trail to confirm the programme applied its rules consistently.
Worked example / 05
Put the idea into a real situation
Illustrative example: a payment from a fictional customer, Anna Kowalczyk, born 14 March 1988, triggers an alert at a match score of 88 against a configured threshold of 85. The list entry is a fictional sanctioned individual, Anatoliy Koval, recorded with a date of birth of 2 July 1961 and a different nationality. The analyst notes that the shared surname stem drove the score, but the birth years are 27 years apart and the nationalities do not match. With two strong identifiers pointing away from the listed person, the analyst clears the alert as a false positive and records both mismatches as the reason. The payment, held for 40 minutes during review, is released.
Evidence & review / 07
Evidence & review
Sanctions name-screening alert investigation at a payment institution; specific reporting and freezing obligations vary by jurisdiction.
What this brief simplifies: The scenario shows a single first-line reviewer and a maker-checker confirmation; real programmes add tiered escalation, list-management, and legal review. The list entry, party name, and amount are synthetic.
Sources for this brief3
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Alert investigation and record-keeping
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 · Handling of potential matches
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.