URM: Prestaties en flexibiliteit zijn key

De oplossing van Keylane voor de uniforme berekeningsmethode is ontwikkeld met aandacht voor zowel flexibiliteit als prestatie. Met een configureerbaar rekenmodel kan elk product worden voorspeld. De prestaties worden geoptimaliseerd door onze expertise op het gebied van actuariële wetenschap en softwareontwikkeling te combineren. Met onze kritische blik op het actuariële veld en de interpretatie van de wet, hebben we ook een uitgebreide en meer consistente versie van rekenmethode 1 ontwikkeld en toegevoegd. Lees verder voor meer informatie.

Uniforme Rekenmethode (URM) voor Nederlandse pensioenuitvoerders

Op 23 april 2018 is in de Staatscourant het besluit gepubliceerd over de vaststelling van rekenmethodieken voor weergave van ouderdomspensioen in scenario’s. Daarin zijn de voorschriften vastgelegd op basis van welke rekenmethodieken deze scenario’s moeten worden berekend. Dit is onderdeel van de Pensioenwet en de Wet Verplichte Beroepspensioenregeling. De voorgeschreven rekenmethoden worden samengevat onder term Uniforme Rekenmethode, afgekort URM.

Als Keylane zijn we erin geslaagd om de URM optimaal vorm te geven in onze software. Hierbij hebben we een hoge mate van flexibiliteit gerealiseerd zodat de module geschikt is voor alle regelingen alsook de prestaties zodanig weten te optimaliseren dat grote batches eenvoudig kunnen worden berekend. De berekeningstool is beschikbaar via een webservice en kan worden gebruikt door elke software oplossing binnen het leven- en pensioendomein. Deze optimale software-oplossing wordt bereikt door onze expertise in zowel het actuariële veld als software development te combineren.

Binnen de Keylane-oplossing hebben we de drie rekenmethoden geïmplementeerd zoals deze wettelijk zijn voorgeschreven (generieke rekenmethode, rekenmethode 1 en rekenmethode 2). Daarnaast hebben we een gedetailleerde versie van rekenmethode 1 ontwikkeld.

De generieke rekenmethode is geïmplementeerd als een zeer flexibele oplossing, passend bij elke pensioenregeling. De flexibiliteit wordt bereikt door een configureerbaar rekenmodel te gebruiken (tabelstructuur) waarin elke projectiemaand in een rij wordt geëvalueerd, volgens de formules die voor de kolommen zijn gedefinieerd. Alle informatie uit de leven- en pensioensoftware kan door het rekenmodel worden gebruikt om de hoogte van de pensioenuitkering vast te stellen en te projecteren.

Na een eenmalige configuratie voert het systeem 2000 runs uit via het (de) rekenmodel(len). De invoer van elke run is deelnemer-, regeling- en scenario-afhankelijk (bijvoorbeeld de deelnemer-afhankelijke pensioendatum en de scenario-afhankelijke rentevoet van het kapitaal). Afgezien van de flexibiliteit voert het systeem vaste berekeningen uit. Deze vaste berekeningen zorgen ervoor dat alles conform de wet wordt uitgevoerd. Hoewel een hoge flexibiliteit wordt gegarandeerd in de generieke rekenmethode, is er geen degradatie van de performance. De webservice voert de berekeningen uit en retourneert de positieve, verwachte en negatieve scenario uitkeringen binnen een fractie van een seconde.

Rekenmethode 1 is geïmplementeerd als een goed presterende oplossing, met behulp van de formules zoals voorgeschreven door de wet. Dit betekent dat de 2000 scenario’s leiden tot drie scenario’s voor rekenmethoden. Uit deze scenario’s voor goed, verwacht en slecht weer (op basis van de koopkrachtfactoren) worden de verwachte werkelijke pensioenbedragen geretourneerd.

Binnen rekenmethode 1 hebben we een extra functie toegevoegd. Het is mogelijk om de berekeningen uit te voeren zonder de 2000 feitelijke scenario’s te vereenvoudigen in drie scenario’s. Deze extensie kan worden geïnterpreteerd als een ‘generieke rekenmethode berekening’ waarbij de performance vergelijkbaar is met die van rekenmethode 1.

We hebben deze functie toegevoegd omdat de vermindering in scenario’s van rekenmethoden leidt tot inconsistentie in het gebruik van de scenario’s*. Door de feitelijke geëvalueerde pensioenbedragen te sorteren, blijven alle scenario’s gescheiden. Bovendien gaan we er vanuit dat de vereenvoudiging is geïntroduceerd vanwege verwachte performance problemen. Dit argument is echter ongeldig omdat de performance degradatie bijna onmerkbaar is (een daling van ongeveer 5%).

Rekenmethode 2 is, evenals rekenmethode 1, geïmplementeerd als een goed presterende oplossing, met behulp van de formules zoals voorgeschreven door de wet. Deze rekenmethode is opgezet voor regelingen en pensioenproducten waarvoor geen haalbaarheidstoets wordt uitgevoerd. Telkens wanneer nieuwe gegevens worden opgeslagen, voert onze oplossing nieuwe initiële berekeningen uit. Deze initiële berekeningen leiden tot de output van een vereenvoudigde haalbaarheidstest. Deze output wordt vervolgens gebruikt in de berekeningen voor elke deelnemer.

We hebben de URM-oplossing geïmplementeerd als een op zichzelf staande rekenmodule. Dit betekent dat de rekenkern zowel beschikbaar is voor klanten die gebruik maken van Keylane software als voor klanten die gebruik maken van software van andere partijen. Volgens onze visie moet de URM module als zelfstandige rekencomponent enkel de URM-berekeningen uitvoeren. De software systemen voor leven en pensioenbeheer communiceren de resultaten.

In de Keylane URM-module zijn prestaties en flexibiliteit de sleutelwoorden:In de generieke rekenmethode kan iedere regeling worden geprognotiseerd. De performance is een fractie van een secondeVoor rekenmethode 1 en rekenmethode 2 ligt de uitvoering van de berekeningen binnen enkele honderdsten van een secondeMeer informatieWilt u meer informatie over onze module voor de uniforme rekenmethode? Neemt u dan contact op met
Floris van Tol
E: floris.van.tol@keylane.com of M: +31 6 206 114 70.
U kunt ook het contactformulier gebruiken. * Voor elk projectiejaar in rekenmethode 1 geldt (volgens de voorgeschreven berekening) dat het evalueren van de uitkering een deling bevat van de cumulatieve koopkracht van het huidige en die van het laatste projectiejaar. Door in elk projectjaar 2000 cumulatieve koopkrachtfactoren te berekenen en deze vervolgens te sorteren, behoren de goed-, verwacht- en slecht weer resultaten (naar alle waarschijnlijkheid) tot verschillende scenario’s per projectjaar. Het delen van de resultaten van vereenvoudigde scenario’s voor rekenmethoden resulteert daarom in een deling van waarden die tot bij scenario’s horen. Dit is inconsistent met andere berekeningen waar alles binnen het eigen scenario wordt gehouden.