AI-Driven ORSA: What It Actually Means for Market Risk Teams
The Gap Between What ORSA Should Be and What It Is
At the heart of the Solvency II directive, the ORSA is defined as a set of processes constituting a tool for decision-making and strategic analysis, aimed at assessing, in a continuous and prospective way, the overall solvency needs related to the specific risk profile of the insurer.
Continuous and prospective. Those two words carry significant regulatory intent.
In practice, most ORSAs are neither. They are annual documents, produced under time pressure by actuarial and risk teams, assembled from multiple data sources, reviewed by management, signed off by the board, filed with the supervisor, and largely untouched until the following year's cycle begins.
This is not a failure of intention. It is a failure of tooling. The ORSA was designed for a dynamic risk assessment process. The tools most insurers use — spreadsheet models, static scenario libraries, manual narrative writing — make dynamic impossible.
AI changes the constraint. But it doesn't automatically deliver the outcome. This piece is about what an AI-assisted ORSA actually requires, specifically for market risk teams running Solvency II standard formula calculations.
What the ORSA Actually Requires for Market Risk
The ORSA's market risk obligations under Solvency II are broader than the SCR calculation alone. Three specific requirements create the most operational burden, and the most potential for AI-assisted improvement.
1. Scenario selection and justification
In their ORSA, insurers must establish their own risk measurement approaches, including those based on scenarios, in order to derive suitable risk assessments and address shortcomings of the standard formula. This means the scenario set isn't just the standard formula stress parameters. It needs to reflect the insurer's actual risk profile, including risks the formula doesn't capture well.
For a portfolio with significant duration exposure in BBB-rated corporates, the relevant scenario isn't just the prescribed spread shock. It's a combined duration-amplified spread shock, calibrated to the portfolio's specific duration profile. Selecting, parameterising, and justifying that scenario currently requires significant manual actuarial work. It also needs to be redone whenever the portfolio composition changes materially.
2. Assessment of standard formula appropriateness
The assessment of the appropriateness of the standard formula is a key part of the ORSA process under Solvency II. The insurer must demonstrate that it understands where the formula captures its risk profile well and where it doesn't, and document that assessment with specific reference to portfolio characteristics.
This is exactly where the concentration risk blind spots from last week's issue become an ORSA obligation. If the formula's single-name threshold misses a sector cluster in the portfolio, the ORSA should say so, and quantify the gap. Currently, identifying that gap requires the kind of cross-module, cluster-level analysis that most standard formula implementations don't produce automatically.
3. Forward-looking prospective solvency assessment
The ORSA requires a thorough analysis of all reasonably foreseeable and relevant material risks under various stress scenarios, it is not a one-time exercise but an ongoing process integral to the insurer's Enterprise Risk Management framework.
The "ongoing" requirement is where annual ORSA cycles most clearly fail to meet regulatory intent. A portfolio that passes its annual ORSA in January faces a very different risk environment in October — new spread levels, shifted interest rate curves, changed equity valuations, potentially new concentration clusters. The regulatory expectation is that the ORSA reflects current risk, not last year's.
What AI Actually Changes — Four Concrete Shifts
Shift 1: Scenario generation from weeks to minutes
The most immediate impact of AI on the ORSA cycle is in scenario construction. Today, building a new stress scenario for an ORSA typically involves: defining the macro shock, translating it into module-level parameters (yield curve shifts, spread widening by rating and duration, equity shocks), running the SCR calculation, and documenting the rationale. For a team with the right tools, this takes days. For most teams, weeks.
An AI layer connected to the SCR calculation engine can compress this to minutes. The risk manager describes the scenario — "EUR sovereign spread widening of 120bps concentrated in BBB periphery, combined with a 15% equity shock" — and the system translates it into module parameters, runs the calculation across all six market risk sub-modules, and produces a structured output with SCR impact by module and aggregate.
The scenario library stops being a fixed document and becomes a dynamic capability.
Shift 2: Continuous standard formula gap detection
All the different processes — data feeds, data validation, scenario analysis, risk modeling, sensitivity analysis and stress testing — can be automated and improved with the right tools, helping insurers respond to emerging risks more efficiently.
For market risk specifically, this means running portfolio-level analysis continuously against the standard formula output, not just at ORSA time. When a new concentration cluster builds, when duration profile shifts, when spread sensitivity changes, the system flags the divergence between the formula's capital charge and the actual risk exposure. That flag becomes the input to the next ORSA update, not a surprise discovered during the annual cycle.
Shift 3: Narrative anchored to calculation
The ORSA report requires qualitative narrative explaining the quantitative results. This is, consistently, the most time-consuming part of the ORSA production cycle. Risk teams with strong quantitative capabilities spend disproportionate time writing, translating numbers into prose that satisfies regulatory expectations for comprehensibility and completeness.
AI can generate that narrative. But there's a critical constraint: the narrative must be anchored to the calculation output, not generated from general reasoning about market risk. An LLM that produces a plausible ORSA narrative without tracing it to the specific portfolio positions and SCR module outputs is worse than no AI at all — it creates a compliance risk disguised as efficiency.
The architecture that works: AI generates narrative from structured calculation output, with every claim traceable to a specific data point, module result, or scenario parameter. The output is readable by a board director and auditable by a supervisor. That combination — comprehensible and traceable — is the ORSA requirement, and it's also the hardest thing to deliver.
Shift 4: ORSA as continuous process, not annual document
This is the most consequential shift, and the furthest from current practice.
The frequency of the ORSA must be at least annual, but must be adapted to the volatility of the risk profile of the insurer. That caveat — adapted to volatility — is the regulatory basis for more frequent ORSA updates. In a market environment where spread levels, interest rate curves, and equity valuations can shift materially within a quarter, "annual" is insufficient for many portfolios.
An AI-assisted ORSA infrastructure that maintains live scenario calculations, continuous gap detection, and on-demand narrative generation makes more frequent updates operationally feasible. The ORSA doesn't become a document that's produced once a year. It becomes a state of the portfolio that's always current, with a formal report generated at regulatory intervals, plus interim updates triggered by material market moves.
That's what "continuous and prospective" actually means.
The Architecture Requirement
Delivering an AI-driven ORSA for market risk isn't a prompt engineering problem. It's an architecture problem.
The components that need to work together:
A live SCR calculation engine covering all six market risk sub-modules, connected to current portfolio positions and market data. A scenario generation layer that translates macro assumptions into module-level parameters with documented methodology. A gap detection layer that continuously compares formula output to portfolio-specific risk exposure. A narrative generation layer that produces ORSA-quality prose anchored to calculation results with full traceability.
None of these components is trivial individually. Integrating them into a coherent ORSA workflow — one that a risk manager can use in real time and a supervisor can audit — is the engineering challenge that most "AI for insurance" platforms have not yet solved.
At RemitRix, this integration is what the platform is built around. The SCR calculation is the foundation. The AI layer reasons on top of it. The output is always traceable to the calculation, not generated from general knowledge about Solvency II.
That's the difference between an AI tool and an AI-driven ORSA.
Effi Mor is the founder of RemitRix, a scenario-based risk intelligence platform focused on Solvency II market risk, covering SCR modules, economic scenario generation, and AI-assisted portfolio stress testing for insurance companies and pension funds. Risk Intelligence Weekly publishes every Wednesday.