Outils personnels

Standards:SMIRK APP1301, l'application JADE

De documentation SEPAmail.

Talk2.jpg
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.
JADEJointed Additional Data & Exchange (application SEPAmail)@SEPAMAIL

Les principes

Les messages

  • La SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail. de l'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail JADEJointed Additional Data & Exchange (application SEPAmail)
  • Le récapitulatif des messages
  • Les directives d'implémentation


Présentation de l'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail

Présentation générale

L'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail JADEJointed Additional Data & Exchange (application SEPAmail) 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èmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail. credit.activation.

Selon les règles détaillées dans cette SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail., 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, JADEJointed Additional Data & Exchange (application SEPAmail) 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 JADEJointed Additional Data & Exchange (application SEPAmail) 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 : Jade sans reponse.png

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 SEPAmailmessagerie bancaire sécurisée. 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 SEPAmailmessagerie bancaire sécurisée. 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 : Jade reponse.png

Les flux 1 et 4 peuvent être des messages SEPAmailmessagerie bancaire sécurisée. 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 IBANInternational Bank Account Number, norme ISO 13616:2003 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 QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code). 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 IBANInternational Bank Account Number, norme ISO 13616:2003 – 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'IBANInternational Bank Account Number, norme ISO 13616:2003 du bénéficiaire, mais son QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code). (champ 2.18.17). Dans ce cas, le message de réponse devra indiquer l'IBANInternational Bank Account Number, norme ISO 13616:2003 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 JADEJointed Additional Data & Exchange (application SEPAmail) décrite dans cette version de la SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail..

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'IBANInternational Bank Account Number, norme ISO 13616:2003 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 JADEJointed Additional Data & Exchange (application SEPAmail), 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 QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code)., l'accord du bénéficiaire vaut accord d'utilisation de son IBANInternational Bank Account Number, norme ISO 13616:2003 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 destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement.. 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 QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code). 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 SEPAmailmessagerie bancaire sécurisée. 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 destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement..
    • 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 IBANInternational Bank Account Number, norme ISO 13616:2003, complété par la banque du bénéficiaire si le message entrant comportait un QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code).. 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'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail JADEJointed Additional Data & Exchange (application SEPAmail) 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 JADEJointed Additional Data & Exchange (application SEPAmail) :

  • 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 JADEJointed Additional Data & Exchange (application SEPAmail)
  • 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 QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code).

Dans certains cas, le donneur d'ordre peut ne connaître que le QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code). de son bénéficiaire – s'ils ont été en relation par RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail), par exemple : le donneur d'ordre JADEJointed Additional Data & Exchange (application SEPAmail) peut être un créancierle créancier est une entité économique (secteur privé, associatif ou institutionnel), soit disposant d'un ICS au niveau SEPA, soit inscrit comme créancier SEPAmail. RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail), et devoir rembourser tout ou partie des sommes perçues à son débiteur.

Il est alors possible d'indiquer ce QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code). à la place de l'IBANInternational Bank Account Number, norme ISO 13616:2003 dans le pain.001 du message “Avis d'ordre de paiement”. La banque du bénéficiaire devra alors transmettre l'IBANInternational Bank Account Number, norme ISO 13616:2003 à 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 IBANInternational Bank Account Number, norme ISO 13616:2003 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 IBANInternational Bank Account Number, norme ISO 13616:2003 pour recevoir les fonds.

Le fonctionnement est alors le suivant :

  • si le bénéficiaire donne son accord, sa banque ajoute l'IBANInternational Bank Account Number, norme ISO 13616:2003 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'IBANInternational Bank Account Number, norme ISO 13616:2003 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