EU Digital Identity Wallet and Payment Services Directive Alignment

The integration of the EU Digital Identity Wallet (EUDI Wallet) under the eIDAS 2.0 framework (Regulation EU 2024/1183) with European payments infrastructure represents a foundational shift in digital identity and financial transactions.

While Article 5f(2) of eIDAS 2.0 mandates Payment Service Providers (PSPs) and relying parties subject to Strong Customer Authentication (SCA) to accept certified EUDI Wallets by 24 December 2027, it introduces structural friction when mapped against the rigorous SCA and liability requirements of the Payment Services Directive framework (PSD2/PSD3/PSR).

Strategic Alignment: Where the Frameworks Converge

At a macro level, both the eIDAS 2.0 framework (Regulation EU 2024/1183) and the PSD2 Regulatory Technical Standards (RTS – Commission Delegated Regulation 2018/389) seek to secure digital interactions and align on foundational security principles:

• Two-Factor Authentication Core: Article 4 of the RTS requires Strong Customer Authentication (SCA) to combine two or more independent elements categorized as Knowledge (PIN/passcode), Possession (device/token), and Inherence (biometrics). The EUDI Wallet is architected around a Wallet Secure Cryptographic Device (WSCD) residing in secure enclave hardware. The cryptographic keys bound to this enclave definitively satisfy the legal threshold for the Possession factor, while user authorization mechanisms provide the second factor.

• High Level of Assurance (LoA High): eIDAS 2.0 mandates that national EUDI Wallets achieve an Assurance Level of "High." The rigor required to issue Person Identification Data (PID) at this level aligns with the strictest verification benchmarks under PSD2/PSD3 and the EU Anti-Money Laundering framework (AMLR), standardising Know Your Customer (KYC) onboarding across Europe.

• Harmonised Cross-Border Acceptance: While PSD2 unified the EU payments market, cross-border authentication remained fragmented across proprietary banking applications and regional electronic ID schemes (e.g. BankID, SPID). The EUDI Wallet replaces this fragmentation with a standardised, interoperable protocol stack across all EU Member States, reducing integration overhead for operating across borders.

Framework Divergence and Operational Friction

The friction stems from fundamentally different design philosophies: PSD2 was engineered for a closed, bilateral relationship between a bank and its customer, whereas eIDAS 2.0 establishes an open, federated identity ecosystem relying on third-party state infrastructure.

Specific Friction Points

• The Dynamic Linking Dilemma (Article 5 RTS): Article 5 of the RTS mandates that remote payments generate an authentication code dynamically linked to the exact amount and payee, where any alteration invalidates the code. A standard digital identity presentation flow via the Wallet only confirms who the user is, not what they are authorising. While Technical Specification TS12 establishes wallet-based SCA presentation mechanisms, residual risks persist regarding full payload context binding on multi-purpose device OSs.

• Transaction Monitoring vs. Data Minimisation: Under Article 2 of the RTS, PSPs must perform real-time risk scoring using session telemetry. However, eIDAS 2.0 is built on privacy-by-design and zero-knowledge proofs. If the Wallet strips out device telemetry and behavioural identifiers before routing to the PSP, financial institutions are left blind to the risk context, neutralising their mandated Transaction Risk Analysis (TRA) systems.

• The Liability Shift: When authenticating via a proprietary banking app, a bank controls mobile application hardening, jailbreak detection, and credential lifecycles. Under eIDAS 2.0 Article 5f(2), PSPs are mandated to accept valid assertions from certified Wallets. If a state-issued wallet or device OS suffers a vulnerability, the PSP carries the strict financial liability for the resulting fraud without possessing operational control over the authenticator.

Risks of Omitting Biometric Authentication in Assertion Flows

The assertion flow is the cryptographic exchange where the Wallet verifies the user locally and transmits a signed statement to the PSP. European banking authorities have highlighted critical operational and systemic vulnerabilities when assertion flows rely solely on knowledge factors (PINs) or device possession without mandatory biometric inherence:

• Neutralising "Shoulder Surfing": Mobile payment fraud frequently combines visual surveillance and physical theft. If an assertion flow permits authentication via a PIN alone, an attacker who observes the PIN and steals the physical device gains unilateral access to drain accounts. Biometric liveness ensures physiological presence is mandatory.

• OS Passcode Fallback Risks: Standard mobile OS biometrics frequently fall back to the device PIN upon failure and allow multiple individuals to register fingerprints on the same device. Relying on simple OS-level unlock status – without cryptographic binding generated inside an isolated enclave exclusively tied to the account holder's specific biometric – creates massive compliance and security vulnerabilities.

• Defeating Headless Malware: Mobile banking trojans frequently abuse OS Accessibility Services to capture screens and automate background actions. A PIN-only Wallet flow allows these trojans to silently approve payment assertions in the background. Hardware-backed biometrics require physical sensory input (e.g. infrared depth map or live scan) that cannot be synthesised remotely.

• Legal Evidentiary Chain: Under PSD2 dispute rules, the burden of proof rests on the PSP to demonstrate an uncompromised authentication. An assertion signed solely by a PIN does not provide non-repudiable proof of who held the device. Biometric cryptographic proofs provide the necessary evidentiary foundation required to rebut "friendly fraud" claims.

Architectural Solution: Proof of Presence

To resolve the tension between eIDAS 2.0 identity assertions and PSD2/3 transaction liability without introducing universal checkout friction, the EUDI Wallet can support a conditional, risk-based Proof of Presence (PoP) credential. Rather than being executed on every low-risk micro-transaction, PoP is requested dynamically by the PSP's Transaction Risk Analysis (TRA) engine when high-value transfers, high-risk scenarios, or anomaly flags warrant elevated assurance.

The PoP credential can be issued as either a non-qualified Electronic Attribute Attestation (EAA) or a Qualified Electronic Attribute Attestation (QEAA), depending on the commercial and trust relationship between the biometric vendor and the PSP.

How the Proposed Flow Works

1. Verification Request: Upon evaluating transaction risk, the PSP (acting as a Verifier) prompts the EUDI Wallet for payment authorisation containing mandatory transaction details (amount and payee) together with a requested PoP credential.

2. Payment Authorisation Callout: The wallet routes the payload to a Trust Service Provider (TSP) or Qualified Trust Service Provider (QTSP) with whom the PSP holds a commercial relationship to generate a compliant payment authorization.

3. Biometric Verification Callout: With explicit user consent, the wallet contacts an accredited biometric vendor, supplying a verified reference portrait extracted from the holder's PID or an existing QEAA (e.g. mDL or ePassport).

4. Liveness and Likeness Check: The biometric vendor runs real-time liveness and face-matching checks aligned with international standards:

   1. • ETSI TS 119 461: Policy and security requirements for trust service components assessing identity verification and liveness detection.

      • ISO/IEC 30107-3 / ETSI EN 319 401: Presentation Attack Detection (PAD) standards to defeat deepfakes, injection attacks, and printed masks.

5. Credential Issuance & Return: Upon successful verification, the biometric vendor issues a short-lived PoP credential as an EAA or QEAA (valid for e.g. 5 minutes). The wallet cryptographically binds this PoP to the payment authorization and returns both to the PSP in a single presentation payload.

Qualified (QEAA) vs Non-Qualified (EAA) in Bilateral PSP Relationships

When the relationship between the biometric vendor and the PSP is bilateral (direct commercial agreement), the choice between issuing a Qualified EAA (QEAA) or a non-qualified EAA comes with distinct operational and legal trade-offs:

Why This Solves the Core Friction Points

This architectural model aligns directly with the European Payments Council (EPC) SCARLET initiative (Strong Customer Authentication Acceptance Rulebook and Liability Framework for EUDIW Transactions), approved on 24 September 2026. As the payments industry prepares for mandatory wallet acceptance under eIDAS 2.0 Article 5f(2) by 24 December 2027, the SCARLET framework provides the commercial rulebook, operational SLAs, and liability allocation rules required across European PSPs.

Integrating the PoP (Q)EAA specification into the emerging SCARLET architecture provides the industry with a standardised, ETSI-compliant evidentiary artifact.