Outils personnels

IG missive

De documentation SEPAmail.

(Redirigé depuis Standards:IG missive)
SEPAmail – Norme 1206

Cette page fait partie de la version 1206 de la norme.

Sauf indication contraire, elle a été validée par les instances concernées et s'impose à tous les adhérents SEPAmail.
ATTENTION ! La version 1606 de la norme est disponible, vérifiez si cette page est toujours valable.

  • These implementation rules shall be applied in accordance with ISO20022 and SEPASingle Euro Payments Area est un espace européen à l’intérieur duquel les entités économiques peuvent effectuer des paiements en euros avec la même facilité, la même sécurité et les mêmes conditions que pour un paiement national. own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmailmessagerie bancaire sécurisée. message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPASingle Euro Payments Area est un espace européen à l’intérieur duquel les entités économiques peuvent effectuer des paiements en euros avec la même facilité, la même sécurité et les mêmes conditions que pour un paiement national. messages.
  • for an explanation of the color coding used in the tables below, see this page
  • for general rules applying to all fields, see this page
  • for business rules directing these IG, see this page

Introduction

This document describes the contents of the SEPAmailmessagerie bancaire sécurisée. missive.

The missive, in the SEPAmailmessagerie bancaire sécurisée. system, is the general-purpose envelope used to dispatch all kinds of contents, independently of the Exchange Mechanism used.

There are four types of missives :

  • Nominal missive, used to convey a payload -- generally a SEPAmailmessagerie bancaire sécurisée. message
  • Acknowlegdement missive, strictly protocol-based, used to indicate proper delivery and understanding of a nominal missive.
  • Service missive, supporting a request-response dialog between parties
  • SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. missive, describing a kind of API between the SEPAmailmessagerie bancaire sécurisée.-supporting plug-in and the internal Information System

This document describes the elements for all kinds of missives.

source Msv_Intro.txt, date Wed Aug 29 16:56:20 CEST 2012


Internal abstraction level

To facilitate upgrades, an abstraction level has been inserted at the root of this element.

The actual contents of the Missive element must be any one of the sepamail_missive_xxx structures.

In addition to this contents, the Missive element has a mandatory attribute called "version", describing the version of the Implementation Guidelines used to construct this missive. This attribute, mandatory since 1206 version, must start with 4 integers, such as "1206" for June 2012 version. A free string, up to 10 chars, may follow these 4 integers.

Only the four first characters are relevant in order to check the version number of a given missive.

For example, the beginning of a missive element could be :

<sem:Missive version="1206_vanilla">
  <MsvId>
    ...

source Msv_Abstract.txt, date Tue Jul 24 21:09:00 CEST 2012


Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
[1..1] sepamail_missive_001 First version of the missive structure

source Msv_Abstract.tab, date Wed Aug 29 16:56:20 CEST 2012


Missive Identification

The missive identification part contains information required for its identification and acknowledgement. It occurs in every missive.

source Msv_Use.txt, date Thu Dec 01 13:02:17 CET 2011


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
A1 [1..1] ++ MsvId Usage Rule The format of this identifier is YYYYMMDDhhmmssxxx + "_" + sender_id
The first part is the creation date and time, including milliseconds
The second part can be used freely by the sender.
The absolute constraint is that a missive identifier MUST be unique for a given sender, except for acknowledgement missives. Thus, if more than one missive is created with the same date-time stamp, it is the sender's responsibility to make sure the "sender_id" part is different for each missive.
For an acknowledgement missive, the identifier must be the one of the missive it acknowledges.
A2 [1..1] ++ MsvTyp The only possible values are
* Nominal
* Acquittement or Acknowledgement
* Service
* SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration.
A3 [1..1] ++ MsvOrd Ordinal number of the missive. 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.
A4 [0..1] ++ MsvPri Priority of the missive. The possible values are "HIGHEST", "HIGH", "NORMAL", "LOW" and "LOWEST". Default value is "NORMAL". If the receiver cannot handle the missive at the requested priority, he must notify it by using a RoutingWarning element (A6.7) in the acknowledgement missive.

source Msv_Use.tab, date Wed Aug 29 16:56:20 CEST 2012


Missive header

The header contains elements about the routing of the missive. It is mandatory in every missive, regardless of its type.

source Msv_Header.txt, date Thu Mar 29 18:43:58 CEST 2012


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
A5 [1..1] ++ MsvHdr
A5.1 [1..1] +++ Snd Sender. Usage rule: the sender can be identified by one or several of the following identifiers:
A5.1.1 [0..1] ++++ BICBank Identifier Code, norme ISO 9362:1994 Mandatory in interbank communication, optional otherwise
A5.1.2 [0..1] ++++ IBANInternational Bank Account Number, norme ISO 13616:2003 Mandatory if BICBank Identifier Code, norme ISO 9362:1994 is absent, optional if it is present

A 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). can be used as an usual IBANInternational Bank Account Number, norme ISO 13616:2003

A5.2 [1..1] +++ SndDtTm Date and time of initial creation by sender, in ISO format
A5.3 [0..1] +++ SndChk Sender-managed checksum. Usage Rule: this attribute can be used by the sender to include a checksum on the missive header, which MUST be sent back by the matching acknowledgement missive. Its content is fully ignored by SEPAmail.
A5.4 [1..1] +++ Rcv Receiver. Usage rule: the receiver can be identified by one or several of the following identifiers:
a BICBank Identifier Code, norme ISO 9362:1994 for a financial establishment
an IBANInternational Bank Account Number, norme ISO 13616:2003 for a creditor or debtor. At least one of the following identifiers must be present.
A5.4.1 [0..1] ++++ BICBank Identifier Code, norme ISO 9362:1994 Mandatory in interbank exchanges, optional otherwise
A5.4.2 [0..1] ++++ IBANInternational Bank Account Number, norme ISO 13616:2003 A 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). can be used as an usual IBANInternational Bank Account Number, norme ISO 13616:2003
A5.4.3 [0..1] ++++ PANacronyme de Primary Account Number ou numéro de carte bancaire
A5.4.4 [0..1] ++++ BBANBasic Bank Account Number, identifiant plus ou moins équivalent à un numéro de compte bancaire<ref>http://fr.wikipedia.org/wiki/BBAN</ref>
A5.4.5 [0..1] ++++ RIS2Dun RIS2D (Relevé d'Identité SEPAmail 2D) est une image de type code barre 2D au format datamatrix, contenant des données propres à l'utilisateur de SEPAmail : nom, prénom, BIC, identifiant QXBAN, date d'expiration
A5.5 [0..1] +++ RcvDtTm Date and time of reception, in ISO format

source Msv_Header.tab, date Wed Jan 16 10:42:15 CET 2013


Acknowledgement element

This part of the missive appears only in acknowledgement missives, in which it is mandatory. It contains detailed information about the delivery of the related nominal missive

source Msv_Ack.txt, date Thu Dec 01 13:02:17 CET 2011


Use of the acknowledgement missive

It must be reminded that an acknowledgement missive is used only after a nominal missive has been sent. A service missive is used to reply to a service missive, and a SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. missive for a SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. missive.

Only nominal missives must be acknowledged.

Generally, the missive identifier and rank, in the missive header, must match exactly those of the nominal missive it acknowledges.

If a missive has been sent several times, with different rank numbers thus, the acknowledgement of a given rank implies the non-acknowledgement of all lower ranks, except in special cases (detailed non-acknowledgement already sent, for instance).

This acknowledgement is internal and SEPAmailmessagerie bancaire sécurisée.-specific. Other protocolar acknowledgements may exist, related to the exchange protocol used (positive answer from a Webservice, SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») acknowledgement ...) but those mechanisms can in no case replace the acknowledgement missive.

Reciprocally, an acknowledgement missive is only used to transmit information about the routing of a nominal missive, or about the sender or recipient addresses. However, all functional changes (IBANInternational Bank Account Number, norme ISO 13616:2003 modification request, change of status for a mandate ...) MUST NOT be sent via an acknowledgement missive. The proper message MUST be used, sent via a nominal missive.

Finally, it must be reminded that several acknowledgement missives MAY be related to the same nominal missive, ie have the same missive identifier and rank. For instance, one could have three successive acknowledgements :

  • the first one indicates proper reception of the missive (ACK without code)
  • the second one indicates that the recipient is part of SEPAmailmessagerie bancaire sécurisée., and that the message has been forwarded (ACK, code 2.1.9)
  • the third one indicates that the debtor's bank has validated his/her IBANInternational Bank Account Number, norme ISO 13616:2003 (ACK, code 2.4.9).

source Msv_Ack_Use.txt, date Tue Jul 24 16:16:58 CEST 2012


A full list of allowed return codes is available here


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
A6 [0..1] + MsvAcq
A6.1 [1..1] ++ AcqSta Status. Possible values are ACK or NAK.
A6.2 [0..1] ++ AcqCla Class of status. See business rules document for meaning of the values of this field.
A6.3 [0..1] ++ AcqSub Subject of status. See business rules document for meaning of the values of this field
A6.4 [0..1] ++ AcqDet Detail of status. See business rules document for meaning of the values of this field
A6.5 [0..1] ++ AcqChk Checksum of the acknowledgement. Currently unused.
A6.6 [0..1] ++ AcqDes Description. If present, this field MUST contain a human-readable explanation of the status, whether the acknowledgement is positive or negative.
A6.7 [0..n] ++ RtgWarn Specific routing-related information
A6.7.1 [1..1] +++ Code Nature of the information. Allowed values are
BAD_TIME: sending time is slightly incorrect
PRIO_HIGH: missive will be handled with "HIGH" priority only
PRIO_NORM: missive will be handled with "NORMAL" priority only
PRIO_LOW: missive will be handled with "LOW" priority only
PRIO_XLOW: missive will be handled with "LOWEST" priority only
A6.7.2 [0..1] +++ Descr Human-readable explanation and details.

source Msv_Ack.tab, date Wed Aug 29 16:56:20 CEST 2012


Service element

This part of the missive appears only in service missives, in which it is mandatory. It contains the protocol elements for information exchange between both parties.

source Msv_Service.txt, date Wed Dec 07 18:13:51 CET 2011


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
A7 [0..1] + MsvSrv
A7.1 [0..1] ++ SrvCmd Command element, only used in command service missives
A7.1.1 [1..1] +++ CmdTyp Command Type. Usage Rule: possible values are DELE, LIST, NOOP, RETR and STAT.
A7.1.2 [0..1] +++ CmdNum Message Number. For DELE and RETR commands, must hold the number of the message to delete or retrieve ; for LIST command, may contain a message number.
A7.1.3 [0..1] +++ CmdSlc Message selection. If this attribute is present and has a "true" value, all messages on server will be included in the command scope. In all other cases, only unread messages are in the scope.
A7.1.4 [0..n] +++ CmdFlt Filter expressions. This attribute must hold a valid Xpath2 expression.
A7.2 [0..1] ++ SrvRes Response element, only used in response service missives
A7.2.1 [1..1] +++ ResTyp Type of response. Possible values are +OK (positive response) and -ERR (negative response).
A7.2.2 [0..1] +++ ResNum Message number
A7.2.3 [0..1] +++ ResSize Message size
A7.3 [0..1] ++ SrvInfo Additional service information. Usage Rule: in a response to LIST or STAT command, this string will hold the required information.

source Msv_Service.tab, date Wed Aug 29 16:56:20 CEST 2012


Missive body

This part of the missive appears only in nominal missives, in which it is mandatory. It contains the actual payload of the missive, which can currently only be a SEPAmailmessagerie bancaire sécurisée. message.

source Msv_Body.txt, date Wed Aug 29 16:56:20 CEST 2012


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
A8 [0..1] + MsvBdy Can be any type of SEPAmailmessagerie bancaire sécurisée. message

source Msv_Body.tab, date Wed Aug 29 16:56:20 CEST 2012


Missive signature

The last element of the SEPAmailmessagerie bancaire sécurisée. missive is a signature, conforming to the XML DSig schema.

This element is not mandatory. It is even currently useless since in the current structure, the missive payload is always clear, and contains an internal signature.

However, in future releases, the payload might become crypted, and this element could then be used by the sender to authenticate the origin of the missive.

source Msv_Signature.txt, date Wed Aug 29 16:56:20 CEST 2012