August 13, 2026

Fuzzy Name Matching in Sanctions Screening, Explained

Axle Team

Key takeaways

Exact-match screening fails in predictable ways — transliteration, alternative spellings, word order, weak aliases. OFAC has cited failure to account for alternative spellings as a root cause of enforcement actions.
Fuzzy name matching tolerates those variations using string-distance algorithms (Jaro-Winkler, edit distance) and phonetic algorithms (Soundex) — the same techniques OFAC's own Sanctions List Search uses.
There is no regulator-blessed match threshold. OFAC's stated expectation is that you calibrate screening tools to your risk profile and routinely test them.
False positives concentrate in short and single-token names, so per-field and length-aware thresholds usually beat a single global setting.
Alert adjudication — not match generation — is where screening programs spend their money, and where AI agents change the economics.

Fuzzy name matching in sanctions screening compares customer and counterparty names against sanctions lists using algorithms that tolerate spelling variation, transliteration, and word-order differences — typically string-distance measures such as Jaro-Winkler combined with phonetic algorithms such as Soundex. It exists because exact matching misses sanctioned parties; the cost is false positives, which threshold calibration and adjudication workflows have to absorb.

This post explains how the matching actually works, what OFAC has said about screening failures, and how to calibrate thresholds without drowning your team in alerts.

How fuzzy name matching works in sanctions screening

The most useful reference implementation is OFAC's own. The agency's public Sanctions List Search tool scores potential matches with a documented, two-algorithm approach:

"Sanctions List Search then uses two matching logic algorithms, and two matching logic techniques to calculate the score. The two algorithms are Jaro-Winkler, a string difference algorithm, and Soundex, a phonetic algorithm."
— OFAC FAQ 249, "How is the Score calculated?"

Per the same FAQ, the tool first pre-filters candidates by first letter and by edit distance (at least 50% similarity), then runs two techniques: comparing the full name string with Jaro-Winkler, and splitting the name into parts and comparing each part with both Jaro-Winkler and Soundex. The search returns the higher of the two scores. Commercial screening engines build on the same foundations and add normalization (case, diacritics, honorifics), transliteration handling, token reordering, and corroboration against secondary identifiers like date of birth, nationality, and SWIFT BICs.

String similarity vs. phonetics

The two algorithm families catch different failure modes. Jaro-Winkler measures character-level similarity and weights agreement at the start of the string, which makes it good at typos and truncations. Soundex encodes how a name sounds, which is what catches Mohammed / Muhamad or Aleksandr / Alexander. Neither handles word order or split tokens on its own — which is why real engines compose several techniques and score against name parts, not just whole strings.

Why exact matching fails — and what OFAC says about it

This isn't hypothetical. The appendix to OFAC's Framework for Compliance Commitments catalogs root causes drawn from actual enforcement actions, and screening filter faults are on the list:

"At times, organizations have failed to update their sanctions screening software to incorporate updates to the SDN List or SSI List, failed to include pertinent identifiers such as SWIFT Business Identifier Codes for designated, blocked, or sanctioned financial institutions, or did not account for alternative spellings of prohibited countries or parties—particularly in instances in which the organization is domiciled or conducts business in geographies that frequently utilize such alternative spellings (i.e., Habana instead of Havana, Kuba instead of Cuba, Soudan instead of Sudan, etc.)"
— A Framework for OFAC Compliance Commitments, Appendix (root causes)

Read that list again as a test plan: list-update latency, missing identifier coverage, and alternative spellings. If your screening engine were audited against just those three failure modes from OFAC's own enforcement history, would it pass? An exact-match-only filter fails the third one by construction.

Calibrating match thresholds: the actual work

No regulator publishes a correct match threshold, and OFAC won't bless your 85. What the Framework does state is a calibration and testing expectation for the technology behind your internal controls:

"To the extent information technology solutions factor into the organization's internal controls, the organization has selected and calibrated the solutions in a manner that is appropriate to address the organization's risk profile and compliance needs, and the organization routinely tests the solutions to ensure effectiveness."
— A Framework for OFAC Compliance Commitments, Internal Controls

"Selected and calibrated" and "routinely tests" are the operative phrases. A defensible tuning process looks like this:

Build a labeled test set. Known-true matches — including transliterated, misspelled, and reordered variants of listed names — plus known-false pairs pulled from your own historical alerts.
Measure, don't inherit. Run the test set across candidate thresholds and record miss rate and false-positive rate at each. Vendor defaults were tuned on someone else's customer base.
Set thresholds per list and per field. Missing an SDN match and missing a PEP association are not equivalent risks; a single global threshold pretends they are.
Handle weak aliases explicitly. OFAC itself distinguishes weak AKAs; letting them alert at full strength buries your team without adding coverage.
Document and re-test. Record the rationale for every setting, and re-run the test set after list updates, engine upgrades, and material changes in your customer population.

One pattern we see consistently in screening queues: false positives aren't uniformly distributed — they concentrate in short and single-token names, where a high similarity score is nearly meaningless. "Ali," "Chen," or "Lee" at a 90 score tells you almost nothing; a 90 on a four-token corporate name tells you a lot. A length-aware policy — requiring secondary-identifier corroboration (date of birth, country, entity type) before alerting on short names — cuts more noise than lowering the global threshold five points, and does it without the coverage loss that a blanket change causes. Most teams tune the global number because it's the knob the vendor exposes; the better knob is usually match policy by name shape.

The real cost center: adjudicating the alerts

Fuzzy matching decides how many alerts you get; adjudication decides what they cost. Every potential match needs the same routine: compare secondary identifiers, check whether the hit is a weak alias, review the customer's profile, and write down why it is or isn't your party. That work is structured and evidence-based, which is why it's one of the first places AI agents earn their keep in a screening program.

Axle's screening agent Baley adjudicates name-match alerts the way a trained analyst does — weighing match strength against corroborating identifiers and producing a documented disposition for human review — as part of the broader Axle platform. If you're earlier in the evaluation process, the AI readiness playbook covers how to prepare your screening stack and procedures for agents.

FAQ

What match threshold should I use for sanctions screening?

There is no regulator-published number, and OFAC's Sanctions List Search default slider is not guidance for your program. The defensible answer is a threshold (or set of thresholds) derived from testing against a labeled data set, documented with a risk-based rationale, and re-validated when lists, engines, or your customer base change.

Does OFAC require fuzzy matching?

No rule mandates a specific algorithm. But OFAC's enforcement history — including root-cause findings about screening software that "did not account for alternative spellings" — makes exact-match-only screening very hard to defend for any institution with meaningful sanctions exposure.

What is the difference between sanctions screening and transaction monitoring?

Sanctions screening is a point-in-time check of names and payment parties against sanctions lists, typically pre-settlement and often blocking. Transaction monitoring evaluates behavior over time to detect suspicious activity for SAR purposes. Different rules, different deadlines, different failure modes — and both are needed.

Spending analyst hours clearing name-match false positives? See how Baley adjudicates screening alerts with documented, reviewable dispositions. See how Baley works →

Fuzzy Name Matching in Sanctions Screening, Explained

More from the blog