# Reglas de prevención de fraude Utiliza reglas de prevención de fraude para proteger tu empresa. Stripe Radar ofrece reglas integradas para ayudar a detectar y proteger contra el riesgo de fraude en todos los [métodos de pago admitidos](https://docs.stripe.com/radar/supported-payment-methods.md). Todas las transacciones se analizan mediante las reglas predeterminadas de Radar. Radar para Equipos de Fraude y [Radar para Plataformas](https://docs.stripe.com/radar/radar-for-platforms.md) te permiten usar el [Dashboard](https://dashboard.stripe.com/test/radar/rules) a fin de crear [reglas personalizadas](https://docs.stripe.com/radar/supported-payment-methods.md#custom-risk-settings) establecidas en la lógica de tu empresa. Por ejemplo, puedes realizar lo siguiente: - **Solicitar 3D Secure** (3DS) para todos los pagos que admitan 3D Secure y sean efectuados por un cliente nuevo - **Autorizar** todos los pagos que lleguen de la dirección IP de tu centro de atención telefónica - **Bloquear** los pagos efectuados desde el extranjero o con una tarjeta emitida fuera de tu país - **Revisar** todos los pagos superiores a USD 1,000 realizados con tarjetas de prepago - **Revisar y suspender automáticamente las transferencias** en cuentas que tienen una alta tasa de disputas (con Radar para Plataformas) > Las empresas de la UE podrían verse afectadas por el [Reglamento sobre Bloqueo Geográfico](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes) y sus prohibiciones de bloqueo de pagos de clientes establecidos en Estados miembros de la UE. ## Reglas integradas Las siguientes reglas están disponibles de forma predeterminada, a menos que se marquen como reglas personalizadas, que solo están disponibles si usas Radar para Equipos de Fraude o Radar para Plataformas. > #### Bloquea fraudes de manera automática > > También puedes usar los [controles de riesgo](https://docs.stripe.com/radar/risk-settings.md) de Radar para bloquear fraudes de manera automática. Los controles de riesgo usan [alertas preventivas de fraude](https://docs.stripe.com/radar/risk-settings.md#early-fraud-warning) para evaluar y bloquear los pagos de mayor riesgo. ### Comprobaciones de riesgo con IA Todas las ofertas de Radar ofrecen un conjunto de reglas predeterminadas basadas en los criterios de nuestros modelos de IA. | Regla de Radar | Descripción | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `si :risk_level: = 'highest'` (Deprecated) | La regla bloquea y no procesa los pagos con alto riesgo de fraude. Esta regla está habilitada de forma predeterminada para todos los usuarios de Radar. | | `if :risk_level: = 'elevated'` | El comportamiento predeterminado de Radar para Equipos de Fraude y Radar para Plataformas es pasar a revisión los pagos que sospechamos que tienen un elevado riesgo de fraude. | Radar para Plataformas tiene modelos adicionales de IA a nivel de cuenta que se incorporan a través de dos reglas predeterminadas: `if :account_risk_level: = 'highest'` `if :account_risk_level: = 'elevated'` Calculamos el riesgo a nivel de cuenta mediante información de KYC, transacciones, factores de riesgo geográfico y patrones de comportamiento. ### Comprobaciones tradicionales de tarjetas Un pago puede seguir efectuándose correctamente aunque falle la comprobación del *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number) o de la dirección (*AVS* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)), ya que los emisores evalúan varias señales cuando deciden autorizar un pago. El emisor de una tarjeta puede considerar como legítimo un pago que no pasa la verificación del CVC o del código postal y, por lo tanto, aprobarlo. Puedes habilitar las reglas integradas de Radar para bloquear determinados pagos aprobados por el emisor de la tarjeta. Cuando están habilitadas, estas reglas también afectan a la asociación de una tarjeta con un cliente y a la creación de un cliente si creas la tarjeta y el cliente al mismo tiempo. #### Reglas de CVC y AVS A partir del 17 de diciembre de 2024, en el Dashboard se muestran estas reglas a los nuevos clientes que no hayan usado las reglas heredadas de CVC o AVS. | Regla de Radar | Descripción | | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `si falla la verificación del número de CVC según la puntuación de riesgo` | Habilita esta regla para bloquear los pagos que no pasen la verificación del CVC del emisor de la tarjeta, a no ser que Stripe lo evalúe como de bajo riesgo. Esta regla no bloquea los pagos en los que el cliente no proporciona el número de CVC porque, por ejemplo, usa una *cartera* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) o el emisor de la tarjeta no admite su verificación. | | `si falla la verificación del código postal según la puntuación de riesgo` | Habilita esta regla para bloquear los pagos que no pasen la verificación del código postal del emisor de la tarjeta, a no ser que Stripe lo evalúe como de bajo riesgo. Esta regla no bloquea los pagos en los que el cliente no proporciona el código postal ni aquellos en los que el emisor de la tarjeta no admite su verificación. | #### Reglas heredadas de CVC y AVS A partir del 17 de diciembre de 2024, en el Dashboard se muestran estas reglas a los clientes existentes que habilitaron al menos una de ellas. | Regla de Radar | Descripción | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `si falla la verificación del CVC` | Habilita esta regla para bloquear los pagos que no pasen la verificación del CVC del emisor de la tarjeta. Esta regla no bloquea los pagos en los que el cliente no proporciona el número de CVC porque, por ejemplo, usa una *cartera* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) o el emisor de la tarjeta no admite su verificación. | | `si falla la verificación del código postal` | Habilita esta regla para bloquear los pagos cuando no pasen la verificación del código postal del emisor de la tarjeta. Esta regla no bloquea los pagos en los que el cliente no proporciona el código postal o el emisor de la tarjeta no admite su verificación. | ### Reglas integradas para solicitar 3D Secure *3D Secure (3DS)* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) solicita a los clientes que realicen un paso adicional de autenticación antes de completar el flujo de compra. Si 3DS autentica un pago, la [responsabilidad](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments) de una disputa relacionada con el fraude para ese pago generalmente se transfiere del vendedor al emisor. Esto significa que, en la mayoría de los casos, el vendedor no es responsable de los costos por fraude de los pagos autenticados con 3DS. Stripe maneja automáticamente los códigos de rechazo temporal que indican que se necesita una autenticación 3DS. También activamos la autenticación 3DS cuando es necesario, para cumplir con normativas como la [autenticación reforzada de clientes](https://stripe.com/guides/strong-customer-authentication) (SCA) que integra el marco de la Segunda Directiva de Servicios de Pago (PSD2). La desactivación de Radar no impide que se active 3DS en los casos en que sea necesario. Stripe admite tres reglas integradas heredadas de solicitud de 3DS cuando se usa Radar con [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) o [SetupIntents](https://docs.stripe.com/payments/save-and-reuse.md): | Regla de Radar | Descripción | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `si se recomienda 3D Secure para la tarjeta` (Deprecated) | Activa esta regla para solicitar al cliente una autenticación 3DS basada en el riesgo. | | `si la tarjeta admite 3D Secure` (Deprecated) | Activa esta regla para solicitar al cliente una autenticación 3DS, siempre y cuando su tarjeta lo admita. | | `si esta autenticación es necesaria para la tarjeta` (Deprecated) | Activa esta regla para solicitar al cliente una autenticación 3DS, si históricamente la tarjeta [exigía 3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#three-ds-cards). Independientemente de estas reglas, Stripe activa automáticamente 3DS: - Si un código de rechazo leve indica que el emisor requiere 3D Secure. - En cumplimiento de la normativa, como la orden de [Autenticación reforzada de clientes (SCA)](https://stripe.com/guides/strong-customer-authentication) de la PSD2. | Debido a que 3D Secure requiere que tu cliente pase por una capa adicional de autenticación, el uso indiscriminado de 3D Secure podría reducir las tasas de conversión. La solicitud de 3DS no significa necesariamente que el emisor realmente utilice 3DS. Obtén más información sobre los [posibles resultados](https://docs.stripe.com/payments/3d-secure.md). ### Reglas personalizadas para solicitar 3D Secure y actuar en función de resultados específicos Después de intentar la autenticación con 3DS, si tienes [Radar para Equipos de Fraude](https://stripe.com/radar/fraud-teams) o [Radar para Plataformas](https://docs.stripe.com/radar/radar-for-platforms.md), puedes evaluar el resultado en las reglas de permiso, bloqueo o revisión. Consulta a continuación los atributos más importantes para las reglas personalizadas de Radar. | Atributo | Descripción | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `is_3d_secure` | Esto es verdadero si se admite la tarjeta, el emisor intentó la autenticación con 3DS y el cliente realizó la autenticación correctamente. Por lo general, recomendamos usar este atributo en las reglas de bloqueo. | | `is_3d_secure_authenticated` | Esto es verdadero si el emisor intentó la autenticación con 3DS y el cliente completó correctamente toda la autenticación. El uso de este atributo en una regla de bloqueo excluye las transacciones legítimas que pueden tener una exención de la Autenticación reforzada de clientes (SCA) o que no se categorizan como un error claro o una autenticación correcta, como los errores de procesamiento. | | `has_liability_shift` | Esto es verdadero si Stripe espera que la *transferencia de responsabilidad* (With some 3D Secure transactions, the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer) cubra el pago. Es posible que esto no siempre sea lo mismo que [3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments), por ejemplo, Apple Pay en ciertas regiones. | Para las reglas personalizadas, recomendamos que mantengas alineadas las reglas `Solicitar 3DS` y `Bloquear` según el [riesgo que quieras asumir](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data). Sin embargo, no bloqueamos los pagos en los que no se admite 3DS, como las de algunas carteras. A continuación, encontrarás algunos ejemplos que muestran cómo lograr esto para diferentes casos de uso: #### Solicita 3D Secure según el nivel de riesgo de Radar Usa Radar para solicitar 3DS en todos los pagos, en función del nivel de riesgo y cuando se supere un cierto importe. | Regla de Radar | Descripción | | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Esta regla verifica el nivel de riesgo de Radar antes de solicitar 3DS en todos pagos con un nivel de riesgo elevado o alto que estén por encima de un cierto importe. | En este caso, sin una regla de bloqueo, las tarjetas o carteras que no admitan 3DS no se bloquearán. Los intentos fallidos de autenticación con 3DS no continuarán con la autorización del cargo. #### Siempre solicita 3D Secure en función del nivel de riesgo de Radar Debes utilizar Radar para solicitar 3DS en todos pagos, en función del nivel de riesgo elevado o alto y que estén por encima de un importe determinado. No debes admitir tarjetas que no admitan 3DS. | Regla de Radar | Descripción | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Esta regla verifica el nivel de riesgo de Radar y antes de solicitar 3DS en todos los cargos con un nivel de riesgo elevado o alto que estén por encima de un cierto importe. | | `Block if not :is_3d_secure: and :risk_level: != 'normal' and :amount_in_usd: > 25 and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regla bloquea los pagos elevados o de alto riesgo que estén por encima de un cierto importe y que no tengan un flujo de 3DS. Esta regla acepta personalizados legítimos que podrían tener una exención de la Autenticación reforzada de clientes (SCA) o no tienen un error claro o una autenticación correcta, como `attempt_acknowledged`. Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y carteras como Apple Pay o Google Pay, para ejecutarse correctamente. | #### Solo acepta pagos completamente autenticados con 3D Secure si se admite 3D Secure Dependes de que Stripe active 3DS cuando sea necesario en casos como la [Autenticación reforzada de clientes](https://stripe.com/guides/strong-customer-authentication) (SCA) (SCA), pero no debes aceptar [casos extremos](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), como errores de procesamiento. | Regla de Radar | Descripción | | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Block if :is_3d_secure: and not :is_3d_secure_authenticated:` | Esta regla bloquea los pagos en los que la tarjeta está inscrita en 3DS y se intentó realizar la autenticación con 3DS, pero el usuario no logró una autenticación correcta. Se aceptan tarjetas que no admiten 3DS, exenciones de la Autenticación reforzada de clientes (SCA), pagos fuera de la sesión, como cargos de suscripciones recurrentes y carteras, como Apple Pay o Google Pay. | #### Solicita 3D Secure en función de los metadatos Usa Radar para solicitar 3DS en todos los pagos con un atributo de metadatos personalizado. | Regla de Radar | Descripción | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Request 3D Secure if ::foo:: = 'bar'` | Esta regla comprueba si hay una condición de metadatos y luego solicita 3DS. Para verificar los metadatos del cliente, reemplaza `::foo:: = 'bar'` con un valor como `::customer:trusted:: = 'false'`. | En este caso, sin una regla de bloqueo, las tarjetas o carteras que no admitan 3DS no se bloquearán. Los intentos fallidos de autenticación con 3DS no continuarán con la autorización del cargo. #### Siempre solicita 3D Secure en función de los metadatos Usa Radar para solicitar 3DS en todos los pagos con un atributo de metadatos personalizado y bloquear las tarjetas que no admitan esta autenticación. | Regla de Radar | Descripción | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if ::foo:: = 'bar'` | Esta regla comprueba si hay una condición de metadatos y luego solicita 3DS. Para verificar los metadatos del cliente, reemplaza `::foo:: = 'bar'` con un valor como `::customer:trusted:: = 'false'`. | | `Block if ::foo:: = 'bar' and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regla bloquea los pagos que no tienen un flujo de 3DS para los cargos con un atributo de metadatos personalizado. Esta regla acepta pagos legítimos que podrían tener una exención de la Autenticación reforzada de clientes (SCA) o no tienen un error claro o una autenticación correcta, como `attempt_acknowledged`. Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y carteras, como Apple Pay o Google Pay, para ejecutarse correctamente. | #### Solicita 3D Secure para todas las tarjetas nuevas y revisa si no se admitió 3D Secure Usa Radar para solicitar 3DS en todas las tarjetas nuevas y revisar manualmente los pagos de las tarjetas que no admitan 3DS. | Regla de Radar | Descripción | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if is_missing(:seconds_since_card_first_seen:)` | Esta regla solicita 3DS en todas las tarjetas que no se hayan utilizado en tu cuenta. Para reducir la fricción para el usuario, puedes agregar una condición para solicitar 3DS solo si `:risk_level: != 'normal'`. | | `Request 3D Secure if :is_new_card_on_customer:` | Como alternativa a la regla anterior, esta regla solicita 3DS en todas las tarjetas que se usen por primera vez en una [Cuenta](https://docs.stripe.com/api/v2/core/accounts/object.md#v2_account_object-configuration-customer) o [Cliente](https://docs.stripe.com/api/customers.md) configurado por el usuario. Para reducir la fricción del usuario, puedes agregar una condición para solicitar 3DS solo si `:risk_level: != 'normal'`. | | `Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regla marca los pagos en los que se espera 3DS, pero no es compatible con la revisión manual. Ignora los pagos fuera de sesión, como los cargos de suscripción recurrentes, y las carteras, como Apple Pay o Google Pay. Los pagos marcados para revisar continúan con la autorización y pueden dar señales adicionales, como comprobaciones de CVC del emisor. | En este caso, sin una regla de bloqueo, las tarjetas o carteras que no admitan 3DS no se bloquearán. Los intentos fallidos de autenticación con 3DS no continuarán con la autorización del cargo. #### Siempre solicita 3D Secure para ciertos países emisores Usa Radar para solicitar 3DS en todos los pagos de emisores de tarjetas provenientes de países que se encuentran en una [lista personalizada](https://docs.stripe.com/radar/lists.md) y para bloquear las tarjetas que no admitan esta autenticación. | Regla de Radar | Descripción | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :card_country: in @enforce_3ds_list` | Esta regla comprueba si hay una condición basada en los países de origen de los emisores de tarjetas y los compara con una [lista personalizada](https://docs.stripe.com/radar/lists.md). Si coinciden, solicitamos 3DS. | | `Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regla bloquea los pagos que no tienen un flujo 3DS y que proceden de países incluidos en la lista personalizada. Esta regla acepta pagos legítimos que podrían tener una exención de la Autenticación reforzada de clientes (SCA) o no tienen un error claro o una autenticación correcta, como `attempt_acknowledged`. Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y carteras, como Apple Pay o Google Pay, para ejecutarse correctamente. | #### Siempre solicita 3D Secure según el nivel de riesgo de Radar y revisa los casos extremos Usa Radar para solicitar 3DS en todos los pagos según el nivel de riesgo y bloquear las tarjetas que no admitan 3DS, pero revisa manualmente los casos extremos. | Regla de Radar | Descripción | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal'` | Esta regla verifica el nivel de riesgo de Radar antes de solicitar 3DS en los pagos elevados o con un alto nivel de riesgo que estén por encima de un cierto importe. | | `Block if not :is_3d_secure: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regla bloquea los pagos elevados o con un alto nivel de riesgo que estén por encima de un cierto importe y que no tengan un flujo de 3DS. Esta regla acepta pagos legítimos que podrían tener una exención de la Autenticación reforzada de clientes (SCA). Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y carteras, como Apple Pay o Google Pay, para ejecutarse correctamente. | | `Review if not :is_3d_secure_authenticated: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regla marca para la revisión manual los pagos que usaban 3DS, pero no completaron el flujo de autenticación. Esto revisa los [casos extremos](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), como `attempt_acknowledged`, y también se marca los pagos legítimos independientemente de las exenciones de la Autenticación reforzada de clientes (SCA). Debido a que las reglas de revisión se evalúan después de las reglas de bloqueo, bloqueamos las tarjetas que no admitan 3DS. | ## Crear reglas Solo el titular, los administradores y los desarrolladores de la cuenta pueden crear reglas. Si necesitas que los [miembros del equipo](https://support.stripe.com/questions/can-i-invite-other-team-members-or-my-developer-to-use-my-stripe-account) creen reglas, revisa la [configuración del equipo](https://dashboard.stripe.com/settings/team) para cerciorarte de que tengan acceso de administración. Las reglas predeterminadas de Stripe pueden bloquear un número considerable de pagos fraudulentos. Las empresas que necesiten un mayor control sobre los pagos que desean revisar, permitir o bloquear pueden escribir reglas personalizadas a través de Radar para Equipos de Fraude. Las plataformas pueden escribir reglas personalizadas a través de Radar para plataformas con el fin de calibrar el riesgo de los pagos para su plataforma y las cuentas conectadas, y aplicar reglas específicas para cada cuenta. Ten en cuenta las siguientes preguntas al decidir si habilitar reglas personalizadas: - Si consideras que ciertas características o comportamientos de usuario son más riesgosos (por ejemplo, el uso de una dirección de correo electrónico temporal). - Si quieres implementar reglas establecidas en el método de pago (por ejemplo, bloquear automáticamente pagos con débito directo SEPA que superen una determinada puntuación de riesgo). - Si quieres implementar reglas según el importe del pago o el nivel de riesgo percibido (por ejemplo, revisar automáticamente si el pago es superior a USD 500 o permitir automáticamente si el pago es inferior a USD 5). - Si tus actuales pagos disputados y rembolsados comparten algún patrón común (por ejemplo, importes similares o el mismo país o tipo de tarjeta). - Si tienes reglas que quieres migrar a Stripe. Es posible que muchas de estas reglas ya estén comprendidas en los modelos de machine learning de Stripe y puedes verificar cómo se comporta nuestro sistema en tu empresa antes de personalizarlo. - Si quieres iniciar revisiones de manera automática y opcionalmente suspender las transferencias en las cuentas. Esto se aplica solo a las plataformas. ### Crear reglas eficaces Si bien las reglas pueden ayudarte a automatizar los flujos de trabajo existentes, también pueden perjudicar a tu empresa si no se usan correctamente. Por ejemplo, si no se configura correctamente, una regla puede permitir una gran cantidad de pagos elevados o con un alto riesgo, o bloquear una gran cantidad de pagos legítimos automáticamente. Recuerda lo siguiente cuando configures reglas: - De forma predeterminada, las reglas se aplican a todos los [métodos de pago admitidos](https://docs.stripe.com/radar/supported-payment-methods.md), a menos que definas un método de pago específico en el predicado de la regla mediante el atributo `payment_method_type`. - Las reglas solo se aplican a pagos futuros y no se aplican a ninguno que ya hayas procesado. - Las reglas de solicitud de 3DS solo se aplican cuando se usa [Stripe Checkout](https://docs.stripe.com/payments/checkout.md), [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) o [Setup Intents](https://docs.stripe.com/payments/save-and-reuse.md) y se evalúan antes que las reglas de revisión, bloqueos y permitidos. - Antes de implementar cualquier regla de bloqueo para bloquear todos los pagos o suspender las transferencias para las cuentas que cumplan con sus criterios, considera si prefieres revisar los pagos o las cuentas primero. - Implementa las reglas de permitidos en la menor medida posible, ya que anulan las reglas predeterminadas de Stripe y cualquier otra regla personalizada que siga los mismos criterios. - Puedes crear un máximo de 200 reglas de transacción y 100 reglas de cuenta. ## Crea reglas de transacción Puedes agregar y administrar reglas desde la [página de reglas de Radar](https://dashboard.stripe.com/test/radar/rules) en el Dashboard. #### Para agregar una regla de transacción 1. Haz clic en **+ Agregar regla**. 1. Selecciona el tipo de regla. 1. En el editor de reglas, crea una regla usando la sintaxis `{action} if {attribute} {operator} {value}` donde: - `{action}`: cómo responde Radar cuando se cumplen los criterios de la regla. Este valor se completa previamente en función de la selección del tipo de regla que elegiste. - `{attribute}`: es el elemento del pago que se evaluará, como el importe o el tipo de tarjeta. Empieza a escribir con `:` para abrir una lista de atributos válidos. También puedes evaluar tus metadatos personalizados si los encierras entre dos puntos, por ejemplo, `::product_sku::`. - `{operator}`: cómo comparar el atributo con el valor, como ``=`,`\>`,`!=`, etc. - `{value}`: es el valor del atributo que se evaluará. 1. Haz clic en **Probar regla**. 1. Corrige los errores de validación detectados, de ser necesario. 1. En la página **Revisar nueva regla**, revisa cómo se comporta esta regla con tus pagos recientes para confirmar si quieres activarla. Si la regla puede afectar los pagos de más de un método de pago, usa el filtro para ver el rendimiento de la regla por método de pago (por ejemplo, ACH o Tarjetas). 1. Haz clic en **Agregar regla** para aplicar esta regla a todas las transacciones futuras. ### Usar Asistente de Radar El editor de reglas de Stripe cuenta con un asistente de LLM integrado que crea una regla de transacción de Radar a partir de una indicación en lenguaje natural. Obtén más información sobre los [servicios de IA de Stripe](https://support.stripe.com/questions/use-of-artificial-intelligence-(ai) en los servicios de Stripe). > #### Consentimiento de datos de entrenamiento > > Cuando usas el Asistente de Radar, aceptas que Stripe pueda registrar y usar tus entradas de chat para entrenar y mejorar las capacidades del Asistente de Radar. Si no quieres que tus entradas de chat se usen para este propósito, escribe reglas manualmente. #### Para usar el Asistente de Radar: 1. En la [página de reglas de Radar](https://dashboard.stripe.com/test/radar/rules), haz clic en **+ Agregar regla**. 1. Selecciona el tipo de regla. 1. En el editor de reglas, haz clic en **Asistente de Radar**. 1. En el campo de mensaje, ingresa tu solicitud de regla. Puedes pedir lo siguiente: - *Revisar los pagos en los que la tarjeta y los países de IP son diferentes.* - *Bloquear los pagos con tarjeta Discover de más de $1000.* - *Permitir pagos desde direcciones de correo electrónico de stripe.com.* 1. Cuando el Asistente devuelva su sugerencia, puedes ingresar un comando adicional para realizar ajustes en la regla o puedes hacer clic en **Probar regla** para ver cómo funciona la regla en tu historial de transacciones recientes. 1. Cuando estés satisfecho con la regla, haz clic en **Agregar regla** para habilitarla para todas las transacciones futuras. > #### Comparte tus comentarios > > Ayúdanos a seguir mejorando el Asistente de Radar. Haz clic en **Compartir comentarios** y dinos cómo se desempeñó el Asistente para ti y qué podemos hacer para mejorar. Agradecemos todas las opiniones, ya sea sobre la precisión de la sugerencia, la interfaz de usuario o cualquier otro aspecto de tu interacción. ### Revisar reglas Stripe sigue procesando pagos normalmente cuando coinciden con los criterios de una regla de revisión. Agregamos estos pagos a tu [cola de revisión](https://dashboard.stripe.com/test/radar) para que tu equipo pueda revisarlos con más detenimiento. Si configuras una regla demasiado amplia, puede que muchos pagos pasen a la cola de revisión, con lo que tus clientes sufrirán demoras y tu equipo de revisión se verá sobrecargado. La interfaz de pruebas de Stripe ejecuta una simulación tomando los cargos de los últimos 6 meses para determinar cuántos pagos legítimos, fraudulentos y bloqueados se hubieran visto afectados por la regla de haberse implementado. Mientras pruebas una regla y examinas los últimos 6 meses, debes asegurarte de lo siguiente: - **El volumen general de pagos es bajo**. La revisión de estos pagos no debería sobrecargar a tu equipo. - **Los revisores humanos aportan un valor añadido**. Por lo general, un revisor humano puede identificar un pago elevado o de alto riesgo con mayor seguridad que el sistema automatizado. - **La regla se traduce en una mezcla de pagos efectuados con éxito y rembolsados o en disputa**. Esto significa que una inspección adicional sobre estos tipos de pagos puede ayudar a separar los pagos legítimos de los fraudulentos. El siguiente ejemplo muestra cómo mejorar una regla de revisión creada por una empresa que desea revisar tarjetas de crédito de prepago. | Regla original | Regla mejorada | | ------------------------------------------------------------------ | ------------------------------------------------------------------- | | `if :card_funding: = 'prepaid'` | `if :is_disposable_email: and :card_funding: = 'prepaid'` | | Esta regla es demasiado amplia y da lugar a demasiadas revisiones. | Esta regla es más específica y genera menor cantidad de revisiones. | ### Reglas de bloqueo Puedes usar reglas de bloqueo para bloquear pagos que consideras que serán fraudulentos o que se basen en restricciones dispuestas por tu empresa (p. ej., bloquear pagos efectuados con tarjetas de prepago). Si tienes dudas respecto de cómo aplicar reglas de bloqueo, te recomendamos usar una regla de revisión para enviar los pagos a revisión. Después de revisar estos pagos en busca de posibles falsos positivos, puedes confirmar si prefieres crear una regla de bloqueo en su lugar. Las reglas de bloqueo solo actúan sobre pagos fraudulentos y pagos efectuados con éxito, ya que los pagos ya bloqueados no se verán afectados. Mientras pruebas una regla, asegúrate de lo siguiente: - **Mantén el número de falsos positivos lo más bajo posible**. Durante la prueba, Stripe identifica la cantidad de pagos correctos y en disputa que hubieran coincidido con la regla. Una buena regla bloquea muchos más pagos fraudulentos que pagos legítimos. - **Minimiza las reglas innecesarias**. Si tu regla parece funcionar bien, pero está comprendida en una regla que ya existe, es posible que la regla nueva no sea necesaria. Asimismo, si los resultados durante la prueba parecen contradictorios, piensa en configurar una regla de revisión para poder reunir más información acerca de esos tipos de pagos. El siguiente ejemplo muestra cómo mejorar una regla de bloqueo creada por una empresa con un alto nivel de fraude en los pagos procedentes de fuera de EE. UU. | Regla original | Regla mejorada | | ------------------------------------------------------------------------------ | ------------------------------------------------------------------- | | `if :card_country: != 'US'` | `if :card_country: != 'US' and :risk_level: = 'elevated'` | | Esta regla es demasiado amplia y bloquea una gran cantidad de pagos legítimos. | Esta regla es más específica y genera menor cantidad de revisiones. | ### Reglas de permitidos Si quieres tener la posibilidad de crear reglas de permitidos, [ponte en contacto con nosotros](https://support.stripe.com/contact). Permite que las reglas anulen todas tus otras reglas, así que úsalas con precaución. Es posible que muchas empresas no necesiten implementar reglas de permisos. Si te preocupa que una regla de permiso pueda permitir incluso una pequeña cantidad de pagos fraudulentos, considera hacer ajustes para restringir aún más estas reglas antes de implementarlas. Las reglas de permitidos se aplican a todos los pagos nuevos en cuanto creas la regla. Esto incluye cualquier pago que sea similar a pagos bloqueados anteriormente. Mientras pruebas una regla, asegúrate de lo siguiente: - **Examina la cantidad de pagos anteriormente bloqueados que ahora hubieran sido permitidos**. Las reglas de permitidos anulan a todas las demás reglas y la evaluación de riesgos de Stripe. Cuando pruebes una nueva regla de permitidos, todos los pagos que aparezcan serán pagos que habrían sido permitidos si la regla hubiera estado activa. Puede incluir pagos bloqueados o puestos en disputa, lo que afectará tus tasas de disputas futuras. - **Sigue bloqueando los pagos de alto riesgo**. Bloquea los pagos de alto riesgo mediante la adición del siguiente código a cualquier regla de permitidos: `and :risk_level: != 'highest'` - **Evalúa un historial de transacciones legítimas en tu empresa**. Puedes analizar las conexiones entre tus clientes para permitir un mayor volumen de transacciones conforme a un historial de compras legítimas. Así, podrás bloquear menos pagos de clientes con historial comprobado en tu empresa. Para ello, revisa la [lista de atributos](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) y busca los atributos que incluyan la palabra «cliente». El siguiente ejemplo muestra cómo mejorar una regla de permitidos para una empresa que generalmente (aunque no siempre) recibe pagos legítimos de clientes en el Reino Unido: | Regla original | Regla mejorada | | -------------------------------------------------------------------- | --------------------------------------------------------------------------- | | `if :ip_country: = 'GB'` | `if :ip_country: = 'GB' and :risk_level: != 'highest'` | | Esta regla es demasiado amplia y permite algunos pagos fraudulentos. | Esta regla es más específica y genera menor cantidad de pagos fraudulentos. | ## Mantén tus reglas actualizadas A medida que tu empresa crece, asegúrate de que tus reglas sigan reflejando los tipos de clientes con los que quieres operar. A continuación, te ofrecemos algunas de las prácticas recomendadas para mantener actualizadas las reglas conforme a la situación de tu negocio. ### Controla las reglas periódicamente para asegurarte de que sigan siendo eficaces #### Métricas de reglas Los patrones de fraude cambian de manera constante, así que te facilitamos [métricas](https://dashboard.stripe.com/settings/radar/rules) para que puedas ver el desempeño de cada regla. Las métricas varían según el tipo de regla, ya que cada uno ejecuta una acción distinta. ![](https://b.stripecdn.com/docs-statics-srv/assets/rule-performance.8d495f28c352641ff7b710df3c3df2ed.png) Es posible que notes una diferencia en la cantidad de pagos que coinciden con las reglas de revisión y la cantidad de pagos enviados a la cola de revisión en el mismo período. Debido a que solo se ponen en revisión los *successful* payments, los pagos que coinciden con los criterios de una regla de revisión, pero son rechazados por el emisor, por ejemplo, no se envían a la cola de revisión. Utiliza el **gráfico de funcionamiento de las reglas** para entender el comportamiento de tus reglas de Radar. Busca picos o descensos inesperados en la cantidad de pagos que coincidan con tus reglas, como reglas que aprueban o que bloquean demasiados pagos. Estos picos podrían indicar un cambio en los tipos de pagos que está recibiendo tu empresa o señalar que es necesario actualizar las reglas. En el gráfico, las actualizaciones de las reglas se marcan con triángulos y pueden ayudarte a comparar el efecto del cambio antes y después de realizarlo. Las **líneas codificadas por colores** muestran el número de pagos que cumplen las reglas de [3DS](https://docs.stripe.com/issuing/3d-secure.md), las reglas de permitidos, las reglas de bloqueo y las reglas de revisión. Las reglas actualizadas se muestran como **símbolos triangulares** en las líneas del gráfico y pueden ayudarte a comparar el impacto de un cambio antes y después de aplicarlo. Haz clic en el menú de contenido adicional (⋯) para ver comandos adicionales para cualquier regla, incluidos **Desactivar**, **Activar**, **Editar** o **Eliminar**. También puedes utilizar nuestros productos de elaboración de informes, Sigma y Data Pipelines, para [consultar disputas y datos de fraude](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md), incluidas las decisiones y los atributos de las reglas para cada pago individual. #### Evalúa la eficacia de las reglas Puedes encontrar información sobre la efectividad de tus reglas y ver cuántos pagos ha afectado cada regla. También puedes ver y descargar una lista filtrada de cada pago al que se ha aplicado una regla. Revisa los ejemplos de preguntas de la siguiente tabla para decidir si necesitas hacer cambios en alguna regla o eliminarla por completo. | Tipo de regla | Evaluar | Acciones para tener en cuenta | | ------------------ | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | General | Si esta regla ya no coincide con ningún pago. | Eliminar la regla. | | | Si esta regla tiene un comportamiento anómalo, como permitir más pagos que en períodos de tiempo anteriores. | Revisa manualmente los pagos que se correspondan con esta regla para determinar si este es el comportamiento que deseas. | | 3D Secure | Si la tasa de finalización de 3DS es alta, pero la cantidad de disputas o alertas preventivas de fraude es baja. | Elimina la regla porque podrías estar causando dificultades para tus usuarios. | | | Si el fraude es alto para las transacciones que pasan 3DS. | Considera cambiar tu regla de 3DS a una regla de bloqueo para evitar que estos usuarios pasen el flujo sin dificultades (controlado por los emisores) o cometan un fraude propio. | | | Si la tasa de conversión de 3DS es baja. | Es posible que esta sea una regla efectiva, ya que podría estar bloqueando principalmente a los estafadores, pero considera investigar de forma manual los pagos correspondientes para asegurarte de que tus buenos usuarios no dejen de usar el servicio debido a una dificultad adicional. | | De permiso | Si la cantidad de disputas, alertas preventivas de fraude, reembolsos o pagos fallidos es alta. | Elimina la regla que permite que se autoricen los pagos incorrectos. | | De bloqueo | Si la cantidad de bloqueos disminuye, pero tu fraude sigue siendo constante o está aumentando. | Modifica tu regla, ya que es posible que ya no sea eficaz. | | | Si la cantidad de bloqueos aumenta, pero tu fraude sigue siendo constante o está aumentando. | Modifica tu regla porque podría bloquear a los buenos usuarios. | | | Si la cantidad de bloqueos aumenta y tu fraude disminuye. | Esta podría ser una regla eficaz, pero considera revisar de forma manual algunas transacciones para asegurarte de que no estés bloqueando demasiados usuarios buenos. | | De revisión manual | Si el porcentaje de pagos que se revisan es bajo. | Modifica la regla para que sea más restrictiva porque podría ser demasiado general. | | | Si el número de pagos exitosos o aprobados es alto. | Elimina por completo la regla de revisión manual o escribe una regla de permitidos que apunte a esos pagos. | | | Si el número de rembolsos o disputas y alertas preventivas de fraude es elevado. | Convertir a una regla de bloqueo. | #### Reglas para solicitar 3DS Para solicitar reglas 3DS, mostramos **3DS solicitada**, que es la cantidad de veces que una regla activó una solicitud 3DS. Puedes hacer clic en una regla 3DS para ver las siguientes métricas. ![](https://b.stripecdn.com/docs-statics-srv/assets/request-credentials-rule-details.c22b65bc432aafec9e5bcb6079c53528.png) **Reglas de permitidos** Si usas Radar para Equipos de Fraude, puedes ver las siguientes reglas de permitidos: - **Pagos permitidos**: la cantidad total de pagos permitidos por tus reglas. - **Volumen de pagos permitidos**: el importe total, en tu moneda local, relacionado con los pagos permitidos por tus reglas. - **Puntuación de riesgo**: los [resultados de la evaluación de riesgos](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) correspondientes, asignados por nuestros modelos de IA al conjunto de pagos permitidos por tus reglas. - **Disputas derivadas de anulaciones**: la cantidad total de pagos permitidos que se disputaron. - **Volumen de disputas derivadas de anulaciones**: el importe total, en tu moneda local, relacionado con las disputas de pagos permitidos. > Si las métricas de disputas son altas, es posible que quieras considerar establecer reglas de permitidos más precisas, con el fin de evitar permitir pagos que terminarán siendo disputados. Selecciona una regla de permitidos para ver las siguientes métricas: ![](https://b.stripecdn.com/docs-statics-srv/assets/allow-rule-details.e8da078613fdbca5592d2f9330c0f6d4.png) **Reglas de bloqueo** Puedes ver las siguientes reglas de bloqueo: - **Pagos bloqueados**: la cantidad total de pagos bloqueados por tus reglas. - **Volumen de pagos bloqueados**: el importe total, en tu moneda local, relacionado con los pagos bloqueados por tus reglas. Si usas Radar para Equipos de Fraude, también puedes ver lo siguiente: - **Puntuación de riesgo**: los [resultados de la evaluación de riesgos](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) correspondientes, asignados por nuestros modelos de IA al conjunto de pagos permitidos por tus reglas. - **Tasa estimada de falsos positivos**: el porcentaje estimado de pagos no fraudulentos que se bloquearon debido a tus reglas de bloqueo en conjunto y a reglas individuales. Para hacer el cálculo, se utilizan las tasas estimadas de falsos positivos obtenidas gracias a la puntuación de riesgo de IA, que se estima a partir de experimentos llevados a cabo en toda la red de Stripe. - **Se evitaron los pagos fraudulentos estimados**: la cantidad estimada de pagos fraudulentos que evitaron las reglas de bloqueo. Stripe utiliza puntuación de riesgo de IA, calculada mediante el análisis de millones de transacciones en toda la red de Stripe, para predecir pagos con una alta probabilidad de disputarse o rechazarse debido a fraude y estimar cuáles de esos pagos fueron bloqueados con éxito por tus reglas. > Si las métricas de las tasas estimadas de falsos positivos son altas, es posible que quieras considerar establecer reglas de bloqueo más precisas o revisar a qué pagos se aplica la regla, con el fin de evitar bloquear la mayor cantidad posible de pagos no fraudulentos. Selecciona una regla de bloqueo para ver las siguientes métricas: ![](https://b.stripecdn.com/docs-statics-srv/assets/block-rule-details.5df9a2e8652f228cf61b525a32ef56da.png) **Reglas de revisión** Si usas Radar para Equipos de Fraude, puedes ver las siguientes reglas de revisión: - **Pagos enviados a revisión**: la cantidad total de pagos que se enviaron a revisión manual debido a tus reglas. - **Volumen de revisiones de pagos aprobados**: el importe total, en tu moneda local, relacionado con las revisiones de pagos aprobados. - **Tasa de rembolso**: el porcentaje de las revisiones que se rembolsaron. - **Disputas derivadas de revisiones de pagos aprobados**: la cantidad total de pagos aprobados durante la revisión, pero que terminaron siendo disputados. - **Volumen de disputas derivadas de revisiones de pagos aprobados**: el importe total, en tu moneda local, relacionado con las disputas de revisiones de pagos aprobados. Selecciona una regla de revisión para ver las siguientes métricas: ![](https://b.stripecdn.com/docs-statics-srv/assets/review-rule-details.10851302ef65dee05ffce64f7989528f.png) #### Ver el historial de reglas Puedes ver un historial de los cambios realizados en tus reglas Radar. Este camino de auditoría te ayuda a entender cuándo se creó, editó, habilitó o deshabilitó una regla y qué usuario de tu equipo lo hizo. Para ver la actividad de una regla específica, ve a la pestaña [Reglas](https://dashboard.stripe.com/radar/rules) de la página Radar y haz clic en el nombre de la regla. El registro de **actividad de la regla** muestra un resumen de todas las modificaciones. Haz clic en el evento específico para ver más detalles, como el predicado completo de la regla antes y después de la actualización. Solo puedes ver los cambios en las reglas de los últimos 180 días. Revisar habitualmente esta actividad puede ayudarte a correlacionar las modificaciones de reglas con su impacto en tu empresa. ### Controla periódicamente tu cola de revisión manual Si tu cola de revisión es demasiado grande para gestionarla, asegúrate de tener implementadas las reglas correctas. Si la mayoría de las revisiones dan como resultado un reembolso por fraude, considera reglas adicionales para bloquear los pagos. Si la mayoría de los pagos se aprueban, considera hacer que tus reglas de revisión sean más específicas. ### Analiza tus pagos disputados y rembolsados Las [disputas](https://docs.stripe.com/disputes.md) están íntimamente ligadas al fraude, de manera que cuanto más medidas tomes para reducir el fraude, menor será tu tasa de disputas. Revisa si los pagos en disputa comparten alguna característica (por ejemplo, provienen del mismo lugar o tienen importes similares). También puedes hacer este tipo de investigaciones durante una revisión analizando los pagos que se reembolsaron. Si observas tendencias, podrás probar y crear las reglas apropiadas. Si algún pago parece fraudulento, te conviene reembolsarlo y denunciarlo como fraude para evitar posibles disputas. También puedes usar nuestros productos de elaboración de informes, Sigma y Data Pipeline, para [consultar disputas y datos sobre fraudes](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md). Puedes responder las disputas que lleguen usando el Dashboard o a través de la API. Además, nuestra [documentación sobre disputas](https://docs.stripe.com/disputes.md) incluye algunas sugerencias sobre cómo presentar casos bien documentados. ### Anticipa los grandes cambios en tu empresa que podrían influir en tu tasa de fraude Si tienes pensado hacer lanzamientos importantes o cambios en tu servicio (por ejemplo, lanzar un nuevo producto de alto valor o expandir tu servicio a nuevos países), es posible que al principio quieras controlar los pagos. En el caso de este tipo de cambios, es aconsejable configurar algunas reglas de revisión para poder examinar los pagos nuevos. Revisar estos pagos e identificar patrones puede ayudarte a configurar nuevas reglas que protejan a tu empresa del fraude. ## Las reglas admiten múltiples métodos de pago De forma predeterminada, las reglas de Radar controlan los pagos con tarjetas, ACH y débitos directos SEPA para la mayoría de los usuarios. Admitimos la regla de bloqueo de pagos de alto riesgo para todos estos métodos de pago. Si utilizas Radar para Equipos de Fraude o Radar para Plataformas, también aceptamos reglas personalizadas a través del atributo `:payment_method_type:` para escribir reglas que se apliquen solo a métodos de pago específicos, por ejemplo: `si :payment_method_type: = 'us_bank_account'`. Obtén más información sobre los [atributos admitidos](https://docs.stripe.com/radar/rules/supported-attributes.md). ## Crea reglas de cuenta Con Radar para Plataformas, también puedes agregar y administrar reglas de cuenta desde la pestaña **Reglas** en la página de Radar en el Dashboard. #### Para agregar una regla de cuenta 1. Haz clic en **+ Agregar regla**. 1. Selecciona el tipo de regla: **Revisar** o **Suspender transferencias** (lo que implica revisar Y suspender las transferencias). 1. En el editor de reglas, crea una regla usando la sintaxis `{action} if {attribute} {operator} {value}` donde: - `{action}`: cómo responde Radar cuando se cumplen los criterios de la regla. Este valor se completa previamente en función de la selección del tipo de regla que elegiste. - `{attribute}`: es el elemento del pago que se evaluará, como el importe o el tipo de tarjeta. Comienza escribiendo `:` para abrir una lista de atributos válidos. - `{operator}`: cómo comparar el atributo con el valor, como ``=`,`\>`,`!=`, etc. - `{value}`: es el valor del atributo que se evaluará. 1. Haz clic en **Probar regla**. 1. Corrige los errores de validación detectados, de ser necesario. 1. En la página **Revisar nueva regla**, consulta las cuentas que coincidirían con esta regla hoy para confirmar si quieres activarla. 1. Haz clic en **Activar regla** para aplicar esta regla a todas las cuentas existentes y futuras. La prueba de las reglas a nivel de cuenta lleva más tiempo que las pruebas de transacciones, sin embargo, recomendamos hacer pruebas para evitar que se envíen cuentas para su revisión o que se suspendan las transferencias automáticas de manera involuntaria. En primer lugar, prueba enviar una cuenta para revisar su comportamiento. A continuación, prueba suspender las transferencias automáticas cuando estés seguro de que la regla afecta a las cuentas tal y como se esperaba. ## See also - [Ejemplos de reglas de 3DS](https://docs.stripe.com/radar/rules.md#request-3d-secure) - [Guía para la gestión continua de fraudes](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) - [Consultar disputas y datos de fraude](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) - [Referencia sobre reglas](https://docs.stripe.com/radar/rules/reference.md) - [Atributos admitidos](https://docs.stripe.com/radar/rules/supported-attributes.md)