Open banking delegated access exposes the limits of static IAM

At a glance

What this is: This is an analysis of open banking delegated access and the way it exposes the limits of static IAM when permissions must change across customers, agents, and third-party providers.

Why it matters: It matters because IAM teams supporting financial data sharing need authorization, consent, and revocation controls that can keep pace with real-time delegated access decisions, not just initial login flows.

👉 Read PlainID’s article on open banking delegated access and static IAM limits

Context

Open banking delegated access is a permissions problem, not just an authentication problem. In this model, a customer authorises a financial advisor, family member, guardian, business agent, or third-party provider to access account data or initiate payments through APIs, often under time-bound and role-specific conditions.

The governance gap is that many IAM programmes still treat access as a static entitlement granted at setup time. Delegated financial access changes in context, scope, and duration, so policy enforcement, consent handling, and revocation all have to remain dynamic across the full access lifecycle.

That makes this a human IAM article with clear downstream implications for service-provider access as well. The subject is not open banking as a market trend, but the control mismatch between traditional IAM and permissioning that changes after the initial grant.

Key questions

Q: What breaks when open banking access is granted without dynamic revocation controls?

A: The main failure is that access outlives the consent that justified it. A third party can keep reading data or initiating payments after the relationship changes if the bank only enforces the original grant. That creates policy drift, audit gaps, and unnecessary fraud exposure.

Q: Why does delegated access increase risk in financial services?

A: Because the bank is no longer governing a single user account. It is governing a live authority relationship that can change by role, purpose, time, or legal basis, and that relationship often extends through external providers and APIs. Static entitlements do not capture that complexity.

Q: How do banks know whether delegated access is actually working?

A: They should compare the active consent state, policy decision logs, and revocation events against the current business relationship. If a cancelled mandate still shows usable API access, the control is failing. Effective delegated access means the technical policy state and the legal authority state always match.

Q: What should security teams do when customers can revoke financial access in real time?

A: They should design for immediate policy synchronisation, not delayed administrative cleanup. Revocation needs to remove or narrow the effective permissions at the enforcement point, then preserve a defensible audit trail showing when the decision changed and why.

Technical breakdown

How delegated access is authorised across open banking APIs

Delegated access in open banking combines customer consent, strong customer authentication, and API-mediated authorisation. The account holder grants a third party or agent permission to act within defined limits, while the bank or authorisation server evaluates that request against policy, role, and legal evidence such as a power of attorney or court order. The key technical point is that the access decision is not a one-time login event. It is a policy check that must be enforced whenever data is requested or a payment initiation is attempted.

Practical implication: treat delegated access as an authorisation workflow that must be evaluated at request time, not as a fixed account grant.

Why RBAC and ABAC both matter in delegated financial access

Role-based access control gives banks a coarse model for who a user is in relation to the account, such as advisor, guardian, or family member. Attribute-based access control then adds context like time, device, location, or transaction type, which is essential when a guardian may view statements but not initiate payments. In open finance, RBAC alone is usually too blunt, while ABAC without strong governance can become difficult to audit. The practical architecture is a combination of stable role assignment and policy conditions that narrow what each role can do in each situation.

Practical implication: combine roles with contextual policy conditions so delegated access can be constrained without becoming impossible to explain or review.

Where static IAM models break under consent revocation and policy drift

Static IAM assumes access remains valid until an administrator changes it. Open banking delegated access breaks that assumption because customer consent can be paused, narrowed, or revoked in real time, and regulatory expectations can change faster than identity records are updated. That creates policy drift, where the access policy reflected in the IAM system no longer matches the legal or customer-approved state. It also weakens auditability, because a historical grant is not enough if the current consent status is different. The control problem is lifecycle coherence across consent, authorisation, and logging.

Practical implication: design revocation and policy synchronisation as first-class controls, not as after-the-fact administrative cleanup.

Threat narrative

Attacker objective: The objective is to retain or expand financial access beyond the customer-approved scope so data or payment actions can be used without current consent.

1. Entry begins when a customer authorises a third party or agent to access account data or initiate payments through an open banking API.
2. Credential or authorisation abuse occurs if that delegated permission is broader than intended, insufficiently time-bound, or not revoked when the relationship changes.
3. Escalation follows when the authorised party can continue to query data or trigger payments beyond the original consent boundary.
4. Impact is loss of control over financial data sharing, weakened auditability, and increased fraud or reputational risk for the bank and the customer.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Canvas Instructure Data Breach: ShinyHunters exploits Canvas LMS platform to expose millions of student records via third-party NHI credential abuse.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static IAM is the wrong control model for open banking delegated access: the problem is not proving a user once, but governing permission after that proof. Consent can narrow, expire, or be withdrawn while the same agent or provider remains connected, so entitlement models that assume stable access no longer match the operating reality. The implication is that banks must treat delegated authority as a living policy state, not a permanent account property.

Delegated access creates lifecycle risk that sits between human identity and third-party access governance: the customer is a human principal, but the effective access path often runs through an external service provider. That means access review, offboarding, and audit have to cover the relationship, the consent state, and the technical token path together. Practitioner implication: separate identity proofing from ongoing authorisation governance, or revocation will lag the business relationship.

Fine-grained authorisation becomes the control plane for open finance: role labels alone cannot distinguish between viewing balances, initiating payments, or acting under a legal mandate. This is where policy engines and authorization servers matter most, because they bind decisions to context rather than relying on coarse account membership. The practical conclusion is that banks need policy expressiveness that matches the transaction, not the organisation chart.

Open banking exposes a consent integrity gap that many IAM programmes still under-estimate: a permission can be technically valid while being business-invalid because the underlying authority changed. That is a governance failure, not just a security issue. Practitioner implication: consent status, legal basis, and access logs must be reconciled continuously or audit trails will describe yesterday's authority, not today's reality.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Consent integrity is now part of identity governance: open banking turns permission management into a live control problem, not a setup problem. Banks that still model delegated access as a static grant will keep missing the point where customer authority, API access, and policy enforcement diverge.

Dynamic authorisation must replace entitlement drift: the operational question is whether the enforcement point changes fast enough when consent, time, or role changes. Without that synchronisation, the bank can be technically compliant at grant time and operationally out of control moments later.

Third-party access paths need lifecycle ownership: the same governance discipline used for service accounts applies here because external providers can retain effective access long after the customer relationship changes. That is why continuous access reconciliation matters more than periodic review alone.

For practitioners

• Define delegated-access policy states Map each allowed state for customer consent, role scope, time limit, and payment initiation separately so the authorisation engine can evaluate them independently.
• Synchronise revocation with access enforcement Ensure consent withdrawal, relationship changes, and policy updates propagate to the enforcement point before any further API calls are accepted.
• Split viewing rights from payment rights Use different policy rules for read-only access, limited action, and initiation privileges so a trusted helper cannot inherit broader authority than intended.
• Audit third-party access paths continuously Review which providers, agents, and tokens still hold live access and compare that state to the current consent record and legal basis.
• Test authorization server behaviour under policy drift Validate that changes in time, location, account type, or customer revocation immediately change the decision outcome rather than relying on stale entitlements.

Key takeaways

• Open banking delegated access exposes the weakness of IAM models that assume permissions are stable after initial approval.
• The article ties delegated access to consent, API security, authentication, and revocation, all of which have to move together to avoid policy drift.
• Banks need dynamic authorisation and continuous reconciliation between legal authority and technical access if they want delegated access to remain trustworthy.

Key terms

• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Consent Integrity: Consent integrity is the requirement that the technical access state matches the customer’s current legal and business permission state. In financial access flows, this means revocation, scope changes, and expiry must be enforced at the same speed as the original grant.
• Dynamic Authorization: Dynamic authorization is an access model that makes the trust decision at request time using current identity and context. It replaces reusable stored credentials with short-lived, policy-scoped tokens issued only after the workload proves itself.
• Policy Drift Detection: Policy drift detection is the process of identifying when an access policy no longer matches the intended rule or the current business context. It helps teams catch unauthorized changes, stale permissions, and exceptions that have quietly become the new normal, so governance stays aligned with actual identity and app usage.

What's in the full article

PlainID's full article covers the operational detail this post intentionally leaves for the source:

• Role-by-role delegated access examples for advisors, guardians, trustees, and family members
• Implementation guidance for RBAC and ABAC in open banking authorisation flows
• A case study showing how time limits, data scoping, and consent choices are applied in practice
• Regulatory discussion of CFPB Section 1033, GDPR, UK Open Banking, and related technical standards

👉 The full PlainID article covers delegated access examples, implementation steps, and regulatory requirements in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.