Core Banking

Everything a customer sees is a layer above it. The app, the card, the branch terminal and the online login are interfaces; the core is where an account exists, where a balance is authoritative, and where a transaction is finally recorded.

That makes it the least visible and most consequential system a bank owns. It also makes it the hardest to change, which is why many banks are still running a core written decades ago in COBOL. Not through neglect — through arithmetic. The system cannot stop, cannot lose a transaction, and cannot be replaced in stages without two ledgers disagreeing about the same account.

Why it explains so much fintech behaviour

Why banks are slow to ship features. A new product often needs the core to represent something it was not designed to represent. The app is not the constraint.

Why transfers still settle in batches. Older cores process the day’s transactions in an overnight run. Real-time payment schemes require the core to post immediately, which many cannot.

Why neobanks moved faster. Not better engineers — no legacy core. Starting on a modern platform means no thirty-year-old assumptions to work around.

Why banking-as-a-service exists. A company wanting to offer accounts can rent someone else’s core and licence rather than build both.

The replacement problem

Core migration is the largest and riskiest project a bank undertakes, measured in years and hundreds of millions, with a failure mode that is visible on the national news. Several well-known outages of recent years were migrations that went wrong.

The common compromise is to leave the old core in place and build a modern layer over it, so new products can move quickly while the ledger stays where it is. It works, and it also means the underlying constraint never actually goes away.