Table of Contents
Fuzzy name matching in sanctions screening is the technique that catches a banned party even when the name is spelled differently. Sanctioned people and companies rarely appear in your records exactly as they sit on a government list. Names get transliterated, misspelled, reordered, or shortened. Fuzzy matching bridges that gap. It compares two names that are not identical and scores how close they are.
Get it wrong and you either drown in false alerts or miss a real hit. Both are expensive. This guide explains how fuzzy matching works, the main algorithms, how to set thresholds, and how to handle the edge cases that break weaker systems. It is meant to be practical. If you run screening for a living, you should be able to act on this.
Why exact matching is not enough
Exact matching only flags a name that is character-for-character identical to a list entry. That sounds safe. It is not. A single extra space, a dropped middle name, or a different spelling of the same Arabic or Russian name will slip past it. Bad actors know this. They alter spellings on purpose to dodge screening.
Real customer and shipment data is messy. You get typos, nicknames, initials, and names in the wrong order. You screen against lists like the OFAC Specially Designated Nationals list, the BIS Entity List, and the Consolidated Screening List. Each list has its own formatting quirks. Fuzzy matching exists because names in the real world do not line up cleanly. For more on the SDN list itself, see our guide on denied party screening and the OFAC SDN list.
How fuzzy name matching works
A fuzzy matching engine takes the name you are screening and each name on the list. It calculates a similarity score between them. The score usually runs from 0 to 100, where 100 is an exact match. You then set a threshold. Anything at or above that score becomes an alert for a human to review.
Here is a simple view of how scores tend to land.
| Name pair | Type of variation | Rough similarity |
|---|---|---|
| Mohammed / Mohammed | Exact | 100 |
| Mohammed / Muhammad | Spelling variant | ~85 |
| Robert Smith / Bob Smith | Nickname | ~70 |
| Ivan Petrov / Petrov Ivan | Reordered tokens | ~90 if order-aware |
Good engines look at several signals at once. They weigh phonetic sound, character distance, token order, and partial matches. The final score blends these signals. That is why two engines can rate the same pair differently.
The main matching algorithms
You do not need to build these yourself. You do need to know what your vendor uses, because each method has clear strengths and weak spots.
Edit distance
Levenshtein distance counts the edits needed to turn one name into another. Changing “Carl” to “Karl” takes one edit. Jaro-Winkler is a related method that rewards names sharing the same start. These methods are fast and good for typos. Their weakness is that they treat all character swaps the same. A “c” to “k” swap sounds alike, but a “c” to “p” swap does not, and edit distance scores them equally.
Phonetic matching
Soundex, Metaphone, and Double Metaphone group names that sound the same. Cyndi, Candy, and Condie can share one phonetic code. This catches names heard and then spelled by different people. Phonetic methods run fast and have high recall. The catch is that they are built around English sounds. They struggle with non-Latin scripts and transliterated names.
Token and statistical methods
Token-based matching compares names word by word, so it handles reordered names and missing middle names. Statistical models train on real matching pairs to learn what counts as similar. These can match across languages without transliteration, but they run slower and need expertise to build and maintain. Most strong screening tools combine several of these methods rather than relying on one.
Setting your match threshold
The threshold is the score at which the system raises an alert. Set it too high and you miss real matches. Set it too low and your team buries itself in false positives. There is no single correct number. The right threshold depends on your risk, your data quality, and your review capacity.
Use these steps to tune it with evidence instead of guesswork.
- Review past alerts. Look at which scores produced true matches and which produced noise.
- Run test data through different threshold settings. Watch how alert volume shifts.
- Test known aliases and transliterations. Confirm they still trigger an alert.
- Use different thresholds for different risk segments. A high-risk market can warrant a lower, more sensitive threshold.
- Review the settings on a regular schedule. Lists and customer bases change.
Numbers like 85 or 70 get thrown around as examples. Treat them as starting points, not standards. Your own alert history is the better guide. For a deeper comparison of tuning by hand versus by system, read automated vs manual denied party screening.
The false positive problem
False positives are the daily cost of fuzzy matching. A low threshold flags common names like “John Smith” against dozens of list entries. Each alert needs a human to clear it. That work is slow, and analyst fatigue leads to real hits being waved through by mistake.
You reduce false positives without going blind by adding context to the match. Score more than the name alone.
- Use date of birth, nationality, or address to confirm or dismiss a name hit.
- Apply secondary identifiers for entities, such as country and registration data.
- Keep clear records of why each alert was cleared, so the next reviewer sees the reasoning.
- Whitelist known good parties you have already cleared, and re-check them when lists update.
Clearing an alert is not the same as ignoring it. Every dismissal should have a documented reason. Our guide on how to resolve a false positive walks through the review steps.
Hard cases that break weak systems
Some name problems trip up basic matching. Plan for them.
Transliteration
Arabic, Russian, and Chinese names get written in the Latin alphabet in many ways. One Arabic name can appear as Mohammed, Muhammad, or Mohamad. Your engine must treat these as the same person. Phonetic methods built only for English will miss some of these.
Name order and structure
Some cultures put the family name first. Some people carry multiple surnames or patronymics. A match engine that assumes first-name-then-last-name will fail on these. Token-based matching that ignores word order handles them better.
Company names and ownership
Business names carry noise words like “Ltd,” “Trading,” and “Group.” Strip or down-weight those before matching. Screening also has to look past the named entity to its owners. Under OFAC’s rule, an entity owned 50 percent or more by sanctioned parties is itself blocked, even if it is not named. See the 50 percent rule in sanctions screening for how that changes your matching scope.
Fitting fuzzy matching into your screening program
Fuzzy matching is one part of a screening program, not the whole thing. It works best inside a defined process with clear ownership. You screen against official government lists, and you can check names directly against the OFAC Sanctions List Search when you need to confirm a hit by hand.
Build the matching engine into a full workflow. Decide when to screen, who reviews alerts, and how you record outcomes. Start with our denied party screening hub for the big picture, and use the step-by-step process for denied party screenings to structure the review. A written procedure keeps results consistent when staff change.
Keep an audit trail of every screen and every decision. Regulators expect to see it. Our note on record keeping for denied party screening covers what to retain and for how long.
Frequently Asked Questions
What is a good fuzzy match threshold for sanctions screening?
There is no universal number. Many teams start near 80 to 85 percent and adjust from there. The right level comes from reviewing your own past alerts and testing sample data. High-risk segments usually get a lower, more sensitive threshold.
What is the difference between fuzzy matching and exact matching?
Exact matching flags only names that are identical, character for character. Fuzzy matching scores how similar two different names are and flags close ones. Exact matching misses misspellings and transliterations. Fuzzy matching catches them but produces more false positives.
Why does fuzzy matching produce so many false positives?
Common names match many list entries at once. A low threshold makes this worse. You cut the noise by adding secondary data like date of birth and nationality, and by whitelisting parties you have already cleared.
Can fuzzy matching handle non-English names?
It can, but only if the engine is built for it. Names transliterated from Arabic, Russian, or Chinese need methods beyond English phonetics. Ask your vendor how they handle transliteration and name order before you rely on the tool.
Key Takeaways
Fuzzy name matching is what makes sanctions screening work on real, messy data. Exact matching alone lets altered spellings and transliterations through. Know which algorithms your engine uses, tune your threshold with your own alert history, and add secondary identifiers to control false positives. Plan for the hard cases: transliteration, name order, and company ownership. Keep a clear audit trail of every decision. If you want help building or reviewing a screening process around these ideas, contact us.