La reciente y enorme aceleración del e-commerce ha provocado un aumento paralelo del fraude en los pagos por Internet. Se estima que el fraude cuesta a las empresas más de 20.000 millones de dólares al año en todo el mundo. Además, por cada dólar perdido por fraude, el coste total para las empresas es mucho mayor debido al aumento de los costes operativos, las comisiones de las redes y la pérdida de clientes.

El fraude no solo resulta caro, sino que quienes lo cometen encuentran constantemente nuevas formas sofisticadas de explotar vulnerabilidades, lo que dificulta combatirlo. Por eso hemos creado Stripe Radar, una solución de prevención del fraude basada en IA e integrada por completo en la plataforma de Stripe. El machine learning de Radar aprovecha los datos de cientos de miles de millones de dólares en pagos que se procesan cada año en la red de Stripe para detectar el fraude con precisión y adaptarse rápidamente a las últimas tendencias. Así puedes hacer crecer tu negocio sin aumentar el fraude.

Aquí tienes una guía para conocer Stripe Radar, que explica cómo aprovechamos las posibilidades de la red de Stripe para detectar fraudes, ofrece una perspectiva general de las técnicas de machine learning que empleamos, explica cómo nos concebimos la eficacia y las prestaciones de los sistemas de detección del fraude y describe cómo hay otras herramientas del paquete de Radar muy útiles para que cualquier empresa optimice su estrategia de lucha contra este fenómeno.

Introducción al fraude con tarjetas de crédito por Internet

Un pago se considera fraudulento cuando el titular de la tarjeta no autoriza el cargo. Veamos el siguiente ejemplo: si un estafador hace una compra con una tarjeta robada cuya sustracción no se ha denunciado, es posible que el pago se procese sin problemas. Posteriormente, cuando la persona titular de la tarjeta descubra este uso fraudulento, le preguntará por el cargo a su banco y presentará una disputa (también llamada «contracargo»).

Ante un contracargo, la empresa puede contestar y rechazarlo si presenta pruebas que acrediten la validez del pago. Sin embargo, en el caso de transacciones efectuadas sin la presencia física de la tarjeta, si las redes consideran que el pago ha sido fraudulento, prevalecerá la postura de la persona titular y la empresa tendrá la obligación de compensar la pérdida de bienes y demás comisiones asociadas.

Históricamente, las empresas han utilizado reglas de fuerza bruta para predecir y bloquear los cargos o pagos sospechosos de fraude. Sin embargo, las reglas inamovibles, codificadas con instrucciones como por ejemplo «bloquear todas las tarjetas de crédito que se usen en el extranjero», implican el riesgo de bloquear multitud de transacciones legítimas. En contraste con ello, el machine learning es capaz de detectar patrones más sutiles y así contribuye a potenciar los ingresos. En el lenguaje de esta nueva tecnología, se considera un falso negativo que el sistema pase por alto algún detalle que está diseñado para detectar. En este caso, una transacción fraudulenta sería un «falso negativo». Por contra, se considera que se produce un falso positivo cuando el sistema apunta como erróneo algo que en realidad no lo es. Por ejemplo, cuando bloquea a un cliente lícito. Pero antes de profundizar en el machine learning, es fundamental que entendamos qué compromisos y renuncias lleva implícitos.

Con los falsos negativos, normalmente las empresas son responsables del monto original de la transacción más las comisiones por contracargo (o sea, los costes derivados de que el banco anule el pago con tarjeta). El resultado es que las redes imponen comisiones más altas y suben los costes operativos porque hay que revisar cobros y disputar transacciones. Encima, si la empresa se involucra en demasiadas disputas, podría ser incluida en el programa de supervisión de contracargos de la red correspondiente. Y eso puede causar costes más elevados e incluso, en ciertos casos, incapacitarla para aceptar pagos con tarjeta.

Los falsos positivos, también llamados pagos rechazados por error, se producen cuando un cliente legítimo intenta realizar una compra, pero no puede hacerlo. Estos rechazos pueden perjudicar tanto el beneficio bruto como la reputación del negocio. De hecho, en una encuesta reciente, el 33 % de los consumidores afirmó que no volvería a comprar en un negocio después de que se rechazara por error uno de sus pagos.

Existe una estrecha relación entre prevenir más disputas (falsos negativos) y reducir el bloqueo de clientes legítimos (falsos positivos), ya que, cuantas menos disputas tengas, mejor tendrás que tolerar el bloqueo de pagos perfectamente válidos, y viceversa. Cuanto más fraude prevengas, mayor será el número de clientes legítimos bloqueados. Por otra parte, reducir el número de falsos positivos suele aumentar la probabilidad de que más casos de fraude acaben colándose entre tus medidas de seguridad. Las empresas tienen que decidir cómo equilibrar este dilema en función de sus márgenes, su perfil de crecimiento y otros factores.

Si los márgenes de tu empresa son bajos (por ejemplo, en un negocio de venta de comida por Internet), puede que tengas que compensar el coste de una transacción fraudulenta con cientos de transacciones legítimas, así que, cada falso positivo te costará muy caro. Las empresas con este perfil pueden decantarse por ampliar su umbral de bloqueo y, así, detener más transacciones fraudulentas. En cambio, una empresa con un mayor margen de beneficios (por ejemplo, un negocio SaaS) se encuentra en el caso contrario. La pérdida de ingresos por haber bloqueado un solo cliente puede superar el coste del aumento del fraude.

Stripe Radar y la red de Stripe

Radar es la solución de Stripe para prevenir el fraude con tarjetas de crédito en internet. Se basa en un sistema de machine learning adaptativo, fruto de años de trabajo en ciencia de datos e infraestructura por parte de los equipos especializados de Stripe. Los algoritmos de Radar evalúan el riesgo de fraude de cada transacción y actúan en consecuencia. Los pagos con una puntuación de riesgo elevada se bloquean, y Radar Plus ofrece herramientas para que los usuarios especifiquen cuándo deben aplicarse 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 funciona desde el primer momento. Por lo general, otras soluciones de prevención del fraude requieren una inversión inicial y continua considerable. En primer lugar, los negocios deben integrar el producto de prevención del fraude, lo que implica trabajo de ingeniería para enviar datos sobre eventos y pagos relevantes. En segundo lugar, deben integrar un sistema para transferir al proveedor de prevención del fraude las etiquetas de los pagos —la clasificación que indica si una transacción fue fraudulenta— desde su procesador de pagos, o etiquetar manualmente los pagos. Esto puede llevar muchísimo tiempo y dar lugar a errores. Radar, en cambio, recibe información fiable sobre el resultado real directamente del flujo de pagos habitual de Stripe y utiliza datos oportunos y precisos de las redes de tarjetas y de los emisores, sin necesidad de dedicar tiempo de ingeniería ni escribir 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

El machine learning hace referencia a un conjunto de técnicas para recopilar grandes cantidades de datos y usarlos para producir modelos capaces de predecir resultados como, por ejemplo, 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 una variable de salida a partir de determinados valores de entrada. En nuestro caso, el valor de salida es verdadero si el pago es fraudulento y falso en caso contrario. Estos valores binarios se denominan booleanos. Un valor de entrada podría ser, por ejemplo, el país en el que se emitió la tarjeta o el número de países distintos desde los que se ha utilizado en la red de Stripe durante el último día. Las predicciones se basan en ejemplos anteriores de datos de entrada y 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 detectamos una nueva transacción, analizamos los valores de entrada y recorremos el árbol, siguiendo una dinámica similar a la del juego de las 20 preguntas, hasta llegar a una de sus «hojas». Cada hoja contiene todas las muestras del conjunto de datos (la tabla anterior) que cumplen las preguntas y respuestas del recorrido seguido por el árbol. La probabilidad que asignamos a que la nueva transacción sea fraudulenta se calcula dividiendo el número de muestras fraudulentas de esa hoja entre el número total de muestras que contiene. Dicho de otro modo, el árbol responde a la pregunta: «De las transacciones de nuestro conjunto de datos que tienen características similares a la que estamos analizando, ¿qué proporción resultó ser fraudulenta?». El machine learning se ocupa de construir el árbol: qué preguntas hacer y en qué orden para distinguir con la mayor precisión posible entre las dos clases. Los árboles de decisión son especialmente fáciles de visualizar y analizar, pero existen muchos algoritmos de aprendizaje diferentes, cada uno con su propia forma de representar las relaciones que queremos modelar.

Hoy en día, los modelos de machine learning están muy extendidos, funcionan en segundo plano en muchos de los productos con los que interactuamos habitualmente y, por lo general, son mucho más sofisticados que el sencillo modelo del ejemplo anterior.

• Google utiliza machine learning para ofrecer sugerencias ortográficas precisas con la función «Quizás quisiste decir» de la Búsqueda, mediante el modelado de millones de parámetros lingüísticos en menos de tres segundos.
  
• Amazon utiliza machine learning para predecir qué comprarán los usuarios mediante su sistema de recomendaciones, que tiene en cuenta sus necesidades, preferencias y comportamientos cambiantes en toda la plataforma, incluso cuando se trata de usuarios nuevos sin datos históricos.
  

Y, lo que es más relevante para este tema, Stripe Radar se basa en machine learning para predecir cuáles de tus pagos son fraudulentos.

¿Cómo funciona el machine learning?

Los cursos académicos sobre machine learning suelen centrarse en el proceso de modelado: los métodos para transformar datos (por ejemplo, la tabla anterior) en modelos (como el árbol de decisión), es decir, algoritmos que indican cómo se relacionan los valores de entrada (el país en el que se emitió la tarjeta, el número de países desde los que se ha utilizado, etc.) con los valores de salida (si la transacción era fraudulenta o no). El proceso que toma la tabla de datos de entrada anterior y produce el «mejor» árbol es un ejemplo de un método de machine learning. El modelado consta de varios pasos que dependen de la naturaleza de los datos y de los modelos que se elijan. Sin entrar en demasiados detalles, a continuación ofrecemos una visión general.

En primer lugar, necesitamos datos de entrenamiento. Para detectar el fraude automáticamente, necesitamos un conjunto de datos con ejemplos de fraude. Para cada ejemplo, debemos haber registrado (o poder calcular a posteriori) una serie de propiedades de entrada que puedan resultar útiles para predecir futuros valores de salida. Estas propiedades se denominan características. El conjunto de valores de entrada de una muestra se denomina vector de características. En el ejemplo anterior, el vector tenía tres componentes: el país en el que se emitió la tarjeta, el número de países desde los que se utilizó durante el día anterior y el importe del pago en USD.

No es raro, sin embargo, que los vectores de características tengan cientos o miles de componentes. De hecho, Radar utiliza cientos de características, la mayoría de ellas agregados calculados a partir de los datos de toda la red de Stripe. A medida que crece nuestra red, cada característica aporta más información, porque los datos de entrenamiento representan mejor el conjunto de datos de esa característica, incluidos los datos ajenos a Stripe. El valor de salida —en nuestro ejemplo, un valor booleano que indica si la transacción era fraudulenta— suele denominarse objetivo o etiqueta. Por tanto, los datos de entrenamiento constan de un gran número de vectores de características y sus correspondientes valores de salida.

En segundo lugar, tenemos que entrenar un modelo. A partir de los datos de entrenamiento, necesitamos un método para crear el modelo predictivo. Por lo general, los clasificadores de machine learning no se limitan a devolver una etiqueta de clase, sino que asignan probabilidades de que una muestra pertenezca a cada una de las clases posibles. Por ejemplo, un clasificador de fraude podría estimar que un pago tiene un 65 % de probabilidades de ser fraudulento y un 35 % de ser legítimo.

Existen muchas técnicas de machine learning para entrenar modelos. En la mayoría de las aplicaciones industriales, los métodos tradicionales, como la regresión lineal, los árboles de decisión o los bosques aleatorios, suelen ser suficientes.

Sin embargo, las técnicas más sofisticadas, como las redes neuronales y el aprendizaje profundo, inspiradas en la estructura de las neuronas del cerebro, han impulsado muchos avances en este campo. Entre ellos se encuentran las predicciones de AlphaFold sobre el 98 % de todas las proteínas humanas. Las redes neuronales ofrecen ventajas reales cuando se entrenan con conjuntos de datos muy grandes, por lo que muchas empresas no pueden aprovecharlas plenamente en la práctica. Gracias al tamaño de nuestra red, Stripe puede adoptar este enfoque más avanzado y ofrecer resultados concretos a nuestros usuarios. Nuestros nuevos modelos han mejorado más de un 20 % interanual el rendimiento del machine learning de Radar, lo que nos permite detectar más fraude y mantener un nivel bajo de falsos positivos.

Ingeniería de características

Una de las tareas más complejas del machine learning industrial es la ingeniería de características. Consta de dos partes:
1) definir características con valor predictivo a partir de un conocimiento profundo del ámbito del problema y 2) desarrollar los medios técnicos necesarios para que los valores de esas características estén disponibles tanto para entrenar el modelo como para evaluarlo en producción.

Al definir una característica, un científico de datos de Stripe podría plantear la hipótesis de que sería útil calcular si el pago con tarjeta procede de una dirección IP habitual para esa tarjeta. Por ejemplo, es menos probable que un pago con tarjeta sea fraudulento si procede de una dirección IP que ya se ha utilizado antes (como la del domicilio o el lugar de trabajo del titular de la tarjeta) que si procede de una dirección IP de otro estado. En este caso, la idea resulta intuitiva, pero estas hipótesis suelen surgir tras examinar miles de casos de fraude. Por ejemplo, quizá te sorprenda saber que calcular la diferencia entre la hora del dispositivo del usuario y la hora universal coordinada (UTC), o contar los países en los que se ha autorizado correctamente una tarjeta, ayuda a detectar el fraude.

Una vez que tenemos la idea de una característica, debemos calcular sus valores históricos para poder entrenar un nuevo modelo que la incluya. Es como añadir una columna nueva a la «tabla» de datos que utilizamos para generar el modelo. Para nuestra característica candidata, tendríamos que calcular, para cada pago del historial de Stripe, las dos direcciones IP más frecuentes desde las que se habían realizado pagos anteriores con esa tarjeta. Podríamos hacerlo mediante un proceso distribuido con Hadoop, pero incluso así el proceso podría tardar demasiado o consumir demasiada memoria. En ese caso, podríamos intentar optimizar el cálculo mediante una estructura de datos probabilística que ahorre espacio. Incluso las características que parecen sencillas requieren infraestructura específica y flujos de trabajo consolidados para generar los datos de entrenamiento.

No todas las características las diseñan manualmente los ingenieros; algunas pueden dejarse en manos del modelo, con las pruebas pertinentes antes de implementarlo. Este enfoque funciona bien con valores categóricos, como el país de emisión de una tarjeta o el comercio que ha procesado una transacción, en lugar de características numéricas. Estos valores pueden abarcar muchas categorías y resulta difícil definir una representación adecuada.

En Stripe, entrenamos nuestros modelos para que aprendan una embedding de cada comercio a partir de los patrones de sus transacciones. Puede entenderse como las coordenadas de un comercio en relación con los demás. Los comercios similares suelen tener representaciones vectoriales parecidas —medidas mediante la distancia coseno—, lo que permite al modelo transferir lo aprendido de un comercio a otro. La tabla siguiente muestra cómo podrían ser estas representaciones: es probable que Uber y Lyft sean más similares entre sí que a Slack. En Stripe utilizamos representaciones vectoriales para distintas características categóricas, como el banco emisor, el país del comercio y del usuario, el día de la semana y muchas otras.

El uso de embeddings es cada vez más habitual en las aplicaciones industriales a gran escala de machine learning. Los embeddings de palabras como estos, por ejemplo, ayudan a capturar las complejas relaciones semánticas entre palabras y han estado presentes en hitos del procesamiento del lenguaje natural como Word2Vec, BERT y GPT-3. Stripe produce embeddings para capturar las relaciones de similitud entre diferentes entidades de la red de Stripe del mismo modo que los métodos anteriores capturan similitudes entre palabras. Los embeddings son una forma eficaz de aprender conceptos de nivel superior sin necesidad de entrenamiento explícito. Por ejemplo, las tendencias de fraude suelen distribuirse de manera desigual en términos geográficos. Con los embeddings, si nuestro sistema identifica una nueva tendencia de fraude en Brasil, puede identificar automáticamente el mismo patrón si aparece en EE. UU., sin necesidad de entrenamiento adicional. De este modo, los avances algorítmicos ayudan a anticiparse a las cambiantes tendencias 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 fuese 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 concreto, 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 (por las siglas en inglés 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 fuese 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 o al añadir más datos para su entrenamiento— 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 indica que un modelo sea bueno (un modelo vacío que asigne aleatoriamente probabilidades de solo 0,0 y 1,0 también tendría una distribución bimodal de puntuaciones). Sin embargo, si hay pruebas de que las transacciones con una puntuación baja no son fraudulentas y las transacciones con una puntuación alta sí lo son, una distribución cada vez más bimodal es señal de que la eficacia del modelo ha mejorado.

A menudo, los diferentes modelos tienen distintas distribuciones de puntuaciones. Cuando lanzamos modelos nuevos, comparamos las distribuciones antiguas con las actualizadas para minimizar cualquier cambio perjudicial causado por un cambio repentino en las puntuaciones. En concreto, tenemos en cuenta las políticas de bloqueo actuales de los comerciantes, que se miden según el umbral en el que bloquean las transacciones, y nuestro objetivo es mantener estable la proporción de transacciones que superan dicho umbral.

Cómo calcular la precisión y la exhaustividad

Podemos calcular las métricas anteriores en dos contextos diferentes: durante el entrenamiento del modelo, mediante los datos históricos que impulsan el proceso de desarrollo del modelo; y después de su implementación, mediante datos de producción (es decir, datos del mundo real cuando el modelo ya se utiliza para tomar medidas, por ejemplo, bloqueando transacciones si P(fraude)>0,7).

Para el primer contexto, los científicos de datos suelen tomar los datos de entrenamiento de los que disponen (consulta la tabla de referencia anterior) y asignar aleatoriamente una fracción de los registros a un conjunto de entrenamiento y el resto, a un conjunto de validación. Por ejemplo, podríamos imaginar que el primer 80 % de las filas se destina al primero y el 20 % restante al segundo.

El conjunto de entrenamiento son los datos que se introducen en un método de machine learning para crear un modelo, tal como se describió anteriormente. Una vez que tenemos un modelo candidato, podemos usarlo 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 utilizan para calcular las curvas ROC y de precisión-exhaustividad, las distribuciones de puntuaciones, etc. El motivo por el que utilizamos un conjunto de validación independiente que no se incluye en el de entrenamiento es que el modelo ya «ha visto la respuesta» de sus ejemplos de entrenamiento y ha aprendido de estas respuestas. Un conjunto de validación nos ayuda a generar métricas que supongan una medida precisa del poder predictivo del modelo con datos nuevos.

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

Una vez que se ha demostrado que el rendimiento de un modelo supera al actual de producción en un conjunto reservado, el siguiente paso es implementarlo en producción. Este proceso presenta dos retos fundamentales:

• Cálculos en tiempo real: tenemos que ser capaces de calcular el valor de cada función para cada pago nuevo en tiempo real, ya que queremos poder bloquear todas las transacciones que nuestro clasificador considere que pueden ser fraudulentas. Este cálculo es totalmente independiente del que se utiliza para producir los datos de entrenamiento: tenemos que mantener un estado actualizado de las dos direcciones IP más utilizadas en cada tarjeta que se haya visto alguna vez en Stripe. Además, la obtención y actualización de esos recuentos deben ser rápidas porque esas operaciones forman parte del flujo de la API de Stripe. Los equipos de infraestructura de machine learning de Stripe han facilitado esta labor mediante la creación de sistemas que permiten especificar las funciones de forma declarativa y hacen que sus valores actuales estén disponibles automáticamente en producción con una latencia baja.

• Aplicación para el usuario en el mundo real: la implementación de un modelo de machine learning es diferente a la implementación de código. Aunque los cambios de código se suelen validar con casos de prueba precisos, los de los modelos se prueban normalmente en un gran conjunto de datos agregados mediante métricas como las definidas anteriormente. A pesar de todo lo anterior, un modelo que detecta mejor el fraude de manera agregada puede no ser el mejor para todos los usuarios de Stripe. Es posible que la mejora del rendimiento se distribuya de forma desigual, de modo que unos pocos comerciantes grandes experimenten grandes beneficios mientras que muchos comerciantes pequeños experimenten pequeñas regresiones. Un modelo puede tener una mayor exhaustividad, pero causar un pico en la tasa de bloqueos, lo que sería perjudicial para las empresas (y sus clientes). Antes de lanzar un modelo, comprobamos que funcione bien en la práctica. Para ello, medimos el cambio que causaría cada modelo en diversas métricas, como la tasa de falsos positivos, la de bloqueos y la de autorización, de forma agregada y por cada comerciante para un subconjunto de usuarios de Stripe. Si detectamos que un modelo nuevo causaría un cambio no deseado en una de esas métricas de seguridad, lo ajustamos para diferentes subconjuntos de usuarios antes de lanzarlo para minimizar los perjuicios y garantizar un rendimiento óptimo.

Hemos comprobado que automatizar al máximo el proceso de entrenamiento y evaluación aporta beneficios exponenciales a la velocidad de iteración de los modelos. Durante el último año, hemos invertido en herramientas para entrenar, ajustar y evaluar modelos de forma automática y regular con la ayuda de nuestras últimas funciones y arquitectura de modelos. Por ejemplo, actualizamos continuamente los dashboards de rendimiento después de entrenar un modelo, es decir, antes de que se publique. De esta forma, un ingeniero puede detectar fácilmente si un modelo candidato se ha quedado obsoleto en un subconjunto de tráfico antes de lanzarlo y puede volver a entrenarlo de forma proactiva.

Después de lanzar un modelo, supervisamos su rendimiento y empezamos a trabajar en la siguiente versión. Como las tendencias de fraude cambian rápidamente, los modelos de machine learning empiezan a sufrir desviaciones pronto: los datos con los que se entrenaron ya no son representativos del fraude actual.

Gracias al uso de estas herramientas, hemos triplicado la velocidad de lanzamiento de modelos, lo que se traduce directamente en grandes mejoras de rendimiento en producción. De hecho, incluso volver a entrenar un modelo del mes pasado con datos más recientes (utilizando las mismas definiciones de funciones y arquitectura) y lanzarlo nos permite aumentar nuestra exhaustividad hasta en medio punto porcentual cada mes. Poder lanzar modelos de forma frecuente y segura nos permite aprovechar y multiplicar los beneficios del trabajo de diseño de funciones y de modelado, así como adaptarnos a los cambios en las tendencias de fraude de los usuarios de Radar.

Una vez que pasamos un modelo a producción, supervisamos continuamente el rendimiento de nuestro par de modelo y política. En el caso de los pagos con puntuaciones por debajo del umbral de bloqueo, podemos observar el resultado final: ¿el titular de la tarjeta disputó la transacción por fraude? Sin 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. En consecuencia, calcular la curva de producción completa de precisión y exhaustividad, o la curva ROC, es más complejo que calcular las curvas de validación porque implica un análisis contrafáctico: tenemos que obtener estimaciones estadísticamente sólidas de lo que habría ocurrido incluso con los pagos que bloqueamos. A lo largo de los años, Stripe ha desarrollado métodos para ello. Puedes obtener más información sobre ellos en esta charla.

Acabamos de describir algunas de las medidas de la eficacia de los modelos que los científicos de datos y los ingenieros de machine learning tienen en cuenta a la hora de desarrollar modelos de machine learning. A continuación, hablaremos sobre cómo deberían plantearse las empresas la prevención de fraude.

Cómo puede ayudarte Stripe

Centrarte en un solo número para registrar el rendimiento de tu prevención de fraude puede llevarte a tomar decisiones que no sean las mejores para tu empresa. Hemos comprobado que, a menudo, las empresas conceden demasiada importancia a los falsos negativos (les preocupa mucho el fraude que no se detecta) y restan importancia a los falsos positivos. Esta mentalidad suele dar lugar a medidas de fuerza bruta ineficaces y costosas, como el bloqueo de todas las tarjetas internacionales. Por lo general, deberías plantearte cómo se relacionan las distintas medidas de rendimiento y cuáles son las compensaciones adecuadas en tus circunstancias concretas. Este es un ejemplo de cómo estas métricas se combinan para ayudarte a determinar la eficacia de tu sistema de prevención de fraude:

MODELO APROXIMADO DE PRECISIÓN DE EQUILIBRIO

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

Los umbrales del machine learning de Radar buscan el equilibrio entre optimizar los márgenes de los comerciantes y mantener estables las tasas de bloqueo en toda nuestra base de usuarios. Puedes acceder a un dashboard para ver qué rendimiento está teniendo el machine learning de Radar en tu empresa, así como el rendimiento de tus reglas personalizadas si utilizas Radar Plus. Estas herramientas te permiten comparar fácilmente tus tasas de disputa por fraude, de falsos positivos y de bloqueo con las de otras empresas similares en función de grupos agregados y personalizados de empresas que operan en sectores similares o tienen un tamaño similar al de la tuya.

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

Además de los algoritmos de machine learning más automatizados, Radar Plus permite a cada negocio crear reglas personalizadas (por ejemplo, «bloquear todas las transacciones superiores a 1000 USD si el país de la dirección IP no coincide con el país de la tarjeta»), solicitar intervenciones y revisar manualmente los 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, reembolsaron 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 o al invertir esfuerzos adicionales (como las revisiones manuales).

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 requieren 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 de fraude en Stripe y cómo evaluar la eficacia de tus sistemas de prevención del fraude. Puedes obtener más información sobre las funciones de Radar o consultar nuestra documentación.

Escríbenos si tienes alguna pregunta o quieres obtener más información sobre Stripe Radar.