Conseils pour une transition aisée vers EBICS 3.0

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

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

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

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

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

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

Auteur : Michael Lembcke


API ouvre les portes aux applications bancaires

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

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

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

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

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

Auteur : Christian Wenz

L’euro numérique et l’alternative aux espèces

Ce n’est pas seulement depuis la pandémie du coronavirus que la Banque centrale européenne (BCE) observe que les consommateurs de la zone euro utilisent moins souvent les espèces. L’utilisation des méthodes de paiement a déjà été transformée par une augmentation du commerce électronique, des méthodes de paiement numériques et des services bancaires à domicile.

La relation pourtant intime de nombreux Européens avec les espèces est motivée par le règlement de petits montants : qu’il s’agisse de payer au restaurant, les achats hebdomadaires au marché ou la pièce d’un euro pour l’utilisation du chariot au supermarché, les espèces ne peuvent pas être complètement abandonnées.

En outre, les espèces apportent d’autres avantages aux citoyens :
 

  • Les paiements restent anonymes et il n’y a guère de préoccupations en matière de protection des données. 
  • La monnaie est protégée – par exemple contre l’insolvabilité d’une institution financière. 
  • Elle ne subit pas d’impôts de la part de l’État et n’est pas frappée par des intérêts négatifs. 
  • L’argent liquide est largement accepté et peut être transporté facilement.


Outre la monnaie, les consommateurs ont la possibilité de payer par voie numérique – par exemple avec leur smartphone au point de vente, leur carte de crédit ou de débit ou des méthodes de paiement en ligne dans le commerce électronique. Toutefois, ces paiements sont principalement effectués avec de la monnaie de banque commerciale, c’est-à-dire de la monnaie émise par les institutions financières. Il n’existe actuellement pas d’alternative numérique aux espèces émises par la BCE.

Les aspects clés des espèces et la différenciation par rapport aux méthodes de paiement numériques seront étudiés par la BCE dans le cadre de l’introduction d’une monnaie numérique européenne. La phase d’analyse de deux ans qui vient de commencer concrétise pour la première fois le travail sur un euro numérique. Le résultat de l’analyse doit notamment permettre de décider si et sous quelle forme les aspects mentionnés vont être pris en compte.

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 représenter un maximum d’anonymat et de sécurité. Les consommateurs demandent que l’alternative numérique de l’euro soit conçue de façon que le paiement anonyme – tout au moins de petits montants au point de vente – reste possible.

Outre la protection des données et la sécurité, la mise à disposition, la disponibilité et l’interopérabilité revêtent une grande importance. Selon les informations actuellement disponibles, la BCE souhaite impliquer les banques commerciales et les prestataires de services de paiement (PSP). Ils doivent jouer le rôle d’intermédiaires entre les banques centrales et les consommateurs. Des tâches telles que l’identification, l’intégration et la mise à disposition du portefeuille doivent être gérées. Mais si on y regarde de plus près, de nombreuses questions restent sans réponse pour l’instant :
 

  • Combien de portefeuilles de paiement les consommateurs peuvent-ils posséder ? 
  • Quelles seront les méthodes de provision à disposition (portefeuille mobile, carte physique, bracelets de paiement, etc.) ? 
  • Comment garantir les paiements hors ligne ? 
  • L’euro numérique peut-il également être utilisé pour payer dans le commerce électronique ? 
  • Quels seront les montants maximaux pour les paiements individuels et pour l’ensemble des paiements ?


Les réponses de la BCE à ces questions ainsi que la manière dont l’euro numérique se distinguera finalement des paiements en espèces ou des paiements numériques existants ne seront probablement pas disponibles avant deux ans. Après une période de développement de trois ans, l’euro numérique pourrait être lancé en 2026.

Chez PPI, nous suivons ce sujet avec beaucoup d’enthousiasme et considérons la délimitation claire de l’utilisation pour les particuliers entre les espèces numériques et les méthodes de paiement numériques comme un élément essentiel de la période d’analyse. Afin de vous tenir au courant des derniers développements, nous vous informerons au cours de l’année prochaine régulièrement des nouveautés sur l’euro numérique au moyen de ce blog.

Auteur : Philipp Schröder


Un an avant la migration vers TARGET2 – Êtes-vous prêt ?

Nous sommes à moins de douze mois de l’échéance. Le 21 novembre 2022 marquera la migration de TARGET2 MT à MX, soit un an plus tard que prévu initialement. Selon la Bundesbank, la migration concerne environ 1 220 participants, dont 955 font partie de la cogestion (https://www.die-bank.de/news/fachtagung-zahlungsverkehr-der-zukunft-update-19327/). Dans le même temps, la phase de transition de la migration ISO de SWIFT commence. Après la Suisse et le Japon, le système TARGET2 (EUR) est l’un des prochains systèmes à migrer vers ISO 20022. Le Royaume-Uni et les États-Unis suivront en 2023 et surveilleront certainement de près la mise en œuvre.  

Le calendrier serré de la consolidation sera un défi pour de nombreuses institutions financière qui migrent leur système informatique vers MX, en plus des opérations quotidiennes et d’autres projets tels que la migration ISO de SWIFT. Le temps est passé très vite et l’année supplémentaire a été caractérisée par d’autres préparatifs. Les concepts métiers sont écrits, la mise en œuvre et les tests internes battent leur plein. 

Un petit regard en arrière

Les tests de connectivité ont commencé dès le début du mois de septembre. L’e-ordering pour l’enregistrement technique pour les services TARGET a été effectué via le Network Service Provider (NSP) concerné : SWIFT ou SIA. Certaines institutions financières ont ainsi pu établir en partie une connexion U2A ou A2A avec ESMIG dès le début du mois d’octobre. Tous les participants sont tenus de communiquer eux-mêmes les résultats de ses tests à la Bundesbank. Cette obligation s’applique également si la connexion est effectuée par un tiers, par exemple par un bureau de service SWIFT. Tous les documents justificatifs étaient à fournir avant le 30 novembre. Les tests de connexion à ESMIG étaient à effectuer avant le 1er décembre.

Un regard en avant

La mise en œuvre des étapes restantes au cours des prochains mois permettra aux participants de se préparer de manière optimale à la migration. Mais cela signifie également que dès à présent des employés devraient être affectés aux tests respectifs afin de garantir avec la plus haute priorité le respect de ces dernières étapes.

Les tests de connectivité et de communauté prévus ont fait l’objet d’une analyse plus profonde lors des formations organisées par la Bundesbank en octobre et novembre. En soumettant le formulaire pour la création des données de base, la Bundesbank effectue automatiquement les configurations nécessaires dans le système de test et crée les données d’utilisateur.

Le participant doit alors saisir toutes les données de base une fois pour le système de test et ensuite une fois pour le système de production. Aucune donnée de base n’est transférée depuis les systèmes existants. Les entrées correspondantes peuvent donc être internalisées dans le système de test et les participants peuvent se familiariser avec les applications.

À partir du début du mois de décembre, après la création des premières données de base à partir du formulaire issu par la Bundesbank, les autres données de base doivent être obligatoirement créées par le participant. Celles-ci constituent la base des autres « Mandatory Test Cases » qui pourront être réalisés à partir du 1er janvier 2022. En novembre, un Information Guide for TARGET Participants a été mis à disposition pour le « Operational Related Testing ». Des tests définis par l’utilisateur même peuvent être effectués au cours de 7 mois afin de vérifier les fonctionnalités de tous les services TARGET et leur interaction.

Un aperçu des dates les plus importantes

  • La prochaine étape « Community Testing » démarrera au début du mois de décembre et couvrira les « Business Day Testing » (y compris T2S et TIPS) et le « Operational Related Testing » (entre autres ECONSII). 
  • L’année du Big Bang 2022, la « Migration Week Rehearsal » (MWR) aura lieu pendant la semaine du 28 mars au 1er avril. Ces tests auront lieu pendant la semaine et permettront de s’assurer que les données de base ont été correctement configurées. L’initialisation des soldes sur T2 est vérifiée. 
  • Les « Migration Weekend Dress Rehearsals » (MWDR) auront lieu le 8 juillet, le 23 septembre et, en option, le 15 octobre. D’autres fonctionnalités seront vérifiées pendant le week-end. Les dates pour MWR et MWDR publiées par la Bundesbank sont obligatoires pour tous les participants. 

 La Bundesbank met également à disposition des tutoriels, c’est-à-dire des vidéos pour la réalisation des tests. Lors des formations, les différentes saisies de DN U2A et A2A ont par exemple été indiquées. Pendant cette étape, le tutoriel apporte son soutien et guide le participant pas à pas à travers les saisies. Pour toute question concernant le sujet des tests, la Bundesbank a également mise à disposition l’adresse électronique targetservices-test@bundesbank.de.

Dans la mesure du possible, les documents justificatifs des tests pour différents « Mandatory Tests » doivent être envoyés ensemble. Il est toutefois possible de les fournir ultérieurement. Si des cas de test ne peuvent pas être réalisés parce qu’ils ne sont pas pertinents pour l’institution financière, par exemple si celle-ci ne possède pas de RTGS DCA, il ne sera pas nécessaire de conduire ces tests, sous accord de la Bundesbank. Une déclaration écrite sur le cas individuel doit être fournie à la Bundesbank.

Les formations ont montré en partie la complexité qu’il faut maintenant mettre en œuvre. Dans ce contexte, il ne suffit plus de donner une estimation approximative sur l’état de la mise en œuvre de la consolidation TARGET2. Il faut maintenant présenter des documents justificatifs et résultats des tests et il faudra d’abord voir qui a réussi la mise en œuvre technique.

Environ un quart à un tiers des banques centrales, des « Closely Monitored Participants » et des « Regularly Monitored Participants » ont jusqu’à présent signalé un statut jaune, ce qui signifie qu’ils prévoient donc des risques qui pourraient rendre leur migration vers TARGET2 plus difficile (https://www.ecb.europa.eu/paym/intro/events/shared/pdf/fs12/2021-09-30-focussession-t2t2sconsolidation-marketreadiness.pdf, https://www.ecb.europa.eu/paym/intro/events/shared/pdf/fs11/T2-T2S_Consolidation_Market_Readiness.pdf). Bien que les tests internes des participants devraient être terminés fin août, de nombreux participants sont toujours en pleine phase de test. Il semble donc difficile de définir les avancées individuelles. Tous les participants à TARGET2 doivent maintenant veiller à ce que l’objectif de l’étape soit atteint à la fin de celle-ci. 


Auteures : Viktoria Liehmann, Sabine Aigner



Démarrage de SEPA 2.0

SEPA 2.0, c’est-à-dire la migration des formats SEPA vers la version ISO 2019 du standard ISO 20022, démarre en novembre 2021. Les trois transitions redoutées, à savoir la consolidation de TARGET2, le passage de SWIFT MT vers MX et également vers SEPA 2.0, ont été évitées par une migration progressive à SEPA 2.0. Le temps restant doit maintenant être utilisé pour travailler activement aux préparatifs.

Remarque : la distinction entre DK et EPC s’applique à l’Allemagne

*https://www.europeanpaymentscouncil.eu/what-we-do/other-schemes/sepa-request-pay-scheme

 

 La migration vers la spécification de format de la Deutschen Kreditwirtschaft qui entre en vigueur à partir de novembre concerne d’abord le virement en temps réel (pain001.001.09), l’avis de crédit des SCT Inst entrants basé sur l’ISO 2019 (camt.054.001.08) ainsi que les formats pour les informations sur les comptes (camt.052, camt.053 et camt.054). La version 09 pour les virements en temps réel consiste en une extension des formats SCT Inst, car les spécifications précédentes (pain.001.001.03 sans horaire et pain.001.001.08 avec horaire) restent valables sans changement. La chronophage opération de changements des formats existants au niveau de l’interface client-institution financière avec l’intégration complète des clients finaux ne sera pas nécessaire actuellement et sera reportée à une date ultérieure.

En novembre 2022, la version ISO 2019 sera poursuivie avec l’inclusion de la spécification de formats pour Request to Pay (RTP ou demande de paiement) dans l’accord EDI. Du fait que cette norme est initialement intégrée dans l’accord EDI en tant qu’option, une activité parallèle quant à la consolidation TARGET2 n’est pas explicitement spécifiée, mais est réservée aux institutions financières qui souhaitent investir dans l’amélioration de l’expérience client.

Le plus grand effort en matière de soumissions par les clients finaux aura lieu en novembre 2023, car la migration des formats SEPA pour les virements et les prélèvements est prévue pour cette date. Le temps restant devrait être mis à profit pour préparer la nécessaire intégration des clients de manière à éviter un report des dates de migration, comme ça a été le cas lors de l’introduction obligatoire de SEPA en 2014. 

Une préparation intensive avec les clients concernés est également fortement conseillée pour la fin de la migration SEPA 2.0. En novembre 2025, les formats MT940 pour les informations sur les comptes de la veille et MT942 pour les informations sur les comptes du jour cesseront d’être la norme du DK. Les clients qui ont besoin de ces informations pour leur comptabilité doivent être en mesure de traiter les informations sur les comptes dans les formats camt de la version ISO 2019 à partir de cette date, ce qui nécessite un effort considérable du côté des clients finaux et donc une préparation longue et intensive.

Les modifications liées à la mise en œuvre de SEPA 2.0 influenceront l’interaction des formats dans la chaîne de traitement et donc également le fonctionnement des procédures de paiement. Tous les systèmes internes de l’institution financière qui produisent et/ou reçoivent des formats importants pour les changements, ainsi que les clients fournisseurs ou récepteurs, sont considérablement impactés. Le risque d’un traitement ultérieur incorrect ou le risque de rejet de paiement peut être limité en examinant le sujet à un stade précoce. En effet, l’adaptation et l’interconnexion des systèmes bancaires permettent de créer de la valeur ajoutée, d’optimiser les processus globalement et d’augmenter les fonctionnalités des systèmes.

Nous sommes actuellement dans les starting blocs pour la migration vers SEPA 2.0. L’effort global nécessaire pour ces changements ne pourra probablement pas être réduit par les étapes de migration décrites, mais il sera au moins plus facile à planifier. Nous accompagnerons de près la mise en œuvre et présenterons ici les développements actuels. 


Auteurs : Rebecca Stannull, Eric Waller



D’une seule source !

Un projet d’externalisation informatique réunit en règle générale tout un ensemble d’experts provenant de différentes parties impliquées : l’entreprise qui externalise, le prestataire d’externalisation en tant que futur opérateur, souvent les développeurs de logiciels utilisés, des experts en migration et de manière assez fréquente une société de conseil pour la gestion globale du projet. Cet effort n’est pas surprenant en soi, car il s’agit des procédures très complexes, nécessitant la gestion de nombreuses interdépendances et – surtout dans le domaine des transactions financières – ne souffrant pratiquement aucune marge d’erreur. Il est tout à fait permis de se demander s’il ne serait pas parfois plus agréable qu’un seul partenaire soit responsable de plusieurs aspects d’un projet. Après tout, ne dit-on pas que plus les parties impliquées à coordonner sont nombreuses, plus grands sont les risques de friction.

C’est dans ce contexte que notre société, PPI AG, a décidé de proposer dès maintenant non seulement des services de conseil et des logiciels pour le traitement des paiements, mais aussi d’exploiter les plateformes correspondantes. Avec ce modèle de Payments as a Service (modèle PaaS), nous franchissons une nouvelle étape pour devenir un prestataire de services polyvalent dans le domaine des paiements en Europe.

Que cela signifie-t-il concrètement ? Nos clients peuvent désormais faire exploiter leur logiciel PPI directement dans le cloud. Ils obtiennent ainsi tous les services à partir d’une seule source – le logiciel, mais aussi tout ce qui concerne le conseil et l’exploitation des systèmes de paiement. Notre offre couvre donc toute la chaîne du traitement des paiements. Cela soulage les services informatiques de nos clients et permet aux institutions financières d’utiliser leurs ressources plus efficacement et de devenir plus compétitives.

Pourquoi nous lançons-nous dans l’exploitation des solutions logicielles ? La réponse est simple : parce que cela aide nos clients à être compétitifs dans un environnement de marché globalement étroit. Et parce que nous en avons les compétences : depuis plus de 30 ans, nous travaillons avec succès dans le domaine du conseil et des logiciels et nous avons correctement anticipé la tendance vers une utilisation accrue des technologies de cloud. Il y a plus d’un an déjà, nous avons ainsi engagé une coopération avec Broadridge Financial Solutions, un spécialiste de la communication avec les investisseurs et des solutions technologiques pour les institutions financières. Grâce à cette coopération, nous pouvons également proposer notre technologie de pointe en tant que PaaS.

Tout n’est que pure théorie ? Non, notre offre complète est déjà expérimentée et éprouvée : la Hamburg Commercial Bank (HCOB) utilise la solution PaaS. Le point de départ du projet était classique. Dans le cadre d’une externalisation de deuxième génération, l’institution souhaitait migrer tous les clients vers une plateforme centrale de paiement et dans le même temps simplifier ses propres processus commerciaux. Le cœur de la nouvelle architecture de la HCOB est notre gamme de produits TRAVIC, une plateforme de paiement standardisée, multi-entités, moderne et hébergée. Notre environnement d’exploitation a été configuré en fonction des souhaits du client afin que nous puissions contrôler et surveiller de bout en bout les paiements de l’institution financière. Les avantages d’un tel projet d’externalisation d’une source unique se sont révélés très clairement, car les systèmes pour les paiements à l’étranger ont déjà été transférés vers le nouveau modèle d’exploitation après douze mois, bien plus rapidement que le délai prévu d’un an et demi. Et – il ne faut pas le négliger – en période de pandémie de coronavirus.

La symbiose unique que PPI offre, se composant d’une expertise métier approfondie et d’un savoir-faire complet en termes de développement, permet de réaliser de tels résultats. Dans le contexte des tendances à l’externalisation, il était logique de proposer également des modèles d’exploitation à l’avenir. Et pour éviter les frictions liées à la multiplicité des intervenants, nous accompagnons nos projets depuis la planification initiale jusqu'à l’exploitation permanente à partir d’une seule source, un ensemble complet de services de paiement.


Vous trouverez plus d’informations sur nos services Payments as a Service ici!

Votre
Hubertus von Poser



L’euro numérique – plus de questions que de réponses?

La Banque centrale européenne examinera attentivement les monnaies numériques dans les années à venir. Les possibilités de conception sont multiples et soulèvent des questions.

Ce mois-ci (oct. 2021) les choses se mettent en route. La Banque centrale européenne (BCE) lance un projet d’analyse de deux ans pour évaluer la façon de réaliser l’euro numérique. Le résultat de la phase d’analyse déterminera sous quelle condition et quelle forme la BCE mettra en œuvre l’euro numérique.

Cependant, les discussions et les publications précédentes montrent clairement que l’euro numérique aura peu de parallèles avec les fonctions des cryptomonnaies privées actuelles. Les infrastructures blockchain et leurs avantages ne sont guère pris en compte dans le contexte de l’euro numérique. La Banque centrale européenne mettra l’accent sur les approches alternatives de l’argent liquide et les répercussions sur le système monétaire.

Les variantes (de mise en œuvre) sont néanmoins diverses, ce qui favorise les discussions passionnantes. Les formes et effets potentiels doivent être compris et évalués en profondeur.
Les questions suivantes peuvent servir de première base :

  • Quelles sont les valeurs ajoutées et les cas d’utilisation pour les différentes parties impliquées ?
    • Institutions financières, prestataires de service de paiement, particuliers, commerce, industrie, Banque centrale européenne 
  • Quelle est la conception technique de l’euro numérique ?
    • La monnaie numérique se fondera-t-elle sur une infrastructure de comptes ou de jetons ?
    • Comment les valeurs seront-elles transférées entre les parties participantes ?
    • Les utilisateurs recevront-ils exclusivement un produit numérique ?
    •  …
  • Comment l’utilisation est-elle conçue pour les particuliers ?
    • Comment l’anonymat est-il assuré ?
    • Des limites existeront-elles pour les sommes utilisées et déposées  ?
  • Comment et par qui la mise en place et la mise à disposition se feront-elles ?
    • Quelles seront les exigences réglementaires ?
    • Comment les institutions financières et les prestataires de service de paiement s’impliqueront-ils ?
    •     …


Même si le projet d’analyse ne fait que commencer, de nombreuses tendances peuvent déjà être identifiées. PPI suit ce sujet avec beaucoup d’enthousiasme et a déjà élaboré quelques thèses sur ces questions. Dans les semaines à venir, nous les partagerons et en discuterons avec vous.

Auteur : Philipp Schröder