Sanctions screening: how to clear a partial name match
Most screening hits are not sanctioned parties. But the work of showing that — properly, in writing, in a way that survives a reviewer six months later — is where a lot of teams are weakest. This note covers what actually discriminates between a name and a name, and what a discounting rationale needs to say.
Why the system gives you the hits it does
Before you can clear a match you need to understand why the engine raised it, and most analysts I have onboarded do not. They treat the screening tool as an oracle. It is not. It is a string comparison with tolerances, and the tolerances are set by someone in your firm who made a judgement about how much noise the team could absorb.
Fuzzy matching works by measuring the distance between two strings. Edit distance counts how many single-character changes turn one name into another. Phonetic algorithms collapse names that sound similar into the same code, which is why Smith and Smyth land in the same bucket. Token-based approaches break a full name into components and score how many align, which is why "Ali Hassan Mohamed" hits against "Mohamed Ali" at a surprisingly high score even though a human would not blink at them.
The threshold at which your engine surfaces a hit is a business decision. Set it at ninety-five per cent and you will miss transliteration variants. Set it at seventy and your analysts will drown. Neither setting is right or wrong in the abstract — what matters is that the setting is documented, that someone owns it, and that the tuning is periodically tested against known-positive samples. The Wolfsberg Group has published useful material on sanctions screening effectiveness that is worth reading if you are anywhere near the calibration conversation.
Once you understand that the hit is arithmetic, the emotional charge drains out of it. Your customer has not been accused of anything. A string matched another string. Your job is to establish whether the two strings belong to the same human being.
The discriminators, in rough order of usefulness
There is a hierarchy here, and juniors often work it in the wrong order. They start with what is easiest to look at rather than what is most probative.
Date of birth is the strongest single discriminator you will normally have, when both sides carry one. A full date of birth on the list entry and a full date of birth on your customer record, differing by more than a year, resolves most hits on its own. Be careful with partial dates. Many list entries carry only a year, or a range of years, or several conflicting dates because the designating authority received conflicting intelligence. A list entry showing three possible birth years is telling you something about the quality of the underlying information, and you should not treat a mismatch against one of them as conclusive.
Place of birth and nationality come next. These are often more stable than address data and harder to change. A customer born in Manchester with a British passport, matched against a designated individual born in Damascus with Syrian nationality, is a clean discount — provided you have actually verified your customer's details rather than accepting whatever the onboarding form said. Dual nationality complicates this. So do designations that list several nationalities because the person travels on multiple documents.
Gender, where recorded on both sides, is quick and occasionally decisive. It is also frequently absent or unreliable on list entries, so treat it as supporting rather than determinative.
Known aliases and AKAs cut both ways. A designation may carry a dozen alternative spellings, and your customer's name may match a low-quality AKA rather than the primary name. Consolidated lists usually flag alias quality — a "good" versus "low" quality AKA on the UK list, for example — and that flag should feed into how much weight you give the hit.
Identifiers — passport number, national ID, tax number — are gold when present, and they are often absent. When a list entry does carry a passport number and your customer's passport number is different, document it and move on.
Address is at the bottom of my list. People move. Designated persons in particular move, or use addresses that were current three years ago when the intelligence was gathered. An address mismatch is weak evidence of anything.
Common names, rare names, and why the match score lies
Here is the thing that took me the longest to internalise, and that I now teach on day one. A ninety-eight per cent match on a very common name is often weaker evidence than an eighty per cent match on a rare one.
Think about it as base rates. If your customer is called Mohammed Ahmed and the list contains a designated Mohammed Ahmed, you have an exact match — and you also have, in the United Kingdom alone, tens of thousands of people with that name combination. The prior probability that your particular customer is the designated one is very low, and the exact match barely moves it. Conversely, if your customer is called something that perhaps forty people worldwide share, and the match is imperfect because of a transliteration difference, the imperfect match is far more concerning.
Screening engines do not know this. They score string similarity, not evidential weight. Some of the better tools now apply name-frequency weighting, but you should not assume yours does. The analyst has to supply that judgement.
The practical consequence: on common names, be willing to discount on comparatively modest secondary evidence, because the base rate is doing most of the work. On rare names, demand more. A rare name with a partial match and no discriminating data available is a case for escalation, not for clearing.
The transliteration problem
This is the failure mode I see most often in firms that have grown quickly, and it is worth its own section.
Names originating in Arabic, Cyrillic, Chinese, Persian, Korean and a dozen other scripts do not have a single correct roman spelling. They have romanisations, and different systems produce different results. The same Arabic name might reach your records as Mohammed, Muhammad, Mohamad, Mohamed or Muhamed. Cyrillic surnames arrive as -ov or -ev or -off depending on whether they came through a Russian, French or German transliteration convention. Chinese names differ depending on whether Pinyin or Wade-Giles was used, and on whether the family name was placed first.
Now consider what happens when your customer base holds names romanised one way, your sanctions list holds them romanised another way, and your matching engine is tuned tight enough to keep the noise down. You get silent misses. Not false positives you can see and clear — hits that never fire at all.
Two things help. First, screen against the original script where you hold it and where your engine supports it; a name in native Arabic characters compared against the same name in Arabic characters is an exact match problem, not a fuzzy one. Second, understand that when a transliteration variant does fire, the fact that the spelling differs from your customer's is not by itself a reason to discount. "Different spelling" is the weakest possible rationale on a name from a non-Latin script. It is very nearly no rationale at all.
Case note
A payments firm I worked with had onboarded a corporate customer in March 2019 — a small trading company with two directors, both named on the customer record in a French-influenced romanisation picked up from their identity documents. Screening ran nightly against the consolidated list and had produced nothing for four years. In August 2023 the firm migrated screening vendors, and the new engine, running at a lower threshold with better phonetic handling, fired an eighty-three per cent match on one director against a designation added in 2022.
The analyst's first instinct was to discount on the basis that the spellings differed by three characters and the customer had been with the firm since 2019. Neither of those is a rationale. On working the discriminators properly, the date of birth on the customer file was 14 June 1971; the list entry carried two possible years, 1970 and 1971, no month or day. Place of birth matched at country level. Nationality matched. Nothing discriminated. The file went to escalation, and a review of nineteen payments totalling about four hundred and eighty thousand euros between February 2022 and August 2023 followed.
The point is not what the outcome was. The point is that the four-year clean history was the least relevant fact on the file, and it was the first thing the analyst reached for.
The tenure error
I want to be direct about the error in that case note because it is endemic.
"The customer has banked with us since 2016 with no issues" is not a discounting rationale. Designations are made at a point in time. A person who was not designated when they onboarded can be designated afterwards — and given how sanctions programmes have expanded over the last few years, this happens constantly. Length of relationship tells you about the past. A designation is a fact about the present.
The same applies to "this was reviewed and cleared last year". If the list entry has been amended, if new identifiers have been added, if your customer's record has been updated, the previous decision may rest on facts that no longer hold. Auto-discount rules that suppress previously cleared hits are operationally necessary at volume, but they need a mechanism that reopens the match when either side of the comparison changes. Ask your vendor how theirs works. Ask specifically.
What a defensible rationale contains
A reviewer picking up your case six months from now, with no memory of it, needs to reach the same conclusion from what you wrote. That is the test.
Name the list and the specific entry — the unique reference, not just "OFAC list". Say what fired: which name field on your side matched which field on theirs, and at what score. Then set out the discriminators one by one, including the ones that did not discriminate. A rationale that only lists the helpful facts reads as advocacy, and reviewers notice.
State the source of each fact you relied on. "Date of birth 3 November 1984 per passport scanned at onboarding, document reference on file" is evidence. "DOB does not match" is an assertion. If you consulted the designating authority's own entry — OFAC, OFSI or whichever applies to the programme in question — say so, and record what you saw, because list entries get amended.
Finally, say what you concluded and why the residual doubt, if any, is tolerable. Sanctions work is not about achieving certainty; it is about documenting a proportionate judgement. Where doubt remains and the discriminators are silent, escalation is the answer, and escalation routes vary by firm and by regime — a potential true match on an asset-freeze target is a different operational problem from a fuzzy hit on a sectoral programme.
If the file ends up needing wider context — source of funds, ownership, counterparties — the discipline is the same as building any enhanced file, and I have written separately on what an EDD file should contain. Where the entity structure is doing the obscuring rather than the name, the relevant skill is reading an ownership structure to find the beneficial owner, because ownership and control tests under most sanctions regimes bite on the structure, not the named party.
Where this sits in the wider workflow
Sanctions screening is a distinct discipline from transaction monitoring, and I resist the tendency in smaller teams to blur them. Monitoring asks whether behaviour is consistent with what you expect. Screening asks a much narrower question: is this the person on the list? The evidentiary standards, the escalation routes and the time pressures are all different. If you are new and building your general triage habits, the transaction monitoring alert triage checklist covers that side.
What they share is the writing discipline. A weak discounting rationale and a weak SAR narrative fail for the same reason — they assert rather than evidence. The worked SAR narrative example demonstrates the same habit applied to a different output.
One last thing. Screening quality is a supervisory interest, not just an internal one. The FCA has been explicit about expecting firms to test screening system calibration rather than trusting vendor defaults, and international standard-setting through FATF continues to push targeted financial sanctions implementation up the agenda. If you find yourself clearing a hundred hits a day and every one is noise, that is not a sign the system is working. It may be a sign nobody has looked at the tuning in three years.
Worth remembering: A name match is a question about identity, not about behaviour — answer it with identifiers you can source, never with how long the customer has been with you.