COBOL in Healthcare Payments

Behind the interface mesh of Part 2, on the payer side, sits the code that actually moves the money. For a great many payers, that code is COBOL, running on a mainframe, and it has been doing its job — adjudicating claims, applying benefit rules, cutting payments — for longer than some of the people maintaining it have been alive. It is easy to treat that as an embarrassment to be hidden. It is more useful to understand why it is there, why it is genuinely hard to replace, and why the clock on replacing it is running faster than it looks.

Why payments ended up on COBOL — and why that was reasonable

COBOL on the mainframe was not a mistake anyone is stuck with by accident. It was the correct engineering choice for the problem, and in many ways it still performs that problem well. The platform was built for high-volume, reliable, transactional and batch processing of financial records — exactly the shape of claims adjudication and payment. Overnight runs process enormous volumes; the arithmetic is exact in ways that matter when you are paying claims to the cent; the systems have demonstrated decades of uptime.

So payers built there, and then did the rational thing: they left a system alone that was working. The result is that a large fraction of healthcare’s payment infrastructure is COBOL, and the scale is not small. Estimates of COBOL in production worldwide range from roughly 220 billion lines (Reuters, reported 2017, via IEEE Spectrum) to upper-bound figures above 800 billion (Micro Focus, by 2022). The range itself is the honest answer — no one has an exact count — but both ends say the same thing: this is load-bearing infrastructure, not a curiosity. COBOL is not going away on its own, and waiting for it to is not a strategy.

The real risk is the workforce, not the language

The mistake is to frame the COBOL problem as “the technology is bad.” It mostly isn’t. The problem is that the systems’ behavior — thousands of accreted adjudication and pricing rules — lives in code that fewer and fewer people can read, and the people who can are leaving.

The figure that makes this concrete: the average COBOL developer is roughly 58 years old, with about 10% of the COBOL workforce retiring each year (IBM, reported via Fujitsu, 2020). Read that as a clock. Every year, roughly a tenth of the people who hold the undocumented rules of these payment systems walk out the door, and the pipeline of replacements fluent in the stack is thin. The knowledge and the people are leaving on the same schedule.

This is why a COBOL payment system that is performing perfectly can still be urgent. The risk is not that it will fail tomorrow; it is that the window to capture why it does what it does — from the people who know — is closing on a human timetable you do not control. When the last engineer who understands the credit-balance logic retires, that logic becomes behavior you must rediscover by archaeology rather than knowledge you can simply ask for. The most time-sensitive part of modernizing a COBOL payment engine is capturing its rules while there is still someone to validate them.

Why a big-bang rewrite of a payment engine is the worst case

Payments concentrate every reason big-bang fails, because the cost of being wrong is measured directly in money and in regulatory exposure.

A claims engine encodes a vast number of rules, most of them undocumented, many of them edge cases that fire on a small fraction of claims and matter enormously when they do — coordination of benefits, unusual provider arrangements, retroactive eligibility, partial payments. A from-scratch rewrite cut over on a date has to reproduce all of those rules correctly, simultaneously, and the only way it discovers the ones it got wrong is by paying claims incorrectly in production. Underpayments generate provider abrasion and appeals; overpayments generate recovery work and leakage; either can become a compliance problem. There is no clean rollback once a payment run has executed against the new system. You have bet the payment integrity of the whole book on a single moment.

This is not a hypothetical caution. The base rate for large all-at-once change is failure — Boston Consulting Group reported that up to 70% of digital transformations fail to deliver on their objectives (September 2023) — and a high-stakes COBOL payment rewrite is the archetype.

Modernizing the payment engine slice by slice

The alternative applies the same method as the rest of the series, sharpened for the stakes of money.

Recover the rules first. Before rebuilding anything, the adjudication and payment logic is recovered from the code itself and captured explicitly — as readable, reviewable specifications of what the system actually does. Where the engineers who know the why are still available, that intent is captured alongside the what, because the code tells you a strategic-flagged claim bypasses a check but never whether that is deliberate policy or a forgotten 2015 hack. This is the tribal knowledge problem at its most expensive, and it is why capture races the retirement clock.

Rebuild one slice at a time, behind a boundary. A slice of the engine — a category of claim, a pricing module, a benefit type — is rebuilt in modern code, reading from and writing to the legacy system through an anti-corruption layer so the surrounding mainframe processing keeps working unchanged.

Prove it pays identically before it goes live. This is the non-negotiable part for payments. A rebuilt slice is validated by running real historical claims through both the legacy engine and the new one and reconciling the results to the cent — the discipline of proving functional equivalence and reconciling outputs. Only claims where the new slice produces an identical payment, across the full distribution of real claim types including the rare ones, earn the slice its place in production. A penny of unexplained divergence is a finding, not a rounding tolerance.

Keep each slice reversible. Behind the routing layer, any slice can be returned to the legacy path on its own if something surfaces, without affecting the rest of the payment run. The risk is contained to one slice at a time rather than concentrated in one date.

What you can’t recover, and what to do about it

A caution on scope. Recovering the what a system does from its code is a tractable, well-understood activity; recovering the why is bounded entirely by who is still there to tell you. Where the people are gone, you have two honest options — preserve the behavior exactly because you cannot justify changing what you do not understand, or prove through analysis that a rule is genuinely unreachable before retiring it. What you must not do is guess at intent and act on the guess in a system that pays claims. Modernization does not give you license to “clean up” payment rules you do not fully understand; it gives you a safe way to carry them forward and a documented basis for changing them deliberately later.

Where this leads

This part has looked at the payment engine as code. But claims processing is also a workflow — intake, eligibility, adjudication, payment, appeals — and modernizing it well means treating it as a sequence of stages that can be modernized independently, not just a body of COBOL to translate. Part 4, Claims Processing Modernization, takes that view: how to slice the claims lifecycle, where to start, and how parity validation keeps the whole pipeline paying correctly while you rebuild it stage by stage.