DSP2 : l’importance d’APIs fonctionnelles et performantes

Dans le cadre de l’entrée en vigueur de la DSP2 et conformément aux normes techniques de réglementation (NTR) de l’Autorité Bancaire Européenne (EBA), les prestataires de services de paiement gestionnaires de comptes (principalement les banques, désignées par le terme ASPSP pour Account Servicing Payment Service Providers) doivent développer et maintenir des interfaces de communication sécurisées (souvent désignées par le terme API pour Application Programming Interface) permettant aux TPPs (Third Party Payment Services Providers), comme les agrégateurs d’informations sur les comptes ou les initiateurs de paiement, d’accéder aux données dont ils ont besoin pour proposer leurs services innovants.

Le développement de ces APIs par les banques elles-mêmes inquiète les TPPs qui craignent des APIs aux fonctionnalités (volontairement ?) limitées et aux performances insuffisantes. C’est notamment pour cette raison qu’elles ont milité auprès de la Commission Européenne pour la possibilité d’une mesure d’urgence sous la forme d’un mécanisme de secours (reposant sur le screen-scraping) dans le cas où ces APIs seraient indisponibles ou insuffisamment performantes.

Malgré les réserves de l’EBA, ce mécanisme de secours a été maintenu mais les autorités nationales seront habilitées à exempter les banques de l’obligation de prévoir ce mécanisme si « des conditions strictes sont remplies, garantissant que les interfaces dédiées ouvrent réellement le marché des services de paiement« . En pratique, les APIs mises à disposition par les banques seront testées par les TPPs et contrôlées par les autorités compétentes.

Dans la continuité, l’alliance Future of European Fintech a publié les critères et fonctionnalités que devraient satisfaire les APIs des banques pour garantir l’essence de la DSP2, qui est l’ouverture du marché des services de paiement, la stimulation de l’innovation et de la concurrence. Les voici :

• Possibilité pour les TPPs de s’appuyer sur les méthodes d’authentification proposées par les ASPSP aux utilisateurs finaux.

• Authentification forte propre à l’initiation de paiement.

• L’utilisateur final ne doit être redirigé vers une interface de l’ASPSP à aucun moment de la cinématique.

• Une authentification au moment de la connexion doit permettre à l’utilisateur final d’avoir accès à la fois aux services d’initiation de paiement et aux services d’informations sur les comptes.

• Dès la première authentification forte, l’API doit rendre disponible les numéros des comptes bancaires, les soldes, le nom, le numéro personnel / de sécurité sociale (le cas échéant), l’adresse, la date et le lieu de naissance de l’utilisateur final.

• Lors de l’initiation d’un paiement, l’API doit rendre disponibles (temps réel ou mode batch) les informations relatives à la bonne exécution du virement et au solde disponible (solde du compte, limite de découvert et les transactions en attente).

• L’API doit prendre en charge tous les types de paiements disponibles (y compris les faster payments, les paiements à l’étranger, les prélèvements automatiques, etc.).

• Pour les services d’informations sur les comptes, l’API doit fournir les mêmes informations que celles rendues disponibles sur les espaces clients en ligne des ASPSP. Le même niveau de détails doit être respecté.

• Pour chaque compte de paiement, l’API doit fournir au minimum : numéro de compte ou IBAN, le type de compte, le solde, les fonds disponibles (fonction des transactions en attente et des limites de découvert), la devise, le nom du compte (nom du produit), la date d’ouverture du compte, la liste des titulaires du compte (notamment si le titulaire du compte est une organisation (société, association, etc.) ou une personne physique et si ce compte bancaire est un compte joint), le nom complet, l’adresse complète, le numéro d’identification du gouvernement, le numéro d’identification fiscale et le numéro de téléphone.

• Pour chaque transaction initiée, l’API doit fournir au minimum : la date de la transaction, la date de comptabilisation de l’opération, le montant, le solde (après transaction), la devise, l’IBAN de la deuxième partie à la transaction, l’objet, le type de transaction tel que défini par la banque (paiement par carte, transfert entrant, frais bancaires, intérêts, etc.), le Merchant Category Code – MCC (pour les paiements par carte).

• Les cartes de crédit et les comptes similaires doivent être visibles dans l’API. Les transactions traitées sur une carte de crédit doivent être visibles sur l’API dès qu’elles sont visibles sur l’espace en ligne des ASPSP (jusqu’à 30 jours avant la date de valeur de la transaction).

• L’accès aux comptes d’épargne et aux crédits doit également être pris en compte, y compris l’historique des transactions pour les produits tels que les prêts et les produits d’investissement par exemple.

• L’API doit fournir l’accès à la liste des bénéficiaires avec les détails (au moins l’IBAN complet et le nom).

• L’API doit permettre l’ajout ou la suppression d’un bénéficiaire.

• L’API devrait permettre la création de paiements récurrents telle que l’offre aujourd’hui les espaces en ligne des ASPSP.

• L’API doit permettre l’accès à plus de 90 jours d’historique des transactions avec une authentification forte unique lors de la cinématique d’accès.

• L’API doit avoir le même niveau de disponibilité et de performance (temps de disponibilité, rapidité, temps de réponse) que les API utilisées par les ASPSP vis-à-vis de leurs propres clients.

• L’API ne doit pas permettre l’annulation d’un paiement initié (avant son exécution).

• L’API doit s’assurer que l’ASPSP applique les mêmes exemptions à l’authentification forte que celles appliquées dans leurs espaces clients propres.

• Le consentement est donné par l’utilisateur final au TPP ; le consentement ne doit pas être donné en plus à l’ASPSP. L’API ne doit pas exiger de vérifications supplémentaires du consentement donné par l’utilisateur au TPP.

• L’API doit proposer une liste de tous les comptes de paiement disponibles à l’utilisateur pour que le TPP puisse gérer le consentement directement avec l’utilisateur. L’utilisateur ne doit pas s’attendre à taper les numéros de compte pour les désigner au TPP.

• L’API ne doit pas déconnecter l’accès aux données aux prestataires de services d’informations sur les comptes tous les 90 jours pour demander une authentification forte à l’utilisateur car cela les empêche de fournir des fonctionnalités telles que des alertes sur les soldes et les transactions alors que cela est encore possible sur les interfaces des ASPSP.

• Les prestataires de services d’informations sur les comptes devraient être en mesure d’initier et de gérer les cinématiques d’identification forte de l’utilisateur sur leurs propres interfaces tous les 90 jours lorsque l’utilisateur se connecte à ses interfaces. Par la suite, le système de comptage de 90 jours doit être remis à 0 automatiquement.

• Le système de comptage de jours doit être mutualisé entre l’ASPSP et le TPP. Cela signifie qu’à chaque authentification forte, qu’elle soit effectuée sur l’interface de l’ASPSP ou du TPP, le système de comptage de 90 jours est réinitialisé à 0.

Il est intéressant de souligner la demande d’accès aux comptes d’épargne et aux crédits qui est essentiel notamment pour les fintech proposant des services de coaching financier. Un service basé uniquement sur les comptes de paiement serait totalement dénué d’intérêt.

Cette liste exhaustive de fonctionnalités doit donc permettre de garantir un niveau de service suffisant aux TPPs pour qu’ils puissent continuer d’exercer sereinement. L’enjeu est crucial et il sera intéressant de voir comment les autorités nationales et les banques appréhenderont et réagiront à cette liste.