Who is accountable when a merchant slips through onboarding controls?

Why This Matters for Security Teams

When a merchant slips through onboarding controls, the issue is rarely just a single bad decision. It usually exposes a gap in governance, control design, or evidence retention. Accountability matters because onboarding is the point where fraud, sanctions exposure, chargeback risk, and downstream abuse can all enter the environment. For regulated businesses, the question is not only who approved the merchant, but who owned the policy, who validated the checks, and who could demonstrate that the decision was defensible under audit.

Current guidance suggests treating merchant onboarding as a control process, not an administrative task. That means compliance may define thresholds, risk may approve exceptions, operations may execute reviews, and product or platform teams may implement the workflow. Under NIST SP 800-53 Rev 5 Security and Privacy Controls, accountability depends on clear control ownership, evidence, and monitoring. In practice, many security teams discover ownership ambiguity only after an adverse event has already forced a retroactive review.

How It Works in Practice

In a well-run onboarding model, accountability is shared but not diffuse. The platform owner is accountable for the approval path, the control owner is accountable for the standard being enforced, and the approver is accountable for the specific decision made within that standard. If a merchant bypasses checks, the critical question becomes whether the failure was in policy, process, implementation, exception handling, or monitoring.

A practical model usually includes these layers:

• Policy owners define what evidence is required before activation.
• Risk or compliance teams set escalation rules for higher-risk merchants.
• Operations teams execute checks and document outcomes.
• Engineering or product teams ensure the workflow cannot silently skip mandatory steps.
• Audit or governance teams verify that exceptions were approved and retained.

That structure is especially important where AML and KYC expectations apply. The FATF Recommendations — AML and KYC Framework place pressure on firms to know who they are dealing with and to apply risk-based due diligence. The practical translation is that onboarding cannot rely on a single reviewer’s judgment if the business must later prove that checks were risk appropriate, consistently applied, and logged.

Accountability also extends to control testing. A merchant who “slips through” may indicate that the workflow allowed a manual override, that a required verification signal was not actually enforced, or that monitoring did not detect the bypass in time. Security teams should therefore link onboarding evidence to incident response and exception reporting so that failures are measurable, not anecdotal. These controls tend to break down when onboarding is distributed across multiple tools and business units because no single owner can see the full approval chain.

Common Variations and Edge Cases

Tighter onboarding controls often increase friction and operational overhead, requiring organisations to balance conversion speed against fraud and compliance exposure. That tradeoff is real, and best practice is evolving rather than settled for every merchant model.

For low-risk merchants, a lightweight process may be acceptable if monitoring is strong and escalation paths are clear. For higher-risk sectors, jurisdictions, or payment flows, the accountability model should be stricter, with documented approval authority and stronger periodic review. Where automated decisioning is used, responsibility still sits with the organisation that configured and accepted the logic, not with the system itself.

Edge cases matter. Outsourced onboarding does not outsource accountability. A third-party provider may perform checks, but the platform remains responsible for oversight, contractual controls, and evidence retrieval. Likewise, if a merchant is later linked to fraud or sanctions concerns, the question is not only whether onboarding was executed, but whether ongoing review and re-verification were part of the operating model. Where that lifecycle is missing, accountability often becomes fragmented between compliance, operations, and product leadership, which makes remediation slower and less credible.

Related resources from NHI Mgmt Group

• Who is accountable when P2P fraud slips through fragmented APAC controls?
• Who is accountable when onboarding controls block legitimate users or let fraud through?
• Who is accountable when a phishing attack drains a treasury through a signer?
• What is the difference between human IAM controls and NHI governance?