SCR Calculation Software for Solvency II: What to Look For

Choosing a solvency capital requirement engine is rarely a question of formulas. The calculation itself is prescribed — the standard formula is set out in the directive and its delegated regulation, and an internal model is validated by the supervisor. What separates one setup from another is everything around the number: where the input data comes from, whether the result can be reproduced six months later, and how quickly the figure reaches the quantitative templates that get filed.

This article covers what an SCR engine actually has to do, the criteria worth testing before committing, and how the calculation connects to the rest of the regulatory chain.

What the calculation involves

Under the standard formula, the SCR is built from risk modules — market, life underwriting, non-life underwriting, health, counterparty default — each broken into sub-modules with their own shocks. These are aggregated through correlation matrices into a basic solvency capital requirement, to which operational risk is added, and from which adjustments are made for the loss-absorbing capacity of technical provisions and deferred taxes.

Firms using undertaking-specific parameters, a partial internal model or a full internal model replace parts of that structure with their own calibrations, subject to supervisory approval.

Two consequences follow for any tool that performs this work. It must handle a layered aggregation whose intermediate results matter as much as the final figure — a supervisor or an auditor will ask about a sub-module, not only about the total. And it must survive regulatory change, since the calibration of the standard formula is periodically revised.

That last point is not theoretical right now. Directive (EU) 2025/2, which revises Solvency II, must be transposed by 29 January 2027 and applies from 30 January 2027. It adjusts, among other things, the extrapolation of the risk-free rate curve and the treatment of interest rate risk — both of which feed the capital calculation. A tool whose calibration logic is buried and undocumented becomes a liability the moment those specifications land.

The criteria that actually differentiate

Traceability of every input. The capital figure aggregates thousands of data points drawn from asset systems, policy administration and accounting. When a result moves between two runs, the useful question is which input changed. A tool that answers this natively saves days of investigation; one that treats the calculation as a black box turns every variance analysis into an archaeology exercise.

Reproducibility. Re-running the same period on the same data must return the same number, months later, with the calibration and parameters that applied at the time. This is what allows a firm to defend a filed figure. It requires versioning of both the data and the calculation parameters, not just of the software release.

Scenario and sensitivity capability. The capital requirement is not only a reporting output; it informs decisions about asset allocation, reinsurance and product design. Being able to re-run the calculation under alternative assumptions — and to do so in minutes rather than in a quarterly cycle — is what turns a compliance tool into something the business uses.

Integration with the reporting chain. The SCR result populates specific quantitative reporting templates and is commented on in the narrative reports. If the engine exports a spreadsheet that someone then re-keys into the reporting layer, the firm has bought a calculation tool and kept the reconciliation problem. The connection matters as much as the calculation.

Auditability of changes. Who modified a parameter, when, and on whose approval. This is standard practice in financial systems and remains uneven in actuarial tooling.

Buying, building, or assembling

The market splits into three approaches, and the right answer depends less on firm size than on how stable the surrounding data landscape is.

A dedicated actuarial platform brings a pre-implemented standard formula, maintained against regulatory updates, and a validation trail the supervisor is used to seeing. The trade-off is usually integration: these platforms carry their own data model, and the work shifts to feeding them correctly.

A calculation layer built on the firm's own data platform keeps the SCR close to the data that feeds it, which removes an entire class of reconciliation problems. It requires the firm to own the regulatory maintenance — and to document the calibration well enough that a new team can take it over.

An assembled approach — a specialised engine for the calculation, the firm's own platform for data preparation and restitution — is what we see most often in practice. It works when the interface between the two is designed deliberately rather than improvised through file exchanges.

We discuss the same trade-off at the level of the full reporting chain in Automating Solvency II Reporting.

What to test before committing

A demonstration on the vendor's dataset proves very little. The tests that reveal the difference use the firm's own figures:

1. Reproduce a past closing. Load a previous period, run the calculation, and compare against what was filed. Discrepancies expose undocumented assumptions on both sides.

2. Trace one sub-module end to end. Pick a single risk sub-module and follow it from source data to the aggregated result. Time how long it takes, and note how many manual steps appear.

3. Change one input and observe. A parameter change should produce an explainable delta, not a new number that nobody can attribute.

4. Run the export into your reporting layer. Not the export itself — the full path to the template that gets filed, including any manual step.

Where the calculation meets the rest of the chain

An SCR engine delivers its value once its output flows into the wider production system without manual handling: quantitative templates, narrative reports, internal risk assessment, and management reporting all draw on the same figure. The architecture that makes this possible is described in Automated Power BI Reporting Architecture.

At Finengy, we work on both sides of that boundary — the regulatory framework and the data chain that produces it — because a capital figure that cannot be traced, reproduced and filed on time solves only part of the problem. For the broader prudential picture, our complete Solvency II guide sets out the three-pillar structure this calculation sits within.

Evaluating an SCR solution or reviewing an existing one? Request a demo.