Ga naar inhoud

8.5: Wijzigingen release 2027

8.5 Wijzigingen release 2027

Deze paragraaf vat samen wat er in deze handleiding is veranderd ten opzichte van release 2026: eerst wat voor alle of meer berichten geldt, dan wat per bericht verandert, en tot slot de opbouw van de handleiding. Wat na de prerelease van 21 juli 2026 is bijgekomen of gewijzigd, is rood. Paragraafnummers verwijzen naar deze versie. De wijzigingen in de JSON-schema's staan in de releasenotes.

Voor alle of meer berichten

FPR-model en rollen

  • Eén FPR-model: het onderscheid tussen model 1 (direct ordermodel) en model 2 (gelaagd ordermodel) is vervallen, met één schematische weergave (Figuur 2). Wat zich onder de beleggingspool afspeelt, valt buiten de gegevensuitwisseling (§4.1, §4.2).
  • De cohortenpool is als laag tussen cohort en beleggingspool vervallen. De PUO aggregeert de mutaties op deelnemerniveau per cohort en vertaalt die rechtstreeks naar netto orders in één of meer beleggingspools; die toerekening ligt bij de PUO en valt buiten de gegevensuitwisseling. De beleggingsadministrateur kent de strategische verdeling binnen een cohort niet en administreert de beleggingspools op instructie van de PUO (§4.2). In de vertaaltabel (§8.4) zijn de rijen van pension.cohortPool vervallen.
  • De rol ACB (Administrateur cohorten- en beleggingspools) is vervallen als zelfstandige actor; in de praktijk vult de BA of de PUO haar in, en het berichtenschema kan de rol nog ondersteunen (§6.4). Zie #131. De rollen zijn teruggebracht tot de vier uit Figuur 8 en 9: PUO, BA, FM/VB en LDI-manager.
  • Beleggingsproduct is de overkoepelende term voor beleggingsfondsen, mandaten en overige beleggingen; de beleggingspool is de administratieve laag daarboven (§4.2, §4.3.5, §6.4). Begrippen LDI-mandaat en Mandaat toegevoegd aan §8.1; ook Beleggingsproduct, Beleggingsfonds en Virtuele pool, de laatste met de aantekening dat de standaard die term niet gebruikt.
  • Voor collectieve premiestromen binnen FPR (risicopremies, reserves, onttrekkingen) worden de SPR-berichten 1 tot en met 4 gebruikt (§4.1). Zie #91. Binnen FPR dienen de berichten 2 en 4 voor de stromen buiten de unit-administratie en bericht 3 voor het profiel renterisico richting FM/VB en LDI-manager (§4.3).
  • Rendementstoedeling hangt af van de inrichting: bij unitized producten zit het rendement in de unitprijs, bij een collectieve uitkeringsvoorziening in euro's loopt het via bericht 4 (§4.2).

Procesflow FPR (Figuur 8 en 9, §4.3.1)

  • Figuur 8 en 9 zijn indicatief: de tijden zijn indicatief, de volgorde van de stappen is richtinggevend. Zij tonen één doorloop van de handelscyclus voor één administratieve inrichting; verzending aan meer ontvangers en aanvullende aanleveringen hebben geen eigen stap. Beide figuren gebruiken dezelfde stapletter voor dezelfde stap.
  • Fase 1 heet order inleg en beslaat alleen T-4; de terugkoppeling op T+3 (orderconfirmation, bericht 6, en definitieve maandeinde-NAV, bericht 13) staat bij fase 3.
  • Fase 3: de LDI-manager voert zelf de transacties op het LDI-mandaat uit (H1); de FM/VB monitort de LDI-manager en handelt de overige beleggingsportefeuilles af (H2). Figuur 8 toont die gesplitste uitvoering nu ook, met de terugkoppeling.
  • Figuur 9 (non-unitized): de cash-instructie voor de CVP gaat op T-4, gelijk met de orderopdracht (was T+3). Bij een switch verstuurt de BA die instructie, bij een complete sell de PUO. De EUR-order voor de CVP loopt niet via de orderopdracht (bericht 5); het waarderingsbericht na de CVP-uitvoering is vervallen, het rendement bereikt de PUO via bericht 4. Hetzelfde geldt voor andere collectieve delen in euro's: risicodelingsreserve, compensatiedepot, overige reserves en voorzieningen.
  • De terugkoppeling van uitgevoerde transacties loopt gewoonlijk via SWIFT, maar dat is niet voorgeschreven en niet voor alle instrumenten zo (swaps lopen anders); het kanaal is een onderlinge afspraak. De kanaalnamen zijn uit de platen gehaald.

Zender en ontvanger (Tabel 12, §6.4)

  • Tabel 12 heeft nieuwe actorkolommen: Soort, ACB en BR vervallen, LDI erbij. Zie #99, #119, #121, #98.
  • Zender en ontvanger volgen overal Figuur 1 (SPR) en Figuur 8 en 9 (FPR), in Tabel 12, in het overzicht van de berichtsoorten (§6.4) en in hoofdstuk 4. Tabel 12 is een rollenmatrix: de berichten 10 en 14 verstuurt de BA, de PUO alleen als die zelf de rol van BA vervult. Zie #142. De wijzigingen per bericht staan hieronder.
  • Uitgangspunt: ontvangen informatie wordt niet doorgestuurd, dus de verzender stuurt hetzelfde bericht aan elke ontvanger afzonderlijk, met een eigen endpoint en identificatie. Het doel kan per ontvanger verschillen: dezelfde orderopdracht is voor de een een instructie, voor de ander een kennisgeving (§2.4).

Reserves en voorzieningen (§6.3)

  • Rolverdeling: refKey identificeert, reserveType (AFDRES) classificeert en is de sleutel voor het beleggingsbeleid, reserveDescription beschrijft. Zie #111.
  • Codelijst AFDRES uitgebreid met de codes 9 tot en met 15. Bij gedeeld beleggingsbeleid kan worden ingedikt; een eigen code alleen bij separaat beleggingsbeleid. Geldt voor SPR en FPR. Zie #134.
  • Bij reserveIndicator = true is reserveType verplicht; reserveDescription is bij 99 (Overige) gewenst en bij de andere codes mogelijk.
  • De reservevelden staan alleen in het cohort, niet op de beleggingsportefeuille.

Overige regels

  • Cohorten met waarde 0 mogen worden meegestuurd met 0 of weggelaten. Zie #100. De regel staat in §6.3 en geldt voor alle berichten met cohorten (1 tot en met 4), ook voor reserves en voorzieningen; het weglaten van een reserve betekent niet vanzelf dat de waarde 0 is. Een veld zonder waarde (null) kent de standaard niet.
  • messageId is uniek over alle berichten heen en dient niet voor groepering of bundeling; uitzondering is chunking (§6.3, §7.6). Zie #108.
  • Datumconventies voor startDate en projectionDate (§6.3, §3.2.1, §3.2.3). Zie #94.
  • APF's met meer kringen: twee gangbare scenario's voor de PUV-codes (§6.3, §6.4.1). Zie #114.
  • participationStatus (ADNDNS): waarde 60 uit de documentatie gehaald, gelijk aan het schema. Zie #103 en #71.
  • Chunking: de standaard kent geen maximum aantal chunks; limieten zijn afspraken tussen ketenpartijen (§2.7). Zie #127. chunkMeta.default heet in de documentatie chunking.default, gelijk aan de schema's.
  • Dekkingsgraad valt buiten de scope (§2.3). Zie #118.
  • Digitale ondertekening (x-jws-signature) en authenticatie met een API-sleutel (x-api-key) zijn mogelijkheden, geen verplichting; alleen OAuth 2.0 is verplicht, gelijk aan de OAS (§2.7, §7.4). De grenzen in de schema's zijn bindend (§2.7).
  • afdDefinitionName heeft in elk schema een vaste waarde, gelijk aan de bestandsnaam met 001.00; ook in het feedbackbericht (in de prerelease …-001.02-…) (§7.5.1.1). Zie #140. afdDefinitionVersion blijft 001.05 voor de tien berichten en 001.02 voor het feedbackbericht, dezelfde nummers als in de prerelease.

Per bericht

Bericht 1 Vermogen (0001a) heeft geen eigen wijzigingen buiten de regels hierboven (cohorten met waarde 0, reserves en voorzieningen).

Berichten 2, 3 en 4: SPR- en FPR-route

  • De prerelease legde voor bericht 2 twee wederzijds uitsluitende invulpatronen vast, met een uitsluitingsregel als verbandscontrole (§6.3.1). Zie #113. De uitsluiting tussen de cashflow direct onder de regeling en de cashflow per beleggingsportefeuille is vervallen; de uitsplitsingen per cohort en per beleggingsportefeuille blijven elkaar in de berichten 2 en 3 uitsluiten. De routes voor de berichten 2, 3 en 4 staan samen in de nieuwe §3.2.5, met Figuur 1a, 1b, 9a en 9b: in bericht 2 is de uitsplitsing optioneel, in bericht 3 precies één; in bericht 4 geldt de beleggingsportefeuille voor beide routes, zonder route-uitsluiting. De cashflow en de betalingen direct onder de regeling gelden in beide routes; in de FPR-route staat daar in de regel het totaal van de portefeuilles.
  • Verbandscontroles (§6.3.1): somcontroles bij een cohortuitsplitsing, en het begrip reconciliatie toegelicht. Een regeling in bericht 2 bevat minstens één cashflow (direct, per cohort of per beleggingsportefeuille). De technische borging via (..)-validationRules.json is nog niet gemodelleerd.

Bericht 2 Cashflow (0001b)

  • In elk cashflowblok zijn netAmount en netDate verplicht, de bedragen en datums van in- en uitstroom optioneel; het geld wisselt op de netDate (§6.3).
  • Het bericht draagt een verwachte of een vastgestelde netto kasstroom. Timing en frequentie zijn ketenafspraken; vast ligt wel dat een vastgestelde opgave volgt op de afwikkeling van de unitverkoop, omdat het bedrag daaruit ontstaat (§4.3.1, §4.3.2).
  • Eigen paragraaf in hoofdstuk 4, met de strekking, het FPR-invulpatroon en de verhouding tot de berichten 5, 10 en 14 (§4.3.2). In Tabel 12 is de BA ook verzender.

Bericht 3 Pensioenprojectie (0001c)

  • Een portefeuilletak voor de FPR-route, met een eigen paragraaf in hoofdstuk 4 (§4.3.3).
  • De betalingen onder het cohort en onder de beleggingsportefeuille zijn optioneel (0..*, O); een lege lijst financialTransaction hoeft niet meer mee (§6.4.4, §6.5).

Bericht 4 Rendementsinformatie (00002)

  • Totaalrendement en de uitsplitsing naar matching en return mogen in één bericht, onderscheiden via refKey (§3.2.4). Zie #109.
  • Eigen paragraaf in hoofdstuk 4, met de afbakening ten opzichte van bericht 13. Het gebruik hangt af van de inrichting: bij een unitized CVP is het niet nodig, bij een CVP in euro's wel, omdat bericht 13 daar geen unitwaarde heeft (§4.3.4).

Berichten 5 Orderopdracht (00541) en 6 Orderconfirmation (00542)

  • Switch-conventie: de code switch in buySellId is vervangen door switchfrom en switchto; de richting volgt uit buySellId, bedragen zijn altijd positief. switchType en financialInformationRef staan ook in bericht 6. Zie #115. switchType heeft de codes van AFDSWI (1, 2) in plaats van de labels sequential en one-day.
  • Bericht 5: per trade-instructie precies één van tradeAmount en tradeQuantity. Zie #116. Bij een switch draagt per switchpaar precies één leg het bedrag of het aantal, de andere leg geen van beide; in de praktijk draagt de switchfrom-leg het aantal units bij de overgang naar de collectieve uitkeringsfase. De verbandscontroles van de berichten 5 en 6 staan in de nieuwe §6.3.2.
  • Bericht 6: tradeQuantity, tradePrice, counterparty, broker, interestAmount, commissionAmount, clearingBroker en clearingBrokerCashAccount zijn optioneel; tradeAmount blijft verplicht. Zie #105. Komen tradeQuantity en tradePrice beide voor, dan geldt aantal × koers = bedrag (§6.3.2).
  • De orderopdracht gaat van de PUO naar de BA, de orderconfirmation terug van de BA naar de PUO. De aanbieder van het fonds, die de ordering in de onderliggende beleggingen uitvoert, is een andere rol dan de order verwerkende partij (§4.3.5, §4.3.6). In §6.4 is de aanduiding Direct order vervallen.

Bericht 10 Stuurinformatiebeleggingspools (00553)

  • De cohortPool-laag is verwijderd; de gegevens staan rechtstreeks op investment.pool (§6.4.8). Een formeel FPR-besluit is in de verslaglegging niet gevonden; de wijziging is doorgevoerd bij gebrek aan bekende bezwaren. Zie #124.
  • dummyCashId, tradeQuantity, unitPrice en currencyExchangeRate verwijderd uit investment.pool; buySellId, tradeValueAmount en currencyType blijven. Zie #133.
  • Toelichting op de strekking, met de vertaalslag van bericht 5 naar bericht 10: saldering per beleggingspool, omrekening van units naar bedragen en de behandeling van switches (§4.3.7). De toegestane waarden van buySellId zijn sell; buy.

Bericht 13 Waarde-informatie beleggingspool (00555b)

  • marketValueAmount verwijderd uit investment.pool; de netto vermogenswaarde loopt alleen via preliminaryUnitValueAmount. Veldbeschrijvingen samengevoegd. Zie #128. De omschrijving van participationValuationDate is bijgewerkt; het attribuut blijft verplicht.
  • Eigen toelichting: het bericht levert de koersinformatie op T-4 en de definitieve maandeinde-NAV op T+3, en is de basis voor reconciliatie en betaalinformatie (§4.3.8).

Bericht 14 Betaalinformatie (00556)

  • Per regeling meer betalingen in één bericht, minstens één en ten hoogste 999, in plaats van één bericht per betaling (§4.3.9, §6.4). Zie #149.
  • Verstuurd door de BA aan de FM; de PUO verstuurt het alleen als die zelf de rol van BA vervult, en staat in Tabel 12 niet meer als verzender. Toelichting op strekking en betekenis (§4.3.9).
  • collectionAccountIban heeft maximaal 34 tekens, de internationale IBAN-lengte volgens ISO 13616 (was 10) (§6.3). Zie #135.

Bericht 15 Corporate Actions (00557)

  • Nieuw bericht, met een procesuitleg voor het doorgeven van corporate actions vanuit de vermogensbeheerketen naar de PUO (§4.3.10). Zie #87. Het is een ad-hocbericht buiten de handelsrun en staat daarom niet in Figuur 8 en 9. Het hoort bij beleggingsfondsen die direct op een handelsplatform worden verhandeld; op beleggingspools zelf zijn corporate actions niet van toepassing. Verzender is de FM of de BA.
  • Codelijst AFDCOA (voorheen AFDCAE) voor corporateActionType: 1 Cash dividend, 2 Stock dividend, 3 Productverandering, 99 Anders. Een rebate valt onder 99 (in de prerelease: rebate); een eigen code is nog niet beschikbaar. Zie #137. Het bedrag van een rebate staat in cashDividendTotalAmount en/of cashDividendPerUnitAmount.
  • Bericht 15 is een uitzondering op de regel dat wijzigingen binnen een beleggingsproduct de PUO niet raken: dividend, rebate en unitmutaties moet de PUO wél verwerken (§4.2).
  • De lege financialInformation.reportingPeriod is uit het bericht gehaald.

Feedbackbericht

  • Een duplicaat messageId wordt afgewezen met HTTP 400 en een feedbackbericht in de response body (§4.4). Zie #129. Chunking is daarop de uitzondering.
  • party.sender en party.receiver in de beschrijving van commonTechnical. Zie #90.
  • Meer scenario's voor succesvolle en foutieve verwerking; errorCodeExplanation maximaal 1000 tekens (was 300). Zie #107.
  • Niet-uitvoerbare orders worden teruggekoppeld met het feedbackbericht (status Afgewezen, foutcode, omschrijving); overmacht valt onder bilaterale afspraken (§4.4). Zie #132.
  • originalMessageType kent ook 00542. Zie #126. De keuzelijst volgt de tien actieve berichten: 00557 erbij, de vervallen berichten eruit; ook in de afbeelding in §4.4.

Vervallen berichten 7, 8, 9, 11 en 12

  • Uit de actieve berichtenset gehaald; de nummering van de overige berichten is ongewijzigd. Zie #99, #119, #121. Zij staan in één blok achteraan in hoofdstuk 4, met per bericht de reden (§4.3.11), en niet meer in §6.4.

Opbouw van de handleiding

  • Hoofdstuk 4 is opnieuw ingedeeld: het gebruik van SPR-berichten binnen FPR staat aan het slot van de inleiding (§4.1); de procesflow heeft een eigen paragraaf (§4.3.1); elk actief bericht heeft een paragraaf, nu ook de berichten 2, 3 en 4 (§4.3.2 tot en met §4.3.10); de vervallen berichten staan in §4.3.11; het feedbackbericht is §4.4. In §6.4 zijn de berichtstructuren doorgenummerd: bericht 10 is §6.4.8 tot en met het feedbackbericht §6.4.12.
  • De tabellen met de basisberichtstructuur en de maximumaantallen in §6.4.1 worden uit het model gegenereerd. Zij tonen de hiërarchie per plaats: een entiteit die op meer plaatsen voorkomt, staat er meer keer, elk onder haar eigen ouder. Bij financialTransaction.payment staan de drie maxima (999, 9999 of 99999) met de plaats waar ze gelden. §6.4 licht de achtervoegsels (zoals _1) in de berichtdiagrammen op GitHub toe.
  • §6.5 Kruisreferentie: leesbare koppen, een filter op bericht en één blok per entiteit en ouder.
  • De voorbeeldberichten staan in een eigen map Voorbeeldberichten per release op GitHub, niet meer in de berichtmappen; main is daar leidend. Voor release 2027 zijn ze aangevuld voor alle berichten, naar situaties uit de praktijk met bestaande pensioenuitvoerders en fictieve data (§7.5).
  • Figuur 3 (§4.2) toont leeftijden in plaats van geboortejaren.
  • Verwijzingen: interne verwijzingen die nergens uitkwamen hersteld, met een toets die dat voortaan bewaakt; GitHub-verwijzingen wijzen naar de repository van Stichting SIVI; verwijzingen naar GitHub-issues bij de tekst; schrijfwijze van technische namen gelijkgetrokken.
  • De colofon vat de wijzigingen samen; deze paragraaf is nieuw.
  • Enkele tekstuele verbeteringen.