Core system modernization for banks and insurers: the options

Core system modernization for banks and insurers comes down to three options: replace the whole core at once, replace it one component at a time, or wrap the existing core with a modern layer and move functions out gradually. Full replacement carries the most risk. Most institutions therefore work in phases, starting where customer impact is lowest and proving each step before taking the next.

What counts as a core system

For a bank, the core is the back-end system that processes daily transactions and keeps accounts and records up to date. A Federal Reserve Bank of Kansas City briefing on core banking systems and options for modernization (2024) lists its primary services as account and customer management, deposit and withdrawal processing, loan processing, and finance and accounting. For an insurer, the equivalent systems handle policy administration, billing and claims.

The briefing describes typical legacy cores as monolithic, with components intertwined after years of patches and customization, often running on a mainframe and needing specialist skills to maintain. Citing 2022 industry research, it notes that many institutions still run cores up to 40 years old. Newer systems use modular designs with APIs and cloud hosting. The gap shows up as slow product changes and difficulty supporting services such as instant payments and open banking.

Three options for core system modernization for banks and insurers

The Kansas City Fed briefing sets out three routes. The same choices apply to insurance platforms.

These are not exclusive. A common path is to wrap first, which buys time and creates clean interfaces, then replace components behind those interfaces.

How a phased approach works

The engineering pattern behind phased modernization is known as the strangler fig. Microsoft’s Azure Architecture Center describes the Strangler Fig pattern in four stages:

1. Put a facade, in effect a routing layer, between client applications and the legacy system. At first it sends most requests to the old system.
2. Build one piece of functionality in the new system and have the facade route those requests to it. Repeat, one piece at a time.
3. When nothing depends on the old system, decommission it.
4. Remove the facade, or keep it as an adapter for older clients.

Customers and channels keep using the same interface and should not notice the migration. The pattern has conditions. Microsoft notes it may not suit cases where requests to the back end cannot be intercepted, or where you need to retire the old system quickly. The facade must keep pace with the migration and must not become a single point of failure or a bottleneck.

During the transition both systems run and have to talk to each other. Microsoft recommends an anti-corruption layer for this: an adapter that translates between old and new so the new design is not forced to copy legacy conventions.

How to sequence the work

Order matters more than speed. A sequence that works for most programs:

1. Map the core. List its functions, the data each one owns, the batch jobs and every system that reads from or writes to it. Undocumented business rules usually surface here.
2. Create the interface layer. Expose core functions through APIs and events so channels stop depending on the legacy system directly.
3. Choose the first domain by risk, not by ambition. Pick something with clear boundaries and low customer visibility.
4. Run old and new in parallel and reconcile the results until they agree.
5. Migrate in cohorts, such as one product, region or branch group at a time.
6. Decommission. Plan and fund the switch-off as its own phase, or you will pay for both systems indefinitely.

The Kansas City Fed briefing gives a public example of this logic, drawn from a 2022 conference account. One regional bank upgraded the lending component of its core first because it had lower customer engagement and visibility. It then moved to deposits after extensive testing, ran the old and new systems side by side and migrated branches one at a time.

The 7 Rs of cloud migration offer a related way to decide what happens to each surrounding application while the core is being reworked.

Data migration and parallel running

Data is where core programs are won or lost. Microsoft’s guidance describes a careful sequence for each domain: load history into the new database, keep it in step with the old one through change data capture, and validate that the two agree before cutover. Only then does the new database become the system of record.

Rollback deserves the same attention. It remains practical while the legacy tables and synchronization are still in place. Once they are removed, going back means restoring objects and replaying changes, which adds effort and risk. Treat removal of the legacy data as a deliberate final step for each domain, taken only after the new system has been validated.

For financial institutions, reconciliation is the test that counts. Balances, interest, premiums and reserves must match to the cent across both systems for an agreed period before anyone signs off.

Vendors, contracts and regulators

Most banks rely on a core provider, so modernization is also a vendor program. The Kansas City Fed briefing warns that ownership of customer data is often ambiguous in core provider contracts, and that an institution will face sizable cost when switching if the provider owns the data. Review data ownership, export rights and exit terms before you plan anything else.

In the United States, the banking agencies’ 2023 interagency guidance on third-party relationships describes a risk management life cycle for vendor relationships and says practices should be commensurate with the bank’s risk profile and the criticality of the activity. A core platform is about as critical as an activity gets. Insurers answer to their own regulators, and rules differ by country. Involve your compliance team and advisers from the start and confirm what applies to you. If the program includes new models or AI, the review process in AI model risk management in banking is worth reading alongside this.

How YLinkTech helps

We work with banks, lenders and insurers through our Cloud & Modernization practice. Our application modernization work uses AI-assisted analysis to map legacy code, dependencies and undocumented business rules, then rebuilds in phases behind APIs, with automated tests to show that the new system behaves like the old one. We favor phased programs over big-bang rewrites. To talk through your core and your constraints, contact us.

Frequently asked questions

Sources

• Federal Reserve Bank of Kansas City: Core Banking Systems and Options for Modernization (2024)
• Microsoft Azure Architecture Center: Strangler Fig pattern
• Office of the Comptroller of the Currency: Bulletin 2023-17, Third-Party Relationships: Interagency Guidance on Risk Management

This article is general information, not professional advice. See our Disclaimer.