基於大數據的資金關係圈探索實踐

背景

2016年12月，國內銀行展示科技風險管理技術的最高規格會議——銀監會「銀行業信息科技風險管理課題成果獎」頒獎大會隆重舉行，我公司與某行合作建設的大數據平台憑藉《大數據時代銀行資金關係圈探索與應用》課題從全國數百家金融機構上千個課題，一、二、三、四類級驗收成果中脫穎而出，一舉斬獲一類成果大獎！

那什麼是關係圈呢？隨著互聯網及微信朋友圈的日益發展，社交網路再次成為人們關注的焦點，針對複雜網路的研究，特別是社群發現受到了普遍的關注。研究表明，用戶關係圈等複雜網路除了擁有小世界和無標度的特徵，還具有社區結構特徵。雖然學術界還沒有針對社群的統一定義，一般我們認為社群是一組具有相似屬性的節點集合，並且具有社群內部邊稠密，社群外部邊稀疏的特徵。不同社群的挖掘就是通過各種社群發現演算法進行切割形成。銀行客戶基於資金往來、銀行業務推薦、貸款擔保、單位信息、資金關係等信息，可以隸屬於生意圈、朋友圈、同事圈等多個典型的社群，即銀行客戶資金關係圈體現為典型的重疊社群模式。

銀行客戶資金關係圈是銀行對客戶社交關係的探索，它以客戶基本信息、轉賬流水、辦理業務留存的社會關係等各種零散數據為基礎，運算每個客戶的社交網路，聚類出關係最密切的客群，輔助銀行為每個客戶提供更加人性化、個性化的金融服務。

客戶資金關係圈對銀行業務的開展有著很大的幫助：

1、資金關係圈的人員關係親密度和可信度高於社交圈子，通過資金關係圈子可挖掘客戶可靠的社會關係；

2、將資金關係圈與銀行獲客、營銷相結合，能夠提升銀行獲客、信用卡營銷、網路金融營銷等的準確率；

3、將資金關係圈數據應用於發卡審批、信貸審批、調額、貸后管理等業務流程中，能進一步提升銀行的風險管理能力；

4、資金關係圈與銀行信用卡反欺詐、信貸反欺詐等場景相結合，提高實時風險的識別度，能加強銀行的風控能力。

二、方案

2.1 總體方案

該行每天會有600萬筆交易數據，一個月生成的數據量大概為135GB，若不進行合適處理，每次更新個人圈子表的時候會耗時巨大。同時，數據導入到應用資料庫也會需要比較長的時間。在業務使用上，該行有約五千萬客戶，如果假定平均每個客戶與10人有過關係，也有五億條記錄，在業務使用上需要保證數據處理的時間成本不能過大。

為有效地實現關係圈子的挖掘，我們把實現的主要步驟分成六步：採集、清洗、加工、存儲、建模、展示。其實現的流程可以用下圖表示：

圖1：關係圈子數據處理流程圖

其中，採集、清洗、加工、存儲、建模交由後台經Hive/MapReduce處理，展示則通過前端Java實現。

2.2 後台處理邏輯2.2.1 ETL數據分層模型

後台方面，我們的整體數據處理在應用中使用分層結構進行處理（ITL、IML、ICL、IDL）。

圖2：整體數據分層處理流程圖

ITL層主要任務是存儲源系統數據，保證獲取數據的時效性和準確性。IML層主要任務是將ITL層的數據按主題進行整合及數據清洗，並加工各主題內部主鍵的映射關係。ICL輕度匯總層主要任務是將各主題內部數據進行共性整合，為指標管理工具提供輸入介面。IDL層利用自助報表平台進行靈活口徑的數據探索，固化業務報表的加工口徑。

通過數據分層設計，對數據進行共性整合，一次加工、多次使用，減少重複的開發工作。通過數據分層設計，統一數據加工標準，促進數據加工標準在大數據平台落地。通過數據分層模型設計，對數據按層級逐級進行加工，降低源系統數據變更的不可控風險，更好的支持共性加工和指標層穩定。通過數據分層模型設計，對元數據進行統一管理，方便後續的數據治理和血統分析。

在數據分層模型中，制定大數據平台數據命名規範，將各層級數據命名標準化。共性加工層及指標層數據開放給業務使用，推動業務人員深度參與大數據項目建設及業務需求自助化開發。

2.2.2 關係圈子加工數據整合

對於關係圈子的處理，我們在與業務探索的過程中，把關係、電話、地址分別獨立出來。關係用於關係圈子的生成，電話與地址則是業務重點關注的信息，所以特別對其進行去重、分類處理。

關係又可以分為：資金圈、親屬圈，朋友圈，同事圈，其他圈。每個圈都有細分子類，如親屬圈包括配偶、子女、兄妹、父母等；其他圈包括擔保人、員工、同家庭電話、同家庭地址等類別；資金圈有微信AA轉賬、微信紅包、銀行內理財工具等多種渠道關係。

圖3：關係及聯繫方式採集轉換流程圖

圈子是由周批全量生成，每次都是重新全量生成新的圈子，這就意味著圈子的有效性僅為一周。但根據業務需要，需要保留一部分關注的圈子。因此，圈子寬表數據的構成應該是上周被關注的圈子加上每周生成新的圈子數據組成。為了避免圈子ID的重複，圈子ID改為由圈子原ID+日期構成。

數據去重

對於數據去重處理，我們針對不同的情況進行特別處理，比如，擔保人關係數據去重處理如下：

圖4：擔保人關係去重流程圖

微信AA轉賬聯繫人關係信息則處理如下：

圖5：微信AA轉賬關係去重流程圖

數據清洗

在清洗階段，我們會對信息進行歸一化。那什麼是信息歸一化呢？潛在客戶歸一化是指對於從不同的業務系統發現的不同潛在客戶，通過某些歸一化規則合併成一個客戶（存量或潛在）的過程，即將不同潛在客戶號的多個客戶合併成一個客戶號的過程，且合併后的客戶號可能是存量客戶號或潛在客戶號。

圖6：數據歸一化流程圖

數據存儲

加工后的結果數據存儲於HIVE裡面。同時，為了可視化的實現速度，把結果數據同步到應用資料庫中。

數據建模

後台處理過後的數據會用於建模，為了更好地展示同一客戶不同關係人的親疏程度，讓業務理解兩人之間的關係，需要把客戶之間的關係進行量化處理。處理特徵包括如兩位用戶之間的轉帳金額、兩位用戶之間的轉帳次數、兩位用戶各自的的轉帳總量等多個因子，通過一系列公式演算法計算，生成關係權重置信度。同時，基於數據探查，測試數據及業務驗證對模型進行反覆調優。實現機器學習的學習方式，重視業務驗證，反覆迭代，對公式進行更新。設定可接受的相似值（不能過高，防止過度擬合測試數據），當相似值在設定範圍內視為模型符合要求。

圖7：建模流程圖

2.3 前端展示

前端應用架構上，我們構建了360全景視圖平台（描述客戶畫像），對外提供登錄認證、信息分佈、單客標籤、關係圈子、客群篩選、後台管理、對外接等模塊。基於Elasticsearch（ES）查詢獲取後台離線加工好的客戶信息及標籤、客群篩選等全方位信息。使用資料庫獲取圈子挖掘等信息，並通過mysql進行元數據管理。此外，系統也支持Impala/Phoenix介面對接Hive/Hba se。

圖8：客戶畫像邏輯架構圖

圈子信息又細分為6種子功能模塊：

（1） 基本圈子信息：通過對客戶查詢獲取其基本圈子信息；

（2） 自定義圈子查詢：通過度數（一度及二度人脈）、關係、往來金額、往來次數、單點關係展示數量等對圈子進行自定義查詢；

（3） 圈子模糊查詢：提供關鍵字模糊查詢功能；

（4） 客戶類型查詢：根據客戶類型分類查詢，如我行個人客戶、我行對公客戶、它行個人客戶、它行對公客戶、VIP客戶、黑名單客戶；

（5） 客戶聯繫方式查詢：點擊圈子的關係人，關聯查詢其客戶聯繫方式；

（6） 客戶查詢：在客戶聯繫方式查詢中，可通過點擊頭像進一步獲取客戶詳細信息。

圈子展示

圖9：關係圈子圖

客戶聯繫方式查詢

圖10：客戶聯繫方式

客戶查詢

圖11：客戶明細信息

最後，對於客戶信息的處理，我們還要考慮紅名單、黑名單等相應的過濾操作。

三、總結

我們對圈子功能進行了反覆的驗證，歷經5次版本迭代和6輪驗證，於2016年8月順利投產並投入業務應用。現已在信用卡失聯催收、潛在VIP客戶識別等業務場景中廣泛應用並獲取良好收益，其中失聯催收業務即可為該行每年新增900萬元催收回款，失聯查得率高於92%，失聯客戶有效聯繫率高於40%。本系統對識別銀行客戶社交網路各要素，研究各要素靈敏度、深化關鍵節點和要素等領域做了深入探索，對銀行開展大數據業務具有重要的實踐和參考意義。