Exchange Mechanisms

From documentation SEPAmail
Jump to navigation Jump to search
This page is a translated version of the page Les mécanismes d'échange and the translation is 100% complete.
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.

Messaging service

Les messages

Les applications

Presentation and principles

Les missives

The messages

The applications

Information about exchanges

As originally defined, SEPAmail was only intended to manage an interbank interface, i.e. the flows exchanged between banks.

In practice, a bank may use either the SEPAmail protocol or the SEPAmail structure (missive), or both, in its exchanges with its own customers (customer interface). More generally, a bank can also use the SEPAmail standards internally (intrabank interface).

Three exchange mechanisms have been defined: electronic mail, Web service and files.

Among these available exchange mechanisms, only the email channel is mandatory and must be supported by all SEPAmail members in an interbank mode. The interbank exchange mechanism based on Web services is optional, even though it has been implemented in the testing phase.

In addition, in terms of architecture SEPAmail is an asynchronous system. As a result, the transmission of messages cannot be subject to any absolute commitment regarding the transmission time. The transmission times related to the priority levels of the missives must therefore be considered in light of the channel which is used. For example, a missive whose priority level is HIGHEST, and which is sent by email, is very likely not be acknowledged within the time frame associated with this priority level.

A third mechanism (file exchange) was defined during the testing phase, initially for intrabank purposes. It is NEVER used for interbank purposes. It may be used for the customer interface or the intrabank interface.

The present description of the exchange mechanisms is essentially functional and provides few technical details. To view the complete technical specifications, which in particular examine the issue of addressing, click here.

Electronic Mail

Principle

The exchange mechanism based on electronic mail was the first to be implemented and SEPAmail in fact takes its name from it. The principle is simple: all data is transmitted like email messages.

The content of the email must therefore comply with RFC 3851[1] . The body of the email must be a SEPAmail missive, appearing as an attachment in an S/MIME format (RFC 5321[2]).

The sender and receiver of the email are required to have the following structure: <ecosystem>@<bic>.sepamail.eu

<ecosystem> refers to a group of transmitted messages.

Five ecosystems are currently supported:

  • direct.debit, which is used by the GEMME application
  • payment.activation, which creates electronic credit transfers and which is used by the RUBIS application
  • identification.verification, which is used to verify banking identifiers in relation to the DIAMOND application
  • secure, which is used to exchange security elements (certificates or messages) between all the players in the SEPAmail system
  • test, which, as its name indicates, is used for configuration and/or communication tests.


<bic> is the sender’s (or recipient’s) BIC. In the case of an interbank exchange, both addresses must contain this BIC. In the case of an exchange between a customer and a bank, the sender’s address may contain an IBAN instead of a BIC.

The messages must first be signed by using the private key of the sender’s signature. They are then encrypted using the recipient’s encryption public key.

The IP addresses of the mail servers, as well as the certificates used for the encryption and signature of the messages, must be registered beforehand with the SEPAmail Scheme.

Use of the Electronic Mail Channel

In addition to the use of fixed and pre-registered IP addresses for message routing, the messages transmitted via this channel comply with normal email rules. It is therefore the sender’s responsibility to ensure the proper transmission of the messages it sends: error or non-delivery notifications are transmitted via the standard channel between MTAs, and in this case the sender is responsible for the possible re-transmission.

constitution de l'enveloppe SEPAmail échangée dans le cas du courrier électronique ou du service WEB

Web Service

Principle

This exchange mechanism was originally designed to allow the sender to manage its messages in a more synchronous and more direct manner than electronic mail.

In the present state of the system, it is deployed for exchanges between banks (interbank connector) and for exchanges between firms and their banks (firm connector).

The basic principle of the Web service is similar to that of electronic mail: the transmitted message has a basic header and a body in compliance with the S/MIME format. It contains a SEPAmail missive and is signed and then encrypted.

In both the header and missive, the sender’s identifier may be any email address – managed by the creditor – but must correspond exactly to the certificate used to encrypt the message. If this is not the case, the transmission will be rejected. The recipient, on the other hand, has the same structure as the email channel: <ecosystem>@BIC.sepamail.eu. In this case the BIC refers to the creditor’s bank.

The connection to the Web service is established via the HTTP protocol which means that the link is not encrypted. Binary data is encoded via the MTOM protocol. As with all exchange mechanisms which can be connected to an outside environment, messages must be signed by using the sender’s private signature key and also encrypted by using the recipient’s public encryption key. All types of missives may be included in a WebService message.

This provides firms using this channel with a range of different possibilities:

  • sending new elements (e.g. money orders, notifications) to SEPAmail by using nominal missives
  • connecting to the Web service to manage received messages (e.g. acknowledgements, change in account references) by using service missives
  • in future versions, changing a firm’s details or relationship with the SEPAmail system

In any case, the Web service is only designed to operate in “pull” mode, i.e. a customer must take the initiative of establishing a link with the Web service in order to communicate.

Use of the Web service

In the context of an intrabank situation (especially the communication between the creditor and the creditor’s bank), the use of a service missive via the Web service may completely replace the SMTP connection. In this case, the SEPAmail acts as the mail server for its customers even though this is not its fundamental role.

In the context of an intrabank situation (especially the communication between the creditor and the creditor’s bank), the use of a service missive via the Web service may completely replace the SMTP connection. In this case, the SEPAmail acts as the mail server for its customers even though this is not its fundamental role. In this situation, it is therefore the full and complete responsibility of the firm or creditor to:

  • Establish a connection at sufficiently frequent intervals in order to receive new messages.
  • Properly manage a possible time-out by the server
  • Process its messages even though SEPAmail only provides storage and does not provide processing services, except for data related directly to the SEPAmail system, e.g. the status of money orders in the internal database.
  • Manage the messages present in the server, especially by deleting those messages which are no longer useful. This is to simplify the management of the remaining messages both by reducing their number and by limiting the space occupied in the SEPAmail servers, whose role is not to process messages.

It should be noted that archiving is provided internally by SEPAmail. Deleting a message through the Web service means that it is no longer accessible through this same channel. However, it is not completely destroyed in the SEPAmail data.

Exchange Mechanism
Exchange Mechanism

File Exchange

Principle

This third type of exchange mechanism is designed to be used exclusively with a bank’s internal interface, especially as the transmitted data is not encrypted. This mechanism is therefore especially intended for interfacing banking information systems which share all or a part of the infrastructure with SEPAmail. With this channel, data to be transmitted is stored in files, both in incoming or outgoing mode. As a result, it is possible to have batch processing for the data. Files are in an XML format in compliance with the requirements specified by SEPAmail.


The file header contains three mandatory elements:

  • The date and time of the creation of the file
  • The identification of the third party with which the exchange is occurring. In any case, this refers to the BIC. For the incoming file this means the sender’s BIC and for the outgoing file the recipient’s BIC.
  • The number of missives contained in the file.

If the number of missives present after the file’s header is different from the number indicated in the header, a protocol error will occur. None of the missives will be processed and a negative acknowledgement will be generated for each missive.

Any file not complying with the standard or the Schema may simply be ignored as no protocol acknowledgment exists for files with this exchange mechanism. As with the other channels, any sender which does not receive an acknowledge missive for a nominal missive is responsible for re-transmission.

Use of the File Exchange Channel

The organization of the file mechanism and its exact details are left to the initiative of the SEPAmail application provider. This includes the following items:

  • file names
  • file locations
  • integration and/or production frequency
  • whether or not a file must be created if there is no data to be transmitted.

Example of Operation

As an example, this section describes an operating process with this channel (adopted during one of the test phases). The process is related to one of the implemented solutions of SEPAmail:

Any third party wishing to use a file connector has a specific directory for its file exchanges. In order to clearly separate the two flows, this directory contains two sub-directories, one for incoming files and the other for outgoing files.

File names have the following structure: <date>

  • <date> refers to the date of creation in a yyyymmdd format
  • <BIC> refers to the sender’s or recipient’s BIC, depending on the case
  • <application> refers to the application associated with the messages contained in the file, e.g. gemme, rubis, test, etc. It can also have the value ALL if the file contains messages for (or from) several applications.
  • <direction> can have two values:
    • in – if the file is coming into SEPAmail, therefore produced by a third party
    • out – if it is produced by SEPAmail , therefore transmitted to a third party.

A file can contain any number of missives, including 0. It contains a header and a certain number of missives, of Missive type.

It is recommended that the date of creation in the file header corresponds to the actual file name, but this is not mandatory.

The SEPAmail system checks the content of the sub-directory of the incoming files every hour at 5 minutes past the hour. It then creates a file in the outgoing files directory which contains all the missives available for a given recipient at that given moment. That file will be available every hour at 35 minutes past the hour at the latest. A file is generated every hour, both by the SEPAmail system and the third party, even if there is no missive to be transmitted.

Each party is responsible for deleting or archiving the files after they have been processed.

SEPAmail archives the incoming files and the third party manages the outgoing files. In any case, a file older than fourteen days may be deleted by SEPAmail in order to avoid overloading the system.

The link between the envelopes, missives and messages

References

Other languages: