AFD (All Finance Datacatalogus)

Actuele AFD-release

Op deze pagina het overzicht van alle downloads die horen bij de actuele AFD-release.
Zie de release notes en waar nodig de handboeken en betreffende web-pagina’s voor specifieke details.

SIVI publishes all documentation in Dutch. If you want to read it in another language, please use the translation module of your browser.

AFD 2.0

Alle documentatie voor AFD 2.0 publiceren we in een online handboek. Volg de verwijzing rechts op deze pagina voor het online handboek.

SIVI publishes all documentation in Dutch. If you want to read it in another language, please use the translation module of your browser.

Eenduidiger AFD

Met inmiddels ruim 35 jaar gebruik is het AFD toe aan groot onderhoud. Binnen SIVI werken we daarom aan verschillende verbetertrajecten, waaronder het opschonen van codelijsten, het uitfaseren van niet langer gebruikte attributen en het aanpakken van issues rond de eenduidigheid van het AFD.

Wat verstaan we onder ’Eenduidiger AFD’ ?

Het gebruik van AFD-gegevens beperkt zich allang niet meer tot alleen berichten, het gebruik is veel breder zoals business rules, berekeningen, workflow-besturing en registratie. Hierbij is het belangrijk dat:

• het AFD eenduidig is – bijvoorbeeld bij de AFD-codelijst Carrosserie (ADNUMR) de overlappende betekenis van Autobusje, Bestelauto en Bestelauto/VAN;
• het gebruik van het AFD goed wordt geduid – bijvoorbeeld wanneer men gebruik maakt van het attribuut ‘Verzekerde som’ en wanneer van het attribuut ‘Verzekerde loonsom’.

Deze vraagstukken vatten we onder de noemer Eenduidiger AFD.

Sinds ongeveer 1995 is het voor SIVI (en haar voorgangers) bij de ontwikkeling van het AFD het uitgangspunt om te ‘uniformeren’. Dat betekent dat we op een eenduidige manier data willen vastleggen dan wel uitwisselen. Voor een bericht over een polis gaan we allemaal uit van dezelfde structuur, en als we brandstof opnemen in een bericht gebruiken we allemaal dezelfde coderingen. De keuze ten aanzien van welke gegevens we opnemen in een bericht is in principe voor iedereen vrij. Een belangrijk uitgangspunt van SIVI is dat partijen binnen het AFD de ruimte moeten hebben om hun producten zodanig in te richten dat zij zich daarmee kunnen onderscheiden. Standaardisatie gaat niet zo ver dat marktpartijen verzekeringsproducten op exact dezelfde manier moeten opbouwen. Dus hebben aanbieders de vrijheid om attributen en/of coderingen in te zetten die hen helpen onderscheidend te zijn.

Toch zijn er ook situaties waarin we bewust wel harmoniseren. Daarbij is vrijwel altijd sprake van een gedragen gemeenschappelijk belang. Voorbeelden zijn:

• De set vaste boekingsgegevens en afspraken binnen het ADN-boekingsbericht.
• Het harmoniseren van slotvragen als gevolg van afstemming tussen het Verbond en de NVGA.
• Het terugdringen van ongewenste variatie in het gebruik van AFD-attributen, zoals het gebruik van verzekerde loonsom voor inkomensverzekeringen in plaats van verzekerde som, dat men bij alle andere typen verzekeringen gebruikt.

De inzet van SIVI is om, waar mogelijk, knelpunten rond de eenduidigheid van het AFD op te lossen. Soms is dit complex en vereist dat brede afstemming; of en in welk tempo dit plaatsvindt, hangt af van de prioriteit. In andere gevallen moeten we issues accepteren als gevolg van de commerciële ruimte die ketenpartijen binnen het gebruik van het AFD nodig hebben.

Wat vraagt SIVI van jou?

Naast dat SIVI op basis van haar activiteiten zelf punten ten aanzien van een eenduidiger AFD onderkent, is het belangrijk dat AFD-gebruikers ook zelf melding maken van de issues die zij tegenkomen rond een eenduidiger AFD. Onderaan deze pagina vind je als download een document met een meer uitgebreide toelichting en concrete voorbeelden.

Voor het melden staat rechts op deze pagina de link naar het formulier. Jouw bijdrage maakt voor SIVI een groot verschil. Goede feedback is essentieel voor de ontwikkeling van het AFD.

Het totale proces rond ‘Eenduidiger AFD’ ziet er als volgt uit:

• Melder vult formulier op SIVI-website in en verzendt dit.
• Melder krijgt ontvangstbevestiging.
• SIVI beoordeelt of het issue op de backlog komt.
• Melder krijgt terugkoppeling wat SIVI met de melding gaat doen.
• Doorlopend lost SIVI items op de backlog op (timebox).
• Tweemaandelijks is er een herijking van de prioriteit van de backlog.
• Tweemaandelijks publiceren we de nieuwe backlog ‘Eenduidiger AFD’ op de SIVI-website.
• Wanneer een gemeld issue is afgehandeld, krijgt de melder een individuele terugkoppeling.
• Alle aanpassingen zijn zichtbaar in de reguliere SIVI AFS release notes.

SIVI publishes all documentation in Dutch. If you want to read it in another language, please use the translation module of your browser.

AFD 1.0 vs. AFD 2.0

De basis voor AFD 1.0 is midden jaren 90 gelegd in het verlengde van het ADN-berichtenverkeer. In 2020 heeft SIVI AFD 2.0 geïntroduceerd. In onderstaande figuur een overzicht van de belangrijkste verschillen tussen AFD 1.0 en AFD 2.0.

AFD 2.0 is overzichtelijker opgebouwd door de basis terug te brengen naar een dertigtal entiteiten, zoals coverage, object, party en document. Entiteiten zijn vervolgens onderverdeeld in subcategorieën die we ‘entityTypes’ noemen. Deze entityTypes, zoals ‘insuredPerson’ en ‘regularDriver’ onder de party-entiteit, bepalen welke deelverzamelingen van attributen er beschikbaar zijn. Verder zitten de verschillen tussen 1.0 en 2.0 vooral in moderne modelleerprincipes en de keuze voor JSON.

Binnen SIVI AFS benaderen we het AFD vanuit één gecombineerd perspectief. We hebben één attribuut ‘Maximaal toelaatbaar gewicht’ en vertalen dat naar AFD 1.0 (MAXGEW) en AFD 2.0 (maximumGrossVehicleWeight), inclusief bijbehorende omschrijving, datatype etc. Door de uitbreiding van het gegevensdomein in AFD 2.0, zoals hypotheekgegevens en energiecontracten, zijn er elementen die alleen in AFD 2.0 voorkomen.

Om de co-existentie van AFD 1.0 en AFD 2.0 te ondersteunen, biedt SIVI uitgebreide ondersteuning voor de mapping van AFD 1.0 naar AFD 2.0 en vice versa. Volg voor meer informatie de verwijzing rechts op deze pagina. Zo kan de keten zonder onderbrekingen blijven werken en stapsgewijs migreren naar AFD 2.0. De overgang van AFD 1.0 naar AFD 2.0 zal geen bigbangmigratie zijn. Binnen deze overgang onderscheiden we twee soorten trajecten:

1. Community-afspraken
   Onder community-afspraken valt bijvoorbeeld het gebruik van ADN-boekingsberichten, GRS-documentberichten en volmacht-services (zoals VPI). Voor deze clusters van gebruik is een bigbangscenario niet mogelijk, en is een gefaseerde en gecontroleerde migratie – van  waarschijnlijk enkele jaren – essentieel om de continuïteit van bedrijfsprocessen te waarborgen. SIVI zal per community de ambitie en tijdlijn voor migratie naar AFD 2.0 afstemmen en vaststellen.
2. Eigen regie
   Buiten de community-afspraken om gebruiken veel organisaties onder eigen regie het AFD. Zij kunnen in essentie zelf bepalen wanneer en hoe ze willen overstappen naar AFD 2.0. Bedrijven kunnen (ondersteund door de SIVI-tools) hun eigen migratiestrategieën ontwikkelen en uitvoeren, afgestemd op hun eigen planning en prioriteiten.

AFD^short

AFD^short is een tussenvariant van een AFD 2.0-bericht voor ketenpartijen die nog geen AFD 2.0-berichten kunnen verwerken, maar wel werken met moderne technieken (JSON/REST) en vertrouwd zijn met AFD 1.0. In AFD^short blijven de techniek en structuur van het bericht volledig AFD 2.0, maar is de naamgeving van de entiteiten en attributen gebaseerd op AFD 1.0.

Een belangrijk verschil in de labels tussen AFD 1.0 en AFD 2.0 is het opnemen van de bovenliggende entiteit in het attribuut-label. Dat zie je goed terug in een paar concrete voorbeelden van AFD 2.0-velden en hun AFD^short-equivalent in onderstaande tabel.

Zie in het handboek AFD 2.0 (verwijzing rechts op deze pagina) het hoofdstuk AFD^short voor meer details over het gebruik.

SIVI publishes all documentation in Dutch. If you want to read it in another language, please use the translation module of your browser.

AFD-mappingen

De transitie van AFD 1.0 naar AFD 2.0 gaat niet zonder een periode dat beide standaarden naast elkaar gebruikt worden. Daarnaast is het belangrijk dat AFD-gebruikers op enig moment de knop moeten kunnen omzetten om zich geheel te richten op het gebruik van AFD 2.0. Aanvullend zien we de wens van softwareleveranciers om het AFD te gebruiken als centrale standaard voor het vastleggen van gegevens. Waar de adviseur werkt aan een financieel 360-graden klantbeeld, ondersteunt het AFD de vastlegging van gegevens. Zo verbindt SIVI AFS niet alleen reguliere verzekeringsgegevens binnen het klantdossier, maar de verschillende domeinen binnen de financiële dienstverlening.

Deze drie uitgangpunten vormen de basis voor het aanbieden van de AFD-mappingen. De volgende AFD-mappingen zijn beschikbaar:

• Van AFD 2.0 naar AFD^short
• Van AFD 2.0 naar AFD 1.0
• Van AFD 1.0 naar AFD 2.0
• Van HDN-bericht naar AFD 2.0

In ontwikkeling is op dit moment de mapping van VNAB-berichten naar AFD 2.0.

Voor de AFD-mappingen is de AFD-mapping API ontwikkeld, zie voor de toelichting rond het gebruik van deze API de verwijzing rechts op deze pagina.

Ook kun je als organisatie zelf een mapping ontwikkelen. Bij inhoudelijke toetsing door SIVI kunnen deze opgenomen worden in het overzicht op deze pagina. Neem hiervoor contact op met Robin Oostrum.

Onderstaand per beschikbare mapping een korte toelichting.

Van AFD 2.0 naar AFD^short

AFD^short is een tussenvariant die SIVI aanbiedt voor de transitie van AFD 1.0 naar AFD 2.0. Zie het Handboek AFD 2.0 voor een toelichting. De verzendende partij stelt zijn berichten op in AFD 2.0. De ontvangende partij zet de berichten om in AFD^short. Technisch volgt AFD^short dezelfde structuur en inrichting als AFD 2.0: dezelfde JSON-structuur, dezelfde berichtopbouw en de dezelfde typering, echter de naamgeving van de labels volgt de AFD 1.0-systematiek.

Waar AFD 2.0 attributen semantisch groepeert binnen entiteiten, zijn in AFD^short de labels opgebouwd zoals in AFD 1.0: de entiteit en het attribuut worden gecombineerd tot één labelnaam. Daarmee zijn entiteit-attribuut-combinaties direct af te leiden uit het label (je kunt in principe het bericht lezen zonder naar de structuur te kijken). Dus het attribuut voor merk van een motorrijtuig is in AFD 2.0 “make” en in AFD^short is het “OB_MERK” (de AFD 1.0-naamgeving).

AFD^short is bedoeld voor partijen die prima uit de voeten kunnen met JSON en REST, maar waar systemen nog zijn ingericht op het ‘platte’ labelgebruik van AFD 1.0. AFD^short  biedt een laagdrempelige manier om AFD 2.0-technologie in te voeren, zonder dat men direct de hele structuur van berichtverwerking binnen een toepassing moet aanpassen aan de nieuwe semantiek.

SIVI ziet de route van AFD^short als voorkeursscenario bij de verwerking van AFD 2.0-berichten waarbij men de AFD 1.0-naamgevingssystematiek wil blijven gebruiken.

Figuur 1 – Voorbeeld van een bericht in AFD 2.0 en AFD^short

Van AFD 2.0 naar AFD 1.0

Met deze mapping is het mogelijk een AFD 2.0 JSON-bericht om te zetten naar een AFD 1.0 XML-bericht. Aandachtspunt bij deze mapping is dat de structuur van het AFD 2.0 JSON-bericht zich wel moet verhouden met geldige AFD 1.0-berichtstructuren.

Waar mogelijk ziet SIVI in de transitiefase het gebruik van AFD^short als voorkeursscenario bij de verwerking van AFD 2.0-berichten.

Figuur 2 – Mapping van AFD 2.0 naar AFD 1.0

 Van AFD 1.0 naar AFD 2.0

Met deze mapping kan een partij een AFD 1.0 XML-bericht omzetten naar een AFD 2.0 JSON-bericht.  Dit stelt partijen die hun software hebben ingericht op de verwerking van AFD 2.0-berichten, in staat om AFD 1.0-berichten te verwerken. Het AFD 2.0-bericht volgt de structuur van het AFD 1.0-bericht.

Figuur 3 – Mapping van AFD 1.0 naar AFD 2.0

Van HDN-bericht naar AFD 2.0

Deze mapping converteert een HDN XML-bericht naar een AFD 2.0 JSON-bericht. HDN is de afkorting van Hypotheken Data Netwerk en faciliteert het aanvraag-, acceptatie- en beheerproces van hypotheek- en hypotheekgerelateerde producten. HDN gebruikt daarvoor een eigen standaard. Deze mapping geeft ontwikkelaars de mogelijkheid om ten behoeve van een integraal klantbeeld alle gegevens uit berichten in AFD 2.0-formaat op te slaan.

Figuur 4 – Mapping van HDN naar AFD 2.0

SIVI publishes all documentation in Dutch. If you want to read it in another language, please use the translation module of your browser.