CASO DE USO
Fintech: pré-validar antes do KYC e antes do payout
Uma fintech LATAM tem três calls pagos por usuário: KYC no onboarding, SMS no OTP, payout no cashout. Cada um cobra por tentativa, não por sucesso. A Normadata roda antes dos três — quando o dado é estruturalmente ruim, você não paga esses calls.
O PROBLEMA
O stack downstream cobra por requests, não por validade
KYC providers cobram por seat. SMS providers cobram por envio. Payout rails cobram por tentativa ou reverse. Se o input é garbage, você paga os três e recebe zero.
CPF malformado consome seat de KYC
Seu usuário preencheu CPF com DV ruim no signup. Seu backend manda pro Sumsub. O Sumsub fatura o seat e rejeita. Seu funnel perde o usuário por um erro que dava pra pegar 30 segundos antes.
Phone com formato quebrado consome SMS
+54 9 11 1234 5678 vs 011 1234 5678 vs 1112345678. Sem normalização para E.164, seu SMS provider tenta o envio com o formato quebrado, cobra a tentativa e o OTP nunca chega. Usuário abandona o signup.
CBU mal preenchido bloqueia cashout
O usuário preenche o CBU no app. Sem DV check, o campo aceita. No primeiro cashout, o rail bancário rejeita por DV inválido. Para o usuário, a fintech parece quebrada — ele não sabe que o erro foi dele.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por que a validation do front não basta
Validação regex no form
Pega shape mas não DV. CPF 111.111.111-11 passa em qualquer regex mas é inválido pela regra da Receita.
Validação no step de KYC
Tarde — o KYC já cobrou. E o usuário está 4 steps dentro do flow, o bounce-rate sobe.
Validação no primeiro cashout
Ainda mais tarde. A essa altura o usuário já fez depósito, esperou settlement, tentou sacar. A frustração é máxima.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/validate/records no signup com tax_id + conta bancária. Uma request, validação por campo, consistência e readiness, antes de criar o user.
POST /v1/validate/tax-ids antes de mandar pro KYC provider. Tax ID com checksum verificado e tipo de contribuinte resolvido — o provider recebe input limpo.
POST /v1/validate/accounts antes de guardar o CBU/Pix/CLABE no user profile. Se format inválido, mostrar inline error no form — o usuário corrige antes do primeiro depósito.
VEJA EM ACAO
Veja em acao
# 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"}]}'LIMITACOES
O que a Normadata não faz em fintech onboarding
—Não substitui o KYC. A Normadata é pre-flight estrutural; KYC verifica identidade regulada com evidência auditável.
—Não envia SMS. Validamos o phone para que seu SMS provider receba input válido — o envio é responsabilidade do Twilio/Sinch/MessageBird/quem for.
PERGUNTAS FREQUENTES
Perguntas frequentes
Reduz o custo de Sumsub/Idwall?
Sim. Os seats que você evita filtrando inputs malformados se traduzem direto em faturamento menor. Magnitude típica em fintechs mobile-first LATAM: 10-25%.
Funciona com webhooks de KYC providers?
A Normadata não se conecta ao seu KYC provider diretamente. Você chama a Normadata, parseia a response, e só se valid=true manda pro KYC. O controle fica no seu code.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.