Minimum compliance is the most expensive EUDI Wallet strategy for Financial Services
Most financial services organizations I talk with see eIDAS and the EUDI Wallet primarily as a compliance item. At face value, that is understandable. Financial services is one of the sectors that must use strong user authentication, by law or by contract, and so must accept the wallet when a customer chooses it. For banks the obligation is clear, and many insurers and credit companies will find themselves in scope as well.
The compliance cost is real, and I won't pretend otherwise. But look at the bigger picture and the same effort can carry a good deal more than the eIDAS obligation.
Here is my core argument: comply with minimum effort now, and you pay again with every regulation that follows. Instead of building something, you rebuild the same capability one obligation at a time.
Why? Let me explain…
The wallet ecosystem is an asset in itself
The EUDI Wallet ecosystem (as a whole, not just the wallet) is designed as a building block in the EU Digital infrastructure. It is a generic, reusable, shared asset, which can be used by public and private sector for various purposes. It is designed to solve cross-border authentication and mutual recognition of attestations, which have previously been hard and out of reach for many.
Today, every authentication solution has to prove its compliance on its own: against national rules, against scheme rules, and once you go cross-border, against rules that are rarely clear. The EUDI Wallet is certified once, at assurance level high, and recognized in every member state.
That changes your starting point. Instead of proving that your own solution is good enough, you rely on one whose assurance is already established in law and is approved by default.
Five EU regulations that build on the EUDI Wallet
The regulations coming your way build on the same foundation, and in financial services the list is long:
eIDAS 2.0: from 24 December 2027, FSI organisations accept the wallet for strong user authentication in online services when a customer chooses it.
AMLR: applies from 10 July 2027. Includes electronic identification means, the wallet included, for remote customer due diligence; with additional benefits from use of Wallet carried attestations.
PSD3 and the PSR: once formally adopted, they will tighten the current strong customer authentication requirements. The EUDI rulebook work in European Payment Council's SCARLET initiative (Strong Customer Authentication Acceptance Rulebook and Liablity Framework for EUDIW Transactions) will describe how a bank carries payment authentication in the wallet.
European Business Wallet: proposed as a regulation of its own, built on the EUDI Wallet framework. It would carry company identity and mandates into corporate KYC.
Digital euro: Although not necessarily relevant for all banks, the Commission's proposal links digital euro services to the EUDI Wallet.
Each of the above asks for identification, authentication or verified data at a level the wallet is built to provide. The reason it keeps turning up is simple: it is the only means of secure identification that every member state must, by law, offer to all its citizens and residents, free of charge.
One investment, four ways to use it
There are at least four approaches you can take:
Minimum compliance: accept the wallet because the law says so, and nothing more.
Cost efficiency: make the wallet a first-class authentication option and let it take over authentication you currently buy from others.
Process optimization: redesign onboarding and other processes around the identity, attestations and signatures the wallet carries.
Strategic asset: rely on the wallet, issue into it, and take part in the ecosystems built on top. Build on top of the shared identity infrastructure instead of building your own.
These could be considered as a maturity ladder, but I think it’s more useful to treat them as returns on one investment.
Whether you build or buy, becoming a relying party carries a fixed cost: registration, deciding what you request and why, updating onboarding and fraud procedures, supporting the customers who use it. You pay it whichever approach you choose. Every additional use you route through it improves the return.
Minimum compliance serves only the occasional customer who asks. That is why it is the most expensive option: you pay the full cost and collect almost none of the return. And when the next regulation arrives, you pay again, because nothing you built was designed to carry it. It is like laying a rail track to your warehouse because regulation requires it, and then running nothing on it.
Some will say the fixed cost is small, because their current provider will simply add the wallet as one more login option. That may well happen, and it is a sensible way to integrate. Yes, it makes compliance cheaper. It does nothing for the return, or for the next wave of regulation.
EUDI Wallet vs Nordic bank IDs
Coming from the Nordics, I've spoken with many experts, and the usual discussion for EUDI adoption is that we've already solved authentication. Our bank IDs and the Finnish Trust Network (FTN) carry the bulk of strong electronic identification, and it's working very well. Why add another channel?
Because the wallet carries more than a login. A bank ID tells you who someone is. The wallet can also tell you what is true about them, from public and private issuers, with a qualified signature in the same flow, and it does that across borders. Bank IDs were built for authentication within one country, and they do that job well.
My personal view is that bank IDs will continue existing still for years, and then gradually start to fade away. Customers will set the pace, since using the wallet is voluntary, so there will be a period of running both. That does not hold back the returns. Each of them pays per customer who uses the wallet. None of them needs the wallet to overtake existing authentication first.
What this means for you
If you are the one responsible for EUDI adoption, start from the return, not the obligation. This is a foundational change across the EU, and not all of its effects on your industry are visible yet. A more level playing field brings new players and new services, built on resources that are now open to everyone. Including you.
Decide early whether you integrate through a broker, a partner or your own team, and make sure the setup can issue as well as verify later. Pick one onboarding flow, ideally one with cross-border customers, and one process where verified attestations would remove manual work. If you are a bank, pick one attestation you could issue.
None of this needs a large programme. It needs the compliance project to be designed as the first step of something.
At Veridient we help organisations work out how they can get the best out of the EUDI adoption, and how they should prepare for the long-term change. If you'd like to think yours through, book a meeting with us.
If you are laying the track anyway, what will you run on it?
Frequently asked questions
Is the EUDI Wallet mandatory for banks?
Accepting it is. Organisations that must use strong user authentication by law or by contract, banks included, must accept the wallet when a customer chooses to use it. Using the wallet stays voluntary for customers.
When must banks accept the EUDI Wallet?
From 24 December 2027. Member states must make at least one wallet available by 24 December 2026.
Does AMLR require the EUDI Wallet?
No. AMLR, applicable from 10 July 2027, recognises electronic identification means, the wallet included, for remote customer due diligence. It does not make the wallet the only option, but it makes the wallet a ready-made route to compliant onboarding.
Does eIDAS require PSPs to accept EUDI Wallets for payment authorization as well?
No. The eIDAS Article 5f(2) applies to strong user authentication “for online identification”. eIDAS defines strong user authentication without dynamic linking, which PSD2 requires for payments. So payment authorisation isn’t covered by the wording in eIDAS. By the letter of the regulation, it isn’t currently binding for payment authorisation.
Comments