Who is accountable for compliance when stablecoins move through banking workflows?

The bank remains accountable for the parts of the workflow it controls, including onboarding, screening, and customer-facing payment operations. If a third party issues the stablecoin, that party owns token mechanics and reserve administration, but the bank still needs oversight of how customers access and use the service. Accountability follows control, not brand ownership.

Why This Matters for Security Teams

Stablecoins do not change the basic accountability rule in regulated banking workflows: the institution is accountable for the controls it operates, even when a third party supplies the token or reserve infrastructure. That matters because compliance failures rarely happen at the point of issuance alone. They usually emerge where onboarding, screening, payment routing, custody interfaces, and exception handling overlap. The bank must be able to show that it can prevent prohibited activity, detect suspicious movement, and explain which control owner is responsible at each step.

This is where standards and operational evidence need to line up. A control framework such as the NIST Cybersecurity Framework 2.0 helps define accountability across govern, identify, protect, detect, respond, and recover, but it does not remove the need for workflow-specific ownership. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how quickly accountability gaps widen when third parties are allowed to operate inside the bank’s customer journey without clear oversight.

In practice, many security teams discover accountability gaps only after a payment review, sanctions exception, or audit finding has already exposed the missing control owner, rather than through intentional governance design.

How It Works in Practice

The practical answer is to map accountability to the control boundary, not the asset label. If the bank is onboarding the customer, running sanctions or fraud screening, approving transaction initiation, or presenting the stablecoin service through its own channels, the bank owns compliance for those steps. If a separate issuer controls minting, redemption, reserve management, or token contract operation, that issuer owns those mechanics. But the bank still needs oversight of how its customers are allowed to access, exchange, and move value through the workflow.

That means compliance teams should document the workflow in layers:

• Customer identity and KYC ownership

• Wallet provisioning and access approval

• Sanctions screening and transaction monitoring

• Exception management, escalation, and recordkeeping

• Third-party issuer controls, attestations, and incident notification duties

For regulated payment paths, the bank should also align its model to external obligations such as the FATF Recommendations, which emphasize risk-based controls for AML and KYC regardless of the underlying token structure. At the control level, NIST guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for assigning responsibility, logging, monitoring, and supplier oversight. NHIMG’s Lifecycle Processes for Managing NHIs is also relevant here because payment workflows increasingly depend on non-human identities, API credentials, and system-to-system access that must be governed with the same rigor as customer-facing controls.

The operational test is simple: if the bank can stop, reroute, or approve the flow, then the bank is accountable for the associated compliance control. These controls tend to break down when stablecoin services are embedded in multi-party fintech stacks because responsibility becomes split across product, treasury, compliance, and vendor teams without a single evidence owner.

Common Variations and Edge Cases

Tighter control over stablecoin workflows often increases integration overhead, requiring organisations to balance faster payment experiences against stronger compliance evidence and clearer role boundaries. Current guidance suggests the hardest edge cases are not the standard bank-issued token flows, but the hybrid models where a wallet provider, exchange, custodian, and bank each touch different parts of the customer journey.

In those cases, accountability can become shared, but it is not diffuse. There should still be one accountable control owner for each required compliance outcome. For example, the issuer may handle reserve attestations, while the bank remains responsible for customer screening and transaction monitoring on accounts it services. If the bank relies on an external program manager or technical platform, that does not transfer regulatory accountability unless the law explicitly says so, and even then the bank usually still retains oversight duties.

Practitioners should also be careful with cross-border activity. Stablecoin transfers can create jurisdictional overlap, especially where custody, redemption, or settlement occurs outside the bank’s primary regulatory perimeter. The best practice is evolving, but the safe assumption is that the bank must prove control over what it directly enables and must contractually bind vendors to provide the audit evidence needed to support that proof. NHIMG’s Top 10 NHI Issues is a useful reminder that third-party dependencies often become accountability failures before they become technical failures.

Related resources from NHI Mgmt Group

• Who is accountable when a vendor supports automated decision-making or privacy workflows?
• Who is accountable when duplicate records create compliance or fraud issues?
• Who is accountable for PKI risk when legal data moves through portals and email?
• Who is accountable when a signing certificate breaks invoice compliance?