Open banking companies build the APIs that let a bank customer's data and payment rails be used by a third-party app, with the customer's consent — payment initiation that lets a checkout pull money straight from a bank account, account aggregation that shows balances from multiple banks in one place, and the consent management and data-enrichment layers that make both possible. It exists because PSD2 forced European banks to open this access in the first place, turning what used to be closed, bank-only infrastructure into a shared utility.
That foundation is now being rebuilt. PSD3 and a directly-applicable Payment Services Regulation reached provisional political agreement in November 2025 and are expected to take effect in Europe from late 2027 into 2028, replacing PSD2 with more prescriptive requirements for API performance and uptime — open banking's original weak point, where banks technically complied but offered unreliable connections.
Payment initiation and account aggregation solve different problems
Account aggregation is read access: pulling balance and transaction data from multiple bank accounts into one view, which is what most personal finance and accounting-integration tools rely on. Payment initiation is write access: triggering a payment directly from a customer's bank account, skipping card networks entirely — which is why it's popular for account-to-account checkout, since it avoids interchange fees a card payment would incur. Most open banking companies specialise in one or the other, even though both technically fall under the same regulatory umbrella.
Why API reliability became the industry's biggest complaint
PSD2 required banks to provide open banking access, but didn't specify much about how good that access had to be — and bank API uptime and consistency varied enormously as a result, undermining the products built on top of it. Data enrichment tools exist partly to paper over this: taking messy, inconsistently formatted transaction data from dozens of different bank APIs and turning it into something a downstream app can actually use reliably.
PSD3 tries to fix the reliability problem directly
The incoming PSD3 and Payment Services Regulation package is more prescriptive than PSD2 about API performance, and requires national regulators to act "without delay" against banks whose open banking interfaces don't meet expected standards. It's a direct response to years of open banking companies complaining that the legal right to access data meant little when the actual connection was unreliable.
FiDA is open banking's sequel, not its replacement
A separate, still-in-progress piece of EU legislation — the Financial Data Access (FiDA) Regulation — would extend the same open-access logic beyond payment accounts to investments, pensions, insurance, and mortgages. It's still in trilogue negotiations and, even under an optimistic timeline, isn't expected to be operational before the end of the decade, but it signals where open banking as a concept is heading next: from bank accounts specifically to financial data generally.
Subcategories
- Payment initiation:
- Payment initiation services use open banking APIs to trigger a bank-to-bank payment directly from a customer's account, without a card network as intermediary.
- Account aggregation:
- Account aggregation uses open banking APIs to provide a consolidated view of financial data from multiple banks and financial institutions in a single interface.
- Consent management:
- Consent management platforms help regulated financial services businesses capture, record, and manage customer consents for data processing, marketing communications, and third-party data sharing.
- Data APIs:
- Data APIs provide programmatic access to financial data — transaction history, account balances, market data, reference data, and financial intelligence — that developers and businesses need to build financial products and analytics.
- Data enrichment:
- Data enrichment platforms enhance raw financial data — transaction records, company information, or customer data — with additional context that makes it more useful for analysis, underwriting, or product decisions.
How to choose
How to choose
Comparing open banking API providers specifically? See best open banking APIs in Europe — named providers compared on coverage, reliability, and pricing. Use this page to understand the category; use that one to choose a provider.
Check bank coverage in the specific countries you operate in, not just "European coverage" as a headline. Open banking API quality still varies significantly by bank and by country — a provider with excellent Dutch and German bank coverage may be weak in markets you actually need.
For payment initiation specifically, ask about the fallback if a bank connection fails. Account-to-account payments avoid card fees, but a checkout that has no card fallback when a bank API has an outage will lose sales at exactly the wrong moment.
Data enrichment quality is genuinely hard to evaluate from a demo — ask for real transaction data testing. Categorisation and merchant-recognition accuracy vary a lot between providers and are easy to overstate in a sales pitch; test against your own real transaction data before committing.
Ask how a provider is preparing for PSD3's stricter API-performance requirements. A provider that's already built toward the incoming standard is a safer long-term bet than one still operating to PSD2's looser expectations.