Why Banks Still Use COBOL: The $3 Trillion Code That Runs Global Finance

Every day, an invisible layer of code processes roughly $3 trillion in financial transactions around the world. It moves money between accounts, authorizes credit card purchases, settles interbank transfers, and keeps the global economy running without interruption. That code is not written in Python, Java, or any language that dominates today's computer science curricula. It is written in COBOL, a programming language that first appeared in 1959. Understanding why the world's largest financial institutions continue to depend on COBOL is essential for anyone working in technology, finance, or both. The reasons go far deeper than institutional inertia, and they reveal uncomfortable truths about how difficult it really is to replace software that works.

The Staggering Scale of COBOL in Global Finance

Before examining why banks have not moved away from COBOL, it is worth understanding the sheer magnitude of what COBOL handles. The numbers are not trivial. They represent the backbone of modern commerce.

An estimated 220 billion lines of COBOL code are in active production worldwide. To put that figure in perspective, if you printed those lines on paper and stacked the pages, the pile would stretch well beyond the orbit of the International Space Station. The overwhelming majority of that code lives inside financial institutions.

Here is what COBOL processes in the banking sector:

These are not dusty programs running on forgotten machines in the corner of a data center. They are high-performance applications executing on modern IBM Z mainframes, processing thousands of transactions per second with uptimes measured in decades rather than days. The Federal Reserve's payment systems, the core banking platforms of JPMorgan Chase, Bank of America, Citibank, Wells Fargo, and virtually every major financial institution you can name, all depend on COBOL code that has been continuously refined and hardened over 40 to 60 years.

Why Banks Do Not Migrate: It Is Not Stubbornness

The obvious question from anyone outside the industry is straightforward: why not just rewrite it all in a modern language? This question assumes that rewriting is a viable option and that the only barrier is willingness. Both assumptions are wrong.

The risk is existential. When a social media platform goes down for a few hours, people are annoyed. When a core banking system fails, people cannot access their money, payroll does not process, mortgages do not close, and markets can seize. The consequences of a failed migration at a major bank are measured not in lost engagement metrics but in regulatory penalties, class-action lawsuits, and genuine economic harm to millions of people. Banks operate under a simple calculus: a system that works reliably is always preferable to a system that might work better but carries the risk of catastrophic failure during the transition.

The cost is extraordinary. Replacing a core banking platform is not a typical software project. It is one of the most expensive and complex undertakings any organization can attempt. Estimates for full core banking replacement at a major institution start at $500 million and routinely exceed $1 billion. These projects require years of parallel running, where both the old system and the new system process the same transactions so results can be compared, followed by a carefully orchestrated cutover. The total cost of ownership during a transition, including the parallel infrastructure, expanded testing teams, regulatory review, and inevitable delays, frequently doubles the initial estimate.

The code is battle-tested. Fifty years of production use means fifty years of bug fixes, edge case handling, and refinement. Every scenario that can occur in banking, from leap-year calculations to currency redenominations to obscure regulatory requirements from the 1970s that still technically apply, has been encountered and addressed. Rewriting that code means rediscovering and re-solving every one of those problems. The business logic embedded in a large bank's COBOL codebase represents an institutional knowledge base that often exceeds what any living employee fully understands.

The documentation is the code itself. COBOL was designed to be readable by business people, not just programmers. Its verbose, English-like syntax means that the code serves as its own documentation in many cases. A COBOL paragraph that reads MULTIPLY HOURLY-RATE BY HOURS-WORKED GIVING GROSS-PAY is immediately understandable. That same logic in a modern language might be gp = hr * hw, which tells you nothing about what the program is actually doing without external documentation that may or may not exist.

Failed Modernization Attempts: Cautionary Tales

The history of COBOL migration in banking is filled with projects that went badly wrong. Two cases in particular illustrate why banks are cautious.

Commonwealth Bank of Australia embarked on one of the most ambitious core banking replacements ever attempted. The project, which aimed to replace the bank's COBOL-based core with a modern platform from SAP, took over five years and cost more than $1 billion AUD. While the project was ultimately completed and is generally considered a success, the timeline and cost far exceeded initial projections. The bank's CEO at the time described it as the most complex project the organization had ever undertaken. Few banks have the appetite to follow this path, and Commonwealth Bank had advantages that many institutions lack, including strong executive sponsorship, deep pockets, and a willingness to accept years of disruption.

TSB Bank in the United Kingdom provides a starker warning. In April 2018, TSB attempted to migrate 5.4 million customer accounts from a legacy system to a new platform over a single weekend. The migration went catastrophically wrong. Customers were locked out of their accounts. Some could see other people's account balances. The bank's online and mobile banking services were disrupted for weeks, not hours. The incident resulted in nearly $400 million in direct costs, the resignation of the CEO, a damning report from regulators, and the loss of approximately 80,000 customers who left the bank entirely. TSB's experience is cited repeatedly throughout the banking industry as evidence that migration carries unacceptable risks.

These are not isolated examples. The U.S. Air Force spent over $1 billion attempting to replace a COBOL-based logistics system before canceling the project entirely. The state of California spent years and hundreds of millions of dollars on a failed attempt to modernize its COBOL-based payroll system. The pattern repeats across industries: COBOL replacement projects fail at a rate that would be considered alarming for any other category of technology initiative.

COBOL's Design Strengths for Financial Transaction Processing

Banks continue to use COBOL not just because replacing it is hard but because COBOL is genuinely well-suited for what banks need software to do. Several design characteristics make COBOL particularly strong for financial applications.

Decimal arithmetic and fixed-point precision. This is perhaps the single most important technical reason COBOL persists in finance. Most modern programming languages use floating-point arithmetic by default, which introduces tiny rounding errors that are mathematically insignificant but financially unacceptable. The classic example: in floating-point, 0.1 + 0.2 does not equal 0.3. It equals something like 0.30000000000000004. When you are processing millions of transactions, those tiny errors compound into real discrepancies. COBOL was designed from the ground up to handle decimal arithmetic with exact precision. Its PICTURE clause lets programmers define exactly how many digits a number has, where the decimal point falls, and how rounding should work. Financial calculations in COBOL produce results that are correct to the penny, every time, without special libraries or workarounds.

Record-oriented data processing. Banking is fundamentally about processing records: account records, transaction records, customer records, regulatory records. COBOL's data division lets programmers define hierarchical record structures with extraordinary precision, specifying the exact layout of every field down to the byte. This maps naturally to how financial data is organized and how mainframe databases store information.

ACID transaction support. COBOL programs running on mainframes under transaction processing monitors like CICS (Customer Information Control System) provide the atomicity, consistency, isolation, and durability guarantees that financial transactions demand. A COBOL/CICS transaction either completes fully or rolls back entirely. There is no intermediate state where money has left one account but not yet arrived in another. This transactional integrity is built into the infrastructure, not bolted on as an afterthought.

Batch processing efficiency. Banks process enormous volumes of transactions in overnight batch runs: clearing checks, calculating interest, generating statements, processing loan payments, and running regulatory reports. COBOL excels at sequential file processing at massive scale. A well-written COBOL batch program can process hundreds of millions of records in hours, reading through sequential files with an efficiency that object-oriented languages struggle to match for this specific workload pattern.

Stability and backward compatibility. COBOL programs written in the 1970s can still compile and run on modern mainframes with minimal or no modification. The language has evolved through multiple standards, from COBOL-68 through COBOL-85 to the COBOL 2023 standard, but each revision has maintained backward compatibility. This stability is a feature, not a limitation. Banks do not want a language where code breaks because of a runtime update.

Regulatory and Compliance Considerations

Banking is one of the most heavily regulated industries in the world, and regulatory requirements create additional pressure to keep existing systems running.

Audit trails and regulatory history. Regulators require banks to maintain detailed records of how transactions are processed. COBOL systems that have been in production for decades have well-established audit trails and regulatory compliance records. Migrating to a new system means re-establishing those compliance frameworks, which requires extensive testing and regulator approval.

Change management requirements. Banking regulators, including the Office of the Comptroller of the Currency (OCC) in the United States, the Prudential Regulation Authority (PRA) in the United Kingdom, and the European Central Bank (ECB) in Europe, all scrutinize major technology changes at banks. A core system migration is classified as a material change that triggers enhanced regulatory oversight. Banks must demonstrate to regulators that the new system will handle every scenario the old system handles, which requires exhaustive parallel testing.

Operational resilience mandates. Recent regulatory frameworks, including the EU's Digital Operational Resilience Act (DORA) and similar frameworks in other jurisdictions, require banks to demonstrate that their critical systems can withstand disruption. Paradoxically, this makes migration harder, not easier. A bank running a proven COBOL system can point to decades of uptime. A bank proposing to replace that system must convince regulators that the replacement will be equally resilient, which is difficult to prove in advance.

Data sovereignty and localization. Some regulatory frameworks require that transaction processing occur within specific jurisdictions. Mainframe-based COBOL systems that run in on-premises data centers naturally satisfy these requirements. Cloud-based replacements may introduce complexity around data residency that banks and regulators are still working to resolve.

What Real Modernization Looks Like

Despite the challenges, banks are not simply ignoring their COBOL systems and hoping for the best. Modernization is happening, but it looks very different from what most people imagine.

  1. API wrapping. The most common modernization approach is placing modern API layers on top of existing COBOL programs. A COBOL program that processes a loan application can be exposed as a RESTful API that a mobile banking app calls. The COBOL code continues to handle the business logic, but the interface is modern. This approach preserves the tested, reliable back end while enabling modern user experiences.

  2. Microservices integration. Banks are increasingly building new functionality as microservices that interact with COBOL systems through message queues and APIs. New customer onboarding flows, fraud detection algorithms, and real-time notification systems can be built in modern languages while the core transaction processing remains in COBOL.

  3. Gradual, module-by-module migration. Rather than attempting a big-bang replacement, some banks are migrating individual modules over years or even decades. A bank might move its customer relationship management functions to a modern platform while keeping core accounting and transaction processing in COBOL. This approach limits risk but extends the timeline significantly.

  4. COBOL modernization in place. Many banks are modernizing their COBOL code itself rather than replacing it. This includes refactoring legacy code to use structured programming techniques, adopting the COBOL 2023 standard's support for JSON and XML, and implementing modern DevOps practices like continuous integration and automated testing for COBOL codebases.

  5. Cloud-enabled mainframes. IBM and other vendors have made it possible to run mainframe workloads in cloud environments, including IBM's Wazi as a Service. This lets banks maintain their COBOL applications while benefiting from cloud infrastructure for scalability and disaster recovery.

  6. AI-assisted code understanding. Banks are using AI tools to analyze and document large COBOL codebases, creating comprehensible documentation from millions of lines of code. This does not replace the code, but it makes maintaining and gradually modernizing it far more feasible.

The Workforce Challenge That Keeps CIOs Awake

The most pressing concern for banks is not whether COBOL is up to the job. It is whether there will be enough people who know how to work with it. The average age of a COBOL programmer is now well above 55, and retirements are accelerating. Banks are responding with several strategies.

Some institutions have created internal training programs to teach COBOL to younger developers. Others are partnering with universities and coding bootcamps to reintroduce COBOL into curricula. Several major banks have established mentorship programs that pair retiring COBOL developers with junior programmers to transfer institutional knowledge.

The shortage has also driven salaries upward. Experienced COBOL developers in the financial sector routinely earn $120,000 to $160,000 or more, with contract rates for specialized mainframe work reaching $150 to $200 per hour. For professionals willing to learn COBOL and mainframe technologies, the compensation and job security are difficult to match in other areas of software development.

The Bottom Line: COBOL Is Not Going Anywhere

The question is not whether banks will still use COBOL in five or ten years. They will. The question is how they will integrate their COBOL systems with the modern technologies their customers and regulators demand. That integration work represents one of the most significant and well-compensated areas of technology employment in the financial sector.

COBOL persists in banking not because bankers are technologically unsophisticated or resistant to change. It persists because it works extraordinarily well for its intended purpose, because replacing it is genuinely dangerous and expensive, and because the alternatives have not demonstrated clear superiority for high-volume, precision-critical financial transaction processing.

For anyone interested in a career at the intersection of technology and finance, or for experienced developers looking for a niche with strong demand and limited competition, COBOL expertise is a strategic asset. The $3 trillion that flows through COBOL systems every day is not moving to a different language anytime soon, and the organizations that depend on those systems need people who can keep them running, evolving, and connecting to the modern world.

Ready to learn COBOL? Read our free Learning COBOL Programming textbook — from Hello World to production-ready programs.