# 不正対策ルール 不正利用防止ルールを使用してビジネスを保護します。 Stripe Radar には、すべての[対応決済手段](https://docs.stripe.com/radar/supported-payment-methods.md)にわたって不正利用リスクの検出と防止を支援する組み込みルールが用意されています。すべての取引は、Radar のデフォルトルールを使用してスクリーニングされます。 Radar for Teams と [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md) では、[ダッシュボード](https://dashboard.stripe.com/test/radar/rules)を使用して、事業ロジックに基づいた[カスタムルール](https://docs.stripe.com/radar/supported-payment-methods.md#custom-risk-settings)を作成できます。たとえば、次のことができます。 - 新規顧客が行い、3D セキュア (3DS) に対応しているすべての支払いに対して、**3D セキュアをリクエストする** - コールセンターの IP アドレスからのすべての支払いを **許可する** - 国外から、または国外で発行されたカードによる支払いを **ブロックする** - プリペイドカードで行われた 1,000 USD を超えるすべての決済を **レビュー** する - 不審請求の申し立て率が高いアカウント (Radar for Platforms を使用) の**入金をレビューして自動的に一時停止します** > EU の事業者は、[ジオブロッキング規則](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes) および EU 加盟国の顧客による決済のブロックを禁止する規定の適用を受ける可能性があります。 ## 構築済みのルール カスタムルールとしてフラグが付けられていない限り、次のルールはデフォルトで使用できます。これらのルールは、Radar for Teams または Radar for Platforms を使用している場合にのみ使用できます。 > #### 不正利用を自動的にブロック > > または、Radar [リスク管理](https://docs.stripe.com/radar/risk-settings.md)を使用して、不正利用を自動的にブロックすることもできます。リスク管理では、[不正利用の早期警告](https://docs.stripe.com/radar/risk-settings.md#early-fraud-warning)を使用して、最高リスクの決済を評価してブロックします。 ### AI によるリスクチェック すべての Radar 製品には、AI モデルの判断に基づく一連のデフォルトルールが用意されています。 | Radar ルール | 説明 | | ----------------------------------- | ------------------------------------------------------------------------------------ | | `if :risk_level: = 'highest'` (非推奨) | このルールは、不正利用リスクが高い支払いをブロックし、取引処理を行いません。このルールは、すべての Radar ユーザーに対してデフォルトで有効になっています。 | | `if :risk_level: = 'elevated'` | Radar for Teams および Radar for Platforms のデフォルトの動作では、不正利用のリスクが比較的高いと疑われる決済が審査対象になります。 | Radar for Platforms には、次の 2 つのデフォルトルールを通じて組み込まれているアカウントレベルの AI モデルもあります。 `if :account_risk_level: = 'highest'` `if :account_risk_level: = 'elevated'` KYC 情報、取引、地理的リスク要因、行動パターンを使用して、アカウントレベルのリスクを算出します。 ### 従来のカードチェック *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) または住所 (*AVS* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)) のチェックが失敗した場合でも、決済が成功する場合があります。これは、カード発行会社が決済のオーソリを決定する際に、さまざまなリスク要因を評価するためです。カード発行会社は、CVC または郵便番号の確認に失敗した決済を正当なものと見なし、承認する場合があります。 Radar の構築済みのルールを有効にして、カード発行会社が承認した特定の支払いをブロックできます。有効にすると、これらのルールは、顧客へのカードの関連付けのほか、カードと顧客を一緒に作成した場合は顧客の作成にも影響します。 #### セキュリティコードと AVS のルール 2024 年 12 月 17 日から、新しい顧客と、レガシーのセキュリティコードと AVS のルールを使用していなかった既存の顧客には、ダッシュボードにこれらのルールが表示されます。 | Radar ルール | 説明 | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `リスクスコアに基づいてセキュリティコードの検証に合格できなかった場合は**ブロック**` | カード発行会社のCVCチェックに失敗した決済をブロックするには、このルールを有効にします。ただし、Stripe が低リスクと判断した場合は除きます。このルールでは、顧客が*ウォレット* (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)を使用している、またはカード発行会社がセCVC検証をサポートしていないなどの理由でCVCを提供しない決済はブロックされません。 | | `リスクスコアに基づいて郵便番号の検証に合格できなかった場合は**ブロック**` | カード発行会社の郵便番号確認チェックに失敗した決済をブロックするには、このルールを有効にします。ただし、Stripe が低リスクであると判断した場合は除きます。このルールは、顧客が郵便番号を提供しない場合や、カード発行会社が郵便番号の確認をサポートしていない場合の決済をブロックしません。 | #### レガシーのセキュリティコードと AVS のルール 2024 年 12 月 17 日以降、Dashboard では、これらのルールを少なくとも 1 つ有効にした既存の顧客に対して、これらのルールが表示されます。 | Radar ルール | 説明 | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `if CVC verification fails` | このルールが有効になっている場合、カード発行会社のCVCチェックに失敗した決済をブロックします。顧客が*ウォレット* (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)を使用しており、CVCを提供できない場合、または顧客のカード発行会社がこの検証をサポートしていない場合は、このルールで決済をブロックすることはできません。 | | `if postal code verification fails` | このルールを有効にすると、カード発行会社の郵便番号確認チェックに失敗した決済をブロックできます。このルールは、顧客が郵便番号を提供していない場合や、カード発行会社が郵便番号の確認をサポートしていない場合の決済をブロックしません。 | ### 3D セキュアをリクエストするための構築済みのルール *3D セキュア (3DS)* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) を使用すると、顧客は購入フローを完了する前に、追加の認証ステップを完了するように求められます。決済が 3DS によって認証されている場合、その決済で発生する不正利用に関する不審請求の申し立ての[責任](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments)は通常、売り手からカード発行会社に移ります。このため、ほとんどの場合、売り手は 3DS 認証済み決済の不正利用費用の責任を負いません。 Stripe は、カード発行会社によって 3DS が要求されていることを示すソフトディクラインコードを自動的に処理します。PSD2 によって義務付けられている[強力な顧客認証](https://stripe.com/guides/strong-customer-authentication) (SCA) などの規制に準拠するため、必要に応じて 3DS の起動も行います。Radar を無効にしても、3DS が必要な場合に起動されないことはありません。 Stripe は、Radar を [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) または [SetupIntents](https://docs.stripe.com/payments/save-and-reuse.md) とともに使用する場合に 3DS をリクエストする、3 つのレガシー組み込みルールをサポートしています。 | Radar ルール | 説明 | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `カードで 3D セキュアが推奨されている場合は`(非推奨) | このルールを有効にすると、リスクに基づいて顧客に 3DS 認証を促します。 | | `カードで 3D セキュアがサポートされている場合は`(非推奨) | このルールを有効にすると、カードが 3DS 認証をサポートしている限り、顧客に 3DS 認証を求めます。 | | `カードに 3D セキュアが必要な場合に`(Deprecated) | このルールを有効にすると、カードで過去に [3DS が必要](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#three-ds-cards)だった場合に、顧客に 3DS 認証を求めます。このルールに関係なく、Stripe は自動的に 3DS をトリガーします。 - カード発行会社が 3DS の使用を要求していることを支払い拒否コードが示している場合。 - PSD2 の[強力な顧客認証](https://stripe.com/guides/strong-customer-authentication) (SCA) 義務などの規制に準拠するため。 | 3DS では顧客が追加の認証レイヤーを通過する必要があるため、3DS をむやみに使用するとかえって購入完了率が低下する可能性があります。 3DS をリクエストしても、カード発行会社が実際に 3DS を実行するとは限りません。[発生しうる結果](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) を使用している場合は、許可、ブロック、またはレビューのルールの結果を評価できます。 カスタム Radar ルールで最も重要な属性については、以下を参照してください。 | 属性 | 説明 | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `is_3d_secure` | これは、カードがサポートされていて、カード発行会社によって 3DS が試行され、顧客が認証に失敗しなかった場合に当てはまります。通常、これをブロックルールで使用することをお勧めします。 | | `is_3d_secure_authenticated` | カード発行会社によって 3DS が試行され、顧客が完全な認証プロセスを正常に完了した場合に true になります。この属性をブロックルールで使用すると、SCA 免除が適用される可能性があるものや、処理エラーのように明確な失敗または成功に分類されない正当な取引が除外されてしまいます。 | | `has_liability_shift` | これは、Stripe が*ライアビリティシフト* (With some 3D Secure transactions, the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer)によってその決済が保護されると想定している場合に当てはまります。これは、必ずしも [3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments) と同じとは限りません。たとえば、一部の地域での Apple Pay などです。 | カスタムルールでは、[リスク選好度](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data)に応じて `Request 3DS` ルールと `Block` ルールを揃えることをお勧めします。ただし、一部のウォレットなど、3DS がサポートされていない決済はブロックしないでください。 これを実現する方法の例を、さまざまなユースケースでご紹介します。 #### Radar リスクレベルに基づいて 3D セキュアをリクエストする Radar を使用して、リスクレベルに基づいて一定金額を超えるすべての決済に 3DS をリクエストします。 | Radar ルール | 説明 | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | このルールは、リスクレベルが「やや高い」または「高い」で、かつ一定金額を超えるすべての決済に対して 3DS をリクエストする前に、Radar のリスクレベルを確認します。 | この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS では、決済のオーソリは継続されません。 #### Radar リスクレベルに基づいて常に 3D セキュアをリクエストする Radar を使用して、リスクレベルが「やや高い」または「高い」で、かつ一定金額を超えるすべての決済に 3DS をリクエストし、3DS をサポートしないカードは受け付けないようにします。 | Radar ルール | 説明 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | このルールは、一定金額を超える、リスクレベルが「やや高い」または「高い」のすべての支払いに対して 3DS をリクエストする前に、Radar のリスクレベルを確認します。 | | `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:)` | このルールは、リスクレベルが「やや高い」または「高い」で、一定金額を超える決済のうち、3DS フローがないものをブロックします。ただし、SCA 免除が適用される可能性があるものや、`attempt_acknowledged` のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの決済 (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は成功として受け付けます。 | #### 3D セキュアがサポートされている場合に、3D セキュアで完全に認証された決済のみを受け付ける [強力な顧客認証](https://stripe.com/guides/strong-customer-authentication) (SCA) などのケースでは、必要に応じて Stripe が 3DS を有効化しますが、処理エラーなどの[例外的なケース](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result)は受け付けたくありません。 | Radar ルール | 説明 | | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Block if :is_3d_secure: and not :is_3d_secure_authenticated:` | このルールは、カードが 3DS に登録されていて 3DS が試行されたものの、ユーザーが正常に認証されなかった決済をブロックします。3DS をサポートしていないカード、SCA 免除、オフセッションの決済 (継続的なサブスクリプションの支払いなど)、ウォレット (Apple Pay や Google Pay など) は受け付けます。 | #### メタデータに基づいて 3D セキュアをリクエストする Radar を使用して、カスタムメタデータ属性を持つすべての決済に 3DS をリクエストします。 | Radar ルール | 説明 | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | `Request 3D Secure if ::foo:: = 'bar'` | このルールは、メタデータ条件を確認して 3DS をリクエストします。顧客メタデータを確認するには、`::foo:: = 'bar'` を `::customer:trusted:: = 'false'` などの値に置き換えます。 | この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、決済のオーソリを続行しません。 #### メタデータに基づいて常に 3D セキュアを要求する Radar を使用して、カスタムメタデータ属性を持つすべての決済に 3DS をリクエストし、3DS をサポートしないカードをブロックします。 | Radar ルール | 説明 | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if ::foo:: = 'bar'` | このルールは、メタデータ条件を確認して 3DS をリクエストします。顧客メタデータを確認するには、`::foo:: = 'bar'` を `::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:)` | このルールは、カスタムメタデータ属性を使用する決済について、3DS フローのないものをブロックします。ただし、SCA 免除が適用される可能性があるものや、`attempt_acknowledged` のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの決済 (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は成功として受け付けます。 | #### すべての新しいクレジットカードに 3D セキュアをリクエストし、3D セキュアがサポートされていなかった場合に審査する Radar を使用してすべての新しいカードに 3DS をリクエストし、3DS がサポートされないカードからの決済を手動でレビューします。 | Radar ルール | 説明 | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if is_missing(:seconds_since_card_first_seen:)` | このルールは、このアカウントで以前に使用されたことのないすべてのカードに 3DS をリクエストします。ユーザーの負担を軽減するには、`:risk_level: != 'normal'` の場合にのみ 3DS をリクエストするという条件を追加できます。 | | `Request 3D Secure if :is_new_card_on_customer:` | 上記のルールの代替として、このルールでは、顧客が設定した [Account](https://docs.stripe.com/api/v2/core/accounts/object.md#v2_account_object-configuration-customer) または [Customer](https://docs.stripe.com/api/customers.md) で新たに使用されるすべてのカードに 3DS を要求します。ユーザーの負担を軽減するには、`:risk_level: != 'normal'` の場合にのみ 3DS を要求する条件を追加できます。 | | `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:)` | このルールは、3DS を想定していたものの 3DS がサポートされていなかった決済に、手動審査のマークを付けます。オフセッションの決済 (継続的なサブスクリプションの決済など) やウォレット (Apple Pay や Google Pay など) は無視します。審査のマークが付けられた決済は引き続きオーソリが行われ、カード発行会社による CVC の確認などの追加のリスク要因が得られます。 | この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、決済のオーソリを続行しません。 #### 特定の国のカード発行会社の場合は常に 3D セキュアを要求する Radar を使用して、[カスタムリスト](https://docs.stripe.com/radar/lists.md)にある国のカード発行会社からのすべての決済に 3DS をリクエストし、3DS をサポートしないカードをブロックします。 | Radar ルール | 説明 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :card_country: in @enforce_3ds_list` | このルールは、カード発行会社の発行国に基づく条件をチェックし、[カスタムリスト](https://docs.stripe.com/radar/lists.md)と比較します。一致する場合は、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:)` | このルールは、カスタムリストの国から発生する決済について、3DS フローのないものをブロックします。ただし、SCA 免除が適用される可能性があるものや、`attempt_acknowledged` のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの決済 (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は成功として受け付けます。 | #### Radar リスクレベルに基づいて常に 3D セキュアを要求し、エッジケースは審査する Radar を使用して、リスクレベルに基づいてすべての決済に 3DS をリクエストし、3DS をサポートしないカードはブロックしますが、エッジケースは手動でレビューします。 | Radar ルール | 説明 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Request 3D Secure if :risk_level: != 'normal'` | このルールは、一定金額を超える、リスクレベルが「やや高い」または「高い」すべての決済で 3DS をリクエストする前に、Radar のリスクレベルを確認します。 | | `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:)` | このルールは、リスクレベルが「やや高い」または「高い」で、一定金額を超える決済のうち、3DS フローのないものをブロックします。ただし、正当な取引で、SCA 免除が適用されている可能性のあるものは受け付けます。オフセッションの決済 (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は成功として受け付けます。 | | `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:)` | このルールは、3DS を使用したが、完全に認証されたフローに至らなかった決済を手動レビュー用にマークします。これにより、[エッジケース](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result) (たとえば `attempt_acknowledged` など) がレビューされ、SCA 免除が適用されている正当な決済もマークされます。レビュールールはブロックルールの後に評価されるため、3DS をサポートしないカードはブロックされます。 | ## ルールの作成 アカウント所有者、管理者、開発者のみがルールを作成できます。[チームメンバー](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)で、メンバーに管理者アクセス権があることを確認してください。 Stripe のデフォルトルールは、多くの不正利用をブロックできます。どの決済をレビュー、許可、ブロックするかをよりコントロールしたい企業は、Radar for Teams を通じてカスタムルールを作成できます。プラットフォームは Radar for platforms を通じてカスタムルールを作成し、プラットフォームおよび連結アカウントの決済リスクを調整し、アカウント固有のルールを適用できます。 カスタムルールを有効にするかどうかを決定する際は、以下を検討してください。 - 使い捨てのメールアドレスの使用など、特定の機能やユーザー行動のなかでリスクが高いと考えるものがある場合。 - 決済手段に基づくルールを実装する場合 (たとえば、特定のリスクスコアを超える SEPA ダイレクトデビット決済を自動的にブロックする場合)。 - 決済金額や想定されるリスクレベルに基づくルールを導入したい場合 (たとえば、決済が 500 USD を超える場合に自動的に審査対象とし、5 USD 未満の場合に自動的に許可するなど)。 - 既存の不審請求の申し立てが行われた決済や返金された決済に、共通のパターン (金額、カードの種類、国などの類似) はありますか？ - Stripe に移行したい既存のルールがある場合。そのようなルールの多くは、Stripe の AI モデルですでにカバーされている可能性があります。カスタマイズする前に、Stripe のシステムが自社ビジネスでどのように機能するかを確認できます。 - レビューを自動的に作成し、必要に応じてアカウントの入金を一時停止したい場合。これはプラットフォームにのみ適用されます。 ### 効果的なルールを作成する ルールは既存のワークフローの自動化に役立ちますが、誤って使用するとビジネスに悪影響を与える可能性もあります。たとえば、ルールが適切に設定されていないと、大量のリスクの高い決済を自動的に許可してしまったり、多くの正当な決済をブロックしてしまったりすることがあります。 ルールを設定する際には、次の点に注意してください。 - デフォルトでは、ルールはすべての[対応決済手段](https://docs.stripe.com/radar/supported-payment-methods.md)に適用されます。ただし、ルール述語で `payment_method_type` 属性を使用して特定の決済手段を定義した場合は除きます。 - ルールは今後の決済にのみ適用され、すでに処理されたものには適用されません。 - 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) を使用するときにのみ適用され、審査、ブロック、および許可のルールの前に評価されます。 - すべての決済をブロックしたり、基準を満たすアカウントの入金を一時停止したりするブロックルールを実装する前に、先に決済をレビューするのか、アカウントをレビューするのかを検討してください。 - 許可ルールは、同じ基準に一致する他のカスタムルールと共に Stripe のデフォルトルールを上書きするため、最小限に実装してください。 - 最大 200 個の取引ルールと 100 個のアカウントルールを作成できます。 ## 取引ルールの構築 Dashboard の [Radar Rules ページ](https://dashboard.stripe.com/test/radar/rules)からルールを追加および管理できます。 #### 取引ルールを追加するには 1. **+ ルールを追加**をクリックします。 1. ルールタイプを選択します。 1. ルールエディターで、構文 `{action} if {attribute} {operator} {value}` を使用してルールを構築します。各項目は以下のとおりです。 - `{action}`: ルールの条件が満たされた場合に Radar がどのように対応するかを示します。この値は、選択したルールタイプに基づいてあらかじめ入力されています。 - `{attribute}`: 評価する決済の要素 (金額やカードタイプなど)。`:` と入力し始めると、有効な属性のリストが表示されます。また、カスタムメタデータを 2 重のコロンで囲み (たとえば、`::product_sku::`)、評価することもできます。 - `{operator}`: 属性を値と比較する方法 (`=`、`>`、`!=` など)。 - `{value}`: 評価する属性の値。 1. **ルールをテストする**をクリックします。 1. 必要に応じて、検出された検証エラーを修正します。 1. **新しいルールのレビュー**ページで、最近の決済に対するこのルールのパフォーマンスを確認し、有効にするかどうかを決定します。ルールが複数の決済手段からの決済に影響を与える可能性がある場合は、フィルターを使用して決済手段 (ACH やカードなど) 別にルールのパフォーマンスを表示します。 1. 今後のすべての取引にこのルールを適用するには、**ルールを追加**をクリックします。 ### Radar アシスタントを使用する Stripe ルールエディターには、自然言語のプロンプトから Radar 取引ルールを作成する組み込みの LLM アシスタントがあります。[Stripe AI services](https://support.stripe.com/questions/use-of-artificial-intelligence-(ai) についてさらに詳しく見る。 > #### トレーニングデータへの同意 > > Radar Assistant を使用することで、お客様が入力したチャット内容を Stripe が記録し、Radar Assistant の機能のトレーニングと改善のために利用することに同意したものとみなされます。このような目的でチャット内容を使用されたくない場合は、ルールを手動で作成してください。 #### Radar Assistant を使用するには 1. [Radar Rules ページ](https://dashboard.stripe.com/test/radar/rules)で、**+ ルールを追加**をクリックします。 1. ルールタイプを選択します。 1. ルールエディターで **Radar アシスタント**をクリックします。 1. メッセージフィールドに、ルールのリクエストを入力します。以下のようなリクエストが可能です。 - 「カードと IP の国が異なる場合の支払いを確認します。」 - 「$1000 を超えるディスカバーカードによる支払いをブロックします。」 - 「stripe.com のメールアドレスからの支払いを許可します。」 1. アシスタントから提案が返されたら、追加のコマンドを入力してルールを調整するか、**ルールをテストする**をクリックして最近の取引履歴に対してルールがどのように機能するかを確認します。 1. ルールに問題がない場合は、**ルールを追加**をクリックして、今後のすべての取引で有効にします。 > #### フィードバックをお寄せください > > Radar アシスタントの継続的な改善にご協力ください。**フィードバックを送る**をクリックして、アシスタントの対応についての詳細と、改善すべき点をご説明ください。推奨内容の正確さ、UI、システムのその他の機能についてなど、あらゆるご意見をお待ちしております。 ### 審査ルール レビュールールの基準を満たす決済は、Stripe で通常どおり処理されますが、チームが詳細を確認できるように[レビューリスト](https://dashboard.stripe.com/test/radar)に追加されます。ルールの条件が広すぎると、レビューリストに入れられる決済が多くなりすぎ、顧客の体験が遅延し、レビューチームの負担が増える可能性があります。 Stripe のルールテストインターフェイスは、過去 6 ヵ月の決済に対してシミュレーションを実行し、そのルールを実装していた場合に、正当な決済、不正利用による決済、ブロックされた決済のそれぞれが何件影響を受けるかを判定します。ルールをテストし、過去 6 ヵ月の履歴を調べる際には、次の点を確認してください。 - **決済の全体量が少ない**。このような決済の審査であれば、チームに大きな負担はかかりません。 - **人による審査には付加価値がある**。審査担当者は、一般に自動化されたシステムよりも確信を持って、リスクの高い決済かどうかを見分けることができます。 - **ルールを適用した結果、成功した決済と返金または不審請求の申し立てが行われた決済が混在している**。このようなタイプの決済をさらに調査することで、正当な決済と不正利用による決済を切り分けることができます。 以下の例は、プリペイドクレジットカードの審査を必要とするビジネスが作成する審査ルールの改善方法を示しています。 | 元のルール | 改善されたルール | | ------------------------------- | --------------------------------------------------------- | | `if :card_funding: = 'prepaid'` | `if :is_disposable_email: and :card_funding: = 'prepaid'` | | このルールは広すぎるため、レビューが多すぎます。 | このルールはより的を絞ったものであり、レビューの回数が少なくなります。 | ### ブロックルール ブロックルールを使用して、不正利用である確率が高いとみられる決済や、ビジネスで適用している制限 (プリペイドカードからの決済のブロックなど) に該当する決済をブロックできます。ブロックルールの適用方法に確信が持てない場合は、レビュールールを使用して決済を審査することをお勧めします。これらの決済について偽陽性の可能性がないかどうかを審査することで、ブロックルールを作成するかどうかを確信を持って判断できるようになります。 すでにブロックされている支払いは影響を受けないため、ブロックルールは不正利用で成功した支払いのみに影響します。ルールをテストする際には、次を確認する必要があります。 - **できるだけ誤判定を少なくする**。Stripe はテスト中に、ルールに一致したであろう、成功した支払いの数と不審請求が申請された支払いの数を表示します。適切なブロックルールでは、正当な支払いよりはるかに多くの不正使用による支払いがブロックされます。 - **不要なルールを最小限に抑える**。ルールが非常にうまく機能しているように見えても、既存のルールですでにカバーされている場合、新しいルールは必要ないことがあります。同様に、テスト中に結果が混在しているように見える場合は、代わりに審査ルールを設定して、そのようなタイプの決済に関してより多くの情報を収集できるようにすることを検討してください。 以下は、アメリカ国外からの決済で不正利用の発生率が高いビジネスが作成したブロックルールの改善方法の例です。 | 元のルール | 改善されたルール | | ------------------------------ | --------------------------------------------------------- | | `if :card_country: != 'US'` | `if :card_country: != 'US' and :risk_level: = 'elevated'` | | このルールは広すぎるため、正当な決済が多数ブロックされます。 | このルールはより的を絞ったものであり、レビューの回数が少なくなります。 | ### 許可ルール 許可ルールの作成機能が必要な場合は、[お問い合わせ](https://support.stripe.com/contact)ください。 許可ルールは他のすべてのルールを上書きするため、注意して使用する必要があります。ビジネスの多くは、許可ルールを導入する必要はありません。許可ルールが少数の不正利用による支払いを見逃す可能性があるという懸念がある場合は、導入前に、これらのルールをさらに制限する調整を検討する必要があります。 ルールが作成されると、許可ルールは即座にすべての新しい支払いに適用されます。これには、以前ブロックされた支払いに類似したものが含まれます。ルールをテストする際は、次を確認する必要があります。 - **以前にブロックされた決済のうち許可されることになる件数を確認します**。許可ルールは、他のすべてのルールと Stripe のリスク評価を上書きします。新しい許可ルールをテストすると、このルールが有効であれば許可されたと考えられるすべての決済が表示されます。これには、ブロックされた決済や不審請求の申し立てが行われた決済も含まれ、今後の不審請求の申し立て率に影響を与える可能性があります。 - **リスクの高い決済は引き続きブロックします**。リスクの高い決済をブロックするには、許可ルールに次を追加します。`and :risk_level: != 'highest'` - **ビジネスでの正当な取引履歴を評価します**。各自の顧客間の関係を分析することで、正当な購入の履歴に基づき、より多くの取引を許可することができます。この結果、ビジネスで実証済みの履歴がある顧客からの支払いのブロックを減らすことが可能になります。これを行うには、[属性リスト](https://docs.stripe.com/radar/rules/reference.md#supported-attributes)を確認し、「customer (顧客)」という文字を含む属性を探します。 以下の例は、通常 (常にではありませんが)、イギリスの顧客から正当な決済を受けているビジネスでの、許可ルールの改善方法を示しています。 | 元のルール | 改善されたルール | | --------------------------------- | ------------------------------------------------------ | | `if :ip_country: = 'GB'` | `if :ip_country: = 'GB' and :risk_level: != 'highest'` | | このルールは広すぎるため、一部の不正利用による決済が許可されます。 | このルールはより的を絞ったものであり、結果として許可される不正利用による決済の件数が少なくなります。 | ## ルールの維持 ビジネスが成長し続けるにつれて、望ましい顧客のタイプをルールで確実に反映し続けることが重要です。以下は、ビジネスの状況に合わせてルールを最新の状態に保つためのベストプラクティスです。 ### ルールを定期的にモニタリングして、有効性が持続していることを確認すること #### ルールの指標 不正使用のパターンは常に変化するため、ルールのパフォーマンスを示す[指標](https://dashboard.stripe.com/settings/radar/rules)を提供しています。ルールのタイプによって実行されるアクションが異なるため、指標はルールのタイプによって異なります。 ![](https://b.stripecdn.com/docs-statics-srv/assets/rule-performance.8d495f28c352641ff7b710df3c3df2ed.png) 同じ期間内でレビュールールに一致した決済件数と、レビューリストに送信された決済件数の差異が見つかる場合があります。_「成功した」_決済のみがレビューの対象になるため、たとえばレビュールールの基準に一致しても、カード発行会社によって拒否された決済は、レビューリストに送信されません。 **ルールのパフォーマンスチャート**を使用して、Radar ルールの動作を把握します。ルールに一致する決済件数の予期しない急増または減少 (許可ルールが多すぎる決済を許可したり、ブロックルールが多すぎる決済をブロックしたりするなど) を探します。このような急増は、ビジネスが受け取る決済の種類の変化を示しているか、ルールの更新が必要になる可能性があります。 **色分けされた線**は、[3DS](https://docs.stripe.com/issuing/3d-secure.md) ルール、許可ルール、ブロックルール、レビュールールに一致する決済件数を追跡します。更新されたルールは、グラフの線に **三角形のシンボル** として表示され、変更前と変更後のインパクトを比較するのに役立ちます。 オーバーフローメニュー (⋯) をクリックすると、**無効化**、**有効化**、**編集**、**削除**などのルールの追加コマンドが表示されます。 Sigma や Data Pipelines といった Stripe のレポートプロダクトを使用して、個別の決済ごとのルール決定と属性を含む、不審請求の申し立てと不正利用のデータを[クエリできます](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md)。 #### ルールの有効性を評価する ルールの有効性に関する情報や、各ルールが影響した決済件数を確認できます。ルールが適用されたすべての決済のフィルター済みリストを表示してダウンロードすることもできます。 次の表のサンプル質問を確認して、ルールを変更する必要があるか、完全に削除する必要があるかを判断してください。 | ルールタイプ | 評価 | 検討すべきアクション | | ------ | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | 一般 | このルールに一致する決済がまったくなくなった場合。 | ルールを削除します。 | | | このルールに異常な動作 (たとえば、以前の期間より多くの支払いを許可するなど) がある場合。 | このルールに一致した決済を手動でレビューし、この挙動が望んだものかどうかを判断します。 | | 3DS | 3DS の完了率が高いが、不審請求の申し立てや不正利用の早期警告の件数が少ない場合。 | ユーザーに負担をかける可能性があるため、ルールを削除します。 | | | 3DS に成功する取引で不正利用の件数が多い場合。 | 3DS ルールをブロックルールに変更し、このようなユーザーがフリクションレスフロー (カード発行会社が管理するフロー) を通過したり、ファーストパーティーによる不正利用を行ったりするのを防ぐことを検討します。 | | | 3DS の購入完了率が低い場合。 | これは、不正利用者の大半をブロックしている可能性があるため、有効なルールである可能性があります。ただし、一致した決済を手動で調査して、正当なユーザーの負担が増して離脱していないかどうかを確認することを検討してください。 | | 許可 | 不審請求の申し立て、不正利用の早期警告、返金、決済失敗の件数が多い場合。 | 不当な支払いを見逃すルールを削除します。 | | ブロック | ブロック件数は減っているのに、不正利用の件数は変わらないか増加している場合。 | ルールが有効でない可能性があるため、変更します。 | | | ブロック件数は増えているのに、不正利用の件数は変わらなかったり増加していたりする場合。 | 正当なユーザーをブロックする可能性があるため、ルールの変更を検討します。 | | | ブロック件数は増えていて、不正利用の件数は減っている場合。 | これは有効なルールである可能性があります。少数の取引を手動でレビューして、正当なユーザーをブロックしすぎていないことを確認することを検討してください。 | | 手動審査 | 審査を通過した支払いの割合が低い場合。 | ルールが広すぎる可能性があるため、ルールをより厳しくします。 | | | 成功した支払いまたは承認された支払いの件数が多いかどうか。 | 手動審査ルールを完全に削除するか、そうした決済を対象とする許可ルールを作成します。 | | | 返金や不審請求の申し立て、不正利用の早期警告の件数が多い場合。 | ブロックルールに変換します。 | #### 3DS リクエストルールをリクエスト リクエスト 3DS ルールの場合、**3DS Requested** と表示されます。これは、ルールが 3DS リクエストをトリガーした回数です。3DS ルールをクリックすると、次の指標を確認できます。 ![](https://b.stripecdn.com/docs-statics-srv/assets/request-credentials-rule-details.c22b65bc432aafec9e5bcb6079c53528.png) **許可ルール** Radar for Teams を使用している場合は、次の許可ルールを確認できます。 - **許可された決済**: ルールによって許可された決済の合計件数。 - **許可された決済の総額**: ルールによって許可された決済に関連付けられている、現地通貨による合計金額。 - **リスクスコア**: ルールで許可された一連の決済に対して、AI モデルによって割り当てられた対応する[リスク結果](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes)。 - **上書きによる異議申し立て**: 許可された決済で不審請求に対して異議申し立てが行われた合計件数。 - **上書きオーバーライドによる不審請求の申し立て金額**: 許可された決済から生じた不審請求の申し立てに関連付けられている、国内通貨による合計金額。 > 不審請求の申し立てに関する指標が高い場合は、最終的に不審請求が申し立てられる決済を許可しないようにするために、より対象を厳しく絞り込む許可ルールの記述を検討することをお勧めします。 許可ルールを選択すると、次の指標が表示されます。 ![](https://b.stripecdn.com/docs-statics-srv/assets/allow-rule-details.e8da078613fdbca5592d2f9330c0f6d4.png) **ブロックルール** 次のブロックルールを表示できます。 - **ブロックされた決済**: ルールによってブロックされた決済の合計件数。 - **ブロックされた決済の金額**: ルールによってブロックされた決済に関連付けられている、現地通貨による合計金額。 Radar for Teams を使用している場合は、次の項目も表示できます。 - **リスクスコア**: ルールで許可された一連の決済に対して、AI モデルによって割り当てられた対応する[リスク結果](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes)。 - **推定偽陽性率**: セットとしてのブロックルールと個々のルールの両方によってブロックされた、不正利用ではない決済の推定割合です。この推定は、対応する AI リスクスコアで推定される偽陽性率を使用して行われます。リスクスコアは、Stripe ネットワーク全体で実行される実験によって算出されます。 - **防止された不正な決済の推定件数**: ブロックルールによって防止された不正利用による決済の推定件数。Stripe は、Stripe ネットワーク全体の数百万件もの取引を分析して計算した AI リスクスコアを使用して、不正利用により不審請求が申し立てられたり拒否された可能性が高い決済を予測し、それらのうちどの決済がルールによって正常にブロックされたかを推定します。 > 推定偽陽性率の指標が高い場合には、より対象を厳しく絞り込むブロックルールの作成を検討したり、ルールの対象にする決済を見直して、不正利用ではない決済を多くブロックしないようにすることをお勧めします。 ブロックルールを選択すると、以下の指標が表示されます。 ![](https://b.stripecdn.com/docs-statics-srv/assets/block-rule-details.5df9a2e8652f228cf61b525a32ef56da.png) **審査ルール** Radar for Teams を使用している場合は、以下のレビューリストを表示できます。 - **レビューに送信された決済**: ルールによって手動レビューに送信された決済の合計件数。 - **承認された審査の金額**: 審査で承認された決済に関連付けられている、現地通貨による合計金額。 - **返金率**: 返金された審査の比率。 - **承認済み審査からの不審請求の申し立て**: レビューにより承認されたが、最終的に不審請求の申し立てが行われた決済の合計件数。 - **承認済み審査からの不審請求の申し立て金額**: 承認された決済審査から生じた不審請求の申し立てに関連付けられている、現地通貨による合計金額。 レビュールールを選択すると、以下の指標が表示されます。 ![](https://b.stripecdn.com/docs-statics-srv/assets/review-rule-details.10851302ef65dee05ffce64f7989528f.png) #### ルール履歴を表示 Radar ルールに加えられた変更の履歴を表示できます。この監査証跡は、ルールがいつ作成、編集、有効化、または無効化されたか、およびチームのどのユーザーによって実行されたかを理解するのに役立ちます。 特定のルールのアクティビティを確認するには、Radar ページの [Rules](https://dashboard.stripe.com/radar/rules) タブに移動して、ルールの名前をクリックします。 **Rule activity** ログには、すべての変更のサマリーが表示されます。特定のイベントをクリックすると、更新前と更新後の完全なルール述語などの詳細が表示されます。過去 180 日間のルールの変更のみを確認できます。 このアクティビティを定期的にレビューすることで、ルールの変更とビジネスへの影響を関連付けることができます。 ### 手動審査リストを定期的に監視する レビューリストが多すぎて管理できない場合は、正しいルールが設定されていることを確認してください。不正利用が原因でほとんどのレビューが返金されている場合は、決済をブロックする追加ルールを検討してください。ほとんどの決済が承認されている場合は、レビュールールをより絞り込むことを検討してください。 ### 不審請求が申請された支払いと返金された支払いを分析する [不審請求の申し立て](https://docs.stripe.com/disputes.md)は本質的に不正利用に関連しているため、不正利用削減への取り組みを強化すると、不審請求の申し立て率は低くなります。不審請求の申し立てが行われた決済に共通する特徴があるかどうかを確認してください (場所の一致、金額の類似性など)。この種の調査は、審査中に返金された決済を確認することでも行えます。傾向が見られたら、適切なルールをテストして作成します。不正利用による決済と思われるものは返金し、不正利用として報告して、潜在的な不審請求の申し立てを回避してください。 Sigma や Data Pipeline といった Stripe のレポートプロダクトを使用して、[不審請求の申請と不正利用のデータをクエリ](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md)できます。 ダッシュボードを使用して、または API を介して、受領したあらゆる不審請求の申請に対応できます。また、Stripe の[不審請求の申請に関するドキュメント](https://docs.stripe.com/disputes.md)には、十分に反証を収集した事例を提示するための推奨事項がいくつか記載されています。 ### 不正利用率に影響を与える可能性があるビジネスへの大きな変化を予測する 主要な商品リリースやサービスの変更 (新しい高額商品や新しい国へのサービス拡大など) を計画している場合、開始当初はこれらの決済を監視することをお勧めします。このような変更については、審査ルールを設定して、新しい決済をすべて調べられるようにすることをお勧めします。これらの決済をしばらく審査してパターンを識別することが、ビジネスを不正利用から保護する新しいルールの設定に役立ちます。 ## ルールは複数の決済手段に対応する デフォルトでは、Radar ルールは、ほとんどのユーザーのカード、ACH、SEPA ダイレクトデビットの決済をスクリーニングします。これらの決済手段のすべてで、高リスクのブロックルールに対応しています。Radar for Teams または Radar for Platforms を使用している場合は、`:payment_method_type:` 属性を使用して、特定の決済手段のみに適用されるルールを作成するカスタムルールも利用できます。たとえば、`if :payment_method_type: = 'us_bank_account'` などです。[supported attributes](https://docs.stripe.com/radar/rules/supported-attributes.md) の詳細をご覧ください。 ## アカウントルールの構築 Radar for Platforms では、Dashboard の Radar ページの **Rules** タブからアカウントルールを追加および管理することもできます。 #### アカウントルールを追加するには 1. **+ ルールを追加**をクリックします。 1. ルールのタイプとして、**Review** または **Payout pause** (レビューの起票と入金の一時停止) を選択します。 1. ルールエディターで、構文 `{action} if {attribute} {operator} {value}` を使用してルールを構築します。各項目は以下のとおりです。 - `{action}`: ルールの条件が満たされた場合に Radar がどのように対応するかを示します。この値は、選択したルールタイプに基づいてあらかじめ入力されています。 - `{attribute}`: は、金額やカードの種類など、評価する決済の要素です。`:` の入力を始めると、有効な属性のリストが表示されます。 - `{operator}`: 属性を値と比較する方法 (`=`、`>`、`!=` など)。 - `{value}`: 評価する属性の値。 1. **ルールをテストする**をクリックします。 1. 必要に応じて、検出された検証エラーを修正します。 1. **新しいルールのレビュー** ページで、今日このルールに一致するアカウントを確認して、ルールを有効にするかどうかを判断します。 1. **Activate rule** をクリックして、このルールを既存および今後のすべてのアカウントに適用します。 アカウントレベルのルールのテストは、取引のテストよりも時間がかかりますが、意図せずにレビューのためにアカウントを起票したり、自動入金を一時停止したりしないように、テストすることをお勧めします。まず、レビューのためにアカウントを起票する動作をテストします。次に、ルールがアカウントに想定どおりに影響することを確認したら、自動入金の自動一時停止をテストします。 ## See also - [3DS ルールの例](https://docs.stripe.com/radar/rules.md#request-3d-secure) - [継続的不正利用管理ガイド](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) - [不審請求の申請と不正利用のデータをクエリする](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) - [ルールリファレンス](https://docs.stripe.com/radar/rules/reference.md) - [サポートされる属性](https://docs.stripe.com/radar/rules/supported-attributes.md)