# 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.

_Published: 2026-04-06 · Category: regulation · Tags: #dsp2 #psd2 #open-banking #regulation #business_

---

[DSP2](https://openfinanceguide.com/en/glossary/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](/blog/architecture-api-dsp2).

## 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.

```mermaid
flowchart LR
    PSU["👤 Customer"]
    APP["🏢 Third-party service"]
    BANK["🏦 Bank"]

    PSU -->|"Hands over their credentials 🔓"| APP
    APP -->|"Logs in on their behalf"| BANK
    BANK -->|"Web page"| APP
    APP -->|"Scrapes the data as best it can"| APP
```

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.

```mermaid
flowchart TB
    PSU["👤 PSU\nThe end customer"]

    subgraph TPP["🏢 TPP — Third-party providers"]
        AISP["📊 AISP\nAccount information"]
        PISP["💸 PISP\nPayment initiation"]
        CBPII["💳 CBPII\nFunds confirmation"]
    end

    ASPSP["🏦 ASPSP\nThe bank"]
    NCA["⚖️ NCA\nThe regulator"]

    PSU -->|"Consent"| TPP
    TPP <-->|"Official access"| ASPSP
    NCA -->|"Licenses"| TPP
    NCA -->|"Supervises"| ASPSP
    ASPSP -->|"Holds the accounts of"| PSU
```

| Player                          | Role in one sentence                                                          |
| ------------------------------- | ----------------------------------------------------------------------------- |
| [PSU](https://openfinanceguide.com/en/glossary/psu)     | The end user — your customer.                                                  |
| [ASPSP](https://openfinanceguide.com/en/glossary/aspsp)   | The bank that holds the accounts and opens them up to third-party services.   |
| [TPP](https://openfinanceguide.com/en/glossary/tpp)     | The third-party service that connects to the bank (your app, or a partner).   |
| [NCA](https://openfinanceguide.com/en/glossary/nca)     | The national authority that licenses TPPs. In France, it's the [ACPR](https://openfinanceguide.com/en/glossary/acpr). |

> **Info:**
> 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.

| Business                        | What it does                                                  | Examples                                              |
| ------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------- |
| [AISP](https://openfinanceguide.com/en/glossary/aisp)    | **Reads** accounts: balances, transactions, aggregation.      | [Bridge](https://openfinanceguide.com/en/glossary/bridge), [Tink](https://openfinanceguide.com/en/glossary/tink), Bankin', Pennylane |
| [PISP](https://openfinanceguide.com/en/glossary/pisp)    | **Triggers** a transfer from the customer's account.          | [Fintecture](https://openfinanceguide.com/en/glossary/fintecture), Bridge, Trustly   |
| [CBPII](https://openfinanceguide.com/en/glossary/cbpii)   | **Confirms** whether there are sufficient funds (yes / no).   | Co-branded card issuers                               |

> **Warning:**
> Without a licence granted by a regulator (the [ACPR](https://openfinanceguide.com/en/glossary/acpr) in France),
>   a player **cannot** connect to banking APIs. That's what protects customers —
>   and what shaped the entire ecosystem.

## Consent: the keystone

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.

```mermaid
sequenceDiagram
    participant PSU as 👤 Customer
    participant APP as 🏢 App (AISP)
    participant BANK as 🏦 Bank (ASPSP)

    PSU->>APP: "I connect my bank"
    APP->>BANK: Access request on the customer's behalf
    BANK-->>APP: Authentication link
    APP->>PSU: Redirect to the bank
    PSU->>BANK: Authenticates (password + biometrics)
    PSU->>BANK: "I authorise"
    BANK-->>PSU: Return to the app
    APP->>BANK: Reads the accounts
    BANK-->>APP: Balances and transactions
    APP->>PSU: Shows everything in one place
```

The "password + biometrics" step corresponds to **strong authentication**, or [SCA](https://openfinanceguide.com/en/glossary/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](https://openfinanceguide.com/en/glossary/3d-secure) v1 to v2 in e-commerce.

## Before / after: what PSD2 really changed

```mermaid
flowchart LR
    subgraph BEFORE["❌ Before PSD2"]
        A1["Bank = sole keeper of the data"]
        A2["Technical workaround\n(shared credentials)"]
        A3["No clear framework for third parties"]
    end

    subgraph AFTER["✅ After PSD2"]
        B1["Mandatory official access"]
        B2["Explicit customer consent"]
        B3["Licensed and supervised third parties"]
        B4["Widespread strong authentication"]
    end

    BEFORE -->|"PSD2 (2018)"| AFTER
```

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](https://openfinanceguide.com/en/glossary/baas) and [Embedded finance](https://openfinanceguide.com/en/glossary/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](https://openfinanceguide.com/en/glossary/agregation-bancaire) and payment initiation become building blocks you can consume through partners (Bridge, Tink, [Fintecture](https://openfinanceguide.com/en/glossary/fintecture)…) without becoming an [AISP](https://openfinanceguide.com/en/glossary/aisp) or [PISP](https://openfinanceguide.com/en/glossary/pisp) yourself. Use cases: **PFM** (personal finance management, see [PFM / BFM](https://openfinanceguide.com/en/glossary/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](https://openfinanceguide.com/en/glossary/baas) logic, see [Treezor / Swan / Solaris](https://openfinanceguide.com/en/glossary/baas-players)).

### 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](https://openfinanceguide.com/en/glossary/dsp3) and [PSR](https://openfinanceguide.com/en/glossary/psr) (proposed in 2023) — strengthened anti-fraud efforts (notably [APP fraud](https://openfinanceguide.com/en/glossary/app-fraud)), better API quality, the official end of screen scraping, an overhaul of CBPII.
- [FIDA](https://openfinanceguide.com/en/glossary/fida) — extension of Open Banking to **all** financial data: savings, credit, insurance, investment. This is "Open Finance".

```mermaid
timeline
    title Regulatory evolution of payments in Europe
    2007 : PSD1 — First payments framework
    2018 : PSD2 — Open Banking and SCA
    2023 : PSD3, PSR and FIDA proposals
    2026-2027 : Gradual entry into force
```

## 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:

- If you want to understand the **technical mechanics** (API standards, certificates, security), read [Technical architecture of a PSD2 API](/blog/architecture-api-dsp2).
- For detailed vocabulary, the [Open Banking glossary](/glossary) covers every term.

---

Source: https://openfinanceguide.com/en/blog/comprendre-psd2-visuellement