The 60-Year-Old Code Still Running Your Bank Account

Somewhere between your direct deposit hitting and your mortgage payment clearing, a program written before the moon landing ran without error. Again.

COBOL—Common Business-Oriented Language—processes roughly $3 trillion in financial transactions every single day. It underpins unemployment systems, motor vehicle records, and Social Security payments across the United States. By the year 2000, 80% of all code ever written was in COBOL. And almost nobody knows how to change it safely.

The Pandemic Cracked the Foundation Open

In the spring of 2020, New Jersey Governor Phil Murphy made a confession that stunned the tech world: his state had run out of COBOL developers. Unemployment claims were flooding in by the hundreds of thousands. The systems that processed them were decades old. The people who built them had long since retired. And no one left on the payroll knew how to update them.

New Jersey wasn't alone. Dozens of states found themselves in the same bind. One rough estimate put COBOL's inefficiencies at a cost of $105 billion to US GDP in 2020 alone—not from a cyberattack or a market crash, but simply from the friction of running ancient software under modern pressure.

New Jersey eventually rebuilt its unemployment system. The user interface got cleaner. The experience improved. But the backend? Still a mainframe. Still COBOL.

The language was first proposed in 1959 by a committee that included computing pioneer Grace Hopper. The problem they were solving was real: programs were written for specific machines, and moving them to a different machine meant rewriting everything from scratch. COBOL was designed to be machine-independent and, crucially, readable—written in plain English so that non-programmers could theoretically use it. The Department of Defense backed the project, and since no defense contractor wanted to miss out on Cold War procurement dollars, COBOL compilers spread fast. Two goals achieved: machine independence and rapid proliferation.

When 'Easy to Read' Became Impossible to Untangle

The promise of readability didn't survive contact with scale. Java allows 68 reserved words. COBOL allows hundreds—including everyday words like "is," "then," and "to." Some of its original designers hoped it would eventually replace programmers altogether. What it actually produced, in large enough programs, was something developers call spaghetti code.

Sponsored

Advertise with Us

[email protected]

Sponsored

The culprit was the GO TO statement—an unconditional jump that could hurl execution from one section of a program to any other, without warning or structure. Follow the logic of a 50,000-line COBOL program and you're not reading prose; you're navigating a maze with no map.

Computer scientist Edsger Dijkstra was characteristically blunt: "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." Original designer Jean Sammet pushed back, arguing the language was simply tasked with representing genuinely complex things—payroll, social security, tax law. Mathematician Fred Gruenberger split the difference: "COBOL, in the hands of a master, is a beautiful tool. COBOL, as it's going to be handled by a low-grade clerk somewhere, will be a miserable mess."

There was also a structural flaw baked in from the start. Sammet later admitted the early design lacked "parameterization"—modules couldn't pass data directly to each other, so they had to share everything. Touch one part of the program, and you might inadvertently break another. Millions of dollars could vanish. Social Security payments could stop. The interdependencies were invisible until they weren't.

Can AI Do What Humans Couldn't?

IBM and others are now selling generative AI-powered COBOL conversion tools. The pitch is familiar: automated, fast, anyone-can-do-it efficiency. Earlier this year, DOGE publicly floated the idea of using one such tool to rewrite the entire Social Security Administration's codebase in a matter of months. That effort has since stalled.

The reason isn't surprising to anyone who's tried it. Simply converting COBOL to Java produces what developers have taken to calling "JOBOL"—a hybrid that mimics COBOL's structure in Java syntax, inheriting the worst of both. The logic is preserved on the surface; the meaning is lost underneath.

The deeper problem is epistemological. The COBOL code running today isn't just code—it's decades of institutional knowledge, edge cases, regulatory exceptions, and business rules encoded in a language that almost no one under 50 can read fluently. Converting the syntax doesn't transfer the understanding. And the people who had that understanding are, in many cases, no longer available to ask.

The financial sector faces this acutely. Banks have been running "modernization" programs for years, spending billions to migrate off mainframes. Some have succeeded. Many have produced exactly the JOBOL problem at enterprise scale—modern interfaces sitting on top of logic structures that haven't fundamentally changed since the Nixon administration.

Three Ways to Read This Problem

For technologists, the COBOL crisis is a cautionary tale about the cost of technical debt deferred. Every year a legacy system isn't replaced is a year of compounding risk—fewer developers who understand it, more downstream systems dependent on it, higher cost to eventually migrate.

For policymakers and regulators, it raises a harder question: who is responsible for the infrastructure risk? The states that still run COBOL unemployment systems didn't choose this situation maliciously. They inherited it, couldn't afford to replace it, and are now trapped. When a system failure disrupts Social Security payments or freezes unemployment claims during a recession, the political fallout lands on officials who had nothing to do with the original design decisions made in 1965.

For investors and finance professionals, the risk is largely invisible—until it isn't. Legacy system failures don't show up on balance sheets as liabilities. They appear suddenly, as outages, as regulatory fines, as reputational damage. The institutions most exposed are often the ones that have been "stable" the longest, because stability sometimes just means nothing has broken yet.