Cuánto presupuesto KYC se te va en data malformada (y cómo medirlo)

Cada vez que tu sistema manda un número de documento a un proveedor KYC — Sumsub, Onfido, Veriff, Persona, Trulioo, Idwall, Truora, Mati, o cualquier otro — pagás por ese intento. Al proveedor no le importa si el input era un número de documento real y bien formado, o una cadena de caracteres que nunca podría pertenecer a ninguna persona o empresa. El contador corre igual. Lo que muchos equipos de ingeniería y compliance descubren demasiado tarde es que una fracción medible de esos intentos llega ya muerta: el input estaba malformado en el origen — un typo en un formulario de checkout, un campo de CRM legacy que almacenó datos sin validación, una importación en bulk de una planilla vieja, un bot llenando un flujo de registro. El check KYC no puede pasar para un documento con el formato incorrecto. Nunca iba a pasar. Pagaste igual. Este post explica cómo funciona el pricing de KYC, de dónde vienen los inputs malformados, qué errores son detectables antes de llamar al proveedor KYC, y — lo más importante — cómo calcular tu propio número. Te damos la fórmula y un ejemplo hipotético trabajado. No te vamos a dar un porcentaje de ahorro garantizado, porque eso depende enteramente de tu data, que solo vos podés medir.

Cómo cobra el proveedor KYC

El modelo de pricing dominante en el mercado de verificación de identidad es la facturación por intento o por verificación. Cada vez que enviás un documento, un check de identidad, o una solicitud de prueba de vida, se te cobra una unidad de costo. Los rangos citados públicamente por la industria sugieren que estos precios por unidad pueden ir desde aproximadamente USD 0,50 hasta USD 3,00 o más por intento, dependiendo del tipo de check (solo documento vs. documento más prueba de vida vs. screening completo AML/watchlist), el vendor, el volumen contratado y la región geográfica verificada. Algunos vendors publican pricing por niveles; otros cotizan según compromisos de volumen. El precio específico que paga tu organización está gobernado por tu contrato — los rangos de arriba son estimaciones citadas públicamente, no los precios de ningún vendor en particular. Lo que importa para este análisis no es el número exacto, sino la estructura: pagás por intento, sea exitoso o no, con input bien formado o no.

De dónde vienen los inputs malformados

Los números de documento malformados que entran a tu pipeline KYC no aparecen de la nada. Vienen de fuentes predecibles:

• Formularios de checkout y registro sin validación frontend — El usuario tipea su tax ID en el formato que recuerda: con guiones, sin guiones, con espacios, con la cantidad incorrecta de dígitos. Si no hay feedback inmediato, ese input llega al backend y eventualmente a la cola KYC.
• Sistemas CRM o ERP legacy — Muchas empresas tienen años de registros de clientes acumulados antes de que alguien pensara en validación de identificadores. Un registro de contacto puede tener un campo RFC que contiene una fecha, un nombre, o una nota de texto libre dejada por un vendedor.
• Onboarding de marketplace y B2B — Cuando sellers, proveedores o contratistas auto-reportan su tax ID durante el onboarding, la tasa de error es típicamente más alta que en flujos de consumidores. Hay menos motivación para ser preciso, y frecuentemente no hay validación en el formulario de onboarding.
• Importaciones en bulk de datasets viejos — Migrar desde un sistema legacy o importar una lista de contactos casi siempre introduce problemas de formato: ceros iniciales eliminados por software de planillas, problemas de encoding al convertir de Latin-1 a UTF-8, desajustes de campos donde un CNPJ se guardó en un campo de CPF.
• Bots e inputs sintéticos — Las submissions automáticas de formularios que testean el sistema o intentan fraude frecuentemente usan identificadores sintéticos o estructuralmente inválidos.

Errores que no requieren KYC para detectarse

El insight crítico es que muchos números de documento malformados fallan un check de formato que cuesta prácticamente nada correr — y ese check puede suceder antes de llamar al proveedor KYC. La validación de formato es matemática determinista: no consulta ninguna base de datos, no depende de ningún registro externo, y puede correr en microsegundos. Estas son categorías de errores puramente estructurales que no requieren ninguna llamada KYC para identificarse:

• Patrones CPF con todos los dígitos iguales — La Receita Federal brasileña nunca emite CPFs donde los once dígitos sean iguales. 000.000.000-00 a 999.999.999-99 son todos estructuralmente inválidos. Pasan el algoritmo matemático de dígito verificador pero están explícitamente en lista negra. Cualquier ocurrencia está garantizada a fallar el KYC real. Ver /methodology/cpf-check-digit.
• CNPJ con dígito verificador incorrecto — El identificador de empresas brasileño usa un cálculo de dígito verificador de módulo 11 en dos pasos. Un CNPJ con cualquier error de transcripción en su cuerpo de 14 dígitos producirá un mismatch en el dígito verificador. Ningún proveedor KYC puede validar un CNPJ que falla este check porque no existe ninguna empresa con esos datos en el registro de la Receita Federal.
• CUIT con prefijo inválido — Los CUITs argentinos usan un prefijo de dos dígitos para codificar el tipo de entidad. Solo los prefijos 20, 23, 24, 27, 30, 33 y 34 son emitidos por AFIP. Un CUIT que empieza con cualquier otro prefijo es estructuralmente inválido. Ver /methodology/cuit-check-digit.
• RFC con fecha imposible — El RFC mexicano codifica la fecha de nacimiento o constitución en formato AAMMDD. Un RFC con mes 13 o día 45 es imposible y estructuralmente inválido. El SAT nunca lo emitió.
• Números de documento con longitud incorrecta — Cada identificador tiene una longitud definida después de normalizar: el CUIT es siempre 11 dígitos, el CPF siempre 11 dígitos, el CNPJ siempre 14, el RFC 12 o 13 caracteres. Cualquier input más corto o más largo luego de eliminar caracteres de formato es inválido.
• Problemas de whitespace, separadores y encoding — Espacios al inicio o al final, guiones no estándar, bytes nulos, o artefactos de encoding de imports CSV no pueden parsearse como identificadores válidos.
• Fallas IBAN MOD-97 — Los números de cuenta bancaria IBAN llevan un check MOD-97. Un IBAN que falla este check nunca fue emitido por ningún banco.

El framework de cálculo (honesto)

Esta es la fórmula para estimar el gasto KYC desperdiciado en inputs malformados. La presentamos con honestidad: la primera variable es una que tenés que medir vos mismo.

Gasto desperdiciado = (intentos_malformados / intentos_totales) x precio_por_intento x intentos_totales_por_mes. El ratio intentos_malformados / intentos_totales es tu tasa de malformados. No te podemos dar este número — depende enteramente de tus fuentes de input, tu validación frontend existente, tu pipeline de datos y tu base de usuarios. Lo que sí podemos mostrarte es cómo se ve la matemática a diferentes tasas, usando un ejemplo hipotético solo para ilustración. Estos números no son benchmarks, no son promedios de ningún dataset, y no son predicciones para tu situación.

• Ejemplo ilustrativo: 10.000 intentos KYC por mes a un costo promedio de USD 1,50 por intento (gasto mensual total: USD 15.000).
• Con una tasa de malformados del 5%: aproximadamente 500 intentos malformados por mes = aproximadamente USD 750 por mes en checks que nunca iban a pasar.
• Con una tasa del 10%: aproximadamente 1.000 intentos malformados = aproximadamente USD 1.500 por mes.
• Con una tasa del 20%: aproximadamente 2.000 intentos malformados = aproximadamente USD 3.000 por mes.
• Tus números reales van a diferir. Estos se muestran para ilustrar el método, no para predecir tu resultado.

Cómo medir tu propia tasa de malformados

Para obtener un número real de tu situación, necesitás correr tu data real por validación de formato y comparar los resultados con tu log de outcomes de KYC. Este es un enfoque concreto:

• Exportá una muestra de intentos KYC recientes — Sacá 1.000 a 10.000 filas del log de intentos de tu proveedor KYC o de tu propia base de datos. Incluí el valor de input enviado y el outcome (pass, fail, error).
• Corré validación de formato sobre la muestra — Pasá cada número de documento por un validador de formato. Existen librerías open-source para CPF, CNPJ, CUIT, RFC y otros identificadores. Normadata Validate cubre estos y más mediante un único endpoint REST en /validators si querés testear múltiples tipos de identificadores sin mantener librerías separadas.
• Cruzá con los outcomes KYC — Para los intentos que fallaron la validación de formato, verificá si también fallaron el KYC. Si un documento falló tanto la validación de formato como el KYC, es un candidato para la categoría malformado. Si un documento pasó la validación de formato pero falló el KYC, la falla fue por una razón sustantiva (match en sanctions, flag PEP, fraude documental, documento vencido) — no es algo que la validación de formato upstream pudiera haber prevenido.
• Calculá el ratio — (cantidad de format-inválidos Y KYC-fallidos) / (total de intentos KYC en la muestra). Aplicalo a tu volumen mensual completo y a tu costo real por intento.
• Repetí en una muestra fresca luego de deployar la validación de formato upstream — Confirmá que la tasa baja.

El stack recomendado: validación de formato más KYC, no en lugar de KYC

La validación de formato no reemplaza el KYC. Es un gate que corre antes del KYC. El flujo: recolectás el número de documento del usuario, corrés validación de formato (check de longitud, estructura, dígito verificador, patrones conocidos inválidos), si el formato es inválido devolvés un error al usuario y no llamás al KYC, si el formato es válido procedés al KYC. El proveedor KYC entonces hace el trabajo que la validación de formato no puede hacer: check biométrico de prueba de vida, verificación de autenticidad documental, screening de sanctions, consulta de base de datos PEP, adverse media y confirmación de registro ante autoridades como AFIP, Receita Federal, SAT, SII, DIAN, SUNAT, SENIAT, IRS o CRA. Esos checks requieren data del mundo real que la matemática de formato no puede acceder. La validación de formato upstream solo filtra los inputs que estaban garantizados a fallar antes de que cualquier trabajo real pudiera comenzar. Los proveedores KYC que atienden el mercado LATAM incluyen plataformas globales como Sumsub, Onfido, Veriff, Persona y Trulioo, y proveedores nativos de LATAM como Idwall, Truora y Mati. Normadata no tiene partnership con ninguno de estos vendors — se mencionan como ejemplos públicamente conocidos de la categoría. Tu elección de vendor KYC es independiente de si agregás una capa de validación de formato antes del KYC. Para el caso de uso completo, ver /use-cases/kyc-pre-validation.

Qué NO ahorra la validación de formato upstream

La validación de formato no reduce los costos de intentos KYC donde el input está bien formado pero el check falla por una razón sustantiva. Si alguien envía un CUIT sintácticamente válido que pertenece a una entidad sancionada, el check de formato pasa y la llamada KYC procede — y esa llamada KYC cuesta dinero independientemente del outcome. Si un número de documento es estructuralmente válido pero la persona es PEP, o el check de prueba de vida falla, o el documento está vencido, la validación de formato no hizo nada para prevenir ese costo. Esos son costos inherentes a hacer KYC correctamente. El único gasto que la validación de formato upstream puede abordar es el subconjunto de intentos donde el input estaba estructuralmente roto antes de que el trabajo real de verificación pudiera comenzar. Para entender el límite completo entre lo que Normadata valida y lo que no, ver /what-we-dont-do.

Preguntas frecuentes

¿La validación de formato reemplaza la consulta a registros oficiales? No. La validación de formato verifica estructura matemática — dígitos verificadores, longitud, charset, patrones conocidos inválidos. No confirma que el identificador esté activo, pertenezca a quien lo reclama, o exista en ningún registro oficial. ¿Puedo validar IBAN, SSN o EIN con el mismo enfoque? Sí — el IBAN tiene un check MOD-97 que detecta la mayoría de errores de transcripción. El SSN y el EIN tienen reglas de número de área y formato que filtran inputs obviamente inválidos. Normadata Validate cubre estos en /validators. ¿Y si mi proveedor KYC ya hace validación de formato antes de cobrar? Algunos providers realizan checks básicos de formato de su lado y pueden no cobrar por inputs que fallan un check estructural inmediato. Confirmalo con tu vendor y testealo contra inputs conocidos inválidos — no lo asumas. ¿Cómo interactúa esto con mi lógica de reintentos existente? Si tu sistema reintenta intentos KYC fallidos, los inputs malformados pueden reintentarse múltiples veces antes de que un humano los revise. Cada reintento es un intento facturable separado. Validar el formato upstream elimina el loop de reintentos para inputs estructuralmente inválidos.

Próximos pasos

Si querés probar validación de formato upstream sobre tu propia data, Normadata Validate está en acceso anticipado — solicitá acceso en /waitlist. Para el walkthrough completo del caso de uso incluyendo patrones de integración y ejemplos de respuesta, ver /use-cases/kyc-pre-validation. Para entender qué valida Normadata y qué no, ver /what-we-dont-do.

Aviso: Este artículo cita rangos de pricing publicados públicamente; los precios específicos de cada vendor (Sumsub, Onfido, Veriff, Idwall, etc.) varían por contrato y no son afirmados por Normadata. Los porcentajes y números de ejemplo de arriba son ilustrativos — muestran cómo funciona el método de cálculo, no benchmarks de data real de clientes. Para obtener un número significativo para tu situación, vas a tener que medirlo sobre tu propia data.