# 不正対策ルール

不正対策ルールを使用してビジネスを保護します。

Fraud prevention rules allow you to take action whenever a payment matches certain criteria. Stripe Radar provides built-in rules to help detect and protect you against fraud risk on card, ACH, and SEPA Direct Debit payments.

Radar for Fraud Teams and [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md) let you use the [Dashboard](https://dashboard.stripe.com/test/radar/rules) to create custom rules based on the business logic specific to your business. For example, you can:

- 新規顧客が行い、3D セキュア (3DS) に対応しているすべての支払いに対して、**3D セキュアをリクエストする**
- コールセンターの IP アドレスからのすべての支払いを **許可する**
- 国外から、または国外で発行されたカードによる支払いを **ブロックする**
- **Review** all payments greater than 1,000 USD that were made with a prepaid card
- **Review and automatically pause payouts** on accounts that have a high dispute rate (with Radar for Platforms)

> EU の事業者は、[ジオブロッキング規則](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes) および EU 加盟国の顧客による決済のブロックを禁止する規定の適用を受ける可能性があります。

## 構築済みのルール

The following rules are available by default, unless flagged as custom rules, which are only available if you use Radar for Fraud Teams or Radar for Platforms.

> #### Block fraud automatically
> 
> Alternatively, you can use Radar [risk controls](https://docs.stripe.com/radar/risk-settings.md) to block fraud automatically. The risk controls use [early fraud warnings](https://docs.stripe.com/radar/risk-settings.md#early-fraud-warning) to evaluate and block the highest risk payments.

### AI によるリスクチェック

All Radar offerings provide a set of default rules based on the judgments of our AI models.

| Radar rule                          | 説明                                                                                                                                                      |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `if :risk_level: = 'highest'` (非推奨) | このルールは、不正利用リスクが高い支払いをブロックし、取引処理を行いません。このルールは、すべての Radar ユーザーに対してデフォルトで有効になっています。                                                                        |
| `if :risk_level: = 'elevated'`      | The default behavior for Radar for Fraud Teams and Radar for Platforms is to place payments into review that we suspect have an elevated risk of fraud. |

Radar for Platforms has additional account-level AI models that are incorporated through two default rules:

`if :account_risk_level: = 'highest'`

`if :account_risk_level: = 'elevated'`

We calculate account-level risk using KYC information, transactions, geographic signals, and behavior patterns.

### 従来のカードチェック

カード発行会社は支払いのオーソリを判断する際に多数のシグナルを評価するため、*セキュリティコード* (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)または住所 (*AVS* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)) のチェックに合格できなかった場合でも、支払いは成功する可能性があります。カード発行会社は、セキュリティコードまたは郵便番号の検証に合格できなかった支払いを正当なものと見なし、承認する場合があります。

Radar の構築済みのルールを有効にして、カード発行会社が承認した特定の支払いをブロックできます。有効にすると、これらのルールは、顧客へのカードの関連付けのほか、カードと顧客を一緒に作成した場合は顧客の作成にも影響します。

#### セキュリティコードと AVS のルール

2024 年 12 月 17 日から、新しい顧客と、レガシーのセキュリティコードと AVS のルールを使用していなかった既存の顧客には、ダッシュボードにこれらのルールが表示されます。

| Radar rule                                    | 説明                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `リスクスコアに基づいてセキュリティコードの検証に合格できなかった場合は**ブロック**` | Enable this rule to block payments that fail a card issuer’s CVC verification check, unless Stripe evaluates it as low risk. This rule doesn’t block payments where the customer doesn’t provide the CVC number because they, for example, use a *wallet* (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), or their card issuer doesn’t support its verification. |
| `リスクスコアに基づいて郵便番号の検証に合格できなかった場合は**ブロック**`      | Enable this rule to block payments that fail a card issuer’s postal code verification check, unless Stripe evaluates it as low risk. This rule doesn’t block payments where the customer doesn’t provide the postal code, or their card issuer doesn’t support its verification.                                                                                                                                                                                                              |

#### レガシーのセキュリティコードと AVS のルール

Effective December 17, 2024, the Dashboard shows these rules to existing customers who enabled at least one of the rules.

| Radar rule                          | 説明                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `if CVC verification fails`         | Enable this rule to block payments that fail a card issuer’s CVC verification check. This rule doesn’t block payments where the customer doesn’t provide the CVC number because they, for example, use a *wallet* (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), or their card issuer doesn’t support its verification. |
| `if postal code verification fails` | Enable this rule to block payments payments when they fail a card issuer’s postal code verification check. This rule doesn’t block payments where the customer doesn’t provide the postal code, or their card issuer doesn’t support its verification.                                                                                                                                                                                                |

### 3D セキュアをリクエストするための構築済みのルール

*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) prompts customers to complete an additional authentication step before they can complete the purchase flow. If 3DS authenticates a payment, the [liability](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments) for any fraud-related disputes for that payment typically shifts from the seller to the issuer. This means that in most cases, the seller isn’t responsible for fraud costs on 3DS authenticated payments.

Stripe automatically handles soft decline codes indicating that 3DS is required by issuers. We also trigger 3DS when necessary, adhering to regulations, such as the [Strong Customer Authentication](https://stripe.com/guides/strong-customer-authentication) (SCA) mandated by the PSD2. Disabling Radar doesn’t prevent 3DS from being triggered in cases where it’s necessary.

Stripe supports three legacy built-in rules to request 3DS when using Radar with [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) or [SetupIntents](https://docs.stripe.com/payments/save-and-reuse.md):

| Radar rule                        | 説明                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `カードで 3D セキュアが推奨されている場合は`(非推奨)    | Enable this rule to prompt the customer for 3DS authentication based on risk.                                                                                                                                                                                                                                                                                                                                                                                 |
| `カードで 3D セキュアがサポートされている場合は`(非推奨)  | Enable this rule to prompt the customer for 3DS authentication, as long as their card supports it.                                                                                                                                                                                                                                                                                                                                                            |
| `カードに 3D セキュアが必要な場合に`(Deprecated) | Enable this rule to prompt the customer for 3DS authentication, if the card historically [required 3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#three-ds-cards). Regardless of this rules, Stripe automatically triggers 3DS:
  - カード発行会社が 3DS の使用を要求していることを支払い拒否コードが示している場合。
  - In adherence to regulations, such as the PSD2 [Strong Customer Authentication](https://stripe.com/guides/strong-customer-authentication) mandate. |

3DS では顧客が追加の認証レイヤーを通過する必要があるため、3DS をむやみに使用するとかえって購入完了率が低下する可能性があります。

Requesting 3DS doesn’t necessarily mean the issuer actually performs 3DS. Learn more about [possible outcomes](https://docs.stripe.com/payments/3d-secure.md).

### 3D セキュアをリクエストして特定の結果に対応するためのカスタムルール

3DS 認証を試行した後、[Radar for Fraud Teams](https://stripe.com/radar/fraud-teams) または [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md) を使用している場合は、許可、ブロック、またはレビューのルールの結果を評価できます。

See below for the most important attributes for custom Radar rules.

| Attribute                    | 説明                                                                                                                                                                                                                                                                                                                                                                                              |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `is_3d_secure`               | This is true if the card is supported, 3DS was attempted by the issuer, and the customer didn’t fail authentication. We generally recommend using this in block rules.                                                                                                                                                                                                                          |
| `is_3d_secure_authenticated` | This is true if 3DS was attempted by the issuer and the customer successfully completed a full authentication. Using this attribute in a block rule excludes legitimate transactions that might have an SCA exemption or don’t fall into a clear failure or successful authentication, such as processing errors.                                                                               |
| `has_liability_shift`        | This is true if Stripe expects *liability shift* (With some 3D Secure transactions, the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer) to cover the payment. This might not always be the same as [3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments), for example Apple Pay in certain regions. |

For custom rules, we recommend keeping `Request 3DS` and `Block` rules aligned depending on your [risk appetite](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data). However, don’t block payments where 3DS isn’t supported, such as from some wallets.

See below for some examples that show how to achieve this for different use cases.

#### Radar リスクレベルに基づいて 3D セキュアをリクエストする

You want to use Radar to request 3DS on all payments, based on the risk level and that are above a certain amount.

| Radar rule                                                               | 説明                                                                                                                                          |
| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | This rule checks for the Radar risk level before requesting 3DS on all payments with an elevated or high risk level above a certain amount. |

In this case, without a block rule, cards or wallets that don’t support 3DS aren’t blocked. 3DS attempts that failed authentication don’t continue to charge authorization.

#### Radar リスクレベルに基づいて常に 3D セキュアをリクエストする

You want to use Radar to request 3DS on all payments, based on an elevated or high risk level and that are above a certain amount. You don’t want to support cards that don’t support 3DS.

| Radar rule                                                                                                                                                                                                               | 説明                                                                                                                                                                                                                                                                                                                                                                                                      |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25`                                                                                                                                                 | This rule checks for the Radar risk level before requesting 3DS on all charges with an elevated or high risk level above a certain amount.                                                                                                                                                                                                                                                              |
| `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:)` | This rule blocks elevated or high-risk payments above a certain amount that don’t have a 3DS flow. This rule accepts legitimate payments that might have an SCA exemption or don’t have a clear failure or successful authentication, such as `attempt_acknowledged`. It accepts off-session payments, such as recurring subscription charges, and wallets, such as Apple Pay or Google Pay to succeed. |

#### Only accept fully 3D Secure authenticated payments if 3D Secure is supported

You rely on Stripe activating 3DS when necessary in cases such as [Strong Customer Authentication](https://stripe.com/guides/strong-customer-authentication) (SCA), but don’t want to accept [edge cases](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), such as processing errors.

| Radar rule                                                     | 説明                                                                                                                                                                                                                                                                                                         |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Block if :is_3d_secure: and not :is_3d_secure_authenticated:` | This rule blocks payments where the card is enrolled in 3DS, and 3DS was attempted but the user didn’t successfully authenticate. Cards that don’t support 3DS, SCA exemptions, off-session payments (such as recurring subscription charges), and wallets (such as Apple Pay or Google Pay) are accepted. |

#### Request 3D Secure based on metadata

You want to use Radar to request 3DS on all payments with a custom metadata attribute.

| Radar rule                             | 説明                                                                                                                                                                         |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Request 3D Secure if ::foo:: = 'bar'` | This rule checks for a metadata condition and then requests 3DS. To check customer metadata, replace `::foo:: = 'bar'` with a value like `::customer:trusted:: = 'false'`. |

In this case, without a block rule, we don’t block cards or wallets that don’t support 3DS. 3DS attempts that failed authentication don’t continue to charge authorization.

#### Always require 3D Secure based on metadata

You want to use Radar to request 3DS on all payments with a custom metadata attribute and block cards that don’t support it.

| Radar rule                                                                                                                                                                   | 説明                                                                                                                                                                                                                                                                                                                                                                                                      |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Request 3D Secure if ::foo:: = 'bar'`                                                                                                                                       | This rule checks for a metadata condition and then requests 3DS. To check customer metadata, replace `::foo:: = 'bar'` with a value like `::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:)` | This rule blocks payments that don’t have a 3DS flow for charges with a custom metadata attribute. This rule accepts legitimate payments that might have an SCA exemption or don’t have a clear failure or successful authentication, such as `attempt_acknowledged`. It accepts off-session payments, such as recurring subscription charges, and wallets, such as Apple Pay or Google Pay to succeed. |

#### すべての新しいクレジットカードに 3D セキュアをリクエストし、3D セキュアがサポートされていなかった場合に審査する

You want to use Radar to request 3DS on all new cards and manually review payments from cards that don’t support 3DS.

| Radar rule                                                                                                                                               | 説明                                                                                                                                                                                                                                                                                                                             |
| -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Request 3D Secure if is_missing(:seconds_since_card_first_seen:)`                                                                                       | This rule requests 3DS on all cards that haven’t been used on your account. To reduce user friction, you can add a condition to only request 3DS if `:risk_level: != 'normal'`.                                                                                                                                                |
| `Request 3D Secure if :is_new_card_on_customer:`                                                                                                         | As an alternative to the rule above, this rule requests 3DS on all cards that are newly used on a [Customer](https://docs.stripe.com/api/customers.md). To reduce user friction, you can add a condition to only request 3DS if `: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:)` | This rule marks payments where 3DS is expected, but isn’t supported for manual review. It ignores off-session payments, such as recurring subscription charges, and wallets, such as Apple Pay or Google Pay. Payments marked for review continue to authorization and can give additional signals, such as issuer CVC checks. |

In this case, without a block rule, we don’t block cards or wallets that don’t support 3DS. 3DS attempts that failed authentication don’t continue to charge authorization.

#### 特定の国のカード発行会社の場合は常に 3D セキュアを要求する

You want to use Radar to request 3DS on all payments from card issuers originating from countries on a [custom list](https://docs.stripe.com/radar/lists.md) and block the cards that don’t support it.

| Radar rule                                                                                                                                                                                       | 説明                                                                                                                                                                                                                                                                                                                                                                                                              |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Request 3D Secure if :card_country: in @enforce_3ds_list`                                                                                                                                       | This rule checks for a condition based on the card issuer’s country of origin and compares them to a [custom list](https://docs.stripe.com/radar/lists.md). If they match, we request 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:)` | This rule blocks payments that don’t have a 3DS flow and that originate from countries on the custom list. This rule accepts legitimate payments that might have an SCA exemption or don’t have a clear failure or successful authentication, such as `attempt_acknowledged`. It accepts off-session payments, such as recurring subscription charges, and wallets, such as Apple Pay or Google Pay to succeed. |

#### Radar リスクレベルに基づいて常に 3D セキュアを要求し、エッジケースは審査する

You want to use Radar to request 3DS on all payments based on the risk level, and block cards that don’t support 3DS, but manually review edge cases.

| Radar rule                                                                                                                                                                                                     | 説明                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Request 3D Secure if :risk_level: != 'normal'`                                                                                                                                                                | This rule checks for the Radar risk level before requesting 3DS on all elevated or high-risk payments above a certain amount.                                                                                                                                                                                                                                                                                                                 |
| `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:)`                | This rule blocks elevated or high-risk payments above a certain amount and that don’t have a 3DS flow. This rule accepts legitimate payments that might have an SCA exemption. It accepts off-session payments, such as recurring subscription charges, and wallets, such as Apple Pay or Google Pay to succeed.                                                                                                                              |
| `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:)` | This rule marks payments that used 3DS, but didn’t result in a fully authenticated flow, for manual review. This reviews [edge cases](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), such as `attempt_acknowledged`, and also marks legitimate payments despite SCA exemptions. Because review rules are evaluated after block rules, we block cards that don’t support 3DS. |

## Create rules

アカウント所有者、管理者、開発者のみがルールを作成できます。[チームメンバー](https://support.stripe.com/questions/can-i-invite-other-team-members-or-my-developer-to-use-my-stripe-account)がルールを作成する必要がある場合は、[チームの設定](https://dashboard.stripe.com/settings/team)で、メンバーに管理者アクセス権があることを確認してください。

The Stripe default rules can block a substantial number of fraudulent payments. Businesses that need more control over which payments they want to review, allow, or block can write custom rules through Radar for Fraud Teams. Platforms can write custom rules through Radar for Platforms to calibrate payments risk for their platform and connected accounts and apply account-specific rules.

カスタムルールを有効にするかどうかを決定する際は、以下を検討してください。

- If you see certain features or user behaviors as more risky (for example, using a disposable email).
- If you want to implement rules based on the payment method (for example, automatically blocking SEPA Direct Debit payments that exceed a certain risk score).
- If you want to implement rules based on payment amounts or perceived risk level (for example, automatically review if the payment is over 500 USD, automatically allow if the payment is under 5 USD).
- If your existing disputed and refunded payments share any common patterns (for example, similar amounts, card types, or countries).
- If you have existing rules you want to migrate to Stripe. The Stripe AI model might already cover many of these rules, and you can check how our system performs for your business before customizing it.
- If you want to automatically raise reviews and optionally pause payouts on accounts. This applies to platforms only.

### Create effective rules 

While rules can help you automate your existing workflows, they can also negatively affect your business if used incorrectly. For example, a rule can automatically allow a large number of elevated or high-risk payments or block a large number of legitimate payments, if it isn’t set up properly.

Remember the following when setting up rules:

- デフォルトでは、`payment_method_type` 属性を使用してルール述語で特定の決済手段を定義しない限り、ルールは Radar がサポートするすべての決済手段に適用されます。
- Rules only apply to future payments and don’t apply to any that you already processed.
- 3DS のリクエストに関するルールは、[Stripe Checkout](https://docs.stripe.com/payments/checkout.md)、[Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md)、または [Setup Intents](https://docs.stripe.com/payments/save-and-reuse.md) を使用するときにのみ適用され、審査、ブロック、および許可のルールの前に評価されます。
- Before implementing any block rule to block all payments or pause payouts for accounts that meet its criteria, consider whether you’d rather review the payments or accounts first.
- Implement any allow rules minimally, because they override the Stripe default rules, along with any other custom rules that match the same criteria.
- 最大 200 個の取引ルールと 100 個のアカウントルールを作成できます。

## 取引ルールの構築

You can add and manage rules from the [Radar Rules page](https://dashboard.stripe.com/test/radar/rules) in the Dashboard.

#### To add a transaction rule

1. **+ ルールを追加**をクリックします。
1. Select the rule type.
1. ルールエディターで、構文 `{action} if {attribute} {operator} {value}` を使用してルールを構築します。各項目は以下のとおりです。
   - `{action}`: is how Radar responds when the rule criteria is met. This value is pre-populated based on the rule type you selected.
   - `{attribute}`: is the element of the payment to evaluate, such as the amount or card type. Begin typing with `:` to open a list of valid attributes. You can also evaluate your custom metadata by enclosing it in double colons, for example, `::product_sku::`.
   - `{operator}`: is how to compare the attribute to the value, such as `=`, `>`, `!=`, and so on.
   - `{value}`: is the value of the attribute to evaluate.
1. **ルールをテストする**をクリックします。
1. 必要に応じて、検出された検証エラーを修正します。
1. On the **Review new rule** page, review how this rule performs against your recent payments to confirm whether you want to enable it. If the rule might impact payments from more than one payment method, use the filter to view rule performance by payment method (for example, ACH or Cards).
1. Click **Add rule** to apply this rule to all future transactions.

### Radar アシスタントを使用する

The Stripe rule editor has a built-in LLM assistant that constructs a Radar transaction rule from a natural language prompt. Learn more about [Stripe AI services](https://support.stripe.com/questions/use-of-artificial-intelligence-\(ai\)-in-stripe-services).

> #### Training data consent
> 
> By using Radar Assistant you agree that Stripe can log and use your chat entries to train and improve the Radar Assistant capabilities. If you don’t want to have your chat entries used for this purpose, write rules manually.

#### To use Radar Assistant

1. On the [Radar Rules page](https://dashboard.stripe.com/test/radar/rules), click **+ Add rule**.
1. Select the rule type.
1. ルールエディターで **Radar アシスタント**をクリックします。
1. In the message field, enter your rule request. You might ask to:
   - 「カードと IP の国が異なる場合の支払いを確認します。」
   - 「$1000 を超えるディスカバーカードによる支払いをブロックします。」
   - 「stripe.com のメールアドレスからの支払いを許可します。」
1. When the Assistant returns its suggestion, you can either enter an additional command to make adjustments to the rule, or you can click **Test rule** to see how the rule performs against your recent transaction history.
1. When you’re satisfied with the rule, click **Add rule** to enable it for all future transactions.

> #### フィードバックをお寄せください
> 
> Radar アシスタントの継続的な改善にご協力ください。**フィードバックを送る**をクリックして、アシスタントの対応についての詳細と、改善すべき点をご説明ください。推奨内容の正確さ、UI、システムのその他の機能についてなど、あらゆるご意見をお待ちしております。

### 審査ルール

Stripe still processes payments normally when they match a review rule’s criteria. We add these payments to your [review queue](https://dashboard.stripe.com/test/radar) so your team can review them more closely. Setting up a rule that’s too broad can result in too many payments placed in your review queue, slowing down your customers and burdening your review team.

The Stripe rule testing interface runs a simulation on the last 6 months of charges to determine how many legitimate, fraudulent, and blocked payments would have been affected by the rule, had it been implemented. While testing a rule and examining the last 6 months, make sure that:

- **Overall volume of payments is low**. Reviewing these payments shouldn’t create a burden for your team.
- **Human reviewers add value**. A human reviewer can generally identify an elevated or high-risk payment with greater confidence than the automated system.
- **The rule results in a mix of successful and refunded or disputed payments**. This means that additional inspection on these types of payments can help separate legitimate payments from fraudulent payments.

以下の例は、プリペイドクレジットカードの審査を必要とするビジネスが作成する審査ルールの改善方法を示しています。

| 元のルール                                                   | 改善されたルール                                                              |
| ------------------------------------------------------- | --------------------------------------------------------------------- |
| `if :card_funding: = 'prepaid'`                         | `if :is_disposable_email: and :card_funding: = 'prepaid'`             |
| This rule is too broad and results in too many reviews. | This rule is more focused and results in a smaller number of reviews. |

### ブロックルール

You can use block rules to block payments that you’re confident are fraudulent, or based on any restrictions your business has in place (such as blocking payments from prepaid cards). If you’re not sure how to apply block rules, we recommend using a review rule to place payments in review. After reviewing these payments for potential false positives, you can confirm whether you want to create a block rule instead.

すでにブロックされている支払いは影響を受けないため、ブロックルールは不正利用で成功した支払いのみに影響します。ルールをテストする際には、次を確認する必要があります。

- **できるだけ誤判定を少なくする**。Stripe はテスト中に、ルールに一致したであろう、成功した支払いの数と不審請求が申請された支払いの数を表示します。適切なブロックルールでは、正当な支払いよりはるかに多くの不正使用による支払いがブロックされます。
- **Minimize unnecessary rules**. If your rule appears to perform well but is already covered by an existing rule, your newer rule might not be necessary. Similarly, if the results during testing appear to be mixed, consider setting up a review rule instead so you can gather more information about those types of payments.

The following is an example of how to improve a block rule created by a business that has a high level fraud from payments outside the US.

| 元のルール                                                                   | 改善されたルール                                                              |
| ----------------------------------------------------------------------- | --------------------------------------------------------------------- |
| `if :card_country: != 'US'`                                             | `if :card_country: != 'US' and :risk_level: = 'elevated'`             |
| This rule is too broad and blocks a high number of legitimate payments. | This rule is more focused and results in a smaller number of reviews. |

### 許可ルール

If you want the ability to create allow rules, [contact us](https://support.stripe.com/contact).

許可ルールは他のすべてのルールを上書きするため、注意して使用する必要があります。ビジネスの多くは、許可ルールを導入する必要はありません。許可ルールが少数の不正利用による支払いを見逃す可能性があるという懸念がある場合は、導入前に、これらのルールをさらに制限する調整を検討する必要があります。

ルールが作成されると、許可ルールは即座にすべての新しい支払いに適用されます。これには、以前ブロックされた支払いに類似したものが含まれます。ルールをテストする際は、次を確認する必要があります。

- **Examine the number of previously blocked payments that would have been allowed**. Allow rules override all other rules and Stripe’s risk assessment. When testing a new allow rule, all payments shown would have been allowed if this rule were active. This can include payments that had been blocked or disputed, impacting your future dispute rates.
- **Continue to block any high-risk payments**. Block high-risk payments by adding the following to any allow rule: `and :risk_level: != 'highest'`
- **ビジネスでの正当な取引履歴を評価します**。各自の顧客間の関係を分析することで、正当な購入の履歴に基づき、より多くの取引を許可することができます。この結果、ビジネスで実証済みの履歴がある顧客からの支払いのブロックを減らすことが可能になります。これを行うには、[属性リスト](https://docs.stripe.com/radar/rules/reference.md#supported-attributes)を確認し、「customer (顧客)」という文字を含む属性を探します。

The following is an example of how to improve an allow rule for a business that generally (but not always) sees legitimate payments coming from customers in the UK:

| 元のルール                                                       | 改善されたルール                                                                                   |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `if :ip_country: = 'GB'`                                    | `if :ip_country: = 'GB' and :risk_level: != 'highest'`                                     |
| This rule is too broad and allows some fraudulent payments. | This rule is more focused and results in allowing a smaller number of fraudulent payments. |

## Maintain your rules

As your business continues to grow, make sure your rules continue to reflect the types of customers that you want to do business with. The following are some best practices to keep rules current for the state of your business.

### Regularly monitor rules to make sure they’re still effective 

#### ルールの指標

不正使用のパターンは常に変化するため、ルールのパフォーマンスを示す[指標](https://dashboard.stripe.com/settings/radar/rules)を提供しています。ルールのタイプによって実行されるアクションが異なるため、指標はルールのタイプによって異なります。
![](https://b.stripecdn.com/docs-statics-srv/assets/rule-performance.8d495f28c352641ff7b710df3c3df2ed.png)

You might notice a difference in the number of payments that matched review rules and the number of payments sent to your review queue in the same time period. Because only *successful* payments are placed in review, payments that match a review rule’s criteria but get declined by the issuer, for example, aren’t sent to your review queue.

Use the **rule performance chart** to understand the behavior of your Radar rules. Look for unexpected spikes or declines in the number of payments matching your rules, such as allow rules letting through too many payments or block rules blocking too many. These spikes might indicate a change in the types of payments your business receives or that might necessitate updates to the rules.

**Color-coded lines** track the number of payments that match [3DS](https://docs.stripe.com/issuing/3d-secure.md) rules, allow rules, block rules, and review rules. Updated rules are displayed as **triangular symbols** on the graph lines, and can help you compare the impact of a change before and after you make it.

Click the overflow menu (⋯) to view additional commands for any rule, including **Disable**, **Enable**, **Edit** or **Delete**.

You can also use our reporting products, Sigma and Data Pipelines, to [query disputes and fraud data](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md), including rule decisions and attributes for each individual payment.

#### ルールの有効性を評価する

You can find information about the effectiveness of your rules and see how many payments each rule has affected. You can also view and download a filtered list of every payment that a rule has been applied to.

Review the sample questions in the following table to help you decide if you need to make changes to any rules or remove them entirely.

| Rule type | 評価                                                                                             | 検討すべきアクション                                                                                                                                                                                                      |
| --------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 一般        | If this rule no longer matches any payments.                                                   | ルールを削除します。                                                                                                                                                                                                      |
|           | このルールに異常な動作 (たとえば、以前の期間より多くの支払いを許可するなど) がある場合。                                                 | Manually review payments that match this rule to determine if this is the behavior you want.                                                                                                                    |
| 3DS       | If the 3DS completion rate is high, but the number of disputes or early fraud warnings is low. | Remove the rule because you might be causing friction for your users.                                                                                                                                           |
|           | 3DS に成功する取引で不正利用の件数が多い場合。                                                                      | Consider modifying your 3DS rule into a block rule to prevent these users from passing frictionless flow (controlled by issuers) or committing first-party fraud.                                               |
|           | 3DS の購入完了率が低い場合。                                                                               | This might be an effective rule because it might be mostly blocking fraudsters. Consider manually investigating matched payments to make sure your good users aren’t abandoning because of additional friction. |
| 許可        | If the number of disputes, early fraud warnings, refunds, or failed payments is high.          | 不当な支払いを見逃すルールを削除します。                                                                                                                                                                                            |
| ブロック      | If the number of blocks is going down, but your fraud is still steady or increasing.           | ルールが有効でない可能性があるため、変更します。                                                                                                                                                                                        |
|           | ブロック件数は増えているのに、不正利用の件数は変わらなかったり増加していたりする場合。                                                    | Modify your rule because it might block good users.                                                                                                                                                             |
|           | If the number of blocks is going up, and your fraud is going down.                             | This might be an effective rule. Consider manually reviewing a few transactions to make sure you’re not blocking too many good users.                                                                           |
| 手動審査      | 審査を通過した支払いの割合が低い場合。                                                                            | Make the rule more restrictive because it might be too broad.                                                                                                                                                   |
|           | 成功した支払いまたは承認された支払いの件数が多いかどうか。                                                                  | Remove the manual review rule entirely, or write an allow rule to target those payments.                                                                                                                        |
|           | If the number of refunds or disputes and early fraud warnings are high.                        | ブロックルールに変換します。                                                                                                                                                                                                  |

#### Request 3DS rules

For request 3DS rules, we display **3DS Requested**, which is the number of times a rule triggered a 3DS request. You can click a 3DS rule to see the following metrics.
![](https://b.stripecdn.com/docs-statics-srv/assets/request-credentials-rule-details.c22b65bc432aafec9e5bcb6079c53528.png)

**許可ルール**

If you use Radar for Fraud Teams, you can view the following allow rules:

- **Allowed payments**: The total number of payments allowed by your rules.
- **Volume, allowed payments**: The total amount, in your local currency, associated with payments allowed by your rules.
- **Risk score**: The corresponding [risk outcomes](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) assigned by our AI models to the set of payments allowed by your rules.
- **Disputes from overrides**: The total number of allowed payments that were disputed.
- **Volume, disputes from overrides**: The total amount, in your local currency, associated with disputes from allowed payments.

> If the disputed metrics are high, you might consider writing more narrowly targeted allow rules, to prevent allowing payments through that are eventually disputed.

Select an allow rule to see the following metrics:
![](https://b.stripecdn.com/docs-statics-srv/assets/allow-rule-details.e8da078613fdbca5592d2f9330c0f6d4.png)

**ブロックルール**

You can view the following block rules:

- **Blocked payments**: The total number of payments blocked by your rules.
- **Volume, blocked payments**: The total amount, in your local currency, associated with payments blocked by your rules.

If you use Radar for Fraud Teams, you can also view the following:

- **Risk score**: The corresponding [risk outcomes](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) assigned by our AI models to the set of payments allowed by your rules.
- **Est. false positive rate**: The estimated percentage of non-fraudulent payments that were blocked for both your block rules as a set and by individual rules. These estimates are made using the estimated false positive rates of the corresponding AI risk scores, which we calculate with experiments across the Stripe network.
- **Est. fraudulent payments prevented**: The estimated number of fraudulent payments that your block rules prevented. Stripe uses AI risk scores, calculated by analyzing millions of transactions across the Stripe network, to predict payments with a high probability of being disputed or declined because of fraud, and estimate which of those payments were successfully blocked by your rules.

> If the estimated false positive rate metrics are high, you might consider writing more narrowly targeted block rules or reviewing which payments are covered by the rule, to avoid blocking as many non-fraudulent payments.

Select a block rule to see the following metrics:
![](https://b.stripecdn.com/docs-statics-srv/assets/block-rule-details.5df9a2e8652f228cf61b525a32ef56da.png)

**審査ルール**

If you use Radar for Fraud Teams, you can view the following review rules:

- **Payments sent to review**: The total number of payments sent to manual review by your rules.
- **Volume, approved reviews**: The total amount, in your local currency, associated with approved payment reviews.
- **Refund rate**: The percentage of reviews that were refunded.
- **Disputes from approved reviews**: The total number of payments approved in your review, but were ultimately disputed.
- **Volume, disputes from approved reviews**: The total amount, in your local currency, associated with disputes from approved payment reviews.

Select a review rule to see the following metrics:
![](https://b.stripecdn.com/docs-statics-srv/assets/review-rule-details.10851302ef65dee05ffce64f7989528f.png)

#### ルール履歴を表示

Radar ルールに加えられた変更の履歴を表示できます。この監査証跡は、ルールがいつ作成、編集、有効化、または無効化されたか、およびチームのどのユーザーによって実行されたかを理解するのに役立ちます。

To see the activity for a specific rule, go to the [Rules](https://dashboard.stripe.com/radar/rules) tab on the Radar page and click the name of the rule.

**Rule activity** ログには、すべての変更のサマリーが表示されます。特定のイベントをクリックすると、更新前と更新後の完全なルール述語などの詳細が表示されます。過去 180 日間のルールの変更のみを確認できます。

このアクティビティを定期的にレビューすることで、ルールの変更とビジネスへの影響を関連付けることができます。

### Regularly monitor your manual review queue 

If your review queue is too large to manage, make sure you have the correct rules in place. If most reviews result in a refund because of fraud, consider additional rules to block payments. If most payments are approved, consider making your review rules more focused.

### 不審請求が申請された支払いと返金された支払いを分析する

[Disputes](https://docs.stripe.com/disputes.md) are inherently linked to fraud, so the more you do to reduce fraud, the lower your dispute rate. Check to see if disputed payments share any similar characteristics (for example, from the same locations or of similar amounts). You can also perform this type of investigation by looking at payments that were refunded during a review. If you see trends, you can test and create the appropriate rules. If any payments appear to be fraudulent, refund and report them as fraud to avoid potential disputes.

Sigma や Data Pipeline といった Stripe のレポートプロダクトを使用して、[不審請求の申請と不正利用のデータをクエリ](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md)できます。

ダッシュボードを使用して、または API を介して、受領したあらゆる不審請求の申請に対応できます。また、Stripe の[不審請求の申請に関するドキュメント](https://docs.stripe.com/disputes.md)には、十分に反証を収集した事例を提示するための推奨事項がいくつか記載されています。

### Anticipate large changes to your business that might impact your fraud rate 

If you’re planning any major product releases or changes to your service (for example, a new, high-value product or expanding your service into new countries), you might want to monitor these payments in the beginning. For these kinds of changes, it’s a good practice to set up some review rules so you can examine any new payments. Reviewing these payments and identifying patterns can help you set up new rules to help protect your business from fraud.

## ルールは複数の決済手段をサポートしています (新規)

By default, Radar rules screen payments for cards, ACH, and SEPA Direct Debits for most users. We support the high risk block rule for all of these payment methods. If you use Radar for Fraud Teams or Radar for Platforms, we also support custom rules using the `:payment_method_type:` attribute to write rules that apply only to specific payment methods, for example: `if :payment_method_type: = 'us_bank_account'`. Learn more about [supported attributes](https://docs.stripe.com/radar/rules/supported-attributes.md).

## アカウントルールの構築

With Radar for Platforms, you can also add and manage account rules from the **Rules** tab on the Radar page in the Dashboard.

#### To add an account rule

1. **+ ルールを追加**をクリックします。
1. Select the rule type: **Review** or **Payout pause** (which raises a review AND payout pause).
1. ルールエディターで、構文 `{action} if {attribute} {operator} {value}` を使用してルールを構築します。各項目は以下のとおりです。
   - `{action}`: is how Radar responds when the rule criteria is met. This value is pre-populated based on the rule type you selected.
   - `{attribute}`: is the element of the payment to evaluate, such as the amount or card type. Begin typing with `:` to open a list of valid attributes.
   - `{operator}`: is how to compare the attribute to the value, such as `=`, `>`, `!=`, and so on.
   - `{value}`: is the value of the attribute to evaluate.
1. **ルールをテストする**をクリックします。
1. 必要に応じて、検出された検証エラーを修正します。
1. On the **Review new rule** page, view the accounts that would match this rule today to confirm whether you want to enable it.
1. Click **Activate rule** to apply this rule to all existing and future accounts.

Testing account-level rules takes longer than transaction testing, however we recommend testing to avoid unintentionally raising accounts for review or pausing automatic payouts. First, test raising accounts for review behavior. Then, test automatic payout pauses after you’re confident the rule impacts accounts as expected.

## See also

- [3DS rule examples](https://docs.stripe.com/radar/rules.md#request-3d-secure)
- [Continuous fraud management guide](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data)
- [Query disputes and fraud data](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md)
- [Rules reference](https://docs.stripe.com/radar/rules/reference.md)
- [Supported attributes](https://docs.stripe.com/radar/rules/supported-attributes.md)