Open banking proof is not enough without continuous API testing

At a glance

What this is: This is an analysis of why formally secure open banking protocols can still be unsafe in production when implementation, integration, and monitoring gaps remain.

Why it matters: It matters to IAM and security teams because open banking depends on identity, consent, token handling, and third-party trust boundaries that fail outside the protocol model.

By the numbers:

• The UK ecosystem carried 16.5 million user connections, up from 12.1 million a year earlier.
• The ecosystem handled 24 billion successful API calls over the year by December 2025.
• 145 regulated providers had live open banking propositions, with another 406 firms acting as their agents as of March 2025.

👉 Read Equixly's analysis of open banking protocol proofs and continuous API testing

Context

Open banking security breaks when teams confuse protocol correctness with deployment security. A formally verified API can still be undermined by weak TLS handling, OAuth token leakage, unsafe redirects, broken session enforcement, and third-party integrations that expand the trust boundary beyond what the proof covered.

That gap matters because open banking is also an identity and consent problem. Customer authentication, token issuance, provider validation, and access revocation all depend on identity controls that have to work in the live system, not just in the model. In regulated environments, the starting position described here is common rather than exceptional.

Continuous testing is the practical response to that mismatch. It checks whether the bank’s current build, configuration, and partner integrations still behave the way the protocol assumes, which is why this topic sits at the intersection of IAM, PAM, and application security.

Key questions

Q: How should security teams test open banking APIs in production without disrupting service?

A: Use production-safe continuous penetration testing that exercises authentication, consent, and authorization paths without moving funds or exposing live customer data. The goal is to validate runtime behaviour after each meaningful change, especially where third-party integrations, redirect handling, and session controls can alter the real attack surface.

Q: Why do formally verified API protocols still fail in live banking systems?

A: Because formal proof only covers the assumptions in the model, while the live system also depends on TLS configuration, certificate handling, redirects, logging, token storage, and partner integrations. If any of those layers drift, the protocol may remain sound in theory while the deployment becomes unsafe in practice.

Q: What breaks when consent and token lifecycle controls are weak in open banking?

A: Users can believe access has ended while delegated tokens, sessions, or partner-side permissions still remain active. That creates residual access after logout or revocation, which broadens the window for account exposure, transaction visibility, and authorization abuse across connected providers.

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

Why formal verification stops at the protocol boundary

Formal verification proves properties about a model, not the bank’s live environment. In the open banking context, that model can confirm message flow, token handling, and security goals under defined assumptions, but it cannot inspect certificate validation, proxy behaviour, logging paths, browser redirects, or release-time misconfiguration. The gap matters because attackers rarely need to break the protocol itself. They look for the places where implementation drift, bad integrations, or unsafe operational choices violate the assumptions the proof relies on.

Practical implication: treat formal proof as design assurance, not operational assurance.

How OAuth, TLS, and consent fail in production

Open banking depends on several identity-heavy controls working together. OAuth 2.0 issues delegated access tokens, OpenID Connect authenticates the user, TLS protects transport, and consent logic is supposed to limit what third parties can reach. In production, each layer can fail independently. Tokens can leak through logs or redirects, certificates can be checked incorrectly, consent can outlive revocation, and session controls can allow access to continue after the user thinks it ended. The weakness is not a single control, but the interaction between controls that were designed separately.

Practical implication: test the combined authentication, consent, and session paths as one control plane.

Why continuous penetration testing matters for third-party API trust

Continuous penetration testing is the operational answer to systems that change faster than annual or quarterly assessments. In open banking, third-party providers connect into the bank’s API estate with their own permissions, credentials, and business logic, creating a trust chain that can fail at the edges. A scanner can confirm endpoints exist, but it usually will not reason through chained calls, authorization order, or cross-service behaviour. An adversarial test can. That is especially important where business logic flaws emerge only when multiple APIs are exercised in sequence.

Practical implication: validate third-party integrations with production-safe adversarial testing, not endpoint-by-endpoint scanning.

Threat narrative

Attacker objective: The attacker aims to turn trusted API access into unauthorized account visibility, transaction exposure, or downstream financial data access.

1. Entry occurs through a live open banking integration, a shadow API, or a third-party trust path that exposes authentication or consent logic to attacker probing.
2. Credential or token abuse follows when OAuth grants, session handling, or redirect flows leak or over-extend delegated access.
3. Escalation happens through authorization bypass, chained API calls, or partner trust failures that expose account and transaction data beyond the intended scope.

NHI Mgmt Group analysis

Continuous testing is now a control requirement, not a security luxury. Open banking exposes a core governance mistake: teams often certify the protocol and then assume the deployment inherits that assurance. In reality, the live system is where certificate handling, redirects, session expiry, and third-party integrations either preserve or destroy security. Practitioners should treat production-safe testing as part of the control stack, not as a periodic validation exercise.

Identity and consent are the real attack surface in open banking. OAuth tokens, OpenID Connect sessions, and consent lifecycles define what a third party can do, but those artefacts are only as strong as their implementation and revocation handling. That makes this a classic identity governance problem in a payment context, not just an application security issue. Teams need to manage delegated access with the same discipline they apply to privileged human access.

Continuous penetration testing reveals a shadow API governance gap. New endpoints, partner integrations, and internal service routes appear faster than formal review cycles can track them. Shadow API sprawl: unmanaged or poorly governed API surfaces that sit outside intended assurance processes. Once that sprawl exists, a verified protocol can still be undermined by unverified implementation paths, and practitioners should assume any untested route is a live risk.

Operational resilience for financial APIs depends on proving the live state, not the intended state. The useful question is no longer whether the architecture is secure in theory, but whether today’s build still matches that theory after each change. That aligns open banking assurance with continuous validation, change control, and evidence-based risk acceptance. Practitioners should reframe testing as an ongoing governance function.

For identity teams, third-party API trust now behaves like ephemeral privilege with hidden persistence. Access granted through consent and tokens can appear temporary while still persisting across sessions, partner systems, and backend workflows. That creates a governance blind spot that is structurally similar to unmanaged non-human access. Teams should therefore bring NHI-style lifecycle thinking into open banking access oversight.

What this signals

Open banking teams should expect assurance programs to move from periodic evidence gathering to continuous runtime validation. When the trust boundary includes OAuth grants, third-party providers, and live customer consent, the important question becomes whether the system still behaves as designed after every release, configuration change, and partner update.

Delegated access drift: access that appears temporary in the user interface but persists through tokens, sessions, or downstream integrations. That drift creates a governance problem that IAM and application security teams need to treat as one control plane, especially when open banking APIs are tied to regulated financial services.

The operational signal is simple: if your API tests do not exercise chained calls, consent revocation, and partner-specific authorization flows, you are probably testing the wrong thing. Teams should pair continuous testing with lifecycle controls for tokens and third-party access, then anchor those controls in standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the NIST control families that cover access management.

For practitioners

• Continuously validate authentication and consent paths Test the full chain from user authentication through token issuance, redirect handling, consent capture, and revocation on every material release. Include negative testing for expired sessions, withdrawn consent, and malformed callbacks so the test covers actual runtime behaviour, not only endpoint reachability.
• Map third-party API trust boundaries end to end Inventory every regulated provider, agent, and downstream dependency that can influence access to open banking data. Classify which systems can issue, store, refresh, or replay tokens, then tie those paths to explicit ownership and offboarding controls.
• Test for business logic and authorization chaining Prioritise scenarios where correct individual calls become unsafe when executed in sequence. Focus on broken object level authorisation, consent leakage, and privilege escalation across multiple API calls, because those weaknesses often escape traditional scanners.
• Treat shadow APIs as governance defects Detect endpoints that appear outside the formal inventory and subject them to the same control review as sanctioned interfaces. Where an API exists without clear owner, test coverage, or lifecycle control, assume it can become an unintended access path.

Key takeaways

• A formally secure protocol can still produce an insecure live service when implementation, integration, and monitoring are weak.
• Open banking risk concentrates in identity, consent, and third-party trust boundaries, not just in the API schema.
• Continuous penetration testing is the practical control that keeps production behaviour aligned with the security assumptions behind the protocol.

Key terms

• Formal Verification: Formal verification is the mathematical proof that a protocol or system model satisfies defined security properties. It is useful for proving design logic, but it does not by itself validate real-world configuration, integration, logging, or runtime behaviour.
• Continuous Penetration Testing as a Service: A delivery model that runs penetration testing as an ongoing process rather than a one-time engagement. It uses change detection, human validation, and remediation loops to keep security findings aligned with the current environment instead of a stale snapshot.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Delegated access drift: The point at which a valid token or OAuth grant begins being used in ways that no longer match the original user intent. In practice, this shows up as mailbox reconnaissance, inbox-rule changes, or data access that follows the sign-in event but does not fit normal user behaviour.

What's in the full article

Equixly's full blog post covers the operational detail this post intentionally leaves for the source:

• How the continuous penetration testing workflow reasons through chained API calls and trust boundaries in live banking systems.
• Examples of business logic and authorization bypass scenarios that only appear when multiple endpoints are tested together.
• How production-safe testing is framed to avoid disrupting customer transactions or exposing live financial data.
• The practical difference between a formal protocol proof and runtime validation of a deployed open banking stack.

👉 The full Equixly post covers the protocol model, runtime attack paths, and the testing approach in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need a rigorous foundation for governing delegated access across modern identity programmes.