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 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 puntuación.) Sin embargo, en presencia de pruebas de que las transacciones con una puntuación baja no son fraudulentas y las transacciones con una puntuación alta son fraudulentas, una distribución cada vez más bimodal es un signo de una mayor eficacia para un modelo.

Diferentes modelos suelen tener distintas distribuciones de puntuación. Cuando lanzamos nuevos modelos, comparamos las distribuciones antiguas y actualizadas, en pedido para minimizar cualquier cambio disruptivo causado por un cambio repentino en las puntuaciones. En particular, tenemos en cuenta las políticas actuales de bloque de los comerciantes, medidas por el umbral al que bloquean las operaciones, y buscamos mantener estable la proporción de transacciones que superan ese umbral.

Precisión y exhaustividad informática

Podemos calcular las métricas anteriores en dos contextos diferentes: durante el entrenamiento del modelo, usando los datos históricos que impulsan el desarrollo del procesar, y después del despliegue del modelo, usando datos de producción; es decir, datos del mundo cuando el modelo ya se está utilizando para actuar bloqueando, por ejemplo, transacciones si P(fraude)>0,7.

En el caso primero, los científicos de datos suelen tomar los datos de entrenamiento que tienen (consulta la tabla anterior) y asignan aleatoriamente una fracción de los registros a un conjunto de entrenamiento y los otros registros a un conjunto de validación. Uno podría imaginar que el primer 80% de las filas va a la primera y el 20% restante a la segunda, por ejemplo.

El conjunto de entrenamiento es la información que se introduce en un método de machine learning para producir un modelo como se ha descrito 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 exhaustividad de precisión, las distribuciones de puntuación, y así sucesivamente. La razón por la que usamos un conjunto de validación separado que se mantiene fuera 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 son una medida precisa del poder predictivo del modelo sobre nuevos datos.

Operaciones de aprendizaje automático: despliegue de modelos de forma segura y frecuente

Una vez que se ha demostrado que el rendimiento de un modelo supera al modelo de producción actual en un set que no se espera, el siguiente paso es desplegarlo en producción. Hay dos desafíos clave en este proceso:

• Cálculos en Real tiempo: Necesitamos poder calcular el valor de cada función para cada nueva pago en tiempo real porque queremos poder bloquear todas las transacciones que nuestro clasificador considera probablemente fraudulentas. Este cálculo es completamente independiente del que se usa para producir datos de entrenamiento: necesitamos mantener un estado actualizado en las dos direcciones IP más usadas para cada tarjeta vista en Stripe, y obtener y actualizar esos conteos debe ser rápido porque esas operaciones se realizan como parte del flujo de Stripe API. Los equipos de infraestructura de aprendizaje automático de Stripe han facilitado esto construyendo sistemas para especificar características de forma declarativa y haciendo que los valores actuales de las características estén disponibles automáticamente en producción con baja latencia.

• Real-world usuario solicitud de acceso: Desplegar un modelo de machine learning es diferente de desplegar código. Aunque los cambios en el código suelen validarse con casos de prueba precisos, los cambios en el modelo suelen comprobarse en un gran conjunto de datos agregado utilizando métricas como las que definimos anteriormente. Pero un modelo que sea mejor captando fraude en conjunto puede no ser mejor para todos los Stripe usuario. Puede que la mejora en el rendimiento esté distribuida de forma desigual, con algunos grandes comerciantes experimentando grandes ganancias mientras que muchos pequeños experimentan pequeñas regresiones. Un modelo puede tener una mayor exhaustividad pero provocar un aumento en la tasa de bloqueo, lo que sería disruptivo para las empresas (y sus clientes). Antes de lanzar un modelo, verificamos que funcione bien en la práctica. Para ello, medimos el cambio que cada modelo causaría en una variedad de métricas, como la tasa de falsos positivos, la tasa de bloqueo y la tasa de autorización, en términos agregados y por comerciante para un subconjunto de usuarios de Stripe. Si descubrimos que un nuevo modelo provocaría un cambio indeseable en una de esas métricas de barrera de seguridad, lo ajustamos para diferentes subgrupos de usuarios antes de lanzarlo para minimizar las interrupciones y garantizar un rendimiento óptimo.

Hemos comprobado que automatizar la mayor parte posible del proceso de entrenamiento y evaluación aporta beneficios compuestos a la velocidad de iteración del modelo. En el último año, hemos invertido en herramientas para entrenar, ajustar y evaluar modelos de forma automática y regular utilizando nuestras últimas características y arquitectura de modelos. Por ejemplo, actualizamos continuamente los paneles de rendimiento después de que un modelo está entrenado, antes de que se lance. De este modo, un ingeniero puede detectar fácilmente si un candidato a modelo se ha quedado obsoleto en un subconjunto de tráfico antes incluso de lanzarlo y reentrenarlo de forma proactiva.

Después de lanzar un modelo, monitorizamos su rendimiento y empezamos a trabajar en la siguiente versión. Debido a que las tendencias del fraude cambian rápidamente, los modelos de machine learning empiezan a experimentar deriva rápidamente: los datos con los que fueron entrenados ya no representan el fraude actual.

Con estas herramientas, hemos triplicado la velocidad a la que lanzamos modelos, lo que se traduce directamente en grandes mejoras de rendimiento en producción. De hecho, incluso reentrenar un modelo del mes pasado con datos más recientes (usando las mismas definiciones de función y arquitectura) y publicarlo nos permite aumentar nuestra exhaustividad hasta en medio punto porcentual cada mes. Poder lanzar modelos con frecuencia y seguridad nos permite aprovechar y aumentar las ganancias de la ingeniería de funciones y el trabajo de modelado, y adaptarnos a los patrones cambiantes de fraude para los usuarios de Radar.

Una vez que ponemos un modelo en producción, monitorizamos continuamente el rendimiento de nuestro par modelo-política. Para pagos con puntuaciones por debajo del umbral de bloqueo, podemos observar el resultado final: ¿fue la transacción impugnada por el titular de la tarjeta como fraude? Sin embargo, los Payments que tienen puntuaciones por encima del umbral están bloqueados, por lo que no podemos saber cuáles habrían sido sus resultados. Calcular la curva de exhaustividad de precisión completa en producción o ROC es, por tanto, más complejo que calcular las curvas de validación porque implica análisis contrafactual: necesitamos 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, sobre los que puedes aprender más en este artículotalk.

Acabamos de describir algunas de las medidas de eficacia de los modelos que los científicos de datos y los ingenieros de machine learning analizan al desarrollar modelos de machine learning. A continuación, hablaremos de cómo deberían pensar las empresas en la prevención de fraude.

Cómo puede ayudarte Stripe

Fijarse solo en un número para captura tu desempeño en materia de fraude puede dar lugar a decisiones que no son óptimas para tu empresa. Hemos comprobado que las empresas suelen sobrevalorar los falsos negativos—les preocupa mucho el fraude que se pasa por alto—y subestiman los falsos positivos. Esta mentalidad suele dar lugar a medidas de fuerza bruta ineficaces y costosas, como bloquear todas las tarjetas internacionales. En general, deberías pensar en cómo se relacionan todas las distintas medidas de rendimiento y cuáles son los mejores sacrificios dadas tus circunstancias particulares. Aquí tienes un ejemplo de cómo estas métricas se relacionan para ayudarte a determinar la eficacia de tu sistema de prevención de fraude:

APPROXIMATE MODELO PARA EL PUNTO DE EQUILIBRIO PRECISION

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 tu producto cuesta 26,00 $ – 2,08 $ = 23,92 $ y se le impone un contracargo comisión 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 equilibrio es 1 / (1 + 18,71) = 5,07%.

Los umbrales de machine learning de Radar se basan en optimizar los márgenes de los comerciantes y mantener las tasas de bloqueo estables en toda nuestra base de usuarios. Puedes acceder a un panel de control para ver cómo está funcionando el machine learning de Radar para tu empresa, así como el rendimiento de tus reglas personalizadas si usas Radar for Fraud Teams. Estas herramientas te permiten comparar fácilmente tus tasas de disputa por fraude, falsos positivos y tasas de bloqueo con otras empresas similares, establecido en grupos agregados y personalizados de empresas que están en verticales o tamaños similares a los tuyos.

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.