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

Introduction

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

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

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

</svnig>

Message Header

The message header contains information required for the processing of the entire message. </svnig>

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.

</svnig>

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
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
test	SimpleTestRequest	simple.request@test

</svnig>

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

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

</svnig>

IG message

Introduction

Internal abstraction level

Message Header

List of known message types

Message Body

Navigation menu

Search