Unleash the power of ISO 20022 to unify FedNow, RTP, Fedwire, and CHIPS
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.
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.
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.
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.
Miriam Sheril: Nothing that has been reported on the radar.
Miriam Sheril: Nothing that has been reported on the radar.
Miriam Sheril: Nothing that has been reported on the radar.
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.
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.