La respuesta corta

El KYC de una app no se construye: se integra. Nadie monta su propio motor de verificación documental y de detección de vida, porque el valor no está en el algoritmo sino en la cobertura de documentos, en el mantenimiento continuo frente al fraude y en la responsabilidad regulatoria.

La decisión real no es «qué proveedor», sino dónde colocas el KYC dentro del embudo. Es el punto donde más gente abandona de toda la app, y el orden de las pantallas mueve más la conversión que la marca del proveedor.

Las tres piezas que suele incluir

Conviene separarlas porque se contratan por separado y fallan por separado:

  1. Verificación documental. Captura del documento, comprobación de que es auténtico y extracción de datos.
  2. Prueba de vida y comparación facial. Que hay una persona real delante y que es la del documento.
  3. Comprobaciones de listas. Sanciones, personas con responsabilidad pública, medios adversos.

Muchos proyectos contratan las tres al mismo proveedor y descubren tarde que la tercera la quería el departamento de cumplimiento con otro criterio y otro histórico.

Dónde colocarlo: la decisión que decide la conversión

El patrón que más abandono provoca es pedir el KYC antes de que el usuario haya visto nada de valor. El que mejor funciona en la mayoría de productos:

  1. Registro mínimo — correo o teléfono, y nada más.
  2. El usuario ve el producto y entiende para qué sirve.
  3. KYC en el momento en que lo exige la operación: antes de mover dinero, de contratar o de retirar.

Eso no siempre se puede: hay productos donde la normativa obliga a verificar antes de dar acceso. Pero cuando se puede, mueve la aguja más que cualquier otra optimización del flujo.

Y una regla que ahorra rehacer trabajo: el KYC no es una pantalla, es un estado del usuario. Modela noVerificado, enRevisión, verificado y rechazado desde el principio, y decide qué puede hacer el usuario en cada uno. Si lo modelas como un paso del alta, el día que aparezca la revisión manual —y aparecerá— toca reescribir la navegación.

Lo que se subestima al integrar

La revisión manual existe. Ningún proveedor aprueba el 100 % automáticamente. Habrá un porcentaje que pase a revisión humana, con horas o días de por medio. Tu app necesita: un estado intermedio visible, una notificación cuando se resuelve, y una pantalla que explique qué pasa mientras tanto. Si no lo tienes, el usuario reintenta, genera duplicados y satura al equipo de cumplimiento.

El rechazo tiene causas, y unas se pueden reintentar y otras no. Un documento borroso se reintenta; una lista de sanciones no. Mapear los códigos del proveedor a mensajes accionables es la diferencia entre un usuario que lo consigue en el segundo intento y uno que se va.

La captura es el 80 % del problema. Reflejos, recortes, poca luz, documentos con holograma. Los SDK nativos de los proveedores llevan años puliendo esa guía en pantalla; una captura hecha con la cámara genérica del sistema dispara los rechazos. Si el proveedor ofrece SDK nativo, se usa el SDK.

Los webhooks son la fuente de verdad, no la respuesta del SDK. El resultado que devuelve el móvil es orientativo. El estado bueno llega por webhook a tu backend, y de ahí a la app. Un cliente que confía en lo que le dijo el SDK acaba con usuarios verificados en el móvil y no verificados en el sistema.

Cobertura, que no es un detalle

Antes de elegir proveedor, la pregunta concreta: ¿qué documentos, de qué países, y en qué idiomas? No «cobertura global». Si tu producto opera en varios mercados, esa lista se contrasta uno a uno, porque es donde se cae la promesa comercial.

Y con ella, dos preguntas más: dónde se procesan y se guardan los datos biométricos —hay implicaciones de protección de datos y de residencia—, y cuánto tiempo los conserva el proveedor. Es información que el departamento de cumplimiento del cliente va a pedir por escrito.

Lo que hay que medir desde el primer día

  • Tasa de finalización del flujo completo, y en qué pantalla se cae cada quien.
  • Tasa de aprobación automática frente a revisión manual.
  • Tiempo hasta resolución en los casos manuales.
  • Reintentos por usuario y motivo de rechazo.
  • Coste por verificación, que se factura por intento y no por usuario verificado.

Ese último punto sorprende en la primera factura: un flujo con mala captura no solo convierte peor, cuesta más dinero, porque cada reintento se paga.

Cuándo no integrar un KYC completo

  • Si la normativa no lo exige todavía para tu caso de uso. Añadirlo «por si acaso» es meter el mayor punto de fricción del producto sin obligación.
  • Si el usuario ya está verificado en el ecosistema del cliente. Reutilizar la verificación existente es siempre mejor que repetirla.
  • Si el volumen es bajo y el proceso es asistido. Hay negocios donde una revisión manual con un formulario seguro sale mejor que un SDK contratado por volumen.

Antes de estimar

  1. ¿Qué exige exactamente cumplimiento, y sobre qué norma?
  2. ¿Documentos de qué países y en qué idiomas?
  3. ¿Puede el KYC ir después de que el usuario vea valor, o tiene que ir antes?
  4. ¿Quién resuelve la revisión manual, con qué herramienta y en qué horario?
  5. ¿Qué pasa con un usuario rechazado: se le expulsa, se le deja en modo limitado, se le permite reintentar?

La cinco es la que casi nadie tiene contestada, y es la que define media docena de pantallas.

Nosotros lo hemos integrado en productos financieros y de seguros con onboarding regulado; el detalle de stack y referencias está en apps fintech y en apps para el sector seguros. Y si lo que llega es una firma de contrato al final del proceso, la parte de firma electrónica es otra conversación distinta que conviene no mezclar con esta.