La reciente y masiva aceleración del e-commerce ha creado un aumento correspondiente en el fraude de pagos por Internet. En todo el mundo, el fraude cuesta a las empresas un estimado de más de 20 mil millones de dólares estadounidenses anuales. Además, por cada dólar perdido por el fraude, el coste total para las empresas es en realidad mucho más alto debido al aumento de los costes operativos, las tarifas de la red y el abandono de clientes.

El fraude no solo es costoso, sino que los estafadores sofisticados encuentran constantemente nuevas formas de explotar las debilidades, lo que hace que el fraude sea un desafío para combatir. Es por eso que creamos Stripe Radar, una solución de prevención de fraude basada en el machine learning, totalmente integrada en la plataforma de Stripe. El machine learning de Radar aprovecha los datos de cientos de miles de millones de dólares estadounidenses en pagos procesados en la red de Stripe cada año para detectar con precisión el fraude y adaptarse rápidamente a las últimas tendencias, lo que te permite crecer sin aumentar el fraude.

Esta guía presenta Stripe Radar y muestra cómo aprovechamos la red de Stripe para detectar fraudes, proporciona un resumen de las técnicas de machine learning que utilizamos, explica nuestra manera de pensar sobre la eficacia y el rendimiento de los sistemas de detección de fraudes, y describe cómo otras herramientas en el conjunto de Radar pueden ayudar a las empresas a optimizar su rendimiento frente al fraude.

Introducción al fraude con tarjetas de crédito en línea

Un pago se considera fraudulento cuando el titular de la tarjeta no autoriza el cargo. Por ejemplo, si un estafador realiza una compra con un número de tarjeta robado que no se ha denunciado, es posible que el pago se procese correctamente. Luego, cuando el titular de la tarjeta descubra el uso fraudulento de la tarjeta, cuestionará el pago con su banco presentando una disputa (también conocida como «contracargo»).

Las empresas pueden impugnar un contracargo presentando pruebas que demuestren que el pago ha sido válido. Sin embargo, para las transacciones sin tarjeta presente, si las redes consideran que el pago ha sido verdaderamente fraudulento, el titular de la tarjeta ganará y la empresa será responsable de la pérdida de bienes y otros cargos.

Históricamente, las empresas han utilizado reglas de fuerza bruta para predecir y bloquear presuntos cargos fraudulentos. Sin embargo, las reglas codificadas, por ejemplo, el bloqueo de todas las tarjetas de crédito utilizadas en el extranjero, pueden causar el bloqueo de muchas transacciones legítimas. El machine learning, por otro lado, puede detectar patrones más matizados para ayudarte a maximizar los ingresos. En la jerga del machine learning, un falso negativo es cuando el sistema pasa por alto una señal para la que está diseñado para detectar, en este caso, una transacción fraudulenta. Un falso positivo es cuando el sistema marca algo que no debería, por ejemplo, bloquear a un cliente legítimo. Antes de entrar en los detalles del machine learning, es importante comprender las compensaciones involucradas.

Con los falsos negativos, las empresas a menudo son responsables del importe de la transacción original más las tarifas de contracargo (el coste asociado con el banco que revierte el pago con tarjeta), comisiones de red más altas como resultado de la disputa y costes operativos más altos por la revisión de cargos o la resolución de disputas. Además, si incurres en demasiadas disputas, podrías terminar en un programa de supervisión de contracargos de la red, lo que puede generar costes más altos o, en algunos casos, la imposibilidad de aceptar pagos con tarjeta.

Los falsos positivos, o los pagos rechazados falsos, se dan cuando un cliente legítimo intenta realizar una compra, pero se le impide hacerlo. Los pagos rechazados falsos pueden hacer que la empresa tenga tanto una ganancia bruta como un impacto en la reputación. De hecho, en una encuesta reciente, el 33 % de los consumidores dijeron que no volverían a comprar en un negocio después de un pago rechazado falso.

Existe una compensación entre evitar más disputas (falsos negativos) y reducir el bloqueo de clientes legítimos (falsos positivos): cuanto menos tengas de los primeros, más tendrás que tolerar los segundos (y viceversa). Cuando evites más fraudes, aumentará la cantidad de clientes legítimos bloqueados. Por otro lado, la reducción del número de falsos positivos a menudo aumenta la probabilidad de que se escapen más fraudes reales. Las empresas deben decidir cómo equilibrar los dos en función de sus márgenes, perfil de crecimiento y otros factores.

Si los márgenes de una empresa son pequeños (por ejemplo, si vende alimentos en línea), es posible que el coste de una transacción fraudulenta deba compensarse con cientos de transacciones legítimas, lo que hace que cada falso negativo sea muy costoso. Las empresas con este perfil pueden inclinarse por lanzar una red amplia cuando intentan detener un posible fraude. Por otro lado, si los márgenes de una empresa son altos, por ejemplo, para una empresa de SaaS (Software como Servicio), ocurre lo contrario. La pérdida de ingresos de un cliente legítimo bloqueado puede superar el coste del aumento del fraude.

Stripe Radar y la red de Stripe

Radar es la solución de prevención del fraude de Stripe que protege a las empresas contra el fraude de tarjetas de crédito en Internet. Utiliza tecnología de machine learning adaptativa, el resultado de años de trabajo de infraestructura y ciencia de datos de los equipos especializados en machine learning de Stripe. Los algoritmos de Radar evalúan cada transacción para detectar el riesgo de fraude y actuar en consecuencia. Los pagos con puntuaciones altas se bloquean y Radar for Fraud Teams proporciona herramientas para que los usuarios puedan especificar cuándo deben tomarse otras medidas.

Stripe procesa cientos de miles de millones de pagos procedentes de millones de empresas e interactúa con miles de bancos colaboradores de todo el mundo cada año. Esta escala significa que con frecuencia podemos ver señales y patrones mucho antes que las redes más pequeñas. Los datos agregados relevantes para el fraude de todas las transacciones de Stripe, recopilados automáticamente a través del flujo de pagos, se usan para mejorar nuestra habilidad de detección del fraude. Señales como el país en el que la tarjeta se ha emitido o la dirección IP desde la que el pago se ha realizado proporcionan datos muy valiosos a la hora de predecir si el pago es probable que sea fraudulento.

Haber visto anteriormente una tarjeta en la red de Stripe también ofrece una importante cantidad de datos que aportan información a nuestras evaluaciones del riesgo. El noventa por ciento de las tarjetas utilizadas en la red de Stripe se han visto más de una vez, lo que nos ofrece datos mucho más completos para realizar evaluaciones sobre si su uso ha sido legítimo o fraudulento.

Otra ventaja clave de nuestro machine learning es que Radar está integrado directamente en Stripe y opera de inmediato. Otras soluciones de prevención del fraude suelen requerir invertir una cantidad sustancial tanto de forma previa como continua. En primer lugar, las empresas deben integrarse con el producto de prevención del fraude. Esto implica trabajo de ingeniería para enviar datos de los eventos y pagos relevantes. En segundo lugar, deben completar una integración para especificar las etiquetas de pago —una categorización de si las transacciones eran o no fraudulentas— de sus procesadores de pago a sus proveedores de prevención del fraude o etiquetar ellos mismos manualmente los pagos, lo que puede llevar a que se invierta mucho tiempo y se generen más errores. Radar, por su parte, recibe información de datos “reales” directamente del flujo de pago habitual de Stripe y accede a los datos de forma oportuna y precisa directamente de las redes y emisores de las tarjetas, sin necesidad de invertir tiempo en ingeniería ni código.

Veamos con más detalle qué es el machine learning y cómo lo usa Stripe.

Los aspectos básicos del machine learning

Machine learning hace referencia a un conjunto de técnicas para recopilar grandes cantidades de datos y usarlos para producir modelos que predigan resultados, tales como la probabilidad de que un cargo se dispute por fraude.

Una de las principales aplicaciones del machine learning es la predicción: queremos predecir el valor de ciertas variables de salida de acuerdo a ciertos valores de entrada. En nuestro caso, el valor de salida es verdadero si el pago es fraudulento y falso si no lo es (tales valores binarios se denominan booleanos), y un ejemplo de un valor de entrada podría ser el país en el que se ha emitido la tarjeta o el número de países diferentes en los que se ha utilizado la tarjeta en toda la red de Stripe el día anterior. Determinamos cómo realizar una predicción basándonos en ejemplos anteriores de datos de entrada y de salida.

Los datos utilizados para entrenar (o generar) los modelos constan de registros (que suelen obtenerse de los datos históricos) con los valores tanto de salida como con los diferentes valores de entrada, tal y como indicamos en el siguiente ejemplo (muy simplificado):

Aunque solo hay tres entradas en este ejemplo, en la práctica, los modelos de machine learning suelen tener cientos o miles de entradas. El valor de salida del algoritmo de machine learning podría ser un modelo como el árbol de decisión siguiente:

Cuando observamos una nueva transacción, nos fijamos en los valores de entrada y realizamos un recorrido del árbol “estilo de 20 preguntas” hasta que llegamos a una de sus “hojas”. Cada hoja consta de todas las muestras del conjunto de datos (la tabla superior) que responden a los pares pregunta-respuesta del camino a medida que bajamos por el árbol, y la probabilidad de ser fraudulenta que creemos que tiene la nueva transacción es el número de muestras de la hoja que son fraudulentas dividido por el número total de muestras de la hoja. Dicho de otro modo, el árbol responde a la pregunta, “De las transacciones de nuestro conjunto de datos con propiedades similares a la transacción que estamos examinando ahora, ¿qué fracción era realmente fraudulenta?” La parte de machine learning está relacionada con la construcción del árbol (¿qué preguntas hacemos y en qué orden para maximizar las opciones de que podamos distinguir entre las dos clases de manera precisa?). Los árboles de decisión son particularmente fáciles de visualizar y razonar, pero hay muchos algoritmos de aprendizaje diferentes, cada uno con su propia forma de representar las relaciones que estamos tratando de modelar.

Los modelos de machine learning de hoy en día son prevalentes —trabajando, en segundo plano, para muchos de los productos con los que interactuamos con frecuencia—, y generalmente mucho más sofisticados que el anterior modelo de juguete:

• Google, cuando realizas una búsqueda, proporciona de forma precisa y exhaustiva sugerencias de ortografía con su función "Quisiste decir" usando machine learning para modelar millones de parámetros relacionados con el idioma en menos de tres segundos.
  
• Amazon usa machine learning para predecir las compras con su sistema de recomendaciones basado en las necesidades, preferencias y cambios de comportamiento de los usuarios en toda su plataforma, incluso para nuevos usuarios de los que no tiene datos históricos.
  

Y, lo más relevante para el tema que estamos tratando, el machine learning es la base de Stripe Radar, cuyo objetivo es predecir cuál de tus pagos es fraudulento.

¿Cómo funciona el machine learning?

Los cursos académicos sobre machine learning suelen centrarse en el proceso de modelado, es decir, en los métodos para traducir los datos (p. ej., la tabla superior) en modelos (p. ej., el árbol de decisión), que son los algoritmos que te dirán cómo los valores de entrada (el país en el que se emitió la tarjeta, el número de países desde donde se utilizó la tarjeta, etc.) se asignan a los valores de salida (¿la transacción fue fraudulenta o no?). El proceso que toma la tabla de datos de entrada superior y produce el “mejor” árbol es un ejemplo de un método específico de machine learning. El modelado implica realizar una serie de pasos, que dependen de la naturaleza de tus datos y de los modelos que decides usar. Si bien no entraremos en mucho detalle, a continuación, encontrarás un resumen general.

En primer lugar, necesitamos obtener datos de entrenamiento. Antes de que podamos comenzar a detectar automáticamente el fraude, necesitamos un conjunto de datos con ejemplos del mismo. Para cada ejemplo, necesitamos haber registrado (o poder calcularlo de forma retrospectiva) un rango de propiedades de entrada que podrían ser útiles para realizar predicciones futuras sobre el valor de salida. Estas propiedades de salida se llaman características. La recopilación de entradas para una determinada muestra es un vector de características. En nuestro ejemplo anterior, el vector de características tenía una longitud de tres (el país en el que la tarjeta se emitió, el número de países en los que se utilizó la tarjeta el día anterior y el importe del pago en USD).

No obstante, los vectores de características con cientos o miles de características no son habituales. De hecho, Radar usa cientos de características y la mayoría de ellas son agregados calculados de toda la red de Stripe. A medida que nuestra red aumenta su tamaño, cada característica se hace más informativa porque nuestros datos de entrenamiento se vuelven más representativos de todo el conjunto de datos de la característica, lo que incluye todos los datos que no son de Stripe. El valor de salida —en nuestro ejemplo, el booleano que indica si la transacción era o no fraudulenta— suele denominarse valor objetivo o etiqueta. Los datos de entrenamiento por tanto constan de un gran número de vectores de características y sus correspondientes valores de salida.

En segundo lugar, necesitamos entrenar un modelo. A partir de los datos de entrenamiento, necesitamos un método para producir nuestro modelo predictivo. Los clasificadores de machine learning no solo suelen generar una etiqueta de clase, sino que, por lo general, asignan probabilidades de que el ejemplo dado pertenezca a cada clase posible. Por ejemplo, el resultado de un clasificador de fraude podría ser una evaluación de que el pago tiene un 65 % de posibilidades de ser fraudulento y un 35 % de posibilidades de ser legítimo.

Hay muchas técnicas de machine learning que pueden utilizarse para entrenar modelos. Para la mayoría de aplicaciones industriales de machine learning sirven los enfoques tradicionales como la regresión lineal, los árboles de decisión o los bosques aleatorios.

No obstante, técnicas sofisticadas, como las redes neuronales y el aprendizaje profundo, inspiradas en la arquitectura de neuronas del cerebro, son las responsables de muchos avances en este campo, lo que incluye las predicciones de AlphaFold para el 98 % de todas las proteínas humanas. Las ventajas reales de las redes neuronales solo se ven cuando se entrenan en conjuntos de datos muy grandes, por lo que, en la práctica, muchas empresas no consiguen sacarle todo el provecho. Debido al tamaño de nuestra red, Stripe es capaz de usar este enfoque más de vanguardia para ofrecer resultados reales a nuestros usuarios. Nuestros nuevos modelos han mejorado el rendimiento del machine learning de Radar en más del 20 % año tras año, lo que nos ayuda a detectar más fraude al tiempo que mantenemos un nivel bajo de falsos positivos.

Ingeniería de características

Una de las partes más complicadas del machine learning industrial es la ingeniería de características, la cual consta de dos partes:
Formulación de características que tienen valor predictivo sobre la base de un extenso conocimiento del dominio del problema.
Ingeniería para que los valores de esas características estén disponibles tanto para el entrenamiento de modelos como para la evaluación de modelos en “producción”.

A la hora de formular una característica, el científico de datos de Stripe puede tener el presentimiento de que una característica útil sería calcular si el pago con tarjeta proviene de una dirección IP que es habitual en esa tarjeta. Por ejemplo, un pago con tarjeta que se origina desde direcciones IP que se han visto antes (como el domicilio o lugar de trabajo del titular de la tarjeta) son menos probables de ser fraudulentas que direcciones IP que proceden de una zona diferente. En ese caso, la idea es intuitiva, pero generalmente estas corazonadas surgen de examinar miles de casos de fraude. Por ejemplo, podría sorprenderte saber que, calcular la diferencia entre la hora del dispositivo del usuario y la hora universal coordinada (UTC) actual o hacer un recuento de los países en los que la tarjeta se ha autorizado correctamente, ayuda a detectar el fraude.

Una vez que tenemos la idea de la característica, debemos calcular sus valores históricos para que podamos entrenar un nuevo modelo que la incluya; este es el proceso de añadir una nueva columna a la “tabla” de datos que usamos para producir nuestro modelo. Para hacerlo para nuestra característica candidata, por cada pago del historial de Stripe, tenemos que calcular las dos direcciones IP más frecuentes desde la que se realizaron pagos anteriores con la tarjeta. Podríamos hacerlo de un modo distribuido con un trabajo de Hadoop, pero incluso así podríamos ver que ese trabajo conlleva demasiado tiempo (o memoria). Por tanto, podríamos intentar optimizar el cálculo utilizando una estructura de datos probabilística que ahorre espacio. Incluso para características que son intuitivamente sencillas, producir datos para el entrenamiento de modelos conlleva infraestructura específica y flujos de trabajo establecidos.

No todas las características las diseñan los ingenieros manualmente, sino que se le puede dejar al modelo que calcule algunas de ellas con pruebas posteriores antes de su implementación. Los valores de categorías, tales como el país de origen de una tarjeta o el comerciante que ha procesado una transacción (en contraposición a características numéricas), se prestan bien a este enfoque. Estas características suelen tener un rango amplio de valores y definir una buena representación de ellas puede ser todo un reto.

En Stripe, entrenamos nuestros modelos para que aprendan una incrustación para cada comerciante basándose en los patrones de transacciones. Una incrustación puede considerarse como las coordenadas del comerciante individual en comparación con las de otros. Los comerciantes parecidos suelen tener incrustaciones similares (medido de acuerdo a la similitud coseno), lo que permite al modelo transferir aprendizajes de un comerciante al siguiente. La tabla que aparece a continuación muestra el aspecto podrían tener estas incrustaciones, dado que es más probable que Uber y Lyft se parezcan más entre sí que a Slack. En Stripe, usamos incrustaciones para diferentes características de categorías tales como banco emisor, comerciante y país del usuario, día de la semana, etc.

El uso de incrustaciones es cada vez más común en aplicaciones industriales de machine learning a gran escala. Por ejemplo, las incrustaciones de palabras como estas, ayudan a captar las relaciones semánticas complejas entre palabras, y han estado implicadas en hitos de procesamiento del lenguaje natural como Word2Vec, BERT y GPT-3. Stripe produce incrustaciones para captar relaciones de similitud entre las diferentes entidades en la red de Stripe del mismo modo que los métodos anteriores captan similitudes entre palabras. Las incrustaciones son una potente forma de aprender conceptos de nivel superior sin entrenamiento explícito. Por ejemplo, los patrones de fraude suelen distribuirse de manera irregular a nivel geográfico. Con las incrustaciones, si nuestro sistema identifica un nuevo patrón de fraude en Brasil, puede identificar automáticamente y sin necesidad de entrenamiento adicional, el mismo patrón si este aparece en los Estados Unidos. En este sentido, los avances algorítmicos ayudan a adelantarse a los cambios en los patrones de fraude, protegiendo así a nuestros clientes.

Cómo evaluar los modelos de machine learning

Una vez que hemos desarrollado un clasificador de machine learning para el fraude que utiliza cientos de características y asigna, para cada transacción entrante, una probabilidad (o puntuación) de que el pago es un fraude, necesitamos determinar lo eficaz que es el modelo detectando fraude.

Términos clave

Para comprender mejor cómo evaluar nuestros sistemas de machine learning, resulta útil definir algunos términos clave.

Comencemos por suponer que hemos creado una directiva para bloquear un pago si el modelo de machine learning asigna a la transacción una probabilidad de ser fraudulenta de al menos 0,7 (lo escribimos como P(fraude)>0,7). A continuación, indicamos algunas cantidades útiles para establecer el razonamiento del rendimiento de nuestro modelo y directiva:

• Precisión: la precisión de nuestra directiva es la fracción de transacciones que bloqueamos que son realmente fraudulentas. Cuanta más precisión haya, menos falsos positivos habrá. Digamos que, de diez transacciones, seis son P(fraude)>0,7 y, de esas seis, cuatro son realmente fraudulentas. La precisión es por tanto de 4/6=0,66.

• Exhaustividad: también conocida como tasa de verdaderos positivos o sensibilidad, la exhaustividad es la fracción de todo el fraude que capta nuestra directiva, es decir, la fracción de fraude en la que P(fraude)>0,7. Cuanta más exhaustividad haya, menos falsos negativos habrá. Digamos que, de diez transacciones, cinco son realmente fraudulentas. Si a cuatro de esas transacciones nuestro modelo asigna un P(fraude)>0,7, la exhaustividad será entonces de 4/5=0,8.

• Tasa de falsos positivos: la tasa de falsos positivos es la fracción de todos los pagos legítimos que nuestra directiva ha bloqueado de manera incorrecta. Digamos que, de diez transacciones, cinco son legítimas. Si a dos de estas transacciones nuestro modelo asigna un P(fraude)>0,7, la tasa de falsos positivos será entonces de 2/5=0,4.

Aunque existen otras cantidades que se usan cuando se evalúa un clasificador, nos hemos querido centrar en estas tres.

Curva de precisión-exhaustividad y curva ROC

La siguiente pregunta natural es cuáles son los valores buenos para la precisión, exhaustividad y tasa de falsos positivos. En un mundo teóricamente ideal, la precisión sería 1,0 (que es que el 100 % de las transacciones que clasificas como fraude son realmente fraude), lo que haría que tu tasa de falsos positivos fuera 0 (no has clasificado de manera incorrecta ni una sola transacción legítima como fraudulenta), y la exhaustividad también sería de 1,0 (el 100 % del fraude se identificaría como tal).

En realidad, hay una compensación entre la precisión y la exhaustividad: a medida que aumentas el umbral de probabilidad para bloquear, la precisión aumentará (dado que el criterio para bloquear es más riguroso) y la exhaustividad disminuirá (dado que habrá menos transacciones que coincidan con el criterio de alta probabilidad). Para un modelo dado, una curva de precisión-exhaustividad capta la compensación entre la precisión y la exhaustividad cuando el umbral de directivas es variado:

Según vayamos mejorando a nivel general nuestro modelo —por entrenar cada vez más datos procedentes de toda la red de Stripe, añadir características que son buenos indicadores de fraude y afinar otros parámetros de modelos— la curva de precisión-exhaustividad irá cambiando, tal como se describió en el ejemplo anterior. Dado que controla la compensación para las empresas de Stripe, monitorizamos de cerca el impacto en la curva de precisión-exhaustividad cuando nuestros científicos de datos e ingenieros de machine learning modifican los modelos.

Cuando se tiene en cuenta un gráfico de precisión-exhaustividad, es importante distinguir entre las dos nociones de “rendimiento.” En sí mismo, un modelo es mejor en general cuanto más se acerca a la parte superior derecha del gráfico (que es donde tanto la precisión como la exhaustividad son de 1,0). No obstante, hacer operativo un modelo suele requerir la selección de un punto operativo en la curva de precisión-exhaustividad (en nuestro caso, el umbral de directivas para bloquear una transacción), que controla el impacto concreto que tiene en una empresa usar el modelo.

Expresado de manera sencilla, hay dos problemas:

• El problema de la ciencia de datos de producir un buen modelo de machine learning con las características adecuadas. El modelo controla la forma de la curva de precisión-exhaustividad.

• El problema de la empresa de seleccionar una directiva para decidir la cantidad de fraude potencial a bloquear. La directiva controla en qué parte de la curva estamos operando.

Otra curva que se estudia cuando se evalúa un modelo de machine learning es la curva ROC (ROC es la abreviatura de “característica operativa del receptor”, una reliquia del origen de la curva en aplicaciones de procesamiento de señales). La curva ROC es una representación gráfica de la tasa de falsos positivos (en el eje “x”) y la tasa de verdaderos positivos (que es lo mismo que la exhaustividad) en el eje “y” para diferentes valores del umbral de directivas.

El ROC ideal englobará la parte superior izquierda del gráfico (donde la exhaustividad es 1,0 y la tasa de falsos positivos es 0,0), y a medida que el modelo mejora, el ROC se moverá más en esa dirección. Una forma de captar la calidad general del modelo es calcular el área bajo la curva (o AUC); el caso ideal sería que el AUC fuera 1,0. Cuando desarrollamos nuestros modelos, nos fijamos para ver cómo cambian la curva de precisión-exhaustividad, la curva ROC y el AUC.

Distribuciones de puntuación

Imagina que tenemos un modelo que asigna aleatoriamente una probabilidad de fraude de entre 0,0 y 1,0 a una transacción. Prácticamente, este modelo no hace nada para diferenciar entre las transacciones legítimas y las fraudulentas, y es de poca utilidad para nosotros. La distribución de puntuación del modelo captura esta aleatoriedad (la fracción de transacciones con cada posible puntuación). En el caso completamente aleatorio, la distribución de puntuación estaría cerca de la uniformidad:

Un modelo tendrá una distribución de puntuación uniforme como la anterior si, por ejemplo, no tiene características que no sean ni remotamente predictivas de fraude. A medida que se mejora un modelo —al añadir funciones predictivas, utilizando más datos para su entrenamiento, etc.— su capacidad para diferenciar entre las clases legítimas y las fraudulentas aumenta, y la distribución de puntuación se hace más bimodal, con picos alrededor de las puntuaciones de 0,0 y 1,0.

Por sí sola, una distribución bimodal no te dice si un modelo es bueno (un modelo vacío que asigne aleatoriamente probabilidades de solo 0,0 y 1,0 también tendría una distribución de puntuación bimodal). No obstante, sí hay evidencia de que las transacciones con una puntuación baja no son fraudulentas y las que tienen una puntuación elevada lo son, una distribución bimodal en aumento es una señal de que ha mejorado la eficacia de un modelo.

Cada modelo suele tener una distribución de puntuación diferente. Cuando lanzamos modelos nuevos, comparamos las distribuciones antiguas con las actualizadas para minimizar cualquier cambio disruptivo provocado por un cambio repentino en las puntuaciones. En particular, tenemos en cuenta las directivas de bloqueo actuales de los comerciantes en función del umbral a partir del cual bloquean las transacciones, y el objetivo es mantener estable la proporción de transacciones que superan ese umbral.

Cómo calcular la precisión y la exhaustividad

Podemos calcular las métricas anteriores en dos contextos diferentes: durante el proceso de entrenamiento de modelos, usando los datos históricos que marcan el proceso de desarrollo del modelo, y después de la implantación del modelo, usando datos de producción; es decir, datos de todo el mundo cuando el modelo ya se está utilizando para tomar acciones como, digamos, bloquear transacciones si P(fraude)>0,7.

Para lo anterior, lo habitual es que los científicos de datos tomen los datos de entrenamiento que tengan (véase la tabla de arriba) y asignen aleatoriamente alguna fracción de los registros a un conjunto de entrenamiento y el resto de registros a un conjunto de validación. Se podría imaginar, por ejemplo, que el primer 80 % de filas van para el primer conjunto y, el 20 % restante, para el segundo.

El conjunto de entrenamiento son los datos que procesa un método de machine learning para producir un modelo tal y como se describió anteriormente. Una vez que tengamos un modelo candidato, podremos utilizarlo para asignar puntuaciones a cada muestra del conjunto de validación. Las puntuaciones del conjunto de validación junto con sus valores de salida se usan para calcular la curva ROC y la curva de precisión-exhaustividad, las distribuciones de puntuación, etc. El motivo de que usemos un conjunto de validación independiente que se retiene fuera del conjunto de entrenamiento es que el modelo ya “ha visto la respuesta” de sus ejemplos de entrenamiento y aprendido de esas respuestas. Un conjunto de validación nos ayuda a generar métricas que representan una medida precisa de la capacidad predictiva del modelo en nuevos datos.

Operaciones de machine learning: cómo implementar modelos de forma segura y frecuente

Una vez que se demuestra que el rendimiento de un modelo supera al modelo de producción actual en un conjunto de validación final, el siguiente paso es implementarlo en la producción. Hay dos retos clave para este proceso:

• Cálculos en tiempo real: Es necesario que podamos calcular el valor de cada característica para cada nuevo pago en tiempo real, puesto que queremos poder bloquear todas las transacciones que nuestro clasificador considere que son probablemente fraudulentas. Este cálculo es independiente por completo del utilizado para producir datos de entrenamiento (necesitamos mantener un estado actualizado en las dos direcciones IP que se utilizan con más frecuencia para cada tarjeta que se vea en Stripe), y la obtención y actualización de estos recuentos debe realizarse rápidamente porque esas operaciones tienen lugar como parte del flujo de la API de Stripe. Los equipos de infraestructura de machine learning de Stripe lo han simplificado al crear sistemas que especifican características de una forma declarativa y al poner automáticamente disponibles en producción los valores actuales de las características con una latencia baja.

• Aplicación para usuarios del mundo real: Implementar un modelo de machine learning es diferente a implementar código: mientras que los cambios de código se suelen validar con casos de prueba precisos, los cambios de modelos suelen probarse en un gran conjunto de datos agregado mediante métricas como las que se definieron anteriormente. Si bien, un modelo que es mejor para detectar el fraude en agregados puede que no lo sea para usuarios individuales en Stripe. Es posible que la mejora en el rendimiento se distribuya de forma irregular, donde solo algunos importantes comerciantes ven grandes ganancias mientras que muchos de los pequeños comerciantes ven pequeñas regresiones. Puede ser que un modelo tenga mayor exhaustividad, pero cause un pico en la tasa de bloqueos que sería disruptivo para las empresas (y sus clientes). Antes de lanzar un modelo, verificamos que tenga un buen rendimiento en la práctica.

Para ello, medimos el cambio que cada modelo causaría en diferentes métricas tales como la tasa de falsos positivos, la tasa de bloqueos y la tasa de autorización en un agregado y por comerciante para un subconjunto de usuarios de Stripe. Si descubrimos que un modelo nuevo provocaría un cambio no deseado en una de esas métricas de protección, antes de lanzarlo, lo ajustamos para diferentes subconjuntos de usuarios de forma que minimicemos las disrupciones y aseguremos un rendimiento óptimo.

Hemos descubierto que automatizar al máximo posible el proceso de entrenamiento y de evaluación proporciona ventajas de composición para la velocidad de iteración de modelos. En el último año, hemos invertido en herramientas para que, de forma automática y con regularidad, entrenen, afinen y evalúen modelos mediante el uso de nuestras funciones y arquitectura de modelos más recientes. Por ejemplo, antes de su lanzamiento, actualizamos continuamente el rendimiento de los Dashboards después de entrenar un modelo. De esa forma, el ingeniero puede detectar con facilidad si un modelo candidato ha quedado obsoleto en un subconjunto de tráfico incluso antes de lanzarlo y así poder volver a entrenarlo de forma proactiva.

Después del lanzamiento de un modelo, realizamos un seguimiento de su rendimiento y comenzamos a trabajar en el siguiente lanzamiento. Dado que las tendencias de fraude cambian rápidamente, los modelos de machine learning empiezan a experimentar cambios rápidamente: los datos con los que se entrenaron ya no son representativos del fraude en la actualidad.

Mediante el uso de estas herramientas hemos triplicado la velocidad a la que lanzamos los modelos, lo que se traduce directamente en mayores ganancias de rendimiento en producción. De hecho, incluso volver a entrenar un modelo del mes anterior con datos más recientes (usando la misma arquitectura y definiciones de característica) y lanzándolo, nos permiten aumentar nuestra exhaustividad en medio punto porcentual cada mes. Al poder lanzar modelos con frecuencia y de manera segura podemos capitalizar y calcular las ganancias del trabajo de ingeniería y modelaje de la característica, y adaptar los cambiantes patrones de fraude a los usuarios de Radar.

Una vez que ponemos un modelo en producción, hacemos un seguimiento continuo del rendimiento de nuestro par modelo-directiva. Para los pagos que tienen puntuaciones por debajo del umbral de bloqueo, podemos observar el resultado definitivo (¿se ha definido como fraude la transacción disputada por el titular de la tarjeta?). Si embargo, los pagos que tienen puntuaciones por encima del umbral se bloquean y, por tanto, no podemos saber cuáles habrían sido sus resultados. Calcular la curva ROC y la de precisión-exhaustividad de toda la producción es por tanto más complicado que calcular las curvas de validación porque implica un análisis contrafactual (necesitamos obtener estimaciones estadísticamente sólidas de lo que habría ocurrido incluso con los pagos que hayamos bloqueado). Con el paso de los años, Stripe ha desarrollado métodos para hacerlo; en esta charla se ofrece más información.

Acabamos de describir algunas de las medidas de eficacia de modelos a las que recurren los científicos de datos e ingenieros de machine learning cuando implementan modelos de machine learning. A continuación, hablaremos sobre cómo las empresas deberían considerar la prevención del fraude.

Cómo puede ayudar Stripe

Fijarse solo en un número como indicador de tu rendimiento de detección del fraude puede dar lugar a hacer elecciones que no sean óptimas para tu empresa. Hemos descubierto que las empresas suelen dar demasiada importancia a los falsos negativos —les preocupa mucho el fraude que pasan por alto—y quitan importancia a los falsos positivos. Este enfoque suele conllevar la aplicación de medidas ineficaces y muy costosas como bloquear todas las tarjetas internacionales. En general, deberías pensar en cómo todas las diferentes medidas de rendimiento se relacionan y qué compensaciones adecuadas se dan en tus circunstancias particulares. A continuación, tienes un ejemplo de cómo estás métricas se combinan para ayudarte a determinar la eficacia de tu sistema de prevención del fraude:

MODELO APROXIMADO PARA PRECISIÓN DE EQUILIBRIO

Si tu media de ventas es de 26 $ con un margen del 8 %, tu beneficio por venta es de 26,00 $ × 8,00 % = 2,08 $. De media, si cuesta producir tu producto 26,00 $ – 2,08 $ = 23,92 $ y se te impone una comisión de contracargo de 15 $, la pérdida total por una venta fraudulenta es de 23,92 $ + 15,00 $ = 38,92 $. Por tanto, una venta fraudulenta te cuesta el beneficio de 38,92 $ / 2,08 $ = 18,7 de ventas legítimas y tu precisión de equilibrio es 1 / (1 + 18,71) = 5,07 %.

Los umbrales de machine learning de Radar equilibran la optimización de los márgenes de los comerciantes y la estabilidad de las tasas de bloqueo en nuestra base de usuarios. Puedes acceder a un dashboard para ver cómo el machine learning de Radar funciona para tu empresa, así como tus rendimientos de reglas de clientes si estás usando Radar for Fraud Teams. Estas herramientas te permiten comparar con facilidad tu tasa de disputas fraudulentas, las tasas de falsos positivos y las tasas de bloqueo con otras empresas en cuanto al agregado y las cohortes personalizadas de empresas que están en verticales o que tienen un tamaño parecido al tuyo.

Cómo mejorar el rendimiento con las reglas y revisiones manuales

Con Radar for Fraud Teams, puedes afinar tu protección al ajustar directamente el umbral de riesgo para bloquear o permitir más pagos. Junto con los algoritmos de machine learning más automáticos, Radar for Fraud Teams también permite a empresas particulares redactar reglas personalizadas (por ejemplo, “bloquear todas las transacciones superiores a 1.000 $ cuando el país de la dirección IP no coincida con el país de la tarjeta”), solicitar intervenciones y revisar manualmente pagos marcados en el Dashboard.

Tales reglas pueden verse como simples “modelos” (al fin y al cabo, pueden representarse como árboles de decisión) y deben evaluarse —con plena consideración de la compensación entre precisión y exhaustividad—de la misma forma que los modelos. Cuando crees una regla con Radar, te mostraremos las estadísticas históricas en función del número de transacciones coincidentes que realmente se disputaron, rembolsaron o aceptaron para ayudar con estos cálculos antes incluso de que la regla se haya implementado. Una vez en modo activo, puedes ver el impacto en las tasas de disputa y falsos positivos por regla.

Igualmente importantes son las reglas, intervenciones y revisiones manuales que permiten a los usuarios cambiar la forma de la curva de precisión-exhaustividad a su favor, al añadir (reglas) lógicas específicas de la empresa y propietarias o al invertir esfuerzos extra (revisión manual).

Si adviertes que los algoritmos de machine learning pasan por alto con frecuencia cierto tipo de fraude específico para tu empresa (y es uno que tú identificas con facilidad), puedes redactar una regla para bloquearlo. Por lo general, esa intervención específica aumentará la exhaustividad teniendo un coste menor en la precisión, lo que lo que hará que el punto operativo se sitúe en una curva de precisión-exhaustividad más favorable y con una pendiente menor.

Al enviar ciertas clases de transacciones a revisión manual en lugar de bloquearlas por completo, puedes ganar precisión sin repercusión en la exhaustividad. De forma similar, al enviar algunas transacciones a revisión manual en lugar de permitirlas por completo, puedes ganar exhaustividad sin repercusión en la precisión.
Por supuesto, en dichos casos, estas ganancias cuestan más trabajo humano (y exponiéndote a ti mismo a la exactitud de las evaluaciones de tu equipo), pero al disponer de herramientas adicionales como son la revisión manual, las reglas y las intervenciones para autenticar a los clientes de alto riesgo, dispones de otra forma de impulsar la optimización de los resultados de fraude.

Pasos siguientes

Esperamos que esta guía te ayude a entender cómo se aplica el machine learning a la prevención del fraude en Stripe y cómo calibrar la eficacia de tus sistemas de detección del fraude. Puedes obtener más información sobre las funciones de Radar o consultar nuestra documentación.

Si tienes alguna pregunta o te gustaría saber más sobre Stripe Radar, contáctanos.