Open banking and continuous penetration testing

In the first formal security analysis of its kind, Modesti et al. (2025) set out to test whether the UK Open Banking Account and Transaction API protocol is secure.

Using two independent verification tools, the researchers confirmed that the protocol’s security goals held even with an unlimited number of parallel sessions. That meant the guarantee held not just for a single isolated session, but under the messy, everything-at-once load of a real-world banking system.

At the same time, they also listed the many ways threat actors can breach a bank once it deploys the protocol.

This contradiction sits at the heart of open banking security. A protocol can be sound, and a system built from it can still be exposed. How can both be true?

Who leads the world in open banking adoption? The system behind 24 billion API calls

Today, the UK is at the forefront of open banking adoption:

• 145 regulated providers had live open banking propositions, with another 406 firms acting as their agents as of March 2025 (Open Banking Limited [OBL], 2025).
• The UK ecosystem carried 16.5 million user connections — up from 12.1 million a year earlier — and handled 24 billion successful API calls over the year by December 2025 (OBL, 2026). Each of these calls transmits invaluable financial data, such as balances, transactions, and account information.

The UK’s open banking mandate came from the Competition and Markets Authority (CMA). In 2016, the CMA required the country’s largest banks to open their account data to third parties via standardized APIs, provided the customer consents.

The UK Open Banking Account and Transaction API protocol stands on well-known cryptographic building blocks:

• OAuth 2.0 for tokens and grants
• OpenID Connect for user authentication
• TLS for transport security

Underpinning all of these is the Open Banking Directory. It is the core infrastructure that enables banks and third-party providers (TPPs) to validate each other’s identity and access customers’ financial data in a secure, permissioned way.

Banks deploying the open banking protocol must also satisfy Strong Customer Authentication. It is the regulatory requirement that governs how users prove their identity before access is granted.

Engineers have studied each of these pillars for years, along with the open banking protocol built on top of them. But all that study covers protocol design. It tells us very little, if anything, about how banks implement and run the daily.

Why formal verification of the protocol alone cannot keep open banking safe

This is where the contradiction disappears.

Modesti et al. (2025) did not prove that every bank running the UK Open Banking Account and Transaction protocol is secure. They demonstrated something narrower: An abstract, formal version of the protocol satisfies security goals, provided the real-world system follows the same rules and assumptions used in that formal version.

In the researchers’ case, that abstract version was a formal AnBx model. It is a structured representation of the protocol’s parties, messages, tokens, credentials, account data, and security goals. And it is useful for proving whether the protocol logic is sound. However, it is not a test of whether a bank has securely configured, coded, integrated, and monitored its live API.

A real-world open banking API is not just a protocol diagram. A bank still must

• Configure TLS
• Validate certificates
• Implement OAuth 2.0
• Manage redirects
• Store tokens
• Expire sessions
• Enforce consent
• Protect customer credentials
• Control employee access
• Monitor providers
• Connect the API to existing banking systems

Each of these steps creates room for mistakes that sit outside the formal proof. And that is precisely the limitation the researchers themselves point out:

The proof assumes that TLS works as intended. It does not prove that a bank has removed weak cipher suites, checked certificates correctly, or blocked man-in-the-middle attacks.

It assumes OAuth 2.0 behaves correctly. It does not prove that tokens cannot leak through logs, browser history, mobile apps, analytics tools, misconfigured proxies, or unsafe redirect flows.

It assumes sessions and consent are enforced. It does not prove that sessions end after logout, that access stops immediately after consent is withdrawn, or that CSRF protections prevent a logged-in customer from being pushed into approving a rogue provider.

It assumes trust boundaries hold. It does not prove that a compromised TPP stays within scope, or that an insider at the bank cannot interfere with how tokens are issued.

It assumes credentials remain protected. It does not prevent phishing, brute-force attacks, reused passwords, or secrets stored in places where attackers can find them.

These observations mean that the protocol and its deployment are different realities. The security of the deployment is settled only by testing your open banking system in the specific form in which you built it and run it in practice. And because that system changes with every release and integration, the testing cannot be done once: It has to be ongoing.

• Formal verification asks: Is the protocol secure if all assumptions hold?
• Continuous penetration testing asks: Do those assumptions still hold in the system you run live?

This is why open banking needs both. The protocol proof gives you confidence in the design. Continuous pentesting validates whether the live API, its integrations, and its operating environment still deserve that confidence.

What is continuous penetration testing for open banking?

Continuous penetration testing addresses both problems by design. Instead of scheduling a security test against a system that has already moved, continuous pentesting checks the system as it moves, with the release cycle.

For open banking, that means you test every material change to the authentication and consent flows before it begins affecting customers. Continuous pentesting enables you to scrutinize new endpoints — including shadow APIs that accumulate outside formal governance — as they emerge and assess business logic as developers write it. Not months later, when a scheduled test finally catches up.

The Financial Conduct Authority’s (FCA) operational resilience framework requires this exact discipline in UK finance. Under PS21/3, banks have to continuously test their key business services to demonstrate they can stay within defined impact tolerances.

For banks running open banking systems, APIs are the core infrastructure through which those services run, and API security is therefore a direct part of that obligation. Continuous pentests produce the documented evidence the framework calls for:

• Test results
• Confirmed remediation
• Running record of the live system’s security state

How Equixly delivers continuous penetration testing for open banking

You already know the deployment risk is hard to close in financial services. A major reason is that it does not stay within your own walls.

Your financial institution’s APIs connect outward to third-party providers (TPPs), each carrying its own credentials, consent flows, and access permissions. A misconfigured TPP integration does not stay contained; it can expose financial information from multiple connected systems at once, not just at the point of contact.

Equixly’s AI agents reason through the open banking API attack surface with an adversarial mindset:

• Chaining calls across services
• Probing trust boundaries between the bank and its partners
• Adapting their approach based on how the live system responds

They detect vulnerabilities that only appear when APIs are tested together rather than one endpoint at a time. An authorization bypass that requires a specific sequence of calls is one example. A data exposure path that emerges from how authentication and session logic interact is another.

A standard vulnerability scanner won’t find those. An adversary that reasons through the workflow will.

And Equixly does this persistently — no test window or fixed scope — so a change to your open banking APIs is assessed for risk as it happens.

A formal proof tells you the design is sound. Equixly tells you the bank still is.

Keep open banking safe between releases, not just on test day.
Book a demo.

FAQs

Does a formally verified open banking protocol still need penetration testing?

Yes — because a formal proof holds only when the live build matches the model’s assumptions, and a penetration test is what checks whether it does.

Which open banking weakness most often slips past scanners?

Broken Object Level Authorization and similar business logic flaws, since they show up only when an attacker reasons through the order and context of API calls.

Can you pentest a live open banking API without disrupting service?

Yes, but only if the testing is built for production. In that case, the agent exercises the authentication, consent, and authorization logic without moving funds or exposing live financial information. This testing is adversarial in reasoning and controlled in execution.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.

Gavin Sutton

Head of Marketing

Gavin is marketing leader with more than a decade of experience in the cybersecurity industry helping startups and scale ups grow internationally. He has a passion for working with disruptive technology companies who can reshape the security landscape with their innovative solutions.