By NHI Mgmt Group Editorial TeamBased on Truvity: “AMLR July 2027: The Deadline Banks Are Overlooking” (May 1, 2026)

TL;DR: Banks face a five-month gap between AMLR in July 2027 and mandatory EUDI Wallet acceptance in December 2027, according to Truvity, and treating them as separate programmes risks duplicating infrastructure and cost. A single verification layer can satisfy stricter CDD requirements and the eIDAS 2.0 acceptance mandate if scoped early.


At a glance

What this is: This is a compliance analysis of how AMLR and eIDAS 2.0 intersect for banks, with the key finding that one verification infrastructure can satisfy both timelines.

Why it matters: It matters because identity verification, customer due diligence, and acceptance of digital identity wallets are converging into one operating model that affects governance, onboarding, and control design.


Context

Banks are being asked to align customer due diligence, digital identity acceptance, and regulatory evidence across two overlapping EU deadlines. AMLR raises the bar on verified customer data and ongoing monitoring, while eIDAS 2.0 creates a separate acceptance obligation for the European Digital Identity Wallet. The governance problem is not the rules themselves, but the tendency to build them as disconnected compliance projects.

For identity and access teams, this is really a digital identity and verification architecture issue, not just a legal one. Where banks ingest pre-verified attributes, rely on selective disclosure, and need fresh evidence of identity assertions, the boundary between KYC operations, IAM governance, and trust infrastructure becomes operational rather than theoretical.


Key questions

Q: How should banks avoid building separate AMLR and EUDI Wallet programmes?

A: Banks should design one verification architecture that serves both AMLR customer due diligence and eIDAS 2.0 wallet acceptance. That means aligning data models, evidence provenance, and assurance rules before implementation begins. If those controls are built separately, the institution usually pays twice in integration, testing, and change management.

Q: Why do overlapping identity regulations create so much operational risk?

A: They create risk because compliance teams often solve each rule in isolation, which leads to duplicated controls, inconsistent assurance levels, and conflicting owners. When the same identity evidence has to support onboarding, due diligence, and wallet acceptance, fragmented governance becomes expensive and hard to audit.

Q: What breaks when banks keep manual KYC processes for AMLR?

A: Manual KYC breaks when the bank has to re-verify larger volumes of customer attributes on a recurring basis. The process becomes slow, costly, and difficult to evidence, especially when regulators expect fresher assertions and standardised data quality across jurisdictions.

Q: Which teams should own digital identity acceptance in a bank?

A: Compliance, IAM, and digital identity teams should share ownership because the problem spans regulation, assurance, and runtime verification. If one function owns it alone, the bank usually optimises for its own workflow and leaves gaps in evidence reuse, lifecycle control, or regulatory reporting.


Technical breakdown

Why AMLR turns customer due diligence into an identity infrastructure problem

AMLR does more than add compliance requirements. It expands the data that must be collected, verified, and periodically refreshed, which pushes banks toward an identity layer capable of handling attribute assurance rather than simple document capture. In practice, customer due diligence becomes an evidence-management problem: the bank needs to know what was verified, by whom, under what assurance level, and whether that evidence remains fresh enough to rely on. That is why manual processes and fragmented KYC workflows become brittle under repeated verification obligations.

Practical implication: Treat CDD as a governed identity workflow, not a one-time onboarding task.

How EUDI Wallet acceptance changes the verification model

The EUDI Wallet is not just another login method. In this context it functions as a high-assurance source of pre-verified attributes that can be presented selectively, reducing the need to re-collect the same data through document-heavy processes. The technical shift is toward trusted claims, selective disclosure, and cryptographic proof of freshness, which are more aligned to ongoing assurance than static customer files. That makes wallet acceptance relevant to AMLR because the bank can verify required data points without rebuilding trust from scratch each time.

Practical implication: Design wallet acceptance around attribute assurance and evidence freshness, not around authentication alone.

Why build-once architectures matter for dual regulatory deadlines

The article’s core operational point is that separate AMLR and eIDAS 2.0 programmes will likely duplicate integration, testing, and change management. A shared verification layer can absorb both the CDD evidence requirements and the wallet acceptance mandate, but only if banks decide early enough to design for both. This is a governance and architecture choice: either build two compliance paths and pay twice, or align the identity verification layer to serve both obligations from the outset.

Practical implication: Plan a single verification architecture that can satisfy both regulatory timelines.


NHI Mgmt Group analysis

AMLR and eIDAS 2.0 are forcing banks to treat identity evidence as infrastructure, not paperwork. The regulatory pressure is not just about collecting more data. It is about making verification repeatable, auditable, and reusable across onboarding and lifecycle monitoring, which is exactly where fragmented KYC stacks fail. The practitioner conclusion is clear: identity evidence must be managed as part of the control plane, not the back office.

The real governance gap is project separation, not technical incapability. Banks that split AMLR and EUDI Wallet workstreams are creating their own duplication risk. That split encourages parallel integrations, inconsistent assurance logic, and conflicting ownership between compliance, IAM, and digital identity teams. The result is a programme design problem that will surface as budget pressure and control inconsistency. The practitioner conclusion is to align ownership before implementation starts.

Selective disclosure is the named concept this market should remember. The article points to a model where banks request only the Article 22 data they need, instead of re-collecting broad identity records every time. That matters because minimisation, freshness, and assurance can coexist when identity claims are structured correctly. The practitioner conclusion is to build verification around claims reuse, not repeated document ingestion.

EUDI Wallet acceptance will expose whether banks have a reusable trust layer or a one-off compliance workaround. If wallet presentations can be accepted once and reused for both AMLR due diligence and eIDAS acceptance, the institution has an adaptable identity architecture. If not, the bank is left with duplicated controls and a higher operating cost. The practitioner conclusion is to measure whether your verification process can support multiple regulatory use cases without rework.

This is an early signal that European identity regulation is converging on operational trust infrastructure. AMLR, eIDAS 2.0, and bank onboarding controls are no longer separable concerns for large regulated institutions. The direction of travel is toward reusable digital identity evidence, stronger assurance, and lower tolerance for manual re-verification. The practitioner conclusion is to plan for converged identity governance now, not after the deadlines land.

What this signals

Selective disclosure is the operational bridge between regulatory minimisation and usable identity evidence. For banks, the practical test is whether identity assertions can be re-used across onboarding and ongoing due diligence without forcing a new document chase each time.

European banking teams should expect wallet acceptance to become an identity architecture decision, not a narrow compliance checkbox. The institutions that win here will be the ones that can prove freshness, preserve assurance, and reuse verified attributes across multiple regulatory obligations.


For practitioners

  • Map one verification layer to both deadlines Scope AMLR CDD and EUDI Wallet acceptance as a single programme so the same evidence pipeline can satisfy both July and December 2027 obligations.
  • Redesign KYC around verified attributes Shift from document re-collection to attribute-based verification, with selective disclosure for the exact fields AMLR requires.
  • Align governance ownership early Assign joint ownership across compliance, IAM, and digital identity teams so the verification architecture is not split into separate delivery tracks.
  • Build for cryptographic evidence freshness Require presentation flows to preserve issuer-signed proof and freshness metadata so ongoing monitoring can reuse trusted assertions.

Key takeaways

  • AMLR and eIDAS 2.0 are converging on the same control problem, which is how banks verify and reuse trusted identity evidence at scale.
  • The main risk is not the regulation itself but the tendency to build separate delivery tracks for due diligence and wallet acceptance.
  • Banks that design one verification layer now can reduce duplication, lower implementation cost, and arrive at both deadlines with a single control model.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63A — Enrollment and Identity ProofingAMLR due diligence depends on verified attributes and identity proofing quality.
SP 800-63C — FederationEUDI Wallet acceptance relies on trusted identity assertions exchanged between parties.
Recommendation — Use SP 800-63A principles to govern the evidence and assurance behind customer identity verification. Apply SP 800-63C to structure trusted assertion exchange and relying-party acceptance.
GDPRArt.5 — Principles relating to processing of personal dataSelective disclosure and minimisation are central to the wallet-based identity model.
Recommendation — Minimise data collection and reuse only the attributes required for the stated verification purpose.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about governing who can accept and rely on verified identity data.
Recommendation — Define authorised reliance paths for verified identity attributes and review them as business processes change.
ISO/IEC 27001:2022A.5.34 — Privacy and protection of PIIBanks handling verified identity attributes need controls around protected personal information.
Recommendation — Apply privacy controls to identity evidence pipelines and restrict processing to stated compliance purposes.

Key terms

  • Customer Due Diligence: Customer due diligence is the process of verifying a customer’s identity and understanding the risk attached to that relationship. Wallet-based presentations can streamline it, but the institution remains accountable for deciding which attributes are trusted and how exceptions are handled.
  • Selective Disclosure: Selective disclosure is the practice of sharing only the identity attributes needed for a specific decision. In credential-based systems, it reduces oversharing, lowers retention burden, and limits exposure when a verifier does not need the full record to make a trustworthy judgment.
  • Eudi Wallet: A digital identity wallet is a user-controlled container for identity credentials, attributes, and presentation proofs. In regulated environments, it becomes part of the trust chain because relying parties may accept its claims for authentication, onboarding, or transaction approval.
  • Identity Assurance: The confidence an organisation has that a person or system is truly who it claims to be before access or action is granted. In modern IAM, assurance depends on evidence quality, channel trust, and the strength of verification around high-risk decisions.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the wider security programme they are responsible for.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org