Les APIs sont entrées dans le monde bancaire avec la DSP2, la Directive européenne sur les paiements. Lesquelles sont obligatoires ? Comment assurer la mise en conformité de l’API DSP2? Peut-on l’accélérer ? Nous vous donnons toutes les clés de réponse dans cet article.
Quelles sont les obligations liées aux APIs DSP2 ?
Pourquoi la DSP2 a-t-elle été mise en place ?
Pour commencer, faisons un rappel rapide concernant la DSP2. Il s’agit de la deuxième Directive européenne sur les paiements. Elle date de 2015 et abroge la DSP1 qui existait jusqu’alors. Son but est d’ouvrir le marché bancaire, en permettant la transmission des données bancaires vers des acteurs tiers.
Pourquoi la DSP2 a-t-elle été mise en place ?
Le marché bancaire était presque exclusivement réservé aux grandes banques, avec peu de concurrence. A partir des années 2010, de nombreux services bancaires “hors banques” ont commencé à se développer. Proposés par des startups qu’on appelle fintech – pour finance et technologie – ces services bancaires nouvelle génération se concentrent sur l’expérience utilisateur, tout en satisfaisant des besoins clients laissés de côté par les banques historiques.
Face à cette ébullition, et pour répondre à un triple enjeu : permettre l’essor des nouveaux services financiers, renforcer la sécurité des paiements en ligne et protéger les consommateurs, la Commission européenne a décidé de légiférer. La DSP2 est née en 2015 et a progressivement été mise en place à partir de 2018. En 2020, la directive est pleinement entrée en vigueur.
Comment se fait l’ouverture des données bancaires ?
La DSP2 a introduit une nouvelle notion : l’Open Banking. Cela désigne cette fameuse ouverture de l’écosystème bancaire. Pour la rendre possible, ce sont des APIs DSP2, encore appelées APIs Open Banking, qui sont utilisées. Ces interfaces de programmation permettent de faire communiquer deux programmes informatiques entre eux. Grâce à elles, les données bancaires sont récupérables par d’autres acteurs financiers, comme les fintech, qui peuvent alors les exploiter pour proposer des services bancaires innovants.
Qui est concerné par la DSP2 ?
Les premières concernées par la DSP2 sont les banques. Ce sont à elles de proposer les APIs Open Banking pour que des acteurs tiers, les TPP (Third Party Providers), puissent avoir accès à leurs données clients. La modernisation des services bancaires induite par la DSP2 leur est également favorable : elles peuvent utiliser les APIs en interne pour accélérer leur transformation digitale et exploiter efficacement les données dont elles disposent.
Quelles sont les obligations pour les APIs DSP2 ?
La directive sur les paiements demande aux banques de développer a minima 3 API DSP2 pour être en conformité. Quelles sont-elles ?
– L’API DSP2 d’agrégation bancaire : elle permet de collecter toutes les données bancaires d’un client dans une même interface, même en cas de comptes bancaires multiples. Plus besoin de se connecter individuellement sur chaque interface bancaire. Cette API peut être utilisée par les acteurs financiers agréés en tant qu’AISP (Account Information Service Providers).
– L’API DSP2 d’initiation de paiement : elle permet d’envoyer une demande de virement Open Banking sans quitter son parcours de paiement. Elle est utilisée pour les e-commerces par exemple, pour payer ses fournisseurs directement dans son logiciel dédié ou encore pour payer les salaires par lot dans son logiciel RH. Cette API peut être utilisée par les acteurs financiers agréés en tant que PISP (Payment Initiation Service Provider).
– L’API DSP2 de consultation de solde : elle permet de consulter automatiquement le solde d’un compte avant qu’un paiement soit validé.
Par ailleurs, afin d’être en conformité, les banques doivent proposer un système d’authentification forte, afin de renforcer la sécurité des paiements en ligne. Le 31 décembre 2020 est la date butoire pour proposer un système d’authentification à double facteur (sauf exemptions). Le code par SMS a vocation à disparaître, au profit de systèmes plus perfectionnés. Il a cependant encore de beaux jours devant lui, puisqu’il peut être utilisé jusqu’à fin 2022 au plus tard.
Comment assurer la conformité de ses API DSP2 ?
Obligations de sécurité et reporting introduits par la DSP2
Il existe tout un volet technique dans la DSP2. Les RTS (Regulatory Technical Standards), les normes techniques à respecter, ont été publiées en mars 2018. Depuis, tous les prestataires de service de paiement sont tenus de s’y conformer, pour proposer des APIs valides ainsi que la sécurisation des paiements. Ils doivent transmettre aux autorités de tutelle des reportings réguliers pour attester de leur conformité aux textes de loi.
5 types de reportings sont attendus, 3 dérivant directement de la DSP2, 2 autres des RTS.
– Le premier est évoqué à l’article 95, paragraphe 2 : “les États membres veillent à ce que les prestataires de services de paiement fournissent à l’Autorité compétente, chaque année ou à des intervalles plus rapprochés fixés par l’Autorité compétente, une évaluation à jour et exhaustive des risques opérationnels et de sécurité liés aux services de paiement qu’ils fournissent et des informations sur le caractère adéquat des mesures d’atténuation et des mécanismes de contrôle mis en œuvre pour faire face à ces risques”.
– Le second est défini par l’article 96, paragraphe 1 : “en cas d’incident opérationnel ou de sécurité majeur, les PSP informent sans retard injustifié l’Autorité compétente dans l’État membre d’origine du prestataire de services de paiement”.
– Le troisième, à l’article 96, paragraphe 6, indique : “les États membres veillent à ce que les PSP fournissent à leurs Autorités compétentes, au moins chaque année, des données statistiques relatives à la fraude liée aux différents moyens de paiement”.
– Le quatrième reporting attendu provient des RTS, comme les deux suivants. Il concerne l’obligation d’authentification forte. Les prestataires de services de paiement doivent prouver qu’ils déploient les mesures de sécurité requises dans un rapport d’examen (protection de la confidentialité et de l’intégrité des données).
– Le cinquième reporting attendu concerne les exemptions d’authentification forte. Les PSP doivent tenir un registre de toutes les fois où la dérogation est mise en œuvre, les fraudes associées ainsi que les taux de fraude liés aux paiements par carte et par virement (et s’assurer qu’ils sont inférieurs aux seuils fixés).
Accélérer la conformité de ses APIs DSP2 avec Bridge
Les textes prévoient donc précisément toutes les obligations de sécurité et de reporting. Les mettre en œuvre peut être plus compliqué, c’est pourquoi Bridge peut aider les acteurs bancaires à développer des APIs DSP2 conformes. Nous le faisons de deux façons :
– Nous avons noué un partenariat avec Fime afin d’aider les banques à accélérer les tests fonctionnels et de sécurité de leurs APIs Open Banking. Grâce à cette plateforme API testing, Fime est en mesure de tester automatiquement les APIs des banques. Le but : valider leur conformité avec les directives européennes, les RTC d’une part, ainsi que les standards Berlin Group et STET.
– Nous proposons également à nos clients de développer leur propre environnement de test des APIs DSP2 grâce à la technologie Bridge.
La conformité avec la DSP2 n’est plus une option : la directive étant pleinement entrée en vigueur, il est nécessaire pour tous les acteurs bancaires d’être conformes DSP2. Les processus de validation des APIs peuvent être complexes à développer, c’est pourquoi Bridge propose à ses clients d’accélérer leur transition vers l’Open Banking.
