Stripe Radar 在它的專長領域表現優異：當金錢流動時即時評分交易。但當金錢沒有流動時，問題就出現了。
我們提供 7 天免費試用。啟動時，使用者只需儲存信用卡，卻不會被收費——實際上這是 Stripe 的 SetupIntent，而不是付款。沒有收費就沒有收費時事件，也就是說 Radar 最強大的規則在最關鍵的時刻——當詐欺帳號被建立並開始消耗試用點數時——完全無法發揮作用。
這就是我們如何從一對一聊天中臨時處理詐欺，進化到每分鐘自動運作的詐欺防護層——而且是建立在我們自家產品 Zero 之上的故事。
Radar 很棒，但「很棒」不等於「完美」
Stripe Radar 在它的領域確實表現出色。它的模型訓練於每年超過 $1 兆美元的支付量，能夠在 92% 的情況下識別曾經見過的信用卡，Stripe 也報告 Radar 平均可減少 32% 的詐欺。
但請再看一次這個數字：減少，不是消除。32% 的平均減少幅度很大——但這代表仍有大量詐欺壓力會落到你身上，而 Stripe 也坦率說明原因。用他們自己的話說，「減少誤判通常會增加真正詐欺漏網的機率。」 漏網不是模型的錯誤，而是為了不阻擋真正客戶所付出的代價。每個詐欺防護團隊都在有意識地決定要放行多少。
對於以試用為主的產品來說，這個漏洞比表面數字更大——因為 Radar 最強大的部分根本沒有運作。
為什麼閘門只能減少，無法根除
收費時引擎能減少詐欺但永遠無法根除，背後有更深層的原因，這不是 Stripe 模型的問題——而是時機與資訊的問題。在卡片剛被新增的那一刻，客戶什麼都還沒做。沒有登入紀錄、沒有產品行為、沒有可學習的使用模式——只有一張卡片和少數網路訊號。Radar 必須在證據最薄弱、資訊最少的時刻做出最佳判斷。
這就是極限。你可以調整閘門，但無法給它還不存在的資料。真正能區分濫用者與正常客戶的資訊，大多是在閘門已經做出決定之後才產生的。
第 1 階段：在聊天視窗裡滅火
我們最初的應對方式完全是人工處理。當一波濫用來襲時，有人會打開與我們智能體的對話，現場處理事件：拉出最近註冊名單、檢查卡片、找出模式、手動關閉帳號。
這方法有效，但無法擴展。每次事件都要從零開始。知識——這個詐欺集團長什麼樣、哪些訊號可靠——只存在於某個人的腦中和一個聊天紀錄裡，視窗一關就消失了。
我們也在漏斗的「好」那一端學到一個昂貴的教訓：當我們想挽回真正放棄結帳的用戶時，隨便寄信到詐欺信箱會造成實質傷害——這等於確認了該信箱有效。任何自動化都必須能分辨真正潛在客戶與假冒者。
第 2 階段：用 Radar 強化前門
接下來我們盡可能把所有能做的事前移到 Radar——在新增卡片時設置黑名單和速度規則，根據當時的壓力調整。這是正確的第一步，也擋下了最粗糙的攻擊。
但很快就遇到兩個天花板。第一個就是 Stripe 自己說的：收費時引擎是一個權衡旋鈕，不是一道牆——調高會擋掉真正客戶，調低則更多詐欺漏網。第二個則是結構性、專屬於試用： 32% 是在收費時才產生，而 SetupIntent 試用根本沒有收費可評分。 除非你明確啟用 Radar 於儲存的付款方式，否則這個引擎根本不會運作——即使有運作，在 SetupIntent 上也只有 Block、Allow 和 3DS 規則會生效。「Review」這個讓人類二次審查的動作，永遠不會觸發。
所以這個堆疊中表現最好的防線，在我們最需要的時刻預設是缺席的。Radar 是前門的閘門。我們需要的是後門的巡邏。
第 3 階段：用 Zero 建立第二層防線
註冊後，資訊全貌就翻轉了。帳號開始留下痕跡——而這些最豐富的痕跡存在於支付處理商看不到的系統：我們的身份驗證服務 Clerk。
所以我們讓 Zero 取得存取權。Clerk 知道 Stripe 不知道的事：帳號如何建立、註冊方式與信箱、背後的 session 與裝置，以及與當天其他註冊相比的精確時機。Stripe 只知道卡片。兩個系統各自都無法拼湊全貌——但智能體可以同時讀取並跨系統關聯。在閘門看不到的地方，濫用行為並排就變得明顯：一個全新帳號的登入身份與帳單身份不符，且與一群相似帳號幾乎同時建立。這種跨系統比對正是收費時閘門做不到的——但坐在兩個系統之上的智能體卻能做到。
基於這更豐富的證據，我們每隔幾分鐘就用 Zero 執行一組排程任務，針對即時註冊與帳單資料進行分析。三個原則主導這些任務：
1. 巡邏，而不只是設閘門。 智能體不是只評估單一時刻，而是以短迴圈掃描所有近期註冊，關聯帳號資料與付款元資料，找出那些溜過前門的帳號。
2. 依信心分級回應。 不是每個訊號都該有同樣處理。高信心模式自動處理——帳號立即停權、試用立即取消，因為這動作可逆且等待的代價很高。低信心訊號絕不自動處理；它們會彙整成報告給人類審查。安全時果斷，不安全時保守。
3. 保留人類稽核紀錄。 每個自動化動作都記錄觸發它的精確訊號，方便隨時審查與還原。無法稽核的自動化就無法信任。
我們對漏斗友善那一端也同樣嚴謹。另一個任務會找出真正的放棄結帳用戶，草擬一封挽回信給人類審核——背後有刻意嚴格的詐欺過濾，確保我們永不驗證壞信箱。相同引擎，不同目標。
對經濟效益的影響
巡邏一上線，數字立刻有感。看看第 90 百分位的註冊——那些真正造成損失的重度帳號。這些帳號在頭幾小時消耗的試用運算量，從約 $4 降到約 $0.25——減少了 94%。 同期所有新註冊的平均每帳號損失也大約下降 85%。
變化的型態說明了一切。大多數註冊對我們沒有成本；損失總是集中在那條又長又重的尾巴——那些只為消耗試用點數而存在的帳號。巡邏沒有縮小漏斗——而是砍掉了那條尾巴。註冊數沒變少，品質變乾淨了。
為什麼用智能體，而不是寫腳本
我們本可以寫個排程腳本。但我們沒這麼做，只有一個原因：威脅變化比發佈週期還快。 當攻擊者改變手法時，我們只需用自然語言更新任務指令，下一次執行就會套用新邏輯——不用部署、不用資料庫遷移、不用開工單。「規則」就是提示詞，提示詞能跟攻擊者一樣快變動。
這才是真正的啟示。Radar 是處理收費時風險的最佳工具，我們也高度依賴它。但以試用為主的業務有一個結構性盲點，任何收費時工具都無法覆蓋——解方不是更大的規則引擎，而是能以威脅速度重編程、可稽核、永遠在線的第二層防線。
給以試用為主團隊的建議
- 盤點你的無收費時刻。 任何用戶在付款被評分前就能獲得價值的地方，都是收費時工具看不到的缺口。
- 疊加，不取代。 保持 Radar 守在前門。後面再加一層持續的註冊後巡邏。
- 跨系統關聯。 你的支付處理商和身份驗證服務各掌握一半資訊。詐欺行為就在重疊處現形。
- 依信心分級行動，並記錄每一次。 只有在動作可逆且訊號強時自動處理；其餘交給人類。
- 優化規則調整速度。 在詐欺防治上，能最快改規則的團隊才會贏。
想知道永遠在線的智能體能自動化你堆疊中的哪些流程？探索 Zero。
註：Radar 數據來自 Stripe 官方公開資料（stripe.com/radar；「A primer on machine learning for fraud detection」）。損失數據為註冊後頭幾小時每新註冊帳號的運算成本，於上線前後相同時間區間測量，排除內部帳號；上線後樣本仍在早期，未來會更穩定。
