不正対策チームは必ずまずルールから始めますが、それにはきちんとした理由があります。ルールはすばやく作成でき、直感的に理解しやすく、目の前で起きている事象に直接対応できるからです。
しかし、ビジネスが成長すると、ルールの限界はすぐに明らかになります。これによりオペレーションが複雑になり、戦略をスケールさせることがはるかに難しくなります。
地域ごと、決済手段ごと、プラットフォームごと、そして顧客セグメントごとに、それぞれ固有のリスクプロファイルが存在します。チームはその異なるリスクプロファイルを目にして、慣れたやり方を取ります――つまり、ルールを増やすのです。多くの場合、それは高まる複雑性に対するその場しのぎの対処になります。ヨーロッパ向け決済の新しいルール。モバイル向けの更新されたしきい値。B2B顧客向けの新しいベロシティチェック。
そしてしばらくの間はうまくいきます。うまくいかなくなるその時までは。
リスクプロファイルだけが、そうしたさまざまな側面で変化するわけではありません。関係するベンダーも変わります。適切な認証フローも変わります。利用可能な基盤データそのものも変わっていきます。
さまざまなリスクレベルごとにルールを設定することはできますが、「ドイツのB2B顧客にはこのKYBベンダーを使い、新しいデバイスからの高額取引には3DSをトリガーし、既に検証済みの定期利用ユーザーにはエンリッチメントをスキップする」といったルールを書くことはできません。
そこでルールの限界が来ます。そして、そこでワークフローレイヤーが登場します。
不正検知ルールとワークフローの違い
これから説明する多くの問題の原因は、この2つの用語が混同されていることにあります。ですので、まずはこの2つの用語をはっきりと定義しておきましょう。
ルールとは戦術を実行するものです。その状況において特定の行動を検知したりブロックしたりするために、特定のシグナルを評価します。
ワークフローは一方で、不正防止戦略を実行するものです。どの取引やユーザーがどのグループに属するのか、どのチェックを適用するのか、どのベンダーを呼び出すのか、そして結果としてどのようなアクションが取れるのかを決定します。
要するに、それはより良いセグメンテーション、より良いルーティング、そしてより良い意思決定のための運用環境を作り出します。
実際には次のようになります。
あるルールは次のように述べています：「デバイスが新しく、IPアドレスが高リスク国にある場合は、この取引にフラグを立てなさい。」
ワークフローは次のように述べています：「500ドルを超える支払いを行う新規ユーザーは、強化された審査を受けます。具体的には、本人確認の拡充サービス提供者に連絡し、デバイスインテリジェンスを実行し、そのうえで不正の兆候を評価します。」
ワークフローが舞台を整え、ルールがその上で動く。どちらか一方だけでは機能しない。
その中に明確なルールがなければ、ワークフローは高度なルーティングに過ぎず、ユーザーは何にも実際に触れることなくレーンの中を移動しているだけです。
ワークフローの文脈を持たないルールは、全体のユーザーに一律に適用され、一部のセグメントでは不正を検知する一方で、他のセグメントではノイズを生み出してしまいます。
実際に検知ルールを作成し、改善を重ねていく手順を詳しく知りたい場合は、この投稿で、実際の事例を最初から最後まで通して解説しています。
ルール | ワークフロー | |
実装 | 戦術 | 戦略 |
評価する | 火災発生時に存在する信号 | 人口、状況、ベンダーのニーズ |
と連携 | シグナルとしきい値 | ベンダー、認証システム、下流のアクション |
変更の範囲 | 検知ロジック（不正対策チームが管理） | コスト、UX、不正対策（部門横断的） |
不正対策ワークフローは、単に振り分けるだけのものではありません
基本的な違いを理解しているチームでさえ、ほとんどのチームが見落としているのはここです。
ワークフローは、単にユーザーを分類して別々の経路に振り分けるだけのものではありません。外部の処理ステップを呼び出し、追加データを収集し、セッションを終了させることなく評価を継続することで、全体のプロセスを統合的に制御します。
トランザクションが発生すると、ワークフローはアイデンティティエンリッチメントベンダーに問い合わせてレスポンスを待ち、その後デバイスインテリジェンスプロバイダーを呼び出すことができます。そして、そこで得られた情報に基づいて、3DSチャレンジを発動するか、バイオメトリクスによるステップアップ認証を行うか、あるいはそのまま不正検知ルールの評価に進むかを判断できます。
これらすべては処理の途中で動的に行われ、最終的な判断が下される前に実行されます。
ルールにはこれはできません。ルールは、発動した時点ですでに存在しているシグナルだけを評価します。追加のデータを取りに行くことも、セッションを開いたままにしておくことも、得られた結果に応じて条件付きで認証をトリガーすることもありません。
これこそが、ワークフローを戦略レイヤーたらしめている点です。誰をチェックするかだけでなく、どのようにチェックするのか、どのツールをどの順番で、どの対象グループに対して使うのかまで決定します。
その後、ルールが強化され、完全に特徴付けられたイベントに対して検知を行います。
また、これは両方のレイヤーがまったく異なる統合インターフェースを持つことも意味します。ルールはシグナルとやり取りし、ワークフローはベンダー、認証システム、そして下流のアクションとやり取りします。
ワークフローとルールを混同したり（あるいはすべてをひとつの仕組みに通そうとしたり）するところから、運用の複雑さが雪だるま式に増え始めます。
なぜ一方を無理やりいじって、もう一方の代わりにさせることはできないのか？
チームがそれを試してみることは時々あります。ですが、たいていは次のような結果になります。
ワークフローをルールで置き換える：技術的には可能です。集団（ユーザー層）のコンテキストを、そのままルール条件に組み込みます。
もし new_user かつ payment > $500 かつ region = EU かつ segment = consumer の場合、〜する。
これらをすべてつなぎ合わせることの問題は、各ルールがそれぞれ独自の文脈を持っているという点です。顧客セグメントが3つ、地域が6つ、支払い方法が16種類になるまではうまく機能するかもしれませんが、その先は難しくなります。
組み合わせが爆発的に増えることが、ルールセットの肥大化という問題を引き起こします。
しかし、より重要なのは、そのどれもベンダーオーケストレーションの課題を解決していないということです。ルールは依然として、セッションの途中でKYBプロバイダーを呼び出したり、3DSフローをトリガーしたり、エンリッチメントのレスポンスを待つ間イベントを保留したりすることができません。
ルーティングの問題は「ハック」して何とかしましたが、オーケストレーションの問題はまったく解決されていません。
ルールを置き換えるワークフロー：これは別の形で失敗します。理論上は、各ノードに単一の検知ロジックを持たせたノードを順番につないで、ワークフローの分岐を作成することができます。
これは有効な場合もありますが、すぐに管理が非常に難しくなります。シミュレーションは、ロジックが並列ではなく順番に実行されるため誤解を招く可能性があり、異なる「ルール」同士の重なりに気づきにくくなります。
これは、ワークフローが非常に肥大化してしまい、戦略を監視し、全体を統制することがより難しくなるということでもあります。
しかし何より重大なのは、深刻なオペレーションリスクを生むことです。新しいルールを試したり、バージョンを更新したりするたびに（それは頻繁に起こり得ます）、ワークフロー全体を危険にさらすことになります。
ルールに誤った値を設定すると、不正を見逃すだけでなく、ワークフローが体現しているプロセス全体を崩壊させてしまう可能性があります。
リアルタイムの不正検知に、本当にワークフローは必要ですか？
よくこんな相談を受けます：「私たちは決済プロセッサーです。複雑なオンボーディングフローはなく、すべてがリアルタイムで処理されています。本当にワークフロー層は必要なのでしょうか？」
はい。その理由を説明します。
リアルタイムのイベントを異なるセグメントに振り分けることは、たいていの場合、よりシンプルなユースケースであるのは確かです。多少ぎこちなくはあっても、ルールだけで対応できるものです。そうした例は、誰もがこれまでに目にしてきたはずです。
しかし、私たちに欠けているのはオーケストレーションの部分です。
こう考えてみてください。ある出来事のリスクが高くなればなるほど、私が負う財務上のリスクも大きくなります。そして、そのリスクが高くなればなるほど、より正確な判断のために投資してもよいと思える額も大きくなるのです。
この原則はさまざまな形で現れることがあります。例えば、次のようなものです。
- 500ドルを超える支払いは、より高価なデータエンリッチメントパイプラインに回されます。
- 高いモデルスコアを持つ支払いは、第2段階のモデルにルーティングされます。このモデルは、対象となる利用者の一部に対してはSLAを低下させている可能性がありますが、はるかに高い精度を備えています。
- 高額残高のあるアカウントへのログインは、強力な2要素認証フローに回されます。
ご覧のとおり、これらのユースケースは検知ロジックや、どのしきい値を適用するかといった点が主題ではありません。このイベントをどのパイプラインに通すのか、そしてそのコストをどうするのかが重要なのです。
ワークフロー層がなければ、すべてのケースに対して同じパイプラインを実行することになります。つまり、不正防止に過剰なコストをかけているか、最もリスクの高いイベントのチェックが不十分になっているかのどちらかです。
たいていは両方が、場所によって違って現れます。
リアルタイムであることは、一様であることを意味しません。ワークフロー層は、適切なベンダーへのルーティング、適切な認証のトリガー、適切なルールセットの適用など、イベントが求める速度で、そのような対象集団の複雑さを同一セッション内で管理します。
リアルタイムの文脈でワークフローを省略したくなる本能的な発想は、多くの場合、ワークフローをバッチ処理やオンボーディングのための仕組みとして捉えていることに起因します。
そうではありません。ワークフローは、どれだけ高速に発生するイベントであっても、あらゆるイベントの前提となる運用コンテキストなのです。
不正対策のワークフローに関する意思決定には、誰がその場にいる必要があるのか
ワークフローは複雑さを管理するために設計されていますが、同時に組織に新たな複雑さも生み出してしまいます。
それを説明するために、まずはルールを確認してみましょう。
新しい不正検知ルールは、あなたの検知ロジックを変えます。ステークホルダーは不正対策チームです。彼らは新しい攻撃パターンを見つけ、ルールを書き、テストし、本番に反映します。サイクルは速く、影響範囲は限定され、最初から最後まで自分たちで責任を持ちます。バックテスト、シャドーモードでの検証、本番環境でのモニタリングまで含めた、ルールリリース全体のプロセスについては、こちらのブログで詳しく解説しています。
ワークフローの変更はまったく別の話です、しかも同時に複数の話し合いが必要になることが多いのです。
ワークフローの分岐で、どのベンダーを呼び出すかを変更すると、それだけでコストに関する意思決定になります。ベンダーへの呼び出しには取引ごとの手数料が発生し、ある程度のボリュームになるとすぐに積み上がっていきます。これはオペレーションと財務の両方に関わる話です。
ワークフローが特定の顧客セグメントに対して 3Dセキュア（3DS）認証を要求するか、生体認証によるステップアップを要求するかを変更すると、その人たちのユーザー体験そのものが変わります。これはプロダクトの観点で語るべきテーマです。
ルーティングロジックそのものを変更することは、どの顧客をどの分岐に通すかを変えることであり、そのセグメントに対する不正対策の姿勢も変わるということです。これは不正対策チームの判断ですが、不正対策にとどまらないビジネス上の影響を伴います。
重要なのはここです。ワークフローの変更は、不正対策、プロダクト、オペレーション、そして時には財務までもが交わる地点にあります。すべてのチームの足並みがそろわないまま動かしてしまうと、善意の変更であっても、思わぬベンダーコストの増加や顧客体験の悪化、カバレッジの抜け漏れといった問題を生み出してしまいます――しかも、その三つが同時に起こることさえあるのです。
とはいえ、組織がスケールしていくうえで複雑さを完全に避けることはできません。
二つのレイヤー、ひとつのスタック
ルールによって、あらゆる不正対策チームは今のレベルまで到達しました。ルールがなくなることはありませんし、なくすべきでもありません。しかし、ルールだけでは到達できる限界があります。
そして、その限界は検知精度そのものというよりも、むしろ複雑さに起因しています。ビジネスが複数の地域、決済手段、プラットフォーム、あるいは顧客セグメントにまたがった瞬間、あなたは本来ルールだけで対処するようには設計されていない文脈で事業を運営していることになるのです。
ベンダーのルーティング、認証オーケストレーション、顧客層のセグメンテーション――これらはワークフロー層に属するものです。2つのレイヤーは競合関係ではありません。ワークフローが戦略を実行し、ルールが戦術を実行するという形で、スタックとして機能します。どちらのレイヤーも、もう一方にはできない役割を担っています。
ルールはリスクを検知し、ワークフローが対応を決定する。
簡単に言えば、ルールは不審な行為を不正対策チームが検知するための仕組みであり、ワークフローはその対応を実行に移すための仕組みです。ルールはシグナルやしきい値を評価します。ワークフローは、その情報をもとにレビューへのエスカレーション、認証のトリガー、外部ベンダーへの連絡、承認、ブロックなど、何を行うかを決定します。ですから、チームに投げかけるべき問いは「ルールとワークフローのどちらを使うべきか？」ではなく、「自社のワークフロー層は本当に自社ビジネスの複雑さを反映できているのか」という点です。そして、各分岐の中にあるルールは、その特定のユーザー層に合わせて適切に調整されているでしょうか？
もし今でも地域差や顧客セグメンテーション、ベンダーの振り分けをルール条件や例外ロジックで管理しているのであれば、すでに限界に達しているということです。
まだ名前を付けていないだけかもしれません。
