CASO DE USO
Fintech: pre-validar antes del KYC y antes del payout
Una fintech LATAM tiene tres calls pagos por usuario: KYC al onboarding, SMS al OTP, payout al cashout. Cada uno cobra por intento, no por éxito. Normadata corre antes de los tres — cuando el dato es estructuralmente malo, no cobrás esos calls.
EL PROBLEMA
El stack downstream cobra por requests, no por validez
KYC providers cobran por seat. SMS providers cobran por envío. Payout rails cobran por intento o reverse. Si el input es garbage, pagás los tres y obtenés cero.
CPF malformado consume seat de KYC
Tu usuario cargó CPF con DV malo en el signup. Tu backend lo manda a Sumsub. Sumsub factura el seat y rechaza. Tu funnel pierde al usuario por un error que se podía atrapar 30 segundos antes.
Phone con formato roto consume SMS
+54 9 11 1234 5678 vs 011 1234 5678 vs 1112345678. Sin normalización a E.164, tu SMS provider intenta el envío con el formato roto, cobra el intento y el OTP nunca llega. Usuario abandona el signup.
CBU mal cargado bloquea cashout
El usuario carga su CBU en la app. Sin DV check, el campo acepta. Al primer cashout, el rail bancario rechaza por DV inválido. Para el usuario, la fintech parece rota — no sabe que el error fue suyo.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN
Por qué el validation del front no alcanza
Validación regex en el form
Atrapa shape pero no DV. CPF 111.111.111-11 pasa cualquier regex pero es inválido por regla Receita.
Validación en el step de KYC
Tarde — KYC ya cobró. Y el usuario está 4 steps adentro del flow, el bounce-rate sube.
Validación al primer cashout
Aún más tarde. Para entonces el usuario ya hizo deposit, esperó settlement, intentó retirar. La frustración es máxima.
COMO NORMADATA AYUDA
Como Normadata te ayuda
POST /v1/verify (smart parse) en el signup con tax_id + phone + email. Una llamada, tres validaciones, antes de crear el user.
POST /v1/verify/contact antes de mandar al SMS provider. Phone normalizado a E.164, country code resuelto, line type detectado — el SMS provider recibe input limpio.
POST /v1/verify/bank antes de guardar el CBU/Pix/CLABE en el user profile. Si format inválido, mostrar inline error en el form — el usuario corrige antes de hacer su primer deposit.
MIRALO EN ACCION
Miralo en accion
# Step 1: Signup — Smart Parse on user-typed ID
$ curl -X POST api.normadata.io/v1/verify \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"BR","value":"111.444.777-35"}'
{
"valid": true,
"normalized": "11144477735",
"identifier": { "type": "CPF" }
}
# → valid=true → send normalized to KYC vendor (Idwall, Truora...)
# → valid=false → no KYC call billed, show inline error
# Step 2: Cashout — validate destination account before payout rail
$ curl -X POST api.normadata.io/v1/verify/bank \
-H "X-API-Key: nd_..." \
-d '{"country":"AR","type":"cbu","value":"0170099220000067802779"}'LIMITACIONES
Lo que Normadata no hace en fintech onboarding
—No reemplaza KYC. Normadata es pre-flight estructural; KYC verifica identidad regulada con evidencia auditable.
—No envía SMS. Validamos el phone para que tu SMS provider reciba input válido — el envío es responsabilidad de Twilio/Sinch/MessageBird/quien sea.
PREGUNTAS FRECUENTES
Preguntas frecuentes
¿Reduce el costo de Sumsub/Truora?
Sí. Los seats que evitás por filtrar inputs malformados se traducen directo en facturación menor. Magnitud típica en fintechs mobile-first LATAM: 10-25%.
¿Funciona con webhooks de KYC providers?
Normadata no se conecta a tu KYC provider directamente. Vos llamás a Normadata, parseás response, y solo si valid=true mandás al KYC. El control queda en tu code.
Integra Normadata en tu stack
El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.