A practical approach to end-to-end Solvency II reporting in Databricks

A practical approach to end-to-end Solvency II reporting in Databricks | Databricks Blog Skip to main content

Summary

Solvency II is an end-to-end insurance reporting process spanning data ingestion, reserving, capital calculation, governance, and disclosure.

Fragmented systems, data sources, and teams make it difficult to monitor reporting readiness, investigate issues, and answer scenario questions quickly.

The demo shows how a connected workflow in Databricks can provide one control view, governed automation, AI-assisted review, and faster scenario analysis.

Solvency II reporting is not only a regulatory submission. It is a business process that connects data, models, controls, approvals, and narrative across an insurer. Solvency II is the EU's risk-based regulatory framework for insurance capital, governance, and disclosure (retained in the UK as Solvency UK). It requires insurers to assess and communicate their financial position through data, models, controls, approvals, the own risk and solvency assessment (ORSA), and regulatory disclosure to demonstrate they can meet obligations to policyholders. In practice, Solvency II reporting is an end-to-end business process that connects data ingestion, actuarial reserving, capital calculation, quantitative reporting templates (QRTs), the ORSA, governance approvals, and disclosure, all against strict regulatory deadlines. The challenge is that the process is often distributed across many systems, teams, data sources, and locations. When those parts are only loosely connected, it becomes difficult to maintain one governed view of the reporting cycle, or to answer a business question that cuts across it. A Databricks demo, presented by Laurence Ryszka, Databricks Insurance Sr. Solutions Architect, illustrates what this process could look like when implemented end-to-end: from ingestion and reserving through capital calculation, reporting, governance, and disclosure.

Why Solvency II reporting is difficult to operate Many Solvency II implementations were assembled over time. Different teams manage different parts of the process, data arrives at different speeds, and reporting activities can be spread across multiple systems and data locations. A person overseeing the process may have responsibility for the final submission without having one connected view of everything happening underneath it. That fragmentation creates specific, recurring problems: A data feed arrives late and requires manual follow-up to identify the owner and assess the impact A data-quality rule fails and the affected rows need a disposition decision before the workflow can proceed Two QRTs may not reconcile A model approval may block an automated workflow Leadership asks a scenario question, for example what happens to the solvency ratio if the insurer doubles its cyber book over the next 12 months, and answering requires data, models, capital calculations, and reporting outputs to work together.

Each issue pulls teams into separate investigations and coordination across tools. The submission gets made, but the process consumes significant effort and remains difficult to monitor. How Databricks supports end-to-end Solvency II reporting Databricks provides a single platform where the full Solvency II reporting cycle can be implemented as one governed workflow. The approach covers data ingestion, quality checks, actuarial reserving, capital calculation, QRT production, ORSA drafting, governance, and disclosure. This is not an either/or proposition. Most insurers run established actuarial and capital modeling suites, and those systems remain in place. Databricks acts as the governed data, orchestration, and reporting layer around them: preparing their inputs, consuming their outputs, and connecting both into one monitored process. The following sections describe how each part of that workflow operates. One control view for the reporting cycle At the center of the workflow is a control tower. It provides a single place to monitor the current solvency ratio, readiness for the reporting deadline, approvals, late feeds, and outstanding issues. Changes to the ratio can also be labeled with the event associated with the change, helping users understand what shifted rather than simply seeing that the number moved. This view changes the operating model from chasing updates across teams to working from a shared picture of the process. A late feed can be linked to its owner. An approval blocker can be surfaced alongside the workflow it affects. A reporting issue can be investigated from the same place where overall readiness is monitored.

Automated ingestion checks and data-quality controls Ingestion in the workflow is automated. Data is pulled as it becomes available and checked immediately. The first checks cover basic operational signals such as freshness, completeness, and ownership. Freshness shows whether a feed arrived when expected. Completeness verifies that expected records and fields are present, with volumes checked against previous uploads. Ownership makes it clear who is responsible for a source when a follow-up is needed. Data-quality rules provide another line of defense. The checks are customizable, and a failed rule can be surfaced for review. Teams can then decide how to handle the affected rows—for example, whether to accept, drop, or quarantine them—based on thresholds that fit their process. The workflow also supports reconciliation between QRTs. In the demo, an AI agent reviews a mismatch between two templates and traces it to stale property development factors flowing from the reserving feed into the capital calculation. It then provides a remediation path. The important point is not that an agent replaces review; rather, that the agent can focus on a specific issue and give the reviewer a useful second set of eyes. Model management, approvals, and audit trails Solvency II reporting depends on more than data movement. It also depends on models, approvals, and evidence that the process was completed correctly. The demo includes reserving models managed in Databricks with MLflow . It also shows how established actuarial and capital modeling suites—such as Prophet, RAFM, or Igloo—can be orchestrated within the same workflow: Databricks prepares the data those engines consume, ingests and governs their outputs, and carries the results through to reporting. The modeling engines stay where they are; the workflow around them becomes connected...