The strange thing about COBOL is not simply that it still exists. Old technologies survive everywhere. The stranger fact is where it survives: inside the systems that move money, clear payments, maintain accounts, process card activity, support public benefits, and quietly keep parts of the administrative world running.
COBOL, short for Common Business-Oriented Language, began in 1959 and first appeared in its early standard form around 1960. Depending on where you start counting, it is now in its mid-sixties. That detail has become a kind of shorthand in recent coverage: a programming language old enough to collect a pension still sits beneath some of the most sensitive financial workflows in the world.
The $3 trillion-a-day figure attached to COBOL comes from industry reporting rather than an audited live counter. In 2017, Reuters reported, in a piece later preserved by Wired, that an estimated $3 trillion in daily commerce flowed through COBOL systems in the financial industry. A 2026 Wired essay used similar language, describing COBOL as handling something on that order in financial transactions on any given day. The exact number should be read as an estimate. The structural point is harder to dismiss: this old language remains buried inside systems that cannot simply be switched off.
The old code is not ornamental
COBOL has an image problem. To many younger developers, it looks verbose, dated and distant from the tools that define modern software work. Its syntax reads almost like formal business prose. Its runtime world often involves mainframes, batch jobs, fixed records, job control, old databases, and decades of local conventions that rarely appear in glossy engineering blogs.
But the language was not an accident. It was designed for business data processing at a time when computers were expensive, incompatible and hard to program. Companies needed a common language for payroll, ledgers, accounts, inventory and government records. COBOL was built for that administrative world: decimal arithmetic, readable statements, structured records, and long-running reliability over elegance.
That design goal explains its persistence. Banks do not keep COBOL because they are sentimental. They keep it because the systems around it work, because they have been amended across decades, and because the business logic inside them is not always cleanly documented anywhere else. The source code may not only be implementation. In many organisations, it is the record of how the institution actually does business.
Replacing that is not the same as swapping one library for another. A banking system can contain layers of rules about interest, fees, exceptions, settlement windows, compliance checks, historical product quirks, edge cases from mergers, and customer records that have accumulated over many years. Some of that logic may be understood by current teams. Some may live only in the code and in the memories of people who are no longer on staff.
The real shortage is institutional memory
The public version of the COBOL problem often sounds like a simple labour-market story: old programmers retire, young programmers do not know the language, so rates rise. That is part of it, but it is not the whole picture.
A 2021 paper, Contemporary COBOL: Developers’ Perspectives on Defects and Defect Location, put the issue plainly. The authors wrote that mainframe systems face a critical shortage of developer workforce as current COBOL developers retire, while entry-level developers taking over legacy systems face difficulties because public COBOL resources are limited. The paper surveyed COBOL and modern-language developers to compare defect categories and defect-location strategies, and its framing captures the practical problem: this is not just about syntax. It is about understanding old systems well enough to change them without breaking them.
That is why the phrase “younger coders” can be misleading. Banks do need newer generations to learn these systems. But the people who become valuable are not valuable because they can type COBOL keywords. They are valuable because they can read a decades-old transaction path, infer why it exists, test a change safely, and know when a apparently ugly piece of code is ugly for a reason.
The Reuters report quoted in Wired noted that experienced COBOL programmers could earn more than $100 an hour when called in to patch glitches, rewrite coding manuals, or make newer systems work with older ones. That is a decent fee, but the more important point is the asymmetry. The cost of paying a specialist looks small next to the risk of damaging a payments system, delaying account processing, or producing errors in regulated financial records.
Why banks do not simply rewrite it
The obvious question is why banks have not already moved away. The short answer is that many have tried, many are still trying, and almost none can treat it as a clean rewrite.
Legacy modernisation is difficult because the old system is usually connected to everything else. A bank’s core system may feed mobile apps, branches, ATMs, payment networks, fraud systems, reporting platforms, regulatory processes, data warehouses, and customer-service tools. Changing the core means changing the behaviour that all those other systems expect.
There is also the problem of equivalence. A new system cannot merely be better in a general sense. It must produce the same answers where the old answers are legally, financially or operationally required. It must handle the same historical records. It must preserve audit trails. It must survive peak loads. It must pass internal controls and external scrutiny. It must fail safely. For a bank, “mostly right” is not a technology strategy.
This is why many organisations wrap old COBOL systems with newer interfaces rather than removing them outright. The mobile app may look modern, the data pipeline may be newer, and the customer experience may change, while a core transaction still passes through code written for another computing era. From the outside, the service appears contemporary. Underneath, the settlement logic may still run on a mainframe.
That layered reality is easy to mock until one considers the alternatives. A full replacement can take years, cost huge sums, and introduce its own failures. In financial systems, the legacy code is not just technical debt. It is also proven behaviour under pressure. The problem is that proven behaviour becomes harder to maintain when the people who understand it leave.
AI is now part of the argument
In 2026, COBOL returned to wider tech discussion because AI coding tools began to be pitched as a way to analyse and modernise old systems. Anthropic’s claims about Claude Code drew market attention, partly because investors wondered whether code analysis could reduce the consulting labour historically required for COBOL projects. IBM pushed back against the idea that modernisation is simply code translation. Reporting by ITPro summarised IBM’s position: decades of hardware and software integration cannot be replicated just by moving code.
That is a useful caution. AI tools may help map dependencies, generate documentation, suggest tests, and explain old code to newer engineers. Those are real needs. But COBOL modernisation has a correctness problem, not merely a translation problem. The output must preserve business meaning, data behaviour and operational guarantees. A tool that can summarise a program is not automatically a tool that can safely replace a payments system.
Recent research reflects this tension. Papers on COBOL code generation and translation show progress, but also limits. The field is active because the maintenance problem is real. The careful conclusion is not that AI will make COBOL disappear, nor that it is useless. It is that old enterprise systems are becoming another test of whether AI can help humans understand complex software without pretending that understanding is the same as replacing it.
The quiet economics of old software
The COBOL story is often told as a joke about ancient code. It is better read as a lesson in infrastructure. Software that handles money does not age like consumer apps. It becomes embedded in processes, contracts, controls, habits and organisational memory. The longer it works, the more people build around it. The more people build around it, the harder it becomes to remove.
That is why a 65-year-old language can still command attention from banks, consultants, AI companies and investors. The value is not in COBOL as a fashionable skill. It is in the risk surrounding the systems written in it. When a bank pays for COBOL expertise, it is often buying continuity: the ability to keep old code working while the institution decides what, if anything, can safely replace it.
For younger developers, that creates a peculiar opportunity. The glamour is elsewhere, but the bargaining power may be here. Learning COBOL is not just learning an old language. It is learning to work inside systems where errors are expensive, documentation may be incomplete, and technical choices are inseparable from business history.
The irony is sharp. A language designed for ordinary business data processing has become one of the clearest reminders that software is never just software. It is memory, process, risk and power, stored in code that keeps running because too much depends on it to stop.
