SIVI AFS voor Intermediaire Distributie

ADN-boekingsberichten

Wat is het?

Ketenintegratie begon in 1985 met het ADN (Assurantie Data Netwerk) met als doel een minder bewerkelijk en kwalitatief beter incassoproces voor adviseurs. Initieel alleen ingezet door verzekeraars en sinds ongeveer 20 jaar ook door serviceproviders. Op dit moment spreken we van het ADN Protocol en kunnen ADN-berichten op verschillende manieren worden uitgewisseld.

Op dit moment zijn alleen de ADN-boekingsberichten nog in gebruik. Het meest gebruikte bericht is het prolongatiebericht (PPR) dat door aanbieders wordt verstuurd in de frequentie van de betaaltermijnen. Voorafgaand aan de hoofdvervaldatum bevat dit bericht eventueel nieuw geïndexeerde gegevens als BM-trede of herbouwwaarde. PPR-berichten bevatten summiere polisgegevens. Daarnaast is er een mutatiebericht (PMB) waarin aanbieders gegevens versturen voor een nieuwe of gemuteerde polis. Naast boekingsgegevens kan het PMB-bericht meer polisgegevens bevatten.

Binnen de gangbare assurantiesoftware zijn processen ingericht om de verwerking van deze berichten te ondersteunen en de registratie van polissen waar nodig te actualiseren. De ADN-boekingsberichten zijn essentieel voor adviseurs die zelf incasseren. Het bespaart hen het afletteren van borderellen en voorkomt fouten. Een deel van de adviseurs die maatschappij-incasso hanteren gebruikt de berichten om de eigen administratie te actualiseren en eventueel controles uit te voeren.

Gebruik in de markt

Inmiddels gebruiken zowel verzekeraars als serviceproviders de ADN-boekingsberichten. Vooral in het serviceprovidersegment zien we de laatste jaren nog groei omdat het een goed en betrouwbaar middel is om de administratie van een aangesloten adviseur te actualiseren.

Exacte data is op dit moment niet voorhanden. De schatting is dat tussen de 100 en 150 aanbieders jaarlijks rond de 200 miljoen ADN-boekingsberichten versturen naar rond de 3.000 adviseurs en de serviceproviders met postenbanken. Niet voor al deze polissen vindt tp-incasso plaats, ook waar sprake is van maatschappij-incasso worden ADN-boekingsberichten gebruikt om polisinformatie door te geven.

ADN-boekingsberichten kunnen worden afgehandeld via Solera (TIME) of via Aplaza. Zo’n 17 leveranciers van assurantiesoftware ondersteunen de verwerking van de ADN-boekingsberichten.

Baten

Bij de start leverden de ADN-boekingsberichten verzekeraars grote besparingen aan portokosten op. Rond 2005 werd dit aanzienlijk minder belangrijk omdat borderellen digitaal (PDF) konden worden verspreid via GRS-documentberichten, via mail of via extranet. Twee andere baten zijn voor aanbieders nog steeds zeer actueel. Ten eerste de kwaliteit van het incassoproces door het aanleveren van automatisch te verwerken gegevens. Ten tweede het geautomatiseerd actualiseren van de administratie van de adviseur, wat duidelijk meetelt in de waardering van adviseurs voor de dienstverlening van aanbieders.

Voor adviseurs levert de geautomatiseerde verwerking van boekingen en de bijgevoegde polisgegevens een substantiële besparing op. De adviseurs die zelf premies incasseren hebben minder uitval/fouten in het incassoproces. Zowel de adviseurs die incasseren als de adviseurs die niet incasseren, hebben minder arbeid om de eigen registratie te actualiseren en zijn beter in staat vanuit de eigen systemen hun klant te bedienen. Voorwaarde voor de efficiencywinst voor adviseurs is de aanlevering van foutloze berichten. Dit is op onderdelen een punt van aandacht.

GRS-documentberichten

Wat is het?

De GRS-Documentberichten worden met name gebruikt om de bij het prolongatieproces behorende documenten digitaal te verzenden vanuit verzekeraars en serviceproviders (aanbieders) naar intermediairs en serviceproviders met postenbanken (ontvangers). Voor de eindklant kunnen dit een polis, een begeleidende brief van de aanbieder, een groene kaart  of een factuurspecificatie zijn. Voor de adviseur kunnen dit (aanvullend) een boekingsnota en een borderel zijn.

Een beperkt aantal aanbieders gebruikt de GRS-documentberichten ook voor het versturen van offertes.

De GRS-documentberichten waren in 2004 onderdeel van het GRS (GIM Resultaten Service) Protocol. Op dit moment worden ze los van elkaar beschouwd.

Het GRS-documentbericht bevat één of meer digitale documenten (veelal PDF-formaat) en, afhankelijk van de situatie, aanvullend een aantal identificerende gegevens zoals POR-code aanbieder, polisnummer, naam van verzekeringnemer, offertenummer, etc. Met deze identificerende gegevens kan de assurantiesoftware van de ontvanger de in het bericht bijgevoegde digitale documenten koppelen aan een te nemen actie binnen een workflow of inboeken in een klantdossier en koppelen aan een offerte, polis of claim.

Gebruik in de markt

In 2023 werden ruim 18 miljoen GRS-documentberichten uitgewisseld. De laatste jaren zien we weer een duidelijke groei (in 2019 waren het 9 miljoen berichten). De bulk van het volume bestaat uit documenten die nodig zijn bij de prolongatie van polissen per hoofdvervaldatum.

In een beperkt aantal gevallen wisselen aanbieders en ontvangers direct GRS-documentberichten op basis van het GRS Protocol (naar schatting 1 miljoen berichten). Voor de overige 17 miljoen berichten faciliteert Aplaza de uitwisseling voor 65 aanbieders en ruim 1.500 ontvangers bij 17 leveranciers van assurantiesoftware.

Baten

Ook hier geldt dat bij de start verzekeraars grote besparingen aan portokosten behaalden. Inmiddels kunnen documenten ook makkelijk digitaal (PDF) worden verspreid via mail of extranet. De belangrijkste meerwaarde om documenten via GRS-documentberichten te versturen is dat de adviseur de documenten verregaand geautomatiseerd kan verwerken binnen zijn administratie, wat duidelijk meetelt in de waardering van de dienstverlening van aanbieders.

Voor adviseurs levert de geautomatiseerde verwerking van GRS-documentberichten een substantiële besparing. De adviseurs die incasseren zijn in staat grotendeels geautomatiseerd de verzending van facturen en onderliggende stukken uit te voeren. Zowel de adviseurs die incasseren als de adviseurs die niet incasseren hebben minder arbeid om de eigen registratie te actualiseren, kunnen waar nodig automatisch workflows activeren voor de opvolging en zijn beter in staat vanuit de eigen systemen hun klant te bedienen. Ook hier is de aanlevering van foutloze en goed verwerkbare berichten een voorwaarde. Dit is op onderdelen een punt van aandacht.

SKP-transactieberichten

Wat is het?

De adviseur gebruikt bij zijn dagelijkse werkzaamheden een reeks van toepassingen. Toepassingen ter ondersteuning van een proces (advies, vergelijking, schademelding) en toepassingen gericht op het uitvoeren van specifieke transacties (offerte, aanvraag, mutatie). Deze toepassingen worden aangeboden door leveranciers, serviceproviders, verzekeraars en derden in de keten (bijv. schadeherstellers). De diversiteit op het bureau van de adviseur is groot. De insteek is dat als de adviseur digitaal een transactie in gang zet hij – als bevestiging van die transactie – een bericht retour krijgt met data en/of document met de specificaties van de transactie.

De doelstelling van SIVI is dat het overnemen van data en het inboeken van stukken – bij het gebruik van toepassingen naast elkaar – geautomatiseerd moeten plaatsvinden. De adviseur bereikt hiermee tijdsbesparing, minder fouten en is beter in staat een centraal klantdossier te beheren. De aanbieders van SKP-koppelingen (leveranciers, serviceproviders, verzekeraars en derden in de keten) voorzien in een meer efficiënte keten en dragen bij aan een goede zorg voor de klant.

Het SIVI Koppelingsprotocol (SKP) is geïntroduceerd in 2018 en richt zich op alle in gebruik zijnde software en omgevingen. SKP is de doorontwikkeling van het GIM Protocol (2006). Het protocol kent drie niveaus:

1. SKP-BASIS: koppeling vanuit bijvoorbeeld een extranet met alleen een PDF-document retour naar bijvoorbeeld de assurantiesoftware.
2. SKP-UITGEBREID: koppeling vanuit bijvoorbeeld een extranet met data (en optioneel PDF-document) retour naar bijvoorbeeld de assurantiesoftware. Ook bekend als ‘Start extranet’.
3. SKP-COMPLEET: koppeling vanuit bijvoorbeeld de assurantiesoftware naar bijvoorbeeld een extranet waarbij initiële data vanuit de assurantiesoftware wordt doorgegeven aan het extranet en waarbij data (en optioneel een PDF-document) retour gaat naar de assurantiesoftware. Ook bekend als GIM.

Gebruik in de markt

Hoewel na de introductie van GIM (de voorloper van SKP) in 2006 het aantal beschikbare koppelingen snel groeide, trad vanaf 2009 een duidelijke stagnatie en daarna een daling op. De complexiteit van de GIM-koppeling op dat moment in de tijd en beperkte prioritering van marktpartijen waren de belangrijkste redenen.

In 2018 is de opvolger SKP geïntroduceerd met als inzet dat het voorzien in SKP-BASIS een hygiënefactor moet zijn. Handmatig inboeken van stukken moet tot het verleden behoren. In ruim 1,5 jaar is met ruim 70 partijen gesproken. In nagenoeg alle gesprekken hebben partijen aangegeven dat het gebruik van SKP-BASIS een winst is voor de keten en technisch niet complex. Toch zijn uiteindelijk maar een beperkt aantal partijen overgegaan tot de implementatie van SKP-BASIS. Twee argumenten waren hier leidend: (financiële) drempels om over te gaan tot het versturen van berichten en gestelde prioriteiten. Op dit moment stuurt SIVI niet actief op het gebruik van SKP-BASIS. Dit zien we als ongewenst en we gaan ons daarom beraden op nadere acties, omdat de markt hier een groot efficiencypotentieel laat liggen.

De SKP-UITGEBREID en SKP-COMPLEET koppelingen worden op dit moment alleen gefaciliteerd door Aplaza. Na een terugval tot zo’n 150.000 SKP-transactieberichten in 2022 is er inmiddels weer meer belangstelling voor het gebruik van deze koppelingen. Op dit moment bieden 5 aanbieders deze koppelingen aan en genereren bijna 1.300 adviseurs ruim 320.000 berichten per jaar.

Baten

De adviseur gebruikt, afhankelijk van zijn specialisatie(s), een reeks aan softwareomgevingen. Lokaal geïnstalleerd of online. In eigen beheer of via verzekeraar, serviceproviders of derde dienstverleners. Tenzij de adviseur gebruik maakt van een serviceprovider die in alles voorziet, betekent dit dat er vele momenten zijn in de verschillende processen dat gegevens of documenten moeten worden overgenomen van de ene omgeving naar de andere. Hoewel dit elke keer maar enkele minuten is, telt dit voor een heel kantoor (zeker bij meer omvangrijke portefeuilles) snel op. Daarnaast is er het risico het handmatig overnemen uit te stellen en daarmee te vergeten, of fouten te maken bij het overnemen van gegevens of het inboeken van documenten. Met oog op een ordentelijk klantdossier i.v.m. zorgplicht is dit ongewenst. Het gebruik van SKP in één van de drie gradaties zorgt voor substantiële besparingen in een kantoor. Zowel de verticale ketenoptimalisatie als de horizontale ketenoptimalisatie werpen dan echt hun vruchten af.

Services

Wat is het?

Bij services gaat het om Machine – Machine interacties waarbij een toepassing van de verzender (Machine) via internet een bericht voor een specifieke functie stuurt naar de toepassing van de ontvanger (Machine). Als dit bijvoorbeeld de functie premieberekening is, dan berekent de ontvanger de premie op basis van de gegevens in het ontvangen bericht en stuurt direct een bericht met de berekende premie terug. Organisaties bieden services aan via een API (Application Programming Interface), dit is een generieke standaard voor de het aanbieden van services.

Naast dat we het gebruik van services zien voor de primaire processen als tariefberekening, vergelijking, offerte, aanvraag, mutatie/beheer en claim zien we services voor de ondersteuning van deze processen. Bijvoorbeeld het raadplegen van voertuigdata, opstaldata, schadeafhandeling, etc.

Als standaard voor het aanbieden van services heeft SIVI voor AFD 1.0 in 2004 het AFD Webservice Protocol ontwikkeld dat uitgaat van SOAP/XML. In 2020 heeft SIVI het SIVI AFS API-raamwerk gepubliceerd dat uitgaat van AFD 2.0 en REST/JSON.

Gebruik in de markt

Binnen de Volmacht Distributie zijn collectieve afspraken gemaakt voor o.a. services voor premieberekening. Het resultaat is een zeer ruim aanbod van deze services en toepassingen die hier goed mee kunnen omgaan, wat resulteert in meer dan 60.000.000 transacties per jaar. Inmiddels zien we dat voor provinciale producten beperkt op dezelfde wijze tarieven worden aangeboden. Echter we zien binnen de Intermediaire Distributie géén collectieve afspraken rond het gebruik van services voor provinciale polissen en daarmee dus ook geen georganiseerd gebruik. Het komen tot een collectieve agenda rond services voor provinciale polissen is een hoge prioriteit binnen de Roadmap Intermediaire Distributie. Mede daarom neemt SIVI het initiatief om een kopgroep te formeren die de uitgangspunt gaat formuleren voor een service ‘Raadpleeg Polis’.

Dit betekent overigens niet dat er geen services worden aangeboden. Individuele partijen bieden voor hun producten of diensten services aan op basis van AFD 1.0 en SOAP/XML (AFD Webservice Protocol) of op basis van AFD 2.0 en REST/JSON (SIVI AFS API-raamwerk). Daarnaast kiezen partijen ervoor om eigen uitgangspunten te hanteren bij het inrichten van services. In alle gevallen betekent dit dat partijen bilateraal afspraken maken en vaak intensieve afstemming hebben rond het gebruik.

Op basis van o.a. de wijzigingsverzoeken voor AFD 1.0 zien we als SIVI dat partijen services inrichten/beheren, maar we hebben geen zicht op het aantal in de markt aangeboden services. Voor het nieuwe AFD 2.0 en het API-raamwerk hebben we dat inzicht beter. Van bij SIVI bekende projecten (mei 2024) hebben 16 projecten betrekking op services rond provinciale verzekeringen bij aanbieders.

Baten

Voor organisaties die digitaal willen of moeten samenwerken met andere organisaties vervullen API’s de sleutelrol in o.a. het aanbieden van functies, het toegang bieden tot data, het distribueren van content of het ontsluiten van een workflow. API’s zijn randvoorwaardelijk voor digitaal zakendoen.

Elke API of daarbinnen elke functie (service) heeft zijn eigen specifieke business case. Bij collectieve afspraken zijn er ook voordelen voor de keten. Bijvoorbeeld bij premieberekening voor volmachten kunnen verzekeraars met zicht op kwaliteit sneller en grootschaliger producten uitrollen, volmachten kunnen bij de ontwikkeling en gebruik van software op een zeer uniforme wijze tarieven van veel producten en verzekeraars raadplegen.

Het gebruik van de SIVI-standaarden AFD Webservice Protocol (AFD 1.0) en SIVI AFS API-raamwerk (AFD 2.0):

• Biedt een verzameling functies/services waarvoor afspraken zijn gemaakt met het oog op eenduidige werking.
• Borgt aanvullend eventuele procesafspraken rond het gebruik van deze functies.
• Stelt eventueel normen voor beveiliging, authenticatie, performance en beschikbaarheid.
• Maakt co-creatie mogelijk waarbij derden (alleen of een groep) toepassingen kunnen ontwikkelen in het verlengde van aangeboden webservices.