Open Banking Integration in the UK: APIs, Consent Flows and Product Architecture
How UK open banking integration works: account information and payment initiation, FCA permissions, providers, consent journeys, VRPs and product architecture.
What does UK open banking integration involve?
UK open banking integration connects your product to customers' bank accounts with their consent, to read account data (account information services, AIS) or start payments (payment initiation services, PIS). The customer chooses their bank, is redirected to it to authenticate, and your product receives data or a payment status through APIs built to the Open Banking Standard. Most product teams do not connect to each bank directly: they integrate with a regulated open banking provider, or become an agent of one, rather than seeking their own FCA permissions. The work that follows is product engineering: consent journeys, token and consent storage, data normalisation, payment status handling, reconciliation and monitoring.
This guide is for product owners and engineering leads at UK fintechs, SaaS platforms, lenders, utilities and marketplaces. It is general information as at October 2026, not legal or regulatory advice. Whether your model needs FCA permissions depends on facts that a payments lawyer should assess.
Key takeaways
- Decide early whether you will use a regulated provider, act as an agent, or seek FCA permissions.
- Design the consent journey before the API integration; it decides conversion and trust.
- Treat a payment initiation as accepted, not settled, until the status confirms it.
- Plan for 90-day consent reconfirmation on ongoing data access.
- Build a refund route for push payments; there is no card-style chargeback.
- Monitor bank-level failure rates and offer a fallback payment method.
Account information, payment initiation and VRPs: what each lets you build
Open banking covers a few distinct services. Pick the one your use case needs, because each has different permissions, journeys and failure modes.
| Service | What it does | Typical uses | Regulatory note |
|---|---|---|---|
| Account information (AIS) | Reads balances, transactions and account details with consent | Affordability checks, bookkeeping feeds, onboarding verification, cash-flow tools | Provider must be registered with the FCA as an account information service provider, or you act as its agent |
| Single payment initiation (PIS) | Initiates a one-off payment from the customer's account, usually over Faster Payments | Checkout, invoice payment, wallet top-ups | Provider must be FCA-authorised for payment initiation |
| Sweeping VRP | A series of payments within agreed limits between the customer's own accounts | Moving savings, paying down a credit card from a current account | The nine largest banks (the CMA9) were required to support sweeping |
| Commercial VRP (cVRP) | Recurring payments to a business within agreed parameters | Utilities, financial services top-ups, government payments | Scheme-based; the UK Payments Initiative scheme went live on 2 June 2026, and bank coverage varies |
Do you need FCA permissions?
Under the Payment Services Regulations 2017, account information and payment initiation are regulated payment services. There are three common operating models, and the choice shapes your architecture, contracts and timeline.
| Model | How it works | When it fits | Trade-offs |
|---|---|---|---|
| Use a regulated provider | You integrate the provider's API and hosted or embedded consent screens; the provider holds the permissions | Most SaaS, marketplaces and merchants adding bank payments or data | Fastest route; you depend on the provider's bank coverage, pricing and data format |
| Act as an agent | You are registered with the FCA as the provider's agent and present the service under your brand | Products that want more control of the journey and brand | Provider oversight and contractual obligations; still not your own licence |
| Own registration or authorisation | You apply to the FCA as an AISP or authorised payment institution and connect to banks | Firms whose core business is open banking | Longest route; capital, safeguarding where relevant, governance, audits and ongoing reporting |
Worth noting
If your firm is FCA-regulated and serves retail customers, the Consumer Duty's outcome expectations apply to how you design and explain these journeys. Confirm the position with your compliance adviser.
How should the consent journey work?
The consent journey is where most drop-off happens, so design it as a product flow rather than an integration detail.
- Before the redirect: explain what you will access or pay, why, for how long, and who the regulated provider is.
- Bank selection: offer search and recently used banks; support business accounts if your customers are businesses.
- Redirect: use app-to-app redirection on mobile so customers authenticate in their banking app, with a browser fallback.
- Return handling: handle success, cancellation, timeout and bank errors with clear next steps and a retry.
- Consent dashboard: let customers see active consents, what each covers and when it expires, and revoke it.
- Reconfirmation: for ongoing account access, prompt customers to reconfirm consent every 90 days. Since the FCA's 2021 changes (PS21/19), banks can apply an exemption so customers reconfirm with you instead of re-authenticating with the bank. Some customers will still need to go back to their bank.
Reference architecture
Keep provider-specific code behind your own interface so you can add a second provider, or change provider, without rewriting the product.
| Component | Responsibility |
|---|---|
| Consent service | Creates, stores and expires consents; records scope, purpose, timestamps and reconfirmations |
| Provider adapter | Wraps each provider's API, authentication and webhooks behind one internal contract |
| Data sync and normalisation | Pulls accounts and transactions, de-duplicates, maps to your categories, handles pending versus booked items |
| Payment orchestration | Creates payment requests with idempotency keys, tracks status changes, triggers fulfilment only on confirmed states |
| Ledger and reconciliation | Matches payments to orders or invoices and to bank statement lines; flags gaps |
| Audit and monitoring | Logs consent and payment events, alerts on failure rates by bank, and retains evidence for complaints |
{
"consentId": "cns_8f2a",
"customerId": "cus_1042",
"provider": "provider_a",
"service": "account_information",
"scope": ["accounts", "balances", "transactions"],
"purpose": "monthly affordability review",
"grantedAt": "2026-10-01T09:14:00Z",
"reconfirmBy": "2026-12-30T09:14:00Z",
"status": "active",
"revokedAt": null
}Payment status, refunds and reconciliation
A payment initiation request that the bank accepts is not the same as money received. Statuses move from initiated to authorised to completed or rejected, and some payments stay pending while the bank runs checks. Release goods, credit wallets or mark invoices paid only on the status your provider documents as final, and reconcile against your bank statement as well as webhooks.
Open banking payments are push payments, so there is no card-style chargeback and no built-in refund. Decide how refunds work, often as a payout to the customer's account through your provider, and say so before the customer pays. For matching payments, payouts and fees to your ledger, see payment reconciliation automation.
Reliability and data quality
- Bank APIs differ in data completeness, transaction descriptions and pending items; normalise and test with several banks.
- Expect bank-side outages; Open Banking Limited publishes API performance statistics, and your provider should expose bank status.
- Use retries with idempotency and webhooks with reconciliation; see API integration reliability.
- Offer a fallback, such as card or manual bank transfer, when a customer's bank is unavailable.
- Keep only the account data you need, for as long as you need it, under UK GDPR.
- Log consent and payment events so you can answer complaints and disputes.
Hypothetical example: invoice payments for a B2B platform
This example is hypothetical. A UK field-services platform sends invoices to small business customers who usually pay by bank transfer with inconsistent references. It adds a pay-by-bank button through a regulated provider: the invoice amount and reference are prefilled, the customer authenticates in their banking app, and the invoice is marked paid only when the provider reports a completed status. Card payments stay available as a fallback, and a nightly job reconciles completed payments against the bank statement. The team sets up an account information consent separately, only for customers who opt in to cash-flow insights.
How UK open banking differs from Australia's Consumer Data Right
The UK regime started from payments regulation, so payment initiation is central, while Australia's Consumer Data Right started as a data-sharing right with its own accreditation and consent rules. If you operate in both markets, share the consent and data components but keep the regulatory logic separate. See Consumer Data Right integration in Australia.
What is changing
The Competition and Markets Authority confirmed in September 2024 that the original Open Banking Roadmap was complete. The FCA now leads. On 2 June 2026 it welcomed the launch of the industry-led UK Payments Initiative scheme for commercial VRPs and said it will consult on a long-term regulatory framework by the end of 2026, subject to expected legislation, and supports an independent standards body (FCA statement). The FCA has also published a roadmap for open finance, and the Data (Use and Access) Act 2025 gives the government powers to create smart data schemes in other sectors.
Treat these as moving parts: check scheme membership, bank coverage and FCA publications before committing to a cVRP-dependent product.
Common mistakes
- Building the integration before deciding the regulatory model.
- Treating an accepted payment request as settled funds.
- No refund process for push payments.
- No consent dashboard or reconfirmation reminders.
- Hard-coding one provider's data format throughout the product.
- Assuming every bank supports commercial VRPs.
Sources
Regulation: Payment Services Regulations 2017; FCA PS21/19 (SCA-RTS changes, 90-day reconfirmation); FCA statement on the UK Payments Initiative, 2 June 2026.
Standards and context: Open Banking Standards; Open Banking Limited: CMA confirms roadmap completion; Data (Use and Access) Act 2025.
Accessed 10 October 2026. Scheme coverage and FCA policy are changing; check current publications. Nothing here is legal or regulatory advice.
Conclusion
Successful UK open banking products settle the regulatory model first, design consent as a product journey, and treat payment status, refunds and reconciliation as first-class features. Keep providers behind your own interface, monitor failures by bank, and keep a fallback. Watch the FCA's consultation on the long-term framework and commercial VRP coverage before building products that depend on them.
Adding pay by bank or account data to your product?
ZSpace Labs is a remote-first technology studio that works with clients globally, building web applications and integrations and mobile apps. We have no UK office and work with your regulated provider and advisers rather than replacing them. If it would help to map the consent journey and architecture, we are happy to talk it through.
Common questions.
A regulated framework, based on the Payment Services Regulations 2017 and the Open Banking Standard, that lets authorised or registered third parties read payment-account data (account information services) and initiate payments (payment initiation services) with the customer's consent, through bank APIs.