TL;DR: Sanctions screening name matching compares customer and payment names against watchlist entries using approximate rather than exact comparison, because one person can legitimately appear under dozens of spellings. Engines layer several algorithms, then apply a threshold that trades missed hits against false positives. The FCA's May 2026 review found firms' systems correctly identified the sanctioned party in 90 percent of test alerts on exact names but only 75 percent on slight variants. Threshold policy, normalization, and secondary identifiers matter more than the choice of algorithm.
Why Exact Matching Fails on Real Names
Exact string comparison fails because a name is not a fixed string. It is a rendering of a spoken identity into whatever script and convention a data entry system enforced. The SDN list carries aliases for this reason, and OFAC's 2019 Framework for OFAC Compliance Commitments lists failure to account for alternative spellings of prohibited parties among the root causes of past enforcement actions.
Transliteration is the largest source of variation. Muhammad, Mohammed, Mohamed, and Mohammad are all standard renderings of one Arabic name, and the Federal Reserve's 2025 FEDS paper on fuzzy matching notes that Russian, Arabic, Chinese, and Farsi are the most represented origin languages on the OFAC lists. Name order and structure add another layer: family-name-first conventions, Spanish double surnames, and Russian patronymics mean Ivan Sergeyevich Petrov may be captured as Ivan Petrov, I. S. Petrov, or Petrov Ivan. Nicknames, initials, titles, and honorifics change the string without changing the person. Corporate suffixes vary by jurisdiction and typist: Ltd and Limited, LLC and L.L.C., OOO and its Cyrillic original. Then come typos, field-length truncation, and deliberate evasion: inserted characters, names split across fields, lesser-known aliases. A screening engine has to tolerate all of this without alerting on every Mohammed Ali in the customer base.
The Algorithms Under the Hood
No single algorithm handles all of that variation, so production engines layer several. Edit distance, usually Levenshtein, counts the insertions, deletions, and substitutions needed to turn one string into another. It handles typos well and transliteration badly, because every substitution costs the same: MOHAMMED and MUHAMMAD differ in two positions out of eight, roughly 75 percent similarity, well below the 85 percent cutoff many programs use. Jaro-Winkler counts matching characters within a sliding window, penalizes transpositions, and rewards a shared prefix. Its weakness is token order: compared as full strings, Petrov Ivan and Ivan Petrov score poorly.
Phonetic algorithms address sound rather than spelling. Soundex reduces a name to a first letter plus three digits from English consonant classes, so Smith and Smyth share a key; Double Metaphone emits two keys where a name has alternate pronunciations. All three are English-centric, and Soundex collapses many unrelated names into one key. Token-based methods split names into parts and compare the sets using Jaccard similarity or token sort and token set ratios; they handle reordered and missing middle names and struggle on single-token names. Character n-grams tolerate errors anywhere in the string and usually serve as the index that narrows millions of list entries to a few hundred candidates.
Two further layers sit on top. Name-culture-aware normalization identifies a name's likely origin and applies rules specific to it: handling the Arabic definite article, stripping patronymics, expanding corporate suffixes. The Federal Reserve researchers built such a routine and reported that it is brittle; expanding every St. to Street breaks St. Mary's Lane. The second layer is a learned reranker that scores each retrieved candidate using every available field. The same Fed study found that large language models used this way cut false positives by 92 percent and increased detection by 11 percent relative to the best fuzzy baseline, while running four orders of magnitude slower, so the authors propose a cascade that sends only uncertain cases to the model.
What OFAC's Own Tool Actually Does
OFAC's Sanctions List Search is the industry's most referenced fuzzy scorer. According to OFAC FAQ 249, the tool first filters on the first letter of each search term and an edit-distance similarity of at least 50 percent, then computes two scores: Jaro-Winkler on the full name string, and a composite in which each name part is scored with Jaro-Winkler and Soundex. It returns the higher of the two. The slider defaults to 100, and OFAC's FAQs on the tool state that OFAC cannot recommend a threshold because each search has its own facts.
Even the reference point has quirks. In July 2026, OpenSanctions published an account of reverse-engineering the OFAC scorer and found that its Jaro-Winkler applies the prefix bonus unconditionally, skipping the 0.7 base-score guard that standard libraries enforce. With that one change, OpenSanctions reached 96 percent agreement with the tool. "Our engine matches what SDN Search matches" is a claim to test, not assume.
Why "Set It to 85 Percent" Is Not a Policy
A threshold is a point on a curve, not a setting. Lowering it catches more legitimate variants and more false positives; raising it does the reverse. 85 on Jaro-Winkler and 85 on a normalized Levenshtein ratio describe different populations of pairs. A two-character difference is a small share of a 16-character corporate name and a large share of a short personal name. And where the pool of common given and family names is small, unrelated people sit closer together in similarity space, so one threshold yields different false positive rates by segment.
The FCA's 2023 review of more than 90 firms found calibration that failed in both directions: too sensitive, flooding teams with false positives, or not sensitive enough, so that minor name variations let sanctioned individuals through. The Wolfsberg Group's Sanctions Screening Guidance treats how exact or fuzzy to set the filter as a risk-based decision that must be documented and supported by analysis and testing.
A defensible policy states which algorithms run against which lists and fields, what threshold applies to each segment, how weak aliases are treated, and what sample testing above and below each threshold showed. Teams that answer a growing screening alert backlog by nudging the slider up are making a detection decision without evidence. Sphinx has written about what actually reduces false positives; threshold changes alone rarely make the list.
Secondary Identifiers Do the Disambiguation
A name score cannot separate the sanctioned Mohammed Ali from the customer named Mohammed Ali. Date of birth, nationality, passport and registration numbers, BICs, gender, and address can. Engines use them at match time as penalties: OpenSanctions' OFAC emulator lowers a score when a candidate's country, date of birth, gender, or registration identifier contradicts the query. Many list entries carry sparse identifiers, and a missing date of birth is not a mismatched one. An engine that treats absence as a penalty will quietly suppress hits it should surface.
What Regulators Expect From the Matching Layer
Regulators do not prescribe algorithms. They expect institutions to understand and evidence what their engine does. The FFIEC BSA/AML Examination Manual's OFAC section says screening criteria should be able to identify name variations and misspellings and that a high volume of false hits may signal a need to review the interdiction program, and its examination procedures tell examiners to test a filter by entering names similar to recent list additions.
The FCA's May 2026 findings, drawn from more than 150 firms assessed since 2022, show what that testing surfaces. In the FCA's own screening tests, 90 percent of alerts correctly identified the sanctioned party on exact names and 75 percent on slightly varied ones. The FCA also found honorifics pushing scores below alert thresholds, one-word names and names containing digits excluded by default, and long names exceeding character limits and failing silently. Anyone evaluating sanctions screening software should treat the ability to explain the matching logic internally as a requirement.
Validate the Engine Like a Model
A screening engine with configurable algorithms and thresholds is a model in the supervisory sense. On April 17, 2026, the Federal Reserve, OCC, and FDIC issued SR 26-2, which supersedes both SR 11-7 and the 2021 interagency statement on model risk management for BSA/AML systems with a risk-based framework aimed primarily at institutions above $30 billion in assets. The principles carry over: conceptual soundness, ongoing monitoring, outcomes analysis, and effective challenge.
Synthetic variant testing is the most direct outcomes analysis for a matcher. Take a sample of list entries and generate variants in each failure class: a vowel-swap transliteration, a reordered name, a dropped patronymic, an added title, a changed corporate suffix, a single typo, an injected character. Run them through the production filter and record detection by class, then run known-clean customer names to measure the false positive rate at the same settings. Sphinx has covered AML model validation requirements in more depth.
The Analyst's Job After the Match
A hit is a hypothesis that the customer and the list entry are the same party. Clearing it requires evidence that they are not. Strong evidence is a contradiction on a hard identifier: a different date of birth, a different nationality, a different passport or registration number. Weak evidence is what appears most often in cleared alerts: the name is common, the customer has been around for years, the score was only just over the line.
Every disposition needs the rationale written against the specific identifiers compared. The FCA's 2026 review flagged falsely discounted positive matches as a recurring cause of breaches. Teams looking to reduce screening alert review time should look at how the comparison is performed and documented, not at how many alerts are allowed to fire.
Where Sphinx Fits
Sphinx does not set thresholds or replace the matching engine. Sphinx's agents pick up screening hits after the engine has scored them, gather the list entry's identifiers and the customer record, compare them field by field, and write the reasoning for each disposition in a form an auditor can sample. Where identifiers contradict, the agent clears the hit and cites the contradiction; where they are missing or consistent, it escalates. The name score opens the alert. The documented comparison closes it.
Frequently Asked Questions
What is fuzzy name matching in sanctions screening?
Fuzzy name matching compares a customer or payment name against sanctions list entries using similarity scores rather than exact equality, so spelling variants, transliterations, and reordered name parts can still produce a hit. Engines typically combine edit distance, Jaro-Winkler, phonetic keys, and token-based comparison, then alert when the score exceeds a configured threshold.
What match threshold should a sanctions screening system use?
No single number is correct, because the same threshold means different things across algorithms, name lengths, and customer populations. OFAC, the FCA, and the Wolfsberg Group expect thresholds to be set through a documented risk-based decision supported by testing above and below the chosen setting.
How do secondary identifiers reduce false positives?
Date of birth, nationality, identification numbers, gender, and address can contradict a name match and either lower its score or give an analyst grounds to clear it. A missing field is not a mismatch; only a genuine contradiction is evidence.
Is a sanctions screening engine subject to model risk management?
Yes. U.S. banking regulators treated BSA/AML screening systems as models under SR 11-7 and the 2021 interagency statement, both superseded on April 17, 2026 by SR 26-2. Conceptual soundness, ongoing monitoring, outcomes analysis, and effective challenge still apply, and synthetic name-variant testing is the most direct way to evidence performance.
.png)
