How Open Banking Works
Open banking replaces proprietary bank integrations and screen-scraping with standardised, regulated APIs. A licensed third-party provider requests access on behalf of the user, the user authenticates directly with their bank, and the bank returns data or executes the payment — all within seconds. No credentials are shared, and the access is scoped to exactly what the customer approved.
User Grants Consent
The customer initiates a flow — for example, clicking "Pay by bank" at checkout. The third-party provider presents a scoped consent request specifying what data it needs or what payment it will initiate. The customer reviews the scope, confirms, and proceeds.
Redirect to Bank Authentication
The customer is redirected to their bank's authentication page or, on mobile, deep-linked directly into their banking app. They authenticate using existing credentials or biometrics. No password or account details are shared with the merchant or the provider.
Bank Issues an Access Token
On successful authentication, the bank issues a time-limited OAuth 2.0 access token to the provider. This token encodes the exact permissions granted — nothing more. It cannot be used to access data or initiate payments outside the approved scope.
Data or Payment Flow Executes
The provider calls the bank's API with the token. For account-to-account payments, the bank executes the payment instruction in real time. For account information requests, it returns balance, transaction history, or identity data as specified in the consent.
Confirmation and Settlement
The merchant receives a real-time payment confirmation. Funds move directly between bank accounts — typically via Faster Payments in the UK or SEPA Instant in the EU — with no card network involved, no interchange fee, and no chargeback window by default.
Why Open Banking Matters
Open banking is one of the most significant structural shifts in payments since the card network era. For merchants, the cost case alone is compelling: payment initiation via open banking APIs carries no interchange fee and no card scheme fee, translating directly into margin improvement at scale. The macroeconomic signals confirm this is not a niche experiment.
- Volume trajectory: Juniper Research forecasts global open banking payment volumes will surpass 116 billion transactions annually by 2027, up from roughly 13 billion in 2022 — a near-tenfold increase in five years driven by PSD2 maturation and emerging-market regulatory rollouts.
- Merchant cost advantage: Merchants processing via open banking APIs pay an average of 40–60% less per transaction compared to card-based alternatives, according to Open Banking Excellence benchmarking data from 2023 — primarily because interchange and scheme fees are eliminated entirely.
- Adoption depth: The UK — the world's most mature open banking market — reported 11.7 million active open banking users and over one billion API calls per month as of Q1 2024, per OBIE published data, demonstrating that consumer trust in the model has crossed a critical threshold.
PSD2 in Europe and the UK's Open Banking Standard created the regulatory floor that made this scale possible by forcing banks to open their infrastructure to licensed competitors. Without that mandate, banks had every commercial incentive to keep their APIs closed.
Settlement speed advantage
In markets with real-time payment rails — Faster Payments in the UK, SEPA Instant in the EU — open banking payments settle in under ten seconds. Card settlements typically take T+1 to T+2 days, tying up merchant working capital and creating reconciliation overhead.
Open Banking vs. Card Payments
Open banking and card payments both move money from a customer to a merchant, but the mechanics and economics differ fundamentally. The table below compares the two across the dimensions that matter most to payment professionals and ecommerce operators.
| Dimension | Open Banking | Card Payments |
|---|---|---|
| Payment rail | Bank-to-bank (Faster Payments / SEPA Instant) | Card network (Visa, Mastercard, etc.) |
| Interchange fee | None | 0.2–2.5% depending on card type and region |
| Scheme fee | None | Yes — per-transaction, typically 0.1–0.3% |
| Settlement speed | Seconds to minutes | T+1 to T+2 days |
| Chargeback risk | Low — push payment, hard to reverse | High — customer-initiated chargebacks |
| Primary fraud vector | Authorised Push Payment (APP) fraud | Card-not-present fraud, BIN attacks |
| Authentication strength | Strong — bank app or biometrics mandatory | 3DS optional; varies by merchant |
| Global acceptance | Growing; strongest in EU, UK, Brazil | Near-universal |
| Refund mechanism | Manual credit transfer required | Automated reversal via card network |
| Data shared with merchant | Minimal — confirmation only | PAN, expiry, CVV in some flows |
Instant payments infrastructure is what gives open banking its settlement speed advantage. Where real-time rails exist, open banking becomes a direct substitute for card payments with structurally better unit economics.
Types of Open Banking Services
Open banking is not a single product — it is a regulatory and technical framework that enables several distinct service categories. Understanding which type applies to your use case determines the technical approach, licensing requirements, and risk profile you are taking on.
Account Information Services (AIS) provide read-only access to account data: balances, transaction history, income patterns, and identity signals. AIS powers credit underwriting decisions, personal finance management apps, KYC enrichment, and affordability checks in lending.
Payment Initiation Services (PIS) instruct a bank to execute a payment from a customer's account directly to a merchant's or recipient's account. PIS is the open banking equivalent of a payment gateway — it is what replaces the card at checkout and eliminates the card network from the flow.
Confirmation of Funds (CoF) is a lightweight yes/no API call: does this account have sufficient funds for a given amount? CoF is used in car hire pre-authorisations, hotel holds, and pre-screening lending applications without exposing the customer's actual balance.
Variable Recurring Payments (VRP) allow a licensed provider to initiate a series of payments within pre-agreed parameters — amount limits, frequency, and purpose. VRP is a more flexible and transparent alternative to the direct debit mandate and is live in production in the UK for account sweeping, with commercial use cases expanding.
Banking-as-a-service and embedded finance platforms frequently build on top of open banking APIs to deliver financial products inside non-financial applications — from invoice financing embedded in accounting software to real-time cash-flow analytics inside ERP systems.
Best Practices
Implementing open banking well requires attention to UX, compliance, and operational resilience simultaneously. Technically valid integrations that ignore the customer experience fail in production; polished flows that cut corners on security create regulatory exposure.
For Merchants
- Offer open banking as a method, not a mandate. Present it alongside cards in a clearly labelled payment method selector. Forcing customers into it where bank API coverage is uneven will increase abandonment and skew your payment success data.
- Surface the value at the point of selection. Most customers do not recognise what "Pay by bank" means. A concise descriptor — "Instant. No card needed. Secured by your bank." — significantly outperforms a generic button label in conversion testing.
- Track authorisation rates per bank. Individual bank API uptime varies, sometimes dramatically. Segment your success rate reporting by bank so a single underperforming institution does not mask broader trends or obscure a real integration problem.
- Design explicit fallback paths. If the bank authentication step fails or times out, redirect customers to a card option with a clear, apologetic message. A dead-end error screen costs the sale and damages trust.
For Developers
- Implement FAPI 1.0 Advanced security profiles. Standard OAuth 2.0 is not sufficient for regulated open banking. Use Pushed Authorisation Requests (PAR) and JWT-Secured Authorisation Responses (JARM) where required by your target market's technical standards.
- Handle token expiry and re-consent flows proactively. Access tokens are short-lived by design. Build re-consent journeys that are low-friction and transparent, particularly for AIS use cases that require ongoing periodic access.
- Test every bank in every target market. Banks implement the open banking specification differently, interpret ambiguous requirements inconsistently, and update their sandboxes on independent schedules. Run integration tests against each bank and regression-test after every API version bump.
- Maintain immutable consent audit logs. Regulators can — and do — request evidence of consent grants. Log the timestamp, scope, version, and session context of every consent event and retain it for the period required by applicable law.
Common Mistakes
Open banking implementations fail in predictable ways. Understanding these failure modes before building saves significant remediation time and protects customer relationships.
1. Treating consent as permanently valid. Open banking consent is scoped and time-limited. Systems that assume a stored token is still valid will fail silently when tokens expire or are revoked by the customer. Always check token validity before initiating any API call.
2. Omitting fallback payment methods. Bank APIs experience downtime. An open banking-only checkout loses revenue every time a bank has an outage. Design for failure at the architecture level and route to cards or alternative methods automatically.
3. Neglecting the redirect experience. The bank redirect or deep-link is the highest-drop step in an open banking payment flow. Poor loading states, broken mobile deep links, or unclear messaging cause abandonment that appears in analytics as payment failure but is actually a UX defect with a straightforward fix.
4. Conflating open banking with open finance. Open banking covers current accounts and payment initiation. Open finance extends the model to mortgages, pensions, and investments under different regulatory frameworks and different API standards. Treating them as interchangeable leads to scope creep and compliance gaps.
5. Underestimating Authorised Push Payment (APP) fraud risk. Open banking payments are push payments: once authorised, they are operationally difficult to reverse and carry no chargeback mechanism. Fraud detection must operate before the authorisation step, not after, because the consumer protection backstop available in card payments does not exist here in the same form.
Open Banking and Tagada
Open banking is a first-class payment rail in Tagada's orchestration layer. Payment teams operating across multiple markets face a fragmented landscape: different open banking APIs per country, varying bank coverage levels, inconsistent success rates, and no unified reporting layer. Tagada normalises this complexity behind a single integration point.
Tagada routes open banking transactions alongside cards and alternative payment methods through one API. If a customer's bank API is unavailable during checkout, Tagada's smart routing falls back to the next viable payment method automatically — preserving conversion without manual intervention. This is what payment orchestration is built to solve at scale: turning a patchwork of open banking providers into a resilient, measurable, commercially optimised payment stack.