Dans la série: «Comment améliorer EBICS», 3e partie – EBICS désormais aussi en ligne

Les exigences posées à l’e-banking par les entreprises concernent-elles vraiment exclusivement l’échange de données par l’intermédiaire de fichiers? Des opérations administratives en ligne ne sont-elles pas également souhaitées ? Sans quoi, comment expliquer pourquoi les petites sociétés utilisent souvent des solutions d’e-banking issues du domaine d’application des clients privés?


D’un point de vue historique, le protocole EBICS a été développé à partir du transfert de fichiers et se révèle particulièrement adapté pour l’échange rapide et sécurisé de fichiers volumineux entre les entreprises et les banques ainsi que dans le trafic interbancaire. Les fichiers à échanger sont, selon les opérations administratives, identifiés par des types d’ordre ou des paramètres de format, lesquels pilotent ensuite le processus correspondant.

Lors de la transmission de données via EBICS et une fois l’authentification de l’utilisateur effectuée avec succès, la liaison est maintenue ouverte uniquement le temps de la transmission des données. Le traitement en tant que tel est généralement réalisé hors ligne. Les résultats de ce traitement doivent ensuite être téléchargés par le biais d’une opération administrative séparée (PTK/HAC). De la même manière, les données à télécharger sur le serveur de la banque (p. ex. les informations relatives aux montants) sont régulièrement mises à disposition hors ligne. Ces données peuvent ensuite être téléchargées sous forme de fichier via EBICS.

Pour l’heure, le protocole EBICS ne permet pas encore l’enregistrement et l’authentification en ligne d’ordres de paiement ou la consultation en ligne d’informations sur les comptes. Ces fonctionnalités sont supportées par les portails web propriétaires dédiés aux opérations avec les clients privés et par les standards nationaux, par exemple HBCI/FinTS en Allemagne. Si une entreprise souhaite aujourd’hui exploiter à la fois les avantages des opérations administratives en ligne et d’EBICS en se conformant aux standards en vigueur, elle doit parfois mettre en œuvre plusieurs solutions nécessitant des identifications distinctes.

Il serait donc judicieux d’implémenter les processus en ligne adéquats dans le protocole EBICS, par exemple:

• Information sur les soldes des comptes: le protocole EBICS pourrait permettre de fournir des informations en ligne sur les soldes actuels de comptes. Pour ce faire, la liaison serait maintenue ouverte dans EBICS le temps de l’interrogation. Les entreprises pourraient ainsi toujours consulter le solde actuel de leur compte.
• Informations sur l’état et les résultats du traitement d’ordres transmis: Le client a besoin de connaître l’état de traitement de chaque ordre transmis. En combinaison avec la référence d’ordre client qui reste à introduire (cf. article du 18.12.2014), la mise en œuvre d’une requête en ligne permettant d’obtenir l’état d’un ordre unitaire simplifierait grandement le processus d’analyse pour l’entreprise. Cela permettrait en outre d’économiser bon nombre d’appels téléphoniques pour s’enquérir de l’état d’un ordre auprès de la banque.

Il existe bien sûr d’autres applications envisageables. Précisons cependant qu’il ne s’agit ici pas d’une concurrence avec d’autres standards et procédés existant sur le segment des clients privés. L’objectif est plutôt d’ajuster le protocole EBICS aux besoins des banques et des entreprises en matière d’e-banking, et ainsi de le conformer aux exigences futures.

Michael Lembcke

En savoir plus

Dans la série «Comment améliorer EBICS», 2ième partie – de la délégation des autorisations avec EBICS et la Signature Electronique Distribuée (VEU)

Le présent article constitue la suite de la série consacrée aux améliorations envisageables d’EBICS initiée au mois de décembre. Il est dédié au problème suivant : lorsqu’un remettant émet un ordre de paiement via EBICS, les fonctions standard existant à l’heure actuelle ne lui permettent pas d’influer sur les autorisations ultérieures. Dans certains cas, il n’est possible de définir ces autorisations qu’au moment même de la présentation de l’ordre de paiement, et il serait alors utile de pouvoir déléguer lesdites autorisations au cas par cas.

Parmi les fonctionnalités actuelles d’EBICS, différents modèles de gestion des pouvoirs pour la présentation et l’exécution de fichiers d’ordre par les entreprises sont mis en œuvre par les serveurs bancaires. Dans les faits, ces modèles reposent toujours sur les classes de signature E, A, B et T, le nombre de signatures requises et les autorisations personnelles nécessaires pour les fichiers physiques. Par ailleurs, les établissements bancaires et les développeurs de logiciels ont au fil du temps étendu leurs modèles de gestion des pouvoirs, de sorte qu’ils peuvent aujourd’hui être appliqués à différents scénarios. Parmi ces extensions figurent entre autres:

• Les autorisations relatives à une personne et à un ordre en combinaison avec les classes de signature, les types d’ordre (donc des cas commerciaux déterminés) et les comptes.
• Différentes notions de limites, par exemple relatives aux montants, au nombre de transactions, à des périodes, et applicables par paliers aux personnes, comptes et/ou clients, et classes de signature.
• Des notions de groupes en relation avec les classes de signature, par exemple pour définir les pouvoirs de personnes appartenant exclusivement à des groupes différents ou exclusivement au même groupe.
• Des classes de signature propriétaires, tenant compte de critères propres pour l’autorisation.
• Des procédures dédiées aux centres de calcul, dans lesquels les processus de présentation et d’autorisation des ordres de paiement sont traités séparément au niveau du client.

Tous ces modèles se révèlent relativement statiques. Quand un client EBICS soumet un ordre, ses possibilités d’influer sur la façon dont la banque traite la transaction sont limitées. Seules les données de base instaurées par la banque constituent la base de contrôle des droits, de la vérification du format et de l’autorisation. Lorsque dans le cadre d’EBICS la détermination desdroits est réalisable par la banque sans aucune équivoque, cette approche est généralement judicieuse et souhaitable. Cependant, EBICS ne permet pas d’appliquer un traitement spécifique aux ordres qui le nécessiteraient. Pour les ordres SEPA identiques de type CCT au crédit d’un compte déterminé, toutes les personnes autorisées à mettre en œuvre la VEU (Signature Electronique Distribuée) pour un compte et une type d’ordre donné sont également autorisées à donner l’ordre de l’exécuter.

Or, ne serait-il pas judicieux pour le client de pouvoir définir les personnes auxquelles il souhaite déléguer l’autorisation dès la présentation d’un ordre de paiement dans EBICS ? Bien entendu, ces personnes devraient alors déjà disposer auprès de la banque d’un niveau d’autorisation de base correspondant. L’avantage serait que les personnes non désignées, mais qui disposent du même niveau d’autorisation, ne reçoivent pas l’ordre pour la VEU et ne peuvent par conséquent pas le consulter. Ce modèle peut par exemple s’appliquer aux cas où un compte déterminé est utilisé tant pour les paiements de toutes sortes que pour le versement de salaires ou de rémunérations, et que les paiements ne disposent pas d’un identifiant de transaction (transaction ID) particuliere. Ce type d’identification diffère de toute manière d’un format et d’un pays à un autre. L’extension correspondante du standard EBICS permettrait donc de mettre en place une solution indépendante et viable du format.

Michael Lembcke

En savoir plus