Imagine, por un momento, que un equipo de prevención del fraude detecta un nuevo ataque un lunes. La regla que lo detiene llega a producción una semana después, a veces dos, y durante todo ese tiempo el atacante se ha dedicado a dar de alta cuentas o a vaciarlas. La explicación habitual de esos días perdidos es el traspaso al equipo de ingeniería: el analista que diseña la solución se la entrega a otro equipo responsable de producción, la solución queda en una cola detrás de otras tareas y cada traspaso de la cadena añade más tiempo.
Creímos en ese diagnóstico, y en parte es acertado, así que dedicamos años a eliminar de nuestra plataforma ese traspaso entre equipos. Los analistas crean e implementan reglas directamente desde el panel de control, sin necesidad de abrir un ticket. Los modelos se implementan mediante un proceso automatizado, y ambos flujos incorporan pruebas, por lo que un cambio que antes esperaba días hasta que se abriera una ventana de implementación ahora puede entrar en producción en cuestión de minutos.
Ese trabajo dio sus frutos, y volvería a hacer la misma inversión. Los despliegues que antes tardaban días ahora se completan en minutos, y es la parte de la infraestructura cuyos efectos perciben primero los clientes. Ese trabajo también puso al descubierto la limitación subyacente: una vez eliminada la transferencia entre equipos, el tiempo transcurrido desde la detección de un ataque hasta la puesta en producción de una solución seguía midiéndose en días, lo que significaba que, para empezar, la mayor parte de ese tiempo nunca se había debido a dicha transferencia. Solo pudimos verlo cuando eliminamos el cuello de botella conocido.
En qué se emplea el tiempo durante el ciclo de respuesta al fraude
Nos llevó un tiempo verlo con claridad, en parte porque el cuello de botella se encuentra entre dos funciones, no dentro de ninguna de ellas. Una investigación genera una teoría sobre un ataque. Las pruebas convierten esa teoría en un control que se puede implementar. El punto de conexión entre ambas, donde hay que contrastar una teoría con los datos reales antes de que alguien esté dispuesto a implementarla, consumía la mayor parte del tiempo.
En ese punto de conexión surgen varios problemas distintos, y vale la pena analizarlos por separado, porque cada uno se resiste a un tipo de automatización diferente.
¿Se llegaron a recopilar los datos de las señales de fraude?
La primera parte del tiempo se dedica a confirmar que los datos existen. Un analista quiere comprobar si una determinada señal del dispositivo permite distinguir el ataque del tráfico normal, pero, antes de poder realizar cualquier prueba, alguien tiene que explicar por qué ese campo está vacío en un tercio de los eventos. ¿Llegó a recopilarse para este segmento de tráfico? ¿Dejó de activarse en algún momento una integración con un proveedor sin que nadie se diera cuenta? O quizá se trate de algo más prosaico: el campo solo se rellena para los clientes que utilizan una versión más reciente del SDK, por lo que la regla no puede detectar a la mitad de la población afectada.
Esas preguntas parecen básicas. Para responderlas, hay que saber cómo se genera cada campo, lo que en la mayoría de las organizaciones implica localizar a una de las pocas personas que tienen ese conocimiento en la cabeza. Ninguna de las automatizaciones de despliegue que creamos abarca este trabajo, porque se lleva a cabo mucho antes de que haya algo que desplegar.
El problema de las etiquetas de fraude
El segundo bloque se destina a las etiquetas, y en el ámbito del fraude estas son un auténtico caos, de formas que quienes no pertenecen al sector suelen subestimar.
Un contracargo puede tardar semanas en llegar. Es posible que una denuncia por estafa nunca llegue a presentarse, ya que depende de que un comercio, un banco asociado o la víctima detecten algo y se tomen la molestia de denunciarlo. Además, tus propios controles sesgan el registro: las transacciones que bloqueaste, es decir, tus decisiones de mayor confianza, no generan ningún tipo de información de retorno, porque un pago bloqueado no produce ningún resultado del que aprender.
Así que, antes de que un analista pueda evaluar una regla propuesta, tiene que dedicar bastante tiempo a determinar qué constituye realmente la verdad de referencia para este ataque. La prueba retrospectiva tarda una hora. Decidir si confiar en ella lleva días.
Fuga de información en el backtesting de fraude
El modo de fallo que más me preocupa es la filtración de información: una regla o un modelo que funciona bien en las pruebas retrospectivas porque la información sobre el resultado se filtró en la evaluación, pero que luego se viene abajo en producción. A veces, una característica solo existía a posteriori. Otras veces, la ventana de etiquetado se solapa con la ventana de evaluación de una forma que nadie detectó.
Lo peligroso es la rapidez con la que ocurre. La regla supera la revisión, se implementa y empieza a tomar decisiones automatizadas de inmediato, por lo que un fallo que un proceso manual habría sacado a la luz poco a poco acaba agravándose en cuestión de horas. Hemos visto casos en los que revertir el daño llevó más tiempo que hacer frente al ataque original.
Detectar esto antes del despliegue requiere una infraestructura de diagnóstico y una buena dosis de paranoia. Ambos costes recaen en esa misma zona intermedia entre la investigación y las pruebas.
Qué significa esto si estás comprando agentes de IA para operaciones antifraude
La mayoría de las herramientas de IA agéntica para la prevención del fraude se promocionan por su rapidez, pero esa rapidez suele concentrarse en los extremos del ciclo: una creación de reglas más rápida y un despliegue más ágil. Si tu motor de reglas es competente, esas partes ya eran rápidas, que era precisamente nuestro caso.
Las mejoras que realmente hemos observado provienen de dirigir los agentes hacia las fases intermedias, y eso solo funciona cuando existe la infraestructura subyacente necesaria:
- Vinculación de entidades, que en la práctica implica disponer de capacidades de grafos, para que un agente que delimita una red de fraude pueda recorrer las conexiones en lugar de intentar adivinarlas
- Modelos de datos organizados subyacentes, porque un agente no puede combinar datos fragmentados de forma más fiable que un analista
- Etiquetas con procedencia conocida, para que la evaluación de una regla se base en datos verificados que estarías dispuesto a defender
- Contexto asociado a cada señal: qué genera el campo y cuándo deja de ser fiable
Sin ese trabajo previo, un agente genera conclusiones a la velocidad de una máquina, con los mismos puntos ciegos que tenían sus analistas.
Hay un principio que nos ha sacado de apuros una y otra vez: todo lo que construimos para los agentes debe poder ser utilizado también por una persona a través de la misma interfaz. Pasamos años desarrollando herramientas de investigación para personas antes de ponerlas a disposición de los agentes, y las lecciones de aquella etapa —dónde fallan los datos y qué conexiones entre entidades inducen a error— están integradas en las herramientas que ahora utilizan los agentes.
Evalúa tu propio ciclo de implementación de reglas antifraude
Chen ha escrito en este blog sobre el ciclo de reacción —el tiempo que transcurre desde que se detecta una carencia hasta que se implementa una solución— como la métrica que un equipo antifraude debería vigilar. Desde el punto de vista de la ingeniería, añadiría algo: al analizar en qué se ha invertido el tiempo durante los últimos incidentes, probablemente se descubra que la causa está en una fase que nadie ha estado optimizando. En nuestro caso, era el punto de conexión entre la investigación y las pruebas, y eliminar todos los obstáculos posteriores fue lo que permitió hacerlo visible.
¿Qué es la implementación de reglas antifraude y por qué es importante para los equipos de prevención del fraude?
El despliegue de reglas antifraude es el proceso de llevar un control de fraude —ya sea una regla, un modelo o un ajuste de umbral— desde la investigación, pasando por las pruebas, hasta su puesta en producción. Es importante porque el tiempo que transcurre entre la detección de un ataque y la implementación de una solución determina cuánto daño puede causar una red de fraude durante el intervalo entre la detección y la respuesta. Un proceso de despliegue de reglas antifraude más rápido y fiable reduce directamente esa exposición.
¿Qué es la filtración de información en el backtesting de fraude y por qué es peligrosa?
La fuga de información en las pruebas retrospectivas de fraude se produce cuando datos sobre el resultado de un evento fraudulento se filtran en la evaluación de una regla o un modelo propuestos, haciendo que parezcan funcionar mejor de lo que lo harán en producción. Es especialmente peligrosa porque una regla que supera la revisión debido a esta fuga se implementa y empieza a tomar decisiones automatizadas de inmediato, lo que significa que un defecto que un proceso manual revelaría lentamente puede agravarse en cuestión de horas. Detectar estas fugas requiere una infraestructura de diagnóstico antes de la implementación, no después.
¿Cuál es el problema del etiquetado de fraude?
Las etiquetas de fraude son las señales de referencia que indican a un modelo o una regla si un evento pasado fue fraudulento. El problema es que, en el ámbito del fraude, estas etiquetas suelen ser incompletas, tardías o estar sesgadas por la falta de observaciones. Los contracargos tardan semanas en llegar. Es posible que las denuncias de estafas nunca aparezcan. Además, las transacciones bloqueadas por las reglas antifraude no generan información sobre el resultado, porque un pago bloqueado no aporta nada de lo que aprender. Antes de poder confiar en una prueba retrospectiva, un analista debe dedicar bastante tiempo a determinar cómo es realmente la referencia para ese ataque concreto, lo que puede llevar días aunque la propia prueba solo tarde una hora.
¿Qué implica en la práctica la recopilación de datos sobre señales de fraude?
La captura de datos de señales de fraude se refiere a si las señales del dispositivo, de comportamiento o de red que un analista desea utilizar en una regla se recopilaron realmente para la población evaluada. Un campo que aparece en el modelo de datos puede estar vacío para un subconjunto de eventos porque una integración con un proveedor dejó de activarse, una diferencia entre versiones del SDK provocó una recopilación inconsistente o la señal nunca se recopiló para un segmento de tráfico concreto. Confirmar esto requiere conocer cómo se genera cada campo, un conocimiento que, en la mayoría de las organizaciones, está en manos de un reducido número de personas en lugar de estar documentado.
¿En qué áreas ayudan realmente los agentes de IA en las operaciones contra el fraude?
Los agentes de IA para operaciones antifraude suelen promocionarse por la velocidad que aportan en los extremos del ciclo de despliegue de reglas de fraude, concretamente por permitir redactar reglas y desplegarlas con mayor rapidez. Si el motor de reglas ya es eficaz, esos extremos ya eran rápidos. Las mejoras que realmente importan se obtienen al dirigir los agentes hacia la parte central del ciclo: vinculación de entidades para rastrear redes de fraude, modelos de datos estructurados que los agentes puedan consultar de forma fiable, etiquetas de fraude con una procedencia conocida y contexto asociado a cada señal que explique qué la genera y cuándo deja de ser fiable. Sin ese trabajo previo, un agente genera conclusiones a la velocidad de una máquina, pero con los mismos puntos ciegos que tendría un analista humano.
¿Cómo deben medir los equipos antifraude el rendimiento de la implementación de sus reglas de fraude?
Haz un seguimiento de todo el ciclo de respuesta al fraude, desde el momento en que se detecta un ataque hasta que la solución está operativa en producción. Después, analiza en qué se ha invertido el tiempo durante los últimos incidentes. La respuesta suele estar en una etapa que nadie ha estado optimizando activamente. Entre las causas habituales se encuentran las deficiencias en la captura de datos de señales de fraude, los problemas de calidad en el etiquetado del fraude y las comprobaciones para evitar fugas de información en las pruebas retrospectivas de fraude; todas ellas se producen antes del propio despliegue. Eliminar el cuello de botella conocido, ya sea el traspaso al equipo de ingeniería o el proceso de despliegue, suele ser lo que permite detectar por primera vez el verdadero cuello de botella en la detección del fraude.
¿Cuál es el cuello de botella en la detección de fraude que la mayoría de los equipos pasa por alto?
La mayoría de los equipos antifraude asumen que el cuello de botella en la detección del fraude es el traspaso al equipo de ingeniería, cuando un analista entrega una solución propuesta a otro equipo responsable del entorno de producción. Eliminar ese traspaso permitiendo que los analistas implementen directamente las reglas es valioso, pero a menudo deja al descubierto un cuello de botella más profundo: la conexión entre la investigación y las pruebas. Esta conexión abarca la verificación de la captura de datos de señales de fraude, la resolución del problema del etiquetado del fraude y el diagnóstico de la filtración de información en las pruebas retrospectivas de fraude antes de poner en producción cualquier regla antifraude automatizada. Estos problemas se encuentran entre dos funciones, en lugar de pertenecer a una de ellas, por lo que suelen ser los que más tardan en optimizarse.
