Who is accountable when bank account verification is used for PSD2 and AML CTF compliance?

Why This Matters for Security Teams

Bank account verification for PSD2 and AML CTF is not just a data quality check. It influences onboarding, payment initiation, fraud screening, and the evidence trail used to justify decisions under regulatory scrutiny. Under the FATF Recommendations — AML and KYC Framework, firms still own the control outcome even when a third party supplies the signal.

That matters because verification failures are rarely isolated. They often cascade into weak exception handling, poor record retention, or inconsistent escalation between compliance and product teams. The risk is similar to broader NHI governance failures: once a control is treated as “the vendor’s problem,” ownership gaps appear quickly. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how often hidden dependencies become audit findings when accountability is not explicit.

For operational teams, the real issue is not whether the verification signal is useful, but whether it is governed, explainable, and reviewable inside the regulated entity’s own control environment. In practice, many security teams discover that accountability gaps only surface after an adverse decision, a regulator query, or a disputed account opening has already occurred.

How It Works in Practice

Best practice is to treat bank account verification as an input to a controlled decision process, not as a compliance waiver. The business collecting the data remains responsible for defining the policy, approving the use case, and proving that the workflow supports PSD2 and AML CTF obligations. That means documenting who owns the control, which checks are mandatory, which exceptions require review, and how long verification evidence is retained.

A workable operating model usually separates four layers:

• Compliance defines the regulatory standard and approves acceptable use of verification.
• Fraud and risk teams decide how the signal affects account opening, payment release, or step-up checks.
• Engineering implements logging, access control, and retention so the evidence is reusable.
• Operations handles exceptions, false positives, and customer disputes with an auditable trail.

That approach aligns with the control discipline in NIST Cybersecurity Framework 2.0 and the security control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where identity evidence, logging, and accountability are concerned. It also mirrors the lifecycle discipline discussed in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where ownership must persist across provisioning, use, review, and retirement.

For regulated institutions, the practical test is simple: can the organisation show who approved the reliance on the verification, what data was consumed, what thresholds were applied, and who overrode the outcome if needed. These controls tend to break down when the verification service is embedded in a fast-moving product flow because ownership, evidence, and exception handling get split across too many teams.

Common Variations and Edge Cases

Tighter verification governance often increases friction, requiring organisations to balance customer experience and onboarding speed against regulatory defensibility. That tradeoff is especially visible when a bank account check is reused across PSD2 payment journeys and AML CTF onboarding, where the same signal may support different decision thresholds.

Current guidance suggests the organisation should not rely on the verification provider’s assurances alone, but there is no universal standard for how much evidence reuse is acceptable across use cases. Some firms keep a single approval model with strict controls; others maintain separate policies for onboarding, step-up authentication, and ongoing monitoring. The important point is consistency: the same verification result may have different meanings depending on product, jurisdiction, and risk appetite.

Edge cases arise when a third-party platform performs the check, when multiple regulated entities share a workflow, or when delegated decisions are made by a partner bank or payment institution. In those cases, contractual language should match the actual operating model, and audit evidence should show who accepted liability for the decision, not just who supplied the data. That is also why NHIMG’s Top 10 NHI Issues remains relevant: governance failures usually begin with unclear ownership and end with weak evidence.

In practice, accountability gets tested hardest when verification is bypassed for high-volume onboarding, because exceptions are often treated as product shortcuts rather than controlled regulatory decisions.

Related resources from NHI Mgmt Group

• Who should be accountable when identity fraud moves across compliance, fraud, and verification teams?
• When does a service account become a compliance problem?
• Who is accountable when stronger anti-fraud regulation requires faster account disruption?
• How should security teams govern non-human identities for compliance?