Why do open banking APIs need identity controls as well as standards?

Why standards alone are not enough for open banking APIs

Open banking standards define how participants should exchange requests, responses, and consent signals, but they do not by themselves decide which party is allowed to act on a specific account or dataset. The practical gap is that a well-formed API call can still be the wrong caller, the wrong scope, or the wrong time. Identity controls supply the governance layer that turns interoperability into bounded, accountable access.

That distinction matters because API standardisation removes friction between systems, which is useful for scale but dangerous if access decisions remain implicit. For a security team, the real question is not whether the interface works, but whether the caller is authenticated, the entitlement is current, and the consent state is still valid.

A useful way to think about this is that standards define the contract, while identity controls enforce the decision. In open banking, those decisions usually include customer authorisation, token binding, scope limitation, session duration, revocation, and traceability. When those controls are weak, interoperability becomes a transport mechanism for overexposure rather than a safeguard for controlled sharing.

What identity controls add to consent, scope, and revocation

Identity controls bind an API transaction to a specific actor and a specific authority to act. That includes authenticating the third party, mapping it to a recognised application or organisation, limiting what data can be retrieved, and making revocation effective when consent changes. Without those checks, an API may remain technically reachable even after the business reason for access has ended.

This is where the identity layer becomes materially different from the standards layer. Standards can say that authorisation should exist, but they do not ensure that the authorisation is fresh, narrowly scoped, or attributable to the right party. The control objective is to prevent token reuse, hidden delegation, and stale access paths from surviving after an integration has been approved, changed, or withdrawn.

For open banking, that usually means pairing the protocol with strong API authentication and authorization, consent lifecycle management, and audit evidence that shows who accessed what and why. The OWASP API Security Top 10 is useful here because broken authorisation is exactly the failure mode that turns a valid API into an unsafe one. For implementation detail, OpenID Connect Core 1.0 shows how identity can be layered onto OAuth-based access rather than assumed by the transport itself.

Why the same standard can be safe in one bank and risky in another

The API standard may be identical across institutions, but the security outcome depends on how the bank governs identity, delegation, and lifecycle. Two firms can expose the same endpoints and follow the same spec, yet one enforces short-lived access, explicit customer consent, and strong client authentication while the other leaves broad scopes in place after initial onboarding. The second design is operationally interoperable but security-poor.

That is why open banking cannot be treated as a pure integration exercise. The security model depends on how identity is represented across participants, how revocation is propagated, and whether the institution can prove that access was approved at the time it occurred. In practice, this also means watching for integration drift, where an approved fintech relationship quietly expands beyond the original consent boundary.

For teams building or assessing these controls, the most relevant external anchor is the NIST SP 800-63 Digital Identity Guidelines, because open banking depends on assurance around authentication and binding between actor, credential, and transaction. Where the implementation is cloud-hosted, the CSA Cloud Controls Matrix reinforces the same point through IAM and audit expectations for controlled access.

Risk and Threat Considerations

Open banking increases the blast radius of a bad access decision because one weakly governed integration can expose high-value financial data across many accounts and many counterparties. The main threat is not just initial abuse, but persistence through stale consent, overbroad scopes, delegated access that outlives the business relationship, and token misuse after enrolment.

Failure mechanism: A standards-compliant API call is accepted even though the caller is overprivileged, the consent has been revoked or narrowed, or the access token remains valid longer than the underlying business approval. That creates an attack path in which interoperability masks an access-control failure.

Impact: Sensitive account data can be read, payments can be initiated, or customer trust can be undermined even though the integration appears conformant. At scale, the same weakness can turn third-party connectivity into a systemic exposure across multiple institutions and applications.

Practitioner Guidance

What to verify: Treat protocol conformance as the starting point, not the control objective. Verify that every live integration has a current consent record, a clear identity for the relying party, and a revocation path that actually stops access rather than only updating a policy file.

Decision rule: If you can explain an API integration only in terms of “it follows the standard,” the control set is incomplete. If you cannot point to the identity binding, scope boundary, and expiry condition for each active relationship, assume the API is exposing more than the business approved.

Practitioner takeaway: In open banking, interoperability is valuable only when identity turns it into governed access, otherwise the same standards that enable safe exchange can also make overreach easier to scale.

Related resources from NHI Mgmt Group

• Who is accountable when identity controls fail in open banking ecosystems?
• Why do digital banks need stronger identity controls when they expand Open Banking and API ecosystems?
• Why does PSD2-style open banking increase the need for stronger identity and authentication controls?
• What happens when open banking APIs are exposed without strong compliance controls?