3 Processen & informatiestromen – Solidaire Premieregeling
3.1 Inleiding
Deze paragraaf beschrijft de informatie-uitwisseling tussen betrokken partijen die nodig is om op een robuuste wijze invulling te geven aan de uitvoering van de solidaire premieregeling1.
In Figuur 1 hieronder wordt de informatie-uitwisseling tussen de betrokken partijen schematisch weergegeven. De beleggingsadministrateur (BA) voorziet de pensioenuitvoeringsorganisatie (PUO) onafhankelijk van de fiduciair manager (FM) van informatie en kan tevens een toetsende rol vervullen. Indien daar niet voor wordt gekozen en de fiduciair ook de leidende beleggingsadministratie voert zal informatiestroom 2 van de FM naar de PUO lopen.
Figuur 1 - Scope informatie-uitwisseling SPR
Legenda (informatiestromen/berichten):
1a - Vermogens per cohort
1b - Cashflow (stortingen en onttrekkingen
1c - Pensioenprojecties /geprojecteerde kasstromen
2 - Rendementen en vermogens
Hieronder worden de rollen van de diverse partijen in het schema nader toegelicht:
-
De pensioenuitvoeringsorganisatie (PUO) heeft de verantwoordelijkheid om conform de door de pensioenuitvoerder vastgestelde toedelingsregels rendementen toe te delen naar de persoonlijke pensioenvermogens van deelnemers (eventueel via een collectieve uitkeringsfase) de solidariteitsreserve, het eventuele compensatiedepot en mogelijke andere reserves.
Op basis van deze persoonlijke pensioenvermogens worden, conform de uitgangspunten van de pensioenuitvoerder, uitkeringen bepaald en geprojecteerd.
De pensioenvermogens en geprojecteerde uitkeringen worden naar cohorten, aan de FM en/of de BA geleverd. De PUO verwerkt premies, uitkeringen en mutaties in het deelnemersbestand en verzorgt de deelnemerscommunicatie. -
De fiduciair manager (FM) ondersteunt de pensioenuitvoerder bij de totstandkoming van het integrale beleggingsbeleid, draagt zorg voor de uitvoering van dit beleggingsbeleid en stuurt daarbij de operationele vermogensbeheerders aan. De FM zal ook een (schaduw) beleggingsadministratie voeren. Bij grote pensioenuitvoerders zonder FM is de pensioenuitvoerder zelf verantwoordelijk voor het aansturen van zowel interne als externe vermogensbeheerders.
-
De operationele vermogensbeheerders beheren onderdelen van de portefeuille en worden daarbij aangestuurd door de FM. Het is mogelijk dat (voor onderdelen) de FM en de operationeel vermogensbeheerder tot dezelfde organisatie behoren.
-
De beleggingsadministrateur/asset serviceprovider (BA; doorgaans aanvullende dienstverlening van de custodian) verzorgt de onafhankelijke beleggingsadministratie voor de pensioenuitvoerder. De BA berekent het totale rendement van de beleggingen en (indien nodig) het rendement van verschillende beleggings(sub)portefeuilles en levert dit aan de PUO. Zoals hierboven aangegeven kan de FM ook de leidende beleggingsadministratie voeren. De beleggingsadministratie wordt gevoed vanuit de afwikkeling van mutaties in de portefeuille, uitgevoerd door de operationele vermogensbeheerders. Met de FM wordt indien gewenst deze administratie gereconcilieerd. De BA draagt ook vaak zorg voor het opstellen van toezichthoudersrapportages of onderdelen hiervan.
3.2 Informatiestromen SPR
De informatiestromen voor SPR-producten tussen de FM, de BA en de PUO zijn:
-
Informatie van de PUO over vermogen, in- en uitstroom van geld- en geprojecteerde af te dekken kasstromen (eventueel per cohort) om de FM en BA in staat te stellen hun rollen te vervullen.
-
Informatie van de BA of FM over rendementen die de pensioenuitvoerder nodig heeft om te komen tot een juiste toedeling aan de deelnemers.
De informatiestroom van de PUO naar FM/BA (stroom 1) is opgedeeld in een drietal berichten: 1a (vermogen), 1b (in- en uitstroom) en 1c (geprojecteerde uitkeringen). Waarde en rendementsinformatie wordt via bericht 4. Rendementsinformatie aan de PUO gezonden.
Deze berichten worden hieronder nader uitgewerkt.
3.2.1 Bericht 1. Vermogen (1a)
Op periodieke (naar verwachting maandelijkse) basis ontvangt de FM over een pensioenuitvoerder (geïdentificeerd door puvCode) per regeling (geïdentificeerd door refKey) het totale pensioenvermogen (startAmount) bij aanvang van de periode (startDate).
Naast de informatie op totaalniveau kan de fiduciair ook per (leeftijds-)cohort (geïdentificeerd door refKey) het pensioenvermogen (startAmount) ontvangen. Zo kan bijvoorbeeld voor het leeftijdscohort 25-29 jaar het totaal van de persoonlijke pensioenvermogens bij aanvang worden ontvangen.
Met de cohortinformatie kan de FM desgewenst een totaalberekening maken en de aansluiting bij de geleverde informatie op totaal/collectief niveau toetsen aan het beleid van het fonds. Dit is nuttig voor een robuuste overdracht en audittrail afhankelijk van afspraken die partijen maken. Conform het beleid van de pensioenuitvoerder kan bij (grote) afwijkingen herbalancering wenselijk zijn. Deze informatie kan behalve aan de FM desgewenst ook worden verstrekt aan de BA/asset serviceprovider om deze ook in staat te stellen toetsings- en rapportage-activiteiten uit te voeren met behulp van de leidende beleggingsadministratie.
Allocatie naar Portefeuilles
Naast het totale vermogen kan de PUO in dit bericht ook de gewenste allocatie van dit vermogen over verschillende portefeuilles doorgeven aan de vermogensbeheerder. Dit biedt de vermogensbeheerder belangrijke stuurinformatie om te kunnen handelen conform de door de PUO gehanteerde normportefeuille.
Deze allocatie-informatie kan zowel op totaalniveau (onder de pensioenregeling) als op cohortniveau worden meegegeven. Het betreft optionele velden waarmee de exposure naar bijvoorbeeld een rendements- of een beschermingsportefeuille kan worden gespecificeerd, zowel in een absoluut bedrag (startExposureAmount) als in een percentage (startExposurePercentage). Hoewel voor de sturing met name het totaalniveau van belang is, kan de informatie op cohortniveau nuttig zijn voor rapportagedoeleinden.
Functionele uitwerking naar bericht: zie hoofdstuk 6 en met name 6.4.2 Berichtstructuur 1. Vermogen (0001a).
De actuele berichtstructuur vindt u op GitHub onder “Wiki/Berichtenoverzicht”
Voor de datumconventies bij startDate zie de toelichting bij financialInformation.reportingPeriod in §6.3.
3.2.2 Bericht 2. Cashflow (1b, in- en uitstroom)
Op periodieke (naar verwachting maandelijkse) basis ontvangt de FM over een pensioenuitvoerder (puvCode) per regeling (refKey) de instroom (contributionAmount) in de periode (op de contributionDate) en de uitstroom of als gesaldeerde cashflow (netAmount) in de periode (op de netDate).
Naast de informatie op totaalniveau kan de FM ook per (leeftijds-)cohort (refKey) de instroom (contributionAmount) en uitstroom (withdrawalAmount) of als gesaldeerde cashflow (netAmount) over de periode (startDate tot endDate) worden ontvangen.
De in- en uitstroom bevat naast premies, waardeoverdrachten en uitkeringen ook de verschuivingen over cohorten als daar sprake van is. Een cohort kan ook een geboortejaar zijn. Een voorbeeld is het persoonlijke pensioenvermogen van deelnemers die van cohort 25-29 jaar naar cohort 30-34 jaar verschuiven. Ook het ‘cohort’ solidariteitsreserve, het ‘cohort’ compensatiedepot en mogelijk andere reserves zullen hierbij betrokken worden.
Met de cohortinformatie kan de FM desgewenst een totaalberekening maken en de aansluiting bij de geleverde informatie op totaal/collectief niveau toetsen aan het beleid van het fonds. Dit is nuttig voor een robuuste overdracht en audittrail afhankelijk van afspraken die partijen maken. Deze informatie kan behalve aan de FM desgewenst ook worden verstrekt aan de BA/asset serviceprovider om ook deze in staat te stellen toetsings- en rapportage-activiteiten uit te voeren met behulp van de leidende beleggingsadministratie.
Invulpatronen in bericht 2. Figuur 1a laat zien hoe bericht 2 per regeling is opgebouwd.
Figuur 1a — Bericht 2 Cashflow (0001b): SPR- en FPR-route Volledige weergave (SVG)
De figuur toont alleen de velden die voor de routes van belang zijn; de volledige berichtstructuur staat in §6.4.3.
- Grijs: de cashflow direct onder de regeling. Die is er in beide routes. In de FPR-route staat hier het totaal van de portefeuilles.
- Blauw: de SPR-route. De cashflow kan daarnaast per cohort worden uitgesplitst; de som van de cohorten sluit aan op de cashflow onder de regeling.
- Groen: de FPR-route. Per beleggingsportefeuille staat precies één cashflow.
Een regeling gebruikt óf de uitsplitsing per cohort, óf die per beleggingsportefeuille, nooit beide. Vetgedrukte velden zijn verplicht, cursieve optioneel: in elk cashflowblok zijn netAmount en netDate verplicht. Voor de berichten 2, 3 en 4 samen zie §3.2.5.
Toepassingen van het Cashflowbericht
De standaard biedt de flexibiliteit om dit bericht voor twee verschillende doeleinden te gebruiken, die in de praktijk naast elkaar kunnen bestaan:
-
Prospectieve Toepassing (Vooruitkijkend)
-
Doel: Liquiditeitsbeheer. In deze toepassing wordt een schatting van de te verwachten netto kasstroom voor de komende periode doorgegeven. Het gesaldeerde bedrag (
netAmount) dient als input voor de daadwerkelijke maandelijkse (de)allocatiebetaling tussen de PUO en de vermogensbeheerder. -
Kenmerken: Doorgaans een gesaldeerd bedrag op regeling-totaalniveau.
-
-
Retrospectieve Toepassing (Terugkijkend)
-
Doel: Analyse en verantwoording. Hierbij worden de daadwerkelijk gerealiseerde kasstromen uit een afgesloten periode gerapporteerd. Deze informatie staat los van de maandelijkse allocatiebetaling.
-
Kenmerken: Het gesaldeerde bedrag (
netAmount) is verplicht; de uitsplitsing (contributionAmount/withdrawalAmount) kan daarnaast worden aangeleverd voor rapportagedoeleinden. Deze variant leent zich voor het verstrekken van details op cohortniveau.
-
De FM draagt zorg voor de belegging van instroom of het vrijmaken van middelen om uitstroom te financieren. netAmount en netDate zijn verplicht. Op de netDate wisselen partijen het geld. Instroom en uitstroom kunnen daarnaast afzonderlijk worden aangeleverd voor rapportagedoeleinden.
De berekeningswijze van de hoogte van de instroom of de uitstroom is afhankelijk van de voorkeur van de pensioenuitvoerder en werkwijze van de PUO. De FM hoeft niet geïnformeerd te worden over de berekeningsmethodiek en ook niet op welke periode de gegevens betrekking hebben. Beleggingen kunnen immers nooit met terugwerkende kracht uitgevoerd kunnen worden. Voor de audittrail kan het wenselijk zijn om de periode wel vast te leggen in de informatie-uitwisseling
Functionele uitwerking naar bericht: zie hoofdstuk 6 met name 6.4.3 Berichtstructuur 2. Cashflow (0001b).
De actuele berichtstructuur vindt u op GitHub onder “Wiki/Berichtenoverzicht”
3.2.3 Bericht 3. Pensioenprojectie (1c, geprojecteerde uitkeringen)
Op periodieke (verwachting is maandelijkse) basis (projectionDate) ontvangt de FM van een pensioenuitvoerder (puvCode) per regeling (refKey) en per (leeftijds-)cohort (refKey) de geprojecteerde uitkeringen (amount) op basis van de opgebouwde vermogens naar toekomstige periodes (expectedPensionPaymentDate).
In FPR kunnen de geprojecteerde uitkeringen in plaats van per cohort ook per beleggingsportefeuille worden aangeleverd. Zie §3.2.5 en, voor FPR, §4.3.3.
Bijvoorbeeld voor het cohort 25-29-jarigen betreft dit (voornamelijk) het projecteerde ouderdomspensioen over 39 jaar (uitgaande van de reglementaire pensioenleeftijd). In de informatiestroom per 31 december 2022 wordt de eerste (uitkerings)kasstroom voor dit cohort dan in 2061 verwacht. Deze informatie is belangrijk voor de FM om (aansturing van) de beschermingsportefeuille in te richten en de beoogde beschermingsrendementen te genereren. De gewenste bescherming per leeftijdscohort (bijvoorbeeld 25% voor 25-29 jaar en 100% vanaf 70-jaar) is bepalend voor de af te dekken rentegevoeligheid. Het volstaat niet langer om alleen een projectie van uitkeringen te baseren op de gehele populatie in een pensioenregeling omdat het renterisico niet langer door de complete deelnemerspopulatie wordt gedeeld. Desgewenst kunnen ook het ‘cohort’ solidariteitsreserve, eventueel het ‘cohort’ compensatiedepot en mogelijk andere reserves beschermingsrendement toebedeeld krijgen. Dan zal voor deze cohorten een (fictief) kasstroomprofiel moeten worden opgesteld. Naast de individuele geprojecteerde uitkeringen per cohort (inclusief de reserves) kan ook een totale geprojecteerde uitkering over de hele populatie worden aangeleverd (amount). Dit is gelijk aan de som van de geprojecteerde uitkeringen over alle cohorten per toekomstige periode (expectedPensionPaymentDate).
Tenslotte bevat de gegevensuitwisseling de af te dekken kasstromen per regeling (hedgedExpectedPensionPaymentAmount) per toekomstige periode. Dit is gelijk aan de som van de gewogen geprojecteerde uitkeringen per cohort. De wegingsfactor is gelijk aan het percentage bescherming per cohort. Bijvoorbeeld: de bescherming van het cohort 25-29 jaar is 25% en de bescherming van het cohort vanaf 70-jaar is 100%. De geprojecteerde uitkeringen van het cohort 25-29 jaar worden met 25% vermenigvuldigd en opgeteld bij de volledige geprojecteerde uitkeringen van het cohort vanaf 70-jaar vermenigvuldigd met 100%. Op deze manier ontstaat een profiel van de af te dekken kasstromen. Deze uitwisseling vermijdt misverstanden ten aanzien van af te dekken kasstromen en kan desgewenst een toets in het proces introduceren.
Functionele uitwerking naar bericht: zie hoofdstuk 6 en met name 6.4.4 Berichtstructuur 3. Pensioenprojectie (0001c)
De actuele berichtstructuur vindt u op GitHub onder “Wiki/Berichtenoverzicht”
Voor de eenduidige toepassing van projectionDate en expectedPensionPaymentDate zie de toelichting bij financialInformation.reportingPeriod in §6.3.
Voor cohorten met waarde 0 geldt de regel in §6.3; die geldt voor alle berichten met cohorten.
3.2.4 Bericht 4. Rendementsinformatie (2, Informatiebehoefte PUO)
Informatiestroom van BA/asset serviceprovider naar de PUO (stroom 2 uit Figuur 1) in de SPR.
De PUO heeft voor het uitvoeren van de solidaire premieregeling periodiek (naar verwachting maandelijks) informatie nodig over het behaalde rendement.
Periodiek ontvangt de PUO over de periode (die loopt van startDate tot endDate) voor een pensioenuitvoerder (puvCode) per regeling (refKey) en per portefeuille (refKey) de waarde aan het begin van de periode (startAmount), de waarde aan het einde van de periode (endAmount) en het rendement in portefeuille valuta en (eventueel) uitgedrukt als percentage (returnPercentage). De PUO draagt zorg voor de toedeling van rendementen naar deelnemers op basis van portefeuillerendementen. Optioneel kunnen ook per cohort in de regeling (refKey) pensioenvermogen (startAmount), beschermingsrendement (protectionReturnAmount) en overrendement (excessReturnAmount) worden gedeeld met de PUO. Of deze optionele elementen worden uitgewisseld hangt af van de overeengekomen rollen en verantwoordelijkheden tussen de samenwerkende partijen. Daarbij is het uitgangspunt dat de PUO de verantwoordelijkheid heeft om conform de door de pensioenuitvoerder vastgestelde toedelingsregels rendementen toe te delen naar de persoonlijke pensioenvermogens van deelnemers, de solidariteitsreserve, een eventueel compensatiedepot en mogelijk andere reserves.
De uitsplitsing per portefeuille geldt in SPR en FPR; elke regeling heeft minstens één portefeuille. Zie §3.2.5.
De BA/asset serviceprovider verstrekt de daartoe benodigde informatie aan de PUO en baseert zich daarbij op de onafhankelijke beleggingsadministratie. In een alternatief governance model kan de FM deze informatie aan de PUO verstrekken.
Indien de solidaire premieregeling is ingericht met indirect (theoretisch) beschermingsrendement dan volstaat in principe informatie over het totale rendement. De toedeling van beschermingsrendement is dan namelijk niet afhankelijk van gerealiseerd rendement. Het door de PUO toe te delen overrendement kan de PUO berekenen op basis van het totale rendement verminderd met het toegedeelde indirect (theoretische) beschermingsrendement.
Wanneer de solidaire premieregeling het toe te delen beschermingsrendement baseert op het direct (feitelijk) behaalde rendement dan moet de PUO beschikken over een onderverdeling van het behaalde rendement. De BA/asset serviceprovider dient dan het rendement aan te leveren voor subportefeuilles (en optioneel naar cohorten), waarbij in ieder geval een onderscheid gemaakt wordt tussen de beschermingsportefeuille en de overrendementsportefeuille. Afhankelijk van de wijze waarop feitelijk beschermingsrendement wordt toebedeeld naar individuele deelnemers kan een verdere uitsplitsing van de beschermingsportefeuille naar subportefeuilles wenselijk zijn.
Een (verdere) uitsplitsing van portefeuilles kan bovendien wenselijk zijn ten behoeve van communicatie over behaalde rendementen naar deelnemers, reconciliatiedoeleinden en eventuele wettelijke verplichtingen. Dit is afhankelijk van de door de pensioenuitvoerder gewenste opzet.
De informatie-uitwisseling ten behoeve van de solidaire regeling gebaseerd op het direct (feitelijk) behaalde rendement kan tevens gebruikt worden voor een uitwisseling bij een specifieke uitvoeringsvariant van de flexibele premieregeling. Deze keuze zal met name gemaakt worden door partijen die voor de flexibele premieregeling een vergelijkbare wijze van toedeling van rendementen hanteren als bij de solidaire premieregeling die uitgaat van feitelijke rendementen. Voor elk cohort wordt dan aan de PUO een feitelijk beschermingsrendement en overrendement geleverd als bedrag en optioneel als percentage.
Rendementsinformatie op meerdere niveaus in één bericht
Binnen één bericht 4 kunnen meerdere typen rendement worden meegegeven: totaalrendement (total), beschermingsrendement (matching) en overrendement (return). De refKey identificeert per blok om welk type rendement of welke portefeuille het gaat. Het is niet nodig om per type een apart bericht te versturen. De standaard legt geen formele relatie vast tussen de drie typen; de veronderstelling dat matching + return = total wordt niet afgedwongen.
Zie GitHub issue #109.
Functionele uitwerking naar bericht: zie hoofdstuk 6 met name 6.4.5 Berichtstructuur 4. Rendementsinformatie (00002)
Een grafisch overzicht van de berichtstructuur vindt u op GitHub onder “Wiki/Berichtenoverzicht”. De JSON-schema’s en deze handleiding zijn echter leidend.
3.2.5 SPR- en FPR-route in de berichten 2, 3 en 4
In de berichten 2, 3 en 4 kan de informatie onder een regeling (pension.scheme) op twee manieren worden uitgesplitst: per cohort, via pension.cohort (de SPR-route), of per beleggingsportefeuille, via investment.portfolio (de FPR-route). Daarnaast heeft elk van deze berichten gegevens direct onder de regeling die in beide routes gelden.
Figuur 1b zet de drie berichten naast elkaar, in dezelfde kleuren als Figuur 1a: grijs geldt voor beide routes, blauw is de SPR-route, groen de FPR-route. Vetgedrukte velden zijn verplicht, cursieve optioneel.
Figuur 1b — Berichten 2, 3 en 4: SPR- en FPR-route naast elkaar Volledige weergave (SVG)
De figuur toont alleen de velden die voor de routes van belang zijn; de volledige berichtstructuren staan in §6.4.3, §6.4.4 en §6.4.5.
Hoe de routes zich verhouden. Een regeling gebruikt nooit beide uitsplitsingen tegelijk: per cohort of per beleggingsportefeuille, niet allebei. In bericht 2 is de uitsplitsing optioneel; de cashflow direct onder de regeling mag ook alleen staan. In bericht 3 wordt precies één uitsplitsing gebruikt. De gegevens direct onder de regeling gelden in beide routes; in de FPR-route staat daar in de regel het totaal van de portefeuilles. In bericht 4 is de beleggingsportefeuille er in beide routes, en is de uitsplitsing per cohort een optionele aanvulling.
Bericht 2: het geld wisselt op de netDate. In elk cashflowblok zijn netAmount en netDate verplicht; samen vormen zij de gesaldeerde cashinstructie. Op de netDate wisselen partijen het geld. De velden voor in- en uitstroom, contributionAmount, contributionDate, withdrawalAmount en withdrawalDate, zijn optioneel en dienen de rapportage. In het cohort zijn dat alleen contributionAmount en withdrawalAmount. Elke beleggingsportefeuille heeft een eigen netDate; die hoeft niet gelijk te zijn aan de netDate van de cashflow direct onder de regeling. Wordt in de SPR-route per cohort uitgesplitst, dan sluit de som van de cohortbedragen aan op het bedrag op regelingniveau: scheme.netAmount = som(cohort.netAmount). Zie §6.3.1 voor de verbandscontroles.
Bericht 3: projectie per beleggingsportefeuille. De portefeuilletak is bedoeld voor regelingen waarin meerdere beleggingsportefeuilles worden onderscheiden. De betalingen direct onder de regeling zijn regelingtotalen.
Reservevelden alleen in het cohort. reserveIndicator (verplicht), reserveType en reserveDescription staan in pension.cohort en niet op de beleggingsportefeuille, in geen van de drie berichten. Is reserveIndicator = true, dan is reserveType verplicht; reserveDescription is bij 99 (Overige) gewenst en bij de andere codes mogelijk (zie §6.3). Hoe reserves aan beleggingsportefeuilles zijn gekoppeld, is inrichting: zo kunnen bijvoorbeeld vijftien reserves in zes portefeuilles zijn belegd. Die koppeling leggen pensioenuitvoerder en vermogensbeheerder onderling vast; zij gaat niet mee in het bericht.
Zie GitHub issue #113.
Functionele uitwerking naar bericht: zie hoofdstuk 6, met name 6.4.3, 6.4.4 en 6.4.5.