For most of banking’s history, the data in your account and the ability to move money out of it lived behind the bank’s own walls. Open banking is the deliberate opening of those walls under strict conditions: it lets you grant a regulated third party secure, consented access to your account data, or the ability to initiate a payment, through defined software interfaces. This explainer walks through how open banking works — the mechanism, the roles, and the regulation that makes it enforceable.
How does open banking actually work?
At its core, open banking works by turning bank access into a permissioned service delivered over application programming interfaces (APIs). Instead of a third party logging in as you, the bank publishes secure endpoints that authorised providers can call — but only after you have authenticated directly with your bank and explicitly consented to the specific access requested. The consent is scoped (what can be seen or done), time-bound, and revocable. Your banking password is never handed to the third party.
Two services sit at the centre of the model. Account Information Services (AIS) let a provider read account data — balances, transactions, account details — to power things like budgeting apps, account aggregation across banks, or faster lending decisions. Payment Initiation Services (PIS) let a provider start a payment straight from your bank account, offering an account-to-account alternative to card networks. A provider may be authorised for one or both.
Who are the participants?
Open banking involves a small cast of clearly defined roles, and the regulation names them precisely.
| Participant | Role in the flow |
|---|---|
| Account holder | The customer who owns the account and grants or revokes consent |
| ASPSP (account-servicing provider) | The bank or provider that holds the account and exposes the secure interfaces |
| AISP | Account Information Service Provider — authorised to read consented account data |
| PISP | Payment Initiation Service Provider — authorised to initiate payments from the account |
| Regulator | Authorises and supervises third parties and enforces the rules |
A useful mental model: the account-servicing bank is the custodian of the account and the rails; the AISP and PISP are the regulated third parties (collectively, third-party providers or TPPs) that act on the customer’s instruction; and the customer sits in control of consent throughout. The account-to-account payment capability that PIS provides is one of the reasons open banking is so closely tied to the payments layer described in our explainer on what embedded finance is.
What regulation underpins it?
Open banking is not a voluntary standard alone — in its major markets it rests on law. In the European Union, the foundation is the revised Payment Services Directive, commonly called PSD2 (Directive (EU) 2015/2366), published in the EUR-Lex Official Journal. PSD2 obliges account-servicing banks to allow regulated third parties to access accounts with customer consent, and it introduced strong customer authentication (SCA) — typically two independent factors — to reduce fraud. It gave AIS and PIS their legal definitions and put third-party providers under a supervisory regime.
The United Kingdom implemented a particularly standardised version. A competition authority remedy required the largest banks to adopt a common Open Banking Standard, with shared API specifications and a central implementation body, so that third parties could integrate once rather than build a different connection for every bank. Details of that standard and its governance are published by the Open Banking Implementation Entity, and authorisation of providers sits with the financial regulator. Other jurisdictions have taken varied routes — some regulatory, some market-led — which is why the maturity and mechanics of open banking differ noticeably from country to country.
Consent and security in practice
The security design is central to the model. Three features do most of the work: providers must be authorised and regulated before they can connect; access requires explicit, scoped consent that the customer can revoke; and authentication happens directly with the bank using strong customer authentication, so the third party never holds the customer’s credentials. This is a deliberate replacement for the older practice of screen scraping, where an aggregator stored a customer’s login and impersonated them on the bank website — an approach with weaker security and no clear consent trail.
Why open banking was created
Open banking did not emerge from banks volunteering to share their data; it was, in its main markets, a deliberate policy intervention with two goals. The first was competition. Regulators observed that incumbent banks held a near-monopoly on customer account data, which made it hard for new entrants and third parties to build competing services. Forcing banks to share data — with the customer’s consent — was intended to lower that barrier and let smaller providers compete on service rather than on who already held the account. The second goal was security and control: replacing the insecure practice of screen scraping with a governed, consented, auditable channel, and putting the customer clearly in charge of who sees their data and for how long.
Those two motives — competition and customer control — explain most of the design choices in the model. Standardised APIs exist so that a third party can build once and reach many banks, lowering the cost of competing. Explicit, revocable consent and strong authentication exist so that opening access does not mean weakening security. Reading open banking as a competition-and-control policy, rather than a purely technical upgrade, is the key to understanding why it looks the way it does.
Why open banking looks different by country
One of the most practical things to understand about open banking is that it is not a single global system but a patchwork of national and regional regimes at different stages of maturity. The route each market took shapes how it works in practice.
- Regulation-led markets — such as the European Union under PSD2 and the United Kingdom under its competition remedy — mandated access and, in the UK’s case, a common technical standard. These tend to have broader, more consistent coverage because participation is compulsory for the banks in scope.
- Market-led markets rely on commercial agreements and industry initiatives rather than a legal mandate. Coverage can be patchier and standards more fragmented, because there is no single rule forcing every bank to participate on the same terms.
- Hybrid approaches mix regulatory pressure with industry standard-setting, landing somewhere between the two.
The consequence is that the same phrase — “open banking” — can describe quite different levels of access and standardisation depending on where you are. For anyone assessing the sector across borders, the regime type is one of the most important variables, because it drives both coverage and the degree of standardisation a third party can rely on.
What open banking enables
Once secure, consented access exists, a range of services becomes possible. Account aggregation lets a customer see multiple banks in one view. Lenders can use consented transaction data to assess affordability more accurately than a static snapshot allows. Personal-finance tools can categorise spending automatically. And payment initiation offers merchants an account-to-account payment method that bypasses card networks, with different cost and settlement characteristics. Small businesses can connect their accounts to accounting and cash-flow tools, and lenders can verify income and outgoings directly rather than relying on statements a customer has to gather and submit. These capabilities also feed directly into the compliance and identity checks discussed in our explainer on what RegTech is.
The frontier is open finance: extending the same consented, API-based sharing beyond payment accounts to savings, investments, pensions and insurance. The principle is identical — customer-controlled, permissioned access to financial data — applied to a broader set of products. How far and how fast open finance develops depends heavily on whether regulators mandate it or leave it to the market.
Open banking’s progress has not been frictionless, and it is worth being honest about the headwinds. Adoption depends on consumers understanding and trusting a model that asks them to grant access to their financial data, which takes time and clear communication. It depends on the quality and reliability of the banks’ interfaces — a poorly performing API undermines every service built on top of it. And it depends on workable commercial arrangements between banks and the third parties that use their rails, since mandated access does not by itself settle who bears the cost of building and maintaining it. These are the practical reasons open banking has advanced faster in some markets than others, even where the legal foundation is broadly similar.
How analysts study the open-banking market
Open banking is best analysed structurally rather than as a single revenue pool, because the value it creates is spread across banks, third parties and the end services built on top. A sound approach segments by service type (AIS versus PIS), by use case (aggregation, lending, payments), and by regulatory regime (mandated versus market-led), then examines adoption, participant economics and regulatory direction in each. That segment-first discipline mirrors the method set out in our guide to market-research methodology. For readers new to the sector, the safest way to gauge open banking is not to chase a headline market figure but to understand the mechanism, the consent model and the regulation — the durable structure beneath the market. Further coverage sits in the banking and financial services hub.
