不正利用リスクの評価は、攻撃経路、パターン、シナリオを特定し、それらを軽減する継続的なプロセスです。ユーザーと緊密に連携する中で、当社のプロフェッショナル・サービス・チームは、不正行為の防止を最も効果的に行っている企業では、不正行為アナリストとデータアナリストが連携して、不正行為防止チーム向け Stripe RadarとStripe SigmaやStripe Data Pipelineなどの Stripe Data 製品を組み合わせて使用し​、一般的な不正行為のパターンと自社のビジネスに固有のパターンの両方を特定していることが多いことに気づきました。

不正の検出と防止を支援する Radar for Fraud Teams は、カスタムルール、レポーティング、手動確認など、お客様のビジネスに特化したオーダーメイドの不正利用設定を可能にします。Stripe Sigmaは、取引、コンバージョン、顧客データ のすべてを、Stripe ダッシュボードのインタラクティブな環境で利用できるようにするレポーティングソリューションです。Data Pipeline は同じデータを提供しますが、自動的に Snowflake または Redshift データウェアハウスに送信するため、他のビジネスデータと一緒にアクセスできます。

これらのツールはシームレスに連携するため、効果的な不正利用対策プロセスの 4 つの柱である、検出、調査、確定、精緻化と軽減に対応することができます。このガイドでは、その詳細を取り上げます。

Stripe Sigma または Data Pipeline と共に利用する Radar for Fraud Teams の価値

Radar for Fraud Teams を Stripe Sigma または Data Pipeline と共に不正利用対策チームで使用する主な目的は、Radar のメタデータなどのデータを、事前承認、ユーザージャーニー、コンバージョン、セッション情報などの独自のデータと一緒に分析し、正当な取引と不正利用者の行動を区別することです。こうすることで、以下を最適化できます:

1. インサイトを得るまでにかかる時間 (不正利用をプロアクティブに検出および防止するため)
   
2. 対応スピード(予防と検出のためのルール開発へ)
   
3. 不正利用に伴うコスト(返金、不審請求の申請に伴う費用、顧客の解約、カード発行会社による支払い拒否など)
   

当社の オンライン不正行為の現状 レポートは、手作業によるレビュープロセスの運用上のオーバーヘッドに着目し、「[会社]の規模が大きくなるほど、レビュー対象となる取引の割合は小さくなる」と指摘しています。このようなプロセスを自動化することで、不正利用アナリストは新たな攻撃経路の特定や不正利用防止ルールの開発により多くの時間を割くことができます。つまり、不正トラフィックのブロックと正規顧客の摩擦 (解約) の低減のバランスをうまくとることができるのです。

取引不正対策の基本プロセス

ここでは、貴社が、より規模の大きなリスク管理の枠組みの中で行われる、検出、調査、確定、精緻化と軽減という取引不正対策の基本プロセスを運用していると仮定します。

• 検出(識別、予測、インシデントレスポンスとも呼ばれる)は、さらなる調査が必要なデータポイントを発見することです。検出は、手動(インシデント発生時など)、半自動(検出ルールまたはベースラインに対するモニタリング)、自動(機械学習または異常検出)、または外部トリガー(顧客からのフィードバックや不審請求の申し立てなど)の場合があります。検出に関しては、Radar の機械学習は一般的な不正利用パターンを自動的に見つけることができ、Stripe Sigma はお客様のビジネスに特化したパターンを見つけることができます。
  
• 調査(または探索的分析)とは、疑わしい支払いや行動を評価し、ビジネスへの影響をより深く理解することです。多くの場合、ノイズを排除するために広範なデータとの照合を行います。通常、不正利用アナリストはRadar レビューキューまたはStripe の決済ダッシュボードを使用して調査を行います。
  
• 確定(モデリングまたはバックテストとも呼ばれる)は、検証された不正利用攻撃経路を次元やモデル候補に一般化することです。また、過去のデータを用いた検証や他のルールに対する影響評価も含まれます。Radar のバックテストとシミュレーション機能 は不正利用アナリストのこの作業を支援しますが、データエンジニアは Stripe Sigma をより幅広いシナリオに利用できます。
  
• 精緻化と軽減(行動または封じ込めとも呼ばれる)とは、不正利用を防止、監視、または迂回させるために、次元と重要な機能を Radar ルール述語にマッピングするモデルの実装のことです。従来であれば、これらは静的な防止ルールでしたが、機械学習 が人間にとって重要な対応であり、精度を高めることが目的である現在では、「精緻化」という用語がより適切です。これは通常、Radar のブロックルールやリストで構成されます。
  

このプロセスの基本的な実装には、ルールに基づく不正利用検出設定の日々のチェック、スプリント、リリースなどの反復サイクルを含めることができます。しかし、サイクルタイムがそれぞれ異なる可能性があり、フィードバックループが同時に発生する可能性もあることから、Stripe ではこれを 1 つの継続的なプロセスとして捉えるのが望ましいと考えています。

次に、これら 4 つの柱のそれぞれを仮想シナリオに沿って詳しく見ていき、Radar for Fraud TeamsとStripe SigmaまたはData Pipelineがどのように役立つかをご紹介します。

今回のシナリオ

今回の仮想シナリオでは、突発的に起きる行動ではなく、一定期間にわたって起きる行動を分析します。

たとえば、貴社は E-コマース事業者であるとします。Webhook モニタリングをオブザーバビリティー (可観測性) ツールで設定し、支払いに関する傾向のさまざまなチャートをリアルタイムで作成しています。貴社は、「Mallory」というカードブランドからの拒否件数が、この数日間で着実に増加していることに気付きました。拒否の対象となっているのは、このカードブランドがよく使われる地域では通常は販売されていない商品です。 (注: Mallory はこのシナリオのための架空のカードブランドであり、Enhanced Issuer Network には登録されていません。)この変化を説明できそうなセールスプロモーションやその他のインシデントが存在しないため、何が起きているのかを調査し、次に取るべき対応を決める必要があります。

検出

Stripe のデフォルトルールでは、機械学習を使って、不正使用による支払いの相当数を予測、検出してブロックします。Radar のアナリティクスダッシュボードを利用すれば、不正使用の傾向の概要を素早く把握することができます。また、レビュー、許可、ブロックの対象とする支払いをより厳密に制御する必要のある企業にとって、ルールは不正防止をカスタマイズするための強力な手段です。

新しい不正パターンを検出し始める前に、まず予測に使える信号の基準 (既存ルールのパフォーマンスなど) を把握しておく必要があります。言い換えれば、自社ビジネスにおいて何が「正常」なのか、あるいは「良い」取引とはどのようなものかを理解しておく必要があるということです。ここで、詐欺分析担当者とデータエンジニアが協力して作業します (場合によっては、DevOps チームやそのオブザーバビリティツールとも連携します)。仮のシナリオでは、継続的なモニタリングによって「Mallory」カードタイプの取引拒否が増加していることが検出されます。

不正利用関連データを含む Stripe Sigma テーブル

新たなパターンを検出するには、まず、カード発行会社の拒否率/オーソリ率や Radar ブロック率などの機能でパフォーマンスの基準値を設定します。次に、不正利用の申し立て、不正利用の早期警告(発行会社の不正記録)、および高速な支払い取引、発行会社の拒否率が高い、またはRadar リスクスコアが高いものをクエリします。理想的には、このクエリを利用可能なデータに基づいて毎日実行するようスケジュールし、Stripe Sigma やデータウェアハウスに手動でクエリすることなく、週次や月次のカットを含む過去のデータですべてのダッシュボードを視覚化することです。これにより、インシデント対応時間が短縮されます。

以下は、最も関連性の高いテーブルです。

不正使用アナリストやビジネスアナリストは、ビジネスドメインに基づいて評価するうえで、追加の内訳ディメンションのうちどれが重要かを把握する必要があります。Radar for Teams の Radar ルール属性 テーブルには、Radar によって評価された既存の取引に関する詳細情報がありますが、2023 年 4 月より前の履歴データはなく、メタデータと最終結果もありません。それより前のデータについては、以下のフィールドに対するクエリを実行します。

新しい Radar ルール属性テーブルでは、Radar によって評価された各取引について、Radar 属性の正確な名前で、同じディメンションだけでなくさらに多くのディメンションも追跡できます。たとえば、name_count_for_card_weekly のようなベロシティに関する傾向を追跡できます。

傾向を視覚化する方法は複数ありますが、他の要因との比較を容易にするため、内訳ごとのシンプルなピボット付き折れ線グラフを作成するとよいでしょう。調査フェーズで掘り下げる際には、それぞれ異なる内訳を組み合わせることをお勧めします。以下のサンプルテーブルでは、「Mallory」カードタイプでの取引拒否の増加に関する商品セグメントの内訳を示しています。

お好みの表計算ツールで次のように可視化することもできます。

それでは、Sigma や Data Pipeline のクエリでベースラインデータを返す例をもっと詳しく見てみましょう。以下のクエリでは、日々の不審請求の申請、支払いの失敗、ブロック率などが、それぞれ異なる列に表示されています。検出や調査の際には、範囲の広い疎データを異なる列で表示した方が視覚的にわかりやすい場合が多いです。また、そうした方が、後で列を Radar 述語にマッピングしやすくなります。ただし、データサイエンティストによっては、調査フェーズでの探索型分析や、確定フェーズ、精緻化フェーズ、軽減フェーズでの機械学習に、縦長の高密度の形式を好むことがあります。

この例では、支払いにメタデータを含めることで、商品セグメントごとの内訳が表示されるようにしています。広範なアプローチにする場合、カードブランド (「Mallory」) と資金調達のタイプについて、このシナリオに沿った同様のクエリが必要となります。ここでは、実際のインテントに焦点を当て、その重大性を際立たせるために、再試行の重複を除外しています。支払いインテントに基づいて重複の除外を選択しましたが、複雑な実装では、ユーザージャーニー全体で重複が確実に除外されるよう、フィールド (メタデータ内の注文 ID など) を送信することがあります。この例は、別の要素を追加することで、不正防止対策の精度を向上できることを示しています。このシナリオでは、商品セグメント「ギフトカード」がこれに該当します。精度を向上させる方法については、後ほど「精緻化と軽減」のセクションでご説明します。

このクエリには、実際の不審請求の申し立てのタイミングは含まれていません。これは遅行指標ですが、カードテスティングの指標としてのリトライなど、いくつかの指標サンプルが含まれています。このクエリでは、いくつかの日々の指標をシンプルな方法で取得します:

• 支払い件数 (重複除外された値と未処理の値の両方): たとえば、1,000 件の支払いインテントに対して 1 日に 1,150 件の支払いがあり、そのうち 100 件が拒否され、50 件が Radar によってブロックされた場合。
  
• オーソリ率: この例では、ブロックされた支払いの情報はカード発行会社に届かないため、支払いについては 90% となり、支払いインテントについては、最終的に再試行がすべて成功するため 100% となります。
  
• 高リスク率とブロック率: この例では、どちらも 1.6% になります (高リスク 50 件もすべてブロックされています)。
  
• 同時期の支払いに対する過去の不審請求の申し立て率: たとえば、1,000 件の支払いのうち 5 件で不審請求の申し立てがあったとします。不審請求の申し立てが多くなると支払い日あたりの数が増えるため、変化を追跡するためにクエリの実行時間を含めます。
  

前述のとおり、これらのクエリは読みやすくするために単純化してあります。実際には、傾向、偏差、損失差など、さらに多くのディメンションをこのクエリに使うことができます。

また、窓関数を使った 30 日移動平均の例も含めています。ロングテール攻撃を特定するために平均値ではなくパーセンタイルを見るなど、より複雑なアプローチも可能ですが、完全に正確な数値よりもトレンドラインの方が重要なため、初期段階の不正利用検出にはほぼ必要ありません。

ベースラインを理解したら、異常や傾向の追跡を開始し、たとえば、特定の国や支払い方法 (この仮想シナリオでは、カードブランド「Mallory」) からの不正利用やブロック率の増加について調査することができます。異常についての調査は通常、ダッシュボードのレポートや手動分析、または Stripe Sigma のアドホッククエリを使って行います。

調査

アナリストが調査すべき異常を見つけたら、次のステップとして、Stripe Sigma (または Data Pipeline 経由のデータウェアハウス) でクエリを実行し、データを探索して仮説を構築します。立てた仮説に基づいて、いくつか内訳ディメンションを含めるとよいでしょう。例としては、不正利用の傾向が見られる支払い方法 (カード使用)、チャネルやサーフェス (メタデータ)、顧客 (評判)、商品 (リスクカテゴリ) を挙げることができます。後に「確定」の段階で、これらのディメンションを「特徴」と呼ぶことができます。これらは Radar 述語にマッピングされることになります。

では、「Mallory」によるプリペイドカードでの大量取引は、不正利用率が高くなるとする仮説に戻ってみましょう。不正利用率は、分析ツールを使ってピボットするためのグループ化ディメンションとして表すことができます。通常この段階では、クエリを反復して細かく調整します。そのため、仮説の縮小版または拡張版としてさまざまな述語候補を含めて、重要性の低い特徴は除外し、その影響を測定するとよいでしょう。以下の例をご覧ください:

このアプローチを通じて重大性を把握して、影響に優先順位を付けることができます。この表では、ルール候補 3 が過度の悪意のある取引を把捉していると思われることが、合理的な信頼性を持って示されています。もっと精緻にした評価は、精度、正確さや再現率に基づいて行われることになります。以下のクエリで、そのような出力を作成できます。

このクエリでは、読みやすくするために重複除外を削除していますが、カードブランドのモニタリングプログラムにとって重要である不審請求の申請率と不正使用の早期警告率は含まれています。ただし、これらは遅行指標であり、この簡略化したクエリでは、これらを単に過去に遡って追跡しています。また、クエリで見つかったパターンをクロスチェックし、より詳細に調査することができるよう、任意の支払いサンプルも含めてあります。これについては後ほど詳しく取り上げます。

追加のメトリクス群をヒストグラムに分解してクラスターを特定しておくと、レート制限に使える速度ルール (例: total_charges_per customer_hourly) を定義するのに役立つ可能性があるのでお勧めです。

ヒストグラム分析による傾向の特定は、顧客のライフサイクルとコンバージョンファネルの全体における望ましい顧客行動を理解するうえで優れた方法となります。それを上記のクエリに加えると複雑になりすぎますが、メタデータに顧客タイプ (ゲストユーザーなど) があると仮定して、複雑なローリング期間のロジックなしで分解する方法の簡単な例を、以下に示します。

このシナリオでは、「Mallory」からのプリペイドカードをすべてブロックしない方がよいかもしれませんが、それでも、相関性のある他のリスク促進要因を確信を持って特定することをお勧めします。この速度関連のクエリにより、たとえば、低頻度のゲスト顧客がブロックされるのを避けられるなど、信頼性が向上する可能性があります。

調査する簡単な方法は、「関連する支払い」ビューでダッシュボードのサンプルを直接見て、攻撃経路や不正パターンといった行動、関連するRadar のリスクに関するインサイトを理解することです。これが、上記のクエリに任意の支払いサンプルを含めた理由です。こうすることで、Stripe Sigmaではまだ利用できない最近の支払いも見つけることができます。より防御的でハイタッチな方法としては、仮説をレビュールールとしてモデル化し、支払いは許可するが、手動レビューのためにアナリストに経路を振り分けることです。顧客の中には、不審請求の申請手数料を下回る支払いについては返金を検討し、それを上回る支払いについてはブロックするために、これを行う場合もあります。

確定

今後、あなたが特定したパターンが単純ではなく、不正利用者の返金とブロックでは軽減できず、デフォルトのブロックリストに該当しないと仮定しましょう。

対処すべき新しいパターンを特定し、優先順位をつけたら、そのパターンが正規の収益に与える潜在的な影響を分析する必要があります。これは些細な最適化問題ではありません。なぜなら、最適な不正利用額はゼロではないからです。様々なモデル候補の中から、単純な大きさ、または精度と再現率によって、リスク選好度に対して最良のトレードオフを示すモデルを選択します。このプロセスは、バックテスト と呼ばれることもあります。特にルールが最初に作成され、その後データに対して検証される場合に該当します(これは逆に行なうこともできます。つまり、まずパターンを発見し、それからルールを作成するのです)。例えば、国ごとに 1 つのルールを作成する代わりに、以下のようなルールを作成すると、確認が容易になります。

Block if :card_funding: = 'prepaid and :card_country: in @preaid_card_countries_to_block

また、「調査」のセクションでご紹介したクエリをモデルとして使用できる場合もあります (ただし、その場合でも、強調される値は異なります)。この点については、後ほど「精緻化と軽減」の技法に関するセクションで詳しくご説明します。

Stripe Sigma スキーマと Radar ルールのマッピング

Stripe Sigma または Data Pipeline からの探索的クエリを、バックテスト用にRadar ルールを Stripe Sigma にマッピングするのに役立てましょう。ここでは、Radar に正しいシグナルを送信していると仮定して、一般的なマッピングをいくつか紹介します:

最後の 2 つの項目である risk_level と risk_score は、その他の項目とは異なります。機械学習モデル自体が他の要素から派生したものであるためです。複雑すぎるルールを作成するのではなく、Radar の機械学習を信頼して活用することをお勧めします。この点については、機械学習を使った精緻化のセクションで詳しくお話しします。

新しい Radar ルール属性テーブルでは、Radar によって実際に評価された各取引について、Radar 属性の正確な名前で、同じディメンションだけでなくさらに多くのディメンションも追跡できます。

上の表は標準的な属性をまとめたものであり、Radar セッションやメタデータなど、カスタマージャーニーに合わせてカスタマイズするようなシグナルは意図的に省略してあります。

上記の調査に基づいて、次のようなルールが出来上がったと仮定しましょう。

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :amount_in_usd: > 20 and ::CustomerType:: = 'guest' and :total_charges_per_customer_hourly: > 2

次のステップでは、このルールが実際の支払い取引に与える影響を確定します。通常はブロックルールでこれを行います。正しいルール構文の作成方法についてのガイダンスとして、Radar for Teams: ルールの基本ガイドをご覧ください。ブロックルールをテストする簡単な方法は、テスト環境で作成し、手動のテスト支払いを実行して、意図したとおりに動作するか検証することです。

ブロックルールとレビュールールのどちらも、Radar for Teams のシミュレーション機能を使用して Radar でバックテストすることができます。

Radar for Teams のシミュレーションを使うメリットの 1 つは、他の既存ルールの影響も考慮されることです。ルールの管理はこのガイドの焦点ではありませんが、ルールの削除や更新も、継続的な改善プロセスの一環とする必要があります。一般に、使用するルールの数は、各ルールがそれ以上分割できず、かつ、検出フェーズと調査フェーズで開発したベースラインクエリを使ってモニタリングでき、副次的な悪影響のリスク (例: ルール 1 が他の何かを除外するため、ルール 2 のみが機能する) なしに明確にバックテストできる程度に、少ないものにする必要があります。

これを行うには、ブロックルールの代わりにレビュールールを使用することもできます。詳細は次のセクションで取り上げます。

精緻化と軽減

最後に、ブロックルールをテストした後で、そのモデルを適用して不正利用の防止、監視、再振り分けを行います。このプロセスは、不正防止対策全般の精度を、特に機械学習と連動して向上させるものであるため、Stripe ではこれを精緻化と呼んでいます。精度を向上させるために、さまざまな技法を導入する場合もあります。このステップは封じ込めや軽減とも呼ばれ、確定と同時に行われる場合もあります。その場合、レビュールール、A/B テスト (メタデータ)、またはシミュレーションを使用してモデルを評価するのではなく、疑わしい支払いを即時にブロックして、差し迫ったリスクを軽減します。

すでに対策を講じている場合でも、以下のように、ステップ 1 ～ 3 で開発したモデルを精緻化して、時間とともに結果を改善させるために使える技法がいくつかあります:

レビュールールを使った精緻化

誤検出率が高くなって収益に影響が出るリスクを避けたいのであれば、レビュールールの導入を選択できます。これはより手動的なプロセスであり、顧客体験にネガティブな影響を与えるおそれがありますが、レビュールールによって、より多くの正当な取引を最終的に進めさせることができます。(速度の遅い取引を対象とした既存のブロックルールに、速度ルールという形でスロットリングを追加することも可能です)。レビュールールを使う場合のより高度な選択肢の 1 つは A/B テストであり、これはレビューキュー内の全ケース数を管理するのに特に有効です。支払いのメタデータを活用して、A/B テスト中に少量のトラフィックを (既知の顧客からのトラフィックや、単に乱数を使用したトラフィックなど) を許可することができます。これをブロックルールに追加することをお勧めします。許可ルールの作成はお勧めしません。その理由は、許可ルールはブロックを上書きするため、ブロックルールのパフォーマンスを経時的に追跡することが難しくなるためです。

パフォーマンスの監視によるルールの最適化

ルールのパフォーマンスを監視するには、Payment Intents API での料金結果オブジェクト、特にルールオブジェクトを確認します。同様にStripe Sigmaでは、charges.outcome_rule_id、charges.outcome_type、およびpayment_intents.review_id フィールドを分析に使用できます。以下は、Stripe Sigma で特別なRadarルール決定テーブル を使用してルールのパフォーマンスを追跡する方法の例です:

機械学習を使った精緻化

多くの場合、差し迫った攻撃をブロックした後の次のステップは、機械学習と並行して誤検出を減らしてルールを繰り返し調整して、より多くの正当なトラフィックを許可し、最終的に売上を計上できるようにすることです。

たとえば、BIN や IIN (カード発行会社識別番号) のブロッキングを考えてみましょう。カードテスティング攻撃の際、BIN を一時的にブロックリストに追加することがありますが、そうすることでカード発行会社にギャップを修正する時間を与えることができます。しかし、カード発行会社を完全にブロックすると、売上が減少する可能性があります。より洗練されたアプローチは、時間をかけてより多くの精査を行い、モデルを改良することです。この機会に、効果的なルールの作成方法や、リスク評価の方法、特に Radar のリスクスコア機能について見直してみるとよいでしょう。Stripe は一般に、Radar の機械学習をユーザーの洞察力と組み合わせることを推奨しています。高リスクの取引をすべてブロックするルールを 1 つだけ用意するのではなく、そのスコアを、リスクモデルやシナリオを表した手動ルールと組み合わせることで、多くの場合、悪意のあるトラフィックのブロックと、売上の確保をよりバランス良く実現できるようになります。以下の例をご覧ください。

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :card_country: in @high_risk_card_countries_to_block and :risk_score: > 65 and :amount_in_usd: > 10

3DS を使った精緻化

前述のとおり、このガイドは 3D セキュア (3DS) 認証について幅広く取り上げているわけではありませんが、リスク軽減戦略の一環としてご検討ください。たとえば、ライアビリティシフトによって、不正使用取引についての不審請求の申請手数料が削減されるかもしれませんが、これらの取引は引き続きカードのモニタリングプログラムの対象であり、それによってユーザー体験が低下する可能性もあります。固定額にするのではなく、次のようにして、このルールを「関連するすべての支払いをブロックする」から「3DS を必要とする」に改善することができます。

Request 3DS if :card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’

その上で、認証に成功しなかったカードや、その他の理由でライアビリティシフトを提供しないカードには、次のようにしてルールでブロックをかけるようにします。

Block if (:card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’) and :risk_score: > 65 and :has_liability_shift: != ‘true’

リストを使った精緻化

デフォルトのリストを使用するか、カスタムリストを維持することで、たとえば不正使用を行った顧客や、不正使用が行われたメールドメイン、カード国をブロックするなどして、インシデント発生時にルールを変更するリスクなしに攻撃を非常に効率的にブロックできます。精緻化では、どのパターンをルールにするか、ルールの述語を変更する必要があるか、既存のリストに単純に値を追加できるかを決定します。Breakglass ルールは、インシデント発生時の応急処置の良い例であり、その後、改善が行われてリストになるか、または既存ルールが変更される可能性があります。

フィードバックプロセス

精緻化とは、ステップ 1 に戻り、使用ルールのパフォーマンスと不正使用パターンの監視を行うことでもあります。優れたモニタリングは、確立されたベースラインと、バックテストのトレーサビリティー、精度および再現率を最適化するための単一でアトミックな変更にかかっています。そのため、ルールや述語の変更は、明確で他のものと区別できる範囲でのみ行い、それ以外はリスト、レビュー、先を見越したブロックや返金に依拠することをお勧めします。

Stripe にできること

プラットフォームでの Radar

Stripe Connect を使用したプラットフォームの場合、作成するルールはプラットフォームアカウントで作成された支払い (Connect の用語では、これはデスティネーション
支払いまたは on-behalf-of 支払いと呼ばれます) のみに適用されます。Connect アカウントで直接作成される支払いには、そのアカウントのルールが適用されます。

Terminal での Radar

Stripe Terminal の場合、支払いは Radar でスクリーニングされません。したがって、Terminal を使用している場合は、対面支払いをブロックしてしまう心配をせずに、IP 頻度に基づいたルールを作成できます。

Stripe のプロフェッショナルサービス

Stripe のプロフェッショナルサービスチームは、継続的に改善される不正使用対策プロセスの実装を支援することができます。既存の実装の強化から新しいビジネスモデルの立ち上げまで、Stripe のエキスパートが既存の Stripe ソリューションの機能強化に役立つガイダンスを提供します。

結論

このガイドでは、Sigma や Data Pipeline を使用して、ベースラインだけでなく、攻撃のシナリオやパターンを表すさまざまな不正利用対策モデルも構築する方法をご紹介してきました。また、Radar を拡張し微調整を加えて、カスタムルールに基づき、より広範囲にわたる不正利用取引に対応できるようにする方法についても取り上げてきました。

支払いにおける不正利用は絶え間なく進化しています。このため、検出、調査、確定、精緻化と軽減のモデルで概説したとおり、このプロセスも遅れを取らないよう常に進化させていく必要があります。これらのサイクルを高速なフィードバックループで継続的に実行していくことで、インシデント対応に費やす時間を削減し、先を見越した不正利用対策戦略の策定のためにより多くの時間を割くことができるはずです。

Radar for Fraud Teams の詳細については、こちら をご覧ください。すでに Radar for Fraud Teams ユーザの方は、ダッシュボードのルールページ をチェックし、ルールの作成を始めてください。

Stripe Sigma についてはこちら を、Stripe Data Pipeline についてはこちら をご覧ください。