Por que pré-validar dados antes do KYC economiza dinheiro — com números

O modelo de pricing dos providers KYC é per-attempt, não per-success. Toda vez que você manda um documento, uma verificação de identidade ou um check de prova de vida, é faturada uma unidade de custo, independentemente de o check passar, falhar, ou o input nunca poder ter passado porque estava estruturalmente quebrado desde a origem. No universo de checkout mobile-first da LATAM, uma fração mensurável dos inputs chega já morta ao pipeline: typos, separadores incorretos, copy-paste de planilhas com encoding estranho, zeros à esquerda removidos por software de spreadsheet. Se seu sistema empurra todos esses para o KYC sem filtro prévio, você está pagando para verificar o impossível. Este post explica o modelo, a matemática da economia e o padrão concreto de middleware para introduzir um gate de pré-validação antes do provider pago.

Como o provider KYC cobra (modelo per-seat / per-attempt)

Os providers KYC anunciam dois modelos principais: per-attempt (faturado por tentativa de verificação) e per-seat / per-active-user (faturado por usuário único verificado num período). Em ambos, o custo é incorrido antes de saber o outcome. No modelo per-attempt, cada submission ao endpoint do provider é uma unidade; um retry sobre o mesmo documento pode ser outra unidade se o sistema não dedupa. No modelo per-seat, uma vez que um usuário ativa uma verificação, conta contra sua cota independente de o fluxo completar ou não. As faixas públicas típicas da indústria vão de USD 0,50 a USD 3,00+ por verificação, dependendo do tipo de check (somente documento vs. documento + prova de vida vs. screening AML). O número exato está sujeito ao seu contrato e não é algo que afirmamos aqui. O que importa é a estrutura: você paga por tentativa, não por sucesso.

O funil típico de um checkout mobile-first LATAM

Em fluxos mobile-first da LATAM, onde boa parte dos usuários entra de apps com teclados numéricos limitados, paste-from-clipboard frequente e conexões instáveis, os inputs estruturais malformados chegam a taxas que variam entre 10% e 25% conforme o segmento. As causas mais frequentes que vemos discutidas na indústria:

• Typos por teclado mobile — Um usuário que digita seu CPF num celular com keyboard pequeno insere ou pula um dígito em ~3-8% das tentativas.
• Copy-paste com lixo — Quando o usuário copia seu CUIT de um email ou WhatsApp, frequentemente arrasta espaços, aspas tipográficas, quebras de linha ou caracteres invisíveis (zero-width spaces).
• Formatos inconsistentes — Um CPF digitado como 11144477735 vs 111.444.777-35 vs 111 444 777 35 — um validador estrito do lado do KYC pode rejeitar um e aceitar o outro.
• Spreadsheet zero-stripping — Datasets importados do Excel ou Google Sheets perdem zeros à esquerda em RUCs peruanos ou RUTs uruguaios.
• Field mismatch — Em B2B onboarding, um CNPJ é carregado no campo de CPF, ou um CUIT no de CBU. O KYC dá mismatch e é faturado.
• Bots e sintéticos — Submissions automáticas com identificadores aleatórios. O KYC rejeita mas conta.

A matemática da economia (com números ilustrativos)

Esta é a fórmula básica: gasto desperdiçado = (tentativas_malformadas / tentativas_totais) × preço_por_tentativa × volume_mensal. A primeira variável é a única que você tem que medir você mesmo; não podemos te dar uma taxa universal porque depende do seu pipeline, da sua validação frontend existente e da sua base de usuários.

Como exercício ilustrativo: imagine 10.000 verificações KYC por mês a USD 1,50 por tentativa em média — gasto mensal total USD 15.000. Com uma taxa de malformados de 5%, são 500 tentativas × USD 1,50 = USD 750/mês em checks que nunca iam passar. Com 10%, USD 1.500/mês. Com 18% (cota frequentemente citada para mobile-first sem validação frontend), USD 2.700/mês. Esses números são hipotéticos e servem só para ilustrar a mecânica — sua taxa real pode ser substancialmente mais alta ou mais baixa. A única forma de saber é medir.

Como a Normadata encaixa antes do KYC

O padrão de integração é um gate de pré-validação: o documento entra, passa por POST /v1/verify/tax-id ou pelo endpoint Smart Parse, e somente se a Normadata retornar valid: true se prossegue ao provider pago. Se valid é false, você devolve um erro ao usuário, evita a chamada KYC e não consome nenhuma tentativa faturável. Como a validação de formato é matemática pura, a latência é desprezível comparada com qualquer KYC real (que costuma rodar em segundos pela prova de vida e pelos checks de registro). Vamos ver o padrão concreto em Node.js como middleware Express:

import type { Request, Response, NextFunction } from "express";

async function preValidateBeforeKyc(
  req: Request,
  res: Response,
  next: NextFunction,
) {
  const { country, type, value } = req.body;

  const ndRes = await fetch("https://api.normadata.io/v1/verify/tax-id", {
    method: "POST",
    headers: {
      "X-API-Key": process.env.NORMADATA_API_KEY!,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ country, type, value }),
  });

  const result = await ndRes.json();

  if (!result.valid) {
    // O input está malformado na origem — não chamar o KYC.
    return res.status(422).json({
      error: "invalid_tax_id_format",
      hint: result.metadata?.reason ?? "format_check_failed",
    });
  }

  // Anexar o formato canônico ao request e seguir para o KYC.
  req.body.value = result.value.formatted;
  req.body.normalized_metadata = result.metadata;
  next();
}

export default preValidateBeforeKyc;

import preValidateBeforeKyc from "./preValidateBeforeKyc";

app.post(
  "/onboarding/verify",
  preValidateBeforeKyc,
  async (req, res) => {
    // Se chegamos aqui, o formato é válido.
    // O input normalizado já está em req.body.value.
    const kycResult = await kycProvider.submit({
      document_number: req.body.value,
      country: req.body.country,
      // ... resto do payload do KYC provider
    });

    return res.json(kycResult);
  },
);

Caching local para evitar round-trips

Como a validação de formato é idempotente (o mesmo input devolve sempre o mesmo resultado), cachear os resultados localmente por uma janela razoável (por exemplo 24h) elimina round-trips redundantes quando o mesmo usuário reenvia o mesmo input — um padrão frequente em fluxos onde o usuário dá duplo clique, recarrega a página ou volta depois de corrigir um campo não relacionado.

const cache = new Map<string, { valid: boolean; ts: number }>();
const TTL_MS = 24 * 60 * 60 * 1000;

async function preValidateCached(
  country: string,
  type: string,
  value: string,
): Promise<boolean> {
  const key = `${country}:${type}:${value}`;
  const hit = cache.get(key);
  if (hit && Date.now() - hit.ts < TTL_MS) {
    return hit.valid;
  }

  try {
    const res = await fetch("https://api.normadata.io/v1/verify/tax-id", {
      method: "POST",
      headers: {
        "X-API-Key": process.env.NORMADATA_API_KEY!,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ country, type, value }),
      signal: AbortSignal.timeout(2000),
    });

    const result = await res.json();
    cache.set(key, { valid: result.valid, ts: Date.now() });
    return result.valid;
  } catch {
    // Se a Normadata está caída ou lenta, deixe passar para o KYC.
    // Melhor pagar uma tentativa do que rejeitar um usuário válido.
    return true;
  }
}

ROI: como pensar o custo da Normadata vs a economia do KYC

O ROI depende inteiramente do seu volume e da sua taxa de malformados. A aritmética é direta: se você pré-valida N requests/mês a custo C_N por request da Normadata, e a economia de evitar tentativas KYC malformadas é (taxa × C_KYC × N), o ponto de equilíbrio é quando taxa × C_KYC > C_N. Como C_KYC costuma ser uma ou duas ordens de magnitude maior que C_N (as faixas públicas sugerem USD 0,50 a 3,00+ para KYC vs valores significativamente menores para validação de formato), mesmo taxas modestas de malformados produzem um ROI positivo. Não vamos te dar um percentual de economia garantido — isso é genuinamente função dos seus dados. O que podemos dizer é que o exercício de medir vale a pena: uma amostra de 1.000-10.000 tentativas cruzada com outcomes do KYC te dá um número defensável para apresentar ao financeiro.

Caveat honesto: pré-validação NÃO substitui o KYC

Este padrão complementa o KYC, não o substitui. A validação de formato não faz nenhuma das coisas que um KYC real faz: não consulta sanções, não verifica PEP, não faz prova de vida, não compara o documento contra a base de registro, não detecta fraude documental. Essas tarefas requerem acesso a dados do mundo real e a sistemas governamentais que a Normadata explicitamente não toca. Os providers que cobrem esse trabalho na LATAM continuam necessários:

• Sumsub, Onfido, Veriff, Persona, Trulioo — Plataformas globais com cobertura LATAM.
• Idwall, Truora, Mati / Metamap, Didit — Providers com foco LATAM ou emergente para identidade e screening.
• A Normadata não tem partnership com nenhum desses — são mencionados como categorias publicamente conhecidas. Sua escolha de KYC é independente de você introduzir pré-validação de formato antes.

Próximos passos

Se seu pipeline KYC tem volume não trivial e você ainda não tem pré-validação estrutural antes do provider pago, o primeiro passo é medir. Tire uma amostra de 1.000-10.000 tentativas KYC recentes com seus outcomes, passe por um validador de formato e conte os inputs que falharam formato e também KYC — esse é seu floor de economia. Para o endpoint que usamos nos exemplos, veja /docs/api/verify-tax-id. Para o caso de uso completo com padrões adicionais, veja /use-cases/kyc-pre-validation. Para acesso à API, /waitlist. Para uma visão mais ampla do custo de inputs malformados no contexto de KYC, leia também /blog/kyc-budget-malformed-data.