周彩冬++潘维民

摘要：随着电子商务和移动互联网的发展，数据流量的持续增长和以双十一为代表的多种数据洪峰的出现，给商业银行传统的反洗钱手段带来了巨大的压力。海量交易数据下隐藏着各种洗钱行为，传统的反洗钱方式在应对持续增长的数据时越来越捉襟见肘。当前，大数据技术的发展为海量数据数据的收集、存储、处理等提供了技术支撑。本文分析了商业银行的反洗钱业务需求，从业务的角度对比研究当前大数据领域众多新技术，提出了一套实用、可扩展的反洗钱处理架构，并且提出了的大数据反洗钱的演进方向。

关键词：计算机应用技术；反洗钱；大数据；商业银行

中图分类号：TP31

文献标识码：A

DOI： 10.3969/j.issn.1003-6970.2016.02.001

引言

洗钱行为给国家和社会带来了巨大损失，我国从上世纪末就开始从国家层面实施反洗钱建设，并且参考国际经验总结了诸多反洗钱策略。但是随着金融业的快速发展和金融领域信息化的不断深入，数据量的增长和新兴金融产品的不断推出，传统的反洗钱方式在处理能力和处理精度上越来越不能满足需求，所以商业银行需要使用新技术来提升自己的反洗钱能力。本文介绍了反洗钱现状和大数据相关技术及其优势，分析对比了当前大数据领域的一些适用技术，并且结合商业银行的业务情况提出了一套实用的大数据反洗钱架构，最后总结了大数据反洗钱的一些发展方向。

1 反洗钱现状

在21世纪初，为了适应国际反洗钱形势，我国反洗钱工作逐步开展，反洗钱监管体系从无到有，逐步建立起来。但是，当前反洗钱的形势依然很严峻。根据中国人民银行发布的《中国反洗钱报告2013》的统计，2013年人民银行共发现和接收4854份洗钱案件线索，中国反洗钱监测分析中心全年向公安部等部门主动移送和协查反馈数量超过前两年总和。最近几年，随着走私、毒品、贪污贿赂等犯罪不断曝光，非法转移资金活动大量存在，对洗钱行为的预防监控愈发显得重要。

由于洗钱行为大多以商业银行作为操作平台，因而商业银行在反洗钱方面具有重要的基础性作用，商业银行有能力也有义务对客户身份、客户交易行为进行识别，完成反洗钱工作的初筛工作。如果银行在反洗钱方面工作不利，不仅会对银行造成经济还有声誉的损失，更会影响反洗钱当局的对于洗钱行为识别，造成国家层面的经济损失，影响国家的声誉。

同时，随着数字化信息时代的来临，网络交易和移动支付的数量不断上升，越来越多、越来越详细的交易数据对传统的反洗钱处理方式构成了挑战，单纯的升级硬件或软件已经无法应对可预期的数据量的疯狂增长，因而商业银行需要新技术来确保未来的反洗钱工作能准确高效地进行。大数据处理技术的发展为商业银行提供一个可靠的解决方案。

2 大数据简介

大数据（big data），是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。在维克托·迈尔一舍恩伯格及肯尼斯·库克耶编写的《大数据时代》中，大数据是指不用随机分析法（抽样调查）这样的捷径，而采用所有数据进行分析处理。大数据的SV特点：Volume（大量）、Velocity（高速）、Variety（多样）、Value（价值）和Veracity（准确性）。

随着移动互联网、物联网、社交网络和云计算等领域的发展，大数据技术在众多的领域得到了应用并推动了这些领域的发展。比如，在商业领域，沃尔玛公司通过分析销售数据，了解顾客购物习惯，得出适合搭配在一起出售的商品；在公共卫生领域，谷歌通过对最频繁检索的词条和美国疾控中心在2003年至2008年间季节性流感传播时期的数据进行了比较，预测了2009年冬季流感的传播；在社会安全管理领域，美国麻省理工学院通过对某地区十万多人的SNS等信息进行处理，提取人们行为的时空规律性，进行犯罪预测。大数据技术的运用，给人类带来了更多的想象。

虽然有些数据处理技术已经出现，然而在一段时间内它们只为调查局、研究所和世界上的一些巨头公司所掌握，但随着开源软件的发展，以Hadoop为代表的数据处理技术和系统得以不断的发展和完善，并且在诸多领域中得以运用，极大地推动了各个产业的发展。众多大公司和研究所都在研究和使用Hadoop平台，并且针对各个细分领域贡献了更多实用的组件，使得Hadoop生态圈更加完善。

商业银行每天都会产生大量的交易数据和客户信息，使用大数据处理技术来实施反洗钱，对于商业银行保证反洗钱职能、提升反洗钱效率、降低反洗钱成本等方面有着重大的意义。

3 大数据反洗钱的优势

使用大数据技术实现反洗钱，将大大提升商业银行的反洗钱处理能力，跳过计算能力的瓶颈。当前，商业银行传统的反洗钱方式是依据《金融机构大额交易和可疑交易报告管理办法》，对交易数据进行计算，若交易数据符合大额交易或者可疑交易标准，就将该数据报送反洗钱监管机构。商业银行一般使用Oracle等传统的关系型数据库进行数据的计算分析，由于传统关系型数据库的扩展能力有限，数据处理能力只能通过提升硬件性能来实现有限提升，无法应对越来越大量的交易数据。大数据处理技术能实现横向扩充计算能力，在处理能力、扩充能力、成本等方面有巨大优势。当前，基于关系型数据库的反洗钱操作都是通过SQL来实现的，大数据平台有Hive、Spark SQL、Dremel等实现SQL接口的大数据处理工具，对于技术方案切换成本和技术学习成本都能有很好的控制。

大数据技术也让反洗钱有更多的提升空间。传统的关系型数据库需要满足范式等约束，一般只能处理结构化的数据。大数据技术支持非结构化的数据，同时配合强大的存储能力能收集记录更多维度的数据，在对交易数据计算的时候可以避免样本计算带来的缺陷，使用完整的数据进行计算分析提升反洗钱的效果。由于拥有强大的计算能力和存储能力，反洗钱的识别可以突破《金融机构大额交易和可疑交易报告管理办法》中相关规则的限制，提供更加细致的识别方案，比如可以针对每个客户的历史数据，对比每笔交易，统筹考虑时间、地点、金额、流向、频繁程度等要素，理解相关交易行为的特点，配合离群值分析等机器学习算法，进而提升可疑交易的识别准确率。

4 大数据反洗钱的设计

4.1 反洗钱业务需求

中国反洗钱工作具有多部门协作的特点，商业银行反洗钱工作只是其中一部分。完整的反洗钱工作流程包括：客户和交易信息收集及筛选、大额和可疑交易分析及甄别、大额和可疑报告报送、数据汇总检查及预处理、可疑交易甄别及行政调查、移交司法立案侦查等环节（见图1），并由各商业银行、人民银行反洗钱机构和司法机构分别承担，形成反洗钱工作的完整闭环。

当前大多数商业银行都是采用Oracle、MySQL等传统的关系型数据库作为数据处理的主要T具，然而随着信息数据的增长和数据分析的需求的转变，传统数据库遭遇诸多瓶颈，比如数据量增长过快，导致运算效率下降；数据抽取处理的代价过高，无法在统一的视图下处理；无法处理多种类型的数据；不具备进行搜索或关联分析以发现隐藏关系的能力；不具备数据挖掘等高级分析的能力等等。大数据相关技术的发展为商业银行快速精准分析数据提供了解决方向。

目前，商业银行的数据分析一般是基于传统的数据仓库，考虑到技术演进的渐进性，需要对反洗钱处理的前后端兼容，同时兼顾使用的便捷性和稳定性，所以使用大数据数据仓库来实现；考虑到今后反洗钱策略的升级，新系统也需要为策略升级留下扩展接口。

《金融机构大额交易和可疑交易报告管理办法》规定，金融机构应当在大额交易发生后的5个T作日内，在可疑交易发生后的10个工作日内以电子方式报送相关报告到中国反洗钱监测分析中心。上报的时间比较宽裕，在线处理和离线处理都可满足需求。

4.2 技术方案比较

4.2.1 数据采集技术

机构信息、员工信息、客户信息、账户信息、牌价汇率信息、本外币交易信息等数据的采集是由商业银行的业务柜台等直接和用户交互的机构录入到系统的，是典型的联机事务处理（OITP），传统的关系型数据库和新兴的NoSQL都是备用方案。下表对关系型数据库和NoSQL数据库做了对比：

从上表可以看出，关系型数据库和NoSQL具有不同的适用场景。商业银行的交易数据相对来说模式比较固定，没有大量的非结构化数据，单纯OLTP场景下处理能力也完全能满足需求，同时，银行现有的业务系统也是基于传统关系型数据库，所以数据采集主要还是依靠传统的数据库来完成。客户数据是非常冗杂的数据，当前商业银行记录的数据主要是交易相关的固定模式的数据，但是用户数据是非常具有挖掘价值的，随着用户数据分析策略的升级，会有很多非结构化的数据作为补充，所以客户数据可以逐步采用Apache HBase等NoSQL数据库，增加对非结构化数据的支持，为在大数据平台上实施客户评级、风险监控等策略的升级提供接口。

4.2.2 数据分析技术

实现大数据反洗钱，最主要的就是在交易数据中识别洗钱行为。中国人民银行对商业银行的反洗钱的要求就是识别和报送大额交易和可疑交易，使用SQL的方式进行反洗钱数据处理，是便捷有效的方式。反洗钱相关需求的实施是典型的联机分析处理（OIAP），当前基于大数据平台的OLAP方案主要有Apache Hive、Dremel clones、Spark SQL三种。在技术方案选型时，当前技术的成熟程度、开源分支的活力和技术演进的方向都需要考虑，需要从趋势上避开一些不具发展潜力的技术，比如之前的Shark。

Apache Hive最初由Facebool公司创建，是第一个基于Hadoop之上的SQL引擎，且至今仍是最成熟的。Hive主要解决的问题就是为开发人员提供SQL方言来存储和处理Hadoop集群中的数据，封装了复杂的编程任务，方便在海量静态数据上做离线分析处理。到目前为止，Hive拥有最完整的SQL功能支持、最为稳定，并且也是拥有最多贡献者的项目，事实上大多数SQL引擎都以这种或那种方式依赖于Hive。Hive最初是构建在MapReduce之上的，运行稳定但是耗时较多。Hortonworks于2013年提出Apache Tez引擎以提高Hive性能，Tez使用数据流（Dataflow）的方式避免了MapReduce中间结果的写磁盘读磁盘的性能瓶颈，提高数据分析的效率。Hive社区于2014年推出了Hive on Spark项目（HIVE-7292），并且在Hive l.1版本中正式推出。Hive on Spark在设计时尽可能重用Hive逻辑层面的功能，从生成物理计划开始，提供一整套针对Spark的实现。在Hive l.l及以后的版本，MapReduce、Tez、Spark三个引擎可以自由切换。

2010年，Google公开了《Dremel：InteractiveAnalysis of WebScaleDatasets》一文，提出了PB级数据规模上的“交互式”数据分析系统。在PB级数据规模上，Hive使用MapReduce作为引擎执行数据处理需要分钟级时间，Dremel只需要秒级。Dremel论文公开后，外部有很多克隆版本，比如Facebook Presto、Cloudera Impala和Apache Drill. Dremel Clones没有再使用缓慢的Hive+MapReduce批处理方式，而是通过使用与商用并行关系数据库（ Parallel DatabaseSystem）中类似的分布式查询引擎，可以直接从HDFS或HBase中用SELECT、JoIN和统计函数查询数据，从而大大降低了延迟。然而，由于流式传输过程中，中间数据都保存在内存中，当数据量过大内存无法容纳时，查询就会失败。Dremel Clones适用于原型阶段的快速数据分析和模型建立，不适合有复杂处理逻辑的计算，不适合大数据量的计算。

Spark是一个通用的大规模快速处理引擎，Spark完全跳出 MapReduce的处理模型，将数据集缓存在内存中，并用Lineage机制容错，其弹性分布式数据集（Resilient Distributed Datasets）也提供更丰富的编程接口。总体而言，Spark为我们提供了一个全面、统一的框架用于管理各种有着不同性质（文本数据、图表数据等）的数据集和数据源（批量数据或实时的流数据）的大数据处理的需求。Spark在SQL方面的发展最早是基于Hive的Shark，由于Shark对于Hive有太多依赖（查询优化、语法解析等），性能提升遭遇瓶颈，2014年Spark Submit上Databricks宣布放弃了的Shark的开发，从此Spark上的SQL就分成两个路线：Spark SQL和Hiveon Spark。Hive on Spark可以认为是前端Hive后端Spark，基于MR或Tez的Hive既有用户可以在原系统与Hive on Spark系统之间轻松切换，切换工作仅仅只需要简单地修改下配置参数。Spark SQL是一个完整的新引擎，Spark SQL团队吸收Shark的优点重新开发了Spark SQL代码，使得Spark SQL无论在数据兼容、性能优化、组件扩展方面都得到了极大的提升。Spark SQL在2015年5月的1.3的版本中才走出“Alpha”状态，是全新的平台，相对于Hive在功能丰富性和稳定性上还有很多不足。

综合分析各个数据处理平台，结合商业银行高稳定性、高可用性需求以及大量交易数据和充足的离线运行时间的实际情况，选用至今最成熟的Apache Hive是商业银行的最佳选择。Hive支持MapReduce、Tez、Spark三大引擎，在运行效率和运行稳定性之间有比较大的选择空间。Dremel Clones可以作为辅助分析工具，帮助调研调试新的反洗钱规则。同时，Spark SQL发展迅速，也可能成为今后的最佳选择。

4.2.3 数据存储技术

大数据平台的数据存储主要是HDFS和HBase两种。虽然HBase的底层也是基于HDFS，但是在许多特性上和HDFS是有明显的区别的。

由于HBase是基于HDFS的，所以HBase也拥有HDFS的高吞吐量、高可伸缩性等特点。实质上，HBase就是在HDFS的基础上增加了基于内存的缓冲区并调整数据查找方式。HBase适用于数据存储和搜索，但是对于数据分析，性能会比HDFS差一些，因为HDFS上典型的访问是顺序I/O，而HBase上的访问有服务器的socket连接资源消耗和对底层多个文件的合并过程。当前，有Apache Kudu这样的项目来兼顾数据扫描、随机访问和数据分析的高性能，避免额外的数据移动，但是该项目正在处于孵化阶段，暂时无法在项目中运用。

商业银行反洗钱的主要数据源是交易数据，辅助数据源为客户、账户信息；同时在数据的ETL处理阶段，有码值映射表等辅助数据。银行每天业务结束后，会将数据导入到HDFS中，以供分析。交易数据是确定不变的数据，可以使用HDFS来存储；对于客户数据等可变数据，可以使用HBase存储，在运行时加载到HDFS中以提高分析速度。如果不考虑非结构化和半结构化的数据，可以不用HBase直接将所有原始数据存入关系数据库然后统一导入HDFS。 文件存储格式对于数据分析的效率也有很大影响。目前，Hive支持的几种主要的数据格式如下：

相对于纯文本格式和面向行的二进制格式，面向列的二进制格式性能消耗较大，但是具有较好的压缩比和查询响应；同时ORC和Parquet还增加了数据的块统计，能有效减少数据分析的时间。反洗钱业务需要大量的数据分析，所以分析时采用ORC格式具有比较好的效果。在数据仓库中，数据会进行分层，不同的数据层应该根据实际采用不同的数据格式。

数据存储文件也需要配合文件压缩来减少占用的磁盘空间并加速数据在网络间的传输。在反洗钱处理情景中，主要数据都是交易记录，使用压缩比和压缩效率比较均衡的LZO或者Snappy皆可。

4.3 大数据反洗钱的应用

4.3.1 大数据反洗钱的架构设计

通过对反洗钱的业务研究和各个数据处理阶段相关技术的对比研究，确定使用MySQL+HBase的方式来进行数据采集（不考虑非结构化数据可以全部使用MySQL）；使用HDFS+HBase的方式实现数据存储。结合反洗钱的实际业务，对反洗钱整体的架构设计如下：

MySQL集群中存储每天的交易数据和客户数据，同时维护着一份反洗钱的配置文件。每天业务结束后，将MySQL中的数据导入到Hadoop处理平台中。Hadoop环境中主要是使用Apache Hive作为数据仓库，在Hive中进行ETL操作，将数据整理转换为反洗钱计算的输入，然后进行反洗钱的数据计算。最后将计算得出的预警结果导出到MySQL中。

就具体的数据分布而言，MySQL主要用于当前操作型事务和少量在线数据应用，其主要存储系统基础数据、元数据、当前处理数据（补录数据、案例处理、报告信息等）等数据。Hadoop是作为数据处理平台（Hive）和数据归档平台（HBase），主要存储海量指标数据和历史数据（交易、报告、客户/账户、评级历史、日志等）。Hive作为基于Hadoop的数据仓库，具有天然的易于扩充的海量数据存储能力，所以存储了所有历史数据，但是基于Hive的查询操作会很慢，所以使用HBase来辅助查询。具体的数据流如下：

Hive相关的部分，是整个系统的数据处理中心，包括ETL和规则计算。数据源是银行的业务系统每天产生的基础数据，导出到Hadoop文件系统上；Hive通过Load命令将数据文件加载进入到贴源层，贴源层与源系统结构一致。数据加载到HDFS后，需要进行ETL转化，主要使用HQL语言进行数据整理，最终在Hive中生成标准数据接口，然后将数据导入HBase，以供应用访问。标准数据接口中的数据是全部数据，使用合适的过滤规则将当日规则计算需要的数据从标准数据模型中取出来，以缩小需要访问的数据范围。然后就可以进行反洗钱核心环节的处理，进行大额和可疑规则的计算，并且生成预警结果，最后将预警中间结果写到MySQL。

每天的预警结果生成以后，需要在Mysql中对生成的预警结果进行案例生成，数据校验等操作，其中并对部分数据进行补录。对经过在MySQL中补录的业务数据，如客户信息、账户、交易信息，归档到Hive中的标准数据接口中，再同步到HBase中。对经过在MySQL中补录、认定、报送已经接收过回执的数据，同步到Hive的历史库中，再同步到HBase中的历史库中。

前台访问主要涉及下面三个操作，日常的补录、案例分析、报告及报送工作在MySQL中操作；对于查询交易、账户、客户等大数据量数据访问HBase，通过服务接口；对于归档的历史数据，通过服务接口访问HBase。

4.3.2 大数据反洗钱计算实现

具体的反洗钱计算如3所示，涉及的过程是从“标准数据接口”开始，到生成“预警结果中间表”结束。主要的计算逻辑就是《金融机构大额交易和可疑交易报告管理办法》中规定的4条大额规则和18条可疑规则，使用HiveQL根据客户数据和交易数据的特征来识别可疑数据。

在计算过程中，由于数据量巨大，全部计算会浪费过多资源，所以需要根据反洗钱的计算规则提炼出一些过滤规则以减少待计算的数据量。当前使用的是以客户为中心的筛选过滤规则，具体的过滤逻辑如下：

首先根据当天的交易流水过滤出所有出现过的客户ID（包括对方客户），然后计算回顾周期，最后根据回顾周期从历史数据中筛选出回顾周期内需要计算的数据。以客户为基准过滤非计算数据，可以有效的避免计算资源的浪费。

反洗钱的计算过程中，描述性的规则在实施过程中需要量化。一条规则在量化后，会划分成对公规则/对私规则、本币规则/外币规则等多种不同的子规则。大多数描述可以通过简单的属性划分来完成，但是有些描述无法通过简单的划分来实现。以中国人民银行的可疑规则第五条为例：与来自于贩毒、走私、恐怖活动、赌博严重地区或者避税型离岸金融中心的客户之间的资金往来活动在短期内明显增多，或者频繁发生大量资金收付。“短期内资金往次数明显增多”这种行为的识别需要和前期的数据比较得到，然而每次计算时都统计历史上的交易次数明显是很低效的。为此，设计了资金收付偏移比这一指标：

短期内日平均交易次数

资金收付偏移比=——————————

长期日平均交易次数+1

其中，“短期”和“长期”都是可调控参数，针对对公用户和对私用户等不同用户有不同的时间设置。由于分母是日平均交易次数，可能是远小于1的值，这样的值会将偶尔出现的交易放大而出现失真，所以添加了基数1来控制敏感度。实际的资金收付偏移比的阈值和上面所列出的指标一样，也是在参数表中动态配置的，默认的偏移比阈值是3。长期参数可以定期计算保存，这样每次计算短期的日平均交易次数既可以获得资金收付偏移比，“短期内资金往次数明显增多”可表示为资金收付偏移比大于阈值，大大减少计算量。在实际的反洗钱计算中，还有新账户指标、账户活跃度指标等，都是为了降低计算复杂度而设立的，在此就不全部列举。

5 反洗钱发展展望

随着信息科技的发展，互联网金融等众多新兴的交易模式逐渐增多，这些新技术在方便普通用户的同时，也给不法分子提供了新的洗钱手段。因此，作为反洗钱前沿阵地的商业银行更需要提升反洗钱的能力，保证金融市场的有序稳定。商业银行提高反洗钱能力，一方面是反洗钱平台技术的提升，提高数据处理能力；另一方面就是反洗钱识别策略的提升，提高数据处理的效率。

在平台技术方面，通过上文的对比分析，可以看出当前大数据技术已经从具有处理能力向具有快速处理能力发展，越来越多的考虑使用内存、固态硬盘等硬件睐加速执行过程。MapReduce、类分布式搜索引擎、Spark等诸多技术的发展，提供越来越高效的数据分析手段。当前，类似Kudu、Spark SQL等部分新的技术尚处在初期发展阶段，暂时不能在商业银行这种对稳定性要求比较高的隋况下使用，但是将来肯定会是数据处理的有力扩充。本文采用的是离线的处理方式，针对反洗钱的部分规则，可以采用Storm等流式计算引擎来完成在线实时分析计算，如果能在秒级别识别洗钱行为，那么对于整个反洗钱生态都是颠覆性的。

在反洗钱识别策略方面，商业银行传统的反洗钱监控上报都是基于《金融机构大额交易和可疑交易报告管理办法》，这一套方式是对过去反洗钱手段的总结，在应对众多新型交易方式，难免有疏漏之处。升级反洗钱识别策略，主要就是引入分类、估计、预测、关联规则、聚类、描述和可视化等数据挖掘技术，从大量数据中揭示J叶J隐含的、先前未知的并有潜在价值的信息。增强对客户的风险控制，避免显性检测规则的弊端，降低反洗钱的识别成本，提升反洗钱执行效率。本文的反洗钱架构给反洗钱识别策略的升级预留了接口，可以使用机器学习组件Apache Mahout在HDFS上直接调试部署；也可以使用Hivemall直接基于Hive进行算法的训练部署；也可以使用基于Spark的机器学习系统MLbase及底层的分布式机器学习库MLlib来进行反洗钱新策略的训练升级。尽管近年来在反洗钱识别策略方面的研究取得不少进展，但总体来讲‘框架研究多，具体方法研究少；理论研究多，结合具体场景研究少”，目前并没有切合实际的方案，但这是反洗钱的必然发展方向。

6 结语

随着全球经济信息化不断加快，洗钱犯罪也呈现出更加多变、隐蔽的特点。商业银行作为反洗钱的前锋，承担着反洗钱工作的重要职责。大数据时代的海量数据不仅给商业银行的反洗钱带来巨大压力，同时也给整个金融市场带来了全面提升反洗钱效率的契机。

本文从当前商业银行的反洗钱技术在数据处理能力不足的角度出发，分析了商业银行的反洗钱业务需求，并对比总结了当前大数据相关技术在反洗钱场景下的优缺点和适用情况，根据实际的业务情况提出一套实用的可扩展的大数据的反洗钱处理框架，并且在反洗钱计算部分提出了优化意见，最后讨论了反洗钱发展的两个方向。相信在不久的将来，大数据技术将和反洗钱碰撞出更多的火花。