PSD2 and open banking in the United Kingdom
The UK now runs its own payment services framework from the same PSD2 starting point; this page maps pay by bank, payment initiation services and account information services across both regimes and keeps authorisation at the bank separate from the credit on your C2B account.
Two frameworks, one flow
PSD2 in the EU, UK payment services rules at home
Authorisation is not credit
Two events, confirmed in different places
Licensed parties named
Regulated payment services sit with their licence holders
Software layer only
Routing, statuses, callbacks, logs, dashboard
Six things the frameworks share and split on
The EU-only briefing is on PSD2 in Europe; the drafted successor is on PSD3.
Regulated account access
PSD2 obliges account servicing banks in the EU to give licensed payment service providers a route to initiate a transfer from a customer account, once the payer has approved that payment. That access is what makes pay by bank possible.
The UK rule set
UK open banking rests on domestic payment services regulation and a national implementation standard rather than the EU directive. Roles stay familiar to anyone who knows PSD2, while the API detail differs.
Licensing by role
Providers are authorised for payment initiation services, for account information services, or for both. EU and domestic permissions are granted separately, so trading on both sides can mean more than one provider.
Strong customer authentication
SCA is carried out by the customer's account servicing bank on its own pages. The payer approves the pay by bank transfer there, and nobody else in the chain sees bank credentials.
The payer's consent
Every initiation carries the user's payment consent for that one transfer. One-off open banking payments are consented payment by payment, and the longer consent windows discussed under PSD2 concern recurring payments.
Where the money lands
Consumer payments arrive on the C2B account, held by an EMI or bank under its own licence and its own contract with the merchant. That relationship stays direct.
Five stages, two events
- 01
Checkout request
The merchant system builds a payment request carrying amount, currency, a reconciliation reference and the payer's chosen bank, then sends it to a licensed payment initiation service provider authorised for that market under EU or domestic rules.
- 02
Authentication at the bank
The payer lands on their own bank, completes strong customer authentication and approves the pay by bank transfer there. Credentials never leave the bank, and the bank alone decides whether to accept the instruction it received.
- 03
Provider status returns
Acceptance at the bank produces an intermediate status from the licensed provider. That status records what the payer authorised at the bank, and says nothing about money arriving on any account.
- 04
Credit check on the C2B account
Read-only API connectivity to the merchant C2B account at the EMI or bank shows whether the incoming transfer has been credited, matched against the reference sent at initiation.
- 05
One final status
A single final status reaches the merchant system by callback, carrying the matched reference, the amount credited and the timestamps that reconciliation and support work will later need.
Who does what
| Who | What they do |
|---|---|
| The merchant | Offers pay by bank at checkout, holds the contract for the C2B account, and releases goods or services on a final confirmed status. |
| The licensed open banking provider | Holds the payment initiation service authorisation for that market under its local rules, forwards the instruction to the payer's bank and returns the authorisation status. |
| End user’s account issuing bank | Captures the end user’s payment consent, performs strong customer authentication and sends the authorised payment from the end user’s account. |
| The EMI or bank holding the C2B account | Receives the incoming transfer under its own licence, credits the account and gives read-only API access to that record. |
| viaBanking | Runs the software service layer: routes the request to the chosen licensed provider, normalises statuses, confirms the credit through read-only API connectivity and sends one final status. |
Four reasons this is one integration
Provider choice stays open
Selling into the UK and the EU usually means more than one licensed provider. One API contract and one status model cover them all, so coverage changes without a rebuild.
Account choice stays separate
Picking a provider no longer decides which EMI holds the incoming money. Any integrated provider pairs with any integrated C2B account, which keeps commercial terms negotiable on both sides.
Evidence before release
Merchants act on confirmation that the pay by bank transfer credited the C2B account. Where a payer reverses course at the bank, money never arrives, and the final status says so.
One operational picture
Callbacks, statuses, logs and reconciliation references sit in one data model whatever market the payment came from and whichever of the payment services carried it, so finance and support work from a single source.
Six topics that differ
| Topic | How it looks in practice |
|---|---|
| Legal basis | PSD2 applies across the EU. UK open banking now sits in domestic payment services regulation. |
| Provider authorisation | A payment service permission is granted where a provider applied for it and does not carry across between EU markets and the domestic regime. |
| API standard | The UK converged on one national implementation standard. EU bank interfaces vary by country and by bank. |
| Authentication | Both frameworks place SCA at the customer's account servicing bank. Screens differ by bank, not by regime, and the choice of bank stays open to the payer. |
| Reference handling | Reference fields differ per bank, so reconciliation matching is set per market rather than once globally. |
| Data scope | Payment initiation services return a status. Account information services need a separate agreement with a licensed AIS provider. |
Pay by bank under PSD2 and under UK rules
- RulebookPSD2 and national law
- Payment initiation servicelicensed PISP per market
- Account information serviceseparate AISP permission
- Pay by bankbank interfaces vary by country
- Recurring paymentsmandate rules set per market
- Payment statuscallback, then credit check
- RulebookPayment Services Regulations
- Payment initiation serviceFCA-authorised PISP
- Account information serviceFCA-authorised AISP
- Pay by bankone national open banking standard
- Recurring paymentsVRP on domestic rails
- Payment statuscallback, then credit check
For a merchant the result is the same on both sides: open banking payments are initiated by a licensed payment service provider, the customer moves money from their own bank account, and the money is only real once it lands on the C2B account. viaBanking keeps one API and one status model across PSD2 markets and the UK, so pay by bank checkout, refunds you pay out and recurring payments all report the same way.
Four payment types on one integration
Each type below runs through the same open banking API at home and in PSD2 markets.
Single immediate payment
The customer pays once from their bank account at checkout. A licensed payment initiation service provider sends the instruction, and it is final when the credit shows on your C2B account.
Pay by bank at checkout
Pay by bank sits next to card payments in the checkout. Customers pay without typing card details, and the open banking provider hands them to their own bank to approve it.
Variable recurring payments
A mandate set once at the customer's bank lets later payments run without a fresh approval. VRP is a domestic open banking service; under PSD2, recurring payment rules depend on the market.
Refunds and pay-outs
When you pay out a refund or a seller balance, a licensed provider initiates the payment from your account. The same status model reports pay-ins and pay-outs.
Four buyer profiles
Cross border online retail
Stores serving UK and EU customers from one platform, offering pay by bank in each market, needing one integration, one status model, and a licensed provider paired with the right C2B account in each market.
Marketplaces
Operators collecting from consumers in several countries, reconciling market by market, and holding an order back until confirmation shows the consumer payment credited the C2B account.
Repeat funding models
Subscription and account funding businesses taking recurring payments by bank transfer, where a transfer that never arrives has to become visible to operations well before the next billing run.
Finance and reconciliation
Teams closing books across accounts on both sides, who want one reference per payment and one record of what actually credited, rather than two dashboards to compare by hand.
Three prerequisites
- 01
Software layer agreement
A commercial service agreement for the orchestration layer covers API credentials, dashboard users, callback endpoints and support. Payment initiation is accessed through this agreement and performed by licensed providers; viaBanking does not execute payments or hold funds.
- 02
Provider access through viaBanking
Your agreement with viaBanking gives access to integrated licensed open banking providers without separate merchant contracts with them. We handle any required provider onboarding for your business; the providers retain responsibility for regulated payment initiation.
- 03
C2B account and API credentials
A C2B account at an EMI or bank, with read-only API credentials issued for it. Onboarding for that account is always direct with the EMI or bank.
Straight answers on the two frameworks
What comes with the integration?
One API contract, one data model and one status model across the licensed providers connected, plus request routing, signed callbacks, a dashboard with logs, and read-only account credit confirmation on the C2B account. The regulated payment initiation service stays with the provider.
Which banks and markets are reachable?
Reach comes from the licensed providers a merchant connects and from the banks each one supports, in the UK and in individual PSD2 markets. Adding a provider widens coverage without touching the merchant integration.
Who holds the licences here?
Payment initiation is performed by a licensed payment service provider authorised for that market. The account receiving consumer money is held by an EMI or bank under its own licence. viaBanking supplies software and holds no AIS or PIS licence.
What proves the money arrived?
A provider status confirms the payer authorised the transfer at their bank, which is a separate event from money arriving. Credit on the C2B account is checked through read-only API connectivity, and until that check passes the payment stays open.
How soon can the first pay by bank payment run?
Technical work on the merchant side is usually measured in days once credentials exist. Overall timing depends on the licensed provider's commercial review and on the EMI or bank opening the C2B account.
Who is this page for?
Merchants with volume on both sides, where domestic rules govern one leg and PSD2 the other, while the operational need stays identical: one integration, per market provider choice, and a final status reporting confirmed credit.
Does PSD2 still apply to open banking payments in the UK?
Not directly. The UK took PSD2 into domestic law and now runs its own payment services regulation and open banking standard. The roles are the same: a licensed payment initiation service provider sends the payment, the customer's bank authenticates, and money lands on your C2B account.
How does pay by bank work for customers?
Customers choose pay by bank at checkout, pick their bank and approve it in their banking app. No card is involved: the customer moves money straight from their account through a licensed open banking provider, and the merchant is paid once the credit lands.
Can one integration cover PSD2 markets and the UK market?
Yes. viaBanking routes each payment to a licensed provider for that market, under PSD2 in the EU or under the domestic payment services rules, and returns one status model. Pay by bank, recurring payments and refunds you pay out all use the same API.
Which payment service does viaBanking provide?
None of the regulated ones. Payment initiation services and account information services are provided by licensed institutions. viaBanking provides the software service that routes payments, normalises statuses and confirms account credits read-only.
Do open banking payments cost less than card payments?
Usually, because pay by bank skips card scheme and interchange fees. Payment initiation service pricing is covered by your agreement with viaBanking, with regulated initiation performed by the connected licensed provider.
Is VRP available under PSD2?
Variable recurring payments are a UK open banking feature built on domestic rails. Under PSD2, recurring payment initiation exists, but rules and bank support vary by market, so a merchant selling on both sides usually runs VRP for UK customers and a different recurring setup for EU customers.
Map the routing across your markets
Send us the markets you sell into, the licensed providers you work with and where your C2B account sits. Our team maps the routing, statuses and reconciliation fields per market, then we open sandbox access so your developers can run the open banking payment flow. You can also reach the team through viabanking.com.
viaBanking is a software and technology provider. Regulated payment initiation and account information services are delivered by licensed partner institutions. viaBanking does not hold an AIS or PIS licence, does not execute bank payments and does not move funds.
Updated: