Stripe Radar 在它擅長的領域表現出色：在金流發生的瞬間對交易進行評分。但問題恰恰出在金流沒有發生的那一刻。
我們提供 7 天免費試用。使用者開始試用時需要綁定一張信用卡，但不會被收費——在底層，這是一個 Stripe SetupIntent，而非付款請求。沒有扣款，就沒有扣款時間點的事件，也就意味著 Radar 最強大的規則，在最關鍵的時刻根本無從發揮：當一個詐欺帳號正在被建立、開始消耗試用額度的那一刻。
這篇文章記錄了我們如何從每次事件都要手動救火，演進到在自家產品 Zero 上建立一套自動化、每分鐘持續運作的詐欺防護層。
Radar 很好用，但「好用」不等於「完美」
Stripe Radar 確實在它的領域做得很好。它的模型基於超過每年 1 兆美元的支付量訓練而成，能以 92% 的準確率識別曾經出現過的信用卡，Stripe 也表示 Radar 平均能為使用它的企業減少 32% 的詐欺損失。
但請再看一次這個數字：是減少，不是消除。平均減少 32% 已經相當可觀——但這也意味著仍有相當大比例的詐欺壓力持續湧入，而 Stripe 對此坦誠以告。他們自己說：「減少誤判的同時，往往會提高真實詐欺漏網的機率。」 漏網不是模型的缺陷，而是為了不誤擋真實客戶所刻意付出的代價。每個詐欺防護團隊都在有意識地選擇放行多少風險。
對於以試用為核心的產品而言，這個漏洞比表面數字所呈現的還要大——因為 Radar 最強大的部分根本不會啟動。
為什麼關卡只能「減少」，而無法「終結」
扣款時間點的引擎之所以只能減少詐欺而無法根絕，有更深層的原因，這與 Stripe 的模型無關，而在於時機與資訊。在信用卡被加入的那一刻，使用者還什麼都沒做。沒有登入紀錄、沒有產品行為、沒有使用模式可供學習——只有一張卡和少量網路訊號。Radar 在資訊最匱乏的時刻，用最薄弱的證據做出最佳判斷。
這就是真正的天花板。你可以調整關卡的靈敏度，但你無法給它尚未存在的資料。真正能區分濫用者與真實客戶的資訊，大多是在關卡做出決定之後才產生的。
第一階段：在對話視窗裡救火
我們最初的應對方式完全是手動的。每當一波濫用攻擊來襲，就有人打開與 Agent 的對話，即時處理事件：拉出近期的註冊紀錄、查看信用卡資訊、找出規律、手動停用帳號。
這個方法有效，但無法擴展。每次事件都要從零開始。那些知識——這個詐欺環長什麼樣、哪些訊號可靠——只存在於某個人的腦袋和某個對話串裡，視窗一關就消失了。
我們也在漏斗的「好」的那一側學到了一個代價高昂的教訓：當我們想要挽回真正放棄結帳的使用者時，若不小心將開發信寄到詐欺地址，反而會造成實質傷害——這等於確認了那個地址是有效的。我們建立的任何自動化流程，都必須能區分真實潛在客戶與植入的假帳號。
第二階段：用 Radar 強化前門
我們的下一步是盡可能將防護推到上游，在信用卡綁定步驟加入 Radar 的封鎖名單和速率規則，並根據我們觀察到的攻擊壓力進行調整。這是正確的第一步，也確實阻擋了最粗糙的攻擊。
但很快就出現了兩個天花板。第一個是 Stripe 自己也承認的：扣款時間點的引擎是一個取捨的調節旋鈕，而不是一道牆——調緊了會擋住真實客戶，調鬆了又會讓更多詐欺漏網。第二個是結構性問題，且是試用模式特有的：那 32% 的成效是在扣款時間點取得的，而 SetupIntent 試用根本沒有扣款可供評分。 除非你明確為已儲存的付款方式啟用 Radar，否則引擎根本不會運作——即使啟用了，SetupIntent 上也只有封鎖、允許和 3DS 規則適用。「審查」動作——也就是讓人工多看一眼的那個——永遠不會觸發。
因此，整個防護堆疊中表現最好的那一層，在預設情況下，恰恰在我們最需要它的時刻缺席了。Radar 是前門的關卡，我們需要的是在它身後的巡邏。
第三階段：在 Zero 上建立第二道防線
註冊之後，資訊的面貌翻轉了。帳號開始留下足跡——而這些足跡中最豐富的部分，存在於支付處理器永遠看不到的系統裡：我們的身份驗證服務提供商 Clerk。
於是我們讓 Zero 存取 Clerk 的資料。Clerk 知道 Stripe 不知道的事：帳號是如何建立的、註冊方式與電子郵件、背後的 Session 與裝置，以及相對於當天其他所有註冊的精確時間點。Stripe 知道信用卡資訊。兩個系統各自都無法呈現完整的故事——但 Agent 可以同時讀取兩者，並跨系統進行關聯分析。在關卡處看不見的濫用行為，並排比對後就變得一目了然：一個全新帳號的登入身份與帳單身份對不上，而且是在一群外觀相似的帳號中，在幾分鐘內接連建立的。這種跨系統的關聯，正是扣款時間點的關卡做不到的——也正是一個同時坐落在兩個系統之上的 Agent 能做到的。
基於這個更豐富的證據基礎，我們每隔幾分鐘就對即時的註冊和帳單資料執行一組 Zero 排程任務。三個原則塑造了這套機制：
1. 巡邏，而不只是把關。 Agent 不是評估單一時間點，而是以短週期掃描所有近期的註冊，關聯帳號資料與付款元資料，將漏過前門的帳號浮出水面。
2. 依信心程度分級回應。 不是每個訊號都值得相同的處置方式。高信心的模式會自動處理——帳號立即被停用、試用資格立即取消，因為這個動作是可逆的，而等待的代價是真實的。信心較低的訊號絕不會自動處置，而是彙整成報告供人工審查。在安全的地方果斷行動，在不確定的地方保持謹慎。
3. 保留人工可查核的稽核軌跡。 每一個自動化動作都記錄觸發它的確切訊號，以便在幾秒內完成審查——或撤銷。無法稽核的自動化，就是無法信任的自動化。
我們對漏斗友善的那一側也採用了同樣嚴謹的態度。一個獨立的任務會找出真正放棄結帳的使用者，並草擬一封挽回信供人工審核——背後設有刻意嚴格的詐欺過濾器，確保我們絕不會驗證一個無效地址。相同的引擎，相反的目標。
對業務數字的影響
巡邏機制上線後，數字立即出現變化。看看第 90 百分位的註冊帳號——那些造成最大損失的重度帳號。其中一個帳號在開始後幾小時內消耗的試用運算成本，從約 4 美元降至約 0.25 美元——下降了 94%。 以同一時間窗口內所有新註冊帳號的平均值來看，每個帳號的損失下降了約 85%。
這個變化的形態說明了一切。大多數註冊帳號從來不會讓我們損失任何東西；損失始終集中在一條又長又重的尾巴上，那些帳號存在的唯一目的就是榨乾試用額度。巡邏機制沒有縮小漏斗——它切斷了那條尾巴。不是更少的註冊，而是更乾淨的註冊。
為什麼選擇 Agent，而不是寫腳本
我們本可以寫一個 cron job，但我們沒有，原因只有一個：威脅的演變速度快過一個發布週期。 當攻擊者改變戰術，我們用自然語言更新任務的指令，新邏輯在下一次執行時就生效——不需要部署、不需要資料庫遷移、不需要開票。「規則」就是一個 Prompt，而 Prompt 的修改速度和攻擊者一樣快。
這才是真正的啟示。Radar 是處理扣款時間點風險的正確工具，我們也充分仰賴它。但以試用為核心的業務有一個結構性盲點，是任何扣款時間點的工具都無法覆蓋的——解決方案不是一個更大的規則引擎，而是一個快速、可稽核、永遠在線的第二道防線，讓你能以和威脅同等的速度重新設定規則。
給以試用為核心的團隊的建議
- 找出你的無扣款時間點。 任何使用者在付款被評分之前就能獲得價值的地方，都是扣款時間點工具看不到的缺口。
- 分層疊加，而非取代。 保留 Radar 在前門的位置，在它身後加入持續的註冊後巡邏。
- 跨系統關聯。 你的支付處理器和身份驗證服務提供商各自掌握了一半的資訊，詐欺就藏在兩者的交集裡。
- 依信心程度分級處置，並記錄每一個動作。 只在動作可逆且訊號強烈時自動執行；其餘的交由人工處理。
- 以適應速度為優化目標。 在詐欺防護領域，能最快改變規則的團隊才能贏。
想知道一個永遠在線的 Agent 能在你的技術堆疊中自動化哪些事？探索 Zero。
備註：Radar 相關數據均來自 Stripe 官方公開資料（stripe.com/radar；「A primer on machine learning for fraud detection」）。損失數據反映的是每個新帳號在註冊後最初幾小時內的運算成本，以上線前後的對應時間窗口進行比較測量，並已排除內部帳號；上線後的樣本仍處於早期階段，數據將隨時間趨於穩定。
