Who is accountable when a delegated banking permission is misused?

Accountability usually sits with the bank and the service provider that failed to enforce the agreed controls, even if the customer originally granted consent. Regulators and auditors will look for evidence that access was bounded, monitored, and revocable. If the platform cannot show that, the governance failure is the institution’s.

Why This Matters for Security Teams

Delegated banking permissions are often treated like a one-time consent event, but the real risk begins after approval. The key question is not whether a customer clicked agree, but whether the bank and the service provider kept the permission bounded, monitored, and revocable throughout its life. That is why NHI governance matters: delegated access behaves like a non-human identity, not a static customer preference. OWASP’s OWASP Non-Human Identity Top 10 frames this as a control problem, not just a consent problem.

NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, which helps explain why delegated access becomes dangerous when scope drifts beyond the original approval. In banking, that drift can turn a narrow payment permission into broad account reach, especially when third-party apps chain actions or retain tokens longer than intended. In practice, many security teams only discover this after an unauthorized transfer or data exposure has already forced the investigation.

How It Works in Practice

Accountability is assigned by control ownership, not by who first granted consent. If a bank exposes delegated access through APIs, tokens, or customer-authorized third-party connections, the bank remains accountable for the control plane, while the service provider is accountable for how it uses and protects the delegated permission. That division must be proven through logs, policy enforcement, revocation evidence, and periodic review. This is where current guidance aligns with Zero Trust thinking: trust is never permanent, and authorization must be evaluated in context at the point of use.

In practice, the strongest programs treat delegated permissions as short-lived, scoped entitlements rather than open-ended access. That means:

• binding the permission to a specific purpose, account, and duration
• issuing revocation-ready tokens or credentials with clear TTLs
• monitoring for use outside the agreed transaction pattern
• logging who approved, who used, and who could revoke the permission
• revalidating permissions after product changes, app updates, or risk events

NIST’s Zero Trust Architecture is useful here because it assumes access must be continuously verified rather than inherited. For banking teams, that means the strongest evidence is not a policy statement, but a demonstrable chain from consent to bounded access to timely revocation. NHI Management Group also notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which illustrates why delegated permissions often persist far longer than intended. These controls tend to break down when third-party integrations are deeply embedded in payment flows because revocation becomes operationally difficult and monitoring is fragmented across systems.

Common Variations and Edge Cases

Tighter revocation and monitoring often increases customer friction and integration overhead, so organisations have to balance user convenience against control assurance. The hard cases are usually not simple misuse, but ambiguous ownership across the bank, the fintech, and any aggregation layer in between. There is no universal standard for this yet, so regulators typically look at whether the institution can show effective governance, not whether the customer technically consented.

Two edge cases matter most. First, if the delegated permission was created through a reseller, broker, or platform marketplace, accountability can fragment unless contracts clearly define who enforces scope limits and who revokes access on demand. Second, if the permission is reused across multiple services, a single compromise can expand into lateral misuse, making the original approval irrelevant from a risk standpoint. For that reason, best practice is evolving toward explicit delegation registers, transaction-level policy checks, and rapid offboarding procedures. When the bank cannot demonstrate those controls, accountability usually lands with the institution that failed to enforce them, even if the misuse was triggered by a third party.

Related resources from NHI Mgmt Group

• Who is accountable when temporary access is misused in a delegated workflow?
• Who is accountable when a shared administrative credential is misused after offboarding?
• Who is accountable when a delegated app or secret causes a breach?
• Who is accountable when a third-party open banking integration misuses access?