PSD2 for startups: when payment innovation requires a legal framework

For many founders, payments initially feel like a product question. How do you make the checkout faster, reduce friction, link multiple accounts, or make it easier for users to initiate transactions? From a legal perspective, that is only half the story. PSD2 demonstrates that payment services are not just a technical or commercial topic, but also a regulated activity with clear rules of the game.

This makes PSD2 relevant to a much broader group of companies than just traditional banks. With PSD2, European legislators aimed to further harmonize the payment services market, promote competition, encourage innovation, and make payment traffic more efficient. The playing field has been intentionally opened up to parties other than banks. Think of payment institutions, electronic money institutions, and providers of new digital services related to payments and account information.

For startups and scale-ups, this is both an opportunity and a warning. An opportunity, because PSD2 creates space for innovation in payment traffic. A warning, because that space comes with oversight, information obligations, security requirements, and civil law rules that can directly impact your product model.

PSD2 is more than just oversight: the contractual side matters too

A key feature of PSD2 is that the framework consists of more than just supervisory law. The regulation combines supervisory and civil law rules. In practice, that distinction is essential.

On the supervisory side, it concerns questions such as who is permitted to provide payment services, when a license is required, and what prudential and conduct-related requirements a provider must meet. For startups, that is often the first reflex: do we need a license, do we fall under an exemption, or should we partner with a party that is already licensed?

But it doesn't stop there. PSD2 also contains civil law rules regarding the rights and obligations of payment service providers and payment service users. This includes, for example, the provision of information, amendments to and termination of agreements, costs, execution of transactions, and liability for unauthorized or incorrectly executed payments.

For tech companies, this is a crucial point. Anyone building a payment service is not just building a compliance layer for regulators, but also a contractual relationship with users that involves legal rights and obligations. The legal design of your product is therefore not just in your licensing process, but also in your terms and conditions, customer journey, and operational processes.

At Startup-Recht, we regularly see founders focusing primarily on whether they "fall under PSD2," while the equally relevant follow-up question is what that means for their user relationship. That is precisely where the first real risks often arise.

Why PSD2 became so relevant for innovation

Traditionally, payment traffic was handled primarily by banks. That had already begun to change, but PSD2 has visibly accelerated that development. The regulation builds on PSD1 while simultaneously introducing a number of essential innovations.

The reasoning behind this is clear. The payment market needed to become more efficient, competitive, and innovative. PSD2 is therefore not just a protection framework, but also a market-structuring instrument. The directive aims to strengthen card payments, internet payments, and mobile payments, and to fix shortcomings from the previous regime.

For startups and scale-ups, this is exactly why PSD2 is so relevant. Many modern fintech products are not on the periphery of payment traffic, but right in the middle of the value chain. A smart checkout tool, a platform that initiates payments, a dashboard that aggregates account information, or an app that provides insight into multiple accounts quickly touches on functions that can legally qualify as payment services.

The legal question is not whether your company labels itself as fintech. The real question is what activity you are actually performing.

The two major innovations of PSD2: payment initiation and account information

One of the most important innovations of PSD2 is that two new payment services have been explicitly regulated: the payment initiation service and the account information service.

Payment initiation services

In short, a payment initiation service is a service that, at the user's request, initiates a payment order regarding a payment account held with another payment service provider. It concerns an online service. In practice, you can think of a service that facilitates a payment to an online store without the provider itself holding the user's payment account.

For startups, this is relevant because many innovative payment solutions operate exactly at this intersection. You are not necessarily on the account itself, but you are in the transaction flow. As soon as you initiate the payment order on behalf of the user from within your product, you legally enter a different playing field.

Account information services

An account information service is an online service that provides consolidated information on one or more payment accounts held by a user with one or more payment service providers. Think of an environment where a user can view balances and account information from different accounts in one place.

This is also particularly relevant for tech companies. Many financial apps rely on overviews, analysis, integrations, and dashboards. As soon as you unlock account information from elsewhere, there is a good chance that you are not just building a data product, but also a regulated service.

What characterizes these new services is that the provider does not need to offer payment accounts and does not need to hold money from or for users. This makes it attractive for digital businesses, but it is not unregulated.

Access to payment accounts is possible, but not without obligations

PSD2 has not only defined new services but also regulated how those services can gain access to users' payment accounts.

Such access is only possible with the explicit consent of the payment service user. It is important that this consent cannot be assumed lightly. A simple checkbox is not enough. In practice, this explicit consent is provided via strong customer authentication.

This brings a second core component of PSD2 into play: security. Strong customer authentication works with at least two elements from different categories, such as knowledge, possession, and an inherent user characteristic. Think, for example, of a combination of a password, a payment card or device, and biometrics.

For startups, this means that ease of use cannot be viewed separately from authentication requirements. A frictionless user flow is commercially attractive, but under PSD2, that flow must also be legally and technically defensible. Anyone wanting to organize access to account data or payment functionality must therefore incorporate authentication into product design and engineering from the very beginning.

Furthermore, for account information services, access does not remain open indefinitely. Consent has a limited time horizon and must be periodically reconfirmed via strong customer authentication. This also directly affects UX, retention, and the way you guide users through your product.

Banks must provide access, but within technical rules

Another fundamental step of PSD2 is that account-servicing payment service providers, in practice often banks, must grant access to payment initiation service providers and account information service providers when the user has explicitly consented to this.

This is a major shift, both legally and commercially. The account may be with the bank, but the user can choose to have a third party provide access or functionality via another service. This opens the door to new propositions and increased competition in the payment market.

At the same time, this access is not unrestricted. Account-servicing payment service providers may set requirements for the technical manner in which access takes place. PSD2 and the associated technical standards therefore mandate a special software environment, typically via an API. Access via screen scraping no longer fits into this framework.

For startups, this is not a minor detail. It means that a payment product must not only be legally sound but must also technically align with the infrastructure provided by account-servicing parties. A business model that relies on informal or outdated access methods is therefore vulnerable.

In practice, we see that this is exactly the point where legal, product, and engineering must come together. Not just when the first bank integration goes live, but starting with the very first architectural choices.

PSD2 has a broad scope, even beyond purely domestic transactions

A common misconception is that PSD2 is only relevant for classic European domestic payments. The scope of the regulation is broader.

The regulatory rules apply to payment services offered in the EU or EEA. As a result, transactions where only one of the payment service providers involved is established in the EU or EEA may also fall under the regime, insofar as the part of the transaction takes place within the EU or EEA.

The civil law scope under PSD2 has also expanded. In certain cases, the rules apply across the board, and in other cases, they apply to the part of the transaction executed within the EU or EEA. This makes PSD2 also relevant for companies with international flows, cross-border users, or foreign partners.

For startups and scale-ups with international ambitions, this is a key point of attention. As soon as your payment product moves across borders, you should not assume too quickly that you fall outside the PSD2 framework. On the contrary, hybrid or cross-border models often require a precise qualification.

Maximum harmonization sounds appealing, but it also imposes constraints

PSD2 is based on maximum harmonization. In principle, this means that member states have little room to create stricter or more lenient rules at a national level. The idea is to create a single, uniform European market for payment services.

On paper, this is attractive for companies. A harmonized framework makes scaling across borders more straightforward than if every country had its own entirely unique system. For startups with European growth plans, this is a significant advantage.

At the same time, maximum harmonization also means that there is limited room for maneuver. Furthermore, the civil law rules of PSD2 are largely mandatory. Especially where consumer protection is involved, you cannot simply contractually override what is legally established.

This is relevant for standard terms, platform terms, embedded finance documentation, and customer contracts. Those who build their commercial model too heavily on their own terms without properly accounting for the legal framework may hit a wall later on.

What does this mean in concrete terms for startups and scale-ups?

For young tech companies, PSD2 is primarily relevant on three levels.

1. Your product may be regulated sooner than you think

An app that initiates payments, a dashboard that aggregates account information, or an infrastructure layer that sits between the user and the payment account can quickly become more than just software from a legal perspective. The label you use internally is not decisive. The actual activity is.

2. Compliance is not an afterthought

Strong customer authentication, access methods, user consent, and information obligations are not topics to be addressed only after achieving product-market fit. They touch the core of your proposition. Those who address them too late often have to rebuild later.

3. The relationship with licensed parties is strategic

Not every company will want or be able to enter the market as a payment service provider itself. Collaborating with an already licensed party can be attractive. But even then, the legal qualification of your own role remains important. "We work with a partner" is not an automatic shield against regulatory risks.

And what about PSD3?

Looking to the future, it is clear that PSD2 is not the final destination. There are proposals for PSD3 and for a PSR, a Payment Services Regulation. These proposals could fundamentally change the regulatory framework.

The main thrust is that PSD3 is intended to replace PSD2 and the current rules for electronic money, while the PSR would bring a significant portion of the civil law rules directly to the European level. This is a fundamental shift. Rules that are currently embedded in the Dutch civil system would then largely follow directly from a European regulation.

In addition, the proposals point toward further tightening and refinement, such as more sharply formulated rules regarding strong customer authentication, a mandatory IBAN check for payments, and technically simpler access for payment initiation service providers and account information service providers to payment accounts. The position of payment institutions in relation to account-servicing parties may also change.

For startups, the practical lesson is this: do not build as if the current framework will remain static for years. Companies active at the intersection of payments, wallets, and crypto, in particular, would do well to account for further shifts.

This is even more true where electronic money tokens play a role. In that domain, overlap can occur between the MiCA framework and payment service regulations. Not every activity involving such tokens automatically qualifies as a payment service, but as soon as tokens are used for regular payment purposes, payment service regulations remain firmly in the picture. For founders building on crypto infrastructure, this is not a detail, but a core question for their licensing and partnership strategy.

Conclusion: PSD2 is not a brake on innovation, but a reality check

PSD2 was written to promote innovation and competition in the payments sector, not to block it. That is precisely why the regulation is so relevant for startups and scale-ups. It creates space for new players, new services, and new interfaces surrounding payments and account information.

However, that space comes with strings attached. Anyone building a payment service will have to deal with licensing requirements, security standards, access issues, contractual obligations, and a legal framework that can significantly impact product decisions.

For founders, the most important message is therefore simple. Do not view payments merely as a feature, but as a regulated domain. Do not view account data merely as data, but as access to a legally protected infrastructure. And do not view PSD2 as something for later, but as something that must be integrated early into your product, governance, and commercial strategy.

At Startup-Recht, we see that this is exactly where the difference is made. Not by slowing down innovation, but by structuring it in a legally smart way. Those who do this well build not only faster, but also more sustainably.

‍