The financial systems we trust with our money run on code older than most of their users.
When you transfer money, check your balance, or pay a bill, you’re interacting with software archaeology. Layers of modern interfaces mask systems written in COBOL, running on mainframes, maintained by engineers approaching retirement.
the invisible foundation
Banks don’t advertise it, but the core transaction systems at most major financial institutions were written in the 1960s and 1970s. These systems were built for batch processing—end-of-day reconciliation, not real-time transactions.
What this means in practice:
- “Pending” transactions exist because batch systems don’t handle real-time
- Account numbers follow patterns designed for punch cards
- Interest calculations use methods optimized for limited computing
- Weekend delays persist because systems were designed around business hours
why it persists
Replacing these systems isn’t just expensive—it’s existentially risky. Banks have tried and failed, costing billions. The systems work, they’re stable, and they handle trillions of dollars daily without drama.
The maintenance challenge:
- COBOL developers are retiring faster than new ones appear
- Documentation exists in filing cabinets, not wikis
- Testing requires understanding decades of edge cases
- Any outage makes national news
what this reveals
Legacy systems persist because they solve the hard problems—reliability, consistency, auditability. Modern startups build sleek apps, but they often connect to the same ancient infrastructure underneath.
The real insight isn’t that banks are behind—it’s that the fundamental problems of moving money reliably haven’t changed since the mainframe era. New interfaces don’t require new foundations.
