Variable Recurring Payments: AI-Ready Controls for 2026

AI in Payments & Fintech Infrastructure••By 3L3C

FCA support for commercial VRPs signals wider adoption. Here’s how AI improves VRP security, fraud detection, and routing as variable payments scale.

Variable Recurring PaymentsOpen BankingPayments RiskFraud DetectionTransaction RoutingPayment Infrastructure
Share:

Featured image for Variable Recurring Payments: AI-Ready Controls for 2026

Variable Recurring Payments: AI-Ready Controls for 2026

A lot of payment fraud doesn’t start with a dramatic breach. It starts with a legitimate payment permission that quietly gets abused over time.

That’s why the FCA’s support for a new commercial scheme for variable recurring payments (VRPs) matters. VRPs let a customer pre-authorise payments that can vary in amount and timing within agreed rules—more flexible than fixed direct debits, and potentially faster and more programmable than many card-on-file setups. For merchants and fintechs, it’s a big infrastructure moment.

But VRPs also create a new operational reality: permissions become the product. And permissions at scale need continuous monitoring, strong controls, and better decisioning than rule-based systems usually deliver. This is exactly where AI in payments and fintech infrastructure earns its keep—fraud detection, transaction routing, and risk controls that adapt as behaviour changes.

What FCA support signals about where VRPs are heading

FCA support is a clear signal: VRPs are moving from “interesting experiment” to commercially viable payment rail, especially for UK account-to-account payments.

Two things are happening at once:

  1. Demand is real. Businesses want lower costs than cards for recurring use cases, better customer experience than manual bank transfers, and more flexibility than fixed direct debit instructions.
  2. Governance is catching up. Regulators know that flexible payment authorisations can be safe—if schemes standardise consumer protections, consent flows, and dispute handling.

A commercial VRP scheme is basically an invitation for the market to build predictable standards around:

  • Consent and limits (amount caps, frequency, expiry)
  • Authentication (strong customer authentication where required)
  • Liability models (who eats the loss when things go wrong)
  • Data and auditability (what’s logged, who can prove what)

If you’re building in payments, this matters because it reduces uncertainty. Once governance is clearer, VRPs become easier to sell into enterprise finance teams—and easier to integrate into core payment stacks.

VRPs vs direct debit vs card-on-file (in plain terms)

VRPs sit between familiar models:

  • Direct debit: reliable but often slow to set up, and typically “pull” based with less granular real-time control.
  • Card-on-file: flexible and globally common, but carries interchange costs and higher fraud/chargeback exposure.
  • VRP: customer pre-authorises a set of payment rules; payments can be initiated under that permission with potentially lower cost and faster settlement.

The trade-off is simple: VRPs increase flexibility—and flexibility increases the number of ways things can fail.

Why commercial VRPs raise the bar on security (and why rules won’t be enough)

VRPs shift risk from “is this transaction legit?” to “is this permission being used as intended?” That’s a subtle but important change.

A classic fraud stack is good at one-off anomalies. VRP fraud often looks like:

  • A valid customer authorisation used in unexpected ways (amount drift, frequency drift, merchant drift)
  • Account takeover followed by “legit” payments within the cap
  • Social engineering: user is tricked into approving a mandate that’s technically compliant
  • Mule account routing: funds go to accounts that are syntactically valid but behaviourally suspicious

If your controls are mostly static (thresholds, velocity rules, blocklists), you’ll catch the obvious stuff and miss the profitable stuff.

A VRP system without continuous authorisation monitoring is basically a subscription business for fraudsters.

The new “attack surface” is the mandate lifecycle

Most teams obsess over the payment event. With VRPs, the mandate lifecycle is where the real risk sits:

  1. Creation: is consent informed, unambiguous, and authenticated?
  2. Mutation: can limits be changed, and how is that verified?
  3. Usage: are successive payments consistent with the customer’s expected pattern?
  4. Termination: how quickly can a user revoke, and do all parties respect it?

AI helps because it can score behaviour across the whole lifecycle, not just at payment time.

How AI strengthens VRP fraud detection and risk controls

AI’s best contribution to VRPs isn’t “detect fraud after it happens.” It’s preventing bad outcomes by making permissions and payments context-aware.

Here’s what works in practice.

1) Consent intelligence: scoring the mandate at creation

The first payment under a new VRP isn’t the real start. The real start is the moment a user is asked to approve.

AI models can score mandate creation using features like:

  • Device and session risk (impossible travel, emulator signals)
  • Behavioural biometrics (typing cadence, navigation patterns)
  • Payee reputation and network relationships (shared identifiers across known bad actors)
  • Language signals (phishing-like copy patterns in payee descriptors in certain contexts)

This isn’t about blocking everything. It’s about routing risky mandate creations into stronger authentication or manual review.

2) “Mandate drift” detection: catching abuse that stays under caps

The sneaky VRP abuse pattern is staying technically within limits while diverging from user intent.

AI can learn a customer’s normal usage and detect drift such as:

  • Frequency increases (weekly becomes daily)
  • Amount clustering just below a cap
  • Time-of-day shifts (payments happening at unusual hours)
  • Cross-merchant correlations (same operator using multiple merchant IDs)

A good approach is a hybrid:

  • Unsupervised models to detect novel drift patterns
  • Supervised models trained on confirmed fraud and disputes
  • Policy rules for hard compliance boundaries (e.g., never exceed cap)

3) Smarter step-up: when to re-authenticate without wrecking conversion

Authentication is a blunt instrument. Overuse it and you kill conversion; underuse it and losses climb.

AI enables risk-based step-up:

  • Only step up when the model’s confidence drops
  • Choose the right step-up method (SCA, biometric, out-of-band) for the risk type
  • Learn from outcomes (fraud confirmed, dispute filed, user complaint)

This matters for commercial VRPs because enterprise customers won’t tolerate a “security tax” that makes payment ops slower than cards.

4) Real-time transaction routing for resiliency and cost

VRPs will live inside multi-rail environments: bank rails, cards, local schemes, and sometimes fallback paths when a bank is down.

AI-driven transaction routing optimises for:

  • Authorisation success rate
  • Latency and uptime
  • Cost per successful payment
  • Downstream risk (chargebacks, disputes, customer support load)

In practice, it looks like:

  • Predicting which rail will succeed for this payer, this bank, this time
  • Detecting scheme-level incidents (spikes in failures) and shifting routes automatically
  • Using soft-fallback logic: retry windows, partial payments (if allowed), or customer prompts

The payoff is measurable: fewer failed payments, fewer “please update your payment method” emails, and fewer support tickets.

Commercial VRP use cases that will scale fastest (and what AI should watch)

Commercial schemes don’t succeed because they’re elegant. They succeed because they solve messy operational problems. VRPs are well-positioned for a few high-volume categories.

Sweeping and cash management (SMEs and corporates)

Automated balance sweeping between accounts is a natural VRP fit: variable amounts, triggered by thresholds.

AI watch-outs:

  • Bot-like patterns that mimic treasury ops
  • New beneficiary accounts added right before a sweep
  • Unusual sweep timing around payroll or tax periods

Subscription alternatives for regulated or high-return industries

Some sectors hate chargebacks and card expiry churn. VRPs offer a bank-based alternative.

AI watch-outs:

  • Refund abuse patterns (refund-to-different-account attempts)
  • Dispute precursors (customer service complaints before payment reversal)
  • “Friendly fraud” risk scoring tied to account tenure and behaviour

B2B pay-by-bank for variable invoices

Variable invoices (usage-based billing, overages, utilities) fit VRPs better than fixed mandates.

AI watch-outs:

  • Invoice manipulation attempts (amount changes outside expected bands)
  • Merchant system compromise (sudden shifts across many customers)
  • Outlier spikes at month-end close

Implementation checklist: building AI-ready VRP infrastructure

If you’re a fintech, PSP, bank, or large merchant preparing for commercial VRPs, you don’t need a moonshot. You need boring basics done well.

Data you should capture from day one

  • Mandate metadata: caps, frequency, expiry, payee identifiers
  • Consent event logs: timestamps, auth method, device and session context
  • Payment events: attempts, approvals, failures, retries, reversals
  • Customer outcomes: disputes, refunds, complaints, chargeback equivalents

If you can’t join mandate creation to mandate usage to outcomes, your models will be blind.

Controls you should design before you scale

  1. Permission governance: who can create/modify mandates, and how you verify changes
  2. Real-time risk scoring: at mandate creation and each payment event
  3. Customer visibility: clear dashboards for mandate limits, upcoming payments, and instant revocation
  4. Response playbooks: automated containment when drift is detected (pause, step-up, notify)
  5. Auditability: immutable logs that support complaints handling and regulatory scrutiny

A practical model strategy (what I’d do)

  • Start with rules for compliance boundaries and basic abuse prevention
  • Add anomaly detection to catch unknown patterns
  • Layer supervised models once you have labelled outcomes
  • Continuously test against false positives (VRPs amplify operational friction fast)

People also ask: what changes when VRPs go commercial?

Do VRPs reduce fraud compared to cards? They can, because bank-based rails and strong consent reduce some card-specific fraud. But VRPs introduce permission abuse risks, so fraud doesn’t disappear—it changes shape.

Will VRPs replace direct debit? Not outright. Direct debit has decades of operational maturity. VRPs will take share where flexibility and real-time control matter.

What’s the biggest operational risk for merchants? Disputes and customer confusion. If customers can’t see, manage, and revoke mandates easily, your support costs climb and trust drops.

Where this goes next for AI in payments infrastructure

Commercial VRPs are a strong signal that payment infrastructure is becoming more permissioned, more programmable, and more dependent on real-time decisioning. That’s the broader story in our AI in Payments & Fintech Infrastructure series: modern rails don’t just move money—they manage risk, identity, routing, and reliability at machine speed.

If you’re planning to adopt VRPs, don’t treat AI fraud detection as a bolt-on you’ll add later. Treat it as the operating system for permissions: scoring consent, monitoring mandate drift, and routing transactions based on predicted outcomes.

Want a concrete next step? Map your VRP journey as a lifecycle—creation, usage, mutation, termination—and list exactly what data you’ll need to make automated decisions at each stage. Where you can’t observe, you can’t control.

If commercial VRPs scale in 2026 the way open banking proponents expect, the winners won’t be the teams that “support VRP.” They’ll be the teams that can answer a harder question in real time: is this payment consistent with the customer’s intent, right now?