One Tool, 45 Countries: 260+ Entities
Global platforms process personal data from many countries at once. Each country has its own ID formats. Each format has its own rules. A single detection tool must handle all of them. Most tools do not.
The Identifier Fragmentation Problem
A marketplace with sellers in 45 countries gets very different onboarding documents. A Brazilian seller submits a CPF. It has 11 digits. Two are check digits. They use a specific weighting formula. An Indian seller submits a PAN. It has 10 characters. Letters and digits appear in fixed positions. A German seller submits a Steuer-ID. It has 11 digits and a Luhn checksum. A Dutch seller submits a BSN. It has 9 digits and uses mod-11 validation.
Each format has a different length and structure. One regex built for one format will not match the others. A broad "10–12 digit" pattern catches too much. It flags prices, dates, and reference numbers. False positives grow fast at scale.
The 40-Identifier Gap
Most enterprise PII tools ship with about 40 identifier types. Common ones include:
- US Social Security Number
- US passport format
- US driving license
- Generic credit card formats with Luhn validation
- Email addresses
- Phone numbers in NANP format
- IP addresses
These cover North American compliance well. They do not cover global operations.
What the Gap Looks Like by Region
South America: Brazilian CPF and CNPJ use checksum algorithms from Brazil's fiscal authority. Argentine CUIT uses a different weighted-sum formula. Colombian NIT has its own validation method. None of these match US patterns.
Asia: Indian PAN, Aadhaar, GSTIN, and Voter ID each have a distinct format. Japanese My Number has 12 digits. South Korean Resident Registration Number and Chinese national ID each require their own recognizer.
EU member states: Full EU coverage needs IBAN formats for all 27 member states. Each has a country-specific length and format. It also needs each national ID format. This includes German Steuer-ID, French NIR, Dutch BSN, Polish PESEL, and Swedish Personnummer. It also includes Slovenian EMŠO, Croatian OIB, Bulgarian EGN, and Romanian CNP.
What 260+ Entity Types Covers
A 260+ entity library covers all 27 EU member state national IDs. It validates all EU IBAN formats. It covers South American IDs: Brazil CPF and CNPJ, Argentina CUIT, Colombia NIT. It covers Asian IDs: India PAN, Aadhaar, GSTIN, Japan My Number, Korea RRN. It covers UK IDs: NI Number, NHS Number, NINO variants. It covers medical IDs: US NPI, DEA numbers, hospital MRN formats. It covers financial IDs: SWIFT codes, BIC formats, account number patterns.
Why Detection Coverage Is a Compliance Question
Each framework requires that its identifiers are found and protected. GDPR covers EU seller data. LGPD covers Brazilian seller data. India's DPDP Act covers Indian seller data.
"Appropriate protection" means the tool found the identifier. A missed Aadhaar is not a config failure. It is a coverage failure. For global platforms, that gap is the difference between partial compliance and real protection.
A single deployment with 260+ entity coverage handles all of these jurisdictions. No separate regional tools. No separate processing pipelines. No manual enrichment for formats a 40-recognizer tool misses.
For details on how coverage maps to GDPR obligations, see GDPR compliance resources. For audit trail and update policies, see security and compliance details.
When This Approach Has Limits
Broad multi-country coverage in a single deployment removes the patchwork of regional tools, but a coverage count is a measure of breadth, not a guarantee of completeness. Three limits apply.
An entity count describes formats configured, not data reliably caught. "260+ entity types across 45 countries" means the system is built to recognize that many identifier categories. It does not mean each is detected with equal accuracy. Checksummed identifiers like the Brazilian CPF or a validated IBAN are caught reliably; free-text names, addresses, and contextual references in the same documents are harder and detected less consistently. The headline measures the catalog, not per-entity recall.
National formats change, and the list is only current as of its last update. Governments revise identifier schemes, add new ones, and retire old formats. A tool covers what its recognizers were last updated to know; a newly introduced national ID or a regional variant can fall outside coverage until added. For a global platform, the relevant question is whether the specific identifiers in your live data are on the current list, not how large the list is.
One tool does not equal one compliance posture. GDPR, LGPD, and India's DPDP Act each impose obligations beyond detection — lawful basis, transfer mechanisms, retention, and data-subject rights that vary by jurisdiction. A single deployment finding the identifiers simplifies one control across markets; it does not harmonize the differing legal duties behind them. Detection coverage is the floor of multi-jurisdiction compliance, not the whole structure.