Inquiétude injustifiée concernant les logiciels standard dans les transactions financières

Ceux qui souhaitent se distinguer de la concurrence développent leurs propres logiciels. Cette règle s'impose de plus en plus dans les entreprises – et toujours plus « d'experts » recommandent aux institutions financières d'investir davantage dans leurs propres applications, ou mieux encore de devenir une entreprise technologique. Mais lorsqu’il s’agit de développer une plateforme pour paiement, ces principes se complexifient.

Les autorités exigent par exemple une continuité de service lorsque les institutions financières souhaitent mettre en place des paiements instantanés. Lors du développement de TRAVIC-Payment Hub, nous avons nous-mêmes expérimenté ce que ces exigences impliquent dans l'architecture d'un logiciel. Il s'y ajoute un grand nombre de systèmes périphériques, comme ceux pour la lutte contre le blanchiment d'argent ou les listes d'embargo ou de sanction, sans parler des systèmes de routage. Pour des raisons de coûts, de nombreuses institutions financières préfèrent par conséquent ne pas du tout traiter ces transactions financières en interne et les externalisent auprès d’une institution centrale au sein d'un grand groupe. En revanche, ce procédé se révèle insatisfaisant si le transfert de paiements représente à terme une activité stratégique.

Plaque tournante pour paiements

C’est pourquoi nous avons recherché la composante spéciale qui doit être intégrée dans les systèmes de paiement par les institutions financières pour se démarquer de la concurrence et pour offrir leur propre transfert de paiements. Cet aspect est notamment pertinent pour les institutions qui se présentent comme prestataire de services auprès de clients entreprises pour le traitement d’opérations financières dans certaines régions du monde. Le résultat : les processus de nombreuses banques ne diffèrent guère les uns des autres. Souvent seul l'ordre dans lequel ils sont exécutés les différencie. Suite à ce constat, nous avons conçu une plaque tournante de paiement qui fonctionne comme un manège. Les fonctionnalités spéciales sont accessibles à chaque étape, de la même manière que les enfants peuvent accéder à n’importe quel manège de leur choix dans une fête foraine (voir aussi figure 1).

TRAVIC-Payment Hub permet à une institution financière d'offrir toute configuration envisageable. Cela s'applique à l’administration du routage, pour lequel un ensemble complexe de règles peut être défini, et également aux systèmes périphériques connectés. Mais de quelle façon TRAVIC-Payment Hub sait-il ce qui est censé se produire, si par exemple le système de conformité nécessite une action ? En règle générale, ce sont les systèmes périphériques qui doivent s'adapter aux indications du système principal. Donc pourquoi les banques s’encombreraient-elles d'un nouveau défi de transfert de paiements, surtout après avoir probablement abandonné un monolithe dans leur système central ? La solution est de doter chaque moteur de workflow intégré de son propre script, ce qui permet une connexion aisée et efficace du fournisseur (par exemple PPI) aux autres systèmes.

Le mot « Hub » dans TRAVIC-Payment Hub est donc dans le même temps un nom de produit et un service.

Développement de logiciel à l'inverse

Techniquement, nous nous penchons particulièrement sur ce qui autrement deviendrait une « monnaie » à l'extérieur. Le langage de script implémenté permet à une institution financière d'intégrer ses propres fonctionnalités métier dans TRAVIC-Payment Hub, sans devoir modifier le code source du logiciel. En raison de la séparation de la technique et de la fonctionnalité métier, une partie essentielle du développement du logiciel est ainsi transférée du fournisseur à l'utilisateur. De cette façon, les mises à jour sont toujours supportées, même si TRAVIC-Payment Hub doit gérer un réseau complexe de systèmes périphériques. De plus, les départements informatiques ne seront pas tentés de modifier le code du système de traitement des paiements principal et ne risqueront donc pas créer des problèmes en cascade.

Dans la pratique, TRAVIC-Payment Hub reçoit les différents statuts des systèmes connectés. Le langage de script est utilisé en interne par les développeurs du département informatique ou le prestataire intégrateur, pour définir la manière de traiter les paiements selon leurs différents statuts. Dès que la définition du workflow est terminée, le système compile le code pour que TRAVIC-Payment Hub s’exécute. Des tâches créées par le moteur de workflow sont traitées par un moteur de tâches interne. Ci-dessous un exemple simple sur la manière dont le langage script utilisé dans TRAVIC-Payment Hub de PPI traite les OUR Charges, c'est-à-dire comment TRAVIC-Payment Hub vérifie si les frais d'un paiement sont intégrés dans le paiement et s'ils peuvent être retenus ou si une demande de paiement doit être créée pour encaisser les frais.
Status CHECKINBOUNDCHRGS {
    if payment is inbound and (payment is ourCharges) then {
        if payment is ourChargesReceived then {
            just set status VALIDATERECEIVCHGS and leave step
        }
        if payment is correspondentChargeExpected then {
            if payment is debitAuthorized then {
                just set status CREATEADVICEOFCHGS and leave step
            }
            just set status CREATECHARGEREQ and leave step
        }
    }
    just set status DONE and leave step
}



Introduire TRAVIC-Payment Hub

Avec la gamme de produits TRAVIC, PPI couvre le processus entier de paiement d'une institution financière, depuis la réception du paiement jusqu'à sa compensation en passant par les activités interbancaires. TRAVIC-Payment Hub représente le traitement noyau des transactions financières. Notre solution fonctionne en tant que banque de client et banque de compensation – même en fonctionnement parallèle – et elle offre également une fonctionnalité pour paiements instantanés. En plus, la solution permet autant l’exploitation locale que l’externalisation du produit de haute disponibilité logicielle, en partenariat avec nos partenaires infrastructurels.

Auteur : Thomas Riedel



Plus d'informations :

SEPA 2.0 : La mise à jour du standard ISO 20022 risque de causer une triple migration

SEPA et le standard ISO 20022 sur lequel il est fondé peuvent être considérés comme des moteurs parmi les initiatives globales ISO 20022. Très tôt, ils se sont présentés comme des règles de fonctionnement (rulebook) pour les différents formats de paiement dans la zone euro, les utilisant en tant que standard de format commun pour permettre l'interopérabilité transfrontalière et inter-systèmes. Malgré certaines spécificités locales, SEPA a permis un traitement continu de bout en bout sans discontinuités et conversions de supports au cours des dernières années, notamment en harmonisant les caractéristiques nationales avec une spécification EPC uniforme. Le traitement de bout en bout s'applique dans ce cas non seulement à la relation interbancaire mais également à la communication du donneur d'ordre au bénéficiaire. Cela est rendu possible par l'utilisation cohérente d'un dictionnaire de données uniforme (data dictionary) au format ISO 20022 qui fournit une base uniforme pour l'échange de données en transportant des éléments de données des messages client-banque (pain) jusqu’aux messages interbancaires (pacs) en passant par les messages des clients bancaires (camt) sans conversions.

Tandis que SEPA continue son évolution (notamment en raison de l'introduction des paiements instantanés), la norme ISO 20022 utilisée pour le SEPA doit encore rattraper son retard : plus particulièrement en ce qui concerne la base 2009 définie par l'EPC. Cette norme ISO étant également en constante évolution pour refléter les développements actuels, le groupe de travail EPC responsable de la poursuite du développement du schéma SEPA prévoit de migrer tous les schémas (SCT, SCT Inst, SDD Core, SDD B2B) vers la version 2019 de la norme ISO 20022. La transition doit être annoncée en 2020 et entrera définitivement en vigueur en novembre 2022 dans le cadre d'une migration big bang (des formats interbancaires). Ce changement, entre autres, fait actuellement l'objet d'une consultation publique en tant que demande de modification majeure (Change request). Au cours de cette phase, des remarques sont demandées au cercle des parties participant à la consultation.

L'une des raisons pour lesquelles cette demande de modification, « CR » est importante est la prise en charge future de Request to Pay (demande de paiement), qui ne peut pas être fournie avec la version ISO actuelle car les futurs éléments requis ne sont pas disponibles dans son format. Cependant, une version à jour de la norme ISO est également requise pour d'autres développements futurs, en particulier à la lumière des migrations TARGET2 et SWIFT MX, qui sont également basées sur la version 2019 de la norme ISO.

La bonne nouvelle est que la norme ISO 20022 est déjà bien implantée dans le monde du SEPA. Contrairement à l'introduction de SEPA, il n'est pas nécessaire d'introduire un nouveau format ni de remplacer les anciens formats à grande échelle. Les systèmes existants doivent « seulement » être ajustés et apprendre à traiter les changements tels que les nouveaux éléments de données. Néanmoins, le défi est de maîtriser une migration big bang avec des effets sur les paiements interbancaires et les formats à l'interface client-banque.

La mauvaise nouvelle: est qu’en raison des développements actuels, la date de transition SEPA coïncide désormais avec le début de la période de transition de SWIFT MT à MX. L'idée originale de réaliser la transition SEPA en 2022 avait pour objectif de ne pas exécuter les trois grandes migrations - TARGET2, SWIFT MX et SEPA ISO 20022 Version 2019 - presque en même temps et d'ainsi séparer l'effort nécessaire. Si TARGET2 aussi prévoit un décalage de la migration big bang prévu, comme il est déjà revendiqué par le marché, toutes les migrations auront lieu en même temps ce qui représente un défi majeur pour les prestataires de services financiers concernés annulant l'approche initiale de séparer les différentes migrations. A qui la faute ? La réponse est vite trouvée : la pandémie mondiale de Corona a mis à rude épreuve notre vie quotidienne et l'économie.

Dans cette situation, les institutions financières doivent garder un œil sur les développements futurs et s'adapter aux changements à venir. Nous surveillerons également de près les événements en cours et continuerons de rendre compte des modifications de l'ISO SEPA une fois la consultation du marché terminée.

Auteur : René Keller

DSP2: Sécuriser les paiements de masse via EBICS

La sécurité des paiements de masse a toujours été un problème. Les premières tentatives visant à établir une protection simple contre la manipulation frauduleuse se sont avérées peu efficaces et n'ont donc jamais conduit à une sécurité fiable. Par exemple, le total de tous les numéros de compte des bénéficiaires a été créé pour empêcher les criminels de modifier ultérieurement les paiements. Mais lorsque l'IBAN est arrivé, même cette méthode extrêmement simple n'était plus utile - les institutions financières l'ont finalement abandonnée en raison des défis mathématiques impliqués.

Il ne reste à ce jour que le nombre de paiements inclus et le montant total. Personne ne prétend que de telles valeurs offrent une protection efficace.

La DSP2 et du RTS ont été plus prometteurs pour fournir plus de sécurité pour les paiements. Cependant, ils n'ont pas conduit à une percée pour les paiements de masse qui sont particulièrement courants chez les entreprises clientes. Pour cause : afficher le bénéficiaire, le compte et le montant et demander au client de vérifier toutes les données contenues, par exemple via un lien dynamique, est difficilement réalisable pour le paiement des salaires dans une entreprise de plus de 10 000 employés. Cela est impossible d'un seul point de vue organisationnel et peut difficilement être réalisé en utilisant les canaux établis sur le plan technique.

Alors, comment s’assurez-vous que le fichier de paiement, une fois créé, est exécuté, sans altération, par l'institution financière ?

La réponse est EBICS !

EBICS est la norme en matière de paiements aux entreprises européennes depuis des années. Il est disponible dans tous les grands pays où le volume de transactions est élevé, tels que l'Allemagne, la France, l'Autriche et la Suisse. D'autres pays suivront.

Alors pourquoi la société EBICS ne définit-elle pas une norme d'audit générale et obligatoire basée sur des procédures internationales de valeur de hachage (par exemple SHA-256) et n'établit-elle pas l'ensemble de règles correspondant ? Le principe est le suivant : toutes les applications qui génèrent des fichiers de paiement de masse génèrent toujours la valeur de hachage correspondante et la transmettent à l'institution financière avec le fichier de paiement. Ainsi, cette valeur de contrôle peut être recalculée dès l'arrivée du fichier de paiement et présentée au client pour vérification avant validation. C'est aussi simple que cela !

Simple et très efficace, car la valeur de hachage identique garantit qu'aucune manipulation n'a eu lieu entre la création du fichier de masse et le traitement de masse par l'institution financière.

Si, pour la définition de la procédure de valeur de hachage par la société EBICS, nous considérons également le client final, au lieu de la comparaison à 32 valeurs doubles, un algorithme pourrait être trouvé qui transforme la valeur de hachage en un nombre composé de 8-10 chiffres - semblable à un TAN. Les clients et les utilisateurs utilisent déjà ce type de valeurs de nos jours. Une comparaison des valeurs de contrôle ne nécessite qu'un minimum de temps et est facile à faire.

Par ailleurs, laisser l’établissement de cette définition au marché seul n’est pas une bonne idée. Si tous les acteurs impliqués font leur propre définition, une multitude de procédures différentes vont être créées, ce qui déroutera les clients au lieu de fournir une sécurité supplémentaire.

C'est donc l'une des tâches de la société EBICS de fournir une solution contraignante à ce stade et de répondre ainsi aux exigences de la DSP2 pour les paiements de masse.

Auteur : Michael Schunk

eBAM – composante de la numérisation

Une crise peut aussi être un catalyseur de progrès. La crise du corona virus est inédite comparée aux crises précédentes en ce sens qu’elle nous plonge dans le monde numérique - de l'enseignement à domicile au home office, la pression est exercée sur la réévaluation de nombreuses activités sur de nombreux aspects. Ce gap qui n’était pas perçu comme tel devient flagrant dans un contexte de confinement et de restrictions en tout genre.

Et quand on parle de solutions de Cash Management ici, dans le blog, je pense que le sujet de la gestion des comptes bancaires (Bank Account Management) en fait également partie. Cela comprend non seulement l'échange de messages sur l'interface client-banque, mais également la gestion des données de base de la banque et du compte et de leurs autorisations de signature (pas uniquement les signatures numériques) ainsi que de tous les documents associés, les processus dans l'ensemble du cycle de vie du compte et la confirmation de l'équilibre fastidieux. C'est là que toutes les exigences en matière de KYC ainsi que les autorisations et les identités numériques entrent en ligne de compte.

Ces sujets auraient pu depuis longtemps être transférés dans le monde numérique dans le cadre d'eBAM - la gestion électronique des comptes bancaires. La normalisation est nécessaire ici et elle commence par l'orthographe correcte. EBAM ou eBAM ou e-BAM ?

Il est temps de réagir - de nombreux blocs de construction sont disponibles. Certains éditeurs de solutions de Cash Management ou de gestion de la trésorerie proposent des modules spécialement pour l'administration des données côté entreprise. Des réussites peuvent déjà être rapportées pour les premiers processus d'ouverture de compte purement numérique. Il y a également eu des développements encourageants concernant le KYC et les identités numériques. Même les messages à l'interface client-banque en XML selon la norme ISO 20022 sont en principe disponibles. La poursuite du développement de la norme est également examinée par un groupe de travail du CGI-MP (mise en œuvre mondiale commune - pratiques du marché) - une initiative mondiale des entreprises, des institutions financières et des fabricants pour l'harmonisation de l'utilisation de l'ISO 20022 à l’interface client-banque. Les normes sont à la base de la numérisation. Ils créent une sécurité pour les fabricants et les utilisateurs.

En Allemagne, avec l'annexe 3 de l'accord DFÜ, il existe une longue tradition multibancaire - c'est-à-dire une norme qui atteint de nombreuses institutions financières. Pour cela, il est désormais possible d'intégrer des rubriques optionnelles telles que la facturation des services bancaires (BSB). Tout le monde n'a pas besoin de soutenir le sujet - mais s'ils le font, ils doivent se conformer à la norme. Et je voudrais plaider pour une telle option au sujet de l'eBAM. Pour EBICS, il est facile de transporter les messages XML dans le groupe de messages camt (gestion des comptes) - les normes (harmonisées) doivent être convenues. Le cas d'utilisation simple d'une vue d'ensemble des autorisations de signature montre un premier pas dans cette direction avec EBICS en utilisant le type de commande HKD, mais - voir ci-dessus - ce n'est encore que le début.

Il est bien entendu que la partie communication client-banque d'eBAM ne doit pas être réalisée via EBICS, car un itinéraire de transport via SWIFT est également possible. Même les API ouvrent de nombreuses possibilités. Indépendamment du canal, la base devrait être une standardisation du contenu (XML en harmonie avec json) et des processus de base. Et pour le contenu au format XML selon ISO 20022, un chapitre supplémentaire devrait être ajouté à l'annexe 3 de l'accord DFÜ.

Sur cette base, les fournisseurs mentionnés ci-dessus peuvent ensuite étendre leurs produits pour le « multi-bancaire » et les institutions financières peuvent offrir de nouveaux services à de nombreux clients avec des systèmes similaires - leur permettant ainsi de s'intégrer très bien dans le monde numérique avec ces services.

Auteur : Dr. Mario Reichel

L’impact du M2M : Communication entre machines sur les transactions financières

L’économie du M2M « Machine to Machine », Internet des objets connaît une croissance rapide. Toujours plus de machines et appareils sont interconnectés. D’ici 2025, 75 milliards d’appareils devraient être interconnectés dans le monde entier. Selon les analyses de BizIntellia, un prestataire IdO américain, les solutions autour l’IdO contribueront à hauteur d’environ 14,2 milliards de dollars au PIB mondial d’ici 2030.

À l’avenir, l’IdO occupera une place significative dans nos vies et dans nos sociétés. La question est de savoir quel impact aura l’IdO sur les paiements ?
Quels sont les potentiels nous réservent les paiements Machine à Machine (M2M) ?

Comment l’IdO et les paiements sont-ils connectés ? Les machines sont autorisées à transférer non seulement des identités et des informations, mais également des valeurs. Ils envoient des paiements à d’autres machines de manière autonome, sans avoir besoin de validation humaine. Toutefois, si ces transactions commerciales ne peuvent pas s’exécuter sans interruptions (par exemple, les machines doivent attendre une action manuelle telle qu’une confirmation de paiement), des périodes de blocage ou même des terminaisons anormales peuvent en résulter - les deux scénarios doivent être évités, afin d’exploiter pleinement le potentiel des paiements M2M.

Mais les paiements M2M ne sont pas uniquement des visions futures. Des solutions concrètes sont déjà en cours de développement, par exemple, dans l’industrie automobile. Certaines entreprises mettent déjà en place les écosystèmes nécessaires. L’idée est que les automobiles aient leurs propres portefeuilles avec de l’argent électronique et puissent ainsi payer les frais de carburant ou de péage sans intervention humaine.

Afin d’analyser l’impact des paiements M2M, nous avons mené une étude sur le thème « Machines payantes » qui traite notamment des questions suivantes :

  1. Quelles conditions préalables doivent être remplies pour permettre la mise en œuvre des paiements M2M ?
  2. Quels sont les défis de la mise en œuvre des paiements M2M ?
  3. Dans quelle mesure le nombre de transactions de paiement augmentera-t-il en raison des paiements M2M ?
  4. Quels moyens de paiement conviennent le mieux aux paiements M2M ?
  5. Quel impact les paiements M2M ont-ils sur les prestataires de services de paiement ?
  6. Comment les prestataires de services de paiement devraient-ils réagir aux paiements M2M ?

Pour que les paiements M2M deviennent une réalité, les machines participantes doivent d’abord recevoir leur identité propre de machine comportant des attributs individuels les distinguant des autres machines. Une identité de machine sécurisée ne peut être ni manipulée, ni falsifiée ou ni utilisée à mauvais escient. La machine reçoit une identité unique et sécurisée qu’elle peut utiliser pour s’authentifier au sein du réseau productif auprès d’autres machines, instances et participants.

Il y a un vide juridique en matière d’objets connectés. En effet des progrès doivent être faits sur le plan réglementaire. Il faut établir des règles de responsabilités claires pour les actions des systèmes autonomes et pour l’allocation des risques liés à l’utilisation des systèmes autonomes. Enfin et surtout, de nouveaux systèmes de responsabilité sont nécessaires qui tiennent compte des particularités des machines autonomes.

En termes de mise en œuvre pratique, nous avons identifié les domaines d’action suivants, dont la solution sera particulièrement difficile:

  1. Cartographie de l’identification des paiements automatiques
  2. Contrôles de conformité par rapport à une machine (KYO au lieu de KYC)
  3. Traitement des informations retournées (y compris les perturbations des processus)
  4. Prise en compte d’un reporting plus complexe et plus complet
  5. Sécurité accrue des machines et des interfaces
  6. Mise en œuvre cohérente de l’intégration numérique et des processus numériques

De nombreuses analyses suggèrent que le nombre de transactions augmentera considérablement avec les paiements M2M. Nous sommes d’accord avec cette évaluation et prévoyons également une augmentation significative. Compte tenu des effets de compensation, nous estimons que d’ici 2027, il y aura environ 12 milliards de transactions de paiement « Machine à Machine » supplémentaires en Allemagne et environ 50 milliards dans l’UE.


Tous les modes de paiement électronique courants ne sont pas adaptés aux paiements M2M. Nous pensons que la monnaie digitale (stable coins : indexées sur un actif réel, unbacked coins : non indexées sur des actifs réels et devises électroniques) et la monnaie électronique sont les plus adaptées aux paiements M2M.

Les méthodes de paiement établies ont généralement des frais de transaction plus ou moins élevés. Les solutions de crypto-monnaie et de monnaie électronique, en revanche, permettent des transactions peu coûteuses même pour les plus petits montants et les rendent attrayantes pour une utilisation dans l’IdO. Après tout, ils offrent la possibilité de régler économiquement même les petits paiements de services, pour un montant inférieur à un centime ; comme, par exemple, l’utilisation d’une ampoule dans une maison intelligente. Les solutions de monnaie électronique et de crypto-monnaie peuvent également être intégrées indépendamment des prestataires de services financiers traditionnels.

Reste à savoir comment les prestataires de services de paiement devraient se positionner à l’avenir. L’Internet des objets renforcera encore la tendance à la différenciation des fournisseurs spécialisés avec un modèle commercial basé sur les données et des fournisseurs d’infrastructure.

Les fournisseurs spécialisés peuvent utiliser l’augmentation du volume de données due à l’IdO à leur avantage dans la concurrence du marché et développer des opportunités commerciales. Par exemple, des services supplémentaires personnalisés avec précision peuvent être proposés aux clients sur la base de données d’utilisation détaillées. Cela dépend de la capacité des prestataires de services de paiement à se placer « au-dessus » des machines ou au moins à agir comme des agrégateurs de données qui compilent les données d’utilisation pertinentes en chiffres et les transfèrent.

En ce qui concerne le positionnement en tant qu’agrégateur de données ou hub de données, les prestataires de services de paiement pourraient également assurer la confiance nécessaire entre les personnes, les entreprises et les machines participantes, et agir comme une sorte d’instance de compensation pour les identités numériques sécurisées et les données valides.

En résumé, cela signifie que les prestataires de services de paiement traditionnels doivent surmonter des défis considérables. Les exigences fonctionnelles et surtout techniques de l’infrastructure des prestataires de services de paiement entraîneront des changements massifs. Ils doivent répondre aux prérequis suivants : 

Disponibilité totalement ininterrompue, augmentant l’importance des modèles d’exploitation 24/7/365 et du traitement des transactions en temps réel
  • Les temps d’arrêt pour l’installation de nouvelles versions ne sont plus possibles.
  • Capacité à gérer des charges très élevées en raison de milliards de transactions supplémentaires
  • Possibilité de faire la distinction entre les paiements automatiques et non automatiques, car ils seront traités par des règles différentes
  • Possibilité de numérisation complète et d’intégration de la machine
  • Conformité future avec KYO pour les machines, qui n’est actuellement pas encore réglementé, en combinaison avec KYC, cartographie dans les systèmes correspondants et, en particulier, réglementation organisationnelle
  • Possibilité non seulement de déclencher des paiements, mais également de traiter les informations en retour du système et de traiter les perturbations en conséquence. Sur la base du retour d’expérience, les machines doivent pouvoir tirer les bonnes « conclusions » en temps réel et sélectionner des alternatives si nécessaire.
En outre, les prestataires de services de paiement doivent décider comment ils souhaitent se positionner et ajuster les structures de vente, car les écosystèmes de l’IdO deviendront de plus en plus importants.

Auteur: Michael Titsch

EBICS-Security – Quand est-il temps de mettre à jour votre système client ?

EBICS spécifie différentes fonctions et règlementations de sécurité qui doivent être respectées par les clients et les institutions financières. Ces dernières doivent toujours veiller à ce que les spécifications les plus à jour soient mises en œuvre et supportées par leurs serveurs bancaires EBICS. Cependant, les clients EBICS et chaque utilisateur ont aussi la responsabilité d’utiliser à tout instant des logiciels client répondant aux standards de sécurité EBICS en vigueur. Il est donc primordial, tant en raison des adaptations fonctionnelles que pour des raisons de sécurité, de mettre à jour fréquemment les logiciels client EBICS.

Toutefois, la mise à jour d’un logiciel client EBICS existant ne signifie pas que ce logiciel EBICS sera automatiquement capable de communiquer avec l’institution financière en utilisant la version EBICS et les procédures de sécurité les plus récentes. En fonction de la version EBICS et des fonctionnalités client utilisées précédemment, il est nécessaire de mettre à jour les différentes clés d’application pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006) ainsi que la version d’EBICS à utiliser, suivie d’un échange de ces données avec les serveurs bancaires EBICS. Il peut aussi être nécessaire de mettre à jour le cryptage Internet (TLS) vers une version plus récente et plus sécurisée en échangeant des certificats renouvelés. De telles mises à jour requièrent en règle générale une intervention proactive et des ajustements manuels de la part de l’utilisateur EBICS.

Pourquoi ces mises à jour sont-elles importantes ?

La communication EBICS via Internet possède ses propres spécifications en termes de procédures de sécurité. La société EBICS les met à jour et les adapte régulièrement aux exigences de sécurité en vigueur au moyen de nouvelles versions d’EBICS. Un exemple est la longueur des clés. Les anciennes versions d’EBICS permettent encore d’utiliser des clés de longueur 1 024 bits pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006). Mais cette longueur ne répond plus aux exigences de sécurité actuelles, car les clés trop courtes sont considérées comme peu sécurisées. Les versions plus récentes d’EBICS n’acceptent que des clés d’une longueur minimale de 2 048 bits. Un autre exemple est mis en évidence avec les procédures et les versions du cryptage TLS. Afin de répondre plus aisément aux recommandations de sécurité, par exemple à celles de BSI en Allemagne, la société EBICS a créé une annexe distincte des spécifications EBICS 3.0, appelée Transport Layer Security qui comporte les directives y afférentes. Comme les spécifications de la version 2.5 d’EBICS ne pouvaient pas être adaptée rétroactivement, la DK (Die Deutsche Kreditwirtschaft) a en outre publié en 2019 son propre document de recommandations intitulé Recommandations concernant les protocoles de sécurité EBICS et la longueur des clés (disponible en allemand et en anglais). Il contient des informations sur les procédures de sécurité à utiliser pour EBICS. Voir aussi www.ebics.de et www.ebics.org.

Afin de permettre aux utilisateurs d’EBICS une transition en douceur vers les nouvelles versions d’EBICS et les nouveaux standards de sécurité, la plupart des institutions financières proposent toujours à leurs clients les versions plus anciennes, en parallèle avec les nouvelles. Malheureusement, il est devenu évident que dans de nombreux cas cela conduit à ce que les clients ne saisissent pas l’occasion de mettre à jour leur communication EBICS. Nombreux sont ceux qui continuent à utiliser les anciens systèmes et procédures. Il est donc plus difficile pour les institutions financières de mettre fin à ces anciennes procédures.

En fin de compte, chaque acteur de la communication EBICS s’attend à ce qu’un échange de données sécurisé soit assuré. Personne ne veut subir de dommages. Ce qui signifie que chacun doit apporter sa contribution. Bien entendu la sécurité d’EBICS n’est pas la seule chose que les institutions financières et les entreprises doivent garder à l’esprit. Après tout, toutes les parties impliquées doivent prendre toutes les mesures de sécurité possibles dans leurs infrastructures et dans leurs solutions logicielles afin de prévenir les abus et les pertes.

Alors, pourquoi attendre ? Allons-y.

Auteur: Michael Lembcke

Open banking : EBICS versus API

L'Open banking est l'une des tendances de fond que de nombreuses institutions financières risquent de manquer. Puisque presqu’aucune interface DSP2 ne semble être prête pour le marché, les autorités de surveillance bancaire ont accordé une période de transition allant jusqu'à décembre 2020. Mais le problème est autre : de nombreuses institutions ne ressentent que peu d'envie d'investir beaucoup d'argent pour faciliter la vie des fournisseurs d’interfaces d'Open banking – d'autant plus que les protocoles établis comme FinTS et EBICS offrent beaucoup plus de possibilités que « l'APIsation » du secteur bancaire.

Les deux protocoles, FinTS et EBICS, couvrent déjà presque tous les domaines des opérations bancaires : des paiements aux opérations de crédit en passant par les transactions de titres. Au total, plus de 200 processus sont disponibles qui décrivent de façon contraignante tant les interfaces métier que la communication technique entre les partenaires participants. Dès les années 90 HBCI et FinTS ont été les pionniers en matière de standards ouverts dans la communication avec les institutions financières. Il y a plus de dix ans qu'EBICS a été introduit par la Deutsche Kreditwirtschaft (DK) ou par son prédécesseur comme standard contraignant pour les échanges avec les entreprises. L'Open banking est donc une réalité en Allemagne depuis de nombreuses années.

Aucune interface DSP2 uniforme en vue


Aussi bonne que soit l'idée de l'Open banking, les évolutions auxquelles pousse la DSP 2 laisse perplexes beaucoup d'institutions financières, même celles qui veulent avancer. D'un côté, la DSP2 est supposée servir de base à une norme européenne d'Open banking. De l’autre, le législateur a délibérément laissé ouverte la question de savoir comment la communication doit avoir lieu et comment elle peut être sécurisée. En conséquence, les fournisseurs d'API pour l'Open banking exhortent les banques à implémenter leurs solutions et à adopter leurs propres interprétations de l'Open banking, juste pour ne pas être marginalisées. En plus, différentes initiatives dans divers pays développent des protocoles pour les aspects technique/métier des applications, ce qui conduit à un nombre incontrôlé des types d’API. Les concepts transnationaux par contre sont encore loin d'être en vue.

Tout cela pourrait devenir un puits sans fonds pour les institutions, s'il n'y a pas bientôt une spécification uniforme de la DSP2 que chaque banque puisse suivre. Tant que cela n'arrivera pas, de nombreuses visions de l'Open banking resteront des vœux pieux. Après tout, selon la loi, l'ouverture doit être gratuite et exempte de discrimination. Gagner de l’argent avec elle est réservé à d’autres acteurs. Alors, quelle devrait être la motivation d’une banque à continuer d’ajouter des nouvelles API gratuitement, juste pour que les prestataires tiers puissent plus facilement augmenter leurs parts de marché ? Cela rétrograderait les institutions elles-mêmes au rang de simples fournisseurs de services. Il est beaucoup plus raisonnable de s’en remettre à des standards établis de longue date.
EBICS : Open banking pour entreprise

L'un de ces standards est EBICS. Il est largement répandu : outre l'Allemagne, EBICS est aussi populaire en France. Il existe un accord de coopération entre la Deutsche Kreditwirtschaft et son équivalent français, le CFONB. Ces deux plus grands marchés des paiements de la zone euro utilisent EBICS pour les entreprises et les opérations interbancaires. La Suisse (SIX) est également fan d’EBICS, et l’Autriche (STUZZA) envisage d’y participer. Au lieu de se perdre dans le maquis des API, il vaut mieux se demander comment EBICS peut évoluer pour être conforme à la DSP2. Et la réponse est : avec une signature à distance (voir figure 1). Un portail EBICS moderne peut générer la signature et l'envoyer au serveur bancaire EBICS en utilisant des données entrantes comme le code d'un PhotoTAN ou d'un QR TAN au moyen de dispositifs matériels.
Figure 1 : Comment les signatures à distance EBICS étoffent EBICS pour en faire une solution d'Open banking conforme à la DSP2
EBICS offre de nombreux avantages aux entreprises. Celles qui disposent d'un client EBICS peuvent effectuer des opérations bancaires multiples et également utiliser la signature électronique distribuée (VEU). De cette façon, les modèles de rôles et de droits peuvent être réalisés (signatures T, A, B et E), pour déterminer par exemple, si les ordres de paiement sont remis par des personnes autorisées ou si la personne concernée dispose des autorisations appropriées pour valider ces ordres de paiement. Tout comme pour FinTS, ce qui suit s'applique également à EBICS : l'infrastructure nécessaire pour mettre en œuvre l'Open banking existe déjà. Rien que pour cette raison il est compréhensible que de nombreuses institutions aient du mal à investir pour le moment. Rien ne garantit qu'elles choisiront le bon fournisseur d'API ou que les législateurs n'adopteront pas de nouvelles règlementations rendant obsolètes les investissements déjà réalisés.

Auteur : Michael Schunk