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

Dans la série: Comment améliorer EBICS, 4e partie – à chacun ses extraits de compte

Une grande partie des données qu'une entreprise télécharge d’un serveur bancaire via EBICS sont afférentes à un compte. Comment déterminer dès le téléchargement quel extrait de compte doit être accessible à quel collaborateur? La solution: instaurer un pilotage correspondant côté serveur bancaire.


EBICS régit l’acquisition et la restitution des données au moeyen de types d’ordre et de paramètres de format. Le format de données associé au type d’ordre détermine les possibilités de traitement offertes au niveau du serveur bancaire EBICS. Les contenus des données ne sont cependant pas régis par EBICS et peuvent donc différer d’un serveur bancaire à l’autre et d’une banque à une autre.

Quelles informations de compte pour quels participants EBICS?

Les données auxquelles ont accès les collaborateurs en leur qualité de participants EBICS sont généralement mises à disposition sur le serveur bancaire pour un client déterminé. Chaque participant EBICS du client qui dispose du type d’ordre correspondant peut donc télécharger l’ensemble des données mises à disposition pour ce même client. Cela s’applique aux données liées au compte telles que les extraits de compte et aux transactions prévisionnelles. Lors de l’accès aux données, l’autorisation du participant pour un compte déterminé n’est pas vérifiée, contrairement à ce qui se passe lors de la présentation d’ordres de paiement dans les échanges entre le client et la banque. En outre, le message EBICS ne comporte aucun détail relatif au compte. Les vérifications et les traitements liés au compte dépendent de l’implémentation du serveur bancaire – et dans l’essentiel également de la complétude des informations du compte associé aux données devant être mises à disposition, ainsi que de l’existence effective de ce compte.

Autorisation de compte pour les données mises à disposition

Dans des cas particuliers, un participant EBICS ne devrait pouvoir accéder aux informations que de certains comptes. Une solution évidente serait dès lors de mettre à disposition les données non plus par client, mais par participant. Cependant, les données étant relatives à un client entreprise, cela se traduit dans le cas de plusieurs participants pour un même client par des redondances et donc par un accroissement du volume de données. Il est par conséquent préférable de continuer à mettre à disposition les données par client et de piloter les accès par le biais de l’autorisation que détiennent les différents participants (s’il s’agit de données effectivement liées au compte). Chaque participant accède ainsi exactement aux données des comptes pour lesquelles il est habilité.

Une extension permettant d’indiquer un ou même plusieurs compte(s) dans une demande EBICS – similaire à l’indication d’une période en cas de demande d’historique – serait donc judicieuse. Cette fonctionnalité EBICS permettrait aux participants d’accéder aux données de comptes déterminés. Pour le participant, il n’est pas toujours important que les informations soient à jour pour tous les comptes. Une extension EBICS en la matière permettrait un accès plus ciblé aux données et apporterait aux clients une plus grande flexibilité dans l’interrogation des comptes.

Michael Lembcke