RTP Network

The RTP network is The Clearing House’s U.S. instant-payment system for eligible dollar credit transfers between participating financial institutions. It processes payments individually, operates around the clock, and provides final interbank settlement using a prefunded settlement model.

Here, RTP means the named payment network, not the International Monetary Fund’s reserve tranche position, which also uses the acronym RTP. A consumer or business accesses the payment network through a participating bank, credit union, or payment service; The Clearing House does not provide an ordinary retail account or payment app to the customer.

Key Takeaways

• The RTP network is a private-sector payment system operated by The Clearing House and launched in 2017.
• It supports U.S. dollar credit-push payments: the sender instructs its institution to send funds. The network does not originate account debits.
• Payment messages are processed individually and continuously, including nights, weekends, and holidays.
• A sending participant cannot revoke or recall a payment after submitting it to the network.
• Settlement becomes final when the system records the sending and receiving position entries for an accepted payment.
• A receiving participant that sends an ordinary accept response must provide immediate funds availability to the receiver under the current rules.
• The settlement model uses a special prefunded balance account and continuously updated participant positions, not a direct debit and credit to Federal Reserve master accounts for every customer payment.
• A request for payment or request for return is a non-payment message. Neither moves money by itself.
• The current network credit-transfer limit is $10 million, but a financial institution can impose a lower customer, account, or channel limit.

What the RTP Network Does

The RTP network connects eligible financial institutions for instant clearing, settlement, and payment-related messaging. It can support account-to-account transfers, business disbursements, supplier payments, insurance payments, payroll-related payments, brokerage transfers, bill payments, and other eligible use cases.

The network can:

• validate payment messages and participant routing;
• reserve sufficient prefunded capacity before releasing a payment message;
• deliver the payment message to the receiving participant;
• receive an accept, accept-without-posting, or reject response;
• record settlement entries for an accepted payment;
• send immediate payment status information;
• carry remittance advice and payment acknowledgements;
• transmit requests for payment, information, or return of funds; and
• provide reports for participant funding, position monitoring, and reconciliation.

The network does not itself:

• hold the customer’s ordinary deposit account;
• decide which customers or account types a participant supports;
• prove that the sender intended the underlying purchase or obligation;
• guarantee that beneficiary instructions are genuine;
• create a debit pull from a request for payment;
• guarantee recovery of a mistaken or fraudulent payment; or
• make every payment described by an app as “instant” an RTP network payment.

Participants, Accounts, and Evidence

Institutions can connect directly or through a third-party service provider. A technical provider can transmit and process messages, but the participant remains responsible for its obligations under the network rules and applicable law.

Participation can also differ by function. An institution may receive RTP payments without offering customer sending, or may support only selected accounts and use cases. Check the institution’s current service and RTP-enabled routing records rather than assuming that one successful payment establishes universal reachability.

How an Accepted RTP Payment Moves

    flowchart TD
	    A["Sender authorizes a credit transfer through its financial institution"] --> B["Sending participant authenticates, screens, and submits the payment message"]
	    B --> C["RTP validates the message and confirms sufficient prefunded capacity"]
	    C --> D["RTP reserves the amount and releases the message to the receiving participant"]
	    D --> E["Receiving participant validates the account and sends an accept response"]
	    E --> F["RTP records simultaneous sending and receiving position entries"]
	    F --> G["Receiving participant makes funds available to the receiver"]
	    G --> H["Participants and customers reconcile the payment reference and purpose"]

A standard accepted payment follows these stages:

1. The sender instructs its financial institution to make a credit transfer.
2. The sending institution authenticates the sender and checks the account, amount, receiver information, limits, fraud indicators, sanctions controls, and payment purpose.
3. The sending participant submits the payment message to the RTP network.
4. The system validates the message, participant status, routing, and available prefunded position.
5. If sufficient capacity exists, the system reserves the amount by reducing the applicable sending-side position and releases the payment message to the receiving participant.
6. The receiving participant validates the identified account and sends an accept, accept-without-posting, or reject response.
7. For an accept response, the system records the sending and receiving entries that complete final settlement.
8. The receiving participant credits the receiver and makes the funds available.
9. Status, acknowledgement, remittance, account, and business records support reconciliation.

If the payment is rejected or cancelled before settlement, the reserved amount is released under the rules. A rejected instruction is not a settled payment, and a system receipt is not proof that all later stages occurred.

Payment Status Is Not One Event

Use the network message ID and related references to connect these records. A customer-facing label such as “sent,” “received,” or “complete” is useful only when the institution can explain which operational stage it represents.

How Prefunded Settlement Works

The RTP network does not settle every customer payment by directly debiting the sender bank’s Federal Reserve master account and crediting the receiver bank’s master account. Instead, the current rules use a special Prefunded Balance Account established for the joint benefit of funding participants and funding agents, together with positions recorded by the RTP system.

The main concepts are:

• Prefunded requirement: minimum funding that The Clearing House assigns under the rules to a participant or funding provider with a funding obligation.
• Opening prefunded position: the recorded position at the start of a reconciliation window.
• Net position: changes produced by payments, funding, disbursements, and other applicable entries during the window.
• Current prefunded position: the continuously updated amount used to determine available sending capacity.
• Net send limit: an additional limit applicable to a member of a non-funding group under its funding arrangement.

Before releasing a payment message, the system checks that the applicable current prefunded position is at least the payment amount and, where relevant, that the payment would not breach a net send limit. The amount is then reserved. If the receiver accepts, the system simultaneously records a decrease to the sender’s net position and an increase to the receiver’s net position. Those entries complete settlement.

This design matters operationally. A participant can have money in its customer account systems yet lack sufficient network sending capacity for a particular payment. Participants and funding providers must monitor their positions continuously, respond to low-balance alerts, and provide supplemental funding when required.

Funding can involve Fedwire Funds Service and, for enabled arrangements, FedNow liquidity management transfers. These transfers fund or disburse from the prefunded structure; they are not the settlement entries for each RTP customer payment.

Finality and Receiver Funds Availability

Under the current RTP rules, settlement is complete when the system records both the sending-position decrease and receiving-position increase. Completion constitutes final settlement and discharges the sending participant’s payment obligation to the receiving participant for that payment message.

For an ordinary accept response, the receiving participant must make funds available to the identified receiver immediately. Keep these events separate during an investigation:

• Network settlement: RTP completes final position entries between participants.
• Customer posting: the receiving institution credits the receiver’s account.
• Funds availability: the receiver can use the credited amount.
• Payment acknowledgement: a message can indicate receipt or application.
• Business reconciliation: the receiver matches the payment to the correct invoice, loan, policy, or other obligation.

The rules provide an accept without posting response for a limited review involving sanctions laws applicable to or followed by the receiving participant. It is not a general pending status for ordinary account, fraud, or operational delays. The receiving participant must follow the applicable investigation, acknowledgement, posting, refund, and notification requirements.

Final interbank settlement also does not determine every legal issue between customers, institutions, merchants, or service providers. Consumer and commercial transfers can be subject to different laws, agreements, warranties, and allocation-of-loss rules.

Continuous Operation and Transaction Limits

The RTP network operates continuously. Its RTP Day follows the calendar day from 12:00 a.m. through 11:59:59 p.m. ET, while reconciliation reports can cover separate defined windows within that day.

Continuous network operation does not mean every customer has uninterrupted access. Customer channels, participant systems, service providers, fraud-review teams, and downstream account platforms can have outages or maintenance. A bank can also restrict sending by account, customer, use case, amount, or risk profile.

As of this article’s review date, the network credit-transfer limit is $10 million. That maximum does not mean:

• every participating institution offers $10 million payments;
• every customer or account qualifies for that amount;
• a payment below the limit will pass all controls; or
• the RTP network is the appropriate rail for every high-value transfer.

Check the current operating rules and the institution’s current product limits before relying on a stated maximum. Network rules, message specifications, and participant capabilities can change.

Return Requests and Return Payments

A sending participant cannot cancel or amend an RTP payment after submitting it to the network. If a settled payment was mistaken, duplicated, or suspected to involve fraud, the sending side can use a request for return of funds message.

That message does not reverse settlement. Under the current rules, the receiving participant must respond within the applicable timeframe but is not obligated merely by the request to return the funds. If value is returned, it moves through a separate credit payment or another permitted mechanism, linked where required to the original reference.

The distinction is important:

• Rejection: original payment does not settle.
• Request for return: non-payment message asking the receiving side to return value.
• Response to request: reports how the request was handled.
• Return payment: separate value transfer back toward the original sender.

Anyone who notices a suspected fraud or error should contact the relevant financial institution immediately through a verified channel and preserve the amount, timestamp, payment reference, account activity, beneficiary instructions, and communications. Fast reporting supports investigation but does not guarantee recovery.

Request for Payment Is Not a Debit

A request for payment (RFP) is a payment-related message asking a customer to initiate an RTP payment. It can carry an amount, requester information, due date, and invoice or account reference, but it does not itself withdraw funds.

If the recipient chooses to pay, the recipient authorizes a separate credit-push payment through its financial institution. That payment then follows the normal validation, reservation, response, settlement, and availability process.

Before responding to an RFP, verify:

• the requester’s identity through trusted records;
• the amount, due date, and payment purpose;
• the invoice, policy, loan, or account reference;
• whether the obligation was already paid; and
• whether the destination information matches prior verified instructions.

An RFP can improve billing and reconciliation, but an impersonator can also use a plausible request to pressure someone into authorizing a real payment. Urgency, changed instructions, and an unexpected payment destination are reasons for independent verification.

ISO 20022 and Related Messages

The RTP technical specifications use ISO 20022 terminology and message structures. The credit-transfer message is the value-bearing message that results in settlement. Other messages support status, requests for payment, requests for information, return requests, acknowledgements, and remittance advice.

Structured data can improve routing, screening, reconciliation, and customer displays when institutions preserve and use it correctly. It does not prove that:

• the sender’s device or credentials were secure;
• the payment purpose was legitimate;
• the receiver was the intended commercial counterparty;
• every required control was performed; or
• the receiver applied the payment correctly.

Payment-message data, network settlement, customer-account entries, and business records answer different questions. A reliable audit trail connects them without treating one layer as proof of all the others.

Worked Example: After-Hours Insurance Payment

Assume an insurer approves a $18,750 property-damage payment at 9:15 p.m. ET on Saturday. The policyholder’s bank is reachable on the RTP network, and both institutions support the required service.

Suppose the insurer’s portal times out after submission. Sending the payment again without checking the original message ID creates duplicate-payment risk. The operations team should first determine whether the first instruction was never submitted, rejected, reserved and cancelled, or accepted and settled.

If the policyholder reports the payment as missing, the institutions should distinguish network settlement from account posting and claim application. A settled RTP record is strong evidence of interbank completion, but it does not by itself show what appeared in the customer’s interface or whether the claim system used the correct reference.

RTP Compared With Other U.S. Payment Methods

FedNow and RTP can both support instant credit transfers, but the names are not interchangeable. Identify the operator, participant routing, message reference, settlement record, and governing rules for the actual transaction.

Risks and Controls

• Authorized-payment fraud: a customer can be deceived into approving a valid message to a fraudster.
• Account takeover: stolen credentials or a compromised device can produce an apparently authorized instruction.
• Irrevocability: a submitted payment cannot be revoked or recalled, and final settlement narrows recovery options.
• Duplicate payment: retrying after an uncertain status can send the amount twice.
• RFP fraud: an unexpected or altered request can impersonate a legitimate biller, supplier, or executive.
• Routing risk: incorrect or stale account and routing information can misdirect value or cause rejection.
• Liquidity risk: insufficient prefunded capacity or a binding limit can prevent message release.
• Availability risk: a customer channel, participant, service provider, or account platform can fail while the network remains online.
• Compliance risk: sanctions, anti-money-laundering, fraud, legal-order, and participant-rule requirements can affect processing.
• Reconciliation risk: network, account, and business systems can use inconsistent IDs, timestamps, or statuses.

Useful controls include independent verification of new payment instructions, strong authentication, role separation, transaction and velocity limits, duplicate detection, verified routing data, status-aware retry logic, prefunded-position monitoring, protected logs, round-the-clock escalation, and end-to-end reconciliation. No control eliminates all fraud, error, outage, or recovery risk.

Common Mistakes

• Using bare “RTP” without distinguishing the payment network from reserve tranche position.
• Calling every fast transfer an RTP network payment.
• Describing the network as a consumer app or customer account provider.
• Saying an RTP request for payment pulls money from an account.
• Treating a technical receipt or reserved amount as final settlement.
• Assuming final network settlement proves customer posting or invoice application.
• Describing every customer payment as a direct transfer between Federal Reserve master accounts.
• Assuming continuous network operation guarantees uninterrupted bank-channel access.
• Treating the $10 million network limit as every institution’s customer limit.
• Assuming a request for return automatically reverses or guarantees recovery of a settled payment.
• Using RTP, FedNow, Same Day ACH, Fedwire, and CHIPS as interchangeable labels.

How to Evaluate an RTP Network Payment

1. Confirm that the transfer actually used The Clearing House’s RTP network.
2. Identify the sender, receiver, sending and receiving participants, service providers, and funding arrangement where relevant.
3. Match the amount, routing data, account information, message ID, payment purpose, remittance fields, and timestamp.
4. Separate customer authorization, network receipt, capacity reservation, receiving response, final settlement, and customer availability.
5. Review any accept-without-posting, rejection, timeout, request for return, response, or return payment.
6. Trace uncertain statuses before sending a replacement payment.
7. Reconcile the network record to customer-account entries, position reports, invoices, claims, and general-ledger records.
8. Check the current operating and participation rules, technical specifications, routing records, and institution limits.
9. Escalate fraud, consumer-protection, sanctions, liability, or legal questions to the relevant institution or qualified professional.

Official Resources

• The Clearing House: RTP Network for Financial Institutions explains the network’s credit-push design, continuous operation, immediate availability, finality, eligibility, connection options, and current transaction limit.
• RTP Document Library provides the current and upcoming operating and participation rules, product guides, schedules, technical specifications, and compliance materials. Verify the effective date before applying a rule.
• RTP Technical Documentation describes payment, status, request-for-payment, return-request, acknowledgement, and remittance messages.
• RTP Participants and Routing/Transit Numbers provides regularly updated routing information for reachable institutions.
• RTP Prefunded Settlement Model and Reconciliation explains the funding-participant position and reconciliation model; use it with the current rules.
• RTP Request for Return of Funds Guidelines explains the return-request process; use it with current rules and institution procedures.

Official network material does not establish whether a specific payment was authorized, correctly addressed, legally valid, or recoverable. Use the actual participant, account, message, and business records for a particular case.

FAQs

Related Terms

• FedNow Service: Federal Reserve Banks’ separate instant credit-transfer service.
• Fedwire Funds Service: Federal Reserve real-time gross settlement service for eligible dollar wires.
• ACH: U.S. batch network supporting credit and debit entries.
• Credit Transfer: Payment initiated from the payer side to credit a receiver.
• RTGS: General settlement model for accepted payments processed individually in real time.
• ISO 20022: Message framework used in RTP technical specifications.
• Routing Number: U.S. institution identifier used with network-specific routing records.
• Settlement Risk: Risk that an expected payment obligation does not settle as intended.
• Reconciliation: Matching network messages, position entries, customer accounts, and business records.

Educational Use

This article provides general financial education. It is not payment-operation, banking, fraud-recovery, accounting, legal, regulatory, cybersecurity, sanctions, compliance, or transaction-specific advice. Use current RTP rules, institution records, account agreements, and qualified professional guidance for an actual payment.