As open banking unlocks unprecedented financial innovation, it simultaneously expands the attack surface. Here is how the industry is managing the tension between openness and security.
In September 2016, the UK’s Competition and Markets Authority issued a landmark ruling: the nine largest banks in Britain would be required to open their data to third-party providers through standardised APIs. It was, at the time, a regulatory nudge toward greater competition in financial services.
Eight years later, that nudge has become a global movement. Open banking frameworks now exist across the EU (PSD2), India (Account Aggregator), Australia (Consumer Data Right), Brazil, Singapore, and dozens of other jurisdictions. The total number of open banking API calls worldwide is projected to exceed 580 billion annually by 2027.
But as the financial system becomes more open, it also becomes more exposed. Every API endpoint is a potential entry point. Every data-sharing agreement is a new privacy vector. Every third-party integration is a link in a chain that is only as strong as its weakest node.
The question is no longer whether open banking carries cybersecurity risk. It clearly does. The question is how regulators, financial institutions, and technology providers are structuring the guardrails — and whether those guardrails are keeping pace with the threats they are meant to contain.
What Open Banking Actually Opens Up
To understand the security implications, it helps to be precise about what open banking infrastructure actually does.
At its core, open banking is a framework that allows consumers and businesses to share their financial data — transaction history, account balances, payment credentials — with third-party applications through standardised, regulated APIs. With the customer’s consent, a fintech app can read your bank account data, initiate payments on your behalf, or aggregate your financial picture across multiple institutions.
This connectivity creates genuine value. It enables account aggregation tools that give individuals a unified view of their finances. It allows lenders to make credit decisions based on real transaction data rather than static credit scores. It powers the payment rails behind buy-now-pay-later products, expense management platforms, and business banking dashboards.
But openness, by definition, increases the number of parties that touch sensitive financial data. And more parties means more points of potential failure.
The Cybersecurity Threat Landscape in Open Banking
API Vulnerabilities
APIs are the connective tissue of open banking. They are also one of the most actively targeted attack vectors in modern cybersecurity. The OWASP API Security Top 10 — the industry’s reference list of critical API risks — identifies broken object-level authorisation, excessive data exposure, and security misconfigurations as among the most prevalent vulnerabilities.
In practice, this means: an API that returns more data than the calling application actually needs exposes that data to potential exfiltration. An API that does not enforce strict object-level authorisation can be manipulated by an authenticated user to access another user’s data. An API endpoint that lacks rate limiting is vulnerable to credential stuffing attacks — automated scripts that cycle through stolen username-password combinations at machine speed.
These are not theoretical vulnerabilities. In 2019, Capital One suffered a breach exposing the personal data of over 100 million customers. The root cause was a misconfigured API in their cloud environment that allowed an attacker to access data they should never have been able to reach. The breach cost Capital One an estimated $80 million in regulatory fines alone.
Third-Party Risk and the Supply Chain Problem
Open banking frameworks are, by design, ecosystems of interconnected entities. A single consumer banking experience might involve the bank itself, an account aggregation provider, a payment initiation service, an identity verification layer, and a data analytics platform — each connected to the others via APIs.
This creates a supply chain security problem that mirrors what the broader technology industry has grappled with since the SolarWinds attack in 2020. If any participant in the chain is compromised, the blast radius extends to every connected party. A breach at a third-party API provider does not stay at that provider.
Token Hijacking and OAuth Exploits
Open banking systems typically use OAuth 2.0 for authorisation — a protocol that issues access tokens to third parties instead of sharing raw credentials. When implemented correctly, OAuth is robust. When implemented carelessly, it creates significant exposure.
Token hijacking — where an attacker intercepts or steals a valid access token — gives them the ability to interact with a victim’s financial data or initiate transactions with the same permissions as the legitimate application. Redirect URI manipulation, token leakage through browser history, and improper token storage on mobile devices are all documented attack vectors.
Social Engineering and Consent Manipulation
Perhaps the most underappreciated risk in open banking is not technical at all. The consent model that underpins these frameworks — the idea that users consciously authorise data sharing — creates opportunity for social engineering. Fraudulent applications can mimic legitimate ones, obtaining consent through deception and then accessing financial data under the cover of legitimately granted permissions.
Data Privacy: The Regulatory Dimension
Cybersecurity and data privacy are related but distinct concerns, and open banking sits at the intersection of both.
Under GDPR in Europe, financial data qualifies as sensitive personal data, subject to heightened protection requirements. PSD2’s Regulatory Technical Standards mandate strong customer authentication, encrypted communication, and strict data minimisation — third parties may only access the specific data the customer has consented to share, and no more.
India’s Account Aggregator framework takes a similar approach, creating a consent-based data flow architecture where the aggregator acts as a data blind — routing encrypted data packets between financial information providers and users without being able to read the content itself. It is a structurally elegant privacy model, though its security depends entirely on the cryptographic integrity of each participating entity.
The common thread across jurisdictions is an attempt to encode privacy into the architecture, not just the policy. But regulatory frameworks are only as effective as their enforcement — and the velocity of product development in open banking consistently outpaces the velocity of regulatory oversight.
How Regulated BaaS Providers Handle Compliance
The most practically significant development in managing open banking security risk has been the emergence of regulated Banking-as-a-Service providers — companies that build and maintain API banking infrastructure within a strict compliance framework, allowing third-party businesses to access financial capabilities without having to independently navigate the regulatory environment.
This model matters for security because it centralises compliance burden at the infrastructure layer. A business integrating with a regulated BaaS provider inherits a baseline of security controls — API authentication, encryption standards, data handling policies, audit logging — that would otherwise require significant independent investment to build and maintain.
In practice, reputable BaaS providers operating in India and comparable markets are required to:
Maintain PCI-DSS compliance for any infrastructure touching payment card data, including independent audits and penetration testing requirements.
Implement ISO 27001-certified information security management systems — a globally recognised standard that governs how information assets are protected, who can access them, and how security incidents are detected and responded to.
Adhere to RBI guidelines on data localisation, which require that all payment data pertaining to Indian customers be stored exclusively within Indian borders — a sovereignty measure with direct security implications, since it limits the jurisdictional complexity of a breach response.
Apply strong customer authentication at payment initiation, requiring multi-factor verification before a transaction can be completed — a control that directly addresses credential-based fraud.
Maintain detailed audit trails of all API interactions, enabling forensic investigation in the event of a breach and demonstrating to regulators that access controls are functioning as intended.
The value of this model is not that it eliminates risk — no architecture does. It is that it distributes security responsibility to the entity best equipped to manage it, rather than fragmenting it across every developer who builds on top of the infrastructure.
The Emerging Standards and Frameworks
The open banking security landscape is not static. Several important developments are reshaping how the industry approaches risk.
FAPI (Financial-Grade API) is an OAuth 2.0 profile developed by the OpenID Foundation specifically for financial services. It imposes stricter requirements on token binding, redirect handling, and request object signing that address many of the vulnerabilities present in generic OAuth implementations. FAPI compliance is increasingly being mandated by open banking regulators globally.
Zero Trust architecture — the security philosophy that no entity inside or outside a network perimeter should be trusted by default — is gaining significant traction in financial API design. Rather than relying on network-level trust (the assumption that traffic from inside the corporate firewall is safe), Zero Trust requires continuous authentication and authorisation at the application level for every request.
AI-driven API threat detection is closing the gap between attack sophistication and defensive capability. Machine learning models trained on API traffic patterns can identify anomalous behaviour — unusual query volumes, unexpected data access patterns, atypical geographic origins — in real time, flagging potential threats before they escalate into breaches.
The Honest Assessment
Open banking carries real security risk. It expands the attack surface, introduces supply chain dependencies, and creates complex data governance challenges that genuinely are difficult to manage at scale.
But the alternative — closed, proprietary, non-interoperable banking systems — carries its own costs: entrenched incumbents, limited competition, and financial products that serve the already-served rather than the underserved.
The security question in open banking is not whether to accept risk. Risk is inherent. It is whether the industry is building the structures — technical, regulatory, and operational — that manage risk proportionately to the value being created.
The evidence, on balance, is that it is. Regulation is maturing. Standards like FAPI are raising the floor. BaaS providers are absorbing compliance complexity at the infrastructure layer. AI-driven detection is improving response times.
The financial system is becoming more open. The effort to ensure that openness does not become vulnerability is serious, ongoing, and — for the first time in the history of financial services technology — genuinely keeping pace.
As open banking frameworks mature and API call volumes scale into the hundreds of billions, cybersecurity has moved from a technical consideration to a board-level strategic priority for every institution operating in the financial technology space.
