Core Banking Wasn't Built to Be Replaced

Banks spend over $60 billion a year on core banking systems. That's more than NASA's entire annual budget, spent on software that, from the outside, just tracks account balances.

If you ask why, you'll hear that banks are stuck on COBOL and large organizations move slowly.

But plenty of industries run software from the 1980s without burning $60 billion a year to keep it alive.

The problem stems from an architecture designed for a world that no longer exists. Core banking systems were built around a constraint that made perfect sense in 1975 — every data model, every integration, every regulatory process assumes banks close at 5pm. The $60 billion is what it costs to run that architecture in a world that never closes.

What "core banking" actually means

When a bank says "core banking system," they don't mean one piece of software. They mean the general ledger, the subledgers for every product line (deposits, loans, cards, FX), and the batch process that reconciles all of them overnight.

That batch process is the heart of the constraint. After branches close, the core system runs end-of-day processing. It gathers the day's transactions, applies sweep rules to move money between accounts automatically, and calculates interest based on closing balances.

Then it reconciles every subledger against the general ledger, generates regulatory reports, loads the data warehouse, and produces statements. The whole sequence runs overnight. Results appear in customer accounts between 4 and 7am.

If this process fails, the bank cannot fully open the next morning.

A single corrupt timestamp in one transaction record can poison the entire batch job. When EOD fails at 2am, a team of engineers works until dawn to fix it, because the ATMs, the mobile app, and the branch tellers all depend on the batch having completed.

Transactions accumulateEOD batch processingAccounts updated

8am

5pm

10pm

12am

4am

7am

if batch fails → bank can't open

Why batch made sense

In the 1970s, mainframe processing capacity was expensive and peaked during business hours. Branches closed at 5pm. The overnight window was effectively free compute.

A restaurant that takes orders all evening but cooks everything at midnight. The kitchen is cheaper to run in one burst. The menu is designed around ingredients that hold.

The entire operation, from how you write tickets to how you plate food, assumes batch cooking. That's core banking.

This worked for decades. ACH settles in batches. Wire transfers post in batches. Interest accrues from batch calculations. Regulatory reports generate from batch outputs.

Systems upstream and downstream of the core were built to match its rhythm.

That worked as long as the world ran on the same clock. Then it stopped. Mobile banking created the expectation that money moves instantly. Real-time payment rails like FedNow made that expectation infrastructure. Customers, regulators, and competitors all began operating 24/7 — but the core still needs its overnight window to close the books.

Why you can't just replace it

Banks try, and they keep failing.

In 2018, TSB Bank migrated 5.2 million customer accounts from one core platform to another. Within hours, customers were locked out. Some could see other customers' balances and transactions.

Fraud attacks spiked to 70 times normal levels within three weeks. The bank received 225,492 complaints over the following year. Total cost: over £300 million.

What TSB got wrong was trying to do two things at once — migrate the data and upgrade the architecture in a single cutover weekend. That much change over a single weekend was bound to cause problems.

A mid-market bank typically has 50 to 150 active third-party integrations. Many are partially or entirely undocumented. These are point-to-point connections built over decades, each one assuming the core's specific data model and batch timing. Rip out the core, and the integrations break.

Then there's the data. Banks migrate petabytes of sensitive financial records, and data migration is the leading cause of core banking project failure.

Allied Irish Banks spent three years trying to migrate to Oracle Flexcube. They moved 3,000 customers out of 5 million before abandoning the project and suing Oracle for €84 million.

94% of core banking modernization projects exceed their original timelines. The typical program runs four to five years. Commonwealth Bank of Australia's transformation, widely considered a success, took five years and cost over $1 billion.

TSB (2018)

Migrate data5.2M accounts

Upgrade architectureNew platform

one weekend

Phased

Phase 1Pilot cohort

Phase 2Expand

Phase 3Migrate

Phase 4Decommission

years, with rollback points

The real-time collision

For decades, batch processing was inconvenient but survivable. ACH took a day or two. Wire transfers were expensive but fast enough. Customers accepted that transfers weren't instant.

FedNow changed the math. Launched in July 2023, it requires 24/7/365 instant settlement. So does The Clearing House's RTP network, live since 2017.

Both require something batch-oriented core systems fundamentally lack: real-time balance verification, instant ledger posting, fraud screening in milliseconds, and availability with no maintenance window.

About 1,900 of the roughly 8,500 U.S. banks and credit unions have joined FedNow. Most are receive-only. They can accept an instant payment, but they can't send one.

Receiving an instant payment is a notification. Sending one requires your core system to confirm the balance, post the debit, and update the ledger in real time. A batch-oriented core can't do that without significant rearchitecture.

	Batch Core	FedNow / RTP
Balance check	End-of-day snapshot	Real-time query
Ledger posting	Bulk overnight	Per-transaction
Fraud screening	After the fact	Sub-second
Availability	Maintenance windows	24/7/365
Settlement	Next business day	Instant

The COBOL question

You might assume the root problem is COBOL. It runs 43% of U.S. core banking systems. It processes an estimated $3 trillion in daily commerce. 95% of ATM transactions flow through COBOL code.

COBOL works. Strict data typing reduces corruption risk. Transaction handling provides atomicity and consistency as built-in language features. For batch workloads, the performance is excellent.

But the average COBOL developer is 58 years old. An estimated 92% will retire by 2030. More than half of organizations that need COBOL expertise say finding qualified developers is their biggest challenge. Salaries have climbed sharply, with the average mainframe COBOL developer now earning over $125,000.

Banks spend an average of $65 million per year on mainframe operations, with roughly a fifth going to maintenance alone. The cost is rising. The talent pool is shrinking. Every year of deferred modernization adds another layer of undocumented integrations that make eventual migration harder.

Where the $60 billion goes

License fees to FIS, Fiserv, and Jack Henry, the three vendors that dominate the market. Mainframe operations averaging $65 million per bank per year. Maintenance labor, integration management for hundreds of third-party connections, and modernization programs that routinely exceed their budgets.

Most of that money goes toward keeping a batch-oriented system running in a world that stopped waiting for the batch to finish.