支付風控系統(tǒng)設(shè)計:風控數(shù)據(jù)倉庫建設(shè)(二)

10 評論 42541 瀏覽 236 收藏 25 分鐘

這篇文章是支付風控系統(tǒng)設(shè)計的第二篇,重點介紹支持支付風控的數(shù)據(jù)倉庫建設(shè)。關(guān)于支付系統(tǒng)在風控上的具體需求,可參見上一篇文章 《支付風控場景分析》。

支付風控系統(tǒng)在數(shù)據(jù)存儲設(shè)計上和其它業(yè)務(wù)不同的地方在于數(shù)據(jù)獲取與使用的流程。一般業(yè)務(wù)系統(tǒng)會先確定系統(tǒng)數(shù)據(jù)需求,再設(shè)計如何在業(yè)務(wù)流程中采集數(shù)據(jù),以及數(shù)據(jù)的格式怎么定義。而支付風控面臨的是一個無法預(yù)知的場景,需要在實踐中根據(jù)當前運行情況不斷調(diào)整。它會先把數(shù)據(jù)采集過來,之后才能從中發(fā)現(xiàn)可能存在的問題,并針對該問題制訂風控規(guī)則。也就是風控是先采集數(shù)據(jù),再使用數(shù)據(jù)。

風控分析不僅要看交易數(shù)據(jù),還得研究所有相關(guān)聯(lián)的數(shù)據(jù),這才能全面分析出來風險的根源,推斷出需要采取的措施。因而數(shù)據(jù)采集工作對風控系統(tǒng)建設(shè)和演化是非常重要的。本文分析風控所需要的數(shù)據(jù),如何采集和存儲數(shù)據(jù),建立支持風控的數(shù)據(jù)倉庫。

一、數(shù)據(jù)來源

一筆交易的風險等級的計算需要考慮到多個維度。未成年人購買高檔酒、促銷期間羊毛客刷單、在洗錢高發(fā)地區(qū)的商戶銷售的物品成交價格遠超實際價格。這些可疑交易的識別,僅依靠支付系統(tǒng)本身是無法完成的。用戶的年齡、商品特點(是否高檔酒)、是否促銷、羊毛號的識別等,需要從各業(yè)務(wù)系統(tǒng),甚至公司外部收集和用戶、商品、商家、地區(qū)、手機號相關(guān)的數(shù)據(jù),通過對這些數(shù)據(jù)進行分析,提取特征,識別潛在的風險。

1. 內(nèi)部數(shù)據(jù)

風控幾乎需要收集所有相關(guān)系統(tǒng)的數(shù)據(jù)。 用戶系統(tǒng)需采集用戶的靜態(tài)信息,姓名、性別、年齡等。風控系統(tǒng)不僅僅關(guān)注這些靜態(tài)信息,還需要重點關(guān)注用戶的行為信息,包括注冊、密碼修改、修改個人信息等操作,需要收集這些操作的時間、地點、設(shè)備等信息。 此外,用戶之間的關(guān)系,也是風控系統(tǒng)需要關(guān)注的數(shù)據(jù)。

  • 商戶系統(tǒng):除了采集機構(gòu)的基本信息,如成立時間、注冊時間、人員規(guī)模、營業(yè)額、銷售額、經(jīng)營范圍、注冊地點等, 還需要考慮到該商戶關(guān)聯(lián)的用戶,包括法人代表、公司組織結(jié)構(gòu)、主要員工信息等。
  • 商品系統(tǒng):商品的靜態(tài)信息,包括類型、價格、上架時間、庫存等信息; 商品的瀏覽、放入購物車、購買、評論、退貨等用戶操作,包括這些操作的時間、地點、設(shè)備等信息。
  • 社交數(shù)據(jù),包括評論、論壇、留言等。
  • 業(yè)務(wù)系統(tǒng),如視頻系統(tǒng)中的觀影記錄、類型偏好、時間、地點、設(shè)備等信息。

當然,支付數(shù)據(jù)是風控最重要基礎(chǔ)數(shù)據(jù)。用戶在支付系統(tǒng)中涉及到的數(shù)據(jù)都需要收集整理來支持風控分析。包括但不限于賬戶數(shù)據(jù)、訂單數(shù)據(jù)、交易數(shù)據(jù)、優(yōu)惠券數(shù)據(jù)和賬務(wù)流水等。這些數(shù)據(jù)在支付數(shù)據(jù)庫中也存在,風控所需要的數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)略有不同。除了業(yè)務(wù)數(shù)據(jù)外,風控還關(guān)心如下數(shù)據(jù):

  • 用戶當前上下文環(huán)境,包括用戶所用設(shè)備的類型、操作系統(tǒng)、IP地址、設(shè)備ID、所在地等,而這些數(shù)據(jù)往往并不是業(yè)務(wù)所關(guān)心的。而且記錄太多的上下文數(shù)據(jù)也影響性能。
  • 賬戶,訂單等操作實體的狀態(tài)。在業(yè)務(wù)數(shù)據(jù)庫中一般僅保留實體的最終狀態(tài),比如賬戶是否已鎖定、訂單是否已支付等。 而風控需要關(guān)心這些狀態(tài)變更的時機,以及變更的時間間隔。例如,用戶頻繁更改交易密碼,超正常頻率提交訂單等,就不是一個正常的狀態(tài)。

這些數(shù)據(jù)一般可以從日志中采集。

2. 外部數(shù)據(jù)

對于大部分業(yè)務(wù)單一和用戶量不大的公司來說,其數(shù)據(jù)有限而且單一,需要使用外部數(shù)據(jù)來輔助完成風控計算。

常用的外部數(shù)據(jù)包括:

  • 公安部的實名認證數(shù)據(jù),包括用戶姓名、身份證號信息;
  • 央行發(fā)布的各種名單,如洗錢區(qū)域,恐怖組織名單等。
  • 央行信用報告,這個查詢可是要真金白銀的。
  • 微博數(shù)據(jù),一個人經(jīng)常了解如何養(yǎng)卡,套現(xiàn)等內(nèi)容并不是太好的事情。
  • 工商局提供的公司信息。
  • 招聘網(wǎng)站上的公司招聘信息。公司一直有招聘說明業(yè)務(wù)還不錯。
  • 芝麻信用,這個需要申請。

二、采集方式

一般來說,風控的非實時數(shù)據(jù)采集,不能直接從線上的數(shù)據(jù)庫中讀取,這會把數(shù)據(jù)庫打死。主要的數(shù)據(jù)采集方式有從庫采集,日志采集和pingback三種方式。

1. 數(shù)據(jù)庫從庫

主流數(shù)據(jù)庫,如Hbase,Mysql都提供同步數(shù)據(jù)進從庫的功能,讀取從庫不會影響主庫操作。但如上所述,采用從庫有如下問題:

  • 分析所需數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)不同,還需要從其他途徑補充數(shù)據(jù)。
  • 將風控所需數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)緊耦合起來了。一旦業(yè)務(wù)有變更,風控系統(tǒng)也需要調(diào)整。

2.?日志

這是風控數(shù)據(jù)采集的主要方式。 業(yè)務(wù)方可以將風控所需要的數(shù)據(jù)輸出到日志中,風控系統(tǒng)對接日志來異步采集數(shù)據(jù)。這使得數(shù)據(jù)采集不會影響業(yè)務(wù)處理主流程。 這種方式風險在于:

  • 需要規(guī)范日志的格式,否則每個系統(tǒng)一套日志格式,會導(dǎo)致對接工作量巨大。
  • 保持日志的穩(wěn)定性。一旦代碼被修改,打印日志的代碼被刪除了,會導(dǎo)致日志數(shù)據(jù)無法采集的風險。
  • 需要注意日志采集系統(tǒng)的可靠性。目前主流的采集框架都有可能會丟失日志。雖然從我們使用的情況來還未發(fā)生這種事情,但不排除這個風險。

從技術(shù)上來說,日志采集的框架主要框架有

  • ELK(Elastic + Logstash + Kibana), Logstash 駐留在日志輸出端采集日志,并發(fā)送到Elastic 服務(wù)器上。 Kibana則是一個日志分析的工具;
  • Flume + Kafka + Elastic 。 通過Flume進行采集,輸出到Kafka,匯總到Elastic進行存儲。日志分析可以在Elastic上離線非實時進行,也可以直接對接Kafka準實時分析,即流處理。 使用Storm 或者Spark都可以。

3.?pingback

Pingback指在頁面上埋入腳本來監(jiān)測用戶的操作,特別是點擊操作和鍵盤操作,將檢測到的用戶行為異步發(fā)送到服務(wù)器端。這可以偵測到用戶在頁面停留時間,鼠標點擊的區(qū)域等信息,由此可以推斷用戶偏好,情緒等信息。 pingback的挑戰(zhàn)在于如何在服務(wù)器端應(yīng)對流量洪峰。pingback數(shù)據(jù)一般不直接入庫,可以先寫入Kafka,風控系統(tǒng)對接Kafka來分析pingback數(shù)據(jù)。

三、數(shù)據(jù)特征

用于支持風控計算的最終數(shù)據(jù),在靜態(tài)與動態(tài)數(shù)據(jù)為基礎(chǔ)計算出來的帶置信度的推算數(shù)據(jù)為主的離散數(shù)據(jù),有點繞口,我們詳細分析下這里涉及到的幾個概念,來說明最終用來支持風控計算的數(shù)據(jù)有什么特征。

1.?靜態(tài)數(shù)據(jù)與動態(tài)數(shù)據(jù)

上述采集到的數(shù)據(jù),大部分是靜態(tài)數(shù)據(jù)。也就是這些數(shù)據(jù)一旦產(chǎn)生,一般不會被修改。但在分析時,還需要一些易變的動態(tài)數(shù)據(jù)來,比如用戶的 年齡,每天的訪問量,每天消費金額等。

2.?原始數(shù)據(jù)與推算數(shù)據(jù)

不管靜態(tài)還是動態(tài)數(shù)據(jù),他們都是從用戶輸入或者系統(tǒng)采集的方式產(chǎn)生。但我們知道,互聯(lián)網(wǎng)的數(shù)據(jù)可靠性是有問題的。網(wǎng)上千嬌百媚的姑娘,在現(xiàn)實中可能是一位摳腳大漢。雖然系統(tǒng)中設(shè)計了復(fù)雜的表格來收集用戶信息,但會提供全部信息的用戶還是很少,大家對隱私內(nèi)容還是捂得很緊。

所以,在進行風險計算前,還需要對數(shù)據(jù)進行驗證和補充。這都需要借助其他數(shù)據(jù)來進行推算,這些數(shù)據(jù)被稱為推算數(shù)據(jù)。推算數(shù)據(jù)和原始數(shù)據(jù)不同之處在于它會有多個可能取值,每個值都帶有置信度。完全可信為100%,不可信為0。置信度總和為1。比如正常情況下,用戶的性別要么男,要么女。假如有個用戶注冊時選擇性別女,但經(jīng)常買刮胡刀,襯衣,沒有買過女性用品,那實際性別為男的置信度就非常高。

3.?離散數(shù)據(jù)與連續(xù)數(shù)據(jù)

這是從屬性值的取值范圍來評估。比如用戶每天的訂單額,一般來說是連續(xù)分布的。而性別,職業(yè),愛好等,是離散值。一般來說,離散值更容易做分析處理,刻畫特征,所以在分析前,需要對連續(xù)數(shù)值做離散化處理。

四、名單數(shù)據(jù)

名單數(shù)據(jù)是支付風控數(shù)據(jù)倉庫中最重要的內(nèi)容。 風控系統(tǒng)數(shù)據(jù)倉庫建設(shè),也一般都從名單數(shù)據(jù)開始。 名單加上簡單的攔截規(guī)則,已經(jīng)可以解決絕大部分風控的問題。就算在更先進的風控系統(tǒng)中,名單仍然是風控中的基礎(chǔ)數(shù)據(jù)。在評估事件風險時,名單往往是用來執(zhí)行第一道攔截時所用的數(shù)據(jù)。比如用戶交易時使用的手機是黑名單中的手機,則必須終止本次交易。

1. 黑白灰名單

大家都熟知黑名單與白名單,一個是必須阻止,一個是必須放行。 除此之外,還有灰名單?;颐麊斡糜趯σ恍└唢L險的用戶進行監(jiān)控。 這些用戶的行為不是直接阻止,而是延遲交易,經(jīng)人工確認無問題后再放行。

2. 更新周期

相對其它數(shù)據(jù)來說,名單數(shù)據(jù)的更新頻率不高,按天、周、月更新都有,很少有需要實時更新的內(nèi)容。對于手機號,證件號等名單,一般可以采取人工更新的策略。每天評估風控數(shù)據(jù),對確認有問題的號碼,加入到黑名單中。如果采用的是第三方名單,則需要按照第三方的要求對名單做更新。

3.?名單列表

一般來說,風控系統(tǒng)需要配置的名單列表有:

(1)個人名單

如下名單是必備的(后續(xù)會及時更新):

(2)IP名單

沒有權(quán)威的IP名單。這需要在運行中積累。建立IP名單需要注意如下事項:公司內(nèi)部IP,合作伙伴IP可以列入白名單列表;手機運營商的IP也要做到白名單中,封一個IP等于封掉一大批手機號;代理服務(wù)器可以列入灰名單;訪問量大的IP也可能大公司的外網(wǎng)IP,不能僅依賴訪問量來識別黑IP。

(3)公司名單

必備名單包括央行反洗錢制裁公司名單和工商局失信企業(yè)名單

(4)手機號名單

這也沒有權(quán)威數(shù)據(jù),電信運營商也不會提供此類服務(wù)。支付寶正在推廣這個服務(wù),但還沒有公開。黑名單數(shù)據(jù)需要自主收集。

(5)地域名單

央行公布的聯(lián)合國反洗錢地區(qū)名單是必須在風控時考慮的名單,其他地域名單也需要自主收集。

(6)協(xié)查名單

公檢法協(xié)查名單,接收到協(xié)查請求后,將人員全部信息拉黑。

4. 名單數(shù)據(jù)存儲

名單數(shù)據(jù)在使用上的特點:

  • 使用頻率高,實時性要求高。各種名單匹配基本都需要在線上做實時計算。
  • 數(shù)據(jù)粒度小,總量大小不一,但存儲空間需求都不高。大部分名單都是一些號碼表,幾個G的空間都能存儲。
  • 更新頻率低。名單數(shù)據(jù)一般都比較穩(wěn)定,按天更新

在使用中,名單數(shù)據(jù)一般直接存儲在內(nèi)存中,或者使用內(nèi)存數(shù)據(jù)庫(Redis,Couchbase)。關(guān)系型數(shù)據(jù)庫可以用來保存名單數(shù)據(jù),但不會直接被線上應(yīng)用所訪問,它無法滿足高訪問量的需求。

五、畫像數(shù)據(jù)

名單數(shù)據(jù)能夠快速發(fā)現(xiàn)用戶在某個維度上的異常行為。在實際使用中,存在過于簡單粗暴,一刀切的問題。比如如果限制單次購買金額為5000元,這個規(guī)則被試探出來后,攻擊者會選擇4999元來規(guī)避這個限制。畫像技術(shù)則是嘗試從多個維度來評估當前事件的風險。 比如畫像刻畫某用戶平時主要在北京地區(qū)登錄,購買習慣在10~300元之間。某一天突然發(fā)生一筆在東莞的4999元額度的消費,那這筆交易就非常可疑了。而這種交易通過規(guī)則比較難發(fā)現(xiàn)出來。 支付風控涉及的畫像包括用戶、設(shè)備、商品、地域、操作行為等。 這里重點介紹用戶、設(shè)備和商品的畫像。

1.?用戶畫像(persona)

用戶畫像是從用戶的角度來刻畫其背景和行為習慣,為判定某交易的風險等級提供支持。 用戶畫像的內(nèi)容包括但不限于:

  • 人口信息:一般就叫基本信息,主要包括:姓名、性別、出生日期、出生地、民族、星座等。
  • 聯(lián)系方式:家庭地址、工作地址、手機、固定電話、緊急聯(lián)系人、QQ、微信號等。
  • 資產(chǎn)特征:月工資、年收入、工資外收入、房產(chǎn)、車等
  • 家庭特征:婚姻狀況、是否有小孩、小孩關(guān)聯(lián)、家庭成員等
  • 交易偏好:交易頻率(總計、年、月、日)、交易金額(總計、年、月、日)、常用賬戶、交易時間偏好、交易地點偏好、交易所使用設(shè)備、交易物品、交易物品所屬類別等。
  • 行為特征,這是和業(yè)務(wù)相關(guān)的特征。比如對于電商,關(guān)注 用戶瀏覽的物品、瀏覽的物品類別、購買的物品等。而對于視頻網(wǎng)站,則關(guān)注用戶查看的視頻、觀影時長、類別偏好、觀影地點偏好等信息。

對于已登錄用戶,可以使用用戶ID來識別并做畫像,但對未登錄用戶,系統(tǒng)需要通過設(shè)備來識別。

2.?設(shè)備畫像

一個用戶配備多臺智能設(shè)備已經(jīng)是很常見的事情了。手機,PAD,筆記本,臺式機,都是常用的設(shè)備。用戶在不同的設(shè)備上的行為往往是不一樣的。有人偏好在電腦上尋找要購買的商品,卻最終使用手機來下單,因為手機支付更便捷。 對設(shè)備進行畫像,和用戶畫像類似,實際上是刻畫使用設(shè)備的用戶的特征。 此外,對于未登錄用戶,由于無法標識,也只能通過設(shè)備來代表這個用戶。設(shè)備畫像關(guān)注如下信息:

  • 設(shè)備信息,包括設(shè)備類型、型號、屏幕大小、內(nèi)存大小、CPU類型、購買時間、購買時價格、現(xiàn)在價格等。
  • 交易偏好,同用戶畫像;
  • 行為特征,同用戶畫像。

對設(shè)備畫像來說,生成一個能唯一識別該設(shè)備的標識,即設(shè)備指紋,是數(shù)據(jù)采集中的一個挑戰(zhàn)。設(shè)備指紋具有如下特點

  • 唯一性,每臺機器的指紋都不同,不能重復(fù)。
  • 一致性,機器指紋在一臺機器上是唯一的,不同應(yīng)用,不同登錄用戶中取到的指紋都是一樣的。
  • 穩(wěn)定性,指紋不會隨時間變更,不會由于外圍設(shè)備變更而變更。重裝應(yīng)用,重裝操作系統(tǒng)也應(yīng)該保持不變。

我們將在專門的主題中介紹如何生成設(shè)備指紋。

3.?商品畫像

商品畫像是從商品的角度來刻畫購買或者擁有該商品的人的特性。

  • 基本特征:名稱,價格,類別,是否虛擬資產(chǎn),上架時間,下架時間等
  • 促銷信息:價格,開始時間,截止時間
  • 購買者特征:偏離這個特征越多,風險越大。購買時間分布,地點分布,價格分布,數(shù)量分布,年齡分布,性別分布等。

4.?畫像數(shù)據(jù)存儲

畫像數(shù)據(jù)有如下特點:

  • 數(shù)據(jù)粒度大。一個用戶的畫像數(shù)據(jù),成百上千個維度都正常。
  • 大部分數(shù)據(jù)都是推算數(shù)據(jù),也就是數(shù)據(jù)格式是帶置信度的,比如 {性別: 男,80%;女,20%};
  • 每個維度的數(shù)據(jù)一般最終都需要離散化,比如年齡,雖然0~150的取值區(qū)間還不算稀疏,一般還會將年齡再分段。
  • 數(shù)據(jù)量大。考慮到匿名用戶和設(shè)備,上千萬規(guī)模的注冊用戶,匿名用戶和設(shè)備會在數(shù)十億規(guī)模的量級。
  • 數(shù)據(jù)結(jié)構(gòu)不穩(wěn)定。 根據(jù)業(yè)務(wù)需要會頻繁添加新的數(shù)據(jù)維度,甚至添加新實體進來。
  • 數(shù)據(jù)更新頻繁。采用推算數(shù)據(jù),每天不僅僅要計算新增數(shù)據(jù),也需要重新計算現(xiàn)有數(shù)據(jù)的維度權(quán)重。
  • 數(shù)據(jù)訪問頻率高。交易時計算權(quán)重,也需要使用畫像數(shù)據(jù)。

很難有一個數(shù)據(jù)庫能夠同時滿足上述的需求。畫像數(shù)據(jù)存儲需要綜合采用多種數(shù)據(jù)庫來滿足不同應(yīng)用上的需求。

  • 數(shù)據(jù)寫入庫, 需要支持數(shù)據(jù)批量、快速地寫入,Hbase是個不錯的選擇。
  • 數(shù)據(jù)讀取庫,需要支持數(shù)據(jù)高速讀取, couchbase可以滿足這個需求。但couchbase不能存儲所有數(shù)據(jù),這樣成本太高。 可以把couchbase作為HBase的緩存來使用。
  • 寫庫和讀庫之間的數(shù)據(jù)同步。可以根據(jù)業(yè)務(wù)量選取合適的消息隊列。每天更新的數(shù)據(jù)規(guī)模在百萬及其以下,ActiveMQ可以滿足需求;而上千萬的數(shù)據(jù),則需要使用Kafka。

六、知識圖譜

畫像是從群體和個體的統(tǒng)計角度評估事件的風險,而圖譜則更進一步,從關(guān)系的角度來評估風險。 知識圖譜是由Google提出來并應(yīng)用到搜索引擎上,其后在多個領(lǐng)域都得到很好的應(yīng)用。 交易是一種社會行為,所以從關(guān)系的角度來評估這個行為,能夠更精確的了解行為中存在的風險。一個簡單的例子,如果發(fā)現(xiàn)A是高風險的用戶,而通過社交圖譜分析,發(fā)現(xiàn)A經(jīng)常和B有交易關(guān)系, 那B的風險等級也相應(yīng)地會被調(diào)高。

圖譜在本質(zhì)上是一個語義網(wǎng)絡(luò), 是一種基于圖的數(shù)據(jù)結(jié)構(gòu), 它由點和邊組成的。點代表一個實體,如人、公司、電話、商品、地址等,邊代表實體之間的關(guān)系。

knowledgegraph

如上所示, 如果A和B兩人之間是夫妻關(guān)系, 則在圖中, A和B分別被用一個節(jié)點來標識, 稱為實體,他們的關(guān)系是 is_wife_of。對電話、出生日期、出生地點、公司等,也可以使用這種方式來表示。 圖譜的表達能力,不僅在于描述實體之間的關(guān)系,而且通過關(guān)系還可以推理出潛在的進一步關(guān)系。 比如A是B的母親, A是C的妻子, 則有很大的概率可以推斷出來C是B的父親。 支付風控需要像建立畫像一樣建立圖譜,需要支持包括人,機構(gòu),地區(qū),日期,電話,手機號,設(shè)備,商品等實體,以及實體之間的關(guān)系。圖譜數(shù)據(jù)源也是和畫像一樣。此外,還有一些互聯(lián)網(wǎng)數(shù)據(jù)也有利于建立圖譜 百度百科,有很不錯的公司,明星,電影,音樂等信息,一般僅限于國內(nèi)或者中文版本的資料。由于編審并不嚴謹,數(shù)據(jù)質(zhì)量不高。 wiki,有各種語言的版本,提供各種領(lǐng)域的實體,參與的專業(yè)人士多,質(zhì)量較高。 各專業(yè)數(shù)據(jù)庫,

知識圖譜是基于圖的數(shù)據(jù)結(jié)構(gòu),它的存儲主要是使用圖數(shù)據(jù)庫。關(guān)系型數(shù)據(jù)庫和Hbase等nosql數(shù)據(jù)庫在處理圖的關(guān)系以及關(guān)系計算上性能較差,需要專用的圖數(shù)據(jù)庫,當前主要的圖數(shù)據(jù)庫有neo4j,Titan,Jena等。neo4j是使用最多的圖數(shù)據(jù)庫,而且可以和spark graph集成,方便對圖譜數(shù)據(jù)做處理。

七、總結(jié)

總結(jié)一下,本文將風控系統(tǒng)所需要的數(shù)據(jù)分為名單、畫像和圖譜三個主題,這三個主題也對應(yīng)了風控系統(tǒng)發(fā)展的不同的階段。這里列出了每個階段所需要的典型數(shù)據(jù),以及這些數(shù)據(jù)會如何存儲。風控系統(tǒng)會如何使用這些數(shù)據(jù),將下一篇博文中分享。

系列文章

支付風控系統(tǒng)設(shè)計:支付風控場景分析(一)

 

作者:鳳凰牌老熊,程序員 & 架構(gòu)師

本文由@鳳凰牌老熊(微信公眾號:shamphone) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理 。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 寫得真好,很全面,受益匪淺

    來自福建 回復(fù)
  2. 大佬,鳳尾(支付風控之三、四)呢?

    來自上海 回復(fù)
  3. 大師

    來自上海 回復(fù)
  4. 好文章 ??

    來自四川 回復(fù)
  5. 謝謝老師

    來自廣東 回復(fù)
  6. 長見識了,期待后續(xù)文章??

    回復(fù)
  7. 期待大神的其它兩篇風控系統(tǒng)文章~~~~~ ??

    來自上海 回復(fù)
  8. 大神還有其它兩篇文章什么時候發(fā)呢,期待中……

    回復(fù)
  9. 很全面,很受教

    回復(fù)