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

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

 

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


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

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.

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 !

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)

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

 

Vérification des certificats EBICS en France sans prestataires tiers de confiance

Certificat électronique et applications
Le certificat électronique est un élément essentiel dans la construction des espaces de confiance ; il permet à son porteur de s’authentifier (certificat d’authentification), de signer (certificat de signature), d’établir une liaison sécurisée … Une application va s’appuyer sur un certificat comme moyen d’identification de son porteur et de contrôle de l’intégrité des informations, dans des fonctions de contrôle d’accès ou de signature. Il existe aujourd'hui de nombreux émetteurs de certificats (secteur bancaire, administration, entreprises…).

Les applications de dématérialisation des flux sont multiples et concernent l’ensemble des secteurs de l’économie. Elles supposent la mise en œuvre d’espaces de confiance dans lesquels il faut pouvoir identifier et authentifier techniquement les différents acteurs et valider la qualité des transactions et de leurs émetteurs.
 
Une application doit pouvoir accepter, en général, des certificats de différentes autorités de certification ; dans un monde ouvert, il serait, en effet, à la fois trop coûteux et trop restrictif de demander à un même porteur d’obtenir un certificat par application.

EBICS et les certificats signés
Pour communiquer avec les institutions financières, les participants EBICS disposant du profile T ou TS doivent utiliser des certificats X.509. Si le participant utilise des certificats signés par une autorité de certification (AC), ceux-ci doivent être validés lors du téléchargement des clés et, si nécessaire, pour les ordres de type FUL, par exemple. Les types d’ordre pour la soumission et la modification des certificats (INI, HIA, H3K, PUB, HCA et HCS) prennent en charge les certificats uniques et les chaînes de certificats.

Validation du certificat basé sur l'AC
La validation du certificat basé sur l'AC peut être effectuée de manière externe ou interne (pour EBICS TS). Il est dorénavant possible de vérifier les certificats soumis en interne dans TRAVIC-Corporate. Pour cela, les notes de la liste de révocation sont vérifiées à l'aide des listes de révocation de certificats (CRL). Les listes de révocation de certificats doivent être téléchargées depuis Internet. Pour télécharger les listes de révocation de certificats de SWIFT, un certificat client est généralement requis pour la communication TLS.

Interface de vérification des certificats internes de TRAVIC-Corporate pour EBICS TS
L'interface provider de TRAVIC-Corporate offre, entre autres paramètres, la vérification des certificats, une stratégie de mise en cache, le stockage des fichiers de non-répudiation et la vérification préliminaire des autorisations ES (EBICS TS), conformément aux spécifications du CFONB. Le provider peut être spécifié à partir du nom de sa classe et activé.

Les certificats sont validés par rapport à un truststore stocké dans TRAVIC-Corporate. La chaîne de certificats complète est validée respectivement jusqu'au certificat racine valide. Aucun service externe n'est utilisé pour valider les certificats.

Un serveur job et un analyseur syntaxique, composants de TRAVIC-Corporate, orchestrent ce traitement. L’ordre de paiement est alors validé si le profil de signature du participant EBICS correspond au profil de signature configuré au niveau du type d’ordre du client.

L’établissement financier peut alors se reposer exclusivement sur sa solution TRAVIC-Corporate sans recours à un tiers simplifiant ainsi son architecture et réduisant ses coûts.

Zaher Mahfouz

Sources : PPI TRAVIC-Corporate, CFONB, standards X.509

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