De documentation SEPAmail.
- 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
- 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
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|
|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.
source Msg_List.txt, date Thu Sep 13 16:03:29 GMT+01:00 2012
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