A sanctioned individual rarely presents their name the way it appears on a watchlist. It arrives transliterated from Arabic or Cyrillic, reordered, abbreviated, misspelled by a data-entry clerk, or deliberately altered by a single vowel. A screening system that only catches exact matches catches almost nothing of value, because the real world does not hand over names in tidy, identical strings.
This is the problem fuzzy matching exists to solve, and it sits at the center of every serious sanctions and watchlist screening program. When the UK's Financial Conduct Authority (FCA) tested screening systems at over 150 firms in 2026, it found that systems correctly identified the sanctioned party in 90% of exact-name-match tests but only 75% where names appeared in slightly different forms. One in four manipulated names slipped through. What follows explains how fuzzy matching works, the algorithm families behind it, the threshold decision that determines whether a program succeeds or fails, and what regulators now expect firms to prove.
The subject sounds technical, and parts of it are, but the underlying idea is simple enough. Human names are messy data. They cross languages, alphabets, and clerical habits, and every crossing introduces variation. A screening program is fundamentally a system for deciding, at speed and at scale, whether two messy strings refer to the same human being. Getting that decision right is what stands between a compliant institution and an inadvertent transaction with a sanctioned party.
The following topics are going to be covered in this article;
- What Is Fuzzy Matching, and Why Screening Needs It
- Edit-Distance Algorithms: Comparing Spelling
- Phonetic Algorithms: Comparing Sound
- Token and Hybrid Methods
- Thresholds: The Calibration Decision That Determines Everything
- What Regulators Expect
- How Sanction Scanner Handles Fuzzy Matching
What Is Fuzzy Matching, and Why Screening Needs It
Fuzzy matching is a comparison technique that identifies approximate matches between a customer's details and entries on sanctions lists, Politically Exposed Person (PEP) databases, and watchlists. Unlike exact matching, which requires identical text, fuzzy matching scores how similar two names are and flags results above a set threshold. It is essential in Anti-Money Laundering (AML) screening because names appear in many forms: Spelling variations, transliterations, typos, aliases, and reordered words. Exact matching alone would miss most of these.
Consider a single, ordinary example. "Mohammed," "Muhammad," and "Mohamed" are three spellings of the same name, routinely used for the same person across different documents and jurisdictions. To an exact-matching system, they are three entirely different strings with no relationship to one another. A sanctioned party spelled one way on the sanctions list and another way in a customer record would pass straight through. Fuzzy matching bridges that gap by measuring similarity rather than demanding identity, which is the entire reason it has become the backbone of modern screening.
The variation is not limited to alternative spellings of a single name. It compounds across several independent dimensions at once. A name can be transliterated differently from its original script, so the same Arabic or Cyrillic name arrives in Latin characters in half a dozen valid forms. Word order shifts between cultures and between documents, so a given name and family name swap places. Honorifics, titles, and suffixes attach and detach. Middle names and patronymics appear in one record and vanish in another. Simple keyboard typos introduce errors that follow no linguistic logic at all. Each of these is a routine occurrence in real customer data, and any one of them is enough to defeat an exact match. Fuzzy matching is the response to a naming environment where identical strings are the exception rather than the rule
Edit-Distance Algorithms: Comparing Spelling
The first major family of fuzzy-matching techniques works by comparing spelling directly, counting how much one string would need to change to become another.
Levenshtein distance is the foundational method. It counts the minimum number of single-character edits, meaning insertions, deletions, or substitutions, required to turn one string into another. Turning "Smith" into "Smyth" takes one substitution, so the Levenshtein distance is 1. That raw distance is then converted into a similarity score, typically calculated as 1 minus the distance divided by the length of the longer string, producing a value between 0 and 1. The method is intuitive and performs well on short strings containing simple typos. Its weaknesses are real, though. It treats every character position as equally important, so an error in the first letter costs exactly the same as an error in the middle, even though first-letter errors are far rarer in practice and far more significant when they occur. It also slows down considerably on long strings.
Jaro-Winkler takes a different approach that suits names particularly well. It weights matches at the start of strings more heavily, which reflects how people actually mistype and how transliteration variants tend to preserve the opening of a name while diverging later. This makes it strong for personal names and transliterated variants, and it has become a common default choice for name matching in compliance systems.
Jaccard similarity works on a set-overlap principle, measuring how many tokens or characters two strings share relative to their combined set. It is less sensitive to word order and useful as one component of a broader matching strategy.
Edit-distance methods share a common characteristic worth understanding. They measure surface-level, character-by-character difference, which makes them excellent at catching the small mechanical errors that creep into data entry and transcription. What they do not understand is meaning or sound. To a pure edit-distance algorithm, the leap from a name to its common nickname, or from one transliteration to a phonetically identical but differently spelled one, can look like a large distance even though a human would instantly recognize the two as the same. This blind spot is precisely why edit-distance algorithms are rarely used alone in serious screening, and why the phonetic and token-based families exist to cover what they cannot.
|
Algorithm |
What It Measures |
Best For |
Limitation |
|
Levenshtein distance |
Minimum single-character edits between two strings |
Short strings with simple typos |
Weights all positions equally; slow on long strings |
|
Jaro-Winkler |
Character similarity, weighted toward the start of the string |
Personal names, transliteration variants |
Less effective for major reordering or long-name variation |
|
Jaccard similarity |
Overlap of shared tokens or character sets |
Comparing token sets, order-independent matching |
Ignores character sequence and spelling nuance |
Phonetic Algorithms: Comparing Sound
Edit-distance algorithms compare how names are spelled. Phonetic algorithms compare how they sound, which catches a different and important category of variation.
Soundex is the oldest of these. It encodes a name into a four-character code based on English pronunciation, grouping consonants that sound alike and largely discarding vowels. "Steven" and "Stephen" both encode to the same Soundex value, S315, which lets a system recognize them as the same name despite their different spellings. The limitation is significant. By throwing away most vowel information and by being built around early-1900s English census pronunciation, Soundex is heavily language-specific and struggles badly outside English-language names.
Metaphone and its successor Double Metaphone refine the phonetic approach considerably. They handle far more English pronunciation rules, including silent letters and combinations such as "ph" mapping to an "f" sound. Double Metaphone goes further by returning two codes for names with ambiguous pronunciation, acknowledging that some names can reasonably be pronounced more than one way. These are generally preferred over Soundex for any serious application.
The value of phonetic matching shows up most in multilingual environments, where a name transliterated from another script may be spelled in several ways that all sound essentially the same. A purely spelling-based comparison can miss those connections, while a phonetic layer catches them.
The limitation cuts the other way, too, and it is worth being honest about. Phonetic algorithms encode assumptions about a specific language's pronunciation, and those assumptions do not travel well. A phonetic encoder built for English will mishandle names whose sound patterns follow Arabic, Mandarin, or Slavic rules, sometimes grouping genuinely different names together and sometimes separating identical ones. In a screening context that spans dozens of nationalities, no single phonetic algorithm covers the whole population well. This is one more reason that phonetic matching functions as a component within a larger system rather than a standalone solution, contributing its particular strength while other methods compensate for its blind spots.
Token and Hybrid Methods
The third technique family addresses a problem neither spelling nor sound comparison handles well on its own: The structure and ordering of names.
Token-based methods break a name into its component parts and compare those components independently of their order. This is what allows a system to recognize that "Ali Hassan" and "Hassan Ali" refer to the same person despite the reversed sequence, a reordering that would badly confuse a naive character-by-character comparison. Token methods also handle missing components gracefully, such as a record that includes a middle name matched against one that omits it. The approach is especially valuable given how many naming cultures place the family name first, a convention that guarantees order mismatches the moment records cross between systems built on different assumptions.
Hybrid and combined methods are where modern screening actually operates. No single algorithm handles the full range of real-world name variation, so contemporary systems blend edit-distance, phonetic, and token-based techniques together. Combining Levenshtein with Metaphone, for instance, catches both the typo that changes spelling and the transliteration that changes it while preserving sound. This layering improves accuracy across the diverse, noisy, multilingual data that sanctions screening actually has to process.
On top of these base algorithms, an AI-driven matching layer adds contextual analysis, weighing secondary information and learned patterns to distinguish genuine matches from coincidental ones and to reduce the false positives that raw algorithmic matching inevitably generates.
The logic behind combining methods is straightforward once the individual weaknesses are laid out side by side. Edit distance misses phonetic variants. Phonetic matching misses cross-language cases and struggles with reordering. Token methods handle reordering but say nothing about spelling accuracy within each token. Each family has a gap that another family fills. A system that runs them together, then reconciles their scores into a single judgment, inherits the strengths of all three while letting each cover the others' blind spots. This is why a modern screening engine is best understood not as a single clever algorithm but as an ensemble, with an intelligence layer sitting above the ensemble to weigh the evidence and decide what genuinely warrants an analyst's attention.
Thresholds: The Calibration Decision That Determines Everything
Every fuzzy-matching comparison produces a similarity score. The threshold is the line drawn across those scores: Matches scoring above it get flagged for review, and matches below it are ignored. That single number quietly determines whether an entire screening program works, and setting it is the most consequential configuration decision a compliance team makes.
The tradeoff is unforgiving in both directions. Set the threshold too low and the system floods analysts with false positives, burying genuine risk under thousands of irrelevant alerts and driving the analyst fatigue that causes real matches to be missed in the noise. Set it too high and the system produces false negatives, letting sanctioned parties pass undetected, which is a direct regulatory breach with severe consequences. There is no universally correct number. The defensible setting sits somewhere between those two failure modes, and finding it is an evidence-based exercise rather than a guess.
A sound calibration approach segments customers by risk, applying lower thresholds to higher-risk relationships where the cost of a miss is greatest. It tests the configuration against datasets of known matches to measure precision and recall directly. It tunes thresholds separately for different list types, since sanctions screening demands a stricter setting than PEP or adverse media screening, where the consequence of a miss is a risk-management failure rather than a legal violation. Above all, it documents the rationale, because regulators now expect firms to produce evidence for why a threshold sits where it does.
One trap deserves particular attention. A sophisticated sanctioned party can combine several small manipulations at once, layering a transliteration variant with a missing middle name and a patronymic change. Each individual alteration, on its own, might leave the similarity score comfortably above the alert threshold. Combined, they can push the aggregate score just below the alert point, and the match is lost. This compound-variation problem is exactly why threshold setting cannot be treated as a simple dial, and why testing has to include realistic, multi-layered manipulations rather than single clean variants.
Data quality sits underneath the entire threshold question and often gets overlooked. A perfectly calibrated threshold cannot compensate for incomplete or poor source data. If customer records contain truncated names, missing nationalities, or absent dates of birth, the screening engine has less information to work with and must lean more heavily on name similarity alone, which forces the threshold lower to maintain detection and drives false positives up. Improving the completeness and accuracy of the underlying data frequently does more to improve screening outcomes than any adjustment to the algorithm or the threshold, because it gives the system additional identifiers to confirm or rule out a match. The threshold decision and the data quality question are, in practice, inseparable.
What Regulators Expect
Regulators do not mandate specific algorithms. Neither the Financial Crimes Enforcement Network (FinCEN) in the United States nor the FCA in the United Kingdom tells firms to use Jaro-Winkler or Double Metaphone or any other named technique. What they require is an outcome: A system that effectively handles name variations, aliases, and typographical errors, backed by evidence that its thresholds have been deliberately calibrated and validated.
That expectation has sharpened considerably. When the FCA published its sanctions screening findings on 28 May 2026, drawing on assessments of more than 150 firms, it put matching effectiveness and threshold calibration under direct scrutiny. The regulator found that including honorifics, titles, and suffixes could push match scores below alert thresholds, that some firms could not detect obfuscated or variant names including those in non-Latin scripts, and that many firms relied on vendor assurances without validating the configuration themselves. The message running through the findings is that firms must be able to demonstrate why their thresholds are set where they are, and to show through testing that their screening actually catches the variations it is supposed to catch. Having a system with fuzzy logic built in is no longer sufficient on its own. The firm has to prove it works.
This shift toward evidence-based supervision was not confined to the UK. Across the first half of 2026, regulators in several jurisdictions converged on the same conclusion, publishing findings that screening systems reliably detect exact matches yet fail on manipulated names, and that responsibility for that failure cannot be outsourced to the vendor that supplied the system. The practical consequence for compliance teams is a higher and more specific bar. A firm can no longer point to the existence of a screening tool as evidence of a functioning control. It has to test that tool against realistic name variations, transliterations, and alternative scripts, document the results, justify its threshold choices against its own customer and geographic risk profile, and retest whenever lists or matching logic change. The regulatory expectation has moved from having a system to evidencing its effectiveness, and the difference between those two things is where enforcement now lands.
How Sanction Scanner Handles Fuzzy Matching
Effective name matching in practice is never a single algorithm but a combination, and that is how Sanction Scanner approaches it. The platform blends fuzzy logic with phonetic search to catch both spelling and sound variations, then adds an AI-driven matching layer that brings contextual judgment to each comparison. Secondary identifiers such as date of birth, nationality, and location feed into the decision, allowing the system to separate a genuine match from a coincidental name similarity that would otherwise generate a needless alert.
Thresholds are tuned to a firm's risk appetite rather than left at factory defaults, and whitelisting removes previously cleared matches from the queue so analysts are not asked to re-review the same false positive repeatedly. The combination is designed to hold both sides of the tradeoff at once, maintaining detection of genuinely sanctioned parties while keeping false positive volumes at a level a compliance team can actually work through. That balance, backed by documentation of how the configuration was reached, is precisely what the current regulatory environment demands.
The broader point is that fuzzy matching is not a feature to switch on and forget. It is a living control that has to be configured to a specific institution's risk, tested against the manipulations real evaders actually use, and re-examined whenever the customer base, the sanctions lists, or the matching logic changes. The algorithms described throughout this article are the raw material. Turning them into a screening program that both catches sanctioned parties and remains operationally workable is a matter of combining them well, calibrating them honestly, and being able to show the evidence when a regulator asks. That is the standard the market has moved to, and it is the standard any serious screening program now has to meet.
Sources
[1] Financial Conduct Authority. Sanctions systems and controls in our firms: our findings. 2026.
FAQ's Blog Post
Fuzzy matching validation means proving, with evidence, that your screening catches the variations it should. Regulators now expect firms to test systems against realistic manipulations, transliterations, and non-Latin scripts, document precision and recall, justify threshold choices against their own risk profile, and retest whenever lists or matching logic change, rather than relying on vendor assurances.
Name matching in AML screening is the process of deciding whether a customer name and a watchlist entry refer to the same person, despite messy real-world data. It relies on fuzzy matching algorithms that compare spelling, sound, and structure, since names cross languages, alphabets, and clerical habits that exact matching cannot bridge.
Sanctioned parties slip through name screening when small manipulations combine to push a similarity score just below the alert threshold. A single transliteration variant, a dropped middle name, and a changed patronymic may each be minor alone, but stacked together they can defeat a system that would have caught any one of them individually.
Fuzzy matching can detect transliterated names, but no single algorithm handles every script well. Phonetic methods help when an Arabic or Cyrillic name reaches a watchlist in several Latin spellings that sound alike, while edit-distance and token methods cover typos and word order. Non-Latin scripts remain a known weak point regulators now test for.
Fuzzy matching produces false positives because it flags names that look or sound similar without being the same person, and a lower threshold widens that net. Common names, shared components, and thin customer data all inflate the volume. Secondary identifiers like date of birth and nationality help separate genuine matches from coincidental ones.
Fuzzy matching threshold is the similarity score above which a comparison is flagged for review and below which it is ignored. That single number largely decides whether screening works: Set it too low and analysts drown in false positives, set it too high and sanctioned parties pass undetected. It should be calibrated with evidence.
Soundex and Metaphone are both phonetic algorithms that match names by sound, but Metaphone is more advanced. Soundex reduces a name to a four-character code from English pronunciation and discards most vowels. Metaphone and Double Metaphone handle far more pronunciation rules, including silent letters and combinations like ph sounding as f.
Jaro-Winkler is an edit-distance method that weights matching characters at the start of a name more heavily. This suits personal names and transliterated variants well, because both typos and transliterations tend to preserve the opening of a name while diverging later. It has become a common default for name matching in compliance systems.
Levenshtein distance counts the minimum number of single-character edits, meaning insertions, deletions, or substitutions, needed to turn one string into another. Turning Smith into Smyth takes one substitution, so the distance is 1. That raw count is usually converted into a similarity score between 0 and 1 for screening.
Fuzzy matching scores how similar two names are and flags anything above a set threshold, while exact matching only catches identical text. In sanctions screening this matters because names arrive with spelling variations, transliterations, typos, and reordered words, so exact matching alone would miss most sanctioned parties that fuzzy matching is built to catch.
