En la página de tiempos de trabajo ya explicamos cómo se ordenan las etapas. Aquí conviene detenerse en algo más incómodo: qué hace distinta a esta defensa frente a las alternativas que ya existen en el mercado, y por qué un equipo de riesgo acepta incorporarla a su stack sin rehacer todo el flujo de verificación.
La mayoría de las soluciones antifraude confían en señales del cliente: sensores, atestación del sistema operativo, huellas del navegador. Cuando el atacante inyecta un video sintético directamente en la llamada al API, esas señales siguen diciendo la verdad y aun así el fraude pasa. Aquí el análisis ocurre en el servidor, sobre el contenido que efectivamente llega al endpoint, sin depender de que el cliente colabore.
No pide tirar el proveedor de KYC actual ni reescribir la lógica de negocio. Se coloca delante del servicio de verificación, evalúa la procedencia del stream y devuelve una decisión clara: continuar, marcar para revisión o bloquear. Los equipos que ya tienen rate limiting, autenticación fuerte y reglas antifraude suman esta pieza sin desarmar lo anterior.
Una apertura de cuenta en banca digital y una validación puntual de identidad no toleran la misma fricción. Los umbrales de detección se calibran por flujo, por geografía y por volumen esperado. En operaciones de alto valor el sistema prefiere derivar a revisión manual antes que arriesgar un falso negativo; en trámites masivos prioriza no bloquear usuarios legítimos con iluminación pobre o redes lentas.
Cada sesión bloqueada o marcada queda con la evidencia que la sustenta: señales observadas, ponderación aplicada y momento exacto de la decisión. Esto importa cuando un cliente reclama, cuando un regulador pregunta o cuando el propio equipo de fraude quiere revisar si el umbral está demasiado agresivo. La trazabilidad no es un extra de cumplimiento, es parte del funcionamiento diario.
El objetivo no es detectar el video sintético perfecto, sino encarecer el ataque hasta volverlo inviable. Un atacante que necesita generar cientos de streams coherentes, con metadatos limpios y respuesta en tiempo real a los estímulos, enfrenta un costo que rara vez justifica el intento. Esa economía del ataque es el criterio real de éxito, más que una tasa de detección aislada.
Si quieres ver cómo se combinan estas capas en una plataforma financiera concreta, revisa las capacidades técnicas o el detalle de los componentes disponibles.
Antes de hablar de plazos conviene fijar el terreno. Estas son las definiciones que usamos cuando un equipo de fraude nos pide una barrera contra video sintético inyectado en el API de KYC, y las condiciones que aplican a cada etapa del proyecto.
Cuando decimos inyección directa hablamos de un stream de video generado que llega al endpoint de verificación sin haber sido capturado por un sensor físico. El atacante controla la petición, no el dispositivo. Por eso las comprobaciones que dependen del cliente, como el acceso a la cámara o la firma del SDK, quedan fuera del alcance real de la defensa. Nuestro trabajo empieza en el servidor, donde el contenido ya es el único dato fiable.
Un video manipulado parte de una captura real y se altera después. Un video sintético se genera desde cero, fotograma a fotograma, con coherencia temporal propia. Ambos son intentos de fraude, pero dejan rastros distintos: el primero conserva ruido de sensor y artefactos de compresión originales, el segundo suele mostrar uniformidad sospechosa entre fotogramas. Los modelos de análisis se entrenan por separado para cada caso.
Una sesión legítima con poca luz, cámara de gama baja o conexión inestable puede parecerse a un stream sintético. No bloqueamos por una sola señal. La decisión se toma ponderando varias capas y, cuando la confianza queda en zona gris, la sesión pasa a revisión manual en lugar de rechazarse automáticamente. Preferimos perder algo de velocidad antes que negar el acceso a un usuario real.
No cubrimos la autenticación del usuario ni la gestión de identidades: eso pertenece al sistema que ya opera la plataforma. Tampoco sustituimos el motor de decisión de fraude existente, sino que le entregamos una señal adicional sobre la procedencia del stream. Si el atacante compromete las credenciales antes de la llamada al API, esa capa debe resolverlo el control de acceso, no el análisis de contenido.
Cada capa de análisis suma milisegundos a la verificación. En una integración típica hablamos de una latencia adicional perceptible solo en pruebas de carga, no en la experiencia del usuario final. Los umbrales se calibran con el equipo de la plataforma durante la fase de ajuste, y quedan documentados para que puedan revisarse si cambia el volumen de tráfico o el perfil de los ataques observados.
Cada fase de este recorrido responde a una pregunta concreta: qué se puede observar en el endpoint, qué se puede validar en el servidor y qué decisiones conviene automatizar antes de bloquear una sesión. El orden no es arbitrario. Primero se instrumenta, después se mide y solo entonces se cierra el paso.
Antes de tocar nada se documenta el recorrido real de una petición de KYC: desde el cliente hasta el servicio de análisis, pasando por pasarelas, colas y almacenamiento temporal. En este punto aparecen los huecos donde un stream puede sustituirse sin que el backend lo note. La salida es un diagrama de puntos de confianza, no un informe comercial.
Se añaden capturas de metadatos del contenedor, coherencia temporal entre fotogramas y respuesta a estímulos en tiempo real. Nada de esto decide por sí solo. La idea es acumular evidencia suficiente para que un video generado deje rastro en al menos dos capas independientes. Los falsos positivos con iluminación pobre o redes lentas se registran desde el primer día.
Con las señales medidas se fijan umbrales por tipo de operación. Una apertura de cuenta no tolera la misma fricción que una consulta de saldo. Aquí se define qué sesiones se rechazan, cuáles pasan a revisión manual y cuáles se aceptan con marca de seguimiento. Las reglas viven en el servidor, no en el cliente, porque el atacante controla el cliente.
Se inyectan videos generados en un entorno aislado para comprobar que la barrera los detecta sin degradar el servicio a usuarios legítimos. Esta fase suele revelar dependencias ocultas: proxies que reescriben cabeceras, SDKs que normalizan el stream antes de enviarlo. Los ajustes se hacen sobre el pipeline real, no sobre un banco de pruebas ideal.
Una vez en producción, el trabajo se traslada a la vigilancia: tasa de bloqueos, motivos de rechazo, tiempo de análisis por sesión y volumen de revisiones manuales. Los modelos generativos cambian, así que los umbrales también. La barrera se revisa con periodicidad fija y con cada incidente relevante que llegue desde fraude.
Los plazos dependen del tamaño del flujo y del número de integraciones externas. En plataformas con varias pasarelas, la fase de mapeo suele ser la más larga; en entornos monolíticos, la instrumentación concentra el esfuerzo. Ninguna etapa se salta, aunque se solapen.