Para evaluar el riesgo de fraude, es necesario aplicar un proceso continuo capaz de identificar situaciones, tendencias y vectores de ataque y mitigarlos. Gracias a una estrecha colaboración con los usuarios, nuestro equipo de servicios profesionales ha observado que en las empresas que aplican dicho proceso con más eficacia los analistas de fraude y los analistas de datos suelen trabajar juntos, combinando Stripe Radar for Fraud Teams y productos de Stripe Data, como Stripe Sigma o Stripe Data Pipeline, con la intención de identificar tendencias de fraude comunes y específicas en su negocio.

Radar for Fraud Teams ayuda a detectar y prevenir el fraude y te permite crear una estrategia antifraude a medida y exclusiva para tu negocio, con reglas personalizadas, informes y revisiones manuales. Sigma es una solución para elaboración de informes que ofrece datos sobre transacciones, conversiones y clientes en un entorno interactivo en el Dashboard de Stripe. Data Pipeline proporciona la misma información, pero la envía automáticamente al almacén de datos de Snowflake o Redshift para que puedas acceder a ella a la vez que consultas otros datos sobre tu negocio.

La combinación de estas herramientas resulta ideal para los cuatro pilares de un proceso efectivo de gestión del fraude, que son la detección, la investigación, la confirmación y la mejora y mitigación, y que trataremos con mayor detalle.

La importancia de utilizar Radar for Fraud Teams con Sigma o Data Pipeline

El objetivo principal de usar Radar for Fraud Teams con Sigma o Data Pipeline es analizar la información de Radar, como los metadatos, aparte de tus propios datos (incluidas la autorización previa, la trayectoria del usuario, la conversión y la información sobre la sesión), a fin de diferenciar las transacciones legítimas de comportamientos fraudulentos de clientes. De esta forma, puedes optimizar lo siguiente:

1. Tiempo para obtener información con la intención de detectar y prevenir el fraude de forma proactiva
   
2. Tiempo de reacción para crear reglas de prevención y detección
   
3. Coste del fraude, que engloba los reembolsos, las comisiones por disputas, el abandono de los clientes y los pagos rechazados por el emisor
   

En nuestro informe La situación del fraude por Internet se destaca la sobrecarga operativa que plantean los procesos manuales de revisión y que «cuanto más grandes son [las empresas], menor es la fracción de transacciones que revisan». Gracias a la automatización de estos procesos, puedes aliviar la carga a los analistas de fraude para que puedan dedicar más tiempo a identificar nuevos vectores de ataque y a desarrollar reglas de prevención y detección. Así te resultará más fácil encontrar un equilibrio entre bloquear el tráfico fraudulento y reducir los inconvenientes que sufran clientes legítimos (abandono).

Un proceso básico para gestionar el fraude en las transacciones

Supongamos que, en tu estrategia de riesgo general, utilizas un proceso básico para gestionar el fraude en las transacciones basado en la detección, la investigación, la confirmación y la mejora y mitigación.

• La detección, conocida también como identificación, predicción o respuesta a incidentes, consiste en detectar datos concretos que justifiquen una investigación más exhaustiva. Puede ser manual (por ejemplo, durante un incidente), semiautomática (con reglas de detección o mediante la supervisión de la línea de base), automática (con machine learning o detección de anomalías) o externa (por ejemplo, por disputas o comentarios de los clientes). Durante la detección, el machine learning de Radar puede detectar automáticamente tendencias de fraude comunes, mientras que Sigma puede ayudarte a identificar tendencias específicas en tu negocio.
  
• La investigación, también conocida como análisis de inspección, consiste en evaluar pagos o comportamientos sospechosos para tener una idea más clara de la repercusión en el negocio; suele requerir una verificación con respecto a otros datos para descartar lo que no proceda. Los analistas de fraude normalmente usarán la cola de revisiones de Radar o el Dashboard de pagos de Stripe para investigar.
  
• La confirmación, conocida también como modelización o backtesting, consiste en la generalización del vector de ataque de fraude verificado en dimensiones y modelos candidatos. También engloba la validación y evaluación del impacto usando datos anteriores y otras reglas. La funcionalidad de simulación y backtesting de Radar puede ayudar a los analistas de fraude en esta fase, pero los ingenieros pueden usar Sigma para muchas otras situaciones.
  
• La mejora y mitigación, una fase para la que también se usan los términos acción o aislamiento, consiste en implementar el modelo, mediante la aplicación de dimensiones y funciones importantes en los predicados de las reglas de Radar para prevenir, supervisar o redirigir el fraude. Antes se hablaría de reglas de prevención estáticas, pero ahora que el machine learning es un complemento importante para los humanos y el objetivo es aumentar la precisión, el término más apropiado es «mejora». Esto normalmente comprendería reglas de bloqueo o listas en Radar.
  

Una implementación básica de este proceso podría englobar ciclos iterativos, como comprobaciones diarias, sprints o distintas versiones de una estrategia de detección de fraude basada en reglas. Sin embargo, dado que las duraciones de los ciclos pueden variar y que se pueden recibir comentarios al mismo tiempo, preferimos tratarlo como un proceso continuo.

A continuación, analizaremos los detalles de cada uno de estos cuatro pilares en un escenario hipotético y te mostraremos cómo Radar for Fraud Teams y Sigma o Data Pipeline pueden ayudarte.

Nuestro escenario

En nuestro escenario hipotético, analizaremos el comportamiento durante un periodo de tiempo, en comparación con un pico repentino.

Supongamos que tienes un negocio de e-commerce. La supervisión de webhooks está configurada en tu solución de observación que crea varios gráficos de las tendencias de pago en tiempo real. Has observado un aumento constante del volumen de pagos rechazados de una marca de tarjeta llamada «Mallory» durante los últimos días para un producto que normalmente no se vende en la región donde suele utilizarse dicha tarjeta. (Nota: Mallory es una marca de tarjeta ficticia que utilizamos para presentar este escenario; por ejemplo, podría ser una marca que no pertenece a Enhanced Issuer Network). No hay promociones de ventas ni otros incidentes que justifiquen este cambio, así que tu equipo debe investigar el motivo y decidir qué medidas aplicar.

Detección

Las reglas predeterminadas de Stripe usan el machine learning para predecir, detectar y bloquear un número elevado de pagos fraudulentos. El Dashboard de análisis de Radar puede ofrecerte un breve resumen de las tendencias de fraude. Y para las empresas que necesitan controlar mejor qué pagos deben revisar, aceptar o bloquear, las reglas son una herramienta eficaz para personalizar la protección antifraude.

Para poder empezar a detectar las nuevas tendencias de fraude, primero debes tener una línea de base de señales predictivas, como la eficacia de las reglas existentes. En otras palabras, debes saber qué parece «normal» para tu negocio o cómo debería ser una transacción «legítima». Este es el motivo por el que los analistas de fraude y los ingenieros de datos trabajan juntos (también pueden colaborar con los equipos de operaciones de desarrollo y su solución de observación). En nuestra situación hipotética, gracias a una supervisión continua, se detecta un aumento de las transacciones rechazadas efectuadas con tarjetas «Mallory».

Tablas de Sigma con datos relevantes sobre fraude

Para detectar nuevas tendencias, primero debes establecer un rendimiento de referencia con funciones como la tasa de autorización y de pagos rechazados por el emisor y la tasa de bloqueos de Radar. A continuación, consulta las disputas por fraude, las alertas de fraude preventivas (Expedientes de fraude del emisor) y las transacciones de pago con una alta velocidad, un número elevado de rechazos del emisor o altas puntuaciones de riesgo de Radar. Lo ideal es que programes esta consulta para que se ejecute diariamente en función de los datos disponibles y que se muestren todos los paneles con los datos anteriores, incluidos los cortes semanales y mensuales, sin tener siquiera que consultar manualmente Sigma ni tu almacén de datos. Así reducirás los tiempos de respuesta a incidentes.

Estas son las tablas más destacadas:

Tus analistas de fraude o del negocio deben tener una idea de qué dimensiones desglosadas adicionales es conveniente evaluar en función del dominio de tu empresa. La tabla de atributos de reglas de Radar de Radar for Fraud Teams tiene información detallada sobre las transacciones que ha evaluado Radar, pero su historial empieza en abril de 2023 y no tiene metadatos ni resultados finales. Antes, consultarías estos campos:

La nueva tabla de atributos de reglas de Radar hace un seguimiento de las mismas dimensiones (y de muchas más) de cada transacción que Radar ha evaluado con el nombre exacto de los atributos de Radar. Por ejemplo, puedes hacer un seguimiento de tendencias de velocidad como name_count_for_card_weekly.

Las tendencias se pueden ver de formas diferentes, pero un sencillo gráfico de líneas dinámico con información desglosada resulta apropiado para comparar fácilmente con otros factores. Cuando profundices en la fase de investigación, puedes combinar distintos datos desglosados. Esta es una tabla de ejemplo en la que se muestran los datos desglosados por segmento de producto en relación con el aumento de las transacciones rechazadas efectuadas con tarjetas «Mallory»:

Puedes verla así en tu herramienta de hojas de cálculo preferida:

Vamos a analizar el ejemplo de una consulta de Sigma o Data Pipeline para obtener datos de referencia. En la consulta siguiente, verás las tasas diarias de disputas, pagos rechazados y bloqueos, entre otras, como columnas independientes. Durante la detección e investigación, suele resultar más fácil visualizar datos más amplios y dispersos en columnas independientes. También facilita la aplicación posterior de columnas en los predicados de Radar. Sin embargo, puede que tus científicos de datos prefieran un formato grande y denso para el análisis pormenorizado durante la investigación, o bien el machine learning en las fases de confirmación y mejora y mitigación.

En este ejemplo, incluimos metadatos sobre el pago para mostrar un desglose por segmento de producto. En un enfoque amplio, necesitaríamos consultas similares para la marca de tarjeta («Mallory») y el tipo de financiación, según nuestro escenario. Aquí eliminamos los reintentos duplicados para centrarnos en las intenciones reales y hacernos una mejor idea de la magnitud. Optamos por eliminar las duplicaciones en función de las intenciones de pago —las integraciones más profundas pueden enviar un campo (por ejemplo, un identificador de pedido, en metadatos) para garantizar la eliminación de duplicaciones durante la trayectoria del usuario—. En este ejemplo, se muestra cómo puedes aumentar la precisión de tus medidas antifraude con la adición de otro factor. En nuestro escenario, sería el segmento de producto «tarjetas regalo». Más adelante, en la sección sobre mejora y mitigación, volveremos a hablar sobre las formas de aumentar la precisión.

Esta consulta no incluye el momento real de la disputa, que es un indicador retrasado, pero incluimos algunos indicadores de ejemplo, como los reintentos como un indicador de prueba de tarjetas. En esta consulta, obtenemos algunas métricas diarias de forma sencilla:

• El volumen de cargos, con la eliminación de duplicaciones y el valor bruto: por ejemplo, 1150 cargos al día, de los cuales Radar rechaza 100 y bloquea 50, con 1000 intenciones de pago.
  
• Tasa de autorización: en este ejemplo, el 90 % corresponde a los cargos, porque los pagos bloqueados no llegan al emisor, y el 100 % a las intenciones de pago, porque al final se reintentaron con éxito.
  
• Alto riesgo y tasa de bloqueos: en este caso, ambos serían el 1,6 % (los 50 de riesgo alto también se bloquearon).
  
• Tasa de disputas retrospectivas para los pagos durante el mismo período: por ejemplo, se disputaron 5 de 1000 cargos. El número por día de pago aumentará cuando surjan más disputas; por lo tanto, incluimos el tiempo de ejecución de la consulta para realizar un seguimiento del cambio.
  

Como hemos comentado antes, hemos simplificado estas consultas para facilitar la lectura. En realidad, esta consulta tendría aún más dimensiones; por ejemplo, tendencias, desviaciones o diferencias de pérdidas.

También hemos incluido un ejemplo de un promedio de rotación de 30 días usando una función de ventana. Se pueden adoptar enfoques más complejos, como analizar los percentiles en lugar de los promedios, para identificar ataques de amplio alcance, pero no suelen ser necesarios para la detección inicial del fraude, ya que las tendencias generales son más importantes que unas cifras exactas.

Una vez que conozcas la línea de base, puedes empezar a realizar un seguimiento de las anomalías y las tendencias para investigarlas; por ejemplo, un aumento de la tasa de fraude o de bloqueos de un país o método de pago concreto (en nuestro escenario hipotético, sería la marca de tarjeta «Mallory»). Las anomalías suelen investigarse con informes o análisis manuales en el Dashboard o con consultas ad hoc en Sigma.

Investigación

En cuanto tus analistas detecten una anomalía que haya que investigar, el siguiente paso es consultar en Sigma, o bien en el almacén de datos a través de Data Pipeline, para explorar los datos y crear una hipótesis. Debes incluir algunas dimensiones desglosadas en función de tus hipótesis, como métodos de pago (uso de tarjetas), canal o plataforma (metadatos), cliente (reputación) o productos (categoría de riesgo), que tengan tendencia al fraude. Después, en la fase de confirmación, puedes utilizar el término «funciones» para hacer referencia a dichas dimensiones. Se aplicarán a los predicados de Radar.

Volvamos a nuestra hipótesis, en la que un gran volumen de transacciones con tarjetas prepago «Mallory» tienen tasas de fraude más altas, que puedes representar como una dimensión de agrupación en la que basarte con la herramienta de análisis. En esta fase, la consulta suele iterarse y adaptarse, por lo que resulta conveniente incluir varios candidatos a predicado como versiones reducidas o ampliadas de las hipótesis, eliminando funciones de menor importancia, para medir su impacto. Por ejemplo:

Este enfoque te dará una idea de la magnitud para priorizar el impacto. En la tabla se muestra con una confianza razonable que la regla candidata 3 parece detectar el exceso de transacciones malintencionadas. Una evaluación más sofisticada se basaría en la exactitud, la precisión o la exhaustividad. Puedes crear un resultado como este con la consulta siguiente.

En esta consulta, hemos eliminado las duplicaciones para facilitar la lectura, pero hemos incluido la tasa de disputas y la tasa de alertas preventivas de fraude, que son importantes para los programas de supervisión de marcas de tarjetas. Sin embargo, son indicadores atrasados y, en esta consulta simplificada, solo les realizamos un seguimiento retroactivo. También incluimos ejemplos de pagos arbitrarios para realizar una comparación y una investigación más exhaustiva de las tendencias identificadas en la consulta; hablaremos de esto más adelante.

Es conveniente que desgloses otras métricas en un histograma para identificar grupos, que pueden resultar útiles para definir reglas de velocidad que puedes usar para limitar la velocidad (por ejemplo, total_charges_per customer_hourly).

Identificar tendencias con el análisis de un histograma es ideal para entender el comportamiento deseado del cliente durante toda su trayectoria y en el embudo de conversión. Incorporar esto a la consulta anterior podría ser complicado, pero este es un ejemplo sencillo de cómo desglosarlo sin una lógica de ventana de rotación compleja, asumiendo que tienes un tipo de cliente en los metadatos (por ejemplo, usuarios invitados):

En nuestro escenario, puede que no quieras bloquear todas las tarjetas prepago «Mallory», pero sí identificar otros factores de riesgo correlacionados. Esta consulta de velocidad puede mejorar la confianza, por ejemplo, para evitar bloquear a clientes invitados poco frecuentes.

Una forma sencilla de investigar esto consistiría en ver los ejemplos directamente en el Dashboard a través de la vista «Pagos relacionados» para entender el comportamiento —es decir, el vector de ataque o la tendencia de fraude— y los informes de riesgo de Radar asociados. Por eso hemos incluido los ejemplos de pagos arbitrarios en la consulta anterior. De esta forma también puedes encontrar pagos más recientes que aún no están disponibles en Sigma. Una forma más defensiva y con un mayor grado de interacción consistiría en modelar tu hipótesis como una regla de revisión que siga aceptando los pagos pero que los remita a tus analistas para que los revisen manualmente. Algunos clientes lo hacen para plantearse el reembolso de los pagos por debajo de la comisión por disputas, bloqueando aquellos que están por encima.

Confirmación

A partir de ahora, vamos a suponer que la tendencia que has identificado no es sencilla, que no se puede mitigar con el reembolso y el bloqueo del cliente fraudulento y que no se encuentra en una lista de bloqueos predeterminada.

Después de identificar y priorizar una nueva tendencia que haya que abordar, debes analizar su impacto potencial en tus ingresos legítimos. No se trata de un problema de optimización trivial, porque la tasa óptima de fraude no es cero. Entre todos los modelos candidatos, elige el que represente la mejor compensación por tu tolerancia al riesgo, ya sea en función de una magnitud sencilla o por precisión y exhaustividad. Este proceso a veces se denomina backtesting, sobre todo cuando las reglas se redactan primero y luego se validan con tus datos. (También puedes hacerlo al contrario, es decir, identificar primero las tendencias y redactar después las reglas). Por ejemplo, en lugar de redactar una regla por país, escribe una regla como esta que facilite la confirmación:

Block if :card_funding: = 'prepaid and :card_country: in @preaid_card_countries_to_block

La consulta presentada anteriormente en la sección de investigación también puede usarse como modelo, pero se destacarían diferentes valores. Hablaremos de esto más adelante cuando tratemos las técnicas de mejora y mitigación.

Esquema de Sigma para la asignación de reglas de Radar

Es el momento de traducir las consultas de análisis de Sigma o Data Pipeline para ayudarte a aplicar las reglas de Radar a Sigma para el backtesting. Estas son algunas aplicaciones comunes, suponiendo que estás enviando las señales correctas a Radar:

Los dos últimos elementos, risk_level y risk_score, no son como los otros, ya que el propio modelo de machine learning deriva de los demás factores. En lugar de escribir reglas demasiado complejas, te recomendamos que confíes en el machine learning de Radar; hablaremos más al respecto en la sección Mejora mediante machine learning.

La nueva tabla de atributos de reglas de Radar hace un seguimiento de las mismas dimensiones (y de muchas más) de cada transacción que Radar ha evaluado realmente con el nombre exacto de los atributos de Radar.

En la tabla anterior se muestra el conjunto habitual de atributos y se omiten deliberadamente las señales que personalizarías para la trayectoria del cliente, como las sesiones de Radar o los metadatos.

Según la investigación anterior, supongamos que creas una regla parecida a esta:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :amount_in_usd: > 20 and ::CustomerType:: = 'guest' and :total_charges_per_customer_hourly: > 2

El siguiente paso es confirmar el impacto de esta regla en las transacciones de pagos reales. Por lo general, lo harías con reglas de bloqueo. Consulta nuestra guía Radar for Fraud Teams: Reglas 101 para saber cómo escribir la sintaxis correcta de las reglas. Una forma sencilla de probar una regla de bloqueo es crearla en modo de prueba y crear pagos de prueba manuales para confirmar que funciona según lo previsto.

Se puede hacer un backtesting de las reglas de bloqueo y revisión en Radar mediante la función de simulación de Radar for Fraud Teams.

Una ventaja de utilizar las simulaciones de Radar for Fraud Teams es que tienen en cuenta el impacto de otras reglas existentes. Esta guía no se centra en el mantenimiento de reglas, pero la eliminación y actualización de reglas también deben formar parte de tu proceso de mejora continua. En términos generales, el número de reglas debe ser lo suficientemente bajo para que cada regla sea atómica y se pueda supervisar con las consultas de referencia desarrolladas en las fases de detección e investigación y se haga un backtesting claramente, sin el riesgo de efectos colaterales (por ejemplo, la regla 2 solo funciona porque la regla 1 filtra otra cosa).

También puedes hacerlo usando reglas de revisión en lugar de reglas de bloqueo, algo que trataremos en la siguiente sección.

Mejora y mitigación

Por último, después de probar las reglas de bloqueo, aplica el modelo para prevenir, supervisar y redirigir el fraude. Esto lo denominamos mejora, porque trata de aumentar la precisión de las medidas antifraude generales, en particular de forma conjunta con el machine learning. Para aumentar la precisión, puedes implementar diferentes técnicas. A veces, este paso, que también puede denominarse contención o mitigación, se realiza al mismo tiempo que la confirmación, donde en lugar de usar reglas de revisión, pruebas A/B (metadatos) o simulaciones para evaluar tu modelo, bloqueas inmediatamente los cargos sospechosos para mitigar el riesgo inmediato.

Aunque ya hayas actuado, hay algunas técnicas que puedes usar para mejorar el modelo desarrollado en los pasos 1 a 3 para optimizar los resultados con el tiempo:

Mejora con reglas de revisión

Si no quieres correr el riesgo de tener una tasa de falsos positivos más alta, que puede afectar a tus ingresos, puedes optar por implementar reglas de revisión. Aunque se trata de un proceso más manual que puede dificultar la experiencia del cliente, las reglas de revisión pueden permitir más transacciones legítimas. (También puedes añadir limitaciones, en forma de reglas de velocidad, en las reglas de bloqueo existentes para transacciones más lentas). Una opción más avanzada para usar las reglas de revisión son las pruebas A/B, que son especialmente útiles para gestionar el número total de casos en la cola de revisión. Puedes utilizar metadatos de los pagos para empezar a aceptar una pequeña cantidad de tráfico mientras se realizan las pruebas A/B, por ejemplo, de clientes conocidos o usando simplemente un número aleatorio. Recomendamos incorporar esto a las reglas de bloqueo en lugar de crear reglas de admisibilidad, ya que estas últimas anularán los bloqueos y, por tanto, dificultarán el seguimiento de la eficacia de la regla de bloqueo con el tiempo.

Optimización de reglas mediante la supervisión de su eficacia

Para supervisar la eficacia de la regla, puedes comprobar el objeto de resultados del cargo en la API Payment Intents, en particular el objeto de la regla. De forma similar, en Sigma puedes usar los campos charges.outcome_rule_id, charges.outcome_type y payment_intents.review_id para el análisis. Este es un ejemplo de cómo supervisar la eficacia de una regla en Sigma con la tabla de decisiones de reglas de Radar especial:

Mejora mediante machine learning

A menudo, el siguiente paso después de bloquear un ataque inmediato es mejorar de forma iterativa la regla en combinación con el machine learning para reducir los falsos positivos, permitiendo que haya más tráfico legítimo y, por tanto, más ingresos.

Tenemos, por ejemplo, el bloqueo del BIN o IIN (número de identificación del emisor). Durante un ataque de prueba de tarjetas, puede que hayas agregado temporalmente un BIN a la lista de bloqueos, por lo que el emisor tiene tiempo para reparar las fisuras. Sin embargo, bloquear directamente a un emisor podría reducir tus ingresos; lo más conveniente es realizar un análisis más minucioso con el tiempo y mejorar el modelo. Es un buen momento para revisar cómo redactar reglas eficaces y cómo evaluar el riesgo, en particular la puntuación de riesgo de Radar. En general, te recomendamos que combines el machine learning de Radar con tu intuición. En lugar de tener una sola regla para bloquear todas las transacciones de alto riesgo, la combinación de la puntuación con reglas manuales que representan un escenario o modelo de riesgo suele conseguir un mejor equilibrio entre bloquear el tráfico malintencionado y aumentar los ingresos. Por ejemplo:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :card_country: in @high_risk_card_countries_to_block and :risk_score: > 65 and :amount_in_usd: > 10

Mejora con 3DS

Como se ha mencionado anteriormente, aunque esta guía no abarca el alcance de la autenticación 3D Secure (3DS), debes considerarla como parte de tu estrategia de mitigación de riesgos. Por ejemplo, aunque la transferencia de responsabilidad puede reducir las comisiones por disputas en las transacciones fraudulentas, estas transacciones siguen contabilizándose en los programas de supervisión de tarjetas, y con esto la experiencia del usuario. En lugar de una cantidad fija, podrías mejorar esta regla, cambiando «bloquear todos los cargos pertinentes» por «solicitar 3DS»:

Request 3DS if :card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’

A continuación, usa una regla para bloquear las tarjetas que no se autenticaron correctamente o que, por otros motivos, no ofrecen una transferencia de responsabilidad:

Block if (:card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’) and :risk_score: > 65 and :has_liability_shift: != ‘true’

Mejora con listas

El uso de listas predeterminadas o el mantenimiento de listas personalizadas puede ser una forma muy eficaz de bloquear un ataque durante un incidente sin el riesgo de modificar las reglas, por ejemplo, bloqueando a un cliente fraudulento, un dominio de correo electrónico o un país de la tarjeta. La mejora también conlleva decidir qué tendencias deben ser una regla, qué debe modificar el predicado de una regla y qué puede aportar valor a una lista existente. Las reglas de emergencia son un buen ejemplo de solución provisional durante un incidente que luego podría mejorarse en una lista o en la modificación de una regla existente.

Proceso de comentarios

Para la mejora, debes volver al paso 1, es decir, supervisar la eficacia de la regla y las tendencias de fraude. Una buena supervisión depende de las líneas de base establecidas y de los cambios únicos y atómicos para una trazabilidad, una precisión y una exhaustividad óptimas del backtesting. Por este motivo, recomendamos cambiar solo las reglas y los predicados en implementaciones claras y distintas y, por otra parte, confiar en listas, revisiones y bloqueos y reembolsos proactivos.

Cómo puede ayudarte Stripe

Radar para plataformas

¿Tu plataforma usa Stripe Connect? Si es así, las reglas que crees se aplicarán solo a los pagos creados en la cuenta de la plataforma (en Connect, se trata de cargos destination u
on-behalf-of). Los pagos creados directamente en la cuenta conectada están sujetos a las reglas de esa cuenta.

Radar para Terminal

Radar no detecta los cargos de Stripe Terminal. Esto quiere decir que, si usas Terminal, puedes escribir reglas basadas en la frecuencia de IP sin tener que preocuparte de que se bloqueen tus pagos en persona.

Servicios profesionales de Stripe

El equipo de servicios profesionales puede ayudarte a implementar un proceso de mejora continua de gestión de fraude. Desde el refuerzo de tu integración actual hasta el lanzamiento de nuevos modelos de negocio, nuestros expertos te orientan para ayudarte a desarrollar tu solución Stripe actual.

Conclusión

En esta guía, hemos visto cómo Sigma o Data Pipeline pueden usarse para crear una línea de base y varios modelos de fraude que representan tendencias y escenarios de ataque que solo tú y tu negocio podéis evaluar. También hemos abordado cómo puedes ampliar y adaptar Radar para reaccionar a un conjunto más amplio de transacciones fraudulentas en función de tus reglas personalizadas.

Puesto que el fraude en los pagos no deja de evolucionar, este proceso también debe evolucionar continuamente para mantenerse al día, como describimos en nuestro modelo de detección, investigación, confirmación y mejora y mitigación. Ejecutar este proceso de forma continua con un ciclo de comentarios rápido debe permitirte dedicar menos tiempo a reaccionar a incidentes y más a desarrollar una estrategia antifraude proactiva.

Puedes consultar más información sobre Radar for Fraud Teams aquí. Si ya eres usuario de Radar for Fraud Teams, consulta la página de reglas en tu Dashboard para empezar a redactar reglas.

Puedes consultar más información sobre Sigma aquí y sobre Stripe Data Pipeline aquí.