Programmable payments move money under rules agreed in advance, with explicit consent. The payer sets the conditions once (how much, how often, to whom, and for how long), and each payment then runs automatically whenever those conditions are met, with no one needing to authorise it at the time.
The term is used in several different ways. Crypto firms use it for payments controlled by smart contracts on a blockchain, banks use it for treasury payments on tokenised deposits, and European central bankers now call the same idea "conditional payments". In this guide, we explain what programmable payments are, how they work, and how open banking already delivers them in the UK through commercial variable recurring payments (cVRP).
What has pushed programmable payments up the agenda is agentic payments: AI agents paying on a person's behalf. An agent needs permission it can act within, and accurate, up-to-date context to decide from. Programmable payments supply these, with the user setting the limits and keeping control.
This article covers:
what a programmable payment is and how it works
how it differs from programmable money and conditional payments
the main types of programmable payments
how cVRP forms the basis for programmable payments in the UK today
how programmable payments fit into agentic finance
the risks and protections that apply
what still has to happen before payments are fully programmable
Exploring programmable payments for your product? Talk to Yapily.
How do programmable payments work?
Every programmable payment has three parts: the rules, a trigger, and a payment that runs inside the rules.
The rules. These are the pre-defined limits the payer agrees to: an amount per payment, a total over a period, a payee or several payees, and how long the permission lasts.
The trigger. This is the condition that starts a payment. It might be a date, an event such as an invoice being approved, or a signal from the payer's own finances, such as income landing or a balance falling below a threshold. In open banking, those signals come from financial insights: consented, real-time bank data that has been categorised so a rule or an agent can act on it.
The payment. When the trigger fires, the payment runs, as long as it stays inside the rules.
With a Direct Debit or a card on file, the payer gives permission once and the business decides how much to take and when. With a programmable payment, the payer sets the limits each payment must stay within and can withdraw them at any time, so they keep control even though nobody approves each payment as it happens.
Programmable payments vs automated payments
Standing orders and Direct Debits are better thought of as "automated payments", because they run on a schedule or when a business initiates a collection. A standing order sends a fixed amount on dates the payer sets, and a Direct Debit is collected when the business chooses, under an authority the payer gave once. Programmable payments give the payer more control. Each payment has to stay within limits the payer has set, and it can be programmed to trigger on a signal, such as income landing or a balance falling below a threshold, rather than only on a date or at a business's request.
Programmable payments vs programmable money: what's the difference?
Programmable payments put rules on when and whether money moves. Programmable money puts rules inside the currency itself, such as limiting what it can be spent on. You do not need programmable money to make payments programmable: the European Central Bank, for example, supports conditional payments for the digital euro while ruling out programmable money.
Are conditional payments the same as programmable payments?
For most purposes, yes. Conditional payments are the name the European Central Bank and the Euro Retail Payments Board adopted for what were formerly called programmable payments: the ability to instruct a payment automatically when pre-defined conditions are met.
What types of programmable payments are there?
Programmable payments run on three main rails. What differs is where the rules run, what money moves, and who enforces the limits.
Payment method | Where the rules run | Money that moves | Who enforces the limits | Where it is live |
|---|---|---|---|---|
Open banking | A mandate held with the payer's bank | Money in ordinary bank accounts | The payer's own bank | UK cVRP, live since June 2026 |
Smart contracts and stablecoins | Code on a blockchain | Stablecoins or other tokens | The smart contract | Public and private blockchains |
Tokenised bank deposits | A bank's programmable ledger | Commercial bank money | The bank running the ledger | Corporate treasury, such as J.P. Morgan's Kinexys |
Open banking. The payer gives consent through their own bank, which holds the mandate and enforces the limits on every payment. The same connection can also supply the bank data that triggers a payment. In the UK, this already runs through cVRP today.
Smart contracts and stablecoins. Code on a blockchain holds the rules and releases tokens when a condition is met, such as confirmed delivery. The Bank for International Settlements has argued that stablecoins fall short as money and that tokenisation belongs inside the regulated banking system.
Tokenised bank deposits. Banks run the rules on their own programmable ledgers, settling in commercial bank money. J.P. Morgan's Kinexys is in live use for corporate treasury: Siemens has tested it, and Saudi National Bank went live in February 2025.
How open banking enables programmable payments through cVRP
In the UK, commercial variable recurring payments (cVRP) are the foundation for programmable payments today. The mandate is the programmable part: the customer gives consent once, sets the rules, and every payment after that runs inside them. cVRP is a UK scheme, so everything in this section applies to the UK only. For a fuller explanation of the product itself, read our guide to commercial variable recurring payments.
How a cVRP mandate works
The customer sets the rules once, and each payment that falls inside them goes through without the need for a fresh approval. A mandate works in four steps:
The customer sets the maximum for each payment, the maximum over a period, and how long the mandate lasts.
They authenticate once, in their banking app.
The business initiates each payment when it is due, and the customer's bank checks it against those limits and checks that funds are available before any money moves.
The customer can cancel the mandate at any time.
What cVRP covers today
cVRP has been live in the UK since 2 June 2026, when the UK Payments Initiative (UKPI) launched what Open Banking Tracker describes as the UK's first new payment scheme since Faster Payments in 2008. Wave 1 covers energy and utilities, telecoms, regulated financial services, government, and charities. That already suits variable bills, regular investment contributions, and loan repayments, where the amount changes from month to month but the customer wants to stay in control of their limits. It also builds on rails people already use.
Why bank-enforced limits matter
With cVRP, the limits sit with the customer's bank. The bank checks each payment against them before any money moves, so the customer does not have to rely on the business to stay within what they agreed. Strong customer authentication happens at the bank when the mandate is set up, and the customer can withdraw the mandate instantly, whenever they choose.
How do programmable payments fit into agentic finance?
Agentic payments, where an AI agent pays on a customer's behalf, are the main use case driving programmable payments today. An agent needs two things from the financial system: a payment method it is allowed to use within set limits, and an accurate picture of the customer's finances to decide from. Open banking can supply both.
Agents need permission they can act within
A cVRP mandate gives an agent bounded authority. The customer authenticates with their bank once and sets the limits, and the agent can then pay within them without asking each time. That gives an agent a controlled way to initiate payments: the customer's bank enforces the limits before any money moves, no card details change hands, and the customer can withdraw the mandate whenever they choose. It also matches what people say they want. In a June 2026 YouGov survey for ACI Worldwide, 43% of UK adults said they would trust AI to follow spending limits, while 70% said purchases made without asking would affect their willingness to use an AI shopping agent.
Financial insights supply the signals
Before an agent pays, it needs to know whether the customer can afford it, when they are paid, and what they have already committed to. Financial insights answer those questions from consented, real-time bank data that has been categorised and enriched. Used together, the two capabilities give agentic payments both the context and the mechanism they need:
Financial insights provide the context. They tell the agent whether a payment is affordable, when it makes sense, and how it fits the customer's existing commitments.
Programmable payments provide the mechanism. The agent pays within limits the customer has set, and the customer's bank enforces them.
Why open banking is a strong foundation for agentic payments
Open banking provides the context and the payment through the same consent model, with the customer's own bank at the centre of both. That gives an agent trusted data to decide from and a secure way to act on the decision, without the customer handing over card details or losing control of the limits. Limits do not remove every risk, though, as the next section explains. We set out this thinking in more depth in programmable payments and financial insights: the next stage of open banking.
What are the risks, and what protections apply?
Programmable payments move money without anyone approving each payment, but what happens when something goes wrong? Protections differ by payment method, and newer methods currently have less developed protections than the ones people know from cards and Direct Debits.
Payment method | Who enforces the limits | Can a payment be reversed? | How disputes are handled | Main gaps |
cVRP (open banking) | The customer's bank checks each payment against the mandate before money moves | Payments move over Faster Payments, so there is no card-style chargeback | Through the UKPI scheme rulebook and the payment providers involved | Purchase protection for e-commerce is still being agreed for Wave 2 |
Cards | The card issuer, under card scheme rules | Yes, through a chargeback raised with the card issuer | Card scheme rules | The rules were written for a person at the checkout, not an agent |
Direct Debit | No limit set by the payer: the business decides the amount and date, with advance notice | Yes, a full and immediate refund for payments taken in error, under the Direct Debit Guarantee | The payer's own bank | The Guarantee does not settle disputes with the business over the goods or service itself |
Smart contracts and stablecoins | Code in the contract or wallet, or a provider's own rules | No built-in way to reverse a blockchain payment | Depends on the provider's terms, if there is a provider | No settled answer yet on who is liable when something goes wrong |
Tokenised bank deposits | The bank running the ledger | Depends on the bank's agreements with its clients | Agreed contractually between the bank and its corporate clients | Built for corporate treasury, so consumer protections do not apply |
cVRP's protections reflect where the scheme is today. Wave 1 was limited to sectors whose existing consumer protections fit the scheme's dispute framework, and the UKPI participants are still agreeing a consumer protection model for Wave 2, including how it compares with the protections cards offer.
Why the risks matter more when AI agents pay
An agent payment can go wrong in three ways. The agent might spend more than the customer authorised, it might stay within its limits and still make a poor decision, such as buying the wrong item or accepting a bad price, or it might be manipulated or compromised by someone else. Those risks need addressing before agents are trusted to spend at scale, so that mistaken payments stay rare.
cVRP is a strong starting point, because the mandate limits are already in place: the customer's bank stops any payment above them before money moves, which deals with the first risk. Limits do not help with the other two, because in both cases the agent stays within what it was allowed to spend. Nothing in a cVRP payment yet marks it as agent-initiated, and the rules on who covers the loss when an agent gets it wrong are still to be settled for Wave 2. Until they are, keeping limits tight and asking the customer to confirm larger or unusual payments are sensible safeguards.
What still has to happen before payments are fully programmable?
Three things stand between today's cVRP and fully agentic-ready programmable payments: coverage for e-commerce, consent that works across multiple merchants, and a way to recognise payments that an AI agent initiates. Our VP of Payments sets out the case for each in his article on cVRP Wave 2 and agent-ready checkout.
E-commerce in Wave 2
Wave 2, which brings e-commerce into scope, is expected in 2027. It depends on HM Treasury laying a statutory instrument under the Data (Use and Access) Act 2025, and the FCA plans to consult on a long-term framework for open banking, which regulators describe as the foundation for expanding cVRP into e-commerce. Once e-commerce is in scope, cVRP can support subscriptions, digital goods, and one-click checkout, so a returning customer can pay a merchant they already hold a mandate with without authenticating again.
Consent that works across merchants
A cVRP mandate today covers one customer and one merchant. That works well for a utility bill, but it does not fit someone who wants a service to manage a whole category of spending, such as groceries, within one budget. The next milestone is consent that lets a customer authorise payments across several merchants, within limits they set.
Payments that AI agents initiate
A mandate already gives an agent permission to act, but nothing in a cVRP payment yet marks it as agent-initiated, so neither the bank nor the customer can later see which purchases an agent made.
The wider market is moving towards the same model. Google's Agent Payments Protocol (AP2), announced in September 2025, uses signed mandates to record what a customer has authorised an agent to buy. Early examples are already appearing, such as the agentic booking prototype Yugo built on open banking.
How Yapily is building towards programmable payments
Agentic payments need two things from open banking: a secure way for an agent to pay, and trusted data to decide from. Yapily brings both together, which puts us in a strong position to help you build agentic payment capabilities. We set out the thinking in programmable payments and financial insights: the next stage of open banking.
Payments and data through one integration
An agent needs trusted data to decide from and a secure way to pay, and Yapily provides both through one integration, under the same consent model. The context behind a decision and the payment that follows come from the same source.
Programmable payments, including cVRP (UK only)
Financial insights from consented, real-time bank data
Over 2,000 bank connections across 19 countries
A founding role in the UK's cVRP scheme
If you build on cVRP, you need the scheme to develop in the direction your product is heading. Yapily is one of the 31 founding organisations behind UKPI, the industry body that operates the cVRP scheme, which gives us direct input into how it develops beyond Wave 1.
Categorised and enriched bank data to set triggers on
A trigger such as "income has landed" relies on transactions being identified correctly. Data Plus turns raw transactions into signals an agent or a payment rule can act on, such as regular income or a recurring commitment.
45 incoming and 150 outgoing categories
Coverage of both consumer and business accounts
Models built on data from more than 100 million merchants
Documentation built for agents
More product teams now build with coding agents, so integration documentation has to work for an agent as well as a developer. Yapily Docs is available as plain text and as an installable Agent Skill, so an agent can look up endpoints, request parameters, and integration guidance while your team builds.
Getting started with programmable payments
Programmable payments are already live in the UK through cVRP, and they give AI agents a controlled way to pay on people's behalf. What they can do will widen as Wave 2 arrives and consent for agents develops. If you are working out where they could fit in your product, talk to a payments expert at Yapily, or see how Yapily Commercial VRP works.
FAQs
Are standing orders and Direct Debits programmable payments?
Not in the full sense. Standing orders and Direct Debits are automated payments: a standing order sends a fixed amount on a schedule the payer sets, and a Direct Debit lets a business collect under an authority the payer gave once. A programmable payment also checks a limit or condition the payer has set before each payment runs.
Is programmable money the same as programmable payments?
No. Programmable money carries rules inside the currency itself, such as limits on what it can be spent on. Programmable payments put rules on when and whether money moves, and they work with the ordinary money in a bank account. The European Central Bank, for example, supports conditional payments for the digital euro but has said the digital euro will not be programmable money.
Is cVRP a programmable payment?
Yes. Commercial variable recurring payments (cVRP) are the foundation for programmable payments in UK open banking. The customer sets limits on a mandate once, authenticates with their bank, and each payment inside those limits runs without a fresh approval. cVRP has been live in the UK since June 2026 for Wave 1 sectors and is not available outside the UK.
Who sets the rules for a programmable payment, and can they be cancelled?
The payer sets the rules. With cVRP, the customer agrees the maximum per payment, the maximum per period, and how long the mandate lasts, and their own bank checks every payment against those limits. The customer can cancel the mandate at any time.
What protections apply if a programmable payment goes wrong?
It depends on the rail. With cVRP, the customer's bank checks each payment against the mandate limits before money moves, and disputes go through the UKPI scheme rulebook rather than card-style chargebacks, with purchase protection for e-commerce still being agreed for Wave 2. Blockchain payments have no built-in way to be reversed, so any protection depends on the provider.
What are some examples of programmable payments?
Examples include variable utility bills and loan repayments collected under a cVRP mandate in the UK, regular investment contributions, corporate treasury payments that trigger automatically on tokenised bank deposits, and smart contracts that release a stablecoin payment once delivery is confirmed.
How will AI agents use programmable payments?
An AI agent can use financial insights from the customer's bank data to decide what to do, then pay inside a mandate the customer has already authorised, without asking each time. Today a cVRP mandate covers a single merchant, so the next steps are consent that spans several merchants and a way to mark payments as agent-initiated.
When will cVRP be available for e-commerce in the UK?
Wave 2 of cVRP, which brings e-commerce into scope, is expected in 2027. It depends on new legislation from HM Treasury and on UKPI's scheme rules, and once live it can support subscriptions, digital goods, and one-click checkout.
Sources
Bank for International Settlements, Anchoring trust in money: innovation beyond stablecoins, Annual Economic Report 2026
European Central Bank, Inputs from ERPB: conditional payments
J.P. Morgan, Programmable payments: automation becomes reality
J.P. Morgan, Kinexys in the MENA region
Open Banking Tracker, Commercial VRP & UKPI
Open Banking Limited, monthly open banking payments
Financial Conduct Authority, statement on the UK Payments Initiative scheme launch
UK Finance, Open Banking payments: industry proposal for a commercial model for Wave 2 cVRP
Worldline, Agent Payments Protocol (AP2) documentation
Business Wire, YouGov survey for ACI Worldwide, June 2026