1. 程式人生 > >【幹貨】第三方支付風控系統架構與運作機制闡述

【幹貨】第三方支付風控系統架構與運作機制闡述

價值 關聯 需要 emca voltdb 一個 memcache 事件處理 可靠的

<轉自http://www.sohu.com/a/2793317_116173>

第三方電子支付是一個高風險的行業,這就意味著第三方電子支付公司必然要與各種不確定性相伴。從風險受益的角度來看,第三方電子支付公司存在的價值不在於其能消滅不確定性,消滅風險,而在於其能在對風險有較深入認識的基礎上控制和管理風險,將風險配置到願意並能承擔風險的主體,並使其獲得收益。風險控制系統目標是實現對各個業務部門、渠道和產品線和相關人員監測,通過對運營業務交易的實時分析、事中和事後分析、跟蹤和處理的方法實現欺詐風險預警的自動化。通過對交易的監測,可以識別那些是高風險交易,以及早發現其欺詐的可能性,並及時采取各種防範措施,由此來降低交易帶來的損失。

一個新產品需要重點考慮業務風險控制。關於風險控制系統整體的技術方案。此方案盡管能夠滿足業務需求,但對於海量交易數據分析、風險事件的實時處理、大量的風險規則處理上,在實時性、性能、架構的可擴展性上都不是很理想,有必要重新從架構上考慮一下實現方案。

一般而言,風險控制系統標準的軟件架構如下:

技術分享

1、風控系統實現的幾種方案

1)、數據庫方案:將風險規則、交易數據等都采用關系數據庫存放。正如 支付系統風控系統建設思考 所提到的方案,交易庫和風險庫一般分別部署在不同的服務器上,在事件觸發上可以采用數據庫觸發器、消息隊列事件等方案。此種方案技術實現相對簡單,但在進行海量交易數據查詢以及大量風險規則處理時候,數據庫系統查詢性能及擴展性成為一個較大的瓶頸。很難滿足風險事件實時分析的要求。

2)、內存數據庫方案:由於對海量交易數據的查詢、分析極其消耗數據庫資源,可以采用內存數據庫方案來替代關系數據庫,保證風險事件實時處理的性能。 但目前開源的內存數據中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大規模的業務場合應用的成熟度尚待考察,而Oracle TimesTen、MCObject eXtremeDB、Altibase價格太高。

3)、分布式緩存方案:采用Memcached等NOSQL的分布式緩存來緩存交易數據、風險規則等,但由於NOSQL解決方案並不擅長數據間的關系邏輯處理,需要在程序中大量維護業務處理邏輯,遠不如關系數據庫或內存數據庫方案方便。

以上方案,都可以通過規則引擎(例如drools)來完成風險規則的管理和維護,避免了風險規則維護的繁瑣及規則間復雜關系處理。

Complex Event Processing (復雜事件處理)是一種新興的基於事件流的技術,它將系統數據看作不同類型的事件,通過分析事件間的關系,建立不同的事件關系序列庫,利用過濾、關聯、聚合等技術,最終由簡單事件產生高級事件或商業流程。CEP適合的場景包括實時風險管理、實時交易分析、網絡詐欺、網絡攻擊、市場趨勢分析等等。

技術分享

CEP的幾大特點:

基於數據流

時間序列

實時

復雜

技術分享

支付系統風控系統建設思考

1. 管理框架

第三方電子支付風險管理解決方案由風險戰略,組織架構和管理流程組成。其中,風險戰略的確定是欺詐風險管理業務體制和運作機制設計的基礎;組織架構確立風險管理運作機制和相應的組織管理模式,明確相關部門、人員、關鍵崗位分工和職責;管理流程則是一個完整的風險管理過程所包含的各個環節。各種風險管理的機制和體制需要通過統一的管理平臺來實現。統一的欺詐風險管理平臺包括監測模塊、分析模塊和案件管理模塊。構建風險管理 平臺的關鍵技術是以合理規範的數據模型,建立整合的風險數據平臺;以及針對內部程序、人員和外部事件,實施有效的業務運營監測。

統一的風險控制系統包括三大模塊:監測模塊、分析模塊和案件管理模塊。 監測模塊對支付平臺的運營作業進行全面監測,將可疑行為信息和相關信息發送到分析模塊進行分析確認,當發現異常行為時發出警報,將警報和與警報相關的信息都發送到分析模塊和案件管理模塊。 分析模塊能對各種數據源進行集成,對各種歷史數據進行學習分析,通過數據挖掘建模定義出典型的行為特征,建立行為模式、場景,並制定欺詐風險監測規則。 案件管理模塊最終將案件處理的數據反饋到監測模塊,從而增強監測模塊對風險的監測和識別能力。

1. 監測模塊

交易監控系統要及時對交易進行處理,在最短的時間內對可能存在的交易風險進行判別,準確的報告欺詐等高風險交易,在第一時間提供詳盡的信息以協助工作人員對可疑交易進行識別、處理。為保證這種效能,交易監控系統需要采用準實時、分布式的模式進行交易處理。在部署上交易監控系統和交易系統應當支持分布式部署,在不同的主機系統上部署,系統間通過可靠的消息中間件進行信息的傳遞,降低系統間的耦合度,保證交易系統的高性能,同時也可以通過前置機方式來降低交易系統對信息處理的負荷。

交易系統在接收到主機的交易信息,及時地發送至交易監控系統;而交易監控系統的接收端也要及時地處理發送至交易監控系統的分析審查信息。當一筆交易進入交易系統後,系統會根據業務規則進行處理,完成以後系統會給這筆交易返回一個結果代碼(批準或拒絕)。在整個交易處理完成之後,主機將交易信息下傳至前置系統。

交易系統接到聯機交易後,通過消息隊列將此筆交易信息傳送到交易監控系統,在交易監控系統內部進行交易情況分析及報警處理。交易系統除了向交易監控系統傳送交易信息外,還需提供客戶的基本信息例如狀態等資料。交易監控系統將從前置系統的jms消息隊列中接收交易系統主機發送的交易信息。上述交易信息將由前置系統所在平臺上的接口程序與帳戶資料、卡片資料等信息組合後形成一個XML報文,通過jms消息隊列傳送給運行在交易系統平臺上的交易監控系統接口程序,經監控系統接口處理後通過jms隊列送入交易監控系統。為保證交易監控系統和交易系統間信息的同步,可采用數據庫的replication機制來保證數據的實時同步;也可以采用程序或存儲過程來實時同步核心數據(例如客戶資料的變動),定時同步其他數據的方式。

3. 分析模塊

分析模塊采用商業智能技術來構建風險控制系統的風險分析引擎,采用商業智能技術可以對海量數據快捷的存儲和提取,基於數據的分析、操縱,建模,穩定的報表能力,多用戶支持能力,再結合有效的信息權限控制、風險預警模型、風險預測、信息整合等,就能夠有效進行電子支付系統的風險管理。

商業智能在風險控制中所起的作用:

a.數據準備: 數據準備主要是從源數據中,提取有效的指標數據、預算數據、交易匯總數據等,並轉換到總體的數據倉庫或風險管理的數據集市中,其本質是實現從操作型數據源到分析型數據變換。

b.分析模版定義: 對各種分析內容進行分類,同時明確風險管理方面的各個數據主題模版定義,包括風險評級,風險分析,風險預測幾個模版定義,提供給風險分析內容進行調用。

c.風險分析: 目前已有多種風險分析度量模型,如基本指標法、標準化方法、內部衡量法、損失分布法、極值理論模型等,可根據銀行業務需求建立。這一階段主要是運用這些模型來對風險進行分析,確定數據的維度、事實表、量度等信息,根據維度來分析各個指標和預測信息。

d.自動化分析: 利用商業智能軟件提供的功能,並根據已經定義的風險分析內容,由系統自動到數據倉庫系統進行優化分析,加載與鉆取這些風險內容。

e.定量、定性分析報告: 根據系統的自動化分析,生成各種定量和定性的分析指標報告。

【幹貨】第三方支付風控系統架構與運作機制闡述