Design and Implementation of a Blockchain-Based Financial Risk Data Sharing and Token Settlement System

Financial institutions and enterprises that conduct risk‑control activities need to collect risk data, build risk‑control systems, and serve related business scenarios; for example, credit‑risk blacklists are common, and data sharing among institutions is often performed via fee‑based API queries.

The paper discusses building a blockchain‑based financial risk data sharing consortium that provides a fair and equal data query platform for member institutions, leveraging blockchain’s token generation and verification features to create a transparent pricing and evaluation mechanism.

The content is divided into two parts: the first part briefly describes the business scenario, pain points, and compares two blockchain design proposals; the second part focuses on the implementation, covering blockchain accounting processes and the design of a token‑based settlement system.

Post‑accounting records include who queried whom, which data were queried, and the resulting token balance changes. Information is stored as key‑value pairs on blockchain nodes, with keys comprising the requester, responder, and a unique sequence number, and values containing request, result, and token transfer data. To protect privacy, only hashes and signatures of the original data are recorded on the endorsement nodes, using Fabric 1.2’s sideDB for private data handling.

Audit is performed automatically by a regulatory operation system that compares off‑chain original data with on‑chain records; if discrepancies are found, the system issues an audit endorsement (signature) allowing the requester to initiate a reversal transaction that invalidates the original accounting entry. Audits are triggered only for transactions that the requester disputes.

The token settlement framework assumes all consortium members start with zero tokens and may overdraft up to a soft limit managed by the regulatory system. Periodic snapshots of token balances are taken for off‑chain settlement. The system defines several transaction types: Token accounting transactions – record query events without altering balances. Token reversal transactions – issued after an audit, before the snapshot period ends. Token settlement transactions – aggregate balance changes and monitor overdraft limits. Token rescheduling transactions – open new accounting periods (e.g., daily) to ensure settlement transactions remain valid. Token snapshot transactions – provide on‑chain balance snapshots for off‑chain settlement.

Scalability and institution onboarding involve adapting data query and provision interfaces, deploying the consortium’s blockchain service stack, and setting up endorsement nodes for each institution. Performance requirements include minimum hardware specs and concurrency thresholds; endorsement nodes may use read‑write separation. New members first test in a sandbox environment before moving to production.

In conclusion, the consortium‑based architecture offers a solution for financial risk data sharing with pricing capabilities, though evaluation mechanisms are still under exploration. Enhancing evaluation through token‑based incentives is a future direction, reflecting blockchain’s broader role as a socio‑technical system that enables industry self‑governance.