本系列的上一篇文章搭建風控系統道路上踩過的坑02-風險分析,咱們介紹了在採集信息後如何去分析這些數據產出風險事件,而產出的報警已經脫離了業務系統並不能被採用的。segmentfault
說白了:分析出來的東西不能光本身看着High,還得去阻攔這些風險才能真正產生業務價值。安全
在開始前,咱們仍是回顧下業務風控主要作的四件事:框架
一、拿到足夠多的數據
二、作足夠靈活的分析平臺去分析數據異步
三、產出風險事件進行阻攔風險
四、量化風險攔截的價值和不斷分析案例進行策略優化優化
到了第三步咱們離整個系統核心框架的搭建就只剩一步之遙了,那麼讓咱們看看這個環節要考慮什麼:設計
咱們最終從數據中發現的報警和問題最終是要在業務邏輯中去阻攔的,在接入這些結果的時候,每每分析師以爲能夠提供的信息有不少,好比命中了什麼規則、這些規則是什麼、何時命中的、何時過時,其中最讓接入方心煩的當屬風險分值當仁不讓了,不少接入風控的研發看到這些分值就一腦殼包:日誌
你到底想讓我作什麼,攔仍是不攔?這時候若是你喏喏的再丟出個多少分值以上要攔,研發多半都會跟你說直接給我結果就行了。 code
是的,不少風控接口設計的都十分累贅,無用信息多到研發會以爲你在故意浪費帶寬,其實一個code list給他們說明對應但願作的操做就好,必定把你以爲那些很牛逼的中間結果等等包裝成最終結果再給出去。接口
舉個例子來解釋實時(T+0)和異步(T+1)風險判斷的區別。事件
你在打拳擊比賽,選手A只會打臉,上來就照着你臉來了一拳,你分析了一下打臉很疼並且不科學,在第二拳往臉揮過來時你忽然告知對方不可打臉,對方就成功的被你剋制住了。這就是T+1的特色,至少要在第二次風險攻擊才能夠生效;
拳擊比賽第二場對陣選手B,一樣被打臉後你說不可打臉,對方說好,結果衝着肚子就來了一拳。你說禁止打肚子,對方又一拳打腋下。這時你發現要在對方揮拳立刻打到你以前就要禁止。
這就是T+0了。
由於T+0在接入的時候要額外承擔不少計算成本,結果要現場算出來而延時要求又很高,因此通常都只在攻擊者得手關鍵步驟採起實時判斷(好比訂單支付或者提現請求)。而對於其餘場景能夠選擇T+1方式,好比登陸或者提交訂單等。
這一點咱們豈安在對外演講的時候介紹過不少,在阻斷風險的時候事件發生的點是不一樣的,但短時間又不可能讓業務研發在全部的地方接入風險阻斷怎麼辦?
因此咱們須要考慮幾個基本的保底措施,好比統一的驗證碼驗證頁面在IP層全局防止任何爬蟲腳本行爲,在帳號層經過登陸態管理統一攔截單個帳號在登陸後任何風險行爲(全局強制登出)。
可能這些措施在體驗上不是最好的,可是在發生特殊問題的時候要等研發給你臨時加阻斷邏輯這個時間就無法控制了。
登陸的時候帳號輸入框鼠標失焦就要去走風控了,登陸結果出來以後再去判斷就沒意義,而資金相關的通常是在跳轉去收銀臺以前,你會發現通常風險判斷都是在結果出來以前(收集本次行爲完整日誌以前),因此若是你要作T+0判斷,就要求研發在進行風險判斷的時候要提供更完整的信息,而不是隻給個IP或者帳號名就好了(每每T+1就之要這些就夠)。
平時可能流量很小的業務,忽然由於某個活動(好比秒殺)流量大增,除了在接入之初要對風險判斷請求有了解,對後續的活動也要提早準備,不然若是資源預估不足,忽然又遇上這個點接了T+0接口有不少要現場計算的邏輯,陡增的業務流量分分鐘教你作人。
風控風險判斷的最基本原則就是要不影響業務邏輯,因此超時機制在一開始就要嚴格約定並執行,一旦發現風控接口超過預計響應時間立馬放行業務請求。
任何風控準確率都不是100%的,因此在和研發溝通好接入後必定要告訴一線同事們風控阻斷可能出現的表象,以及大體的緣由,以免一線客服們對風險攔截的投訴不知道如何解釋,並給出具體的阻斷回覆措施(加白名單、刪除黑名單等等,上帝們在某些日子好比315維權意識是很是強的)。
阻斷是最終產生真實價值的環節,另外也是關聯部門最敏感的環節(嚇唬我半天逼着我把風控接了,結果一天到晚給我出毛病?生產環境是給大家玩的?!),請保護這相當重要的信任,你後面會越作越順的。
最後,請期待咱們本系列的最終話:《量化風險攔截的價值和不斷分析案例進行策略優化》。
劉明 豈安科技聯合創始人,首席產品技術官超過6年的風控和產品相關經驗,曾就任網易,負責《魔獸世界》中國區帳戶體系安全。現帶領豈安互聯網業務風控團隊爲客戶提供包括了明星產品Warden和RED.Q的風控服務。