Publications Contractual Service Margin – calculate this also at the policy level!

Contractual Service Margin – calculate this also at the policy level!

This article appeared in The Actuary from October 2018, with the theme ‘IFRS17’

The implementation of IFRS 17 and determining the Contractual Service Margin (CSM) for existing insurance contracts presents insurers with major challenges. The CSM represents the unearned profit of a group of insurance contracts (‘unit of account’) and is shown as a liability on the balance sheet (see IFRS 17.38). The CSM is shown as ‘revenue’ in the P&L account during the period in which the insurer provides services (IFRS 17.44(e), 45(e), and 66(e)). The depreciation pattern should take into account the ‘coverage units’ (IFRS 17.B119).

Despite the requirement that the CSM must be determined at the unit or account level, we see significant advantages in having the results of the calculations available at the lowest possible level, namely at the cover, claim, policy or contract level. This gives insurers maximum flexibility in determining the CSM on transition date (the transition date is the starting date of the earliest period included for comparison in the financial statements. This is the date when the IFRS opening balance sheet will be opened) and thus a great deal of insight into the differences between the various calculation methods and the impact of grouping on the results. This is also a good step towards an integrated solution for multiple reports.

In this article we will discuss the principles for calculating the CSM; the challenges, but especially the opportunities that investing in the right calculation level offers an organisation.

CSM Calculation level

IFRS 17 applies to groups of insurance contracts (IFRS 17.14). A group includes products with similar risks that are managed as such. These groups are further classified by type of profitability (certainly profitable, probably profitable and loss-making), measured at the time of entering into the insurance contracts. Finally, a distinction is made for annual increments. This classification forms the basis for the CSM calculations.

 Figure 1: Example of contract grouping

Three methods are available for the CSM calculation for existing portfolios at transition date. In the ‘full retrospective approach’ (‘FRA’) and ‘modified retrospective approach’ (‘MRA’), the CSM is determined as if IFRS 17 had always been applicable, i.e. from the moment of initial valuation. With the ‘Fair Value’ (FV) method, the CSM is determined prospectively. In principle, the FRA must be applied. If this is not possible, then the choice is between the MRA and the FV method. It should be noted that when information is available, it should also be used. Think for example of the information available for the compensation calculations of investment insurances.

Figure 2: example of application of transition method

The choice of grouping the contracts in combination with the transition method will largely determine the level of the CSM. The impact is expected to be greatest with the MRA because the standard leaves the most room for determining the groups. Modelling of the CSM at the lowest level (coverage, claim, policy or contract level) can provide benefits in determining the optimal allocation of groups.

In practice, it has already been shown that the number of groups used in determining the CSM has a significant impact on both the height and course of the CSM. With little effort, we also see enormous potential for the CSM in applying the MRA as compared to the FV method.

Data requirements: more data, more accessible

Obtaining the right historical data to determine the CSM at the outset will be an enormous exercise with the FRA and MRA. The specific problems here will strongly depend on society and even the insurer’s administration. Each system will have its own challenges, depending on the extent to which historical information and changes are still available. Method changes or conversions make the situation even more difficult. Obtaining realised cash flows and historical assumptions at unit or account level is the next challenge in this data exercise.

In short, IFRS 17 makes higher demands on data storage and access. Fortunately, there have been technological developments in recent decades that have enabled the storage of, and access to, huge amounts of data. Databases are often central in these solutions.

Model and system requirements: What level of detail can you handle?

IFRS 17 also sets strong requirements for the calculation of the CSM for models and systems:

  • Models should be able to calculate several interest curves and several principles (historical and current);
  • At a minimum, models should be able to calculate at the level of the unit or account and provide information;
  • Systems should be able to develop the CSM from period to period and to deliver the impact of changes to the CSM. In doing so, there should be a good link with the database/systems for IFRS 17 reporting to establish the balance sheet and P&L account.

The performance of models and systems is crucial here. They must be able to report the necessary information quickly. Calculating at a detailed level will demand a lot from models, because many insurers still calculate goals at a much higher model point level because of performance constraints. Performance also has influence on the consultation of all historical information, because links to the data can be time-consuming and not all models will have sufficient memory storage.

There is, therefore, a great need for robust, fast models that can calculate on a very detailed level. Here, too, the technological developments of recent times offer hope – efficient use of memory and database links is becoming more and more possible, and in terms of computing power, it is becoming less and less expensive for more computing power, so that calculations at policy level no longer create limitations.

Choice of detail level

The requirements imposed on data, models and systems by IFRS 17, and the technological possibilities that exist to achieve these, are a good opportunity to review the level of detail of the models. Not only does this offer valuable analysis possibilities, it can also be the start of an integrated solution for all reporting standards. We understand that, given the limited implementation time of IFRS 17 and the expected complexity, this will not be a priority for every insurer, but it is certainly worth investigating given the expected benefits.

Valuable analysis options

We have seen that IFRS 17 imposes high requirements on the level of detail to which information and calculations are required, namely per annual increment, product group and profit level. The CSM must be strictly prescribed at this level and must be depreciated: not at a higher level, but nor at a lower level. Nevertheless, it is interesting for an insurer to consider whether they are able to carry out the calculations at the lowest possible level. The Best Estimate Liability, the Risk Adjustment and the previous CSM, and the depreciation pattern should then be available at that level.

Advantages from this include enormous analysis possibilities, allowing for powerful management information, and explanation of impacts and differences. In addition, the allocation of unit or account groups in the transition phase is very flexible. In this way the CSM calculation can be set up generically, which makes calculating on unit or account level much easier. Aggregation can also be used to a greater extent. This gives insurers greater flexibility in determining the groups for the CSM calculation. Additionally, in regards to internal controls on the value of new production (VNB) and pricing, calculations at the lowest level can be a clear added value.

Of course this method also has disadvantages. It requires many models and systems, and not every insurer can move from their current point due to the short timelines, or simply will not want to make the investment because it isn’t strictly necessary. Calculations at the level of unit or account will also remain necessary at all times, because the CSM and depreciation must be reported at that level.

All reports from one system

Another consideration is whether an insurer will want an integrated solution for determining all reporting standards under IFRS 17 (including the CSM), Solvency II and internal reporting. What we still often see in today’s market are stand-alone solutions: a model determines the cash flows, but the eventual risk margin calculation is done in another system. An Analysis of Change is determined outside these systems. Excel solutions often still play an important role here.

There is a risk that the CSM will be calculated in yet another system. More systems pose more operational risks in the interconnecting areas. In addition, more systems make it more difficult to analyse the data integrally and to zoom in where necessary. By having all risk measures calculated by one system and offering them to the user in a combined analysis or change, with sufficient zooming possibilities, it is also easier to bridge the gap with Solvency II. For the model, Solvency II should therefore be nothing more than calculating a different scenario with different parameters.


In this article we have discussed the challenges that life insurers in particular will have in determining the CSM on transition date. Due to recent technological developments, applications are available that make it possible to determine the CSM at the lowest level. This gives insurers a lot of flexibility in determining the groups for which the CSM must be determined and a lot of insight in order to properly analyse the CSM determination and movement.

Do you want to cooperate with Triple A?

Do our themes appeal to you and is our culture exactly what you are looking for? Take a look at our vacancies. We are always looking for talent!

More knowledge?

This publication is part of the following themes

Call me back
  • This field is for validation purposes and should be left unchanged.

© 2024 AAA-Riskfinance – Belgium. All rights reserved.

This site is registered on as a development site.