A model in which authorised third parties can access banking data through APIs with the customer’s consent. It expands the identity surface because partner credentials, consent tokens, and application entitlements must be governed as non-human identities.
Expanded Definition
Open banking access is the controlled exposure of financial data and payment capabilities to authorised third parties through APIs, typically with customer consent and scoped permissions. In NHI terms, each partner application, token, certificate, and delegated entitlement behaves like a non-human identity that must be governed across issuance, rotation, revocation, and monitoring. The practical boundary is not the API alone but the trust relationship behind it, which is why the OWASP Non-Human Identity Top 10 is a useful reference point for treating third-party access as an identity problem, not just an integration pattern.
Definitions vary across vendors on whether open banking access starts with consent, token exchange, or downstream account retrieval, so governance teams should avoid assuming a single standard governs this yet. The operational reality is that partner onboarding, entitlement scoping, and consent lifecycle management all create identity state that can outlive the original customer approval if it is not actively revoked. The most common misapplication is treating API access as a purely technical integration, which occurs when consent, credentials, and application permissions are managed in separate tools without a shared revocation path.
Examples and Use Cases
Implementing open banking access rigorously often introduces latency in partner onboarding and friction in consent renewal, requiring organisations to weigh data sharing speed against tighter control of delegated access.
- A budgeting app retrieves transaction history through a bank API after customer consent, with the app’s client credential and refresh token treated as governable NHI assets.
- A payment initiation provider uses a scoped certificate and JIT access for specific endpoints, limiting blast radius if the partner environment is compromised.
- An aggregator revokes access when a customer disconnects the app, but the bank still has to verify that cached tokens, API keys, and entitlements are fully invalidated.
- A bank performs partner risk review using lessons from the Ultimate Guide to NHIs, then maps every third-party credential to an owner and expiry date.
- A security team benchmarks API authentication patterns against the OWASP Non-Human Identity Top 10 to catch overprivileged partner apps and missing rotation controls.
Because customer consent is often the visible event while identity governance sits behind the scenes, open banking programs frequently discover gaps only when partner access needs to be removed quickly. That is why many teams use the broader NHI lifecycle guidance in the Ultimate Guide to NHIs — Key Challenges and Risks to align onboarding, access review, and offboarding workflows.
Why It Matters in NHI Security
Open banking access expands the identity surface because third-party applications can hold the same operational power as internal services once a token or certificate is issued. NHIMG research shows that 92% of organisations expose NHIs to third parties, underscoring how partner-connected identity sprawl becomes a supply-chain security issue when revocation is slow or incomplete. If a bank cannot answer who owns a partner credential, what it can access, and when it expires, it cannot reliably contain compromise or prove least privilege.
The security risk is not just unauthorised access, but also stale permissions, mis-scoped consent, and weak offboarding when a partner app is abandoned or replaced. The 52 NHI Breaches Analysis reinforces a consistent pattern: identities that were meant to be temporary or delegated become persistent attack paths when governance breaks down. Organisationally, the issue becomes unavoidable after a partner breach, suspicious API activity, or a customer complaint reveals that access continued long after consent should have ended, at which point open banking access must be remediated as an identity incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers non-human identity secrets, tokens, and lifecycle weaknesses in delegated access. |
| NIST Zero Trust (SP 800-207) | AC-4 | Open banking access depends on enforced least privilege and continuous authorization decisions. |
| NIST CSF 2.0 | PR.AC-1 | This term depends on identity and access management for external entities and API consumers. |
Apply least privilege to API scopes and continuously verify partner access before each transaction.
