Central banks around the world have been looking at how they can use blockchain technology to modernize their payments infrastructure to deliver improvements to the speed, cost and security of financial transactions. The Monetary Authority of Singapore (MAS), the country’s central bank, was among the first to seriously address the question, with Project Ubin.
In this interview, Sopnendu Mohanty, Chief FinTech Officer at MAS, speaks about progress made and challenges ahead, international standardization, future proofing, and central bank policy considerations when setting up blockchain based payments systems.
What exactly is Project Ubin?
Project Ubin is a series of practical experiments on Distributed Ledger Technology (DLT) in the area of payments and securities settlement. There has been much talk in the industry about the potential of DLT. What we are doing under Project Ubin is to partner with the industry to develop, deploy and test working prototypes. We believe we need to get our feet wet, to truly understand the technology, its potential benefits, and how we can realize those benefits.
The goal of Project Ubin is to develop simpler to use and more efficient alternatives to today’s systems based on digital central bank issued tokens. Phase 1 of the project which concluded in 2016 focused on domestic inter-bank payments. The key findings are captured in the report “Project Ubin: SGD on Distributed Ledger” MAS published in May 2017. Subsequent phases will be in the areas of securities settlement and cross border inter-bank payments.
Your digital Singapore dollar proof of concept seemed to move really quickly. How long do you think it will be before we see a system go live, and what are the main issues that still need to be addressed?
From a technical standpoint, with a minimum viable scope, a system that transacts in central bank issued currency equivalents can go live within months.
However, such a system would be limited compared to the existing functionality offered by real time gross settlement (RTGS) systems. First, whilst some initial prototypes of liquidity savings mechanisms on these systems exist, they are primitive and may not properly exploit in full the capabilities offered by DLT based platforms.
An example of this is the design of a netting function. How one could design such a netting function, respecting the needs of participants to retain privacy and resilience while still maximising liquidity savings, is an open question.
Second, at a very basic level, there is no standardized feature list for a wholesale payment system. Needs differ across ecosystems, resulting in different and unique requirements.
One would hope that the new systems will be future-ready.
We hope to future-proof the system by not adding in all the bells and whistles that are available or conceivable in the future.
There are also questions surrounding the commercial agreements that govern these systems. How one would charge fees for the use of the system, and which activities would attract fees? Would participants be required to pay a premium for bill enquiries? What about fees for the services provided by potential notaries, storage services, oracles and other services required for the network to function? These are some of the questions which are unanswered.
What is the risk that technology overtakes you, meaning user requirements quickly move on beyond what your system allows?
We hope to future-proof the system by not adding in all the bells and whistles that are available or conceivable in the future.
In fact, the drive is in the opposite direction: we should scale the current system’s features down to a hard core of essential functions such as the settlement engine and queue management. More complex functions can be added that interact with these core functions through well-defined Application Programming Interfaces (APIs).
The idea is that as market requirements shift, participants’ needs can be met by new applications developed outside the core/kernel of the payments engine.
Part of the reason international payments take so long to settle is the interoperability issues between different national systems. Is there a risk that the next generation of DLT payments platforms will evolve separately and without common standards, meaning some of those interoperability issues and inefficiencies remain?
There is certainly a risk of fragmentation of these systems without common standards. However, there is a strong push towards standards formation at multiple international forums, including the ISO/TC 307 standards working group [the International Organization for Standardization group working on blockchain and electronic distributed ledger technologies – Ed.]
The DLT system we are building will have to natively support the ISO standard and have specific libraries to understand the legacy formats required for our own jurisdiction.
Let me address interoperability in two key areas:
Firstly, message formats: Mapping between our RTGS system’s established formats and ISO 20022 standards [the standard for electronic messaging between financial institutions – Ed.] is one of the big items in our roadmap. The DLT system we are building will have to natively support the ISO standard and have specific libraries to understand the legacy formats required for our own jurisdiction.
Secondly, business interoperability: To have meaningful cross border payments, national systems may evolve to hold multi-currency accounts or enable multi-currency liquidity providers that are non-participants to join. It may also evolve to enable banks that do not participate on the MEPS+ [MAS’ real-time gross settlement system – Ed.] to issue payments in their central bank liabilities to participant banks – such as banks with MEPS+ access – in a way that respects anti-money laundering and other policies.
One of the main legal hurdles to overcome is how to handle bankruptcy. What exactly is the difficulty you’re facing?
The finality of transactions in payment systems is often affected by bankruptcy laws. In the case of our original design, the digital currency was issued against segregated collateral-like accounts held by MAS. This meant that if we wished to allow banks to convert digital currency back into normal RTGS balances at all times, the balances in these segregated accounts had to be re-balanced.
Put simply, if you started the day with $100 in the account, which you have pledged to MAS and cannot operate yourself, you would have $100 worth of digital currency.
Say at 6pm you have $300 worth of digital currency, after you tallied up the day’s transactions. Now you wish to withdraw that digital currency into the RTGS to make payments to someone who is not part of the DLT network yet. You send the request to redeem the money to the smart contract, and the contract instructs MAS to release the funds, then proceeds to destroy the digital currency. But it cannot proceed unless we top up your collateral-like account with an additional $200.
This money would have to be gathered from other banks’ accounts. What if one of these banks is bankrupt? The money in the collateral-like account remains in the banks’ names and hence ownership is theirs. The trustee appointed by the courts will have control of the monies. We would require either a guarantee by MAS – where we make whole the missing money – or some loss sharing agreement amongst participants. Alternatively we need to make a change to the law, such that we can still operate these accounts after the failure of the bank.
There are sound business concerns about the increased cost of pre-funding required to making all retail payments on a real time, gross basis.
You initially envisage using DLT for making inter-bank payments, and you have talked about cross border payments and fixed income trading. Could it eventually be applied to retail payments as well?
The current architecture excludes retail payments for now. There are sound business concerns about the increased cost of pre-funding required to making all retail payments on a real time, gross basis. Possible counters to these concerns include the design of hybrid net settlement engines for smaller retail payments, or exploiting ideas from the Lightning Network for payment channels. [The open source Lightning Network uses blockchain technology to make payments, without individual transactions being executed on the blockchain itself, much like how legal contracts provide enforceability without the need to go to court every time. This makes payments faster and reduces costs. – Ed.]
Would having a digital currency give MAS more influence over the economy, for example making monetary policy transmission better?
If we designed the system to do so – yes. However, one can design a system that does not change MAS’ influence.
Some of the arguments for better monetary policy transmission really center on associated reductions in the physical cash in circulation when a digital currency is introduced. This might remove the zero lower bound on interest rates.
Since MAS conducts monetary policy through the foreign exchange rate, however, these benefits are less likely to be reaped.
What impact will the new system have on the broader financial infrastructure? Will banks and other institutions have to make a lot of changes to their own systems as well?
We have deliberately designed Project Ubin in tandem with the clearing house and the banks in order to ensure that there are minimal updates and upgrades required on their part to conduct payments.
This means that we have enhanced, wherever possible, the existing payment gateways and interfacing systems, and respected entrenched formats.
The details of what we have accomplished in this regard have been shared in the Project Ubin Public Report.
Do you envisage digital money completely replacing physical cash in the medium or longer term?
It is possible in the long term to see a phasing out of physical cash. This is more of a question about habits, form factors and business models than the fundamental technology.
Questions by Solomon Teague
