Are Solvency II technical provisions hard? Here are a few tricks to make your life easier

Admitted, technical provisions under Solvency II are never going to be easy. They require loads of data that often hardly exist, methodologies beyond the traditional actuarial curriculum, and technical solutions that are expensive whether bought or developed internally. However, there are ways to take away some of the headache. If your headache comes from delivering technical provisions within the shortening deadline, you should look into some of these tricks.

1. Make approximations

In many cases, technical provisions only have to use the full machinery for the annual calculation. According to EIOPA guidelines, you can make simplifications for your quarterly technical provisions, as long as they are proportionate, and follow common sense.

Not only are you allowed to make such simplifications, you probably should have something like this if you are materially exposed to market risk on your liability side. That way, you can keep an eye on it and run a hedging programme on a shorter time scale than quarterly.

The common sense that EIOPA guidelines prescribe is

  • Technical provisions have to be rolled forward with cash in-flows and out-flows, and with new business. Also, the roll-forward assumptions cannot be way off the actual experience.
    With respect to risk factors, the simplification should connect to the sensitivity analysis that the actuarial function has to make anyway.
  • EIOPA only applies this to life obligations, but it sounds like a good idea for non-life too.

From there, it is up to your imagination and modelling skills. Plus, you should probably clear it with your National Competent Authority.

2. Pick the right random numbers

If you are experiencing headaches with your technical provisions, chances are that you are doing stochastic simulations. Although stochastic implies drawing random numbers, make sure they are not too random. In other words, make sure you are using some of the many neat techniques for improving precision. If you get them to work well, it could maybe improve your precision a factor of 10, saving you roughly 99% in simulation time, since precision scales with the square root of the number of simulations.

I will get back to the actual techniques in a later article. Until then, if you are in the business of stochastic simulation for technical provisions, make sure that you, or a colleague, has read and understood Glasserman’s Monte Carlo Methods in Financial Engineering.

3. Take optimisation seriously

I once worked with a calculation that took about six hours on a 10-machine cluster and had to be run in 5-10 configurations every quarter. Something would often go wrong with the input data, so we would diligently spend a whole day on checking the input for two calculations so we could run them overnight with minimal risk of having to recalculate.

No-one knew how extremely wasteful this was, until a colleague and I tried to make a parallel implementation in the R programming language. After a week of programming, it ran in eight hours on a laptop. I recently tried to re-implement it in the highly efficient Julia programming language, and it ran in about 10 minutes on my laptop.

What I found most disturbing, was the way the long calculation times made our processes rot and gave us the impression, that spending weeks every quarter on this task was necessary. We could probably have done it in a day or two with the right tools at hand.

In the same way, you should not accept long calculation times and expensive hardware requirements without question.

If you want to know what questions to ask, be sure to hang around for an article on that subject!

Leave a Reply

Your email address will not be published. Required fields are marked *