De documentation SEPAmail.
General principles of the standard
Introduction : numbering
Each version of the standard is identified by a 4 digits number, with the format YYMM. The version 1206 is then dated in June 2012 for instance. The steering committee decides the frequency and the content of successive versions.
The version 1206 of the standard changed many items compared to the previous version, 1202. As a summary, we may even consider that this version changed everything.
On the other hand, the future versions of the standard will not necessarily have the same impact. They may content themselves to limited evolutions of some messages or ecosystems, even to let them completely unchanged – just adding for instance one or several new applications.
The version numbers of all messages may then be different from the standard version number itself: if these messages have not changed since the previous version of the standard, they will keep the same version number. We can consider that the version number of the standard is the maximum numbers of the messages and the missives included.
The diagram below shows a representation of the scope of the SEPAmail standards specifications:
Within a banking SEPAmail member, there are 4 types of main functional components:
- SMART which receives and sends missives in the SEPAmail members network (interbank cooperative space)
- the business components related to payment:
- RUBIS, related to payment request, managing RUBIS messages (linked to the payment.activation ecosystem)
- GEMME, related to money order signature, managing GEMME messages (linked to the direct.debit ecosystem)
- one security business component:
- SAPPHIRE, related to authentication and to authentication components exchange, managing SAPPHIRE message (linked to the ecosystem secure)
- SMILE which receives and sends missives in the bank customers network (intrabank competitive space)
The documents of the standard are:
- the XML diagrams and their implementation directives
- the comments requests (SMIRK in blue)
- business rules (in green)
- Functional and technical specifications
- API SMART (file and web-service)
- exchange protocols
- XML validation
- companies and application providers guide