IG missive

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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. </svnig>

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>
    ...

</svnig>

Mult	Message Element	SEPAmail requirement
[1..1]	sepamail_missive_001	First version of the missive structure

</svnig>

Missive Identification

The missive identification part contains information required for its identification and acknowledgement. It occurs in every missive. </svnig> <svnig conversion="tab" date="Wed Aug 29 16:56:20 CEST 2012" last="" repository="General" revision="195" source="Msv_Use.tab">

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.

</svnig>

Missive header

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

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

</svnig>

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 </svnig>

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).

</svnig>

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.

</svnig>

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. </svnig>

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.

</svnig>

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. </svnig> <svnig conversion="tab" date="Wed Aug 29 16:56:20 CEST 2012" last="" repository="General" revision="195" source="Msv_Body.tab">

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

</svnig>

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. </svnig>

IG missive

Introduction

Internal abstraction level

Missive Identification

Missive header

Acknowledgement element

Use of the acknowledgement missive

Service element

Missive body

Missive signature

Navigation menu

Search