Migration ISO dans les paiements internationaux – un appel au réveil

Dans le monde entier, les systèmes de paiement passent à la norme ISO 20022 UNIFI (universal financial industry message scheme). Dans la zone euro, ce processus a commencé avec l’introduction de SEPA en 2007. En novembre prochain, la transition sera également effective pour les paiements individuels et internationaux. Le monde financier compte beaucoup sur cette transition. Dans une enquête menée par msgGillardon et Unifits, 99 % des experts interrogés considèrent la migration ISO comme très ou plutôt positive. En effet, la nouvelle norme offre de nombreux avantages, une fois qu’elle sera prise en charge de manière aussi généralisée que possible.

Le sujet n’est donc pas nouveau et pourtant le chemin est difficile et l’introduction a dû être reportée à plusieurs reprises. Sur ce point, l’Eurosystème de la Banque centrale européenne mise sur une approche de big bang, tandis que SWIFT prévoit une phase de coexistence de trois ans des formats MT et MX pour les transactions financières mondiales via le réseau SWIFT. Bien que la migration big bang semble être le projet le plus difficile, étant donné que toutes les banques européennes dotées d'une connexion TARGET2 ou EBA Euro1 doivent effectuer la conversion en même temps et sans aucune tolérance temporelle, la phase de coexistence de MT et MX a également ses pièges.

La migration TARGET MX est tout d’abord bien plus qu’un simple changement de format. L’accès technique à ESMIG (Eurosystem Single Market Infrastructure Gateway) sera migré en même temps. Un processus de rappel basé sur les normes ISO ainsi qu’une gestion centralisée des liquidités (CLM) avec de nouveaux comptes de liquidités (MCA/DCA) seront introduits. La BCE a imposé aux institutions financières une période de test d’environ un an et surveille en permanence la migration vers le nouveau système – pour un nombre non négligeable d’institutions financières, les propres projets TGT MX sont en jaune ou en rouge. Le fonctionnement sécurisé des paiements de gros montants en Europe semble être menacé dans certaines institutions.
 
Ce rappel à l’ordre concerne toutefois la migration des paiements internationaux. L’initiative SWIFT CBPR+ (Cross Border Payments and Reporting Plus) tente de permettre une transition progressive grâce à une période de transition de 3 ans. Chaque institution financière doit pouvoir atteindre l’objectif de la migration ISO à son propre rythme. Par conséquent, de nombreuses conversions sont effectuées au lieu de traiter les données ISO de bout en bout. Certaines institutions financières continuent d’envoyer et de recevoir des messages MT pour les paiements, d’autres utilisent déjà les formats ISO. En outre, la migration par type de message est de toute façon échelonnée dans le temps.

En y regardant de plus près, on constate que la période de transition laisse présager d’énormes problèmes, tant pour les institutions financières qui n’ont pas encore migré vers ISO que pour celles qui sont en fait prêtes pour ISO.

Les institutions financières qui ne peuvent traiter que des formats MT risquent de voir leurs processus ralentis par les conversions et doivent investir, par exemple, dans des solutions transitoires pour des raisons de conformité, car certains processus nécessitent tout de même de récupérer les formats ISO originaux et de les vérifier. Le plus grand problème : le risque de perte de données, comme celle des adresses...
D’autres problèmes se présentent à tous les participants SWIFT : la période de transition MT/MX entraîne une multitude de nouveaux scénarios et cas d’utilisation en raison des formats possibles dans les messages d’une transaction – avis dans MT, couverture dans MX, demande de frais dans MT, rappel dans MX, etc. La surveillance des transactions est rendue plus difficile, les différentes mises en correspondance dans les institutions financières participantes peuvent conduire à des interprétations erronées.

Je voudrais présenter brièvement un scénario particulièrement problématique : un paiement ordonné au format ISO est exécuté via une longue chaîne de banques de correspondance, dont l’une ne peut envoyer que le format MT. Le correspondant MT reçoit le paiement ISO converti et est obligé de récupérer le format ISO original, mais il ne peut pas transmettre les données coupées au format MT. Le SWIFT Transaction Monitor ne contient pas encore de Golden Copy du paiement original et la banque du bénéficiaire ne peut donc pas lire ou consulter les données perdues, ni dans le message MT, ni dans SWIFT. Dans ce scénario, les informations ne sont donc pas transportées intégralement du donneur d’ordre au bénéficiaire, même si tant l’institution financière du donneur d’ordre que celle du bénéficiaire savent déjà utiliser les formats ISO.

Ma recommandation est donc, malgré le manque aigu de personnel qualifié, d’utiliser le temps qui reste et de tester la migration des paiements internationaux dans tous ses nombreux scénarios (qui sont vraiment nouveaux sous cette forme). Dans l'idéal, vous testez ensemble, notamment avec vos correspondants et vérifiez si la mise en correspondance des affectations MT convenues bilatéralement est encore compatible dans le monde ISO.

Toutes les institutions financières agissant en tant que banques de transaction devraient pouvoir traiter rapidement et sans conversion les données ISO de bout en bout.

Sinon, les transactions financières risquent d’être mises à l’épreuve pendant trois ans.

Thomas Riedel


«Adresses structurée» – ou : la stratégie de l’autruche ne sert à rien

Le temps presse, le prochain grand défi informatique pour les formats ISO20022 approche. Comme c’est souvent le cas, les premières règles sont déjà renforcées : à partir de novembre 2022, les paiements ISO20022 remis par le client avec des contenus d’adresse non structurés au niveau de Ultimate Creditor et Ultimate Debtor seront refusés par les institutions financières.

Pourquoi particulièrement ces deux spécifications ? C’est très simple – les champs qui sont les moins souvent complétés lors des paiements de masse sont utilisés pour les tests. Ainsi peu de transactions seront concernées – ce qui permet d’aborder le sujet à partir d’une petite envergure maîtrisée.

« Pas du tout » ne va pas du tout
Pour les applications et leurs développeurs, l’approche à petite échelle n’est toutefois pas une bonne pratique. De nombreux arguments plaident en faveur de tout ou rien – mais « rien » n’est pas une option envisageable. Si les adresses structurées viennent à être utilisées, il faut qu’elles le soient partout, y compris pour le créancier, le débiteur et les autres détails d’adresse.

Une pensée sans vision
Si vous pensez maintenant : « Ah, c’est la Suisse, cela ne me concerne pas ici en Allemagne ou en Autriche », vous vous trompez fortement. Même dans les futurs paiements SWIFT, seules les adresses structurées seront utilisées à partir de 2025 !
Et ceux qui pensent que l’interface client ne sera pas affectée, c’est-à-dire la livraison correcte des adresses structurées par les nombreux systèmes clients, oublient qu’il n’existe à ce jour aucun système capable de décomposer correctement n’importe quelle adresse fournie de manière non structurée et de la traiter ensuite comme une adresse structurée. La multiplicité des données d’adresses internationales rend cela impossible.

Le traitement manuel est nécessaire
Nous devons donc tous nous y mettre, fabricants de produits clients comme institutions financières elles-mêmes. Les adresses structurées doivent être saisies et transportées partout via les formats concernés, jusqu’à ce qu’elles se retrouvent un jour dans le réseau SWIFT. Les saisies doivent être modifiées, les structures des bases de données adaptées et les données de contenu doivent se retrouver à un nouvel endroit dans le format ISO20022 correspondant. Comme déjà évoqué, étant donné qu’une migration/conversion automatique et sans erreur des données d’adresses non structurées actuelles vers des données d’adresses structurées n’est pas possible, nous devons demander à nos clients et aux collaborateurs de l’institution financière de procéder à un contrôle manuel des données d’adresses converties – ce qui en fait un projet plus long. Pour l’Allemagne, cela a déjà été défini pour le nouveau paiement international ISO au format ISO20022 pain.001.00.09, sera effectif à partir de 2025.

Les délais sont relatifs
Ceux qui estiment encore que cette migration surviendra miraculeusement d’une manière ou d’une autre se trompent : le temps presse ! Trois ans sont un délai très court pour le développement de logiciels et la tâche à réaliser est très vaste. La stratégie de l’autruche peut sembler confortable mais elle conduit à la perte de vue à court terme. Le monde appartient à ceux qui se lèvent tôt et qui ont le budget et les ordres en vue depuis longtemps.


Auteur : Michael Schunk

EBICS et notifications en temps réel - un bilan de la situation

Cela fait maintenant plus de deux ans que la spécification « Notifications en temps réel » a été publiée sur le site web www.ebics.de. J’avais déjà abordé ce sujet dans un article de ce blog publié en octobre 2019. Cependant, que s’est-il passé depuis ? Comment l’application a-t-elle évolué dans la pratique ?
 
 En fait, la nouvelle interface pour les notifications en temps réel a été implémentée par quelques institutions en Allemagne dans leur serveur bancaire EBICS et est désormais utilisée en mode productif par celles-ci. Il est évident que les nouvelles fonctionnalités qui en découlent ne sont utiles que s’il existe des clients EBICS utilisant cette interface. L’interface a également été implémentée sous certaines conditions, côté client dans les portails des entreprises clientes gérées par les institutions financières.

Nous nous rappelons. La valeur ajoutée de cette nouvelle interface réside dans la réponse potentiellement plus rapide aux paiements instantanés SEPA dans le canal EBICS ainsi que dans l’économie des « demandes de téléchargement vaines » pour les données de téléchargement. Où en sommes-nous sur ce point ?

Oui, certaines institutions financières en Allemagne ont mis en œuvre le concept. Toutefois, toutes les institutions financières ne sont pas en mesure de proposer ce nouveau service. Il est possible que du côté de la banque, cela ne soit pas ou pas encore la priorité pour la communication EBICS. Outre la nouvelle interface pour la notification en temps réel en direction du client, la mise à disposition rapide des données de téléchargement dans le serveur bancaire est une des conditions préalables pour offrir une valeur ajoutée aux clients dans le cadre de la communication EBICS. Cette mise à disposition continue et rapide à partir du système back end pour le canal EBICS doit être disponible auprès des institutions financières.

Du côté des clients, la notification push est particulièrement intéressante pour les entreprises clientes pour lesquelles l’actualité et la similitude avec le temps réel sont de plus en plus pertinentes. Ces clients EBICS ont en partie déjà implémenté la notification en temps réel côté client. D’autres qui utilisent par exemple un portail d’entreprises clientes approprié de l’institution financière peuvent éventuellement profiter de ce nouveau service sans intervention de leur part. Néanmoins, tous les clients EBICS ne disposent pas de la nouvelle interface WebSocket pour la notification en temps réel.

En résumé, la fonction de notification en temps réel n’est pas encore largement répandue parmi les clients EBICS. Jusqu’à présent, ce sont surtout les entreprises clientes spécialisées et les clients institutionnels EBICS qui comptent sur les notifications en temps réel dans le canal EBICS. Pour eux, le temps réel dans les processus de paiement représente une valeur ajoutée particulière pour laquelle certains investissements sont rentables. Les institutions financières de ces clients offrent le service adéquat.

En général, nous constatons que le sujet du temps réel dans les transactions financières possède encore un potentiel de croissance. On peut donc s’attendre à ce que le thème de la notification en temps réel en relation avec EBICS gagne encore en importance. Restons donc connectés !

Auteur : Michael Lembcke



L’Euro numérique en tant que base d’innovation pour l’économie

L’Euro numérique en tant que base d’innovation pour l’économie
La numérisation de l’économie et de la société se poursuit à un rythme accéléré. L’IoT (Internet of Things et en français Internet des objets) en particulier promet des modèles commerciaux révolutionnaires dans lesquels l’industrie européenne peut se positionner en tant que leader mondial. Dans ce contexte, le terme IoT désigne l’interaction croissante des machines et des appareils. Les appareils sont dotés d’une identité numérique leur permettant de communiquer mutuellement et d’exécuter des processus de manière autonome sans intervention humaine. Cette tendance deviendra de plus en plus importante à l’avenir.

Pour profiter pleinement du potentiel de la numérisation de l’industrie, l’ensemble du processus, y compris les transactions financières, doit être optimisé et adapté aux paiements IoT de sorte que les paiements liés à ces nouveaux modèles commerciaux puissent également être traités de manière efficace, automatisée et en temps réel.

Dans le contexte de l’IoT, le système de paiement actuel présente toutefois encore les inefficacités suivantes :

  1. Mise en œuvre limitée des modèles commerciaux basés sur l’IoT
    Les paiements à l’utilisation (pay per use) et les paiements de machine à machine nécessitent une intervention humaine.
  2. Pas de normalisation de bout en bout
    Pour un traitement automatisé de bout en bout, il manque encore des normes appropriées.
  3. Manque d’automatisation lors de l’intégration
    La mise en place de machines autonomes requiert une intégration automatisée.
  4. Coûts de transaction élevés
    Ce sont surtout les transactions transfrontalières et les paiements de faible montant qui entraînent des coûts élevés.
  5. Mécanismes de règlement lents
    Les paiements instantanés permettent d’effectuer des paiements en temps réel, mais leur propagation est limitée.
  6. Absence de processus KYO (Know Your Object)
    Des processus de conformité appropriés pour reconnaître et vérifier les identités des machines doivent encore être mis en place.

Pour minimiser ces insuffisances de processus et les limites du système de paiement, la mise en place d’un système monétaire innovant serait très avantageuse. Par conséquent, au cours de la phase d'analyse de deux ans de l’euro numérique, la Banque centrale européenne (BCE) devrait non seulement prendre en compte l’impact sur les consommateurs, mais également développer des solutions pour la transformation numérique des processus économiques en cours. Étant donné que les résultats de la phase d’analyse pour l’économie ne sont pas encore connus, le secteur privé a déjà commencé à numériser l’euro, ce qui permet d’introduire des technologies (de transition) dans les processus économiques.

Chez PPI, nous suivons ce sujet avec beaucoup d’enthousiasme et considérons que la capacité d’innovation du système de paiement est indispensable pour l’économie. Afin de vous tenir au courant des derniers développements, nous vous informerons au cours de cette année régulièrement des nouveautés sur l’euro numérique au moyen de ce blog.

Auteur : Philipp Schröder

Les paiements en 2022 : l’année décisive

Le nombre de tâches dans les paiements reste énorme. Pour de nombreux projets, 2022 sera une année décisive. Compte tenu des conditions difficiles, notamment en raison de la pandémie persistante, on peut toutefois se demander si tous ces projets seront menés à bien dans les délais prévus ou s’ils pourront être poursuivis de manière significative.

Parmi les initiatives les plus importantes en 2022 figurent certainement les grands projets dans le domaine des paiements internationaux et de gros montants : le lancement de la consolidation TARGET2 et le démarrage de la migration de SWIFT vers le format ISO 20022 qui auront lieu tous deux en novembre 2022. Les tests effectués par les utilisateurs au printemps et leur suivi par les Banques centrales fourniront des indications concrètes sur l’état d’avancement des préparatifs du secteur des prestataires de services financiers en vue de la migration vers TARGET2.

En outre, deux autres projets se profilent déjà à l’horizon des paiements internationaux : le traitement des paiements transfrontaliers en temps réel ainsi que la simplification et l’amélioration des paiements internationaux pour les petites entreprises et les consommateurs. Les moteurs de cette évolution sont les pays du G20 et le succès de prestataires alternatifs comme Wise.

En ce qui concerne les paiements de masse (SEPA), les prestataires de services de paiement doivent se préparer cette année à la migration des procédures SEPA vers la nouvelle version ISO, prévue pour 2023. En outre, ils doivent évaluer l’impact concret de la directive européenne contre la fraude à la TVA sur leurs activités commerciales. Le contexte : l’UE prend des mesures législatives massives pour endiguer l’écart de TVA au sein de l’Union européenne et introduit à cet effet une sorte de Conservation des données fiscales dans les transactions financières. Les nouvelles obligations de déclaration affecteront les prestataires de services financiers à partir de janvier 2024.

 

Année cruciale pour la demande de paiement (Request to Pay ou RTP)

En matière de procédures SEPA, l’attention se portera cette année sur les chances d’introduire la Request to Pay sur le marché. Les scénarios d’application ne manquent pas. La demande de paiement peut notamment être utilisée dans le commerce électronique, dans le processus de facturation électronique et pour les paiements récurrents, voire au point de vente. Pourtant, les prestataires de services financiers semblent hésiter à passer à la mise en œuvre concrète. Jusqu’à présent, on ne voit guère d’efforts pour développer des produits basés sur une utilisation RTP. Les raisons possibles sont un manque de demande et des obstacles économiques ou techniques :

  • Interface client-institution financière : il n’existe actuellement aucun registre central indiquant quel client a son compte auprès de quelle institution.
  • Compensation RTP : jusqu’à présent, seule l’EBA CLEARING propose de tels processus conformes à la RTP. Pour couvrir le plus grand nombre possible de bénéficiaires de paiement et de payeurs, d’autres chambres de compensation doivent suivre.
  • Processus de paiements : il faut tout d’abord trouver une solution technique pour la mise en correspondance, c’est-à-dire pour l’affectation des messages de réponse à l’institution financière du bénéficiaire du paiement à la demande de paiement initiale. Puis d’autre part, il s’agit de décider des possibilités de paiement à proposer.

En ce qui concerne le processus de paiement de la RTP, de nombreux cas d’application reposent sur l’utilisation des paiements instantanés SEPA. L’année 2022 permettra de savoir si la Commission européenne rendra les paiements instantanés obligatoires pour toutes les institutions de paiement dans le cadre d’une adaptation du règlement SEPA ou de la Directive sur les services de paiement 2 (DSP2), du moins en matière d’accessibilité. En effet, à la fin de l’année 2021, seuls 60 % environ des prestataires de services de paiement européens avaient souscrit au schéma correspondant. Par conséquent, seulement – ou tout de même – un peu plus de 10 % de tous les virements dans l’espace SEPA sont effectués sur la base du SEPA Instant Credit Transfer (SCT Inst).


Peu de dynamisme à attendre de la European Payments Initiative (EPI)

La généralisation de la RTP et des paiements instantanés jouera également un rôle important dans la réalisation de la European Payments Initiative (EPI). Pour l'instant, on peut toutefois se demander si une solution de paiement paneuropéenne unique pourra être créée comme alternative aux solutions et systèmes de paiement internationaux existants. En Allemagne, seules la Sparkassen Finanzgruppe et la Deutsche Bank semblent encore suivre l’initiative. Si l’EPI échoue, les Européens se rendront définitivement dépendants des procédures américaines et probablement aussi des procédures chinoises. Il reste à espérer que la politique et le secteur public augmentent encore une fois nettement la pression, mais aussi le soutien, envers le secteur financier. Et peut-être un noyau franco-allemand constituera-t-il le noyau de l’EPI.

Et que se passera-t-il en 2022 avec l’euro numérique ? Ce projet d’avenir est toujours en test. Le principe est que l’euro numérique ne doit pas remplacer les espèces, mais les compléter. Du point de vue du consommateur, l’alternative numérique doit garantir un maximum d’anonymat et de sécurité. En outre, la mise à disposition, la disponibilité et l’interopérabilité sont d’une grande importance. Selon les informations actuellement disponibles, la BCE souhaite impliquer les banques commerciales et les prestataires de services de paiement (PSP) dans le projet. Ils doivent jouer le rôle d’intermédiaires entre les Banques centrales et les consommateurs.

 

D’une manière ou d’une autre : l’euro numérique deviendra réalité

Mais la monnaie numérique ne doit pas nécessairement être émise par une Banque centrale. Les institutions financières peuvent également créer des solutions pour les paiements dits programmables. Les stablecoins basés sur l’euro, des jetons numériques adossés à une valeur monétaire donnée, en sont un exemple. Pour ces procédures aussi, des progrès sont attendus en 2022.

Finalement, la monnaie numérique deviendra réalité, quelle que soit la forme qu’elle prendra. C’est l’unique façon pour que l’industrie allemande puisse pleinement profiter du potentiel de l’Internet des objets (IoT). L’automatisation progressive dans le domaine de la logistique des marchandises ou les modèles de plus en plus populaires de type « asset as a service » sont notamment difficiles à imaginer à long terme sans paiements entièrement autonomes en temps réel.

Compte tenu des coûts liés aux transformations susmentionnées, les institutions financières – principalement les institutions de niveau Tier 2 – externaliseront plus en plus le traitement des paiements en 2022 ou, du moins, achèteront des logiciels de paiement en tant que service.



Lutte pour les talents

Et pour terminer, une tendance sociétale de ces dernières années prendra encore de l’ampleur : le manque de ressources ou la lutte pour les ressources. Les prix des experts et des services dans le domaine de l’informatique ne cesseront d’augmenter. En effet, la question n’est progressivement plus de savoir qui peut assumer une tâche, mais plutôt si l’on peut trouver quelqu’un pour l’accomplir. Les services d’achat des institutions financières se transformeront en chasseurs de têtes de ressources externes.


Auteur : Hubertus von Poser, Head of Consulting Payments, PPI AG

Conseils pour une transition aisée vers EBICS 3.0

Depuis novembre 2021, EBICS 3.0 est officiellement introduit auprès les institutions financières et peut être utilisé par les entreprises clientes. Par ailleurs, la version précédente reste valable. L’un des changements d’EBICS 3.0 concerne la suppression des types d’ordres à trois caractères ou des paramètres FileFormat en France pour les opérations métier. Celles-ci sont désormais représentées par les Business Transaction Formats (BTF). Les BTF comprennent chacun huit paramètres : Service Name, Service Scope, Service Option, Service Message Name, Service Message Name Version, Service Message Name Format, Service Message Name Variant et Service Container.

Dans le cadre d’un accord client, il doit être possible de prendre en compte l’accord central pour l’opération métier concernée, indépendamment de la version EBICS. La compatibilité et l’interopérabilité entre les versions précédentes sont spécifiées pour EBICS. Si deux signatures électroniques sont convenues pour un virement SEPA, il n’est pas pertinent, par exemple, que les remises relatives soient effectuées par BTF ou par type d’ordre ou paramètres FileFormat. Cette condition exige une mise en correspondance interne des anciennes et des nouvelles opérations métier dans le serveur bancaire et, le cas échéant, dans les systèmes clients. Jusqu’à présent, ces mises en correspondance sont officiellement spécifiées pour les opérations métier standard.

Les traitements préalables et ultérieures d’EBICS auprès des institutions financières et des entreprises clientes reposent en règle générale encore sur les anciens ID EBICS, comme les types d’ordres à trois caractères, et en France sur les paramètres de FileFormat pouvant comporter jusqu’à 40 caractères. Tant qu’une mise en correspondance existe, il n’est pas nécessaire de modifier ce procédé. Mais que se passerait-t-il si aucun type d’ordre/paramètre FileFormat n’est plus spécifié pour une opération métier et que les opérations métier sont valables uniquement avec BTF ? Si on ne souhaite pas adapter ses processus de traitement annexes à la BTF, on peut bien sûr garder une mise en correspondance. Pour les mises en correspondance non spécifiées, il convient toutefois de définir des ID individuels appropriés.

Dans les relations externes entre le client et l’institution financière, il faut tenir en compte que les spécifications du serveur bancaire concernant les opérations métier et les mises en correspondance sont communiquées au client ou au système Client par différents moyens. Les différentes représentations du point de vue du client, du participant et du moment jouent également un rôle. Un participant utilise toujours une version EBICS concrète, alors que l’accord client doit représenter toutes les versions valables. En outre, le moment de l’information a une incidence. Ainsi, avant l’initialisation du participant, l’institution financière ne sait généralement pas quelle version EBICS ce dernier utilise.

Le formulaire des paramètres bancaires, créé sur le serveur bancaire lors de la configuration du participant, doit donc représenter les options de toutes les versions EBICS prises en charge, y compris les éventuelles spécifications de mise en correspondance BTF. Il en va de même au moins pour le type d’ordre HKD permettant de télécharger les accords au niveau du client par le Client technique. Si aucune mise en correspondance n’est plus proposée pour certaines opérations métier dans la relation entre le client et l’institution financière, indépendamment de l’utilisation interne, les informations respectives devraient en conséquence représenter la mise en correspondance exclusivement par BTF. Pour l’administration et la gestion internes, il serait utile que les ID individuels utilisés uniquement en interne soient visibles dans le cas d’une mise en correspondance interne, (par exemple, les types d’ordre individuels avec leur propre mise en correspondance BTF), mais qu’ils soient différents des ID externes.

En résumé, le défi consiste à rendre la migration vers EBICS 3.0 aussi facile que possible pour toutes les parties concernées, compte tenu de la nouvelle diversité des informations. Cependant, avec une configuration adéquate et en respectant quelques consignes d’utilisation, la transition vers la nouvelle version EBICS n’est pas si difficile. Si vous avez besoin de soutien pour passer à EBICS 3.0 ou si vous avez des questions à ce sujet, n’hésitez pas à nous contacter.

Auteur : Michael Lembcke


API ouvre les portes aux applications bancaires

En ce moment, l’abréviation API est omniprésente. Ces trois lettres signifient Application Programming Interface, c’est-à-dire une interface de programmation pour les applications. Toutes les API nourrissent le même espoir de mettre en œuvre le plus simplement et le plus rapidement possible de nombreux cas d’application bancaires via une interface standardisée. Le nombre de cas d’application utilisés à cet effet ne cesse de croître. Beaucoup d’institutions variées font avancer ce développement, de sorte que les API pourront considérablement modifier le marché bancaire.

La DSP2 en tant que germe de cristallisation des API au cours des dernières années a conduit à ce que différentes initiatives en Europe spécifient une API accès au compte. Les initiatives les plus importantes sont certainement « The Berlin Group », « stet » et « PolishAPI ». Mais la DSP2 a également eu un impact en dehors de l’Europe. En Suisse, le « OpenBankingProject » a été créé, inspiré de l’API du Berlin Group SwissNextGenAPI. Au Royaume-Uni, l’initiative « Open Banking »  a été lancée. Toutes les initiatives et leurs API misent sur la DSP2 et elles ont toutes en commun l’objectif de réaliser un gain d’efficacité élevé.

La réalité tempère quelque peu cet espoir. Il existe bien sûr des initiatives de normalisation décrites ci-dessus. Cependant, tout d’abord il n’existe pas de spécification universelle, mais ensuite, les institutions financières ne sont pas obligées de s’y conformer et enfin, les spécifications laissent une certaine liberté d’implémentation (mot-clé Implementor Options). Si un acteur du marché, qu’il s’agisse d’une institution financière ou d’un prestataire de services tiers, souhaite utiliser l’API accès au compte des institutions financières, il est confronté à un défi. PPI a relevé ce défi et a créé, avec le produit TRAVIC-Payment-Client-API, une bibliothèque qui dissimule l’hétérogénéité décrite derrière une seule interface. L’utilisation de TRAVIC-Payment-Client-API permet de minimiser les risques et de raccourcir le temps de développement pendant la connexion des interfaces accès au compte des institutions financières. Le produit est utilisé de manière productive chez Atruvia AG. Pour en savoir plus et découvrir par exemple comment Atruvia AG en a profité, cliquez ici.

Du point de vue de PPI, le thème API est un incontournable dans le contexte des paiements. Poussés en partie par la DSP2, les premiers pas ont été faits du côté des institutions financières. Mais il est prévisible que le progrès ne s’arrêtera pas là. Le Berlin Group a depuis longtemps spécifié l’openFinance API Framework (https://www.berlin-group.org/open-finance) qui développe les cas d’utilisation de l’interface accès au compte. Pour autant que l’on sache, d’autres extensions de la spécification sont prévues pour 2022. Ces services à valeur ajoutée, qui sont bien entendu fournis via des API, sont de plus en plus proposés sur les portails pour développeurs des grandes institutions financières. Certaines de ces API ne s’adressent plus seulement à des prestataires de services tiers, mais aussi directement aux entreprises. Cela montre clairement que le thème de l’API ne se limite pas aux cas d’utilisation pertinents pour la DSP2, mais qu’il s’établira de plus en plus comme un canal autonome pour différentes parties impliquées. Par conséquent, il est probable que tôt ou tard, d’autres API seront disponibles en plus d’EBICS, FinTS et accès au compte.

Le Berlin Group n’est pas le seul à s’intéresser à l’API. Le Conseil européen des paiements (EPC) a créé un groupe de travail au niveau européen, chargé d’élaborer un Rulebook pour l’accès aux comptes de paiement SEPA via les API (https://www.europeanpaymentscouncil.eu/news-insights/news/call-candidates-sepa-payment-account-access-multi-stakeholder-group-spaa-msg), auquel PPI participe. En outre, dans l’annonce publiée récemment au sujet du « SEPA Request to Pay Scheme Rulebook 2.0 », l’EPC a même déclaré que l’échange de messages SRTP via des API serait obligatoire à l’avenir.
Le marché est en pleine mutation, mais une chose est claire : la liste des initiatives existantes et futures autour des API est longue et de nombreuses innovations sont envisageables dans cet environnement. Avec le produit TRAVIC-Payment-Client-API, PPI a fait le premier pas et le propose notamment aussi comme service. En outre, PPI conçoit d’autres services autour du thème de l’API.

Auteur : Christian Wenz