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 FPR-berichten zijn vervallen (zie §4.3.11). Het onderscheid tussen een direct en een gelaagd ordermodel is per release 2027 vervallen; zie §4.2.
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 | van | |
| 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) | 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.
Toelichting: rol versus partij. Tabel 12 is een rollenmatrix en wordt gegenereerd uit het gegevensmodel. De berichten 10 en 14 worden verstuurd door de rol BA. Die rol kan door de PUO worden vervuld; dat maakt de PUO geen tweede verzender. Om die reden staat bij bericht 14 in de PUO-kolom geen van. Zie GitHub issue #142.
Het Feedbackbericht kent geen vaste zender en ontvanger — het volgt het bericht waarop het antwoordt — en valt daarom buiten de gegenereerde rijen.
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. Een bericht kan daardoor aan meer dan één ontvanger worden verstuurd, elk met een eigen endpoint en identificatie; zie §2.4.
Toelichting: achtervoegsels in de berichtdiagrammen op GitHub. Een entiteit kan in één bericht op meer dan één plaats voorkomen. In bericht 3 staat financialTransaction.payment bijvoorbeeld direct onder de regeling, onder het cohort en onder de beleggingsportefeuille. In de berichtdiagrammen op GitHub (het Wiki/Berichtenoverzicht en de map MessageStructureView bij elk bericht) krijgen die plaatsen een achtervoegsel, zoals financialTransaction.payment_1. Dat achtervoegsel is een volgnummer om de plaatsen in het diagram uit elkaar te houden, geen ander entiteitstype: het attribuut entityType heeft op elke plaats dezelfde waarde (hier payment). In het bericht zelf komt het achtervoegsel niet voor; welke plaats bedoeld is, volgt uit de bovenliggende entiteit. Het volgnummer wordt per bericht toegekend, dus hetzelfde achtervoegsel kan in een ander bericht een andere plaats aanduiden. Deze handleiding toont de achtervoegsels niet: in het basisbericht (§6.4.1), de berichtstructuren en de kruistabel (§6.5) staat elke plaats onder haar eigen bovenliggende entiteit.
In onderstaande tabel de berichtsoorten en de betekenis. De berichten die vanaf release 2027 zijn vervallen, staan in §4.3.11. Tussen haakjes de verwijzing naar het eindrapport van de werkgroep1: “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 API2 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, BA/asset serviceprovider en LDI-manager (zie Figuur 1, stroom 1c, en Figuur 8 en 9, stappen F en G). 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 |
Van 🡪 Naar Informatiestroom van PUO naar BA (zie Figuur 8 en 9, stap A). 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 niveau van het beleggingsproduct. De aanbieder van het product 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 | Van 🡪 Naar Informatiestroom van BA naar PUO (zie Figuur 8 en 9, stap B). Vanuit de order verwerkende partij komen de confirmationtgegevens van de order terug naar de PUO. |
| FPR | 10. Stuurinformatie beleggingspools (00553) (5.5.3) |
Stuurinformatie Beleggingspools/ |
Informatie aansturen beleggingspools Van 🡪 Naar Van BA naar FM (zie Figuur 8 en 9, stap E). De PUO verstuurt het alleen wanneer die zelf de rol van BA vervult. 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 | 13. Waarde-informatie beleggingspool (00555b) (5.5.5) |
Waarde-informatie Beleggingspool/ ValueAmountInvestmentPool |
Doorgeven waardes per beleggingspool Van 🡪 Naar Informatiestroom van BA naar PUO (zie Figuur 8 en 9, stappen C en J). De BA berekent de unitwaarde per unit in de beleggingspool en geeft die, met de waarde per beleggingspool, door aan de PUO. |
| FPR | 14. Betaalinformatie (00556) (5.5.6) |
Betaalinformatie/ PaymentDetailsCreditor |
Betaalinstructies onttrekkingen Van 🡪 Naar Informatiestroom van BA naar FM, begin van de maand (zie Figuur 8 en 9, stap L). De PUO verstuurt het alleen wanneer die zelf de rol van BA vervult. 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 minimaal en maximaal kan voorkomen. Met V (verplicht) of O (optioneel) wordt daarbij aangegeven of een entity.entitytype moet of mag voorkomen.
Het basisbericht is een generalisatie over de afzonderlijke berichten en geen bericht op zichzelf. Het toont elke plaats in de hiërarchie die in ten minste één bericht voorkomt. Een entiteit die op meer plaatsen kan staan, komt daarom meer keer voor, elk onder haar eigen bovenliggende entiteit: financialTransaction.payment staat direct onder de regeling, onder het cohort en onder de beleggingsportefeuille. Niet elk bericht kent elke plaats. Welke plaatsen een bericht bevat, en met welke kardinaliteit, staat in de berichtstructuur van dat bericht (§6.4.2 en verder); die kan afwijken van deze tabel.
Uit onderstaande tabel valt bijvoorbeeld af te leiden dat:
1) Per party.sender meerdere party.contact mogelijk
2) Per party.pensionProvider een of meer pension.schemes voorkomen
3) Per pension.scheme precies één financialInformation.reportingPeriod voorkomt; bericht 15 kent geen rapportageperiode (§6.4.11)
| 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 |
| pension.cohort | 0..*, O |
| investment.portfolio | 0..*, O |
| financialTransaction.payment | 0..*, O |
| investment.portfolio | 0..*, O |
| financialTransaction.cashflow | 1..1, V |
| financialTransaction.payment | 0..*, O |
| financialTransaction.cashflow | 0..1, O |
| financialTransaction.payment | 1..*, V |
| party.creditor | 1..1, V |
| investment.investmentDetails | 1..*, V |
| financialTransaction.trade | 1..*, V |
| investment.corporateAction | 1..*, V |
| investment.pool | 1..*, V |
| document.default | 0..*, O |
| chunking.default | 0..1, O |
| error.default | 0..*, 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 | 999, 9999 of 999991 |
| pension.cohort | 99999 |
| investment.pool | 99 |
| investment.portfolio | 99 |
| investment.investmentDetails | 999 |
| investment.corporateAction | 99 |
| financialTransaction.trade | 99 |
| error.default | 99 |
| document.default | 99 |
| chunking.default | 1 |
Het maximum aantal financialTransaction.payment hangt af van de plaats in het bericht: onder pension.scheme 99999 in bericht 3 en 999 in bericht 14; onder pension.cohort en onder investment.portfolio 9999 (bericht 3).↩︎
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 en, voor het FPR-gebruik, 4.3.2.
Tabel in volledig scherm openen
6.4.4 Berichtstructuur 3. Pensioenprojectie (0001c)
Zie ook 3.2.3.
Zie ook, voor het FPR-gebruik, 4.3.3, en voor de routes in de berichten 2, 3 en 4 3.2.5.
Tabel in volledig scherm openen
6.4.5 Berichtstructuur 4. Rendementsinformatie (00002)
Zie ook, voor het FPR-gebruik, 4.3.4.
Zie ook 3.2.4.
Tabel in volledig scherm openen
6.4.6 Berichtstructuur 5. Orderopdracht (00541)
Tabel in volledig scherm openen
6.4.7 Berichtstructuur 6. Orderconfirmation (00542)
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 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.
Tabel in volledig scherm openen
6.4.9 Berichtstructuur 13. Waarde-informatie beleggingspool (00555b)
Tabel in volledig scherm openen
6.4.10 Berichtstructuur 14. Betaalinformatie (00556)
Tabel in volledig scherm openen
6.4.11 Berichtstructuur 15. Corporate Actions (00557)
Tabel in volledig scherm openen
6.4.12 Berichtstructuur Feedback Message
Zie ook 4.4.
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).
-
Eindrapport onderzoek standaard VB PUO (september 2023.pdf. zie: SIVI/Downloads ↩