Cada pocos años, una nueva tecnología promete cambiar para siempre la detección del fraude. Por lo general, no lo consigue. Por eso nos tomamos con un sano escepticismo las grandes afirmaciones sobre la IA, incluidas las nuestras.
Entonces llevamos a cabo este experimento.
Tomamos el mismo tipo de modelo en el que se basa ChatGPT, pero, en lugar de entrenarlo con texto, lo entrenamos con transacciones reales con tarjeta. Después, incorporamos lo aprendido al modelo de detección de fraude en la emisión de tarjetas que ya utilizamos en producción.
Ese modelo detectó entre un 24 % y un 35 % más de fraude que antes, manteniendo la misma proporción de transacciones marcadas como de alto riesgo. Y lo hizo sin que se le mostrara en ningún momento cuáles de las transacciones anteriores resultaron ser fraudulentas.
Estos resultados nos entusiasmaron. Sin embargo, desde una perspectiva más realista, conviene señalar algunas salvedades relacionadas con la facilidad con la que podrían obtenerse los mismos resultados en otros casos de uso.
Entrenamiento de un modelo fundacional de pagos
La idea surge directamente de la forma en que aprenden los grandes modelos de lenguaje. Un modelo como ChatGPT procesa enormes cantidades de texto y se entrena con una tarea sencilla: observar las palabras que han aparecido hasta el momento y predecir la siguiente. Al repetir este proceso miles de millones de veces, el modelo desarrolla una comprensión profunda del funcionamiento del lenguaje.
Aplicamos el mismo enfoque a los pagos. El historial de la tarjeta de cada cliente se convierte en una secuencia de transacciones ordenadas cronológicamente. Después, entrenamos el modelo para que analizara las transacciones anteriores de un cliente y predijera la siguiente.
Para ello, el modelo tiene que interpretar una transacción del mismo modo que interpreta una palabra. Así, cada transacción se descompone en sus distintos elementos: quién es el comercio, qué vende, qué importe se transfirió, a través de qué canal se realizó y cuánto tiempo ha pasado desde la última transacción de ese cliente. Al ordenar todos estos elementos, el historial de un cliente se convierte en algo que el modelo puede leer de principio a fin, igual que leería una frase.
Lo que aprende de todo esto es el patrón de gasto de una persona: en qué comercios compra, en qué orden, con qué frecuencia y por qué importe. Al repetir este proceso con millones de transacciones, el modelo desarrolla una visión detallada de lo que es normal para cada cliente.
Cabe señalar que nunca le indicamos al modelo qué transacciones eran fraudulentas. Lo hicimos deliberadamente, porque no queríamos que se centrara directamente en detectar el fraude. Queríamos que aprendiera cómo son los hábitos de gasto habituales de una persona determinada, para que cualquier anomalía destacara por sí sola sobre ese patrón de referencia.
Para cada transacción, el modelo genera dos resultados. El primero es un resumen numérico compacto de todo lo que el cliente ha hecho hasta ese momento, lo que en aprendizaje automático se denomina «embedding». El segundo es una puntuación de «sorpresa»: una medida de lo inesperada que resulta esa transacción concreta teniendo en cuenta el historial del cliente.
También es importante señalar que no sustituimos nuestro modelo de puntuación por una red neuronal. Nuestro modelo de emisión ya puntúa cada transacción mediante árboles de decisión con potenciación del gradiente, creados con XGBoost, y utiliza 77 características que hemos desarrollado a lo largo de los años. Los nuevos embeddings simplemente se añadieron como características adicionales a las 77 existentes y, después, volvimos a entrenar el mismo modelo de XGBoost con el conjunto ampliado.
Los resultados
En todos los umbrales que probamos, añadir los embeddings permitió detectar entre un 24 % y un 35 % más de fraude. En un punto operativo habitual, en el que se marcan para su revisión el 1 % de las transacciones con mayor riesgo, la mejora fue del 28 %.
Al medir simultáneamente todos los umbrales mediante una métrica estándar de clasificación denominada AUC-PR, que premia al modelo por situar los fraudes confirmados en los primeros puestos de la lista, la mejora fue del 68 %.
También comprobamos hasta qué punto el modelo de puntuación utilizaba realmente los embeddings al calcular la puntuación. Al ordenar las características por importancia, los embeddings figuraban entre aquellas en las que más se apoyaba el modelo y representaban más de la mitad de las veinticinco principales.
Sin embargo, la primera versión que desarrollamos obtuvo peores resultados que nuestro modelo existente. Proporcionar a un modelo de árboles de decisión unos cientos de nuevas variables de entrada sin nombre le aporta tanto ruido con el que tropezar como señal, y fue necesario un ajuste considerable para superar ese problema. El modelo final necesitó casi el doble de árboles de decisión que el modelo de referencia para aprovechar lo que le habíamos proporcionado.
El modelo también mejoró a medida que lo entrenamos con datos de más clientes. Entrenarlo con datos de varios clientes dio resultados aproximadamente un tercio mejores que entrenarlo con los de uno solo. Al analizar más transacciones, aprende más sobre el comportamiento general del gasto con tarjeta, y una red compartida permite alcanzar precisamente esa amplitud.
Pero el resultado más sorprendente provino de un cliente que excluimos por completo del conjunto de entrenamiento. Tomamos una cartera cuyos datos nunca se habían utilizado para entrenar el modelo de lenguaje y construimos su modelo de emisión del mismo modo que construimos todos los demás. Los embeddings mejoraron su rendimiento en un 29 %.
El modelo había aprendido algo lo bastante general sobre el gasto con tarjetas como para ayudar a una cartera de la que nunca había visto ni una sola transacción. Curiosamente, la mejora fue mayor en las transacciones que identificaba con más confianza como fraudulentas, es decir, aquellas con más probabilidades de ser rechazadas o bloqueadas.
Ese resultado tiene una ventaja práctica. Como el modelo aprende del historial de transacciones sin procesar, en lugar de basarse en etiquetas de fraude, un nuevo cliente no tiene que esperar meses hasta acumular suficientes casos de fraude confirmados para disponer de un modelo que funcione. El historial de transacciones que necesita el modelo ya existe desde el mismo día en que el cliente se incorpora.
Qué impulsó la mejora del rendimiento
El resultado se debió a la estructura de los datos de emisión y, en particular, a tres aspectos de estos.
La primera es un historial extenso y ordenado. Un titular utiliza la misma tarjeta muchas veces por semana durante años, por lo que el emisor acumula un registro detallado del comportamiento de cada cliente. Más del 90 % de los clientes de nuestra prueba tenían registradas al menos 75 transacciones anteriores. Eso supone una gran cantidad de señales, y el orden de esas transacciones aporta información que un simple total nunca podría ofrecer.
La segunda es la poca información que un emisor ve sobre cada transacción individual. Para cuando la autorización de una tarjeta llega al banco emisor, el comercio y la red ya han eliminado la mayor parte del contexto. El banco no ve el dispositivo, la sesión de pago ni lo que se compró realmente. Solo ve una tarjeta, un importe, una categoría de comercio y una marca de tiempo.
Por eso, nuestro modelo de emisión funcionaba con solo 77 características principales. Había poco margen para crear más a partir de ellas. Y es el mejor caso posible para este enfoque: unas características existentes poco detalladas dejan espacio para que el modelo de lenguaje aporte algo que las anteriores no podían captar.
La tercera razón es que las secuencias se resisten a ser aplanadas, y eso es precisamente lo que hacen las variables tradicionales. Contar las transacciones de los últimos 30 días. Calcular el importe medio. Medir cuánto se desvía esta compra de lo habitual para el cliente. Cada una de estas operaciones selecciona una ventana temporal, y dentro de ella desaparecen el orden y el ritmo.
Este ejemplo ayuda a ilustrar el principio: imagine una tarjeta que se utiliza con una rutina estable entre semana: café cerca de la oficina cada mañana, una compra en el supermercado de camino a casa y gasolina cada dos viernes. Una semana, esa misma tarjeta se utiliza para realizar tres compras de productos electrónicos por internet en una sola hora, en comercios donde nunca antes se había usado y en plena jornada laboral.
Ningún resumen agregado por sí solo va a detectar esto: todos los importes se encuentran dentro del rango habitual del cliente, el recuento de los últimos 30 días parece normal y cada comercio, considerado por separado, no tiene nada de particular. Lo anómalo es la secuencia, el orden de los tipos de comercio y la ruptura de un patrón que el cliente ha mantenido durante meses.
Un modelo de secuencias no necesita elegir una ventana. Analiza todo el historial ordenado y determina por sí mismo qué eventos pasados aportan información sobre el siguiente.
También se ocupa de aspectos que ningún ingeniero de características pensaría en crear. Los nombres de los comercios son poco uniformes. «HARBOR COFFEE #4471» y «Harbor Coffee Co» son la misma tienda para una persona, pero dos cadenas de texto sin relación para un ordenador. Un modelo de secuencias aprende a tratarlos como uno solo porque, en los datos, las compras realizadas en ambos se parecen: importes similares, momentos similares y los mismos tipos de transacciones a su alrededor.
Por supuesto, se puede argumentar que todo lo que produce el modelo fundacional podría, en principio, desarrollarse manualmente. El problema es el coste. Requiere meses de trabajo de personas que entienden tanto de fraude como de datos y que, precisamente, son el recurso más escaso en cualquier equipo de riesgos. Además, las funcionalidades siguen necesitando mantenimiento mucho después de haberse creado.
Dónde esperamos que se quede corto
La conclusión más obvia es que los modelos fundacionales son el futuro de la detección del fraude, no solo en el ámbito de la emisión de tarjetas, sino en un sentido más amplio. Sin embargo, las mismas características que hicieron que funcionaran tan bien en la emisión son las que nos hacen ser cautos con respecto a otros casos de uso.
Hay dos factores que determinan si analizar secuencias resulta útil: cuánto historial se acumula por cuenta y cuánta información aporta cada evento. La emisión de tarjetas es el caso extremo, con un historial extenso y pocos detalles. Sin embargo, otros casos de uso relacionados con el fraude son muy distintos.
Un comercio o un adquirente ve prácticamente lo contrario. Cuando alguien finaliza una compra en un sitio de comercio electrónico, el comercio ve el dispositivo, la sesión, los artículos de la cesta, la dirección de envío y la identidad facilitada al pagar. Estos conjuntos de características ya son amplios y maduros. E incluso si los compradores visitan ese sitio con frecuencia, el promedio no se acerca ni de lejos a 75 veces, por lo que hay muy poco historial que analizar. Dado que cada evento contiene más detalles y hay menos historial por cuenta, creemos que los modelos fundacionales basados en secuencias probablemente no ofrecerían tan buenos resultados en este tipo de casos de uso.
La incorporación de nuevos usuarios y el pago como invitado representan el extremo opuesto. Un único evento, sin ningún historial previo. No hay ninguna secuencia que analizar, por lo que este enfoque no puede aportar nada.
Las billeteras digitales y las aplicaciones de transferencia de dinero se sitúan en un punto intermedio. Las personas realizan transacciones con suficiente frecuencia como para acumular cierto historial, y el proveedor dispone de más información sobre cada operación que un emisor.
Sin embargo, para el caso de uso de emisión, este enfoque funciona muy bien. Los datos sin procesar son escasos y solo permiten obtener un conjunto reducido de características, por lo que añadir un nuevo conjunto amplio de características mejora el rendimiento de forma natural. Cuando los datos sin procesar ya son abundantes y las características existentes ya capturan la mayor parte de la información, esas mismas representaciones vectoriales aportan menos.
De la investigación a la producción
Quedan dos retos por resolver antes de que algo así pueda funcionar en un entorno real y regulado, y son precisamente los que probablemente determinarán dónde puede llegar a implementarse.
El primero es la explicabilidad. Cuando una característica tradicional determina una decisión, se puede identificar: esta transacción se marcó porque el importe era diez veces superior al habitual del cliente. Cuando lo que determina la decisión es la dimensión 192 de una incrustación, no hay nada que identificar.
Pero ese número significa lo que el modelo haya decidido que debe significar, y los humanos no pueden deducir ningún significado de él. En un sector regulado, esa falta de explicación es un obstáculo insalvable.
El segundo es la latencia. Procesar todo el historial de un cliente mediante un modelo fundacional justo en el momento en que una transacción requiere ejecutarse en tiempo real no es una tarea para la que estén optimizados estos modelos. El enfoque habitual consiste en calcular las representaciones vectoriales de antemano y almacenarlas, sacrificando un poco de actualidad a cambio de mucha más velocidad. En este caso, parece un compromiso asumible, porque una transacción más apenas altera la visión global de los hábitos de gasto de una persona durante seis meses.
Aunque tenemos ideas sólidas sobre cómo abordar estas cuestiones, se dejaron deliberadamente fuera de la fase de investigación. Ahora que hemos desarrollado con éxito la prueba de concepto, estamos avanzando en su puesta en producción como preparación para su implementación en un entorno real.
¿Son los modelos fundacionales el futuro de la detección del fraude?
Volvamos al escepticismo con el que empezamos. En el ámbito de la emisión, y a la luz de los datos disponibles, este enfoque demuestra su valía: permite detectar hasta un tercio más de fraude gracias a mejores datos de entrada para un modelo en el que ya confías, y sin necesidad de etiquetar casos de fraude para lograrlo.
Pero, al alejarnos de la emisión y pasar a conjuntos de características más completos e historiales más breves, esperamos que la ventaja se reduzca, quizá hasta desaparecer. Es una línea de investigación en la que seguimos trabajando activamente.
Así que, antes de preguntarte si un modelo fundacional es adecuado para ti, hay una pregunta más sencilla que debes responder primero: ¿cómo son realmente tus datos?
Lo que acaba de leer es la versión resumida. El informe técnico completo, «Creación de un modelo fundacional de riesgo», está dirigido a los equipos encargados de desarrollar este tipo de modelo. En él se detalla la metodología completa para que sus propios científicos de datos puedan aplicarla, los resultados íntegros para cada umbral, el análisis de cuántos datos históricos necesita realmente el modelo y una exposición franca de las cuestiones pendientes, desde la explicabilidad y la latencia hasta los experimentos que aún no hemos realizado.
Si estás evaluando si un enfoque como este encaja en tu organización, aquí encontrarás todos los detalles.