TL;DR: Roughly 43% of financial institutions still run a core banking system built more than 20 years ago, most of it COBOL on mainframe hardware, and 70% of banks say integrating with that legacy core is at least "somewhat" of an obstacle to shipping modern fintech products. The fix, in almost every real-world case, is not a rip-and-replace migration — it's a well-designed integration layer (API gateway, event streaming, or a "sidecar core") that exposes legacy functionality safely to modern applications while the underlying core is modernized incrementally, if at all. IDC projects 40% of global banks will run a sidecar strategy by 2026, rising to 70-80% by 2028.

The problem every fintech integration eventually runs into

A fintech app — a lending product, a budgeting tool, a business banking dashboard — almost always needs to talk to a bank's core system: account balances, transaction history, fund transfers, KYC data. The core system it needs to talk to was, in a large share of cases, built decades ago on a monolithic mainframe architecture, written in COBOL, and designed for nightly batch processing rather than real-time API calls. That mismatch — a modern app expecting instant, granular, well-documented API responses, talking to a system built for end-of-day batch runs — is the root cause of most core banking integration pain.

This isn't a fringe problem. Legacy core systems built on decades-old procedural languages, monolithic architectures, and batch-oriented processing remain the norm rather than the exception across the industry, and the talent that can maintain them — experienced COBOL engineers — is retiring faster than it's being replaced, pushing up consulting costs for even routine maintenance.

Why "just rip it out and replace it" rarely works

Every few years, a bank announces an ambitious core replacement project, and a meaningful share of those projects either stall, go dramatically over budget, or get quietly descoped into something much smaller than originally announced. There are structural reasons for this:

  • The core system is load-bearing for regulatory reporting, reconciliation, and decades of business logic that was never fully documented anywhere except the code itself. Replacing it means first reverse-engineering rules that may predate anyone currently on the team.
  • Downtime is not an option. A core banking system processes real customer money movement; a botched cutover has consequences well beyond a typical software outage.
  • Regulatory scrutiny on core transformation projects has tightened. The OCC's risk-based examination framework, effective January 2026, now treats an active core transformation as an elevated operational risk event requiring documented governance, tested rollback capability, and third-party vendor controls — which raises the bar (and the cost) for any full migration.
  • The technical debt often runs deeper than the API layer can hide. Wrapping a legacy core in a modern API makes the interface modern, but underneath, the COBOL engine is often still slow and batch-based — the wrapper improves developer experience without necessarily improving the underlying system's actual capacity for real-time processing.

The integration patterns that actually work

Given those constraints, most successful core banking integrations follow one of a small number of proven patterns, usually in combination:

1. API gateway / legacy wrapper layer

An integration layer sits in front of the legacy core and exposes modern, well-documented REST or GraphQL APIs, translating requests into whatever the core system actually understands (often still batch files, screen-scraping, or proprietary protocols under the hood). This is the fastest way to unblock fintech app development without touching the core itself, and it's where most banks start. The risk to manage here is treating the wrapper as the finished solution — it solves the interface problem, not the underlying latency or batch-processing limitations, so it works well for read-heavy use cases (balance checks, transaction history) and needs careful design for anything that requires real-time write consistency (fund transfers, holds).

2. Event-driven integration (change data capture / streaming)

Rather than polling the legacy core for changes, a change-data-capture layer streams events (a transaction posted, a balance changed) out of the core database or transaction log into a modern event bus (Kafka or similar), which downstream fintech applications subscribe to. This pattern handles real-time-feeling experiences (instant balance updates in a mobile app) without requiring the legacy core itself to become real-time — it just needs its existing data changes to be observable.

3. Sidecar core

A sidecar core is a separate, modern banking system that runs in parallel with the legacy core, gradually taking over specific products, customer segments, or functions (say, all new digital-only checking accounts) while the legacy core continues serving existing business. This avoids a single high-risk cutover in favor of an incremental one, and it's the pattern gaining the most traction — IDC projects 40% of global banks will be running some form of sidecar strategy by 2026, climbing toward 70-80% by 2028. The trade-off is running (and reconciling between) two systems during the transition period, which adds its own operational complexity, but it dramatically reduces the blast radius of any single failure compared to a full cutover.

4. Open banking API standards

Where regulation mandates it (UK Open Banking, EU PSD2, and an expanding set of similar frameworks elsewhere), banks are required to expose standardized APIs for account information and payment initiation. Building fintech integrations against these standardized interfaces, where available, is generally lower-risk and lower-maintenance than building bespoke integrations against a proprietary legacy interface, since the standard is maintained and versioned externally rather than being the bank's own one-off wrapper.

What tends to go wrong

A few recurring failure patterns show up across integration projects that run into trouble:

  • Underestimating batch-processing latency. A fintech app built assuming real-time balance accuracy breaks when the underlying core only reconciles overnight — users see stale data and file support tickets, or worse, a transaction appears to succeed twice because the app didn't account for the core's actual settlement timing.
  • No clear ownership of the integration layer. When the wrapper API is treated as "the bank's problem" by the fintech team and "the fintech's problem" by the bank's IT team, it ends up unmaintained, undocumented, and eventually a bigger liability than the legacy system itself.
  • Skipping reconciliation tooling. Any architecture running two systems in parallel (sidecar, event-driven sync) needs robust reconciliation — automated checks that catch drift between the legacy system of record and the modern layer before a customer-facing discrepancy happens.
  • Treating the integration as a one-time project rather than an ongoing capability. Core systems change, regulations change, and fintech product requirements change continuously — the integration layer needs an owner and a maintenance budget, not just a launch date.

A practical roadmap

Step 1 — Map what actually needs to move in real time versus what can stay batch. Not every use case requires real-time core access. Balance display can often tolerate a short delay; a fund transfer confirmation usually can't. Segmenting requirements this way avoids over-engineering the integration.

Step 2 — Build (or adopt) an API gateway layer first. This unblocks the fastest set of fintech use cases with the lowest risk to the core, and it's reversible — you're not committing to a specific long-term architecture yet.

Step 3 — Add event streaming for the use cases that genuinely need near-real-time visibility. This is where user experience gains (instant notifications, live balance updates) usually come from.

Step 4 — Evaluate a sidecar core only once the API layer's limitations become the actual bottleneck, not before. Many banks find the API and event-streaming layers sufficient for years, and a sidecar core is a significant undertaking that should be justified by a specific, quantified business need (a new digital-only product line, a specific customer segment growing faster than the legacy core can economically support) rather than pursued as a trend.

Step 5 — Build reconciliation and monitoring in from day one, not as an afterthought once a discrepancy has already reached a customer.

Team and governance implications

Integrating with a legacy core isn't purely a technical exercise — it changes who needs to be in the room for every fintech feature decision. A team building against modern legacy infrastructure typically needs at least one person who deeply understands the core system's actual behavior (not just its documented API), because the gap between documented behavior and actual behavior is where most production incidents originate. Banks that centralize this expertise — a small platform team that owns the integration layer and understands both the legacy core and the modern consumers of it — tend to ship fintech features faster and with fewer incidents than banks where every product team builds its own ad hoc connection to the core.

Governance has gotten more formal too. Under the OCC's 2026 risk-based examination framework, any active core transformation work — including significant integration-layer changes, not just full core replacements — is treated as an elevated operational risk event. That means documented rollback plans, tested failover procedures, and clear third-party vendor controls for any external integration partner. Banks that built their API gateway or sidecar strategy without this governance layer in place are increasingly finding they need to retrofit it, which is a good argument for building the documentation and rollback tooling alongside the integration from the start rather than after an examiner asks for it.

Cost and timeline expectations

Budget conversations around core banking integration tend to go sideways when the scope isn't segmented clearly. As a rough guide:

  • An API gateway covering read-only use cases (balance inquiry, transaction history, account details) is the fastest and lowest-risk piece — typically a few months of focused engineering work, assuming reasonable access to the legacy core's existing interfaces.
  • Write operations through the gateway (initiating transfers, updating account details) require significantly more validation, error handling, and reconciliation logic, and typically take proportionally longer given the higher stakes of getting them wrong.
  • Event-driven / change-data-capture layers add meaningful infrastructure work (a message bus, monitoring, replay/recovery tooling) on top of the gateway, and are usually a second phase rather than a starting point.
  • A full sidecar core is a multi-year undertaking on the scale of hundreds of thousands to millions of dollars, and should only be pursued once a specific, quantified business case justifies it — not as a default modernization strategy.

The single biggest cost driver, in practice, isn't the modern side of the integration — it's how well-documented and stable the legacy core's actual behavior is. A legacy system with clear, consistent interfaces (even if old) integrates faster and cheaper than one with undocumented edge cases and inconsistent batch timing, regardless of how modern the target architecture is.

Where Syslabs fits in

We build the integration layer that sits between legacy core banking infrastructure and the fintech products that need to talk to it — API integration work that exposes modern, well-documented interfaces without requiring a bank to commit to a full core replacement before shipping. We also work with fintechs on the other side of that integration: building custom software that's designed from the start to handle the realities of batch-based legacy data (eventual consistency, reconciliation, graceful degradation) rather than assuming a real-time core that doesn't exist yet. If you're scoping a core banking integration and trying to figure out whether you need a wrapper, an event pipeline, or a sidecar core, that's the conversation worth having before any code gets written.

Sources: DreamFactory — Legacy System Modernization Statistics 2026, Crassula — Legacy Core Banking Systems, Gart Solutions — Core Banking Modernization, Backbase — Banking Modernization 2026, Insight Global — Open Banking Clarity 2026