Parity: modernise COBOL, with proof

Created by team reverteris on September 27, 2026

**The problem.** COBOL still runs much of the world's banking. In 2020, New Jersey's governor went on TV asking for COBOL volunteers, because the state's unemployment system still ran on it. Banks want to move off, and AI can now rewrite the code. But moving is dangerous: in 2018 a botched migration at the UK bank TSB locked customers out for weeks and ended in a £48.65m regulatory fine. The slow, error-prone step is **verification**. Teams run the old and new systems side by side for weeks and compare the results by hand, and a single wrong cent, repeated across millions of accounts, is a regulatory incident. **The workflow Parity improves:** verifying a legacy-code migration. It turns that step from weeks of manual comparison into one command that answers in seconds, with the exact field that differs when something is wrong. **How it works, on a real system.** We used AWS CardDemo, an open-source mainframe banking app with 31 programs and 20,650 lines of COBOL, and migrated its monthly interest job (CBACT04C). 1. **Map:** parse the JCL and COBOL into a system map: 31 programs, 11 business jobs, 26 data files, and which program reads or writes which file. 2. **Rules:** plain-English business rules, each tied to the exact COBOL lines, with every citation checked automatically. They flag a real bug in the original: the last account's interest is never posted to its balance. 3. **Rewrite:** IBM Bob, in a custom mode called COBOL Migrator, writes the Java. Its one rule is to change the language, never the behaviour, so known bugs are reproduced on purpose and marked FAITHFUL. 4. **Proof:** the original COBOL, compiled unmodified with GnuCOBOL, and Bob's Java run on the same 2,000 generated accounts, with edge cases on purpose (negative balances, one cent, missing rate groups, near-maximum amounts). Every output record is compared field by field. Result: 5,321 of 5,321 records identical, and identical again on three fresh data sets. On the live site, anyone can press "Run proof" on brand-new data and get the answer in about 2 seconds. 5. **Planted bugs:** a checker that always says yes is worthless, so Parity breaks Bob's program six realistic ways and checks each one is caught: 6 of 6. Using floating point for money changed only 2 of 3,321 transactions, by one cent, and it was caught. The planted bugs also exposed a gap in our own test data (cycle credits were always zero), which we fixed. 6. **Report:** a migration report written for a bank's risk team: translation decisions, results, behaviour kept on purpose, and limitations. **Why it scales.** The map is deterministic parsing, not AI. Bob only ever sees one program and its record layouts at a time. The proof compares the files a program reads and writes, so it works for any target language. **Limits (honestly).** One batch program today. Online (CICS) screens and DB2 come next. Generated data can miss rare branches, so coverage-guided generation is the next step.

Category tags: