随着互联网的发展,游戏、商业、慈善、博彩、餐饮等各行各业都开始走向线上。“天下繁华,皆为利来;天下繁华,皆为利来。”各种各样的线上活动都直接或间接地与金钱有关。传统支付无法满足人们快节奏的互联网生活,电子支付应运而生。然而,电子支付在给人们带来方便快捷的同时,也给支付的各方当事人带来了风险。账户盗用、虚假交易、金融诈骗等事件层出不穷。支付风险自古以来就存在,在互联网繁荣的今天,更是花样翻新。风控系统对交易、渠道、产品、用户进行监控,实时、准实时、定时地对相关数据进行分析、挖掘,从而识别交易风险,尽早发现欺诈行为,采取各种措施降低交易损失。
风险控制系统功能需求
实时监控——实时监控及控制各类支付服务的交易风险。
同步反馈——接受并处理来自各支付业务平台的支付交易信息请求,风控系统实时将处理结果返回给业务系统。
联动控制——对风险控制系统识别的风险信息进行自动化(通过人工预设的策略)的交易风险处理。
持续迭代——交易风险特征识别方法可通过系统自动排序、人工参数设定、外部资源共享等方式持续动态更新。
统计分析——针对风控系统中的各类信息和数据,相关人员可以通过组合查询、报表审核等方式监控系统运行情况、交易风险、工作绩效等。
风控系统非功能性需求
灵活性——风控规则需要频繁添加和调整,如何降低添加和修改风控规则的成本是风控系统需要解决的问题。另外,风控系统需要能够与不同的业务系统集成,又需要与业务系统保持相对独立,以方便集成。
性能——风控系统的响应时间需要小于,同时具备较大的吞吐量。风控系统应该在不影响用户体验的情况下降低风险,否则就是本末倒置。
准确度——风控系统会根据风控规则自动冻结交易相关资源。如果准确度过低,会引起大范围投诉,损害公司声誉、公众形象,失去用户信任,给公司造成巨大损失。因此,风控系统识别风险的准确度必须有一个下限。同时要注意风险识别的准确度和覆盖率是相互影响的,两者必须达到一个可以接受的平衡点。
对风险控制系统的误解
风控体系的目的是在不影响正常业务的前提下,将交易风险降低到合理的水平,风控体系并不能完全杜绝风险,因此在构建风控体系时,不应盲目追求数据的准确性和一致性。
风控体系架构
风控系统主要由以下几个部分组成:风控实时引擎、风控准实时引擎、风控定时引擎、惩罚中心、规则中心等,下面分别介绍。
风控实时引擎
支付系统会将部分当前交易信息同步传递给风控实时引擎,获取当前交易的风险评分及处理建议。风险总分为100分,分数越高风险越大。-1表示风控系统无法评估当前交易的风险,一般是指风控系统尚未能够获取当前交易的正面或负面信息。风控实时引擎面临的最大挑战是性能,实时引擎必须在内部完成支付交易的风险评估,否则会影响用户体验。
风控实时引擎根据公司累计风控数据及第三方风控数据进行风险评估,公司风控数据主要来源于风控准实时引擎和风控定时引擎。
在规则引擎的基础上构建了风控实时引擎,以提高系统的灵活性和可配置性。
下图是风控报表的领域模型:
规则引擎的优点
风控系统中风控规则变化频繁,其他部分相对稳定,通过引入规则引擎,可以解耦系统与规则,提高复杂逻辑的可维护性,提高规则的可读性和可理解性。
风控准实时引擎
交易欺诈具有一定的隐蔽性,并不是所有的风险都能被实时正确评估,有些情况下需要分析近一段时间的数据来判断欺诈,比如分析最近一个月的用户行为。准实时风控引擎从消息服务器获取交易数据,对交易数据流进行异步分析,分析结果通过风控服务存入风控数据库,供实时风控引擎评估交易风险。准实时风控引擎从发现异常到风控数据生效所需时间更短,可以有效阻止交易风险的扩大。
风控系统初期搭建时,准实时风控引擎往往通过消息监听器消费交易消息,将中间数据存储在缓存中,并对数据进行多维分析。由于需要针对每个指标开发相应的程序,导致风控规则开发成本高、上线周期长。为了解决该问题,提高系统的灵活性和可配置性,在风控系统2.0版本中引入了CEP引擎和规则引擎。
风控准实时引擎需要用到、、IO AMQP、、等组件,其中是我们对的扩展,主要用于提高可配置性,丰富IO功能,弥补缺陷。
下图是风控准实时引擎架构图:
什么是 CEP
事件驱动是一种监控和分析信息流并从中得出推论的方法。CEP()是复杂事件驱动,它结合来自多个数据源的数据来监控和分析信息流并推断一些复杂事件或模式。CEP 的目的是识别一些有意义的事件,例如机会和威胁,并尽快做出响应。
为了满足需要对事件进行分析和响应的需求,一些公司开发了 CEP 引擎,以下是一些典型的应用示例:
业务流程管理和自动化(流程监控、业务活动监控、报告异常)
金融(自动交易、欺诈检测、风险管理)
网络和应用程序监控(入侵检测、SLA 监控)
传感器网络应用(RFID读取、生产线调度和控制)
CEP 技术选择
下面列举了部分CEP产品,您可以根据自身情况进行选择。
开源 CEP 产品:

商业 CEP 产品:
IBM(IBM ODM)
优势
改进的数据窗口机制
目前支持的数据窗口大概有30种,深入理解窗口是应用的关键,下表列举了几种常用的数据窗口:
时间:
:
时间:
EPL语句的语法与SQL类似,降低了学习成本。
事件处理语言 (EPL) 是 SQL 标准语言的扩展,提供 FROM、BY 和 BY 等子句。
使用灵活
它提供了丰富的API,可以独立部署或集成到任何应用程序中。
支持多种方式获取结果
缺点
所有统计分析的中间数据都存放在内存中,无法跨服务器部署,只能部署在单机上。内存有限,存在单点故障,全内存运行会导致系统重启后中间数据丢失且无法恢复。这些缺点对于风控系统来说都是可以接受的,对风控系统没有实质性的影响。
风控择时引擎
有些非常隐蔽的交易欺诈行为很难通过实时或准实时风控引擎发现,只有通过分析跨月或跨年的用户数据才能发现这些风险。定时风控引擎主要用于对支付相关数据进行深度挖掘,并建立相应的风控模型,典型的应用场景是用户信用评级模型、用户行为分析等。
时机风控引擎构建在集群之上。
惩罚中心
惩罚中心负责积累风控数据,提供奖惩相关服务。风控实时引擎、风控准实时引擎、风控定时引擎会调用惩罚中心的服务查询或保存风控数据。惩罚中心针对不同维度提供多种惩罚策略和奖励策略。风控实时引擎在识别交易风险时,根据规则综合考虑奖惩相关数据,提高风险识别准确率。
下图是惩罚中心领域模型:
风险控制体系建设往往分阶段进行,一般分为以下三个阶段:
第一阶段:核心任务:
建设基础设施
在线申请访问
移动应用程序访问
建立有效的监测队伍和工作机制
第二阶段:增强任务:
交易监控功能
风险控制模型完善
监控团队能力和工作机制
第三阶段:后续开发:
持续优化
新应用程序访问
团队技能是慢慢积累的,对风控体系、风控模型的理解也需要时间。如果初期搭建的太全面,会增加搭建工作的不确定性,一旦技术或者业务方向出现偏差,会给公司带来巨大的损失。当前一阶段的工作产生效益的时候,对下一阶段工作的抵抗力就会小很多。随时保持团队对项目的掌控力非常重要。这是我们在搭建风控体系过程中的感受。