COBOL in Banking: The Risk Clock

Part 2 framed the replace-versus-modernize decision and noted that one constraint shapes it more than any technical factor: the people who understand the core are retiring. This part looks hard at that constraint. It is the most reliable forcing function in core banking modernization — not a regulation, not a vendor end-of-life notice, but a demographic curve — and it changes the math on every path. The headline up front, because it is easy to get backwards: the problem is not COBOL. The problem is the gap between the knowledge the COBOL encodes and the people left who can read it.

COBOL is not the villain

It is worth being precise, because a lot of modernization marketing treats COBOL as a punchline. Well-written, well-maintained COBOL on a mainframe is among the most reliable software ever fielded. It is verbose by design — readable, explicit, durable. It has posted the ledger correctly through forty years of edge cases. Replacing it because it is old is the same category error as the big-bang cutover: change for its own sake, paid for in risk.

And it is still everywhere. Reuters reported in 2017 that 43% of banking systems were built on COBOL, that 80% of in-person transactions and 95% of ATM swipes relied on it, and that roughly $3 trillion in daily commerce flowed through COBOL systems (Reuters, 2017). Globally, estimates of COBOL in production 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 is wide because no one has an exact count, but both ends say the same thing: this is load-bearing infrastructure at massive scale, concentrated heavily in financial services.

So if the language is reliable and the footprint is enormous, where is the risk?

The clock: a workforce retiring on schedule

The risk is in the people. Industry figures put the average COBOL developer’s age at roughly 58, with about 10% of the COBOL workforce retiring each year (IBM, reported via Fujitsu, 2020). Read that as a clock. Every year, about a tenth of the people who can read the core walk out the door, and the pipeline replacing them is thin — COBOL is rarely taught, rarely chosen by new graduates, and increasingly maintained by a shrinking pool of contractors at rising rates.

That clock matters for one specific reason: the retiring developers are often the only complete copy of the specification. The COBOL says what the system does; the engineer who has maintained it for twenty years knows why — why that account type is handled specially, why the interest calc rounds the way it does, which downstream batch job will break if a field changes. That knowledge was never written down. When the person leaves, it is gone, and the only way to recover it is the expensive way: by breaking it in production and reconstructing it from the wreckage.

This is the tribal knowledge problem in its highest-stakes form. In most software it is a productivity drag. In core banking it is a migration risk multiplier, because any rebuild that cannot reproduce the undocumented rules will produce wrong balances — and wrong balances are a regulatory event, not a bug.

Why the clock makes big-bang worse and waiting expensive

The talent cliff sharpens both conclusions from earlier parts.

It makes the big-bang rewrite even more dangerous, because a big-bang depends on having reconstructed all the undocumented behavior before the single cutover — exactly the knowledge that is leaving. A program that bets a one-shot switch on the completeness of a specification reverse-engineered from code, while the people who could check it retire mid-program, is stacking two of the worst risks in the field on top of each other.

It also makes waiting genuinely expensive, in a way that is rare among “act now” arguments because here the mechanism is concrete and local. This is not “modernize because the market is growing.” It is: if the two people who understand this workload retire in three years, the cost and risk of migrating it goes up materially the day they leave. The cost of delay is not abstract; it is the price of recovering knowledge that used to be free to ask for.

Capturing the knowledge before it walks out

The defensible response to the clock is not to panic-replace the core. It is to capture what the experts know, from the code, while they are still here to confirm it. That is the first move in any progressive modernization, and it is where AI-accelerated discovery earns its place:

• Deep-read the system as a whole. The COBOL, copybooks, batch JCL, and database schema are analyzed together to reconstruct the call graph, the batch dependencies, the data flows, and — critically — the edge cases and special handling buried in the logic.
• Write it down as living specifications the team owns: not a one-time document that drifts, but specs maintained alongside the code, so the knowledge stops being tribal.
• Confirm with the people who still know. The retiring experts review the reconstructed behavior while they are still on staff — turning their tacit knowledge into reviewed, durable specs instead of an exit interview.
• Then modernize on evidence. With behavior captured and confirmed, each slice can be rebuilt and parity-validated against the running core, so the undocumented rules are preserved by construction rather than rediscovered by failure.

The honest framing of AI’s role, consistent across this series: it is how we make discovery fast and thorough enough to beat the retirement clock — an analysis-time gain that compresses months of manual archaeology into weeks. It does not make the cutover safe, and it does not replace the senior engineers who own the architecture and the parity gates. It buys time against the clock; it does not stop it.

Understanding the core isn’t the same as replacing it

Capturing knowledge is valuable even if you never modernize a line — a core whose behavior is documented and owned is less risky to run, easier to audit, and cheaper to staff than one that lives in three people’s heads. So the talent clock argues first for discovery, and only then, where the pressures justify it, for migration. A stable workload whose behavior you have captured and whose handful of maintainers are not imminently leaving may be fine to keep running. The clock raises the urgency of understanding the core; it does not, by itself, mandate replacing it. The worst position is the common one: a critical workload nobody fully understands, maintained by people about to retire, with no capture in progress. That is the situation this part exists to flag.

Where this leads

The talent cliff is one of two forcing functions pressing on the core. The other comes from outside the building: examiners, auditors, and regulators whose expectations a legacy core increasingly struggles to meet. Crucially, those regulations rarely order modernization — they mandate outcomes like security, resilience, and auditability, and leave the means to you. Part 4, Banking Modernization & Regulatory Compliance, maps the real regulatory landscape — FFIEC and OCC, GLBA, NYDFS Part 500 — and is honest about exactly what it does and does not require of your systems.