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