PSD2 and open banking in Europe
A plain-language role map of the European directive that opened licensed access to bank accounts and set the rules its third parties work under.
Directive scope
PSD2 governs payment services across the European Economic Area
Licensed access
Bank account access requires authorisation from a national regulator
Two service types
Payment initiation and account information are separate licences
Authentication at the bank
Strong customer authentication happens on the bank's own side
Six building blocks
The successor version is drafted from the same primitives — see the PSD3 briefing for what changes and what does not.
-
Regulated account access
Under PSD2 a licensed third party may reach a payment account held at another institution once the account holder has given the user's payment consent. Access is limited to what the licence covers.
-
Payment initiation service
A payment initiation service provider is authorised to instruct a transfer from the payer's account. The provider does not hold the funds, because the account servicing bank executes the transfer itself.
-
Account information service
An account information service provider is licensed to read account data on the user's behalf. Such access is a separate authorisation from payment initiation and is granted separately by the regulator.
-
Dedicated bank interfaces
Account servicing banks publish a dedicated interface for licensed providers, with documentation and a test facility. Availability and performance of that interface fall under reporting obligations set by the directive.
-
Strong customer authentication
Electronic payments call for two independent authentication elements. The check runs on the account servicing bank's own domain, which means account credentials never reach the merchant or the initiating provider.
-
Public registers
National competent authorities grant and list authorisations. Registers are public, so a merchant can confirm which licence an open banking provider holds and which countries that licence covers.
Five stages under the directive
The endpoint-level shape of that initiation sits on the payment initiation API page.
- 01
Payment request
A merchant creates a request carrying amount, currency and a reference. That request reaches a licensed payment initiation service provider, which prepares the corresponding instruction for the payer's own account servicing bank.
- 02
Bank selection
The payer chooses their own bank and is taken into that bank's environment. Nothing about the payer's account becomes visible to the merchant here, and login details stay with the bank.
- 03
Authentication and payment consent
Strong customer authentication is performed by the account servicing bank, which also records the user's payment consent for the transfer. Approval confirms the payer's authorisation, not the arrival of money anywhere.
- 04
Execution by the bank
The account servicing bank moves funds towards the payee account using the relevant payment scheme. Its outcome is reported back to the initiating provider as a status on the instruction.
- 05
Credit on the payee account
Money arrives at the payee account held at an EMI or bank. Confirmation of that credit comes from the receiving institution and is a separate event from the authorisation reported earlier.
Who does what
| Who | What they do |
|---|---|
| The merchant | Requests the payment, holds a C2B account at an EMI or bank, and decides what each reported status permits in its own processes. |
| The licensed payment initiation provider | Holds the authorisation, submits the instruction and reports the outcome. Regulatory supervision of that activity applies to this institution. |
| 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 for the merchant and provides read-only API access used to confirm the credit. |
| viaBanking | Software only. Routes initiation requests to licensed providers, normalises statuses and confirms credits through read-only API connectivity. Holds no payment licence. |
Four places software helps
The same pattern runs across countries — see the aggregator overview.
-
Two events reported separately
Authorisation at the payer's bank and a credit on the payee account are distinct occurrences. viaBanking reports them as distinct statuses, so merchant systems can act on the second one.
-
Several licensed partners, one contract
A merchant signs one agreement with viaBanking to access integrated licensed open banking providers through a single API, one data model and one status set internally.
-
Account choice kept with the merchant
Any integrated provider can be paired with any integrated EMI or bank account, so the receiving account is selected on commercial terms rather than provider compatibility.
-
Stated plainly
viaBanking supplies routing, status normalisation and read-only account credit confirmation. Regulated activity remains with the licensed institutions named in the table above, which are the parties supervised for it.
Six mechanics to read carefully
| Topic | What the directive sets out |
|---|---|
| Licence types | Payment initiation and account information are separate authorisations. An institution may hold either or both, and the public register states which. |
| Dedicated interface | Banks provide an interface for licensed providers, with documentation and a testing facility available ahead of live use. |
| Contingency measures | Where a dedicated interface is unavailable beyond defined thresholds, the technical standards describe fallback arrangements for licensed providers. |
| Authentication elements | Two elements from separate categories are needed: knowledge, possession, inherence. The account servicing bank performs and verifies the check. |
| Access renewal | Account information access is renewed within a period the directive caps. One-off payment initiation works per payment, so renewal mainly concerns recurring access. |
| Revocation window | A payer may be able to withdraw an instruction before funds leave the account, depending on the bank and the scheme. Practice differs between institutions. |
Four kinds of reader
A merchant-side view of the same flow sits on the merchants page.
-
E-commerce merchants
Teams weighing account-to-account payments against cards, who need to know which party is licensed for what and what a provider status actually confirms.
-
Platforms and marketplaces
Operators paying sellers depend on money being present on the receiving account. The role map shows which institution can confirm that, and on what basis.
-
Product and engineering
Companies building on bank interfaces establish early whether they need their own authorisation or an agreement with an institution that already holds one.
-
Finance and treasury
Reconciliation depends on knowing which event an incoming status describes. That distinction between authorisation and credit drives how postings are made.
Three prerequisites
- 01
A software agreement
A commercial agreement and API credentials with the orchestration software provider, covering request routing, status normalisation, callback delivery and read-only account credit confirmation on the merchant C2B account.
- 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
A C2B account with API access
A C2B account at an EMI or bank able to receive incoming transfers and provide read-only API credentials. That onboarding is arranged directly with the EMI or bank.
Straight answers on PSD2
-
What does PSD2 ask of account servicing banks?
Banks make a dedicated interface available to licensed third party providers, with documentation and a test facility, and they apply strong customer authentication to electronic payments. Supervision of those duties sits with national competent authorities in each country.
-
Does a merchant need its own authorisation under the directive?
A merchant accepting payments through a licensed payment initiation service provider is not itself the licensed party, since the authorisation sits with that provider. Whether a particular business model calls for its own licence is a question for the merchant's legal advisers.
-
How far does licensed account access reach across Europe?
Authorised institutions operate in the countries their authorisation covers, and coverage of individual banks differs from one provider to the next. Registers held by national authorities are the reliable source, and each provider confirms its own bank connections.
-
Which event tells a merchant the payment worked?
A credit on the payee account at the EMI or bank holding it. The provider status reporting authorisation describes what happened at the payer's bank, which is an earlier occurrence with an outcome of its own.
-
What position does viaBanking hold in this structure?
viaBanking supplies software. Its role is to route initiation requests to licensed providers, normalise statuses and confirm credits through read-only API connectivity to the merchant C2B account. No payment licence is held and no regulated payment activity is performed.
-
How soon can a merchant start once the roles are clear?
Merchant-side integration runs against a sandbox and is usually short. Live traffic then depends on provider activation arranged by viaBanking and on C2B account credentials issued directly by your EMI or bank.
Send us the flows you are planning
We will map each step to the party licensed for it, show which status each party is able to report, and set out what has to be agreed before live traffic runs.
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 hold or move funds.
Updated: