Big Bang de T2/T2S : les institutions financières risquent d'être exclues des transactions financières

Pour le grand public, les transactions financières fonctionnent de manière invisible et fiable. Mais cela ne doit pas rester ainsi. Inconnu du public, le sujet d’actualité le plus important est la consolidation TARGET2/TARGET2-Securities, et avec elle la migration ISO 20022 ainsi que le nouveau modèle de comptes. Les institutions financières qui ne relèvent pas ces défis à temps risquent d’être exclues des transactions de paiements – et les clients en ressentiront les conséquences.

La migration concerne tous les participants au système TARGET2 actuel et elle a lieu dans l'infrastructure des institutions financières, des banques centrales et de la Banque centrale européenne (BCE). Du fait que la transition s’effectuera en mode Big Bang, c'est à dire simultanément pour toutes les institutions financières en Europe le 21 novembre 2021, les retards de chaque institution peuvent avoir des conséquences négatives sur l'économie. Des complications dans les systèmes informatiques souvent obsolètes ou des retards dans la réalisation des projets peuvent, au pire, conduire à l'exclusion des paiements individuels, si la bascule ne peut pas se dérouler à la date limite.
Les conséquences pour les institutions financières en cas d'un échec de la consolidation T2/T2S :

  • Exclusion des paiements individuels en monnaie banque centrale
  • Exclusion du traitement des opérations monétaires, ce qui signifie en particulier :
  • Impossible d’utiliser les opérations d'open market.
  • Impossible d'utiliser les facilités permanentes.
  • Impossible de respecter les réserves obligatoires.

Si un système secondaire connecté à TARGET2 comme SEPA-Clearer est utilisé pour les paiements de masse, l'institution financière sera également exclue des canaux de compensation concernés et elle ne pourra plus traiter les paiements.

Les conséquences sont alors dramatiques et menacent la viabilité de la banque elle-même. La seule alternative possible est d’établir une connexion directe via une autre institution. Mais ce procédé devrait être décidé et planifié à un stade précoce et ne pourra pas être mis en place juste avant novembre 2021. Si ceci échoue également, l'avenir de la banque est en péril. Spéculer ou compter sur un éventuel report de la migration serait négligeant.

Toutefois, le défi majeur de la consolidation de TARGET2 est non seulement la refonte de la structure des comptes mais également l'harmonisation technique de l'accès des systèmes existants TIPS et T2S à TARGET2, ainsi que la migration imminente des formats de message.

Accès futur à TARGET2

La connexion à TARGET2 va changer. Jusqu'à présent le service FIN Copy de SWIFT (appelé mode Y Copy) est utilisé. À l'avenir, il y aura une propre architecture de communication dédiée et distincte, fournie par la BCE, qui fonctionnera avec l'Eurosystem Single Market Infrastructure Gateway (ESMIG) comme point d’accès central à tous les services TARGET2. Pour cet accès, un Network Service Provider (NSP) échangeant avec l’ESMIG sera requis en tant que nouveau participant.

Formats de message

L'avenir parle ISO 20022 et aussi TARGET2. Jusqu'à ce jour, TARGET2 utilise toujours les messages MT pour les échanges. Ces messages MT seront remplacés par des messages ISO 20022 en XML (MX), qui seront beaucoup plus complets et qui permettront de compiler beaucoup plus d'informations. Les messages MX ne sont pas introduits dans une approche similaire qui permettrait de transformer  facilement les messages MT en messages MX. Au lieu de cela, le potentiel des nouveaux formats sera exploité d’emblée.

De ce fait et en raison du réaménagement complet de l'infrastructure, une utilisation parallèle ou une solution transitoire avec les deux formats ne sera pas possible.

Trop ambitieux ?

De nouveaux formats de message, de nouveaux canaux de connexion, de nouveaux acteurs et de nouveaux processus – tout cela à une date butoir dans toute l'Europe. Cela peut-il bien se passer ?
En raison de l’actualité de ce sujet, un reporting détaillé avec un calendrier strict est établi via les banques centrales. Les jalons du projet sont définis de manière centralisée par la BCE et l'atteinte des objectifs est régulièrement surveillée. Chaque banque est elle-même responsable de sa propre mise en œuvre. En ce moment, sept marchés participants (y compris l'Allemagne) ont indiqué un statut  jaune, 18 un état vert. À première vue, tout semble encore aller pour le mieux – mais les institutions financières qui sous-estiment les conséquences et les efforts nécessaires pour se mettre en conformité à temps pourraient passer du jaune au rouge plus rapidement que souhaité.

Pour que les choses conservent leur intérêt, la bascule des formats MT vers les formats MX se déroulera en plus de la consolidation de TARGET2. Pour les formats, par contre, une période de transition de quatre ans est prévue pendant laquelle les institutions financières pourront encore utiliser les deux formats. En raison de la proximité de ce thème, il est sensé de le traiter en même temps que TARGET2.

La liste des tâches est plutôt longue et va mobiliser les capacités des institutions pendant les prochaines années. Cela doit également entrer dans les esprits des membres du conseil d'administration. Il ne s'agit pas seulement d'un « exercice obligatoire », mais de la viabilité de chaque institution.

Auteurs : Swaantje Anneke Völkel, Thomas Ambühler

EBICS pour la compensation et le règlement des transactions de paiements instantanés SEPA – le nouveau document Delta comme jalon

Depuis l'introduction de SEPA en Janvier 2018, le protocole de transfert EBICS est également utilisé dans les opérations interbancaires pour la compensation bilatérale et le règlement ainsi que pour l'échange des paiements SEPA avec la Deutsche Bundesbank. Au fil des années, le nombre d'institutions Européennes qui utilisent EBICS n'a cessé de croître. Il n'est alors pas surprenant qu’à partir de novembre 2013 EBA Clearing ait aussi offert EBICS comme accès alternatif à ce que l’on désigne par « garage clearing » (compensation bilatérale) et à STEP2.

Après la transition à SEPA, l'introduction des paiements instantanés SEPA fut l’étape suivante vers la standardisation dans le secteur européen des paiements. Toutefois, en raison de l’approche temps réel, ce nouveau type de paiement constitue un défi particulier pour l’utilisation d’EBICS. Alors que l'échange de données basé sur des fichiers était la base de l'utilisation conventionnelle d'EBICS, pour les paiements interbancaires les procédures de paiements instantanés SEPA demandent une approche basée sur des messages relatifs aux transactions. Ainsi en novembre 2017 EBA Clearing a mis en œuvre avec succès le RT1 basé sur des paiements instantanés SEPA.

Afin de promouvoir EBICS dans l'échange et la compensation des transactions de paiements instantanés SEPA, la société EBICS a officiellement publié en octobre 2019 un document Delta relatif à la spécification EBICS (cf. Use of EBICS for the Clearing & Settlement of Instant Payment Transactions, www.ebics.org, disponible en anglais). Ce document décrit les modifications à prendre en considération pour le traitement des paiements instantanés avec la version 3.0 d’EBICS. Pour répondre aux nouvelles exigences nées du fonctionnement en temps réel, le nouveau schéma ebics_inst_request_H005.xsd a été ajouté. Toutefois pour les opérations métiers administratives des paiements instantanés, le fonctionnement d’EBICS basé sur des fichiers et par conséquent le schéma standard demeurent nécessaires. Le nouveau schéma doit être ajouté au schéma global pour l'utilisation des paiements instantanés SEPA avec EBICS.

Rien ne change lorsque EBICS est utilisé dans le cadre des échanges entreprise-banque ou pour les transactions interbancaires qui ne portent pas sur les paiements instantanés.

Le document Delta Use of EBICS for the Clearing & Settlement of Instant Payment Transactions est bienvenu. Dans la pratique, EBICS est largement utilisé et de nombreux autres scénarios sont envisageables. Afin de garantir l'utilisation intégrale et harmonisée d'EBICS les standards ainsi que leur respect sont indispensables. Il faut, par contre, pouvoir réagir de manière flexible aux défis du marché. Ce document répond tout aussi bien à ces deux objectifs. Un autre jalon a été posé sur la voie vers une normalisation des transactions financières en Europe.

Auteur: Michael Lembcke

La demande de paiement modifie les transactions financières - les défis techniques

Notre dernier article du blog concernant la demande de paiement (R2P) nous a montré jusqu’à quel point la demande de paiement pouvait rendre les fêtes de fin d'année plus simple en permettant de réaliser les achats associés de manière parfaitement organisée. Les prochaines fêtes de fin d'années étant encore lointaines, il est encore temps de s’intéresser aux défis découlant de l'intégration des systèmes de paiement basés sur la demande de paiement.

Dans ce contexte il convient en premier lieu de parler de la composante technique. En décembre dernier, EBA CLEARING a publié des spécifications de formats, décrivant tant la demande de paiement (pain.013) que la réponse à la demande de paiement (pain.014). Ainsi, la partie compensation est précisée techniquement et le « seul » défi qui reste à relever est de préparer les interfaces d'entrée et de sortie des systèmes de paiements à ces cinématiques et formats. Cela peut sembler trivial de prime abord, mais c’est en fait un véritable challenge pour les systèmes de paiement : tant le chemin aller (demande de paiement) que le chemin retour (réponse à la demande) doivent être routés par le système de paiement en très peu de temps depuis un système client répondant vers les systèmes de compensation concernés et le système client récepteur et/ou répondant.

Reste bien sûr à déterminer comment les clients pourraient transférer la demande de paiement à leur institution financière. D’un point de vue technique, le Conseil européen des paiements et la Deutsche Kreditwirtschaft (DK) mènent un débat à ce sujet, qui se matérialisera par une spécification technique de l'interface entre le client et la banque.

C'est là que la composante métier entre en jeu. Elle devrait impliquer de repenser conceptuellement les systèmes existants quant au système qui reçoit les demandes de paiement et celui qui doit y répondre. Les questions de suivi qui en résultent traitent par exemple de la manière dont le client peut choisir de payer via SEPA ou SCTINST (à condition que la conception de la demande de paiement permette ce choix). La question de savoir comment le client peut autoriser la demande de paiement n'est pas moins importante. Les méthodes d'autorisation adaptées sont par exemple un dispositif mobile muni d’un système TAN ou une signature électronique disjointe EBICS.

Par ailleurs, les informations sur un avis de paiement suivant une demande de paiement réglée instantément peuvent désormais être restituées plutôt facilement, grâce à la « notification de crédit pour virements SEPA en temps réel ».

Moyennant une bonne combinaison des possibilités techniques, la R2P favorisera certainement le développement des paiements instantanés. Relever ces défis exigera un effort considérable, qui – selon les choix de conception – ne portera ses fruits qu’en cas de mise en œuvre efficace. Nous avons déjà discuté des cas d'application résultant des possibilités techniques dans le livre blanc « Demande de paiement – des possibilités d'application multiples ». N'hésitez pas non plus à nous contacter à tout moment pour des discussions sur le contenu et des discussions techniques.

Auteur : Eric Waller

Multi banques – tout en un seul portail

Les normes comme base de l’automatisation des processus en réseau

Les données sont le pétrole du 21ème siècle. Cela a été prêché lors de toutes les conférences numériques depuis des années. Plus un prestataire dispose de données d'un client, mieux ce dernier peut être regroupé et segmenté en groupes cibles. Ce savoir sur les besoins du client permet de lui composer des offres supplémentaires intéressantes.

Dès lors que dans le cadre de la normalisation les canaux d'accès s’appuient de plus en plus sur   l'Internet, le point de contact décisif entre les institutions financières et leur clientèle entreprise sera assuré par l’agence digitale en ligne telle que le portail web TRAVIC-Port. Si l'opérateur parvient à agréger tous les comptes bancaires du client, y compris ceux que celui-ci détient également auprès d'autres institutions financières, et à les regrouper dans son propre portail, il réunit alors les meilleures conditions pour proposer une vue d'ensemble des opérations de paiement à son client. Plus de comptes sont regroupés, meilleures seront les offres de services que l’opérateur peut proposer à ses clients.

Le mot clé « multi banques » fait référence aux fonctionnalités qui permettent de regrouper de manière optimale les transactions financières d'un client. Les deux parties - clients et institutions financières - tirent bénéfice de ce regroupement sous un même toit. Les clients disposent d’un aperçu global des transactions. L'agrégation concerne tant la remise de tous les types de paiement que le téléchargement des informations sur tous les comptes connectés. Le portail multi banque offre aux utilisateurs une interface utilisateur unifiée et facile à utiliser pour les différents prestataires de services de paiements via un accès sécurisé - et permet ainsi la mise en place de processus internes efficients. Mais le bénéfice de cette automatisation sans heurts de multiples transactions de paiement dépend de la rapidité du traitement et de l'implémentation correcte des serveurs bancaires de différents prestataires. Un niveau élevé de transactions interconnectées dans les deux sens requiert des interfaces uniformisées et la conformité aux spécifications en vigueur. Dans ce contexte la communication basée sur EBICS de TRAVIC-Port met à disposition le protocole technique basé sur Internet pour l’espace SEPA le plus sécurisé. Des adaptations trop larges et des écarts trop importants par rapport aux spécifications empêchent des processus limpides côté prestataire et font obstacle à une consolidation globale et sans faille des paiements. Dans ce cas, tant les clients de fournisseurs de portails que les éditeurs de logiciels devraient agir ensemble. En revanche, les API avec des interfaces propriétaires permettent des adaptations spécifiques aux environnements techniques de chaque institution financière. Cependant tout écart par rapport aux normes retarde l'intégration aisée d’un trafic de données complexe. Une interprétation imprécise des spécifications réduit le degré d'automatisation et le débit de chaque connexion. Plus il y a de lacunes dans un réseau complexe de connexions multi bancaires, moins le client en tire profit et de moindre qualité sont les analyses.

Auteur invité : Christian Veith

ISO 20022 dans les paiements internationaux : c'est l'heure du changement !

Presque tous les grands systèmes de paiement sont en train d'introduire des formats de données standardisés basés sur XML. Ils rendent les paiements internationaux et propriétaires plus rapides et produisent moins d'erreurs. Par contre, la transition ne va pas de soi et il ne reste pas beaucoup de temps. Que faut-il prendre en considération ?

Les paiements par carte pendant les vacances et les virements internationaux sont désormais considérés comme acquis dans la vie quotidienne. Toutes les transactions électroniques nécessitent cependant des processus très complexes, car pour assurer des transactions financières rapides et fluides, tous les systèmes informatiques concernés doivent être en mesure de traiter les données générées de la même manière. Un standard tel que l'ISO 20022 est requis à cet effet, étant donné qu’il sera la référence pour les paiements internationaux et individuels dans les années à venir.

Un standard éprouvé pour l'avenir

Toujours plus d'espaces de paiement migrent leurs systèmes vers le standard ISO car ses avantages sont considérables : il est évolutif, il permet un traitement des données de paiement beaucoup plus rapide et il permet une efficacité considérablement accrue. Les conversions d'un format de données vers un autre ne seront plus nécessaires. De plus en plus de données pourront être directement traitées sans interactions ou ruptures de supports  (STP).

Ne sous-estimez pas l'effort

Mais ce n'est pas sans coûts. Le passage à l'ISO 20022 exige des ressources humaines et financières. En ce moment de nombreuses institutions financières sous-estiment l’effort nécessaire. Elles doivent non seulement automatiser des processus manuels éventuellement existants, mais aussi adapter leur propre logiciel à l'ISO. S'il s'agit comme souvent des systèmes Legacy établis, la préparation des processus pour le traitement des paquets de données XML est exigeante. Et le temps presse : la mise en service de la conversion de TARGET2 au standard XML est prévue pour le 21 novembre 2021. À cette date débutera une période de coexistence avec SWIFT.

Un sentiment de préparation trompeur

Les institutions financières européennes appliquent déjà les standards basés sur ISO, car ils servent de base au SEPA. Mais cela ne signifie pas qu’elles peuvent rester les bras croisés. En fonction du type de mise en œuvre, des adaptations s’imposeront dans tous les secteurs importants de l'informatique des transactions financières : des données de base aux systèmes back end en passant par l'e-banking. Sans parler de l’impact sur l'architecture future du Core banking.

Diverses implémentations du standard ISO

Nous ne devons pas oublier qu'il s'agit d'un standard générique, qui définit uniquement les principes de base pour les messages de paiements. Lors de chaque implémentation spécifique le standard est adapté de manière appropriée, ce qui signifie qu'elle peut être différente pour TARGET2, SWIFT et SEPA. De la limitation des codes ISO et types de données autorisés à l'élimination des éléments facultatifs du message de base non utilisés, différentes variantes sont imaginables. Voilà pourquoi une seule solution pour tous les scénarios est irréaliste pour la migration.

De nombreux projets spécifiques

Il n'est donc pas correct de parler d'une seule transition ISO 20022 alors qu’en réalité existent bon nombre de projets distincts. Il est donc d'autant plus important d’impliquer très tôt le service IT afin d’aider les équipes métier à identifier à temps les pièges et les problèmes et, non des moindres, à estimer les coûts. Car la conversion des paiements internationaux et individuels de TARGET2 au standard XML est susceptible de générer un coût global de l’ordre de sept à huit chiffres. Ce montant inclue l'étude préliminaire, l’implémentation et les adaptations IT. Il faut en plus budgéter les formations des employés impliqués et le développement en temps voulu du savoir-faire nécessaire, ou alternativement l'intégration d'un partenaire externe.

Quelle est la suite ?

Si elle n'existe pas encore, les institutions financières ont besoin d'une feuille de route dans les meilleurs délais – contenant tous les tâches et jalons nécessaires pour la conversion au standard ISO. Un inventaire objectif de la situation actuelle sert de base, il n’est contournable par personne. À cette occasion il peut aussi être opportun de se demander si la fourniture de paiements transfrontaliers par sa propre institution sera toujours économiquement viable ou si une coopération renforcée avec des prestataires de services externes représente une meilleure solution.

Faire du changement une opportunité

La transition à l'ISO 20022 met sans aucun doute les prestataires de services financiers sous pression, surtout si nous considérons la consolidation quasi simultanée de TARGET2 et de TARGET2 securities. Par contre, les changements réglementaires sont également une possibilité pour vérifier critiquement ses propres systèmes et pour déterminer leurs capacités à être modélisés de manière agile et flexible. En fin de compte, cela aide à faire progresser la transformation numérique dans son ensemble – car l’immobilisme n'est pas une option dans le monde numérique d'aujourd’hui.

Auteurs invités : Sabine Aigner, Raija Wehrli

EBICS 3.0 – un ensemble de paramètres au lieu du type d'ordre Que faut-il prendre en compte lors de l'identification des opérations métier ?

Avec EBICS 3.0 les différentes opérations métier ne sont plus effectuées via les types d’ordres, mais via les nouveaux paramètres BTF.

Afin de permettre l'utilisation de contrats client avec des clients EBICS de différentes versions d'EBICS combinées avec EBICS 3.0, des règles de mapping ont été spécifiquement développées par les organismes nationaux de spécification. Ces règles suivent généralement les cinq paramètres BTF Service Name, Service Scope, Service Option, Service Message Name et Service Container. Il est important que la combinaison de ces paramètres BTF dans le serveur bancaire EBICS soit unique. Cela permet de s'assurer qu'un type d'ordre peut être attribué à l'opération métier via BTF et vice versa.

Dans la pratique, des ordres identiques d'un format donné peuvent être créés dans différentes versions de format et soumis au serveur bancaire. Bien que des ajustements de format soient effectués régulièrement par les organismes de spécification, la version de format utilisée par le système client dépend également de la version du logiciel client. Comme la version de format doit être transparente dans les logiciels clients, leurs utilisateurs n'ont aucune influence sur les envois dans une version de format spécifique lors de la compilation de leurs remises. En outre, les institutions financières acceptent en règle générale différentes versions de format d'une opération métier. En fin de compte, pour le traitement côté banque, la version de format correspondante peut également être lue à partir du namespace du fichier XML, au moins pour les formats XML. Jusqu’à présent, les serveurs bancaires sont conçus de manière flexible pour différentes versions de format.

Les autres paramètres BTF applicables pour EBICS 3.0 sont Service Message Name Format, Service Message Name Variant et Service Message Name Version. Si une institution financière inclut également ces autres paramètres dans les mappings des types d’ordre et les détails des contrats client, il convient de prendre en considération certains aspects. S’ils n’ont pas déjà été utilisés plus intensivement via le paramètre FileFormat ou s’ils ne sont pas nécessaires pour des raisons inhérentes au traitement, ces paramètres supplémentaires devraient être pris en compte de manière plus mesurée du côté des banques pour les tests EBICS.

Finalement, ces informations supplémentaires sur les paramètres font déjà partie du fichier d’ordre lui-même et, de toute façon, elles peuvent être lues à partir de ce dernier. Que faut-il faire en cas d’indications contradictoires ? Un surplus de gestion dans le serveur bancaire implique plus de temps et davantage d'efforts pour la gestion des référentiels. Il devrait y avoir un accord client propre à chaque version de format d'une opération métier. En plus, ces détails de format sont visibles par le client dans le logiciel client et certains d’entre eux ne peuvent pas être contrôlés.

Que se passerait-il si, par exemple, le serveur bancaire prenait en charge les versions 03 et 04 d'un format XML lors de la remise, mais que le client remettait la version 04 dans le BTF au lieu d’utiliser la version 03 du format ? L’ordre serait rejeté lors de la prise en compte de la version, bien que le système bancaire puisse traiter la version de format. La version réelle est reconnaissable au moyen du namespace.

La mise à disposition de fichiers pour download est encore plus compliquée. Celle-ci devrait être générée de manière synchrone dans la version demandée à la date/heure de téléchargement et être publiée en tant que fichier. Il en va de même pour les téléchargements historiques.

Conclusion : les institutions financières ne devraient pas être trop restrictives dans leurs définitions des accords BTF avec leurs clients. Cela leur permettrait ainsi d’être plus flexibles et d’économiser du temps et des efforts supplémentaires dans la gestion des contrats et des référentiels.


Auteur: Michael Lembcke

Paiements avant Noël – achats de Noël avec la demande de paiement ?

Les fêtes de Noël approchent. Pas aussi manichéennes, pas aussi simples et paisibles que les histoires le racontent – mais à leur manière tout à fait charmantes. Cependant, cette période de fin d’année peut être un peu déroutante, en particulier quand je regarde les relevés de compte de mes expériences d’achats effectués avant Noël.

La plupart des gens le savent : les bonnes intentions du type « ...mais cette année nous n’offrirons rien ! » sont encore moins valables que les résolutions du Nouvel An qui ne manqueront pas de suivre. Et même si on a l’impression que Noël commence en automne avec le premier pain d’épices sur les étagères, le temps des achats de cadeaux est toujours reporté à la dernière minute. Cette année encore je me retrouve encore une fois prise dans la folie du shopping. Parents, sœurs, grands-parents, famille du conjoint avec cinq frères et sœurs – et la génération suivante est déjà à la porte. Concilier les différentes listes de souhaits, listes d’achats et attentes avec mes relevés bancaires semble être un travail de Sisyphe.

Mes boutiques en ligne préférées possèdent mon mandat de prélèvement automatique alors que dans d’autres magasins digitaux, seuls les paiements par carte de crédit sont possibles. Je paie les billets de concert avec PayPal et les commerçants via Girocard pour les produits achetés dans les réseaux physiques ou « hors ligne ».

Retrouver toutes ces positions sur mon relevé de compte qui est beaucoup trop long me rappelle que je dois encore commander un puzzle trois mille pièces pour ma tante. Le service à thé pour ma grand-mère a-t-il déjà été payé ou sera-t-il débité plus tard ? Quand ma facture de téléphone sera-t-elle encaissée ce mois-ci ? C’est d’habitude cette semaine, n’est-ce pas ? Et qu’est-ce que ce « shop XY », et pour quoi a-t-il reçu 90 € de ma part ?

Comme chaque année, j’ai l’impression que la folie du shopping me submerge et je perds la vue d’ensemble. Le décalage entre la commande et le paiement ainsi que les différents délais me laissent un sentiment désagréable– surtout qu’en cette période de débits inhabituels de mon compte, quelque chose peut m’échapper facilement. À quoi me sert-il de pouvoir faire une réclamation sur un débit effectué par prélèvement si je ne peux plus ensuite l’identifier ? Quel paiement par carte de crédit ai-je vraiment autorisé ?

Cela devrait être plus facile. Cela devrait être plus ordonné. Cela devrait être plus immédiat. L’année prochaine à la même époque ?

Je m’imagine commander la nouvelle radio pour ma mère et que mon application bancaire me demande de débloquer le montant, au moment de la commande. Les pull-overs de Noël kitsch avec le nez de renne sont commandés en deux tailles différentes et essayés. Et qu’au moment de retourner le pull beaucoup trop grand, ma banque en ligne me demande si je débloque le paiement pour le bon pull.

Trois paquets sont à ma disposition dans l’entrepôt de livraison. Afin d’ouvrir le paquet, j’autorise le paiement après en avoir reçu la demande. Le magasin XY réclame encore 90 € de ma part ? Rejeté ! Je n’ai rien commandé chez eux. Et en décembre ma facture de téléphone était apparemment plus élevée que d’habitude et pour cette raison la demande de paiement n’a pas été confirmée automatiquement. Je vérifie le relevé des appels et j’autorise la facture manuellement – c’est exact, j’ai appelé ma famille en Angleterre.

Voilà ce qu’est la demande de paiement. Qui sait si cela rendra la prochaine période des fêtes de fin d’année plus calme et plus paisible. Mais avoir plus de contrôle sur mes paiements avant leurs exécutions et ainsi éviter des regards inquiets sur mon compte, cela sonne presque aussi bien que d’avoir un Noël blanc.

Auteur : Anuschka Clasen