Industry insights

Solvency II: Challenges for software providers remain

With the introduction of Solvency II on January 1, 2016, a new regulatory regime for the insurance sector has been established in the European Union. Some commentators have observed that Solvency II is the largest shake up of insurance supervision since the Second World War. The breadth of this new regulatory framework will have a substantial impact on the daily business of insurance companies in the EU, as well as software providers.

There are several challenges insurers have faced (and still face today) which we at the Regulatory Centre of Excellence have encountered first hand during the implementation of the Solvency II requirements over the past five years.

Learnings so far

One observation is that the mass of reporting requirements of Solvency II overburdens many small and medium sized insurers. Pillar III alone consists of more than 75 reporting templates which have to be provided to the authorities on a quarterly or annual basis.

When we started our first Solvency II project, several clients raised concerns about the availability of data, with one clearly stating: “We are only able to provide about two thirds of the required information, the rest is not present in our current system today.” Since then, insurers have enriched their asset management systems with the relevant data, but still some of the more detailed reporting templates cannot be completely delivered due to lack of data or missing data. The issue becomes particularly complex and laborious if many IT systems are involved in providing data for a certain report or if different parties or departments are involved in delivering the relevant data.

In the asset management area, one important and interesting example where data management has a very important role is fund decomposition. The Solvency II requirements in principle say that funds shall be looked through into the constituting parts. Now it turns out that insurance companies invest into many funds from many different asset managers.

Consolidating the large amount of fields to be reported under Solvency II from 100+ different asset managers is a huge task for an insurance company (without proper standardization). It is interesting to see data hubs evolve which collect and distribute fund detail data, but still it is expected that the data quality and the currently observed level of heterogeneity of data from different providers will demand undertaking-specific post-processing actions for insurance companies.

Satisfying the technical requirements

Although there is a vast amount of documentation on Solvency II, there is still a lot of uncertainty about the interpretation and concrete implementation of these requirements. EIOPA, the European Insurance and Occupational Pension Funds Authority, has issued thousands of pages in consultation papers, comments, technical standards, recommendations and other publications, but the complexity and size of Solvency II still requires clarification on a detailed level.

For software providers, one of the main problems is that we are expected to have a working software solution before the market has built a common opinion on how to interpret certain requirements. Another observation is that clients involve auditors in order to interpret requirements and different auditors (sometimes from the same auditing company) have different opinions on the same subject.

What can we as a software provider do in this case? There are two approaches: Either define one standardized interpretation and build the solution based on that, or create the solution as flexible as possible so that multiple relevant interpretations can be supported. We have in most cases decided to go for the second option, which later can lead to the situation that you have too many alternatives to be supported and maintained.

The challenges concerning the regulatory requirements from a software development point-of-view are manifold, including:

  • the “interplay” of different opinions from relevant market players (authorities, insurance companies and auditors)
  • the fact that requirements often seem to be defined and written by people who have little experience with software systems and therefore lack the necessary understanding about what a software system can and cannot do
  • the changing nature of the regulatory requirements
  • the deadlines in the software development cycle (which are completely independent from the regulatory deadlines)

It will be interesting to observe in which direction Solvency II will go in the coming months and years and which Solvency II standards and common sense will evolve over time.

To learn more about how we can support your Solvency II requirements, visit our Regulatory Center of Excellence.