ルール
Fraud prevention rules allow you to take action whenever a payment matches certain criteria.
Stripe Radar provides built-in rules to help detect and guard against fraud risk for all Stripe users.
Radar for Fraud Teams users can use the Dashboard to create custom rules based on the unique business logic specific to your business. For example, you can:
- 新規顧客が行い、3D セキュアに対応しているすべての支払いに対して、3D セキュアをリクエストする
- コールセンターの IP アドレスからのすべての支払いを 許可する
- 国外から、または国外で発行されたカードによる支払いを ブロックする
- プリペイドカードで行われた 1,000 USD を超えるすべての支払いを レビューする
注意
EU merchants might be affected by the Geo-blocking Regulation and its prohibitions on blocking payments from customers based in EU member states.
構築済みのルール
The following rules are enabled by default for all Radar users.
機械学習によるリスクチェック
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 ダッシュボードで有効または無効にできます。
これらのルールは、顧客にカードを関連付けるときに実施されるカード検証プロセスにも適用されます。カードと顧客を一緒に作成する場合、セキュリティーコードまたは郵便番号の検証に失敗すると、顧客レコードを正常に作成できません。このルールは、デフォルトではアカウントで有効になっていないことがあります。Stripe ダッシュボードを使用して、いつでも有効または無効にできます。
Block if CVC verification fails
Stripe は、カード発行会社によるセキュリティコードの検証チェックに失敗した支払いをブロックします。顧客がウォレットを使用することからセキュリティーコード番号を提供しない場合、または顧客のカード発行会社がこの検証をサポートしていない場合は、このルールで支払いをブロックすることはできません。
Block if postal code verification fails
Stripe は、カード発行会社の郵便番号の検証に失敗した支払いをブロックします。顧客が郵便番号を提供しなかった場合、あるいは顧客のカード発行会社がこの検証に対応していない場合は、このルールでは支払いをブロックできません。このルールは、アカウントのデフォルトでは有効になっていない場合があります。Stripe ダッシュボードを使用して、いつでも有効と無効を切り替えることができます。
3D セキュアをリクエストするための構築済みのルール
Using 3D Secure prompts customers to complete an additional authentication step before they can complete the purchase flow. If 3D Secure authenticates a payment, the liability for any fraud-related disputes for that payment typically shift from the seller to the issuer. This means that in most cases, the seller isn’t responsible for fraud costs on 3D Secure authenticated payments.
Stripe automatically handles soft decline codes indicating that 3DS is required by issuers. We also trigger 3DS when necessary, adhering to regulations like the Strong Customer Authentication (SCA) mandated by the PSD2. Disabling Radar doesn’t prevent 3D Secure from being triggered in cases where it’s necessary.
Stripe provides three default disabled rules you can enable to dynamically request 3DS when using Radar with Payment Intents or Setup Intents:
Request 3D Secure if 3D Secure is required for card
- デフォルトでは無効です。このルールを有効にすると、以前にカードに 3D セキュアが必要であった場合は、3D セキュア認証を求めるメッセージが顧客に表示されます。
- Stripe は、カード発行会社によって 3DS が要求されていることを示す再試行可能な支払い拒否コードを自動的に処理します。さらに、PSD2 によって義務付けられている強力な顧客認証 (SCA) などの規制に準拠するため、必要に応じて 3DS の起動も行います。
Request 3D Secure if 3D Secure is supported for card
- デフォルトでは無効になっていますが、前述のルールと同様です。このルールを有効にすると、カードが 3D セキュアに対応している限り、3D セキュア認証を顧客に求めます。
- ライアビリティシフト対象の支払いの数を最大限に増やしたい場合は、前述のルールの代わりにこのルールを使用します。この要件の追加により、コンバージョン率が低下する可能性があることに注意してください。
Request 3D Secure if 3D Secure is recommended for card
- デフォルトでは無効になっています。このルールを有効にすると、コンバージョン率への影響を最小限に抑えながら 3D セキュア認証を実行できると Stripe が確信する場合に、3D セキュア認証を顧客に求めます。
- ライアビリティシフト対象の支払いの数を最大限に増やしたい場合は、これを有効にします。
3D セキュアでは、顧客が追加の認証レイヤーを実行する必要があるため、無差別に 3D セキュアを使用すると購入完了率が低下する可能性があります。サポート対象カードからのすべての支払いを 3D セキュアを使用して送信する場合にのみ、デフォルトの 3D セキュアルールを有効にすることをお勧めします。
3D セキュアをリクエストしても、必ずしもカード発行会社が実際に 3D セキュアを実行するとは限りません。考えられる結果について詳しくは、3D セキュアのドキュメントをご覧ください。
3D セキュアをリクエストして特定の結果に対応するためのカスタムルール
Radar for Teams を利用している場合は、3D セキュア認証を試行した後に、許可ルール、ブロックルール、またはレビュールールで結果を評価できます。
カスタム Radar ルールで最も重要な属性は次のとおりです。
is_3d_secure
: カードがサポートされていて、カード発行会社による 3D セキュアの試行でユーザーが認証に失敗しなかった場合に true になります。通常はこれをブロックルールで使用することをお勧めします。is_3d_secure_authenticated
which is true if 3D Secure was attempted by the issuer and the user successfully went through 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
which is true if Stripe expects the payment to be covered under the liability shift rule. This might not always be the same as 3D Secure, for example Apple Pay in certain regions.
For custom rules, we recommend keeping Request 3D Secure
and Block
rules aligned depending on your risk appetite. However, don’t block transactions where 3D Secure isn’t supported, such as some wallets.
これを実現する方法の例を、さまざまなユースケースでご紹介します。
Radar リスクレベルに基づいて 3D セキュアをリクエストする
Radar を使用して、Radar リスクレベルに基づいて一定金額を超えるすべての支払いに 3D セキュアをリクエストします。
Radar ルール | 説明 |
---|---|
Request 3D Secure if :risk_level: != | このルールは、Radar のリスクレベルを確認し、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに対して 3D セキュアをリクエストします。 |
この場合、ブロックルールがないと、3D セキュアをサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3D セキュアは、支払いのオーソリを続行しません。
Radar リスクレベルに基づいて常に 3D セキュアをリクエストする
You want to use Radar to request 3D Secure on all charges based on elevated or high risk Radar risk level and above a certain amount. If cards don’t support 3D Secure, you don’t want to accept them.
Radar ルール | 説明 |
---|---|
Request 3D Secure if :risk_level: != | このルールは、Radar のリスクレベルを確認し、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに対して 3D セキュアをリクエストします。 |
Block if not :is_3d_secure: and :risk_level: != | このルールは、リスクレベルが比較的高いか高リスクで、一定金額を超える支払いについて、3D セキュアフローのない支払いをブロックします。ただし、SCA 免除が適用される可能性があるか、attempt_acknowledged のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) とウォレット (Apple Pay や Google Pay など) は受け付けます。 |
3D セキュアがサポートされている場合に 3D セキュアで認証された取引のみを受け付ける
Stripe を利用して、強力な顧客認証 (SCA) など、必要な場合に 3D セキュアを起動しますが、処理エラーのようなエッジケースは受け付けません。
Radar ルール | 説明 |
---|---|
Block if :is_3d_secure: and not :is_3d_secure_authenticated: | このルールでは、カードが 3D セキュアに登録されていて、3D セキュアが試行されたもののユーザーが正常に認証されなかった場合に支払いをブロックします。3D セキュア、SCA の免除、オフセッションの支払い (継続的なサブスクリプションの支払いなど)、ウォレット (Apple Pay や Google Pay など) に対応していないカードの場合、支払いは受け付けられます。 |
メタデータに基づいて 3D セキュアをリクエストする
Radar を使用して、カスタムメタデータ属性を持つすべての支払いに 3D セキュアをリクエストします。
Radar ルール | 説明 |
---|---|
Request 3D Secure if ::foo:: = | このルールは、メタデータ条件を確認して 3D セキュアをリクエストします。Customer メタデータを確認するには、::foo:: = 'bar' を ::customer:trusted:: = 'false' などの値に置き換えます。 |
この場合、ブロックルールがないと、3D セキュアをサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3D セキュアは、支払いのオーソリを続行しません。
メタデータに基づいて常に 3D セキュアを要求する
Radar を使用して、カスタムメタデータ属性を持つすべての支払いに 3D セキュアをリクエストし、3D セキュアをサポートしないクレジットカードをブロックします。
Radar ルール | 説明 |
---|---|
Request 3D Secure if ::foo:: = | このルールは、メタデータ条件を確認して 3D セキュアをリクエストします。Customer メタデータを確認するには、::foo:: = 'bar' を ::customer:trusted:: = 'false' などの値に置き換えます。 |
Block if ::foo:: = | このルールは、カスタムのメタデータ属性を使用する支払いについて、3D セキュアフローのない支払いをブロックします。ただし、SCA 免除が適用される可能性があるか、attempt_acknowledged のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は受け付けます。 |
すべての新しいクレジットカードに 3D セキュアをリクエストし、3D セキュアがサポートされていなかった場合にレビューする
Radar を使用してすべての新しいクレジットカードに 3D セキュアをリクエストし、3D セキュアがサポートされないクレジットカードの支払いは手動でレビューします。
Radar ルール | 説明 |
---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | このルールは、このアカウントで以前に使用されたことのないすべてのクレジットカードに 3D セキュアをリクエストします。ユーザーの負担を軽減するには、:risk_level: != の場合にのみ 3D セキュアをリクエストするという条件を追加できます。 |
Request 3D Secure if :is_new_card_on_customer: | 上記のルールの代替手段として、このルールは、Customer (顧客) が新たに使用したすべてのカードに 3D セキュアをリクエストします。ユーザーの負担を軽減するには、:risk_level: != の場合にのみ 3D セキュアをリクエストするという条件を追加できます。 |
Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | This rule marks payments where 3D Secure 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. |
この場合、ブロックルールがないと、3D セキュアをサポートしないカードまたはウォレットはブロックされません。認証が失敗した 3D セキュアは、支払いのオーソリを続行しません。
特定の国のカード発行会社の場合は常に 3D セキュアを要求する
Radar を使用して、カスタムリストにある国のカード発行会社からのすべての支払いに 3D セキュアをリクエストし、3D セキュアをサポートしないクレジットカードをブロックします。
Radar ルール | 説明 |
---|---|
Request 3D Secure if :card_country: in @enforce_3ds_list | このルールは、各国のカード発行会社に基づく条件を確認してカスタムリストと比較し、一致する場合は 3D セキュアをリクエストします。 |
Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | このルールは、カスタムリストの国から発生する支払いについて、3D セキュアフローのない支払いをブロックします。ただし、SCA 免除が適用される可能性があるか、attempt_acknowledged のように認証の失敗または成功が明確ではない正当な取引は受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) やウォレット (Apple Pay や Google Pay など) は受け付けます。 |
Radar リスクレベルに基づいて常に 3D セキュアを要求し、エッジケースはレビューする
Radar を使用して、Radar リスクレベルに基づいてすべての支払いに 3D セキュアをリクエストし、3D セキュアをサポートしないクレジットカードはブロックしますが、手動でエッジケースをレビューします。
Radar ルール | 説明 |
---|---|
Request 3D Secure if :risk_level: != | このルールは、Radar のリスクレベルを確認し、リスクレベルが比較的高いか高リスクで、一定金額を超えるすべての支払いに対して 3D セキュアをリクエストします。 |
Block if not :is_3d_secure: and :risk_level: != | このルールは、リスクレベルが比較的高いか高リスクで、一定金額を超える支払いについて、3D セキュアフローのない支払いをブロックします。ただし、正当な取引で、SCA 免除が適用されている可能性のあるものは受け付けます。オフセッションの支払い (継続的なサブスクリプションの支払いなど) とウォレット (Apple Pay や Google Pay など) は受け付けます。 |
Review if not :is_3d_secure_authenticated: and :risk_level: != | このルールは、3D セキュアを使用していたものの認証フローを最後まで完了しなかった支払いに手動レビューのマークを付けます。これにより、attempt_acknowledged などのエッジケース がレビュー対象となり、SCA 免除ではあるが正当な支払いにもマークが付けられます。レビュールールはブロックルールの後に評価されるため、3D セキュアをサポートしていないクレジットカードはブロックされます。 |
When to create rules
Stripe’s 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.
Consider the following questions when deciding whether to enable custom rules:
- リスクが高いと思われる特定の特徴やユーザーの行動 (使い捨てのメールアドレスの使用など) はありますか?
- 支払い金額や認識されるリスクレベルに基づくルール の導入を希望しますか (支払いが 500 USD を超えている場合に自動的にレビュー対象とし、支払いが 5 USD 未満の場合に自動的に許可するなど)?
- 既存の不審請求が申請された支払いと返金された支払いには、共通のパターン (金額、カードの種類、または国の類似など) がありますか?
- Do you have existing rules you want to migrate to Stripe? Many of these rules might already be covered by Stripe’s machine learning models, and it’s worth seeing how our system performs for your business before customizing it.
効果的なルールの作成方法
ルールは既存のワークフローの自動化に役立ちますが、誤って使用するとビジネスに悪影響を与える可能性もあります。たとえば、ルールが適切に設定されていないと、ルールが不正使用による大量の支払いを自動的に許可したり、多くの正当な支払いをブロックしたりすることもあります。
ルールを設定する際に役立つヒントを以下に示します。
- ルールは今後の支払いにのみ適用され、すでに処理されたものには適用されません
- 3D セキュアのリクエストに関するルールは、Stripe Checkout、Payment Intents、または Setup Intents を使用するときにのみ適用され、レビュー、ブロック、および許可のルールの前に評価されます
- Before implementing any block rule to block all payments that meet its criteria, consider whether you’d rather review such payments first.
- Implement allow rules minimally, because they override Stripe’s default rules along with any other custom rules that match the same criteria.
- アカウントごとに、すべてのルールタイプを合計して最大 200 個のルールを作成できます
Construct rules
You can add and manage rules from the Rules tab of the Radar page in the Dashboard.
To add a new rule:
- Click + Add rule.
- Choose the type rule type from the sub-menu.
- In the rule editor, construct a rule using the syntax
{action} if {attribute} {operator} {value}
where:- {action}: How Radar responds when the rule criteria is met. This value is pre-populated based on the rule type selection you chose.
- {attribute}: The element of the transaction 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}: How to compare the attribute to the value, such as
=
,>
,!=
, and so on. - {value}: The value of the attribute to evaluate.
- Click Test rule.
- Correct any detected validation errors, if necessary.
- On the Review new rule page, review how this rule performs against your recent transactions to confirm whether you want to enable it.
- Click Add rule to begin applying this rule to all future transactions.
Use Radar Assistant
Stripe’s rule editor has a built-in LLM assistant that constructs a Radar rule from a natural language prompt.
To use Radar Assistant:
- From the Rules tab of the Radar page in the Dashboard, click + Add rule.
- Choose the type rule type from the sub-menu.
- In the rule editor, click Radar Assistant.
ルールを自分で記述
Radar Assistant
- In the message field, enter your rule request. You might ask to:
- Review payments where the card and IP countries are different.
- Block Discover card payments of more than $1000.
- Allow payments from stripe.com email addresses.
- 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.
- When you’re satisfied with the rule, click Add rule to enable it for all future transactions.
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.
Learn more about Stripe AI services.
レビュールール
レビュールールの基準を満たす支払いは、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 の機械学習モデルを含み、他のすべてのルールを上書きするため、注意して使用する必要があります。ビジネスの多くは、許可ルールを導入する必要はありません。許可ルールが少数の不正使用による支払いを見逃す可能性があるという懸念がある場合は、導入前に、これらのルールをさらに制限する調整を検討する必要があります。許可ルールは、Stripe の機械学習による判断を含む他すべてのルールを上書きするため、作成した許可ルールでは、不正使用である可能性が高いと Stripe が確信する支払いのすべてを引き続きブロックすることを強くお勧めします。
ルールが作成されると、許可ルールは即座にすべての新しい支払いに適用されます。これには、以前ブロックされた支払いに類似したものが含まれます。ルールをテストする際は、次を確認する必要があります。
- 以前にブロックされた支払いのうち許可されることになる数を調べます。許可ルールは、他のすべてのルールと Stripe のリスク評価を上書きします。新しい許可ルールをテストすると、このルールが有効であれば許可されたと考えられるすべての支払いが表示されます。これには、ブロックまたは不審請求の申請が行われた支払いが含まれ、今後の不審請求の申請率に影響を与える可能性があります。
- リスクの高い支払いのブロックは続行します。これを行うには、許可ルールに次を追加します。
and :risk_level: !=
'highest'
- ビジネスでの正当な取引履歴を評価します。各自の顧客間の関係を利用することで、正当な購入の履歴に基づき、より多くの取引を許可することができます。この結果、ビジネスで実証済みの履歴がある顧客からの支払いのブロックを減らすことが可能になります。これを行うには、属性リストを確認し、「customer (顧客)」という文字を含む属性を探します。
以下の例は、通常 (常にではありませんが) 、イギリスの顧客から問題のない支払いを受けているビジネスでの、許可ルールの改善方法を示しています。
元のルール | 改善されたルール |
---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
条件が緩すぎる場合: 一部の不正な支払いが許可されます | 条件がより厳しい場合: 許可される不正支払いが少なくなります |
ルールの管理
ビジネスが成長し続けるためには、望ましい顧客のタイプをルールで確実に反映し続けることが重要です。以下は、ビジネスの状況に合わせてルールを適切な状態に保ち、機能させ続けるためのベストプラクティスです。
ルールを定期的にモニタリングして、有効性が持続していることを確認する
ルールの指標
不正使用のパターンは常に変化するため、ルールのパフォーマンスを示す指標を提供しています。ルールのタイプによって実行されるアクションが異なるため、指標はルールのタイプによって異なります。
ルールのパフォーマンスチャートを使用して、Radar ルールの機能状況を把握します。ルールに一致する支払い件数の想定外の急増や減少 (許可ルールで許可される支払いが多すぎる、ブロックルールによるブロック件数が多すぎるなど) がないかを確認します。急増は、ビジネスで受け取る支払いの種類が変化したことを示す場合も、ルール自体の更新が必要になっていることを示す場合もあります。ルールを更新すると、グラフ上に三角形が表示され、変更前と変更後の影響を比較することができます。
色分けされた線は、3D セキュア ルール、許可ルール、ブロックルール、およびレビュールールと一致した支払いの件数を追跡します。これらのグラフの描線上の三角形の記号は、対応するタイプのルールの更新を表しています。
独自ルールの有効性についての情報が提供され、各ルールが対処した支払いの数が示されます。ルールが適用された支払いのみを限定して表示し、ダウンロードすることもできます。この情報を評価することで、ルールに変更を加える必要があるか、完全に削除する必要があるかを判断できます。
その他のコマンドを表示するには、省略符号 (•••) アイコンをクリックします。その他のコマンドには、無効化、有効化、編集、削除があり、すべてのルールに対して使用できます。
オプションとして、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 ネットワーク全体で実行される実験によって算出されます。
ブロックルールをクリックすると、以下の指標が表示されます。
レビュールール
レビュールールについて Radar for Teams のユーザーが表示できる内容は、次のとおりです。
- レビューに送信された支払い: ルールによって手動レビューに送信された支払いの合計件数。
- 承認されたレビューの金額: レビューで承認された支払いに関連付けられている、現地通貨による合計金額。
- 返金率: 返金されたレビューの比率。
- 承認済みレビューからの不審請求の申請: レビューにより承認されたが、最終的に不審請求の申請が行われた支払いの合計件数。
- 承認済みレビューからの不審請求の申請金額: 承認された支払いレビューから生じた不審請求の申請に関連付けられている、現地通貨による合計金額。
レビュールールをクリックすると、以下の指標が表示されます。
手動レビューリストを定期的に監視する
レビューリストが大きくなりすぎて管理できない場合は、適切なルールが設定されているかどうかを確認します。ほとんどのレビューが不正使用として返金されている場合は、支払いをブロックする追加ルールを検討します。同様に、ほとんどの支払いが承認されている場合は、レビュールールの対象を絞ることを検討してください。
不審請求が申請された支払いと返金された支払いを分析する
不審請求の申請は本質的に不正使用に関連しているため、不正使用削減への取り組みを強化すると、不審請求の申請率は低くなります。不審請求の申請が行われた支払いに類似する特徴があるかどうかを確認してください (場所の一致、金額の類似性など)。この調査は、レビュー中に返金された支払いを確認することでも実施できます。傾向を確認したら、適切なルールをテストして作成します。支払いが不正使用によるものであると判断できる場合は、返金を行い、不正使用として報告し、潜在的な不審請求の申請を回避します。
オプションとして、Sigma や Data Pipeline といった Stripe のレポート製品を使用して、不審請求の申請と不正使用のデータをクエリできます。
ダッシュボードを使用して、または API を介して、受領したあらゆる不審請求の申請に対応できます。また、Stripe の不審請求の申請に関するドキュメントには、十分に反証を収集した事例を提示するための推奨事項がいくつか記載されています。
不正使用率に影響を与える可能性があるビジネスへの大きな変化を予測する
主要な商品リリースやサービスの変更 (新しい高額商品や新しい国へのサービス拡大など) を計画している場合、開始当初はこれらの支払いを監視することをお勧めします。このような変更については、レビュールールを設定して、新しい支払いをすべて調べられるようにすることをお勧めします。これらの支払いをしばらくレビューしてパターンを識別することが、ビジネスを不正使用から保護する新しいルールの設定に役立ちます。