Open Banking & PSD2 Flows
How regulated third parties access bank accounts and initiate payments on a customer's behalf — the PSD2 roles, the consent and SCA flows, the FAPI security profile, and the regional API standards (UK Open Banking, Berlin Group, STET) that implement them.
FAPI — the security profile
Open Banking APIs are secured with the OpenID Foundation's Financial-grade API (FAPI) profile — a hardened set of OAuth2 / OIDC constraints designed for high-value, write-capable financial APIs. UK Open Banking mandates FAPI; the Berlin Group and others align to it.
mTLS & sender-constrained tokens
Mutual TLS with the TPP's QWAC; access tokens are bound to the client certificate so a stolen token can't be replayed by another party.
PKCE + PAR
Proof Key for Code Exchange protects the authorization code; Pushed Authorization Requests move request parameters server-to-server, out of the browser.
Signed request objects (JAR)
The authorization request is a signed JWT, so its parameters (amount, payee) can't be tampered with in transit.
JARM / signed responses
Authorization responses are signed so the TPP can verify the issuer and detect manipulation of the returned code or state.
SCA & its exemptions
PSD2 requires Strong Customer Authentication — two of three factors (knowledge, possession, inherence) — with dynamic linking for payments (the SCA is cryptographically tied to the specific amount and payee). The same exemptions used on the card side apply, including:
- TRA — Transaction Risk Analysis, based on the provider's fraud rate.
- Low value — under €30 (with cumulative caps).
- Trusted beneficiaries — payee allow-listed by the PSU.
- Recurring — subsequent payments of a fixed-amount series.
Related: 3-D Secure & SCA on the card side →