Banks should treat B2B open banking as a delegation problem, not just a customer-consent problem. The practical approach is to model who has authority, who performs the action, and what scope of access is actually needed. Configurable claims and scopes can express that relationship per client, allowing on-behalf-of access while keeping policies consistent and reducing custom code across integrations.
How to model B2B open banking consent without hard-coding every case
The core design choice is to treat consent as an authorisation policy that can vary by client, rather than as a fixed set of one-off API exceptions. That means separating the subject who grants authority, the actor who calls the API, and the scope of actions allowed. In practice, banks need policy-driven claims, scopes, and delegation rules that can be configured per relationship.
That separation matters because B2B open banking often involves a user acting through a business relationship, a platform, or a delegated third party. If the bank hard-codes each integration, every new partner becomes a bespoke security case. If the bank models authority, context, and scope consistently, the same controls can support many customer, partner, and service patterns.
A useful design pattern is to define a small number of policy primitives, such as delegated authority, consented data classes, action scope, expiry, and revocation. Those primitives can then be combined to express who may read, initiate, or approve a transaction on behalf of a business customer without rewriting the trust model each time.
Why configurable claims and scopes work better than bespoke integration logic
Configurable claims let the bank carry relationship context through the authorisation flow, so the API can tell whether access is direct, delegated, or constrained to a specific business purpose. Scopes then limit what the client can do, while claims add the extra context that simple scopes alone often cannot express. That keeps the API policy-readable instead of embedding partner logic in code.
This approach also improves consistency across channels and products. If the same claims and scopes drive dashboards, consent records, and API enforcement, the bank reduces drift between what was agreed, what was granted, and what is actually enforced. It also becomes easier to review, audit, and revoke access without tracing custom code paths for each integration.
For banks operating in regulated environments, configurable consent design aligns naturally with data minimisation and purpose limitation. The consent artefact should describe the permitted business action and data access in a way that can be enforced by policy, not just documented in legal text. For a privacy-oriented reference point, see the EU General Data Protection Regulation (GDPR), and for a bank-specific perspective on open banking and financial-services identity obligations, the Financial Services Identity Security Guide explains why banking controls need to balance delegated access, third parties, and regulatory obligations.
What banks should standardise in the authorisation layer
The authorisation layer should standardise the mechanics that every partner must use, even when the business terms differ. That usually means a common pattern for consent creation, consent refresh, consent expiry, token issuance, and revocation. The implementation can still vary by client, but the policy model should not.
- Use explicit claims for relationship context, such as acting on behalf of a legal entity or business unit.
- Bind scopes to concrete API actions, not to vague customer narratives.
- Separate approval from execution when a process needs dual control or step-up authorisation.
- Make revocation and time limits first-class so access can expire cleanly.
- Log the policy decision, not just the token event, so reviewers can reconstruct why access was granted.
For authorisation model choices, the Authorisation Models Guide is a good companion when deciding how much of the decision should come from roles, attributes, relationships, or policy. When access is granted to external parties, the Third-Party, B2B and Contractor Access Guide also helps because the same sponsorship, least-privilege, and review principles apply to business delegations.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | B2B consent needs governed account and delegated access lifecycle control. |
| AC-3 — Access Enforcement | Configurable claims and scopes are access decisions that must be enforced consistently. | |
| IA-5 — Authenticator Management | Consent-driven access depends on controlled issuance, rotation, and revocation of tokens and secrets. | |
| Recommendation — Define and review delegated access accounts with clear ownership, expiry, and revocation. Enforce policy-based scope checks on every B2B API request. Manage tokens and secrets with defined issuance, rotation, and revocation processes. | ||
| OWASP ASVS | V8 — Authorization | The page is fundamentally about enforcing fine-grained API authorisation for delegated access. |
| V10 — OAuth and OIDC | B2B open banking commonly uses OAuth-style delegated access and scoped tokens. | |
| Recommendation — Implement fine-grained authorization checks for delegated and on-behalf-of requests. Use delegated-token flows that bind scopes and consent to the intended client. | ||
Practitioner Guidance
What to prioritise: Start by defining the minimum policy model that can express authority, actor, scope, and expiry without any partner-specific branching. If you cannot explain a consent state in those four terms, the design is still too bespoke.
What to verify: Test whether the same policy can support at least two materially different B2B relationships, such as a delegated payment flow and a delegated data-access flow. If not, the model probably encodes integration detail instead of reusable access logic.
Common mistake: Treating scopes as a substitute for business context. Scopes are effective when they are paired with claims that tell the bank whose authority is being exercised and under what delegation terms.
Practitioner takeaway: The best design is the one that makes every new client look like a policy instance, not a new code path, while still keeping revocation, auditability, and delegated authority explicit.
Related resources from NHI Mgmt Group
- How should banks and insurers design a superapp so customers can complete multiple services without weakening access control?
- How should teams implement attribute-based access control in a Go web application without hard-coding access rules into the app?
- How should banks and FinTech teams approach Open Banking when API access, customer consent, and service integration all need to work together?
- How should banks expand open banking without weakening customer data control?
