The payment industry’s migration to the ISO20022 XML data format promises much, or rather the list of promises is long and the same as it has been for a long time, and is very promising: richer data, easier data mining, easier compliance-checking and harmonization
(aka everyone else is going to use it so we should too).
Multiple years of effort, an expenditure of hundreds of millions of dollars, and what will be the Day 1 deliverable? What we have now, at best, but all in XML and operating within a single, accommodative, global framework, as opposed to multiple, mainly
national, more disciplined frameworks, with consequential distancing of accountability into supranational NGOs.
The UK’s RTGS Renewal and New Payments Architecture will use at their outset a UK pacs credit transfer that is a like-for-like with what exists now.[1] When the benchmarks are SWIFT MT for CHAPS and Standard 18 for BACS, that is
a pretty low bar, and will ensure that the majority of fields within the XML schema will be empty, narrowly surpassing, in a form of limbo dance, a SEPA Credit Transfer completed with IBAN-only, in which almost all the fields are empty.[2]
An IBAN-only payment defies compliance-checking, undermining that supposed benefit of ISO20022: it has no checkable content.[3]
Nevertheless an ISO20022 message ships a large number of characters, including voluminous padding. A claim made for ISO20022 is its supposed structured information, but one should not confuse that with the message itself being structured: all of SWIFT MT,
BACS Standard 18, ISO8583 et al have structure and a user manual. Their supposed shortcomings are that fields for accompanying information are too short, and that the rules for the population of the fields that do exist are too loose.
It is funny that the same criticism was made – but ignored – of ISO20022 when it was compared to the legacy data formats used in the Single Euro Payments Area, such as CFONB (France), DTA (Germany) and CRI (Italy). The SEPA payment schemes lacked numerous
features and functions existing in these data formats but the train rolled on regardless in the name of harmonization. An EU Regulation was enacted to retire these formats, making up for ISO’s defective sales proposition.[4]
What then occurred was that ‘national communities’ adopted their own versions of the SEPA schemes, adding back their lost features and functions under the heading of ‘Community Additional Optional Services’ or AOS, and effectively reserving numerous fields
in the schema. The SEPA Scheme Implementation Guidelines colour-code each field as Yellow (common), White (country-specific – ‘To be developed and documented by AOS Communities’), and Red (not to be used). Furthermore, national specifics are permitted to eat
into the common area as ‘yellow fields [which] can be used in a specific way for an AOS’.[5]
It is in this manner that ISO20022 is made accommodative: an apparently capacious schema, more than half empty in some cases, with a large number of ‘white’ fields reserved by a national community for usage in a way that is incompatible with the way the
same field is populated in another SEPA Area member state, and even some ‘yellow’ fields used in a way that is not ‘interoperable’, to use the industry term for being compatible with what is done in other countries.
The result is a deployment of ISO20022 in the SEPA Area that has run itself into the sand. This ‘new’ data format has become ossified within its first and largest implementation.
There appears to no longer be any pretence that ‘Value Added Services’, or VAS, can be added on top of the SEPA schemes, as was supposed to be the basis of competition between Payment Service Providers. There appears to be no pretence that a ‘Community’
can be anything other than a national body such as the Dutch Banking Association. The schemes have now remained virtually unchanged for 14 years, in their Day 1 form.
An organisation like EBA Euro Bankers Association, that might have been a forum in which banks from multiple SEPA Area member states could have developed VAS, instead has its market space circumscribed by the over-arching ISO bureaucracy, the ISO20022 management
layer, the European Payments Council, SWIFT, and the national communities.[6] EBA could not recommend usage of a field for its VAS that had been reserved for the AOS of any national community of one of its members, if it wanted its
new service to be rolled out in the respective SEPA Area member state. As a result EBA is left with a Venn diagram with no space for VAS in the middle. Instead it has to try and add value by intermediating between banks and corporate customers about liquidity
management,[7] and between banks and suppliers of Access-to-Accounts services.[8]
The result is stagnation, and no plausible way of developing new features and functions to gain competitive advantage. The elephantine governance model ensures a glacial lead-time and comprehensive exposure of plans to the competition: everyone makes do
with driving a grey Trabant.
The global migration to ISO20022 is not a new beginning, but a sideways switch to a bloated data format that has already run into a cul-de-sac. At best the feature-and-function will be as good as it is now, if one is unlucky enough to currently be receiving
a low-function service like the one in the UK. If the functionality is advanced, then, following the SEPA pattern, functionality will initially be reduced in the interests of harmonization.
This sideways move, even if it is successfully accomplished without major outages, will take payments to the bottom-left square on a snakes-and-ladders board. Feature-and-function will need to be rebuilt in some countries to regain the status quo ante. Further
construction will be needed everywhere to make ISO20022 deliver on its many promises, although the available space in the format for doing that is limited. Given the consequent need to re-use space, the SEPA pattern presents itself: space gets re-used on a
country-by-country basis. This undermines ISO20022’s sole selling point: harmonization. All that is achieved is the ubiquitous usage of the same box of Lego, only without the fun, and with bricks in just three colours.
[1] Pacs, the series of ISO20022 messages for ‘payment clearing and settlement’, broadly encompassing the SWIFT MT message types 102, 103, 104, 200 and 202
[2] IBAN – International Bank Account Number; Funds Transfer 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
[3]
https://en.irefeurope.org/publications/online-articles/article/payment-technocrats-have-crippled-eus-ability-to-impose-biting-sanctions-on-russia/ accessed on 9 October 2022
[4] SEPA Migration End Date Regulation (EU) 260 of 2012
[5] The European Payments Council might argue that an AOS Community does not have to be a national user community. This is true, but in practice they are.
[6] https://www.abe-eba.eu/ accessed on 9 October 2022
[7]
https://www.abe-eba.eu/thought-leadership-innovation/liquidity-management-working-group/ accessed on 9 October 2022
[8]
https://www.abe-eba.eu/thought-leadership-innovation/open-banking-working-group/ accessed on 9 October 2022, addressing the portion of Payment Services Directive 2 which allows Third-Party providers to act as aggregators between customers and their banks,
for payment initiation and account information services, and similar to Open Banking in the UK