Variable Recurring Payments: Open Banking's Killer Use Case (and Why It's Still Hard)

Variable Recurring Payments (VRP) is the open banking use case that most directly threatens card networks, and sits at the center of evolving PSP and infrastructure decisions for subscription-based operators. A VRP lets a merchant or platform initiate a payment pull from a customer's bank account on a variable schedule and for a variable amount — subject to consent limits the customer sets upfront. No card number. No card network. No interchange. Settled bank-to-bank via Faster Payments in the UK or SCT Inst in the EU — the same infrastructure governed by the EU Instant Payments Regulation.

The commercial case is obvious. For subscription platforms, marketplaces, utility billers, and any operator running recurring charges, VRP eliminates the 1.5–3% card MDR on each recurring transaction. For high-frequency, lower-value recurring flows — streaming services, SaaS, insurance premiums — the economics are compelling.

The operational reality in August 2026 is more qualified than "coming soon." UK sweeping VRP is mandated and has been live since 2022. Commercial VRP is now live too, as of 2 June 2026 — but only for a specific set of regulated sectors under a new multilateral scheme, the UK Payments Initiative (UKPI). The wave that would open commercial VRP to subscription billing and general e-commerce — the use case most of this article is written for — hasn't launched; it's expected later in 2026 with no confirmed date. The EU's equivalent framework exists in regulation but is still short of formal adoption. This article maps what's actually live, what's still pending, and what to build for.

The UK Framework: Sweeping vs Commercial VRP

VRP's standards and governance sit with Open Banking Limited (OBL) — the body that succeeded the original Open Banking Implementation Entity (OBIE) in 2023 — operating under oversight from the Payment Systems Regulator (PSR) and Financial Conduct Authority (FCA). OBL itself is mid-transition: the FCA's Joint Regulatory Oversight Committee (JROC) has wound down, and a successor "Future Entity" has been in design since 2025, with HM Treasury legislation to formally establish it anticipated in Q4 2026 and a formal appointment expected after end-2026. Until that lands, OBL remains the operating body. The mandate distinguishes two VRP categories:

VRPs accounted for 16% of all UK open banking transactions as of late 2025, mostly through sweeping use cases (FCA/PSR joint update on commercial VRP delivery, December 2025) — a figure covered in context in the open banking payments real adoption analysis for 2026. More recent figures show the broader open banking base still growing fast: OBL's Payments Fraud Monitor reported more than 19 million active user connections and over 40 million open banking payments a month as of its June 2026 edition, published July 2026. Sweeping VRP covers transfers between accounts that a single customer owns — moving money from a current account to a savings account, paying down a credit card, or funding an investment account. Sweeping VRP is covered by the CMA's Open Banking Order and was mandated for the UK's nine largest banks (the "CMA9") with a compliance deadline.

Commercial VRP covers payments from a customer's bank account to a third-party merchant or service provider — the subscription, bill payment, and platform payment use case. Commercial VRP is not covered by the CMA Order and has no regulatory mandate; it now runs on an industry-built scheme (UKPI, detailed below) rather than a compliance deadline.

This distinction is the root cause of most operator frustration with VRP. The use case that has commercial value — charging a customer's bank account for their monthly subscription — is the industry-led, non-mandated version, and its rollout depends on scheme-by-scheme sector eligibility rather than a single go-live date.

Sweeping VRP: Current State

Sweeping VRP is live across the CMA9: Barclays, HSBC Group (covering HSBC and First Direct), Lloyds Banking Group (Lloyds, Halifax, Bank of Scotland), Nationwide, NatWest Group (formerly RBS), Santander, AIB Group (UK), Bank of Ireland (UK), and Danske (UK). OBL publishes the sweeping VRP technical standards, and all nine have implemented APIs to at least minimum specification.

In practice, sweeping VRP quality varies significantly. NatWest and Lloyds have the most developer-friendly implementations with documented edge case handling. Barclays' implementation has historically had higher error rates on consent management edge cases. The FCA has continued monitoring bank API quality but enforcement has been light — banks that implement below-standard APIs face reputational rather than financial consequences.

Use cases built on sweeping VRP include: automated savings round-ups (Plum, Chip), debt repayment automation, and investment account funding. The market has grown but remains small relative to the total recurring payment opportunity because sweeping is consumer-to-own-account only.

Commercial VRP: Wave 1 Is Live, Wave 2 Is the One That Matters

The PSR and FCA pursued commercial VRP through an industry-led rather than mandated approach, and that approach has now shipped. Thirty-one firms — Token.io plus the major UK retail banks (Barclays, HSBC, Lloyds Banking Group, NatWest, Nationwide, Santander) and challenger banks (Monzo, Revolut, Starling), alongside PISPs including TrueLayer, GoCardless, and Yapily — formed the UK Payments Initiative (UKPI) as a new payment scheme, and it went live on 2 June 2026: the UK's first new payment scheme since Faster Payments launched in 2008 (Open Banking Expo, June 2026). This is a genuine milestone, not a pilot.

The catch is scope. UKPI's Wave 1 covers only five sector categories: energy, utilities and telecoms; regulated financial services; e-money institutions; local and central government; and registered charities (Open Banking Expo, June 2026). Early production clients cited by TrueLayer under its "Bank on File" cVRP product include IG Group, InvestEngine, Trading 212, and East Lothian Housing Association — all financial-services or government-adjacent, not general subscription merchants. Wave 1 does not cover SaaS subscriptions, streaming, retail subscriptions, or general e-commerce. That's Wave 2, and as of August 2026 it has not launched — industry trackers and UK Finance's own commercial-model proposal put it at "second half of 2026," with no confirmed date (UK Finance; multiple industry trackers, 2026).

On pricing, UKPI published a Wave 1 commercial model in July 2026: a 5.5p access fee paid by the PISP to the customer's bank per successful transaction, plus a 2.5p scheme fee shared equally between banks and PISPs — roughly 8p in wholesale cost per transaction before any PISP markup to the merchant (industry sources citing UKPI's published framework, July 2026). This superseded an earlier proposed range of 3–11p per transaction floated in 2025. Separately, the FCA and PSR confirmed in January 2026 that they would not, at that stage, prioritise a Competition Act investigation into UKPI's centralised Wave 1 pricing model — a decision that applies only through the current implementation period and doesn't rule out future scrutiny (A&O Shearman restating the FCA/PSR joint statement, January 2026).

For operators: if your business falls inside Wave 1's five sectors, commercial VRP is live today and worth evaluating through a PISP partner. If you're a general subscription or e-commerce operator — the audience this article is mostly written for — commercial VRP isn't accessible yet. The realistic move is to track Wave 2's launch rather than build against Wave 1 eligibility you don't have.

Consent Architecture: How VRP Actually Works

Understanding VRP's technical architecture is necessary to assess integration complexity.

A VRP operates under a VRP Consent — a standing authorization the customer grants that specifies:

• Maximum single payment amount (e.g., up to £500 per transaction)
• Maximum periodic amount (e.g., up to £2,000 per month)
• Valid from / valid to (consent expiry date)
• Payee details (the merchant's account details)

The consent is established once, requires Strong Customer Authentication (SCA), and is stored at the customer's bank. Subsequent payments within the consent parameters can be initiated by the PISP without re-authentication.

This architecture is more flexible than direct debit (fixed amounts, fixed dates) but requires more work than card-on-file to implement. Specifically:

Consent management: Operators must store and track active consents, detect when consents expire or are revoked, and trigger re-consent flows gracefully. A customer who cancels their bank's VRP consent doesn't go through a merchant-side cancellation — they do it in their banking app, and the operator learns about it when the next payment attempt returns a consent-revoked error.

Variable amount handling: The "variable" in VRP is both the feature and the challenge. If a customer grants consent for "up to £200/month" and an invoice comes in at £210, the payment fails. Operators running usage-based billing, overage charges, or plan upgrades need to build consent limit management — notifying customers when charges are approaching their consent limit and triggering re-consent before the limit is breached, not after.

Irrevocability: Like Faster Payments generally, VRP payments are irrevocable. A payment that goes through cannot be recalled by the operator — refunds require a separate payment back to the customer. This changes the merchant's exposure profile versus card payments where chargebacks provide a forced reversal mechanism.

EU Framework: PSD2, PSD3, and What's Changing

The EU does not have a direct equivalent of UK VRP under PSD2. Recurring payment authorization under PSD2 is done differently — through Strong Customer Authentication at initial consent, with exemptions for subsequent transactions based on merchant-initiated transaction (MIT) flows or low-value SCA exemptions.

PSD3 and its companion regulation, the Payment Services Regulation (PSR), were proposed by the European Commission in June 2023. The European Parliament and Council reached provisional political agreement on 27 November 2025, the Council published final compromise texts on 23 April 2026, and the Parliament's ECON committee approved the agreed text on 5 May 2026 (European Parliament Legislative Train Schedule, accessed August 2026). As of this writing, PSD3/PSR have not yet had their formal Parliament plenary and Council adoption votes, and have not been published in the EU's Official Journal — publication had originally been targeted for the end of Q2 2026 but multiple industry trackers now put it later in H2 2026 (Norton Rose Fulbright; DLA Piper, industry legal analyses, 2026). Once published, the PSR — a directly applicable regulation — is expected to apply roughly 18 months after entry into force for most obligations, with a 24-month runway specifically for the new payee-verification and liability rules; PSD3 gives member states 18 months to transpose into national law (Norton Rose Fulbright, industry analysis, 2026). Realistic full application: not before the second half of 2027, and plausibly 2028 if the schedule slips further.

Once in force, PSD3 is expected to strengthen recurring payment frameworks in several ways:

• Explicit recurring payment authorization: clearer rules for recurring payment consents, modeled partly on UK VRP architecture — the payer grants a standing authorization with specified parameters; the payee can initiate within those parameters.
• Dedicated-interface API requirements with uptime SLAs, and removal of the screen-scraping fallback PSPs currently rely on when bank APIs fail — addressing the implementation-quality problems that plagued PSD2, where banks created technical barriers to API access.
• Reduced SCA friction for recurring transactions: clearer exemption frameworks for low-value and recognized recurring transactions.

The practical gap for operators: PSD3's recurring payment provisions won't be operational across major EU markets until 2027 at the earliest. Until then, EU operators running recurring payment flows via open banking are working under PSD2's more limited framework, with variable implementation quality across EU banks. One relevant piece of the baseline is already live, though: since 9 October 2025, euro-area PSPs must run Verification of Payee name checks on every SEPA credit transfer, a check that PISP-initiated payments inherit.

EU open banking maturity for recurring use cases is uneven. Sweden and Finland have the most production-grade infrastructure, with PISPs like Tink (Sweden, acquired by Visa) and Neonomics integrated against bank APIs that work; Klarna also operates an open banking product. The Netherlands runs on iDEAL for one-off payments, with iDEAL 2.0 and SEPA Request-to-Pay framing the recurring story (iDEAL itself is a single-payment scheme, not a native VRP equivalent). Germany leans on SEPA Direct Debit, which already covers most recurring use cases at low cost; open banking PIS adoption there has been slower because direct debit works. Southern and Eastern Europe are early-stage and patchy.

What Operators Need to Build

For UK operators considering VRP for subscription or platform payment flows:

Step 1: Check whether you're actually eligible yet. Commercial VRP is live, but only for UKPI's Wave 1 sectors — utilities, financial services, government, and charities. A general SaaS, media, or retail subscription business is not eligible until Wave 2 launches. Don't build a routing decision tree around bank coverage; build it around scheme eligibility first, then bank coverage within your PISP partner's network once Wave 2 opens.

Step 2: Line up a PISP partner now, even if you can't transact yet. The PISPs active in UKPI include TrueLayer, GoCardless, Token.io, and Yapily, alongside Plaid on UK open banking more broadly. Confirming integration readiness ahead of Wave 2 shortens the gap between launch and your first live transaction.

Step 3: Build consent lifecycle management. Your backend needs to track consent status per customer, handle consent-revoked payment errors with retry logic, manage consent expiry (trigger re-consent before expiry, not after failed charge), and handle partial consent limit situations (amount above single-payment limit → card fallback or consent upgrade request).

Step 4: Model the VRP economics against the published wholesale pricing. UKPI's Wave 1 commercial model sets a 5.5p access fee (PISP to bank) plus a 2.5p scheme fee — roughly 8p in wholesale cost per successful transaction, before whatever markup your PISP applies to reach a merchant price. Against a 1.5–3% card MDR, that flat-fee structure favors higher-value, higher-frequency recurring charges; at very low transaction values, a percentage-based card fee can still come out lower in absolute terms. Model your specific transaction-value distribution once Wave 2 pricing is published — it may differ from Wave 1's.

Step 5: Maintain card as the universal fallback. VRP does not replace card acceptance — it routes eligible customers away from cards when VRP is available and cost-effective. Operators who remove card acceptance to push VRP adoption face coverage gaps and customer friction.

What This Means for Operators

VRP's value proposition is real, and the UK has now proven it can ship a new payment scheme. But the live part doesn't yet cover the use case this article is mostly about — that's Wave 2, still pending with no confirmed date. EU implementation is further behind: PSD3/PSR haven't cleared a full adoption vote or Official Journal publication, with realistic application not before 2027.

The useful move now is preparation, not integration: line up a PISP partner, confirm eligibility the moment Wave 2 opens, and model the wholesale pricing UKPI has already published. For primarily EU customer bases, track PSD3/PSR's path through the Official Journal rather than building against a date that keeps moving.

The structural advantage of VRP over direct debit — variable amounts without re-authorization — makes it the superior technical solution for usage-based billing and any flow where charge amounts change month to month. That case doesn't change based on scheme timing. What changes is when you can actually build against it.