Por qué pre-validar datos antes del KYC te ahorra dinero — con números

El modelo de pricing de los providers KYC es per-attempt, no per-success. Cada vez que mandás un documento, una verificación de identidad o un check de prueba de vida, se factura una unidad de costo, independientemente de si el check pasa, falla, o el input nunca podría haber pasado porque estaba estructuralmente roto desde el origen. En el universo de checkout mobile-first de LATAM, una fracción medible de los inputs llegan ya muertos al pipeline: typos, separadores incorrectos, copy-paste de planillas con encoding raro, ceros iniciales eliminados por software de spreadsheet. Si tu sistema empuja todos esos al KYC sin filtro previo, estás pagando por verificar lo imposible. Este post explica el modelo, la matemática del ahorro y el patrón concreto de middleware para introducir un gate de pre-validación antes del proveedor pago.

Cómo cobra el proveedor KYC (modelo per-seat / per-attempt)

Los proveedores KYC publicitan dos modelos principales: per-attempt (se factura por intento de verificación) y per-seat / per-active-user (se factura por usuario único verificado en un período). En ambos, el costo se incurre antes de saber el outcome. En el modelo per-attempt, cada submission al endpoint del provider es una unidad; un retry sobre el mismo documento puede ser otra unidad si el sistema no deduplica. En el modelo per-seat, una vez que un usuario activa una verificación, contás contra tu cuota sin importar si el flujo completa o no. Los rangos públicos típicos de la industria van desde USD 0,50 a USD 3,00+ por verificación, dependiendo del tipo de check (solo documento vs. documento + prueba de vida vs. screening AML). El número exacto está sujeto a tu contrato y no es algo que afirmemos acá. Lo que sí importa es la estructura: pagás por intento, no por éxito.

El funnel típico de un checkout mobile-first LATAM

En flujos mobile-first de LATAM, donde una buena parte de los usuarios entran desde apps con teclados numéricos limitados, paste-from-clipboard frecuente y conexiones inestables, los inputs estructurales malformados llegan a tasas que varían entre 10% y 25% según el segmento. Las causas más frecuentes que vemos discutidas en la industria:

• Typos por teclado mobile — Un usuario que tipea su CPF en un teléfono con keyboard chico inserta o salta un dígito en ~3-8% de los intentos.
• Copy-paste con basura — Cuando el usuario copia su CUIT desde un email o WhatsApp, frecuentemente arrastra espacios, comillas tipográficas, saltos de línea o caracteres invisibles (zero-width spaces).
• Formatos inconsistentes — Un CPF tipeado como 11144477735 vs 111.444.777-35 vs 111 444 777 35 — un validador estricto del lado del KYC puede rechazar uno y aceptar otro.
• Spreadsheet zero-stripping — Datasets importados desde Excel o Google Sheets pierden ceros a la izquierda en RUC peruanos o RUT uruguayos.
• Field mismatch — En B2B onboarding, un CNPJ se carga en el campo de CPF, o un CUIT en el de CBU. El KYC tira mismatch y se factura.
• Bots y sintéticos — Submissions automáticas con identificadores aleatorios. El KYC los rechaza pero los cuenta.

La matemática del ahorro (con números ilustrativos)

Esta es la fórmula básica: gasto desperdiciado = (intentos_malformados / intentos_totales) × precio_por_intento × volumen_mensual. La primera variable es la única que tenés que medir vos mismo; no podemos darte una tasa universal porque depende de tu pipeline, tu validación frontend existente y tu base de usuarios.

Como ejercicio ilustrativo: imaginá 10.000 verificaciones KYC por mes a USD 1,50 por intento promedio — gasto mensual total USD 15.000. Con una tasa de malformados del 5%, son 500 intentos × USD 1,50 = USD 750/mes en checks que nunca iban a pasar. Con 10%, USD 1.500/mes. Con 18% (cota frecuentemente citada para mobile-first sin validación frontend), USD 2.700/mes. Estos números son hipotéticos y solo sirven para ilustrar la mecánica — tu tasa real puede ser sustancialmente más alta o más baja. La única forma de saberlo es medir.

Cómo encaja Normadata antes del KYC

El patrón de integración es un gate de pre-validación: el documento ingresa, se pasa por POST /v1/verify/tax-id o por el endpoint Smart Parse, y solo si Normadata devuelve valid: true se procede al provider pago. Si valid es false, devolvés un error al usuario, evitás la llamada KYC y no consumís ningún intento facturable. Como la validación de formato es matemática pura, la latencia es despreciable comparada con cualquier KYC real (que suele moverse en segundos por la prueba de vida y los checks de registro). Veamos el patrón concreto en 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) {
    // El input está malformado en origen — no llamar al KYC.
    return res.status(422).json({
      error: "invalid_tax_id_format",
      hint: result.metadata?.reason ?? "format_check_failed",
    });
  }

  // Adjuntar el formato canónico al request y continuar al 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) => {
    // Si llegamos acá, el formato es válido.
    // El input normalizado ya está en req.body.value.
    const kycResult = await kycProvider.submit({
      document_number: req.body.value,
      country: req.body.country,
      // ... resto del payload del KYC provider
    });

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

Caching local para evitar round-trips

Como la validación de formato es idempotente (el mismo input devuelve el mismo resultado siempre), cachear los resultados localmente por una ventana razonable (por ejemplo 24h) elimina round-trips redundantes cuando el mismo usuario reintenta el mismo input — un patrón frecuente en flujos donde el usuario hace doble clic, recarga la página o vuelve después de corregir un campo no 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 {
    // Si Normadata está caído o lento, dejá pasar al KYC.
    // Mejor pagar un intento que rechazar a un usuario válido.
    return true;
  }
}

ROI: cómo pensar el costo de Normadata vs el ahorro KYC

El ROI depende enteramente de tu volumen y tu tasa de malformados. La aritmética es directa: si pre-validás N requests/mes a costo C_N por request de Normadata, y el ahorro de evitar intentos KYC malformados es (tasa × C_KYC × N), el punto de equilibrio es cuando tasa × C_KYC > C_N. Como C_KYC suele ser uno o dos órdenes de magnitud mayor que C_N (los rangos públicos sugieren USD 0,50 a 3,00+ para KYC vs valores significativamente menores para validación de formato), incluso tasas modestas de malformados producen un ROI positivo. No vamos a darte un porcentaje de ahorro garantizado — eso es genuinamente función de tu data. Lo que sí podemos decir es que el ejercicio de medir vale la pena: una muestra de 1.000-10.000 intentos cruzada contra outcomes de KYC te da un número defendible para presentar al equipo de finanzas.

Caveat honesto: pre-validación NO reemplaza KYC

Este patrón complementa al KYC, no lo reemplaza. La validación de formato no hace ninguna de las cosas que un KYC real hace: no consulta sanciones, no verifica PEP, no hace prueba de vida, no compara el documento contra la base de registro, no detecta fraude documental. Esas tareas requieren acceso a datos del mundo real y a sistemas gubernamentales que Normadata explícitamente no toca. Los proveedores que cubren ese trabajo en LATAM siguen siendo necesarios:

• Sumsub, Onfido, Veriff, Persona, Trulioo — Plataformas globales con cobertura LATAM.
• Idwall, Truora, Mati / Metamap, Didit — Proveedores con foco LATAM o emergente para identidad y screening.
• Normadata no tiene partnership con ninguno de estos — se mencionan como categorías públicamente conocidas. Tu elección de KYC es independiente de si introducís pre-validación de formato antes.

Próximos pasos

Si tu pipeline KYC tiene volumen no trivial y todavía no tenés pre-validación estructural antes del provider pago, el primer paso es medir. Sacá una muestra de 1.000-10.000 intentos KYC recientes con sus outcomes, pasala por un validador de formato y contá los inputs que fallaron formato y también KYC — ese es tu floor de ahorro. Para el endpoint que usamos en los ejemplos, ver /docs/api/verify-tax-id. Para el caso de uso completo con patrones adicionales, ver /use-cases/kyc-pre-validation. Para acceso a la API, /waitlist. Para una visión más amplia del costo de inputs malformados en el contexto de KYC, leé también /blog/kyc-budget-malformed-data.