Définition
La SCA (Strong Customer Authentication), ou authentification forte, est l'exigence de sécurité centrale de la DSP2.
Pour valider un paiement en ligne, accéder à des données sensibles ou autoriser un TPP, le PSU doit prouver son identité avec au moins deux facteurs indépendants, issus de catégories distinctes.
Les 3 facteurs
La SCA exige 2 facteurs sur 3, chacun d'une catégorie différente :
- Connaissance (what you know) : mot de passe, PIN, réponse secrète.
- Possession (what you have) : téléphone (OTP, push), clé physique, carte.
- Inhérence (what you are) : biométrie — empreinte, visage, voix.
Exemples : PIN + push dans l'appli (connaissance + possession) est valide ; empreinte + téléphone (inhérence + possession) aussi ; mot de passe + question secrète ne l'est pas (deux fois la même catégorie).
Quand la SCA est obligatoire
- À chaque paiement en ligne initié par le PSU.
- À chaque accès d'un AISP aux comptes (tous les 180 jours depuis l'évolution des RTS de 2022, contre 90 auparavant).
- À la première connexion à un service bancaire ou à une nouvelle session.
- Pour toute action sensible : ajout d'un bénéficiaire, virement vers un nouvel IBAN, hausse de plafond.
Les exemptions prévues
Pour ne pas dégrader l'UX, l'EBA prévoit des exemptions que les banques peuvent accorder :
- Faible montant : ≤ 30 € (compteur cumulé à 100 € ou 5 transactions).
- TRA (Transaction Risk Analysis) : possible si le marchand ou la banque a un faible taux de fraude.
- Marchand de confiance : ajouté par le PSU à sa liste blanche.
- Paiement récurrent identique : même montant, même bénéficiaire (SCA à la première occurrence).
- Virement entre comptes du même titulaire chez le même ASPSP.
- Paiement B2B via protocole sécurisé dédié (cartes corporate).
Dynamic Linking
Pour les paiements, la SCA doit inclure le dynamic linking : le code est lié au montant et au bénéficiaire exacts. Si l'attaquant change l'IBAN ou le montant après l'authentification, la transaction est rejetée — ce qui complique fortement les attaques man-in-the-middle.
Dans l'écosystème PSD2
La SCA est mise en œuvre par l'ASPSP (la banque), jamais par le TPP. Le TPP peut la déclencher via différents flux (redirect, decoupled, embedded), mais c'est toujours la banque qui authentifie son client.
Exemples concrets
- Paiement carte en ligne : 3D Secure 2 est l'implémentation dominante. Vous validez par biométrie ou push dans l'appli de votre banque, plutôt que par OTP SMS, car la biométrie convertit mieux.
- Connexion à un AISP : relier Bankin' à votre banque suppose une SCA complète (login + biométrie), à renouveler tous les 180 jours.
- Marchand de confiance : après un premier paiement SCA chez Amazon, l'ajout à la liste blanche supprime la SCA des paiements suivants.
- TRA et conversion : un grand marchand (Cdiscount, Decathlon) investit dans un moteur de risque, souvent via son PSP, pour déclencher l'exemption TRA et maximiser la conversion.
- Côté TPP : un PISP (Fintecture, Bridge, Trustly) doit gérer trois modes SCA — redirect (envoi sur la page banque), decoupled (push pendant que le PSU reste sur le site) et embedded (saisie dans l'interface du TPP, plus rare) — chaque banque en privilégiant un.