Two platforms connect to the same high street bank through open banking api standards. One integration is smooth for two years. The other fails silently every few weeks, with tokens expiring unpredictably and error messages that never quite match the documentation.
Both providers are compliant. Both technically meet the same open banking api standards. So why do they behave so differently against the identical bank in open banking UK?
This guide answers that question directly, working from the actual UK Open Banking Standard specification rather than marketing language, so technical and compliance readers can see exactly what open banking and APIs are required to do and what is left to each provider to decide.
For the broader participant landscape this standard sits inside, see our guide to the open banking ecosystem; for how this standard underpins commercial collection, see b2b payment methods built on top of it.
Key Takeaways
- Open banking api standards mandate which endpoints must exist and which fields are required, but leave token lifetime, error message wording, and consent dashboard design to each provider.
- The UK Open Banking Standard uses Static Enumerations, which are fixed by the spec, and Namespaced Enumerations, which banks can extend themselves, explaining much of the behavioural variance seen in production.
- PSD2 is the underlying regulatory basis; the UK-specific Read/Write API Specification builds on top of it with additional mandatory detail.
- As of June 2026, revised OBL guidance confirms banks can implement their own rate-limiting thresholds, meaning identical requests can throttle differently depending on which bank sits behind the connection.
What Do Open Banking API Standards Actually Mandate?
Open banking API standards in the UK originate from the CMA Order of 2017 and are formalised through what is now the Read/Write API Specification, maintained under the successor to the Open Banking Implementation Entity. The specification defines five distinct categories:
- Read/Write API Specifications
- Open Data API Specifications
- Directory Specifications
- Dynamic Client Registration Specifications
- MI Reporting Specifications.
Within the Read/Write specification, banks, referred to as ASPSPs (Account Servicing Payment Service Providers), must implement any endpoint marked Mandatory, and must process any field marked Mandatory when a provider submits it. Every ASPSP operating in open banking UK is bound by the same mandatory endpoint list, regardless of size.
The consent model is standardised too: A provider defines an intent, the customer authenticates directly with their bank using Strong Customer Authentication, and the bank returns an access token scoped to that specific intent. This part of open banking and APIs working together is genuinely uniform across every UK bank.
The Read and Write Split Is Defined at The Specification Level
Account information access (read) and payment initiation (write) are governed as separate permission sets under open banking api standards. A provider authorised for one does not automatically gain the other; each requires its own scope, its own consent, and its own token.
What do UK Open Banking API Standards Cover?
This is where most confusion sits, and where open banking API documentation from individual providers becomes essential reading rather than boilerplate. Comparing open banking API providers on this table, not on marketing claims, is the fastest way to predict integration stability.
| Element | Standardised By Spec | Provider-Specific |
|---|---|---|
| Endpoint existence | Yes, if marked Mandatory | No |
| Required field presence | Yes, if marked Mandatory | No |
| Token lifetime | No | Yes, varies by bank |
| Error message wording | Partially (error code only) | Yes, message text varies |
| Consent dashboard | Not required by regulation | Yes, OBL encourages but does not mandate |
| Supplementary data fields | No | Yes, ASPSPs define their own structure |
| Rate-limiting thresholds | No | Yes, set individually by each bank |
Namespaced Enumerations Allow Banks To Extend The Standard Themselves
The specification uses two types of enumerated values. Static Enumerations are fixed by the standard and remain the same across banks. Namespaced Enumerations start with OBIE-defined values but allow banks to add their own. This is why the same API can behave slightly differently across banks.
Token behaviour follows the same pattern. The specification explicitly avoids fixing token lifetime, and providers are told to expect that token length and duration may change over time. A robust integration handles this dynamically; a fragile one hardcodes assumptions that break the moment a bank changes its token behaviour.
Why do Open Banking API Providers Behave Differently Under The Same Open Banking API Standards?
If the underlying bank connection is identical, the variance comes from three places: implementation quality, retry logic, and connection maintenance discipline.
A provider with weak retry logic and poor error handling treats a temporary bank-side timeout as a hard failure, surfacing an error to the end user that a better-built provider would have quietly resolved on the second attempt. Connection maintenance matters just as much: as each ASPSP updates its own implementation, providers that monitor and adapt continue working, while providers that built once and stopped watching start failing silently.
None of this is a standards violation; it is the difference between an implementation built to the letter of open banking api standards and one built with production reliability and proper error handling in mind.
Which Regulations Govern Open Banking API Standards in Open Banking UK?
The UK’s PSD2 regulation is the underlying legal requirement behind open banking api standards, mandating that banks provide regulated third parties with secure account access under customer consent. The CMA Order added UK-specific detail on top, requiring the nine largest UK banks to implement the standard to a stricter timeline than PSD2 alone required.
This UK context matters because open banking and APIs built only to baseline PSD2 requirements, without the additional CMA-driven detail, will fall short of what open banking UK banks actually expect from a connecting provider.
How Should You Read a Provider’s Open Banking API Documentation Against Open Banking API Standards?
A short checklist separates open banking API documentation that reflects genuine open banking API UK compliance from documentation that merely references it. This is especially useful when comparing open banking API providers who all claim standard compliance on their homepage.
- Check whether Mandatory fields are confirmed present in every response, not just described as available in principle.
- Look for explicit token refresh handling, since the standard leaves lifetime undefined and a serious provider will document their own approach.
- Read the error handling section closely; documentation that lists only generic HTTP codes without bank-specific detail has not been tested against real ASPSP behaviour.
- Confirm whether coverage claims are bank-by-bank or aggregate, since “99% of UK accounts” can still mean gaps at specific banks that matter to your user base.
For a walkthrough of what actual request and response payloads look like once you have selected a provider, see open banking API examples.
How Does Finexer Build To The UK Open Banking Standard?
Finexer does not author or govern the UK Open Banking Standard; no provider does. What Finexer does is build to it consistently across open banking and apis, with attention to the parts the specification leaves open.
- FCA-authorised for AIS, PIS and Verification, with consent handling that follows the standardised intent model described earlier.
- Consistent response handling across banks, so provider-specific variance in field naming or supplementary data is normalised before it reaches your integration.
- Token refresh and consent expiry are handled server-side, addressing the exact area the specification leaves undefined.
- Finexer Data covers UK banks under one authenticated connection, reducing the implementation-quality gap discussed throughout this guide.
For a broader look at how providers differ in practice, comparing open banking providers sets out the wider evaluation criteria beyond the standard itself.
Bottom Line
Open banking API standards create a shared foundation, not identical behaviour. Mandatory endpoints, required fields, and the consent model are uniform across every UK bank. Token lifetime, error message detail, supplementary data, and rate limiting are not, and this is precisely where implementation quality separates providers.
When evaluating open banking and APIs for a serious integration, read the documentation for what it says about the undefined areas, not just the mandated ones. That is where reliability is actually built or lost.
Is Open Banking API UK Compliance The Same As PSD2 Compliance?
No. PSD2 is the baseline legal requirement. Open banking API UK compliance under the CMA Order adds further mandatory detail on top, specific to the nine largest UK banks and beyond.
Why Do Token Lifetimes Differ Between Banks If There Is A Standard?
The specification does not fix token lifetime. Providers must build to handle variable and changing token duration by design.
Does Following Open Banking API Standards Guarantee Identical Behaviour Across Banks?
No. Mandatory endpoints and fields are consistent across open banking and apis generally, but Namespaced Enumerations, supplementary data, and rate limits are bank-specific by design.
How Can I Tell If Open Banking API Documentation Reflects Real Testing?
Look for bank-specific error details and explicit token refresh logic. Generic documentation without these usually has not been stress-tested against live ASPSPs.
See how Finexer simplifies UK Open Banking API integration with a single, production-ready connection.
Explore with AI
About the Author
Clare Pearson
Clare Pearson is a senior payments professional with extensive experience across the global financial services and payments industry. She specialises in Open Banking, payment infrastructure, and financial technology transformation, with expertise spanning product delivery, operational strategy, regulatory compliance, and large-scale payments programmes. Clare currently serves as a Non-Executive Director at Finexer and a panel member for the Payment Systems Regulator (PSR), advising on the development of payment systems policy and innovation