3 Processen & informatiestromen – Solidaire Premieregeling

3.1 Inleiding

Deze paragraaf beschrijft de noodzakelijke informatie-uitwisseling tussen betrokken partijen die nodig is om op een robuuste wijze invulling te geven aan de uitvoering van de solidaire premieregeling¹.

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 6 met name 0 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.

Twee alternatieve invulpatronen in bericht 2 — gebruik één van beide

Bericht 0001b ondersteunt twee wederzijds uitsluitende invulpatronen per pension.scheme:

SPR-route — de cashflow wordt direct opgenomen onder pension.scheme als financialTransaction.cashflow (optioneel, 0..1). Cohortuitsplitsing verloopt via pension.cohort, inclusief netDate op cohortniveau. Wanneer cohortuitsplitsing wordt toegepast, sluit de som van de cohortbedragen aan op het bedrag op regelingniveau: scheme.netAmount = som(cohort.netAmount). Zie §6.3.1 voor de verbandscontroles.

FPR-route — de cashflow wordt opgenomen per beleggingsportefeuille via pension.scheme → investment.portfolio → financialTransaction.cashflow. In dit patroon zijn netAmount en netDate verplicht op portfolioniveau.

De twee patronen zijn wederzijds uitsluitend: aanwezigheid van investment.portfolio sluit directe financialTransaction.cashflow onder pension.scheme uit, en aanwezigheid van pension.cohort sluit gebruik van investment.portfolio uit.

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:

1. 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.

2. 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: De cashflow kan gesaldeerd (netAmount) of uitgesplitst (contributionAmount / withdrawalAmount) worden aangeleverd. 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. Instroom en uitstroom kunnen separaat worden aangeleverd of als gesaldeerde cashflow. Bij separate aanlevering dienen ook de inflow en outflow datum te worden gevuld, bij een gesaldeerde aanlevering is dat alleen de cashflow datum.

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).

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.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.

Omgang met lege cohorten

De standaard staat twee benaderingen toe voor cohorten met waarde 0:

1. Meesturen met expliciete waarde 0 — maakt het onderscheid duidelijk tussen “waarde is 0” en “data ontbreekt”.
2. Weglaten — houdt berichten compact.

Partijen moeten beide varianten kunnen verwerken. Afspraken hierover worden vastgelegd tussen ketenpartijen (TOM / SLA). Bij grote berichten kan het chunking-mechanisme uitkomst bieden. Zie GitHub issue #100.

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 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.

---

1. Let op: het SPR-gegevensmodel, wat feitelijk een decompositiemodel is, kan ook voor de gegevensuitwisseling van FPR worden gebruikt. Dit ligt voor de hand als de uitvoering van een FPR-regeling niet unitised is maar ook is terug te voeren op rendementsdecompositie, zie 4.6. ↩