Stripe Radar は、お金が動いたその瞬間に取引をスコアリングする、という仕事を実に見事にこなします。しかし私たちの問題が潜んでいたのは、まさにお金が「動かない」瞬間でした。
私たちは7日間の無料トライアルを提供しています。トライアルを始めるとき、ユーザーはカードを登録しますが課金はされません。内部的には、これは決済ではなく Stripe の SetupIntent です。課金がなければ課金時のイベントも発生せず、つまり Radar の最も強力なルールは、最も重要な瞬間、すなわち不正アカウントが作成されトライアルのクレジットを消費し始めるその瞬間に、評価できるものが何もないのです。
これは、私たちが1対1のチャットで不正と火消し的に格闘していた状態から、自社プロダクトである Zero の上に構築した、分単位で動く自動化された不正対策レイヤーへとたどり着くまでの物語です。
Radar は優秀です。ただし「優秀」は「完璧」ではありません。
Stripe Radar は、その仕事において本当に優れています。年間 1兆ドル を超える決済ボリュームで学習したそのモデルは、過去に見たことのあるカードを 92% の確率で認識し、Stripe によれば Radar を利用する企業では 平均で不正を32%削減 しているとされています。
ただ、この数字をもう一度よく見てください。「削減」であって、「根絶」ではありません。平均32%の削減は大きな成果です。しかしそれは、依然として相当な割合の不正の圧力があなたの元に届いていることを意味します。そしてその理由について、Stripe は驚くほど正直です。彼ら自身の言葉を借りれば、「誤検知の数を減らすことは、より多くの本物の不正がすり抜ける可能性を高めることが多い」のです。漏れはモデルのバグではありません。本物の顧客をブロックしないために意図的に支払っているコストなのです。あらゆる不正対策チームは、どれだけの不正を通すかを、意図的に選択しているのです。
トライアル主導のプロダクトにとって、この漏れは見出しの数字が示唆するよりもさらに大きくなります。なぜなら、Radar の最も強力な部分はそもそも一度も動かないからです。
ゲートは「削減」しかできない理由
課金時のエンジンが不正を「削減」できても根絶できない、より深い理由があります。それは Stripe のモデルの問題ではなく、タイミングと情報 の問題です。カードが登録されたその瞬間、顧客はまだ何もしていません。サインイン履歴も、プロダクト上の行動も、学習すべき利用パターンもなく、あるのはカードと、わずかなネットワークシグナルだけです。Radar は、判断材料が最も少ないその唯一の瞬間に、考えうる限り最も薄い証拠の断片だけで最善の判断を下しているのです。
これが本当の限界です。ゲートはチューニングできますが、まだ存在しないデータを与えることはできません。不正利用者と顧客を実際に分けるための情報の大半は、ゲートが判断を下さなければならない時点よりも 後 に生まれるのです。
ステージ1：チャット画面での火消し
私たちの最初の対応は、完全に手作業でした。不正の波が押し寄せると、誰かがエージェントとの会話を開き、インシデントにその場で対処しました。最近のサインアップを引き出し、カードを確認し、パターンを見つけ、アカウントを手作業で停止する、という具合です。
これは機能しましたが、スケールしませんでした。どのインシデントもゼロから始まります。「この不正グループはどんな見た目か、どのシグナルが信頼できるか」といった知見は、一人の頭の中と一つのチャットスレッドの中だけに存在し、ウィンドウを閉じた瞬間に蒸発してしまいました。
私たちはファネルの 良い 側でも、高くついた教訓を学びました。チェックアウトを離脱した本物のユーザーを呼び戻そうとしたとき、不正なアドレス宛てに不用意なアウトリーチメールを送ることは、実害をもたらします。そのアドレスが生きていることを確認させてしまうのです。私たちが構築するどんな自動化も、本物の見込み客と、仕込まれた偽物とを見分けられなければなりませんでした。
ステージ2：Radar で玄関を固める
次に私たちが取った手は、可能な限りすべてを上流の Radar に押し込むことでした。カード登録の段階でのブロックリストとベロシティルールを、私たちが目にしていた圧力に合わせてチューニングしたのです。これは正しい最初の一手であり、最も粗雑な攻撃は止めることができました。
しかし、2つの限界がすぐに姿を現しました。1つ目は Stripe 自身が名指ししているものです。課金時のエンジンは壁ではなく トレードオフのダイヤル なのです。回し上げれば本物の顧客をブロックし、回し下げればより多くの不正がすり抜けます。2つ目は構造的で、トライアル特有のものです。あの32%は課金時に得られるものであり、SetupIntent によるトライアルにはスコアリングすべき課金が存在しないのです。 保存済みの支払い方法に対して明示的に Radar を有効化しない限り、エンジンはまったく動きません。そして動く場合でも、SetupIntent に適用されるのは Block、Allow、そして 3DS のルールだけです。人間に再確認の余地を与える「Review」アクションは、決して発火しないのです。
つまり、スタックの中で単体として最も成績の良いレイヤーが、デフォルトでは、私たちが最も必要とするまさにその瞬間に出番を欠席しているのです。Radar は玄関のゲートです。私たちが必要としていたのは、その奥を見回るパトロールでした。
ステージ3：Zero の上に築いた第2のレイヤー
サインアップの後、情報の構図は反転します。アカウントは痕跡を残し始め、その痕跡の最も豊かな部分は、決済処理業者が決して目にしないシステム、すなわち私たちの ID プロバイダーである Clerk の中に存在します。
そこで私たちは Zero にそれへのアクセスを与えました。Clerk は Stripe には知り得ないことを知っています。アカウントがどのように作成されたか、サインアップの方法とメールアドレス、その背後のセッションとデバイスの挙動、そしてその日の他のすべてのサインアップとの正確なタイミングです。Stripe はカードを知っています。どちらのシステムも単体では物語の全体を語りません。しかしエージェントは両方を読み取り、それらを横断して相関づける ことができます。ゲートの時点では見えない不正も、並べてみれば明らかになります。サインインの本人性が請求時の本人性と一致しない真新しいアカウントが、そっくりなアカウント群とほんの数瞬の差で作成されているのです。このシステムをまたいだ突合こそ、課金時のゲートには決して作れないものであり、まさに両方のシステムの上に立つエージェントにこそ作れるものなのです。
このより豊かな証拠の土台の上で、私たちは数分ごとに一連のスケジュール化された Zero タスクを、ライブのサインアップデータと請求データに対して実行しています。それらを形づくる3つの原則があります。
1. ゲートで留めず、パトロールする。 エージェントは一つの瞬間を評価するのではなく、短いループで最近のサインアップを残らず巡回し、アカウントデータと決済メタデータを相関づけて、玄関をすり抜けたアカウントを浮かび上がらせます。
2. 確信度に応じて対応を段階づける。 すべてのシグナルが同じアクションに値するわけではありません。確信度の高いパターンは自動で処理されます。アクションが取り消し可能であり、待つことのコストが現実のものであるため、アカウントは即座に停止され、そのトライアルはその場でキャンセルされます。確信度の低いシグナルは決して自動でアクションされることはなく、人間がレビューするためのレポートに集約されます。安全なところでは決然と、そうでないところでは慎重に、というわけです。
3. 人間が監査できる証跡を残す。 すべての自動アクションは、それを引き起こした正確なシグナルを記録するので、数秒でレビューし、取り消すことができます。監査できない自動化は、信頼できない自動化です。
私たちは、ファネルの友好的な側にも同じ厳格さを適用しました。別のタスクが、本物の「チェックアウトを離脱した」ユーザーを見つけ出し、人間が承認するための呼び戻しメールを 下書き します。これは、私たちが決して不正なアドレスを有効化してしまわないよう、意図的に重めの不正フィルターの背後で行われます。同じエンジンで、目的は正反対です。
経済性にもたらした変化
パトロールが稼働すると、数字はただちに動きました。90パーセンタイルのサインアップ、つまり本当に損害を与えた重いアカウントを見てください。そのうちの1つが最初の数時間で消費したトライアルの計算コストは、約4ドルから約0.25ドルへ、94%の削減 となりました。同じ期間のすべての新規サインアップで平均すると、アカウントあたりの損失は おおよそ85% 減少しました。
この変化の「形」こそが、すべてを物語っています。ほとんどのサインアップは私たちに何のコストももたらしません。損失は常に、トライアルのクレジットを枯渇させるためだけに存在する、長く重いテール（裾野）のアカウントに集中していました。パトロールはファネルを縮めたのではなく、そのテールを切り落としたのです。サインアップが減ったのではありません。よりクリーンになったのです。
なぜスクリプトではなくエージェントなのか
私たちは cron ジョブを書くこともできました。そうしなかった理由は一つです。脅威はリリースサイクルよりも速く変化するからです。 攻撃者が手口を変えたとき、私たちはタスクの指示を平易な言葉で更新し、新しいロジックは次の実行で稼働します。デプロイも、スキーマのマイグレーションも、チケットも不要です。「ルール」はプロンプトであり、プロンプトは攻撃者と同じ速さで変更できるのです。
これが本当の教訓です。Radar は課金時のリスクに対する正しいツールであり、私たちはそれに大きく頼っています。しかし、トライアル主導のビジネスには、いかなる課金時のツールでもカバーできない構造的な死角があります。そしてその解決策は、より大きなルールエンジンではありません。脅威の速さに合わせて再プログラムできる、速くて、監査可能で、常時稼働する第2のレイヤーなのです。
トライアル主導のチームへの示唆
- 課金のない瞬間をマッピングする。 ユーザーが決済をスコアリングされる前に価値を得られる場所はどこであれ、課金時のツールには見えない穴です。
- 置き換えるのではなく、重ねる。 Radar は玄関に置いたままにする。その奥に、サインアップ後の継続的なパトロールを追加する。
- システムをまたいで突合する。 決済処理業者と ID プロバイダーは、それぞれ全体像の半分ずつを握っています。不正はその重なりの中に見えてきます。
- アクションを確信度で段階づけ、そのすべてを記録する。 アクションが取り消し可能でシグナルが強いところでのみ自動対応し、それ以外は人間に回す。
- 適応の速さを最適化する。 不正対策では、ルールを最も速く変えられるチームが勝ちます。
常時稼働するエージェントが、あなた自身のスタックで何を自動化できるか気になりますか？Zero を試す。
注：Radar の数値は Stripe が公開している自社の数字です（stripe.com/radar、「A primer on machine learning for fraud detection」）。損失の数値は、登録後最初の数時間における新規サインアップあたりの計算コストを反映しており、ローンチ前後の対応する期間で測定し、内部アカウントは除外しています。ローンチ後のサンプルはまだ初期段階であり、時間の経過とともに精度が高まっていきます。
