不正対策ルール
不正対策ルールを使用してビジネスを保護します。
不正対策ルールを使用すると、支払いが特定の基準に一致するたびにアクションを実行できます。
Stripe Radar には、すべての Stripe ユーザーに対する不正利用のリスクを検出して監視するための構築済みのルールが用意されています。
Radar for Teams のユーザーは、ダッシュボードを使用して、ビジネスに固有のビジネスロジックに基づき、カスタムのルールを作成できます。たとえば、以下を行うことができます。
- 新規顧客が行い、3D セキュア (3DS) に対応しているすべての支払いに対して、3D セキュアをリクエストする
- コールセンターの IP アドレスからのすべての支払いを 許可する
- 国外から、または国外で発行されたカードによる支払いを ブロックする
- プリペイドカードで行われた 1,000 USD を超えるすべての支払いを 審査する
注意
EU の加盟店は、Geo-blocking Regulation と、それにより EU 加盟国を拠点とする顧客からの支払いをブロックできないことの影響を受ける可能性があります。
構築済みのルール
以下のルールは、すべての Radar ユーザーに対してデフォルトで有効になっています。
機械学習によるリスクチェック
Stripe Radar と Stripe Radar for Teams は、次に示す Stripe の機械学習モデルの判断に基づくデフォルトルールセットを提供します。
Block if :risk_level: = 'highest'
このルールは、不正使用のリスクが高い支払いをブロックし、処理しません。Radar または Radar for Teams のユーザーの場合、このルールはデフォルトで有効になっています。
Review if :risk_level: = 'elevated'
Stripe Radar for Teams のデフォルトの動作では、不正使用のリスクが比較的高いと疑われる支払いが審査対象になります。
従来のカードチェック
セキュリティコードや住所 (AVS) のチェックで不合格とされた場合でも、支払いが成功することがあります。これは、カード発行会社が支払いを承認するか拒否するかを決定するときに多くのシグナルを考慮するためです。また、セキュリティコードまたは郵便番号の検証チェックで不合格とされた場合でも、カード発行会社が正当と見なせば、支払いを承認することがあります。
Stripe には構築済みのルールがあるため、カード発行会社によって承認された支払いもブロックできます。これらのルールは、Stripe ダッシュボードで有効または無効にできます。
これらのルールは、顧客にカードを関連付けるときに実施されるカード検証プロセスにも適用されます。カードと顧客を一緒に作成する場合、セキュリティーコードまたは郵便番号の検証に失敗すると、顧客レコードを正常に作成できません。このルールは、デフォルトではアカウントで有効になっていないことがあります。ダッシュボードを使用して、いつでも有効または無効にできます。
Block if CVC verification fails
If this rule is enabled, Radar blocks payments that fail a card issuer’s CVC verification check. If the customer doesn’t provide the CVC number, for example because they use a wallet, or their card issuer doesn’t support its verification, the rule can’t block the payment.
Block if postal code verification fails
このルールが有効になっている場合、Radar はカード発行会社の郵便番号の検証に失敗した支払いをブロックします。顧客が郵便番号を提供しなかった場合、あるいは顧客のカード発行会社がこの検証に対応していない場合は、このルールでは支払いをブロックできません。このルールは、アカウントのデフォルトでは有効になっていない場合があります。ダッシュボードを使用して、いつでも有効と無効を切り替えることができます。
3D セキュアをリクエストするための構築済みのルール
3DS を使用すると、顧客は購入フローを完了する前に、追加の認証ステップを完了するように求められます。支払いが 3DS によって認証されている場合、その支払いで発生する不正利用に関する申請の責任は通常、売り手からカード発行会社に移ります。このため、ほとんどの場合、売り手は 3DS 認証済み支払いの不正利用による費用の責任を負いません。
Stripe は、カード発行会社によって 3DS が要求されていることを示す再試行可能な支払い拒否コードを自動的に処理します。PSD2 によって義務付けられている強力な顧客認証 (SCA) などの規制に準拠するため、必要に応じて 3DS の起動も行います。Radar を無効にしても、3DS が必要な場合に起動されないことはありません。
Stripe は、デフォルトで無効になっている 3 つのルールを提供しており、Radar を Payment Intents または Setup Intents で使用する場合、これらのルールを有効にして 3DS を動的にリクエストすることができます。
Request 3D Secure if 3D Secure is required for card- デフォルトでは無効です。このルールを有効にすると、以前にカードに 3DS が必要であった場合は、3DS 認証を求めるメッセージが顧客に表示されます。
- Stripe は、カード発行会社によって 3DS が要求されていることを示す再試行可能な支払い拒否コードを自動的に処理します。さらに、PSD2 によって義務付けられている強力な顧客認証 (SCA) などの規制に準拠するため、必要に応じて 3DS の起動も行います。
Request 3D Secure if 3D Secure is supported for card- デフォルトでは無効になっていますが、前述のルールと同様です。このルールを有効にすると、カードが 3DS に対応している限り、3DS 認証を顧客に求めます。
- ライアビリティシフト対象の支払いの数を最大限に増やしたい場合は、前述のルールの代わりにこのルールを使用します。この要件の追加により、購入完了率が低下する可能性があることに注意してください。
Request 3D Secure if 3D Secure is recommended for card- デフォルトでは無効になっています。このルールを有効にすると、購入完了率への影響を最小限に抑えながら 3DS 認証を実行できると Stripe が確信する場合に、3DS 認証を顧客に求めます。
- ライアビリティシフト対象の支払いの数を最大限に増やしたい場合は、これを有効にします。
3DS では、顧客が追加の認証レイヤーを実行する必要があるため、無差別に 3DS を使用すると購入完了率が低下する可能性があります。サポート対象カードからのすべての支払いを 3DS を使用して送信する場合にのみ、デフォルトの 3DS ルールを有効にすることをお勧めします。
3DS をリクエストしても、必ずしもカード発行会社が実際に 3DS を実行するとは限りません。考えられる結果について詳しくは、3D セキュアのドキュメントをご覧ください。
3D セキュアをリクエストして特定の結果に対応するためのカスタムルール
Radar for Teams を利用している場合は、3DS 認証を試行した後に、許可ルール、ブロックルール、または審査ルールで結果を評価できます。
カスタム 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 をリクエストします。
| Radar ルール | 説明 |
|---|---|
Request 3D Secure if :risk_level: != | このルールは、Radar のリスクレベルを確認し、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに対して 3DS をリクエストします。 |
この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、支払いのオーソリを続行しません。
Radar リスクレベルに基づいて常に 3D セキュアをリクエストする
Radar を使用して、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに 3DS をリクエストします。クレジットカードで 3DS がサポートされない場合は受け付けません。
| Radar ルール | 説明 |
|---|---|
Request 3D Secure if :risk_level: != | このルールは、Radar のリスクレベルを確認し、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに対して 3DS をリクエストします。 |
Block if not :is_3d_secure: and :risk_level: != | このルールは、リスクレベルが比較的高いか高リスクで、一定金額を超える支払いについて、3DS フローのない支払いをブロックします。ただし、SCA 免除が適用される可能性があるか、attempt_ のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) とウォレット (Apple Pay や Google Pay など) は受け付けます。 |
3D セキュアがサポートされている場合に 3D セキュアで認証された取引のみを受け付ける
Stripe を利用して、強力な顧客認証 (SCA) など、必要な場合に 3DS を起動しますが、処理エラーのようなエッジケースは受け付けません。
| 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:: = | このルールは、メタデータ条件を確認して 3DS をリクエストします。Customer メタデータを確認するには、::foo:: = 'bar' を ::customer:trusted:: = 'false' などの値に置き換えます。 |
この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、支払いのオーソリを続行しません。
メタデータに基づいて常に 3D セキュアを要求する
Radar を使用して、カスタムメタデータ属性を持つすべての支払いに 3DS をリクエストし、3DS をサポートしないクレジットカードをブロックします。
| Radar ルール | 説明 |
|---|---|
Request 3D Secure if ::foo:: = | このルールは、メタデータ条件を確認して 3DS をリクエストします。Customer メタデータを確認するには、::foo:: = 'bar' を ::customer:trusted:: = 'false' などの値に置き換えます。 |
Block if ::foo:: = | このルールは、カスタムのメタデータ属性を使用する支払いについて、3D セキュアフローのない支払いをブロックします。ただし、SCA 免除が適用される可能性があるか、attempt_ のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は受け付けます。 |
すべての新しいクレジットカードに 3D セキュアをリクエストし、3D セキュアがサポートされていなかった場合に審査する
Radar を使用してすべての新しいクレジットカードに 3DS をリクエストし、3DS がサポートされないクレジットカードの支払いは手動で審査します。
| Radar ルール | 説明 |
|---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | このルールは、このアカウントで以前に使用されたことのないすべてのクレジットカードに 3DS をリクエストします。ユーザーの負担を軽減するには、:risk_level: != の場合にのみ 3DS をリクエストするという条件を追加できます。 |
Request 3D Secure if :is_new_card_on_customer: | 上記のルールの代替手段として、このルールは、Customer (顧客) が新たに使用したすべてのカードに 3DS をリクエストします。ユーザーの負担を軽減するには、:risk_level: != の場合にのみ 3DS をリクエストするという条件を追加できます。 |
Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | このルールは、3DS を想定していたものの 3DS がサポートされていなかった支払いに、手動審査のマークを付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は無視します。審査のマークが付けられた支払いは引き続き認証が行われ、結果として、カード発行会社によるセキュリティコードの確認などの追加シグナルを提供することができます。 |
この場合、ブロックルールがないと、3DS をサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3DS は、支払いのオーソリを続行しません。
特定の国のカード発行会社の場合は常に 3D セキュアを要求する
Radar を使用して、カスタムリストにある国のカード発行会社からのすべての支払いに 3DS をリクエストし、3DS をサポートしないクレジットカードをブロックします。
| Radar ルール | 説明 |
|---|---|
Request 3D Secure if :card_country: in @enforce_3ds_list | このルールは、各国のカード発行会社に基づく条件を確認してカスタムリストと比較し、一致する場合は 3DS をリクエストします。 |
Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | このルールは、カスタムリストの国から発生する支払いについて、3D セキュアフローのない支払いをブロックします。ただし、SCA 免除が適用される可能性があるか、attempt_ のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は受け付けます。 |
Radar リスクレベルに基づいて常に 3D セキュアを要求し、エッジケースは審査する
Radar を使用して、Radar リスクレベルに基づいてすべての支払いに 3DS をリクエストし、3DS をサポートしないクレジットカードはブロックしますが、手動でエッジケースを審査します。
| Radar ルール | 説明 |
|---|---|
Request 3D Secure if :risk_level: != | このルールは、Radar のリスクレベルを確認し、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに対して 3DS をリクエストします。 |
Block if not :is_3d_secure: and :risk_level: != | このルールは、リスクレベルが比較的高いか高リスクで、一定金額を超える支払いについて、3DS フローのない支払いをブロックします。ただし、正当な取引で、SCA 免除が適用されている可能性のあるものは受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) とウォレット (Apple Pay や Google Pay など) は受け付けます。 |
Review if not :is_3d_secure_authenticated: and :risk_level: != | このルールは、3DS を使用していたものの認証フローを最後まで完了しなかった支払いに手動審査のマークを付けます。これにより、attempt_ などのエッジケースが審査対象となり、SCA 免除ではあるが正当な支払いにもマークが付けられます。審査ルールはブロックルールの後に評価されるため、3DS をサポートしていないクレジットカードはブロックされます。 |
ルールを作成する状況
Stripe のデフォルトルールでは、かなりの数の不正利用による支払いをブロックできます。どの支払いを審査、許可、またはブロックするかをより詳細に制御する必要があるビジネスは、Radar for Teams を使用してカスタムのルールを作成できます。
カスタムルールを有効にするかどうかを決定する際は、以下を検討してください。
- リスクが高いと思われる特定の特徴やユーザーの行動 (使い捨てのメールアドレスの使用など) があるかどうか。
- 支払い金額や認識されるリスクレベルに基づくルール の導入を希望するかどうか (支払いが 500 USD を超えている場合に自動的に審査対象とし、支払いが 5 USD 未満の場合に自動的に許可するなど)。
- 既存の不審請求が申請された支払いと返金された支払いに、共通のパターン (金額、カードの種類、または国の類似など) があるかどうか。
- Stripe に移行したい既存のルールがあるかどうか。それらのルールの多くは Stripe の機械学習モデルですでにカバーされている可能性があります。カスタマイズする前に、Stripe のシステムがお客様のビジネスでどのように機能するかを確認することができます。
効果的なルールの作成方法
ルールは既存のワークフローの自動化に役立ちますが、誤って使用するとビジネスに悪影響を与える可能性もあります。たとえば、ルールが適切に設定されていないと、ルールが不正使用による大量の支払いを自動的に許可したり、多くの正当な支払いをブロックしたりすることもあります。
ルールを設定する際は、次の点に注意してください。
- ルールは今後の支払いにのみ適用され、すでに処理されたものには適用されません
- 3DS のリクエストに関するルールは、Stripe Checkout、Payment Intents、または Setup Intents を使用するときにのみ適用され、審査、ブロック、および許可のルールの前に評価されます。
- 基準を満たすすべての支払いをブロックするブロックルールを導入する前に、その支払いを最初に審査するかどうかを検討します。
- 許可ルールは、同じ基準に一致する他のカスタムルールと共に、Stripe のデフォルトルールを上書きするため、最小限に実装します。
- アカウントごとに、すべてのルールタイプを合計して最大 200 個のルールを作成できます
ルールを構築する
ダッシュボードの Radar ページのルールタブから、ルールを追加して、管理することができます。
新しいルールを追加するには、以下のようにします。
- + ルールを追加をクリックします。
- サブメニューからタイプルールのタイプを選択します。
- ルールエディターで、構文
{action} if {attribute} {operator} {value}を使用してルールを構築します。各項目は以下のとおりです。{action}: ルール基準が満たされた場合の Radar の対応。この値は、選択したルールタイプに基づいて事前入力されています。{attribute}: 評価する取引の要素 (金額やカードタイプなど)。最初に:を入力して、有効な属性のリストを開きます。また、カスタムのメタデータを 2 重のコロンで囲み (たとえば、::product_)、評価することもできます。sku:: {operator}: 属性を値と比較する方法 (=、>、!=など)。{value}: 評価する属性の値。
- ルールをテストするをクリックします。
- 必要に応じて、検出された検証エラーを修正します。
- 新しいルールの審査ページで、このルールが最近の取引に対してどのように機能するかを検討し、ルールを有効にするかどうかを確認します。
- 今後のすべての取引にこのルールを適用するには、ルールを追加をクリックします。
Radar アシスタントを使用する
Stripe のルールエディターには、LLM アシスタントが内蔵されており、自然言語プロンプトから Radar ルールを作成できます。
Radar アシスタントを使用するには、以下のようにします。
- ダッシュボードの Radar ページのルールタブで、+ ルールを追加をクリックします。
- サブメニューからルールタイプを選択します。
- ルールエディターで Radar アシスタントをクリックします。
ルールを自分で記述
Radarアシスタント
- メッセージフィールドに、ルールのリクエストを入力します。以下のようなリクエストが可能です。
- 「カードと IP の国が異なる場合の支払いを確認します。」
- 「$1000 を超えるディスカバーカードによる支払いをブロックします。」
- 「stripe.com のメールアドレスからの支払いを許可します。」
- アシスタントから提案が返されたら、追加のコマンドを入力してルールを調整するか、ルールをテストするをクリックして最近の取引履歴に対してルールがどのように機能するかを確認します。
- ルールに問題がない場合は、ルールを追加をクリックして、今後のすべての取引で有効にします。
トレーニングデータへの同意: Radar Assistant を使用することで、お客様のチャットへの入力を Stripe が記録し、Radar Assistant の機能のトレーニングと改善のために Stripe が利用することに同意したとみなされます。このような目的でのチャットへの入力の使用を望まない場合は、ルールを手動で作成してください。
Stripe AI サービス の詳細をご覧ください。
審査ルール
審査ルールの基準を満たす支払いは、Stripe で通常どおり処理されますが、チームが詳細を確認できるように審査リストに配置されます。ルールの条件が広すぎると、審査リストに入れられる支払いが多くなりすぎ、顧客の体験が遅延し、審査チームに負担がかかる可能性があります。
Stripe のルールのテストインターフェイスは、過去 6 カ月の支払いに対してシミュレーションを実行し、そのルールによる影響が及ぶと考えられる正当な支払い、不正利用による支払い、ブロックされた支払いの数を判定します。ルールをテストし、過去 6 カ月の履歴を調べる際には、確認の必要な事項があります。
- 支払いの全体量が少ない。このような支払いの審査は、チームに負担がかかりません。
- 審査担当者が価値を向上している。審査担当者は、一般に自動化されたシステムよりも確実に支払いが不正使用であったかどうかを判断できます。
- ルールを適用した結果、成功した支払い、返金または不審請求が申請された支払いが混在している。これらのタイプの支払いをさらに調査することで、不正利用による支払いから正当な支払いを切り離すことができます。
以下の例は、プリペイドクレジットカードの審査を必要とするビジネスが作成する審査ルールの改善方法を示しています。
| 元のルール | 改善されたルール |
|---|---|
Review if :card_funding: = | Review if :is_disposable_email: and :card_funding: = |
| 条件が広すぎるため、審査の対象が多くなります | 条件が絞られ、審査件数が少なくなります |
ブロックルール
ブロックルールを使用して、不正利用である確率が高いとみられる支払いや、ビジネスで適用している制限 (プリペイドカードからの支払いのブロックなど) に該当する支払いをブロックできます。ブロックルールの適用方法に確信が持てない場合は、審査ルールを使用して支払いを審査することをお勧めします。これらの支払いについて偽陽性の可能性がないかどうかをしばらく審査することで、ブロックルールに移行するかどうかを確信を持って判断できるようになります。
すでにブロックされている支払いは影響を受けないため、ブロックルールは不正利用で成功した支払いのみに影響します。ルールをテストする際には、次を確認する必要があります。
- できるだけ誤判定を少なくする。Stripe はテスト中に、ルールに一致したであろう、成功した支払いの数と不審請求が申請された支払いの数を表示します。適切なブロックルールでは、正当な支払いよりはるかに多くの不正使用による支払いがブロックされます。
- 不要なルールを最小限に抑える。ルールが非常にうまく機能しているように見えても、既存のルールですでにカバーされている場合、新しいルールは必要ないことがあります。同様に、テスト中に結果が混在しているように見える場合は、代わりに審査ルールを設定して、そうしたタイプの支払いに関してより多くの情報を収集できるようにすることを検討してください。
以下は、アメリカ国外からの支払いでの不正使用のレベルが高いビジネスが作成したブロックルールの改善方法の例です。
| 元のルール | 改善されたルール |
|---|---|
Block if :card_country: != | Block if :card_country: != |
| 条件が広すぎるため、多くの件数の正当な支払いがブロックされます | 条件が絞られ、審査件数が少なくなります |
許可ルール
許可ルールは他のすべてのルールを上書きするため、注意して使用する必要があります。ビジネスの多くは、許可ルールを導入する必要はありません。許可ルールが少数の不正利用による支払いを見逃す可能性があるという懸念がある場合は、導入前に、これらのルールをさらに制限する調整を検討する必要があります。
ルールが作成されると、許可ルールは即座にすべての新しい支払いに適用されます。これには、以前ブロックされた支払いに類似したものが含まれます。ルールをテストする際は、次を確認する必要があります。
- 以前にブロックされた支払いのうち許可されることになる数を調べます。許可ルールは、他のすべてのルールと Stripe のリスク評価を上書きします。新しい許可ルールをテストすると、このルールが有効であれば許可されたと考えられるすべての支払いが表示されます。これには、ブロックまたは不審請求の申請が行われた支払いが含まれ、今後の不審請求の申請率に影響を与える可能性があります。
- リスクの高い支払いのブロックは続行します。これを行うには、許可ルールに次を追加します。
and :risk_level: !='highest' - ビジネスでの正当な取引履歴を評価します。各自の顧客間の関係を分析することで、正当な購入の履歴に基づき、より多くの取引を許可することができます。この結果、ビジネスで実証済みの履歴がある顧客からの支払いのブロックを減らすことが可能になります。これを行うには、属性リストを確認し、「customer (顧客)」という文字を含む属性を探します。
以下の例は、通常 (常にではありませんが) 、イギリスの顧客から問題のない支払いを受けているビジネスでの、許可ルールの改善方法を示しています。
| 元のルール | 改善されたルール |
|---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
| 条件が緩すぎる場合: 一部の不正な支払いが許可されます | 条件がより厳しい場合: 許可される不正支払いが少なくなります |
ルールの管理
ビジネスが成長し続けるためには、望ましい顧客のタイプをルールで確実に反映し続けることが重要です。以下は、ビジネスの状況に合わせてルールを適切な状態に保ち、機能させ続けるためのベストプラクティスです。
ルールを定期的にモニタリングして、有効性が持続していることを確認する
ルールの指標
不正使用のパターンは常に変化するため、ルールのパフォーマンスを示す指標を提供しています。ルールのタイプによって実行されるアクションが異なるため、指標はルールのタイプによって異なります。
ルールのパフォーマンスチャートを使用して、Radar ルールの機能状況を把握します。ルールに一致する支払い件数の想定外の急増や減少 (許可ルールで許可される支払いが多すぎる、ブロックルールによるブロック件数が多すぎるなど) がないかを確認します。急増は、ビジネスで受け取る支払いの種類が変化したことを示す場合も、ルール自体の更新が必要になっていることを示す場合もあります。ルールを更新すると、グラフ上に三角形が表示され、変更前と変更後の影響を比較することができます。
色分けされた線は、3DS ルール、許可ルール、ブロックルール、および審査ルールと一致した支払いの件数を追跡します。これらのグラフの描線上の三角形の記号は、対応するタイプのルールの更新を表しています。
独自ルールの有効性についての情報が提供され、各ルールが対処した支払いの数が示されます。ルールが適用された支払いのみを限定して表示し、ダウンロードすることもできます。この情報を評価することで、ルールに変更を加える必要があるか、完全に削除する必要があるかを判断できます。
その他のコマンドを表示するには、オーバーフローメニュー () をクリックします。その他のコマンドには、無効化、有効化、編集、削除があり、すべてのルールに対して使用できます。
Sigma や Data Pipeline といった Stripe のレポートプロダクトを使用して、個別の支払いに対するルール決定とルール属性を含む、不審請求の申請と不正利用のデータをクエリできます。
ルールの有効性を評価する
独自ルールの有効性についての情報を確認し、各ルールが対処した支払いの数を把握できます。ルールが適用された支払いのみを限定して表示し、ダウンロードすることもできます。以下の表にあるサンプルの質問を確認すると、ルールに変更を加える必要があるか、完全に削除する必要があるかを判断できます。
| ルールのタイプ | 評価 | 検討すべきアクション |
|---|---|---|
| 一般 | このルールが支払いにまったく一致しなくなっている場合 | ルールを削除します。 |
| このルールに異常な動作 (たとえば、以前の期間より多くの支払いを許可するなど) がある場合。 | このルールに一致した支払いを手動で確認し、この処理が適切かどうかを判断します。 | |
| 3DS | 3DS の完了率は高いが、不審請求の申請件数または EFW の件数は低い場合。 | 正当なユーザーに負担が生じている可能性があるため、ルールを削除します。 |
| 3DS に成功する取引で不正利用の件数が多い場合。 | 3DS ルールをブロックルールに変更し、このようなユーザーが負担の少ないフロー (カード発行会社が管理するフロー) を通過したり、ファーストパーティーによる不正使用を行ったりするのを防ぐことを検討します。 | |
| 3DS の購入完了率が低い場合。 | これは、不正利用者の大半をブロックしている可能性があるため、良いルールである可能性があります。ただし、一致した支払いを手動で調査して、正当なユーザーの負担が増して離脱していないかどうかを確認することを検討してください。 | |
| 許可 | 不審請求の申請、EFW、返金、または失敗した支払いの件数が多い場合。 | 不当な支払いを見逃すルールを削除します。 |
| ブロック | ブロック件数は減っているのに、不正使用の件数は変わらなかったり増加していたりしますか？ | ルールが有効でない可能性があるため、変更します。 |
| ブロック件数は増えているのに、不正利用の件数は変わらなかったり増加していたりする場合。 | 正当なユーザーをブロックしている可能性があるため、ルールを変更します。 | |
| ブロック件数は増えていて、不正利用の件数は減っている場合。 | これはルールが有効であることを示しています。ただし、正規のユーザーをブロックしすぎていないか確認するために、いくつかのトランザクションを手動で審査することを検討してください。 | |
| 手動審査 | 審査を通過した支払いの割合が低い場合。 | ルールが広すぎる可能性があるため、ルールの制限をより厳しくします。 |
| 成功した支払いまたは承認された支払いの件数が多いかどうか。 | 手動審査ルールを完全に削除するか、そうした支払いを対象とする許可ルールを作成します。 | |
| 返金または不審請求の申請および不正利用の早期警告の件数は多いかどうか。 | ブロックルールに変換します。 |
3DS リクエストのルール
3DS リクエストのルールについて表示される内容は、次のとおりです。
- リクエストされた 3DS: ルールが 3DS リクエストを起動した回数。
3DS ルールをクリックすると、以下の指標が表示されます。
許可ルール
許可ルールについて Radar for Teams のユーザーが表示できる内容は、次のとおりです。
- 許可された支払い: ルールによって許可された支払いの合計件数。
- 許可された支払いの総額: ルールによって許可された支払いに関連付けられている、現地通貨による合計金額。
- リスクスコア: ルールによって許可された支払いのセットに対して、Stripe の機械学習モデルが割り当てた対応するリスク評価の結果。
- オーバーライドによる不審請求の申請: 許可された支払いで不審請求が申請された合計件数。
- オーバーライドによる不審請求の申請金額: 許可された支払いから生じた不審請求の申請に関連付けられている、現地通貨による合計金額。
許可ルールをクリックすると、以下の指標が表示されます。
ブロックルール
ブロックルールについて表示される内容は、次のとおりです。
- ブロックされた支払い: ルールによってブロックされた支払いの合計件数。
- ブロックされた支払いの金額: ルールによってブロックされた支払いに関連付けられている、現地通貨による合計金額。
Radar for Teams のユーザーは、以下も確認できます。
- リスクスコア: ルールによって許可された支払いのセットに対して、Stripe の機械学習モデルが割り当てた対応するリスク評価の結果。
- 推定偽陽性率: セットとしてのブロックルールと、個々のルールの両方によってブロックされた、不正利用ではない支払いの推定率 (この推定は、対応する機械学習リスクスコアで推定される偽陽性率を使用して行われます。リスクスコアは、Stripe ネットワーク全体で実行される実験によって算出されます)。
- 防止された不正な支払いの予想件数: ブロックルールによって回避された不正利用による支払いの推定件数。Stripe は、Stripe ネットワーク全体の数百万件もの取引を分析して計算した、機械学習のリスクスコアを使用して、不正利用により不審請求が申請されたり拒否された可能性が高い支払いを予測し、それらのうちどの支払いがルールによって正常にブロックされたかを推定します。
ブロックルールをクリックすると、以下の指標が表示されます。
審査ルール
審査ルールについて Radar for Teams のユーザーが表示できる内容は、次のとおりです。
- 審査に送信された支払い: ルールによって手動審査に送信された支払いの合計件数。
- 承認された審査の金額: 審査で承認された支払いに関連付けられている、現地通貨による合計金額。
- 返金率: 返金された審査の比率。
- 承認済み審査からの不審請求の申請: 審査により承認されたが、最終的に不審請求の申請が行われた支払いの合計件数。
- 承認済み審査からの不審請求の申請金額: 承認された支払い審査から生じた不審請求の申請に関連付けられている、現地通貨による合計金額。
審査ルールをクリックすると、以下の指標が表示されます。
手動審査リストを定期的に監視する
審査リストが大きくなりすぎて管理できない場合は、適切なルールが設定されているかどうかを確認します。ほとんどの審査が不正使用として返金されている場合は、支払いをブロックする追加ルールを検討します。同様に、ほとんどの支払いが承認されている場合は、審査ルールの対象を絞ることを検討してください。
不審請求が申請された支払いと返金された支払いを分析する
不審請求の申請は本質的に不正利用に関連しているため、不正利用削減への取り組みを強化すると、不審請求の申請率は低くなります。不審請求の申請が行われた支払いに類似する特徴があるかどうかを確認してください (場所の一致、金額の類似性など)。この調査は、審査中に返金された支払いを確認することでも実施できます。傾向を確認したら、適切なルールをテストして作成します。支払いが不正利用によるものであると判断できる場合は、返金を行い、不正利用として報告し、潜在的な不審請求の申請を回避します。
Sigma や Data Pipeline といった Stripe のレポートプロダクトを使用して、不審請求の申請と不正利用のデータをクエリできます。
ダッシュボードを使用して、または API を介して、受領したあらゆる不審請求の申請に対応できます。また、Stripe の不審請求の申請に関するドキュメントには、十分に反証を収集した事例を提示するための推奨事項がいくつか記載されています。
不正使用率に影響を与える可能性があるビジネスへの大きな変化を予測する
主要な商品リリースやサービスの変更 (新しい高額商品や新しい国へのサービス拡大など) を計画している場合、開始当初はこれらの支払いを監視することをお勧めします。このような変更については、審査ルールを設定して、新しい支払いをすべて調べられるようにすることをお勧めします。これらの支払いをしばらく審査してパターンを識別することが、ビジネスを不正利用から保護する新しいルールの設定に役立ちます。