Variable Recurring Payments: Open Banking Payment Initiation API Architecture

A card-on-file charge and a direct debit both rest on the same uncomfortable idea: the merchant holds a credential, and the customer’s protection comes mostly from after-the-fact disputes. Variable recurring payments (VRP) invert that. The customer authenticates once at their own bank, the bank stores a machine-readable mandate with hard limits, and every later payment is checked by the bank against those limits before money moves. The consent is a first-class object with a lifecycle, not a credential that happens to be reusable.

This matters in 2026 because the UK has moved from one VRP flavour to two. Sweeping VRP, which moves money between a person’s own accounts, has been live under a regulatory mandate for years. Commercial VRP, where a merchant or lender is the payee, went live as a scheme in June 2026 according to the sources checked below. Meanwhile the EU is rewriting its rules through PSD3 and the Payment Services Regulation (PSR), which will change what a payment initiation provider must build.

What this covers: the actors and the consent object, the OAuth security profile underneath, a worked limit-check implementation, the payment lifecycle and its failure modes, revocation and webhooks, the fraud and liability model, how VRP compares with cards and direct debit, and the UK and EU regulatory state as verified in October 2026. This is systems analysis, not financial or legal advice.

Context and Background

Open banking payment initiation began as a single-shot pattern. Under PSD2 in the EU and the Open Banking Standard in the UK, a payment initiation service provider (PISP) can ask a customer’s bank, the account servicing payment service provider (ASPSP), to push one payment. The customer authenticates with strong customer authentication (SCA) every time. That is fine for a one-off checkout and useless for a gym membership, a utility bill whose amount changes monthly, or a loan overpayment.

Recurring payment needs historically went to two incumbents. Direct debit, run on Bacs in the UK and SEPA Direct Debit in the euro area, is cheap and scheme-protected, but the payee pulls money with little real-time customer control and a multi-day settlement cycle. Card-on-file, using merchant-initiated transactions on the card networks, offers authorisation and chargebacks but carries interchange and scheme fees and relies on tokens the issuer cannot see in context. VRP is a third mechanism: account to account payments over faster payment rails, authorised against a mandate the bank itself enforces.

The UK specification is published by Open Banking Limited (OBL) in its Read/Write API standard. The VRP usage examples show the consent, funds-confirmation and payment endpoints that the rest of this article builds on. The commercial layer is newer. According to the Open Banking Tracker guide on commercial VRP, the UK Payments Initiative (UKPI) Wave 1 went live on 2 June 2026, described there as the first new UK payment scheme since Faster Payments in 2008, with 31 funders from banks, card networks and open banking fintechs. A Lewis Silkin note dated 11 June 2026 cites the FCA as saying VRPs account for around 16 percent of open banking payments. That figure is dominated by sweeping VRP, so do not read it as commercial adoption.

Readers who have followed our coverage of payment reliability will recognise the shape of the problem. Any system that issues repeated pushes against one mandate must survive retries without double-charging, which we cover in depth in payment API idempotency keys and exactly-once retries. And any push-payment rail inherits the scam problem described in authorised push payment fraud and confirmation of payee.

The thesis of this article: VRP is best understood not as “recurring payments over open banking” but as a distributed authorisation system. The bank is the policy decision point, the PISP is the policy enforcement client, and the consent object is the policy. Once you read it that way, the API surface, the security profile and the failure modes all follow.

The Reference Architecture: Bank as Policy Engine, PISP as Client

In a VRP system the customer grants a long-lived consent once, at the bank, with explicit limits on amount, period and validity. The PISP then submits individual payment instructions against that consent without the customer present. The bank validates every instruction against the stored limits, runs its own fraud checks, and executes over a payment rail such as UK Faster Payments or SEPA Instant. The customer can revoke the consent at the bank or the PISP at any time.

Figure 1: Actors and flows in a VRP deployment. The consent is created once with the customer present; every later payment is an off-session call checked against it.

The diagram shows five parties. The payee, a merchant or lender, has a commercial relationship with the PISP or acts as the PISP itself. The PISP holds a regulatory authorisation and a client identity with each bank. The ASPSP exposes the consent and payment APIs, owns the customer authentication step and operates the limit-enforcement logic. A payment rail carries the money. The customer touches only the first leg, the consent journey, and the later notification and revocation channels.

Actors and trust boundaries

Two trust boundaries matter. The first is between the PISP and the bank: the PISP authenticates as an OAuth client, and in the UK also signs requests with a JSON Web Signature, visible in the x-jws-signature header of the OBL examples. The second is between the customer and the bank: only the bank sees the customer’s credentials, which is the whole point of the model and what distinguishes it from screen scraping. The PISP never learns the customer’s banking password and cannot widen the limits by itself, because the limits live in a consent the bank authenticated.

This produces a useful asymmetry. A compromised PISP can do damage only inside the envelope of each live consent: at most the per-payment maximum, at most the periodic cap, only until the validity end. A compromised card-on-file merchant database, by contrast, exposes credentials that are usable for any amount the issuer’s risk engine will tolerate. Bounded blast radius is the strongest architectural argument for VRP.

The UK specification expresses the policy in ControlParameters. From the OBL usage examples, the fields include VRPType, PSUAuthenticationMethods, PSUInteractionTypes (for example OffSession), ValidFromDateTime, ValidToDateTime, MaximumIndividualAmount and an array of PeriodicLimits, each carrying an amount, currency, PeriodType such as Week, and a PeriodAlignment such as Consent. The Initiation block may carry debtor and creditor accounts, or be empty if the customer picks the debit account during authorisation. Status values in the examples include AWAU (awaiting authorisation) and AUTH (authorised).

Think of these fields as a small policy language with four dimensions: who can pay (accounts), how much per payment, how much per window, and for how long. A merchant that wants a utility bill collection sets the per-payment cap above the largest plausible bill, the weekly or monthly cap near twice the average bill, and a validity of a year or more. A savings app sets the cap by the customer’s chosen top-up size. The design pressure is to keep caps tight enough to bound harm but loose enough that legitimate variation does not cause failures, a tension that returns in the trade-offs section.

Sweeping versus commercial VRP

Sweeping VRP restricts the payee to an account in the customer’s own name. According to the Open Banking Tracker guide, it has been live since 2022 to 2023 under a competition authority order and is free to the payer. Commercial VRP lifts the own-account restriction so the payee can be a business, and it comes with a scheme rulebook. The same guide describes UKPI as providing a single rulebook, operational standards and a shared commercial model, with a centrally managed per-transaction price intended to replace bilateral bank deals. It also notes that no headline fee was public at launch; any per-transaction figure you see quoted is a cost estimate, not a tariff. I could not verify the scheme’s dispute and liability rules from the pages fetched, and the Lewis Silkin note says only that safeguards and dispute processes are intended to be built in from the outset.

An engineering consequence follows. Sweeping VRP needs only that the debtor and creditor accounts belong to the same person, which the bank can check itself. Commercial VRP must additionally convey the payee’s identity, purpose and the risk context, which is why the Risk block (payment context code, purpose codes, beneficiary indicators) matters more there and why scheme rules, not just API schema, decide what a compliant request looks like.

Every VRP API call rides on an OAuth 2.0 authorisation, and for financial-grade deployments that means the Financial-grade API (FAPI) profiles from the OpenID Foundation. The FAPI 2.0 Security Profile reached Final status in February 2025. A caveat on scope: the UK ecosystem was built on the earlier FAPI 1.0 Advanced profile, and I did not verify which UK banks have migrated to FAPI 2.0, so treat the following as the target design, not a statement about any specific bank.

The requirements are precise, and I checked them against the final specification. Authorisation servers must require pushed authorisation requests (PAR, RFC 9126) with client authentication, and must reject authorisation requests that do not use PAR. They must require PKCE with the S256 method. They must issue only sender-constrained access tokens, using either mutual TLS (RFC 8705) or DPoP (RFC 9449). Clients must be confidential and authenticate with mutual TLS or private_key_jwt. Authorisation codes live at most 60 seconds, request_uri values expire in under 600 seconds, and JWTs use PS256, ES256 or EdDSA, never none.

Figure 2: The consent journey and the later off-session payment path. The customer is present only for the first half.

Why each control exists for VRP specifically

PAR moves the request parameters off the browser. In a VRP flow the parameters include the payment limits themselves, so a tampered front-channel request could widen a mandate. By pushing the consent identifier through an authenticated back channel and sending the browser only a request_uri, the bank closes that window. Sender-constrained tokens matter because a VRP token is long-lived relative to a one-off payment token; if a bearer token leaks from a log, a replay would be accepted. Binding it to a key (mTLS certificate or DPoP key) makes the stolen string useless.

One detail deserves attention. The profile says authorisation servers should not use refresh token rotation except in extraordinary circumstances, and clients must still support it. The profile also notes in its token-lifetime guidance that short access tokens combined with refresh tokens narrow the attack window and let clients rotate sender-constraining keys without losing the grant. For a PISP that holds a consent for months, this means two independent lifetimes: the OAuth grant, which authorises API access, and the consent object, which authorises money movement. Do not conflate them. An expired access token is routine; an expired or revoked consent ends the business relationship.

In the UK flow, the PISP first creates the consent resource with a POST /domestic-vrp-consents, sending control parameters, optional initiation details and risk data. The bank returns a consent identifier and a status; the examples show AWAU when the debit account is not yet chosen and AUTH in the scenario where the PISP named it. The PISP then redirects the customer to the bank, referencing the consent through PAR. The customer authenticates with SCA, reviews limits, picks an account if needed, and approves. After the redirect back, the PISP exchanges the code for a token and can GET the consent to confirm that the stored parameters match what it asked for.

That last check is not ceremony. Banks may display and store the consent in a form that differs from the request, for instance by rounding validity or dropping an unsupported field. A production PISP should diff the returned ControlParameters against the intended policy and refuse to activate a mandate that is looser than requested, and flag one that is tighter, since a tighter cap will cause later declines.

Deeper Analysis: Limit Checks, Payment Lifecycle and Idempotency

Every instruction submitted via POST /domestic-vrps carries the consent identifier, an instructed amount, the creditor details, and in the OBL examples headers including x-idempotency-key, x-jws-signature and x-fapi-interaction-id. The bank must decide, synchronously, whether the instruction lies inside the mandate. The logic is simple enough to model exactly, and writing it down clarifies what PISPs should pre-check to avoid wasting calls.

The following Python models the UK-style control parameters and evaluates a payment against them. Field names follow the OBL examples; the evaluation logic is my own illustration of how an ASPSP or a PISP pre-check could behave, not any bank’s actual implementation. Period handling is simplified to a rolling window from consent creation; the specification also supports other alignments, and I have not verified exact bank behaviour for calendar alignment.

from datetime import datetime, timedelta, timezone
from decimal import Decimal

consent = {
    "ConsentId": "vrp-consent-001",
    "Status": "AUTH",
    "ControlParameters": {
        "VRPType": ["UK.OBIE.VRPType.Sweeping"],
        "PSUInteractionTypes": ["OffSession"],
        "ValidFromDateTime": "2026-11-01T00:00:00+00:00",
        "ValidToDateTime": "2027-11-01T00:00:00+00:00",
        "MaximumIndividualAmount": {"Amount": "250.00", "Currency": "GBP"},
        "PeriodicLimits": [
            {"Amount": "400.00", "Currency": "GBP",
             "PeriodType": "Month", "PeriodAlignment": "Consent"}
        ],
    },
}

PERIOD_DAYS = {"Day": 1, "Week": 7, "Fortnight": 14, "Month": 30, "Year": 365}  # illustrative

def check(consent, amount, ccy, now, history):
    """history: list of (timestamp, Decimal amount) already accepted."""
    if consent["Status"] != "AUTH":
        return False, "CONSENT_NOT_AUTHORISED"
    cp = consent["ControlParameters"]
    start = datetime.fromisoformat(cp["ValidFromDateTime"])
    end = datetime.fromisoformat(cp["ValidToDateTime"])
    if not (start <= now <= end):
        return False, "OUTSIDE_VALIDITY"
    amount = Decimal(amount)
    cap = cp["MaximumIndividualAmount"]
    if ccy != cap["Currency"] or amount > Decimal(cap["Amount"]):
        return False, "ABOVE_INDIVIDUAL_MAX"
    for lim in cp["PeriodicLimits"]:
        days = PERIOD_DAYS[lim["PeriodType"]]
        # consent-aligned window: whole periods since validity start
        n = (now - start).days // days
        w_start = start + timedelta(days=n * days)
        used = sum(a for t, a in history if t >= w_start)
        if used + amount > Decimal(lim["Amount"]):
            return False, "PERIODIC_LIMIT_EXCEEDED"
    return True, "OK"

now = datetime(2026, 11, 20, tzinfo=timezone.utc)
hist = [(datetime(2026, 11, 3, tzinfo=timezone.utc), Decimal("180.00")),
        (datetime(2026, 11, 12, tzinfo=timezone.utc), Decimal("150.00"))]
print(check(consent, "80.00", "GBP", now, hist))   # (False, 'PERIODIC_LIMIT_EXCEEDED')
print(check(consent, "60.00", "GBP", datetime(2026, 12, 5, tzinfo=timezone.utc), hist))  # (True, 'OK')

Worked numbers (illustrative): with a 250 pound per-payment cap and a 400 pound monthly cap, the history of 180 and 150 pounds has used 330 pounds of the first 30-day block that began on 1 November. An 80 pound request on 20 November would reach 410 pounds and is declined as a periodic-limit breach, even though it is far below the per-payment cap. A 60 pound request would reach 390 pounds and pass. The same 60 pound request on 5 December falls into a fresh block and passes. The lesson: window boundaries and alignment decide outcomes at the margin, so a PISP should pre-check against its own ledger and still treat the bank’s answer as authoritative.

Funds confirmation and the payment state machine

Before sending a payment the PISP may call POST /domestic-vrp-consents/{ConsentId}/funds-confirmation with the consent identifier, a reference and the instructed amount. The OBL example response returns a FundsAvailableResult with FundsAvailable set to Available. This answers a single question, “could this amount be paid now?”, without exposing the balance. It is a hint, not a reservation: money can leave the account between the confirmation and the payment, so a positive answer reduces declines but never guarantees settlement.

Figure 3: Payment and consent states. Payment status is separate from consent status, and a payment can be pending long after the HTTP call returned.

The examples show a payment created in RCVD in one scenario and PDNG with a status reason code in another, which tells you not to assume a single terminal state on the first response. A robust PISP models at least four payment states (received, pending, accepted or settled, rejected) and three consent states (awaiting authorisation, authorised, and revoked or expired). Poll or subscribe for the payment status, and never treat an HTTP 201 as proof of settlement. Open banking payments over instant rails settle quickly, but the status can lag, and a PDNG payment is a liability on your books until it resolves.

Idempotency: the retry problem is worse off-session

Recurring pushes are submitted by a scheduler, not a person staring at a spinner. When a call times out, the scheduler will retry, and without protection a retry can send the money twice. The OBL examples carry an x-idempotency-key header precisely for this. The pattern is covered in detail in our piece on idempotency keys and exactly-once retries; the VRP-specific advice is to derive the key deterministically from the business event, for example a hash of consent identifier, billing period and invoice number, so that a crashed and restarted scheduler regenerates the same key rather than minting a fresh one.

Two further subtleties. First, idempotency windows differ by bank, and the specification does not guarantee indefinite replay protection; after the window passes, a retry with the same key may be treated as new. Mitigate this by reconciling the status of any ambiguous payment, by lookup, before resubmitting. Second, the bank’s own limit accounting must count a payment once. If a bank implementation increments the periodic counter before the idempotency check, a retried request could consume headroom twice. I have not verified how any specific bank orders these steps, so a test that replays the same key against a sandbox and watches remaining headroom is worth writing.

Revocation, expiry and event handling

A consent can end four ways: the customer revokes it at the bank, the customer or merchant revokes it at the PISP, the validity end passes, or the bank withdraws it for risk or account reasons. The first is the dangerous one for the PISP, because the PISP may learn of it only when the next payment fails. Treat any rejection that signals an invalid or revoked consent as terminal for that mandate and stop retrying, since repeated attempts against a dead consent are noise at best and a monitoring alert at worst.

Where banks offer change notifications, use them; where they do not, design for discovery by failure. I could not verify a universal standard for push events on VRP consent revocation across UK banks, so do not build a design that depends on one. A defensible approach is a periodic GET of each active consent just before the billing run, which costs one cheap call and converts a surprise decline into a planned customer message. Pair this with a notification path to the customer the day before an expected variable amount, since a mandate that allows variable payments leaves the customer the least warning of exactly the thing that varies.

In the EU, PSD3 and PSR add a customer-facing permission dashboard. Per a Worldline summary of the political deal, customers will be able to view and revoke data-access permissions. That is a data-access dashboard, and I have not verified that it will cover payment mandates, so for payments assume revocation routes remain primarily at the bank and PISP.

VRP Versus Card-on-File and Direct Debit

The choice among recurring mechanisms is a set of trade-offs, not a ranking. The table below is qualitative; costs vary by contract and I have deliberately not quoted fees I could not verify.

Dimension	VRP	Direct debit	Card-on-file (MIT)
Customer authentication	SCA once, at consent	At mandate setup	At first payment
Limits enforced by	Payer’s bank, in the mandate	Mostly the payee’s own rules	Issuer risk engine, no explicit mandate
Variable amounts	Native, within caps	Allowed, with advance notice rules	Allowed
Settlement speed	Rail dependent, can be near instant	Multi-day cycle	Authorisation instant, settlement later
Dispute route	Scheme rules, still being established for commercial VRP	Established scheme guarantee	Chargeback
Cost to payee	Per-transaction scheme and provider fee; central price at UKPI, not public at launch	Low	Interchange and scheme fees
Failure on insufficient funds	Declined at once	Failed after submission, with delay	Declined at once
Credential leak impact	Bounded by consent limits	Account details exposed	Token or card number reusable

The row that changes system design most is dispute route. Chargebacks are a mature, well-understood remedy, which is why merchants and consumers both trust cards. Commercial VRP aims to replace that safety net with scheme-level dispute processes, and the sources I checked say only that such processes are intended to be built in. Until those rules are published and tested, treat VRP as strong on prevention (hard limits, SCA, bank-side checks) and unproven on cure.

Fraud and liability

Prevention is genuinely stronger. The bank sees every payment and can apply its own fraud models, and the PISP cannot exceed the mandate. But new attack paths appear. The consent journey is a social-engineering target: a scammer who convinces a customer to authorise a high-cap mandate to an attacker-controlled merchant has obtained an authorised, SCA-protected, legitimate-looking instrument. This is authorised push payment fraud in a recurring costume, and the defences in our article on APP fraud detection and confirmation of payee apply at consent time: payee-name checks, merchant vetting, and friction proportional to cap size.

Figure 4: Where fraud controls sit. Consent-time checks are the cheapest place to stop a bad mandate; payment-time checks catch drift; monitoring catches patterns across mandates.

On liability the EU picture is moving. Taylor Wessing, summarising the 27 November 2025 provisional agreement, reports that a PSP lacking suitable anti-fraud mechanisms is liable for customer losses, that PSPs must fully refund spoofing-fraud victims who report to police and their PSP, that online platforms may owe PSPs that reimburse victims if they fail to remove notified fraudulent content, and that PSPs must check a payee’s name against the identifier. These are regulation-level rules for payment services in general, not VRP-specific, and the final legal text and dates should be checked before relying on them. In the UK, I did not verify how the commercial VRP scheme allocates liability between bank, PISP and merchant, which is the single most important open question for a merchant signing up.

Regulatory state, October 2026

UK: sweeping VRP is live; commercial VRP Wave 1 went live on 2 June 2026, with Wave 2 (open e-commerce) expected in the second half of 2026 per the Open Banking Tracker page, which gave no firm date. Wave 1 use cases listed there are utilities, telecoms and rail, regulated financial services, e-money institutions, government and registered charities. The regulators’ stated target was about 75 percent of UK current-account coverage at launch; the achieved figure was not reported in the sources I could read. Lewis Silkin reports the FCA intends to consult on a longer-term open banking regulatory framework by the end of 2026, subject to legislation. On 20 January 2026, per the tracker, the FCA and PSR said they would not, at this stage, prioritise a Competition Act investigation into the centralised pricing model.

EU: the Council and Parliament announced a provisional agreement on PSD3 and the PSR on 27 November 2025. Worldline’s summary says publication in the Official Journal was expected in the first half of 2026 and that PSD3 transposition should land around Q2 or Q3 2028; it also contained internally inconsistent statements about the PSR transition, so confirm timelines against the Official Journal text. Notably for payment initiation, the same summary says the obligation on banks to offer a dedicated interface for third parties is removed, API reliability and non-discrimination rules are reinforced, and SCA exemptions become more risk-based. I did not find an EU-wide equivalent of the UK VRP specification in the sources checked (unverified as a negative claim), so assume EU recurring account-to-account flows depend on national or scheme-level API standards and bank-specific PSD2 implementations.

Trade-offs, Gotchas, and What Goes Wrong

Cap design is a product decision with fraud consequences. A cap set to the largest plausible bill avoids declines but raises the cost of a malicious mandate; a tight cap protects the customer but turns a seasonal spike into a failed payment and a support call. Use per-merchant defaults informed by billing history, and revisit them by re-consenting rather than by asking customers to approve a vague, very large ceiling.

Coverage gaps shape architecture. A PISP cannot assume every customer’s bank supports commercial VRP. Regulators targeted about 75 percent current-account coverage at launch, which implies one in four accounts may not be reachable at first. You need a fallback collection method, typically direct debit or card, and logic to choose between them per customer. Building VRP as the only path is a way to lose revenue.

Status ambiguity. PDNG plus a reason code is a legitimate answer. Systems that treat anything other than a final accepted status as failure will double-collect on retry; systems that treat 201 as success will recognise revenue that never arrives. The fix is an explicit state machine with reconciliation against the bank’s status endpoint, plus a daily comparison of expected and settled amounts.

Window misalignment. Period boundaries tied to the consent date differ from calendar months, and a merchant who bills on the first of the month may find the periodic window rolls over mid-month. Test alignment behaviour in each bank’s sandbox. I have no verified data on how consistently UK banks implement each alignment option, so treat it as a certification item.

Consent drift and silent narrowing. Banks can show different text to the customer than your UI promised. Capture the returned consent object, hash it, and store it with the customer record; it is your evidence of what the customer authorised.

Key and certificate operations. Sender-constrained tokens, signed requests and mTLS mean certificate expiry becomes an availability risk. A certificate that lapses at midnight stops every collection at every bank at once. Automate rotation, alert well before expiry, and keep key identifiers in your token-binding logic so rotation does not invalidate live grants. The FAPI 2.0 profile’s own guidance that refresh tokens allow key rotation without losing the grant is the mechanism to rely on.

Agent-initiated payments are a new stressor. If an AI agent can trigger payments against a standing mandate, the mandate’s caps are your last line of defence against a runaway or manipulated agent. Compare the delegated-credential approaches in our piece on agentic commerce protocols ACP, AP2 and UCP: the principle that authority should be bounded, auditable and revocable is the same, and bank-enforced limits are a stronger bound than any limit the agent platform enforces on itself.

Practical Recommendations

If you are building PISP architecture for variable recurring payments, treat the consent as a versioned, immutable record and everything else as derived state. Keep the intended policy, the bank’s returned policy, and every payment ledger entry linked to the consent identifier. Reconcile daily. Model the bank as an unreliable, slow, authoritative oracle: precheck locally, submit with deterministic idempotency keys, and trust the bank’s verdict.

If you are a merchant or lender choosing a mechanism, use VRP where the amount varies and payer-side control matters (utility bills, savings sweeps, flexible loan repayments), keep direct debit for fixed, high-volume, low-friction collections where cost dominates, and keep cards where chargeback protection is the consumer expectation. Do not decide until you have the dispute and liability terms for your scheme in writing.

Checklist:

Confirm bank coverage and fallback logic before committing volume.
Diff the returned ControlParameters against intended policy on every consent.
Derive idempotency keys from business events, not random values.
Model payment and consent as separate state machines.
Refresh and check consent status before each billing run.
Pin FAPI-style controls: PAR, PKCE S256, sender-constrained tokens, private_key_jwt or mTLS.
Automate certificate and key rotation with expiry alerts.
Notify customers before variable amounts, and give an easy revocation path.
Log the full consent object and signed request for dispute evidence.
Re-verify regulatory dates (UKPI waves, PSD3/PSR publication) before each roadmap cycle.

Frequently Asked Questions

What are variable recurring payments?

Variable recurring payments are a bank-enforced mandate for account-to-account payments. The customer authenticates once at their bank and approves limits on per-payment amount, amount per period and validity. A payment initiation provider can then submit payments of varying amounts without the customer present, and the bank rejects any instruction outside the limits. The customer can revoke the mandate at any time.

How is VRP different from a direct debit?

A direct debit lets the payee pull funds under a mandate, with settlement on a multi-day cycle and customer protection mainly through a scheme guarantee. VRP puts the payer’s bank in the decision path for every payment, with explicit machine-readable limits and, on instant rails, much faster settlement. Direct debit remains cheaper and more established, while VRP offers tighter payer-side control and variable amounts natively.

What is the difference between sweeping and commercial VRP?

Sweeping VRP moves money between accounts in the same person’s name and, per the Open Banking Tracker guide, has been live since 2022 to 2023 under a competition authority order and is free to the payer. Commercial VRP allows businesses, government and charities as payees under the UKPI scheme, whose Wave 1 reportedly went live on 2 June 2026 with a shared rulebook and a centrally managed per-transaction price.

Does VRP exist in the EU?

I did not find an EU-wide VRP specification in the sources checked. The EU framework is PSD2, being replaced by PSD3 and the PSR, for which the Council and Parliament reached a provisional agreement on 27 November 2025. Recurring account-to-account payments there depend on bank APIs and SEPA rails, so confirm what your target banks support and how PSD3 transposition, expected around 2028, will change it.

What security standard do VRP APIs use?

The UK ecosystem uses OAuth 2.0 with the Financial-grade API profiles and signed requests. FAPI 2.0 Security Profile, final since February 2025, requires pushed authorisation requests, PKCE with S256, sender-constrained access tokens through mTLS or DPoP, and confidential clients authenticating with mTLS or private_key_jwt. I did not verify which UK banks have migrated from the earlier FAPI 1.0 Advanced profile.

Who is liable if a VRP payment is fraudulent?

It depends on the scheme and jurisdiction, and I could not verify the UKPI commercial VRP liability rules. Public sources say only that dispute processes are intended to be built in. In the EU, the provisional PSD3 and PSR deal makes PSPs without suitable anti-fraud mechanisms liable and requires full refunds for reported spoofing fraud. Get liability allocation in writing before onboarding.

Variable Recurring Payments (VRP) and Open Banking Payment Initiation: API Architecture (2026)

Variable Recurring Payments: Open Banking Payment Initiation API Architecture

Context and Background