Almost every core banking conversation I have starts in the wrong place. Someone says the core is old, someone else names the year it went live or the language it is written in, and the discussion turns to replacement. But age is not what makes a core expensive. Plenty of decades-old systems still post transactions reliably every night. What makes a core expensive is everything the bank has done to it since go-live. This is the first of six parts on core banking modernisation, and it starts with the diagnosis, because a bank that cannot say how its core aged will not build a credible case for replacing it.

The question is no longer only an internal one. On 11 September 2026 the Federal Reserve, the FDIC and the OCC issued a joint statement on community banks' engagement with core providers[1]. It calls core providers community banks' "most material, complex, and highest-risk third-party relationships", and says the agencies will weigh, among other things, "excessive limitations on the ability of unaffiliated service providers to integrate with the core platform" and how providers manage "end-of-support and end-of-life assets" when deciding how closely to supervise them[2]. The statement follows an OCC request for information in November 2025 that raised concerns about consolidation and "reduced negotiating power for many community banks vis-à-vis their core service providers"[3]. When supervisors start treating integration limits as a risk factor, the shape of a bank's core has become a board matter.

Cores age by accretion, not by calendar

A core is designed around the products, channels and rules that existed when it was bought. Everything that arrives later has to be fitted around it. Each fit is reasonable on its own, approved by a sensible committee under a deadline. Together, they become the bottleneck.

I see four kinds of accretion, and almost every bank has all of them.

  1. Product clones. The quickest way to launch a variant of an existing product is to copy its product code and change a few parameters. Do that for every campaign, segment, legacy acquisition and grandfathered rate, and the core ends up holding far more product codes than the bank actually sells. Each one has to be tested when anything changes, and nobody is quite sure which can be retired.
  2. Sidecars. When the core cannot support something (a new loan type, a card programme, a partner's accounts, a multi-currency wallet), the bank puts a separate system next to it. That system holds its own copy of some balances, and every copy needs reconciling with the core, every day, forever.
  3. Interfaces. Every channel, payment scheme, regulatory report and fintech partner connects to the core somewhere. Many of those connections were built point to point, often around the core's batch cycle, and they carry business logic nobody documented. The core's real behaviour is no longer in the core; it is spread across the interfaces.
  4. Workarounds. Where systems do not fit, people and spreadsheets fill the gap: manual adjustments, end-user tools, overnight fixes. They work, which is why they survive.

A core does not age with the calendar. It ages with every product, partner and regulation that had to be bolted on around it.

Every copy of a balance is a reconciliation you run forever

Sidecars deserve particular attention, because they are where the risk hides. The collapse of Synapse in 2024 is the extreme case. The intermediary held the records of what each fintech customer owned in pooled accounts at its partner banks, and when it failed, the FDIC said the bankruptcy trustee and the banks "encountered significant difficulties in obtaining, reviewing, and reconciling Synapse's records" against the banks' own[4]. The FDIC's proposed response was to require banks to keep accurate records of beneficial owners and to reconcile such custodial accounts at least daily[4].

Most sidecars are not run by a failing intermediary. But the principle is the same: when the core is not the only place a balance lives, the bank's system of record has quietly become a set of systems that are supposed to agree. The more of them there are, the more the bank spends making them agree, and the less certain anyone is when they do not.

The symptoms show up far from the core

The cost of accretion rarely appears on the core's own budget line. It shows up elsewhere, which is why it is underestimated.

In risk reporting. The ECB's 2024 guide on risk data aggregation reports supervisors observing "large-scale miscalculations of key risk ratios and limits" caused by "reconciliation errors, extensive manual adjustments, inconsistent or incomplete underlying data, and weak data quality controls", and production times of "40 or more working days" for monthly risk reports at some banks[5]. The guide expects timely reporting to be unhampered by "a fragmented IT infrastructure or a large amount of manual aggregation processes"[5]. The Basel Committee's 2023 review of the 31 global systemically important banks concluded that "additional work is required at all banks to attain or sustain full compliance" with its risk data principles[6]. And the ECB's supervisory priorities for 2026 to 2028 still include remedying deficiencies in risk reporting and data aggregation[7]. That is not a reporting problem. It is the downstream cost of a fragmented book of record.

In resilience. In the UK, data gathered by the Treasury Committee showed at least 158 IT failure incidents at nine banks and building societies between January 2023 and February 2025, adding up to at least 803 hours of unplanned outages (Treasury Committee data, via cyprus-mail.com). Among the causes the banks gave were third-party suppliers, knock-on effects of system changes and internal software malfunctions[8]. Not every outage traces to a core. But when a change in one place breaks something in another, that is what tight, undocumented coupling looks like from the outside.

In speed. This is the one boards feel. A simple pricing change takes a quarter because it touches dozens of product codes, three sidecars and a batch schedule. A fintech partnership takes a year because the integration has to go through the provider's roadmap. The agencies' statement names this directly when it lists limits on unaffiliated providers integrating with the core[2].

Lock-in is accretion too

For banks on a provider's platform, the contract ages along with the code. The Kansas City Fed found that three providers served more than 70% of US banks surveyed in 2022, and cites survey data showing 61% of banks had been with their core provider for more than ten years[9]. Long tenure is not a problem in itself. It becomes one when every bolt-on was bought from, or built around, the same provider, so that the cost of leaving grows every year. The joint statement lists "unsupported or contractually undefined core deconversion fees" and opaque pricing and billing among the practices that make it hard for banks to manage these relationships[2]. I covered what happens when a provider extends further into a bank's stack in the Fiserv agentOS brief; the same logic applies to every bolt-on.

Measure the ageing before you price the cure

Most core business cases I review rest on anecdote: the core is slow, the vendor is difficult, the talent is retiring. All may be true, but none of it is measurable, and a board cannot weigh it against a nine-figure programme. The diagnosis should come first, and it should be numeric.

  • Product codes against products sold. How many live product codes does the core hold, and how many products does the bank actually market? The gap is the testing burden on every change.
  • Systems that hold a balance. List every system that keeps its own version of a customer balance or position. Each one is a permanent reconciliation.
  • Reconciliation breaks and manual adjustments. Count them monthly, by source system. This is the cost the ECB guide describes, and finance and risk already have the data.
  • Change lead time and change failure. How long does a routine parameter or pricing change take from request to production, and what share of core-related changes cause an incident?
  • Interfaces and their owners. How many integrations touch the core, how many are point to point, and how many have a named owner and current documentation?
  • Exit terms. What does the contract say about deconversion fees, data return and third-party integration? Read it before you need it.

What to do on Monday

Ask the CIO and CFO for those six numbers, together, within a month. Do not ask for a replacement option at the same time; the point is to see the shape of the problem first. Put the results in front of the risk committee alongside the risk-reporting timeline, because the two are the same problem. And if the bank is a US community bank, read the joint statement against the core contract, clause by clause.

The numbers will tell you whether the core is old or whether it is overgrown. They call for different responses, and only one of them needs a replacement. The next part of this series turns those numbers into the business case: what a core replacement really costs and pays back, and how to present it to a board.