As Europe moves closer to rolling out the European Digital Identity Wallet, questions are shifting from if to how, and what this really means for banking, payments, and trust online.
In a recent live webinar, we explored these questions with Marie Austenaa, Payment Domain Lead for the EUDI Large Scale Pilots and Head of Digital Identity at Visa. Drawing on her experience across EU policy, large-scale pilots, and global payment networks, Marie offered a grounded, practitioner’s view on where the EUDI wallet creates real value for banks and payment providers, and where the hard work still lies.
The conversation covered everything from account opening and cross-border payments to fraud reduction, privacy safeguards, ecosystem design, and the emerging role of AI agents in digital commerce. Below are the key insights and takeaways from that discussion.
Why the EUDI Wallet is a “present on a silver plate” for banks
- A government-issued, high-assurance identity credential becomes “online-native”
- The wallet holds a verified identity credential issued by a Member State.
- That credential is verifiable at high assurance and has legal equivalence to showing a passport in a branch (in Marie’s framing).
- It de-risks the hardest part of banking: regulated identity proofing
- Account opening is foundational, high-risk, and tightly tied to AML obligations.
- Cross-border onboarding is especially painful today because processes and interpretations differ by country.
- A harmonized EU approach reduces fragmentation
- Same standards + same assurance level across Europe, with Member States responsible for identity accuracy.
- The wallet is positioned as becoming an accepted method for identity verification under the evolving AML framework.
The big banking & payments use cases Marie expects to benefit first
- Account opening and contract signing
- Onboarding with a trusted digital identity flow (PIN/Face ID + verified credential presentation).
- Signing legally binding agreements (open account, request a new card, apply for a loan).
- Login and step-up authentication
- Reducing dependence on passwords, OTP apps, and SMS OTP.
- Using the wallet to confirm sensitive changes (e.g., address change) or new product actions (e.g., mortgage agreement).
- Proofs beyond identity
- Selective disclosure proofs like “over 18” rather than sharing full DOB.
- Eligibility proofs (e.g., student status for discounts).
- Direct debit setup and payment-related verification
- Confirming a new direct debit or authorizing one-off transactions with higher confidence.
- Verifying that an IBAN/account belongs to the intended recipient to reduce social-engineering-driven misdirected payments.
Cross-border impact: where the wallet could change the “shape” of EU banking
- Cross-border expansion becomes more feasible
- If onboarding is more uniform and trusted, banks/fintechs can enter new EU markets with less process rework.
- Marie speculates this could increase cross-border competition and consolidation dynamics.
- Cross-border payments become less scary for consumers (and less risky for banks)
- Marie’s example: banks currently add heavy friction (even discouragement) to prevent irreversible fraud.
- With wallet-based verification, banks can more confidently confirm:
- the payer’s intent (authentication / signing),
- and the payee’s identity (recipient validation), without requiring bespoke bank-to-bank integrations.
Fraud reduction: strong foundations, but not “magic”
- Why fraud should drop
- Cryptographic proof and strong onboarding to the wallet can create a higher-integrity “starting point.”
- Marie references Norway’s experience (BankID + wallet flows) as indicative of lower fraud when identity is strong and consistent.
- Why it won’t solve everything
- Fraud moves to other attack vectors; integrity must be maintained.
- Ongoing needs:
- monitoring for anomalies and risky behavior,
- continuous integrity checks,
- strong issuance processes so the identity credential goes to the rightful holder.
- Regulatory motivation is explicitly tied to fraud + single market goals
- The wallet is framed as a tool to reduce fraud and make cross-border digital business easier across Europe.
Privacy & “Big Brother” concerns: the guardrails Marie emphasizes
- The core risk is oversharing becoming too easy
- If sharing becomes “Face ID + tap,” the temptation to request more data increases.
- Guardrail 1: relying parties must have a legitimate reason
- Merchants/verifiers should only request data they can justify as necessary (not just for marketing/personalization).
- Guardrail 2: relying parties must be known and registered
- Verifiers are expected to be registered in a trust framework/trust list context.
- Guardrail 3: mutual authentication
- The verifier proves who they are to the wallet.
- The wallet checks if the verifier is legitimate and entitled to request that data.
- Guardrail 4: selective disclosure
- Share only what’s required (e.g., “over 18”), not full identity attributes.
- Open question / risk
- The “cookie banner problem”: consent fatigue where users click through without meaningful choice.
- Success depends on UX that preserves real choice without blocking legitimate business flows.
Timelines: “the train is in motion,” but readiness is uneven
- Stated obligations
- Member States: wallet availability + ability to request an identity credential by end of year.
- Relying parties (banks, merchants, large platforms): acceptance/ability to rely on wallets roughly 12 months later for core use cases (login/account opening, etc.)
- Marie’s assessment
- She is worried the deadlines won’t be met uniformly.
- She sees intense activity across governments; some will be later (example mentioned: Germany aiming later), others moving faster (example mentioned: Poland iterating).
- Bottom line
- It’s “when, not if,” but not everyone will hit the same date.
What banks must do to be ready
- Decide where to focus and “embrace the opportunity”
- Choose initial use cases (account opening and login are the likely first wave).
- Change business processes (often harder than the tech)
- Accept wallet-based identity verification as an official path.
- Integrate wallet flows into mortgage signing, account changes, higher-risk step-ups, etc.
- Modernize around legacy constraints
- Wallet integration lands in an environment with old infrastructure and multiple concurrent regulatory pressures.
- Prepare for risk model changes
- Determine what wallet-derived signals mean for:
- risk scoring,
- fraud operations,
- compliance and audit expectations.
- Determine what wallet-derived signals mean for:
- Aim for synergies
- Marie hopes for alignment with payment regulation work (e.g., upcoming requirements) so compliance efforts reinforce each other.
“Trust at scale” lesson from global payment networks
- Payments succeeded because they operationalized trust, not just technology
- Standards are implemented, tested, and certified across thousands of providers.
- Rules are enforced and monitored for compliance.
- Always-on infrastructure + fraud ops are part of the product
- High-availability requirements, abnormality detection, and ecosystem-wide monitoring.
- User protection is crucial
- Refund/recourse mechanisms are what make users comfortable transacting.
- Predictable UX matters
- Fast, repeatable, low-friction interaction (tap / Face ID / passkeys).
- Identity ecosystems need the same mindset
- Wallets won’t succeed by “shipping an app” alone.
- They need standards + governance + monitoring + recourse + consistent UX.
AI agents & agentic commerce: identity and delegation become the hard problem
- The core trust questions
- How do you know an agent is acting on your behalf?
- How do you prove it acted within your intent and mandate?
- How do you establish trust when agent-to-agent interactions happen (consumer agent ↔ merchant agent)?
- Why wallets/credentials matter here
- Similar mechanics to mutual authentication:
- Who is the relying party / agent on the other end?
- Are they entitled to request data or execute a transaction?
- Cryptographic proof is positioned as a way to reduce “fakeable” claims.
- Similar mechanics to mutual authentication:
- Agents likely need distinct identities
- Marie argues agents should be identifiable and clearly linked to whoever is responsible.
- Distinction matters for accountability and liability attribution.
- Delegation must be explicit and bounded
- Examples discussed:
- spend limits (e.g., €50),
- merchant/category constraints,
- time constraints,
- clearly defined mandate to enable autonomy without constant human presence.
- Examples discussed:
- Liability models don’t “break,” but they get harder
- Refund/recourse can still exist, but figuring out fault becomes more complex:
- Did the agent exceed authority?
- Did the user specify poorly?
- Did the merchant mis-handle the interaction?
- Refund/recourse can still exist, but figuring out fault becomes more complex:
Audience Q&A: what it revealed about payments implementation details
- Does the wallet provider need to be a PISP to trigger payments?
- Marie’s view: the wallet holds payment credentials; initiation can happen via a PISP role—wallet as credential container rather than the initiating regulated entity.
- Fraud liability if the wallet performs SCA instead of the bank
- The model discussed:
- the bank issues the authentication credential that lives in the wallet,
- the wallet presents it,
- the bank makes the final decision and retains liability.
- This is framed as a way to avoid “delegating authentication” to the wallet as a regulated outsource.
- Caveat noted: final regulatory alignment still needs confirmation (e.g., supervisory interpretation).
- The model discussed:
- Can the EUDI wallet become a payment initiation tool directly?
- They are experimenting with:
- holding card credentials / IBAN credentials,
- presenting to merchants,
- and routing through the payment ecosystem for settlement.
- Not impossible, but requires standards + acceptance + technical work.
- They are experimenting with:
- How much control do users have vs. merchant requests?
- Principle: selective disclosure + “ask only what’s necessary.”
- Merchants are expected to justify data requests; operational details are still being defined.
- Will banks become QTSPs?
- Marie’s expectation: many banks may rely on partners rather than become QTSPs themselves due to audit/compliance overhead.
- Some credential types may not require “qualified” status if other safeguards and rules are sufficient, but this depends on use case and assurance needs.
