RTP — Real-Time Payments
Overview
RTP (Real-Time Payments) is the first US real-time payment rail, launched by The Clearing House (TCH) in November 2017. It enables immediate, irrevocable credit transfers between participating financial institutions, 24 hours a day, 7 days a week, 365 days a year — including weekends and holidays.
RTP is a credit-push only rail — only the sending party can initiate a payment. There are no pull/debit transactions on RTP. Once a payment is sent and accepted, it cannot be reversed by the sender. This irrevocability is a core design feature that distinguishes RTP from ACH.
Network Coverage
As of early 2026, RTP reaches approximately 65% of US demand deposit accounts through over 300 participating financial institutions, including most major US banks and a growing number of community banks and credit unions.
How RTP Works
Unlike ACH (batch) or Fedwire (Federal Reserve account-to-account), RTP uses a centralized real-time clearing infrastructure operated by TCH. Settlement occurs through a pre-funded settlement account at the Federal Reserve Bank of New York — each RTP participant must maintain a funded position in the TCH joint settlement account.
| Characteristic | Value |
|---|---|
| Settlement mechanism | Real-time, immediate, net funded position at Federal Reserve Bank of New York |
| Settlement finality | Immediate upon acceptance by the Receiving Bank |
| Payment direction | Credit push only (sender initiates, receiver accepts) |
| Transaction limit | $1,000,000 per transaction |
| Message standard | ISO 20022 pacs.008 (Customer Credit Transfer Initiation) |
| Operating hours | 24/7/365 — no downtime windows |
| Reversals | Not available. Irrevocable upon acceptance. |
| Returns | Possible in limited cases — only if the RDFI cannot post (e.g., account closed, invalid account) |
Processing Flow
Sender
Initiates
Initiates
→
Sending Bank
Validates
Validates
→
TCH RTP
Network
Network
→
Receiving Bank
Posts
Posts
→
Receiver
Notified
Notified
- Payment Initiation: The Sending Bank's customer (individual or business) initiates an RTP credit transfer via mobile app, online banking, or API integration. The instruction includes the receiving bank's routing number, beneficiary account number, amount, and remittance information.
- Sending Bank Validation: The Sending Bank validates the message format (ISO 20022 pacs.008), confirms sufficient funds in the sender's account, performs OFAC screening, and confirms the Receiving Bank participates in RTP.
- Submission to TCH RTP: The Sending Bank submits the pacs.008 message to the TCH RTP system. TCH validates the message and routes it to the Receiving Bank.
- Receiving Bank Response: The Receiving Bank has a defined response window (typically seconds) to accept or return the payment. If the account is valid and open, the payment is accepted. The Receiving Bank posts the credit to the beneficiary account.
- Settlement: TCH debits the Sending Bank's prefunded position in the joint settlement account at the Federal Reserve Bank of New York and credits the Receiving Bank's position. Settlement is immediate and final.
- Confirmation: Both the Sending Bank and the Receiving Bank receive confirmation from the TCH RTP system. The sender receives a payment confirmation (pacs.002 or equivalent status message).
No Reversal After Acceptance
Once the Receiving Bank accepts the RTP payment and TCH settles, the transaction is final. If the Sending Bank's customer sent the payment in error, they must contact the beneficiary directly to request a return. The bank cannot force a reversal. Customer service teams must be trained on this critical distinction from ACH.
Transaction Limits and Controls
| Limit Type | Amount | Notes |
|---|---|---|
| Maximum per transaction (TCH network) | $1,000,000 | Individual institutions may set lower limits for their customers |
| Typical institutional retail limit | $25,000 – $100,000 | Banks commonly cap retail RTP at lower thresholds for fraud prevention |
| Business/corporate limit | Up to $1,000,000 | Higher limits available for verified business customers with appropriate controls |
| Minimum | $0.01 | No practical minimum enforced by TCH |
Request for Payment (RfP)
RTP's Request for Payment (RfP) feature allows a payee (biller, business, individual) to send a standardized payment request to a payer. The payer reviews and approves the request, triggering an RTP credit transfer. RfP is distinct from ACH debit — the payer always initiates the payment and controls the release of funds.
RfP Use Cases
- Billing and invoice payment — a business sends an RfP to a corporate client for outstanding invoices
- P2P payment requests — individual requests payment from another individual (similar to Zelle/Venmo request functionality, but directly bank-to-bank)
- Mortgage/rent collection — landlord sends RfP to tenant on due date
- Insurance premium collection — insurer sends periodic payment requests
| Step | Action | Message Type |
|---|---|---|
| 1 | Payee sends payment request to Payer's bank | pain.013 (Creditor Payment Activation Request) |
| 2 | Payer's bank presents request to Payer for approval | Internal notification |
| 3 | Payer approves — Payer's bank sends RTP credit transfer | pacs.008 |
| 4 | Payee's bank confirms receipt | pacs.002 (Payment Status Report) |
Compliance Requirements
OFAC Screening
- All RTP transactions must be screened against OFAC SDN and applicable sanctions lists prior to submission to the TCH network.
- Because RTP is immediate, OFAC screening must be pre-configured in the payment processing workflow and must not cause processing delays for clean transactions.
- Automated screening with near-zero false-positive rate is essential — manual review queues are incompatible with real-time SLAs.
Fraud Prevention Considerations
- The irrevocable nature of RTP makes it a high-value target for social engineering and authorized push payment (APP) fraud.
- Implement behavioral analytics to detect anomalous RTP patterns: first-time payees, large amounts, account activity inconsistent with customer profile.
- Customer confirmation steps (e.g., "Are you sure? RTP payments cannot be reversed") reduce APP fraud liability exposure.
- Consider cooling-off periods or velocity controls for first-time RTP beneficiaries above defined thresholds.
Exception Handling
RTP Returns
RTP payments can be returned in a limited set of circumstances — only when the Receiving Bank cannot post the payment. Unlike ACH, there is no customer-initiated return window.
| Return Reason | Condition | Timeframe |
|---|---|---|
| Account Closed | Receiving account no longer exists at the RDFI | Must be returned before TCH settlement; typically within seconds |
| Invalid Account Number | Account number does not exist or does not match | Before settlement |
| Account Blocked | RDFI cannot post due to regulatory hold, fraud block, or court order | Before settlement |
No NSF Returns on RTP
Unlike ACH, RTP does not return for insufficient funds (NSF) at the Receiving Bank. If the beneficiary account is valid and open, the payment is accepted and posted regardless of the beneficiary's account balance. The Receiving Bank assumes the risk of posting.
RTP vs. FedNow — Operational Comparison
| Attribute | RTP (TCH) | FedNow |
|---|---|---|
| Operator | The Clearing House (private, bank-owned) | Federal Reserve (government) |
| Launch | November 2017 | July 2023 |
| Transaction limit | $1,000,000 | $500,000 (default); up to $1,000,000 for eligible participants |
| Participant base | Large/mid-size banks; growing | Community banks, credit unions, broader reach expected |
| Message standard | ISO 20022 | ISO 20022 |
| RfP (Request for Payment) | Yes | Yes |
| Interoperability | Not yet — separate from FedNow | Not yet — industry working on interop standards |
| Settlement | TCH joint account at FRBNY | FRB master account (direct) |