Modelverbeteringen doorvoeren en kostenbesparingen realiseren: sluit het één het ander uit?

De verzekeringsmarkt staat onder grote druk om kostenbesparingen te realiseren, terwijl de eisen op het gebied van regelgeving alleen maar toenemen en men steeds sneller wil kunnen of moet rapporteren. Dit gebeurt bij de meeste Nederlandse verzekeraars nog met een combinatie van de bekende maar enigszins verouderde actuariële software pakketten en een wirwar van Excel sheets. Terwijl de technologische ontwikkelingen juist heel veel mogelijkheden bieden om versnellingen te realiseren, de controle en het inzicht te verhogen én toch kosten te besparen. In dit artikel tonen we aan hoe dit gerealiseerd kan worden.

De huidige omgeving van de Nederlandse actuaris

Nederlandse verzekeraars zitten in zwaar vaarwater. Lage rentestanden en sterk verminderde vraag naar met name levensverzekeringsproducten drukken hun stempel op de markt. Kostenbesparingen staan daardoor hoog op de agenda van de Raad van Bestuur van iedere verzekeraar. Voorbeelden van kostenbesparingen die we in de markt waarnemen zijn het reorganiseren en moderniseren van processen, het opzetten van nieuwe direct writing labels, maar ook door een consolidatieslag.

Echter, toenemende eisen op het gebied van regelgeving (Solvency II, IFRS 17) maken het lastig om op het terrein van risico management en rapportages forse besparingen te realiseren. De implementatie van Solvency II heeft al een aanzienlijke investering in risico management en rapportage processen gevraagd, IFRS 17 zal om een nieuwe investering vragen. Naast het kunnen rapporteren van alle aanvullende eisen (bijvoorbeeld SCR en QRT onder Solvency II en de CSM onder IFRS 17), wordt de druk om dit steeds sneller te kunnen doen alleen maar groter. Zo gaat de deadline van de solo QRT onder Solvency II van 8 weken in 2016 naar 5 weken in 2020. IFRS 17 zal in 2020 een op marktwaarde gebaseerde verslaglegging tot gevolg hebben, waarbij nu het opleveren van IFRS rapportages op werkdag 5 voor grote verzekeraars geen uitzondering is. Ook intern neemt de behoefte aan snellere rapportages en meer analyse mogelijkheden toe.

Hoe gaan verzekeraars deze rapportage vereisten realiseren? Hoe zorgen zij dat ze de flexibiliteit hebben om toekomstige wijzigingen snel om te kunnen zetten? De huidige rapportage en risico management processen van Nederlandse verzekeraars hangen nog van veel aan elkaar geknoopte

Excel sheets en handmatige handelingen aan elkaar. Dit soort oplossingen worden daarom vaak aangeduid als “Spreadsheet City” of de “Excel jungle”. Excel blijft populair onder actuarissen en werkt laagdrempelig en prettig, maar bij complexere processen zijn betere alternatieven voor handen. Om ons heen volgen de technologische ontwikkelingen elkaar in een steeds sneller tempo op, dus waarom maken we hier geen gebruik van?

In dit artikel zullen wij de belangrijkste marktontwikkelingen delen op het gebied van actuariële modelling oplossingen aan de hand van een pilot bij een grote Nederlandse verzekeraar. Met dit artikel willen we aangeven hoe belangrijk het is dat IT en het actuariaat steeds nauwer met elkaar gaan samenwerken om de toekomstige uitdagingen aan te kunnen.

Een enorme toename van technologische mogelijkheden…

Ondanks dat de Wet van Moore van jaarlijkse verdubbeling van de snelheid van chips al een aantal jaren geen stand meer houdt, is er door de tijd heen voor dezelfde investering nog altijd steeds meer computerkracht beschikbaar. Berekeningen die voorheen een heel computercentrum aan rekenkracht vroegen, vinden tegenwoordig op een telefoon plaats en zijn makkelijk te bedienen en op afstand te besturen. Partijen als Facebook, Google en Amazon maken massaal gebruik van de kracht van databases, en algoritmen en tooling op databases wordt steeds slimmer (“Business Intelligence”). Ook de mogelijkheden tot cloud toepassingen nemen sterk toe: wereldwijd wordt er al veel gebruik gemaakt van de cloud. De concurrentie tussen aanbieders neemt sterk toe, waardoor onbeperkte capaciteit voor op- en afschalen steeds goedkoper wordt. Dit omdat er alleen betaald hoeft te worden voor het daadwerkelijke gebruik van computerkracht, en niet het reserveren ervan.

De beweging naar open source software heeft er ook voor gezorgd dat zelfs gevestigde partijen als Microsoft steeds meer kant- en klare en goed geteste invoegtoepassingen beschikbaar stellen binnen hun aanbod aan betaalde software pakketten.

…tegenover een verouderde en foutgevoelige werkomgeving

Dit alles staat in schril contrast tot de toepassing van IT oplossingen binnen het actuariaat. De actuariële software pakketten die door levensverzekeraars het meest worden gebruikt, zijn eind jaren negentig ontstaan en kennen in vergelijking met andere IT oplossingen zeer hoge licentiekosten. Veelgebruikte actuariële software pakketten in Nederland en de wereld kennen een beperkte koppeling van de berekende kasstromen en standen met databases. Input- en outputbestanden zijn regelmatig in een eigen bestandformaat gedefinieerd en zijn alleen via meerdere mappings in een database te krijgen. Het inrichten hiervan vraagt hoge licentie- en implementatiekosten.

De zwaardere actuariële modellen in Nederland draaien voornamelijk nog op een (intern of extern gehoste) serverruimte. Hierbij wordt altijd voor een bepaalde basiscapaciteit betaald die nooit optimaal benut wordt. Daardoor zijn de lasten hoger in vergelijking met de cloud, waar “pay-per-use” geldt. Ideaal voor piekbelasting, zoals bij actuariële kwartaal- of jaarrapportages het geval is.

De huidige rekenprocessen kennen ook nog veel schakels en handmatige handelingen, en daardoor lange doorlooptijden. Door de beperkingen in rekenkracht wordt vaak gekozen voor indikking van de portefeuilles en zijn uitkomsten vaak alleen op een geaggregeerd niveau beschikbaar of wordt onnauwkeurigheid in de berekeningen geaccepteerd. Dit terwijl uitkomsten op polisniveau met de huidige technologische ontwikkelingen erg goed te realiseren zijn en veel meer analysemogelijkheden en flexibiliteit bieden.

Ook op procesmatig gebied kan in het actuariaat nog veel van de IT collega’s geleerd worden. Actuariële modellen worden vaker niet dan wel vanuit requirements gebouwd en getest, waardoor ze moeilijk onderhoudbaar zijn naar toekomst en lastig te controleren. De impact van een change op doorlooptijd en op functionaliteit is dan ook lastig in te schatten, en het risico op een langer durend iteratief change proces ligt dan op de loer.

Modelaanpassingen worden veelal niet automatisch gelogd, en als meerdere gebruikers aan één model werken, moeten deze versies nog handmatig samengevoegd worden. Er is geen grote markt beschikbaar van collega’s die pakketten en add-ins doorontwikkelen, testen en gratis beschikbaar stellen, zoals bij open source software wel het geval is (pakketten als R of de .NET community).

De wereld van gebruik van cloud, apps, business intelligence tooling en grafische kaarten is ver weg voor de Nederlandse actuaris. Toch zijn er in Nederland enkele verzekeraars waarvan de risico modelleringsafdelingen al goede stappen aan het zetten zijn om een inhaalslag te maken op technologisch gebied. We willen verderop in dit artikel kort stil staan bij de specifieke modelontwikkelingen van een grote Nederlandse verzekeraar, maar nu eerst ingaan op de modelsituatie van de gemiddelde Nederlandse verzekeraar.

De situatie bij de gemiddelde Nederlandse verzekeraar

De gemiddelde Nederlandse verzekeraar heeft vaak één of meerdere kasstroommodellen in één van de veelgebruikte actuariële softwarepakketten. Deze zijn in gebruik om de marktwaarde van de verplichtingen van haar Leven portefeuilles te bepalen (dit kan zijn: uitvaart, unit linked, overig individueel leven en pensioen). Bij de meeste verzekeraars zijn deze modellen over een lange periode organisch gegroeid. Modellen werden uitgebreid wanneer portefeuilles werden toegevoegd of nieuwe producten werden geïntroduceerd. Zo kan een lappendeken van meerdere geschakelde modellen met vele subproducten ontstaan, die er elke keer los bij zijn ontwikkeld.

Documentatie achteraf

De code van deze modellen is vaak door veel verschillende actuarissen geschreven en niet of onvolledig gedocumenteerd. Met name door de komst van Solvency II is in deze “documentatie achteraf” in Nederland een flinke inhaalslag gemaakt. Echter, documentatie achteraf helpt niet mee aan een betere modelbouw en de motivatie daalt om de documentatie goed bij te blijven houden: als je vanuit requirements ontwikkeld moet je wel documenteren, bij achteraf documenteren sneeuwt dit vaak onder ten opzichte van andere prio’s.

Ook zijn modelkeuzes uit het verleden en de bijbehorende onderbouwing vaak niet meer uit de documentatie te achterhalen. De introductie van Solvency II en interne modelvalidaties heeft bij de meeste partijen dan ook vele modelissues aan het licht gebracht. Een groot deel hiervan is inmiddels opgelost, maar sommige onopgeloste modelissues worden bij de verzekeraars steeds moeilijker op te lossen in de bestaande situatie.

Onvoldoende analyse en rapportage mogelijkheden

De bestaande kasstroommodellen van Nederlandse verzekeraars werken veelal met geaggregeerde modelpunten als invoer, vanwege de lange rekentijden. Zeker voor de winstdelingsbepaling ligt dit aggregatieniveau zeer hoog, waardoor voor een portefeuille van miljoenen polissen nog enkele honderden modelpunten resteren. Daardoor is er geen output op polisniveau beschikbaar, wat de analysemogelijkheden zeer beperkt maakt en een beperking vormt voor bijvoorbeeld hedge onderzoeken, winstgevendheid- en Value New Business-rapportages en de komst van IFRS 17. Bijkomend nadeel van het gebruik van modelpunten is dat er op reguliere basis aangetoond moet worden dat ze voldoende representatief zijn voor de totale portefeuille.

Hoge foutgevoeligheid

Tot slot kent het rapportage proces van verzekeraars vele handmatige handelingen, procesafhankelijkheden en tussenstappen. Hierbij zijn vaak vele Excel sheets in gebruik, die door verschillende mensen zijn gemaakt en worden onderhouden en allemaal onderling geschakeld zijn (bijvoorbeeld via externe koppelingen. Daardoor is de doorlooptijd van het rapportage proces hoog, de inzet van medewerkers om de rapportage op te stellen intensief, de kans op fouten groot en onstaat er een aanzienlijk “key person risk”. Er zijn dan weer aanvullende handmatige maatregelen getroffen om deze kans op fouten te beperken, bijvoorbeeld door het 4-ogen principe toe te passen of controle sheets op te stellen. Door de toenemende behoefte aan meer, gedetailleerdere en snellere rapportages wordt deze situatie steeds moeilijker houdbaar en gaat iedere rapportageperiode gepaard met steeds meer stress.

Onderzoek naar alternatieven via een pilot

De verzekeraar uit dit artikel had behoefte aan het oplossen van meer modelissues, het kunnen berekenen van meer detailinformatie, een versnelling en verbetering van de rapportages en toename van de rapportage frequentie.

Uit een evaluatie samen met consultants is de conclusie getrokken dat het met oog op IFRS 17 en de huidige technologische mogelijkheden beter en op de middellange termijn kostenefficiënter is om een geheel nieuw modellandschap te introduceren. Daarbij zijn diverse oplossingen overwogen en is er uiteindelijk voor gekozen om in Microsoft Visual Studio een C# model te ontwikkelen, gebaseerd op één centrale Microsoft SQL database voor input-, run- en outputwaarden. Hiervoor is deze verzekeraar in de zomer van 2016 met een pilot gestart.

Het doel van deze pilot was het kunnen aantonen dat een zelf ontwikkeld model in C# en SQL geschikt is om de marktwaarde rapportages mee te kunnen uitvoeren, waarbij diverse doelstellingen op het gebied van kwaliteit, compliance en kostenefficiëntie moesten worden behaald. Dit aantonen werd gedaan door de marktwaarderapportage over 2016Q4 van de grootste portefeuille qua polis volume, de uitvaartportefeuille via dit nieuwe model te verzorgen. Daarbij willen we graag opmerken dat deze uitvaartportefeuille een grote variëteit aan productkenmerken, indexatieregelingen en winstdelingsvormen kent.

Een generiek model volgens de laatste IT principes

De insteek van het pilot model was het ontwikkelen van één generiek model, dat in de basis geschikt is om alle portefeuilles te kunnen waarderen, met minimale handmatige handelingen. Directe koppeling tussen de rekenmodules en de database voor input, berekeningen en output staan in dit modellandschap centraal. Functionaliteiten zijn in modules ontwikkeld, die afzonderlijk te draaien zijn, maar elkaar ook onderling kunnen aanroepen. Code is efficiënt en schaalbaar opgezet (“parallelliseerbaar”), cloudtoepassing is hierdoor eenvoudig te implementeren. De output van kasstromen is op een geaggregeerd niveau dat flexibel per polis is in te stellen. Daarnaast zijn output van contante waarden en standen op polisniveau beschikbaar.

Het model voldoet aan de nieuwste IT principes van de verzekeraar, in tegenstelling tot de oude modellen. Data kwaliteit en auditeerbaarheid worden via automatische procedures gegarandeerd. Zo wordt er een automatisch datakwaliteitsrapport over de gehele keten gegenereerd in database en csv formaat (waardoor dit eenvoudig in Excel te openen en te analyseren is), en worden ook run- en error logs op die manier geproduceerd.

Veranderingen in de gehele modelketen worden via Microsoft Team Foundation Server (TFS) automatisch samengevoegd worden en gelogd. Hierdoor is een snelle en parallelle ontwikkeling mogelijk. Tevens zijn veranderingen ook te herleiden en per persoon, tijd en datum in verschillende change versies automatisch vastgelegd. De productie- en acceptatieomgevingen zijn afgeschermd voor ontwikkelaars en modellen en data zijn in productie niet aan te passen door gebruikers, waardoor een controleerbare keten ontstaat.

Het modelontwikkelproces centraal

Het changeproces t.a.v. modelontwikkeling van deze verzekeraar is ook aanzienlijk verbeterd. Er wordt nu ontwikkeld door van te voren requirements op te stellen, die goedgekeurd worden door gebruikers en geaccepteerd worden door ontwikkelaars voordat zij gaan bouwen. Onafhankelijk van het daadwerkelijke model wordt er in Excel al tijdens de requirementsfase een eenvoudig en inzichtelijk schaduwmodel ontwikkeld, dat gebruikt wordt om de resultaten van het hoofdmodel 1-op-1 met grote precisie te vergelijken.

In de requirements worden modelkeuzes en –benaderingen expliciet vastgelegd en onderbouwd. Ook bevatten de requirements gedetailleerde formules, die door de bouwers eenvoudig in te bouwen zijn met weinig risico op interpretatieverschillen. De formulenummers en –namen komen overeen tussen requirements, input, model, schaduwmodel en output. Dit komt ten goede aan de overdraagbaarheid en testbaarheid van het model. De requirements vormen tevens de basis voor modeldocumentatie en zorgen ervoor dat de documentatie altijd up-to-date is, omdat het model pas gebouwd wordt als de requirements gereed zijn.

Het ontwikkelproces volgt het principe van “test driven development”. Eerst worden testcases en –code vastgesteld en de uitkomsten hiervan vanuit het schaduwmodel in het C# model geïmporteerd en blijvend vastgelegd. Dan wordt in het model de functionele code gebouwd, die ervoor moet zorgen dat alle tests slagen (“op groen gaan”). Dit wordt automatisch getest bij het opleveren van nieuwe code in TFS, waardoor voor testers direct te zien is of de tests geslaagd zijn, en testrapportages eenvoudig en geautomatiseerd gegenereerd kunnen worden. Doordat output op een gedetailleerd niveau per polis automatisch vergeleken wordt, kunnen testers snel verschillen en fouten opsporen.

Een belangrijk doel van de verzekeraar was ook om eigen interne medewerkers op te leiden en mee te nemen in het change proces, en dit niet volledig door externe consultants te realiseren. Het ontwikkelteam bestaat daarom voor ongeveer de helft uit interne medewerkers, die op alle onderdelen meedraaien.

Modelverbeteringen doorvoeren en kostenbesparingen realiseren: het kan samen!

De verzekeraar uit dit stuk heeft voor haar uitvaart portefeuille aangetoond dat een zelf ontwikkeld model in C# en SQL zeer geschikt is om de marktwaarde rapportages mee uit te voeren en het management van stuurinformatie te voorzien. De gestelde doelstellingen op het gebied van kwaliteit, compliance en kostenefficiëntie zijn behaald. Belangrijker echter nog is de potentie van het model naar de toekomst. De verzekeraar heeft haar model, modelomgeving en modelontwikkelingsproces op een dusdanige manier opgezet dat:

1. Het model gemakkelijker aangepast kan worden;
2. Door berekeningen en output op polisniveau ingespeeld kan worden op veranderingen in analysevragen en regelgeving; en
3. Er gebruik gemaakt wordt en nog verder gebruik gemaakt kan worden van technologische verbeteringen en versnellingen indien nodig.

De komende tijd wil deze verzekeraar het model verder uitbreiden met stochastische modules en andere portefeuilles. Daarnaast is men op dit moment ook bezig om door middel van Business Intelligence tooling in combinatie met een workflow manager (een programma om processen geautomatiseerd en gecontroleerd aan te sturen) haar rapportage- en analyse sheets te vervangen. Deze kunnen nu gebaseerd worden op de database input en output van het projectiemodel, waardoor er zich een heel nieuw scala aan mogelijkheden opent.

Een omslag in de modelomgeving van Nederlandse verzekeraars

In dit artikel hebben we een beeld geschetst van de modelomgeving van Nederlandse verzekeraars. Deze staat onder druk door toenemende rapportagevereisten, analysebehoeften en benodigde versnellingen. Terwijl er op dit moment veel technologische mogelijkheden zijn om deze doelen te bereiken, is het gemiddelde projectiemodel van een Nederlandse verzekeraar hier niet op ingericht. Veel verzekeraars bevinden zich nu in een situatie dat ze een afweging moeten maken wat op lange termijn efficiënter en voordeliger is: de huidige oplossingen die organisch gegroeid zijn steeds verder aanpassen of een geheel nieuwe opzet te maken, gebruik makend van de laatste technologische ontwikkelingen?

We hebben het voorbeeld van een grote Nederlandse verzekeraar aangehaald die, door middel van een pilot,  is gaan bouwen in een Microsoft omgeving met databases (C# en SQL). De verzekeraar heeft (intern) aangetoond dat met een dergelijke opzet kwaliteit, flexibiliteit en technologische vernieuwingen wel mogelijk zijn, waarbij de doorlopende kosten van deze omgeving een stuk lager zijn dan die van haar bestaande projectiemodellen in bekende actuariële software. De actuarissen zullen weer meer tijd hebben voor analyse en zich minder hoeven bezig te houden met het uitvoeren van het rapportage proces.

Deze verzekeraar is in Nederland niet de enige partij die van deze nieuwe technologische mogelijkheden gebruikt maakt. Inmiddels hebben meerdere grote verzekeraars zelfgebouwde modellen en/of rapportage processen in pakketten als C# en Python, die rechtstreeks op databases rekenen. Ook voor kleine verzekeraars is dit mogelijk: met standalone applicaties zonder licentiekosten en IT structuren.

Het aandeel van deze “early adapters” groeit en de IT wereld vermengt zich meer en meer met de actuariële wereld. Een soortgelijke ontwikkeling vindt al langere tijd plaats in de bankensector. Volgens ons is dit een omslag in de Nederlandse verzekeringsindustrie die niet meer te stoppen is.