Outils personnels

Standards: SMIRK MIS1202, the missive in the interbank exchanges

De documentation SEPAmail.

Cette page est une traduction de la page SMIRK MIS1202, la missive dans les échanges interbancaires et la traduction est complétée à 99 % et à jour.

LogoScheme.png

document type: comments request
the missive in the interbank exchanges

code SMIRK MIS1202 version 1.1 of June 26, 2012


Sommaire

Introduction and overview

The missive is the only entity allowing the exchange of information in the SEPAmail system. The missive has the envelope role for confidential data. In order to properly route the different information of the system, four types of missives have been defined:

  • the nominal missive, routing a message
  • the acknowledgement missive, with mainly a protocol objective

as well as:

  • the service missive, allowing a dialog of "command - answer" type between two systems, reserved to the competitive space outside of the SEPAmail network participants. This missive is therefore not used for exchanges between participants of the SEPAmail network
  • the SMAPI missive (SEPAmail API), that can solely be reached in an intrabank context, and allowing a SEPAmail service provider to provide a direct access to some elements of its platform.

The SMAPI missive is at the border of the SEPAmail standards: its existence is part of the standards but the exact content of SMAPI messages is up to service providers.

SEPAmail uses the missive to:

  • information addressing (who is the reveiver, who is the sender)
  • the information routing (how I forward the information)
  • the information receipt (has the information arrived)
  • the information integrity (is it the correct information)
  • the authentication of parties (are the sender and the receiver the ones they indicate they are)
  • the time stamping of the information (when was the information sent and received)

Principles

The missive is an XML flow complying with the diagram sepamail_missive[1], that is part of the specifications of the system. This element is used to transport all kinds of messages or other contents. It plays the envelope role and may be forwarded in several ways.

The missive may be of two types:

  • a nominal missive, envelope for any kind of content (but especially for a SEPAmail message),
  • an acknowledgement missive, allowing to notify the receipt of a nominal missive.

Note: The service missive is a notion that should not be used in the interbank space. It is therefore not included in this SMIRK. A lexicon of terms that are used is present on documentation of the SEPAmail Community[2].

The routing

The routing uses a "mail" type addressing on the domain sepamail.eu. The name of the sepamail.eu is managed by the SEPAmail scheme under the format: <ecosystem>@<bic>.sepamail.eu or <ecosystem>@<xx.scheme>.sepamail.eu where:

  • <ecosystem> is a valid SEPAmail family of the referential application@SCHEME
  • <bic> is a valid BIC if the referential BIC@SCHEME
  • <xx.scheme> represents a network node owned and managed by the scheme, for instance fr.scheme for the French QXOO. To understand the scheme organisation, refer to the SMIRK on its organisation SMIRK ORG1110

The routing is performed by the SEPAmail participants in the scheme with unattended machines implementing the following routing rules:

Routing rules at the receipt

  • A Participant only accepts missives for BICs it represents. Therefore, a Participant does not act as a relay of another Participant.
  • A Participant only accepts missives coming from a BIC linked to a SEPAmail Participant. The SEPAmail nekwork is therefore a network reserved solely to its Participants et closed to the rest of the world.

Routing rules for sending

  • A Participant sends flows in the SEPAmail network only to a SEPAmail Participant for a BIC that is declared and valid in the referential BIC@SCHEME.

The acknowledgement of a missive

The acknowledgement aims at informing the sender of the receipt, good or bad, of the missive that is sent and of a time stamping of this receipt.

It is the sender that manages the forward of information and not the receiver. The acknowledgement is mandatory and systematic. It does not depend on the sequence historic.

The acknowledgement class does not depend on the controls inmplemented by the receiver. The return codes are listed in specific implementation guidelines.

The acknowledgement is performed with the following rules:

  • only nominal missives are acknowledged
  • any nominal missive received (whatever its order) must be acknowledged
  • the acknowledgement must be performed in compliance with the priority and the maximum time limit of the priority.

The sequencing

The natural sequence of an exchanges of missives is:

séquencement des missives
  • a Participant A sends a nominal missive to a Participant B from a missive source system
  • a Participant B receives the nominal missive from the Participant A in a missive target system
  • the Participant B sends one or more acknowledgement missives to the Participant A as a response to th nominal missive
  • the Participant A receives the acknowledgement missive(s).

Below are listed the sequencing rules to be implemented:

  • the receiver of any received nominal missive must perform the acknowledgement of this nominal missive by at least one acknowledgement missive
  • no missive of another type than "nominal" or "acknowledgement" is sent
  • no missive of another type than "nominal" is acknowledged"
  • no "acknowledgement" missive is sent without having previously received a "nominal" missive

Resending a missive

A system to resend a missive may be implemented.

It is performed as follows:

  • it is implemented only with nominal missives,
  • the missive is resent with an order incremented by 1; the sender cannot change the content of the missive that is resent, except the order number
  • the S/MIME signature of the sender is therefore different.

If a nominal missive has not been acknowledged after a while, the following rules are implemented:

  • the sender of any nominal missive for which no acknowledgement has been received after the time limit of mimimum defined for the missive priority, may send again the missive with an incremented order number; it cannot do it beforehand; it is not obliged to so do
  • the resending of a missive cannot be performed after a period of time, as defined in the table below, after the sending of the previous missive
  • the sender of any nominal missive for which an acknowledgement is not received in the maximum timing authorised for the priority of the missive and that has resent at least once the missive may then implement the planned process to escalate; it cannot do it beforehand; it is not obliged to do it.

The system to increment the order of the nominal missives is not intended to allow to forward several times a same missive to receive different acknowledgements. This system is only used to receive an acknowledgement if it has not been received.

The following rules are therefore applied:

  • a system to receive and control the acknowledgements must be implemented,
  • resending a missive is not possible if it has already been acknowledged, except if the acknowldegement class is 4 (temporary error).
Waiting time before resending depending on the missive priority
Priority Acknowledgement maximum time limit Minimum time limit before resending Maximum tile limit before resending Maximum resending number
1 the highest 20 sec 30 sec 1 min 3
2 high 3 min 5 min 10 min 5
3 normal 4 h 4 h 8 h 4
4 low 12 h 12 h 24 h 3
5 the lowest 48 h 48 h 96 h 3

The resending time limits are reset to zero each time the missive is resent. Therefore, if a missive with a "high" priority is sent at T time for the first time (order 1), the missive of order 2 can be sent between T+5min and T+10min. If it is sent at T+7min, the missive of order 3 (if no acknowledgement is still received of course) can be sent between T+12min and T+17min, etc...

The maximum acknowledgement time limit, the minimum time limit before resending and the maximum number of resendings that are mentionned here, are default values. If two Participants sign a bilateral agreement, they are free to agree on different time limits and/or on a higer number of resendings.


Waiting time before escalation depending on the priotity of the missive
Priority Minimum time limit before escalation
1 the highest 10 min
2 high 30 min
3 normal 16 h
4 low 36 h
5 the lowest 120 h

Reminder: this time limit is calculated starting when the first missive is sent (order 1), it is not reset to zero each time the missive is resent, contrary to the resending time limits described above.

The escalation process

If a missive is not acknowledged, even after having been resent, the participant may process an escalation planned by the scheme as soon as a minimum time limit is reached after the last resending (refer to the table below).

This escalation is specified by the Scheme in a specific SMIRK.

The content

According to the SEPAmail business rules, a missive necessarily includes:

Contenu facultatif et obligatoire d'une missive
  • a unique identifier,
  • a type,
  • a presentation order,
  • a header,

and depending on the missive type:

  • an acknowledgement for an acknowledgement type missive,
  • a SEPAmail message for a nominal type missive,

and as an option:

  • a signature of the message, which should not be mixed up with the signature of the message within the SMTP envelope. This signature is essentially used to provide the capability to add an electronic signature of the signer, customer of the bank and sender of the message.

It is important to note that, from the strict point of vue of the compliance to the XML schema, the "message" and the "acknowledgement" sections are optional (refer to the next diagram).

The header of the missive follows three principles:

  • the symmetry principle between the receiver and the sender of the message, as both may have the two functions
  • the priority principle which allows each entity to manage the peak by prioritizing the flows
  • the principle of integrity of the information generated by the unattended machines; this principle is ensured by a set of controls on the content for which the integrity check is required

The envelope

The missive is integrated in an SMTP-S/MIME envelope. This envelope includes:

  • headers:
    • FROM, mail address such as specified in this document, valid with a domain name declared in the DNS
    • TO, mail address such as specified in this document, valid with a domain name declared in the DNS
    • X-priority, priority according to the specification of this document
    • SUBJECT empty be default, without significtive information on the content of the message
  • a body integrating again two parts:
    • the missive, enciphered with the private key of the S/MIME certificate linked to the FROM address
    • a S/MIME signature, mandatory

Modèle:Note: the missive must be enciphered in any case, even for a flash route (webservice on an SMTP layer), in order to allow a non adhesion of the production application layers of the SMTP layers and of its transport.

The security: authentication, confidentiality and time stamping

The security is ensured at different levels:

  • the authentication of both parties
  • the confidentiality of the forwarded information
  • the time stamping of the processes of the missives sending and receiving

SEPAmail uses asymmetric encryption processes.

Participants are sure to have access, in a secure way, to the public keys of each Participant.

The authentication of the sender (SEPAmil Participant)is then ensured by a signature of the condensate of the whole content of the missive with the private key of the sender. The receiver will then be able to check that the condensate of the missive it has generated is the same than the one of the signature it has deciphered.

The confidentiality is ensured by the encryption of the missive by the sender with the public key of the receiver. Therefore, the receiver will be the only one able to decrypt the flow with its private key.

The missive is time stamped both for the sending and the receipt by a time reference of date/time type. The detailed time stamping principles that apply to SEPAmail, issued from best practices of the FNTC [3], sont décrits dans cette page.

If a time stamping of type "signed time countermark" is needed, this time stamping is then performed on the SMTP envelope (and not only the missive) by a certified third party entity right before the sending or right after the receipt.

The exchange protocol of the missives

la place des protocoles d'échange dans l'architecture protocolaire

The exchange of missives is natively performed on the IP network via the TCP transport layer.

On these layers, SEPAmail implements two routes with two different communication ptotocols:

  • SMTP
  • HTTPS+SOAP


Modèle:Note: this exchange gets implementation guidelines and is outside of the standards context of this document.

Modèle:Note: a study is currently ongoing to enable a flash route based on HTTP+REST

The service quality

The service quality is defined in a separate document [4].

Processing

The functional diagrams of the receipt and of the sending of a missive are described below. Unattended machines of Bank Participants must comply with those diagrams.

Actions on data to be performed are in blue, tests in green.

The operations follow each other according to a time sequence described from the top to the bottom.


Receipt of a nominal missive

la séquence fonctionnelle autour de la réception de missive

Receipt of an SMTP envelope with the S/MIME format

The receiver of the missive receives envelopes at the format S/MIME, whatever channel this envelope comes from (SOAP or SMTP).

Check of the S/MIME integrity

It is necessary to check that the format of the received envelope is S/MIME.

The following elements must also be present:

  • the FROM field filled in
  • the TO field filled in
  • one part enciphered or not
  • a signature with the S/MIME format

Modèle:Note: the SMTP subject may be absent or empty.

Extraction of the MIME header and of its two parts

The following elements are extracted: the FROM address, the TO address and the two parts attached to the envelope, usually the XML content of the missive and a signature of this content.

Check of the BIC

It is necessary to extract the sub-domains of the FROM and TO addresses.

These two sub-domains must be those of a BIC included in BIC@SCHEME.

The one corresponding to the receiver (TO) must also be on the BICs linked to the receiving Participant in the participant@SCHEME referential.

Check of the ecosystem

The ecosystem provided by the mail address must be a set of messages managed by the SEPAmail network. It must be part of ecosystem@SCHEME.

Decryption

The first part of the MIME envelope is encrypted (Content-Type: multipart/encrypted) and must therefore be decrypted with the private key of the receiver (BIC extracted from the TO address) (protocol defined by the "protocol" attribute of the "Content-Type header). The decrypted chain is considered as the missive to check.

Calculation of the condensate of the missive

A condensate of the content of the missive is calculated based on the method declared in the S/MIME characteristics (micalg attribute of the Content-Type header).

Check of the S/MIME signature of the sending Participant

The signature of the SEPAmail sending Participant is checkedby comparing the condensate previously calculated with the result of the signature decryption.

Check of the XML compliance

The missive is an XML document for which we check it is correctly created (correct syntax)[5].

Check of the XML validity

The missive is an XML document fow which the following checks are performed:

  • it includes a reference to the SEPmail name space,
  • it is valid (it validates the XML schema that it references).

Header extraction

The header is extracted from the missive in order to allow the following checks.

Time stamping

The missive is time stamped when received, which means the XML content is enriched by filling in the field « RcvDtTm » of the missive header with the date and time of the system.

Check of the Rcv field

The Rcv field includes at least:

  • an identifier of a SEPAmail user (usually a bank identifier IBAN, PAN, QXBAN...),
  • an identifier of the SEPAmail Participant (BIC or SCHEME entity code)

This identifier must correspond to a valid user of the SEPAmail service.

It must represent a active user in one of the identifiers referentials managed by the Participant receiving the missive: QXBAN@BIC, IBAN@BIC, PAN@BIC.

Acknowledgement

The acknowledgement involves sending a missive with rules that have been defined above.

Internal routing of the missive

The missive is routed toward the bank application or the technical mechanism linked to the SEPAmail ecosystem involved.

Receipt of an acknowledgement missive

The SEPAmail Participant is theoretically not obliged to perform any process when receiving the acknowledgement, except:

  • to get the statistics requested by the Scheme
  • to comply with the requirements of the Participants charter

If it wishes to process these missives, it will have to implement the same procedure than the one used for the receipt of a nominal missive, with the difference that the acknowledgement missive is not itself acknowledged.

Modèle:Note: in case of errors within the acknowledgement missive during the checks (non compliant or non valid XML, non valid headers), these errors can therefore not be notified. The mechanism to resend the nominal missve or the escalation process must then be used in order to avoid the system to loop.

Check of the acknowledgement missive history

At this stage, it is possible to check whether the acknowledgement missive already has a history:

  • when receiving: do other acknowledgements exist on the same nominal missive ?
  • when sending: does a nominal missive exist ?

Internal routing of the missive to the IS

The missive is routed to the bank application or the technical mechanism linked to the SEPAmail ecosystem if the logic of the bank IS requires it.

Sending a nominal missive

la séquence fonctionnelle autour de l'émission de missive

Recovery of the sending/information order

A nominal missive is sent after a sending order from a bank application.

The missive may be recovered as it is, in which case it is verified before signature/encryption and sending.

The missive may be created by the unattended machine.

In both cases, the following checks are performed.

Check of the BIC

BIC are extracted from the inforamtion routed or deduced from a IBAN@BIC referential. The two BIC must belong to a Participant@SCHEME or be SCHEME.

The one corresponding to the sender (FROM) must also be a BIC owned by the Participant.

Check of the ecosystem

The ecosystem may be deduced from the message included in the missive or transmitted by the bank application (preferred way). It must be an ecosystem managed by the SEPAmail network, osned by ecosystem@SCHEME.

Check of MsvSnd

The field MsvSnd includes an identifier(IBAN, QXBAN, PAN, ICQX/BIC, BIC)

This identifier must correspond to a valid user of the SEPAmail service.

It must therefore be active in one of the identifiers referentials managed by the Participant sending the missive: QXBAN@BIC, IBAN@BIC, PAN@BIC.

Check of the compliance of the XML of the message

The message to be enveloped in the missive is an XML document for which the compliance is checked.

Check of the validity of the XML message

The message is an XML document for which the following checks are performed:

  • it includes a reference to an XML schema of the family of the requested application,
  • it is valid.

Creation of the missive

A missive is created from the message and from previously checked information or, in the case of the initial routing of a missive, from an enrichment of this missive.

Time stamping

The missive is time stamped when sending, which means the XML content is enriched by filling in the "SndDtTm" field of the header of the missive with the date and time of the system.

Check of the compliance of the XML with the missive

The missive created at the previous step is an XML document for which the compliance is checked.

Check of the validity of the XML of the missive

The missive is an XML document for which the following checks are performed:

  • it includes a reference to the XML schema

sepamail_missive[6]

  • it is valid.

Calculation of the condensate of the missive

A condensate of the missive is calculated in accordance with a valid method declared in the S/MIME characteristics (micalg attribute of the Content-Type header).

S/MIME signature of the sending Participant

The signature of the condensate previsouly created is performed with the private key of the sending SEPAmail Participant, this key being dedicated to sending missives.

Encryption

The missive encryption is performed with the encryption public key of the receiver.

Creation of a MIME envelope

A MIME envelope is created. It includes:

  • the field FROM,
  • the field TO,
  • a first part including the missive, possibly encrypted,
  • a second part including the S/MIME signature of the missive.

Note: the possible attached documents of the message are attached to the message and therefore included in the XML as binary. The MIME mechanism of the attached documents is therefore not used for them but only for the missive AND for the signature.

Sending according to the priority

The priority of the missive is taken back for the routing.

Sending an ackowledgement missive

The case of an acknowledgement missive is similar. Only the message is replaced by the acknowledgement structure, including the acknowledgement code.

References

  1. http://xsd.sepamail.eu/current/sepamail_missive.xsd
  2. Permalien http://documentation.sepamail.eu/wiki/Lexique
  3. Guide des bonnes pratiques en matière de datation d’événements ou d'objets électroniques, http://www.fntc.org/, section guide (utilisateurs enregistrés)
  4. SMIRK escalade ESC1108
  5. Refer to the W3C definition here [1]
  6. http://xsd.sepamail.eu/current/sepamail_missive.xsd
Autres langues :English 99% • ‎Français 100%