In most modern programming languages, 0.1 + 0.2 does not equal 0.3. IEEE-754 floating-point arithmetic stores values as powers of two, and some decimals simply can't be represented exactly. Close enough for physics simulations. A different matter entirely when a bank is settling millions of transactions to the penny.
COBOL doesn't have this problem. It never did. And that fact is probably the best explanation for why it's still processing 95% of ATM transactions and handling what Reuters estimated at $3 trillion in daily commerce, sixty-seven years after it was written.
In 1959, the CODASYL committee — six computer manufacturers and three government agencies working under a Department of Defense mandate — set out to build a common language for business data processing. Elegance was beside the point. As CODASYL adviser Bob Bemer observed:
"In business, there are no scientific laws and no algebra, but there are different laws for the 50 states, different fiscal years and different reporting requirements."
From IBM's COMTRAN language, they adopted the PICTURE clause. In COBOL, every numeric variable gets an explicit shape. PIC S9999V99 means a signed number with four digits before the decimal and two after. The V marks where the decimal sits. All arithmetic respects that shape exactly. A dollar seventy-eight is stored as exactly a dollar seventy-eight.
Fixed-point decimal arithmetic. Precision baked in from the start, approximation only when you asked for it. And the language was built around batch processing: sequential jobs that run through entire ledgers, settle accounts, reconcile balances overnight. The rhythm of financial computing — end-of-day cutoffs, overnight clearing runs, morning settlement reports — didn't just adopt COBOL's batch orientation. It calcified around it. The DoD mandated that no computer could be purchased unless it ran COBOL. By 1970, it was the most widely used programming language in the world.
Then there's the English. Commands like MOVE CUSTOMER-NAME TO PRINT-LINE made business logic transparent to non-programmers. That readability was a deliberate design virtue in 1962. Over the decades, the code absorbed institutional knowledge that nobody wrote down anywhere else. The COBOL source is the documentation of business rules, regulatory logic, and operational sequences that exist in no other form. Somewhere between 220 and 250 billion lines of it sit in production today.
Modern languages can do exact decimal arithmetic, though they don't do it natively. Java's primitives use floating-point; migrating financial logic without specialized libraries introduces rounding errors that violate regulatory requirements. COBOL programs weave business logic, data handling, and batch scheduling into single source files where changing one module can break another you didn't know was connected. Replicating the actual behavior, getting the same outputs for the same inputs under every edge case, is where migrations fracture.
When Commonwealth Bank of Australia replaced its core COBOL platform, it took five years and $749.9 million. Industry estimates put the overall modernization failure rate around 70%. And when ANSI proposed backward-incompatible changes in the early 1980s — the proposed COBOL-80 standard — 1,700 of 2,200 public responses were negative. Even the governing body couldn't override what was already installed.
The decimal point sits exactly where they put it. That was the whole point.
Things to follow up on...
- Floating-point breaks financial software: The EU's MiFID II regulation mandates specific rounding rules for transaction reporting, and banks have been fined millions for discrepancies caused by the same IEEE-754 precision gaps that COBOL was designed to avoid.
- AI meets the migration wall: IBM and Anthropic are both targeting COBOL modernization with agentic coding tools, but Futurum Group's analysis finds that code translation alone doesn't address the full scope of behavioral equivalence, data architecture, and transactional integrity that determines whether migrations succeed.
- Architectural debt is compounding: Gartner projects that by 2026, 80% of technical debt will be architectural rather than code-level, and organizations already spend 70–80% of IT budgets maintaining existing systems rather than building new ones.
- The mainframe skills cliff: According to the 2024 Futurum Group Global Mainframe Skills Report, 91% of organizations expect to hire mainframe developers within two years, but 62% cite a lack of modern mainframe skills as their most significant hiring barrier.

