风控系统随着业务发展多元化，场景复杂化，市场监管趋严，商业纵深整合的需要以及黑产专业化，风险对抗加剧，也经历着不断的演进与升级，今天就来一起探究这些年风控系统经历过的演进与升级。
第一代风控系统大多基于规则策略做硬编码开发，各家系统大同小异，毕竟满足业务需求是第一位。而其最大的问题就是风控策略流程变更迭代周期长、效率低，毕竟就算调整一个阈值也需要 IT 开发人员排期、开发、测试、部署流程走一遍，平均每次迭代要 1-2 天。此外，由于频繁上线加之小需求繁杂，需求沟通差异（开发人员计算机工程背景与风控分析人员数据分析和金融背景）导致的线上问题日渐频繁，难以维护。硬编码为主的系统难以满足更复杂、快速迭代的风控需求，于是，如何解决迭代效率成为首先要解决的问题。以 drools 为代表的规则引擎（专家系统）成为救命稻草，通过引入配置化脚本简化风控策略调整。其编码风格如下：rule "test_rule1"
when
$user: User(age >= 18)
then
$user.setRank("A")
end
通过掌握脚本语言语法，即可配置所需规则策略，再通过代码引擎自动执行，将规则策略调整与代码分离，降低开发测试要求，大大提高了迭代效率。但这一代风控引擎需要额外引入新的脚本语法学习成本，也很难直接交付给风控分析师，大多仍需要 IT 开发来完成迭代。算是决策引擎的过渡版本，所以归为第 1.5 代风控系统。
▌第二代：智能决策引擎
第二代风控决策引擎系统，具备简单易用的图形化操作后台，支持风控分析师后台调整风控规则和流程，并一键热部署生效，大大提升风控策略调整效率。支持 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 等指标；以及底层特征的缺失率、零值率等指标。通过“录制”线上流量的方式，将决策流执行过程所依赖的数据特征，及请求入参和结果快照下来。此数据可以作为流量回放和模型回溯的源数据，通过部署离线引擎，可以在线下对决策流调整进行效果评估与验证，以此来降低决策流变更带来的的风险。同理，通过离线回溯进行模型性能分析，结合模型陪跑，可以实现新模型平滑决策。
由于决策流配置长短不一导致决策引擎执行时间不确定，属于不均衡延时系统，因此其部署和执行上必须要考虑隔离方案以保障系统高可用。
※ 长短请求调度隔离 / 同步异步隔离
一般像前筛、预审等场景配置规则较少，需要快速响应（<1s），同步返回。而授信、支用等场景需要校验更多，响应时间可以更长（5-20 s），可以采用异步方式获取结果。
在部署决策引擎执行决策流时针对不同场景性能要求和调用方式差异采取隔离部署，降低因资源池打满而造成的互相影响。
※ 业务线流量调度资源隔离
作为统一风控中台，如面对多条业务线接入，一定要减少相互影响，由于决策引擎对数据库依赖较小，因此数据层只做逻辑隔离，但引擎应用层需要保障各业务有独立资源，并在网关层（调度层）做分流路由。可以依托 K8s 的 label 对资源分组，通过请求 header 标签做流量调度。此外保障高可用做好集群负载均衡、服务治理、限流、熔断、降级方案，以及请求链路监控等。
4、平台化工程化
当决策引擎完成工程化后，大量的风控开发工作集中在数据源 API 接入和特征开发上，而借助工程化、平台化可以进一步减少开发工作。数据源接入大多工作可模板化解决，通过配置请求地址 、请求方式、超时时间等必要信息，再结合入参、出参报文映射解析实现模板化接入数据源。入参通过配置参数映射或常量值完成。简单的报文解析，可以通过 Jsonp 的方式，直接从结果集中提取关键字段。复杂的报文解析，需要进一步代码加工工作，也可以开发一些常用的函数辅助完成粗加工。
对于批量加载特征且有多源依赖的，可以通过构造接口依赖关系图，并通过逐层调用执行加工。随着大规模机器学习的应用，为进一步提升模型迭代效率，让模型迭代周期从月级降低到天级，将模型工程化，打造出自动建模平台及模型管理平台，整体工程分为离线工程和在线工程两部分。离线工程，机器学习平台，主要围绕模型训练和回溯，通过自动特征工程、自动建模技术（AutoML）提高模型迭代效率和效果。按模型开发流程依次分为：数据管理（维护样本和数据集），数据挖掘（自动特征工程），算法选择（支持 XGBoost/LightGBM等），模型训练（训练任务管理），模型调优（自动调参），效果评估（一键打分），发布上线（输出标准 PMML 模型和 python pickle 模型）。
在线工程，模型引擎，通过加载模型库模型文件（支持 PMML 和 pickle），完成实时预测打分，并提供 API 供决策引擎调用。
模型管理平台，包括模型资产管理、生命周期管控、监控报警管理，整合机器学习平台实现模型生成后一键热部署，整合决策引擎配置实现关联调用和在线陪跑。总结：第三代风控系统，针对业务的高速发展，满足互联网三高场景，全面平台化，打造出一个完整的风控中台。
▌第四代：数字化智能化创新
第四代风控系统通过全面大数据、人工智能、云计算、区块链等技术实现进一步提质增效，个人觉得大多数企业仍处于此探索阶段，故称为数字化智能化创新阶段。
1、智能化决策
智能化决策基于数据分析、机器学习、深度学习、专家经验，通过归因下探，规则量化，全链路过程监控追踪，结果回溯等手段实现规则策略自动调优、自动生成与推荐，达成风控“自动驾驶”。用以解决人工配置操作风险、策略效果衰减以及迭代调整滞后等问题。实践中自动调优风控策略以及自适应模型也会带来“可解释性”问题和稳定性因素，需要大量 AB 实验探索，与专家经验对比，人工干预和过程管控不可或缺。随着黑产职业化分工和集团化发展，金融风险呈现规模化特征，给传统规则策略和模型识别带来巨大挑战，针对个体行为属性的特征难以识别团伙行为的规模风险，因此关联分析需求及图解决方案成为风控发展的新趋势。
图数据库应用，图数据库相比关系型数据库具有更高效的关联查询性能。通过图数据库群体特征（如二度联系人中黑名单用户占比）能更好的识别团伙欺诈；通过图计算特征进行子图匹配，发现相似模式风险账号；利用社区发现算法进行社群发现，识别群体风险；通过图连通性、路径发现做失联修复；通过构建用户 360 视图（异构图）完善用户画像，更好地发现信贷风险；此外基于图神经网络的深度学习技术成为图应用的发展趋势。
实践中 Neo4j 代表的原生图数据库，满足一般中小规模数据量级，有更好的性能表现，但其集群版本不支持开源；JanusGraph 分布式数据库，可以构建更大规模图，性能方面略有不足。购买商业版或自造轮子开发图数据库，解决海量数据构建异构图，原生图，以及查询性能成为关键。
3、隐私计算与联邦学习
随着数据安全法和个人信息保护法的实施，数据安全和隐私保护日趋严格，为了满足“原始数据不出域，数据可用不可见”，隐私计算解决方案成为破局之道。隐私计算分为联邦学习（FL）、安全多方计算（MPC）、可信执行环境（TEE）等。联邦学习是通过数据加密计算，分布式机器学习，实现各公司间数据在不出库的前提下完成联合建模需求。FATE 框架使用多方安全计算 (MPC) 以及同态加密 (HE) 技术构建底层安全计算协议，以此支持不同种类的机器学习的安全计算，包括逻辑回归、基于树的算法、深度学习和迁移学习等，基于此框架可快速构建隐私计算体系。实践中由于要求合作双方部署同套隐私计算方案，而市面上隐私计算体系割裂，不同解决方案难以互通，成本较高成为主要限制屏障。
4、区块链
区块链去中心化、不可篡改、开放自治的特性，建立数据联盟链，既保障了数据的可信赖，又可利用其网络广播特性实现数据共享，有效解决大数据风控的数据孤岛问题；在供应链金融方面区块链提供信用保证和履约保证，提供更好的风控解决方案；在金融智能合约应用上，通过区块链可编程特点，构建智能合约，有效防范了人为操作风险。区块链技术+大数据+人工智能的组合也是未来风控的发展趋势。
▌总结 Roadmap
风控系统演进之路，从不断提升效率实现自动化，解决性能、可靠性问题，到全面数字化、智能化升级，不断探索应用新技术手段提升风控效果。各家系统发展和迭代方式不同，但基本演进思路和发展方向殊途同归。感谢阅读！欢迎与我交流提出您的见解，觉得文章可以欢迎分享、点赞支持。
