Open banking creates IAM and NHI challenges because external parties receive delegated access to sensitive financial data and payment functions. That access must be authenticated, authorised, logged, and revoked across different organisations. The problem is not the API itself, but the fact that trust is distributed outside the enterprise boundary.
Why This Matters for Security Teams
Open banking turns a bank’s internal identity model into a distributed trust problem. Third parties, fintechs, and aggregators often act on behalf of customers, but their access must still be authenticated, authorised, logged, and revoked with the same rigor as internal users. That creates nhi governance pressure because API clients, service accounts, tokens, and certificates now sit at the edge of financial risk.
The challenge is not just API security. It is lifecycle control across organisations that do not share the same IAM stack, approval workflows, or monitoring maturity. NIST Cybersecurity Framework 2.0 frames this as an identity and access governance issue, but open banking makes it harder because trust is delegated, time-bound, and frequently mediated by consent. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs both highlight that inconsistent control of non-human access is a recurring failure mode, not an edge case.
In practice, many security teams encounter over-permissioned API clients and weak revocation only after a third-party integration has already expanded its access beyond the original use case.
How It Works in Practice
Open banking usually relies on delegated authorisation, short-lived tokens, and scoped APIs, but the governance burden does not disappear just because the exchange is standards-based. Security teams need to distinguish between the customer’s consent, the third party’s operational identity, and the underlying NHI used to call the API. Those are different control points, even if they are chained together in one transaction.
Current guidance suggests treating each external integration as a separately governed workload identity with explicit purpose, scope, and expiry. That means mapping every client to a known owner, issuing credentials or tokens only for the minimum necessary duration, and revoking access when the consent window, contract, or business relationship changes. For stronger control, teams should pair API gateway enforcement with identity governance, so a token cannot be valid if the associated client registration, certificate, or trust anchor is no longer approved.
- Use strong client authentication for third-party applications, not shared secrets reused across integrations.
- Prefer short-lived credentials and rotate certificates or tokens on a defined schedule, not only after incidents.
- Log consent, token issuance, API scope changes, and revocation events in a way that supports audit across organisations.
- Enforce least privilege at the resource and operation level, not just at the application level.
The NIST Cybersecurity Framework 2.0 supports this kind of access governance, while IETF OAuth 2.0 Security Best Current Practice and OpenID Financial-grade API describe how to harden token-based trust in regulated API flows. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because open banking governance depends on the same lifecycle discipline: provision, validate, monitor, rotate, and revoke.
These controls tend to break down when third parties subcontract access to downstream processors because ownership, audit evidence, and revocation paths become fragmented.
Common Variations and Edge Cases
Tighter token scoping and revocation usually improves safety, but it also increases operational overhead, so organisations must balance faster partner onboarding against stronger control assurance. That tradeoff becomes sharper when banks support many fintechs, multi-jurisdiction consent models, or high-frequency payment initiation.
One common edge case is API aggregation, where a single third party brokers access to multiple banks and sub-processors. Another is long-lived “technical” credentials hiding behind otherwise modern consent flows. Best practice is evolving, but there is no universal standard for this yet: some ecosystems rely on mutual TLS and client assertions, while others lean more heavily on consent servers and gateway policy. The practical answer is to govern the full chain, not only the customer-facing consent step.
NHIMG’s 52 NHI Breaches Analysis shows why this matters operationally: access misuse often appears where secrets, service identities, and third-party boundaries intersect. The NIST Cybersecurity Framework 2.0 and the 2024 Non-Human Identity Security Report both reinforce the same practical point: if the organisation cannot prove who or what is calling the API, for how long, and under what authority, the governance model is incomplete.
In financial ecosystems, the hardest failures usually emerge when revoked consent and still-valid machine credentials are allowed to coexist.
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 CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Open banking depends on knowing and verifying external identities and their access scope. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Third-party API credentials need tight lifecycle and rotation control. |
| NIST AI RMF | Distributed trust and consent flows need AI-style governance of autonomy and accountability. |
Define ownership, monitoring, and escalation for every external workload that can act on financial data.
