Wat SIVI AFS en AFD betekenen voor je verzekeringssoftware.

Wat is SIVI AFS precies?

Wie voor het eerst software bouwt voor een assurantiekantoor, een volmachtbedrijf of een verzekeraar, loopt binnen een week tegen een muur van afkortingen aan: AFD, ADN, GRS, SKP, NVGA, UIV. Ze komen allemaal uit hetzelfde huis — SIVI, het standaardisatie-instituut van de branche.

Dat is even wennen, maar het is goed nieuws. In veel sectoren moet je per ketenpartner opnieuw onderhandelen over veldnamen en formaten. In verzekeren is dat werk al gedaan. Er ligt één catalogus van entiteiten, attributen en codelijsten, en daaromheen een set protocollen die vastleggen hoe je berichten verstuurt. Je hoeft die standaard niet mooi te vinden om er baat bij te hebben.

De vergelijking die het snelst duidelijk maakt wat SIVI is: het is voor verzekeren wat EDI en GS1 zijn voor de groothandel. Een gedeelde taal die je niet zelf verzint, opgelegd door de partij aan de andere kant van de lijn.

AFD: de gegevensstandaard onder alles

AFD staat voor All Finance Datacatalogus. Het beschrijft hoe gegevens moeten worden uitgewisseld of vastgelegd en is voortgekomen uit het ADN-berichtenverkeer van eind jaren tachtig. In ruim vijfendertig jaar is de catalogus uitgegroeid van pure schadeverzekering naar pensioen, hypotheken en andere financiële domeinen.

De opbouw is hiërarchisch en verrassend leesbaar zodra je hem doorhebt:

• Entiteiten: objecten uit de echte wereld — de verzekeringnemer, het object, de dekking, de polis.
• Attributen: de eigenschappen van zo'n entiteit, zoals achternaam, ingangsdatum of verzekerd bedrag.
• Formaatindicatoren: het datatype en de lengte van een attribuut.
• Codelijsten: de toegestane waarden, zodat "bromfiets" bij elke partij hetzelfde nummer krijgt.

AFD 1.0 en AFD 2.0 leven naast elkaar

Hier zit de eerste echte beslissing. AFD 1.0 heeft zijn fundament in het midden van de jaren negentig, gebruikt XML en heeft een platte structuur waarin entiteit en attribuut samen in één label zitten. AFD 2.0 is in 2020 geïntroduceerd: JSON in plaats van XML, ongeveer dertig basisentiteiten, semantische groepering via entityTypes en ruimte voor nieuwere domeinen zoals hypotheken en energiecontracten.

SIVI heeft AFD 1.0 niet uitgezet. Beide versies bestaan naast elkaar en er zijn mappings om van de ene naar de andere te vertalen. Dat is geen tijdelijke overgangssituatie van een paar maanden — dit duurt al jaren en gaat nog jaren duren. Reken er dus op dat je in één kantoor allebei tegenkomt.

Een sectorstandaard verdwijnt nooit in één keer. Hij stapelt. Wie dat vooraf inplant, bouwt goedkoper dan wie op de grote overstap wacht.

De protocollen: waar de standaard concreet wordt

AFD zegt wat er in een bericht staat. De protocollen zeggen hoe je dat bericht verstuurt en wanneer. SIVI AFS kent er inmiddels negen. Deze kom je in de praktijk het vaakst tegen:

• ADN-protocol: boekingsberichten voor prolongatie en mutatie. Dit is de ruggengraat van de incasso bij adviseurs die zelf incasseren.
• GRS-protocol: digitale documenten — polissen, voorwaarden, nota's — van aanbieder naar intermediair, met identificerende gegevens erbij zodat het document automatisch in het juiste dossier landt.
• SKP (SIVI Koppelingsprotocol): asynchrone uitwisseling van transactiedata en documenten tussen adviseur en ketenpartner.
• AFD-webserviceprotocol: services aanbieden op basis van SOAP en XML, gekoppeld aan AFD 1.0.
• SIVI AFS API-raamwerk: de moderne tegenhanger, gebaseerd op AFD 2.0 en REST/JSON.
• NVGA-protocol: welke gegevens een gevolmachtigd agent aan de verzekeraar moet aanleveren.

Het patroon is duidelijk: de oudere stromen zijn batchgericht en documentachtig, de nieuwere zijn realtime en servicegericht. Een moderne polisadministratie moet allebei aankunnen — een nachtelijke ADN-verwerking naast een synchrone premieberekening die binnen een seconde antwoord moet geven.

Het volume is geen randverschijnsel

Voor wie denkt dat dit om een handjevol berichten gaat: SIVI meldt dat er in 2023 ruim 18 miljoen GRS-documentberichten zijn uitgewisseld, een verdubbeling ten opzichte van 9 miljoen in 2019. Meer dan 1.500 intermediairs ontvangen die documenten via zeventien softwareleveranciers. De SKP-transactieberichten zitten op ongeveer 320.000 per jaar, afkomstig van bijna 1.300 adviseurs.

Dat zijn getallen die je architectuur raken. Documentstromen van deze omvang wil je niet synchroon in een webrequest verwerken, en je wilt ze zeker niet twee keer verwerken als een aanlevering opnieuw binnenkomt. Idempotente verwerking is hier geen luxe maar de basis.

Volmacht loopt voor, provinciaal loopt achter

De verzekeringsketen kent twee werelden die technisch mijlenver uit elkaar liggen, en dat verschil bepaalt vaak wat je wel en niet kunt bouwen.

In de volmachtdistributie beheert een gevolmachtigd agent de portefeuille namens de verzekeraar. Daar zijn collectieve serviceafspraken gemaakt, en dat werkt: SIVI spreekt over meer dan 60 miljoen transacties per jaar via services als premieberekening en acceptatie. Wie daar bouwt, sluit aan op iets wat draait.

In de provinciale distributie — de adviseur die rechtstreeks bij de verzekeraar bemiddelt — ontbreken generieke services voor polisinformatie juist. Adviessoftware, vergelijkers en sluitsystemen zijn daar volgens SIVI slecht of niet op aangesloten. Het gevolg is precies wat je verwacht: overtypen, dubbele vastlegging en een adviseur die in het verzekeraarsportaal moet inloggen om te zien wat er in zijn eigen portefeuille zit.

SIVI werkt daaraan met de Kopgroep Raadpleeg Polis, een sectorbreed initiatief om actuele polisinformatie via uniforme API's op te vragen. Volgens de plannen komen de eerste services in 2026 beschikbaar. Bouw je nu iets voor een assurantiekantoor, houd er dan rekening mee dat dit stuk keten binnen afzienbare tijd verandert — en zet je polisophaling achter een eigen interface, zodat je die later kunt omzetten zonder je hele applicatie te raken.

Wat dit vraagt van je eigen software

De grootste fout die ik in verzekeringsprojecten zie, is dat het interne datamodel een kopie wordt van AFD. Dat lijkt logisch — de standaard is er tenslotte al — maar het levert een applicatie op die elke keer breekt als de catalogus of een codelijst wijzigt, en die vol zit met velden waar jouw proces niets mee doet.

1. Modelleer je eigen domein eerst: beschrijf wat jouw gebruiker doet — offreren, muteren, schade melden — en wat daarvoor nodig is. Dat model is van jou en verandert alleen als je proces verandert.
2. Zet AFD als vertaallaag aan de rand: één adapter die inkomende berichten omzet naar jouw model en uitgaande berichten naar AFD 1.0 of 2.0. Een versiewissel raakt dan één laag, niet je hele applicatie.
3. Behandel codelijsten als data, niet als code: zodra een branchecode of dekkingsvorm in een enum of een match-statement staat, is elke wijziging een release. Laad ze uit een tabel die je zonder deploy kunt bijwerken.
4. Bewaar het originele bericht: sla het ruwe binnenkomende bericht op naast je verwerkte versie. Bij elk verschil van mening met een ketenpartner is dat je enige bewijs — en het maakt herverwerken na een bugfix mogelijk zonder heraanlevering te vragen.
5. Bouw op idempotentie en herverwerking: aanleveringen komen dubbel binnen, batches worden opnieuw gedraaid. Een boeking die twee keer wordt verwerkt, is in een incassostroom een probleem dat je pas bij de rekening-courant ontdekt.

Waar de tijd echt in gaat zitten

Niet in het protocol. SOAP of REST is een dag werk, de authenticatie een tweede. De tijd gaat op aan de invulling: welke velden verwacht déze verzekeraar precies, welke codelijstversie hanteert die serviceprovider, wat betekent een leeg optioneel veld in de ene stroom versus de andere.

SIVI probeert daar iets aan te doen. In december 2025 kondigde het instituut aan dat zijn AOS-software (AFD Online Samenstellen) is uitgebreid, zodat services voortaan ook volgens de OpenAPI-specificatie gedocumenteerd kunnen worden. Daarmee komen de functionele beschrijving van een service en de technische API-afspraak op één plek te liggen. Dat scheelt: een OpenAPI-document kun je inlezen, valideren en gebruiken om clientcode te genereren, waar een functioneel document in een PDF alleen leesbaar is voor mensen.

Mijn kijk op bouwen tegen SIVI AFS

Ik heb voor genoeg branches gebouwd waar iedere ketenpartner zijn eigen formaat verzint. Vergeleken daarmee is verzekeren comfortabel: er ís een catalogus, er zíjn protocollen, en je hoeft niet met vijf partijen apart te onderhandelen over wat een ingangsdatum is. Dat de standaard oud aanvoelt, is een prijs die ik graag betaal voor die duidelijkheid.

Waar ik wel op let: een sectorstandaard verleidt tot passiviteit. "Het staat in AFD, dus we nemen het over." Dan bouw je een systeem dat de standaard reproduceert in plaats van een systeem dat het werk van een assurantiekantoor makkelijker maakt. De kantoren waar maatwerk echt verschil maakt, zijn juist de kantoren die iets eigens doen — een specialisme, een doelgroep, een werkwijze die de bestaande backofficepakketten niet ondersteunen. Die eigenheid moet in jouw model zitten, niet in dat van SIVI.

En let op de gaten. De volmachtkant is technisch volwassen, de provinciale kant nog niet. Beloof een klant dus geen realtime polisoverzicht over de volle breedte als de services daarvoor deels nog moeten landen. Wees eerlijk over wat vandaag kan, en bouw zo dat je het morgen kunt aanzetten.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen maatwerksoftware voor assurantiekantoren en volmachtbedrijven: portalen, dossier- en mutatieprocessen en de koppelingen naar backofficepakketten als ANVA en ASSU. Daarbij houden we de sectorstandaard waar hij hoort — aan de rand, als vertaallaag — en het domeinmodel van jouw kantoor in het midden.

Twijfel je of een bestaand pakket te koppelen is, of wat een eigen laag erbovenop realistisch oplevert? Lees dan ook stapsgewijs een API-koppeling bouwen en soorten API's. Neem contact op voor een vrijblijvend gesprek.