【摘要】当前,金融机构出于对自身业务风险防范及保障客户资金安全的需要,都在探索使用新型信息技术应用于业务开展过程来识别、预警风险,提高风险防范能力,本文分享了某城商行基于大数据技术的银行卡交易风险监控系统架构设计,可以为同行相关工作提供参考借鉴。
【作者】刘赟,某城商行科技部架构设计师,主要负责数据集成平台、大数据风控平台等项目建设需求获取、架构设计,及容灾能力设计建设工作。
一、 系统背景
随着信息技术的发展,金融业务智能化渠道网络化不断深化,线上业务场景越来越丰富,为金融机构提升市场竞争力的同时,也带来更加难以防范的风险。银行管理部门 及金融监管部门也在逐步加大监管力度,提高对金融风险防范要求,金融机构出于对自身业务风险防范及保障客户资金安全的需要,都在探索使用新型信息技术应用于业务开展过程来识别、预警风险,提高风险防范能力,建立基于大数据技术的银行卡交易风险防控体系,目前已经被金融机构普遍接受。在此背景下,本文将分享某城商行基于大数据技术建设银行卡交易风险监控系统,以提升借记银行卡交易风险管理水平的案例实践。
二、 需求分析
为提升自身风险防范能力,并且切实满足监管要求,业务部门提出构建基于大数据架构的反欺诈风险监测系统的需求,通过过滤规则匹配实时交易实现高风险交易阻断,及通过大数据分析提出风险预警,利用技术手段对实时数据和非实时数据分析处理来提升银行借记卡交易风险监测能力,从而提升借记卡业务风险的综合防控能力。经过对业务需求的分析,可得出待建系统的功能需求和性能需求分别如下:
(一) 功能需求
按照交易渠道实时监测交易数据,结合模型规则来判断交易数据是预警、放行、阻断、或强认证,形成相应的统计数据。主要功能有实时分析、警报监控及处理、用户习惯自学习、规则灵活定制、数据共享及数据交换。
本系统主要对借记卡通过网上银行、手机银行、ATM、POS及柜面等渠道发起的交易数据进行监测,分为事前风险评估、事中风险监测、事后风险分析。一是基于高风险交易特点和持卡人行为特征,建立风险评估模型。二是根据风险等级实施差异化风险防控,对风险较大,可疑程度较高的交易,采取精准识别、实时拦截等措施。三是通过交易行为分析,风险预警规则匹配等不断优化风险评估模型,对于大数据分析认定的高风险交易,进行附加交易验证,对于单日频次过高的异常交易,采取拒绝交易授权措施,提高欺诈交易拦截成功率,切实提升银行卡交易安全防护能力。四是给予客户一定的自主权,可通过柜面、网上银行、手机银行、电话银行等渠道提供银行卡交易安全锁,能够让客户根据自己的实际需要限定银行卡交易场景,设置或修改相关交易类型、渠道、地区、时段、额度等参散,以此来限定部分交易达到保障资金安全的目标。
(二) 性能需求
1、系统性能要求,包括批处理数据处理时间和联机数据处理性能要求。联机数据处理性能要求包括一般交易响应时间、一般查询类交易响应时间、复杂事物大表查询响应时间等。
2、系统可用性要求,包括系统不间断运行时间,非计划停机时间,及应用系统重新启动恢复时间等。系统必须稳定运行,一旦停机将导致卡业务实时交易故障。要求部署模式为主备快速切换模式,或者集群部署。
3、系统必须具有伸缩性。由于业务快速拓展,卡业务实时交易量也在不断增加,而且每年有几个特殊时点支付交易量会突发增大,比如双十一等,在必要的时候必须增加计算资源。
三、 系统设计
(一) 设计原则
系统支持业务的不间断持续运行,即在业务功能发生变更、新增时也能保持业务的不间断持续运行。
系统支持集群部署,保证业务的快速拓展能力和业务运行的安全性。
支持高效的横向扩展机制,支持负载均衡及灾难备份。系统的设计需满足实时监控7×24小时不间断高效运行的要求,系统设计支持数据清理不停服务。
支持系统持续发展的需要。通过渐进的发展实现有序的、有效的系统扩展,即系统的设计保证系统特性的扩充不影响其性能。
系统具有良好的可维护性。系统源代码具有详细的注解,以便于今后阅读、维护、修改和扩充。
(二) 业务架构
在对借记卡大数据风控系统需求分析的基础上,确定系统主要业务功能应该有管理平台、批量数据处理、数据采集管理、模型管理,总体功能结构如图1:
图1
大数据风险监控系统主要实现的功能有:
1、管理平台:主要供业务人员使用,可分为业务处理、统计查询、业务配置、基础管理等四个子模块。实现的功能有交易监控、预警模型维护、业务模型处理、统计分析,以及用户、权限、模型管理等。
2、批量数据处理:主要分为批量数据加载以及数据同步服务两部分功能。批量数据加载完成数据平台数据到本系统的批量加载;数据同步服务主要完成内存数据库与关系型数据库的数据交换等功能。数据同步服务主要是实现内存数据库中的交易数据、预警数据、异常数据三种数据与Oracle数据库的数据同步。
3、数据采集:主要实现从交易渠道采集交易数据,并返回经过计算的预警结果。根据使用目的不同,本模块又可分为风险数据监听和行为数据采集,用socket实现实时风险数据监听,用MQ消息队列实现交易报文数据采集。
4、模型管理:主要功能是根据业务人员输入的风险预警规则,在组件系统打包生成 新的jar包,再重组成为实时流计算引擎使用的预警规则jar包,并传递到实时流计算子系统。本系统包括模型组件以及模型发布两个子功能。
(三) 应用架构
经过分析业务需求、技术要求、系统复杂度、历史数据处理能力等因素,该系统应该采用大数据系统架构,不仅要具有整合实时计算和离线计算功能要求,也要满足高容错、低延时、可扩展等性能要求,所以应用架构应该选择Lambda大数据架构。Lamdba架构的结构主要包括三部分,即批处理层、加速层、服务层。Lambda架构可以适应流式数据计算、批处理和机器学习等应用场景。Lambda架构如图2:
图2
参考Lambda架构设计大数据风险监控系统架构,批处理层负责分析大量历史交易数据后得出风险预警结论,采用MapReduce作为数据处理引擎。加速层负责监测实时交易数据风险,采用了业内流行的Storm实时流式计算引擎,为了提高计算速度、缩短响应时间采用了Redis内存数据库加Oracle两级数据库存储计算数据。服务层负责整合、加工、输出处理结果,汇总流处理和批处理结果并提供查询等,实现人机交互。参考Lambda架构如图3:
图3
经过以上分析,我们设计借记卡大数据风险监控系统应用架构如图4:
图4
本系统从逻辑架构上看,主要包括大数据平台、模型、监测、管理和渠道等部分。大数据平台主要包括存储和计算引擎。存储平台作为大数据风险监测系统的基础,用于存储计算模型、风险监测规则,及计算行为习惯、交易特征等的历史数据。大数据计算平台,主要是大数据风险监测系统的计算引擎,用于分析历史数据及使用规则计算出是否疑似风险,用结论来决定实时交易是否继续,是成功完成交易还是阻断交易。模型用于管理风险规则与计算模型的管理,主要包括预设风险规则、用户输入预警规则、客户定制安全锁及系统计算出来的行为习惯、异常交易等。监测是该系统的主要功能,在大数据平台和模型管理的支撑下,应用各种风险预警情况于渠道传过来的交易,对交易的合法性予以预判。管理平台主要是业务部门用于管理、操作大数据风险监测系统,管理用户、黑名单,发布预警规则等。渠道主要指已经在用的银行卡交易渠道,不在新建范围内。
(四) 数据架构
本系统的数据处理主要有实时处理数据流与批量处理数据流两个流程,所以数据的组织结构按照数据处理的加工流程展开布局,如图5:
图5
1、行内业务管理人员通过管理平台应用建立模型,发布到模型管理服务,与规则组件组合成计算模型,用于实时处理数据流计算引擎需要的风险计算规则,并发送给实时计算引擎。
2、数据采集服务从各业务渠道采集实时卡交易数据,将风险交易通过socket发送给实时数据流计算引擎,同步等待按照计算模型运算后的处理结果;将行为交易通过MQ消息队列,异步发送给实时计算引擎。经过计算的处理结果反馈给卡系统用于决定交易是继续还是中止。
3、实时数据流计算引擎进行风险分值计算,并返回风险结论后,同时将交易数据、预警数据、预警分值等,写入到关系数据库Oracle及内存数据库Redis中。对于核心系统处理成功的交易以及仅需进行行为模型计算的交易,由卡系统通过MQ消息队列发送给流计算引擎,存储于Oracle数据库,同时同步于Redis内存数据库中,用于计算行为模型。
4、数据处理服务定时接收数据平台推送的历史交易数据文件,加载到Oracle数据库中,进行行为习惯的风险分析,存储计算结论,并利用数据同步服务同步到Redis数据库中;并及时将Redis数据库中经过计算的交易数据、预警数据、异常数据同步回Oracle数据库中。
5、大数据风险监控系统自行维护的黑名单数据,同步到Redis内存数据库中,用于计算风险模型。
(五) 技术架构
本系统在进行开发框架选型及设计时,考虑到以后的可扩展性以及可维护性,在开发框架上采用的是javaEE企业级开发主流技术SSM(Spring+Spring MVC+Mybatis)的标准J2EE/JAVA技术实现,是标准的MVC模式。该设计模式是一个四层的架构模式,分别是视图层(view),控制层(Controller),服务层(Service),持久层(DAO)。
在大数据技术的选择,尽量采用经过实践检验的,业内流行的大数据开源技术组件, 主要有流式计算Storm和批量计算MapReduce。
(六) 网络架构
银行卡大数据风险监控系统需要部署的服务器包括:应用服务器、数据库服务器、流计算服务器、批量计算服务器、内存数据库服务器等,网络部署架构图如图6。
图6
从左到右共三层部署,分别为管理区、计算存储区、源数据区。两台应用服务器为主备双机系统,主要部署管理平台应用服务。两台数据库服务器部署Oracle RAC,使用一套共享存储。三台流计算服务器部署Storm,包括资源调度Zookeeper,以及Redis内存数据库。两台批量计算服务器部署MapReduce。源数据区均为已有系统,不涉及新部署,不再详细解释。
四、 相关设计
(一) 数据库设计
为了提高大数据风险监控系统的计算速度,设计了内存数据库与关系数据库两级存储体系,内存数据库采用Redis,关系数据库采用Oracle。
1、采用Oracle关系型数据库来存储预警处理结果,以及用于计算预警模型的批量数据。由于银行借记卡交易数据属于结构化数据,所以本系统不涉及非结构化数据和半结构化数据。各渠道每天的借记卡交易数据以文本文件方式批量的通过数据平台同步到大数据风控系统。通过对历史交易数据分析计算,总结出预警模型数据,并同步到redis内存数据库,用于对实时交易数据形成预警。
2、采用Redis内存数据库,Redis是一个高性能的key-value数据库。为了解决数据库访问影响实时计算的性能瓶颈,本系统采用Redis内存数据库作为预警及交易数据临时存储,Redis是一个开源内存存储的数据结构服务器,可用作数据库,高速缓存和消息队列代理。
3、内存数据库与关系数据库的数据同步。实时数据计算引擎首先从redis内存数据库读取数据,数据存在则直接用于计算;如若数据不存在则从oracle数据库读取数据,同时同步到redis数据库中。实时数据流计算引擎进行风险分值计算,并返回风险结论后,同时将交易数据、预警数据、预警分值等,先写入到关系数据库oracle中,并且同步写入内存数据库redis中。
(二) 与卡系统接口通讯
1、为提高系统处理性能,卡系统与大数据风控系统,采用SOCKET同步与MQ消息队列异步两种通讯方式。其中SOCKET同步通讯用于需要进行大数据风控的高风险 交易,例如转账、取款、消费等,卡系统同步等待大数据风控系统处理结果。MQ异步通讯用于行为模型计算服务,例如密码错误、查询等。
2、SOCKET通讯方式,由卡系统负责报文映射为统一接口,MQ消息队列方式,由大数据风控系统负责报文映射及转换。
3、卡系统消息队列包括请求报文队列及响应报文队列,卡系统发送给核心的消息均需写入消息队列,大数据风控系统根据报文编号进行报文组合。
4、大数据风控系统提供接口范围说明,对于不需进行风险系统监控服务接口,由大数据风控系统提高规则,卡系统根据外部交易码进行过滤,不发送给大数据风控系统。
五、运行效果
借记卡大数据风险监控系统上线部署后,利用大数据技术的优势,对各渠道的借记卡交易进行实时监控,有效地发挥了业务风险识别、预警、阻断等风险防范能力,切实提高了借记卡交易的安全性,形成了企业跨部门、跨渠道企业级的交易安全保障体系,极大地缓解了由内外部欺诈损失、风险监管及案件防控带来的管理压力。但是大数据风控系统部署后,在卡交易链路上增加了一个业务处理节点,增加业务处理过程中所需的时间。虽然在部署之前充分论证了流计算的速度对卡交易时效性的影响,集群部署了三台X86服务器作为流计算服务器,设置了单笔交易的最大响应时间。但是由于业务部门营销了公交车刷卡购票业务,特定时段卡交易量急剧上升。这些大量的小额交易占用了太多的大数据系统计算资源,导致发生了交易排队拥堵,处理速度大幅下降的事件。经过扩展一台流计算服务器、放大了最大响应时间等技术处理,系统终于趋于稳定。
问题处理过程充分体现了该系统架构具有的容错性好、易伸缩、易扩展等优点,而且 离线计算稳定性好,未发生任何事件。同时该架构也存在缺点,需要部署流处理和批处理两套系统,不仅开发成本高,而且后期运维难度大。