Notifications
Clear all
Topic starter
24/06/2026 9:07 pm
TL;DR: Open banking delegated access depends on consent, fine-grained authorization, and strong authentication across banks, agents, and third-party providers, but it also exposes legacy IAM gaps in revocation, auditability, and policy drift, according to PlainID. Static access models are no longer enough when financial authority can change in real time.
NHIMG editorial — based on content published by PlainID: What Is Open Banking Delegated Access?
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- Role-by-role examples for advisors, guardians, trustees, and family members across open banking scenarios
- The vendor's implementation approach for fine-grained access control, authorization servers, and API policy enforcement
- Practical discussion of user experience trade-offs, consent flows, and customer-facing delegation design
- Examples of how legacy banking platforms can adapt to open banking APIs and regulatory technical standards
👉 Read PlainID's article on open banking delegated access and fine-grained authorization →
Open banking delegated access: where IAM controls still fall short?
Explore further
25/06/2026 6:08 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Open banking delegated access exposes the limits of static IAM
