La mise en place de l’authentification forte doit se faire de façon coordonnée et progressive

Mise en place des APIs et des “fallbacks”

Les APIs que doivent créer les banques dans le cadre de la DSP2 ne seront certainement pas prêtes au 14 septembre. Nous vous avons expliqué dans cet article pourquoi. Ces APIs doivent nous permettre de récupérer les données des utilisateurs auprès des banques de façon souple et sécurisée pour garantir aux utilisateurs une expérience de très haute qualité.

Lorsque l’API n’est pas prête ou fonctionnelle, la banque doit mettre en place une “fallback”. Les fallbacks sont les interfaces en ligne des banques que les TPP (Third Party Provider comme Bridge) peuvent utiliser comme alternative dans le cas où l’API n’est pas disponible ou pas au niveau de qualité attendue. Dans les cas où les API ne sont pas prêtes au 14 Septembre, ces fallbacks doivent être documentées et fournies au moins 6 mois à l’avance afin que les TPP puissent adapter leurs interfaces et opérer les migrations de la base utilisateurs.

Or, aujourd’hui les fallbacks ne sont bien souvent ni identifiées, ni documentées à date. Ceci explique également qu’au 14 septembre, nous continuerons certainement à utiliser les interfaces existantes et fonctionnelles en place aujourd’hui de manière extrêmement transitoire jusqu’au moment où les API ou les fallbacks seront prêtes.

Qu’est-ce que l’authentification forte ?

En parallèle, les banques doivent — pour être conforme aux standards techniques de la DSP2 (les RTS)— implémenter l’authentification forte pour l’accès aux comptes depuis les interfaces qu’elles mettent à disposition de leurs propres clients.

L’authentification est une action qui permet de valider l’authenticité et, pour un système informatique, elle consiste à vérifier que la personne est bien l’ayant droit afin d’autoriser l’accès à des ressources.

L’authentification peut se baser sur 3 facteurs distincts :

1. Quelque chose que l’on sait et le mot de passe en est le meilleur exemple;
2. Quelque chose que l’on a comme une clé ou un carte d’identification;
3. Quelque chose que l’on est comme une empreinte digitale ou un visage.

L’authentification forte consiste à combiner au moins deux de ces facteurs d’authentification.

Mise en place de l’authentification forte dans ce contexte

A date, nous ne savons bien souvent pas encore quelle authentification forte va être demandée sur les interfaces (APIs et fallbacks) développées par les banques. La mise en place de l’authentification forte n’a souvent pas encore été documentée et nous n’avons pas d’environnement de tests pour gérer ces nouveaux systèmes.

Les régulateurs nationaux, la Commission Européenne et l’EBA (European Bank Association) ont pris conscience du problème. Au niveau français et européen, il a été demandé aux banques et aux TPP (comme Bridge) de collaborer pour trouver une solution.

• En France, c’est l’AFEPAME (dont Joan Burkovic, notre CEO et co-fondateur est membre du conseil d’administration) qui a réuni banques et TPP autour de la table pour trouver des solutions.
• En Europe, c’est la Commission Européenne qui a demandé aux associations bancaires et à l’association des TPP (ETTPA, dont Bridge est membre fondateur et Joan Burkovic au conseil d’administration) de trouver des solutions à l’échelle européenne.

Une mise en place non coordonnée avec les TPP et non progressive de l’authentification forte sur les interfaces en ligne des banques alors que les APIs ne sont pas prêtes, aurait des conséquences très négatives sur les utilisateurs en premier lieu, l’activité des banques et des TPP :

• Envoi de millions d’OTP (one time password), qui peuvent être des SMS ou des mails par exemple, auprès des utilisateurs à n’importe quel moment de la journée sans qu’ils n’en comprennent la provenance. En effet à chacune de nos tentatives de connexion, un OTP serait envoyé. Les utilisateurs risquent de penser à un piratage ou à du phishing. Cela engendrerait donc des inquiétudes très importantes, beaucoup de contacts envers les services clients des banques, de nos partenaires et des TPPs ainsi qu’un risque d’image pour ces derniers.
• Cela bloquerait aussi totalement les connexions des TPP, ce qui est parfaitement contraire aux principes de la DSP2.

Forts de ces constats, banques et TPP travaillent ensemble à plusieurs solutions :

• Décaler la date de mise en place de l’authentification forte afin de pouvoir la mettre en place de façon coordonnée et progressive.
• Documentation par la banque du mécanisme d’authentification forte qu’elle va mettre en place afin que nous puissions tester et développer les mécanismes qui garantiront une bonne expérience utilisateur.
• Donner plus de temps aux banques pour développer des APIs de qualité en collaboration avec les TPP.

Garantir la continuité de nos services

La Commission Européenne a rappelé qu’il est du devoir pour les régulateurs nationaux d’assurer la continuité des services des TPP sans dégradation. Nous faisons pleinement confiance à nos régulateurs nationaux dans la réalisation de cette mission essentielle. Voici un extrait du rappel publié par la Commission Européenne :

The Commission will be particularly vigilant in monitoring this
transition, ensuring that all players, including NCAs, play their
full role and assume their responsibilities. The Commission will
also expect that the interfaces (including APIs and possible
contingency ‘fallback’ interfaces) which the banks will have to
put in place on 14 September are fully up to the required
standards, not creating obstacles and ensuring at least full
business continuity from third party providers (TPP) wishing to
avail themselves of their new rights. The Commission expects
NCAs to enforce these rights, which contribute to achieving the
objectives of the PSD2 in terms of innovation and competition

*NCAs: acronyme représentant les régulateurs nationaux

D’où viennent ces informations ?

Joan Burkovic, notre CEO et co-fondateur est membre de différentes associations et groupes de travail qui sont au coeur de la mise en place des standards techniques de la DSP2 (également appelés RTS). Cela permet à Bridge de garder un temps d’avance pour aiguiller ses partenaires sur la mise en conformité réglementaire. Dans nos articles, nous vous faisons un compte-rendu exclusif des avancées de ces travaux.

Pour en savoir plus sur Bridge et essayer nos solutions, cliquez ici.

No worries, here is the English version:

Implementation of APIs and fallbacks

The APIs that banks are required to create as part of the PSD2 will certainly not be ready by September 14. We have explained in this article why. These APIs should allow us to collect user data from banks in a flexible and secure way to ensure a very high quality user experience.

When the API is not ready or functional, the bank must set up a “fallback”. Fallbacks are the online interfaces of banks that TPPs (Third Party Providers such as Bridge) can use as an alternative in case the API is not available or not at the expected quality level. In cases where the APIs are not ready by September 14, these fallbacks must be documented and provided at least 6 months in advance so that TPPs can adapt their interfaces and migrate the user base.

However, today fallbacks are often neither identified nor documented. This also explains why, on September 14, we will certainly continue to use the existing and functional interfaces in place today in an extremely transient way until the APIs or fallbacks are ready.

What is strong authentication?

In parallel, banks must — to comply with the PSD2 technical standards (RTSs) — implement strong authentication for accessing accounts from the interfaces they make available to their own customers.

Authentication is an action that validates authenticity and, for a computer system, it consists in verifying that the person is indeed the rightful owner in order to authorize access to resources.

Authentication can be based on 3 distinct factors:

1. Something we know, the password is the best example;
2. Something we have, like a key or an identification card;
3. Something that we are, like a fingerprint or a face ID.

Strong authentication consists of combining at least two of these authentication factors.

Implementation of strong authentication in this context

Today, we often do not yet know which strong authentication will be required on the interfaces (APIs and fallbacks) developed by banks. The implementation of strong authentication has often not yet been documented and we do not have a test environment to handle these new systems.

National regulators, the European Commission and the European Bank Association (EBA) have become aware of the problem. At the French and European level, banks and TPPs (such as Bridge) have been asked to work together to find a solution.

• In France, it was AFEPAME (in which Joan Burkovic, our CEO and co-founder, is a member of the Board of Directors) that brought banks and TPPs together around the table to find solutions.
• In Europe, it was the European Commission that asked the banking associations and the TPPs association (ETTPA, of which Bridge is a founding member and Joan Burkovic on the Board of Directors) to find solutions at the European level.

A non-coordinated implementation with TPPs and a non-progressive implementation of strong authentication on banks’ online interfaces, while APIs are not ready, would have very negative consequences on users in the first place, the activity of banks and TPPs:

• Sending millions of OTPs (one time password), which can be SMS or emails for example, to users at any time of the day without them understanding where they come from. Indeed, each time we try to connect, an OTP would be sent. Users may suspect of hacking or phishing. This would therefore generate very significant worries, a lot of contacts with the customer services of banks, our partners and TPPs, as well as a risk of image for all three.
• It would also completely block the connections of the TPPs, which is completely contrary to the principles of the PSD2.

This is regarding these firsthand findings, banks and TPPs are working together on several solutions:

• Postpone the date of implementation of strong authentication in order to be able to implement it in a coordinated and progressive manner.
• Documentation by the bank of the strong authentication mechanism it will set up so that we can test and develop the mechanisms that will guarantee a good user experience.
• Give banks more time to develop quality APIs in collaboration with TPPs.

Guaranteeing the continuity of our services

The European Commission recalled that it is the duty of national regulators to ensure the continuity of TPPs services without degradation. We have full confidence in our national regulators to carry out this essential mission. Here is an extract from the reminder published by the European Commission:

The Commission will be particularly vigilant in monitoring this
transition, ensuring that all players, including NCAs, play their
full role and assume their responsibilities. The Commission will
also expect that the interfaces (including APIs and possible
contingency ‘fallback’ interfaces) which the banks will have to
put in place on 14 September are fully up to the required
standards, not creating obstacles and ensuring at least full
business continuity from third party providers (TPP) wishing to
avail themselves of their new rights. The Commission expects
NCAs to enforce these rights, which contribute to achieving the
objectives of the PSD2 in terms of innovation and competition

*NCAs: acronym representing national regulators

Where does this information come from?

Joan Burkovic, our CEO and co-founder, is a member of various associations and working groups that are at the heart of the implementation of the PSD2. This allows Bridge to stay one step ahead to guide its partners in regulatory compliance. In our articles, we give you an exclusive report on the progress of this work.

To know more about Bridge and try our solutions, clic here.