Open Banking API Security: What PSD2 and GCC Open Finance Frameworks Actually Require

Open banking flipped a basic assumption of financial security: instead of a bank's data staying locked inside its own systems, regulation now requires banks to expose it, account information, payment initiation, to licensed third parties through APIs. That's a genuine consumer benefit, and it's also, by design, a bigger API attack surface than most financial institutions had to secure five years ago. The regulatory landscape driving it looks different across Europe and the Gulf, but the underlying security requirements converge on the same core idea.

PSD2, the framework everything else got compared against

The EU's Payment Services Directive 2 (PSD2) took effect in January 2018, and it's still the reference point the rest of the world's open banking frameworks get measured against, it required every EU bank to provide API access to licensed Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs), establishing both the legal right to that access and, critically, the security obligations that come with it: Strong Customer Authentication (SCA) requiring at least two of three independent factors, something you know, have, or are, for electronic payments and account access. That single requirement is a meaningful step up from the password-and-static-security-question model a lot of legacy banking still ran on, and it's a large part of why open banking, done properly, can genuinely reduce fraud compared to the screen-scraping approaches it replaced.

The Gulf isn't copying PSD2, it's building its own, fast

Saudi Arabia's central bank, SAMA, launched its open banking framework in 2022–2023 as part of the Vision 2030 financial-sector modernization agenda, and moved decisively in March 2026: full commercial licensing for open banking service providers went live, ending the sandbox-only phase, with the first commercial licence granted and more expected through the rest of 2026, expanding use cases into lending and insurance, not just account aggregation.

The UAE has moved on a parallel track. Its open finance framework, run through the Al Etihad Credit Bureau since 2023, covers an intentionally broad scope spanning banking, credit data, and insurance. In June 2026, the UAE completed Project Aperta, a BIS Innovation Hub initiative connecting domestic open finance networks across the UAE, UK, Hong Kong, Brazil, and India, with the underlying architecture released as open source, a genuinely significant interoperability step, since it means an API security failure in one connected market's implementation has a more direct path to affecting the others than open banking's early, more siloed years.

Financial-grade API security built on OAuth 2.0 and OpenID Connect, the same security model behind UK Open Banking, has been adopted across UAE AlTareq and other regional implementations specifically because ad hoc API authentication wasn't holding up at the scale open banking operates at.

What breaks in practice

Every real API security review we run against open banking-adjacent infrastructure tends to surface the same handful of categories: broken object-level authorization (an authenticated third-party app able to pull another customer's account data because an ID parameter wasn't properly scoped), excessive data exposure (an endpoint returning far more than the specific fields a given integration actually needs), and missing or misconfigured rate limiting on payment-initiation endpoints specifically, see our pieces on common API security mistakes and API rate limiting and resource consumption for what those actually look like in a real finding. OAuth and OIDC solve the authentication problem; they don't automatically solve authorization scoping, which is consistently where the real, exploitable gaps live.

What this means for scoping a test

An open banking API surface deserves testing scoped specifically around its regulatory model, PSD2's SCA requirements in the EU, SAMA's licensing framework in Saudi, the UAE's AlTareq standard, not a generic web API test applied without that context. This is exactly the kind of scoped work our Web & API Security service covers, alongside our broader Middle East and financial-sector engagements for institutions operating under SAMA, NCA, or UAE Central Bank oversight.