Types d’ordres et paramètres de format – les différentes variantes d’EBICS

En dépit de l’existence d’une seule et unique spécification, EBICS est mis en œuvre de manières différentes en Europe pour la présentation d’ordres de paiement et leur authentification par les banques. En Allemagne, l’on utilise par exemple exclusivement les types d’ordres, alors qu’en France l’on emploie les paramètres de format de fichier. Mais le client doit-il vraiment connaître ces différences? Comme je l’annonçais dans mon dernier article, voici quelques informations supplémentaires.


Par le biais du type d’ordre EBICS, le client indique la nature de la transaction qu’il souhaite transmettre au serveur bancaire. Si le type d’ordre est connu du serveur et que la personne à l’origine de la demande dispose des autorisations requises, le traitement est exécuté en appliquant le format spécifique à ce type d’ordre.

S’agissant des trigrammes des types d’ordres, EBICS fait systématiquement la différence entre l’initialisation d’un envoi de fichier et celle d’une récupération de fichier. Le standard établit en outre une distinction entre types d’ordres de production et d’administration. Les types d’ordres d’administration sont ceux permettant de piloter le protocole EBICS en soi, comme HIA et INI pour l’échange de clés ou encore HVU pour l’obtention de la signature électronique distribuée (ou VEU). Les types d’ordres de production quant à eux décrivent le contenu d’un transfert de fichier, comme CCT pour les paiements au format SEPA Credit Transfer. Les types d’ordres de production déterminent donc le format de traitement spécifique à appliquer.

EBICS établit une liste des types d’ordres de production à utiliser, ainsi que des transactions et des formats concernés. Ces types d’ordres de production sont pour l’heure principalement mis en œuvre en Allemagne.

En France et indépendamment du contenu du fichier, l’on utilise pour chaque ordre de production un type d’ordre déterminé pour les envois (FUL) et les récupérations (FDL). Pour fournir au serveur bancaire les données requises concernant le format, le type d’ordre reçoit côté client un paramètre de format de fichier (FileFormat) pouvant comprendre jusqu’à 40 caractères. La structure de ce paramètre est également spécifiée par EBICS.

Qu’en est-il de la compréhension mutuelle entre serveur bancaire et logiciel client?

Tant la variante allemande que celle utilisée en France en matière de types d’ordres permettent d’instaurer des contrôles d’authentification spécifiques à chaque format côté banque. Les paramètres de format de fichier rendent ici possible une convention plus détaillée entre le client et la banque sur le type de contenus à échanger (par exemple la version SEPA, les spécificités propres au pays). Ceci dit, les types d’ordres peuvent se révéler plus faciles à mettre en œuvre pour le client, car il n’a alors pas besoin de se poser de question sur les détails de format dans EBICS. Seul impératif : les serveurs bancaires EBICS et les logiciels client doivent se comprendre. Pour ce faire, le client doit absolument connaître le langage parlé par le serveur bancaire en face de lui.

Les deux modes d’échange de données de production entre logiciel client EBICS et serveur bancaire EBICS ont leurs avantages et leurs inconvénients. En définitive, la décision revient à l’entreprise cliente qui détient peut-être des comptes auprès de différentes institutions bancaires dans divers pays. Ce client exigera alors sans doute un standard unique. Le succès d’EBICS dépendra par conséquent également de l’homogénéité de son utilisation, ou de l’interopérabilité de ses différentes variantes. Une tâche pour les spécificateurs. Comme indiqué dans l’article de Carsten Miehling du 9.9.2014, le processus est déjà en marche.

Michael Lembcke
Réactions :

0 commentaires:

Enregistrer un commentaire