不正対策ルール

不正対策ルールを使用すると、支払いが特定の基準に一致するたびにアクションを実行できます。

Stripe Radar には、すべての Stripe ユーザーを対象に、カード、ACH、SEPA ダイレクトデビットによる決済の不正利用リスクを検出して保護するためのルールが組み込まれています。

Radar for Fraud Teams および Radar for Platforms のユーザーは、ダッシュボードで会社固有のビジネスロジックに基づいたカスタムルールを作成できます。たとえば、次のようなルールが作成可能です。

• 新規顧客が行い、3D セキュア (3DS) に対応しているすべての支払いに対して、3D セキュアをリクエストする
• コールセンターの IP アドレスからのすべての支払いを 許可する
• 国外から、または国外で発行されたカードによる支払いを ブロックする
• プリペイドカードで行われた 1,000 USD を超えるすべての支払いを 審査する
• 不審請求の申し立て率が高いアカウントの入金を確認し、自動的に一時停止する (Radar for Platforms を使用)

構築済みのルール

以下のルールは、カスタムルールとしてフラグが立てられていない限り、デフォルトですべての Radar ユーザーが使用できます。カスタムルールは、Radar for Fraud Teams または Radar for Platforms ユーザーのみが使用できます。

AI risk checks

All Radar offerings provide a set of default rules based on the judgments of our AI models, which are:

Block if :risk_level: = 'highest'

このルールは、不正利用リスクが高い支払いをブロックし、取引処理を行いません。このルールは、すべての Radar ユーザーに対してデフォルトで有効になっています。

Review if :risk_level: = 'elevated'

Stripe Radar for Fraud Teams および Radar for Platforms のデフォルトの動作では、不正利用リスクが高いと疑われる支払いがレビュー対象になります。

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

**レビュー**が acccount_risk_level の場合 'highest'

**レビュー**が acccount_risk_level の場合'elevated'

KYC 情報、取引、地理的指標、行動パターンを参照してアカウントのリスクを評価します。

従来のカードチェック

カード発行会社は支払いのオーソリを判断する際に多数のシグナルを評価するため、セキュリティコードまたは住所 (AVS) のチェックに合格できなかった場合でも、支払いは成功する可能性があります。カード発行会社は、セキュリティコードまたは郵便番号の検証に合格できなかった支払いを正当なものと見なし、承認する場合があります。

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

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

3DS を使用すると、顧客は購入フローを完了する前に、追加の認証ステップを完了するように求められます。3DS によって支払いが認証されている場合、その支払いで発生する不正利用の申し立ての責任は、通常は、販売者からカード発行会社に移ります。このため、ほとんどの場合、販売者は 3DS 認証済みの支払いに対する不正利用の費用の責任を負いません。

Stripe は、カード発行会社によって 3DS が要求されていることを示す再試行可能な支払い拒否コードを自動的に処理します。PSD2 によって義務付けられている強力な顧客認証 (SCA) などの規制に準拠するため、必要に応じて 3DS の起動も行います。Radar を無効にしても、3DS が必要な場合に起動されないことはありません。

Stripe は、Payment Intents (支払いインテント) またはSetup Intents (設定インテント) で Radar を使用する際に 3DS をリクエストする、3 種類のレガシーの構築済みルールをサポートしています。

1. カードで 3D セキュアが推奨されている場合は 3D セキュアをリクエストする非推奨
   • Radar の認証不正防止制御は、このルールに置き換わりました。
2. カードで 3D セキュアがサポートされている場合は 3D セキュアをリクエストする非推奨
   • Radar の認証不正防止制御は、このルールに置き換わりました。
   • このルールを有効にすると、カードが 3DS 認証をサポートしている限り、顧客に 3DS 認証を求めるプロンプトが表示されます。
3. カードに 3D セキュアが必要な場合に 3D セキュアをリクエストするDeprecated
   • カードが過去に 3DS を要求していた場合、このルールを有効にすると、顧客に 3DS 認証を求めるプロンプトが表示されます。
   • このルールに関係なく、Stripe は自動的に 3DS をトリガーします。
     • カード発行会社が 3DS の使用を要求していることを支払い拒否コードが示している場合。
     • PSD2 の強力な顧客認証要件などの規制に準拠している場合。

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

3DS をリクエストしても、必ずしもカード発行会社が実際に 3DS を実行するとは限りません。考えられる結果について詳しくは、3D セキュアのドキュメントをご覧ください。

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

3DS 認証を試行した後、Radar for Fraud Teams または Radar for Platforms を使用している場合は、許可、ブロック、またはレビューのルールの結果を評価できます。

カスタム Radar ルールで最も重要な属性は次のとおりです。

• is_3d_secure: カードがサポートされていて、カード発行会社による 3DS の試行でユーザーが認証に失敗しなかった場合に true になります。通常はこれをブロックルールで使用することをお勧めします。
• is_3d_secure_authenticated: カード発行会社によって 3DS が試行され、ユーザーが認証プロセス全体に成功した場合に true になります。この属性をブロックルールで使用すると、SCA 免除が適用される可能性があるか、処理エラーのように認証の失敗または成功が明確ではない正当な取引が除外されます。
• has_liability_shift: 支払いがライアビリティシフトルールの対象になると Stripe が予測する場合に true になります。これは必ずしも 3DS と同じとは限りません (例: 一部地域での Apple Pay など)。

カスタムルールについては、リスク選好度に応じて 3DS を要求するルールと ブロックルールを合わせることをお勧めします。ただし、一部のウォレットなど、3DS がサポートされない取引はブロックしないようにする必要があります。

これを実現する方法の例を、さまざまなユースケースでご紹介します。

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

Radar を使用して、Radar リスクレベルに基づいて一定金額を超えるすべての支払いに 3DS をリクエストします。

この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、支払いのオーソリを続行しません。

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

Radar を使用して、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに 3DS をリクエストします。クレジットカードで 3DS がサポートされない場合は受け付けません。

3D セキュアがサポートされている場合に 3D セキュアで認証された取引のみを受け付ける

Stripe を利用して、強力な顧客認証 (SCA) など、必要な場合に 3DS を起動しますが、処理エラーのようなエッジケースは受け付けません。

メタデータに基づいて 3D セキュアをリクエストする

Radar を使用して、カスタムメタデータ属性を持つすべての支払いに 3DS をリクエストします。

この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、支払いのオーソリを続行しません。

メタデータに基づいて常に 3D セキュアを要求する

Radar を使用して、カスタムメタデータ属性を持つすべての支払いに 3DS をリクエストし、3DS をサポートしないクレジットカードをブロックします。

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

Radar を使用してすべての新しいクレジットカードに 3DS をリクエストし、3DS がサポートされないクレジットカードの支払いは手動で審査します。

この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、支払いのオーソリを続行しません。

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

Radar を使用して、カスタムリストにある国のカード発行会社からのすべての支払いに 3DS をリクエストし、3DS をサポートしないクレジットカードをブロックします。

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

Radar を使用して、Radar リスクレベルに基づいてすべての支払いに 3DS をリクエストし、3DS をサポートしないクレジットカードはブロックしますが、手動でエッジケースを審査します。

ルールを作成する状況

Stripe のデフォルトルールでは、大半の不正な支払いをブロックできます。支払いごとにレビュー、許可、ブロックを詳細に制御する必要がある場合は、Radar for Fraud Teams を使用してカスタムルールを作成することをお勧めします。プラットフォームは、Radar for Platforms を使用してカスタムルールを作成し、プラットフォームと連結アカウントの支払いリスクを調整し、アカウント固有のルールを適用できます。

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

• リスクが高いと思われる特定の特徴やユーザーの行動 (使い捨てのメールアドレスの使用など) があるかどうか。
• 決済手段に基づくルールを実装するかどうか (たとえば、特定のリスクスコアを超える SEPA ダイレクトデビットを自動的にブロックするなど)。
• 支払い金額や認識されるリスクレベルに基づくルール の導入を希望するかどうか (支払いが 500 USD を超えている場合に自動的に審査対象とし、支払いが 5 USD 未満の場合に自動的に許可するなど)。
• 既存の不審請求が申請された支払いと返金された支払いに、共通のパターン (金額、カードの種類、または国の類似など) があるかどうか。
• Whether you have existing rules you want to migrate to Stripe—many of these rules might already be covered by Stripe’s AI models, and you can check how our system performs for your business before customizing it.
• プラットフォームの場合:レビュー対象の自動指定やアカウントの支払いの一時停止を必要に応じて設定します。

効果的なルールの作成方法

ルールは既存のワークフローの自動化に役立ちますが、誤って使用するとビジネスに悪影響を与える可能性もあります。たとえば、ルールが適切に設定されていないと、ルールが不正使用による大量の支払いを自動的に許可したり、多くの正当な支払いをブロックしたりすることもあります。

ルールを設定する際は、次の点に注意してください。

• デフォルトでは、payment_method_type 属性を使用してルール述語で特定の決済手段を定義しない限り、ルールは Radar がサポートするすべての決済手段に適用されます。
• ルールは今後の支払いにのみ適用され、すでに処理されたものには適用されません
• 3DS のリクエストに関するルールは、Stripe Checkout、Payment Intents、または Setup Intents を使用するときにのみ適用され、審査、ブロック、および許可のルールの前に評価されます。
• 基準を満たすアカウントのすべての支払いをブロックしたり、入金を一時停止したりするブロックルールを実装する前に、まずそのような支払いやアカウントをレビューするかどうかを検討してください。
• 許可ルールは、同じ基準に一致する他のカスタムルールと共に、Stripe のデフォルトルールを上書きするため、最小限に実装します。
• 最大 200 個の取引ルールと 100 個のアカウントルールを作成できます。

取引ルールの構築

ダッシュボードの Radar ページのルールタブから、ルールを追加して、管理することができます。

新しいルールを追加するには、以下のようにします。

1. + ルールを追加をクリックします。
2. サブメニューからタイプルールのタイプを選択します。
3. ルールエディターで、構文 {action} if {attribute} {operator} {value} を使用してルールを構築します。各項目は以下のとおりです。
   • {action}: ルール基準が満たされた場合の Radar の対応。この値は、選択したルールタイプに基づいて事前入力されています。
   • {attribute}: 評価する取引の要素 (金額やカードタイプなど)。最初に : を入力して、有効な属性のリストを開きます。また、カスタムのメタデータを 2 重のコロンで囲み (たとえば、::product_sku::)、評価することもできます。
   • {operator}: 属性を値と比較する方法 (=、>、!= など)。
   • {value}: 評価する属性の値。
4. ルールをテストするをクリックします。
5. 必要に応じて、検出された検証エラーを修正します。
6. 新しいルールの確認 ページで、最近の取引に対するこのルールのパフォーマンスを確認し、有効にするかどうかを確認します。ルールが複数の決済手段の取引に影響を与える可能性がある場合は、決済手段フィルターを使用して、決済手段 (ACH やカードなど) ごとにルールのパフォーマンスを表示します。
7. 今後のすべての取引にこのルールを適用するには、ルールを追加をクリックします。

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

Stripe のルールエディターには、自然言語プロンプトから Radar 取引ルールを作成するビルトインの LLM アシスタントが搭載されています。

Radar アシスタントを使用するには、以下のようにします。

1. ダッシュボードの Radar ページのルールタブで、+ ルールを追加をクリックします。
2. サブメニューからルールタイプを選択します。
3. ルールエディターで Radar アシスタントをクリックします。

ルールを自分で記述

Radarアシスタント

1. メッセージフィールドに、ルールのリクエストを入力します。以下のようなリクエストが可能です。
   • 「カードと IP の国が異なる場合の支払いを確認します。」
   • 「$1000 を超えるディスカバーカードによる支払いをブロックします。」
   • 「stripe.com のメールアドレスからの支払いを許可します。」
2. アシスタントから提案が返されたら、追加のコマンドを入力してルールを調整するか、ルールをテストするをクリックして最近の取引履歴に対してルールがどのように機能するかを確認します。
3. ルールに問題がない場合は、ルールを追加をクリックして、今後のすべての取引で有効にします。

トレーニングデータへの同意: Radar Assistant を使用することで、お客様のチャットへの入力を Stripe が記録し、Radar Assistant の機能のトレーニングと改善のために Stripe が利用することに同意したとみなされます。このような目的でのチャットへの入力の使用を望まない場合は、ルールを手動で作成してください。

Stripe AI サービス の詳細をご覧ください。

審査ルール

審査ルールの基準を満たす支払いは、Stripe で通常どおり処理されますが、チームが詳細を確認できるように審査リストに配置されます。ルールの条件が広すぎると、審査リストに入れられる支払いが多くなりすぎ、顧客の体験が遅延し、審査チームに負担がかかる可能性があります。

Stripe のルールのテストインターフェイスは、過去 6 カ月の支払いに対してシミュレーションを実行し、そのルールによる影響が及ぶと考えられる正当な支払い、不正利用による支払い、ブロックされた支払いの数を判定します。ルールをテストし、過去 6 カ月の履歴を調べる際には、確認の必要な事項があります。

• 支払いの全体量が少ない。このような支払いの審査は、チームに負担がかかりません。
• 審査担当者が価値を向上している。審査担当者は、一般に自動化されたシステムよりも確実に支払いが不正使用であったかどうかを判断できます。
• ルールを適用した結果、成功した支払い、返金または不審請求が申請された支払いが混在している。これらのタイプの支払いをさらに調査することで、不正利用による支払いから正当な支払いを切り離すことができます。

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

ブロックルール

ブロックルールを使用して、不正利用である確率が高いとみられる支払いや、ビジネスで適用している制限 (プリペイドカードからの支払いのブロックなど) に該当する支払いをブロックできます。ブロックルールの適用方法に確信が持てない場合は、審査ルールを使用して支払いを審査することをお勧めします。これらの支払いについて偽陽性の可能性がないかどうかをしばらく審査することで、ブロックルールに移行するかどうかを確信を持って判断できるようになります。

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

• できるだけ誤判定を少なくする。Stripe はテスト中に、ルールに一致したであろう、成功した支払いの数と不審請求が申請された支払いの数を表示します。適切なブロックルールでは、正当な支払いよりはるかに多くの不正使用による支払いがブロックされます。
• 不要なルールを最小限に抑える。ルールが非常にうまく機能しているように見えても、既存のルールですでにカバーされている場合、新しいルールは必要ないことがあります。同様に、テスト中に結果が混在しているように見える場合は、代わりに審査ルールを設定して、そうしたタイプの支払いに関してより多くの情報を収集できるようにすることを検討してください。

以下は、アメリカ国外からの支払いでの不正使用のレベルが高いビジネスが作成したブロックルールの改善方法の例です。

許可ルール

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

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

• 以前にブロックされた支払いのうち許可されることになる数を調べます。許可ルールは、他のすべてのルールと Stripe のリスク評価を上書きします。新しい許可ルールをテストすると、このルールが有効であれば許可されたと考えられるすべての支払いが表示されます。これには、ブロックまたは不審請求の申請が行われた支払いが含まれ、今後の不審請求の申請率に影響を与える可能性があります。
• リスクの高い支払いのブロックは続行します。これを行うには、許可ルールに次を追加します。and :risk_level: != 'highest'
• ビジネスでの正当な取引履歴を評価します。各自の顧客間の関係を分析することで、正当な購入の履歴に基づき、より多くの取引を許可することができます。この結果、ビジネスで実証済みの履歴がある顧客からの支払いのブロックを減らすことが可能になります。これを行うには、属性リストを確認し、「customer (顧客)」という文字を含む属性を探します。

以下の例は、通常 (常にではありませんが) 、イギリスの顧客から問題のない支払いを受けているビジネスでの、許可ルールの改善方法を示しています。

ルールの管理

ビジネスが成長し続けるためには、望ましい顧客のタイプをルールで確実に反映し続けることが重要です。以下は、ビジネスの状況に合わせてルールを適切な状態に保ち、機能させ続けるためのベストプラクティスです。

ルールを定期的にモニタリングして、有効性が持続していることを確認する

ルールの指標

不正使用のパターンは常に変化するため、ルールのパフォーマンスを示す指標を提供しています。ルールのタイプによって実行されるアクションが異なるため、指標はルールのタイプによって異なります。

ルールのパフォーマンスチャートを使用して、Radar ルールの機能状況を把握します。ルールに一致する支払い件数の想定外の急増や減少 (許可ルールで許可される支払いが多すぎる、ブロックルールによるブロック件数が多すぎるなど) がないかを確認します。急増は、ビジネスで受け取る支払いの種類が変化したことを示す場合も、ルール自体の更新が必要になっていることを示す場合もあります。ルールを更新すると、グラフ上に三角形が表示され、変更前と変更後の影響を比較することができます。

色分けされた線は、3DS ルール、許可ルール、ブロックルール、および審査ルールと一致した支払いの件数を追跡します。これらのグラフの描線上の三角形の記号は、対応するタイプのルールの更新を表しています。

独自ルールの有効性についての情報が提供され、各ルールが対処した支払いの数が示されます。ルールが適用された支払いのみを限定して表示し、ダウンロードすることもできます。この情報を評価することで、ルールに変更を加える必要があるか、完全に削除する必要があるかを判断できます。

その他のコマンドを表示するには、オーバーフローメニュー () をクリックします。その他のコマンドには、無効化、有効化、編集、削除があり、すべてのルールに対して使用できます。

Sigma や Data Pipeline といった Stripe のレポートプロダクトを使用して、個別の支払いに対するルール決定とルール属性を含む、不審請求の申請と不正利用のデータをクエリできます。

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

独自ルールの有効性についての情報を確認し、各ルールが対処した支払いの数を把握できます。ルールが適用された支払いのみを限定して表示し、ダウンロードすることもできます。以下の表にあるサンプルの質問を確認すると、ルールに変更を加える必要があるか、完全に削除する必要があるかを判断できます。

3DS リクエストのルール

3DS リクエストのルールについて表示される内容は、次のとおりです。

• リクエストされた 3DS: ルールが 3DS リクエストを起動した回数。

3DS ルールをクリックすると、以下の指標が表示されます。

許可ルール

許可ルールについて Radar for Teams のユーザーが表示できる内容は、次のとおりです。

• 許可された支払い: ルールによって許可された支払いの合計件数。
• 許可された支払いの総額: ルールによって許可された支払いに関連付けられている、現地通貨による合計金額。
• Risk score—The corresponding risk outcomes assigned by our AI models to the set of payments allowed by your rules.
• オーバーライドによる不審請求の申請: 許可された支払いで不審請求が申請された合計件数。
• オーバーライドによる不審請求の申請金額: 許可された支払いから生じた不審請求の申請に関連付けられている、現地通貨による合計金額。

許可ルールをクリックすると、以下の指標が表示されます。

ブロックルール

ブロックルールについて表示される内容は、次のとおりです。

• ブロックされた支払い: ルールによってブロックされた支払いの合計件数。
• ブロックされた支払いの金額: ルールによってブロックされた支払いに関連付けられている、現地通貨による合計金額。

Radar for Teams のユーザーは、以下も確認できます。

• Risk score—The corresponding risk outcomes assigned by Stripe’s 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 due to fraud and estimate which of those payments were successfully blocked by your rules.

ブロックルールをクリックすると、以下の指標が表示されます。

審査ルール

審査ルールについて Radar for Teams のユーザーが表示できる内容は、次のとおりです。

• 審査に送信された支払い: ルールによって手動審査に送信された支払いの合計件数。
• 承認された審査の金額: 審査で承認された支払いに関連付けられている、現地通貨による合計金額。
• 返金率: 返金された審査の比率。
• 承認済み審査からの不審請求の申請: 審査により承認されたが、最終的に不審請求の申請が行われた支払いの合計件数。
• 承認済み審査からの不審請求の申請金額: 承認された支払い審査から生じた不審請求の申請に関連付けられている、現地通貨による合計金額。

審査ルールをクリックすると、以下の指標が表示されます。

手動審査リストを定期的に監視する

審査リストが大きくなりすぎて管理できない場合は、適切なルールが設定されているかどうかを確認します。ほとんどの審査が不正使用として返金されている場合は、支払いをブロックする追加ルールを検討します。同様に、ほとんどの支払いが承認されている場合は、審査ルールの対象を絞ることを検討してください。

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

不審請求の申請は本質的に不正利用に関連しているため、不正利用削減への取り組みを強化すると、不審請求の申請率は低くなります。不審請求の申請が行われた支払いに類似する特徴があるかどうかを確認してください (場所の一致、金額の類似性など)。この調査は、審査中に返金された支払いを確認することでも実施できます。傾向を確認したら、適切なルールをテストして作成します。支払いが不正利用によるものであると判断できる場合は、返金を行い、不正利用として報告し、潜在的な不審請求の申請を回避します。

Sigma や Data Pipeline といった Stripe のレポートプロダクトを使用して、不審請求の申請と不正利用のデータをクエリできます。

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

不正使用率に影響を与える可能性があるビジネスへの大きな変化を予測する

主要な商品リリースやサービスの変更 (新しい高額商品や新しい国へのサービス拡大など) を計画している場合、開始当初はこれらの支払いを監視することをお勧めします。このような変更については、審査ルールを設定して、新しい支払いをすべて調べられるようにすることをお勧めします。これらの支払いをしばらく審査してパターンを識別することが、ビジネスを不正利用から保護する新しいルールの設定に役立ちます。

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

デフォルトでは、Radar ルールはほとんどのユーザーのカード、ACH、SEPA ダイレクトデビットの決済をスクリーニングします。すべての Stripe Radar ユーザーに対して、これらすべての決済手段で高リスクのブロックルールをサポートしています。Radar for Fraud Teams または Radar for Platforms のユーザー向けには、 :payment_method_type: 属性を使用して、特定の決済手段にのみ適用されるルールを記述するカスタムルールもサポートしています。 Block if :payment_method_type: = 'us_bank_account' などです。詳しくは、サポートされている属性をご覧ください。

アカウントルールの構築

Radar for Platforms では、ダッシュボードの Radar ページにあるルールタブからアカウントルールを追加・管理することもできます。新しいルールを追加するには、次の手順を実行します。

1. + ルールを追加をクリックします。
2. 次のルールタイプのいずれかを選択します:「レビュー」または「入金の一時停止」(レビュー、入金の一時停止が発生します)。
3. ルールエディターで、構文 {action} if {attribute} {operator} {value} を使用してルールを構築します。各項目は以下のとおりです。
   • {action}: ルール基準が満たされた場合の Radar の対応。この値は、選択したルールタイプに基づいて事前入力されています。
   • {attribute}:金額やカードタイプなど、評価する取引の要素。: で入力を開始すると、有効な属性のリストが開きます。
   • {operator}: 属性を値と比較する方法 (=、>、!= など)。
   • {value}: 評価する属性の値。
4. ルールをテストするをクリックします。
5. 必要に応じて、検出された検証エラーを修正します。
6. 新しいルールの確認ページで、現在このルールに一致するアカウントを表示し、有効にするかどうかを確認します。
7. ルールを有効にするをクリックして、既存のアカウントと今後のすべてのアカウントにこのルールを適用するようにします。

アカウントルールのテストは取引のテストよりも時間がかかりますが、意図しないアカウントをレビュー対象にしたり、自動入金を一時停止したりしないように、一度テストしておくことをおすすめします。まず、レビュー対象アカウントの作成の動作をテストします。次に、ルールが想定どおりにアカウントに影響を与えることを確認したら、自動入金の一時停止をテストします。