Last Thursday Europe’s Target2 (T2) and Target2 Securities (T2S) interbank payment systems went down throughout normal business hours. The European Central Bank extended operating hours until midnight, as the system only came back online at 18:00, when the real time gross settlement (RTGS) would usually be taking its last instructions. It’s a relatively rare failure, but not unheard off – another outage of similar scale happened in October 2020.
There was one critical difference. The 2020 outage was on a slow Friday afternoon. This year’s was the day before month end, a busy time for both mainstream payments and securities settlement.
If there were a wholesale central bank digital currency (wCBDC) system, similar to the Banque de France’s DL3S, would that help to provide redundancy? At this stage our analysis is only ‘maybe’ and it will take a while.
Database failures and blockchain redundancy
At first the ECB identified a database error. Hence, it initially thought it couldn’t switch to the failover location because it was corrupted. Late in the day it found the problem was “an infrastructure component,” which we’d assume means a hardware failure. Hence, the database was switched to the failover location and the system was restarted after checks.
Without using blockchain, it’s possible to replicate databases in real time. That’s the way most large internet systems work. And from the description, we believe T2 does this. Until recently, the approach used to be referred to as a master and slave database, which while politically incorrect, describes the relationship more clearly than primary and secondary.
If the primary database has been corrupted in some way, the replicated database is a copy that’s in exactly the same state. However, if one can identify a point (or transaction) where the problem starts, it’s often possible to roll back a few transactions on the replica, and get up and running from there.
By contrast, a blockchain works differently. Like database replications, there are multiple nodes. But it provides redundancy because in the case of validating nodes (which can write to the ledger), each node’s ledger contents are not just copied from the primary ledger, they’re independently created based on transaction verifications. A bogus transaction can get approved by all nodes, but is likely to be deliberate.
The two bucket metaphor
An imperfect analogy is havings two taps, each with a bucket. In the replicated database case, one bucket has a flow of water and reaches a certain level. The second bucket then has a tap that automatically switches on and aims to get to the same level. By then, the first tap is already filling up further.
In the blockchain case, the taps would drip water into their respective buckets in a synchronized fashion at the same rate.
However, blockchains aren’t really designed for situations where just one party (the central bank) writes transactions. If the sole purpose is redundancy, it’s a significant overhead to run a blockchain system that has to arrive at a consensus between nodes in order to write to multiple separate databases.
On the other hand, if there’s another purpose, such as enabling atomic settlement for securities transactions and programmability, then it might just be worth it.
The ECB has other redundancies
The ECB already has multiple strategies for T2 redundancy. In addition to the failover location, there’s also the Enhanced Contingency Solution II (ECONS II). However, it does not have the same level of functionality as T2, so it was only used for foreign exchange payments to CLS and margin calls by central counterparties (CCPs).
If something like France’s wCBDC had been in production, it would still need to tokenize money transferred from the RTGS (or escrowed) in order to function. So in the first instance, if T2 was down, the wCBDC might also be out of action. If ECONS II were allowed to be used for banks to top up their wCBDC balances, then banks could potentially make some settlements that way. But ECONS II often requires additional collateral from banks.
There’s a much bigger reason why a wCBDC – in the early stages – is unlikely to help with redundancy. wCBDC systems are not designed to clone the functionality of an RTGS. They usually have specific purposes targeted at the settlement of transactions relating to tokenized assets, whether that’s a digital bond or the interbank settlement of tokenized deposits. Hence, their integration with commercial bank systems will be focused on these functionalities alone.
That said, if there were a tokenized deposit system that was up and running with most banks onboarded, in a crisis it might be possible to switch to tokenized deposits and wCBDC as a primary solution for payments. But we’re currently a way off from that happening.
