The hardest part of deciding whether to build or partner for eIDAS 2.0 compliance is not the technical complexity — it is recognising that the decision is not really a technical one at all. It is a product strategy call, and one that needs to be made before an engineering team has even begun scoping.
According to Hopae, AML-R and eIDAS 2.0 are on the radar for most identity product teams, and their clients are aware too. The real question is whether products will be ready when those clients come asking — and that conversation is likely closer than most teams expect.
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 sound comfortable in the abstract, but the maths tells a different story. Building compliant support for eID-based verification from scratch typically takes between 18 and 24 months, and that is before accounting for the complexity of connecting to 27 different EU member state trust registries, each with its own technical requirements, credential formats, and accreditation process. If this is not scoped and resourced today, a team is not ahead of the deadlines — it is already behind them.
This is not just a European problem
A common assumption among identity product teams is that because AML-R and eIDAS 2.0 are EU regulations, they belong to someone else’s problem set. That assumption is costly. If clients operate in Europe — and the vast majority of enterprise clients in banking, FinTech, crypto, telecom, and payments do — then by December 2027 those businesses will be legally required to accept EUDI Wallet-based identification. They will look to their identity verification provider to make that possible. If the provider cannot deliver, they may begin looking elsewhere.
For product managers, the risk is not merely technical — it is competitive. Clients that took years to onboard will have a reason to evaluate alternatives, and competitors are already having those conversations.
What “ready” actually means
Supporting AML-R and eIDAS 2.0 is not a feature update. It is an entirely new category of verification. The traditional document-based model — passport upload, liveness check, manual review — is supplanted by something fundamentally different: cryptographically-signed identity attributes, issued by government authorities, presented directly from a user’s digital wallet. There is no document, no image, only a signed credential and a trust framework that either recognises a given platform or does not.
To accept that, a product needs to connect to the trust registries of each EU member state it intends to support, handle credential formats and protocols specific to decentralised identity — including ISO 18013-5, SD-JWT, and OpenID4VP — pass and maintain accreditation as a relying party within the eIDAS trust framework, and stay current as standards, wallet versions, and implementing acts continue to evolve. This is a significant and permanent engineering and compliance surface that grows larger over time as wallet adoption increases and more member states roll out their implementations.
Start with what already exists
The EUDI Wallet is not yet fully deployed, but the eID infrastructure it builds on 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 in active use by tens of millions of Europeans. From a user experience standpoint, they function in ways closely aligned with how the EUDI Wallet will operate.
Identity product teams that integrate national eIDs today are not just preparing for 2027 — they are unlocking genuine near-term value through better conversion rates, reduced fraud risk, and faster onboarding in markets where eID adoption is already high. They are also building the internal expertise — the flows, trust framework integrations, and institutional knowledge — that makes EUDI Wallet support considerably less painful when the time comes.
This is arguably the most underused lever available to product managers right now. The path to 2027 readiness does not have to 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 — and when to make it
This is the call that defines a product’s trajectory for the next three years, and it must be made at the product strategy level rather than delegated to engineering to scope first.
The sequencing matters because once scoping begins, organisational momentum builds in the build direction. Estimates are produced, resources discussed, and by the time engineering returns with a 20-month timeline, teams are already politically committed — 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 offers control and keeps the capability within the product. 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 maintain.
Partnering with an infrastructure layer purpose-built for this problem means working with an organisation that already holds the trust registry connections, handles standards compliance, and absorbs ongoing maintenance as the 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, this model does not replace an existing product; it extends it. eID and wallet support can be added without rebuilding from the ground up, and without inheriting the compliance surface that comes with it.
The question worth asking now
If a major enterprise client called today and asked whether a platform supports AML-R and eIDAS-compliant eIDs, what would the answer be?
If the honest answer is “not yet,” the next question is how quickly that changes — and whether the change will be driven by a build decision that has not yet been fully costed, or a partner integration that could be live within weeks. The providers that move now will enter 2027 with a tested product, optimised conversion flows, and clients who never had cause to look elsewhere. Those that wait risk spending 2027 explaining why they are still 12 months away.
Read the full Hopae post here.
Copyright © 2026 RegTech Analyst
Copyright © 2018 RegTech Analyst
