La reciente y masiva aceleración del e-commerce creó un aumento correspondiente en el fraude de pagos electrónicos. En todo el mundo, el fraude les cuesta a las empresas un estimado de más de 20 mil millones de dólares estadounidenses anuales. Además, por cada dólar perdido por el fraude, el costo total para las empresas es en realidad mucho más alto debido al aumento de los costos operativos, las tarifas de la red y la pérdida de clientes.

El fraude no solo es costoso, sino que los/las estafadores/as sofisticados/as encuentran constantemente nuevas formas de explotar las debilidades, lo que hace que combatir el fraude sea desafiante. Es por eso que creamos Stripe Radar, una solución de prevención de fraude basada en el machine learning, totalmente integrada en la plataforma Stripe. El machine learning de Radar aprovecha los datos de cientos de miles de millones de dólares estadounidenses en pagos procesados en la red de Stripe cada año para detectar con precisión el fraude y adaptarse rápidamente a las últimas tendencias, lo que te permite crecer sin aumentar el fraude.

Esta guía presenta Stripe Radar y muestra cómo aprovechamos la red de Stripe para detectar fraudes; proporciona un resumen de las técnicas de machine learning que utilizamos; explica nuestro pensamiento sobre la eficacia y el rendimiento de los sistemas de detección de fraudes, y describe cómo otras herramientas del conjunto de Radar pueden ayudar a las empresas a optimizar su rendimiento frente al fraude.

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

Un pago se considera fraudulento cuando el o la titular de tarjeta no autoriza el cargo. Por ejemplo, si un estafador o estafadora realiza una compra con un número de tarjeta robado que no se denunció, es posible que el pago se procese correctamente. Luego, cuando el o la titular de tarjeta descubra el uso fraudulento de la tarjeta, cuestionará el pago con su banco presentando una disputa (también conocida como «contracargo»).

Las empresas pueden impugnar un contracargo presentando evidencia que demuestre que el pago fue válido. Sin embargo, para las transacciones sin tarjeta presente, si las redes consideran que el pago fue verdaderamente fraudulento, el o la titular de tarjeta ganará y la empresa será responsable de la pérdida de bienes y otros cargos.

Históricamente, las empresas utilizaban reglas de fuerza bruta para predecir y bloquear presuntos cargos fraudulentos. Sin embargo, las reglas codificadas de forma rígida, por ejemplo, el bloqueo de todas las tarjetas de crédito utilizadas en el extranjero, pueden causar el bloqueo de muchas transacciones legítimas. El machine learning, por otro lado, puede detectar patrones más matizados para ayudarte a maximizar los ingresos. En la jerga del machine learning, un falso negativo es cuando el sistema pasa por alto un evento para el que está diseñado para detectar, en este caso, una transacción fraudulenta. Un falso positivo es cuando el sistema marca algo que no debería, por ejemplo, bloquear a un cliente legítimo. Antes de entrar en los detalles del machine learning, es importante comprender las compensaciones involucradas.

Con los falsos negativos, las empresas a menudo son responsables del importe de la transacción original más las comisiones de contracargo (el costo asociado con el banco que revierte el pago con tarjeta), comisiones de red más altas como resultado de la disputa y costos operativos más altos por la revisión de cargos o la resolución de disputas. Además, si incurres en demasiadas disputas, podrías terminar en un programa de monitoreo de devoluciones de cargo de la red, lo que puede generar costos más altos o, en algunos casos, la imposibilidad de aceptar pagos con tarjeta.

Los falsos positivos, o los pagos rechazados falsos, se dan cuando un o una cliente legítimo/a intenta realizar una compra, pero se le impide hacerlo. Los pagos rechazados falsos pueden hacer que la empresa se vea afectada tanto en las ganancias brutas como en la reputación. De hecho, en una encuesta reciente, el 33 % de los consumidores y las consumidoras dijeron que no volverían a comprar en un negocio después de un pago rechazado falso.

Existe una compensación entre evitar más disputas (falsos negativos) y reducir el bloqueo de clientes legítimos/as (falsos positivos): cuanto menos tengas de los primeros, más tendrás que tolerar los segundos (y viceversa). Cuando evites más fraudes, aumentará la cantidad de clientes legítimos/as bloqueados/as. Por otro lado, reducir el número de falsos positivos a menudo aumenta la probabilidad de que se escapen más fraudes reales. Las empresas deben decidir cómo equilibrar los dos en función de sus márgenes, perfil de crecimiento y otros factores.

Si los márgenes de una empresa son pequeños (por ejemplo, si vende alimentos en línea), es posible que el costo de una transacción fraudulenta deba compensarse con cientos de transacciones legítimas, lo que hace que cada falso negativo sea muy costoso. Las empresas con este perfil pueden inclinarse por lanzar una red amplia cuando intentan detener un posible fraude. Por otro lado, si los márgenes de una empresa son altos, por ejemplo, para una empresa de SaaS (Software como Servicio), ocurre lo contrario. La pérdida de ingresos de un o una cliente legítimo/a bloqueado/a puede compensar el costo del aumento del fraude.

Stripe Radar y la red de Stripe

Radar es la solución de prevención de fraude de Stripe que protege las empresas contra el fraude que se comete en línea con las tarjetas de crédito. Su desarrollo se debe al machine learning adaptativo, que resulta de años de trabajo realizado por los exclusivos equipos de machine learning de Stripe en cuanto a la infraestructura y la ciencia de datos. Los algoritmos de Radar evalúan el riesgo de fraude de cada transacción y toman las medidas que correspondan. Los pagos de puntuación alta están bloqueados. Además, Radar para Equipos de Fraude ofrece herramientas para que los usuarios puedan especificar cuándo se deben tomar otras medidas.

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 significa que, con frecuencia, podemos ver señales y patrones 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 a 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 valiosa información al momento de predecir la probabilidad de que el pago sea fraudulento.

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. El noventa por ciento de las tarjetas que se utilizan en la red de Stripe se ha analizado más de una vez, lo cual nos brinda datos mucho más valiosos para realizar evaluaciones respecto de si esos datos se utilizan de forma legítima o fraudulenta.

Otra ventaja clave respecto del machine learning consiste en que Radar se desarrolló directamente como parte de Stripe y está listo para usar. En general, otras soluciones de prevención de fraude requieren una cantidad sustancial de inversiones constantes y anticipadas. En primer lugar, las empresas deben integrarse con el producto de fraude. Esto implica trabajo de ingeniería para enviar datos sobre los eventos y los pagos pertinentes. En segundo lugar, las empresas deben completar una integración para aprobar las etiquetas de pago (categorización que indica si la transacción fue fraudulenta) que proporciona el procesador de pagos al proveedor de soluciones contra el fraude o deben etiquetar los pagos por sí mismas de forma manual, lo cual puede requerir de mucho tiempo o generar mayor probabilidad de cometer errores. Por otro lado, 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 requiere programación ni tiempo dedicado a tareas de ingeniería.

Analicemos en profundidad el machine learning y cómo lo usamos en Stripe.

Conceptos básicos del machine learning

El machine learning se refiere a un grupo de técnicas para obtener grandes cantidades de datos con el fin de usar esos datos para producir modelos que predigan resultados, como la probabilidad de que un cargo derive en una disputa por fraude.

Una de las principales aplicaciones del machine learning es la predicción: Queremos predecir 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 denominan 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. Determinamos cómo hacer una predicción en función de los ejemplos anteriores de datos de entrada y salida.

Los datos utilizados para formar (o generar) los modelos consisten en registros (que suelen obtenerse de datos históricos) tanto con el valor de salida como con los diferentes valores de entrada, tal como se pueden observar en el siguiente ejemplo (muy simplificado):

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 con «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, «De las transacciones incluidas en nuestro conjunto de datos que tienen propiedades similares a la transacción que estamos analizando en este momento, ¿qué parte fue fraudulenta en realidad?». La parte del machine learning tiene que ver con la elaboración del árbol: ¿qué preguntas hacemos y en qué orden para maximizar las probabilidades de que podamos distinguir entre dos clases con precisión? Los árboles de decisiones son especialmente fáciles de visualizar y de analizar. Sin embargo, existen muchos algoritmos de aprendizaje diferentes, cada uno de los cuales incluye su propia forma exclusiva de representar las relaciones con las que intentamos crear modelos.

En la actualidad, predominan los modelos de machine learning, los cuales permiten desarrollar, en segundo plano, muchos de los productos con los que solemos trabajar. Además, en general, esos modelos son mucho más sofisticados que el modelo de muestra que aparece más arriba:

• Google proporciona sugerencias de escritura con la función «¿Quisiste decir?» en el motor de búsqueda que utiliza el machine learning para representar modelos de millones de parámetros relacionados con los idiomas en menos de tres segundos.
  
• Amazon utiliza el machine learning para predecir las compras con su sistema de recomendación basado en las necesidades, las preferencias y los comportamientos cambiantes de los usuarios en toda su plataforma, incluso en el caso de los nuevos usuarios que no cuentan con datos históricos.
  

Además, lo que resulta más importante para este debate es que el machine learning es la base para Stripe Radar, que busca predecir cuáles de los pagos son fraudulentos.

¿Cómo funciona el machine learning?

Los cursos académicos de machine learning suelen centrarse en el proceso de creación de modelos: los métodos para convertir los datos (por ejemplo, la tabla anterior) en modelos (por ejemplo, el árbol de decisiones) y para saber cuáles son los algoritmos que te informan cómo los valores de entrada (el país en el cual se emitió la tarjeta, la cantidad de países en los cuales se utilizó esa tarjeta, etc.) se asignan a valores de salida (¿la transacción fue fraudulenta o no?). El proceso que toma la anterior tabla de datos de entradas y elabora el «mejor» árbol es un ejemplo de un método de machine learning en concreto. La creación de modelos involucra la realización de varios pasos, que dependen de la naturaleza de los datos y los modelos que optaste por utilizar Si bien no profundizaremos en el tema, incluimos un resumen de gran precisión a continuación.

En primer lugar, debemos obtener datos de capacitación. Antes de que podamos comenzar a detectar el fraude automáticamente, necesitamos tener un conjunto de datos con ejemplos de ello. 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 funcionalidades. La recopilación conjunta de entradas para una determinada muestra es un vector de funcionalidad. En nuestro ejemplo anterior, el vector tuvo la longitud de tres funcionalidades (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).

Sin embargo, los vectores de funcionalidades con cientos o miles de funcionalidades son habituales. De hecho, Radar utiliza cientos de funcionalidades, y la mayoría de ellas consisten en grupos que se calculan considerando toda la red de Stripe. A medida que crece el tamaño de la red, cada funcionalidad se vuelve más informativa porque nuestros datos de capacitación se vuelven más representativos del conjunto total de datos de la funcionalidad, incluidos los datos que no pertenecen a Stripe. El valor de salida (en nuestro ejemplo actual, el booleano respecto de si la transacción era fraudulenta o no) se suele denominar objetivo o etiqueta. Por lo tanto, los datos de capacitación consisten en una gran cantidad de vectores de funcionalidades y sus valores de salida correspondientes.

En segundo lugar, debemos formar un modelo. Dados los datos de capacitación, 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 respecto de que la muestra dada pertenece 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, es decir, las redes neurales y el aprendizaje profundo, inspiradas en la arquitectura de neuronas del cerebro, son responsables de muchos avances logrados en el campo, incluidas las predicciones de AlphaFold del 98 % 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. Por lo tanto, en la práctica, muchas empresas no pueden aprovecharlas en su totalidad. Dado el tamaño de nuestra red, Stripe puede implementar este enfoque más vanguardista para ofrecer resultados reales a nuestros usuarios. Nuestros nuevos modelos han mejorado el rendimiento del machine learning de Radar en un 20 % de un año al otro, lo que nos ayuda a detectar más situaciones de fraude mientras se mantienen bajos los falsos positivos.

Ingeniería de funcionalidades

Una de las partes más importantes del machine learning industrial es la ingeniería de funcionalidades. La ingeniería de funcionalidades consiste en dos partes:
(1) la formulación de funcionalidades 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 funcionalidades a disposición de la formación de modelos y la evaluación de los modelos que están en «producción».

En la formulación de funcionalidades, es posible que el científico de datos de Stripe sienta la intuición que le dice que una funcionalidad es útil si permite determinar que el pago con tarjeta proviene de una dirección IP que es habitual para esa tarjeta. Por ejemplo, a diferencia de lo que sucede cuando la dirección IP proviene de un estado diferente, es menos probable que el pago con tarjeta que se origina de direcciones IP que fueron consultadas anteriormente (como la conectividad en el hogar o el lugar de trabajo del titular de tarjeta) sea fraudulento. En este caso, la idea es intuitiva. Sin embargo, en general, esta intuición se siente lugar de analizar miles de casos de fraude. Por ejemplo, es posible que te sorprenda saber que el cálculo de la diferencia que existe entre la hora del dispositivo del usuario y la hora universal coordinada (UTC) actual o la cantidad de países en los cuales se autorizó correctamente la tarjeta contribuye a detectar el fraude.

Una vez que tengamos la idea de la funcionalidad, tenemos que calcular sus valores históricos para que podamos formar un nuevo modelo, incluida la funcionalidad. Se trata del proceso de agregar una nueva columna a la «tabla» de datos que usamos para elaborar nuestro modelo. A fin de hacer esto para la funcionalidad candidata, respecto de cada pago que figura en el historial de Stripe, debemos calcular las dos direcciones IP más frecuentes desde las cuales se realizaron los pagos precedentes con la tarjeta. Podríamos hacer esto de forma distribuida con un trabajo de Hadoop, aunque, incluso, es posible que consideremos que el trabajo requiere de mucho tiempo (o memoria). Podríamos intentar optimizar el cálculo mediante el uso de una estructura de datos de probabilidad que permite ahorrar espacio. Incluso en el caso de funcionalidades que son intuitivamente sencillas, la producción de datos para la formación de modelos requiere exclusivos flujos de trabajo establecidos y de infraestructura.

Los ingenieros no pueden crear todas las funcionalidades; algunas de ellas se pueden dejar para que el modelo realice el cálculo con pruebas posteriores antes de su implementación. Los valores categóricos, como el país de origen de una tarjeta o el comerciante que procesó una transacción (en oposición a las funcionalidades numéricas) aportaron mucho a este enfoque. Estas funcionalidades suelen tener un amplio rango de valores. Además, la definición de una correcta representación de ellas puede resultar desafiante.

En Stripe, formamos a nuestros modelos para que conozcan la integración de cada comerciante en función de los patrones de transacciones. Si hablamos de integración, podemos pensar en las coordinadas del comerciante individual en comparación con los demás. Con frecuencia, comerciantes similares tendrán integraciones similares (según se miden con la distancia del coseno), lo cual permite al modelo transferir el aprendizaje de un comerciante al otro. La tabla que aparece a continuación muestra cómo deben verse estas integraciones, dado que es probable que Uber y Lyft sean más similares uno a otro que respecto de Slack. En Stripe, usamos integraciones para una variedad de funcionalidades categóricas, como el banco emisor, el país del comerciante y del usuario, el día de la semana, entre otras.

El uso de integraciones es cada vez más habitual en las aplicaciones industriales de machine learning de gran escala. Las integraciones de palabras como estas, por ejemplo, ayudan a captar las complejas relaciones semánticas que existen entre las palabras. Además, se han incluido en metas de procesamiento del idioma natural como Word2Vec, BERT y GPT-3. Stripe produce integraciones para captar relaciones de similitud entre las diferentes entidades de la red de Stripe de la misma manera en que los métodos descriptos 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 despareja. 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 ninguna otra capacitación. 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

Una vez que hayamos desarrollado un clasificador de machine learning respecto del fraude que utilice cientos de funcionalidades y asigne una cierta probabilidad (o puntuación) de que el pago es fraudulento para cada transacción entrante, debemos determinar 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. (Escribimos esto 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, que también se conoce 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 funcionalidades 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 funcionalidades 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 funcionalidades que incluso predigan el fraude remotamente. A medida que el modelo mejora, al agregarle funcionalidades 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.

Operaciones de machine learning: implementación de modelos de manera segura y frecuente

Una vez que el rendimiento del modelo se haya mostrado para superar el modelo de producción actual en un conjunto extraído, el paso siguiente consiste en implementarlo en la producción. Existen dos retos clave de este proceso:

• Cálculos en tiempo real: Debemos poder calcular el valor de cada funcionalidad 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. Debemos mantener un estado actualizado respecto de las dos direcciones IP más frecuentemente utilizadas por cada tarjeta que se procesó en Stripe. 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 funcionalidades de modo declarativo y al poner a disposición los valores actuales de las funcionalidades automáticamente en la etapa de producción con baja latencia.

• Aplicación del usuario 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 comerciantes obtendrán importantes ganancias, mientras que muchos pequeños comerciantes verán pequeñas regresiones. Es posible que un modelo tenga una recuperación superior pero cause 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 comerciante 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.

Llegamos a la conclusión de que, en la mayor medida de lo posible, la automatización del proceso de capacitación y evaluación proporciona beneficios compuestos a la velocidad de iteración de los modelos. Durante el año pasado, invertimos en la creación de herramientas para capacitar, ajustar y evaluar los modelos con nuestras funcionalidades 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, controlamos su rendimiento y comenzamos a trabajar en el próximo lanzamiento. Dado que las tendencias del fraude cambian con rapidez, los modelos de machine learning comienzan rápidamente a experimentar el desplazamiento: Los datos sobre los cuales se capacitaron ya no representan las transacciones actuales de la actualidad.

Al utilizar estas herramientas, triplicamos la velocidad a la cual lanzamos los modelos, lo cual se traduce directamente en la obtención de grandes ganancias de rendimiento en la producción. De hecho, incluso 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 el relanzamiento de ese modelo nos permiten aumentar la recuperación medio punto porcentual todos los meses. Poder lanzar modelos con frecuencia y de manera segura nos permite capitalizar y combinar las ganancias del trabajo de creación de modelos e ingeniería de funcionalidades y adaptarnos a los cambiantes patrones de fraude que corresponden a los usuarios de Radar.

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: ¿el titular de tarjeta disputó la transacción como fraudulenta? No obstante, los pagos que tienen puntuaciones que están por encima del umbral están bloqueados. Por lo tanto, no podemos saber cuáles hubieran sido los resultados. En consecuencia, el cálculo de la curva ROC o de recuperación y precisión de producción total es más importante que las curvas de validación porque involucra el análisis contrafáctico. Debemos obtener cálculos estadísticamente efectivos de lo que hubiera ocurrido incluso con los pagos que bloqueamos. Con el correr de los años, Stripe ha desarrollado métodos para hacer esto. Puedes obtener más información sobre ello en esta conversación.

Acabamos de describir unas pocas medidas de la eficacia de los modelos que los científicos de datos y los ingenieros de machine learning observan cuando desarrollan modelos de machine learning. A continuación, hablaremos de cómo las empresas deben pensar en relación con la prevención de fraude.

Cómo puede ayudar Stripe

La fijación de solo un número para identificar el rendimiento respecto del fraude podría derivar en la toma de decisiones que no son óptimas para la empresa. Concluimos que, con frecuencia, las empresas exagerarán los falsos negativos (les preocupa mucho el fraude que no detectan) y subestimarán los falsos positivos. Esta mentalidad suele derivar en la aplicación de medidas de fuerza bruta que resultan ser ineficaces y costosas, como el bloqueo de todas las tarjetas internacionales. En general, deberías pensar cómo se relacionan las diferentes medidas de rendimiento y cuáles son las compensaciones correctas, dadas 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:

MODELO APROXIMADO DE UMBRAL DE RENTABILIDAD

Si su 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 compensan la optimización de los márgenes de los comerciantes y el hecho de mantener las tasas de bloqueo estables en toda nuestra base de usuarios. Puedes acceder al Dashboard para ver el rendimiento del machine learning de Radar respecto de tu empresa y el rendimiento de las reglas personalizadas si utilizas Radar para Equipos de Fraude. Estas herramientas te permiten comparar con facilidad las tasas de disputa por fraude, las tasas de falsos positivos y las tasas de bloqueo con las mismas tasas de otras empresas similares en función de las cohortes personalizadas y agrupadas de las empresas que tienen similares verticales o tamaños a los tuyos.

Mejora del rendimiento con revisiones manuales y reglas

Gracias a Radar para Equipos de Fraude, puedes ajustar a la perfección tu protección. Para ello, ajusta 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 para Equipos de Fraude 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, presentaremos estadísticas históricas respecto de la cantidad de transacciones coincidentes que en realidad fueron disputadas, reembolsadas o aceptadas para recibir ayuda a partir de estos cálculos y antes de que la regla incluso se implemente. Una vez que esté activa, puedes ver el impacto que genera cada regla sobre las tasas de falsos positivos y disputas.

Con la misma importancia, las reglas, las intervenciones y las revisiones manuales permiten a los usuarios cambiar la forma de la curva de precisión y recuperación a su favor al incorporar la lógica patentada y específica de la empresa (reglas) o al realizar esfuerzos adicionales (revisión manual).

Si te das cuenta de que, con frecuencia, a los algoritmos de machine learning les falta un cierto tipo de fraude específico de tu empresa (y que puedes identificar el fraude con facilidad), 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, lo cual moverá el punto operativo a lo largo de una curva de recuperación y precisión más favorable y menos excesiva.

Al enviar algunas clases de transacciones a revisión manual en lugar del bloqueo inmediato, puedes ganar precisión sin incurrir a la recuperación. De modo similar, al enviar algunas transacciones a revisión manual en lugar de su aprobación inmediata, puedes ganar recuperación sin incurrir a la precisión.
Por supuesto, 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 ayude 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 de fraude. Puedes obtener más información sobre las funcionalidades de Radar o consultar nuestra documentación.

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