Open banking’s API growth is reshaping finance governance

At a glance

What this is: This is a Kong guide to open banking that argues API standardisation, consent-based access, and stronger governance are now central to modern finance.

Why it matters: It matters to IAM, NHI, and security teams because open banking turns regulated API access into an identity, consent, and lifecycle problem, not just an integration problem.

By the numbers:

• The global open banking market was valued at $31.61 billion in 2024 and is projected to reach $135.17 billion by 2030.
• In January 2024, consumers in the United Kingdom made a record-breaking 14.5 million open banking payments.
• By July 2024, the UK reached 10 million active open banking users.

👉 Read Kong's guide to open banking APIs, regulations, and finance

Context

Open banking is a regulated model for sharing financial data through standard APIs instead of screen scraping or password sharing. The primary identity question is who is allowed to request data, on what consent basis, and under what controls across banks, fintechs, and enterprise integrators.

The article frames open banking as an API-driven shift in finance, but the real governance issue is lifecycle control over tokens, consent, and third-party access. That places it squarely in IAM, API security, and broader identity governance, especially where external organisations can initiate payment or read account data.

Key questions

Q: How should security teams govern consent-based API access in open banking?

A: Security teams should treat consent as a controlled entitlement with scope, expiry, monitoring, and revocation. The key is to align what the user approved with what the third party can actually do, then ensure the permission is automatically removed when the relationship or use case ends. Without that lifecycle discipline, delegated access becomes persistent risk.

Q: Why do open banking APIs create IAM and NHI governance challenges?

A: 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.

Q: What breaks when API scopes are too broad in open banking?

A: Broad scopes collapse least-privilege controls and make it harder to prove that a third party accessed only what it needed. In practice, that increases the blast radius of a compromised token, weakens auditability, and creates downstream disputes about whether a payment or data pull was actually authorised.

Q: Who is accountable when a third-party open banking integration misuses access?

A: Accountability sits with both the bank and the third party, but the bank remains responsible for how access is granted, scoped, monitored, and revoked. Governance frameworks should define ownership before launch, not after an incident. That is the only way to make external access auditable and enforceable.

Technical breakdown

OAuth 2.0, OIDC, and FAPI in open banking

Open banking security depends on delegated authorisation rather than credential sharing. OAuth 2.0 grants scoped access, OpenID Connect supports identity confirmation, and Financial-Grade API profiles add stronger protections for financial transactions. FAPI 2.0 tightens this model further with features such as Pushed Authorization Requests, which move parameters away from the browser and reduce tampering risk. The technical point is not simply encryption or transport security. It is that access is expressed as a bounded, revocable, auditable delegation chain between a customer, an accredited third party, and a bank.

Practical implication: treat consent, token scope, and revocation as governance controls, not implementation details.

Standardised banking APIs and permission scope

Open banking depends on predictable endpoints and data schemas so third parties can interact with many institutions in the same way. That standardisation enables account information services, payment initiation, and recurring payment use cases, but it also makes scope definition critical. If scopes are too broad, the bank loses meaningful control over what a third party can do. If scopes are too narrow or inconsistently implemented, interoperability breaks and partners build workarounds. The architectural lesson is that standardisation only works when entitlement boundaries are enforced consistently across all participants.

Practical implication: align API design, scopes, and entitlement policies so permission boundaries stay consistent across banks and partners.

Governance, accreditation, and audit trails

The guide emphasises that open banking is not a trust-free API model. It depends on accredited participants, technical certification, monitoring, and dispute procedures that make access accountable after the fact. Audit trails matter because they connect a consent event to the specific API call, data object, and responding party. Without that chain, banks cannot prove whether access was properly authorised or operationally contained. In governance terms, this is identity lifecycle management for external access: who joins, what access they receive, how it is monitored, and how it is revoked when the relationship changes.

Practical implication: build onboarding, monitoring, and offboarding controls for third-party API access with the same discipline used for privileged internal identities.

Threat narrative

Attacker objective: The objective is to turn legitimate delegated access into unauthorised financial or data access without needing the victim's password.

1. Entry occurs when a third party or consumer authorises API access through an open banking flow rather than by sharing bank credentials directly.
2. Escalation occurs if scopes, consent handling, or token controls are too broad, allowing the external party to retrieve more data or initiate more payments than intended.
3. Impact occurs when delegated access is abused, misrouted, or insufficiently monitored, leading to unauthorised financial activity, data exposure, or failed accountability.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Open banking is an identity governance problem wrapped in API language. The article rightly describes regulation, interoperability, and innovation, but the operating control surface is consent, token scope, and revocation. Banks do not just expose endpoints; they delegate authority to external actors that must be on-boarded, monitored, and offboarded with lifecycle discipline. The practitioner conclusion is that API strategy and identity governance now converge in the same control plane.

Consent does not equal risk acceptance unless it is lifecycle-managed. Open banking works because the user can authorise access, but that authorisation is only safe if it is time-bounded, narrow, and auditable across the full third-party relationship. This is where many programmes drift from policy to implementation, especially when tokens outlive the business need or when partner entitlements are not revisited after onboarding. The practitioner conclusion is that consent review must be treated as an entitlement review, not a legal formality.

Standardised APIs reduce integration friction, but they also standardise failure modes. Once banks and fintechs converge on common endpoints, the same weak assumptions can repeat across many ecosystems: broad scopes, weak auditability, inconsistent revocation, and unclear accountability. That is why open banking maturity depends on governance consistency more than technical compatibility. The practitioner conclusion is that shared API standards need shared access governance standards.

Identity lifecycle controls are now a trust requirement for financial ecosystems. Open banking extends access beyond the enterprise boundary, so joiner, mover, and leaver processes must cover third parties, service integrations, and payment actors. This aligns directly with NIST CSF access control expectations and Zero Trust thinking, where trust is continuously verified rather than assumed at onboarding. The practitioner conclusion is that external identity lifecycle management is part of financial resilience, not an optional compliance layer.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For a lifecycle view of the external access problem, see NHI Lifecycle Management Guide and align it with the consent and offboarding model used in open banking.

What this signals

Consent-led finance will fail if external identity lifecycle management stays manual. Open banking expands the number of non-human and third-party access paths that must be reviewed, revoked, and evidenced. The governance gap is not the API specification itself, but the programme discipline required to retire access when partner relationships, permissions, or regulations change. Teams should expect entitlement review to become a recurring control, not a launch activity.

API standardisation increases the value of a shared control model. As open banking moves toward broader open finance, banks and fintechs will need consistent ways to trace consent, validate token scope, and prove revocation. That is where the NHI Lifecycle Management Guide becomes useful for programme design, because external access now behaves like governed machine identity rather than a one-off integration.

For practitioners

• Map every open banking integration to a named identity owner Assign ownership for each third-party API relationship, including who approves access, who reviews scope changes, and who revokes access when the business relationship ends. Document the owner in the same system used for entitlement and contract tracking so accountability does not disappear across teams.
• Treat consent scopes as enforceable entitlements Review whether each API scope matches the minimum data or payment action required, then align technical scopes with business purpose and expiry. Reassess any token or consent that remains active after the original use case has completed.
• Build offboarding into partner access governance Make revocation part of the standard third-party lifecycle, including API key removal, token invalidation, and partner certification withdrawal when needed. Use the NHI Lifecycle Management Guide to pressure-test whether external access can be fully withdrawn without manual exceptions.
• Audit audit trails for end-to-end accountability Verify that each API call can be traced back to a specific consent event, user, partner, and data object. If logs cannot answer those questions, the governance model cannot reliably support dispute handling or incident response.

Key takeaways

• Open banking turns financial access into an identity and lifecycle problem, not just an API design problem.
• The scale is accelerating, with the market projected to more than quadruple by 2030 and UK usage already reaching tens of millions of interactions.
• Practitioners should focus on consent scope, revocation, and offboarding because delegated access is only safe when its lifecycle is enforceable.

Key terms

• Open Banking: A regulated model that lets customers share financial data or initiate payments through standard APIs instead of credential sharing. It shifts access control from passwords to delegated, consent-based permissions that must be scoped, monitored, and revoked across organisations.
• Consent Scope: The exact set of data types or payment actions a customer has authorised a third party to access. In practice, scope is the boundary that determines whether delegated access stays narrow and auditable or becomes too broad to govern safely.
• Payment Initiation Service: An open banking service that allows an approved third party to request payments from a user’s bank account. It is more sensitive than read-only data access because it directly affects funds movement and requires stronger accountability, validation, and revocation controls.
• Third-Party Access Lifecycle: The full sequence of onboarding, monitoring, review, and offboarding for external organisations that can access financial APIs. It is the governance mechanism that keeps delegated access aligned to business need and ensures it can be removed when trust changes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Open Banking: The Guide on APIs, Regulations, and the Future of Finance. Read the original.