# Flux SCA

> Redirect, Decoupled, Embedded

Los 3 modos de autenticación reforzada previstos por la PSD2. Cada banco privilegia uno u otro, y la elección condiciona directamente la conversión y la experiencia de usuario.

_Categoría: technique_

---

## Definición

Los **flujos SCA** definen cómo un PSU realiza su autenticación reforzada ante su ASPSP, durante un consentimiento PSD o una iniciación de pago.

La PSD2 prevé tres modos — **redirect**, **decoupled**, **embedded** — y cada banco elige cuál ofrece. Para un TPP que quiere cubrir todo el mercado, dominar los tres es indispensable.

## Los 3 modos en resumen

- **Redirect** — el PSU es enviado a la página o la app de su banco para autenticarse y luego vuelve al TPP. El más habitual en Francia.
- **Decoupled** — el PSU permanece en la interfaz del TPP, pero valida la SCA mediante una notificación push en la app de su banco. La UX más fluida.
- **Embedded** — el PSU introduce sus factores de SCA directamente en la interfaz del TPP, que los transmite al banco. El más raro y el menos recomendado.

## Redirect: el estándar de facto

El más extendido, sobre todo en Francia y Alemania. El TPP redirige a la URL de autenticación del ASPSP; el PSU se identifica en la página real de su banco (biometría, SMS, push) y vuelve con un código OAuth2. Ventajas: familiar, responsabilidad clara del lado del banco, integración sencilla. Inconvenientes: salida del contexto del TPP (pérdida de marca), retornos a veces fallidos en móvil (deep links), fricción si la sesión bancaria ha caducado.

## Decoupled: la mejor UX

El TPP dispara la SCA del lado del ASPSP, que envía una notificación push a la app bancaria; el PSU valida con biometría en su teléfono, sin salir del sitio del TPP, que hace polling del estado. Ventajas: mantenimiento del contexto, biometría nativa, sin redirección. Inconvenientes: presupone la app bancaria instalada, gestión más compleja (polling o webhook), soporte desigual según los bancos.

## Embedded: a evitar salvo caso específico

El TPP muestra un formulario para introducir credenciales y factores de SCA, que transmite al banco. Ventaja: ninguna redirección. Grandes inconvenientes: riesgo de phishing (el PSU se acostumbra a introducir sus credenciales fuera de contexto), responsabilidad ambigua, sin biometría y un modo mal visto por los reguladores — la mayoría de los grandes bancos lo rechazan.

## Comparación resumida

| Criterio | Redirect | Decoupled | Embedded |
|---|---|---|---|
| Fluidez de UX | Media | Excelente | Buena |
| Seguridad percibida | Excelente | Excelente | Débil |
| Compatibilidad | Muy amplia | Variable | Muy limitada |
| Móvil nativo | Media (deep links) | Excelente | Buena |
| Esfuerzo de integración | Bajo | Medio | Alto |
| Recomendado | Sí (opción segura) | Sí (si disponible) | No (a evitar) |

## En el ecosistema PSD2

El flujo lo elige el ASPSP, no el TPP. Del lado del TPP hay que detectar dinámicamente el modo o los modos de cada banco y adaptar la integración. Los agregadores (Bridge, Tink, TrueLayer) absorben esta complejidad.

```mermaid
flowchart TB
    PSU["PSU"]
    TPP["TPP\n(Bankin', Fintecture, Pennylane…)"]
    ASPSP["ASPSP (banco)"]
    APP_BANK["App móvil del banco"]

    subgraph REDIRECT["Redirect"]
        R1["Redirige a la página del banco"]
        R2["SCA en la interfaz del banco"]
        R3["Vuelta al TPP"]
    end

    subgraph DECOUPLED["Decoupled"]
        D1["El TPP dispara la SCA en el ASPSP"]
        D2["Notif. push en la app del banco"]
        D3["El PSU valida con biometría"]
        D4["El TPP hace polling del estado"]
    end

    subgraph EMBEDDED["Embedded"]
        E1["El PSU introduce credenciales en el TPP"]
        E2["El TPP transmite al ASPSP"]
        E3["El ASPSP valida o rechaza"]
    end

    TPP --> REDIRECT
    TPP --> DECOUPLED
    TPP --> EMBEDDED
    REDIRECT --> ASPSP
    DECOUPLED --> APP_BANK
    EMBEDDED --> ASPSP
```

## Ejemplos concretos

- **Bancos franceses (redirect)**: BNP Paribas, Société Générale, Crédit Agricole, LCL, BPCE y La Banque Postale privilegian el redirect, con la SCA realizándose en su app mediante push.
- **Neobancos (decoupled)**: N26, Revolut, Boursorama y Hello Bank suelen ofrecer un modo decoupled más fluido, sobre todo en móvil.
- **Caso PISP**: en el checkout, Fintecture debe detectar el banco en cuanto se introduce el IBAN, enrutar al flujo correcto y gestionar el polling en decoupled — de ahí su valor añadido frente a una integración banco por banco.
- **Conversión**: pasar del redirect al decoupled puede ganar de 10 a 15 puntos de conversión en una cesta de comercio electrónico.
- **Caso AISP**: una sola SCA completa en la conexión y, después, 180 días de refresh mediante un token OAuth2 sin nueva SCA.
- **Trampas**: algunos bancos exigen un retardo mínimo antes del polling, otros imponen un webhook — leer la documentación de cada ASPSP es obligatorio.
- **Evolución PSR**: el banco solo aplicará su SCA en el primer acceso de un AISP, y después será el propio AISP quien haga una SCA al menos cada 180 días (art. 86). Un banco no podrá exigir dos SCA en un mismo flujo de iniciación (art. 44(1)(l)) ni añadir pasos respecto a su canal directo (art. 44(1)(j)). El PISP elegirá el procedimiento de autenticación cuando el banco ofrezca varios (art. 36(4)(ha)). Texto aún no adoptado, numeración provisional del compromiso de abril de 2026.

## Fuentes

- [Commission Delegated Regulation (EU) 2018/389 (RTS SCA & CSC)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R0389) — EUR-Lex
- [Berlin Group NextGenPSD2 — XS2A Framework](https://www.berlin-group.org/nextgenpsd2-downloads) — Berlin Group

---

Fuente: https://openfinanceguide.com/es/glossary/sca-flows