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 decided that customer financial data belongs to the customer. What sounds like a technical footnote has become one of the more significant restructurings in how retail and SME finance actually works.

What Open Banking Actually Means

Open banking is a regulatory framework that requires banks to give authorised third parties access to customer account data — with the customer's consent — through standardised programming interfaces. The word that matters is "requires." Open banking in Europe and the UK is a mandate, not a market initiative. Banks are legally obliged to build and maintain these interfaces. They cannot charge for access. They cannot drag their feet on maintenance. And they must support a standardised set of data types that any licensed third party can call.

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 — known almost universally as PSD2 — began applying across EU member states from January 2018, requiring banks to provide access to payment account data and to support third-party payment initiation, with the Regulatory Technical Standards governing strong customer authentication and open banking APIs coming into full effect in September 2019. PSD2 defined the categories of authorised third parties, the consent requirements, and the security standards — but it left banks significant latitude in how they built their APIs. The result was a patchwork: some banks built excellent APIs, many built minimal-compliance implementations that barely worked, and integration complexity was high.

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 OBIE is now transitioning to a new governance structure under the Joint Regulatory Oversight Committee (JROC), a joint effort between the FCA and the Payment Systems Regulator. The intention is to embed open banking governance in the UK's permanent regulatory landscape rather than treating it as a time-limited CMA remedy — a signal that this is infrastructure now, not an experiment.

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. Consent can be revoked at any time, directly through the bank. Third parties cannot exceed the scope they were granted. And the consent is time-limited: under PSD2's Strong Customer Authentication (SCA) rules, AISP connections required re-authentication every 90 days, which turned out to be a significant source of user drop-off — useful connections breaking because customers did not realise they needed to reauthorise them. The UK removed this reauthentication requirement for AISP connections in 2022, allowing longer-lived consents where the third party implements appropriate ongoing authentication controls. The underlying consent reconfirmation obligation — periodically confirming the customer still wishes to share data — was retained; what was eliminated was the requirement to run a full strong authentication re-challenge every 90 days.

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 MoneyDashboard 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 — 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) are the newest and arguably most commercially interesting development in UK open banking. A VRP consent can allow variable payments within parameters the customer sets — for example a maximum per transaction or per month. Sweeping between accounts owned by the same customer is established under the CMA's open-banking requirements. Broader commercial VRP for third-party billers is still being developed through an industry-led framework, with the FCA and Payment Systems Regulator continuing to monitor delivery in 2026. If it achieves broad participation, commercial VRP could give subscription and regular-payment services a more controllable alternative to card-on-file. 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's Rule 1033, finalised in late 2024, is beginning to create a US regulatory framework for open banking, but implementation is contested and 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. In January 2025, the system had approximately 62 million active consents, demonstrating the scale the deployment had reached.

The United States has no mandatory open banking standard. The CFPB's Rule 1033, finalised in October 2024, requires covered institutions to make consumer financial data available in machine-readable form to the consumer or authorised third parties, with compliance timelines running to 2026–2030 by institution size. Whether it produces a UK-style standardised ecosystem depends heavily on whether the Financial Data Exchange (FDX) can deliver a common technical standard before the regulatory deadlines arrive.

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.

Sources and methodology: This article draws on the EU Payment Services Directive 2 (PSD2) legislative text; UK Payment Services Regulations 2017; Open Banking Implementation Entity (OBIE) published standards and statistics; JROC open banking roadmap publications; and publicly available product documentation from named infrastructure providers. No proprietary data is cited.