消費金融大數據風控架構與實踐（雲時代架構文章讀後感07）

風險：

1.1 信用風險

 

根據銀行業的風險理論，信用風險是指借款人因各類緣由未能及時、足額償還債權人或銀行貸款而違約的可能性。

 

信用風險的風控重點在於，甄別客戶違約的緣由到底是還款能力，仍是還款意願問題。若是客戶真的因爲各方面的緣由，暫時不具有還款能力，這是機率問題。即便發生了，處置起來也不會有什麼損失。而若是是還款意願問題，存在較大的資金損失機率。

 

1.2 欺詐風險

 

在風控中，欺詐風險比信用風險要大得多，因此反欺詐是重中之重。通常來講正常的客戶，若是不是刻意騙貸的，只是由於家裏出現突發事故、生意出現問題、暫時失業等等緣由而致使資金週轉不過來而逾期的，這畢竟是少數，並且借款只是逾期，可以還款的機率仍是比較高。

 

消費金融行業絕大多數不良是由於欺詐引發的，若是反欺詐可以比較有效的狀況下，信用風險控制在5%之內沒有太大問題。

挑戰：

消費金融發放的借款都就小額分散的，沒有任何抵押和擔保的狀況。隨着消費金融行業的崛起和規模擴大，整個行業面臨的欺詐問題愈來愈嚴重，一批批的羊毛黨和欺詐等黑產團體接踵而來。黑產團隊的規模越大，意味着消費金融機構的損失越大。

 

欺詐風險目前是總體消費金融風控的重點，目前整個行業75%甚至以上的風險都是來自欺詐風險。形式有不少種，如常見的身份僞冒、中介黑產、僞造材料、惡意套現等。欺詐主體一是申請本人或親戚朋友，二是借用或盜用別人的身份信息進行欺詐。欺詐主體的不一樣，防範風險的手段和形式也不一樣。

架構實踐：

4.1 業務架構

 

風控平臺是相對獨立的系統，信審的案件能夠從借款端平臺推過來，也能夠從第三方平臺推過來。信審案件到達風控平臺後，自動建立工做流，根據風控流程處理各流程環節任務。

 

• 自動決策

 

風控流程自動處理案件，訪問第三方合做夥伴的接口，獲取用戶黑名單、欺詐數據和多頭借貸等數據，查詢名單數據，決策引擎輸出各環節處理結果。自動決策後出三個結果，自動經過、轉人工、拒絕。

 

• 人工信審

 

根據決策引擎輸出的結果進行轉人工處理，人工經過初審和複覈崗，給出具體信審結果，信審經過的案件給出風險等級和具體額度。

 

• 拒絕

 

被自動或者人工拒絕的案件通知到用戶，建議補充資料、過段時間從新申請或者推薦到第三方機構。

 

4.2 技術架構

 

4.2.1 分佈式、微服務架構

 

分佈式架構目前是互聯網行業成熟應用的架構，這裏不詳細討論。

微服務架構下，比較成熟的使用Spring Framework，使用MyBatis、Hibernate等數據映射框架。

 

4.2.2 RPC架構

 

RPC是分佈式架構的核心，解決服務分佈和服務解耦問題，目前咱們使用的是Dubbo, RPC框架解決序列化、反序列化、網絡框架、鏈接池、收發線程、超時處理、狀態機等「業務以外」的重複技術勞動。

 

4.2.3 分佈式消息

 

分佈式系統中重要的組件，解決應用耦合，異步消息，流量削鋒等問題，是分佈式系統不可缺乏的中間件。目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。

 

4.2.4 分佈式緩存

 

高併發環境下，大量的讀寫請求涌向數據庫，磁盤的處理速度與內存顯然不在一個量級，從減輕數據庫的壓力和提升系統響應速度兩個角度來考慮，通常都會在數據庫以前加一層緩存。因爲單臺機器的內存資源以及承載能力有限，而且，若是大量使用本地緩存，也會使相同的數據被不一樣的節點存儲多份，對內存資源形成較大的浪費，所以，才催生出了分佈式緩存。經常使用的分佈式緩存是Redis。

 

4.2.5 分佈式日誌

 

分佈式狀況下，每一個日誌分散到各自服務所在機器，日誌的收集和分析須要統一處理。日誌框架主要這幾塊內容：

 

• 業務日誌埋點

• 日誌收集處理系統

• 日誌處理系統

• 日誌分析系統

 

ELK（ElasticSearch, Logstash, Kibana）平臺能夠實現日誌收集、日誌搜索和日誌分析的功能。

 

4.3 反欺詐平臺

 

目前的欺詐團伙已經造成完整的地下產業鏈，反欺詐平臺須要根據平臺沉澱的用戶數據、環境數據、第三方數據結合生物探針技術採集的本次用戶行爲數據，創建用戶、環境、行爲畫像以及基於用戶、環境、行爲的關係網絡，經過對業務數據創建多重模型來甄別對異經常使用戶的識別能力和反欺詐能力。

 

4.3.1 數據來源

 

數據源主要是三個方向：

 

1. 用戶申請過程的填寫的數據和埋點時採集的行爲數據和日誌數據。

2. 第三方合做數據，如人行徵信數據、學歷、多頭借貸等數據。

3. 互聯網上的數據，須要靠開發的爬蟲平臺去抓取。

 

數據分類主要如下幾類：

 

1. 身份信息：姓名、身份證、手機號、卡號、居住地址、學歷等。

2. 信用信息：收入信息、借款信息、賬戶信息、還款和逾期信息。

3. 社交信息：通迅錄信息、通話記錄、QQ和其它平臺交互信息。

4. 消費信息：銀行卡詳單、電商網站購買信息等其它信息。

5. 行爲信息：申請和填寫信息、GPS、時間點、地點等信息。

6. 第三方：多頭信息、黑灰名單、授信信息。

 

4.3.2 反欺詐模型

 

以上的多方面數據，能夠根據對用戶行爲、語義、關聯網絡等組成一個巨大的數據關係圖譜。利用這些數據創建的模型風控體系對用戶的欺詐機率、還款風險等進行強有力的預測和判斷。

 

4.3.2.1 社交圖譜模型

 

利用「手機-設備」及「手機-手機（通話）」關係，進行圖建模，全部用戶及外部已知風險手機號容納在一張圖中，經過圖中的風險標記以及圖中的異常關係結構。

 

用戶數據量上來的時候，社交關係很容易破億，這時候就要使用圖數據庫，相對成熟就是Neo4j，比易用性和穩定性來說Neo4j比orientdb和arangodb要好不少。

 

NEO4J數據庫，其可提供35億節點，當前2.5億多點，其中付費版支持無限節點，費用是6.8萬美圓/年。

 

4.3.2.2 黑產攻擊模型

 

經過分析收集的高風險人羣及中介通話數據，挖掘出一張高風險人羣聯繫密切的關係網，有效識別申請動機不良的客戶，發現黑產攻擊苗頭。

 

4.3.2.3 多頭授信模型

 

經過對客戶與各種機構的通訊關係，發現一些體現多頭風險異常結構，如客戶總被一些催收機構聯繫，同時又在主動撥打其餘一些機構的營銷電話。

 

4.3.2.4 頻次異常分析

 

欺詐團伙在發現系統規則漏洞時，每每會在短期內發起大量欺詐交易，以便在受害者反應過來前儘快變現，例如醫美欺詐案，短期內大量發起虛假的美容貸款請求。

 

這種交易的頻次經常會在時間分佈上造成異常的波形，經過ARIMA模型能夠很好的預測事件的時間分部特徵，貝葉斯框架的生成式模型可以解決不一樣空間分佈維度下細顆粒都的時間分佈問題。

 

經過這兩種手段能夠將時間和空間分佈上存在異常的交易行爲與正常的交易行爲區分開來。

 

4.3.2.5 欺詐團伙發現

 

在互聯網金融行業，欺詐團伙日益嚴重而且難以防範。從特色上來看，團伙欺詐有以下幾個特色：

 

• 專業性。欺詐團伙一般會根據各平臺的風控規則，制定相應的欺詐手段；

• 多變性。欺詐團伙的欺詐手法常常變化，讓各平臺防不勝防；

• 爆發性。欺詐團伙一旦發現欺詐的可能性，會在短期內，利用地下渠道得到的身份信息，大量反覆地欺詐；

 

團伙欺詐的發現是業務反欺詐領域面臨的一個重要挑戰。目前反團伙欺詐技術思路以下：

 

• 構成網絡：將交易，交易信息項（地址，電話，設備id），用戶等定義爲節點；同屬一個交易的節點間造成邊；對邊根據業務經驗或其餘規則賦予權重；

• 特徵提取和信息挖掘：提取網絡飽和度，網絡直徑，關聯度，中心度，羣聚係數等特徵；基於已有的黑名單，利用社區發現等算法獲得節點的欺詐相關程度預測；

• 加入模型：提取的特徵能夠做爲模型或規則的輸入；

• 欺詐預警：在無標註數據的狀況下，及時發現異常的網絡拓撲結構，做爲欺詐的早期預警；

 

4.3.2.6 評分模型

 

在消費金融反欺詐領域，各類欺詐特徵常以規則形式出現，經過一系列的規則的邏輯組合，排除有欺詐嫌疑的進件:

 

• 規則系統優勢：可解釋性強，能夠迅速調整，應對欺詐手段變化；

• 規則系統缺點：複雜的規則體系難於維護，難以利用弱特徵，對強特徵依賴，容易被攻破；

 

評分模型：評分模型在金融領域應用至關成熟，信用評分模型是最多見的應用。但公司將評分模型應用到反欺詐場景時經常與信用評分混淆，但本質上，兩者的預測目標是不一樣的，反欺詐模型預測的是欺詐的可能性，信用模型預測的是還款的可能性。所以創建獨立的反欺詐評分模型頗有必要。

 

反欺詐評分模型有以下優勢：

• 能夠充分利用弱特徵；

• 對抗性好，模型結構由一系列弱特徵決定，提升欺詐者假裝成本；

 

反欺詐評分模型和反欺詐規則系統有很好的互補性，在風控平臺中，同時創建起反欺詐規則系統和評分模型頗有必要。

 

4.4 變量平臺

 

反欺詐模型和信用模型兩個模型體系裏，最基礎的須要先加工出風控變量，根據基礎信息、關聯關係、信用歷史、設備信息、社交數據以及消費和交易數據等六大緯度加工出數百、數千或者數萬個變量。輸出給模型進行計算和決策。

 

基於實時決策的風控流程須要對數據和大部分變量加工有實時性要求。隨着數據量愈來愈大，傳統關係數據沒法解決實時和效率的問題，基於Hadoop平臺的解決方案成爲變量平臺的方案。

 

4.4.1 數據來源

• 實時日誌採集：

業務埋點在流程處理中把風控須要的數據打印到日誌中。

Flume從日誌採集的數據放入kafka消息隊列中。

• 實時日誌採集：

經過Canal分析mysql的bilog日誌，放到kafka中。

4.4.2 數據加工

Spark streaming處理時效只能達到準實時，因此變量加工採用Storm方案。Storm能夠達到低延遲的響應，在秒級或者毫秒級完成分析、並獲得響應，並且體系可以隨着數據量的增大而拓展。