Cómo funcionan los SDK de Regula en dispositivos móviles

Un navegador puede abrir una cámara y guiar al usuario durante una sesión básica de captura. Un smartphone puede ir más allá: permite controlar con mayor precisión la experiencia de captura, utilizar directamente el hardware del dispositivo y, en muchos modelos, leer chips RFID de documentos de identidad electrónicos mediante NFC. Esto proporciona a los programas KYC evidencias más sólidas que un par de imágenes cargadas.

Este artículo analiza Regula Document Reader SDK y Regula Face SDK para dispositivos móviles desde una perspectiva práctica: qué se ejecuta en el dispositivo, qué requiere soporte del servidor, qué decisiones relacionadas con las bases de datos y los paquetes afectan al diseño del producto y cómo se integra la misma lógica de los SDK en aplicaciones nativas y multiplataforma.

El escaneo de documentos en dispositivos móviles debe identificar qué tipo de documento de identidad se está examinando, extraer los campos correctos, comprobar si la calidad de la captura es suficiente y proporcionar al equipo de verificación algo más sólido que el texto OCR sin procesar. En los procesos de mayor riesgo, esto también puede implicar la lectura del chip RFID y la comparación de sus datos con la información capturada visualmente.

Document Reader SDK gestiona el escaneo como una sesión estructurada, en lugar de una simple carga de fotografías. Puede localizar el documento dentro del encuadre, identificar su tipo, leer la MRZ, los códigos de barras y los campos de la zona visual, recortar la foto del titular o la firma, proporcionar información sobre la calidad de la imagen, ejecutar las comprobaciones de autenticidad compatibles e incorporar resultados RFID cuando la lectura del chip forme parte del proceso.

El SDK funciona mediante sesiones de escaneo. Usted selecciona un escenario de procesamiento, inicia la captura con la interfaz de cámara integrada o mediante un flujo de cámara personalizado y recibe resultados estructurados.

Para los documentos de identidad más comunes, los resultados pueden incluir:

• Datos de MRZ, validación de MRZ y códigos de MRZ
• Campos de códigos de barras
• OCR de la zona de inspección visual (VIZ)
• Campos gráficos, como la foto del titular o la firma
• Información sobre la calidad de la imagen
• Resultados de las comprobaciones de autenticidad
• Datos de la sesión RFID cuando la lectura del chip forma parte del proceso

Los resultados exactos dependen del escenario seleccionado, el documento, el paquete del motor y la base de datos incluida en la aplicación. Un proceso ligero que solo necesite escanear la MRZ y leer códigos de barras puede mantenerse más pequeño y sencillo, mientras que una comprobación documental más rigurosa normalmente requiere identificación del tipo de documento, OCR de la zona visual, comprobaciones de autenticidad, una base de datos y, para los documentos de identidad electrónicos compatibles, procesamiento RFID.

La base de datos de documentos es un archivo db.dat. Es necesaria cuando la aplicación debe reconocer tipos de documentos y zonas visuales, pero no se requiere para el reconocimiento de MRZ, el reconocimiento de códigos de barras ni el recorte de imágenes.

Cuando se necesita una lógica documental más avanzada, la base de datos puede incluirse en la aplicación para su uso sin conexión, descargarse mediante prepareDatabase o actualizarse mediante runAutoUpdate. Una base de datos personalizada puede reducir el tamaño de la aplicación al limitar la cobertura por país, tipo de documento, idioma, documentos con chips RFID o comprobaciones de seguridad seleccionadas.

La selección del paquete del motor sigue el mismo principio en iOS, Android y Flutter. La aplicación incluye el paquete API y un paquete del motor que corresponde a las funciones autorizadas por la licencia y al nivel de profundidad de verificación requerido por el proyecto. La diferencia entre plataformas radica principalmente en cómo se añade la dependencia, no en las capacidades del SDK: iOS utiliza CocoaPods, Swift Package Manager o integración manual; Android utiliza Gradle o integración manual; y Flutter utiliza los paquetes indicados en pubspec.yaml.

Las familias de paquetes del motor disponibles abarcan distintas combinaciones de lectura de MRZ, reconocimiento de códigos de barras, procesamiento de chips RFID, identificación del tipo de documento, OCR de la zona visual, detección de límites del documento, recorte de campos gráficos y comprobaciones de seguridad.

El procesamiento de chips RFID permite leer mediante NFC los datos almacenados en el chip sin contacto de un documento de identidad electrónico. El chip puede almacenar los mismos datos personales impresos en la página de datos del documento, como nombre completo, fecha de nacimiento, lugar de nacimiento, fecha de expedición y fecha de vencimiento. También puede almacenar una imagen digital de la foto del titular, un número de identificación del chip y una firma digital utilizada como medida de protección.

Document Reader SDK lee chips RFID conforme a ISO/IEC 14443 en dispositivos compatibles con NFC y puede ejecutar procedimientos de autenticación pasiva, activa, de chip y de terminal. Las aplicaciones móviles suelen utilizar el módulo NFC integrado del teléfono, mientras que las implementaciones especializadas también pueden utilizar lectores RFID externos mediante Bluetooth.

En la mayoría de los procesos de verificación, la lectura del chip se realiza después del procesamiento óptico. Si el procesamiento óptico ya se ha ejecutado y la licencia incluye la lectura del chip, el SDK puede utilizar la clave de acceso obtenida durante ese paso óptico.

Document Reader SDK también admite procesos con licencias de conducir móviles (mDL) y credenciales digitales de viaje (DTC). Estos tipos de credenciales requieren una planificación específica porque no son simples fotografías de una tarjeta física.

Document Reader SDK Mobile también incluye fijación de certificados (certificate pinning), prevención de capturas de pantalla y comprobaciones de integridad del proceso de captura. Estos ajustes son opcionales, pero resultan valiosos en banca, telecomunicaciones, viajes, verificación de personal y otros procesos que manejan datos personales confidenciales.

La diferencia entre dispositivos móviles y web es más evidente en Document Reader SDK que en Face SDK, aunque no debe plantearse como una simple competencia entre dos canales. La versión web puede integrarse en una página de onboarding y funciona bien tanto en navegadores de escritorio como en navegadores de smartphones. La versión móvil, por su parte, es la opción adecuada cuando la empresa ya dispone de una aplicación o desea crear un proceso de verificación nativo personalizado.

La versión móvil se convierte en la mejor opción cuando el proceso necesita acceder a capacidades del dispositivo que los navegadores no pueden ofrecer por completo. La lectura de chips RFID mediante NFC es el ejemplo más claro; si la política exige datos del chip, una aplicación nativa para iOS o Android suele ser la solución práctica.

La versión móvil también es preferible cuando el producto necesita un mayor control de las condiciones de captura y una protección más sólida contra ataques de inyección. Una aplicación nativa proporciona al equipo un mayor control sobre el proceso de captura, los permisos del dispositivo y los ajustes de seguridad a nivel de aplicación, lo que puede resultar valioso en procesos de mayor riesgo donde las imágenes de documentos, la entrada de la cámara o los datos de la sesión pueden ser objetivos de intentos de fraude.

La versión móvil resulta especialmente relevante cuando el proceso requiere:

• Lectura de chips RFID mediante NFC
• Verificación recurrente de documentos dentro de una aplicación instalada
• Mayor control del entorno de captura
• Protección más sólida contra ataques de inyección
• Ajustes de seguridad a nivel de aplicación
• Un proceso de usuario personalizado vinculado a un producto móvil existente

La versión web suele ser la mejor opción cuando el usuario necesita completar una verificación puntual o con pocas fricciones. El proceso de captura de documentos puede integrarse directamente en una página web de onboarding, lo que evita instalar una aplicación y facilita el proceso a los usuarios nuevos.

Esto funciona bien para el onboarding de clientes, los procesos de prueba, el registro de visitantes, la recuperación de cuentas o cualquier proceso en el que solicitar al usuario que instale una aplicación genere fricciones innecesarias. La versión web también puede funcionar bien en smartphones, por lo que la cuestión no es “web de escritorio frente a teléfono móvil”, sino si la empresa necesita una aplicación instalada o un paso basado en el navegador.

Un proceso basado en el navegador funciona mejor cuando el proyecto necesita:

• Acceso rápido mediante una página de onboarding
• No requerir la instalación de una aplicación
• Captura de documentos en navegadores de escritorio o smartphones
• Procesamiento en el backend después de la captura
• Un paso de verificación puntual que requiera un compromiso mínimo del usuario

Una vez verificado el documento, la siguiente pregunta es si la persona que lo presenta es su titular legítimo. Face SDK captura una selfie, comprueba que la persona esté viva, evalúa la calidad de la imagen facial y puede comparar la selfie con una foto del titular extraída del documento o del chip RFID.

La mayoría de los procesos regulados utilizan Face SDK junto con Face SDK Web Service, de modo que la prueba de vida, la comprobación de los rostros, el registro de auditoría y las decisiones sobre políticas permanecen bajo el control del backend. Cuando la aplicación necesita realizar una comparación 1:1 local, las versiones nativas para iOS y Android pueden incorporar el framework Match y comparar dos imágenes faciales en el dispositivo.

Antes de realizar la comparación, es necesario controlar la calidad de la imagen facial de entrada. La detección facial puede procesar uno o varios rostros, y los ajustes de identificación permiten definir cuántos rostros se procesan. Esto ayuda a los equipos de onboarding a evitar problemas de privacidad y de toma de decisiones provocados por la presencia de rostros en segundo plano.

La evaluación de atributos faciales puede proporcionar características como la edad, las emociones, los lentes, las mascarillas médicas y los elementos que cubren la cabeza. En los procesos con restricciones de edad, la edad estimada funciona mejor como un factor de evaluación inicial que como sustituto de la verificación de edad basada en documentos.

La evaluación de la calidad de la imagen facial comprueba si una fotografía cumple condiciones de calidad alineadas con los estándares de fotografías de identidad. Utiliza parámetros configurables que abarcan el tamaño y la posición de la cabeza, la postura, la expresión, las obstrucciones del rostro y los objetos inadecuados.

Face Capture abre la interfaz de la cámara y captura una imagen facial adecuada. La prueba de vida puede ejecutarse en modalidad activa o pasiva. La prueba de vida activa solicita al usuario que gire la cabeza y alinee la posición del rostro, mientras que la modalidad pasiva se asemeja más a tomarse una selfie. La modalidad activa es la predeterminada, y la pasiva puede habilitarse mediante la configuración.

El modelo de servicio en línea resulta adecuado para los programas KYC regulados porque la prueba de vida, la comprobación de los rostros, el registro de auditoría y las reglas de las políticas pueden permanecer bajo el control del backend. Cuando la comparación 1:1 debe funcionar con una conectividad deficiente o durante una breve interrupción del servicio, el framework Match puede comparar rostros sin enviar una imagen al servidor.

La diferencia entre dispositivos móviles y web es mucho menor para Face SDK que para Document Reader SDK. En ambos casos, el usuario puede recibir instrucciones para realizar la captura facial y la prueba de vida con una experiencia muy similar.

La elección del canal depende del modelo de implementación: aplicación instalada o enlace del navegador, proceso exclusivamente en línea o comparación local 1:1, riesgo estándar o protección más sólida contra ataques de inyección y deepfakes.

Face SDK para dispositivos móviles suele ser la mejor opción cuando la verificación facial forma parte de un proceso de identidad integrado en una aplicación. Esto es habitual en banca, fintech, telecomunicaciones, gestión de personal, plataformas de trabajo independiente y otros productos en los que los usuarios ya tienen instalada una aplicación y pueden necesitar verificar su identidad más de una vez.

También es una mejor opción cuando se requiere una comparación 1:1 local. Con el framework Match, las integraciones nativas para iOS y Android pueden comparar rostros directamente en el dispositivo, lo que puede resultar útil para el trabajo de campo, instalaciones similares a quioscos o situaciones en las que una breve interrupción de la red no debería detener la sesión de verificación.

La exposición al fraude también puede llevar a optar por la versión móvil, especialmente cuando la aplicación se utiliza para autenticaciones recurrentes o acciones de alto riesgo en cuentas y necesita una protección más sólida contra ataques de inyección o intentos con deepfakes. En estos casos, el código móvil nativo proporciona a los equipos un mayor control sobre el proceso de captura y las comprobaciones de seguridad que lo rodean.

Face SDK Web es una mejor opción cuando el usuario necesita completar una acción puntual con la menor fricción posible. Un proceso basado en el navegador funciona bien para enlaces de invitación, onboarding ocasional, recuperación de cuentas, comprobaciones puntuales o situaciones en las que solicitar al usuario que instale una aplicación sería excesivo para el nivel de riesgo.

El usuario puede abrir el enlace, completar la captura facial y la prueba de vida, y continuar sin añadir otra aplicación al dispositivo. Esto hace que la versión web resulte especialmente útil cuando la conversión y el acceso rápido tienen mayor prioridad que la comparación sin conexión o los controles a nivel de aplicación.

El fraude suele dirigirse al punto más débil de un proceso: un documento falsificado puede superar un OCR básico, un documento auténtico robado puede superar la extracción de texto y un ataque con video grabado puede superar una captura de selfie que carezca de prueba de vida. La versión móvil funciona mejor cuando las comprobaciones documentales y biométricas se validan mutuamente.

Un proceso móvil habitual es el siguiente:

1. Document Reader SDK escanea el documento, extrae los datos, comprueba la calidad de la imagen y ejecuta las omprobaciones de autenticidad compatibles con el escenario y la base de datos seleccionados.

2. Si el documento tiene un chip RFID y la política de riesgos lo requiere, la aplicación inicia la lectura del chip, valida sus datos, ejecuta las comprobaciones de autenticación y extrae la foto del titular almacenada en el chip.

3. Face SDK captura la selfie, ejecuta la prueba de vida y compara la selfie con la foto del titular del documento.

4. La aplicación o el backend almacena los resultados necesarios para auditorías, soporte y revisiones de cumplimiento normativo.

El valor reside en decidir dónde se necesitan evidencias más sólidas, en lugar de añadir comprobaciones sin un propósito concreto: comprobaciones visuales de documentos para usuarios de menor riesgo, lectura de chips RFID para procesos de mayor riesgo, prueba de vida pasiva cuando la prioridad es evitar fricciones, prueba de vida activa cuando el riesgo de suplantación es mayor y reprocesamiento en el backend cuando la auditabilidad forma parte de la política.

Si los usuarios ya utilizan una aplicación, la versión móvil ofrece herramientas que la web no puede igualar por completo: lectura de chips NFC, procesamiento de documentos sin conexión, mayor control de la captura, ajustes de seguridad a nivel de aplicación y, en integraciones nativas para iOS y Android, comprobación de los rostros 1:1 del lado del cliente. La versión web sigue siendo útil cuando la prioridad es ofrecer acceso inmediato, pero la versión móvil es más adecuada cuando la verificación es recurrente, está regulada o está vinculada a chips de documentos electrónicos y evidencias biométricas.

Cuando Document Reader SDK y Face SDK se utilizan conjuntamente, proporcionan una defensa confiable contra el fraude de identidad y ayudan a verificar que los clientes sean quienes afirman ser.

Document Reader SDK procesa imágenes de documentos, verifica la presencia del documento, identifica su tipo, extrae los datos necesarios, los valida de forma cruzada y comprueba si el documento es auténtico mediante una amplia variedad de comprobaciones de autenticidad. También realiza comprobaciones liveness de documentos que abarcan los principales elementos de seguridad dinámicos, incluidos hologramas, tintas ópticamente variables (OVI), imágenes láser múltiples (MLI) y Dynaprint®.

Al mismo tiempo, Face SDK realiza reconocimiento facial mediante procesos pasivos y activos y ayuda a prevenir ataques de presentación fraudulentos, como imágenes faciales estáticas, fotografías impresas, intentos con videos grabados, inyecciones de video o máscaras. La solución puede realizar tanto comprobación de los rostros 1:1, comparando la imagen facial en vivo del usuario con la foto del documento de identidad, como reconocimiento facial 1:N, comparando los datos faciales del usuario con una base de datos.

¿Le interesa ver los SDK en acción? Hablemos.