Who is accountable when identity verification fails under eIDAS and AML expectations?

Why This Matters for Security Teams

identity verification failures are not just operational defects. Under eIDAS and AML expectations, they can become control failures that affect trust, auditability, and regulatory exposure. The practical question is not whether a vendor performed the check, but who defined the assurance target, approved exceptions, and owned the escalation path when the result was wrong. That ownership becomes especially important when onboarding is distributed across product, compliance, and outsourced verification services.

NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that control ownership often breaks down when identity workflows are treated as someone else’s problem. The same accountability discipline applies to human identity verification, where downstream risk can survive long after a failed check is discovered. Regulatory intent is clear in eIDAS 2.0 and the FATF Recommendations: institutions remain responsible for the effectiveness of their identity and due diligence controls, not merely for procuring a tool.

In practice, many security teams encounter ownership gaps only after a failed onboarding decision has already enabled account abuse, regulatory queries, or recovery work that is far more expensive than the original control.

How It Works in Practice

The accountability model should be written into the control itself. If an organisation uses a third-party identity verification provider, that provider may operate the check, but the organisation still owns the policy outcome: what level of assurance is acceptable, what evidence is sufficient, which exceptions are allowed, and who can override a failed result. That is the same governance pattern reflected in NIST SP 800-53 Rev. 5, where control responsibility remains with the system owner even when implementation is outsourced.

Practitioners usually separate the workflow into four accountable layers:

• Policy owner: defines assurance levels, documentary thresholds, and acceptable fallback methods.
• Control operator: performs the verification, records evidence, and flags failures or anomalies.
• Risk approver: decides whether an exception can be accepted, time-boxed, and reviewed.
• Audit owner: ensures the decision trail shows who accepted the risk and why.

That structure matters because AML and eIDAS expectations both care about traceability. A false pass can be as problematic as a false fail if it results in improper onboarding, weak customer due diligence, or a broken audit trail. NHIMG’s 52 NHI Breaches Analysis shows how quickly trust breaks down when identity controls are weak or ambiguous, even in adjacent NHI-heavy environments. For identity verification, teams should maintain evidence of who configured the rule, who approved the exception, which checks were performed, and what monitoring detects later fraud signals.

These controls tend to break down when verification is embedded in fast-moving onboarding funnels with no explicit exception workflow because operational speed overtakes documented accountability.

Common Variations and Edge Cases

Tighter verification often increases friction, cost, and abandonment, so organisations have to balance customer experience against regulatory defensibility. Current guidance suggests that the right answer is not always a single “pass or fail” rule. Some environments allow tiered assurance, where low-risk use cases use lighter checks and higher-risk transactions require stronger proof, but there is no universal standard for this yet.

Edge cases matter most when a verification vendor returns an ambiguous result, a politically exposed person triggers enhanced due diligence, or identity evidence is valid but insufficient for the specific risk appetite. In those cases, accountability should remain with the organisation’s named control owner, not with procurement or the vendor relationship manager. That owner must be able to explain why an exception was approved, denied, or escalated.

The broader lesson is that failure handling must be designed before a failure occurs. The organisation should document fallback identity proofing methods, escalation SLAs, review intervals for exceptions, and how adverse decisions are appealed. NHIMG’s Top 10 NHI Issues reinforces a familiar pattern: when identity governance is fragmented, the control gap becomes visible only after abuse or investigation. The same is true for eIDAS and AML workflows, where ambiguity over ownership creates the delay that regulators notice first.

Related resources from NHI Mgmt Group

• Who is accountable when identity verification fails under CANAFE?
• Who should be accountable when identity fraud moves across compliance, fraud, and verification teams?
• Who is accountable when bank account verification is used for PSD2 and AML CTF compliance?
• Who is accountable when document-free onboarding fails to meet AML or privacy requirements?