周彩冬++潘維民

摘要：隨著電子商務和移動互聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)流量的持續(xù)增長和以雙十一為代表的多種數(shù)據(jù)洪峰的出現(xiàn)，給商業(yè)銀行傳統(tǒng)的反洗錢手段帶來了巨大的壓力。海量交易數(shù)據(jù)下隱藏著各種洗錢行為，傳統(tǒng)的反洗錢方式在應對持續(xù)增長的數(shù)據(jù)時越來越捉襟見肘。當前，大數(shù)據(jù)技術的發(fā)展為海量數(shù)據(jù)數(shù)據(jù)的收集、存儲、處理等提供了技術支撐。本文分析了商業(yè)銀行的反洗錢業(yè)務需求，從業(yè)務的角度對比研究當前大數(shù)據(jù)領域眾多新技術，提出了一套實用、可擴展的反洗錢處理架構，并且提出了的大數(shù)據(jù)反洗錢的演進方向。

關鍵詞：計算機應用技術；反洗錢；大數(shù)據(jù)；商業(yè)銀行

中圖分類號：TP31

文獻標識碼：A

DOI： 10.3969/j.issn.1003-6970.2016.02.001

引言

洗錢行為給國家和社會帶來了巨大損失，我國從上世紀末就開始從國家層面實施反洗錢建設，并且參考國際經(jīng)驗總結了諸多反洗錢策略。但是隨著金融業(yè)的快速發(fā)展和金融領域信息化的不斷深入，數(shù)據(jù)量的增長和新興金融產(chǎn)品的不斷推出，傳統(tǒng)的反洗錢方式在處理能力和處理精度上越來越不能滿足需求，所以商業(yè)銀行需要使用新技術來提升自己的反洗錢能力。本文介紹了反洗錢現(xiàn)狀和大數(shù)據(jù)相關技術及其優(yōu)勢，分析對比了當前大數(shù)據(jù)領域的一些適用技術，并且結合商業(yè)銀行的業(yè)務情況提出了一套實用的大數(shù)據(jù)反洗錢架構，最后總結了大數(shù)據(jù)反洗錢的一些發(fā)展方向。

1 反洗錢現(xiàn)狀

在21世紀初，為了適應國際反洗錢形勢，我國反洗錢工作逐步開展，反洗錢監(jiān)管體系從無到有，逐步建立起來。但是，當前反洗錢的形勢依然很嚴峻。根據(jù)中國人民銀行發(fā)布的《中國反洗錢報告2013》的統(tǒng)計，2013年人民銀行共發(fā)現(xiàn)和接收4854份洗錢案件線索，中國反洗錢監(jiān)測分析中心全年向公安部等部門主動移送和協(xié)查反饋數(shù)量超過前兩年總和。最近幾年，隨著走私、毒品、貪污賄賂等犯罪不斷曝光，非法轉移資金活動大量存在，對洗錢行為的預防監(jiān)控愈發(fā)顯得重要。

由于洗錢行為大多以商業(yè)銀行作為操作平臺，因而商業(yè)銀行在反洗錢方面具有重要的基礎性作用，商業(yè)銀行有能力也有義務對客戶身份、客戶交易行為進行識別，完成反洗錢工作的初篩工作。如果銀行在反洗錢方面工作不利，不僅會對銀行造成經(jīng)濟還有聲譽的損失，更會影響反洗錢當局的對于洗錢行為識別，造成國家層面的經(jīng)濟損失，影響國家的聲譽。

同時，隨著數(shù)字化信息時代的來臨，網(wǎng)絡交易和移動支付的數(shù)量不斷上升，越來越多、越來越詳細的交易數(shù)據(jù)對傳統(tǒng)的反洗錢處理方式構成了挑戰(zhàn)，單純的升級硬件或軟件已經(jīng)無法應對可預期的數(shù)據(jù)量的瘋狂增長，因而商業(yè)銀行需要新技術來確保未來的反洗錢工作能準確高效地進行。大數(shù)據(jù)處理技術的發(fā)展為商業(yè)銀行提供一個可靠的解決方案。

2 大數(shù)據(jù)簡介

大數(shù)據(jù)（big data），是指無法在可承受的時間范圍內(nèi)用常規(guī)軟件工具進行捕捉、管理和處理的數(shù)據(jù)集合，是需要新處理模式才能具有更強的決策力、洞察發(fā)現(xiàn)力和流程優(yōu)化能力的海量、高增長率和多樣化的信息資產(chǎn)。在維克托·邁爾一舍恩伯格及肯尼斯·庫克耶編寫的《大數(shù)據(jù)時代》中，大數(shù)據(jù)是指不用隨機分析法（抽樣調(diào)查）這樣的捷徑，而采用所有數(shù)據(jù)進行分析處理。大數(shù)據(jù)的SV特點：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（價值）和Veracity（準確性）。

隨著移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、社交網(wǎng)絡和云計算等領域的發(fā)展，大數(shù)據(jù)技術在眾多的領域得到了應用并推動了這些領域的發(fā)展。比如，在商業(yè)領域，沃爾瑪公司通過分析銷售數(shù)據(jù)，了解顧客購物習慣，得出適合搭配在一起出售的商品；在公共衛(wèi)生領域，谷歌通過對最頻繁檢索的詞條和美國疾控中心在2003年至2008年間季節(jié)性流感傳播時期的數(shù)據(jù)進行了比較，預測了2009年冬季流感的傳播；在社會安全管理領域，美國麻省理工學院通過對某地區(qū)十萬多人的SNS等信息進行處理，提取人們行為的時空規(guī)律性，進行犯罪預測。大數(shù)據(jù)技術的運用，給人類帶來了更多的想象。

雖然有些數(shù)據(jù)處理技術已經(jīng)出現(xiàn)，然而在一段時間內(nèi)它們只為調(diào)查局、研究所和世界上的一些巨頭公司所掌握，但隨著開源軟件的發(fā)展，以Hadoop為代表的數(shù)據(jù)處理技術和系統(tǒng)得以不斷的發(fā)展和完善，并且在諸多領域中得以運用，極大地推動了各個產(chǎn)業(yè)的發(fā)展。眾多大公司和研究所都在研究和使用Hadoop平臺，并且針對各個細分領域貢獻了更多實用的組件，使得Hadoop生態(tài)圈更加完善。

商業(yè)銀行每天都會產(chǎn)生大量的交易數(shù)據(jù)和客戶信息，使用大數(shù)據(jù)處理技術來實施反洗錢，對于商業(yè)銀行保證反洗錢職能、提升反洗錢效率、降低反洗錢成本等方面有著重大的意義。

3 大數(shù)據(jù)反洗錢的優(yōu)勢

使用大數(shù)據(jù)技術實現(xiàn)反洗錢，將大大提升商業(yè)銀行的反洗錢處理能力，跳過計算能力的瓶頸。當前，商業(yè)銀行傳統(tǒng)的反洗錢方式是依據(jù)《金融機構大額交易和可疑交易報告管理辦法》，對交易數(shù)據(jù)進行計算，若交易數(shù)據(jù)符合大額交易或者可疑交易標準，就將該數(shù)據(jù)報送反洗錢監(jiān)管機構。商業(yè)銀行一般使用Oracle等傳統(tǒng)的關系型數(shù)據(jù)庫進行數(shù)據(jù)的計算分析，由于傳統(tǒng)關系型數(shù)據(jù)庫的擴展能力有限，數(shù)據(jù)處理能力只能通過提升硬件性能來實現(xiàn)有限提升，無法應對越來越大量的交易數(shù)據(jù)。大數(shù)據(jù)處理技術能實現(xiàn)橫向擴充計算能力，在處理能力、擴充能力、成本等方面有巨大優(yōu)勢。當前，基于關系型數(shù)據(jù)庫的反洗錢操作都是通過SQL來實現(xiàn)的，大數(shù)據(jù)平臺有Hive、Spark SQL、Dremel等實現(xiàn)SQL接口的大數(shù)據(jù)處理工具，對于技術方案切換成本和技術學習成本都能有很好的控制。

大數(shù)據(jù)技術也讓反洗錢有更多的提升空間。傳統(tǒng)的關系型數(shù)據(jù)庫需要滿足范式等約束，一般只能處理結構化的數(shù)據(jù)。大數(shù)據(jù)技術支持非結構化的數(shù)據(jù)，同時配合強大的存儲能力能收集記錄更多維度的數(shù)據(jù)，在對交易數(shù)據(jù)計算的時候可以避免樣本計算帶來的缺陷，使用完整的數(shù)據(jù)進行計算分析提升反洗錢的效果。由于擁有強大的計算能力和存儲能力，反洗錢的識別可以突破《金融機構大額交易和可疑交易報告管理辦法》中相關規(guī)則的限制，提供更加細致的識別方案，比如可以針對每個客戶的歷史數(shù)據(jù)，對比每筆交易，統(tǒng)籌考慮時間、地點、金額、流向、頻繁程度等要素，理解相關交易行為的特點，配合離群值分析等機器學習算法，進而提升可疑交易的識別準確率。

4 大數(shù)據(jù)反洗錢的設計

4.1 反洗錢業(yè)務需求

中國反洗錢工作具有多部門協(xié)作的特點，商業(yè)銀行反洗錢工作只是其中一部分。完整的反洗錢工作流程包括：客戶和交易信息收集及篩選、大額和可疑交易分析及甄別、大額和可疑報告報送、數(shù)據(jù)匯總檢查及預處理、可疑交易甄別及行政調(diào)查、移交司法立案偵查等環(huán)節(jié)（見圖1），并由各商業(yè)銀行、人民銀行反洗錢機構和司法機構分別承擔，形成反洗錢工作的完整閉環(huán)。

當前大多數(shù)商業(yè)銀行都是采用Oracle、MySQL等傳統(tǒng)的關系型數(shù)據(jù)庫作為數(shù)據(jù)處理的主要T具，然而隨著信息數(shù)據(jù)的增長和數(shù)據(jù)分析的需求的轉變，傳統(tǒng)數(shù)據(jù)庫遭遇諸多瓶頸，比如數(shù)據(jù)量增長過快，導致運算效率下降；數(shù)據(jù)抽取處理的代價過高，無法在統(tǒng)一的視圖下處理；無法處理多種類型的數(shù)據(jù)；不具備進行搜索或關聯(lián)分析以發(fā)現(xiàn)隱藏關系的能力；不具備數(shù)據(jù)挖掘等高級分析的能力等等。大數(shù)據(jù)相關技術的發(fā)展為商業(yè)銀行快速精準分析數(shù)據(jù)提供了解決方向。

目前，商業(yè)銀行的數(shù)據(jù)分析一般是基于傳統(tǒng)的數(shù)據(jù)倉庫，考慮到技術演進的漸進性，需要對反洗錢處理的前后端兼容，同時兼顧使用的便捷性和穩(wěn)定性，所以使用大數(shù)據(jù)數(shù)據(jù)倉庫來實現(xiàn)；考慮到今后反洗錢策略的升級，新系統(tǒng)也需要為策略升級留下擴展接口。

《金融機構大額交易和可疑交易報告管理辦法》規(guī)定，金融機構應當在大額交易發(fā)生后的5個T作日內(nèi)，在可疑交易發(fā)生后的10個工作日內(nèi)以電子方式報送相關報告到中國反洗錢監(jiān)測分析中心。上報的時間比較寬裕，在線處理和離線處理都可滿足需求。

4.2 技術方案比較

4.2.1 數(shù)據(jù)采集技術

機構信息、員工信息、客戶信息、賬戶信息、牌價匯率信息、本外幣交易信息等數(shù)據(jù)的采集是由商業(yè)銀行的業(yè)務柜臺等直接和用戶交互的機構錄入到系統(tǒng)的，是典型的聯(lián)機事務處理（OITP），傳統(tǒng)的關系型數(shù)據(jù)庫和新興的NoSQL都是備用方案。下表對關系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫做了對比：

從上表可以看出，關系型數(shù)據(jù)庫和NoSQL具有不同的適用場景。商業(yè)銀行的交易數(shù)據(jù)相對來說模式比較固定，沒有大量的非結構化數(shù)據(jù)，單純OLTP場景下處理能力也完全能滿足需求，同時，銀行現(xiàn)有的業(yè)務系統(tǒng)也是基于傳統(tǒng)關系型數(shù)據(jù)庫，所以數(shù)據(jù)采集主要還是依靠傳統(tǒng)的數(shù)據(jù)庫來完成?？蛻魯?shù)據(jù)是非常冗雜的數(shù)據(jù)，當前商業(yè)銀行記錄的數(shù)據(jù)主要是交易相關的固定模式的數(shù)據(jù)，但是用戶數(shù)據(jù)是非常具有挖掘價值的，隨著用戶數(shù)據(jù)分析策略的升級，會有很多非結構化的數(shù)據(jù)作為補充，所以客戶數(shù)據(jù)可以逐步采用Apache HBase等NoSQL數(shù)據(jù)庫，增加對非結構化數(shù)據(jù)的支持，為在大數(shù)據(jù)平臺上實施客戶評級、風險監(jiān)控等策略的升級提供接口。

4.2.2 數(shù)據(jù)分析技術

實現(xiàn)大數(shù)據(jù)反洗錢，最主要的就是在交易數(shù)據(jù)中識別洗錢行為。中國人民銀行對商業(yè)銀行的反洗錢的要求就是識別和報送大額交易和可疑交易，使用SQL的方式進行反洗錢數(shù)據(jù)處理，是便捷有效的方式。反洗錢相關需求的實施是典型的聯(lián)機分析處理（OIAP），當前基于大數(shù)據(jù)平臺的OLAP方案主要有Apache Hive、Dremel clones、Spark SQL三種。在技術方案選型時，當前技術的成熟程度、開源分支的活力和技術演進的方向都需要考慮，需要從趨勢上避開一些不具發(fā)展?jié)摿Φ募夹g，比如之前的Shark。

Apache Hive最初由Facebool公司創(chuàng)建，是第一個基于Hadoop之上的SQL引擎，且至今仍是最成熟的。Hive主要解決的問題就是為開發(fā)人員提供SQL方言來存儲和處理Hadoop集群中的數(shù)據(jù)，封裝了復雜的編程任務，方便在海量靜態(tài)數(shù)據(jù)上做離線分析處理。到目前為止，Hive擁有最完整的SQL功能支持、最為穩(wěn)定，并且也是擁有最多貢獻者的項目，事實上大多數(shù)SQL引擎都以這種或那種方式依賴于Hive。Hive最初是構建在MapReduce之上的，運行穩(wěn)定但是耗時較多。Hortonworks于2013年提出Apache Tez引擎以提高Hive性能，Tez使用數(shù)據(jù)流（Dataflow）的方式避免了MapReduce中間結果的寫磁盤讀磁盤的性能瓶頸，提高數(shù)據(jù)分析的效率。Hive社區(qū)于2014年推出了Hive on Spark項目（HIVE-7292），并且在Hive l.1版本中正式推出。Hive on Spark在設計時盡可能重用Hive邏輯層面的功能，從生成物理計劃開始，提供一整套針對Spark的實現(xiàn)。在Hive l.l及以后的版本，MapReduce、Tez、Spark三個引擎可以自由切換。

2010年，Google公開了《Dremel：InteractiveAnalysis of WebScaleDatasets》一文，提出了PB級數(shù)據(jù)規(guī)模上的“交互式”數(shù)據(jù)分析系統(tǒng)。在PB級數(shù)據(jù)規(guī)模上，Hive使用MapReduce作為引擎執(zhí)行數(shù)據(jù)處理需要分鐘級時間，Dremel只需要秒級。Dremel論文公開后，外部有很多克隆版本，比如Facebook Presto、Cloudera Impala和Apache Drill. Dremel Clones沒有再使用緩慢的Hive+MapReduce批處理方式，而是通過使用與商用并行關系數(shù)據(jù)庫（ Parallel DatabaseSystem）中類似的分布式查詢引擎，可以直接從HDFS或HBase中用SELECT、JoIN和統(tǒng)計函數(shù)查詢數(shù)據(jù)，從而大大降低了延遲。然而，由于流式傳輸過程中，中間數(shù)據(jù)都保存在內(nèi)存中，當數(shù)據(jù)量過大內(nèi)存無法容納時，查詢就會失敗。Dremel Clones適用于原型階段的快速數(shù)據(jù)分析和模型建立，不適合有復雜處理邏輯的計算，不適合大數(shù)據(jù)量的計算。

Spark是一個通用的大規(guī)?？焖偬幚硪?，Spark完全跳出 MapReduce的處理模型，將數(shù)據(jù)集緩存在內(nèi)存中，并用Lineage機制容錯，其彈性分布式數(shù)據(jù)集（Resilient Distributed Datasets）也提供更豐富的編程接口?？傮w而言，Spark為我們提供了一個全面、統(tǒng)一的框架用于管理各種有著不同性質(zhì)（文本數(shù)據(jù)、圖表數(shù)據(jù)等）的數(shù)據(jù)集和數(shù)據(jù)源（批量數(shù)據(jù)或?qū)崟r的流數(shù)據(jù)）的大數(shù)據(jù)處理的需求。Spark在SQL方面的發(fā)展最早是基于Hive的Shark，由于Shark對于Hive有太多依賴（查詢優(yōu)化、語法解析等），性能提升遭遇瓶頸，2014年Spark Submit上Databricks宣布放棄了的Shark的開發(fā)，從此Spark上的SQL就分成兩個路線：Spark SQL和Hiveon Spark。Hive on Spark可以認為是前端Hive后端Spark，基于MR或Tez的Hive既有用戶可以在原系統(tǒng)與Hive on Spark系統(tǒng)之間輕松切換，切換工作僅僅只需要簡單地修改下配置參數(shù)。Spark SQL是一個完整的新引擎，Spark SQL團隊吸收Shark的優(yōu)點重新開發(fā)了Spark SQL代碼，使得Spark SQL無論在數(shù)據(jù)兼容、性能優(yōu)化、組件擴展方面都得到了極大的提升。Spark SQL在2015年5月的1.3的版本中才走出“Alpha”狀態(tài)，是全新的平臺，相對于Hive在功能豐富性和穩(wěn)定性上還有很多不足。

綜合分析各個數(shù)據(jù)處理平臺，結合商業(yè)銀行高穩(wěn)定性、高可用性需求以及大量交易數(shù)據(jù)和充足的離線運行時間的實際情況，選用至今最成熟的Apache Hive是商業(yè)銀行的最佳選擇。Hive支持MapReduce、Tez、Spark三大引擎，在運行效率和運行穩(wěn)定性之間有比較大的選擇空間。Dremel Clones可以作為輔助分析工具，幫助調(diào)研調(diào)試新的反洗錢規(guī)則。同時，Spark SQL發(fā)展迅速，也可能成為今后的最佳選擇。

4.2.3 數(shù)據(jù)存儲技術

大數(shù)據(jù)平臺的數(shù)據(jù)存儲主要是HDFS和HBase兩種。雖然HBase的底層也是基于HDFS，但是在許多特性上和HDFS是有明顯的區(qū)別的。

由于HBase是基于HDFS的，所以HBase也擁有HDFS的高吞吐量、高可伸縮性等特點。實質(zhì)上，HBase就是在HDFS的基礎上增加了基于內(nèi)存的緩沖區(qū)并調(diào)整數(shù)據(jù)查找方式。HBase適用于數(shù)據(jù)存儲和搜索，但是對于數(shù)據(jù)分析，性能會比HDFS差一些，因為HDFS上典型的訪問是順序I/O，而HBase上的訪問有服務器的socket連接資源消耗和對底層多個文件的合并過程。當前，有Apache Kudu這樣的項目來兼顧數(shù)據(jù)掃描、隨機訪問和數(shù)據(jù)分析的高性能，避免額外的數(shù)據(jù)移動，但是該項目正在處于孵化階段，暫時無法在項目中運用。

商業(yè)銀行反洗錢的主要數(shù)據(jù)源是交易數(shù)據(jù)，輔助數(shù)據(jù)源為客戶、賬戶信息；同時在數(shù)據(jù)的ETL處理階段，有碼值映射表等輔助數(shù)據(jù)。銀行每天業(yè)務結束后，會將數(shù)據(jù)導入到HDFS中，以供分析。交易數(shù)據(jù)是確定不變的數(shù)據(jù)，可以使用HDFS來存儲；對于客戶數(shù)據(jù)等可變數(shù)據(jù)，可以使用HBase存儲，在運行時加載到HDFS中以提高分析速度。如果不考慮非結構化和半結構化的數(shù)據(jù)，可以不用HBase直接將所有原始數(shù)據(jù)存入關系數(shù)據(jù)庫然后統(tǒng)一導入HDFS。 文件存儲格式對于數(shù)據(jù)分析的效率也有很大影響。目前，Hive支持的幾種主要的數(shù)據(jù)格式如下：

相對于純文本格式和面向行的二進制格式，面向列的二進制格式性能消耗較大，但是具有較好的壓縮比和查詢響應；同時ORC和Parquet還增加了數(shù)據(jù)的塊統(tǒng)計，能有效減少數(shù)據(jù)分析的時間。反洗錢業(yè)務需要大量的數(shù)據(jù)分析，所以分析時采用ORC格式具有比較好的效果。在數(shù)據(jù)倉庫中，數(shù)據(jù)會進行分層，不同的數(shù)據(jù)層應該根據(jù)實際采用不同的數(shù)據(jù)格式。

數(shù)據(jù)存儲文件也需要配合文件壓縮來減少占用的磁盤空間并加速數(shù)據(jù)在網(wǎng)絡間的傳輸。在反洗錢處理情景中，主要數(shù)據(jù)都是交易記錄，使用壓縮比和壓縮效率比較均衡的LZO或者Snappy皆可。

4.3 大數(shù)據(jù)反洗錢的應用

4.3.1 大數(shù)據(jù)反洗錢的架構設計

通過對反洗錢的業(yè)務研究和各個數(shù)據(jù)處理階段相關技術的對比研究，確定使用MySQL+HBase的方式來進行數(shù)據(jù)采集（不考慮非結構化數(shù)據(jù)可以全部使用MySQL）；使用HDFS+HBase的方式實現(xiàn)數(shù)據(jù)存儲。結合反洗錢的實際業(yè)務，對反洗錢整體的架構設計如下：

MySQL集群中存儲每天的交易數(shù)據(jù)和客戶數(shù)據(jù)，同時維護著一份反洗錢的配置文件。每天業(yè)務結束后，將MySQL中的數(shù)據(jù)導入到Hadoop處理平臺中。Hadoop環(huán)境中主要是使用Apache Hive作為數(shù)據(jù)倉庫，在Hive中進行ETL操作，將數(shù)據(jù)整理轉換為反洗錢計算的輸入，然后進行反洗錢的數(shù)據(jù)計算。最后將計算得出的預警結果導出到MySQL中。

就具體的數(shù)據(jù)分布而言，MySQL主要用于當前操作型事務和少量在線數(shù)據(jù)應用，其主要存儲系統(tǒng)基礎數(shù)據(jù)、元數(shù)據(jù)、當前處理數(shù)據(jù)（補錄數(shù)據(jù)、案例處理、報告信息等）等數(shù)據(jù)。Hadoop是作為數(shù)據(jù)處理平臺（Hive）和數(shù)據(jù)歸檔平臺（HBase），主要存儲海量指標數(shù)據(jù)和歷史數(shù)據(jù)（交易、報告、客戶/賬戶、評級歷史、日志等）。Hive作為基于Hadoop的數(shù)據(jù)倉庫，具有天然的易于擴充的海量數(shù)據(jù)存儲能力，所以存儲了所有歷史數(shù)據(jù)，但是基于Hive的查詢操作會很慢，所以使用HBase來輔助查詢。具體的數(shù)據(jù)流如下：

Hive相關的部分，是整個系統(tǒng)的數(shù)據(jù)處理中心，包括ETL和規(guī)則計算。數(shù)據(jù)源是銀行的業(yè)務系統(tǒng)每天產(chǎn)生的基礎數(shù)據(jù)，導出到Hadoop文件系統(tǒng)上；Hive通過Load命令將數(shù)據(jù)文件加載進入到貼源層，貼源層與源系統(tǒng)結構一致。數(shù)據(jù)加載到HDFS后，需要進行ETL轉化，主要使用HQL語言進行數(shù)據(jù)整理，最終在Hive中生成標準數(shù)據(jù)接口，然后將數(shù)據(jù)導入HBase，以供應用訪問。標準數(shù)據(jù)接口中的數(shù)據(jù)是全部數(shù)據(jù)，使用合適的過濾規(guī)則將當日規(guī)則計算需要的數(shù)據(jù)從標準數(shù)據(jù)模型中取出來，以縮小需要訪問的數(shù)據(jù)范圍。然后就可以進行反洗錢核心環(huán)節(jié)的處理，進行大額和可疑規(guī)則的計算，并且生成預警結果，最后將預警中間結果寫到MySQL。

每天的預警結果生成以后，需要在Mysql中對生成的預警結果進行案例生成，數(shù)據(jù)校驗等操作，其中并對部分數(shù)據(jù)進行補錄。對經(jīng)過在MySQL中補錄的業(yè)務數(shù)據(jù)，如客戶信息、賬戶、交易信息，歸檔到Hive中的標準數(shù)據(jù)接口中，再同步到HBase中。對經(jīng)過在MySQL中補錄、認定、報送已經(jīng)接收過回執(zhí)的數(shù)據(jù)，同步到Hive的歷史庫中，再同步到HBase中的歷史庫中。

前臺訪問主要涉及下面三個操作，日常的補錄、案例分析、報告及報送工作在MySQL中操作；對于查詢交易、賬戶、客戶等大數(shù)據(jù)量數(shù)據(jù)訪問HBase，通過服務接口；對于歸檔的歷史數(shù)據(jù)，通過服務接口訪問HBase。

4.3.2 大數(shù)據(jù)反洗錢計算實現(xiàn)

具體的反洗錢計算如3所示，涉及的過程是從“標準數(shù)據(jù)接口”開始，到生成“預警結果中間表”結束。主要的計算邏輯就是《金融機構大額交易和可疑交易報告管理辦法》中規(guī)定的4條大額規(guī)則和18條可疑規(guī)則，使用HiveQL根據(jù)客戶數(shù)據(jù)和交易數(shù)據(jù)的特征來識別可疑數(shù)據(jù)。

在計算過程中，由于數(shù)據(jù)量巨大，全部計算會浪費過多資源，所以需要根據(jù)反洗錢的計算規(guī)則提煉出一些過濾規(guī)則以減少待計算的數(shù)據(jù)量。當前使用的是以客戶為中心的篩選過濾規(guī)則，具體的過濾邏輯如下：

首先根據(jù)當天的交易流水過濾出所有出現(xiàn)過的客戶ID（包括對方客戶），然后計算回顧周期，最后根據(jù)回顧周期從歷史數(shù)據(jù)中篩選出回顧周期內(nèi)需要計算的數(shù)據(jù)。以客戶為基準過濾非計算數(shù)據(jù)，可以有效的避免計算資源的浪費。

反洗錢的計算過程中，描述性的規(guī)則在實施過程中需要量化。一條規(guī)則在量化后，會劃分成對公規(guī)則/對私規(guī)則、本幣規(guī)則/外幣規(guī)則等多種不同的子規(guī)則。大多數(shù)描述可以通過簡單的屬性劃分來完成，但是有些描述無法通過簡單的劃分來實現(xiàn)。以中國人民銀行的可疑規(guī)則第五條為例：與來自于販毒、走私、恐怖活動、賭博嚴重地區(qū)或者避稅型離岸金融中心的客戶之間的資金往來活動在短期內(nèi)明顯增多，或者頻繁發(fā)生大量資金收付。“短期內(nèi)資金往次數(shù)明顯增多”這種行為的識別需要和前期的數(shù)據(jù)比較得到，然而每次計算時都統(tǒng)計歷史上的交易次數(shù)明顯是很低效的。為此，設計了資金收付偏移比這一指標：

短期內(nèi)日平均交易次數(shù)

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

長期日平均交易次數(shù)+1

其中，“短期”和“長期”都是可調(diào)控參數(shù)，針對對公用戶和對私用戶等不同用戶有不同的時間設置。由于分母是日平均交易次數(shù)，可能是遠小于1的值，這樣的值會將偶爾出現(xiàn)的交易放大而出現(xiàn)失真，所以添加了基數(shù)1來控制敏感度。實際的資金收付偏移比的閾值和上面所列出的指標一樣，也是在參數(shù)表中動態(tài)配置的，默認的偏移比閾值是3。長期參數(shù)可以定期計算保存，這樣每次計算短期的日平均交易次數(shù)既可以獲得資金收付偏移比，“短期內(nèi)資金往次數(shù)明顯增多”可表示為資金收付偏移比大于閾值，大大減少計算量。在實際的反洗錢計算中，還有新賬戶指標、賬戶活躍度指標等，都是為了降低計算復雜度而設立的，在此就不全部列舉。

5 反洗錢發(fā)展展望

隨著信息科技的發(fā)展，互聯(lián)網(wǎng)金融等眾多新興的交易模式逐漸增多，這些新技術在方便普通用戶的同時，也給不法分子提供了新的洗錢手段。因此，作為反洗錢前沿陣地的商業(yè)銀行更需要提升反洗錢的能力，保證金融市場的有序穩(wěn)定。商業(yè)銀行提高反洗錢能力，一方面是反洗錢平臺技術的提升，提高數(shù)據(jù)處理能力；另一方面就是反洗錢識別策略的提升，提高數(shù)據(jù)處理的效率。

在平臺技術方面，通過上文的對比分析，可以看出當前大數(shù)據(jù)技術已經(jīng)從具有處理能力向具有快速處理能力發(fā)展，越來越多的考慮使用內(nèi)存、固態(tài)硬盤等硬件睞加速執(zhí)行過程。MapReduce、類分布式搜索引擎、Spark等諸多技術的發(fā)展，提供越來越高效的數(shù)據(jù)分析手段。當前，類似Kudu、Spark SQL等部分新的技術尚處在初期發(fā)展階段，暫時不能在商業(yè)銀行這種對穩(wěn)定性要求比較高的隋況下使用，但是將來肯定會是數(shù)據(jù)處理的有力擴充。本文采用的是離線的處理方式，針對反洗錢的部分規(guī)則，可以采用Storm等流式計算引擎來完成在線實時分析計算，如果能在秒級別識別洗錢行為，那么對于整個反洗錢生態(tài)都是顛覆性的。

在反洗錢識別策略方面，商業(yè)銀行傳統(tǒng)的反洗錢監(jiān)控上報都是基于《金融機構大額交易和可疑交易報告管理辦法》，這一套方式是對過去反洗錢手段的總結，在應對眾多新型交易方式，難免有疏漏之處。升級反洗錢識別策略，主要就是引入分類、估計、預測、關聯(lián)規(guī)則、聚類、描述和可視化等數(shù)據(jù)挖掘技術，從大量數(shù)據(jù)中揭示J葉J隱含的、先前未知的并有潛在價值的信息。增強對客戶的風險控制，避免顯性檢測規(guī)則的弊端，降低反洗錢的識別成本，提升反洗錢執(zhí)行效率。本文的反洗錢架構給反洗錢識別策略的升級預留了接口，可以使用機器學習組件Apache Mahout在HDFS上直接調(diào)試部署；也可以使用Hivemall直接基于Hive進行算法的訓練部署；也可以使用基于Spark的機器學習系統(tǒng)MLbase及底層的分布式機器學習庫MLlib來進行反洗錢新策略的訓練升級。盡管近年來在反洗錢識別策略方面的研究取得不少進展，但總體來講‘框架研究多，具體方法研究少；理論研究多，結合具體場景研究少”，目前并沒有切合實際的方案，但這是反洗錢的必然發(fā)展方向。

6 結語

隨著全球經(jīng)濟信息化不斷加快，洗錢犯罪也呈現(xiàn)出更加多變、隱蔽的特點。商業(yè)銀行作為反洗錢的前鋒，承擔著反洗錢工作的重要職責。大數(shù)據(jù)時代的海量數(shù)據(jù)不僅給商業(yè)銀行的反洗錢帶來巨大壓力，同時也給整個金融市場帶來了全面提升反洗錢效率的契機。

本文從當前商業(yè)銀行的反洗錢技術在數(shù)據(jù)處理能力不足的角度出發(fā)，分析了商業(yè)銀行的反洗錢業(yè)務需求，并對比總結了當前大數(shù)據(jù)相關技術在反洗錢場景下的優(yōu)缺點和適用情況，根據(jù)實際的業(yè)務情況提出一套實用的可擴展的大數(shù)據(jù)的反洗錢處理框架，并且在反洗錢計算部分提出了優(yōu)化意見，最后討論了反洗錢發(fā)展的兩個方向。相信在不久的將來，大數(shù)據(jù)技術將和反洗錢碰撞出更多的火花。