Companies can integrate EUDI Wallet verification with bank ID authentication by connecting both methods through a single identity integration layer that accepts verified attributes from the wallet alongside existing bank authentication flows. The practical approach depends on how a company’s current systems handle strong customer authentication and what role the EUDI Wallet will play, whether as a primary identification method, a supplementary verification step, or a replacement for specific use cases. The sections below walk through the key questions organizations in financial services are asking right now.
What authentication methods do banks currently use for digital identity?
Banks currently rely on a combination of password-based login, one-time codes sent by SMS or app, hardware tokens, and national bank ID schemes such as Swedish BankID, Norwegian BankID, and Denmark’s MitID. These methods handle everyday authentication for online banking and are widely trusted within their home markets, but they operate as separate national systems with limited cross-border reach.
For higher-stakes interactions, such as opening a new account or authorizing a large transfer, banks layer in additional checks: document scans, video identification, or biometric verification against a passport chip. These steps satisfy Know Your Customer requirements under anti-money laundering rules, though whether a bank may rely on a check performed elsewhere is governed by AML legislation, not by eIDAS.
The assurance levels of existing methods vary considerably. Swedish BankID and Norwegian BankID are strong authentication tools, but they operate as two entirely separate systems and should not be described as a single scheme. Most national bank ID solutions reach a substantial level of assurance, yet they rarely reach the high assurance level that the EUDI Wallet is required to deliver under eIDAS 2.0. That gap matters when regulators or contracts require the highest level of identity certainty.
How does EUDI Wallet verification differ from bank ID authentication?
EUDI Wallet verification differs from bank ID authentication in three fundamental ways: the assurance level it delivers, the data it carries, and the cross-border scope it covers. Where bank ID schemes authenticate a user within a national ecosystem, the EUDI Wallet presents cryptographically signed identity attributes, issued at high assurance, that any registered relying party across the EU can verify.
When a user presents attributes from their EUDI Wallet, the receiving organization performs three distinct checks:
- The issuer’s signature is verified against the national trusted list of the issuing Member State, which is part of the EU List of Trusted Lists (LOTL) under ETSI TS 119 612.
- The revocation status of the attestation is checked against status information published by the issuer. Skipping this step means accepting potentially revoked credentials.
- The wallet unit attestation confirms that the presenting wallet is running on a certified wallet solution. This check involves the wallet unit, which is the wallet instance together with its Wallet Secure Cryptographic Application and Wallet Secure Cryptographic Device.
Bank ID authentication typically confirms that a specific user controls a specific account or device. The EUDI Wallet goes further by delivering verified identity attributes, such as name, date of birth, or address, directly from an authoritative source, with selective disclosure so the user shares only what a particular interaction requires. A bank ID tells you who is logging in; the EUDI Wallet can also tell you who that person legally is, at a level of assurance that satisfies regulatory requirements.
How can companies technically integrate EUDI Wallet with existing bank ID systems?
The technical integration connects EUDI Wallet presentation protocols with the authentication flows that already handle bank ID. In practice, this means adding support for the credential formats and exchange protocols defined in the Architecture and Reference Framework (ARF v3.0.0): mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC, exchanged via OID4VP for presentation and OID4VCI for issuance.
A workable integration path typically involves the following steps:
- Register as a relying party under CIR (EU) 2025/848 with the national authority in your Member State of establishment. Registration is required before you can request wallet data, and it defines exactly which attributes you are permitted to request per intended use.
- Obtain access certificates that the wallet checks at every data request. These certificates confirm your registration and the scope you declared.
- Implement the three verification checks described above: issuer signature against the trusted list, revocation status, and wallet unit attestation.
- Connect wallet presentation to your existing session management, so a verified wallet presentation can initiate or elevate a session in the same way a bank ID login currently does.
- Handle selective disclosure correctly in your data layer: log that you stayed within your registered attribute scope, not the full set of presented attributes, to preserve the privacy benefit of selective disclosure.
One practical note on customer records: never tie a customer file to a wallet unit identifier. Private keys cannot leave the secure cryptographic device, so attestations are reissued rather than copied when a user switches devices. The same person will return with a new wallet unit and freshly issued attestations. Link records to stable identity attributes instead.
For organizations that want to accept both EUDI Wallets and existing bank IDs through a single connection, the ID Connector from TrustTech handles this at the integration layer, covering trust management, revocation checks, and wallet unit attestation validation across certified European wallets and other identity methods.
What compliance requirements apply to EUDI Wallet integration in financial services?
Financial services organizations integrating EUDI Wallet verification face compliance requirements from two directions: the eIDAS 2.0 framework and existing sector-specific rules, particularly AML legislation.
Under eIDAS 2.0, the key obligations for a financial institution acting as a relying party are:
- Registration under CIR (EU) 2025/848 (established 6 May 2025): you must register with a national authority before requesting wallet data, specifying per intended use exactly which attributes and attestations you will request. Requesting more than your registered scope is an explicit ground for revocation of your registration.
- Accepting every certified wallet: a relying party must accept any notified EUDI Wallet regardless of which provider issued it or which Member State it comes from. You do not choose a wallet provider; you accept all of them.
- Not refusing pseudonyms where identification is not legally required (article 5a).
- Maintaining a separate legal basis under GDPR for processing the identity data you receive. The user’s approval in the wallet is not the same as consent under article 6(1)(a) GDPR. For KYC purposes, the legal basis is typically a statutory obligation.
On the AML side, eIDAS does not determine whether a bank may rely on a KYC check performed elsewhere. That question is governed by the AML Regulation (AMLR), which applies from July 2027, five months before the private sector acceptance deadline of 24 December 2027. Financial institutions should align their EUDI Wallet integration planning with AMLR readiness, since both timelines converge in the second half of 2027.
The private sector acceptance obligation under article 5f applies to banks and financial services from 24 December 2027, covering contexts where strong user authentication is legally or contractually required. Micro and small enterprises with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros are exempt.
What are the main challenges of combining EUDI Wallet and bank ID authentication?
The main challenges fall into three areas: technical interoperability, process alignment, and regulatory coordination. None of them is insurmountable, but each requires deliberate planning rather than a last-minute integration effort.
Technical interoperability
Bank ID systems were built for national ecosystems with specific protocols and trust models. Adding EUDI Wallet support means implementing new credential formats (mdoc and SD-JWT VC), new exchange protocols (OID4VP, OID4VCI), and the three-step verification process against trusted lists, revocation endpoints, and wallet unit attestations. Existing authentication middleware may not support these out of the box, requiring updates or a new integration layer.
Process and data model alignment
Bank ID authentication confirms a session; EUDI Wallet verification delivers identity attributes. Mapping those attributes to existing customer records, KYC files, and onboarding workflows requires careful data model work. As noted above, customer records must be linked to stable identity attributes rather than wallet unit identifiers, because the same person may present with a different wallet unit after switching devices.
Regulatory and timeline coordination
The EUDI Wallet framework, the AMLR, and existing strong customer authentication requirements under PSD2 all have different timelines and different rule-setters. Aligning compliance work across these frameworks, while also tracking the implementation status of national wallets (which varies significantly between Member States), adds coordination complexity that purely technical integration work does not capture.
When should companies start preparing for EUDI Wallet integration?
Financial services organizations should start preparing now. The public sector acceptance deadline of 24 December 2026 requires every Member State to have issued at least one certified EUDI Wallet and public services to accept it. The private sector deadline of 24 December 2027 follows twelve months later, covering banks and financial services wherever strong authentication is legally or contractually required.
That may sound like enough runway, but the registration process under CIR (EU) 2025/848 takes time, technical integration and testing add further lead time, and the AMLR applies from July 2027, creating a compliance convergence point well before the December 2027 deadline. Organizations that wait until late 2027 will be integrating under time pressure while simultaneously managing AMLR readiness.
A practical starting point is to map which of your services require strong authentication and therefore fall within the scope of article 5f. From there, the registration process, attribute scope definition, and technical integration can be sequenced. National sandboxes and the open-source reference implementation of the EUDI Wallet are available for testing without waiting for production wallets to be widely deployed across all Member States.
The implementation landscape is uneven: some Member States are running national wallets in production and marking them as EUDI-conformant, others have limited beta programmes, and a third group has not published a rollout plan. Build your integration to accept any certified wallet from any Member State rather than targeting a single national implementation.
How TrustTech helps with EUDI Wallet and bank ID integration
The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
For financial services organizations combining EUDI Wallet verification with existing bank ID flows, the ID Connector handles the following concretely:
- Verification of issuer signatures against national trusted lists and the EU List of Trusted Lists (LOTL)
- Revocation status checks for presented attestations
- Validation of wallet unit attestations to confirm the presenting wallet runs on a certified wallet solution
- Enforcement of your registered attribute scope, so requests stay within what you declared under CIR (EU) 2025/848
- Reuse of verified identity data across interactions, without requiring the user to re-present attributes for every session
The ID Connector is used by organizations in financial services, government, healthcare, and pharmaceuticals. If you want to see how it connects to your current authentication setup, get in touch with TrustTech.