Open banking forced banks to expose accounts through regulated APIs so licensed third parties can read data or initiate payments — with the customer’s consent. A decade in, it is real in the UK and EU, mandated harder under PSD3, and barely begun across most of Africa.
Open banking is access-with-consent, mandated by a regulator. No mandate, no genuine open banking — just bilateral API deals.
Open banking is the regulated ability for a licensed third party to access a customer’s bank account — to read data or initiate a payment — through a standardised API, with the customer’s explicit consent. The bank must open the door; the third party must be authorised; the customer is in control.
It exists because regulators decided the customer, not the bank, owns the relationship to their own data and money. PSD2 in the EU was the lever: it obliged banks to provide third-party access and banned the old screen-scraping workarounds in favour of secure, dedicated APIs.
Open finance is the extension of the same principle beyond payment accounts — to savings, investments, pensions, insurance and credit. Open banking was the first chapter; open finance is the book.
AISP reads, PISP pays. The consent and SCA model is what separates open banking from the screen-scraping it replaced.
The regulated third party (a TPP) plays one or both of two roles, and everything hinges on a strong, revocable consent.
| Role | Full name | What it does | Example use |
|---|---|---|---|
| AISP | Account Information Service Provider | Reads account data — balances, transactions — with consent | Budgeting apps, affordability/credit checks, account aggregation |
| PISP | Payment Initiation Service Provider | Initiates a payment from the customer’s account on their instruction | Pay-by-bank checkout, account top-ups, bill payment |
Access is scoped, time-bound and revocable. The customer authenticates with their own bank (SCA), not the third party — the TPP never sees credentials.
PSD2 requires multi-factor authentication for access and payment initiation. It is the security floor that made API access acceptable to regulators.
Banks must expose secure interfaces. Standardised specs (UK OBIE, Berlin Group NextGenPSD2) reduce the integration burden across thousands of banks.
Payment initiation is what turns open banking into a card alternative — it is the regulated API that powers “pay by bank” over A2A rails.
The UK’s VRP lets a customer pre-authorise a TPP to make recurring payments within set limits — the open-banking answer to card-on-file and direct debit. ~16% of UK open-banking payments by 2026.
PSD2 (in force 2018) created the legal basis: it mandated third-party access, defined AISP/PISP, required SCA, and forced banks to build APIs. It was deliberately a competition intervention — break the banks’ monopoly on the customer relationship.
The EU is now finishing the job with PSD3 and the Payment Services Regulation (PSR). The agreed texts were published in April 2026, with publication in the Official Journal expected mid-2026 and the rules generally applying around 21 months later. PSD3/PSR tightens API performance and quality, improves fraud liability and confirmation-of-payee, and lays groundwork for open finance (via the separate FIDA framework). The intent: fix the patchy, inconsistent API quality that held PSD2 back.
The UK diverged after Brexit. It retained on-shored PSD2 but is steering via the Payments Forward Plan (Feb 2026, from HM Treasury, FCA, PSR and the Bank of England), a 2026–2028 roadmap covering much of the same ground — including the commercial VRP expansion under the new UK Payments Initiative.
The UK proved that mandate + common standard + central body works — and that API quality, commercial incentives and liability clarity are the unglamorous things that decide whether it scales.
The UK is the reference implementation. The CMA ordered the nine largest banks to fund a central body — the Open Banking Implementation Entity (OBIE), now Open Banking Limited (OBL) — to build a single API standard, a directory of TPPs, and conformance testing. A common standard plus a mandate plus a referee is why the UK led.
PSD2 mandated access but not consistent quality. Flaky, slow or non-conformant bank APIs broke TPP user journeys and stalled adoption — the gap PSD3/PSR explicitly targets.
Banks were forced to spend on APIs with no direct revenue. Without premium/commercial APIs, the incentive to maintain quality was weak — hence slow improvement.
Early rules forced frequent re-consent (e.g. 90-day SCA re-authentication for AISPs), breaking long-lived data connections. Rules have been relaxed, but UX scar tissue remains.
When a PISP payment goes wrong, who is liable — TPP, bank, or scheme? OBL itself flagged gaps in dispute processes and consumer protection. Push finality (no chargeback) makes this sharper.
A mandate produces access, not usage. UK volumes grew steadily but took years; assuming a regulatory open-banking regime instantly yields a card-killer is the recurring mistake.
Open banking in Africa is early and uneven. There is no continent-wide PSD2 equivalent. What exists is a mix of market-led API initiatives, bank-fintech partnerships, and regulators watching the EU/UK before moving.
South Africa has the ingredients but not the mandate. The SARB’s payments modernisation programme and the 2026 opening of the National Payment System to non-bank PSPs create room for data-and-initiation services, but there is no obligatory open-banking API regime — access is largely commercial and bilateral, often intermediated by aggregators. This is closer to “open banking by partnership” than the mandated UK/EU model.
Elsewhere, Nigeria has moved furthest, with a Central Bank of Nigeria open-banking framework and operational guidelines — among the first mandated regimes on the continent. The realistic read for Africa: open banking will arrive market by market, often built on top of the mobile-money and instant-payment rails that already dominate, rather than the bank-account-centric model the EU started from.
If you lend, underwrite, or assess affordability in the UK/EU, consented account data beats inference and screen-scraping. It is the cleanest path to real-time affordability — and increasingly the regulated expectation.
For high-value or low-margin checkout in mature open-banking markets, PISP A2A payment can undercut card interchange materially. Pair it with VRP for recurring use cases that previously needed card-on-file or direct debit.
Building a UX that assumes uniform, high-quality bank APIs will break on the weakest bank in your coverage. And treating PISP payments like card payments — expecting chargebacks — leaves your refund and dispute handling exposed to push finality and unresolved TPP/bank liability.
Do not wait for a South African PSD2 — it is not imminent. If you need open-banking-style data or initiation in SA today, you will go through a commercial aggregator or direct bank partnership. Design for that bilateral reality, and watch the 2026 NPS reforms for when a mandated regime becomes plausible.