Roadmap SIVI AFS

Stip op de horizon: digitaal ecosysteem

Binnen de financiële dienstverlening is de inzet van data en software randvoorwaardelijk voor de vormgeving van bedrijfsactiviteiten. Dit geldt voor processen binnen de keten, zoals het verwerken van een aanvraag, maar ook voor de ontwikkeling van klantbediening, zoals een vergelijker. De stip op de horizon voor SIVI is een dynamisch en flexibel ecosysteem rond digitaal zakendoen.

Dit digitale ecosysteem kenmerkt zich door:

1. gedeelde uitgangspunten die als fundament dienen;
2. mogelijkheden voor ketenpartijen om klanten optimaal te ondersteunen;
3. ondersteuning van diverse distributiemodellen;
4. het gebruik van open standaarden, wat leidt tot:
   • lagere kosten voor interoperabiliteit;
   • maximale benutting van marktkansen;
   • ruimte voor individuele verschillen.
5. een gezamenlijke governance voor functionaliteit en, waar nodig, kostenontwikkeling;
6. afstemming over transport, opslag en verwerking van gegevens, waar relevant;
7. gegarandeerde kwaliteit van authenticatie en beveiliging.

 

Digitaal ecosysteem financiële dienstverlening Onder het ecosysteem voor de financiële dienstverlening verstaat SIVI de werking van en de samenwerking tussen partijen betrokken bij de invulling van financiële dienstverlening. Dit zijn de primaire ketenpartijen zoals verzekeraars en adviseurs, maar ook alle partijen die hier een ondersteunende rol vervullen, van schadeherstellers tot leveranciers van software en services. Onder het digitale ecosysteem verstaat SIVI de digitale werking van individuele partijen en digitale samenwerking tussen partijen binnen dit ecosysteem. De digitale werking en de digitale samenwerking vormen de primaire focus van SIVI. In functie hiervan kijkt SIVI naar de inrichting van processen. SIVI streeft naar een uniform digitaal ecosysteem. Dit is echter niet noodzakelijk een homogeen ecosysteem. Variatie in invulling kan met name ontstaan afhankelijk van de signatuur/positionering van ketenpartijen, zoals een klein intermediair, een serviceprovider of een grote regionale volmacht. De SIVI-agenda dient dus niet één specifieke oplossingsrichting. SIVI streeft naar voorwaarden binnen de sector die ervoor zorgen dat de verschillende distributiemodellen en verschillende soorten spelers binnen één digitaal ecosysteem tot hun recht kunnen komen.

SIVI AFS

SIVI AFS is de standaard voor digitale uitwisseling en vastlegging van gegevens binnen de financiële dienstverlening. Belangrijkste bouwstenen binnen SIVI AFS zijn afspraken over gegevens (semantiek, typering, waardebeperkingen), over structuren (ordening van entiteiten en attributen) en over de ondersteuning van branchespecifieke functies (bijv. een aanvraag of een premieberekening). Voor technische ICT-standaarden als een syntax-standaard (JSON) of een webservice-standaard (REST) volgt SIVI de gangbare marktstandaarden.

SIVI AFS is de benaming voor alle SIVI-standaarden, en bestaat op hoofdlijnen uit drie onderdelen:

• AFD: structuren en gegevenselementen
• AFD-definitie Standaard: specificaties van een correct AFD-bericht
• SIVI AFS API-raamwerk: specificaties van functies

Collectieve afspraken: protocollen

Met SIVI AFS kunnen partijen op individuele basis bijvoorbeeld services maken voor premieberekeningen, aanvragen van inkomensverzekeringen of afhandelingen van reisschades. Ook kan men op basis van SIVI AFS zelf databases of een datawarehouse inrichten. Aan de andere kant kennen we collectieve afspraken rond het gebruik van standaarden: dit noemen we protocollen. Een protocol is een set afspraken over het gebruik van één standaard of een combinatie van standaarden voor een specifiek doel. Op basis van SIVI AFS zijn op dit moment negen protocollen ontwikkeld:

• ADN Protocol: stelt afspraken vast voor het opstellen en verwerken van boekingsberichten, waarmee adviseurs hun incassoproces vereenvoudigen en administratie bijwerken
• Protocol Rekening-courantberichten: stelt aanbieders in staat om mutaties in de rekening-courantverhouding met agenten elektronisch te verzenden, met gegevens over saldo’s en boekingen
• GRS Protocol: stelt aanbieders in staat om via GRS-documentberichten digitale documenten zoals polissen, voorwaarden en facturen naar intermediairs en serviceproviders te verzenden, met identificerende gegevens voor koppeling in assurantiesoftware
• AFD-webservice Protocol: voor het aanbieden van services op basis van SOAP/XML
• SIVI Koppelingsprotocol (SKP-transactieberichten): voor efficiënte en geautomatiseerde uitwisseling van transactiedata en documenten tussen adviseurs en ketenpartijen
• Protocol AFD-definities UIV: voor de uniforme inrichting van volmachtportefeuilles, waarin verzekeraars gestandaardiseerde product-specificaties leveren en volmachten hun assurantiesoftware hierop afstemmen
• Protocol AFD-definities Registratie Polis: voor het leveren van correcte polisgegevens in digitale berichten, zodat softwareleveranciers polisgegevens juist kunnen verwerken en deze zonder fouten op polisschermen verschijnen
• NVGA Protocol: legt vast welke gegevens volmachten moeten aanleveren aan verzekeraars
• VBPUO Protocol: voor gegevensuitwisseling tussen pensioenuitvoeringsorganisaties, fiduciair managers en beleggingsadministrateurs

Het perspectief van de soort gebruiker van SIVI AFS

Binnen de Roadmap SIVI AFS ligt het perspectief vooral bij de gebruiker van de standaarden. Hierbij onderscheiden we drie groepen:

1. Softwareproducenten, te onderscheiden in twee subgroepen:
   1. Leveranciers van software & services. Zij bieden diensten zoals assurantiesoftware, adviessoftware, data-diensten, enzovoort.
   2. Software-ontwikkelteams bij verzekeraars, gevolmachtigd agenten, serviceproviders, adviseurs en derde partijen. Deze ketenpartijen ontwikkelen zelf software voor de ondersteuning van hun (deel)processen.
2. Functioneel beheerders, die in aanraking komen met SIVI AFS omdat zij hun software moeten configureren om met de SIVI AFS-standaarden of -protocollen te werken.
3. Gebruikers, die in aanraking komen met SIVI AFS omdat hun software de SIVI AFS-standaarden en -protocollen gebruikt.

Al deze drie gebruikersgroepen kennen vanuit hun rol in meer of mindere mate de SIVI AFS-standaarden en SIVI AFS-protocollen. Met deze gebruikersgroepen heeft SIVI verschillende vormen van interactie, waaronder:

• Creëren van nieuwe kansen
• Kennisoverdracht
• Problemen bij gebruik
• Uitbreidingsverzoeken

Algemene observaties

• Alle groepen hebben belang bij eenvoudige standaarden en minimale technische integratieproblemen.
• Verschillen in IT-maturiteit en gebruik (zelfbouw vs. standaardsoftware) zijn ketenbreed aanwezig en beïnvloeden de interactie met SIVI.
• Kwaliteitsverbeteringen zoals het Protocol AFD-definities Registratie Polis en de adoptie van OpenAPI-specificaties verminderen foutgevoeligheid en verhogen efficiëntie.

Perspectief softwareproducent
Alle softwareproducenten hebben behoefte aan goede aansluiting van de SIVI-standaarden bij de eigen ICT-architecturen en ontwikkelomgevingen. Voor softwareproducenten is het verder belangrijk dat SIVI heldere documentatie, trainingen en gebruiksvriendelijke tooling biedt om met de standaarden te werken. Ook moeten de SIVI-standaarden flexibiliteit bieden in ondersteuning bij de agile werkwijze van softwareproducenten anno nu.
We zien software-ontwikkelteams van alle in deze roadmap onderkende ketenpartijen (vanzelfsprekend met uitzondering van de eindklant) contact zoeken met SIVI. Dat varieert van uitbreidingsverzoeken voor het AFD tot intensieve begeleiding van SIVI bij implementatietrajecten.

Aandachtspunten voor de softwareproducent

• Softwareproducenten ontwikkelen het merendeel van de toepassingen voor berichtuitwisseling (en -opslag) in de keten. Bij hen ligt een belangrijke taak om deze toepassingen zo in te richten dat de kans op fouten geminimaliseerd wordt. Het correct gebruik van de SIVI-standaarden moet dan ook hoog op de agenda staan bij de ontwikkeling en het beheer van deze toepassingen.
• Sterker nog: tot op zekere hoogte hebben softwareproducenten ook een rol in het bevorderen van het gebruik van standaarden. Een softwareproducent kan zich prima naar klanten (bijv. een verzekeraar) uitlaten over het gewenst gebruik van (branche)standaarden, en het gebruik van proprietary standaarden voorkomen.

Perspectief functioneel beheerder
Functioneel beheerders configureren zowel ingaande als uitgaande berichten of services, en hebben daarom behoefte aan praktische richtlijnen en protocollen om fouten te voorkomen. Voor het inrichten van standaardsoftware hebben functioneel beheerders behoefte aan heldere documentatie, trainingen en gebruiksvriendelijke tooling.
Van alle ketenpartijen zoeken de functioneel beheerders (product owners) contact met SIVI. Vanuit leveranciers zijn dat vaak ook functioneel beheerders die namens een opdrachtgever (gebruiker van de software) werken. Het gaat daarbij bijvoorbeeld om ondersteuning bij implementatie of troubleshooting bij het opstellen van AFD-definities UIV.

Aandachtspunten voor de functioneel beheerder

• Functioneel beheerders (en product owners) zijn verantwoordelijk voor het opstellen van (AFD-)specificaties. Zij hebben daarom vanuit hun werk grote impact op fouten in de keten.
• Het is cruciaal dat functioneel beheerders de SIVI-standaarden en -protocollen goed volgen. Zelfs een correct geconfigureerd scherm binnen de assurantiesoftware garandeert nog geen foutloos AFD-bericht.
• Bij het opstellen van AFD-definities is het belangrijk dat functioneel beheerders zorgvuldig en consequent de SIVI-instructies volgen.

Perspectief gebruiker
Voor gebruikers van SIVI AFS is vooral inzicht in het proces rond het gebruik van een standaard of protocol belangrijk. Wat moet men doen, wat kan men verwachten en hoe moet men omgaan met fouten. Directe betrokkenheid is beperkt: vragen over het gebruik komen eigenlijk altijd eerst bij de softwareleveranciers of aanbieders terecht in de vorm van een foutmelding, en in tweede instantie pas bij SIVI.

Aandachtspunten voor de gebruiker

• Gebruikers doorlopen processen binnen hun software waarin de SIVI AFS-standaarden en -protocollen worden toegepast. Hoewel zij hinder ondervinden van fouten, hebben zij geen directe invloed op het voorkomen ervan. Wel kunnen zij bijdragen aan verbeteringen door consequent fouten te melden via de foutmeldprocedure (zie “Meldingen fouten berichtenverkeer” binnen het Domein Intermediaire Distributie).