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

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

業務場景介紹：

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

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

業務痛點如下： 

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

業務痛點主要來源于兩個原因：

一，缺乏聯盟性質的中介服務；

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

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

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

基于區塊鏈的設計方案-1.0版本

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

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

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

 

經過一段時間的試驗與論證，逐漸發現1.0版設計方案中存在一些問題： 

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

2.數據質量方面：在報送數據沒有經過業務實時驗證的前提下，對應的通證積分已經記入參與方的賬戶余額，報送數據質量沒有得到有效保證。

3.交易效率方面：所有參與機構的報送數據統一集中管理后，在聯盟共識的基礎下完成數據查詢，交易效率偏低。

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

基于區塊鏈的設計方案-2.0版本

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

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

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

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

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

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

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

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

1.A業務系統向A服務系統發起查詢請求，該請求接口兼容批量查詢，同時支持一對多的查詢；

2.A服務系統與區塊鏈節點同步機構路由地址等信息，進行查詢轉發，向B服務系統發起查詢；

3.B服務系統與區塊鏈節點同步機構狀態等信息，經過審核校驗后，向B業務系統轉發查詢請求；

4.B業務系統查詢后端數據后，返回查詢結果給B服務系統；

5.B服務系統返回查詢結果給A服務系統；

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

如上所述，數據查詢的過程已經結束，其中主要有兩點疑問：

***，為什么要添加服務系統作為數據中轉？ 

綜合來看，服務系統的設立有以下幾個目的： 

1.作為業務系統接入區塊鏈節點的橋梁，聯盟統一定制，可以降低接入成本； 

2.與區塊鏈節點共同協作完成分布式數據查詢的路由轉發；

3.為后端的業務系統提供屏蔽，保護其數據查詢接口不被公開； 

4.通過流經服務系統的查詢請求與查詢結果數據，進行基于區塊鏈的事后記賬；

第二，A向B查詢數據的過程并未關聯區塊鏈？

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

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

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

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

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

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

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

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

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

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

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

2.0版本系統架構設計

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

BS-F（區塊鏈服務系統）作為參與機構接入區塊鏈節點的橋梁，在提供數據寫入與數據讀取基本功能的同時，還會將區塊鏈數據按照區塊和交易的維度進行緩存備查。

BU-F（區塊鏈工具系統）包含了運營系統來作為監管運營方接入聯盟，此外，還包括一些運維角度的區塊鏈底層配置管理，比如節點管理，證書管理等等。

2.0版本部署架構設計

HyperLedger Fabric將節點分為排序節點和背書節點，排序節點用于維護組網配置和生成區塊，幾乎不支持動態變更；背書節點分別從屬于不同的參與機構，用來在業務層面達成共識，并且支持動態變更。運營系統作為監管角色，直接接入區塊鏈節點，而參與機構的業務系統都是通過服務系統中轉接入區塊鏈節點。

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

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

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

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

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

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

基于區塊鏈的通證積分清結算體系

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

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

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

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

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

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

總結與展望

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

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