Outils personnels

IG message

De documentation SEPAmail.

(Redirigé depuis Standards 1206:IG message)
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


This document describes the contents of the standard SEPAmail message.

Messages are used to convey information, both between creditor's bank and debtor's bank, and between banks and their customers (creditor / debtor).

Here are the messages currently defined in the SEPAmail system :

  • Four are related to the direct.debit ecosystem:
    • MandateAcceptanceReport, based on pain.012, used to acknowledge and accept a mandate created or modified by a MandateInitiationRequest message
    • MandateInitiationRequest, based on pain.009, used to create or update a mandate
    • Prenotification, describing a payment schedule, either global (annual schedule) or local (single payment)
    • RequestForCopy, used by debtor to ask for a copy of the original mandate
  • Two belong to the identification.verification ecosystem
    • VerificationRequest, to require a verification
    • VerificationReport, to reply to a request.
  • Three belong to the payment.activation ecosystem
    • PaymentActivationRequest, to require a payment
    • PaymentActivationReport, to accept or decline it
    • PaymentActivationEnroll, to accept or decline an invitation to be part of Rubis
  • Seven belong to the scheme ecosystem
    • CreditorCreationRequest
    • CreditorCreationReport
    • CreditorUpdateRequest
    • CreditorUpdateReport
    • CreditorInformationRequest
    • CreditorInformationReport
    • CreditorActivationAdvise
  • Three belong to the secure ecosystem:
    • EnrollRequest, to submit a certificate for use in the SEPAmail system
    • EnrollReport, to accept or reject a certificate
    • EnrollAdvise, for inter-partner certificate notification
  • Two belong to the test ecosystem
    • SimpleTestRequest, used to test communication, protocol compliancy ...
    • SimpleTestReport, its reply

Each of these messages is described in a separate document. However, they are all held in a standard Message element, which we will describe hereafter.

source Msg_Intro_1206.txt, date Thu Sep 13 16:03:29 GMT+01:00 2012

Internal abstraction level

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

The actual contents of the Message element must be any one of the sepamail_message_xxx structures.

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

Note that the version of the message is not necessarily the same as the version of the missive.

source Msg_Abstract.txt, date Thu Sep 13 16:03:29 GMT+01:00 2012

Mult Message Element SEPAmail requirement
[1..1] sepamail_message_001 First version of the message structure

source Msg_Abstract.tab, date Thu Sep 13 16:03:29 GMT+01:00 2012

Message Header

The message header contains information required for the processing of the entire message.

source Msg_Header.txt, date Thu Sep 13 16:03:29 GMT+01:00 2012

Ref Mult Message Element SEPAmail requirement
A [1..1] ++ MsgHdr
A1 [1..1] +++ MsgId This identifier should be equal to the missive identifier (MsvId element, see related doc.), followed by an underscore ('_') and by a number, which must be unique in a given missive. In any case, the message identifier MUST be unique for a given sender.
A2 [1..1] +++ MsgTyp The general form is “message@ecosystem”. See table below for allowed values.
A3 [0..n] +++ MsgRedir Redirections for the message. These redirections may be implemented by the receiving part, and can take one of the following forms
A3.1 [0..1] ++++ InternalReference Can be a phone number, an office identifier ...
A3.2 [0..1] ++++ RedirectURI Can be a mail address, a Web page or Web service ...
A4 [0..n] +++ MsgRef This element indicates previous messages, which are somehow or other in relation with the current one.
A4.1 [1..1] ++++ MsgId The identifier of the related message
A4.2 [1..1] ++++ Relation A string describing the relation. Currently, this string is free-form, but it could for example be "invoice", "mandate" ...
A5 [0..1] +++ MsgExpiry An ISO date and time at which the message is no longer relevant, and can be deleted by all actors. Possible actions taken at that time depend on the ecosystem and on the relation between the bank and its customer.

source Msg_Header.tab, date Thu Sep 13 16:03:29 GMT+01:00 2012

List of known message types

Here are, in alphabetical order, all currently known messages, along with their associated message types (A2 - MsgTyp) element.

Ecosystem Message MsgTyp
direct.debit MandateInitiationRequest mandate.request@direct.debit
MandateAcceptanceReport mandate.report@direct.debit
Prenotification notification@direct.debit
RequestForCopy request.copy@direct.debit
identification.verification VerificationReport report@identification.verification
VerificationRequest request@identification.verification
payment.activation PaymentActivationEnroll activation.enroll@payment.activation
PaymentActivationReport activation.report@payment.activation
PaymentActivationRequest activation.request@payment.activation
scheme CreditorActivationAdvise activation.advise@scheme
CreditorCreationReport creation.report@scheme
CreditorCreationRequest creation.request@scheme
CreditorInformationReport information.report@scheme
CreditorInformationRequest information.request@scheme
CreditorUpdateReport update.report@scheme
CreditorUpdateRequest update.request@scheme
secure EnrollAdvise enroll.advise@secure
EnrollReport enroll.report@secure
EnrollRequest enroll.request@secure
test SimpleTestReport simple.report@test
SimpleTestRequest simple.request@test

source Msg_List.txt, date Thu Sep 13 16:03:29 GMT+01:00 2012

Message Body

The message body depends on the type of message, as defined in the MsgTyp element. At this level, it contains only one element.

source Msg_Body.txt, date Thu Sep 13 16:03:29 GMT+01:00 2012

Ref Mult Message Element SEPAmail requirement
B [1..1] ++ MsgBdy Can be any of the messages belonging to the SEPAmail system : payment.activation_ActivationRequest, direct.debit_MAndateAcceptanceReport ...

source Msg_Body.tab, date Thu Sep 13 16:03:29 GMT+01:00 2012