Sanctions screening: matching and scoring.

What screening is actually doing

A screening filter does not decide whether someone is sanctioned. It decides whether a string of text is similar enough to be worth a human look. Everything else in this course follows from that.

The Wolfsberg Group's Guidance on Sanctions Screening frames it exactly this way: screening detects a risk of sanctions exposure, which is then confirmed or discounted using additional information, to judge whether the similarity in the text reveals a true match. The filter produces candidates. People produce decisions.

Two controls, doing different jobs. Most institutions run both:

• Customer or name screening identifies targeted individuals and entities at onboarding and through the life of the relationship. It works with a full customer record and has time to think.
• Transaction screening identifies transactions involving targeted parties. It works with whatever the payment message carries — often truncated, often without identifiers — and it has milliseconds.

They fail differently, and a programme that treats them as one control will tune them wrongly.

Why "true match" is harder than it sounds. The guidance lists the variables that make it complex: alphabets, languages, cultures, spelling, abbreviations, acronyms and aliases. Automating it adds more — fuzzy matching algorithms, workflows and match rules. Each is a place where a real target slips through or an innocent customer is stopped.

Start from the risk, not the filter. An institution should identify and assess the sanctions risks it is exposed to, then build screening commensurate with its nature, size and complexity. The guidance points to factors including the jurisdictions where the institution operates and its proximity — geographically, culturally and historically — to sanctioned countries. That word culturally is doing real work: an institution serving a community whose naming conventions sit far from the list's romanised spellings has a harder matching problem than its neighbour, and should configure accordingly.

The two errors, and why they are not symmetrical. A false negative is a missed target: a sanctions breach, with legal consequences. A false positive is a stopped payment or a delayed customer: an operational cost. The asymmetry tempts institutions to tune wide and absorb the noise. That is a defensible choice only up to the point where the volume exceeds what reviewers can consider properly — beyond it, every extra alert reduces the attention paid to all of them, and the false negative arrives anyway, inside an alert nobody read.

Why names defeat computers

Screening fails on names more than on anything else, because a human name is not an identifier. It is a cultural artefact that varies in structure, spelling, order and completeness.

Transliteration is the largest single problem. Sanctions lists are published in a romanised form. A name originally written in Arabic, Cyrillic, Chinese, Devanagari or Amharic has no single correct spelling in Latin script — it has conventions, and they disagree. The same person can appear as Mohamed, Mohammed, Muhammad, Muhammed or Mohammad; Yusuf or Yousef; Aleksandr, Alexander or Alexandr. None is a misspelling. Different standards exist for mapping scripts into Latin characters, and different authorities, banks and customers use different ones — or none, transliterating by ear.

Name structure is not universal. A matching engine built around "given name, surname" assumptions breaks on much of the world:

• Patronymics, where the second name is the father's name rather than a family name, so a surname field may contain something that is not inherited.
• Compound surnames, where two or more elements must be kept together, and systems routinely truncate or split them.
• Family-name-first conventions, which produce reversed order and false non-matches when one source follows local order and the other does not.
• Particles and prefixes — al-, bin, ibn, van, de, della — which are variously written attached, separated, hyphenated or dropped entirely.
• Single-name individuals, who have no surname to put in a surname field at all.
• Honorifics and titles absorbed into a name field, so the string carries words that are not part of the name.

And then the ordinary mess of data. Initials instead of given names. Middle names present in one source and absent in the other. Nicknames and diminutives. Spelling errors made at onboarding, at the counter, or by the sanctioning authority. Truncation by systems with short fields — a particular problem in payment messages. Concatenation of first and last name into a single string without a separator.

Two consequences worth holding onto.

First, very common names are a structural problem, not a tuning problem. A target with a name shared by millions will generate volume no threshold can resolve, because the name alone genuinely cannot distinguish them. The answer is never a higher threshold — that just hides the target too. The answer is the next lesson's subject: other data.

Second, the filter's view of a name is only as good as the data reaching it. If customer records hold a concatenated string, or the payment message truncates at 35 characters, the matching engine is solving a different problem from the one you think. Data quality is upstream of every algorithm choice.

How matching actually works

A matching engine runs a pipeline: normalise, compare, score, decide. Each stage is a choice, and each choice is a risk decision.

Normalisation happens before any comparison. Case is folded, accents and diacritics are stripped, punctuation removed, particles possibly dropped, honorifics stripped, name order possibly reordered, and known variants mapped to a canonical form. Normalisation is powerful and quietly dangerous: every distinction it removes is a distinction the comparison can no longer make.

Comparison uses one or more families of algorithm. Understanding what each is blind to matters more than knowing their names.

• Exact matching — identical strings. Fast, no false positives from the algorithm itself, and defeated by a single character. Appropriate for structured identifiers, not for names.
• Edit distance — how many single-character insertions, deletions or substitutions turn one string into another. Good for typing errors and minor spelling variation. Blind to word order, and it treats a one-character change in a short name as far more significant than in a long one.
• Phonetic matching — reduces a name to how it sounds, so spellings that sound alike collapse together. Effective for variants within the language the algorithm was designed for, and frequently poor outside it; most of the classical phonetic algorithms were built for English or European names.
• Token-based matching — splits the name into parts and compares sets of parts, which handles reordering, missing middle names and extra elements. This is usually the backbone for full names, often combined with per-token edit distance.
• Statistical and learned approaches — models trained on known name variants. Potentially stronger across scripts, and carrying the obligations of any model: validation, explainability, and a reviewer's ability to understand why something matched.

Scoring. The comparison produces a similarity score, often normalised to a percentage. Treat that number with suspicion. It is a function of the algorithm, the normalisation applied, the length of the strings and the weighting of the parts — not a probability that the person is the target. The same pair of names will score differently on two systems, and "85%" means nothing portable.

Thresholds are risk decisions, and the guidance says so. Wolfsberg offers no numeric cut-off, which is correct — none could be right everywhere. What it requires is that the degree of exactness or fuzziness is a risk-based decision, documented, supported by analysis and testing. Its governance expectation is explicit: the framework should contain the documented rationale for risk-based decisions, including those made in support of screening rules and threshold settings.

Different thresholds for different things is normal and good. A threshold appropriate for a long, distinctive name is wrong for a short common one. Many institutions vary thresholds by list, by name length, by whether other identifiers are present, and between customer and transaction screening. What matters is that each setting has a reason written down beside it.

Lists, identifying information and weak aliases

A filter is only as good as what it screens against, and list handling is where a surprising amount of real risk sits.

The lists themselves. Institutions typically screen against the sanctions regimes applying to them, which vary by location, currency and clearing arrangements, and they must decide the scope deliberately rather than by what a vendor supplies by default. Lists change frequently, and the practical questions are how quickly an update reaches production, who confirms it arrived complete, and what happens to customers and payments processed in the gap.

Identifying information is not for screening. This point is widely misunderstood and the Wolfsberg guidance is clear: along with list entries, authorities often provide identifying information — attributes such as date of birth, nationality where legally permissible, and place of birth. That information does not need to be screened. It is provided to help assess an alert, to distinguish a true match from a false positive.

The practical implication is important. These attributes are the single most effective tool for resolving the common-name problem in the previous lesson. A name match against a target born in 1962 falls away quickly if your customer was born in 1994 — but only if the reviewer can see both, side by side, at the moment of decision. Filters that surface a name and a score without the identifying data force reviewers to guess or to go looking, which is slow and produces inconsistent outcomes.

Weak aliases. Authorities also publish ancillary information of varying usefulness, including what the guidance calls weak aliases or low-quality aliases: broad or generic names of sanctions targets, including nicknames and common acronyms, which add little value in confirming a match. The guidance states that it is not expected, nor typically productive, to screen against weak aliases. Screening them produces large volumes of alerts that cannot be resolved by the data that generated them. Institutions that screen weak aliases "to be safe" are usually buying noise.

Internal lists. Many institutions maintain their own lists — previously identified parties, internal intelligence, entities of concern. The guidance notes their usefulness depends on the data quality of the entries, and suggests setting minimum inclusion criteria including minimum data attributes and quality, so that entries are operationally effective and actually help alert investigation. It also recommends regular review, so that intelligence does not become stale or outdated. An internal list that grows and is never pruned becomes a permanent tax on reviewers.

Suppression, and the danger in it. Filters support suppression rules, sometimes called "good guys" lists, to stop repeated false positives on known customers from being reviewed again and again. This is legitimate and necessary at volume. It is also the control most capable of hiding a real match, because a suppression is a decision to stop looking. Suppressions need a stated basis, an owner, an expiry or review date, and a record — and they must be re-examined when the underlying list entry changes, because the entry that was a false positive last year may have been amended since.

Removing data. The guidance includes the removal of reference data from screening once it is no longer risk relevant. Screening against data that no longer matters costs reviewer attention that should be elsewhere.

Testing, metrics and what reviewers need

A filter that has never been tested with known inputs is a filter of unknown capability. The only way to find out what a configuration catches is to put things through it where the right answer is known in advance.

Designed test packs. Build a set of names where you decide what should and should not match, covering the variation that matters for your book:

• Transliteration variants of real list entries, across the scripts your customers actually use.
• Reordered names, missing middle names, initials in place of given names.
• Particles attached, separated and omitted.
• Truncated names at the lengths your payment messages actually impose.
• Deliberate near-misses that should not match — different people with similar names — to measure false positives honestly.
• Common names that match a target, paired with identifying data that distinguishes them, to test the whole decision and not just the string comparison.

Run the pack on every configuration change, keep the results, and keep the pack itself under version control. A test pack that never changes stops testing anything, because the configuration is eventually tuned to pass it.

Measure both directions. Recall is the proportion of things that should have matched which did — it measures missed targets, and only a designed test pack can tell you. Precision is the proportion of alerts that were worth raising. Tuning always trades one against the other, and reporting only one is how programmes mislead themselves. Alert volume on its own measures neither.

Independent testing. Wolfsberg expects independent review to look at the sophistication and configurability of the matching software, alert generation, thresholds and rules, and the accuracy and completeness of data. Note the last item: the review covers the data as well as the engine, because perfect matching logic reading a truncated field will miss consistently and silently.

What the reviewer must be shown. The guidance is specific that alert generation is the core of any screening application: it must present an alert clearly to trained sanctions personnel, show all relevant data from both the institution and the sanctions list so a decision can be made on the validity of that data, and let the reviewer record the rationale. Where the institution's risk tolerance requires it, a maker-checker or four-eyes step applies. A filter that shows a reviewer a name and a percentage is not meeting this; the data that resolves the alert has to be in front of the person resolving it.

Record the reasoning, not just the outcome. "Not a match" is not a decision anyone can review later. "Date of birth differs by 32 years, nationality differs, no other identifiers in common" is. When a regulator or an auditor examines closed alerts years afterwards, the written rationale is the only evidence that a judgement was made at all — and it is also what lets you re-open a population quickly if a list entry is later amended.

The honest summary. Screening cannot be made accurate, because the underlying data does not support accuracy. It can be made defensible: configured for your actual risk, tested against known answers, documented at every decision point, and presented to reviewers who have what they need to decide. That is what is being asked for, and it is achievable.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.