Why FedNow was a core-processor decision for community banks and credit unions
The Federal Reserve’s instant payment service went live in July 2023. For community banks and credit unions, joining turned on what their core processor could do in real time, all year round, and on fraud controls for payments that cannot be recalled.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On July 20, 2023, the Federal Reserve launched the FedNow Service, an instant payment rail that settles individual payments in central bank money around the clock, every day of the year. It went live with a first group of early-adopter banks and credit unions, the Treasury’s Bureau of the Fiscal Service and a set of service providers, many of them core processors. FedNow joined the RTP network, which The Clearing House has operated since 2017, as a second instant payment option in the United States. The Fed set a default per-transaction limit that participants could adjust within a cap, and offered both send-and-receive and receive-only participation. Most eligible institutions were not on day one, and the Fed said adoption would build over years.
For a large bank, FedNow was one more rail beside RTP, ACH, wires and cards. For a community bank or credit union, the decision looked different. These institutions rarely run their own core systems. They rent them from a small number of processors, and their ability to offer anything in real time depends on what that processor supports and when. We break the decision into four parts that follow the life of a payment: posting it to the account, running the service without pause, stopping fraud before money leaves, and choosing the order in which to take on each capability.
Posting in real time
An instant payment is only instant if the receiving account shows the money immediately and the sending account reflects the debit at once. Many community bank cores were built around batch processing. They post transactions overnight and calculate available balances from a mix of posted entries and memo holds.
Joining FedNow forces a choice of architecture. Some cores can post incoming credits in real time natively. Others rely on a middleware layer that receives the payment, updates a shadow balance and posts to the core later. Middleware is faster to deploy but creates two versions of the balance. If the shadow ledger and the core disagree, customers see the wrong number and overdraft decisions go wrong.
The questions for the processor are specific. Does the core post FedNow credits in real time, or through a memo post later settled in batch? What happens to an incoming payment during the core’s end-of-day processing window? How are returns and exceptions reconciled? The answers determine whether instant payments create operational debt or retire it.
Data access is the related question. Fraud screening, liquidity dashboards and customer notifications all need transaction events as they happen. If the core exposes them only in end-of-day files, every real-time control has to be built on the middleware instead, and the institution depends on that layer for more than payments. Asking for event streams or real-time APIs at this stage costs little. Retrofitting them later is expensive.
Running without pause
FedNow does not close. A receiving institution must be able to accept and post payments at 3 a.m. on a Sunday and on public holidays. That changes the operating model of an institution used to business hours.
Liquidity is the first issue. Payments settle in the institution’s Federal Reserve master account, or through a correspondent. Treasury staff need to monitor balances and move funds outside normal hours, or set automated rules that do it. Operations is the second. Exception handling, customer inquiries and incident response need coverage at all hours, either through staff rotas or through a service provider. Technology is the third. Maintenance windows, patching and disaster recovery tests can no longer assume a quiet period when payments stop.
Each of these can be bought rather than built, usually from the core processor or a payments provider. That is often the right choice for a small institution. It also deepens dependence on that provider, which matters at contract renewal.
Stopping fraud before money leaves
FedNow payments are final and irrevocable. The service supports messages requesting the return of a payment, but the receiving institution is not obliged to return funds. Once money leaves, recovery depends on cooperation and speed.
That shifts fraud control to the moment before sending. Institutions offering send capability need real-time screening that can score a payment in the seconds available. They need limits set by customer type and history, not only the default network limit. They need extra friction for first payments to new recipients and for amounts out of pattern, such as a confirmation step or a short delay. Authorized push payment scams, where a customer is tricked into sending money, are the hardest case. Screening must weigh the customer’s own instruction against signs of coercion.
Receiving institutions have duties too. Accounts opened to receive stolen funds, often called money mule accounts, show patterns: new accounts, rapid inbound and outbound flows, and logins from unexpected devices. Monitoring for these protects the institution from becoming a destination for fraud on other rails.
Choosing the sequence
The Fed’s receive-only option gives institutions a way to stage the decision. Receiving payments requires real-time posting and round-the-clock availability. It carries less fraud exposure, because the institution is not sending money on a customer’s instruction. Sending can follow once fraud controls and limits are ready.
The right sequence depends on demand. Institutions with business customers that want instant payroll or supplier payments may have a case for sending early. Institutions whose customers mainly want faster incoming funds, such as account-to-account transfers or insurance payouts, can start with receive-only and learn. Either way, the decision belongs to a cross-functional group of operations, treasury, fraud, technology and finance, with a business case that includes the processor’s fees.
Above all, the timing of the decision is partly in the processor’s hands. An institution whose core cannot post in real time will wait regardless of its own readiness. Core contract renewals in the years after 2023 were the moment to require real-time posting, round-the-clock availability and access to transaction data as stated capabilities with service levels, rather than roadmap promises.
With hindsight
FedNow adoption grew steadily rather than dramatically. Participation expanded each year, and many institutions joined as receive-only first, much as the staging logic suggested. Transaction volumes stayed small next to ACH and cards, and use cases built more slowly than early commentary expected. Core processors remained the gating factor for most community institutions, both in technical readiness and in pricing. Fraud concerns proved justified across faster payment channels generally. Authorized push payment scams stayed a prominent topic for regulators and consumer advocates, and the Fed added fraud-prevention features to the service over time. The more durable effect was on the cores. Instant payments put real-time posting and continuous operations on the list of questions any institution can ask at a core contract renewal.