Open Banking Delegated Access lets a customer authorize a third party to access bank data or initiate payments on their behalf without sharing primary credentials. Technically, consent is scoped, time-bound access issued through OAuth-based flows or similar authorization controls, with strong identity verification, revocation, and auditability to limit misuse.
What Open Banking Delegated Access Actually Is
Open Banking delegated access is a controlled permission model, not a password-sharing model. It lets a customer authorise a third party to act on their behalf while keeping primary bank credentials out of the relationship, which is why consent scope and trust boundaries matter so much.
The practical distinction is that the third party receives limited authority, usually for a specific account, purpose or duration, rather than a full account takeover path. That makes delegated access safer than handing over login details, but also means the design must preserve clear user intent, revocation and traceability.
How Delegated Access Is Structured
In most implementations, delegated access is issued through OAuth-based flows or a closely related authorisation mechanism. The customer is the original authority, the third party is the delegated actor, and the bank or authorisation server enforces the rules that bind the grant to a defined scope.
That structure matters because it separates authentication from authorisation. The customer proves who they are to the bank, then the bank issues a narrow token or consent grant that allows a bounded action set, such as reading balances or initiating a payment, without exposing the primary credential set.
This model is strongest when the delegation artifact is audience-restricted, time-bound and auditable. It becomes fragile when implementations blur consent with standing access, reuse broad tokens across journeys, or fail to bind the grant tightly enough to the intended third party.
Why Delegated Access Matters in Banking
Delegated access is what makes open banking usable at scale for payment initiation, aggregation and account information services. It supports customer convenience and ecosystem interoperability while preserving a stronger security posture than shared credentials or screen scraping.
It also creates a governance boundary. Banks must know who is acting, for what purpose, under what consent, and for how long. Human vs Non-Human Identity is a useful lens here because delegated access often sits at the boundary between a person authorising an action and a third-party system executing it.
That boundary is especially important in financial services, where strong customer authentication, payment integrity and third-party accountability are not optional design details. The control objective is to preserve user intent while preventing a delegated channel from becoming a durable abuse path.
Common Control Failures and Operational Weaknesses
Delegated access fails when consent is too broad, revocation is weak, audit trails are incomplete, or the third party can reuse the grant outside the intended context. The most serious weakness is when a delegated flow becomes indistinguishable from full account control in practice, even if the policy says otherwise.
Another common failure is poor lifecycle management. If expired grants, stale integrations or orphaned consents remain active, the organisation accumulates dormant access paths that are difficult to detect and easy to abuse. OAuth Token Exchange and Delegation Guide helps explain why the underlying delegation mechanics must be tightly constrained, especially where one actor operates on behalf of another.
Identity proofing and consent capture also need to be aligned. If the bank cannot reliably link the grant to the right customer, the right application and the right transaction context, delegated access can drift into impersonation risk rather than legitimate delegation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Delegated banking flows depend on robust token-based authentication and trust binding. |
| Recommendation — Bind delegated grants to the correct client and reject weak token authentication paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated access depends on lifecycle control of credentials, tokens and revocation. |
| AC-6 — Least Privilege | Open banking delegation should limit third-party authority to the minimum needed scope. | |
| AU-2 — Event Logging | Delegated access requires auditable evidence of consent, use and revocation. | |
| Recommendation — Manage token issuance, rotation, revocation and expiration with enforced lifecycle controls. Restrict delegated permissions to the narrowest approved actions and data. Log consent creation, token use, revocation and third-party actions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Consent grants and third-party access are lifecycle-managed access relationships. |
| Recommendation — Track, review and revoke delegated access relationships as managed accounts. | ||
Practitioner Guidance
Governance implication: Treat delegated access as a lifecycle control, not a one-time login event. Ownership should cover consent issuance, scope definition, expiry, revocation and evidence retention so the grant remains intelligible throughout its life.
What to watch for: Review whether your implementation can prove who authorised the access, what was authorised, and whether the third party can only operate within that exact boundary. PSD2/PSD3 Strong Customer Authentication Guide is especially relevant where delegated access depends on regulated banking flows and audit evidence.
For teams building or reviewing these journeys, the key judgment is whether the user can still understand, revoke and challenge the delegation easily. If not, the implementation may be technically OAuth-compliant but still operationally unsafe.