FedNow Architecture

Prerequisite: Payment Rails

Your customer initiates a $2,000 payment at 2 AM on a Saturday. ACH won’t settle until Monday. Fedwire is closed — its operating hours end at 7 PM ET on weekdays. RTP could work, but your bank isn’t a Clearing House member. The payment sits in a queue for 40 hours, and your customer calls Monday morning asking why the money hasn’t moved. FedNow exists because the Federal Reserve decided that instant payments should not depend on private network membership or business-day calendars.

Position in the US Payments Landscape

The United States has four interbank payment rails, each with a different settlement model, speed, and access profile.

Rail	Operator	Settlement	Speed	Availability	Max amount
Fedwire	Federal Reserve	RTGS	Minutes	Weekdays 9 PM–7 PM ET	No limit
ACH	Federal Reserve / EPN	Deferred net	Hours to days	Batch windows	$1M (same-day)
RTP	The Clearing House	Pre-funded real-time	Seconds	24/7/365	$10M
FedNow	Federal Reserve	RTGS	Seconds	24/7/365	$500K (default)

RTP launched in 2017 and proved the demand for real-time payments. But RTP is operated by The Clearing House, a private company owned by 22 of the largest US banks. Smaller institutions — community banks, credit unions — either cannot join or face integration costs disproportionate to their transaction volume. The Fed built FedNow to provide the same capability through the public infrastructure that all depository institutions already connect to.

The distinction between RTP and FedNow is not technical — both settle in seconds, both run 24/7, both use ISO 20022 messaging. The distinction is access. Every depository institution in the US already has a Federal Reserve master account. FedNow settles against that account. No new banking relationship, no private network membership, no Clearing House ownership stake required.

Real-Time Gross Settlement

FedNow is an RTGS system. Each payment settles individually and immediately against the sender’s and receiver’s Federal Reserve master accounts. There is no netting, no batching, no end-of-day settlement cycle.

When a $2,000 payment clears through FedNow, the Federal Reserve debits the sending bank’s master account by $2,000 and credits the receiving bank’s master account by $2,000. The settlement is final the instant the Fed posts the entries. There is no provisional credit, no pending state, no window during which the transaction can be reversed by the system.

This is the same settlement model as Fedwire — individual gross settlement against Fed accounts. The difference is speed and availability. Fedwire processes a payment in minutes during business hours. FedNow processes a payment in seconds, around the clock.

RTGS finality means there is no chargeback, no return mechanism, no system-level reversal. If the sending institution submits a payment, and FedNow settles it, the money has moved. The only recourse for an erroneous payment is a request to the receiving institution — which they are under no obligation to honor.

Message Flows

FedNow uses ISO 20022 message formats. The core message flow for a credit transfer involves three message types.

Sender Bank (ODFI)                FedNow Service              Receiver Bank (RDFI)
     |                                 |                             |
     |--- pacs.008 (Credit Transfer) ->|                             |
     |                                 |--- pacs.008 --------------->|
     |                                 |                             |
     |                                 |<--- pacs.002 (Accept/Reject)|
     |<--- pacs.002 ------------------|                             |
     |                                 |                             |

The pacs.008 message carries the payment instruction — amount, sender account, receiver account, remittance data. The FedNow Service validates the message against participant limits, checks the sender’s liquidity position, and forwards it to the receiving institution. The RDFI responds with a pacs.002 — either accepting or rejecting the payment. The entire cycle must complete within 20 seconds.

FedNow also supports the pain.013 Request for Payment (RFP) flow. The payee’s bank sends a request to the payer’s bank, which presents the request to the payer for approval. If approved, the payer’s bank initiates a standard pacs.008 credit transfer. RFP enables bill payment and invoicing use cases without requiring the payer to initiate the transaction.

Message	ISO 20022 type	Direction	Purpose
Credit Transfer	pacs.008	ODFI → FedNow → RDFI	Move money
Payment Status	pacs.002	RDFI → FedNow → ODFI	Accept or reject
Request for Payment	pain.013	Payee bank → FedNow → Payer bank	Request funds
RFP Response	pain.014	Payer bank → FedNow → Payee bank	Accept/reject/modify request
Account Report	camt.052	FedNow → Participant	Liquidity position report

All messages are XML-encoded ISO 20022 with specific FedNow implementation guides constraining the optional fields. The rich data payload — structured remittance information, purpose codes, regulatory reporting fields — is one of the architectural advantages over the fixed-width NACHA format used by ACH.

Participant Requirements

Any depository institution with a Federal Reserve master account can join FedNow. This includes commercial banks, savings institutions, and credit unions — roughly 10,000 institutions in the US.

Participants choose between two integration paths:

FedLine Direct. A dedicated network connection to the Federal Reserve. The institution runs its own ISO 20022 message processing, handles its own liquidity management, and integrates directly with FedNow APIs. Large banks and core banking vendors with existing FedLine infrastructure use this path.

Through a service provider. A third-party processor — a core banking vendor like Jack Henry, Fiserv, or FIS — connects to FedNow on behalf of multiple institutions. The service provider handles message formatting, liquidity monitoring, and fraud screening. The institution’s integration is with their existing core banking system, not with FedNow directly. Community banks and credit unions with limited engineering capacity typically take this path.

Participants must also decide their operational role:

Role	Can send	Can receive	Typical participant
Receive-only	No	Yes	Initial adoption — lower risk, simpler integration
Send and receive	Yes	Yes	Full participation
Settlement-only	N/A	N/A	Correspondents settling on behalf of respondent banks

Most institutions start as receive-only. Receiving is lower risk — you are credited funds, not debited. Send capability requires fraud controls, liquidity management, and customer-facing integration, each of which takes time to build or procure.

Liquidity Management

FedNow settles against Federal Reserve master accounts in real time. Every outbound payment immediately reduces the sender’s account balance. If the balance is insufficient, the payment is rejected — there is no overdraft facility on FedNow, no intraday credit, no deferred settlement to give you time to fund.

This creates a liquidity management problem that does not exist with batched systems. ACH nets debits and credits across a settlement window, so you need enough to cover the net position, not the gross. FedNow settles gross — every outbound dollar must be in the account at the moment the payment processes.

At 3 AM on a Sunday, your institution’s treasury team is asleep. Payments are still processing. Your master account balance is draining. FedNow provides two tools to manage this:

Liquidity transfer messages. Participants can move funds between their Fedwire and FedNow settlement accounts using the camt.050 liquidity transfer message. This allows pre-positioning funds in the FedNow settlement account during expected high-volume periods. The transfer settles immediately — it is a book-entry move between two accounts at the same Federal Reserve Bank.

Joint account structures. Multiple affiliated institutions can designate a joint account for FedNow settlement, pooling liquidity across entities. A bank holding company with four subsidiary banks can settle all FedNow activity from a single pool rather than pre-funding four separate accounts.

The practical impact: institutions must forecast their FedNow payment volumes and pre-position sufficient liquidity, especially for nights and weekends when other funding mechanisms are unavailable. Under-funding means rejected payments. Over-funding means idle capital earning less than it could in overnight markets.

See Payment Rails. The handbook covers the difference between RTGS and deferred net settlement. FedNow’s liquidity requirements are a direct consequence of the RTGS model — every payment settles individually, so every payment requires available funds.

Transaction Limits and Value Controls

FedNow imposes a default per-transaction limit of $500,000. Participants can set their own limit lower — a credit union might cap at $100,000 — but cannot exceed the system maximum. The Fed has stated it will review and potentially increase the limit as adoption matures.

Limit type	Default	Configurable
Per-transaction maximum	$500,000	Participant can lower
Daily aggregate	No system limit	Participant-defined
Per-customer	No system limit	Participant-defined

RTP’s limit is $10 million per transaction — 20x higher than FedNow’s default. For large-value payments, Fedwire has no per-transaction limit at all. FedNow’s limit positions it as a retail and small-business payment rail, not a wholesale settlement mechanism.

The 20-Second Window

FedNow mandates an end-to-end processing window of 20 seconds. The ODFI submits the pacs.008. The FedNow Service validates and forwards it. The RDFI processes the payment and responds with a pacs.002. If the RDFI does not respond within 20 seconds, the payment times out.

The time budget breaks down roughly as follows:

Step	Allocation
ODFI → FedNow transmission	~1–2 seconds
FedNow validation and routing	~1–3 seconds
FedNow → RDFI transmission	~1–2 seconds
RDFI processing and response	~10–14 seconds
RDFI → FedNow → ODFI response	~1–3 seconds

The RDFI has the largest window — roughly 10–14 seconds to run fraud checks, sanctions screening, account validation, and posting logic. For a bank running these checks against external services (OFAC lists, fraud models, account verification APIs), the latency budget is tight. A fraud model that takes 3 seconds to score, combined with a sanctions check that takes 2 seconds and a core banking post that takes 4 seconds, consumes most of the available time.

If the RDFI times out, the payment fails. The ODFI receives no acceptance, the sender’s master account is not debited, and the payment does not settle. The ODFI’s system must handle this as a terminal failure or a retryable error, depending on the institution’s policy. FedNow does not automatically retry.

Faster Payments, Faster Fraud

Irrevocable settlement in seconds creates a fraud asymmetry that batch systems do not have. An ACH debit can be returned for unauthorized use up to 60 calendar days later. A FedNow credit transfer, once settled, cannot be reversed by the system.

The fraud attack surface shifts from post-settlement reversal (where the bank recovers funds through the return process) to pre-settlement prevention (where the bank must detect and block fraud before the payment settles). The 10–14 seconds the RDFI has to process the payment is also the window to detect account takeover, social engineering, and authorized push payment (APP) fraud.

Fraud type	ACH defense	FedNow defense
Unauthorized debit	60-day return window	N/A (credit-push only)
Account takeover	Post-settlement investigation, return	Pre-settlement detection, block
Social engineering / APP fraud	Limited — payment was “authorized”	Limited — same problem, faster timeline
Mule accounts	Suspicious activity reports, delayed settlement	Real-time behavioral scoring, network analysis

FedNow’s credit-push-only model eliminates unauthorized debit fraud entirely — the sender always initiates the payment, so there is no pull mechanism to exploit. But authorized push payment fraud — where the customer is tricked into sending money willingly — is harder under instant settlement because the funds are gone before the customer realizes the mistake.

The Fed’s approach: require participants to implement fraud controls but do not prescribe what those controls must be. Each institution determines its own risk appetite and builds or buys accordingly. The FedNow Service itself performs basic validation — message format, participant status, value limits — but does not run fraud detection.

The Cross-Border Gap

FedNow is a domestic US system. It settles payments between US depository institutions in US dollars. A payment from a US bank to a European bank cannot travel over FedNow — it requires SWIFT, correspondent banking, or a cross-border overlay.

This is where instant payments stop being instant. A $2,000 domestic payment settles in seconds over FedNow. The same $2,000 sent to a bank in Germany takes the SWIFT correspondent path — 2 to 5 intermediary banks, each adding processing time and fees, with the payment arriving in 1 to 5 business days.

The architectural gap is not accidental. Domestic instant payment systems — FedNow, SEPA Instant, Faster Payments, PIX, UPI — each operate within a single currency and a single regulatory jurisdiction. Cross-border instant settlement requires solving currency conversion, multi-jurisdictional compliance, and multi-system finality simultaneously. No production system has solved all three at the scale FedNow operates domestically.

BIS initiatives like Project Nexus aim to interlink domestic instant payment systems — connecting FedNow to SEPA Instant to India’s UPI through a coordinating layer. The technical challenge: each system has different message formats, finality definitions, timeout windows, and liquidity requirements. Bridging them requires a translation layer that preserves the guarantees of each system while adding cross-border capabilities.

See Cross-Border Settlement Mechanics. The grimoire covers the approaches companies use to bridge the cross-border gap — virtual IBANs, tokenized settlement, multi-rail routing — that work around the limitation of domestic-only instant payment systems.

Adoption Trajectory

FedNow launched in July 2023 with 35 early-adopter institutions. Adoption has followed a predictable curve: large banks and core banking processors first, community institutions following as their service providers integrate.

Date	Participants	Notable milestones
July 2023	35	Launch with early adopters
End 2023	~200	Major core processors (Jack Henry, Fiserv) onboarded
Mid 2024	~900	JPMorgan Chase, Wells Fargo joined
2025	~1,200+	Continued organic growth

RTP, with a seven-year head start, has roughly 800 participating financial institutions covering about 65% of US demand deposit accounts. FedNow’s adoption trajectory is steeper — partly because FedLine infrastructure already exists at most institutions, and partly because the receive-only option lowers the barrier to initial participation.

The volume comparison reflects the maturity gap. RTP processes approximately 1 million transactions per day. FedNow’s daily volume is substantially lower but growing. Neither system has displaced ACH for bulk payments — ACH still processes roughly 80 million transactions per day. FedNow and RTP are additive capacity for use cases where same-day ACH’s hours-long settlement is too slow and Fedwire’s per-transaction cost ($0.50–$1.00 per message) is too high for the payment size.

FedNow’s per-transaction pricing — $0.045 per credit transfer — positions it as the lowest-cost instant rail. RTP charges $0.045 per credit transfer as well, with an additional fee for request-for-payment messages. Both are orders of magnitude cheaper than Fedwire for small-to-mid-value payments.