Modernizing banking core systems

Banking core systems are the least glamorous and most consequential software in a bank. They hold the ledger, the accounts, the interest accruals, and the audit trail that regulators read on a bad Monday morning. When they break, a bank stops. When they age, everything built on top slows down with them.

Most banks we work with are not replacing their core. They are trying to make a thirty year old mainframe behave like a modern platform without triggering a two year freeze on product launches. That is a specific kind of engineering problem, and it is where embedded senior teams tend to earn their keep.

Why banking core systems resist modernization

A core banking system is not one system. It is a ledger, a product catalog, a batch scheduler, an authorization engine, a reporting layer, and a set of nightly jobs that other departments have quietly built their month end around. Every one of those has consumers, and most of the consumers are not documented.

The result is that a rip and replace project looks tractable on a slide and impossible in a sprint. Analysts at McKinsey have noted that most full core replacements run three to seven years and a material share are abandoned or descoped. The reason is rarely the new platform. It is the integration surface no one mapped before the RFP went out.

Modernization is therefore an integration and decomposition problem more than a vendor selection problem. The interesting engineering happens at the seams.

Fiserv core banking systems and the incumbent reality

Fiserv core banking systems, along with FIS, Temenos, TCS BaNCS, and Finastra, run a large share of retail and commercial banking globally. Most of our fintech engagements sit next to one of these, not instead of one.

That matters for how you scope a modernization. The incumbent core is going to be there for years. The realistic goal is to stop the core from being on the critical path for every new product, every new channel, and every new regulatory requirement.

The strangler pattern, applied to banking

Martin Fowler's strangler fig pattern is the default approach and for good reason. You wrap the core with an API layer, route new functionality to modern services, and gradually move read and write paths out of the mainframe as confidence grows.

In banking, the strangler has three practical shapes:

• A canonical account and customer API in front of the core, so downstream systems stop talking to the mainframe directly.
• An event stream, usually Kafka, that publishes ledger events for consumers who used to run nightly extracts.
• A product engine outside the core, so new deposit and lending products do not require a core release cycle.

None of this is exotic. The difficulty is doing it without breaking reconciliation, and that requires engineers who have seen a general ledger before.

Top core banking systems, and what actually differentiates them

When clients ask us to rank the top core banking systems, we push back on the framing. Rankings are misleading because the fit depends on the bank's product mix, regulatory footprint, and existing integrations.

What matters more, in our experience:

1. Does the core expose real time APIs, or only batch and file interfaces?
2. Can it publish events, or does every consumer have to poll?
3. How is the product catalog modeled, and can it be extended without a vendor change request?
4. What is the actual cost of a test environment, in time and money?
5. Is the data model documented well enough for a new team to build against in a quarter?

A core that scores well on these questions is modernizable. A core that scores poorly will drag every project attached to it, regardless of vendor marketing.

How embedded engineering changes the shape of the project

Most core modernization work is delivered through large system integrators with fixed price statements of work. That model optimizes for contract clarity, not for the reality that half the requirements will change once the team is inside the code.

Our bias, unsurprisingly, is toward embedded teams. Devspace places senior engineers from our network of 500+ across Europe directly into a bank's own squads, working the bank's Jira, the bank's repo, and the bank's release process. It is a remote development team model, time and materials, no fixed scope lock in.

The reason this fits core modernization specifically:

• Requirements shift weekly as integration surprises surface. Fixed scope contracts turn every surprise into a change request negotiation.
• Domain knowledge compounds. An engineer who spent six months learning your ledger quirks is more valuable in month seven than a fresh consultant in month one. 60% of our assignments extend for this reason.
• Regulatory review requires the bank to own the code and the decisions. Embedded engineers make that ownership real.

A modernization checklist worth keeping

Before committing to a core modernization roadmap, we usually walk clients through this list. It is not exhaustive, but it exposes the questions that quietly kill projects.

1. Map every consumer of the core, including the spreadsheets. Especially the spreadsheets.
2. Identify the three integrations that would cause the largest operational incident if they broke. Design around those first.
3. Decide whether the general ledger stays in the core or moves. This is the single biggest architectural choice and it is often deferred too long.
4. Build the event stream before you build the new services. Consumers will find uses you did not plan for.
5. Instrument reconciliation from day one. If you cannot prove the new path matches the old path to the cent, you cannot cut over.
6. Keep a rollback path for every migration wave. Big bang cutovers in banking rarely end well.
7. Assume the vendor roadmap will slip. Plan the sequence so your progress does not depend on it.

Where the CTO conversation lands

For scale ups moving into regulated banking, or PE backed neobanks planning a platform overhaul, the harder question is often organizational rather than technical. Who owns the roadmap, who decides the sequence, and who says no when a business unit asks for a shortcut that will cost eighteen months later.

That is the work of a Fractional CTO, and it is often the missing piece in modernization programs that have plenty of engineers and not enough architectural authority. A part time senior technical leader who has done this before will move a program faster than three more developers.

The pattern that tends to work

The banks and fintechs we see succeed at modernizing banking core systems share a few habits. They treat the core as a component, not the platform. They invest in the integration and event layer before the shiny new services. They keep teams small, senior, and stable across years, not months. And they resist the temptation to declare victory when the first new product ships, because the second and third products are what prove the architecture.

None of this is a secret. It is just harder to execute than the slideware suggests, and it rewards teams that have done it before.

Photo by Tyler on Unsplash