Design of a Blockchain‑Based Financial Risk Data Sharing Alliance (Version 1.0 & 2.0)

Financial institutions collect extensive risk‑control data (blacklists, greylists, etc.) to support credit and other C‑end services, but individual data is often siloed and priced by sellers, leading to unfair pricing, high integration costs, data quality issues, and limited trust among participants.

The proposed solution is a blockchain‑based financial risk data sharing alliance that provides a fair, transparent platform for data queries, leveraging token ("points") economics to price and reward data exchanges.

Version 1.0 Design : Data is uploaded by participants, tokens are awarded based on upload volume, and queries deduct tokens. Issues identified include data security (still stored on participants' nodes), data quality (no real‑time validation before token issuance), low transaction efficiency, and regulatory constraints on token trading.

Version 2.0 Improvements :

Eliminate mandatory data upload; core data remains with owners, accessed via secure multi‑party computation.

Introduce a service system that bridges business systems and blockchain nodes, reducing integration effort and protecting interfaces.

Implement post‑query accounting on the blockchain to ensure timeliness while preserving efficiency.

Allow token overdraft with periodic settlement, enabling participants to monetize tokens within regulatory limits.

The architecture relies on Hyperledger Fabric, with two main subsystems:

BS‑F (Blockchain Service System) : Provides data read/write APIs, caches blockchain data, and acts as the bridge for participant institutions.

BU‑F (Blockchain Utility System) : Hosts the regulatory operator, handles node management, certificate issuance, and offers audit services.

Data query flow example:

A’s business system sends a query to A’s service system.

The service system forwards the request via the blockchain network to B’s service system.

B’s service system validates the request and forwards it to B’s business system.

B’s business system retrieves the data and returns it to B’s service system.

B’s service system returns the result to A’s service system, which finally delivers it to A’s business system (potentially via asynchronous messaging for multi‑target queries).

Post‑query, the queried party records the transaction on the blockchain, enabling later audit by the regulatory operator to ensure accounting accuracy.

The article concludes with a comparison of the two versions, highlighting how Version 2.0 improves data security, quality, transaction efficiency, and token circulation, and notes that the next part will detail post‑accounting and audit mechanisms.