TL;DR: The final EU AMLR customer due diligence RTS turns KYC into a risk-based orchestration problem, according to Namirial, with eID, EUDI Wallets and qualified trust services as the default path and remote fallback verification governed by documented safeguards. The control assumption is no longer checklist completion but evidencing why each identity journey, data point and re-screening decision was proportionate.
At a glance
What this is: Namirial's analysis of the final AMLR customer due diligence RTS shows that KYC, remote identification and ongoing monitoring now need to be designed as one risk-based workflow rather than separate compliance steps.
Why it matters: This matters because identity teams in regulated environments must align onboarding evidence, fallback verification, screening and review cadence to a single defensible rulebook.
Context
The EU Anti-Money Laundering Regulation is directly applicable, but the regulation leaves practical gaps around which data points to collect, which sources count as reliable and independent, and when remote verification is acceptable. The final customer due diligence RTS fills those gaps and gives KYC, onboarding and compliance teams a common operating model to plan against.
For identity and compliance programmes, the real issue is governance, not only verification. The text pushes firms to treat onboarding journeys, evidence retention, screening triggers and ongoing review as connected controls, with documented rationale for when simplified due diligence or fallback remote verification is used.
Key questions
Q: How should organisations distinguish KYC from customer due diligence in AML onboarding?
A: KYC is the broader customer verification framework, while customer due diligence is the core process inside it. Organisations use KYC to identify the customer, understand risk, and monitor activity over time. CDD becomes more intensive for higher risk relationships, unusual transactions, or inconsistent information, so teams should treat it as a risk based control layer rather than a one time check.
Q: When should firms use alternative remote identification instead of eID or a wallet?
A: Use alternative remote identification only when the customer cannot reasonably present the document in person and does not have access to eID or qualified trust services that meet the preferred route. The fallback must satisfy the RTS safeguards and be justified with evidence. In practice, exceptions should be rare, documented and reviewable.
Q: What breaks when KYC data and screening are not integrated?
A: Re-screening, PEP checks, beneficial ownership verification and periodic refreshes become inconsistent and slow. Without connected data and event-driven triggers, teams can miss changes in customer status, list updates or ownership structures, which weakens both compliance and auditability. The result is a monitoring model that looks complete on paper but fails in operation.
Q: How should compliance teams prove that customer due diligence is proportionate?
A: They should retain enough evidence to show why the chosen data set, verification source and review frequency matched the identified risk. That means keeping decision logs, source quality rationale and exception handling together. Proportionality is defensible only when the programme can explain its choices after the fact.
Technical breakdown
Risk-based customer due diligence under the AMLR
The RTS is built around proportionality rather than a fixed checklist. That matters because customer due diligence under the AMLR now has to reflect the type and level of risk identified, which means the same onboarding flow may collect different evidence depending on customer segment, product and geography. Simplified due diligence is explicitly encouraged in low-risk cases, while higher-risk scenarios justify deeper verification, more frequent review and stronger screening. The practical effect is that policy design, evidence capture and review cadence become part of the control itself, not afterthoughts.
Practical implication: map each onboarding journey to a documented risk rationale and make the evidence set variable by risk class.
Remote identification, eID and qualified trust services
Article 22(6) places identity documents, electronic identification means and relevant qualified trust services at the top of the verification hierarchy. The RTS clarifies that this includes EUDI Wallets and eID at substantial or high assurance, and it can apply face to face as well as remotely. Alternative remote verification is allowed, but only where the customer cannot reasonably present the document and lacks access to the preferred means. That makes fallback identity proofing a governed exception, not an equivalent primary path.
Practical implication: re-sequence digital onboarding so eID, wallet and qualified trust service flows are the default, with exception handling explicitly justified.
Ongoing monitoring and re-screening as a data integration problem
The operational burden shifts sharply once onboarding data has to stay current. The RTS requires periodic updates, event-driven reviews, PEP checks, sanctions re-screening and retention of records that support ex post verification. Because those controls are triggered by customer data changes and list updates, manual workflows become fragile unless the workflow can connect identity data, source registers, watchlists and review logic. In practice, the standard turns continuous data synchronisation into a compliance requirement, not a convenience.
Practical implication: integrate screening, source-of-truth data and review triggers so monitoring is event-driven instead of batch-only.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
KYC governance is shifting from document collection to evidence orchestration. The RTS does not simply add more fields to capture. It requires firms to prove that each data point, source and verification route was proportionate to the risk profile, which changes the control model for onboarding and monitoring. That means compliance teams now have to govern the decision logic behind identity journeys, not just the identity artefacts themselves. The practitioner conclusion is clear: evidence design is now a core control design problem.
Remote identification is being normalised around trusted digital identity rails. The combination of eID, EUDI Wallets and qualified trust services makes alternative selfie-and-video flows a fallback rather than the centre of gravity. This does not eliminate remote onboarding tools, but it does raise the bar for justification when firms rely on them. The implication for practitioners is that digital identity assurance now needs explicit routing rules, not one generic remote process.
Ongoing monitoring becomes an identity data quality discipline. PEP screening, sanctions re-screening, beneficial ownership verification and periodic refreshes all depend on current, connected data. The RTS rewards firms that can propagate customer changes through screening and review logic quickly and consistently. For identity and compliance leaders, the lesson is that stale data is now a governance weakness, not merely an operational inconvenience.
AMLR compliance is now a programme architecture issue, not a single-control issue. The RTS touches identity proofing, source credibility, beneficial ownership, sanctions, risk scoring, retention and re-identification. That breadth means teams cannot solve it with a point fix in one system. The practitioner conclusion is to govern KYC as an end-to-end lifecycle that spans onboarding, review, change detection and audit evidence.
Document authenticity and source reliability are the real control boundary. The RTS repeatedly emphasises that identity data must come from reliable and independent sources and that documents must be checked for authenticity. That shifts attention away from whether data exists and toward whether it can be trusted and defended under supervision. The practical takeaway is to treat source assurance as part of the identity model, not a separate compliance note.
What this signals
Customer due diligence is becoming an identity orchestration problem: the control boundary now spans proofing, fallback verification, screening and ongoing review. That means teams should stop treating onboarding as a one-time event and instead govern it as a lifecycle with explicit exception handling, evidence retention and change triggers.
Risk-based design is the point of the RTS, not a side effect: simplified due diligence, alternative remote verification and deeper review for higher-risk customers all sit inside one proportionality model. Identity programmes that can justify why each journey exists will be easier to defend than those that merely capture more data.
Remote identity assurance is moving toward trusted digital rails: eID, qualified trust services and wallet-based identification now sit above older fallback channels in the hierarchy. Practitioners should expect governance pressure to prove why they are still relying on document-plus-selfie or video-based routes when higher-assurance options are available.
For practitioners
- Map onboarding journeys to the preferred verification hierarchy Determine which customer flows can use identity documents, eID means, EUDI Wallets or qualified trust services as the primary path, and document when fallback remote verification is justified.
- Rebuild fallback logic for remote identification Define the Article 7 safeguards your alternative remote process must satisfy, including holder matching, communication integrity, evidence quality, interruption on doubt and secure retention.
- Calibrate data collection to risk level Align your data model with the RTS rules on names, address, birthplace, nationality and low-risk simplifications, so each journey collects only what the risk profile supports.
- Connect screening to customer change events Trigger PEP and sanctions re-screening when customer data, watchlists or beneficial ownership information changes, and keep audit records that support ex post verification.
- Review existing customers against the new time limits Plan remediation so higher-risk customers are updated within one year and other customers within five years, using a risk-sensitive schedule and clear ownership.
Key takeaways
- The RTS turns AML KYC into a governed identity lifecycle, where verification, monitoring and refresh decisions must be tied to risk.
- The biggest operational change is not more data, but stronger evidence for why a customer was verified, screened and rechecked the way they were.
- Teams that integrate identity proofing, screening and change-driven review will be better placed to defend proportionality under the new rulebook.
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, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.32 — Security of Processing | Identity and screening data must be handled securely across onboarding and monitoring. |
| Recommendation — Protect customer identity data with documented security controls and secure retention across the KYC lifecycle. | ||
| NIST SP 800-63 | SP 800-63A — Enrollment and Identity Proofing | The RTS is fundamentally about identity proofing and verification assurance. |
| Recommendation — Align proofing evidence and fallback identity checks to a documented assurance model. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article stresses controlled access to identity data, screening and verification workflows. |
| Recommendation — Restrict access to onboarding and screening data to authorised roles with documented approvals. | ||
| CIS Controls v8 | CIS-5 — Account Management | Customer identity handling depends on governed account and access lifecycle processes. |
| Recommendation — Apply account governance to onboarding systems and remove stale access to KYC workflows. | ||
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.
- Simplified Due Diligence: Simplified Due Diligence is the lowest-intensity form of customer due diligence used for customers or transactions assessed as low risk. It allows institutions to reduce some verification and monitoring steps while still meeting AML obligations. The purpose is to preserve compliance while improving speed and operational efficiency.
- 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.
- Event-Driven Review: Event-driven review means reassessing vendor risk when a material change occurs, such as a contract shift, access expansion, or control failure. It is stronger than calendar-only review because it responds to real relationship changes rather than waiting for a scheduled cycle.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or identity governance in your organisation, it is worth exploring.
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