设为首页 收藏本站
查看: 1644|回复: 0

[经验分享] 基于规则引擎的客户风险评分 – IBM ODM实现

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-10-3 12:48:22 | 显示全部楼层 |阅读模式
  通常的业务规则我们使用If then的形式来描述,而现实生活中的企业业务决策要复杂得多,一般由多个规则组成,而且其复杂性很难直接通过经典的基于rete的规则引擎利用其推理能力执行多个if then语句来解决。需要对规则流的设计,模型的建立,规则的层次结构有一个整体的考虑设计,以真正达到企业运营决策逻辑的敏捷变更的目的。
  本文将使用一个金融行业常见的客户风险评分场景,来说明怎么利用业务规则技术(IBM ODM/JRules)实现复杂决策。
客户风险评分需求
  所谓客户风险评分,就是根据客户信息使用特定的公式规则算法计算出用于标识客户风险级别的分值,在金融行业广泛的应用,如银行信用卡申请,个人或企业贷款审批。自动化的客户风险评分可以提高风险管理的及时性,确保评分决策的一致性,减少人工干预,进而实现业务流程自动化,降低运营成本。通常企业希望评分机制可以根据情况随时调整,包括评分参数,计算公式,风险因子等。如果使用代码方式或者数据库参数表的方式实现评分逻辑,其灵活性通常难以达到用户的期望。
  一个客户的具体风险评分需求如下:
  1. 准入规则
  - 申请人的年龄比如大于18岁,小于60岁
  - 申请的金额不得超过1,000,000
  - 申请人必须有正当职业,不接受无业者的申请
  2. 评分规则
  以下表格是客户风控部门设定的评分标准的一个子集,实际的评分模型当然远远比示例复杂,某些因子之间有关联关系,其权重或者风险分值也可能相互影响。
风险要素权重缺省分值风险要素取值范围风险要素分值Age10%10< =2575   26 - 3030   31 - 4510   > =4650Gender5%20Male100   Female50Education Level15%20High School80   Associate Degree50   Bachelor Degree20   Master Degree20   Doctor Degree50Employment Type10%20Employed20   Self Employed50Corporate Type10%30Top 1000 Corporations10   State Owned Corporations20   Others30Business Nature5%20Investment  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 Income20%20<=500080   5000 - 1000040   10000 - 4000020   >=4000060Position In Company15%20Sole Proprietor80   Top Management60   Manager40   Professional20   Contractual50   Others10Months Of Employment10%200-12100   12-3660   36-6020   >=6010            至于这个评分标准是如何出来的呢?通常有两种基本途径:
  1)根据金融机构风控业务专家的经验,确定要素及其权重分值
  2)通过对大量历史数据的统计分析,发掘出用户行为模式,由此关联到特定风险要素,
  具体做法不是本文讨论的重点。
  3. 分级规则
  根据风险分值进行分级,确定应该采取的动作,供后续系统或人员参考。
分值风险级别动作<=30low risk customerAccept31 - 50Medium risk customerAccept51 - 80High risk customerReview>80Very high risk customerReject  总体而言,客户希望可以灵活添加更多的准入规则,增加删除风险要素,修改各要素的权重及分值,调整分级策略。
模型设计
  在ODM/JRules中,规则模型包含两层,执行对象模型(eXecution Object Model)和业务对象模型(Business Object Model),XOM的设计类似于Java对象模型的设计,
  针对上述需求,我们设计如下简单的对象模型
DSC0000.png
  由于风险要素需要动态添加,我们定义RiskFactor类型,包含名称,权重,缺省值等属性,Result中使用list存储运行时创建的风险要素。常我们会在XOM中定义一些操作,用来描述比较技术化的逻辑,例如Result中的addRiskFactor方法会创建RiskFactor对象并加入列表,这样可以避免将不必要的复杂性暴露到规则层面。
  接下来,利用规则设计器生成BOM,词汇化模型中相应的属性和操作,并将Application和Result分别指定为决策服务规则集的输入输出参数。
DSC0001.png
规则设计与实现
  规则设计一般从规则流开始。规则流是现在规则管理系统中一个基本组件,把决策流程以图形化可理解的方式展现出来,并在执行期帮助规则引擎更合理的控制规则执行,
  有人可能会问,规则引擎不是可以根据规则和事实进行推导吗?为什么需要显式的指定其执行顺序?事实上目前的企业应用中,很少完全利用规则引擎的推导能力来做出决策,业务决策通常是可解释的,当规则业务含义层面的前后依赖关系非常明显,我们就可以使用规则流来显式定义其执行顺序,这也可以帮助业务人员/开发人员更好的理解决策的流程,从性能的角度规则引擎只选择一部分规则执行。
  根据前面的需求描述,我们设计如下的规则流来描述决策流程:
DSC0002.png
  1)首先是准入资格的检查,即根据用户信息进行筛选,如果用户不符合准入资格,规则流将直接退出
  2)第二步进行评分,使用了一个Subflow,包含Definition和Scoring两个步骤。
  3)最后根据用户风险分值进行分级。
  每个规则任务中均引用了一部分规则,当规则任务执行时,规则引擎将使用规则集输入参数或Working memory中的事实数据验证该部分规则。
  下面我们来具体看看规则的设计。据准入检查的要求,Eligibility规则主要检查用户数据,相互独立,如果申请人违反了任何一条准入规则,结果中的qualified标识将被设置为false。反之,如果没有任何准入规则被触发,规则流将进入风险评分流,否则直接退出。
  根针对用户年龄的规则如下:
DSC0003.png
DSC0004.png
  我们也可以随意增加其他的规则,例如
DSC0005.png
DSC0006.png
  缺省情况下,所有的Eligibility规则都会验证。一个常见的需求是,只要有一条规则被触发,即意味着该客户不符合准入资格,规则任务立即退出无需执行其他规则,此类需求可以通过设定该规则任务的Exit Criteria为RuleInstance实现。
DSC0007.png
  接下来在评分子规则流中,Definition任务的目的是在评分之前实例化必要的风险因素,设定相关参数,如Name,Weight等,并将风险要素加入到Result对象中。
DSC0008.png
  请注意这个决策表中所有的规则都将被规则引擎执行,示例中的condition列仅作为开关之用(ODM/JRules要求决策表必须有条件列)。这种参数化决策表是规则设计中常见的做法,可以让用户灵活添加新的风险要素。
  下一步Scoring任务的目的则是将风险因素与用户数据进行规则匹配,确定其分值。我们首先利用Scoring任务的Initial Action将definition阶段定义的风险要素加入Working Momory
DSC0009.png
  在评分决策表中,我们使用预定义变量通过唯一的名称来绑定Working memory中对应的风险因素对象,Age评分所使用的预定义变量和决策表如下所示:
DSC00010.png
DSC00011.png
  其他风险要素的评分可用类似决策表定义,如教育程度:
DSC00012.png
  我们也可以使用决策表表示更复杂的打分逻辑,如组合多个用户属性:
DSC00013.png
  Scoring任务执行完规则后后,使用Final Action对各个风险因素的评分进行汇总:
DSC00014.png
  最后我们根据风险评分结果进行简单的分级,依然应用决策表实现。
DSC00015.png
  当然我们可以结合用户申请中的其他信息,比如金额,产品等定义更为复杂的个性化的分级策略。
总结
  使用业务规则技术实现复杂决策的关键是:
  1)建立适合规则处理的灵活的领域模型
  2)用规则流准确描述决策的逻辑步骤
  3)合理使用规则,暴露/隐藏合适的参数逻辑
  注:本文也发表于http://decisionrule.com/zh/2014/07/riskscoring,  转载请注明出处。
  

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-122131-1-1.html 上篇帖子: IBM的双机切换HACMP方案介绍 下篇帖子: 【IBM Tivoli Identity Manager 学习文档】6 Identity Feeds功能
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表