Defensa contextualizada: por qué gastar más en ciberseguridad no reduce el fraude (Parte 1)
Invertimos cada vez más en ciberseguridad, pero el fraude sigue creciendo. El problema no siempre está en la tecnología, sino en cómo se relacionan las distintas señales que ya utilizan las entidades para tomar decisiones. La defensa contextualizada, basada en un enfoque de autenticación contextual, propone conectar identidad, biometría, comportamiento, dispositivo, canal y contexto para detectar patrones que hoy permanecen ocultos.
La defensa contextualizada parte de un principio básico: ninguna señal de riesgo debería interpretarse de forma aislada. La autenticación contextual consiste precisamente en eso, en analizar conjuntamente identidad, biometría, comportamiento, dispositivo, canal y contexto de la operación para tomar decisiones con una visión completa y no fragmentada.
Este es el primero de dos artículos en los que quiero profundizar en un concepto que considero clave para la evolución de la prevención del fraude: la defensa contextualizada
Hay un dato que aparece cada vez con más frecuencia en las conversaciones entre responsables de riesgo, fraude y tecnología: nueve de cada diez organizaciones han incrementado su inversión en ciberseguridad durante los últimos años; sin embargo, siete de cada diez siguen registrando pérdidas por fraude. Son cifras reflejadas por Gartner en sus análisis sobre gasto en seguridad de la información y detección del fraude (Information Security Spending & Fraud Detection Research), que ponen de manifiesto una realidad difícil de ignorar
La reacción más habitual es pensar que todavía hace falta invertir más. Sin embargo, esa conclusión deja fuera una cuestión importante.
Las soluciones tecnológicas han evolucionado enormemente y, en general, cumplen bien la función para la que fueron diseñadas. El problema aparece cuando cada una analiza únicamente la parte del proceso que le corresponde y ninguna dispone de una visión completa de la identidad o de la operación que está evaluando.
| 9/10 | 7/10 |
|
organizaciones han aumentado el gasto en ciberseguridad Fuente: Gartner, 2025 |
siguen teniendo pérdidas por fraude con mayor gasto Fuente: Gartner, 2025 |
| 244.2B$ | 87% |
|
gasto global proyectado en seguridad de la información en 2026 Fuente: Gartner, 2026 |
identifican las vulnerabilidades de IA como el riesgo de mayor crecimiento Fuente: Global Cybersecurity Outlook 2026, WEF/Accenture, enero 2026 |
Cuando analizamos casos de fraude, hay un patrón que se repite con frecuencia: las distintas soluciones implicadas en una operación suelen cumplir correctamente su función, pero sus resultados rara vez se interpretan de forma conjunta.
Por ejemplo:
- La verificación documental confirma que el documento es auténtico.
- La biometría valida que la persona es quien dice ser.
- El motor antifraude considera que la operación entra dentro de los parámetros habituales.
Cada sistema llega a una conclusión correcta desde su propio punto de vista. Pero el problema aparece cuando nadie relaciona esas conclusiones. La autenticidad del documento no influye en cómo se interpreta la biometría, y la información biométrica tampoco aporta contexto al análisis de la transacción. Cada decisión se toma de forma independiente.
El resultado es un conjunto de tecnologías eficaces que, sin embargo, dejan escapar patrones que solo se hacen visibles cuando todas las señales se analizan conjuntamente.
No creo que esto sea un fallo de la tecnología ni del trabajo que ha hecho el sector durante los últimos años. Al contrario. Es una consecuencia lógica de cómo se han construido estas arquitecturas: cada solución nació para resolver un problema concreto y pocas fueron diseñadas para compartir contexto con el resto.
Desde I+D llevamos años encontrándonos con ese mismo límite en proyectos desplegados en producción. Cada vez que identificamos uno de esos puntos ciegos acaba convirtiéndose en un nuevo requisito de producto. Es una de las ventajas de trabajar con entidades financieras de perfiles muy distintos y en más de treinta países: los casos cambian, pero los patrones de fondo suelen repetirse.
Por eso creo que el siguiente paso para la industria ya no consiste únicamente en mejorar cada tecnología por separado, sino en conseguir que todas compartan contexto y puedan interpretar el riesgo como un único sistema.
«El fraude no se perpetra por falta de tecnología. Se perpetra a través de las brechas entre capas que no hablan entre sí.»
Qué significa contextualizar una defensa
Cuando hablamos de defensa contextualizada no estamos planteando añadir una nueva solución al stack de seguridad. El reto es conseguir que las tecnologías que ya existen compartan información y ayuden a interpretar una operación de forma conjunta.
Hoy eso ocurre pocas veces.
En la mayoría de las entidades, la verificación documental, la biometría, el análisis transaccional o los sistemas de fraude siguen trabajando sobre conjuntos de datos distintos. Cada uno toma decisiones con la información que tiene disponible y rara vez incorpora lo que ya sabe el resto. Eso limita la capacidad para detectar determinados ataques.
Pensemos en un caso concreto. Un usuario abre una cuenta y supera sin incidencias la verificación documental. Dos semanas después, inicia sesión desde un dispositivo que nunca había usado, en una ciudad distinta a la habitual, y ordena una transferencia a un beneficiario nuevo por un importe muy superior a su patrón de gasto. Por separado, ninguna de esas señales dispara una alerta: cambiar de dispositivo es normal, viajar también, y recibir un beneficiario nuevo ocurre constantemente en operaciones legítimas. Pero las tres juntas, documento verificado hace poco, dispositivo desconocido, beneficiario nuevo con importe atípico, sí describen un patrón que merece revisión.
Ese es el cambio que propone una defensa contextualizada. No consiste en generar más señales, sino en aprovechar mejor las que ya existen.
Antes de diseñar la arquitectura, hay que entender el contexto
Antes de hablar de capacidades técnicas conviene hacerse una pregunta más básica: ¿qué realidad tiene que proteger cada entidad?
No existe un banco igual a otro. Tampoco existen dos entornos de fraude idénticos.
Cada organización arrastra un legado tecnológico diferente, opera bajo marcos regulatorios distintos y trabaja con perfiles de clientes que poco tienen que ver entre sí. A eso se suman factores específicos de cada país: la calidad de las infraestructuras de identidad, el grado de digitalización o incluso incidentes como las filtraciones masivas de bases de datos nacionales, que modifican por completo el escenario de riesgo.
Una entidad con presencia en México, Colombia y Emiratos Árabes Unidos no gestiona un único modelo de fraude, sino tres realidades diferentes. Los vectores de ataque cambian, las restricciones regulatorias también y las señales disponibles para tomar decisiones no siempre son las mismas.
Por eso una defensa contextualizada no puede partir de una configuración estándar. Antes necesita entender el contexto sobre el que va a operar.
Tres capacidades que solo tienen sentido juntas
Si el objetivo es interpretar el riesgo desde una visión completa, hay tres capacidades que deberían funcionar como un único sistema:
1. Historia de identidad continua
Cada punto de contacto con el usuario genera información que hoy muere en el módulo que la produjo. La verificación documental no le habla al motor biométrico. El motor biométrico no le habla al sistema de monitorización transaccional. La defensa contextualizada exige un registro de identidad continuo: no un evento de verificación, sino una señal viva que acumula contexto a lo largo de toda la relación con el cliente.
2. Orquestación basada en el contexto
Acumular información no basta si después no se interpreta correctamente. Una autenticación contextual debe ser capaz de considerar variables como el canal, el país, el dispositivo, el perfil del cliente o los vectores de fraude activos en ese momento para ajustar la evaluación del riesgo.
La misma señal biométrica puede tener implicaciones distintas durante un onboarding móvil en México que en una autenticación presencial en Emiratos Árabes Unidos. El contexto cambia la interpretación de la señal y, por tanto, también la respuesta que debería ofrecer el sistema.
3. Evaluación continua a lo largo del ciclo de vida
El fraude no se anuncia en el onboarding, o no siempre. Se construye durante semanas o meses. Una cuenta puede superar limpiamente el KYC inicial y aun así convertirse en vector de fraude seis meses después.
La defensa contextualizada no cierra el caso en el onboarding sino que mantiene abierta la evaluación del patrón completo durante toda la vida del cliente en la entidad.
De proteger cuentas a proteger el sistema
Hasta ahora hemos hablado de cómo una entidad puede tomar mejores decisiones cuando interpreta las señales de forma conjunta. Pero hay una consecuencia aún más relevante.
El fraude nunca ha sido un problema aislado de un banco. Los atacantes observan el ecosistema completo y buscan dónde tienen más posibilidades de éxito. Si encuentran una entidad con controles más débiles o con menos capacidad para relacionar señales, entrarán por ahí. Esa es una ventaja que hoy sigue estando de su lado.
Una defensa contextualizada también cambia esa lógica. Cuando las entidades son capaces de compartir inteligencia bajo modelos de gobernanza adecuados, los patrones de ataque dejan de quedarse dentro de una única organización. Una señal detectada por una entidad puede ayudar a anticipar un ataque en otra.
El objetivo es hacer que el sistema en su conjunto aprenda más rápido que quien intenta atacarlo.
«El atacante no ataca un banco. Ataca el punto más débil de todo el sistema. Defender puntos aislados es defender de espaldas al problema real.»
¿Por dónde empezar?
Un buen punto de partida consiste en revisar cómo circulan hoy las señales entre las distintas capas del stack de seguridad. En muchas organizaciones, cada sistema sigue trabajando con sus propios datos, sus propios umbrales y su propia lógica de decisión.
Tres preguntas ayudan a identificar rápidamente ese nivel de madurez:
- ¿Las soluciones de identidad, biometría y fraude intercambian información en tiempo real?
- ¿La evaluación del riesgo cambia según el país, el canal o el contexto de la operación?
- ¿La identidad continúa evaluándose después del onboarding o el análisis termina con el KYC?
Si la respuesta sigue siendo negativa en la mayoría de los casos, probablemente el reto no esté en incorporar una herramienta más, sino en construir una arquitectura capaz de conectar las que ya existen.
En la segunda parte de esta serie veremos por qué la medicina de precisión ofrece un marco sorprendentemente útil para entender ese cambio de paradigma y qué puede aprender la industria financiera de un modelo que lleva años utilizando el contexto como principal herramienta de decisión.
Aumentar el gasto no reduce el fraude cuando cada capa del stack trabaja sin saber lo que hacen las demás. El motor de documentos, el módulo biométrico y el sistema antifraude emiten su diagnóstico y cierran el caso, pero ninguno ve el patrón completo. El fraude se cuela por el hueco entre capas, no por falta de tecnología en cada una.
La autenticación contextual verifica la identidad valorando el contexto de cada intento: el dispositivo, la geografía, el canal, el historial del usuario y los ataques activos en ese territorio. El mismo patrón biométrico puede significar cosas distintas en un onboarding móvil en México que en una verificación presencial en UAE. La decisión de riesgo se ajusta a esas variables en tiempo real.
Un stack normal apila productos que deciden por separado: cada uno evalúa el momento presente sin acceso al patrón histórico ni al contexto de las otras capas. Una defensa orquestada mantiene una señal de identidad continua que acumula contexto a lo largo de toda la relación con el cliente, y una capa que pondera esas señales juntas en lugar de tres veredictos sueltos.
El fraude rara vez se anuncia en el alta: se construye durante semanas o meses. Una cuenta que supera limpiamente el KYC inicial —por ejemplo, para recibir después transferencias de origen fraudulento como cuenta mula— puede activarse medio año después. La defensa contextualizada no cierra el caso en el onboarding: mantiene abierta la evaluación del patrón completo durante toda la vida del cliente.
Cada país combina un legado tecnológico, un marco regulatorio y una infraestructura de identidad distintos. Una entidad con presencia en México, Colombia y Emiratos Árabes Unidos no gestiona un único modelo de fraude: gestiona tres realidades con vectores de ataque, restricciones y señales disponibles diferentes. La defensa contextualizada parte de ese diagnóstico antes de definir cualquier arquitectura.