在線支付之風控系統架構選型

風控系統介紹

伴隨着互聯網的發展,遊戲、商貿、慈善、博彩、餐飲等各行各業都開始觸網。“天下熙熙,皆爲利來;天下攘攘,皆爲利往”,種類繁多的網絡活動直接或間接的都與錢相關,傳統的支付不能滿足人們快節奏的互聯網生活,電子支付應運而生,但電子支付給人們帶來方便快捷的同時也給參與支付的各方帶來了風險,賬號盜用、虛假交易、金融欺詐等事件層出不窮。支付風險自古就存在,在互聯網繁榮的今天只是多了些新花樣,風控系統就是通過監控交易、渠道、產品、用戶,對相關數據進行實時、準實時、定時的分析、挖掘,從而識別交易風險,儘早發現欺詐,採取各種措施降低交易損失。

風控系統功能性需求

實時監控——針對各類支付業務交易風險的事中監測與控制。
同步反饋——接受並處理各支付業務平臺的支付交易信息請求,並由風控系統將處理結果實時返回業務系統。
聯動控制——對風控系統識別出的風險信息,進行系統自動化(通過人工預置策略實現)交易風險處理。
持續迭代——交易風險特徵識別方式可以通過系統自動整理、人工設定參數、外部資源共享等方式進行持續動態更新。
統計分析——對於風控系統中存在的各類信息和數據,有關人員可以通過組合查詢和查閱報告等方式,對系統運行情況、交易風險情況、崗位績效情況等進行監督。

風控系統非功能性需求
靈活性——風控規則需要經常新增以及調整,如何降低風控規則新增、修改的成本是風控系統需要解決的一個問題。此外,風控系統需要能夠與不同業務系統進行集成,需要和業務系統保持相對的獨立,以利於集成。
性能——風控系統響應時間需要小於100ms同時能夠有很大的吞吐量,風控系統降低風險的同時不能影響用戶體驗,否則就本末倒置了。
準確性——風控系統根據風控規則會自動凍交易相關資源等,如果準確率過低會引起大面積投訴,損害公司信譽、公衆形象使用失去信心,給公司帶來巨大的損失,所以風控系統識別風險的準確率必需要有一個下限,同時要注意風險識別的準確率和覆蓋率是相互影響的兩者要達到一個可以接受的平衡。

風控系統的誤區
風控系統的目的是在不影響正常業務的同時把交易風險降低到合理的水平,風控系統並不能消滅風險,所以在建設風控系統時不可盲目追求數據的準確性以及一致性。

風控系統架構

這裏寫圖片描述

風控系統主要由以下幾個部分構成:風控實時引擎、風控準實時引擎、風控定時引擎、懲罰中心、規則中心等,下面分別進行介紹。

風控實時引擎

支付系統會把當前交易部分信息同步傳遞給風控實時引擎以獲取當前交易的風險評分和處理建議。風險評分總分爲100,分數越高風險越大,-1代表風控系統不能對當前交易進行評估風險,一般是指風控系統沒能獲取到當前交易正面或負面的信息。風控實時引擎最大的挑戰是性能,實時引擎對支付交易進行風險評估必須在100ms內完成,否則會影響用戶體驗。

風控實時引擎依據公司積累的風控數據以及第三方風控數據對進行風險評估。公司風控數據主要來自風控準實時引擎和風控定時引擎。

風控實時引擎建立在規則引擎Drools基礎上,目的是爲了提高系統的靈活性和可配置性。

下圖是風控報告的域模型:

這裏寫圖片描述

規則引擎優點

風控系統中風控規則變動比較頻繁,其它部分相對穩定,通過引入規則引擎可以解耦系統與規則、提高複雜邏輯的可維護性、提高規則的可讀性以及可理解性。

風控準實時引擎

交易欺詐行爲具備一定的隱蔽性,不是所有風險都能實時的作出正確的評估,某些情況下需要通過對最近一段時間的數據進行分析才能確定欺詐行爲,例如:對最近一個月的用戶行爲進行分析。風控準實時引擎從消息服務器獲取交易數據,對交易數據流作異步分析,分析的結果通過風控服務存入風控數據庫,供實時風控引擎評估交易風險。風控準實時引擎從發現異常到風控數據生效的時間在100ms以內,可以有效防止交易風險擴大。

風控系統初始建設時中風控準實時引擎往往是通過消息監聽器消費交易消息,把中間數據存儲在Redis緩存上,對數據進行多維度分析。由於需要針對每項指標開發相應程序,風控規則開發成本較高、上線週期長,爲了解決這個問題以及提高系統的靈活性、可配置性,在風控系統2.0版本引入了CEP引擎Esper以及規則引擎Drools。

風控準實時引擎需要使用到Drools、Esper、Esper IO AMQP、Esper Extension、Spring等組件,其中Esper Extension是我們對Esper的擴展,主要用來提高Esper可配置性以及豐富Esper IO功能以及彌補Esper缺陷。

下圖是風控準實時引擎架構:

這裏寫圖片描述

什麼是CEP

事件驅動是一種監測、分析信息流從中得出推論的方法。CEP(Complex Event Processing)也就是複雜事件驅動,是結合多種數據源的數據對信息流進行監測、分析從推理出一些複雜的事件或模式,CEP的目的是識別出一些有意義的事件,例如:機遇、威脅,並且儘可能快的作出反應。

CEP引擎已經被一些公司開發出來,用來滿足那些需要分析事件並對其作出反應的的需求,下面是一些典型的應用示例:

業務流程管理和自動化(流程監控、商業活動監控、報告異常)
金融(自動化交易、欺詐檢測、風險管理)
網絡以及應用監控(入侵檢測、SLA監測)
傳感器網絡應用(讀取RFID、生產線調度與控制)

CEP技術選型

下面列出一些CEP產品,大家可以根據自己的情況選用。
開源 CEP產品:

JBoss Drools Fusion
EsperTech Esper
Triceps

商業CEP產品:

EsperTech Esper Enterprise Edition
EsperTech EsperHA
IBM Operational Decision Manager (IBM ODM)
Oracle Stream Explorer platform
TIBCO BusinessEvents
TIBCO StreamBase
Esper優點

數據窗口機制完善

Esper目前支持大約30種數據窗口,深入理解窗口是應用Esper的關鍵,下面表格列出常用的幾種:

這裏寫圖片描述

Time Window:
這裏寫圖片描述

Length Window:

這裏寫圖片描述

Time Batch Window:

這裏寫圖片描述

EPL語句的語法與SQL相似降低學習成本

事件處理語言(EPL)是SQL標準語言並做了擴展,提供了SELECT、 FROM、 WHERE、 GROUP BY、HAVING和 ORDER BY等子句。

使用方式靈活

Esper提供了豐富的API,可以獨立部署也可以集成進任何應用。

支持多種獲取結果方式
這裏寫圖片描述

Esper缺點

Esper統計分析的中間數據全部是存儲在內存中,不能跨服務器,只能單機部署,內存有限,存在單點故障,由於全內存操作,系統重啓後中間數據就會丟失無法恢復。Esper的這些缺點風控系統都可以接受,對風控系統沒有實質的影響。

風控定時引擎

某些非常隱蔽的交易欺詐通過實時或準實時風控引擎很難發現,這些風險需要通過分析用戶跨月或跨年的數據才能識別。定時風控引擎主要用來定時對支付相關等數據進行深度挖掘,建立對應的風控模型,典型應用場景是用戶的信用等級模型以及用戶行爲分析。

定時風控引擎構建在Hadoop集羣上。

懲罰中心

懲罰中心負責積累風控數據並提供獎勵和懲罰的相關服務,風控實時引擎、風控準實時引擎、風控定時引擎會調用懲罰中心的服務查詢或保存風控數據。懲罰中心針對不同維度提供多種懲罰策略以及多種獎勵策略。風控實時引擎在識別交易風險時根據規則綜合考慮獎勵以及懲罰相關數據以提高風險識別準確率。

下圖是處罰中心域模型:

這裏寫圖片描述

風控系統的建設往往是分階段實施的,一般分爲以下三個階段:

第一階段:核心任務:

搭建基礎架構
網上應用接入
手機應用接入
建立起有效的監控團隊和工作機制

第二階段:提升性任務:
交易監控能力
風控模型提煉
監控團隊能力和工作機制

第三階段:後續發展:

持續優化
新應用接入
團隊技能是逐步積累的,對風控系統以及風控模型的理解也需要時日,如果初始建設階段求大求全會使建設工作增加不確定性,一旦出現技術或業務方向上的偏差會給公司帶來巨大的損失。循序漸進逐步建設,在前一階段的工作產生效益時再去進行下一階段的工作阻力會小很多,任何時候保持團隊對項目的控制力都是相當重要的,這是我們在建設風控系統的過程中的一點感悟。

抄襲地址:http://www.infoq.com/cn/articles/risk-management-analysis-system

發佈了49 篇原創文章 · 獲贊 52 · 訪問量 9萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章