FedNow opens an instant payment rail, but distribution still belongs to banks

FedNow gave US banks another way to move money around the clock. Payment startups needed reachable accounts, bank relationships and continuous operations to turn that access into a useful service.

Payments3 min read

Federal Reserve headquarters, Washington, D.C.AgnosticPreachersKid · CC BY-SA 3.0

A payment sent on a Sunday should be useful on a Sunday. That was the practical promise behind the Federal Reserve's launch of FedNow on 20 July 2023: participating banks and credit unions could transfer money for customers at any time of day, on any day of the year. The launch group included 35 banks and credit unions, the US Treasury's Bureau of the Fiscal Service and 16 service providers supporting payment processing.

Payment startups still had to work through participating institutions. FedNow operated alongside Fedwire and FedACH as an interbank service, with access dependent on the banks and financial apps that supported it. A customer needed more than a connection to the settlement infrastructure: a clear price, reliable confirmation and somebody accountable when a transfer failed.

The product begins with a participating institution

The launch announcement described customers eventually accessing FedNow through their institution's mobile app, website and other interfaces as adoption grew. That established a distribution boundary. A software company could build an appealing payout experience, but it still needed the participating institution to expose the required capability. Account availability, onboarding, transaction permissions and customer support all sat between a working connection and a dependable customer proposition.

From payment infrastructure to a customer service

Scroll to view all columns

Comparison	Infrastructure or institution	Product work still required
Settlement	FedNow provides an interbank payment service	Connect the transfer to a customer's specific task
Availability	The service operates around the clock	Support, monitoring and funding must fit that schedule
Reach	Participating institutions connect to the network	Verify which intended recipients can use the offering
Access	Institutions provide customer-facing interfaces	Agree permissions, pricing and responsibility for exceptions

FedNow's launch model paired with the product decisions facing a payment provider. Infrastructure capabilities are drawn from the Federal Reserve's announcements.

The bank relationship determined what the product could offer. A startup founder needed to establish which intended recipients were reachable, what the institution would allow the application to initiate, and how exceptions would be handled. The number of connected institutions described network development, but did not establish the share of a startup's customers who could receive money. That required testing their intended transactions and accounts.

Immediate access changes the value of a receipt

The Federal Reserve's launch preparation notice said recipients would have full access to funds immediately. For a small business waiting for a customer payment, that could change when a supplier could be paid or when a cash shortfall would be visible. The benefit depended on the surrounding workflow. A customer who did not approve an invoice would still not pay it; a transfer arriving quickly without a usable reference could still require manual reconciliation.

Those distinctions mattered when estimating revenue. A startup could charge for a meaningful reduction in uncertainty or administrative work, but the existence of an instant rail did not establish willingness to pay. A useful pilot would compare the time from approval to usable funds, the share of receipts matched automatically, and the cost of unresolved exceptions. Faster transmission was one measurable component of that result.

Operating around the clock

FedNow's preparation programme tested how organisations would operate as well as whether they could connect. The Federal Reserve announced formal certification beginning in April, with testing for operational readiness and network experience, followed by production validation with certified participants scheduled for June. Organisations had to demonstrate their readiness before live transactions began.

A startup building on that infrastructure had a related responsibility. It needed to decide who responded to an incident outside office hours, how duplicate instructions were detected, and how a customer learned whether a payment had completed. Funding arrangements also needed to support the proposed hours of service. The institution's actual controls and customer terms determined how those responsibilities were shared at launch.

San Francisco office towers rise behind boats moored along the waterfront at dusk. — San Francisco's Financial District from Pier 7.King of Hearts (opens in a new tab) · CC BY-SA 3.0 (opens in a new tab)

An invoice request still needs a business record

An earlier Federal Reserve design announcement described a request-for-payment capability through which one participating institution could ask another for payment of a bill, invoice or other amount owed. That planned feature could support business applications, provided they distinguished requesting money, obtaining approval and receiving it. An application needed to preserve those separate states in its status messages and accounting records.

A product for managing receivables, for example, could attach an invoice reference to a request, record the customer's decision and match the resulting receipt to the correct obligation. It would remove work across the collection process. Faster transfers alone might leave the finance team with the same spreadsheet, unanswered customer messages and uncertainty over which invoice had been settled. An investment case needed to connect those workflow improvements to recurring customer payments and the cost of operating the service.