Our mainframe engineers knew the bank, not just COBOL

Japanese banks have been warned for years that the people who understand their mainframes are retiring. A widely read government report in 2018 described a cliff in 2025, when ageing systems and the ageing people who knew them would leave companies unable to change either. At least one major domestic manufacturer has since announced that it will stop making mainframes later this decade. The usual response is a skills programme: train younger engineers in COBOL, hire contractors who know the language, or rewrite the code in something newer. My position, after moving Shiomine off its mainframe in 2025, is that these responses address the smaller problem. The scarce thing is not the language. It is the knowledge of why the system does what it does to customers' money, and a bank should pay its retiring engineers to explain that knowledge, record it in business terms and hand it to the divisions that own the customers.

The shortage is not of programmers

COBOL is not hard to learn. A capable graduate engineer can read and change a well-structured COBOL program within a few months, and several of ours did. What they could not do, however well trained, was tell me why a loan's repayment date moved in some months and not in others, or why one savings product rounded interest in a way no current product did. Those behaviours were decisions made by people in the bank, sometimes forty years ago, and implemented by engineers who understood the reason at the time and documented the code rather than the reason.

When we began preparing for our migration in 2021 we had about 4,600 programs and 2,300 batch jobs. Thirty-seven engineers in the bank and our technology subsidiary could maintain them, and fifteen of those would reach sixty before cut-over. I asked each senior engineer to describe the parts of the system that worried them. Almost none of their worries concerned code. They concerned exceptions: arrangements for particular customers, products or seasons that existed nowhere except in the programs and in their memories.

One example has stayed with me. Some of our agricultural loans had repayment schedules tied to the rice harvest, so that payments fell due in the autumn rather than every month. The schedules had been set up in the 1980s through a combination of a product code and a branch-level parameter that only three engineers understood. The new system handles seasonal schedules perfectly well. It simply had no way of knowing that these loans needed one. Had we converted them on product code alone, about 1,900 farming households would have received monthly demands in their first spring on the new core.

Paying people to explain

Japanese employers usually retire staff at sixty and offer continued employment to sixty-five on reduced terms, often around half of final pay and in lighter roles. That arrangement made sense when an experienced engineer's knowledge could pass to others gradually over several years. It makes no sense in the four years before a migration, when the bank needs that knowledge more intensively than at any earlier point in the engineer's career.

We created fixed-term migration-specialist contracts at final pay for the twelve engineers whose knowledge covered the most critical areas. The contract said plainly that their job was to explain and review, not to write code. Each worked alongside two younger engineers, and most of their week was spent with colleagues from lending, deposits and operations, recording rules in the language of the business rather than of the program. Our head of human resources argued against special terms for one group, and she was right that experienced branch staff held knowledge as important as any engineer's. The category we eventually agreed with her and the employees' union was open to any re-employed colleague whose role met published criteria.

Eleven of the twelve stayed to the end of the programme. Together with the business divisions they recorded 2,140 rules. Of those, 318 appeared in no existing specification, and 27 would have produced wrong results on the new core. The extra pay cost about ¥210 million over four years. A single rule converted wrongly, affecting interest or repayments across thousands of accounts, would have cost more than that to put right, and far more in trust.

Rules belong to the divisions that own the customers

The most important decision came after the migration. A rule library kept by the Systems Division would have decayed as the old specifications did, because engineers are not the people who change the rules. We gave each rule an owner in the business division concerned, so that the head of agricultural lending owns the harvest schedules and the deposits division owns interest conventions. Every change request we now send to the shared system's operator cites the rules it affects, and the owning division signs it.

This is less dramatic than a skills programme and harder to sustain. Divisions resist owning documentation, and the library needs a small permanent team to keep it consistent. It also exposes awkward facts. Some rules exist only because nobody ever asked whether they were still needed, and retiring them requires a business decision rather than a technical one. Twelve of our 2,140 rules have since been withdrawn on that basis, each with the owning division's agreement.

I am not arguing against training engineers in mainframe languages. Banks that will run mainframes for another decade need them, and we trained seven younger engineers who now support the interfaces that remain. But a board that hears about its mainframe risk only as a headcount of COBOL programmers is being given the wrong number. The better questions are how many of the system's rules about customers are written down where the business can read them, who owns those rules and how many people the bank depends on to explain the rest. If the answer to the last question is a handful of colleagues approaching sixty, the bank should pay them to talk, now, on terms that reflect what their knowledge is worth.