The accumulation problem: technical debt in core banking
Core banking systems age differently from other enterprise software. Because they process every transaction the bank touches, they accumulate workarounds and extensions at a pace that reflects the bank's own product evolution. Each workaround that is not resolved in the next upgrade cycle becomes harder to address in the one after that.
After five or six deferred upgrade cycles, the customisation layer has grown complex enough that a standard upgrade project is no longer straightforward. The bank is now looking at a modernisation programme, not a maintenance task.
Why banks defer upgrades and the real cost
The reasons banks defer core banking upgrades are predictable: competing transformation priorities, risk aversion during stable operating periods, and the difficulty of building a business case for work that prevents problems rather than creates visible new capability.
The cost of deferral is rarely captured in a single budget line. It appears as increased support effort, growing consultant dependency on legacy expertise, integration failures when adjacent systems are upgraded, and eventual regulatory non-compliance when the running version falls out of vendor support.
Regulatory pressure as a forcing function
Central banks in several markets where Finexta operates have begun specifying minimum version requirements for core banking platforms, particularly as these relate to real-time payment infrastructure and anti-money laundering data reporting. Where a bank has deferred upgrades, these regulatory requirements create a forcing function that compresses the implementation timeline.
A compressed timeline increases delivery risk, requires more parallel resources, and typically results in a programme that costs more than a planned upgrade would have.
What a disciplined upgrade cycle looks like
Banks that maintain a regular upgrade cadence — typically every two to three years for major Oracle Banking releases — treat the upgrade as a standard programme of work rather than an exceptional project. They maintain a current record of every customisation and integration, understand which customisations are still required and which can be retired, and allocate budget for upgrade work in the same planning cycle as any other operational expenditure.
Building internal capacity vs relying on vendors
One consequence of deferred upgrades is that internal knowledge of the system becomes concentrated in a small group of long-tenured staff or external consultants who have worked on the system for years. When those people leave, the bank's ability to manage the next upgrade safely is reduced.
Banks with disciplined upgrade cycles tend to maintain broader internal knowledge of the system. Each upgrade cycle is an opportunity to document the system's current state and train staff on the new version.
The case for incremental modernisation
The banking industry's experience with large-scale core replacement programmes over the past decade has tempered enthusiasm for big-bang modernisation. Many programmes that began as comprehensive replacements ended as expensive hybrid states, with the new system running alongside the old one indefinitely.
Incremental modernisation — keeping the core current while progressively modernising the surrounding technology layer — has a better delivery record. It requires discipline and consistent investment, but it avoids the concentration of risk that comes with attempting to replace everything at once.