FedNow API in 2026: No Payment Endpoint

The Federal Reserve publishes a REST API for the FedNow Service, and not one of its endpoints can move a dollar. You can ping it, pull your master account balance, download the participant list and query receiver-account risk insights. To actually send a payment you deploy IBM MQ, install a server certificate, and push a pacs.008 over a FedLine connection that starts at £-equivalent five figures a year.

That gap between what people mean by "the FedNow API" and what the Fed actually operates is the single most common source of wasted architecture time I see on US instant payments projects. Here is what the rail really exposes.

What Is the FedNow API and What Can It Actually Do?

The FedNow Service Operating Procedures (April 2026, v3.6) are explicit: the service offers two methods for exchanging data, APIs and MQ, and "APIs are optional, while FedNow ISO 20022 messaging is required."

Four Fed-operated APIs exist:

Network Intelligence went to early adopters on 28 April 2026 and has to be enabled by the Reserve Banks per managed-RTN group on request. I wrote about that launch when it happened in FedNow's network intelligence API.

There is no payment-initiation endpoint. There is no plan announced for one. If a vendor sells you "the FedNow API" and it accepts a POST that debits a customer, you are buying their abstraction over MQ, not the Fed's.

How to Connect to FedNow: FedLine, MQ and Certificates

Four connectivity options exist: new or existing FedLine Direct, Advantage or Command. Third-party service providers must establish FedLine Advantage or higher. Lead times run 90 to 120 days for a new FedLine Direct connection, around 30 days to reconfigure an existing one. The 2026 schedule puts Advantage at $415 to $570 per month by tier, Direct Plus at $5,750 and Premier at $11,000, before bandwidth add-ons running $1,700 a month for 10Mbps up to $11,000 for 200Mbps.

On top of the pipe you need three separate credential sets, and teams routinely discover the third late: a FedNow server certificate plus IBM MQ client middleware for ISO messaging; active public keys for message signature and a reliable time server; then a distinct API certificate, separate API signature keys and a FedNow Endpoint ID header for the four APIs above.

Per-item pricing is 4.5 cents for a pacs.008, and the first 2,500 credit transfers each month carry a matching discount, so they are free. The $25 per RTN monthly participation fee is discounted to $0.00 for 2026. The marginal cost is trivial. The fixed cost of touching the rail directly is a five-figure annual FedLine bill, certificate lifecycle management, an MQ deployment and 24×7 on-call, on top of eligibility for a Federal Reserve master account. That arithmetic is why 53 certified service providers exist and why most teams sit behind one.

Which ISO 20022 Messages FedNow Uses

FedNow is ISO 20022, but the in-scope set is narrower and more opinionated than base ISO. The messages that matter:

• pacs.008 Customer Credit Transfer. The only customer payment order.
• pacs.002 Payment Status Report. Carries ACTC, ACSC, RJCT, ACWP, ACCC, PDNG, BLCK.
• pacs.028 Payment Status Request. Works against pacs.008, pacs.004, pacs.009 and pain.013.
• pacs.009 FI Credit Transfer, for liquidity management transfers only.
• camt.056 → camt.029 → pacs.004 for returns. Note that a pacs.004 is a new credit transfer, not a reversal, and it follows the same processing path as a pacs.008.
• pain.013 / pain.014 Request for Payment and its response.
• camt.060 → camt.052 for reporting. FedNow reuses camt.052 for three different reports: Account Balance, Account Activity Totals and Account Activity Details.
• admi.* for system messages, including admi.007 receipt acknowledgement and admi.006 retrieval requests capped at 50 messages each.

One capacity limit worth designing around: a camt.052 holds at most 15,000 entries, so a 35,000-message Account Activity Details Report arrives as three messages.

What FedNow Transaction Limits Are in 2026

Most published guides are still wrong on this, because the limits moved twice in 2025.

The history runs $500,000 at launch in July 2023, to $1m announced 24 June 2025, to $10m in November 2025. If your integration docs say $500k, they are three limit changes stale.

The default matters more than the ceiling. A receiving institution that never touched its configuration sits at $100,000, and your $250,000 payout fails against a bank that is technically capable of receiving $10m.

Operating hours are 24×7×365 with no planned downtime, but the funds transfer business day rolls at approximately 7:01 p.m. ET. Liquidity management transfers only run 7 p.m. to 7 a.m. ET on weekdays and 24 hours at weekends and Federal Reserve holidays; a pacs.009 outside that window is rejected. Profile administration, correspondent changes and account opening are Monday to Friday, standard Fed hours. The payments never sleep. The admin very much does.

What Happens When a FedNow Payment Times Out

The clock is 20 seconds, and it starts from the CreDtTm in the Business Application Header, not from when FedNow receives your message. Clock management is your problem.

There is a second timer almost nobody writes about. Each participant configures a Reserved Receiver FI Response Time between 1 and 5 seconds, and before delivering a message FedNow checks that the remaining clock is at least that window. Set it high and you guarantee yourself thinking time, but FedNow declines to deliver messages arriving with less runway and you never see them. Set it low and you get more traffic with less time to answer it. A genuine tuning decision with no default right answer.

The failure paths diverge in a way that affects reconciliation:

• Clock expires before delivery to the Receiver FI: FedNow rejects and sends pacs.002 to the Sender FI only.
• Clock expires after delivery but before settlement: the rejection goes to the Receiver FI as well.

Do not poll early. Wait 25 seconds from the start of the clock before sending a pacs.028. A status request inside the window tells you nothing.

Settlement is final at the earlier of settlement time or the moment advice reaches the Receiver FI. Under Regulation J and Operating Circular 8 the receiving institution must make funds available no more than a few seconds after that advice, around the clock. Memo-posting counts.

Why FedNow Fraud Checks Fail Open

This is the operational fact I would put on the wall, and it is hiding in section 10.2 of a public PDF.

FedNow's fraud tooling is time-bounded. If a check exceeds its budget, the Operating Procedures state the message is not checked against that tool and continues processing with the potential to settle. You get warning code F004, F010 or F011 in the end-of-day Account Activity Details Report. If the tooling is down rather than slow, those messages are not flagged at all; the Support Center tells you after cycle-day rollover.

The proprietary code family is more informative than the generic ISO set:

• F002 rejected by the sender's own negative list
• F101 rejected by a fraud control setting, which is also what a sender sees when the receiver's negative list caused the block, deliberately without saying so
• F008 cumulative value threshold breached
• F009 velocity threshold breached
• F004 the check timed out and the message went through unchecked

Note also what FedNow lacks. There is no confirmation-of-payee equivalent, so a name mismatch is the receiving institution's problem, discovered after the clock and after settlement. Engineers coming from Confirmation of Payee, or from the newer Verification of Payee rules, should not assume a name check exists.

FedNow vs RTP: Which Instant Rail to Build On First

Both rails cost the same 4.5 cents. The differences are reach and message set.

RTP carries roughly 28 times FedNow's transaction volume and reaches the large banks. FedNow's edge is the credit union and community bank long tail, a settlement account directly at the Fed rather than a TCH joint account, and liquidity management transfers, which RTP has no equivalent for.

Message-level traps when you support both: RTP publishes against noticeably older spec versions, pacs.008 v2.3 from May 2019 and the pain/camt family from April 2018. RTP has camt.035 payment acknowledgement and remt.001 stand-alone remittance advice, which FedNow lacks. FedNow has pacs.009, pacs.028, camt.055 and the whole admi. family, which RTP lacks. And camt.028 means Additional Payment Information on FedNow but Response to Request for Information* on RTP. Same message identifier, different semantics, one shared parser. That one has cost people a release.

My recommendation, and it is a recommendation rather than a sourced fact: build RTP-first with FedNow fallback for consumer payouts, because reachability at the large banks dominates, then route on a directory lookup rather than a static table. That is precisely what FedNow's Participant List API and providers' directory endpoints exist for. Anyone treating this as an either-or is optimising the wrong variable.

FedNow vs Same-Day ACH: Cost, Speed and Reversibility

Same-Day ACH caps at $1,000,000 today and rises to $10m on 17 September 2027, approved by Nacha membership on 27 April 2026. It clears in three windows, at 10:30 a.m., 2:45 p.m. and 4:45 p.m. ET, at a fraction of a cent per item.

The real distinction is not speed, it is reversibility. ACH has return codes and a genuine unwind path. FedNow credit transfers are final and irrevocable, with no chargebacks. Recovery is a camt.056 request, a camt.029 response, and if the receiver agrees, a brand new pacs.004 sending the money back. The Reserve Banks cannot cancel a settled message and make no determination on the merits. If your product needs to claw money back, instant rails are the wrong tool and no amount of engineering fixes that.

How FedNow Request for Payment Works

Two field behaviours to encode carefully. Expiry can be a date, or a date and time in ET; a bare date defaults to 23:59:59 ET. Requested execution date is the due date for the resulting credit transfer. Both are calendar dates, not cycle days, and expiry may legitimately fall after the requested execution date to allow late payment.

Reachability lags credit transfers because receiving an RfP requires both the "Send and Receive with Receive Request for Payment" configuration and the ability to present the request to an end customer. Only 22 of the 53 certified service providers carry the Receive RFP flag. Market practice is to send a zero-dollar RfP first to test whether a counterparty can act on one.

Abuse is controlled by the RfP Warranty under Operating Circular 8. The remedy for a breach is a camt.056 carrying reason code WNTB within 95 calendar days of settlement, answered within 20 business days. Note the carve-out: a WNTB return request is explicitly not a cancellation request for the purposes of UCC Article 4A.

The economics are worth contrasting. FedNow's RfP costs the sender a flat cent. RTP's costs a cent plus a 10 cent incentive fee paid to the institution that sends the resulting credit transfer, so 11 cents all-in, more than double the credit transfer it triggers. The Clearing House is paying banks to build receive capability. The Fed is not, and RfP adoption reflects that.

Can a UK Firm Connect to FedNow?

Not directly, and the honest answer has an asterisk that is only a few months old.

Eligibility requires the ability to hold a Federal Reserve master account. The eligible list includes US branches and agencies of foreign banks, so a UK bank with a US branch has a theoretical route, subject to each Reserve Bank's discretion. Everyone else reaches US instant rails through a US sponsor bank or a certified service provider, takes a REST abstraction over both RTP and FedNow, and accepts that the domestic leg is instant while FX and the cross-border leg are not.

The asterisk: on 8 April 2026 the Federal Reserve Board proposed amending Regulation J to let FedNow participants use intermediaries other than Reserve Banks, explicitly to enable use of FedNow for the domestic segment of cross-border payments via correspondents. The comment period closed 9 June 2026 and the Board is still evaluating feedback. Proposed, not final, and nobody should be building against it yet.

For UK engineers the sharpest contrast is not technical. Faster Payments caps at £1 million per single payment, has Confirmation of Payee, and has carried mandatory APP fraud reimbursement since October 2024. FedNow's ceiling is an order of magnitude higher, it has no name check, and it pairs irrevocability with no reimbursement regime. Design your dispute process accordingly, because the scheme will not do it for you.

What This Means for Payment Engineers

Concrete steps if you are scoping this work:

1. Decide direct or provider on the fixed cost, not the per-item fee. 4.5 cents is noise. A FedLine Direct Plus line at $5,750 a month plus MQ, certificates and 24×7 cover is not. 2. Get Appendix F of the Operating Procedures before you design. The mandatory, optional and prohibited matrix by participation type determines what you can even build. 3. Model the 20-second clock from CreDtTm, set Reserved Receiver FI Response Time deliberately, wait 25 seconds before any pacs.028, and generate a fresh message ID on every resend. 4. Handle the asymmetric timeout. Sender-only rejections exist. Your ledger must reconcile a state the counterparty never observed. 5. Do not treat the negative list as a control. It is fail-open, sometimes silently. Put your own screening in the path before you emit the pacs.008. 6. Check the receiver's configured limit, not the network maximum. The $100,000 default catches large payouts constantly. 7. Assume no name check, and if you support RTP too, split camt.028 handling by network.

Key Takeaways

The FedNow API is real, useful and cannot send a payment. Money moves over ISO 20022 on MQ, through a FedLine connection with a months-long lead time and a five-figure annual cost. The interesting engineering is not the happy path, which is a pacs.008 and a pacs.002 inside 20 seconds. It is the timeout asymmetry, the fail-open fraud checks, the $100,000 default nobody changed, and the fact that finality makes your recovery path a polite request the counterparty may decline. Both US instant rails now cap at $10m and cost 4.5 cents, so reach and message-set differences decide the build, not price.

Written by Tom Wang, a payments engineer working on cross-border and stablecoin infrastructure.