基於商務規則的客戶風險評分 – IBM ODM實現

標籤：

通常的商務規則我們使用If then的形式來描述，而現實生活中的企業業務決策要複雜得多，一般由多個規則群組成，而且其複雜性很難直接通過經典的基於rete的規則引擎利用其推理能力執行多個if then語句來解決。需要對規則流的設計，模型的建立，規則的階層有一個整體的考慮設計，以真正達到企業運營決策邏輯的敏捷變更的目的。

本文將使用一個金融行業常見的客戶風險評分情境，來說明怎麼利用商務規則技術（IBM ODM/JRules）實現複雜決策。

客戶風險評分需求

所謂客戶風險評分，就是根據客戶資訊使用特定的公式規則演算法計算出用於標識客戶風險層級的分值，在金融行業廣泛的應用，如銀行信用卡申請，個人或企業貸款審批。自動化的客戶風險評分可以提高風險管理的及時性，確保評分決策的一致性，減少人工幹預，進而實現商務程序自動化，降低運營成本。通常企業希望評分機制可以根據情況隨時調整，包括評分參數，計算公式，風險因子等。如果使用代碼方式或者資料庫參數表的方式實現評分邏輯，其靈活性通常難以達到使用者的期望。

一個客戶的具體風險評分需求如下：

1. 准入規則

- 申請人的年齡比如大於18歲，小於60歲

- 申請的金額不得超過1,000,000

- 申請人必須有正當職業，不接受無業者的申請

2. 評分規則

以下表格是客戶風控部門設定的評分標準的一個子集，實際的評分模型當然遠遠比樣本複雜，某些因子之間有關聯關係，其權重或者風險分值也可能相互影響。

風險要素	權重	預設分值	風險要素取值範圍	風險要素分值
Age	10%	10	< =25	75
			26 - 30	30
			31 - 45	10
			> =46	50
Gender	5%	20	Male	100
			Female	50
Education Level	15%	20	High School	80
			Associate Degree	50
			Bachelor Degree	20
			Master Degree	20
			Doctor Degree	50
Employment Type	10%	20	Employed	20
			Self Employed	50
Corporate Type	10%	30	Top 1000 Corporations	10
			State Owned Corporations	20
			Others	30
Business Nature	5%	20	Investment	80 - Employed 100 - Self Employed
			Banking	60 - Employed 100 - Self Employed
			Consultancy	50 - Employed 100 - Self Employed
			Agriculture	30 - Employed 50 - Self Employed
			Construction	30 - Employed 50 - Self Employed
			Education	10 - Employed 30 - Self Employed
			Others	10 - Employed 20 - Self Employed
Monthly Income	20%	20	<=5000	80
			5000 - 10000	40
			10000 - 40000	20
			>=40000	60
Position In Company	15%	20	Sole Proprietor	80
			Top Management	60
			Manager	40
			Professional	20
			Contractual	50
			Others	10
Months Of Employment	10%	20	0-12	100
			12-36	60
			36-60	20
			>=60	10

至於這個評分標準是如何出來的呢？通常有兩種基本途徑：

1）根據金融機構風控業務專家的經驗，確定要素及其權重分值

2）通過對大量曆史資料的統計分析，發掘出使用者行為模式，由此關聯到特定風險要素，

具體做法不是本文討論的重點。

3. 分級準則

根據風險分值進行分級，確定應該採取的動作，供後續系統或人員參考。

分值	風險層級	動作
<=30	low risk customer	Accept
31 - 50	Medium risk customer	Accept
51 - 80	High risk customer	Review
>80	Very high risk customer	Reject

總體而言，客戶希望可以靈活添加更多的准入規則，增加刪除風險要素，修改各要素的權重及分值，調整分級策略。

模型設計

在ODM/JRules中，規則模型包含兩層，執行物件模型（eXecution Object Model）和業務物件模型（Business Object Model），XOM的設計類似於Java物件模型的設計，

針對上述需求，我們設計如下簡單的物件模型

由於風險要素需要動態添加，我們定義RiskFactor類型，包含名稱，權重，預設值等屬性，Result中使用list儲存運行時建立的風險要素。常我們會在XOM中定義一些操作，用來描述比較技術化的邏輯，例如Result中的addRiskFactor方法會建立RiskFactor對象並加入列表，這樣可以避免將不必要的複雜性暴露到規則層面。

接下來，利用規則設計器產生BOM，詞彙化模型中相應的屬性和操作，並將Application和Result分別指定為決策服務規則集的輸入輸出參數。

規則設計與實現

規則設計一般從規則流開始。規則流是現在規則管理系統中一個基本組件，把決策流程以圖形化可理解的方式展現出來，並在執行期協助規則引擎更合理的控制規則執行，

有人可能會問，規則引擎不是可以根據規則和事實進行推導嗎？為什麼需要顯式的指定其執行順序？事實上目前的公司專屬應用程式中，很少完全利用規則引擎的推導能力來做出決策，業務決策通常是可解釋的，當規則業務含義層面的前後依賴關係非常明顯，我們就可以使用規則流來顯式定義其執行順序，這也可以協助業務人員/開發人員更好的理解決策的流程，從效能的角度規則引擎只選擇一部分規則執行。

根據前面的需求描述，我們設計如下的規則流來描述決策流程：

1）首先是准入資格的檢查，即根據使用者資訊進行篩選，如果使用者不符合準入資格，規則流將直接退出

2）第二步進行評分，使用了一個Subflow，包含Definition和Scoring兩個步驟。

3）最後根據使用者風險分值進行分級。

每個規則任務中均引用了一部分規則，當規則任務執行時，規則引擎將使用規則集輸入參數或Working memory中的事實資料驗證該部分規則。

下面我們來具體看看規則的設計。據准入檢查的要求，Eligibility規則主要檢查使用者資料，相互獨立，如果申請人違反了任何一條准入規則，結果中的qualified標識將被設定為false。反之，如果沒有任何准入規則被觸發，規則流將進入風險評分流，否則直接退出。

根針對使用者年齡的規則如下：

我們也可以隨意增加其他的規則，例如

預設情況下，所有的Eligibility規則都會驗證。一個常見的需求是，只要有一條規則被觸發，即意味著該客戶不符合準入資格，規則任務立即退出無需執行其他規則，此類需求可以通過設定該規則任務的Exit Criteria為RuleInstance實現。

接下來在評分子規則流中，Definition任務的目的是在評分之前執行個體化必要的風險因素，設定相關參數，如Name，Weight等，並將風險要素加入到Result對象中。

請注意這個決策表中所有的規則都將被規則引擎執行，樣本中的condition列僅作為開關之用（ODM/JRules要求決策表必須有條件列）。這種參數化決策表是規則設計中常見的做法，可以讓使用者靈活添加新的風險要素。

下一步Scoring任務的目的則是將風險因素與使用者資料進行規則匹配，確定其分值。我們首先利用Scoring任務的Initial Action將definition階段定義的風險要素加入Working Momory

在評分決策表中，我們使用預定義變數通過唯一的名稱來綁定Working memory中對應的風險因素對象，Age評分所使用的預定義變數和決策表如下所示：

其他風險要素的評分可用類似決策表定義，如教育程度：

我們也可以使用決策表表示更複雜的打分邏輯，如組合多個使用者屬性：

Scoring任務執行完規則後後，使用Final Action對各個風險因素的評分進行匯總：

最後我們根據風險評分結果進行簡單的分級，依然應用決策表實現。

當然我們可以結合使用者申請中的其他資訊，比如金額，產品等定義更為複雜的個人化的分級策略。

總結

使用商務規則技術實現複雜決策的關鍵是：

1）建立適合規則處理的靈活的領域模型

2）用規則流準確描述決策的邏輯步驟

3）合理使用規則，暴露/隱藏合適的參數邏輯

註：本文也發表於http://decisionrule.com/zh/2014/07/riskscoring,  轉載請註明出處。

 

基於商務規則的客戶風險評分 – IBM ODM實現