Fuzzy name matching: nicknames, typos, and name order

Bill and William are the same name, and no string-distance algorithm knows it. Their Levenshtein distance is 4, Jaro-Winkler similarity is 0.73, and their Soundex codes (B400 and W450) do not match. Meanwhile Jon and Jan, which may be two different people, share a Soundex code and score 0.80. That pair of failures is the whole problem with fuzzy name matching in one example: similarity in spelling is neither necessary nor sufficient for two names to belong to the same person. This post walks through the real failure cases, what each name matching algorithm catches, and why labeled match tiers beat one blended score.

Key takeaways

• String similarity misses nicknames entirely and over-matches short names that differ by one letter.
• Use a nickname table for diminutives, phonetic keys for spelling drift, and explicit rules for compound and transposed names.
• Run exact matching first, then one relaxation at a time, and label every result with the relaxation that found it.
• Send weak tiers to a review queue instead of auto-merging them.

Where fuzzy name matching fails: real cases

These are the variants that show up in any intake form, CRM export, or account file, scored with three standard methods:

Read the table bottom-up. The two highest-scoring pairs on Jaro-Winkler include Martin and Martina, which are usually different people. The pairs that most often are one person (nicknames and compound surnames) score worst. Two more cases do not fit in a pairwise table at all:

• Transposed name order. "Nguyen Thi Lan" on one form and "Lan Nguyen" on another, or a first and last name swapped by a clerk. Comparing first-to-first and last-to-last scores this as a total mismatch.
• Married and former surnames. "Maria Lopez" who became "Maria Chen" shares no surname characters at all. Only an address or date-of-birth link, plus a record of the former name, connects them.

What each name matching algorithm actually catches

No single technique covers the list above. Each one fixes one class of variant:

• Normalization (lowercase, strip punctuation and suffixes like Jr., split hyphens) handles "O'Brien" vs "OBrien" and lets "Rivera-Lopez" be compared token by token.
• Edit distance (Levenshtein, Jaro-Winkler) catches typos and one-letter spelling drift such as Catherine and Katherine. Jaro-Winkler weights a shared prefix, which suits names but inflates scores for short names.
• Phonetic keys (Soundex, Metaphone, and successors) group names that sound alike, such as Smith and Smyth. Soundex keeps the first letter, which is why Catherine and Katherine get different codes even though the rest matches.
• Nickname tables map diminutives to formal names: Bill, Will, and Billy to William; Peggy and Maggie to Margaret. This is a lookup, not an algorithm, and it is the only way Bill and William ever meet.
• Token and order rules compare names as sets of tokens, so swapped order and compound surnames can match on a shared token.

Most libraries make it easy to mix several of these into one number. That is where nickname matching and record matching pipelines go wrong.

Labeled match tiers beat one blended score

A blended score answers "how similar?" A reviewer needs to know why two records matched. A 0.86 that came from an exact name plus a relaxed date of birth is a different decision from a 0.86 that came from a phonetic surname plus a nearby city. Collapse both into one number and nobody can set a sensible threshold, audit a bad merge, or explain a result.

The alternative is to widen one criterion at a time and label each pass:

Run the tiers in order and stop at the first that returns a match, so a strong match is never displaced by a looser one. Store the tier name with the result. Downstream code can then auto-accept exact and nickname tiers and send everything else to a review queue, and when someone asks why two records were merged, the answer is a label, not a reconstructed score. The pillar guide on identity resolution covers the wider pool-and-score design this fits into.

This is how CoverFi's person search works: when an exact search misses, it widens one criterion at a time (former names, nicknames, transposed name order, compound surnames, relaxed date of birth, nearby metro areas), and every result says which tier produced it alongside a 0-100 match-confidence score. The glossary defines each tier.

A review checklist for fuzzy matches

Before a non-exact match is accepted, a reviewer or rule should confirm:

• At least one non-name identifier agrees: date of birth, address, phone, or email.
• The tier is appropriate for the action. A phonetic match may be fine for deduplicating a mailing list and not fine for merging two account histories.
• Gender-marked name pairs (Martin and Martina, Daniel and Daniela) are not merged on name evidence alone.
• Short names (three letters or fewer) never match on edit distance alone.
• The decision and the tier are logged, so a wrong merge can be traced and reversed.

Matching decides which records describe the same person. It should never be the step that makes a decision about that person; keep identity matching separate from any approval or eligibility logic, and use matched records for the purpose your data license allows.

Frequently asked questions

What is the best name matching algorithm?

There is no single best one. Jaro-Winkler handles typos, phonetic keys handle spelling drift, and only a nickname table handles diminutives like Bill and William. Combine them as separate, labeled tiers.

Why does Soundex give Catherine and Katherine different codes?

Soundex keeps the first letter as-is and encodes only the rest. Names that differ in their first letter never share a Soundex code, even when they sound identical.

Should fuzzy matches be merged automatically?

Only the strongest tiers, such as exact or nickname matches backed by a second identifier. Send transposed, phonetic, and relaxed-date matches to human review.