CASO DE USO
Fintech: pre-validar antes del KYC y antes del payout
Una fintech LATAM tiene calls pagos por usuario: KYC al onboarding, payout al cashout. Cada uno cobra por intento, no por éxito. Normadata corre antes — 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. Payout rails cobran por intento o reverse. Si el input es garbage, pagás igual 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.
Tax ID con prefijo equivocado frena el alta
Prefijos 30/33/34 son personas jurídicas, 20/23/24/27 son físicas. Un usuario marca un tipo de entidad pero carga un tax ID con prefijo del otro. El sistema crea el perfil con datos inconsistentes y todo se rompe downstream.
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/validate/records en el signup con tax_id + cuenta bancaria. Una request, validación por campo, consistencia y readiness, antes de crear el user.
POST /v1/validate/tax-ids antes de mandar al KYC provider. Tax ID con checksum verificado y tipo de contribuyente resuelto — el provider recibe input limpio.
POST /v1/validate/accounts 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 — validate the applicant record
$ curl -X POST api.normadata.io/v1/validate/records \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"items":[
{"reference_id":"u-9001","country":"BR",
"tax_id":"111.444.777-35","name":"Maria Lima"}
]}'
{
"results": [
{ "reference_id": "u-9001",
"fields": { "tax_id": { "valid": true, "normalized": "11144477735" } } }
]
}
# → valid=true → send the normalized id to your KYC vendor
# → valid=false → no KYC call billed, show an inline error
# Step 2: Cashout — validate the destination account before the payout rail
$ curl -X POST api.normadata.io/v1/validate/accounts \
-H "X-API-Key: nd_..." \
-d '{"items":[{"id":"1","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 mueve dinero. Validamos el formato del CBU/Pix/CLABE para que tu payout rail reciba input válido — la transferencia es responsabilidad del rail.
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, leés el 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.