DSP2 is often seen from the business side as a simple "obligation for banks to open up APIs". On the technical side, it's a non-trivial assembly: multiple standards, qualified electronic certificates, hardened OAuth2, asynchronous authentication flows, and very real fragmentation between banks.
This article gives a high-level but precise view of that architecture, for CTOs, technical PMs and developers who need to scope a PSD2 project — whether to integrate a partner TPP or to expose your own APIs. For the business / product version, see instead: Understanding PSD2 visually.
The PSD2 stack in one picture
A PSD2 call crosses several layers that don't serve the same purpose. None of them is optional.
Key takeaway: you don't just sign your requests over plain HTTPS. The channel is mTLS (both parties authenticate), the payloads are signed independently, and authorisation goes through a strictly profiled OAuth2.
API standards: not one, but three
The directive requires opening up APIs but does not dictate the format. Three standards have emerged in Europe.
| Standard | Coverage | Style |
|---|---|---|
| STET | France and Belgium | REST/JSON, based on ISO 20022 |
| Berlin Group | Most of the EU | REST/JSON, the most widespread |
| Open Banking UK | United Kingdom | The most mature, mandatory FAPI profile |
Concrete consequences:
- Covering all of France = supporting STET (BNP, Société Générale, BPCE, Crédit Agricole, La Banque Postale, etc.) plus a few Berlin Group implementations from online banks.
- Scaling across Europe = adding Berlin Group with per-country variants (Germany, Spain and Italy don't follow exactly the same version).
- In practice, many teams use an aggregator (Bridge, Tink, TrueLayer, Yapily) that absorbs this fragmentation in exchange for a margin.
The chain of trust: eIDAS, QWAC and QSealC
PSD2 answers a simple question: how does a bank know that an API call really comes from a licensed TPP? The answer lies in the qualified electronic certificates of the eIDAS TSP regulation.
Two certificates, two uses:
- QWAC — used to establish the mTLS channel. It identifies the TPP at the transport level. Think "ID card".
- QSealC — signs the content of requests (detached signature). It guarantees the integrity and non-repudiation of the payload. Think "wax seal on the envelope".
Both encode the TPP's PSD2 roles (AISP / PISP / CBPII). The bank dynamically checks that the certificate actually covers the requested operation.
OAuth2: materialising consent
On the authorisation side, it's OAuth2 in its Authorization Code + PKCE flow. Nothing exotic, but with constraints:
- The TPP builds the authorisation URL and redirects the PSU to the bank.
- The bank authenticates the PSU (login + SCA) then shows the consent screen.
- Return to the TPP with a single-use code.
- Exchange of the code for a (short-lived) access token and a (long-lived) refresh token (up to 180 days on the AISP side).
- Every API call carries
Authorization: Bearer <token>and the QSealC signature and goes through mTLS.
For stricter profiles (FAPI 1.0 Advanced or 2.0), you add JWT / JWS / JWE for signed requests (JAR), and binding of the token to the client certificate. It's mandatory in the UK, optional / not enforced on Berlin Group and STET.
The three SCA flows to support
The moment when the PSU authenticates with their bank (the SCA) can take three forms, and the bank chooses, not you. Covering the whole market requires handling all three — see Flux SCA.
| Flow | How it works | When the bank picks it |
|---|---|---|
| Redirect | The PSU is redirected to their bank's website or app, then comes back. | The de facto standard in France. |
| Decoupled | Push notification in the banking app, biometric validation, polling on the TPP. | Neobanks, better mobile UX. |
| Embedded | The PSU enters their credentials in the TPP interface, which forwards them. | Rare, discouraged, often refused. |
Common pitfalls:
- In decoupled mode, some banks require a minimum delay between triggering and polling, others limit the number of calls and require a webhook.
- In redirect mode, mobile returns via deep link are a source of bugs: plan a web fallback.
- A single initial SCA, then 180 days of AIS access via refresh token without a new SCA — that's the 2022 EBA rule. Before 2022 it was 90 days.
Consent: an object to model end to end
Consent is not a boolean. It's an object stored on the bank's side, with:
- A scope (accounts, access types: balances, transactions, details).
- A time window (up to 180 days for AIS, single-use for PIS).
- A frequency (4 refreshes per day without the PSU present).
- A state that changes over time.
On the implementation side, you must:
- Persist the consentId and tie it to your PSU.
- Monitor its state (poll + webhook if available).
- Trigger a renewal before expiry, ideally with a UX that anticipates it.
- Handle revocation on the bank side: a consent that's active on your end can be killed without you knowing until you call the API.
Security: mTLS, signing, idempotency
Three technical requirements shape any PSD2 integration.
- mTLS on all back-channel calls. The TPP presents its QWAC, the bank presents its own.
- HTTP Signature of requests via QSealC: the signature covers the critical headers and a hash of the body. Essential on the PIS side so a payment initiation cannot be repudiated.
- Idempotency key on all PIS operations to avoid double payments in case of a network retry.
On top of this comes robust error handling: HTTP codes, business codes specific to each standard, rate limits, banking maintenance windows. No ASPSP API has a contractual 99.99% SLA.
Webhook or polling?
To track the state of a consent, an initiated payment or a decoupled SCA flow, two mechanisms coexist — see Webhook / Polling.
- Polling: the TPP queries the status API at intervals. Universal, but costly and slow.
- Webhook: the bank calls a TPP endpoint. Reactive, but few banks expose a reliable one on the EU PSD2 side.
In practice you combine the two: webhook when available, polling as a fallback, with exponential backoff.
Testing without breaking prod
Three environments to know:
- Public sandbox: open, without real eIDAS certificates. Useful for a POC.
- Certified sandbox: requires test certificates issued by a QTSP, with a per-bank enrolment process. This is where you validate the end-to-end integration.
- Production: requires ACPR licensing (or equivalent), valid QWAC + QSealC certificates, and prior registration with each bank.
The move from sandbox to prod is rarely seamless: payload sizes, latencies, error codes, real versus simulated SCA — every bank has surprises in store.
What's next? What DSP3 and PSR change
For technical teams, the changes to anticipate:
- API quality measured and published by regulators: SLA, response times, error rates.
- End of screen scraping: no more fallback outside the API.
- Reinforced anti-fraud (notably APP fraud): VoP (Verification of Payee) on SEPA, sharing of indicators between players.
- FAPI convergence more than likely, alignment with the EUDI Wallet for identity.
- FIDA: extension to new data families (savings, credit, insurance). The technical model is heavily inspired by PSD2 but with finer-grained permission schemes.
To sum up
Building or integrating a PSD2 API is not "plugging in yet another REST API". It's:
- Choosing one or more standards (STET, Berlin Group, possibly OB UK).
- Obtaining and maintaining eIDAS certificates (QWAC + QSealC).
- Implementing OAuth2 with PKCE, request signing and idempotency.
- Supporting the three SCA flows on both the UX and backend sides.
- Modelling consent as a first-class object, with its lifecycle.
- Handling fragmentation bank by bank — or outsourcing it to an aggregator.
For the product / business version, read Understanding PSD2 visually. For the full vocabulary, the Open Banking glossary is indexed by category.