We now present two designs for payment systems that use distributed ledgers. One such was implemented by the Bank of Canada for commercial banks for use in the interbank market, Project Jasper. This design is largely about the potential to improve on existing systems or at least validate that DLT payments can do as well as traditional systems. Initially with Ethereum, and then subsequently with Corda, the project was ultimately successful, including time lockups in a multilateral queuing system.
A second system is under development in Southeast Asia for money transfer operators who engage in the Lightnet international fiat money exchange, with Lightnet transferring fiat tokens across boundaries. This design is about creating and implementing something new and can include ultimately constrained-optimal designs for trade, credit, and insurance in coordination with a digital reserve system.
To summarize from the Payments Canada (2017) white paper, Project Jasper is an experiment in private permissioned distributed ledgers that allows for the exchange of central-bank-issued digital assets. The goal is to transform the payment structure in Canada. If an improved ecosystem could be built, there could be significant benefits for the whole financial sector and the economy overall. It is important to keep pace with the shift to digital commerce and remove impediments and to try to get as close as possible to a frictionless end-to-end customer experience. In experimental simulations, Project Jasper could indeed handle the high volume of Canada’s large-value interbank transfer system.
Project Jasper first explored Ethereum and then moved to R3’s Corda platform to allow for improvements in settlement finality, scalability, and privacy. As noted in the white paper, DLT allows improved back-office payment processing and reconciliation with and across participating financial institutions, reducing the likelihood of costly errors and improved automation through the use of smart contracts.1 Another goal of Project Jasper was cybersecurity, creating backup ledgers to eliminate single points of failure.
As noted in the Payments Canada white paper as well, it is possible to limit information on a database when privacy and confidentiality concerns among parties are paramount. For example, in Project Jasper, parties see only their own activity. The role of the Corda notary node is played by the Bank of Canada, though Corda can eliminate the need for such a single trusted database operator.
Netting promotes funding efficiency and smoother intraday-payments flow. Phase 2 of Project Jasper appears to be one of the first instances of a central queue within a DLT platform for payments. For example, a participant’s account gives permission for a bounded, specified amount of value to be placed into a queuing option. This can be changed, but not when the queuing algorithm is running; during that time the participant is blocked as codes search over best transfers.2 Phase 3 extended the phase 2 proof of concept to the settlement of exchange traded equities.
The central bank maintains a commitment to settle accounts but has risk exposure in doing so, and so collateral is posted by participants. Technically, in Jasper there are two versions that differ in the collateral and loss allocation procedures: The defaulter pays, and the survivors pay through pooled risk.3
Project Jasper is illustrative of sophisticated multiparty smart contracts used in the design of a payment system, showing what is feasible to do with distributed ledger technology. Other potential examples of DLT-based payment systems come from the Monetary Authority of Singapore. Nevertheless, there is some skepticism among central bankers concerning DLT interbank systems for large-value payments. Are they really needed? The Project Jasper application succeeded in re-creating the functionality of an existing traditional payment infrastructure—that is, on one hand, it did as well, but on the other hand it did not dominate.
Still one does wonder if the reconciliation, data security, and contract commitment advantages of DLT are being underemphasized in the attempt to replicate existing systems.
The Project Jasper white paper does note, in addition, that DLT is particularly relevant, likely needed for cross-border payments. Current infrastructure still relies on financial institutions maintaining their own databases, and so counterparty risk is high. Subsequent collaboration among the Bank of England, the Bank of Canada, and the Monetary Authority of Singapore has explored in detail the limits of current interbank transfer systems and the possible use of distributed ledger technology (see Kimberley 2019; also Monetary Authority of Singapore 2018).
Consider the case of Cambodian or Myanmar migrants in Thailand, migrants who both need to fund their trip (now regulated) and to send money back home to family. Remittances in Southeast Asia amounted to $63.9 billion in 2016, while over the six years leading up to 2016, transfer fees grew by 3% to 7.1% (Leong 2017). The high transfer fees are partly a result of legacy technology in the formal sector and limited access to formal currency exchange markets. Traditionally, a money transfer operator (MTO) conducts cross-border transactions using a single server to record transactions among its international subsidiaries, going through traditional financial institutions or entering into a bilateral agreement with an MTO in another country. This limits the number of partners a given MTO can have and results in high transaction costs.
Lightnet proposes to create for MTOs in Southeast Asia a highly liquid decentralized settlement layer on a permissioned blockchain. It is a hybrid in the sense that it uses, and effectively transfers, fiat money. It does this with its own fiat tokens that have been minted by posting collateral tokens (Velo) to the Velo protocol. MTOs can be viewed as agents with varying underlying balance sheets hit by the needs of their customers for trade.
To trace out a sample transaction, a client, to be called Alan, asks an MTO in Thailand to transfer money to Alice in Cambodia. Alan is essentially lending money as a deposit to the Thai MTO, which will be extinguished when Alice in Cambodia receives her money. We come to the determination of the exchange rate (as discussed below). At some point in the time line, Alice receives a text message that her money from Alan is in. Alice then goes to a payment gateway—for example, a 7-Eleven or a registered point-of-sale (POS) store—and shows a QR code from the text message. The 7-Eleven staff scans it and gives Alice the money. At this point, the Cambodian MTO is lending money to the Thai MTO. Conceptually this is to be repaid, ideally, by a transaction in the reverse direction. More generally, though, netted transactions among a larger community of MTO operators happen in a multilateral clearing operation. We come back to this later.
When the Thai MTO first enters Lightnet, it enters into a smart contract and converts Thai fiat money into Thai baht collateral. In return for its deposit, the MTO gets an intraday Thai fiat credit balance in Thai fiat tokens. This serves as an upper bound for outgoing remittance transactions on any given day. During the day, the Thai MTO then initiates the transaction for Alan by submitting the order to Lightnet, giving up some of its Thai baht credit line. In turn, Lightnet posts collateral for it Thai fiat accounts, secured as backed by Velo tokens. These tokens are acquired as a loan from Velo labs or a grant (or purchased on an exchange, which we will come back to).
Lightnet maintains an off-chain order book, linked to Stellar. When initiating the transaction, Alan’s Thai MTO queries the Lightnet order book and finds the best offer exchange rate, asking Alan whether he wants to continue (Alan could withdraw at that point). The order book matches MTO orders on behalf of customers to funding from liquidity providers (not simply banks but others, arguably with lower cost of funds). In the case of the Alan-Alice example transaction, the liquidity provider is giving up Cambodian riel. Such transactions are grouped and offset before sending batched orders to Stellar at regular intervals. Order-book matching maintains an accurate source of transactional reference between any two transacting MTOs, providing reconciliation. This reduces the probability of disputes and delays, a feature of DLT commented on earlier in chapter 3. The Lightnet settlement network and the Velo protocol are built on Stellar, which provides interoperability. Velo hopes to achieve a transaction throughput of 1,000+ per second, with each transaction taking three to five seconds at a very low cost, a tiny fraction of a penny.
At the end of the day, as anticipated, the many transactions that occur among all MTOs will be netted using a digital reserve system’s distributed ledger algorithm. Each MTO will be notified about how much it needs in order to settle its credit line. If the MTO successfully settles its end-of-day balance, its fiat credit balances will be replenished, also resulting in an increase in the MTO’s credit rating. Alternatively, if any MTO fails to settle the balance, the MTO’s fiat collateral will be liquidated, which had been locked as collateral, executing the conditionality of the contract and cutting the MTO’s credit rating.4 Under this system, counterparties can conduct transactions with multiple pairings in different countries without having to trust each other.
Some MTOs are already engaged in contractual bilateral relationships, with fiat credit and e-credit lines. In principle, depending on these relationships, they handle credit and insurance with each other. This was noted in chapter 4 on M-Pesa and in Indonesia. Going one step further, the implementation of constrained-optimal contracts among MTOs is possible. This could be implemented on DLT as envisioned in the examples on information-constrained credit and insurance in chapter 7.
1. Reconciliation and reliable registries were mentioned in the introduction to this book.
2. See Güntzer, Jungnickel, and Leclerc (1998) and Kuussaari (1996) for further discussion of algorithms for clearing and risks.
3. See Monnet and Nellen (2014) for theoretical modeling of central counterparty (CCP) clearing. Also related, see Monetary Authority of Singapore and the Association of Banks in Singapore (2017, 6) on running its own innovation center: “The prototypes successfully demonstrate several points. Firstly, that key functions of a RTGS [real-time gross settlement] system such as fund transfer, queueing mechanism and gridlock resolution can be achieved through different techniques and solution designs. Secondly, decentralizing the key functions of a RTGS system may not only mitigate the inherent risks of a centralized system, such as single point of failure, but may also affirm the promised benefits of DLT, for example cryptographic security and immutability.”
4. One vision for Velo has the token as a utility at a fixed price. If there are markets for Velo exchanges against fiat, new issues are raised, and addressed, in chapter 11 on cryptocurrency.