By NHI Mgmt Group Editorial TeamBased on IDnow: “AMLR CDD RTS: what the final draft changes for your onboarding” (October 20, 2026)

TL;DR: AMLA’s final RTS draft for customer due diligence lets eID and qualified trust services work in every channel, narrows remote document verification to justified exceptions, and requires missing attributes to be filled before onboarding can be treated as complete, according to IDnow. That pushes identity teams toward one governed verification flow, not separate branch and digital exceptions.


At a glance

What this is: This is an analysis of AMLA’s final RTS draft on customer due diligence, which clarifies how eID, qualified trust services, remote document checks, and missing attribute handling should shape onboarding.

Why it matters: It matters because onboarding teams now need a single evidence model for identity verification, attribute collection, and exception handling across digital and in-person journeys.


Context

Customer due diligence rules only work when the verification path, the evidence collected, and the exception logic all line up. In identity programmes, the real failure mode is not a missing policy statement but a gap between what a regulated flow says it can verify and what it can actually prove later.

The final RTS draft makes that gap more visible for financial onboarding. It turns what many firms treated as separate channel-specific processes into a governance problem: one set of verification rules, one evidence trail, and one standard for when an exception is justified.


Key questions

Q: How should firms govern customer onboarding when multiple identity verification routes are allowed?

A: Treat the routes as one governance model, not three separate processes. Define which assurance levels, evidence outputs, and exception conditions are acceptable, then apply the same policy across digital, branch, and assisted onboarding. The aim is consistency: the organisation should be able to explain why a route was chosen, what data it produced, and how that evidence will stand up in later review.

Q: Why do exception-based verification flows create compliance risk?

A: Exception-based flows create risk when eligibility is informal, evidence is incomplete, or supervisors cannot reconstruct the decision later. In regulated onboarding, the problem is not the exception itself but the lack of a case-specific justification and a verifiable record. If the alternative path cannot be defended customer by customer, it becomes a control gap rather than a lawful fallback.

Q: What should teams do when identity attributes are missing from a compliant verification flow?

A: Do not treat missing attributes as a manual afterthought. Define which fields are mandatory for the chosen route, identify the permitted supplements for closing gaps, and route any unresolved cases into a governed exception process. The objective is to keep onboarding evidence complete enough for audit and ongoing screening without asking for unnecessary data.

Q: When should organisations prioritise a single onboarding policy over channel-specific workflows?

A: Prioritise a single policy when the same legal standard applies across channels and the main difference is how evidence is captured, not what must be proved. That is the right model when branch, remote, and assisted journeys all need the same identity assurance outcome. Separate workflows should exist only where the regulation genuinely creates a different control requirement.


Technical breakdown

How eID and trust services change verification routing

The RTS treats an identity document, an eIDAS electronic identification means at substantial or high assurance, and a relevant qualified trust service as lawful verification routes for natural persons. The practical change is that channel no longer determines the method. A firm can use the same assurance logic for branch, remote, or assisted onboarding, which reduces fragmentation in policy design. The key control question becomes whether the assurance level and attribute set are sufficient for the use case, not whether the interaction happens face to face or online. See the IAM and IGA Basics.

Practical implication: design one verification policy that maps acceptable assurance levels and evidence outputs across all onboarding channels.

Why remote document verification becomes an exception path

Article 7 makes remote document verification a narrow alternative, not a default route. It only applies when the customer cannot reasonably be expected to submit a document in person and has no access to an eID or qualified trust service, while still holding a valid identity document. That turns exception handling into a controlled decision process. Firms need a way to prove both eligibility and the adequacy of the alternative solution, because a general policy cannot substitute for case-specific justification. This is less about digitising document checks and more about proving why the standard routes were unavailable.

Practical implication: build case-level exception logic that records why the standard route was unavailable and what evidence supported the alternative.

What attribute completeness means for compliant onboarding

The RTS defines a minimum attribute set for eID and qualified trust service flows, including names, date of birth, nationality, residence, and tax identification number where available. Where those attributes are present, firms should not ask for extra data. Where one is missing, the obligation shifts to completing the attribute through other permitted means. That creates a data governance issue as much as an identity one: onboarding cannot be considered complete until the record contains the required attributes or a documented basis for why a low-risk route applies. The operational risk is inconsistent data capture across channels. See the NHI Lifecycle Management Guide.

Practical implication: compare your intake fields against the required attribute set and close any gaps with governed supplemental collection.


NHI Mgmt Group analysis

Channel-specific onboarding is becoming a governance liability. The RTS removes the old assumption that digital verification and branch verification should be managed as separate control families. Once eID, trust services, and document alternatives are all part of the same lawful framework, the real issue is whether the organisation can defend its decision logic consistently. For identity teams, that means policy fragmentation becomes a compliance risk, not just an operational inconvenience. The practitioner conclusion is simple: standardise the control objective before standardising the channel.

Exception handling is the real control point, not the verification method itself. The article shows that remote document checks survive only as a narrow justified route, which means the governance burden moves to eligibility, evidence capture, and supervisory review. That is a classic identity assurance problem, not just an AML rule change. Identity proofing and KYC becomes relevant wherever firms need to justify why a customer used an alternative route instead of the preferred one. The practitioner conclusion is to govern exceptions as first-class controls.

Attribute completeness now defines whether onboarding is actually complete. eID and qualified trust service flows are only useful if the resulting attributes are sufficient for the risk profile and legal route being used. Missing address or tax ID data turns into a downstream governance task, while low-risk handling remains a documented decision rather than a default shortcut. The broader lesson for identity programmes is that verification and enrichment are not separate stages when regulatory evidence depends on both. The practitioner conclusion is to treat attribute gaps as lifecycle events, not manual cleanup.

AML onboarding is converging with identity governance discipline. The RTS pushes firms toward consistent evidence, controlled exceptions, and explicit attribute governance, which are the same design principles used in mature IAM and IGA programmes. That does not make this an IAM regulation, but it does mean identity teams should stop treating regulated onboarding as an isolated compliance workflow. The practitioner conclusion is to align financial identity proofing with lifecycle governance, auditability, and policy-based decisioning.

What this signals

Verification policy is becoming a data governance issue. The real operational challenge is no longer whether a firm can check a customer, but whether it can prove that the chosen route produced the right evidence and the right attributes. For regulated onboarding, that means identity assurance, data completeness, and auditability now have to be designed together.

Exception governance will separate mature programmes from brittle ones. Firms that rely on remote document checks need controls that justify each use case, preserve the evidence trail, and support later supervisory review. The important shift is that alternative verification is no longer a convenience layer; it is a controlled exception with its own lifecycle.

Attribute completeness is the new benchmark for onboarding quality. A compliant verification flow that leaves gaps in address or tax ID handling is not finished, even if the identity check itself passed. The programme question is whether missing data is resolved through governed supplementation or left to downstream manual correction.


For practitioners

  • Map every onboarding route to one approved verification policy Document which journeys use identity documents, eID, qualified trust services, or the narrow remote document exception, and make the approval criteria explicit. See the IAM and IGA Basics.
  • Build case-level justification for remote document use Capture the reason the customer could not reasonably use the standard route and retain the supervisory evidence needed to defend each exception.
  • Compare collected attributes to the required minimum set Check names, birth data, nationality, residence, and tax identification coverage, then define a governed process for filling any missing attribute.
  • Separate low-risk decisions from routine assumptions Record the risk assessment that justifies reduced data collection so low-risk handling remains a documented decision and not a default onboarding shortcut.
  • Align screening and retention to the update cycle Make sure screening happens at onboarding, when lists change, and when customer data changes, with evidence retained for later verification.

Key takeaways

  • The article shows that regulated onboarding is moving from channel-based verification to a single governed decision model.
  • Its central governance issue is not only identity proofing, but whether firms can prove exceptions, attribute completeness, and retention later.
  • Teams that separate verification, enrichment, screening, and evidence retention will struggle most as the RTS moves into force.

Related NHI Mgmt Group resources: IAM and IGA Basics · NHI Lifecycle Management Guide · Joiner-Mover-Leaver (JML) Guide · Third-Party Risk Management Guide


Standards & Framework Alignment

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

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and GDPR defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63A — Enrollment and Identity ProofingThe RTS governs how natural persons are verified during onboarding, which maps directly to enrollment proofing.
Recommendation — Align onboarding evidence collection to SP 800-63A assurance and retain the rationale for each accepted identity source.
GDPRArt.5 — Principles relating to processing of personal dataThe article discusses collecting only required attributes and avoiding unnecessary data collection.
Recommendation — Minimise identity data capture to the fields required for the lawful verification route and document the basis for each extra field.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsVerification routing and exception approval are governance decisions about who can proceed and under what conditions.
Recommendation — Use entitlement and authorization controls to restrict alternative onboarding routes to documented, approved exceptions.
CIS Controls v8CIS-5 — Account ManagementThe onboarding workflow creates or updates customer accounts and needs controlled lifecycle handling.
Recommendation — Apply account-management discipline to onboarding, screening, and record retention so identity changes remain traceable.
OWASP API Security Top 10API10 — Unsafe Consumption of APIsDigital identity and trust-service flows depend on consuming external verification services safely and consistently.
Recommendation — Validate third-party identity service inputs and outputs before trusting them in onboarding decisions.

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.
  • Electronic Identification: A regulated way of proving a person or organisation’s identity for digital transactions. In eIDAS 2 contexts, it is not just a login mechanism. It is an assurance process that must support interoperability, auditability, and appropriate privacy handling across jurisdictions and service providers.
  • Qualified Trust Service Provider: A qualified trust service provider is an organisation authorised to deliver trust services such as digital signatures, seals, timestamps, or certificates under EU trust rules. In practice, it must prove strong governance, resilience, and accountability because its services underpin digital trust for regulated transactions.
  • Alternative Verification Measure: An alternative verification measure is a narrow fallback route used when the standard verification path cannot reasonably be used. It should be treated as an exception with explicit justification, not as a cheaper substitute, because the organisation still has to prove why the exception was necessary and adequate.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It helps practitioners connect regulated identity workflows to broader security and audit requirements.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org