AMLA's Final CDD Standards Make eID the Default for Remote Onboarding

On September 30, 2026, AMLA published its final draft Regulatory Technical Standards on customer due diligence (CDD). These are the rules that tell every obliged entity in the EU how to run KYC under AMLR. For remote onboarding, electronic identification is now the default route, and a remote document-and-selfie check is the fallback.

US regulators made a similar move last month when they cleared mDLs for bank onboarding. Europe has gone a step further by putting digital ID first.

Article 7 sets an order of operations

AMLR Article 22(6) gives you two ways to verify a customer’s identity. The first is an identity document, passport or equivalent. The second is an electronic identification means at eIDAS assurance level substantial or high. The RTS, written under Article 28(1) AMLR, define how those routes work in practice.

Article 7 covers a customer who can’t reasonably present a document in person and doesn’t have access to a qualifying eID. Only then may you verify their document remotely through an “alternative solution,” and only if that solution meets a list of safeguards. You also have to be able to demonstrate why the customer couldn’t be verified through either route in Article 22(6).

The consultation drew 325 responses. Respondents from banks to casino operators asked for clarity on remote verification, and a recurring concern was that the draft read as “eIDAS-first.” AMLA clarifying response says the Article 22(6) measures remain the default, with alternative methods reserved for cases where neither can be used. AMLA also confirmed that existing remote onboarding tools can keep running if they meet the Article 7 requirements.

Any eID at substantial or high counts, notified or not

Recital 11 defines which eIDs qualify. Any electronic identification means at assurance level substantial or high counts, whether or not a member state has notified it under eIDAS. EUDI Wallets are named explicitly, and so are relevant qualified trust services.

That opens the eID route today Notification is a process for cross-border recognition, and not every scheme that meets an assurance level has been through it. The RTS only ask about the assurance level.

The installed base is already large. In our Global eID Adoption Report, we track 89 active digital IDs in Europe covering 372 million people. That’s about half the adult population, and the count excludes eID cards. More than 99% of Swedish adults have a BankID. Schemes like Denmark’s MitID, Italy’s SPID and Belgium’s itsme are rated LoA High under eIDAS. You can see every scheme we support across Europe on our coverage page.

EUDI Wallets add to this rather than replace it. Every member state has to offer at least one by December 24, 2026. By December 2027, banks and other regulated businesses that require strong user authentication must accept them when a user asks. Our State of EUDI report covers where each member state stands. If you onboard customers in the Nordics, Italy or Belgium, you can route most of them through eID before a single wallet is certified.

Want to know which of your EU markets you can move to eID today? Talk to our team and we’ll map it against your customer base.

Annex I uses the EUDI Wallet’s data model

Annex I lists the attributes an eID must be able to provide for CDD. The names come straight from the person identification data (PID) rules for EUDI Wallets: family_name, given_name, birth_date, birth_place, nationality, resident_address. For legal entities, it maps to a persistent unique identifier and, where available, the Legal Entity Identifier.

Two things follow. First, AMLA has picked your data model. If your compliance system stores identity data under each vendor’s own field names, now is the time to map everything to the PID schema. Second, gaps are yours to close. Under Article 27(2), when an eID doesn’t carry an attribute you need, you obtain and verify it some other way. National schemes vary in what they return, and address is the usual gap. AMLA did confirm you don’t need to re-verify data points the eID already provides.

For low-risk customers, the gap nearly disappears. Under simplified due diligence, the RTS require only core identity data: names, date and place of birth, and nationality, with no address.

Document flows get a stricter spec and a paper trail

For customers without a qualifying eID, Article 7 requires an alternative solution to provide:

• controls confirming that the person presenting the document is its holder

• integrity and confidentiality of the communication

• images, video, sound and data clear enough to identify the person unambiguously

• a stop to the process on technical faults, dropped connections, or any doubt about the person or the check

• valid, current data, with copies time-stamped, stored securely and readable for later review

What’s new is that the burden of proof sits with IDV providers, and AMLA cites emerging technological threats as the reason. Injection attacks and generated faces target exactly this flow.

Under Article 7(3), you must be able to explain why each customer verified by document couldn’t use a default route. If your flow never offers eID, every document onboarding is a customer you never tried to verify the default way.

What to change before July 2027

1. Offer eID first. Put the customer’s national eID, bank-based ID or wallet ahead of the document upload. The order of your screens is now evidence.

2. Record a reason for every fallback, such as no supported scheme in the customer’s country, no credential held, an assurance level that’s too low, or a technical failure. Log the reason with the verification event.

3. Accept the schemes your customers already hold. You don’t need to wait for EUDI Wallets.

4. Map results to Annex I, and flag missing attributes so you can fill them under Article 27(2).

5. Check your document vendor against Article 7, including holder binding, session integrity, stopping on doubt, and time-stamped records.

None of this is a single integration. As Riley put it on Liminal’s Friday Five, accepting one digital ID is harder than it looks, and the RTS ask you to accept dozens.

How Trinsic fits

Trinsic is digital ID acceptance infrastructure. Through one integration, you accept the digital IDs your EU customers already carry, including national eIDs, bank-based IDs and EUDI Wallets, with your existing IDV provider as the fallback for everyone else. We already support national identity authentication services for France, Italy, Denmark, Austria and other member states. We’re adding EUDI Wallets as they launch.

For a compliance team working through the RTS, that turns the eID-first requirement from a roadmap item into configuration. You set the attributes and assurance level each tier of due diligence requires: substantial for standard CDD, and high where enhanced due diligence calls for it. We route each customer to a credential that meets them. Every result comes back in a consistent data model and is logged with the provider, assurance level, attributes returned and timestamp, so the evidence a supervisor asks for is already there.

If you’re turning the RTS into an onboarding plan for July 2027, talk to our team and we’ll show you what eID-first onboarding looks like in production.

Related from Trinsic: read The EUDI Wallet, Explained; see digital ID across Europe; download The State of EUDI.