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

El fraude no solo es caro, sino que los estafadores sofisticados encuentran constantemente nuevas formas de explotar las vulnerabilidades, lo que hace que el fraude sea difícil de combatir. Por eso hemos creado Stripe Radar, una solución de prevención de fraude basada en IA, totalmente integrada en la plataforma de Stripe. El machine learning de Radar aprovecha los datos de cientos de miles de millones de dólares en pagos procesados en la red de Stripe cada año para detectar el fraude con precisión y adaptarse rápidamente a las últimas tendencias, lo que te permite crecer 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, o falsos pagos rechazados, se producen cuando un cliente legítimo intenta realizar una compra pero se le impide hacerlo. Los falsos pagos rechazados pueden hacer que la empresa sufra un impacto tanto en su beneficio bruto como en su reputación. De hecho, en una encuesta reciente, el 33 % de los consumidores afirmó que no volvería a comprar en una empresa después de un falso pago rechazado.

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 prevención de fraude de Stripe que protege a las empresas frente al fraude en las tarjetas de crédito online. Cuenta con tecnología de machine learning adaptativo, que es el resultado de años de trabajo de ciencia de datos e infraestructura de los equipos especializados en machine learning de Stripe. Los algoritmos de Radar evalúan cada transacción en busca de riesgo de fraude y toman las medidas adecuadas. Se bloquean los pagos con puntuaciones altas, y Radar Plus ofrece herramientas para que los usuarios puedan especificar cuándo se deben tomar 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 puede activarse desde el primer momento. Otras soluciones de prevención del fraude suelen requerir inversiones muy importantes (tanto en pagos iniciales como en costes recurrentes). En primer lugar, las empresas deben integrar el producto de prevención de fraude que elijan. Esto implica trabajo de ingeniería para enviar datos de los eventos y pagos relevantes. Después, deben completar una integración específica que les permita asignar etiquetas a los pagos —una categorización de si las transacciones eran o no fraudulentas— de sus procesadores de pago para enviarlas a sus proveedores de prevención del fraude o etiquetar manualmente cada pago, lo que puede requerir más tiempo y provocar errores. Radar, por su parte, recibe la información directamente del flujo de pago habitual de Stripe y accede a los datos de las redes y emisores de las tarjetas de forma precisa y en el momento ideal, sin necesidad de invertir tiempo ni recursos de ingeniería.

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 unos valores de entrada. En nuestro caso, el valor de salida es verdadero si el pago es fraudulento y falso si no lo es (estos valores binarios se llaman booleanos), y un ejemplo de un valor de entrada podría ser el país en el que se emitió la tarjeta o la cantidad de países distintos en los que se usó la tarjeta en la red de Stripe en el último día. Determinamos cómo hacer una predicción en función de 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 al estilo del «juego de las 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 que podamos distinguir entre las dos clases con la máxima precisión?). 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 proporciona de forma precisa y exhaustiva sugerencias de ortografía con su función «Querías decir...?» usando machine learning para modelar millones de parámetros relacionados con el idioma en menos de tres segundos.
  
• Amazon utiliza el 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 qué pagos podrían ser fraudulentos.

¿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 gran 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 datos complejos (una combinación de varios datos simples) calculados por 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 (o, como se le conoce en inglés, deep learning), inspiradas en la arquitectura de neuronas del cerebro, son las responsables de muchos avances en este campo, entre los que encontramos 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 estas 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 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 te indica que un modelo sea bueno. (Un modelo vacío que asigne aleatoriamente probabilidades de tan solo 0,0 y 1,0 también tendría una distribución de puntuación bimodal). 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 una mayor eficacia de un modelo.

Es habitual que distintos modelos tengan distintas distribuciones de puntuaciones. Cuando lanzamos modelos nuevos, comparamos las distribuciones antiguas y actualizadas para minimizar los posibles cambios perjudiciales causados por un cambio repentino en las puntuaciones. En particular, tenemos en cuenta las políticas de bloqueo actuales de los comerciantes, según el umbral en el que bloquean transacciones, y nuestro objetivo es que la proporción de transacciones que supera el umbral se mantenga estable.

Cómo calcular la precisión y la exhaustividad

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

Para el primero, los científicos de datos suelen tomar los datos de entrenamiento que tienen (toma de referencia la tabla anterior) y asignan de manera aleatoria 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 va al primero y el último 20 % al segundo.

El conjunto de entrenamiento consiste en los datos que se introducen en un método de machine learning para generar un modelo como se ha descrito anteriormente. Una vez que tenemos un modelo candidato, podemos usarlo para asignar puntuaciones a cada muestra en el conjunto de validación. Las puntuaciones del conjunto de validación junto con sus valores de salida se utilizan para calcular la curva ROC y las curvas de precisión-exhaustividad, las distribuciones de las puntuaciones, etc. El motivo por el que usamos un conjunto de validación separado del conjunto de entrenamiento es que el modelo ya ha «visto la respuesta» para sus ejemplos de entrenamiento y ha aprendido de esas respuestas. Un conjunto de validación nos ayuda a generar métricas que representan 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 del modelo de producción actual en un conjunto reservado, el siguiente paso es implementarlo en producción. Hay dos retos principales en este proceso:

• Cálculos en tiempo real: necesitamos poder calcular el valor de cada función para cada pago nuevo en tiempo real, porque queremos poder bloquear todas las transacciones que nuestro clasificador considere que probablemente sean fraudulentas. Este cálculo es totalmente independiente del que se utiliza para generar datos de entrenamiento: debemos mantener un estado actualizado en las dos direcciones IP que más se usan para todas las tarjetas que se han visto en Stripe. Además, la recuperación y la actualización de esos recuentos debe ser rápida, porque esas operaciones se producen como parte del flujo de la API de Stripe. Los equipos de infraestructura de machine learning de Stripe han facilitado esta tarea al crear sistemas para especificar las funciones de forma declarativa y hacer que los valores actuales de las funciones estén disponibles automáticamente en producción con baja latencia.

• Aplicación de usuario en el mundo real: implementar un modelo de machine learning no es lo mismo que implementar código. Aunque los cambios en el código se suelen validar mediante casos de prueba precisos, los cambios en los modelos se suelen poner a prueba en un gran conjunto de datos agregados con métricas como las que hemos definido antes. Sin embargo, puede que un modelo que sea más eficaz para detectar el fraude a nivel general no sea el mejor para cada usuario de Stripe. Es posible que la mejora del rendimiento se distribuya de forma desigual, de modo que unos pocos comerciantes de gran tamaño obtengan grandes beneficios y muchos comerciantes de menor tamaño experimenten pequeñas regresiones. Puede que un modelo tenga mayor exhaustividad, pero provoque un pico en la tasa de bloqueos, lo que sería perjudicial para las empresas (y para 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 provocaría en diversas métricas, como la tasa de falsos positivos, la tasa de bloqueo y la tasa de autorización a nivel agregado y por 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 control, lo ajustamos para diferentes subconjuntos de usuarios antes de lanzarlo con el objetivo de minimizar los perjuicios y garantizar un rendimiento óptimo.

Hemos descubierto que automatizar en la medida de lo posible el proceso de entrenamiento y de evaluación aporta beneficios exponenciales a la velocidad de iteración de los modelos. En el último año, hemos invertido en herramientas para entrenar, ajustar y evaluar modelos de forma automática y frecuente mediante nuestras funciones y arquitectura de modelo más recientes. Por ejemplo, actualizamos continuamente los dashboards de rendimiento después de que se entrene un modelo (antes de que se lance). De este modo, un ingeniero puede detectar fácilmente si un modelo candidato se ha quedado obsoleto en un subconjunto del tráfico incluso antes de lanzarlo y volver a entrenarlo de forma proactiva.

Después de lanzar un modelo, supervisamos su rendimiento y empezamos a trabajar en el siguiente lanzamiento. Como las tendencias de fraude cambian con rapidez, los modelos de machine learning no tardan en empezar a experimentar una desviación: los datos con los que se entrenaron ya no son representativos del fraude actual.

Con estas herramientas, hemos triplicado la velocidad a la que lanzamos los modelos, lo que se traduce directamente en grandes mejoras de rendimiento en producción. De hecho, volver a entrenar un modelo del mes pasado con datos más recientes (usando las mismas definiciones de función y arquitectura) y lanzarlo nos permite aumentar nuestra exhaustividad hasta medio punto porcentual cada mes. El hecho de poder lanzar modelos de forma frecuente y segura nos permite aprovechar y multiplicar los beneficios del trabajo de la ingeniería de funciones y de los modelos, así como adaptarnos a los patrones de fraude cambiantes para los usuarios de Radar.

Una vez que ponemos un modelo en producción, supervisamos continuamente el rendimiento de nuestro par de modelo-política. En los pagos que tienen puntuaciones por debajo del umbral de bloqueo, podemos observar el resultado final: ¿el titular de la tarjeta ha disputado la transacción por fraude? Sin embargo, los pagos que tienen puntuaciones por encima del umbral se bloquean, de modo que no podemos saber cuáles habrían sido sus resultados. Por tanto, calcular la curva ROC o de precisión-exhaustividad de la producción completa es más complejo que calcular las curvas de validación porque conlleva un análisis contrafactual: tenemos que obtener estimaciones sólidas desde el punto de vista estadístico de lo que habría pasado incluso en los pagos que hemos bloqueado. A lo largo de los años, Stripe ha desarrollado varios métodos para hacerlo, de los cuales puedes obtener más información en esta charla.

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

Cómo puede ayudarte Stripe

Obsesionarse con una sola cifra para reflejar tu rendimiento en materia de fraude puede hacer que tomes decisiones que no sean las mejores para tu empresa. Hemos descubierto que las empresas suelen dar demasiada importancia a los falsos negativos (les preocupa mucho el fraude que se pasa por alto) y quitan importancia a los falsos positivos. Con frecuencia, esta forma de pensar deriva en medidas de fuerza bruta que resultan ineficaces y costosas, como bloquear todas las tarjetas internacionales. Por lo general, deberías plantearte cómo se relacionan entre sí las distintas medidas de rendimiento y cuáles son las contrapartidas adecuadas en función de tus circunstancias concretas. A continuación, te mostramos un ejemplo de cómo estas métricas se vinculan para ayudarte a determinar la eficacia de tu sistema de prevención de fraude:

MODELO APROXIMADO DE PRECISIÓN DE RENTABILIDAD

Si tu venta media es de 26 $ con un margen del 8 %, tu beneficio por venta es de 26,00 $ × 8,00 % = 2,08 $. De media, 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 por una venta fraudulenta es de 23,92 $ + 15,00 $ = 38,92 $. Por lo tanto, una venta fraudulenta te cuesta el beneficio de 38,92 $ / 2,08 $ = 18,71 ventas legítimas, y tu precisión de rentabilidad es de 1 / (1 + 18,71) = 5,07 %.

Los umbrales del machine learning de Radar logran un equilibrio entre la optimización para los márgenes de los comerciantes y el mantenimiento de unas tasas de bloqueo estables en toda nuestra base de usuarios. Puedes acceder a un dashboard para ver cómo funciona el machine learning de Radar para tu empresa, así como el rendimiento de tus reglas personalizadas si usas Radar Plus. Con estas herramientas, puedes comparar fácilmente tus tasas de disputas por fraude, tus tasas de falsos positivos y tus tasas de bloqueo con las de empresas parecidas gracias a grupos agregados y personalizados de empresas de sectores o de 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 automáticos, Radar Plus también permite que las empresas particulares elaboren reglas personalizadas (por ejemplo, «bloquear todas las transacciones de más de 1000 $ si el país de la IP no coincide con el de la tarjeta»), soliciten intervenciones y revisen de forma manual 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 medir la eficacia de tus sistemas de fraude. Puedes obtener más información sobre las funciones de Radar o explorar nuestra documentación.

Si tienes alguna duda o quieres obtener más información sobre Stripe Radar, ponte en contacto con nosotros.