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

Abstract Financial institutions collect risk data for credit and other services; sharing this data can improve risk control, but current query‑based pricing is dominated by data sellers. This article proposes a blockchain‑based financial‑risk‑data sharing alliance that offers a fair, transparent data‑exchange and pricing mechanism.

Business Scenario Introduction In consumer‑facing financial services, institutions need to identify fraud, identity spoofing, and other risks using black‑, gray‑, and yellow‑lists. Individual lists are insufficient, prompting a market for purchasing risk data via paid query interfaces, which gives sellers full control over pricing.

Key Pain Points

Seller‑centric pricing leads to unfair costs for buyers – solution: distributed ledger.

Multiple seller interfaces increase integration cost – solution: consortium consensus.

Risk of secondary resale of queried data – solution: privacy protection.

Lack of a public, fair accounting system for data quality – solution: smart contracts.

The root causes are the absence of a neutral intermediary and the lack of mutual trust among institutions.

Version 1.0 Design The initial design links data categories to a token called “points”. Data upload earns points recorded on a distributed ledger; data download consumes points via smart‑contract‑driven accounts. This creates a token‑based marketplace for risk data.

Issues Identified in 1.0

Data security – shared data remains stored on each participant’s nodes, reducing willingness to contribute.

Data quality – points are awarded before data validation, so low‑quality data can be tokenised.

Transaction efficiency – centralized query processing under consensus slows down operations.

Token circulation – regulatory restrictions prevent secondary market trading of blockchain‑issued tokens.

Version 2.0 Design Improvements

Data remains under the owner’s control; a service layer enables secure multi‑party computation (SMC) for blacklist checks.

Real‑time validation of queried data ensures quality.

Post‑settlement and post‑audit mechanisms keep query latency low while preserving ledger integrity.

Points are treated as prepaid credits that are cleared after a fixed period, allowing institutions to realize value without violating regulations.

Overall 2.0 Architecture A “service system” acts as a bridge between business systems and blockchain nodes, reducing integration cost, routing queries, shielding backend interfaces, and providing after‑the‑fact accounting. Data queries follow a six‑step flow: request from A’s business system → A’s service system → blockchain‑assisted routing → B’s service system → B’s business system → response back to A.

Role of the Regulator A regulated operating entity joins the consortium to manage the distributed query mechanism, provide post‑audit services, and handle off‑chain settlement based on on‑chain accounting records, without directly altering the ledger.

Technical Stack The consortium builds on Hyperledger Fabric, using two core components: BS‑F (Blockchain Service System) for data read/write and caching, and BU‑F (Blockchain Utility System) for node, certificate, and operational management. Ordering nodes maintain network configuration; endorsement nodes belong to each participant and achieve business‑level consensus.

Deployment Diagram The architecture separates ordering services, endorsement peers, the service layer, and the regulator’s operational system, illustrating how each participant interacts with the Fabric network.

The next article will detail post‑settlement and audit mechanisms and explore the complete accounting framework for the consortium.