不正使用リスクの評価は、攻撃のベクトル、パターン、シナリオを特定し、それを軽減する反復プロセスです。Stripe のプロフェッショナルサービスチームがユーザーと緊密に連携にして調べたところ、このような作業を最も効率的に行っている企業の多くは、Stripe の Radar for Teams と 、Stripe Sigma や Stripe Data Pipeline などの Stripe Data 製品を組み合わせて不正使用分析とデータ分析を連携させることで、一般的な不正使用パターンと自社に特有のパターンの両方を特定していることがわかりました。

Radar for Teams の使用により、不正使用の検出と防止に対応し、カスタムルール、レポート作成、手動レビューなど、ユーザーの事業に合わせてカスタムの不正使用対策設定を作成することができます。また、レポート作成ソリューション の Sigma を使用すると、取引データ、コンバージョンデータ、顧客データのすべてを、Stripe ダッシュボードのインタラクティブな環境で利用できるようになります。Data Pipeline では、Sigma と同じデータを取得し、さらにそのデータを自動的に Snowflake や Redshift のデータウェアハウスに送信するため、他のビジネスデータと合わせて利用することが可能です。

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

Radar for Teams を Sigma や Data Pipeline と組み合わせて使用するメリット

Radar for Teams を Sigma や Data Pipeline と組み合わせて使用する主な目的は、メタデータなどの Radar データを、プレオーソリ、ユーザージャーニー、コンバージョン、セッション情報などの自社データと合わせて分析して、正当な取引と不正行為を区別することです。そうすることで、次のような点を最適化することができます。

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

Stripe のオンライン不正行為の現状レポートでは、手作業によるレビュープロセスのオーバーヘッドを浮き彫りにし、「[企業の] 規模が大きくなればなるほど、レビュー対象とする取引件数は少ない」傾向を指摘しています。このようなプロセスを自動化すれば、不正利用アナリストは、新たな攻撃ベクトルを特定したり、予防や検出のためのルールを開発したりする作業にもっと多くの時間を割くことができます。すなわち、不正利用のトラフィックをブロックすることと、正当な顧客の負担 (解約) を減らすことのバランスをうまく取れるようになるのです。

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

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

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

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

次に、仮想シナリオの中で 4 つのそれぞれの柱を確認し、Radar for Teams と Sigma や Data Pipeline がどのように役立つかをご紹介します。

今回のシナリオ

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

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

検出

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

新しい不正使用パターンの検出を開始する前に、まずは既存のルールのパフォーマンスなど、予測シグナルのベースラインを用意しておく必要があります。言い換えると、貴社にとって「通常」に見える取引、あるいは「良い」取引がどのようなものかを把握しておく必要があるということになります。そこで、不正使用アナリストとデータエンジニアが協力することになります (両者は、DevOps チームやそのチームの可観測性ツールとも連携することがあります)。この仮想シナリオでは、継続的なモニタリングを通じて、「Mallory」カードタイプからの取引拒否が増加していることが検出されています。

関連する不正使用データの Sigma テーブル

新たに登場したパターンを検出するには、まず、カード発行会社による支払い拒否率やオーソリ率、Radar のブロック率などの特徴でベースラインパフォーマンスを確立する必要があります。次に、不正使用に関する不審請求と不正使用の早期警告 (カード発行会社の不正使用記録)をクエリで確認します。さらに、高速で発生しているか、カード発行会社の支払い拒否率が高いか、Radar のリスクスコアが高い支払いトランザクションもクエリで確認します。利用できるデータに基づいてこのクエリを毎日実行するようにスケジュールを設定し、週次や月次など過去のデータですべてのダッシュボードを視覚化するのが理想的です。そうすれば、Sigma やデータウェアハウスに手動でクエリを行う必要がなくなります。その結果、インシデント対応時間を短縮できます。

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

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

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

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

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

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

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

このクエリには、遅延指標である実際の不審請求の申請のタイミングは含まれていません。ただし、カードテスティングの指標としての再試行など、いくつかのサンプル指標は含まれています。このクエリでは、以下のようないくつかの日次指標をシンプルな方法で取得できます。

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

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

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

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

調査

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

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

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

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

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

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

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

調査する簡単な方法は、ダッシュボードの「関連する支払い」ビューでサンプルを直接確認することで、行動 (攻撃ベクトルや不正使用パターン) および関連する Radar のリスクに関するインサイトを把握することです。そのため、上記のクエリでは任意の支払いサンプルを含まれています。そうすることで、Sigma ではまだ表示されない、より最近の支払いも見つけることもできます。より防御を重視したハイタッチな方法としては、立てた仮説をレビュールールとしてモデル化し、そのルールによって支払いを引き続き許可しながらも、アナリストに転送して手動レビューにかけることができます。一部のユーザーはこの方法を採用し、不審請求の申請手数料を下回る支払いについては返金し、それを超える支払いについてはブロックすることを検討しています。

確定

ここからは、特定したパターンが単純ではなく、不正使用を行った顧客への返金やブロックでは軽減できず、デフォルトのブロックリストの項目に当てはまらない場合を想定しています。

対応すべき新しいパターンを特定し、優先順位を付けたら、そのパターンが正当な売上に影響する可能性を分析する必要があります。これは、普通の最適化問題とは異なります。というのも、最適な不正使用件数はゼロでないためです。異なるすべてのモデル候補の中から、単純な重大性、または精度と再現率の点で、貴社のリスク選好に最適なトレードオフを表しているモデルを選びましょう。このプロセスはバックテストと呼ばれることもあり、特に、まずルールを作成し、その後で使用データに突き合わせて検証する場合にそのように呼ばれます (これを逆にして、最初にパターンを発見し、それからルールを作成することもできます)。たとえば、国ごとに 1 つのルールを作成するのではなく、次のようなルールを作成すると、確定が容易になります。

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

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

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

いよいよ、Sigma や Data Pipeline からの探索型クエリを翻訳して、Radar ルールをバックテストに向けて 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 の支払い結果オブジェクト、特にルールオブジェクトを確認することができます。同様に、Sigma では、charges.outcome_rule_id、charges.outcome_type、および payment_intents.review_id の各フィールドを分析に使用できます。ここでは、特別な Radar ルール決定テーブルを使用して、Sigma でのルールのパフォーマンスを追跡する方法の例を以下に示します。

機械学習を使った精緻化

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

たとえば、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 Teams の詳細については、こちらをご覧ください。すでに Radar for Teams をご使用の場合は、ダッシュボードの「ルール」ページを確認してルールの記述を始めましょう。

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