A 1959 programming language still quietly runs modern finance: COBOL handles ATMs, card networks, bank ledgers and government payments, with an estimated $3 trillion in commerce passing through it daily. Now, as the specialists who understand that old code retire, banks are paying premium rates just to keep it from breaking.

The strange thing about COBOL is not that it is old. Many things in finance are old. The strange thing is that a programming language first proposed in 1959 still sits underneath activities that feel entirely modern: tapping a card, drawing cash from an ATM, checking a balance in a banking app, receiving a benefit payment, or moving money between accounts.

That does not mean every payment in the world runs through COBOL. It does mean that a large part of the financial system still depends on code written for mainframes, batch processing and the careful movement of records. A 2026 essay in Wired described COBOL as a 1959 language that remains widely used in government and finance, handling, by one rough estimate, about $3 trillion in financial transactions on a given day.

The estimate should be read as a scale marker, not a real-time meter. The more important point is that COBOL’s position is not symbolic. It is operational. A 2017 Reuters report, excerpted by Wired‘s archive, described COBOL systems as underpinning deposit accounts, check-clearing, card networks, ATMs, mortgage servicing, loan ledgers and other financial services.

That is why the shortage of COBOL specialists is not a nostalgia problem. It is an infrastructure problem. The people who know how those systems work are retiring, and the code they leave behind is often too valuable, too entangled and too risky to replace quickly.

A language built for ledgers

COBOL stands for Common Business-Oriented Language. The name is plain because the ambition was plain. It was designed for business data processing at a time when computers were expensive, incompatible and often programmed close to the machine. The goal was a language that could express business rules in something closer to English than mathematical notation.

That readability was not an accident. COBOL was meant to be used by organisations that needed to process payrolls, inventories, insurance records, government files and bank accounts. It was designed for records and reports, not graphics or consumer apps. It was built for the slow, exacting work of moving structured information without losing a cent or a line item.

In that setting, COBOL had real strengths. Its fixed-point arithmetic suited money better than floating-point shortcuts. Its verbose syntax made business logic explicit. Its programs ran on mainframes built for high reliability, high throughput and long service lives. Once banks and governments had put critical workflows into COBOL, the language became part of the institution itself.

That is the trap and the achievement. A modern banking app may be written in Java, Kotlin, Swift, JavaScript or some other contemporary stack. But the app can still call systems whose deepest logic lives elsewhere. The surface changes quickly. The ledger underneath changes slowly because it has to be right.

Why banks did not simply replace it

From the outside, replacing COBOL can sound obvious. Translate the old code, move the data, retire the mainframe and let younger engineers work in newer languages. In practice, that framing misses what the old code contains.

Decades of banking rules are often embedded in the programs themselves. Some of those rules may be written down elsewhere. Some may exist only as code paths shaped by past products, regulatory changes, mergers, exception handling and fixes made after failures. A ledger system is not just software. It is a record of institutional memory.

Replacement is therefore not like changing a website. It is closer to replacing the foundations of a building while people are still living in it and while every room must keep its exact address. Balances must remain correct. Payments must settle. Audit trails must survive. Regulators must be satisfied. Customers must not discover the migration through missing money.

That is why many institutions have chosen wrappers, interfaces and gradual modernisation instead of total replacement. New services are built around old systems. Mobile banking talks to middleware. Middleware talks to mainframes. The old code keeps doing what it has done for decades, while the modern world keeps adding new demands on top of it.

The human bottleneck

The most fragile part of this arrangement is not always the hardware or the language. It is the people.

A 2021 study, Contemporary COBOL: Developers’ Perspectives on Defects and Defect Location, put the problem plainly: mainframe systems face a shortage of developer workforce as the current generation of COBOL developers retires. The authors also noted that entry-level developers often face difficulty because public COBOL resources are limited and the maintenance problems differ from those in modern programming-language ecosystems.

That matters because maintenance is not only syntax. A programmer can learn COBOL grammar. What is harder to learn is the shape of a bank’s 40-year-old settlement system, the reason a particular exception exists, or why one batch job must run before another on the last business day of the month.

The Reuters report captured the economics of that knowledge. Experienced COBOL programmers could command more than $100 an hour when called in to patch glitches, rewrite documentation or make new systems work with old ones. The amount sounds high until it is compared with the alternative: a failed payment system, a botched migration, or a full replacement project that takes years and still carries operational risk.

This is the quiet labour market behind modern finance. The fashionable end of technology rewards people who build the next interface. COBOL rewards people who can understand why yesterday’s interface still depends on a file layout written before many of today’s engineers were born.

Government systems have the same problem

Banks are not alone. COBOL also remains in government systems that handle tax, benefits, motor vehicle records, unemployment insurance and other payments. The pandemic made that dependence visible when some US state unemployment systems struggled under sudden demand and officials had to look for people who could work on decades-old code.

The lesson was not that COBOL suddenly failed. In many cases, the systems had kept running for years precisely because they were stable. The failure was institutional: too few people understood the systems well enough to change them quickly under stress.

That distinction matters. Calling COBOL obsolete can obscure the real issue. Obsolete things usually stop being useful. COBOL is still useful enough that organisations cannot simply walk away from it. The risk is that usefulness has outlived the training pipeline.

Can AI translate it away?

There is now a market for tools that promise to analyse, document or translate COBOL into newer languages. Some use conventional rule-based methods. Others use generative AI. These tools may help, especially with code summarisation, test generation and migration planning.

But translation is not the same as replacement. If a system is poorly understood, automatically converting it into Java or another language can preserve the structure of the old system while removing the familiarity that made it maintainable. The result may be newer code that still behaves like the old code, only now fewer people understand why.

That does not make modernisation futile. It makes it slow, expensive and evidence-driven. The serious path is usually inventory, documentation, tests, staged migration, parallel running and careful verification. The glamorous version is a switch. The real version is a long audit of institutional memory.

The old code is still load-bearing

COBOL survives because it solved a problem that never went away. Modern finance still needs exact records, repeatable processes, high-volume transaction handling and systems that can run for years. The language is no longer culturally central to programming, but it remains technically central in places where failure is expensive.

The premium paid to COBOL specialists is therefore not really payment for knowing an old language. It is payment for being able to touch old code without breaking the present. That is a rarer skill than it sounds.

The deeper story is about time. Software is often described as if it belongs to the future, but financial infrastructure is full of the past still executing. A 1959 language can sit beneath a contactless payment because the bank is not only running code. It is running history, and history is hard to refactor.