Skip to content

COBOL: The Language That Runs Banking

Abstract

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 Pentagon convened the Conference on Data Systems Languages (CODASYL) in May 1959 to design a common business language, and once the specification existed the Department of Defense supplied the enforcement: it would not buy or lease a computer that could not run COBOL. For manufacturers, the largest customer in computing had made support non-optional. 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:

  • 775 to 850 billion lines of COBOL in daily production use, per an independent survey commissioned by Micro Focus in February 2022, three times the roughly 220 billion estimated in 2017
  • $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 standard added an optional commit-and-rollback facility (COMMIT and ROLLBACK statements), dynamic-length item handling via SET, alternate-key suppression on indexed files, and a nonfatal I/O warning condition, building on the Unicode support and object-oriented features introduced back in COBOL 2002. COBOL is being extended rather than replaced.

Myth: COBOL is a dead language.

Old is not dead. A 2022 industry survey put 775 to 850 billion lines of COBOL in active production (more than any other language) processing trillions of dollars in transactions daily and running the core systems of most major banks, insurers, and government agencies. COBOL has been declared obsolete roughly once per decade since 1970 and keeps running; the standard is still being revised (2023). The real risk is not the language dying but the workforce that maintains it retiring faster than it is replaced, which is the opposite of a dead language. See Myths and Misconceptions.

The workforce pipeline is the more serious concern. In April 2020, IBM and the Linux Foundation’s Open Mainframe Project responded to the unemployment-claims crunch with a COBOL talent portal, a technical forum staffed by experienced programmers, and a free training course. IBM’s academic initiative works with roughly 120 universities, about half of which teach COBOL. 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.

📚 Sources