Showing posts with label SWIFT. Show all posts
Showing posts with label SWIFT. Show all posts

Monday, April 28, 2025

Trump-proofing Canada means ending our dependence on SWIFT


It's time to stop staring into the headlights and respond to the fact that Canada is being eyed as a choice morsel by a much larger predator: our former ally the United States of America. In President Trump's very own words, he wants to use "economic force" to join Canada and the United States together. In anticipation of the U.S. turning its economic might against us, we need to locate all the ways in which our access points to various crucial financial networks are controlled by this predator, and switch those dependencies off, quickly, before they are used to hurt us. One of our most glaring dependencies is the SWIFT network.

Banking and payments run on networks. And network users tend to coalesce around a single dominant network, like SWIFT or the Visa and MasterCard networks. Which leaves whomever controls the dominant network, often the U.S, with tremendous power over all the network's other users. If Canada can reduce our exposure to some of these networks now, then we can't be exploited by the Trump regime down the road to weaken us economically, sap our strength, and threaten to take our resources or annex us.

I've already written about one point of failure: our dependency on the U.S.-controlled MasterCard and Visa card networks. Canada has enjoyed huge conveniences by being connected to the U.S. card networks. However, if Trump were to suddenly cut off our access, Canadian credit cards would be rendered ineffective in one stroke, throwing us into chaos.

The good news, I wrote back then, is that our MasterCard/Visa dependency can be solved by building a domestic credit card system, underpinned by Interac, our made-in-Canada interbank debit network. With a domestic fall-back in place, the threat of a Trump disconnection would no longer loom over our heads. Canada wouldn't be doing anything unique. All sorts of nations have their own indigenous credit card systems, including India, Indonesia, Brazil, France, and Japan.

The next chokepoint we need to address, and quickly, is Canada's dependence on the SWIFT network. Most Canadians don’t realize that SWIFT isn't just an international payment tool. It is deeply embedded in our domestic financial system, too.

What is the SWIFT network? Payments are really just synchronized updates of bank databases. A paying bank subtracts numbers from its database while the receiving bank credits its own. To initiate these updates, banks need to communicate with each other, which is where SWIFT comes in. Think of SWIFT as WhatsApp for bankers. It's a highly secure communications network that banks can use to coordinate bank-to-bank payments, otherwise known as wire transfers, between each other on behalf of their customers, using specialized financial languages like ISO 20022 or FIN.

The SWIFT network, owned by the Society for Worldwide Interbank Financial Telecommunication, a non-profit based in Belgium, has over the years become the global standard for banks to signal cross-border database updates. There is currently no alternative. Decades ago, everyone gravitated toward using the SWIFT network for international payments; so that's where a banker has gotta be.

Canada's SWIFT exposure is especially problematic. Many of the world's largest nations only rely on the SWIFT network for international payments; they do not use SWIFT for domestic payments. For security reasons, these nations have built their own bespoke messaging networks and require their banks to use the domestic network for making within-country wires. For example, India has the Structured Financial Messaging System (SFMS), the U.S. uses FedLine*, and Japan has the Zengin Data Telecommunication System.

Yet a group of smaller countries, including Canada, also rely on the SWIFT network for domestic payments. The UK, Australia, and South Africa are part of this group, too. (I wrote about this domestic reliance a few years ago, if you want more details.) What it boils down to is that if a Toronto-based customer of Royal Bank wants to wire $1 million to a Calgary-based customer of TD Bank, it is the SWIFT network that conducts the communications necessary to complete this within-Canada wire payment.

That is, our domestic payment system is fully reliant on a piece of Belgian infrastructure. And this domestic reliance is a huge weakness.

Cutting countries off from SWIFT has become one of the U.S.'s standard tools for disciplining enemies. Over the years North Korea, Iran, and Russia have all undergone it. Being de-SWIFTed isn't a killing blow, but it makes it much tougher for the offending nation's banks to interact with counterparties to make payments. Without SWIFT, bankers fall back on ad hoc networks of fax machines, email, and telex. Efficiency is replaced by clunky, error-prone workarounds.

In 2025, Canada suddenly finds itself in the same boat as North Korea, Iran, and Russia: we are all U.S. targets (or is Russia about to become a U.S. friend again?) And so Canada faces a genuine threat of being de-SWIFTed. Some of you are thinking: "But wait, JP. SWIFT is a European-based platform. As a liberal democracy, Europe is on Canada's side. They would never allow us to be cut off, right?"

Yes and no. The U.S. market is far bigger than the Canadian market. Given a U.S. ultimatum between disconnecting Canada's banking system and facing U.S. punishment, SWIFT and the Europeans may very well choose to take the path of least resistance and cut Canada off.

A potential European betrayal is precisely what happened to Iran when it was severed from SWIFT in 2018. Recall that the U.S., Europe and other partners had signed a nuclear deal with Iran in 2015 whereby Iran agreed to cease its efforts to get the bomb in exchange for a cessation of western sanctions. Trump reneged on the deal in 2018, enraging the Europeans, who wanted to continue honoring it. The U.S.'s 45th president began to pressure SWIFT to remove Iran from its network, threatening sanctions and travel bans on SWIFT execs. At the time, I thought SWIFT might resist Trump's pressure. Europe remained supportive of Iran, after all, and the EU's "blocking statute" makes it illegal for EU firms like SWIFT to comply with American sanction demands. But Europe caved and Iran was quietly unplugged from SWIFT.

In short, Canada, like Iran, can't rely on Europe to uphold its SWIFT access.

As I said earlier, a de-SWIFTing is doubly serious for Canada. Not only would it sever our banks from the sole communications network through which they can make foreign payments. We would also lose our ability to make local wire payments in Canadian dollars. Need to pay $500,000 by wire to close a house purchase? Too bad. It won't go through.

For those interested in visuals, the chart below illustrates our SWIFT dependence. Note how all arrows pass through the SWIFT network:

How a Canadian wire transfer works: When a Canadian bank (i.e. the "instructing agent") makes a wire payment to another Canadian bank (the "instructed agent") on behalf of a customer, it starts by initiating a PACS message. This message is sent to the SWIFT network, which notifies Lynx, Canada's high value payments system. All Canadian banks have accounts at the Bank of Canada, our nation's central bank. Lynx's role is to debit the central bank account of the first bank and credit the account of the second bank. A confirmation message then flows back from Lynx to SWIFT and on to the recipient bank. SWIFT is central to this entire flow. All arrow lead to or away from it. If SWIFT is no longer permitted to bridge Canadian banks and Lynx because of a Trump ban, then this entire payments flow ceases to function. Image source: Payments Canada

While we can't do much about losing access to SWIFT's international payments services, we do have options for mitigating the effects of lost access on local transactions. Canada must build its own proprietary domestic financial messaging network — urgently. For argument's sake I'll call it MapleFIN. Once built, the government could require domestic banks like BMO and TD Bank to support MapleFIN along with the existing SWIFT option, giving financial institutions two routes for passing on financial messages to other Canadian banks. Then if we are threatened with a de-SWIFTing, at least our domestic payments system won't be paralyzed; we can fall back on MapleFIN.

The oddest thing for me about the sudden emergence of the U.S. threat is that I've been looking to bad actors like Russia and Iran for inspiration on how Canada must harden itself. Like Canada, Russia was historically dependent on the SWIFT network for "almost all" domestic transactions. For many years it had no domestic financial messaging system. Then Russia unjustly invaded Crimea in 2014. It was only at that point that, realizing its vulnerability, the rogue nation belatedly built its own domestic messaging network: the Sistema peredachi finansovykh soobscheniy, or System for Transfer of Financial Messages (SPFS). When Russia's banks finally began to be de-SWIFTed in 2022, they were cut off from making cross-border payments, but at least they could fall back on SPFS for making domestic payments, saving its economy from all sorts of extra chaos.

Iran, too, has its own domestic financial messaging system, having introduced SEPAM in 2013, so when Trump's 2018 de-SWIFTing hit, at least Iran's domestic payments still went through.

We need to do what Russia and Iran did and build domestic payments networks.

A recent design change by the European Union really drives home the point that no nation should be 100% reliant on SWIFT. Like Canada, the EU has always used SWIFT for all of its domestic financial messaging traffic. SWIFT is based in the EU, so you'd think that Europeans would be comfortable being wholly dependent on it. But they aren't. In 2023, European Central Bank modified the domestic payments system so that in addition to SWIFT, banks could also transmit payment messages via a non-SWIFT competitor, SIAnet. (I wrote two articles, here and here, on Europe's decision to reduce its SWIFT reliance).

I worry that many Canadians are still stuck in the early stages of coping with the loss of our privileged relationship with the U.S. There's plenty of anger and betrayal. Many are in denial and think things will return to normal once Trump's regime comes to an end, assuming it ever does. But if we want to safeguard our economy against the years of instability ahead, we can't just stew. We need to accept that things have changed and quickly move forward to mitigate the threat. Financial messaging systems are not irrelevant bits of financial arcanery. They are a vital part of Canada's plumbing through which a large chunk of the nation's commerce flows. If the plumbing seizes up, our financial lives go on pause. Let's fix this, now.


*The Federal Reserve used to refer to its network as FedNet, but appears to have switched its nomenclature to FedLine.

Saturday, December 28, 2024

Someone is wrong on the internet about the SWIFT network

There's a chart that has been circulating for a while now on social media that shows payments traffic on SWIFT, a key global financial messaging network. Below is a version from the Economist, but I've seen other versions too.

Source: The Economist

When banks make cross-border payments between each other, say euros to dollars, they need to use a communications network to coordinate the debiting and crediting of accounts, and SWIFT is the dominant network for doing so. Think of it as WhatsApp for banks.

Here's the problem. The main conclusion that pundits are taking away from the chart is the wrong one. Most of them seem to think that the chart illustrates an erosion in the euro's global popularity (i.e. de-euroization) and a simultaneous move towards the dollar for global trade. The Economist, which entitles its chart "Dollarisation," is also guilty.

Today I'm going to show you why that's the wrong conclusion; there is no SWIFT-related de-euroization. The reason for going through this effort isn't just because it's fun to dunk on wrong folks. It can also teach us some interesting things about the massive bits of unsung payments infrastructure that underlie our global economy, including not only SWIFT but also Europe's T2 and the U.S.'s Fedwire, two of the world's busiest financial utilities.

Let's dig in. The problem with trying to analyze charts of SWIFT messages across various currency jurisdictions is the data isn't necessarily comparable. As I said at the outset, commercial banks around the world use SWIFT to coordinate cross-border payments with other banks, and that is what people are hoping to measure with the SWIFT chart at top. But muddying the waters is the fact that in the EU, banks also use SWIFT for domestic payments. Here's how:

The most important bit of payments infrastructure in both the U.S. and EU are their respective central bank's large-value payments (or settlement) systems. When commercial banks make crucial domestic payments with each other, typically on behalf of their customers, these payments are settled in real-time using each commercial banks' respective account at their central bank, in the U.S.'s case the Federal Reserve, and in Europe's case the European Central bank, or ECB. The ECB's mechanism for settling payments is known as T2 (and previous to that, Target2.) The Fed uses Fedwire.

To coordinate this "dance of databases," the central bank and participating commercial banks need to communicate clearly and rapidly with each other, and that's where financial messaging networks come in. Fedwire doesn't use SWIFT for this. It comes fitted-out with its own proprietary messaging network for member banks. But the ECB has chosen a different setup. Up until 2023 the ECB had outsourced all messaging to SWIFT, a bank-owned cooperative based in Belgium.

Now you may be able to see why comparing the amount of euro payments made using SWIFT messages to dollar payments made using SWIFT is an apples to oranges comparison. Both data sets include cross-border payments, but the EU dataset also includes a large amount of domestic payments. The U.S. dataset doesn't.

This means that the variations in the amount of euro payments messages that get captured in the chart at top may not reflect dramatic geopolitical shifts like "de-euroization, but may be linked to more banal things like changes in local EU payments habits. And indeed, I'm going to show why domestic and not international factors explain the 2023 drop in the euro share of SWIFT messages. 

In 2023, the ECB replaced its Target2 settlement system with a new system called T2. Two key upgrades were introduced with T2 that ultimately affected SWIFT message flows. 

The first of the upgrades was a new language for constructing messages, with the ISO 20022 messaging standard replacing the legacy MT messaging format. (I wrote about ISO 20022 in an article entitled The Standard About to Revolutionize Payments.) 

This change in payments lingo has had a big effect on the sum of SWIFT data displayed in the chart at top. Both the ECB and SWIFT provide explanations for this, but here is my shorter summary. Prior to the 2023 changeover, a type of euro payment known as a liquidity transfer was regularly captured in the SWIFT chart. A liquidity transfer occurs when a European commercial bank, which often has several accounts at the ECB, must rebalance between its accounts when one of them is running low. These within-bank liquidity transfer messages aren't terribly interesting and have nothing to do with global payments, but were included in the SWIFT dataset nonetheless up until 2023, thus fudging the results. 

With the arrival of ISO 20022, messages related to euro liquidity transfers are now conveyed using a new type of message. Thus the big decline in the euro's share of SWIFT messages in 2023  liquidity transfers have effectively dropped out of the chart. This is a good thing, though, since the omission of these relatively unimportant within-bank transfers means we're getting a cleaner and more accurate signal.

The second upgrade introduced in 2023 was the opportunity for European commercial banks to choose among multiple messaging networks for accessing T2. Under T2's predecessor, Target2, banks only had one access choice: the SWIFT network. With T2, European banks can also use SIAnet, owned by the Nexi Group. (I wrote about this upgrade here, in which I described T2's switch from an older Y-copy topology to a network agnostic V-shaped topology.)

In that older post, I suggested that adding additional access points was a healthy step for Europe, since it meant more resilience should one network suffer an outage. And in fact, Europe is already reaping the benefits. When SWIFT failed for several hours on July 18, 2024, the ECB issued the following alert:

"T2 is operating normally. However, due to an ongoing SWIFT issue, some incoming messages do not reach T2 immediately. Similarly, some T2 outgoing messages might not reach the receiver immediately... There is no impact on traffic sent or received via NEXI. Participants may continue sending new instructions and queries to CLM/RTGS/CRDM. Updated information will be provided at the latest by 16:30."

Whereas an outage of SWIFT in 2021 or 2022 would have seriously slowed down Europe's financial activity, the addition of Nexi's SIAnet to the mix in 2023 limited the damage caused by the 2024 SWIFT outage. By contrast, the UK's central bank, the Bank of England, remains entirely reliant on SWIFT for messaging, and so the 2024 outage caused more disruption for Brits than Europeans, according to the Financial Times.

Unfortunately, I can't find any data on how many European banks have actually chosen to shift their T2 messaging needs over to Nexi. But I'd imagine that it isn't negligible, given that Nexi's SIANet is already being used by banks to access other key bits of Europe's payments architecture including STEP2, a pan-European automated clearinghouse. And so some non-negligible portion of the drop in the euro's share of SWIFT messages in the top chart is due to a shift away from SWIFT.

If the SWIFT chart at top doesn't mean what people think it means, what is the euro's status as a global trading currency? A 2024 article from the ECB clears this up. In short, the euro's international role hasn't eroded over the last few years. The de-euroization memes are all wrong.

The irony of all of this is that rather than reflecting a decline in Europe's status, the SWIFT chart illustrates the opposite. A bunch of healthy advances are driving the euro's share of SWIFT payments down, including a more accurate classification of financial messaging data thanks to a better messaging language, combined with a much needed de-SWIFTication of European messaging flows. It's not as juicy as euro critics make it out to be.

Tuesday, November 28, 2023

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.

Thursday, August 17, 2023

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.

Monday, July 12, 2021

Those 70s ACH payments

Here is Facebook's David Marcus, who has been involved in rolling out Facebook's much-touted Libra/Novi/Diem payments system:

By ACH, Marcus is referring to automated clearinghouse payments. If you want to pay your phone bill, the payment gets sent to a clearing house, which batches your payment together with many other payments and then settles it the next day. These systems were built in the 60s and 70s.

I don't want to pick on Marcus, since he isn't the only one with this view. But modern money no longer moves at the pace of early 70s ACH. His critique would have made sense maybe 6 or 7 years ago, and only in the US. But that's not the case in 2021.

The speeding up of modern payments is a great success story. Let me tell you a bit about it.

To begin with, central banks and other public clearinghouses have spent the last 15-or-so years blanketing the globe with real-time retail payments systems. Europe has TIPS, UK has Faster Payments, India has IMPS, Sweden has BiR, Singapore FAST. There must be at least thirty or forty of these real-time retail payments system by now. 

The speed of these new platforms get passed on to the public by banks and fintechs, which are themselves connected to these core systems. In the UK's case, for example, consumers can bypass the slower ACH system, BACS, which takes three days to settle, by choosing to make their bank payment proceed via the Faster Payments system.

The U.S. is lagging. The Federal Reserve's FedNow retail payment system, which will facilitate real-time retail payments, won't be in place till 2024, more than 15 years after UK's Faster Payments was introduced. So Marcus's tweet could just be a function of having a U.S.-centric viewpoint.

However, the Fed's private competitor, The Clearing House, has had a real-time settlement system in place since 2017, the Real-Time Payments (RTP) network. Roll-out has been slow, but as of July 2021 The Clearing House claims that RTP reaches 56% of U.S. checking accounts. 

RTP illustrates that it's not just central banks that are facilitating real-time payments. Private players are too. Visa and MasterCard, for instance, built their own proprietary real-time person-to-person payments platforms, Visa Direct and MasterCard Send, on the back of their debit card networks.

As Arturo Portilla points out, Visa Direct and MasterCard Send don't actually settle payments in real-time. They only clear them. From the perspective of the consumer, however, it makes little difference. Ned can send Jenny $100 using a Visa Direct enabled account, and Jenny can then spend that $100 within moments of receiving it. (Ned and Jenny's banks settle up the next day.)

In 2017 U.S. banks debuted Zelle, a now ubiquitous instant person-to-person bank payments option. Zelle was built using the Visa Direct and MasterCard Send networks. And now Zelle is being connected to The Clearing House's RTP network, too. Which means that settlement can be done in real-time.

Perhaps Marcus's ACH critique is limited to non-domestic transactions. But even cross-border payments are also going quicker.

Remittance companies like Western Union and MoneyGram are leveraging Visa Direct and MasterCard Send to do instant cross-border transfers. As of late 2020, Western Union was facilitating real-time payouts to 80 countries. MoneyGram recently announced that 575 corridors from 25 countries in Europe would go instant thanks to an integration with Visa Direct, complementing its existing instant payments options from the US.

Transferwise, another global remittance company, is dispatching up to 38% of its remittances instantly. Whereas Western Union and MoneyGram are building on top of Visa Direct and MasterCard Send, my understanding is that most of Transferwise's success in speeding up remittances comes from integrating with the new retail real-time payments systems I listed above, like Singapore's FAST and UK's Faster Payments.

Let's not forget SWIFT gpi, which is bringing a new speed standard to corporate cross-border payments.

Even the ACH network that Marcus criticizes is upping its game. ACH payments have typically not settled till a day or two after origination, which meant consumers have had to wait for salaries and bill payments to settle. But in 2017, same-day ACH was introduced. It's taken some time for this option to gain adoption. As of the first quarter of 2021, only 2% of all ACH transactions are done on a same-day basis.


But same-day ACH is getting better. In 2020, the limit for same-day payments was raised from $25,000 to $100,000. Just this year a third window for clearing and settling same-day ACH payments was introduced, 6:30 PM EST, making same-day ACH even more convenient for Californians and others in later time zones. Next year, limits will be raised from $100,000 to $1 million.

Lastly, Marcus maligns slow in his tweet. But remember, slow can be a good thing, too. Slowing down transactions allows us to batch them together and cancel out reciprocating payments, thus reducing the amount of work our payments systems must do. And this makes our payments systems cheaper. (I've written two articles on this topic, here and here.)

The ideal payments ecosystem isn't slow or fast. It provides a combination of slow, medium, and fast options. The Libra/Diem/Novi project project that David Marcus is working on will fit in somewhere on this spectrum. The more options, the better off are consumers. But 70s ACH is no longer a very realistic way to describe modern money.

Tuesday, February 11, 2020

Cutting Martin Sellner off from the payments system


I few weeks back I learned who Martin Sellner is. If you haven't heard of him, Sellner is a prominent Austrian populizer of remigration, the idea that non-whites living in Western nations should be sent back to where they come from.

In a recent tweet from his wife, Brittany Sellner, we find out that Sellner has been kicked off of by a long list of banks and payments platforms.

The companies that are accused of removing Sellner include German bitcoin exchange Bitpanda, a number of European banks, and payments processors PayPal and Stripe.

Should we support efforts to stop prominent remigrationists from making payments? It's a tricky question, one I've touched on before. What should be the ground rules for removing individuals with views like Sellner's from payments platforms? 

A bit of background first. Sellner isn't your typical advocate for the forced repatriation of ethnic minorities. He doesn't walk around with a shaved head or a swastika tattoos. He's personable, clean cut, well-dressed, social media savvy, and suave.

Sellner and his fellow Identitarians, the group to which he belongs, distance themselves from predecessor groups who have espoused versions of remigration, say like the neo-Nazis. Identitarians do not advocate racial superiority, hate, or violence. "We respect other cultures, we don't hate different cultures, we just want to preserve our own culture," says Sellner in this video.

To help spread ideas like remigration, Sellner has pulled off a number of stunts. These include crashing a theatrical piece in which all the actors were refugees and hiring a boat to sail the Mediterranean and harass NGOs that are helping boat people.

Although Sellner says that he respects other cultures and doesn't advocate hate, this doesn't square with the fact that any remigration would be an incredibly violent event. "I don't hate you. I respect your culture. I just want to kick you out of the country." What an incongruent set of beliefs!

How might remigration play out? Let's imagine how it would work in my home town of Montreal. (Yep, Quebec has its own Identitarian branch). Many Montrealers are members of a visible minority, including those of Middle Eastern, North African, West African, Latin American, and Asian descent. Laws would have to be struck down so that these people's citizenship could be revoked. Even the most despicable Canadians haven't been treated this way (think Luka Magnotta or Paul Bernardo).

Next, these new non-citizens would be rounded up and interned. Then they'd be sent down to the Old Port and shipped out by ocean freighter. Those who didn't leave peacefully would be hunted down, maybe shot. Any whites who helped them would become criminals. Whole neighbourhoods would be denuded of their population. Businesses across Montreal would suddenly cease to exist. Mixed-race families would be torn apart. It would be awful. 

Remigration is a violent idea. But at the same time, removing someone like Martin Sellner from the payments system is no small matter. Like garbage disposal service, or running water, or electricity, the ability to make payments is a necessity. If folks like Martin Sellner can't pay, they can't live.

The water utility generally won't sever the neighbourhood asshole's connection just because he's being unpleasant. Likewise, as long as Sellner isn't doing anything explicitly illegal, should he not be able to get access to basic payments services? If access to electricity, water, and garbage disposal services are all apolitical, maybe the same should apply to payments.

-------

I'd suggest the following way to referee this conflict.

We can think of the payment system as being comprised of backbones and onramps. A backbone is a shared piece of financial infrastructure across which a nation's payments/payments information flows. Any given country will have just a handful of payments backbones. Each one of them processes a huge amount of economic value.

For instance, one of the key American payments backbones is Fedwire, a large-value payments system operated by the Federal Reserve. In Europe the equivalent is Target2. In Canada it is LVTS. You probably haven't heard of these utilities. But they are vital to every one of us. Every time we want to make a payment, we are (ultimately) using one of these giant but unknown pieces of financial infrastructure. The utility bill you paid from your bank account last week? It was settled on Fedwire (or Target2 or LVTS).

Banks act as onramps to these backbones. Your account at the State Bank of Toledo, for instance, is your means for accessing Fedwire. Vancouver City Savings Credit Union is your gateway to Canada's LVTS.

Whereas the list of payments backbones is short, the list of onramps is long. There are 4,700 banks in the U.S. Which means there are 4,700 access points. In Europe, there are 1,056 financial institutions that directly participate in Target2. Canada has fewer banks, around 90.

Banks aren't the only type of onramp. Non-bank financial institutions and fintech firms provide indirect access to Fedwire and Target2. PayPal, for instance, is a popular way to make payments, but it doesn't actually hold customer deposits or have access to Fedwire. Rather, all customer funds are custodied at JP Morgan, PayPal's banker. So PayPal account owners get access to Fedwire via JP Morgan.

I'd argue that backbones like Fedwire and Target2 should not be allowed to block Martin Sellner. So if an onramp sends Sellner's utility bill payments or his donations to be processed by a backbone, that backbone shouldn't censor those transactions.

Onramps, however, should be able to choose if they want to serve Martin Sellner or not.

Onramps like banks will often specialize in building up expertise in serving a certain set of customers (i.e. some banks may cater to business customers rather than individuals). Or they may have designed their brands to attract a wide range of customers and employees. Connecting Martin Sellner may not be consistent with an onramp's expertise. Sellner is a risky client, after all, one who has received payments from terrorists. A bank that lacks the ability to closely monitor his transactions should be free to ask him to leave.

Sellner may also threaten the onramp's brand. By connecting Sellner, the onramp could be damaging  its relationship to the rest of its customers, or put the onramp's commitment to its employees, many of whom may be visible minorities, at risk. Onramps should be free to protect their brands from being associated with remigrationists.

As I said, onramps are plentiful. While it might be a nuissance to be cut off by one of them, Martin Sellner will always be able to find an alternative payments provider. If not, he and others like him might consider starting their own onramp, say an Identitarian bank or First Amendment Payment Processing.

The same logic doesn't apply to backbones. Because backbones are often set up as government-enforced monopolies, anyone who has been denied access will have no other option for making payments.

Backbones aren't solely creatures of government monopoly. Strong market forces push everyone to use the existing shared payments infrastructure. The privately-owned Visa and MasterCard networks, for instance, are incredibly useful because everyone is already connected to them. A new competing card backbone can only become useful by attracting a large base of card users, but it can't attract this user base if it isn't already useful. This chicken & egg problem is incredibly difficult to solve. And so we tend to congregate around a few central payments hubs.

I think it would be dangerous to start regulating access to payments backbones such as Visa or Fedwire on the basis of moral fitness. The core service that a payment backbone provides—universal financial connectivity—is as important as water or electricity. Excluding someone from any of these systems could potentially kill them. We may not like Sellner's ideas, but don't forget that he's a human.

Once we start trying to rid ourselves of the world's Martin Sellners, we risk politicizing the entire backbone layer of the payments system. Other people who aren't so threatening could end up getting exiled simply simply because they are unpopular or different.

I'm far less worried about exclusion at the onramp level of the payments system. Even if PayPal or Bank Austria won't connect Martin Sellner, another onramp will. This doesn't mean that prominent remigrationists get off scot-free. They will end up atoning for the violence of their ideas by having to endure a constant stream of of inconvenient and embarrassing disconnections and reconnections.

-------

Which gets us back to the original tweet. The list of institutions that have disconnected Sellner is comprised solely of onramps. Not a single backbone (Target2, Visa, MasterCard, SWIFT) has removed him. I'd say that these results abide by the rough set of rules set out in this post: onramps, not backbones. So far, the cutting off of Martin Sellner has been a fair one.

And while being cutoff by PayPal, Stripe, and a few banks has no doubt been a pain for Sellner, there are still several onramps that continue to serve him. On his website, Sellner accepts donations to the following IBAN account number HU85117753795858688200000000. A quick search shows that this account is held at Hungary-based OTP Bank.

Donors can also pay him via SubscribeStar, a subscription-based crowdfunding platform. (Presumably he added SubscribeStar after being cutoff by Patreon, the more mainstream alternative.)

Sellner also accepts cryptocurrency donations using a Coinbase Commerce button:

Screenshot of Sellner's website from February 10, 2020

Coinbase is one of the worlds largest cryptocurrency exchanges. The Coinbase tool that Sellner is using on his site provides a relatively painless way for merchants to receive cryptocurrency payments. Using Internet Archive's Wayback Machine, I see that while Sellner has been accepting cryptocurrency for some time now, but he only recently upgraded his cryptocurrency payments option to Coinbase Commerce.

Coinbase describes itself as an "open financial system for the world". Perhaps serving Martin Sellner is not inconsistent with this philosophy. "Coinbase provides payments services to everyone, remigrationists or not." On the other hand, Coinbase's mission statement also includes the goal of "bringing about more economic freedom... and equality of opportunity in the world." Remigration is certainly not about economic freedom or equality. It is about destroying it.

A quick glance through Coinbase Commerce's terms of service specifies that an account cannot be used in ways that are
"threatening, intimidating, harassing, hateful, racially, or ethnically offensive, or instigate or encourage conduct that would be illegal, or otherwise inappropriate, including promoting violent crimes."
Sellner himself may be as gentle as a dove, but the idea his is promoting—remigration—isn't. One wonders why Coinbase has agreed to do business with him.

Thursday, August 23, 2018

Europe's SWIFT problem

SWIFT headquarters in Belgium (source)

German foreign minister Heiko Maas recently penned an article in which he said that "it’s essential that we strengthen European autonomy by establishing payment channels that are independent of the US, creating a European Monetary Fund and building up an independent Swift system."

So what exactly is Maas's quibble with SWIFT, the Society for Worldwide Interbank Financial Telecommunication? SWIFT is a proprietary messaging system that banks can use communicate information about cross border payments. This November, U.S. President Trump has threatened to impose sanctions on SWIFT if it doesn't remove a set of Iranian banks from the SWIFT directory.

For Heiko Maas, this is a problem. Iran and Germany remain signatories to the same nuclear deal that Trump reneged on earlier this year. The deal committed Iran to cutting back its uranium enrichment program and allowing foreign inspectors access to nuclear sites, in return obligating signatories like Germany to normalize economic relations with Iran, including allowing the unrestricted sale of oil. If Iran is bumped from SWIFT, it could prevent Germany from meeting its side of the deal, potentially scuppering the whole thing. So a fully functioning SWIFT, one that can't be manipulated by foreign bullies, is key to Germany meeting its current foreign policy goals.

SWIFT is vital because it is a universal standard. If I want to send you $10,000 from my bank in Canada to your bank in Singapore to pay for services rendered, bank employees will use SWIFT terminals and codes to communicate how to manipulate the various bank ledgers involved in the transaction. If a bank has been banished from SWIFT, then it can no longer use what is effectively a universal banker's language for making money smoothly flow across borders.

It would be as-if you were at a party but unlike all the other party-goers were prohibited from using words to communicate. Sure, you could get your points across through hand gestures and stick drawings, but people would find conversing with you to be tiring and might prefer to avoid you. Without access to SWIFT, Iranian banks will be in the same situation as the mute party-goer. Sure, they can always use other types of communication like email, telex or fax to convey banking instructions, but these would be cumbersome since they would require counterparties to learn a new and clunky process, and they wouldn't necessarily be secure.

It seems odd that Maas is complaining about SWIFT's independence given that it is located in Belgium, which is home territory. But Trump, who is on the other side of the Atlantic, can still influence the network. The way that he plans to bend SWIFT to his will is by threatening members of its board with potential asset expropriations, criminal charges, travel bans, as well as punishing the companies they work for by restricting them from conducting business in the U.S.

How credible is this threat? As I pointed out here...

...SWIFT's board is made up of executives from twenty-five of the world's largest banks, including two Americans: Citigroup's Yawar Shah and J.P Morgan's Emma Loftus. No matter how erratic and silly he is, I really can't imagine Trump following up on his threat. Would he ban all twenty-five banks, including Citigroup and J.P. Morgan, from doing business in the U.S.? Not a chance, that would decimate the global banking system and the U.S. along with it. Requiring U.S. banks do stop using SWIFT would be equally foolish. Would he risk ridicule by putting two American bank executives—Shah and Loftus—under house arrest for non-compliance? I doubt it.     

No, the SWIFT board is TBTP, or too-big-to-be-punished. But even if Trump's threat is not a credible one, surely SWIFT will fall in line anyways. Large international businesses generally comply with the requests of governments, especially the American one. But there's a kicker. European law prohibits European businesses from complying with foreign sanctions unless the have secured EU permission to do so. This leaves SWIFT in an awfully tight place. Which of the two jurisdictions' laws will it choose to break? Assuming it can't get EU permission to comply with U.S. sanctions, then it can either illegally comply with U.S. law, or it can legally contravene U.S. laws. Either way, something has to give.  

Europe can win this battle, a point that Axel Hellman makes for Al-Monitor. After all, SWIFT is located in Belgium, not New York, and jurisdiction over SWIFT surely trumps lack of jurisdiction. Indeed, on its website SWIFT says that its policy is to defer to the EU on these matters:
"Whilst sanctions are imposed independently in different jurisdictions around the world, SWIFT cannot arbitrarily choose which jurisdiction’s sanction regime to follow. Being incorporated under Belgian law it must instead comply with related EU regulation, as confirmed by the Belgian government."
Consider too that SWIFT itself is supposed to be committed to a policy of non-censorship. Chairman Yawar Shah once said that “neutrality is in SWIFT’s DNA.” So from an ideological perspective it would seem that SWIFT would be aligned with Europe's more inclusive stance.

Of course, SWIFT's stated commitment to neutrality conflicts with the fact that it has banned Iran from the network before. In early 2012, U.S. pressure on SWIFT grew in the form of proposed legislation that would punish the messaging provider should it fail to ban Iranian users. SWIFT prevaricated, noting in early February that it would await the "right multilateral legal framework" before acting. In March 2012, the EU Council passed a resolution prohibiting financial messaging providers from servicing Iranian banks, upon which SWIFT disconnected them. It was only in 2015, after passage of the nuclear deal, that SWIFT reconnected Iran. (I get this timeline from the very readable Routledge Global Institutions book on SWIFT, by Suzan Scott and Markos Zachariadis).

The takeaway here is that SWIFT only severed Iranian banks in response to European regulations, in turn a product of a conversation between American and European leaders. SWIFT will seemingly compromise its neutrality if there is a sufficient level of global agreement on the issue followed up by a European directive, not an American one.

If Heiko Maas wants an "independent SWIFT," the above analysis would seem to illustrate that he already has it. Thanks to its European backstop, SWIFT is already independent enough to say no to U.S. bullying. As long as they are willing, European officials can force a showdown over SWIFT that they are destined to win, thus helping to preserve the Iranian nuclear deal.

But maybe European officials don't want to go down this potentially contentious path. Perhaps they would prefer to preserve the peace and grant SWIFT an exemption that allows the organization to comply with U.S. sanctions, thus cutting Iran off from the messaging network, while trying to cobble together some sort of alternative messaging system in order to salvage the nuclear deal. Maybe this alternative is what Maas is referring to when he talks of a building an "independent SWIFT."

An alternative messaging service would have to be capable of providing bankers with sufficient usability so that Iranian oil sales can proceed fluidly. In a recent paper, Esfandyar Batmanghelidj and Axel Hellman give some clues into what this system would look like. During the previous SWIFT ban, several European banks were able to maintain their relationships with Iranian financial institutions by using "ad hoc messaging systems." These ad hoc solutions could be revived, note Batmanghelidj and Hellman.

Using this ad hoc system, so-called gateway banks—those that have both access to the ECB's large value payments system Target2 and limited exposure to the U.S. financial system—would conduct euro transactions on behalf of buyers and sellers of Iranian oil. Since presumably only a few gateways would be necessary to conduct this trade, it would be relatively painless for them to learn the new messaging language and the set of processes involved. For instance, instead of using SWIFT bank identifier codes to indicate account numbers, Batmanghelidj and Hellman point to the possibility of using IBAN numbers, an entirely different international standard.

This independent ad-hoc system would probably work, on the condition that the European monetary authorities continue providing gateway banks that serve Iranian clients with access to the ECB's Target2 payments system. This is a point I stressed in my previous blog post. It isn't access to SWIFT that is the lynchpin of the nuclear deal, it is access to European central banks. But as long as folks like Heiko Maas get their way, I don't see why this sponsorship wouldn't be forthcoming. In response, Trump could always try to sanction the European central bank(s) that allow this ad-hoc system to continue. But an escalation of U.S. bullying from the mere corporate level (i.e. SWIFT) to the level of a friendly sovereign nation would constitute an even more nutty policy. I just don't see it happening.

At stake here is something far larger than just Iran. As I recently wrote for the Sound Money project, financial inclusion is a principle worth fighting for. If one bully can unilaterally ban Iran from the global payments system, who is to say the next victim won't be Canada, or Qatar, or Russia, or  China? Europe needs to stand up to the U.S. on this battle, either by forcing a SWIFT showdown or by sponsoring an ad hoc alternative—not because Iran is an angel—but because we need censorship resistant financial utilities.

Friday, June 8, 2018

Evading the next Iranian monetary blockade

Network view of cross-border banking, IMF, Minoiu and Reyes (2011) PDF

I recently blogged at Bullionstar on the topic of the upcoming Iranian monetary blockade.

Many years ago when I was taking a political science class at university, I remember the professor teaching us two criticisms of sanctions. The first is that they don't really work—people can always get around them. And secondly, even if they are so tight that they can't be evaded, sanctions don't change the behaviour of the party being sanctioned.

The Iranian monetary blockade that ran from 2010-2015 seemed to contradict both of these claims. The sanctions were very difficult to evade. And they forced Iran to come to the bargaining table and agree to end their nuclear program in exchange for economic relief. According to the International Atomic Energy Agency, Iran has complied with its promise.

The Trump administration has announced that it is reneging on the nuclear deal and re-imposing sanctions in order to force Iran to agree to a new and stricter terms. Most nations who were signatories remain comfortable with the existing deal. Will the next monetary blockade—the Trump blockade—be as effective as the last one? There's a good chance that it won't.

I refer to Iran sanctions as a monetary blockade because the U.S. banking system is being levered to extract concessions from the rest of the world. Think how large retailers like Walmart force suppliers to sign exclusivity agreements, or face the threat of being cutoff from store shelves. Do business with us, or them, but not both! Suppliers often accept these exclusivity agreements because large retailers like Walmart are too big to abandon.

The U.S.'s first monetary blockade, which ran from 2010-2015, worked along the same principles. Foreign banks in places like Europe were free to continue providing transactions services to Iran, but if they did so they would not be able to maintain correspondent accounts at U.S. banks. To ensure these rules were enforced, U.S. banks were to be fined and U.S. bank executives incarcerated if found guilty of providing accounts to offenders. Fearful bank executives were very quick to comply by carefully vetting those that they offered correspondent banking services to.

Having a U.S. correspondent account is very important to a non-US bank. If a European bank has a corporate customer who wants to make a U.S. dollar payment, the bank's correspondent relationship with a U.S. bank allows it to effect that payment. Since the revenues from U.S. dollar payments far exceeds revenues from providing Iranian agencies and corporations with payments services, a typical European bank would have had no choice but to abandon Iran in order to keep its U.S. correspondent account.

This was a very effective tool. With ever fewer foreign banks willing to facilitate Iranian trade, it became tougher for Iran to sell its lifeblood: crude oil. Lacking hard currency, Iran suffered from shortages of vital foreign products including medicine and refined oil products. After enduring much hardship, it finally gave in.   

So let's get to the fun bit: can Trump's monetary blockade be evaded?

That hinges on what happens in Europe. The euro, after all, is the world's second-most important medium of exchange. Let's say that Europe is committed to the existing Iran deal. Which means it will have to continue to facilitate Iranian trade in exchange for Iranian nuclear compliance. But how to facilitate this trade when no European bank wants to open accounts for Iranian businesses out of fear of losing access to the U.S. payments system?

One scheme would be to set up a single sanctions-remote bank that conducts all Iranian business. To defang the U.S. Treasury's threat "do business with us, or them, but not both!", this bank should not be dependent on U.S. dollar business. Without a U.S. correspondent, the Treasury's threat to disconnect it from the correspondent network packs no punch. A private European bank that already specializes in Iran business, say like  Hamburg-based Europäisch-Iranische Handelsbank AG, could serve as the sanctions-remote bank. Alternatively, a newly-created government bank that focuses only on Iranian transactions might fill the role.

Let's assume Europäisch-Iranische Handelsbank (EIH) is chosen. Iranian companies that sell crude could open accounts at EIH. How would they get paid? Like other European banks, EIH has a settlement account at the European Central Bank (ECB). Crude oil buyers from all over Europe could have their banks wire payments to EIH's account via the ECB's large value payments sytem, Target2. EIH could also open accounts for companies in India, China, and elsewhere who want to buy Iranian crude oil with euros. In this way, Europäisch-Iranische Handelsbank could theoretically process payments for every drop of Iranian crude, via Target2, and the U.S. Treasury's banking dragnet could do nothing to stop this.

The U.S. could always impose travel bans on EIH bank officials and freeze their U.S. assets. That would surely be annoying, but it wouldn't be decisive. I remember the officials of Canadian-based Sherritt being subject to these sorts of bans many years ago because they did business in Cuba—yet Sherritt gamely trudged on.

Screenshot of Europäisch-Iranische Handelsbank's website. "We are open for business."

There is also the extreme possibility that the U.S. would impose travel bans on the ECB itself, in an effort to force ECB officials to remove Europäisch-Iranische Handelsbank from Target2. Here is one such threat: "Treasury this week designated the governor of Iran's central bank—does any European country think Treasury can't designate their own central bank governor too?" Look, the idea of preventing Mario Draghi from travelling to the U.S., or blocking his U.S. assets, sounds so unhinged that it's not even worth entertaining.

So why was Europäisch-Iranische Handelsbank not used as a sanctions-remote bank during the last monetary blockade? In short, the EU wouldn't allow it. In 2011, it decided to impose its own sanctions on the bank that resulted in EIH's bank accounts being frozen, the banning of all new business, and its removal from the SWIFT and Target2 financial communications networks. According to this report, Chancellor Angela Merkel did so at the urging of Obama.

The key point here is that the U.S. was not itself capable of forcing a sanctions-remote EIH to comply—it had to ask European officials to do the dirty work. Back then, this would have been an easy sell. Obama was respected and had a good working relationship with European leaders. The sanctions had been a carefully negotiated effort that had United Nations support, and therefore broad buy-in, including that of the Russians and Chinese. Trump, on the other hand, has chosen to rudely upset the existing consensus rather than carefully gaining the tacit support of other nations. Unlike the last time around, Merkel can't be asked to take one for the team—there is no team. And as Steve Randy Waldman points out, this time Europe and others have a morally and politically defensible grounds for enabling a work-around.

So rather than shutting down its sanction-remote bank like it did last time, Europe may simply turn a blind eye and allow it to stay open, EIH (or some other government-anointed financial institution)  becoming the go-to bank for conducting Iran's worldwide crude oil business. And if Iran has a means for selling its oil, it may be able to ignore Trump. Thus, the success (or not) of Trump's sanctions is ultimately a European policy variable.

Supposing that Europe caves into pressure from Trump, then India or China could also set-up their own sanctions-remote banks. But these would be in rupee or yuan, neither of which has the wide usefulness of the dollar or euro. Realistically, only Europe can engineer a credible resistance. Here's hoping it does.