Quick Answer: COBOL still runs 95% of ATM transactions and 43% of banking systems because replacing it is overwhelmingly risky and expensive. Originally adopted in the 1960s for its readable, English-like syntax, COBOL became the foundation of financial business logic. Today, modern languages are simply layered on top of this legacy core.
Next time you pull cash out of an ATM, take a second to think about the software architecture making that transaction happen. I often hear engineers assume their request is hitting a modern Go microservice or a highly optimized Rust backend.
The reality is much older. That transaction is almost certainly passing through a piece of software written in a programming language from 1959.
COBOL (Common Business-Oriented Language) is over 60 years old, yet it refuses to go away. Despite decades of new frameworks and paradigms, it remains the core of global finance. Let's look at why this old language still runs the majority of our banking systems today.
Why is COBOL still used in banking systems today?
COBOL remains deeply embedded in finance because ripping it out poses a massive operational and financial risk to institutions. Over decades, banks built their core business logic on this language, meaning modern applications are typically just layered on top of a legacy COBOL foundation.
The sheer volume of legacy code is hard to wrap your head around. There are roughly 220 billion lines of COBOL still sitting in production environments right now. Over the years, instead of replacing it, banks started adding Java, Python, and other modern languages into their stack.
What happens in practice is that a mobile app request hits a modern API, which then routes through various middleware layers, until it eventually talks to the COBOL core to actually move the money. You have a situation where the core of these old systems is entirely COBOL. Touching that foundation is incredibly risky, so the industry just keeps building around it.
| Metric |
Percentage |
| ATM Transactions |
95% |
| In-Person Banking Transactions |
80% |
| Active Bank Adoption |
43% |
What made COBOL so popular for business logic in the 1960s?
COBOL was explicitly designed to read a bit like plain English. This readability allowed non-technical managers to review the code and verify it was executing the correct business rules.
In the 1960s, 70s, and 80s, bridging the gap between business requirements and technical execution was a major priority for businesses. If you were writing financial software, you wanted managers to come along, look at what you wrote, and say, "Okay, I think I understand what this thing is doing, and I can verify this is what I want it to do."
Because of this management-friendly approach, banks and massive corporations wrote nearly all of their business logic in COBOL. It solved a communication problem between the business side and the engineering side. The adoption was so widespread that by 1997, 80% of all business logic globally had been written in it.
Why is migrating away from COBOL so difficult for banks?
Migrating legacy banking systems requires translating decades of complex, undocumented business rules into modern languages without breaking a live financial network. For technical leaders, the massive cost and high risk of failure usually outweigh the benefits of modernization.
Imagine you are a bank's CTO and the board asks what project you want to prioritize next year. You could propose a complete COBOL replacement project. But realistically, migrating software that has been patched and modified for 40 years is highly likely to go wrong. If it breaks, transactions stop, regulators get involved, and you will probably lose your job. Most leaders look at that risk and decide to leave the migration for later.
When a bank actually commits to a rewrite, the undertaking is massive. For example, the Commonwealth Bank of Australia spent five years and three-quarters of a billion dollars to finally get rid of their COBOL. They did it eventually, which is a great engineering achievement. However, other institutions have tried to replace their COBOL and failed, burning millions of dollars in the process before reverting to the mainframe. It is simply very expensive and highly risky to get rid of this stuff.
Frequently Asked Questions
Can we automatically translate COBOL to Java or Python?
While there are automated transpilers and AI tools that can convert COBOL syntax into Java or Python, they generally produce code that is hard to maintain. More importantly, automated tools cannot untangle decades of undocumented business logic, which still requires engineers to manually test and verify.
Are there still developers writing new COBOL code?
Yes, though they are rare. Most modern COBOL work is strictly maintenance, bug fixing, or writing API wrappers to allow modern web applications to communicate with the legacy systems, rather than building completely new standalone COBOL applications from scratch.
What happens if a bank's COBOL system fails?
If a core COBOL system goes offline, the bank effectively stops processing transactions. ATM withdrawals halt, card transactions are declined, and inter-bank transfers queue up or fail entirely until the system is restored, which is why banks invest heavily in maintaining these environments.
