Why Smart Debits exist at all
If you are already familiar with open banking, you may reasonably ask why commercial variable recurring payments (cVRP) are needed at all. After all, we already have:
- Cards on file, widely accepted but expensive and increasingly fragile from a fraud and churn perspective.
- Direct Debit, low-cost and trusted, but slow to set up, inflexible, and poorly suited to modern digital experiences.
- One-off Pay by Bank, efficient but requiring repeated customer action.
Smart Debits sit deliberately in the gap between these models. They are designed to combine:
- the control and real-time nature of account-to-account payments,
- the automation of recurring billing,
- and a consent-led model that reflects how consumers now expect to manage payments.
This is a structural change in how recurring payments can work.
What cVRP actually is (and is not)
At a technical level, cVRP allows a customer to give pre-authorised consent for a third party to initiate payments within defined parameters, rather than for a single fixed amount or a single transaction¹.
Those parameters can include:
- a maximum amount per payment,
- a frequency or cadence,
- a total cap,
- and time limits on the mandate.
Crucially, each payment is still a Pay by Bank transaction, authenticated using strong customer authentication (SCA) at the point of mandate creation, not silently in the background.
What cVRP is not:
- It is not a Direct Debit replacement in its current form.
- It is not “cards on file but cheaper”.
- It is not universally available yet, nor frictionless by default.
Why rollout has taken longer than many expected
From the outside, the delay in commercial rollout can look frustrating. In reality, it reflects the fact that cVRP is a scheme-level change, not just a technical one.
Three factors matter:
1. Commercial alignment
Unlike one-off PIS, recurring payments require agreement on:
- liability allocation,
- dispute handling,
- participant obligations,
- and sustainable economics.
This is why the industry has moved towards a multilateral agreement (MLA) model, rather than bilateral contracts².
2. Scheme governance
To scale safely, cVRP needs:
- a neutral operator,
- standard participation rules,
- consistent onboarding and monitoring.
This is the rationale behind the industry-owned operator, UK Payments Initiative Ltd., now being established, funded by 31 organisations including Wonderful (Asima)².
3. Bank readiness
ASPSPs must support:
- mandate storage and lifecycle management,
- revocation and amendment flows,
- and predictable performance at scale.
That requires changes well beyond exposing another API endpoint.
How Smart Debits compare to existing models
Versus cards on file
Smart Debits offer:
- no PAN storage,
- no credential stuffing risk,
- no expiry or reissue churn,
- materially lower fraud exposure.
They also avoid the escalating operational burden of card scheme compliance and chargeback handling³.
The trade-off is customer education and UX. Consumers understand cards instinctively; Smart Debits must earn that trust through clarity and control.
Versus Direct Debit
Compared to Direct Debit, Smart Debits offer:
- instant setup,
- real-time confirmation,
- granular control for customers,
- better suitability for variable billing.
However, Direct Debit remains:
- extremely well understood,
- supported across almost all banks,
- and embedded in back-office processes.
For many organisations, Smart Debits will co-exist rather than replace Direct Debit - at least in the near term.
The Asima view: infrastructure matters more than feature lists
For Asima clients, the key question is not whether cVRP is interesting, but how it is implemented.
Based on what we see across the ecosystem, there are five considerations that matter far more than marketing claims.
1. Mandate design and auditability
A cVRP mandate is a live object, not a static record.
You should understand:
- how mandates are stored,
- how changes are recorded,
- how revocation propagates,
- and how you evidence consent months later.
This is not optional in regulated environments.
2. Observability and controls
Recurring payments fail in subtle ways:
- partial outages,
- latency spikes,
- bank-specific behaviour.
Infrastructure must provide end-to-end visibility, not just success/failure flags.
3. Scheme alignment
If your provider is not aligned with the industry cVRP scheme, you risk:
- rework,
- incompatible mandate models,
- and commercial dead ends.
Early alignment matters more than short-term speed.
4. Security model
Smart Debits reduce some risks, but introduce others:
- mandate abuse,
- parameter misconfiguration,
- social engineering at consent time.
Suppliers should be explicit about their threat model, not vague.
5. Operational reality
Finally, ask how cVRP integrates with:
- refunds,
- reconciliation,
- customer support,
- and failure scenarios.
Recurring payments are judged in operations, not demos.
Where this leaves Smart Debits today
Smart Debits are no longer theoretical. The regulatory framework is stabilising, commercial models are emerging, and industry-backed infrastructure is forming.
But they are also not yet a default choice.
For larger retailers, platforms and fintechs, the opportunity lies in:
- reducing card dependency,
- improving customer control,
- and building payment models that align with modern expectations.
The risk lies in treating cVRP as “just another payment method”.
cVRP (Smart Debits) procurement checklist
When evaluating a cVRP supplier, focus less on feature claims and more on how the underlying infrastructure behaves in production. The questions below are designed to surface material differences between providers.
| Area |
What to ask |
Why it matters |
| Scheme alignment |
Is the provider aligned with the UK industry cVRP scheme and multilateral agreement (MLA), or operating via bilateral arrangements only? |
Early alignment reduces rework and commercial dead ends as the industry scheme becomes the default route. |
| Mandate structure |
How are mandates defined, stored, versioned and revoked? Is the full lifecycle auditable months or years later? |
Mandates are live authorisations, not static records. Poor lifecycle handling creates regulatory and dispute risk. |
| Consent evidence |
Can the provider evidence SCA, consent parameters and user confirmation at mandate creation? |
In regulated environments, retrospective proof of consent is critical. |
| Parameter controls |
How granular are the limits (amount, frequency, total cap, duration)? Who enforces them and where? |
cVRP’s value lies in controlled variability. Weak parameter enforcement undermines trust and safety. |
| Security model |
What threats has the provider explicitly designed for (mandate abuse, social engineering, replay)? |
cVRP reduces some risks but introduces new ones. Vague answers here are a red flag. |
| Observability |
What telemetry is available across mandate creation, payment initiation, failures and retries? |
Recurring payments fail quietly unless you can see what’s happening end-to-end. |
| ASPSP coverage |
Which banks are supported today, and how is behaviour normalised across them? |
Bank-specific quirks are a major source of operational friction at scale. |
| Performance at scale |
What happens under peak load, partial outages or degraded bank performance? |
cVRP magnifies performance issues because failures repeat over time. |
| Disputes and refunds |
How are disputes handled? What tooling exists for refunds and mandate correction? |
Recurring payments are judged in operations, not demos. |
| Reconciliation |
How are payments reconciled back to mandates and customer accounts? |
Finance teams need clarity, not manual workarounds. |
| Commercial model |
Are fees transparent and scheme-aligned, including operator components? |
Hidden or bespoke pricing complicates future migration and scaling. |
| Exit strategy |
If you change provider, how portable are mandates and data? |
Lock-in risk is real in recurring payments. Plan for it early. |
A practical tip:
If a supplier cannot clearly answer most of these questions without caveats or forward promises, they are likely optimised for pilots rather than production.
Final thought
Smart Debits are best understood not as a feature, but as a new payment primitive. One that sits between cards and Direct Debit, and borrows selectively from both.
For Asima clients, the right question is not “can we enable cVRP?”
It is “what kind of recurring payment infrastructure do we want to build for the next decade?”
That is where the real advantage lies.
¹ FCA. Open banking: a year of progress. December 2025. Link
² Open Banking Limited. Firms agree to fund key activities to deliver the initial phase of commercial VRPs. May 2025. Link
³ UK Finance. Fraud the Facts 2024. Link
