Generador de CLABE interbancaria

Los cuatro trozos de una CLABE

La Clave Bancaria Estandarizada son dieciocho dígitos con una estructura fija, y cada trozo significa algo:

Que los tres primeros dígitos identifiquen al banco tiene una consecuencia práctica muy usada: puedes saber a qué entidad va una transferencia sin preguntarle nada al usuario. Muchos formularios de pago rellenan el nombre del banco en cuanto tecleas los tres primeros dígitos, y eso es exactamente lo que conviene probar con datos sintéticos de varios bancos.

El dígito de control, y la trampa del módulo

El control se calcula con pesos 3-7-1 que se repiten a lo largo de los diecisiete primeros dígitos. Hasta aquí, normal. La trampa está en lo que se suma:

function controlClabe(d17) {
  const pesos = [3, 7, 1];
  let suma = 0;
  for (let i = 0; i < 17; i++) {
    suma += (Number(d17[i]) * pesos[i % 3]) % 10;   // ← solo la UNIDAD
  }
  return (10 - suma % 10) % 10;
}

controlClabe("00201007777777777")   // 1  →  002010077777777771
controlClabe("03218000011835971")   // 9  →  032180000118359719

Ese % 10 de dentro del bucle es lo que separa una implementación correcta de una que parece funcionar: de cada producto se toma solo la cifra de las unidades, no el número entero. Un 8 multiplicado por 7 aporta 6, no 56.

Si sumas los productos completos, el algoritmo devuelve un dígito plausible y equivocado, y como el resto de la CLABE es correcto nadie lo detecta hasta que el banco rechaza la cuenta. Verificado con 002010077777777771, el ejemplo canónico de Banxico, y con una segunda CLABE publicada.

CLABE, número de cuenta y tarjeta

Tres cosas distintas que los formularios mexicanos piden a veces en el mismo campo:

• CLABE — 18 dígitos. Identifica la cuenta de forma única en todo el sistema. Es lo que necesita un SPEI.
• Número de cuenta — de 10 a 11 dígitos según el banco. Solo tiene sentido dentro de su entidad.
• Número de tarjeta — 16 dígitos. Identifica el plástico, no la cuenta, y valida con Luhn, no con los pesos 3-7-1.

La confusión más cara es aceptar los tres en un solo campo y validar por longitud: 16 y 18 dígitos se distinguen bien, pero un número de cuenta de 11 y un teléfono de 10 no tanto. Si tu formulario admite varias formas de pago, prueba con las tres longitudes seguidas.

Qué probar con CLABE sintéticas

• Control incorrecto. El modo inválido cambia solo el último dígito. Si tu formulario lo acepta, no está validando nada.
• Varios bancos seguidos. Comprueba que la detección automática de entidad funciona con más de uno, incluidos los que no son banca tradicional como STP o NVIO.
• Ceros a la izquierda. Una CLABE que empieza por 002 deja de ser válida si alguien la guarda como número entero. Guárdala siempre como cadena.
• Con espacios. La gente copia la CLABE del estado de cuenta, con separaciones. Normaliza antes de validar y de comparar, o tendrás la misma cuenta duplicada.
• Longitud equivocada. 17 o 19 dígitos, para comprobar que el error que ve el usuario es claro y no un fallo genérico.
• Duplicados. Genera un lote de 100 y cárgalo dos veces: es la forma rápida de ver si tu sistema detecta cuentas repetidas.

Válidas en formato, inexistentes en el banco

Estas CLABE pasan el dígito de control, que es lo que comprueba cualquier formulario, pero no corresponden a ninguna cuenta abierta en ninguna entidad. Una transferencia SPEI contra ellas sería rechazada por el banco receptor. No sirven para cobrar ni para pagar: están para probar tu software.

Si además necesitas el documento del titular, tienes el generador de CURP y el de RFC en la misma web.