Contribuciones: Cinthia Tanaka, Edesio Alcobaça, Felipe Almeida, Caroline Custodio, Pedro Schoen, Otávio Vasques

La prevención de fraudes sigue siendo uno de los desafíos más urgentes para las instituciones financieras, ya que los estafadores evolucionan constantemente sus tácticas. En Nu, aprovechamos la tecnología y la ciencia de datos para mantenernos un paso adelante.

En este artículo, conocerás un poco más sobre la modelización secuencial: una técnica avanzada de aprendizaje automático que ha transformado la manera en que detectamos y prevenimos el fraude.

Nuestro equipo de expertos, Carol, Pedro y Otávio, del equipo de Ciencia de Datos de Fraude (DS) de Nu, comparten sus experiencias sobre la construcción escalable de modelos secuenciales. Aprende cómo estos modelos nos han ayudado a comprender mejor los patrones de fraude y mejorar la protección al cliente, basándonos en las respuestas que nuestros expertos dieron a las preguntas preparadas por el equipo editorial de Nu.

P: ¿Qué son los modelos secuenciales? ¿En qué se diferencian de los enfoques tradicionales de aprendizaje automático?

Pedro: La principal diferencia entre los modelos secuenciales y los modelos tradicionales de aprendizaje automático radica en cómo incorporamos las características. En lugar de crear características (por ejemplo, agregando un valor determinado dentro de una ventana temporal específica, como 24 horas), alimentamos los eventos (por ejemplo, primero una compra con tarjeta de crédito, luego un préstamo) al modelo. El tiempo entre los eventos y el orden en que ocurren son señales críticas para identificar fraudes y robos, lo que hace que los modelos secuenciales sean especialmente efectivos para estos casos.

Descubre las oportunidades

P: ¿Por qué empezaron a invertir en modelos secuenciales?

Carol: Los modelos secuenciales ofrecen muchas ventajas, especialmente en lo que respecta a la escalabilidad y adaptabilidad. Para los modelos secuenciales, tenemos un desafío diferente para construir las características en tiempo real. No tenemos un volumen enorme de características que crear, es relativamente fácil realizar la ingeniería de características. El problema es recibir un array ordenado de eventos para poder calcular las características de cada evento. Sin embargo, una vez que tienes la estructura lista, es fácil expandirla porque tienes claves predeterminadas que recibes y esto no cambia cuando agregas más eventos o datos al modelo; no es necesario cambiar la ingeniería de características, lo que lo hace escalable y más fácil de adaptar a diferentes geografías.

Pedro: Añadiendo a lo que mencionó Carol, el verdadero beneficio de los modelos secuenciales es que nos permiten descubrir relaciones entre eventos que podríamos pasar por alto con los modelos tradicionales. Por ejemplo, saber qué ocurrió primero y qué ocurrió al final, o cuánto tiempo pasó entre esos eventos, nos ayuda a identificar patrones de fraude que de otro modo podrían pasar desapercibidos.

P: ¿Cómo implementaron los modelos secuenciales?

Pedro: Utilizamos redes neuronales para implementarlos, en una estructura que procesa eventos con capas que también reciben entradas adicionales relacionadas con características tradicionales (tabulares). En cuanto a las características, podemos crear cualquier número de características por evento, de tal manera que cada evento tiene n características predefinidas. Cada evento tiene el mismo conjunto de características y, si necesitamos algo nuevo, tenemos que incluirlo en un mapa. También podemos trabajar en una estructura que incorpore la información tradicional junto con las características secuenciales. Para diseñar el conjunto de datos de entrenamiento, capturamos eventos para una ventana temporal específica limitando el número de eventos, para optimizar el rendimiento.

Carol: En producción, tuvimos que obtener los datos en un formato con el que no estábamos acostumbrados. En general, para los modelos tradicionales, usamos  diferentes microservicios, pero ninguna de las fuentes de datos nos daba toda la información que necesitábamos para nuestro modelo secuencial, así que no podíamos obtener los datos desde un solo lugar en este caso. Nuestra solución fue construir una aplicación de streaming utilizando Apache Flink para obtener todos los eventos de un cliente dado dentro de una ventana temporal.

Otávio: Sin la aplicación de streaming, tendríamos que obtener estos eventos individualmente, haciendo llamadas a varios servicios diferentes. Nuestra aplicación escucha un tema de Kafka que tiene todo el Change Data Capture (CDC) relacionado con los eventos que nos interesan. La parte difícil fue que tuvimos que ponernos en contacto con los equipos que tienen la propiedad de los datos para que los integraran en la plataforma y así poder consumir los eventos en este tema. La aplicación de streaming es responsable de hacer los joins necesarios para que podamos construir la consulta SQL utilizando Apache Pinot.

P: ¿Cuáles fueron los desafíos durante la implementación?

Pedro: Uno de los primeros desafíos que enfrentamos fue lidiar con las fugas de memoria después de desplegar el modelo. Afortunadamente, pudimos depurar y resolver el problema, pero nos llevó algo de tiempo.

También fue difícil validar si las predicciones en línea eran correctas: si una característica particular en el evento estaba equivocada o si el orden no era correcto, el array no coincidiría con la entrada por lotes, por lo que tuvimos que validar cada característica dentro de cada evento. En cuanto a la interpretabilidad, utilizamos SHapley Additive exPlanations (Shap), pero tuvimos que adaptarlas para trabajar con los datos secuenciales. Para cada evento, tenemos un valor Shap, pero podemos sumarlos para leerlos como el valor Shap para las características habituales.

Carol, Otávio: El principal desafío del proyecto fue construir la aplicación de streaming que necesitábamos para consumir de manera eficiente los datos en tiempo real, ya que fue una de las primeras que construimos en Nu. Procesar grandes cantidades de datos de eventos, garantizar la compatibilidad entre los formatos de validación por batches y en tiempo real, y lidiar con tiempos de respuesta irregulares fueron también obstáculos significativos que enfrentamos al implementarlo.

Cuando pensamos en nuevas aplicaciones, algo que tiende a preocupar a los interesados es el costo detrás de ellas, pero no hemos visto muchos cambios en eso en comparación con los modelos tradicionales.

P: ¿Cómo impactaron los modelos secuenciales en la prevención de fraudes?

Pedro: Aunque parece que la estructura del modelo secuencial es más compleja, es más sencilla del lado de los datos: miles de millones de filas pueden procesarse en pocas horas. Para la primera prueba de concepto que hicimos, los resultados fueron peores que nuestra línea base, pero como la estructura era ligera y fácil de usar, comenzamos a utilizarla para otros casos de uso, donde obtuvimos un mejor rendimiento que la referencia.

P: ¿Dirían que el siguiente paso es hacer que los modelos secuenciales sean globales?

Pedro: Hemos visto que el comportamiento de los estafadores es similar en diferentes países y no hay limitaciones en el lado de la arquitectura del modelo.

Carol: En el lado del consumo de datos, hay una necesidad de adaptarse a los requisitos legales (privacidad de datos / intercambio de datos) y a las fuentes de datos de cada país. Puede ocurrir que tengamos que integrar nuevas fuentes de datos o adaptar ciertos eventos localmente. Por ejemplo, Pix (método de transferencia instantánea) solo existe en Brasil.

Otávio: Puede haber dominios en los que esta estandarización de datos ocurra casi de manera automática y esos son los dominios en los que ya hemos comenzado a trabajar en una versión global de un modelo secuencial. Para otros dominios, es posible que necesitemos abstraer ciertos eventos para asegurarnos de tener una estructura agnóstica al país.

P: Finalmente, ¿qué lecciones aprendieron y qué consejos compartirían con otros equipos?

Carol, Otávio, Pedro: Algunas lecciones clave destacan. Primero, los modelos secuenciales son mucho más fáciles de reutilizar para diferentes casos de uso en comparación con los modelos tradicionales. Aunque el modelo se beneficia de las capacidades de las GPU, ten en cuenta que cuanto más datos tienes, mayores son las demandas de recursos.

Otra lección importante fue la aplicación de streaming: construir una desde cero fue una jugada arriesgada, pero valió la pena. La lección clave es que, cuando intentas algo nuevo, es importante planificar con antelación y mitigar riesgos. No comenzamos obteniendo todos los eventos utilizando la aplicación de streaming. En su lugar, evaluamos si era factible para cada fuente de datos y trabajamos estrechamente con otros equipos para garantizar una integración fluida.

Finalmente, para agilizar el entrenamiento de los modelos secuenciales, construimos un flujo de trabajo personalizado utilizando una herramienta interna (Common Python Workflows) con el apoyo de nuestro equipo de infraestructura. Nuestro consejo a otros equipos interesados en explorar modelos secuenciales es comenzar con un caso de uso claro y estar preparados para un desarrollo iterativo.

Conclusión

La implementación de modelos secuenciales en Nu ha mejorado significativamente nuestra capacidad para prevenir fraudes y proteger a nuestros clientes. Al usar redes neuronales avanzadas para procesar datos basados en eventos, hemos construido modelos escalables y adaptables que pueden responder a los patrones de fraude en rápida evolución. Las lecciones aprendidas a lo largo de este proceso destacan el poder de la innovación y la adaptabilidad en la lucha contra el fraude.

En Nu, estamos comprometidos en seguir llevando los límites de la Ciencia de Datos y el Aprendizaje Automático para salvaguardar a nuestros clientes. Estén atentos para más perspectivas de la serie Purple MinDS, donde seguimos explorando los últimos avances en la prevención de fraudes y más allá.

Descubre las oportunidades