Reference · Proposed legislation
PSD3 open banking, as proposed
PSD3 is the shorthand for a proposed third payment services directive, published by the European Commission together with a proposed Payment Services Regulation. Between them they set out how the European Union proposes to update the rules that open banking runs on: how a bank exposes an API, how well that bank API has to work, how data access permission is managed, how a payment service is authorised and how fraud is handled. This page sets out what the package covers and, just as usefully, what it does not yet settle.
Status: these are proposals, not law. They have been moving through the European legislative process, the text can change during it, and no application date should be treated as fixed. Nothing here describes rules that apply today, and nothing here is legal advice.
The package
What PSD3 is
Not one instrument but two, which is the first thing that trips people up. The rules open banking services depend on are proposed to sit in the regulation rather than in the directive that carries the PSD3 name, so reading only the PSD3 text would miss most of what matters to a payment service.
- Two instruments
A directive and a regulation
The package as published splits the current rulebook in two. A directive, widely called PSD3, is proposed to carry authorisation and supervision of the institutions that provide a payment service. A directly applicable regulation, the Payment Services Regulation, is proposed to carry the conduct rules every payment service follows, including the ones that govern open banking access to a bank account and the data a bank holds in it. Which instrument a rule sits in matters: a regulation applies as written, a directive does not.
- Why split
The reason for the structure
A directive has to be transposed into national law, and member states transposed PSD2 differently. Moving conduct rules into a regulation is proposed to reduce that divergence, so the same rule reads the same way in every market rather than being interpreted bank by bank and supervisor by supervisor. Anyone who has shipped an open banking integration in more than one country has met that divergence: the same payment service, the same bank API pattern, different local expectations about how to use it.
- Scope
E-money brought together
The proposals also bring electronic money institutions into the payment institution regime rather than leaving them under a separate instrument. For open banking services that matters because many providers and account issuers are e-money institutions rather than banks, so the regime a business would use for its account and the regime its payment services provider sits under start to look alike.
Comparison
PSD2 to PSD3: what is changing
Themes rather than requirements. Every row on the right sets out what the PSD3 package aims to address, not a rule a business or its payment services provider can rely on yet. The directive in force today is described on the PSD2 open banking page.
| Topic | Today, under PSD2 | In the proposals |
|---|---|---|
| Legal form | One directive, transposed by each member state in its own way | Proposed as a directive plus a directly applicable payment services regulation |
| E-money rules | A separate e-money regime | Proposed to be folded into the payment institution regime |
| Access interfaces | A dedicated bank API required, with a fallback expectation | Bank API performance and availability are a stated focus of the PSD3 package |
| Consent management | Consent handled per service and per bank | Customer-facing management of open banking data permissions is addressed |
| Fraud | SCA plus whatever supervisory practice each market uses | Fraud prevention is one of the package's headline themes |
| Status | In force and applying today | Proposed, still in the legislative process |
Deliberately absent from that table: article numbers, thresholds and dates. A package under negotiation changes in exactly those details, and repeating an early draft as settled law is how vendor pages end up wrong. Where a number matters to a decision, it should come out of the official text rather than out of a summary like this one.
Open banking
Open banking under PSD3
Open banking is not being rebuilt by the package. The architecture PSD2 created stays recognisable: a bank exposes an API, a licensed service uses it with the customer's permission, and account data or a payment moves through it. The proposals work on the parts of that model which have proved awkward in practice rather than on the model.
- Interfaces
The API is the regulated surface
Under PSD2 the dedicated bank API became the channel open banking runs on, and every account data request and payment service call travels through it. The proposals keep that architecture and put more attention on how well that bank API serves the services that use it, which is where most day-to-day open banking friction sits.
- Parity
What the interface should offer
A recurring theme in the package is that the data and functionality reachable through a bank API should line up with what the same bank offers its own customers directly. That principle exists in the current regime too; the proposals give it more prominence. In practice it is the difference between a bank API a service can build on and one that returns half the data the same bank's own app shows.
- Visibility
Permissions the customer can see
Giving a customer one place to review and withdraw the data access they have granted is among the areas the package addresses. Today that visibility is uneven, and a customer often has to go provider by provider to find out which open banking service still holds a live data permission against their bank account.
Technical side
API quality and access
Ask anyone who has built an open banking service what the hard part is and the answer is rarely the concept. It is that one bank API answers in a second while another times out, that error codes carry different meanings from bank to bank, and that an API can disappear for a morning with no notice. The whole tech burden of the market sits in that variance, and it is why most teams use an aggregation layer rather than calling out to each bank API directly.
That is why API quality is the part of the package the tech side of the market pays most attention to. Availability, response behaviour and the parity between what a bank API offers and what the same bank's own channels offer are all areas the proposals take up, and all three are tech problems before they are legal ones. None of it is settled, and the operational detail is expected to arrive later in tech standards, which is where the current regime put it too. A service that uses twenty bank APIs feels those standards more than it feels the directive.
Data and protection
Data access and protection
The consent model is not what the package sets out to replace. Most of the work on the data side is about making a data permission visible to the customer who gave it, and about making fraud harder for every service that handles a payment.
- Access
Data access stays consent-based
The core design is not proposed to change: a third party reaches bank account data only with the customer's permission, and only within the scope that permission sets out. The proposals work on how that permission is captured, shown and withdrawn rather than on replacing the model. Consent stays the thing that unlocks the data, the bank stays the place the customer proves who they are, and no open banking service gets data outside what that consent covers.
- Fraud
Fraud prevention moves up the agenda
Fraud is one of the package's headline themes. Matching the name of a payee against the account identifier before a transfer, and sharing fraud data between the payment services providers involved, are among the areas addressed. How far each goes is set by the final text, and both would land on banks and the licensed services above them rather than on the software layers those services use.
- Beyond payments
A separate open finance track
A related proposal deals with access to financial data beyond the payment account, often discussed as open finance. It is a separate instrument on its own timeline, so it should not be read as part of PSD3 even though the two get discussed together and use much of the same vocabulary. Anyone tracking data access should follow both, because they answer different questions about which data an open banking service may reach and on what terms.
Outlook
What it may mean for the market
Written in the conditional on purpose. These are reasonable readings of the direction of travel for open banking services, not predictions, and none of them should be planned against as fact. How much any of it changes depends on text that does not exist in final form.
-
Bank API quality becomes measurable
If bank API performance is supervised more closely, the practical difference between one bank API and another may narrow. For anyone building an open banking service that would cut out the per-bank defensive engineering the market requires today, and the tech cost of adding the next bank would fall with it.
-
More work on the fraud side
Stronger fraud expectations would land on banks and licensed providers rather than on the software vendors they use. How that reshapes payment services across the market, and what it costs each bank to build out, is one of the more consequential open questions in the package.
-
Less divergence between markets
Conduct rules in a directly applicable regulation would be expected to read the same in every member state. A business that has to use open banking services across several markets may find fewer national quirks to work out, though supervisory practice still varies in ways no text fully removes.
-
A long runway either way
A directive needs transposition after adoption, and the bank API estate a market runs on takes years to change. Even once the package is settled, the tech and operational reality of open banking would be expected to shift gradually rather than on a single date, bank by bank and service by service, as each bank rolls out changes on its own schedule.
Disclosure
Where viaBanking fits
One section about the operator of this site, in the same third person as the rest of the page, and deliberately short.
viaBanking is a software company. It holds no authorisation under the payment services regime, it does not perform the account information service or the payment initiation service, and it does not hold or move funds. Those services are performed by licensed providers and the banks involved, which is how the current regime allocates them.
What the platform does is orchestration: it connects a business to the licensed providers it uses through one integration, routes each request to a provider that reaches the relevant bank, and normalises the data that comes back into one data model. On top of that it confirms, read-only, that a payment reached the business's own bank account. The same model is set out on the open banking aggregator page.
This page will not forecast how that arrangement changes under a text still being negotiated, and no reader should use it that way. A software layer sits above whatever the licensed parties are required to do, and if those requirements change, they change for the licensed parties first. Anyone who tells you today exactly what a vendor will do under PSD3 is describing a roadmap, not a regulation.
- Licensed AIS and PIS providers Hold the authorisations and perform each regulated payment service
- Banks and account issuers Expose the bank API, authenticate customers and move the money
- Supervisors Set out and enforce what the rules require of those parties
- viaBanking Software a business chooses to use: routing and normalisation over what those parties do
Caveats
Open questions and timing
The most useful part of any page about proposed legislation is the list of things it cannot tell you, whatever tech or legal summary you use alongside it. These are the questions to keep out of a business case until the text lands.
- 01
The text is not final
The package has been working through the European legislative process, where the Parliament and the Council each take positions and the text is negotiated. What was published at the start is not necessarily what comes out at the end, which is why this page describes areas rather than requirements.
- 02
Timing is not settled
No application date should be treated as fixed until the final instruments are published. A directive also carries a transposition period afterwards, so the date a rule is adopted and the date a business or a bank actually feels it are different dates, often by a long way.
- 03
Detail sits in technical standards
As with the current regime, a lot of the operational detail on a bank API and on authentication is expected to arrive in tech standards written after the main text. Those tech standards usually decide what an integration actually has to do, so a team reading only the directive would still not know what to build or which data to expect.
- 04
Read the source, not the summaries
Vendor summaries of a moving legislative package age badly, and this page is one of them. For anything that matters commercially, the official documents and a qualified adviser are the right place to check. Use it to get oriented, not to make a decision, and check anything load-bearing against the source.
FAQ
Common questions
-
Is PSD3 in force yet?
No. PSD3 and the accompanying Payment Services Regulation are proposals that have been working through the European legislative process. Nothing on this page describes law that applies today. The rules in force are those of the current regime, PSD2.
-
How is PSD3 different from PSD2?
The clearest difference is structural: the package is proposed as a directive plus a directly applicable regulation, rather than one directive transposed differently in each market. Beyond that, the areas it gives most attention to are bank API quality, data permission visibility and fraud. The substance of each is set out by the final text.
-
Does viaBanking change what it does under PSD3?
The honest answer is that no software vendor can responsibly answer that about a text still being negotiated. viaBanking is a software layer today: it routes to the licensed services a business uses and holds no authorisation of its own. That division of labour is not something this page will forecast changes to.
-
Will open banking APIs get better?
Bank API quality and availability are a stated focus of the proposals, so the direction of travel is clear enough. Whether that turns into bank APIs a service can rely on depends on the final requirements, the tech standards that follow and how each supervisor chooses to use them.
-
Should we plan our roadmap around PSD3?
That is a question for your own advisers rather than for a vendor page. What can be said neutrally is that the text and its timing are not settled, so plans that assume a specific requirement or a specific date carry more risk than plans that do not.
See how the platform works today
This page was about proposed rules. If you would rather see what runs under the rules that apply now, the connectivity layer is described on the bank connectivity page.
This page is general information about proposed European payment services legislation. It is not legal advice, not a description of law in force, and not a commitment about future product behaviour. The proposals may change during the legislative process, and no date on which any of it applies should be inferred from this page. viaBanking is a software and technology provider: it holds no authorisation under the payment services regime, does not perform account information or payment initiation services, does not execute bank payments and does not hold or move funds.