Country-Specific Entity Formats

Detecting PII globally is more than translating labels — the identifiers themselves are country-specific. A US Social Security Number (123-45-6789) looks nothing like a UK National Insurance number (QQ 12 34 56 C) or a Spanish DNI (12345678Z). IBANs vary in length from 15 to 34 characters depending on the country, phone numbers switch prefix and grouping conventions at every border, and postal codes range from 4 digits to alphanumeric blocks. The detection model recognizes these national formats together with the surrounding language context, so entity types such as NATIONAL_ID, IBAN_CODE, PHONE_NUMBER, ZIP_CODE, and PASSPORT_NUMBER work across jurisdictions. A sample of the formats covered:

Why Multilingual Detection Needs Context, Not Just Patterns

Names are the hardest multilingual entity: there is no pattern for "Zhang Wei", "Ayşe Yılmaz", or "João Silva" — only context tells a detector that a word is a person. The same applies to addresses, which reverse their order between countries (street-first in the US, city-district-street in Japan), and to dates of birth written as 15.03.1985, 15/03/1985, or 1985年3月15日. Because the API's NER model reads whole sentences rather than matching character patterns, it correctly detects:

• Person names across scripts — Latin, Cyrillic, Arabic, Devanagari, CJK — including transliterations and names embedded in prose.
• Addresses in local ordering and with local administrative units (préfecture, Bundesland, oblast, distrito).
• National identifiers by their country format and the words around them ("NIF", "Steuernummer", "codice fiscale"), even when the label is in another language than the number's country.
• Mixed-language text — a German support ticket quoting an English error message with an IP address and an API key is scanned as one document.

This is the practical difference between multilingual PII detection and a library of per-country regexes: one request, any language, the same structured response. For a comparison of approaches, see NER vs regex vs rules.

One Request, Any Language

No language parameter is needed — send the text and the model handles language identification internally. The entity types and response fields are identical in every language:

import requests

resp = requests.post(
    "https://piidetectionapi.com/api/moderate.php",
    json={
        "api_key": "YOUR_API_KEY",
        "api_type": "pii_detection",
        "text": "Kontaktieren Sie Hans Müller unter [email protected] "
                "oder +49 170 1234567. IBAN: DE89 3704 0044 0532 0130 00.",
        "mask_mode": "replace",
    },
    timeout=30,
)
data = resp.json()
for e in data["detected_entities"]:
    print(e["type"], e["text"], e["start"], e["end"], e["confidence"])

# PERSON_NAME    Hans Müller                     17 28  0.97
# EMAIL_ADDRESS  [email protected]           35 56  0.99
# PHONE_NUMBER   +49 170 1234567                 62 77  0.99
# IBAN_CODE      DE89 3704 0044 0532 0130 00     85 112 0.99

Character offsets (start/end) are counted on the original Unicode text, so they stay valid for highlighting or building your own redaction in any script. Detection quality is strongest in widely spoken languages (English, Spanish, German, French, Portuguese, Chinese, Japanese, Arabic, Hindi) and remains reliable across the full list above; for details on measuring per-language accuracy, see precision, recall & F1 for PII detection.

Global Data, Global Regulations

Multilingual coverage matters because privacy law follows the person, not the language of your codebase. GDPR applies to a French customer's data even when it sits in an English-language CRM; LGPD covers Brazilian CPF numbers in your logs; and HIPAA-regulated providers increasingly serve patients in Spanish, Mandarin, and Vietnamese. Scanning every language your users actually write in is the only way to make GDPR personal-data discovery, DLP, and support-ticket scanning complete.