Original IREF article of 16 March 2022 accessed on 21 March 2022

Published on 23 March 2022

The EU recently announced partial financial sanctions on Russia, designed to keep payments for energy moving. The EU accepted the contention – disproved below – that a bank either gets cut off from SWIFT, the global financial telecommunications network, completely or not at all. It has consequently banned dealings with only 7 banks, sparing Sberbank, Gazprombank and all others.[1] The option of imposing a blanket ban but with a ‘safe corridor’ over SWIFT for energy payments exists but was not taken. Furthermore, the EU omitted to mention that its own push to make the EU, EEA and a number of other extension territories into a single domestic area for euro payments has left it incapable of identifying, still less stopping, illicit money flows where both of the payment’s endpoints are within the SEPA Area.[2] This misinformation protects the EU from rolling back what they have swallowed whole from their payment technocrats since the euro was established.

The SEPA project underpins the EU objective of establishing a Single Market with free flow of goods and money, and on payment terms applicable to a domestic market, meaning:

  • No foreign exchange conversion
  • Identical treatment, legal framework, fee structure and timings wherever an account is domiciled in the SEPA Area and regardless of the residency status of the account-holder
  • No statistical reporting to the member state central bank on ‘cross-border payments’[3]
  • No exchange control regulations

The SEPA Area is meant to be a ‘free market’, but it has been designed by technocrats and circumscribed by successive EU Regulations and Directives: an oxymoron. A monopoly was established by Regulation (EU) 260/2012 for the ISO2022 XML data format. Bank accounts are identified by the IBAN, or International Bank Account Number, another ISO standard. Regulation (EU) 847 of 2015 allows that the IBAN on its own can be used to identify the payer and payee for a payment with both endpoints in the SEPA Area: no name and address, or reason for the payment, are required.

IBAN has been implemented in such a way that a payment message can consist entirely of numeric characters apart from the initial two alpha-character country code:

  • CY17 0020 0128 0000 0012 0052 7600 for an account in Cyprus
  • LT12 1000 0111 0100 1000 for an account in Lithuania

The message is anonymous and cannot be screened for a sanctioned person or organisation. The payment can be for up to €1 billion.[4] Then you have the Virtual IBANs service offered by numerous banks and financial technology companies (fintechs): the institution to whom the IBAN is identifiable has no Know-Your-Customer due diligence file on whoever the IBAN is being used by.

Add in Golden Passports issued by various member states, and the 700+ sanctioned persons and 50+ sanctioned organisations can continue to use their accounts within the SEPA Area, freely and undisturbed, as long as the banks and fintechs involved remain cooperative.

It is better where the legacy SWIFT data format is used.[5] The TARGET2 and EBA EURO1 payment systems are planning to migrate to ISO20022 XML but for now SWIFT MT is used. BICs of sanctioned Russian banks must be visible in related payment messages.[6] A payment ought not to reach that bank when it is either a payment system member or its BIC is directly addressable through the payment system.[7]

Within the SWIFT MT world, SWIFT access (and payment system access) can be interdicted at five levels, contrary to the EU’s assumptions:

  1. SWIFT disconnects all members whose BIC has ‘RU’ in the fifth and six positions, such as SABRRUMM – Sberbank in Russia;
  2. SWIFT disconnects the BICs of Russian-controlled entities outside Russia, such as DOBAnnnn – VTB Bank (Europe) SE, based in Germany but operating principally through its Vienna branch, the former Donau Bank AG;
  3. Individual members cancel ‘RMA’.[8]  This is the facility whereby institutions permit ‘value messages’ to reach one another;
  4. Individual members stop short of full disconnection by subjecting their traffic to RMA+: they select specific ‘value messages’ to be exchanged and all others will fail;
  5. Individual members add a party (person, organisation or bank) to their lists of sanctioned entities and any payment message containing their details will be diverted out of the normal processing flow and into the supervision of the member’s Financial Crime Unit.

This gives the lie to the statement that either a bank gets completely cut off SWIFT or not at all.

A ‘safe corridor’ could easily becreated for energy payments, which are Customer payments and not Financial Institutions payments.[9] Central banks of payer countries could issue lists of approved payers and payees, payments between whom for approved purposes would be exempted from a blanket ban on dealings with all Russian banks. The blanket ban would result in all payment orders quoting a Russian bank as the ‘Account With Institution’ being diverted to the Financial Crime Unit of the payer’s bank – method 5 as listed above.[10] The volume of payments will be low, although their value will be high: the payers’ banks can therefore operate an eyes-on process in their Financial Crime Units of releasing energy payments based on matching the payment message content to invoices submitted by the payer, and to the presence of the payer and payee on the central bank’s approved list and to the statement of approved purposes. By doing that the payers’ banks will have reinstituted the process of Exchange Control that the payment technocrats have kicked away since 1st January 1999 when the euro was launched.

Payment technocrats have crippled EU’s ability to make sanctions bite on euro payments within the SEPA Area using the ISO20022 XML data format. Contrary to what the EU has stated, sanctions can be made to bite on SWIFT payments in legacy format, with a ‘safe corridor’ only for energy payments. It looks like it is time for the EU to find itself a new team of payment experts.


[1] https://www.reuters.com/business/finance/eu-excludes-seven-russian-banks-swift-official-journal-2022-03-02/ accessed on 9 March 2022

[2] SEPA – Single Euro Payments Area

[3] ‘Cross-border’ could mean any or all of the payment being in a foreign currency and/or being between a resident and a non-resident and/or travelling across the member state’s border

[4] https://n26.com/en-eu/blog/sepa-transfers-everything-you-need-to-know accessed on 7 March 2022

[5] Known as ‘MT’: the messages are ordered into series, each series is tagged with a domain of business, and each individual message in the series has a three-character number and name, identifying it as its distinct MT (which stands for Message Type). When a series is to be identified, the layout 1nn or 2nn is used to signify all messages in that series

[6] Business Identifier Code – a member’s mailbox on the SWIFT system

[7] ‘Directly addressable’ means that routing tables within a payment system identify which system member represents another institution, such that payments run seamlessly to the system member and then on to the other institution

[8] RMA = Relationship Management Application; ‘value messages’ are ones ordering payments, movement of securities and similar; a typical non-value message would be an announcement of an unscheduled bank holiday

[9] Customer payments are the SWIFT MT1nn message series, as opposed to the SWIFT MT2nn series for Financial Institutions payments, the SWIFT MT5nn series for movement and payment for securities, and the SWIFT MT7nn series for trade finance operations such as Letters of Credit

[10] The payment order would be given by MT101 Request for Transfer or through a proprietary electronic banking system of the payer’s bank that captured the same data. The payment would be executed by MT103 Single Customer Credit Transfer. In both SWIFT messages the ‘Account With Institution’ is populated as a BIC of the payee’s bank under Option A (the ‘preferred option’ in the SWIFT Message Reference Guide) in Field 57a, and is mapped through from the MT101 to the MT103