FAQ n°5

Q5.1 : RUBIS : Combien de décimales sont autorisées dans le montant à payer ?

Le montant se trouve, dans la requête RUBIS (message ActivationRequest), dans le fragment xml Amt (xpath /sem:ActivationRequest/sem:ReqCompl/sem:Request/pain013:PmtInf/pain013:CdtTrfTx/pain013:Amt/pain013:InstdAmt).
Selon le shema XML du pain013, le montant est un nombre décimal positif qui peut avoir 5 décimales au plus.
Selon la directive d'implémentation RUBIS du message ActivationRequest, le montant ne peut pas être nul.
Le montant minimum est donc 0.00001 et un message avec ce montant valide bien le schéma XML du message.

Ce nombre de décimales permet d'effectuer la conversion entres les différentes devises sans ambigüité sur la deuxième décimale. C'est la règle générale qui a été adoptée en Europe au moment du passage des monnaies nationales à l'euro. Elle parait donc adaptée à l'univers SEPAmail et à la zone SEPA en particulier.

L'EPC a précisé pour le pacs.008 puis le pain.001 une règle plus contraignante qui peut se résumer à "Format rule: The fractional part has a maximum of two digits". On retrouve cette règle par exemple pour l'échange de pain.001 entre une banque et son client (référence IG SCT Bank-Client v7.0, Instructed Amount AT-04).

Certains guides du CFONB reprennent la règle ISO (5 décimales) ou la règle EPC (2 décimales).

La question est donc bien licite pour RUBIS.

Concernant une demande de règlement, quel est le sens de payer un montant avec 5 décimales ?
Dans la plupart des usages proposés par RUBIS, cela n'a aucun sens, donc une règle d'au plus 2 décimales aurait du sens.
D'un autre côté, Rubis ne propose que la demande de règlement et non le règlement lui-même, qui est articulé par la banque de débiteur selon le contrat qu'elle a avec le débiteur. Les cas d'usage qui ont été relevés lors du passage à l'euro, peuvent toujours donc se dérouler avec RUBIS.

Il parait raisonnable donc, pour pouvoir s'articuler avec un règlement par virement et être compatible avec les règles EPC d'implémenter à minima les règles suivantes :

• un créancier DEVRAIT utiliser des montants avec au plus deux décimales s'il n'a pas besoin de conversion
• l'adhérent du débiteur DOIT arrondir à deux décimales selon les règles d'usage des arrondis dans le monde bancaire tout montant émanant d'une demande de règlement avec plus de deux décimales avant d'initier un règlement par virement (pacs.008 ou pain.001)

Q5.2 : Comment doit réagir un adhérent si une missive n'est pas adressée à un de ces clients ou l'émetteur n'est pas chez l'adhérent qui envoie la missive ?

Le cas est simple et se présente de temps à autre.
L'adhérent émetteur de la missive envoie à un adhérent une enveloppe SEPAmail correcte contenant une missive dont :

• l'expéditeur (balise Snd) n'est pas un QXBAN de l'émetteur (mauvais BIC)
• le destinataire (balise Rcv) n'est pas un QXBAN du récepteur (mauvais BIC)

La missive peut donc être acquittée puisqu'elle est valide et lue correctement.

En version 1206, le relai entre les adhérents n'est pas autorisé.

• Conséquence 1 : l'adhérent qui reçoit la missive NE DOIT PAS  la relayer.
• Conséquence 2 : L'adhérent qui a envoyé la missive NE DEVAIT PAS la relayer également.

L'acquittement est donc négatif (NAK).
Le code retour peut être utilisé; c'est 511 pour le premier cas (mauvais Snd) et 512 pour le second (mauvais Rcv)

Q5.3 : peut-on envoyer une missive d'ordre 0 ?

Le schéma XML de la missive (voir ici) décrit une balise MsvOrd comme un entier.
Par contre, la directive d'implémentation de la missive donne explicitement l'usage de cette balise : "Usage Rule : this field must be set to 1 (one) at first sending of a given missive. If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged.
Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges."

On commence à un et on incrémente de un à chaque renvoi.
On acquite une missive avec le même ordre que la missive nominale acquittée.

Que faire alors si on reçoit une missive nominale d'ordre 0 ?
On acquitte négativement (NAK) avec un code retour 584 ( Order number error).

Mais que faire pour l'ordre de la missive d'acquittement puisqu'il est dit : "Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges." ?

Quitte à être non conforme à la directive, je préconise un ordre à 1 et non 0.


De même, si l'ordre n'est pas un entier positif (par exemple un entier négatif), j'acquitterai négativement (NAK) avec un code retour 581 (XML syntax error, non conforming to schema) et un ordre 1.

Q5.4 est-on obligé de renvoyer une missive ?

L’émetteur d'une missive qui n'a pas reçu à temps un acquittement peut renvoyer une missive, selon la directive d'implémentation de la missive et la SMIRK Missive.
La première dit "If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent".
La seconde dit "Un système de renvoi d'une missive peut être implémenté.[...] l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans un temps supérieur aux minima définis pour la priorité de la missive peut renvoyer la missive avec un numéro d'ordre incrémenté ; il s'interdit de le faire avant ; il n'est pas obligé de le faire"

L’émetteur peut donc renvoyer une missive mais il n'est pas obligé de le faire; il n'est même pas obligé d'implémenter le système donc de proposer le service à son client.