Definición
La SCA (Strong Customer Authentication), o autenticación reforzada del cliente, es el requisito de seguridad central de la PSD2.
Para validar un pago en línea, acceder a datos sensibles o autorizar a un TPP, el PSU debe demostrar su identidad con al menos dos factores independientes, procedentes de categorías distintas.
Los 3 factores
La SCA exige 2 factores de 3, cada uno de una categoría diferente:
- Conocimiento (algo que sabes): contraseña, PIN, respuesta secreta.
- Posesión (algo que tienes): teléfono (OTP, push), llave física, tarjeta.
- Inherencia (algo que eres): biometría — huella, rostro, voz.
Ejemplos: PIN + push en la app (conocimiento + posesión) es válido; huella + teléfono (inherencia + posesión) también; contraseña + pregunta secreta no lo es (dos veces la misma categoría).
Cuándo es obligatoria la SCA
- En cada pago en línea iniciado por el PSU.
- En cada acceso de un AISP a las cuentas (cada 180 días desde la modificación de los RTS de 2022, frente a 90 antes).
- En la primera conexión a un servicio bancario o a una nueva sesión.
- Para cualquier acción sensible: añadir un beneficiario, transferir a un nuevo IBAN, subir un límite.
Las exenciones previstas
Para no degradar la UX, la EBA prevé exenciones que los bancos pueden conceder:
- Importe bajo: ≤ 30 € (contador acumulado de 100 € o 5 transacciones).
- TRA (Transaction Risk Analysis): posible si el comercio o el banco tiene una baja tasa de fraude.
- Comercio de confianza: añadido por el PSU a su lista blanca.
- Pago recurrente idéntico: mismo importe, mismo beneficiario (SCA en la primera ocurrencia).
- Transferencia entre cuentas del mismo titular en el mismo ASPSP.
- Pago B2B mediante un protocolo seguro dedicado (tarjetas corporativas).
Dynamic Linking
Para los pagos, la SCA debe incluir el dynamic linking: el código queda vinculado al importe y al beneficiario exactos. Si el atacante cambia el IBAN o el importe tras la autenticación, la transacción se rechaza — lo que dificulta enormemente los ataques man-in-the-middle.
En el ecosistema PSD2
La SCA la implementa el ASPSP (el banco), nunca el TPP. El TPP puede dispararla mediante distintos flujos (redirect, decoupled, embedded), pero siempre es el banco quien autentica a su cliente.
Ejemplos concretos
- Pago con tarjeta en línea: 3D Secure 2 es la implementación dominante. Validas con biometría o push en la app de tu banco, en lugar de un OTP por SMS, porque la biometría convierte mejor.
- Conexión a un AISP: vincular Bankin' a tu banco requiere una SCA completa (login + biometría), a renovar cada 180 días.
- Comercio de confianza: tras un primer pago con SCA en Amazon, añadirlo a la lista blanca elimina la SCA de los pagos siguientes.
- TRA y conversión: un gran comercio (Cdiscount, Decathlon) invierte en un motor de riesgo, a menudo a través de su PSP, para activar la exención TRA y maximizar la conversión.
- Del lado del TPP: un PISP (Fintecture, Bridge, Trustly) debe gestionar tres modos de SCA — redirect (envío a la página del banco), decoupled (push mientras el PSU permanece en el sitio) y embedded (introducción en la interfaz del TPP, más raro) — privilegiando cada banco uno de ellos.