Open banking proof is not enough without continuous API testing

At a glance

What this is: Equixly shows that a formally verified open banking protocol can still be unsafe in production when live TLS, OAuth, consent, and integration behaviour diverge from the model.

Why it matters: IAM and API security teams need to treat open banking as a deployment-governance problem as much as a protocol problem, because assurance at design time does not remove runtime authorization and session risk.

By the numbers:

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

Context

Open banking security depends on both protocol design and the way that design is implemented in a live banking environment. A formal proof can show that a protocol is logically sound, but it cannot by itself prove that token handling, consent enforcement, certificate validation, or session control are correctly operated once the API is connected to real systems and third parties.

That gap matters because open banking combines regulated customer access, external providers, and persistent API traffic. The identity and authorization problem is not only who may authenticate, but whether the live service preserves those permissions safely across redirects, sessions, and delegated access chains. In that sense, the control problem sits at the boundary of API security and identity governance.

The practical lesson is that assurance must follow the running service, not stop at the model. In regulated environments, continuous testing becomes the mechanism that checks whether implementation drift has undermined the assumptions on which the protocol proof depended.

Key questions

Q: What breaks when a formally verified open banking protocol is deployed without continuous testing?

A: The proof still holds for the abstract model, but the real service can fail at TLS, OAuth, consent, redirect handling, session expiry, or third-party integration. That is why the assurance problem shifts from design correctness to runtime correctness. In regulated finance, the deployment is what customers use, so the live system must be tested continuously.

Q: Why do open banking APIs create more authorization risk than many other application interfaces?

A: Open banking APIs increase authorization risk because they combine unique business logic, multiple teams, and layered access rules across customers, partners, developers, and admins. As APIs change quickly, policy drift becomes common. That makes Broken Object Level Authorization especially dangerous, since a small logic mistake can expose data or actions that were never meant to be reachable.

Q: What do security teams get wrong about open banking penetration testing?

A: They often test too late and too narrowly. A scheduled assessment against a stable snapshot misses the drift created by code changes, new endpoints, and partner integrations. Continuous testing is needed because open banking behaviour changes with releases, and the highest-risk issues often appear only when calls are chained in real workflows.

Q: How should banks govern open banking consent and access after a live release?

A: They should treat consent, authorization, and session control as operational controls that need continuous verification, not one-time certification. That means confirming revocation works immediately, sessions end when expected, and partner access stays within the intended boundary. In practice, governance must follow the running service, because that is where customer risk lives.

Technical breakdown

Why protocol proof does not cover the live API stack

Formal verification proves properties of an abstract protocol model. It does not inspect the bank’s actual deployment choices, such as TLS configuration, certificate validation, redirect handling, token storage, logging, session expiry, or downstream integration behaviour. That distinction matters because security failures usually arise at the boundaries between specifications and implementation. A sound protocol can still be wrapped in insecure code, permissive infrastructure, or weak operational controls. In open banking, the model may assume ideal behaviour for authentication and consent, while the production system must handle browsers, proxies, mobile apps, partner systems, and release churn. The runtime environment is therefore the real security boundary.

Practical implication: Treat formal proof as design assurance only, then test the deployed API, not the abstract protocol.

Where OAuth, consent, and session logic tend to diverge

Open banking depends on OAuth 2.0, OpenID Connect, and consent workflows to bind access to the right user and the right provider. In practice, those controls fail when tokens leak into logs, browser history, analytics tools, mobile storage, or unsafe redirects. Consent can also be weakened if revocation is not immediate, sessions survive logout, or CSRF and authorization checks allow a user to be steered into approving the wrong party. These are not theoretical defects in the protocol itself. They are implementation and lifecycle failures that only appear when authentication, authorization, and session state interact under real usage and adversarial sequencing.

Practical implication: Test token handling, consent revocation, and session termination together, because each can fail without breaking the others.

How continuous penetration testing catches API drift

Continuous penetration testing keeps pace with the release cycle, so each material change to endpoints, authentication, or third-party integrations is assessed while it is still live. That approach is especially important in open banking because partner connections create compound risk: a weakness in one integration can expose multiple systems through shared credentials, shared flows, or unexpected call sequences. Testing needs to model the API as an attacker would, chaining requests and checking whether authorization depends on order, context, or hidden trust assumptions. This is where scanners often miss the issue and adversarial testing finds it.

Practical implication: Run continuous tests against changed endpoints and partner flows so authorization bypasses are found before release.

Threat narrative

Attacker objective: The attacker aims to exploit the gap between protocol soundness and live implementation to access financial data or authorized actions that should have remained out of reach.

1. Entry occurs through the live open banking API surface, where the attacker or tester exercises authentication, consent, and redirect flows against the production deployment.
2. Credential or token abuse can follow when OAuth artifacts, sessions, or certificates behave differently in production than they did in the verified model.
3. Escalation happens when business logic, authorization sequencing, or third-party trust boundaries allow access beyond the intended user or provider scope.
4. Impact is exposure of account data, transaction data, or other regulated financial information through a deployment that passed design-level assurance but failed runtime assurance.

Breaches seen in the wild

• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Open banking security debt is now a deployment problem, not a protocol problem. The article’s core distinction is that formal proof can validate the logic of an API design while leaving the production service exposed to everything that happens after release. That means banking teams should stop treating assurance as a one-time protocol milestone and start treating it as a runtime governance duty. The practical conclusion is that live configuration drift is the control gap that matters.

API security and identity governance now overlap at the consent boundary. In open banking, OAuth, OpenID Connect, and session handling are effectively identity controls because they decide who gets what access, for how long, and through which third party. If token handling, revocation, or redirect logic is weak, the system has an identity problem even if the protocol remains formally correct. Practitioners should read open banking assurance as part of access governance, not just application security.

Continuous testing is the only assurance model that matches release-speed finance. The article shows why scheduled assessments are too slow for systems that change with every integration, code push, or partner update. A bank can satisfy a proof obligation and still fail operationally if a later release changes trust boundaries. The field implication is clear: assurance has to move from static confidence to continuous validation, or risk accumulates faster than governance can certify it.

Implementation drift is the named concept that explains most of the gap here. The article’s strongest contribution is showing that verified assumptions break when the deployed service no longer matches the model. That applies directly to open banking APIs, but the governance lesson extends to any regulated API estate built from a secure design and run through changing integrations. Practitioners should assume the live service is the system that matters, not the proof artifact.

Shadow API behaviour is a material open banking risk even when the protocol is correct. The article points to hidden endpoints and integration paths that appear outside formal governance as deployments evolve. Those paths can bypass the assumptions tested in the model and create unauthorised access routes the architecture never intended. The practitioner takeaway is to govern the full API inventory continuously, not just the documented interface.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: API Key Management Guide

What this signals

Implementation drift is the key open banking control problem. A formally verified API can still become unsafe when live redirects, token handling, or consent flows change after release. Teams should therefore treat the production interface as the system of record and test it continuously as part of operational resilience.

API governance and identity governance are converging in regulated finance. Open banking access decisions are identity decisions because they determine who may act on behalf of the customer and through which third party. The control agenda should therefore include explicit testing of authorization sequences, partner boundaries, and consent revocation paths, not just protocol conformance.

Open banking programmes should also watch for shadow API growth as integrations multiply. Each undocumented endpoint or partner-specific workflow expands the attack surface that formal proof never covered, so inventory discipline becomes a security control rather than an administrative task.

For practitioners

• Validate the deployed API, not just the protocol Test the live open banking service after each material release, with particular attention to TLS, redirects, token handling, and consent enforcement.
• Test authentication and consent as one control path Verify that authentication, authorization, revocation, and logout all fail closed together when a customer withdraws consent or a session ends.
• Exercise third-party integration sequences Chain API calls across bank and TPP workflows to surface authorization bypasses that only appear when requests arrive in a specific order.
• Monitor for shadow API drift Track endpoints, redirects, and partner-created access paths as part of the production inventory so new routes are tested before they become trusted.
• Preserve evidence of continuous testing Keep a running record of test results, remediation actions, and the current security state so operational resilience obligations are demonstrable.

Key takeaways

• Formal verification can prove an open banking protocol is internally sound without proving that the production service is secure.
• The real risk sits in implementation drift across TLS, OAuth, consent, sessions, and partner integrations.
• Continuous testing is the control that checks whether the live API still matches the assumptions behind the proof.

Key terms

• Lifecycle Drift: Lifecycle drift is the gap between the intended state of an identity and the access that remains active in systems after the business context changes. It often appears as delayed revocation, stale privileges, or unowned credentials, and it is a practical indicator that governance is out of sync.
• 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.
• Consent Revocation: Consent revocation is the process of cancelling previously granted delegated access so it can no longer be used. For AI agents, effective revocation should invalidate refresh capability and, where possible, active tokens, because lingering access turns temporary approval into persistent risk.
• Authorization Sequencing: The order in which API calls, tokens, and session checks are executed to decide whether access is allowed. Weak sequencing can create business logic flaws that scanners miss, because the vulnerability only appears when requests are chained in the right context.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building resilient access controls. It gives security teams a common governance baseline for machine and human identity programmes.