Sanctions Screening Configuration: Fuzzy Matching, Thresholds and False-Positive Tuning

OFAC applies strict liability to sanctions violations: no intent or knowledge is required for a business to be held responsible. That standard is why screening-threshold configuration carries real financial weight rather than being a background system setting. In July 2025, Interactive Brokers settled with OFAC for $11,832,136 over 12,367 apparent violations spanning multiple sanctions programs, a case rooted in blocked-persons and jurisdictional screening gaps rather than name-matching alone, but a clear illustration of how screening configuration failures compound into eight-figure exposure. A separate manufacturer paid $4.4 million for 223 missed matches caused by an outdated sanctions list, a more direct example of what a poorly tuned name-screening configuration costs.

For a payments business screening across multiple jurisdictions, getting that configuration right means understanding both how matching actually works and where the threshold trade-off sits.

Why this isn't optional

The OFAC Specially Designated Nationals (SDN) List is the primary US reference set, and the maximum civil penalty for a violation under the International Emergency Economic Powers Act runs to $377,700 per violation, or twice the transaction value, whichever is greater. Penalties accrue per violation, which is how a few hundred missed matches compound into millions in fines. On the crypto side specifically, OFAC publishes SDN-listed wallet addresses and expects VASPs to screen against them directly; the pseudonymous nature of a blockchain transaction doesn't change the obligation.

In the EU, the equivalent reference is the Consolidated List of persons, groups and entities subject to EU financial sanctions, maintained by the European Commission and reflecting officially adopted Council decisions. Financial institutions carry particular responsibility here since they handle the bulk of the transactions these sanctions are designed to catch.

How matching actually works

Screening systems combine several techniques, each suited to a different kind of name variation:

Exact matching — direct string comparison. Effective for standardised identifiers, but insufficient on its own since it misses any spelling variation.
Fuzzy matching — algorithms like Levenshtein distance or Jaro-Winkler similarity that score how close two strings are, catching typos, transpositions, and minor spelling differences.
Phonetic matching — Soundex or Metaphone-style algorithms that match names by how they sound, useful for transliteration across languages (Mohammed vs. Muhammad vs. Mohamed).
Token-based matching — breaking names into components and matching each part, useful for multi-part names or names presented in different orders.

Each technique has a failure mode. Exact matching misses transliterations entirely and fuzzy matching catches more variation but generates more noise. Phonetic matching is strong for cross-language names but weak for structurally different name orders, which is where token-based matching picks up the slack.

The threshold trade-off

A configurable match threshold decides which results get flagged for review. Set it too loose, and the system generates an unmanageable volume of false positives; common names collide constantly with SDN entries, so most name matches at a loosely tuned threshold turn out to be false. Set it too tight, and the system misses genuine matches, the failure pattern behind the manufacturer's $4.4 million penalty.

The Wolfsberg Group's Sanctions Screening Guidance frames this as a risk-based exercise: screening effectiveness depends on an institution's specific data, customer base, and inherent sanctions exposure, and the guidance is explicit that not every institution should apply every control to the same degree. OFAC's own framing runs parallel to this — tools should be commensurate with risk profile, so a high-volume payments processor needs real-time automated screening, while a business with lower transaction velocity and a narrower customer base can run a lighter configuration. The threshold that fits is the one tested against actual hit-review data for your own exposure, not one copied from a vendor default or a peer institution.

Recent research points toward where this is heading. A 2025 Federal Reserve working paper found that large language models reduced sanctions screening false positives by 92% and improved detection rates by 11% compared with the best-performing fuzzy-matching baseline, though at meaningfully slower processing speeds. The paper's proposed approach is a cascade: fast fuzzy and exact matching handle clear cases, while ambiguous ones escalate to slower, more accurate LLM review. That tiered structure is a useful model for any screening configuration regardless of which specific technology sits underneath it.

The multi-list reality for a cross-border payments business

A business operating a single regulated entity in a single jurisdiction can tune one threshold against one list. That's not the situation most cross-border payment businesses are actually in. A firm with regulated entities across Cyprus, the UK, and elsewhere is screening the same customer base against OFAC's SDN list, the EU consolidated list, and the UK's own sanctions list simultaneously, and the UK's list itself changed shape recently: the UK moved to a single consolidated Sanctions List on 28 January 2026, closing the previous OFSI Consolidated List it had run separately.

Running one threshold across all of that leaves gaps rather than saving effort. Each list has its own update cadence, its own naming conventions, and its own regulator watching for gaps. A configuration tuned against OFAC's SDN list alone won't necessarily perform the same way against the EU or UK lists, since the underlying name data, transliteration conventions, and entity-type coverage differ across all three.

This also runs into a practical operational constraint worth naming directly: where alert review still sits with human analysts working through a largely manual process rather than an automated rules engine, threshold tuning has a direct effect on analyst workload, not just on system output. A threshold set without regard for review capacity shifts the compliance risk from missed matches to unreviewed alerts, a failure that looks just as bad to a regulator as a threshold set too loose in the first place.

Screening-config guide and false-positive tuning checklist

Matching-technique guide by scenario:

Multi-part or reordered names (common in Arabic, Slavic, and East Asian naming conventions) → weight token-based matching higher.
Transliteration-heavy corridors (names moving between scripts, e.g., Cyrillic or Arabic to Latin) → weight phonetic matching higher.
High-volume, low-variation customer data (standardised onboarding fields) → exact and lighter fuzzy matching can carry more of the load without excessive review burden.
Wallet-address screening → match directly against OFAC's published SDN wallet addresses; this is a distinct data set from name-based SDN matching and needs its own configuration.

False-positive tuning checklist:

Track true-positive rate against total alerts generated at the current threshold, not just total alert volume.
Re-test threshold performance after every list update, since new entries change the shape of what counts as a near-match.
Document the rationale for wherever the threshold currently sits. Wolfsberg's guidance treats this kind of documented, risk-based justification as an expectation, not a nice-to-have, if the configuration is ever questioned during examination.
Size the threshold against actual review capacity. A threshold generating more alerts than can be properly investigated creates the same compliance exposure as a threshold set too loose to catch real matches.
Where multiple sanctions lists apply (OFAC, EU, UK, or others), tune each independently rather than assuming one threshold transfers across lists with different data conventions.

Frequently asked questions

Why does sanctions screening threshold configuration matter financially?

OFAC applies strict liability, meaning no intent or knowledge is required for a violation. Penalties accrue per violation under IEEPA, up to $377,700 or twice the transaction value, which is how a few hundred missed matches compound into millions in fines.

What's the difference between fuzzy and phonetic matching?

Fuzzy matching (Levenshtein distance, Jaro-Winkler) scores how close two strings are, catching typos and spelling variations. Phonetic matching (Soundex, Metaphone) matches names by how they sound, which is stronger for cross-language transliteration but weaker for reordered name structures.

What happens if a sanctions screening threshold is set too loose or too tight?

Too loose generates an unmanageable volume of false positives, since common names collide constantly with SDN entries. Too tight risks missing genuine matches, the failure pattern behind a real $4.4 million penalty a manufacturer paid for 223 missed matches from an outdated list.

Do businesses need to screen against multiple sanctions lists?

Yes, if operating across jurisdictions. A firm with regulated entities in Cyprus, the UK, and elsewhere screens the same customer base against OFAC's SDN list, the EU consolidated list, and the UK's own sanctions list simultaneously, each with different naming conventions and update cadences.

Can AI improve sanctions screening accuracy?

A 2025 Federal Reserve working paper found large language models reduced false positives by 92% and improved detection by 11% versus the best fuzzy-matching baseline, though at slower processing speeds, using a cascade where fast matching handles clear cases and AI reviews ambiguous ones.