Table of Contents
Core Banking Modernization: The FedNow Send Gap Mid-Market Banks Can’t Ignore
Your bank is live on FedNow. Customers can receive instant payments. The press release went out. The board checked a box.
Then a business client asked to send a payroll disbursement via FedNow. And the answer was no.
That asymmetry, receive-yes and send-no, is not a payments department problem. It’s a core infrastructure diagnostic. Your core system can’t process a send transaction in real time because it was built around a fundamentally different architecture: one designed for a world where money moved overnight, not instantly. The same architectural constraint that blocks real-time payment sends also explains why your AI modernization initiatives have stalled, why your compliance reporting is getting harder, and why your most operationally sophisticated business clients are quietly paying attention.
This guide is for CEOs and CTOs at mid-market banks (roughly $1B to $10B in assets) who want to understand what the FedNow send gap actually signals, what the three realistic modernization paths look like, and how to diagnose where your core stands before your next board meeting.
1. Most mid-market banks can receive FedNow payments but can’t send them. The gap comes from batch-processing core architecture, not a settings problem.
2. The send gap is a diagnostic: if your core can’t send real-time payments, it can’t support real-time AI, modern compliance reporting, or digital-first business accounts.
3. Three paths exist: full core replacement (3-5 years, high risk), sidecar core (run modern alongside legacy), or payment hub wrapper (an API layer that buys time without locking you in).
4. Accenture’s 2026 banking survey puts 70% of bank IT budgets toward maintaining technical debt. The cost of staying put compounds annually.
5. Sidecar and API-layer approaches can achieve FedNow send capability in months, not years.
The Asymmetry Your Board Should Be Asking About: You Can Receive, But You Can’t Send
Your board may not have asked this question yet. Most haven’t. But the gap between receive participation and send capability at mid-market banks is one of the clearest signals of core system readiness you can get without a full technical audit, and it’s hiding inside your FedNow enrollment status.
A diagram showing the asymmetry between FedNow receive-only and full send/receive participation across mid-market bank tiers.
Receiving FedNow payments doesn’t require real-time processing. Your correspondent bank or FedNow-certified service provider handles the inbound transaction. Your core processes it during the next available window. It looks like instant payments. It isn’t. The moment you need to send, your core must generate, validate, and clear a transaction in real time. Most legacy cores weren’t built for that.
How receive-only FedNow participation became the easy default
When FedNow launched in 2023, the Federal Reserve structured onboarding to allow receive-only participation. Banks could claim instant payment capability, satisfy early regulatory questions, and satisfy their boards without touching their core systems. For institutions managing constrained IT budgets, this was an attractive option. Receive-only participation is genuinely useful: it lets customers get paid instantly even if the bank hasn’t addressed the harder infrastructure work.
But receive-only became the default for a reason that has nothing to do with strategy. It’s all that many legacy cores can technically support. Enabling send requires the core to operate in a fundamentally different mode. The architectural difference between “can receive” and “can send” is the difference between a passive participant and an active one. Active participation exposes exactly what the legacy system can and cannot do.
What it actually means when your core can’t support send: a technical plain-English explanation
Legacy core banking systems were built on a batch processing architecture. At a defined interval, usually overnight, the system collects all pending transactions, processes them in sequence, and updates account balances. FedNow send requires something different: when a business customer initiates an instant payment, your core system needs to validate available funds, generate the transaction message, submit it to FedNow, receive confirmation, and update the account ledger, all within seconds.
A batch-processing architecture can’t do this. The core doesn’t have a transaction pipeline that works that way. This isn’t a configuration issue or a vendor update. It’s a design philosophy baked into systems that, in many cases, include code written before the year 2000. A CIO study cited by The Financial Revolutionist found 63% of banks still rely on pre-2000 code, a figure consistent with how long the dominant core banking platforms have been in production. The design assumptions of those platforms didn’t include real-time clearing because real-time clearing didn’t exist when they were built.
Batch vs. Real-Time: Why Your Core Processes Money the Way a 1985 Mainframe Does
Batch processing works by accumulating transactions and processing them in bulk at scheduled intervals. End-of-day settlement, overnight clearing, and next-day balance updates are all artifacts of this architecture. The design made sense when wire transfers and ACH were the fastest payment mechanisms available, and when computing resources were too expensive to run continuously.
The architecture of batch processing and why it fundamentally blocks send capability
A batch core maintains a queue. Transactions sit in that queue until the processing window opens. The core isn’t listening for incoming events in real time. It isn’t running a continuous reconciliation loop. It processes when scheduled, not when triggered.
Real-time payments require an event-driven architecture. The moment a transaction request arrives, the system needs to respond: check balance, validate, authorize, submit, confirm, and update. All of that in under five seconds. A queue-based system can’t close that loop. The processing model is incompatible at the architecture level, not the feature level.
What “end-of-day settlement” actually costs you in 2026
There’s a line-item cost and a competitive cost. The line-item cost is operational overhead: exceptions, manual reconciliation, the staff hours that go into managing settlement windows. These are real but often absorbed into overhead without being named.
The competitive cost is more significant. Business customers running payroll, managing cash positions, or operating across multiple markets increasingly expect intraday finality. A regional competitor running a modern core, or a fintech-as-a-service platform, can offer it. When your business clients notice the gap, they don’t call to complain. They open a second account somewhere else.
Accenture’s 2026 banking survey found that 70% of bank IT budgets go toward maintaining technical debt. That figure includes the operational overhead of working around batch processing limitations. The real cost of end-of-day settlement isn’t just the settlement itself. It’s everything your organization does to compensate for not having a real-time core.
What the Send Gap Is Actually Telling You: Three Downstream Risks Beyond Payments
The FedNow send gap matters for payments. But a CTO who frames it only as a payments problem is reading the signal wrong. The same architectural limitation that prevents real-time payment sends also predicts your position on three other dimensions: AI integration capacity, regulatory compliance posture, and competitive account retention.
Three downstream risk areas connected to legacy batch-processing core architecture at mid-market banks.
AI integration readiness: why a batch core can’t support real-time model inference
A fraud detection model that scores transactions in real time needs to operate in the same event-driven environment as the transaction itself. The model receives a transaction event, evaluates it, returns a score, and influences the authorization decision, all before the transaction clears. A batch core doesn’t generate those events in real time. The model has nothing to score until the batch runs.
This is why AI projects at banks with legacy cores consistently stall at the pilot stage. The pilot environment simulates event-driven behavior. Production doesn’t support it. When the pilot works and deployment doesn’t, the gap is almost always infrastructure, not model quality.
The IBM Institute for Business Value’s 2025 survey of banking CIOs found that less than half reported meaningful gains on desired business benefits from core modernization programs. The reason isn’t failure of ambition. Modernization attempts that don’t address the batch-vs-real-time architecture gap produce incremental improvements on top of a fundamentally limiting foundation.
Regulatory compliance posture: what examiners are starting to ask about real-time infrastructure
Bank examiners are asking about real-time monitoring and reporting capabilities: BSA/AML compliance, liquidity management, and operational risk. A batch-processing core generates compliance data on a scheduled basis, not a continuous one. This creates surveillance gaps that examiners are trained to identify.
This pressure will increase as regulators align their own systems with real-time infrastructure standards. A mid-market bank that hasn’t addressed batch limitations will face growing examiner friction on compliance reporting, regardless of whatever front-end investments it has made.
Competitive deposit attrition: when your business customers notice
Mid-market businesses, the commercial accounts that generate a disproportionate share of fee income and deposit balances, are run by people who understand operational technology. They know what instant settlement means for cash management. And increasingly, they have options.
Fintechs and digital-first banks have no legacy core constraint. Regional banks that have completed or partially completed core modernization are competing for exactly these accounts. The commercial clients who notice the send gap first are the ones you can least afford to lose.
The Three Paths Mid-Market Banks Are Taking: Honest Tradeoffs
Three modernization paths dominate the conversation at banks in the $1B to $10B asset range. Each has genuine merit and genuine risk. Any consultant who presents only one option without acknowledging the others is optimizing for their own product, not your situation.
Comparison of three core banking modernization paths: full replacement, sidecar strategy, and payment hub wrapper, with timeline, cost, and risk tradeoffs.
Path 1: Full core replacement (the 3-to-5-year commitment most boards aren’t ready for)
Full replacement means selecting a next-generation core banking platform and migrating all accounts, transactions, and data from the legacy system to the new one. When it works, the outcome is a clean slate: event-driven architecture, API-first design, cloud-native infrastructure, and full support for FedNow send, real-time AI, and modern compliance reporting.
The risk profile is significant. The Kansas City Federal Reserve’s analysis of core banking modernization options identifies full replacement as the highest-disruption path, requiring years of parallel operation, complex data migration, and a cutover event that carries material operational risk. IBM IBV’s 2025 data adds context: 73% of banking CIOs said managing costs became harder after modernization attempts, and less than half reported meaningful gains on their original business benefits.
Full replacement is the right answer when the legacy system is genuinely unrepairable, when the organization has the capital and executive bandwidth to absorb a multi-year migration, and when the board holds realistic expectations about timeline and disruption. For most mid-market banks with constrained IT budgets and limited staff, it isn’t the starting point.
Path 2: The sidecar strategy (run modern alongside legacy, no cutover day)
The sidecar approach deploys a modern core alongside the existing legacy platform rather than replacing it. New products and new account types run on the modern system. Legacy products stay on the old one. Over time, as accounts migrate and products sunset, the balance shifts.
The sidecar addresses FedNow send directly: new business accounts or payment types run through the modern sidecar, which has the event-driven architecture required for real-time processing. The legacy core keeps handling existing accounts without disruption.
The tradeoff is operational complexity. Running two cores means managing two systems, two data models, and synchronization logic between them. For banks with limited IT capacity, that overhead is real. The sidecar is a risk-managed path, not a simple one.
Path 3: Payment hub wrapper, an API abstraction layer that buys you time without locking you in
The payment hub approach doesn’t replace the legacy core. A payment hub or API middleware layer sits between the core and the payment network. The hub handles the real-time event processing FedNow send requires, translates between real-time protocols and the batch logic of the legacy core, and delivers the capability without requiring the underlying system to change.
This path gets a bank to FedNow send capability in the shortest timeline, often 90 to 180 days. It also preserves optionality: the abstraction layer doesn’t lock the bank into a specific future modernization path.
The honest limitation: the hub is a bridge, not a destination. It doesn’t solve the batch architecture problem; it routes around it. AI integration, real-time compliance monitoring, and the full commercial account experience all eventually require the core to change. The hub buys time and capability. It doesn’t eliminate the underlying constraint.
Why Sidecar and API-Layer Approaches Succeed Where Full Replacement Fails
A full core replacement has failed at enough institutions (on timeline, cost, and business case) that treating it as the default option is operationally reckless for most mid-market banks. Sidecar and API-layer approaches have a better track record for a structural reason: they don’t require everything to go right simultaneously.
Why legacy core operating costs make full replacement financially hard
Accenture’s 2026 banking survey captures the pattern: 70% of bank IT budgets consumed by technical debt maintenance, leaving 30 cents of every IT dollar available for anything else. That ratio makes full replacement financially difficult. Banks spending the majority of their technology budget on maintenance don’t have the capital available for a 3-to-5-year parallel-system migration. They need a path that produces capability and cost relief on a shorter timeline.
Galileo Financial Technologies’ analysis of operating costs suggests legacy core expenses can run roughly 10 times higher than modern system equivalents once you account for maintenance, exception handling, and integration overhead. This is a vendor-sourced figure, so treat it as directional, but the directional point aligns with what the Accenture data captures: the maintenance burden is the constraint that makes everything else harder.
The COBOL retirement problem: what happens when your last legacy maintainer leaves
The Financial Revolutionist, citing a CIO study, found over three-quarters of banks have only one or two people capable of maintaining their legacy code. The Open Mainframe Project’s 2020 analysis put the average COBOL programmer age at 58, with approximately 10% retiring annually. That retirement curve has been running for six years since that analysis was published.
“unquantifiable risk of retiring domain experts whose institutional knowledge is embedded in undocumented, bespoke COBOL business logic, making simple mid-tier maintenance a cascading operational liability.”
When the last person who understands how the core works retires, the bank faces a knowledge loss event that makes any modernization approach dramatically more expensive and risky. The window for a knowledge-guided incremental migration is narrowing. Every bank running on legacy cores is somewhere on that staffing curve, and the curve is running in one direction.
How incremental approaches get to FedNow send in months, not years
A payment hub wrapper can be scoped, built, and validated in 90 to 180 days for a mid-market bank with a reasonably documented API surface. The sidecar approach takes longer, typically 12 to 18 months before meaningful account migration begins, but neither timeline resembles the 3-to-5-year commitment of full replacement.
The timeline advantage compounds. Every month on a legacy core with no FedNow send capability is a month where commercial account attrition can accelerate, where examiner friction on real-time reporting grows, and where the competitive gap with digital-first alternatives widens. An incremental path that delivers FedNow send in Phase 1 and keeps modernization moving in subsequent phases captures business value faster than a replacement project that delivers nothing until cutover.
What “Execution Without a 3-Year Shutdown” Actually Looks Like
Strategy only matters when it connects to an implementation model. This section covers what incremental core modernization actually looks like at a mid-market bank: the sequencing, the architecture, and the real preconditions.
The phased migration model: peripheral systems before the core
Start with peripheral systems, the systems that interact with the core but don’t constitute it. Online banking interfaces, mobile apps, reporting pipelines, fraud detection layers. Modernizing these doesn’t require touching the core’s transaction processing logic. It builds the skills, patterns, and organizational confidence needed when the core itself is on the table.
Peripheral modernization also produces measurable business value early. A modern mobile banking interface runs faster and supports richer features. A cloud-based reporting pipeline produces compliance data on a shorter cycle. Each peripheral win reduces the dependency on the legacy core, makes the eventual core migration smaller in scope, and funds the modernization roadmap with demonstrated ROI.
API abstraction layer as a translation bridge: how it works in practice
A FedNow send request arrives at the payment hub. The hub validates, formats, and submits the transaction to FedNow in real time. It then posts a ledger entry to the legacy core through whatever mechanism the core supports, often a queued API or file-based interface. The core processes the ledger entry in its next available window.
There’s a short reconciliation gap between when FedNow confirms the transaction and when the legacy core’s ledger reflects it. For most payment types, this gap is operationally acceptable. The point is that the gap is manageable, and far smaller than the gap between having FedNow send capability and not having it.
What a mid-market bank realistically needs to have in place before starting
Three preconditions matter most. First, documented core APIs: the abstraction layer needs something to connect to. If the legacy core has no documented API surface, mapping it is the actual first step. That’s a scoping exercise, not a modernization project, but it needs to happen before technical work begins.
Second, a clear FedNow certification path: if the bank hasn’t begun FedNow send certification with its service provider, that process runs in parallel with the technical build.
Third, an internal technical owner: someone on the bank’s side who understands the core well enough to validate integration logic and approve testing milestones. They don’t need to be a core banking architect. They need to understand the core’s transaction model and have the authority to make decisions during implementation.
These preconditions can be assessed in a few weeks. If they’re not in place, the modernization project starts with a documentation and scoping phase, not a build phase.
How to Diagnose Your Own Core Readiness in 30 Minutes
If you’re a CTO at a mid-market bank, you should be able to answer every question below without pulling up a vendor presentation. If you can’t answer them, that inability is itself the answer.
Five questions your CTO should answer before your next board meeting
1. Does your core support API-based transaction initiation, or does it require file-based input?**
A core that accepts transactions only via file upload or batch input cannot support real-time payment send without an abstraction layer. If the answer is “file-based” or “I’m not sure,” your FedNow send path requires a hub, not a direct integration.
2. What is the batch processing cycle: when does your core run, and how long does a cycle take?**
A nightly batch that runs for four hours means four hours per day, where real-time response is structurally impossible. Understanding the batch cycle tells you the exact constraint you’re working around and how much it matters for your specific payment use cases.
3. How many people in your organization can modify core transaction processing logic?**
One or two people is both a staffing risk and a modernization constraint. When those individuals retire or leave, the knowledge required to safely implement any modernization path leaves with them. The number doesn’t need to be large. It must be more than one.
4. When you run AI or analytics models in your environment, are they scoring transactions in real time or post-batch?**
Post-batch scoring means your fraud detection, credit models, and any other analytical tools are running on data that’s already hours old. Real-time scoring requires real-time data pipelines. If the answer is post-batch, your AI investments have an architecture ceiling they haven’t reached yet.
5. In your last regulatory examination, were there any findings related to real-time monitoring or surveillance coverage gaps?
Examination findings on monitoring gaps often trace directly to batch processing limitations. This question surfaces compliance risk that may already be in an open finding, and that a phased modernization program can address directly.
What your FedNow participation status actually reveals about your modernization posture
Receive-only or not yet onboarded means your core hasn’t been tested against real-time send requirements. It’s the starting position for most mid-market banks, and it’s recoverable. The diagnostic value is in understanding why the limitation exists. Is it architecture, budget, or decision? Which path forward fits your specific constraints?
Finzly, a payments technology vendor (with commercial interest in this figure), reported that nearly three-quarters of financial institutions cite moderate to severe challenges with legacy systems in handling instant payments send. The receive/send gap is not a minority problem at mid-market banks. It’s the baseline condition. The question is what you do with it.
What This Means If You’re Ready to Move
Sitting on receive-only FedNow participation isn’t a neutral holding position. Commercial clients who need instant outbound payments will find a bank that can send them. Your examiners will notice the real-time reporting gaps. And every AI initiative that needs event-driven data will hit the same ceiling, over and over, until the infrastructure changes.
The FedNow send gap is diagnostic, not merely operational. It tells you precisely where your core’s architecture ends and where the modernization work begins. That clarity has real value: you can scope the problem, sequence a response, and choose a path that delivers capability in months rather than years.
Nearshore beats offshore for most mid-market bank modernization projects, and a phased approach beats full replacement for most institutions in the $1B to $10B range. Both positions are based on the same logic: scope risk to what you can execute, prove value before expanding, and keep the existing system running while you build something better alongside it.
Nexa builds and deploys the middleware and API-layer components that connect legacy banking infrastructure to modern payment networks and AI-ready systems, without requiring a multi-year core replacement project. Every engagement delivers complete documentation that your team owns, backed by SLA-based ongoing support.
FAQ
Why are banks slow to adopt FedNow send capabilities?
Most mid-market banks cannot enable FedNow send without modifying their core banking architecture, which operates on batch processing designed decades ago. Receive-only participation is easier because it does not require the core to generate real-time transactions. Enabling send exposes the architectural limitation directly, and fixing it requires either an abstraction layer or partial core modernization, both of which require budget and planning.
What is the difference between FedNow receive-only and send participation?
Receive-only means your bank can accept instant payments from other institutions. Your core processes them in the next batch window, but customers see funds arrive quickly. Sending participation means your core can generate and submit instant payment instructions in real time. Send requires event-driven processing capability that many legacy cores do not have.
What is a sidecar core banking strategy, and how does it work?
A sidecar deploys a modern core banking system alongside your existing legacy platform rather than replacing it. New products and account types run on the modern system, while the legacy core keeps handling existing accounts. Accounts migrate incrementally over time, avoiding a single high-risk cutover. The tradeoff is complexity: two systems require two data models, synchronization logic, and additional operational overhead.
How does legacy core banking infrastructure prevent real-time payment processing?
Legacy cores are built on a batch processing architecture. They collect transactions in a queue and process them at scheduled intervals, typically overnight. FedNow send requires real-time event-driven processing: the core must respond within seconds. A batch core cannot do this. The constraint is architectural design, not a missing feature.
What is the cost of maintaining a legacy core banking system vs. modernizing?
Accenture’s 2026 banking survey found 70% of bank IT budgets go toward technical debt maintenance. Incremental approaches, including payment hub wrappers and sidecar strategies, can deliver FedNow send in 90 to 180 days and begin shifting the maintenance ratio. Full core replacement takes 3 to 5 years but delivers a clean architectural slate when executed successfully.
How long does core banking modernization typically take for a mid-market bank?
Full core replacement takes 3 to 5 years. A payment hub wrapper enabling FedNow send can typically be delivered in 90 to 180 days for a bank with a documented API surface. A sidecar approach takes 12 to 18 months before meaningful account migration begins. IBM IBV 2025 data found less than half of banking CIOs reported meaningful gains from modernization attempts, which is why path selection matters as much as speed.