Webinar Q&A

Unleash the power of ISO 20022 to unify FedNow, RTP, Fedwire, and CHIPS

What challenges are you seeing for Banks adopting the ISO standard, for example meeting the structured address data requirements for their clients?

Frank Van Driessche: Currently banks are faced with challenges that find their origin in the phased adoption/migration of ISO 20022, e.g., the ongoing Swift MT/ISO 20022 migration. During this period, it may not be possible to benefit from all ISO 20022 enhancements across all markets and solutions where one participates, and banks may need to cater for temporary interoperability measures to guarantee information can flow end to end. However, banks should always keep the end-state in mind as they upgrade their systems and solutions. A good example is indeed the move to better structured postal address information. While not all systems are ready for fully structured information, and most implementations support both structured and unstructured address information for any person/entity/FI involved in a payment, the hybrid end-state as defined by the global Payments Market Practice Group (PMPG) and by the CPMI in their harmonised ISO 20022 data requirements (coming into effect end-2027) needs to be considered (the hybrid postal address requires minimal structured information like country code and town name, while also allowing unstructured address lines, e.g., for street and building number. For additional details, please refer to the Postal Address guidance by the PMPG). So players should incorporate providing at least those minimum structured data elements as they update their systems and solutions.

Can we banks think ahead and future proof our initiations API from channel integration point of view and mix all the rails mapping in one agonistic format which can cater all rails requirement? Can current ISO 20022 Pain001 version satisfy that? Plus can we add NACHA in this mix thinking way ahead of time?

Miriam Sheril: Good question. Form3 for example offers an agnostic API that allows banks to initiate any type of payment - FedNow, RTP, Fedwire, even SEPA , FPS. So there is definitely a way to do this, but it takes hard work and really smart data mapping and modelling.

Deepmala Khubchandani: Yes, it is possible through service-oriented architecture. Agree with what Miriam's explanation on how service providers are addressing this challenge. Many banks in US have adopted third-party payment transformation & integration tools to minimze the change/impact to core processing systems that may be unique to each payment rail.

What will be key data elements in payments that will be driving payment routing logic for an outgoing payment to FedNow vs RTP vs Fedwire vs CHIPS in the future? Let’s say Creditor FI is enabled for all the rails in the US.

Miriam Sheril: The data you mentioned is key - the creditor FI is the key piece if you are looking for routing logic. Based on that and other preferences, the logic should be able to say which rail to send the payment over. Other key elements will be the dollar amount (as the limits that can apply) But beyond routing there are obviously other very key data elements that the standard allows and even provides strength in like the IDs that can be used for end-to-end tracking purposes, and exception processing.

There are a lot of benefits to the industry from ISO 20022, how do you see the business/consumer benefits materialising?

Miriam Sheril: As banks can standardize their processes around this data, they can offer more data to their merchants and consumers allowing for a better end customer experience. Imagine if as an end customer you really could get access and insight into all the aspects of your payments including tracking where they went (which banks) and how long it took. ISO will allow banks to open up some of this data to the end users and consumers 

Deepmala Khubchandani: The businesses will benefit from efficiencies in their accounting processes, better security controls through approvals process, transparency with data on remittances & party (bank) details, and features such as easier instruction routing if/as-when supported by banks offering multiple rails.  
Similar benefits are expected for Consumers with  better validation checks of payment instruction (before processing), secure payments and data transparency on payment status in general.  

Is there any evolution planning and/or thinktank  for fedwire or ISO to integrate into digital currency?

Miriam Sheril: Nothing that has been reported on the radar. 

I know it's a little tangential, but curious how ISO 20022 is being looked at by EPN and FedACH given recent McKinsey surveys and current ISO 20022-to-ACH mapping guides from Nacha. Will US ACH move to ISO 20022 next?

Miriam Sheril: Nothing that has been reported on the radar. 

As you talked about multiple system rolling out ISO standards... what about NACHA?

Miriam Sheril: Nothing that has been reported on the radar. 

Given the later migration dates and the CPMI common requirements till 2027 - is this achievable? How do you both see the yearly changes of ISO message standards?

Frank Van Driessche: From a Fedwire Funds Service implementation point of view it is possible to meet end-2027 when the CPMI requirements come into effect. The Service will roll out the complete core message set in line with the 12 overarching CPMI-requirements, and will enable its participants to apply the CPMI data model to the individual messages as early as March, 10 2025 when going live, only requiring a minor upgrade of specifications by the end of 2027.

Even though both FedNow and TCH RTP use ISO20022, there are lot of differences in the specifications. Apart from that, the messages differences as well... For example, PACS.004 is supported in FedNow and RTP doesn't. With this, how can we achieve "message routing" and if so, by when?

Miriam Sheril: While there are differences, a smart solution would provide an agnostic approach to those differences, like how Form3's API works. That allows banks to not have to worry about the differences at all and basically send an "instant payment". The logic then can handle how to route it. The vendor you choose, if they offer this type of solution, takes care of the differences between the two schemes. As for true message interoperability as the panelists mentioned, we are a bit of a time away from that reality given some of the architecture and builds that are already done - as you mentioned.