For Chief Risk Officers and Chief Actuaries at European insurers, Solvency II compliance has always demanded rigorous governance over how capital requirements get calculated. But as the framework evolves — with Directive 2025/2 now in force and Member States transposing amendments by January 2027 — the bar for data transparency is rising. And for carriers still running actuarial calculations, policy administration, or claims processing on legacy mainframe or AS/400s, meeting that bar gets harder every year.
Solvency II isn't just about holding enough capital. It's about proving you understand why your models produce the numbers they do — where the inputs originate, how they flow through your systems, and what business logic transforms them along the way. For insurers whose critical calculations still run on legacy languages like COBOL or RPG, that proof is becoming increasingly difficult to produce.
What Solvency II Actually Requires of Your Data
At its core, Solvency II's data governance requirements are deceptively simple. Article 82 of the Directive requires that data used for calculating technical provisions must be accurate, complete, and appropriate.
The Delegated Regulation (Articles 19-21 and 262-264) adds specificity around governance, internal controls, and modeling standards. EIOPA's guidelines go further, recommending that insurers implement structured data quality frameworks with regular monitoring, documented traceability, and clear management rules.
In practice, this means insurers need to demonstrate:
- Data traceability: A clear, auditable path from source data through every transformation to the final regulatory output — whether that's a Solvency Capital Requirement calculation, a technical provision, or a Quantitative Reporting Template submission.
- Calculation transparency: How does a policy record become a reserve estimate? What actuarial assumptions apply, and where do they come from?
- Data quality governance: Structured frameworks with defined roles, KPIs, and continuous monitoring — not just point-in-time checks during reporting season.
- Impact analysis capability: If an input changes, what downstream calculations and reports are affected?
For modern cloud-based platforms with well-documented APIs and metadata catalogs, these requirements are manageable. But for the legacy mainframe or AS/400 systems that still process the majority of core insurance transactions at many European carriers, this level of transparency requires genuine investigation.
The Legacy System Problem That Keeps Getting Worse
Many large European insurers run core business logic on mainframe or AS/400 systems that have been evolving for 30, 40, even 50+ years. Policy administration, claims processing, actuarial calculations, reinsurance — the systems that generate the numbers feeding Solvency II models were often written in COBOL by engineers who retired decades ago.
The documentation hasn't kept pace. In many cases, it was never comprehensive to begin with. Business rules were encoded directly into procedural code, updated incrementally over the years, and rarely re-documented after changes. The result is millions of lines of code that effectively are the documentation — if you can read them.
This creates a compounding problem for Solvency II compliance:
When supervisors or internal audit ask how a specific reserve calculation works, or where a risk factor in your internal model originates, the answer too often requires someone to trace it through the code manually. That trace depends on a shrinking pool of specialists who understand legacy COBOL systems — specialists who are increasingly close to retirement across the European insurance industry.
Every year the knowledge gap widens. And every year, the regulatory expectations for data transparency increase.
The Regulatory Pressure Is Intensifying
The Solvency II framework isn't standing still. The amending Directive published in January 2025 introduces significant updates that amplify data governance demands:
- Enhanced ORSA requirements now mandate analysis of macroeconomic scenarios and systemic risk conditions — requiring even more data inputs with clear provenance.
- Expanded reporting obligations split the Solvency and Financial Condition Report into separate sections for policyholders and market professionals, each requiring precise, auditable data.
- New audit requirements mandate that the balance sheet disclosed in the SFCR be subject to external audit — increasing scrutiny on the data chain underlying reported figures.
- Climate risk integration requires insurers to assess and report on climate-related financial risks, adding new data dimensions that must be traceable through existing systems.
National supervisors across Europe — from the ACPR in France to BaFin in Germany to the PRA in the UK — are tightening their expectations in parallel. The ACPR, for instance, has been specifically increasing its focus on the quality of data used by Solvency II functions, requiring actuarial, risk management, and internal audit teams to demonstrate traceability and solid evidence.
And the consequences of falling short are becoming tangible. Pillar 2 capital add-ons, supervisory intervention, and in severe cases, questions about the suitability of responsible executives — these aren't theoretical outcomes. They're tools that European supervisors have demonstrated willingness to use.
The Supervisory Fire Drill
Every CRO at a European insurer knows the scenario: a supervisor asks a pointed question about how a specific technical provision was calculated, or requests that you trace a data element from source through to its appearance in a QRT submission. Your team scrambles. The mainframe or AS/400 specialists — already stretched thin — get pulled from other work. Days or weeks pass before the answer materializes.
These examinations are becoming more frequent and more granular. Supervisors aren't just asking for high-level descriptions of data flows. They want attribute-level traceability. They want to see the actual business logic that transforms raw policy data into the numbers in your regulatory reports.
For carriers whose critical processing runs through legacy mainframe or AS/400s, these requests expose a fundamental vulnerability: institutional knowledge that exists only in people's heads, supported by code that only a handful of specialists can interpret.
The question isn't whether your supervisor will ask. It's whether you'll be able to answer confidently when they do.
Extracting Lineage from Legacy Systems
The good news: you don't have to replace your entire core system to solve the transparency problem. AI-powered tools can now parse legacy codebases and extract the data lineage that's been locked inside for decades.
This means:
- Automated tracing of how data flows through COBOL and RPG modules, job schedulers, and database operations — across thousands of programs, without needing to know where to look.
- Calculation logic extraction that reveals the actual mathematical expressions and business rules governing how risk data gets transformed — not just that Field A maps to Field B, but what happens during that transformation.
- Visual mapping of branching conditions and downstream dependencies, so compliance teams can answer supervisor questions in hours instead of weeks.
- Preserved institutional knowledge that doesn't walk out the door when your legacy specialists retire — because the logic is documented in a searchable, auditable format.
The goal isn't to decommission your legacy systems overnight. It's to shine a light into the black box — so you can demonstrate the governance and control that Solvency II demands over systems that still run your most critical functions.
From Compliance Burden to Strategic Advantage
The European insurers who navigate Solvency II most smoothly aren't necessarily the ones with the newest technology. They're the ones who can clearly articulate how their risk management processes work — including the parts that run on infrastructure built before many of today's actuaries were born.
That clarity doesn't require a multi-year transformation program. It requires the ability to extract and document what your systems already do, in a format that satisfies both internal governance requirements and supervisory scrutiny.
For CROs, Chief Actuaries, and compliance leaders managing legacy technology estates, that capability is rapidly moving from nice-to-have to essential — especially as the 2027 transposition deadline for the amended Solvency II Directive approaches.
The carriers that invest in legacy system transparency now won't just be better prepared for their next supervisory review. They'll have a foundation for every modernization decision that follows — because you can't confidently change what you don't fully understand.
Zengines helps European insurers extract data lineage and calculation logic from legacy mainframe or AS/400 systems. Our AI-powered platform parses COBOL and RPG code and related infrastructure to deliver the transparency that Solvency II demands — without requiring a rip-and-replace modernization.
