央行南京分行李涛:基于大数据技术的支付结算执法检查系统设计
2019/10/24 14:40:38

随着支付业务快速发展,监管科技应用已被提上了监管工作日程,作为重要监管手段的支付结算执法检查也不例外。对于海量的支付数据,基于单机离线处理的传统检查工具难以应付,因此我们引入当下成熟的大数据分布式框架Ha-doop来进行执法检查数据处理。

传统支付结算执法检查方法和工具发展历程

1.发展历程

支付结算执法检查经历了纯手工查询阶段、数据处理软件阶段和专用执法检查工具阶段。经历了早期处于探索的手工查询阶段后,执法检查人员基于提高效率的需求,主动发挥EXCEL及Access、FoxPro等办公软件或小型数据库在数据处理分析中的积极作用,要求被查单位提供有关业务数据,并通过设置筛选条件、简单编程、数据透视等,对检查数据进行主动分析。由于需要手工编码,对使用人员要求较高,方法复制能力不强。随着支付检查程序化和专业化的发展,人民银行分组织开发了专用支付结算执法检查工具。与数据处理软件相比较,支付结算执法检查工具建立了完整的执法检查数据库,封装了履职合规性典型问题发现和分析模块,使用人员可快速上手,提高了检查工作效率。

2.传统检查工具的不足

传统检查工具在执法检查中发挥了积极作用,但是,随着业务的发展和实践的深入,其不足也显现出来:一是数据要求严格。一些检查工具对源数据要求严格,如要求提供数据库格式的检查数据,对于科技力量薄弱的小型银行和支付机构来说存在困难。二是运行效率低。由于采用笔记本电脑为主的单机运行环境,计算能力低。以某备付金检查工具为例,对每日平均交易量200万笔的支付机构,导入一天交易数据需近30分钟,分析每日交易商户检查和交易数据需约40分钟。考虑到随着导入数据增多,导入、统计分析性能也会下降。三是数据未预处理。数据需进一步人工清洗、审核,被检查对象提供的数据出现不一致或者差错时,缺乏自动核对校验功能,导致错误数据录入,得出错误的检查结果。另外,对于一些敏感数据,缺乏脱敏手段,存在泄漏风险。

新形势下支付结算执法检查面临的挑战

1.支付信息“大爆炸”

2018年全国银行业金融机构共办理非现金支付业务2203.12亿笔,金额3768.67万亿元,同比分别增长36.94%和0.23%,非银行支付机构发生网络支付业务5306.10亿笔,金额208.07万亿元,同比分别增长85.05%和45.23%。支付业务日均产生交易数据量已达到TB级。大型银行和支付机构的账户数量和日均交易量均为亿级别,传统检查手段能以应付海量检查数据。

2.支付市场主体和业态的多样化

伴随着支付场景的丰富、支付参与和服务主体的增加和支付产业链的变长,支付的内涵不断的丰富,与此同时,一些无证机构、“二清”商户、为赌博私彩等行为提供支付服务等乱象频出。每一种模式的增加,意味着数据准备、处理难度增加和方法的复杂化。

3.统一数据接口标准的缺乏

在缺乏统一标准的情况下,各检查主体调取数据格式要求不一,检查数据源的质量完全依靠于检查方和被检查方的沟通程度、相关技术人员的的业务能力水平,无形中增加了检查双方成本。实践中,往往需要多次反复,才能得到较为准确的数据。

4.支付检查的规范性要求日益提高

执法检查是重要的行政手段,执法检查过程必须保证程序合规、证据充足,检查的结果是行政处罚的重要依据,检查的规范性和统一的标准也是监管权威的有力保证。随着法律部门对执法检查工作介入的深度增加,支付检查的规范性要求也越来越高。

引入平台系统

引入的平台系统要求技术成熟,能够为业务应用层提供强大的数据运算能力支持,并可以有效管理海量存储空间。普通人民银行工程技术人员可以通过技术手册的支持,能够独立在市场常见计算机硬件平台上(服务器或PC)进行组网,快速完成大数据集群的部署搭建。Hadoop生态系统包含分布式文件系统HDFS和分布式计算框架MapReduce,凭借其低廉的软硬件成本、强大的并行计算能力、丰富的数据采集通道和多样化的计算查询引擎,成为金融领域搭建大数据平台解决方案的标配,因此本系统采用Hadoop框架搭建。

1.功能需求

系统主要功能包括基础数据的处理、风险预警和检查业务。通过检查标准数据接口规范转换为检查客体即账户、客户、交易内容。基础数据处理过程包括加载、清洗、校验和转换等处理过程。基础数据包括检查对象核心业务系统数据、人民银行账户管理系统等相关系统数据、清算组织数据、举报投诉信息、工商企业信息及其他外部权威数据等。对个别长交易链条交易,必要时可通过他行(支付机构)交易流水补充交易对手等相关信息。各关联数据可以互相匹配和交叉核验,确保基础数据的完整和准确。通过合规和可疑交易规则处理,将满足相应规则的客户、账户及交易生成检查疑似结果。

2.逻辑架构

系统的逻辑架构主要包括基础数据层、数据处理层、规则模型层、业务应用层。数据存储采用HDFS,数据的处理、规则计算采用MapReduce和Hive结合的方式,调度采用Oozie实现。

3.系统主要功能

数据采集清理功能。检查系统通过统一的数据字典和数据通讯接口协议,保证数据含义和接口的一致性;通过数据预处理、数据校验、督报催报等手段,保证数据报送的及时性和准确性。数据预处理分为数据清洗和数据仓库构建两部分。

数据核验功能。数据的真实性和完整性是保证检查结果真实有效的基础,因此有必要引入数据核验功能,进行多维数据交叉对比,交叉对比包括内部数据核验和外部数据核验,在内部将检查单位提供的不同关联表之间核验,外部将被检查单位提供数据和外部客观、权威数据库如人民币结算账户管理系统、联网核查身份系统、工商企业数据、清算组织数据进行核验。

违规线索排查功能。检查系统设置不同业务检查模块,根据支付服务主体、清算组织报送的业务数据进行分析,支持违规行为、疑似违规线索的非现场筛查,提高检查工作的针对性。

风险预警功能。系统通过人工智能根据历史数据样本进行自我学习,设立关键指标风险预警阈值,预判检查对象风险级别和违规范围,为检查对象选择和针对性的开展非现场监管提供依据。

数据的查询、统计功能。系统支持对违规问题及相关业务数据的查询、统计,根据用户权限以界面、报表或报告的形式展示银行和支付机构业务基本情况。通过设定的指标体系,将采集的数据形成统计报表,将数据形象化、直观化、具体化,为监管提供决策支持。

检查业务。检查业务模块围绕账户业务、支付系统业务、备付金业务、银行卡收单业务、网络支付业务、无证支付业务等。根据检查实践需求,调取检查时间段全量数据和汇总数据,根据设立的检查规则和模型,对数据进行分析。

系统管理功能。系统具备基础信息设置、权限分配管理、模型参数设置、系统接口管理、系统日志记录等基础功能,确保检查系统具备稳定运行环境。针对以往检查工具或系统未区分用户角色,存在误操作风险和数据安全风险的不足,系统采用Hadoop用户管理标准的RBAC模型,系统用户角色分为本组人员、其他人员、主查、检查组长,通过给用户绑定角色来赋予用户对对象的访问权限,如只有本组检查人员对本组涉及数据有修改权,主查和检查组长拥有全量数据的查询权,公共数据只有主查才有修改权等。

4.系统特点

可扩展性。系统可根据实际不同需求,通过灵活增加相关硬件获取系统运算、存储等性能的提升。系统的功能模块也可根据检查需求进行设置。

并发性。支持多客户多任务同时运行,方便多位检查人员进行并行查找和分析,并设置系统运行状态监测和调度功能,防止可能出现的系统任务瓶颈拥堵。

数据可视化。检查中间过程和结果的可视化,有助于检查者快速排查问题,如通过颜色匹配不同风险商户、通过不同时间轴上交易量区分异常交易。同时,可视化结果也可有助于快速自动生成检查报告。另一方面,可视化界面的交互性有助于用户通过钻取功能快速定位检查细节。

功能可配置。检查各功能模块可根据检查目的、业务、规模需求灵活设置调整参数。相关模型采用模块化和参数化配置,可以根据检查任务进行定制化配置,生成的模型可以进行导入导出,供不同地区的不同使用者使用。

本文转载目的在于知识分享,版权归原作者和原刊所有。如有侵权,请及时联系我们删除。

展开全文
相关阅读
资讯查询取消