regulation·7 min read

Understanding PSD2: what it changes for your customers and your business

Everything an executive, a product manager or a business team needs to understand about PSD2. Players, consent, opportunities, without technical jargon.

DSP2, PSD2 in English, is the European directive that made Open Banking explode in Europe. It created a new market of fintechs, transformed the relationship between banks and customers, and opened up a massive playground for financial products.

This article explains, without technical jargon, what PSD2 changes for your business: who the players are, how data flows, and where the opportunities lie. If you're a CTO or developer looking for the mechanics under the hood, read the sister article instead: Technical architecture of a PSD2 API.

The problem PSD2 solves

Before 2018, banks were the only intermediaries between your customers and their financial data. Services that wanted to aggregate accounts or initiate a payment relied on screen scraping: logging in on your behalf with your banking credentials and reading the bank's web page.

Not secure, not reliable, with no clear legal framework on liability.

PSD2 replaced this makeshift setup with a clear framework: banks must open up official access channels, and third-party services connect to them with the customer's explicit consent, without ever seeing their banking credentials.

The players in the ecosystem

PSD2 distinguishes four roles. Once those four acronyms are clear, everything else falls into place.

PlayerRole in one sentence
PSUThe end user — your customer.
ASPSPThe bank that holds the accounts and opens them up to third-party services.
TPPThe third-party service that connects to the bank (your app, or a partner).
NCAThe national authority that licenses TPPs. In France, it's the ACPR.

The customer (PSU) is always at the centre. No access to their data happens without their explicit consent. That's the founding principle of PSD2.

The three businesses of a TPP

"TPP" is a catch-all term. PSD2 distinguishes three very different businesses, each with its own licence.

BusinessWhat it doesExamples
AISPReads accounts: balances, transactions, aggregation.Bridge, Tink, Bankin', Pennylane
PISPTriggers a transfer from the customer's account.Fintecture, Bridge, Trustly
CBPIIConfirms whether there are sufficient funds (yes / no).Co-branded card issuers

Without a licence granted by a regulator (the ACPR in France), a player cannot connect to banking APIs. That's what protects customers — and what shaped the entire ecosystem.

No access to data happens without the customer's explicit consent. It's not a simple "I agree" checkbox: it's a formal object, framed by the directive.

What a consent defines:

  • Scope — which accounts, which data (balances only, or transactions too).
  • Duration — up to 180 days for recurring read access, then mandatory renewal.
  • Frequency — how many times a day the service can refresh the data.
  • Revocation — the customer can cut off access at any time, on the bank or service side.

For a payment, consent is single-use: one payment = one consent.

The journey, from the customer's perspective

To make all of this concrete, here's what happens when a customer connects their account to an aggregation app.

The "password + biometrics" step corresponds to strong authentication, or SCA: two factors out of three (something I know, something I have, or something I am). It's mandatory to validate consent and to confirm a payment, and it's what tipped the market from 3D Secure v1 to v2 in e-commerce.

Before / after: what PSD2 really changed

Concretely:

  • For customers: more choice of services, better security, real control over their data.
  • For fintechs: a legal framework to innovate without depending on the goodwill of banks.
  • For banks: an obligation to open up their data, but also an opportunity to become platforms (BaaS and Embedded finance logic).

The business opportunities opened up by PSD2

Depending on your position in the ecosystem, PSD2 opens up very different avenues.

If you're a fintech

Agrégation bancaire and payment initiation become building blocks you can consume through partners (Bridge, Tink, Fintecture…) without becoming an AISP or PISP yourself. Use cases: PFM (personal finance management, see PFM / BFM), automated accounting, credit scoring, alternative payments to cards.

If you're a merchant or e-commerce business

Payment initiation (PISP) offers an alternative to cards: an instant transfer triggered from the customer's account, with no interchange fees, with immediate confirmation. Attractive for high baskets, subscriptions, or wallet top-ups.

If you're a bank or financial institution

Beyond the obligation, PSD2 lets you turn the API into a product: premium billing to TPPs, value-added services, embedded distribution at partners (BaaS logic, see Treezor / Swan / Solaris).

If you're a B2B SaaS software vendor

Automatically connecting your customers' business accounts (via a partner AISP) removes hours of manual data entry. That's what propelled Pennylane, Qonto and most modern accounting tools.

What's next? PSD3, PSR and FIDA

PSD2 is eight years old, and Europe is preparing what comes next. Three texts shape the coming years:

  • DSP3 and PSR (proposed in 2023) — strengthened anti-fraud efforts (notably APP fraud), better API quality, the official end of screen scraping, an overhaul of CBPII.
  • FIDA — extension of Open Banking to all financial data: savings, credit, insurance, investment. This is "Open Finance".

The bottom line

PSD2 looks complex because of its acronyms, but the core concept is simple: give customers back control of their banking data, and create a framework of trust so that other players can innovate without resorting to workarounds.

To go further:

#dsp2#psd2#open-banking#regulation#business
Trending

Read next

Expand your knowledge with these hand-picked posts.

April 7, 2026
technical

Technical architecture of a PSD2 API: what to know before writing the first line of code — Read more

A technical overview of PSD2 for CTOs, developers and technical PMs: API standards, security (mTLS, eIDAS certificates), OAuth2, SCA flows, consent management, implementation pitfalls.