Radar for Fraud Teams: Reglas 101

En esta guía abarca diferentes temas relacionados con las reglas de Radar, incluidas más de 100 reglas de Radar que puedes usar, así como prácticas recomendadas en materia de backtesting, escritura de reglas y mucho más.

Radar
Radar

Combate el fraude con la eficacia de la red de Stripe.

Más información 
  1. Introducción
  2. La importancia del orden de las reglas y la jerarquía
  3. Hoja de características clave del lenguaje de las reglas
    1. Cómo redactar reglas usando lenguaje natural
  4. Reglas frecuentes del uso de Radar
    1. Reglas de prevención de cobro o prueba de tarjetas
    2. Reglas que te ayudan a prevenir el fraude con SKU de riesgo conocidos
    3. Reglas que te ayudan a evitar el abuso de pruebas de tarjetas de prepago
  5. Analiza el fraude para guiar la creación de reglas
    1. Revisión de fraude
    2. Obtén más información sobre los generadores de fraude
  6. Existen tres tipos de atributos para crear reglas
    1. Tipo 1
    2. Tipo 2
    3. Atributos basados en la frecuencia
    4. Atributos basados en los datos de la tarjeta
    5. Atributos basados en los datos de pago
    6. Atributos basados en los datos del cliente
    7. Tipo 3
  7. ¿Cómo usar listas guardadas en tus reglas (p. ej., permitir listas, bloquear listas)?
  8. ¿Cómo escribir reglas complejas con varias condiciones?
  9. Reglas de backtesting
    1. ¿Cómo realizar Backtesting en el Dashboard?
    2. ¿Cómo realizar análisis de backtesting personalizados?
  10. Vectores de fraude frecuentes
    1. Pruebas
    2. Extracción de valor
  11. Otras prácticas recomendadas
    1. La importancia del uso de Stripe.js
  12. Conclusión
    1. Otras notas

Las reglas predeterminadas de Stripe usan machine learning para predecir y bloquear una cantidad sustancial de pagos fraudulentos. Para las empresas que necesitan más control sobre qué pagos se deben revisar, permitir o bloquear, las reglas son una herramienta sólida de personalización de protección contra fraudes.

En esta guía, abarcamos una variedad de temas relacionados con las reglas de Radar, incluidas más de 100 reglas de Radar que puedes usar, así como prácticas recomendadas en materia de backtesting, escritura de reglas y mucho más.

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

El orden en el que se enumeran las reglas de la página de Radar es importante. Cada pago se evalúa en función de las reglas que hayas creado y puesto en práctica en el siguiente orden:

  1. Request 3DS: las reglas que solicitan una autenticación mediante 3D Secure cuando se usan con la API Payment Intents o Checkout. Independientemente de las coincidencias con esta regla las reglas permitir, bloquear o revisar se evalúan después.
  2. Allow: reglas que permiten que se procese un pago. Estas reglas deben implementarse con muchísimo cuidado, ya que anulan todas las demás, a excepción de las de 3D Secure, incluidos los modelos de machine learning de Stripe, y deben usarse con la máxima precaución. Solo los comerciantes que han procesado más de USD 100,000 pueden escribir reglas de permiso.
  3. Block: reglas que bloquean un pago y lo rechazan. Si se rechaza un pago, no se evalúa en función de ninguna regla de revisión.
  4. Review: estos pagos se siguen procesando, y se cobra al cliente, pero se marcan para que puedas revisarlos si así lo deseas.

Para poner esto en práctica, usemos las siguientes reglas como ejemplo. Todos los pagos inferiores de 10 dólares deberían procesarse. Esto es así porque la primera regla permite el pago de USD 1500 realizado dentro de Estados Unidos con un nivel de riesgo normal también se permitiría, a pesar de la regla de bloquear pagos de más de USD 1000. Esto es así por la segunda regla de la lista, que permite pagos hechos desde Estados Unidos y con un nivel de riesgo normal. Una vez que se activa una regla en particular, no se evalúa ninguna regla más.

  • Allow payments less than $10 (Permitir pagos menores a USD 10).

  • Allow payments within the US and with a risk level of normal (Permitir pagos dentro de EE. UU. con un nivel de riesgo normal).

  • Block payments where the risk level is high (Bloquear pagos con un nivel de riesgo alto).

  • Block payments greater than $1,000 (Bloquear pagos mayores a USD 1000).

  • Review payments with a card issued outside the US (Revisar pagos con tarjetas emitidas fuera de EE. UU.).

Hoja de características clave del lenguaje de las reglas

Las reglas usan un lenguaje similar a SQL y hay diferentes operadores que puedes utilizar según el tipo de datos que uses para crear tu regla. A continuación encontrarás una hoja de referencias clave.

Operador
Cadena
Metadatos
País
Numérico
Descripción
Ejemplo
=
Igual a

:card_country: = 'us'

!=
No igual a

:card_funding: != 'prepaid'

<
Menor que

:amount_in_gbp: < 10.00

>
Mayor de

:amount_in_usd: > 500.00

<=
Inferior o igual a

:amount_in_eur:<= 100.00

>=
Superior o igual a

:amount_in_cad: >= 10.00

IN
Está en el grupo

:card_country: IN ('gb', 'ie')

INCLUDES
Contiene la cadena

:ip_address: INCLUDES '192.168'

LIKE
Coincide con el patrón indicado

:email: LIKE 'fraud%@stripe.com'

Si deseas verificar explícitamente la existencia de un atributo o un atributo de metadatos, no uses el operador !=. En cambio, usa la función is_missing. Ingresa esta función con la clave de metadatos o el atributo que pueda estar faltando. Por ejemplo, si no tienes acceso a la dirección de correo electrónico del cliente, puedes escribir una regla que coincida con todos los pagos:

  • Review if is_missing(:email_domain:)

O bien, puedes escribir una regla que coincida con todos los pagos para los que TIENES acceso:

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

Cómo redactar reglas usando lenguaje natural

Si quieres escribir reglas con más facilidad o no tienes seguridad respecto de qué atributos usar para tratar un escenario específico de fraude, el Asistente de Radar con tecnología de IA traducirá las indicaciones del lenguaje natural en reglas que tengan la sintaxis de Radar. También puedes hacer un backtest de la regla directamente desde el Asistente de Radar. De este modo, puedes ver cuál hubiera sido el rendimiento histórico antes de implementar dicha regla.

Reglas frecuentes del uso de Radar

La siguiente es una lista de algunas reglas de Radas que se usan con frecuencia, en función de diferentes objetivos.

Reglas de prevención de cobro o prueba de tarjetas

Block if :total_charges_per_ip​_address_hourly: > 1

Esta regla es útil con las pruebas de tarjetas. Bloqueará los cargos si se autorizó correctamente una dirección IP en tu cuenta más de una vez.

Block if :blocked_charges_per_ip​_address_hourly: > 1

Si deseas ser más riguroso en la prevención de pruebas de tarjetas, usa esa regla en conjunto con :total_charges_per_ip_address_hourly:

Block if :total_charges_per​_card_number_hourly: > 1

Esta regla es útil con el cobro de tarjetas. Bloqueará los cargos si se autorizó correctamente un número de tarjeta en tu cuenta en la última hora más de una vez.

Block if :blocked_charges_per_card​_number_hourly: > 1

Si deseas ser más riguroso en la prevención de cobro de tarjetas, usa esta regla en conjunto con :total_charges_per_card_number_hourly:

Block if :address_zip_check: != 'pass'

Asegúrate de recopilar los códigos postales en tu formulario del proceso de compra para usar esta regla. Esta regla bloqueará los cargos si el emisor de la tarjeta no puede validar el código postal proporcionado con lo que se archivó para la tarjeta.

Block if :cvc_check:: != 'pass'

Asegúrate de recopilar los CVC en tu formulario del proceso de compra para usar esta regla. Esta regla bloqueará los cargos si el emisor de la tarjeta no puede validar el código de CVC (o CVV) proporcionado con lo que se archivó para la tarjeta.

Reglas que te ayudan a prevenir el fraude con SKU de riesgo conocidos

Esta regla requiere metadatos o definir información de SKU como descripción del cargo. Estos pagos se siguen procesando, y se le cobra al cliente, pero se marcan para que puedas revisarlos nuevamente.

Review if ::SKU Category:: IN ('baby formula', 'personal hygiene')

Supongamos que eres un supermercado y nos envías metadatos con la categoría SKU. Observas que los pedidos que contienen items etiquetados con la categoría SKU 'personal hygiene' o 'baby formula' suelen representar un riesgo mayor. Esta regla colocará todos los pedidos que incluyan estos items en la lista de Revisión manual de tu Dashboard de Stripe para que puedas realizar una segunda revisión. Ten en cuenta que estos pagos se procesarán y que serán cobrados al cliente, a menos que canceles el pedido de forma manual.

Review if :charge_description: = 'Trial class'

Supongamos que vendes dos productos ('Trial class' and '10 class package') y que envías a Stripe el nombre del producto como descripción del cargo. Esta regla colocará todos los pedidos cuya descripción del cargo sea exactamente 'Trial class en la lista de Revisión manual de tu Dashboard de Stripe para que puedas realizar una segunda revisión. Ten en cuenta que estos pagos se procesarán y que serán cobrados al cliente, a menos que canceles el pedido de forma manual.

Reglas que te ayudan a evitar el abuso de pruebas de tarjetas de prepago

Block if :card_funding: = 'prepaid' OR :card_funding: = 'unknown'

Supongamos que eres un comerciante minorista que ofrece pruebas en casa y observaste un aumento repentino en los estafadores que usan tarjetas de prepago a las que luego no puedes efectuar cargos Esta regla bloqueará todos los pedidos que no se paguen con una tarjeta de débito o crédito.

Analiza el fraude para guiar la creación de reglas

Revisión de fraude

Para crear reglas más efectivas, debes comprender profundamente la actividad de fraude en tu cuenta. Es importante caracterizar los diferentes tipos de vectores de fraude presentes. Algunas preguntas que puedes formular:

  • ¿Las cuentas se registran y comienzan de inmediato a realizar compras fraudulentas mediante correos electrónicos y nombres de titular de cuenta nuevos?

  • ¿Están los actores fraudulentos accediendo a cuentas antiguas y realizando compras de cantidades inusualmente grandes?

  • ¿Hay un sesgo en el fraude dependiendo de las redes de tarjetas o países de tarjetas específicos?

  • ¿Se produce fraude a gran velocidad, lo que significa que se hacen varios intentos con la misma tarjeta, correo electrónico o dirección IP en un período breve?

Si revisamos la alta velocidad en la que tiene lugar el fraude en la captura de pantalla anterior, las reglas que utilizan authorized_charges_per_card_number_hourly o authorized_charges_per_ip_address_hourly podrían abordar potencialmente este vector de fraude.

Obtén más información sobre los generadores de fraude

La información sobre fraude te ayudan a identificar y abordar rápidamente las causas del fraude sin tener que analizar los datos de las transacciones de forma manual. La pestaña Información en el Dashboard muestra los atributos principales que están asociados a las transacciones fraudulentas. Desde allí, puedes agregar una regla para abordar ese atributo directamente desde la pestaña Información.

Existen tres tipos de atributos para crear reglas

Tipo 1

Atributos de posteriores a la autorización: estas reglas están disponibles para su uso general. Si usas estos atributos, debes usar dos puntos (:) antes y después del atributo posteriores a la autorización como :cvc_check:.

Atributos
Descripción

:address_line1_check:

Una revisión por parte del emisor de la tarjeta para hacer coincidir la primera línea de la dirección de facturación proporcionada (por lo general, el nombre de la calle y el número) con la información del titular de la tarjeta que el emisor tiene en sus registros.

:address_zip_check:

Una revisión por parte del emisor de la tarjeta para hacer coincidir el código postal proporcionado con la información del titular de la tarjeta que el emisor tiene en sus registros.

:cvc_check​:

Una revisión por parte del emisor de la tarjeta para hacer coincidir el CVC (también llamado CVV) proporcionado con la información del titular de la tarjeta que el emisor tiene en sus registros.
Posibles valores
Descripción

pass

Los datos proporcionados son correctos.

fail

Los datos proporcionados no son correctos.

unavailable

El emisor de la tarjeta del cliente no verificará los datos proporcionados. No todos los emisores de tarjetas ni todos los países admiten la verificación de la dirección.

unchecked

Se proporcionaron los datos, pero aún no han sido verificados. El emisor de la tarjeta del cliente a la larga verificará los datos proporcionados.

not_provided

No se proporcionaron los datos a Stripe.
Los valores distinguen mayúsculas y minúsculas.

A continuación, encontrarás un ejemplo de cómo usar atributos posteriores a la autorización:

  • Block if :address_line1_check: != 'pass' Con esta regla, se bloquearán los cargos que no pasen específicamente la verificación del emisor de la tarjeta para que la primera línea de la dirección de facturación proporcionada coincida con la información guardada del titular de tarjeta. Esto significa que si la verificación aparece como ‘unavailable’ («no disponible»); si la información aparece como ‘unchecked’ («no verificada») por el emisor, o si los datos aparecen como ‘not_provided’ («no proporcionados»), se bloqueará el pago.

Tipo 2

Atributos estándar: estas reglas están disponibles para su uso general. Necesitas usar dos puntos (:) antes y después de los atributos estándar, como :card_bin:. Dividimos nuestros atributos estándar en cuatro categorías:

  • Atributos basados en la frecuencia: son útiles para prevenir las pruebas y los cobros de 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 que otros requieren números. Aquí te presentamos un ejemplo de cada atributo para que sea más comprensible. Si el atributo requiere una cadena, como :card_bin:, verás en el ejemplo que el número aparece entre ‘ ’. Por ejemplo, :card_bin: = ‘424242’. Si bien necesita un número, no tendrá ‘ ’, como :amount_in_usd: > 250.

Atributos basados en la frecuencia

Hay cuatro tipos de atributos basados en la frecuencia que son especialmente útiles para prevenir el fraude de tarjetas robadas, la prueba y el cobro de tarjetas.

  1. Authorization: atributo basado en las autorizaciones del emisor
  2. Charge: basado en los cargos
  3. Decline: basado en los pagos rechazados del emisor
  4. Block: basado en los bloqueos hechos por el modelo de machine learning de Radar

También hay otros atributos basados en los resultados de cobro, como autorizaciones (basado en las autorizaciones exitosas del emisor), cargos (basado en los intentos de cobros), rechazos (basado en los pagos rechazados por el emisor), disputas (basado en las disputas de transacciones marcadas como fraudulentas) y bloqueos (basado en los bloqueos hechos por el modelo de machine learning de Radar. Los resultados se combinan con los datos del cliente (correo electrónico, dirección IP, nombre o ID del cliente) para conformar un atributo.

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

  1. Basadas en los resultados del cargo (p. ej., authorized_charges_per_email_hourly, blocked_charges_per_email_hourly), en las que el resultado son autorizaciones, intentos de cobro, pagos rechazados, disputas y bloqueos exitosos.
  2. Basadas en los vínculos entre la información del cliente y una tarjeta o una dirección IP (p. ej., name_count_for_card_weekly, email_count_for_ip_hourly).

Las reglas de frecuencia excluyen los pagos que se están procesando en el momento. Por ejemplo, authorized_charges_per_email_hourly representa la cantidad de intentos de cobro que se realizaron correctamente desde una dirección de correo electrónico en la última hora. Para el primer intento de cobro en una hora determinada para un correo electrónico, authorized_charges_per_email_hourly tiene un valor de 0. En los primeros pagos exitosos, el segundo intento de cobro de ese correo electrónico dentro de la misma hora tiene un valor de 1 y así sucesivamente.

Atributo
Descripción

:authorized_charges_per​_card_number_all_time:

La cantidad de cargos que se autorizaron correctamente para esta tarjeta en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:authorized_charges_per​_card_number_weekly:

La cantidad de cargos que se autorizaron correctamente para esta tarjeta durante la última semana en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_card_number_daily:

La cantidad de cargos que se autorizaron correctamente para esta tarjeta durante el último día en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_card_number_hourly:

La cantidad de cargos que se autorizaron correctamente para esta tarjeta durante la última hora en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_email_all_time:

La cantidad de cargos que se autorizaron correctamente para este correo electrónico en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:authorized_charges_per​_email_weekly:

La cantidad de cargos que se autorizaron correctamente para este correo electrónico durante la última semana en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_email_daily:

La cantidad de cargos que se autorizaron correctamente para este correo electrónico durante el último día en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_email_hourly:

La cantidad de cargos que se autorizaron correctamente para este correo electrónico durante la última hora en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_ip_address_all_time:

La cantidad de cargos que se autorizaron correctamente para esta dirección IP en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:authorized_charges_per​_ip_address_weekly:

La cantidad de cargos que se autorizaron correctamente para esta dirección IP durante la última semana en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_ip_address_daily:

La cantidad de cargos que se autorizaron correctamente para esta dirección IP durante el último día en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_ip_address_hourly:

La cantidad de cargos que se autorizaron correctamente para esta dirección IP durante la última hora en tu cuenta. (Nota: El límite superior es ≤25).

:authorized_charges_per​_customer_daily:

La cantidad de veces que se autorizó un cliente en tu cuenta en las últimas 24 horas. (Esta cantidad no incluye el pago que se está evaluando en este momento).

:authorized_charges_per​_customer_hourly:

La cantidad de veces que se autorizó un cliente en tu cuenta en el transcurso de la última hora. (Esta cantidad no incluye el pago que se está evaluando en este momento).

:blocked_charges_per​_card_number_daily:

La cantidad de veces que un número de tarjeta fue bloqueado por los modelos de machine learning de Stripe en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:blocked_charges_per​_card_number_hourly:

La cantidad de veces que un número de tarjeta fue bloqueado por los modelos de machine learning de Stripe en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:blocked_charges_per​_customer_daily:

La cantidad de veces que un cliente fue bloqueado por los modelos de machine learning de Stripe en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:blocked_charges_per​_customer_hourly:

La cantidad de veces que un cliente fue bloqueado por los modelos de machine learning de Stripe en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:blocked_charges_per​_ip_address_daily:

La cantidad de veces que una dirección IP fue bloqueada por los modelos de machine learning de Stripe en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:blocked_charges_per​_ip_address_hourly:

La cantidad de veces que una dirección IP fue bloqueada por los modelos de machine learning de Stripe en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:total_charges_per​_card_number_daily:

La cantidad de veces que se intentó efectuar un cargo en una tarjeta en tu cuenta durante las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:total_charges_per​_card_number_hourly:

La cantidad de veces que se intentó efectuar un cargo en una tarjeta en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:total_charges_per​_customer_daily:

La cantidad de veces que un cliente intentó efectuar un cargo en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:total_charges_per​_customer_hourly:

La cantidad de veces que un cliente intentó efectuar un cargo en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:total_charges_per​_ip_address_daily:

La cantidad de veces que una dirección IP intentó efectuar un cargo en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:total_charges_per​_ip_address_hourly:

La cantidad de veces que una dirección IP intentó efectuar un cargo en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:declined_charges_per​_card_number_daily:

La cantidad de veces que un número de tarjeta fue rechazado por el emisor de la tarjeta en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:declined_charges_per​_card_number_hourly:

La cantidad de veces que un número de tarjeta fue rechazado por el emisor de la tarjeta en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:declined_charges_per​_customer_daily:

La cantidad de veces que un cliente fue rechazado por el emisor de la tarjeta en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:declined_charges_per​_customer_hourly:

La cantidad de veces que un cliente fue rechazado por el emisor de la tarjeta en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:declined_charges_per​_ip_address_daily:

La cantidad de veces que una dirección IP fue rechazada por el emisor de la tarjeta en tu cuenta en las últimas 24 horas. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:declined_charges_per​_ip_address_hourly:

La cantidad de veces que una dirección IP fue rechazada por el emisor de la tarjeta en tu cuenta en la última hora. Esta cantidad no incluye el pago que se está evaluando en este momento (p. ej., 4).

:declined_charges_per​_email_all_time:

La cantidad de cargos rechazados para este correo electrónico en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:declined_charges_per​_email_weekly:

La cantidad de cargos rechazados para este correo electrónico durante la última semana en tu cuenta. (Nota: El límite superior es ≤25).

:declined_charges_per​_email_daily:

La cantidad de cargos rechazados para este correo electrónico durante el último día en tu cuenta. (Nota: El límite superior es ≤25).

:declined_charges_per​_email_hourly:

La cantidad de cargos rechazados para este correo electrónico durante la última hora en tu cuenta. (Nota: El límite superior es ≤25).

:dispute_count_on_ip_all_time:

La cantidad de disputas por fraude asociadas a cargos provenientes de esta dirección IP en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:dispute_count_on_ip_weekly:

La cantidad de disputas por fraude asociadas a cargos en tu cuenta provenientes de esta dirección IP en la última semana. (Nota: El límite superior es ≤25).

:dispute_count_on_ip_daily:

La cantidad de disputas por fraude asociadas a cargos en tu cuenta provenientes de esta dirección IP en el último día. (Nota: El límite superior es ≤25).

:dispute_count_on_ip_hourly:

La cantidad de disputas por fraude asociadas a cargos en tu cuenta provenientes de esta dirección IP en la última hora. (Nota: El límite superior es ≤25).

:email_count_for​_card_all_time:

La cantidad de correos electrónicos asociados a esta tarjeta provenientes de transacciones en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:email_count_for​_card_weekly:

La cantidad de correos electrónicos asociados a esta tarjeta provenientes de transacciones en tu cuenta en la última semana. (Nota: El límite superior es ≤25).

:email_count_for​_card_daily:

La cantidad de correos electrónicos asociados a esta tarjeta provenientes de transacciones en tu cuenta en el último día. (Nota: El límite superior es ≤25).

:email_count_for​_card_hourly:

La cantidad de correos electrónicos asociados a esta tarjeta provenientes de transacciones en tu cuenta en la última hora. (Nota: El límite superior es ≤25).

:email_count_for​_ip_all_time:

La cantidad de correos electrónicos asociados a esta dirección IP provenientes de transacciones en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:email_count_for​_ip_weekly:

La cantidad de correos electrónicos asociados a esta dirección IP provenientes de transacciones en tu cuenta en la última semana. (Nota: El límite superior es ≤25).

:email_count_for​_ip_daily:

La cantidad de correos electrónicos asociados a esta dirección IP provenientes de transacciones en tu cuenta en el último día. (Nota: El límite superior es ≤25).

:email_count_for​_ip_hourly:

La cantidad de correos electrónicos asociados a esta dirección IP provenientes de transacciones en tu cuenta en la última hora. (Nota: El límite superior es ≤25).

:name_count_for​_card_all_time:

La cantidad de nombres asociados a esta tarjeta provenientes de transacciones en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:name_count_for​_card_weekly:

La cantidad de nombres asociados a esta tarjeta provenientes de transacciones en tu cuenta en la última semana. (Nota: El límite superior es ≤25).

:name_count_for​_card_daily:

La cantidad de nombres asociados a esta tarjeta provenientes de transacciones en tu cuenta en el último día. (Nota: El límite superior es ≤25).

:name_count_for​_card_hourly:

La cantidad de nombres asociados a esta tarjeta provenientes de transacciones en tu cuenta en la última hora. (Nota: El límite superior es ≤25).

:total_charges_per​_card_number_all_time:

La cantidad total de cargos para esta tarjeta en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:total_charges_per​_card_number_weekly:

La cantidad total de cargos para esta tarjeta durante la última semana en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_card_number_daily:

La cantidad total de cargos para esta tarjeta durante el último día en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_card_number_hourly:

La cantidad total de cargos para esta tarjeta durante la última hora en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_email_all_time:

La cantidad total de cargos para este correo electrónico en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:total_charges_per​_email_weekly:

La cantidad total de cargos para este correo electrónico durante la última semana en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_email_daily:

La cantidad total de cargos para este correo electrónico durante el último día en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_email_hourly:

La cantidad total de cargos para este correo electrónico durante la última hora en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_ip_address_all_time:

La cantidad total de cargos para esta dirección IP en tu cuenta. Se toman en cuenta los pagos a partir de 2020. (Nota: El límite superior es ≤25).

:total_charges_per​_ip_address_weekly:

La cantidad total de cargos para esta dirección IP durante la última semana en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_ip_address_daily:

La cantidad total de cargos para esta dirección IP durante el último día en tu cuenta. (Nota: El límite superior es ≤25).

:total_charges_per​_ip_address_hourly:

La cantidad total de cargos para esta dirección IP durante la última hora en tu cuenta. (Nota: El límite superior es ≤25).

Atributos basados en los datos de la tarjeta

Atributo
Descripción

:card_bin:

El número de identificación bancaria (BIN) de la tarjeta utilizada para efectuar el pago. Se trata de los primeros seis dígitos del número de la tarjeta (p. ej., «424242»).

:card_brand:

La marca de la tarjeta que se está utilizando para hacer el pago. Los valores admitidos son: «amex» (American Express), «visa» (Visa), «mc» (Mastercard), «dscvr» (Discover), «diners» (Diners Club), «interac» (Interac), «jcb» (JCB) y «cup» (UnionPay).

:card_country:

El código de dos letras correspondiente al país donde se emitió la tarjeta (p. ej., «US»). Para ver una lista de los códigos de países, consulta esta página. Para especificar varios países, usa el operador IN: IN ('GB', 'DE', 'AE').

:card_fingerprint:

La huella de la tarjeta que se está usando para hacer el pago. La huella de la tarjeta es el identificador único de un número de tarjeta en particular. Puedes encontrar este número si te diriges a Pagos e inspeccionas un pago en la sección Método de pago (p. ej., «VfE3rx3VlaQhS8Lp»). Distingue mayúsculas y minúsculas.

:card_funding:

Si la tarjeta es prepaga, de débito o de crédito. Los valores admitidos son: «credit», «debit», «prepaid» y «unknown».

:card_3d_secure_support:

El nivel de soporte de 3D Secure de la tarjeta que se usa para realizar el pago. Los valores admitidos son: «required», «recommended», «optional» y «not_supported».

Atributos basados en los datos de pago

Atributo
Descripción

:amount_in_xyz:

El importe del pago, convertido a la moneda que especificó xyz (p. ej., amount_in_usd). Especifica una de las siguientes monedas admitidas y Stripe calculará de forma automática el importe convertido que se vaya a utilizar: aud, brl, cad, chf, dkk, eur, gbp, hkd, inr, jpy, mxn, nok, nzd, ron, sek, sgd o usd. No se deben utilizar subunidades de monedas (p. ej., dólares estadounidenses, no centavos; p. ej., :amount_in_usd: > 250).

:average_usd_amount​_attempted_on_card_all_time:

El importe promedio (en USD) de las transacciones que se intentaron para la tarjeta en tu cuenta. Se toman en cuenta los pagos a partir de 2020.

:average_usd_amount​_successful_on_card_all_time:

El importe promedio (en USD) de las transacciones autorizadas para la tarjeta en tu cuenta. Se toman en cuenta los pagos a partir de 2020.

:risk_level:

El nivel de riesgo de un pago según lo determine Stripe. Los valores admitidos son: «normal», «elevated», «highest» y «not_assessed».

:risk_score:

La puntuación de riesgo de un pago según lo determine Stripe (p. ej., >50). El rango de valores oscila entre 0 (riesgo más bajo) y 100 (riesgo más alto). Una puntuación de riesgo a partir de 65 corresponde a un nivel de riesgo «elevado», mientras que una puntuación de riesgo a partir de 75 corresponde a un nivel de riesgo «muy alto».

:charge_description:

La descripción proporcionada con el pago (p. ej., «clase de prueba»).

:is_recurring:

Identifica si el pago es recurrente, por ejemplo, por suscripciones. (Este es un valor booleano, por lo que debes usar :is_recurring: para los casos en los que es verdadero o NOT :is_recurring: para los casos en que no lo es. No puedes usar !=).

:is_off_session:

Indica cuando la acción directa del usuario no activa un pago de Stripe Billing o cuando se estableció el marcador off_session en la confirmación de PaymentIntent. (Este es un valor booleano, por lo que debes usar :is_off_session: para los casos en los que es verdadero o NOT :is_off_session: para los casos en que no lo es. No puedes usar !=).

:digital_wallet:

El tipo de cartera digital que se usa para almacenar la información de pago. Los valores admitidos son: «android_pay», «amex_express_checkout», «apple_pay», «masterpass», «samsung_pay», «unknown», «visa_checkout» y «none».

:destination:

Para los usuarios Connect que crean cargos a un Destino, la cuenta de destino a nombre de la que se hace el cargo (p. ej., «acct_19KCB9AlaaEw6AgR»). Distingue mayúsculas y minúsculas.

:is_checkout:

Identifica si el pago se procesa mediante Checkout. Este atributo solo se aplica a los pagos procesados con la nueva versión de Checkout y no captura pagos con la versión heredada de Checkout. (Este es un valor booleano, por lo que debes usar :is_checkout: para los casos en los que es verdadero o NOT :is_checkout: para los casos en que no lo es. No puedes usar !=).

:is_3d_secure​_authenticated:

Identifica si el pago es precedido por una verificación con autenticación mediante 3D Secure finalizada correctamente. La autenticación puede basarse en el riesgo o en un desafío. (Este es un valor booleano, por lo que debes usar :is_3d_secure_authenticated: para los casos en los que es verdadero o NOT :is_3d_secure_authenticated: para los casos en que no lo es. No puedes usar !=).

:is_3d_secure:

Identifica si el pago usa una fuente con 3D Secure. (Este es un valor booleano, por lo que debes usar :is_3d_secure: para los casos en los que es verdadero o NOT :is_3d_secure: para los casos en que no lo es. No puedes usar !=).

:has_liability_shift:

Verdadero si se cambió la responsabilidad por el fraude de este pago (Este es un valor booleano, por lo que debes usar :has_liability_shift: para los casos en los que es verdadero o NOT :has_liability_shift para los casos en que no lo es. No puedes usar !=).

:seconds_since_card​_first_seen:

La cantidad de segundos que transcurrieron desde la primera vez que se vio la tarjeta del pago en tu cuenta. Se toman en cuenta los pagos a partir de 2020.

:seconds_since_first_successful​_auth_on_card:

La cantidad de segundos que transcurrieron desde la primera autorización realizada correctamente para la tarjeta asociada al pago en tu cuenta. Se toman en cuenta los pagos a partir de 2020.

:total_usd_amount_failed​_on_card_all_time:

El importe total (en USD) de las transacciones de esta tarjeta que fallaron (bloqueadas o rechazadas) en tu cuenta. Se toman en cuenta los pagos a partir de 2020.

:total_usd_amount_successful​_on_card_all_time:

El importe total (en USD) de las transacciones autorizadas para la tarjeta en tu cuenta. Se toman en cuenta los pagos a partir de 2020.

Atributos basados en los datos del cliente

Atributo
Descripción

:ip_country:

El código de dos letras correspondiente a la geolocalización por país de la dirección IP desde la que se origina el pago (p. ej., «GB»). Para ver una lista de los códigos de países, consulta esta página. Para especificar varios países, usa el operador IN: IN ('GB', 'DE', 'AE').

:ip_address:

La dirección IP desde la que se origina el pago (p. ej., «192.168.0.1» para especificar una sola IP o, si deseas emitir una red amplia, puedes usar INCLUDES '192.168' para incluir todas las direcciones IP que comparten los primeros seis dígitos).

:is_anonymous_ip:

Identifica si la dirección IP desde la que se origina el pago es un proxy conocido o un nodo de salida de Tor. Esta información se actualiza a diario. (Este es un valor booleano, por lo que debes usar :is_anonymous_ip: para los casos en los que es verdadero o NOT :is_anonymous_ip: para los casos en que no lo es. No puedes usar !=).

:is_my_login_ip:

Identifica si la dirección IP desde la que se origina el pago se usó alguna vez para iniciar sesión en tu cuenta de Stripe. Este atributo puede utilizarse como proxy para «es mi dirección IP». (Este es un valor booleano, por lo que debes usar :is_my_login_ip: para los casos en los que es verdadero o NOT :is_my_login_ip: para los casos en que no lo es. No puedes usar !=).

:email:

La dirección de correo electrónico proporcionada con el pago (p. ej., «usuario@ejemplo.com»).

:email_domain:

El dominio de la dirección de correo electrónico proporcionada con el pago (p. ej., «ejemplo.com»).

:is_disposable_email:

Identifica si la dirección de correo electrónico proporcionada con el pago se utiliza con un proveedor de direcciones de correo electrónico descartables. Stripe conserva una lista de dominios correspondiente a las direcciones de correo electrónico descartables para proporcionar este atributo. (Este es un valor booleano, por lo que debes usar :is_disposable_email: para los casos en los que es verdadero o NOT :is_disposable_email: para los casos en que no lo es. No puedes usar !=).

:billing_address:

La dirección de facturación completa del titular de la tarjeta proporcionada (p. ej., «510 Townsend, San Francisco, CA 94110»).

:billing_address_line1:

La primera línea de la dirección de facturación proporcionada del titular de la tarjeta, por lo general, el nombre y el número de la calle (p. ej., «510 Townsend»).

:billing_address_line2:

La segunda línea de la dirección de facturación del titular de la tarjeta proporcionada, por lo general, el número del departamento o la unidad (p. ej., «Apt 5B»).

:billing_address_postal_code:

El código postal de la dirección de facturación del titular de la tarjeta proporcionada (p. ej., «94110»).

:billing_address_city:

La ciudad de la dirección de facturación del titular de la tarjeta proporcionada (p. ej. «San Francisco»).

:billing_address_state:

El estado de la dirección de facturación del titular de la tarjeta proporcionada (p. ej. «CA»).

:billing_address_country:

El código de dos letras correspondiente al país de la dirección de facturación del titular de la tarjeta (p. ej., «US»). Para ver una lista de los códigos de países, consulta esta página. Para especificar varios países, usa el operador IN: IN ('US', 'DE', 'AE').

:seconds_since​_email_first_seen:

La cantidad de segundos desde que la dirección de correo proporcionada con el pago se vio por primera vez en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

:seconds_since​_email_first_seen_on_stripe:

La cantidad de segundos que transcurrieron desde la primera vez que la dirección de correo electrónico proporcionada con el pago se vio en Stripe. Se toman en cuenta los pagos a partir de 2020.

:shipping_address:

La dirección de envío completa proporcionada (p. ej., «510 Townsend, San Francisco, CA 94110»).

:shipping_address_line1:

La primera línea de la dirección de envío proporcionada, por lo general, el nombre y el número de la calle (p. ej., «510 Townsend»).

:shipping_address_line2:

La segunda línea de la dirección de envío proporcionada, por lo general, el número del apartamento o la unidad (p. ej., «Apt 5b»).

:shipping_address_postal_code:

El código postal de la dirección de envío proporcionada (p. ej., «94110»).

:shipping_address_city:

La ciudad de la dirección de envío proporcionada (p. ej., «San Francisco»).

:shipping_address_state:

El estado de la dirección de envío proporcionada (p. ej., «CA»).

:shipping_address_country:

El código de dos letras correspondiente al país de la dirección de envío proporcionada (p. ej., «US»). Para ver una lista de los códigos de países, consulta esta página. Para especificar varios países, usa el operador IN: IN ('US', 'DE', 'AE').

A continuación, encontrarás un ejemplo de cómo usar atributos estándar:

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

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

Tipo 3

Atributos de metadatos: estos atributos dependerán de los metadatos que envíes a Stripe. Con estos atributos, debes usar dos puntos dobles (::) antes y después de los atributos estándar, p. ej., ::Customer Age::. Los atributos de metadatos pueden operar como cadenas o como números. Si se usan como cadenas, los atributos de metadatos distinguen entre mayúsculas y minúsculas.

Los metadatos pueden usarse para crear reglas sólidas, como colocar los cobros en revisión manual según el SKU que se compró, o reducir la fricción para los clientes frecuentes. Consulta esta guía para aprender cómo pasar más metadatos.

Los atributos de metadatos se escriben con la siguiente estructura:

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

Supongamos que tenemos pagos con los siguientes datos de clave/valor almacenados en el campo metadatos:

Nombre de los metadatos
Valor de los metadatos
Customer age
22
Item ID
5A381D
Category ID
groceries

Puedes escribir una regla para colocar los pagos que coincidan con el siguiente criterio en revisión.

  • Review if ::Customer Age:: < 30

Puedes escribir reglas con atributos de metadatos y otros atributos compatibles mencionados en este documento. Por ejemplo, puedes escribir una regla que ponga un pago en revisión si el ID del ítem es 5A381D y el monto del pago supera los USD 1000.

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

Los atributos de metadatos también admiten que el operador IN coincida con varios valores. Por ejemplo, puedes escribir una regla que coloque un pago en revisión si el ID de la categoría es «almacén», «electrónicos» o «ropa».

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

El operador INCLUDES puede usarse con reglas de atributos de metadatos y otros atributos de cadena para que coincidan con cadenas secundarias. Por ejemplo, puedes escribir una regla que coloque un pago en revisión si el ID de ítem incluye la cadena A381, como «A381», «5A381D», «A381D», «5A381» y más.

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

También se puede acceder a los metadatos en los objetos destino y clientes (si son los que se usan para un pago determinado). Estos atributos se escriben con la siguiente estructura:

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

Supongamos que tienes un cliente con los siguientes metadatos:

Nombre de los metadatos
Valor de los metadatos
Trusted
true

Puedes escribir una regla que siempre permita pagos si el campo de metadatos Trusted del cliente es true.

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

O bien, si tienes un destino con los siguientes metadatos:

Nombre de los metadatos
Valor de los metadatos
Category
new

Puedes escribir una regla que coloque el pago en revisión si el campo de metadatos Category del destino es new.

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

¿Cómo usar listas guardadas en tus reglas (p. ej., permitir listas, bloquear listas)?

Puedes hacer referencia a un grupo de valores en tus reglas a través de listas creadas previamente (p. ej., permitir listas o bloquear listas). Si deseas bloquear una lista de correos electrónicos, debes crear una lista de bloqueo en lugar de crear varias reglas para cada correo electrónico que desees bloquear.

Todos los alias de listas a los que se haga referencia deben comenzar con @. Para crear una regla que haga referencia a una lista, utiliza la siguiente estructura:

  • {action} [attribute] in [list]

Por ejemplo, supongamos que tienes una lista de países emisores de tarjetas que deseas bloquear. Puedes escribir una regla con varias cláusulas OR:

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

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

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

También puedes crear una lista de países emisores de tarjetas que desees bloquear, denominada card_countries_to_block. A continuación, puedes agregar a la lista los países que elijas y hacer referencia a esta 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 mucho más fácil de editar, y puedes agregarle una gran cantidad de elementos.

Nota: Los comerciantes de la Unión Europea deben conocer el Reglamento sobre bloqueo geográfico y sus prohibiciones referidas al bloqueo de pagos de clientes establecidos en estados miembros de la Unión Europea. Obtén más información sobre este reglamento.

¿Cómo escribir reglas complejas con varias condiciones?

Puedes diseñar condiciones complejas uniendo condiciones básicas con operadores AND, OR y NOT. También puedes usar los símbolos equivalentes: &&, || y !, respectivamente. Al igual que los lenguajes de programación como C, Python y SQL, Stripe admite la prioridad de operador estándar (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 admiten los agrupamientos subcondicionales dentro de condiciones complejas con el uso de paréntesis. Por ejemplo, en el ejemplo anterior puede modificarse para que cambie 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})

El uso de paréntesis en diferentes lugares determina que cada una de las condiciones complejas tenga diferentes resultados.

La función is_missing también puede usarse en conjunciones OR o AND:

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

También puedes usar la función is_missing aunque no falte la condición En este caso, si se bloquean los pagos cuando NO falte :ip_country: y la IP sea de Puerto Rico o los EE. UU.

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

Reglas de backtesting

Como regla general para el análisis de reglas, debe existir un equilibrio entre la prevención del fraude y el bloqueo de transacciones legítimas o falsos positivos. El backtesting ayuda a identificar las reglas que caen dentro del nivel de riesgo que una empresa puede aceptar o logran el equilibrio correcto entre la prevención de disputas y el aumento de falsos positivos. Para estimar el impacto de una regla, puedes hacer combinaciones de backtesting con datos de transacciones de los últimos seis meses a través del Dashboard de Radar y realizar análisis más específicos para comprender cómo hubiera funcionado la regla si la acabas de implementar.

¿Cómo realizar Backtesting en el Dashboard?

Las definiciones de lo que constituyen pagos fraudulentos y otros pagos realizados correctamente son diferentes según el tipo de regla que estés probando:

Reglas 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 pagos rechazados: pagos 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 se reembolsaron por fraude.

  • Otros pagos realizados correctamente: cargos realizados con éxito que no se disputaron ni reembolsaron por fraude.

  • Rechazados o puestos en revisión: pagos rechazados por el emisor o bloqueados por Radar, o cargos realizados correctamente puestos en revisión (independientemente de su estado de disputa o reembolsos).

Regla de permitidos

  • Bloqueados 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: cargos rechazados por el emisor o 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 funcionalidad de backtesting en el Dashboard de Radar se enfocan en los últimos seis meses de transacciones e incluyen disputas, alertas de fraude preventivas y cargos reembolsados como fraudulentos.

Tal vez desees realizar un análisis más específico, por ejemplo, si estás en riesgo de que se te identifique en un Programa de monitoreo de Visa (que se enfocan exclusivamente en las advertencias de fraude preventivas) o notas un aumento repentino del fraude proveniente de un tipo de cartera digital o IP de un país en particular. Para ello, puedes crear una consulta de SQL en Sigma o exportar y analizar informes de datos de pagos en el Dashboard. El backtesting personalizado brinda flexibilidad en los períodos (más de seis meses) y análisis más enfocados (por ejemplo, puedes centrarte solo en las disputas o en las EFW). La consulta de ejemplo a continuación hace un backtest de las advertencias de fraude preventivas (EFW) en transacciones superiores a USD 100 si, en teoría, observas que el volumen de fraude aumentó recientemente en mayores valores y que las transacciones con puntuación de riesgo elevada crearon riesgos de ingresar en el programa de monitoreo:

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

La realización de un backtest en los últimos 60 días antes de la fecha de creación de las EFW se centra en el fraude más reciente, mientras que realizar esta prueba en los últimos 60 a 120 días de ventas no fraudulentas permite que el fraude se desarrolle de forma más completa.

Vectores de fraude frecuentes

La mayoría de los actores fraudulentos siguen un patrón común a la hora de cometer fraude. Primero, validan la información de pago robada (p. ej., tarjetas). Una vez que validan los datos, usan las credenciales para extraer valor en la forma de bienes físicos para uso personal o reventa (bienes de lujo o electrónicos), servicios de uso personal o reventa (servicios de entrega de alimentos) o servicios y productos que ayudan a cometer más fraudes (es decir, servicios de hosting web, servicios de mensajería de correos no deseados, etcétera).

Para obtener más información sobre los vectores de fraude más frecuentes y formas recomendadas para usar las reglas de mitigación de fraude de Radar, continúa leyendo.

Pruebas

Las pruebas de tarjetas suceden cuando los actores fraudulentos usan códigos o procesos manuales para probar si los números de tarjetas robadas siguen activos. Esta etapa del fraude no se trata de obtener un servicio o un bien físico, sino de validar si las tarjetas están activas. Estos cargos suelen ser autorizaciones o transacciones por valores en dólares bajos. Las pruebas suelen ocurrir rápidamente. Los atributos que pueden ser útiles son las funcionalidades de velocidad y agrupamiento, tales como los siguientes:

  • total_charges_per_customer

  • card_count_for_email

  • card_count_for_ip_address

  • total_charges_per_ip

Por lo general, los actores fraudulentos intentarán evitar estos atributos con correos electrónicos falsos y direcciones diferentes. Los actores fraudulentos más experimentados enmascaran las direcciones de IP o incluso tendrán varios dispositivos para proporcionar datos de dispositivo únicos. En ese punto, es muy importante conocer los comportamientos de clientes típicos y correctos. Las funcionalidades como el dominio del correo electrónico y el país de la IP, entre otras categorías más amplias, pueden ayudar a identificar transacciones con riesgo más alto. Muchos clientes fraudulentos utilizarán dominios de correo electrónico populares de proveedores de correo electrónico establecidos, como gmail.com. Es posible que veas dominios como gmail.comms o gomail.co, que intentan enmascarar la identidad de actores fraudulentos. El país de la tarjeta y de la IP pueden usarse para segmentar clientes y garantizar que las transacciones sean de áreas típicas de tu base de usuarios. Es posible que las transacciones fuera de estas ubicaciones sean de interés para su revisión o bloqueo.

Una última funcionalidad para evitar este comportamiento de pruebas es implementar un código CAPTCHA.

En Stripe Checkout, los desafíos CAPTCHA aparecen automáticamente cuando nuestro modelo de machine learning detecta ataques de prueba de tarjetas. Para reducir las pruebas de tarjetas, Stripe usa una serie de controles manuales y automáticos, incluidos limitadores de frecuencia, alertas y revisiones continuas junto a modelos de prueba de tarjetas para detectar ataques automáticamente. Estos modelos solo muestran desafíos CAPTCHA cuando un ataque de prueba de tarjetas se encuentra en curso para que solo los bots vean un CAPTCHA y casi nunca lo hagan los usuarios reales. Gracias a esto, los ataques de prueba de tarjetas en las empresas que usan Stripe Checkout se redujeron un 80 %, una cifra espectacular, sin que prácticamente hubiese ningún efecto detectable en la conversión.

Agregar códigos CAPTCHA gestionados por Stripe para todos los usuarios de Checkout redujo la prueba de tarjetas en un 80 %, con un impacto de menos de 2 puntos básicos (0.02 %) en las tasas de autorización.

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

Extracción de valor

Tarjetas de crédito robadas (nuevo comportamiento)

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

Este vector suele usarse de forma abusiva a través de ataques masivos con código o, a pequeña escala, con redes y bolsillos de fraude más orientados. De todas formas, existen atributos de reglas que miden qué tan nueva es una cuenta en Stripe, como hours_since_email_first_seen_on_stripe, que junto a risk_score y otras funcionalidades mantienen a estos nuevos titulares de tarjetas a raya. Además, las restricciones de velocidad sobre direcciones IP, correos electrónicos y tarjetas pueden proteger mejor a los comerciantes de ataques por volumen en los que los actores fraudulentos intentan monetizar credenciales robadas lo más rápido posible.

Tarjetas de crédito robadas (comportamiento de enmascaramiento)

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

El actor fraudulento intentará enmascarar su presencia a través de las siguientes acciones:

  • Usando el mismo nombre que en las transacciones completadas previamente.

  • Usando la misma dirección de facturación que en las transacciones completadas previamente.

  • Usando una VPN para que parezca que es el titular original de la tarjeta. Es posible que configure la VPN en la misma ciudad y hasta en la misma cuadra.

  • Cambiando solo un pequeño detalle, como la dirección de correo electrónico o el número de teléfono.

  • Cambiando la dirección de envío de transacciones previas, para un producto físico, potencialmente con una gran diferencia en la distancia entre la dirección de facturación y la de envío. Esta es una señal no estricta.

El comportamiento de enmascaramiento descrito anteriormente dificulta analizar quién está realizando la transacción en realidad, ya sea el titular de la tarjeta original o un actor fraudulento que ha vulnerado la cuenta. Esto suele significar que este tipo de fraude pasa desapercibido durante más tiempo, tanto para el comerciante como para el titular original de la tarjeta.

Aquí la estrategia es la misma: el actor fraudulento intentará extraer el máximo valor posible de las credenciales robadas. Las reglas que usan funcionalidades para limitar la velocidad, junto con riskscore, los fallos de comprobaciones de cvccheck, o los fallos de comprobaciones de zip, pueden ayudarte a protegerte de este comportamiento.

Otras prácticas recomendadas

Estas son algunas prácticas recomendadas que te ayudarán a optimizar la escritura de reglas de Radar.

Flujo de proceso de compra
Incluye una referencia explícita de tus condiciones de servicio en el flujo del proceso de compra.
En el caso de los contracargos, proporciona una captura de pantalla etiquetada de forma clara de las Condiciones de uso como se muestran en el flujo del proceso de compra y explica su significado. Esto aumentará tus posibilidades de que la disputa se resuelva a tu favor.
Valida el CVS y el código postal
Permite al emisor validar el titular de tarjeta. Puede aumentar la probabilidad de que una disputa se resuelva a tu favor y, a menudo, mejora las tasas de autorización. Considera bloquear las verificaciones con errores.
Recopila la mayor cantidad posible de información del cliente
Recopilar esta información ayuda a los emisores a evaluar tu caso si se generan contracargos, lo cual aumenta tus posibilidades de que se resuelva a tu favor. Se consideran como diligencia debida.
El estándar Gold incluye: CVC y código postal, nombre del cliente, dirección de correo electrónico, dirección completa de facturación, dirección IP, información del dispositivo, etc.
La implementación de Stripe.js le proporciona a Radar la información sobre la dirección IP, el dispositivo y el comportamiento para mejorar la detección de fraudes.
Interacciones con los clientes
Genera listas de bloqueos para las tarjetas con contracargos de la categoría «fraudulento»
Si un cliente disputa un cargo como fraudulento, es probable que también se disputen futuros cargos.
Reembolsa pagos sospechosos o fraudulentos
Del 70 al 85 % de las transacciones TC40 se vuelven disputas, y solo las transacciones completas pueden evitar que se genere una disputa.
Implementa una descripción del cargo en el extracto bancario que sea clara
Reduce la cantidad de disputas no reconocidas.

La importancia del uso de Stripe.js

  • Incluye Stripe.js en la ruta de pagos completa para marcar la mayor cantidad de fraude.
  • Para aprovechar Radar al máximo sin que ello influya en el tiempo de carga de las páginas, carga Stripe.js asíncrono en las páginas que no sean de pago.
  • Es lo más sencillo de poner junto a las etiquetas de script de Google Analytics.
  • El tamaño de agrupación completo de Stripe.js es de 29.6 kb comprimido con gzip.
    • Estado futuro: Radar.js puede incluirse por separado de Stripe.js.

Conclusión

Las reglas pueden ser una herramienta extremadamente sólida de personalización de protección contra fraudes. A través de la implementación de una lógica única, con la información proporcionada en algunas de las prácticas recomendadas que se indican en esta guía, puedes crear una configuración de prevención de fraude en Radar específica para las necesidades de tu empresa.

Puedes obtener más información sobre Radar for Fraud Teams aquí.

Si ya eres usuario de Radar for Fraud Teams, consulta la página Reglas en el Dashboard para empezar a escribirlas.

Otras notas

Radar para plataformas

¿Tienes 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 destination
o on-behalf-of). Los pagos que se crean directamente en la cuenta conectada están sujetos a las reglas de esa cuenta.

Radar for Terminal

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

¿Todo listo para empezar?

Crea una cuenta y empieza a aceptar pagos sin necesidad de firmar contratos ni proporcionar datos bancarios. Si lo prefieres, puedes ponerte en contacto con nosotros para que diseñemos un paquete personalizado para tu empresa.
Radar

Radar

Combate el fraude con la solidez de la red de Stripe.

Documentación de Radar

Utiliza Stripe Radar para proteger tu empresa contra fraude.