Solvency II in SAC: structuring SCR, MCR and the solvency ratio

Solvency II is the European prudential framework that tells an insurer how much capital it must hold to stay safe. In a SAP Analytics Cloud model, three figures decide everything — the SCR, the MCR and the solvency ratio — and if they are aggregated the wrong way, every dashboard above them is wrong. This guide explains what each figure means, the thresholds that matter, and exactly how to structure them in SAC so the ratios are always correct.

What Solvency II actually requires

Solvency II (Directive 2009/138/EC, supervised across the EU by EIOPA) rests on three pillars. Pillar 1 is quantitative: it fixes how to value assets and liabilities, how to calculate technical provisions, and how much capital — the SCR and MCR — an insurer must hold. Pillar 2 covers governance and the ORSA (Own Risk and Solvency Assessment). Pillar 3 is disclosure: the Quantitative Reporting Templates (QRTs), the SFCR and the RSR. A SAC model is a Pillar 1 and Pillar 3 instrument: it computes the capital figures and feeds the reporting. Getting the Pillar 1 arithmetic right inside the model is therefore the whole game.

The three aggregates you must model

The SCR (Solvency Capital Requirement) is the capital that lets an insurer absorb a 1-in-200-year shock over one year — a 99.5% Value-at-Risk on own funds. It is the reference requirement supervisors watch.

The MCR (Minimum Capital Requirement) is the hard floor. Breaching it can trigger withdrawal of authorisation. By design the MCR sits between 25% and 45% of the SCR, subject to an absolute floor in euros that depends on the type of insurer.

The solvency ratio (SCR coverage ratio) is the headline number: eligible own funds ÷ SCR. It must be at least 100%; in practice insurers steer to a comfortable buffer (often 150–200%) so that a bad quarter does not push them toward the regulator. There is a parallel MCR coverage ratio (eligible own funds ÷ MCR) on the same logic.

The fourth ingredient is own funds themselves — the eligible capital, tiered (Tier 1, 2, 3) by quality. Own funds are a balance at a point in time, not a flow you add up across months; that distinction drives how you aggregate them in SAC.

How the SCR is built: the standard formula

Most insurers compute the SCR with the standard formula, which assembles it from risk modules rather than a single number. The main modules are Market risk, Counterparty default risk, Life underwriting, Non-life underwriting, Health underwriting and Intangible asset risk. Each module is itself built from sub-modules (interest rate, equity, spread, lapse, catastrophe, and so on).

These modules are not simply summed. They are combined through a correlation matrix that recognises diversification — different risks rarely hit their worst at the same instant. The Basic SCR is:

BSCR = √ ( Σ_i,j Corr_i,j × SCR_i × SCR_j )

The total SCR then adds the operational risk charge and subtracts the adjustment for the loss-absorbing capacity of technical provisions and deferred taxes:

SCR = BSCR + SCR_operational − Adjustment

The single most common modelling error is to treat the SCR as the arithmetic sum of the modules. That over-states the requirement by ignoring diversification, and it cannot be fixed downstream — the aggregation has to be a calculation, never a default sum.

Structuring it in SAP Analytics Cloud

A clean Solvency II model in SAC turns on a small set of well-chosen dimensions and a strict discipline on how each measure aggregates.

Dimensions

Four dimensions carry most Solvency II reporting: Risk module (Market, Counterparty, Life, Non-life, Health, Intangible, Operational), Line of business (the LoB segmentation the QRTs require), Entity (legal entity / solo vs group), and Version (Actual, Forecast, and your stress scenarios). The Risk-module dimension is what lets you show the SCR build-up as a waterfall instead of an opaque total.

Measures and — critically — their aggregation

This is where models break. Own funds, SCR and MCR are balances: across a time hierarchy they should aggregate with LAST (closing value), not SUM. If you leave them on the default SUM, a year total becomes the sum of four quarter-end balances — a meaningless number several times too large. We cover this trap in depth in how to choose the right aggregation in SAC; for Solvency II it is non-negotiable.

The ratios are worse if mishandled. The solvency ratio is a quotient of two aggregates. It must be defined as a calculated measure — own funds ÷ SCR computed at the level being displayed — and never stored as a number that SAC then sums or averages. Averaging a ratio across entities, or summing it across modules, produces figures that look plausible and are entirely false. Calculate the numerator and denominator, divide last.

The SCR aggregation itself

Because of the correlation matrix, the total SCR cannot be a roll-up of the Risk-module dimension. Two clean options in SAC: hold the correlation result as its own calculated measure driven from the module-level SCRs, or compute the diversified SCR upstream (in the actuarial engine) and import it as a separate measure alongside the undiversified modules, so the model can show both the gross build-up and the diversified total. Either way, the displayed total SCR is a deliberate calculation, not a dimensional sum.

Versions: ORSA, stress tests and forecasts

Solvency II is not a single snapshot; it is a steering exercise. The Version dimension is how you make the model answer "what if". Build an Actual version from the closing figures, then derive scenario versions — a rate shock, a mass-lapse event, a catastrophe — and let the ratio recompute under each. This is exactly the Actual / Budget / Forecast / scenario pattern described in using the Version dimension in SAC Planning, applied to capital instead of P&L. A well-built version structure turns the ORSA from a once-a-year document into a live dashboard.

A worked mini-example

Suppose an insurer reports, at year-end: Market SCR 60, Life SCR 40, Counterparty SCR 15, operational charge 8, and an adjustment of −10. Summed naively the modules give 115; with the correlation matrix the diversified BSCR might come to roughly 85. Total SCR ≈ 85 + 8 − 10 = 83. With eligible own funds of 150, the solvency ratio is 150 ÷ 83 ≈ 181% — comfortably above 100%. Had the model summed the modules (115) and skipped diversification, the same insurer would have shown 150 ÷ 113 ≈ 133% and looked materially weaker than it is. Same data, two stories — the difference is entirely in the aggregation.

Common mistakes to avoid

• Summing risk modules. Always aggregate the SCR through the correlation matrix, never as a dimensional total.
• SUM on balances. Own funds, SCR and MCR aggregate with LAST across time, not SUM.
• Storing ratios as data. The solvency and MCR ratios are calculated measures; compute numerator and denominator at the display level and divide last.
• One version only. Without scenario versions the model cannot support the ORSA or stress testing.
• Mixing solo and group. Keep an Entity dimension so solo and group views never contaminate each other.

Where this fits

Solvency II rarely lives alone. Insurers running it also report under IFRS 17, and banking groups face the parallel logic of Basel III capital and liquidity ratios — the same "calculate, don't sum" discipline applies to all three. If you want a head start, our Solvency II insurance template ships with the dimensions, modules and ratio measures already structured, and the verified & maintained regulatory kit adds the pre-filled thresholds and an import guide.

Sources

Directive 2009/138/EC (Solvency II) and its Delegated Regulation (EU) 2015/35; EIOPA guidelines on the standard formula and own-funds classification. Always check the consolidated EIOPA texts for the current correlation parameters and MCR floors, as they are periodically revised.