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. 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 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 2026 is more qualified. UK sweeping VRP is mandated and live at major banks. Commercial VRP — the version operators actually want for subscriptions and platform payments — is not mandated, commercially variable, and only live at a subset of UK banks. The EU’s equivalent framework exists in regulation but is ahead of implementation. This article maps what’s real, what’s delayed, and what operators need to build for.

The UK Framework: Sweeping vs Commercial VRP

The UK’s Payment Systems Regulator (PSR) and Financial Conduct Authority (FCA) have developed VRP under the Open Banking Implementation Entity (OBIE) framework. The mandate distinguishes two categories:

VRPs now account for 16% of all UK open banking transactions as of late 2025, mostly through sweeping use cases (PSR, December 2025). 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. It exists as a capability, not a mandate.

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 unregulated, non-mandated version.

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). The OBIE published 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: The Gap

The PSR and FCA have pursued commercial VRP through an industry-led rather than mandated approach. In 2025, 31 firms formed the UK Payments Initiative (UKPI), a new entity to deliver commercial VRP for “Phase 1” use cases: utilities, financial services, and government payments. The FCA expects the first live Phase 1 commercial VRP payments in Q1 2026, with the FCA and PSR assessing progress toward end-2026 (PSR/FCA, December 2025). A full mandate with broader use case coverage may follow HM Treasury legislation expected in 2026 granting the FCA new open banking rulemaking powers.

The commercial VRP ecosystem in the UK is therefore voluntary. Banks that support commercial VRP do so on their own commercial terms. Current commercial VRP availability:

• NatWest: Live for commercial VRP via selected PISP partners
• HSBC: Limited commercial VRP availability, undergoing expansion
• Lloyds: Commercial VRP pilot with selected use cases
• Barclays: Commercial VRP not publicly available as of Q1 2025

Major UK challenger banks — Monzo, Starling, Revolut — have varying commercial VRP support. Monzo has been among the more developer-friendly banks for open banking capabilities generally, but commercial VRP coverage at challengers matters less given their lower share of primary current accounts.

For operators: Commercial VRP coverage gaps mean that a UK subscription platform cannot currently offer VRP as a universal payment method. At best, they can offer it to customers whose banks support commercial VRP (estimated 40–60% of UK current account holders at CMA9-covered banks, varying by bank and PISP partner) while maintaining card acceptance as the universal fallback.

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, which entered legislative process in 2023 and is expected to be transposed into national law across EU member states by 2026–2027, strengthens recurring payment frameworks in several ways:

• Explicit recurring payment authorization: PSD3 introduces 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.
• Improved payment initiation service provider (PISP) rights: PSD3 strengthens PISP access to bank APIs, 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–2028. 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.

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 in 2026:

Step 1: Define your VRP-eligible customer segment. Given commercial VRP coverage at 40–60% of UK current account holders, build a decision tree: if the customer’s bank supports commercial VRP via your PISP partner, offer VRP at checkout; if not, fall back to card or direct debit. The UX must handle this routing transparently.

Step 2: Choose a PISP partner with commercial VRP coverage. The major open banking PISPs with commercial VRP access in the UK include TrueLayer, Yapily, Plaid (via UK open banking), and Token.io. Coverage varies — ask each for an explicit list of supported banks for commercial VRP specifically, not just open banking payment initiation generally.

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: Price the VRP economics accurately. PISP pricing for commercial VRP is typically £0.05–0.20 per transaction flat versus card MDR of 1.5–3% of transaction value. For a £50 monthly subscription, VRP at £0.15/transaction saves ~£0.60 versus a 1.5% card MDR. Multiply by volume to size the opportunity. At low average transaction values (under £20), the percentage savings are smaller and the operational overhead may not justify VRP-first routing.

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 but the timeline to universal applicability has slipped. The UK mandate for commercial VRP has not landed; EU implementation is 2027+ at the earliest; and bank coverage in both markets is partial.

For operators with high-volume UK recurring payment flows and average transaction values above £30, the economics justify building commercial VRP routing now — the coverage is sufficient to capture material savings on a meaningful subset of transactions. For operators with lower average values or primarily EU customer bases, the near-term priority is monitoring the PSR’s commercial VRP mandate progress and the PSD3 transposition timeline, and building the infrastructure when coverage justifies the integration cost.

The structural advantage of VRP over direct debit — variable amounts without re-authorization — makes it the superior technical solution for usage-based billing, platforms with variable payout schedules, and any flow where charge amounts change month to month. Building toward VRP as a primary rail for these use cases, while maintaining card acceptance for coverage gaps, is the right architecture for operators planning 3–5 years out.