Definition
SCA flows define how a PSU completes strong customer authentication with their ASPSP, during a PSD consent or a payment initiation.
PSD2 sets out three modes — redirect, decoupled, embedded — and each bank chooses which it offers. For a TPP looking to cover the whole market, mastering all three is essential.
The 3 modes at a glance
- Redirect — the PSU is sent to their bank's page or app to authenticate, then returns to the TPP. The most common in France.
- Decoupled — the PSU stays within the TPP's interface but approves SCA via a push notification in their bank's app. The smoothest UX.
- Embedded — the PSU enters their SCA factors directly in the TPP's interface, which passes them to the bank. The rarest and least recommended.
Redirect: the de facto standard
The most widespread, especially in France and Germany. The TPP redirects to the ASPSP's authentication URL; the PSU identifies themselves on their bank's real page (biometrics, SMS, push), then returns with an OAuth2 code. Pros: familiar, clear liability on the bank's side, simple to integrate. Cons: leaving the TPP context (loss of brand), sometimes failed returns on mobile (deep links), friction if the banking session has expired.
Decoupled: the best UX
The TPP triggers SCA on the ASPSP's side, which sends a push notification to the banking app; the PSU approves with biometrics on their phone, without leaving the TPP's site, which polls for the status. Pros: keeps context, native biometrics, no redirection. Cons: assumes the banking app is installed, more complex handling (polling or webhook), uneven support across banks.
Embedded: to be avoided except in specific cases
The TPP shows a form to enter credentials and SCA factors, which it passes to the bank. Pro: no redirection. Major cons: phishing risk (the PSU gets used to entering credentials out of context), ambiguous liability, no biometrics, and a mode frowned upon by regulators — most large banks refuse it.
Summary comparison
| Criterion | Redirect | Decoupled | Embedded |
|---|---|---|---|
| UX smoothness | Medium | Excellent | Good |
| Perceived security | Excellent | Excellent | Weak |
| Compatibility | Very broad | Variable | Very limited |
| Native mobile | Medium (deep links) | Excellent | Good |
| Integration effort | Low | Medium | High |
| Recommended | Yes (safe default) | Yes (if available) | No (avoid) |
In the PSD2 ecosystem
The flow is chosen by the ASPSP, not the TPP. On the TPP side, you must dynamically detect each bank's mode(s) and adapt the integration. Aggregators (Bridge, Tink, TrueLayer) absorb this complexity.
Concrete examples
- French banks (redirect): BNP Paribas, Société Générale, Crédit Agricole, LCL, BPCE and La Banque Postale favour redirect, with SCA happening in their app via push.
- Neobanks (decoupled): N26, Revolut, Boursorama and Hello Bank often offer a smoother decoupled mode, especially on mobile.
- PISP case: at checkout, Fintecture must detect the bank as soon as the IBAN is entered, route to the right flow and handle polling in decoupled — hence its added value over a bank-by-bank integration.
- Conversion: moving from redirect to decoupled can win 10 to 15 conversion points on an e-commerce basket.
- AISP case: a single full SCA at connection, then 180 days of refresh via an OAuth2 token without re-SCA.
- Pitfalls: some banks require a minimum delay before polling, others impose a webhook — reading each ASPSP's docs is mandatory.
- PSR / PSD3 evolution: tighter flow-quality requirements and equal treatment between a bank's own customers and TPP customers, ending some discriminatory practices.