FCA Just Rewrote the Open Banking Playbook for 2026. Here's What UK Payment Developers Actually Need to Know

I'm the CTO of an FCA-authorised Payment Institution. I spend most of my week either writing payments code or reading FCA / PSR consultation papers so my team doesn't have to.

2026 is the year that work stopped being optional for everyone else.

Three things shifted in the first half of the year, and if you ship anything that touches UK payments — checkouts, wallets, invoicing, recurring billing — at least two of them affect your roadmap. Most developer threads I read are still pattern-matching open banking onto "OAuth, but for banks." The actual changes are more interesting than that, and a lot more consequential.

Here's the part I wish someone had handed me as a one-pager.

1. Variable Recurring Payments went from "spec" to "shipping"

The FCA confirmed that the first commercial Variable Recurring Payments (VRPs) under the UK Payments Initiative scheme started flowing in Q1 2026. Phase 1 covers utilities, financial services top-ups, and payments to local and central government. (FCA / PSR joint statement on open banking pricing models)

For developers, this is the line where open banking stops being a one-off-payment toy and starts looking like a real subscription rail.

What changes in your code:

• Consent has duration now. A VRP consent is the closest thing UK open banking has ever had to "card-on-file." The user authorises a mandate — amount caps per period, total cap, expiry — and you can initiate payments against it without a fresh SCA dance every time. That's a different state machine than single-payment PIS.
• You need to store mandate IDs, not card tokens. The shape of the entity you persist is closer to a Direct Debit instruction than a Stripe payment_method. Caps, frequency, last-used timestamp, status, revocation timestamp.
• Revocation is bank-side, not app-side. Users can kill a VRP mandate inside their banking app and you get a webhook telling you it's gone. If your retry logic assumes the mandate is still good because the user didn't cancel in your UI, you'll log a lot of 401s.
• Pricing is now regulated. The FCA / PSR joint statement in 2026 explicitly addressed VRP pricing models. Translation: this is no longer a back-room commercial conversation between ASPSPs and TPPs. The rate card has rails.

If you're SaaS-billed-monthly and your customers are UK consumers, this is the first year where "switch from cards to open banking" is a real engineering conversation, not a 2027 prediction.

2. The FCA is getting actual rule-making powers over open banking

The other big shift: the Data (Use and Access) Act gives the FCA new statutory powers to set open banking rules directly, rather than acting through the legacy CMA-mandated framework. The FCA has said it will consult on the long-term regulatory framework before the end of 2026, with workshops over the summer and autumn. (FCA: Open banking — a year of progress)

A developer-facing translation:

• The Open Banking Implementation Entity (OBIE) era is winding down. A "Future Entity" is being stood up — the FCA wrote to trade associations in late 2025 and expected the process to kick off around February 2026. (Open banking — process to establish a Future Entity)
• The Open Banking Standard you've been integrating against will get formalised into FCA rules instead of CMA orders. Same spec, harder enforcement, broader scope.
• Expect new categories of regulated activity to land in scope: open finance (savings, pensions, investments, insurance) is being framed as the next phase, and the FCA published a vision paper for it. (FCA: vision for open finance)

If you're betting on open banking, you're now betting on a rail with a clearer regulator on top of it. That tends to be good for serious builders and bad for people who were treating PISP authorisation as optional.

3. The architecture decision hasn't changed, but the stakes have

The architectural choice for any UK payment developer is still binary, and it's the same one I wrote about in What Developers Get Wrong About PSD2 a few weeks ago:

1. Become an FCA-authorised PISP yourself. Months of compliance work. A regulated entity. Ongoing capital requirements. Direct ASPSP relationships. Worth it if payments is your business.
2. Integrate against an authorised provider. Days, not months. One API. Webhook semantics that don't change every time a CMA9 bank updates their consent flow.

What 2026 changes is the cost of getting this wrong. With VRPs going live, open finance on the roadmap, and the FCA now sitting on direct rule-making powers, the compliance surface is going to grow. If you've shipped a bank-by-bank integration, that surface grows linearly with every spec revision. We learned this running payments services across the CMA9 — every quarter, something changes.

If you're not a payments company, don't become one by accident.

What the integration actually looks like

Same minimal pattern as a single-payment PIS, slightly different envelope for VRP. A mandate creation against Atoa looks roughly like this:

// 1. Create a VRP mandate
const mandate = await fetch('https://api.atoa.me/v1/mandates', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${ATOA_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    reference: subscription.id,
    period: 'monthly',
    max_amount_per_period: 4999,   // £49.99 cap per month
    max_total_amount: 599999,       // £5,999.99 lifetime cap
    expires_at: '2027-05-13',
    redirect_url: 'https://app.example.com/mandates/return',
  }),
}).then(r => r.json());

// 2. Send the customer to mandate.authorisation_url
return res.redirect(mandate.authorisation_url);

// 3. Later, charge against the mandate without re-authing the user
const payment = await fetch(`https://api.atoa.me/v1/mandates/${mandate.id}/payments`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${ATOA_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    amount: 4999,
    currency: 'GBP',
    reference: invoice.id,
  }),
}).then(r => r.json());

The user does SCA once, when the mandate is created. Every subsequent charge is a single API call. No 3DS dialogs. No saved-card vault. No PAN data on your servers.

This is the thing developers don't realise until they ship it: the new open banking rail isn't a worse Stripe — it's a different shape, and once VRPs are live, that shape covers most of the cases card-on-file used to.

What I'd do this quarter

If you're shipping UK payments in 2026, three concrete moves:

1. Add VRP to your payments roadmap, even if you don't ship it this quarter. The schema you'd need to model mandates is going to land in your codebase eventually. Sketch the data model now while you're still designing.
2. Decide whether you're integrating directly or through an aggregator before the FCA consultation lands. The new rules will reset the bar for "compliant" — if you're piecing together bank integrations, you've now got a regulatory clock on top of an engineering one.
3. Subscribe to the FCA consultation feed. Genuinely. The 2026 papers will set the rails for the next five years. (FCA: vision for open finance)

This is the moment open banking stops being "the alternative" and starts being "the rail." If you're a developer shipping UK payments, the bet you're being asked to make this year is whether you want to build on the rail before it's mainstream, or after.

I'd build on it now.

---

If you want to try the API and skip the regulatory headache, the sandbox is open: docs.atoa.me.