Who is accountable for AML compliance when businesses delegate due diligence tasks to third parties?

Why This Matters for Security Teams

When due diligence is outsourced, the operational work may move, but the accountability does not. That distinction matters because AML failures usually surface as governance failures: weak customer due diligence, inconsistent risk scoring, incomplete monitoring, or poor escalation of suspicious activity. The FATF Recommendations — AML and KYC Framework make clear that firms can rely on third parties for parts of the process, but they still need effective oversight, documented controls, and evidence that the outsourced activity is actually working.

Security and compliance teams often underestimate how quickly third-party due diligence becomes an evidence problem. If the firm cannot show who performed the check, when it was done, what data was used, and how exceptions were handled, the regulator will usually treat the control as if it failed. The same principle applies even when the third party is another regulated institution, a fintech partner, or a specialist onboarding provider. Accountability sits with the obliged entity because it owns the customer relationship, the risk decision, and the reporting obligation.

In practice, many teams discover this only after a failed audit trail exposes that outsourcing reduced effort but not responsibility.

How It Works in Practice

Delegation is usually acceptable only within a controlled framework. The firm should define which tasks may be performed by a third party, what evidence must be retained, how quality is checked, and when the firm will override or repeat the third party’s work. The control objective is not simply to “trust the vendor,” but to preserve the firm’s ability to demonstrate that AML decisions were reasonable, repeatable, and reviewable.

Good practice usually includes written agreements, service level expectations, data-handling requirements, escalation paths, and audit rights. The firm should also align its oversight model with internal control standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0, because AML outsourcing failures often start as poor access governance, weak logging, or missing monitoring around the shared workflow.

• Assign a named accountable owner for each outsourced AML process.
• Document the risk-based criteria for using third-party due diligence.
• Retain source data, decision evidence, and exception handling records.
• Perform periodic QA on samples of delegated cases and follow up on defects.
• Test whether alerts, reviews, and suspicious activity escalation still work end to end.

This guidance tends to break down in multi-jurisdiction groups where local AML obligations, privacy rules, and retention periods conflict across entities because the oversight model becomes fragmented.

Common Variations and Edge Cases

Tighter oversight often increases onboarding friction and operating cost, requiring organisations to balance regulatory confidence against speed and scale. That tradeoff becomes sharper when the third party performs high-volume checks, uses automated screening, or sits in another legal jurisdiction. In those cases, best practice is evolving, and there is no universal standard for how much testing is enough, but the accountable firm still needs a defensible review cadence and clear escalation thresholds.

One common edge case is intra-group delegation. Even where a parent company or affiliate performs the work, accountability usually remains with the entity that is subject to the AML obligation. Another is technology-mediated delegation, where a platform or workflow tool executes parts of due diligence. If identity data, sanctions screening, or risk scoring is embedded in automated workflows, the firm must also control the underlying credentials, service accounts, and non-human access paths. That is where OWASP Non-Human Identity Top 10 becomes relevant to AML governance, because weak control over machine identities can undermine the integrity of outsourced checks.

Another practical exception is reliance on a third party for customer identification only, while retaining risk rating and monitoring internally. That can work, but the firm still needs evidence that the outsourced step matches its policy, not just the vendor’s process. Where the relationship involves repeated API-based verification or shared case management, the control problem is less about vendor selection and more about ongoing assurance.

Related resources from NHI Mgmt Group

• How should compliance teams implement customer due diligence under Kenya’s AML framework in higher-risk onboarding flows?
• Who is accountable when customer identification and due diligence fail in cross-border compliance programmes?
• Who is accountable when identity verification or due diligence fails in a Nigeria compliance programme?
• How should compliance teams implement risk-based customer due diligence under South Africa’s AML rules?