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 how it reshapes authorization, consent, and fraud risk in financial services.

Why it matters: It matters because banks and service providers must govern delegated financial access with controls that work across NHI, human, and policy-driven access paths.

👉 Read PlainID's article on open banking delegated access and fine-grained authorization

Context

Open banking delegated access is the controlled sharing of financial data and payment capability through APIs, with consent and authorization separating a customer’s authority from the service that acts on their behalf. The IAM challenge is not whether access exists, but whether that access is scoped, time-bound, auditable, and revocable across banks, third-party providers, and human intermediaries.

That governance problem is broader than authentication alone. Retail banks, payment service providers, and account information providers need to manage identity proofing, delegated consent, and policy enforcement while keeping pace with changing regulatory expectations and legacy platform constraints.

For IAM teams, the real issue is that delegated access looks like a familiar identity pattern but behaves more like a dynamic authorization lifecycle. That makes it a useful lens for NHI governance, customer identity, and access control design in regulated environments.

Key questions

Q: How should banks govern delegated access in open banking?

A: Banks should govern delegated access as a lifecycle of granted authority, not as a one-time login event. That means tying consent to policy enforcement, limiting privilege by role and context, logging every action, and making revocation immediate. The goal is to ensure the delegate can act only within the exact authority the customer intended.

Q: When does delegated access create more risk than it reduces?

A: Delegated access becomes riskier when access is broad, hard to revoke, or poorly audited. That is especially true when banks rely on legacy platforms that cannot enforce fine-grained limits or confirm whether a delegate still has a valid business need. In those cases, authority outlives intent and the control model weakens.

Q: What do banks get wrong about customer consent in delegated access?

A: Many banks treat consent as if it were enough on its own. In practice, consent only starts the authorization process. Security teams still need to enforce scope, duration, and monitoring, or the system will allow more access than the customer expected. Consent without policy is only documentation, not control.

Q: Who is accountable when a delegated banking permission is misused?

A: 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.

Technical breakdown

How delegated consent becomes an authorization decision

Open banking delegated access starts with customer consent, but consent alone does not grant safe authority. The bank still has to translate that consent into enforceable policy, usually through an authorization server, API controls, and a trust decision about who may act, on what data, and for how long. That is why delegated access is closer to policy enforcement than simple login. The customer, the account information service provider, and the payment initiation provider each sit in a different trust zone, and the bank must preserve intent across those boundaries.

Practical implication: model delegated consent as an authorization lifecycle, not a one-time authentication event.

RBAC and ABAC in open banking access control

RBAC and ABAC solve different parts of the delegated access problem. RBAC maps broad relationship-based access, such as advisor or guardian, while ABAC adds context like device, location, account type, or time window. In open banking, that combination is often necessary because a role alone is too coarse to represent what the delegate may do. A guardian may view one account, a payment provider may initiate only approved transactions, and a trustee may need broader authority under legal constraints. Without fine-grained policy logic, banks either overgrant or block legitimate use cases.

Practical implication: use RBAC for baseline delegation and ABAC for boundaries, limits, and context.

Why audit trails and revocation determine control quality

Delegated access is only as strong as the bank’s ability to prove what happened and undo it quickly. Audit trails show who accessed which account, what action was taken, and whether the access matched consent. Revocation matters just as much, because the risk in delegated banking is stale authority that outlives the need for it. Real-time controls, short-lived permissions, and visible approval history are therefore core security functions, not reporting extras. In regulated financial environments, these controls become part of evidence, accountability, and customer trust.

Practical implication: require revocation and auditability in the same design review as initial access approval.

NHI Mgmt Group analysis

Delegated access is an authorization lifecycle problem, not a banking UX feature. Open banking often gets described as customer convenience, but the underlying security issue is who can exercise authority after consent is granted. That shifts the centre of gravity from authentication to governance, because the bank must continuously enforce scope, duration, and revocation across multiple parties. Practitioners should treat delegated access as a control plane, not a user journey.

Fine-grained access control is the only credible response to relationship-based banking authority. A family member, advisor, trustee, or payment provider does not need the same rights, and legal permission is not the same as operational privilege. RBAC supplies coarse delegation, but ABAC is what keeps the policy usable in real banking scenarios with time, device, and transaction constraints. The implication is that overgeneralised roles will either fail compliance or fail usability.

Legacy banking systems create delegated access debt. Many platforms still lack real-time consent management, modern API policy enforcement, and visible auditability across third-party access. That leaves customer intent separated from actual enforcement, which is where fraud, overreach, and support burden tend to accumulate. Banks that cannot revoke and explain access quickly are already running an authority model they cannot fully defend.

Open banking delegated access will increasingly converge with broader NHI governance patterns. The same lifecycle questions appear in service accounts, API tokens, and other non-human access paths: who approved it, what scope was granted, when does it expire, and who can terminate it. The field is moving toward shared governance patterns across human and non-human delegation. Practitioners should stop treating banking delegation as a separate category of control.

Open banking delegated access shows why identity security and compliance are now inseparable. Regulatory requirements are no longer satisfied by login strength alone, because the real control question is whether the delegate can act only within the authority that was actually granted. That makes access policy, consent evidence, and revocation design part of the same control objective. Security teams should expect auditors to ask how authority is bounded, not just how it is authenticated.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• For a broader control model, see Ultimate Guide to NHIs for lifecycle, visibility, and revocation patterns that also apply to delegated banking authority.

What this signals

Delegated access is converging with NHI governance: banks are increasingly managing customer-authorised delegates the same way they manage machine identities, with scope, lifecycle, and revocation as the real control points. That matters because the security model breaks when authority is granted once but managed forever. The governance lesson is to treat delegated banking access as a policy object with a lifecycle, not as a static permission.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the risk pattern is familiar: overbroad authority is easier to grant than to contain. Financial institutions that cannot express least privilege in transaction terms will struggle to defend customer consent in practice. The next maturity step is continuous authorization, not better phrasing in consent screens.

For practitioners

• Define delegated access as policy, not permission Map every open banking delegated access flow to explicit policy rules for who can see, initiate, or modify account data, and separate those rules from authentication steps.
• Split broad roles from contextual limits Use RBAC for the delegate category and ABAC for time, device, account, and transaction constraints so access matches the legal and operational intent.
• Make revocation and audit trails non-optional Require real-time cancellation paths and immutable access logs so consent can be withdrawn immediately and every delegated action can be reviewed later.
• Review third-party access as a lifecycle process Put delegated banking access into recurring certification, offboarding, and exception review cycles so stale authority does not persist after the business need changes.

Key takeaways

• Open banking delegated access is fundamentally an authorization governance problem, because consent alone does not constrain what the delegate can actually do.
• Banks need fine-grained policy, revocation, and auditability to keep delegated authority aligned with customer intent and regulatory expectations.
• The same lifecycle discipline used for NHIs is increasingly relevant to delegated financial access, especially where third-party authority can outlive its business purpose.

Key terms

• Delegated Access: Delegated access is a model where one identity is allowed to act on behalf of another under defined limits. In banking, that usually means a customer grants a trusted person or service specific rights to view data, initiate payments, or manage an account, with policy, consent, and revocation all remaining part of the control design.
• Fine-grained Authorization: Fine-grained authorization is the practice of deciding access based on detailed conditions rather than broad role membership alone. In open banking, it controls which account, action, time window, or context applies, so the delegate receives only the authority needed for the approved task.
• Consent Lifecycle: Consent lifecycle is the full path from approval to review, change, suspension, and revocation. It matters because a consent record without ongoing enforcement leaves the delegate with authority that may no longer match the customer’s intent, business need, or regulatory obligation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by PlainID: What Is Open Banking Delegated Access? Read the original.