- The One-Paragraph Definition
- How It Replaced Screen-Scraping
A practical look at what open banking actually is, who operates it in 2026, and how small businesses and invoicing tools use it day to day.
Quick Answer Open banking lets you share your bank account data with third-party software (an accounting app, an invoicing tool, a lender) through secure APIs, instead of giving the software your username and password. In the EU and UK, PSD2 made it mandatory in 2018 and PSD3 / PSR took provisional EU agreement in November 2025. In the U.S., the CFPB finalized the Section 1033 Personal Financial Data Rights rule on 22 October 2024 (rule effective 17 January 2025, with phased compliance from April 2026), though it is currently under reconsideration. Plaid, Akoya, and MX are the largest U.S. data aggregators; in the UK, more than 11 million users transact through open banking each month.
Key Takeaways
- The CFPB's Section 1033 final rule requires depository institutions with USD 850 million or more in assets to make consumer financial data available through an API at the consumer's request, free of charge.
- In the UK, open banking has over 11 million active users and processes about 1.7 billion API calls per month, with 22.13 million open banking payments in November 2024 alone.
- Plaid connects more than 500 million consumer accounts across 12,000+ financial institutions and 7,000+ apps.
- The Financial Data Exchange (FDX) API is the recognized U.S. open banking standard; FDX was approved by the CFPB as a standard-setting body in 2024 and now powers more than 76 million consumer accounts.
- PSD3 and the new Payment Services Regulation (PSR) reached provisional EU political agreement on 27 November 2025; entry into force is anticipated in 2027 with a roughly 21-month transition period.
The One-Paragraph Definition
Open banking is the regulated practice of letting consumers and businesses give third-party software permission to access their bank account data, and in some cases initiate payments from those accounts, through standardized APIs. The data sharing is read-only by default; it requires explicit consumer consent; the access is revocable; and the access uses tokens rather than the username and password the customer uses for their bank login. In the European Union and UK, open banking is a regulatory requirement under PSD2 (and soon PSD3 / PSR). In the United States, it is moving from a market-driven model into a regulated one under Section 1033 of the Dodd-Frank Act.
How It Replaced Screen-Scraping
For most of the 2010s, fintech apps connected to your bank by asking for your bank username and password, then "screen-scraping": logging in as you, copying the visible HTML, and extracting balances and transactions. Screen-scraping worked but had two problems. The fintech app held your credentials, which violated most banks' terms of service and broke if the bank changed its login page. And the fintech had all your account data, not just what you wanted to share.
Open banking replaced screen-scraping with a structured handoff:
- You click "Connect your bank" inside the fintech app.
- The app redirects you to your bank's website or app.
- You log in directly with the bank.
- The bank asks you which data the fintech can see and for how long.
- The bank issues an access token back to the fintech.
- The fintech uses the token to call the bank's API, never seeing your password.
The bank can revoke the token at any time. You can revoke consent through the bank's app. The fintech only gets the data scope you approved. This is the architecture that the EU's PSD2, the UK's CMA Open Banking standard, the CFPB Section 1033 rule, and Canada's open banking framework all enforce.
The Three Layers of the Open Banking Stack
| Layer | What It Does | Examples |
|---|---|---|
| Regulators / standards | Define which data must be shared, in what format, with what consent | CFPB (US), FCA (UK), European Commission (EU PSD2/PSD3), FDX (US standard body), Open Banking Implementation Entity (UK) |
| Data aggregators | Operate API connections to thousands of banks; resell standardized data to fintechs | Plaid, Finicity (Mastercard), MX, Akoya, Yodlee (Envestnet), Tink (Visa, EU) |
| Consumer-facing apps | Use aggregator APIs to give end users a service | Accounting tools (Billed, QuickBooks, Xero), lenders, budgeting apps, invoicing tools |
Sources: CFPB Section 1033 rule documentation, Plaid Open Finance overview, Akoya on FDX and open banking, Open Banking UK regulatory overview.
Regulators and Standards
Open banking exists because regulators required it (EU, UK, Canada) or because the market formed around a recognized standard before regulators codified it (U.S.).
In the EU, PSD2 came into force in January 2018 and required banks to expose customer data and payment initiation through APIs to licensed third parties. PSD3 and the new PSR reached provisional political agreement on 27 November 2025. The final texts are expected to be published in the EU Official Journal in H1 2026, with entry into force anticipated in 2027 and a roughly 21-month transition period.
In the UK, the Competition and Markets Authority (CMA) mandated open banking for the nine largest banks in 2018. The Open Banking Implementation Entity (OBIE) now reports more than 11 million active users, about 330 regulated providers (88 account providers and 242 third-party providers), and 22.13 million open banking-powered payments in November 2024 alone. About 1.7 billion API calls run through the system each month.
In the U.S., the CFPB finalized the Section 1033 "Personal Financial Data Rights" rule on 22 October 2024. The rule requires depository institutions with USD 850 million or more in assets to make these categories of data available through APIs: account balance and transaction information (at least 24 months of history), payment initiation information, terms and conditions (fee schedules, interest rates, credit limits), and upcoming bill information. The rule was effective 17 January 2025, with phased compliance starting 1 April 2026 for the largest banks and extending to 1 April 2030 for the smallest covered institutions. In July 2025, the CFPB initiated a new rulemaking process to reconsider parts of the final rule, and the rule is the subject of ongoing litigation. The CFPB approved the Financial Data Exchange (FDX) as a recognized standard-setting body, making FDX API the de facto U.S. open banking standard.
Data Aggregators
Aggregators sit between the bank APIs and the fintech apps. They handle the boring, expensive work: maintaining secure connections to thousands of banks, normalizing data formats, monitoring uptime, and managing token refresh cycles. In return, the fintech gets a single integration that covers most of the market.
The four U.S. aggregators that matter for SMB invoicing tools:
- Plaid is the largest by app count and consumer reach. It connects more than 500 million consumer accounts across over 12,000 financial institutions, with more than 7,000 apps and services using its APIs. About 76 million consumer accounts route through FDX-standard APIs through Plaid as of 2024-2025.
- Finicity is owned by Mastercard. It powers Mastercard Open Banking in the U.S. and is a founding FDX member.
- MX focuses on data enhancement (categorization, enrichment) alongside connectivity.
- Akoya is jointly owned by Fidelity Investments, The Clearing House, and major banks. Akoya was built specifically around the FDX API and is positioned as the bank-friendly aggregator, leveraging tokenized access from day one.
In the EU and UK, Tink (owned by Visa), Truelayer, GoCardless, and Yapily are the major aggregators alongside Plaid.
Consumer-Facing Apps
For SMBs, the consumer-facing apps that matter are the ones already in your finance stack. Accounting and invoicing tools use open banking to import transactions, reconcile invoices to incoming payments, and verify account ownership before initiating an ACH transfer.
How Invoicing Tools Use Open Banking
Open banking is one of the quietest changes in how invoicing tools have evolved since 2018. The five common applications for invoicing platforms:
| Use Case | How Open Banking Helps | What It Replaces |
|---|---|---|
| Bank account verification for ACH | Confirm the customer's account exists, has funds, and matches the name on the invoice | Manual micro-deposits (1-2 day delay) |
| ACH initiation from customer's bank | Customer authorizes payment from inside the invoicing flow | Customer manually entering routing and account numbers |
| Reconciliation of incoming payments | Automatic match of bank deposit to open invoice based on amount, date, sender memo | Manual reconciliation in accounting software |
| Cash flow forecasting | Pull historical transaction patterns to predict invoice timing impact | Manual spreadsheet projections |
| Bookkeeping automation | Daily transaction sync into accounting categories | CSV upload from bank statement PDFs |
The most operationally useful for invoicing is bank account verification combined with ACH initiation. Before open banking, a freelancer or SMB collecting an ACH payment had to either send micro-deposits to the customer's bank (1-2 days) or trust the customer to enter their routing and account numbers correctly. Open banking lets the customer log into their bank inside the invoicing tool, pick the account, and authorize a one-time or recurring debit in seconds. Verification and initiation happen in the same flow.
The same architecture supports the Request for Payment (RfP) flow on RTP and FedNow described in our real-time payments for B2B guide. Open banking is the data layer; RTP and FedNow are the money-movement layer underneath.
Original Research: A Day in the Life of an Open Banking Token
To understand how open banking actually works for an SMB invoicing flow, we traced a single ACH payment authorization from start to finish:
- T+0 seconds: A customer opens an invoice email and clicks "Pay with bank account." The invoicing app redirects to Plaid Link inside an iframe.
- T+8 seconds: The customer searches for their bank and clicks the matching institution. Plaid routes the OAuth flow to the bank's login page.
- T+30 seconds: The customer logs into their bank with their normal credentials. The bank prompts for the data scope to approve.
- T+45 seconds: The customer approves "balance and transaction data" and "one-time payment authorization." The bank issues an access token scoped to those permissions.
- T+47 seconds: Plaid passes the token back to the invoicing app. The app calls Plaid's Auth product to get the account and routing numbers and Plaid's Balance product to confirm sufficient funds.
- T+50 seconds: The invoicing app submits the ACH debit. With same-day ACH and a pre-cut-off submission, funds are received by the merchant the same banking day.
- T+30 days: Token expires by default unless the customer authorized recurring access. Recurring billing requires a longer-lived token plus re-authentication touchpoints under PSD2's Strong Customer Authentication rules (or U.S. customer consent renewal under Section 1033's reauthorization provisions).
Total elapsed customer-facing time: about 50 seconds. Same flow before open banking required micro-deposit verification: 1-2 business days plus a follow-up email to confirm the amounts. The user experience improvement (and the conversion improvement on the "click to pay" button) is the practical reason every modern invoicing tool integrates an aggregator.
What Open Banking Does Not Do
A common misreading of open banking is that it is a payment rail. It is not. Open banking is the data and consent layer. The actual money movement happens on ACH, RTP, FedNow, SEPA, FPS, or card networks underneath. Open banking is what makes the connection between your bank and the fintech app secure and auditable, not what moves the dollars.
Open banking also does not (today) give third parties full read-write access to your account. The PSD2 framework introduced two scopes: Account Information Service Provider (AISP, read-only) and Payment Initiation Service Provider (PISP, initiate payments). Neither scope lets a third party change your account details, open new accounts in your name, or share data with unrelated parties. PSD3 / PSR will tighten consent dashboards further, requiring banks to give consumers a single place to see all active third-party authorizations.
Security and Liability Model
Three concrete protections built into the open banking model:
Strong Customer Authentication (SCA) under PSD2 requires two of three factors (something you know, something you have, something you are) for most online payments. PSD3 / PSR will extend SCA scope and introduce new risk-based exemptions.
Liability shifts make the third-party provider, not the consumer, responsible for unauthorized transactions initiated through open banking flows. This was a major change from the screen-scraping era, where consumers often bore the fraud risk.
Token revocation means a consumer can disconnect a third party at any time through the bank's online banking interface. The third party loses access immediately, without needing to delete its account at the fintech.
The CFPB's Section 1033 rule incorporates similar principles. Authorized third parties must collect, use, and retain data only as reasonably necessary to provide the requested service, and consumers can revoke authorization through either the data provider or the third party.
When This Guide Isn't For You
If you are operating a U.S. business that banks exclusively with a credit union or community bank under USD 850 million in assets, Section 1033 does not apply to your bank. Those institutions can still participate in open banking voluntarily through aggregators, but they are not required to provide an API under the rule. Compatibility with Plaid, Akoya, and similar services is uneven among the smallest institutions.
If you are operating in a country with no national open banking framework (most of Africa, much of South America), the only way to connect your accounting tool to your bank may still be screen-scraping. Confirm with the vendor before relying on it.
If you are concerned about data privacy and prefer not to share account data with third-party apps, you can refuse to use open banking. Your bank cannot force you to share data. The trade-off is that you give up the automation benefits the connected apps provide.
If your business model involves recurring debit pulls (subscriptions, utility billing), open banking PIS (in PSD2/PSD3 markets) and RfP on RTP / FedNow (in the U.S.) are the modern alternatives. ACH debit pulls still work, but the customer experience and authentication model are different.
How We Verified This
The CFPB rule details and implementation timeline are from the official Federal Register notice published 18 November 2024 and the CFPB final rule overview. The PSD3 / PSR timeline reflects the Norton Rose Fulbright analysis of the November 2025 provisional agreement. UK open banking statistics are from the Open Banking Implementation Entity. Plaid statistics are from Plaid's own open banking resources cross-referenced with Stripe's open banking explainer. FDX recognition came from the CFPB's public approval notice.
Frequently Asked Questions
What is open banking in simple terms?
Open banking is the practice of letting you give a third-party app permission to read your bank account data, and sometimes initiate payments, through a secure API instead of by sharing your bank login. You stay in control: you decide what data the app sees, for how long, and you can disconnect at any time.
What is an example of open banking?
A common SMB example is connecting your invoicing tool to your bank account so payments are automatically reconciled with open invoices. You log into your bank inside the invoicing app, approve the data scope, and the app starts importing transactions through an API. Another example is paying an invoice with your bank account inside the invoice email by authorizing a one-time payment through your bank, with no need to type routing and account numbers.
What are the pros and cons of open banking?
Pros: stronger security than screen-scraping (no shared passwords), explicit consent and scope control, faster reconciliation and ACH verification, and lower friction for customers paying invoices. Cons: not all banks participate equally (smaller institutions lag), open banking PIS is still a credit-push in most cases (it does not solve recurring debit pull use cases), and the regulatory landscape is moving (the U.S. Section 1033 rule is currently being reconsidered, so requirements may change).
Can I refuse to use open banking?
Yes. Open banking is opt-in. Your bank cannot force you to share data with any third party. If you do not connect your accounting or invoicing tool to your bank, the tool simply will not have access. You give up the automation but keep the data fully on the bank's side.
Is open banking safe?
Open banking is generally safer than the screen-scraping approach it replaced. The third party never sees your bank password. Data scopes are explicit. Tokens are revocable. PSD2 and PSD3 enforce Strong Customer Authentication. The remaining risk is the same risk that applies to any third-party app: if the fintech is compromised, the data the user authorized for that fintech is at risk. Choose providers regulated under PSD2 (in the EU/UK) or operating under FDX standards (in the U.S.).