不正検知ルールを書くこと自体は、ほとんどのデータアナリストや不正対策の専門家なら、仕事を始めて最初の週でもできる作業です。不正検知ルールを良いものに仕上げるとなると、残念ながら少しばかり厄介になります。
その理由を理解するためには、まず良い不正検知ルールとは何かを明確にする必要があります。答えはとてもシンプルで、そのルールはその時々の状況で十分に効果を発揮しつつ、不正行為者の行動変化にも耐えうる強さを持っていなければなりません。
たとえば、金額条件が固定されたルールは、かなり脆くなることがあります。ルールに「金額が100ドルを超えること」という条件が含まれている場合でも、不正者は99ドルを動かせばそのルールを回避し、同じだけの金額を稼ぐことができてしまいます。
このブログ記事では、最近一部のお客様向けに不正検知ルールを作成した際に私が行った分析プロセスを共有したいと思います。皆さんがご自身のルールを設計する際のヒントになれば幸いです。
始める前に、方法論について少しお話しします
本日の焦点は、新しいルールのリサーチ段階です。あらゆる分析的なリサーチ作業と同様に、私は Excel やルールエンジン上ではなく、SQL 環境で行うことをおすすめします。もちろん、どのような方法でリサーチしても構いませんが、私の経験では、データウェアハウス内で行ったほうがより効果的な取り組みになります。SQL はまだ初心者ですか？心配はいりません、今の時代にはそのための LLM がありますから！
もう一つ付け加えておきたいのは、反復的なリサーチを行う際に私の指針となる一連のKPIについてです。
本番環境でルールを有効化する前に、私の組織には順守すべき成功基準を定めたポリシーがあります。多くの組織では、これは新しいルールをリリースする際に必要となる目標、検証、そしてドキュメントの一式を指します。
最終的な成功基準は、どのKPIを見るべきか、どの目標を目指すべきかといった点に至るまで、私たちの反復的なリサーチプロセスの設計に反映されるべきです。ルールを一つひとつ条件ごとに作成しているとき、これによって自分が正しい判断を下しているかどうかを理解する助けになります。
ユースケースごとに変わる可能性はありますが、プロセスのあらゆる段階で常に追跡しておきたいKPIが2つあります。
- 精度：自分のルールがどれだけ正確か、そしてその結果としてどれだけ多くの誤検知（偽陽性）が影響を受けるか
- 再現率：不正検知でどれだけ多くの不正事例を捉えられているか
このバランス調整はかなり分かりやすいものの、決して簡単ではありません。ルールに条件を一つ追加するごとに、リコールをほとんど変えずに、適合率が上がっていることを確認したいのです。
最後に、私が扱っていたデータセットについて少し説明します。レビューを始めたとき、私は特定のセグメント、つまり特定の期間に、特定の顧客グループから発生したあらゆる種類の支払いイベントに焦点を当てました。
最初のデータセットには約47万6千件のレコードが含まれており、そのうち1,480件が不正と判定されていました。これにより、初期の精度（不正率）は0.31％となりました。
私は常に支払いの自動拒否ルールの基準として40％の適合率を使っています。その数値に十分高い再現率を保ったまま到達できれば、満足だと考えています。
3つのステップでできる不正対策ルールの作り方：
私は16年間にわたり不正防止に携わり、何百ものルールを作成し、何千もの不正防止ルールが稼働するシステムを監督してきました。
高い効果を発揮するルールを作成するために、私が用いているプロセスは次のとおりです。
- 「きっかけとなる異常」を見つける。阻止しようとしている中核的な不審行動を定義する。
- 異常の内容を説明してください。ルールを洗練し、誤検知を減らすために次のものを除外します：異常の説明：私たちの主な疑いに似た正当な行動／トラストシグナル：一般的にリスクが低い集団を特徴づける指標
- 検証して承認する。
分かりやすく説明しましょう。
「発端となる異常」を見つける
先ほど説明したデータセットを眺めながらチャージバックを確認し、何かヒントになりそうなものを探していました。すると気づいたのです。いくつかの不正利用のケースで、IP の位置情報（特に IP の州情報）がユーザーの住所と一致していないことに。
考えさせられました。ジオミスマッチは典型的な不正のシグナルなのに、こうした事例がかなり見つかったのです。普通なら、こうしたミスマッチはシステムですぐに検知されると思いますよね？
その理由は、すでにお察しのとおり、「承認されたミスマッチ」の母集団が誤検知であふれていたからです。4,355件のうち、不正と判定されたのはわずか370件だけでした。
これらの「低リスク」の不一致が却下されなかった理由は理解できましたが、それと同時に、ルールを調査するための良い「きっかけ」や「誘発的異常（Inciting Anomaly）」としても機能していました。精度は低くても、多くの不正事例を特徴づける異常なシグナルなのです。
そして実際、精度が8.5％ということは、IPと住所が一致しない場合は、一般の利用者と比べてすでに27倍もリスクが高くなっており、その条件だけで不正のちょうど25％を検知できていることを意味します。
私は可能性を感じました。 通常、一般集団よりも20倍リスクが高いシグナルは、ルール調査を始めるうえで良い出発点になります。
ルール案
IP_state != address_state
ルールのパフォーマンス
不正件数 | イベント数 | 精度 | 想起す |
370 | 4,355 | 8.5％ | 25％ |
異常の説明
きっかけとなる異常を見つけたら、次の目標は再現率をあまり下げずに精度を高めることです。
私がやりたくないのは、ルールロジックにさらに疑わしい指標を追加することです。なぜかというと、それをすると不正者の集団が複数の詐欺グループに分かれてしまう可能性が高いからです。
それはリコールを低下させるだけでなく、ルールを非常に限定的なものにしてしまいます。そして忘れないでください、特定の条件に特化しすぎたルールは簡単に回避されてしまうのです。
その代わりに、信頼できる顧客の行動がどのようなものかを説明し、その行動をルールのロジックから除外できるようにしたいのです。言葉の言い換えのように聞こえるかもしれませんが、すぐに気づくことになるでしょう、それはルール作成における重要なポイントは、疑わしい兆候を見つけることではなく、誤検知（偽陽性）をどのように定義するかということだという点だということに。
除外できる誤検知パターンを特定する方法は2つあります。それは、異常の説明とトラストシグナルです。
異常の説明
アノマリーの説明とは、それ自体は必ずしもリスクが低いとは限らないものの、そのアノマリーを「解消」し得るシグナルのことです。つまり、なぜ正当なユーザーがそのような行動を取るのかを示すものです。
例えば、IP に関わる異常を扱うとき、私がまず確認する説明要素は IP の種類そのものです。もしそれが厳格に管理された IP（.gov、.mil、.edu など）であれば、その IP とユーザーの住所との間に地理的な不一致がある理由を説明できます。これは一部には頻繁な出張や移動を示唆するためでもありますが、それ以上に、社内 VPN などの内部 VPN が使われていることを示している場合が多いからです。
もちろん、厳格に管理されたIPを使うこと自体は、今回のような特定の異常なケースに限らず、一般的に安全です。ただし代償もあります。そうしたIPはそれほど多くはないのです。そして、まさにここでもそのことが当てはまっていました。
ルール案
IP_state != address_state
かつ、IP_connection_type が（"mil | gov | edu | org | corp"）のいずれかであること
ルールのパフォーマンス
不正件数 | イベント数 | 精度 | 想起す |
370（－） | 4,344（-11） | 8.5％（－） | 25％（減） |
誤検知をわずかに減らすことはできましたが、性能はほとんど変わっていません。
次に、IPプロキシのシグナルをより詳しく確認したいと考えました。多くの不正行為が、プロキシIPの使用確率が中程度から高い場合に発生していることが明らかになりました。これは理にかなっていて、不正行為者は同じ国でさえあれば被害者の住所から大きく離れた場所のプロキシIPを雑に使うことが多いからです。
そこで、プロキシの使用可能性が低いイベントに注目してみると、ISP の接続タイプはモバイルやハイブリッドの接続タイプよりもはるかに安全であることに気づきました。これも理にかなっています。詐欺行為を行う者は、自分たちの身元が露呈しかねない安定した IP レンジを使う可能性が低いからです。
そこで、プロキシの可能性が「低く」、かつ接続タイプがISPであるケースを除外する条件を追加しました。
ルールドラフト
IP_state != address_state
かつ、IP_connection_type が（“mil | gov | edu | org | corp”）のいずれかであること
AND (IP_proxy == “low” AND IP_connection_type == “ISP”)
ルールのパフォーマンス
不正件数 | イベント数 | 精度 | 想起す |
370（-46） | 2,860（-1484） | 11.3%（+2.8%） | 21.4%（-3.6%） |
なかなか良さそうに見えますよね？そうかもしれませんが、ここで「取り逃がして」しまった不正ケースの数には満足していませんでした。多くの誤検知を減らせたとはいえ、もっと分析を重ねれば、まだ悪い奴らを取り締まり続けられると確信していたのです。
こちらは、私が普段どのように取り組んでいるかを示す短い動画です。
直近の除外によって私のルール対象から外れた1,484件のケースを、私が確認している様子がわかります。最初に行うのは、結果を不正ケースが上に来るように並べ替え、パターンを見つけやすくすることです。
それから、全体でどれくらいの不正ケースがあるか（除外された46件）を素早く確認し、最後に、不正な母集団と健全な母集団をどう見分けられるかを探ります。
この場合（そしてもちろん、動画を録画する前に気づいていましたが）、不正なケースはすべて認証済みのメールアドレスを持っていないことに気づきました。そこで、その条件をすぐに自分のルールロジックに組み込みました。
ルールドラフト
IP_state != address_state
かつ、IP_connection_type が（"mil | gov | edu | org | corp"）のいずれかであること
AND (IP_proxy == “low” AND IP_connection_type == “ISP” AND cust_email_verified == TRUE)
ルールのパフォーマンス（直近のバージョンを除く）
不正件数 | イベント数 | 精度 | 想起す |
370（－） | 3,279（-1065） | 11.3%（+2.8%） | 25％（減） |
私の精度は同じままであり、誤検知をそれほど多く除外していないにもかかわらず、再現率は大きく向上しています。これははるかに優れたルールのバージョンです。
信頼のシグナル
この時点で、IPアドレスと住所が食い違っていてもおかしくない、ほかのもっと納得のいく理由がないかを探そうとして、さらに数時間を費やしました。これ以上の説明が見つからなかったため、私は第2の作戦に切り替えました。つまり、一般的な信頼のシグナルを見極めることです。
ここでの考え方は、この異常がなぜ理にかなっているのかを説明することではなく、一般的にリスクの低いセグメントを除外することで、対象となる母集団を絞り込むことです。
先ほど使用したメール認証シグナルは、その代表的な例です。このデータセットの文脈では、それ単体では特に強力な指標ではありませんでしたが、IPタイプの条件と組み合わせることで初めて強い効果を発揮しました。
一方で、認証済みの電話番号はそれ自体で十分に強力なシグナルであることが分かったので、次のレイヤーとして組み込みました。
ルール案
IP_state != address_state
かつ IP_connection_type が（"mil | gov | edu | org | corp"）のいずれかである
AND (IP_proxy == “low” AND IP_connection_type == “ISP” AND cust_email_verified == TRUE)
かつ cust_phone_verified == TRUE
ルールのパフォーマンス
不正件数 | イベント数 | 精度 | 想起す |
366（-4） | 1,862（-1417） | 19.7%（+8.4%） | 24.7％（-0.3％） |
最終的に、私のルールバージョンで検知された多くの優良顧客がビジネス用メールアドレスを使っていることに気付きました。そこで、データセットには「フリーメール」のドメインだけを残すことにしました。
これはそれ自体では必ずしも強力な指標とは言えません（詐欺師は簡単にあなたのメールアドレスを盗めてしまうため）ですが、私たちが直接は特定できなかった、より多くの旅行やVPNに関するストーリーを説明してくれる可能性があります。
ルール案
IP_state != address_state
かつ、IP_connection_type が（“mil | gov | edu | org | corp”）のいずれかであること
AND (IP_proxy == “low” AND IP_connection_type == “ISP” AND cust_email_verified == TRUE)
かつ cust_phone_verified == TRUE
かつ email_domain_type == "free"
ルールのパフォーマンス
不正件数 | イベント数 | 精度 | 想起す |
296（-70） | 769（-1093） | 38.5%（+18.8%） | 20％（-4.7％） |
ご覧のとおり、リコールは約2割低下しましたが、精度は2倍に向上しており、いくつか調整を加えれば、このルールは本番環境にリリースできる水準になっています。
ルールのリリース準備
ルールのロジックが確定したら、本番環境で実際に稼働させる前に行うべきステップがあと2つ残っています。1つ目は、そのルール全体のパフォーマンスと、ビジネスへの期待される影響を承認することです。
承認申請を行う際にパフォーマンスを包括的に把握してもらうため、私は次の内容を共有します。
説明 | このルールは、顧客セグメントXに対する支払いのうち、IPアドレスの都道府県がユーザーの登録住所の都道府県と一致しないものを対象とします。 |
想定ヒット数／月 | 月間約1,250件の支払い |
精度：件数／量 | 38.5% / 39.6% |
リコール：件数／数量 | 20% / 20.2% |
毎月／毎年の損失削減額 | $80.5k / $966k |
FPR：件数／金額 | 0.1% / 0.1% |
毎月／毎年の損失収益 | 20万3,000ドル / 244万ドル |
これで承認担当のマネージャーが、私の申請を自信を持って承認するために必要な情報はすべて揃うはずです。
しかし、承認は戦いの半分にすぎません。次にやるべき2つ目のことは、ルール検証の全プロセスを完了することです。朗報なのは？ 6つあるステップのうち、今ちょうど最初のステップを完了したところです！