De portemonnee komt in december, de acceptatieplicht een jaar later.

TL;DR. Lidstaten leveren in december 2026 een EU-portemonnee voor digitale identiteit. Banken accepteren hem vanaf december 2027. Die twaalf maanden zijn het probleem.

Belangrijkste punten

Twee data, één gat. Begin bij de tijdlijn, want vrijwel elke verkeerde lezing van dit dossier komt voort uit het samenvouwen van de twee data tot één.
Vertrouwende partij is een juridische rol, geen integratiepatroon. Dit is de bepaling die in technische lezingen het vaakst wordt overgeslagen, en het is de bepaling met de langste doorlooptijd.
De portemonnee schaft sterke cliëntauthenticatie niet af. Een terugkerende fout in vroege planningsdecks is de aanname dat acceptatie van de portemonnee het authenticatieregime van PSD2 opzijzet.
Wat verificatie u niet vertelt. Dit is het deel dat identiteitsteams stelselmatig verrast, en het is de moeite waard om het onomwonden te zeggen.

Tien jaar lang bezaten banken de login. De instelling gaf de verklaring uit, voerde de authenticatie uit, hield het auditspoor bij en bepaalde wat "geverifieerd" betekende. De Europese verordening over digitale identiteit beëindigt die opzet zonder dat ooit met zoveel woorden te zeggen. Zij verplicht elke lidstaat om vóór december 2026 een portemonnee beschikbaar te stellen aan burgers, en zij verplicht banken — bij sector genoemd, niet bij gevolgtrekking — om die portemonnee vóór december 2027 te accepteren voor sterke gebruikersauthenticatie. Tussen die twee data ligt een jaar waarin de verklaring bestaat, klanten haar bij zich dragen en de verplichting nog niet bijt. De meeste instellingen behandelen dat jaar als speling. Het is het bouwvenster.

Managementsamenvatting

Dit is vaststaand recht, anders dan het meeste in het dossier 2026. Regulation (EU) 2024/1183 is van kracht. De data staan vast in de tekst in plaats van te wachten op de triloog, waardoor dit een van de weinige programma's is waarop met vertrouwen kan worden gepland.

De bank wordt een vertrouwende partij. Dat is een omschreven juridische rol met een registratieplicht eraan vast. Het is het eerste identiteitsregime waarin een bank formeel, bij een publieke registerhouder, moet verklaren wat zij haar klanten wil vragen.

Acceptatie is geen authenticatiestrategie. De verplichting is om een presentatie uit de portemonnee te accepteren wanneer een gebruiker die aanbiedt. Wat de bank met de verkregen zekerheid doet — en hoe zij die rijmt met haar eigen risicomodel — blijft aan de bank.

Het lastige begint nadat de verklaring is geverifieerd. Een cryptografisch geldige presentatie vertelt u dat de houder is wie de staat zegt dat hij is. Zij vertelt u niet of hij de persoon is die in 2014 de rekening opende.

Twee data, één gat

Begin bij de tijdlijn, want vrijwel elke verkeerde lezing van dit dossier komt voort uit het samenvouwen van de twee data tot één.

Regulation (EU) 2024/1183 wijzigde de oorspronkelijke eIDAS-verordening, Regulation (EU) No 910/2014, en trad in mei 2024 in werking. Zij gaf de Commissie een mandaat om uitvoeringshandelingen vast te stellen die bepalen hoe portemonnees worden gebouwd, gecertificeerd, geregistreerd en gebruikt, en zij stelde twee verplichtingen in die op verschillende klokken lopen.

De eerste rust op de lidstaten. Vóór 24 december 2026 moet elke lidstaat ten minste één European Digital Identity Wallet beschikbaar stellen aan burgers en ingezetenen. Dat is een leveringsplicht: de staat, of een partij die hij aanwijst, levert de portemonnee, en natuurlijke personen betalen er niet voor.

De tweede rust op vertrouwende partijen. Vóór 24 december 2027 moeten grote en middelgrote vertrouwende partijen die wettelijk of contractueel verplicht zijn sterke gebruikersauthenticatie toe te passen bij identificatie — en die actief zijn in een van de genoemde sectoren, waaronder het bank- en financiële wezen — de portemonnee accepteren wanneer een gebruiker daar vrijwillig om vraagt, op grond van Article 5f.

Daar zitten twaalf maanden tussen, en de volgorde doet ertoe. De verklaring komt eerst. De plicht om haar te accepteren komt een jaar later.

De meeste programmaplannen die ik heb gezien, ankeren op de datum in 2027. Dat is een redelijke lezing van een compliancedeadline en een slechte lezing van het werkelijke risico. Vanaf december 2026 kunnen klanten van een bank een door de staat uitgegeven digitale identiteitsverklaring bezitten die de bank nog niet kan verwerken. Concurrenten die dat wel kunnen, zullen haar gebruiken — voor klantacceptatie in seconden in plaats van dagen, en voor herauthenticatietrajecten die het uploaden van documenten volledig overslaan. De deadline is 2027. De concurrentiële blootstelling begint in 2026.

Vertrouwende partij is een juridische rol, geen integratiepatroon

Dit is de bepaling die in technische lezingen het vaakst wordt overgeslagen, en het is de bepaling met de langste doorlooptijd.

Op grond van Article 5b moet een partij die zich op European Digital Identity Wallets wil verlaten, zich registreren in de lidstaat waar zij is gevestigd. Registratie is geen aanmelding op een ontwikkelaarsportaal. Zij identificeert de instelling, legt de lidstaat van vestiging en het registratienummer vast en dekt — cruciaal — het beoogde gebruik, inclusief de attributen die de vertrouwende partij zal opvragen.

Daaruit volgen drie gevolgen, en geen ervan is een engineeringprobleem.

Het attribuutverzoek wordt een verklaard standpunt. Een bank moet vooraf en voor de registers beslissen wat zij klanten zal vragen prijs te geven. "Alles wat de portemonnee ons geeft" is geen beschikbaar antwoord. Dataminimalisatie houdt op een principe te zijn waarvoor de privacyafdeling pleit en wordt een beperking die de registratie vastlegt.

Productwijzigingen krijgen een registratieafhankelijkheid. Een nieuw traject dat een attribuut buiten de geregistreerde reikwijdte nodig heeft, is geen sprintitem. Wat de administratieve doorlooptijd per lidstaat ook blijkt te zijn, dezelfde dag is het niet.

Banken in meerdere jurisdicties registreren zich op meerdere plaatsen. Een instelling die in verschillende lidstaten is gevestigd, heeft met verschillende registerhouders te maken. De portemonnee is ontworpen om grensoverschrijdend te werken — een Duitse portemonnee werkt bij een Franse vertrouwende partij — maar de registratieplicht hangt aan de vestiging, en de groepsstructuur bepaalt hoeveel gesprekken dat betekent.

Tabel 1: Waar de bank vóór en na staat

Dimensie	Bankeigen identiteit (vandaag)	EUDI Wallet (Article 5f)
Wie geeft de verklaring uit	De bank, na haar eigen klantacceptatie	De lidstaat of een aangewezen aanbieder
Wie bepaalt of zij geldig is	De bank, tegen haar eigen administratie	De bank, tegen handtekening en status van de uitgever
Wat de klant beheerst	Weinig; de bank bezit de relatie	Welke attributen worden vrijgegeven, per presentatie
Wat de bank moet doen	Wat haar risicobereidheid toelaat	Een presentatie accepteren wanneer een gebruiker daarom vraagt
Voorwaarde om deel te nemen	Geen, buiten haar eigen systemen	Registratie als vertrouwende partij op grond van Article 5b
Kosten van meer data vragen	Een interne productbeslissing	Een wijziging van een geregistreerde, verklaarde reikwijdte

De portemonnee schaft sterke cliëntauthenticatie niet af

Een terugkerende fout in vroege planningsdecks is de aanname dat acceptatie van de portemonnee het authenticatieregime van PSD2 opzijzet. Dat doet zij niet.

Sterke cliëntauthenticatie op grond van Directive (EU) 2015/2366 en de technische reguleringsnormen in Commission Delegated Regulation (EU) 2018/389 blijft bepalen hoe betaaldienstverleners betalers authenticeren en transacties autoriseren. De verplichting uit Article 5f komt daar boven op, niet in de plaats van. Een bank moet nog steeds aan haar SCA-verplichtingen voldoen; zij moet daarnaast een portemonnee accepteren wanneer een klant die aanbiedt voor sterke gebruikersauthenticatie.

De praktische vraag is dus niet "vervangt de portemonnee onze SCA-factoren", maar "wat draagt een presentatie uit de portemonnee bij aan een SCA-conforme authenticatie, en wat moeten wij zelf nog doen". Dat is een architectuurvraag met een echt antwoord, en het loont die vóór de deadline uit te werken in plaats van eronder, want de twee regimes zijn door verschillende instrumenten voor verschillende doelen opgesteld en zij komen samen binnen uw authenticatiedienst.

Er zit een verwante val in het aansprakelijkheidsmodel. In de huidige opzet geeft de bank de verklaring uit en bezit zij daarmee de meeste faalwijzen. In de nieuwe wordt de verklaring elders uitgegeven en door de bank geverifieerd. Verificatie die open faalt, een verouderde intrekkingsstatus bij een uitgever, of een presentatie die opnieuw wordt afgespeeld: het zijn faalwijzen waarmee de instelling weinig geschiedenis heeft, en de verdeling van de schade tussen aanbieder van de portemonnee, uitgever en vertrouwende partij is precies het soort vraag dat traag en kostbaar wordt beslecht na het eerste incident.

Wat verificatie u niet vertelt

Dit is het deel dat identiteitsteams stelselmatig verrast, en het is de moeite waard om het onomwonden te zeggen.

Een presentatie uit de portemonnee geeft cryptografische zekerheid dat een reeks attributen door een vertrouwde autoriteit is uitgegeven aan de houder van de portemonnee, en dat de houder aanwezig is. Zij vertelt u met hoge zekerheid dat deze persoon is wie de staat zegt dat hij is.

Zij vertelt u niet dat deze persoon de klant is die de rekening heeft geopend.

Voor klantacceptatie maakt dat onderscheid weinig uit — de portemonnee benadert het ideaal, en identiteitsvaststelling die nu een documentscan, een liveness-controle en een handmatige beoordeling vergt, klapt samen tot één presentatie. Voor een bestaande portefeuille maakt het enorm uit. Een door de staat uitgegeven digitale identiteit koppelen aan een rekening die in 2014 werd geopend op een inmiddels verlopen paspoort, onder een naam die mogelijk is gewijzigd, is een recordkoppelingsprobleem. Het is hetzelfde werk aan entiteitsresolutie dat open finance- en klantdataprogramma's telkens opnieuw ontdekken, en het wordt niet eenvoudiger doordat de binnenkomende verklaring cryptografisch uitmuntend is.

Instellingen die integratie van de portemonnee als een kanaalproject behandelen, bouwen een werkende presentatiestroom en ontdekken daarna dat de interessante faalwijze het matchpercentage tegen hun eigen klantenbestand is. Dat werk heeft een lange doorlooptijd en geen afhankelijkheid van welke uitvoeringshandeling dan ook. Het kan nu beginnen.

Tabel 2: Waarin de bouw feitelijk uiteenvalt

Werkstroom	Afhankelijk van het bestaan van de portemonnee?	Kan nu beginnen
Registratie als vertrouwende partij in elke lidstaat van vestiging	Registerhouder operationeel	Bepaal de attribuutreikwijdte die u verklaart
Verificatie van presentaties, vertrouwenslijst en afhandeling van intrekking	Ja, voor end-to-end-testen	Protocolkeuze en dienstontwerp
Een geverifieerde identiteit koppelen aan een bestaand klantrecord	Nee	Ja — dit is de langste paal
Acceptatie van de portemonnee rijmen met SCA-verplichtingen	Nee	Ja
Aansprakelijkheid, incident- en geschilafhandeling voor een verklaring die u niet uitgaf	Nee	Ja
Toetsing op attribuutminimalisatie van bestaande trajecten	Nee	Ja

Vier van de zes wachten nergens op.

Het operationele draaiboek

Zes zetten, in de volgorde waarin ik ze zou plannen.

Wijs de verantwoordelijke eigenaar aan. Dit ligt dwars over identiteit, klantacceptatie, betalingen en juridische zaken, wat in de meeste banken betekent dat het nergens ligt. Acceptatie van de portemonnee mislukt als gefedereerd initiatief.
Bepaal de attribuutreikwijdte voordat de registerhouder ernaar vraagt. De registratie verklaart wat u zult opvragen. Werk het minimum uit dat uw trajecten ondersteunt, want een verklaarde reikwijdte is eenvoudiger bewust te verbreden dan te versmallen na een privacytoetsing.
Begin nu met het koppelingsprobleem. Een staatsidentiteit matchen aan een bestaand klantrecord is de werkstroom met de langste staart en de minste afhankelijkheden. Het is ook de werkstroom die bepaalt of acceptatie een goede ervaring wordt of een supportwachtrij.
Leg de afstemming met SCA schriftelijk vast. Documenteer hoe een presentatie uit de portemonnee samenspeelt met uw bestaande authenticatiefactoren en waar de regimes elkaar raken. Doe dat als architecture decision record, niet als slide.
Modelleer de faalwijzen die u nooit bezat. Verouderde intrekking, uitval bij de uitgever, verificatie die open faalt. U hebt deze verklaring niet uitgegeven; ga ervan uit dat de faalwijzen niet de uwe zijn om te beheersen en ontwerp daarnaar.
Gebruik het gat van twaalf maanden bewust. Portemonnees zijn live vanaf december 2026. Behandel 2027 als het jaar waarin u de capaciteit exploiteert, niet het jaar waarin u haar bouwt.

Banken hebben in het open-bankingtijdperk geleerd dat een verplichte interface zelden alleen een interface is. Dit is dezelfde les, die via een ander instrument binnenkomt. De instellingen die Article 5f lezen als een integratieticket, leveren op tijd een conforme presentatiestroom op en kunnen nog steeds de enige vraag die aan de balie telt niet beantwoorden: is de persoon die deze portemonnee vasthoudt de persoon wiens rekening u op het punt staat te openen?

Veelgestelde vragen

Wanneer moet een bank de portemonnee precies accepteren?
Vóór 24 december 2027, voor grote en middelgrote vertrouwende partijen die wettelijk of contractueel verplicht zijn sterke gebruikersauthenticatie toe te passen en die actief zijn in een genoemde sector, waaronder het bank- en financiële wezen. De afzonderlijke verplichting voor lidstaten om ten minste één portemonnee beschikbaar te stellen loopt een jaar eerder af, op 24 december 2026.

Staat dit vast, of kunnen de data verschuiven?
Regulation (EU) 2024/1183 is van kracht en de data staan in de aangenomen tekst, niet in een voorstel dat nog wordt onderhandeld. Dat maakt dit wezenlijk steviger dan het meeste waarop banken nu plannen, en het is een van de redenen waarom dit dossier vroeg werk beloont.

Betekent acceptatie van een portemonnee dat wij onze eigen authenticatie kunnen uitfaseren?
Nee. De verplichting is om een presentatie uit de portemonnee te accepteren wanneer een gebruiker daar vrijwillig om vraagt. Klanten die geen portemonnee hebben, of die haar niet willen gebruiken, moeten nog steeds worden bediend, en de eisen voor sterke cliëntauthenticatie uit PSD2 blijven hoe dan ook gelden voor betaaltrajecten.

Waartoe verplicht de registratie op grond van Article 5b ons feitelijk?
Tot registratie in de lidstaat waar u bent gevestigd, identificatie van de instelling en verklaring van het beoogde gebruik, inclusief de attributen die u wilt opvragen. Het praktische effect is dat uw positie inzake dataminimalisatie openbaar wordt vastgelegd en een beperking vormt op toekomstige productwijzigingen.

Wij zijn niet in de EU gevestigd. Raakt dit ons?
De acceptatieplicht in Article 5f hangt aan vertrouwende partijen die binnen het kader van de Unie in de genoemde sectoren actief zijn, en de registratieplicht hangt aan de lidstaat van vestiging. Groepsstructuur en de vestigingsplaats van elke gereguleerde entiteit bepalen het antwoord. Dat is een juridische vraag die u beter vroeg oplost dan een technische.

Wat is het nuttigste om dit kwartaal te starten?
Entiteitsresolutie tussen een door de staat uitgegeven identiteit en uw bestaande klantenbestand. Het hangt niet af van portemonnees, uitvoeringshandelingen of registerhouders, het is de werkstroom die het meest bepaalt of acceptatie in de praktijk werkt, en het is de werkstroom die standaard van niemand is.

Referenties

European Parliament and Council of the European Union, 2024. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Brussel: Publicatieblad van de Europese Unie. Beschikbaar op: European Parliament and Council of the European Union, 2024..
Europese Commissie, 2026. European Digital Identity Wallet. Brussel: Directoraat-generaal Communicatienetwerken, Inhoud en Technologie. Beschikbaar op: Europese Commissie, 2026..
Europese Commissie, 2026. EUDI Wallet Architecture and Reference Framework. Brussel: Europese Commissie. Beschikbaar op: Europese Commissie, 2026..
European Parliament and Council of the European Union, 2015. Directive (EU) 2015/2366 on payment services in the internal market (PSD2). Brussel: Publicatieblad van de Europese Unie. Beschikbaar op: European Parliament and Council of the European Union, 2015..
Europese Commissie, 2018. Commission Delegated Regulation (EU) 2018/389 supplementing Directive (EU) 2015/2366 with regard to regulatory technical standards for strong customer authentication. Brussel: Publicatieblad van de Europese Unie. Beschikbaar op: Europese Commissie, 2018..
OpenID Foundation, 2026. OpenID for Verifiable Presentations. San Ramon: OpenID Foundation. Beschikbaar op: OpenID Foundation, 2026..

Laatst herzien 2026-08-08.

Dit artikel herpubliceren

De portemonnee komt in december, de acceptatieplicht een jaar later. — Sebastien Rousseau

Lidstaten leveren in december 2026 een EU-portemonnee voor digitale identiteit. Banken accepteren hem vanaf december 2027. Die twaalf maanden zijn het probleem.

Dit artikel valt onder de licentie Creative Commons Attribution 4.0 International. Herpublicatie vereist attributie aan de canonieke URL.

De portemonnee komt in december, de acceptatieplicht een jaar later. — Sebastien Rousseau

Lidstaten leveren in december 2026 een EU-portemonnee voor digitale identiteit. Banken accepteren hem vanaf december 2027. Die twaalf maanden zijn het probleem.

Originally published at https://sebastienrousseau.com/nl/2026-08-01-eudi-wallet-eidas-2-banks-relying-party-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER