Outils personnels

IG missive

De documentation SEPAmail.

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 SEPA own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmail message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPA 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 SEPAmail missive.

The missive, in the SEPAmail 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 SEPAmail 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
  • SMAPI missive, describing a kind of API between the SEPAmail-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 SEPAmail 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 SEPAmail 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
* SMAPI
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 SEPAmail 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] ++++ BIC Mandatory in interbank communication, optional otherwise
A5.1.2 [0..1] ++++ IBAN Mandatory if BIC is absent, optional if it is present

A QXBAN can be used as an usual IBAN

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 BIC for a financial establishment
an IBAN for a creditor or debtor. At least one of the following identifiers must be present.
A5.4.1 [0..1] ++++ BIC Mandatory in interbank exchanges, optional otherwise
A5.4.2 [0..1] ++++ IBAN A QXBAN can be used as an usual IBAN
A5.4.3 [0..1] ++++ PAN
A5.4.4 [0..1] ++++ BBAN
A5.4.5 [0..1] ++++ RIS2D
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 SMAPI missive for a SMAPI 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 SEPAmail-specific. Other protocolar acknowledgements may exist, related to the exchange protocol used (positive answer from a Webservice, SMTP 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 (IBAN 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 SEPAmail, 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 IBAN (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 SEPAmail 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 SEPAmail 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 SEPAmail message.

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


Ref Mult Message Element SEPAmail requirement
A8 [0..1] + MsvBdy Can be any type of SEPAmail message

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


Missive signature

The last element of the SEPAmail 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