Open Banking Explained: How API-Driven Finance Is Reshaping Banking

For most of their history, banks sat on an extraordinary asset and said nothing about it. Every transaction you ever made, where you shopped, how much you earned, whether you dipped into your overdraft in December, was recorded in their systems and stayed there. If a mortgage lender wanted to verify your income, you printed three months of statements and posted them. If a budgeting app wanted to track your spending, you handed over your credentials. The data existed; accessing it was laborious, insecure, and entirely on the bank's terms.

Open banking changed that arrangement, not because banks volunteered to, but because regulators in Europe and the UK created consent-based rights for customers to let authorised providers access payment-account data and initiate payments. That gives customers meaningful control over access and use; it does not settle the separate legal question of who "owns" every item of bank-held data.

What Open Banking Actually Means

Open banking is a regulatory framework under which account-servicing payment providers give authorised third parties access to specified payment-account data or payment initiation, with the customer's consent, through secure interfaces. In the UK, the framework combines the Payment Services Regulations 2017^[1] with the more prescriptive requirements imposed on the CMA9 by the CMA's Retail Banking Market Investigation Order^[2]. The precise duties and data scope depend on the provider, account and legal instrument; open banking is not a general right for any app to obtain any financial data.

The standardisation matters because it solves a coordination problem. Before open banking, a handful of fintechs built data aggregation products by screen-scraping: logging into a customer's bank account using the customer's credentials and reading the HTML like a browser would. It worked, crudely, but was fragile, required sharing passwords, and existed in a regulatory grey area. The whole point of open banking APIs is to replace that with a structured, consent-based data channel that both banks and third parties can rely on.

The Regulatory Origins: PSD2 and the UK Standard

The EU's Payment Services Directive 2^[3] (known almost universally as PSD2) began applying across EU member states from January 2018, requiring access to payment-account information and support for authorised payment initiation, with the Regulatory Technical Standards governing strong customer authentication and secure communication applying from September 2019. PSD2 defined the regulated third-party roles and security framework but left room for different technical implementations, contributing to uneven integration experiences across banks and markets.

The UK took a more prescriptive path. Alongside implementing PSD2 through the Payment Services Regulations 2017, the Competition and Markets Authority (CMA) created the Open Banking Implementation Entity (OBIE), which mandated that the nine largest UK banks (the so-called CMA9) implement a specific technical standard: the Open Banking Standard, built on OAuth 2.0 and OpenID Connect. Instead of each bank designing its own API, they all had to implement the same one. This is a significant part of why the UK's open banking ecosystem has developed further and faster than most EU equivalents. Infrastructure providers connecting to UK banks write one integration; infrastructure providers connecting to German or Italian banks write however many the market requires.

The Joint Regulatory Oversight Committee (JROC) that previously steered this work has been wound down. The National Payments Vision named the FCA as lead regulator for the next phase, while the FCA works with industry to establish a successor Future Entity^[4] for common open-banking API standards. That does not make the FCA the sole regulator of every part of open banking: the Future Entity's proposed role and the FCA's powers to oversee it depend on the long-term statutory framework. In February 2026^[5], the FCA said it did not yet have legislative powers to oversee the Future Entity.

The EU framework itself is also being refreshed: a successor package, PSD3 and an accompanying Payment Services Regulation, reached political agreement in November 2025, with formal adoption expected in 2026 and application roughly 21 months after publication in the Official Journal.

The Two Service Types: AISP and PISP

Under PSD2 and the UK regulations, there are two distinct authorisations a third party can hold, and they do very different things.

An Account Information Service Provider (AISP) is authorised to read account data (transaction history, current balances, account identifiers, and related information) with the customer's consent. An AISP cannot move money. It has read-only access to a defined set of data fields, for a defined period, that the customer has explicitly approved. A personal finance app that shows you all your bank balances in one screen is almost certainly operating as an AISP. So is a mortgage broker that pulls 12 months of transaction data to assess your affordability rather than asking you to upload paper statements.

A Payment Initiation Service Provider (PISP) is authorised to instruct a payment from the customer's bank account. The customer never shares their card details with the PISP. Instead, the PISP sends a payment instruction to the bank's API, the customer authenticates directly with their bank, and the money moves. This is account-to-account (A2A) payment: no card network in the middle, no interchange fee, settlement in seconds rather than days. When you see a "Pay by Bank" button at checkout, that is PISP in action. The merchant receives funds directly from the customer's bank account, and the only parties involved are the customer's bank and the merchant's bank, plus whatever infrastructure layer is powering the PISP.

Some providers hold both licences. Most fintechs that do anything interesting in the open banking space hold or rely on both, because the most useful products combine data access with payment capability. For more on how A2A payments are reshaping card-network economics, see our piece on account-to-account payments.

How the Consent Model Works

Open banking flows use OAuth 2.0, the same authorisation framework that powers "Sign in with Google" buttons across the web. The mechanics are worth understanding because the consent model is what distinguishes open banking from the screen-scraping era.

When a user wants to share their bank data with a third-party app, the flow goes roughly like this: the app initiates a request specifying what data it wants (say, 90 days of transactions from a current account) and for how long. The user is redirected to their bank's own authentication interface: the bank's app or website, not the third party's. They log in with their own credentials, which the third party never sees. The bank presents a consent screen spelling out exactly what the third party will be able to access. The user approves it. The bank issues an access token to the third party, which can then call the bank's API to retrieve the data it asked for.

The user retains control throughout. The Open Banking customer-experience guidelines^[6] require dashboards through which users can view and revoke ongoing consents. Third parties must stay within the authorised scope. The UK removed the blanket requirement for customers to repeat strong customer authentication every 90 days for ongoing AISP access in 2022, while retaining periodic consent reconfirmation and the provider's security responsibilities.

The Use Cases: What Open Banking Actually Enables

The theoretical case for open banking is neat. The practical case is messier: it depends heavily on which specific use case you are looking at.

Mortgage affordability assessment is probably the most mature and commercially significant AISP use case in the UK. A growing number of UK mortgage lenders, including major high-street names and a range of specialist buy-to-let and self-employed mortgage providers, now accept open banking transaction data as an alternative to bank statements. A broker can request 12 months of income and expenditure data in roughly 30 seconds, instead of chasing a client for three months of PDFs. The data is also harder to manipulate than PDF statements, which reduces underwriting fraud risk. For self-employed borrowers whose income appears in lumpy, irregular patterns across multiple accounts, open banking data is often more informative than standard income documentation.

Credit decisioning is the second major AISP application. Fintechs including ClearScore and Creditspring, alongside incumbents like Experian, use open banking transaction data to build credit assessments for borrowers with thin or non-existent credit files: recent immigrants, young adults, gig economy workers, and others for whom the traditional credit bureau record is incomplete or misleading. The logic is straightforward: three months of rent payments, consistent income deposits, and no overdraft charges is useful evidence that three years of credit file silence cannot provide.

Personal financial management (PFM) is the consumer-facing AISP use case most people encounter first. Apps like Emma, Moneyhub, and Snoop pull together accounts from multiple banks into a single view, categorise spending automatically, and surface patterns the user would not otherwise notice. The category has struggled to monetise, and several early entrants have pivoted or closed, but the UX patterns they established have influenced how banks have designed their own aggregation products.

Payment initiation via PISP is where the commercial stakes are highest and the bank resistance is strongest. Checkout flows that use open banking (Mastercard's "Pay by Bank" product, TrueLayer's payment initiation API, GoCardless's Instant Bank Pay) allow merchants to accept payments directly from customer bank accounts at a fraction of the cost of card acceptance. For high-value, low-frequency transactions (insurance premiums, solicitor payments, property deposits), the economics are compelling. For everyday consumer retail, the user experience has historically lagged card payments, but the gap has narrowed as authentication flows have improved.

Variable recurring payments (VRP) allow a customer to authorise variable payments within parameters they set, for example a maximum per transaction or per month. Sweeping between accounts held by the same customer is established under the CMA's open-banking requirements. Commercial VRP for third-party payments is different: it is being introduced through an industry-led commercial scheme and a phase-one rollout, rather than being a universally available UK payment method. The FCA and Payment Systems Regulator's delivery update^[7] says they will support and monitor industry progress through 2026. Firms assessing it for bills, subscriptions or other regular payments should check the scheme's actual participant coverage, pricing and consumer-protection terms rather than assume market-wide availability. See our analysis of B2B embedded finance for how open banking payments fit into the broader embedded finance stack.

The Infrastructure Layer: Who Connects the Banks

Most fintechs and merchants do not connect directly to each bank's API. They use an open banking aggregator: a third-party infrastructure provider that maintains connections to dozens or hundreds of banks and exposes a single, unified API that abstracts the variation between them. These providers hold the AISP and PISP licences needed to make the calls, maintain the bank connections (including the inevitable maintenance windows and API version migrations), and handle the regulatory authorisation in each jurisdiction.

TrueLayer is the UK and European market leader for open banking infrastructure. It powers the bank connection layer for Revolut, Trading212, and a long list of lenders and payments businesses. It holds licences in the UK and EEA and provides both data (AISP) and payment (PISP) APIs.

Tink, acquired by Visa in 2022 for approximately €1.8 billion, is particularly strong in the Nordics and Germany, markets where bank API quality tends to be higher and developer adoption came early. Visa's acquisition is a signal of how seriously card networks are taking the A2A payment threat that open banking enables.

Plaid dominates US data aggregation and has expanded into European markets. Its UK and EU footprint is smaller than TrueLayer's or Tink's, partly because the US market, where Plaid built its franchise on screen-scraping and bilateral data-sharing agreements with banks, operates under different rules. The CFPB finalised an open banking rule under Section 1033 in late 2024, but it never took hold: the rule is enjoined in federal court and the CFPB is rewriting it, so US data access remains market-driven in ways the EU and UK mandates are not.

Yapily focuses on enterprise clients in the UK and EU, with a strong presence in B2B payments and treasury use cases. Token.io has positioned itself specifically around payment initiation, particularly for high-value transactions. Moneyhub occupies a distinct niche: it specialises in pension, wealth, and financial wellbeing use cases, connecting to pension providers, savings platforms, and investment accounts alongside bank accounts, a broader data set than most AISP providers cover.

The infrastructure providers are essentially the middleware layer of the open banking stack, analogous to the BaaS middleware layer described in our explainer on Banking-as-a-Service. They abstract integration complexity, but they also introduce a dependency: a fintech whose bank connections run through a single aggregator is exposed to that aggregator's reliability, pricing power, and regulatory status.

The Global Picture

Open banking is not a UK or EU phenomenon, though the two implementations are the most developed and best documented.

Australia launched the Consumer Data Right (CDR) in 2020, designed from the start to extend beyond banking into energy and telecommunications. Implementation has been slower than hoped, but the banking layer is operational and the open energy regime is live. Brazil launched Open Finance in 2021 with a scope that covers credit, insurance and investment data alongside payment accounts. Its adoption metrics should be read from the latest Banco Central do Brasil or Open Finance Brasil publication because measures such as consent, active connection and customer are not interchangeable.

The United States has no mandatory open banking framework in force. The CFPB finalised a rule under Section 1033 of the Dodd-Frank Act in October 2024 that would have required covered institutions to make consumer financial data available in machine-readable form to the consumer or authorised third parties, with compliance deadlines phased from 2026 to 2030 by institution size. It has not survived contact with litigation: the rule is enjoined by a federal court, the CFPB has told that court it considers the rule unlawful, and the agency launched a rewrite with an advance notice of proposed rulemaking in August 2025. The first compliance deadline, in April 2026, passed without binding effect. Until a rewritten rule lands, US open banking remains a matter of bilateral agreements and the Financial Data Exchange's voluntary technical standard rather than regulatory mandate.

What Banks Actually Think About This

Banks have not embraced open banking willingly, and it is worth being honest about why. The commercial logic is uncomfortable: implement infrastructure at your own cost that makes it easier for customers to compare you unfavourably with competitors, switch accounts, or route payments around your network. The banks that built PSD2 APIs with minimal effort and poor documentation were not being obstructionist for its own sake; they were rationally limiting the damage to their competitive position.

The more sophisticated response has been to find ways to benefit from the infrastructure they were forced to build. The largest UK banks have used open banking APIs to offer their own account aggregation products, showing customers their accounts at rival banks inside the bank's own app. It sounds counterintuitive, but the bank that shows you all your finances becomes harder to leave. NatWest and Lloyds have both offered multi-bank views to varying degrees.

Some banks have invested in improving their own credit underwriting using open banking data from external sources, accessing richer transaction data on borrowers who bank elsewhere. Others are exploring operating as TPP infrastructure themselves, offering aggregation APIs to third parties as a revenue line. None of this erases the structural challenge open banking creates for banks whose competitive position depends on opacity. But the banks that invested seriously in API quality and developer experience are better positioned than those that built the minimum viable compliance implementation and hoped the market would not notice.

Methodology: CloudFintech extracted four dated milestones from the official legal texts and Commission package. The final row records a proposal, not enacted legislation.

Primary sources: Directive (EU) 2015/2366 (PSD2); CMA Retail Banking Market Investigation Order 2017; European Commission financial data access and payments package

Download underlying dataset