Guide
Why EU personal data needs detectors most US-built tools don't ship with
- 01
Identify sensitive values
- 02
Replace with stable tokens
- 03
Restore only inside your boundary
Direct answer
Most PII detection tools are tuned for US formats first — Social Security numbers, US phone numbers, US street addresses. EU personal data includes country-specific structured formats (IBANs, national ID schemes that vary by member state, VAT numbers) and names that don't follow English-language capitalization or the training data most named-entity recognition models were built on, so detectors optimized for US data commonly under-detect it.
IBANs have a checkable structure, which helps and can mislead
An IBAN is a two-letter country code, two check digits, and a country-specific basic bank account number, with total length varying by country — 22 characters for Germany, 27 for France, up to 34 for some member states. The check digits follow a mod-97 checksum, which means a detector can validate a candidate match rather than just pattern-match its shape.
A detector that only matches the general shape of an IBAN without validating the checksum will flag ordinary alphanumeric strings of the right length as false positives. Checksum validation is what separates a usable IBAN detector from a noisy one.
National identifiers vary by member state, with no single format
Unlike a US Social Security number, there is no single EU-wide personal identifier format. Each member state defines its own scheme, and some encode information directly into the number itself.
- Germany: Steuer-ID, an 11-digit tax identification number
- France: the INSEE/NIR number, 15 digits that encode sex and date of birth
- Italy: Codice Fiscale, a 16-character alphanumeric code derived from name and birth data
- Spain: DNI and NIE numbers, each with their own digit-and-letter check structure
- A detector built only against one country's format will silently miss the others
VAT numbers and multilingual names both need locale-aware detection
EU VAT numbers follow a country-code-plus-digits structure, but the digit count and internal structure differ by member state, similar to IBANs. Detecting them reliably means maintaining per-country rules rather than one generic pattern.
Names are a harder problem than either format. Diacritics, compound and hyphenated surnames, and naming-order conventions that don't match English defaults (patronymic and matronymic surnames, for instance) mean a named-entity recognition model trained mostly on English text will under-detect names common across EU member states. Reliable detection needs either multilingual training data or locale-specific dictionaries layered on top of a general model, not a single English-tuned detector applied everywhere.
Related PII guidance
Frequently asked questions
Why does IBAN detection need checksum validation instead of just pattern matching?
Pattern matching alone flags any string of the right length and character set, including ones that aren't real IBANs. Mod-97 checksum validation confirms a candidate match is structurally valid, cutting false positives significantly.
Is there a single EU-wide national ID format?
No. Each member state defines its own scheme — length, structure, and what information (if any) is encoded in the number — so detection needs per-country rules rather than one generic pattern.
Why do English-trained NER models miss non-English names?
Named-entity recognition models learn from their training data. A model trained mostly on English text has seen far fewer examples of diacritics, compound surnames, and non-English naming conventions, which lowers recall on exactly the names most common across EU member states.