ISO 20022 for ACH and RTGS payments?

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.

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)

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.

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.

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.

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. 

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.