Open Banking

44.0 What this chapter gives you#

1. You will be able to explain why open banking is not a payment system, and name the rail that actually carried the £340.
2. You will be able to say what a payment initiation service provider may and may not do, and why only the account holder can authorise money to move.
3. You will be able to price an open banking payment against a card payment and say why the saving grows with the average transaction value rather than staying constant.
4. You will be able to tell a merchant exactly what they gain and what their customer gives up when a checkout moves from cards to pay-by-bank.
5. You will be able to distinguish the Payment Services Regulations 2017 from the CMA’s Retail Banking Market Investigation Order 2017, and say which binds every bank and which produced the specification and binds nine.
6. You will be able to explain why “open banking works with your bank” is a claim about one institution on one day, and build a coverage matrix instead of relying on a principle.
7. You will be able to describe a variable recurring payment’s control parameters and say why sweeping is free at the point of use and commercial VRP is not.
8. You will be able to state what the ninety-day rule now requires and why most published explanations of it are out of date.
9. You will be able to trace a payment initiation from consent creation to a terminal status, and say why building a checkout that waits for one is a mistake.
10. You will be able to explain what regulation 79 does, why its application to commercial VRP is unsettled, and why the Direct Debit Guarantee is the standard VRP will be judged against.

At twenty past nine on a Wednesday evening, a woman in Bristol pays a quarterly energy bill of £340. She is on the supplier’s website. Next to the card fields there is a button that says “Pay by bank”. She presses it, picks her bank from a list of logos, and her phone opens her banking app. The app shows her three lines: the amount, £340.00, the name of the energy supplier, and the account the money will leave. She holds her thumb to the sensor. The app closes, the supplier’s page refreshes, and the bill is marked paid. The whole thing takes about eleven seconds. The supplier has the money, finally and completely, before she has put her phone down.

At two o’clock the following morning, while she is asleep, £85 moves out of her current account and into a savings account she holds with a different firm. She set this up seven months ago and has not thought about it since. It happens because the balance in her current account crossed a threshold she chose. No standing order was involved. No direct debit was involved. Nobody at either institution touched anything.

Both of those movements used the same machinery, and the machinery has a name that misleads almost everybody who hears it. It is called open banking, and the most important thing to understand about it is a negative: it is not a payment system. No money moves through it. It is a way of asking a bank to do something the bank could already do, and of asking in a form the bank is legally obliged to answer. The £340 travelled down the Faster Payments Service, the same pipe that has carried British instant retail payments since 2008. The £85 travelled down it too. Open banking supplied the instruction and the permission. It did not supply the road.

That distinction sounds pedantic. It is in fact the source of nearly every important consequence in this chapter, including the one that matters most to anyone building a business on it, which is what happens when the customer wants their money back.

All figures, dates, versions and limits in this chapter are accurate at the time of writing, August 2026. This is the fastest-moving area in the entire book. The commercial arrangement that makes open banking payments viable for ordinary businesses went live ten weeks before this was written, the legal framework that will govern the whole thing from the late 2020s has not yet been made, and the body that will run the standard does not yet exist. Check every date below against a primary source before you rely on it.

The plain version#

Think of your bank as a large office building with a counter at the front. You go to the counter, you prove who you are, and the clerk does things for you: shows you your statements, moves your money.

Now suppose you want somebody to help you. Maybe an app that adds up all your accounts across four different banks and tells you what you actually spend on food. Maybe a shop that wants to be paid without the faff of you typing an account number off an invoice.

Before 2018, there was only one way to let a helper do either of those jobs. You gave them your keys. You told the app your online banking username and password, and it logged in pretending to be you, walked around inside your account, and copied down what it found. This was, and this is not too strong a word, a disaster. Your bank could not tell the helper apart from a thief, because there was nothing to tell apart: they were using the same credentials in the same way. If something went wrong nobody could say whose fault it was. And it broke every time the bank redesigned its login page.

Open banking replaced the keys with two service hatches cut into the wall of the building, and a rule that the bank has to keep them open.

Through the first hatch, a helper who holds a reader’s pass can ask for a copy of your statements. Not your password, not the ability to move anything, just the numbers: balances, transactions, standing orders, the name on the account. That reader’s pass is a real licence, issued by the financial regulator, and the helper’s name goes on a public list.

Through the second hatch, a helper who holds a form-filler’s pass can hand in a payment instruction on your behalf. And here is the part that carries all the weight: the form-filler cannot sign the form. They fill in the payee, the amount, the reference. Then they hand it back to you, and you walk to the counter yourself and sign it, with your own thumbprint or your own passcode, in your own bank’s app. The bank checks the signature, not the form-filler’s word. Then the bank pays.

That is the whole idea. Two hatches, a list of who is allowed to knock, and a hard rule that only the account holder can authorise money to move.

What it costs, and who it costs#

Here is why a business cares, using the £340 energy bill.

If our Bristol customer had paid by debit card, a slice of that £340 would have gone to the bank that issued her card. That slice is capped by law at 0.2 per cent for a consumer debit card, which is 68 pence. If she had used a credit card the cap is 0.3 per cent, which is £1.02. Those caps only cover one slice; the card network takes a fee and the supplier’s own payment provider takes a margin, and the all-in cost is meaningfully higher than the cap.

The key thing is not that the number is big. The key thing is that it is a percentage. Doubling the bill doubles the fee. A business collecting £3,400 pays ten times what a business collecting £340 pays, for exactly the same amount of work.

An open banking payment is not priced that way. The form-filler charges the business a fee per payment, quoted in pence, and it does not move when the amount moves. Collecting £3,400 costs the same as collecting £34. For a business with large average transaction values, an energy supplier, a letting agent, an investment platform, a car dealer, that is not a discount. That is a different order of magnitude.

The second difference is timing. The card payment showed up as approved instantly, but the supplier would not actually have the cash for a day or two. The open banking payment went over Faster Payments, which runs every hour of every day including Christmas morning, and the money was in the supplier’s account in seconds. On a Wednesday evening. Which is when people pay bills.

The third difference is the one nobody puts on the marketing page. With the card, the supplier’s money can be taken back off them, months later, if the customer complains to her bank and the bank agrees. With the open banking payment, it cannot. Once a Faster Payment has gone, it has gone. If the customer wants a refund, the supplier has to choose to send her one.

That is the trade, in one sentence: the merchant gets the money faster, cheaper and for keeps, and the customer gives up the right to reach back and take it.

Standing orders that can change their mind#

The £85 that moved at two in the morning is the other half of open banking, and it has a clumsy name: a variable recurring payment, or VRP.

A standing order is a fixed instruction: £85 on the 3rd of every month, until I say stop. It cannot adapt. A direct debit is the opposite: the company you are paying decides the amount, and tells your bank to take it. That is flexible, but you have handed the steering wheel to somebody else.

A VRP sits between the two. You sign one form, once, that says something like: this named helper may take money from my account, but never more than £200 in a single payment, never more than £600 in a calendar month, only to this one named destination, and only until 5 April next year. After that, the helper can make payments inside those walls without waking you up, and cannot make one that steps outside them by a penny. Your bank enforces the walls, not the helper.

Right now the overwhelming majority of live VRPs do one job, and it has a name too: sweeping. Sweeping means moving your own money between your own accounts. Current account into savings when the balance goes above a threshold. Savings into current account when the balance goes below one, so you do not slide into an overdraft. Spare cash into an account that repays a loan early. The nine largest British banks were required to build sweeping, and they have all built it.

The interesting frontier, and it is only just open, is letting a VRP pay somebody else: your energy company, your council, a charity, a subscription. That is called commercial VRP, and it went live in Britain on 2 June 2026 under a new industry scheme. It is the first serious attempt to build something that does the direct debit’s job without the direct debit’s three-day cycle and without the direct debit’s paper-era limitations.

How big is this#

Those are Open Banking Limited’s own published figures. In mid-2026 the ecosystem passed one billion open banking payments and one hundred billion requests since it started in 2018.

For scale: 31 million open banking payments were made in March 2025, which Open Banking Limited put at roughly one in every thirteen Faster Payments. So it is real, it is growing quickly, and it is still a minority of a minority of how Britain moves money.

The one-line summary#

Open banking is a set of doors cut into the wall of your bank, a licensed list of who may knock, a rule that the bank must answer, and an absolute requirement that only you can authorise money to leave. Everything behind the door is the old plumbing.

Where the plain version stops being true#

The hatch is not the same size at every bank#

The plain version says “the bank has to keep the hatch open”, and that is true, but it hides that two entirely different pieces of law are doing two entirely different jobs, and they cover different institutions.

The first is the Payment Services Regulations 2017, which apply to every account servicing payment service provider in the country. They require access. They say almost nothing about what that access looks like. Regulation 69 says a bank must communicate securely with a payment initiation service provider and treat its payment orders exactly as it treats orders coming direct from the customer. Regulation 70 says the same for account information. Neither regulation specifies a data format, a field name, an uptime target, or a response time.

The second is the Competition and Markets Authority’s Retail Banking Market Investigation Order 2017, made under the Enterprise Act 2002. That is where the actual specification came from, and it binds nine institutions: Barclays, HSBC, Lloyds Banking Group, Nationwide, NatWest Group, Santander, Danske Bank, Bank of Ireland and Allied Irish Bank. Those nine, universally called the CMA9, were required to fund and implement a common standard against a published roadmap, and to submit to monitoring.

Everybody else built whatever they liked, or built to the standard voluntarily, or built something that technically satisfies the regulation and is miserable to integrate with. Sweeping VRP was mandated on the CMA9 alone. So the sentence “open banking works with your bank” is a claim about one specific institution on one specific day, not a claim about the United Kingdom. Anyone building a product needs a coverage matrix, not a principle.

There is not one consent, there are at least two, and they drift#

The plain version has you signing one form. In reality two separate permissions exist, they are held by two different parties, they have different lifetimes, and cancelling one does not reliably cancel the other.

The first is the consent you give the third party. That is a contractual and data-protection permission: you told this app it may look at your accounts, for these purposes, for this long.

The second is the authorisation you give your bank. That is a strong customer authentication event which produces an access token and a refresh token, held by the third party, scoped to a consent resource that lives on the bank’s servers.

They come apart routinely. Delete the app from your phone and the tokens keep working. Cancel in the app and the bank may still show a live consent in its “connected services” screen. Cancel at the bank and the app’s next call fails, but the app may not tell you why.

The famous ninety-day rule has also changed, and most explanations of it are now wrong. Originally the bank had to re-authenticate you every ninety days for data access to continue, which meant a monthly-budgeting app dragged you through your bank’s login four times a year for every bank you had connected. The Financial Conduct Authority changed this in policy statement PS21/19, adding a new Article 10A to the UK version of the technical standards. Since 26 March 2022, the obligation is a reconfirmation of consent that the account information provider obtains from you, at least every ninety days, rather than a re-authentication the bank performs. The FCA expected banks to adopt the exemption by 30 September 2022. The friction moved from the bank’s app to the third party’s app, which was the point. The ninety days did not go away.

The money arrives instantly, but that is not the same as knowing it arrived#

The plain version says the supplier has the money in seconds. Usually true. What is not true is that the supplier’s software has been told so with certainty.

A payment initiation service provider does not receive a settlement confirmation from Pay.UK. It receives a status from the bank about the payment order, which is a different object in a different system. Statuses lag, sometimes by minutes, and a number of banks stop at an intermediate status and never emit the terminal one. Building a checkout that waits for final confirmation before releasing goods is a good way to build a checkout that hangs.

The limits are similarly misleading. The Faster Payments scheme maximum is £1 million per transaction, and you will almost never meet it. Individual banks set their own lower ceilings, and the ceiling applied to payments initiated through open banking is frequently lower than the ceiling the same bank applies inside its own app for the same customer. Some banks step the limit by authentication method, some by account age, some by whether the payee is already known. Never size a product against the scheme limit. Size it against the worst bank on your coverage matrix, and find out what that number is by testing rather than by asking.

And “instant” has a legal floor rather than a legal guarantee. Pay.UK’s own description is that payments between direct participants normally arrive almost immediately but can occasionally take up to two hours, with the statutory backstop being end of the following business day.

It is not a cheaper card, and treating it as one is expensive#

This is the correction that costs real money.

A card payment is a pull with a dispute system bolted to it. Two dispute systems, in fact. Chargeback is a set of private rules written by the card schemes: the customer complains, the issuer reverses the transaction, the merchant has to defend it. It is not law, and it exists because the schemes decided it should. On top of that, for credit cards, section 75 of the Consumer Credit Act 1974 makes the card issuer jointly and severally liable with the retailer for breach of contract or misrepresentation, where the cash price of the item is over £100 and no more than £30,000. Section 75A extends a narrower right above that.

An open banking payment is a push with neither. There is no chargeback, because there is no scheme sitting between the parties writing dispute rules. There is no section 75, because there is no credit agreement. A refund is a brand new payment, in the opposite direction, that the merchant elects to send.

The statutory refund right that does exist, regulation 76 of the Payment Services Regulations 2017, requires a payment service provider to refund an unauthorised transaction and restore the account, by the end of the business day following the day it becomes aware. But an open banking payment that the customer approved with strong customer authentication is, by definition and by design, authorised. The regulation is not available for a sofa that never arrived.

The authorised push payment reimbursement regime, live since 7 October 2024, is also not the answer. It covers being deceived into sending money to a criminal, up to £85,000 per claim, with the cost shared equally between the sending and receiving firms. It does not cover a merchant dispute. A supplier who took your money and then went quiet is a civil matter, not a scam claim.

So the honest framing is that open banking payments are a bank transfer with a good user interface, and they carry exactly the protections of a bank transfer, which is to say almost none beyond the fraud regime. That is fine, and often better than fine, for paying your own energy bill or moving your own money. It is a materially worse deal for the consumer than a credit card when buying a mattress from a company they have never heard of. Any business presenting the two side by side and describing them as equivalent is misrepresenting the product.

The technical version#

Two legal instruments, one ecosystem#

UK open banking sits on two foundations that are frequently conflated.

The Payment Services Regulations 2017 (SI 2017/752) transposed the second Payment Services Directive, Directive (EU) 2015/2366, and came into force on 13 January 2018. The relevant provisions:

• Regulation 68, confirmation of availability of funds, for card-based payment instrument issuers.
• Regulation 69, access to payment accounts for payment initiation services. The ASPSP must communicate securely with the PISP and treat its payment orders identically to orders received directly from the payer. The PISP must not hold the payer’s funds at any time, must not store sensitive payment data, and must not alter the amount, the payee or any other feature of the transaction.
• Regulation 70, access to payment accounts for account information services. The AISP must have the user’s explicit consent, must identify itself in every communication session, and must access only the designated accounts and their associated transactions.
• Regulation 71, limits on the use of payment instruments and access to payment accounts. An ASPSP may deny a TPP access for reasonably justified and duly evidenced reasons relating to unauthorised or fraudulent access, but must notify the customer, report the incident to the FCA, and restore access once the justification lapses.
• Regulation 100, authentication, which imposes strong customer authentication.

The Retail Banking Market Investigation Order 2017, made by the CMA under the Enterprise Act 2002, produced the standard. Article 10.5 of Part 2 provided for an Implementation Trustee to drive delivery against an agreed roadmap. Open Banking Limited, originally the Open Banking Implementation Entity, was established by the CMA9 in October 2016 to do that work. The CMA declared the roadmap substantially complete on 12 January 2023, with six providers finished, and confirmed full completion in September 2024 once Danske Bank, Bank of Ireland and Allied Irish Bank had delivered their remaining obligations, including sweeping VRP.

The forward-looking picture is different again. The Joint Regulatory Oversight Committee has been wound up and replaced by a department inside the FCA, which is now lead regulator. HM Treasury is expected to legislate under the Data (Use and Access) Act 2025, whose Part 1 provides for smart data schemes, to give the FCA rulemaking powers over open banking. The FCA set out its expectations for a successor to Open Banking Limited, called the Future Entity, in Feedback Statement FS25/4 (August 2025), and wrote to trade associations on 19 December 2025, published 16 January 2026, inviting industry to coalesce behind a candidate body and offering an independent consultant-led assessment. The FCA expects the Future Entity and commercial scheme operators to be regulated as interface bodies under the DUAA, and intends to consult on the long-term regulatory framework by the end of 2026.

The role taxonomy#

A firm providing account information services only may be a registered account information service provider, a lighter regulatory status. Payment initiation requires full authorisation as a payment institution, or the firm must already be a credit institution or e-money institution, and it must hold professional indemnity insurance or a comparable guarantee. In practice a large proportion of merchants do not hold either permission and reach the rails through a regulated PISP acting as their provider, or as an agent.

Identity in the ecosystem is managed through the Open Banking Directory. Participants enrol, obtain certificates, and publish software statements. Third parties obtain a Software Statement Assertion signed by Open Banking, which can be used for dynamic client registration at each ASPSP’s authorisation server, avoiding a manual onboarding per bank.

Certificates deserve a paragraph because Brexit changed them. Article 34 of the SCA-RTS originally required eIDAS qualified certificates: a QWAC for transport, a QSeal for signing. UK TPPs’ eIDAS certificates were revoked at the end of the transition period. The UK version of the RTS was amended to permit alternatives, and the Open Banking Certificate Authority issues ETSI-profile equivalents: OBWAC for website authentication and OBSeal for electronic seals. EEA TPPs accessing UK ASPSPs may still present QWACs and QSeals, which can be uploaded to the Directory.

As at June 2026 the Directory carried 327 regulated providers: 88 account providers and 239 third party providers, of which 143 regulated entities had at least one proposition live with customers.

The security profile#

The current specification is the Open Banking Standard, currently v4.0.1. Version 4.0 was published on 28 June 2024 and was the first major release since 2018, developed with over forty ecosystem participants.

Its headline change was the security uplift from FAPI 1.0 Implementer’s Draft 2 to FAPI 1.0 Advanced Final, made mandatory, with the earlier profile deprecated at the end of 2024. Version 4.0 also aligned message content with ISO 20022, including the fields required for Bank of England CHAPS compliance from 1 May 2025, centralised the codeset repository, and improved payment status reporting and error messaging.

The concrete requirements a practitioner will implement:

Transport. TLS 1.2 with mutual authentication. The client presents its transport certificate; the ASPSP validates it against the Directory.

Client authentication. private_key_jwt. The TPP signs a JWT assertion with its private key; the ASPSP validates against the registered public key. Shared secrets are not used.

Authorisation. OAuth 2.0 and OpenID Connect. The specification supports the authorisation code grant and identifies the hybrid grant as the preferred redirect mechanism under the FAPI profile. Authorisation parameters are packaged in a signed JWT request object, which prevents tampering during the redirect.

Intent model. Rather than relying on coarse OAuth scopes, the standard uses dedicated consent resources: account-access-consent, domestic-payment-consent, domestic-vrp-consent and their siblings. An access token binds to exactly one PSU and one intent.

Message signing. Detached JWS per RFC 7515 Appendix F, algorithm PS256, carried in the x-jws-signature header. The JOSE header carries critical claims http://openbanking.org.uk/iat, http://openbanking.org.uk/iss and http://openbanking.org.uk/tan, the last identifying the trust anchor domain. This gives non-repudiation independently of the TLS session. Message encryption via JWE is optional.

Correlation headers. x-fapi-interaction-id, an RFC 4122 UUID that the ASPSP must echo in its response, is the single most useful field in the entire specification when you are on the phone to a bank’s support desk about a failed payment. x-fapi-auth-date carries the time of the PSU’s last login with the TPP. x-fapi-customer-ip-address carries the PSU’s IP when the PSU is present, and its absence signals an unattended call.

Idempotency. POST endpoints that create resources take x-idempotency-key, maximum 40 characters. The ASPSP must treat an identical key from the same TPP within 24 hours as a duplicate. The TPP must not modify the request body while reusing a key, and must leave at least one second between a submission and its retry.

Authentication models. The redirect model sends the PSU to the ASPSP’s authorisation endpoint, in practice app-to-app on mobile, and back again. The decoupled model uses CIBA, Client Initiated Backchannel Authentication: the TPP initiates, the PSU authenticates on a separate device or channel, and the TPP polls. Decoupled matters for call centres, in-branch journeys and any flow where the PSU is not holding the device that displays the merchant.

A payment initiation, step by step#

1. The PISP POSTs to /domestic-payment-consents with the payee, amount, currency, reference and, optionally, the debtor account. The ASPSP returns a ConsentId. Nothing has been authorised and no money has moved.
2. The PISP constructs a signed request object carrying the ConsentId as an intent claim and redirects the PSU to the ASPSP’s authorisation endpoint.
3. The ASPSP authenticates the PSU with strong customer authentication. If the debtor account was not specified, the PSU selects it here. The ASPSP plays the consent back to the PSU: amount, payee, reference. The PSU accepts or rejects.
4. The consent resource transitions to authorised. The ASPSP returns an authorisation code to the PISP’s redirect URI. The PISP exchanges it at the token endpoint for an access token scoped to that consent.
5. The PISP POSTs to /domestic-payments, referencing the ConsentId, with a request body that must match the consented payment exactly.
6. The ASPSP submits the payment to a clearing system. For a domestic single immediate payment in sterling this is, in practice, almost always Faster Payments.
7. The PISP polls GET /domestic-payments/{DomesticPaymentId} for status.

Version 4.0 aligned payment order statuses to the ISO 20022 external code set. The values a practitioner will encounter include RCVD received, PDNG pending, ACTC accepted technical validation, ACCP accepted customer profile, ACFC accepted fraud checking, ACSP accepted settlement in process, ACWC accepted with change, ACSC accepted settlement completed, ACWP accepted with partial execution, ACCC accepted and closed, BLCK blocked, RJCT rejected, and CANC cancelled for future-dated payments and standing orders.

The specification also supports multi-authorisation for accounts requiring more than one signatory, through the MultiAuthorisation block carrying Status, NumberRequired, NumberReceived, LastUpdateDateTime and ExpirationDateTime, with the PISP able to request an authorisation type of Single or Any and an optional CompletionDateTime. Corporate journeys live or die on this.

There is a RefundAccount structure in the domestic and international payment models, which returns the payer’s account details to the PISP so that a merchant can send a refund. Note carefully what this is: it is an address, so that the merchant can make a new payment. It is not a reversal mechanism.

Strong customer authentication in the consent flow#

Regulation 100 of the PSRs 2017 requires a payment service provider to apply strong customer authentication where a user accesses a payment account online, whether directly or through an AISP; initiates an electronic payment transaction; or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.

Strong customer authentication means two or more elements from independent categories: knowledge, something only the user knows; possession, something only the user has; and inherence, something the user is. Independence means the breach of one does not compromise the others.

Regulation 100(2) adds dynamic linking: where a payer initiates an electronic remote payment transaction, directly or through a PISP, the authentication must include elements which dynamically link the transaction to a specific amount and a specific payee. This is why your bank’s app shows you the amount and the payee name on the approval screen and why a PISP cannot alter either after authorisation. It is also why the payment request body must match the consent.

The exemptions live in the SCA-RTS, originally Commission Delegated Regulation (EU) 2018/389, onshored and now maintained by the FCA as technical standards in the Handbook. The ones that matter here:

Article 10 and Article 10A, account information. Article 10 permitted an ASPSP not to apply SCA where a user accesses balance or transaction data, subject to a ninety-day limit. Article 10A, introduced by PS21/19, removed the periodic re-authentication at the ASPSP for AIS access through a TPP and shifted the obligation onto the AISP to obtain the customer’s explicit reconfirmation of consent at least every ninety days. The FCA strongly encouraged adoption by 30 September 2022.

Article 13, trusted beneficiaries. An ASPSP need not apply SCA where the payee is on a list of trusted beneficiaries previously created by the payer. This is the mechanism that makes VRP work at all.

Article 11, contactless, and Article 16, low value remote, are card-side and rarely relevant to open banking, though the FCA has publicly encouraged continued support for the contactless exemption for charitable donations.

The FCA has also been explicit that firms must develop SCA solutions that work for all groups of consumers, including those without mobile telephones. A journey that assumes app-to-app on a smartphone is not, on its own, an adequate SCA implementation for a whole customer base.

Variable recurring payments#

The VRP API Profile, at v3.1.10 of the read-write specification, defines two resources:

• domestic-vrp-consents, a consent between a PSU and a TPP permitting the TPP to create payments subject to control parameters.
• domestic-vrps, individual payment orders that must fall within those parameters.

The control parameters set the walls. They include the validity window, ValidFromDateTime and ValidToDateTime; a maximum individual amount; and periodic limits, each with an amount, a period type, and a period alignment. The period type enumerations are Day, Week, Fortnight, Month, Half-year and Year, and an ASPSP must support all of them. Period alignment is either Consent, meaning the window starts when the consent was created, or Calendar. ASPSPs may impose additional control parameters, limits and restrictions on non-sweeping VRPs.

The flow is: the TPP POSTs a domestic-vrp-consents resource, the PSU authorises it once with SCA, and thereafter the TPP POSTs domestic-vrps against it without further SCA, provided each payment sits inside the parameters. GET on vrp-details returns funds availability and remaining allowance.

Sweeping is a regulatory category, not a technical one. The CMA approved VRP as the mechanism for implementing sweeping under item A10 of the revised roadmap on 27 July 2021, extended the CMA9 implementation deadline to July 2022 by letter of 15 November 2021, and published a clarification of the definition of sweeping in March 2022. On 3 December 2025 the CMA published a letter responding to an OBL recommendation regarding the sweeping use case of alternative forms of credit that closely compete with overdrafts.

The requirements the CMA9 had to meet for sweeping, as set out in OBL’s standards proposition, are worth listing because they explain the consent screens you actually see:

• The sweeping consent must specify the payee account name, the payee account identification, the maximum cumulative amount per time window, and the maximum amount of each individual sweeping payment.
• The ASPSP must tell the PSU that the payee will be added to their trusted beneficiary list, and must add it once consent setup completes.
• The ASPSP must then apply the trusted beneficiary SCA exemption when the PISP initiates a payment inside the consent parameters, or the transfer-to-self exemption where the destination is at the same ASPSP. It may decline to apply the exemption in exceptional circumstances, taking an objective approach consistent with the proportionality requirements of the PSRs.
• The ASPSP must provide a specific error indicator if the payee has been removed from the trusted beneficiary list and the exemption can no longer be applied.
• The PISP must attest to the ASPSP that the consent is a sweeping consent.
• The ASPSP must provide non-discriminatory access both to sweeping consent setup and to the initiation of sweeping payments.

That last requirement is the reason sweeping is free at the point of use and commercial VRP is not. Non-discriminatory access, in the CMA’s sense, meant the CMA9 could not charge for it.

Commercial VRP and the UK Payments Initiative#

Extending VRP beyond me-to-me sweeping required something the CMA Order did not provide: a commercial model. A bank has no obligation to offer VRP to a merchant and no reason to build the capacity for free.

Under the JROC, the Payment Systems Regulator led work on a commercial model for so-called phase 1 use cases. The FCA took over as lead regulator and continued the work jointly with the PSR, publishing a summary report on development and rollout in December 2025.

In late 2025, 31 firms came together to establish UK Payments Initiative Ltd (UKPI), an independent industry-owned company to own and operate a commercial VRP scheme with its own rulebook, commercial model and operational standards. The FCA described the first live payments under the scheme as the start of a new era for payments and open banking in the UK, and expected them in the first quarter of 2026.

The scheme was announced as launched on 2 June 2026, at Money20/20 Europe in Amsterdam. UKPI’s own announcement names 24 founding shareholders, including Barclays, HSBC, Lloyds Banking Group, NatWest, Nationwide and Santander, alongside Monzo, Revolut, Starling, GoCardless, Plaid, TrueLayer, Yapily and Token.io. The scheme’s first wave covers government payments, utilities, charities and financial services, with subscriptions and wider e-commerce planned to follow. A launch coverage target of around 75 per cent of UK current accounts is quoted consistently in the guidance scheme participants have issued to merchants, and it is the figure the industry has settled on. It is worth being clear about its standing: it does not appear in the FCA’s statement on the launch, nor in the regulators’ correspondence with the CMA, and no public scheme document confirms it, so the number rests on industry restatement rather than on a published primary source.

The commercial model itself required a competition-law answer, because a group of competitors agreeing a central price is exactly the arrangement competition law exists to police. On 15 January 2026 the FCA and the PSR wrote to the CMA setting out their position; on 16 January the CMA confirmed it did not intend to take a different view on prioritisation; and on 20 January 2026 the regulators published a joint statement confirming they would not at this stage prioritise a Competition Act 1998 investigation into UKPI’s centralised access fee model. That forbearance runs until the government’s anticipated legislative framework or July 2027, whichever comes first. The FCA has said it will assess industry-led cVRP growth by the end of 2026 and fold the lessons of the first phase into the long-term framework.

VRPs accounted for roughly 15 to 16 per cent of open banking transaction volume at the time of writing, with sweeping VRP volumes having nearly doubled year on year in 2025.

Why it settles over Faster Payments, and what follows from that#

Nothing in the specification requires Faster Payments. The standard describes a payment order; the ASPSP decides how to execute it. LocalInstrument can carry a scheme preference and some ASPSPs support CHAPS or scheduled Bacs credits for particular payment types.

In practice, the domestic single immediate payment, which is the overwhelming majority of open banking payment volume, executes over the Faster Payments Service, for the obvious reason: it is the only sterling retail rail that clears in seconds, around the clock, seven days a week. Bacs takes three working days on a submission, processing and entry cycle, and is deferred net settlement, which is fine for payroll and useless for a checkout. CHAPS is same-day, irrevocable real-time gross settlement inside the Bank of England’s RTGS system, carrying the large majority of sterling value, with an early-afternoon cut-off for the same-day guarantee, and it is not priced for a £340 energy bill.

Four consequences follow, and they are the practical heart of this chapter.

Irrevocability. Pay.UK’s own description is unambiguous: because of their real-time nature, once sent, Faster Payments cannot be cancelled. There is a Credit Payment Recovery process for misdirected payments, which is a best-efforts request to the receiving institution to return funds it has not yet released, not a right. Confirmation of Payee, launched in 2020, checks the payee name against the account before you send, which prevents some errors and some frauds but changes nothing about finality once the payment has gone.

Limits. The scheme maximum is £1 million per transaction. Individual PSPs set their own lower ceilings, and channel-specific ceilings for open banking are frequently lower still.

No chargeback. There is no scheme adjudication layer, because the scheme is Faster Payments and Faster Payments does not adjudicate merchant disputes. Compare the card world, where chargeback rights are written by the card networks into their operating rules and where section 75 of the Consumer Credit Act 1974 imposes joint and several liability on a credit provider for purchases with a cash price over £100 and up to £30,000.

Refunds are new payments. A merchant refunding an open banking payment initiates a fresh credit transfer to the payer. That is why the specification carries a RefundAccount structure: not to reverse anything, but to tell the merchant where to send the money. Operationally this means refunds need their own payout capability, their own reconciliation, their own fraud controls and their own audit trail, none of which a merchant migrating off cards will have.

The protection map#

The statutory refund provisions in the PSRs are worth stating precisely, because they are routinely misdescribed:

• Regulation 74 requires notification without undue delay and in any event within thirteen months of the debit date, otherwise the redress provisions are unavailable.
• Regulation 76 requires the PSP to refund an unauthorised transaction and restore the account, as soon as practicable and no later than the end of the business day following the day it becomes aware. Where a PISP is liable, regulation 75(2) applies and the PISP must compensate the ASPSP immediately on request.
• Regulation 77 caps the payer’s own liability at £35 for losses from a lost, stolen or misappropriated payment instrument, with the cap disapplied where the payer acted fraudulently or with intent or gross negligence, and with no liability at all where the ASPSP failed to apply SCA that regulation 100 required.
• Regulation 79 gives a refund right for authorised transactions initiated by or through the payee, where the authorisation did not specify the exact amount and the amount exceeded what the payer could reasonably have expected. Regulation 80 requires the request within eight weeks of the debit and a response within ten business days.
• Regulation 95 gives a right of recourse between PSPs where liability is attributable to another provider or intermediary, including for failure to apply SCA.

Regulation 79 is the interesting one for VRP, and the position is genuinely unsettled. Its trigger is a transaction initiated by or through the payee, which is the direct debit shape. A VRP is initiated by a PISP acting for the payer, within limits the payer set, which is a different shape. Whether and how the regulation 79 refund right attaches to a commercial VRP is one of the questions the FCA’s long-term framework will need to answer, and it is the single largest open consumer-protection question in the area. The direct debit’s competitive advantage over VRP is not technical. It is the Direct Debit Guarantee, which promises an immediate refund from your own bank, on request, with no time limit and no argument. VRP as currently specified has no equivalent, and the UKPI rulebook’s treatment of disputes will determine whether it needs one.

What changes next#

Three things are moving, and a chapter written eighteen months from now will read differently.

In the UK, the Data (Use and Access) Act 2025 provides the vehicle. HM Treasury is expected to legislate to give the FCA rulemaking powers over open banking; the FCA intends to consult on the long-term regulatory framework by the end of 2026; and industry is expected to stand up a Future Entity to succeed Open Banking Limited as the primary API standard-setting body, regulated as an interface body under the DUAA. Beyond payments, the same Act provides for smart data schemes in energy, telecoms, transport and retail, which is what “open finance” and eventually “open data” mean in a British context.

In the EU, the successor to PSD2 has landed. The Parliament and Council reached provisional political agreement on PSD3 and the accompanying Payment Services Regulation on 27 November 2025; the Council published final compromise texts on 23 April 2026 following COREPER endorsement on 22 April; the ECON committee approved the agreed text on 5 May 2026. Formal adoption by both institutions was still outstanding at the time of writing. A separate Regulation on a Framework for Financial Data Access, which is the EU’s open finance instrument, remained in trilogue. Among the changes relevant here, the package clarifies that SCA for account information access should be performed by the account provider once, at the outset.

In the rails beneath, the EU’s Instant Payments Regulation has made instant euro transfers universal and price-capped, which removes the main structural reason European open banking payments lagged British ones. Britain’s advantage in this area was always the early availability of a genuinely instant, genuinely ubiquitous retail rail. That advantage is now shared.

The through-line is worth restating, because it is the thing most easily lost. Open banking did not build a payment system. It built a legally mandated, cryptographically enforced way of asking a bank to use the payment system it already had, and a licensed register of who may ask. Everything good about it, the speed, the price, the finality, comes from Faster Payments. Everything difficult about it, the absence of chargeback, the absence of section 75, the fact that a refund is a fresh payment somebody has to choose to make, comes from Faster Payments too. It is the same fact wearing two faces, and any product built on this layer has to be designed for both of them at once.

44.98 Common wrong ideas#

Wrong: open banking is a payment system and money moves through it. Right: it is a legally mandated, cryptographically enforced way of asking a bank to use the payment system it already had, and the money travels down Faster Payments.

Wrong: an open banking payment is a cheaper card payment. Right: it is a push with no chargeback and no section 75, and a refund is a brand new payment in the opposite direction that the merchant elects to send.

Wrong: regulation 76 will get the customer’s money back when the goods never arrive. Right: regulation 76 covers unauthorised transactions, and a payment the customer approved with strong customer authentication is authorised by definition and by design.

Wrong: the authorised push payment reimbursement regime covers a merchant dispute. Right: it covers being deceived into sending money to a criminal, up to £85,000 per claim; a supplier who took the money and went quiet is a civil matter.

Wrong: every bank must keep the hatch open to the same standard. Right: the Payment Services Regulations require access without specifying a data format, an uptime target or a response time, and only the CMA9 were required to implement the common standard and sweeping VRP.

Wrong: deleting the app or cancelling in it ends the connection. Right: there are at least two permissions, held by two different parties with different lifetimes, and they come apart routinely.

Wrong: the ninety-day rule drags a customer through their bank’s login four times a year. Right: since 26 March 2022, Article 10A has made it a reconfirmation of consent that the account information provider obtains, not a re-authentication the bank performs.

Wrong: the Faster Payments scheme maximum of £1 million is the ceiling to build against. Right: individual banks set lower limits, and the limit applied to open-banking-initiated payments is frequently lower than the same bank applies in its own app, so size against the worst bank on the coverage matrix and find the number by testing.

Wrong: an accepted payment status means the money has settled. Right: a PISP receives a status about the payment order from the bank, not a settlement confirmation from Pay.UK, statuses lag, and some banks stop at an intermediate status and never emit the terminal one.

Wrong: the RefundAccount structure is a reversal mechanism. Right: it is an address, returned so that the merchant can make a fresh payment, with its own payout capability, reconciliation, fraud controls and audit trail.

44.99 Chapter summary in 20 lines#

1. Open banking is not a payment system: it is a way of asking a bank to do something it could already do, in a form the bank is legally obliged to answer.
2. Both the £340 energy bill and the £85 overnight sweep travelled down the Faster Payments Service, which open banking did not build and does not own.
3. It replaced shared passwords and screen-scraping with two regulated interfaces: one that reads account data and one that submits a payment order for the customer to authorise.
4. The payment initiation provider fills in the form but never signs it; only the account holder authorises, with strong customer authentication, in their own bank’s app.
5. Two legal instruments underpin the ecosystem: the Payment Services Regulations 2017, which require access from every account provider, and the CMA Order 2017, which produced the specification and bound only the CMA9.
6. Everybody outside the CMA9 built what they liked, so coverage is a matrix of institutions rather than a national fact.
7. Card fees are percentages and open banking fees are flat in pence, which is why the saving grows with the size of the payment rather than staying constant.
8. The money arrives in seconds at twenty past nine on a Wednesday evening, because Faster Payments runs every hour of every day including Christmas morning.
9. It also arrives for keeps: a push payment has no chargeback, no section 75 protection and no reversal mechanism.
10. Regulation 76 refunds unauthorised transactions, and a payment approved with strong customer authentication is authorised, so it is unavailable for a sofa that never arrived.
11. The authorised push payment regime covers deception by a criminal rather than a dispute with a merchant.
12. So an open banking payment is a bank transfer with a good user interface: better than a card for paying your own energy bill, materially worse for buying a mattress from a company you have never heard of.
13. Consent is at least two permissions, one contractual with the third party and one an authorisation event at the bank, and they drift apart in ordinary use.
14. Since March 2022 the ninety-day obligation has been a reconfirmation of consent obtained by the account information provider, which moved the friction rather than removing it.
15. Status is not settlement: the provider sees the bank’s view of the payment order, statuses lag, and a checkout that waits for a terminal status is a checkout that hangs.
16. A variable recurring payment is one authorisation plus control parameters, a maximum per payment, periodic limits, a named payee and a validity window, enforced by the bank rather than by the third party.
17. Sweeping, moving your own money between your own accounts, was mandated on the CMA9 with non-discriminatory access, which is precisely why it is free at the point of use.
18. Commercial VRP needed a commercial model the CMA Order never provided, which arrived with the UK Payments Initiative scheme launched on 2 June 2026 and a regulatory forbearance on its centralised access fee running to July 2027.
19. Whether regulation 79’s refund right attaches to a commercial VRP is genuinely unsettled, and the Direct Debit Guarantee, an immediate refund on request with no time limit, is the standard against which VRP will be measured.
20. Everything good about open banking payments and everything difficult about them come from the same fact wearing two faces: they run on Faster Payments.

Sources: Open Banking Limited, on the Open Banking Standard v4.0 and v4.0.1, the Read-Write API Profile and VRP API Profile v3.1.10, the Payment Initiation API Profile v4.0, the standards proposition on Variable Recurring Payments, Directory and certificate guidance on OBWAC and OBSeal, the API performance statistics for June 2026, the ecosystem highlights published on openbanking.org.uk, and the year-in-review analysis for 2025; the Competition and Markets Authority, Retail Banking Market Investigation Order 2017, the roadmap completion confirmations of January 2023 and September 2024, the letters on VRP for sweeping of 27 July 2021, 15 November 2021, March 2022 and 3 December 2025; the Payment Services Regulations 2017 (SI 2017/752), regulations 68 to 71, 74 to 80, 95 and 100, as published on legislation.gov.uk; the Financial Conduct Authority, PS21/19 on changes to the SCA-RTS, the strong customer authentication pages, FS25/4 on the design of the Future Entity, the letter to trade associations of 19 December 2025, the open banking progress statement of 2025, the joint statement with the PSR of 20 January 2026 on open banking pricing models, and the statement on the launch of the UK Payments Initiative scheme; the Payment Systems Regulator, PS24/7 on the maximum level of reimbursement for Faster Payments APP scams; Pay.UK, on how Faster Payments work and on Confirmation of Payee; UK Payments Initiative, launch announcement of 2 June 2026; Directive (EU) 2015/2366 and Commission Delegated Regulation (EU) 2018/389; the Data (Use and Access) Act 2025; the Council of the European Union, final compromise texts for PSD3 and the Payment Services Regulation of 23 April 2026; the Consumer Credit Act 1974, sections 75 and 75A, and the Financial Ombudsman Service guidance on section 75 and chargeback.