那些年搭建風控體系所踩的坑
編輯導語:“風控是金融的心臟,數據則是風控的血液。”風控系統在業務中是非常重要的,跟多時候都需要風控中有價值的信息來進行參考,并且搭建風控體系還需要從不同的角度考量;本文作者分享了關于搭建風控體系所踩的坑,我們一起來了解一下。
業務部一般找風控部的主要問題是:新上了一個業務,結果發現效果不達標,經過分析后發現有很多不合理的數據結果,懷疑是被黑產盯上了,希望風控部門幫忙解決這些問題。
作為專業的風控人員,業務的需求會轉化為一個可大可小的風控項目,如果這家公司的業務部門很多很雜,可能還要涉及到定制化的風控體系搭建。
那么在這個搭建或者項目落地之前,一般都會有遇到可大可小的坑;這篇文章主要是基于筆者的經驗,將之前踩過的坑小結出來,供需要的同學參考,由于涉及的內容較多,將分為兩篇文章來講。
01 調研評估
前面文章我提過第一步需要調研評估,這一步其實風控的第一個關鍵點,也是最容易掉坑的一個地方。
業務的同事往往不了解風控實際工作,因此對于風控有價值的信息,不能盡述道來,這就需要風控人員做主動地問詢、調研和評估了,一般包含的主要內容有兩點:
1)業務描述
風控人員通過了解業務的每一個環節,一來可以大致確認業務可能遭受的風險攻擊類型,二來為埋點提供更多細節信息。
2)損失盤點
歷史損失記錄有助于風控人員了解并復盤黑產攻擊業務的模式、可能使用到的資源、并能評估出業務的短板以及現有的防御能力。
但是,這些調研并不代表調研評估階段已經完成,后面可以順順利利地按照原計劃來執行了,在這期間還有一些坑位也需要提前預知。
1. 一定要有量化且貼近業務KPI的目標
這一點很重要,務必要貼近業務并且量化!因為這個可以理解為驗收標準,將切實地影響整個項目的進展。
雖然業務的需求通常比較明確——解決一個業務風險問題,但在實際立項搭建的過程中,如果只有定性目標,或者目標完全不考慮業務感受,那么這個項目最后一定很難收尾或者得到業務方滿意的驗收。
另外,如果業務方無法給出明確的量化指標,風控人員需要協助一同制定出項目指標,比如結合風控通用的指標以及業務通用或者關注的指標來制定。
2. 業務資源的盤點也很重要
風控體系化的搭建需要多個資源的整合,這里的資源按歸屬方分為風控資源和業務資源,風控資源來自于風控部門;比如決策引擎、名單庫、設備指紋SDK、數據分析工具、看板/預警系統、風控數據倉庫等,業務資源來自于業務部門,包括名單系統、處罰中心等。
完整的風控體系需要結合這兩部分資源來共同實現,任何一方資源的缺失或不全都會造成風控短板,無法達到優良的風控循環,尤其是業務系統,在實際盤點的時候務必要跟業務方確認,否則如果具體的落地方案輸出給了業務方,結果業務方說沒有那就很尷尬了。
3. 業務漏洞務必要先排除
這是個老生常談的話題,但如果忽略了就是一個巨坑,甚至會讓風控部的績效涼涼。業務漏洞的排查主要存在于風控方案產生之前,主要來自于兩方面:
1)業務規則漏洞
主要指業務范疇的漏洞、流程環節的漏洞以及人為失誤的漏洞。
這里分別依次舉三個例子,比如營銷活動的無門檻優惠券問題、用戶可重復無限次中獎、活動在凌晨無人值守的時間點上線;這些都需要風控部門在前期排查整改,否則損失無法估計,尤其是又遇到大量客戶投訴要求索賠,到時候也只能怪自己疏忽大意了。
2)監控漏洞
主要指風險覆蓋率的漏洞、接口的漏洞。覆蓋率的漏洞指的是有遺漏的業務接口沒被風控監控,比如某個渠道沒有盤點進來,接口的漏洞指的是業務接口沒有做安全封裝,比如接口重放的攻擊。
02 埋點接入
埋點接入是將風控人員將關注的場景和數據通過日志埋點的方式輸送給風控系統,它的精準度將直接影響后面的風控策略質量,它需要風控人員具備風險敏感度。
尤其對于核心場景的識別,這里簡單描述一下核心場景,核心場景指的是最容易產生與業務核心KPI關聯的損失的環節,比如對于交易類業務,業務更關心成交量和成交額,那核心場景就是下單或者購買環節,資金來往類業務的核心場景就是在提現或者轉賬環節;而這些環節以外的其他環節,比如下載、注冊、登陸、綁定銀行卡、注銷都屬于關聯場景,從這些場景里產生的數據,都將最終累積成核心場景那一個關鍵動作的風險結果。
因此風控人員需要準確識別出核心風險場景,并切分出與其相關的關聯場景。
在這個環節也有許多需要提前知道的坑:
1. 埋點位置一定要澄清
作為風控人員,我們自己是知道什么時候需要調風控接口,但是對于系統開發測試人員,他們并不能準確地知道每個風控點,如果沒有及時溝通好,很有可能開發就按照自己理解的位置去埋點取數了,結果就變成了一個坑;因此風控人員務必需要在需求澄清會上與開發測試約定好準確的埋點位置,并且如果有必要,需要使用對方業務系統的測試環境進行相關操作,并根據返回的數據驗證是否滿足風控需求。
2. 數據質量務必做好監控
數據是風控的核心之一,數據質量的好壞必然與風控質量相關,因為如果前者很差,極有可能導致風控誤判或者漏判,進而導致客戶投訴甚至法律糾紛;因此,在該階段需要對每一個場景入口的數據做質量監控,并將相關異常預警給相關的開發同事,這個維度監控包括兩點:
1)空值監控
如果業務不存在空值的可能性,則監控是否出現空值即可,如果業務允許空值的存在,則監控空值的占比是否出現異常。
2)干擾值的監控
如果2C端的業務不存在出現內外IP的情況,則忽然某個業務接口有大量內網IP輸入,則需要監控是否存在異常接口數據上報的問題。
3. 接入流程要規范統一
風控的接入并不是靜止的一次性動作,隨著業務的變化,也會有隨之而來的新需求,因此如果沒有形成規范的接入流程和文檔,則會給大家都帶來不便,這里的規范統一化包含如下兩點:
1)日志格式的統一
日志格式的規范化可以省去很多重新對接的時間成本,比如每個字段都有規范的屬性劃分,手機號只能傳入到mobile這個字段、用戶名只能放在username這個字段,而不是手機號即可以存入到mobile字段也可以存放在username字段,這樣不規范的存儲會讓后期策略上線很被動也很復雜。
2)接入文檔的統一
接入文檔的固化和規范,極能便于開發人員看懂文檔中涉及的每個環節以及字段,并且在返回報錯時,通過文檔的內容找出問題點,而不是反過來問風控或者產品來解決問題。
好了,以上就是我在風控體系搭建前期過程中踩過的一些坑,感謝閱讀。
作者:小瑪,某金融公司風控分析師一枚;公眾號:一個數據人的自留地
本文由@一個數據人的自留地 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
????