A cybersecurity system is only as secure as its weakest link. Consumers and developers likely had no reason to doubt the security of a fintech API used by most of the largest banks in the world, official financial institutions, and the majority of the most widely used financial software and services on the market. Unfortunately, this credibility extends to partners and third-party providers using the Open Banking APIs, who don’t always follow the most rigorous cybersecurity best practices. This overconfidence can result in disastrous cybersecurity incidents like the Okta data breach of October 2023 that exposed the sensitive data of 18,400 Okta customers.

The Okta cybersecurity incident involved the Open Banking API tangentially, as it was brought about by improperly exposing authenticated assets like user tokens, but it does reveal a potential vulnerability. This vulnerability has the potential to cause major issues, considering that over 15 million customers use tools and software involving the Open Banking API in the UK alone. Open Banking adoption and usage are only spreading, growing at a compound annual growth rate of approximately 23.3% each year. With open banking on the rise, it’s essential we close any potential security issues before they become gaping holes in our cybersecurity systems.

In September 2016, the Open Banking Implementation Entity (OBIE) released the Open Banking Account and Transaction API in an effort to standardize financial transactions while still empowering competition and transparency by enabling third-party providers. It was a bold move with its heart in the right place, but it has its limitations. Many researchers and cybersecurity analysts feel that the Open Banking Account and Transaction API have some vulnerabilities, even if they’re not immediately apparent.

Originally published in March 2020 by researchers Abdulaziz Almehrej, Leo Freitas, Paolo Modesti, and Qudus Shotomiwa as a preprint for the ArXiv archive, “Security Analysis of the Open Banking Account and Transaction API Protocol” reports numerous API-level vulnerabilities. Some of the suspected risks include issues with authentication, authorization, and secrecy. Since then, numerous additional researchers and cybersecurity analysts have built upon the report to analyze the risks in greater detail while also offering some potential solutions.

Since “Security Analysis of the Open Banking Account and Transaction API Protocol” is finally seeing official publication in the December 2025 edition of the Cyber Security and Applications journal, it seemed a good time to reconsider the Open Banking Account and Transaction API Protocol in light of the research that’s emerged in the last five years.

What Is the Open Banking Account and Transaction API Protocol?

Before we delve more extensively into the research, let’s pause for a moment and define our terminology. What is the Open Banking Account and Transaction API protocol exactly?

The Open Banking Account and Transaction API Protocol is intended to be the cornerstone of all modern financial interoperability. Designed using regulatory frameworks like the UK’s Open Banking Standard and the European Union’s PSD2 (Payment Services Directive 2) Standard, this protocol allows third-party providers (TPPs) to access consumer banking data from financial institutions like Santander or Barclays Bank in the UK or HSBC Holdings in Europe and make financial transactions on a user’s behalf.

To achieve this, the protocol dictates how account servicing payment service providers (ASPSPs) like banks expose RESTful APIs that allow TPPs to retrieve account details, balances, and transaction histories, or initiate payments once a user has granted explicit consent. Security is enforced using a layered authentication process that includes Strong Customer Authentication (SCA), OAuth 2.0 authorization flows, and mutual TLS (mTLS) for transport security. Both access and refresh tokens are used to help make sure that data access is scoped, time-limited, and tied to a specific consent session.

Security Analysis of the Open Banking Account and Transaction API Protocol: First Analysis

In theory, the APIs are robust and secure. Practice is another matter, however, as “Security Analysis of the Open Banking Account and Transaction API Protocol” reports numerous issues with the protocol’s design. Luckily, that paper ultimately concludes that most of these risks can be mitigated by strictly following the latest best practices around API cybersecurity. Most notably, the researchers strongly advise following the latest best practices about session identifiers and avoiding token reuse.

Subsequent research reveals further limitations of the Security Analysis of the Open Banking Account and Transaction API Protocol. The 2024 whitepaper “API Security in the Open Banking Ecosystem by Akamai finds that not only does the Transaction API protocol contain these vulnerabilities, it’s also susceptible to some of the run-of-the-mill cybersecurity vulnerabilities that can plague APIs. Issues like broken object-level authorization (BOLA), token leakage, and rate-limit bypasses can also be caused by improper implementation of the Transaction API protocol, weak identity propagation, or poor error handling.

Now that we have a firmer understanding of the Security Analysis of the Open Banking Account and Transaction API Protocol, let’s look at some of the knowledge and wisdom that has arisen in the last five years to help you secure your open banking APIs.

How To Secure the Open Banking Account and Transaction API

Consent Binding, Token Binding, and Session Integrity

Virtually all research into the Security Analysis of the Open Banking Account and Transaction API Protocol concludes that consent binding needs to be enforced if you want your Open Banking API to be secure. This means that consent and tokens remain thoroughly bound together throughout the session. Minor irregularities like misconfigured redirect URIs or insufficient token scoping can result in consent misbinding or token substitution.

To neutralize this threat, the OWASP Transaction Authorization Cheat Sheet recommends implementing fine-grained token scopes, nonce validation, and one-time transaction tokens to prevent replay attacks or unauthorized reuse. A thesis from Linköping University, Security Evaluation of Open Banking Authentication Flows, supports this viewpoint, noting how intermediary tools like an API gateway can end up accidentally exposing API credentials. Together, they illustrate how consent, tokens, and session integrity work together to create one of the fundamental cornerstones of Open Banking API cybersecurity.

Watch Out For Broken Object-Level Authorization and Resource Access Control

Both the Akamai 2024 whitepaper and OWASP API Security Top 10 cite broken object-level authorization (BOLA) as the most common attack vector for APIs, as attackers can inundate known endpoints by modifying authorized resources. This is one instance where the Open Banking API can make a network less secure, as it demands a standardized layout. To mitigate this risk, analysts and researchers emphasize the need for defense-in-depth authorization logic, binding resource IDs to user-specific tokens, and verifying every access at the server level.

Avoid Assumptions About Implementation

Early reports declaring the security and stability of open banking APIs assumed that each API would take advantage of a clean, end-to-end communication channel between ASPSP and TPP secured via mutual TLS. The 2025 Linköping University research shows that many API consumers use a complicated array of API gateways, load balancers, proxies, and API management layers. Improperly configured gateways and outdated certificates can create issues that go undetected by high-level security measures. Instead, cybersecurity experts insist that API gateways need to be a part of the security routine. Regular certificate rotation, endpoint verification, and logging of gateway behavior are now considered essential.

Monitoring and Operational Metrics as Security Signals

The Open Banking UK operational dashboards are surprisingly useful for bolstering API security. While not specifically intended for security, Open Banking’s operational dashboards monitor a wide array of metrics across hundreds of institutions. This makes the dashboards ideal for detecting and guarding against anomalous behavior like suspicious business calls or unexpected traffic spikes. To help protect against anomalous traffic, use the operational dashboards to create a baseline of things running smoothly and then use that baseline to trigger an alarm should something unexpected happen.

Regulatory Alignment and Governance

The 2024 paper Harmonizing Open Banking in the European Union emphasizes that security in Open Banking isn’t just a technical matter but also a governance challenge. PSD2 and the UK’s Open Banking framework demand strong authentication, consent management, and incident reporting, but they also establish certification processes that ensure TPPs and ASPSPs adhere to standardized controls.

Shifting the focus to governance reveals some vulnerabilities that might otherwise remain invisible. Most notably, different institutions might define technical terms like “data access control” in different ways. The paper argues for security-by-design principles embedded in regulation, where protocol updates, audits, and certification cycles continually evolve alongside threat intelligence.

Final Thoughts on the Open Banking Account and Transaction API

In the last five years, Open Banking API cybersecurity has gone from theoretical to practical. While at times frustrating, this is actually a good thing, as it unearths obscure edge cases and unanticipated shades of grey. Knowing where these breaks in the cybersecurity armor might occur. Pairing these insights with the latest cutting-edge best practices around access control and identity management will lay most of these worries to rest, freeing your mind to focus on what really matters — creating the best-possible financial tools and software and serving your customers.