FAQ sur le formulaire de notification à l’ACPR des problèmes affectant les API DSP2

Comment puis-je notifier un problème survenu sur une API DSP2 ?
Les notifications doivent être adressées exclusivement via le formulaire prévu à cet effet. Celui-ci doit être envoyé à l’adresse électronique indiquée. Aucun autre format de notification n’est accepté.

Qui peut soumettre une notification ?
Tout établissement teneur de comptes (PSPGC) ou prestataire de services de paiement (PSP) fournissant ou utilisant une API DSP2 a l’obligation de notifier à l’ACPR les problèmes rencontrés sur une interface dédiée (API).

Dans quelle langue les notifications doivent-elles être rédigées ?
Les notifications doivent être rédigées en français ou exceptionnellement en anglais si l’établissement n’est pas francophone mais une traduction pourra, si nécessaire, être demandée. 

Est-il possible de fournir des pièces jointes en complément du formulaire ?
Des pièces jointes peuvent bien être ajoutées au mail d’envoi, et ce en plus du formulaire (auquel elles ne peuvent en aucun cas se substituer). Elles peuvent contenir des copies d’écran, des messages d’erreur ou tout autre élément permettant d’objectiver la non-conformité de l’API. Les pièces jointes sont limitées à 10 méga-octets.

Y a-t-il un délai pour transmettre une notification ?
L’article 33 paragraphe 3 du règlement délégué UE 2018/389 dispose que la notification doit être effectuée « sans délai ».

Tous les champs du formulaire sont-ils obligatoires ?
Seuls les champs marqués d’un astérisque (*) sont obligatoires. Sans ces informations, l’ACPR ne pourra pas prendre en compte la notification. Il est notamment attendu des déclarants une description précise et étayée du problème constaté sur l’API, en fournissant le plus de détails possible, y compris sur le périmètre concerné.
Les champs facultatifs sont utiles à la compréhension du problème, mais ne sont pas bloquants pour le traitement de la notification.

Quels sont les types de problèmes pouvant être notifiés ?
L’obligation de notification concerne les problèmes décrits au paragraphe 1 de l’article 33 du règlement délégué UE 2018/389. Cela peut notamment inclure : l’existence d’un obstacle non justifié sur le parcours de paiement susceptible de décourager le client, une différence de disponibilité ou de performance entre l’API et l’espace banque en ligne, l’indisponibilité momentanée de l’API ou l’expérience de perturbations, l’absence de système d’authentification forte, la non publication de statistiques trimestrielles sur la disponibilité et le fonctionnement des API, une documentation relative aux API inexistante ou incomplète, un service d’assistance défaillant, une absence de communication sur une opération de maintenance programmée, etc.

L’absence d’API constitue-t-elle une non-conformité ?
L’absence d’API ne constitue pas en soi une non-conformité au sens de la réglementation. En effet, un PSPGC n’est à ce jour pas obligé de fournir une API s’il permet l'utilisation des interfaces servant à l'authentification et à la communication avec les utilisateurs de services de paiement des prestataires de services de paiement gestionnaires de comptes.
En revanche, l’absence de toute interface d’accès sécurisé (via un système d’authentification forte) constitue une non-conformité qu’il convient de signaler.

Y a-t-il une durée minimum de non-fonctionnement d’une API pour considérer qu’il s’agit d’une non-conformité ?
Tout dysfonctionnement d’une API, même de courte durée et ponctuel, doit être notifié à l’ACPR. Toutefois, un dysfonctionnement ne sera pas automatiquement qualifié de non-conformité, si les utilisateurs ont été prévenus suffisamment en amont (notamment pour les opérations de maintenance) et si un mécanisme alternatif d’accès aux données est en place (sauf pour les API exemptées de ces mécanismes « de secours »).

Si un problème sur une API résulte d’une même cause racine qu’un incident de paiement plus large, dois-je déclarer un incident de paiement ou un problème sur l’API ?
Deux notifications sont à distinguer. D’une part, la notification qui doit être faite par le PSPGC ou le PSP fournissant ou utilisant une API DSP2 pour déclarer un problème affectant l’API. D’autre part, celle qui doit être réalisée par l’entité financière en charge de la déclaration sur base individuelle conformément au règlement n° 2022/2554 du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (dit règlement « DORA ») au titre d’un incident majeur lié au TIC ou d’un incident opérationnel ou de sécurité lié au paiement.

Un dysfonctionnement intervenant sur l’API mais impactant également l’espace de banque en ligne est-il une non-conformité ?
Une défaillance touchant les deux canaux, API et banque en ligne, n’exonère pas de la déclaration de non-conformité de l’API.

Que se passe-t-il après l’envoi de la notification à l’ACPR ?
Les notifications sont transmises au service de contrôle en charge de la supervision des établissements fournissant l’API bancaire en cause.
Elles sont traitées dans le cadre du contrôle permanent réalisé par l’ACPR, sur la base des éléments transmis.

À quel type de retour dois-je m’attendre après l’envoi de ma notification ? 
Un accusé de réception est envoyé pour indiquer que la notification a bien été reçue. Si cela est nécessaire à son évaluation, l’ACPR pourra éventuellement contacter l’établissement notifiant ou l’établissement fournisseur de l’API.

Serai-je informé des suites données à ma notification ?
La notification des problèmes relatifs aux API est une obligation pour les acteurs des paiements fournissant et/ou utilisant une API, afin de permettre aux autorités compétentes d’assurer un suivi général du bon fonctionnement des API bancaires en France. Il n’implique pas une information individualisée des déclarants s’agissant des suites données à leur notification.

Que faire si je constate que le problème persiste malgré ma notification ? Puis-je relancer l’ACPR ?
Chaque notification fait l’objet d’un suivi. Il peut arriver que, malgré une demande de remédiation, le problème persiste ou se renouvelle. Dans ce cas, il convient de transmettre une nouvelle notification, en détaillant autant que possible le contexte.