Dans la série: Comment améliorer EBICS, 5e partie – administration des comptes et des participants par les clients

À la base, EBICS est doté de toute une série de types d’ordres utiles pour obtenir des informations relatives aux clients et participants (à noter qu’ils ne sont pas systématiquement proposés par tous les fournisseurs). Il est ici par ex. question de types d’ordres comme HKD (interrogation des données client) et HTD (interrogation des données participant). Les grandes banques helvétiques aimeraient non seulement accéder à ces données, mais également pouvoir les administrer et les modifier elles-mêmes.


Une particularité de l’implémentation suisse réside dans sa limitation actuelle aux types de signatures «T» et «E». Dans le cas de la première, l’ordre d’exécution est transmis sur un canal de communication distinct (par ex. banque en ligne). Pour la deuxième, l’ordre est traité immédiatement, le donneur d’ordre étant lui-même responsable des mesures de sécurité à appliquer. En règle générale, la personne qui a apposé sa signature n’est pas connue dans le cas du type «E», mais seulement l’entreprise ou le client donneur d’ordre.

La raison principale invoquée pour ne pas mettre en œuvre la signature électronique distribuée («VEU») en Suisse reste la complexité de l’administration des droits VEU par participants et par comptes. Etant donnée la fréquente absence de lien direct entre les données de base client de la banque et le produit EBICS, des doubles saisies sont engendrées qui peuvent avoir des répercussions sur un certain nombre de clients et de modifications des autorisations. Il faudrait donc mettre en œuvre un mécanisme proche de l’«Electronic Bank Account Management» (eBAM).

Quinze messages ont d’ores et déjà été modélisés à cet effet dans le standard ISO 20022 (voir catégorie de messages acmt). Cette base pourrait être utilisée pour étendre le protocole EBICS afin de permettre de déléguer au moins en partie l’administration des comptes et des participants au client. Un système de confirmations multiples, par le biais de signatures côté client et un principe de double vérification côté banque, pourrait être ajouté en fonction des différentes exigences en matière de sécurité. À titre d’exemple, le client aurait à contrôler deux fois une transaction sensible, tandis que la banque aurait à valider manuellement son exécution (sans toutefois devoir la saisir intégralement).

Avec un type d’ordre propre à la banque (XYZ) relatif à la transmission de données XML de compte et de participant, il serait possible d’introduire un tel procédé dès aujourd’hui. La banque pourrait alors vérifier les autorisations et les appliquer de manière automatisée par le biais de l’interface avec le produit EBICS (par ex. Webservices). La position suisse en la matière est pour l’heure marquée d’une certaine réserve, puisque de nombreux types d’ordres helvétiques ont déjà été introduits en suivant le même principe – types d’ordres que l’on souhaite remplacer dans un proche avenir par un concept global basé sur la variante française FUL/FDL. Pour notre part, nous souhaiterions que cette exigence soit intégrée dans une future description d’ordre dans EBICS. Tant le client que la banque ont tout à gagner d’une automatisation accrue.

Carsten Miehling