If you run a US-built matching tool against an international dataset, you will quietly miss 25-40% of true matches. The tool won't error. It won't warn you. It'll just produce a match count that looks fine against a quick spot-check, while systematically dropping rows that any human would see as obvious matches.
This post is about what actually breaks when name-matching crosses locale boundaries, why it breaks, and what it takes to handle it properly. If you operate in Europe, Latin America, or any other multi-locale region, this matters.
The baseline assumption that breaks
Most matchers assume the anglosphere naming convention: first name, middle name (optional), last name, all ASCII. Match logic typically does some combination of:
- Exact or fuzzy compare on first and last name
- Maybe Soundex or Metaphone for phonetic similarity
- Case-fold to lowercase
- Maybe strip diacritics to ASCII
Each of those steps makes an assumption that breaks in some other locale. Here's a concrete tour.
Spanish two-surname conventions
Spanish-speaking countries (Spain, most of Latin America) use two surnames — paternal first, then maternal. "Pablo Ruiz García" is Pablo's given name plus two surnames (Ruiz paternal, García maternal). When Pablo fills a US-designed form with one "last name" field, he might write "Ruiz García," "García," "Ruiz," or "Ruiz-García" depending on context and personal preference.
A US-built matcher treating "last name" as a single field:
- Compares "Ruiz García" to "García" → very low similarity, misses the match
- Compares "Ruiz-García" to "Ruiz García" → usually works (if it handles the hyphen)
- Compares "Ruiz García" to "Garcia Ruiz" → treats as different, though the second is a common Spanish re-ordering
Handling this right means understanding two-surname structure: each surname is a separate matchable unit, and either one being shared is evidence. "García" matching "Ruiz García" on the maternal-surname-only side is a reasonable partial match.
Dutch and Belgian van / de / ter / van der particles
Dutch surnames often have particles — "van," "de," "der," "ter," "van der," "van den." In Dutch usage the particles are lowercase ("Vincent van Gogh"). In government records and alphabetical sorting, they're often demoted or stripped.
The practical reality:
- "van der Berg" vs "Vanderberg" vs "Van Der Berg" all describe the same person
- US-built matchers typically lowercase-and-compare, which handles case variation but not spacing/concatenation variants
- A proper matcher normalizes the particle prefix separately and matches against the "core" surname ("Berg") with the particle as metadata
This also applies to German "von," French "de/du/de la," Italian "di/della," Portuguese "da/dos/das" — same pattern, different particles.
German umlauts (ä, ö, ü, ß)
German has diacritic vowels (Umlaute) and ß (Eszett). The naive approach — strip diacritics to ASCII — produces:
- "Müller" → "Muller"
- "Schäfer" → "Schafer"
- "Straße" → "Strae" (wrong; should be "Strasse")
The ASCII-strip handles Müller → Muller fine (that's the correct "ae, oe, ue, ss" replacement for Müller is actually Mueller, but in casual dropoff it's often just Muller). But "Straße" → "Strae" is a genuine bug that will drop real matches on any address containing "Straße." The correct transformation is "Straße" → "Strasse."
A proper matcher knows: German ä → ae, ö → oe, ü → ue, ß → ss. Not universal diacritic-strip.
Brazilian Portuguese surname chains
Brazilian Portuguese names often have three to five surnames — paternal grandmother, paternal grandfather, maternal grandmother, maternal grandfather, plus family marriage names. "Maria Eduarda Silva Santos Oliveira Pereira" is a normal name, not an exception.
When Maria fills a form with one "last name" field, she might write any subset. A matcher needs to treat each surname token as independently matchable — any subset agreement is evidence, not just full-string compare.
Scandinavian characters (Å, Ø, Æ, å, ø, æ)
Swedish uses ä, ö, å. Norwegian and Danish use æ, ø, å. These are real distinct letters, not decorated vowels. "Ängström" and "Aengstroem" are the same name; "Ängström" and "Angstrom" are a mismatch in a Swedish context because "Ä" and "A" are different characters.
The correct transliterations:
- Swedish: å → aa, ä → ae, ö → oe (for ASCII fallback)
- Norwegian/Danish: æ → ae, ø → oe, å → aa
Naive matchers just strip diacritics (å → a), which produces false mismatches and occasional false merges.
Polish characters (ł, ń, ś, ż, ą, ę)
Polish has several diacritics not present in most Western European languages. "ł" is a separate letter from "l" (pronounced differently). Standard ASCII fallbacks:
- ł → l (reluctant, loses phonetic distinction)
- ń → n, ś → s, ż → z, ą → a, ę → e
Matching across Polish ASCII-stripped data against original Polish text requires these transliterations to be consistent. Naive strip-diacritics produces inconsistencies.
CJK names (Chinese, Japanese, Korean)
Separate topic, but worth noting: CJK names have fundamentally different character sets and ordering conventions (family name first in native order, often different romanization schemes — pinyin vs. Wade-Giles vs. others for Chinese). US matchers typically don't handle these at all; specialized tooling is needed.
The phone and address angle
It's not just names. International phone numbers require proper E.164 handling (country code detection, national-trunk prefix normalization). International addresses have wildly varying formats — UK SW1A 1AA postcodes, Dutch 1012 AB, Polish 00-950, Portuguese 1000-001, Brazilian CEPs. Each has a canonical format that needs to be recognized and normalized before matching.
A matcher that only handles US 5-digit + 5+4 ZIP codes will fail on every international postcode.
What a proper international matcher does
The concrete capabilities:
- Locale-aware transliteration. Not generic ASCII-strip — per-locale rules (German ß → ss, Swedish å → aa, Polish ł → l, etc.)
- Name particle detection. Recognizes "van," "de," "von," "de la," "di," "da" and normalizes the core surname separately
- Multi-surname handling. Treats Spanish two-surname and Brazilian Portuguese surname chains as independently matchable tokens
- Locale-specific phonetic algorithms. Metaphone works for English; German has its own (Kölner Phonetik); Spanish has its own phonetic approach
- Regional postcode recognition. 20+ different postcode formats across major markets
- Phone E.164 normalization. Country-code-aware phone matching
You can build all of this yourself. Most in-house matchers don't, because the specs for each locale are documented in different places and the effort to get them all right is significant.
What happens when you don't get it right
In practice, running a US-built matcher against EU customer data produces:
- 25-40% false-negative rate on true matches (they're same person but matcher says no)
- Systematic bias against specific surname patterns (Spanish two-surname rows miss more than Anglo single-surname rows)
- Silent failure — you get a low match count, but the "missed" rows are indistinguishable from true non-matches without manual review
For an EU operations team running monthly dedup on 50K customer records, 25% false-negative means 12,500 duplicate pairs staying in the system every month. Compounding year over year.
How to evaluate a matcher for international data
Before committing, test with a known-outcome dataset. Take 100 pairs where you know the right answer (same person, different record). Include:
- Spanish two-surname variants (full name vs partial)
- Dutch/German particle variants (with/without particle, lowercase/uppercase)
- Diacritic-stripped vs original spellings (Müller vs Muller)
- International postcodes in various formats
Run them through the matcher. If match rate on those 100 pairs is below 85%, the tool isn't built for international data. If it's above 95%, it probably is.
Bottom line
International name matching isn't a feature of matching tools — it's a fundamentally different problem than US-only matching, and most tools handle it badly because they weren't built for it. If your customer base spans locales, tool selection matters more here than almost anywhere else.
ListMatchGenie handles the 20 locales listed on our international matching page natively — Spanish two-surname, Dutch/German particles, Scandinavian Å/Ø/Æ, Polish ł/ń/ś/ż, Brazilian Portuguese surname chains, plus regional postcode formats and E.164 phone normalization. The free tier includes all of it — test on your actual data before committing.
