金融风控系统的演进与升级:从第一代到第四代

技术琐话 2022-06-28 08:48 发表于四川

以下文章来源于技术岁月，作者贺鹏Kavin

风控系统随着业务发展多元化，场景复杂化，市场监管趋严，商业纵深整合的需要以及黑产专业化，风险对抗加剧，也经历着不断的演进与升级，今天就来一起探究这些年风控系统经历过的演进与升级。

▌第一代：单体系统/规则硬编码第一代风控系统大多基于规则策略做硬编码开发，各家系统大同小异，毕竟满足业务需求是第一位。而其最大的问题就是风控策略流程变更迭代周期长、效率低，毕竟就算调整一个阈值也需要 IT 开发人员排期、开发、测试、部署流程走一遍，平均每次迭代要 1-2 天。此外，由于频繁上线加之小需求繁杂，需求沟通差异（开发人员计算机工程背景与风控分析人员数据分析和金融背景）导致的线上问题日渐频繁，难以维护。硬编码为主的系统难以满足更复杂、快速迭代的风控需求，于是，如何解决迭代效率成为首先要解决的问题。▌第 1.5 代：规则引擎/专家系统以 drools 为代表的规则引擎（专家系统）成为救命稻草，通过引入配置化脚本简化风控策略调整。其编码风格如下：

rule "test_rule1"
    when
        $user: User(age >= 18)
    then
        $user.setRank("A")
end

通过掌握脚本语言语法，即可配置所需规则策略，再通过代码引擎自动执行，将规则策略调整与代码分离，降低开发测试要求，大大提高了迭代效率。但这一代风控引擎需要额外引入新的脚本语法学习成本，也很难直接交付给风控分析师，大多仍需要 IT 开发来完成迭代。算是决策引擎的过渡版本，所以归为第 1.5 代风控系统。

▌第二代：智能决策引擎

1、图形化决策引擎第二代风控决策引擎系统，具备简单易用的图形化操作后台，支持风控分析师后台调整风控规则和流程，并一键热部署生效，大大提升风控策略调整效率。 支持 BPMN 标准图形化风控决策流配置，还支持冠军挑战者 / AB Test 分流测试，以及条件分流配置。
支持决策表、决策树、决策矩阵、评分卡、表达式等更复杂规则决策配置方式。 第二代风控决策引擎彻底解决了风控策略调整效率问题，实现了风控策略流程迭代从天级降到小时级。

2、机器学习模型

在解决效率问题的同时，效果是另一个待提升的问题。随着黑产的专业化发展，单纯的规则配置可以通过反复测试试探阈值而被突破，规则调整变更手段滞后难起到最佳效果，引入机器学习等智能化模型成了进一步解决问题的银弹，这也是现在常说的“智能风控”的开始。

通过将模型与决策引擎整合，将模型打分作为重要决策特征，提升决策效果。

3、大数据应用

引入三方征信数据补充规则与模型，充分利用大数据优势，可以更好地提高风险识别能力，也就是“大数据风控”。

总结：第二代风控系统，以高效的决策引擎为主，引入了机器学习模型和大数据，大幅提升了风控迭代效率和风险识别效果。

▌第三代：智能风控大中台

随着互联网高速发展，在高性能、可靠性、通用性、风险识别等方面提出了更高的要求和挑战。第三代风控系统满足精细化运营需求，表现为支持高性能、高度平台化、智能化的风控大中台，下面分别展开描述。

1、系统高性能

互联网场景下，秒级风控决策能力成了普遍性要求。在决策流程短，特征涉及少，没有太多外部数据源的情况下，比较容易达成。而随着决策流配置更长，规则策略更多，特征繁多且加工逻辑复杂，并引入一堆外部数据源的情况下，提升执行效率成为一个更复杂的系统性能工程亟待解决。

※提升特征计算性能

基本思路是空间换时间。如果每次决策流执行时才去实时计算特征，那么特征计算所消耗的时间将会导致整体流程时间变长。通过预计算方式提前完成特征计算，将计算结果冗余 KV 存储中，执行时即可 O(1）取出所需特征数据。

预计算的方案亦有其局限性：

首先，准确性上可能不如实时计算，比如预计算结果后发生了数据变更，所以触发预计算时机需要考虑。可以通过 CDC （变更数据捕获）的方案，来实现每一次数据变更后完成一次计算变更，提高特征数据的准确率。

其次，可能存在决策发生时预计算未完成，导致特征数据缺失。此时处理方案是忽略，或是失败异常，或是触发实时计算，亦或是要求必须预计算结束通知才能做决策调用，需要根据业务需求来择优。

再有，针对三方数据源接口存在收费问题，如果预计算后并没有使用，可能导致数据成本浪费，所以一般只对内部数据进行预计算，对三方数据进行实时计算。此外，可以对历史数据（t-1）进行批处理计算，再融合当日数据进行融合计算，可进一步提升计算效率，也是大数据 Lambda 架构形式，但对于需要做全局去重统计的数据可能会损失精度。

※ 提升并发执行能力

决策引擎的流程配置，在一定程度上会影响其执行效率。通过配置并行网关，节点并发执行，可缩短执行时间。但风控分析师一般关注风控效果和成本，让其兼顾考虑并行执行有些强人所难。因此，有必要让系统自动分析完成高效并发执行流程。

过程可以分发布时（将配置的决策流转成决策引擎执行的 DSL），运行时（决策引擎执行 DSL）两个阶段，类似某些编程语言的编译期和运行时。发布时可以提示方案修改建议，运行时可以强制按最优并行度来执行。

提高并行度，分析决策流图节点依赖关系，将无上下文依赖的节点并行执行，可以充分利用 CPU 多核以及并发批量调用特征。

对上图进行广度优先遍历，获取一个 List(A,s1,B,E,C,F,D) ，如果后继节点依赖特征不与前序节点输出重合，那么即可认为前后节点没有上下文依赖，可以并发执行。此外 s1 排它网关会选择 BCD 或 EFD 一条路径执行，可以进行剪枝操作。此外还要考虑有成本数据特征，以及提前中断情况，需要结合业务场景需求合理做出并发优化。

2、系统高可靠

※ 决策流配置校验规则配置是风控的一道重要防线，如何防止配置出错这类操作风险造成业务损失？决策流校验是重要的保障。既要保障减少业务耦合打造决策引擎的通用性，也要降低配置出错率让操作风险可控，因此每一条校验规则都是在实践与犯错中总结而成。校验同样分为发布时校验和运行时校验两部分治理：

发布时校验，保障决策流无明显语法错误，分支闭合，流程完整。如 ab 分流网关要求所有分支流量之和必须等于 100%；决策矩阵要求所有分箱区间必须连续无交叉且覆盖所有取值范围；下游节点依赖某决策树输出特征，上游必须配置该决策树节点；只有分支节点出度可大于 1 其他类型必须为 1；决策流构建成有向无环图（DAG）做成环检测避免执行无法终止...

运行时校验，针对某分支或模式匹配失败而导致决策流无法正常流转下去，进入异常案件中。常见如遇特征缺失（获取失败或其他原因），忽略继续执行，抛异常，或者强制失败。

※ 实时监控报警

打造全方位分层监控报警，系统层、链路层、应用层、业务层，除传统监控报警之外，针对风控指标和模型效果的监控必不可少。针对模型调用情况，风控通过率的监控；基于模型分分箱条件下的数据和效果稳定性，计算出 PSI、AUC、KS 等指标；以及底层特征的缺失率、零值率等指标。※ 流量回放与模型回溯

通过“录制”线上流量的方式，将决策流执行过程所依赖的数据特征，及请求入参和结果快照下来。此数据可以作为流量回放和模型回溯的源数据，通过部署离线引擎，可以在线下对决策流调整进行效果评估与验证，以此来降低决策流变更带来的的风险。同理，通过离线回溯进行模型性能分析，结合模型陪跑，可以实现新模型平滑决策。

3、系统高可用由于决策流配置长短不一导致决策引擎执行时间不确定，属于不均衡延时系统，因此其部署和执行上必须要考虑隔离方案以保障系统高可用。

※ 长短请求调度隔离 / 同步异步隔离

一般像前筛、预审等场景配置规则较少，需要快速响应（<1s），同步返回。而授信、支用等场景需要校验更多，响应时间可以更长（5-20 s），可以采用异步方式获取结果。
在部署决策引擎执行决策流时针对不同场景性能要求和调用方式差异采取隔离部署，降低因资源池打满而造成的互相影响。

※ 业务线流量调度资源隔离

作为统一风控中台，如面对多条业务线接入，一定要减少相互影响，由于决策引擎对数据库依赖较小，因此数据层只做逻辑隔离，但引擎应用层需要保障各业务有独立资源，并在网关层（调度层）做分流路由。可以依托 K8s 的 label 对资源分组，通过请求 header 标签做流量调度。 此外保障高可用做好集群负载均衡、服务治理、限流、熔断、降级方案，以及请求链路监控等。