nieuws

‘Administratieve problemen vragen om rigoureuze aanpak’

Archief

Levensverzekeraars in Nederland, en ook daarbuiten, kampen al tientallen jaren met grote administratieve problemen. Een aanvraag voor een nieuwe verzekering duurt vaak weken en het verwerken van een mutatie kan zelfs maanden op zich laten wachten. Er worden door deze trage afhandeling veel fouten gemaakt bij maatschappij en intermediair. Daarnaast zien we dat veel verzekeraars tientallen miljoenen investeren in nieuwe systemen met regelmatig een desastreuze afloop. Een rigoureus andere aanpak is nodig.

Door Emiel Goosens
Levensverzekeringen hebben een bijzonder karakter. Het zijn lange-termijncontracten, met in veel gevallen afgegeven garanties gedurende de looptijd of aan het eind van het contract. Anderzijds zal een verzekering tijdens die lange looptijd regelmatig worden gewijzigd. Deze mutaties moeten administratief goed verwerkt en vastgelegd worden. Dit vereist een complex mutatiemechanisme, die de gehele life-cycle van een verzekering zichtbaar moet laten. Geen andere bedrijfstak met zulke grote volumes heeft met dit fenomeen te maken.
Een andere complicerende factor zijn de vele actuariële berekeningen binnen het verzekeringsbedrijf. Voor traditionele levensverzekeringen, zoals een gemengde verzekering of risicoverzekering, zijn er per product formules geprogrammeerd voor de berekeningen van premies, koopsommen, voorzieningen, mutaties, et cetera. Ontbreken dergelijke formules, dan moeten de mutatieberekeningen handmatig of met behulp van een spreadsheet worden gemaakt, wat de kans op fouten aanzienlijk doet toenemen.
Bij veel producten zijn de actuariële formules en de processen voor het afsluiten van een nieuwe verzekering goed uitgewerkt en getest. Echter, door de druk van de commercie wordt er geen of te laat aandacht geschonken aan de berekeningen bij een mutatie en de mutatieprocessen. Bij een succesvolle verkoop van nieuwe verzekeringen leidt dit onvermijdelijk tot administratieve problemen.
ICT en Actuariaat
Eén van de belangrijkste oorzaken van de problemen op administratief terrein ontstaat al in de beginfase, tijdens het ontwerpen en implementeren van de backoffice-systemen. De ICT-afdeling is vaak onvoldoende op de hoogte van de verzekeringstechniek en denkt de oplossing vanuit een technische invalshoek te kunnen vinden. Het actuariaat op zijn beurt heeft zijn handen vol aan jaarwerk, profit-testing en berekeningen van embedded- en fair-value, waardoor er onvoldoende betrokkenheid is bij de primaire gang van zaken. Terwijl toch het actuariaat in combinatie met productontwikkeling de kerngebruiker dient te zijn bij het opzetten van een architectuur voor een levensysteem.
De actuariële verslaglegging (voor de Pensioen- en Verzekeringskamer en interne rapportages) vragen om een gedetailleerde analyse van de winst naar de verzekeringstechnische bronnen. Voor traditionele verzekeringen moeten separate berekeningen worden gemaakt voor deze voorzieningen en analysecomponenten. Voor unit-linkedverzekeringen zijn deze gegevens, als het goed is, direct beschikbaar vanuit de rekeningadministratie. Het opzetten, testen en vervolgens onderhouden van zo’n verslagleggingsysteem is complex, mede omdat rekening moet worden gehouden met mutaties in vorige verslagperioden.
Winstdelingen
Volgend probleem is dat er in de jaren zeventig en tachtig bij levensverzekeraars zeer complexe winstdelingsregelingen zijn ontwikkeld, zoals bepaalde vormen van overrentedeling, die diep ingrijpen in de architectuur van een administratiesysteem. Ook op collectief terrein zijn regelingen ontwikkeld waar de klant zich het best in kon vinden, maar die administratief tot gedrochten zijn uitgegroeid. Ook voor dit soort regelingen en winstdelingen geldt dat ze voor nieuwe productie eenvoudig zijn door te rekenen, maar de consequenties voor mutaties zijn onvoldoende te overzien.
Een ander complex fenomeen zijn mutaties die met terugwerkende kracht moeten worden uitgevoerd; bijvoorbeeld een salarisverhoging die leidt tot een wijziging in aanspraken. Risicopremies en kosten moeten met terugwerkende kracht worden gecorrigeerd. Het handmatig berekenen van een dergelijke correctie is zeer tijdrovend en foutgevoelig.
Offertesoftware
Veelal werkt het intermediair voor offertes nog met cd-roms van verzekeraars. Dit betekent dat de rekenprogrammatuur (en parameters als grondslagen en productregels) dubbel worden geprogrammeerd en er nooit een exacte aansluiting kan zijn tussen deze offerteprogrammatuur en de polissystemen.
Daarnaast zijn productaanpassingen niet eenvoudig door te voeren en heeft de verzekeraar te maken met een kostbaar distributiesysteem. Offertes die leiden tot een polisaanvraag moeten meestal opnieuw worden ingetikt met een grote foutenkans. Mutaties kunnen sowieso niet door het intermediair worden doorgerekend, omdat zij niet over de actuele stand van de polis beschikken en de separate offertesoftware geen mutatieregels bevat.
Standaardisatie
Een maatschappij heeft vaak tussen de twintig en honderd levensverzekeringsproducten in omloop. En daar komen elk jaar wel wat producten of varianten bij. Een verzekeraar zal moeten streven naar een standaardisatie in berekeningen, waarderingen en analyses. De uitgangspunten voor de berekeningen moeten gelijk worden getrokken voor alle nieuw te ontwikkelen producten. Bij een overgang naar een nieuw systeem moet dit alles overstappen op de nieuwe bedrijfsuitgangspunten. De verschillen met de oude berekeningen zullen bij een goede productinvulling niet al te groot zijn en automatisch verdwijnen bij de eerstvolgende mutatie.
Om voldoende flexibel te zijn en de tijd om nieuwe producten naar de markt te brengen aanzienlijk te versnellen, moeten verzekeraars hun oude ‘gesloten’ berekeningsformules omzetten naar de open actuariële recursieformule. Hiermee kan in feite elk type levensverzekering worden berekend en daarmee wordt direct een standaardisatie in de berekeningen bereikt. De recursieformule kennen we vanuit het universal-lifeproduct, waar maandelijks de risicopremies voor de verzekerde dekkingen worden berekend en onttrokken uit de waarde. Dat deze formule ook voor traditionele garantieproducten kan worden gebruikt, is vaak niet bekend of wijkt te veel af van de oude leerschool.
Ketenintegratie
Verzekeraars moeten af van het per product uitwerken van mutatieformules. Het gaat er om wat de verzekeraar qua kosten en provisie wil verrekenen bij een mutatie. Als dat eenmaal bekend is, kan het generieke berekeningsmechanisme verder aan de gang.
De traditionele tweedeling van verkoop door het intermediair en acceptatie en administratie door de verzekeraar loopt ten einde. De ontwikkelingen op ICT-terrein maken het mogelijk dat de verzekeraar zijn deuren openzet en steeds meer gaat fungeren als een virtuele maatschappij, die zich vooral richt op productontwikkeling en het afdekken van risico’s. Het klantcontact, de verkoop en het beheren van verzekeringen zal steeds vaker door de adviseur/werkgever plaatsvinden.
Alle berekeningen, voorwaarden en regels liggen voor de complete keten vast op één plaats en kunnen van daaruit onderhouden worden. De cd-rom voor offertes verdwijnt. Het intermediair wordt dan in staat gesteld binnen bepaalde grenzen online eigen labelproducten te ontwikkelen die het best passen bij de doelgroep. Verzekeraars kunnen hun producten ook eenvoudig over de grens voeren, want er zijn nauwelijks nog grenzen.
In dit kader zullen verzekeraars ook een omslag moeten maken in het denken over ICT. Zij moeten afstappen van het idee om totaalsystemen te ontwikkelen of aan te schaffen. Er moet worden gekeken naar ‘best of breed’-oplossingen, die op basis van nieuwe technologieën (Java, CBD) goed aan elkaar gekoppeld kunnen worden. Bij de keuze van componenten moet kritisch worden gekeken naar de functionaliteit, performance, schaalbaarheid en robuustheid.
Leanapps (Barneveld).

Reageer op dit artikel
Lees voordat u gaat reageren de spelregels

Reageren kan op twee manieren.

Meld uzelf als gebruiker aan, uw naam verschijnt dan automatisch bij de reacties.

Of vink de optie gast aan en reageer onder eigen naam of een schuilnaam. Inlog en wachtwoord zijn dan niet nodig. Het kan maximaal 1 minuut duren voordat uw reactie zichtbaar wordt.

Een e-mailadres wordt altijd gevraagd maar nooit getoond.