Biometría facial para fintech en Perú: cumplimiento SBS y onboarding digital sin fricción

Por qué la biometría facial dejó de ser opcional en el fintech peruano

El contexto regulatorio y de mercado convergió en una misma dirección. La SBS reforzó las exigencias de seguridad para operaciones financieras: la Resolución SBS N° 2286-2024 estableció el doble factor de autenticación obligatorio para tarjetas de crédito y débito (operaciones presenciales y no presenciales), y la posterior Resolución SBS N° 00771-2026 fijó la entrada en vigor el 1 de junio de 2026. Aunque esta norma específica apunta a tarjetas y billeteras tokenizadas, marca el rumbo regulatorio: cualquier operación que pueda generar perjuicio al usuario exige autenticación reforzada. En paralelo, Open Finance abrió la puerta a billeteras y fintech no bancarias que necesitan verificar identidad sin sucursal, y los ataques de suplantación se sofisticaron con deepfakes generados por IA y videos sintéticos que superan los métodos tradicionales de verificación facial.

El efecto combinado es que el onboarding 100% digital, que hace cinco años era un diferenciador, hoy es la línea base del producto. Y mientras más fintech compiten por captar clientes sin oficina física, más alta es la barrera técnica que el regulador, la UIF (Unidad de Inteligencia Financiera) y la propia operación interna de fraude exigen.

La pregunta que el resto del artículo responde es directa: ¿qué tipo de biometría exige el regulador peruano y cómo se implementa sin que la experiencia del cliente se derrumbe?

Qué exige la SBS para verificación de identidad biométrica en 2026

La SBS no impone un único estándar técnico. Aplica un enfoque basado en principios: integridad de captura, vinculación del cliente al documento de identidad, trazabilidad de la verificación y proporcionalidad del control respecto al riesgo de la operación. En la práctica, esto se traduce en un conjunto de obligaciones que las empresas supervisadas deben cubrir, con biometría como herramienta dominante.

Las normas que aterrizan estas obligaciones son varias y conviven:

• Resolución SBS N° 2660-2015 — Reglamento de Gestión de Riesgos de Lavado de Activos y Financiamiento del Terrorismo. Define las exigencias de debida diligencia, identificación y verificación del cliente, y diferencia entre debida diligencia simplificada, normal y reforzada según perfil de riesgo. Es la base normativa de la que se desprende la obligación de verificar identidad con un nivel de control proporcional al riesgo de la operación.
• Resolución SBS N° 2286-2024 + Resolución SBS N° 00771-2026 — Reglamento de tarjetas de crédito y débito que impone doble factor de autenticación. La segunda resolución prorrogó el plazo de implementación al 1 de junio de 2026. El alcance específico cubre tarjetas y billeteras tokenizadas (Plin, Yape), no onboarding fintech genérico — pero define el estándar de seguridad que la SBS espera para operaciones que puedan generar perjuicio al usuario.
• Ley N° 27693 y reglamento — crea la Unidad de Inteligencia Financiera (UIF-Perú), define las obligaciones de los sujetos obligados y el rol del oficial de cumplimiento en el reporte de operaciones sospechosas.
• Ley N° 29733 (Protección de Datos Personales) y su nuevo reglamento, Decreto Supremo N° 016-2024-JUS (publicado el 30 de noviembre de 2024 y vigente desde el 31 de marzo de 2025). Los datos biométricos califican expresamente como dato sensible. El nuevo reglamento añade obligaciones reforzadas: notificación de incidentes de seguridad a la ANPD (Autoridad Nacional de Protección de Datos Personales), designación de un Oficial de Datos Personales en organizaciones que tratan datos sensibles a gran escala, y adopción de estándares como ISO/IEC 27001.
• Ley N° 31814 (Ley de IA) y su reglamento — marco peruano que promueve el uso de IA y establece principios de transparencia, supervisión humana y proporcionalidad cuando la IA se usa en decisiones automatizadas. Aplica cuando la biometría es el motor de una decisión de onboarding (aceptar o rechazar al cliente).
• Ley N° 32314 — modifica el Código Penal (Decreto Legislativo 635) y la Ley 30096 de Delitos Informáticos para tipificar penalmente los delitos cometidos mediante inteligencia artificial: deepfakes, suplantación automatizada de identidad y generación de contenido falso para defraudar o extorsionar. Publicada el 26 de abril de 2025. La ley castiga al delincuente; el control técnico (biometría con liveness y PAD) sigue siendo responsabilidad de la fintech.

En el mercado regulado, el estándar técnico de facto para liveness detection es ISO/IEC 30107-3 PAD Level 2 (Presentation Attack Detection nivel 2). No es una exigencia escrita en una resolución SBS, pero las auditorías y debidas diligencias técnicas lo asumen como punto de partida.

Anatomía de un onboarding biométrico SBS-compliant

Un flujo SBS-compliant en 2026 se compone de siete pasos encadenados, donde cada uno cumple una función regulatoria específica. Saltarse uno —incluso por buenas razones de UX— abre boquete de compliance.

1. Captura del documento de identidad. Anverso y reverso del DNI con OCR, lectura del chip cuando el dispositivo lo permita, validación de elementos de seguridad (microimpresión, MRZ, holograma). Este paso establece la identidad declarada.
2. Validación cruzada con Reniec. Coincidencia entre los datos del documento capturado y la base oficial. Reduce el riesgo de DNI físico falsificado o de uso de documento ajeno.
3. Captura facial con liveness pasivo. El sistema valida que detrás de la cámara hay una persona viva real, sin pedirle al usuario que parpadee, sonría o gire la cabeza. El análisis es invisible: textura de piel, profundidad, micro-movimientos espontáneos, reflejos. Esto reduce abandono y elimina la fricción de los gestos forzados.
4. PAD Level 2 (anti-spoofing). El motor bloquea fotos impresas, videos en pantalla, máscaras 3D, deepfakes generados por IA y otros vectores de presentation attack. PAD Level 2 cubre los ataques más comunes en LATAM hoy, incluyendo los videos sintéticos.
5. Match facial 1:1 contra la foto del documento. El score de similitud se contrasta con un umbral de aceptación auditable. Lo que importa no es solo el resultado binario "aprobado/rechazado", sino que el score quede registrado para trazabilidad y para refinamiento del modelo.
6. Registro trazable del evento. Log inmutable con timestamp, score de match, evidencia (frame congelado y hash) para auditoría SBS y UIF. Esta es la capa que diferencia "verificar" de "demostrar que verificaste".
7. Storage cifrado o esquema zero-knowledge. El enfoque recomendado es procesar el match facial sin almacenar la plantilla biométrica como dato identificable, alineado con los principios de minimización de datos de la Ley 29733. Cuando la plantilla sí se guarda, debe ir cifrada con clave administrada bajo controles equivalentes al estándar bancario.

Cada uno de estos pasos es una decisión técnica con impacto regulatorio. Una fintech que captura el DNI pero no valida contra Reniec falla la debida diligencia. Una que verifica con liveness pero sin PAD certificado pasa fotos impresas. Una que aprueba el match pero no registra el log no puede demostrarlo en una auditoría.

Liveness pasivo vs activo: el dilema UX vs seguridad

Como explicamos en nuestra guía sobre qué es liveness detection, existen dos modalidades. Liveness activo pide al usuario gestos explícitos (parpadear, mover la cabeza, leer un código en voz alta). Liveness pasivo valida la presencia humana de forma invisible mediante análisis de textura, profundidad y micro-movimientos espontáneos.

En fintech, la decisión entre uno y otro tiene consecuencias económicas reales. Cada gesto adicional pedido al usuario en un onboarding agrega entre 5% y 15% de abandono según benchmarks de la industria. En verticales donde la tasa de abandono ya supera el 60%, esos puntos porcentuales son CAC perdido en escala. Y en el ecosistema fintech peruano, donde la competencia por captar clientes es feroz y el cliente migra de app en minutos, no es un detalle menor.

El argumento histórico a favor del liveness activo era que ofrecía mayor seguridad. En 2026 ese argumento dejó de sostenerse: los motores de liveness pasivo certificados PAD Level 2 e iBeta cubren los mismos vectores de ataque, sin pedir gestos, y sin la fricción que cuesta abandono. Es una de esas situaciones donde elegir bien la tecnología no obliga a sacrificar UX por seguridad — los dos objetivos se alinean.

KYC, AML y la diferencia entre verificar y vincular

Hay una distinción que la mayoría de los vendors omite y que la SBS audita explícitamente: verificar no es lo mismo que vincular.

Verificar consiste en confirmar que la persona detrás de la cámara es quien dice ser. Es lo que hace el flujo de los siete pasos del onboarding biométrico: captura, match, liveness, PAD.

Vincular consiste en asociar esa identidad verificada al producto, sesión o cuenta abierta, con una cadena de custodia inmutable que pueda demostrarse a un tercero (auditor SBS, oficial UIF, perito en un proceso judicial). Esto incluye token de sesión, log con marca temporal, registro de canal usado y pista de auditoría que cubra todo el ciclo de vida de la operación.

"Una fintech que solo verifica y no vincula falla la auditoría incluso si su tasa de match es del 99%."

La SBS no pregunta solo "¿confirmaste la identidad?", sino también "¿puedes probar, frente a una controversia, que esa identidad es la titular de esta operación?". Una solución bien diseñada entrega ambas capas en el mismo flujo: verificación + token de sesión vinculado + log auditable que cubre el evento completo.

Para el oficial de cumplimiento, la diferencia se traduce en si la fintech puede defender un caso de impugnación o no. Para el producto, en si la operación queda blindada o expuesta.

Riesgos específicos del fintech peruano: deepfakes, SIM swap y fraude sintético

El fintech peruano enfrenta tres vectores de fraude que la biometría facial bien implementada bloquea, y que los métodos tradicionales no:

Deepfakes. Videos generados por IA capaces de simular un rostro humano con expresiones realistas. Superan flujos de verificación facial débiles, sobre todo los basados en selfie estático. Un motor PAD Level 2 los detecta porque analiza textura de píxel, anomalías de iluminación y artefactos de generación; un selfie comparado contra DNI no.

SIM swap combinado con onboarding fraudulento. Un atacante secuestra el número telefónico de la víctima, recibe los SMS de verificación y abre cuenta o solicita crédito a nombre del titular real. La biometría rompe la cadena del ataque porque el rostro físico no se "swappea" con un trámite administrativo. El segundo factor biométrico convierte una vulnerabilidad de telecom en un control bancario robusto.

Identidad sintética (synthetic identity fraud). Combinación de un DNI real (a veces de una persona fallecida o de un menor de edad) con datos falsos para construir una identidad ficticia que aprueba checks documentales. La defensa es el cross-check múltiple: Reniec + biometría + comportamiento (device fingerprinting, velocidad de tipeo, geolocalización). La biometría es el ancla que hace que el resto se sostenga.

Estos tres vectores son justamente los que la Ley N° 32314 —vigente desde abril de 2025— tipificó penalmente al modificar el Código Penal y la Ley de Delitos Informáticos. Esa ley castiga al atacante; pero la responsabilidad de impedir que el ataque tenga éxito sigue siendo del proveedor del servicio. Y los datos del mercado lo reflejan: según reporte de Sovos publicado en Gestión, el mercado peruano duplicó la implementación de biometría digital en un año, con un crecimiento del 50% en verificaciones biométricas faciales durante 2023, y los intentos de suplantación con documentos alterados ya representan alrededor del 10% de las transacciones digitales en empresas que usan estas soluciones. La adopción creció porque el costo de no actuar —pérdidas operativas, sanción SBS, exposición ante la ANPD por incidentes de seguridad y daño reputacional— superó largamente el costo de implementar.

Cómo elegir vendor de biometría para fintech en Perú: 7 criterios no negociables

Antes de evaluar vendor, conviene establecer la matriz de criterios. Estos son los siete que un equipo de producto + compliance + seguridad debería revisar antes de firmar contrato:

1. Certificaciones técnicas auditables. ISO/IEC 30107-3 PAD Level 2 como mínimo. NIST FRVT (Face Recognition Vendor Test) e iBeta como referencias adicionales. Sin certificación, el motor opera bajo declaración del vendor — no bajo estándar verificable.
2. Liveness pasivo de fábrica. Sin gestos forzados como default. Si el vendor solo ofrece liveness activo, va a costar abandono.
3. Compatibilidad regulatoria local. Comprensión específica del marco peruano: SBS, UIF, Ley 29733, Ley 32314. Vendors internacionales sin partner local rara vez aterrizan los matices regulatorios peruanos.
4. Soberanía y privacidad de datos. ¿Dónde se procesa la imagen? ¿Dónde se almacena la plantilla biométrica? ¿Existe esquema zero-knowledge? Una arquitectura alineada con estándares europeos (GDPR) ofrece un piso de protección reforzado y funciona como respaldo cuando una autoridad peruana pregunta cómo se trata el dato sensible.
5. API/SDK con onboarding ágil. Integración medida en semanas, no en trimestres. Documentación clara, sandbox disponible, soporte técnico real. Una integración que demora seis meses retrasa el producto y aumenta el costo por cliente captado.
6. Soporte técnico local en Perú. Huso horario, idioma, contrato bajo ley peruana. Cuando un componente crítico falla un domingo a las 11 PM en pleno cierre de mes, importa quién contesta el teléfono.
7. Trazabilidad y auditoría. Logs inmutables, evidencia exportable, dashboard de cumplimiento disponible para el oficial de cumplimiento. Si la herramienta no facilita la auditoría, va a ser una espina en cada revisión SBS.

Bio'lock, nuestra solución de identidad digital en Altimea, cumple los siete criterios con una propuesta diferenciada en privacidad por diseño: arquitectura zero-knowledge, certificación PAD Level 2, soporte local en Lima e integración promedio en 1 a 2 semanas para fintech con stack moderno.

Errores frecuentes en implementación (y cómo evitarlos)

En proyectos de biometría que hemos revisado, los errores se repiten:

• Saltarse liveness para "simplificar UX". Atajo costoso. El abandono no se reduce significativamente y la auditoría SBS lo va a marcar.
• Almacenar la imagen del rostro como blob sin cifrar. Choca con el régimen de dato sensible de la Ley 29733 y el DS 016-2024-JUS. Si hay incidente, la fintech queda obligada a notificar a la ANPD y queda expuesta a sanción.
• Usar liveness activo barato sin PAD certificado. Pasa fotos impresas y videos en pantalla. La aparente seguridad es ilusoria.
• No registrar log de match con score. Sin trazabilidad para SBS y UIF, una controversia se vuelve indefendible aunque el flujo haya operado correctamente.
• Tratar la biometría como feature de producto, no como capa de compliance. El equipo de producto la integra, pero la lógica de fallback (qué pasa cuando el score es ambiguo, cuando el liveness rechaza dos veces, cuando el cliente está en una zona con mala conexión) queda sin diseñar. Y es justo en los casos ambiguos donde se decide la experiencia real.

FAQ: las preguntas frecuentes de fintech y bancos sobre biometría

¿Es obligatorio usar biometría facial en onboarding fintech en Perú?

No existe una norma SBS que diga "debes usar biometría facial". Lo que sí existe es la obligación de verificar identidad con un nivel de seguridad proporcional al riesgo. En la práctica, para onboarding 100% digital, biometría facial es el método estándar que el regulador y el mercado asumen.

¿Liveness activo o pasivo cumple mejor SBS?

Ambos pueden cumplir si están certificados PAD Level 2. La diferencia es UX. La SBS no exige una modalidad específica; exige que el control sea efectivo y proporcional al riesgo.

¿Puedo almacenar la foto del rostro del cliente?

Solo con consentimiento expreso, finalidad declarada, plazo definido y medidas de seguridad reforzadas, según Ley 29733 y su nuevo reglamento (DS 016-2024-JUS, vigente desde marzo 2025). Lo recomendable es minimizar: guardar el match score y el hash de la imagen, no la imagen en sí. Los esquemas zero-knowledge de Bio'lock evitan el problema desde el diseño.

¿Qué pasa si el match falla? ¿Cómo manejo el fallback?

Diseñar fallback es parte del flujo, no una excepción. Las opciones típicas son reintento con captura mejorada, escalamiento a verificación con video-llamada asistida, o derivación a sucursal cuando el caso lo amerita. Sin fallback, el cliente se va.

¿Bio'lock funciona offline o con baja conectividad?

Sí. La captura inicial se hace en el dispositivo y la verificación se sincroniza cuando la conexión se restablece, manteniendo la trazabilidad del evento. Esto importa especialmente en regiones del país con conectividad intermitente.

¿Cuánto demora integrar biometría en una app fintech?

Para una fintech con stack moderno (mobile nativa o React Native, backend con APIs REST), una integración Bio'lock se ejecuta entre 1 y 2 semanas, incluyendo sandbox, pruebas con datos reales y go-live progresivo.