4 Processen & informatiestromen – Flexibele Premieregeling

4.1 Inleiding

Dit hoofdstuk beschrijft de 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.

De aansturing van het proces van de flexibele premieregeling verloopt volgens één FPR-model voor het “orderen” van beleggingen, dat in de operationele samenwerking tussen pensioenuitvoering en vermogensbeheer wordt toegepast. Eerdere releases onderscheidden hierin een eenvoudiger, direct ordermodel en een uitgebreider, gelaagd ordermodel. Dat onderscheid is vervallen: de gegevensuitwisseling is in beide gevallen dezelfde.

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.

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 binnen het gehele FPR-model.

4.2 Het FPR-model

Het FPR-model kent drie lagen: deelnemers worden ingedeeld in cohorten, en er wordt belegd in beleggingspools. De indeling van deelnemers in cohorten vindt plaats bij de pensioenuitvoeringsorganisatie (PUO).

Die toerekening van cohort naar beleggingspool ligt bij de PUO en maakt geen deel uit van de gegevensuitwisseling. Financiële gebeurtenissen op deelnemerniveau worden door de PUO per cohort geaggregeerd en leiden tot netto orders voor de onderliggende beleggingspools, al naar gelang de strategische verdeling binnen het cohort¹. Voor de vermogensbeheerketen speelt het cohort daarbij geen rol: de deelnemers participeren via de beleggingspools. Omdat de PUO die verdeling kent, is een vermogen per cohort daaruit af te leiden.

Figuur 2 – Het FPR-model Volledige weergave (SVG)

Beleggingspool en beleggingsproduct. In dit hoofdstuk spelen twee lagen een rol, die we uit elkaar houden:

• Beleggingspool: de administratieve eenheid waarin de beleggingen worden gegroepeerd en waarvoor units en unitwaarden worden bijgehouden. In het gegevensmodel is dit de entiteit investment.pool.
• Beleggingsproduct: datgene waarin een beleggingspool belegt. Een beleggingsproduct is een
  • beleggingsfonds: met een eigen fondsstructuur, al dan niet via een handelsplatform verhandelbaar; of een
  • mandaat: een beleggingsopdracht aan een vermogensbeheerder om een portefeuille te beheren volgens vooraf afgesproken richtlijnen en risicolimieten, niet toegankelijk voor andere beleggers (zie §8.1).

In deze handleiding staat beleggingsproduct waar het niet uitmaakt of het om een fonds of een mandaat gaat. Beleggingsfonds en mandaat staan alleen waar dat onderscheid ertoe doet.

Afbakening. De VB-PUO-gegevensuitwisseling reikt tot en met de beleggingspools. Wat zich daaronder afspeelt — de onderliggende beleggingsproducten, liquide en illiquide, en de verdere handelsuitvoering — valt buiten deze standaard. De partij die een order verwerkt kan afhankelijk van de keteninrichting een broker, transfer agent of order desk zijn; die keuze raakt de gegevensuitwisseling niet.

De beleggingen kunnen bestaan uit:

• direct via een platform verhandelbare beleggingsfondsen,
• niet dagelijks verhandelbare beleggingsfondsen,
• niet via een platform verhandelbare (illiquide) fondsen
• mandaten.

Bij handelsplatformen gaat het bijvoorbeeld om AllFunds of Fundsettle, waar beleggingsfondsen direct kunnen worden verhandeld.

De PUO vertaalt mutaties op deelnemersniveau naar benodigde (gesaldeerde) transacties in de beleggingsproducten van operationele vermogensbeheerders. 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.

De pensioenuitvoerder wordt 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 beleggingsproducten). Dergelijke wijzigingen resulteren in transitie-activiteiten bij de PUO en/of de asset serviceprovider/custodian. Specifieker: als een beleggingsproduct 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 beleggingsproduct. Uitzondering zijn de gebeurtenissen die via bericht 15 Corporate actions worden doorgegeven — dividend, rebate, unitmutaties — die de PUO wél moet verwerken; zie §4.3.10.

Cohorten

Een cohort is een administratieve groepering van deelnemers die op basis van het lifecycle principe — minder beleggings- en renterisico naarmate de pensioeningang of de einddatum van de beleggingshorizon nadert — een gelijke beleggingsverdeling kennen. Een cohort kan worden gebruikt om deelnemersgroepen te onderscheiden. Dit kan op basis van tijd (leeftijd, periode tot pensioen etc.) zijn, maar ook op basis van een kenmerk als actief, slaper of arbeidsongeschikt. Het aantal cohorten is in de basis onbeperkt: er worden er zoveel gemaakt als nodig zijn om deelnemersgroepen te onderscheiden die een eigen beleggingsmix vereisen. De verdeling van de gewichten (percentages) wordt veelal door de FM gemaakt.

Hieronder volgt een eenvoudig voorbeeld met indeling in drie lifecycles op basis van leeftijden en de vastgestelde verdeling over aandelen en obligaties.

	Lifecycle defensief		Lifecycle neutraal		Lifecycle offensief
Cohort	% Aandelen	% Obligaties	% Aandelen	% Obligaties	% Aandelen	% Obligaties
Leeftijd 39	90	10	95	5	100	0
Leeftijd 40	88	12	94	6	98	2
Leeftijd 41	86	14	93	7	96	4
Leeftijd 42	85	15	91	9	94	6
Leeftijd 43	84	16	89	11	92	8
Leeftijd 44	83	17	87	13	90	10
Leeftijd 45	82	18	85	15	88	12
Leeftijd 46	81	19	84	16	86	14
Leeftijd 47	80	20	82	18	84	16

Figuur 3 - Voorbeeld cohorten en lifecycles

Het voorbeeld in Figuur 3 laat zien hoe de leeftijd van een deelnemer invloed heeft op de verdeling van beleggingen binnen lifecycles.

Als een deelnemer een jaar ouder wordt, dan wordt een zogenaamde leeftijdsrebalance doorgevoerd, waarbij de deelnemer in een volgend cohort 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 cohorten conform de instructies voor de beleggingentransacties. De risicodelingsreserve wordt gezien als een apart cohort dat conform een eigen beleggingsbeleid in beleggingsproducten belegt.

Rollen en verantwoordelijkheden

Deelnemers participeren in cohorten conform de gekozen lifecycle en de gekozen samenstelling van cohorten. De PUO aggregeert de mutaties op deelnemerniveau per cohort en vertaalt die naar netto orders in één of meer beleggingspools, al naar gelang de strategische verdeling binnen het cohort¹. De beleggingsadministrateur (BA) kent die verdeling niet en hoeft die ook niet te kennen: de BA wordt door de PUO geïnstrueerd met aan- en verkopen in de beleggingspools of rechtstreeks in beleggingsproducten. Deze beleggingspools beleggen in uiteenlopende beleggingsproducten, liquide en illiquide. Om de toedeling naar deelnemers robuust en traceerbaar vorm te geven worden voor de beleggingspools 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. Als eenvoudig voorbeeld geldt eveneens Figuur 3, waarbij “% Aandelen” en “% Obligaties” dan vervangen worden door bijvoorbeeld “% Zakelijke waarden”, “% Vastrentende beleggingen, korte looptijden”, “% Vastrentende beleggingen, lange looptijden”, etc.

In dat proces zijn vier rollen te onderscheiden — dezelfde vier die in de procesflow van §4.3.1 en in Figuur 8 en Figuur 9 terugkomen.

• De PUO heeft de verantwoordelijkheid om conform de door de pensioenuitvoerder vastgestelde allocatieregels de vermogensontwikkeling 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 cohorten. Bij de samenstelling van de cohorten 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.

• De beleggingsadministrateur (BA), ook asset serviceprovider genoemd, voert voor de pensioenuitvoerder de onafhankelijke beleggingsadministratie van de beleggingspools. Die administratie kent twee lagen:

  • de posities: de BA legt vast welke beleggingen zich in de beleggingspool bevinden en in welke omvang. Die vastlegging wordt gevoed vanuit de afwikkeling van mutaties in die beleggingen, uitgevoerd door de operationele vermogensbeheerders die door de FM worden geïnstrueerd, en gereconcilieerd³ met de (schaduw)administratie van de FM;
  • de units: de BA verzorgt de administratie van de beleggingspools (bijvoorbeeld zakelijke waarden, vastrentende waarden), op basis van de instructies van de PUO. Hiervoor worden voor de beleggingspools unitwaarden berekend en het aantal units geadministreerd. Hierbij worden premies, onttrekkingen en herbalanceringen meegenomen. De unitwaardes en het aantal units vormen de basis voor de PUO om vermogen expliciet aan deelnemers toe te delen.

• De fiduciair manager / vermogensbeheerder (FM/VB) ondersteunt de pensioenuitvoerder bij de totstandkoming van het integrale beleggingsbeleid en draagt zorg voor de uitvoering daarvan. De FM stuurt daarbij de operationele vermogensbeheerders aan, die onderdelen van de portefeuille beheren. De FM zal ook een (schaduw)beleggingsadministratie voeren.

• De LDI-manager voert het renterisicobeleid uit op het LDI-mandaat, gericht op het beschermingsrendement, en wordt daarbij door de FM/VB gemonitord.

Deze rolverdeling is niet voorschrijvend: rollen kunnen in een alternatieve inrichting door een en dezelfde partij worden uitgevoerd. Zie §2.5.

Rendementstoedeling. De allocatie van de rendementen kan door de PUO of door de beleggingsadministrateur worden gedaan. Of het rendement expliciet wordt toegedeeld hangt af van de inrichting. Bij een unitized inrichting zit het rendement verwerkt in de unitprijs; er is dan geen sprake van expliciete rendementstoedeling, en de BA deelt daartoe periodiek de waardering van de beleggingspools met de PUO via bericht 13. Wordt de collectieve uitkeringsvoorziening in euro's geadministreerd, dan wordt het rendement wél expliciet toegedeeld, via bericht 4.

Opbouwfase en uitkeringsfase

In het FPR-proces wordt onderscheid gemaakt tussen een opbouwfase en een uitkeringsfase.

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 er gekozen wordt 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 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 cohort naar de FM. De gegevensuitwisseling zal daarvoor conform de gegevensuitwisseling 1c uit de SPR worden opgezet.

4.3 Informatiestromen FPR

De gegevensuitwisseling binnen het FPR-model verloopt via de berichten die in deze paragraaf worden beschreven. Welke partij welk bericht verstuurt en ontvangt, is vastgelegd per rol; zie Tabel 12 in §6.4. Een rol kan door verschillende partijen worden vervuld — zo kan een PUO de rol van beleggingsadministrateur vervullen — maar dat verandert de informatiestroom niet.

De twee procesplaten in §4.3.1 geven eerst het overzicht; daarna volgen de berichten in oplopende berichtnummer. De berichten 2, 3 en 4 zijn SPR-berichten die binnen de FPR worden hergebruikt: 2 en 4 voor de stromen die niet via de unit-administratie lopen, 3 voor het profiel renterisico richting FM/VB en LDI-manager; zie §4.1 voor de achtergrond daarvan. De berichten 5 tot en met 15 vormen de eigen FPR-berichtenset. Daarvan zijn de berichten 7, 8, 9, 11 en 12 per release 2027 vervallen; zij staan, met de reden, in §4.3.11.

4.3.1 Procesflow FPR

Deze paragraaf geeft het overzicht van de FPR-procesflow. De gestandaardiseerde gegevensuitwisselingen zijn in de figuren als pijlen aangegeven, met de berichtnummers erbij. Welke gegevens elke informatiestroom draagt, staat in de berichtparagrafen hierna.

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. Timing, frequentie en de vraag of een bericht voorlopig, definitief of in beide vormen wordt aangeleverd, leggen partijen vast in afspraken tussen ketenpartijen (TOM / SLA).

Figuur 8 en Figuur 9 tonen geen verschillende FPR-modellen. Zij tonen twee administratieve inrichtingen van de opbouwfase en de collectieve uitkeringsfase (CVP)²:

	Opbouwfase	CVP
Figuur 8	unitized	unitized
Figuur 9	unitized	in EUR

De opbouwfase is in beide gevallen unitized. Het verschil zit uitsluitend in de administratieve representatie van de CVP: in units, of in euro's. Die keuze bepaalt welke aanvullende informatiestromen nodig zijn.

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

Wat de platen niet tonen. Figuur 8 en Figuur 9 tonen één doorloop van de handelscyclus voor één administratieve inrichting. Daarbuiten vinden uitwisselingen plaats die er niet in staan. Een bericht kan aan meer dan één ontvanger worden verstuurd, elk met een eigen endpoint en identificatie, en met een doel dat per ontvanger kan verschillen; zie §2.4. Ook aanvullende aanleveringen van hetzelfde bericht hebben in de platen geen eigen stap.

Stapletters. Figuur 8 en Figuur 9 delen hun stapletters: dezelfde letter staat in beide figuren voor dezelfde stap. Ontbreekt een letter in een figuur, dan komt die stap in die inrichting niet voor. Zo kent Figuur 8 geen stap K, omdat het rendement van de CVP daar in de unitwaarde besloten ligt en geen apart bericht 4 vraagt.

Bericht 15 staat niet in de procesplaten. Corporate actions volgen hun eigen ritme en vallen buiten de handelsrun van T-4 tot en met T+3. Zou het bericht in Figuur 8 en 9 worden opgenomen, dan suggereert dat een tijdsrelatie met de handelscyclus die er niet is. Zie §4.3.10.

Figuur 8 — Procesflow FPR: opbouw en CVP unitized Volledige weergave (SVG)

Toelichting bij Figuur 8: opbouw en CVP unitized

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

Kleurcodering: grijze pijlen zijn generieke stromen die in beide figuren identiek zijn. Blauwe pijlen markeren stromen die hier een bredere betekenis hebben doordat ze zowel opbouw als CVP dekken. De tijdsaanduidingen (T-4, T, T+3) zijn indicatief; T is het handelsmoment.

Fase 1 — Order inleg (T-4): De PUO stuurt een orderopdracht (SIVI 5, stap A) naar de BA. De BA levert dezelfde dag de waarde-informatie beleggingspool (SIVI 13, stap C), die hier tevens het CVP-rendement dekt. Die koersinformatie is nodig om de order in units te kunnen uitdrukken.

Fase 2 — Sturing richting FM/VB en LDI (T-4): De BA stuurt netto stuurinformatie (SIVI 10, stap E) naar de FM/VB. De PUO stuurt het profiel renterisico (SIVI 3 — bericht 3, Pensioenprojectie, 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 terug naar de BA (stap I).

Op T+3 volgt de terugkoppeling naar de PUO: eerst de orderconfirmation (SIVI 6, stap B), dan de definitieve maandeinde-NAV (SIVI 13, stap J). Op basis daarvan stuurt de BA de definitieve betaalinformatie naar de FM (SIVI 14, stap L), waarna de FM de cash-afwikkeling verzorgt (stap M).

Over de terugkoppeling van uitgevoerde transacties. De stappen I en M dragen geen kanaalnaam. In de praktijk verloopt dit meestal via SWIFT, maar de standaard schrijft dat niet voor: niet alle instrumenten worden zo teruggekoppeld — swaps bijvoorbeeld lopen anders. Welk kanaal ketenpartijen hiervoor gebruiken is een onderlinge afspraak en valt buiten de VB-PUO-gegevensuitwisseling.

Afzender van de berichten 10 en 14. Deze berichten worden verstuurd door de rol BA. De PUO/ZAF stuurt ze alleen wanneer die zelf de rol van beleggingsadministrateur vervult. In de rollenmatrix van §6.4 staat daarom uitsluitend de BA als verzender. Zie GitHub issue #142.

Waarom hier geen aparte CVP-waardering staat. Omdat de CVP via netting meeloopt in dezelfde unit-administratie, dekt stap J zowel de beleggingspool als de CVP. Na stap M vindt geen handel meer plaats, zodat een tweede waarderingsbericht niet nodig is. In Figuur 9 ligt dat anders: daar heeft de CVP een eigen uitvoeringscyclus en daarmee een eigen waardering.

Figuur 9 — Procesflow FPR: opbouw unitized; CVP in EUR Volledige weergave (SVG)

Toelichting bij Figuur 9: opbouw unitized; CVP in EUR

Hier wordt de CVP niet in units maar in euro's geadministreerd, terwijl de opbouwfase wél unitized blijft. Dat leidt tot aanvullende informatiestromen, omdat rendement en cashflows van de CVP niet via de unit-administratie meelopen.

Wat hier over de CVP staat, geldt op dezelfde manier voor andere collectieve delen die in euro's worden geadministreerd: de risicodelingsreserve, een eventueel compensatiedepot en overige reserves en voorzieningen. Ook daarvoor is een aparte cash-instructie en een aparte rendementsopgave nodig, om dezelfde reden.

Kleurcodering: grijze pijlen zijn generieke stromen (zie Figuur 8 voor de volledige kleurcodering). Groene pijlen markeren de stromen die specifiek zijn voor een CVP in EUR.

De opbouwfase (stappen A t/m J) verloopt gelijk aan die in Figuur 8. Het verschil zit in de aanvullende groene stromen:

• Cash-instructie CVP (stappen O en P, T-4): cash-instructies in EUR gaan via SIVI 2 naar de FM/VB, gelijktijdig met de orderopdracht (SIVI 5). Wie die instructie verstuurt, hangt af van de aard van de mutatie. Gaat het om een switch — vermogen verschuift van de opbouwfase naar de CVP en het totaal belegde vermogen verandert niet — dan verstuurt de BA de instructie; die kent immers beide kanten van de switch. Gaat het om een complete sell — vermogen verlaat de keten, bijvoorbeeld bij uitkering of uitgaande waardeoverdracht — dan verstuurt de PUO de instructie. Beide situaties komen in de praktijk voor.

  De EUR-order voor de CVP loopt dus niet via de orderopdracht (SIVI 5). Bericht 5 betreft de unitized orders in de beleggingspools; over de aanstaande cashflow voor de non-unitized delen wordt de FM/VB geïnformeerd via de cash-instructie (SIVI 2 — bericht 2, Cashflow). Zie ook §4.1. - 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. - Terugkoppeling CVP (stap R): uitgevoerde transacties en cash-overboekingen naar de pensioenrekening komen terug naar de BA.

Geen apart waarderingsbericht na de CVP-uitvoering. Hoewel de CVP een eigen uitvoeringscyclus kent (stappen Q en R), volgt daarna geen waarderingsbericht (SIVI 13) voor de CVP in EUR. De CVP wordt immers niet in units geadministreerd, zodat er geen unitwaarde door te geven valt. Het rendement over de CVP bereikt de PUO via SIVI 4 (stap K).

4.3.2 Bericht 2. Cashflow (0001b)

Informatiestroom van PUO of BA naar FM/VB

Bericht 2 is een SPR-bericht dat binnen de FPR wordt hergebruikt voor de periodieke kasstroominformatie. Het wordt gebruikt voor die geldstromen die niet via de unit-administratie lopen — met name de collectieve stromen. Wie het bericht verstuurt hangt af van de mutatie: bij een switch de BA, bij een complete sell de PUO (zie §4.3.1, Cash-instructie CVP). Zie ook §4.1.

Strekking en betekenis

Het bericht meldt de verwachte of vastgestelde netto kasstroom per beleggingsportefeuille, zodat de ontvangende partij daar liquiditeit op kan inrichten. Het gaat daarbij zowel om uitkeringen als om overboekingen van vermogen vanuit de opbouwfase naar de collectieve uitkeringsvoorziening (CVP) of naar reserves.

Invulpatroon binnen FPR

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. De SPR-route (cashflow rechtstreeks onder pension.scheme, met uitsplitsing via pension.cohort) en de FPR-route sluiten elkaar uit. Zie §6.3.1 voor de verbandscontroles en §6.4.3 voor de berichtstructuur.

Naast de cashflow per portefeuille kan de cashflow direct onder de regeling het totaal dragen; die geldt in beide routes. De bedragen en datums van in- en uitstroom zijn in elk cashflowblok optioneel; netAmount en netDate zijn overal verplicht. Op de beleggingsportefeuille staan geen reservevelden. Zie §3.2.5 voor de berichten 2, 3 en 4 samen.

Figuur 1a — Bericht 2 Cashflow (0001b): SPR- en FPR-route (zie ook §3.2.2) Volledige weergave (SVG)

De FPR-route is groen: per beleggingsportefeuille precies één cashflow. Grijs geldt voor beide routes, blauw is de SPR-route. Vetgedrukte velden zijn verplicht, cursieve optioneel. De figuur toont alleen de velden die voor de routes van belang zijn; de volledige berichtstructuur staat in §6.4.3.

Verhouding tot de berichten 5, 10 en 14

Bericht 2 en de orderketen doen twee verschillende dingen. De orderketen — bericht 5 (orderopdracht), bericht 10 (stuurinformatie) en bericht 14 (betaalinformatie) — betreft de unitized stromen: die worden per beleggingspool in units geadministreerd en leiden tot orders en de bijbehorende afwikkeling. Bericht 2 betreft juist de stromen die níet unitized zijn en dus geen order in een beleggingspool opleveren. De twee vullen elkaar aan; ze zijn geen alternatieven voor elkaar.

Verwachte of vastgestelde cashflow

Bericht 2 kan zowel een verwachte als een vastgestelde netto kasstroom dragen. §3.2.2 beschrijft die twee toepassingen — vooruitkijkend voor liquiditeitsbeheer, terugkijkend voor analyse en verantwoording — en stelt dat zij in de praktijk naast elkaar kunnen bestaan. Binnen FPR geldt dat onverkort. Welke toepassing een keten gebruikt, op welk moment en met welke frequentie, leggen partijen vast in afspraken tussen ketenpartijen (TOM / SLA). De positie op T-4 in de procesplaten past bij de vooruitkijkende toepassing en is indicatief.

Volgorde, niet tijdstip. In de procesplaten staat bericht 2 op T-4 (Figuur 9, stappen O en P). Dat past bij de vooruitkijkende toepassing: een verwachte kasstroom vraagt geen afwikkeling vooraf. Gaat het om vermogen dat vanuit de opbouwfase naar de CVP wordt overgeboekt, dan ontstaat het definitieve bedrag pas uit de afwikkeling van de unitverkoop — in de platen op T+3, waar de orderconfirmation (stap B) en de definitieve maandeinde-NAV (stap J) staan. Een vastgestelde opgave volgt dus op die stappen.

Van de tijdstippen zelf kan een keten afwijken; van die opeenvolging niet. De platen tonen alleen de vooruitkijkende aanlevering — zie Wat de platen niet tonen in §4.3.1.

4.3.3 Bericht 3. Pensioenprojectie (0001c)

Informatiestroom van PUO naar FM/VB en LDI-manager

Ook bericht 3 is een SPR-bericht dat binnen FPR wordt hergebruikt. In de procesflow levert de PUO daarmee het profiel renterisico aan de FM/VB en de LDI-manager (Figuur 8 en 9, stappen F en G). Voor de strekking zie §3.2.3.

Invulpatroon binnen FPR

In FPR kunnen de geprojecteerde uitkeringen per beleggingsportefeuille worden aangeleverd, via pension.scheme → investment.portfolio → financialTransaction.payment. De portefeuilletak is bedoeld voor regelingen waarin meerdere beleggingsportefeuilles worden onderscheiden. Per portefeuille staan dezelfde betalingsgegevens als per cohort; reservevelden staan niet op de portefeuille. De betalingen direct onder de regeling zijn regelingtotalen en gelden in beide routes. Zie §3.2.5 voor de verhouding tot de SPR-route.

Figuur 9a — Bericht 3 Pensioenprojectie (0001c): SPR- en FPR-route Volledige weergave (SVG)

De FPR-route is groen: de betalingen per beleggingsportefeuille. Grijs geldt voor beide routes, blauw is de SPR-route. Vetgedrukte velden zijn verplicht, cursieve optioneel. De figuur toont alleen de velden die voor de routes van belang zijn. Zie GitHub issue #113.

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

4.3.4 Bericht 4. Rendementsinformatie (00002)

Informatiestroom van BA naar PUO

Ook bericht 4 is een SPR-bericht dat binnen FPR wordt hergebruikt. Het geeft het behaalde rendement door over dat deel van het vermogen waarvoor het rendement niet al in een unitwaarde besloten ligt.

Strekking en betekenis

Bij een unitized inrichting is bericht 4 niet nodig: het rendement zit verwerkt in de unitprijs, en bericht 13 geeft die prijs door. Bericht 4 is bedoeld voor de collectieve delen die in euro's worden geadministreerd — de collectieve uitkeringsvoorziening, de risicodelingsreserve en eventuele andere reserves en voorzieningen — waar het rendement wél expliciet moet worden toegedeeld. Bericht 13 kan daar niet voor in de plaats komen: zonder unit-administratie is er geen unitwaarde om door te geven.

Of een keten bericht 4 gebruikt hangt dus af van de inrichting. Figuur 8 en 9 tonen beide varianten: bij een unitized CVP komt bericht 4 niet voor, bij een CVP in euro's wel (stap K). §3.2.4 merkt vanuit de SPR-kant hetzelfde op: de rendementsuitwisseling kan ook bij een specifieke uitvoeringsvariant van de flexibele premieregeling worden gebruikt.

Figuur 9b — Bericht 4 Rendementsinformatie (00002): SPR- en FPR-route Volledige weergave (SVG)

In bericht 4 is de beleggingsportefeuille grijs: zij geldt voor beide routes, met minstens één en ten hoogste 99 portefeuilles per regeling. De uitsplitsing per cohort (blauw) is optioneel. Vetgedrukte velden zijn verplicht, cursieve optioneel. De figuur toont alleen de velden die voor de routes van belang zijn.

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

4.3.5 Bericht 5. Orderopdracht (00541)

Informatiestroom van PUO naar BA

Deze informatiestroom bevat de minimale set aan gegevens die benodigd is om een order te kunnen sturen aan de 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 is een andere rol dan de order verwerkende partij, die de order van de PUO afhandelt en bijvoorbeeld een broker, transfer agent of order desk kan zijn. Dat kan onder andere genoteerde en illiquide beleggingen betreffen.

Switch-conventie. Een switch bestaat uit twee gekoppelde orders: één met buySellId = switchfrom (het beleggingsproduct dat wordt verlaten) en één met buySellId = switchto (het beleggingsproduct 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 opeenvolgende (1, sequential) of gelijktijdige (2, one-day) switch betreft (codelijst AFDSWI). 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, behalve bij de leg van een switch die niet stuurt (zie hieronder). Als een instructie zowel een bedrag- als een hoeveelheidcomponent heeft, worden die als afzonderlijke trade-records vastgelegd. Zie GitHub issue #116.

Bij een switch stuurt één van beide legs. Een switch bestaat uit twee gekoppelde orders, en maar één daarvan wordt werkelijk geïnstrueerd; de andere volgt eruit. Draag je op "verplaats 20 units uit product A", dan draagt de switchfrom-leg tradeQuantity en blijft de switchto-leg leeg: hoeveel units in het ontvangende product worden verkregen, hangt af van de opbrengst én van de koers op het uitvoeringsmoment, en is bij het instrueren niet vast te stellen. Draag je omgekeerd op "leg € 3.000 in product B", dan draagt de switchto-leg het bedrag en blijft de switchfrom-leg leeg. Vandaar de regel: per switchpaar draagt precies één leg precies één van beide velden, en de andere leg geen van beide. Welke leg gevuld is, geeft zelf aan welke kant de switch stuurt; een apart veld daarvoor is niet nodig.

Switches in de praktijk. Bericht 5 wordt in de praktijk vooral gebruikt om bij de overgang van de opbouwfase naar de collectieve uitkeringsfase (CVP) een aantal units aan een beleggingsproduct te onttrekken. De switchfrom-leg draagt dan het aantal units (tradeQuantity); de switchto-leg blijft leeg. De geldwaarde van die units staat niet in bericht 5, maar volgt via bericht 6.

In bericht 6 geldt deze regel niet. Een orderconfirmation meldt wat er is uitgevoerd, en dan zijn aantal, koers en bedrag alle drie bekend. Daar komen tradeQuantity, tradePrice en tradeAmount doorgaans samen voor; komen aantal en koers beide voor, dan geldt tradeQuantity × tradePrice = tradeAmount (zie §6.3.2). Bij een switch is dat ook de verbinding tussen de twee legs: het bedrag dat uit de switchfrom-leg komt, gaat de switchto-leg in. De verbandscontroles van bericht 5 en 6 staan samen in §6.3.2.

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

4.3.6 Bericht 6. Orderconfirmation (00542)

Informatiestroom van BA naar PUO

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.3.7 Bericht 10. Stuurinformatiebeleggingspools (00553)

Informatiestroom van BA naar FM

Strekking en betekenis

Bericht 10 geeft de fiduciair manager de netto stuurinformatie per beleggingspool: wat er per saldo bij moet komen of uit moet, zodat de FM/VB de onderliggende beleggingen kan aansturen. Waar bericht 5 een instructie is aan de administratie, is bericht 10 een signaal aan het beleggingsproces.

Bericht 10 wordt verstuurd door de beleggingsadministrateur. De PUO verstuurt het alleen wanneer die zelf de rol van beleggingsadministrateur vervult (zie Afzender van de berichten 10 en 14 in §4.3.1). De informatie die daarvoor nodig is ontvangt deze via bericht 5 (Orderopdracht) van de PUO.

Van bericht 5 naar bericht 10

Tussen beide berichten zit een vertaalslag, die de BA uitvoert:

• Van instructie naar saldo. Bericht 5 bevat de afzonderlijke orderinstructies. De BA saldeert die per beleggingspool tot één netto koop- of verkoopbehoefte. Instructies die tegen elkaar wegvallen, bereiken het beleggingsproces dus niet.
• Van units naar bedragen. Bericht 5 kan zowel op bedrag (tradeAmount) als op aantal units (tradeQuantity) instrueren. Bericht 10 drukt de behoefte uit in een bedrag, waarvoor de BA de unitwaarde uit bericht 13 gebruikt.
• Switches vallen grotendeels weg. Een switch bestaat uit een switchfrom- en een switchto-leg. Betreffen die dezelfde beleggingspool, dan salderen ze en levert de switch geen stuurinformatie op. Alleen wanneer de legs verschillende pools raken, blijft er een netto behoefte over.

Zie ook de toelichting bij Figuur 8 en 9 (stap E). Functionele uitwerking: zie §6.4.8.

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

Zie de toelichting bij Figuur 8 en 9 (stappen C en J).

Informatiestroom van BA naar PUO

Strekking en betekenis

Bericht 13 is het bericht waarop de hele unitized administratie steunt. Zonder een unitwaarde kan de PUO geen vermogen aan deelnemers toedelen, geen order in units omrekenen en geen betaling afstemmen. Het bericht is daarmee geen terugkoppeling achteraf maar een voorwaarde vooraf: de andere partijen kunnen pas verder zodra de BA de waardering heeft afgegeven.

Bericht 13 geeft de waardering van de beleggingspools door. De beleggingsadministrateur stelt hiermee de unitwaarden en de administratieve koers van de beleggingspools beschikbaar aan de betrokken partijen, zodat die hun administratie, waardering en vervolgverwerking kunnen uitvoeren.

Het bericht bevat per beleggingspool het ID (refKey) en de beschrijving (description), de waarde per beleggingspool (unitsSummedValueAmount), de netto vermogenswaarde per unit (preliminaryUnitValueAmount), het aantal uitgegeven units (numberOfUnits) en de valuta van de pool (currencyType).

In de procesflow komt dit bericht tweemaal voor. Op T-4 levert het de waarde-informatie van de beleggingspool (Figuur 8 en 9, stap C); op T+3 de definitieve maandeinde-NAV (stap J). Daarmee voorziet bericht 13 zowel in de koersinformatie die nodig is om orders te vormen, als in de definitieve waardering waarop de reconciliatie en de betaalinformatie worden gebaseerd.

Functionele uitwerking: zie §6.4.9.

4.3.9 Bericht 14. Betaalinformatie (00556)

Informatiestroom van BA naar FM

Strekking en betekenis

Bericht 14 wordt verstuurd door de beleggingsadministrateur. De PUO verstuurt het alleen wanneer die zelf de rol van beleggingsadministrateur vervult. Per regeling bevat het bericht minstens één en ten hoogste 999 betalingen (financialTransaction.payment). Zie GitHub issue #149. Bericht 14 sluit de handelscyclus af. Nadat de definitieve maandeinde-NAV bekend is (bericht 13, stap J), stelt de beleggingsadministrateur vast welk bedrag daadwerkelijk moet worden overgemaakt en aan wie. Het bericht is daarmee de brug tussen de administratie en de feitelijke geldstroom: waar bericht 5 en 10 gaan over wat er moet gebeuren, gaat bericht 14 over wat er is gebeurd en wat er wordt betaald.

Voor de FM is het bericht de grondslag voor de cash-overboeking van de definitieve betalingen (stap M).

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

4.3.10 Bericht 15. Corporate Actions (00557)

Informatiestroom van de vermogensbeheerketen naar de PUO

Bericht 15 is een ad-hocbericht: het hoort niet bij de reguliere maandstroom en staat daarom niet in Figuur 8 en 9. 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.

Toepassingsgebied. Het bericht hoort bij de inrichting waarin direct via een handelsplatform verhandelbare beleggingsfondsen worden verhandeld; zie §4.2. Op de beleggingspools zelf zijn corporate actions niet van toepassing — die doen zich voor op de onderliggende beleggingsproducten.

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 = 99 (Anders, codelijst AFDCOA). Een aparte code voor rebate is op het moment van schrijven nog niet beschikbaar in AFDCOA. Het rebatebedrag wordt vastgelegd in cashDividendTotalAmount en/of cashDividendPerUnitAmount, dezelfde attributen als bij een cashdividend (corporateActionType = 1). Zolang rebate geen eigen code heeft, is een rebate in het bericht niet te onderscheiden van andere corporate actions met code 99. Zie GitHub issue #137.

AFDCOA kent nu de codes 1 Cash dividend, 2 Stock dividend, 3 Productverandering en 99 Anders.

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

Zie GitHub issue #87.

4.3.11 Vervallen berichten

Vijf berichten uit eerdere releases zijn per release 2027 niet meer actief. Zij staan hier bij elkaar, zodat de beschrijving van de actieve berichten hierboven aaneengesloten leesbaar blijft. De berichtnummering is ongewijzigd gelaten: de nummers 7, 8, 9, 11 en 12 worden niet opnieuw uitgegeven.

Bericht	Omschrijving	Waarom vervallen
7 (00551)	Mutatiesaldi — informatiebehoefte administrateur cohortenpools en beleggingspools	De cohortenpool als administratieve laag is vervallen; de gegevens landen rechtstreeks op beleggingspoolniveau.
8 (00552a)	Reconciliatie-informatie	Hoorde bij de rol administrateur cohortenpools, die als zelfstandige actor is vervallen.
9 (00552b)	PUO-reconciliatie-informatie	Idem; aanvullende stroom voor het geval de PUO die rol vervulde.
11 (00554)	Rebalancinginformatie — rebalancing cohortenpools	Rebalancing op cohortenpoolniveau bestaat niet meer.
12 (00555a)	Waarde-informatie cohortenpool	Vervangen door bericht 13, dat de waarde op beleggingspoolniveau geeft.

Zie GitHub issues #99, #119 en #121.

Het berichtenschema kan deze uitwisselingen desgewenst nog steeds ondersteunen; zij maken alleen geen deel meer uit van de actieve berichtenset.

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

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. Uitzondering is chunking: chunks van hetzelfde logische bericht delen dezelfde messageId (zie §7.6).

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 cohort A de (strategische) verdeling van de beleggingen 30% beleggingspool I en 70% beleggingspool II zijn. Bij cohort B kan die verdeling 40:60 zijn. ↩↩

2. De procesplaten zijn in groot formaat te openen via de link Volledige weergave (SVG) onder elke figuur. ↩

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