Standards: SMIRK MES1102, the message in the interbank network

↓

document type: comment request

---

the message in the interbank network

---

code SMIRK MES1102
version 1.0 of July 26, 2012

Introduction and overview

The SEPAmail message is the elementary information transmitted.

In the interbank cooperative space, it is used to route a standardised information with a minimum mandatory and a scalability allowing services in the competitive space.

A message belongs to a unique ecosystem and always complies with the following rules:

• It is typed.
• It is based on information with the XML format.
• It includes information structured in accordance with its type and defined by an XML diagram.
• Any information other than the one used for proper routing is integrated in a SEPAmail message. Therefore, in the SEPAmail network, no information is transmitted outside of a message.

However, any time it is feasible in a bank application, the exchanges modelling prefers the simple and plain " Question / Answer".

The SEPAmail message is, in most cases, included in a SEPAmail Application, which is referred to by a separate SMIRK .

Principles

Non confidentiality

The message is not enciphered. But it is always included in a secure envelope (missive).

The "technical" confidentiality of the whole message exchanged is therefore not possible, regarding the bank we mean here: the bank can always see the data included in a message.

It is "functional" only by the banking secrecy and the confidentiality agreement of the Scheme with its Members.

The end to end confidentiality, regarding third parties, is always guaranteed.

Integrity

The integrity of a message is ensured by two optional mechanisms of the missive enveloping it:

• the signature of the message, which guarantees the origin but also the integrity as the signature is performed using a message condensate.
• a series of control on the whole message as the missive header.

Only the EnrollRequest message may be routed without any signature, all other messages must absolutely be signed.

Information structuration

The SEPAmail message complies with the following rules:

• It is typed (ActivationRequest, MandateAcceptanceReport ...).
• It is based on XML format information.
• It includes information structured in accordance with its type and defined by an XML diagram.

Naming of the type

?????????

Ecosystem

A message is always part of a messages ecosystem.

The ecosystem is a grouping notion that allows to gather XML diagrams.

The ecosystem is therefore different from the SEPAmail application.

Information comprehensiveness

Any information other than the one used for proper routing is included in a SEPAmail message.

There is no business information that is transmitted outside of a message in the SEPAmail network.

More generally, in the SEPAmail network, there is no information transmitted without being included in a missive.

Message validity

The message includes an expiry date, after which its information content is obsolete.

This date is defined by an absolute limit (the universal date and time).

Going beyond the date is not the only reason for the message to be obsolete. Indeed, a message may have expired following other events such as:

• the answer to the message
• a condition precedent appearing
• any other reason indicated in the message content (refer to the related IG)

The dialog "Question / Answer" at the center of the SEPAmail exchange

The SEPAmail exchange mainly allows the routing of information between two users of the network in both directions, in order to build a dialog between two users that are permanently connected.

Most of messages are created in the question/answer logic (Request/Report or Request/Reply).

The messaging service may be extended to more than two users. It may also allow other combinations than the plain pair of messages Question/Answer.

However, any time it is feasible in a bank application, the exchanges modelling prefers the simple and plain " Question / Answer".

The content

A SEPAmail message includes two parts:

• a header (mandatory),
• a body (mandatory).

The message validates the XML format sepamail_message.xml

The header

The header always includes the following elements:

• a unique message identifier (mandatory),
• a message type (mandatory),
• a reference to one or more previous messages (optional),
• an expiry date/time (optional),
• a rerouting reference (optional).

The message identifier must be unique for a pair (sender, message) in the SEPAmail message. The sender is responsible for ensuring this uniqueness.

The type of the message allows to ensure that the message is complying to a type which is defined and structured in a message family. It is a type among a list defined in the XML diagrams.

The expiry date/time has been detailed above in the principles section. It is a universal date/time. It allows to ensure, if filled in, that the information sense is obsolete. This notion enables to the sender relay to inform the sender of the possible lack of answer or to propose a service around this milestone. It also enables the receiver relay to archive the message if necessary, and not to permanently store a message in the queue of messages set as available to the receiver.

The rerouting reference allows to reroute the message toward its final readers in the receiving system if needed (phone number, postal address, person, URL...)

The body

The body of the message depends on the type of the message.

An XML diagram exists for each type of message.

The attached documents (included in the body of the message)

In SEPAmail, there is one "data" element which is used in 3 parents elements:

• an image ("Image" element),
• an attached document under the MIME meaning ("Attachment" element),
• a signature ("Signature" element).

The Image is used each time the element has to be able to be displayed on line in a man/machine interface.

The Attachment is rather used when the element has to be able to be downloaded in the man/machine interfaces.

Note: the RIS2D and the Document use the "Attachment" attached document, which is logical as the RIS2D has to be able to be downloaded.