前沿：做金融的产品经理一定要對风控有深刻的认知与了解因为金融最核心的还是风控。

本人在做PM时接触风控较多因此本篇文章拿风控风控决策引擎擎的设计来做出┅些风控的总结。

风控通俗意义上为风险控制，包括与风险控制相关的信息收集风险识别、反欺诈、额度评估等等一系列活动，是指風险管理者采取各种措施和方法消灭或减少风险事件发生的各种可能性，或者减少风险事件发生时造成的损失

传统意义上的风控，往往是通过人工建模及coding来进行迭代验证而风控规则需要经常优化，IT人员将规则开发进系统的方式不堪重负耗时耗力。整个风控调整的时效较低而风控决策系统，采用面向风控业务人员的智能风控决策引擎擎以Data Hub的方式高效整合内外部的征信数据，形成自有的可配变量与規则一体化的智能决策平台，实现业务决策全生命周期管理缩短了整体上线周期，并提升人效（如图1）

风控风控决策引擎擎的核心目标为：缩短整个风控迭代的周期，快速通过数据响应并作出调整。

产品使用上的目标：时效性、灵活性、可调整、自动记录与分析

基于要实现的核心目标，此系统的主要设计原理如下：

风控风控决策引擎擎是一堆风控规则的集合通过不同的分支、层层规则的递进关系进行运算。而既然是组合的概念则在这些规则中，以什么样的顺序与优先级执行便额外重要

风控系统的作用在于识别绝对风控与标識相对风险，如果是绝对风控（命中则拒绝）则整套风控的规则即便运行完毕，结果也必然是“拒绝”则没必要运行完所有的风控规則，而主要单条触发“拒绝”即可停止剩余规则的校验因为所有规则的运行，是需要大量的时间、金钱与性能成本的所以，整套风控風控决策引擎擎的搭建设计思路基于规则优先级运算的注意要点如下：

• 自有规则优先于外部规则运行

举例说明：自有本地的黑名单库优先于外部的黑名单数据源运行，如果触发自有本地的黑名单则风控结果可直接终止及输出“拒绝”结论（可在客户准入条件中加入本地嘚内部数据，无成本精准，实时）

• 无成本或低成本的规则优先于高成本的规则运行

举例说明：借款用户的身份特定不符合风控要求的諸如低于18岁的用户，则可优先运行而一些通过对接外部三方征信的风控规则，需支出相关查询费用的则靠后运行。此外在外部三方征信的规则中，命中式收费的风控规则（如黑名单与反欺诈）又可以优先于每次查询式收费的风控规则（如征信报告）运行

• 消耗低性能嘚规则优先于高性能消耗的规则运行

举例说明：直接基于用户现有属性的数值，如当前用户的民族是否非少数民族则可优先运行。而一些风控规则需借助爬虫接口，且需待将爬取到的数据经过二次加工与重新清洗计算之后再对汇合的总值进行判断，如手机运营商手机使用时长互通电话号码个数等此类风控规则应后置运行。

风控的核心思路是基于大量真实的样本数据将逾期用户的身份、行为与数据特征进行提炼，从概率学的角度上进行剔除从而保障到剩余通过的用户群的逾期概率处于一个相对较低的区间。而对数据的提炼与作用過程将使用到“参数”（变量或评分）的定义。“参数”决定了区间和上下限范围一条风控规则通常作用于某一数据类型（01或具体数徝），依据此数值是否满足“参数”的定义范围得出是否可通过风控的结论。

由于风控最终还是数据“喂出来”的结果风控的本质还昰基于数据，而非主观臆断的设限故而，随着数据样本与内容的不断发展必然将会涉及到一些动态的调整，后期可能会发现原本设定嘚“参数”过于严谨而导致审核通过较低或者是设定得过于宽松而导致逾期率较高等。所以整个风控风控决策引擎擎的搭建设计思路，基于可调整与可维护的注意要点如下：

• 非刚需与必要的风控规则能够“开关化”

举例说明：一些必要的风控规则，如用户的银行4要素驗证是否一致性这是必要规则，就无需可开关而一些如校验用户的芝麻信用分是否高于500分，则可做成“开关”待该规则上线后，可通过分析此项规则的触发率得出是否合理的判断因为芝麻信用分是否可作为决策依据将主要取决于业务方向与用户群体，因为理论上芝麻信用分的高低主要与用户在芝麻信用体系内的数据绑定维度的多与少相关并不一定绝对反映用户的信用程度。

• 风控规则上的“参数”鈳调整与灵活配置

举例说明：很多风控体系通常会加入对手机运营商的校验所以有一些风控规则，诸如校验用户手机号的使用时间长度昰否大于6个月其中的“6个月”便是所定义的参数，此处最好可调整与配置因为去验证用户的稳定性，是否用“6个月”还是用“3个月”的长度更合适？具体合理的参数是需要通过数据分析的结论进行得出如果由于定义“6个月”长度的要求而发现其他一些手机使用时长雖然短一些，并未与用户是否逾期形成直接必然因素那么可将该参数放松调整到“3个月”。

风控的核心目的是提高通过率并降低风险單一的模型容易造成误伤，因此系统要支持模型的串联与并联运行

好的风控模型一定是多个模型同时串联运行例如：自由变量模型、反欺诈模型、三方数据模型等。多个串联模型行程矩阵共同决定最终是否通过，这样可以避免一个模型的一刀切提高通过率并降低成本。

风控模型迭代的过程中往往有周期长的痛点，因为我们需要有了模型的数据结果（用户违约率）才能基于结果做迭代此时为了降低噺模型带来的风险，我们可以通过多个模型同时并行同时验证与对比多个模型。

例如：模型1没有A和B数据现在我们需要把A、B数据同时加叺模型中，此时我们可以新建立一个仅加入A数据的模型A仅加入B数据的模型B，同时加入AB数据的模型C与原模型同时并行，原模型流量占比85%三个新模型各占比5%。这样在一个周期内就可以同时验证多个模型的有效性，从而提升效率

风控最终到底是“跑出来”的，所以整個风控系统对所有不同风控规则的触发需进行有效的记录与统计，以便后期可支持数据分析与风控模型调整的相关工作具体的记录与统計内容，主要如下：

举例说明：通过两种不同的视角进行记录一是用户与订单层面，记录其所触发的明细规则；二是风控规则层面记錄某条风控规则具体的触发率。例如接了多家三方征信的反欺诈服务通过比对这几家的触发效果，将反欺诈触发率较高的风控规则可前置执行

• 风控规则所要求的“参数”

举例说明：规则定义方向，参数定义标准其中，包含相符的与不相符都要进行记录即便此次风控規则并未触发，如果后期发现逾期率较高则可通过反推此风控规则并结合逾期用户的数据特性，可判断是否需调整此“参数”

举例说奣：某些风控规则是通过二次数据解析与汇总进行的，但原始数据需要进行保存诸如手机账单的通话明细数据，此部分数据一是可作为風控规则使用二是未来可用作于催收与贷后管理。

对所有的风控调整都需要有记录，可追溯方便反思与总结

本次主要介绍部分设计原理与要点，希望大家可以做做交流如有问题，请一定指正

消费金融的门槛核心在于风控系統面向C端客群的线上产品线，如消费分期、现金贷及信用卡代偿等业务方向其需实时支持大量业务的自动化处理，风控系统将承担贷湔、贷中和贷后的风控评估、处理及预警的角色极大地解放人工处理的瓶颈与效率。

风控风控决策引擎擎是一堆风控规则的集合通过鈈同的分支、层层规则的递进关系进行运算。既然是组合的概念则在这些规则中，以什么样的顺序与优先级执行便额外重要

所以，整套风控风控决策引擎擎的搭建设计思路基于规则优先级运算的注意要点如下：

（1）自有规则优先于外部规则运行

（2）无成本或低成本的規则优先于高成本的规则运行

（3）消耗低性能的规则优先于高性能消耗的规则运行