Real-Time Payments (RTP) for Developers

Introduction

The Real Time Payment (RTP) Network from The Clearing House presents a particularly interesting opportunity for businesses to move away from the batched, time-sensitive operations of traditional payment rails.

Below, we’ll take a detailed look at RTP and how to go about implementing it via the perspective of a developer working to build products or processes that move money.

An overview of RTP

Design principles of RTP

Credit Only

RTP only supports credit, or “push,” payments. You can not debit another bank account using RTP. All payments are final when completed and cannot be reversed, which eliminates payment failures due to insufficient funds.

Because there is no way to initiate a transaction that pulls money out of the sender's account, the RTP Network uses Request for Payment (RFP). RFP is essentially an RTP message that functions like an invoice or a bill. RFPs can include all information needed to remit the requested payment, so the customer can approve and send the payment directly from their banking app.

Richer Messaging Standards

RTP uses ISO 20022 as a messaging standard. This means more information can be sent in the body of the payment, making reconciliation easier. We cover ISO 20022 in more detail below.

Transaction Limits

The current credit transfer limit on the RTP network is $1 million. But financial institutions (FIs) can set lower limits for customers sending RTP transactions. Currently, FIs cannot cap transaction amounts for received RTP payments.

Use Cases for RTP

We elaborated on some of the business benefits of RTP in our piece about use cases for Faster Payments. For developers working with products that move money, here are the some products you can build with RTP:

Benefits

RTP increases the speed of bank transfers in a cost-effective manner, reduces transaction risk by eliminating payment reversals and returns, and also supports attaching richer context on payments (which facilitates faster reconciliation).

In addition to the benefits for businesses:

• RTP is easier to build with because it’s credit only, settles immediately, and operates 24/7/365 (i.e., there’s no batching, returns, debits, or cutoff windows to program around).
• RTP makes reconciliation easier because you can easily map one transfer object to one payment transfer. As explored in our Recon Diaries series, banks bundle payment objects in one transfer—both in their APIs and statements. For traditional rails, you would need to build a reconciliation engine to match transaction line items (say, invoices) and transactions. With RTP, there is no such need.

How RTP Compares to Other Bank Rails

RTP addresses pain points that can exist with wire transfers and ACH: higher cost and slower processing times, respectively. While wires are settled on a transaction basis, they can come with a steep price tag. ACH’s batch-based processing, means it takes at least one business day to move funds. Same-Day ACH, while faster, is still subject to bank cutoff times and batch processing.

On the developer end, there’s also the need to manage returns and reversals, and parse NACHA files. (Our friend and customer Gusto has a developer’s primer to ACH, a mainstay in our onboarding readings).

A chart noting the differences in cost, settlement time, payment direction, and bank coverage between RTP, ACH, and Wires in the US.

Building Against RTP

Step 1: Ensure Your Bank Partner Supports RTP

In order to initiate an RTP payment, you’ll need to be banking with an FI equipped to process this type of instant transaction.

Right now, 285 financial institutions in the US support RTP payments, but any federally-insured US depository institution can connect to the RTP network directly or via a third party service provider (e.g., a hosted gateway, bankers’ bank, or corporate credit union).

When working with Modern Treasury, we can help you find a bank partner that supports RTP payments and is the right fit for your business.

Step 2: Understand the Core Flow

A basic look at the RTP Payment Flow.

When someone is ready to make an RTP payment, they send payment instructions to their bank. The bank then creates an RTP Credit Transfer message, which it sends to the RTP Network for routing. If that Credit Transfer message passes validation by the RTP Network, it is then forwarded on to the recipient’s bank.

The receiving bank then confirms the message, accepts it, and makes the funds immediately available for transfer. (It is possible that a recipient’s financial institution could reject the message for a variety of reasons, outlined in the RTP technical documentation.)

Once the payment settles, both the sending and receiving financial institutions receive a message confirming that the transaction has been successfully completed.

Let’s look at an example of what that API call would look like. Imagine you need to send a $10k RTP payment:

A sample API call for an RTP payment.

With Modern Treasury, you can quickly and easily set up the $10k payment (in this case, formatted in cents, so that $10 becomes “1000000”). To add an extra safety net for ensuring that your payment is successful, you can also set a fallback payment type. In the example above, if the RTP payment were to fail, the fallback type is set to ACH; while the payment wouldn’t happen instantaneously as with RTP, the payment could still be completed if the rail has been built.

Most banks process significant amounts of transactions per second, so there is theoretically no limit to the number of RTP transactions you can send in any given time period.

Step 3: Understand the Messaging Specs

Messages used for an RTP transaction are formatted with the ISO 20022 global messaging standard. RTP is unique in this regard, as historically, most networks have developed their own format to exchange information using unstructured or semi-structured text files (think of the NACHA file format for ACH payments). Technical documentation for ISO 20022 is available online via The Clearing House.

ISO 20022 describes a collection of extensible markup language (XML) based schemas that cover most types of financial messaging. Each schema covers a specific message purpose, such as Credit Transfer Initiation or Payment Status Report.

All ISO 20022 files have specific four-part identities signifying category, type within that category, variant, and version. These categories are used to indicate the broad classification of the message. Messages related to cash management are identified with camt; ATM card transactions with catp; securities clearing with secl; those related to payments initiation with pain; and pacs for messages between financial institutions to update each other on the status of certain payments.

A look at the four parts of an ISO 20022 message.

Some of the more common RTP messages are pain messages, which allow for sending payments and receiving payment feedback, and camt messages, which allow for periodic balance and transaction updates.

A sampling of some of the common schemas used for RTP transactions.

FIs will often need to update one another on the status of RTP transactions and the messages that facilitate these updates are labeled with pacs. pacs is a shortened form of "Payments Clearing and Settlement."

A look at two of the pacs messaging schemas.

Step 4: Initiate an RTP Transaction

Let’s take a more detailed look at the process for sending an RTP transaction. The sender initiates a Credit Transfer with their bank, their bank then sends the Credit Transfer message pacs.008 to the RTP network.

One thing that is important to note here is that a pacs.008 message could be used to reference several payment types: a direct RTP transfer from one party to another, a response to a Request for Payment (RFP), or a Request for Return of Funds.

Once received from the sender’s financial institution (FI), the RTP Network performs a series of formatting, processing, and business rule validations. The RTP Network then routes the pacs.008 message to the receiving FI and waits for a response for a predefined time-out period—during this time, a receiving bank must respond to the Credit Transfer message from the RTP Network or the message will time out.

Upon receipt, the recipient’s FI performs its own series of validations to ensure the correctness of the message, before sending a response to the RTP Network in the form of a pacs.002 Message Status Report indicating whether or not the Credit Transfer has been accepted.

An example RTP Credit Transfer and Message Status Report diagram.

The RTP Network then validates the response and passes it to the sender’s bank to alert the sender whether or not the transaction has been successful. The RTP Network also sends a “Message Receiver Confirmation” to the recipient’s bank, alerting them that the transaction has settled.

Credit Transfer messages have limited remittance fields, so the sender may choose to send more detailed remittance information about the transaction to the receiver with a separate message. This separate message is called a Remittance Advice message and is formatted as remt.001. Once the receiver’s FI has received the remt.001, they will ensure that it includes the unique ID associated with the original Credit Transfer message, so that it is clear to the recipient which transaction this additional information is referencing.

The recipient can then opt to send an additional message, Payment Acknowledgement by Receiver camt.035, that confirms their receipt of the funds and can include details about the payment.  For example:

• “Payment received, thank you! Your package has been shipped with tracking number abcd1234.”
• “Invoice #123-456-789 has been paid.”
• “Your payment was received and credited to your account.”

How to Use RTP With Modern Treasury

Rather than building a (time and labor intensive) direct integration with your bank, you can instead integrate with Modern Treasury and connect to all your banks simultaneously. Our software layer sits on top of your bank account, giving you a single, centralized integration for multiple bank accounts and payment methods, including RTP for customers with supporting banks.

Via our API or simplified Create Payment Order interface (which can handle RTP and translate these calls to an individual bank's specific format), you can initiate RTP transactions. When using Modern Treasury, you can also apply Automatic Reconciliation to instantly reconcile every payment and make it easy to keep track of your business’ funds.

To learn more about using RTP with Modern Treasury, you can review our API Docs or reach out to us.