基于规则引擎的客户风险评分 – 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,  转载请注明出处。