搭建風控系統道路上踩過的坑（3）-阻斷風險

01-30

本系列的上一篇文章搭建風控系統道路上踩過的坑02-風險分析，我們介紹了在採集信息後如何去分析這些數據產出風險事件，而產出的報警已經脫離了業務系統並不能被採用的。

說白了：分析出來的東西不能光自己看著High，還得去阻攔這些風險才能真正產生業務價值。

在開始前，我們還是回顧下業務風控主要做的四件事：

1、拿到足夠多的數據

2、做足夠靈活的分析平台去分析數據

3、產出風險事件進行阻攔風險

4、量化風險攔截的價值和不斷分析案例進行策略優化

到了第三步我們離整個系統核心框架的搭建就只剩一步之遙了，那麼讓我們看看這個環節要考慮什麼：

1、最終呈現給業務研發直白的判定結果

我們最終從數據中發現的報警和問題最終是要在業務邏輯中去阻攔的，在接入這些結果的時候，往往分析師覺得可以提供的信息有很多，比如命中了什麼規則、這些規則是什麼、什麼時候命中的、什麼時候過期，其中最讓接入方心煩的當屬風險分值當仁不讓了，很多接入風控的研發看到這些分值就一腦袋包：

你到底想讓我做什麼，攔還是不攔？這時候如果你喏喏的再丟出個多少分值以上要攔，研發多半都會跟你說直接給我結果就好了。

是的，很多風控介面設計的都十分累贅，無用信息多到研發會覺得你在故意浪費帶寬，其實一個code list給他們說明對應希望做的操作就好，一定把你覺得那些很牛逼的中間結果等等包裝成最終結果再給出去。

2、T＋0還是T＋1

舉個例子來解釋實時(T+0)和非同步（T＋1）風險判斷的區別。

T+1
你在打拳擊比賽，選手A只會打臉，上來就照著你臉來了一拳，你分析了一下打臉很疼而且不科學，在第二拳往臉揮過來時你突然告知對方不可打臉，對方就成功的被你剋制住了。這就是T+1的特點，至少要在第二次風險攻擊才可以生效；

T＋0
拳擊比賽第二場對陣選手B，同樣被打臉後你說不可打臉，對方說好，結果沖著肚子就來了一拳。你說禁止打肚子，對方又一拳打腋下。這時你發現要在對方揮拳馬上打到你之前就要禁止。
這就是T＋0了。

因為T＋0在接入的時候要額外承擔很多計算成本，結果要現場算出來而延時要求又很高，所以一般都只在攻擊者得手關鍵步驟採取實時判斷（比如訂單支付或者提現請求）。而對於其他場景可以選擇T＋1方式，比如登錄或者提交訂單等。

3、阻斷邏輯到阻斷產品

這一點我們豈安在對外演講的時候介紹過很多，在阻斷風險的時候事件發生的點是不同的，但短期又不可能讓業務研發在所有的地方接入風險阻斷怎麼辦？

所以我們需要考慮幾個基本的保底措施，比如統一的驗證碼驗證頁面在IP層全局防止任何爬蟲腳本行為，在賬號層通過登錄態管理統一攔截單個賬號在登錄後任何風險行為（全局強制登出）。

可能這些措施在體驗上不是最好的，但是在發生特殊問題的時候要等研發給你臨時加阻斷邏輯這個時間就沒法控制了。

坑位

1、接入風控阻斷的邏輯位置

登錄的時候賬號輸入框滑鼠失焦就要去走風控了，登錄結果出來之後再去判斷就沒意義，而資金相關的一般是在跳轉去收銀台之前，你會發現一般風險判斷都是在結果出來之前（收集本次行為完整日誌之前），所以如果你要做T+0判斷，就要求研發在進行風險判斷的時候要提供更完整的信息，而不是只給個IP或者賬號名就行了（往往T＋1就之要這些就夠）。

2、對業務流量充分調研並關注

平時可能流量很小的業務，突然因為某個活動（比如秒殺）流量大增，除了在接入之初要對風險判斷請求有了解，對後續的活動也要提前準備，否則如果資源預估不足，突然又趕上這個點接了T+0介面有很多要現場計算的邏輯，陡增的業務流量分分鐘教你做人。

3、bypass ！ bypass ! bypass

風控風險判斷的最基本原則就是要不影響業務邏輯，所以超時機制在一開始就要嚴格約定並執行，一旦發現風控介面超過預計響應時間立馬放行業務請求。

4、讓一線同事們知道你在做什麼

任何風控準確率都不是100%的，所以在和研發溝通好接入後一定要告訴一線同事們風控阻斷可能出現的表象，以及大致的原因，以避免一線客服們對風險攔截的投訴不知道如何解釋，並給出具體的阻斷回復措施（加白名單、刪除黑名單等等，上帝們在某些日子比如315維權意識是非常強的）。

結語

阻斷是最終產生真實價值的環節，另外也是關聯部門最敏感的環節（嚇唬我半天逼著我把風控接了，結果一天到晚給我出毛病？生產環境是給你們玩的？！），請保護這至關重要的信任，你後面會越做越順的。

最後，請期待我們本系列的最終話：《量化風險攔截的價值和不斷分析案例進行策略優化》。

作者介紹

劉明豈安科技聯合創始人，首席產品技術官
超過6年的風控和產品相關經驗，曾就職網易，負責《魔獸世界》中國區賬戶體系安全。現帶領豈安互聯網業務風控團隊為客戶提供包括了明星產品Warden和RED.Q的風控服務。