Quanto orçamento KYC você desperdiça com dados malformados (e como medir)

Toda vez que o seu sistema envia um número de documento para um provedor KYC — Sumsub, Onfido, Veriff, Persona, Trulioo, Idwall, Truora, Mati ou qualquer outro — você paga por aquela tentativa. O provedor não se importa se o input era um número de documento real e bem formado ou uma sequência de caracteres que nunca poderia pertencer a nenhuma pessoa ou empresa. O medidor roda de qualquer forma. O que muitas equipes de engenharia e compliance descobrem tarde demais é que uma fração mensurável dessas tentativas chega já morta: o input estava malformado na origem — um erro de digitação em um formulário de checkout, um campo de CRM legado que armazenava dados sem validação, uma importação em massa de uma planilha antiga, um bot preenchendo um fluxo de cadastro. O check KYC não pode passar para um documento com formato incorreto. Nunca ia passar. Você pagou assim mesmo. Este post explica como funciona o pricing de KYC, de onde vêm os inputs malformados, quais erros são detectáveis antes de chamar o provedor KYC e — o mais importante — como calcular o seu próprio número. Vamos dar a fórmula e um exemplo hipotético trabalhado. Não vamos dar uma porcentagem de economia garantida, porque isso depende inteiramente dos seus dados, que só você pode medir.

Como os provedores KYC precificam o serviço

O modelo de pricing dominante no mercado de verificação de identidade é a cobrança por tentativa ou por verificação. Cada vez que você envia um documento, um check de identidade ou uma solicitação de prova de vida, é cobrada uma unidade de custo. Faixas citadas publicamente pela indústria sugerem que esses preços por unidade podem variar de aproximadamente USD 0,50 a USD 3,00 ou mais por tentativa, dependendo do tipo de check (apenas documento vs. documento mais prova de vida vs. screening completo AML/watchlist), do vendor, do volume contratado e da região geográfica verificada. Alguns vendors publicam pricing por faixas; outros cotizam por compromissos de volume. O preço específico que a sua organização paga é regido pelo seu contrato — as faixas acima são estimativas citadas publicamente, não os preços de nenhum vendor em particular. O que importa para esta análise não é o número exato, mas a estrutura: você paga por tentativa, bem-sucedida ou não, com input bem formado ou não.

De onde vêm os inputs malformados

Números de documento malformados que entram no seu pipeline KYC não aparecem do nada. Eles vêm de fontes previsíveis:

• Formulários de checkout e cadastro sem validação frontend — O usuário digita seu CPF, CNPJ ou outro identificador no formato que lembra: com pontos e traços, sem eles, com espaços, com quantidade incorreta de dígitos. Se não há feedback imediato, esse input chega ao backend e eventualmente à fila KYC.
• Sistemas CRM ou ERP legados — Muitas empresas têm anos de registros de clientes acumulados antes de alguém pensar em validação de identificadores. Um registro de contato pode ter um campo CNPJ que contém uma data, um nome ou uma nota de texto livre deixada por um vendedor.
• Onboarding de marketplace e B2B — Quando vendedores, fornecedores ou prestadores auto-informam seu identificador fiscal durante o onboarding, a taxa de erro é tipicamente maior do que em fluxos para consumidores. Há menos motivação para ser preciso, e frequentemente não há validação no formulário de onboarding.
• Importações em massa de datasets antigos — Migrar de um sistema legado ou importar uma lista de contatos quase sempre introduz problemas de formato: zeros à esquerda eliminados por software de planilhas, problemas de encoding ao converter de Latin-1 para UTF-8, incompatibilidades de campos onde um CNPJ foi armazenado em um campo de CPF.
• Bots e inputs sintéticos — Submissões automáticas de formulários que testam o sistema ou tentam fraude frequentemente usam identificadores sintéticos ou estruturalmente inválidos.

Erros que não precisam de KYC para serem detectados

O insight crítico é que muitos números de documento malformados falham em um check de formato que custa praticamente nada — e esse check pode acontecer antes de chamar o provedor KYC. A validação de formato é matemática determinística: não consulta nenhum banco de dados, não depende de nenhum registro externo e pode rodar em microssegundos. Estas são categorias de erros puramente estruturais que não requerem nenhuma chamada KYC para serem identificados:

• Padrões CPF com todos os dígitos iguais — A Receita Federal brasileira nunca emite CPFs onde todos os onze dígitos são iguais. 000.000.000-00 a 999.999.999-99 são todos estruturalmente inválidos. Eles passam no algoritmo matemático de dígito verificador, mas estão explicitamente na lista negra. Qualquer ocorrência está garantida a falhar no KYC real. Ver /methodology/cpf-check-digit.
• CNPJ com dígito verificador incorreto — O identificador de empresas brasileiro usa um cálculo de dígito verificador de módulo 11 em duas etapas. Um CNPJ com qualquer erro de transcrição no corpo de 14 dígitos produzirá um mismatch no dígito verificador. Nenhum provedor KYC pode validar um CNPJ que falha nesse check porque não existe nenhuma empresa com esses dados no registro da Receita Federal.
• CUIT com prefixo inválido — Os CUITs argentinos usam um prefixo de dois dígitos para codificar o tipo de entidade. Apenas os prefixos 20, 23, 24, 27, 30, 33 e 34 são emitidos pela AFIP. Um CUIT começando com qualquer outro prefixo é estruturalmente inválido. Ver /methodology/cuit-check-digit.
• RFC com data impossível — O RFC mexicano codifica a data de nascimento ou constituição no formato AAMMDD. Um RFC com mês 13 ou dia 45 é impossível e estruturalmente inválido. O SAT nunca o emitiu.
• Números de documento com comprimento incorreto — Cada identificador tem um comprimento definido após normalização: o CNPJ é sempre 14 dígitos, o CPF sempre 11 dígitos, o CUIT sempre 11. Qualquer input mais curto ou mais longo após remover caracteres de formatação é inválido.
• Problemas de espaço em branco, separadores e encoding — Espaços no início ou no final, traços não padronizados, bytes nulos ou artefatos de encoding de imports CSV não podem ser interpretados como identificadores válidos.
• Falhas IBAN MOD-97 — Números de conta bancária IBAN carregam um check MOD-97. Um IBAN que falha nesse check nunca foi emitido por nenhum banco.

O framework de cálculo (honesto)

Esta é a fórmula para estimar o gasto KYC desperdiçado em inputs malformados. Apresentamos de forma honesta: a primeira variável é uma que você mesmo precisa medir.

Gasto desperdiçado = (tentativas_malformadas / tentativas_totais) x preço_por_tentativa x tentativas_totais_por_mês. O ratio tentativas_malformadas / tentativas_totais é a sua taxa de malformados. Não podemos dar esse número — depende inteiramente das suas fontes de input, da sua validação frontend existente, do seu pipeline de dados e da sua base de usuários. O que podemos mostrar é como a matemática se parece com diferentes taxas, usando um exemplo hipotético apenas para ilustração. Esses números não são benchmarks, não são médias de nenhum dataset e não são previsões para a sua situação.

• Exemplo ilustrativo: 10.000 tentativas KYC por mês a um custo médio de USD 1,50 por tentativa (gasto mensal total: USD 15.000).
• Com uma taxa de malformados de 5%: aproximadamente 500 tentativas malformadas por mês = aproximadamente USD 750 por mês em checks que nunca iriam passar.
• Com uma taxa de 10%: aproximadamente 1.000 tentativas malformadas = aproximadamente USD 1.500 por mês.
• Com uma taxa de 20%: aproximadamente 2.000 tentativas malformadas = aproximadamente USD 3.000 por mês.
• Seus números reais serão diferentes. Estes são mostrados para ilustrar o método, não para prever seu resultado.

Como medir sua própria taxa de malformados

Para obter um número real para a sua situação, você precisa rodar seus dados reais por validação de formato e comparar os resultados com seu log de outcomes de KYC. Este é um método concreto:

• Exporte uma amostra de tentativas KYC recentes — Extraia 1.000 a 10.000 linhas do log de tentativas do seu provedor KYC ou do seu próprio banco de dados. Inclua o valor de input enviado e o outcome (aprovado, reprovado, erro).
• Rode validação de formato na amostra — Passe cada número de documento por um validador de formato. Existem bibliotecas open-source para CPF, CNPJ, CUIT, RFC e outros identificadores. O Normadata Validate cobre estes e mais através de um único endpoint REST em /validators, se quiser testar múltiplos tipos de identificadores sem manter bibliotecas separadas.
• Cruze com os outcomes KYC — Para as tentativas que falharam na validação de formato, verifique se também falharam no KYC. Se um documento falhou tanto na validação de formato quanto no KYC, é um candidato para a categoria malformado. Se um documento passou na validação de formato mas falhou no KYC, o erro foi por um motivo substantivo (match em sanctions, flag PEP, fraude documental, documento vencido) — não é algo que a validação de formato upstream pudesse ter prevenido.
• Calcule o ratio — (quantidade de format-inválidos E KYC-reprovados) / (total de tentativas KYC na amostra). Aplique ao seu volume mensal completo e ao seu custo real por tentativa.
• Repita em uma amostra nova após fazer deploy da validação de formato upstream — Confirme que a taxa cai.

O stack recomendado: validação de formato mais KYC, não em vez de KYC

A validação de formato não substitui o KYC. É um gate que roda antes do KYC. O fluxo: você coleta o número de documento do usuário, roda a validação de formato (check de comprimento, estrutura, dígito verificador, padrões conhecidos inválidos), se o formato for inválido retorna um erro ao usuário e não chama o KYC, se o formato for válido prossegue para o KYC. O provedor KYC então faz o trabalho que a validação de formato não consegue fazer: check biométrico de prova de vida, verificação de autenticidade documental, screening de sanctions, consulta ao banco de dados PEP, adverse media e confirmação de registro junto a autoridades como Receita Federal, AFIP, SAT, SII, DIAN, SUNAT, SENIAT, IRS ou CRA. Esses checks requerem dados do mundo real que a matemática de formato não consegue acessar. A validação de formato upstream apenas filtra os inputs que estavam garantidos a falhar antes que qualquer trabalho real pudesse começar. Provedores KYC que atendem o mercado LATAM incluem plataformas globais como Sumsub, Onfido, Veriff, Persona e Trulioo, além de provedores nativos de LATAM como Idwall, Truora e Mati. A Normadata não tem parceria com nenhum desses vendors — são mencionados como exemplos publicamente conhecidos da categoria. Sua escolha de vendor KYC é independente de você adicionar uma camada de validação de formato antes do KYC. Para o caso de uso completo, veja /use-cases/kyc-pre-validation.

O que a validação de formato upstream NÃO economiza

A validação de formato não reduz os custos de tentativas KYC onde o input está bem formado, mas o check falha por um motivo substantivo. Se alguém envia um CNPJ sintaticamente válido que pertence a uma entidade sancionada, o check de formato passa e a chamada KYC prossegue — e essa chamada KYC custa dinheiro independentemente do outcome. Se um número de documento é estruturalmente válido, mas a pessoa é PEP, ou o check de prova de vida falha, ou o documento está vencido, a validação de formato não fez nada para prevenir esse custo. Esses são custos inerentes a fazer KYC corretamente. O único gasto que a validação de formato upstream pode abordar é o subconjunto de tentativas onde o input estava estruturalmente quebrado antes que o trabalho real de verificação pudesse começar. Para entender o limite completo entre o que a Normadata valida e o que não valida, veja /what-we-dont-do.

Perguntas frequentes

A validação de formato substitui a consulta a registros oficiais? Não. A validação de formato verifica estrutura matemática — dígitos verificadores, comprimento, charset, padrões conhecidos inválidos. Ela não confirma que o identificador está ativo, pertence a quem o reivindica ou existe em algum registro oficial como a Receita Federal, SUNAT ou DIAN. Posso validar IBAN, SSN ou EIN com a mesma abordagem? Sim — o IBAN tem um check MOD-97 que detecta a maioria dos erros de transcrição. O SSN e o EIN têm regras de número de área e formato que filtram inputs obviamente inválidos. O Normadata Validate cobre estes em /validators. E se o meu provedor KYC já faz validação de formato antes de cobrar? Alguns provedores realizam checks básicos de formato do lado deles e podem não cobrar por inputs que falham em um check estrutural imediato. Confirme com seu vendor e teste com inputs conhecidos inválidos — não assuma. Como isso interage com minha lógica de retry existente? Se o seu sistema reprocessa tentativas KYC reprovadas, inputs malformados podem ser reprocessados múltiplas vezes antes de uma revisão humana. Cada retry é uma tentativa faturável separada. Validar o formato upstream elimina o loop de retry para inputs estruturalmente inválidos.

Próximos passos

Se você quer testar validação de formato upstream nos seus próprios dados, o Normadata Validate está em acesso antecipado — solicite acesso em /waitlist. Para o walkthrough completo do caso de uso com padrões de integração e exemplos de resposta, veja /use-cases/kyc-pre-validation. Para entender o que a Normadata valida e o que não valida, veja /what-we-dont-do.

Aviso: Este artigo cita faixas de pricing publicadas publicamente; os preços específicos de cada vendor (Sumsub, Onfido, Veriff, Idwall, etc.) variam por contrato e não são afirmados pela Normadata. As porcentagens e os números de exemplo acima são ilustrativos — mostram como o método de cálculo funciona, não benchmarks de dados reais de clientes. Para obter um número significativo para a sua situação, você precisará medir nos seus próprios dados.