CASO DE USO
Filtre data malformada antes de pagar a vendors downstream
Cada call para KYC, SMS provider, credit bureau ou payment rail custa. E cobram por tentativa, não por sucesso. Quando o input é estruturalmente malformado, você paga esses calls sem receber nada. A Normadata roda como middleware entre seu code e seus paid vendors.
O PROBLEMA
Os paid vendors não devolvem a cobrança se o input é malformado
O modelo de pricing padrão é pay-per-request. KYC providers, SMS providers, bureaus, rails — todos cobram cada vez que você manda algo, independente de o dado ser válido. Filtrar pre-call é ROI direto.
KYC cobra por seat mesmo se o CPF é garbage
Sumsub/Idwall/Metamap cobram o seat quando o flow inicia. Se o CPF chegou com DV ruim, o flow termina imediato mas o seat é faturado.
SMS provider cobra por intent de envio
Twilio/Sinch/MessageBird/Vonage cobram cada SMS attempted. Se o phone chega sem country code ou com formato quebrado, o carrier rejeita mas o SMS attempt já foi cobrado.
Credit bureau cobra por consulta bem-sucedida ou rejeitada
Serasa/Boa Vista/Equifax cobram cada query. Se o tax ID tem DV ruim, a query falha e o bureau te fatura igual. Multiplicado por 10.000 consultas/mês, é real money.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por que os paid vendors não filtram eles mesmos
Esperar que o vendor melhore a validation dele
O business model dele é pay-per-request. Zero incentivo em rejeitar pré-cobrança.
Negociar pricing por valid-only
Alguns aceitam em contratos enterprise. Para tier médio, raro. E não se aplica a tier startup.
Custom validation antes do call
Funciona mas exige manter algoritmos de DV de cada país. Quando você adiciona um país, adiciona biblioteca + tests + dependencies.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/validate/tax-ids como middleware entre seu code e o paid vendor. Se valid=false, short-circuit — você não chama o vendor.
Para inputs específicos (conta bancária antes do rail, tax_id-only antes do bureau), use o endpoint específico (/v1/validate/accounts ou /v1/validate/tax-ids) — menos overhead.
Acompanhe a taxa de valid:false na sua telemetria. Se for alta, o ROI do filter é alto. Se for baixa, está servindo igual como insurance — o custo extra é marginal.
VEJA EM ACAO
Veja em acao
# Middleware gate — before any paid downstream call
$ curl -X POST api.normadata.io/v1/validate/tax-ids \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"items":[{"id":"g","country":"BR","type":"cpf","value":"111.444.777"}]}'
{
"results": [
{ "id": "g", "valid": false, "error": "invalid_length" }
]
}
# → DO NOT call KYC vendor (saved $1.50)
# → DO NOT send SMS OTP (saved $0.04)
# → DO NOT query credit bureau (saved $0.80)
# Track the valid:false rate to forecast monthly savings:
# invalid_inputs * (cost_per_kyc + cost_per_sms + cost_per_bureau)LIMITACOES
O que a Normadata não faz como middleware
—Não substitui seus paid vendors. É um filter — só evita que você mande garbage pra eles.
—Não audita as faturas dos seus vendors. Para isso use sua billing reconciliation tool.
PERGUNTAS FREQUENTES
Perguntas frequentes
Quanto eu economizo tipicamente?
Depende da qualidade dos seus inputs. Funnels mobile-first LATAM veem 10-25% de inputs com erros estruturais. Filtrá-los reduz o paid-vendor cost por esse fator (com o cost da Normadata abaixo do cost de um vendor downstream típico).
Onde eu coloco no flow?
Middleware no seu service de onboarding/payments — entre seu code e a chamada ao vendor. Ou step no seu workflow engine (Temporal, Airflow, n8n) antes do step que chama o paid vendor.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.