CASO DE USO
Seller onboarding: pre-validar antes de provisionar la cuenta
Cada seller que pasás a KYC con datos malformados es un seat de KYC quemado. Cada cuenta provisionada con tax ID errado es una cuenta que va a fallar el primer payout. Normadata corre en el signup del seller para que solo lleguen records con formato válido al stack downstream.
EL PROBLEMA
El KYC cobra por seat independiente de si el dato es válido
Los marketplaces típicamente pagan por cada verificación KYC iniciada. Si el seller cargó un CPF con DV errado, Sumsub/Truora/Idwall te lo factura igual aunque rechace en el primer step.
CPF que pasa regex pero falla DV
El front valida "11 dígitos numéricos" pero no calcula el módulo-11. El seller termina el signup, vos creás la cuenta, mandás a KYC, KYC factura, KYC rechaza. Plata tirada por validación que se podía hacer client-side.
CUIT con prefijo equivocado para el tipo de entidad
Prefijos 30/33/34 son personas jurídicas, 20/23/24/27 son físicas. Un seller marca "empresa" pero carga CUIT con prefijo de persona — el sistema crea cuenta empresa con datos de persona y todo se rompe en facturación.
Cuenta bancaria en el campo equivocado
El seller pega un CVU en el campo de CBU, o un alias donde va el número de cuenta. El front lo acepta y nadie atrapa el error. La cuenta queda activa pero el primer payout rebota.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN
Por qué los validators de form no son suficientes
Regex client-side
Atrapa shape pero no atrapa DV, prefijos LATAM, ni typos de dominio. Falsos positivos en 5-15% de submissions.
Validación en el step de KYC
Demasiado tarde — el seat de KYC ya está facturado. Y el seller se frustra cuando ve el error después de pasar 4 steps del signup.
Validación en el primer payout
Aún más tarde. Para entonces el seller ya estuvo operando, generó historial, y el rebote del rail rompe su confianza.
COMO NORMADATA AYUDA
Como Normadata te ayuda
POST /v1/validate/records con el payload completo del signup. Tax ID, cuenta bancaria, dirección y nombre validados en una sola request, con consistencia y readiness, antes de crear la cuenta.
El país viaja en cada record (campo country). El endpoint chequea consistencia entre el país y el documento/cuenta del seller.
Bloqueá el submit si valid=false. Mostrá el field específico que falló (response.warnings tiene el field path) — el seller corrige y reintenta en el mismo viewport.
MIRALO EN ACCION
Miralo en accion
# Pre-validate seller tax IDs at the signup form — one batch, multiple sellers
$ curl -X POST api.normadata.io/v1/validate/tax-ids \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"items":[
{"id":"ar","country":"AR","type":"cuit","value":"30-71234567-9"},
{"id":"br","country":"BR","type":"cnpj","value":"11.222.333/0001-81"}
]}'
{
"results": [
{ "id": "ar", "valid": true, "normalized": "30712345679" },
{ "id": "br", "valid": true, "normalized": "11222333000181" }
]
}
# One schema for AR CUIT, BR CNPJ, CL RUT, CO NIT — reject before provisioningLIMITACIONES
Lo que Normadata no hace en seller onboarding
—No reemplaza KYC. Normadata es pre-validación estructural; Sumsub/Truora/Didit/Idwall/Metamap hacen verificación de identidad regulada. Son complementarios.
—No verifica que el seller esté autorizado para operar en LATAM. Eso es trabajo del compliance officer de tu marketplace.
PREGUNTAS FRECUENTES
Preguntas frecuentes
¿Cuánto reduce el costo de KYC?
Depende de la calidad de tu funnel. Marketplaces con onboarding mobile-first típicamente ven 10-25% de inputs con errores estructurales. Filtrarlos antes de KYC reduce el seat-cost proporcionalmente.
¿Detecta el país sin que el seller lo elija?
El país es un campo requerido en cada item; no se infiere. El endpoint valida el documento contra ese país y reporta inconsistencias.
Integra Normadata en tu stack
El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.