The most challenging aspect of preparing for eIDAS 2.0 is not the technical complexity itself — it is recognising that the decision is not primarily a technical one at all. For digital identity product teams, the build vs partner question is fundamentally a product strategy call, and one that should be made well before engineering has begun any scoping exercise.
According to Hopae, AML-R and eIDAS 2.0 are on the radar for most identity product teams. The more pressing question is whether their products will be ready when enterprise clients come looking — and that moment may arrive sooner than anticipated.
Hopae recently discussed the build vs. partner decision that every digital identity product team is facing.
The July and December 2027 deadlines for AML-R and eIDAS 2.0 respectively may appear distant, but building compliant support for eID-based verification from scratch typically requires 18 to 24 months. That timeline does not account for the added complexity of connecting to 27 different EU member state trust registries, each carrying its own technical requirements, credential formats, and accreditation processes. For any team whose roadmap has not already scoped and resourced this, the uncomfortable reality is that they are not ahead of the deadlines — they are already behind them.
This is not just a European problem
A common and costly assumption among identity product teams is that AML-R and eIDAS 2.0 are European regulations affecting only European businesses. That assumption does not hold. The majority of enterprise clients in banking, FinTech, crypto, telecom, and payments operate across Europe. By December 2027, those businesses will be legally required to accept EUDI Wallet-based identification and will expect their identity verification provider to make that possible. Providers that cannot meet that requirement risk giving long-standing clients a reason to evaluate alternatives — and competitor conversations are already underway.
What “ready” actually means
Supporting AML-R and eIDAS 2.0 is not a feature update. It represents an entirely new category of verification. The traditional document-based model — passport upload, liveness check, manual review — gives way to something fundamentally different: cryptographically-signed identity attributes, issued by government authorities and presented directly from a user’s digital wallet. There is no document, no image, only a signed credential validated within a trust framework that either recognises the platform or does not.
To accept this, a product must connect to EU member state trust registries, handle credential formats and protocols specific to decentralised identity — including ISO 18013-5, SD-JWT, and OpenID4VP — maintain accreditation as a relying party within the eIDAS trust framework, and remain current as standards, wallet versions, and implementing acts continue to evolve. This is a significant and permanent engineering and compliance surface that grows rather than shrinks as wallet adoption increases and more member states implement their national schemes.
Start with what already exists
The EUDI Wallet is not yet fully deployed, but the eID infrastructure underpinning it largely is. BankID in Sweden and Norway, itsme in Belgium, SPID in Italy, MitID in Denmark, France Identité in France, and Personalausweis in Germany are all government-issued digital identity schemes already used by tens of millions of Europeans. These systems operate in ways that closely resemble how the EUDI Wallet will function.
Identity product teams that integrate national eIDs today are not simply preparing for 2027 — they are creating immediate value through better conversion rates, reduced fraud risk, and faster onboarding in high-adoption markets. They are also developing the product capabilities — the flows, the trust framework integrations, and the institutional knowledge — that will make EUDI Wallet support considerably more manageable when the time comes. The path to 2027 readiness need not begin with a 24-month build. It can begin with a working integration in a single high-adoption market and expand from there.
The build vs partner decision
This is the call that will shape a product’s trajectory for the next three years, and it must be made at the product strategy level before engineering is brought in to scope. The risk in reversing that sequence is that once scoping begins, organisational momentum builds firmly in the direction of building. Estimates are produced, resources are discussed, and by the time engineering returns with a 20-month timeline, there is already a political commitment — even if the numbers do not support it. The partner conversation never receives a fair hearing because it was never properly opened.
Building in-house preserves control and keeps the capability within the product organisation. It also means owning the full technical, regulatory, and operational complexity indefinitely — standards evolve, implementing acts are updated, and new member states introduce national variations. That is not a one-time integration; it is a permanent engineering commitment with a compliance dimension that most product teams are not currently staffed to sustain.
Partnering with an infrastructure layer purpose-built for this challenge means working with an organisation that already holds trust registry connections, manages standards compliance, and absorbs ongoing maintenance as regulation matures. Under the eIDAS 2.0 Architecture Reference Framework, this role is formally defined as an Intermediary — an organisation that acts on behalf of relying parties to connect to wallets and request user attributes. For most identity product teams, the intermediary model does not replace the existing product; it extends it. Providers remain in the verification layer their clients already rely on, adding eID and wallet support without rebuilding their stack or inheriting the compliance surface that comes with full ownership.
The question worth asking now
If a key enterprise client called today and asked whether the platform supports AML-R and eIDAS-compliant eIDs, what would the answer be? If the honest response is “not yet,” the follow-up question is how quickly that changes — and whether that change will be driven by a build decision that has not been fully costed, or a partner integration that could be live within weeks. Providers who move now will enter 2027 with a tested product, optimised conversion flows, and clients who never had reason to look elsewhere. Those who wait will spend 2027 explaining why they are still 12 months away.
Read the full Hopae post here.
Copyright © 2026 FinTech Global
