編輯導讀：風控流程方案設計會牽扯到多方系統，需要考慮到各方因素，踩的坑自然也會多。上篇文章分享了搭建風控體系在調研評估和埋點接入時所踩過的坑，這篇把之前在搭建過程中踩過的坑分享給大家，一起來看看吧。

01??風控流程方案設計

風控流程方案設計會牽扯到多方系統，好的設計既考慮策略的優、簡、易，同時能兼顧于各系統的耦合，也是風控的重要環節之一，在設計過程中，須清楚如下兩點：

1. 大方向須結合自身“資源”

整個風控體系搭建的方向是針對業務關注的某類或者某幾類風險，在搭建過程中一方面需要從黑產情報中獲知其目前掌握的攻擊技術、作案手段以及工具資源，另一方面需要掌握現有業務系統所能支撐的資源情況，比如運營資源、數據資源、處置資源等等。筆者之前參與的一個風控設計項目因為沒有深入了解業務側的實際資源情況，導致交稿方案中的名單落地因為業務方資源跟不上而被推翻。

2. 細節決定方案落地的成敗

每一個細節都務必與業務側以及開發側確認！每一個細節都務必與業務側以及開發側確認！每一個細節都務必與業務側以及開發側確認！因為筆者花費最多時間的就在這個環節，所以重要的事情說三遍。一個好的風控體系可以理解為一個資源整合優化的過程：全量的接入數據，經過復雜運算后，通過與各個系統間的耦合，將壞數據“篩選”出來。每一步都是環環相扣，承前啟后的，所以設計的時候要考慮好這一步與下一步的關聯以及對全局的影響。

筆者曾經在一個風控項目中在業務響應側就出現過一個問題，由于沒有過細考慮過某些維度字段的實際落地細節問題，導致開發在接入的過程中發現由于業務前端本身對接系統太多，無法采集到這個字段，最終導致該字段無法落地到名單標簽中，最終導致閉環系統里里缺了這個字段，后面為了解決這個事情讓項目耽誤了一段時間。

02??測試聯調

在這個環節，業務方的開發人員已經完成基本的數據采集以及接口開發工作，后面就進入聯調校驗階段，筆者的日常工作中需要使用風控引擎對接各個業務系統，風控引擎其本質是將從各個業務端輸入進來的數據，經過各類數據分析計算，最終輸出風控處置結果（如下圖）。由于業務線復雜多變，每一次的需求變動，以及每個變量的修改/增減、規則調整、模型迭代優化或者代碼的優化，都有可能影響引擎性能，因此在每次搭建的測試聯調階段都需要確認接入的數據是否滿足風控需求。

在這個過程中，筆者之前踩過的坑有如下這些：

1. 驗證問題

風控測試驗證不是說通過業務方的測試傳入幾個必傳參數就完事了，這里面有兩點須確認：數據、決策結果。

1）關于數據

如上圖所示，風控接口一般會收到基礎用戶數據、業務參數數據、設備指紋采集數據、第三方的名單或者接口調用的數據，在這個環節需要確認數據的準確度與一致性。筆者之前經常在這個環節遇到問題，不同業務線的開發人員經常會錯誤理解采集點或者經常丟失，導致返回的參數始終無法命中風控策略，需要反復多次的聯調驗證，因為這個環節的數據將決定生產環境的上線結果，因此這一步需要格外重視。

此外，如果有客戶端測試環境，建議通過該環境的操作確認風控埋點位置是否都有采集，這一步做的目的也是為了精準確認數據的采集情況。

2）關于決策結果

如上圖所示，風控引擎接收到測試數據后，通過模型及規則的一系列復雜計算，最終輸出決策結果，因為決策引擎只輸出一個風險評價數據，真正影響到業務的是處置階段，這個環節重的點是驗證決策結果的準確度。決策結果的準確度主要指按照約定好的模型和規則是否可以準確響應，反映準確度的評價標準一般可包含覆蓋率、交叉率、誤傷率、準確率、WOE、IV值、ROC、KS等，分析完成后，最后根據分析的測試結果，可輸出決策評估報告給業務方。

筆者在這一步主要遇到的問題是在做策略時沒有深入了解一線業務的真實情況，或者業務方自己也忽視了這些情況，這就導致經常從數據分析角度看用戶是有問題的，但實際上這些異常是有合理的業務解釋的，所以對于決策結果準確度上，除了要具備嚴謹的數據分析能力以外，還需要緊密的業務合作。

2. 響應問題

這里筆者想講的響應問題包含兩點：性能響應與業務響應，前者是通過相關指標的監控驗證系統間對接后的性能的響應問題，后者是通過客戶端的展示驗證是否與背后的風控處置結果一致。

1）關于性能響應

業務側通常需要“零感知”的風控效果，因此對風控系統通常有明顯的調用時長（RT）限制，此外，對于體量較大的業務方還會對QPS、TPS等有明確要求，因此在測試聯調階段，也需要考慮增加對此類指標的監控。

筆者之前遇到的問題主要來自于響應時長問題，不同業務方對響應時長的級別不同，對于那些RT可以滿足的風控接入，如果需要極短的響應時間，可考慮使用輕量級的接入，因此在測試階段重點關注該數據是否達標。如果RT不能滿足的風控接入，可通過異步接口調用，同樣也要驗證RT是否達標。

2）關于業務響應

風控決策結果輸出之后，業務側需要按照預期設計好的邏輯響應落地，在這個環節需要驗證的是：每一個風控結果的輸出都有對應的業務處置落地，并且客戶端也有對應的響應話術，以及正確的事后閉環 。展開來說，每個決策結果跟業務現有的處置手段都存在映射關系，不存在有冗余的決策結果或者處置手段，且每個處置手段都在客戶端有相應的響應動作，最后，每個需要有處置手段的數據都可以將關鍵的風控維度落地，并多次使用。

筆者有一次因為在這個環節因為缺乏經驗，設計了繁冗復雜的落地方案，結果在測試驗證的時候發現業務方并沒有做好客戶端的相關改造，結果導致在改造完成之前先用臨時的急救方案替代正式的方案。

好了，以上就是我在風控領域搭建時遇到的坑以及總結的經驗，希望這些能夠幫助到大家今后的工作。

作者：小瑪，某金融公司風控分析師一枚，專注風控多年，持續更新風控系列文章，“數據人創作者聯盟”成員。

本文由@一個數據人的自留地 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議