L’authentification forte, un obstacle pour certains services financiers innovants

Depuis quelques semaines et encore davantage depuis l’adoption récente par le Sénat du texte transposant la dernière directive européenne sur les services de paiement (dites DSP2), un climat général de satisfaction règne (à juste titre) mais certains points décisifs sont parfois oubliés. Revenons sur le plus crucial : l’authentification forte du client (SCA pour Strong Customer Authentication en anglais).

Un but légitime : renforcer la sécurité des transactions et la protection des données sensibles

Les modalités de l’authentification forte du client sont définies par les Normes Techniques de Réglementation (RTS) rédigé par l’Autorité Bancaire Européenne et adopté par la Commission Européenne. Le Règlement 2018/389 de la Commission complète donc la DSP2 sur les sujets d’authentification forte et de communications sécurisées entre acteurs.

Revenons très rapidement sur les grands principes de la SCA. Pour effectuer une authentification forte du client, la DSP2 requiert l’utilisation d’au moins deux éléments indépendants parmi la connaissance (mot de passe, pin, …), la possession (mobile, carte, token, …) et l’inhérence (empreinte digitale, reconnaissance faciale ou vocale, …). La DSP2 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 les Third Party Providers (TPP initiateur de paiement et agrégateur 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
  • paiement vers un bénéficiaire sur une liste de « bénéficiaires de confiance »
  • initiation d’un paiement d’un montant inférieur à 30 € et le total des paiements du client ne dépasse pas 100 € depuis la dernière application de l’authentification forte
  • transaction considérée à faible risque (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)

Il y a donc très peu de marge et cela remet en question certains usages déjà établis.

Un frein au taux de conversion et un obstacle majeur au prestataire de services d’information sur les comptes

L’authentification forte est une bonne chose et permettra de réduire le risque de fraude mais elle engendre également des étapes supplémentaires dans le parcours client et donc des frictions pouvant être très problématiques pour des acteurs innovants (fintech) qui prônent la fluidité et la simplicité de leur service.

Introduire la notion de risque dans les exemptions est une excellente chose car effectivement il y a des situations à risques mais d’autres n’en présentent absolument pas. En outre, mettre en place des systèmes de monitoring de la fraude reste relativement compliqué pour des acteurs fintech.

Dans le cas précis des prestataires de services d’informations sur les comptes comme Budget Insight, l’authentification forte est un véritable obstacle et n’a pas de sens car ce service présente un risque faible.

Soyons concret :  effectuer une authentification forte pour initier des paiements nous paraît légitime mais effectuer une authentification forte tous les 90 jours par prestataire de services de paiement gestionnaire de comptes pour autoriser le TPP à 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 qu’il a de banques alors que cela pourrait facilement être mutualisable. Et si 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 rendu possible), il nous semble plus adapté que l’authentification, dans ce cas précis de l’agrégation de comptes, soit gérée par les TPP et qu’elle soit généralisable à toutes les banques de l’utilisateur. En pratique, l’utilisateur final effectue une SCA tous 90 jours (180 jours serait d’ailleurs plus adapté) qui vaut pour toutes les banques qu’il a choisi d’agréger.

Notre message est relativement simple : l’authentification forte est une bonne chose mais elle doit être rendue obligatoire intelligemment et prendre en compte le risque sous jacent à chaque use case et notamment celui d’agrégation de comptes.