Open banking & PSD2 for UK accountants — what changed, what’s coming.

The short answer

UK Open Banking under PSD2 lets accounting software read your clients’ bank data (via a regulated AISP) and, less commonly, initiate payments on their behalf (via a regulated PISP). The consent expires every 90 days and must be re-confirmed by the client. The data flow is transparent: bank → FCA-authorised AISP → software vendor → user. The FCA’s Payments Vision (2024) is shifting the regime through 2026–2028 — longer consent windows, expanded Variable Recurring Payments, and smart-data feeds beyond banking. Accountants who understand the mechanics will pick better software and explain it better to clients.

1. PSD2 in plain English

The EU’s Second Payment Services Directive (PSD2), transposed into UK law via the Payment Services Regulations 2017 (PSRs), did two important things for UK accounting:

• Forced banks to expose customer data via APIs — with the customer’s explicit consent, third parties can read account balances, transactions and account holder details. This is the foundation of every modern bank feed in accounting software.
• Created two new regulated roles: Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs). Both require FCA authorisation (or, for small firms, FCA registration) before they can operate.

In the UK, the rollout was overseen by the Competition and Markets Authority (CMA), which mandated the nine largest banks (the “CMA9”) to expose standardised APIs. The Open Banking Implementation Entity (OBIE), now transitioning to a new body, defines the technical standards. The FCA regulates the third parties using those APIs.

2. AISP vs PISP — who does what

Most UK accounting software uses an AISP for bank feeds. PISP is rarer in the accounting world (more common in pure payments products like Adfin, the SmartBooks payments partner), but is starting to appear in “pay your VAT return now” flows inside accounting software.

3. The 90-day consent cycle

Under current FCA / EBA Regulatory Technical Standards, customer consent for account-information access expires every 90 daysand must be re-confirmed. The point is to keep the customer actively aware of which third parties have access to their data — a security control, not a vendor limitation.

The re-auth flow is light:

1. Bank notifies the customer that access is about to expire (typically 7–14 days before).
2. Software (SmartBooks) shows a banner / email prompt.
3. Customer logs into their bank app or website.
4. Bank confirms the access (Strong Customer Authentication).
5. Feed resumes — historic data is untouched, new transactions flow again.

For a firm managing 100 clients with bank feeds, that’s roughly 1 re-auth event per client per quarter — or ~8–10 re-auths per week on a steady state. Build the renewal nudge into your quarterly review cadence rather than treating it as ad-hoc admin.

What’s changing:the FCA is consulting on extending this period — potentially up to 180 days for certain low-risk uses — as part of the Open Banking strategic review. If implemented, this materially reduces the renewal burden through 2026–2027.

4. FCA authorisation — how to vet providers

Every AISP and PISP operating in the UK must be either FCA-authorised (full PSD2 authorisation) or FCA-registered (for small AISPs under specific conditions). Before trusting a provider with your clients’ bank data, check the FCA register:

• Go to register.fca.org.uk.
• Search for the provider’s legal entity name.
• Confirm they hold AISP permissions for account-information services and/or PISP permissions for payment initiation.
• Check their status (Authorised / Registered / Restricted).
• Verify the firm reference number (FRN) matches what the provider publishes.

SmartBooks’ provider:Yapily (Yapily Connect Ltd or the relevant Yapily group entity at the point of consent). Their FCA authorisation is verifiable on the register. SmartBooks itself is not an AISP — we are software that uses Yapily on the customer’s behalf. This is the standard pattern for UK accounting software.

5. Who actually sees the data

Three parties have visibility into the bank data:

1. The bank itself — obvious, but worth stating. They’re the source.
2. The FCA-authorised AISP — intermediates the API call, fetches the data, returns it to the calling software. Their PSD2 obligations include not retaining data beyond what’s needed and not using it for any purpose other than fulfilling the request.
3. The accounting software vendor — receives the data from the AISP and displays it to the user. Their privacy notice should explicitly list the AISP as a sub-processor.

Who does NOT see the data:

• Advertisers — bank-transaction data cannot be used for advertising under PSD2.
• Data brokers — resale is prohibited.
• Other software vendors — no aggregation across products without explicit fresh consent.
• The accountancy firm working with the client — unless the client explicitly grants firm-user access to the data inside the software product (a separate authorisation, not part of the AISP consent).

SmartBooks documents this flow explicitly in the privacy notice sub-processor list, and on the security page.

6. Bank coverage — what works, what doesn’t

In the UK in 2026, Open Banking coverage is broad:

• CMA9 banks (Lloyds, HSBC, Barclays, RBS/NatWest, Santander, Nationwide, Bank of Ireland, Allied Irish, Danske) all required and live.
• Most challenger banks and digital-first — Monzo, Starling, Revolut Business, Tide, Mettle, Anna, Coconut, etc. — all live.
• Most business banks — Metro Bank, Cynergy, Allica, OakNorth, etc.
• Coverage gaps in 2026 are rare and tend to be very small building societies, specialist business banks, or foreign-currency accounts. Falling back to CSV import preserves the digital link if Open Banking isn’t available.

SmartBooks uses Yapily, which integrates with all of the above on a single API surface. The bank-list view inside the product reflects current coverage.

7. Variable Recurring Payments (VRP) and what’s coming

Variable Recurring Payments is a payment-initiation pattern: the customer authorises repeating payments to a single payee, possibly within parameters (max amount, max frequency), without re-authenticating each one. Two flavours:

• Sweeping VRP — mandated by the CMA on the CMA9. Moves money between accounts owned by the same customer (e.g. main current account to savings). Live.
• Commercial VRP — for non-sweeping use cases (pay a supplier, pay HMRC). Rolling out under the FCA Payments Vision and the JROC (Joint Regulatory Oversight Committee) framework through 2026.

For accountants, the practical implications:

• Pay HMRC payments-on-account by VRP — your client sets up a VRP authorising you to pay their July and January POAs from their account without re-authenticating each time. Reduces missed payments materially.
• Pay supplier invoices in bulk — one approval covers multiple individual payments.
• Pay quarterly VAT — client authorises VAT payment from the return-period balance.

SmartBooks doesn’t ship VRP today. It’s on the roadmap once Yapily’s VRP rails are production-ready and we have the FCA-appropriate consent flow.

8. The FCA Payments Vision in plain English

The FCA published its Payments Vision in late 2024, outlining the regulatory direction for UK payments through 2030. The headlines that matter for accountants:

• Open Banking expanding beyond PSD2. The current PSD2-mandated regime is moving toward a commercial-led model, with longer consent windows, broader use cases, and richer data fields.
• Variable Recurring Payments at scale. Commercial VRP roll-out through 2026, materially changing how clients pay HMRC and suppliers.
• Smart Data framework. The Data (Use and Access) Bill (going through Parliament 2025) extends the Open-Banking-style API pattern to other regulated sectors — energy, telecoms, transport. For accountants this means future smart-data feeds (e.g. an energy supplier’s API for VAT-relevant consumption data).
• Authorised Push Payment (APP) fraud rules. Mandatory reimbursement rules from October 2024 changed the bank-fraud landscape. Firms helping clients investigate APP-fraud claims should be aware of the new 5-business-day investigation window.
• Stablecoins and digital pound considerations. Longer term, but the FCA’s Vision flags them. Not immediately relevant to mainstream UK accounting but worth tracking.

9. Practical implications for your firm

Five things to do in 2026:

1. Audit your software stack’s AISP provider. Verify FCA authorisation on the register. Check the privacy notice lists the AISP as a sub-processor. Confirm UK or EU data residency for the access flow.
2. Build the 90-day re-auth nudge into your client cadence. Don’t treat it as ad-hoc admin. Quarterly review — check feed status — nudge client to re-authenticate if expiring — resume.
3. Explain Open Banking to new clients honestly. Bank data flows through a regulated AISP, not just “the software”. Name the AISP. Clients value the transparency.
4. Watch for commercial VRP rollout. Sweeping VRP is live; commercial VRP follows in 2026. Once available, “pay HMRC by VRP” is a meaningful firm offering.
5. Consider smart-data feeds beyond banking. Energy, telecoms and transport APIs are coming. Firms whose software supports them first will have a workflow advantage on data quality.

10. Where SmartBooks fits

SmartBooks uses Yapily as its AISP for UK Open Banking access. Yapily is FCA-authorised; their register entry is publicly searchable. Our application to use Yapily in production is currently in progress (alongside our HMRC production-credentials application).

In the meantime:

• For pilot customers: bank-feed setup uses Yapily once the application lands. Until then, CSV import preserves the digital link.
• The consent flow will explicitly name Yapily as the regulated provider accessing data — not just “SmartBooks”.
• The 90-day re-auth cycle is built into the product with renewal nudges to bookkeepers ahead of expiry.
• Future VRP support for HMRC and supplier payments is on the roadmap, contingent on Yapily’s VRP rails being production-ready in the UK.

Canonical status of SmartBooks’ AISP integration is on the Trust & security page; the sub-processor entry is in the privacy notice.

Related guides

• Strong Customer Authentication (SCA) explained — how authentication actually works under PSD2.
• APP fraud rules for UK accountants — what regulation doesn’t prevent.
• MTD ITSA April 2026 — what it means for firms
• Pricing MTD ITSA quarterly returns
• Best MTD VAT software 2026 — picked by use case
• Trust & security — current sub-processor list and HMRC recognition status.
• Privacy notice — how sub-processors are listed, the lawful basis for processing, the data-flow diagram.

FAQ

A note on advice

This guide is general operational guidance on UK Open Banking and PSD2. It is not regulatory or legal advice for a specific firm. UK firms should consult their professional body (ICAEW, ACCA, AAT), the FCA’s published guidance at fca.org.uk, and a suitably qualified solicitor for any specific compliance question. The FCA Payments Vision and the Data (Use and Access) Bill are evolving through 2026 — specific timelines may shift; verify against current FCA publications before relying on dates in this guide.