Esta página reúne las funciones que usamos a diario para auditar liveness en procesos de registro remoto: desde la primera captura hasta el informe que se entrega al equipo de cumplimiento. No es un catálogo de producto; es la lista de trabajo con la que un analista de e-KYC decide si una sesión aguanta una revisión posterior.
Revisamos bordes de mandíbula, parpadeo asincrónico, sombras que no siguen la fuente de luz y micro-temblores que un avatar generativo suele repetir de forma idéntica entre frames. En sesiones de apertura de cuenta en mercados con alta presión regulatoria, ese patrón se detecta antes de que el inversor complete el formulario fiscal.
Cruzamos la geometría facial de la captura con la fotografía del pasaporte o DNI, pero también con metadatos de la sesión: hora del dispositivo, resolución de cámara, si hubo cambio de red a mitad del proceso. Una máscara 3D bien construida puede engañar al ojo humano y fallar en este cruce.
Anotamos cuántas veces el usuario repitió la prueba, con qué dispositivo y en qué franja horaria. Los reintentos múltiples en pocos minutos suelen indicar ensayo previo con herramientas de sustitución facial, algo relevante cuando el bróker opera con cuentas de inversión en mercados de EE. UU. o la UE.
Entregamos un resumen con marcas de tiempo, capturas de referencia y una clasificación del riesgo. El área de compliance del bróker decide si aprueba, escala o rechaza la apertura. Sin este paso, cualquier veredicto automático queda sin trazabilidad y no sirve ante una auditoría posterior.
Cuando la sesión queda en zona gris, la marcamos y volvemos a revisarla con otro analista. Documentamos qué cambió entre la primera y la segunda lectura, y dejamos constancia de la decisión final. Es la parte menos vistosa del trabajo y la que más veces evita un alta fraudulenta.
Si querés ver cómo aplicamos este flujo en un caso concreto, revisá nuestro enfoque de análisis o escribinos desde la página de contacto.
Lo que cambia cuando la verificación de liveness se diseña para mesas de apertura de cuentas, no para demos de laboratorio.
El sistema revisa si el flujo de cámara llega manipulado desde el origen: capas virtuales, cámaras emuladas o streams precargados. Si el feed no proviene del sensor físico del dispositivo, la sesión no avanza y queda registrada con el motivo técnico.
Microgestos, seguimiento ocular y variaciones de iluminación en tiempo real. Un avatar generado puede imitar una selfie, pero no sostiene la coherencia entre parpadeo, reflejo pupilar y respuesta al estímulo durante toda la captura.
Cada intento de apertura deja trazas con marca temporal, resultado del análisis y señales de riesgo detectadas. Útil cuando un regulador o un auditor interno pide explicar por qué se rechazó una solicitud concreta.
El reto se ajusta al perfil y al canal: no es lo mismo abrir cuenta desde un móvil en Buenos Aires que desde una terminal en Fráncfort. Menos pasos innecesarios para el cliente legítimo, más barreras para el intento automatizado.
Se integra sobre SDKs de captura existentes y APIs de onboarding. No obliga a reemplazar el proveedor de identidad ni el core bancario: se suma como capa de verificación antes de la firma del contrato.
Un bróker que opera con clientes internacionales no puede permitirse dos errores opuestos: rechazar a un inversor legítimo por una verificación torpe, o aceptar una cuenta abierta con un rostro generado. Los puntos anteriores atacan ambos extremos. Si querés ver cómo se aplica esto en un caso concreto de onboarding, revisá el análisis de preparación previa a una primera consulta o el desglose de cómo elegir el formato de verificación según el mercado.