PSD2 is one of those acronyms that quietly reshaped how money moves in Europe. If your business uses any modern finance tool that connects to a bank account, initiates payments through an app, or pulls in account data automatically, you are already living inside the world PSD2 created. This article explains what PSD2 is, what Strong Customer Authentication means in practice, how open banking APIs work, and what the upcoming PSD3 and PSR rules may change.
What PSD2 is
PSD2 is the second Payment Services Directive, an EU law that has applied across the EU and EEA since 2018. It had two big ambitions: make electronic payments safer, and open up the payments market so that licensed third parties — not only banks — can offer account and payment services. Before PSD2, your bank held a near-monopoly on access to your own account data. After PSD2, you can authorise a regulated provider to access that data or initiate payments on your behalf.
This is the legal foundation of what people loosely call open banking. The directive forced banks and Electronic Money Institutions to expose secure APIs so authorised third parties can connect. The result is the rich ecosystem of accounting integrations, payment apps, and finance tools European businesses now take for granted.
Strong Customer Authentication (SCA)
The most visible part of PSD2 for everyday users is Strong Customer Authentication. SCA requires that many electronic payments and account log-ins are verified using at least two independent factors from three categories:
- Something you know — a password or PIN.
- Something you have — a phone, a hardware token, or a registered device.
- Something you are — a fingerprint or face scan.
This is why card payments online increasingly trigger a confirmation in your banking app, and why logging into financial services often needs a second step. For businesses, SCA cuts fraud but also means automated flows must be designed around it. There are defined exemptions — for example certain low-value or recurring transactions — that keep legitimate commerce smooth while still protecting the account.
The two API roles: AISP and PISP
Open banking under PSD2 is built on two regulated roles. Understanding them helps you read what any finance tool is actually doing with your account.
AISP — Account Information Service Provider
An AISP can, with your consent, read account information: balances, transactions, and account details. This is what powers automatic bank feeds in accounting software, cash-flow dashboards, and reconciliation tools. The provider never moves money; it only reads data you have authorised it to see.
PISP — Payment Initiation Service Provider
A PISP can, with your consent, initiate a payment directly from your account — without a card and without you logging into your bank manually. This underpins 'pay by bank' checkout options and some supplier-payment flows. The money moves straight from your account over standard rails, which can reduce cost compared with card acceptance.
Both roles are licensed and supervised. Behind the scenes, the institution actually holding your funds — a bank or an EMI — remains responsible for safeguarding them. If you are weighing where your money sits, our piece on EMIs versus banks explains how an EMI keeps funds segregated under EU rules.
Why open banking matters for businesses
The benefits are concrete rather than abstract. PSD2 turned the bank account into something programmable.
- Automated reconciliation — account feeds flow into your accounting system, so transactions match invoices without manual entry.
- Faster, cheaper payments — bank-initiated payments can sidestep card fees for certain flows.
- Real-time cash visibility — dashboards pull live balances across accounts, improving treasury decisions.
- Better access for fintech challengers — competition lowered prices and expanded the tools available to smaller companies.
For finance teams running ad budgets, contractor payouts, or programmatic spend, the same standards make it possible to connect issuing and account systems together. A provider can offer API issuing and webhooks so cards and transactions plug into your own software. This is exactly the model behind virtual cards for AI agents, where programmatic control over issuing and limits is the whole point.
PSD2 did not just regulate payments — it made the account itself an API that businesses can build on.
The PSD3 and PSR horizon
PSD2 is not the end of the story. The EU has proposed a next phase, commonly referred to as PSD3 alongside a new Payment Services Regulation (PSR). The aim is to refine what PSD2 started: improve how open banking APIs perform, strengthen fraud protections, clarify rules for EMIs and payment institutions, and reduce friction where SCA has been clumsy in practice.
Nothing here changes your obligations overnight — these proposals move through the EU legislative process over time. But the direction of travel is clear: more standardisation, better data sharing, and tighter anti-fraud measures. Businesses that already lean on open banking integrations are well positioned, because the foundations stay the same even as the rules sharpen.
What to do as a business
You do not need to become a payments lawyer. A few practical habits keep you on the right side of PSD2 and ready for what follows.
- Use licensed providers — check that any tool touching your account is a regulated AISP or PISP, or is partnered with one.
- Expect SCA — design internal processes so a second authentication step does not block routine work.
- Review consents — periodically audit which third parties can read your data or initiate payments, and revoke what you no longer use.
- Favour API-native finance — choosing account and card services built around APIs and webhooks future-proofs your stack.
PSD2 turned European banking into an open, programmable system. For businesses, that means cheaper integrations, faster automation, and stronger security — with PSD3 and the PSR set to extend the same principles further.