Open banking
What is open banking?
Open banking is a framework that lets licensed third-party providers read bank account data or initiate payments directly from a customer's account through standardized APIs, with that customer's explicit consent. The account holder controls what is shared, with whom, and for how long, and can withdraw permission at any time.
Under traditional banking, account data sits inside each institution and moves only through channels the bank itself controls. Open banking replaces that with published API specifications any authorized provider can build against, so a budgeting app, a lender, or a checkout flow can reach balances or push a transfer across many banks through one integration. Coverage isn't uniform across markets: the EU mandates access under and the UK runs an equivalent regime, while other countries operate their own national frameworks or rely on commercial data-sharing agreements between banks and aggregators.
Key facts
- Also known as: bank data sharing, account-to-account access; branded as pay-by-bank when used at checkout
- Governed by: in the EU, an equivalent regime in the UK, and separate national frameworks elsewhere
- Three core API types: account information (balances and transaction history), payment initiation (moving money out of the account), confirmation of funds (checking a balance covers a specific amount)
- Requires: explicit, revocable customer consent plus at the bank
- Applies to: banks, licensed third-party providers, and the merchants and apps that build on them
How it works
- Consent request – The provider states exactly what it wants: read access to transaction history, or permission to initiate a specific payment.
- Bank authentication – The customer is handed off to their own bank, where they approve the request. The provider never sees or stores the banking credentials, which is what separates API access from screen scraping.
- Token issued – The bank returns an access token scoped to what was approved and to a defined validity period. Data consents expire and need renewing on a schedule set by the local framework; payment consents cover a single transfer or a recurring mandate comparable to a .
- API call – The provider calls the account information, payment initiation, or confirmation of funds endpoint using that token.
- Execution or return – Data requests return structured account data. Payment requests are executed by the bank as a credit transfer, such as a transfer in the euro area, so funds move account-to-account without touching card rails.
Why it matters
- A payment initiated through open banking settles as a bank transfer, so it carries no card interchange and no card-scheme process. Disputes are resolved between the merchant and the customer directly.
- Lenders and onboarding flows read the bank's own transaction data instead of asking applicants to upload statement PDFs, which removes the manual review step from underwriting and affordability checks.
- One app can display balances and transactions across several banks, because each connection is a separate consent against the same API specification rather than a separate custom integration.
Common issues
- Uneven bank coverage – API quality and uptime vary from bank to bank, which is why most providers connect through an aggregator rather than directly. A pay-by-bank option usually reaches most accounts in a market, rarely all of them.
- Consent expiry – Data access stops when the consent window closes, so recurring use cases like expense tracking or subscription underwriting break unless the customer re-authorizes.
- No card-style buyer protection – A completed bank transfer isn't reversible the way a payment is. Buyers who want chargeback rights still tend to pay by card.
- Authentication drop-off – Every request routes through the bank's own login and authentication step, which adds friction a stored card credential doesn't have.
