One regulatory-change workflow for Solvency II and IFRS 17.
Solvency II and IFRS 17 have different objectives and calculations, but they often depend on related actuarial, finance, risk and data processes. Connect both requirement sets without collapsing the differences that matter.
Solvency II and IFRS 17 have different objectives, calculations and reporting outputs, but they often depend on related actuarial, finance, risk and data processes. Sia RegAI helps insurers connect both requirement sets to shared policies, controls, owners and evidence—without replacing the systems that perform valuation, capital or accounting calculations.
Two regimes, one operating environment
Solvency II is a prudential regime. It addresses the financial resources, governance, risk management and supervisory reporting expected of EU insurers and reinsurers.
IFRS 17 is an accounting standard for insurance contracts. It governs recognition, measurement, presentation and disclosure in general-purpose financial statements.
The objectives are different. So are important concepts, methods and outputs. Yet the implementation burden frequently converges in the same operating environment:
- Actuarial cash-flow data and assumptions.
- Discount-rate governance.
- Data lineage and quality controls.
- Model change and validation.
- Close and reporting calendars.
- Reconciliations and management review.
- Policies, methodologies and approval evidence.
- Regulatory and accounting change assessment.
The opportunity is not to force the two regimes into one calculation. It is to manage their relationships deliberately, reuse appropriate controls and evidence, and preserve the differences that matter.
Where requirements overlap—and where they do not
| Area | Solvency II | IFRS 17 | Control opportunity |
|---|---|---|---|
| Primary purpose | Prudential solvency, capital adequacy and policyholder protection | Comparable accounting for insurance contracts | Keep distinct interpretations and outputs while sharing governed source data where appropriate |
| Cash-flow estimates | Used in the valuation of insurance obligations | Used in fulfilment cash flows | Align data lineage, ownership, reconciliations and assumption governance |
| Discount rates | Defined by the prudential framework and related technical requirements | Reflect timing, currency and liquidity characteristics under the accounting standard | Preserve separate methodologies while sharing rate governance and change controls where justified |
| Risk adjustment / margin | Includes the Solvency II risk margin | Includes an explicit adjustment for non-financial risk | Do not treat the measures as interchangeable; document separate methodology and approvals |
| Contractual service margin | Not a Solvency II concept | Represents unearned profit under relevant IFRS 17 measurement models | Maintain IFRS 17-specific calculations, controls and disclosures |
| Capital requirements | SCR and MCR form part of the prudential framework | No equivalent prudential capital calculation | Keep calculation and reporting systems separate from the requirements traceability layer |
| Governance and evidence | System of governance, risk management, actuarial function and supervisory reporting | Accounting policies, estimates, controls, close, disclosure and audit | Connect shared owners, evidence and change impacts without collapsing distinct accountabilities |
This table is an operating-model summary, not a substitute for the standards or firm-specific accounting and actuarial analysis.
The problem with two separate compliance inventories
When Solvency II and IFRS 17 are managed in separate spreadsheets or document repositories, the same source data, model, control or policy can be assessed repeatedly by different teams. Changes may be implemented on one side without a structured check of the other.
Typical symptoms include:
- Duplicate requirement interpretation and control testing.
- Unclear ownership between actuarial, finance, risk and regulatory reporting.
- Reconciliations performed late in the close or reporting process.
- Evidence stored separately from the requirement or decision it supports.
- Model or assumption changes reviewed for one regime but not the other.
- Difficulty explaining why a shared data element produces different results.
- Manual reconstruction of impact analysis when a standard, delegated act or supervisory expectation changes.
Sia RegAI gives teams a shared requirements and impact layer without forcing them into a single calculation platform.
How Sia RegAI supports the combined workflow
Review regulatory and accounting changes
Use RegReview to identify, compare and assess changes in applicable Solvency II material and the organisation’s controlled IFRS 17 source set. Record the source, effective date, interpretation, applicability and review decision.
Identify affected obligations and processes
Break the change into actionable obligations. Connect each obligation to the entities, portfolios, products, processes, data elements, models, reports and disclosures potentially affected.
Match obligations to policies and controls
Use RegMatcher to connect the requirement to existing policies, controls, reconciliations, review steps and evidence. Highlight gaps, duplicate controls and mappings that require expert confirmation.
Route work to the right owner
Assign actions across actuarial, finance, risk, accounting policy, data, technology, compliance and internal audit. Preserve the review and approval trail rather than managing critical decisions in email.
Evidence the decision
Keep the interpretation, mapping, owner, approval, implementation evidence and effective date together. Auditors, regulators and internal reviewers can trace the outcome back to its source.
Example: assessing a change to an actuarial assumption process
- A relevant source or internal methodology changes.
- RegReview captures the change and the reviewer records its applicability.
- The affected Solvency II and IFRS 17 obligations are identified separately.
- RegMatcher surfaces shared data, model-governance and approval controls.
- Actuarial and finance owners confirm which controls can be reused and which must remain distinct.
- Actions are assigned for methodology, testing, disclosure, documentation or reporting changes.
- Evidence and approval are recorded before the change becomes effective.
- The final record shows both the shared operating impact and the different regime-specific outcomes.
A practical control model
Organise the combined inventory across six layers:
1. Source and requirement
Preserve the official source, paragraph or article, effective date, version and interpretation.
2. Applicability
Record affected entity, jurisdiction, product, portfolio and reporting basis.
3. Process and data
Map the requirement to source systems, data fields, models, transformations, calculations, reconciliations and reports.
4. Control and owner
Identify the control objective, control activity, frequency, accountable owner and reviewer.
5. Evidence and decision
Link policies, methodology papers, test results, approvals, committee minutes and reporting outputs.
6. Change and remediation
Track gaps, actions, dependencies, implementation status and residual risk.
A shared data model without shared calculations
| Shared object | Common identity | Solvency II relationship | IFRS 17 relationship |
|---|---|---|---|
| Legal entity | Entity identifier, jurisdiction, consolidation scope | Solo and group prudential scope | Reporting-entity and consolidation scope |
| Product / portfolio | Controlled product, line-of-business and portfolio keys | Risk, technical provision, capital and QRT views | Portfolio, group and measurement-model views |
| Data element | Source system, field, owner, effective period and lineage | Inputs to valuation, capital and supervisory reporting | Inputs to fulfilment cash flows, CSM and disclosures |
| Methodology | Version, approval, model owner and change record | Prudential assumptions and methods | Accounting policy, estimates and methods |
| Control | Control ID, objective, owner, frequency and evidence | Governance, data, model and reporting assurance | Financial-close, model, disclosure and audit assurance |
| Output | Report ID, period, producer, approver and retained evidence | QRT, SFCR, RSR and internal prudential reporting | Financial statements, notes, reconciliations and management reporting |
The identifiers can be shared while calculations and accounting conclusions remain in their authorised systems. Every mapping should record whether the relationship is equivalent, convergent, supporting or regime-specific.
Reconciliation workflow
- Confirm the entity, product, portfolio, currency and reporting-period perimeter on both sides.
- Reconcile controlled source populations before comparing calculated outputs.
- Separate expected methodology differences from data defects, mapping errors and timing differences.
- Assign each break to actuarial, finance, data or reporting ownership and record the resolution rationale.
- Retest affected totals and disclosures after correction; do not clear an exception only because the net difference is small.
- Retain the approved reconciliation, unresolved items, materiality decision and downstream-report impact.
Implementation architecture
| Layer | System role | Sia RegAI role |
|---|---|---|
| Official sources | EUR-Lex, EIOPA and the organisation’s controlled IFRS source set | Capture version, change, applicability and review decision |
| Actuarial and finance systems | Cash flows, assumptions, valuation, capital, subledger, consolidation and accounting entries | Reference system, field, model and output; do not replace calculation ownership |
| Data and reconciliation | Data platform, lineage, quality rules and reconciliation engine | Connect requirements to data elements, controls, owners, issues and evidence |
| Reporting | QRT/SFCR/RSR production and financial-statement reporting | Trace output requirements to process, approvals and retained evidence |
| Governance and GRC | Policies, controls, actions, testing and audit | Provide source-linked regulatory interpretation and mapping; define the system of record during implementation |
Buyer and pilot checklist
Public product view
Designed to complement—not replace—your existing stack
Insurers already use specialised systems for actuarial modelling, finance, subledger processing, consolidation, capital calculation and regulatory reporting. Replacing those systems is rarely the fastest way to improve regulatory traceability.
Sia RegAI sits around that stack. It makes the relationship between source, obligation, process, control and evidence explicit, while calculation results remain in their designated system of record.
Outcomes to validate in a pilot
A focused pilot should demonstrate that the team can:
- Trace a regulatory or accounting change to affected processes and controls.
- Distinguish shared controls from regime-specific requirements.
- Identify ownership and evidence gaps earlier.
- Compare the current and previous interpretation or mapping.
- Export an audit-ready record of review, action and approval.
- Reduce duplicate review without creating false equivalence between the regimes.
Avoid promising a specific time or cost reduction until it has been measured in an approved customer case.
Frequently asked questions
Can one
system calculate both Solvency II and IFRS 17?
Some actuarial and finance platforms support calculations or reporting for both regimes. Sia RegAI serves a different role: it manages requirements, impact, controls, ownership and evidence across the surrounding operating model.
Are Solvency
II and IFRS 17 values interchangeable?
No. The frameworks have different purposes and important methodological differences. Shared source data or controls do not imply that the resulting measures are equivalent.
Does Sia
RegAI produce IFRS 17 accounting entries?
No. Accounting engines, subledgers and finance systems remain responsible for accounting calculations and entries. Sia RegAI connects requirements and changes to the relevant process and evidence.
Does
Sia RegAI calculate Solvency II capital requirements?
No. SCR, MCR, technical provisions and related actuarial calculations remain in the insurer’s authorised actuarial and capital systems.
Who should participate
in implementation?
Typical stakeholders include actuarial, finance, accounting policy, risk, regulatory reporting, data, technology, compliance and internal audit. The exact governance depends on the insurer’s operating model.
Connect requirements to the way your insurer actually works
See how Sia RegAI can map Solvency II and IFRS 17 requirements to the processes, controls, owners and evidence already operating across your actuarial, finance and risk environment.