Treat them as one operating change, not three isolated obligations. The practical response is to redesign customer identity assurance so it can accept new evidence types, re-check trust after change events, and support strong authentication and due diligence from the same control model.
How eIDAS 2.0, AMLR and PSD3 fit into one identity programme
The three regimes overlap around one operational question: how do you establish a person’s identity, reuse that assurance safely, and prove it still holds after something changes? eIDAS 2.0 pushes reusable digital identity and wallet-based evidence, while AMLR and PSD3 raise the bar for customer due diligence and strong authentication in financial flows. The programme challenge is to make one assurance model serve all three without weakening any of them.
That means teams should stop thinking in product silos. The identity layer, verification rules, fraud controls, and compliance evidence need to be designed together so the same customer record can support onboarding, payment authentication, and ongoing risk reviews. If those controls are built separately, firms end up duplicating checks, creating inconsistent trust decisions, and slowing both customer experience and operations.
For a practical baseline, anchor the design to a common identity evidence model and a clear trust posture for each customer state. The wallet, documentary evidence, biometrics, transaction signals, and periodic refresh events should all feed the same decision logic, rather than living in separate compliance workflows. That makes it easier to explain why a customer can be accepted in one channel, challenged in another, or re-verified after a material change.
Why this becomes an architecture and control design problem
These obligations change more than policy wording. They affect how evidence is accepted, how trust is re-established, and how exceptions are handled when a customer’s profile, device, or behaviour changes. If the assurance model cannot ingest new evidence types or cannot trigger re-checks after change events, teams will end up with brittle manual reviews that do not scale across onboarding, payments and AML monitoring.
Done well, the design separates identity assurance from momentary risk decisions. A wallet or verified credential can strengthen confidence in who the customer is, but AML controls still need sanctions screening, source-of-funds logic, and event-driven review. Likewise, PSD3 strong authentication should not be treated as a one-time login step, but as part of a broader trust chain that can respond to device changes, payee changes, step-up events, and suspicious behaviour.
The same logic should extend to privileged operators and automated back-office processes that handle customer records and payment exceptions. Where teams rely on Financial Services Identity Security Guide-style governance, the important point is that human approvals, delegated actions, and service workflows all need the same traceability and change control discipline when they can alter identity trust.
What teams should change first in onboarding, payments and AML reviews
Start by mapping each required decision to a trust input, not to a business unit. Customer onboarding, wallet acceptance, step-up authentication, due diligence refresh, and account recovery should all consume the same authoritative evidence set where possible. That lets you avoid duplicate identity proofing, but still apply stricter scrutiny when the risk context changes.
Next, define the events that must force a re-check of trust. A new device, a changed phone number, an updated address, a new payment beneficiary, a failed liveness step, or an unusual transaction pattern should not be handled as isolated alerts. They should trigger a controlled reassessment of the customer’s identity confidence and transaction authority, with clear thresholds for when friction is acceptable and when the case must be escalated.
For the identity evidence layer itself, teams preparing for Digital Identity, eID and Identity Wallets Guide should design for selective disclosure, replay resistance, and evidence provenance. That matters because wallet-based journeys can reduce manual collection, but only if the verifier can tell which claims are trustworthy, which are fresh, and which still require additional checks under AML or payment rules.
Risk and Threat Considerations
The main risk is over-trusting a single identity event and assuming it remains valid across onboarding, payments and AML decisions. If trust is not rechecked after a change event, a customer can pass an early verification step and later use a compromised account, changed device, or manipulated profile to move money or bypass review. The opposite failure is also common: treating every regime as separate creates control duplication, inconsistent decisions, and excessive manual friction.
Failure mechanism: The organisation accepts evidence once, but does not bind that evidence to later state changes, so authentication strength and due diligence drift apart over time.
Impact: That gap can produce false approvals, delayed suspicious-activity detection, weak step-up logic, and audit findings where the control model cannot explain why trust was still considered valid.
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 SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Level | Identity assurance and evidence strength are central to reusable customer identity across these regimes. |
| Recommendation — Define assurance levels for onboarding and re-verification so each step uses the right evidence strength. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PSD3 strong authentication and change-driven re-checks depend on credential and authenticator lifecycle control. |
| IA-2 — Identification and Authentication (Organizational Users) | Customer-facing workflows still rely on strong identification and authentication decisions at access points. | |
| Recommendation — Manage authenticators with rotation, revocation and lifecycle controls tied to trust-state changes. Enforce strong identification and authentication where users enter regulated customer journeys. | ||
| NIST Zero Trust (SP 800-207) | ZT-032 — Continuous Verification | The question hinges on re-checking trust after changes rather than trusting a one-time validation. |
| Recommendation — Continuously re-evaluate trust when device, context or transaction state changes. | ||
| GDPR | A.5.1 — Legal, regulatory and contractual requirements | Identity evidence handling for EU customers must align with overlapping regulatory obligations and purpose limits. |
| Recommendation — Align evidence collection and retention with the legal basis for each customer-identity use case. | ||
Practitioner Guidance
What to prioritise: Build a single trust decision model before you tune individual controls. The first deliverable should be a shared set of identity states, evidence sources, and re-check triggers that compliance, fraud, onboarding and payments teams all recognise.
What to verify: Test whether the same customer can move from onboarding to active use without any mechanism that re-validates trust after key changes. If the answer is yes, the design is probably too static for eIDAS 2.0, AMLR and PSD3 to coexist cleanly.
Decision rule: If a control can change the customer’s authority to transact, it should also change the customer’s assurance state. If it cannot, treat it as an alerting input, not as proof that the customer remains trustworthy.
Practitioner takeaway: The winning design is not the strongest single control, but the ability to carry one trustworthy identity record through onboarding, authentication and review without losing sight of when trust must be refreshed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org