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.
O 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.
Email con dominio inexistente o typo conocido
gmal.com, hotmial.com, outloook.com. El seller los tipea desde el móvil y nadie atrapa el error. La cuenta queda activa pero el seller nunca recibe el email de verificación.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
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 O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/verify (smart parse) con el payload completo del signup. Tax ID, email, phone, dirección y nombre validados en una sola llamada, antes de crear la cuenta.
Si el seller tiene multiselect de país, pasá country_hint al smart parse. La detección heurística mejora ~15% con el hint.
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.
VEJA EM ACAO
Veja em acao
# Pre-validate seller tax ID at signup form
$ curl -X POST api.normadata.io/v1/verify/tax-id \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"AR","type":"cuit","value":"30-71234567-9"}'
{
"valid": true,
"normalized": "30712345679",
"identifier": {
"type": "CUIT",
"contributor_type": "persona_juridica"
}
}
# Same gate works for MX RFC, BR CNPJ, CL RUT — one schema
# Reject before provisioning the seller accountLIMITACOES
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.
PERGUNTAS FREQUENTES
Perguntas frequentes
¿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?
Heurísticamente, sí. Smart parse usa el shape del tax ID y el código de país del teléfono para inferir. Pero recomendamos siempre pasar country (selectbox visible en el form) — la heurística cae a best-guess sin hint.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.