Recommended Free Tools
In UK open banking, a customer chooses a trusted service, approves a specific request at their bank, then the service and bank exchange permitted information through APIs. The bank remains the authentication point in this redirect flow; the customer is not expected to give the third party their bank password. Reading account information and authorizing a payment are separate permissions.
What an open banking API does
An API is a defined interface through which software makes requests and receives responses. In open banking, a third-party provider (such as a budgeting or accounting service) uses the bank’s API to request permitted account data or, in a distinct payment-initiation use case, to request a payment action.
As an Amazon Associate I earn from qualifying purchases.
The API is not a public window into a bank’s systems. Access is bounded by customer authorization, the permissions granted, and the endpoints and data fields defined by the applicable standard. The UK Read-Write API Profile specifies API interactions and data structures for participating implementations: Open Banking Read-Write API Profile v3.1.2. Check the current specification version before building an implementation.
What happens when you connect an account
- You choose a service and a task. For example, you might connect an account to a budgeting app, or select a payment service to make a payment.
- The service identifies the access it needs. The request should be limited to the relevant capability and data, rather than treated as blanket access to every account detail.
- You are sent to your bank. In the documented redirect model, the bank handles your authentication and presents the authorization journey. Screens and steps can differ by bank and implementation.
- You review and approve or decline. The bank records the relevant consent and authorizes an appropriate access path if you approve. You can decline instead of connecting.
- You return to the service. The service makes API requests under the granted authorization. The bank responds only with information or actions permitted by the interface and permissions.
Open Banking Limited’s 2019 account describes this redirect journey; it is a historical implementation description, not a guarantee that every bank’s current screens are identical: How Open Banking works.
#1 Best Overall
Account data and payments are different permissions
Account-information access
A data-access service may request information such as account details or transaction data, within the relevant API and permissions. Approval to read information does not by itself authorize the service to make a payment.
Payment initiation
A payment service uses a payment-initiation capability. The customer must authorize the payment action; consent to share account information is not a substitute for approving a payment. The FCA describes UK open banking as regulated access-sharing for payment-account data with trusted apps and services: FCA: Open banking and open finance.
How APIs, OAuth, OpenID Connect, scopes and tokens fit together
Standards define the interface
Common API specifications describe how requests and responses are structured, including endpoint behavior and data fields. Banks and providers must implement the applicable profile to interoperate, but specific features and operational behavior depend on the specification version and each bank’s implementation.
OAuth authorizes access; OpenID Connect adds identity
The UK Read-Write profile uses OAuth 2.0 and OpenID Connect-related standards. OAuth is an authorization framework: it governs what a client is permitted to access. OpenID Connect adds an identity layer. They are related but not interchangeable concepts.
Scopes describe requested permissions
A scope is a label for a requested permission. A client should request only what its task requires, and the API should check that the request carries the scope needed for that operation. UK government API guidance recommends user-context authorization code with PKCE and checking required scopes: GOV.UK: API technical and data standards (last updated 2026-09-30).
Tokens present authorized access
An access token lets an authorized client present its permitted access when calling an API. The exact token lifetime, binding, and refresh behavior should not be assumed: those details depend on the current specification and the bank’s implementation.
What “open” does—and does not—mean
- It means customer-consented access through trusted services within a regulated framework, not unrestricted public access to bank data.
- It does not mean every country uses the same APIs, legal framework, endpoints, or authorization flow. This explanation covers the UK; it does not establish a detailed comparison with other markets.
- It does not mean every service is risk-free or that a particular service stores no data. Authorization standards alone cannot guarantee a service’s overall safety.
- It does not mean every bank presents the same screens or exposes identical data fields.
UK standards and governance are still developing
Common standards are intended to support interoperability, safety, scalability, and monitoring. The FCA’s account of UK governance describes an evolving framework. Its 2025 statement says a Future Entity is expected to set common API standards subject to future legislation; that role should not be treated as a completed, unconditional authority: FCA: FS25/4, Design of the Future Entity for UK open banking. For broader context, see FCA: Open banking and the FCA.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
