Nederland is groot in pensioenen. Nederland is nummer 1 wereldwijd met pensioenkapitaal afgezet tegen het bbp. En niet alleen in kapitaal loopt Nederland voorop, maar ook in innovaties van de pensioenvoorziening zelf en in de manier waarop pensioenen geadministreerd worden. En juist in de pensioenadministratie worden grote stappen gezet. Waar traditioneel administraties gebaseerd zijn op het administreren van standen, , zijn nieuwe pensioenadministraties gebaseerd op andere uitgangspunten: op een feitenadministratie of op een eventadministratie. Wat zijn de overeenkomsten en verschillen tussen deze drie soorten administraties? En wat betekent dat voor de ontwikkeling en het onderhoud?
Ben je architect of systeemontwerper? Je krijgt inzicht in de onderliggende uitgangspunten en werking van pensioenadministraties. Je zult de specifieke voordelen en aandachtspunten van standen-, feiten en eventadministraties begrijpen.
Ben je migratieconsultant? Je krijgt inzicht in het conceptuele model van standen-, feiten- en eventadministraties en hoe deze gemigreerd kunnen worden.
Dit artikel is de tweede in een reeks van vier. In het eerste deel legden we een aantal belangrijke concepten uit die specifiek van belang zijn bij pensioenadministraties: afgeleide gegevens en terugwerkende kracht mutaties. In dit tweede artikel gaan we in op de conceptuele datamodellen van een standen-, feiten- en eventadministratie. Het derde deel in deze artikelenserie vergelijkt de drie administraties onderling. Het laatste en vierde deel geeft aan welke specifieke uitdagingen er zijn om van een standenadministratie te migreren naar een eventadministratie.
Om een dieper begrip te krijgen in hoe de verschillende administraties werken, beschrijven we in dit artikel de conceptuele datamodellen.
Standenadministratie
De standenadministratie is een administratie waarbij naast de feiten en gebeurtenissen ook de afgeleide / berekende gegevens worden vastgelegd, de standen. Meestal zijn deze afgeleide gegevens vanuit het oogpunt audit en reproduceerbaarheid opgenomen in de administratie. Het vastleggen van de afgeleide gegevens geeft ook een performance voordeel doordat de afgeleide gegevens niet opnieuw berekend hoeven te worden.
Onderstaande figuur geeft een voorbeeld van een conceptueel datamodel van een standenadministratie. Hierin zijn de typische pensioen specifieke klasses opgenomen, zoals de deelnemer, werkgever, reglement, dienstverband, etcetera. Voorbeelden van deze afgeleide/berekende gegevens zijn: de grondslag, de opgebouwde pensioenaanspraken, de verwachte aanspraken op pensioendatum, enz.
Figuur 1: conceptueel datamodel van een standenadministratie
In een standenadministratie is verwerken van een TWK-mutatie bewerkelijker en complexer, vergeleken met de twee andere type administraties. Op dat moment moeten de afgeleide gegevens (de standen) worden berekend en vaak worden extra controles (vier-ogen) uitgevoerd.
Een ander probleem is dat je in een standen administratie ook niet meer weet wat de stand op een moment in het verleden was met de gegevens die op dàt moment bekend waren. Het is niet mogelijk om standen te (her-)berekenen met of zonder een bepaalde TWK mutatie. Standen worden berekend met de meest recente informatie. De informatie wanneer welke informatie in de administratie is verwerkt, is meestal niet opgenomen in een standen administratie.
Feitenadministratie
Een feitenadministratie slaat alleen de feiten op die binnenkomen. Geen enkele stand of afgeleid gegeven wordt opgeslagen. Het verwerken van TWK’s is dan heel simpel. Omdat je de afgeleide gegevens niet opslaat, hoef je die ook niet meer te corrigeren bij een TWK.
Het conceptuele datamodel van een feitenadministratie lijkt sterk op die van een standen administratie, echter zonder de afgeleide gegevens. Zie onderstaande figuur.
Figuur 2: conceptueel datamodel van een feitenadministratie
In een feitenadministratie kan je de afgeleide gegevens op ieder moment opnieuw berekenen met de TWK mutaties die bekend waren op een ander moment. Dit wordt weergegeven in onderstaande figuur. Deze figuur geeft een salarisverhoging weer die vandaag binnenkomt en verwerkt wordt, maar in gaat in het verleden, in dit voorbeeld vijf perioden terug.
Figuur 3: Het principe van een feitenadministratie
De consequentie hiervan is dat je van ieder attribuut je moet bijhouden wanneer die van kracht is geworden (gebeurtenisdatum) en wanneer die in het systeem is verwerkt (verwerkingsdatum). Dit wordt een timestamp genoemd. Ieder attribuut bestaat nu uit een tijdlijn van meerdere waarden en bij iedere waarde is een gebeurtenisdatum en een verwerkingsdatum vastgelegd, zie onderstaande figuur.
Figuur 4: Timestamps en tijdlijnen van attributen
Als je de historie van ieder attribuut opslaat, kan je de bekende feiten van de deelnemer op ieder moment bepalen. Wat weet ik nu van deze deelnemer? Dan moet je alle mutaties meenemen. Wat wist ik vorige maand van deze deelnemer? Dan moet je alle mutaties met een verwerkingsdatum tot vorige maand meenemen. En dat leidt tot een ander ‘feitenboek’ van die deelnemer. Met een feiten administratie kan je allerlei situaties uitrekenen: de pensioenrechten op ieder moment, met de kennis van de mutaties van een ander moment.
Door de standen niet meer op te slaan, is de verwerking van TWK mutaties veel simpeler. Én je krijgt de mogelijkheid om met een subset van de mutaties tot een opgegeven datum te rekenen. Daar staat tegenover dat iedere TWK mutatie met een gebeurtenisdatum en een verwerkingsdatum opgeslagen moet worden.
Eventadministratie
Een administratie die gebaseerd is op een heel ander conceptueel datamodel is een eventadministratie. Net als bij een feitenadministratie worden bij eventadministraties geen afgeleide gegevens vastgelegd. Met betrekking tot de pensioen gerelateerde gegevens echter, slaat een eventadministratie al deze pensioen gerelateerde gegevens op in een standaard formaat: namelijk als mutatie / event. De administratie is hiermee nog veel simpeler, er worden namelijk alleen events geregistreerd. Per event moet je dan denken aan: dezelfde gebeurtenisdatum en verwerkingsdatum als bij een feiten administratie, en daarnaast de naam van het gewijzigde kenmerk(en) en de bijbehorende nieuwe waarde(n).
Figuur 5: Conceptueel datamodel van een eventadministratie
Het idee hierachter is dat de rekenkern bij het doorrekenen van de events, de pensioen gerelateerde gegevens op basis van de events opbouwt en doorrekent. Daar zit het verschil met een feiten administratie: bij een feiten administratie krijgt de rekenkern de pensioen gerelateerde gegevens als input, en bij een event administratie krijgt de rekenkern de events als input (waar de pensioen gerelateerde gegevens onderdeel van zijn).
In een eventadministratie leidt de rekenkern de pensioen gerelateerde gegevens af uit de events om vervolgens de rechten te berekenen. De pensioen gerelateerde gegevens zijn opgeslagen in de events, en deze events worden eerst door de rekenengine omgezet tot de bekende pensioen gerelateerde gegevens (deelnemer, werkgever, dienstverband, reglement en pensioenrechten). Het onderliggende uitgangspunt van een event administratie is dat de events on-the-fly kunnen worden omgezet naar pensioen gerelateerde gegevens en dat de performance hiervan geen issue is.
Dit soort administraties zijn niet nieuw en zijn beter bekend als ‘event sourcing’. Event administraties kunnen tot een enorme versimpeling van de administratie leiden. Daar staat dan wel tegenover dat de rekenkern wat complexer wordt.
Een andere consequentie van de keuze voor event administratie is het zoeken in de administratie naar verbanden in de portefeuille lastiger is, omdat de gegevens opgeslagen zijn als event. Als voorbeeld nemen we het selecteren van alle gescheiden deelnemers. Omdat de gegevens opgeslagen zijn als event, is er geen attribuut deelnemer.scheidingsdatum waarop een selectie gemaakt kan worden. Event administraties lossen dit op door alle pensioengerelateerde gegevens van de deelnemers als afgeleid gegeven op te slaan in een ‘query database’, zoals aangegeven in onderstaande figuur.
Figuur 6: Alle pensioen gerelateerde gegevens als afgeleid query model
Tot slot
In dit tweede artikel hebben we het conceptuele datamodel van standen-, feiten- en eventadministraties met elkaar vergeleken. In het volgende artikel vergelijken we de drie soorten administraties en in het daaropvolgende artikel gaan we in op de impact voor migraties.
Plaats je vraag of opmerking of neem vrijblijvend contact op.
Wij maken graag kennis om te sparren over pensioenadministraties.