La reciente aceleración masiva del comercio electrónico ha dado lugar a un aumento significativo en los casos de fraude en línea. A nivel mundial, las empresas se ven obligadas a destinar más de USD 20 mil millones al año aproximadamente para combatir el fraude. Además, el costo total para las empresas por cada dólar perdido debido al fraude es aún más elevado, considerando los incrementos en los gastos operativos, las comisiones de red y la pérdida de clientes.

El problema no es solo que el fraude sea caro, sino en la constante evolución de los métodos utilizados por estafadores altamente sofisticados, quienes aprovechan las vulnerabilidades haciendo que la lucha contra el fraude sea cada vez más difícil de combatir. Es por eso que creamos Stripe Radar, una solución de prevención de fraude basada en el machine learning, que está totalmente integrada a 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 toda la red de Stripe cada año, lo que permite detectar el fraude con precisión y adaptar tu empresa rápidamente a las últimas tendencias, lo cual te permite crecer sin aumentar los riesgos asociados al fraude.

Esta guía presenta Stripe Radar y explica cómo aprovechamos la red de Stripe para detectar el fraude. Además, proporciona un resumen de las técnicas de machine learning que usamos, explica qué pensamos sobre la eficacia y el rendimiento de los sistemas de detección de fraude y describe cómo otras herramientas del paquete de Radar pueden ayudar a las empresas a optimizar su rendimiento en la gestión de fraudes.

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

Se considera que un pago es fraudulento cuando el titular de la tarjeta no autoriza el cargo. Por ejemplo, si un estafador realiza una compra con un número de tarjeta robado que aún no ha sido reportado como tal, es posible que el pago se procese sin problemas. Luego, cuando el titular descubre el uso indebido de la tarjeta, cuestiona el cargo a través de su banco, presentando una disputa, también conocida como "contracargo".

Las empresas pueden impugnar un contracargo proporcionando pruebas que respalden la legitimidad del pago. Sin embargo, en el caso de las transacciones donde no se presenta físicamente la tarjeta, si las redes consideran que el pago fue realmente fraudulento, el titular de tarjeta ganará la disputa, dejando a la empresa responsable de la pérdida de bienes y el pago de otras comisiones.

Históricamente, las empresas han confiado en
reglas de fuerza bruta para prever y bloquear cargos sospechosos de fraude. Sin embargo, estas reglas codificadas de forma rígida (por ejemplo, el bloqueo de todas las tarjetas de crédito utilizadas en el extranjero), pueden resultar en el bloqueo de transacciones legítimas. Por otro lado, el uso de machine learning permite detectar patrones más sutiles, contribuyendo a maximizar los ingresos. En términos de machine learning, un falso negativo es cuando el sistema ignora algo que debió haber detectado, como una transacción fraudulenta. Un falso positivo, por otro lado, sucede cuando el sistema identifica algo que no debió haber identificado (por ejemplo, el bloqueo de un cliente legítimo). Antes de conocer más detalles sobre el machine learning, es importante entender las compensaciones que implica.

En el caso de los falsos negativos, las empresas suelen asumir la responsabilidad del pago del monto original de la transacción, junto con las comisiones asociadas al contracargo (los costos asociados a la reversión por parte del banco del pago de la tarjeta), comisiones de la red más altas, como consecuencia de la disputa y mayores costos operativos, debido a la revisión de cargos o la defensa en disputas. Además, si acumulas un número significativo de disputas, es posible que termines envuelto en un programa de monitoreo de contracargos de la red, lo cual puede generar mayores costos o, en algunos casos, la incapacidad de aceptar pagos con tarjeta.

En cuanto a los falsos positivos, o pagos legítimos rechazados, se dan cuando un cliente legítimo intenta realizar una compra, pero se le impide hacerlo. Estos rechazos pueden afectar tanto los ingresos brutos de la empresa como su reputación. Según una encuesta reciente, el 33 % de los consumidores dijo que no volvería a comprar en una empresa después de experimentar un pago rechazado.

Existe un equilibrio delicado entre evitar más disputas (falsos negativos) y reducir el bloqueo de clientes legítimos (falsos positivos): cuantas menos disputas tengas, mayor será la probabilidad de tolerar rechazos injustos de clientes legítimos, y viceversa. Al evitar más fraudes, aumenta la posibilidad de bloquear buenos clientes; por otro lado, al reducir la cantidad de falsos positivos, se incrementa la probabilidad de dejar pasar fraudes genuinos. Las empresas deben tomar decisiones estratégicas para encontrar un equilibrio entre ambos extremos, considerando factores como sus márgenes, perfil de crecimiento y otros elementos.

Estas situaciones donde los márgenes de una empresa son estrechos, por ejemplo el caso de la venta en línea de alimentos, el costo de una transacción fraudulenta podría requerir compensarse con cientos de transacciones legítimas, esto hace que cada falso negativo sea muy costoso. En este contexto, las empresas podrían optar por implementar medidas más amplias para prevenir posibles fraudes. Por otro lado, en empresas con márgenes elevados, como las compañías de SaaS, la pérdida de ingresos por bloquear un cliente legítimo podría ser suficiente para cubrir el costo asociado con un aumento en el fraude.

Stripe Radar y la red de Stripe

Radar es la solución de prevención de fraude de Stripe que protege las empresas contra el fraude que se comete en línea con las tarjetas de crédito. Este sistema se basa en el machine learning adaptativo, fruto de años de trabajo realizado por los exclusivos equipos de machine learning de Stripe, que se centran en la infraestructura y la ciencia de datos. Los algoritmos de Radar evalúan el riesgo de fraude de cada transacción y toman medidas correspondientes, bloqueando aquellos pagos de puntuación elevada de riesgo están bloqueados. Además, Radar for Fraud Teams ofrece herramientas para que los usuarios puedan especificar cuándo se deben tomar acciones adicionales.

Cada año, Stripe procesa cientos de miles de millones de pagos procedentes de millones de empresas e interactúa con miles de bancos asociados de todo el mundo. Esta escala le permite identificar señales y patrones de fraude mucho antes que las redes más pequeñas. Los datos recopilados de todas las transacciones de Stripe respecto del fraude, que se obtienen automáticamente por medio del flujo de pagos, se utilizan con el fin de mejorar nuestra capacidad para detectar el fraude. Señales como el país en el cual se emitió la tarjeta o la dirección IP desde la cual se efectuó el pago ofrecen información valiosa que contribuye a prevenir la probabilidad de fraude en un pago.

Los encuentros previos con una tarjeta de toda la red de Stripe también ofrecen una importante cantidad de datos para aportar información a nuestras evaluaciones de riesgo. Más del 90 % de las tarjetas que se utilizan en la red de Stripe se han analizado más de una vez, lo que brinda información valiosa para determinar si los datos asociados a esas tarjetas se utilizan de manera legítima o fraudulenta. Este enfoque integral basado en datos permite a Stripe mejorar constantemente sus capacidades de prevención del fraude.

Otra ventaja fundamental del machine learning es que Radar se desarrolló directamente como parte integral de Stripe y está listo para usar. En contraste, muchas otras soluciones de prevención de fraude requieren inversiones considerables, tanto constantes como anticipadas. En primer lugar, las empresas deben realizar una integración con el producto de prevención del fraude, lo que implica trabajos de ingeniería para enviar datos relacionados con eventos y los pagos relevantes. En segundo lugar, deben completar una integración para aprobar las etiquetas de pago, indicando si una transacción fue fraudulenta, proporcionadas por el procesador de pagos al proveedor de la solución contra el fraude. Alternativamente, las empresas pueden etiquetar manualmente los pagos, una tarea que puede requerir de mucho tiempo y aumentar la probabilidad de cometer errores. En cambio, Radar recibe información que contiene la «verdad fundamental» directamente desde el flujo habitual de pagos de Stripe y accede a datos precisos y oportunos directamente de los emisores y las redes de tarjetas. No se necesita programación adicional ni tiempo dedicado a tareas de ingeniería para su implementación.

Ahora, profundicemos en el uso del machine learning y cómo lo usamos en Stripe.

Conceptos básicos del machine learning

El machine learning abarca un conjunto de técnicas que involucran la adquisición de grandes cantidades de datos con el fin de utilizarlos para crear modelos predictivos, como la probabilidad de que un cargo resulte en una disputa por fraude.

Una de las aplicaciones principales del machine learning es la predicción. El objetivo es anticipar el valor de alguna variable de salida en función de ciertos valores de entrada. En nuestro caso, el valor de salida es verdadero si el pago es fraudulento y falso si no lo es (esos valores binarios se conocen como booleanos). Además, un ejemplo del valor de entrada podría ser el país en que se emitió la tarjeta o la cantidad de países diferentes en los cuales se utilizó la tarjeta en toda la red de Stripe el día anterior. La forma en que realizamos estas predicciones se basa en ejemplos previos de datos de entrada y salida.

Los datos utilizados para entrenar (o generar) los modelos consisten en registros (que suelen obtenerse de datos históricos). Estos registros contienen tanto el valor de salida como los diferentes valores de entrada, tal como se pueden observar en el siguiente ejemplo (de manera simplificada):

Si bien hay solo tres entradas en este ejemplo, en la práctica del machine learning, los modelos suelen tener cientos o miles de entradas. La salida del algoritmo del machine learning podría ser un modelo como el árbol de decisiones que se muestra a continuación:

Cuando observamos una nueva transacción, analizamos los valores de entrada y nos desplazamos por el árbol utilizando un "estilo de 20 preguntas" hasta que lleguemos a una de sus "hojas". Cada hoja incluye la totalidad de las muestras del conjunto de datos (la tabla que se muestra anteriormente) que responde a los pares de pregunta-respuesta que aparecen a lo largo del recorrido que seguimos al bajar por el árbol. Además, la probabilidad de que pensemos que la nueva transacción es fraudulenta se refiere a la cantidad de muestras fraudulentas que tiene la hoja dividida por la cantidad total de muestras que incluye dicha hoja. En otras palabras, el árbol responde la pregunta: "dentro de las en nuestro conjunto de datos que comparten propiedades similares a la transacción que estamos evaluando, ¿qué parte resultó ser fraudulenta?». La esencia del machine learning radica en la construcción del árbol: ¿qué preguntas hacemos y en qué orden para maximizar las probabilidades de que podamos distinguir entre dos clases? Aunque los árboles de decisiones son fácilmente visualizables y analizables, existen diversos algoritmos de aprendizaje, cada uno son su forma única de representar las relaciones para crear modelos.

En la actualidad, predominan los modelos de machine learning y están detrás de muchos de los productos con los que interactuamos diariamente. Estos modelos suelen ser mucho más sofisticados que el ejemplo mencionado anteriormente:

• Google emplea machine learning en su motor de búsqueda para proporcionar sugerencias de escritura mediante la función "¿Quisiste decir?". Este sistema es capaz de representar modelos de millones de parámetros relacionados con los idiomas en menos de tres segundos.
  
• Amazon utiliza el machine learning en su sistema de recomendación, que anticipa la compras según en las necesidades, preferencias y comportamientos cambiantes de los usuarios en toda su plataforma. Este sistema funciona incluso para nuevos usuarios que no cuentan con datos históricos.
  

En el contexto de este debate, es fundamental destacar que el machine learning es la base angular de Stripe Radar, que busca predecir qué pagos son propensos a ser fraudulentos.

¿Cómo funciona el machine learning?

Los cursos académicos de machine learning suelen centrarse en el proceso de creación de modelos. Se centran en métodos para transformar datos (como la tabla mencionada anteriormente) en modelos (como el árbol de decisiones). También exploran algoritmos que te informan cómo asignar valores de entrada (como el país de emisión de la tarjeta o la cantidad de países utilizados) a valores de salida (¿la transacción fue fraudulenta o no?). El proceso que toma la tabla de datos de entradas y elabora el "mejor" árbol es un ejemplo específico de un método de machine learning. La creación de modelos implica varios pasos, dependiendo de la naturaleza de los datos y los modelos seleccionados. Aunque no profundizaremos en el tema, incluimos un resumen preciso a continuación.

En el proceso de machine learning, el primer paso es obtener datos de entrenamiento. Antes de comenzar a detectar el fraude automáticamente, necesitamos tener un conjunto de datos con ejemplos de transacciones fraudulentas. Por cada ejemplo, es necesario que hayamos registrado (o poder calcular de forma retrospectiva) una variedad de propiedades de entrada que podrían ser útiles para realizar predicciones futuras sobre el valor de salida. Estas propiedades de entradas se denominan características, y la recopilación conjunta de entradas para una determinada muestra es un vector de características. En nuestro ejemplo anterior, el vector tuvo la longitud de tres características (el país en el cual se emitió la tarjeta, la cantidad de países en los cuales se utilizó la tarjeta el día anterior y el importe del pago en USD).

Es común trabajar con vectores de características que tienen cientos de miles de elementos. De hecho, Radar utiliza cientos de características muchas de las cuales se calculan considerando toda la red de Stripe. A medida que crece el tamaño de la red, cada característica se vuelve más informativa, ya que nuestros datos de entrenamiento se vuelven más representativos del conjunto total de datos de la característica, incluidos los datos que no pertenecen a Stripe. El valor de salida (en nuestro ejemplo actual, el booleano que indica si la transacción fue fraudulenta o no) se suele denominar objetivo o etiqueta. Por lo tanto, los datos de entrenamiento consisten en una gran cantidad de vectores de características y sus valores de salida correspondientes.

En el siguiente paso es necesario entrenar modelo. Dados los datos de entrenamiento, necesitamos tener un método para elaborar un modelo predictivo. En general, los clasificadores de machine learning no producen solo una etiqueta de clase; suelen asignar probabilidades en relación con la probabilidad de que la muestra dada pertenezca a cada clase posible. Por ejemplo, la salida de un clasificador de fraude podría consistir en la evaluación respecto de que el pago tiene un 65 % de probabilidad de ser fraudulento y un 35 % de probabilidad de ser legítimo.

Existen muchas técnicas de machine learning que se pueden usar para formar modelos. En el caso de la mayoría de las aplicaciones de machine learning industrial, los enfoques tradicionales como la regresión lineal, los árboles de decisiones o los bosques aleatorios sirven perfectamente.

Sin embargo, las técnicas sofisticadas, como las redes neurales y el aprendizaje profundo, inspiradas en la arquitectura de neuronas del cerebro, han logrado avances significativos en el campo. Esto incluye predicciones como las del modelo de AlphaFold, que alcanzó el 98 % de precisión en la predicción de todas las proteínas humanas. Las ventajas reales de las redes neurales solo se obtienen cuando se forman en función de grupos de datos muy grandes. En la práctica, muchas empresas pueden tener limitaciones para aprovechar completamente estas técnicas avanzadas. Sin embargo, dada la extensión de nuestra red, Stripe puede implementar estos enfoques más innovadores para ofrecer resultados significativos a nuestros usuarios. Nuestros nuevos modelos han mejorado el rendimiento del machine learning en Radar en un 20 % de un año al otro, lo que nos ayuda a detectar más situaciones de fraude al tiempo que se mantienen bajos los falsos positivos.

Ingeniería de características

La ingeniería de características es una de las partes más importantes del machine learning industrial y consta de dos componentes:
(1) la formulación de características que tienen valor predictivo en función del amplio conocimiento para solucionar el problema y (2) las tareas de ingeniería para poner los valores de esas características a disposición de la formación de modelos y la evaluación de los modelos que están en un entorno de "producción".

En la formulación de características, el científico de datos de Stripe puede utilizar la intuición para determinar la utilidad de una característica, como en el caso en que se analiza si el pago con tarjeta proviene de una dirección IP que es habitual para esa tarjeta. Por ejemplo, los pagos realizados desde direcciones IP previamente consultadas, como el hogar o el lugar de trabajo del titular de la tarjeta, pueden ser menos propensos a ser fraudulentos en comparación con aquellos originados desde un estado diferente. Aunque esta idea puede surgir de la intuición, en general, se respalda mediante el análisis de miles de casos de fraude. De manera sorprendente, factores como el cálculo de la diferencia horaria entre el dispositivo del usuario y la hora universal coordinada (UTC) o la cantidad de países en los cuales se autorizó correctamente la tarjeta, también pueden contribuir significativamente a la detección del fraude.

Una vez que tengamos identificada la idea de la característica, es necesario calcular sus valores históricos para poder entrenar un nuevo modelo que incluya dicha característica. Esto implica agregar una nueva columna a la "tabla" de datos que usamos para elaborar nuestro modelo. En el caso de la característica propuesta, que implica calcular las dos direcciones IP más frecuentes desde las cuales se realizaron los pagos anteriores con la tarjeta en el historial de Stripe, este proceso puede realizarse de manera distribuida utilizando una herramienta como Hadoop. Sin embargo, es posible que este trabajo se perciba como que requiere mucho tiempo (o memoria). Una alternativa sería optimizar el cálculo mediante el uso de una estructura de datos de probabilidad que permita ahorrar espacio. Incluso para características que parecen intuitivamente sencillas, la producción de datos para la formación de modelos requiere flujos de trabajo establecidos y una infraestructura dedicada.

Es importante destacar que no todas las características pueden ser creadas por ingenieros; algunas de ellas se pueden dejar para que el modelo realice el cálculo con pruebas posteriores antes de su implementación. Las características categóricas, como el país de origen de una tarjeta o el comercio que procesó una transacción (a diferencia de las características numéricas), son ejemplos que han demostrado ser valiosos en este enfoque. Estas características suelen tener un amplio rango de valores, y la definición de una representación correcta puede resultar desafiante.

En Stripe, formamos a nuestros modelos para que conozcan la integración de cada comercio en función de los patrones de transacciones. Cuando hablamos de integración, nos referimos a las coordinadas del comercio individual en comparación con los demás. Con frecuencia, comerciaos similares tendrán integraciones similares (según se miden con la distancia del coseno), lo cual permite al modelo transferir el aprendizaje de un comercio al otro. La tabla que aparece a continuación muestra cómo podrían ser estas integraciones, ya que es probable que Uber y Lyft sean más similares entre sí que con Slack. En Stripe, usamos integraciones para diversas características categóricas, como el banco emisor, el país del comercio y del usuario, el día de la semana, entre otras.

El uso de integraciones es cada vez más común en las aplicaciones industriales de machine learning de gran escala. Las integraciones de palabras, como las utilizadas para captar complejas relaciones semánticas entre las palabras, han sido incluidas en objetivos de procesamiento del lenguaje natural como Word2Vec, BERT y GPT-3. En Stripe, producimos integraciones para captar relaciones de similitud entre las diferentes entidades de la red de Stripe de la misma manera en que los métodos descritos anteriormente captan similitudes entre las palabras. Las integraciones son una excelente forma de aprender los conceptos de nivel superior sin capacitación explícita. Por ejemplo, los patrones de fraude suelen distribuirse geográficamente de forma desigual. Gracias a las integraciones, si el sistema identifica un nuevo patrón de fraude en Brasil, puede identificar automáticamente el mismo patrón en caso de que aparezca en los Estados Unidos sin necesidad de capacitación adicional. De esta manera, los avances en los logaritmos ayudan a anticiparse a los cambios en los patrones de fraude, lo cual protege a los clientes.

Evaluación de los modelos de machine learning

Después de desarrollar un clasificador de machine learning para el fraude que utiliza cientos de características y asigna una probabilidad (o puntuación) de que el pago es fraudulento para cada transacción entrante, es crucial evaluar la eficacia del modelo para detectar el fraude.

Condiciones clave

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

Comencemos por suponer que hemos creado una política para bloquear un pago si el modelo de machine learning le asigna a la transacción una cierta probabilidad de fraude de, al menos, 0.7. (expresado como as P(fraude)>0.7). A continuación, incluimos algunas cantidades que resultan útil para reflexionar sobre el rendimiento de nuestro modelo y política:

• Precisión: la precisión de nuestra política se refiere a la fracción de transacciones que bloqueamos y que son, en realidad, fraudulentas. Cuanto mayor sea la precisión, menos serán los falsos positivos. Por ejemplo, de 10 transacciones, P(fraude)>0.7 para seis y, de esas seis, cuatro son fraudulentas en realidad. Por lo tanto, la precisión es 4/6=0.66.

• Recuperación: la recuperación, también conocida como la tasa de verdaderos positivos o sensibilidad, es la fracción de todas las transacciones fraudulentas que capta nuestra política; es decir, la fracción de fraude para la cual P(fraude)>0.7. Cuanto mayor sea la recuperación, menos serán los falsos negativos. Por ejemplo, de 10 transacciones, cinco son fraudulentas en realidad. Si nuestro modelo les asigna a cuatro de estas transacciones un P(fraude)>0.7, la recuperación es 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 política bloquea de forma incorrecta. Por ejemplo, de 10 transacciones, cinco son legítimas. Si nuestro modelo les asigna a dos de estas transacciones un P(fraude)>0.7, la tasa de falsos positivos es 2/5=0.4.

Si bien existen otras cantidades que se utilizan al momento de evaluar los clasificadores, nos centraremos en estas tres.

Curvas ROC y de recuperación y precisión

La siguiente pregunta natural se refiere a cuáles son los valores correctos en lo relativo a la precisión, la recuperación y la tasa de falsos positivos. En un mundo teóricamente ideal, la precisión sería de 1 (es decir, el 100 % de las transacciones que clasificas como fraudulentas en realidad lo son), lo que daría como resultado una tasa de falsos positivos de 0 (no clasificaste ninguna transacción legítima individual como fraudulenta). Además, la recuperación también sería de 1 (el 100 % de las transacciones fraudulentas se identifican de esa manera).

En realidad, existe una compensación entre la precisión y la recuperación. A medida que el umbral de probabilidad para el bloqueo aumenta, la precisión aumentará (dado que el criterio para el bloqueo es más estricto) y la recuperación disminuirá (dado que una menor cantidad de transacciones cumple con el criterio de alta probabilidad). Para un determinado modelo, la curva de recuperación y precisión capta la compensación que existe entre la precisión y la recuperación, dado que el umbral de la política es variado:

A medida que nuestro modelo mejora en términos generales, debido a la capacitación con más y más datos de toda la red de Stripe, la incorporación de características que permiten predecir correctamente el fraude y el ajuste de otros parámetros de modelos, la curva de recuperación y precisión cambiará, tal como se muestra en el ejemplo anterior. A medida que controla la compensación para las empresas en Stripe, supervisamos atentamente el impacto que se genera en la curva de recuperación y precisión cuando nuestros científicos de datos e ingenieros de machine learning modifican los modelos.

Al momento de considerar el gráfico de recuperación y precisión, resulta importante distinguir entre las dos nociones de "rendimiento". Por sí solo, un modelo es mejor en términos generales cuanto más cerca se encuentre del margen superior derecho del gráfico (es decir, cuando la precisión y la recuperación sean de 1). Sin embargo, el hecho de poner en funcionamiento un modelo suele requerir la selección de un punto operativo en la curva de recuperación y precisión (en nuestro caso, el umbral de la política para bloquear una transacción), que controla el impacto en concreto que el uso del modelo genera para una empresa.

En otras palabras, existen dos problemas:

• El problema de la ciencia de datos de producir un modelo correcto de machine learning mediante la incorporación de las características correctas. El modelo controla la forma de la curva de recuperación y precisión.

• El problema de una empresa de elegir una política para decidir cuántas transacciones posiblemente fraudulentas se deben bloquear. La política controla dónde estamos operando en la curva.

Otra curva que se analiza al momento de evaluar un modelo de machine learning es la curva ROC. (ROC consiste en la abreviatura de «característica operativa del receptor», una reliquia del origen de la curva en las aplicaciones de procesamiento de señales). La curva ROC es una representación de la tasa de falsos positivos (en el eje x) y la tasa de verdaderos positivos (que es la misma que la recuperación) en el eje y para los diferentes valores del umbral de la política.

La ROC ideal se acercará al margen superior izquierdo del gráfico (cuando la recuperación es de 1 y la tasa de falsos positivos es de 0). Además, a medida que el modelo mejora, la ROC se desplazará más en esa dirección. Una forma de captar la calidad general del modelo es mediante el cálculo del área que se encuentra debajo de la curva (o AUC); en un caso ideal, el AUC será de 1. Al momento de desarrollar los modelos, analizamos cómo cambian la curva de recuperación y precisión, la curva ROC y el AUC.

Distribuciones de puntuaciones

Supongamos que contamos con un modelo que asigna al azar a una transacción una cierta probabilidad de fraude de entre 0 y 1. Prácticamente, este modelo no hace nada para diferenciar las transacciones legítimas de las fraudulentas. Además, lo usamos muy poco. La distribución de la puntuación del modelo (la fracción de las transacciones que toma cada posible puntuación) capta esta aleatoriedad. En un caso completamente aleatorio, la distribución de la puntuación sería casi uniforme:

El modelo tendrá una distribución de puntuación uniforme como la anterior si, por ejemplo, dicho modelo no incluye características que incluso predigan el fraude remotamente. A medida que el modelo mejora, al agregarle características predictivas, capacitación con más datos, entre otras cosas, la capacidad que tiene para diferenciar entre las clases fraudulentas y legítimas aumentará, y la distribución de puntuación se volverá más bimodal, con picos que rondarán las puntuaciones de 0 y 1.

Por sí misma, la distribución bimodal no te informa que un modelo es correcto. (Un modelo vacío que asigna al azar probabilidades de solo 0 y 1 también tendría una distribución de puntuación bimodal). Sin embargo, ante la presencia de evidencia respecto de que las transacciones con puntuación baja no son fraudulentas y de que las transacciones con puntuación alta son fraudulentas, la distribución cada vez más bimodal es una señal de la eficacia mejorada de un modelo.

Con frecuencia, los diferentes modelos tendrán distintas distribuciones de puntuaciones. Cuando lanzamos nuevos modelos, comparamos las antiguas distribuciones con las actualizadas a fin de minimizar los cambios disruptivos que provoca una modificación repentina en las puntuaciones. En particular, tomamos en cuenta las políticas actuales de bloqueo de los comerciantes, según se miden con el umbral a partir del cual dichos comerciantes bloquean las transacciones. Además, nuestro objetivo es mantener estable la proporción de las transacciones por debajo del umbral.

Cálculo de la precisión y la recuperación

Podemos calcular la métrica anterior en dos contextos diferentes: durante la capacitación sobre modelos, mediante el uso de datos históricos que impulsen el proceso de desarrollo de modelos, y después de la implementación de modelos, mediante el uso de datos de producción; es decir, datos del mundo cuando el modelo ya se utiliza para tomar medidas mediante, por ejemplo, el bloqueo de transacciones en los casos en que P(fraude)>0.7.

En el primer caso, en general, los científicos de datos obtendrán los datos sobre capacitación que tienen (nos referimos a la tabla anterior) y asignarán al azar alguna parte de los registros a un conjunto sobre capacitación y los demás registros a un conjunto de validación. Podríamos suponer que el primer 80 % de las filas se incluye en el primer caso y el último 20 % en el segundo caso, por ejemplo.

El conjunto sobre capacitación consiste en los datos que se incorporan a un método de machine learning para producir un modelo tal como se describió anteriormente. Una vez que tengamos un modelo candidato, podemos usarlo para asignar puntuaciones a cada muestra del conjunto de validación. Las puntuaciones del conjunto de validación con sus valores de salida se utilizan para procesar las curvas ROC y de recuperación y precisión, las distribuciones de puntuaciones, etc. El motivo por el cual usamos un conjunto de validación por separado que se obtiene del conjunto de capacitación consiste en que el modelo ya "vio la respuesta" para sus ejemplos de capacitación y obtuvo información a partir de estas respuestas. El conjunto de validación nos ayuda a generar métricas que consisten en medidas precisas de la potencia predictiva del modelo respecto de los datos nuevos.

Implementación segura y eficiente de modelos de machine learning

Una vez que hemos demostrado que el rendimiento del modelo supera al del actual en un conjunto de datos de prueba, el siguiente paso es llevarlo a la producción. Sin embargo, este proceso enfrenta dos retos clave:

• Cálculos en tiempo real: debemos poder calcular el valor de cada característica para cada pago nuevo que se realice en tiempo real porque queremos ser capaces de bloquear todas las transacciones que nuestro clasificador considere como probablemente fraudulentas. Este cálculo es totalmente independiente del que se utilizó para producir los datos sobre capacitación. Mantener un estado actualizado de las dos direcciones IP más frecuentemente utilizadas por cada tarjeta procesada en Stripe es fundamental. Además, la obtención y la actualización de estos recuentos deben ser rápidas porque esas operaciones se realizan como parte del flujo de las API de Stripe. Los equipos de infraestructura de machine learning de Stripe han facilitado este cálculo al crear sistemas para especificar características de modo declarativo y proporcionar automáticamente los valores actuales de las características en tiempo real durante la etapa de producción con baja latencia.

• Aplicación del modelo en el mundo real: La implementación de un modelo de machine learning es diferente de la implementación de un código. Mientras que los cambios de código suelen validarse con casos de pruebas precisas, los cambios de modelo suelen probarse con grandes conjuntos de datos agrupados mediante el uso de métricas como las que definimos anteriormente. Sin embargo, es posible que un modelo que sea mejor para detectar el fraude de forma agrupada no sea mejor para todos los usuarios de Stripe. Es posible que la mejora en el rendimiento se distribuya de forma despareja. En ese caso, unos pocos grandes comercios obtendrán importantes ganancias, mientras que muchos pequeños comercios verán pequeñas regresiones. Además, un modelo puede tener una recuperación superior pero causar un aumento en la tasa de bloqueo, lo cual sería perjudicial para las empresas (y sus clientes). Antes de lanzar un modelo, verificamos que tenga buen rendimiento en la práctica. Para hacer eso, medimos el cambio que provocaría cada modelo según una variedad de métricas, como la tasa de falsos positivos, la tasa de bloqueo y la tasa de autorización de forma agrupada y en función de cada comercio respecto de un subconjunto de usuarios de Stripe. Si determinamos que un nuevo modelo causaría un cambio indeseable en una de esas métricas de contención, lo ajustamos para los diferentes subconjuntos de usuarios antes de lanzarlo a fin de minimizar las interrupciones y garantizar un óptimo rendimiento.

En nuestra búsqueda de eficiencia, hemos automatizado el proceso de capacitación y evaluación de modelos, brindando beneficios significativos a la velocidad de iteración. Durante el último año, invertimos en la creación de herramientas para capacitar, ajustar y evaluar los modelos con nuestras características y arquitectura de modelos más recientes. Por ejemplo, actualizamos continuamente los dashboards de rendimiento después de que se forma un modelo y antes de su lanzamiento. De esta manera, un ingeniero puede detectar con facilidad si un candidato modelo se ha vuelto obsoleto respecto de un subconjunto de tráfico incluso antes de su lanzamiento. En ese caso, podrá volver a formarlo de forma proactiva.

Después de lanzar un modelo, monitoreamos continuamente su rendimiento y nos preparamos para el próximo lanzamiento. Dada la rápida evolución de las tendencias de fraude, los modelos de machine learning experimentan un desplazamiento, ya que los datos sobre los cuales se capacitaron ya no representan las transacciones actuales de la actualidad.

Gracias a las herramientas implementadas, triplicamos la velocidad a la cual lanzamos los modelos, generando ganancias sustanciales de rendimiento en la producción. Incluso realizar la recapacitación de un modelo del último mes a partir de datos más recientes (mediante el uso de las mismas definiciones y arquitectura de funcionalidades) y relanzarlo nos permiten aumentar la recuperación medio punto porcentual cada mes. La capacidad de lanzar modelos frecuentemente y de manera segura nos permite capitalizar y combinar las ganancias del trabajo de creación de modelos y la ingeniería de características, adaptándonos a los cambiantes patrones de fraude.

Una vez que ponemos un modelo en producción, controlamos continuamente el rendimiento de nuestro par de modelo y política. En el caso de los pagos que tienen puntuaciones que están por debajo del umbral de bloqueo, podemos observar los resultados finales, como si el titular de tarjeta disputó la transacción como fraudulenta. Sin embargo, para los pagos bloqueados, no podemos conocer los resultados potenciales. Por lo tanto, el cálculo de la curva ROC o la curva de recuperación y precisión de producción total es más importante que las curvas de validación, ya que implica un análisis hipotético. En Stripe desarrollamos métodos efectivos a lo largo de los años para realizar estos cálculos estadísticamente significativos, y puedes obtener más información al respecto en esta conversación.

Hemos abordado algunas medidas clave que los científicos de datos y los ingenieros de machine learning consideran al desarrollar modelos de prevención de fraudes. A continuación, profundizaremos en cómo las empresas deben abordar la prevención de fraudes y cómo Stripe puede ser un aliado efectivo en este aspecto.

¿Cómo puede ayudar Stripe?

Fijar un solo número para identificar el rendimiento respecto a la prevención del fraude podría derivar en la toma de decisiones que no son óptimas para la empresa. En muchas ocasiones, las empresas pueden exagerar los falsos negativos (les preocupa mucho el fraude que no detectan) y subestimar los falsos positivos. Esto a menudo conduce a la aplicación de medidas de fuerza bruta costosas e ineficaces, como el bloquear todas las tarjetas internacionales. En general, es crucial considerar la relación entre diferentes medidas de rendimiento y encontrar compensaciones adecuadas según las condiciones particulares de tu empresa. A continuación, incluimos un ejemplo de cómo estas métricas se unen para ayudarte a determinar la eficacia del sistema de prevención de fraude:

EJEMPLO DE MODELO DE UMBRAL DE RENTABILIDAD

Supongamos que tu venta promedio es de $26 con un margen del 8 %, su ganancia por venta es de $26.00 × 8 % = $2.08. En promedio, si la producción del producto cuesta $26.00 – $2.08 = $23.92 y se les cobra una comisión por contracargo de $15, su pérdida total por una venta fraudulenta es de $23.92 + $15.00 = $38.92. Por lo tanto, una venta fraudulenta les cuesta la ganancia de $38.92/$2.08 = 18.71 ventas legítimas, y tu umbral de rentabilidad es de 1/(1 + 18.71) = 5.07 %.

Los umbrales de machine learning de Radar tienen en cuenta la optimización de los márgenes de los comercios y el mantenimiento de tasas de bloqueo estables en toda la base de usuarios. Puedes acceder al Dashboard para ver el rendimiento del machine learning de Radar específicamente de tu empresa, comparando tasas de disputa por fraude, tasas de falsos positivos y tasas de bloqueo con otras empresas que tienen similares verticales o tamaños a los tuyos. Esto te permiten evaluar el rendimiento de manera más precisa y ajustar tu estrategia según tus necesidades específicas y el contexto del mercado.

Mejora del rendimiento con revisiones manuales y reglas

Gracias a Radar for Fraud Teams, puedes ajustar a la perfección tu protección. Para ello, modifica directamente el umbral de riesgo a fin de bloquear o permitir la realización de más pagos. Junto con los algoritmos de machine learning más automáticos, Radar for Fraud Teams también permite a las empresas individuales crear reglas personalizadas (por ejemplo, bloquear todas las transacciones que superen los $1000 cuando el país de la dirección IP no coincida con el país de la tarjeta), solicitar intervenciones y revisar manualmente los pagos identificados en el Dashboard.

Esas reglas pueden considerarse como simples "modelos" (pueden representarse como árboles de decisión, después de todo). Además, deben evaluarse de la misma manera que los modelos, con total consideración de la compensación que existe entre la precisión y la recuperación. Al momento de crear una regla con Radar, te presentamos estadísticas históricas sobre las transacciones similares que fueron disputadas, reembolsadas o aceptadas. Esto te brinda información valiosa antes de implementar una regla. Una vez activada, puedes monitorear el impacto de cada regla en las tasas de falsos positivos y disputas.

Es importante destacar que estas reglas, intervenciones y revisiones manuales ofrecen a los usuarios la posibilidad de influir en la forma de la curva de precisión y recuperación. Esto se logra al incorporar la lógica específica y patentada de la empresa a través de las reglas, o al realizar esfuerzos adicionales mediante revisiones manuales.

Si observas que los algoritmos de machine learning a menudo no detectan un tipo específico de fraude que tu empresa puede identificar fácilmente, puedes crear una regla para bloquearlo. En general, esa intervención específica aumentará la recuperación con bajo costo respecto de la precisión, moviendo así el punto operativo a lo largo de una curva de recuperación y precisión más favorable y menos extrema.

Al enviar algunas clases de transacciones a revisión manual en lugar del bloqueo inmediato, puedes mejorar la precisión sin afectar la recuperación. De modo similar, al enviar algunas transacciones a revisión manual en lugar de probarlas de inmediato, puedes aumentar la recuperación sin sacrificar la precisión.
Es importante tener en cuenta que en estos casos, estás pagando por esas ganancias con trabajo humano adicional (y te expones a la precisión de las evaluaciones de tu equipo). Sin embargo, contar con revisiones manuales, reglas e intervenciones para autenticar los clientes de riesgo alto como herramientas adicionales te brinda otro factor para optimizar los resultados respecto del fraude.

Próximos pasos

Esperamos que esta guía te haya ayudado a comprender cómo se aplica el machine learning a la prevención de fraude en Stripe y cómo medir la eficacia de los sistemas antifraude. Puedes obtener más información sobre las características de Radar o consultar nuestra documentación.

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