The $3 Trillion COBOL Problem — And How PCD Solves It

The Scale of the Problem

There are 220 billion lines of COBOL running in production right now. Not in museums. Not in textbooks. In the systems that process 95% of ATM transactions, 80% of in-person financial transactions, and the majority of government operations worldwide. Every time you swipe a card, withdraw cash, file a tax return, or receive a government payment, there is a near-certain chance that COBOL is executing somewhere in the chain.

The financial industry alone spends $3 billion per year maintaining this code. Not improving it — maintaining it. Keeping it alive. Patching it when something breaks. Paying contractors who specialize in a language that universities stopped teaching decades ago.

The average COBOL programmer is over 55 years old. The workforce that understands this code is not growing — it is retiring. Every year, institutional knowledge walks out the door and does not come back. The people who wrote these systems in the 1970s and 1980s are gone or going. Their code remains, undocumented, mission-critical, and increasingly unmaintainable.

This is not a technology problem. It is a civilizational risk. The financial infrastructure of the global economy depends on code that fewer and fewer humans can read, understand, or safely modify.

Why Traditional Migration Fails

The obvious solution is to rewrite it. Banks have tried. Governments have tried. The results are catastrophic.

In 2018, TSB Bank attempted to migrate its core banking systems. The result: 1.9 million customers locked out of their accounts, fraudulent transactions going undetected, and a total cost exceeding $330 million. The CEO resigned. The bank's reputation never fully recovered. And the migration was not even complete.

COBOL-to-Java transpilers exist. They produce code that technically compiles — and is utterly unreadable. A 200-line COBOL paragraph becomes 800 lines of Java that no human would ever write. The transpiled code preserves syntax but loses meaning. Business logic becomes buried under layers of mechanical translation. The resulting codebase is harder to maintain than the original COBOL.

Manual rewrites take years. A medium-sized bank's core system might be 10 million lines of COBOL. At best, a team of 50 engineers can rewrite and validate 100,000 lines per year. That is a 100-year project. And every line rewritten is a line that might introduce a bug in a system that handles real money.

The fundamental problem: testing equivalence between the old system and the new system is nearly impossible. COBOL systems have accumulated decades of edge cases, implicit behaviors, and undocumented business rules. You cannot write tests for rules nobody remembers exist. One wrong number in a financial system is not a bug report — it is a regulatory violation, a lawsuit, or a bank run.

The PCD Approach: Extract, Verify, Emit

PCD takes a fundamentally different approach. Instead of translating COBOL line by line, it extracts the computational essence — the mathematical logic that the code actually performs — and represents it as a formally verified circuit.

COBOL → brikc lift → PCD Blueprint → brikc build → Rust / JS / Python / Go / C

Step 1: LIFT       Extract computational logic from COBOL source
Step 2: VERIFY     Certify the PCD blueprint (Φ_c = 1)
Step 3: EMIT       Compile to any modern language

Step 1: LIFT — Read the COBOL, Extract the Math

The COBOL frontend reads PROCEDURE DIVISION paragraphs, COMPUTE statements, IF/EVALUATE blocks, and PERFORM loops. It does not translate syntax — it identifies the underlying computation. A COMPUTE statement that calculates compound interest becomes a composition of arithmetic monomers. An EVALUATE block that routes transactions becomes a conditional composition. A PERFORM VARYING loop becomes a sequential fold.

COBOL's rigid structure is actually an advantage here. Unlike dynamically typed languages where behavior depends on runtime state, COBOL's DATA DIVISION declares every variable, its type, and its size upfront. PROCEDURE DIVISION paragraphs are essentially named functions with explicit inputs and outputs. This maps naturally to PCD's circuit model.

Step 2: VERIFY — Prove the Circuit Is Correct

The lifted PCD blueprint is run through the Thermodynamic Coherence Engine. When Φ_c = 1, the circuit is closed — every input produces a deterministic output, every path terminates, every domain constraint is satisfied. This is not a test suite that might miss edge cases. It is a mathematical proof that the extracted logic is internally consistent.

The verification also establishes behavioral equivalence: the PCD circuit computes the same function as the original COBOL code. If the COBOL computes PRINCIPAL * RATE / 100, the PCD circuit computes the same arithmetic — same operation, formally verified.

Step 3: EMIT — Compile to Any Modern Language

Once verified, the PCD blueprint compiles to any target language. Rust for performance-critical systems. JavaScript for web interfaces. Python for data pipelines. Go for microservices. C for embedded systems. The emitted code includes auto-generated tests that validate behavioral equivalence with the original computation.

A Real Example

Consider this COBOL routine — a simplified interest calculation that runs in thousands of banking systems worldwide:

       PROCEDURE DIVISION.
           COMPUTE INTEREST = PRINCIPAL * RATE / 100.
           IF INTEREST > MAX-INTEREST
               MOVE MAX-INTEREST TO INTEREST
           END-IF.
           COMPUTE TOTAL = PRINCIPAL + INTEREST.

The Lifter reads this and produces a PCD blueprint:

// PCD Blueprint: interest_calc
// Domains: principal [0, 1000000], rate [0, 30], max_interest [0, 100000]
// Computes: interest capped at max, added to principal
// Verified: Φ_c = 1

The PCD circuit does exactly what the COBOL does — but with explicit domain constraints, formal verification, and a liftability score of 0.95+. The TCE certifies Φ_c = 1: the circuit is closed, deterministic, and correct.

From this single PCD blueprint, you can emit:

brikc build interest_calc.pcd -t rust      # High-performance Rust
brikc build interest_calc.pcd -t js        # Browser / Node.js
brikc build interest_calc.pcd -t python    # Data pipeline integration
brikc build interest_calc.pcd -t go        # Microservice deployment
brikc build interest_calc.pcd -t c         # Embedded / legacy integration

All five outputs are provably equivalent. They compute the same function. The math guarantees it.

Why This Changes Everything

The key insight is that PCD migration is incremental. You do not need a big-bang rewrite. You do not need to shut down the mainframe. You lift one COBOL paragraph at a time, verify it, emit it, and deploy it alongside the existing system.

Migration Strategy: Incremental Lift
─────────────────────────────────────────
Week 1    Lift INTEREST-CALC paragraph       → Φ_c = 1 ✓
Week 2    Lift ACCOUNT-BALANCE paragraph     → Φ_c = 1 ✓
Week 3    Lift TRANSACTION-VALIDATE paragraph → Φ_c = 1 ✓
Week 4    Lift FEE-COMPUTATION paragraph     → Φ_c = 1 ✓
  ...
Week N    All critical paths lifted and verified
─────────────────────────────────────────
Original COBOL keeps running throughout.
Swap modules when ready. Roll back if needed.
The PCD blueprint is the source of truth.

Each lifted function is independently verified. Each can be tested against the original COBOL output. If something goes wrong — and in banking, you plan for things going wrong — the PCD blueprint is the source of truth. You can re-emit to a different language. You can adjust domain constraints. You can roll back to the COBOL. The blueprint captures the logic permanently.

This eliminates the existential risk that has killed every major COBOL migration attempt. There is no single cutover date. There is no "go live" moment where everything might break. There is a gradual, verified, mathematically proven transition from COBOL to whatever comes next.

The Business Case

The COBOL Migration Problem — By the Numbers
─────────────────────────────────────────────────
Industry COBOL maintenance spend:    $3 billion / year
Average migration project duration:  3 – 5 years
Migration project failure rate:      60%
TSB Bank migration loss (2018):      $330 million
Commonwealth Bank migration (2012):  $750 million over 5 years

The PCD Alternative
─────────────────────────────────────────────────
Lift-verify-emit cycle per module:   Days to weeks
Mathematical equivalence proof:      Automatic (Φ_c = 1)
Rollback capability:                 Instant (PCD is source of truth)
Target language flexibility:         Any (Rust, JS, Python, Go, C)
New talent pool:                     Millions of modern developers

The ROI is straightforward. Reduce $3 billion in annual maintenance costs. Access a talent pool of millions of modern developers instead of a shrinking pool of COBOL specialists. Eliminate the 60% failure rate of traditional migration projects. And do it incrementally, without betting the bank — literally — on a single cutover.

For a single institution, the calculus is even clearer. A major bank spending $50 million per year on COBOL maintenance can begin lifting critical modules immediately. Each module lifted is a module that can be maintained by any developer who knows Rust, JavaScript, or Python. The PCD blueprint serves as permanent documentation — something the original COBOL never had.

Getting Started

# Install the BRIK-64 toolchain
curl -fsSL https://brik64.dev/install | bash

# Lift a COBOL source file to PCD
brikc lift legacy_system.cob

# Verify the lifted blueprint
brikc check lifted.pcd              # Verify Φ_c = 1

# Emit to your target language
brikc build lifted.pcd -t rust      # → lifted.rs
brikc build lifted.pcd -t js        # → lifted.js
brikc build lifted.pcd -t python    # → lifted.py
brikc build lifted.pcd -t go        # → lifted.go

Start with a single COBOL module — the one your team dreads touching. Lift it. Read the PCD blueprint. For the first time, you will see what that code actually does, expressed as a formal circuit with explicit inputs, outputs, and domain constraints. Then emit it to whatever language your team knows. Run it alongside the original. Compare outputs. When you are satisfied, swap it in.

Then do the next module.

The Stakes

The COBOL problem is not going away. Every year, more COBOL programmers retire. Every year, the risk increases. Every year, the cost of doing nothing grows. The question is not whether these systems will be migrated — it is whether they will be migrated safely or catastrophically.

PCD does not ask you to rewrite 220 billion lines. It asks you to lift them — one function at a time, one circuit at a time, one proof at a time. The computational logic is preserved. The mathematical equivalence is guaranteed. The new code runs in languages that the next generation of engineers can actually read, understand, and maintain.

The math does the heavy lifting. You just point it at your code.