作者：中国人民银行南京分行 李涛

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

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

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.系统特点

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

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

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

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

本文选自《金融电子化》2019年09月刊

声明：本文来自金融电子化，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。