關注並將「

人人都是產品經理

」設為星標

每天早 07 ： 45 按時送達

“風控是金融的心臟，資料則是風控的血液。”風控系統在業務中是非常重要的，跟多時候都需要風控中有價值的資訊來進行參考，並且搭建風控體系還需要從不同的角度考量；本文作者分享了關於搭建風控體系所踩的坑，我們一起來了解一下。

作者：

小瑪，某金融公司風控分析師一枚

題圖來自 Unsplash，基於 CC0 協議

全文共 2717 字，閱讀需要 5 分鐘

—————— BEGIN ——————

業務部一般找風控部的主要問題是：新上了一個業務，結果發現效果不達標，經過分析後發現有很多不合理的資料結果，懷疑是被黑產盯上了，希望風控部門幫忙解決這些問題。

作為專業的風控人員，業務的需求會轉化為一個可大可小的風控專案，如果這家公司的業務部門很多很雜，可能還要涉及到定製化的風控體系搭建。

那麼在這個搭建或者專案落地之前，一般都會有遇到可大可小的坑。

這篇文章主要是基於筆者的經驗，將之前踩過的坑小結出來，供需要的同學參考。由於涉及的內容較多，將分為兩篇文章來講。

調研評估

前面文章我提過第一步需要調研評估，這一步其實風控的第一個關鍵點，也是最容易掉坑的一個地方。

業務的同事往往不瞭解風控實際工作，因此對於風控有價值的資訊，不能盡述道來，這就需要風控人員做主動地問詢、調研和評估了，一般包含的主要內容有兩點：

1）業務描述

風控人員通過了解業務的每一個環節，一來可以大致確認業務可能遭受的風險攻擊型別，二來為埋點提供更多細節資訊。

2）損失盤點

歷史損失記錄有助於風控人員瞭解並覆盤黑產攻擊業務的模式、可能使用到的資源、並能評估出業務的短板以及現有的防禦能力。

但是，這些調研並不代表調研評估階段已經完成，後面可以順順利利地按照原計劃來執行了，在這期間還有一些坑位也需要提前預知。

1. 一定要有量化且貼近業務KPI的目標

這一點很重要，務必要貼近業務並且量化！因為這個可以理解為驗收標準，將切實地影響整個專案的進展。

雖然業務的需求通常比較明確——解決一個業務風險問題，但在實際立項搭建的過程中，如果只有定性目標，或者目標完全不考慮業務感受，那麼這個專案最後一定很難收尾或者得到業務方滿意的驗收。

另外，如果業務方無法給出明確的量化指標，風控人員需要協助一同制定出專案指標，比如結合風控通用的指標以及業務通用或者關注的指標來制定。

2. 業務資源的盤點也很重要

風控體系化的搭建需要多個資源的整合，這裡的資源按歸屬方分為風控資源和業務資源，風控資源來自於風控部門；比如決策引擎、名單庫、裝置指紋SDK、資料分析工具、看板/預警系統、風控資料倉庫等，業務資源來自於業務部門，包括名單系統、處罰中心等。

完整的風控體系需要結合這兩部分資源來共同實現，任何一方資源的缺失或不全都會造成風控短板，無法達到優良的風控迴圈，尤其是業務系統，在實際盤點的時候務必要跟業務方確認，否則如果具體的落地方案輸出給了業務方，結果業務方說沒有那就很尷尬了。

3. 業務漏洞務必要先排除

這是個老生常談的話題，但如果忽略了就是一個巨坑，甚至會讓風控部的績效涼涼。

業務漏洞的排查主要存在於風控方案產生之前，主要來自於兩方面：

1）業務規則漏洞

主要指業務範疇的漏洞、流程環節的漏洞以及人為失誤的漏洞。

這裡分別依次舉三個例子，比如營銷活動的無門檻優惠券問題、使用者可重複無限次中獎、活動在凌晨無人值守的時間點上線；這些都需要風控部門在前期排查整改，否則損失無法估計，尤其是又遇到大量客戶投訴要求索賠，到時候也只能怪自己疏忽大意了。

2）監控漏洞

主要指風險覆蓋率的漏洞、介面的漏洞。覆蓋率的漏洞指的是有遺漏的業務介面沒被風控監控，比如某個渠道沒有盤點進來，介面的漏洞指的是業務介面沒有做安全封裝，比如介面重放的攻擊。

埋點接入

埋點接入是將風控人員將關注的場景和資料透過日誌埋點的方式輸送給風控系統，它的精準度將直接影響後面的風控策略質量，它需要風控人員具備風險敏感度。

尤其對於核心場景的識別，這裡簡單描述一下核心場景：

核心場景指的是最容易產生與業務核心KPI關聯的損失的環節，比如對於交易類業務，業務更關心成交量和成交額，那核心場景就是下單或者購買環節，資金來往類業務的核心場景就是在提現或者轉賬環節。

而這些環節以外的其他環節，比如下載、註冊、登陸、繫結銀行卡、登出都屬於關聯場景，從這些場景裡產生的資料，都將最終累積成核心場景那一個關鍵動作的風險結果。

因此風控人員需要準確識別出核心風險場景，並切分出與其相關的關聯場景。

在這個環節也有許多需要提前知道的坑：

1. 埋點位置一定要澄清

作為風控人員，我們自己是知道什麼時候需要調風控介面；但是對於系統開發測試人員，他們並不能準確地知道每個風控點，如果沒有及時溝通好，很有可能開發就按照自己理解的位置去埋點取數了，結果就變成了一個坑。

因此，風控人員務必需要在需求澄清會上與開發測試約定好準確的埋點位置，並且如果有必要，需要使用對方業務系統的測試環境進行相關操作，並根據返回的資料驗證是否滿足風控需求。

2. 資料質量務必做好監控

資料是風控的核心之一，資料質量的好壞必然與風控質量相關，因為如果前者很差，極有可能導致風控誤判或者漏判，進而導致客戶投訴甚至法律糾紛；因此，在該階段需要對每一個場景入口的資料做質量監控，並將相關異常預警給相關的開發同事。

這個維度監控包括兩點：

1）空值監控

如果業務不存在空值的可能性，則監控是否出現空值即可，如果業務允許空值的存在，則監控空值的佔比是否出現異常。

2）干擾值的監控

如果2C端的業務不存在出現內外IP的情況，則忽然某個業務介面有大量內網IP輸入，則需要監控是否存在異常介面資料上報的問題。

3. 接入流程要規範統一

風控的接入並不是靜止的一次性動作，隨著業務的變化，也會有隨之而來的新需求，因此如果沒有形成規範的接入流程和文件，則會給大家都帶來不便，這裡的規範統一化包含如下兩點：

1）日誌格式的統一

日誌格式的規範化可以省去很多重新對接的時間成本，比如每個欄位都有規範的屬性劃分，手機號只能傳入到mobile這個欄位、使用者名稱只能放在username這個欄位，而不是手機號即可以存入到mobile欄位也可以存放在username欄位，這樣不規範的儲存會讓後期策略上線很被動也很複雜。

2）接入文件的統一

接入文件的固化和規範，極能便於開發人員看懂文件中涉及的每個環節以及欄位，並且在返回報錯時，透過文件的內容找出問題點，而不是反過來問風控或者產品來解決問題。

好了，以上就是我在風控體系搭建前期過程中踩過的一些坑，感謝閱讀。

—————— / END / ——————

▼ 喜歡請分享&收藏，滿意點個贊，最後點「在看」 ▼