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