Why FedNow was a core-processor decision for community banks and credit unions

The week

On July 20, 2023, the Federal Reserve launched the FedNow Service, an instant payment rail. For most of the history of American banking, money has kept office hours. Send a payment on Friday evening and it might arrive on Monday. Payroll lands on a set day because the systems behind it move in overnight batches. FedNow was designed to change that.

The service had been a long time coming. The Fed announced in August 2019 that it would build a round-the-clock instant payment service. It then ran a pilot program with banks, credit unions, processors and other firms, and opened formal testing and certification for prospective participants in the spring of 2023. The July launch was the end of that sequence and the start of adoption.

A payment rail is the shared network banks use to move money between each other. FedNow settles individual payments in central bank money, meaning the funds move directly between banks’ accounts at the Federal Reserve, the safest form of money in the system. And it does so around the clock, every day of the year, including nights, weekends and holidays.

It went live with 35 early-adopting banks and credit unions, the Treasury’s Bureau of the Fiscal Service, and 16 service providers ready to process payments for others, many of them core processors. A core processor is the company that runs a bank’s core banking system: the central ledger that holds customer accounts and balances, and records every deposit and withdrawal. Most smaller banks and credit unions rent this system rather than building their own.

FedNow was not the country’s first instant payment option. It joined the RTP network, which The Clearing House, a bank-owned payments company, has operated since 2017. With FedNow, the United States had two.

How the service was designed

Several design choices shaped what joining would involve. FedNow carries credit transfers, payments pushed by the sender, rather than debits pulled by a biller. A biller can send a request for payment, but the payer’s institution still sends the money. Messages use ISO 20022, an international standard that carries richer data than older domestic formats, such as structured remittance details for business payments.

Participants settle through their master accounts at the Reserve Banks, or through the account of a correspondent bank if they choose. The Fed also built in liquidity management transfers, which let participants and their usual liquidity providers move funds between accounts at any hour. Once a payment settles, the receiving institution must make the funds available to its customer immediately.

The Fed published fees at launch, including a charge of 4.5 cents per credit transfer, and said it expected to recover its costs over the long run. For most small institutions, the larger bill would come from their processor rather than from the Fed.

The Fed set a default per-transaction limit of $100,000, which participants could raise to as much as $500,000, a basic safeguard against large losses on payments that cannot be reversed. It also offered two ways to join: full send-and-receive participation, or receive-only, in which an institution accepts incoming instant payments but does not yet send them. Alongside the limits, it offered tools such as the ability to reject payments to or from specific accounts.

The timing also mattered. Four months earlier, the failure of Silicon Valley Bank had shown how fast depositors could move money through digital channels. In June, the federal banking agencies had issued joint guidance on managing third-party relationships. Both bore on any board weighing a service that never closes and depends on outside vendors.

Most eligible institutions were not on day one. The Fed said it would work with the more than 9,000 banks and credit unions across the country to widen availability over the coming years. Boards of community banks and credit unions now had to weigh whether and when to join. For them, the deciding factors were less about the Fed than about something closer to home: the capabilities of the company that runs their core.

For a large bank, FedNow was one more rail beside RTP, ACH, wires and cards. ACH is the long-established network that moves direct deposits and bill payments in batches; wires move large sums the same day during business hours. A big bank already runs teams and technology for all of them, and adding another is a familiar project.

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.

The analysis below has eight parts. It starts with what instant payment actually requires and what a board stands to gain or lose. Three capabilities follow, in the order a payment needs them: posting it to the account, running the service without pause and stopping fraud before money leaves. Then come choosing the order in which to take them on, the operating model that ties them together, and the processor questions to settle first.

Throughout, one theme recurs. For a small institution, almost every one of these capabilities is bought, so almost every decision is partly a vendor decision.

What “instant” actually asks of a bank

An instant payment is easy to mistake for a normal payment that travels faster. In fact it changes several assumptions at once.

Traditional payments in the United States are mostly processed in batches. Throughout the day, instructions pile up. At set times, often overnight, they are processed together: accounts are debited and credited, balances are updated, statements are produced. Batch processing is efficient and well understood, and it has shaped how banks run their systems, their staffing and their risk controls for decades.

Instant payment removes the overnight sort. Each payment has to be checked, approved, settled and posted to the customer’s account within seconds, one at a time, at any hour. The receiving customer expects to see the money, and spend it, immediately. The sender expects it gone. There is no evening window to catch mistakes, no morning reconciliation before customers wake up.

That has three practical consequences for an institution. Its account systems must update in real time. Its operations must run without a closing time. And its fraud defenses must work before the money moves, because afterward it is too late. Each of these depends heavily on the core processor, and each is the subject of a section below.

How a FedNow payment moves

The steps are simple to list and demanding to meet. The sender’s institution checks the customer’s balance, screens the payment and sends a credit transfer message to FedNow. FedNow checks that the sending institution has enough funds in its settlement account. It then passes the message to the receiving institution.

The receiver has a few seconds to accept or reject. It must confirm that the account exists, is open and can take the payment. If it accepts, FedNow debits the sender’s settlement account, credits the receiver’s and notifies both. The receiver must then make the money available to its customer at once.

Every step happens while the customer waits. If any system in the chain is slow or offline, the payment fails, and the customer sees the failure immediately. An institution’s technical weaknesses, once hidden by overnight processing, become visible in real time.

Push payments change the fraud picture

Because FedNow carries only credit transfers, no one can pull money out of a customer’s account through it. That removes one familiar kind of fraud, such as unauthorized debits. It concentrates risk elsewhere. A criminal must either take over the customer’s account and send the money, or persuade the customer to send it.

The data standard has its own consequence. ISO 20022 messages can carry invoice numbers and remittance details that business customers value. If the core or the online banking platform cannot store and display that data, it is lost on arrival, and one of the service’s main advantages for business payments disappears.

What a board stands to gain or lose

Without instant payments, a community institution risks losing customers to banks that offer them; with them, it takes on faster fraud and new costs.

Customers. People increasingly expect money to move the way messages do. A small business owner who can be paid instantly by one bank and has to wait two days at another will notice. So will a family waiting on an insurance payout after a storm. For a community institution whose main advantage is the relationship, being unable to offer what customers see elsewhere is a slow drain on loyalty.

Competition. The RTP network had been running since 2017. FedNow added a second route to instant payments, this one a service run by the Federal Reserve itself, open to banks and credit unions of every size. Whether a given institution could use it, and when, was the question that mattered.

Risk. Faster money means faster fraud. A loss on an irrevocable payment is a direct hit to the institution or its customer, and a customer who loses savings to a scam will often blame the bank, fairly or not.

Cost. Processor fees, round-the-clock staffing or services, and new fraud tools all cost money. For a small institution, these are material budget lines that have to be weighed against revenue and retention that are harder to forecast.

Regulators. Examiners expect an institution to understand and control the risks of any new product, including the risks that sit with its vendors. “Our processor handles that” is a starting point for an examination, not an answer.

Banks and credit unions face different oversight

The regulatory frame differs by charter. Community banks are supervised by the FDIC, the Office of the Comptroller of the Currency or the Federal Reserve. Those three agencies issued their joint guidance on third-party risk management in June 2023, a month before FedNow’s launch. It expects a bank to manage risks across a relationship’s whole life cycle: planning, due diligence, contracting, monitoring and termination.

Banking regulators can also examine major technology service providers directly under the Bank Service Company Act. Banks can typically ask their regulator for the resulting examination reports on their processors.

Federally insured credit unions are supervised by the National Credit Union Administration, which was not a party to that guidance. The NCUA has long told Congress that it lacks comparable authority to examine third-party vendors. A credit union therefore leans more heavily on its own due diligence, its contract and the vendor’s audit reports when it assesses a processor’s instant payment capability.

Customer bases shape the case

The business case also differs by institution. A community bank with many small business customers may see instant payments as a commercial product: faster receivables, instant payroll and supplier payments, perhaps priced as a premium service. A credit union serving consumers may see it mainly as a member convenience, valued for faster incoming funds and an emergency transfer option.

These cases call for different sequencing. A commercial case points toward sending, with its fraud demands. A consumer convenience case points toward receiving first.

The case for waiting

The strongest argument against early adoption was demand. Many consumers already moved money between people instantly through Zelle, which banks had run since 2017, or through card-based push payments. Few customers asked their credit union for FedNow by name. An institution that waited could learn from early adopters’ mistakes and pay lower prices once processors had amortized their development.

That argument holds for FedNow itself. It does not hold for the underlying capabilities. Real-time posting, continuous operations and pre-transaction fraud screening are needed for RTP, for instant card payouts and for whatever real-time service comes next. An institution can defer FedNow and still use the same years to press its processor on those capabilities.

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, temporary notes on an account saying “this is coming” or “this is pending” until the official posting run catches up.

Joining FedNow forces a choice of architecture. Some cores can post incoming credits in real time natively. Others rely on a middleware layer, a separate piece of software that sits between the payment network and the core. The middleware receives the payment, updates a shadow balance (its own running copy of the account balance) and posts to the core later.

Middleware is faster to deploy but creates two versions of the balance. Most of the time the numbers agree. When they do not, a payment bounces that should have cleared, or one clears that should have bounced. If the shadow ledger and the core disagree, customers see the wrong number and overdraft decisions go wrong. That leads to complaints, fee refunds and, at scale, regulatory attention.

The questions for the processor are specific:

• whether the core posts 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, when many batch systems are briefly busy or unavailable; and
• how returns and exceptions are reconciled between the payment system and the core.

The answers determine whether instant payments create operational debt or retire it. Operational debt here means workarounds and manual fixes that pile up and have to be paid down later in staff time and errors.

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.

The technical terms to listen for are event streams, a continuous feed of transactions as they occur, and real-time APIs. An API, or application programming interface, is a defined way for one piece of software to ask another for information or to request an action. Asking for event streams or real-time APIs at this stage costs little. Retrofitting them later is expensive.

Where the balances must agree

The shadow balance problem reaches further than the core. When a customer swipes a debit card, the card processor checks an available balance, sometimes from the core and sometimes from its own copy. If an instant payment updates the middleware’s balance but not the card system’s, a customer who has just received money can have a card declined minutes later.

The same applies to online banking displays, mobile alerts, overdraft decisions and fraud screening. Each system that reads a balance must read the same one. Mapping every consumer of balance data, and confirming which source each one uses, is unglamorous work that prevents the most visible failures.

What testing should show

A processor’s demonstration usually shows a payment arriving on a weekday afternoon with nothing else running. The tests that matter are less comfortable. An institution should ask to see payments received during end-of-day processing, at month-end and over a holiday weekend. It should also see what happens during a core outage, and how payments are handled when the core comes back.

After launch, a short set of measures tells management whether posting is healthy:

• the number of differences between the payment system and the core found in daily reconciliation, and how fast each is resolved;
• the share of incoming payments rejected, and the reasons;
• the time from settlement notice to funds showing in the customer’s account; and
• customer complaints that mention missing or duplicated payments.

When the answer is a new core

Some processors offered real-time posting only on their newer platforms. For an institution on an older one, FedNow could turn into a core conversion: a migration of every account and product to a new system. Conversions often take more than a year, consume scarce staff and carry their own risks. In that situation the instant payment decision and the core strategy become the same decision, and the board should treat them as one.

The small number of institutions that run their own cores in-house face a different trade-off. They control their roadmap but carry the whole engineering burden of real-time posting themselves.

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. Liquidity, in this context, means having enough money in the right account to settle payments as they go out. Payments settle in the institution’s Federal Reserve master account, the account a bank holds at the Fed, or through a correspondent, a larger bank that settles on its behalf. Treasury staff need to monitor balances and move funds outside normal hours, or set automated rules that do it. A holiday weekend with heavy outbound payments and no one watching the balance is not a theoretical concern.

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. A customer who sends money at midnight and sees it fail will want an answer before Monday.

Technology is the third. Maintenance windows, patching and disaster recovery tests can no longer assume a lull when payments stop. Systems that have always been taken offline for upgrades on Sunday morning need a different approach.

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, which cannot easily staff a round-the-clock operations center. It also deepens dependence on that provider, which matters at contract renewal. An institution that outsources its liquidity monitoring, its overnight operations and its real-time posting to the same company has very little bargaining power left in a negotiation, and knows it.

Suppose a credit union with a few dozen branches decides to receive FedNow payments. It discovers that its treasury team works weekdays, its call center closes at 6 p.m., and its core provider takes the system offline for a short period most Sunday nights. Each was harmless before, and each now needs a decision: extend hours, buy a service, or accept a risk and document it. The technical connection to FedNow turns out to be the easy part.

The weekend liquidity gap

Weekends create a specific mechanical problem. Fedwire Funds, the Fed’s service for large-value transfers and the usual way banks top up their master accounts, runs on business days only. FedNow keeps settling on Saturdays, Sundays and holidays. An institution whose customers send more than they receive over a long weekend draws down its settlement balance with no Fedwire to refill it.

There are two main answers. One is to pre-position funds on Friday, sized for a plausible worst case. Too little risks rejected payments, and too much sits idle. The other is to arrange liquidity management transfers from a correspondent or liquidity provider, which FedNow supports around the clock. Either way, someone must model expected flows, set thresholds and decide who acts when a threshold is breached.

Settling through someone else

Many small institutions settle through a correspondent rather than their own master account. For credit unions, that correspondent is often a corporate credit union, a cooperative that provides payment and liquidity services to member credit unions.

This arrangement shifts some burdens and creates others. The correspondent manages the master account. It also sets the limits and terms under which the respondent’s payments settle. The respondent’s instant payment capacity is only as large as that agreement allows, so the agreement belongs in the same review as the core contract.

When the institution is unavailable

If a receiving institution cannot respond in time, the payment fails and the sender sees the failure. Downtime that was invisible at 3 a.m. under batch processing now shows up in other people’s banking apps. Availability becomes a customer-facing measure.

Examiners and auditors will expect the evidence to match. That means business continuity plans updated for continuous service, recovery tests that do not assume a weekend lull and contracts with availability commitments. It also means incident escalation paths that reach a decision-maker at any hour. For a small institution, an on-call rota with clear authority is often enough. The rota needs a written list of what the on-call person may do alone and what requires a call to an executive.

Stopping fraud before money leaves

FedNow payments are final and irrevocable. Once sent, they cannot be pulled back by the sender’s bank. 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. A check can be stopped before it clears; cash handed over cannot. Instant payments are much closer to cash.

Institutions offering send capability need several things:

• Real-time screening that can score a payment for fraud risk in the seconds available, using signals such as the customer’s usual behavior, the device being used and the recipient.
• Limits set by customer type and history, rather than the default network limit alone. A long-standing business customer and a two-week-old personal account should not have the same ceiling.
• Extra friction for risky payments, such as first payments to new recipients and amounts out of pattern. That might be a confirmation step, a warning message or a short delay.

Authorized push payment scams, where a customer is tricked into sending money themselves, are the hardest case. The customer logs in correctly, passes every security check and genuinely instructs the payment, because a fraudster posing as their bank, a utility or a romantic partner has persuaded them to. Screening must weigh the customer’s own instruction against signs of coercion, such as an unusual amount, a brand-new recipient or a payment made during a long phone call. Too little friction and customers lose savings. Too much and legitimate customers grow frustrated and leave.

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 every rail, FedNow included. No bank wants to be known as the place where stolen money lands.

Three kinds of fraud, three liability regimes

Fraud on instant payments arrives in three main forms, and who bears the loss differs for each. Organizations should check the details with counsel.

• Account takeover. A criminal steals a consumer’s login and sends money. For consumer accounts, Regulation E generally treats this as an unauthorized transfer. The institution then bears most of the loss, within limits that depend on how quickly the customer reports it. The CFPB has said that a transfer remains unauthorized even when the consumer was tricked into handing over credentials.
• Authorized push payment scams. The customer sends the money personally, under deception. Regulation E’s unauthorized-transfer protections generally do not reach these payments, so the loss usually stays with the customer. That legal outcome does nothing to protect the institution’s reputation.
• Business account fraud. Commercial accounts fall outside Regulation E. Losses turn on funds-transfer law, the account agreement and whether the institution followed the security procedures agreed with the customer.

The split matters for control design. Strong authentication addresses account takeover. It does nothing against a scam in which the real customer, correctly authenticated, sends the money. Scam controls work on behavior and context instead.

Using the network’s tools and your own

FedNow provides some controls at the network level: transaction limits for the network and for each participant, the ability to reject payments to or from specific accounts, and configurable account activity thresholds. These are useful backstops. They cannot see what the institution sees about its own customers, such as a new device, a password reset yesterday or a pattern of small test payments.

Most small institutions will buy their real-time fraud screening from their core processor, their digital banking provider or a specialist vendor. The questions to put to that vendor are practical. Ask which signals the model uses and how quickly it returns a score. Ask what happens when it times out, whether the institution can tune it, and what reports show its performance.

Measuring friction

Calibration needs numbers on both sides. Fraud losses and the share of payments that turn out to be fraudulent show the cost of too little friction. Abandoned payments, false alerts and complaints about delays show the cost of too much. An institution that tracks only losses will keep adding friction until customers go elsewhere.

Other countries offer comparisons. The United Kingdom introduced a confirmation-of-payee check in 2020, which tells a sender whether the recipient’s name matches the account. American instant payment rails had nothing equivalent across the market when FedNow launched. That gap put more weight on each institution’s own warnings and checks.

Sharing what the receiving side sees

Mule detection improves when institutions compare notes. Section 314(b) of the USA PATRIOT Act lets financial institutions that register with FinCEN share information about possible money laundering or terrorist financing with each other under a safe harbor. A receiving institution that spots a mule account can contact the sending institution quickly. That sometimes allows funds to be frozen before they move again.

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. A landscaping company that wants to pay its crews the moment a job is done is a different customer from a retiree who mainly receives a pension. 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: operations, treasury, fraud, technology and finance. It needs a business case that includes the processor’s fees, the cost of extended staffing or bought-in services, and the expected fraud losses and controls. A decision made by technology alone tends to underestimate the operational change. A decision made by marketing alone tends to underestimate the fraud.

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. A service level is a measurable commitment in a contract, such as how quickly something must happen and what remedy applies if it does not. A roadmap promise is a slide that says “coming soon.”

What receive-only still demands

Receive-only lowers the fraud stakes but does not make joining trivial. The institution still needs real-time posting, availability at all hours and immediate funds availability. It also needs monitoring for mule accounts, because stolen funds sent elsewhere may land with its customers.

Liquidity is easier, since incoming payments add to the settlement balance rather than draining it. Customer service still needs coverage: a customer expecting money on a Sunday will call when it does not arrive.

Gates before sending

Moving from receiving to sending works best when the conditions are agreed in advance. A practical set of gates includes:

• a real-time fraud screening service, tested against the institution’s own transaction history;
• send limits by customer segment, approved by the risk committee;
• a weekend liquidity plan with named owners and tested thresholds;
• customer warnings and confirmation steps for first-time recipients;
• a process for handling scam claims and return requests; and
• a reporting pack for management and the board on volumes, losses, exceptions and availability.

Writing the gates down protects against two pressures. One is a competitor’s announcement that makes sending look urgent. The other is a fraud scare that makes it look impossible.

Building the business case honestly

The cost side is easier to estimate than the benefit side. It includes the Fed’s fees, the processor’s fees, any middleware or fraud screening subscription, staff time for implementation and extended coverage, and an allowance for fraud losses. Processor fees often dwarf the Fed’s.

The benefits are harder to price. They include customer retention, deposits that stay because customers can move money where they need it, and fee income from business services. Many are defensive: they show up as losses avoided rather than revenue gained. A board should accept that and judge the case on strategy as well as on a spreadsheet.

An operating model decision

A well-prepared community institution treats FedNow as an operating model decision, not a technology project. It knows exactly how its core handles real-time posting and has seen it tested. It has a plan for liquidity on a holiday weekend. It has decided who answers the phone at 2 a.m. It has fraud limits that reflect its own customers. And it has written what it needs from its core processor into the contract, with dates and service levels.

Institutions that stumble tend to do so in the same places:

• Treating it as a connection project. Plugging into the network is the smallest part of the work.
• Accepting a shadow ledger without a reconciliation plan. Two balances that disagree will eventually disagree in front of a customer.
• Forgetting the weekend. Liquidity, operations and maintenance all need answers for hours the institution has never staffed.
• Using the network’s default limit as the only limit. It is a ceiling, not a risk policy.
• Launching sending before fraud controls are ready. Payments that cannot be recalled punish haste.
• Taking roadmap promises at renewal. The contract is the main bargaining power a small institution has over its processor’s priorities.

One owner, regular reporting

Because instant payments cut across operations, treasury, fraud, technology and customer service, they need a single accountable executive. Without one, each function optimizes its own part, and the gaps fall between them. The owner should report to management and the board on a regular schedule, with the same small set of measures each time. Those cover volumes, fraud losses, rejected and failed payments, availability, and incidents outside business hours.

Second-order effects

The move to continuous operations has costs that rarely appear in the business case. Staff on call at night and on weekends need rotas, pay arrangements and limits on how often they are woken. Small teams can burn out quickly. Some institutions find that the continuous-operations change outlasts the payment project and reshapes how they handle every incident.

Vendor concentration is the other effect. An institution that buys real-time posting, fraud screening, liquidity monitoring and overnight operations from one processor has simplified its life. It has also placed most of its instant payment risk with a single counterparty. Concentration can be a reasonable choice for a small institution. It should be made deliberately, with an exit plan and contract terms that reflect the dependence.

Settling the processor questions first

• Does our core post instant payments to the account in real time, or through a shadow ledger that settles later? If the latter, how often are the two reconciled, and what happens to a payment during Sunday maintenance?
• Who monitors our settlement balance on a holiday weekend, and what happens if it runs low?
• What send limits will we set for different kinds of customers, and what extra checks apply to first payments to new recipients?
• Should we start with receive-only? What would have to be true before we send?
• When does our core contract come up for renewal, and are real-time posting, round-the-clock availability and data access written in as service levels?

The questions are deliberately concrete. Each has an owner inside the institution and a counterpart at the processor, and each answer can be written into a contract or a test plan.

For community banks and credit unions, FedNow’s launch was less a question of whether to join a network than of what kind of institution they could become. Much of that answer depended on a vendor they did not control.

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. For many smaller banks and credit unions, receiving was the natural first step: it delivered faster incoming funds to customers while postponing the harder fraud questions that come with sending.

By the Fed’s own published counts, participation passed a thousand institutions within roughly two years of launch. That was a large increase from 35 early adopters. It was still a minority of the more than 9,000 banks and credit unions the Fed had in view.

Transaction volumes stayed small next to ACH and cards, and use cases built more slowly than early commentary expected. That is a familiar pattern with payment networks. A rail is only as useful as the number of people on it, and each new participant makes it more useful to the rest.

The Fed adjusted the service to widen its uses. In late 2024 it raised the network’s maximum transaction limit from $500,000 to $1 million, to support larger business payments. A higher ceiling made the institution’s own limits, set by customer type, matter more.

Core processors remained the gating factor for most community institutions, both in technical readiness and in pricing. An institution could be ready in every other respect and still wait on its processor’s schedule, or find that the fees changed the business case.

The risk of ledgers held outside the core was shown dramatically, though in a different setting. In 2024 Synapse, a middleware firm that connected fintech apps to partner banks, collapsed into bankruptcy. Its records of who owned which funds could not be reconciled with the banks’ own. Customers were left unable to reach their money for months. Synapse was not a FedNow story, but it showed what can happen when a shadow ledger and the official one diverge and nobody can say which is right.

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 basic tension did not go away: payments that are fast and final are convenient for customers and for criminals alike.

The policy responses diverged by country. In October 2024 the United Kingdom began requiring payment firms to reimburse most victims of authorized push payment scams on its Faster Payments system, up to a cap. The United States took a different path. In December 2024 the CFPB sued Zelle’s operator and three large banks over fraud on that network, and the agency dropped the case in 2025. American institutions were left to set their own scam controls and reimbursement policies.

The federal government added its own push toward electronic money. In March 2025 an executive order directed agencies to stop issuing paper checks for most federal payments from September 30, 2025, with limited exceptions. The Treasury’s Bureau of the Fiscal Service, a FedNow participant from the first day, was charged with much of the transition. For receiving institutions, the direction of travel was clear: more government money arriving electronically, and customers expecting to use it at once.

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. Even an institution with no immediate plans for FedNow benefits from a core that updates balances as events happen, exposes data in real time and runs without a nightly pause.

For smaller institutions, the point reaches beyond payments. Your strategic options are bounded by what your core processor can do. The time to widen those options is at renewal, in writing, with service levels attached.