September 2026
This paper draws on Artizent’s experience building and operating an AI assisted reverse engineering platform across Fortran, COBOL, Delphi, C++, VB6 and Java codebases.
Executive Summary
Insurers have spent twenty years replacing legacy code and have mostly failed, because the problem was never the code. The rules that make an insurer an insurer exist only inside old systems and inside the memories of people who are about to retire. Five developments in applied AI now make it possible to recover those rules as signed, cited, tested statements, and to prove that whatever runs next honors them. That changes what modernization means.
of insurers still run legacy technology for pricing, rating and underwriting. Industry survey cited by Earnix, 2024.
of an insurer’s IT budget goes to maintaining legacy systems. PwC, cited by Earnix.
of new product technology budget is diverted to technical debt. McKinsey CIO survey.
Where the knowledge is locked
A mid sized carrier runs one to two hundred applications, but the knowledge that matters sits in a handful of them. Figure 1 is a composite estate. The color of each system shows how much of what it does is written down anywhere other than its own code.
The modern core rarely covers the whole book. Guidewire, Duck Creek, Insurity, Majesco or Sapiens usually runs the newer or larger lines, while one or more legacy policy systems continue to run older lines, specialty business and closed books.
The modern core’s rules were copied from legacy by hand. The analysts who configured rating algorithms and form attachment rules in the new core read the old code or asked the people who knew it, and wrote down only what the new system needed. The knowledge was moved, not recovered.
The amber systems are the ones regulators and auditors ask about. Rating engines, underwriting rules, claims adjudication and reinsurance cession logic are the most rule dense systems in the estate, and they carry the highest regulatory and financial exposure.
Why a legacy system that still works is still a problem
The policies issue, the bills go out and the claims are paid, so the system is left alone. But an insurer is not a transaction processor. It must change its prices and products continuously, prove to regulators that its rules are fair, report at a level of detail that depends on those rules, and buy and sell books whose value depends on knowing exactly what they contain. A system that works but cannot be understood fails at every one of those tasks.
Rate adequacy
A carrier that needs three release cycles to implement a rate change is underpriced for the difference, and it attracts the risks that faster competitors have just repriced away.
Speed to market
Cyber, parametric, embedded and usage based covers are configuration in a modern core and code changes in a VB6 or Fortran rating engine that two people can safely touch.
Filings and examinations
A SERFF filing must explain the rule. A market conduct exam asks how claims are handled. The NAIC AI bulletin, adopted by more than half of the states, requires the logic behind decisions to be documented and tested for unfair discrimination. The exposure is not that the rules are wrong but that nobody can show what they are.
Claims leakage
Auto adjudication thresholds, deductible and coinsurance application, salvage and subrogation triggers and reserve rules sit in batch code nobody can audit from outside.
Financial reporting
IFRS 17, LDTI and Schedule P depend on extracts from legacy policy and claims systems through transformations as old and undocumented as the systems themselves.
Deals and the AI roadmap
A buyer’s due diligence asks what the system does, and a carrier that cannot answer takes a lower price. The AI program, from automated underwriting to claims assistants, needs the same rules and definitions and is blocked by the same debt.
A tool that translates COBOL into Java does not reduce this debt. It moves the same undocumented rules into a language a different group of people also does not understand. A method that recovers the rules, has them confirmed by the people who still know them, and proves that whatever runs next honors them, does reduce it.
What changed: the rules can now be recovered
Five engineering disciplines have matured together since 2024. The clearest way to show what each one does is to follow one composite carrier through four months. It writes auto and homeowners in fourteen states. Auto moved to a modern core; homeowners still runs on a 1989 COBOL policy system, and both are rated by a VB6 engine whose author retires in fourteen months.
Week one, the knowledge graph. Parsers turn both systems into one structure of programs, copybooks, data items, forms and rate tables with every dependency as an edge. On day one it shows that POLICY MASTER is read by eleven programs, three of them in the billing batch, and it computes a blast radius for every routine to decide where to start.
Week two, context engineering. The 640 line territory routine read alone produces a plausible and wrong description. Read with its callers, its record layouts, the carrier’s own data dictionary entries and three already signed claims from a similar routine, it yields two correct rules and one bug: a hard coded effective date from a 2016 change that affects renewals in two states.
Weeks two to five, agents. An agent reads, looks up callers, fetches tables, drafts a claim, checks that the cited lines exist and say what the claim says, and raises open questions instead of guessing. Every fact must come from a recorded tool call, so an unsupported claim is rejected before a human sees it.
Week four, the ontology. The policy system says CONST CD; the rating engine says BLDGTYPE. Both are typed as construction class, so the two can be compared. A harmonization pass finds seven values in one and six in the other. The seventh falls through to a default factor: a live pricing gap in two states.
Weeks six to eight, loop engineering. The generated .NET rating code fails equivalence on four routines, all rounding. The fix is applied automatically, the gate passes, and the fix becomes a rule. The falsifying gate then finds a boundary at exactly three years licensed that nobody would have written a test for. The actuary resolves it in a minute.
Month four, drift. A three state rate revision changes two routines. The graph marks the signed claims on the moved lines stale, grouped by cause, and the actuary confirms them again in twenty minutes. The documentation the examiners will see is regenerated from signed claims and stays true.
Proof, not trust
The right objection to AI generated code in regulated work is that nobody knows whether it is correct. The answer is to make correctness a mechanical property of the pipeline rather than a matter of trust. Every generated artifact passes four gates before it can be committed, and every gate result is recorded.
The signed specification is the asset. Each recovered rule is a claim with a citation to source lines, typed against an insurance ontology, accepted or corrected by a named expert, hashed, signed with a key the carrier controls, and superseded automatically when the source changes. That catalog is what a state department means by the rule behind a rate, what an examiner means by how claims are handled, and what a core replacement program needs on day one.
The AI is tested like the code. A golden dataset of known traps for each language scores every prompt change in continuous integration, and a change that lowers claim coverage fails the build. Pilots are defined by numbers agreed in writing before they start: claim acceptance rate, citation accuracy, reviewer hours per routine, gate pass rate and audit completeness.
Inference stays inside the insurer’s environment. Model calls go through a zero data retention provider with the configuration version recorded per call, source is never logged, the audit trail is append only, and the whole pipeline runs in the insurer’s own cloud subscription with an approved model endpoint.
The same artifacts satisfy the regulators
The NAIC Model Bulletin, adopted by at least 24 states and the District of Columbia, requires governance, validation and testing, third party oversight and documentation of AI systems. DORA has applied to EU insurers since 17 January 2025 and requires a documented ICT risk framework. A signed, cited, gate tested specification with an append only audit trail is precisely what both describe. An insurer that builds it for modernization has built most of its AI governance evidence at the same time.
The method in one view
The five principles below follow from the loop in Figure 3. Each is paired with the part of a carrier estate where it earns its place first.
1. The signed specification is the asset
What it means: Produce cited, typed, expert signed claims before any code. Version control stays the truth for code; the specification becomes the truth for knowledge.
Where it applies first: Rating engines and COBOL policy administration, where the rules are densest and the filing and exam exposure is highest.
2. Correctness is proved, not trusted
What it means: Compile, test pack, equivalence and falsifying gates on every generated artifact, with a bounded repair loop and an audit event per result.
Where it applies first: Claims adjudication and payments, where thousands of input combinations make handwritten fixtures useless.
3. Documentation is kept alive
What it means: System overview, entry point map, data dictionary, interface and business rules catalogs drafted from the graph, signed, and marked stale when source moves.
Where it applies first: Acquired books, run off portfolios and any system whose two remaining experts are near retirement.
4. Sequence by dependency
What it means: Blast radius and readiness computed from the graph choose the waves; the shared copybook is documented first and migrated last.
Where it applies first: Mainframe estates where policy, billing, claims and the warehouse share the same forty copybooks.
5. Pay down debt in place
What it means: Same file, same signatures, upgrade actions as signed claims, equivalence proven; no rewrite.
Where it applies first: Java 8 and 11 portals, Spring Boot 2 integrations, .NET Framework workbenches, Delphi and VB6 desktop tools.
Why now, and how to start
The capability exists
Models read whole codebases with citations and return structured output; proof tooling is containerized and cheap; the five disciplines are repeatable engineering practice.
Regulators want the output
The NAIC bulletin and DORA ask for exactly the artifacts the method produces.
Deadlines are fixed
Java 17 premier support ends in September 2026. Windows Server 2016 extended support ends in January 2027. Older Java, .NET Framework and desktop toolchains have already passed their dates.
The experts are still here
The method depends on a human confirming each claim. In most carriers the last person who understands the rating engine is within a few years of retirement, and this is the one condition that cannot be bought back.
The hype is being filtered
AWS made agentic mainframe modernization generally available in May 2025. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027 for unclear value and weak risk controls. The projects that survive will be the ones with mechanical proof and written acceptance numbers, and it is now possible to insist on those.
Ninety days, one system, real numbers
Weeks 1 to 3. Choose one system that hurts now, still has one person who understands it, and is small enough to finish: a personal lines rating engine or one claims rules module. Ingest it, build the graph, let blast radius pick a first wave of ten to twenty routines, and agree the acceptance numbers in writing.
Weeks 4 to 8. Extract the wave. Put the actuary or claims manager in front of the claims beside the highlighted source and record every acceptance, edit, rejection and question. This is where the numbers come from, and where the organization learns which of its assumptions were wrong.
Weeks 9 to 12. Generate the target, whether a migration, an in place upgrade or documentation only. Run all four gates. Review the falsifying gate’s findings. Decide on the next wave on measured numbers, and cost the full program from them.
The insurance industry does not have a code problem. It has a knowledge problem that shows up as code. For twenty years the only tools available worked on the code, so that is what programs worked on, and the knowledge stayed locked where it was. The tools now exist to work on the knowledge directly, to have it confirmed by the people who hold it, and to prove that whatever runs next honors it. That is a different kind of modernization, and it is available now to any carrier willing to start with one system and measure the result. Whatever the next decision turns out to be, the signed specification that the first ninety days produce is also the answer to the next rate filing, the next market conduct examination and the next due diligence request.
About the platform behind this paper
The method described here is implemented in the Astra RE Harness, a reverse engineering and modernization platform that Artizent has built and operated since May 2026. It implements the loop in Figure 3 and the gates in Figure 4 for Fortran, COBOL, Delphi, C++, VB6 and Java sources, with .NET, Java and Angular targets, and it generates signed, drift aware transition documentation. Artizent uses it in its own modernization engagements and in the reverse engineering stage of its data migration work.
The carrier described above is a composite; the findings in it are the kinds of finding the process produces, and the counts are illustrative. Pilot targets on the platform are at least 70% of drafted claims accepted without material edit, at least 95% citation accuracy, under two hours of reviewer time per routine, 100% of scaffolds compiling and 100% audit completeness. These are design targets, not published client results. Readers who want to see the method applied to one of their own systems can contact the author.
Sources and notes
Earnix, “Data Modernization for Insurance: 74% Still Use Legacy Technology,” 2024 industry trends report citing PwC and Clearwater Analytics research. McKinsey, “Tech debt: Reclaiming tech equity,” October 2020, survey of 50 CIOs. McKinsey, “The new economics of enterprise technology in an AI world,” May 2025.
Computer Weekly, “Cobol knowledge crisis threatens Dutch financial systems,” 11 June 2024. NAIC Model Bulletin adoption count and the December 2025 NAIC statement as reported by actuary.info, “AI Regulation in Insurance 2026.” EIOPA, Digital Operational Resilience Act, application date 17 January 2025.
Oracle Java SE Support Roadmap, updated August 2026. Windows Server 2016 end of support date as reported by Microsoft partners; confirm against the Microsoft lifecycle page before publication. AWS, “AWS Transform for mainframe is now generally available,” 15 May 2025. Gartner, press release of 25 June 2025 on agentic AI project cancellations.
Figures 1, 2 and 5 are illustrative composites drawn from Artizent’s engagement experience across carriers and MGAs and do not depict any single client. The companion paper, “Technical Debt in Insurance Is Knowledge Debt: the full method and a worked case,” covers the four responses that have not worked, the complete carrier story, and each principle in detail.