COBOL: The Language That Runs Banking

Zusammenfassung

COBOL was designed in 1959 to be readable by business managers, not elegant for computer scientists. It succeeded beyond any reasonable expectation: today it processes more than $3 trillion in financial transactions daily, runs payroll for a majority of the world’s employees, and handles the core systems of most major banks, insurance companies, and government agencies. Approximately 800 billion lines of COBOL code are estimated to be in active production — more than any other programming language. COBOL has been declared obsolete roughly once per decade since 1970. It is still running.

The CODASYL Committee and the DoD Ultimatum

By 1959, the US government was operating dozens of different computer systems that ran programs written in mutually incompatible languages. Moving a program from one computer to another required complete rewriting — expensive, slow, and error-prone. The Department of Defense issued a directive: develop a common business language, or the DoD would stop buying computers from manufacturers who did not support it.

The threat convened the Conference on Data Systems Languages (CODASYL) in May 1959. The committee included manufacturers (IBM, Sperry Rand, Burroughs, Honeywell), the DoD, and users. The intellectual driving force was Grace Hopper of the Navy, whose FLOW-MATIC language had demonstrated that business programs could be written in English-like statements rather than mathematical notation. Jean Sammet, Bob Bemer, and others contributed the technical specification.

The committee produced the first COBOL specification in April 1960 — eleven months from inception. The compilers appeared by the end of 1960. The DoD mandated COBOL for its data processing systems, and banks, insurance companies, and government agencies rapidly adopted it.

Design Philosophy: English for Business

COBOL’s syntax was deliberately verbose. A COBOL program begins with an IDENTIFICATION DIVISION identifying the program, then an ENVIRONMENT DIVISION describing the computing environment, a DATA DIVISION defining all data structures, and a PROCEDURE DIVISION containing the actual logic. A statement that adds two numbers might read:

ADD CUSTOMER-BALANCE TO TOTAL-AMOUNT GIVING FINAL-TOTAL.

This verbosity was the design intent. The committee envisioned COBOL programs being reviewed by business managers and auditors who were not programmers. The program should be understandable to anyone who could read business English. Whether this goal was achieved in practice is debatable — COBOL programs do become complex in ways that require expertise to understand — but the aspiration shaped the syntax.

Decimal arithmetic was a critical technical requirement. Financial calculations require exact decimal representation: $1.00 divided by 3 should give $0.33 with specific rounding, not the floating-point approximation 0.33333… that binary arithmetic produces. COBOL’s native decimal arithmetic, implemented without floating-point, was essential for financial applications.

Record-oriented file processing matched the data of the era: punched cards, magnetic tape, and eventually disk records. A COBOL program described the layout of records, opened files, read records, processed them, and wrote output records. This model matched how financial data actually flowed through institutional systems.

Standardization and Longevity

COBOL was standardized by the American National Standards Institute (ANSI) in 1968, and the standard has been updated in 1974, 1985, 2002, 2014, and 2023. Each revision added modern capabilities while preserving backward compatibility — a COBOL program written in 1965 should still compile under a 2023 COBOL compiler, and largely does.

The commitment to backward compatibility is the source of COBOL’s longevity. Financial institutions that wrote COBOL systems in the 1960s are still running them because the cost of replacing them — reimplementing decades of accumulated business logic, edge cases, regulatory adaptations, and institutional knowledge — exceeds the cost of maintaining them. The code works. It handles the edge cases. The programmers who understand it remember what the edge cases mean.

The Scale of the Installed Base

Estimates of COBOL’s deployment scale are staggering:

800 billion lines of COBOL code in active production (IBM estimate; other estimates range from 220 billion to 1 trillion)
$3 trillion in financial transactions processed daily through COBOL systems
95% of ATM transactions touch COBOL at some point in their processing chain
The majority of payroll systems in major economies run on COBOL
The US Social Security Administration runs COBOL
Major clearing houses (SWIFT transactions, CHIPS in the US) process through COBOL systems

The workforce implication is underappreciated: the programmers who wrote the core COBOL systems in the 1960s and 1970s are in their 70s, 80s, or dead. The people who maintain these systems are younger, but there are fewer of them, and each year there are fewer. Universities stopped teaching COBOL decades ago as an entry-level language; it is now specialist knowledge acquired on the job or through employer-specific training programs.

Y2K: The Most Expensive COBOL Maintenance Event

The Year 2000 problem — the use of two-digit year fields in COBOL programs that would interpret “00” as 1900 rather than 2000 — was substantially a COBOL problem. COBOL programs, written when memory was expensive and every byte mattered, stored years as two digits. A loan system that calculated interest by subtracting the loan origination year from the payment year would produce catastrophically wrong results if both “origination year” and “payment year” could be ambiguous.

The Y2K remediation effort cost an estimated $300–600 billion globally, involved millions of programmer-years of work, and was substantially the work of finding and fixing two-digit year fields in COBOL programs. The absence of major failures on January 1, 2000 was not because the problem was overstated; it was because the remediation succeeded.

Y2K was also the most comprehensive effort ever made to understand and audit existing COBOL codebases. The knowledge gained — about what systems existed, how they were structured, and what they did — has not been retained. Much of it was learned and then lost as the temporary workforce assembled for remediation dispersed.

COVID-19: COBOL Shortage Made Visible

In April 2020, New Jersey Governor Phil Murphy held a press conference announcing that the state’s unemployment system was overwhelmed by the surge in claims following COVID-19 pandemic shutdowns. He explicitly asked the public for COBOL programmers — the state’s unemployment system ran on COBOL, and the state did not have enough people who could maintain and extend it.

New Jersey was not unusual. Most US state unemployment systems, and the federal systems that connect to them, run on COBOL. The pandemic revealed what had been a slow-developing crisis: these systems were understaffed, underdocumented, and difficult to extend because the expertise required to modify them was scarce and aging.

COBOL’s Future

COBOL compilers and tools continue to be maintained. IBM offers COBOL for the IBM Z mainframe, which runs the majority of enterprise COBOL workloads. Micro Focus (now OpenText) offers COBOL compilers and tools for distributed platforms. There are active efforts to run COBOL programs on cloud infrastructure.

The language itself is not dying — the 2023 ANSI standard added JSON support, UTF-8 support, and improvements to object-oriented COBOL features that had been added in 2002. COBOL is being extended rather than replaced.

The workforce pipeline is the more serious concern. IBM, Broadcom, and other vendors run COBOL training programs. The University of Missouri offered COBOL courses when the pandemic demonstrated the shortage. But the total number of people entering the COBOL workforce each year is small relative to the total amount of COBOL that needs to be maintained.

The most likely long-term outcome is not replacement but managed decline: as organizations migrate specific subsystems from COBOL to modern languages over decades, the total COBOL codebase shrinks gradually, the expertise required shrinks proportionally, and the transition happens incrementally rather than catastrophically. This is how legacy technology dies in financial computing — slowly, expensively, without drama.