Standards:SMIRK APP1301, l'application JADE

Cette page est à l'état de discussion.

Elle n'a donc aucune valeur normative, et pourrait même disparaître du périmètre de SEPAmail.

Si vous voulez contribuer, utilisez la page de discussion SVP. Consultez également les autres pages en discussion.

Présentation de l'application

Présentation générale

L'application JADE a pour objet l'émission d'un avis d'ordre de paiement, de donneur d'ordre à bénéficiaire, et éventuellement la réponse à cet avis. Elle utilise les messages de l'écosystème credit.activation.

Selon les règles détaillées dans cette SMIRK, et les accords entre la banque et son client donneur d'ordre, le message d'avis d'ordre de paiement peut déclencher directement un paiement.

À cette fin, les messages de credit.activation sont fondés sur le pain.001 de l'ISO 20022, CustomerCreditTransferInitiation. Ainsi, le déclenchement d'un paiement pourra se faire en réutilisant directement le message inclus, ou du moins l'essentiel de ses champs.

Dans la situation actuelle, JADE est orientée vers les virements. Toutefois, rien n'empêche d'utiliser les mêmes messages pour déclencher des paiements par d'autres moyens (chèque ou lettre-chèque, carte bancaire ...)

Deux formes d'utilisation de JADE peuvent être distinguées :

• sans réponse
• avec réponse obligatoire

Les utilisations détaillées possibles sont décrites dans cette page.

Usage sans réponse

Si le donneur d'ordre n'attend pas de réponse de son bénéficiaire – cas d'un virement de salaire par exemple –, le message de réponse est interdit. Dans ce cas, si les accords avec sa banque le prévoient, le message d'avis d'ordre de paiement peut valoir instruction à sa banque de procéder au paiement décrit par le pain.001 inclus.

Il faut noter que la date d'exécution demandée dans ce pain.001 (2.7, ReqdExctnDate) peut être positionnée au choix du donneur d'ordre, de façon par exemple à ne déclencher le paiement que quelques jours après l'envoi du message d'avis de paiement (fin du mois pour un salaire, par exemple).

Dans ce cas d'usage, les échanges de données sont les suivants :

Le flux 1 peut consister en un message CreditAdvise complet, ou en toute autre transmission de données convenue entre le donneur d'ordre et sa banque.

Le délai entre émission du paiement et envoi du message SEPAmail est variable, et l'ordre de ces deux évènements n'est pas fixé par la norme. Voir cette page pour les différents cas d'usage.

Usage avec réponse obligatoire

Dans certains cas, le donneur d'ordre a impérativement besoin d'une réponse de son bénéficiaire : solde de tout compte, renonciation à recours ... Une réponse positive devient alors une condition nécessaire à l'éventuelle émission d'un paiement.

La réponse demandée peut être de deux types :

• authentification seule : dans ce cas, le fait que le bénéficiaire soit identifié par sa banque et que les messages transitent par SEPAmail suffit au donneur d'ordre.
• scellement : dans ce cas, la banque du bénéficiaire devra produire une signature numérique associée au bénéficiaire, afin que le donneur d'ordre puisse conserver le message retour à titre de preuve.

Si la banque du bénéficiaire ne gère pas la forme de réponse demandée, elle doit répondre par un message “Réponse à avis d'ordre de paiement” technique, c'est-à-dire ne comportant que le champ Status, avec la valeur "unavailable". Ceci est fonctionnellement équivalent à une réponse négative, c'est-à-dire que le paiement ne peut pas avoir lieu. Le donneur d'ordre peut alors, soit demander une autre forme de réponse, soit utiliser un autre moyen de paiement et/ou de communication.

Dans tous les cas, si le bénéficiaire ne répond pas, ou répond négativement, le paiement ne peut en aucun cas être émis. L'initiative revient dans les mains du donneur d'ordre.

Si le bénéficiaire répond positivement, le paiement peut être émis, soumis aux mêmes conditions que dans l'usage sans réponse obligatoire, sur la date d'exécution par exemple. Cette date est dans ce cas considérée comme un minimum : si une réponse positive parvient après cette date, le paiement sera émis lors de la réception de cette réponse.

Voici un schéma récapitulant les échanges dans ce cas d'usage :

Les flux 1 et 4 peuvent être des messages SEPAmail complets, ou tout autre échange de données convenu entre la banque et son client.

Pour limiter dans le temps la possibilité d'émission d'un paiement, le donneur d'ordre doit utiliser le champ prévu à cet effet dans le message d'avis (ExpirationDate).

Le message d'avis d'ordre de paiement

1. Utilisation

Le message d'avis d'ordre de paiement a plusieurs objets :

1. indiquer au bénéficiaire les éléments de l'ordre de paiement : nature, montant, raison
2. lui demander un accord formel sur les conditions de cet ordre de paiement
3. éventuellement, lui demander un accord sur l'utilisation de son IBAN pour ce paiement
4. si les conditions sont réunies, déclencher automatiquement le paiement

Le point 1 est inhérent au message lui-même.

Le point 2 est activé à l'initiative du donneur d'ordre : c'est lui qui indique si un accord du bénéficiaire est nécessaire, en renseignant au moins un élément ExpAgrmt (B4, ExpectedAgreement). Si un ou plusieurs tels éléments sont présents, l'accord du bénéficiaire devient une condition nécessaire à l'éventuelle émission d'un paiement.

Le point 3 est lié au point 2 et à la présence d'un QXBAN dans le pain.001 (cf ci-dessous. Pour accepter le paiement, le bénéficiaire devra non seulement accepter les conditions demandées par le donneur d'ordre, mais aussi l'utilisation de son IBAN – qui ne sera bien entendu pas montré au donneur d'ordre.

Le point 4, enfin, est lié au contrat existant entre le donneur d'ordre et sa banque. Ce contrat devra notamment préciser les conditions et dates d'émission d'un paiement.

2. Contenu

Le message d'avis d'ordre de paiement comporte deux parties :

• l'ordre de paiement à proprement parler, contenu dans un message pain.001 de l'ISO 20022.
• des éléments complémentaires dans une partie non-ISO :
  • une date d'expiration, au-delà de laquelle le paiement ne sera en aucun cas émis. Cette date est obligatoire si une réponse est demandée.
  • un nom et un logo qui seront affichés au bénéficiaire, si le canal le permet
  • un ou plusieurs documents justifiant ou explicitant le paiement concerné
  • dans le cas où une réponse est attendue, la description précise de cette réponse :
    • type de réponse (authentification ou scellement)
    • documents relatifs à la réponse
    • libellé exact de la réponse

Le pain.001 figurant dans ce message peut être de l'une quelconque des versions actuellement acceptées par ISO 20022, c'est-à-dire 2 à 5.

Pour faciliter l'usage de ce message, le pain.001 peut contenir, non l'IBAN du bénéficiaire, mais son QXBAN (champ 2.18.17). Dans ce cas, le message de réponse devra indiquer l'IBAN réel du bénéficiaire, afin que le virement puisse être réalisé. Les détails sont décrits ci-dessous.

Rappelons que, dans l'optique actuelle, une réponse affirmative implique l'accord du bénéficiaire, et, si elle est demandée par le donneur d'ordre, elle est absolument nécessaire à l'éventuelle émission de l'ordre de paiement.

On pourrait imaginer des cas d'usage où une réponse déclencherait d'autres traitements (soupçons de fraude, par exemple). Ces cas ne sont pas inclus dans la version de JADE décrite dans cette version de la SMIRK.

3. Présentation au bénéficiaire

Dans tous les cas, mais plus particulièrement si une réponse est demandée, la banque du bénéficiaire doit présenter au bénéficiaire tous les éléments lui permettant d'apprécier exactement le paiement proposé et les conditions attachées. Ceci comporte au minimum :

• l'identité du donneur d'ordre
• les conditions du paiement (montant, date d'exécution demandée ...)
• toute la partie non-ISO et notamment :
  • tous les documents joints
  • le libellé exact de l'accord demandé
  • la date limite de réponse de sa part

En revanche, l'IBAN du donneur d'ordre NE DOIT PAS être transmis au bénéficiaire.

Le message de réponse à avis d'ordre de paiement

1. Utilisation

Le message de réponse à avis d'ordre de paiement n'a, dans la conception actuelle de JADE, qu'une seule utilité : transmettre l'accord ou le désaccord du bénéficiaire sur les documents et conditions proposés par le donneur d'ordre dans le message “Avis d'ordre de paiement”. Il ne peut donc intervenir qu'en réponse à un message “Avis d'ordre de paiement”, et à la condition que celui-ci demande une réponse.

Il doit être expédié à l'initiative du bénéficiaire, par lui-même ou sa banque.

La réponse positive du bénéficiaire vaut acceptation contractuelle des conditions proposées par le donneur d'ordre, ou confirmation si un contrat avait déjà été signé.

Inversement, la réponse négative vaut refus explicite de ces conditions. Dans tous les cas, le bénéficiaire peut également ajouter un message libre, par exemple des remarques ou une justification de sa décision. Par rapport à l'absence de réponse, elle permet non seulement d'expliciter la position du bénéficiaire, mais de plus d'accélérer le traitement de la transaction puisque le donneur d'ordre n'est pas obligé d'attendre la date d'expiration de son message originel.

Rappel : si le message entrant comportait un QXBAN, l'accord du bénéficiaire vaut accord d'utilisation de son IBAN pour le paiement. Ce point doit être précisé clairement au bénéficiaire lorsque le message lui est présenté.

2. Réponse "technique"

Dans certains cas, la banque du bénéficiaire ne peut pas présenter le message à son destinataire. Elle doit dans ce cas répondre par un message “Réponse à avis d'ordre de paiement” dit "technique", c'est-à-dire dont la partie Complement ne comporte qu'un seul champ : Status. Ce champ peut alors valoir :

• unknown si un QXBAN est fourni, et qu'il ne correspond pas à un compte pouvant recevoir des virements
• unavailable si la forme de réponse demandée n'est pas disponible – par exemple si le donneur d'ordre demande un scellement et que la banque ne sait pas le fournir.

Cette réponse, qui ne peut bien entendu se produire qu'en mode "réponse obligatoire", clôture la transaction, et ne doit en aucun cas donner lieu à l'émission d'un paiement.

3. Contenu

Le message “Réponse à avis d'ordre de paiement” comporte trois parties, obligatoires sauf cas particulier :

• un message pain.001, tel qu'il apparaissait dans le message d'avis. Ceci permet aux messages SEPAmail de rester autoporteurs, et valide le fait que le bénéficiaire ait effectivement pris connaissance des conditions de l'ordre de paiement. Puisqu'il est la recopie de celui du message entrant, le pain.001 peut être de l'une quelconque des versions supportées par ISO 20022 (de 2 à 5 inclus)
• une partie non-ISO de compléments, comportant :
  • obligatoirement un état, précisant notamment si la réponse est d'ordre "humaine", à l'initiative du bénéficiaire, ou "technique", à l'initiative de sa banque. Les valeurs autorisées sont "accepted" ou "rejected" si le bénéficiaire a fait connaître sa décision, et "unknown" et "unavailable" si le message d'origine n'a pas pu être présenté au destinataire.
  • sauf dans le cas d'une réponse "technique", la réponse du bénéficiaire. Elle doit alors être recopiée du message d'avis et complétée par l'indication "accepté" ou "refusé".
  • un IBAN, complété par la banque du bénéficiaire si le message entrant comportait un QXBAN. Voir ci-dessous pour les détails de l'utilisation de ce champ.
  • des commentaires facultatifs, sous forme de texte libre, qui devront être transmis au donneur d'ordre.
• une signature du bénéficiaire, obligatoire si le donneur d'ordre demandait un scellement, permettant au donneur d'ordre d'obtenir une preuve certaine de l'accord du bénéficiaire. La signature doit porter sur les deux éléments ci-dessus (pain.001 et compléments), puisque l'accord du bénéficiaire porte à la fois sur l'ordre de paiement et sur les conditions attachées.

Articulation éventuelle d'un paiement

Rappelons que nous parlons de façon générique de paiement, même si pour l'instant l'application JADE est essentiellement orientée vers les virements.

Règles gouvernant cette articulation

Trois règles doivent s'appliquent pour l'articulation éventuelle d'un paiement autour des messages JADE :

• il doit exister un contrat entre le donneur d'ordre et sa banque, précisant notamment les conditions d'émission du paiement (type, date, coût ...), et mentionnant explicitement l'automatisation des paiements associés au flux JADE
• le paiement doit respecter la date minimum indiquée dans le pain.001 (2.7, ReqdExctnDate)
• si le message “Avis d'ordre de paiement” a été envoyé avec réponse obligatoire, une réponse positive doit avoir été reçue avant la date d'expiration précisée dans le message entrant (ExpirationDate).

La réception tardive de la réponse peut entraîner une émission du paiement postérieure à la date d'exécution figurant dans le pain.001.

La banque du donneur d'ordre doit impérativement respecter la date d'expiration précisée dans le message “Avis d'ordre de paiement”, et ne pas émettre de paiement après cette date. En effet, en l'absence de réponse à cette date, le donneur d'ordre peut avoir utilisé un autre canal entre temps, et ceci provoquerait alors un double paiement.

Utilisation du QXBAN

Dans certains cas, le donneur d'ordre peut ne connaître que le QXBAN de son bénéficiaire – s'ils ont été en relation par RUBIS, par exemple : le donneur d'ordre JADE peut être un créancier RUBIS, et devoir rembourser tout ou partie des sommes perçues à son débiteur.

Il est alors possible d'indiquer ce QXBAN à la place de l'IBAN dans le pain.001 du message “Avis d'ordre de paiement”. La banque du bénéficiaire devra alors transmettre l'IBAN à la banque du donneur d'ordre, afin qu'elle puisse le substituer dans le pain.001 et procéder au paiement. Bien évidemment, la banque du donneur d'ordre ne transmet en aucun cas cet IBAN au donneur d'ordre lui-même.

Dans ce cas, la réponse est toujours obligatoire, le bénéficiaire devant donner explicitement son accord à l'utilisation de son IBAN pour recevoir les fonds.

Le fonctionnement est alors le suivant :

• si le bénéficiaire donne son accord, sa banque ajoute l'IBAN dans le message “Réponse à avis d'ordre de paiement” avant de le transmettre à la banque du donneur d'ordre.
• s'il le refuse, l'IBAN ne doit en aucun cas figurer dans le message de réponse.

Récapitulatif des messages et éléments techniques

Nom du message	Schéma	Implementation Guidelines
CreditTransferAdvise	Fichier:Sepamail message credit.activation CreditTransferAdvise.xsd	Standards:IG_Jade_CreditTransferAdvise
CreditTransferReply	Fichier:Sepamail message credit.activation CreditTransferReply.xsd	Standards:IG_Jade_CreditTransferReply
types communs	Fichier:Type sepamail credit.xsd	N/A

---