VB-PUO Standaard Documentatie

Functionele en technische documentatie voor de standaard datauitwisseling VB-PUO.

Auteur(s)	SIVI
Status	Pre-Release 2027
Website	www.sivi.org

---

© SIVI — Kennis- en standaardisatie-instituut voor de financiële dienstverlening

Colofon

15-07-2026 Standaard voor uitwisseling data tussen Vermogensbeheer en Pensioenuitvoering

Datum	20260715
Project Referentie	VBPUO
Vertrouwelijkheid	Openbaar
Status	Pre-Release 2027
Opdrachtgever	Stuurgroep DSO
Auteurs	SIVI
Repository	https://github.com/Stichting-SIVI/VBPUOdsk
English version	https://stichting-sivi.github.io/VBPUOdsk-docs/ (unofficial, machine-translated)
Document versie	20260715 Handleiding Standaard datauitwisseling VB-PUO release 2027
Releasenummers	GitHub (pre-)release 2027 Tag v.1.4.0 bestaat uit de volgende onderdelen: JSON-Schema’s versie: VBPUO-001.05 (voor berichten 1 t/m 15 en feedback message - Model base: 20260717-0825 vb-puo entiteitenattribs OH - Doc (2027 version) 2.0 veegactie)
Releasenotes	https://github.com/Stichting-SIVI/VBPUOdsk/releases/tag/v1.4.0 In de releasenotes worden de wijzigingen beschreven. De impact van de wijzigingen is verwerkt in deze handleiding.
Technische wijzigingen release 2027	Overgang naar JSON Schema Draft 2020-12: Overgang van definitions naar $defs Aanpassing van interne en externe schemareferenties Modernisering van JSON Schema-validatie en toolingondersteuning Zie ook GitHub issue #104 JSON Schema Versie
Functionele wijzigingen release 2027	participationStatus (ADNDNS): waarde 60 verwijderd uit documentatie (was reeds gecorrigeerd in JSON-schema). Zie GitHub issue #103 en #71. APF-kringen: toelichting twee gangbare scenario's voor PUV-codes bij APF's met meerdere kringen (§6.4.1, §6.3). Zie GitHub issue #114. Lege cohorten: toelichting dat beide benaderingen (meesturen met waarde 0 of weglaten) zijn toegestaan (§3.2.3). Zie GitHub issue #100. Chunking: geen maximum aantal chunks in de standaard; limieten zijn afspraken tussen ketenpartijen (§2.7). Zie GitHub issue #127. Datumconventies: eenduidige toepassing van startDate en projectionDate vastgelegd (§6.3, §3.2.1, §3.2.3). Zie GitHub issue #94. Dekkingsgraad / coverage ratio: expliciet buiten scope geplaatst (§2.3). Zie GitHub issue #118. Opschoning FPR-berichten: berichten 7, 8, 9, 11 en 12 uit de actieve berichtenset gehaald; nummering ongewijzigd. Berichtenmatrix omgezet naar nieuwe actorkolommen: Soort, ACB en BR verwijderd, LDI toegevoegd (§6.4, §4.5). Zie GitHub issues #99, #119, #121, #98. Rol ACB (Administrateur cohorten- en beleggingspools): vervallen als zelfstandige actor. In de praktijk ingevuld door de BA of de PUO; het berichtenschema biedt nog steeds de mogelijkheid deze rol te ondersteunen indien nodig (§6.4). Zie GitHub issue #131. Reserves en voorzieningen: rolverdeling refKey (identificatie), reserveType/AFDRES (classificatie en sleutel beleggingsbeleid) en reserveDescription (beschrijvend) verduidelijkt (§6.3). Zie GitHub issue #111. Bericht 10 (00553): cohortPool-laag verwijderd; gegevens rechtstreeks op investment.pool-niveau (§6.4.11, §4.5.3, §6.3). Geen expliciet formeel FPR-besluit in beschikbare verslaglegging; wijziging doorgevoerd op basis van beschikbare context en ontbreken van bekende bezwaren. Zie GitHub issue #124. Bericht 10 (00553): velden dummyCashId, tradeQuantity, unitPrice en currencyExchangeRate verwijderd uit entiteit investment.pool. De velden buySellId, tradeValueAmount en currencyType blijven actief (§6.4.11, §6.3, §6.5). Zie GitHub issue #133. Bericht 14 Betaalinformatie (00556): veldlengte collectionAccountIban gecorrigeerd van 10 naar 34 in financialTransaction.payment en party.creditor. De waarde 34 is de internationale IBAN-maxlengte conform ISO 13616; de Nederlandse IBAN-lengte (18) valt daar binnen (§6.3). Zie GitHub issue #135. Berichten 5 en 6 (00541/00542): switch-conventie aangepast. Code switch in buySellId vervangen door switchfrom en switchto; richting volgt uit buySellId, bedragen zijn altijd positief. switchType en financialInformationRef nu ook beschikbaar in bericht 6 (§4.4, §6.3, §6.5). Zie GitHub issue #115. Bericht 5 (00541): verbandscontrole expliciet vastgelegd — per trade-instructie moet exact één van tradeAmount of tradeQuantity gevuld zijn. Beide gevuld of beide leeg is niet toegestaan (§4.4). Zie GitHub issue #116. Bericht 6 (00542): velden tradeQuantity, tradePrice, counterparty, broker, interestAmount, commissionAmount, clearingBroker en clearingBrokerCashAccount gewijzigd van verplicht naar optioneel onder financialTransaction.trade. tradeAmount blijft verplicht (§6.4.7, §6.5). Zie GitHub issue #105. Uniciteit messageId: expliciet vastgelegd dat messageId altijd uniek is over alle berichten heen; gebruik voor groepering of bundeling is niet toegestaan (§6.3). Uitzondering: chunking (§7.6). Zie GitHub issue #108. Bericht 15 Corporate Actions (00557): procesuitleg toegevoegd voor het doorgeven van corporate-action gebeurtenissen vanuit de vermogensbeheerketen naar de PUO. Modellering rebate toegelicht: corporateActionType = rebate, vastlegging via cashDividendTotalAmount en/of cashDividendPerUnitAmount (§4.5.7). Zie GitHub issue #87. Bericht 4 Rendementsinformatie: verduidelijkt dat totaalrendement en uitsplitsing naar matching/return in één bericht mogen, onderscheiden via refKey (§3.2.4). Zie GitHub issue #109. Bericht 2 Cashflow (0001b): twee wederzijds uitsluitende invulpatronen vastgelegd. SPR-route: directe cashflow op regelingniveau met optionele cohortuitsplitsing (incl. netDate op cohortniveau). FPR-route: cashflow per beleggingsportefeuille via investment.portfolio → financialTransaction.cashflow; netAmount en netDate verplicht. Conditionele verbandscontroles vastgelegd (§3.2.2, §4.4, §6.3, §6.3.1, §6.4.3, §6.5). Zie GitHub issue #113. Gebruik van SPR-berichten in FPR: expliciet vastgelegd dat voor collectieve premiestromen binnen FPR (risicopremies, reserves, onttrekkingen) gebruik wordt gemaakt van SPR-berichten 1, 2, 3 en/of 4, zowel voor Model 1 als Model 2 (§4.6). Zie GitHub issue #91. Feedbackbericht: afhandeling van een duplicaat messageId vastgelegd — de ontvangende partij wijst het bericht af met HTTP 400 en een Feedbackbericht in de response body, inclusief errorCode en errorCodeExplanation (§4.7). Zie GitHub issue #129. Feedbackbericht: party.sender en party.receiver toegevoegd aan de beschrijving van commonTechnical (§4.7). Zie GitHub issue #90. Feedbackbericht: asynchroon feedbackbericht uitgebreid met aanvullende scenario's voor succesvolle en foutieve verwerking; maximale lengte errorCodeExplanation verhoogd van 300 naar 1000 tekens (§4.7, §6.3). Zie GitHub issue #107. Feedbackbericht: 00542 (Orderconfirmation) toegevoegd aan de originalMessageType enum, zodat ook op orderconfirmation-berichten feedback kan worden gegeven (§6.3). Zie GitHub issue #126. Bericht 13 Waarde-informatie beleggingspool (00555b): marketValueAmount verwijderd uit investment.pool; de netto vermogenswaarde wordt uitsluitend via preliminaryUnitValueAmount uitgedrukt, met bijgewerkte omschrijving. Veldbeschrijvingen geconsolideerd; dubbele buySellId-definitie samengevoegd en tradeValueAmount-omschrijving verduidelijkt (§6.3, §6.5). Zie GitHub issue #128. Functionele uitval bij orders: vastgelegd dat niet-uitvoerbare orders worden teruggekoppeld via het feedbackbericht (status Afgewezen, foutcode, omschrijving). Overmacht en force majeure kennen geen standaardbericht; afhandeling valt onder bilaterale SLA/TOM-afspraken (§4.7). Zie GitHub issue #132. Procesplaten FPR model 2: Figuur 8 en 9 zijn indicatieve procesflow schema's. Tijdsaanduidingen zijn indicatief; de volgorde van stappen is richtinggevend. Berichten 10 en 14 kunnen door de PUO of de BA worden verstuurd (§4.5). Reserves en voorzieningen: codelijst AFDRES uitgebreid met codes 9 t/m 15 voor reserveType. Bij gedeeld beleggingsbeleid kan worden ingedikt; expliciete code alleen bij separaat beleggingsbeleid. Geldt voor SPR en FPR (§6.3). Zie GitHub issue #134. Verbandscontroles cashflowbericht: SPR/FPR-uitsluitingsregel als formele verbandscontrole gepositioneerd; somcontroles bij cohortuitsplitsing expliciet naar SPR-route geschaald en reconciliatiebegrip toegelicht (§6.3.1). Zie GitHub issue #113. Entiteitnaam chunkMeta.default hernoemd naar chunking.default in de documentatie, conform de reeds doorgevoerde wijziging in de JSON-schema's (§2.7, §6.3, §6.4, §6.5, §7.6). Procesflow FPR model 2, Fase 3 (stap H): rolverdeling gecorrigeerd — de LDI-manager voert zelf de transacties op het LDI-mandaat uit (stap H1), de FM/VB monitort de LDI-manager en handelt de overige (non-LDI) beleggingsportefeuilles af (stap H2) (§4.5). Begrippen LDI-mandaat en Mandaat toegevoegd aan de begrippenlijst (§8.1). Procesflow FPR model 2, non-unitized variant (figuur 9): timing SIVI 2 cash-instructie CVP (stappen O en P) gecorrigeerd van T+3 naar T-4, gelijktijdig met SIVI 5 orderopdracht (§4.5). Enkele tekstuele verbeteringen doorgevoerd.

Inhoudsopgave

• 1 Inleiding
• 2 Uitgangspunten
• 3 Processen & informatiestromen – Solidaire Premieregeling
• 4 Processen & informatiestromen – Flexibele Premieregeling
• 5 Aanpak/opzet gegevensstandaard
• 6 Functionele specificaties
• 6.4 Berichten
• 6.5 Kruisreferentie Attributen & berichten
• 7 Technische specificaties
• 7.4 Transport / OpenAPI
• 7.5 Samenstellen berichten, versionering en publicatie
• 7.6 Verwerkingsprotocol voor Deelberichten (Chunking)
• 8 Bijlagen
• 8.1 Begrippenlijst/Afkortingenlijst Vermogensbeheer & Pensioenuitvoering
• 8.2 Begrippenlijst gegevensuitwisseling op basis van standaarden
• 8.3 Onderdelen Standaard Vermogensbeheer Pensioenuitvoering
• 8.4 Vertaaltabel van functionele attributen naar AFD2.0 attributen.

1 Inleiding

In deze inleiding bespreken we de context, het doel en de doelgroep van deze handleiding. Tevens presenteren we (vrij uitgebreid) de opzet van de handleiding.

1.1 Context

Eindrapport

Begin september 2023 verscheen het eindrapport ‘’Resultaten onderzoek: Standaard voor data-uitwisseling pensioenuitvoering & vermogensbeheer partijen’’.

Met de invoering/uitvoering van de Wet Toekomst Pensioenen (Wtp) is strakkere aansluiting tussen fondsvermogen en collectieve administratie van persoonlijke pensioenvermogens noodzakelijk. Daarmee neemt de frequentie van de noodzakelijke informatie-uitwisseling toe. In de huidige praktijk regelen pensioenuitvoerders en vermogensbeheerpartijen onderling de informatie-uitwisseling. Door de intensivering van de informatie-uitwisseling is standaardisatie van de informatie-uitwisseling gewenst.

Het genoemde eindrapport beschrijft de voor de uitwisseling benodigde functionele gegevens, de informatiestromen en de, daarvan medeafhankelijke, deelnemercommunicatie.

De gegevens en informatiestromen zijn uitgewerkt voor zowel de solidaire premieregeling als de flexibele premieregeling.

Het eindrapport is gebaseerd op bijdragen van diverse organisaties, waaronder APG, AZL, Caceis, Capgemini, H&C, Van Lanschot Kempen IM, MN, Pensioenfederatie, SIVI en TKP. Via een consultatieronde zijn onder andere nog diverse andere uitvoeringsorganisaties, fiduciairs, custodians en pensioenfondsen betrokken. Deze consultatieronde is afgerond en de input daaruit is verwerkt.

Vervolg

Het eindrapport vertaalt SIVI naar een gegevensstandaard gebaseerd op AFD 2.0 uit SVI AFS. Bij deze gegevensstandaard hoort een basisbericht waar we de oorspronkelijke 14 berichten van hebben afgeleid. De berichten worden uitgewisseld via REST-API endpoints. Naast die berichten is een Feedback_Message beschikbaar voor terugkoppeling. Bij asynchrone verwerking is het feedbackbericht het verplichte mechanisme voor status- en foutterugkoppeling (zie §4.7). Inmiddels is de berichtenset gewijzigd waarbij de berichtnamen overigens wel zijn gehandhaafd.

Governance en beheer

De standaard vertegenwoordigt een gezamenlijk belang van pensioenuitvoering en vermogensbeheer waarvoor het bestuurlijk en het inhoudelijk beheer moet worden belegd. Na introductie van de standaard ontstaan nieuwe wensen die al dan niet in de standaard zullen moeten worden opgenomen.

Afgesproken is dat:

• Het eigenaarschap van de standaard bij de Pensioenfederatie berust.

• Inhoudelijk en bestuurlijk beheer rond de standaard vorm zal worden gegeven.

• De standaard beheerd wordt door beheerorganisatie SIVI.

• Een klankbordgroep ondersteunt het beheer en eventuele verdere ontwikkeling.

1.2 Doel

Deze handleiding vormt een toelichting op de standaard voor data-uitwisseling tussen vermogensbeheer en pensioenuitvoering. De handleiding geeft:

• Analisten en ontwikkelaars een handvat om de standaard te (laten) implementeren;

• Betrokkenen inzicht in het beheer van de standaard.

1.3 Doelgroep

Deze handleiding is bestemd voor consultants, analisten en ontwikkelaars die betrokken zijn bij de implementatie van de standaard voor data-uitwisseling tussen vermogensbeheer- en pensioenuitvoeringspartijen.

1.4 Opzet

1.4.1 Notatie van Attribuutnamen

In de beschrijvende teksten van deze handleiding zult u een dubbele naamgeving voor datavelden tegenkomen, in het volgende formaat:

technischeNaam (Functionele Naam)

• technischeNaam: Dit is de definitieve, technische attribuutnaam conform de SIVI AFD 2.0 standaard, weergegeven in een monospace lettertype. Dit is de naam die daadwerkelijk in de JSON-berichten gebruikt moet worden.

• (Functionele Naam): Dit is de oorspronkelijke, functionele naam zoals deze werd gebruikt tijdens de requirements- en ontwerpfase. Deze naam wordt tijdelijk, tussen haakjes en in een iets kleiner, normaal lettertype vermeld om de herkenbaarheid tijdens de transitie te vergroten. In een volgende release van deze handleiding zal deze functionele naam worden verwijderd.

De complete Vertaaltabel van functionele attributen naar AFD2.0 attributen. Is opgenomen in 8.4.

Hoofdstuk	Inhoud
1	Inleiding In deze inleiding bespreken we de context, het doel en de doelgroep van deze handleiding. Tevens presenteren we (vrij uitgebreid) de opzet van de handleiding.
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’’.
3	Processen & informatiestromen – Solidaire premieregeling De processen & informatiestromen staan uitvoering beschreven in het rapport ‘’Resultaten onderzoek: Standaard voor data-uitwisseling pensioenuitvoering & vermogensbeheer partijen’’: Hoofdstuk 4: Solidaire premieregeling.
4	Processen & informatiestromen – Flexibele premieregeling De processen & informatiestromen staan uitvoering beschreven in het rapport ‘’Resultaten onderzoek: Standaard voor data-uitwisseling pensioenuitvoering & vermogensbeheer partijen’’: Hoofdstuk 5: Flexibele premieregeling.
5	Aanpak/opzet gegevensstandaard In dit hoofdstuk leggen we uit hoe we komen tot specificaties van de berichten. Stappen om te komen tot de functionele specificaties van de berichten: Maak beschrijvingen van de processen en informatiestromen. Stel een lijst op met entiteiten en bijbehorende attributen. Bepaal de basisstructuur van de berichten. Geef aan welke berichten nodig zijn. Maak een kruistabel tussen de basisstructuur en de berichten. De relatie met SIVI AFS leggen we uit. De bouwstenen uit SIVI AFS (AFD 2.0) gebruiken we om tot technische specificaties te komen.
6	Functionele specificaties In dit hoofdstuk volgen de functionele specificaties: Datadictionary; Basisbericht; Kruisreferentie basisbericht & berichten.
7	Technische specificaties De technische gegevensspecificaties komen beschikbaar op basis van AFD 2.0 uit SIVI AFS. In dit hoofdstuk kan de lezer kennisnemen van een toelichting.
10	Bijlagen In de bijlagen treft u de: Begrippenlijst/Afkortingenlijst Vermogensbeheer & Pensioenuitvoering; Begrippenlijst gegevensuitwisseling op basis van standaarden.

1.5 Links

Deze handleiding bevat links, veelal bronvermeldingen. Deze zijn blauw gekleurd. Door op de link te klikken komt de lezer bij de desbetreffende webpagina of het desbetreffende rapport/artikel.

1.6 Bron afbeelding op titelpagina

https://www.flaticon.com/free-icon/data-exchange_4995192

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.

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

4 Processen & informatiestromen – Flexibele Premieregeling

4.1 Inleiding

Dit hoofdstuk beschrijft de noodzakelijke informatie-uitwisseling tussen betrokken partijen die nodig is om op een robuuste wijze invulling te geven aan de uitvoering van de Flexibele premieregeling. Op basis van de uitgangspunten en de scope is de benodigde gegevensset vastgesteld.

In de aansturing van het proces van de flexibele premieregeling kan onderscheid gemaakt worden tussen twee modellen voor het “orderen” van beleggingen die in de operationele samenwerking tussen pensioenuitvoering en vermogensbeheer worden toegepast:

• Model 1, een eenvoudiger, direct ordermodel en een

• Model 2, een uitgebreider, gelaagd ordermodel.

Er is ook een model denkbaar waarbij voor de FPR-gegevensuitwisseling het SPR-gegevensmodel gebruikt kan worden. In dit model is FPR ingericht vergelijkbaar met SPR-feitelijk waarbij alleen meerdere risicoprofielen per cohort ondersteund worden.

4.2 Model 1 eenvoudiger, direct ordermodel

In dit model (zie Figuur 2) bestaan de beleggingen (onderste laag uit Figuur 2) alleen uit direct via een platform verhandelbare, beleggingsfondsen. Dit betreffen handelsplatformen (bijvoorbeeld AllFunds, Fundsettle etc.) waar beleggingsfondsen direct kunnen worden verhandeld. Dit model wordt in de bestaande praktijk vooral toegepast voor Individuele DC-regelingen. Het direct order model kan door de pensioenuitvoeringsorganisatie (PUO) zelf uitgevoerd worden.

Figuur 2 – Schematische weergave directe ordermodel

De PUO vertaalt bij toepassing van dit model mutaties op deelnemersniveau naar benodigde (gesaldeerde) transacties in de beleggingsfondsen van operationele vermogensbeheerders en laat deze uitvoeren via een handelsplatform. Een dergelijke opzet kan ook gezamenlijk met de asset serviceprovider/custodian worden geïmplementeerd waarbij de PUO mutaties op deelnemersniveau vertaalt naar gesaldeerde mutaties en de asset serviceprovider/custodian zorgdraagt voor de uitvoering van de transacties in beleggingsfondsen via een handelsplatform zie Figuur 6 - Model 1b: de PUO geeft beleggingsopdrachten aan een tussenpartij (order platform: custodian, fiduciair). Bij de samenstelling van de orders wordt rekening gehouden met aspecten zoals de minimale orderomvang per beleggingsproduct, de settlement cyclus en de bijbehorende financiële stromen.

In het direct ordermodel wordt de pensioenuitvoerder in de regel door de fiduciair manager (FM) ondersteund ten aanzien van de inrichting van de lifecycle(s) en de samenstelling daarvan (selectie en monitoring van onderliggende beleggingen). Specifieke aandacht verdient het proces van wijzigingen in de samenstelling van de beleggingen (vervanging van beleggingsfondsen). Dergelijke wijzigingen resulteren in transitie-activiteiten bij de pensioenadministrateur en/of asset serviceprovider/custodian. Specifieker omgeschreven; als een beleggingsproduct (dat kan bijvoorbeeld een beleggingsfonds maar ook een virtuele pool of een mandaat zijn) wordt vervangen, verwijderd of toegevoegd dan zal de PUO dit aanpassen en verwerken. Als in een beleggingsproduct aanpassingen worden doorgevoerd dan is dat voor de PUO niet relevant en raakt dit enkel de aanbieder van het product.

In het direct ordermodel bestaat een cohortenpool uit een groep deelnemers die op basis van het lifecycle principe (minder beleggings- en renterisico naarmate de pensioeningang/einddatum beleggingshorizon nadert) een gelijke beleggingsverdeling kennen. Een cohortenpool kan gebruikt worden om deelnemersgroepen te onderscheiden. Dit kan op basis van tijd (leeftijd, periode tot pensioen etc.) zijn maar ook op basis van een kenmerk als bv. actief, slaper, arbeidsongeschikt etc. Het aantal pools is in de basis onbeperkt. Er worden zoveel pools gemaakt als nodig om de juiste deelnemersgroepen te kunnen onderscheiden die een eigen beleggingsmix nodig hebben. Hieronder volgt een eenvoudig voorbeeld met indeling in drie lifecycles op basis van geboortejaren en de vastgestelde verdeling over aandelen en obligaties. De administratie van de cohortenpool is optioneel en kan bij de PUO, de beleggingsadministrateur/asset serviceprovider (BA) of elders liggen. De verdeling van de gewichten (percentages) wordt veelal door de FM gemaakt.

Een cohortenpool is een administratieve groepering die bestaat uit een groep deelnemers die op basis van het bijvoorbeeld het lifecycle principe een gelijke beleggingsverdeling kennen.

	Lifecycle defensief		Lifecycle neutraal		Lifecycle offensief
Cohortenpool	% Aandelen	% Obligaties	% Aandelen	% Obligaties	% Aandelen	% Obligaties
Geboortejaar 1987	90	10	95	5	100	0
Geboortejaar 1986	88	12	94	6	98	2
Geboortejaar 1985	86	14	93	7	96	4
Geboortejaar 1984	85	15	91	9	94	6
Geboortejaar 1983	84	16	89	11	92	8
Geboortejaar 1982	83	17	87	13	90	10
Geboortejaar 1981	82	18	85	15	88	12
Geboortejaar 1980	81	19	84	16	86	14
Geboortejaar 1979	80	20	82	18	84	16

Figuur 3 - Voorbeeld cohortenpools en lifecycles

Het voorbeeld in Figuur 3 laat zien hoe geboortejaren en daarmee leeftijden invloed kunnen hebben op de verdeling van beleggingen binnen lifecycles.

Als een deelnemer een jaar ouder wordt, dan wordt een zogenaamde leeftijdsrebalance doorgevoerd. Elke deelnemer wordt in een volgende cohortenpool wordt geplaatst.

Daarbij wordt de beleggingsmix van de deelnemer aangepast naar die van het nieuwe cohort. In het voorbeeld hierboven (Figuur 3) wordt ongeacht het gekozen risicoprofiel het aandeel aandelen afgebouwd en het aandeel obligaties opgebouwd. Dit leidt dus tot concrete aan- en verkooporders richting de productaanbieders.

Een andere vorm van rebalancing is de doelgewichtenrebalancing. Deze kan worden uitgevoerd wanneer de werkelijke verdeling van beleggingen buiten vooraf vastgestelde bandbreedtes valt als gevolg van koersontwikkelingen. Ook deze vorm van rebalancing leidt tot aan- en verkooporders.

Een groep (cohort) deelnemers kan op verschillende manieren worden samengesteld. Over het algemeen spelen daarbij 3 aspecten een rol:

• Leeftijd.

• Status.

• Beleggingsprofiel.

Voor het leeftijdsaspect kan bijvoorbeeld gebruik gemaakt worden van:

• Leeftijd.

• Periode tot pensioeningang/einddatum beleggingshorizon.

• Geboortejaar/maand.

Voor de status kan onderscheid worden gemaakt in:

• Opbouwend versus uitkerend.

• Actief/Slaper/Arbeidsongeschikt (AO)/Uitkerend/etc.

Salderen (ook wel “netten”) van de beleggingen vindt plaats over de cohortenpools conform de instructies voor de beleggingentransacties. In het direct ordermodel vindt dat plaats “in de spaghetti” (zie Figuur 2: Schematische weergave direct ordermodel) tussen de cohortenpools en de beleggingen. De risicodelingsreserve wordt gezien als een aparte cohortenpool die conform een eigen beleggingsbeleid in beleggingsproducten belegt.

4.3 Model 2 uitgebreider, gelaagd ordermodel

In het “Uitgebreidere, gelaagde model” (Figuur 4) kunnen de beleggingen ook bestaan uit niet dagelijks verhandelbare en/of niet via een platform) verhandelbare (illiquide) fondsen of uit beleggingsmandaten. Dit model wordt al toegepast voor grotere Collectieve Individuele DC (CIDC) regelingen.

Figuur 4 - Schematische weergave gelaagd ordermodel

In dit model:

• Participeren deelnemers in cohortenpools conform de gekozen lifecycle en gekozen samenstelling van cohorten. De cohortenpools participeren vervolgens in beleggingspools. Deze beleggingspools kunnen bestaan uit uiteenlopende onderliggende beleggingen (liquide, illiquide, fondsen en mandaten). De cohortenpools participeren in beleggingspools al naar gelang de strategische verdeling binnen de cohortenpools¹. Om de toedeling naar deelnemers robuust en traceerbaar vorm te geven worden voor de verschillende (gelaagde) pools units uitgegeven en unitwaardes uitgerekend. Het vermogen van de deelnemer is daardoor exact terug te voeren naar het pro rata deel van de onderliggende beleggingen. De laag met cohortenpools is overigens optioneel en kan de inrichting van het beleggingsbeleid en/of de beoogde functiescheiding reflecteren. Indien deze laag ontbreekt dat dient de PUO per deelnemer te administreren welke participaties in de verschillende beleggingspools worden aangehouden. In het eenvoudigere FPR Direct Order-model zijn de cohortenpools en/of beleggingspools niet nodig.
  De beleggingen zijn dan dagelijks verhandelbaar en de koersen zijn ook dagelijks beschikbaar. Als eenvoudig voorbeeld voor een cohortenpool geldt eveneens Figuur 3 waarbij “% Aandelen” en “% Obligaties” dan vervangen wordt door bijvoorbeeld “% Zakelijke waarden”, ”% Vastrentend beleggingen, korte looptijden”,”% Vastrentende beleggingen, lange looptijden”, etc.

• Kan de allocatie van de rendementen door de PUO of de administrateur van de cohortenpools en beleggingspools worden gedaan:

• Heeft de PUO de verantwoordelijkheid om conform de door de pensioenuitvoerder vastgestelde allocatieregels rendementen expliciet toe te delen naar: de persoonlijke pensioenvermogens van deelnemers, de risicodelingsreserve, een eventueel compensatiedepot en mogelijk andere reserves. Daartoe verwerkt de PUO mutaties in het deelnemersbestand en de allocatie van persoonlijke pensioenvermogens naar cohortenpools. Bij de samenstelling van de cohortenpools wordt rekening gehouden met de lifecycle die de deelnemer gekozen heeft (offensief, neutraal, defensief etc.). Ook wordt rekening gehouden met ingelegde premie en mogelijke verrekeningen zoals met de risicodelingsreserve. Op basis van deze persoonlijke pensioenvermogens worden, conform de uitgangspunten van de pensioenuitvoerder, uitkeringen geprojecteerd. Daarnaast verzorgt de PUO de deelnemerscommunicatie.

• Verwerkt de administrateur van cohortenpools en beleggingspools de allocatie en administratie van cohortenpools zoals aangeleverd door de PUO. Daarnaast verzorgt hij de allocatie naar beleggingspools (bijvoorbeeld zakelijke waarden, vastrentende waarden). Hiervoor worden zowel voor de cohortenpools als de beleggingspools unitwaarden berekend en het aantal units geadministreerd. In het geval van cohortenpools spreken we hierbij van participatiewaardes, bij beleggingspools van unitwaardes. Hierbij worden premies, onttrekkingen en herbalanceringen meegenomen. Deze rol kan eventueel ook uitgevoerd worden door een PUO of door een BA/asset serviceprovider. De participatiewaardes en het aantal participaties van de cohortenpools vormen de basis voor de PUO om vermogen expliciet aan deelnemers toe te delen. De administrateur van cohortenpools en beleggingspools ontvangt maandelijks de posities uit de leidende administratie van de BA van de beleggingspools, aangevuld met de posities uit de (schaduw) administratie van de FM. Deze posities worden gereconcilieerd³ met de posities in de eigen administratie van de administrateur van cohortenpools en beleggingspools.

• Kan sprake zijn van een dubbele cohortenadministratie. De eerste ligt bij de PUO en betreft de deelnemer- & cohortenadministratie. De tweede ligt bij “een administrateur”, dat kan de PUO, een andere gespecialiseerde partij of de BA/asset serviceprovider zijn. In deze tweede rol wordt de relatie tussen de cohortenpools en de beleggingspools gelegd. Deze laatste administratie kan ook wel middenadministratie genoemd worden en is optioneel. Als deze niet van toepassing is dan administreert de PUO op deelnemersniveau in welke beleggingspools de deelnemer belegt en geeft de PUO de benodigde informatie rechtstreeks door aan de FM.

• Ondersteunt de FM de pensioenuitvoerder bij de totstandkoming van het integrale beleggingsbeleid. Hij draagt zorg voor de uitvoering van dit beleggingsbeleid en stuurt daarbij (operationele) vermogensbeheerders aan. De FM zal ook een (schaduw) beleggingsadministratie voeren.

• Beheren de vermogensbeheerders onderdelen van de portefeuille. Zij worden daarbij aangestuurd door de FM. Het is mogelijk dat (voor onderdelen) de FM en de operationeel vermogensbeheerder tot dezelfde organisatie behoren.

• Verzorgt de BA/asset serviceprovider (doorgaans aanvullende dienstverlening van de custodian) de onafhankelijke beleggingsadministratie van de beleggingspools voor de pensioenuitvoerder. Deze administratie wordt gevoed vanuit de afwikkeling van mutaties in de portefeuille van de beleggingspool, uitgevoerd door de operationele vermogensbeheerders die worden geïnstrueerd door de FM. Deze beleggingsadministratie wordt gereconcilieerd met de (schaduw)administratie van de FM.

In het proces voor “Model 2 uitgebreider, gelaagd ordermodel” wordt onderscheid gemaakt tussen een opbouwfase (links van de stippellijn in Figuur 4) en een uitkeringsfase (rechts in Figuur 4).

Voor zover de uitkeringsfase volledig is ondergebracht bij een verzekeraar is de gegevensuitwisseling out-of-scope van deze uitwerking van gegevensuitwisseling. In dat geval krijgt de verzekeraar het kapitaal van de deelnemer overgemaakt middels een uitgaande waardeoverdracht vanuit de PUO en wordt daarmee een pensioenuitkering aangekocht bij de verzekeraar.

De uitkeringsfase die door een PUO wordt uitgevoerd is in-scope. In de uitkeringsfase hebben deelnemers de keuze uit doorbeleggen (met een variabele pensioenuitkering) of voor een vaste pensioenuitkering. Bij een variabele uitkering kan het pensioenfonds kiezen voor een model met een individuele uitkeringsfase of een collectieve uitkeringsfase.

Bij een individuele uitkeringsfase kan de gegevensuitwisseling voor de doorbeleggen variant op dezelfde wijze worden ingericht als voor de opbouwfase (waarbij op hogere leeftijd bijvoorbeeld meer wordt belegd in kortere vastrentende waarden).

Bij een collectieve uitkeringsfase (alle gepensioneerden in één cohort), zowel bij vaste als variabele uitkeringen, is aansluiting van de rentegevoeligheid van de beleggingen (in een matchingportefeuille) bij de collectieve rentegevoeligheid van geprojecteerde uitkeringen van belang. Het is mogelijk dat de opbouwfase in model 1 (direct order model) plaatsvindt en de uitkeringsfase middels model 2 (uitgebreider order model). Tevens is het mogelijk dat er gekozen kan worden om individueel door te beleggen in de uitkeringsfase en later te switchen naar een collectieve uitkeringsfase. Deze switch heeft geen impact op de datavelden en/of gegevensuitwisseling tussen partijen.

Voor de uitkeringsfase (die uitgevoerd wordt door een pensioenuitvoerder) zal de FM de (aansturing van een) matchingsportefeuille inrichten. Voor de benodigde gegevensuitwisseling stuurt de PUO op periodieke (verwachting is maandelijkse) basis per regeling de geprojecteerde af te dekken uitkeringen per cohortpool naar de FM. De gegevensuitwisseling zal daarvoor conform de gegevensuitwisseling 1b uit de SPR worden opgezet.

4.4 Informatiestromen FPR - model 1 (1a en 1b)

De informatie-uitwisseling voor model 1 kan worden uitgesplitst naar een variant 1a waarin de PUO zelf belegt en een variant 1b waarin de PUO belegt via een order platform. Strikt genomen is er vanuit de PUO bezien geen onderscheid tussen beide varianten maar voor de helderheid worden beide varianten apart uitgelegd. Een en ander wordt schematisch en vereenvoudigd weergegeven in Figuur 5 respectievelijk Figuur 6. Via een broker zou een PUO bijvoorbeeld ETF's kunnen verhandelen namens het pensioenfonds als deze onderdeel zijn van de afgesproken beleggingsmix.

Figuur 5 - Model 1a: de PUO belegt direct bij diverse marktpartijen

De gegevensuitwisseling, in Figuur 5 aangeduid met "scope", vindt in dit model plaats tussen de PUO enerzijds en de diverse type marktpartijen anderzijds.

Figuur 6 - Model 1b: de PUO geeft beleggingsopdrachten aan een tussenpartij (order platform: custodian, fiduciair)

Gegevensuitwisseling (scope) uit Figuur 6 vindt uitsluitend plaats tussen PUO en order platform.

De gegevensuitwisseling voor FPR-model 1 (a en b) verloopt via de navolgende 2 berichten voor de orderverwerking.

Naast de orderberichten maakt de FPR ook gebruik van bericht 2. Cashflow (0001b) voor de periodieke kasstroominformatie. Voor FPR-gebruik loopt de cashflow per beleggingsportefeuille via pension.scheme → investment.portfolio → financialTransaction.cashflow. In dit invulpatroon zijn netAmount en netDate verplicht op portfolioniveau. Zie §6.4.3 voor de berichtstructuur.

4.4.1 Bericht 5. Orderopdracht (00541)

Informatiestroom van PUO naar Brokers/Transfer Agents/Order Desks (model 1a en 1b)

Deze informatiestroom van PUO naar Brokers/Transfer Agents/Order Desks bevat de minimale set aan gegevens die benodigd is om een order te kunnen sturen aan een order verwerkende partij. Tevens kan er een switch mee worden uitgevoerd.

De PUO stuurt orders in op het niveau van het beleggingsfonds. De aanbieder van het fonds voert zelf de ordering uit in de onderliggende beleggingen. Dat kan onder andere genoteerde en illiquide beleggingen betreffen.

Switch-conventie. Een switch bestaat uit twee gekoppelde orders: één met buySellId = switchfrom (het fonds dat wordt verlaten) en één met buySellId = switchto (het fonds waarnaar wordt overgestapt). De richting van de transactie volgt uitsluitend uit buySellId; tradeAmount en tradeQuantity worden altijd positief opgegeven. De twee switch-legs worden aan elkaar gekoppeld via financialInformationRef, dat verwijst naar de refKey van de andere leg. Het veld switchType geeft aan of het een gelijktijdige (one-day) of opeenvolgende (sequential) switch betreft. Zie GitHub issue #115.

Orderinstructie: tradeAmount of tradeQuantity. Per individuele trade-instructie moet exact één van tradeAmount of tradeQuantity gevuld zijn. Beide velden tegelijk vullen is niet toegestaan; beide leeg laten evenmin. Als een instructie zowel een bedrag- als een hoeveelheidcomponent heeft, worden die als afzonderlijke trade-records vastgelegd. Zie GitHub issue #116.

Functionele uitwerking naar bericht: zie hoofdstuk 6 en met name 6.4.6.

4.4.2 Bericht 6. Orderconfirmation (00542)

Informatiestroom van brokers/transfer agents/order desks naar PUO (model 1a en 1b)

Vanuit de order verwerkende partij komen de confirmationgegevens van de order terug naar de PUO. Voor switches bevestigt bericht 6 dezelfde structuur als bericht 5, inclusief switchType en financialInformationRef. Zie GitHub issue #115.

Functionele uitwerking naar bericht: zie hoofdstuk 6 en met name 6.4.7.

4.5 Informatiestromen FPR - model 2

De informatie-uitwisseling van model 2 (uitgebreider, gelaagd ordermodel) kan schematisch vereenvoudig als volgt worden weergegeven.

Figuur 7 - Model 2: de PUO laat beleggen

De in Figuur 7 geschetste scope leidt tot de uitwisseling van diverse informatiestromen. De gestandaardiseerde gegevensuitwisselingen die binnen de scope vallen worden in onderstaande procesflow figuren aangegeven met rode pijlen. De gegevens nodig voor die verschillende informatiestromen/processen wordt in de paragrafen beschreven.

Let op: Figuur 8 en Figuur 9 zijn indicatieve procesflow schema's. De tijdsaanduidingen zijn indicatief en kunnen per klantketen tussen alle betrokken partijen onderling anders worden ingevuld; de volgorde van de stappen is wel richtinggevend. Dit document gaat slechts over de informatiestromen.

De informatiestroom van model 2 wordt hieronder weergegeven in twee procesflow schema’s die de twee inrichtingsvarianten voor de collectieve uitkeringsfase (CVP) tonen: een unitized variant (Figuur 8) en een non-unitized variant (Figuur 9)².

Figuur 8 — Procesflow FPR model 2: unitized variant (opbouw en CVP via netting) Volledige weergave (SVG)

Toelichting bij Figuur 8: unitized variant (opbouw en CVP via netting)

In de unitized variant worden de beleggingsstromen van de opbouwfase en de collectieve uitkeringsfase (CVP) gecombineerd via netting. De CVP wordt in units geadministreerd, waardoor dezelfde orderstromen (SIVI 5/6) zowel opbouw- als CVP-mutaties dekken.

De procesflow verloopt in drie fasen met vier actoren: PUO/ZAF, BA (beleggingsadministrateur), FM/VB (fiduciair manager/vermogensbeheerder) en LDI-manager. Onder PUO wordt in deze context ook het zelf uitvoerend fonds (ZAF) begrepen.

Kleurcodering: grijze pijlen zijn generieke stromen die in beide varianten identiek zijn. Blauwe pijlen markeren stromen die in de unitized variant een bredere betekenis hebben doordat ze zowel opbouw als CVP dekken. De tijdsaanduidingen (T-4, T, T+3) zijn indicatief.

Fase 1 — Unit-administratie (T-4 en T+3): De PUO stuurt een orderopdracht (SIVI 5, stap A) naar de BA op T-4. Na handelsuitvoering volgt de orderconfirmation (SIVI 6, stap B) terug naar de PUO op T+3. De BA levert op T-4 ook de waarde-informatie beleggingspool (SIVI 13, stap C), die in de unitized variant tevens het CVP-rendement dekt.

Fase 2 — Sturing richting FM/VB en LDI (T-4): De PUO/ZAF (stap D) en de BA (stap E) sturen netto stuurinformatie (SIVI 10) naar de FM/VB. De PUO stuurt het profiel renterisico (SIVI 3, stappen F en G) naar FM/VB en LDI-manager.

Fase 3 — Handelsuitvoering, terugkoppeling en betaalinformatie (T tot T+3): De LDI-manager voert op T de netto koop-/verkoopbehoefte op het LDI-mandaat uit (stap H1), gericht op het beschermingsrendement. De FM/VB monitort de LDI-manager en voert de netto koop-/verkoopbehoefte uit op de overige (non-LDI) beleggingsportefeuilles (stap H2). Uitgevoerde transacties komen via SWIFT (stap I) terug naar de BA. Na ontvangst van de definitieve maandeinde-NAV (SIVI 13, stap J) volgen de definitieve betaalinformatie (SIVI 14, stappen K en L) en de cash-afwikkeling via SWIFT (stap M).

Figuur 9 — Procesflow FPR model 2: non-unitized variant (CVP als EUR-mandaat) Volledige weergave (SVG)

Toelichting bij Figuur 9: non-unitized variant (CVP als EUR-mandaat)

In de non-unitized variant wordt de collectieve uitkeringsfase (CVP) als aparte EUR-pot beheerd, los van de unitized opbouwfase. Dit leidt tot aanvullende informatiestromen.

Kleurcodering: grijze pijlen zijn generieke stromen (zie Figuur 8 voor de volledige kleurcodering). Groene pijlen markeren de non-unitized-specifieke stromen: extra berichten omdat de CVP een aparte EUR-pot is.

De opbouwfase (stappen A t/m J) verloopt identiek aan de unitized variant. Het verschil zit in de aanvullende groene stromen:

• Cash-instructie CVP (stappen O en P, T-4): de PUO of BA stuurt cash-instructies in EUR naar de FM/VB via SIVI 2, gelijktijdig met SIVI 5 (orderopdracht).
• Rendement CVP (stap K): de BA stuurt rendementen voor de CVP en overige collectieve reserves naar de PUO via SIVI 4.
• Beleggingsproces CVP (stap Q): de FM/VB maakt geld vrij uit of voegt toe aan de CVP via het beleggingsproces.
• SWIFT-terugkoppeling (stap R): uitgevoerde transacties en cash-overboekingen komen via SWIFT terug naar de BA.

Deze extra stromen zijn nodig omdat de CVP geen units kent — rendement en cashflows worden apart in EUR afgehandeld.

4.5.1 Bericht 7. Mutatiesaldi (00551), Informatiebehoefte administrateur cohortenpools en beleggingspools

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

4.5.2 Berichten voor reconciliatie informatie

Vervallen vanaf release 2027. De berichten 8 en 9 in deze sectie zijn niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

4.5.3 Bericht 10. Stuurinformatiebeleggingspools (00553)

Zie de toelichting bij Figuur 8 en 9 (stappen D en E). Functionele uitwerking: zie §6.4.11.

4.5.4 Bericht 11. Rebalancinginformatie (00554), Rebalancing cohortenpools

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

4.5.5 Doorgeven waardes per beleggingspool en per cohortenpool

Zie de toelichting bij Figuur 8 en 9 (stappen J, K en L).

4.5.5.1 Bericht 12. Waarde-informatie cohortenpool (00555a)

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

4.5.5.2 Bericht 13. Waarde-informatie beleggingspool (00555b)

Zie de toelichting bij Figuur 8 en 9 (stap J). Functionele uitwerking: zie §6.4.14.

4.5.6 Bericht 14. Betaalinformatie (00556)

Zie de toelichting bij Figuur 8 en 9 (stappen K en L). Functionele uitwerking: zie §6.4.15.

4.5.7 Bericht 15. Corporate Actions (00557)

Informatiestroom van de vermogensbeheerketen naar de PUO

Bericht 15 wordt gebruikt voor het doorgeven van corporate-action gebeurtenissen op beleggingsproducten vanuit de vermogensbeheerketen aan de pensioenuitvoeringsorganisatie (PUO). Het bericht is bedoeld voor situaties waarin dergelijke gebeurtenissen wel binnen de vermogensbeheeradministratie worden verwerkt, maar niet automatisch zichtbaar zijn binnen de administratie van de PUO.

De informatie wordt aangeleverd door de partij binnen de vermogensbeheerketen die verantwoordelijk is voor de vastlegging van de betreffende gebeurtenis. Afhankelijk van de inrichting van de keten kan dit bijvoorbeeld een BA, FM of andere vermogensbeheerpartij zijn.

Het bericht is primair bedoeld voor:

• cash dividend;
• rebate;
• vermeerdering of vermindering van units;
• kapitaal- en unitverschuivingen als gevolg van collateral calls of collateral returns;
• correcties op eerder verzonden corporate actions.

Daarnaast kan het bericht worden gebruikt voor aanvullende corporate-action gerelateerde wijzigingen, zoals productwijzigingen of andere administratieve aanpassingen, voor zover deze binnen de afgesproken implementatie van bericht 15 vallen.

Hierdoor kan de PUO:

• de eigen administratie synchroon houden met de vermogensbeheeradministratie;
• geld- en unitmutaties correct verwerken;
• corporate-action gebeurtenissen administratief vastleggen;
• verschillen tussen PUO- en vermogensbeheeradministraties voorkomen.

Modellering Rebate

Een rebate wordt gemodelleerd als een corporate action met corporateActionType = rebate (codelijst AFDCAE). Het rebatebedrag wordt vastgelegd in cashDividendTotalAmount en/of cashDividendPerUnitAmount, dezelfde attributen die ook worden gebruikt bij cashDividend. Het onderscheid tussen een cashdividend en een rebate volgt uitsluitend uit de waarde van corporateActionType.

Functionele uitwerking naar bericht: zie hoofdstuk 6 en met name 6.4.16.

Zie GitHub issue #87.

4.6 Gebruik van SPR-berichten in FPR

Binnen een Flexibele Premieregeling (FPR) bestaan er naast de individuele, 'unitized' geldstromen ook collectieve premiestromen. Dit zijn geldstromen die niet aan één specifieke deelnemer toebehoren, zoals risicopremies, bijdragen aan reserves, of onttrekkingen uit een collectieve uitkeringspool.

De standaard FPR-berichten (5 t/m 15) zijn puur gericht op de unitized wereld en bieden geen ondersteuning voor deze collectieve stromen. Om dit op te lossen, is de afspraak dat partijen voor de uitwisseling van deze informatie terugvallen op de beproefde SPR-berichten 1, 2, 3 en/of 4. Deze methode geldt voor zowel het directe (Model 1) als het gelaagde (Model 2) FPR-ordermodel.

4.7 Feedbackbericht (& Herverzending)

Doel en Functie

Bij het uitwisselen van berichten is het essentieel dat de verzender weet of een bericht correct is ontvangen en verwerkt. Het feedbackbericht is ontwikkeld om deze zekerheid te bieden in de volgende situaties:

• Bij asynchrone verwerking: Om de definitieve status (zowel succes als fout) van een bericht terug te koppelen nadat de verwerking op de achtergrond is voltooid.

• Bij synchrone verwerking: Om directe, gedetailleerde foutinformatie terug te geven wanneer een bericht niet kan worden geaccepteerd.

Een feedbackbericht wordt dus altijd gebruikt om fouten te specificeren. Bij een succesvolle verwerking wordt het alleen verstuurd als onderdeel van een asynchroon proces. Bij een succesvolle synchrone verwerking volstaat een HTTP 200 OK statuscode.

Structuur van het Feedbackbericht

Het feedbackbericht heeft een compacte, vaste structuur die is geoptimaliseerd voor het terugkoppelen van statusinformatie. De onderstaande afbeelding (eveneens beschikbaar op Github onder berichtenoverzicht en in de MessageStructureView van het bericht.) toont de hiërarchische opbouw en de belangrijkste entiteiten.

De kern van het bericht wordt gevormd door de volgende componenten:

• commonTechnical: Bevat de technische identificatie van het feedbackbericht zelf, zoals een nieuwe, unieke messageId. Daarnaast kan optioneel een party-blok worden opgenomen met informatie over de sender en receiver van het bericht, ter ondersteuning van routering en voor consistentie met andere commonTechnical-structuren (#90).

• commonFunctional: Bevat de functionele metadata, waaronder:

• statusType: De status van het oorspronkelijke bericht: Geaccepteerd (8) of Afgewezen (0).

• originalMessageId: Een verplichte verwijzing naar de messageId van het bericht waarop deze feedback betrekking heeft.

• originalMessageType: Een optioneel veld dat het type van het oorspronkelijke bericht aangeeft, om routering bij de ontvanger te vereenvoudigen.

• error: Een optioneel blok dat, in geval van afwijzing, een errorCode en een errorCodeExplanation bevat.

• party.pensionProvider: Identificeert de pensioenuitvoerder waarop het oorspronkelijke bericht betrekking had.

Voor een gedetailleerde specificatie van alle attributen en codelijsten, zie de paragrafen 6.5 en 6.4.16.

Interactiepatronen en Procesflow

De technische afhandeling van de feedback is vastgelegd in de OpenAPI Specificatie (OAS) en volgt zes vaste scenario's. Deze beschrijven zowel synchrone als asynchrone verwerking, inclusief de afhandeling van fouten en "paniek"-situaties waarin de feedback-loop zelf faalt.

Een visueel overzicht van deze scenario's is te vinden op GitHub: Feedback activity diagram.

De scenario's worden hieronder functioneel toegelicht.

1. Synchrone validatie - Succes: Direct 200 OK.

2. Synchrone validatie - Fout: Direct 400 Bad Request met een feedbackbericht in de body.

3. Asynchrone validatie - Succes: Eerst 202 Accepted, later gevolgd door een callback met een "Geaccepteerd" feedbackbericht.

4. Asynchrone validatie - Fout: Eerst 202 Accepted, later gevolgd door een callback met een "Afgewezen" feedbackbericht.

5. Paniek-scenario (na Fout): De callback met "Afgewezen" feedback wordt door de ontvanger niet geaccepteerd (400 Bad Request).

6. Paniek-scenario (na Succes): De callback met "Geaccepteerd" feedback wordt door de ontvanger niet geaccepteerd (400 Bad Request).

In paniek-scenario's (5 en 6) is handmatige afstemming via een ander kanaal noodzakelijk.

Protocol voor Correcties en Herverzendingen

Het feedbackmechanisme dicteert het protocol voor het corrigeren van berichten. Dit protocol is gebaseerd op het fundamentele uitgangspunt:

"Eenmaal geaccepteerde berichten worden niet eenzijdig gecorrigeerd."

Het ontvangen feedbackbericht is de primaire vorm van communicatie die bepaalt hoe met een correctie moet worden omgegaan.

Scenario 1: Correctie na een Foutmelding (Feedback "Afgewezen")
Als de ontvangende partij een feedbackbericht heeft verstuurd met de status "Afgewezen", fungeert dit als het officiële verzoek tot correctie.

• De ontvangende partij verwacht een nieuw, gecorrigeerd bericht.

• De verzendende partij mag en moet een gecorrigeerd bericht sturen zonder verdere, aparte afstemming.

Scenario 2: Correctie na Acceptatie van een bericht

Dit scenario treedt op als een bericht succesvol is geaccepteerd (via een 200 OK) en de verzendende partij achteraf een fout ontdekt. Omdat er geen officiële trigger is voor een correctie is het eenzijdig sturen van een nieuwe versie van het bericht (een correctiebericht) niet toegestaan.

Een bericht met een reeds gebruikte messageId wordt door de ontvangende partij behandeld als een duplicaatbericht. Dit betreft bijvoorbeeld hergebruik van een bestaande messageId of een netwerk-retry van een eerder verwerkt bericht.

Een duplicaatbericht wordt afgewezen met: - HTTP 400 Bad Request - een Feedbackbericht in de response body

Het Feedbackbericht bevat in ieder geval: - originalMessageId - statusType = Afgewezen (0) - errorCode - errorCodeExplanation

De errorCode identificeert het type fout. De errorCodeExplanation beschrijft dat sprake is van een reeds gebruikte of niet-unieke messageId.

In dit soort situaties moet de verzendende partij contact opnemen met de ontvangende partij om de situatie te bespreken. De uitkomst van dit overleg bepaalt de vervolgactie. Mogelijke oplossingen zijn:

• Ad hoc akkoord voor herzending.
• Correctie in de volgende reguliere aanlevering.
• Het volgen van een afgesproken incidentenprocedure.

Functionele uitval bij orderverwerking

Een order die functioneel niet uitvoerbaar is — bijvoorbeeld door een onbekend fonds of een ongeldige combinatie van instructievelden — wordt door de ontvangende partij teruggekoppeld via het feedbackbericht. Het feedbackbericht bevat:

• statusType = Afgewezen (0)
• een errorCode die het type uitval classificeert
• een errorCodeExplanation met een leesbare toelichting

De terugkoppeling volgt de synchrone of asynchrone interactiepatronen zoals hierboven beschreven. Zie GitHub issue #132.

Overmacht en termijnen

Situaties van overmacht vallen buiten de scope van de VB-PUO-standaard. De standaard voorziet niet in een apart bericht of statuscode voor overmacht; de afhandeling hiervan is een zaak van bilaterale afspraken tussen ketenpartijen, bijvoorbeeld in een SLA of TOM.

Daarnaast legt de standaard geen normatieve termijnen vast voor terugkoppeling. De snelheid waarmee een feedbackbericht wordt verstuurd na ontvangst van een inhoudelijk bericht, is onderwerp van operationele afspraken tussen de betrokken partijen. Zie GitHub issue #132.

---

1. Bijvoorbeeld kan binnen cohortenpool A de (strategische) verdeling van de beleggingen 30% beleggingspool I en 70% beleggingspool II zijn. Bij cohortenpool B kan verdeling 40: 60 zijn. ↩

2. In bijlage 10.3 "Proces flow & data-uitwisseling FPR" zijn de proces flow schema's in een groter formaat opgenomen. ↩

3. Reconciliatie tussen FM en BA is niet in scope voor de gegevensuitwisseling maar de reconciliatie tussen de BA, de FM en de PUO is in scope voor de gegevensuitwisseling. ↩

5 Aanpak/opzet gegevensstandaard

In dit hoofdstuk leggen we uit hoe we komen tot specificaties van de berichten.

Stappen om te komen tot de functionele specificaties van de berichten:

1. Maak beschrijvingen van de processen en informatiestromen.

2. Stel een lijst op met entiteiten en bijbehorende attributen.

3. Bepaal de basisstructuur van de berichten.

4. Geef aan welke berichten nodig zijn.

5. Maak een kruistabel tussen de basisstructuur en de berichten.

   De relatie met SIVI AFS leggen we uit. De bouwstenen uit SIVI AFS (AFD 2.0) gebruiken we om tot technische specificaties te komen.

5.1 Maak beschrijvingen van de processen en informatiestromen

Om de koppelvlakken inclusief berichtuitwisseling tussen partijen in de keten(s) te kunnen standaardiseren maken we beschrijvingen van de verschillende ketenprocessen zoals die plaatsvinden, inclusief op hoofdlijnen de gewenste functionaliteit bij de ketenactoren. Tevens geven we aan welke informatiestromen aan de orde zijn. Gevisualiseerde afbeeldingen van de informatiestromen tussen partijen zijn hierbij een hulpmiddel.

De processen & informatiestromen staan uitvoering beschreven in het rapport ‘’Resultaten onderzoek: Standaard voor data-uitwisseling pensioenuitvoering & vermogensbeheer partijen’’:

Hoofdstuk 4: Solidaire premieregeling.

Hoofdstuk 5: Flexibele premieregeling.

Zie ook hoofdstuk 3 van deze handleiding.

5.2 Stel een lijst op met entiteiten en bijbehorende attributen

Maak definities van entiteiten en attributen. Maak waar mogelijk gebruik van codelijsten, waarbij de voorkeur uitgaat naar bestaande codelijsten. Geef ook de vereiste verbanden tussen de gegevenselementen aan. Iedere entiteit en ieder attribuut krijgt op technisch niveau ook een label. De labels worden met bijbehorende waarden opgenomen in een bericht. Een computer kan hierdoor de gegevens uit het bericht automatisch verwerken. In Figuur 10 zijn de bouwstenen van een gegevensmodel opgenomen.

Figuur 10 – Bouwstenen gegevensmodel

5.3 Bepaal de basisstructuur van de berichten

Maak tevens de opbouw van de berichten duidelijk, bijvoorbeeld:

Entiteit A	V
Entiteit B*	V, 1… 999
Entiteit C	V, 1
Entiteit D	F, 1

Entiteit A komt 1 keer verplicht voor.

Entiteit B komt minimaal 1 keer voor en maximaal 999 keer.

Entiteit C is genest onder entiteit B en komt verplicht 1 keer voor.

Entiteit D is genest onder entiteit B en komt maximaal 1 keer voor.

5.4 Geef aan welke berichten nodig zijn.

Stel op basis van de beschrijvingen van de processen en informatiestromen vast welke berichten nodig zijn.

5.5 Maak een kruistabel tussen de basisstructuur en de berichten.

Geef per bericht in de tabel aan welke entiteiten/attributen van toepassing. Geef hierbij het aantal herhalingen (entiteiten) aan en geef ook aan welke attributen verplicht gevuld moeten worden. Het is tevens mogelijk selecties uit codelijsten te maken, dat wil zeggen aan te geven welke codewaarden van toepassing zijn.

Onderstaande Figuur 11 geeft aan hoe we vanuit een verzameling entiteiten/attributen meerdere basisstructuren opstellen en hoe we van iedere basisstructuur meerdere functionele berichten kunnen afleiden. Tenslotte leveren we technische berichtspecificaties. Figuur 11 licht een en ander toe.

Figuur 11 - Van entiteiten naar basisstructuur naar functionele berichten naar technische berichtdefinities

5.6 Relatie met SIVI AFS

Het Engelstalige AFD 2.0 is onderdeel van de SIVI All Finance Standaard. Via AFD 2.0 Online Raadplegen kun je online zoeken op alle entiteiten, attributen en codelijsten. Aanvullend vind je ook een overzicht van AFD 2.0 in XLS-formaat. Pensioen is tot op zekere hoogte al in AFD 2.0 aanwezig. Dit heeft onder andere te maken met de mapping die SIVI ontwikkelde voor het Ockto Datamodel. Ockto heeft een koppeling met pensioenregister. Gebruik van JSON is een uitgangspunt bij AFD 2.0.

AFD 2.0 bevat bouwstenen die we gebruiken bij het specificeren van de entiteiten en attributen ten behoeve van de standaard voor data-uitwisseling tussen vermogensbeheer en pensioenuitvoering. Hierbij geven we aan welke AFD 2.0 bouwstenen we gebruiken en welke bouwstenen ontbreken. Deze laatste kan SIVI dan aan AFD 2.0 toevoegen. Naast entiteiten/attributen kan het daarbij ook gaan om codelijsten.

Hoofdstuk 6: Functionele specificaties

6 Functionele specificaties

In dit hoofdstuk volgen de functionele specificaties:

• Datadictionary;

• Basisbericht;

• Kruisreferentie basisbericht & berichten.

6.1 Datadictionary

De datadictionary geeft een overzicht van alle gebruikte entiteiten en entiteittypen die worden gebruikt binnen deze standaard.

Entity.entitytype
commonTechnical.default
party.sender
party.contact
party.receiver
commonFunctional.default
party.pensionProvider
pension.scheme
financialInformation.reportingPeriod
financialTransaction.payment
party.creditor
financialTransaction.cashflow
financialTransaction.expectedPayment
pension.cohort
pension.cohortPool
investment.pool
investment.portfolio
investment.investmentDetails
investment.corporateAction
financialTransaction.trade
error.default
document.default
chunking.default

6.2 Entiteiten en entiteitstypen

In deze paragraaf zijn de diverse entiteiten en de attributen binnen die entiteiten beschreven.

Hieronder volgt een toelichting op de entiteiten. Deze informatie is ontleend aan AFD 2.0 wat via deze link kan worden geraadpleegd.

Let op: het entiteittype is verplicht.

Entiteit.entiteittype	Toelichting
commonTechnical.default	Deze entiteit bevat technische details over het verzenden en opslaan van berichten. Het vormt als het ware de basis voor de technische aspecten binnen het berichtensysteem.
party.sender	De entiteit "party.sender" verwijst naar de afzender van het bericht.
party.contact	De entiteit "party.contact" vertegenwoordigt een contactpersoon binnen een juridische entiteit. Deze contactpersonen kunnen worden benaderd voor verdere informatie over het bericht.
party.receiver	Deze entiteit vertegenwoordigt de ontvanger van het bericht.
commonFunctional	Binnen deze entiteit bevindt zich domeinspecifieke informatie over de inhoud van het bericht. Het geeft context en betekenis aan de functioneledetails in het bericht.
party.pensioenProvider	Deze entiteit staat voor een pensioenuitvoerder, Een pensioenuitvoerder is een pensioenfonds, verzekeraar of premiepensioeninstelling (PPI) waar pensioen wordt opgebouwd voor de werknemer door de werkgever.
pension.scheme	Deze entiteit is bevat gegevens op het niveau van de pensioenregeling of het pensioenplan of -schema.
financialInformation.reportingPeriod	Deze entiteit heeft betrekking op rapportageperiodes, tijdsintervallen waarvoor wordt gerapporteerd en andere generieke datums.
financialTransaction.payment	Deze combinatie van entiteit en entiteittype gegevens over een betaling.
party.creditor	Deze entiteit vertegenwoordigt de crediteur; de ontvanger van de betalingen, binnen het ecosysteem waarin de berichten worden uitgewisseld.
financialTransaction.cashflow	Deze entiteit behandelt financiële transacties met betrekking tot pensioenen, specifiek gericht op kasstromen.
financialTransaction.Payment	Deze entiteit bevat informatie over betalingen en toekomstige kasstromen/betalingen.
pension.cohort	Deze entiteit bevat informatie over specifieke doelgroepen binnen het pensioenschema.
pension.cohortPool	De gepoolde (verzamelde) combinatie van beleggingspools voor een cohort.) Bij FPR wordt óf individueel belegd (via trades in investments) of wordt gezamenlijk belegd in investmentpools via cohortPools. In deze entiteit worden de gegevens over het pensioenvermogen en de in- en uitstroom voor een gepoolde (verzamelde) combinatie van beleggingen (beleggingspools) voor een cohort vastgelegd. In een cohortpool wordt belegd voor een groep deelnemers die op basis van de mate van risico een gelijke beleggingsverdeling kennen.
investment.pool	Deze entiteit (beleggingspool) vertegenwoordigt de collecties van uiteenlopende onderliggende beleggingen (liquide, illiquide, fondsen en mandaten).
investment.portfolio	Deze entiteit heeft betrekking op beleggingsportefeuilles, die het totaal beheerde vermogen (of een deelvermogen) binnen het collectief weergeven.
investment.investmentdetails	Deze entiteit beschrijft individuele beleggingen van een pensioenuitvoerder in aandelen of beleggingsfondsen.
investment.corporateAction	Deze entiteit bevat gegevens over corporate-action gebeurtenissen op beleggingsproducten, zoals cash dividend, stockdividend, rebate, unit- en kapitaalverschuivingen en productwijzigingen. Het bericht is bedoeld voor het doorgeven van dergelijke gebeurtenissen vanuit de vermogensbeheerketen aan de PUO.
financialTransaction.trade	Deze entiteit heeft betrekking op handelsactiviteiten binnen het pensioenschema.
error	In het geval van fouten in het systeem wordt deze entiteit gebruikt om foutmeldingen te genereren en aan te geven wat er precies mis is gegaan.
document	Deze entiteit is bedoeld voor het toevoegen van eventuele bijlagen aan berichten.
chunking.default	Deze entiteit bevat metadata voor het opsplitsen en samenvoegen van grote berichten in deelberichten (chunking). Indien aanwezig, geeft het aan dat het bericht een deel van een groter logisch bericht is.

6.3 Attributen in entiteiten.entiteitstypen

In de tabellen in deze paragraaf worden de attributen per combinatie van entiteit en entiteitstype beschreven. De beschrijving bevat naast de attribuutnaam een definitie van het attribuut, het datatype van het attribuut, de beoogde maximale lengte van het gegeven en een verwijzing (link) naar een eventuele codelijst.

PM de omschrijving van de attributen in de feedback message kan afwijken van de omschrijving in de inhoudelijke berichten.

De beschrijving van de gebruikte datatypen is te vinden in de manual sivi-all-finance-standard.

Bij het interpreteren van de tabellen hierna is het volgende van belang:

• Datatype string: In de tabellen hierna wordt bij strings het maximum aantal posities vermeld tenzij wordt verwezen naar een codelijst of een opsomming. In die gevallen is “lengte” leeg.

• Datatype decimal: heeft in principe maximaal 2 plaatsten achter de “,” (1E-2). Bij afwijking daarvan wordt dat vermeld in de kolom datatype.

De attribuutnamen wijken af van de naamgeving in het consultatiedocument; ze zijn nu – mede – vormgegeven op basis van de AFD 2.0 conventies. In de bijlage 8.4 is de “Vertaaltabel van functionele attributen naar AFD2.0 attributen.

Gebruik van refKey

In de tabellen hieronder komt bij vrijwel elke entiteit het attribuut refKey voor. Dit attribuut dient als unieke identifier van een entiteit. Het doel is dat een entiteit binnen of tussen berichten en bestanden betrouwbaar kan worden herkend en dat ernaar kan worden verwezen — zoals een ISIN een beleggingsinstrument identificeert zonder iets te zeggen over het beleggingsbeleid dat erop van toepassing is.

refKey mag technisch of functioneel herkenbaar zijn, maar er mag geen classificatie, beleggingsbeleid of businesslogica uit worden afgeleid. De inhoudelijke classificatie hoort in de daarvoor bestemde velden (bijvoorbeeld reserveType).

Zie GitHub issue #111.

commonTechnical.default [T1]

Unieke berichtidentificatie

Attribuutnaam	Definitie	datatype	lengte	Codelijst
messageId	Unieke berichtidentificatie	string	70
creationDateTime	Aanmaakdatum en tijd Date	timestamp
testMessage	Indicatie testbericht	boolean

Uniciteit van messageId

De messageId is altijd uniek over alle berichten heen, ongeacht berichtsoort of periode. Gebruik van de messageId voor het groeperen of bundelen van berichten is niet toegestaan. Eventuele samenhang tussen berichten wordt afgeleid uit inhoudelijke kenmerken, zoals de periode waarop het bericht betrekking heeft.

De enige uitzondering is chunking (§7.6): chunks van hetzelfde logische bericht delen dezelfde messageId.

Zie GitHub issue #108.

party.sender [T2]

Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string	70
rsinNumber	Governmental identification number for legal entities and associations (RSIN)	string	9
organizationName	Organisatie naam van de afzender	string	60
applicationSenderName	Naam van de applicatie die het bericht heeft aangemaakt*	string	60

^* applicationSendername is in AFD 2.0 zowel beschikbaar onder party.sender als onder commonTechnical. Dat blijkt inderdaad niet uit de AFD 2.0 Online raadplegen documentatie (per april 2024). Er is voor gekozen om het attribuut voor VBPUO te plaatsen onder party.sender. ↩︎

party.contact [T3]

Werk emailadres

Attribuutnaam	Definitie	datatype	lengte	Codelijst
emailWork	Werk emailadres	string	60
workPhoneNumber	Werk telefoonnummer	string	60

party.receiver [T4]

Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string	70
rsinNumber	Governmental identification number for legal entities and associations (RSIN)	string	9
organizationName	Naam van de ontvanger(s) (organisatie (s))	string	60

commonFunctional.default [T5]

Message function code. (NL: Code waarmee de functie van het bericht wordt aangegeven.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
function	Message function code. (NL: Code waarmee de functie van het bericht wordt aangegeven.)	string		ADNFUN (01; 02;09;54 of 23)
statusType	Status of the proccessing of the original message for which the status and/or errors are being sent to the Feedback endpoint. Message statuses are either 'Accepted (8 - Geaccepteerd)' or 'Not Accepted (0 - Afgewezen).	string		ADNSTS (0; 8)
afdDefinitionName	Soort bericht	string	80
afdDefinitionVersion	Versie van de standaard	string	80
originalMessageId	Het oorspronkelijke messageId van het bericht dat wordt vervangen door dit bericht	string	70
originalMessageType	Message type of the original request to which this message is a response. (NL: Berichtsoort van het oorspronkelijke bericht waarop dit bericht een response is.). Bijvoorbeeld: 0001a uit “Berichtstructuur 1. Vermogen (0001a)”	string		0001a; 0001b; 0001c; 00002; 00541; 00542; 00551; 00552a; 00552b; 00553; 00554; 00555a; 00555b; 00556

party.pensionProvider [T6]

ID van het pensioenuitvoerder (PUV-code) / Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
puvCode	ID van het pensioenuitvoerder (PUV-code) / Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string		AFDIDP (U0003; U0005; ... ;U0765)
rsinNumber	Governmental identification number for legal entities and associations (RSIN)	string	9
organizationName	Naam van de pensioenuitvoerder	string	60

Bij APF's met meerdere kringen zijn er twee gangbare scenario's voor het gebruik van PUV-codes. Zie de toelichting bij het basisbericht in §6.4.1.

pension.scheme [T7]

ID van de pensioenregeling / (Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.))

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	ID van de pensioenregeling / (Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.))	string	70
pensionSchemeName	Naam van de pensioenregeling	string	60
startAmount	Totaal pensioenvermogen per startdatum	decimal
tradingPortfolioId	Portefeuille ID van de custodian (bewaren en beheren van financiële activa)	string	10

financialInformation.reportingPeriod [T8]

Begindatum van de gegevensperiode waarop de aanlevering vanuit de PUO wordt gebaseerd of Peildatum

Attribuutnaam	Definitie	datatype	lengte	Codelijst
startDate	Begindatum van de gegevensperiode waarop de aanlevering vanuit de PUO wordt gebaseerd of Peildatum	date
endDate	Einddatum van de gegevensperiode waarop de aanlevering vanuit de PUO wordt gebaseerd	date
mutationValuationDate	Datum verwerking mutaties per leeftijdsgroep	date
tradeDate	Gewenste handelsdatum	date
investmentOrderSettlementDate	Datum waarop de volledige cyclus van de beleggingsorder afgewikkeld moet zijn	date
projectionDate	Datum van de projectie van pensioenuitkeringen	date
instructionDate	Instructiedatum (datum van de bestelling verzonden door de PUO)	date
unitValueEstimationDate	Geeft de datum aan waarop de voorlopige unitwaarde (belegginspool) is bepaald	date
participationValuationDate	Prijsdatum participatiewaarde (cohortpool)	date
valueDate	Currency date. (NL: Valutadatum)	date
positionDate	De datum waarop de posities in de beleggingsadministratie zijn vastgesteld	date

Datumconventies voor startDate en projectionDate

Om inconsistent gebruik van datums tussen ketenpartijen te voorkomen, hanteert de standaard de volgende conventie:

Veld	Bericht	Conventie	Voorbeeld
startDate	Bericht 1 (Vermogen)	Laatste dag van de voorgaande maand	31-01-2025
projectionDate	Bericht 3 (Pensioenprojectie)	Laatste dag van de voorgaande maand	31-01-2025
firstExpectedPaymentDate	Bericht 3 (Pensioenprojectie)	Eerste dag van de lopende maand	01-02-2025

Deze aanpak biedt duidelijkheid en voorspelbaarheid in de keten. Zie GitHub issue #94.

financialTransaction.payment [T9]

Bedrag in valuta

Attribuutnaam	Definitie	datatype	lengte	Codelijst
amount	Bedrag in valuta	decimal
currencyType	Valuta	string		ISOVAL (EUR; USD; …)
collectionAccountIban	IBAN-nummer van debet rekening	string	34
description	Omschrijving van de transactie (betaling)	string	60
refKey	ID van de expected payment	string	70
expectedPensionPaymentDate	Pensioenuitkeringsmoment	date
hedgedExpectedPensionPaymentAmount	Af te dekken kasstroom over alle cohorten	decimal

Veldlengte `collectionAccountIban` gecorrigeerd van 10 naar 34 (internationale IBAN-maxlengte conform ISO 13616). Zie GitHub issue [#135](https://github.com/Stichting-SIVI/VBPUOdsk/issues/135).

party.creditor [T10]

Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string	70
collectionAccountIban	IBAN-nummer van credit rekening per regeling	string	34
collectionAccountInNameOf	Naam van de tegenpartij per regeling	string	60
collectionAccountBic	Business Identifier Code (BIC) per regeling	string	10
collectionAccountBicCorrespondent	BIC-correspondent per regeling	string	10

Veldlengte `collectionAccountIban` gecorrigeerd van 10 naar 34. Zie GitHub issue [#135](https://github.com/Stichting-SIVI/VBPUOdsk/issues/135).

financialTransaction.cashflow [T11]

Som van inleg

Attribuutnaam	Definitie	datatype	lengte	Codelijst
contributionAmount	Som van inleg	decimal
contributionDate	Datum van ontvangst van de inleg	date
withdrawalAmount	Som van de uitstroom	decimal
withdrawalDate	Datum waarop (uiterlijk) de liquiditeiten ten behoeve van de onttrekking zijn vrijgemaakt	date
netAmount	Som van inleg en onttrekkingen per regeling (net). Een negatief bedrag is een (netto) withdrawal. / Verschil tussen inleg en onttrekking. Een negatief bedrag is een (netto) onttrekking.)	decimal
netDate	De valutadatum waarop het gesaldeerde netto kasstroombedrag (inleg minus onttrekking) daadwerkelijk door de PUO wordt betaald aan, of ontvangen van, de Vermogensbeheerder	date
netAmount	Gesaldeerd netto kasstroombedrag per beleggingsportefeuille binnen een regeling. Een negatief bedrag is een netto onttrekking.	decimal
netDate	De valutadatum waarop het netto kasstroombedrag per beleggingsportefeuille daadwerkelijk door de PUO wordt betaald aan, of ontvangen van, de Vermogensbeheerder	date

Veldgebruik in financialTransaction.cashflow

In de SPR-context wordt financialTransaction.cashflow direct onder pension.scheme gebruikt; daarbij zijn de bedrag- en datumvelden optioneel. Partijen stemmen onderling af welke bedrag/datum-combinaties zij gebruiken; in het JSON-schema zijn alle velden optioneel. Bij gebruik van de entiteit wordt minimaal één combinatie gevuld.

In de FPR-context wordt de financialTransaction.cashflow entiteit onder investment.portfolio gebruikt en zijn netAmount en netDate verplicht.

pension.cohort [T12]

ID van het cohort

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	ID van het cohort	string	70
description	Beschrijving van het cohort	string	60
participationStatus	Status van de deelnemers in een cohort	string		ADNDNS (16; 20; 35; 40; 70; 80)
startAge	Startleeftijd in maanden	integer
endAge	Eindleeftijd in maanden	integer
reserveIndicator	Indicatie of het cohort een reserve weerspiegelt	boolean
reserveType	Keuze van het type (reserve feitelijk een) voorziening / type of provision. Bij gedeeld beleggingsbeleid kan worden ingedikt; expliciete code alleen bij separaat beleggingsbeleid.	string		AFDRES (1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 99)
reserveDescription	Beschrijving de reserve bij keuze van "Overige" in reserve type.	string	60
startAmount	Pensioenvermogen van het cohort per begindatum	decimal
netAmount	Som van inleg en onttrekkingen per cohort. Een negatief bedrag is een (netto) onttrekking.)	decimal
netDate	De valutadatum waarop het gesaldeerde netto kasstroombedrag voor het cohort daadwerkelijk door de PUO wordt betaald aan, of ontvangen van, de Vermogensbeheerder	date
contributionAmount	Instroom te beleggen door de fiduciair manager	decimal
withdrawalAmount	Uitstroom te beleggen door de fiduciair manager	decimal
protectionReturnPercentage	Het behaalde beschermingsrendement in percentage over gegevensperiode per regeling en per cohort	decimal (1E-12)
excessReturnPercentage	Het behaalde overrendement in percentage over gegevensperiode per regeling en per cohort	decimal (1E-12)
protectionReturnAmount	Het behaalde beschermingsrendement in valuta van de regeling over gegevensperiode per regeling en per cohort	decimal
excessReturnAmount	Het behaalde overrendement in valuta van de regeling over gegevensperiode per regeling en per cohort	decimal

Leeftijdscohorten: standaardinrichting

In de standaardinrichting worden jaarlijkse leeftijdscohorten gebruikt. Dit betekent dat tussen twee opeenvolgende startAge-waarden in beginsel een verschil van 12 maanden wordt gehanteerd: startAge is een veelvoud van 12 (0, 12, 24, ...) en endAge = startAge + 11. Kleinere stappen (bijvoorbeeld maandelijks) zijn niet uitgesloten, maar de jaarlijkse indeling geldt als referentiemodel. Zie GitHub issue #111.

Reserves en voorzieningen: rolverdeling van velden

Voor cohorten die een reserve of voorziening vertegenwoordigen (reserveIndicator = true) geldt de volgende rolverdeling:

• reserveType (codelijst AFDRES) is de inhoudelijke classificatie en de uitsluitende sleutel voor het beleggingsbeleid. Reserves of voorzieningen met een verschillend beleggingsbeleid vereisen een verschillende reserveType-waarde. De codelijst is per release 2027 uitgebreid met codes 9 t/m 15. Bij gedeeld beleggingsbeleid kan worden ingedikt; een expliciete code is alleen nodig bij separaat beleggingsbeleid. Dit geldt voor zowel SPR als FPR. Zie GitHub issue #134.
• reserveDescription is uitsluitend beschrijvend. De omschrijving kan toelichten of verduidelijken, maar is niet bepalend voor classificatie, routering of beleggingsbeleid.
• refKey identificeert het cohort uniek (zie de algemene toelichting op refKey hierboven). Meerdere cohorten met hetzelfde reserveType zijn toegestaan, mits zij onder hetzelfde beleggingsbeleid vallen.

Zie GitHub issue #111.

investment.portfolio [T13]

ID Beleggingsportefeuille / Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	ID Beleggingsportefeuille / Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string	70
description	Beschrijving	string	60
startExposureAmount	De toedeling van het pensioenvermogen per cohort aan een specifieke investmentportfolio, berekend op basis van de toedelingsregels zoals door de PUO gehanteerd.)	decimal
startExposurePercentage	Het relatieve aandeel van startExposureAmount ten opzichte van het totale pensioenvermogen per datum.)	decimal
startAmount	De waarde van de Total Market Value aan het begin van de gegevensperiode	decimal
netAmount	Som van inleg en onttrekkingen per regeling (net). Een negatief bedrag is een (netto) withdrawal	decimal
endAmount	De waarde van de Total Market Value aan het eind van de gegevensperiode. Per regeling en beleggingsportefeuille	decimal
returnPercentage	Het behaalde rendement in percentage over gegevensperiode per regeling en per beleggingsportefeuille	decimal (1E-12)
returnAmount	Het behaalde rendement in valuta van de regeling over gegevensperiode per regeling en per beleggingsportefeuille	decimal

pension.cohortPool [T14]

ID van de cohortpool

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	ID van de cohortpool	string	70
cohortRef	Geeft aan op welk cohort in de regeling de cohortpool-gegevens betrekking hebben	string	70
description	Beschrijving	string	60
currencyType	Valuta van de cohortgegevens	string		ISOVAL (EUR; USD; …)
inflowPremiumAmount	Premie-inleg per cohortpool per regeling	decimal
inflowRebalanceAmount	Geldbedrag van rebalance transacties per cohortpool per regeling	decimal
numberOfNewParticipations	Nieuwe uit te geven participaties in cohortpool per regeling (instroom)	decimal (1E-06)
numberOfParticipations	Aantal uitstaande units (participaties) in de Cohortpool	decimal (1E-06)
numberOfRebalanceParticipations	Rebalance participaties per cohortpool per regeling (bij overgang van een cohortpool naar een ander cohort)	decimal (1E-06)
participationsSummedValueAmount	Waarde per cohortpool (som participatiewaarde) per participationValuationDate	decimal

investment.pool [T15]

Beleggingspool / beleggingsportefeuille

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	ID van de beleggingspool per regeling	string	70
description	Beschrijving	string	60
unitsSummedValueAmount	Waarde per beleggingspool(unitwaarde)	decimal
preliminaryUnitValueAmount	De door de beleggingsadministrateur vastgestelde netto vermogenswaarde (NAV) per unit van de beleggingspool	decimal (1E-06)
numberOfUnits	Aantal units uitgegeven voor de beleggingspool,	decimal (1E-06)
currencyType	Valuta van de pool	string		ISOVAL (EUR; USD; …)
buySellId	Aan- verkoopindicator; ID voor aan-/verkoop per beleggingspool per regeling per cohort	string		sell, buy
tradeValueAmount	Waarde transactie per beleggingspool per regeling (gesommeerd over cohorten)	decimal

`marketValueAmount` is per release 2027 uit de standaard verwijderd; de netto vermogenswaarde wordt uitsluitend via `preliminaryUnitValueAmount` uitgedrukt. De veldnaam `preliminary` is historisch gegroeid en wordt in een toekomstige release opgeschoond. Zie GitHub issue [#128](https://github.com/Stichting-SIVI/VBPUOdsk/issues/128).

investment.investmentDetails [T16]

Identifier (bijvoorbeeld ISIN of interne code)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	Identifier (bijvoorbeeld ISIN of interne code)	string	70
description	De naam van de belegging / de officiële naam van het fonds / van het instrument	string	60
currencyType	Valuta van het instrument	string		ISOVAL (EUR; USD; …)
numberOfUnits	Aantal aangekochte units per instrument per regeling per beleggingsportefeuille	decimal (1E-06)
numberOfHoldings	Aantal holdings per instrument per regeling per beleggingsportefeuille	decimal (1E-06)
localPrice	Prijs per instrument in originele valuta per regeling per beleggingsportefeuille	decimal (1E-06)
localValueAmount	Totale marktwaarde in originele valuta per instrument per regeling per beleggingsportefeuille[1]	decimal
result	Ongerealiseerd resultaat per instrument per regeling per beleggingsportefeuille	decimal
accruedInterest	Opgelopen rente per instrument per regeling per beleggingsportefeuille	decimal
poolPercentage	Gewicht in de portefeuille per instrument per regeling per beleggingsportefeuille[2]	decimal
currencyExchangeRate	FX rates per instrument per regeling per beleggingsportefeuille / koers per positionDate	decimal
tradeDate	handelsdatum (beoogd)	date

investment.corporateAction [T17]

Sleutel van de Corporate Action.

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	Sleutel van de Corporate Action.	string	70
description	Omschrijving van de Corporate Action.	string	60
corporateActionType	Type Corporate Action.	string		AFDCAE (cashDividend; productChange; rebate; stockDividend)
instructionDate	Instructiedatum van de Corporate Action.	date
tradeDate	Transactiedatum van de Corporate Action.	date
paymentDate	Betaaldatum van de Corporate Action.	date
cashDividendTotalAmount	Totaal contant bedrag van de Corporate Action.	decimal
cashDividendPerUnitAmount	Contant bedrag per eenheid.	decimal
currencyType	Valuta van het contante bedrag.	string	3	ISOVAL (EUR; USD; GBP; CHF; JPY)
stockDividendPerUnitNumber	Aantal stockdividend per eenheid.	decimal
stockDividendTotalNumber	Totaal aantal stockdividend.	decimal
newProductName	Naam van het nieuwe product.	string	60
newProductIdentifier	Identificatie van het nieuwe product.	string	60

financialTransaction.trade [T18]

handelsdatum (feitelijk)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
tradeDate	handelsdatum (feitelijk)	date
refKey	Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string	70
adjustmentIndicator	Aangepaste trade instructie	boolean
buySellId	Aan-, verkoop- of switchrichtingindicator	string		sell; buy; switchfrom; switchto
tradeAmount	Positief bedrag van de transactie in de valuta waarin de belegging luidt; richting volgt uit buySellId	decimal
tradeQuantity	Positief aantal te verhandelen stukken (units) van de transactie; richting volgt uit buySellId	decimal (1E-06)
tradePrice	Aankoopprijs / koers	decimal (1E-06)
switchType	Type switch; one-day of sequential	string		AFDSWI (sequential; one-day)
financialInformationRef	Verwijs hier bij switchfrom/switchto naar de refKey van de andere switch-leg ten behoeve van verbandscontrole.	array
counterparty	Transfer Agent; de partij die de aankoop/verkoop verricht	string	70
broker	Effectenmakelaar die beleggingsorders uitvoert namens klanten op de markt	string	70
interestAmount	Bedrag aan van toepassing zijnde rente	decimal
commissionAmount	Vergoeding voor het uitvoeren van de transactie	decimal
clearingBroker	Effectenmakelaar verantwoordelijk administratieve en financiële afwikkeling van de transactie	string	70
clearingBrokerCashAccount	Geldrekening (IBAN) bij de clearingbroker op naam van de Pensioenuitvoerder	string	18

error.default [Te]

Error message. (NL: Foutmelding)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string	70
errorCode	Error code type. (NL: Soort foutmelding code.)	string		ADNFTM (09; 11; 12; 13; 14; 99)
errorCodeExplanation	Explanation of the error message. (NL: Toelichting op de soort foutmelding.)	string	1000

Zie ook de informatie over de error.default in de SIVI All Finance Standard

document.default [T19]

Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
refKey	Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)	string	70
fileName	Name of the file under which the attachment can be saved. (NL: Naam van het bestand waaronder de bijlage kan worden opgeslagen.)	string	60
fileExtension	Extension of the file under which the attachment can be saved. For example "pdf", "doc", etc. (NL: Extensienaam van het bestand waaronder de bijlage kan worden opgeslagen. Bijvoorbeeld "PDF", "DOC", etc.)	string		pdf; csv; txt

chunking.default [T20]

Unique reference (id) of the current chunk. (NL: Unieke referentie van de huidige chunk.)

Attribuutnaam	Definitie	datatype	lengte	Codelijst
currentChunkId	Unique reference (id) of the current chunk. (NL: Unieke referentie van de huidige chunk.)	string	70
chunkSequenceNumber	Sequence number of the current chunk. (NL: Volgnummer van de huidige chunk.)	integer
totalNumberOfChunks	Total number of chunks the message has been split into. (NL: Totale aantal chunks waarin het bericht is opgesplitst.)	integer
chunkFragmentPaths	Array of JMESPath references to the message fragments used within the current chunk. (NL: Array van JMESPath-verwijzingen naar de berichtdelen die gebruikt zijn binnen deze chunk.)	array

6.3.1 Verbandscontroles cashflowbericht (0001b)

Structuurregel: SPR-route en FPR-route zijn wederzijds uitsluitend

Per pension.scheme geldt exact één cashflowpatroon:

• SPR-route — de cashflow wordt direct onder pension.scheme opgenomen als financialTransaction.cashflow, met optionele uitsplitsing via pension.cohort.
• FPR-route — de cashflow wordt opgenomen per beleggingsportefeuille via pension.scheme → investment.portfolio → financialTransaction.cashflow.

Binnen één pension.scheme gelden de volgende uitsluitingsregels:

• Aanwezigheid van investment.portfolio → financialTransaction.cashflow wordt niet direct onder pension.scheme gevuld.
• Aanwezigheid van pension.cohort → investment.portfolio mag niet worden gebruikt.

Deze regel is een formele verbandscontrole: een bericht dat beide routes combineert of geen van beide toepast, is niet geldig.

Somcontroles bij cohortuitsplitsing (SPR-route)

Wanneer in de SPR-route pension.cohort wordt gebruikt als uitsplitsing van de cashflow op regelingniveau, moeten de detailbedragen aansluiten op het totaal. Dit is een reconciliatiecontrole: de controle dat de som van de afzonderlijke cohortbedragen overeenkomt met het eerder opgegeven bedrag op cohort-regelingniveau — ofwel, de onderdelen tellen op tot het geheel.

• scheme.netAmount = som(cohort.netAmount)
• scheme.contributionAmount = som(cohort.contributionAmount)
• scheme.withdrawalAmount = som(cohort.withdrawalAmount)

Deze somcontroles zijn van toepassing op de SPR-route en niet automatisch op de FPR-route. In het FPR-model worden cashflows per beleggingsportefeuille vastgelegd zonder een hiërarchie van scheme- naar cohortniveau; de somrelatie is daar niet definieerbaar. Pas deze controles uitsluitend toe wanneer totalen en onderliggende uitsplitsingen gelijktijdig aanwezig zijn.

Open punt (AOS)

De formele verwerking van M002-0001b-001 in SIVI AOS is nog niet afgerond. De verbandscontroles zijn functioneel vastgesteld; de technische borging volgt in een separate stap.

6.4: Berichten

6.4 Berichten

Het basisbericht wordt hierna uitgewerkt naar specifieke berichten. Vanaf release 2027 zijn 10 inhoudelijke berichten en het Feedbackbericht actief; 5 berichten uit het FPR gelaagde ordermodel zijn vervallen (zie markering in Tabel 12).

Onderstaande Tabel 12 geeft een overzicht van die berichten en tussen welke rollen ze worden uitgewisseld:

Berichtnaam	PUO	FM	BA	LDI
1. Vermogen (0001a)	van	naar
2. Cashflow (0001b)	van	naar
3. Pensioenprojectie (0001c)	van	naar		naar
4. Rendementsinformatie (00002)	naar		van
5. Orderopdracht (00541)	van		naar
6. Orderconfirmation (00542)	naar		van
10. Stuurinformatiebeleggingspools (00553)		naar	van
13. Waarde-informatie beleggingspool (00555b)	naar		van
14. Betaalinformatie (00556)	van	naar	van
15. Corporate Actions (00557)	naar	van	van
Feedback Message

Het Feedbackbericht kan zowel voor FPR als SPR worden gebruikt en is altijd een antwoord op een ontvangen bericht; een van de overige berichten.

Tabel 12 – Overzicht berichten tussen zenders en ontvangers

Legenda

• Pensioenuitvoeringsorganisaties (PUO) — hieronder vallen ook Zelf Administrerende Fondsen (ZAF)

• Fiduciair managers (FM)

• Beleggingsadministrateurs / asset serviceprovider (BA)

• Liability-Driven Investment-managers (LDI)

Toelichting: Administrateur cohorten- en beleggingspools (ACB) — vervallen

De rol ACB is als zelfstandige actor vervallen uit dit overzicht. In de praktijk wordt deze rol ingevuld door de BA of soms de PUO. Omdat de ACB-rol per juli 2026 niet meer als afzonderlijke partij voorkwam, is de kolom uit de matrix verwijderd. Mocht de ACB-rol in de toekomst opnieuw als expliciete partij optreden, dan biedt het berichtenschema via de aanwezige berichten nog steeds de mogelijkheid om daar invulling aan te geven. Zie GitHub issue #131.

Let op: Elke ontvangende partij/rol krijgt zijn informatie rechtstreeks van de verzendende partij. Ook de verzending naar niet in Tabel 12 genoemde partijen/rollen is rechtstreeks. Ontvangen informatie wordt niet doorgestuurd aan andere partijen.

In onderstaande tabel de berichtsoorten en de betekenis. Berichten die vanaf release 2027 zijn vervallen, zijn doorgehaald weergegeven. Tussen haakjes de verwijzing naar het eindrapport van de werkgroep¹: “Eindrapport onderzoek standaard VB PUO (september 2023.pdf”.

PMT = pensionMessageType in AFD 2.0 (aangegeven zijn de omschrijvingen van de berichttypes).

TAG = de in de API² gebruikte aanduiding voor het bericht.

Soort	Berichtsoort	PMT/ TAG	Omschrijving
SPR	1. Vermogen (0001a) (4.2.1.1)	Vermogen/ Capital	Van 🡪 Naar Van PUO naar FM en BA/asset serviceprovider. Op periodieke (naar verwachting maandelijkse) basis ontvangt de FM over een pensioenuitvoerder per regeling het totale pensioenvermogen bij aanvang van de periode. Naast de informatie op totaalniveau kan de FM ook per cohort het pensioenvermogen 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.
SPR	2. Cashflow (0001b) (4.2.1.3)	Cashflow/ Cashflow	Instroom en uitstroom Van 🡪 Naar Van PUO naar FM en BA/asset serviceprovider. Op periodieke (naar verwachting maandelijkse) basis ontvangt de FM over een pensioenuitvoerder per regeling de instroom in de periode en de uitstroom. Naast op totaalniveau kan ook per cohort instroom en uitstroom aangeleverd worden. 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. 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.
SPR	3. Pensioenprojectie (0001c) (4.2.1.3)	Pensioenprojectie/ PensionProjection	Geprojecteerde uitkeringen Van 🡪 Naar Van PUO naar FM en BA/asset serviceprovider. Op periodieke (verwachting is maandelijkse) basis ontvangt de FM van een pensioenuitvoerder per regeling en per cohort de geprojecteerde uitkeringen op basis van de opgebouwde vermogens naar toekomstige periodes. Tevens bevat de gegevensuitwisseling de af te dekken kasstromen per regeling 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. 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.
SPR	4. Rendementsinformatie (00002) (4.2.2.)	Rendementsinformatie/ ReturnOnInvestment	Informatiebehoefte PUO Van 🡪 Naar Informatiestroom van BA/asset serviceprovider naar de PUO. 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 voor een pensioenuitvoerder per regeling en per portefeuille de waarde aan het begin van de periode, de waarde aan het einde van de periode en het rendement in portefeuille valuta en (eventueel) uitgedrukt als percentage. De PUO draagt zorg voor de toedeling van rendementen naar deelnemers op basis van portefeuillerendementen. Optioneel kunnen ook per cohort in de regeling pensioenvermogen, beschermingsrendement en overrendement 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.
FPR	5. Orderopdracht (00541) (5.4.1.)	Orderopdracht/ Trade	Direct order (PUO belegt zelf) Van 🡪 Naar Informatiestroom van PUO naar Brokers/Transfer Agents/Order Desks. Dit is de minimale set aan gegevens die benodigd is om een order te kunnen sturen aan een order verwerkende partij. Tevens kan er een switch mee worden uitgevoerd. De PUO stuurt orders in op het hoogste niveau van het beleggingsfonds. De aanbieder van het fonds voert zelf de ordering uit in de onderliggende beleggingen. Dat kan onder andere genoteerde en illiquide beleggingen betreffen.
FPR	6. Orderconfirmation (00542) (5.4.2.)	Orderconfirmation	Direct order (PUO belegt via een order platform) Van 🡪 Naar Van brokers/transfer agents/order desks naar PUO. Vanuit de order verwerkende partij komen de confirmationtgegevens van de order terug naar de PUO.
FPR	7. Mutatiesaldi (00551) (5.5.1)	Mutatiesaldi/ BalanceAdjustments	Vervallen vanaf release 2027. Informatiebehoefte administrateur cohortenpools en beleggingspools Van 🡪 Naar Van PUO naar administrateur van cohortenpools en beleggingspools. De eerste (naar verwachting maandelijkse) informatiestroom van de PUO naar de administrateur van cohortenpools en beleggingspools betreft gesaldeerde mutaties, zijnde aankoop, verkoop en switches op totaalniveau per cohortenpool welke worden doorgegeven aan de administrateur cohortenpools en beleggingspools. Deze administrateur kan hiermee de in- of uitstroom voor beleggingspools berekenen en daarmee de FM instrueren.
FPR	8. Reconciliatie-informatie (00552a) (5.5.2)	Reconciliatie-informatie/ InvestmentDetails	Vervallen vanaf release 2027. Reconciliatie administrateur van cohortenpools en beleggingspools, FM en BA. Van 🡪 Naar Informatiestroom tussen administrateur van cohortenpools en beleggingspools, FM en BA. De administrateur cohortenpools en beleggingspools ontvangt maandelijks de posities uit de leidende administratie van de BA van de beleggingspools, mogelijk aangevuld uit de (schaduw) administratie van de FM. Deze posities worden gereconcilieerd met de posities in de eigen administratie van de administrateur van cohortenpools en beleggingspools.
FPR	9. PUO-reconciliatie-informatie (00552b) (5.5.2)	PUO-reconciliatie-informatie/ InvestmentDetailsPUO	Vervallen vanaf release 2027. Additionele informatie als de PUO (ook) de rol van administrateur van cohortenpools vervuld. Van 🡪 Naar Administrateur beleggingspools naar de PUO. Indien de PUO de rol van administrateur cohortenpools vervult dan is een additionele informatie-uitwisseling nodig van de administrateur beleggingspools naar de PUO over de voorlopige unitwaarden van de beleggingspools. Deze is in de onderstaande tabel weergegeven. Door ook het aantal uitgegeven units per beleggingspool te delen wordt de PUO in staat gesteld om de aansluiting bij het aantal gehouden units in de beleggingspools door alle cohortenpools te reconciliëren.
FPR	10. Stuurinformatie beleggingspools (00553) (5.5.3)	Stuurinformatie Beleggingspools/ ControlInformationInvestmentPools	Informatie aansturen beleggingspools Van 🡪 Naar Van PUO en/of BA naar FM (zie Figuur 8 en 9, stappen D en E). De PUO en/of de BA berekent de participatiewaarden van actieve leeftijdsgroepen en combineert deze waarden met de opgegeven mutaties om de casheffecten op de beleggingspools te schatten. De stuurinformatie op de beleggingspool (met onderbouwing) wordt verstuurd naar de FM in het volgende format.
FPR	11. Rebalancinginformatie (00554) (5.5.4)	Rebalancinginformatie/ RebalancingDetails	Vervallen vanaf release 2027. Rebalancing cohortenpools Van 🡪 Naar Informatiestroom tussen administrateur van cohortenpools en beleggingspools en FM. De administrateur van cohortenpools en beleggingspools herbalanceert de relevante leeftijdsgroepen om op basis van de unitwaarden van de beleggingspools van tijdstip T conform het normbeleid belegd te zijn voor alle cohorten. De administrateur van cohortenpools en beleggingspools verstuurt alle maandultimo transacties in de cohortenpools en beleggingspools in het afgesproken format naar de FM.
FPR	12. Waarde-informatie cohortenpool (00555a) (5.5.5)	Waarde-informatie cohortenpool/ ValueAmountCohortPool	Vervallen vanaf release 2027. Doorgeven waardes per beleggingspool en per cohortenpool (Fiduciair ontvangt van de PUO) Van 🡪 Naar Fiduciair ontvangt van de PUO (PUO administreert cohortenpools) De administrateur van cohortenpools en beleggingspools berekent de unitwaarde per unit in de beleggingspool en de participatiewaarde per participatie in de cohortenpool. Indien de PUO de rol van de administrateur cohortenpools vervult dan zal deze de unitwaarden van de beleggingspools ontvangen van de administrateur beleggingspools maar zelf zorgdragen voor de berekening van de participatiewaarden van de cohortenpools. De FM zal deze dan ook ontvangen van de PUO. De administrateur van cohortenpools en beleggingspools geeft daarnaast de gesommeerde (unit)waarden van beleggingspools door aan partijen.
FPR	13. Waarde-informatie beleggingspool (00555b) (5.5.5)	Waarde-informatie Beleggingspool/ ValueAmountInvestmentPool	Doorgeven waardes per beleggingspool en per cohortenpool Van 🡪 Naar Informatiestroom tussen BA, PUO en FM (zie Figuur 8 en 9, stap J). De BA berekent de unitwaarde per unit in de beleggingspool en de participatiewaarde per participatie in de cohortenpool. De BA geeft de (participatie)waarden van de cohortenpools door aan de PUO en aan de FM.
FPR	14. Betaalinformatie (00556) (5.5.6)	Betaalinformatie/ PaymentDetailsCreditor	Betaalinstructies onttrekkingen Van 🡪 Naar Informatiestroom van PUO of BA naar FM, begin van de maand (zie Figuur 8 en 9, stappen K en L). De PUO of de BA verstuurt de betaalinstructie voor onttrekkingen naar de FM.
FPR	15. Corporate Actions (00557)	Corporate Actions/ CorporateActions	Doorgeven corporate-action gebeurtenissen op beleggingsproducten Van 🡪 Naar Informatiestroom van de vermogensbeheerketen naar de PUO. Bericht 15 wordt gebruikt voor het doorgeven van corporate-action gebeurtenissen op beleggingsproducten vanuit de vermogensbeheerketen aan de PUO. Het bericht is bedoeld voor situaties waarin dergelijke gebeurtenissen wel binnen de vermogensbeheeradministratie worden verwerkt, maar niet automatisch zichtbaar zijn binnen de administratie van de PUO.
SPR/ FPR	Feedback Message	Feedback Message/ Feedback	Terugkoppeling van fouten of bevestigen van verwerkbaarheid. Van 🡪 Naar De ontvanger van het inhoudelijke bericht, de berichten 1 tot en met 15, is de verzender van de feedback message.

6.4.1 Basisbericht

De basisstructuur voor berichten (transactie) toont de hiërarchische verbanden tussen verschillende entiteiten in het gegevensmodel. De entiteiten en entiteitstypen vormen een samenhangende hiërarchie. Per definitie is het nodig om in uit te wisselen berichten een hiërarchie aan te brengen en de structuur van de transactie vormt hiervoor de basis. De structuur geeft onder meer aan welke onderliggende entiteit bij welke bovenliggende entiteit hoort.

In de kolom "Kardinaliteit" wordt weergegeven hoe vaak die entiteit dan minimaal en maximaal kan voorkomen.Met R (verplicht) of O (optioneel) wordt onder Kardinaliteit aangegeven of een entity.entitytype moet of mag voorkomen. Binnen het basisbericht zijn alle entiteiten optioneel gelaten.

Uit onderstaande tabel valt bijvoorbeeld af te leiden dat:

1) Per party.sender meerdere party.contact mogelijk

2) Per party.pensionProvider

1)  maximaal 1 financialInformation.reportingPeriod voorkomt en mogelijk

2)  meerdere pension.schema’s

Entity.entitytype	Kardinaliteit
commonTechnical.default	1..1, V
party.sender	1..1, V
party.contact	0..*, O
party.receiver	1..1, V
commonFunctional.default	1..1, V
party.pensionProvider	1..1, V
pension.scheme	1..*, V
financialInformation.reportingPeriod	1..1, V
financialTransaction.payment	0..*, O
party.creditor	1..*, V
financialTransaction.cashflow	0..1, O
pension.cohort	0..*, O
financialTransaction.payment	0..*, O
pension.cohortPool	0..*, O
investment.pool	1..*, V
investment.pool	0..*, O
investment.investmentDetails	1..*, V
investment.corporateAction	1..*, V
investment.portfolio	0..*, O
investment.investmentDetails	0..*, O
financialTransaction.trade	1..*, V
error.default	0..*, O
document.default	0..*, O
chunking.default	0..1, O

NB.in de technische implementatie is het aantal herhalingen (*) begrenst. Zie het overzicht hieronder:

Entity.entitytype	Maximumaantal iteraties
commonTechnical.default	1
party.sender	1
party.contact	9
party.receiver	1
commonFunctional.default	1
party.pensionProvider	1
pension.scheme	999
financialInformation.reportingPeriod	1
party.creditor	1
financialTransaction.cashflow	1
financialTransaction.payment	9999 of 999991
pension.cohort	99999
pension.cohortPool	99
investment.pool	99
investment.portfolio	99
investment.investmentDetails	999
investment.corporateAction	99
financialTransaction.trade	99
error.default	99
document.default	99
chunking.default	1

---

1. Het maximum aantal financialTransaction.payment onder pension.cohort is 9999 en onder pension.scheme blijft 99999.↩︎

APF-kringen: twee gangbare scenario's

Bij een Algemeen Pensioenfonds (APF) met meerdere kringen is er per kring één pension.scheme onder één party.pensionProvider. In de markt bestaan twee scenario's naast elkaar:

Scenario 1 — Kring heeft een eigen PUV-code Elke kring wordt geïdentificeerd met een eigen puvCode in party.pensionProvider. Weerstandsvermogen boven kringniveau wordt pragmatisch afgehandeld via een cohort-constructie, omdat daarvoor geen aparte PUV-code bestaat.

Scenario 2 — Kring heeft géén eigen PUV-code Er is één PUV-code op APF-/uitvoerdersniveau. Het onderscheid tussen kringen loopt via referenties op pension.scheme-niveau.

Beide scenario's worden door de standaard ondersteund. Partijen leggen de gekozen werkwijze vast in afspraken tussen ketenpartijen (TOM / SLA). Zie GitHub issue #114.

6.4.2 Berichtstructuur 1. Vermogen (0001a)

Zie ook 3.2.1.

Tabel in volledig scherm openen

6.4.3 Berichtstructuur 2. Cashflow (0001b)

Zie ook 3.2.2.

Tabel in volledig scherm openen

6.4.4 Berichtstructuur 3. Pensioenprojectie (0001c)

Zie ook 3.2.3.

Tabel in volledig scherm openen

6.4.5 Berichtstructuur 4. Rendementsinformatie (00002)

Zie ook 3.2.4.

Tabel in volledig scherm openen

6.4.6 Berichtstructuur 5. Orderopdracht (00541)

Zie ook 4.2 & 4.4.1.

Tabel in volledig scherm openen

6.4.7 Berichtstructuur 6. Orderconfirmation (00542)

Zie ook 4.2 & 4.4.2.

Tabel in volledig scherm openen

De volgende velden onder financialTransaction.trade zijn gewijzigd van verplicht naar optioneel: tradeQuantity, tradePrice, counterparty, broker, interestAmount, commissionAmount, clearingBroker en clearingBrokerCashAccount. tradeAmount blijft verplicht. Zie GitHub issue #105.

6.4.8 Berichtstructuur 7. Mutatiesaldi (00551)

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

6.4.9 Berichtstructuur 8. Reconciliatie-informatie (00552a)

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

6.4.10 Berichtstructuur 9. PUO-reconciliatie-informatie (00552b)

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

6.4.11 Berichtstructuur 10. Stuurinformatiebeleggingspools (00553)

Vanaf release 2027 is de cohortPool-laag uit dit bericht verwijderd; de gegevens landen rechtstreeks op investment.pool-niveau. Zie GitHub issue #124.

Tevens zijn de volgende velden van entiteit investment.pool verwijderd uit bericht 00553: dummyCashId, tradeQuantity, unitPrice en currencyExchangeRate. De velden buySellId, tradeValueAmount en currencyType blijven actief. Zie GitHub issue #133.

Zie ook 4.3 & 4.5.3.

Tabel in volledig scherm openen

6.4.12 Berichtstructuur 11. Rebalancinginformatie (00554)

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

6.4.13 Berichtstructuur 12. Waarde-informatie cohortenpool (00555a)

Vervallen vanaf release 2027. Dit bericht is niet meer actief in de release 2027 berichtenset. Zie GitHub issues #99, #119, #121.

6.4.14 Berichtstructuur 13. Waarde-informatie beleggingspool (00555b)

Zie ook 4.3 & 4.5.5.2.

Tabel in volledig scherm openen

6.4.15 Berichtstructuur 14. Betaalinformatie (00556)

Zie ook 4.3 & 4.5.6.

Tabel in volledig scherm openen

6.4.16 Berichtstructuur 15. Corporate Actions (00557)

Tabel in volledig scherm openen

6.4.17 Berichtstructuur Feedback Message

Zie ook 4.7.

Tabel in volledig scherm openen

Let op:

• Het initiële bericht wordt niet meegezonden met de feedback message.
• In de feedback message wordt altijd verwezen naar het messageId (via originalMessageId) van het bericht waar de feedback message een reactie op is en kan verwezen worden naar het messageType (via originalMessageType).

---

1. Eindrapport onderzoek standaard VB PUO (september 2023.pdf. zie: SIVI/Downloads ↩

2. Zie: OAS (Open API Specificaties) ↩

6.5: Kruisreferentie

6.5 Kruisreferentie Attributen & berichten

Dit overzicht toont welke attributen binnen een bepaald bericht verplicht (V) of optioneel (O) of niet van toepassing ( ) zijn.

Kruisreferentietabel in volledig scherm openen

Hoofdstuk 7: Technische specificaties

7 Technische specificaties

De technische gegevensspecificaties komen beschikbaar op basis van AFD 2.0 uit SIVI AFS. In dit hoofdstuk kan de lezer kennisnemen van een toelichting.

7.1 Berichten & regelingen

Ieder bericht kan over meerdere regelingen (pension.scheme) gaan. Wel gaat het steeds om 1 party.pensioenprovider. De verzending is per bericht en dat bericht bevat dus 1 pension.provider en 1 of meer pension.scheme's

7.2 Validaties

De volgende validatieregels kunnen met de technische specificaties uitgevoerd worden:

• Controle of de berichtstructuur correct is;

• Klopt het gegevenstype (onder meer getallen, strings);

• Controle op minimale en maximale waarden;

• Validatie van de veldlengte;

• Controle of verplichte entiteiten en verplichte attributen aanwezig zijn;

• Controle op het aantal herhalingen van entiteiten;

• Is sprake van toepassing van toegestane codes uit codelijsten.

PM verbandscontroles (validatie regels op de tussen verschillende gegevens) zijn nog in ontwikkeling. Zie ook de JSON-schema’s.

7.3 JSON

1. Het SIVI AFS team volgt voor AFD 2.0 in combinatie met JSON onderstaande specificaties (ontleend aan Forum Standaardisatie):

Betreft	Omschrijving
Volledige naam	JavaScript Object Notation
Versie	RFC8259, december 2017
Specificatiedocument	Specificatiedocument JSON
Beheerorganisatie	Internet Engineering Task Force https://datatracker.ietf.org/doc/html/rfc7159
Functioneel toepassingsgebied	Objectnotatie voor het uitwisselen van datastructuren. Bijvoorbeeld in webapplicaties die asynchroon gegevens ophalen van de webserver.
Typering	Uitwisselen van datastructuren
Nut	JSON (JavaScript Object Notation) is een deelverzameling van de programmeertaal JavaScript. De eenvoud van JSON heeft geleid tot een grote populariteit ervan, met name als een ‘light’ alternatief voor XML.
Werking	JavaScript Object Notation (JSON) een formaat om net zoals XML gegevens op te slaan en te versturen. JavaScript is de programmeertaal waarvan de basis syntax beschrijving is afgeleid voor gebruik in JSON. JSON wordt gebruikt voor het uitwisselen van datastructuren, met name in webapplicaties die asynchroon gegevens ophalen van de webserver. De standaard is met name gericht op efficiënt programmeren en kent een compacte notatie bijvoorbeeld: { “naam”: Jan, “geboren”: 1983 }
Hulpmiddelen	Verschillende online JSON validators en hulpmiddelen zijn te vinden, ook voor de verschillende programmeerplatformen. Meer informatie over de standaard is ook te vinden via publicaties van ECMA International

Richtlijn: Als een niet verplicht attribuut geen waarde heeft, moet het attribuut volledig worden weggelaten uit het JSON-bericht. Dit is een aanbevolen praktijk volgens de JSON-conventies.

7.3.1 Gebruik van JSON Schema

Voor validatie van de berichtstructuren maakt de standaard gebruik van JSON Schema.

De JSON-schema's worden gegenereerd vanuit AFD 2.0 / AOS en gepubliceerd via GitHub. Deze schema's ondersteunen: - validatie van berichtstructuren; - validatie van verplichte velden; - validatie van codelijsten; - validatie van technische constraints.

7.3.2 Overgang naar JSON Schema Draft 2020-12

Vanaf release 2027 gebruikt de VBPUO-standaard JSON Schema Draft 2020-12.

Deze wijziging is besproken en vastgelegd via GitHub issue:

#104 JSON Schema Versie

De overstap betreft een technische modernisering van de JSON-schema's. De functionele betekenis van de berichten wijzigt hierdoor niet.

Verschillen ten opzichte van JSON Schema Draft 2019-09

Hoofdschema

1. Het schema-dialect is gewijzigd van:

http://json-schema.org/draft/2019-09/schema#

naar:

https://json-schema.org/draft/2020-12/schema

1. De container met definities heet niet meer definitions maar $defs.

2. Interne verwijzingen zijn aangepast van:

#/definitions/...

naar:

#/$defs/...

1. De externe verwijzing naar de codelist gebruikt nu het 2020-12-pad:

https://www.sivi.org/afd-online-tool/json/2020-12/AFDIDP.json#/$defs/AFDIDP

in plaats van:

https://www.sivi.org/afd-online-tool/json/AFDIDP.json#/definitions/AFDIDP

ValidationRules

1. Geen 2020-12-specifieke modelverschillen vastgesteld.

2. De file blijft een JSON-structuur met metadata en validatieregels; er zijn geen inhoudelijke wijzigingen vastgesteld als gevolg van de overgang naar Draft 2020-12.

AfdCodelists

1. Het schema-dialect is gewijzigd van:

http://json-schema.org/draft-07/schema#

naar:

https://json-schema.org/draft/2020-12/schema

1. De container met definities heet niet meer definitions maar $defs.

7.4: Transport OpenAPI

7.4 Transport / OpenAPI

7.4.1 OpenAPI model

Vanaf begin 2024 is gewerkt aan een standaard voor het transport van de berichten. Een aantal PUO's en vermogensbeheerders hebben in samenwerking met SIVI stappen gezet in de ontwikkeling van een OpenAPI-specificatie binnen de eerder geschetste technische contouren.

Deze inspanning beoogde zowel de ondersteuning van alle partijen die de RESTful API zullen implementeren als het bevorderen van een uniforme toepassing ervan. De specificatie is te vinden op GitHub. De voorgestelde OpenAPI-specificatie helpt partijen bij het eenduidig uitwisselen van de berichtstructuren, zowel voor SPR als voor FPR. Naast de inhoudelijke berichten is ook een feedbackbericht gerealiseerd waarmee gereageerd kan worden op de inhoudelijke berichten.

De API fungeert als een digitaal loket, waarmee de verschillende PUO- en vermogensbeheerpartijen data kunnen ontvangen. De communicatie vindt plaats op initiatief van de verzendende partij (push-model); de verzendende partij levert de berichten aan bij de ontvangende partij zonder dat deze hier actief om hoeft te vragen. De specificatie begint met algemene informatie, waarin de naam, beschrijving en versie van de API staan vermeld.

De kern van de API beschrijft de specifieke services die beschikbaar zijn. Voor elke service is er een duidelijk pad gedefinieerd waarop berichten kunnen worden afgeleverd. Dit omvat bijvoorbeeld het aanleveren van informatie of het uitvoeren van bepaalde handelingen. Elk pad biedt een beschrijving van wat de dienst doet en hoe deze gebruikt kan worden.

Let op, in de praktijk zal niet iedere partij alle services uit de OAS aan. Partijen die alleen SPR voeren kunnen bijvoorbeeld, naast het feedbackbericht de berichten de SPR-berichten 1, 2, 3 en 4 aanbieden.

Daarnaast bevat de specificatie herbruikbare bouwstenen, zoals berichten en entiteiten. Dit zorgt ervoor dat de API consistent is en gemakkelijk te begrijpen en te gebruiken. Door het hergebruik van deze berichten en entiteiten wordt ontwikkeling eenvoudiger en de kans op fouten verminderd.

Om de volledigheid en integriteit van de berichten te waarborgen, is een mechanisme geïntroduceerd dat controle mogelijk maakt op wijzigingen tijdens transport. Het gaat om een zogenaamde x-jws-signature header, die een digitale handtekening van de payload bevat. Dit biedt een betrouwbare basis voor partijen om erop te vertrouwen dat ontvangen berichten exact overeenkomen met wat is verzonden. Het gebruik van dit middel is een mogelijkheid, geen verplichting. Partijen kunnen afwijkende keuzes maken.

Belangrijk is dat de standaard uitsluitend ondersteuning biedt voor de OAS API; andere vormen van gegevensuitwisseling worden niet ondersteund. Dit betekent dat alle communicatie tussen partijen volgens de gespecificeerde OpenAPI-specificatie dient te verlopen, en alternatieve methoden buiten de scope van de standaard vallen.

Beveiligingsmaatregelen API:

De belangrijkste beveiligingsmaatregelen zijn als volgt:

Beveiligingsmaatregel	Beschrijving
Authenticatie met API-sleutel	Elke aanvraag moet een geldige API-sleutel bevatten in de x-api-key header. Dit voorkomt ongeoorloofde toegang tot de API.
OAuth 2.0 Client Credentials Flow	De API maakt gebruik van OAuth 2.0 voor authenticatie en autorisatie. Clients moeten een toegangstoken verkrijgen via de token endpoint met hun client-ID en geheim.
	Specifieke scopes worden gebruikt om toegang tot verschillende API-functies te regelen, waardoor alleen geautoriseerde acties kunnen worden uitgevoerd.
Digitale Handtekeningen met x-jws-signature (optie)	Als van dit mechanisme gebruik wordt gemaakt, dan bevat elke aanvraag een digitale handtekening van de payload in de x-jws-signature header. Dit stelt de ontvanger in staat om te verifiëren dat het bericht niet is gewijzigd tijdens transport. .
Versleutelde Communicatie via HTTPS	Alle communicatie verloopt via HTTPS, wat zorgt voor versleuteling van gegevens tijdens transmissie en bescherming tegen onderschepping.

7.4.2 API-implementatie en back-up

Deployment en operationeel houden van de API's is de verantwoordelijkheid van de partij die de API aanbiedt en valt buiten het bereik van de standaard. (Tijdelijke) uitval van de API-gegevenstransportvoorziening kan voorkomen. Het risico daarop is kleiner bij een aanpak waarbij meerdere replica’s van de API gelijktijdig draaien (op verschillende omgevingen en/of locaties). Uiteindelijk is dit een kosten/baten afweging; het garanderen van een 99,9% uptime is kostbaarder dan een 98% uptime garantie.

Uitgangspunt is dat uitval steeds kortdurend zal zijn. In uitzonderingsgevallen kan email als “back-up” transportmechanisme gelden.

7.5: Samenstellen berichten

7.5 Samenstellen berichten, versionering en publicatie

7.5.1 Toelichting op het gebruik van “afdDefintionVersion”

“afdDefintionVersion” wordt gevuld met het versienummer (uit de “Naam schema”) van het VBPUO-JSON-schema.

Het VBPUO-JSON-schema voor de functionele berichten en de VBPUO_Feedback_Message wordt door SIVI onderhouden met behulp van “AFD Online Samenstellen (AOS)” en wordt daarin geadministreerd met de volgende metagegevens:

Metagegeven AOS schema	Waardes (voorbeeld)
SIVI community	AFD 2.0
Berichtsoort:	Protocol PUO Vermogensbeheer
Domein:	Algemeen
Naam schema:	VBPUO-###.##

Tabel : Metagegevens (AOS) VBPUO-schema

In het (AOS) VBPUO-schema worden de VBPUO-berichtstructuren gedefinieerd als ”functies” bijvoorbeeld de functie: “Bericht_1._Vermogen_(0001a)”. Vanaf release 2027 zijn 10 inhoudelijke berichten en het Feedbackbericht actief; 5 berichten uit het FPR gelaagde ordermodel zijn vervallen (zie §6.4). Per “functie” worden vervolgens 3 JSON-schema’s gegenereerd die op GitHub worden gepubliceerd (“commit”). Deze JSON-schema’s hebben de volgende doelen:

JSON-Schema toegelicht

Doelen	nadere omschrijving	Voorbeeld filenaam
Berichtstructuur	Definiëring van de structuur, verplichte elementen en veldvalidaties, met interne en externe referenties om dataconsistentie en standaardisatie te waarborgen.	VBPUO-001.00-Bericht_1._Vermogen_(0001a).json
Codelijsten/tabellen:	Definieert de codelijsten (bijvoorbeeld pensioenuitvoerder- en valutacodes) die worden gebruikt als referenties in het JSON-schema voor veldvalidatie.	VBPUO-001.00-Bericht_1._Vermogen_(0001a)-afdCodelists.json
Verbandscontroles	Definieert de regels voor verbandscontroles in het JSON-schema om de geldigheid en consistentie van gegevensrelaties te waarborgen.	VBPUO-001.00-Bericht_1._Vermogen_(0001a)-validationRules.json

Tabel : JSON-Schema's (uit AOS) toegelicht

7.5.1.1 Versienummer / afdDefinitionVersion bij een GitHub release

Het versienummer een AOS-schema moet worden opgenomen in elk te verzenden bericht. Dit nummer is te vinden in de Berichtstructuur als constante onder afdDefinitionVersion.

Onder dit nummer zijn de JSON-Schemas terug te vinden op https://portal.sivi.org/organisationschemas. De berichten die met dit schema worden gemaakt – binnen het schema VBPUO zijn die gedefinieerd als functies – worden gepubliceerd op GitHub.

Bestandsnaam versus afdDefinitionVersion

De bestandsnamen van de JSON-schema's bevatten een versienummer als onderdeel van de naam, bijvoorbeeld VBPUO-001.00-Bericht_1._Vermogen_(0001a).json. Dit versienummer is bevroren op de waarde die gold bij eerste publicatie en wordt bij latere releases niet bijgewerkt.

De reden hiervoor is de koppeling met de OpenAPI Specificatie (OAS). De OAS verwijst naar de JSON-schema's via een directe bestandspad-referentie ($ref):

$ref: 'VBPUO-Bericht_1._Vermogen_(0001a)/VBPUO-001.00-Bericht_1._Vermogen_(0001a).json'

Als het versienummer in de bestandsnaam bij elke release zou worden bijgewerkt, moesten ook alle $ref-verwijzingen in de OAS worden aangepast. Omdat implementerende partijen (PUO's en vermogensbeheerders) hun API-implementaties op de OAS baseren, zou elke bestandsnaamswijziging een aanpassing vereisen in alle geïmplementeerde API's in de sector. Dit is bewust vermeden.

Het gevolg is dat bestandsnaam en inhoud uiteen kunnen lopen: de bestandsnaam vermeldt 001.00 terwijl het veld afdDefinitionVersion binnenin het schema de actuele waarde bevat, zoals 001.02.

Let op: gebruik voor implementatie en validatie altijd de waarde van afdDefinitionVersion — niet het versienummer in de bestandsnaam.

Zie ook: GitHub issue #58

7.5.2 Publicatie op GitHub versienummer en tag

Bij het releasen op GitHub krijgt de release een Naam en een Tag. Alle JSON-s, voorbeeldberichten en de OAS vallen onder die release/tag.

De naam van de juli release 2024 was bijvoorbeeld “2024_Juli” met tag v1.1.0. De GitHub-releasenaam en -tagnummer zijn niet terug te vinden in de pay-load van de berichten. Zowel de berichten als de OAS hebben een eigen releasenummer.

7.5.3 JSON Schema-versies

Per bericht worden meerdere JSON-gerelateerde bestanden gepubliceerd: - berichtstructuur; - codelijsten; - validation rules.

Vanaf release 2027 worden deze bestanden gepubliceerd conform JSON Schema Draft 2020-12.

Hierbij geldt: - berichtstructuren gebruiken $defs; - interne referenties gebruiken #/$defs/...; - externe AFD-referenties verwijzen naar het 2020-12-pad; - validation rules blijven inhoudelijk ongewijzigd.

7.6: Chunking

7.6 Verwerkingsprotocol voor Deelberichten (Chunking)

Deze paragraaf beschrijft het protocol voor het opsplitsen (door de zender) en verwerken (door de ontvanger) van grote berichten. Het gebruik van deelberichten (chunks) is een optioneel mechanisme dat wordt toegepast wanneer de omvang van een bericht de afgesproken limieten overschrijdt.

7.6.1 Fundamentele Uitgangspunten van Chunking

Voordat we het opsplits- en samenvoegproces beschrijven, gelden de volgende fundamentele regels voor het chunking-mechanisme:

• Validiteit per Chunk: Elke chunk moet een op zichzelf staand, volledig JSON-schema-conform bericht zijn. Dit betekent dat elke chunk alle verplichte "header"-blokken bevat, zoals commonTechnical en commonFunctional.

• Gedeelde messageId: Alle chunks die deel uitmaken van één logisch bericht, delen exact dezelfde messageId in het commonTechnical-blok. Dit is de unieke identificatie van het overkoepelende, logische bericht.

• Verplichte chunking-attributen: Indien de chunking.default-entiteit aanwezig is om aan te geven dat chunking wordt toegepast, zijn alle attributen binnen deze entiteit verplicht. Dit is essentieel voor een robuust en deterministisch reconstructieproces aan de kant van de ontvanger.

• Integriteit van het logische bericht: Een fout in één enkele chunk (bijv. een validatiefout of het niet aankomen van de chunk) maakt het gehele logische bericht ongeldig. Het bericht moet dan in zijn geheel, met een nieuwe messageId, opnieuw worden aangeboden.

7.6.2 Opsplitsen van een groot bericht (Kant van de zender)

1. Bepalen van de Noodzaak
Opsplitsen is nodig wanneer een bericht de afgesproken maximale grootte (default: 4 MB) overschrijdt. De zender is verantwoordelijk voor het correct opdelen van de data.

2. Het Opsplitsproces
De zender creëert meerdere chunks door de data uit grote, herhalende arrays (zoals de lijst met cohorten) te verdelen. Elke chunk krijgt een chunking-blok met de juiste metadata (chunkSequenceNumber, totalNumberOfChunks, etc.) en de chunkFragmentPaths die de inhoud van die specifieke chunk beschrijven.

3. Gebruik van JMESPath in chunkFragmentPaths
Het chunkFragmentPaths-veld bevat de essentiële instructies voor de ontvanger om het oorspronkelijke bericht correct te kunnen reconstrueren. Het JMESPath kan een specifiek bereik (slice) aangeven (bv. pension[0:100]), wat garandeert dat de ontvanger de data in de exact juiste volgorde kan terugplaatsen, zelfs als de chunks in een andere volgorde worden ontvangen.

7.6.3 Verwerken van ontvangen chunks (Kant van de ontvanger)

1. Het Reconstructieproces

De ontvanger gebruikt de gedeelde messageId om chunks te verzamelen

• Start met de Eerste Chunk: De chunk met chunkSequenceNumber: 1 dient als de basis of 'template' voor de reconstructie.

• Plaats Datafragmenten: Voor alle volgende chunks worden de datafragmenten op de juiste positie in de template geplaatst, geleid door de chunkFragmentPaths.

• Bepaal Compleetheid: Het bericht is compleet als het aantal ontvangen chunks gelijk is aan totalNumberOfChunks.

2. Verwerkingsstrategieën
Na conceptuele compleetheid kan de ontvanger kiezen voor:

• Reconstructie-eerst (Batch-aanpak): Bouw het volledige bericht in het geheugen en valideer het daarna.

• Streaming-verwerking (Directe verwerking): Sla datafragmenten per chunk direct op en voer overkoepelende validaties later uit op de database.

3. Foutafhandeling en incompleetheid

De integriteit van het volledige logische bericht is cruciaal.

• Als één enkele chunk faalt (bijvoorbeeld door een technische validatiefout, of als deze niet binnen een bepaalde tijd wordt ontvangen), wordt het gehele logische bericht als mislukt en onverwerkbaar beschouwd.

• In dat geval dient de verzender, na eventueel overleg, het volledige bericht opnieuw aan te bieden met een nieuwe messageId, opgesplitst in een nieuwe set chunks.

Hoofdstuk 8: Bijlagen

8 Bijlagen

In de bijlagen treft u de:

• Begrippenlijst/Afkortingenlijst Vermogensbeheer & Pensioenuitvoering;

• Begrippenlijst gegevensuitwisseling op basis van standaarden;

8.1: Begrippenlijst VB-PUO

8.1 Begrippenlijst/Afkortingenlijst Vermogensbeheer & Pensioenuitvoering

Begrip	Afkorting	Omschrijving
Afdekkingspercentage, beschermingspercentage		De mate waarin de rentegevoeligheid van op basis van persoonlijke vermogens geprognosticeerde uitkeringen wordt afgedekt.
Algemeen Pensioenfonds	APF	Algemeen Pensioenfonds (APF): Een APF is een pensioenuitvoerder die verschillende pensioenregelingen van verschillende werkgevers en bedrijfstakken kan bundelen in één administratie.
Asset service provider		Zie: Beleggingsadministrateur.
Bank Identifier Code	BIC	Bank Identifier Code. bijvoorbeeld van ABN: ABNANL2A
BIC Correspondent		Een BIC correspondent is de BIC-code van een correspondentbank; een bank die diensten verleent aan andere banken.
Beleggingsadministrateur	BA	Een onafhankelijke partij die de beleggingsadministratie voert voor de pensioenuitvoerder. Dit is een dienst die veelal door de custodian wordt verzorgd.
Beleggingen methode		Berekening van het beschermingsrendement vindt, buiten het domein van de pensioenuitvoeringsorganisatie plaats op basis van de werkelijke renterisico afdekking.
Beleggingsinstructie		Beleggingsorder.
Beleggingsorder		Een opdracht tot het aankopen van bepaalde beleggingen.
Beleggingspool		Een beleggingspool is een verzameling van beleggingen in verschillende fondsen of mandaten die een gemeenschappelijk kenmerk delen. Een voorbeeld hiervan is de 'zakelijke waarden beleggingspool', waarin wordt belegd in meerdere zakelijke waarden fondsen en/of mandaten. Beleggingspools zijn bedoeld om de beleggingen van een groep investeerders te bundelen en te beheren. Ze bieden investeerders de mogelijkheid om te diversifiëren en risico's te spreiden door te investeren in verschillende activa.
Beschermingsportefeuille		Specifiek deel van de beleggingsportefeuille aangehouden met als doel om (voornamelijk) het beschermingsrendement te genereren. Bij de SPR kan dit een operationeel onderdeel zijn van de totale portefeuille waarmee de renteafdekking wordt vormgegeven. Bij het gebruik van feitelijk beschermingsrendement zal het een of meerdere afgescheiden portefeuilles zijn.
Beschermingsrendement		De vermogensbijschrijving die ervoor zorgt dat de, uit het opgebouwde pensioenvermogen te financieren, toekomstige pensioenuitkeringen en lopende pensioenuitkeringen nominaal stabiel blijven voor de mate waarin deze worden beschermd, dat wordt gefinancierd vanuit het totaal behaalde rendement en looptijdafhankelijk wordt toebedeeld aan de vermogens op basis van marktwaardering, waarbij toedelingsregels worden gehanteerd. Toedelingsregels SPR worden vastgesteld: ofwel op basis van wijziging van de rentetermijnstructuur, die de toezichthouder beschikbaar stelt (RTS) ofwel rechtstreeks uit het rendement van de daarvoor bestemde beleggingen. (Beleggingen methode) Zie ook: Beleggingen methode en Rentetermijnstructuur methode.
Book of records		Een aanduiding voor boekhoudkundige administraties binnen vermogensbeheer. Binnen de kaders van dit rapport gaat het om: ABOR = Accounting Book of Records (hoofdadministratie, volgens accounting regels), IBOR = Investment Book of Records (vaak schaduwadministratie).
Cohorten		De term verwijst naar doelgroepen. Deze kunnen op allerlei wijze worden samengesteld. Leeftijdsdoelgroepen maar ook op bijvoorbeeld deelnemer, slaper, gepensioneerd, arbeidsongeschikt en/of soort dienstverband kan gedifferentieerd worden Een cohort kan de basis zijn waarop een pensioenuitvoerder deelnemers aan een passende herbalanceringssystematiek koppelt.
Cohortenpool/ Cohortpool		Een cohortenpool bevat de verzameling van alle beleggingen (beleggingspools) voor 1 cohort. Oftewel de gepoolde (verzamelde) combinatie van beleggingen (beleggingspools) voor een cohort.
Collectieve uitkeringsfase	CVP (ook: CVU)	Fase binnen een flexibele premieregeling (FPR) waarin pensioenuitkeringen collectief worden gefinancierd. De CVP kan unitized (in units geadministreerd, geïntegreerd met de opbouwfase via netting) of non-unitized (als aparte EUR-pot met eigen cashflows) worden ingericht.
Collectieve uitkeringsfase	CVU	Zie: Collectieve uitkeringsfase (CVP). CVU is een gangbare alternatieve afkorting voor hetzelfde begrip.
Custodians		Bewaarder van het beheerde vermogen van een pensioenuitvoerder. Bepaalt onafhankelijk de waardering en het rendement van de holdings en beleggingsportefeuilles/pools.
Defined Benefit	DB	Pensioenregeling waarbij de uitkering vooraf is toegezegd. Niet in scope van de VBPUO-standaard, maar als referentiekader relevant voor de berekeningsmethoden van kasstromen.
Defined Contribution	DC	Pensioenregeling waarbij de premie-inleg vaststaat en de uitkering afhankelijk is van het beleggingsresultaat. SPR en FPR zijn beide DC-regelingen.
Direct (feitelijk)beschermingsrendement		Rendement dat gegenereerd wordt met een of meerdere directe beschermingsportefeuilles voor renterisico. Hierbij zijn er twee opties: Met één beschermingsportefeuille: de beschrijving per deelnemer vindt plaats op basis van het theoretisch beschermingsrendement waarbij het resultaat ‘geschaald’ wordt naar het resultaat van de beschermingsportefeuille. Voorbeeld: indien het totale theoretische beschermingsrendement 1000 zou zijn maar het feitelijk beschermingsrendement maar 900, dan krijgt iedere deelnemer 90% van het theoretisch beschermingsrendement bijgeschreven. Met meerdere beschermingsportefeuilles: per leeftijdscohort geldt een allocatie naar de beschermingsportefeuilles (eventueel inclusief inflatie-instrumenten).
Fiduciair manager	FM	Een fiduciair manager draagt zorg voor de integrale aansturing van het vermogensbeheer waarbij het (strategisch) beleggingsbeleid van het fonds in brede zin wordt geïmplementeerd. Daarbij kunnen vervolgens uiteenlopende, onderliggende vermogensbeheerders worden aangestuurd. De FM zal ook een (schaduw) beleggingsadministratie voeren.
Flexibele premieregeling	FPR	Premieovereenkomst waarbij de premie individueel wordt belegd en waarbij het kapitaal voortvloeiend uit de premie vanaf de pensioendatum wordt aangewend voor financiering van een variabele uitkering of voor de aankoop van een vastgestelde uitkering.
Foreign Exchange Rate	FX-rate	Wisselkoers Een investment currency waarde van 1,1 USD bij een investment-pool currency waarde van 1 leidt tot een waarde in euro van 1/1,1 = € 0,9090
Geprojecteerde pensioenuitkeringen		De verwachte variabele uitkeringen in een solidaire premieovereenkomst van een pensioenuitvoerder op basis van het opgebouwde voor pensioen bestemde vermogen. De hoogte van de verwachte variabele uitkering wordt bepaald door het inrekenen van een projectierendement op het voor pensioen bestemde vermogen Dit kan hoger of lager zijn dan de risicovrije rente. De precieze invulling van geprojecteerde uitkeringen is een partijen/governance afspraak.
Identifier		Een sleutel gegeven dat een beleggingsinstrument uniek identificeert bijvoorbeeld ISIN of SEDOL.
Instruction Date		Datum van de verzending van de beleggingsorder/beleggingsinstructie door de pensioenuitvoeringsorganisatie.
International Securities Identification Number	ISIN	Een codenummer voor een “effect” bestaande uit een landencode en een uniek National Security Number (NSIN). ISIN is het acroniem van International Securities Identification Number. ISIN codes worden alleen gebruikt voor beursgenoteerde genoteerde beleggingsfondsen. In de pensioenvermogensbeheerpraktijk wordt veelal gewerkt met administratieve pools die GEEN ISIN hebben. Voor zulke pools is wel een unieke identifier nodig.
DNB-jaarstaat kosten vermogensbeheer	J402	Kosten vermogensbeheer uitgesplitst naar verschillende (beleggings)categorieën. De jaarstaat omvat alle vermogensbeheerkosten zowel de gefactureerde kosten als kosten die worden ingehouden op de behaalde bruto rendementen. Per beleggingscategorie worden beheervergoedingen, prestatieafhankelijke vergoedingen en transactiekosten gerapporteerd.
Leidende beleggingsadministratie		Beleggingsadministratie die voor de pensioenuitvoeringsorganisatie en de pensioenuitvoerder de basis is voor (mutaties in) het persoonlijk voor pensioenuitkering bestemd vermogen (SPR), voor pensioen bestemd kapitaal (FPR) en voor de rapportage aan de toezichthouder.
Liability-Driven Investmentmanagers	LDI	Partijen die zich specialiseren in het beheer van beleggingen met als primaire doelstelling het afdekken van toekomstige verplichtingen of verplichtingen van een investeerder of instelling.
LDI-mandaat		Een op maat gemaakte beleggingsportefeuille waarmee de LDI-manager of vermogensbeheerder het renterisico van de uitkerings- en opbouwrechten afdekt, volgens vooraf vastgestelde richtlijnen, om het beschermingsrendement te realiseren conform de risicovrije termijndefinities uit het Wtp-kader.
Lifecycle		Het doel van beleggen volgens een lifecycle is om de grote schommelingen in de kapitaalopbouw te verminderen bij het naderen van de beleggingshorizon. Om dit te bereiken, delen pensioenuitvoerders deelnemers op in deelpopulaties op basis van de resterende tijd tot de pensioendatum. Naarmate de pensioendatum en beleggingshorizon dichterbij komen, wordt het beleggings- en renterisico voor deze deelpopulaties afgebouwd. Zo wordt ervoor gezorgd dat het beleggingsbeleid past bij de levensfase waarin de deelnemer zich bevindt.
Local valuta / Local price		Prijs van het beleggingsinstrument in diens originele valuta.
Lookthrough		Met dit begrip wordt gedoeld op het "doorzicht" naar daadwerkelijke beleggingen. Afhankelijk van het type product en de beleggingssamenstelling is dit "doorzicht" eenvoudig dan wel moeilijk of tegen forse kosten te realiseren. Bij SPR producten is de beleggingsmix op individueel niveau niet te bepalen. Bij FPR-producten kunnen de beleggingen in sommige gevallen direct aan een beursgenoteerd fonds worden gelinkt.
Mandaat		Een beleggingsopdracht aan een vermogensbeheerder om een portefeuille te beheren volgens vooraf afgesproken richtlijnen en risicolimieten (vastgelegd in een Investment Management Agreement of beleggingsrichtlijnen), niet toegankelijk voor andere beleggers; posities, kosten en risico's zijn direct toerekenbaar aan de opdrachtgever.
Net asset value	NAV	Zie: Total Market Value.
Netten		Het samenvoegen (salderen/consolideren) of optellen van beleggingsorders in hetzelfde beleggingsproduct.
Order date		Instruction Date
Overrendement		Het saldo van het totaal behaalde rendement op de beleggingen, de ontwikkeling van de levensverwachting en het sterfteresultaat en het toebedeelde beschermingsrendement op basis van de toedelingsregels.
Pensioenfonds		Instellingen die pensioenregelingen beheren en uitvoeren ten behoeve van werknemers die bij een specifiek bedrijf of bedrijfstak werken.
Pensioenuitvoerder		In Nederland worden verschillende partijen gedefinieerd als "pensioenuitvoerder" volgens de Pensioenwet. In 2023 gaat/ging het om: Pensioenfondsen, Pensioenverzekeraars, Premiepensioeninstellingen (PPI's) en Algemeen Pensioenfonds (APF).
Pensioenregeling		Een pensioenregeling volgens de Pensioenwet is een overeenkomst (of toezegging) tussen een werkgever en een werknemer waarin is vastgelegd welke pensioenuitkeringen worden toegezegd en onder welke voorwaarden.
Pensioenreglement		De door de pensioenuitvoerder opgestelde regeling waarin de rechten en plichten van de deelnemer en de pensioenuitvoerder zijn beschreven.
Pensioen uitvoeringsorganisatie	PUO/PA	Administrateur van pensioenregelingen.
Pensioenverzekeraar		Verzekeringsmaatschappijen die individuele en collectieve pensioenverzekeringen aanbieden en de pensioenregelingen beheren en uitvoeren.
Portfolio		Een beleggingsportefeuille, oftewel een geheel van aandelen en andere effecten.
Premiepensioeninstelling	PPI	Financiële instellingen die individuele premieovereenkomsten aanbieden, waarbij de hoogte van het pensioen afhangt van de premie-inleg en het rendement daarop.
Premie-uitkeringsovereenkomst		Premieovereenkomst uitgevoerd door een verzekeraar waarbij de premie individueel wordt belegd, waarbij de premie of het kapitaal voortvloeiend uit de premie in de laatste 15 jaar voor de pensioengerechtigde leeftijd kan worden aangewend voor aankoop van een vastgestelde uitkering vanaf de pensioendatum en waarbij het resterend kapitaal vanaf de pensioendatum wordt aangewend voor financiering van een variabele uitkering of voor de aankoop van een vastgestelde uitkering.
Projectierendement		Het ingerekende toekomstig rendement voor de vaststelling van variabele uitkeringen.
Rebalancen		Het periodiek of op verzoek in evenwicht brengen van een beleggingsportefeuille met de doelgewichten binnen deze portefeuille, na in- of uitstroom in de betreffende portefeuille (externe aanleiding) of doordat binnen de portefeuille sprake is ongewenste afwijkingen van normbeleid door marktbewegingen.
Reconciliatie		Het proces waarbij vergeleken wordt of de (totalen) van registraties van stukken tussen de verschillende partijen (bijvoorbeeld vermogensbeheerder en custodian) in overeenstemming zijn en zo nee het oplossen van verschillen.
Rentetermijnstructuur methode	RTS	Bij de RTS-methode vindt de berekening van het SPR beschermingsrendement plaats op basis van de wijziging van de RTS in de schaduw-VPV. De schaduw VPV is de VPV van de schaduw-aanspraken op basis van het aanwezige kapitaal.
Solidariteitsreserve		Een collectieve vermogensreserve waarmee in een solidaire premieovereenkomst financiële mee- of tegenvallers met toekomstige opbouw kunnen worden gedeeld.
Risicodelingsreserve		Een collectieve vermogensreserve waarmee in een flexibele premieovereenkomst financiële mee- of tegenvallers met toekomstige opbouw kunnen worden gedeeld.
Settlement date		Datum waarop de volledige cyclus van de beleggingsorder vanaf de trade date - afgewikkeld is. Elk (beleggings)product heeft z’n eigen settlement duur variërend van T+1 tot T+4 (T = trade date)
Solidaire premieregeling	SPR	Premieregeling waarbij de premie collectief wordt belegd, de resultaten in ieder geval naar leeftijdscohorten worden toebedeeld en waarbij het voor pensioenuitkering bestemd vermogen gedurende de uitkeringsfase wordt aangewend voor financiering van een variabele uitkering. Voor de cohorten moet door de pensioenuitvoerders worden voorzien in toedelingsbeleid naar de individuen/deelnemers die van een cohort deel uitmaken.
Toedelingsbeleid / Toedelingsregels		De wijze waarop de pensioenuitvoerder het rendement toebedeeld aan de (groepen / cohorten en vanuit die groepen naar individuele) deelnemers.
Total market value		De nettowaarde van een belegging. Bij de FPR gaat het om de waarde van een aandeel of andere participatievorm in het totale kapitaal. Bij de SPR wordt door de beleggingsadministrateur de waarde (NAV) van het totale kapitaal van de (collectieve) belegging doorgegeven aan de pensioenuitvoeringsorganisatie.
Trade date		Datum waarop de pensioenuitvoeringsorganisatie de order voor een pensioenregeling (scheme) uitgevoerd wil hebben.
Indirect (theoretisch beschermingsrendement)		Bescherming voor het renterisico in de solidaire premieregeling door gebruik te maken van een rentetermijnstructuur, bedoeld in artikel 2, tweede lid, van het Besluit financieel toetsingskader pensioenfondsen.
Transfer agent		Registrar; degene die de participaties bijhoudt. Vooral van belang bij dagelijks verhandelbare stukken (bij FPR) Een transferagent is een trustmaatschappij, bank of soortgelijke instelling die is aangewezen om de financiële gegevens van een belegger bij te houden en het rekeningsaldo van elke belegger bij te houden. Voorbeelden zijn: Fundsettle, Allfunds en BBH).
Valuation date		Datum van de waardebepaling van de cohortenpool gebruikt bij het doorgeven van de waarde van (pool)unit binnen deze pool.
Value date		Valuta datum. Een datum binnen een opdracht tot het doen van een betaling.
Vermogensbeheerder	VB	Uitgever van financiële producten (structured products) verantwoordelijk voor het actief en/of passief portefeuillemanagement.
Voorziening pensioenverplichtingen	VPV	Het benodigde kapitaal wat nodig is om aan de huidige en toekomstige pensioenverplichtingen te kunnen voldoen.
Zelf uitvoerend fonds	ZAF	Een pensioenfonds dat de pensioenadministratie en het vermogensbeheer geheel of grotendeels in eigen beheer uitvoert, in plaats van deze uit te besteden aan een pensioenuitvoeringsorganisatie (PUO). In de procesflows van deze standaard wordt onder PUO ook het ZAF begrepen.

8.2: Begrippenlijst gegevensuitwisseling

8.2 Begrippenlijst gegevensuitwisseling op basis van standaarden

Begrip	Betekenis
API	Een application programming interface (API) is een gestructureerd en gedocumenteerd koppelvlak voor communicatie tussen applicaties. Voor steeds meer organisaties vormen API’s (bibliotheek met webservices) de sleutelrol in het aanbieden van transacties, het distribueren van content of het ontsluiten van een workflow tussen schakels in de keten.
Attribuut	Een uniek kenmerk of gegeven van een entiteit.
Begrijpelijkheid gegeven	Bron: NORA De mate waarin gegevens eenvoudig gelezen en geïnterpreteerd kunnen worden door gebruikers.
Bericht	Een bericht beschrijft de interface tussen twee geautomatiseerde toepassingen die berichten uitwisselen.
Berichtschema	Een bericht-/productdefinitie in schemavorm.
Berichtstructuur	Op basis van de bouwstenendoos met entiteiten, attributen etc. worden een of meer hiërarchische structuren gespecificeerd. In deze structuur worden de relaties tussen de entiteiten aangegeven.
Consistentie gegevens	Bron: NORA De mate waarin gegevens vrij van tegenspraak zijn en samenhang vertonen met andere gegevens.
CSV-bestand	Een gegevensbestand waarvan de waarden door een leesteken worden gescheiden (in de regel een komma of puntkomma) als specificatie voor tabelbestanden. De waarden kunnen in een rekenblad¬ of een databaseprogramma worden ingelezen en vervolgens op een beeldscherm als tabel worden gepresenteerd.
Data Exchange	Data Exchange is de techniek waarbij de data van verschillende geautomatiseerde toepassingen op geautomatiseerde wijze met elkaar uitwisselbaar zijn op basis van gemaakte afspraken over onder andere standaarden.
Data Governance	Een systeem dat interoperabiliteitscomponenten (standaarden en beleidsregels) toepast om het acceptabele gebruik en de hoge kwaliteit van gegevens binnen een specifiek ecosysteem te garanderen. Beheert de beschikbaarheid, bruikbaarheid, consistentie, integriteit en beveiliging van de gebruikte gegevens.
Entiteit	Dit is ‘iets wat een bestaan heeft’. Dus iets dat er toe doet, dat men kan duiden, kan benoemen en waarde heeft. Bijvoorbeeld een persoon is een entiteit en kan beschreven worden met attributen zoals voornaam, familienaam of BSN-nummer (uniek persoonsgebonden nummer).
Gegeven	Bron: NORA Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
Gegevensgroep (entiteit)	Groep van gegevenselementen die logisch bij elkaar hoort.
Gegevenskwaliteit of Datakwaliteit	Bron: NORA De mate waarin een geheel van eigenschappen en kenmerken van één of meer gegevens voldoet aan eisen. Het streven is dat gegevenskwaliteit "fit-for-purpose" is; dat deze aansluit bij het gebruik. Kwaliteit heeft betrekking op de mate waarin wordt voldaan aan verwachtingen.
Gegevensoverdraagbaarheid	Dataportabiliteit. De mogelijkheid om gegevens gemakkelijk te verplaatsen tussen interoperabele toepassingen en domeinen.
Interoperabiliteit	Interoperabiliteit is het vermogen van organisaties (en hun processen en systemen) om effectief en efficiënt informatie te delen met hun omgeving. In het European Interoperability Framework worden drie vormen van interoperabiliteit onderscheiden: Technische interoperabiliteit – Om systemen te kunnen koppelen, moeten er afspraken worden gemaakt over interfaces, standaarden en protocollen voor communicatie, berichtenformaten, gegevensintegratie, beveiliging, beschikbaarheid, etc. Semantische interoperabiliteit – De informatie die partijen uitwisselen, moet wederzijds begrijpelijk zijn. Context en betekenis van gegevens moet eenduidig zijn vastgelegd. Organisatorische interoperabiliteit – Om gezamenlijke diensten te kunnen leveren, moeten organisaties op elkaar zijn afgestemd in termen van hun businessdoelen, verdeling van verantwoordelijkheden en uitwisselingsprocessen.
Koppelvlak	Het geheel van gemeenschappelijke afspraken dat de uitwisseling van gegevens tussen digitale systemen mogelijk maakt.
Kwaliteitseis of norm	Bron: NORA Een norm waaraan gegevens moeten voldoen. Een kwaliteitseis wordt in veel gevallen uitgedrukt in een getal zoals een percentage.
Metadata	Bron: NORA Metagegevens. Data over data. Metadata zijn data die de karakteristieken van andere data beschrijven. Het bewaren bij of koppelen van metadata aan de data waarop ze betrekking hebben, heeft als voordeel dat de data makkelijker gevonden kunnen worden.
Metagegevens	Bron: NORA Gegevens die context, inhoud, structuur en vorm van informatie en het beheer ervan door de tijd heen beschrijven.
Onweerlegbaarheid gegeven	Bron: NORA Begrip dat gebruikt wordt bij elektronische berichtuitwisseling en dat inhoudt dat de zender van een bericht niet kan ontkennen een bepaald bericht te hebben verstuurd en dat de ontvanger van een bericht niet kan ontkennen het bericht van de zender in de oorspronkelijke staat te hebben ontvangen.
Plausibiliteit gegeven	Bron: NORA De mate waarin gegevens worden beschouwd als waar en geloofwaardig door gebruikers.
Precisie gegeven	Bron: NORA De mate waarin gegevens exact of onderscheidend genoeg zijn.
Semantiek	Bron: NORA Leer van de betekenis van woorden en woordgroepen.
Standaard	Dit zijn afspraken over informatie of over een proces, dit kan zowel op het niveau van semantische als technische standaarden. Veelal worden de afspraken vastgelegd in documenten met erkende status. Standaarden worden onderhouden vanuit standaardisatie organisaties zoals het NEN en aanbevolen of verplicht gesteld door bijvoorbeeld Bureau Forum Standaardisatie.
Straight Through Processing (STP)	STP is de elektronische verwerking van processen waarbij de elkaar opvolgende administratieve handelingen plaatsvinden met zo min mogelijk menselijke tussenkomst.
Transparantie	Bron: SSI Speelveldanalyse, Innopay & TNO, 1 oktober 2021 De mate waarin personen, groepen en organisaties zicht hebben op welke gegevens die op henzelf betrekking hebben voor welk doel gebruikt worden.
Validiteit gegevens	Bron: NORA De mate waarin gegevens voldoen aan de verwachte structuur en opslagvorm.

8.3: Onderdelen standaard

8.3 Onderdelen Standaard Vermogensbeheer Pensioenuitvoering

In onderstaande Figuur 14 staat aangeven wat SIVI gaat vastleggen voor de Standaard Vermogensbeheer Pensioenuitvoering. Daarna volgt in de tabel een toelichting op de onderdelen.

Figuur 14 - Onderdelen van de standaard in samenhang

Nr.	Onderdeel standaard	Toelichting
1	Uitgangspunten	De belangrijkste uitgangspunten bij de ontwikkeling, opzet en besturing van de standaard.
2	Procesbeschrijvingen	Procesbeschrijvingen zijn gestructureerde beschrijvingen die de stappen, activiteiten en betrokken elementen van de specifieke ketenprocessen en informatiestromen in detail uitleggen. We gebruiken deze beschrijvingen om een duidelijk begrip te verschaffen van hoe de processen werken en welke informatiestromen aan de orde zijn. In dit geval is vooral het onderscheid tussen flexibele en solidaire premieregeling relevant.
3	Governance	Governance gaat over het optimaal inrichten van de organisatie van de community rond de standaard. Duidelijk moet zijn wie beslist over wat uitgevoerd wordt met betrekking tot standaarden, en wie beslist hoe dit wordt uitgevoerd. Onderdeel is het huishoudelijk reglement van de klankbordgroep en de eventuele tijdelijke werkgroepen.
4	Organisatie beheer	Beheer gaat in op de beheersmatige processen rondom de standaarden. Het omvat alle activiteiten gericht op het aanpassen, uitbreiden, doorontwikkelen, beschikbaar stellen en houden van een (set van) berichten die steeds past bij de actuele behoefte van de belanghebbenden.
5	Wijzigingsprocedure	Wijzigingen op de standaard raakt meerdere belanghebbenden. In de procedure van wijziging zijn hierom de belangen van alle deelnemende partijen vertegenwoordigd. Verzoeken en voorstellen voor wijzigingen zullen een afgesproken procedure worden behandeld.
6	Gegevensspecificaties	In de gegevensspecificaties is de betekenis van de gegevenselementen beschreven en zijn de onderlinge verbanden beschreven. Gegevenselementen zijn entiteiten, attributen en codelijsten. In de gegevensspecificaties is de afbeelding naar AFD 2.0 opgenomen. Hierdoor is duidelijk wat ontbreekt. Voor de ontbrekende elementen is een voorzet gedaan in AFD 2.0 termen.
7	Basisstructuur berichten	Basisbericht met de basisstructuur voor een set berichten. In de basisstructuur staat een opsomming van de entiteiten/attributen en de bijbehorende hiërarchische structuur. De beschrijving van dit basisbericht kan gebruikt worden om een baseline te maken.
8	Kruistabel basisstructuur en berichten	Een kruistabel tussen de basisstructuur en de berichten. Per bericht is in de tabel aangegeven welke entiteiten/attributen van toepassing zijn. Hierbij is het aantal herhalingen (entiteiten) aangegeven en ook welke attributen verplicht gevuld moeten worden. Het is tevens mogelijk selecties uit codelijsten te maken, dat wil zeggen aan te geven welke codewaarden van toepassing zijn.
9	Berichtspecificaties	De specificaties zijn gebaseerd op de gegevensspecificaties. In deze berichtspecificatie wordt dit vertaald naar een hiërarchische berichtstructuur. Onderdeel van de set berichtspecificaties is het responsebericht. Dit moeten we nog opstellen. Ieder bericht kent een algemene sectie waarin onder meer staat aangegeven wie de zender/ontvanger is van het bericht.
10	Berichtcontroles	Een specificatie van alle controles op de berichten, bijvoorbeeld verbandcontroles. Het is een optie deze controles in machine leesbare vorm uit te leveren, maar in eerste instantie is dit niet noodzakelijk.
11	Uitbreiding AFD 2.0	Uitbreiding van AFD 2.0 met gevraagde gegevenselementen. AFD 2.0 kan op verzoek van belanghebbenden maandelijks uitgebreid worden.
12	Baseline	Dit is het basisbericht dat in AOS wordt geïmporteerd. Daarna kunnen AFD-definities gemaakt worden.
13	Schema’s	JSON-Schema of XML-Schema per bericht/basisstructuur. Onder meer om berichten te kunnen valideren. AOS levert JSON-schema’s op basis van AFD 2.0 berichten en AFD-definities.
14	Handleiding events	Voorbeelden van het afhandelen van specifieke situaties. De situaties laten zien hoe de standaard toegepast moet worden. Voorbeeldberichten zijn onderdeel van de handleiding events.
15	Koppelvlakspecificaties	Bij geautomatiseerde koppelingen tussen gedistribueerde systemen (machine-‐machine) is sprake van een interface waarmee communicatie mogelijk wordt gemaakt. Zo'n interface wordt een koppelvlak genoemd. De beschrijving van een koppelvlak noemen we koppelvlakspecificaties. Voorbeelden: Webservices File transfer Aanlevering via portaal Onderdeel van de koppelvlakspecificaties kunnen instructies zijn over de (data)beveiliging. Opmerking: koppelvlakspecificaties hebben Duco/Gerhard niet toegezegd. Als hier vraag naar ontstaat, dan pakken we dat op.
16	Testvoorzieningen	Voorzieningen om de ontwikkelaars te ondersteunen bij het implementeren van de berichten/koppelvlakspecificaties. Onderdeel kan een generieke set zijn met testgegevens.
17	Rekenvoorschriften	Instructies om berekeningen uit te voeren. De berekeningen zijn van toepassing voor gegevenselementen in de berichten.

Berichtcontroles/

Verbandscontroles worden vastgelegd in JMESPath en hebben betrekking op het bericht waarvoor zij zijn geschreven. Controles die berichtoverstijgend zijn; waar dus andere berichten of backoffice informatie voor nodig is vallen buiten de scope van deze controles

JSON-schema’s

De JSON-schema's zijn in principe zelfverklarend, maar enige toelichting kan nuttig zijn omdat deze schema's ook in JSON-technologie zijn opgesplitst. Dit betekent dat naast de verwachte entiteiten en entiteittypen zoals 'party' en 'pension.scheme', er ook wordt gesproken over bepaalde sleutelelementen zoals "$defs", "type", "properties", "additionalProperties" en "required".

Vanaf JSON Schema Draft 2020-12 heet dit "$defs". In oudere versies (draft-07, 2019-09) werd hiervoor de term "definitions" gebruikt.

Deze eigenschappen en specificaties die van toepassing zijn op bijvoorbeeld 'commonFunctional', zijn niet allemaal gegroepeerd rond 'commonFunctional', maar zijn verspreid over het JSON-schema. Het belangrijkste om op te merken is dat deze verspreiding niet willekeurig is, maar volgt uit de verschillende typen eigenschappen

8.4: Vertaaltabel

8.4 Vertaaltabel van functionele attributen naar AFD2.0 attributen.

In het consultatierapport werden op diverse plaatsen andere attribuutnamen gebruikt dan in het uiteindelijke AFD 2.0 model. Hieronder een overzicht van de functionele attribuutnamen en de uiteindelijke AFD 2.0 gegevensnamen.

Attribuutnaam Functioneel	AFD 2.0 entity.entitytype	AFD 2.0 attribuutnaam	Omschrijving
Transfer ID	commonTechnical.default	messageId	Unieke berichtidentificatie
Pensionfund ID	party.pensionProvider	puvCode	ID van het pensioenuitvoerder (PUV-code) / Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)
Pension scheme ID i	pension.scheme	refKey	ID van de pensioenregeling / (Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.))
Capital i	pension.scheme	startAmount	Totaal pensioenvermogen per startdatum
Portfolio	pension.scheme	tradingPortfolioId	Portefeuille ID van de custodian (bewaren en beheren van financiële activa)
Capital date i / Start date PUO admin / Start date Investment Report	financialInformation.reportingPeriod	startDate	Begindatum van de gegevensperiode waarop de aanlevering vanuit de PUO wordt gebaseerd of Peildatum
End date PUO admin	financialInformation.reportingPeriod	endDate	Einddatum van de gegevensperiode waarop de aanlevering vanuit de PUO wordt gebaseerd
Mutations date	financialInformation.reportingPeriod	mutationValuationDate	Datum verwerking mutaties per leeftijdsgroep
End date​ Investment Report	financialInformation.reportingPeriod	endDate	Einddatum van de gegevensperiode waarover rendement wordt gerapporteerd
Trade date	financialInformation.reportingPeriod	tradeDate	Gewenste handelsdatum
Settlement date	financialInformation.reportingPeriod	investmentOrderSettlementDate	Datum waarop de volledige cyclus van de beleggingsorder afgewikkeld moet zijn
Projection date	financialInformation.reportingPeriod	projectionDate	Datum van de projectie van pensioenuitkeringen
instruction date	financialInformation.reportingPeriod	instructionDate	Instructiedatum (datum van de bestelling verzonden door de PUO)
Estimation date	financialInformation.reportingPeriod	unitValueEstimationDate	Geeft de datum aan waarop de voorlopige unitwaarde (belegginspool) is bepaald
Valuation date	financialInformation.reportingPeriod	participationValuationDate	Prijsdatum participatiewaarde (cohortpool)
value date	financialInformation.reportingPeriod	valueDate	Currency date. (NL: Valutadatum)
Date	financialInformation.reportingPeriod	positionDate	De datum waarop de posities in de beleggingsadministratie zijn vastgesteld
Value	financialTransaction.payment	amount	Bedrag in valuta
currency i	financialTransaction.payment	currencyType	Valuta
IBAN debet i	financialTransaction.payment	collectionAccountIban	IBAN-nummer van debet rekening
Description i	financialTransaction.payment	description	Omschrijving van de transactie (betaling)
IBAN credit i	party.creditor	collectionAccountIban	IBAN-nummer van credit rekening per regeling
Counterparty i	party.creditor	collectionAccountInNameOf	Naam van de tegenpartij per regeling
BIC i	party.creditor	collectionAccountBic	Business Identifier Code (BIC) per regeling
BIC-correspondent i	party.creditor	collectionAccountBicCorrespondent	BIC-correspondent per regeling
Contribution i	financialTransaction.cashflow	contributionAmount	Som van inleg
Contribution date i	financialTransaction.cashflow	contributionDate	Datum van ontvangst van de inleg
Withdrawal i	financialTransaction.cashflow	withdrawalAmount	Som van de uitstroom
Withdrawal date i	financialTransaction.cashflow	withdrawalDate	Datum waarop (uiterlijk) de liquiditeiten ten behoeve van de onttrekking zijn vrijgemaakt
Net contribution/withdrawal i	financialTransaction.cashflow	netAmount	Som van inleg en onttrekkingen per regeling (net). Een negatief bedrag is een (netto) withdrawal. / Verschil tussen inleg en onttrekking. Een negatief bedrag is een (netto) onttrekking.)
Net contribution/withdrawal date i	financialTransaction.cashflow	netDate	Datum waarop gesaldeerde instroom en uitstroom wordt gefaciliteerd / Datum waarop het saldo van inleg en onttrekking is bepaald
Cohort ID i, k	financialTransaction.payment	refKey	ID van de expected payment
Expected pension payment Date i, k	financialTransaction.payment	expectedPensionPaymentDate	Pensioenuitkeringsmoment
Hedged expected pension payment i,k	financialTransaction.payment	hedgedExpectedPensionPaymentAmount	Af te dekken kasstroom over alle cohorten
Cohort expected pension payment i,j,k	financialTransaction.payment	amount	Geprojecteerde uitkering over alle cohorten
Cohort ID i, k	pension.cohort	refKey	ID van het cohort
Cohort Capital i,k	pension.cohort	startAmount	Pensioenvermogen van het cohort per begindatum
Net contribution/withdrawal I,k	pension.cohort	netAmount	Som van inleg en onttrekkingen per cohort. Een negatief bedrag is een (netto) onttrekking.)
Cohort contribution i,k	pension.cohort	contributionAmount	Instroom te beleggen door de fiduciair manager
Cohort withdrawal i,k	pension.cohort	withdrawalAmount	Uitstroom te beleggen door de fiduciair manager
Cohort return rate protection i,k	pension.cohort	protectionReturnPercentage	Het behaalde beschermingsrendement in percentage over gegevensperiode per regeling en per cohort
Cohort return rate excess i,k	pension.cohort	excessReturnPercentage	Het behaalde overrendement in percentage over gegevensperiode per regeling en per cohort
Cohort return protection i,k	pension.cohort	protectionReturnAmount	Het behaalde beschermingsrendement in valuta van de regeling over gegevensperiode per regeling en per cohort
Cohort return excess i,k	pension.cohort	excessReturnAmount	Het behaalde overrendement in valuta van de regeling over gegevensperiode per regeling en per cohort
Hedged expected pension payment i,k	financialTransaction.payment	hedgedExpectedPensionPaymentAmount	Af te dekken kasstroom
Cohort expected pension payment i,j,k	financialTransaction.payment	amount	Geprojecteerde uitkering
Cohort ID i, k	pension.cohortPool	cohortRef	Geeft aan op welk cohort in de regeling de cohortpool-gegevens betrekking hebben
Cohort Inflow i-k (1)	pension.cohortPool	inflowPremiumAmount	Premie-inleg per cohortpool per regeling
Cohort Inflow i-k (2)	pension.cohortPool	inflowRebalanceAmount	Geldbedrag van rebalance transacties per cohortpool per regeling
Cohort withdrawal i,k	pension.cohortPool	numberOfNewParticipations	Nieuwe uit te geven participaties in cohortpool per regeling (instroom)
Number of units, i,k	pension.cohortPool	numberOfParticipations	Aantal uitstaande units (participaties) in de Cohortpool
Cohort rebalance i,k	pension.cohortPool	numberOfRebalanceParticipations	Rebalance participaties per cohortpool per regeling (bij overgang van een cohortpool naar een ander cohort)
Cohort Capital i,k / Cohort value i, k	pension.cohortPool	participationsSummedValueAmount	Waarde per cohortpool (som participatiewaarde) per participationValuationDate
Pool ID i,j	investment.pool	refKey	ID van de beleggingspool per regeling
Market value portfolio	investment.pool	marketValueAmount	Marktwaarde per portefeuille per regeling in currencyType
Pool value i, k	investment.pool	unitsSummedValueAmount	Waarde per beleggingspool(unitwaarde)
Market value instrument	investment.pool	marketValueAmount	Marktwaarde van de beleggingspool in currencyType van de pool
Preliminary market value i, k	investment.pool	preliminaryMarketValueAmount	Voorlopige Marktwaarde per portefeuille per regeling in currencyType van de pool
Preliminary pool value i, k	investment.pool	preliminaryUnitValueAmount	Dagelijks vastgestelde unitprijs/NAV in currencyType van de pool
number of units investment pool i,k	investment.pool	numberOfUnits	Aantal units uitgegeven voor de beleggingspool,
currency i,j	investment.pool	currencyType	Valuta van de pool
Transaction description i,j, k /Description	investment.pool	description	Beschrijving
Dummy cash ID	investment.pool	dummyCashId	ID voor dummy cash instrument per beleggingspool per regeling per cohort(pool)
Sell buy ID i,j, k	investment.pool	buySellId	Aan- verkoopindicator; ID voor aan-/verkoop per beleggingspool per regeling per cohort
Amount i,j, k	investment.pool	tradeQuantity	Aantal te verhandelen stukken (units) van de transactie
Unit value i,j, k	investment.pool	unitPrice	Unitwaarde (/prijs) per beleggingspool per regeling per cohort
FX rate i,j, k	investment.pool	currencyExchangeRate	FX rate per beleggingspool per regeling per cohort
Value i,k	investment.pool	tradeValueAmount	Waarde transactie per beleggingspool per regeling (gesommeerd over cohorten)
portfolio ID i,n	investment.portfolio	refKey	ID Beleggingsportefeuille / Unique reference key assigned to an entity. (NL: Entiteitsreferentie is een unieke referentie sleutel die aan een entiteit wordt toegekend.)
Total Market Value start I,n	investment.portfolio	startAmount	De waarde van de Total Market Value aan het begin van de gegevensperiode
Net contribution/withdrawal I, n	investment.portfolio	netAmount	Som van inleg en onttrekkingen per regeling (net). Een negatief bedrag is een (netto) withdrawal
Total Market Value end I,n	investment.portfolio	endAmount	De waarde van de Total Market Value aan het eind van de gegevensperiode. Per regeling en beleggingsportefeuille
Return rate i,n​	investment.portfolio	returnPercentage	Het behaalde rendement in percentage over gegevensperiode per regeling en per beleggingsportefeuille
Return i,n​	investment.portfolio	returnAmount	Het behaalde rendement in valuta van de regeling over gegevensperiode per regeling en per beleggingsportefeuille
Identifier	investment.investmentDetails	refKey	Identifier (bijvoorbeeld ISIN of interne code)
Fund Name i	investment.investmentDetails	description	De naam van de belegging / de officiële naam van het fonds / van het instrument
Local Price i,j, k	investment.investmentDetails	currencyType	Valuta van het instrument
Total holdings i,j, k	investment.investmentDetails	numberOfHoldings	Aantal holdings per instrument per regeling per beleggingsportefeuille
Local Price i,j, k	investment.investmentDetails	localPrice	Prijs per instrument in originele valuta per regeling per beleggingsportefeuille
Local Value instrument i,j, k	investment.investmentDetails	localValueAmount	Totale marktwaarde in originele valuta per instrument per regeling per beleggingsportefeuille[1]
Result i,j, k[1]	investment.investmentDetails	result	Ongerealiseerd resultaat per instrument per regeling per beleggingsportefeuille
Accrued Interest i,j, k	investment.investmentDetails	accruedInterest	Opgelopen rente per instrument per regeling per beleggingsportefeuille
Portfolio weight i,j, k	investment.investmentDetails	poolPercentage	Gewicht in de portefeuille per instrument per regeling per beleggingsportefeuille[2]
FX rate i,j, k	investment.investmentDetails	currencyExchangeRate	FX rates per instrument per regeling per beleggingsportefeuille / koers per positionDate
Trade date / Transaction date	financialTransaction.trade	tradeDate	Gewenste handelsdatum
Adj Trade i, j	financialTransaction.trade	adjustmentIndicator	Aangepaste trade instructie
Buy/Sell i,j	financialTransaction.trade	buySellId	Aan- verkoop- switchindicator
Amount	financialTransaction.trade	tradeAmount	Bedrag van de aankoop in de valuta waarin de belegging luidt
Quantity	financialTransaction.trade	tradeQuantity	Aantal te verhandelen stukken (units) van de transactie
Price i,j	financialTransaction.trade	tradePrice	Aankoopprijs / koers
Switch type	financialTransaction.trade	switchType	Type switch; one-day of sequential
Counterparty i,j	financialTransaction.trade	counterparty	Transfer Agent; de partij die de aankoop/verkoop verricht
Broker i,j	financialTransaction.trade	broker	Effectenmakelaar die beleggingsorders uitvoert namens klanten op de markt
Interest i,j	financialTransaction.trade	interestAmount	Bedrag aan van toepassing zijnde rente
Commission i, j	financialTransaction.trade	commissionAmount	Vergoeding voor het uitvoeren van de transactie
Clearing broker i,j	financialTransaction.trade	clearingBroker	Effectenmakelaar verantwoordelijk administratieve en financiële afwikkeling van de transactie
Cash account i,j	financialTransaction.trade	clearingBrokerCashAccount	Geldrekening (IBAN) bij de clearingbroker op naam van de Pensioenuitvoerder