Open Banking API Specification: Complete UK Reference

What does the open banking API specification actually define, and what does a build team get from implementing it?

The specification gives every authorised third-party provider a predictable contract with every participating bank in Open Banking UK. Without it, each bank integration would require a separate implementation pattern. With it, one integration pattern covers the market. That is the practical value of the specification before any endpoint is called.

Open Banking Limited maintains the Open Banking API specification in the UK. It is the technical implementation layer above open banking API standards ,the conceptual framework. This page goes to endpoint structure, field-level data models, and consent mechanics.

Open Banking API UK infrastructure processed 2.81 billion API calls in June 2026, a new monthly record. Every one of those calls was governed by the specification this page explains.

Key Takeaways

• The open banking API specification defines how AIS (read) and PIS (write) endpoints work, what fields they return, and how consent is structured, giving build teams one pattern across all UK banks
• PSD2 sets the regulatory obligation; the UK Open Banking API specification sets the technical implementation. Most competitor pages conflate these two; they are separate layers
• The consent model has four mandatory fields: permissions, expiry date, transaction from/to dates, and the account-access-consent resource identifier
• The psd2 open banking API specification requires SCA on every payment and data access, implemented as a bank redirect, not a provider-side authentication step

What Does the Open Banking API Specification Cover?

The open banking API specification is the technical standard published by Open Banking Limited (formerly OBIE). It defines three primary API families: the Read/Write API, the Open Data API, and the Directory API. For build teams integrating account data or payment initiation, the Read/Write API is the relevant specification.

The Read/Write API covers two permission types, read access (AIS) and write access (PIS), plus a Confirmation of Funds endpoint. Together, these form the full specification surface for an authorised third-party provider in Open Banking UK.

For worked Open Banking API examples showing what specific calls return, see Open Banking API examples.

The three API families

What Are the AIS Endpoints in the Open Banking API Specification?

The AIS side of the open banking API specification enables Account Information Service Providers to retrieve account data with customer consent. The endpoint structure follows a consent-first pattern: consent is created and authorised before any data request is made.

The way the account-access-consent resource works

The account-access-consent resource is the central object in AIS. It is created by the AISP on the ASPSP’s (bank’s) system before any account data can be retrieved. The resource carries four mandatory fields:

• Permissions: A defined list of data types the AISP is requesting access to. Permissions are scoped; an AISP must request only what its use case requires. Common permissions include ReadAccountsBasic, ReadTransactionsDetail, ReadBalances, and ReadBeneficiariesDetail.
• ExpirationDateTime: The date and time at which the consent expires. After expiry, the AISP can no longer retrieve data without a new consent.
• TransactionFromDateTime: The earliest transaction date the AISP is permitted to retrieve.
• TransactionToDateTime: The latest transaction date boundary (optional).

Once the account-access-consent resource is created, the bank returns a ConsentId. The AISP uses this to redirect the customer to the bank’s authorisation interface, where SCA is completed.

For a full explanation of the AISP role and permissions scope, see aisp.

Types of AIS endpoints return at field level

After authorisation, the AISP calls data endpoints. In generic terms (no field names are reproduced verbatim from the specification):

• Account endpoints return account identifiers, account type, currency, and name fields
• Transaction endpoints return transaction identifiers, amount, currency, booking and value dates, transaction type, and counterparty information where available
• Balance endpoints return the current balance amount, credit/debit indicator, and balance type
• Beneficiaries endpoints return saved payee details linked to the account

The psd2 open banking API specification does not mandate a single data format per field, individual banks implement the fields defined in the specification, but field population varies by bank. This is the most common source of integration issues in production.

What Are the PIS Endpoints in the Open Banking API Specification?

The PIS side of the psd2 open banking API specification enables Payment Initiation Service Providers to submit payment instructions with customer authorisation. Like AIS, it follows a consent-first pattern through the payment consent resource.

The way payment consent resource works

Before a payment is submitted, a domestic payment consent resource is created. This carries:

• InstructedAmount: The amount and currency of the payment
• CreditorAccount: The recipient’s account details (sort code and account number for UK domestic payments)
• RemittanceInformation: The payment reference visible to both parties
• LocalInstrument: The payment scheme (FasterPayments for UK domestic)

Once the payment consent resource is created, the PISP redirects the customer to their bank for SCA authorisation. After authorisation, the PISP submits the payment instruction. The bank executes it and the payment settles instantly via Faster Payments.

Types of PIS endpoints return

After payment submission, the specification defines status fields the PISP can query:

• Payment status codes (Pending, AcceptedSettlementInProgress, AcceptedCreditSettlementCompleted, Rejected, and others)
• The payment identifier assigned by the bank
• The transaction identifier once settlement is confirmed

The psd2 open banking API specification also defines a Confirmation of Funds endpoint, which allows a PISP to confirm whether a customer’s account holds sufficient funds before initiating a payment, without retrieving transaction data.

How Does PSD2 Map to the Open Banking API Specification?

This is the distinction most pages covering psd2 open banking API specification get wrong. PSD2 and the UK open banking API specification are separate layers with separate purposes.

PSD2 sets the regulatory obligation: banks must allow authorised third parties access to customer accounts with consent. It defines the obligation but not the technical implementation.

The UK open banking API specification sets the technical implementation: the exact endpoint structure, field definitions, consent model, and security requirements that fulfil the PSD2 obligation within Open Banking UK. A provider could in principle satisfy PSD2 without using the Open Banking API UK specification, but in UK practice, conformance with the specification is the implementation path.

The Data (Use and Access) Act 2025 has now created a statutory basis for smart data schemes, including Open Banking UK, which gives the FCA authority to evolve the specification framework. The regulatory relationship is changing, but the current specification remains operative.

What Security Does the Open Banking API Specification Require?

The psd2 open banking API specification imposes security requirements at the connection and authorisation layers.

Dynamic Client Registration

Dynamic Client Registration (DCR) is the mechanism by which a TPP registers itself with a bank before making API calls. The process uses a Software Statement Assertion (SSA) issued by the Open Banking Limited directory. The ASPSP validates the SSA and returns client credentials the TPP uses for subsequent calls. No manual registration is required, DCR automates.

SCA and redirect-based authorisation

Every consent authorisation flow, for both AIS and PIS ,requires the customer to authenticate with their bank using SCA. The specification implements this through a redirect: the TPP redirects the customer to the bank’s authorisation interface, the customer completes SCA, and the bank redirects back to the TPP’s callback URI with an authorisation code. The TPP exchanges the code for access and refresh tokens.

The specification defines the OAuth 2.0 and OpenID Connect profile that governs this flow. Token lifetimes, refresh mechanics, and re-authentication triggers (at 90-day consent expiry) are defined in the specification. Re-authentication requires a new consent authorisation flow ,not a simple token refresh.

How Is the Open Banking API Specification Versioned?

The UK open banking API specification is versioned by Open Banking Limited. Banks must implement mandated versions within a defined migration window.

Things platforms must monitor

Platforms building on the psd2 open banking API specification face version management in two directions:

• Provider-side: Your open banking provider (AISP or PISP) must track specification updates and maintain conformance. Ask any provider: what is your process for tracking and implementing specification version updates?
• Bank-side: Individual banks implement new versions at different points in the migration window. A platform that expects identical behaviour across all banks on day one of a version change will encounter inconsistencies.

The Open Banking Limited changelog and API performance pages are the authoritative monitoring sources. Most platforms delegate this monitoring to their provider.

How Does Finexer Handle the Open Banking API Specification?

Finexer implements the UK open banking API specification across AIS, PIS, and Verification, covering the full Read/Write API surface. For platforms building on Finexer, the specification handling happens at the infrastructure layer: Finexer manages consent creation, bank redirect flows, SCA handling, token lifecycle, re-authentication at 90-day expiry, and version conformance per bank.

What this means for a build team:

• The account-access-consent resource and payment consent resource are managed by Finexer, not built per bank
• Re-authentication is triggered and managed through Finexer’s consent lifecycle layer
• Specification version updates are absorbed at the infrastructure layer, the platform API contract remains stable
• Dynamic Client Registration with each participating bank is handled by Finexer’s existing directory registration
• Most of the UK bank coverage including challenger and business accounts
• FCA-authorised AISP and PISP (FRN 925695), verifiable on the FCA Register

See Finexer Data for the data access product and AIS implementation details.

Bottom Line

The open banking API specification gives technical architects a single integration contract across Open Banking UK. AIS consent follows a four-field model through the account-access-consent resource. PIS consent creates a payment consent resource before payment submission. SCA is implemented through bank redirect, not provider-side authentication. PSD2 sets the obligation; the psd2 open banking API specification sets the implementation.

Specification version updates land per bank across a migration window; most platforms delegate this monitoring to their provider. That delegation is where the commercial argument for an infrastructure provider begins.

Explore with AI

ChatGPT

Key takeaways Explain why it matters Create action plan Future watch

Claude

Key takeaways Explain why it matters Create action plan Future watch

Perplexity

Key takeaways Explain why it matters Create action plan Future watch

Grok

Key takeaways Explain why it matters Create action plan Future watch

About the Author

Ravi Ranjan

Ravi Ranjan is Co founder & CEO of Finexer