Blog article
See all stories »

ISO 20022 for ACH and RTGS payments?

I had an interesting conversation recently that followed on from the Sibos 2011 Standards Forum in Toronto where the Canadian Payment Association (CPA) discussed its plans to use ISO 20022 for both High and Low value payments.  The CPA has now put out a discussion paper that goes further than most countries’ thinking today.  The current trend is that ACH (low value) payments are moving to ISO 20022 standards, RTGS (high value) payments are moving to SWIFT standards, and some countries have started moving ACH payment to (near) real time (UK being ISO 8583 based and Singapore being ISO 20022 based, etc). 

But the Canadians are thinking differently, they are discussing moving ALL payments to ISO 20022, high and low value.  They say the ISO 20022 messages contain all the data that current and future regulations (like Dodd Frank and remittance info) require and can handle both high and low value payments, whereas other standards cannot; and of course XML messages are far easier to maintain. 

Seems a sensible idea to me. If you are going to make changes to prepare for an increasingly on-line, real time, global market place, why stick with a standard based on old technology and why run multiple different payment systems?  Take this to its logical extension, today we say high and low value, but more and more we are saying high and low care.  The trend is already there where systems allow clients to choose between high care (important, immediate, lots of validation) payments and low care (not urgent, value tomorrow or the day after).  If all payments were ISO 20022 and the systems could cope with volume and priority why would you need two different systems for ACH and RTGS?  Now you might want two identical load balanced systems in case one fails, but that’s still a huge saving in infrastructure and annual standards maintenance.  This may also finally see the light at the end of the tunnel that is the journey to retire the legacy SWIFT MT messages.  I guess I am way out there with this; no-one would do this today, would they, makes you think?

11986

Comments: (7)

A Finextra member
A Finextra member 17 September, 2012, 07:48Be the first to give this comment the thumbs up 0 likes

In my opinion RTGS will eventually move to ISO20022 standards. Today a good amount of high value payments are generated due to trade finance (including open account). There is big shift in trade finance space where BPO (Bank Payment Obligation) soon to be endorsed by ICC is based on ISO20022. As per SWIFT there are plans to move Demand Guarantee and Standby LC on ISO 20022 standards.  Eventually when high value payments are also moved to ISO20022 there will be more automation/linking between various products and capability to use better remittance information from trade transactions to payments resulting in faster and better reconciliation.

 

As per World Payments Report (WPR) (2011) from Capgemini, The Royal Bank of Scotland (RBS), and Efma  - There is an increasing blurring of a number of traditional distinctions between different types of payment systems, for example, between Low-Value (high-volume) ACH payments and High-Value (low-volume) RTGS payments. The Faster Payments System (FPS) in the U.K., a good example of this trend, is increasingly attracting volumes from both BACS and CHAPS.19 ACHs generally are shortening their clearing cycles in the process, sometimes making their services more attractive for Treasurers than those provided by the more costly RTGS systems, even for more urgent transactions. However, in the second half of 2010, more than 60% of payments in TARGET2 (the European Central Bank RTGS) were for amounts that it considers to be “retail payments” (less than €50,000), showing that while RTGS is designed for high-value payments, it also handles many low-value payments. As a result, RTGS is starting to compete with ACHs for certain types of low-value payments.

A Finextra member
A Finextra member 18 September, 2012, 04:10Be the first to give this comment the thumbs up 0 likes

There is typo in my previous post.

It should be read as follows - ACHs generally are shortening their clearing cycles in the process, sometimes making their services more attractive for Treasurers than those provided by the more costly RTGS systems, even for more urgent transactions. (19 ACHs is typo)

 

A Finextra member
A Finextra member 18 September, 2012, 07:24Be the first to give this comment the thumbs up 0 likes This is the usual pragmatic vs idealistic view of the evolving payments ecosystem. The use of 8583 in the UK was rightly a very pragmatic approach which resulted in the success of Faster Payments. The business case for idealism is a difficult one.
Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 18 September, 2012, 16:56Be the first to give this comment the thumbs up 0 likes

Not sure about the message format but the ACH and RTGS in India both run on the same rails. All differentiation in terms of settlement cycles, delivery time, fees and frontends happen outside the rails. Some banks use up the full T+2d SLA for delivery whereas others provide instant credit for NEFT. At the time the ePayment system was commissioned some 8-10 years ago, some questioned the service provider's judgement of using common rails for ACH and RTGS, which seemed to neglect certain basic differences between the two systems. Articles like this and the drift of CHAPS volumes to FPS in the UK vindicate the Indian ePayment architecture, even if only upon hindsight.

Barry Kislingbury
Barry Kislingbury - ACI Worldwide - London 19 September, 2012, 14:38Be the first to give this comment the thumbs up 0 likes

A couple of good points here.  Firstly technology has progress to the point that a payments system can handle both high and low value / care in one system.  The transition of payments to both UKFP and TARGET2 shows that users are choosing real time services and NEFT shows that banks can differentiate their services and charges using such systems

The second point is that if you designed a system like this today you would have to seriously consider ISO 20022 and XML, as the Canadians have.  Innovations like UKFP and NEFT were before ISO 20022 had become generally accepted and took the pragmatic approach based on reliable technology of the time.  UKFP has been live since 2008 and was started back in 2005, which does not seem a long time ago but was before ISO 20022 and XML became mainstream in the payments world.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 19 September, 2012, 19:18Be the first to give this comment the thumbs up 0 likes

As I recall, SCT went live with ISO20022 a couple of months before UKFP did on ISO8583. So, ISO20022 was fit for purpose for a high-volume payment system even back in 2008. But, SCT was a T+1 system. Four years later, the situation could be different, but this backdrop makes me wonder if the richness of ISO20022 somehow imposes high processing overheads, thereby ruling it out as the format of choice for near / real time payment systems. 

Barry Kislingbury
Barry Kislingbury - ACI Worldwide - London 20 September, 2012, 09:55Be the first to give this comment the thumbs up 0 likes

That was one reason given why UKFP did not go ISO 20022, plus the speed of XML parsers.  However I think that has been proved a non-issue and countries like Singapore and Canada are now adopting ISO 20022 and XML for their next generation of domestic payment systems.

Now hiring