一、風控重要性

如果把平臺比喻為一顆樹，那么需要投入足夠的養分才能快速生長，而業務風險則是寄生于樹木竊取養分的角色，只有能夠充分抵御這種風險的才能成長為參天大樹。這就是業務風險在平臺發展中扮演的角色。

在大部分場景下，風控意味著阻斷用戶操作，在大部分人眼里與用戶體驗是背道而馳的存在。單就消費金融領域而言，競爭逐漸白熱化，用戶體驗成為了吸引用戶的重要因素，此時風控如何在盡可能少打擾到用戶的情況下，能阻斷盡可能多的惡意行為？這是一場善與惡的博弈，也是關乎生死存亡的博弈。

二、業務風控原則

在這里，需要提出行業內一個著名的原則：輕管控，重檢測，快響應，私以為基本能實現用戶體驗與風控需要的平衡。怎么來理解這個原則呢？

輕管控：在出現風險，需要阻斷用戶操作時，阻斷動作宜輕不宜重。能驗證碼校驗就不短信校驗，能短信校驗就不禁訪。同時被阻斷后文案，下一步出口都需要照顧用戶感受。看似簡單，其實背后涉及到對用戶風控行為以及對用戶風控阻斷動作的分層管理。

重檢測：通過盡可能多的獲取用戶信息（包括靜態及動態數據），由規則引擎進行實時或離線計算，來動態分析每個用戶及采取行為的風險程度。這里需要盡量全的數據來源，以及非常強大的規則引擎，才可以實現良好的檢測效果。

快響應：是指在檢測出用戶存在的風險后，如何快速的進行阻擋。這里的重點是快，則意味著對業務的理解要細，提前在關鍵動作進行布局，才可以做到盡可能減少損失。

業務風控的業務模型設計

說完了原則，我們怎么具體來看業務風控的業務模型設計呢？

在我理解，業務風控的業務模型主要分為六層，分別為數據輸入層，數據計算層，數據輸出層，運營管控層，業務接入層以及用戶觸達層。

大家可以看到，下面三層，是偏向于數據，研發的；上面三層，是偏向于業務，運營，產品的。做風控其實就是做數據，因此數據的接入、技術、處理是其中最核心的模塊；但現階段，由于算法模型的限制，還需要有人為的因素進行規則模型的校正，以及特殊樣本的審理，因此會有運營層的存在；最上面的觸達層，是拿結果的一層，產品的部分工作也在于對此進行良好的設計。

這六層側重的點也各有不同，下面為大家簡單說明：

?

如何獲取數據？獲取什么數據？數據準確性如何？這是數據輸入層需要解決的三個問題。

1.獲取數據方式

目前獲取數據主要有兩種方式，一種是主動獲取，一種是被動獲取。

1）主動方式

主動方式是自己去業務方數據庫、日志里面去讀，這樣可以拿到最全的信息，而不用依賴消息報等被處理過的二手數據。有些比較成熟的公司有自己的消息總線，風控可以去實時的訂閱信息然后作為數據源進行分析；但在公司沒有消息總線的時候，風控可以發揮自己橫向，跨業務的優勢，建立自己的消息總線，去獲取數據進行分析。這樣的好處是對業務方依賴降低，數據來源最全，能進行深入的數據挖掘；壞處是建立難度較大，需要大量資源支持，適合較為成熟的公司。

2）被動方式

被動方式就是提供接口給業務研發，讓業務把消息按格式標準傳過來。這種配合周期非常長，但成本較低，可以按照標準來拿到高質量的信息，所以是比較常見的風控系統搭建方式。

2.獲取數據種類

鑒于目前大部分公司都采用第二種方式，因此與業務方如何合作，獲取高質量的數據就很重要了。對數據種類的要求是能全就全，能深就深。以我做過的賬號安全業務為例：

1）數據全面程度

往往風控關心的信息比如IP地址、referer這些信息業務都是不關心的，但這些信息的缺失可能造成很多策略沒法做，所以在采集信息開始的時候就要有個明確的信息列表。

2）數據詳細程度

以注冊登錄行為為例對數據詳細程度進行深入：

基礎的登陸注冊數據，就可以從頻率、登陸注冊特征來進行分析；

進一步拿到登錄注冊行為的上下文，比如登陸前訪問了哪些頁面，登陸后去訪問了什么，就可以從訪問行為軌跡來增加更多的分析維度，例如頁面停留時間，是否有訪問到必訪問的頁面；

用戶的操作行為數據，比如鼠標移動的軌跡，鍵盤輸入，進一步的從操作過程來增加分析維度，比如是不是輸入密碼的時候有過多次輸入刪除？是不是直接復制粘貼的賬號密碼？

3.獲得的數據準確性

比較常見的例子：需要用戶的訪問IP，結果拿到的IP地址是內網的服務器IP；或者是想要用戶名，結果傳遞過來的是UID。這點需要大量的前期溝通確認工作。

如何在日常工作中確保數據的準確性呢？

1、對采集回來的數據必須定期的對數據質量進行監控

已經采集到的數據可能因為技術架構調整，代碼更新等各類奇葩原因造成采集回來的數據不準了，如果無法及時發現可能造成后面一系列分析過程都出現錯誤。

2、采集點盡量選擇穩定的業務點

比如采集登錄日志，一次性在公共服務采集好，后面出現問題只要找一個點。但如果是去前端從WEB、移動端等各個調用登錄服務的點去采集，出了問題要改動的工作就會成倍增加，還有可能出現新業務點的日志無法覆蓋的情況。

數據輸入原則：

宜早不宜晚，宜全不宜少；

數據分層處理：

實時數據與離線數據分離。實時數據接入需要評估響應時間RT時間及準備一旦被降級的預案。

二、數據計算層

數據計算層是由各種規則、模型等算法形成的計算核心，一般都依附在一個強大的規則引擎之上。

為什么采用規則引擎？因為黑產的反應速度實在太快了。如果把風控規則都硬編碼進業務代碼中，那一旦規則被繞過，反應速度就會非常慢。規則引擎必須能把策略邏輯從業務邏輯中解藕出來，讓防御者可以靈活配置規則在靜默模式下驗證和實時上線生效，并可以去隨時調整。

雖然說數據技術層主要是研發和算法同學處理的，但作為產品可以做的，除了了解基本的規則，模型及實現原理外，還可以增加對規則的生命周期及健康度的評估，比如：風控系統的規則有多少？哪些已經很久沒有觸發了？產生誤判投訴的對應規則有哪些？

一個新規則在建立起初的效果肯定是最有效的（因為這時風險問題正在發生，而規則正好對應了風險），但隨著時間其有效性是快速下降的，比如攻擊者都知道網站三次輸入密碼錯誤觸發驗證碼，那么他們會傻傻的嘗試第三次猜測密碼的概率有多大？那么是否有人在定期的去統計分析這些規則的效率就是風控產品的重要運營環節了，而運營風控產品所要付出的代價是往往大于常規互聯網業務產品的，并且是保證項目能夠持續產出價值并不斷迭代進化的一個前提。

三、數據輸出層

數據輸出層是將數據計算層的計算結果轉化為可以被下游使用的分數，主要的輸出為用戶的風險畫像，風險分數及風險等級。

數據輸出層主要的原則是數據可讀性高（因為會直接被運營及下游業務方消費，需要降低使用方的使用成本，提高效率）以及可復用性（一個輸出的數據，可以在多個場景下被使用。比如垃圾注冊的數據可以同時被反欺詐，反作弊等場景使用）。由于用戶分層及用戶畫像展開來說內容比較多，就不展開了，大家可以自行百度~

四、運營管控層

如果說上面三層主要靠技術的手段來實現風險管控，那么運營管控層主要是靠人為經驗來對技術尚無法處理的風險進行管控。

技術尚無法進行處理的風險主要分為兩種，一是樣本較少，計算準確度不足，然而危害較大的風險行為，比如金融盜卡，詐騙等；二是人為，非機器行為的風險行為，比如工作室層次的大量人工刷單等。以上兩種都是需要運營的經驗來進行判斷會更為合理。同時運營層的處理結果也會反饋到數據輸出層，優化數據輸出的準確性，也有利于為算法及模型提供較為準確的樣本進行學習。

運營管控層主要是風控運營后臺的設計，由于各個運營后臺設計的特點不一而足，因此在這里只說明主要的涉及原則，主要包括可讀性以及案件存檔。

可讀性

讓分析人員可以快速的查詢原始日志：日志并不是簡單的存下來，從風控分析的需求來看，通過IP、用戶名、設備等維度在一個較長的跨度中搜索信息是非常高頻的行為，同時還存在在特定類型日志，比如在訂單日志或者支付日志中按特定條件搜索的需求。

機器語言轉化為自然語言：這主要是為了能夠讓分析人員可以快速的還原風險CASE，例如從客服那邊得到了一個被盜的案例，那么現在需要從日志中查詢被盜時間段內這個用戶做了什么，這個過程如果有一個界面可以去做查詢，顯然比讓分析人員用grep在一大堆文件中查詢要快的多，并且學習門檻也要低得多。

如果在日志做過標準化的前提下，也可以進行后續的業務語言轉譯，將晦澀難懂的日志字段轉化為普通員工都能看得懂的業務語言，也能極大的提升分析師在還原CASE時閱讀日志的速度。

案件存檔

這里指將實時或離線的計算加工消息成變量&檔案。例如在分析某個帳號被盜CASE的時候，往往需要把被盜期間登錄的IP地址和用戶歷史常用的IP地址進行比對，即使我們現在可以快速的對原始日志進行查詢，篩選一個用戶的所有歷史登錄IP并察看被盜IP在歷史中出現的比例也是一個非常耗時的工作。

再比如我們的風控引擎在自動判斷用戶當前登錄IP是否為常用IP時，如果每次都去原始日志里面查詢聚合做計算也是一個非常“貴”的行為。

那么，如果能預定義這些變量并提前計算好，就能為規則引擎和人工節省大量的時間了，而根據這些變量性質的不同，采取的計算方式也是不同的。不過還好我們有一個標準可以去辨別：頻繁、對時效敏感的利用實時計算；而相對不頻繁、對時效不敏感的利用離線計算，以這樣的原則進行指導，就可以盡可能節省時間了。

五、業務接入層

風控的業務模型是環環相扣的，在已經具備了數據處理能力以及運營后臺之后，如果沒有業務方接入，那相當于只有內功而無法出拳，這樣就只是風控內部的自娛自樂，無法為業務保駕護航。在風控與業務技術的合作中，由于業務為王，一切要以業務為重，因此風控在合作中，需要注意：盡可能避免給業務帶來不必要的麻煩。

如何做到與業務進行良好的合作，主要從4點出發：

1.呈現給業務研發直白的判定結果

我們最終從數據中發現的報警和問題最終是要在業務邏輯中去阻攔的，在接入這些結果的時候，往往分析師覺得可以提供的信息有很多，比如命中了什么規則、這些規則是什么、什么時候命中的、什么時候過期，一個code list給他們說明對應希望做的操作，一定把中間結果等等包裝成最終結果再給出去。

2.實時與離線計算分離，降低業務系統壓力

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

3.超時及降級預案準備

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

4.充分關注業務流量

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

六、用戶觸達層

終于來到最后一層，用戶觸達層了。風控的用戶觸達，主要包括各種C端的安全中心，安全組件以及多樣的風控阻斷操作。在這一層，需要做的是細化管控手段，以及重視用戶體驗。

細化管控手段

風控管控手段需要豐富，包括圖形驗證碼，語音驗證碼，實名校驗，touchid校驗，密保問題，禁訪，禁買，禁言等，在不同場景下，采取對應的方式，而不是千遍一律。千遍一律的話，太輕會導致管控效果不佳；太重的話會極大影響用戶體驗。

重視用戶體驗

這點說起來容易做起來難。在獲客成本高昂的今天，假設獲客成本是100塊，他可能因為被風控之后，文案的簡單粗暴，缺少申訴出口或者流程難以繼續而選擇用腳投票，從而離開。而這些是產品可以做的事情。使用提醒式而非警告式的文案；在被風控后及時提示用戶后續的操作；與客服同學加強溝通（任何風控準確率都不是100%的，所以在和研發溝通好接入后一定要告訴一線同事們風控阻斷可能出現的表象（文案提示），以及大致的原因，以避免一線客服們對風險攔截的投訴不知道如何解釋，并給出具體的阻斷回復措施（CRM后臺增加白名單、刪除黑名單權限等

總結

以上是生活随笔為你收集整理的【采用】解读消金业务风控模型的6个层级的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。