Why Banks Should Adopt Blockchain Systems: Principles and Architecture

Why Adopt a Blockchain System

Before launching a project, we need to discuss why blockchain is relevant.

Both for us and banks, the logic is to consider which products suit blockchain architecture and which do not. The article references Duan Xinxing’s three principles and adds bank‑specific notes.

Law 1: “Don’t use a cannon to kill a mosquito” – blockchain is best for asset networks; banks deal with assets, so it matches.

Law 2: Multi‑party data writing is required – if a single writer can handle the data, blockchain is unnecessary; therefore a genuine multi‑party collaboration need must exist.

Law 3: Blockchain products are inherently weakly centralized – domestic payments are dominated by centralized platforms, but cross‑border settlement, clearing, and trade finance benefit from blockchain because they lack a trusted central coordinator.

Examples include the credit‑letter blockchain pilot by China‑Citic Bank and Minsheng Bank, and CMB’s blockchain‑based cross‑border clearing that reduced message latency from minutes to seconds.

Typical Integration Architecture

The following diagram shows a typical integration of a bank’s existing IT with blockchain nodes interacting at the application, business, and data layers.

Application Layer : banking systems such as international settlement, foreign exchange, and payment interact with blockchain via RESTful APIs or WebSocket for transaction submission and result reception.

Business Layer : risk control, settlement rules, AML policies are encoded in smart contracts (chaincode) to enforce on‑chain.

Data Layer : blockchain uses a key‑value store for immutable ledger data, while relational databases (Oracle, DB2, MySQL, …) provide backup, analytics, and integration with existing bank data pipelines.

Changes in Reconciliation Model

Traditional reconciliation relies on a central clearing house (e.g., UnionPay) with end‑of‑day batch processing. Blockchain generates blocks every few seconds, achieving near‑real‑time consensus, so reconciliation becomes continuous and can be based on the blockchain ledger instead of a central entity.

End‑of‑day reconciliation → real‑time reconciliation.

Reference shifts from a central clearing house to the blockchain ledger.

The result is higher efficiency and near‑zero error rates.

Ensuring Transaction Consistency

In a digital‑asset withdrawal scenario, a blockchain transaction and a corresponding banking ledger update must be atomic.

Traditional banking ensures consistency via strong relational DB consistency, compensating transactions, or two‑phase commit (2PC). These mechanisms do not work for blockchain because blockchain nodes are independent services, use NoSQL stores, and lack rollback.

The solution is to leverage micro‑service patterns for consistency. Three patterns exist: reliable event, compensation, and TCC. The reliable event pattern (or compensation when needed) is most suitable because blockchain cannot support cancel operations required by TCC.

We recommend an external event system that records the full lifecycle of messages. Normal flow (steps 1‑5) is illustrated, with possible exceptions such as blockchain transaction failure or missing notifications.

Blockchain transaction fails.

Blockchain succeeds but event system is not notified.

Account system transaction fails.

Account system succeeds but event system is not notified.

The reconciliation process periodically scans for (A) registered transactions without block notifications and (B) account transactions not marked “completed”, then resolves each case by querying the blockchain, updating event status, or re‑triggering account processing. Idempotency in the account system is required.

Identity Real‑Name Verification and Key Management

Public blockchains typically lack identity verification and leave key management to users, which does not meet financial regulations. For a banking consortium chain, two goals are essential:

On‑chain identity real‑name verification.

Manageable asset control keys, including loss and recovery.

We suggest using existing bank KYC channels (e.g., four‑element card verification) for identity, and offering an optional custodial key service where the bank can store keys securely and provide recovery mechanisms.

High‑Availability Deployment Architecture

Bank IT demands high availability; blockchain must support HA clusters.

We propose a micro‑service architecture where blockchain nodes are logical services composed of scalable physical machines. Service registration (e.g., Spring Cloud Eureka) and discovery (Ribbon) enable applications to locate nodes without single points of failure.

Performance‑optimized nodes act as ledger writers, while lighter nodes provide service responses and backup, fitting typical bank HA standards.