I hope you have read my FT Alphaville blog of March 1st Iran’s experience signals banning Swift will not work as expected
My overall argument still seems to me entirely correct: blocking access to payments messaging networks is nothing like so important or effective as prohibition of payments themselves. Indeed I did not highlight enough one big concern: blocking payments messaging does little to prevent the largest value payments getting through;
and I made one blooper when I wrote that “Rerouting through these alternative systems [the Russian SPFS or the Chinese CIPS] is simply “plug and play”, provided you have a member bank willing to plug you in.“
What should I have written? I would have been much more accurate writing that “Rerouting through these alternative systems, is not really so difficult, provided you have a member bank willing to do some manual processing to hide the messaging trail. For larger payments the cut available for undertaking such manual processing can be pretty attractive. For smaller payments they are not. So the SWIFT ban is essentially a block to payments by the small fish, but a wave through for payments by the big bosses.”
Here is why the SWIFT ban hits the smaller payments but not the large. It is all about automation.
Automation is the entire point of SWIFT messaging. A SWIFT message is not the payment itself. Bank payment systems though are set up to automatically process SWIFT messages and execute the instructions they contain, often without any manual intervention at all.
There are two elements to the SWIFT service. SWIFT provides a secure messaging environment, ensuring the message reaches everyone it needs to reach and that it can be trusted as genuine. It also supports a standard language for payments messaging, known as ISO20022, which makes linking to banks internal systems relatively straightforward. Other alternative payments messaging systems, such as the Russian SPFS and the Chinese CIPS, also all also use ISO20022.
Swift exclusion makes fully automated payment transmission to excluded banks difficult if not impossible. Few Western banks are members of SPFS. More are members of CIPS but only set up for payments in Renminbi by their Chinese subsidiaries. It would be pretty difficult to get a membership, or setting up an indirect association, through any Western bank’s compliance department.
But if a stage of manual intervention is to be allowed, and payments intermediaries can be found to do this, then the SWIFT ban is not so difficult to get around. This will be worthwhile for larger payments. A manual intervention will cost an hour or so of staff time. Lets say $50. The bank doing this will also want to extract a bit of return for doing a favour, say $250. Overall cost $300. Not worth doing for smaller payments, or even middle sized $2,000 or $4,000. But for are payment of $10,000 it could be well worth paying $300 to get the money to Russia. OK, maybe not worth the compliance risks. But tor $100,000 the potential margin can be enough to keep any compliance officer quiet..
Here is an example. Send SWIFT message to authorise a payment of $20,000 from a London account to a correspondent bank in Kazakhstan. Instruct the correspondent manually (telephone call, whatsapp message, etc.), asking the Kazakhstan correspondent to use the SPFS system (created by the Russian central bank, also ISO20022) to make a further SPFS message sending the money on to Russia. The Kazakhstan bank takes its cut of $300 and $19,700 gets through.
This also means that all the talk about “network effects” in payment messaging is irrelevant to the sanctioning of larger payments. Network effects are crucial for automated payments. The investment and compliance costs of linking directly to a payments messaging system are only worthwhile if you will be sending many messages through the platform for subsequent automated processing. But automation does not matter in the same way for large payments as it does for small. For larger payments a partial messaging solution, through existing networks, with a manual bridge works perfectly well.
A technical detail. There is an issue here still – but nothing to do with SWIFT or payments messaging. The Kazakhstan correspondent – or another bank in the chain – will need to conduct supporting foreign exchange transactions (they don’t do this payment by payment, they can work out a net figure covering many payments going in different directions, but ultimately there will be some foreign exchange transactions to settle net balances). In this example this will require exchanging sterling held with a bank in the West for Kazakhstani Tenge held with the central bank of Kazakhstan, then exchanging Tenge for Russian Roubles with the Central bank of Russia, which can then ultimately be used to make a deposit with a bank in Russia. Note that this implies that the current freezing of assets of the Central Bank of Russia itself has holes in it, they can hold indirectly with balances in Tenge and the Bank of Kazakhstan can transact on behalf of the Central Bank of Russia.
To sum up:
- if willing parties to the payments chain are willing to play the game, reprocessing payments messages manually to pass them between systems, then the payments can be expected to get in and out of Russia fairly easily.
- for larger payments there is plenty of dosh on offer to make it worth there while doing this.
- So, SWIFT exclusion pretty good at preventing the smaller payments under $10,000 , but $100,000 or more plenty of work arounds are available