2 Uitgangspunten

In dit hoofdstuk bespreken we de belangrijkste uitgangspunten bij de ontwikkeling, opzet en besturing van de standaard. Dit is vooral gebaseerd op Resultaten onderzoek: Standaard voor data-uitwisseling pensioenuitvoering & vermogensbeheer partijen’’.

2.1 Preambule: Uitgangspunten Standaardisatie VBPUO

Het doel van standaardisatie is een naadloze en efficiënte informatie-uitwisseling tussen alle partijen in de keten. De VBPUO-standaard rust op de volgende uitgangspunten:

• Pragmatisme en flexibiliteit
  De standaard is geen eis tot uniformiteit, maar een raamwerk voor interoperabiliteit. Ketenpartners behouden hun eigen interne processen en systemen. De focus ligt op het stroomlijnen van de externe communicatie.

• Interoperabiliteit als einddoel
  De waarde van de standaard blijkt in de praktijk. De toets: een organisatie moet probleemloos kunnen overstappen naar een andere ketenpartner, zonder noemenswaardige aanpassingen aan de gegevensinterface.

• Beheersbare vrijheidsgraden
  Flexibiliteit is niet onbegrensd. Voor voorspelbaarheid en betrouwbaarheid zijn de toegestane variaties expliciet gedefinieerd en bewust beperkt.

• Gedragen door de keten
  Aanpassingen en variaties ontstaan niet eenzijdig. Ze vragen breed draagvlak om fragmentatie te voorkomen en de waarde van de standaard duurzaam te behouden.

Zo blijft de VBPUO-standaard een gezamenlijk instrument voor efficiëntie, voorspelbaarheid en toekomstbestendige samenwerking in de keten.

2.2 Aanleiding

Pensioenuitvoeringsorganisaties (PUO's) hebben regelmatig informatie nodig van fiduciair managers (FM's) en/of beleggingsadministrateurs (BA's) om de deelnemersadministratie van pensioenregelingen correct uit te kunnen voeren. Anderzijds hebben FM's (en vermogensbeheerders) informatie nodig om de middelen voor verschillende pensioenuitvoerders te kunnen beleggen binnen de kaders van het afgesproken beleggingsbeleid. De benodigde gegevensuitwisseling tussen PUO's, FM's en BA's (en vermogensbeheerders) is naar verwachting in alle gevallen zeer vergelijkbaar.

Met de invoering van de Wtp zal de informatiebehoefte wijzigen en zal de frequentie waarin informatie-uitwisseling gewenst is toenemen. De informatiebehoefte voor PUO's, FM's en BA's voor de dienstverlening aan pensioenuitvoerders komt in de basis sterk overeen. Eventuele verschillen in de informatie-uitwisseling zullen met name afhankelijk zijn van het type regeling dat wordt uitgevoerd.

In de opbouwfase van de flexibele premieregeling (FPR) zal de informatiebehoefte grotendeels overeenkomen met die van de huidige 'defined contribution' regelingen, mogelijk aangevuld met gegevens over risicodelingsreserve. Wat betreft de uitwisseling van gegevens tijdens de collectieve uitkeringsfase, zal deze in veel opzichten vergelijkbaar zijn met de uitkeringsfase van de solidaire premieregeling.

Voor de solidaire premieregeling (SPR) zal een geheel nieuwe datastroom moeten worden opgezet, zowel voor de opbouw-, als de uitkeringsfase. Er zal een strakkere aansluiting moeten zijn tussen het fondsvermogen dat door de FM wordt belegd en de collectieve administratie van persoonlijke pensioenvermogens door de PUO.

2.3 Buiten scope

Buiten scope van de uitwerking van de informatie-uitwisseling vallen:

• Contractuele afspraken met betrekking tot het totale proces rondom vermogensbeheer tussen partijen. De standaard voorziet in de noodzakelijke informatie-uitwisseling, de gegevensbehoefte, tussen PUO's en vermogensbeheerpartijen op de verschillende procesmomenten. De standaard voorziet in de gegevensbehoefte voor zowel Solidaire Premieregeling (SPR) als Flexibele Premieregeling (FPR). De exacte invulling van de gegevensuitwisseling tussen partijen wordt echter bepaald door contractuele afspraken tussen de samenwerkende pensioenuitvoerder en zijn vermogensbeheerpartners

• Processen die al lopen en in de basis niet veranderen, zoals de reconciliatie van de beleggingsadministratie tussen de FM en de BA/asset serviceprovider.

• Informatie die niet hoeft te worden uitgewisseld omdat deze slechts door één partij in de keten wordt gebruikt.

• Informatie met betrekking tot beleggingsbeleid, bescherming en toedelingsregels en cohortsamenstelling. Deze informatie wordt door de pensioenuitvoerder met betrokken partijen gedeeld via diverse beleidsdocumenten, zoals het strategisch beleggingsbeleid, het jaarplan beleggingen en beleggingsrichtlijnen.

• Informatie-uitwisseling tussen pensioendeelnemer, pensioenuitvoerder en/of PUO.

Toedeling van rendementen aan deelnemers.

• Informatie over kosten:

• Vooralsnog is er geen uitgekristalliseerd en eenduidig proces in samenwerkingsketens om te komen tot de kostentoedeling (en tevens de communicatie over kosten). De ervaringen tot dusverre lijken aan te geven dat dit lastig is te standaardiseren. Verschillende partijen maken verschillende afwegingen ten aanzien van verwerking, fijnmazigheid, feitelijk versus begroot, treffen van voorzieningen, tijdigheid, rolverdeling in de aanlevering van verschillende onderdelen etc.

• Verwacht wordt dat bestaande processen om de DNB-jaarstaat J402 samen te stellen de basis blijven vormen voor de informatie-uitwisseling over kosten, voor zowel de SPR als de FPR

• Inzicht in/ doorzicht naar de daadwerkelijke beleggingen meestal aangeduid met “Lookthrough” informatie. Ad hoc verzoeken om aanvullende informatie bij BA/asset serviceprovider of FM kunnen nodig zijn maar vallen niet onder reguliere gegevensuitwisseling in de context van de uitwisseling zoals beschreven in deze handleiding.

• Eventuele specifieke Informatie-uitwisseling benodigd voor een premie-uitkeringsovereenkomst zoals aangeboden door verzekeraars.

• De periodiciteit van de uitwisseling. Niet elk proces binnen de pensioenuitvoering leidt tot noodzakelijke acties binnen vermogensbeheer. De gevolgen van processen die wel tot vermogensbeheeracties leiden moeten echter wel op periodieke basis worden uitgewisseld. De periodiciteit van de uitwisseling van de daarmee samenhangende berichten is flexibel invulbaar tussen partijen.

• Dekkingsgraad / coverage ratio. De berekening en rapportage van de dekkingsgraad valt onder de verantwoordelijkheid van de PUO of BA. De VBPUO-standaard voorziet hier niet in een apart bericht. Zie GitHub issue #118.

• Taakverdeling/Rolverdeling. De wijze waarop partijen samenwerken, de rolverdeling of governance, maakt geen onderdeel uit van de standaard.

2.4 Uitgangspunten gegevensuitwisseling

Om de gegevensuitwisseling zo praktisch mogelijk vorm te geven gelden de navolgende uitgangspunten:

• De gegevensstandaard is bruikbaar voor elke (governance)verdeling tussen pensioenuitvoering en vermogensbeheer.

• Indien de asset serviceprovider een onafhankelijke rol vervult als leidende BA en/of de uitvoering van beleid toetst, dan ontvangt deze dezelfde informatie als de FM om onafhankelijk te kunnen rapporteren aan pensioenfondsen over het gevolgde en gerealiseerde beleggingsbeleid in relatie tot de doelstellingen.

• De FM-rol ontvangt de benodigde informatie om het collectieve vermogen conform de kaders van het beleggingsbeleid te beleggen, rekening houdend met in- en uitstroom (door premies, uitkeringen en waardeoverdrachten) en geprognosticeerde uitkeringen.

• De PUO geeft de deelnemer inzicht in de ontwikkeling van voor de pensioenuitkering bestemd vermogen (SPR) en/of voor pensioen bestemd kapitaal (FPR) inclusief de toedeling van rendementen en verwachte uitkeringen.

• Partijen krijgen de voor hen bestemde gegevens rechtstreeks van de verzendende partij. Een FM hoeft dus bijvoorbeeld de van een PUO ontvangen informatie niet door te sturen aan een andere partij die door het pensioenfonds is geselecteerd, zoals een asset serviceprovider en/of een Liability-Driven Investment (LDI) manager

• Eenmaal geaccepteerde berichten worden niet eenzijdig gecorrigeerd. Berichten die door de ontvangende partij zijn geaccepteerd, kunnen direct leiden tot onomkeerbare operationele processen, zoals beleggingstransacties of de toedeling van rendementen aan deelnemers. Indien een verzendende partij een fout ontdekt in een reeds geaccepteerd bericht, is afstemming met de ontvangende partij verplicht alvorens een eventueel correctiebericht wordt verstuurd. De specifieke procedures hiervoor zijn verder toegelicht in paragraaf 4.6.

2.5 Verduidelijking uitgangspunten gegevensuitwisseling

Bij de inhoudelijke consultatieronde in mei/juni 2023 kwamen enkele kwesties regelmatig terug die niet tot aanpassingen in het inhoudelijk deel van het rapport leidde maar wel verduidelijkt moesten worden om misverstanden te voorkomen.

• Gegevensmodel: Het gegevensmodel bevat slechts de gegevens die nodig zijn om de benodigde informatie rond het beleggen van pensioengelden te kunnen verzenden en/of te ontvangen en informatie rondom gerealiseerde beleggingsresultaten te kunnen delen.

• Rollen (niet voorschrijvend): Ter ondersteuning van de uitwerking van het gegevensmodel wordt gegevensuitwisseling tussen diverse partijen in de keten beschreven. Om het begrip van het gegevensmodel te ondersteunen is hierbij zowel voor de SPR als voor de FPR een rolverdeling geschetst in de keten waarbij het governance model voorziet in bepaalde functiescheidingen. In een alternatieve inrichting kunnen rollen door eenzelfde partij worden uitgevoerd, zo kan de FM ook de leidende beleggingsadministratie voeren. Het is niet de bedoeling van deze handleiding om de vorm van samenwerking tussen partijen en daarmee het governance model voor te schrijven.

• Periodiciteit: Bij de beschrijving van een aantal processen is aangegeven dat deze naar verwachting maandelijkse periodiciteit kennen. Deze periodiciteit wordt niet voorgeschreven. De genoemde uitwisselingsmomenten en periodes zijn voorbeelden die in de afspraken tussen partijen anders kunnen worden ingevuld.

• Procesbeschrijving: Voor de FPR is het mogelijk om uit te gaan van al bestaande processen (inclusief -indicatieve- tijdslijnen en rolverdeling) voor (collectieve) individuele DC-regelingen. Voor de SPR is dit nog niet het geval.

• Kosten: De informatie-uitwisseling over kosten valt buiten de scope van deze standaard. Vooralsnog gaan we er van uit dat wordt voortgebouwd op bestaande processen die ook de basis vormen voor bijvoorbeeld de J402 DNB-jaarstaat..

• Begrip Vermogensbeheer: Als in deze handleiding het begrip “vermogensbeheer” wordt gebruikt, dan wordt daarmee gedoeld op de partijen: FM, BA/asset serviceprovider, custodian en Liability-Driven Investment-manager. Bij “pensioenuitvoering” gaat het om de combinatie van de wettelijke pensioenuitvoerder en de PUO's die voor hen de administratie voeren.

• Taal: Dit rapport is opgesteld voor de gegevensuitwisseling tussen PUO's en vermogensbeheerders binnen de Nederlandse WTP-context. Het rapport en de standaard worden in de Nederlandse taal opgeleverd. De namen van de gebruikte variabelen in de standaards zijn overigens wel in het Engels gesteld zodat het begrippenapparaat ook voor niet Nederlandstaligen die wel thuis zijn in vermogensbeheer begrijpelijk is.

2.6 Deelnemer communicatie

Zie hoofdstuk 6 in het eerdere in de inleiding genoemde eindrapport.

2.7 Techniek

Rond gebruik en technische invulling van de gegevensstandaard zijn een aantal principes geformuleerd:

• De gegevensuitwisseling is “duurzaam” dus niet gekoppeld aan technologische trends (of hypes).

• De documentatie is duidelijk en transparant.

• De gegevensset kan in overleg met de betrokken partijen worden bijgesteld.

• Er wordt zoveel mogelijk gebruik gemaakt van open technische standaarden (bijvoorbeeld REST, JSON, SOAP, ODATA, OAuth).

Voor de technische invulling van het berichtenverkeer is het volgende afgesproken:

• Gegevensuitwisseling: RESTful Web services.

• Gegevensformaat: JSON.

• Voor het gegevensformaat conformeren we ons binnen deze standaard aan AFD 2.0. Dat heeft onder andere consequenties voor de naamgeving van de attributen en entiteiten.

• AFD 2.0 definieert het gegevenstype van een attribuut, maar beperkt de tekenreekslengte of het aantal decimalen niet.. Een eventuele beperking van het aantal posities kan tussen partijen onderling worden afgesproken. Zie https://www.manula.com/manuals/sivi/sivi-all-finance-standard/1/en/topic/data-types-and-formats

• Berichtenverwerking is asynchroon. Het berichtenverkeer is conform REST synchroon. De frequentie van de informatie-uitwisseling is periodiek (bijvoorbeeld maandelijks) en de verwerking door de ontvanger in principe op dagbasis; synchroon (realtime) is niet nodig.

• Bericht initiatief ligt bij de verzender van de informatie, deze brengt (pushed) het bericht naar de ontvanger.

• Service venster: advies is kantoortijden. Partijen kunnen hierover onderling eigen afspraken maken.

• Beveiligingsaspecten:

• Tijdens het transport van informatie wordt er gebruik gemaakt van two-way authentication (mutual-TLS).

• Authenticatie van de verzender bij de ontvangende server is vereist.

• De gegevens dienen gegarandeerd ongewijzigd aan te komen bij de ontvanger (zijn onweerlegbaar). Ze zijn daarom digitaal ondertekend.

Afspraken over de onderstaande aspecten worden uitgewerkt en behandeld binnen de kaders van de governancestructuur rond de standaard.

• De complete – technische – gegevensstandaard en de verschillende daarop gebaseerde berichten.

• Maximale omvang (aantallen en/of bestandsomvang) van het bericht. Zie hieronder bij "Omgaan met Grote Berichten".

• Granulariteit van het berichtenverkeer.

• Een lagere granulariteit geeft aan dat er -op een zeker niveau- minder details worden uitgewisseld.

• Verwerkingstijd van ontvangen berichten.

• Berichtterugkoppeling: response berichten (ontvangstbevestiging en correct of foutmelding – inhoudelijk en technisch - of waarschuwing). Hiervoor moeten de regels worden beschreven.

• Responsetijd (server).

Omgaan met Grote Berichten (Deelberichten of Chunking)

Hoewel het aantal transacties per dag relatief laag kan zijn, kan de omvang van individuele berichten (met name Bericht 3 - Pensioenprojectie) aanzienlijk zijn. Berichten groter dan circa 4 MB kunnen in de praktijk tot problemen leiden bij transport en verwerking via moderne cloud-infrastructuren.

Om dit te ondervangen, biedt de standaard een mechanisme om grote berichten op te splitsen in meerdere, kleinere deelberichten (chunks).

• Mechanisme: Het opsplitsen gebeurt via een optioneel chunking.default blok op het hoogste niveau van een bericht. Dit blok bevat metadata over de opsplitsing, zoals het volgnummer en het totaal aantal chunks.

• Toepasbaarheid: Dit mechanisme is van toepassing op alle functionele berichten, maar niet op het feedbackbericht.

• Validiteit: Elk deelbericht is een op zichzelf staand, valide JSON-bericht.

• Verwerking: De ontvanger kan de deelberichten pas na ontvangst van alle delen samenvoegen tot het volledige, logische bericht. Een fout in één deelbericht betekent dat het gehele logische bericht als mislukt wordt beschouwd.

• Limieten: De standaard schrijft geen maximum aantal chunks voor. De maximale berichtgrootte en het aantal chunks zijn afspraken tussen ketenpartijen (TOM / SLA). Zie GitHub issue #127.

De gedetailleerde specificaties van dit mechanisme zijn te vinden in Hoofdstuk 6.

2.8 Transport van gegevens

(Enige) standaardisatie van het transport van gegevens, een koppelvlak, is van groot belang. Standaardisering maakt het leven voor de verzendende en ontvangende partijen veel eenvoudiger en voorkomt dat alle samenwerkende partijen steeds bilateraal het wiel moeten uitvinden. De uitwerking daarvan beperkt zich tot één oplossing, namelijk RESTful API/webservice. Het SIVI-API raamwerk biedt hierbij ondersteuning. Partijen die niet met de RESTful API/webservice oplossing kunnen of willen werken, kunnen zelf bilaterale oplossingen ontwikkelen. Hiervoor wordt vanuit de werkgroepen rond de standaard geen ondersteuning geboden.

De webservice oplossing heeft de voorkeur omdat de informatiestroom dan beter te managen is (sneller door de (interne) keten, betere versionering, betere controleerbaarheid). Een portaloplossing brengt handwerk met zich mee en is daarom onwenselijk.

Zie ook: 7.4 Transport / OpenAPI.

2.9 Governance, Beheer en Releases

2.9.1 Rollen en verantwoordelijkheden

Het gebruik van de standaard vormt onderdeel van de individuele overeenkomsten tussen pensioenuitvoerders en vermogensbeheerpartijen. Partijen gebruiken de standaard conform de afspraken die voor de standaard gelden en in hun contracten zijn vastgelegd.

De standaard is eigendom van de Pensioenfederatie. Het beheer is ondergebracht bij SIVI, dat handelt in opdracht van de Stuurgroep DSO. De inhoudelijke doorontwikkeling vindt plaats in samenspraak met de sector via een Klankbordgroep (KBG).

De precieze inrichting van het beheer, de rollen, de wijzigingsprocedure en de werkwijze van de Klankbordgroep zijn vastgelegd in het document "Organisatie Beheer Standaard Vermogensbeheer Pensioenuitvoering". Dit document is de leidende bron voor alle governance-gerelateerde afspraken.

2.9.2 Releasebeleid en Versiebeheer

Om de doorontwikkeling van de standaard voorspelbaar en beheersbaar te maken, is het volgende releasebeleid van kracht:

• Jaarlijkse Releasecyclus: Ieder jaar verschijnt eind juni een prerelease, die eind september wordt omgezet in de definitieve jaarrelease (bijv. "Release 2026").

• Continue Ontwikkeling: Wijzigingen die gedurende het jaar worden goedgekeurd, worden zodra ze zijn afgerond beschikbaar gesteld op GitHub

• Ondersteuning van Versies: Naast de actuele jaarrelease blijven de twee voorgaande jaarreleases beschikbaar. Voor 2026 zijn dit: Release 2026, Release “2024 November” en Release “Juli 2024”.

JSON Schema Draft 2020-12

Vanaf release 2027 gebruikt de VBPUO-standaard JSON Schema Draft 2020-12 voor de JSON-schema's die via GitHub worden gepubliceerd.

De overstap naar Draft 2020-12 heeft primair betrekking op: - modernisering van het JSON Schema-dialect; - harmonisatie met actuele tooling en IDE-ondersteuning; - aanpassing van interne en externe schemareferenties.

Als gevolg van deze technische migratie blijven de functionele berichtstructuren en businessbetekenis van de berichten ongewijzigd.