Open Banking was sold to the public as a revolution: give your bank’s data to a third-party app, get better budgeting tools, cheaper loans, smarter investing. And to be fair, it delivered on a lot of that. But here’s what the press releases quietly skipped over. When you mandate a standardised API layer across every regulated bank in the country, you also hand attackers a standardised, publicly documented attack surface with consistent endpoint naming conventions, shared OAuth 2.0 flows, and predictable error responses. That is the Open Banking API security UK PSD2 attack problem that almost nobody in the mainstream conversation is actually willing to name.
I’ve spent a fair amount of time reading through the Open Banking Implementation Entity (OBIE) specifications, watching traffic in Burp, and reading the FCA’s published API security expectations. What follows is a technical walkthrough of where the real risk sits, and why automated probing of these endpoints is both easier and more rewarding for attackers than most fintech marketing teams would like to admit.
What the PSD2 API layer actually looks like
The Second Payment Services Directive, as implemented in the UK through the Payment Services Regulations 2017, required all banks above a certain size to open up transactional data and payment initiation to authorised Third Party Providers (TPPs). The OBIE produced the Open Banking Standard, which defines REST endpoints, JSON payloads, and the OAuth 2.0 with PKCE and mTLS flows that govern access.
The endpoints are public knowledge. The specification is online. The error codes, the token endpoint paths, the consent object schema, all of it is documented and largely consistent across every major UK bank. Barclays, HSBC, Lloyds, NatWest: they all expose /open-banking/v3.1/aisp/accounts or a very close variant. Attackers do not need to fingerprint anything. The reconnaissance is done for them.
The authorisation flow uses Dynamic Client Registration (DCR) in many implementations, meaning a TPP can register a new OAuth client programmatically by presenting a signed Software Statement Assertion (SSA) from the Financial Conduct Authority’s directory. That directory is the trust anchor. If you can get a legitimate SSA, or compromise one, you have a path into every bank’s DCR endpoint simultaneously.
Credential stuffing at the consent screen layer
The most common automated attack I see discussed in threat intel circles is not against the API endpoints themselves, it is against the redirect flow that delivers the user to their bank’s own consent screen. Here is the thing: the Open Banking standard does not govern what that consent screen looks like or how banks rate-limit authentication attempts on it. It is effectively a standard login page with a fancy OAuth context bolted on.
Credential stuffing tools like Sentry MBA or generic Python scripts using aiohttp can hammer these consent endpoints with leaked username/password combos from breach databases. The Open Banking redirect just gives attackers a cleaner, more predictable URL structure to target. Banks are supposed to implement strong customer authentication (SCA) under the Payment Services Regulations 2017, which mandates multi-factor authentication, but the quality of that implementation varies enormously. Some banks are genuinely solid. Others are still leaning on a six-digit SMS code, and as I covered in detail on this blog, SIM swap fraud is actively defeating that exact control at UK banks right now.
Consent token abuse: the attack the spec quietly enables
Once a user authorises a TPP, the bank issues an access token bound to a specific consent object. That consent object defines what the TPP can read: account balances, transaction history, beneficiaries. The access token is typically short-lived, but a refresh token can persist for 90 days under OBIE rules.
Here is where it gets interesting from an attacker’s perspective. If a TPP’s infrastructure is compromised, every stored refresh token is effectively a persistent read-access credential into every connected user’s bank account. The attacker does not need to touch the bank’s systems at all. They hit the TPP, extract the refresh token store, and then quietly poll account data through the legitimate API. The bank sees clean, authorised requests. There is no anomaly to detect unless you are doing behavioural analysis on access patterns at the TPP level.
There is a documented real-world parallel in the way wallet-draining smart contracts are disguised as legitimate FCA-registered platforms to harvest authorisation from users. The underlying mechanic is the same: abuse the trust infrastructure to get a legitimately issued credential, then exploit it quietly.
The OBIE spec does allow banks to implement token binding and require mTLS between the TPP and the bank’s resource server, which ties the token to a specific client certificate. But not every bank enforces mTLS at the resource server for every call, and certificate management at smaller TPPs is often treated as a box-ticking exercise rather than an operational security control.
What the FCA’s API security expectations actually say
The FCA published its expectations for firms under SYSC (Senior Managers Arrangement, Systems and Controls) and through its participation in the European Banking Authority’s guidelines on ICT risk. The short version: firms must implement appropriate technical and organisational measures, conduct regular vulnerability assessments, and have incident response plans. The FCA’s Open Banking guidance page is worth reading if you have not already, though it reads with the kind of careful vagueness that regulators favour.
What the FCA does not do is specify how banks should implement rate limiting on API endpoints, what WAF rules should be in place, or how refresh token stores should be encrypted at rest. That is left to firms. In practice, this means a spectrum from genuinely hardened implementations at large banks with dedicated security engineering teams, to TPPs running their token stores in a poorly configured RDS instance on AWS with overpermissive security groups.
Automated scanning tools, and I am talking about everything from Nuclei templates targeting Open Banking endpoints to custom Python scrapers checking DCR endpoint exposure, are actively looking for misconfigured implementations. The attack surface is consistent enough that you can build a generic scanner and hit every UK bank’s Open Banking base URL systematically. That is not a hypothetical; threat actors are doing exactly this.
Where the real risk lands for users
For most people, the most plausible harm from Open Banking API attacks is not a direct bank breach. It is a compromised TPP leaking their financial data to someone who then uses it for targeted fraud. Transaction history reveals salary, regular bills, subscriptions, and financial stress signals. That data is enormously valuable for social engineering. An attacker who knows you have a standing order to a specific solicitor, for example, has the raw material for the kind of technically engineered conveyancing fraud that has cost UK homeowners millions.
Payment initiation APIs carry a harder risk. A TPP with payment initiation permissions that gets compromised can have those permissions abused to initiate payments directly. The confirmation of payee system helps, but it is not foolproof, and social engineering around it is well understood by fraud groups.
What a hardened Open Banking implementation actually needs
From a technical standpoint, the minimum viable security posture for a TPP or bank in this space should include mutual TLS enforced end-to-end, not just at registration; refresh token rotation on every use with single-use semantics; anomaly detection on access patterns per consent object; short-lived access tokens (15 minutes maximum); webhook endpoint validation using signed JWTs; and DCR endpoints that are not exposed to the public internet without IP allowlisting.
Most of these are in the OBIE spec as options. The word “option” is the problem. Making mTLS optional in a financial API that handles account data is the kind of decision that looks fine until a mid-tier TPP gets popped and 200,000 people’s transaction histories end up in a Telegram channel.
My read of the current state: the large banks have mostly got this right at the infrastructure level. The weak points are in the ecosystem of smaller TPPs, the budget fintech startups chasing FCA authorisation, and the consent screen UX flows that users click through without reading. The spec created a level playing field for developers. It also created a level playing field for attackers. That was always going to be the trade-off, and I am not convinced the industry has been honest enough about it.
Frequently Asked Questions
What is Open Banking and why does PSD2 create an API attack surface?
Open Banking requires regulated UK banks to expose standardised REST APIs so authorised third parties can access account data and initiate payments on a customer’s behalf. Because the API specification is public and consistent across all major banks, attackers can build generic tools to probe every participating bank without needing to fingerprint individual implementations.
How does credential stuffing target Open Banking consent flows?
When a user initiates an Open Banking connection, they are redirected to their bank’s consent and login screen. Attackers use automated tools loaded with leaked username and password combinations to hammer these screens. The Open Banking redirect provides a predictable URL structure, and the quality of rate limiting on these screens varies significantly between banks.
What is consent token abuse in Open Banking and how does it work?
After a user authorises a third-party app, the bank issues access and refresh tokens tied to a consent object. If the third-party provider’s servers are compromised, attackers can steal those refresh tokens and silently query account data through legitimate API calls for up to 90 days. Banks see authorised requests and have no inherent reason to flag them as suspicious.
What does the FCA require from firms regarding Open Banking API security?
The FCA requires firms to implement appropriate technical and organisational security measures, conduct regular vulnerability assessments, and maintain incident response plans under SYSC rules. However, the FCA does not prescribe specific controls like WAF rules or token encryption standards, which means the quality of implementation varies widely across the ecosystem.