Topic starter
18/08/2026 2:37 pm
TL;DR: Formal verification can prove an open banking protocol is sound while still leaving the live deployment exposed to TLS, OAuth, consent, and integration failures, according to Equixly. The practical lesson is that API security for regulated finance depends on continuous testing of implementation drift, not confidence in the abstract design alone.
Editorial analysis by NHI Mgmt Group, based on content published by Equixly: “Open banking and continuous penetration testing”.
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.
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.
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.
Q: What do security teams get wrong about open banking penetration testing?
A: They often test too late and too narrowly.
Practitioner guidance
- 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.
Bottom line: Formal verification can prove an open banking protocol is internally sound without proving that the production service is secure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:22 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Open banking proof is not enough without continuous API testing