Open banking
Also known as: open finance, PSD2 access to account, XS2A, Section 1033
Open banking is a framework that lets you tell your bank to share your account data with a third-party app, or let that app start a payment, through a secure, permissioned connection.
While it is often sold as a fintech revolution, its real achievement is more modest and more important: it replaces the risky habit of giving apps your banking password with a controlled, revocable consent.
Open banking, explained at three levels
At home
Think of open banking like giving a house-sitter a key that only opens the front door and stops working on Sunday, instead of handing over your whole keyring. You tell your bank, 'let this budgeting app see my transactions,' and the bank gives the app limited, temporary access. You never share your password, and you can cancel the access any time.
At work
For a business, open banking means customers can connect their bank accounts to your service safely. A lender can see income history to approve a loan faster, or an accounting tool can pull transactions automatically. The bank controls the connection, so neither you nor your customer has to store banking passwords.
At home
Before open banking, many apps used 'screen scraping': you typed your online banking password into the app, and it logged in as you to copy your data. That works, but it breaks your bank's terms and makes fraud claims messy. Open banking swaps that for an API connection. You approve the specific data and the time period on your bank's own screen, and the app gets a token rather than your credentials.
At work
Open banking regimes usually define two roles: account information service providers, which read data, and payment initiation service providers, which can move money on the customer's instruction. Third parties are typically accredited or licensed, must meet security standards, and carry liability rules. For product teams, the practical choice is between building direct bank connections or using an aggregator such as Plaid or Flinks that normalizes dozens of bank APIs.
At home
Under the hood, most open banking APIs use OAuth 2.0 with tighter security profiles such as the OpenID Foundation's Financial-grade API (FAPI), mutual TLS between participants, and short-lived access tokens bound to a specific consent. In my opinion, the consent screen is where these systems succeed or fail. A technically perfect API still leaks data if people click 'allow all, forever' because the screen made the narrow option hard to find.
At work
The hard problems are governance, not plumbing: who accredits third parties, who pays when a breach or a mistaken payment happens, and whether banks may charge for data access. The US fight over Section 1033 turned on exactly those questions, including whether banks can charge fees. North America is converging on the Financial Data Exchange (FDX) API standard, while the UK mandates its own Open Banking Standard and EU banks mostly follow the Berlin Group's specifications. Building on open banking means tracking liability frameworks as closely as API versions.
Real-world examples
At home
Sophie wanted a budgeting app to track her spending, but she refused to type her banking password into it. Her bank supported open banking, so the app sent her to the bank's own login page, where she approved read-only access to her chequing account for 90 days. When she stopped using the app, she revoked the connection in her bank's settings in two taps.
At work
Thomas runs underwriting at a small online lender. Instead of asking applicants to upload PDF bank statements, the lender asks them to connect their accounts through open banking. Thomas's team now sees verified income and spending patterns in minutes, catches doctored statements that used to slip through, and cut approval times from three days to the same afternoon.
How it compares
| feature | Open banking | Screen scraping |
|---|---|---|
| How the app gets your data | Bank-issued token through an approved API | Logs in with your actual username and password |
| Scope of access | Limited to the data and period you approved | Everything you could see when logged in |
| Revoking access | Cancel the consent at your bank | Change your password |
| Bank's position | Sanctioned and supported | Often against the bank's terms of use |
| Reliability | Stable, versioned interfaces | Breaks when the bank redesigns its website |
Both approaches let an app see your bank data, but only open banking does it without handing over your password.
For analysts
Treat open banking as a regulatory product, not an integration ticket. I've seen teams scope it like a weekend API project and then stall for months on accreditation, consent design, and liability terms. Map the rules of each jurisdiction you serve before writing a line of code, because in this space the law sets the timeline.
History & origin
The modern concept took shape in Europe. The EU's revised Payment Services Directive (PSD2), adopted in 2015, required banks to open account access to licensed third parties, and it applied from January 13, 2018. The UK went further: after its Competition and Markets Authority found in 2016 that the big banks faced too little competition, a 2017 order forced the nine largest to build common open APIs, and UK Open Banking went live the same day PSD2 applied. Australia followed with its Consumer Data Right in 2020 and Brazil launched Open Finance in 2021. In the United States, the CFPB finalized its Section 1033 open banking rule in October 2024, but by 2025 the agency had reversed course, a court had blocked enforcement, and the rule was being rewritten. Canada's version, branded consumer-driven banking, is still being phased in. Having watched these rollouts, I'd argue the lesson is clear: open banking moves at the speed of regulation, not technology.