Who is accountable when banks onboard modern digital asset services through third-party integrations?

The bank remains accountable for customer risk, regulatory compliance, and the controls applied to onboarding and transaction flows, even when third-party providers handle parts of the process. Security and compliance teams should define shared responsibilities, audit requirements, escalation paths, and evidence retention before launch. Without that governance, integration speed can create unclear ownership and control gaps.

Why This Matters for Security Teams

When a bank integrates modern digital asset services through third-party providers, accountability does not transfer with the API call. The institution still owns customer harm, regulatory exposure, and the control environment around onboarding, transaction approval, logging, and exception handling. That matters because third-party workflows often obscure where authentication, entitlement checks, and evidence retention actually occur.

Current guidance from the OWASP Non-Human Identity Top 10 treats service identities, tokens, and machine-to-machine access as governance objects that require explicit ownership. NHIMG research shows why this is not theoretical: in the 52 NHI Breaches Analysis, third-party exposure and poor credential handling recur as common failure patterns. For banks, the risk is not only compromise, but also being unable to prove who approved what, when, and under which control.

Security teams often assume the provider will carry the burden once contracts are signed, but regulators usually look at the bank’s ability to supervise, detect, and intervene. In practice, many banks discover ownership gaps only after a payment exception, onboarding failure, or credential leak has already exposed the control weakness.

How It Works in Practice

Accountability should be mapped as a control chain, not a vendor label. The bank needs defined ownership for customer due diligence, permissioning, transaction monitoring, incident escalation, and offboarding, while the third party may operate parts of the workflow under bank-approved guardrails. That means the bank must require evidence of how identities are issued, how secrets are protected, and how actions are logged, even when the provider runs the software path.

A practical model starts with a written responsibility matrix that separates business ownership, technical operation, and regulatory evidence. The matrix should specify who approves access, who reviews anomalies, who rotates credentials, who preserves records, and who notifies the bank when control changes occur. This is especially important for non-human identities because service accounts, API keys, and workload tokens often outlive the teams that created them.

Controls should align to established security baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls, particularly around access control, audit logging, and system integrity. Banks should also inspect third-party identity sprawl using lessons from NHIMG’s Ultimate Guide to NHIs, which highlights how often service identities are overprivileged and poorly rotated.

• Define shared responsibility before launch, not after a finding.
• Require least privilege for each onboarding and transaction step.
• Set evidence retention rules for logs, approvals, and exception handling.
• Test escalation paths for outage, fraud, and credential compromise.

These controls tend to break down when multiple providers chain together in a single onboarding flow because no single party can explain the full identity and decision trail.

Common Variations and Edge Cases

Tighter third-party control often increases onboarding time and integration overhead, so banks must balance speed against the need for durable oversight. Best practice is evolving, but the underlying principle is stable: outsourcing activity does not outsource accountability. That is especially true when a provider subcontracts functions again, creating a layered chain of responsibility that can dilute evidence and delay response.

One common edge case is “managed” onboarding where the vendor performs identity checks, sanctions screening, or transaction routing inside its own platform. Even then, the bank should retain approval authority over policy thresholds, dispute handling, and exceptions. Another is cloud-hosted or embedded wallet infrastructure, where access may be mediated by rotating tokens and service accounts; those identities still require lifecycle controls, because short-lived access does not eliminate the need for traceability.

NHIMG’s research on breach patterns shows that third-party exposure is a recurring source of control failure, including cases where token handling or supply chain integration widened access beyond the bank’s intended scope. Where there is no universal standard for this yet, banks should treat evidence of access governance, rotation, and revocation as mandatory contract terms rather than optional assurances.

The practical rule is simple: if the bank cannot demonstrate control over the risk, it will still be treated as responsible for it.

Related resources from NHI Mgmt Group

• Who is accountable when Travel Rule compliance fails in a digital asset transfer workflow?
• How should security teams reduce breach risk when third-party services are involved in business workflows?
• Who is accountable when a third-party enterprise application is exploited through a zero-day?
• Who is accountable when third-party or service access is still routed through a VPN?