Evaluar el riesgo de fraude es un proceso continuo de identificación de vectores de ataque, patrones y escenarios, y de su mitigación. Al trabajar de manera estrecha con los usuarios, nuestro equipo de servicios profesionales observó que las empresas que logran la mayor eficacia respecto al fraude suelen contar con analistas de fraude y analistas de datos que trabajan en colaboración, y combinan Radar para Equipos de Fraude de Stripe y productos de Stripe Data como Stripe Sigma o Stripe Data Pipeline para identificar tanto patrones de fraude comunes como patrones específicos de su empresa.

Radar para Equipos de Fraude ayuda a detectar y prevenir el fraude, y te ofrece la posibilidad de crear una configuración de fraude a medida exclusiva para tu empresa, con reglas personalizadas, informes y revisiones manuales. Sigma es una solución de elaboración de informes que reúne todos tus datos de transacciones, de conversión y de clientes en un entorno interactivo en el Dashboard de Stripe. Data Pipeline proporciona los mismos datos, pero los envía a tu almacén de datos Snowflake o Redshift de manera automática para que puedas acceder a ellos junto con el resto de los datos de tu empresa.

Estas herramientas funcionan juntas a la perfección para implementar los cuatro pilares de un proceso eficaz de gestión de fraudes: detección, investigación, confirmación, y perfeccionamiento y mitigación, que abordaremos de manera más detallada.

La importancia de usar Radar para Equipos de Fraude con Sigma o Data Pipeline

El objetivo principal de usar Radar para Equipos de Fraude con Sigma o Data Pipeline es analizar los datos de Radar, como los metadatos, junto con tus propios datos, por ejemplo, la autorización previa, el recorrido del usuario, la conversión y la información de sesión, para separar las transacciones legítimas del comportamiento fraudulento de los clientes. De este modo, puedes optimizar lo siguiente:

1. El tiempo de análisis para detectar y prevenir el fraude de forma proactiva.
   
2. El tiempo de reacción para desarrollar reglas de prevención y detección.
   
3. El costo del fraude, que incluye rembolsos, comisiones por disputa, pérdida de clientes y pagos rechazados de emisores.
   

Nuestro informe El estado del fraude en línea destaca el gasto operativo de los procesos de revisión manual y que "cuanto más grandes son las [empresas], menor es la cantidad de transacciones que revisan". Automatizar estos procesos permite que los analistas de fraude destinen más tiempo a identificar nuevos vectores de ataque y a desarrollar reglas de prevención y detección. Esto significa que puedes lograr un mejor equilibrio entre el bloqueo del tráfico fraudulento y la reducción de la fricción de clientes legítimos (pérdida de clientes).

Un proceso básico de gestión de fraudes en las transacciones

Supongamos que dispones de un proceso básico de gestión de fraudes en las transacciones de detección, investigación, confirmación, perfeccionamiento y mitigación que se lleva a cabo dentro de un marco de riesgo más amplio.

• La detección, también conocida como identificación, predicción o respuesta a incidentes, es el descubrimiento de un punto de datos que amerita una mayor investigación. La detección puede ser manual (p. ej., durante un incidente), semiautomática (mediante reglas de detección o supervisión en función de un punto de referencia), automatizada (mediante machine learning o detección de anomalías) o activada de manera externa (p. ej., comentarios de los clientes o disputas). En lo que respecta a la detección, el modelo de machine learning de Radar permite encontrar patrones de fraude comunes de manera automática, mientras que Sigma puede ayudarte a encontrar patrones específicos de tu empresa.
  
• La investigación, o análisis exploratorio, es la evaluación de pagos o comportamientos sospechosos para comprender mejor el impacto en la empresa. Esto suele implicar la verificación con datos adicionales para eliminar aquellos que son innecesarios. Por lo general, los analistas de fraude usan la cola de revisión de Radar o el Dashboard de pagos de Stripe para investigar.
  
• La confirmación, también conocida como modelado o backtesting, es la generalización del vector de ataque de fraude verificado en dimensiones y candidatos a modelo. Esto también incluye la validación y la evaluación del impacto mediante el uso de datos previos y en comparación con otras reglas. Las funcionalidades de backtesting y simulación de Radar pueden ayudar a los analistas de fraude a realizar esto, pero los ingenieros de datos pueden utilizar Sigma en una mayor variedad de escenarios.
  
• El paso de perfeccionamiento y mitigación, a veces denominado acción o confinamiento, consiste en la implementación del modelo: asignar las dimensiones y funcionalidades significativas en predicados de reglas de Radar para prevenir, controlar o redirigir el fraude. Tradicionalmente, se trataba de reglas preventivas estáticas, pero ahora que el modelo de machine learning es una contrapartida importante para los seres humanos y que el objetivo es mejorar la precisión, «perfeccionamiento» es el término más apropiado. Por lo general, esto comprende las reglas de bloqueo o listas en Radar.
  

Una implementación básica de este proceso podría incluir ciclos iterativos como comprobaciones diarias, períodos de desarrollo o lanzamientos de una configuración de detección de fraude basada en reglas. Sin embargo, debido a que la duración de los ciclos puede ser diferente y los bucles de comentarios se pueden producir de manera simultánea, preferimos abordarlo como un proceso continuo.

A continuación, analizaremos en detalle cada uno de estos cuatro pilares en el contexto de un escenario hipotético y te mostraremos cómo Radar para Equipos de Fraude y Sigma o Data Pipeline pueden ayudarte.

Nuestro escenario

En nuestro escenario hipotético, analizaremos un comportamiento que se extiende en el tiempo, a diferencia de un aumento repentino.

Supongamos que tienes una empresa de comercio electrónico. Configuraste el monitoreo con webhooks en tu paquete de observabilidad que traza varios gráficos de tendencias de pago en tiempo real. En los últimos días, observaste un aumento constante del volumen de pagos rechazados de una marca de tarjetas llamada «Mallory», para un producto que no se suele vender en la región en la que se utiliza habitualmente esa marca de tarjetas. (Nota: Mallory es una marca de tarjeta ficticia que usamos para darle vida a este escenario. Por ejemplo, podría ser una marca que no se encuentra en la red de emisores mejorada). No hay promociones de ventas ni otros incidentes que puedan explicar este cambio, por lo que tu equipo debe investigar qué ocurre y decidir qué medida tomar.

Detección

Las reglas predeterminadas de Stripe usan el modelo de machine learning para predecir, detectar y bloquear una cantidad considerable de pagos fraudulentos. El Dashboard de análisis de Radar puede ofrecerte un resumen breve sobre las tendencias de fraude. Para las empresas que necesitan más control sobre qué pagos se deben revisar, permitir o bloquear, las reglas son una herramienta potente para personalizar tu protección contra fraudes.

Antes de detectar patrones de fraude nuevos, debes tener un punto de referencia de señales predictivas, como el rendimiento de tus reglas existentes. En otras palabras, debes saber lo que es «habitual» para tu empresa o cómo es una «buena» transacción. Aquí es donde los analistas de fraude e ingenieros de datos trabajan en colaboración. También pueden trabajar con equipos de DevOps y su paquete de observabilidad. En nuestro escenario hipotético, mediante un monitoreo continuo, se detecta un aumento de transacciones rechazadas con los tipos de tarjeta «Mallory».

Tablas de Sigma con datos de fraude relevantes

Para detectar patrones emergentes, primero debes establecer el rendimiento de referencia con funcionalidades como la tasa de pagos rechazados/autorizaciones del emisor y la tasa de bloqueo de Radar. A continuación, debes consultar las disputas por fraude y las alertas preventivas de fraude (registros de fraude del emisor), además de las transacciones de pago con alta velocidad, con muchos pagos rechazados del emisor o con las altas puntuaciones de riesgo de Radar. Lo ideal es programar la ejecución diaria de esta consulta en función de los datos disponibles y ver todos los Dashboard con datos previos, incluidos cortes semanales y mensuales, sin siquiera tener que consultar Sigma o tu almacén de datos de manera manual. Esto acelerará el tiempo de respuesta a los incidentes.

Las siguientes son las tablas más relevantes:

En función del dominio de tu empresa, los analistas de fraude o de negocio deberían tener una idea sobre qué dimensiones de desglose adicionales sería importante evaluar. La tabla Atributos de la regla de Radar que aparece en Radar para Equipos de Fraude incluye información detallada de las transacciones actuales que evalúa Radar. Sin embargo, no incluye la información de las transacciones que se realizaron antes del mes de abril de 2023. Tampoco presenta resultados finales ni de metadatos. Anteriormente, realizarías consultas sobre estos campos:

La nueva tabla Atributos de la regla de Radar realiza un seguimiento de las muchas dimensiones que tiene cada transacción que evalúa Radar con el nombre exacto de los atributos de Radar. Por ejemplo, puedes realizar un seguimiento de tendencias de velocidad como name_count_for_card_weekly.

Existen diferentes formas de visualizar las tendencias, pero un simple gráfico de líneas pivotadas por desglose es una buena manera de realizar una comparación sencilla con otros factores. Cuando profundices en la etapa de investigación, es posible que quieras combinar diferentes desgloses. A continuación, proporcionamos una tabla de ejemplo que muestra el desglose por segmentos de productos del aumento de las transacciones rechazadas con los tipos de tarjeta «Mallory»:

Puedes visualizarlo del siguiente modo en la hoja de cálculo que prefieras:

Analicemos con más detalle el ejemplo de una consulta en Sigma o Data Pipeline para mostrar datos de referencia. En la consulta que se encuentra a continuación, verás las tasas diarias de disputas, de pagos rechazados, de bloqueo, etc. como columnas independientes. Durante la detección y la investigación, los datos amplios y dispersos en columnas separadas suelen ser más fáciles de visualizar. Esto también facilita la posterior asignación de columnas a predicados de Radar. Sin embargo, es posible que los científicos de datos prefieran un formato alto y denso para el análisis exploratorio durante la investigación, o el modelo de machine learning en las fases de confirmación, y perfeccionamiento y mitigación.

En este ejemplo, incluimos metadatos en el pago para mostrar un desglose por segmento de productos. En un enfoque amplio, necesitaríamos consultas similares para la marca de la tarjeta («Mallory») y el tipo de financiación, según nuestro escenario. Aquí eliminamos los reintentos duplicados para centrarnos en los intentos reales y obtener una mejor sensación de magnitud. Optamos por eliminar los objetos Payment Intents duplicados: las integraciones más profundas pueden enviar un campo (p. ej., un identificador de pedido, en metadatos) para garantizar la eliminación de los duplicados en todo el recorrido del usuario. Este ejemplo muestra cómo puedes mejorar la precisión de tus medidas antifraude si agregas otro factor. En nuestro escenario, este sería el segmento de producto «tarjetas de regalo». Abordaremos cómo mejorar la precisión más adelante, en la sección Perfeccionamiento y mitigación.

Esta consulta no muestra el plazo real de las disputas, que es un indicador de resultado, pero incluimos algunos indicadores de muestra. Por ejemplo, los reintentos como indicador de prueba de tarjetas. En esta consulta, obtenemos algunas métricas diarias de forma sencilla:

• El volumen de cargos, tanto los valores duplicados eliminados como aquellos sin procesar: por ejemplo, 1150 cargos al día (de los cuales Radar rechaza 100 y bloquea 50), a través de 1000 Payment Intents.
  
• La tasa de autorización: en este ejemplo, es del 90 % para los cargos (porque los pagos bloqueados no se dirigen al emisor) y del 100 % para Payment Intents (ya que finalmente todos se reintentaron de manera correcta).
  
• La tasa de riesgo alto y de bloqueo: en este caso, ambas serían del 1.6 % (también se bloquearon los 50 riesgos altos).
  
• La tasa de disputas retrospectiva para los pagos del mismo periodo: por ejemplo, se disputaron 5 de cada 1000 cargos. El número por día de pago aumentará cuando ingresen más disputas. Por este motivo, incluimos el tiempo de ejecución de la consulta para realizar un seguimiento del cambio.
  

Como mencionamos anteriormente, simplificamos estas consultas para facilitar su lectura. En realidad, esta consulta tendría aún más dimensiones: por ejemplo, tendencias, desviaciones o diferencias de pérdidas.

También incluimos un ejemplo de media móvil de 30 días mediante una función de ventana. Es posible implementar enfoques más complejos, como el examen de los percentiles en lugar de las medias para identificar los ataques de cola larga, pero no suelen ser necesarios para la detección inicial del fraude, ya que las líneas de tendencia son más importantes que las cifras perfectamente exactas.

Cuando comprendes el punto de referencia, puedes empezar a realizar seguimientos de anomalías y tendencias para investigar, por ejemplo, un aumento del fraude o de la tasa de bloqueo en un determinado país o con un método de pago específico (en nuestro escenario hipotético, se trataría de la marca de tarjeta «Mallory»). Las anomalías se suelen investigar mediante informes o análisis manuales en el Dashboard, o consultas ad-hoc en Sigma.

Investigación

Una vez que los analistas encuentran una anomalía que se debe investigar, el siguiente paso es realizar una consulta en Sigma (o en tu almacén de datos mediante Data Pipeline) para explorar los datos y generar una hipótesis. Deberás incluir algunas dimensiones de desglose en función de las hipótesis. Por ejemplo, métodos de pago (uso de tarjetas), canal o plataforma (metadatos), cliente (reputación) o productos (categoría de riesgo) con tendencia al fraude. Más adelante, en la etapa de confirmación, podrás llamar a esas dimensiones «funcionalidades». Se asignarán a los predicados de Radar.

Volvamos a nuestra hipótesis de que un gran volumen de transacciones con tarjetas de pago anticipado de «Mallory» tiene mayores tasas de fraude, que puedes representar como una dimensión de agrupación sobre la que pivotar con tu herramienta de análisis. Por lo general, en esta etapa se repite y modifica la consulta. Entonces, es una buena idea incluir varios predicados candidatos como versiones reducidas o ampliadas de las hipótesis, y eliminar funcionalidades menores, para medir su impacto. Por ejemplo:

este enfoque te daría una idea de la magnitud para priorizar el impacto. La tabla indica con razonable seguridad que la regla candidata 3 parece capturar el exceso de transacciones maliciosas. Una evaluación más sofisticada se basaría en la exactitud, la precisión o la sensibilidad. Puedes crear un resultado similar con la siguiente consulta.

En esta consulta, eliminamos la duplicación para facilitar la lectura, pero incluimos la tasa de disputas y la tasa de alertas preventivas de fraude, que son importantes para los programas de monitoreo de marcas de tarjetas. Sin embargo, se trata de indicadores de resultado, y en esta consulta simplificada realizamos un seguimiento mirando hacia atrás. También incluimos ejemplos de pagos arbitrarios para realizar comprobaciones cruzadas y profundizar en los patrones que se encontraron en la consulta. Abordaremos este tema más adelante.

Es posible que desees desglosar métricas adicionales en un histograma para identificar grupos, lo que puede ser útil para definir las reglas de velocidad que puedes usar para la limitación de frecuencia (p. ej., total_charges_per customer_hourly).

La identificación de tendencias mediante el análisis de histogramas es una forma excelente de comprender el comportamiento deseado del cliente a lo largo de todo su ciclo de vida y embudo de conversión. Agregar esto a la consulta anterior sería demasiado complejo, pero proporcionamos un ejemplo sencillo de cómo desglosar esto sin una lógica compleja de ventana móvil, suponiendo que tienes un tipo de cliente en los metadatos (p. ej., usuarios invitados):

En nuestro escenario, es posible que no quieras bloquear todas las tarjetas de prepago de «Mallory», pero sí identificar con seguridad otros factores de riesgo correlacionados. Esta consulta de velocidad podría mejorar la confianza para, por ejemplo, evitar el bloqueo de clientes invitados de baja frecuencia.

Una forma sencilla de investigar es mirar los ejemplos directamente en el Dashboard mediante la vista «Pagos relacionados» para comprender el comportamiento (o sea, el vector de ataque o patrón de fraude) y las conclusiones sobre riesgos de Radar asociadas. Por eso incluimos ejemplos de pagos arbitrarios en la consulta anterior. De este modo, también podrás encontrar pagos más recientes que aún no están disponibles en Sigma. Una forma más defensiva y de alta interacción sería modelar tu hipótesis como una regla de revisión que aunque permite pagos, los dirige a los analistas para una revisión manual. Algunos clientes lo hacen para considerar el rembolso de pagos por debajo de la comisión por disputa mientras bloquean los que se encuentran por encima.

Confirmación

Supongamos que el patrón que identificaste no es sencillo, no se puede mitigar mediante un rembolso y el bloqueo del cliente fraudulento y no puede incluirse en una lista de bloqueo predeterminada.

Después de identificar y priorizar un patrón nuevo para abordar, es necesario analizar su posible impacto en los ingresos legítimos. No se trata de un problema de optimización insignificante, porque la cantidad óptima de fraude es distinta de cero. De todos los modelos candidatos, elige el que mejor se adapte al riesgo que quieras asumir, ya sea por simple magnitud o por precisión y sensibilidad. Este proceso se suele denominar backtesting, especialmente cuando las reglas se escriben primero y luego se validan con los datos. (También se puede hacer a la inversa, es decir, descubrir primero los patrones y luego escribir las reglas). Por ejemplo, en lugar de escribir una regla por país, escribe una regla como la siguiente que facilita la confirmación:

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

La consulta que compartimos anteriormente en la sección Investigación también se puede utilizar como modelo, con la diferencia de que se destacan distintos valores. Abordaremos esto más adelante, cuando lleguemos a las técnicas de perfeccionamiento y mitigación.

Asignación del esquema de Sigma a la regla de Radar

Es hora de traducir tus consultas exploratorias desde Sigma o Data Pipeline para ayudarte a asignar las reglas de Radar a Sigma para el backtesting. A continuación, proporcionamos algunas asignaciones comunes, suponiendo que envías las señales correctas a Radar:

Los últimos dos elementos, risk_level y risk_score, no son como los demás, ya que el propio modelo de machine learning se deriva de los otros factores. En lugar de escribir reglas demasiado complejas, te recomendamos que uses machine learning de Radar. Abordaremos esto en la sección Perfeccionamiento mediante machine learning.

La nueva tabla Atributos de la regla de Radar realiza un seguimiento de las muchas dimensiones que tiene cada transacción que, en realidad, evaluó Radar con el nombre exacto de los atributos de Radar.

La tabla que aparece más arriba muestra el conjunto estándar de atributos y omite deliberadamente señales que personalizarías para tu recorrido del cliente, como sesiones de Radar o metadatos.

En función de la investigación anterior, supongamos que llegas a una regla como la siguiente:

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 consiste en confirmar el impacto de esta regla en tus transacciones de pago reales. Esto se suele hacer con reglas de bloqueo. Consulta nuestra guía Radar para Equipos de Fraude: aspectos básicos de las reglas para obtener información sobre 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 validar que funciona según lo previsto.

Tanto las reglas de bloqueo como las reglas de revisión pueden someterse a pruebas de backtesting en Radar mediante la funcionalidad de simulación de Radar para Equipos de Fraude.

Una ventaja de usar las simulaciones de Radar para Equipos de Fraude es que tienen en cuenta el impacto de otras reglas existentes. El mantenimiento de reglas no es el tema principal de esta guía, pero eliminar y actualizar las reglas también debería formar parte de tu proceso de mejora continua. En términos generales, la cantidad de reglas debe ser lo suficientemente pequeña como para que cada regla sea atómica y se pueda monitorear mediante las consultas de referencia desarrolladas en las etapas Detección e Investigación, y someterse a backtesting de manera clara, sin riesgo de efectos secundarios (p. ej., la regla 2 solo funciona porque la regla 1 filtra otra cosa).

También puedes hacerlo mediante reglas de revisión en lugar de reglas de bloqueo, que abordaremos en la siguiente sección.

Perfeccionamiento y mitigación

Por último, luego de probar las reglas de bloqueo, se aplica el modelo para prevenir, controlar o redirigir el fraude. Lo llamamos "perfeccionamiento" porque se trata de mejorar la precisión de tus medidas antifraude generales, especialmente en combinación con el modelo de machine learning. Para mejorar la precisión, puedes aplicar varias técnicas. Este paso, que también se conoce como contención o mitigación, a veces se realiza al mismo tiempo que la confirmación, donde en lugar de utilizar reglas de revisión, pruebas A/B (metadatos) o simulaciones para evaluar tu modelo, bloqueas los cargos sospechosos al instante para mitigar el riesgo inmediato.

Incluso si ya tomaste medidas, existen algunas técnicas que puedes utilizar para perfeccionar el modelo que desarrollaste en los pasos 1 a 3 a fin de mejorar los resultados con el tiempo:

Perfeccionamiento mediante reglas de revisión

Si no quieres arriesgarte a una mayor tasa de falsos positivos, que podría afectar tus ingresos, puedes optar por aplicar reglas de revisión. Aunque se trata de un proceso más manual y puede generar fricción en la experiencia del cliente, las reglas de revisión pueden permitir que, en última instancia, se realicen más transacciones legítimas. (También puedes agregar limitaciones, en forma de reglas de velocidad, a las reglas de bloqueo existentes para las transacciones más lentas). Una opción más avanzada para usar las reglas de revisión son las pruebas A/B, que son muy útiles para gestionar la cantidad total de casos en la cola de revisión. Puedes aprovechar los metadatos de los pagos para empezar a permitir una pequeña cantidad de tráfico mientras realizas pruebas A/B, por ejemplo, de clientes conocidos o simplemente de un número aleatorio. Recomendamos agregar esto a las reglas de bloqueo en lugar de crear reglas de permiso, ya que las reglas de permiso anularán los bloqueos y, por lo tanto, dificultarán el seguimiento del rendimiento de la regla de bloqueo a lo largo del tiempo.

Optimización de las reglas mediante el monitoreo del rendimiento

Para monitorear el rendimiento de la regla, puedes comprobar el objeto de resultado de cargo en la API Payment Intents, en particular el objeto de regla. Del mismo modo, 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 realizar el seguimiento del rendimiento de una regla en Sigma mediante la tabla especial de decisiones sobre reglas de Radar:

Perfeccionamiento mediante machine learning

El paso siguiente a bloquear un ataque inmediato suele ser perfeccionar la regla de manera iterativa junto con el modelo de machine learning para reducir los falsos positivos, lo que permite que pase más tráfico legítimo y, por lo tanto, ingresos.

Por ejemplo, el bloqueo de BIN o IIN (número de identificación del emisor). Durante un ataque de prueba de tarjetas, es posible que se haya agregado temporalmente un BIN a una lista de bloqueo, lo que permite a los emisores corregir las brechas. Sin embargo, bloquear directamente a un emisor podría reducir tus ingresos. Un planteamiento perfeccionado consiste en aplicar un mayor escrutinio a lo largo del tiempo y perfeccionar el modelo. Este es un buen momento para revisar cómo escribir reglas efectivas y cómo evaluar riesgos, en particular la puntuación de riesgos de Radar. Por lo general, recomendamos combinar el modelo de machine learning de Radar con tu intuición. En lugar de tener una única 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 generar un mejor equilibrio entre el bloqueo del tráfico malicioso y la autorización de 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

Perfeccionamiento mediante 3DS

Como mencionamos anteriormente, aunque esta guía no aborda la amplitud de la autenticación 3D Secure (3DS), debes tenerla en cuenta como parte de tu estrategia de mitigación de riesgos. Por ejemplo, si bien la transferencia de responsabilidad puede reducir las comisiones por disputas de transacciones fraudulentas, estas transacciones se siguen incluyendo en los programas de monitoreo de tarjetas, y con ello, la experiencia de usuario. En lugar de una cantidad fija, podrías perfeccionar esta regla de «bloquear todos los cargos relevantes» a «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’

Luego puedes usar una regla para bloquear las tarjetas que no se autentiquen correctamente o que por otras razones no proporcionen la 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’

Perfeccionamiento mediante listas

Usar las listas predeterminadas o mantener listas personalizadas puede ser una forma muy eficaz de bloquear un ataque durante un incidente sin el riesgo de cambiar las reglas. Por ejemplo, bloquear a un cliente fraudulento, un dominio de correo electrónico o el país de una tarjeta. Parte del perfeccionamiento consiste en decidir qué patrones deben ser una regla, cuáles deben cambiar un predicado de regla y cuáles pueden simplemente agregar valor a una lista existente. Las reglas de anulación de emergencia son un buen ejemplo de medida provisoria durante un incidente, que posteriormente puede convertirse en una lista o en una modificación de una regla existente.

Proceso de comentarios

El perfeccionamiento también implica volver al paso 1. Es decir, monitorear el rendimiento de las reglas y los patrones de fraude. Un buen monitoreo depende de puntos de referencia establecidos y de cambios únicos y atómicos para un seguimiento, precisión y sensibilidad óptimos del backtesting. Por este motivo, recomendamos cambiar las reglas y los predicados solo en implementaciones claras y diferenciadas, así como confiar en listas, revisiones, bloqueos y rembolsos proactivos.

¿Cómo te puede ayudar Stripe?

Radar para plataformas

¿Eres una plataforma que usa Stripe Connect? Si es así, las reglas que creas solo se aplican a los pagos creados en la cuenta de la plataforma (en términos de Connect, se trata de cargos de destino
o a nombre de alguien). Los pagos que se crean directamente en la cuenta conectada están sujetos a las reglas de esa cuenta.

Radar para Terminal

Radar no controla los cargos de Stripe Terminal. Esto significa que si usas Terminal, puedes escribir reglas basadas en la frecuencia de IP sin preocuparte de bloquear tus pagos en persona.

Servicios profesionales de Stripe

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

Conclusión

En esta guía, abordamos cómo usar Sigma o Data Pipeline para crear tanto un punto de referencia como varios modelos de fraude que representan escenarios de ataque y patrones que solo tú y tu empresa pueden juzgar. También mostramos cómo ampliar y configurar Radar para que reaccione ante una mayor variedad de transacciones fraudulentas en función de reglas personalizadas.

Debido a que el fraude en los pagos evoluciona de manera continua, este proceso también debe evolucionar para mantenerlo actualizado, tal y como detallamos en nuestro modelo de Detección, Investigación, Confirmación, y Perfeccionamiento y mitigación. Ejecutar estos ciclos de forma continua con un bucle de comentarios rápido debería permitirte dedicar menos tiempo a reaccionar ante los incidentes y más a desarrollar una estrategia proactiva contra el fraude.

Puedes obtener más información sobre Radar para Equipos de Fraude aquí. Si ya eres usuario de Radar para Equipos de Fraude, consulta la página Reglas en el Dashboard para empezar a escribirlas.

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