RTP: the US real-time payment network

RTP, the Real-Time Payments network, is the United States instant payment system operated by The Clearing House, launched in November 2017, and it lets a payment move between accounts at different US banks in seconds, 24 hours a day, 7 days a week, including weekends and holidays. It settles in central bank money through a prefunded joint account at the Federal Reserve, and it carries ISO 20022 messages, so a payment can include rich remittance data, and a request for payment can be sent before the payment itself. The transaction limit is USD 10 million per payment, raised from USD 1 million on 9 February 2025, which makes RTP usable for business payments as well as personal ones. Source: The Clearing House, RTP network; Federal Reserve, FedNow and RTP comparison. Why RTP exists is that the United States had no real-time retail payment system, and a payment sent on Friday arrived on Monday, which was unacceptable once customers could order and pay instantly in every other part of their lives. Businesses needed to pay suppliers on the day the invoice was due, gig workers needed to be paid the same day they worked, and the old ACH batch system, which settles in one to two business days, could not do any of that. RTP answers by settling each payment individually in seconds, with immediate confirmation, so the payment is final within seconds and both parties know it, and the system never closes, so a payment sent at 02:00 on a Sunday settles at 02:00 on a Sunday. The parties are the payer and the payee, their banks, which must be RTP participants, The Clearing House, which operates the network, and the Federal Reserve, where the prefunded settlement account is held. A distinctive feature is the request for payment: a biller can send a request for USD 850 to a customer, the customer sees the request, approves it, and the payment is sent, which turns a pull into a push that the customer controls. The prefunding is the settlement model: each participating bank prefunds its share of the joint account, and each RTP payment moves money between the banks prefunded positions, so settlement is immediate and final, and no bank can send a payment it has not funded. How it works is shown by a worked example. A company in New York owes a supplier in Chicago USD 240,000 for parts, and pays by RTP on a Saturday at 09:00. The New York bank checks that its prefunded position covers USD 240,000, sends the ISO 20022 payment, the network settles it against the prefunded account, and the Chicago bank credits the supplier USD 240,000 at 09:00:03, three seconds later, with the invoice number in the remittance data. The supplier sees the payment on Saturday, not Monday, and can dispatch the parts on Monday morning. For a smaller payment, a gig platform pays a driver USD 180 at 18:00 on a Sunday, and the driver sees it in seconds, which is the difference between being paid today and being paid on Tuesday. On success the payment is final in seconds, the receiver can use the money immediately, and the sender has confirmation, so there is no uncertainty to manage. On failure the payment can be rejected, for example because the receiving bank is not an RTP participant, the amount exceeds USD 10 million, or the sending bank prefunded position is insufficient, and the rejection is immediate, so the sender knows at once. The failure that matters most is a payment sent to the wrong account, because the payment is final and irrevocable, so the recovery is a request to the receiver to return the money, and the bank follows its mistaken payment process, which depends on the receiver cooperation. The data in an RTP payment is the payer and payee identification, the account and routing numbers, the amount in US dollars, the remittance information, and the ISO 20022 message that carries it. The remittance data is the feature that matters for business payments, because it lets the receiver reconcile automatically, while the old ACH system carried limited remittance data and often required a separate email. A BA must specify the prefunding check, the limit check, the request for payment handling, the remittance field and the mistaken payment process, because each of those is a customer promise. Edge cases show the limits. RTP and FedNow are both US instant systems, and a bank may participate in one, the other, or both, so a payment can only travel by RTP if both banks are RTP participants, and the sending bank must check participation before promising an instant payment. A payment of USD 12,000,000 exceeds the RTP limit of USD 10 million and must travel by Fedwire instead, which settles in real time but is not a retail instant system, and the customer must be told why the payment is not instant. A bank whose prefunded position runs low on a busy day must top it up, or its payments will be rejected, so liquidity monitoring is a 24/7 duty, not a business-hours one. The effect on the bank is a service customers expect, and a reduction in ACH and cheque volume. The effect on the customer is money that moves when the customer wants it to move, including weekends, and a request for payment that lets a biller ask for money without pulling it. The effect on operations is a 24/7 service with fraud screening in milliseconds, a prefunded position to monitor continuously, and a mistaken payment queue that must be worked quickly, because the customer who sent money to the wrong account wants it back today. What a BA, PO or SME must understand is that RTP is a prefunded instant network, and the prefunding is the settlement, the ISO 20022 data is the reconciliation, and the request for payment is the control that makes it usable for billing. The test is to send one payment on a Sunday, check that it settled in seconds, that the remittance matched the invoice, and that the prefunded position was updated, because if any of those fails, the service is not working. Further reading: The Clearing House, RTP network; Federal Reserve, FedNow service; Bank for International Settlements, fast payment systems. Last reviewed 7 November 2026.