CASO DE USO
Pre-validacao de formato antes da consulta ao bureau de credito
Cada consulta ao bureau (Boa Vista, Serasa, Equifax, Experian) custa. Seu plano tem volume mensal contratado. Se uma parte do volume e gasta em consultas com tax IDs estruturalmente invalidos — que o bureau ia rejeitar igual — e dinheiro perdido. Validar formato do tax ID antes do lookup e um gate barato que protege um gasto caro.
O PROBLEMA
O orcamento de bureau e desperdicado em inputs ruins
Os bureaus cobram por consulta ou tem volumes contratados. Inputs estruturalmente invalidos costumam consumir cota mesmo sem retornar resultado util.
Cada lookup tem custo, sucesso ou nao
Boa Vista, Serasa, Equifax e Experian cobram por consulta ou por volume contratado. Um CPF com DV invalido nao retornara um credit report util — mas a consulta conta contra seu plano.
Inputs sujos vem do frontend
O usuario digita o tax ID no formulario de aplicacao de credito. Se seu frontend nao valida checksum, o dado sujo entra no pipeline. E dai vai ao bureau, onde dado sujo custa dinheiro.
Drift entre o formato esperado pelo bureau e o da sua base
Alguns bureaus esperam o tax ID sem separadores, outros com mascara. Se sua base guarda em um formato e voce envia em outro, ha risco de rejeicao por formato — gastando a consulta igual.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por que o front nao filtra isso sozinho
Regex no formulario
Valida comprimento e caracteres mas nao calcula checksum. Um tax ID com DV errado passa o regex e chega ao bureau.
Validar ao receber erro do bureau
Quando o bureau retorna erro, voce ja gastou a consulta. O feedback e post-factum.
Biblioteca por pais no backend
Manter implementacoes corretas de CPF, CUIT, RFC com checksum e manutencao. Open source costuma estar incompleto ou desatualizado.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
Chame verify/tax-id antes de cada bureau lookup. Se valid=false, nao faca a consulta — devolva erro de formato ao cliente. Cota de bureau preservada.
Complemente com verify/contact se o bureau tambem usa telefone ou email do solicitante para enriquecer — pre-validar reduz chance de falha do lookup por dado secundario malformado.
O campo normalized da a forma canonical que o bureau espera (sem separadores, comprimento correto, checksum valido). Envie isso ao bureau, nao o que o usuario digitou.
VEJA EM ACAO
Veja em acao
# Format gate BEFORE paid bureau lookup (Veraz, Boa Vista, Equifax...)
$ curl -X POST api.normadata.io/v1/verify/tax-id \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"AR","type":"cuit","value":"20-31456789-1"}'
{
"valid": false,
"errors": ["invalid_check_digit"]
}
# valid=false → SKIP bureau call. Quota preserved.
# valid=true → call bureau with normalized value
# Important: Normadata does NOT call the bureau, does NOT return a credit score.
# We only confirm the tax ID is structurally valid before you spend quota.LIMITACOES
O que o Normadata nao faz aqui
—O Normadata NAO faz credit scoring. Nao consulta o bureau, nao retorna credit score, nao retorna historico de credito. Isso e do bureau, nao nosso.
—O Normadata nao garante que o tax ID esteja registrado no bureau, so que esta bem formado. Um CPF estruturalmente valido pode nao ter historico em Serasa — isso so o bureau diz.
PERGUNTAS FREQUENTES
Perguntas frequentes
O Normadata substitui Boa Vista ou Serasa?
Nao, somos complementares. O Normadata roda antes do bureau lookup como format gate. A consulta ao bureau (credit history, score, comportamento de pagamento) continua sendo do bureau.
Reduz custos de bureau?
Sim — ao filtrar inputs estruturalmente invalidos antes da consulta, voce nao gasta cota em lookups que iam falhar igual. A economia real depende da sua taxa atual de inputs malformados. Mede sobre seu volume antes de projetar.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.