Verzekeraars kunnen EUDI-wallet-verificatie integreren in het onboardingproces van polishouders door zich te registreren als relying party, de specifieke identiteitsattributen op te vragen die ze nodig hebben en de credentials te verifiëren die door de wallet van de polishouder worden gepresenteerd. Het proces past naadloos in bestaande digitale onboardingflows en levert identiteitsgegevens op betrouwbaarheidsniveau hoog, wat de meeste huidige verificatiemethoden op zichzelf niet halen. De secties hieronder beschrijven welke gegevens beschikbaar zijn, hoe de flow werkt, welke compliancestappen vereist zijn en wanneer je moet beginnen.
Welke gegevens kunnen verzekeraars daadwerkelijk verifiëren via de EUDI-wallet?
Via de EUDI-wallet kunnen verzekeraars identiteitsattributen verifiëren uit de Personal Identification Data (PID) van de polishouder, zoals naam, geboortedatum, adres en nationaliteit. Afhankelijk van welke attestations de polishouder bezit, kunnen aanvullende geverifieerde gegevens beroepskwalificaties, aanspraken op ziektekostenverzekering of andere attributen omvatten die zijn afgegeven door bevoegde instanties.
De wallet slaat twee hoofdtypen verifieerbare gegevens op. De PID wordt afgegeven door een door de staat aangewezen autoriteit en bevat de kernidentiteitsattributen. Electronic Attestations of Attributes (EAA) worden afgegeven door andere bevoegde partijen en kunnen een veel breder scala aan informatie omvatten, van rijbewijzen tot beroepscredentials.
Een belangrijk kenmerk voor verzekeraars is selective disclosure. De polishouder deelt alleen de specifieke attributen die de verzekeraar heeft opgevraagd, en niets meer. Een verzekeraar die om leeftijdsbewijs vraagt, kan bijvoorbeeld bevestiging ontvangen dat de persoon ouder is dan 18 zonder de volledige geboortedatum te ontvangen. Dit is ingebouwd in de credentialformaten die de wallet gebruikt: mdoc (ISO/IEC 18013-5) en SD-JWT VC ondersteunen beide disclosure op attribuutniveau.
Eén belangrijke grens: de EUDI-wallet levert het identiteitsverificatiemechanisme. Of een verzekeraar op een wallet-gebaseerde controle mag vertrouwen om te voldoen aan zijn Know Your Customer-verplichtingen onder de antiwitwasregels, wordt bepaald door de Anti-Money Laundering Regulation (AMLR) en sectorspecifieke regels, niet door eIDAS 2.0 zelf. De wallet levert de gegevens; de AML-complianceregels bepalen hoe die gegevens mogen worden gebruikt.
Hoe past EUDI-wallet-verificatie in de onboardingflow?
EUDI-wallet-verificatie past in het onboardingproces van polishouders als een gestructureerd presentatieverzoek: de verzekeraar stuurt een verzoek naar de wallet van de polishouder, de polishouder beoordeelt en keurt goed welke attributen worden gedeeld, en de verzekeraar ontvangt een cryptografisch ondertekend antwoord. Dit vervangt of vult handmatige documentcontroles en het invullen van formulieren aan met één enkele, geverifieerde gegevensuitwisseling.
In de praktijk ziet de flow er als volgt uit:
- De onboardinginterface van de verzekeraar genereert een presentatieverzoek met de exacte benodigde attributen, bijvoorbeeld naam, adres en geboortedatum.
- De polishouder ontvangt het verzoek in zijn wallet-app, beoordeelt wat er wordt gevraagd en keurt de disclosure goed.
- De wallet presenteert de gevraagde attributen als een ondertekende attestation.
- Het systeem van de verzekeraar verifieert de presentatie en vult het klantrecord met de bevestigde gegevens.
Omdat de identiteitsgegevens vooraf geverifieerd binnenkomen op betrouwbaarheidsniveau hoog, hoeft de verzekeraar de onderliggende documenten niet opnieuw te controleren. De polishouder hoeft geen gegevens opnieuw in te voeren die de wallet al bevat, wat de wrijving en het risico op invoerfouten vermindert.
Een praktisch punt voor systeemontwerp: koppel het klantrecord niet aan een wallet unit-identifier. Als de polishouder van apparaat wisselt, worden zijn attestations opnieuw uitgegeven door de oorspronkelijke uitgever en gekoppeld aan een nieuwe wallet unit. Dezelfde persoon keert terug met andere technische identifiers, dus het klantrecord moet worden verankerd aan stabiele identiteitsattributen, niet aan de wallet unit zelf.
Aan welke compliancevereisten moeten verzekeraars voldoen om EUDI-wallet-credentials te accepteren?
Verzekeraars die EUDI-wallet-credentials willen accepteren, moeten zich registreren als relying party onder CIR (EU) 2025/848 van 6 mei 2025 bij een nationale autoriteit in hun lidstaat van vestiging voordat ze wallet-gegevens kunnen opvragen. Registratie is een voorwaarde, geen formaliteit die later kan volgen.
Registratie heeft directe operationele gevolgen:
- De scope is bindend. Bij registratie verklaart de verzekeraar precies welke attributen en attestations hij zal opvragen, per beoogd gebruik. De wallet controleert elk inkomend verzoek aan de hand van die geregistreerde scope en stopt de presentatie als het verzoek die scope overschrijdt. Meer opvragen dan geregistreerd is een expliciete grond voor intrekking van de registratie.
- Toegangscertificaten. Geregistreerde relying parties ontvangen toegangscertificaten. De wallet verifieert deze certificaten bij elk gegevensverzoek, zodat de polishouder kan zien dat de verzoekende partij rechtmatig is geregistreerd.
- Pseudoniemen. Waar identificatie niet wettelijk vereist is, mag de verzekeraar een polishouder die kiest voor een pseudoniem niet weigeren.
Aan de verificatiekant omvat het accepteren van een wallet-presentatie drie controles, niet één. Ten eerste wordt de handtekening van de uitgever geverifieerd aan de hand van de nationale trusted list van de betreffende lidstaat, die deel uitmaakt van de EU List of Trusted Lists (LOTL). Ten tweede wordt de intrekkingsstatus van de attestation gecontroleerd aan de hand van statusinformatie die door de uitgever is gepubliceerd. Ten derde bevestigt de wallet unit attestation dat de presenterende wallet draait op een gecertificeerde wallet solution. De eerste controle kan offline worden uitgevoerd; het overslaan van de tweede betekent het accepteren van mogelijk ingetrokken attestations.
Financiële diensten worden expliciet genoemd in artikel 5f van eIDAS 2.0 als een gereguleerde sector die onderworpen is aan de private acceptatieplicht. Voor verzekeraars is de deadline 24 december 2027: vanaf die datum is het accepteren van de EUDI-wallet verplicht waar sterke gebruikersauthenticatie wettelijk of contractueel vereist is. De verplichting geldt voor organisaties boven de drempel voor micro- en kleine ondernemingen, wat betekent dat organisaties met minder dan 50 werknemers en een jaarlijkse omzet of balanstotaal van maximaal 10 miljoen euro zijn vrijgesteld.
Verzekeraars die werken met digitale identiteit in financiële dienstverlening willen ook de AMLR in de gaten houden, die van toepassing is vanaf juli 2027, vijf maanden vóór de deadline voor wallet-acceptatie.
Hoe verhoudt EUDI-wallet-onboarding zich tot bestaande digitale identiteitsmethoden?
EUDI-wallet-onboarding levert identiteitsgegevens op betrouwbaarheidsniveau hoog, het hoogste niveau dat is gedefinieerd onder eIDAS. De meeste bestaande digitale identiteitsmethoden die worden gebruikt bij verzekeraarsonboarding, zoals kennisgebaseerde controles, gescande documentuploads of eID-schema’s met een lager betrouwbaarheidsniveau, halen dat niveau niet zonder aanvullende stappen.
De praktische verschillen zijn aanzienlijk. Bij documentuploads of handmatige controles ontvangt de verzekeraar een kopie van een identiteitsdocument en moet de authenticiteit ervan beoordelen. Met de EUDI-wallet ontvangt de verzekeraar een cryptografisch ondertekende attestation van een door de staat bevoegde uitgever, geverifieerd aan de hand van een nationale trusted list. De gegevens zijn al bij de bron gecontroleerd.
Bestaande nationale eID-schema’s, zoals DigiD in Nederland of ID Austria, werken in sommige contexten al op hoog betrouwbaarheidsniveau, maar ze zijn landspecifiek. De EUDI-wallet introduceert een gemeenschappelijk kader voor alle EU-lidstaten, wat van belang is voor verzekeraars die grensoverschrijdend actief zijn of polishouders uit andere landen onboarden.
Selective disclosure is een ander onderscheid. Huidige methoden vereisen doorgaans het delen van een volledig document om één feit te bewijzen. Met de wallet kan de polishouder alleen het attribuut delen dat daadwerkelijk nodig is, wat de hoeveelheid gegevens die de verzekeraar verzamelt vermindert en de naleving van de dataminimalisatievereisten onder de AVG vereenvoudigt.
Eén beperking om op te letten: de wallet-goedkeuring die een polishouder geeft bij het delen van attributen is niet hetzelfde als toestemming als rechtsgrondslag onder artikel 6(1)(a) AVG. De verzekeraar heeft nog steeds een eigen rechtsgrondslag nodig voor de verwerking van de ontvangen gegevens. Voor KYC-doeleinden is die grondslag doorgaans een wettelijke verplichting, niet toestemming.
Welke technische infrastructuur hebben verzekeraars nodig om de EUDI-wallet te integreren?
Om EUDI-wallet-presentaties te accepteren, heeft een verzekeraar de mogelijkheid nodig om conforme presentatieverzoeken te genereren, attestations in de ondersteunde formaten (mdoc en SD-JWT VC) te ontvangen en te verwerken, en de drie verificatiecontroles uit te voeren aan de hand van trusted lists, intrekkingsstatus en de wallet unit attestation. Dit vereist integratie met de EU List of Trusted Lists en de Lists of Trusted Entities (LoTE) zoals gedefinieerd in ARF v3.0.0.
De uitwisselingsprotocollen zijn OID4VP voor presentatie en OID4VCI voor uitgifte. Voor mdoc gebruikt nabijheidspresentatie ISO/IEC 18013-5 en online presentatie ISO/IEC TS 18013-7. Verzekeraars die zich richten op remote onboarding werken voornamelijk met het online presentatiepad. Het High Assurance Interoperability Profile (HAIP) profileert beide protocollen voor gebruik op hoog betrouwbaarheidsniveau en is de relevante referentie voor implementatie.
Verzekeraars moeten ook de toegangscertificaten beheren die via registratie zijn verkregen, omdat de wallet deze bij elk verzoek controleert. De software van de verzekeraar als relying party is zelf niet gecertificeerd, maar de implementatie moet de vereiste protocollen en formaten correct volgen en alle drie de verificatiecontroles uitvoeren.
Omdat attestations opnieuw worden uitgegeven in plaats van overgedragen wanneer een polishouder van apparaat wisselt, moet het systeem van de verzekeraar worden ontworpen om terugkerende klanten te matchen op basis van stabiele identiteitsattributen in plaats van op basis van een wallet-niveau-identifier. Dit is een ontwerpbeslissing die van invloed is op hoe klantrecords vanaf het begin worden gestructureerd.
Wanneer moeten verzekeraars beginnen met de voorbereiding op EUDI-wallet-adoptie?
Verzekeraars moeten nu beginnen met de voorbereiding. De private sector-acceptatieplicht onder artikel 5f geldt vanaf 24 december 2027, en het registratieproces, de technische integratie en het interne compliancewerk kosten allemaal tijd. De AMLR is van toepassing vanaf juli 2027, wat een paralleel compliancetraject toevoegt dat raakvlakken heeft met identiteitsverificatieprocessen.
De deadline voor de publieke sector van 24 december 2026 is ook relevante context: vanaf die datum moet elke lidstaat ten minste één gecertificeerde EUDI-wallet hebben uitgegeven en moeten publieke diensten deze accepteren. Dit betekent dat polishouders wallets zullen gaan bezitten en gebruiken voordat verzekeraars wettelijk verplicht zijn deze te accepteren. Vroege adopters in de verzekeringssector kunnen wallet-gebaseerde onboarding aanbieden aan die gebruikers vóór de verplichte deadline.
Registratie onder CIR (EU) 2025/848 is een voorwaarde voor het accepteren van wallet-gegevens. Verzekeraars kunnen geen wallet-presentaties opvragen zonder geregistreerd te zijn, dus het registratieproces moet ruim vóór een geplande go-live-datum worden gestart. Het definiëren van de exacte attribuutscope bij registratie vereist ook interne afstemming tussen compliance-, juridische en productteams, omdat de geregistreerde scope bindend is en niet mag worden overschreden zonder het risico op intrekking.
Organisaties die werken aan implementatie van digitale identiteit in gereguleerde sectoren merken doorgaans dat de compliance- en organisatorische voorbereiding meer tijd kost dan de technische integratie zelf. Door het interne proces in 2026 te starten, is er voldoende tijd om te registreren, te testen en live te gaan vóór de deadline van 2027.
Hoe de ID Connector verzekeraars helpt de EUDI-wallet te accepteren
De ID Connector is een integratie waarmee relying parties elke gecertificeerde Europese wallet kunnen accepteren, ongeacht welke lidstaat deze heeft uitgegeven, voor identificatie, inloggen en gekwalificeerd ondertekenen. EUDI-wallet-acceptatie staat voorop; dezelfde interface ondersteunt ook andere ID’s, zoals nationale eID’s, bank-ID’s en identiteitsdocumenten, binnen en buiten de EU.
Specifiek voor verzekeraarsonboarding verzorgt de ID Connector de technische laag die zich bevindt tussen de systemen van de verzekeraar en het wallet-ecosysteem:
- Verificatie van handtekeningen van uitgevers aan de hand van nationale trusted lists en de LOTL
- Controles van de intrekkingsstatus voor gepresenteerde attestations
- Validatie van de wallet unit attestation om te bevestigen dat de wallet draait op een gecertificeerde solution
- Handhaving van de geregistreerde attribuutscope, zodat de verzekeraar alleen ontvangt wat hij heeft opgevraagd
- Hergebruik van geverifieerde identiteitsgegevens over interacties heen, zodat een terugkerende polishouder dezelfde verificatiestappen niet hoeft te herhalen
De ID Connector is gebouwd voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en de overheid, waar identiteitszekerheid en naleving van regelgeving centrale vereisten zijn. Neem contact op met TrustTech om te bespreken hoe de ID Connector past in jouw onboardingarchitectuur.