Depuis plusieurs mois, un climat général de satisfaction règne à propos de la 2e directive sur les services de paiement (DSP 2), mais certains points décisifs sont parfois oubliés. Le plus crucial étant clairement l’authentification forte du client (en anglais, Strong Customer Authentication – SCA), qui met à mal la fluidité des parcours clients. L’objectif avancé de renforcer la sécurité des transactions et la protection des données sensibles est tout à fait légitime, mais ne doit pas se faire au détriment complet des parcours utilisateurs.
Les modalités de l’authentification forte du client sont définies par les normes techniques de réglementation (RTS), rédigées par l’Autorité bancaire européenne et adoptées par la Commission européenne. Elles composent le Règlement délégué 2018/389 de la Commission, qui complète donc la DSP 2, sur les sujets d’authentification forte et de communications sécurisées entre acteurs.
Connaissance, possession, inhérence
Revenons très rapidement sur les grands principes de la SCA. Pour effectuer une authentification forte du client, la DSP 2 requiert l’utilisation d’au moins deux éléments indépendants relevant de la connaissance (mot de passe, pin, etc.), de la possession (mobile, carte, token, etc.) et de l’inhérence (empreinte digitale, reconnaissance faciale ou vocale, etc.). La DSP 2 insiste également sur l’utilisation d’un mécanisme pour lier dynamiquement la transaction à un montant spécifique et un bénéficiaire spécifique.
Cette authentification doit être appliquée par tous les acteurs y compris par les prestataires tiers (Third Party Providers – TPP), initiateurs de paiement et agrégateurs de comptes.
Quelques exemptions existent mais restent très limitées. Voici les principaux cas pour lesquels l’authentification forte n’est pas obligatoire :
- une série de paiements récurrents pour le même montant au même bénéficiaire ;
- un paiement vers un bénéficiaire figurant sur une liste de « bénéficiaires de confiance » ;
- l'initiation d’un paiement d’un montant inférieur à 30 euros et si le total des paiements du client ne dépasse pas 100 euros depuis la dernière application de l’authentification forte ;
- une transaction considérée à faible risque, c'est-à-dire si le taux de fraude du prestataire de services de paiement ne dépasse pas les seuils – très bas – fixés par le Règlement européen.
La simplicité du parcours, clé du succès pour les jeunes acteurs
Il existe donc très peu de marge, et cela remet en question certains usages déjà établis.
En tant que TPP, nous nous rendons bien compte, chez Budget Insight, que la SCA constitue un frein au taux de conversion, ainsi qu'un obstacle majeur pour les différents usages que nous avons pu développer avec certains de nos clients.
Sur le fond, nous sommes d’accord sur le fait que l’authentification forte est une bonne chose et qu'elle permettra de réduire le risque de fraude. Mais elle engendrera également des étapes supplémentaires dans le parcours client, et donc des frictions pouvant devenir très problématiques pour des acteurs innovants comme les FinTechs, qui prônent la fluidité et la simplicité de leur service.
En effet, la simplicité du parcours est LE facteur clé de succès des acteurs innovants. C’est ce qui drive une croissance forte dans les usages et les innovations qu’ils portent. Chaque étape supplémentaire dans le parcours, imposée par le régulateur, les banques ou les autres « services de paiement gestionnaires du compte » (Account Servicing Payment Service Providers – ASPSP) met en danger le modèle économique d’acteurs encore jeunes. Il s’agit donc d’être extraordinairement vigilant.
Un service d’agrégation de comptes quasiment inutilisable !
Introduire la notion de risque dans les exemptions d'authentification forte était une excellente chose : effectivement, il y a des situations à risques et d’autres qui n’en présentent absolument pas. Mettre en place des systèmes de monitoring de la fraude reste relativement compliqué pour des acteurs FinTechs tels que nous.
Dans le cas précis des prestataires de services d’informations sur les comptes (Account Information Services – AIS) comme Budget Insight, l’authentification forte récurrente est un véritable obstacle et n’a pas de sens, car ce service présente un risque faible.
Soyons concrets : effectuer une authentification forte pour initier des paiements nous paraît légitime mais effectuer une authentification forte tous les 90 jours, pour chaque prestataire de services de paiement gestionnaire de comptes (ASPSP), pour autoriser le prestataire tiers à accéder aux comptes de paiement n’a pas de justification crédible.
L’utilisateur du service d’agrégations de comptes devra effectuer, tous les 90 jours, autant d’authentifications fortes que de banques dont il est client, alors que cette opération pourrait facilement être mutualisable. Et s’il décide de présenter plus de 90 jours d’historique, il devra effectuer systématiquement une SCA. Cela rend le service d’agrégation de comptes quasiment inutilisable !
Le risque sous-jacent étant très faible, car seule la consultation en lecture des comptes est rendue possible, une solution plus adaptée serait que l’authentification, dans le cas précis de l’agrégation de comptes, soit gérée par les prestataires et qu’elle soit généralisable à toutes les banques de l’utilisateur. L’utilisateur final effectuerait alors une SCA tous les 90 jours – 180 jours serait d’ailleurs une échéance plus adaptée – qui vaudrait pour toutes les banques qu’il a choisi d’agréger. D'ailleurs, d’autres protocoles comme EBICS (Electronic Banking Internet Communication Standard) donnent mandat sans limitation de temps.
À quand une solution d'authentification déléguée aux TPP ?
C’est pourquoi nous militons fortement pour trouver une solution d'authentification déléguée aux TPP. Nous sommes d’accord pour être redirigés sur les interfaces des ASPSP pour une première synchronisation, mais souhaitons que le renouvellement des 90 jours soit totalement géré par nos soins. Des solutions telles que celles de FIDO Alliance nous intéressent tout particulièrement, car elles proposent des mécanismes d’authentification déléguée.
De plus, aucun texte réglementaire ne s’oppose à l’authentification déléguée. L’ASPSP peut tout à fait décider de confier l'authentification forte au prestataire tiers et se décharger de sa responsabilité. Porter le (faible) risque lié à ce renouvellement de consentement ne dérangerait absolument pas les prestataires tiers que nous sommes.
L’authentification forte par redirection, telle qu’elle est imaginée par les ASPSP, est totalement incompatible avec le paiement en proximité, puisqu’elle engage dans un process beaucoup plus lourd qu’un paiement par carte par exemple. Ce type de use case montre clairement l’obstacle à l’innovation pour le client que représentent les choix techniques actuels.
Notre message est relativement simple : l’authentification forte est une bonne chose, mais elle doit être rendue obligatoire intelligemment et prendre en compte l'importance du risque sous-jacent à chaque use case, notamment celui d’agrégation de comptes.
