¿Qué modo de integración de Shufti es el adecuado para tu pila tecnológica? Explicación de la API, el SDK y el cliente web.

Según el informe "Estado de las API 2024" de Postman, el 43 % de los desarrolladores identifica la integración de API como la tarea de desarrollo que más tiempo consume. Para los equipos que añaden verificación de identidad a un producto regulado, una integración incorrecta no solo ralentiza la entrega, sino que también crea brechas de cumplimiento que resultan costosas de solucionar posteriormente.

Shufti ofrece cinco modos de integración distintos, cada uno diseñado para una combinación diferente de requisitos técnicos, limitaciones de implementación y plazos de lanzamiento. Esta guía relaciona cada modo con el escenario en el que mejor se adapta, para que su equipo pueda tomar la decisión una sola vez y lanzar el producto.

¿Por qué el binario del SDK o la API no cumple su función?

La mayoría del contenido sobre verificación de identidad dirigido a desarrolladores plantea la decisión de integración como una cuestión binaria: SDK o API. Este enfoque ignora otros tres modos que existen precisamente porque no todos los productos son servicios de backend y no todos los equipos disponen de semanas de tiempo para el desarrollo.

La arquitectura de integración de Shufti se basa en la distribución real de productos que requieren verificación: aplicaciones móviles nativas, flujos de incorporación web, plataformas de cumplimiento sin código e implementaciones empresariales con requisitos de soberanía de datos. Cada modo se adapta a uno de estos contextos. La API RESTful no es intrínsecamente mejor que el cliente web; es más adecuada para un tipo específico de equipo que desarrolla un tipo específico de producto.

Los cinco modos de integración de Shufti

1. API RESTful

La API RESTful de Shufti le brinda a su backend control total sobre el flujo de trabajo de verificación. Su servidor envía una solicitud de verificación, Shufti la procesa y los resultados se devuelven de forma asíncrona a través de webhooks (cargas útiles HTTP POST entregadas a su punto final una vez que se completa la verificación). El mismo punto final de la API cubre todos los productos de Shufti: verificación de documentos, comparación facial, AML screening, KYB y más.

Utilice esta opción cuando necesite verificación de servidor a servidor, procesamiento por lotes o una estrecha integración con su capa de orquestación existente. Los ingenieros de backend en empresas de tecnología financiera y servicios financieros suelen elegir esta opción cuando la lógica de verificación debe ubicarse dentro de su propia gestión del ciclo de vida del usuario, en lugar de en el lado del cliente. La complejidad técnica es la mayor de las cinco modalidades, pero también lo es el grado de control. Más del 83 % de las cargas de trabajo empresariales dependen de las API para la comunicación y automatización de datos.y la API de Shufti está diseñada para integrarse en esa infraestructura desde el primer día.

2. SDKs móviles

Kits de desarrollo de software (SDK) móviles de Shufti Están disponibles para Android, iOS, Flutter, React Native y Cordova. Gestionan la captura de documentos, la detección de vitalidad y la biometría facial directamente en el dispositivo, y envían los resultados procesados ​​al sistema de verificación de Shufti.

Utilice esto cuando: esté creando una aplicación móvil nativa y la calidad de la captura biométrica sea una prioridad. Los SDK móviles acceden directamente al flujo de la cámara del dispositivo, lo que significa que pueden detectar ataques de inyección y presentación de la cámara a un nivel que los canales basados ​​en el navegador no pueden igualar. Esto se alinea con los principios de garantía del autenticador en Norma NIST SP 800-63Bque reconocen el acceso nativo al dispositivo como el canal más seguro para la verificación biométrica. El SDK gestiona la experiencia de usuario de captura; su aplicación gestiona el flujo de la sesión.

3. Cliente web (página de verificación personalizada / iFrame)

El cliente web alojado de Shufti es un flujo de verificación preconfigurado que se integra en una sesión del navegador mediante un iFrame. Shufti Gestiona la interfaz de usuario, la captura de documentos y datos biométricos, y la entrega de resultados. Recibirás una notificación web cuando finalice la verificación, sin necesidad de crear ni mantener la interfaz de usuario de verificación.

Utilice esto cuando: necesite un flujo de incorporación basado en la web y quiera evitar crear y mantener una interfaz de usuario de verificación. Este suele ser el camino más rápido para productos web: la integración lleva días en lugar de semanas, obligaciones de manejo de datos en Artículo 32 del RGPD Shufti se encarga de la gestión y no se requiere la compilación de un SDK móvil. La dificultad técnica es de baja a media.

4. Creador de viajes

Constructor de viajes es el configurador de flujo de verificación sin código de Shufti. Los equipos de cumplimiento y los líderes de operaciones pueden ensamblar flujos de trabajo de verificación de varios pasos (verificación de documentos, comparación facial, AML screening, verificación de direcciones) desde una interfaz visual, sin escribir una sola línea de código.

Utilice esto cuando: necesite implementar o iterar rápidamente en un flujo de verificación y la capacidad de ingeniería sea la limitación, no la viabilidad técnica. También es la opción correcta para equipos que necesitan múltiples flujos específicos del mercado: diferentes países, diferentes tipos de documentos, diferentes listas de vigilancia AML, todos configurables de forma independiente. Biblioteca Journey Builder Incluye flujos predefinidos que abarcan más de 30 mercados. Tiempo de puesta en marcha: de horas a un día para la primera implementación.

5. En las instalaciones

La implementación local de Shufti ejecuta toda la pila de verificación dentro de su propia infraestructura. Ningún dato de verificación sale de su entorno. Se aplica la misma interfaz API RESTful y usted conserva el control total sobre la capa de procesamiento, la residencia de datos y el registro de auditoría.

Utilice esta opción cuando: la soberanía de los datos sea un requisito indispensable. Los bancos e instituciones financieras en jurisdicciones con estrictas normativas de residencia de datos, o las empresas sujetas a marcos sectoriales que restringen la transferencia de datos en la nube, utilizan esta vía. El tiempo de puesta en marcha es el más prolongado de los cinco modos, pero el nivel de seguridad también es el más alto: se elimina por completo la exposición de datos en la nube.

Elegir el modo adecuado: un marco práctico

Dos preguntas reducen rápidamente las opciones.

• Primero, ¿dónde se aloja su producto? Las aplicaciones móviles nativas utilizan el SDK móvil. Los productos web utilizan por defecto el cliente web o la API RESTful. Los equipos sin personal de ingeniería pueden empezar con Journey Builder. Las empresas reguladas con requisitos de residencia de datos necesitan la solución local (On-Premises).
• Segundo, ¿de cuánto tiempo de ingeniería dispone? Si el plazo se mide en horas, Journey Builder es la opción más realista. De días a una semana: cliente web o API. De una a dos semanas: API o SDK móvil. Implementación empresarial sin plazos definidos: en las instalaciones.

Los equipos que integran KYC en un producto financiero suelen comenzar con el cliente web para lograr una puesta en marcha conforme a la normativa más rápida, y luego migran a la API una vez que se ha demostrado el flujo de trabajo principal. Una guía más amplia para planificar ese ciclo de vida está disponible en Integración KYC Estrategias para una incorporación fluida y que cumpla con la normativa.

Utilizar varios modos a la vez

Es común y está previsto desde el punto de vista arquitectónico utilizar más de un modo de integración de Shufti en un mismo producto. Una aplicación de servicios financieros podría ejecutar el cliente web para la incorporación de usuarios a través del navegador, el SDK móvil dentro de su aplicación nativa y la API RESTful para la verificación de cumplimiento normativo en segundo plano, conectándose los tres a la misma plataforma, panel de control y datos de cumplimiento. Para obtener una visión más detallada de cómo funciona la capa de API dentro de un contexto más amplio, consulte la documentación correspondiente. servicios de verificación de identidad pila, ver API KYCQué es, cómo funciona, integración y casos de uso.