Cutover OS for mid-tier European banks to launch EUDI wallet flows with post-quantum step-up auth and AI-fraud-safe recovery.

1. European Digital Identity Wallet rollout turns wallet capability into a near-term bank launch program instead of a vague standards roadmap.
2. AI-enabled identity fraud is shifting authentication budgets toward safer recovery and step-up controls, so banks have immediate fraud ROI rather than only future compliance value.
3. Government and industry post-quantum timelines mean banks must identify brittle signing and authentication dependencies before wallet launches harden them into production.
4. Banks in more than 25 countries already buy specialized post-quantum and digital-identity software, which lowers the adoption barrier for a vendor-led cutover layer.

Catalyst. Wultra's round shows banks are already funding wallet capability because EUDI rollout, AI-enabled identity fraud, and post-quantum migration timelines are colliding now.

The product connects to a bank's mobile-auth stack, identity-proofing vendors, HSM or signing infrastructure, fraud engine, and wallet program backlog to map every step that will break or slow down a wallet launch. It creates a cutover plan for specific journeys—onboarding, account recovery, and high-value payment step-up—showing which components need PQ-safe signing, stronger device binding, or different escalation logic before launch. Teams get a test harness that replays synthetic fraud and recovery scenarios against proposed wallet flows and produces evidence packs for security, risk, and regulator-facing review. The first release wins by compressing months of cross-vendor discovery and manual project management into a single approval-ready program for one bank and one journey. Over time, the company becomes the control layer banks use whenever they add new wallet credentials, relying parties, or cryptographic standards.

What's different. Wallet SDK vendors help banks ship features, and incumbent MFA vendors secure one control point, but neither owns the cross-vendor cutover across recovery, device binding, signing, and audit evidence. Consulting firms can manage the program, yet they do not leave behind a living dependency graph, reusable test harness, or continuous crypto-agility layer. That makes the product both a faster launch tool today and a durable control plane for the next wave of identity changes.

Jobs to be done

flowchart LR
  Buyer[Bank identity lead] --> Pain[Wallet launch blocked by fraud and crypto cutover risk]
  Pain --> Product[Wallet auth cutover OS]
  Product --> Outcome[Faster launch with safer recovery and PQ-ready authentication]

Executive takeaways

• The strongest wedge is a bank-side cutover and evidence layer, not another wallet, MFA token, or cryptography SDK.
• Urgency is real because wallet rollout, deepfake fraud, and post-quantum planning are colliding in the same bank journeys.
• Competition is crowded at the control-point level, but no obvious vendor owns cross-vendor dependency mapping, dual-stack rollout, and launch evidence.
• The beachhead should stay narrow: one bank, one journey, one approval packet, starting with account opening, login, or high-value payment approval.

Market definition

Software for European retail banks that inventories authentication and wallet dependencies, stages a dual-stack cutover, pressure-tests recovery and step-up flows, and generates approval-ready evidence for EUDI-related launches.

Customer and buyer

Primary users are heads of digital identity and authentication, mobile-banking security leads, and fraud teams at mid-tier European retail banks. The economic buyer is usually the CISO or chief digital officer, with digital-channel and payments leaders as strong technical sponsors.

Buying triggers

• Wallet rollout has moved from standards work into bank-facing launch planning, with service-provider workflows, pilots, and account-opening use cases now concrete enough to trigger programs. [1][2][3][6][7]
• Banks are being pushed to prepare for wallet-based strong customer authentication, turning login and transaction approval into a near-term platform decision rather than a distant policy watch item. [9][10]
• Deepfake-driven identity fraud and account-takeover pressure make recovery and authentication controls easier to fund than compliance-only projects. [16][20][21][22]
• Post-quantum guidance has become phased migration planning, which forces earlier mapping of cryptographic dependencies inside authentication stacks. [23][24][28][29]

Willingness to pay

Willingness to pay is credible because banks already fund specialist identity vendors, and the wallet business-case evidence points to lower onboarding and authentication costs plus better risk management as a practical ROI story. [11][12][17][30]

Category dynamics

Growth signal Deepfake fraud share up 2,137% over three years

Validation signals

• Large Scale Pilots involve 550 private companies and public authorities across 26 Member States plus Norway, Iceland, and Ukraine, including explicit payments and banking use cases.
• POTENTIAL includes bank account opening as a core wallet use case, confirming that private-sector onboarding is a real deployment target rather than a theoretical scenario.
• NOBID tested wallet onboarding, bank account linking, and online-store payments across multiple stakeholders, showing practical coordination complexity.
• Wultra says it serves more than 70 clients across 25 countries and raised fresh capital around wallet, fraud, and post-quantum demand.
• Signicat reports a steep rise in deepfake-driven identity fraud, which gives banks a non-compliance budget justification for stronger authentication and recovery controls.

Regulatory & technical constraints

• Wallet-relying service providers must register in their Member State and handle PID and attestation validation correctly before production use.
• Remote onboarding, protocols/interfaces, relying-party registration, and trust-framework implementing acts all affect launch design and can change over time.
• Wallet-based SCA depends on standards-aligned device-bound keys, attestation handling, and interoperable interfaces rather than simple UI changes.
• Post-quantum migration requires cryptographic inventory and phased upgrades, so banks need sequencing that fits existing authentication estates.

Competition is fragmented by layer. Wallet hubs and identity-proofing vendors help banks connect to EUDI flows; mobile authenticator and transaction-signing vendors secure specific control points; fraud platforms improve runtime decisions. The whitespace is a neutral bank-side workflow that maps cross-vendor breakpoints, stages the cutover, and packages evidence for risk, security, and launch approval.

Why incumbents do not win by default

• Mobile authentication and transaction-signing vendors. These vendors secure login and payment approval well, but they do not automatically become the cross-vendor program layer that inventories every dependency and prepares the launch packet.
• Identity hubs and wallet orchestration suites. Identity hubs can connect banks to wallet and eID methods, but they are not positioned as brownfield cutover systems for recovery, device binding, and crypto-agility across mixed stacks.
• Fraud and risk-auth platforms. Risk-aware authentication platforms help block attacks at runtime, yet they still leave banks to coordinate rollout sequencing, recovery redesign, and audit evidence across multiple suppliers.
• Consultants and internal program offices. Pilots and business-case work show that cross-organisation coordination is necessary, but project management alone does not leave behind a reusable dependency graph, test harness, or continuous control layer.

Wallet Auth Cutover OS should launch as a bank-side cutover and evidence layer for EUDI-related authentication changes, not as another consumer wallet, MFA app, or cryptography SDK. The first customer is a Czech, Slovak, or Austrian retail bank with 1-3 million mobile customers, existing app-based soft-token authentication, and a funded 2026-2027 wallet or digital-ID program. Budget is most likely to release when a wallet pilot, a fraud review after a deepfake or account-takeover spike, or a board-level post-quantum workstream exposes cross-vendor dependencies across mobile auth, fraud, IAM, and signing systems. The initial product should stay read-only and focus on one journey—account recovery first, with high-value payment step-up as the immediate expansion path—by mapping dependencies, simulating attack and fallback paths, and generating an approval packet for risk and security sign-off. Research supports real urgency and specialist-software spend, but the modeled base market is still narrow at about $217.5M TAM, $22.5M SAM, and $4.5M year-3 SOM before adjacent expansion. The best scale path is to turn each launch packet into recurring crypto-agility monitoring, relying-party policy controls, and additional wallet-auth journeys inside the same bank. The biggest disconfirming risks are regulatory timing drift, incumbent or integrator compression, and whether banks will fund a neutral cutover layer instead of extending existing programs. Public inputs do not identify named target banks, exact budget owners, or whether recovery reliably beats payment approval as the first paid journey, so the first 6-9 months must prove buyer ownership, deployment speed, and paid cutover conversion.

Problem

• Mid-tier European banks must change wallet onboarding, recovery, device binding, and step-up authentication while EUDI rollout, deepfake fraud, and post-quantum migration all hit the same stack.
• Those changes span mobile-banking teams, IAM, fraud ops, HSM or signing vendors, wallet providers, and integrators, so banks lack a single workflow that finds breakpoints, sequences the cutover, and produces audit-ready launch evidence.

Solution

• Connect read-only to the bank's mobile-auth, fraud, wallet, and signing stack to build a dependency graph for one named journey, starting with account recovery, and generate a dual-stack cutover plan that shows where stronger device binding, PQ-safe signing, or fallback logic is required.
• Replay synthetic fraud and recovery scenarios against the planned journey and package the results into an approval packet for security, risk, compliance, and launch stakeholders so the bank can approve production without replacing incumbent systems.

Why we win

• The company owns the neutral cross-vendor cutover and evidence layer that wallet vendors, MFA providers, fraud tools, and consultants do not leave behind today.
• The first deal is attached to a named launch program and one approval packet, which is a faster proof point than asking banks to buy a bank-wide identity transformation upfront.
• Each deployment compounds a reusable graph of dependencies, control gaps, simulation outcomes, and approval artifacts that improves expansion and is hard for any single incumbent to recreate across mixed stacks.

Milestones

flowchart LR
  Wedge[Account-recovery cutover wedge] --> MVP[Read-only dependency map and evidence MVP]
  MVP --> Proof[Approval packet accepted and launch accelerated]
  Proof --> Expansion[More journeys plus recurring crypto-agility control layer]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least half of qualified target banks must have a named wallet or SCA launch with budget and an accountable sponsor inside 12 months.
• Account recovery must repeatedly win the first paid scope over login, account opening, or payment approval in early buyer discovery.
• The product must deliver an approval-ready dependency map and evidence packet in 60 days or less on the first common stack.
• At least 3 of the first 5 paid cutovers must convert to annual subscriptions above $400k ARR.
• The neutral cutover layer must beat incumbent-vendor or SI-led alternatives in at least 40% of competitive evaluations.

Open diligence questions

• Which first journey consistently releases budget fastest in target accounts: account recovery, payment approval, login, or onboarding?
• Which executive actually controls the budget for wallet-auth cutover in the beachhead: CISO, chief digital officer, fraud lead, or payments owner?
• Which vendor stack combinations dominate the first 20 target banks and therefore determine integration order?
• What evidence, simulation output, and governance artifacts are required for a bank to treat the approval packet as launch-ready?
• Can incumbent vendors and regional integrators be turned into channels before they use their installed base to compress the category?

Model sanity

• Revenue engine. Base-case revenue comes from moving from 3 paid banks at Y1 exit to 5 production logos at Y2 exit and 6 live banks at Y3 exit at about $720K of blended annual spend per bank-year.
• Must go right. The company has to keep the first common-stack deployments near the 60-day target so it can reach 5 production logos before adding much more delivery headcount.
• Model breaks if. If the business slips toward the downside case of 5 Y3 banks, $680K ARPU, and 68% gross margin, cash turns slightly negative before the next round.
• Next-round proof. The seed narrative is credible once 5 production logos, 2 partner-sourced deployments, and the first payment step-up expansion are live with a visible cash buffer still on the balance sheet.

Scenarios

Sensitivity

flowchart LR
  TargetBanks --> PaidCutovers
  PaidCutovers --> ProductionBanks
  ProductionBanks --> ExpansionJourneys
  ProductionBanks --> Revenue
  ExpansionJourneys --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: The base case still concentrates more than $4.1M of Y3 revenue into only 6 bank customers, so one delayed expansion or non-renewal matters a lot. · CAC is high at about $438K per new production logo because founder-led bank sales, partner enablement, and procurement overhead remain heavy. · Gross margin only holds at 70% if connector reuse and approval-packet templating prevent the company from drifting into bespoke services work. · The funding ask is only at the low end of the business-plan range, and the downside case still turns cash slightly negative before the next round.

• Regulatory timing drift. Country-by-country wallet rollout dates may slip, stretching sales cycles if the product depends only on compliance deadlines. Mitigation: Start with banks that already have funded launch programs and sell fraud-safe recovery plus faster approval as the first ROI, not compliance alone.
• Incumbent and integrator squeeze. Existing authentication vendors or systems integrators may claim they can extend current projects to cover the same workflow. Mitigation: Position as the cross-vendor cutover and evidence layer that complements incumbents, and prove value by reducing launch time across mixed stacks they do not unify.
• Integration liability. Touching identity and recovery infrastructure can create long deployments and high trust barriers for a young startup. Mitigation: Launch with read-only discovery, testing, and evidence generation for one journey before taking on inline orchestration or credential-sensitive controls.