FedNow vs RTP: US Instant Payment Rails for Analysts

FedNow and RTP are both ISO 20022 instant payment rails with a $10 million network limit, running 24x7x365, but they are not interchangeable. FedNow settles in Federal Reserve master accounts and returns money with a pacs.004; RTP settles against a prefunded joint account at the Federal Reserve Bank of New York and returns money with a fresh pacs.008. ACWP means a settled payment on hold, not a pending one. And neither rail requires a payee name check, so fraud control sits with the sending bank.

A corporate treasury team asks its bank to make supplier payments “instant”. The bank is live on RTP and has just joined FedNow. Half the suppliers bank somewhere reachable on only one network, the returns process was built for RTP, and the status screen shows “pending” for payments that already settled.

That is the US instant payments problem for an analyst: two rails, one standard, different rules. This piece sits in the scheme track of The ISO 20022 Reference, next to SEPA Instant and RTGS on ISO 20022.

What are FedNow and RTP, and how do they differ?

Current as of October 2026:

	FedNow	RTP
Operator	Federal Reserve Banks	The Clearing House (TCH)
Live since	20 July 2023	2017
Network limit	$10 million (pacs.008 and pacs.004)	$10 million (Operating Rule II.C.2)
Default participant limit	$100,000, configurable up to $10 million	Sending participant may set lower; receiving participant may not
Settlement	Participant’s Federal Reserve master account, or a correspondent’s	Prefunded joint account held at the Federal Reserve Bank of New York
Returns	pacs.004 payment return	New pacs.008 carrying the original local instrument
Request for payment	pain.013 and pain.014	pain.013 and pain.014
Hours	24x7x365	24x7x365
Participants	About 1,900 institutions on the Fed’s list dated 5 October 2026	Over 1,378 as of September 2026 (TCH figure)
Recent volume	5.0 million payments, $274.7 billion in Q2 2026	150 million payments, $621 billion in Q3 2026

Notice the volume gap. RTP’s latest quarter carried roughly thirty times FedNow’s payment count, while FedNow’s average payment is far larger (about $55,000 in Q2 2026, per the Fed’s statistics page). FedNow has more listed participants and thin traffic; RTP has fewer participants and far more traffic.

Which ISO 20022 messages do FedNow and RTP use?

Both are ISO 20022 native. The message families overlap; the usage rules do not. RTP’s Message Specification version 5.0 pins exact versions; take FedNow versions from its participant technical documentation.

Function	FedNow	RTP (spec v5.0)
Customer credit transfer	pacs.008	pacs.008.001.08
Status report	pacs.002	pacs.002.001.10
Status request	pacs.028	pacs.028.001.03
Return of funds	pacs.004	New pacs.008, original local instrument
Request for return	camt.056, answered by camt.029	camt.056.001.08, answered by camt.029.001.09
Request for payment	pain.013, answered by pain.014	pain.013.001.07, answered by pain.014.001.07
Request for information	camt.026, answered by camt.028	camt.026.001.07, answered by camt.028.001.09
Stand-alone remittance	Not listed in the FedNow Operating Procedures	remt.001.001.04
Liquidity between banks	pacs.009 (liquidity management transfer)	pacs.009.001.08
Payment acknowledgement by the receiver	No equivalent listed	camt.035.001.05

The returns row is the one that breaks shared code. On FedNow, a return is a pacs.004 that references the original. On RTP, a return is a brand new credit transfer, and the RTP specification requires it to use the local instrument of the original payment and repeat its parties (debtor, creditor, ultimate parties, intermediary agents). A bank that builds one returns engine and points it at both rails will produce valid XML that one network rejects or misreads. Returns, reversals, and recalls covers the general model; on US instant rails you need two implementations of it.

How do the $10 million limits actually work?

Both networks reached $10 million in 2025, in different steps.

Date	Change
18 April 2022	RTP limit raised from $100,000 to $1,000,000
9 February 2025	RTP limit raised from $1 million to $10 million
24 June 2025	FedNow limit raised from $500,000 to $1 million, with account activity thresholds
November 2025	FedNow limit raised to $10 million (announced 9 September 2025)

Two details change requirements.

FedNow has a default. Each participant’s customer credit transfer limit starts at $100,000 and the participant configures it up to $10 million. The liquidity management transfer (pacs.009) has its own default of $2,500,000. If your bank joined FedNow and never touched its profile, it is running at $100,000, and a corporate client promised “up to ten million” will see rejections.

RTP forbids a lower receive limit. Under Rule II.C.2 a sending participant may cap its senders, but a receiving participant may not set a lower limit for its receivers. Your inbound processing, posting, and fraud checks must handle a $10 million credit at three in the morning on a Sunday.

Keep both as owned configuration, not constants. These numbers moved four times in four years.

What does ACWP mean, and why is it a trap?

ACWP is “accept without posting” on both FedNow and RTP, and it is the status most often modelled wrong.

The receiving bank answers a pacs.008 with one of three responses: accept (ACTC), reject (RJCT), or accept without posting (ACWP). With ACWP, the network settles the payment with finality, but the receiving bank does not credit its customer yet because it needs time for a legal or compliance review.

On RTP, the receiving participant may use ACWP mainly when it has reasonable cause to need more time for that review (the rules also allow it for certain returns to a closed account). It is expected to decide by 11:59 p.m. local time on the next business day, except for sanctions reviews or when it needs information from another party such as a government agency. It then sends a follow-up payment acknowledgement to make the funds available, or refunds the sender. On FedNow, a participant using ACWP must reject and return the funds or make them available, and must send a pending (PDNG) update to the sender by the ACWP availability deadline.

So ACWP is a settled payment on hold, not an unsettled one. If your status model maps ACWP to “pending”, the ledger shows money that already left as in flight, reconciliation breaks, and a retry rule may resend a settled payment. Give it its own state and exits. ISO 20022 payment status codes covers the base meanings; here the scheme narrows them.

One warning for teams working across borders: Payments Canada’s Real-Time Rail uses ACWP in its pacs.002 to mean “accepted by instructed agent”, with no compliance-hold meaning. Same code, different scheme rule. Payments Canada for analysts covers that rail.

How do settlement and liquidity differ?

FedNow settles in the master accounts the Federal Reserve Banks hold for participants, or in a correspondent’s master account if the participant settles through one. Liquidity moves between participants with a liquidity management transfer, a pacs.009. LMTs run from 7 p.m. to 7 a.m. ET on weekdays and 24 hours a day on weekends and Federal Reserve holidays, when Fedwire is closed. A correspondent can also set a net send limit to protect its own master account balance while its respondents send.

RTP settles against the Prefunded Balance Account, a joint account held for all funding participants at the Federal Reserve Bank of New York. Each funding participant’s position in it is a record kept by the RTP system, and the account has paid interest since 20 July 2023. You fund it in advance. The Clearing House even publishes instructions for funding the RTP joint account with a FedNow liquidity management transfer, which tells you how the two rails interact over a weekend: FedNow becomes the way to top up RTP when Fedwire is shut.

The requirement that falls out is a weekend liquidity runbook: who watches the RTP prefunded position and the FedNow master account at 2 a.m. on a Saturday, which thresholds trigger a top-up, and which message moves the money.

What happens when an instant payment times out?

FedNow runs a 20 second timeout clock. Each receiving participant also reserves a response window of one to five seconds; FedNow checks that enough time remains on the clock before forwarding a payment. If the clock expires before the receiver answers, FedNow rejects the payment. The Operating Procedures tell the sender to wait at least 25 seconds from creating the payment before sending a pacs.028 status request.

RTP uses a five-leg flow. The sender’s pacs.008 goes to RTP, RTP forwards it, the receiver answers with a pacs.002, RTP settles, and RTP sends a final pacs.002 to both sides. If the receiver does not answer within the time-out period, RTP sends it a camt.056 system time-out and rejects the payment to the sender. The specification is blunt: a receiving participant must not make funds available until it has the fifth-leg pacs.002, and if that never arrives it should send a pacs.028 to find out.

Duplicates follow from timeouts. RTP defines exactly how to answer a resent payment flagged CpyDplct = DUPL: repeat the original outcome if the first one completed, reject with reason DUPL if it timed out. That is an idempotency rule written into the scheme, and it is worth a test case per branch.

How do request for payment and remittance work?

Both networks carry request for payment (RfP) as a pain.013, with the payer’s acceptance or refusal in a pain.014. An RfP moves no money. If the payer accepts, their bank sends a normal pacs.008 that references the request.

The rule layers differ. A Federal Reserve-convened work group published RfP market practices on 26 September 2023, focused on consumer to business bill payment, and the FedNow Operating Procedures cover RfP warranties. The Clearing House requires RfP senders to register and has a rules interpretation on permissible RfP uses, effective 15 April 2025.

Remittance is richer on RTP: beyond the structured remittance in the pacs.008, RTP has a stand-alone remittance advice (remt.001) for detail that will not fit, a real difference for invoice-level corporate reconciliation.

What fraud controls do FedNow and RTP give you?

This is where the US differs most from the UK and the EU. RTP Operating Rule V.D says a receiving participant may rely on the account number and has no obligation to confirm that the name and account number match. There is no mandated payee name check equivalent to Verification of Payee in Europe or Confirmation of Payee in the UK, and no scheme-wide reimbursement rule for authorised push payment fraud.

What the networks do provide:

FedNow

• A block list: reject transactions to or from specific accounts at other institutions.
• Network and participant transaction limits.
• Account activity thresholds (live 24 June 2025): value and velocity limits by customer segment.
• A network intelligence API (early adopters from 28 April 2026) returning receiver account-level data observed on the network, to support a send, hold, or review decision.
• The Fed has said it is exploring Payee Name Verification, part of its FedDetect services, for real-time use. Exploring, not live.

RTP

• Mandatory fraud reporting through the network: a camt.056 request for return of funds with reason FRAD for unauthorised payments, and since 31 March 2026 UAPA for payments fraudulently induced under false pretenses (UPAY where the RfP warranty claim conditions are met).
• From 1 March 2027, those reports must go out no later than two business days after the bank determines the payment was fraudulent.
• Payment transparency rules: the debtor name field must hold the sender’s legal name, not a nickname or a reference. A temporary exception for instant account validation codes in the debtor name ends on 31 January 2027, after which the code moves to the unstructured data field.

The design consequence: on US instant rails, the sending bank owns the authorised push payment risk. Write its controls into the requirements as explicit pre-settlement steps, each with a latency budget, the way the ten second rule forces it in SEPA.

How does this relate to Fedwire’s ISO 20022 migration?

Fedwire Funds moved to ISO 20022 on 14 July 2025 in a single-day cutover, covered in RTGS on ISO 20022. FedNow was ISO 20022 from its first day. So a US bank on all three rails now runs at least three ISO 20022 profiles for domestic dollar payments: Fedwire, FedNow, and RTP, plus CHIPS and CBPR+ for cross-border.

The trap is assuming a pacs.008 built for Fedwire is valid on FedNow because both are Federal Reserve services. Element usage, code lists, limits, and status flows differ: the usage guidelines problem in its purest form. Reuse the data mapping; never reuse the validation profile.

One new interaction to watch: RTP’s rules from 4 October 2026 introduce One Leg Out (OLO) payments, where one end of the payment is outside the United States, with a new OLO local instrument and a UETR defined in the rules. Early adopters can opt in now, and all participants must be able to receive inbound OLO payments from 31 March 2028. That puts a cross-border leg, and its screening and data requirements, onto a domestic instant rail.

FedNow, RTP, or both?

The business question is reach, then cost, then operating load. Which payment rail? sets out the general method; for US instant payments it reduces to three rules.

1. Reachability per rail. Build a lookup from the Fed’s participant list (published as a routing number file) and RTP’s participant directory, refreshed on a schedule with an owner. A stale entry produces a reject that looks like a system fault.
2. Preferred rail and fallback. Decide which rail wins when both reach the beneficiary, and what happens when neither does: ACH, Fedwire, queue, or fail. Each changes speed and finality, so tell the client.
3. Limit check before routing. A $3 million payment to a FedNow-only bank whose participant limit is still $100,000 fails on the receive side, not yours.

For the payments domain behind this, Break Into Banking covers the domain and API Testing and QA Mastery for BAs covers turning these rules into test suites.

What should an analyst test?

Start from the rules above, one case per branch.

• A payment at exactly the participant limit, one cent over, and at the $10 million network limit, on each rail.
• An inbound RTP payment above your own outbound customer limit, asserting it is accepted (receivers cannot set a lower limit).
• A receiver ACWP response, asserting the sender shows “settled, funds on hold”, not “pending”, and that the follow-up acknowledgement or refund moves it to a final state.
• A FedNow timeout at 20 seconds, asserting no pacs.028 is sent before 25 seconds and the customer sees a clear failure.
• An RTP payment where the fifth-leg pacs.002 never arrives, asserting the receiving side does not credit the customer and sends a pacs.028.
• A resent RTP payment flagged DUPL, once after a completed original and once after a timed-out original, asserting the two different answers.
• A return on each rail: pacs.004 on FedNow, new pacs.008 with the original local instrument and parties on RTP.
• A fraud report on RTP, asserting the camt.056 carries UAPA for a scam payment and FRAD for an unauthorised one.
• A beneficiary reachable only on the non-preferred rail, asserting the fallback and the customer message.
• A weekend liquidity top-up into the RTP prefunded account by FedNow LMT, asserting the position updates before the next outbound payment.

To practise reading a payments contract for gaps like these, the free Analyze a payment API mission is a good warm-up.

The takeaway

FedNow and RTP look alike from a distance: ISO 20022, instant, final, 24x7x365, $10 million. Up close they settle differently (master accounts against a prefunded joint account at the New York Fed), return money differently (pacs.004 against a new pacs.008), and handle timeouts with different flows. ACWP means a settled payment on hold on both, and it needs its own state.

The bigger difference from Europe and the UK is fraud. Neither network obliges the receiving bank to match name to account, so the sending bank owns authorised push payment risk and has to build its controls before release. Route by reachability first, keep limits as configuration, write a weekend liquidity runbook, and test every branch where the two rulebooks disagree. The rest of the scheme track is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Instant Payments, FedNow, RTP, ISO 20022, Systems Analysis, Banking