Using replicated ledger to reduce SWIFT costs
Introduction
This paper proposes an approach to build a payment product that could be deployed across units of same bank or banks which have correspondent relationships, to reduce SWIFT message costs and to conserve liquidity by reducing need for Settlement and Nostro accounts.
The paper proposes an outline of a product that implements a replicated, single wrapper around existing ledgers of such bank units to enable quick, irrevocable, tamper-proof approach to managing electronic payments between correspondent bank units.
Existing ledgers of the bank would not be replaced or disturbed. Instead a wrapper application would be deployed that tracks specific entries in the ledger and replicates the changes to all members. This enables each member bank to see the same ledger at the same time and also be guaranteed of its accuracy. For this purpose, it is recommended the product be built using Blockchain for established and proven security.
Such a replicated ledger would reduce active, recurring costs of using SWIFT network to pass payment messages. This will also reduce the much larger passive cost of holding funds in a non-remunerative settlement a/c with the correspondent bank.
Challenges
Existing ledger schemes, developed during the 1400s by Luca Pacioli, are based on individual ledgers for each business, thus preserving its own version of truth. There is no “common” agreed-upon version of truth. With each bank seeing only its own part of the transactions, the view they have is similar to the “six blind men and an elephant”.
To overcome these shortcomings, and process payments between unrelated parties, a central trusted 3rd party is necessary. SWIFT exists to pass payment messages between Commercial banks. The Central bank (for a given currency) is used to settle payments in central bank money. Both are trusted 3rd parties which do not have a financial stake in the concerned Commercial banks which transmit the messages and handle settlement.
Background of payments
The above diagram is a representation of how current payment schemes work. This approach is called 4-box Model and is common to all payment schemes and systems. The CI comprises of the Payment scheme and scheme provider.
There are three parts to a payment mechanism:
a) Payment message transmission
b) Payment reconciliation
c) Settlement via Central bank’s settlement accounts and ledger entries.
Payment message transmission
Payment messages between Commercial banks are typically fulfilled by the scheme provider’s schematics and technical requirements.
Here we take the example of LV local payments that involves using RTGS protocol.
Commercial banks wanting to make payments or receive payments (Push and Pull), send the messages to the CI. The CI acts as a Hub for receiving, collating and netting[1] payment messages before retransmitting confirmations/denials to Commercial banks.
The scheme provider offers finality of message transmission. In this case, SWIFT.
Payment reconciliation
The CI or the PSP (Payment Scheme Provider) typically acts as the super-agent of all individual Commercial bank ledgers. It calculates and reconciles payments to/from various Commercial banks and then sends the amounts to the Settlement bank (Central bank in most scenarios). The reconciliation ledger entries calculated by CI and sent to Commercial banks and also to the Settlement bank.
Individual ledger entries of banks have to be reconciled with what the CI entry shows, thus making the CI as a super-ledger of all ledgers. The CI provides finality of reconciliation.
Settlement via Central Bank and ledger entries
The Settlement bank (Central bank mostly) receives the settlement figures and transfers the money between the Commercial banks using the settlement account to reflect the changes.
The settlement bank offers finality of payment. If it is settled in Central bank money, it offers a guarantee that funds will be available to the receiver. To reduce risk to itself, the settlement bank expects all member Commercial banks to fund and maintain funds in a settlement account which is funded with enough money to meet daily obligations. The settlement bank could also offer to lend its own money at overdraft charges to meet temporary/overnight shortfalls. It can also demand collateral in addition to settlement account funding to ensure enough funds are available to avoid a freeze in payments.
This is solely because no single bank, not even the settlement bank, has a single picture of all ownership of funds. This means no single bank/CI/settlement bank can know the assets and balances of Commercial bank beyond what is held in the settlement account.
The only account the settlement bank can trust and access immediately is the settlement account of each Commercial bank held with it.
Ledger activities during the transfer
This is how individual ledgers will look like when transferring funds to/from other banks or units in a country or a currency. Same principle happens in cross-currency too.
Shortcomings in As-Is process
a. Since no two banks can agree on a transaction based on their own ledger, SWIFT came into being to guarantee and confirm message transmission. Central banks operated as settlement agents to guarantee payments.
b. SWIFT charges the Bank for processing the payment orders of both receiving and sending banks.
c. Commercial banks’ paid SWIFT about $600mn to transmit 5.6bn payment messages between 10,800 institutions. Many of these are branches and subsidiaries of same bank group.
d. Banks seek to reduce cost on payment processing and a good starting point is reduction or zero cost on transfers between subsidiaries.
e. A trusted 3rd party with powers to overwrite and overturn ledger activities needed to have a unified view. In UK, the CI transmits the amounts due/from each bank at end of every settlement cycle. The BoE makes entries in the settlement accounts of each bank which is final and binding. This enforces a cost on the entire payments mechanism.
f. A Central bank typically insists that commercial banks maintain massively funded settlement accounts with it to cover the payments due from the Commercial bank.
g. Central banks play the role of arbitrator of ledger, guaranteeing payment with their central bank money. This results in high costs of payments and also forces the commercial banks to deposit and retain large sums of money in settlement accounts to cover payments via Central bank money.
Domestic transfer through the central bank (BoE) as example
Value Proposition / Introduction to the Technology and Approach
Scope of coverage of instruments
The scope of instruments covered are outlined in blue. Those not in scope of this paper are outlined in gray background and white text.
A better way would be for a single view of the ledger of all participants, with the ledger state replicated between the participant banks, monitored by central bank. This approach needs to be tamper-proof, irrevocable and with a traceable history.
The proposed technology concept is Blockchain. Blockchain can be used to implement a replicated ledger between Banks with all the safety measures listed above. This also makes it possible for the banks to have a bilateral visible, immutable, transfer of value, adjudicated by the settlement agency. The central bank in this case would move away from the role of a settlement agency and instead act as an adjudicator.
Based on above examples, we can conclude that in a replicated ledger concept, A’s bank initiates the payment, and customer E is credited for value directly. BoE is operating as an adjudicator to ensure compliance and regulations are met. This reduces its settlement risk. At present most RTGS payments worldwide, are done using SWIFT CUGs. E.g., CHAPS, FedWire, SMA, HKMA, etc.
Blockchain replicated ledger solution
This approach is to initially map a Blockchain ledger as a Virtual Ledger over existing ledgers of the bank. This way banks can utilize existing infrastructure with minimal change and payments to other banks can process via SWIFT. Payments to same bank/recognized banks are converted to Blockchain Transactions and confirmations and posted to the distributed ledger. This is picked up by all other distributed ledgers connected to each other and the data replicated. The transaction is processed by the concerned / targeted bank and the amount credited to the corporate/business account.
In above diagram, each bank holds the entire history of changes to the ledger. So, no one bank will be able to double-spend or defraud others. Every transaction entered into the bank’s own internal ledger is fed through the proposed Product, which acts as a Blackbox, and replicates the changes to the ledger copies maintained by all other associated banks. This would enable each bank to see the exact balances available and to confirm or deny a Payment, without going through the convoluted approach of using SWIFT and correspondent banks and settlement accounts.
This proposed Blockchain-based product can be built as a ledger and can be incorporated into any Core Banking System, like Commercial bank to ensure banks operating with this CBS could opt for a Blockchain based ledger to reduce collateral and liquid funds needed at the central bank.
Why Blockchain in this scenario?
A Blockchain based distributed database has the following benefits over a centralized ledger:
- No single centralized database. Blockchain is a database that contains all the payment history (ledger of activities) of banks connected to the product. This database is replicated across all banks so that all banks see the same picture.
- Architecture prevents revision of modification of data entered. You can add, but not delete or edit once entered. At any point of time you can activate or deactivate the entities (BICs) of the same Parent Bank.
- A Blockchain consists of Transactions which are created by Business Entity within the same parent Bank and sent into the system. Blocks are confirmations of those transactions which freeze the transaction. These blocks actually replace the SWIFT confirmations.
- Every instance of the Database is synced with all others via the Blockchain protocol. This uses Blocks to confirm the transactions. Transactions and Blocks (confirmations) are part of the transmission and hence inherently secure.
- Easier to add more bank branches and in fact more scalable as it grows.
Conclusion
Changing Capital and Liquidity regulations force commercial banks to hold large funds in settlement and Nostro accounts. Payment transfer costs including SWIFT costs are increasing. The issue is the current independent ledger approach with each bank seeing its own view of the accounts. To overcome shortcomings of this 400-year approach, independent operators like Nostro accounts, ACH and Settlement accounts with central bank have risen. This document proposes an approach to a Product which can reduce cost of funds and payment costs by adopting a replicated ledger wrapper that ensures a single virtual ledger exists between correspondent banks. This ensures a single view of funds and ledger entries for all participant banks, and solves the 400-year-old problem in accounting and ledgers. This replicated ledger is proposed to be built using Blockchain as a protocol to ensure safety, irrevocability and visibility.
[1] Netting is not done for RTGS payments. The Central bank typically owns the CI and runs it. It also acts as a settlement bank.
All trademarks referred here/mentioned here belong to the respective owners.
