金融機構或者企業(yè)在開展各類風控相關業(yè)務的過程中，需要收集風控數(shù)據(jù)，構建風控體系，并最終服務于相關業(yè)務場景。以信貸業(yè)務為例，基于風控數(shù)據(jù)的黑名單機制，是比較常見的一類風控措施。在開展此類業(yè)務的過程中，各家金融機構或者企業(yè)往往會產生數(shù)據(jù)共享的需求，用以提高相應的風控能力。目前金融風險數(shù)據(jù)共享的主要方式，一般通過接口查詢的方式實施，被查詢方根據(jù)查詢流量進行計價收費。

本文將討論基于區(qū)塊鏈技術，搭建金融風險數(shù)據(jù)共享聯(lián)盟，為聯(lián)盟中各個金融機構或者企業(yè)提供一個公正平等的數(shù)據(jù)互查平臺，并且推動聯(lián)盟中數(shù)據(jù)整體質量得到提高，使得聯(lián)盟成員去偽存真，優(yōu)勝劣汰。最終目標是結合區(qū)塊鏈技術對通證的生成和驗證等特性，為金融風險數(shù)據(jù)共享提供公平有效的計價和評價體系，并促進整體聯(lián)盟不斷迭代增值。

業(yè)務場景介紹：

很多金融機構在開展C端業(yè)務的時候，時常需要甄別來自于C端用戶的交易風險，身份偽造，營銷欺詐等等。 簡單舉例：營銷或者支付業(yè)務中，甄別某位個人用戶是否有過欺詐行為就屬于這一類風控識別措施。這些金融機構隨著業(yè)務的開展，往往已經(jīng)收集并沉淀積累了很多黑名單，黃名單，灰名單等。簡單來說，金融機構通過使用這些名單數(shù)據(jù)，做一些用戶過濾處理就能達到一定的業(yè)務風險控制的目標。 

業(yè)務開展過程中，金融機構或許要面臨一個顯而易見的問題：已有的黑名單數(shù)據(jù)并不足以控制業(yè)務風險，時常需要借助其他機構的名單數(shù)據(jù)進行補充，才能達到一定的業(yè)務風控效果。而基于C端用戶的風控數(shù)據(jù)，基本上都屬于金融機構的核心數(shù)據(jù)，并不能無償共享。這就衍生出了一個關于C端用戶風控數(shù)據(jù)的買賣市場。傳統(tǒng)的風控數(shù)據(jù)查詢方式，往往通過賣方機構提供一個收費的數(shù)據(jù)查詢接口的形式來實現(xiàn)。買方機構通過預付費或者后付費的方式向賣方機構支付數(shù)據(jù)查詢的相關費用。而關于費用的計價維度多種多樣，但相同之處是所有數(shù)據(jù)計價完全由數(shù)據(jù)賣方主導設定。

業(yè)務痛點如下： 

• 基本上屬于完全的賣方市場，數(shù)據(jù)的定價權和計價賬單都由賣方來制定，對買方機構而言，并不足夠公平。解決方案->分布式賬本
• 買方機構開展業(yè)務時一般需要對接多家賣方機構，每次接入都需要重新按照賣方的數(shù)據(jù)接口來開發(fā)對接，接入成本較高。解決方案->聯(lián)盟共識
• 買方機構查詢獲取的數(shù)據(jù)，可能會出現(xiàn)二次售賣的情況。解決方案->隱私保護
• 缺乏公開公平公正的賬戶體系為數(shù)據(jù)的質量負責。解決方案->智能合約

業(yè)務痛點主要來源于兩個原因：

一，缺乏聯(lián)盟性質的中介服務；

二，金融機構之間缺乏相互信任；

數(shù)據(jù)共享聯(lián)盟目前已經(jīng)有很多實踐，但是大部分效果不佳，原因還是金融機構之間缺乏信任和共識。如果采用技術的手段，建立數(shù)據(jù)共享細分領域的行業(yè)共識，將能夠極大地促進行業(yè)的發(fā)展，提高整體行業(yè)的業(yè)務風控水平。

區(qū)塊鏈技術中的聯(lián)盟鏈恰好適用于當前這樣的業(yè)務場景，能夠在聯(lián)盟參與方之間通過技術的手段達成業(yè)務共識。換言之，各家金融機構加入聯(lián)盟之后，并不需要信任聯(lián)盟組織方，也不需要信任其他聯(lián)盟參與方，只需要信任來自于底層的區(qū)塊鏈技術以及技術之上的行業(yè)約定即可。聯(lián)盟鏈的幾個重要組成部分：分布式賬本，共識機制，智能合約和隱私保護，可以為聯(lián)盟業(yè)務開展提供堅實的技術基礎。

基于區(qū)塊鏈的設計方案-1.0版本

區(qū)塊鏈中的分布式共識，是來源于整體技術架構的，而寶貴的業(yè)務共識一旦達成，需要量化和固化下來，才能清晰地表征業(yè)務狀態(tài)以及促進業(yè)務發(fā)展。通證的設定可以有效的量化共識，而分布式賬戶體系可以達到固化共識的目標。通證，即區(qū)塊鏈中通用的憑證，需要一個具體的單位來描述，這里暫且使用“積分”作為這個通證單位。

1.0版設計方案的主體思路：將數(shù)據(jù)分類后制定價格并與“積分”關聯(lián)，建立基于合約的賬戶體系，所有數(shù)據(jù)的買賣都由共識下通證“積分”流轉來實現(xiàn)。

• 數(shù)據(jù)上傳階段：各家參與機構把希望共享的數(shù)據(jù)上傳，在各個共識節(jié)點的監(jiān)督下，根據(jù)上傳數(shù)據(jù)量發(fā)放通證“積分”，并記錄在分布式賬本中。 
• 數(shù)據(jù)下載階段：各家參與機構使用自己的通證“積分”余額，在各個共識節(jié)點的審查下，查詢目標數(shù)據(jù)，并支付扣減通證“積分”。

經(jīng)過一段時間的試驗與論證，逐漸發(fā)現(xiàn)1.0版設計方案中存在一些問題： 

1.數(shù)據(jù)安全方面：共享數(shù)據(jù)仍然物理上存儲于各個參與機構的共識節(jié)點上，盡管可能采用了加密存儲的方式，仍然會導致參與機構的數(shù)據(jù)報送意愿不足。

2.數(shù)據(jù)質量方面：在報送數(shù)據(jù)沒有經(jīng)過業(yè)務實時驗證的前提下，對應的通證積分已經(jīng)記入?yún)⑴c方的賬戶余額，報送數(shù)據(jù)質量沒有得到有效保證。

3.交易效率方面：所有參與機構的報送數(shù)據(jù)統(tǒng)一集中管理后，在聯(lián)盟共識的基礎下完成數(shù)據(jù)查詢，交易效率偏低。

4.通證流轉方面：目前國家的政策法規(guī)還不允許，基于區(qū)塊鏈發(fā)行的通證，在二級市場進行買賣。導致某些參與機構可能只是數(shù)據(jù)賣方，積累了大量通證積分而無法變現(xiàn)；某些參與機構可能只是數(shù)據(jù)買方，賬戶余額中沒有通證積分，無法進行數(shù)據(jù)查詢。 

基于區(qū)塊鏈的設計方案-2.0版本

首先分析1.0版設計方案的組成要素，可以逐漸明確2.0版設計方案的改進措施：

• 聯(lián)盟鏈去中心化的設計方案，使得參與機構信任主體變成底層技術。
• 基于聯(lián)盟鏈形成分布式賬戶體系，并使用積分作為通證單位來計量數(shù)據(jù)。

數(shù)據(jù)采用報送的方式收集，換取通證積分，花銷通證積分查詢數(shù)據(jù)。

可見，1.0版設計方案最主要的問題來源在于“使用報送的方式收集數(shù)據(jù)”。各家參與機構的核心數(shù)據(jù)不會以報送的方式被獲取，即使能夠換取聯(lián)盟的通證積分，也很難促進聯(lián)盟參與機構的數(shù)據(jù)報送意愿。因此，2.0版設計方案***的改進之處在于，各家參與機構不再需要將核心數(shù)據(jù)進行報送，風控原始數(shù)據(jù)并不會匯集到區(qū)塊鏈的節(jié)點上。換言之，各家參與機構依然可以按照原有的方式保護自己的核心數(shù)據(jù)，參與到聯(lián)盟中的金融機構也間接地形成了一個核心數(shù)據(jù)的分布式存儲架構。基于如上的分析，聯(lián)盟鏈需要解決的核心問題有兩個：

一，建立基于分布式存儲數(shù)據(jù)的互查機制，或者說，在黑名單數(shù)據(jù)互查這個業(yè)務場景下，實現(xiàn)安全多方計算（SMC）。

二，借助區(qū)塊鏈分布式共識的特性，建立公開公平公正的數(shù)據(jù)計價體系。

2.0版設計方案的總體設計思路：聯(lián)盟參與機構的核心數(shù)據(jù)并不需要報送，通過添加一層“服務系統(tǒng)”來協(xié)助智能合約完成安全多方計算，合約中添加賬戶體系來為每次數(shù)據(jù)查詢進行計價服務。在數(shù)據(jù)查詢與計價服務實現(xiàn)的基礎上，同時考慮數(shù)據(jù)安全，數(shù)據(jù)質量，交易效率與通證記賬完備性問題等等。

在整體架構設計中，首先需要簡單介紹一下數(shù)據(jù)查詢的應用示例。例如，金融機構A查詢金融機構B提供的風控數(shù)據(jù)，通過如下的流程來完成： 

1.A業(yè)務系統(tǒng)向A服務系統(tǒng)發(fā)起查詢請求，該請求接口兼容批量查詢，同時支持一對多的查詢；

2.A服務系統(tǒng)與區(qū)塊鏈節(jié)點同步機構路由地址等信息，進行查詢轉發(fā)，向B服務系統(tǒng)發(fā)起查詢；

3.B服務系統(tǒng)與區(qū)塊鏈節(jié)點同步機構狀態(tài)等信息，經(jīng)過審核校驗后，向B業(yè)務系統(tǒng)轉發(fā)查詢請求；

4.B業(yè)務系統(tǒng)查詢后端數(shù)據(jù)后，返回查詢結果給B服務系統(tǒng)；

5.B服務系統(tǒng)返回查詢結果給A服務系統(tǒng)；

6.A服務系統(tǒng)收集查詢結果，（如果是一對多的查詢），使用消息隊列異步返回查詢結果給A業(yè)務系統(tǒng)； 

如上所述，數(shù)據(jù)查詢的過程已經(jīng)結束，其中主要有兩點疑問：

***，為什么要添加服務系統(tǒng)作為數(shù)據(jù)中轉？ 

綜合來看，服務系統(tǒng)的設立有以下幾個目的： 

1.作為業(yè)務系統(tǒng)接入?yún)^(qū)塊鏈節(jié)點的橋梁，聯(lián)盟統(tǒng)一定制，可以降低接入成本； 

2.與區(qū)塊鏈節(jié)點共同協(xié)作完成分布式數(shù)據(jù)查詢的路由轉發(fā)；

3.為后端的業(yè)務系統(tǒng)提供屏蔽，保護其數(shù)據(jù)查詢接口不被公開； 

4.通過流經(jīng)服務系統(tǒng)的查詢請求與查詢結果數(shù)據(jù)，進行基于區(qū)塊鏈的事后記賬；

第二，A向B查詢數(shù)據(jù)的過程并未關聯(lián)區(qū)塊鏈？

基于區(qū)塊鏈的分布式記賬交易需要考慮時效性，完備性，準確性等等因素。A向B查詢數(shù)據(jù)完成之后，記賬交易是通過事后記賬的形式完成的。設計成事后來完成記賬交易，主要是考慮了風控數(shù)據(jù)的時效性，即交易效率的考量。區(qū)塊鏈是異步確認交易的過程，如果等待異步確認交易完成后，再返回查詢結果，將會大幅降低交易效率。此外，事后記賬交易由被查詢方來完成（即上述示例中的參與機構B），這樣設計的目的是為了保證記賬交易的完備性。從博弈的角度來看，被查詢方B輸出查詢結果從而獲得通證積分，具備發(fā)起記賬的自發(fā)性和主動性。B記錄賬目的準確性，則是通過記賬完成之后的事后審計來控制。對于A查詢B并由B記錄賬目這個事件，唯一可能對賬目存在異議的只能是交易對手方A。A可以在賬目記錄完成后發(fā)起事后審計，以保證記賬交易的準確性。本文下篇會詳述事后記賬與事后審計的相關內容。

前文提到鑒于國家政策法規(guī)的限制，區(qū)塊鏈項目中產生的通證，并不允許在二級市場進行自由買賣。目前沒有國家背書的法定數(shù)字貨幣正式推出，尚無法關聯(lián)區(qū)塊鏈通證并實時結算。這種情況下，添加一個具備監(jiān)管屬性的運營參與方到聯(lián)盟鏈中，是解決通證結算問題的***方案。通過合約中限制監(jiān)管運營方的交易操作，仍然能夠保證區(qū)塊鏈分布式去中心的相關特性，使得監(jiān)管運營方只作為業(yè)務流程中某些特殊環(huán)節(jié)的輔助參與機構，并非作為中心化的權力機構。

基于以上設計思路，監(jiān)管運營方在聯(lián)盟鏈中，主要承擔如下幾個主要任務： 

1.建立健全分布式數(shù)據(jù)查詢的機制，并維護機制的正常運轉，提供聯(lián)盟運營和運維的相關服務；

2.提供事后審計服務，本文下篇將詳述其審計服務的必要性；

3.基于區(qū)塊鏈上的記賬信息，主持進行鏈外的資金清結算工作；（備注：監(jiān)管運營方無法直接干預區(qū)塊鏈原始記賬信息；）

總結對照2.0版設計方案的改進之處：

數(shù)據(jù)安全方面：各家機構無需報送數(shù)據(jù)，仍然保留數(shù)據(jù)的訪問控制權，數(shù)據(jù)安全得到保證。

數(shù)據(jù)質量方面：被查詢的數(shù)據(jù)會經(jīng)過業(yè)務流程的實時驗證，數(shù)據(jù)質量通過反饋機制可以得到有效控制。

交易效率方面：由于采用了事后記賬與事后審計的機制，數(shù)據(jù)查詢的效率并沒有被分布式架構所影響。

通證流轉方面：積分采用透支的方式獲取，固定期限后進行積分軋差清零，參與機構可以及時變現(xiàn)。

2.0版本系統(tǒng)架構設計

區(qū)塊鏈底層框架，仍然沿用了金融機構目前廣泛接受的超級賬本開源項目HyperLedger Fabric。如前文所述，智能合約中主要包括兩部分內容：分布式數(shù)據(jù)互查機制和公開公平公正的數(shù)據(jù)計價體系。 

BS-F（區(qū)塊鏈服務系統(tǒng)）作為參與機構接入?yún)^(qū)塊鏈節(jié)點的橋梁，在提供數(shù)據(jù)寫入與數(shù)據(jù)讀取基本功能的同時，還會將區(qū)塊鏈數(shù)據(jù)按照區(qū)塊和交易的維度進行緩存?zhèn)洳椤?/p>

BU-F（區(qū)塊鏈工具系統(tǒng)）包含了運營系統(tǒng)來作為監(jiān)管運營方接入聯(lián)盟，此外，還包括一些運維角度的區(qū)塊鏈底層配置管理，比如節(jié)點管理，證書管理等等。

2.0版本部署架構設計

HyperLedger Fabric將節(jié)點分為排序節(jié)點和背書節(jié)點，排序節(jié)點用于維護組網(wǎng)配置和生成區(qū)塊，幾乎不支持動態(tài)變更；背書節(jié)點分別從屬于不同的參與機構，用來在業(yè)務層面達成共識，并且支持動態(tài)變更。運營系統(tǒng)作為監(jiān)管角色，直接接入?yún)^(qū)塊鏈節(jié)點，而參與機構的業(yè)務系統(tǒng)都是通過服務系統(tǒng)中轉接入?yún)^(qū)塊鏈節(jié)點。

非對稱信息博弈的***契約-事后記賬與事后審計

如本文上篇所述，事后記賬由被查詢方來完成，那么記錄的賬目信息中都包含哪些內容呢？ 簡單來說，可以描述成，誰查詢了誰，查詢了哪些數(shù)據(jù)，這些數(shù)據(jù)會導致通證積分余額產生什么樣的變化。 詳細來說，賬目信息會以鍵值對的方式記錄到區(qū)塊鏈節(jié)點中。

Key值包括查詢方與被查詢方，以及查詢方擬定的唯一序列號組成（由查詢方擬定序列號，主要考慮到被查詢方記錄賬目以及雙方存在博弈關系）。此外，記賬信息Key值中還包含了分期信息，后文將詳述分期信息的必要性。

Value值中主要包括查詢請求與查詢結果，還有根據(jù)查詢請求和查詢結果生成的通證積分結轉信息。查詢請求和查詢結果信息并不能直接作為賬目信息發(fā)往區(qū)塊鏈的背書節(jié)點。 本文上篇的部署架構中明確了背書節(jié)點分別從屬于不同的參與機構，如果直接發(fā)送原始數(shù)據(jù)，會有數(shù)據(jù)安全的隱患存在。Fabric1.2版本中添加了節(jié)點私有數(shù)據(jù)庫sideDB，用于處理此類隱私數(shù)據(jù)的安全隱患問題，但仍然存在一些交易效率的相關問題。所以實施方案中，會把原始數(shù)據(jù)的摘要信息以及對摘要信息的簽名作為記錄賬目的組成部分。摘要信息證明了原始數(shù)據(jù)的存在，而簽名則證明了原始數(shù)據(jù)的來源。這兩項數(shù)據(jù)可以有效證明查詢請求與查詢結果的合法性，并且原始數(shù)據(jù)不會以任何形式暴露給背書節(jié)點。

記賬信息通過交易的形式發(fā)往區(qū)塊鏈背書節(jié)點，背書節(jié)點通過合約校驗記賬交易的合法性，包括簽名是否正確，積分結轉是否合理等等。唯一無法校驗的環(huán)節(jié)在于，原始數(shù)據(jù)與摘要數(shù)據(jù)的一致性。對于查詢方來說，對于被查詢方的記賬交易，唯一需要質疑的內容，也是原始數(shù)據(jù)與摘要數(shù)據(jù)的一致性問題。原始數(shù)據(jù)基于安全性考慮，無法傳遞到區(qū)塊鏈背書節(jié)點，公布給所有參與機構見證。 但是，查詢方對于賬目信息存在疑慮的時候，可以在鏈外向監(jiān)管運營系統(tǒng)發(fā)起審計操作。

事后審計是監(jiān)管運營系統(tǒng)自動執(zhí)行的相關業(yè)務流程，不需要人工干預。系統(tǒng)會讀取原始數(shù)據(jù)與鏈上數(shù)據(jù)，按照固定的處理流程進行對比，最終裁定該筆審計操作是否被認可。一旦查詢方獲取到監(jiān)管運營系統(tǒng)給予的審計背書（包含監(jiān)管運營系統(tǒng)的簽名），就可以發(fā)起一筆沖正交易，將對應的記賬信息置為無效。這個過程也就是記賬交易完成之后的審計流程，簡稱事后審計。需要特別指出的是，并不是每筆記賬交易都需要進行事后審計，只有那些查詢方質疑的交易才會由查詢方發(fā)起審計校驗，而審計校驗的成本是向監(jiān)管運營系統(tǒng)公布原始數(shù)據(jù)。

基于區(qū)塊鏈的通證積分清結算體系

探討通證積分清結算體系之前，簡要介紹一些預先設定，聯(lián)盟鏈參與機構的初始積分都是零，使用透支的方式來花銷積分，并設置積分透支的軟上限。透支軟上限的監(jiān)測以及調控，都是通過監(jiān)管運營系統(tǒng)來統(tǒng)一管理。所有參與機構的積分余額，在固定期限（比如一個月），由監(jiān)管運營系統(tǒng)根據(jù)鏈上的快照數(shù)據(jù)來進行鏈外的資金結算。舉例來說，鏈上的每家機構的積分余額，可能為正也可能為負，在鏈下進行資金兌付后，積分余額將被清零。 

深入探討積分清結算體系內的幾類交易： 

• 積分記賬交易：由參與機構發(fā)起交易。由于區(qū)塊鏈是異步確認交易的過程，每個區(qū)塊中包含的交易會在區(qū)塊生成后進行再次校驗。同一個區(qū)塊中的多筆交易可能改變了同樣的讀寫集合，就會導致交易無效的發(fā)生。如下圖，區(qū)塊0中，A查B，B查C，如果兩筆交易都讀取了B的余額，至少會造成B查C交易無效。為了提高交易的有效性，所有的記賬交易并不會讀取并改變每家機構的積分余額，只是記錄賬目的發(fā)生（誰查詢了誰，查詢數(shù)據(jù)是什么，待清算積分是多少）。
• 積分沖正交易：由參與機構發(fā)起交易。沖正交易來源于事后審計，但是需要考慮時限性問題。如果記賬交易已經(jīng)完成鏈下的資金結算，將無法回滾交易并執(zhí)行沖正操作。所以，沖正交易發(fā)起時限為當期積分快照交易完成前。
• 積分清算交易：由監(jiān)管運營系統(tǒng)發(fā)起交易。主要有兩個功能，首先是匯總記賬交易產生的積分余額變更，其次是監(jiān)管運營系統(tǒng)監(jiān)測聯(lián)盟參與機構的透支額度是否已經(jīng)被突破。積分清算交易同樣面臨交易有效性問題，如果該交易不是某個區(qū)塊的***一筆交易，則一定會造成交易無效。因為積分清算交易依賴于積分記賬交易，在積分清算交易提交后再次發(fā)生積分記賬交易，一定會導致積分清算交易無效。為了解決這個問題，適時引入了積分改期交易。
• 積分改期交易：由監(jiān)管運營系統(tǒng)發(fā)起交易。將所有的記賬交易，分為若干記賬周期。例如，每日零點發(fā)起積分改期交易，開啟一個新的記賬周期。這樣使得積分記賬交易依賴于積分改期交易，而積分改期交易一定是有效交易。積分改期交易完成之后，積分清算交易無論何時進行，同樣也變成有效交易了。
• 積分快照交易：由監(jiān)管運營系統(tǒng)發(fā)起交易。積分快照交易將匯總多個積分清算交易產生的積分余額變更，為鏈外資金結算提供鏈上積分快照數(shù)據(jù)參照。積分清算交易周期可以被監(jiān)管運營系統(tǒng)靈活調整，但積分快照交易周期則需要與鏈外資金結算周期保持同步。

項目可擴展性-機構接入成本

聯(lián)盟鏈項目的機構接入成本主要體現(xiàn)在組網(wǎng)配置中，本文暫不討論此類問題。從業(yè)務開展角度來看，新機構加入聯(lián)盟鏈，需要首先進行接口改造，主要包括數(shù)據(jù)查詢與數(shù)據(jù)提供兩個接口；然后部署區(qū)塊鏈服務系統(tǒng)，服務系統(tǒng)將由聯(lián)盟提供統(tǒng)一定制藍本；***部署從屬于該機構的區(qū)塊鏈背書節(jié)點，承載智能合約，校驗各類交易的有效性。

根據(jù)聯(lián)盟整體運行性能要求，服務系統(tǒng)的部署環(huán)境會有***配置要求，而參與機構的業(yè)務系統(tǒng)接口也需要達到一定的***并發(fā)要求。此外，為了提高節(jié)點運行性能，參與機構背書節(jié)點可以采用讀寫分離的部署策略等等，不再逐一詳述。新機構接入流程，首先在測試環(huán)境進行演練，之后將移植到生產環(huán)境。

總結與展望

綜合前文所述，基于聯(lián)盟鏈的架構，設計實施了金融風險數(shù)據(jù)共享的解決方案。目前該方案僅提供了數(shù)據(jù)的計價能力，仍然欠缺數(shù)據(jù)的評價能力。完善數(shù)據(jù)的評價能力可以通過使用權益積分來實現(xiàn)，仍處于探索階段。

區(qū)塊鏈從問世之初，就不僅僅是一種分布式數(shù)據(jù)庫，不應該只被用來完成上鏈記賬操作。或者說，區(qū)塊鏈不僅僅是一項技術，而是結合了經(jīng)濟學，社會學，密碼學，博弈論等等內容的綜合體。在一個熵增（不確定性逐步增長）的環(huán)境下達成共識，形成制度博弈，最終優(yōu)勝劣汰，良幣驅逐劣幣，達到某個細分領域內的行業(yè)自治才是區(qū)塊鏈能夠帶來的最終改變。