De documentation SEPAmail.
Sender and Recipient
From a technical point of view, there is a sender of the transmission and a recipient. From a ' ' 'business' ' ' point of view, the transmission is especially important in terms of its response. As a result, the sender of the transmission becomes the recipient of the response.
For the initially planned services, it is therefore always preferable to use ' 'business-related' ' identifiers: creditor, debtor, ordering party, beneficiary.
Nevertheless, for the purposes of a general presentation, we will use the terms ' 'initial sender' ' and ' 'initial recipient' ' for the terms ' 'sender' ' and ' 'recipient' ', which have a double meaning.
The business exchanges are therefore structured as indicated above:
- Transmission initialization performed by initial sender
- Transmission to the recipient’s bank. In the SEPAmailmessagerie bancaire sécurisée. structure, this transmission is called a REQUEST (payment-request, mandate-request, etc.)
- Availability provided by the recipent’s bank, depending on the channel(s) provided by this bank.
- Validation by the initial recipient. As with initialization, authentication rules can be changed according to the underlying service
- After validation has been carried out and checked, the response is called REPORT (mandate-report, payment-report, etc.)
To ensure the smooth operation of the messaging service from a business point of view, every interbank transmission (nominal missive) must receive an acknowledgement missive from the recipient’s bank. It may contain data about service levels, but should not contain any business-related data. The latter should be included in a nominal missive transporting a REPORT message.
The acknowledgement missive is not acknowledged.
' ' 'The acknowledgement missive is not required to use the same exchange channel as the nominal missive' ' ' . In particular, it is quite possible to use only the SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») channel for all acknowledgement missives.
As SEPAmailmessagerie bancaire sécurisée. is a private initiative, it is not possible that ' ' 'all' ' ' members start on the ' ' 'same day' ' ' for each new applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail and each new upgrade.
As a result, it is important for the sender’s bank to manage reachability at 2 levels:
- At a high level by indicating that a recipient banking network has opened the service (this information will be organized in terms of the governance structure)
- At a transaction level by providing an intermediate response (section 2) which indicates if the bank is reachable.
The sender’s bank may take advantage of this management of reachability to offer an additional service. As part of the GEMMEGlobal European Mandate Management & Exchange (Application SEPAmail) test phase, this service involves the following:
- Receiving all mandate flows
- Responding based on whether or not the mandate has been sent (bank not reachable)
- Storing non-reachable mandates
- Automating the future transmission of these stored mandates each time that a new bank joins the SEPAmailmessagerie bancaire sécurisée. network.
Obviously, such a service is not very useful in terms of RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail) whose payment requests have a very short period of use.