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.
Consent, authorisation & the three SCA models
Every AIS or PIS journey is gated by an explicit consent and a Strong Customer Authentication step performed by the ASPSP. PSD2 defines three approaches to where that authentication happens:
Redirect (decoupled redirect)
The TPP redirects the PSU to the bank's own web/app authentication, the PSU completes SCA, then is redirected back with an authorisation code. This is the most common model and maps directly onto the OAuth2 / OIDC authorization-code grant.
- PISP creates a payment-consent resource at the ASPSP.
- PISP redirects the PSU to the ASPSP authorization endpoint.
- ASPSP authenticates the PSU (SCA: e.g. banking-app approval + biometric).
- ASPSP redirects back to the TPP with an authorization code.
- PISP exchanges the code for an access token, then submits the payment.
- ASPSP returns a payment status (e.g. ACSC / RCVD).
Decoupled
SCA happens entirely in a separate channel (typically the bank's mobile app). The TPP starts the flow with an identifier and then polls for completion — the PSU never leaves the TPP's interface. Comparable to 3DS decoupled authentication.
Embedded
The PSU enters credentials and SCA challenge data directly into the TPP, which relays them to the ASPSP. Used by some Berlin Group implementations; discouraged in the UK model because the TPP touches credentials.
Payment status codes (ISO 20022 style)
| Code | Meaning |
|---|---|
| RCVD | Received — payment initiation accepted by the ASPSP |
| PDNG | Pending — awaiting SCA or processing |
| ACTC | AcceptedTechnicalValidation |
| ACSC | AcceptedSettlementCompleted — funds moved |
| ACSP | AcceptedSettlementInProcess |
| RJCT | Rejected |
Animated walkthrough — step through each flow
A "pay by bank" checkout under PSD2: the PISP creates the payment order over the ASPSP's API, the payer is redirected to their bank for SCA with dynamic linking, and the payment settles as a (usually instant) credit transfer — no card rails involved.
Pay by Bank Selected
PSU chooses account-to-account payment at checkout.
Instead of entering card details, the payer picks their bank. The merchant hands off to its payment-initiation provider — a licensed PISP.