Notifications
Clear all
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.
NHIMG editorial — based on content published by Equixly: Open banking security, formal verification, and continuous penetration testing
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Test for business logic and authorization chaining Prioritise scenarios where correct individual calls become unsafe when executed in sequence.
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.
👉 Read Equixly's analysis of open banking protocol proofs and continuous API testing →
Open banking security gaps: are your API controls keeping up?
Explore further
18/08/2026 3:22 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Open banking proof is not enough without continuous API testing
