Open banking is exposing the limits of legacy IAM controls

At a glance

What this is: This is an analysis of how open banking is pushing financial services toward API-first identity patterns built on financial-grade APIs and enterprise IAM.

Why it matters: It matters because practitioners have to govern customer-facing API trust, access delegation, and lifecycle controls as banks modernise across human, NHI, and platform identity surfaces.

👉 Read Ping Identity's analysis of open banking, financial-grade APIs, and IAM

Context

Open banking is forcing financial institutions to treat identity as part of the customer experience layer, not just the authentication layer. In practice, that means API access, consent, and trust relationships now sit at the centre of how digital banking services are built and monetised.

The governance gap is that many incumbent identity programmes were designed around user login journeys, not standards-based API ecosystems. As banks adopt financial-grade APIs and API-first architectures, IAM teams need to think about delegated access, assurance, and lifecycle control as a continuous control plane.

For practitioners, the question is no longer whether open banking will change identity governance. It already has, and the organisations that fail to adapt will struggle to balance customer experience, security, and regulatory expectations.

Key questions

Q: How should IAM teams govern access in open banking environments?

A: IAM teams should govern open banking as a multi-party access problem, not a simple login problem. That means defining controls for customer authentication, consent, delegated access, token scope, and revocation across applications and service identities. The control objective is consistent policy across the full API access chain, not just a strong front-door experience.

Q: Why do financial-grade APIs matter for identity governance?

A: Financial-grade APIs matter because they raise the assurance required for regulated data sharing and make identity decisions part of the trust model. They force organisations to govern not only who logs in, but what is allowed to act, delegate, and persist after the initial request. That shifts identity governance into the architecture of the banking service itself.

Q: What do security teams get wrong about API-first banking?

A: They often focus on integration speed and customer experience while underestimating the number of identities involved in each access path. In practice, API-first banking introduces customers, apps, service accounts, and external partners into the same trust chain. If those identities are not governed consistently, revocation, audit, and scope control all become weaker.

Q: What is the difference between customer login controls and API access governance?

A: Customer login controls prove that a person authenticated, while API access governance controls what that identity or delegated application can do next. In open banking, the second problem is broader because access may continue through tokens, scopes, and partner integrations after the login event ends. Teams need both layers, but they are not the same control.

Technical breakdown

Financial-grade APIs and identity assurance

Financial-grade APIs are standards designed to make API interactions more trustworthy in regulated financial contexts. They typically add stronger requirements for authentication, authorisation, token handling, and request integrity than generic public APIs. That matters because open banking is not just an integration pattern, it is a trust framework for moving sensitive financial data across institutions and applications. The identity challenge is that assurance now has to survive across multiple parties, not just inside one enterprise boundary. Practical identity controls must therefore extend beyond login and into token governance, client authentication, and delegated access policy.

Practical implication: IAM teams should map API trust requirements to the controls that govern authentication, authorisation, and token lifecycle.

API-first banking changes the access model

An API-first model shifts banking services from monolithic channels to composable services that are consumed by applications, partners, and digital experiences. This changes the access model from direct user access to mediated access, where consent, scopes, and service-to-service trust determine what is allowed. In identity terms, the programme must govern not only the human customer but also the applications and backend services acting on their behalf. That creates a wider control surface for secrets, client credentials, certificate trust, and entitlement review.

Practical implication: identity architects should design separate governance for human, application, and service access paths in open banking environments.

Why enterprise IAM and open banking now intersect

Enterprise IAM becomes the enforcement layer for financial-grade APIs because it anchors who or what is allowed to initiate, delegate, and consume access. Open banking expands the number of identities involved in a transaction, including customers, apps, third-party services, and internal systems. Without strong IAM alignment, organisations can end up with fragmented trust decisions that are difficult to audit or revoke. The real issue is governance consistency across the entire access chain, not just strong authentication at the front door.

Practical implication: security teams should review whether their IAM stack can enforce consistent policy across every API consumer and delegated access path.

NHI Mgmt Group analysis

Open banking turns identity into a financial infrastructure control, not just a login mechanism. As banks expose services through APIs, identity decisions move into the path of product delivery, partner connectivity, and customer monetisation. That means IAM is no longer a supporting function around the channel, but a core part of how financial institutions prove trust and control access. Practitioners should treat this as an architectural shift, not a channel feature.

Financial-grade APIs create a stronger governance requirement than generic API security. The article points to standards-based access as the foundation of better digital banking, which means simple token issuance is not enough. Financial services teams need to govern assurance, delegation, and revocation in ways that match regulated data-sharing relationships. The implication is that open banking security must be measured as a lifecycle problem, not a point-in-time authentication problem.

Open banking widens the identity perimeter across customers, applications, and service identities. That broadens the set of subjects IAM teams must account for, even when the article focuses on customer experience. The same governance logic that applies to machine identities and delegated workloads now matters in customer-facing banking APIs. Practitioners should expect identity governance to become more distributed as financial services become more composable.

Consent and trust relationships are becoming the new access review boundary. In an open banking model, the important question is not only who authenticated, but what was authorised to continue operating after the initial exchange. This raises the bar for auditability, revocation, and policy consistency across different service providers. The practical conclusion is that access governance must follow the transaction, not stop at the login event.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• From our research: The Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why access lifecycle discipline is a control boundary, not an afterthought.

What this signals

Open banking is pushing financial institutions toward a broader identity perimeter where customer identity, application identity, and service identity all matter at once. The programme risk is not only weak authentication, but weak governance over delegated access and revocation across external ecosystems.

Identity perimeter drift: as API-first banking expands, the control boundary moves from the login screen to the transaction lifecycle. Teams that still think in channel-centric IAM terms will miss where accountability, token scope, and partner access actually need to be governed.

For security and IAM leaders, the practical signal is that financial-grade API adoption should trigger a review of entitlement models, audit trails, and offboarding logic across partner integrations. NIST Cybersecurity Framework 2.0 remains useful here because the issue spans governance, protection, detection, and recovery, not just authentication.

For practitioners

• Map API trust to identity controls Inventory which financial-grade API flows depend on customer identity, application identity, and service credentials, then map each flow to the controlling IAM policy and revocation path.
• Separate consent from authentication governance Treat user authentication, consent capture, and delegated authorisation as distinct control points so that access decisions can be reviewed and revoked independently.
• Review token and client credential lifecycle Check whether API tokens, client secrets, and certificates are rotated, scoped, and retired on a schedule that matches partner and customer relationship changes.
• Extend audit trails across partner interactions Ensure logging covers the full access chain from request initiation through downstream API use so that accountability does not disappear once an external application is involved.

Key takeaways

• Open banking is turning identity governance into a core part of financial service delivery, not a back-office control.
• Financial-grade APIs extend the access problem across customers, applications, and delegated service identities, which raises the audit and revocation burden.
• IAM teams should focus on consent, token lifecycle, and consistent policy enforcement across the full API chain, not only on customer login security.

Key terms

• 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.
• Delegated authorisation: Delegated authorisation is access granted to one application or service to act on behalf of another identity. In open banking, it is the mechanism that makes third-party access possible, but it also expands the number of trust decisions that must be governed, logged, and revoked.
• Identity perimeter: The identity perimeter is the set of people, applications, services, and partners whose access decisions must be governed as one system. In API-first environments, it extends beyond the login boundary and includes every token, scope, and downstream service that can continue access.

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 Ping Identity: Open banking is rapidly becoming a critical plank of digital innovation in financial services. Read the original.