CURP Validator

Compute the 16-character root from demographic data

Useful as a capture aid: shows how positions 1–16 should look for a given person.

Batch validation

Paste CSV or JSON, or upload a file. CSV header must be: paternalSurname,maternalSurname,givenNames,dateOfBirth,sex,entityCode,capturedCurp

Validation rules and scope

This service applies the rules described in the DGRNPI document "Reglas para la Ejecución de los Procedimientos para la Asignación de la CURP". Per DGIS guidance for SEUL certification, validation covers:

• Positions 1–16 (root segment): deterministic. Rebuilt from the patient's demographic data and compared character by character against the captured CURP.
• Position 17 (homonymy differentiator): format only. Must be a digit 0–9 if the patient was born on or before 1999-12-31, or a letter A–Z if born on or after 2000-01-01.
• Position 18 (check digit): not validated locally. RENAPO is the authoritative source.

Foreign-born and special populations

The 18-character CURP format and the construction algorithm are identical for everyone — what changes is the supporting documentation, the entity code (positions 12–13), and which institution issues the CURP. The validator handles every case below the same way:

• Mexicans born abroad — entity code NE; algorithm unchanged.
• Naturalized Mexicans — DGRNPI assigns the CURP from the SRE naturalization certificate; entity code NE.
• Foreign nationals with regular migration status — INM assigns the CURP; entity code NE; rule 5.1.10 commonly applies (single surname is normal in many cultures).
• Refugees / asylum seekers — COMAR issues a CUR and the DGRNPI assigns the CURP; entity code NE.
• Stateless persons — handled via DGRNPI special procedure; entity code NE.

Note for HarmoniMD: when the patient hands you an official CURP that was already issued by INM/DGRNPI, capture it verbatim. The validator will rebuild the root from the demographic data and flag any mismatch. For people whose source country uses only one surname, leave the maternal-surname field blank — rule 5.1.10 is automatically applied.

Endpoints

GET  /api/health
GET  /api/entities
GET  /api/demo-cases
POST /api/build              { paternalSurname, maternalSurname, givenNames, dateOfBirth, sex, entityCode }
POST /api/validate           { ...above, capturedCurp }
POST /api/validate-batch     [ {record}, {record}, ... ]

Rules implemented (positions 1–4)

1. 5.1.1 — leading Ñ → X
2. 5.1.2 — compound given names: use first word
3. 5.1.3 — exception to 5.1.2: if first given is MARIA / MA. / MA / M. / M / JOSE / J. / J → use the next non-particle given name
4. 5.1.4 — special chars (/ - . ') intervening: X
5. 5.1.5 — compound surname: first word
6. 5.1.6 — Ü → U
7. 5.1.7 — skip leading particles (DA, DAS, DE, DEL, DER, DI, DIE, DD, EL, LA, LAS, LE, LES, LOS, MAC, MC, VAN, VON, Y)
8. 5.1.8 — first 4 letters in profanity catalog: replace 2nd letter with X
9. 5.1.9 — no internal vowel: X at position 2
10. 5.1.10 — single surname: X at position 3
11. 5.1.11 — no surnames: XXX + name initial

Rules implemented (positions 14–16)

1. 5.2.1 — internal Ñ → X
2. 5.2.2 — no internal consonant → X
3. 5.2.3 — single surname → X at position 15
4. 5.2.4 — compound given name: first internal consonant of first word
5. 5.2.5 — exception to 5.2.4 for MARIA / MA. / JOSE / J. variants
6. 5.2.6 — no surnames: XX + consonant of name
7. 5.2.7 — special chars in consonant scan → X