• +44 (0) 208 123 8304

  • Hours: Mon-Fri 8am - 6pm

Menu Close

Proactive vs Reactive: Approaches to Solvency II changes

Solvency II returns have been mandatory for insurance and reinsurance companies since the 1st January 2016 and Lloyd’s Syndicate returns were submitted as early as the 1st November 2012. Preparation of the Solvency II returns has been an uphill battle ever since.

Solvency II reporting sets out regulatory requirements for these companies, and covers financial resources, governance and accountability, risk assessment and management, supervision, reporting and public disclosure. The regulation determines the solvency capital requirement which is the amount of capital that EU insurance and reinsurance companies must hold in order to substantially reduce the risk of insolvency.

Gradual reviews have been undertaken by EIOPA since the introduction of the directive, and reporting timetables has been steadily accelerated. Historic changes often have significant impact on capital modelling teams. For example, changes to the calculation of regulatory capital requirements for several categories of assets. Unprecedented events continue to drive changes to the directive and the production of the returns. Today we contend with the disruption caused by the coronavirus pandemic, and the ongoing tumult resulting from Brexit. 

Reporting processes initially set up are often found to be out of date, arduous and, in many cases, no longer fit for purpose.

Solvency II reporting is a beast and it takes years to develop a solid understanding of all the intricacies involved. Often users submitting their data do not fully understand all the regulatory requirements. The user journey, from calculating and capturing data, through to submitting to the regulator, needs to be transparent, efficient and precise. The aggressive timelines leave very little scope for rework and delays.

As Solvency II data is strictly regulated, there should always be very strong governance in place. Ensuring an adequate segregation of duties, and relevant security regarding user access, provides the company with a strong foundation of control and governance.

EIOPA (European Insurance and Occupational Pensions Authority) issues a new taxonomy at least once per year. As a result, there are plenty of changes to both systems and processes, so it’s a good idea for companies to conduct a review of their Solvency II processes and systems at the end of each reporting period, in a bid to identify weaknesses and drive continuous improvements. 

A rigorous review should be undertaken annually. Ideally this review should be conducted alongside the release of the new annual taxonomy, which is to be used as a basis for Q4 reporting onward. But what should you look out for?

Existing conditions:

Assuming that you are preparing for the upcoming Q4 and annual reporting cycle, it is necessary to review your prior Q3 and prior year annuals reporting logs.

  • Review all data defects encountered during the reporting periods, and when, in the process, they were encountered? Ideally data defects should be identified as far upstream as possible, at point of entry. Source systems, ETLs and data entry forms may need to be modified to eliminate these defects from recurring.
  • Compare the validations between your Solvency II solution and the submission portal (e.g. BEEDS). Are they aligned? If not, it may be necessary to update your system to include missing validations. If you are using a strategic reporting solution, it is likely that this responsibility resides with your vendor. Your vendor should be providing detailed release notes to support each update. Consider if the vendor has omitted any validations. If they have, it may be necessary to ask them to update the software and provide a new release – or provide you with hotfix instructions.
  • If you have a support desk for your users, you should also revisit any tickets raised by the users. Make sure to study these carefully. Tickets that were closed without technical remediation often identify needs to improve processes and/or end-user training.
  • Review your workflows. Do your workflows reflect the actual order of task execution? If not, why not? It may be necessary to reconsider the end-to-end user-journey, which may also result in technical changes to your Solvency II solution.
  • You should also review the governance process and timetable. If there were any resubmissions in the last year, then you need to understand why and ask if there are any weaknesses in the governance that may give rise to improvements. You should also discuss the timetable with the wider team to ensure that everybody can adhere to the timelines.

New conditions:

Changes to the regulations are frequent, and unless you are suitably prepared, the changes can become disruptive, even to a point at which reporting submission dates are jeopardised. The changes typically impact the Solvency II software solutions, but to accommodate the changes it is likely that source systems and complex models need to be updated for the changes too.

  • Consolidate the list of changes. Along with various other useful references, EIOPA provide a detailed list of all validations pertinent to both the current and prior taxonomies as well as a detailed change log. Most of the other supervisory authorities have similar references available on their websites.
  • Identify which changes impact your organisation.  A highly effective way to do this is to reference the Contents of Submission from the prior Q3 and prior annuals return.
  • Firstly, the changes need to be evaluated by the Solvency II reporting team, for expert assessment. There may be changes that require onward communication, and assessment, by other teams such as actuarial, underwriting and capital modelling.
  • Once a business review of changes has been undertaken, the changes need to be reviewed by the relevant technical teams and persons. The changes may yield further technical reconfiguration in the Solvency II software solution, and/or the source systems and spreadsheets that feed the solution.
  • Again, it may be necessary to visit release notes provided by your vendor. Ensure that the vendor has captured all changes in the software, and that your interpretations of any changes are aligned.

If there are many changes, prepare and execute comprehensive end-to-end testing. Where this is the case, you should ensure that you have the relevant test environments set-up, and even devise a test execution plan and test scripts. This is especially crucial for organisations relying on offshore and outsource teams responsible for the data processing.

It is always best to use your prior Q3 and prior annuals data, but some additional data may need to be manufactured to cater for changes to the taxonomies.

Resources need to be lined up and a sufficient window also made available for remediation and retesting of failed test cases.

The key is to systemise this process, as Function Six have done for countless insurers. Naturally, much of this depends on the Solvency II software that you use, but most systems will log various activities, and help expediate the review process. CCH Tagetik, for example, maintains a log of data entry by origin and by user. It will keep a log of all validation warnings and errors. It will even keep track of workflow execution, so it’s possible to view who processed what, when and in which order. 

At Function Six, we have devised reports and diagnostics tools to provide tremendously powerful overviews instantly, even comparing execution of one period compared with another. Having systemised the process, we can complete a comprehensive review in as little as a few days.

In summary, when dealing with Solvency II changes, there’s the choice to decide between proactive and reactive.  You can elect to take it head on and be prepared, or be in a perpetual state of reacting to what simply doesn’t work anymore.

It’s always better to  set yourself up for success and take a proactive approach. With a little extra effort and discipline, what might appear to be a daunting task can itself be mostly automated and spare your staff countless hours of stress and anxiety.




Kai Engel
Kai is an experienced Application Consultant and exceptional CPM architect. He is an Oracle HFM Certified Implementation Specialist and a former Tagetik CPM consultant. Kai also has considerable Solvency II Pillar 3 application implementation experience having held the Tagetik UK position of Solvency II Lead. Kai’s technical skills extend well beyond Tagetik and HFM, and he has spent his entire career on the project frontlines.

Learn how LucaNet transformed financial reporting at Toshiba.


Learn how LucaNet transformed financial reporting at Toshiba.

Share This

Copy Link to Clipboard