Comment améliorer EBICS, 8e partie – éviter les doubles remises grâce aux fonctionnalités d’EBICS: Ce genre d’incident peut se produire rapidement, comment procéder?

Un moment d’inattention et les ordres de paiement ont été transférés à la banque deux fois via EBICS. Et personne ne l’a remarqué. Plusieurs scénarios sont possibles:

1. Un paiement est saisi et transmis deux fois.
2. Le fichier comportant les ordres de paiement est envoyé une nouvelle fois et donc en double.
3. Le fichier est envoyé deux fois pour des raisons techniques, parce que le statut de transfert du premier envoi était équivoque.

Une double remise se caractérise par le fait qu’un client transmette deux fois un paiement ou un fichier identique à sa banque pendant un laps de temps déterminé. Mais deux remises identiques peuvent-elles toujours être considérées comme une double remise devant être refusée? La réponse est non, car certains paiements sont émis et transmis plusieurs fois par le remettant en toute connaissance de cause.


Dès lors, comment identifier à coup sûr les doubles remises côté banque et éviter ainsi tout préjudice pour le client?

Dans un premier temps, il est possible d’identifier et de refuser les doubles remises évidentes dès leur réception par le serveur bancaire EBICS.

S’agissant des doubles remises pour raisons techniques (scénario 3), le protocole EBICS jusqu’à la version 2.4 est en mesure de détecter si un client réutilise un ID d’ordre attribuée par le client EBICS dans un laps de temps déterminé. À partir de la version 2.5, le serveur bancaire EBICS attribue un ID d’ordre unique dès le début de la communication. Par conséquent un doublon avec même ID d’ordre ne peut pas se produire via EBICS V2.4.

En revanche, un serveur bancaire implémentant les fonctionnalités existantes d’EBICS n’est pour l’heure pas en mesure d’exclure le scénario 2, au cours duquel un fichier ou un ordre est transmis une nouvelle fois par erreur par le biais d’un nouveau transfert et donc muni d’un ID d’ordre différent. Pour permettre une identification efficace des doubles remises au niveau des fichiers, la prochaine version d’EBICS doit être enrichie de la proposition d’amélioration EBICS-CR EB-14-08 DoubleUploadControl.

Celle-ci impose la transmission, par le logiciel client au serveur bancaire EBICS, d’une valeur de hachage afférente au fichier. Cette valeur de hachage est de toute façon produite par le logiciel client pour générer la signature. Le serveur bancaire EBICS doit ensuite vérifier si la valeur de hachage a déjà été reçue au cours d’un laps de temps déterminé et refuser l’ordre si tel est le cas.
Une identification plus étendue des doubles remises p. ex. au niveau des transactions unitaires (scénario 1) se révèle plus compliquée et la solution passe ici toujours par des mécanismes extérieurs à EBICS. Le cas échéant, un collaborateur de la banque doit déterminer en concertation avec le client si une double remise est voulue ou non.

Grâce à l’implémentation de la proposition EBICS-CR EB-14-08 DoubleUploadControl, EBICS se voit complété et amélioré d’une nouvelle fonctionnalité aussi utile que nécessaire, qui permettra d’éviter suffisamment tôt les doubles remises erronées. Cela dit, il ne s’agit pas d’un remède universel et les applications bancaires devront continuer à effectuer des recherches de doublons plus étendues.

Michael Lembcke