Las reglas predeterminadas de Stripe utilizan el machine learning para predecir y bloquear una cantidad sustancial de pagos fraudulentos. Para empresas que necesitan más control sobre qué pagos deben revisarse, permitirse o bloquearse, las reglas son una potente herramienta que permite personalizar su forma de protegerse contra el fraude.

En esta guía hacemos un repaso exhaustivo a los aspectos más importantes de las reglas de Radar, te presentamos más de 100 reglas que puedes usar en Radar y analizamos las prácticas recomendadas con respecto al backtesting, la escritura de reglas y mucho más.
Vamos a empezar.

La importancia del orden y la jerarquía en las reglas

El orden que siguen las reglas en tu página de Radar es importante. Cada pago se evalúa teniendo en cuenta las reglas que has creado y el proceso de evaluación se ejecuta en este orden:

1. Request 3DS: estas son las reglas que solicitan autenticación 3D Secure cuando se usan con Stripe Checkout o con la API de Payment Intents. Sean cuales sean los resultados de este paso, las siguientes reglas también se evalúan a continuación.
   
2. Allow: cuando se aplican estas reglas de «permiso», se autoriza que un pago se procese. Este tipo de reglas debe implementarse con mucha atención, ya que pasarán siempre por delante de cualquier otra regla (excepto las de 3DS). Solo los comerciantes que han procesado más de 100.000 USD puede escribir reglas del tipo Allow.
   
3. Block: cuando se aplican estas reglas de «bloqueo», se rechaza el pago. Cuando se aplica un bloqueo a un pago, no se evalúa con respecto a ninguna regla de revisión.
   
4. Review: cuando se aplica una regla de «revisión», el pago se sigue procesando y se cobra al cliente, pero se asigna un mensaje a la transacción para que puedas analizarla más adelante si lo consideras necesario.
   

Para poner esto en práctica, usemos las siguientes reglas como ejemplo:

• Allow payments less than $10

• Allow payments within the US and with a risk level of normal

• Block payments where the risk level is high

• Block payments greater than $1,000

• Review payments with a card issued outside the US

En este caso, todos los pagos inferiores a 10 USD se procesarían, porque la primera regla permite la transacción y evita que se evalúen más reglas. Del mismo modo, un pago de 1500 USD realizado dentro de los Estados Unidos con un nivel de riesgo «normal» también se permitiría, a pesar de que más adelante hay una regla que bloquea pagos de más de 1000 USD. Esto es así porque la segunda regla de la lista permite pagos realizados dentro de Estados Unidos y con un nivel de riesgo normal. Cuando una regla autoriza o bloquea un pago, ya no se evalúan las reglas posteriores.

Simbología básica del lenguaje de las reglas

Las escritura de reglas funciona de forma similar a SQL: tienes acceso a distintos operadores que puedes usar en función del tipo de datos que utilizas en tu regla. Estos son algunos de los más relevantes:

Si quieres comprobar específicamente si existe un atributo o un atributo de metadatos, no utilices el operador !=, sino la función is_missing. Debes introducir en esta función el atributo o la clave de metadatos que pueda faltar. Por ejemplo, puedes escribir una regla que coincida con todos los pagos en los que no tengas acceso a una dirección de correo electrónico del cliente:

• Review if is_missing(:email_domain:)
  

También podrías escribir una regla que coincida con todos los pagos para los cuales NO falte la dirección de correo electrónico del cliente:

• Review if !(is_missing(:email_domain:))
  

Redactar reglas con lenguaje natural

Si prefieres escribir las reglas de una manera más sencilla o no sabes con seguridad qué atributos hay que usar para actuar sobre una situación de fraude específica, el Asistente de Radar, que funciona gracias a la IA, se ocupará de traducir tus solicitudes escritas en lenguaje natural y las transformará en reglas expresadas en la sintaxis de Radar. También puedes realizar el backtesting de la regla antes de implementarla directamente desde el Asistente de Radar, para comprobar qué resultados habría obtenido respecto a un historial de datos.

Reglas de Radar de uso común

Esta lista contiene algunas las reglas más habituales en Radar, enfocadas a distintos objetivos.

Reglas que contribuyen a evitar las pruebas de tarjetas o el cobro de tarjetas

Reglas que ayudan a prevenir el fraude en función del tipo de producto

Este tipo de reglas requiere usar metadatos o definir información sobre el SKU (el código único de cada producto) en la descripción del cargo. Estos pagos se siguen procesando, y se cobra al cliente, pero se marcan para que los puedas revisar.

Reglas que ayudan a evitar el fraude con tarjetas prepago

Analizar la situación de fraude que sufres antes de crear reglas

Revisión de los fraudes

Si aspiras a diseñar reglas verdaderamente eficaces, tienes que conocer a fondo la actividad fraudulenta que se desarrolla en tu cuenta. Es fundamental que conozcas los rasgos característicos de cada vector de fraude que haya presente. Plantéate estas cuestiones:

• ¿Resulta que hay cuentas que se ponen a hacer compras fraudulentas nada más crearse, utilizando direcciones de correo electrónico y nombres de titulares nuevos?

• ¿Hay estafadores que acceden a cuentas ya veteranas y hacen compras con importes inusualmente elevados?

• ¿El fraude se centra sobre todo en redes de tarjetas concretas o en países determinados?

• ¿Detectas fraudes a alta velocidad, con varios intentos desde la misma tarjeta, dirección de correo o dirección IP durante intervalos de tiempo muy cortos?

Si revisamos el fraude a alta velocidad que se produce en la captura de pantalla anterior, veremos que las reglas que utilizan authorized_charges_per_card_number_hourly o authorized_charges_per_ip_address_hourly podrían actuar sobre este vector de fraude.

Conoce mejor cuáles son los motores del fraude

La información sobre los métodos de fraude te ayudará a detectar rápidamente los orígenes de cada fraude y actuar sin que sea necesario analizar manualmente los datos de las transacciones. La pestaña Insights tab del Dashboard te presenta los atributos más destacados asociados a transacciones fraudulentas. A continuación, puedes agregar una regla que actúe sobre cada atributo afectado, directamente desde la pestaña Insights.

Los tres tipos de atributos en la creación de reglas

Tipo 1

Atributos posteriores a la autorización: este tipo de atributos está disponible para todos los usuarios. Para configurar un atributo posterior a la autorización, utiliza dos puntos antes y después del atributo que quieras usar: por ejemplo, «:cvc_check:».

Aquí tienes un ejemplo de cómo usar este tipo de atributos posteriores a la autorización:

• Block if :address_line1_check: != 'pass' Con esta regla, cualquier cargo se bloqueará si no pasa específicamente la verificación del emisor de tarjeta. Es decir, para que se pueda autorizar el pago, deberá coincidir la primera línea de la dirección de facturación que el cliente ha proporcionado con la información que el emisor tiene registrada para el titular de la tarjeta. Por lo tanto, si la verificación aparece como «no disponible» (unavailable), si el emisor «no verificó» los datos (unchecked) o si el emisor «no proporcionó» (not_provided) los datos, el pago se bloqueará.
  

Tipo 2

Atributos estándar: este tipo de atributos está disponible para todos los usuarios. Para configurar un atributo estándar, también debes utilizar dos puntos antes y después del atributo que quieras usar: por ejemplo, «:card_bin:». Hemos dividido nuestros atributos estándar en cuatro categorías:

• Atributos basados en la frecuencia (útiles para evitar ataques de prueba de tarjetas o cobros fraudulentos con tarjetas)
  
• Atributos basados en los datos de la tarjeta
  
• Atributos basados en los datos de pago
  
• Atributos basados en los datos del cliente
  

Algunos atributos requieren valores como cadenas, mientras otros requieren valores como números. Hemos incluido un ejemplo de cada atributo para que veas cómo funciona cada caso. Si el atributo requiere una cadena (como, por ejemplo, :card_bin: ), verás en el ejemplo que los números están entre comillas simples (‘ ’): :card_bin: = ‘424242’. Si el atributo requiere un número, no tendrá esas comillas: por ejemplo, :amount_in_usd: > 250.

Atributos basados en la frecuencia

Hay cuatro tipos de atributos basados en la frecuencia que son particularmente útiles para prevenir el fraude por robo de tarjetas (como, por ejemplo, los cobros fraudulentos o los ataques de prueba de tarjetas).

1. Authorization: se basa en autorizaciones del emisor
   
2. Charge: se basa en cargos
   
3. Decline: se basa en rechazos del emisor
   
4. Block: se basa en bloqueos realizados por el machine learning de Radar
   

También hay atributos basados en el resultado de cargos, como las autorizaciones (en función de si el emisor ha autorizado correctamente un cargo), cargos (en función de los intentos de cargo), rechazos (en función de los cargos que ha rechazado el emisor), disputas (en función de cuántas transacciones disputadas han sido identificadas como fraudulentas) y bloqueos (basados en los cargos bloqueados por el machine learning de Radar). Los resultados se combinan con los datos de un cliente (correo electrónico, dirección IP, nombre o ID de cliente) para formar un atributo.

Además, puedes combinar la frecuencia de los datos de un cliente (correo electrónico, nombre) con la tarjeta o dirección IP utilizada en una transacción. Dicho de otro modo, hay disponibles dos tipos de reglas de frecuencia:

1. Basadas en el resultado del cargo (p. ej., authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) donde el resultado es una autorización correcta, un intento de cargo, rechazos, disputas, bloqueos
   
2. Basadas en vínculos entre la información del cliente y una tarjeta o IP (p. ej., name_count_for_card_weekly, email_count_for_ip_hourly)
   

Las reglas de frecuencia excluyen el pago que estés procesando en ese momento. Por ejemplo, authorized_charges_per_email_hourly representa la cantidad de intentos anteriores realizados correctamente de un correo electrónico en la hora anterior. De modo que, para el primer intento de cargo en una hora dada para un correo electrónico, authorized_charges_per_email_hourly tiene un valor de 0. Si el primero se realiza correctamente, el segundo intento de cargo dentro de la misma hora de ese correo electrónico tiene un valor de 1, y así sucesivamente.

Atributos basados en los datos de tarjeta

Atributos basados en los datos de pago

Atributos basados en los datos del cliente

Aquí tienes un ejemplo de cómo usar estos atributos estándar:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Con esta regla, cualquier cargo de una tarjeta emitida en Canadá, Alemania o los Emiratos Árabes Unidos se bloqueará.

Tipo 3

Atributos de metadatos: estos atributos dependerán de qué metadatos envíes a Stripe. Con estos atributos tienes que usar dos puntos dobles, es decir, dos veces antes y dos veces después de los atributos: ::Customer Age::. Los atributos de metadatos pueden funcionar como cadenas o como números. Cuando se usan como cadenas, los atributos de metadatos distinguen entre mayúsculas y minúsculas.

Los metadatos pueden usarse para crear reglas muy potentes, como poner cargos en revisión manual según los tipos de producto que incluye el pedido o reducir la fricción en los pagos de clientes recurrentes. Para obtener más información sobre cómo definir más metadatos, consulta esta guía.

Los atributos de metadatos se escriben con la siguiente estructura:

• ::[metadata attribute name]:: [operator] [metadata_value]
  

Supongamos que tienes pagos con los siguientes datos almacenados como metadatos:

Puedes escribir una regla para enviar los pagos que coincidan a la fase de revisión manual.

• Review if ::Customer Age:: < 30
  

También puedes escribir reglas usando atributos de metadatos además de los otros tipos de atributos que hemos mencioando en este documento. Por ejemplo, puedes escribir una regla que solo ponga un pago en revisión si el identificador del artículo es 5A381D y el importe del pago es superior a 1000 USD.

• Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000
  

Los atributos de metadatos también admiten el operador IN para comparar con distintos valores. Por ejemplo, puedes escribir una regla que ponga un pago en revisión si la categoría del identificador del producto es «alimentación», «electrónica» o «ropa».

• Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')
  

El operador INCLUDES puede utilizarse con reglas para los atributos de metadatos y otros atributos de cadena para coincidir con subcadenas. Por ejemplo, puedes escribir una regla que ponga un pago en revisión si el ID de la partida incluye la cadena A381. Esto coincide con “A381”, “5A381D”, “A381D”, “5A381”, etc.

• Review if ::Item ID:: INCLUDES 'A381'
  

A los metadatos también se puede acceder en objetos de destino y cliente (si se utilizan para un pago determinado). Estos atributos se escriben con la siguiente estructura:

• ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:
  

Supongamos que tienes un cliente con los siguientes metadatos:

Podrías escribir una regla que siempre permita pagos de clientes de confianza, es decir, si el campo de metadatos «Trusted» del cliente es «true».

• Allow if ::customer:Trusted:: = 'true'
  

O si tuvieras un destino con los siguientes metadatos:

Podrías escribir una regla que ponga un pago en revisión si el campo de metadatos Category de destino es new.

• Review if ::destination:Category:: = 'new'
  

Cómo usar listas guardadas en tus reglas

Puedes hacer referencia a un grupo de valores en tus reglas a través de listas creadas anteriormente. Por ejemplo, puedes usar tus listas de bloqueo (block lists) o las listas de autorización (allow lists) para incluir grupos de clientes en tus reglas. Si estás intentado bloquear una lista de correos electrónicos, te será mucho más fácil crear una lista de bloqueo en lugar de crear varias reglas para cada correo electrónico que quieras bloquear.

Toda la lista de alias referenciados en las reglas deben comenzar con @. Para crear una regla que haga referencia a una lista, debes seguir la siguiente estructura:

• {action} [attribute] in [list]
  

Por ejemplo, supongamos que tienes una lista de países de tarjetas que te gustaría bloquear. Podrías escribir una regla usando varias cláusulas OR:

• Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

También podrías escribir una regla usando una lista en línea:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Si lo prefieres, podrías crear una lista de países de tarjetas que te gustaría bloquear, denominada card_countries_to_block. A continuación, puedes añadir a la lista los países que elijas y hacer referencia a esa lista en una regla:

• Block if :card_country: in @card_countries_to_block
  

La regla que usa una lista no es solo más concisa, sino que es más fácil editarla y añadirle un gran número de elementos.

Cómo escribir reglas complejas con varias condiciones

Puedes crear reglas complejas combinando condiciones básicas con el uso de los operadores AND, OR y NOT. También puedes usar sus símbolos equivalentes &&, || y ! respectivamente. De forma similar a los lenguajes de programación, como C, Python y SQL, Stripe admite el operador estándar precedence (orden de las operaciones). Por ejemplo, la condición compleja:

• {condition_X} OR NOT {condition_Y} AND {condition_Z}
  

se interpreta como:

• {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})
  

También se pueden agrupar subcondiciones dentro de condiciones complejas con paréntesis. De hecho, el ejemplo anterior puede modificarse para cambiar explícitamente el orden de evaluación de los subpredicados:

• ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

• {condition_X} OR NOT ({condition_Y} AND {condition_Z})

Al usar paréntesis en diferentes posiciones, cada una de estas condiciones complejas genera resultados distintos.

También puedes usar la función is_missing en las conjunciones OR o AND:

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

O puedes usar la función is_missing cuando no falte; en este caso, si bloquea pagos en caso de que :ip_country: NO falte y de que la dirección IP sea de EE. UU. o PR.

• Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
  

Reglas de backtesting

Una pieza fundamental del análisis de reglas es encontrar el equilibrio entre prevenir el fraude y bloquear transacciones legítimas o falsos positivos. El backtesting ayuda a identificar reglas que coincidan con el riesgo que quieres asumir o que consigan el equilibrio adecuado entre las disputas evitadas y cualquier aumento de falsos positivos. Para calcular el impacto de una regla, puedes realizar este backtesting combinando datos de transacciones de los últimos seis meses a través del Dashboard de Radar y realizar análisis más específicos para calcular cuáles hubiesen sido los resultados de una regla si se hubiera aplicado recientemente.

Cómo realizar el backtesting desde el Dashboard

Las definiciones de qué es lo que constituye un pago fraudulento y otros pagos realizados correctamente difieren según el tipo de regla que estés probando:

Regla de bloqueo

• Disputados, con alerta de fraude preventiva recibida o reembolsados por fraude: cargos realizados correctamente que se disputaron o reembolsaron por fraude o cargos realizados correctamente puestos en revisión que se disputaron o reembolsaron por fraude

• Otros pagos realizados correctamente: cargos realizados correctamente que no se disputaron ni reembolsaron por fraude o cargos realizados correctamente puestos en revisión y que no se disputaron ni reembolsaron por fraude

• Intentos de pago fallidos: rechazados por el emisor o bloqueados por Radar

Regla de revisión

• Disputados, con alerta de fraude preventiva recibida o reembolsados por fraude: cargos realizados correctamente que se disputaron o reembolsaron por fraude

• Otros pagos realizados correctamente: cargos realizados correctamente que no se disputaron ni reembolsaron por fraude

• Fallido o puesto ya en revisión: rechazado por el emisor, bloqueado por Radar, o cargos realizados correctamente puestos en revisión (independientemente de si el estado es en disputa o reembolsado)

Regla de permiso

• Bloqueado por Stripe o por tus reglas personalizadas: cargos bloqueados por Radar

• Disputados, con alerta de fraude preventiva recibida o reembolsados por fraude: cargos realizados correctamente que se disputaron o reembolsaron por fraude o cargos realizados correctamente puestos en revisión que se disputaron o reembolsaron por fraude

• Otros pagos realizados correctamente o rechazados por el banco: rechazados por el emisor, cargos realizados correctamente que no se disputaron ni reembolsaron por fraude, o cargos realizados correctamente puestos en revisión y que no se disputaron ni reembolsaron por fraude

Cómo realizar análisis de backtesting personalizados

La función de backtesting del Dashboard de Radar se centra en los últimos seis meses de transacciones e incluye disputas, alertas de fraude preventivas y cargos reembolsados como fraudulentos.

Quizá quieras realizar un análisis más específico si, por ejemplo, estás en riesgo de ser identificado en un programa de Visa para la supervisión del fraude (centrado exclusivamente en alertas de fraude preventivas) o has notado un pico reciente de fraude procedente de un país de IP o tipo de monedero concretos. Para ello, puedes crear una consulta SQL en Sigma o exportar y analizar informes de datos de pagos en el Dashboard. El backtesting personalizado ofrece flexibilidad en las franjas de tiempo (más de seis meses) y análisis más específicos (por ejemplo, puedes centrarte únicamente en disputas o en alertas de fraude preventivas (AFP) La consulta de ejemplo que aparece a continuación realiza backtesting en las alertas de fraude preventivas (AFP) de Visa en transacciones que superen los 100 dólares si has detectado que el volumen de fraude ha estado aumentando últimamente y que las transacciones de puntuación de riesgo elevado crearon el riesgo de entrar al programa de supervisión:

Using fields and tables available in Sigma

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select 
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from base

El backtesting de los últimos 60 días mediante la creación de una fecha de alerta de fraude preventiva (AFP) se centra en el fraude más reciente, mientras que el backtesting de los últimos 60-120 días de ventas no fraudulentas permite que el fraude se desarrolle de forma más completa.

Vectores de fraude habituales

La mayoría de los estafadores siguen un patrón común a la hora de cometer un fraude. En primer lugar, validan la información de pago robada (por ejemplo, las tarjetas). Una vez que se ha validado que funcionan, usan estas credenciales para obtener valor en forma de productos físicos para uso personal o reventa (artículos de lujo o aparatos electrónicos), servicios para uso personal o reventa (servicios de entrega de comida a domicilio) o servicios y productos que ayuden a seguir cometiendo fraude (es decir, servicios de alojamiento web, servicios de envío de SMS no deseados, etc.).

Sigue leyendo para conocer más detalles sobre algunos de los vectores de fraude más comunes y obtener sugerencias sobre cómo usar las reglas de Radar para mitigarlos.

Pruebas

La prueba de tarjetas tiene lugar cuando los estafadores usan scripts o procesos manuales para probar si los números de tarjetas robadas sin procesar aún están operativos. Esta fase del fraude no pretende conseguir un servicio o producto físico, sino validar que las tarjetas están activas. Estos cargos suelen corresponderse con autorizaciones o transacciones de menos de un dólar. Por lo general, las pruebas se llevan a cabo con una secuencia rápida y a gran velocidad. Los atributos que pueden ser útiles son las funciones de agrupación y velocidad, como las siguientes:

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

Los estafadores normalmente intentan eludirlas creando correos electrónicos falsos y usando direcciones de correo electrónico características. Los estafadores con más experiencia enmascaran las direcciones IP o incluso cuentan con varios dispositivos para proporcionar datos de un único dispositivo. Por tanto, es importante reconocer el comportamiento típico de un cliente que actúa de buena fe. Hay funciones, como el dominio del correo electrónico o el país de la dirección IP, entre otras categorías más amplias, que pueden ayudar a identificar transacciones que plantean más riesgos. Muchos cliente fraudulentos usan dominios de correo electrónico populares de proveedores consolidados, como gmail.com. Puede que veas dominios como gmail.comms o gomail.co, que tratan de enmascarar la identidad de los estafadores. El país de la tarjeta y el de la IP también pueden servir para segmentar clientes y garantizar que las transacciones proceden de las regiones típicas de tu cartera de usuarios. Es conveniente que revises o bloquees las transacciones que no procedan de dichas regiones.

Una última funcionalidad para frenar este comportamiento de prueba es implementar CAPTCHA.

En Stripe Checkout, los desafíos de CAPTCHA se activan automáticamente cuando el machine learning detecta un ataque de prueba de tarjetas. Para mitigar la prueba de tarjetas, Stripe usa una serie de controles automatizados y manuales, como limitadores de velocidad, alertas y revisiones continuas con modelos de entrenamiento de prueba de tarjetas para detectar los ataques automáticamente. Estos modelos solo activan desafíos cuando hay un ataque de prueba de tarjetas en curso, por lo que esos usuarios reales casi nunca ven un CAPTCHA, solo los bots. Gracias a esto, la prueba de tarjetas en las empresas que usan Checkout se ha reducido un 80 %, una cifra espectacular, sin percibir prácticamente ningún impacto en la conversión.

Ten en cuenta que también puedes escribir reglas personalizadas como «Bloquear si se rechaza más de 3 veces desde una dirección IP dada» para reducir los ataques de pruebas de tarjetas.

Extracción de valor

Tarjetas de crédito robadas (comportamiento de usuario nuevo)

En este vector de fraude, el actor fraudulento utiliza la tarjeta robada validada en su dispositivo personal o en un dispositivo que emplea para cometer fraude.

Este vector se suele explotar mediante un uso abusivo, ya sea a través de ataques masivos generados por scripts o, a una escala más pequeña, con objetivos de fraude más pequeños. Sea como fuere, existen atributos de reglas que miden la antigüedad de una cuenta en Stripe, como hours_since_email_first_seen_on_stripe, que junto a risk_score y otras funciones mantienen a raya a esos nuevos titulares de tarjetas. Además, las restricciones de velocidad sobre direcciones IP, correos electrónicos y tarjetas pueden reforzar la protección para los comerciantes frente a ataques por volumen donde los estafadores intentan monetizar las credenciales robadas lo más rápido posible.

Tarjetas de crédito robadas (comportamiento de enmascaramiento)

En este vector de fraude, el estafador se sirve de la tarjeta robada validada en su dispositivo personal o en un dispositivo utilizado para cometer fraude, o bien el estafador ha vulnerado una cuenta de suscripción y accedido a la información de la tarjeta de crédito almacenada en la cuenta.

A continuación, intentará enmascarar su presencia de la mejor forma posible con estas tres estrategias:

• Usar el mismo nombre que en las transacciones efectuadas anteriormente.

• Usar la misma dirección de facturación que en las transacciones efectuadas anteriormente.

• Usar una VPN para que parezca que se trata del titular original de la tarjeta. Es posible que configure la VPN en la misma ciudad e incluso en el mismo bloque.

• Modificar tan solo un detalle mínimo, como la dirección de correo electrónico o el número de teléfono.

• Cambiar la dirección de envío respecto a transacciones anteriores (si la transacción implica productos físicos), que implica una distancia potencialmente llamativa entre la dirección de envío y la dirección de facturación. Esta no se puede considerar una señal absolutamente fiable.

El comportamiento de enmascaramiento que acabamos de describir provoca que resulte difícil analizar quién realiza realmente la transacción, ¿será el titular original de la tarjeta o un estafador que se ha adueñado de la cuenta? Lo que suele suceder a menudo es que este tipo de fraude pasa desapercibido durante largos períodos de tiempo, sin que lo detecten el comerciante ni el titular original.

Aquí la estrategia es similar: lo que busca el estafador es obtener el máximo valor en el mínimo tiempo posible con esas credenciales robadas. Las reglas que usan funciones para limitar la velocidad, junto con riskscore, fallos en cvccheck o fallos en comprobaciones del código postal, pueden ayudar a protegerse de este comportamiento.

Otras prácticas recomendadas

Te proponemos las mejores prácticas complementarias para que optimices cómo escribes las reglas en Radar.

La importancia de usar Stripe.js

• Incluye stripe.js en la ruta de pagos para señalizar el fraude al máximo
  
• Para sacarle todo el partido a Radar sin que ello en el tiempo de carga de las páginas, carga stripe.js de forma asíncrona en las páginas que no sean de pago
  
• Lo más sencillo es ponerlo junto a las etiquetas de script de Google Analytics
  
• El tamaño completo de stripe.js es de 29,6 kb (comprimido mediante gzip)
  
  • En un futuro, radar.js se podrá incluir de forma separada de stripe.js
    

Conclusión

Las reglas pueden ser una herramienta extraordinariamente poderosa para ayudarte a personalizar tu protección contra el fraude. Al implementar una lógica única, con la información proporcionada en algunas de las mejores prácticas que se indican en esta guía, puedes crear una configuración de prevención del fraude en Radar específica para las necesidades de tu empresa.

Si quieres consultar más información sobre Radar for Fraud Teams, puedes hacerlo aquí.

Si ya utilizas Radar for Fraud Teams, echa un vistazo a la página Reglas de tu Dashboard para comenzar a escribir reglas.

Otras notas

Radar para plataformas

¿Eres una plataforma que usa Stripe Connect? Si es así, cualquier regla que crees solo se aplicará a los pagos creados en la cuenta de la plataforma (en los términos de Connect, estas son cargos destination o on-behalf-of).
Los pagos creados directamente en la cuenta conectada están sujetos a las reglas de la cuenta.

Radar for Terminal

Radar no detecta los cargos de 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.