Cómo Comprobar que una CURP Corresponde a una Persona: el Cotejo

Una CURP puede estar bien formada, existir en el registro de RENAPO, estar activa y aun así no ser de la persona que se está dando de alta. Basta con que alguien capture la CURP de un familiar, la de otro cliente copiada de un expediente, o una propia vieja con el nombre de otra persona.

Ninguna validación de formato lo detecta: la CURP está bien. Lo que la delata es que no codifica a la persona que tienes enfrente. Y eso se puede comprobar sin consultar ningún registro, porque la CURP no es un número opaco.

(Si todavía no tienes clara la diferencia entre validar el formato y verificar en RENAPO, empieza por Validar vs. verificar una CURP.)

Lo que la CURP ya dice de la persona

De los 18 caracteres, 16 salen de los datos de la persona:

Posiciones	Qué codifican
1–2	Inicial y primera vocal interna del primer apellido
3	Inicial del segundo apellido (X si no tiene)
4	Inicial del nombre
5–10	Fecha de nacimiento, AAMMDD
11	Sexo: H o M
12–13	Entidad de nacimiento (NE si nació en el extranjero)
14–16	Primera consonante interna del primer apellido, del segundo y del nombre

Si en tu alta ya capturaste nombre, apellidos, fecha, sexo y entidad, puedes derivar lo que esas posiciones deberían tener y compararlo con lo que tienen. Eso es el cotejo: un cálculo sobre la propia CURP, que responde en milisegundos y no cuesta una consulta al registro.

La parte fácil: fecha, sexo y entidad

Tres de los campos se comparan casi directamente.

• Fecha de nacimiento. Está completa en la CURP, con el siglo en la posición 17. Coincide o no coincide; no hay interpretación.
• Sexo. La CURP lleva H o M, con la convención del registro: M es mujer, no masculino. Si tu sistema guarda F/M en el sentido inglés, compara mal la mitad de tus clientes sin que nada falle visiblemente.
• Entidad. El registro usa claves propias (DF, MC, NL), y los expedientes guardan de todo: "CDMX", "Edo. Méx.", "Nuevo León". Hay que mapear las variantes, y hay una trampa: "México" sin más puede ser el Estado de México, la Ciudad de México o el país. No se debe adivinar.

La parte difícil: los nombres

Aquí es donde un cotejo ingenuo empieza a acusar a personas reales. Las reglas con que el registro lee un nombre incluyen decisiones que no se pueden reconstruir con certeza desde fuera:

• Partículas. En "De la Rosa" el registro descarta "De la" y lee ROSA. Pero hay expedientes donde la partícula quedó escrita como parte del apellido. Las dos lecturas son plausibles.
• Apellidos compuestos. En un campo con dos palabras, el registro toma la primera; algunos registros las tratan como un solo nombre.
• María y José. Cuando son el primero de varios nombres, el registro los salta y usa el siguiente: "María Fernanda" se codifica con la F. Si la persona solo usa "Fernanda", también coincide.
• La Ñ. Se escribe X. "Muñoz" aporta M, U y, como consonante interna, X.
• Las palabras inconvenientes. Cuando las cuatro primeras letras formarían una palabra altisonante, el registro sustituye la segunda letra por una X. Si solo tienes parte del nombre, no puedes saber si esa sustitución ocurrió.

La consecuencia es que para muchos nombres no hay una lectura correcta, hay varias. Y eso cambia cómo debe responder un cotejo.

Por qué la respuesta tiene tres valores

Un cotejo de sí o no tiene que decidir qué hacer cuando la lectura es ambigua y ninguna coincide. Si dice "no coincide", en algunos de esos casos estará diciéndole a una persona real que su propia CURP es falsa.

Por eso nuestro cotejo responde campo por campo con tres valores:

• coincide: alguna lectura plausible del dato coincide con la CURP.
• no_coincide: el dato tenía una sola lectura posible y no coincide. No hay decisión del registro que lo explique; el desacuerdo es real.
• indeterminado: el dato admitía varias lecturas y ninguna coincide, o no se puede interpretar (un sexo X, una entidad ambigua). Afirmar o negar sería adivinar.

Un ejemplo con la CURP ficticia ROLF900315MJCSPR02:

{
  "cotejo": "no_coincide",
  "cotejoCampos": {
    "nombres": "coincide",
    "primerApellido": "coincide",
    "segundoApellido": "coincide",
    "fechaNacimiento": "no_coincide",
    "sexo": "coincide",
    "entidad": "indeterminado"
  }
}

La fecha enviada era un día después: eso es un no_coincide claro. La entidad enviada era "México", que no se puede ubicar: indeterminado, no un error. El veredicto general es el peor de los campos.

Y la asimetría importa en los apellidos: si el expediente dice "Lozano" y la CURP empieza con RO, no hay lectura que los reconcilie y la respuesta es no_coincide. Si dice "De la Torre", hay dos lecturas plausibles, ninguna coincide, y la respuesta es indeterminado: un caso para revisión, no un rechazo automático.

Lo que el cotejo no dice

coincide significa que la CURP es consistente con los datos, no que los datos sean idénticos a los registrados. La CURP solo guarda iniciales y algunas letras internas: "Rosa" y "Rosales" producen las mismas posiciones. El cotejo descarta la CURP que claramente no es de la persona; confirmar el nombre completo exige consultar el registro.

Por eso el cotejo y la verificación se complementan:

1. Validación y cotejo, al instante y sin consultar a nadie: la CURP está bien formada y es consistente con quien dice ser.
2. Verificación en RENAPO: la CURP existe, está vigente y el registro devuelve los datos completos.

En la práctica

En nuestra API, el cotejo va en la misma llamada que la validación: envías la CURP y los campos que tengas de la persona (todos son opcionales; solo se comparan los que envías), y en la misma llamada puedes pedir la verificación en RENAPO. Los datos que envías para el cotejo no se guardan. Todo por 1 token.

• El formato completo de la petición y de cotejoCampos está en la documentación de la API.
• Para probar solo el formato, sin cuenta, usa el validador de CURP, que corre en tu navegador.