Are central banks too reliant on SWIFT for domestic payments?

Central bank settlement systems are the the tectonic plates of the payment system: they are vitally important to our lives, but we never see them in action. All of a nations' electronic payments are ultimately completed, or settled, on these systems. If they stop working, our financial lives go on pause, or at least regress to older forms of payment.

In this post I want to introduce readers to a crucial feature of these payments tectonic plates: their reliance for domestic settlement on SWIFTNet, a financial messaging network used by banks and other financial institutions to communicate payments information. Think of SWIFTNet as a WhatsApp for banks, but exclusive and very secure. 

This reliance – or over-reliance – is best exemplified by a recent decision by the European Central Bank. The Target2 settlement system has long been the bedrock layer of the European payments universe. All domestic payment ultimately get tied-off on the system. Since it was introduced in 2007, Target2 has been solely reliant on SWIFTNet for sending and receiving messages. 

When the European Central Bank replaced Target2 with T2 earlier this year, it modified the system to have two access points: it kept SWIFTNet but added a competing messaging network, SIAnet, to the mix. As one commentator triumphantly put it, "SWIFT’s monopoly for access to the T2/T2S system is broken."

SWIFTNet is owned by the Society for Worldwide Interbank Financial Telecommunication, or SWIFT, which is structured as a cooperative society under Belgian law and is owned and governed by its 11,000 or so member financial institutions. Whenever SWIFT gets mentioned in conversations, it tends to be associated with cross-border wire payments, for which its messaging network is dominant. However, for many jurisdictions, including Europe, SWIFT is also integral to making domestic payments. It's this little-known local reliance that I'm going to explore in this post.

The dilemma faced by central banks such as the European Central Bank is that SWIFTNet is an incredibly useful messaging network. It is ubiquitous: most banks already use it for cross-border payments. And so the path of least resistance for many central banks is to outsource a nation's domestic messaging requirements to SWIFT, too. However, this reliance exposes national infrastructure to SWIFTNet-related risks like foreign control, sanctions, snooping, and system outages.

Financial messaging 101

Before going further, we need to understand why financial messaging is important. For a single electronic payment to be completed, a set of databases owned by a number of financial institutions, usually banks, must engage in an intricate dance of credits and debits. To coordinate this dance, these banks need to communicate, and that's where a messaging network is crucial.

Say, for example, that Google needs to pay Apple $10 million. Google tells its banker at Wells Fargo to make the payment. Wells Fargo first updates its own database by debiting Google's balance by $10 million. The payment now has to hop over to Google Apple, which banks at Chase. For that to happen the payment flow must progress to the core of the U.S's payments system, the database owned by the Federal Reserve, the U.S.'s central bank.

Along with most other U.S. banks, Wells Fargo has an account at the Federal Reserve. It communicates to the central bank that it wants its balance to be debited by $10 million and the account of Chase to be credited by that amount. Once Chase's account at the Federal Reserve is updated, Chase gets a notification that it can finally credit Apple for $10 million. At that point Apple can finally spend the $10 million.

This entire process takes just a second or two. For this "dance of databases" to execute properly, the Federal Reserve, Chase, and Wells Fargo need to be connected to a communications network.

The sort of messaging network to which the central bank is connected, and the stewardship of that network, is thus crucial to the entire functioning of the economy.

Proprietary messaging networks or SWIFTNet? 

The Federal Reserve is somewhat unique among central banks in that it has built its own proprietary messaging network for banks. All of the 9,000 or so financial institutions that use the Federal Reserve settlement system, Fedwire, must connect to the Fed's proprietary messaging network to make Fedwire payments. To make international payments, however, U.S. banks must still communicate via SWIFTNet.  

Let's flesh the story out by trekking north of the border. Whereas the Federal Reserve has no reliance on SWIFTNet, Canada's core piece of domestic settlement infrastructure, Lynx, relies entirely on SWIFTNet for messaging.

For example, if Toronto Dominion Bank needs to make a $10 million to Scotiabank, it enters this order into SWIFTNet, upon which SWIFT forwards the message to Lynx, which updates each banks' accounts by $10 million and sends a confirmation back to SWIFTNet, which tells Scotiabank that the payment has settled.

For payments nerds, this network setup is called a Y-copy topology. The network looks like a "Y" because the originating bank message is relayed from the sending bank via SWIFTNet, the pivot at the center of the Y, down to the settlement system, and then back up via SWIFTNet to the recipient bank. It is illustrated below in the context of the UK's payment system, with the CHAPS settlement system instead of Lynx, but the idea is the same.

A Y-copy network topology for settling central bank payments in the UK [source]

The upshot is that the Federal Reserve controls the messaging apparatus on which its domestic settlement depends, whereas Canada outsources this to a cooperative on the other side of the ocean.

Many of the world's small and middle-sized central banks have adopted the same Y-copy approach as Canada. This list includes Australia, Singapore, New Zealand, Nigeria, UK, Sweden and South Africa. However, some members of this group are starting to have second thoughts about fusing themselves so completely to SWIFT.

Removing the single point of failure

The European Central Bank is at the vanguard of this group. Prior to 2023, the European Central Bank was in the same bucket as Canada, relying entirely on SWIFTNet to settle domestic transactions. 

With its upgraded T2 system, Europe doesn't go quite as far the Fed's model, which is to build its own bespoke messaging network. Rather, European banks now have the option of either sending messages to T2 using SWIFTNet, or they can use SIAnet, a competing network owned by Nexi, a publicly-traded corporation. SIAnet stands for Societa Interbancaria per l'Automazione, a network that originally connected Italian banks but has now gone pan-European.

The reason for this design switch is that European Central Bank desires "network-agnostic connectivity." This dual access model will make things more complex for the European Central Bank. If a commercial bank originates a SIAnet message, the central bank will have to translate this over to a SWIFT message if the recipient bank uses SWIFTNet. Nevertheless, the European Central Bank believes this dual structure will offer more choice to domestic banks.

The ECB also hints at the enhanced "information security" that this new setup will provide, without providing much detail. The UK's recent efforts to update its core settlement layer sheds some extra insights into what these security improvements might be. Right now, the UK's core settlement system, CHAPS, can only be accessed by SWIFTNet, much like in Canada, so that all domestic UK payments are SWIFT-reliant.

In its roadmap for updating CHAPS, the Bank of England is proposing to allow banks to access the system via either SWIFTNet or a second network, which doesn't yet exist. The idea is to enable "resilient connectivity" to the core settlement layer, especially in periods of "operational or market disruption." Should SWIFTNet go down there would be no way for financial institutions to communicate with CHAPS, and the entire domestic economy would grind to a halt. A second network removes the "single point of failure" by allowing banks to re-route messages to CHAPS.

The Bank of England also highlights the benefits of competition, which would reduce the costs of connectivity.

This sounds great, but there are tradeoffs. Using a a single network for both domestic and international payments is valuable to the private sector because it offers standardization and efficiencies in banks' processing. Adding a second option will also complicate things for the Bank of England, since it will have to design and build a system from scratch, much like the Fed did, which could be costly. Either that or it will have to find another private option, like the ECB did with SIAnet. This second network may not be as good as SWIFTNet which, despite worries about resiliency, has been incredibly successful.

When CHAPS went down earlier this year for a few hours, for instance, it wasn't SWIFT's fault, but the Bank of England's fault. The same goes for a full day outage in 2014. 

Comparing a V-shaped network topology to Y-Copy in an Australian context [source]

The type of settlement topology that the UK is proposing is known as "V-shaped," since all messages are sent directly to the central bank settlement system for processing via any of a number of messaging networks, and then back to the recipient bank. The difference between a V-shaped topology and Y-copy is visualized in the chart above in an Australian context, but the principles apply just as well to the UK.

Sanctions and "the SWIFT affair"

The decision to make domestic payments less dependent on SWIFTNet is much more easy to make for outlier nations like Russia. SWIFT is based in Belgium and is overseen by the Belgian central bank, along with the G-10 central banks: Banca d’Italia, Bank of Canada, Bank of England, Bank of Japan, Banque de France, De Nederlandsche Bank, Deutsche Bundesbank, European Central Bank, Sveriges Riksbank, Swiss National Bank, and the Federal Reserve. That put SWIFT governance far out of Russian control.

You can see why this could be a problem for Russia. Imagine that only way to settle domestic Russian payments was by communicating through SWIFTNet. If Russia was subsequently cut off from that network for violating international law, that would mean that all Russian domestic payments would suddenly cease to work. It would be a disaster.

Needless to say, the Central Bank of Russia has ensured that it doesn't depend on SWIFTNet for communications. It has its own domestic messaging network known as Sistema peredachi finansovykh soobscheniy, or System for Transfer of Financial Messages (SPFS), which was built in 2014 after the invasion of Crimea. Prior to then, it appears that "almost all" domestic Russian transactions passed through SWIFTNet – a dangerous proposition for a country about to face sanctions.

Mind you, while Russia has protected its domestic payments from SWIFTNet-related risk, it can't do the same for its international payments. SWIFTNet remains the dominant network for making a cross border wire. There is no network the Russians can create that will get around this.

I'm pretty sure that most larger developing states and/or rogue nations have long-since built independent domestic financial messaging systems to avoid SWIFTNet risk. I believe China has done so. Brazil has the National Financial System Network, or Rede do sistema financeiro nacional (RSFN). India also has its own system, the Structured Financial Messaging System (SFMS), built in 2001. India is even trying to export SFMS as a SWIFT competitor.

The Japanese were typically way ahead on this. The Bank of Japan built its messaging network, the Zengin Data Telecommunication System, back in 1973, several years before SWIFT was founded.

The last SWIFTNet risk is snooping risk. This gets us into the so-called SWIFT affair. After 9/11, the U.S. intelligence agencies were able to pry open SWIFT through secret broad administrative subpoenas. They had the jurisdiction to do so because one of SWIFT's two main data centres was located in the U.S.

To ensure data integrity, SWIFT had been mirroring European data held in its data centre in Belgium at its U.S. site. That effectively gave U.S. intelligence access to not only SWIFT's U.S. payments information, but  also information on foreign payments sourced from Europe or directed to Europe. Worse, it also provided spooks with data on domestic European payments. Recall that the European Central Bank's Target2 settlement system, which settles all digital domestic payments in Europe, was entirely reliant on SWIFTNet for communications.

When the U.S.'s snooping arrangement was made public by the New York Times in 2006, it caused a huge controversy in Europe. SWIFT tried to placate Europe by building a third data warehouse in Switzerland to house Europe's back-up data. But the precedent was set: SWIFT is not 100% trustworthy. And that may be part of the reason why the European Central Bank chose to downgrade its reliance on SWIFTNet when it introduced its new system, and is surely why other nations want to entirely hive their domestic systems off from it.

---

In sum, central banks face a host of complicated decisions in how to bolt on messaging capabilities to their key settlement systems. SWIFTNet is a top notch network. However, too much SWIFT-related risk may be perceived as having negative implications for national security. For large nations with extensive banking industries, building a proprietary domestic messaging alternative seems to be the preferred option. It also seems to be the default choice for rogue states like Russia.

Another alternative is to fallback on using multiple independent networks for access, of which one is SWIFTNet, and thus mitigating exposure to SWIFT-related problems. This is the approach taken by Europe and the UK.

For smaller nations that comply with the global consensus, like Canada, the calculus is different. Building an alternative communications network is likely to be costly. The risk of sanctions and censorship are negligible while the benefits of using a high-quality ubiquitous network for both domestic and foreign payments messaging are significant. Given these factors, it may be worthwhile to bear all SWIFT-related risks and adopt the Y-copy model.

UK's core payments settlement system fails... again. Some thoughts

As they increasingly forsake cash, regular folks are making dozens of digital payments every month. What they don't realize is how this growing reliance on digital payments increasingly yokes their commercial lives to the fate of a single piece of infrastructure: their central bank's large-value settlement system. When that system experiences a glitch, everyone's financial life gets put on hold.

In the United Kingdom's case, it is the Bank of England's RTGS settlement system that lies at the core of the economy. RTGS's centrality is highlighted by the fact that all the arrows in the chart below converge on it: every payment in the UK, big or small (except for cash), ultimately gets finalized using RTGS.

Alas, RTGS failed this Monday for six hours. No reasons were given, although I can't help wonder if it is was due to a software glitch stemming from Bank of England staff having been recently upgraded RTGS to the ISO 20022 payments language, rather than something like a cyberattack.

RTGS's centrality illustrated. Source: Bank of England

This isn't RTGS's first long failure. Back in 2014, a poorly-managed software update caused RTGS to shut down for 9 hours, leading to a revealing independent review.

The failure of the nation's key piece of payments infrastructure, even for just a few hours, is not a good thing. During those hours of unavailability, costly delays are imposed on day-to-day commerce as well as financial markets. Even when a buggy system is up and running, the uncertainty of another potential long failure acts as a pervasive cost on commercial society. 

To reduce these costs, central bank large value payments systems are typically built with multiple layers of redundancy. In RTGS's case, the hardware is hosted at two different sites, so that if the primary site goes down, the other one can quickly kick in. Presumably whatever knocked RTGS down last Monday was fierce  enough to incapacitate both sites.

A third layer of redundancy comes in the form of the Bank of England's Market Infrastructure Resiliency Service, or MIRS. With RTGS's two sites incapacitated, the Bank can "fail over" to MIRS, payments recommencing. MIRS uses different software, programming, and hardware, as well as being  hosted in a geographical remote location with a separate group of staff. This is achieved by an outsourcing arrangement with SWIFT, the same folks who run the global SWIFT messaging system.

There's no indication that the Bank of England failed over to MIRS earlier this week, staff preferring to focus on fixing RTGS instead. Alas, this choice subjected the UK economy to a long settlement delay. Why no fail-over to MIRS? Why choose such a long period of settlement deprivation?

A reading of the inquiry into the 2014 failure gives some clues into what may have happened two days ago. When RTGS failed on Monday, October 20, 2014, the Bank of England likewise chose not to fail over to MIRS. Why? The inquiry pointed to the fact that it would haven taken 2-2.5 hours to get MIRS up and running. Given this length of time, it made sense to try to fix RTGS instead, an inherently-preferable system because of features like the ability to save on liquidity, which the back-up system MIRS lacked.

Management was also reticent to switch on MIRS because they weren't sure if, after having activated it on Monday, they could turn it off on Tuesday night and manually return to a now-repaired RTGS without making a mistake. Bank officials only felt comfortable doing this manual switch back to RTGS on a weekend, because it afforded them much more time than a weeknight.

And thus trepidation about switching on the back up system led to it never being activated in 2014, which forced 9 hours of settlement deprivation on the UK economy.

Among its suggestions, the 2014 inquiry called for an upgrade to the MIRS back up option in order to make it a less anxiety-inducing option to turn to. The passage is worth reading in full:

Work should be undertaken to remove or reduce the barriers to invocation of MIRS so that
the Bank can "switch and fix" in parallel and in confidence. This should focus on testing the process to fail-back to RTGS intraweek (which is the primary barrier to invocation). If it is not possible to reduce this barrier, consideration should be given to enhancing the resilience and functionality within MIRS. In addition the Bank may wish to consider other back-up options for RTGS.

These were all good ideas. They would have reduced the hassle of resorting to the backup option by either improving the switching experience, or by upgrading MIRS's features so that being stuck on it for a few days posed less of a nuissance.

Which brings us back to 2023. If there is an inquiry into Monday's RTGS outage, investigators will need to explore why a multi-hour delay was once again imposed on UK citizens. Was it because, once again, the costs of using the back up system were deemed too high relative to the benefits? If so, were the costs deemed too high because none of the improvements suggested back in 2014 were adopted?

Failure to learn from the past would be unfortunate. These issues are especially salient because the Bank of England will introduce the next version of RTGS in 2024. Given that the updated RTGS will be built with more modern technology, it will (hopefully) fail less often than the older version. But it will still fail. What will the updated back up scheme look like? Will RTGS quickly switch over to tertiary site, or will the economy be forced to endure multi-hour settlement failure as a fix is pursued?

These are not just questions for the UK, but for every nation, since we all have large value payments systems on which commercial society is entirely dependent. It seems to me that if you have designed and built a back up system, that back up system should be, ya know, used. Those who operate them, usually central banks, should not be afraid to switch over. In the UK's case, that means that the decision to turn on MIRS (or whatever back up system the updated RTGS will use after 2024) should always be an easy decision for the Bank of England to make, not a gut-wrenching one.

Back to 1875

The last time I wrote about settlement speed was back in 2017. In that article I published a chart of the history of U.S. securities settlement speed, which I only recently had the chance to update. 

Well, here it is:

You'll sometimes catch technologists making the claim that settlement speed is a function of societal advancement. That is, in the old backward days of yore, settlement used to proceed at horse-and-carriage like pace, but as technology improves we gain the capacity to quicken settlement up to hours, then minutes, seconds and finally zero.

But as the chart illustrates, the technological explanation of settlement speed isn't right. We're about to return to t+1 (or next-day settlement) in 2024, the same pace we had back in 1875. Settlement speed isn't dictated by technological advancement, folks, it's the end result of a conscious choice that takes other factors into consideration, such as efficiency.

I was going to write an article explaining this more clearly, but I was reminded of a post I wrote for AIER back in 2021, and hadn't yet re-published here, which already makes this point more than adequately. So without further ado, read on:

In Finance, Slow is Good

In an age of instant communications, a stock trade takes a leisurely two days to settle. That is, if you buy some shares of Tesla on Monday, your brokerage won’t receive the shares (or pay the cash) until Wednesday. In industry speak, this is called T+2.

This seems an achingly long time to settle a transaction. Indeed, last month, the CEO of Robinhood, a discount brokerage, went so far as to suggest that there is no reason why “the greatest financial system the world has ever seen cannot settle trades in real time.”

In fact, there is a very good reason to eschew real-time settlement. Going slowly is a way to capture one of the world’s great natural financial forces: netting. Go too fast and you lose out on it.

To understand the magic of netting, let’s consider a world without it. Imagine a world with real-time settlement, where if I buy Tesla on Monday at 10:49 it settles at 10:49.

Say that I buy $100 worth of Tesla shares from you. We each use a different brokerage. With settlement proceeding in real time, the moment after the trade is made your brokerage will transfer the Tesla shares to my brokerage. My brokerage will simultaneously wire your brokerage the $100.

That’s two transactions between the brokerages.

Now let’s say that thirty minutes later, Jill decides to buy $100 worth of Tesla from Tom. Tom and I are clients of the same broker, while you and Jill are clients of the second broker. As before, the brokerages will have to settle up immediately. Tom’s brokerage will have to transfer the Tesla shares to Jill’s brokerage, and Jill’s brokerage will have to wire Tom’s brokerage the $100.

The two brokers now have to do four transfers between each other.

But if settlement is slowed by just a little bit, then the participants to this trade get to enjoy the magic of netting.

Let’s repeat all those transactions, but wait an hour before settling up accounts. When the hour is up, the brokers have two trades to settle up. But instead of processing both separately, they can just cancel them out. In this example, the inter-brokerage flows perfectly counterbalance each other. Our $100 Tesla trade is offset by that of Jill and Tom. And so the two brokerages needn’t do any transactions with each other. The first brokerage simply balances Jack’s and my account while the second brokerage balances Jill’s and your account.

And that’s why netting is so powerful. By making everyone wait just a little, it cuts down on the amount of work the system must do, in this case reducing brokerage-to-brokerage transfers from four to zero.

The netting afforded by T+2 settlement is so efficient that it allows the National Securities Clearing Corporation, which processes all trades involving U.S. equities, to reduce average daily equity volume of around $1.7 trillion by about 98%, leaving just a tiny $38 billion to be settled.

Faster is often better. But, in finance, a bit of tardiness can be a good thing. That’s why we should be wary of Robinhood’s call for real-time settlement. It would put an end to netting.

In fact, we already have financial systems that have gone real time only to double back and reintroduce slowness. It’s an interesting story, one worth recounting if only to show why real-time stock settlement is no panacea.

In the 1990s, central banks around the world began to roll out a new type of large-value payment system: real-time gross settlement systems (RTGSs). People like you and I use banks to make payments. But banks in turn must make payments amongst each other––very large payments––and for that they use their national central bank’s large-value payments system. This bit of central bank infrastructure is one of the most important, unsung pieces of any nation’s plumbing.

For decades, large-value payment systems operated on a deferred net settlement basis. Settlement was slow by design. Throughout the day, banks initiated payments to each other using the central bank platform. When 5:00PM finally rolled around, all reciprocating debits and credits were netted off and then settled between banks. Deferring settlement to the end of the day allowed for the number of bank-to-bank payments to shrink to a tiny fraction of total business transacted. It was incredibly efficient, albeit slow.

With the arrival of RTGSs in the ’90s, large-value payments were settled instantly, rather than at the end of the day. When Wells Fargo pays Citibank $100 million at 9:52AM, this involves an immediate transfer of $100 million in settlement balances at the Federal Reserve.

The ability to make a real-time payment is valuable. Sometimes you really need to wire funds to someone by 2:31PM, not 2:45PM.

However, real-time settlement at the central bank meant doing without the benefits of netting. So RTGSs had to process a lot more transactions than the deferred net settlement systems that they replaced. To keep up with this payments firehose, banks had to maintain a much larger hoard of central bank money on hand.

In an effort to reduce this hoard, banks adopted a strategy of waiting for an incoming payment to arrive before making an outgoing payment. Unfortunately, with all banks adopting this strategy, the result has been that payments often get pushed towards the end of the day. Many payments experts worry that this pattern isn’t healthy, since it increases the banking system’s vulnerability to operational problems.

The solution that emerged in the mid-2000s was the introduction of a new piece of central bank architecture: liquidity savings mechanisms (LSM). Central banks still allowed banks to settle payments in real time via the RTGS, but they also provided the option of submitting payments to an LSM, or central bank queue. A payment might wait in the LSM for 1 minute, 10 minutes, or 1 hour, until offsetting payments from another bank arrived to cancel it out.

By slowing down settlement, LSMs reintroduced the wonders of netting. And as a result, banks no longer had to keep such a big hoard of central bank money on hand. The Bank of England, UK’s central bank, estimates that after installing its LSM in 2013, the amount of liquidity that UK commercial banks required to make payments fell by 20%. So the same amount of business was being conducted over the Bank of England’s large-value payments system, but much less work was being expended to conduct that business.

LSMs have made the financial system safer by encouraging banks to make payments earlier in the day. After all, the quicker that a bank submits a payment to the LSM, the more time it will have to be matched. This is a neat little paradox. Queues, notorious for causing delay, actually speed things up.

Having taken a detour through central bank large-value payments systems, let’s return to the original debate over two-day stock settlement. Sure, stock markets could follow Robinhood’s advice and introduce real-time settlement. But before long, we’d all start to miss the magic of netting. Just as central banks reintroduced delays by building LSMs, stock markets would likely take steps to bring back slow.

If anything, what the central bank RTGS/LSM two-step teaches us is that we need a good balance between fast and slow. Sure, real-time settlement is a nice feature. But let’s also have delayed settlement. If brokerages have a choice to use some combination of two-day and real-time settlement, we may arrive at a socially optimal stock settlement rate.

Does FedNow mean quicker bank runs?

The Federal Reserve is introducing its first instant retail payments system this summer, FedNow. Retail is a catch-all term for small payments made by (and to) regular folks like you and me. Think bill payments, transfers to friends and family, salary, and more. Up till now, the retail crowd hasn't had a Fed-provided instant payments options.

The U.S. is also in the middle of a banking crisis.

Putting a banking crisis together with instant payments, some commentators fear that future U.S. bank runs will proceed even quicker than before.

I don't think so.

A bit of background. Up till now, the Fed's flagship retail payments system has been FedACH. (ACH stands for automated clearinghouse). FedACH is not a real-time system. Historically it has taken a day or two for ACH payments to settle, but even with the recent addition of a "same-day" ACH option, it still takes several hours for funds to land in a recipient's account.

Now that the Fed is building an instant system, the fear is that banking customers can presumably execute a run on their banks much faster than before.

One of the big gaps in this argument is that retail customers are generally sticky. The types of customers most likely to run on their bank are large depositors such as corporations, funds, and wealthy individuals. But these actors have always had Fedwire at their disposal, the Fed's large-value payments system. And Fedwire is already a real-time system; the moment a transaction request is sent to Fedwire, it gets settled. 

So the addition of FedNow to the arsenal of Fed instant payments systems doesn't add much in terms of runnability. Large U.S. depositors have always been able to execute rapid bank exits.

Fedwire closes at nights and on the weekends, though, whereas FedNow will be open 365/24/7. Won't this offer more temporal scope for runs?

I still don't think so. As a payments option for retail customers, FedNow payments will likely be capped, say at $25,000. Limits on the weekend and at night will likely be even lower than that. This is how other real-time systems like UK's Faster Payments have been managed, the idea being to cut down on fraud. If you're a large business with millions deposited in the banking system, a tiny $25,000 aperture isn't going to cut it.

So long story short, FedNow won't speed up bank runs. And that's because it won't serve as an additional exit for the most run-prone bank depositors, who already have Fedwire at their disposal.

The threat of a weekend or midnight bank run only begins when Fedwire itself starts to operate on a 365/24/7 basis. That's just a matter of time. India's large value payments system switched over in 2020; and the U.S. is generally a few years behind India when it comes to payments.

The siren call of T+0, or real-time settlement

The NYSE's clearinghouse in 1898, six years after its founding

Traditional financial systems often get mocked for being slow. In North America, for instance, securities markets have recently switched from T+3 to T+2 settlement. Before, if you sold a stock the cash would only appear in your account three days after the trade—now settlement has been moved to a blazing fast two days. In an age where mail is transmitted in milliseconds, this delay seems terribly old fashioned. Or take automatic clearing house (ACH) payments in the U.S. Earlier this month the ability to make same-day ACH debit payments was rolled out, an improvement over the three or four days they used to take, but still no where near immediate.

The snail-like pace of securities and ACH settlement is often contrasted to real-time settlement, say like how payments using banknotes, coins, or bitcoins are finalized the moment the token leaves ones wallet and enters the destination wallet. Or take real-time gross settlement systems operated by central banks, over which a transfer of balances from one account to the other occurs instantaneously and is irrevocable. In the case of securities settlement, why only go from T+3 to T+2? Why not go straight to T+0?

Don't be beguiled by settlement speed. Slow isn't necessarily a bug—it's often a feature. Imagine the following scenario. You and your friends play poker every day at a cafe. To buy into the game, cash or bitcoins are required. And at the end of each game, cash or bitcoin is paid out to the winners. The problem with this system is that each day all players have to lug a transactions medium to the cafe and back from it—and this involves a sacrifice. Banknotes and coins take up lots of space and can be easily stolen. Like bitcoin, they don't yield interest—so a stream of interest income is being foregone to play poker. Once the game is done, the laborious process of counting out cash and banknotes occurs. In the case of bitcoin, the payouts are costly since each one involves incurring a fee to send bitcoins from one wallet to another.

Participants in financial markets have adopted a time-tested strategy to avoid much of the work involved in repetitive use of transactions media like cash: substitute them with IOUs that are only settled from time-to-time. Returning to the poker example, rather than stumping up cash each game players can buy-in using IOUs denominated in cash or bitcoin. These IOUs are recorded in a ledger. Rather than cashing out at the end of the game each player's balance is held over to the next day, only to be updated subject to that day's results. These ledger balances continue to be updated at the close of each game until after (say) the tenth game, everyone finally decides to settle their accounts, upon which all debtors, or losers, bring cash and/or bitcoin to the cafe to pay off winners, or creditors. The system has settled—not in real-time—but T+10.

The advantage of delayed settlement is that quid pro quo is achieved with one set of transactions conducted at the end of the 10-game cycle rather than a set of transaction for each game. No more tedious counting out coins each day or daily bitcoin fees. Because the obligation to carry around cash is kept to a minimum, interest income needn't be sacrificed by players. Nor are there any nuisances of storing cash.

While slowing down the system reduces the amount of work that must be done, it comes at the expense of flexibility and safety. One of the benefits of a cash payment is that transactions media are immediately available for use in subsequent transactions. If a player can only get cash out of the game after ten games, they will have to be sure that they don't need that cash for other payments in the interim. Slowing down the system also introduces credit risk into the system. Players may be unable or unwilling to honor their IOUs at the end of the cycle. Lengthening the cycle only increases the odds of settlement failure due to insolvency or bankruptcy.

If the benefits that your friends expect to harvest from delaying poker settlement—the reduction in work and fees—outweigh the aforementioned costs, then a T+10 system makes a lot of sense. Keep this in mind whenever you encounter a real-life financial transaction like an ACH payment that takes a long time to settle. The system's sluggishness may be designed that way because the conservation of work and transactions costs outweighs the inconveniences of not having immediate availability of transactions media and exposure to credit risk.

Even the bitcoin ecosystem has adopted various forms of delayed settlement. Thanks to high fees and long wait times, Bitcoin companies have been avoiding direct exchanges of bitcoins among each other in favor of netting out bitcoin-denominated IOUs, says Izabella Kaminska, only settling net amounts after some time has passed. And Bitcoin developers are working towards introducing something called the Lightning Network, which will allow users to make payments using fully-backed bitcoin depository receipts rather than having to settle trades directly on the blockchain using regular (and peskily-slow) bitcoins. 

Let's finish off by revisiting the recent shift from T+3 to T+2 securities settlement in the US and Canada. Interestingly, if you zoom out you'll see that over time the New York Stock Exchange shows a predominant tendency to lengthen the settlement cycle, not shorten it. The recent move to T+2 only brings the exchange back to the same settlement speed at which it operated at from 1933 to 1952. Prior to 1933, next-day settlement, or T+1, had been standard.

The lengthening of the cycle to T+2 in 1933, which corresponded with an increase in stock trading volumes, was implemented to "ease the work" of brokerage clerks. Back then all securities were recorded in physical form, so settlement required the transportation by hand of certificates from one office to another by an army of runners. In the face of growing trade volumes, the only way to maintain T+1 settlement would have been to do much more work, which meant hiring more clerks and runners—costs that would be offloaded onto clients. Slowing down the system to T+2 from T+1 presumably would have kept things cheap.

The 1968 switch to T+5 settlement was an effort to cope with the famous "back office crisis." Investors who were too young to remember the Great Depression had begun to arrive in droves to equity markets in the early-60s. Back office clerks could not keep up with amount of work required to settle trades. At one point the NYSE even closed on Wednesdays to help deal with the backlog.

The recent move back to T+2 means that cash will appear in investors' accounts 24 hours earlier, making it easier for them to meet subsequent payments deadlines. Credit risk is reduced too. Brokers conduct trades with other brokers on behalf of their clients, building up credit and debits over the settlement cycle. The shorter the cycle, the quicker these debts will be unwound by transfers of stock and cash, the resulting savings hopefully flowing through to customers.

Why not go straight to real-time, or T+0? The move from T+3 to T+2 means one less day over which brokers can 'net out' their respective debits and credits so as to conserve on transactions costs. T+0 means no netting-out window whatsoever—and that would impose a terrific amount of work on the system. Like I say, it's a trade-off. Real-time settlement is no panacea.

---

P.S. Here's a great article on the history of securities clearing and settlement: Was Trade Settlement Always on T+3? A History of Clearing and Settlement Changes, by Kenneth Levine (1996)

Another Fedcoin sighting

Early map of Fedwire. Source: FRBNY

The pace of Fedcoin sightings has been accelerating this year. If you're new to this blog, Fedcoin is a catch-all term I like to use for a central bank-issued cryptocurrency. Earlier this month the Federal Reserve itself hosted a conference called Finance in Flux: The Technological Transformation of the Financial Sector. The keynote presentation was given by Adam Ludwin, CEO of blockchain firm Chain Inc, who had some interesting things to say about a central bank digital currency.

A criticism I have of blockchain advocacy in general and Fedcoin in particular is that evangelists tend to understand little of the history or qualities of the institutions that they are trying to overthrow. The result is that they invariably end up mis-estimating the benefits of replacing existing systems with new ones.

For instance, Ludwin calls his presentation Why Central Banks Will Issue Digital Currency, a title that must have got Janet Yellen scratching her head since the Fed has been issuing digital currency, or reserves, for a long time now. A system called Fedwire, one of the most important utilities in the U.S., allows some 9,000 financial institutions to transfer these digital reserves among each other.

Ludwin goes on to provide more details on the sort of blockchain-style digital currency he is promoting:

...I find it more helpful to look back to bearer instruments, like banknotes, to appreciate what this new medium enables: a digital bearer instrument... With bearer instruments the payment is also the settlement. It is one step. This is a neat property of a bearer instrument...The goal of the blockchain industry is to collapse these steps into a single step, where payment is the settlement, just like with physical notes. 

Ok, Ludwin wants not just digital currency but instantly-settled digital currency. But Fedwire already achieves this. In a Fedwire payment between banks, the exchange of reserves constitutes settlement. Put differently, in the same way that a banknote or bitcoin payment involves a single step, a Fedwire payment also involves but one step. Say bank A wants to pay bank B $10,000 in reserves via Fedwire. The moment a bank hits the button to complete the payment, reserves change hands and the transaction is complete. An ensuing clearing process does not need to be initiated, nor does an underlying set of assets need to be mobilized to settle the payment. To top it off, trades cannot be undone. Fedwire payments are final. The moment reserves enter your account, you own them.

Fedwire is what is known as a real-time gross settlement system (RTGS); payments are made in real time and are irrevocable. Most of the world's central banks operate an RTGS. Ludwin's firm is leading the battlecry for central bank blockchains, but the main selling point—that Fedcoin collapses payments into a single step—brings nothing to the table that an RTGS like Fedwire doesn't already provide. So why bother?

Ludwin mentions security. Is he claiming that Fedwire is in any way insecure? Fedwire is a robust system that in 2015 processed 143 million transfers with a total value of $834 trillion. It has been operating without major mishap for decades. He also floats the idea that there will be "perfect clarity around where the asset is at any point in time." I'm sure that the Fed always knows the exact location of each reserve it has ever issued. He also brings up the question of speed. But as I pointed out above, Fedwire payments are instantaneous. In fact, Fedwire would probably be faster than Fedcoin.

As far as I can tell, the only difference between the two networks is that a proposed Fedcoin would be distributed while Fedwire is centralized. What this boils down to is that the Fedcoin network would be maintained by a large number of independent nodes whereas Fedwire is run out of a lone data centre in New Jersey (see my old post here for a map). If you take out a Fedcoin node the remaining nodes will continue to operate the payments network. Destroy Fedwire's New Jersey data centre (and its two back-up locations), however, and the system collapses. Redundancy is great, but is it enough to justify switching from Fedwire to Fedcoin? I'm not convinced.

What about operating costs? If Fedcoin and Fedwire have the same capabilities, but Fedcoin costs half as much  to operate, then an infrastructure switch could make a lot of sense. We know how much it costs for the Fed to process a Fedwire transaction because it publishes a set of fees that is designed to recoup its costs:

Source: Fedwire

A Fedwire transfer can cost as little as 15.5 cents (before incentives) for the Fed to process. So a $100,000 transfer might cost just 0.0002% in fees. That's not much. For comparison sake, the UK-equivalent RTGS—called CHAPS—costs just 16.5 pence per transfer. On a large transaction that's a pittance. Can Fedcoin beat theses costs while providing the same degree of speed and security? I'm not sure, but these are the sorts of questions that an advocate of Fedcoin needs to answer.

It's with small-value payments that Fedwire trips up. Between 1.55% to 7.9% of a $10 Fedwire payment will be eaten up by fees. That's not cheap. Payments of this size are the sort that a retail customer would typically originate, which means Fedwire is not a great retail payments network. If a proposed Fedcoin could bring down the cost of operating a small-value central bank payments than it might help banks serve retail clients. That's a worthwhile use case.

In addition to their RTGSs, central banks typically maintain a retail payments system. While the U.S.'s archaic system ACH is just awful (it takes several days to settle), more recent systems like the UK's Faster Payments Service (FPS) are decent. The drawback to FPS is that it isn't capable of collapsing a payment into a single step, say like Fedcoin or Fedwire. Instead of instantaneous settlement, FPS payments will typically be settled via CHAPS during one of three daily settlement cycles. Three times daily isn't bad, but it's not immediate. However, FPS fees are paltry, running around 3.51 pence per transaction. Even if Fedcoin achieves instantaneous settlement, would it be able to do so at a cost that is competitive with FPS? That's something Fedcoin advocates like Ludwin need to demonstrate before folks like Janet Yellen will make a move into small-value blockchain.

Finally, Ludwin suggests that central banks issue cryptocurrency not only to banks but also to non-bank financial companies, corporations, and individuals. He suggestion is a bit too casual for my taste and it probably made Janet Yellen wince. Central banks have a long tradition of steering wide of competition with banks. If the Fed (or any other central bank) were to begin providing digital money directly to the public, it would be breaking with this tradition; central bank digital tokens would effectively be competing head-to-head with private bank deposits. This would be one of the most momentous policy changes in Federal Reserve history and would have many far-reaching consequences.

Even if the Fed thinks the time is ripe to embark on such a historical path, Ludwin hasn't made the case for the blockchain. Why not just allow individuals to keep accounts at the Federal Reserve and make Fedwire payments via a Fedwire app?

Blockchain technology is cool and interesting and sexy. But I'm not convinced that the old fashioned centralized incumbents like Fedwire aren't up to snuff. I suppose time will tell.

---

PS: I won't be able to answer comments on this till the weekend.