Joining FedNow as a Community Bank or Credit Union: What the Project Actually Involves

By AZdev

FedNow is straightforward to join and harder to operate than most institutions expect. What connecting actually requires: sponsor vs. direct, receive-only first, liquidity, fraud controls, and the 24/7/365 staffing question nobody budgets for.

Joining FedNow as a Community Bank or Credit Union: What the Project Actually Involves

Updated July 2026.

Most coverage of FedNow is written for people deciding whether instant payments matter. That question is settled. The Federal Reserve is working toward connecting the large majority of the roughly 9,000 US banks and credit unions, and the institutions joining now are not early adopters. They are catching up.

The useful question for a community bank or credit union is narrower and much less discussed: what does connecting actually involve, and which parts will cost more than the budget says?

The decision that shapes everything else: direct or through a provider

Almost no institution under a few billion in assets connects to FedNow directly. The realistic path runs through whoever already provides your core and digital banking: Fiserv, Jack Henry, Corelation, or a payments hub sitting alongside them.

This matters more than it sounds, because it means your FedNow timeline is mostly your vendor's timeline. The Fed's onboarding requirements are well documented and stable. Your provider's queue, their certification cycle, and what they charge for the connection are the actual constraints.

Two questions to ask your provider before anything else:

  1. What is the all-in cost, including the pieces that are not the connection fee? Implementation, per-transaction pricing, and any charge for the fraud tooling that comes bundled or does not.
  2. What is realistic queue position, in months? Not "we support FedNow". A date.

Institutions that skip these two questions tend to discover both answers about four months into a project they thought would take six.

Receive-only first is the right default

FedNow participation splits into receiving payments and sending them. You can do the first without the second, and for most institutions joining now, that is the correct sequence.

Receive-only is genuinely lower risk. Money arriving is not a fraud exposure in the way money leaving is. There is no send-side liquidity question. Your members or customers get the benefit that they actually notice: funds showing up instantly from payroll, from a marketplace, or from another institution, without you standing up real-time fraud decisioning first.

Send capability is where the engineering and the risk live. Treating it as a second phase, deliberately, is not timidity. It is the difference between a six-month project and an eighteen-month one.

The liquidity question

FedNow settles through your Federal Reserve master account, in real time, around the clock. That last part is the operational change.

Under batch rails, your balance moves at predictable times and someone reconciles in the morning. Under FedNow, funds leave the account on a Saturday night at the same speed they leave on a Tuesday afternoon. You need a position that can absorb outflows when nobody is watching, and you need alerting that reaches a human when it cannot.

The Fed offers liquidity management transfers to move funds between master accounts outside standard hours, which helps. It does not remove the requirement to decide, in advance, what balance you hold overnight and over a long weekend, and who has authority to act when it runs low at 3am.

Fraud is the part that gets underestimated

Instant, irrevocable, credit-push payments produce a specific fraud profile. Once a payment is authorized and sent, the money is gone. There is no chargeback. Recovery means calling the receiving institution and asking nicely, backed by a camt.056 return request the receiving institution can decline.

The dominant vector is authorized push payment fraud, where the account holder is deceived into sending the money themselves. Every control that assumes the transaction is unauthorized fails here, because the transaction is authorized. The customer really did mean to press send; they were lied to about who was receiving it.

The UK ran this experiment ahead of the US, including mandatory reimbursement since October 2024. UK Finance reported 拢576.4M in APP fraud losses in 2025 across 248,070 cases, up 19% in value and 7% in volume, while unauthorized fraud fell 5%. Making banks liable did not suppress the losses in the first full year. As account-takeover controls hardened, the attack moved to persuading the customer to send the money.

For an institution joining FedNow now, the practical implications:

  • Send-side controls need to decide in under a second. Any control requiring a batch lookup, an overnight model run, or a human review does not fit the window.
  • Confirmation-of-payee style checks matter more than transaction scoring. The fraud is in who the beneficiary is, not in whether the pattern looks unusual.
  • Your first-time-beneficiary flow is the highest-leverage control you have. Most APP losses go to an account the customer has never paid before.
  • Member and customer education is a real control, not a compliance checkbox. It is also the cheapest one available to you.

The staffing change nobody budgets for

FedNow is 24/7/365. Your operations are probably not.

This is the single most common gap between the project plan and the first quarter of live operation. Instant payments do not stop for weekends, holidays, or your core's maintenance window. When something breaks at 2am on a Sunday, whether a stuck payment, a liquidity threshold, or a failed settlement message, someone has to be reachable and empowered.

For a 20-to-40-person IT organization, this usually means one of three things: a genuine on-call rotation with the compensation structure that implies, a managed service arrangement with your provider, or an explicit, documented decision to accept degraded response outside business hours. All three are defensible. Discovering at go-live that you chose the third by accident is not.

Budget for the operational change as well as the integration. The integration is finite work. The staffing model is permanent.

A realistic sequence

For a community bank or credit union starting now:

  1. Provider conversation first. Cost, queue position, what fraud tooling is included, whether receive-only is supported as a distinct phase.
  2. Receive-only go-live. Delivers visible member benefit, builds operational familiarity, carries limited risk.
  3. Operational readiness before send. On-call model, liquidity policy, alerting that reaches a person, runbooks for stuck and returned payments.
  4. Send capability with fraud controls built for the window. Sub-second decisioning, beneficiary-focused checks, hard limits that are low at launch and raised deliberately.
  5. Revisit limits. The network ceiling is $10M as of November 2025. Whatever you configure at launch should be far below that, and moved on evidence rather than on request.

Institutions that follow roughly this order tend to go live without incident. Institutions that compress it into a single phase tend to go live and then spend a year fixing what compression cost them.


If you are weighing FedNow against RTP rather than planning a FedNow connection, the rail-by-rail comparison covers that decision directly. For what an engagement on this looks like, see FedNow & RTP integration and technology leadership for credit unions, or book a call.

Book a call