Coup de sifflet de mi-temps – premier bilan de la BCE sur la phase d’analyse de deux ans de « l’euro numérique »

Comme nous l’avons déjà rapporté dans un article de blog précédent, la Banque centrale européenne (BCE) a lancé en octobre 2021 un projet d’analyse de deux ans visant à évaluer la manière dont l’euro numérique doit être conçu. À l’issue de cette phase d’analyse, il sera décidé en 2023 si la BCE mettra en œuvre l’euro numérique et sous quelle forme.

À mi-parcours de la période de deux ans, un rapport intermédiaire a été publié par la BCE le 29 septembre 2022. Ce document examine de nombreuses questions et thèses que nous avons abordées dans la dernière série de blogs traitant de l’euro numérique. Le rapport de la BCE reprend les progrès réalisés et aborde les options de conception fondamentales de l’euro numérique qui ont été récemment approuvées par le Conseil de la BCE. Nous souhaitons présenter ces options dans cet article, de manière synthétique :

Exécution des paiements en ligne et hors ligne
Actuellement la BCE se concentre sur les deux options de transaction suivantes :

1. Exécution des transactions en ligne validées par un intermédiaire
2. Exécution des transactions hors ligne dans un contexte de pair-à-pair, validées directement ou sans intermédiaire.

Protection des données, anonymat et gestion des avoirs
Quant à la confiance des consommateurs, le Conseil de la BCE décrit dans son rapport que l’euro numérique présentera probablement des caractéristiques de protection de données similaires à celles des procédures de paiement numériques actuelles. Les paiements ayant une faible valeur doivent bénéficier d’une protection des données plus élevée que les paiements ayant des montants maximaux comparables. Une exécution entièrement anonyme des paiements sans limite de montant n’est pas envisagée actuellement.
En outre, il est envisagé d’introduire des limites pour la gestion des avoirs. L’objectif est de limiter la détention de l’euro numérique afin de ne pas créer artificiellement une forme d’investissement alternative pour les consommateurs.

Grandes étapes en 2023

1. Au premier trimestre 2023, la Commission européenne élaborera une proposition de règlement pour l’introduction de l’euro numérique.
2. D’ici fin octobre 2023, le Conseil de la BCE doit décider des modalités de poursuite du développement de l’euro numérique. La phase suivante pourra s’étaler sur trois années consécutives.

Source : BCE
https://www.ecb.europa.eu/paym/digital_euro/investigation/governance/shared/files/ecb.degov220929.en.pdf

L’argent public comme catalyseur ?
Même si le bilan à mi-course laisse encore une grande marge d’interprétation et d’organisation, les premières tendances se dessinent clairement.  À l’instar de ce qui est décrit dans le rapport, nous considérons chez PPI que l’argent public sous forme numérique peut apporter une contribution importante à l’ère numérique. L’euro numérique dans le contexte actuel des consommateurs serait un premier fondement important. Pour cette raison, nous continuons notre veille sur ce sujet avec beaucoup d’enthousiasme et nous suivrons en détails les développements de l’euro numérique dans ce blog EBICS.
À la prochaine fois.

Auteur : Philipp Schröder

En savoir plus

Remise en temps réel EBICS – qui transfère des millions d’euros avec PayPal ?

Il faut bien admettre que la technologie développée par les FinTechs au cours des dernières années est intelligente, compacte et surtout rapide. Le feedback direct sur les terminaux mobiles en mouvement, au point de vente ou sur le canapé lors des achats en ligne est aujourd’hui tout à fait normal et les clients modernes ne voudraient plus en être privés.

Mais imaginez que vous deviez transférer de grandes quantités d’argent ou que vous ayez la responsabilité de fonds étrangers appartenant à votre entreprise. Quels seraient vos standards en matière de sécurité et de traitement fiable et transparent de vos paiements ? Les volumes, non seulement en termes de somme d’argent, mais également en termes de tailles techniques des fichiers pour les paiements de masse, supposent d’autres procédures qui ont été testées depuis longtemps et établies avec des partenaires de confiance des institutions financières. EBICS pour le traitement par lots de grands fichiers collectifs est le standard bancaire européen privilégié par tous les experts en matière de paiement, et qui est progressivement introduit de manière obligatoire par un plus grand nombre de pays européens. Ces concepts EBICS établis ont maintenant été adaptés à la remise en temps réel et aux paiements instantanés pour un traitement en ligne innovant.

La sécurité n’exclut pas la rapidité
La communication avec vos institutions financières établies et le transfert sécurisé de vos fichiers de paiement sont désormais également assurés par EBICS sous forme de remise en temps réel. En se basant sur l’interface WebSocket introduite avec la spécification en temps réel EBICS, les paiements saisis ou les fichiers de paiement transférés sont soumis au serveur bancaire avec le type d’ordre WIP (ou le BTF correspondant à partir d’EBICS 3.0). Dans le client EBICS, l’utilisateur reçoit immédiatement un message de réussite actif sous forme de message push sur le traitement du paiement auprès de l’institution financière en tant qu’avis C5N. Les messages de retour de protocole standard du rapport de statut pain.002 de l’institution financière sont bien entendu également fournis. Tout cela est possible si tous les produits impliqués sont parfaitement adaptés et intégrés dans le processus continu. Les applications mobiles EBICS pour la validation des paiements sur la route reproduisent également ces processus en temps réel. 

Sur la voie rapide en toute sécurité
Les premières institutions financières introduisent cette fonction dans leur production afin d’offrir à leurs clients la qualité et la sécurité habituelles ainsi qu’une rapidité innovante. Il faudra certes un peu de temps pour que les grands transferts de fonds soient effectués « intelligemment » et rapidement depuis son canapé vers les services comptables des entreprises.

Mais qui sait quelles habitudes se sont entre-temps glissées dans certains bureaux à domicile. Le travail décentralisé a en tout cas acquis une nouvelle dimension. La plupart des entreprises proposent désormais le travail à domicile, et les responsables de département et les fondés de pouvoir travaillent également depuis leur domicile. Les validations de paiements importants avec des signatures distribuées sont donc également soumises en temps réel et confirmées immédiatement.

Le protocole WebSocket offre en outre l’option supplémentaire de pousser des notifications de l’institution financière vers les utilisateurs de l’application de paiement. Outre les simples informations sur le statut des paiements, l’institution financière communique aussi avec ses clients sous forme de messages textes. Les messages apparaissent à la demande de l’utilisateur sous forme d’info-bulle sur l’interface et sont rassemblés dans une propre boîte aux lettres pour être lus et téléchargés.

API ou pas : un processus intelligent et rapide, respectant les normes de sécurité habituelles de votre institution financière n’est pas un problème grâce à EBICS !

Auteur : Christian Veith

En savoir plus

DORA – Digital Operational Resilience Act Partie 2 : Perspectives et objectifs

DORA doit permettre de faire face aux cyberrisques croissants. Quelles réglementations sont prévues ? Qui sera concerné par ces réglementations ?

Nous souhaitons aborder ces questions dans deux articles de blog consécutifs. Dans la première partie, nous rassemblons des informations sur le contrôle et l’organisation et examinons les exigences étendues en matière de gestion des risques liés aux TIC, la notification des incidents liés aux TIC et les risques liés aux fournisseurs tiers de TIC.

Dans la deuxième partie, nous donnons un aperçu des futurs développements et nous discutons de la manière dont les fournisseurs de cloud américains peuvent être intéressés à s’installer dans l’UE. 

Partie 2 

Le Parlement européen et le Conseil adopteront le texte officiel du règlement probablement à l’automne 2022 et celui-ci sera ensuite publié au Journal officiel de l’Union européenne. On s’attend à ce que le règlement DORA soit applicable dans toute l’UE fin 2024. Dès à présent, les institutions financières et les prestataires de services financiers devraient réfléchir à la mise en œuvre d’une gestion adéquate des risques liés aux TIC et envisager des mesures appropriées.

Les entreprises financières actives dans les transactions financières ont un intérêt intrinsèque à protéger la résilience opérationnelle numérique et à la rendre plus résiliente aux cyberattaques, car les perturbations opérationnelles peuvent entraîner des pertes de chiffre d’affaires considérables et, par conséquent, d’immenses dommages à la réputation. Le fait que les grandes institutions financières, les Fin- et BigTechs, représentent une grande surface de projection pour les attaques de pirates et que la numérisation exponentielle devient de plus en plus pertinente, renforce la nécessité de mettre en œuvre des mesures européennes pour renforcer la résilience opérationnelle numérique des entreprises financières.

Étant donné que les entreprises financières sont généralement très interconnectées, même un cyberincident localisé peut entraîner d’énormes risques systémiques pour le secteur financier et menacer la stabilité financière. Les produits et services fournis par les entreprises financières sont souvent élémentaires pour le fonctionnement d’une société. Les coûts engendrés par une cyberattaque sont souvent très élevés pour la société et les entreprises financières.

D’une part, les entreprises financières pourraient être découragées de signaler les cyberincidents aux autorités compétentes en raison des coûts de notification et des dommages potentiels à leur réputation. D’autre part les rapports sur les cyberincidents pourraient générer des bénéfices externes importants en permettant à d’autres entreprises financières d’identifier et de combler les failles de sécurité. La proposition de règlement n’est toutefois pas proportionnée. La gestion des risques liés aux TIC des entreprises financières devrait se concentrer uniquement sur les éléments critiques de la résilience opérationnelle numérique. DORA, en revanche, couvre tous les composants physiques, les infrastructures, les locaux et les centres de traitement de données, indépendamment de leur risque opérationnel. 

DORA oblige les entreprises financières à résilier les contrats avec des fournisseurs tiers critiques de TIC si ceux-ci enfreignent les lois, les règlements, les directives ou les conditions contractuelles, ou si elles y sont contraintes par une autorité de surveillance financière.

Cela devrait augmenter le risque opérationnel pour les entreprises financières, car il pourrait être difficile de trouver des fournisseurs alternatifs appropriés rapidement. Au lieu de cela, DORA devrait encourager une coordination étroite entre les acteurs concernés, articuler une liste de niveaux de sanctions et prévoir au moins des périodes de transition. Un mandat strict de résiliation de contrat devrait être le dernier recours.

La restriction de conclure des contrats de fourniture informatique avec des fournisseurs tiers critiques de TIC issus de pays tiers est une forte atteinte à la liberté contractuelle des entreprises financières européennes. Cette mesure pourrait paradoxalement freiner le renforcement de la résilience opérationnelle numérique, car les sociétés financières pourraient se voir contraintes de conclure des contrats avec des fournisseurs présentant un niveau de cybermaturité inférieur. Cette contrainte a le potentiel de limiter le choix et l’accès à des solutions, produits et services TIC plus cybersécurisés et innovants.

L’objectif de la Commission européenne de réduire la dépendance du secteur financier européen vis-à-vis des fournisseurs de cloud américains ne doit pas se transformer en actionnisme. Une action plus ciblée consisterait à prendre des mesures réglementaires pour inciter ces fournisseurs à établir des filiales dans l’UE, afin qu’ils puissent être surveillés plus efficacement par les autorités de surveillance locales en ce qui concerne les risques opérationnels.

En 2023, l’Autorité bancaire européenne (EBA) aura pour mandat de créer le cadre réglementaire pour MiCAR et DORA. En plus de son rôle de supervision, l’EBA est chargée d’élaborer des directives et des procédures de supervision, ainsi que des lignes de conduite visant à assurer l’échange d’informations entre toutes les parties concernées. Il s’agit notamment des émetteurs de cryptoactifs réglementés, des autorités nationales compétentes, de la BCE et des autres banques centrales concernées. Le temps d’agir est limité, car tout doit être réalisé avant la date d’application de MiCAR et DORA. Le cadre à développer pour DORA fournira un cadre réglementaire pour assurer la surveillance et la limitation des cyberrisques et des incidents liés aux TIC. En revanche, pour le règlement MiCAR, l’EBA devra rédiger des exigences spécifiques concernant l’émission de cryptoactifs et l’offre de services de cryptographie.

Source de la figure : EU Digital Operational Resilience Act (DORA) | Compliance | Haufe

Auteurs : Salar Hydary, Judith Petersen

En savoir plus

DORA – Digital Operational Resilience Act : Partie 1 : Pourquoi la résilience opérationnelle numérique doit être évaluée de manière uniforme au niveau de l’UE ?

DORA doit permettre de faire face aux cyberrisques croissants. Quelles réglementations sont prévues ? Qui sera concerné par ces réglementations ?
Nous souhaitons aborder ces questions dans deux articles de blog consécutifs. Dans la première partie, nous rassemblons des informations sur le contrôle et l’organisation et examinons les exigences étendues en matière de gestion des risques liés aux TIC, la notification des incidents liés aux TIC et les risques liés aux fournisseurs tiers de TIC.
Dans la deuxième partie, nous donnons un aperçu des futurs développements et nous discutons de la manière dont les fournisseurs de cloud américains peuvent être intéressés à s’installer dans l’UE.

Partie 1

Le 22 mai 2022, la Commission européenne, le Conseil de l’Union européenne et le Parlement européen ont conclu un accord préliminaire sur la proposition de loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act – DORA). En tant que partie intégrante de la stratégie de numérisation de l’ensemble du secteur financier européen, DORA se trouve ainsi au centre de l’attention. La Commission européenne a publié la proposition législative de DORA pour la première fois le 24 septembre 2020 dans le cadre du Digital Finance Package. Le triumvirat composé de la Commission, du Conseil et du Parlement a déjà adopté le Digital Finance Package en septembre 2020 pour réaliser une numérisation transfrontalière.
Le Digital Finance Package comprend les parties suivantes :

• Stratégie de numérisation du secteur financier
• Propositions législatives sur les cryptoactifs (Markets in Crypto Asset Regulation, règlement pilote de Distributed-Ledger-Technology et Transfer of Funds Regulation)
• Propositions législatives sur la résilience opérationnelle des systèmes numériques (DORA) du secteur financier
• Stratégie pour les paiements de masse  

La stratégie européenne en matière de résilience opérationnelle numérique a été complétée par deux règlements importants en matière de cryptographie, à savoir le Markets in Crypto Assets Regulation (MiCAR) et le Transfer of Funds Regulation (ToFR). Le 30 juin 2022, l’Union européenne a donné son feu vert au règlement MiCAR pour la surveillance du secteur de la cryptographie.
Un jour plus tôt, le 29 juin 2022, le Parlement européen avait déjà trouvé un accord sur le règlement ToFR.
L’objectif de DORA est, d’une part, de garantir la stabilité financière, la protection des consommateurs et l’intégrité du marché et, d’autre part, d’éliminer efficacement les obstacles réglementaires dans le secteur financier grâce à une harmonisation juridique. En outre, un cadre intersectoriel à l’échelle de l’UE sera mis en place pour gérer et atténuer les risques liés aux technologies de l’information et de la communication (risques liés aux TIC). Les acteurs financiers traditionnels tels que les institutions financières, les compagnies d’assurance et les sociétés d’investissement sont concernés par le règlement DORA, mais également les Fin- et BigTechs, les prestataires de services cryptographiques et les places de marché. Les micro-entreprises qui emploient moins de 10 personnes et dont le chiffre d'affaires annuel ou le bilan annuel n’excède pas 2 millions d’euros sont exclues. (art. 3, p. 1, point 50, en combinaison avec l’article 2, par. 3 de l’annexe de la recommandation 2003/361/CE).

Gouvernance et organisation
Les institutions financières et les prestataires de services financiers devraient disposer de cadres de gouvernance et de contrôle internes garantissant une gestion efficace et prudente de tous les risques liés aux TIC (art. 4, par. 1). Les institutions financières devraient disposer d’un cadre de gestion des risques liés aux TIC solide, complet et bien documenté, leur permettant de faire face aux risques liés aux TIC de manière immédiate et efficace (art. 5, par. 1). L’organe de direction définit, autorise et contrôle le cadre de gestion des risques liés aux TIC et doit rendre compte de sa mise en œuvre. Afin de garantir le bon fonctionnement de la gouvernance, des fonds doivent être alloués aux investissements dans les ressources des TIC, y compris la formation aux risques liés aux TIC pour le personnel (art. 4, par. 2).

Exigences en matière de gestion des risques liés aux TIC
Les exigences énumérées dans DORA pour répondre à une gestion adéquate des risques liés aux TIC requièrent des fonctions spécifiques. Le cadre de gestion des risques liés aux TIC est documenté et réexaminé au moins une fois par an, ainsi que lors de la survenance d’incidents graves liés aux TIC, résultant de contrôles ou de procédures d’audit quant à la résilience opérationnelle numérique. L’objectif est d’identifier les menaces potentielles à un stade précoce, de collecter des informations et d’assurer une amélioration continue de la gestion des risques informatiques. (art. 5 par. 9 DORA)
La gestion des TIC doit assurer la protection et la prévention contre les cyberattaques ou réduire au minimum la vulnérabilité aux cyberincidents et mettre en œuvre des stratégies et des procédures garantissant « la résilience, la continuité et la disponibilité des systèmes de TIC » et « des normes élevées en matière de sécurité, de confidentialité et d’intégrité des données » (art. 8, par. 2).
Les institutions financières et les prestataires de services financiers doivent mettre en œuvre une stratégie de TIC visant à réagir rapidement, efficacement et de manière appropriée à tous les incidents liés aux TIC, notamment les cyberattaques, afin de limiter les dommages et d’assurer la reprise des activités et le rétablissement des opérations (art. 10, par. 2). La mise en œuvre de mécanismes permettant à la fois de détecter les vulnérabilités et d’enregistrer tous les incidents liés aux TIC est indispensable.
En tant qu’acteurs du marché particulièrement orientés vers le client et considérés comme intègres, les institutions financières doivent disposer de plans de communication permettant de « divulguer de manière responsable les incidents liés aux TIC ou les vulnérabilités importantes aux clients et aux autres entreprises financières, ainsi qu’au public » (DORA, art. 13, par. 1).

Notification d’incidents liés aux TIC
DORA exige des institutions financières et des prestataires de services bancaires qu’ils mettent en place des procédures de gestion pour surveiller, identifier, classer, suivre, consigner et signaler aux autorités compétentes les incidents graves liés aux TIC (art. 15, par. 1).
Les destinataires des notifications d’incidents TIC graves sont les autorités nationales compétentes. Les institutions financières et les prestataires de services financiers doivent fournir des détails pertinents sur les incidents à d’autres institutions ou autorités, telles que les Autorités européennes de surveillance (AES), la Banque centrale européenne (BCE) ou les points de contact centraux désignés en vertu de la Directive sur la sécurité des réseaux et des systèmes d’information (Directive NIS). Les incidents graves liés aux TIC doivent être signalés de manière centralisée par les autorités au niveau de l’Union. Les entreprises financières seront tenues de présenter des rapports initiaux, intermédiaires et finaux. Si un incident lié aux TIC a une répercussion sur les intérêts financiers des utilisateurs de services et des clients de l’entreprise financière concernée, ceux-ci doivent en être informés sans délai (art. 17, par. 2).

L’une des principales tâches de l’AES consiste à publier annuellement un rapport complet, sous forme anonyme, fournissant des informations sur les notifications d’incidents graves liés aux TIC faites par les autorités compétentes. Cela concerne le nombre minimum d’incidents graves, leur nature, l’impact sur les activités commerciales des entreprises financières ou des clients, ainsi que les coûts (art. 20, par. 2). En outre, le projet de règlement oblige les institutions financières à veiller à ce que les contrats d’utilisation de services liés aux TIC soient résiliés si les fournisseurs tiers de TIC enfreignent les lois, les règlements ou les conditions contractuelles applicables (art. 25, par. 8). 

Contrôle de la résilience opérationnelle numérique
La gestion des risques liés aux TIC des institutions financières et des prestataires de services financiers doit faire l’objet d’audits réguliers afin de vérifier leur capacité à se défendre et à détecter les vulnérabilités, les défauts ou les lacunes ainsi que la mise en œuvre immédiate de mesures correctives. Les systèmes de TIC doivent être régulièrement examinés en profondeur. Un tel contrôle doit être effectué au moins une fois par an et être dûment documenté. La réalisation de tests de prévention, de détection, de réaction et de récupération est indispensable pour corriger exhaustivement tous les points faibles, défauts ou lacunes (art. 21, par. 5).

Les principaux outils utilisés pour tester la résilience opérationnelle numérique sont les suivants (art. 22) :

• Évaluations et contrôles de la vulnérabilité
• Analyses de logiciels à source ouverte
• Évaluations de la sécurité des réseaux
• Analyses des failles
• Analyses de la sécurité physique
• Vérifications de la sécurité physique
• Questionnaires et solutions logicielles d’analyse
• Audits de code source, dans la mesure du possible
• Tests basés sur des scénarios
• Tests de compatibilité
• Tests de performance
• Tests de bout en bout
• Tests d’intrusion basés sur les menaces

Le niveau d’exigence des tests de résistance dépend en grande partie de la taille du profil commercial et du profil de risque de chaque entreprise financière.
Des exigences particulièrement élevées quant aux tests de résilience opérationnelle numérique s’appliquent aux établissements importants dans le domaine des paiements, par exemple les grands établissements de crédit, les grandes institutions de paiement et les grandes institutions de monnaie électronique. Cela s’applique également aux sous-secteurs jouant un rôle central dans les transactions financières, le secteur bancaire, la compensation et le règlement.

Risques liés aux fournisseurs tiers de TIC
DORA met un accent particulier sur la surveillance de l’UE, sur ce que l’on appelle les fournisseurs tiers de TIC et sur le risque de tiers en matière de TIC qui en découle. L’externalisation de fonctions numériques joue aujourd’hui un rôle important dans la stratégie TIC des entreprises financières. C’est là que les fournisseurs tiers de TIC entrent en jeu. Ils proposent aux entreprises financières la mise à disposition d’espace de stockage ou de performance informatique (Infrastructure as a Service) jusqu’à la mise à disposition d’applications logicielles (Platform as a Service).
L’externalisation ne peut fonctionner que si les institutions financières sont en mesure de surveiller et de contrôler pleinement les processus de sous-traitance. Les entreprises financières qui font appel à des services liés aux TIC de fournisseurs tiers de TIC ont la responsabilité de s’assurer que ces derniers respectent le règlement DORA (art. 25, par. 1). Toutefois, si une entreprise financière constate que le fournisseur tiers de TIC ne respecte pas les lois, les règlements ou les conditions contractuelles en vigueur lors de la fourniture de services informatiques, le contrat avec ce fournisseur doit être résilié (art. 25, par. 8). Les entreprises financières doivent mettre en place des stratégies de sortie pour faire face aux défaillances des prestataires de services tiers liés aux TIC. La résiliation du contrat ne doit pas être contraire aux exigences réglementaires ou affecter la qualité des services offerts (art. 25, par. 9).
En résumé, DORA vise à créer un cadre de surveillance européen pour les fournisseurs tiers de TIC « critiques » (art. 28, par. 1). DORA accorde à l’entreprise financière le droit de surveiller intégralement les prestations à fournir par le fournisseur tiers de TIC (art. 27, par. 2). Dans ce cadre, les autorités de surveillance financière compétentes peuvent forcer les entreprises financières à suspendre temporairement, partiellement ou totalement, leurs contrats avec des fournisseurs TIC tiers, jusqu’à ce que les risques soient éliminés. Les autorités peuvent, si nécessaire, exiger des entreprises financières qu’elles mettent fin à tout ou partie des accords contractuels pertinents conclus avec des prestataires tiers critiques de TIC (art. 37, par. 3).
Avant de conclure un contrat avec un fournisseur tiers TIC, les institutions financières et les prestataires de services financiers doivent vérifier si le fournisseur informatique en question doit être considéré comme un fournisseur critique ou s’il couvre des fonctions numériques importantes. Les institutions financières et les prestataires de services financiers doivent vérifier si votre fournisseur tiers TIC est remplaçable ou si plusieurs contrats sont conclus avec lui (art. 25, par. 5). L’évaluation de ces critères est importante dans la mesure où les entreprises financières ne peuvent pas entretenir de relations contractuelles avec des fournisseurs tiers TIC critiques qui ont leur siège en dehors de l’UE et ne sont donc pas basés dans l’UE (art. 28, par. 9).

Source de la figure : EU Digital Operational Resilience Act (DORA) | Compliance | Haufe

Auteurs : Salar Hydary, Judith Petersen

En savoir plus

SEPA 2.0 bat son plein – la migration vers les nouvelles spécifications de format commence !

Depuis novembre 2021, de nouvelles spécifications de format de la Deutschen Kreditwirtschaft sont en vigueur. Jusqu’à présent, les changements n’ont pas eu d’impact important sur les institutions financières et leurs clients. Cependant, en novembre 2023, cela changera brusquement !

Les formats SEPA pour les virements et les prélèvements changent en profondeur et tous les prestataires de services de traitement des paiements ainsi que leurs clients finaux doivent se préparer aux changements imminents et s’y préparer.

Du fait que SEPA 2.0 affectera effectivement tous les composants et tous les systèmes, gérer en amont le sujet et toutes ses interdépendances est d’une grande importance pour un procédé sans heurt et un traitement ultérieur ininterrompu des paiements.

En juin de cette année, l’EPC a publié des directives d’implémentation qui, outre les spécifications correspondantes, fournissent des informations supplémentaires sur les modifications à venir. L’utilisation de données d’adresses structurées est un thème essentiel des adaptations futures. Jusqu’à présent, les adresses pouvaient être soumises et traitées de manière non structurée en indiquant le nom et l’adresse, mais avec SEPA 2.0, les adresses doivent être indiquées de manière structurée. Il y aura dorénavant des champs spécifiques pour le nom, la rue et le numéro, le code postal et le code ISO du pays. Outre l’utilisation de données d’adresses structurées, les adaptations de certains champs, comme l’identifiant de batch booking, ont des conséquences importantes. Le nouveau paramètre par défaut true de l’identifiant de batch booking permettra à l’avenir d’effectuer une écriture collective. Ce n’est que s’il existe un accord correspondant avec le client pour les écritures unitaires que chaque transaction sera représentée individuellement sur le relevé de compte du payeur (donneur d’ordre) en cas de valeur false.

Les changements à venir n’ont donc pas uniquement des répercussions sur le fichier de paiement et les systèmes de paiement en tant que tels, mais affectent également les systèmes périphériques, tels que les systèmes de données de base. De nombreuses institutions financières utilisant des solutions de conversion ou d’anciennes versions du format SEPA peuvent désormais revoir leurs systèmes dans leur ensemble dans le cadre d’un projet et assurer un traitement ultérieur des paiements sans faille. Selon cette procédure, il est recommandé de recourir à des tableaux de correspondance qui rendent les analyses, évaluations et recommandations de mise en œuvre plus aisées et plus ciblées. Il est ainsi possible d’établir des règles et des mécanismes propres à chaque institution.

La consolidation TARGET2/T2S a déjà montré que la migration du format MT vers le format MX ne doit pas être sous-estimée et que les projets correspondants prennent plus de temps que de nombreuses institutions ne l’avaient pensé. Un report de calendrier par le Conseil de la BCE a été avantageux pour de nombreuses institutions financières. Un report et de nouveaux scénarios de transition allant au-delà des scénarios des directives d’implémentation ne doivent toutefois pas être présupposés lors de la migration vers SEPA 2.0. Les institutions qui ne privilégient pas un démarrage précoce s’exposent à un risque énorme.

Auteur : Rebecca Stannull

En savoir plus

La numérisation mise en pratique – l’échange de clés par lettre INI

Depuis l’introduction des clés cryptographiques dans les services bancaires en ligne, tant pour les particuliers que pour les professionnels, le processus d’échange des clés publiques de l’institution financière et de l’utilisateur était toujours long et compliqué. Il est vrai que le processus est particulièrement pénible pour les utilisateurs ; pour le reste de l’humanité, c’est un mystère absolu :

La procédure de lettre INI s’est établie dans ce contexte. Utilisée depuis plus de 15 ans, elle constitue toujours un obstacle à l’utilisation d’EBICS, par exemple. Générer des clés, les envoyer, puis imprimer la lettre INI sur papier, la signer et la transférer à l’institution financière sont des opérations compliquées et fastidieuses pour nombre d’utilisateurs. Le traitement au sein même de l’institution financière, où un employé reçoit la lettre INI, ouvre le compte client correspondant dans le système EBICS et doit y comparer les valeurs de contrôle du transfert électronique avec les valeurs figurant sur la lettre INI, voire les saisir, est également laborieux. Il faut bien entendu vérifier également la signature apposée dans les données du compte ou sur le contrat. Cela ne ressemble pas du tout à la numérisation qui doit pourtant accompagner nos opérations commerciales.       

Simplifier la validation des clés EBICS
Pourtant, tout serait beaucoup plus simple si les institutions financières détachaient le processus décrit ci-dessus de leurs propres employés, le numérisaient entièrement et le déléguaient ainsi à l’utilisateur. La première étape à mettre en œuvre est la vérification indubitable de l’identité de l’utilisateur en échangeant d’un secret convenu ensemble (par exemple un TAN) ou – si elle existe déjà – une session en ligne activée garantissant que l’utilisateur est bien la bonne personne. En règle générale, cela s’applique déjà à chaque session bancaire en ligne connectée ! Si nous supposons maintenant que le système bancaire peut contacter l’utilisateur de manière active et en ligne après une remise de clé réussie, par exemple par smartphone avec un SMS, une application ou via une session bancaire en ligne, alors il serait tout de même possible que cet utilisateur puisse confirmer lui-même le caractère correct de sa transmission de clé et ainsi valider ses clés EBICS dans les plus brefs délais.

Seulement lui !
L’utilisateur peut le faire lui-même, car le système bancaire – par exemple grâce à l’exactitude du TAN demandé – a validé son identité . L’utilisateur ne compare alors plus que les valeurs de contrôle de la lettre INI et de l’affichage dans le système bancaire et confirme leur exactitude. Il se peut aussi qu’il doive les saisir à nouveau lui-même. C’est donc exactement ce que fait l’employé de l’institution financière. Bien entendu, le système bancaire consigne cette validation par l’utilisateur afin de pouvoir prouver ultérieurement que l’utilisateur a vérifié l’opération.

La numérisation mise en pratique
L’utilisateur du protocole EBICS peut utiliser son nouvel accès en quelques minutes. Il ne sera plus nécessaire d’imprimer les documents et de les transférer à l’institution financière concernée. Le délai d’attente initial de plusieurs jours est réduit à quelques minutes. L’institution financière évite les processus internes manuels à la fois complexes et coûteux de la validation des clés. Les documents transmis, à savoir la lettre INI, ne doivent plus être archivés. La consignation numérique de la nouvelle procédure est suffisante et ne nécessite plus de saisie/numérisation manuelle de la lettre INI. La satisfaction des clients et l’acceptation de la procédure EBICS sont renforcées, les institutions financières économisent des frais de personnel et d’édition ultérieure manuelle. La numérisation mise en pratique, une situation gagnant-gagnant claire !

Auteur : Michael Schunk

 

En savoir plus

Quelle est la relation entre CESOP et la législation sur la TVA par rapport aux paiements transfrontaliers ?

Soyons honnêtes, lorsque nous entendons le mot « droit fiscal » dans notre secteur d’activité, nous ne pensons pas forcément qu’il s’agit de quelque chose de pertinent et lié aux transactions financières. Il est évident que toutes les parties impliquées utilisent des moyens de paiements pour régler leurs obligations fiscales, mais cela n’en fait pas pour autant un sujet de réglementation du droit fiscal. Cependant, la mauvaise nouvelle est qu’à l’avenir, nous devrons toujours être un peu plus attentifs quant à la directive TVA de l’UE.

La surcharge comme cause

Dans le cadre du plan d’action visant à créer un espace unique de TVA, la Commission européenne est inévitablement confrontée au problème de la fraude à la TVA. L’utilisation croissante du commerce électronique pour la vente transfrontalière de biens et de services dans les États membres accroît particulièrement cette situation.

Les autorités chargées des investigations sont confrontées à des limites pour collecter les informations, qui sont lacunaires de surcroît. Les informations nécessaires sont souvent détenues par des tiers (comme les prestataires de services de paiement) généralement basés dans un autre État. S’ajoutent à cela, des capacités administratives insuffisantes qui sont surchargées par le volume important de données nécessaire à la détection de la fraude à la TVA. Cela concerne aussi bien l’échange que le traitement des quantités de données correspondantes.

La Commission européenne estime la perte de recettes fiscales de trois chiffres en milliards (https://op.europa.eu/en/publication-detail/-/publication/bd27de7e-5323-11ec-91ac-01aa75ed71a1/language-en/). Pour remédier à cette situation du point de vue du législateur européen, les règlements existants jusqu’à présent ont été complétés en ce sens le 18 février 2020.

Règlement (UE) 2020/283 du Conseil du 18 février 2020 modifiant le règlement (UE) n° 904/2010 en ce qui concerne des mesures de renforcement de la coopération administrative afin de lutter contre la fraude à la TVA

• Définition de la coopération entre les autorités fiscales nationales afin de détecter la fraude à la TVA et d’assurer le respect des obligations en matière de TVA.

Directive (UE) 2020/284 du Conseil du 18 février 2020 modifiant la directive 2006/112/CE en ce qui concerne l’instauration de certaines exigences applicables aux prestataires de services de paiement
Modifications de la directive sur la TVA :

• Les prestataires de services de paiement seront obligés de conserver les données sur les paiements transfrontaliers liés au commerce électronique.
• Les données doivent être mises à la disposition des autorités fiscales nationales. Des conditions strictes (notamment en matière de protection des données) doivent être prises en considération.

Directive (UE) 2020/285 du Conseil du 18 février 2020 modifiant la directive 2006/112/CE relative au système commun de taxe sur la valeur ajoutée en ce qui concerne le régime particulier des petites entreprises et le règlement (UE) n° 904/2010 en ce qui concerne la coopération administrative et l’échange d’informations aux fins du contrôle de l’application correcte du régime particulier des petites entreprises
Outre d’autres dispositions relatives à la coopération des autorités administratives, de nouvelles dispositions spéciales pour les petites entreprises ont été introduites à l’échelle européenne :

• Les petites entreprises ayant leur siège dans d’autres États membres peuvent désormais bénéficier du régime particulier des petites entreprises.
• Leur chiffre d’affaires annuel ne doit pas dépasser 85 000 euros (limite fixée par l’État membre).
• Selon certaines conditions, ce chiffre d’affaires peut atteindre 100 000 euros, sous réserve qu’il ait été réalisé dans toute l’UE.

 
À partir du 1er janvier 2024, la directive 2020/284/EU obligera les prestataires de services de paiement à partager leurs informations avec les autorités fiscales, autrement dit à améliorer l’accès à l’information du point de vue des autorités. À cette fin, la directive impose aux prestataires de service de paiement de déclarer de manière centralisée certaines données de paiement que les autorités doivent utiliser en cas de soupçon pour mener leur enquête plus facilement.

CESOP – données de paiement dans la conservation des données

Le mot-clé pour la conservation des données fournies est « CESOP » (Central Electronic System of Payment Information, en français : système électronique central concernant les informations sur les paiements) – un système central de l’UE, placé sous la supervision d’EUROFISC. Il doit non seulement enregistrer les données fournies, mais également les rendre consultables, permettre la recherche intelligente des enregistrements redondants, rendre visibles les corrélations, etc.

Seules les autorités fiscales des États membres y auront accès. Tout cela, évidemment, est en conformité avec les autres droits. L’intérêt général d’éviter les dommages causés par la fraude fiscale, se chiffrant en milliards, dépasse dans ce cas le droit de l’individu à la confidentialité des données. 

Quels paiements doivent être déclarés par qui ? 

Chaque fois que des prestataires de services de paiement fournissent des services de paiement pour plus de 25 paiements transfrontaliers au cours d’un trimestre calendaire au même bénéficiaire du paiement, indépendamment du montant de la transaction, ceux-ci doivent être déclarés. Les données doivent être conservées pendant au moins trois années calendaires.

Prestataires de services de paiement européens

Si le paiement est versé à un bénéficiaire du paiement dans l’UE, l’obligation comptable incombe au prestataire de services de paiement du bénéficiaire du paiement.

Si le paiement est versé par un payeur dans l’UE vers un bénéficiaire du paiement dans un pays hors l’UE, l’obligation comptable incombe au prestataire de services de paiement du payeur.

Fournir, mais comment ?

Le lecteur désormais intéressé se demandera certainement : « D’accord, une nouvelle obligation de déclaration. Mais comment introduire les données dans CESOP ? » La bonne et la mauvaise nouvelle sont que vous, en tant que prestataire de services de paiement, n’avez pas à le faire, car CESOP est « alimenté » par les autorités nationales. Dans ce contexte, le type d’interface et le format de fourniture et de données sont déjà précisés. En revanche, ce qui n’est pas clarifié – et c’est la mauvaise nouvelle – est comment les prestataires de services de paiement doivent à leur tour transmettre les informations aux autorités nationales après les avoir récupérées dans leurs systèmes (si toutefois elles disposent déjà aujourd’hui de cette fonctionnalité).

Les directives nécessitent une mise en œuvre par le législateur national. Elles se distinguent donc des règlements quant à leur mode d’action (indirect). Les règlements sont directement en vigueur et doivent être appliquées directement. Les législateurs allemands n’ont pas encore examiné les modifications de la directive sur la TVA ; ils n’ont donc pas encore commencé à les transposer. Après tout, ils ont jusqu’au 31/12/2023 pour le faire (souvenez-vous que l’utilisation doit commencer le 01/01/2024) et ils attendent actuellement les autres développements au niveau de l’UE (ce qui n’est pas forcément une mauvaise chose). 

Dans le cadre de la transposition, le législateur allemand est libre de décider s’il préfère une adaptation à l’identique ou qu’il adopte des règles plus strictes. Une déviation du texte de la directive serait également légitime. Les détails pourraient donc se trouver dans la mise en œuvre par le législateur allemand.

Conclusion

La législation européenne sur la TVA est désormais connectée aux transactions financières et impose aux prestataires de service de paiement l’obligation de fournir des informations aux autorités fiscales des États membres.

La situation juridique au niveau national et la manière dont elle sera mise en œuvre ne sont pas encore clarifiées. Par ailleurs, les moyens techniques par lesquels les informations seront transmises à l’autorité nationale responsable ne sont pas encore précisés. Cela ne signifie pas pour autant que les prestataires de services de paiement peuvent se reposer, car l’agrégation des données, l’orchestration de la mise en œuvre du reporting ne doivent pas être sous-estimées.

Auteur : Benjamin Schreck

En savoir plus

Projet possible dans les transactions financières transfrontalières

Avez-vous déjà essayé de convaincre votre réseau international de 11 000 participants d’escalader ensemble le mont Everest ? Un projet impossible, direz-vous. Pour être honnête, la plupart d’entre nous n’y parviendraient pas à cause de l’absence de réseau. Pourtant, la Society for Worldwide Interbank Financial Telecommunication (SWIFT) a réussi, depuis sa création en 1973, à constituer un réseau suffisamment important et à lancer le projet (im)possible – cependant il ne s’agit pas d’escalader réellement le mont Everest, mais de renouveler l’interface de messagerie dans les paiements internationaux.

Épreuve de force en novembre 2022

Quiconque se rend aujourd'hui dans les bureaux de paiement des institutions financières à travers le monde voit le projet (im)possible partout. Permettez-moi de vous résumer brièvement la situation :
 
SWIFT changera la base de communication actuelle à partir de 2022. Alors que la communication dans les transactions financières internationales repose aujourd’hui sur les transactions MT selon l’ISO 15022, une migration vers les transactions MX aura lieu à partir de 2022. Les transactions MX ont été définies par un groupe de travail international Cross-Border-Payments and Reporting (CBPR+) et se basent sur le standard ISO 20022. Pour cette raison, les termes transactions CBPR+ ou transactions MX sont souvent utilisées. Le champ d’application comprend les formats de transactions des domaines paiements, reporting et investigation. Dans l’ancien environnement MT, cela correspond aux catégories MT1xx, MT2xx et MT9xx.

Les nouvelles transactions sont également envoyées via une nouvelle interface. Le canal InterAct-(FIN+) sera ouvert aux transferts de paiements à partir de novembre 2022. Une migration complète de FIN vers le canal InterAct-(FIN+) est fixée à novembre 2025. SWIFT désigne la période entre novembre 2022 et novembre 2025 comme une « période de coexistence » et parle d’une migration « user driven ». Chaque institution financière du réseau SWIFT peut décider elle-même de la date à laquelle elle passera à MX en sortie. Il faudra toutefois s’attendre à des transactions MX dans la réception à partir de novembre 2022.
 
Un projet de migration supposé petit se transformant en l’un des plus grands défis dans le domaine des paiements au cours des dernières années. Les anciens systèmes hôtes, le traitement de nouveaux champs de données, la coordination avec les institutions financières partenaires et les conditions en modification permanente entraînent toujours de nouveaux défis et de nouvelles questions qui doivent être résolus :
 
En tant qu’institution financière, quand dois-je effectuer la migration ? Que se passe-t-il avec les éléments Rich Data ? Dois-je sauvegarder tous les sous-éléments ou puis-je peut-être renoncer à la Garnishment Remittance ? Que se passe-t-il exactement entre novembre 2022 et novembre 2025 ? Quel est le minimum requis pour novembre 2022 ?
 
Avec novembre 2022, SWIFT a fixé le point de lancement de la mise en service le plus tôt possible. Il reste donc trois mois aux institutions financières pionnières pour répondre aux dernières questions urgentes, corriger les derniers défauts et informer les derniers clients. Les institutions financières pionnières, représentant plus de 50 % du volume total des transactions transfrontalières selon SWIFT, sont prêtes et pourtant, il reste encore des changements et des recommandations qui peuvent remettre en question la mise en service.

Trop tard pour faire demi-tour

Le report du gestionnaire de transactions de SWIFT à la fin du premier trimestre 2023 au lieu de novembre 2022 fait partie des grandes frayeurs. Le gestionnaire de transactions a longtemps été présenté comme une application SWIFT « salvatrice », censée assurer un échange de messages sans troncature sur l’ensemble de la chaîne de paiement grâce à la sauvegarde d’une « copie dorée ». Qu’il s’agisse d’envoyer ou de traiter des transactions MX contenant beaucoup d’informations ou des transactions MT rudimentaires, le gestionnaire de transactions devrait à chaque fois compléter les transactions avec la diversité des données envoyées à l’origine et garantir ainsi la transmission cohérente de toutes les informations. Maintenant, avec le retard, la crainte de perdre des informations importantes se fait sentir.
 
Afin de résoudre ce problème, le PMPG (Payment Market Practice Group) a publié en juillet une recommandation visant à renoncer aux Rich Data jusqu’en novembre 2023 (https://www.swift.com/swift-resource/251867/download). Les Rich Data sont les informations qui seront désormais transmises avec les transactions MX. Une institution financière peut légitimement se demander s’il est judicieux de poursuivre le projet si une telle incertitude persiste.
 
Mais il est trop tard pour opérer un demi-tour. Le budget du projet a été accordé, les équipes de développement sont en plein développement, les premières versions ont déjà été mises en œuvre, le plan de lancement interne est prêt, les campagnes de communication sont en cours et le planning du projet pour les prochains mois est déjà rempli. Quelle que soit le degré d’agilité qu’une institution financière souhaite adopter, un projet de migration qui touche l’ensemble de l’institution financière, de la banque en ligne à la réconciliation des comptes en passant par le traitement de base, ne peut pas être arrêté facilement.

Nous avons atteint le camp de base - l’ascension est encore devant nous

SWIFT pousse ses participants à monter le mont Everest avec une rigueur réglementaire et de marché et, comme c’est le cas dans toute randonnée, certains sont plus en avant et d’autres sont un peu en arrière. Ce qui est sûr, c’est qu’un certain nombre d’institutions financières émettra des transactions MX à partir de novembre 2022. Mais ont-elles déjà atteint le sommet qu’elles visaient ? En regardant ce qui a été réalisé et le champ d’application envisagé par SWIFT, on ne peut parler que d’atteindre le camp de base - l’ascension est encore une étape à venir. La surveillance de la production, les efforts supplémentaires dans l’exploitation, la conversion des messages de reporting, la conversion des messages d’investigation, le traitement des éléments Rich Data et les éventuelles modifications et propositions de la part de SWIFT devraient faire en sorte que le projet (im)possible continue à faire partie intégrante de l’agenda de projets de nombreuses institutions financières.
 
En conclusion, il faut retenir que la SWIFT Community bouleverse actuellement en profondeur les paiements transfrontaliers et construit, avec la migration vers l’ISO 20022, une base susceptible d’améliorer et d’optimiser les transactions financières à long terme. Même si les avantages tant promis de données structurées et granulaires, d’une meilleure qualité des données, de meilleures possibilités d’analyse et d’une interopérabilité internationale ne se concrétiseront pas encore en 2022 ou 2023, la base est posée pour davantage de progrès. Nous sommes impatients de voir ce qui va se passer dans les prochaines années dans le domaine des paiements internationaux.
 
Où en êtes-vous actuellement avec votre projet de migration SWIFT MX et comment voyez-vous la situation actuelle ? Faites-le nous savoir ou laissez-nous un commentaire.
 

Auteur : Florian Stade

En savoir plus

Les institutions financières joueront-elles un rôle dans la mise en œuvre de l’euro numérique ?

La phase d’analyse de deux ans de la Banque centrale européenne (BCE) sur l’euro numérique n’est pas encore terminée et de nombreuses questions restent actuellement sans réponse. Toutefois, les premières tendances se dessinent déjà sur certains sujets, comme le modèle de mise en œuvre ou la répartition des rôles.

 

Différents scénarios de mise en œuvre sont actuellement discutés en considérant les conditions de base d’une monnaie numérique de la Banque centrale (CBDC), comme les titres analogues à des quasi-espèces, la protection de la vie privée, les paiements peer-to-peer faciles à utiliser pour l’utilisateur et une distribution à grande échelle.

Dans cet article, nous aborderons deux scénarios de mise en œuvre répandus :

1. CBDC direct

Dans le cadre de l’approche directe, la Banque centrale européenne développerait l’euro numérique en toute autonomie et constituerait l’interface avec les utilisateurs.

Par conséquent, la BCE est responsable de la mise en place de l’infrastructure, de l’exploitation du système, de l’accueil des nouveaux clients et du traitement des paiements.
Toutes ces tâches demandent des efforts considérables de la part de la BCE, car outre le développement du back end et du front end, l’administration et la gestion ultérieures incombent à la BCE. Les clients doivent par exemple être guidés à travers des processus tels que les contrôles KYC et AML. En outre, nous ne savons pas encore si les utilisateurs auront un compte séparé auprès de la BCE pour les activités de paiement.

Outre les facteurs d’effort et de temps, l’écosystème actuel est également compromis, car ni les banques commerciales ni les prestataires de services financiers n’agissent en tant que distributeurs à l’interface client-banque.

Le scénario de CBDC indirect est donc beaucoup plus probable :

2. CBDC indirect

Dans ce modèle, l’euro numérique est émis par la BCE et distribué au consommateur final par le biais d’intermédiaires approuvés, tels que les institutions financières et les prestataires de services de paiement. La distribution sera comparable au système actuel d’argent liquide, mais sous forme numérique. Par conséquent, l’utilisateur n’a pas de contact direct avec la Banque centrale, mais dispose d’un droit légal direct vis-à-vis de celle-ci.

Le modèle renforcerait l’écosystème existant en préservant le rôle des intermédiaires et en les impliquant dans la fourniture de l’euro numérique.
Outre la gestion, les intermédiaires pourront se fonder sur des processus établis (notamment les contrôles KYC et AML), des processus d’accueil et des développements de front end.
Dans ce modèle, il faut également tenir compte du fait que le développement de services à valeur ajoutée peut être lié aux cas d’application existants des institutions financières et de l’euro numérique. La capacité d’innovation est augmentée et les consommateurs peuvent espérer une expérience utilisateur optimisée.

Pour les raisons susmentionnées, nous partons actuellement du principe que les banques commerciales seront impliquées dans la distribution de l’euro numérique afin de profiter des processus établis et de renforcer le contact direct avec la clientèle. Toutefois, il reste à déterminer si, outre les banques commerciales classiques, d’autres prestataires peuvent jouer le rôle d’intermédiaire.

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 régulièrement des nouveautés sur l’euro numérique au moyen de ce blog.

En savoir plus

Une étape importante vers l’unité

À partir de fin 2023, le cercle des utilisateurs de l’Electronic Banking Internet Communication Standard (EBICS) s’élargira : en novembre prochain, la migration des systèmes de paiement de la norme propriétaire Multi Bank Standard (MBS), utilisé jusqu’ici, commencera en Autriche. Pour les entreprises de la République alpine, ce changement représente tout d’abord du travail, mais présente pour finir des avantages évidents. En effet, avec EBICS, il existe une connexion fluide au plus grand espace de paiement européen autour de l’Allemagne et de la France. En outre, les institutions financières ne laisseront évidemment pas leurs clients seuls durant la migration. En revanche, les institutions doivent d’abord faire leurs propres devoirs. Dans une interview commune, Thomas Bargehr, chef de produit Banking Solutions and Payment Services, Hypo Vorarlberg Bank AG, et Michael Lembcke, chef de produit chez PPI AG, parlent du calendrier, des avantages et des procédures.

 

1. Monsieur Bargehr, en juillet 2020, le secteur de crédit autrichien a déclaré son adhésion à la société EBICS, et depuis, l’introduction auprès des institutions financières est en cours. Où en est votre institution et comment se présente la suite du calendrier ?
   Actuellement, nous coordonnons au sein du PSA (Payment Service Austria) les exigences relatives aux interfaces de migration automatiques. Celles-ci serviront à transférer les données et les méthodes d’autorisation des anciens logiciels et données de base MBS. La migration de MBS vers EBICS pourra ainsi se faire de manière aisée pour les utilisateurs. Selon le plan de projet national, la migration elle-même devrait suivre à partir de novembre 2023. À partir de cette date, tous les clients professionnels devront également migrer vers EBICS.
    
2. Monsieur Lembcke, les institutions financières allemandes utilisent EBICS depuis un certain temps déjà et aucun problème n’a été signalé. Quels sont les avantages de ce standard pour les institutions de crédit, par rapport à MBS ?
   Pour les entreprises clientes, il est surtout important de disposer d’une capacité multibancaire transfrontalière. Trop de standards nationaux ou de procédures différentes entraînent un surcroît de travail et perturbent les processus. Une uniformisation favorise en outre une éventuelle automatisation des processus dans le sens d’un Straight Through Processing (STP). Au niveau de l’architecture, EBICS permet une conception innovante et moderne des systèmes de paiement.
    
3. Monsieur Bargehr, le développement de MBS a été arrêté, les entreprises clientes devront donc un jour passer à EBICS. Cela entraîne du travail pour vos entreprises clientes, qu’est-ce qui justifie cette mesure ?
   Depuis l’introduction de l’euro, les paiements et, par conséquent, les formats à prendre en charge par le logiciel client, sont soumis à des changements constants. Les entreprises sont donc déjà habituées à des changements tous les deux ou trois ans. En règle générale, les éditeurs de logiciels de planification des ressources accompagnent ces évolutions à temps et de manière très qualitative. Il en va de même pour notre propre institution, qui se considère toujours comme un partenaire fiable aux côtés des clients.
    
4. Monsieur Lembcke, PPI AG est leader du marché des solutions EBICS et a accompagné le standard dès le début. Comment se déroule l’introduction en Autriche du point de vue d’un conseiller en paiements ?
   Jusqu’à présent, aucun problème significatif n’a été identifié. Le défi consiste tout simplement à rendre la transition aussi fluide que possible pour toutes les parties concernées. En tant que fabricant de logiciels EBICS, nous sommes naturellement sollicités pour fournir des solutions. Bien entendu, Avec MBS, l’Autriche disposait déjà d’un standard d’eBanking opérationnel. Mais à l’avenir, les institutions et les entreprises clientes autrichiennes disposeront désormais d’un standard européen multibancaire, basé sur des architectures modernes, et pourront réaliser des opérations de paiement nationales et les pérenniser sur le long terme.
    
5. Monsieur Bargehr, une telle migration des normes de traitement des données est loin d’être une affaire triviale. Comment garantissez-vous que tout ira bien et qu'il n’y aura pas de temps d’arrêt ?
   Bien avant le début de la migration, nous évaluons la situation actuelle du client et déterminons ainsi très tôt les exigences particulières en matière de technique et d’assistance. En conséquence, nous accompagnons ensuite les entreprises jusqu’à la migration. La clé du succès est un transfert correct des accès clients vers le serveur EBICS, une période de transition à la fois courte et gérable, ainsi qu’un service client de qualité.
    
6. Monsieur Lembcke, PPI AG a accompagné de nombreux projets de migration vers EBICS. Quelle est la procédure que vous recommandez à une institution financière ?
   Il n’existe pas de solution unique, la méthode dépend fortement de la stratégie et de la structure cliente de chaque institution. Il est donc tout à fait envisageable de procéder à une migration big bang, dans laquelle tous les clients migrent en une seule fois. Mais les scénarios de migration par étapes sont tout aussi justifiés, même si une exploitation parallèle d’EBICS et de MBS est nécessaire. Le dialogue avec les entreprises clientes, dont le plan de migration doit être consulté, est important. En tout état de cause, rien ne justifie des temps d’arrêt, une migration en cours d’exploitation est tout à fait réalisable.
    
7. Monsieur Bargehr, EBICS présente des différences régionales, la France a par exemple insisté sur certaines adaptations locales. Existe-t-il également en Autriche des divergences par rapport par rapport à la version standard d’EBICS ?
   Même si EBICS n’est pas encore un standard en Autriche, la plupart des institutions financières exploitent déjà des serveurs et des clients correspondants en raison des exigences du marché. Elles procèdent toutefois différemment : certaines achètent des solutions toutes prêtes et les exploitent sans les adapter aux spécificités nationales. D'autres en revanche – Hypo Vorarlberg en fait partie – analysent justement ces exigences locales et en tiennent compte lors de la conception de leurs systèmes clients. Pour nous, PPI a intégré les cas particuliers dans les solutions de paiement. C’est pourquoi nous sommes déjà entièrement prêts pour EBICS depuis 2017.
    
8. Monsieur Lembcke, EBICS 3.0 a-t-il le potentiel de mettre fin à la discussion sur la nécessité d'API supplémentaires conformes à la DSP2 ?
   Il s’agit en fin de compte d’une discussion dont le résultat ne peut être une décision. En effet, tout comme EBICS est un standard établi et maîtrisé par toutes les institutions, les API font également partie intégrante du paysage informatique en raison de leur quantité. Les deux coexisteront encore plus longtemps.
    
9. Monsieur Bargehr, quelle sera la stratégie de la banque Hypo Vorarlberg ? Allez-vous proposer des interfaces supplémentaires ou misez-vous entièrement sur EBICS ?
   Les petits clients peuvent continuer à utiliser notre banque en ligne comme d’habitude. Toutefois, chez nous, les petites et moyennes entreprises ainsi que les grands clients travailleront à l’avenir exclusivement avec EBICS. Nous profitons de la migration EBICS pour désactiver peu à peu les anciens systèmes de paiement et bancaires et ainsi éviter les procédures redondantes.
    
10.  Monsieur Lembcke, il se passe actuellement beaucoup de choses dans les paiements européens, comme la migration SWIFT ou la demande de paiement (Request to Pay - RTP). Quelle est la place d’EBICS dans ce contexte ?
    Ce standard satisfait à toutes les conditions importantes pour harmoniser les changements prévisibles dans les paiements européens. Pour cette raison, tout devrait être fait pour introduire EBICS officiellement dans d’autres pays. Ce faisant, il faut également veiller à uniformiser le mode d’utilisation afin d’améliorer l’acceptation. Les domaines d’application sont déjà très variés. Les paiements instantanés SEPA peuvent par exemple être traités avec EBICS, et RTP est pris en charge dans la communication interbancaire. Pour participer aux transactions financières futures, EBICS est le ticket d’entrée !

En savoir plus

La Retail Payments Strategy de l’UE – résultat intermédiaire

Dans l’article d’aujourd’hui, nous traitons le sujet du développement de la European Payments Strategy dans le cadre d’une courte interview. Quels sont les progrès, les nouveautés et les perspectives ? Nous avons invité notre collègue Swaantje, expert dans le domaine, pour un entretien.

Blog EBICS :
Bonjour Swaantje ! Je suis heureux que tu prennes le temps d’aborder ce sujet avec nous. Pour commencer, est-ce que tu peux nous parler un peu de toi ?

Swaantje :
Bonjour ! Oui, avec plaisir. Je m’appelle Swaantje Völkel, je suis consultante dans le domaine du conseil en paiements pour PPI AG à Hambourg et je me consacre aux adaptations initiées au niveau européen. Il en va de même pour la Digital Finance Strategy de l’UE et, plus concrètement, la Retail Payments Strategy de l’UE.

Blog EBICS :
Quel est le plus grand défi dans ce domaine ?

Swaantje :
Tout d’abord, une stratégie n’est pas une loi, mais seulement une sorte de déclaration d’intention, un plan général pour l’avenir, pour des événements futurs. Il n’y a pas d’obligations ni de délais à respecter, c’est un processus de croissance qui demande de l’observation, de l’interprétation, de l’expérience et du jugement.

Blog EBICS :
Le désir d’autonomie est donc fort, mais la motivation de le rendre obligatoire faible ?

Swaantje :
La Retail Payments Strategy de l’UE fait partie de la Digital Finance Strategy l’UE. Les deux sont notamment poussés par la Open Strategic Autonomy de l’UE et doivent la soutenir. Oui, c’est vrai – l’accent est clairement mis sur la promotion de la Open Strategic Autonomy de l’UE. La Retail Payments Strategy de l’UE décrit 17 mesures de taille et d’impact différents. L’un des thèmes principaux est la vérification de la DSP2, c’est là que nous intervenons chez PPI.

Blog EBICS :
Est-ce que cela signifie que les activités deviennent plus concrètes sur ce point et que l’on peut se préparer à des changements ?

Swaantje :
En effet. Le travail commence à devenir plus concret : dans deux consultations, nous demandons actuellement un feedback sur les objectifs de la DSP2, y compris sur le degré de réussite de la DSP2 dans la réalisation de ses objectifs. En outre, les retours concernent aussi la mise en œuvre de la DSP2 par les autorités de régulation nationales et sur les éventuelles modifications qu’ils estiment devoir être apportées à la directive. Il est également demandé si le champ d’application, les mesures et les procédures de la DSP2 sont appropriés, tout en adoptant une approche tournée vers l’avenir. Les réponses à ces consultations doivent être soumises dès maintenant, durant l’été.

Blog EBICS :
C'est justement l’estimation de la charge de travail qui est décisive – peut-on formuler une hypothèse à ce stade ?

Swaantje :
La DSP2 a entraîné de très grands changements en introduisant l’accès aux comptes par les prestataires tiers et de nouvelles exigences en matière d’authentification forte des clients. Après l’examen et la modification de la DSP2, nous comptons sur des changements, mais pas aussi profonds que ça. Mais il peut déjà en résulter des changements importants et majeurs – en revanche pas aussi importants que lors de l’introduction initiale de la DSP2. En fin de compte, nous avons beaucoup de travail à réaliser – car de petits changements peuvent avoir de grandes conséquences et vice versa, c’est pourquoi je me garde bien de faire des prévisions.
 
Blog EBICS :
Est-ce utile de partir sur des bases aussi floues ?

Swaantje :
C’est pourtant là que réside la phase créative précieuse qui nous a toujours fourni des connaissances utiles jusqu’à présent. Je me réfère à la difficulté de trouver le chemin la dernière fois. Mais nous espérons secrètement que le chemin vers la DSP3 ne sera pas aussi long qu’à l’époque. En particulier, le travail de lobbying permanent qui, d’une part, fait progresser la stratégie, mais qui, malheureusement, met aussi en évidence de nombreux souhaits concurrents, les évalue et tente de les concilier, favorise les retards. Ce n’est pas un aspect accélérateur.

Blog EBICS :
En toute honnêteté, quand peut-on espérer un achèvement du projet de DSP3 ?

Swaantje :
En 2023 ! (rit)

En savoir plus

Grand moment lors du groupe d’utilisateurs TRAVIC 2022 - Payments-as-a-Service en double exemplaire

Après une pause forcée de trois ans, le groupe d’utilisateurs TRAVIC a enfin pu se réunir en présentiel. Les nouveautés relatives à la gamme de produits TRAVIC et les ateliers liés aux produits ont été présentés et les besoins et les questions ont été abordés en profondeur dans un cadre commun. Mais ce n’est pas tout : les très attendus présentateurs invités, Alexander Merkel (Deutsche Bundesbank) et Nico Frommholz (Hamburg Commercial Bank), ont attiré l’attention. M. Merkel a souligné le status quo et osé regarder plus loin que le bout de son nez en mettant en lumière les attentes, les chances et les risques à ne pas perdre de vue dans le domaine des « crypto-monnaies / euro numérique ». M. Frommholz, directeur des opérations de paiement, a abordé le sujet principal des Payments-as-a-Service avec son discours « SEPA est live » – un sujet que PPI AG met de plus en plus au centre de ses intérêts et qui, en plus d’EBICS, l’anime et le fait avancer avec force enthousiasme.

Avec le lancement de HCOB, PPI AG a réussi à combler une lacune importante sur le marché Payments-as-a-Service. Mais il y a bien mieux : pour son expansion dans l’espace européen, la banque directe en ligne britannique Revolut mise sur la solution d’échange de données TRAVIC-Interbank et également sur le modèle Payments-as-a-Service – basé sur le cloud et proposé par PPI AG. La néobanque Revolut, fondée à Londres en 2015, compte actuellement environ 18 millions de clients privés utilisant l’application financière de l’entreprise. En janvier 2022, Revolut a lancé son offre de services bancaires en Allemagne et dans neuf autres pays européens. Pour développer sa stratégie offensive sur le marché de l’UE, Revolut a besoin, en tant que banque non européenne, d'une connexion à la European Banking Authority (EBA) ainsi que d’une connexion technique à l’EBA Clearing – notamment au système de paiement en temps réel RT1 pour les paiements instantanés SEPA et à la plateforme STEP2 pour les paiements SEPA réguliers. Cette connexion est réalisée par la solution d’échange de données TRAVIC-Interbank ainsi que par le modèle Payments-as-a-Service.

La société de conseil et de logiciels hambourgeoise PPI AG devient ainsi un prestataire de services complet dans le domaine des paiements européens. La solution Payments-as-a-Service enrichit les secteurs du conseil et des produits logiciels d’une offre globale et complète ainsi le portefeuille de prestations de l’entreprise hambourgeoise. Avec ses équipes de conseillers spécialisés et sa gamme de produits TRAVIC, PPI se classe ainsi parmi les leaders européens du marché des paiements. « Nous sommes désormais en mesure d’offrir Payments-as-a-Service aux institutions financières pour le traitement entier des paiements. Les institutions peuvent ainsi décharger leurs services informatiques, utiliser leurs ressources de manière efficace et améliorer ainsi leur compétitivité », a constaté Dr. Thorsten Völkel, directeur général de PPI AG. Un exemple concret qui montre que la gamme de produits TRAVIC n’est pas seulement la solution logicielle centrale pour cela, mais qu’elle constitue surtout l’avenir pour une plateforme de paiements standardisée, multi-banques, moderne et hébergée pour le marché bancaire européen ! Avec ces prestations, PPI AG permet aux institutions financières et aux compagnies d’assurance d’exploiter des chaînes entières de création de valeur en tant que Software-as-a-Service. Le portefeuille modulaire s’étend depuis la mise à disposition et de l’exploitation de l’infrastructure informatique jusqu’à de multiples services et il enthousiasme non seulement en raison de son caractère international, de sa complexité technique, mais aussi et surtout au niveau de la conformité et de la légalité.

Ces succès illustrent bien ce qui nous unit : la passion pour l’excellence en matière de logiciels et de conseils de paiement. Nous sommes très heureux d’avoir concrétisé cette aspiration avec le groupe d’utilisateurs 2022. Comme nous l’avons tous appris, l’échange d’expériences et de solutions aux problèmes lors de réunions et d’appels numériques a été une évidence. Mais c’est justement l’inspiration mutuelle et collective dont bénéficie depuis toujours le développement des produits TRAVIC, marquée par des échanges vivants, animés et en face à face, qui nous a manqué. Nous étions donc d’autant plus heureux de pouvoir renouer solennellement avec ces étroites collaborations et d’honorer pendant deux jours la clientèle estimée de PPI avec un programme bien rempli et varié : depuis la présentation des nouvelles versions des produits TRAVIC aux discussions approfondies avec les clients dans le cadre des ateliers spécifiques aux produits, en passant par les cas d’utilisation et les derniers témoignages d’expérience.

Auteur : Andreas Löwe

 

En savoir plus