How RTP Works: A Look at ISO 20022

Among the many improvements that Real-Time Payments brings to the money transfer ecosystem, one of the most overlooked is its adherence to the global standard ISO 20022. For the uninitiated, ISO 20022 describes a collection of XML-based schemas that cover most types of financial messaging. This is a radical departure from previous payment systems which have historically developed their own unique format to exchange similar information, most commonly in unstructured or semi-structured text files. A notable example is the NACHA format for ACH payments.

RTP is unique in the United States in that all messages on its network follow the ISO standard and The Clearing House (who own and operate the RTP network) have published their documentation online. In the past few years, banks have started allowing their customers to send them messages conforming to the ISO standard. Most use only a small subset:

Each schema covers a specific message purpose. Messages related to Payments Initiation are prefixed (ironically) with pain, and allow customers to send payments and receive payment feedback. Those related to Cash Management are prefixed with camt and allow a customer to receive periodic balance and transaction updates. So anytime a company wants to pay one of their users, they would send a pain.001 message and anytime they want to charge a customer, they would use pain.008. From a customer's perspective, any interaction with the bank usually falls into one of these messaging types.

Many financial institutions are seeing the benefits of standardizing on ISO schemas for their customers, as theoretically customers only have to deal with a single messaging schema that can handle ACH and Wire payments. Under the hood, these payment networks still have their own proprietary formats but they publish official guidelines that describe how to map fields between their format and the relevant ISO schemas. Fedwire will actually move their backend messaging format for wire transfers to ISO 20022, but that migration has been delayed from its original timeline. [1]

The Clearing House has taken a different approach than NACHA, Fedwire, or CHIPS, specifically standardizing ISO 20022 for all the Bank-to-Bank messaging without tackling any of the above customer-related messages. While this approach helps developers working inside the bank, they do little to help companies who wish to integrate RTP into their products.

This means that there is no standard for creating RTP payments and so each originating bank has built their own interface.

Because RTP is meant to be real-time, the interfaces provided by banks are often HTTP-based rather than file-based. A notable side effect of this transition is the use of JSON instead of XML. That being said, most financial institutions have taken the approach of modeling their customer interfaces as thin wrappers on top of the messages they (or their software providers) send on the network, namely pacs.002 and pacs.008:

pacs is a shortened form of "Payments Clearing and Settlement," a collection of messages that Financial Institutions (FIs) send to each other to process payments. Financial institutions also use pacs messages to each other to update each other on the status of certain payments. The exact timings and flows of these messages are dictated by the RTP Technical Documentation.

How to Implement RTP

There are two ways to implement RTP. The first is to get the interface details from your corporate bank, who will act as the originating bank.

The second is to use a third party service provider such as Modern Treasury. We have a simplified Create Payment Order interface which can trivially handle RTP payments and is able to translate such calls to the individual bank's specific format. Here is an example:

Conclusion

If you want to learn more about RTP infrastructure or learn about implementing RTP in your payment flows, please reach out.