風控策略、風控運營等業務人員時常會用到一類系統，即風控決策引擎。那么，什么是風控決策引擎？風控決策引擎有哪些具體的功能模塊，其對應的設計又是怎么樣的？一起來看看作者的解讀。

一、前言

信貸管理中的貸前管理、貸中管理、貸后管理這三篇介紹了信貸管理業務中的主要業務及系統是如何設計的，但是從內容來說，我自我感覺還是稍微比較亂的，后續的工作中如果有了新的理解，可能出再出對應的文章去做補充說明。

信貸管理部分就此告一段落，接下去就介紹下之前一直留下來的一個大坑——風控篇，也就是風控決策引擎部分。

二、什么是風控決策引擎？

「風控決策引擎」目前在市場上沒有統一的官方定義，但是從用途來說主要是通過可視化的操作，提供規則、評分卡、決策流等工具，管理和評估風險的系統。主要在金融、電商、保險等各領域被使用。

為什么要設計成的系統？

本質上還是與業務流程的結耦，因為風控規則是高度靈活變動的，在業務的不同階段和時期，或者說不同領導人的要求下，都是變動的。

如果配置靈活度不高，后期重新設計開發的可能性比較高。

風控決策引擎主要的使用對象是風控策略、風控運營等業務人員，主要工具包含規則、評分卡、決策流。

三、什么是特征？

在說具體工具之前，我們先來聊一聊特征，什么是特征？

特征可以說是風控系統中的最小單元，是風控工具的重要組成部分，我們也可以理解成變量。不過叫什么問題不大，團隊內有相同的共識就行。

那么特征有哪些呢？

我們來稍微舉幾個例子，年齡、性別、年收入這些都屬于特征，而這些特征我們需要給予他們對應的類型。從變量分類的角度來分類，可以有int、long、double、string、boolean等類型。但我是設計成了數值型（普通數值型/匯總數值型）、字符串型和枚舉型這三種，做了一層歸集和刪減。

但是，無論采取哪種分類方式，后續的設計能夠閉環即可。

四、什么是規則？

一個規則包含特征、邏輯運算符、比較運算符、閾值和觸發結果。其中，特征、比較運算符和閾值構成條件表達式，規則由一個或多個條件表達式和觸發結果構成，具體關系如下圖：

看不懂？

沒關系，我們就來舉個簡單的例子，就以進入網吧的準入規則為例：

1. 若對象年齡大于等于18歲，則可進入
2. 若對象年齡小于18歲，則不可進入

這就是一個簡單的規則，也是一個條件表達式，其中特征=年齡、比較運算符=大于等于、閾值=18，若滿足條件，則觸發結果=True，則可進入網吧；否則觸發結果=False，不可進入。

那如果增加一個準入條件“是否有錢呢”，那么準入規則就變成為：

1. 若對象年齡大于等于18歲，且有錢，則可進入
2. 若對象年齡大于等于18歲，且沒錢，則不可進入
3. 若對象年齡小于18歲，且有錢，則不可進入
4. 若對象年齡小于18歲，且沒錢，則不可進入

在滿足年齡大于等于18歲的條件下，還增加了一個條件是否有錢，其中“年齡大于等于18歲”和“是否有錢”這兩個條件的邏輯運算符=且，表示兩個條件均需滿足。

實際的計算過程中，第3、4兩種條件下，對象年齡小于18歲的時候，就會造成短路運算，不會再去判斷是否有錢。

所以，由上面這個例子可以得出，規則的本質其實就是在處理條件語句。理解了這個大前提之后，風控決策引擎設計上就已經了解了一大半了。

五、功能模塊

了解完規則之后，我們來聊下有哪些具體的功能模塊以及對應的設計。

風控決策引擎主要由特征管理、規則管理、規則集管理、評分卡管理、決策流管理和歷史決策管理組成，在此之上可能迭代出其他模塊，但是我是覺得這幾個模塊是從0開始必須的。

1. 特征管理

系統中的所有基礎特征都是需要進行定義的，因此再提交開發之前需要將特征的取值和計算邏輯和開發溝通清楚。在基礎特征之外，系統可設計對應衍生特征的簡單配置，比如加減乘除、最大、最小值之類的，可以在前端提供給也業務方使用，減少開發的工作量。

在特征管理中著重說明下特征類型和特征來源這兩個字段。

a）特征類型

在上文中也說明了每個特征都是有具體的類型的，我在處理的時候做了一層歸集，減少了類型數，分為了數值型、枚舉型和字符串型。

其中數值型又拆分成普通數值型和匯總數值型，二者主要區別是不同時間維度下的是否存在不同的統計值，最終體現在前端的是是否有時間維度的選擇 。

例如“年齡”，年齡的具體數字根據規則執行節點的年月日和出生日期的差值計算得出，在不同的時間維度下年齡是不會有區別的（比如近3個月），所以年齡屬于普通數值型；而“月均收入”是根據計算月份的總收入/計算總月份計算得出，所以不同時間維度下是有區別的（比如近3個月和近6個月）。

另外不同類型的特征也綁定了特定的運算符，這樣在規則配置的時候也會更簡潔點。

• 數值型：綁定了大于、大于等于、小于、小于等于、等于等運算符，閾值需要是數值。
• 枚舉型：綁定了在集合內、不再集合內的運算符，閾值需要是一個集合。
• 字符串型：綁定了等于、不等于、在集合內、不在集合內等運算符，閾值需要是一個字符串。

具體的比較運算符的綁定，可以采取先配置基礎的運算符，然后根據實際的業務需求再做加法。

b）特征來源

同一個特征，可能會對接不同數據供應商（成本考慮）。比如企業法人信息變更，就可能來自兩個不同的供應商，那么，就需要根據特征來源對供應商進行判斷。

2. 規則管理

了解規則是由特征、邏輯運算符、比較運算符、閾值和觸發結果組成，以及規則其實是在處理條件語句的本質之后，那么前端設計就萬變不離其宗了。

上圖就是規則管理的部分頁面內容，其中比較重要的功能是規則測試。規則測試主要面向對象是業務和測試人員。

• 業務人員：能夠就配置的規則，立馬知道規則執行是否有問題。
• 測試人員：上文說過特征來源可能是自有數據，也有可能是供應商的數據。規則的測試分為取值正確性和規則邏輯性驗證。規則測試主要解決規則邏輯性驗證，確定好這部分正確后，就可著重對取值進行驗證，在規則的驗證過程中有的放矢。

另外在觸發結果上，一般是有“通過”、“拒絕”、“記錄”、“轉人工”等選擇。因為規則設計都是順序執行，所以在遇到“拒絕”結果上，整條規則就會中斷執行并輸出結果；“記錄”結果可以認為是一個中性結果，用作規則調試；“轉人工”結果就會將案件轉人工，由人工介入二次審批。

觸發結果除了上述的結果，還有可能輸出某一變量的值。比如輸出的是“會員等級”這一變量值，根據具體的規則輸出金牌、銀牌、銅牌這個變量值。

觸發結果有哪些、形式是怎樣以及對應的邏輯處理，讀者可根據實際的業務背景進行定義。

3. 規則集管理

規則集是將多條規則組合成一條規則集合，其本質上還是在執行規則。下圖是規則集配置的部分前端頁面：

因為規則集也是順序執行，并且包含了多條規則，在設計上可以加上一些快速變更執行規則順序的操作。

另外，類似的還有規則表和規則樹。

a）規則表

規則表由條件列和結果列構成，上圖中的貸款主體變更次數和欠繳費總金額為條件列，最右側的觸發結果為結果列，總共規則數為兩個條件列的乘積。

b）規則樹

規則樹的設計上是按照橫向的樹葉分支結構。

所以，從上面的額介紹可以得出規則集、規則表和規則樹都是規則的聚合，本質上都是在執行規則。

但是在使用體驗上還是有差異的：

• 規則集：規則復用性高，可以復用已經配置好的規則；
• 規則表：可以額外增加一些表格導入規則的操作；
• 規則樹：樹狀結構使用上我覺得是最直觀的。

4. 評分卡管理

評分卡本質上也是一種規則的變體，在規則中輸出的是一個是否通過的結果，而評分卡輸出的是一個分數結果。例如針對“年收入”這個特征，可能設置的評分卡如下：

• 年收入小于5萬，得10分
• 年收入大于等于5萬，小于20萬，得20分
• 年收入大于等于20萬，得30分

這個例子就是一個評分卡，理解了這個例子就理解了評分卡。

上圖是評分卡管理部分的前端頁面，其中不同的特征維度之間可能還會有「權重」的設置，比如年收入相較于年齡，設置的權重要更高點，在這樣的業務背景下，前端就需要有配置的權重的功能。點擊「設置權重」，展示對應權重列，可對某一特征進行設置權重值。那么，最終的評分=特征評分1*權重值1+特征評分2*權重值2+…

在設計評分卡的過程中，要著重注意缺失值 的處理，也就是要有個兜底的區間，保證對應的條件都能取到分值。

5. 決策流管理

決策流類似工作流，能將規則、規則集、評分卡編排，實現一個較大的業務決策流程。

決策流由開始、規則節點、決策和結束構成。規則節點包含規則、規則集和評分卡等工具。

決策就是拿著上一個規則節點的結果進行判斷，是選擇結束，還是去往下一個規則節點。

上圖就是決策流的前端界面，通過規則節點和決策之間的連線，可以清晰的看出決策的處理邏輯。

6. 歷史決策管理

歷史決策管理中主要管理決策引擎中的歷史決策，可查看歷史決策的執行路徑、明細和結果。

上圖是歷史決策詳情的部分前端頁面，針對歷史決策，還需要有重新執行、決策回溯之類的操作，以滿足業務需要。

• 重新執行：在進行決策時，會調用大量的內外部接口進行計算，計算的過程中可能會接口錯誤導致決策停止，針對異常情況，需要有對應的重新執行的操作。
• 決策回溯：業務是動態變化的，因此針對歷史的決策，能回溯重測。

六、補充

功能模塊也聊好了，那我們來兩個補充的內容吧，分別是貸前的決策模型及規則介紹、數據使用原則。

a）決策模型及規則介紹

貸前模型：

預授信：常使用模型或者評分卡。通常用于白名單營銷，在我對接的資金方中，網商和京東有采取預授信，通過主體的基礎信息和經營信息，可以預授信出對應的額度，可用于白名單營銷。正式進件之后，會再執行準入、反欺詐之類的策略。

準入：常使用規則。一般使用平臺自有數據、工商數據、司法數據、納稅數據、發票數據、多頭借貸數據。

• 平臺自有數據：年齡、加盟商狀態、加盟時長、發貨數量、充值金額…
• 工商數據：成立年限、經營狀態、法人變更、股東變更…
• 司法數據：被列入失信被執行人、限高、被執行案件數量…
• 納稅數據：納稅年限、納稅登記水平、欠繳稅金額….
• 發票數據：開票月份數、最近一次開票月份距今、開票金額…
• 多頭借貸數據：不同時間緯度下的平臺申請數、非銀機構逾期記錄、非銀機構申請數…

反欺詐：常使用規則和評分卡。一般使用平臺自有數據、運營商數據。

• 平臺自有數據：三要素/四要素、在網異常、入網時間…
• 運營商數據：提交時間異常、MAC值變化情況…

授信評級：常使用評分卡。

定額定價：常使用評分卡。

模型的使用不同機構間可能不同，以實際業務為準。

b）數據使用原則（主打一個降本～）

• 優先使用自有數據源：對于同一個特征可能自有和外部供應商都能提供接口查詢，應該優先使用自有數據源。
• 優先使用低成本數據源：對于同一個特征，可能有多個外部供應商提供接口查詢，在選擇時應該選擇費用較低的數據源。
• 外部數據及時入庫：外部供應商的數據接口查詢一般分為查詢和查得兩種，針對請求回來的供應商的數據要及時入庫，在一定周期內是可以重復使用的，避免重復調用供應商接口產生不必要的費用。

七、總結

作為金融風控小學生，在設計風控決策引擎的時候，我覺得最難的不是功能設計，在吃透業務之后，了解了網上相關的材料也能完成設計。在接觸的過程中，最難的還是對于規則的設置，在頂層戰略規劃下，你要怎么去設計你的規則去滿足業務規模需要，又能保證風險可控，當然這也可能是對規則背后含義的理解不透徹。

還有個我覺得最繁瑣的事，那就是設計特征。文中也說到很多特征是來源于第三方供應商，在設計特征的過程中，看了幾十篇接口文檔，成百上千個字段，現在回想起來都有一種惡寒，不知道你有沒有這樣的感受…

那么，風控篇也告一段落了，后續也會繼續輸出總結相關的內容，讓我們一起期待下吧。

希望這篇文章對你有用～