Who is accountable when crypto scams move through regulated platforms?

Accountability sits with the firms that control onboarding, transfer approval, monitoring, and reporting, not with a single compliance function in isolation. Regulators will expect evidence that the organisation could identify suspicious activity, stop transfers at the conversion point, and apply the right licensing and reporting controls. Shared ownership needs named control owners.

Why This Matters for Security Teams

When crypto scams move through regulated platforms, accountability is not abstract: it lands on the firms that own onboarding, transfer approvals, monitoring, and suspicious activity reporting. That means compliance, fraud, operations, and security must be aligned on who can stop a transaction, who reviews alerts, and who proves the decision trail. Current guidance suggests regulators look for demonstrable control ownership, not shared responsibility language that leaves gaps.

This is especially important where non-human identities, API keys, and automated workflows initiate or approve transfers. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes governance at the transfer layer just as important as customer-facing fraud controls. In practice, many security teams encounter this only after a suspicious transfer has already cleared because the control owner, review queue, and escalation path were never tested together.

How It Works in Practice

Accountability usually maps to three operational points: identity proofing and onboarding, transaction monitoring and hold authority, and regulatory reporting. At onboarding, the platform must know who it is allowing in, what risk tier applies, and when enhanced checks are required. During transfer processing, controls need to detect mule activity, sanctions exposure, layering patterns, and unusual velocity. At reporting time, the organisation must preserve evidence that alerts were reviewed, decisions were made, and required reports were filed on time.

That is why regulators expect control evidence, not just policy statements. The NIST Cybersecurity Framework 2.0 is useful here because it ties governance, detection, and response together rather than treating them as separate compliance tasks. For systems that rely on service accounts, payment bots, or orchestration APIs, NHIMG’s Lifecycle Processes for Managing NHIs is relevant because transfers often depend on non-human identities whose privileges, rotation, and offboarding must be controlled like any other regulated access path.

• Assign a named owner for onboarding risk decisions, transfer interdiction, and post-event reporting.
• Require immutable audit logs showing who approved, held, released, or escalated each transfer.
• Separate fraud review from execution authority so one queue cannot silently override another.
• Test whether automated agents or scripts can initiate high-risk transfers without human challenge.

The NIST SP 800-53 Rev. 5 Security and Privacy Controls is a good reference for building this into access control, audit, and incident response mechanisms. These controls tend to break down when payment rails, customer support, and fraud operations each use different tooling and no single workflow can stop a transfer at the conversion point.

Common Variations and Edge Cases

Tighter transfer controls often increase friction, requiring organisations to balance fraud prevention against customer experience, payment speed, and operational cost. That tradeoff becomes sharper when regulated platforms handle cross-border transfers, stablecoins, embedded finance, or third-party payment orchestration, because the accountable party may not be the entity that technically initiates the movement.

There is no universal standard for this yet across all jurisdictions, but current guidance suggests the platform with effective control over onboarding, approval, or reporting remains accountable even when a partner performs part of the workflow. NHIMG’s Regulatory and Audit Perspectives is useful where audit teams need evidence that responsibility was not dispersed beyond recovery. The Top 10 NHI Issues also matters when automated workflows, admin tokens, or API credentials are part of the scam path, because those identities can become the hidden control plane for movement.

Edge cases often arise when a regulated platform relies on a fintech partner, wallet provider, or outsourced monitoring service. Even then, accountability does not disappear. It must be contractually assigned, technically enforced, and operationally evidenced. In practice, failures usually appear where the customer sees one brand, the transfer uses another system, and nobody can prove who had authority to stop the money.

Related resources from NHI Mgmt Group

• Who is accountable when illicit crypto flows pass through a regulated exchange?
• Who is accountable when an attacker reuses valid access to move through systems?
• Who is accountable when a crypto exchange account is taken over through recovery abuse?
• Who is accountable when compromised identities are used to move through the environment?