在线支付之风控系统架构选型

风控系统介绍

伴随着互联网的发展，游戏、商贸、慈善、博彩、餐饮等各行各业都开始触网。“天下熙熙，皆为利来；天下攘攘，皆为利往”，种类繁多的网络活动直接或间接的都与钱相关，传统的支付不能满足人们快节奏的互联网生活，电子支付应运而生，但电子支付给人们带来方便快捷的同时也给参与支付的各方带来了风险，账号盗用、虚假交易、金融欺诈等事件层出不穷。支付风险自古就存在，在互联网繁荣的今天只是多了些新花样，风控系统就是通过监控交易、渠道、产品、用户，对相关数据进行实时、准实时、定时的分析、挖掘，从而识别交易风险，尽早发现欺诈，采取各种措施降低交易损失。

风控系统功能性需求

• 实时监控——针对各类支付业务交易风险的事中监测与控制。
• 同步反馈——接受并处理各支付业务平台的支付交易信息请求，并由风控系统将处理结果实时返回业务系统。
• 联动控制——对风控系统识别出的风险信息，进行系统自动化（通过人工预置策略实现）交易风险处理。
• 持续迭代——交易风险特征识别方式可以通过系统自动整理、人工设定参数、外部资源共享等方式进行持续动态更新。
• 统计分析——对于风控系统中存在的各类信息和数据，有关人员可以通过组合查询和查阅报告等方式，对系统运行情况、交易风险情况、岗位绩效情况等进行监督。

风控系统非功能性需求

• 灵活性——风控规则需要经常新增以及调整，如何降低风控规则新增、修改的成本是风控系统需要解决的一个问题。此外，风控系统需要能够与不同业务系统进行集成，需要和业务系统保持相对的独立，以利于集成。
• 性能——风控系统响应时间需要小于 100ms 同时能够有很大的吞吐量，风控系统降低风险的同时不能影响用户体验，否则就本末倒置了。
• 准确性——风控系统根据风控规则会自动冻交易相关资源等，如果准确率过低会引起大面积投诉，损害公司信誉、公众形象使用失去信心，给公司带来巨大的损失，所以风控系统识别风险的准确率必需要有一个下限，同时要注意风险识别的准确率和覆盖率是相互影响的两者要达到一个可以接受的平衡。

风控系统的误区

风控系统的目的是在不影响正常业务的同时把交易风险降低到合理的水平，风控系统并不能消灭风险，所以在建设风控系统时不可盲目追求数据的准确性以及一致性。

风控系统架构

风控系统主要由以下几个部分构成：风控实时引擎、风控准实时引擎、风控定时引擎、惩罚中心、规则中心等，下面分别进行介绍。

风控实时引擎

支付系统会把当前交易部分信息同步传递给风控实时引擎以获取当前交易的风险评分和处理建议。风险评分总分为 100，分数越高风险越大，-1 代表风控系统不能对当前交易进行评估风险，一般是指风控系统没能获取到当前交易正面或负面的信息。风控实时引擎最大的挑战是性能，实时引擎对支付交易进行风险评估必须在 100ms 内完成，否则会影响用户体验。

风控实时引擎依据公司积累的风控数据以及第三方风控数据对进行风险评估。公司风控数据主要来自风控准实时引擎和风控定时引擎。

风控实时引擎建立在规则引擎 Drools 基础上，目的是为了提高系统的灵活性和可配置性。

下图是风控报告的域模型：

规则引擎优点

风控系统中风控规则变动比较频繁，其它部分相对稳定，通过引入规则引擎可以解耦系统与规则、提高复杂逻辑的可维护性、提高规则的可读性以及可理解性。

风控准实时引擎

交易欺诈行为具备一定的隐蔽性，不是所有风险都能实时的作出正确的评估，某些情况下需要通过对最近一段时间的数据进行分析才能确定欺诈行为，例如：对最近一个月的用户行为进行分析。风控准实时引擎从消息服务器获取交易数据，对交易数据流作异步分析，分析的结果通过风控服务存入风控数据库，供实时风控引擎评估交易风险。风控准实时引擎从发现异常到风控数据生效的时间在 100ms 以内，可以有效防止交易风险扩大。

风控系统初始建设时中风控准实时引擎往往是通过消息监听器消费交易消息，把中间数据存储在 Redis 缓存上，对数据进行多维度分析。由于需要针对每项指标开发相应程序，风控规则开发成本较高、上线周期长，为了解决这个问题以及提高系统的灵活性、可配置性，在风控系统 2.0 版本引入了 CEP 引擎 Esper 以及规则引擎 Drools。

风控准实时引擎需要使用到 Drools、Esper、Esper IO AMQP、Esper Extension、Spring 等组件，其中 Esper Extension 是我们对 Esper 的扩展，主要用来提高 Esper 可配置性以及丰富 Esper IO 功能以及弥补 Esper 缺陷。

下图是风控准实时引擎架构：

什么是 CEP

事件驱动是一种监测、分析信息流从中得出推论的方法。CEP(Complex Event Processing) 也就是复杂事件驱动，是结合多种数据源的数据对信息流进行监测、分析从推理出一些复杂的事件或模式，CEP 的目的是识别出一些有意义的事件，例如：机遇、威胁，并且尽可能快的作出反应。

CEP 引擎已经被一些公司开发出来，用来满足那些需要分析事件并对其作出反应的的需求，下面是一些典型的应用示例：

• 业务流程管理和自动化（流程监控、商业活动监控、报告异常）
• 金融（自动化交易、欺诈检测、风险管理）
• 网络以及应用监控（入侵检测、SLA 监测）
• 传感器网络应用（读取 RFID、生产线调度与控制）

CEP 技术选型

下面列出一些 CEP 产品，大家可以根据自己的情况选用。
开源 CEP 产品：

• JBoss Drools Fusion
• EsperTech Esper
• Triceps

商业 CEP 产品：

• EsperTech Esper Enterprise Edition
• EsperTech EsperHA
• IBM Operational Decision Manager (IBM ODM)
• Oracle Stream Explorer platform
• TIBCO BusinessEvents
• TIBCO StreamBase

Esper 优点

数据窗口机制完善

Esper 目前支持大约 30 种数据窗口，深入理解窗口是应用 Esper 的关键，下面表格列出常用的几种：

Time Window：

Length Window：

Time Batch Window：

EPL 语句的语法与 SQL 相似降低学习成本

事件处理语言（EPL）是 SQL 标准语言并做了扩展，提供了 SELECT、 FROM、 WHERE、 GROUP BY、HAVING 和 ORDER BY 等子句。

使用方式灵活

Esper 提供了丰富的 API，可以独立部署也可以集成进任何应用。

支持多种获取结果方式

Esper 缺点

Esper 统计分析的中间数据全部是存储在内存中，不能跨服务器，只能单机部署，内存有限，存在单点故障，由于全内存操作，系统重启后中间数据就会丢失无法恢复。Esper 的这些缺点风控系统都可以接受，对风控系统没有实质的影响。

风控定时引擎

某些非常隐蔽的交易欺诈通过实时或准实时风控引擎很难发现，这些风险需要通过分析用户跨月或跨年的数据才能识别。定时风控引擎主要用来定时对支付相关等数据进行深度挖掘，建立对应的风控模型，典型应用场景是用户的信用等级模型以及用户行为分析。

定时风控引擎构建在 Hadoop 集群上。

惩罚中心

惩罚中心负责积累风控数据并提供奖励和惩罚的相关服务，风控实时引擎、风控准实时引擎、风控定时引擎会调用惩罚中心的服务查询或保存风控数据。惩罚中心针对不同维度提供多种惩罚策略以及多种奖励策略。风控实时引擎在识别交易风险时根据规则综合考虑奖励以及惩罚相关数据以提高风险识别准确率。

下图是处罚中心域模型：

风控系统的建设往往是分阶段实施的，一般分为以下三个阶段：

第一阶段：核心任务：

• 搭建基础架构
• 网上应用接入
• 手机应用接入
• 建立起有效的监控团队和工作机制

第二阶段：提升性任务：

• 交易监控能力
• 风控模型提炼
• 监控团队能力和工作机制

第三阶段：后续发展：

• 持续优化
• 新应用接入

团队技能是逐步积累的，对风控系统以及风控模型的理解也需要时日，如果初始建设阶段求大求全会使建设工作增加不确定性，一旦出现技术或业务方向上的偏差会给公司带来巨大的损失。循序渐进逐步建设，在前一阶段的工作产生效益时再去进行下一阶段的工作阻力会小很多，任何时候保持团队对项目的控制力都是相当重要的，这是我们在建设风控系统的过程中的一点感悟。

作者简介

康大强，拥有 14 年企业与互联网开发、设计、架构经验；历任金蝶软件、芒果网、华为、OPPO 架构师；目前专注于文法分析、工作流、高并发系统、大数据以及复杂业务分析处理。