Open banking’s API growth is reshaping finance governance

At a glance

What this is: This is Kong's guide to open banking and open finance, showing how regulated API growth is replacing password sharing with tokenised consent, standardised access, and stronger participant governance.

Why it matters: It matters to IAM and API governance teams because open banking turns identity, consent, and third-party accountability into production controls that must scale across banks, fintechs, and partners.

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.
• The market is expected to grow at a compound annual growth rate of 27.6% between 2025 and 2030.
• Consumers in the United Kingdom made a record-breaking 14.5 million open banking payments in January 2024.
• The UK had 10 million active open banking users by July 2024, about 15% of the population.

Context

Open banking is a regulated model for sharing financial data and initiating payments through standardised APIs rather than handing credentials to third parties. In Kong's guide, the central shift is governance as much as technology: permissioned access, accredited participants, and auditable consent replace screen scraping and ad hoc integrations.

That shift matters because the control problem changes when data access is distributed across banks, fintechs, and enterprises. The article frames open banking as part of a broader open finance trajectory, where banks become platform operators and IAM teams have to govern third-party access, token lifecycles, and revocation behaviour across an expanding ecosystem.

The article also makes clear that API growth is no longer a niche channel issue. As open banking expands into open finance, financial institutions have to treat identity, authorisation, and partner oversight as core operating controls, not as integration details.

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: What breaks when open-banking access is not tightly governed?

A: When consent, authentication strength, and API security are managed separately, third-party access can drift beyond its intended scope. That creates inconsistent assurance between direct and delegated journeys, weak auditability, and a higher chance that legitimate-looking access masks an abusive transaction path.

Q: Why do tokenised open banking models need stronger audit trails than screen scraping?

A: Tokenised access creates a formal trust chain, which means every request, approval, and revocation should be traceable. Without audit trails, banks cannot prove whether a third party accessed only the approved accounts or payment paths. In regulated finance, the log becomes part of the control itself, not a secondary record.

Q: What is the difference between AIS and PIS from a governance perspective?

A: AIS governs read access to account and transaction data, while PIS governs the initiation of payments. The first is mainly about controlled disclosure and visibility, while the second adds direct financial action and therefore higher assurance requirements. Practitioners should not apply the same risk treatment to both, even when they use the same ecosystem.

Technical breakdown

OAuth 2.0, OIDC, and FAPI in open banking authorisation

Open banking replaces credential sharing with delegated authorisation. OAuth 2.0 provides the consented access token model, OpenID Connect adds identity context, and FAPI tightens the flow for financial use cases by reducing browser-based exposure and request tampering. The practical effect is that a third party never needs to see the user's password, but it still needs tightly scoped, time-bound authority to call APIs on the user's behalf. That distinction is what makes open banking governable at scale, while still leaving revocation, consent provenance, and auditability as first-class controls.

Practical implication: Map every open banking integration to its authorisation flow, token scope, and revocation path before exposing live financial data.

Why standardised AIS and PIS APIs change governance requirements

Account Information Services and Payment Initiation Services create interoperability by forcing common data structures and predictable endpoints across participants. That standardisation reduces integration friction, but it also means governance must extend beyond one bank's perimeter. If every participant can call the same account or payment endpoints, then policy consistency, error handling, and participant certification become part of access control, not separate programme concerns. In practice, the risk is not only abuse of one API, but inconsistent enforcement across many banks and fintechs using the same trust model.

Practical implication: Treat API schema consistency as a governance dependency and validate that partner onboarding enforces the same policy baseline everywhere.

FAPI 2.0 and pushed authorisation requests narrow the attack surface

The article's discussion of FAPI 2.0 centres on a subtle but important security change. Pushed authorisation requests move sensitive parameters away from the browser and into a direct server-to-server exchange, which removes a common tampering point and reduces leakage in transit. For finance APIs, that matters because small weaknesses in the authorisation step can undermine the whole trust chain. The control value here is not just stronger authentication, but a more defensible authorisation path that is easier to monitor and harder to manipulate.

Practical implication: Prefer authorisation designs that keep sensitive request parameters off the browser path and under server-controlled audit.

NHI Mgmt Group analysis

Consent is becoming the new perimeter in finance. Open banking shifts the governance problem from password protection to delegated authority, revocation, and proof of participant legitimacy. That is a different control plane, not a lighter version of the old one. IAM teams should read this as a move toward consent lifecycle governance rather than simple authentication hardening.

Open banking governance now spans the full third-party identity chain. A bank no longer controls only its own users and devices. It has to govern approved external companies, the tokens they hold, the APIs they can call, and the business purpose under which access remains valid. That makes participant accreditation, scope enforcement, and auditability part of identity governance, not adjacent compliance work.

Open finance expands the identity problem faster than it expands the policy model. The article shows the direction of travel toward insurance, pensions, investments, mortgages, and even cryptocurrency holdings. The control challenge is that many institutions will add new data domains faster than they add unified governance across those domains. The result is likely to be fragmented consent policy unless banks and fintechs standardise access controls around the whole data lifecycle.

API growth in finance is turning trust frameworks into operating architecture. The market signal is not merely more integrations, but more reliance on accredited participants, common standards, and monitorable authorisation flows. That favours organisations that can treat identity, policy, and telemetry as one system. Practitioners should expect governance maturity to matter as much as integration speed.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.

What this signals

Consent lifecycle governance will become the core IAM skill in open finance. As open banking expands into mortgages, pensions, investments, and other financial domains, the control question shifts from whether a partner is connected to whether its access remains justified. Teams that still manage this as a static integration list will miss the operational reality of rotating consent, changing scopes, and revocation pressure.

Open banking is pushing identity governance into the API layer. The article shows that trust now depends on accredited participants, token-bound authorisation, and monitored data exchange. That means banks and fintechs need governance models that cover both the human grant of consent and the machine enforcement of that consent across every downstream call.

For practitioners

• Define consent lifecycle controls Track how user consent is granted, scoped, renewed, and revoked across every open banking API and third-party relationship.
• Inventory accredited third parties Maintain a live register of approved participants, including the APIs, data classes, and payment functions each one can access.
• Enforce token scope limits Bind access tokens to the minimum data set and payment action required, then validate that scopes cannot be broadened downstream.
• Test authorisation paths for tampering Verify that sensitive request parameters are not exposed in browser-based flows and that pushed authorisation requests stay server-controlled.
• Align API governance with regulatory change Map open banking controls against evolving requirements such as FAPI 2.0, PSD3, and Section 1033 so policy changes do not lag implementation.

Key takeaways

• Open banking replaces credential sharing with delegated API access, which shifts the primary control problem toward consent, scope, and revocation.
• The scale evidence in the article shows that this is now a mass-market finance pattern, not a pilot, with both user adoption and transaction volume growing quickly.
• IAM and API teams need to govern third-party access as a lifecycle, because the trust boundary now lives in tokens, participant accreditation, and auditable authorisation flows.

Key terms

• Open Banking Access: 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.
• Account Information Service Provider: An Account Information Service Provider is a third party that accesses bank account data with customer consent to deliver insights, aggregation, or comparison services. These providers help consumers view financial information across institutions, but they require trusted APIs, clear permissions, and secure data handling.
• 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.
• Financial-grade APIs: Financial-grade APIs are API standards designed to support regulated data sharing with stronger identity assurance and access controls. They matter because they make authorisation, token handling, and trust relationships part of the security model, not just technical integration details.

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 building or maturing an IAM programme, it is worth exploring.