Swift bids to drive ISO20022 harmonisation

There has to be balance between flexiblity and Standardisatioin. Creating more flavors can lead to chaos in implementing the standards and governance. This can kill the real reason behind implementing  ISO20022

Is it too late? Will harmonisation of different uses of just PAIN and PACS usage be challenging.

All too often 20022 is described as a message content standard, ignoring the business context in which it is used.

I see a world of difference between a real-time payment that needs immediate acceptance acknowledgement and a SEPA or BACS credit that might be rejected asynchronously days later. Scheme rules provide some of the context, but there will be confusion if basic expectations of these alternatives aren't built into the common structure. This will enable those who see the "ISO20022 supported" label on a product to be sure that it will do the job they need.

It’s great to see that ISO 20022 is now accepted as the way forward, however I am concerned at the number of ‘schemes for harmonisation’ that are now appearing.  First back in January 2015 EACHA published their study on Interoperable Immediate Payment Schemes, the EBA responded to the ECB and ERPB call to action with their Instant Payment Forum, and as recently as the end of April the ISO 20022 RMG convened a very inclusive and independent roundtable to discuss and make a plan for Global Interoperability of Real Time Payment schemes, which SWIFT, market infrastructures, associations, vendors and the press were invited to.  Now we hear that SWIFT, not including all interested parties, has also held a meeting to cover the same topic.  I have three main concerns with this:-

1. There are now so many of these interoperable schemes or working groups which are expensive for the industry to resource, surely this is what the ‘International Standards Organisation’ is there for, are they not best placed to bring all the parties together to create a single way forward?
2. Did SWIFT take an all-inclusive approach? Possibly not as they now compete commercially with some stake holders, unlike the ISO and the EBA.  Other parties, including vendors see the good and the bad with standards as we work with them all the time, we have valuable insight and experience and are willing to share.
3. Following on from the above, you have to question if SWIFT is truly an independent standards organisation any longer?  There is already scepticism in the industry, especially as it is developing the Australian NPP immediate payments scheme.

I would encourage SWIFT to make the output public as do the EBA and ISO, including details of participants and key discoveries, so all stake holders in the industry can benefit.

Single harmonised standard is no virtue in itself (view Inflexibility / straitjacket) and multiple standards is not a vice (flexibility)... Is this a lot of time and expense spent chasing the impossible.. should we focussing on how one can support easy implementation despite multiple variants...

It seems to be a good initiative ofcourse. Harmonisation is utmost required, as it will give a better underlining to the implementation stakeholders. Since, the market demand to move towards ISO20022 standards is increasing day by day globally, having multiple implementation rules would not be encouraging and will be a chaos within.

Since markets like European markets have high stakes in the implementation of the same with SEPA, the variation of PAIN, PACS, etc implementation in NG-RTGS in India is visible. And having the same repeated in upcoming NPP implementations in Australia may cause increasing the number of new rules within one standard (all because the format have a lot of flexibility and independence). Multiple versions support is another area, which, if gets harmonised will set a very good standards of the implementation of ISO20022 (we have had a hard time in multiple version support in some pain messages in a recent implementation in SEPA region, standardisation would for sure be a nice to have in this case).