Reducing False Positives in Sanctions Screening: Fuzzy Name Matching, Aliases and Date-of-Birth Filters

Most sanctions screening programs have the same problem. The system finds plenty of potential matches, and nearly all of them turn out to be someone else. Analysts spend their days clearing alerts for customers who happen to share a common surname with a listed person, and the alerts that matter get the same tired attention as the rest.

This post covers the practical tuning work behind screening that stays strict but generates less noise: cleaner input, smarter fuzzy matching, careful alias handling, and secondary identifiers such as date of birth.

Why False Positives Happen

A sanctions list entry is often thin. It may include a name, a few aliases, a partial date of birth and a nationality. Your customer record may be equally thin, or worse, typed by hand with errors. When the matching engine has only a name to compare, it has to be permissive to avoid missing a true hit. Permissive matching against common names produces volume.

The goal is to match on names loosely enough that you catch spelling variations and transliterations, and then use every other available data point to separate real matches from coincidences.

Start With Clean Input Data

Many false positives come from the customer side of the comparison. Hand-entered names contain typos, swapped first and last names, missing middle names and nicknames. Each of these either creates spurious matches or forces looser thresholds.

Extracting identity data directly from the ID document is the most effective fix:

• Document OCR captures the full legal name as printed rather than as the customer chose to type it.
• MRZ and barcode reading provide structured fields with an explicit surname and given-name split, a full date of birth and a nationality code.
• Document authentication confirms that the data comes from a genuine document, so you are not screening a fabricated identity.

Structured name fields matter more than they appear to. If your engine knows which token is the surname, it can weight that token appropriately instead of treating "Lee" as a surname and a given name with equal suspicion.

Fuzzy Name Matching That Fits the Data

Exact matching misses too much, and naive fuzzy matching flags too much. A layered approach usually works better than a single similarity score.

Normalize Before You Compare

Before running any similarity algorithm, normalize both sides consistently:

• Fold case and strip diacritics, while keeping the original for audit.
• Remove honorifics and titles such as Mr, Dr or Sheikh.
• Standardize punctuation, hyphens and spacing.
• Handle common particles such as "al", "bin", "van" and "de" consistently.

Combine Several Techniques

Different algorithms catch different kinds of variation:

• Edit distance handles typos and minor spelling differences.
• Phonetic matching catches names that sound alike but are spelled differently.
• Token-based matching handles reordered names, so "Ahmed Hassan Ali" and "Ali Ahmed Hassan" compare sensibly.
• Transliteration-aware comparison accounts for the many valid Latin spellings of names originally written in Arabic, Cyrillic or other scripts.

Tune Thresholds on Your Own Data

There is no universal correct threshold. Run historical customer data through the engine, review the alerts at different score cut-offs, and choose a level you can defend. Document the testing, because regulators and auditors will ask how you set it. Revisit the threshold when your customer base or list coverage changes.

Handling Aliases Without Drowning in Them

Sanctions entries frequently include multiple aliases, and they are not all equally useful. Some lists distinguish between strong aliases, which are names a person is actually known by, and weak aliases, which are broad nicknames or partial names that are unreliable on their own.

Treat these differently:

• Screen strong aliases with the same rigor as the primary name.
• For weak aliases, require additional corroboration before raising an alert, such as a matching date of birth or nationality.
• Do not run very short or single-token aliases through loose fuzzy matching. They will match large portions of your customer base.

Keep alias handling rules explicit and versioned so you can explain why a given alert was or was not raised.

Date-of-Birth and Other Secondary Filters

Once a name match crosses the threshold, secondary identifiers are where most noise disappears.

Use Date of Birth Carefully

A reliable date of birth from the customer's document is a powerful discriminator. Common rules include:

• Clear or down-rank a candidate when the full dates of birth clearly conflict.
• Allow tolerance when the list entry gives only a year, a range or several possible dates.
• Watch for day-month transposition, which is a common data error across date formats.

Add Nationality, Gender and Document Data

Nationality, gender and, where listed, document numbers can each strengthen or weaken a candidate. Treat these as score adjustments rather than hard exclusions, since list data can be incomplete and people can hold multiple nationalities.

Building a Review Workflow That Learns

Tuning is never finished. A sustainable process includes:

• Risk-ranked alert queues so the strongest candidates are reviewed first.
• Recorded dispositions with a written rationale for every cleared alert.
• Managed good-guy lists that suppress repeat alerts for customers already cleared against a specific list entry, with re-review when that entry or the customer's data changes.
• Quality sampling of cleared alerts to confirm that analysts and rules are not clearing true hits.

Track alert volume and disposition outcomes over time. If a particular rule or alias generates alerts that are almost always cleared, that is a signal to review it, not simply to delete it.

Putting It Together

Lower false positives come from the whole pipeline, not from a single threshold. Capture identity data from verified documents, normalize and match names with several complementary techniques, treat aliases according to their quality, and use date of birth and other identifiers to separate real matches from coincidences. Document every choice so the program stands up to scrutiny.