What do teams get wrong when implementing on-behalf-of access in open banking?

A common mistake is assuming one consent pattern can cover every business relationship. In practice, delegation varies by company, account structure, and approval chain. If teams hard-code those assumptions, they create brittle integrations, weak auditability, and policy gaps. The better pattern is to express delegation through claims, scopes, and tokens that carry the needed context.

Where on-behalf-of access breaks down in open banking

Teams usually get the protocol mechanics right and the delegation model wrong. Open banking is not one universal “consent + token” pattern: the business relationship may be customer-to-bank, business-to-business, aggregator-to-bank, or multi-party. If the access model does not reflect the real approval chain, the resulting tokens can be technically valid while still authorising the wrong actor, wrong resource, or wrong scope.

That is why delegation has to be expressed as context, not as a shortcut. Claims, scopes, and audience restrictions should carry the relevant relationship and resource boundaries so the token describes who is acting, for whom, and against what. The safer pattern is to use OAuth 2.0 Token Exchange when the on-behalf-of step needs a distinct delegated token rather than reusing a broad bearer token.

The common implementation failure is hard-coding a single consent shape into multiple customer journeys. That tends to flatten important differences such as corporate hierarchy, account ownership, entitlement boundaries, and whether the approver is a person, a business function, or an external application. Once those assumptions are embedded in code, the integration becomes fragile when a bank, aggregator, or merchant relationship changes.

In practice, the control failure shows up as poor traceability. A team may be able to prove that a token was issued, but not that the asserted delegation matched the actual business approval path. That weakens auditability, complicates incident investigation, and makes it harder to detect where access is broader than the underlying mandate. For the authentication and delegation layer, OAuth 2.0 authorization semantics should be kept distinct from the business meaning carried in the delegated transaction.

The same problem appears when teams treat consent as static instead of time-bound and resource-bound. A delegation that is valid for one account, one service, or one purpose should not silently become a reusable standing permission for adjacent use cases.

What good on-behalf-of design looks like in practice

A sound design separates the original actor, the delegating party, and the downstream resource server. That usually means the access token is not just “allowed” or “denied”, but also constrained by audience, scope, expiry, and a delegation context that downstream services can verify. In open banking, that often means the token needs enough structure to survive multi-hop processing without losing the approval chain.

When the flow is certificate-bound or sender-constrained, the team also reduces the chance that a delegated token is replayed outside its intended channel. Where mutual TLS is the chosen binding model, OAuth 2.0 mutual TLS client authentication and certificate-bound access tokens can help keep the delegation tied to the authenticating client. If the resource target itself varies by product or account group, audience restriction matters too, which is why resource indicators for OAuth 2.0 are useful for preventing tokens from drifting across services.

For teams that need a broader implementation reference, the Agentic AI Identity Guide is useful because it explains delegated authority, agent ownership, and token exchange patterns in a way that maps well to any “acting on behalf of” design. The same delegation discipline also appears in the Financial Services Identity Security Guide, which frames open banking as a regulated identity and access problem rather than a pure API integration problem. Teams also benefit from NHI Authentication Guide because delegated access in service-to-service flows often fails for the same reason: the credential proves caller identity, but not necessarily the intended delegation context.

Risk and Threat Considerations

Open banking on-behalf-of flows are attractive to attackers because they can convert a legitimate delegation path into broad, hard-to-detect access. If scope, audience, or approval context is too loose, a valid token may be reused beyond the original business intent, especially across APIs that were not designed with a strict delegated-actor model.

Failure mechanism: The implementation binds access to a generic consent or bearer token, then reuses that token across business relationships that have different approvers, entitlements, or resource boundaries. That creates replay, overreach, and audit failures even when the cryptography is sound.

Impact: A compromise or misuse can expose customer data, permit unauthorized payments or account actions, and make it difficult to prove which party authorised the transaction. In regulated environments, that also increases dispute risk and weakens the evidence needed for investigations and controls testing.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Non-Organizational Users)	Open banking delegation often spans external parties and downstream services.
	AC-3 — Access Enforcement	On-behalf-of flows must enforce scopes, audience, and resource boundaries.
	AU-2 — Event Logging	Delegation failures need auditable traces of who acted for whom and why.
Recommendation — Bind delegated access to the correct external identity and token context. Enforce token scope and audience at the resource server. Log delegation context for every on-behalf-of access decision.
ISO/IEC 27001:2022	A.5.15 — Access control	Delegated access in open banking depends on policy-bound authorization.
	A.8.5 — Secure authentication	Token-based on-behalf-of flows still depend on strong client authentication.
Recommendation — Define delegation rules that map to the real business relationship. Use strong client authentication before issuing delegated tokens.

Practitioner Guidance

What to verify: Confirm that each delegation path has an explicit business owner, an auditable approver, and a token shape that narrows audience, scope, and lifetime to that exact relationship. If the same token works across multiple relationship types, the design is probably too broad.

Decision rule: If the downstream service cannot tell whether the caller is acting for itself or on behalf of another party, add an explicit delegation claim or exchange the token before the call reaches the resource server.

Common mistake: Teams often test the happy path with one customer and one bank connection, then assume the same consent model will hold for corporate banking, aggregators, and partner integrations. That is where the hidden policy gap appears.

Practitioner takeaway: On-behalf-of access is only safe when the token expresses the real approval chain, not when it merely proves that somebody authenticated.