智能风控平台核心之风控决策引擎(五)
编辑导读:互联网金融的兴起,金融科技向传统金融渗透,智能风控平台应运而生。决策引擎担任着智能风控平台的核心角色,在当代的互联网金融浪潮中至关重要。本文作者主要讲解风控决策引擎的亮点功能,供大家学习参考。
前面四篇讲解了风控决策引擎的重要功能,产品功能基本满足金融业务的风险控制需求,能够承载贷前、贷中、贷后全生命周期信贷风控所涉及的规则、模型等风控策略。虽然风控决策引擎的重要功能能够实现基础的核心的风控能力,但是在实现风控人员的操作效率、操作便捷,以及多态信贷业务等方面还有许多提升空间。本章重点介绍风控决策引擎除重要功能外的亮点功能。
风控决策引擎的亮点功能不一定必须是基础的重要的功能,相反很多两点功能是一些嫁接在基础功能上的小型功能点。风控决策引擎的亮点功能核心目标是提升用户在产品使用时的操作效率、操作便捷、操作精确,并且能够应对多态的信贷业务。风控决策引擎通常打造的亮点功能如下图所示:
亮点功能主要包含版本管理、版本对比、配置验证、结果评估、手动进件、案件管理、审核管理、名单管理、A/B测试。其中有些功能是基于之前重要功能衍生的功能点,如版本管理、版本对比、配置验证是基于模型、规则、评分卡、表达式衍生的通用亮点功能;结果评估、A/B测试是基于决策流管理衍生的亮点功能;手动进件、案件管理、审核管理、名单管理通常是独立模块形式的亮点功能。
一、版本管理
版本管理主要负责模型、规则、评分卡、表达式等模块中具体项目的版本管理,实现规则、模型、评分卡、表达式细微内容变更的记录,以及不同版本规则间的自有切换,如下图所示。
规则、模型、评分卡、表达式的具体内容在风控决策引擎中都是以每个项目的形式存在,这些项目会被决策流管理中配置的决策流引用,引用的项目又会根据决策流中的先后顺序自动进行决策计算。决策流引用的每个项目可能有多个版本的内容,但是决策计算的时候实际只会计算一个,因此这个时候就需要在版本管理中设计一个“设为系统版本”的选项,定义一个版本为默认的计算版本,系统就会自动调用默认的版本进行决策计算。版本管理中可以通过复制功能快速创建一个副本,然后在副本中进行另一个版本的内容调整,从而实现快速的内容变更和变更内容的记录。
版本管理功能的核心作用是对规则、模型、评分卡、表达式细微调整的记录,有了不同版本的记录更容易进行不同规则、模型、评分卡、表达式的测试研究,并且也能够减少新上线版本存在的风险,通过版本的切换实现规则、模型、评分卡、表达式的快速回滚。
二、版本对比
版本对比用于同一项目下不同版本内容的对比,规则、模型、评分卡、表达式的每个版本通常包含很多内容,如果这些内容都是通过人工手动去对比,随着内容的增加不同版本间不同内容的识别难度成指数级增加。同时随着业务的开展,时间久了之后版本的数量会越来越多,又或者人员变动等因素都会增加风控引擎决策使用者对不同版本间不同内容区分的难度,因此增加不同版本间内容的对比就格外有效。
版本对比功能的设计,不同功能模块有所区别,规则和评分卡都是指标、运算符号、条件值、决策结果或者决策得分的框架,对比的逻辑可以按照名称、指标名称、运算符号、条件值、决策结果进行逐一对比,又或者为了提升效率,可以为以上对比内容分别制定映射定义,然后利用函数对每一条规则或者评分卡内的每条得分进行计算生成结果,然后利用结果实现快速对比,然后再通过不同的结果反过来定位对应的不同内容。模型和表达式的对比主要是对模型文件、表达式的代码内容进行对比,通过对代码解析定位不同内容,可以利用代码编译器中的代码对比功能等。在版本对比中不同的内容可以通过高亮的形式进行展示。
三、配置验证
配置验证用于模型、规则、评分卡、表达式配置过程的检验。模型、规则、评分卡、表达式通常都需要手动配置,配置的过程需要能够及时的检查配置的正确性,因此需要有支持配置验证的功能,尤其在配置规则的时候,有些是规则集、规则树,规则的数量繁多,逻辑也比较复杂,配置验证功能就为这种配置过程的检验提供了很好的解决方案。
配置验证是基于模型、规则、评分卡、表达式的亮点功能,其核心逻辑是通过输入需要验证的模型、规则、评分卡、表达式的计算值,然后决策引擎模拟真实计算,输出决策结果,配置人员根据输入的值和输出的结果判断配置的内容是否正确,如图下图所示。
配置验证功能的入参输入通常提供手动输入和自动填充,自动填充默认会根据特征的类型自动生成对应特征属性的值。
四、结果评估
结果评估主要用于决策流的验证和决策效果的评估。决策流通过引用模型、规则、评分卡、表达式的内容实现整个决策流的计算,配置的决策流需要和之前设计的决策流方案完全相同,并且需要确保配置的决策流效果和线下设计的效果完全相同。
结果评估功能的核心逻辑类似配置验证需要向决策流导入需要的入参值,然后系统根据导入的值进行决策计算,与配置验证的区别是结果评估还会添加客户的好坏标识,从而实现客户全生命周期风险的管理。导入客户的好坏标识可以实现决策流中包含的所有规则、模型、表达式、评分卡以及其关联特征的分析,从而快速跟踪风控业务使用的策略的效果,实现风控策略的即时响应。
结果评估主要分为线下评估和线上评估,线下评估主要是决策流配置完成后,用于验证决策流的正确性或者用于策略设计时的辅助分析,使用者在线下评估的时候可以手动导入样本数据然后提交计算决策,等待数据计算决策完成后可以通过系统查看分析结果,同时还能够导出决策系统计算出的明细结果,包含规则命中、模型分数、评分卡分数、表达式等详细内容,通过对比构建策略时和下线评估时的详细内容实现配置的精准性验证,如果标记了样本的好坏标签,能够自动计算规则的、评分卡、模型的通过率、拒绝率、召回率、精确率、精准率、KS、IV等指标。线上评估类似线下评估,只是无需手动导入样本数据以及好坏标签,而是通过接口对接的形式,直接同步贷后的借贷行为数据,实现信贷业务的贷前业务运营如通过率、拒绝率、业务波动等指标的统计分析,以及贷前风控统计如规则拦截率和预警率、拦截明细、预警明细、模型评分分布、KS等。
五、A/B测试
A/B测试主要用于风控策略的上线验证、优化验证,借助于决策流管理模块的可视化在线配置,实现配置化的A/B测试任务。通过引入分流节点组件和陪跑任务功能实现A/B测试功能,如下图。
随机分流就是分流节点,通过分流节点能够实现占比分流和条件分流、陪跑等任务。完成决策任务后,风控报告显示单个案件决策流中的规则、模型等详细内容,监控报告中显示整体的规则、模型的监控状况,并且风控报告、监控报告还能进行A/B对比,测试集也可以通过结果评估实现线上化自动化评估。从而实现A/B测试任务配置,测试结果展示,测试结果评估全周期的管理。
六、手动进件
风控决策引擎的通常提供两种服务方式,一是提供api接口服务,二是提供web页面手动调用服务及手动进件。决策引擎的手动进件主要应用于一些系统化能力比较薄弱,或者业务前期没有标准业务系统的企业,他们能够通过决策引擎直接实现风控的决策调用。
手动进件的产品设计核心是手动进件能够选择对应业务需要执行的决策流项目,然后自动生成需要输入的决策入参字段,用户根据入参字段输入入参值,然后手动调用决策流实现决策结果的计算。手动进件不仅需要满足单个订单进件,而且还需要满足批量进件的场景,因此还需要具备批量导入调用的功能。
七、案件管理
案件管理是风控决策引擎的案件池,主要用于所有调用案件的记录存档和查询,所有风控决策引擎计算过的案件都可以在案件管理中查询。案件管理的核心是提供用户查询历史案件窗口,并且记录所有的案件的决策状态,如果决策状态失败能够通过案件管理中的“重新决策”手动触发案件再次决策。
八、审核管理
审核管理主要用于风控决策引擎中核心流程的审批,有些环节是业务流程的重要环节,需要多人确认、审核,例如规则、模型、决策流的上线和下线等。
审核管理是对审核任务的管理,一个审核任务既包含了任务的发起又包含任务的审批,因此审核管理都是面向多角色,至少包含审核发起人和审批人。审核管理对应不同的角色拥有不同的任务池,通常分为发起人的任务池和审批人的任务池。风控决策引擎中的审核任务通常都是些简单的审核任务,审核的流程有串行短链路审核和并行短链路路审核,审核链路一般都是两个环节。
审核管理的功能设计主要有两种形式,一种是主动发起审核,另一种系统预制审核。主动发起审核功能是审核任务的发起人根据业务规则自行决定该任务是否需要发起审核,如果需要就自行发起审核任务并确定审批人,然后系统根据发起人指定的审批人自动推动审核任务到审批人,审批人进行审核。系统预制审核功能是系统管理员在审核任务配置中提前配置好需要进行审核的任务,并制定这些任务的审批人,当需要审核的任务触发后,系统会根据预制的审批规则自动推送审核任务到审批人,系统预制审核省去了每次审核任务的手动发起,只需要一次配置实现后续固定的审核机制,但是也降低了审核任务的灵活性。
九、名单管理
名单管理用于黑名单、灰名单、白名单的管理,风控决策引擎在进行决策计算时可以直接对名单库进行筛查,拦截黑、灰名单案件。名单管理的设计重点是名单的唯一ID定义,通常有手机号、身份证号、设备ID三种,名单在进入名单库时都有入库原因、入库时间、在库有效期,一个名单不会是一直都是黑名单、灰名单、白名单,随着时间的变化,名单的类型可能发生改变,例如黑名单在很久后可能就不再是黑名单,因此名单会有在库有效期。名单管理功能比较简单,设计的核心主要是名单类型定义、在库有效期定义。
风控决策引擎的亮点功能核心目的是提升工作的效率和便捷性,通过这些亮点功能使得风控决策引擎的能力更加强大,满足更多不同类型的复杂业务。
#相关阅读#
作者:郑氏杂货铺,微信号:hizhengshi
本文由 @郑氏杂货铺 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自unsplash,基于CC0协议
1、一个规则可以多版本同时在线正式跑吗 ?
2、一个组件(如规则或者评分卡)他的编辑限制有哪些 ?比如评分卡我原来只有年龄,后来我再增加一个学历,这时候是走版本升级进行编辑还是需要创建新的评分卡 ?编辑和创建新的评分卡的依据是什么?
3、如果一个规则被多个决策流引用了,这时候升级这个规则对其他业务线的决策流的影响是怎么控制的?
请问,文中截图的决策引擎链接可以发一下吗
写的很好,赞一个~这个系列都干货满满,作者大大加油