COBOL Isn’t the Problem: AI Exposes Banking’s Missing Memory

What if the hardest part of moving a bank off COBOL is not understanding COBOL? OpenAI’s latest results suggest that the syntax barrier is finally becoming negotiable. The more uncomfortable conclusion is that banking’s real legacy is not a programming language. It is a body of undocumented decisions, exceptions and institutional memory embedded in software that nobody can safely explain anymore.

OpenAI says its models can migrate existing COBOL programs to C++, Java, Kotlin, Python or Rust while preserving their behavior. On the company’s COBOL migration evaluation, GPT-6.1 Sol reached 86.6% accuracy at low reasoning effort and 97.9% at higher effort. As Engadget reports, a migration counts as successful only when all tests pass. That is an impressive benchmark result—and a useful warning against treating it as a green light for production banking systems.

AI is getting better at translation, not at deciding what “correct” means

The strongest part of OpenAI’s work is that it does not define migration as “the new code compiles.” It tests whether the rewritten program behaves like the original, including details that are easy to miss in a superficial translation. COBOL’s fixed-point arithmetic, for example, discards excess decimal digits unless rounding is explicitly requested. A rewrite that rounds instead can run flawlessly while producing different financial results.

That distinction matters because legacy code is often a historical record of business policy. A line that looks awkward or obsolete may encode how a system handles a missing record, a fractional amount or an unusual transaction state. In this context, AI is valuable not because it makes the code modern, but because it can help expose and reproduce behavior that engineers cannot afford to casually reinterpret.

Still, a model can preserve only the behavior represented by its evaluation. OpenAI’s test uses hidden cases and byte-for-byte parity on observable outputs. A real institution must establish whether those outputs are themselves the desired ones. If a rule was created decades ago, copied through several systems and never documented, “matching the old system” may preserve an error as faithfully as it preserves a requirement.

The benchmark’s most important result is the gap that remains

OpenAI’s broader MultiLangBench evaluation asks models to build a SQLite-compatible database engine across 20 languages. GPT-6 Astra reached an average test pass rate of 87.4%, compared with 26.8% for GPT-5.6 Sol. Yet COBOL remained the hardest language in the test, at 72.1% for Astra. OpenAI’s own write-up presents that result as progress, and it is. But it also shows why “AI can code in COBOL” is a much smaller claim than “AI can modernize a bank.”

A database-engine benchmark gives the model a defined target and an objective test harness. A bank has transaction monitors, batch schedules, data stores, interfaces and operational dependencies around its programs. The supplied research does not establish that these surrounding systems have been migrated, nor does it show that a model can independently discover every dependency that matters.

This is where the sales pitch becomes less interesting than the organizational diagnosis. OpenAI says documentation may be incomplete, original developers may have left and important business rules may exist only in code. Those are not merely obstacles for an AI assistant. They are evidence that the institution has allowed its knowledge to become inseparable from an executable artifact.

The scarce resource will be tests, not generated code

The most consequential line in this story is not the 97.9% score. It is the condition behind the score: all tests must pass. That standard turns migration into a question of evidence. What cases should be tested? Which outputs are legally or financially significant? Which exceptions were intentional, and which are accidents nobody has dared to remove?

We think banks that have strong regression suites will gain the most from AI-assisted migration. They can use models to translate code, explain control flow, propose documentation and generate candidate implementations, while their existing tests provide a boundary around acceptable behavior. Institutions with weak tests face a more dangerous prospect: a fast, polished rewrite that passes the limited checks available and silently changes the cases nobody recorded.

That makes AI less a replacement for COBOL expertise than a pressure test for engineering discipline. A model can lower the cost of producing alternatives. It cannot, by itself, assign accountability for a changed interest calculation or prove that an undocumented exception was safe to remove. OpenAI explicitly says production use still requires expert review and testing against business rules and dependencies, a caveat that should be treated as the headline rather than the footnote.

COBOL may become an asset instead of a stigma

There is a temptation to frame COBOL as dead weight waiting for a modern language to rescue it. That framing is too convenient. COBOL is still valuable precisely because it expresses systems that have survived years of real-world use. The problem is not that the language is old; it is that the knowledge surrounding it has not been made portable.

AI could help change that balance. Used carefully, it can turn opaque procedures into readable explanations, identify repeated logic, map behavior across versions and create test cases for review. In that role, it is closer to an archaeological tool than an autonomous replacement engineer: useful for recovering structure, dangerous when allowed to declare the excavation complete.

The winners will not be the banks that rush to delete COBOL. They will be the ones that use migration projects to capture the rules currently trapped inside it. Our verdict is straightforward: treat OpenAI’s results as evidence that translation is becoming cheaper, not that modernization is solved. Before moving a line of critical code, build the tests, document the exceptions and name the humans responsible for the result. The future of banking software may be written in Python or Rust—but its correctness will still be a social and institutional achievement, not a syntax conversion.