CASO DE USO
Pre-validacion en apertura de cuenta bancaria o fintech
El signup de una cuenta digital LATAM (banco, fintech, billetera) rechaza al usuario porque el RFC tiene 12 caracteres en lugar de 13, o el CUIT tiene un digito verificador mal. El usuario llega al ultimo paso del formulario y recibe un error generico. Algunos corrigen y reintentan. Muchos abandonan. Pre-validar al perder el foco del campo — antes del submit, antes del KYC — convierte ese abandono en una correccion in-form.
EL PROBLEMA
El abandono en signup es caro de recuperar
Adquirir un usuario hasta que llega al formulario de alta de cuenta cuesta marketing, performance ads y tiempo. Perderlo en el ultimo paso por un error de formato es el costo de adquisicion peor invertido.
Errores de formato aparecen tarde en el flow
Muchos productos validan tax ID y telefono recien al submit, despues de que el usuario completo todo el formulario (a veces decenas de campos). El error generico al final del flow es la peor experiencia posible.
Productos multi-pais multiplican el problema
Una fintech que opera en AR/BR/MX necesita validar CUIT, CPF/CNPJ y RFC respectivamente. Cada uno con su algoritmo, cada uno con su error humano tipico. Sin un gate uniforme, el equipo de producto mantiene tres validadores con drift entre ellos.
El costo de KYC se desperdicia en inputs malos
El paso siguiente del signup tipicamente es KYC con un proveedor que cobra por intento. Si el tax ID es estructuralmente invalido, el intento de KYC fallar igual — pero te cobran. Pre-validar formato antes del KYC ahorra esos costos.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN
Por que la validacion solo del lado del front no alcanza
HTML pattern attribute
Valida regex de longitud y caracteres. No calcula digitos verificadores de RFC, CPF o CUIT. Una cadena con el largo correcto pero DV invalido pasa el pattern.
Libreria npm por pais
Funciona para un pais, pero al expandir a tres paises se vuelve tres librerias con tres APIs distintas, cada una con su cadencia de updates. La logica de UX (cuando validar, que mensaje mostrar) se duplica.
Validar todo en el KYC vendor
El KYC vendor cobra por intento y devuelve errores de bajo nivel. Hacer que el usuario espere a que llame al vendor para decirle que el formato del RFC esta mal es mala UX y plata gastada en vano.
COMO NORMADATA AYUDA
Como Normadata te ayuda
Llama a /v1/verify (smart parse) o verify/tax-id al perder el foco del campo o al submit del formulario. Si valid=false, mostras el error especifico (DV incorrecto, longitud incorrecta, prefijo invalido) antes de avanzar al paso siguiente.
Complementa con verify/contact para validar telefono y email — pre-validar telefono antes de enviar el OTP SMS te ahorra el costo del SMS a numeros invalidos.
Mismo schema de respuesta para AR, BR, MX, CL, CO, PE. Tu codigo de front es uno solo — cambias el country segun el pais del usuario.
MIRALO EN ACCION
Miralo en accion
# Smart Parse the full signup payload at account opening
$ curl -X POST api.normadata.io/v1/verify \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"AR","value":"20-31456789-0"}'
{
"valid": true,
"normalized": "20314567890",
"identifier": {
"type": "CUIT"
}
}
# Validate phone format before sending SMS OTP
$ curl -X POST api.normadata.io/v1/verify/contact \
-H "X-API-Key: nd_..." \
-d '{"country":"AR","type":"phone","value":"+5491134567890"}'
# Then hand off to KYC / liveness vendor (not us — we are pre-flight only)LIMITACIONES
Que no hace Normadata aqui
—Normadata no es KYC. No hace verificacion de identidad, no hace liveness, no escanea documentos, no consulta listas de PEP o sanciones. Esa capa la hace tu proveedor de KYC.
—Normadata no crea la cuenta, no asigna un IBAN/CVU/Pix key, no es core banking. Validamos los datos antes de que vos hagas todo eso.
PREGUNTAS FRECUENTES
Preguntas frecuentes
Reemplaza a Sumsub, Truora, Mati u Onfido?
No. Normadata es complementario al KYC: corre antes y filtra inputs estructuralmente invalidos para que no llegues a pagar un intento de KYC con datos malformados. La verificacion de identidad real sigue siendo del KYC vendor.
Crea la cuenta bancaria o asigna un CVU/IBAN?
No. Normadata es estrictamente validacion de formato pre-flight. La apertura de la cuenta, la asignacion del CVU/CBU/Pix key/CLABE, la integracion con core banking — todo eso queda del lado de tu stack.
Integra Normadata en tu stack
El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.