La tremenda aceleración que ha experimentado el e-commerce en los últimos tiempos ha provocado que se dispare el fraude en los pagos por Internet. Se calcula que, a nivel mundial, el fraude supone unos costes superiores a los 20.000 millones de dólares anuales para las empresas afectadas. Y lo que es peor: en realidad, por cada dólar que se pierde debido al fraude, el coste total para los negocios es muy superior, dado que suben los gastos de explotación, las comisiones de las redes y el abandono de clientes.

El problema no estriba solamente en que el fraude sea caro. Es que además, los estafadores más sofisticados encuentran constantemente nuevos modos de explotar los puntos débiles del sistema, por eso el fraude es tan difícil de combatir. Y por eso hemos creado Stripe Radar, una solución de prevención de fraude basada en el machine learning, totalmente integrada en la plataforma Stripe. La tecnología machine learning de Radar utiliza los datos recopilados al procesar pagos por valor de cientos de miles de millones de dólares en toda la red Stripe año tras año, para detectar con la máxima precisión los intentos de fraude y adaptarse a toda velocidad a las tendencias emergentes. Como resultado, tu negocio puede crecer sin que sufrir un aumento de estas actividades delictivas.

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 conocidos como falsos pagos rechazados, se producen cuando un cliente legítimo intenta efectuar una compra pero se le impide finalizar el proceso. Estos pagos rechazados de forma errónea pueden dañar la reputación y los beneficios de una empresa. De hecho, en una encuesta reciente, el 33 % de los consumidores afirmó que no volverían a comprar en la misma tienda si se les rechazase un pago indebidamente.

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 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 adaptativo: 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 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.

Esa capacidad de predicción es una de las principales aplicaciones del machine learning: 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 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 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. Podríamos imaginar, por ejemplo, que el primer 80 % de filas va para el primer conjunto y el 20 % restante se usará 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 conoce la respuesta de sus ejemplos de entrenamiento y aprendido de ellas. 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. Este proceso suele comportar dos retos:

• 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 los paneles de rendimiento 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 de su rendimiento. 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 conseguirlo: te contamos más detalles en esta charla.

Acabamos de describir algunas de las medidas de eficacia de modelos a las que recurren los científicos de datos e ingenieros 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 el importe medio de tus ventas es de 26 € y tienes un margen de beneficio del 8 %, tu beneficio por venta es de 26,00 € × 8,00 % = 2,08 €. De media, si producir tu producto cuesta 23,92 € (26,00 € – 2,08 €) 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 18,7 de ventas legítimas (el resultado de dividir 38,92 € / 2,08 €) y tu precisión de equilibrio es 1 / (1 + 18,71) = 5,07 %.

Los umbrales del machine learning de Radar se pueden equilibrar en función de los márgenes de cada comerciante y la estabilidad de las tasas de bloqueo en nuestra base de usuarios. Desde tu Dashboard, puedes acceder a un panel de control que te mostrará cómo funciona el machine learning de Radar para tu empresa, así como el rendimiento de tus reglas personalizadas 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, tanto con la media general como con un grupo específico de empresas de sectores similares 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 automáticos de machine learning, Radar for Fraud Teams también permite que las empresas escriban 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, 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 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.