Embed Size (px)
Citation preview
SEPAmailNorme1206–ÉditiondeJuin2015 Page1
SEPAmail Norme 1206
Edition Juin 2015
SEPAmailNorme1206–ÉditiondeJuin2015 Page2
Table des matières
Validation 1206 .................................................................... 5
Contributeurs 1206 ................................................................. 6
1. Introduction ...................................................................... 7
1.1. Présentation générale .................................................... 8
1.2. Evolutions de la Norme 1206 - édition de juin 2015 ....................... 9
2. La messagerie .................................................................... 10
2.1. Présentation et principes ............................................... 11
2.2. Les mécanismes d'échange ................................................ 14
2.3. Spécification de l'échange des enveloppes SEPAmail ...................... 20
2.4. Les mécanismes d'identification ......................................... 24
2.5. ICQX ................................................................... 31
2.6. RIS2D .................................................................. 32
2.7. Algorithme de génération du QXBAN ....................................... 34
2.8. La vision métier........................................................ 35
3. La sécurité ...................................................................... 38
3.1. Principes de sécurité ................................................... 39
3.2. SMIRK CRY1203, la cryptographie ......................................... 41
4. La norme ......................................................................... 44
4.1. La norme ............................................................... 45
4.2. IG General Rules........................................................ 47
4.3. IG Colour Coding........................................................ 48
4.4. SMIRK MIS1202, la missive dans les échanges interbancaires .............. 49
4.5. IG missive ............................................................. 62
4.6. Missive de service...................................................... 67
4.7. Horodatage des missives ................................................. 68
4.8. Statistiques ........................................................... 69
4.9. IG missive returnCodes .................................................. 72
4.10. IG message ............................................................. 74
4.11. SMIRK MES1102, le message dans le réseau interbancaire .................. 79
4.12. SMIRK APP1103, l'application SEPAmail ................................... 82
4.13. SMIRK REF1104, les référentiels ......................................... 85
4.14. SMIRK REF1201, le référentiel icqx@scheme ............................... 88
5. L'application RUBIS .............................................................. 96
5.1. RUBIS 1206 ............................................................. 97
5.2. Les principes généraux (RUBIS) .......................................... 98
5.3. Les avantages pour le client (RUBIS) ................................... 100
5.4. Cas d'usage (RUBIS) .................................................... 101
SEPAmailNorme1206–ÉditiondeJuin2015 Page3
5.5. La gestion des inscriptions des débiteurs (RUBIS 1206) ................. 106
5.6. La gestion des flux (RUBIS) ............................................ 110
5.7. Les normes utilisées par RUBIS ......................................... 115
5.8. Le lettrage des virements (RUBIS) ...................................... 116
5.9. Les règles métier (RUBIS) .............................................. 117
5.10. La gestion des refus après acceptation et avant échéance (RUBIS) ....... 120
5.11. Le récapitulatif des messages (RUBIS 1206) ............................. 121
5.12. IG payment.activation .................................................. 122
5.13. IG Rubis ActivationRequest ............................................. 123
5.14. IG Rubis ActivationReport .............................................. 172
5.15. IG Rubis ActivationEnroll .............................................. 230
6. L'application GEMME ............................................................. 232
6.1. GEMME ................................................................. 233
6.2. Les principes généraux (GEMME) ......................................... 234
6.3. Les avantages pour le client (GEMME) ................................... 235
6.4. Cas d'usages (GEMME) ................................................... 236
6.5. La problématique des flux autour du prélèvement ........................ 238
6.6. La gestion des flux (GEMME) ............................................ 240
6.7. Les normes utilisées (GEMME) ........................................... 242
6.8. Le récapitulatif des messages (GEMME) .................................. 243
6.9. Les règles métier (GEMME) .............................................. 244
6.10. IG direct.debit ....................................................... 251
6.11. IG Gemme MandateInitiationRequest ...................................... 252
6.12. IG Gemme MandateAcceptanceReport ....................................... 259
6.13. IG Gemme Prenotification ............................................... 265
6.14. IG Gemme RequestForCopy ................................................ 268
7. L'application DIAMOND ........................................................... 271
7.1. DIAMOND ............................................................... 272
7.2. Les principes généraux (DIAMOND) ....................................... 273
7.3. Cas d'usage (DIAMOND) .................................................. 274
7.4. Gestion des flux (DIAMOND) ............................................. 275
7.5. Les règles métier (DIAMOND) ............................................ 276
7.6. Le récapitulatif des messages (DIAMOND) ................................ 286
7.7. Les aspects juridiques (DIAMOND) ....................................... 287
7.8. IG identification.verification ......................................... 289
7.9. IG Diamond VerificationRequest ......................................... 290
7.10. IG Diamond VerificationReport .......................................... 295
8. L'écosystème TEST ............................................................... 300
SEPAmailNorme1206–ÉditiondeJuin2015 Page4
8.1. IG test ............................................................... 301
8.2. IG Test SimpleTestRequest .............................................. 302
8.3. IG Test SimpleTestReport ............................................... 303
9. L'écosystème SECURE ............................................................. 304
9.1. IG secure ............................................................. 305
9.2. IG Secure EnrollAdvise ................................................. 306
9.3. IG Secure EnrollRequest ................................................ 309
9.4. IG Secure EnrollReport ................................................. 312
10. Sources et contributeurs de l’article ............................................ 315
11. Source des images, licences et contributeurs .................................... 316
12. Licence ......................................................................... 317
SEPAmailNorme1206–ÉditiondeJuin2015 Page5
Validation1206La Norme 1206 a été validée par le Comité de coordination SEPAmail
Christine GUILLAUMET – Représentante BNP PARIBAS – Animatrice Comité Expérimentation
Lise MAHAUT – Animatrice Comité Normes
Arnaud-Louis CHEVALLIER – Représentant SOCIETE GENERALE
Marc RAINTEAU – Représentant Crédit Mutuel CIC
Laurent RIPOCHE / Jacques BAILLON – Représentants Groupe CREDIT AGRICOLE
Hervé ROBACHE - Committer de la Norme
Eric VERONNEAU – Représentant BPCE
Cyril VIGNET – Animateur du Comité de Coordination SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page6
Contributeurs1206
Norme SEPAmail 1206
Cette norme est mise à disposition selon les termes de la licence Creative Commons Paternité -
Partage à l'Identique 3.0 non transposé.
Auteurs
Lise MAHAUT – Crédit Mutuel CIC Manfred OLM – DECIBI
Eric MEVEL – Euro INFORMATION Olivier JOUSSELIN – SOLAGO
Jean-Philippe NAUDOT – Euro INFORMATION Eric VERONNEAU – BPCE
Hervé ROBACHE - STET Cyril VIGNET - BPCE
Contributeurs aux travaux du Comité Norme
édition Novembre 2012
Chloé BOIVIN – NATIXIS PAIEMENTS Frédérique FORTIN – SOCIETE GENERALE
Théa SIEMONS – Groupe CREDIT AGRICOLE
Frédéric ALBOUY - BPCE Nicolas BARTHELEMY – NATIXIS PAIEMENTS
Jean-François BAUDIN – TURBO S.A Lionel CHEMLA – pour BPCE
Tony CROIZER – Euro INFORMATION Tristan DENMAT – AriadNext
Guillaume DESPAGNE – AriadNext Jean-Louis GLORIAN – Crédit Mutuel CIC
Nicolas MUHADRI – STREAM MIND Hervé NEUMAN – pour SOCIETE GENERALE
Marc NORLAIN – AriadNext Thierry PONS – BNP PARIBAS
Marc RAINTEAU – Crédit Mutuel CIC Bertrand SANDOZ – BNP PARIBAS
Maxime TOHIER – STREAM MIND Rui VAZ – BNPPARIBAS
éditions Septembre 2014 et Juin 2015
Chloé BOIVIN – Natixis Payment Solutions Isabelle GODELIER – Groupe CREDIT AGRICOLE/LCL
Jacques BAILLON – Groupe CREDIT AGRICOLE Luc BIRS – Groupe CREDIT AGRICOLE
Pierre BOULEAU - STET Thierry CAILLETET – BPCE
Christophe CORNILLE – pour Groupe CREDIT AGRICOLE Eric CUVILLIER – Société Générale
Matthieu DAMBRIN – pour Natixis Payment Solutions Jean-Louis GLORIAN – Crédit Mutuel CIC
Jérome MAILLART - Natixis Payment Solutions Thierry PONS – BNP PARIBAS
Les contributions à la mise à jour du WIKI sont quant à elles répertoriées en fin de document.
SEPAmailNorme1206–ÉditiondeJuin2015 Page7
1. Introduction
SEPAmailNorme1206–ÉditiondeJuin2015 Page8
1.1. PrésentationgénéraleSEPAmail est un service de messagerie sécurisée pour l'ensemble des entités économiques
européennes.
SEPAmail utilise des flux XML sécurisés utilisant le BIC et l’IBAN comme identifiant de
référence.
En valorisant Internet et les normes du W3C, le réseau SEPAmail permet, à coût réduit, la
réalisation d’échanges complexes entre les clients des banques à un niveau mondial.
Ce nouveau réseau interbancaire se veut une contribution de l’industrie bancaire à l’agenda
de Lisbonne et Europe 2020 en facilitant les échanges dématérialisés entre les entités
économiques.
Historique
SEPAmail est un projet d’innovation démarré en 2008 dans le but de proposer une messagerie
interbancaire sécurisée principalement pour une utilisation pour des documents non comptables
autour des paiements (factures, mandats, devis, avis,...)
Ce concept a été décliné techniquement et une série de messages structurés pour les flux autour
des prélèvements a été définie. Sur la base de ce concept un partenariat a été signé avec SFR
pour la mise en œuvre d’un pilote sur flux réel.
Prérequis
Pour comprendre cette documentation, un certain nombre de notions doivent être connues, voire
maîtrisées. Voici une liste de ce qui est supposé connu :
le fonctionnement du courrier électronique : sa structure (RFC 822 et suivants, ainsi
que ceux relatifs à S/MIME), son mode d'acheminement (de MTA à MTA), les erreurs
protocolaires pouvant survenir ...
le fonctionnement de DNS
de bonnes notions de cryptographie, en provenance par exemple du portail de la
cryptologie de Wikipédia
Si vous consultez la documentation sur le Wiki de SEPAmail, nous vous recommandons en outre de
comprendre auparavant ce qu'est un wiki, comment il fonctionne et comment interagir avec lui.
SEPAmailNorme1206–ÉditiondeJuin2015 Page9
1.2. EvolutionsdelaNorme1206‐éditiondejuin2015Les évolutions de la version 1206 édition de juin 2015 par rapport à l’édition précédente de
septembre 2014 portent sur :
la réécriture des IG Rubis ActivationRequest et ActivationReport pour une plus grande
précision sur le contenu de ces messages (import des règles ISO20022, précision des
règles d’usage SEPAmail)
l’introduction, dans ces IG Rubis ActivationRequest et ActivationReport, des contrôles
possibles et des ReasonCodes associés
la suppression du document de correspondance (mapping) entre ActivationRequest et
ActivationReport, et entre ActivationReport et le message pacs.008, car ces éléments ont
été reportés dans les IG Rubis ActivationRequest et ActivationReport elles-mêmes.
SEPAmailNorme1206–ÉditiondeJuin2015 Page10
2. Lamessagerie
SEPAmailNorme1206–ÉditiondeJuin2015 Page11
2.1. PrésentationetprincipesLe système SEPAmail se compose :
d’un réseau interbancaire sécurisé assurant le transport de messages structurés
conformément aux normes partagées par les utilisateurs de SEPAmail. Le réseau SEPAmail
se déploie par l’interconnexion entre serveurs conformes à la norme installés dans
chaque établissement adhérent.
de services métiers à valeur ajoutée, supportés par le système SEPAmail au travers de
l’utilisation d’une famille de messages structurés liés à chaque service métier mis en
ligne sur ce réseau.
SEPAmail décrit également les connecteurs permettant aux entreprises d'envoyer, de recevoir et
de gérer des messages –- ou plus exactement, en termes SEPAmail, des missives – à travers
diverses formes d'interfaces : courriel, Web service, et même échange de fichiers.
Lesespacesdeconfiance
Pour assurer une parfaite sécurisation des échanges et des données, SEPAmail repose sur trois
espaces de confiance complètement distincts et indépendants :
L’espace expéditeur – banque de l’expéditeur, dont la sécurité repose sur les systèmes
en place : banque à distance et authentification associée, remise de fichiers ...
Le réseau interbancaire SEPAmail dont la sécurité repose sur :
1. Un nom de domaine unique géré par le « scheme-manager » et associant l’adresse
BIC.sepamail.eu à la bonne adresse physique de routage de la banque possédant le
BIC
SEPAmailNorme1206–ÉditiondeJuin2015 Page12
2. Une déclaration au scheme-manager de la clé publique qui sera utilisée par S/MIME, déclaration faite en même temps que la fourniture de l’adresse IP de la banque
L’espace banque du destinataire – destinataire, dont la sécurité repose également sur
les systèmes en place : banque à distance et authentification associée, remise de
fichiers, ...
Il y a un certificat S/MIME de signature et un certificat S/MIME de chiffrement par BIC
et par application SEPAmail.
Lastructurationdusystème
L'élément de base pour les échanges d'informations, dans SEPAmail, est la missive. Quel que
soit le canal d'échange, et quels que soient l'expéditeur et le destinataire, toutes les
informations circulant dans le système sont systématiquement structurées en missives. Il existe
quatre types de missives, qui seront décrites en détail par la suite :
la missive nominale, qui sert d'acheminement à un message
la missive d'acquittement, élément essentiellement protocolaire qui permet notamment à
l'expéditeur d'être sûr de la réception des informations transmises
la missive de service, permettant d'échanger des commandes et des réponses entre des
éléments actifs du système. Elle ne peut pas être utilisée en interbancaire.
la missive d'interfaçage (SMAPI), permettant à l'éditeur d'une solution SEPAmail de
donner accès à des fonctions internes de sa plate-forme. Elle ne peut être utilisée
qu'en intrabancaire.
La missive est sécurisée par des mécanismes de signature et de chiffrement. Elle peut être vue
comme une enveloppe, dont le contenu peut être quelconque, mais n'est accessible qu'au
destinataire. Dans la plupart des cas, et notamment dans le cas des missives nominales, le
contenu d'une missive est un message SEPAmail. Le message contient des informations relatives
au service mis en jeu, la nature de ces informations variant bien entendu selon le message.
L'ensemble des éléments de SEPAmail, missives et messages, sont des structures XML. Tous les
éléments sont décrits par des schémas XML précis, s'appuyant, dans la mesure du possible, sur
la norme et le dictionnaire de données ISO 20022. Enfin, les missives sont échangées, entre les
acteurs du système SEPAmail, par le biais d'un mécanisme d'échange. Trois mécanismes, qui sont
détaillés par ailleurs, sont actuellement définis et implémentés dans le système :
le courrier électronique
un web-service
un système d'échange de fichiers.
Le schéma ci-dessous récapitule les éléments de structure du système SEPAmail:
SEPAmailNorme1206–ÉditiondeJuin2015 Page13
RappelS/MIME
Le standard S/MIME étend le format de courrier MIME pour permettre, au travers de
plusieurs mécanismes cryptographiques, de chiffrer et signer les différents composants
d'un message. Il s'applique donc directement sur le contenu du message et non sur le
canal de transport de ce contenu.
La clé de session est insérée dans l'en-tête de chaque partie S/MIME, après avoir été
chiffrée à l'aide de la clé publique de chacun des destinataires. Ainsi ces derniers
pourront par la suite déchiffrer, à l'aide de leurs clés privées, la clé de session et
accéder au contenu de la partie S/MIME.
Par ailleurs, la signature d'une partie S/MIME est générée à l'aide de la clé privée de
l'expéditeur. La vérification de cette signature à l'aide de la clé publique de
l'expéditeur permet de garantir au destinataire l'identité de celui-ci et de contrôler
l'intégrité de la partie S/MIME.
Source : http://www.commentcamarche.net/contents/crypto/s-mime.php3#q=smime&cur=1&url=%2F
SEPAmailNorme1206–ÉditiondeJuin2015 Page14
2.2. Lesmécanismesd'échangePrécisionssurleséchanges
Dans son acceptation initiale, SEPAmail gère uniquement une interface interbancaire, c'est à
dire celle des flux échangés entre les banques.
Dans la pratique, il se peut qu'une banque utilise soit le protocole SEPAmail, soit la
structure SEPAmail (missive), soit les 2 dans ses échanges avec ses propres clients (interface
client). Plus généralement, une banque peut aussi utiliser en interne (interface intrabancaire)
les normes SEPAmail.
Trois mécanismes d'échanges ont été définis : courriel, web service, fichier.
Parmi ces mécanismes d'échange disponibles, seul le canal courriel est obligatoire, et doit
être supporté par tous les adhérents à SEPAmail en interbancaire. Le mécanisme d'échange
interbancaire fondé sur les Web services est facultatif (même si c'est celui mis en œuvre dans
l'expérimentation).
Par ailleurs, SEPAmail est un système asynchrone par architecture. De ce fait, l'acheminement
des messages ne peut être soumis à aucun engagement absolu quant au temps de transit. Les
délais liés aux priorités des missives sont donc à mettre en perspective du canal utilisé – par
exemple, une missive en priorité HIGHEST envoyée par courriel risque fort de ne pas être acquittée dans les délais prévus par ce niveau de priorité.
Un troisième mécanisme (fichier) a été défini pendant la phase d'expérimentation, initialement
pour des besoins intrabancaires, et ne concerne JAMAIS l'interface interbancaire. Il peut être
utilisé pour l'interface client ou l'interface intrabancaire.
La description donnée ici des mécanismes d'échange est essentiellement fonctionnelle, et
légèrement technique. Des spécifications techniques complètes, traitant notamment des
problématiques d'adressage, sont disponibles ici.
Lecourrierélectronique
Principe
Le mécanisme d'échange fondé sur le courrier électronique a été le premier implémenté, et le
système SEPAmail en tire d'ailleurs son nom. Le principe en est simple : tous les éléments sont
acheminés comme des messages mail.
Le contenu du mail doit donc être conforme au RFC 38511, le corps du mail étant obligatoirement
une missive SEPAmail, apparaissant comme un attachement au format S/MIME ( RFC 53212).
L'expéditeur et le destinataire du mail sont obligatoirement de la forme :
<ecosystem>@<bic>.sepamail.eu
<ecosystem> correspond à un ensemble de messages acheminés.
Cinq écosystèmes sont actuellement supportés :
direct.debit, qui est utilisé par l'application GEMME
payment.activation, qui permet la création de virements de proximité, et est utilisé par
l'application RUBIS
identification.verification, pour la vérification d'identifiants bancaires, en rapport
avec l'application DIAMOND
SEPAmailNorme1206–ÉditiondeJuin2015 Page15
secure, qui permet l'échange d'éléments de sécurité (certificats ou messages) entre tous
les intervenants du système SEPAmail
test, destiné comme son nom l'indique à des tests de configuration et/ou de
communication
<bic> est le BIC de l'expéditeur (ou du destinataire). Dans le cas d'un échange interbancaire,
les deux adresses doivent présenter ce BIC. Dans le cas d'un échange entre client et banque,
l'adresse de l'expéditeur peut comporter un IBAN au lieu du BIC.
Les messages doivent être d'abord signés en utilisant la clé privée de signature de
l'expéditeur, puis chiffrés en utilisant la clé publique de chiffrement du destinataire.
Les adresses IP des serveurs de mail doivent être déposées au préalable auprès du Scheme
SEPAmail, ainsi que les certificats utilisés pour le chiffrement et la signature des messages.
Utilisationducanalcourriel
En-dehors de l'utilisation d'adresses IP fixes et pré-déclarées pour router les messages, les
messages acheminés par ce canal suivent les règles habituelles du courriel. Il est donc de la
responsabilité de l'expéditeur de s'assurer de la bonne émission des messages qu'il envoie :
les notifications d'erreur ou de non-remise sont acheminées par le canal standard entre MTA, et
l'expéditeur doit prendre en charge la réexpédition éventuelle dans ce cas.
LeWebservice
Principe
Cette méthode d'échange a été initialement prévue pour permettre à un émetteur de gérer ses
messages de façon plus synchrone et plus directe que le courrier électronique.
SEPAmailNorme1206–ÉditiondeJuin2015 Page16
Dans l'état actuel du système, il est déployé pour les échanges entre banques (connecteur
interbancaire) et pour les échanges entre les entreprises et leurs banques (connecteur
entreprise).
Le principe du Web service est similaire à celui du courrier électronique : le message envoyé
comporte un en-tête basique, et un corps, respectant le format S/MIME, contenant une missive
SEPAmail, signée puis chiffrée.
Dans l'en-tête comme dans la missive, l'identifiant de l'expéditeur peut être une adresse mail
quelconque, gérée par le créancier, mais doit correspondre précisément au certificat utilisé
pour chiffrer la missive. À défaut, la transmission sera rejetée. Le destinataire, lui, est de
la même forme que pour le canal mail : <ecosystem>@BIC.sepamail.eu où le BIC est celui de la
banque du créancier.
La connexion avec le Web service se fait au travers du protocole HTTP ou HTTPS. Les données
binaires sont encodées au travers du protocole MTOM. Comme pour tous les autres mécanismes
d'échange pouvant être ouverts vers l'extérieur, les messages doivent être, d'une part signés
en utilisant la clé privée de signature de l'expéditeur, d'autre part chiffrés en utilisant la
clé publique de chiffrement du destinataire. Tous les types de missives peuvent figurer dans un
message WebService.
Ceci ouvre donc de nombreuses possibilités à l'entreprise utilisant ce canal :
envoyer des nouveaux éléments (mandats, notifications ...) à SEPAmail, en utilisant des
missives nominales
se connecter pour gérer les messages reçus (acquittements, modifications de coordonnées
bancaires ...), par le biais de missives de service
dans des versions futures, modifier ses informations ou sa relation avec le système
SEPAmail
Dans tous les cas, le Web service n'est prévu que pour fonctionner en mode "pull" : un client
doit se connecter au Web service à son initiative pour communiquer.
UtilisationduWebservice
Dans un cadre intrabancaire (communication créancier-banque du créancier notamment),
l'utilisation de la missive de service sur le Web Service peut se substituer entièrement à la
connexion SMTP. Le serveur SEPAmail joue alors le rôle de serveur de messagerie pour ses
clients, ce qui n'est pas son rôle fondamental.
Dans ce cadre, il est donc de la pleine et entière responsabilité de l'entreprise ou du
créancier :
de se connecter à intervalles suffisamment fréquents pour recevoir les nouveaux
messages.
de gérer correctement une éventuelle absence de réponse de la part du serveur (time-out)
d'exploiter ces messages, étant entendu que SEPAmail n'assure qu'un rôle de stockage et
non d'exploitation, sauf pour les données concernant strictement le système SEPAmail
(état des mandats dans la base de données interne, par exemple)
de gérer les messages présents sur le serveur, notamment en supprimant ceux qui ne sont
plus utiles. Ceci a pour but, d'une part de faciliter la gestion des messages restants
en réduisant leur nombre, d'autre part de limiter la place occupée sur les serveurs
SEPAmail, dont la vocation n'est pas à proprement parler de servir des messages.
SEPAmailNorme1206–ÉditiondeJuin2015 Page17
Précisons que l'archivage est assuré par SEPAmail de façon interne. Le fait de supprimer un
message par le biais du Web service le rend donc inaccessible par ce même canal, mais ne le
détruit pas entièrement des données de SEPAmail.
L'échangedefichiers
Principe
Ce troisième canal d'échange est conçu pour être utilisé uniquement sur une interface interne à
la banque, notamment parce que les données sont transférées sans être chiffrées. Il est donc
avant tout destiné à s'interfacer avec des systèmes d'informations bancaires partageant tout ou
partie de l'infrastructure avec celle de SEPAmail. Dans ce canal, les éléments à acheminer sont
stockés dans des fichiers, aussi bien en entrée qu'en sortie. Ceci permet donc d'organiser des
traitements en batch des données. Les fichiers seront au format XML, conformément au schéma
fourni par SEPAmail.
L'en-tête du fichier contient trois éléments, tous obligatoires :
la date et heure de constitution du fichier.
l'identification du tiers avec lequel l'échange se déroule. Dans tous les cas, c'est un
BIC. Pour un fichier entrant, c'est le BIC de l'émetteur et, pour un fichier sortant,
c'est celui du destinataire.
le nombre de missives contenues dans le fichier.
Si le nombre de missives effectivement présentes après l'en-tête du fichier est différent de
celui indiqué dans l'en-tête, une erreur protocolaire sera déclenchée, aucune des missives ne
sera traitée, et elles feront toutes l'objet d'un acquittement négatif.
Un fichier non conforme à la norme ou au schéma peut être purement et simplement ignoré : aucun
acquittement protocolaire, au niveau fichier, n'existe dans ce canal. Comme pour les autres
SEPAmailNorme1206–ÉditiondeJuin2015 Page18
canaux, l'expéditeur qui ne reçoit pas les missives d'acquittement correspondant à ses missives
nominales doit prendre en charge leur renvoi.
Utilisationducanalfichiers
L'organisation du canal fichiers et ses détails précis sont laissés à l'initiative de l'éditeur
de solutions SEPAmail, notamment en ce qui concerne :
les noms des fichiers
les emplacements où ils se trouvent
la fréquence de leur intégration et/ou de leur production
l'obligation ou non de produire un fichier si aucun élément ne doit être transmis.
Exempledefonctionnement
À titre d'exemple, nous décrivons ici un mode de fonctionnement de ce canal adopté lors de
l'une des expérimentations, avec l'une des implémentations de SEPAmail :
Chaque tiers souhaitant utiliser un connecteur fichiers dispose d'un répertoire spécifique pour
ses échanges de fichiers. Ce répertoire comportera deux sous-répertoires, l'un pour les
fichiers entrants et l'autre pour les fichiers sortants, afin de séparer clairement les deux
flux.
Le nom des fichiers sera de la forme <date><heure>_<BIC>.<application>.<direction>.xml
<date> est la date de création sous la forme aaaammjj
<heure> est l'heure de création sous la forme HHMM
<BIC> est le BIC de l'émetteur ou du destinataire, selon les cas
<application> est l'application associée aux messages contenus dans ce fichier, par
exemple gemme, rubis, test ... Elle peut également prendre la valeur ALL si le fichier
contient des messages destinés à (ou provenant de) plusieurs applications.
<direction> peut prendre deux valeurs :
1. in si le fichier est entrant dans SEPAmail, donc produit par un tiers
2. out s'il est produit par SEPAmail, donc à destination d'un tiers.
Un fichier peut contenir un nombre quelconque de missives, y compris 0. Il sera donc composé
d'un en-tête, puis d'un nombre quelconque de missives, de type Missive.
Il est recommandé que la date de création figurant dans l'en-tête du fichier corresponde au nom
du fichier lui-même, mais ceci n'est pas obligatoire.
Le système SEPAmail vérifiera le contenu du sous-répertoire des fichiers entrants toutes les
heures, à 5 minutes après l'heure juste. Il produira ensuite un fichier dans le répertoire des
fichiers sortants, contenant toutes les missives disponibles pour ce destinataire à ce moment.
Ce fichier sera disponible chaque heure, au plus tard 35 minutes après l'heure juste. Un
fichier devra être généré à chaque heure, aussi bien par le système SEPAmail que par le tiers,
et ce, même s'il n'y a aucune missive à transmettre.
Chaque partie a la responsabilité de supprimer ou d'archiver les fichiers après traitement.
SEPAmail archivera les fichiers entrants, et le tiers gèrera les fichiers sortants. En tout
état de cause, un fichier datant de plus de quatorze jours pourra être purement et simplement
supprimé par SEPAmail, afin d'éviter l'engorgement du système.
SEPAmailNorme1206–ÉditiondeJuin2015 Page19
SEPAmailNorme1206–ÉditiondeJuin2015 Page20
2.3. Spécificationdel'échangedesenveloppesSEPAmailAu sein du réseau des adhérents SEPAmail, il est nécessaire de pouvoir simplement échanger des
enveloppes SEPAmail. Ces enveloppes se concrétisent sous la forme de composants S/MIME, au sein
d'un message SMTP. Ce document spécifie techniquement comment cet échange se réalise.
Résumé
L'enveloppe SEPAmail (enveloppe SMTP au format S/MIME contenant une missive SEPAmail et une
signature de cette missive) est prise en charge en émission et en réception par un automate
qui, selon le protocole de communication retenu :
assure l'échange de cette enveloppe dans le cas de SMTP (jeu de commande du protocole
d'échange SMTP)
assure l'échange de cette enveloppe dans le cas de HTTPS de deux manières possibles :
1. en l'insérant dans le corps d'une requête POST envoyée sur la ressource https://bic.sepamail.eu/ecosystem/receive-envelope-smtp et attendant une réponse
200 ou 204
2. en l'envoyant via un service web SOAP (url https://bic.sepamail.eu/ecosystem/soap à l'aide d'une méthode sendMissive)
Spécificationstechniques
L'architecture
L'échange des enveloppes se fait sur le réseau Internet avec la famille de protocole TCP/IP.
Il
n'est pas prévu de réseau de secours dans la phase expérimentale (aucun paiement ne transite
par SEPAmail, c'est juste un réseau d'échange d'information du même niveau que la messagerie
électronique).
Deux protocoles d'échange sont retenus : HTTP et SMTP.
Le routage et l'adressage se font par les protocoles IP et DNS.
Le transport est assuré par TCP (UDP pour DNS).
SEPAmailNorme1206–ÉditiondeJuin2015 Page21
L'adressage
Chacun des systèmes d'information définit une adresse DNS dans le registre du domaine
sepamail.eu, géré par le Scheme, avec plusieurs enregistrements A, CNAME et MX.
Supposons que l'adhérent bancaire ait plusieurs BIC pour un même système d'information.
Alors, il décidera du BIC principal (BICp) et tous les autres BICs seront considérés comme
secondaires (BICs). Seront définis alors les champs suivants :
Liste des enregistrements à définir dans le registre de SEPAmail.eu
FQDN TTL Type Classe RData F/O
BICp.sepamail.eu 86400 A IN IP1 publique SI O
BICp.sepamail.eu 86400 MX 10 IN BICp.sepamail.eu O
Pour chacun des BIC secondaires
BICs.sepamail.eu 86400 CNAME IN BICp.sepamail.eu F
BICs.sepamail.eu 86400 MX 10 IN BICp.sepamail.eu F
La classe est celle d'internet (IN), le TTL conseillé par défaut est 86400 secondes (24
heures).
Les seuls enregistrements obligatoires sont
le RR (resource record) de type A pour le BIC principal,
le RR (resource record) de type MX pour le BIC principal.
Remarque : il peut y avoir plusieurs enregistrements A ou MX pour un même FQDN afin de mettre
en œuvre une répartition de charge sur plusieurs IP.
Les BICS secondaires sont déclarés comme des alias du BIC principal.
L'enregistrement du service de messagerie est obligatoire. Il pointe usuellement sur le RR de
type A du BIC principal mais l'adhérent SEPAmail peut aussi implémenter une liste de MX
externes pour répartir la charge entre plusieurs serveurs externes au domaine sepamail.eu.
Remarque : il faut qu'un service dédié du Scheme local (QXOO) s'occupe de l'aspect DNS.
L'authentification
Il y a plusieurs authentifications. La compréhension du concept est généralement mal partagée
par les parties devant le mettre en œuvre.
On parle ici de l'authentification du SYSTEME SEPAmail des deux SI pour échanger les enveloppes
SEPAmail.
Les principes de l'authentification, quel que soit le protocole d'échange utilisé, sont :
il n'y a pas de mots de passe transitant sur le réseau, même chiffrés,
l'authentification est fondée sur un échange pair à pair préalable de clé
cryptographique entre les parties,
il existe une procédure de révocation pair à pair ou centralisée permettant de s'assurer
qu'aucune clé révoquée n'est utilisée.
SEPAmailNorme1206–ÉditiondeJuin2015 Page22
Les clés utilisées pour l'échange de missives (échange HTTPS) ne sont pas les mêmes que
pour la signature des missives et le chiffrement des missives au sein de l'enveloppe
SEPAmail.
On peut utiliser HTTPS, et, dans ce cas, c'est avec TLS en version supérieure ou égale à la
version 1.23 (ou SSL version supérieure ou égale à la version 3.3).
L’échangeavecSMTP
Le transport se fait entre deux serveurs MTA implémentant SMTP.
La missive est alors forcément chiffrée car ce protocole fait transiter les trames en clair.
On a donc les règles suivantes :
la missive transportée via SMTP est toujours chiffrée,
les MTAs sont paramétrés pour respecter les règles de priorité et de délai de
l'acheminement,
L’échangeavecHTTPS
Le transport se fait entre deux serveurs qui implémentent HTTP dans sa version au-dessus de TLS
(HTTPS).
Le certificat utilisé pour la couche TLS n'est pas l'un de ceux utilisés pour chiffrer et
signer les missives SEPAmail.
Il faut alors mettre en place une mécanique applicative du même ordre que celle offerte par les
MTAs (envoi, accusé de réception, file d'attente etc...), ce qui peut être fait par un
protocole de type RPC comme SOAP ou un style d'architecture comme REST.
On a donc les règles suivantes :
l'authentification des serveurs entre eux utilise HTTPS
le certificat utilisé pour HTTPS n'est pas un des certificats utilisés par SEPAmail pour
chiffrer/signer les missives.
L’échangeavecHTTP
Le transport peut aussi se réaliser entre deux serveurs implémentant HTTP sans couche TLS. La
missive est alors forcément chiffrée au sein de son enveloppe SMTP/S-MIME, comme pour l'échange
avec SMTP.
Il faut alors mettre en place une mécanique applicative du même ordre que celle offerte par les
MTAs (envoi, accusé de réception, file d'attente etc...), ce qui peut être fait par un
protocole de type RPC comme SOAP ou un style d'architecture comme REST.
Échangedel'enveloppeSEPAmailavecunemécaniquesimple
Le principe est de :
insérer l'enveloppe SEPAmail (enveloppe SMTP S/MIME)
dans le corps (BODY et non entête HEADERS) d'une requête HTTP (version > 1.1)
méthode POST
sur la ressource https://bic.sepamail.eu/ecosystem/receive-envelope-smtp.
La réponse est alors soit :
une réponse 204 (pas de contenu)
SEPAmailNorme1206–ÉditiondeJuin2015 Page23
à défaut une réponse 200 (OK) si l'automate ne sait pas implémenter une réponse 204
La ressource est spécifique à ecosystem (équivalent de l'échange SMTP sur une adresse de
courriel [email protected]). Elle précise la méthode de réception de l'enveloppe SMTP
en la nommant explicitement receive-envelope-smtp.
Charge à l'automate de distribuer l'enveloppe dans la boite de courriel
[email protected] pour le traitement SEPAmail.
Échangedel'enveloppeSEPAmailavecunecoucheSOAP
Le principe est d'utiliser le protocole SOAP (version supérieure ou égale à 1.24) qui n'est pas
un protocole de la famille internet pour s'abstraire des parties authentification/échange
d'information.
Cette couche est plus utile dans le cadre intrabancaire pour partager avec des systèmes
d'information de clients des méthodes sur des objets SEPAmail défini dans le SI de la banque.
Dans le cas d'un échange via SOAP, alors :
le service web SOAP est appelé sur l'url
https://bic.sepamail.eu/ecosystem/soap
à l'aide d'une méthode sendMissive
avec comme arguments :
1. les paramètres d'authentification
2. la missive à envoyer
Charge à l'automate de distribuer l'enveloppe dans la boite de courriel
[email protected] pour le traitement SEPAmail.
Notesd'architecture
Les notes qui suivent n'ont pas de valeur normative. Elles sont fournies à titre de précisions
sur les choix techniques et éventuellement d'aide à l'implémentation.
Lagestiondesfilesd'attentes
Les MTAs implémentent naturellement un système de files d'attente et d'espaces utilisateurs
(les boites de courriels).
Avec le besoin d'antispam et d'antivirus, la plupart des MTAs ont implémenté une architecture
en couches avec des files d'attentes et des agents indépendants.
Le traitement des files d'attentes se fait donc indépendamment les unes des autres et ce modèle
permet de répartir sur plusieurs architectures les fonctions différentes (notamment l'antispam,
l'antivirus) et gérer de façon différenciée le trafic interne au SI et avec l'extérieur.
Lagestiondelacharge
La gestion de la charge ne se gère pas de la même façon avec un protocole de type web-service
et avec un protocole de type SMTP pour une raison principale :
le protocole SMTP est construit autour d'une distribution « au mieux » et non immédiate
le protocole HTTP est construit pour servir de façon quasi-immédiate l'information et ne
permet pas simplement la gestion de file d'attente sur un canal (voir paragraphe
précédent)
Dans le réseau interbancaire, le nombre d'adhérents va être faible et le service symétrique. La
gestion de la charge devrait pouvoir se réguler assez facilement quel que soit le protocole
utilisé.
SEPAmailNorme1206–ÉditiondeJuin2015 Page24
2.4. Lesmécanismesd'identificationLeBICetl’IBAN
La problématique de l’adressage dans une messagerie repose sur le partage des identifiants.
SEPAmail a apporté une double réponse, non dans une approche technique, mais dans une vision
métier :
La messagerie étant plutôt pour une sécurisation au travers de banques, le BIC est
l’identifiant du ‘‘fournisseur d’accès SEPAmail’’
L’identifiant du client de la banque peut être choisi parmi plusieurs (numéro de
compte, numéro de carte, identifiant dédié banque en ligne) mais la proximité du SEPA et
la promesse de services autour des paiements rendent le choix de l’IBAN, paneuropéen,
une évidence.
Même si le sigle IBAN@BIC est utilisé, il ne correspond qu’à une vue métier et non à une vue
technique. Du point de vue métier :
Le BIC, identifiant des banques, n’est pas sensible et donc circule en clair
l’IBAN, identifiant des clients, est par nature une donnée sensible et doit être
protégée. Il ne peut donc circuler que sous un format confidentiel
LeBIC:descontraintespourlesclients
De plus, la première expérimentation avec SFR a mis en évidence :
le créancier peut facilement retrouver l'IBAN à partir du numéro de compte client (BBAN
en anglais), par un algorithme connu
le créancier ne dispose pas de moyen fiable de trouver un BIC.
Prenant en compte la réalité du terrain, anticipant aussi la pression réglementaire et
projetant la norme SEPAmail dans une utilisation client-banque, SEPAmail a proposé de ne pas
obliger le client à fournir de BIC mais uniquement un IBAN, charge à la banque SEPAmail de
fournir l'enrichissement.
Uneidentificationnonfigée
Dès le début de SEPAmail, les standards et la mise en œuvre se sont attachés à ne pas
solidifier l’usage du BIC et de l’IBAN pour être en mesure d’utiliser d’autres types
d’identification pouvant répondre à des besoins complémentaires à ceux du SEPA. En effet dans
le SEPA, l'utilisation de l’IBAN ne couvre que les paiements par virement ou prélèvement.
De manière plus générale, toute identification de type identifiant@bic peut devenir
intéressante pour SEPAmail. Cette caractéristique, couplée à la notion précédente
d'enrichissement, permet de proposer toute une gamme d'identifiant dans SEPAmail.
IdentificationparPAN:PrimaryAccountNumber,outoutsimplementnumérodecartebancaire
Le numéro de carte est un identifiant au moins aussi, voire plus, connu que l'IBAN. Il a aussi
l'avantage d'être souvent présent avec le client, le porteur de carte, plus que le Relevé d'identité bancaire !
Le PAN peut être facilement utilisé pour :
SEPAmailNorme1206–ÉditiondeJuin2015 Page25
identifier le BIN (bank identification number) à partir du PAN. Dans la plupart des cas,
prendre les 6 premiers caractères suffit
associer le BIC au BIN : ceci se fait à partir du fichier des établissements géré par Cartes Bancaires ou par d'autres organismes pour d'autres places européennes
formater les envois SEPAmail avec
1. le BIC et le PAN, ce dernier remplaçant l'IBAN pour identifier le client destinataire
2. le BIC et l'IBAN pour le client émetteur de l'envoi
associer, au niveau de la banque destinataire de l'envoi, le PAN avec soit l'IBAN soit
le compte référence du client. Par définition, tout émetteur de carte sait associer un
numéro de carte avec un numéro de compte, ne serait-ce que pour débiter son client !
L'utilisation du PAN pourrait servir à une extension des avis de paiement aux paiements
monétiques : JADE pour la monétique !
QXBAN:uneidentificationSEPAmail
Même si l'IBAN devient couramment utilisé, il pose un souci de sécurité car c'est un élément
sensible du client. Il peut être utilisé par certains fraudeurs, soit comme mode
d'identification auprès d'un centre d'appel peu regardant sur les procédures
d'authentification, soit pour générer des prélèvements y compris sans mandats préalables.
Dans le cadre de l'expérimentation RUBIS et de l'expérimentation SAPPHIRE, il est apparu les
contraintes suivantes :
il n'est pas acceptable de donner directement l'IBAN au créancier
1. il est difficile de promouvoir l'IBAN pour les clients dont le souci principal reste la communication de l'IBAN et donc qui continuent avec le chèque (car le
prélèvement nécessite de communiquer l'IBAN)
2. il apparaît une augmentation de la sensibilité des bases de données « créanciers » dès lors que l'on y ajoute des numéros IBAN
il n'est pas pratique d'échanger un IBAN entre 2 personnes.
SEPAmail a donc créé le QXBAN :
un format d'IBAN (ou presque) pour rester compatible avec les développements et normes
SEPAmail
une utilisation interdite en compensation, donc pas de prélèvements possibles
une utilisation peu ergonomique (grand nombre de caractères) pour éviter une utilisation
dans des procédures d'authentification
une utilisation réservée au réseau SEPAmail
Le format du QXBAN suit presque la norme des IBAN avec quelques spécificités :
le country code est QX ce qui est le seul NON RESPECT de la norme des IBAN. Le code pays
QX n'existant pas, il ne peut y avoir de compensation avec un tel code.
le code banque DOIT être le BIC de la banque, ou tout du moins celui de routage SEPAmail
des flux
SEP
Il e
à pr
Il e
DOC.
Le R
form
Il n
RIS2
AmailNorm
le numé
client
le numé
du QXBA
est bien e
révoir la
Relevé
est apparu
. Ceci a c
la logi
SEPAmai
la maté
lecture
RIS2D repr
mat 2D-DOC
n'est pas
2D.
me1206–Éd
éro de comp
éro de comp
AN.
ntendu que
correspond
d'identitéS
une syner
onduit à d
ique de rel
il"
érialisatio
e qu'au vu
end les in
.
prévu de r
ditiondeJui
pte DOIT ê
pte DOIT u
e la banque
dance inter
SEPAmail:
rgie intére
définir la
levé de co
on sous fo
du nombre
nformations
représentat
in2015
tre un tir
tiliser la
e qui a émi
rne entre l
RIS2D
essante des
notion de
mpte banca
rme de cod
de donnée
s de NOM, P
tion du Re
rage aléato
a longueur
is un QXBAN
le QXBAN e
s travaux
RIS2D ou r
aire mais a
de-à-barre
es à gérer.
PRENOM, QXB
levé d'Ide
oire sous l
maximale p
N s'engage
t l'IBAN d
sur le QXB
relevé d'i
adapté à l'
2D tant po
BAN et une
entité SEPA
la responsa
pour augmen
à traiter
u client.
AN et des
dentité SE
identifica
our une sim
signature
Amail hors
abilité de
nter le ni
r sa récept
travaux du
EPAmail rep
ation d'un
mplificati
e de ces do
de celle
Pag
e la banque
veau d'alé
tion, et do
u projet 2D
prenant :
n "compte
on de la
onnées au
en format
ge26
e du
éa
onc
D-
SEP
Le f
Le s
paie
AmailNorm
format int
les éto
un débu
Protect
schéma sui
ement par
me1206–Éd
ègre, outr
oiles appor
ut de menti
tiondeside
vant montr
virement e
ditiondeJui
re le code-
rtant un r
ion du pré
entifiantsp
re comment
et donc de
in2015
-à-barre :
appel du l
nom et du
ourlepaiem
il est pos
protéger c
logo SEPAMA
nom en cla
mentparv
ssible d'é
cette donn
AIL
air pour po
virement
viter de c
ée sensibl
ouvoir s'y
ommuniquer
e.
retrouver
r son IBAN
Pag
r.
pour le
ge27
SEP
Le p
créa
perm
réfé
AmailNorm
1. À l'insla base
2. le clieimage f
prénom
3. le créaexclusi
4. la banq{QXBAN-
passage
banque
5. le flux
6. le virede la b
d'ordre
Protect
prélèvemen
ancier. Un
mettre de
érence uni
me1206–Éd
scription d
e de donnée
ent a ainsi
facilement
(puce 2)
ancier peut
ivement le
que recevan
->IBAN} (pu
e que le co
offre ce s
x de retour
ement utili
banque du c
e à un béné
tiondeside
t pose une
e utilisat
s'affranch
que de man
ditiondeJui
de son cli
es {QXBAN-
i donc tou
lisible e
t démarrer
QXBAN de
nt la dema
uce 4) et
ompte qui
service.
r (flux ro
ise l'IBAN
créancier
éficiaire.
entifiantsp
e problémat
tion des id
hir de cett
ndat (RUM)
in2015
ent au ser
>IBAN} et
t le loisi
t dont le
la séquen
son client
nde peut i
proposer l
sera débit
uge) se fa
du donneu
car celle-
ourlepaiem
tique certa
dentifiants
te contrain
que l'on p
rvice, la b
le remet à
ir de mettr
créancier
nce de demat (flux ble
identifier
le service
té peut êtr
ait en util
ur d'ordre.
-ci n'a pas
mentparp
aine du fa
s (RIS2D-QX
nte. En ef
peut mettr
banque du c
à son clien
re à dispos
peut extra
ande de règeu)
son client
de validat
re un compt
lisant le Q
Cependant
s le droit
prélèvemen
it de l'ob
XBAN) et d
fet la nor
e à profit
client génè
nt sous for
sition du c
aire le QXB
glement en
t grâce à s
tion à son
te quelconq
QXBAN du c
t cet IBAN
de remettr
nt
ligation d
es flux SE
me SEPA DI
.
ère le QXB
rme de RIS
créancier
BAN, le no
utilisant
sa base de
client. N
que de ce
lient débi
reste dan
re l'IBAN
de donner s
EPAmail pou
IRECT DEBIT
Pag
BAN, mainti
S2D (puce 1
ce fichier
om et le
e données
Notons au
client si
teur
ns l'encein
du donneur
son IBAN au
urrait
T impose un
ge28
ient
1)
r
la
nte
r
u
ne
SEP
Ains
prot
De p
créa
AmailNorm
1. comme p1)
2. le cliepaiemen
ce mode
3. le créaQXBAN e
4. la banqfait ch
mandat
parallè
validit
5. la banqà son c
6. il sufffichier
7. la banq{créanc
si les ide
tection de
plus le mé
ancier. Ce
me1206–Éd
précédemmen
ent débiteu
nt par prél
e de paieme
ancier génè
et la RUM,
que du débi
hoisir le c
de prélève
èle, la ban
té.
que du créa
client créa
fira au cré
rs d'initia
que du créa
cier/RUM ->
ntifiants
s clients
canisme pr
lui-ci peu
ditiondeJui
nt, la ban
ur donne s
lèvement.
ent.
ère une de
référence
iteur iden
compte de
ement acce
nque du dé
ancier con
ancier que
éancier de
ation de p
ancier com
> IBAN} et
sensibles
et une plu
récédent ne
ut changer
in2015
que du déb
on RIS2D o
Notons au
mande de m
unique du
tifie son
prélèvemen
pté par so
biteur mém
stitue une
le mandat
fournir l
rélèvement
plète la R
émet en c
(IBAN) res
us grande s
e crée pas
de banque
biteur a gé
ou son QXBA
passage qu
mandat avec
u mandat (f
client grâ
nt désiré p
on client e
morise les
e base de d
t est accep
la RUM comm
t (flux noi
RUM avec l'
compensatio
stent dans
simplicité
de lien f
assez simp
énéré et mi
AN au créan
ue cela pou
c le servic
flux bleu)
âce à la ba
par son cli
et avec le
RUM accept
données {cr
pté
me identifi
ir)
IBAN trouv
on.
les encei
de gestio
ort entre
plement :
is à dispos
ncier tout
urrait pous
ce GEMME@SE
ase de donn
ient et ren
véritable
tées par so
réancier/RU
iant de pa
vé dans la
ntes banca
n par le c
la banque
sition un
en demand
sser plus
EPAMAIL en
nées {QXBA
nvoie (flu
IBAN du c
on client
UM -> IBAN
iement dan
base de d
aires pour
créancier.
du créanci
Pag
RIS2D (puc
dant un
de clients
n utilisant
AN->IBAN},
ux rouge) l
client. En
et en gère
N} et indiq
ns ses
données
une meille
ier et le
ge29
ce
s à
t le
le
e la
que
eure
SEP
l'IC
l'IC
AmailNorm
1. le créapar sa
2. la banqdébiteu
3. la nouvpourra
ICQX
CQX est un
CQX est dé
me1206–Éd
ancier envo
nouvelle b
que du débi
ur puisque
velle banqu
ainsi comp
identifia
rivée de c
ditiondeJui
oie des av
banque
iteur peut
nous somm
ue du créa
pléter les
ant des per
celle de l'
in2015
enants de
répondre
es dans le
ncier cons
flux de p
rsonnes mor
ICS.
mandats en
immédiatem
e cas d'un
stitue la b
prélèvement
rales part
n utilisant
ment sans v
amendement
base de don
ts
icipant à
t le couple
validation
t
nnées {créa
SEPAmail.
e QXBAN/RU
nécessair
ancier/RUM
La normali
Pag
UM en passa
re par le
M -> IBAN}
isation de
ge30
ant
et
SEPAmailNorme1206–ÉditiondeJuin2015 Page31
2.5. ICQXL'ICQX est l'identifiant unique d'un créancier personne morale dans le réseau SEPAmail. Cet
identifiant est géré par le SCHEME. Il est unique pour une entité économique et pérenne.
Il n'est pas nécessaire qu'un créancier dispose d'un identifiant ICS pour obtenir un ICQX.
Principes
Les ICQX sont destinés à gérer le référentiel des créanciers des différents services de
SEPAmail, icqx@scheme.
La base des ICQX est gérée par le Scheme Manager SEPAmail, qui attribue donc les ICQX à sa
seule discrétion.
L’ICQX repose sur la norme définie dans SEPA pour l’ICS
Le code pays est celui du RIS : QX
Les 2 premiers caractères du Business code de l’ICS sont utilisés pour le code pays du
créancier
Pour les créanciers de test ces 2 premiers caractères seront positionnés à QX
Le troisième caractère du Business code est au libre choix du créancier. Il est mis à Z
par défaut
Structure
L’ICQX est un champ pouvant contenir jusqu'à 35 caractères alphanumériques comprenant :
Positions 1 et 2 : les caractères « QX »
Positions 3 et 4 : deux chiffres : clé de contrôle (ISO7064)
Positions 5 et 6 : deux lettres majuscules
1. Soit le code pays du QXOO local : « FR » pour la France
2. Soit QX dans le cas des ICQX de test
Position 7 : un caractère alphanumérique
1. « Z » par défaut quand l’ICQX est attribué par le QXOO (ou local OO)
2. Caractère à la discrétion du créancier : il peut donc changer ce caractère suivant le message
Positions 8 à 35 (aussi appelé « identificateur ») : la constitution de ces 28
caractères est à la discrétion du QXOO (ou local OO)
Références
SMIRK le référentiel icqx@scheme
SEP
Un R
data
Voic
Le c
Les
Voic
AmailNorm
2.6. Présent
RIS2D (Rel
amatrix5 co
nom,
prénom,
identif
date d'
ci un exem
Contenu
contenu du
champs su
bloc d'
08 - da
30 - qu
des /
31 - co
bloc si
Exempl
ci un exem
en-tête
1.
2.
3.
4.
données
1.
2.
me1206–Éd
RIS2Dtation
evé d'Iden
ontenant de
fiant QXBAN
expiration
ple de RIS
u
RIS2D est
ivants de
en-tête, a
ate d'expir
ualité, nom
ode IBAN, q
ignature
le
ple de con
e
autorité é
pas de dat
date de si
type de do
s
date d'exp
propriétai
ditiondeJui
ntité SEPAm
es données
N,
n
S2D
t conforme
2D-DOC son
avec un co
ration
m et préno
qui contie
ntenu de RI
émettrice :
te d'émissi
ignature :
ocument : 0
piration :
ire : M. Gi
in2015
mail 2D) es
propres à
à la norme
nt obligato
de d'ident
m dans l'o
ndra le QX
IS2D :
: FR99
ion
26/09/2012
05, RIS2D
26/09/2013
illes Montp
st une ima
à l'utilisa
e 2D-DOC d
oires pour
tification
ordre quali
XBAN
2 (4652 jo
3 (5017 jo
parnasse
ge de type
ateur de SE
isponible
le RIS2D
de documen
ité/nom/pré
urs, soit
urs, soit
code barr
EPAmail:
sur le sit
:
nt à 05
énom, en sé
122C hex,
1399 hex)
re 2D au fo
te de l'ANT
éparant le
depuis le
Pag
ormat
TS.
es champs p
01/01/2000
ge32
par
0)
SEPAmailNorme1206–ÉditiondeJuin2015 Page33
3. QXBAN : QX97CEPAFRPP751AZX25TR1234567890AA
La chaîne 2D-DOC correspondante sera la suivante (en ignorant le padding, l'encodage et la
signature) :
DC01FR991204FFFF122C05 08139930M/MONTPARNASSE/GILLES<GS>31QX97CEPAFRPP751AZX25TR1234567890AA
Notez que le saut de ligne dans la chaîne ci-dessus n'est présent que pour indiquer la
séparation entre l'en-tête et les données, il devrait être absent en réalité.
SEP
Réfé
On p
L'av
AmailNorm
2.7. Aférence : sp
un code
une clé
EBS 204
un BIC
(avec l
un iden
aléatoi
propose la
tirage
générat
vérific
si non
si oui
alerte
si oui
du réfé
vantage de
le coût
l'alert
me1206–Éd
Algoritspécificati
e QX (2 car
é de contrô
4 du CFONB
sur 11 car
le modèle
ntifiant in
irement
séquence
aléatoire
tion des QX
cation si l
pour au mo
pour les t
de densité
pour deux
érentiel sa
cette séq
t en temps
te de densi
ditiondeJui
thmedions CYV 20
ractères)
ôle (2 car6)
ractères,
[A-Z]{6}[A
nterne au
fonctionne
(loi unif
XBANs équi
les QXBAN
oins un, a
trois, alo
é à l'admi
d'entre e
ans except
quence est
est fixe
ité est bi
in2015
egénér010. Le QXB
actères),
complété a
-Z0-9]{5})
BIC sur 19
elle suivan
orme) de t
valents, a
ainsi géné
lors on pr
rs on génè
nistrateur
ux, on gén
ion sur la
que :
quel que s
en prévue
rationBAN est un
selon le c
avec des le
9 caractère
nte pour l
trois nombr
avec calcul
érés existe
rend ce QXB
ère une exc
r du référe
nère une si
a génératio
soit le tir
dès le dép
duQXBcode de 3
calcul de c
ettres X s'
es (avec le
e tirage :
res
l de la clé
ent déjà
BAN
ception sur
entiel
imple alert
on
rage
part pour l
BAN4 caractèr
clé de cont
il ne fait
e modèle [A
é de contrô
r la généra
te de dens
l'administr
res composé
trôle de l
t que 8 ca
A-Z0-9]{19
ôle
ation du Q
ité à l'ad
rateur du
Pag
é de :
'IBAN (gui
aractères
9}), tiré
QXBAN et un
dministrate
référentie
ge34
ide
ne
eur
el
SEP
Du p
vue
dev
Dans
iden
Néan
et «
ayan
Les
Pour
inte
AmailNorm
2.8. L'émett
point de v
métier, l
ient le de
s les prem
ntifiants
nmoins pou
« destinatnt un doub
échanges
une ini
la tran
cette t
la mise
par cet
la vali
règles
Une foi
report,
Princip
r assurer
erbancaire
me1206–Éd
Lavisioteuretlede
ue techniq
'envoi est
stinataire
iers servi
métiers :
r une prés
taire initile sens.
métiers se
itialisatio
nsmission d
transmissio
e à disposi
tte banque
idation par
d'authenti
is la valid
payment-r
pesd’acquit
le bon fon
(missive
ditiondeJui
onmétestinataire
que, il y a
t surtout i
e de la rép
ices envisa
créancier,
sentation g
ial » en li
e structure
on d'un en
de l'envoi
on est nom
ition par
r le desti
ification
dation eff
report,...
ttement
nctionnemen
nominale)
in2015
tier
a bien un é
important p
ponse.
agés, il se
débiteur,
générale, n
ieu et plac
ent donc su
voi réalis
vers la b
mée REQUES
la banque
nataire in
peuvent êt
ectuée et
)
nt de la me
doit faire
émetteur d
pour sa ré
era donc t
, donneur
nous utili
ce des expr
uivant le
sée par l'é
banque du d
ST (payment
du destina
nitial. Au
tre adaptée
contrôlée,
essagerie
e l'objet p
e l'envoi
ponse. De
oujours pr
d'ordre, b
serons les
ressions «
schéma pré
émetteur in
destinatair
t-request,
ataire, sui
même titre
es au servi
la répons
à un nivea
par la ban
et un dest
ce fait, l
éféré l'ut
énéficiair
expressio
émetteur
cédent :
nitial
re. Dans la
mandate-re
ivant le ou
e que pour
ice sous-ja
se est nomm
u métier, que du des
tinataire.
l'émetteur
tilisation
re.
ons « émett» et « des
a structur
equest,...
u les cana
l'initial
acent.
mée REPORT
chaque env
stinataire
Pag
Du point d
de l'envo
des
teur initiastinataire
re SEPAmail
)
aux proposé
isation, l
T (mandate-
voi
d'une miss
ge35
de
i
ial » »
l,
és
les
-
sive
SEP
d'ac
les
tran
La m
Il n
la m
cana
SEPA
déma
De c
AmailNorm
cquittemen
données m
nsportant
missive d’
n'y a aucu
missive no
al SMTP po
Princip
Amail étan
arrent le
ce constat
niveau
(inform
niveau
si la b
me1206–Éd
t. Celle-c
étiers. Ce
un message
acquittem
une obligat
ominale. En
ur toutes
pesdedesse
t une init
même jour,
, il est i
global par
mation qui
transactio
banque est
ditiondeJui
ci peut com
es dernière
e de type R
ment n'est
tion que la
n particuli
les missiv
erte(reach
tiative pri
et ceci à
important q
r informat
sera orga
on en mett
desservie
in2015
mporter des
es sont cen
REPORT.
pas acquit
a missive
ier, il est
ves d'acqui
ability)
ivée, il n'
à chaque no
que la banq
ion qu'un
nisée au n
ant à disp
.
s éléments
nsées fair
ttée.
d'acquitte
t tout à f
ittement.
'est pas en
ouvelle ap
que de l'ém
réseau ban
niveau de l
position un
sur le ni
e l'objet
ement passe
fait possib
nvisageabl
plication
metteur gè
ncaire dest
la structur
ne réponse
veau de se
d'une miss
e par le mê
ble d'utili
e que tous
ou nouvell
re la dess
tinataire a
re de gouve
intermédia
ervice mais
sive nomina
ême canal
iser unique
s les acteu
le évolutio
serte à 2 n
a ouvert l
ernance)
aire (puce
Pag
s doit évit
ale
d'échange
ement le
urs adhéren
on.
niveaux :
e service
e 2) indiqu
ge36
ter
que
nts
uant
SEP
La b
comp
Il e
règl
AmailNorm
banque de
plémentair
recevoi
répondr
stocker
automat
le rése
est éviden
lement ont
me1206–Éd
l'émetteur
e. Dans le
ir l'ensemb
re suivant
r les manda
tiser l'env
eau SEPAmai
t qu'un te
une pério
ditiondeJui
r peut prof
e cadre de
ble des fl
que le ma
ats non de
voi ultéri
il
el service
ode d'utili
in2015
fiter de ce
l'expérime
ux de mand
ndat est t
sservis
eur de ces
n'est pas
isation réd
ette gesti
entation GE
dats,
transmis ou
s stocks ch
très util
duite.
on de la d
EMME, le s
u non (banq
haque fois
e dans le
esserte po
ervice con
que non des
qu'une nou
cas de RUB
our offrir
nsiste à :
sservie)
uvelle ban
BIS dont le
Pag
un service
nque rejoin
es demandes
ge37
e
ndra
s de
SEPAmailNorme1206–ÉditiondeJuin2015 Page38
3. Lasécurité
SEPAmailNorme1206–ÉditiondeJuin2015 Page39
3.1. PrincipesdesécuritéIl y a plusieurs principes de sécurité au sein de SEPAmail.
Indépendance des espaces de sécurité
1. client - banque / banque – banque / banque – client
2. chaque articulation entre espaces de sécurité passe par un membre adhérent à l’espace (banque)
Authentification
1. les missives SEPAmail sont obligatoirement signées en S/MIME (utilisation de chiffrement avec une clé secrète de l’expéditeur de la missive), ce qui assure
l'authentification de l'expéditeur de la missive et l'intégrité de cette dernière
2. les messages SEPAmail peuvent être signés par l'émetteur du message et cette signature est transportée jusqu'au destinataire, ce qui assure l'authentification
de l'émetteur du message
Signature numérique
1. la signature numérique (appelée aussi cachet électronique) est possible pour le message en harmonisant les règles communes à respecter au sein du réseau des
adhérents SEPAmail. Ce sujet est traité par le protocole SAPPhire.
Confidentialité
1. la confidentialité est obtenue par chiffrement des missives avec la clé publique S/MIME du destinataire.
Traçabilité
1. Tous les éléments doivent être suivis, et doivent pouvoir être produits à titre de preuve
2. ils doivent rester associés à leur expéditeur et à leur destinataire, dûment authentifiés
Échange de l'information
1. webservice avec utilisation SSL (HTTPS+SOAP ou HTTPS+REST)
2. SMTP
Signaturedesmessages
La possibilité de signature des messages est prévue par l'incorporation d'un schéma XML de
signature et permet ainsi de communiquer sur une faisabilité de principe.
La mise en œuvre d'une technique de signature des messages va dépendre du type de message et
surtout de comment l'application utilisant le message est contractuellement réalisée :
Mandat GEMME (hors expérimentation) :
1. une signature du message retour pour contrôle indépendant par le créancier peut être un plus, si tant est que le créancier ait les moyens de contrôle de la
signature
2. cependant, un transfert de responsabilité de la banque du créancier à la banque du débiteur peut aussi être utilisé : dans ce cadre, qui serait contractuel entre
banques, la seule réception de la missive signée par la banque du créancier
pourrait suffire. La banque du débiteur s'engageant en cas de différend avec le
créancier.
3. il y aura peut-être les 2 types de flux à terme suivant les besoins des clients.
SEPAmailNorme1206–ÉditiondeJuin2015 Page40
Règlement RUBIS :
1. Pas de nécessité d’avoir une notion de signature au niveau du message de retour :
c’est le virement qui est irrévocable et cela suffit pour la plupart des cas
d'usage.
2. À terme, on peut aussi imaginer que seule une missive signée de la banque suffit car contractuellement celle-ci s’engage devant les autres banques à honorer les
informations de cette missive. Par exemple, le renvoi d'une missive dans laquelle
le message porte une information de garantie du virement engage la banque du débiteur, charge à elle d'avoir bien fait les contrôles avec son débiteur.
Le besoin le plus nécessaire sur la signature des messages sera pour ceux du service JASPE. Ce
point étant en cours d'étude, nous pouvons résumer que la signature des messages n'est pas une
fonction à l'ordre du jour.
Indépendancedesespacesdesécurité
SEPAmail propose de véhiculer l'information le long d'espaces de sécurité indépendants comme
décrit dans le schéma ci-dessous:
Il y a :
l'espace de sécurité entre chacun des adhérents et son client, selon les canaux
existants (DAB/GAB, banque à distance, guichet, centre d'appel, application mobile)
l’espace de sécurité entre les deux adhérents SEPAmail, mis en œuvre tel que défini
dans la norme SEPAmail.
SEPAmailNorme1206–ÉditiondeJuin2015 Page41
3.2. SMIRKCRY1203,lacryptographieCette demande de commentaires (SMIRK pour SEPAmail Internal Request for Komment) spécifie les
règles communes d'utilisation de la cryptographie. Ce SMIRK est un standard de la communauté
SEPAmail, spécifié et maintenu par le scheme SEPAmail.
Introduction
SEPAmail utilise des procédés techniques de cryptographie asymétrique pour assurer:
l'authentification forte des adhérents du réseau SEPAmail,
la confidentialité et l'intégrité de l'information échangée.
Ce document précise les normes utilisées et le cadre de cette utilisation dans le réseau des
adhérents SEPAmail. Une partie annexe décrit l'extension qui peut être fait de la norme dans un
cadre hors-réseau, notamment entre un adhérent et son client.
Avertissement
SEPAmail encadre juridiquement le cadre et la portée:
des transferts sécurisés d'information, qui constituent le dispositif technique
SEPAmail,
des mandats électroniques de chaque membre du réseau pour son propre compte ou celui de
ses clients,
des garanties pour chaque membre du réseau.
Ce cadre juridique ne fait pas partie de ce document. Notamment, la non-répudiation est
contractuelle et juridique dans le cadre de SEPAmail. Elle ne fait donc pas partie des
prérogatives du dispositif technique.
SEP
Pr
SEPA
par
cert
sign
Ce c
AmailNorm
rincipes
SEPAmai
1.
2.
avec de
1.
2.
ainsi q
avec un
Lecerti
Amail util
BIC et pa
tificats e
nature.
certificat
un usag
me1206–Éd
s
il utilise
le contenu
détachée)
cette enve
chiffremen
eux échange
le parcour
un parcour
que les usa
ne signatur
ificatSEPAm
ise deux c
r écosystè
st utilisé
doit prés
ge de la bi
ditiondeJui
la norme
u est inclu
eloppe de s
nt S/MIME
es possibl
rs canoniqu
rs flash ut
ages X509
re incluse
certificats
ème, voir l
é exclusive
senter les
i-clé pour
in2015
S/Mime 7
us dans une
signature e
es entre l
ue utilisan
tilisant un
10 de confi
dans le c
s S/MIME po
la demande
ement pour
caractéris
e envelopp
est elle-m
les adhéren
nt un écha
n échange
dentialité
contenu chi
our chacun
de commen
le chiffr
stiques su
e de signa
ême inclus
nts SEPAmai
nge via le
via un web
é et d'auth
iffré
e des adre
taire auto
ement, l'a
ivantes :
ature S/MIM
e dans une
il :
e protocole
b service 9
hentificati
sses de co
ur de la m
utre exclu
ME opaque
e enveloppe
e SMTP 8
ion (intégr
ourriels ut
missive 11).
usivement p
Pag
(i.e. non-
e de
rité de fa
tilisées (u
L'un des
pour la
ge42
it)
une
SEPAmailNorme1206–ÉditiondeJuin2015 Page43
1. la confidentialité (chiffrement ou encryption)
2. l'authentification (digital signature)
signé par une autorité de certification reconnue
un nom canonique (canonicalname ou CN) à l'adresse de courriel
[ecosystem]@[bic].sepamail.eu
Casduparcourscanonique
Dans le cas du parcours canonique (privilégié), la confidentialité et la signature sont
obligatoires.
Casduparcoursflash
Dans le cas du parcours flash, une négociation de l'échange pair à pair entre les adhérents au
réseau SEPAmail est obligatoire afin de savoir quelles sont les exigences du client et du
serveur en matière :
de protocole d'échange (HTTP, HTTPS)
de politique d'authentification des équipements réseaux (réciproque, unilatérale)
de protocole de web-services (SOAP, REST, autres)
de politique de réponse et de qualité de service (temps de réponse, résultat
désynchronisé ou synchronisé dans la réponse)
SEPAmailNorme1206–ÉditiondeJuin2015 Page44
4. Lanorme
SEP
Chaq
Ains
la f
La v
1202
En r
pour
voir
plus
Il n
de l
norm
norm
On t
la n
Au s
prin
AmailNorm
4.1. Princip
P
que versio
si, la ver
fréquence
version 12
2. En résu
revanche,
rraient se
re les lai
sieurs app
n'y a donc
la norme e
me, ils co
me est le
P
trouve ci-
norme SEPA
sein d'un
ncipaux :
SMART q
coopéra
me1206–Éd
Lanormpesgénérau
Préambule
n de la no
sion 1206
et le cont
06 de la n
mé, on peu
les versio
contenter
sser compl
lications
pas forcé
lle-même :
nserveront
maximum de
Périmètre
dessous so
mail :
adhérent S
qui reçoit
atif inter-
ditiondeJui
meuxdelanor
:numérota
orme est id
date du mo
tenu des ve
norme a cha
ut même con
ons futures
r d'évoluti
lètement in
nouvelles.
ément ident
si ces me
t le même n
es numéros
ous forme g
SEPAmail ba
et émet d
-bancaire)
in2015
rme
ation
dentifiée p
ois de juin
ersions suc
angé beauco
nsidérer qu
s de la nor
ions limité
ntacts -- e
tité entre
essages n'o
numéro de v
des messag
graphique l
ancaire, il
es missive
par un num
n 2012, par
ccessives.
oup de cho
u'elle a t
rme n'auron
ées sur cer
en se cont
les numér
ont pas ch
version. On
ges et de
la représen
l y a quatr
es dans le
éro à 4 ch
r exemple.
ses par ra
out changé
nt pas for
rtains mes
entant par
os de vers
angé depui
n peut dir
la missive
ntation du
re classes
réseau des
iffres, so
Le comité
pport à la
.
cément le
sages ou c
exemple d
ion de tou
s la versi
e que le n
la consti
périmètre
de compos
s adhérents
ous la form
é de coordi
a précédent
même impac
certains éc
d'ajouter u
us les mess
ion précéde
numéro de v
ituant.
e des spéci
sants fonct
s SEPAmail
Pag
me AAMM.
ination règ
te version,
ct. Elles
cosystèmes,
une ou
sages et ce
ente de la
version de
ifications
tionnels
(espace
ge45
gle
,
,
elui
la
de
SEPAmailNorme1206–ÉditiondeJuin2015 Page46
les composants métiers autour du paiement:
1. RUBIS, autour de la demande de règlements qui traite les messages RUBIS (lié à l’écosystème payment.activation)
2. GEMME, autour de la signature de mandats qui traite les messages GEMME (lié à
l’écosystème direct.debit)
3. DIAMOND, autour de la vérification de la domiciliation bancaire qui traite les messages DIAMOND (lié à l’écosystème identification.verification)
un composant métier de sécurité:
1. SAPPHIRE (de façon optionnelle), autour de l'authentification et de l'échange de composants d'authentification, qui traite les messages SAPPHIRE (lié à
l'écosystème secure)
SMILE (de façon optionnelle) qui reçoit et émet des missives dans le réseau des clients
de la banque (espace compétitif intra-bancaire)
Les documents de la norme sont :
les schémas XML et leurs directives d'implémentation
les demandes de commentaires (SMIRK en bleu)
les règles métiers (business rules en vert)
1. RUBIS
2. GEMME
3. DIAMOND
des spécifications techniques et fonctionnelles
1. API SMART (file et web-service)
2. protocoles échanges
3. validation XML
SEPAmailNorme1206–ÉditiondeJuin2015 Page47
4.2. IGGeneralRulesThese rules apply to all messages in SEPAmail.
Acceptablecharacters
As per SEPA rules, the only acceptable characters are as follows:
lower case letters a -z
upper case letters A - Z
digits 0 - 9
special chars / : - ? ( ) . , ' +
space
This is valid for all messages, and it is an absolute rule in all ISO parts.
The"Name"field
Whenever the "Name" (Nm) field is used, it must be filled as follows:
if the designated party is a corporation, its registered name must be used
if the designated party is a person, this field should hold "firstName lastName", with a
single space between both.
Dateandtimefields
All date, time or date and time fields are in ISO 8601 format12. The time zone indicator MUST be
used, in any of the formats supported by the standard.
SEPAmailNorme1206–ÉditiondeJuin2015 Page48
4.3. IGColourCoding
Element
Available (or mandatory) in SEPAmail, must be used according to
SEPAmail rules. Some of these elements also exist in SEPA
rulebooks and must also be used according to these rules.
Element Available in SEPA rulebooks, unused in SEPAmail
Element Not available under any of these rules
SEPAmailNorme1206–ÉditiondeJuin2015 Page49
4.4. SMIRKMIS1202,lamissivedansleséchangesinterbancairesIntroductionetgénéralités
La missive est la seule entité permettant l'échange d'informations dans le système SEPAmail, où
elle joue un rôle d'enveloppe pour les données confidentielles. Pour pouvoir acheminer
efficacement les différentes informations du système, quatre types de missives ont été définis
:
la missive nominale, acheminant un message
la missive d'acquittement, à but essentiellement protocolaire
ainsi que :
la missive de service, permettant un dialogue de nature « commande - réponse » entre
deux systèmes, réservée à l'espace compétitif hors réseau des adhérents SEPAmail, donc
non utilisé dans les échanges entre les adhérents du réseau SEPAmail
la missive SMAPI (SEPAmail API), accessible exclusivement en intrabancaire, et
permettant à un éditeur SEPAmail de fournir un accès direct à certains éléments de sa
plateforme.
La missive SMAPI est en bordure de la norme SEPAmail : son existence fait partie de la norme,
mais le contenu exact des messages SMAPI est laissé à la discrétion des éditeurs.
SEPAmail se sert de la missive pour :
l'adressage de l'information (qui est le destinataire, qui est l'émetteur)
le routage de l'information (comment j'achemine l'information)
la réception de l'information (l'information est-elle arrivée)
l'intégrité de l'information (est-ce la bonne information)
l'authentification des parties (l'émetteur et le destinataire sont-ils ceux qu'ils
prétendent être)
l'horodatage de l'information (quand l'information est-elle émise et reçue)
Lesprincipes
La missive est un flux XML respectant le schéma sepamail_missive13, qui fait partie des
spécifications du système. Cet élément sert à transporter toutes sortes de messages ou autres
contenus. Elle joue le rôle d'enveloppe et peut être acheminée par divers moyens.
La missive peut être de deux types :
une missive nominale, enveloppe pour toute forme de contenu (mais en particulier pour un
message SEPAmail),
une missive d'acquittement, qui permet d'accuser réception d'une missive nominale.
Remarque : La missive de service est une notion à ne pas utiliser dans l'espace interbancaire.
Elle ne fait donc pas partie de ce SMIRK. Un lexique des termes utilisés se trouve sur la
documentation de la communauté SEPAmail14.
Leroutage
Le routage se sert d'un adressage de type « courriel » sur le domaine sepamail.eu15 de la forme
:
SEPAmailNorme1206–ÉditiondeJuin2015 Page50
<ecosystem>@<bic>.sepamail.eu
ou
<ecosystem>@<xx.scheme>.sepamail.eu
où :
<ecosystem> est une famille SEPAmail valide du référentiel ecosystem@scheme
<bic> est un BIC valide du référentiel bic@scheme
<xx.scheme> représente un nœud du réseau appartenant au scheme et administré par lui (xx
est facultatif, c'est un code représentant le gestionnaire au sein du scheme, par
exemple fr.scheme pour le QXOO français.16)
Le routage est réalisé par les adhérents SEPAmail et au sein du scheme à l'aide d'automates qui
implémentent les règles de routage suivantes :
Règlesderoutageàlaréception
Un adhérent n'accepte des missives que pour les BICs qu'il représente. Un adhérent ne
fait donc pas de relais pour un autre adhérent.
Un adhérent n'accepte des missives qu'en provenance d'un BIC lié à un adhérent SEPAmail.
Le réseau SEPAmail est donc un réseau réservé à ses seuls adhérents et fermé au reste du
monde.
Règlesderoutageàl'émission
Un adhérent n'envoie des flux au sein du réseau SEPAmail qu'à un adhérent SEPAmail pour
un BIC déclaré et valide du référentiel bic@scheme.
L'acquittementd'unemissive
L'acquittement vise à informer l'émetteur de la réception, bonne ou mauvaise, de la missive
émise et d'un horodatage de cette réception.
C'est l'émetteur qui pilote l'envoi d'information et non le destinataire. L'acquittement est
obligatoire et systématique, il ne dépend pas de l'historique de la séquence.
La classe de l'acquittement ne dépend que des contrôles implémentés par le destinataire. On
trouve les codes retour dans une directive d'implémentation spécifique.
L'acquittement se fait selon les règles suivantes :
seules les missives nominales sont acquittées
toute missive nominale reçue (quel que soit son ordre) doit être acquittée.
l'acquittement doit être mis en œuvre selon la priorité et en respectant les délais
maximaux de la priorité.
Leséquencement
La séquence naturelle d'un échange de missives est :
SEPAmailNorme1206–ÉditiondeJuin2015 Page51
un adhérent A émet une missive nominale destinée à un adhérent B depuis un système
source de la missive
l'adhérent B reçoit la missive nominale provenant de l'adhérent A dans un système cible
de la missive
l'adhérent B émet une ou plusieurs missives d'acquittement destinée à l'adhérent A en
réponse à la missive nominale
l'adhérent A reçoit la ou les missives d’acquittement
Nous donnons ci-dessous les règles à implémenter sur le séquencement :
le destinataire de toute missive nominale reçue doit mettre en œuvre l'acquittement de
cette missive nominale par au moins une missive d'acquittement
aucune missive de type autre que « nominale » ou « acquittement » n'est émise
aucune missive de type autre que « nominale » n'est acquittée
aucune missive de type « acquittement » n'est émise sans avoir reçu au préalable une
missive de type « nominale »
Renvoid'unemissive
Un système de renvoi d'une missive peut être implémenté.
Il fonctionne ainsi :
il n'est mis en œuvre qu'avec les missives nominales,
la missive est renvoyée avec un ordre incrémenté de 1 ; l'émetteur s'interdit de changer
le contenu de la missive renvoyée, à l'exception du numéro d'ordre
la signature S/MIME de l'émetteur est donc différente.
SEPAmailNorme1206–ÉditiondeJuin2015 Page52
Dans le cas où une missive nominale n'est pas acquittée après un certain temps, les règles
suivantes sont implémentées :
l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans un
temps supérieur aux minima définis pour la priorité de la missive peut renvoyer la
missive avec un numéro d'ordre incrémenté ; il s'interdit de le faire avant ; il n'est
pas obligé de le faire
le renvoi d'une missive ne peut pas intervenir plus d'un certain temps, précisé dans le
tableau ci-après, après l'émission de la missive précédente
l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans le laps
de temps maximal autorisé pour la priorité de la missive et qui a renvoyé au moins une
fois la missive peut alors mettre en œuvre le procédé d'escalade prévu ; il s'interdit
de le faire avant ; il n'est pas obligé de le faire.
Le système d'incrément de l'ordre des missives nominales n'est pas destiné à permettre
d'envoyer plusieurs fois une même missive pour obtenir des acquittements différents. Ce système
n'est utilisé que pour obtenir un acquittement si celui-ci n'est pas arrivé.
On a donc les règles suivantes :
un système de réception et de contrôle des acquittements doit être mis en place,
le renvoi d'une missive n'est pas possible si elle est déjà acquittée sauf si la classe
d'acquittement est 4 (erreur transitoire).
Temps d'attente avant renvoi selon la priorité de la missive
Priorité Délai maximal
acquittement
Délai minimal
avant renvoi
Délai maximal
avant renvoi
Nombre maximal
de renvois
1 la plus haute 20 sec 30 sec 1 min 3
2 haute 3 min 5 min 10 min 5
3 normale 4 h 4 h 8 h 4
4 basse 12 h 12 h 24 h 3
5 la plus basse 48 h 48 h 96 h 3
Les délais de renvoi sont remis à zéro à chaque renvoi de la missive. Ainsi, si une missive de
priorité "haute" est envoyée à l'instant T pour la première fois (ordre 1), celle d'ordre 2
pourra être envoyée entre T+5mn et T+10mn. Si elle est envoyée à T+7mn, la missive d'ordre 3
(toujours en l'absence d'acquittement évidemment) pourra être envoyée entre T+12mn et T+17mn,
et ainsi de suite.
Le délai maximal d'acquittement, le délai minimal avant renvoi et le nombre maximal de renvois
indiqué ici sont des valeurs par défaut. Si deux adhérents concluent un accord bilatéral, ils
peuvent librement convenir de délais différents et/ou d'un plus grand nombre de renvois.
Temps d'attente avant escalade selon la priorité de la missive
Priorité Délai minimal avant escalade
SEPAmailNorme1206–ÉditiondeJuin2015 Page53
1 la plus haute 10 min
2 haute 30 min
3 normale 16 h
4 basse 36 h
5 la plus basse 120 h
Rappel : ce délai est calculé à partir de l'émission de la première missive (ordre 1), il n'est
pas remis à zéro à chaque rémission, contrairement aux délais de renvoi ci-dessus.
Leprocédéd'escalade
Dans le cas où une missive ne serait pas acquittée, même après un renvoi, l'adhérent peut
procéder à l'escalade prévue par le scheme dès qu'un délai minimal est passé après le dernier
renvoi (voir tableau ci-dessus).
Cette escalade est spécifiée par le Scheme dans un SMIRK spécifique.
Lecontenu
Selon les règles métier de SEPAmail, une missive contient obligatoirement :
un identifiant unique,
un type,
un ordre de présentation,
un en-tête,
et selon le type de missive :
un acquittement pour une missive de type acquittement,
un message SEPAmail pour une missive de type nominal,
et facultativement :
une signature du message, à ne pas confondre avec le cachet électronique apposé à la
missive au sein de l'enveloppe S/MIME. Cette signature sert essentiellement à pouvoir
SEPAmailNorme1206–ÉditiondeJuin2015 Page54
adjoindre une signature électronique du signataire, client de la banque et émetteur du
message.
Il faut noter que, du strict point de vue de la conformité au schéma XML, les blocs message et acquittement sont facultatifs (cf. schéma ci-contre).
L'en-tête de la missive respecte trois principes :
le principe de symétrie entre le destinataire et l'émetteur du message, car l'un et
l'autre peuvent avoir les deux fonctions
le principe de priorité, qui permet à chaque entité de gérer l'affluence en priorisant
les flux
le principe d'intégrité des informations générées par les automates qui est assuré par
des sommes de contrôle sur le contenu dont on veut vérifier l'intégrité
L'enveloppe
La missive est encapsulée dans une enveloppe SMTP-S/MIME. Cette enveloppe contient :
des entêtes:
1. FROM, adresse de courriel comme spécifié dans ce document, valide avec un nom de domaine déclaré au niveau des DNS
2. TO, adresse de courriel comme spécifié dans ce document, valide avec un nom de domaine déclaré au niveau des DNS
3. X-priority, priorité selon la spécification de ce document
4. SUBJECT vide par défaut, sans information signifiante sur le contenu du message
un corps reprenant deux parties
1. la missive, chiffrée avec la clé privée du certificat S/MIME liée à l'adresse FROM
2. une signature S/MIME, obligatoire
Remarque : la missive doit être chiffrée dans tous les cas, même dans le cas d'un parcours
flash (webservice sur couche HTTPS), afin de permettre une non adhérence des couches
applicatives de production de l'enveloppe SMTP et de son transport.
Lasécurité:authentification,confidentialitéethorodatage
La sécurité est assurée à plusieurs niveaux :
l'authentification des deux parties
la confidentialité de l'information transmise
l'horodatage des opérations d'émission et de réception des missives
SEPAmail utilise des procédés de cryptographie asymétrique.
Les adhérents disposent de façon certaine et sécurisée des clés publiques de chaque adhérent.
L'authentification de l'émetteur (adhérent SEPAmail) est alors assurée par une signature du
condensat du contenu intégral de la missive avec la clé privée de l'émetteur. Le destinataire
pourra alors vérifier que le condensat de la missive qu'il a généré est le même que celui de la
signature qu'il a déchiffré.
SEP
La c
publ
priv
La m
date
prat
Si u
est
just
L'éc
Sur
diff
AmailNorm
confidenti
lique du d
vée.
missive es
e/heure. L
tiques de
un horodat
réalisé s
te avant l
Leprot
change des
ces couch
férents :
SMTP
HTTPS+S
me1206–Éd
alité est
estinatair
t horodaté
es princip
la FNTC 17,
age de typ
ur l'envel
'émission
tocoled'éch
missives
es, SEPAma
SOAP
ditiondeJui
assurée pa
re. Ainsi,
ée en émiss
pes détaill
sont décr
pe « contre
loppe SMTP
ou juste a
hangedesm
se fait na
ail impléme
in2015
ar le chiff
seul le de
sion et en
lés d'horod
rits dans c
emarque de
(et non se
après la ré
missives
ativement s
ente deux p
frement de
estinatair
réception
datage app
cette page.
temps sign
eulement l
éception.
sur le rés
parcours a
la missiv
e pourra d
par une m
licables à
.
née » est
a missive)
eau IP via
vec deux p
e par l'ém
échiffrer
marque de t
SEPAmail,
nécessaire
par un se
la couche
rotocoles
metteur ave
le flux av
temps de ty
inspirés
e, alors ce
ervice tier
e de transp
de communi
Pag
ec la clé
vec sa clé
ype
des bonnes
et horodata
rs certifié
port TCP.
ication
ge55
s
age
é,
SEPAmailNorme1206–ÉditiondeJuin2015 Page56
Remarque : Cet échange fait l'objet de recommandations d'implémentation et sort du cadre
normatif de ce document.
Remarque : Une étude est en cours pour permettre un parcours flash sur la base de HTTP+REST
Laqualitédeservice
La qualité du service est soumise à un cadre faisant l'objet d'un document séparé 18.
Fonctionnement
Voici les schémas fonctionnels de la réception et de l'émission d'une missive, à réaliser par
les automates des adhérents bancaires.
Les actions sur les données à effectuer sont en bleu, les tests en vert.
Les opérations se succèdent selon une série temporelle représentée de haut en bas.
Réceptiond'unemissivenominale
Réception enveloppe SMTP au format S/MIME Le récepteur de missive réceptionne des enveloppes au format S/MIME, quel que soit le canal
d'entrée de cette enveloppe (SOAP ou SMTP).
SEPAmailNorme1206–ÉditiondeJuin2015 Page57
Vérification de l'intégrité S/MIME Il faut vérifier que l'enveloppe reçue est bien au format S/MIME.
Il doit y avoir également :
le champ FROM renseigné
le champ TO renseigné
une partie chiffrée ou non
une signature au format S/MIME
Remarque : le sujet SMTP peut être absent ou vide.
Extraction de l'en-tête MIME et des deux parties On extrait l'adresse FROM, l'adresse TO et les deux parties jointes à l'enveloppe, normalement
le contenu XML de la missive et une signature de ce contenu.
Vérification des BIC Il faut extraire les sous-domaines des adresses FROM et TO.
Ces deux sous-domaines doivent être ceux d'un BIC appartenant à bic@scheme.
Celui correspondant au destinataire (TO) doit également être l'un des BICs rattachés à
l'adhérent destinataire dans le référentiel member@scheme.
Vérification de l'écosystème L'écosystème fourni par l'adresse de courriel doit être un ensemble de messages géré par le
réseau SEPAmail, appartenant à ecosystem@scheme.
Déchiffrement La première partie de l'enveloppe MIME est chiffrée (Content-Type: multipart/encrypted), et
doit donc être déchiffrée avec la clé privée du destinataire (BIC extrait de l'adresse TO
(protocole défini par l'attribut protocol de l'en-tête Content-Type). La chaîne ainsi déchiffrée est considérée comme la missive à vérifier.
Calcul du condensat de la missive Un condensat du contenu de la missive est calculé selon la méthode déclarée dans les propriétés
S/MIME (attribut micalg de l'en-tête Content-Type).
Vérification de la signature S/MIME de l'adhérent émetteur La signature de l'adhérent SEPAmail émetteur est vérifiée en comparant le condensat calculé
précédemment avec le résultat du déchiffrement de la signature.
Vérification de la conformité du XML La missive est un document XML dont on vérifie qu'il est bien formé (la syntaxe est correcte)19.
Vérification de la validité du XML La missive est un document XML dont on vérifie :
qu'il contient une référence à l'espace de nom SEPAmail,
qu'il est valide (il valide le schéma XML qu'il référence).
SEPAmailNorme1206–ÉditiondeJuin2015 Page58
Extraction en-tête On extrait l'en-tête de la missive afin de permettre les vérifications suivantes.
Horodatage La missive est horodatée en réception, ce qui consiste à enrichir le contenu XML en renseignant
le champ « RcvDtTm » de l'en-tête de la missive avec la date et heure du système.
Vérification champ Rcv Le champ Rcv contient au moins :
un identifiant d'un utilisateur SEPAmail (généralement un identifiant bancaire IBAN,
PAN, QXBAN ...),
un identifiant de l'adhérent SEPAmail (BIC ou code entité SCHEME)
Cet identifiant doit correspondre à un utilisateur valide pour le service SEPAmail.
Il doit donc représenter un utilisateur actif dans l'un des référentiels d'identifiants gérés
par l'adhérent destinataire de la missive : QXBAN@BIC, IBAN@BIC, PAN@BIC.
Acquittement L'acquittement fait l'objet d'une émission de missive avec des règles qui ont été définies plus
haut.
Routage interne de la missive La missive est routée vers l'application bancaire ou le dispositif technique lié à l'écosystème
SEPAmail concerné.
Réceptiond'unemissived'acquittement
L'adhérent SEPAmail n'est pas tenu dans l'absolu d'effectuer un traitement en réception de
l'acquittement, sauf
pour obtenir les statistiques demandées par le Scheme
pour se conformer aux obligations de la Charte de l'adhérent
S'il souhaite traiter ces missives, il devra implémenter la même procédure que celle utilisée
pour la réception d’une missive nominale, à la différence qu’une missive d’acquittement
n’est pas elle-même acquittée.
Remarque : dans le cas d'erreurs au sein de la missive d'acquittement lors des vérifications
(XML non conforme ou valide, en-têtes non valides), on ne peut donc pas signaler ces erreurs.
Le mécanisme de renvoi de la missive nominale ou le procédé d'escalade doivent alors être
utilisés, pour ne pas faire boucler le système.
Vérification antécédent missive d'acquittement A ce stade, on peut vérifier si la missive d'acquittement possède déjà un antécédent :
en réception : existe-t-il d'autres acquittements sur la même missive nominale ?
en émission : existe-t-il une missive nominale ?
SEPAmailNorme1206–ÉditiondeJuin2015 Page59
Routage interne de la missive vers le SI La missive est routée vers l'application bancaire ou le dispositif technique lié à l'écosystème
SEPAmail si la logique du SI bancaire le nécessite.
Émissiond'unemissivenominale
Récupération ordre émission/information Une missive nominale est émise sur ordre d'émission d'une application bancaire.
La missive peut être récupérée telle quelle, auquel cas elle est vérifiée avant
signature/chiffrement et envoi.
SEPAmailNorme1206–ÉditiondeJuin2015 Page60
La missive peut être construite par l'automate.
Dans les deux cas, les vérifications suivantes sont réalisées.
Vérification des BIC Il faut extraire les BIC des informations transmises ou les déduire d'un référentiel IBAN@BIC.
Les deux BIC doivent appartenir à member@scheme ou être SCHEME.
Celui correspondant à l'expéditeur (FROM) doit également être un BIC possédé par l'adhérent.
Vérification de l'écosystème L'écosystème peut-être déduit du message contenu dans la missive ou transmis par l'application
bancaire (souhaitable). Ce doit être un écosystème géré par le réseau SEPAmail, appartenant à
ecosystem@scheme.
Vérification MsvSnd Le champ MsvSnd contient un identifiant (IBAN, QXBAN, PAN, ICQX/BIC, BIC)
Cet identifiant doit correspondre à un utilisateur valide pour le service SEPAmail.
Il doit donc être actif dans l'un des référentiels d'identifiants gérés par l'adhérent émetteur
de la missive : QXBAN@BIC, IBAN@BIC, PAN@BIC.
Vérification de la conformité du XML du message Le message à envelopper dans la missive est un document XML dont on vérifie la conformité.
Vérification de la validité du XML du message Le message est un document XML dont on vérifie :
qu'il contient une référence à un schéma XML de la famille de l'application demandée,
qu'il est valide.
Construction de la missive On construit la missive à partir du message et des informations précédemment vérifiées ou, dans
le cas d'une transmission initiale de missive, par un enrichissement de cette missive.
Horodatage La missive est horodatée en émission, ce qui consiste à enrichir le contenu XML en renseignant
le champ « SndDtTm » de l'en-tête de la missive avec la date et heure du système.
Vérification de la conformité du XML de la missive La missive construite à l'étape précédente est un document XML dont on vérifie la conformité.
Vérification de la validité du XML de la missive La missive est un document XML dont on vérifie :
qu'il contient une référence au schéma XML sepamail_missive20
qu'il est valide.
SEPAmailNorme1206–ÉditiondeJuin2015 Page61
Calcul du condensat de la missive Un condensat de la missive est calculé selon une méthode valide qui est déclarée dans les
propriétés S/MIME (attribut micalg de l'en-tête Content-Type).
Signature S/MIME de l'adhérent émetteur La signature du condensat créé précédemment est réalisée à partir à l'aide de la clé privée de
l'adhérent SEPAmail émetteur, dédiée à l'envoi de missives.
Chiffrement Le chiffrement de la missive est réalisé à l'aide de la clé publique de chiffrement du
destinataire.
Constitution de l'enveloppe MIME Une enveloppe MIME est constituée. Elle contient :
le champ FROM,
le champ TO,
une première partie contenant la missive éventuellement chiffrée,
une seconde partie contenant la signature S/MIME de la missive.
Remarque: les pièces jointes éventuelles du message sont jointes au message et donc incluses
dans le XML comme du binaire. Le mécanisme MIME des pièces jointes n'est donc pas utilisé pour
celles-ci, mais seulement pour la missive ET la signature.
Envoi selon priorité La priorité de la missive est reprise pour le transport
Émissiond'unemissived'acquittement
Le cas d'une missive d'acquittement est similaire. Seul le message est remplacé par la
structure d'acquittement, contenant le code d'acquittement.
SEPAmailNorme1206–ÉditiondeJuin2015 Page62
4.5. IGmissive These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the colour coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail missive.
The missive, in the SEPAmail system, is the general-purpose envelope used to dispatch all kinds
of contents, independently of the Exchange Mechanism used.
There are four types of missives:
Nominal missive, used to convey a payload -- generally a SEPAmail message
Acknowledgement missive, strictly protocol-based, used to indicate proper delivery and
understanding of a nominal missive.
Service missive, supporting a request-response dialog between parties
SMAPI missive, describing a kind of API between the SEPAmail-supporting plug-in and the
internal Information System
This document describes the elements for all kinds of missives.
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
The actual contents of the Missive element must be any one of the sepamail_missive_xxx
structures.
In addition to these contents, the Missive element has a mandatory attribute called "version",
describing the version of the Implementation Guidelines used to construct this missive. This
attribute, mandatory since 1206 version, must start with 4 integers, such as "1206" for June
2012 version. A free string, up to 10 chars, may follow these 4 integers.
Only the four first characters are relevant in order to check the version number of a given
missive.
For example, the beginning of a missive element could be:
<sem:Missive version="1206_vanilla"> <MsvId> ...
Mult Message Element SEPAmail requirement
[1..1] sepamail_missive_001 First version of the missive structure
SEPAmailNorme1206–ÉditiondeJuin2015 Page63
MissiveIdentification
The missive identification part contains information required for its identification and
acknowledgement. It occurs in every missive.
Ref Mult Message Element SEPAmail requirement
A1 [1..1] ++ MsvId
Usage Rule The format of this identifier is YYYYMMDDhhmmssxxx +
"_" + sender_id
The first part is the creation date and time, including
milliseconds
The second part can be used freely by the sender.
The absolute constraint is that a missive identifier MUST be
unique for a given sender, except for acknowledgement missives.
Thus, if more than one missive is created with the same date-
time stamp, it is the sender's responsibility to make sure the
"sender_id" part is different for each missive.
For an acknowledgement missive, the identifier must be the one
of the missive it acknowledges.
A2 [1..1] ++ MsvTyp
The only possible values are
* Nominal
* Acquittement or Acknowledgement
* Service
* SMAPI
A3 [1..1] ++ MsvOrd
Ordinal number of the missive. Usage Rule: this field must be
set to 1 (one) at first sending of a given missive. If the
missive needs to be resent, with the same contents, this number
MUST be incremented by one each time it is resent. All other
missive fields, including MsvId and SndDtTm, must be unchanged.
Usage Rule: for an acknowledgement missive, the order number
will be the one of the missive it acknowledges.
A4 [0..1] ++ MsvPri
Priority of the missive. The possible values are "HIGHEST",
"HIGH", "NORMAL", "LOW" and "LOWEST". Default value is "NORMAL".
If the receiver cannot handle the missive at the requested
priority, he must notify it by using a RoutingWarning element
(A6.7) in the acknowledgement missive.
SEPAmailNorme1206–ÉditiondeJuin2015 Page64
Missiveheader
The header contains elements about the routing of the missive. It is mandatory in every
missive, regardless of its type.
Ref Mult Message Element SEPAmail requirement
A5 [1..1] ++ MsvHdr
A5.1 [1..1] +++ Snd Sender. Usage rule: the sender can be identified by one or
several of the following identifiers:
A5.1.1 [0..1] ++++ BIC Mandatory in interbank communication, optional otherwise
A5.1.2 [0..1] ++++ IBAN
Mandatory if BIC is absent, optional if it is present
A QXBAN can be used as an usual IBAN
A5.2 [1..1] +++ SndDtTm Date and time of initial creation by sender, in ISO format
A5.3 [0..1] +++ SndChk
Sender-managed checksum. Usage Rule: this attribute can be used
by the sender to include a checksum on the missive header, which
MUST be sent back by the matching acknowledgement missive. Its
content is fully ignored by SEPAmail.
A5.4 [1..1] +++ Rcv
Receiver. Usage rule: the receiver can be identified by one or
several of the following identifiers:
a BIC for a financial establishment
an IBAN for a creditor or debtor. At least one of the following
identifiers must be present.
A5.4.1 [0..1] ++++ BIC Mandatory in interbank exchanges, optional otherwise
A5.4.2 [0..1] ++++ IBAN A QXBAN can be used as an usual IBAN
A5.4.3 [0..1] ++++ PAN
A5.4.4 [0..1] ++++ BBAN
A5.4.5 [0..1] ++++ RIS2D
A5.5 [0..1] +++ RcvDtTm Date and time of reception, in ISO format
Acknowledgementelement
This part of the missive appears only in acknowledgement missives, in which it is mandatory. It
contains detailed information about the delivery of the related nominal missive
Useoftheacknowledgementmissive
It must be reminded that an acknowledgement missive is used only after a nominal missive has
been sent. A service missive is used to reply to a service missive, and a SMAPI missive for a
SMAPI missive.
Only nominal missives must be acknowledged.
Generally, the missive identifier and rank, in the missive header, must match exactly those of
the nominal missive it acknowledges.
If a missive has been sent several times, with different rank numbers thus, the acknowledgement
of a given rank implies the non-acknowledgement of all lower ranks, except in special cases
(detailed non-acknowledgement already sent, for instance).
This acknowledgement is internal and SEPAmail-specific. Other protocolar acknowledgements may
exist, related to the exchange protocol used (positive answer from a Webservice, SMTP
acknowledgement ...) but those mechanisms can in no case replace the acknowledgement missive.
SEPAmailNorme1206–ÉditiondeJuin2015 Page65
Reciprocally, an acknowledgement missive is only used to transmit information about the routing
of a nominal missive, or about the sender or recipient addresses. However, all functional
changes (IBAN modification request, change of status for a mandate ...) MUST NOT be sent via an
acknowledgement missive. The proper message MUST be used, sent via a nominal missive.
Finally, it must be reminded that several acknowledgement missives MAY be related to the same
nominal missive, i.e. have the same missive identifier and rank. For instance, one could have
three successive acknowledgements:
the first one indicates proper reception of the missive (ACK without code)
the second one indicates that the recipient is part of SEPAmail, and that the message
has been forwarded (ACK, code 2.1.9)
the third one indicates that the debtor's bank has validated his/her IBAN (ACK, code
2.4.9).
A full list of allowed return codes is available here
Ref Mult Message Element SEPAmail requirement
A6 [0..1] + MsvAcq
A6.1 [1..1] ++ AcqSta Status. Possible values are ACK or NAK.
A6.2 [0..1] ++ AcqCla Class of status. See business rules document for meaning of the
values of this field.
A6.3 [0..1] ++ AcqSub Subject of status. See business rules document for meaning of
the values of this field
A6.4 [0..1] ++ AcqDet Detail of status. See business rules document for meaning of the
values of this field
A6.5 [0..1] ++ AcqChk Checksum of the acknowledgement. Currently unused.
A6.6 [0..1] ++ AcqDes
Description. If present, this field MUST contain a human-
readable explanation of the status, whether the acknowledgement
is positive or negative.
A6.7 [0..n] ++ RtgWarn Specific routing-related information
A6.7.1 [1..1] +++ Code
Nature of the information. Allowed values are
BAD_TIME: sending time is slightly incorrect
PRIO_HIGH: missive will be handled with "HIGH" priority only
PRIO_NORM: missive will be handled with "NORMAL" priority only
PRIO_LOW: missive will be handled with "LOW" priority only
PRIO_XLOW: missive will be handled with "LOWEST" priority only
A6.7.2 [0..1] +++ Descr Human-readable explanation and details.
SEPAmailNorme1206–ÉditiondeJuin2015 Page66
Serviceelement
This part of the missive appears only in service missives, in which it is mandatory. It
contains the protocol elements for information exchange between both parties.
Ref Mult Message Element SEPAmail requirement
A7 [0..1] + MsvSrv
A7.1 [0..1] ++ SrvCmd Command element, only used in command service missives
A7.1.1 [1..1] +++ CmdTyp Command Type. Usage Rule: possible values are DELE, LIST, NOOP,
RETR and STAT.
A7.1.2 [0..1] +++ CmdNum
Message Number. For DELE and RETR commands, must hold the number
of the message to delete or retrieve; for LIST command, may
contain a message number.
A7.1.3 [0..1] +++ CmdSlc
Message selection. If this attribute is present and has a "true"
value, all messages on server will be included in the command
scope. In all other cases, only unread messages are in the
scope.
A7.1.4 [0..n] +++ CmdFlt Filter expressions. This attribute must hold a valid Xpath2
expression.
A7.2 [0..1] ++ SrvRes Response element, only used in response service missives
A7.2.1 [1..1] +++ ResTyp Type of response. Possible values are +OK (positive response)
and -ERR (negative response).
A7.2.2 [0..1] +++ ResNum Message number
A7.2.3 [0..1] +++ ResSize Message size
A7.3 [0..1] ++ SrvInfo
Additional service information. Usage Rule: in a response to
LIST or STAT command, this string will hold the required
information.
Missivebody
This part of the missive appears only in nominal missives, in which it is mandatory. It
contains the actual payload of the missive, which can currently only be a SEPAmail message.
Ref Mult Message Element SEPAmail requirement
A8 [0..1] + MsvBdy Can be any type of SEPAmail message
Missivesignature
The last element of the SEPAmail missive is a signature, conforming to the XML DSig schema.
This element is not mandatory. It is even currently useless since in the current structure, the
missive payload is always clear, and contains an internal signature.
However, in future releases, the payload might become crypted, and this element could then be
used by the sender to authenticate the origin of the missive.
SEP
Le f
En
d’ê
SEPA
pend
en é
dans
La m
conn
(cas
ou a
Comm
mise
AmailNorm
4.6. fonctionne
La miss
La miss
récepti
interbanca
être toujo
Amail est
dant l’ex
écoute. Po
s un conte
missive de
nexion ave
s identiqu
acquitteme
me tous le
e en œuvre
me1206–Éd
Missivement stand
sive nomina
sive d’acq
ion de miss
ire, ces 2
urs (24/24
une norme
périmentat
ur contour
xte autre
service p
c l’adhér
e à celui
nt).
s éléments
de cette
ditiondeJui
edesedard de la
ale qui pe
quittement
sive nomin
2 missives
4 – 7/7) à
qui a voca
tion qu’il
rner cette
que celui
permet à un
rent, que c
de l’inte
s de la rel
missive es
in2015
rvicemessagerie
rmet l’en
, systémat
ale
suffisent
l’écoute
ation à êtr
l était dif
contrainte
de l’inte
ne entrepri
ce soit pou
erbancaire)
lation entr
st facultat
e SEPAmail
nvoi des do
tiquement e
amplement
en récept
re utilisé
fficile d’
e et perme
erbancaire
ise d’êtr
ur l’envo
) mais aus
re un adhér
tive.
repose su
onnées en i
envoyé par
car chaqu
ion.
e avec les
imposer a
ttre une u
, la missi
e systémat
i des miss
si pour la
rent et se
r 2 types
interbanca
le destina
e adhérent
entrepris
ux entrepr
tilisation
ve de serv
iquement à
ives nomin
réception
s clients,
de missive
ire
ataire pou
t a une obl
ses, et il
rises d’êt
n de la nor
vice a été
à l’initia
nales ou d'
n de missiv
l’utilis
Pag
es :
ur toute
ligation
est apparu
tre toujour
rme SEPAma
créée.
ative de la
acquitteme
ves (nomina
sation et l
ge67
u
rs
il
a
ent
ales
la
SEPAmailNorme1206–ÉditiondeJuin2015 Page68
4.7. HorodatagedesmissivesL'horodatage de la missive doit permettre d'assurer une datation raisonnablement fiable de la
missive, et par voie de conséquence du message à l'intérieur de la missive. Par
"raisonnablement fiable", on entend une date synchronisée sur les serveurs de temps normalisés
et accessibles au travers de l'Internet.
L'adhérent SEPAmail devra donc disposer d'une référence horaire auprès d'un serveur de temps de
niveau 1 (ou de niveau zéro), en utilisant le protocole NTP, avec une mise à l'heure au moins
une fois par jour. Le protocole STIME n'est pas demandé mais possible.
La procédure pour garantir la fiabilité se fonde sur 3 mécanismes à mettre en œuvre :
une mise à l'heure régulière du serveur d'émission assurant l'horodatage (du serveur qui
écrit la date dans le schéma XML de la missive).
une mise à l'heure régulière du serveur de réception.
un contrôle de chaque missive en réception. Le serveur en réception contrôle l'heure de
la missive reçue vis-à-vis de sa propre heure.
1. la logique de traitement, dès lors que les 2 serveurs ont une même heure, veut que l'heure d'envoi de la missive (champ SndDtTm de l'en-tête de la missive) soit toujours inférieure à l'heure du serveur de réception
2. le contrôle se fait par comparaison de l'heure du serveur de réception (H2) et l'heure de la missive (H1), en prenant en compte les fuseaux horaires.
1. si H2 > H1 (cas normal) :
1. la missive est traitée normalement
2. la missive d'acquittement est renvoyée avec un résultat standard
2. si H2 < H1 < H2 + 3 secondes :
1. la missive est traitée normalement
2. la missive d'acquittement doit comporter un avertissement (RoutingWarning, A6.7) avec un code "BAD_TIME"
3. une mise à l'heure du serveur de réception est effectuée
3. si H1 > H2 + 3 secondes :
1. la missive n'est pas traitée
2. la missive d'acquittement doit indiquer un code erreur 4.3.3 (temporaire, heure erronée)
3. une mise à l'heure du serveur de réception est effectuée
3. à la réception d'une missive d'acquittement ayant un code 4.3.3 ou 5.3.3 ou d'une missive d'acquittement avec un avertissement BAD_TIME, une mise à l'heure du
serveur d'émission doit être effectuée
4. de plus, si le code d'acquittement est 4.3.3, le serveur d'émission doit renvoyer la missive après cette remise à l'heure
NOTA : l'horodatage des missives ne doit pas être confondu avec un éventuel horodatage des
messages, celui-ci étant spécifique au besoin métier du message.
SEPAmailNorme1206–ÉditiondeJuin2015 Page69
4.8. StatistiquesLes statistiques devant être fournies par les adhérents au Scheme sont de deux sortes :
des statistiques de niveau "missive"
des statistiques de niveau "message"
Les seules statistiques devant être remontées au SCHEME MANAGER par les adhérents aux SCHEME
concernent exclusivement les flux inter-adhérents.
Les flux ON-US, gérés en interne par un même adhérent, n'ont pas à être remontés. Ce cas inclut
les flux qui pourraient être échangés entre deux infrastructures de traitement SEPAmail d'un
même adhérent.
Principesgénéraux
Dans tous les cas, nous parlons ici de statistiques cumulées : un seul enregistrement doit
apparaître pour chaque ensemble de valeurs des éléments distinctifs (lignes orange ci-dessous),
et cet enregistrement doit indiquer (lignes vertes) les valeurs cumulées pour tous les messages
ou missives correspondant à ces valeurs.
Les fichiers seront en cible au format XML et en phase transitoire au format CSV précisé dans
les Règles Opérationnelles.
SEPAmailNorme1206–ÉditiondeJuin2015 Page70
Statistiquesdeniveau"missive"
Ces statistiques concernent toutes les missives, nominales et d'acquittement, reçues et
envoyées par un adhérent dans la période de temps concernée. Chaque missive compte ; en
d'autres termes, si une missive est renvoyée plusieurs fois, elle sera comptabilisée plusieurs
fois dans ces statistiques.
élément format commentaire exemple
date YYYY-MM-DD
(ISO8601)
Ceci doit correspondre à la partie
Date de la balise SndDtTm de la
missive
2012-05-12
flow énumération "Sending" ou "Receiving" Sending
reportingMemberBIC BIC11 BIC de l'infrastructure SEPAmail
(memberBic) produisant la donnée
statistique
BQPCFRPPXXX
senderBIC BIC11 en émission, le BIC du PSP du client
rattaché au BIC de l'adhérent ; en
réception, le BIC de la contrepartie
BQPBFRPPXXX
receiverBIC BIC11 en émission, le BIC du PSP de la
contrepartie ; en réception, le BIC
interne du PSP du BIC maître
BQPAFRPPXXX
type énumération Type de missive, "Nominal" ou
"Acknowledgement"
Nominal
order chaîne pour une missive nominale, numéro
d'ordre ; pour une missive
d'acquittement, son code de retour
sous la forme c.s.d.
2.1.4
priority énumération peut prendre 5 valeurs : "HIGHEST",
"HIGH", "NORMAL", "LOW", "LOWEST"
NORMAL
mode énumération 2 valeurs possibles : "Canonical" et
"Flash"
Flash
missivesCount entier total du nombre de missives concernées 42
volume entier total du volume de ces missives (en k-
octets), pièces jointes comprises,
mais sans prendre en compte
l'enveloppe S/MIME.
872
Statistiquesdeniveau"message"
Contrairement aux autres statistiques, celles-ci ne doivent être réalisées que pour les
missives nominales correctement acquittées par le destinataire.
élément format commentaire exemple
SEPAmailNorme1206–ÉditiondeJuin2015 Page71
date YYYY-MM-DD
(ISO8601)
Ceci doit correspondre à la partie
Date de la balise SndDtTm de la
missive.
2012-05-12
flow énumération "Sending " ou "Receiving" Sending
reportingMemberBIC BIC11 BIC de l'infrastructure SEPAmail
(memberBic) produisant la donnée
statistique
BQPCFRPPXXX
senderBIC BIC11 en émission, le BIC du PSP du client
rattaché au BIC de l'adhérent ; en
réception, le BIC de la contrepartie
BQPBFRPPXXX
receiverBIC BIC11 en émission, le BIC du PSP de la
contrepartie ; en réception, le BIC
interne du PSP du BIC maître
BQPAFRPPXXX
version NNNN Version de SEPAmail utilisée par le
message
1206
ecosystem énumération Écosystème auquel le message
appartient
payment.activation
messageType énumération Type du message dans son écosystème activation.request@pa
yment.activation
returnCode chaîne Si le message est de type report pour RUBIS, GEMME, DIAMOND ou SECURE,
valeur du code de retour qu'il
transmet
ACSP
transactionsCount entier total du nombre de transactions
ISO20022 portées par les messages
42
transactionsAmount réel total des montants des transactions
liées à ces messages, en Euros
123456.78
attachmentsCount entier total du nombre de pièces jointes à
ces messages
2
Écosystèmesetmessages
Voyez ici pour une liste complète des écosystèmes et des noms des messages pouvant être
utilisés dans ces statistiques.
SEPAmailNorme1206–ÉditiondeJuin2015 Page72
4.9. IGmissivereturnCodesAnnex:returncodesfortheacknowledgementmissive
The class, subject and detail elements of the acknowledgement missive are used to indicate
precisely on which elements the acknowledgement -- or lack thereof -- is based.
Class 2 always indicates success
Class 4 indicates a transient error, that a resending of the missive could solve
Class 5 indicates a permanent error, which cannot be solved by resending the missive
The full list of codes appears in the following table.
In this table, some codes appear with an 'N' class. This means that the receiver must decide
whether the error is transient or permanent, and use 4 or 5 accordingly. Class 4, which allows
for automatic resending of missives, should be preferred whenever possible.
Code Description
Subject addresses
5.1.1 Unknown sender
5.1.2 Unknown receiver
5.1.3 Receiver known but out of SEPAmail scheme or ecosystem.
2.1.9 Receiver known, missive forwarded.
Subject mailbox
N.2.1 Mailbox is deactivated
N.2.2 Mailbox is full
5.2.3 Message is too long
Subject system
N.3.1 File system full
N.3.2 Inaccessible server
N.3.3 Sending date+time incorrect, and outside of the margin. (Missive has not been
handled).
Subject debtor
5.4.1 Invalid addressing identifier (IBAN, QXBAN ...)
2.4.9 Valid addressing identifier, real account
Subject Security and cryptography
5.7.2
Impossible to decrypt (key1 or key2). In fact, since the decryption of the S-MIME
envelope cannot be processed, the embedded missive cannot be read and acknowledged.
Thus, the proper behaviour in this case will be avoiding any response to the sender.
5.7.3 Unsupported algorithm or security function
5.7.4 Integrity error
Subject contents
5.8.1 XML syntax error, non-conforming to schema
5.8.2 Missive contents incoherent
5.8.3 Invalid missive identifier
5.8.4 Order number error
SEPAmailNorme1206–ÉditiondeJuin2015 Page73
Code Description
5.8.5 Version not supported
5.8.6
Corrupted contents or virus detected. In fact, since the detection of a corrupted
content may be prior to the extraction of the embedded missive due to infrastructure
constraints, this missive may not be acknowledged to the sender.
SEPAmailNorme1206–ÉditiondeJuin2015 Page74
4.10. IGmessage These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the colour coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the standard SEPAmail message.
Messages are used to convey information, both between creditor's bank and debtor's bank, and
between banks and their customers (creditor / debtor).
Here are the messages currently defined in the SEPAmail system:
Four are related to the direct.debit ecosystem:
1. MandateAcceptanceReport, based on pain.012, used to acknowledge and accept a mandate created or modified by a MandateInitiationRequest message
2. MandateInitiationRequest, based on pain.009, used to create or update a mandate
3. Prenotification, describing a payment schedule, either global (annual schedule) or local (single payment)
4. RequestForCopy, used by debtor to ask for a copy of the original mandate
Two belong to the identification.verification ecosystem
1. VerificationRequest, to require a verification
2. VerificationReport, to reply to a request.
Three belong to the payment.activation ecosystem
1. PaymentActivationRequest, to require a payment
2. PaymentActivationReport, to accept or decline it
3. PaymentActivationEnroll, to accept or decline an invitation to be part of Rubis
Seven belong to the scheme ecosystem
1. CreditorCreationRequest
2. CreditorCreationReport
3. CreditorUpdateRequest
4. CreditorUpdateReport
5. CreditorInformationRequest
6. CreditorInformationReport
7. CreditorActivationAdvise
Three belong to the secure ecosystem:
1. EnrollRequest, to submit a certificate for use in the SEPAmail system
2. EnrollReport, to accept or reject a certificate
3. EnrollAdvise, for inter-partner certificate notification
Two belong to the test ecosystem
1. SimpleTestRequest, used to test communication, protocol compliancy ...
SEPAmailNorme1206–ÉditiondeJuin2015 Page75
2. SimpleTestReport, its reply
Each of these messages is described in a separate document. However, they are all held in a
standard Message element, which we will describe hereafter.
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
The actual contents of the Message element must be any one of the sepamail_message_xxx
structures.
In addition to these contents, the Message element has an attribute called "version",
describing the version of the SEPAmail Implementation Guidelines used to construct this
message. This attribute, mandatory since version 1206, must start with 4 integers, such as
"1202" for February 2012 version. A free string, up to 10 chars, may follow these 4 integers.
Note that the version of the message is not necessarily the same as the version of the missive.
Mult Message Element SEPAmail requirement
[1..1] sepamail_message_001 First version of the message structure
SEPAmailNorme1206–ÉditiondeJuin2015 Page76
MessageHeader
The message header contains information required for the processing of the entire message.
Ref Mult Message Element SEPAmail requirement
A [1..1] ++ MsgHdr
A1 [1..1] +++ MsgId
This identifier should be equal to the missive identifier (MsvId
element, see related doc.), followed by an underscore ('_') and
by a number, which must be unique in a given missive. In any
case, the message identifier MUST be unique for a given sender.
A2 [1..1] +++ MsgTyp The general form is “message@ecosystem”. See table below for
allowed values.
A3 [0..n] +++ MsgRedir
Redirections for the message. These redirections may be
implemented by the receiving part, and can take one of the
following forms
A3.1 [0..1] ++++
InternalReference Can be a phone number, an office identifier ...
A3.2 [0..1] ++++ RedirectURI Can be a mail address, a Web page or Web service ...
A4 [0..n] +++ MsgRef This element indicates previous messages, which are somehow or
other in relation with the current one.
A4.1 [1..1] ++++ MsgId The identifier of the related message
A4.2 [1..1] ++++ Relation A string describing the relation. Currently, this string is
free-form, but it could for example be "invoice", "mandate" ...
A5 [0..1] +++ MsgExpiry
An ISO date and time at which the message is no longer relevant,
and can be deleted by all actors. Possible actions taken at that
time depend on the ecosystem and on the relation between the
bank and its customer.
SEPAmailNorme1206–ÉditiondeJuin2015 Page77
Listofknownmessagetypes
Here are, in alphabetical order, all currently known messages, along with their associated
message types (A2 - MsgTyp) element.
Ecosystem Message MsgTyp
direct.debit MandateInitiationRequest [email protected]
MandateAcceptanceReport [email protected]
Prenotification [email protected]
RequestForCopy [email protected]
identification.verificationVerificationReport [email protected]
VerificationRequest [email protected]
payment.activation PaymentActivationEnroll [email protected]
PaymentActivationReport [email protected]
PaymentActivationRequest [email protected]
scheme CreditorActivationAdvise activation.advise@scheme
CreditorCreationReport creation.report@scheme
CreditorCreationRequest creation.request@scheme
CreditorInformationReport information.report@scheme
CreditorInformationRequestinformation.request@scheme
CreditorUpdateReport update.report@scheme
CreditorUpdateRequest update.request@scheme
secure EnrollAdvise enroll.advise@secure
EnrollReport enroll.report@secure
EnrollRequest enroll.request@secure
test SimpleTestReport simple.report@test
SimpleTestRequest simple.request@test
SEPAmailNorme1206–ÉditiondeJuin2015 Page78
MessageBody
The message body depends on the type of message, as defined in the MsgTyp element. At this
level, it contains only one element.
Ref Mult Message Element SEPAmail requirement
B [1..1] ++ MsgBdy
Can be any of the messages belonging to the SEPAmail system :
payment.activation_ActivationRequest,
direct.debit_MAndateAcceptanceReport ...
SEPAmailNorme1206–ÉditiondeJuin2015 Page79
4.11. SMIRKMES1102,lemessagedansleréseauinterbancaireIntroductionetgénéralités
Le message SEPAmail est l'information élémentaire transmise.
Dans l'espace coopératif interbancaire, il est utilisé pour faire transiter une information
standardisée avec un minimum obligatoire et une scalabilité permettant des services dans
l'espace compétitif.
Un message appartient à un unique écosystème et il répond toujours aux règles suivantes :
Il est typé.
Il est composé d'informations au format XML.
Il contient de l'information structurée selon son type, définie par un schéma XML.
Toute information autre que celle servant au bon routage est intégrée dans un message
SEPAmail et il n'y a donc aucune information qui transite en dehors d'un message dans le
réseau SEPAmail.
Cependant, chaque fois que c'est possible au sein d'une application bancaire, la modélisation
des échanges préfère le « Question/Réponse » simple et sobre.
Le message SEPAmail fait le plus souvent partie d'une Application SEPAmail, qui fait l'objet
d'un SMIRK séparé21.
Lesprincipes
Nonconfidentialité
Le message n'est pas chiffré. Par contre, il est toujours inclus dans une enveloppe sécurisée
(missive).
La confidentialité « technique » de l'intégralité du message échangé n'est donc pas possible,
vis-à-vis de la banque s'entend : la banque peut toujours voir les données contenues dans un
message.
Elle est « fonctionnelle » par le seul secret bancaire et l'accord de confidentialité du Scheme
envers son réseau d'adhérents.
La confidentialité de bout en bout, vis-à-vis des tiers, est toujours garantie.
Intégrité
L'intégrité d'un message est assurée par deux mécanismes facultatifs de la missive
l'enveloppant :
la signature du message, qui assure l'origine mais aussi l'intégrité puisque que la
signature est réalisée sur un condensat du message.
une somme de contrôle sur l'ensemble du message en en-tête de la missive.
Seul le message EnrollRequest peut transiter sans signature, tous les autres doivent
impérativement être signés.
Structurationdel'information
Le message SEPAmail répond aux règles suivantes :
Il est typé (ActivationRequest, MandateAcceptanceReport ...).
Il est composé d'informations au format XML.
SEPAmailNorme1206–ÉditiondeJuin2015 Page80
Il contient de l'information structurée selon son type, définie par un schéma XML.
Nommagedutype
Le type d'un message SEPAmail
a son nom composé de mots clés anglais, à la norme CamelCase 22
reprend les normes du SEPA sur le nommage des grandes fonctions : Request, Report,
Reply.
Écosystème
Un message fait toujours partie d'un écosystème de messages (ecosystem en anglais).
L'écosystème est une notion ensembliste permettant de regrouper des schémas XML.
L'écosystème est donc différent de l'application SEPAmail.
Complétudedel'information
Toute information autre que celle servant au bon routage est intégrée dans un message SEPAmail.
Il n'y a aucune information métier qui transite en-dehors d'un message dans le réseau SEPAmail.
Plus généralement, il n'y a aucune information qui transite en-dehors d'une missive dans le
réseau SEPAmail.
Duréedevaliditédumessage
Le message possède une date de péremption, date après laquelle son sens informatif est périmé.
Cette date est définie par une borne absolue (date heure universelle).
Le dépassement de la date n'est pas le déclencheur exclusif de la péremption du message. En
effet, un message peut être périmé aussi par d'autres événements tels :
la réponse au message
l'apparition d'une clause suspensive
toute autre cause définie par le contenu du message (se reporter aux IG correspondantes)
Ledialogue«Question/Réponse»aucœurdel'échangeSEPAmail
Le message SEPAmail permet essentiellement de faire transiter de l'information entre deux
utilisateurs du réseau dans les deux sens, afin de composer un dialogue entre deux utilisateurs
indéfiniment connectés.
La plupart des messages sont conçus dans une logique de question/réponse (Request/Report ou
Request/Reply).
La messagerie peut s'étendre à plus de deux utilisateurs et permettre d'autres combinaisons que
la simple paire de messages Question/Réponse.
Cependant, chaque fois que c'est possible au sein d'une application bancaire, la modélisation
des échanges préfère le « Question/Réponse » simple et sobre.
Lecontenu
Un message SEPAmail est composé de deux éléments :
un en-tête (obligatoire),
un corps (obligatoire).
Le message valide le schéma XML sepamail_message.xml23
SEPAmailNorme1206–ÉditiondeJuin2015 Page81
L'en‐tête
L'en-tête est toujours composé des éléments :
un identifiant de message unique (obligatoire),
un type de message (obligatoire),
une référence à un ou plusieurs messages précédents (facultative),
une date/heure de péremption (facultative),
une référence de redirection (facultative).
L'identifiant de message doit être unique pour un doublet (émetteur, message) dans le réseau
SEPAmail. Il est de la responsabilité de l'émetteur de s'assurer de cette unicité.
Le type de message permet de s'assurer que le message est conforme à un type défini et
structuré au sein d'une famille de message. C'est un type parmi une liste définie dans les
schémas XML.
La date/heure de péremption a été décrite plus haut dans les principes. Il s'agit d'une
date/heure universelle. Elle permet d'assurer, si elle est renseignée, que le sens informatif
du message est périmé. Cette notion permet au relais de l'émetteur d'informer l'émetteur de
l'éventuelle absence de réponse ou de proposer du service autour de ce jalon. Cela permet aussi
au relais du destinataire d'archiver le message si besoin, et de ne pas conserver indéfiniment
un message dans la queue des messages mis à disposition du destinataire.
La référence de redirection permet de rediriger le message vers ses lecteurs finaux dans le
système destinataire si besoin (numéro de téléphone, poste, personne, URL etc...)
Lecorps
Le corps du message dépend du type de message.
Il existe un schéma XML pour chaque type de message
Lespiècesjointes(inclusesdanslecorpsdumessage)
Dans SEPAmail, il y a un élément « data » qui est utilisé dans trois éléments parents :
une image (élément « Image »),
une pièce jointe au sens MIME (élément « Attachment »),
une signature (élément « Signature »).
L'image est utilisée chaque fois que l'élément doit pouvoir être affiché en ligne dans une
interface homme/machine.
La pièce jointe est plutôt utilisée lorsque l'élément doit pouvoir être téléchargé dans les
interfaces homme/machine.
Remarque : le RIS2D et le Document utilisent la pièce jointe « Attachment », ce qui est logique
car le RIS2D doit pouvoir se télécharger.
SEPAmailNorme1206–ÉditiondeJuin2015 Page82
4.12. SMIRKAPP1103,l'applicationSEPAmailCette demande de commentaires (SMIRK) spécifie la structuration spécifique d'un dialogue de
messages SEPAmail (SMIRK MES110224) : l'application SEPAmail.
Introduction
L'application SEPAmail permet de définir quelles sont les séquences possibles d'un dialogue
autour d'une fonctionnalité métier définie.
Pour cela, SEPAmail définit une application comme :
un ensemble de messages SEPAmail,
des séquences possibles et définies de dialogue,
une liste d'états possibles du dialogue initié,
un ensemble de règles de gestion à implémenter pour permettre la transition d'états pour
chacun des dialogues.
Lesprincipes
Lafonctionnalitémétier
C'est une fonctionnalité métier bancaire, interne ou tierce qui justifie la création d'une
application SEPAmail.
Cette fonctionnalité induit la création d'un dialogue plus ou moins complexe entre les parties.
Lenommagedelafamille
Les applications SEPAmail prennent le nom de pierres précieuses ou semi-précieuses.
Si possible, ce nom sert d'acronyme pour définir la fonctionnalité métier en anglais.
Le « E » final, lorsqu'il est présent, devrait signifier Exchange.
Lesmessages
Le message est obligatoirement conforme à la SMIRK MES1102.
Ledialogue
Un dialogue est constitué d'une séquence finie de messages parmi les messages définis de
l'application.
Un dialogue est initié dans SEPAmail par l'émission d'un premier message.
Dans la plupart des cas, il se termine lors de la réponse à ce premier message.
En effet, la plupart des échanges structurés d'information met en jeu :
deux utilisateurs, l'émetteur du premier message et son destinataire,
une question et une unique réponse.
Cependant, des cas plus complexes permettent plus de deux utilisateurs et plus de deux
messages. Le dialogue se termine lorsque la date de péremption de chacun des messages le
constituant est dépassée ou qu'aucune réponse n'est possible.
Remarque : Il n'y a actuellement pas de limite au nombre possible de messages dans un échange.
Lavuestatutairedel'application
Il y a des messages qui :
SEPAmailNorme1206–ÉditiondeJuin2015 Page83
peuvent initier le dialogue
peuvent terminer le dialogue
ne peuvent pas initier le dialogue
doivent succéder à un autre message.
L'application SEPAmail peut donc être vu comme un ensemble de transitions possibles entre un
ensemble de messages (qui seraient alors considérés comme les états de l'application), avec un
état « start » et un état « end ».
Remarque : Dans l'état actuel de cette SMIRK, l'annulation et la péremption des messages ne
sont pas envisagées, bien que les structures de données nécessaires soient en place.
L'utilisateurdel'application
Le dialogue entre deux utilisateur est possible si :
les deux utilisateurs sont actifs pour cette application
les deux utilisateurs sont « connectés ».
On dit que deux utilisateurs sont connectés s'ils ont chacun émis et reçu un message (autorisé
pour l'application) de l'autre utilisateur.
Sinon, ils sont déconnectés.
L'état connecté est indéfini ; il revient à « déconnecté » dans les cas suivants :
un des deux utilisateurs demande la déconnexion,
un des deux utilisateurs n'est plus actif pour cette application,
un des relais de messagerie (les adhérents SEPAmail) fait une requête de déconnexion des
deux utilisateurs.
Lecontenu
Une application est définie par :
un nom,
un objectif d'échange bancaire d'information,
un ensemble de messages SEPAmail,
un ensemble de transitions possibles entre les messages considérés comme des états avec
les deux états « start » (pas de transition vers l'état « start ») et « end » (pas de
transition depuis l'état « end »),
un ensemble d'utilisateurs de l'application, dont le profil permet ou non l'émission ou
la réception de message.
Applicationaucœurdel'architecturedeSEPAmail
L'application traite des messages qu'elle récupère généralement d'une implémentation logicielle
de SMART via une API, comme décrit dans le schéma ci-dessous.
SEPAmailNorme1206–ÉditiondeJuin2015 Page84
SEPAmailNorme1206–ÉditiondeJuin2015 Page85
4.13. SMIRKREF1104,lesréférentielsCette demande de commentaires (SMIRK) spécifie les référentiels partagés par la communauté
SEPAmail et les méthodes permettant de synchroniser ces référentiels. Ce SMIRK est un standard
de la communauté SEPAmail, spécifié et maintenu par le scheme SEPAmail.
Introduction
On distingue pour chaque référentiel le référent naturel du référentiel parmi les grands
acteurs du réseau SEPAmail : l'adhérent SEPAmail ou le Scheme. On appelle référentiel un
ensemble structuré d'informations faisant référence pour l'ensemble du système SEPAmail. Par
exemple, la liste des applications SEPAmail est un référentiel SEPAmail.
Lexique
Lecréancier
Le créancier est une entité économique (secteur privé, associatif ou institutionnel)
soit disposant d'un ICS au niveau SEPA
soit inscrit comme créancier SEPAmail.
L'ICS
L'ICS (Identifiant Créancier SEPA, SEPA Creditor-ID abrégé CI en anglais) est géré au niveau de
chaque pays SEPA par une entité unique. Seules les banques du pays peuvent demander
l'inscription ou la modification d'un ICS à cette entité unique nationale de gestion de l'ICS
.
LeQXBAN
Le QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au
système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en
conformité avec la définition et le règles génériques de création d'un l'IBAN pour un code pays
« QX » (pas de pays avec ce code).
LeRIS2D
Un RIS2D (Relevé d'Identité SEPAmail 2D) est une image de type code barre 2D au format
datamatrix contenant des données propres à l'utilisateur de SEPAmail : nom, prénom, BIC,
identifiant QXBAN, date d'expiration
L'ICQX
L'ICQX est l'identifiant unique d'un créancier dans le réseau SEPAmail. Cet identifiant est
géré par le Scheme. Il est unique pour une entité économique et pérenne.
L'applicationSEPAmail
Une 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 (messagerie bancaire
sécurisée).
L'horodatage
L'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure.
L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une
source de temps. Il est décrit plus en détail dans cette page.
SEPAmailNorme1206–ÉditiondeJuin2015 Page86
LeScheme
Le Scheme, ou Scheme SEPAmail, est l'entité au sein de laquelle les adhérents SEPAmail sont regroupés, et qui a pour mission de maintenir la norme SEPAmail et les référentiels.
Lesprincipes
Lalocalisationduréférentiel
Les référentiels sont localisés et gérés :
soit par le Scheme,
soit par un adhérent SEPAmail.
Lasynchronisationdel'information
Certains référentiels doivent être synchronisés avec ceux d'un ou plusieurs autres adhérents
SEPAmail.
Cette synchronisation sera définie précisément pour chaque référentiel.
LeSchemeaunrôleparticulier
Dans le réseau, le Scheme a un rôle particulier puisqu'il n'est pas un établissement bancaire
avec des clients.
LesréférentielsSEPAmail
On adopte la convention de nommage d'un référentiel objet_référence@environnement où :
objet_référence est le concept faisant référentiel
environnement est l'environnement maître du référentiel: Scheme, BIC (adhérent SEPAmail)
ou autre.
Par homogénéité, il est également décidé que les noms des référentiels, aussi bien actuels que
futurs, seront :
en anglais
entièrement en minuscules
séparés par des points lorsqu'il y a plusieurs éléments
au singulier
Notez que les référentiels présentés ici n'existent pas tous aujourd'hui, et ne sont pas tous
complètement spécifiés. Certains d'entre eux pourraient même être fusionnés avant
implémentation.
ecosystem@scheme
Le référentiel de tous les écosystèmes SEPAmail partagés au sein de l'espace coopératif est
maintenu au sein du Scheme.
service@scheme
Le référentiel de toutes les applications SEPAmail partagées au sein de l'espace coopératif est
maintenu au sein du Scheme.
member@scheme
Le référentiel des adhérents SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page87
bic@scheme
Le référentiel de tous les BICs accessibles au sein du réseau SEPAmail.
bic.service@scheme
Ce référentiel est maintenu par le Scheme, éventuellement par un QXOO (fr.scheme pour la
France). Ce référentiel détaille les services et niveaux de priorités sur lesquels chaque BIC
est actif.
icqx@scheme
Le référentiel des ICQX (équivalent SEPAmail de l'ICS pour SEPA) est maintenu par le Scheme,
éventuellement par un QXOO (fr.scheme pour la France). Chaque banque peut se doter localement
d'une extraction synchronisée quotidiennement du référentiel icqx@scheme pour toutes les
applications SEPAmail qu'elle met en œuvre.
Le référentiel icqx@scheme recense les liaisons ICQX/QXBAN par service (cf. ServiceCard) ainsi
que les dates de validité de ces liaisons.
qxban@bic
Chacune des banques adhérentes SEPAmail doit mettre en œuvre un référentiel des QXBAN de ses
clients et notamment de ses clients créanciers. Étant à la main de la banque, ce référentiel ne
fait pas partie de la norme SEPAmail. Toutefois, sa désignation qxban@bic sera utilisée pour le
désigner.
Il est de la responsabilité de chacune des banques de mettre en œuvre pour tout nouveau client
la génération de son QXBAN selon l'algorithme du Scheme.
LesNomenclaturesexternes
LanomenclaturedesBICS
Standard BIC (ISO 9362)
LanomenclaturedesICS
(Externe par pays, Banque de France pour la France)
Lesnomenclaturesofficiellesgéographiques
les nomenclatures pays (code pays, intitulés, banque centrale)
les nomenclatures devises (dans un premier temps, on se limite à la zone euro)
les nomenclatures de localisation (langues, jeu de caractères)
SEPAmailNorme1206–ÉditiondeJuin2015 Page88
4.14. SMIRKREF1201,leréférentielicqx@schemePrincipesgénéraux
Le référentiel des ICQX (icqx@scheme) contient tous les créanciers personnes morales inscrits
auprès de SEPAmail, qu'ils soient « visibles » par les débiteurs ou non.
Comme son nom l'indique, il est maintenu par le Scheme manager, ou par le QXOO (QX Operational
Office).
Il est mis à jour à l'initiative de la banque du créancier, sur demande du créancier, que ce
soit lors de la création de l'enregistrement (correspondant donc à une demande d'ICQX) ou lors
d'un changement de contenu. Dans tous les cas, cette mise à jour passe par l'adhérent SEPAmail
dont dépend le créancier, et est faite sous sa responsabilité.
Seuls les créanciers personnes morales peuvent être inscrits dans ce référentiel. Les personnes
physiques ne sont inscrites dans aucun référentiel.
L'ICQX sert d'index dans ce référentiel. Il est unique pour un créancier donné, quels que
soient les changements de situation qui puissent l'affecter (changement d'adresse, de nom, de
banque ...). Le seul changement pouvant intervenir dans cet ICQX concerne le 7ème caractère
(position 3 du business code), qui est laissé à la libre disposition du créancier. Dans le référentiel, ce caractère sera systématiquement forcé à 'Z'. En revanche, d'autres valeurs
pourront être utilisées pour la recherche.
Lorsqu'un créancier est présent dans le référentiel, il peut « s'inscrire » à un ou plusieurs
« services ». Ces services correspondent à tout ou partie d'une application SEPAmail, et seront
par exemple :
RUBIS inscription
RUBIS émission
RUBIS réception
DIAMOND émission
GEMME émission
GEMME réception
Contenuduréférentiel
Le référentiel contient tous les éléments relatifs à un créancier : éléments d'identification,
éléments bancaires, éléments de communication avec les débiteurs et bien sûr éléments relatifs
au référentiel lui-même.
Voici la liste détaillée de ces éléments :
1.Index
ICQX (avec le 3ème caractère du business code mis à 'Z')
2.Élémentsdedésignation
Nom (PartyName) [chaîne de 1 à 140 caractères]
Nom courant (DisplayName) [chaîne de 1 à 140 caractères]
Logo [image]
Vignette (thumbnail) [image]
Adresse postale [format ISO 20022]
SEPAmailNorme1206–ÉditiondeJuin2015 Page89
3.Élémentsd'identificationL'adresseinternetducréanciern'estpasretenueici,pourdesraisonsdereroutageetdemiseàjour
[pour tous : type = chaîne (1 à 16 car) parmi une énumération ("SIRET", "SIREN" ... "Other"), valeur = chaîne de 1 à 35 caractères pouvant ou non avoir un format figé]
SIRET
SIREN
TVA intracommunautaire
autre (pour l'administration)
forme juridique
activité
4.Élémentsbancaires
BIC (correspond au BIC de dernière mise à jour)
5.Élémentsliésauréférentiel
Dates de validité (début – fin, correspondant à la validité de l'ICQX) [2 dates format ISO]
Date de dernière mise à jour [format ISO]
Compte de test (booléen) (toujours égal à false dans l'usage actuel)
6.Élémentsliésàunservice(0àNblocspossibles)
Nom du service («RUBIS inscription » par exemple) [valeur dans une énumération]
Activité vis-à-vis de ce service (booléen)
Portée (locale ou globale) ["local" ou "global"]
QXBAN associé(s)
Communication avec débiteurs (0 à 3 identifiants possibles)
1. Nom de l'identifiant du débiteur [chaîne de 1 à 70 caractères]
2. Où et comment le trouver (texte et/ou image) [chaîne de 1 à 140 caractères + image]
Tous les éléments des blocs 1, 2, 4 et 5 sont obligatoires. Concernant ceux d'identification
(bloc 3), au moins un des quatre premiers éléments doit être fourni, et plusieurs peuvent être
présents (sauf SIRET et SIREN, qui sont exclusifs l'un de l'autre).
L'ensemble des éléments des blocs 1 à 5 constituent une structure dénommée ICQXCard, qui est
transportée intégralement dans certains messages de gestion du référentiel, décrits plus loin
dans ce document. Cette structure n'est utilisée nulle part ailleurs dans SEPAmail.
Les éléments liés à un service (bloc 6) constituent une ServiceCard. Chaque créancier
enregistré dans le référentiel peut disposer de 0, une ou plusieurs ServiceCards.
La portée figurant dans une ServiceCard est à interpréter ainsi :
local : le pays du créancier (ou du QXOO local), correspondant au code pays figurant dans l'ICQX
global : tous les pays
Exemple
Un créancier qui envoie et reçoit des messages RUBIS, et qui accepte les messages d'inscription
à ce service, aura un enregistrement comportant :
SEPAmailNorme1206–ÉditiondeJuin2015 Page90
les blocs 1, 2, 4 et 5 complets
suffisamment d'éléments dans le bloc 3 pour que sa banque ait pu valider son identité
3 ServiceCards (bloc 6), avec le champ "actif" à true dans les trois, et un ou plusieurs
QXBAN dans chaque ServiceCard 25 :
1. une pour le service "RUBIS inscription", comportant au moins 1 et au plus 3 blocs "communication avec le débiteur"
2. une pour le service "RUBIS émission", sans blocs "communication avec le débiteur"
3. une pour le service "RUBIS réception", sans blocs "communication avec le débiteur"
Accèsduclientfinalauxdonnéesduréférentiel
Toute banque adhérente à SEPAmail est tenue de donner accès aux données des blocs 1 à 3 à
l'ensemble de ses clients SEPAmail.
Pour l'utilisation du service "RUBIS inscription", elles devront être complétées par les
éléments "communication avec le débiteur" (contenues dans la ServiceCard, bloc 6)
correspondantes.
L'affichage et les modes de recherche ne sont pas spécifiés par SEPAmail.
Utilisationduréférentiel
À partir du moment où un créancier est inscrit dans ce référentiel, il se contente d'envoyer,
dans les messages qu'il émet, son ICQX. La banque du débiteur peut alors consulter le
référentiel, ou un miroir local qu'elle maintient à jour, pour obtenir toutes les informations
nécessaires sur ce créancier et les présenter aux débiteurs.
Processusetmessagesautourduréférentiel
Tous les messages relatifs à ce référentiel appartiennent à l'écosystème scheme. Sauf mention contraire, l'adresse destinataire des messages à destination du Scheme sera
[email protected] ou [email protected].
Les BIC correspondant à cette adresse 26 sont :
pour le QXOO, SKEMQX..XXX, où .. doivent être remplacés par le code du pays
pour le Scheme Manager, SKEMQXQXXXX
Créationd'uncréancier
Le créancier communique les informations de son ICQXCard à sa banque, sauf bien sûr l'ICQX 27.
La banque réalise les tests de vérification d'identité du créancier, qui sont de son entière
responsabilité.
S'ils sont négatifs, elle lui répond par un rapport négatif et le processus est terminé.
S'ils sont positifs, elle envoie cette ICQXCard au Scheme par le biais d'un message
CreditorCreationRequest.
Le Scheme attribue un ICQX au créancier et répond à la banque par un CreditorCrea-
tionReport positif28 contenant cet ICQX. Ce créancier n'a aucun service associé lors de
sa création.
La banque envoie alors au créancier un rapport positif, contenant au minimum son ICQX.
Le message CreditorCreationRequest peut donc être acheminé
par le créancier à sa banque s'ils utilisent les échanges SEPAmail
SEP
Ce r
gat
S'il
doit
Le m
Le p
créa
nouv
La b
AmailNorm
par la
R
rapport es
if. S'il e
l est néga
t reprendr
message Cr
par le
par la
M
processus
ancier tra
velle banq
banque réa
me1206–Éd
banque du
Rapportde
t acheminé
st positif
tif, le cr
e au début
editorCrea
Scheme à l
banque du
Miseàjour
de mise à
nsmet les
ue.
lise les t
ditiondeJui
créancier
ecréationd
é par un me
f, ce messa
réancier n'
t, après co
ationReport
la banque
créancier
rd'uncréan
jour d'un
informatio
tests de vé
in2015
au Scheme
'uncréanci
essage Cred
age contien
est pas cr
orrection d
t peut donc
du créanci
au créanc
ncier
créancier
ons de mise
érification
e
ier
ditorCreat
nt une ICQX
réé dans l
des anomal
c être ach
ier
cier, s'ils
est très
e à jour à
n d'identi
ionReport,
XCard comp
e référent
ies bien s
eminé
s utilisent
similaire
sa banque
té du créa
qui peut
lète.
iel du Sch
ûr.
t les échan
à celui de
– en cas
ncier29.
être posit
heme, et la
nges SEPAm
e création
de changem
Pag
tif ou né-
a procédure
: le
ment, à sa
ge91
e
SEPAmailNorme1206–ÉditiondeJuin2015 Page92
S'ils sont négatifs, elle lui répond par un rapport négatif et le processus est terminé.
S'ils sont positifs, elle envoie l'ICQXCard au Scheme par le biais d'un message
CreditorUpdateRequest.
Le Scheme met à jour le référentiel et répond à la banque par un CreditorUpdateReport
positif30.
La banque répond alors au créancier par un rapport positif, contenant au moins son ICQX.
Le message CreditorUpdateRequest peut donc être acheminé
par le créancier à sa banque s'ils utilisent des échanges SEPAmail
par la banque du créancier au Scheme
Rapportdemiseàjourd'uncréancier
Ce rapport est acheminé par un message CreditorUpdateReport, qui peut être positif ou négatif.
De même que pour le rapport de création d'un ICQX, s'il est positif, ce message contient une
ICQXCard complète.
Si le rapport est négatif, l'enregistrement du créancier dans le référentiel et l'ICQXCard sont
inchangés.
Le message CreditorUpdateReport peut donc être acheminé
par le Scheme à la banque du créancier
par sa banque au créancier, s'ils utilisent des échanges SEPAmail
Diffusiond'informationsuruncréancier
Lorsqu'un créancier est prêt à émettre ou à recevoir les messages d'un service particulier, il
est de la responsabilité de sa banque de transmettre cette information à l'ensemble du réseau
SEPAmail.
Elle se fait par le biais d'un message CreditorActivationAdvise, qui contient l'ICQX du
créancier et la ServiceCard concernée. Le même message permet aussi de suspendre l'activité
d'un créancier sur un service spécifique.
Le message est adressé par la banque du créancier à toutes les autres banques et au Scheme, qui
met à jour son référentiel à réception.
Demandedeconsultationduréférentiel
Lorsqu'une banque reçoit un message, typiquement de l'écosystème Rubis, contenant un ICQX, elle
peut consulter le Scheme pour obtenir les informations relatives au créancier détenteur de cet
identifiant.
La consultation du référentiel sert également à la banque du débiteur pour mettre à disposition
le service d'inscription RUBIS.
Ceci se fait par un message CreditorInformationRequest, mentionnant l'ICQX du créancier31.
L'ICQX fourni peut contenir un caractère quelconque en position 7, il sera systématiquement
forcé à 'Z' par le Scheme avant consultation du référentiel.
SEP
En r
Cred
Serv
Pour
miro
miro
AmailNorm
R
réponse à
ditorInfor
viceCards
S
r limiter
oir local
oir resten
me1206–Éd
Réponseàc
un message
mationRepo
relatives
Synchronis
les messag
de son con
t à défini
ditiondeJui
consultatio
e CreditorI
ort, conten
à ce créan
ationduréf
ges de cons
ntenu. Les
ir.
in2015
nduréfére
Information
nant l'ICQX
ncier.
éférentielen
sultation,
conditions
entiel
nRequest,
XCard comp
ntrebanque
il serait
s exactes
le Scheme
lète du cr
es
cohérent
de constit
répond par
éancier, e
que chaque
ution et d
r un messag
et l'ensemb
e banque di
de mise à j
Pag
ge
ble des
ispose d'un
jour de ce
ge93
n
SEP
Nom
Cred
Cred
Cred
Cred
Cred
Cred
Des
réfé
Nom
Cred
Paym
AmailNorm
R
du message
ditorCreatio
ditorCreatio
ditorUpdateR
ditorUpdateR
ditorInforma
ditorInforma
messages
érentiel d
du message
ditorActivat
mentActivati
me1206–Éd
Récapitulat
Mes
onRequest
onReport
Request
Report
ationReques
ationReport
supplément
ans les ba
Mes
tionAdvise
ionEnroll
ditiondeJui
tifdesmess
sagesSchem
Ut
Cr
M
t Co
taires pour
anques.
sagesinterb
U
D
u
I
R
in2015
sagescréés
me
tilisation
réation d'u
ise à jour
onsultation
rront être
bancaires
Utilisation
Diffusion d'
un créancier
nscription
RUBIS inscri
un créancier
d'un créanc
n du référen
créés, no
un service
r
d'un débite
iption)
r
cier
ntiel
tamment ce
associé à
eur (servic
acteurs
Banque cré
Créancier
Banque cré
Créancier
Banques ↔
ux gérant
acteurs
Banque cr
Banque cr
e Banque dé
créancier
éancier ↔ Sc
↔ Banque cr
éancier ↔ Sc
↔ Banque cr
Scheme
la réplica
réancier →
réancier →
ébiteur → b
r
Pag
cheme
réancier
cheme
réancier
ation du
autres banq
Scheme
banque
ge94
ques
SEPAmailNorme1206–ÉditiondeJuin2015 Page95
Phasetransitoire
Pour accélérer la mise en place de ce système, sans la rendre dépendante de l'implémentation
effective du référentiel et de l'écosystème correspondant, on peut à court terme travailler
ainsi :
le référentiel est remplacé par une feuille de calcul maintenue par le Scheme
la feuille est envoyée par mail aux adhérents, une fois par jour, dès lors qu'il existe
au moins une mise à jour
les messages d'inscription et de modification, ainsi que leurs rapports, sont remplacés
par des formulaires papier. Ceux-ci seront supprimés au fur et à mesure de la
disponibilité des messages SEPAmail correspondants.
SEPAmailNorme1206–ÉditiondeJuin2015 Page96
5. L'applicationRUBIS
SEPAmailNorme1206–ÉditiondeJuin2015 Page97
5.1. RUBIS1206RUBIS est une application SEPAmail. Son Sigle est RUBIS@SEPAmail. RUBIS est l'acronyme français
de "Règlement Universel Bancaire Immédiat & SEPA".
L'application permet de gérer des demandes de règlement, et peut aussi permettre d'initier des
paiements correspondant à ces demandes.
Historique
Fin 2010, le Ministère des Finances a incité les parties prenantes à mettre en place un nouveau
moyen de paiement sous le nom de virement de proximité. Le cahier des charges de ce nouveau moyen était simple :
paiement à la main du client,
permettant le règlement de factures par les particuliers,
offrant la possibilité de règlement entre particuliers.
En parallèle, le projet SEPAmail démarrait ses premiers flux réels avec SFR sur les flux GEMME,
de gestion des autorisations de prélèvement. Le règlement des factures ayant été envisagé par
SEPAmail dès 2008, il a été décidé de bâtir un nouveau service dans le cadre de la messagerie
SEPAmail, pour répondre aux besoins exprimés du "virement de proximité".
SEPAmailNorme1206–ÉditiondeJuin2015 Page98
5.2. Lesprincipesgénéraux(RUBIS)Contexted’utilisation
RUBIS vise à couvrir les contextes d’utilisation suivants :
Virement occasionnels entre 2 entités (entreprises ou particuliers)
Paiement de factures régulières avec une validation systématique par le payeur
La conception de RUBIS ne préjuge pas du mode de transfert de fonds (virements, prélèvements,
compensation cartes) qui sera utilisé tout en envisageant que le mode de référence sera le
virement, donc le SEPA Credit Transfer au niveau européen.
De plus, pour le paiement de factures régulières, les besoins complémentaires suivants sont
pris en compte :
RUBIS est à la main du client et donc chaque règlement doit être validé par le débiteur. Aucune validation implicite ne peut être acceptée, ce besoin étant déjà couvert par le
paiement par prélèvement
RUBIS doit aider à sa propre montée en charge, c'est-à-dire inciter les clients
débiteurs à utiliser le service sans que cela soit trop compliqué pour les émetteurs de
factures
RUBIS doit proposer une solution levant l’inconvénient majeur perçu par les facturiers
: la difficulté de lettrage entre le virement et la facture initiale.
Unservicecomplet
RUBIS comporte trois composantes majeures :
1. un service d'inscription auprès des facturiers qui utilisent RUBIS
1. ce service permet une inscription très simple pour le débiteur auprès de ce facturier pour recevoir les demandes de règlement. Cette inscription reste, bien
entendu, à la main du débiteur pour respecter le cahier des charges de RUBIS. Elle est rendue possible par l'inscription préalable des facturiers dans un référentiel
partagé
2. l'inscription utilise un alias d'IBAN, le QXBAN, garantissant au débiteur que son IBAN n'est pas communiqué au facturier, comme dans le cas du paiement par chèque à
ce jour.
3. ce service, ainsi que le référentiel, n'est pas disponible pour les règlements occasionnels de particuliers à particuliers ou avec des entreprises
1. une transmission électronique des demandes de règlements comportant un message XML et de façon optionnelle, un fichier PDF
1. directement émis par le créancier (celui-ci peut être un particulier, un facturier ou une entreprise) à sa propre banque
2. mis à disposition du débiteur (particulier ou entreprise) par sa propre banque et permettant ainsi une validation électronique authentifiée par la banque du
débiteur
3. un message de confirmation dès lors que la validation est effective
2. un virement SEPA (SCT) envoyé à la banque du créancier
1. avec une copie à l'identique des éléments fondamentaux de la demande de règlement initiale
SEPAmailNorme1206–ÉditiondeJuin2015 Page99
2. pour que le créancier recevant le virement puisse automatiquement associer le virement avec le "compte client" qui a fait l'objet de la demande.
SEPAmailNorme1206–ÉditiondeJuin2015 Page100
5.3. Lesavantagespourleclient(RUBIS)Pourlecréancier
la relation commerciale et de confiance maintenue avec sa banque
un envoi électronique des demandes de paiements, ouvrant sur une économie des coûts
postaux et une intégration complète de la chaîne de facturation
la possibilité, à terme, de proposer plusieurs moyens de paiement (virement, carte,
prélèvement)
une automatisation de la réconciliation (lettrage)
une diminution des coûts de gestion
un risque minimisé de gestion des données de ses clients, car les QXBAN ne sont pas
utilisables directement pour des transferts d'argent comme peuvent l'être les numéros de
cartes bancaires ou les IBAN
une compatibilité avec les données IBAN dans le cas où ils en possèdent
une facilité, réservée aux créanciers facturiers, de recourir au service d'inscription
RUBIS ainsi qu'une visibilité accrue grâce au référentiel des facturiers
une conservation en cas de contentieux de la trace de la demande initiale.
Pourledébiteur
la relation commerciale et de confiance maintenue avec sa banque
l'accord systématique avant chaque paiement, à la main du client
le choix du moyen de paiement et du compte à débiter, suivant l'offre de sa banque,
celle-ci peut gérer un virement à partir d'un compte différent de celui associé au QXBAN
l'utilisation des canaux : banque à distance, GAB, téléphone mobile ou directement dans
son système d'information pour une entreprise
une disponibilité 7/7 24/24
une capacité d'alimentation automatique d'un coffre-fort électronique pour conserver les
éléments de la facture et de son règlement
une simplification dans la mise en relation avec les créanciers, soit par le service
d'inscription RUBIS soit directement en utilisant le format code-à-barre du QXBAN (ce
format s'appelle le RIS2D)
une sécurité dans la mise en relation avec le créancier :
1. par une protection de ses coordonnées bancaires car il ne diffuse qu'un alias d'IBAN
2. par la nécessité que le débiteur donne son identifiant QXBAN au créancier, soit directement (SEPAmail, téléphone, MMS ou email) soit par le service d'inscription
RUBIS.
SEP
RUBI
init
RUBI
paie
cas
Le v
disp
disp
préa
Il e
non
val
créa
néce
AmailNorm
5.4. IS peut po
tiale.
Cœurd
IS a été c
ement à la
d'usage :
le paie
personn
le tran
viremen
RUBISp
virement é
position d
ponible en
alable des
est cepend
pas au tr
idation du
ancier. Ce
essaire
de mett
que cha
réponse
me1206–Éd
Casd'utentiellem
ecibleRUB
onçu pour
main du c
ement de fa
nes, morale
nsfert de f
nt, compte
pourlesflu
tant par n
es fonds n
l'état po
banques p
ant possib
avers de l
client :
ci est pos
tre en plac
aque banque
e immédiate
ditiondeJui
usage(Rment prendr
BIS
répondre a
client. RUB
actures, q
es ou phys
fonds entr
tenu de l
uxurgents
nature du s
n'est pas n
our des flu
participant
ble d'imagi
l'accélérat
cette répo
ssible dès
ce des règ
e de débit
e et un vi
in2015
RUBIS)re en compt
au besoin e
BIS a pour
uittances,
iques, pou
e particul
a complexi
système SCT
native dans
ux urgents
tes.
iner une fu
tion du vir
onse pourra
aujourd'hu
les partic
eur défini
rement déc
)te de nombr
exprimé du
vocation
... présen
ur qui le p
liers, qui
ité de sais
T à au moin
s RUBIS. L
et nécess
uture vers
rement, ma
ait avoir
ui dans le
culières en
isse un sys
calé : serv
reux cas d
Ministère
de remplac
ntant une c
prélèvement
mobilise à
sir des IBA
ns 1 jour,
'applicati
iterait, e
ion de RUB
is dans le
valeur de
s messages
ntre banque
stème de ge
veur d'auto
'usage bie
des Finan
er le chèq
certaine ré
t ne peut p
à ce jour p
AN sur une
l'immédia
on RUBIS n
n tout cas
IS ou l'im
traitemen
transfert
RUBIS. Il
es sur ce s
estion du r
orisation c
en au-delà
nces d'un m
que ou le T
égularité,
pas conven
plus le ch
banque en
ateté de mi
n'est donc
s, un accor
mmédiateté
nt de la ré
auprès de
l serait né
sujet
risque ent
comme pour
Page
de sa cibl
moyen de
TIP dans de
pour les
nir
hèque que l
n ligne.
ise à
pas
rd explicit
est attein
éponse aprè
la banque
éanmoins
re une
r la monéti
e101
le
eux
le
te
nte,
ès
du
ique
SEP
Ce p
cons
plus
Le c
Le p
Sché
L'in
ensu
AmailNorm
? compt
solutio
point sera
sidéré com
s tard, av
Comme
commerce é
une séc
une erg
une vit
la livr
de mult
positionne
une int
1.
2.
une val
de sa b
éma compar
nscription
uite, et p
me1206–Éd
tabilité te
ons.
it similai
me assuran
ec une vit
erceélectro
lectroniqu
curité des
gonomie sim
tesse du pa
raison doit
tiples cas
ment de RU
teraction à
inscriptio
une transm
lidation au
banque) pou
atif entre
préalable
résente un
ditiondeJui
emps réel
ire à l'uti
nce de paie
tesse simil
onique
ue met en é
paiements
mple pour
aiement ou
t être déc
d'interac
UBIS sur le
à la main
on préalabl
mission en
u travers
ur la vali
e le paieme
e a pour av
ne limite d
in2015
? réservat
ilisation d
ement alors
laire à cel
évidence de
pallier l'
d'assuran
lenchée tr
tions avec
e commerce
du client
le du clien
direct du
de sa prop
dation du
ent par car
vantage de
d'utilisati
tion préala
du système
s que le f
lle du vir
es besoins
absence d'
nce du paie
rès rapidem
c le client
électroni
pour la mi
nt-débiteu
RIS2D (fo
pre banque
paiement
rte et le p
permettre
ion pour l
able des fo
monétique
lux effect
ement.
multiples
humains
ement (voir
ment (vente
t : centre
que se bas
ise en rela
r sur le s
rmat code-
à distance
paiement R
l'utilisa
es achats
onds ? voir
ou le flu
if de comp
:
r paragraph
e d'informa
d'appel, w
e sur :
ation :
ite de com
-à-barre du
e (ou de l'
RUBIS en e-
tion du ca
"compulsif
re un mix
ux d'autori
pensation i
he précéde
ation ou d
web, smart
mmerce élec
u QXBAN)
'applicati
-commerce.
anal "centr
fs". Pour c
Page
de ces
isation est
interviendr
ent) lorsqu
de logiciel
phone.
ctronique
on smartph
re d'appel"
ces dernier
e102
t
ra
ue
ls)
hone
"
rs,
SEP
la n
comp
RUBI
RUBI
déd
AmailNorm
nécessaire
pulsivité.
Paieme
IS pourrai
paiemen
nombreu
paiemen
de sant
frais p
facture
Paieme
IS, couplé
ié) peut p
me1206–Éd
transmiss
entsdenich
t résoudre
nt contre l
ux soucis e
nts fléchés
té par exem
professionn
es
entdebillet
avec une
ermettre u
ditiondeJui
sion du QXB
hes
e aussi des
livraison,
en inter-e
s, c'est-à
mple)
nels avec
télectroniq
applicatio
une automat
in2015
BAN (30 car
s paiements
souvent a
ntreprises
-dire mett
transfert
que
on d'envoi
tisation co
ractères)
s complexe
appelé au cs
tant en œuv
directemen
de billet
omplète de
ou du RIS2
s tels que
cul du cami
vre des con
nt à la com
électroni
ce cas de
D limite f
:
ion, paieme
ntrôles trè
mptabilité
que (messa
vente.
fortement c
ents qui p
ès spécifi
de l'entr
age secure
Page
cette
posent de
ques (rése
reprise des
ou message
e103
eau
s
e
SEP
Le c
AmailNorm
Les flu
à l'arr
électro
PDF imp
L'ardoi
concept ci
me1206–Éd
ux de 1 à 5
rivée du fl
onique sous
primable di
seélectron
-dessous r
ditiondeJui
5 sont les
lux 5, le
s forme de
irectement
niqueencom
reprend le
in2015
flux de b
vendeur de
code-à-ba
de manièr
mmercede
principe d
base de RUB
e billet pe
arres pour
re sécurisé
eproximité
d'ardoise
BIS
eut à son t
une lectur
ée (flux 6,
éutilisablep
sur la bas
tour envoye
re simplif
7, 8)
paruntiers
e des serv
er un bill
iée par ex
s
vices RUBIS
Page
et
xemple, ou
S.
e104
un
SEPAmailNorme1206–ÉditiondeJuin2015 Page105
Dans un premier temps, l'utilisateur signe un contrat avec le commerce de proximité pour
utiliser ce service. Le contrat prévoit que ce service est accessible tant à l'utilisateur mais
potentiellement par un tiers, par exemple, la Nounou des enfants avec, le cas échéant, un
montant maximal par dépense sur ce tiers.
L'utilisateur s'enregistre au travers du service d'inscription RUBIS en indiquant, comme
convenu avec le commerce au préalable, son QXBAN et le numéro d'une carte d'identification
(NFC, code à barre) appartenant à la Nounou. Le commerce met en place :
une cible NFC pour lire l'identifiant de la carte d'identification
une base logicielle permettant d'associer l'identifiant de la carte et le QXBAN et le
cas échéant, la gestion des limites de paiements, voire même des alertes si certains
aliments ne sont pas autorisés.
Lorsque la Nounou passe en caisse, elle valide avec sa carte d'identification, le commerce émet
immédiatement une demande de règlement avec le montant des achats et la liste complète (le
ticket sous format PDF). L'utilisateur peut ainsi recevoir et valider le paiement.
Pour des raisons de facilité, il semble utile que le contrat initial autorise un passage sans
validation immédiate tout en attendant la validation pour autoriser le passage suivant.
Ce cas d'usage, bien que théorique, montre la puissance du service RUBIS ainsi que la capacité
d'une banque à créer des nouveaux services compétitifs indépendamment des autres banques.
SEPAmailNorme1206–ÉditiondeJuin2015 Page106
5.5. Lagestiondesinscriptionsdesdébiteurs(RUBIS1206)
RUBIS comprend un service RUBIS inscription, particulièrement adapté aux facturiers.
La liste des créanciers enregistrés sur le service RUBIS inscription est appelée référentiel
RUBIS.
ATTENTION, ce référentiel RUBIS ne doit pas être confondu avec le référentiel icqx@scheme dont
l'objet est beaucoup plus large, voir ici. L'objet du référentiel RUBIS est de faciliter la
migration des clients-débiteurs.
ConstitutionduréférentielRUBIS
Le référentiel RUBIS est un sous-ensemble du référentiel icqx@scheme constitué des blocs 1,2,3
et des éléments 'Communication avec débiteurs' du bloc 6, pour les créanciers dont l'élément
'Activité' sur le service RUBIS inscription est égal à 'true'.
Les critères d'éligibilité au service RUBIS inscription sont :
posséder un ICQX (l'équivalent RUBIS de l'ICS pour les prélèvements SEPA) - voir ici le
processus préalable de création d'un créancier pour obtention d'un ICQX
avoir une activité de facturation récurrente, comme peut l'avoir une entreprise ayant
fortement recours aux prélèvements. De fait le service d'inscription RUBIS est exclu
pour les créanciers-particuliers.
Le service RUBIS inscription est optionnel. Seuls y souscrivent les créanciers désirant être
publiés sur le référentiel RUBIS. On peut tout à fait imaginer qu'une entreprise ayant une
activité principalement en B2B ne recoure pas aux fonctionnalités du service RUBIS inscription.
Il doit être noté que l'IBAN du créancier n'est pas une donnée publiée dans le référentiel
RUBIS car elle n'est pas utile au débiteur pour s'inscrire auprès d'un créancier. En revanche,
afin de permettre le routage des flux d'inscription des débiteurs jusqu'au créancier concerné,
l'IBAN figure dans le référentiel icqx@scheme parmi les données de la ServiceCard RUBIS
inscription destinées aux banques.
L'inscription auprès d'une banque de créancier pour le service RUBIS inscription n'est pas
forcément liée à la remise des flux de demandes de règlement (auquel cas les IBAN enregistrés
dans les ServiceCards RUBIS émission et RUBIS inscription sont différents). Cependant, une
banque de créancier pourrait mettre cette condition à l'ouverture du service.
Par ailleurs, en cas d'inscription du créancier au service RUBIS inscription auprès de
plusieurs banques, seule la dernière inscription est prise en compte.
Les flux concernant la constitution du référentiel RUBIS sont schématisés ci-dessous :
SEP
Le r
l'éc
accé
loca
Chaq
AmailNorm
1. le créadéfinie
basée s
phase s
niveau
2. la banqla vali
3. Une foile Sche
informa
4. la banqinforme
Partage
référentie
cosystème
éder aux i
alement, s
Obligat
que banque
à la pr
banque
à offri
signifi
me1206–Éd
ancier dema
e par sa ba
sur les mes
suppose que
du Scheme.
que du créa
idité de l'
is la valid
eme Manager
ation se fa
que du créa
er son créa
eduréféren
l RUBIS es
scheme déd
nformation
oit à trav
tionsdelab
de débite
résentation
en ligne e
ir la capac
ier son acc
ditiondeJui
ande l'act
anque (puc
ssages d'u
e le créan
.
ancier DOI
'ICQX, des
dation eff
r de cette
ait grâce
ancier att
ancier de
ntielRUBIS
st partagé
diés au réf
ns concerna
vers le Sch
banquedud
eur adhéren
n du référ
est à priv
cité aux d
cord de ré
in2015
ivation du
e 1). Cett
n écosystè
cier dispo
T valider
images et
ectuée, la
nouvelle
au message
end les ac
la finalis
S
entre les
férentiel i
ant un créa
heme qui es
débiteurco
nte à RUBIS
entiel RUB
ilégier)
ébiteurs d
ception de
u service R
te procédur
ème SEPAMai
ose d'un IC
les élémen
t logos tra
a banque du
entrée dan
e CreditorA
ccusés de r
sation de l
banques au
icqx@schem
ancier ins
st le gest
oncernantl
S doit met
BIS auprès
de s’inscr
es demandes
RUBIS inscr
re peut êtr
il (secure
CQX, et don
nts remis p
ansmis (puc
u créancier
ns le référ
ActivationA
réception d
la diffusio
u travers
e. Tous le
crit dans
ionnaire d
leserviced
tre en pla
des débite
rire auprès
s de règlem
ription se
re manuelle
ou scheme,
nc qu'il a
par le créa
ce 2).
r informe
rentiel RUB
Advise de
des différe
on (puce 4)
de message
s adhérent
le référen
u référent
d'inscription
ce les fon
eurs sur au
s d'un créa
ments par R
lon la pro
e ou élect
, par exem
it déjà ét
ancier, en
les autres
BIS (puce
la famille
entes banq
).
es spécifiq
ts SEPAmail
ntiel icqx@
tiel.
nRUBIS
nctions néc
u moins un
ancier pou
RUBIS. Cet
Page
océdure
ronique et
mples). Cet
é créé au
n particuli
banques e
3). Cette
e scheme.
ques et peu
ques de
l peuvent
@scheme, so
cessaires
n canal (la
ur lui
te fonctio
e107
t/ou
tte
ier
et
ut
oit
:
a
on
SEP
Le m
chezet d
bonn
affe
Pour
cont
le d
Deux
AmailNorm
permet
de la f
message d'
z le créandu prénom
ne référen
ectation.
r aider le
tienne des
débiteur p
x exemples
me1206–Éd
l'envoi de
famille RUB
inscriptio
ncier. En equi peuven
ce client.
débiteur
éléments
eut trouve
possibles
ditiondeJui
es coordon
BIS.
on permet d
effet, une
nt avoir un
Il reste
à saisir l
de communi
er cette ré
s dans l'im
in2015
nées du dé
de véhicule
telle info
ne homonymi
bien sûr à
la bonne ré
ication ave
éférence.
mage suivan
ébiteur (QX
er un champ
ormation e
ie, pour qu
à la charg
éférence,
ec le débi
nte.
XBAN) au mo
p représen
st nécessa
u'il puiss
e du créan
il a été p
teur, dont
oyen du mes
tant la réire au cré
e affecter
cier la vé
révu que l
au moins
ssage Acti
éférence deéancier, en
r le QXBAN
érification
le référent
une image
Page
vationEnro
de ce clientn plus du n
reçu à la
n de cette
tiel RUBIS
indiquant
e108
oll
nt nom
où
SEP
Cett
créa
Le m
déb
anal
adéq
d'ex
Lors
règl
Act
reçu
AmailNorm
te image,
ancier lor
Désinsc
même messa
iteur, peu
lyse, cett
quate des
xpérimenta
Gestion
squ'un cré
lement ver
ivationEnr
ue au seul
me1206–Éd
fournie pa
s de la de
criptionaup
ge Activat
t aussi se
e fonction
messages s
tion.
nsoupleen
ancier est
s un débit
oll, la ba
motif de
ditiondeJui
ar le créan
emande d'ac
prèsd'unc
tionEnroll,
ervir en ca
n, si elle
suivants ve
l'absenced
t présent d
teur ne s'é
anque du dé
l'absence
in2015
ncier, doit
ctivation d
créancier
utilisé p
as de désin
est propos
enant de ce
d'inscriptio
dans le réf
étant pas i
ébiteur ne
du message
t faire l'
du service
pour inform
nscription
sée à un d
e créancier
onpréalabl
férentiel R
inscrit aup
doit pas r
e Activati
objet d'un
RUBIS ins
mer le cré
souhaitée
ébiteur, d
r. Les règ
edudébite
RUBIS et q
près de lu
rejeter d'
onEnroll p
contrôle
cription p
ancier de
de celui-
oit être c
les devron
eur
u'il émet
i par un m
emblée la
réalable.
par la Ban
par le créa
l'inscript
-ci. En pre
couplée ave
nt être pré
une demand
message
demande de
Page
nque du
ancier.
tion d'un
emière
ec une gest
écisées en
de de
e règlement
e109
tion
fin
t
SEPAmailNorme1206–ÉditiondeJuin2015 Page110
5.6. Lagestiondesflux(RUBIS)Initiationdelatransaction
RUBIS part du principe (de bon sens) que celui qui veut recevoir les fonds (le créancier) doit
être à l’initiation du processus et ce pour les raisons suivantes :
Le créancier est le plus intéressé pour la réalisation du transfert des fonds, et donc
doit être le responsable de la supervision du processus de paiement
Le créancier peut définir dès l’initiation du processus les références qui lui
permettront de traiter le mouvement de fonds en automatique (Straight Trough
Processing).
En initiant la transaction (demande de règlement), le créancier prend date et pourra
ainsi faire état de sa demande en cas de litige.
Remarque : cette description est conforme au processus habituel de paiement dans lequel le
créancier envoie une facture (ou facture pro forma, quittance, ...) avant de recevoir le
paiement.
Circulationdesfluxentrecréancieretdébiteur
La circulation des flux se fait en respectant le modèle 4 coins : créancier, banque du
créancier, banque du débiteur, débiteur.
1. Envoi de la demande de paiement comportant
1. Les références de la demande de règlement, qui serviront de références pour le virement (libellé, end2end, ultimate, sur la base des champs du virement SEPA)
2. Le montant
SEP
Les
doub
AmailNorm
3.
4.
1. Accepta
2. Générat(débite
3. viremen
4. Récepti
5. Contrôldemande
Leprin
flux préc
ble intérê
sécuris
débiteu
articul
le créa
1.
le créa
me1206–Éd
Le compte
D’éventue
à disposit
ation par l
tion d’un
eur)
nt de fonds
ion des fon
le et dénot
e de règlem
cipedefon
édents son
t :
ser les flu
ur
ler ces flu
ancier et l
garantissa
ancier (fut
ditiondeJui
du créanci
elles infor
tion du ser
le débiteu
message d
s réalisé
nds
tage du vi
ment émise
nctionneme
nt mis en œ
ux de dema
ux avec ce
le débiteu
ant ainsi l
tur payé)
in2015
ier à crédi
rmations co
rvice
r en donna
e retour e
par la ban
rement, de
par le cr
entRUBIS
œuvre en ut
nde de règ
ux liés au
r adhèrent
l'authentif
envoie un
iter
omplémenta
ant un ordr
en confirma
nque du déb
e la confir
réancier
tilisant l
glement et
u virement
t chacun au
fication d
message "d
ires sur l
re de règle
ant l’acce
biteur vers
rmation de
a messager
de réponse
u système a
es acteurs
demande de
a livraiso
ement à sa
eptation pa
s la banque
règlement
ie SEPAmai
e entre le
auprès de
pour le s
règlement"
on des bien
banque
ar le donn
e du créan
vis-à-vis
il, ce qui
créancier
leur banqu
service
" au débit
Page
ns ou la m
neur d’ord
ncier
de la
présente l
r et le
ue respecti
eur (payeu
e111
ise
dre
le
ive
ur
SEPAmailNorme1206–ÉditiondeJuin2015 Page112
1. en valorisant la messagerie SEPAmail pour gérer les erreurs d'acheminement et de non disponibilité
le payeur doit valider systématiquement la demande pour qu'elle puisse être réglée
1. charge à la banque du débiteur de mettre en œuvre les outils permettant cette validation
le créancier est informé de la validation du débiteur
1. suivant les cas cette information peut être de différentes natures : ordre donné à sa banque par le débiteur de procéder au transfert, transfert en exécution,
assurance donnée par la banque du débiteur que le transfert sera réalisé
le règlement se fait directement entre la banque du débiteur et la banque du créancier
en utilisant les circuits SEPA existants
le règlement se fait à la date prévue entre le débiteur et le créancier
1. le règlement ne peut pas se faire avant l'acceptation par le débiteur, il peut être immédiat ou différé suivant les indicateurs positionnés par le créancier et
la demande du débiteur
la banque du débiteur envoie les références de dénotage fournies par le créancier
1. le virement complété suivant les normes RUBIS permet au créancier de pouvoir dénoter uniquement à partir des données reçues dans le relevé électronique
Lesfluxentreuncréancieretsondébiteur
Ce schéma reprend les flux à l’initiative d’un créancier-facturier une fois le créancier en
possession de l’identifiant du payeur.
SEPAmailNorme1206–ÉditiondeJuin2015 Page113
1. Le créancier envoie une demande de règlement (puce 1) reprenant les éléments obligatoires et/ou optionnels décrits dans les directives du message RUBIS payment-request.
2. La banque du créancier complète avec le BIC et route vers la banque du débiteur (puce 2)
1. La banque du débiteur émet un accusé réception (puce 2bis, réponse protocolaire SEPAmail, présente dans toutes les applications et non spécifique à RUBIS)
permettant d’indiquer que le message a été reçu et qu’il est mis à disposition
du client (ou non suivant les cas : IBAN inconnu, service non accessible, …)
2. La banque du débiteur (puce 3) offre sur les canaux définit dans son offre commerciale la mise à disposition pour validation de la demande de règlement. L’avertissement (SMS,
email, autre) du client de l’arrivée d’une demande est à la discrétion de la banque du
débiteur et hors du champ de RUBIS. Le choix du compte du virement est un service
pouvant être offert par la banque du payeur.
3. Une fois validé, une confirmation de l’ordre de règlement (payment-report, puce 4) est
envoyée à la banque du créancier. Différents codes réponses peuvent préciser cette
confirmation : refus, acceptation avec règlement en attente, acceptation avec règlement
garantie, acceptation avec règlement en compensation.
1. une réponse protocolaire SEPAmail est envoyée à la banque du débiteur par la banque du créancier (puce 4bis)
4. La banque du créancier route vers le créancier la confirmation (puce 5).
5. La banque du débiteur émet, le cas échéant, le virement (puce 6) en conformité avec la demande de son client-payeur et sur la base des données remplies dans le payment-request
(flux 1).
6. Le relevé électronique du créancier (AFB120 ou autre format, puce 7) reprend les données inscrites dans le virement SEPA permettant ainsi une réconciliation automatique des flux
émis (puce 1) et des virements reçus (puce 6).
Ce schéma met aussi en évidence les 4 domaines utilisés par RUBIS :
domaine concurrentiel entre une banque et son créancier
domaine coopératif SEPAmail entre la banque du créancier et la banque du débiteur
domaine concurrentiel entre la banque du débiteur et le débiteur
domaine coopératif SEPA
Lesfluxentredeuxparticuliers
Ces flux peuvent s'étendre à deux entités quelconques : particuliers, entreprises,
administrations. En effet RUBIS réalise des demandes de règlements IBAN vers IBAN sans préjuger
de la nature juridique ou organisationnelle de l'entité gérant cet IBAN.
SEPAmailNorme1206–ÉditiondeJuin2015 Page114
SEP
RUBI
Les
AmailNorm
5.7. IS fait ap
Normes
Normes
règleme
Normes
Normes
Normes
Normes
Bien qu
définit
l'évolu
normes su
SEPAmai
banque
SEPAmai
PACS 00
me1206–Éd
Lesnorpel à diff
SEPA, pour
SEPAmail-m
ents et d'a
SEPAmail p
bancaires
SEPAmail-R
SEPAmail-R
ue la relat
t un standa
ution de le
ivantes so
il - RUBIS
du créanci
il - RUBIS
08 si virem
ditiondeJui
rmesuférents nor
r les vire
messagerie
annuaires
pour l'ide
pour l'id
RUBIS pour
RUBIS pour
tion Banqu
ard princi
eurs systè
ont utilisé
Activatio
ier
Activatio
ment effec
in2015
utiliséesrmes et sta
ments SCT
, pour les
ntificatio
entificati
la struct
la struct
e-client s
palement à
mes en cas
ées :
nRequest p
nReport po
tif
sparRandards ex
s échanges
on des acte
ion des act
turation de
turation de
soit dans l
à l'usage d
s de change
pour la dem
our la conf
RUBISistants.
interbanca
eurs au tra
teurs au tr
es données
es données
le domaine
des entrepr
ement de ba
mande initi
firmation p
aires des f
avers du QX
ravers de
en Interba
dans la re
compétitif
rises pour
anque.
iale et la
par la banq
flux de de
XBAN
l'IBAN
ancaire
elation ba
f, SEPAmai
éviter à
transmiss
que du cré
Page
emandes de
anque-clien
l-RUBIS
celle-ci
ion par la
éancier
e115
nt.
a
SEP
La t
est
dema
Pour
norm
AmailNorm
5.8. troisième
la capaci
ande RUBIS
r garantir
mes RUBIS
l'Activ
dans le
l'Activ
débiteu
le vire
me1206–Éd
Lelettrcomposante
té pour un
.
cette com
décrivant
vationReque
e schéma)
vationRepor
ur (puce 4
ement SEPA
ditiondeJui
ragedee de RUBIS,
n créancier
mposante, l
le lien en
est (compo
rt (compor
dans le s
au format
in2015
esvirem outre le
r de lettre
la banque d
ntre :
rtant un o
tant un ou
chéma)
pacs.008
ments(référenti
er en autom
du débiteur
ou plusieur
u plusieurs
(puce 6 da
(RUBISel et la d
matique le
r a dans l
rs pain.013
s pain.014)
ans le sché
S)emande de
s virement
'obligatio
3) émis par
) renvoyé p
éma)
règlement
ts à partir
on de respe
r le créan
par la ban
Page
électroniq
r d'une
ecter les
ncier (puce
nque du
e116
que,
e 1
SEPAmailNorme1206–ÉditiondeJuin2015 Page117
5.9. Lesrèglesmétier(RUBIS)Objetdudocument
Ce document décrit le mécanisme global du système SEPAmail de demande de règlement. Il est
destiné à des interlocuteurs fonctionnels, les éléments techniques figurant dans les directives
correspondantes (implementation guidelines).
Présentationgénérale
Le système SEPAmail se compose :
d’un réseau interbancaire sécurisé assurant le transport de messages structurés
conforment aux normes partagées par les utilisateurs de SEPAmail. Le réseau SEPAmail se
déploie par l’interconnexion entre des serveurs logiciels installés dans chaque
établissement adhérent.
de services métiers à valeur ajoutée, mutualisables, supportés par le système SEPAmail
au travers de l’utilisation d’une famille de messages structurés liés à chaque service
métier mis en ligne sur ce réseau.
L'un de ces services métier est RUBIS, qui vise à établir un ensemble de règles et d'outils
permettant de gérer des demandes de règlements électroniques dont le règlement est validé par
le débiteur :
création des demandes de règlement par le créancier
validation par le débiteur
gestion d’un référentiel des créanciers
capacité d’inscription des débiteurs auprès des créanciers
MessagesdelafamilleRUBIS
RUBIS est l'application SEPAmail utilisant l'écosystème payment.activation.
Dans cet écosystème, trois messages ont été définis à ce jour :
PaymentActivationRequest
PaymentActivationReport
PaymentActivationEnroll
Nous allons décrire en détail l'utilisation de ces messages et les règles associées.
Lemessagededemandederèglement
Ce message est utilisé, à l'initiative du créancier (émetteur), pour demander le versement
d'une somme déterminée.
Si le débiteur (destinataire) répond, ce sera obligatoirement par le biais d'un message de
réponse à demande de règlement (PaymentActivationReport, décrit plus loin), et ce quelle que
soit la nature de sa réponse. Notez que le message de demande de règlement peut aussi être
purement et simplement ignoré par le destinataire.
Si le règlement demandé (ou plus exactement, l'un des règlements demandés) est accepté, il est
du ressort de l'adhérent de déclencher éventuellement un ou des paiements associés.
Le message est fondé sur le message pain.013 de la norme ISO 20022,
CreditorPaymentActivationRequest, auquel sont ajoutées des informations spécifiques à RUBIS.
Toutefois, il est important de noter qu'un seul message de demande de règlement peut contenir
plusieurs messages pain.013, par exemple si le créancier souhaite proposer plusieurs modalités
de paiement (comptant avec escompte, trois fois sans frais, ...).
SEPAmailNorme1206–ÉditiondeJuin2015 Page118
Lemessagederéponseàdemandederèglement
Ce message peut être utilisé dans deux cas d’usage distincts :
à l'initiative du débiteur, après réception d'un message de demande de règlement. Dans
ce cas, il indique si le débiteur accepte l’une ou l’autre des modalités de paiement
proposées, ou les refuse toutes. Il permet également au débiteur d'exercer des options
(paiement immédiat ...), voire de proposer un autre mode de paiement. Si ce message
contient acceptation de règlement, il peut déclencher, à l'initiative de l'adhérent, un
ordre en vue de la réalisation du paiement.
Exemple : - acceptation de la DDR, - refus de la DDR, - refus après acceptation, - voire acceptation après refus.
à l'initiative de la banque du débiteur, dans le cadre de ses relations contractuelles
avec son client, pour indiquer une évolution de l'état de la demande de virement.
Exemples : - Avant remise au client : si le client n’est pas atteignable, - Après décision du client pour informer de l’état d’avancement du
paiement : virement rejeté par la banque, virement exécuté par la banque …
Le message PaymentActivationReport est fondé sur le message pain.014 de la norme ISO 20022,
CreditorPaymentActivationRequestStatusReport, auquel sont ajoutées des informations spécifiques
à RUBIS. De même que le message de demande de règlement peut contenir plusieurs pain.013, un
message de réponse peut contenir plusieurs pain.014. Les règles suivantes s'appliquent aux deux
cas d’usage précités :
les pain.013 et pain.014 sont appariés par le paramètre « identification de
l'information de paiement » du pain.013.
un seul pain.014, dans le message de retour, peut représenter la modalité de paiement
acceptée.
en revanche, il peut y avoir plusieurs pain.014 avec des modalités de paiement refusées
(état RJCT).
si toutes les modalités de paiement sont refusées et que le débiteur désire communiquer,
alors tous les pain.013 reçus doivent être renvoyés sous forme de pain.014 à l'état
RJCT.
après avoir accepté ou refusé une modalité de paiement, le débiteur reste toujours libre
de signifier un refus ou une acceptation. le mandat de la banque du débiteur impose
alors que la banque du créancier soit informée de ce nouveau choix du débiteur.
Il est donc possible d'envoyer plusieurs messages PaymentActivationReport en réponse au même
message PaymentActivationRequest pour traduire l'évolution de la prise en compte de la demande
de règlement.
SEPAmailNorme1206–ÉditiondeJuin2015 Page119
Lemessaged'inscriptionauservice
Par des canaux externes à SEPAmail32, un débiteur peut être invité par l'un de ses créanciers à
utiliser le système RUBIS pour le règlement de ses futures factures. En réponse à ce message,
le débiteur peut accepter ou non l'usage de ce système, et préciser certains modes de
fonctionnement. Un message d'inscription au service, PaymentActivationEnroll, est alors envoyé.
Ce message peut également être envoyé dans tous les cas de modification de l'inscription :
changement de coordonnées bancaires
désinscription
Ce message est strictement non-ISO.
SEPAmailNorme1206–ÉditiondeJuin2015 Page120
5.10. Lagestiondesrefusaprèsacceptationetavantéchéance(RUBIS)
Pour couvrir les besoins émis par les créanciers et les débiteurs, RUBIS permet, dans le
formatage des messages par le créancier :
le paiement dès l'acceptation
le paiement à date
Cette possibilité se ramifie en fonction de la complexité des interfaces proposées par une
banque de débiteur : de l'interface très simple de règlement immédiat à des interfaces
sophistiquées pouvant impliquer des offres de crédits à l'occasion de ce règlement.
Dans le cas d'un paiement à échéance, le débiteur donne son accord pour 2 éléments :
l'envoi d'une notification, le payment-report
la demande d'un ordre de virement à sa banque pour l'échéance choisie.
La Directive des Services de Paiement, autorise tout client à révoquer un ordre de paiement
tant que celui-ci n'a pas été pris en compte pour exécution, en général la veille en fin
d'après-midi de la date interbancaire du virement.
Pour garder cohérent les flux RUBIS et ceux de virement, la banque du débiteur ne peut accepter
un ordre d'annulation de l'ordre initial de virement que si elle envoie un avis payment-report
correspondant. La banque du débiteur devrait prévoir ce point tant dans ses interfaces avec ses
clients que dans sa relation contractuelle.
SEP
Voic
AmailNorm
5.11. ci les mes
message
message
message
me1206–Éd
Lerécasages poss
e SEPAmail
e SEPAmail
e SEPAmail
ditiondeJui
apitulasibles pour
Demande d
Réponse à
Inscripti
in2015
tifdesr RUBIS :
e règlemen
demande d
on d'un dé
messag
nt
de règlemen
ébiteur aup
ges(RU
nt
près d'un c
UBIS12
créancier
206)
Page
e121
SEPAmailNorme1206–ÉditiondeJuin2015 Page122
5.12. IGpayment.activationL'écosystème payment.activation comporte trois messages :
Nom Directives d'implémentation Schéma
ActivationReport Standards
1206:IG_Rubis_ActivationReport
Schéma
ActivationRequest Standards
1206:IG_Rubis_ActivationRequest
Schéma
ActivationEnroll Standards
1206:IG_Rubis_ActivationEnroll
Schéma
SEPAmailNorme1206–ÉditiondeJuin2015 Page123
5.13. IGRubisActivationRequestReference document
The underlying message, pain.013.001.01, is described by an ISO 20022 document, entitled "Creditor Payment Activation Request : Message Definition Report", in its October 2010 version, with which the reader should be familiar.
It is available directly from ISO 20022 [http://www.iso20022.org/documents/general/Creditor_Payment_Activation_Request.zip here].
Introduction
This document describes the contents of the SEPAmail RUBIS message used to request payment from a debtor.
The full name of this message is sepamail_message_payment.activation_PaymentActivationRequest.
This message is normally generated and sent by the creditor to its bank, which then forwards it to the debtor's bank, for final validation by the debtor.
The answer to this message is always a PaymentActivationReport message, accepting or rejecting the payment. A second PaymentActivationReport message may be sent later, if the payment is accepted by the debtor, but could not be settled.
This message contains one or several ISO pain.013 structures. For adaptability reasons, this message also includes non-ISO parts. All message parts are described in this document
Header
Ref. Mult. Ch. DepthMessage element
Requirements
A [1..1] + Header SEPAMAIL rule
Global header for message
A1 [1..1] ++ CreationDateTime
SEPAMAIL rule
Creation date and time, ISO format
If checked, when the value is too far in the past or in the future, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
MAP TO This structure must not be copied into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /Header
SEPAmailNorme1206–ÉditiondeJuin2015 Page124
rule /CreDtTm] (A1) within the [RUBIS Payment Activation Report] message that refers to the creation timestamp of the paymentActivationReport itself.
A2 [1..1] ++ NbOfRequests
SEPAMAIL rule
In #1206 version of the SEPAmail standard, only one occurrence of ReqCompl is allowed
If checked, when the value is not equal to 1, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
SEPAMAIL rule
Number of ReqCompl elements contained in the message
If checked, when the value is different from the count of 'ReqCompl' structures, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
A3 [0..*] ++ Documents
SEPAMAIL rule
Any document justifying the payment request
MAP TO rule
The enclosed documents within this structure must not be copied into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /Header /Documents] (A3) within the [RUBIS Payment Activation Report] message.
A3.1 [1..1] +++ Type SEPAMAIL rule
Type of document attached. Possible values are 'mandate', 'invoice' and 'information'. In this message, only the last two values should be used. This field is valued by the creditor under its own responsibility and is not supposed to be controlled by the SEPAmail member.
If checked, when the value is not equal to 'invoice' or 'information', then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
A3.2 [0..1] +++ Date SEPAMAIL rule
reference date of the document
A3.3 [1..1] +++ Title SEPAMAIL rule
title of the document
A3.4 [1..1] +++ Reference SEPAMAIL rule
internal reference
A3.5 [1..1] +++ Lang SEPAMAIL language used on the document, 2-letter code
SEPAmailNorme1206–ÉditiondeJuin2015 Page125
rule
A3.6 [0..1] +++ Contents
A3.6.1 [1..1] ++++ mime-type
SEPAMAIL rule
Type of data in the document.
SEPAMAIL rule
Usage rule: only the following values can be used: image/gif, image/jpeg, image/png, image/vnd.microsoft.icon, application/pdf.
SEPAMAIL rule
In #1206 version of the SEPAmail standard, only 'application/pdf' is allowed
If checked, when the value is not equal to 'application/pdf', then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
A3.6.2 [0..1] ++++ name SEPAMAIL rule
original document name
A3.6.3 [1..1] ++++ data SEPAMAIL rule
actual document contents
If checked, when the document cannot be proccessed according to the declared mime-type, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
ISO and Non-ISO parts
Each RequestAndComplements element describes one proposed payment modality. If the creditor wishes to offer several payments modalities (e.g. immediate or in three monthly installments), several ReqCompl elements must be present in the message. The debtor will then choose the one s/he wishes to use, if any.
Each ReqCompl element has the following contents:
Ref. Mult. Ch. DepthMessage element
Requirements
B [1..*] + ReqCompl SEPAMAIL rule
Mandatory for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page126
SEPAMAIL rule
In #1206 version of the SEPAmail standard, only one occurrence of ReqCompl is allowed
SEPAMAIL rule
ISO + non-ISO parts, described further in this document. This element must be present as many times as described by the NbOfRequests element, in the header.
B1 [1..1] ++ Request
ISO20022 rule
R1 Grouping1Rule If GroupHeader/Grouping is present and equals GRPD, then one and only one occurrence of PaymentInformation must be present.
ISO20022 rule
R2 Grouping2Rule If GroupHeader/Grouping is present and equals SNGL, then each occurrence of PaymentInformation must contain one and only one occurrence of PaymentInformation /CreditTransferTransactionInformation.
SEPAMAIL rule
CreditorPaymentActivationRequest, as per ISO 20022 pain.013.001.01
B2 [1..1] ++ Complements SEPAMAIL rule
Non-ISO part, described further in this document
ISO Part : CreditorPaymentActivationRequestV01
Please note : this whole part is directly copied from ISO20022 documents, and is only provided here for ease of reference. The indices in first column match the ones in this document.
Ref. Mult. Ch. Depth Message element Requirements
1.0 [1..1] + GroupHeader ISO20022 rule
Set of characteristics shared by all individual transactions included in the message.
1.1 [1..1] ++ MessageIdentification
ISO20022 rule
Point to point reference assigned by the instructing party and sent to the next party in the chain to unambiguously identify the message.
ISO20022 rule
Usage: The instructing party has to make sure that 'MessageIdentification' is unique per instructed party for a pre-agreed period.
If checked, when the uniqueness of the value has not been complied, then the Reason Code to use within the REJECT is 'DU01' (DuplicateMessageID).
SEPAmailNorme1206–ÉditiondeJuin2015 Page127
SEPAMAIL rule
Will be used in the pain.014 reply (2.1 OriginalMessageIdentification) to allow reconciliation.
MAP TO rule
This structure must not be copied into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /GrpHdr /MsgId] (1.1) within the [RUBIS Payment Activation Report] message that shall be set by the party who sends the PaymentActivationReport.
MAP TO rule
Each occurrence of this structure must be copied into the relevant occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlGrpInfAndSts /OrgnlMsgId] (2.1) within the [RUBIS Payment Activation Report] message in order to allow the reconciliation of the PaymentActivationRequest and the PaymentActivationReport.
1.2 [1..1] ++ CreationDateTime
ISO20022 rule
Date and time at which a (group of) payment instruction(s) was created by the instructing party.
If checked, when the value is too far in the future, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
SEPAMAIL rule
This is a technical date, which may be different from the same field in main message
MAP TO rule
This structure must not be copied into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /GrpHdr /CreDtTm] (1.2) within the [RUBIS Payment Activation Report] message that refers to the creation timestamp of the paymentActivationReport itself.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlGrpInfAndSts /OrgnlCreDtTm] (2.3) within the [RUBIS Payment Activation Report] message must be either omitted or copied from this structure.
1.3 [1..1] ++ NumberOfTransactions
ISO20022 rule
Number of individual transactions contained in the message.
If checked, when the value is different from 'Payment Information' structures count, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
SEPAMAIL rule
In #1206 version of the SEPAmail standard, only one occurrence of 'Payment Information' is allowed.
If checked, when the value is not equal to 1, then the Reason Code to use within the REJECT is 'FF01'
SEPAmailNorme1206–ÉditiondeJuin2015 Page128
(Invalid File Format).
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlGrpInfAndSts /OrgnlNbOfTxs] (2.4) within the [RUBIS Payment Activation Report] message must be either omitted or copied from this structure.
1.4 [0..1] ++ ControlSum
ISO20022 rule
Total of all individual amounts included in the message, irrespective of currencies.
If checked, when the value is not equal to the total of individual transactions, then the Reason Code to use within the REJECT is 'AM10' (InvalidControlSum).
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlGrpInfAndSts /OrgnlCtrlSum] (2.5) within the [RUBIS Payment Activation Report] message must be either omitted or copied from this structure.
1.5 [1..1] ++ InitiatingParty
ISO20022 rule
Party initiating the creditor payment activation request. This can either be the creditor himself or the party that initiates the request on behalf of the creditor.
SEPAMAIL rule
Name of the party sending the message (Nm) is mandatory if it is not a bank, BIC (in Id) is mandatory if it is a bank.
If checked, when the structure is not set according to the IG rule, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
MAP TO rule
This structure must not be copied into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /GrpHdr /InitgPty] (1.3) within the [RUBIS Payment Activation Report] message that refers to the party who creates the PaymentActivationReport.
See details below
2.0 [1..*] + PaymentInformation
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Set of characteristics that applies to the debit side of the payment transactions included in the creditor payment initiation.
ISO20022 R5 PaymentTypeInformationRule
SEPAmailNorme1206–ÉditiondeJuin2015 Page129
rule If PaymentTypeInformation is present, then CreditTransferTransaction/PaymentTypeInformation is not allowed.
ISO20022 rule
R9 UltimateDebtorGuideline UltimateDebtor may only be present if different from Debtor.
ISO20022 rule
R14 ChargeBearerRule If ChargeBearer is present, then CreditTransferTransaction/ChargeBearer is not allowed. If CreditTransferTransaction/ChargeBearer is present, then ChargeBearer is not allowed. CreditTransferTransaction/ChargeBearer and ChargeBearer may both be absent.
SEPAMAIL rule
In #1206 version of the SEPAmail standard, only one occurrence of 'Payment Information' is allowed.
2.1 [0..1] ++ PaymentInformation-Identification
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Reference assigned by a sending party to unambiguously identify the payment information block within the message.
If checked, when the uniqueness of the value is not complied, then the Reason Code to use within the REJECT is 'DU02' (DuplicatePaymentInformationID).
SEPAMAIL rule
Will be sent back by Report message for matching purposes between Request and Report.
MAP TO rule
Each occurrence of this structure must be copied into the relevant occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /OrgnlPmtInfId] (3.1) within the [RUBIS Payment Activation Report] message.
MAP TO rule
Each occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Complements /PmtModif /PmtId] (B2.5.1) within the [RUBIS Payment Activation Report] message must be copied from the relevant occurrence of this structure in case of modification of the amount by the debtor.
2.2 [1..1] ++ PaymentMethod
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Specifies the means of payment that will be used to move the amount of money.
SEPAmailNorme1206–ÉditiondeJuin2015 Page130
SEPAMAIL rule
The only value currently accepted here is "TRF". Note: if the OtherPmtMtd field, in the non-ISO part, is used, this field will be ignored.
If checked, when the value is not equal to 'TRF', then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
MAP TO rule
Each occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /PmtMtd] (3.68) within the [RUBIS Payment Activation Report] message must be either omitted or copied with the relevant occurrence of this structure.
2.3 [0..1] ++ PaymentTypeInformation ISO20022 rule
Set of elements used to further specify the type of transaction.
2.4 [0..1] +++ InstructionPriority SEPAMAIL rule
Not Allowed for SEPAmail
2.5 [0..1] +++ ServiceLevel SEPAMAIL rule
Not Allowed for SEPAmail
2.8 [0..1] +++ LocalInstrument SEPAMAIL rule
Not Allowed for SEPAmail
2.11 [0..1] +++ CategoryPurpose
ISO20022 rule
Specifies the high level purpose of the instruction based on a set of pre-defined categories.
ISO20022 rule
Usage: This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain.
MAP TO rule
Each occurrence of this structure must be copied into the relevant occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /PmtTpInf /CtgyPurp] (3.65) within the [RUBIS Payment Activation Report] message.
2.12 [1..1] | ++++ Code ISO20022 rule
Category purpose, as published in an external category purpose code list.
2.13 [1..1] | ++++ Proprietary ISO20022 rule
Category purpose, in a proprietary form.
2.14 [1..1] ++ RequestedExecutionDate ISO20022 Date at which the initiating party requests the clearing agent to process the payment. If payment by cheque, the
SEPAmailNorme1206–ÉditiondeJuin2015 Page131
rule date when the cheque must be generated by the bank.
ISO20022 rule
Usage: This is the date on which the debtor's account(s) is (are) to be debited.
If checked, when the value is too far in the future, then the Reason Code to use within the REJECT is 'CH03' (RequestedExecutionDateOrRequestedCollectionDateTooFarInFuture).
If checked, when the value is too far in the past, then the Reason Code to use within the REJECT is 'CH04' (RequestedExecutionDateOrRequestedCollectionDateTooFarInPast).
SEPAMAIL rule
Mandatory.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /ReqdColltnDt] (3.40) within the [RUBIS Payment Activation Report] message must be either omitted or copied from this structure
2.15 [1..1] ++ Debtor
ISO20022 rule
Party that owes an amount of money to the (ultimate) creditor.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /Dbtr] (3.119) within the [RUBIS Payment Activation Report] message must be copied from this structure.
See details below
2.16 [0..1] ++ DebtorAccount
ISO20022 rule
Account used to process charges associated with a transaction.
SEPAMAIL rule
Mandatory: IBAN (or QXBAN)
If checked, when the value is missing, then the Reason Code to use within the REJECT is 'RR01' (Missing Debtor Account or Identification).
If checked, when the specified account does not exist or cannot be reached, then the Reason Code to use within the REJECT is 'AC01' (IncorrectAccountNumber).
If checked, when the specified account cannot be used due to legal reason, then the Reason Code to use within the REJECT is 'AG01' (TransactionForbidden).
If checked, when the debtor does not accept requests from this creditor, then the Reason Code to use within the REJECT is 'SL01' (Specific Service offered by Debtor Agent).
If checked, when the specified account cannot be used for this application, then the Reason Code to use within the REJECT is 'AG03' (TransactionNotSupported).
If checked, when the specified account is closed, then the Reason Code to use within the REJECT is
SEPAmailNorme1206–ÉditiondeJuin2015 Page132
'AC04' (ClosedAccountNumber).
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /DbtrAcct] (3.120) within the [RUBIS Payment Activation Report] message must be copied from this structure, though the copy of the following substructures is optional: - Type - Currency - Name
2.16/2.1.0 [1..1] +++ Identification
2.16/2.1.1 [1..1] | ++++ IBAN ISO20022 rule
IBAN A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.
If checked, when the value does not comply with IBAN format, then the Reason Code to use within the REJECT is 'AC01' (IncorrectAccountNumber).
2.16/2.1.2 [1..1] | ++++ BBAN SEPAMAIL rule
Not Allowed for SEPAmail
2.16/2.1.3 [1..1] | ++++ UPIC SEPAMAIL rule
Not Allowed for SEPAmail
2.16/2.1.4 [1..1] | ++++ ProprietaryAccount SEPAMAIL rule
Not Allowed for SEPAmail
2.16/2.1.6 [0..1] +++ Type
2.16/2.1.7 [1..1] | ++++ Code
2.16/2.1.8 [1..1] | ++++ Proprietary
2.16/2.1.9 [0..1] +++ Currency
2.16/2.1.10 [0..1] +++ Name
2.17 [1..1] ++ DebtorAgent
ISO20022 rule
Financial institution servicing an account for the debtor.
SEPAMAIL rule
Mandatory (AT-13 BIC of the Debtor Bank) Usage Rule: Only BIC is allowed.
SEPAmailNorme1206–ÉditiondeJuin2015 Page133
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /GrpHdr /DbtrAgt] (1.4) within the [RUBIS Payment Activation Report] message must be either omitted or copied from this structure.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /DbtrAgt] (3.121) within the [RUBIS Payment Activation Report] message must be copied from this structure.
2.17/3.1.0 [1..1] +++ FinancialInstitution-Identification
ISO20022 rule
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
2.17/3.1.1 [0..1] ++++ BICFI
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAMAIL rule
BICFI Valid BICs for financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE and BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
If checked, when the BIC is not registered, then the Reason Code to use within the REJECT is 'RC01' (BankIdentifierIncorrect).
If checked, when the value is not consistant with the account id, then the Reason Code to use within the REJECT is 'RC01' (BankIdentifierIncorrect).
2.17/3.1.2 [0..1] ++++ ClearingSystem-MemberIdentification
SEPAMAIL rule
Not Allowed for SEPAmail
2.17/3.1.7 [0..1] ++++ Name SEPAMAIL rule
Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page134
2.17/3.1.8 [0..1] ++++ PostalAddress SEPAMAIL rule
Not Allowed for SEPAmail
2.17/3.1.19 [0..1] ++++ Other SEPAMAIL rule
Not Allowed for SEPAmail
2.17/3.1.25 [0..1] +++ BranchIdentification SEPAMAIL rule
Not Allowed for SEPAmail
2.18 [0..1] ++ UltimateDebtor
ISO20022 rule
R9 UltimateDebtorGuideline UltimateDebtor may only be present if different from Debtor.
ISO20022 rule
G2 UltimateDebtorGuideline UltimateDebtor may only be present if different from Debtor.
ISO20022 rule
Ultimate party that owes an amount of money to the (ultimate) creditor.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /UltmtDbtr] (3.118) within the [RUBIS Payment Activation Report] message must be copied from this structure. However, the copy of the substructures is only mandatory for data that will be eventually forwarded within the SEPA Credit Transfer Core Mandatory Subset (*). The other data may optionally be copied.
See details below
2.19 [0..1] ++ ChargeBearer SEPAMAIL rule
Not Allowed for SEPAmail
2.20 [1..*] ++ CreditTransferTransaction
ISO20022 rule
Payment processes required to transfer cash from the debtor to the creditor.
ISO20022 rule
G1 UltimateCreditorGuideline UltimateCreditor may only be present if different from Creditor.
ISO20022 rule
G2 UltimateDebtorGuideline UltimateDebtor may only be present if different from Debtor.
SEPAMAIL rule
Usage Rule: only one occurrence of this structure can be used.
SEPAmailNorme1206–ÉditiondeJuin2015 Page135
2.21 [1..1] +++ PaymentIdentification ISO20022 rule
Set of elements used to reference a payment instruction.
2.22 [0..1] ++++ InstructionIdentification
ISO20022 rule
Unique identification as assigned by an instructing party for an instructed party to unambiguously identify the instruction. Usage: the instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.
MAP TO rule
Each occurrence of this structure must be copied into the relevant occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlInstrId] (3.17) within the [RUBIS Payment Activation Report] message.
2.23 [1..1] ++++ EndToEndIdentification
ISO20022 rule
Unique identification assigned by the initiating party to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction.
If checked, when the uniqueness of the value for the given creditor and debtor has not been complied, then the Reason Code to use within the REJECT is 'DU04' (DuplicateEndToEndID).
SEPAMAIL rule
Will be forwarded as is into the Rubis ActivationReport message.
MAP TO rule
Each occurrence of this structure must be copied into the relevant occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlEndToEndId] (3.18) within the [RUBIS Payment Activation Report] message.
2.24 [0..1] +++ PaymentTypeInformation SEPAMAIL rule
Not Allowed for SEPAmail
2.35 [1..1] +++ Amount
ISO20022 rule
Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party.
SEPAMAIL rule
Usage rule: this amount MUST NOT be zero.
2.36 [1..1] | ++++ InstructedAmount ISO20022 rule
CurrencyAmount The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
SEPAmailNorme1206–ÉditiondeJuin2015 Page136
Note: The decimal separator is a dot.
ISO20022 rule
Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party.
SEPAMAIL rule
Up to two decimals are allowed
If checked, when the value format is incorrect, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
SEPAMAIL rule
The value must be greater than '0.01' but less than '999999999.99'
If checked, when the value is incorrect, then the Reason Code to use within the REJECT is 'AM02' (NotAllowedAmount).
MAP TO rule
Each occurrence of this structure must be copied into the relevant occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /Amt /InstdAmt] (3.35) within the [RUBIS Payment Activation Report] message.
[1..1] | +++++ Currency
ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
SEPAMAIL rule
The sole currency code to be used is 'EUR'
If checked, when the currency is not equal to 'EUR', then the Reason Code to use within the REJECT is 'AM03' (NotAllowedCurrency).
2.37 [1..1] | ++++ EquivalentAmount SEPAMAIL rule
Not Allowed for SEPAmail
If checked, when the value is set whilst it is not allowed, then the Reason Code to use within the REJECT is 'AM12' (InvalidAmount).
2.40 [1..1] +++ ChargeBearer ISO20022 rule
Specifies which party/parties will bear the charges associated with the processing of the payment transaction.
SEPAmailNorme1206–ÉditiondeJuin2015 Page137
SEPAMAIL rule
Mandatory. The only currently accepted value is SLEV.
If checked, when the value is not equal to 'SLEV', then the Reason Code to use within the REJECT is 'BE19' (InvalidChargeBearerCode).
2.41 [0..1] +++ ChequeInstruction SEPAMAIL rule
Not Allowed for SEPAmail
2.59 [0..1] +++ UltimateDebtor SEPAMAIL rule
Not Allowed for SEPAmail
2.60 [0..1] +++ IntermediaryAgent1 SEPAMAIL rule
Not Allowed for SEPAmail
2.61 [0..1] +++ IntermediaryAgent2 SEPAMAIL rule
Not Allowed for SEPAmail
2.62 [0..1] +++ IntermediaryAgent3 SEPAMAIL rule
Not Allowed for SEPAmail
2.63 [1..1] +++ CreditorAgent
ISO20022 rule
Financial institution servicing an account for the creditor.
SEPAMAIL rule
Mandatory. BIC
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /GrpHdr /CdtrAgt] (1.5) within the [RUBIS Payment Activation Report] message must be either omitted or copied from this structure, though the copy of the following substructures is optional: - ClearingSystemMemberIdentification - Name - PostalAddress - Other - BranchIdentification
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /CdtrAgt] (3.122) within the [RUBIS Payment Activation Report] message must be copied from this structure, though the copy of the following substructures is optional: - ClearingSystemMemberIdentification - Name - PostalAddress
SEPAmailNorme1206–ÉditiondeJuin2015 Page138
- Other - BranchIdentification
2.63/3.1.0 [1..1] ++++ FinancialInstitution-Identification
ISO20022 rule
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
2.63/3.1.1 [0..1] +++++ BICFI
ISO20022 rule
Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAMAIL rule
BICFI Valid BICs for financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE and BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
If checked, when the BIC is not registered, then the Reason Code to use within the REJECT is 'RC01' (BankIdentifierIncorrect).
If checked, when the value is not consistant with the account id, then the Reason Code to use within the REJECT is 'RC01' (BankIdentifierIncorrect).
2.63/3.1.2 [0..1] +++++ ClearingSystem-MemberIdentification
ISO20022 rule
Information used to identify a member within a clearing system.
2.63/3.1.3 [0..1] ++++++ ClearingSystemIdentification ISO20022 rule
Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.
2.63/3.1.4 [1..1] | +++++++ Code ISO20022 rule
Identification of a clearing system, in a coded form as published in an external list.
2.63/3.1.5 [1..1] | +++++++ Proprietary ISO20022 rule
Identification code for a clearing system that has not yet been identified in the list of clearing systems.
2.63/3.1.6 [1..1] ++++++ MemberIdentification ISO20022 rule
Identification of a member of a clearing system.
SEPAmailNorme1206–ÉditiondeJuin2015 Page139
2.63/3.1.7 [0..1] +++++ Name ISO20022 rule
Name by which an agent is known and which is usually used to identify that agent.
2.63/3.1.8 [0..1] +++++ PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
2.63/3.1.9 [0..1] ++++++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
2.63/3.1.10 [0..1] ++++++ Department ISO20022 rule
Identification of a division of a large organisation or building.
2.63/3.1.11 [0..1] ++++++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
2.63/3.1.12 [0..1] ++++++ StreetName ISO20022 rule
Name of a street or thoroughfare.
2.63/3.1.13 [0..1] ++++++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
2.63/3.1.14 [0..1] ++++++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
2.63/3.1.15 [0..1] ++++++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
2.63/3.1.16 [0..1] ++++++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
SEPAmailNorme1206–ÉditiondeJuin2015 Page140
2.63/3.1.17 [0..1] ++++++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.63/3.1.18 [0..7] ++++++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
2.63/3.1.19 [0..1] +++++ Other ISO20022 rule
Unique identification of an agent, as assigned by an institution, using an identification scheme.
2.63/3.1.20 [1..1] ++++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
2.63/3.1.21 [0..1] ++++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.63/3.1.22 [1..1] | +++++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
2.63/3.1.23 [1..1] | +++++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
2.63/3.1.24 [0..1] ++++++ Issuer ISO20022 rule
Entity that assigns the identification.
2.63/3.1.25 [0..1] ++++ BranchIdentification ISO20022 rule
Identifies a specific branch of a financial institution
2.63/3.1.26 [0..1] +++++ Identification ISO20022 rule
Unique and unambiguous identification of a branch of a financial institution.
2.63/3.1.27 [0..1] +++++ Name ISO20022 rule
Name by which an agent is known and which is usually used to identify that agent.
2.63/3.1.28 [0..1] +++++ PostalAddress ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
SEPAmailNorme1206–ÉditiondeJuin2015 Page141
ISO20022 rule
Postal address of a party.
2.63/3.1.29 [0..1] ++++++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
2.63/3.1.30 [0..1] ++++++ Department ISO20022 rule
Identification of a division of a large organisation or building.
2.63/3.1.31 [0..1] ++++++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
2.63/3.1.32 [0..1] ++++++ StreetName ISO20022 rule
Name of a street or thoroughfare.
2.63/3.1.33 [0..1] ++++++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
2.63/3.1.34 [0..1] ++++++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
2.63/3.1.35 [0..1] ++++++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
2.63/3.1.36 [0..1] ++++++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
2.63/3.1.37 [0..1] ++++++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
SEPAmailNorme1206–ÉditiondeJuin2015 Page142
2.63/3.1.38 [0..7] ++++++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
2.64 [1..1] +++ Creditor
ISO20022 rule
Party to which an amount of money is due.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /Cdtr] (3.123) within the [RUBIS Payment Activation Report] message must be copied from this structure.
See details below
2.65 [0..1] +++ CreditorAccount
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction.
SEPAMAIL rule
Mandatory.
If checked, when the structure is missing, then the Reason Code to use within the REJECT is 'AC01' (IncorrectAccountNumber).
SEPAMAIL rule
IBAN (or QXBAN). For interbank exchanges, this MUST NOT be a QXBAN.
If checked, when the value format is incorrect, then the Reason Code to use within the REJECT is 'AC01' (IncorrectAccountNumber).
If checked, when the country code does not comply with SEPA, then the Reason Code to use within the REJECT is 'AC01' (IncorrectAccountNumber).
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /CdtrAcct] (3.124) within the [RUBIS Payment Activation Report] message must be copied from this structure, though the copy of the following substructures is optional: - Type - Currency - Name
2.65/1.1.0 [1..1] ++++ Identification ISO20022 rule
Unique and unambiguous identification for the account between the account owner and the account servicer.
SEPAmailNorme1206–ÉditiondeJuin2015 Page143
2.65/1.1.1 [1..1] | +++++ IBAN
ISO20022 rule
International Bank Account Number (IBAN) - identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions.
ISO20022 rule
A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.
2.65/1.1.2 [1..1] | +++++ Other SEPAMAIL rule
Not Allowed for SEPAmail
2.65/1.1.8 [0..1] ++++ Type ISO20022 rule
Specifies the nature, or use of the account.
2.65/1.1.9 [1..1] | +++++ Code
2.65/1.1.10 [1..1] | +++++ Proprietary
2.65/1.1.11 [0..1] ++++ Currency
ISO20022 rule
Identification of the currency in which the account is held. Usage: Currency should only be used in case one and the same account number covers several currencies and the initiating party needs to identify which currency needs to be used for settlement on the account.
ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
2.65/1.1.12 [0..1] ++++ Name ISO20022 rule
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account. Usage: The account name is different from the account owner name. The account name is used in certain user communities to provide a means of identifying the account, in addition to the account owner's identity and the account number.
2.66 [0..1] +++ UltimateCreditor
ISO20022 rule
Ultimate party to which an amount of money is due.
ISO20022 rule
G1 UltimateCreditorGuideline UltimateCreditor may only be present if different from Creditor.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /UltmtCdtr] (3.125) within the [RUBIS Payment Activation Report] message must be copied from this structure. However, the copy of the substructures is only mandatory for data
SEPAmailNorme1206–ÉditiondeJuin2015 Page144
that will be eventually forwarded within the SEPA Credit Transfer Core Mandatory Subset (*). The other data may optionally be copied.
See details below
2.67 [0..*] +++ InstructionForCreditorAgent SEPAMAIL rule
Not Allowed for SEPAmail
2.70 [0..1] +++ Purpose ISO20022 rule
Underlying reason for the payment transaction. Usage: Purpose is used by the end-customers, that is initiating party, (ultimate) debtor, (ultimate) creditor to provide information concerning the nature of the payment. Purpose is a content element, which is not used for processing by any of the agents involved in the payment chain.
2.71 [1..1] | ++++ Code ISO20022 rule
Underlying reason for the payment transaction, as published in an external purpose code list.
2.72 [1..1] | ++++ Proprietary ISO20022 rule
Purpose, in a proprietary form.
2.73 [0..10] +++ RegulatoryReporting ISO20022 rule
Information needed due to regulatory and statutory requirements.
2.73/6.1.0 [0..1] ++++ DebitCredit-ReportingIndicator
ISO20022 rule
Identifies whether the regulatory reporting information applies to the debit side, to the credit side or to both debit and credit sides of the transaction.
Code Name Definition
BOTH Both Regulatory information applies to both credit and debit sides. CRED Credit Regulatory information applies to the credit side. DEBT Debit Regulatory information applies to the debit side.
2.73/6.1.1 [0..1] ++++ Authority ISO20022 rule
Entity requiring the regulatory reporting information.
2.73/6.1.2 [0..1] +++++ Name ISO20022 rule
Name of the entity requiring the regulatory reporting information.
2.73/6.1.3 [0..1] +++++ Country
ISO20022 rule
Country of the entity that requires the regulatory reporting information.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2
SEPAmailNorme1206–ÉditiondeJuin2015 Page145
code).
2.73/6.1.4 [0..*] ++++ Details ISO20022 rule
Set of elements used to provide details on the regulatory reporting information.
2.73/6.1.5 [0..1] +++++ Type ISO20022 rule
Specifies the type of the information supplied in the regulatory reporting details.
2.73/6.1.6 [0..1] +++++ Date ISO20022 rule
Date related to the specified type of regulatory reporting details.
2.73/6.1.7 [0..1] +++++ Country
ISO20022 rule
Country related to the specified type of regulatory reporting details.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.73/6.1.8 [0..1] +++++ Code ISO20022 rule
Specifies the nature, purpose, and reason for the transaction to be reported for regulatory and statutory requirements in a coded form.
2.73/6.1.9 [0..1] +++++ Amount
ISO20022 rule
Amount of money to be reported for regulatory and statutory requirements.
ISO20022 rule
CurrencyAmount The number of fractional digits (or minor unit of currency) must comply with ISO 4217. Note: The decimal separator is a dot.
2.73/6.1.10 [1..1] ++++++ Currency ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
2.73/6.1.11 [0..*] +++++ Information ISO20022 rule
Additional details that cater for specific domestic regulatory requirements.
2.74 [0..1] +++ Tax SEPAMAIL rule
Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page146
2.75 [0..10] +++ RelatedRemittance-Information
SEPAMAIL rule
Not Allowed for SEPAmail
2.82 [0..1] +++ RemittanceInformation
ISO20022 rule
Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts' receivable system.
SEPAMAIL rule
Only unstructured remittance information is allowed in SEPAmail
2.83 [0..*] ++++ Unstructured
ISO20022 rule
Information supplied to enable the matching/reconciliation of an entry with the items that the payment is intended to settle, such as commercial invoices in an accounts' receivable system, in an unstructured form.
ISO20022 rule
Information supplied to enable the matching/reconciliation of an entry with the items that the payment is intended to settle, such as commercial invoices in an accounts' receivable system, in an unstructured form.
SEPAMAIL rule
Only one occurrence may be used in order to forward a proposal of remittance information to the debtor.
If checked, when there are more than one occurrence of the structure, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
SEPAMAIL rule
Due to later truncation, the length of this value must not exceed 105 characters.
If checked, when the value length exceeds 105 characters, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
MAP TO rule
Each occurrence of [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /RmtInf /Ustrd] (3.87) within the [RUBIS Payment Activation Report] message must be valued with the concatenation of the two following values * the end-to-end reference provided by the Debtor and padded up to 35 characters with space characters * and, within a limit of 105 characters that may need truncation: ** either a value given by the debtor ** or the copy of this structure.
2.84 [0..*] ++++ Structured SEPAMAIL rule
Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page147
Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/GrpHdr/InitgPty element (previously indexed as 1.5)
Ref. Mult. Ch. Depth Message element Requirements
1.5/4.1.0 [0..1] + Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
1.5/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
1.5/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
1.5/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
1.5/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
1.5/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
1.5/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
1.5/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
1.5/4.1.8 [0..1] ++ TownName ISO20022 Name of a built-up area, with defined boundaries, and a local government.
SEPAmailNorme1206–ÉditiondeJuin2015 Page148
rule
1.5/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
1.5/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.5/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
1.5/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
1.5/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
1.5/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
1.5/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
1.5/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
SEPAmailNorme1206–ÉditiondeJuin2015 Page149
1.5/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
1.5/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
1.5/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
1.5/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
1.5/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
1.5/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
1.5/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
1.5/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 rule
Province where a person was born.
1.5/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
1.5/4.1.26 [1..1] | ++++ CountryOfBirth
ISO20022 rule
Country where a person was born.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.5/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
1.5/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
SEPAmailNorme1206–ÉditiondeJuin2015 Page150
1.5/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
1.5/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
1.5/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
1.5/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
1.5/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.5/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
1.5/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
1.5/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
1.5/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
1.5/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
1.5/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
SEPAmailNorme1206–ÉditiondeJuin2015 Page151
1.5/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
1.5/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/Dbtr element (previously indexed as 2.15)
Ref. Mult. Ch. Depth Message element Requirements
2.15/4.1.0 [0..1] + Name
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
SEPAMAIL rule
Mandatory.
If checked, when the name is not set, then the Reason Code to use within the REJECT is 'BE08' (MissingDebtorName).
2.15/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
2.15/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
2.15/4.1.3 [0..1] ++ Department ISO20022 Identification of a division of a large organisation or building.
SEPAmailNorme1206–ÉditiondeJuin2015 Page152
rule
2.15/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
2.15/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
2.15/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
2.15/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
2.15/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
2.15/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
2.15/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.15/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
2.15/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
2.15/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
2.15/4.1.14 [0..1] | +++ AnyBICIdentifier ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAmailNorme1206–ÉditiondeJuin2015 Page153
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
2.15/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
2.15/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
2.15/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.15/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
2.15/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
2.15/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
2.15/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
2.15/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
2.15/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
2.15/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 Province where a person was born.
SEPAmailNorme1206–ÉditiondeJuin2015 Page154
rule
2.15/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
2.15/4.1.26 [1..1] | ++++ CountryOfBirth
ISO20022 rule
Country where a person was born.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.15/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
2.15/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
2.15/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.15/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
2.15/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
2.15/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
2.15/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.15/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
SEPAmailNorme1206–ÉditiondeJuin2015 Page155
2.15/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
2.15/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
2.15/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
2.15/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
2.15/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
2.15/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
2.15/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/UltmtDbtr element (previously indexed as 2.18)
Ref. Mult. Ch. Depth Message element Requirements
2.18/4.1.0 [0..1] + Name
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
2.18/4.1.1 [0..1] + PostalAddress ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
SEPAmailNorme1206–ÉditiondeJuin2015 Page156
ISO20022 rule
Postal address of a party.
2.18/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
2.18/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
2.18/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
2.18/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
2.18/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
2.18/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
2.18/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
2.18/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
2.18/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
SEPAmailNorme1206–ÉditiondeJuin2015 Page157
2.18/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
2.18/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
2.18/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
2.18/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
2.18/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
2.18/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
2.18/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.18/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
2.18/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
2.18/4.1.20 [0..1] | ++++ Issuer ISO20022 Entity that assigns the identification.
SEPAmailNorme1206–ÉditiondeJuin2015 Page158
rule
2.18/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
2.18/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
2.18/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
2.18/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 rule
Province where a person was born.
2.18/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
2.18/4.1.26 [1..1] | ++++ CountryOfBirth
ISO20022 rule
Country where a person was born.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.18/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
2.18/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
2.18/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.18/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
2.18/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
SEPAmailNorme1206–ÉditiondeJuin2015 Page159
2.18/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
2.18/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.18/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
2.18/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
2.18/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
2.18/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
2.18/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
2.18/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
2.18/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
2.18/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
SEPAmailNorme1206–ÉditiondeJuin2015 Page160
Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/CdtTrfTx/Cdtr element (previously indexed as 2.64)
Ref. Mult. Ch. Depth Message element Requirements
2.64/4.1.0 [0..1] + Name
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
SEPAMAIL rule
Mandatory.
If checked, when the value is missing, then the Reason Code to use within the REJECT is 'RR03' (Missing Creditor Name or Address).
2.64/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
2.64/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
2.64/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
2.64/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
2.64/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
2.64/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
SEPAmailNorme1206–ÉditiondeJuin2015 Page161
2.64/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
2.64/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
2.64/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
2.64/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.64/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
2.64/4.1.12 [0..1] + Identification
ISO20022 rule
Unique and unambiguous identification of a party.
SEPAMAIL rule
Mandatory for icqx@scheme registered users
If checked, when the structure is missing, then the Reason Code to use within the REJECT is 'BE05' (UnrecognisedInitiatingParty).
2.64/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
2.64/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify:
SEPAmailNorme1206–ÉditiondeJuin2015 Page162
- the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
2.64/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
2.64/4.1.16 [1..1] | ++++ Identification
ISO20022 rule
Identification assigned by an institution.
SEPAMAIL rule
Must contain the ICQX
If checked, when the value is not an active ICQX whilst the context is B2B or B2C, then the Reason Code to use within the REJECT is 'BE05' (UnrecognisedInitiatingParty).
MAP TO rule
This structure, when containing an ICQX, must be forwarded into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /Cdtr /Id /OrgId /Othr /Id] (3.123/4.1.16) within the [RUBIS Payment Activation Report] message
SELF-MAP rule
When this structure is set with an ICQX, then [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /Cdtr /Id /OrgId /Othr /SchmeNm /Prtry] (2.64/4.1.19) must be valued with "SEPAMAIL.EU"
2.64/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.64/4.1.18 [1..1] | | +++++ Code SEPAMAIL rule
Not Allowed for SEPAmail
If checked, when the value is set whilst it is not allowed, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
2.64/4.1.19 [1..1] | | +++++ Proprietary
ISO20022 rule
Name of the identification scheme, in a free text form.
SEPAMAIL rule
If set, this tag must contain the value "SEPAMAIL.EU"
If checked, when the value is not equal to 'SEPAMAIL.EU', then the Reason Code to use within the REJECT
SEPAmailNorme1206–ÉditiondeJuin2015 Page163
is 'FF01' (Invalid File Format).
SELF-MAP rule
When [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /Cdtr /Id /OrgId /Othr /Id] (2.64/4.1.16) is set with an ICQX, then this structure must be valued with "SEPAMAIL.EU"
MAP TO rule
This structure, if valued with "SEPAMAIL.EU", must be forwarded into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /Cdtr /Id /OrgId /Othr /SchmeNm /Prtry] (3.123/4.1.19) within the [RUBIS Payment Activation Report] message.
2.64/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
2.64/4.1.21 [1..1] | ++ PrivateIdentification SEPAMAIL rule
Not Allowed for SEPAmail
2.64/4.1.33 [0..1] + CountryOfResidence SEPAMAIL rule
Not Allowed for SEPAmail
2.64/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
2.64/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
2.64/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
2.64/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
2.64/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
SEPAmailNorme1206–ÉditiondeJuin2015 Page164
2.64/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
2.64/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
2.64/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/CdtTrfTx/UltmtCdtr element (previously indexed as 2.66)
Ref. Mult. Ch. Depth Message element Requirements
2.66/4.1.0 [0..1] + Name
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
2.66/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
2.66/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
2.66/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
SEPAmailNorme1206–ÉditiondeJuin2015 Page165
2.66/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
2.66/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
2.66/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
2.66/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
2.66/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
2.66/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
2.66/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.66/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
2.66/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
2.66/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
2.66/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11)
SEPAmailNorme1206–ÉditiondeJuin2015 Page166
contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
2.66/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
2.66/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
2.66/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.66/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
2.66/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
2.66/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
2.66/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
2.66/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
2.66/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
2.66/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 rule
Province where a person was born.
SEPAmailNorme1206–ÉditiondeJuin2015 Page167
2.66/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
2.66/4.1.26 [1..1] | ++++ CountryOfBirth
ISO20022 rule
Country where a person was born.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.66/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
2.66/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
2.66/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
2.66/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
2.66/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
2.66/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
2.66/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.66/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
2.66/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr.
SEPAmailNorme1206–ÉditiondeJuin2015 Page168
MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
2.66/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
2.66/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
2.66/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
2.66/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
2.66/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
2.66/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Non-ISO part
This part is only used by the SEPAmail/RUBIS system, to provide additional services both to creditor and debtor.
Ref. Mult. Ch. Depth Message element Requirements
B2.1 [1..1] + Title SEPAMAIL rule
Payment description, such as "Payment upon validation". This is presented to the user through the debtor's bank interface.
B2.2 [1..1] + PmtCond SEPAMAIL rule
Mandatory. Specific payment conditions
B2.2.1 [1..1] ++ PmtModifAccepted
SEPAMAIL rule
Mandatory. Are modified payment amounts accepted by the creditor ?
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Complements /PmtModif] (B2.5) within the [RUBIS Payment Activation Report] message is only set if the relevant this structure was set to «True».
SEPAmailNorme1206–ÉditiondeJuin2015 Page169
B2.2.2 [1..1] ++ ImmPmtAccepted
SEPAMAIL rule
Mandatory. Is immediate payment accepted by the creditor ?
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Complements /ImmPmt] (B2.3) within the [RUBIS Payment Activation Report] message is set to «False» if this structure was set to «False». Otherwise, ImmPmt is set to true (accepts) or false (does not accept) according to the choice of the debtor.
B2.2.3 [0..1] ++ DelayPenalty SEPAMAIL rule
Penalties applicable in case of payment delay. This is free text, considering the wide variety of possibilities.
B2.2.4 [0..1] ++ ImmPmtRebate
SEPAMAIL rule
Discount rate for immediate payment. Even if immediate payment is accepted by the creditor, this field is not mandatory. Its absence means immediate payment implies no discount.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Complements /ImmPmtRebate] (B2.4) within the [RUBIS Payment Activation Report] message must be either omitted or copied from this structure.
B2.3 [0..1] + OtherPmtMtd SEPAMAIL rule
Payment method requested by creditor. Possible values are TRF (Transfer), DD (Direct Debit), and CARD (payment card). If this field is present, the PaymentMethod field in the ISO part will be ignored.
If checked, when the value is not allowed, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
B2.5 [0..1] + PmtGuarantee SEPAMAIL rule
Payment guarantee to be applied to this transaction. Possible values are AUTO transfer will be automatically guaranteed DBTR transfer will be guaranteed if debtor agrees NONE no guarantee can be applied to transfer XXXX transfer is not possible Currently, this field is not taken into account.
B2.6 [0..1] + TrfNature SEPAMAIL rule
Nature of the generated payment. Possible values are IMMED and TERM. This field MUST NOT be set to IMMED if B2.2.2 is false. Currently, this field MAY be ignored by the debtor's bank. The meaning of the possible values for TrfNature field is as follows : IMMED : the default option displayed to the debtor will be a transfer initiated upon validation (immediate transfer, in French facture à vue) TERM : the default option displayed to the debtor will be a transfer occurred on the RequestedExecutionDate (index 2.14) (transfer at term, in French facture à échéance). If this field is not present and immediate payment is allowed, the default nature applied will be IMMED. If this field is not present and immediate payment is not allowed, the message is then inconsistent and thus shall be rejected.
SEPAmailNorme1206–ÉditiondeJuin2015 Page170
If checked, when the value is not set or set to 'IMMED' whilst B2.2. is false2, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Complements /TrfNature] (B2.6) within the [RUBIS Payment Activation Report] message must exactly match this structure.
B2.7 [0..3] + CustRef
SEPAMAIL rule
Customer references, delivered by the creditor, unambiguously identifying the debtor in the creditor reference system for one given contract. If several RequestComplements are present, this field MUST have the same value(s) in all structures.
MAP TO rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Complements /CustRef] (B2.7) within the [RUBIS Payment Activation Report] message must exactly match this structure.
B2.8 [1..1] + RltnType SEPAMAIL rule
Type of relation between creditor and debtor. Possible values are B2B, B2C, C2B and C2C. If this field is B2B or B2C, there SHOULD BE an ICQX in element 4.1.12 above.
Generic checks
SEPAMAIL rule
The whole message should comply with the SEPAmail defined caracter set
If checked, when some characters do not belong to the SEPAmail character set, then the Reason Code to use within the REJECT is 'RR10' (InvalidCharacterSet).
SEPAMAIL rule
The request may be refused by the debtor
If checked, when the debtor refuses the payment request, then the Reason Code to use within the REJECT is 'MS02' (NotSpecifiedReasonCustomer Generated).
SEPAMAIL rule
The debtor's bank may not be able to process the payment
If checked, when the debtor's bank cannot process the payment, then the Reason Code to use within the REJECT is 'MS03' (NotSpecifiedReasonAgent Generated).
SEPAMAIL rule
The payment request may expire
If checked, when the payment request has expired, then the Reason Code to use within the REJECT is 'NOAS' (NoAnswerFromCustomer).
SEPAmailNorme1206–ÉditiondeJuin2015 Page171
(*) The SEPA Credit Transfer Core Mandatory Subset to which several [MAP TO] rules refer in this document is the subset specified through the yellow shaded elements within the SEPA Credit Transfer Scheme Inter-Bank Implementation Guidelines produced by the European Payment Council.
SEPAmailNorme1206–ÉditiondeJuin2015 Page172
5.14. IGRubisActivationReport
Reference document The underlying message, pain.014.001.01, is described by an ISO 20022 document, entitled "Creditor Payment Activation Request: Message Definition Report", in its October 2010 version, with which the reader should be familiar. It is available directly from ISO 20022 [http://www.iso20022.org/documents/general/Creditor_Payment_Activation_Request.zip here].
Introduction This document describes the contents of the SEPAmail RUBIS message used to accept or reject payment as requested by a debtor. The full name of this message is sepamail_message_payment.activation_PaymentActivationReport. This message can be used in two cases: * Normally, it is generated and sent by the debtor upon reception of a {{LienRubisActivationRequest|EN}} Rubis ActivationRequest message, to indicate his approval or rejection. * It can also be generated and sent by the debtor's bank This message contains one or several ISO pain.014 structures. For adaptability reasons, this message also includes non-ISO parts. All message parts are described in this document
Header
Ref. Mult. Ch. DepthMessage element
Requirements
A [1..1] + Header SEPAMAIL rule
Global header for message
A1 [1..1] ++ CreationDateTime
SEPAMAIL rule
Creation date and time, ISO format. This date will be used as instruction date for the associated payments, if any.
MAP FROM rule
[ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /Header /CreDtTm] (A1) within the [RUBIS Payment Activation Request] message must not be copied into this structure that refers to the creation timestamp of the paymentActivationReport itself.
MAP TO rule
This structure must not be copied into [ /Document /FIToFICstmrCdtTrf /GrpHdr /CreDtTm] (1.2) within the [SEPA Inter-Bank Credit Transfer] message
A2 [1..1] ++ NbOfReports SEPAMAIL rule
Mandatory. Number of RepCompl elements contained in the message
A3 [0..*] ++ Documents SEPAMAIL rule
Any document justifying the payment decision.
SEPAmailNorme1206–ÉditiondeJuin2015 Page173
MAP FROM rule
The enclosed documents within [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /Header /Documents] (A3) within the [RUBIS Payment Activation Request] message must not be copied into this structure.
A3.1 [1..1] +++ Type SEPAMAIL rule
Type of document attached. Possible values are mandate, invoice and information. In this message, only the last two values should be used.
A3.2 [0..1] +++ Date SEPAMAIL rule
reference date of the document
A3.3 [1..1] +++ Title SEPAMAIL rule
title of the document
A3.4 [1..1] +++ Reference SEPAMAIL rule
internal reference
A3.5 [1..1] +++ Lang SEPAMAIL rule
language used on the document, 2-letter code
A3.6 [0..1] +++ Contents SEPAMAIL rule
Structured properties of the document
A3.6.1 [1..1] ++++ mime-type SEPAMAIL rule
Type of data in the document. Usage rule: only the following values can be used
image/gif
image/jpeg
image/png
image/vnd.microsoft.icon
application/pdf
A3.6.3 [0..1] ++++ name SEPAMAIL rule
original document name
A3.6.3 [1..1] ++++ data SEPAMAIL rule
actual document contents
ISO and Non-ISO parts Each "ReportAndComplements" element describes exactly one payment method, which can be either accepted or rejected. * Usage rule 1 : No more than one payment in a given PaymentActivationReport message can be accepted. * Usage rule 2 : If the debtor accepts one payment among several proposed by the
SEPAmailNorme1206–ÉditiondeJuin2015 Page174
creditor, the PaymentActivationReport MAY include only the accepted payment. It MAY also include all other payments, each one with a rejected status (RJCT). * Usage rule 3 : If the debtor rejects all proposed payments, the PaymentActivationReport message MUST include all payments, each one with a rejected status (RJCT). Each RepCompl element has the following contents :
Ref. Mult. Ch. DepthMessage element
Requirements
B [1..*] + RepCompl
SEPAMAIL rule
ISO + non-ISO parts. This element must be present as many times as described by the NbOfReports element, in the header.
SEPAMAIL rule
There can only be zero or one Report with an "Accepted" status (i.e. /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/TxSts set to « ACSP », « ACSC » or « ACWC »), as the payment modality which has been chosen by the debtor. It is possible to add as well the payment modalities which have not been accepted. Their status is then "Rejected" (i.e. /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/TxSts set to « RJCT »)
B1 [1..1] ++ Report
SEPAMAIL rule
CreditorPaymentActivationReport, as per ISO 20022 pain.014.001.01
SEPAMAIL rule
The sole report, as payment modality, that has been accepted by the debtor can be used later to generate one or several CT transaction that be embedded within FIToFICstmrCdtTrf messages (pacs.008)
B2 [1..1] ++ Complements SEPAMAIL rule
Non-ISO part, described further in this document
ISO Part : CreditorPaymentActivationRequestStatusReportV01 Please note : this whole part is directly copied from ISO20022 documents, and is only provided here for ease of reference. The indices in first column match the ones in this document. Ref. Mult. Ch. Depth Message element Requirements
1.0 [1..1] + GroupHeader ISO20022 rule
Set of characteristics shared by all individual transactions included in the message.
1.1 [1..1] ++ MessageIdentification
ISO20022 rule
Point to point reference assigned by the instructing party and sent to the next party in the chain to unambiguously identify the message.
ISO20022 rule
Usage: The instructing party has to make sure that 'MessageIdentification' is unique per instructed party for a pre-agreed period.
SEPAmailNorme1206–ÉditiondeJuin2015 Page175
SEPAMAIL rule
To be set by the sender of the Activation report
MAP FROM rule
[ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /GrpHdr /MsgId] (1.1) within the [RUBIS Payment Activation Request] message must not be copied into this structure that shall be set by the party who sends the PaymentActivationReport.
MAP TO rule
This structure must not be copied into [ /Document /FIToFICstmrCdtTrf /GrpHdr /MsgId] (1.1) within the [SEPA Inter-Bank Credit Transfer] message
1.2 [1..1] ++ CreationDateTime
ISO20022 rule
Date and time at which the status report was created by the instructing party.
SEPAMAIL rule
This is a technical date, which may be different from the same field in main message
MAP FROM rule
[ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /GrpHdr /CreDtTm] (1.2) within the [RUBIS Payment Activation Request] message must not be copied into this structure that refers to the creation timestamp of the paymentActivationReport itself.
MAP TO rule
This structure must not be copied into [ /Document /FIToFICstmrCdtTrf /GrpHdr /CreDtTm] (1.2) within the [SEPA Inter-Bank Credit Transfer] message
1.3 [1..1] ++ InitiatingParty
ISO20022 rule
Party initiating the creditor payment activation request. This can either be the creditor himself or the party that initiates the request on behalf of the creditor.
SEPAMAIL rule
Party sending the message. Must indicate the debtor when this message is generated by his action (acceptance or rejection), and the debtor's bank in other cases. Notice that this rule is different from the original one provided by ISO20022 and overwrite this ISO20022 rule.
MAP FROM rule
[ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /GrpHdr /InitgPty] (1.5) within the [RUBIS Payment Activation Request] message must not be copied into this structure that refers to the party who creates the PaymentActivationReport.
See details below
1.4 [0..1] ++ DebtorAgent
ISO20022 rule
Financial institution servicing an account for the debtor.
SEPAMAIL Usage Rule: Only BIC is allowed
SEPAmailNorme1206–ÉditiondeJuin2015 Page176
rule
MAP FROM rule
This structure must be either omitted or copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /DbtrAgt] (2.17) within the [RUBIS Payment Activation Request] message.
SELF-MAP rule
This structure and [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /DbtrAgt] (3.121) refer to same actor, respectively at group and transaction level.
1.4/3.1.0 [1..1] +++ FinancialInstitutionIdentification ISO20022 rule
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
1.4/3.1.1 [0..1] ++++ BICFI
ISO20022 rule
Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAMAIL rule
BICFI Valid BICs for financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE and BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
1.4/3.1.2 [0..1] ++++ ClearingSystem-MemberIdentification
SEPAMAIL rule
Not Allowed for SEPAmail
1.4/3.1.7 [0..1] ++++ Name SEPAMAIL rule
Not Allowed for SEPAmail
1.4/3.1.8 [0..1] ++++ PostalAddress SEPAMAIL rule
Not Allowed for SEPAmail
1.4/3.1.19 [0..1] ++++ Other SEPAMAIL rule
Not Allowed for SEPAmail
1.4/3.1.25 [0..1] +++ BranchIdentification SEPAMAIL Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page177
rule
1.5 [0..1] ++ CreditorAgent
ISO20022 rule
Financial institution servicing an account for the creditor.
SEPAMAIL rule
Mandatory. BIC.
MAP FROM rule
This structure must be either omitted or copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /CdtrAgt] (2.63) within the [RUBIS Payment Activation Request] message, though the copy of the following substructures is optional: - ClearingSystemMemberIdentification - Name - PostalAddress - Other - BranchIdentification
SELF-MAP rule
This structure and [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /OrgnlPmtInfAndSts /TxInfAndSts /OrgnlTxRef /CdtrAgt] (3.122) refer to same actor, respectively at group and transaction level.
1.5/3.1.0 [1..1] +++ FinancialInstitutionIdentification ISO20022 rule
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
1.5/3.1.1 [0..1] ++++ BICFI
ISO20022 rule
Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAMAIL rule
BICFI Valid BICs for financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE and BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
1.5/3.1.2 [0..1] ++++ ClearingSystem-MemberIdentification
ISO20022 rule
Information used to identify a member within a clearing system.
SEPAmailNorme1206–ÉditiondeJuin2015 Page178
1.5/3.1.3 [0..1] +++++ ClearingSystemIdentification ISO20022 rule
Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.
1.5/3.1.4 [1..1] | ++++++ Code ISO20022 rule
Identification of a clearing system, in a coded form as published in an external list.
1.5/3.1.5 [1..1] | ++++++ Proprietary ISO20022 rule
Identification code for a clearing system that has not yet been identified in the list of clearing systems.
1.5/3.1.6 [1..1] +++++ MemberIdentification ISO20022 rule
Identification of a member of a clearing system.
1.5/3.1.7 [0..1] ++++ Name ISO20022 rule
Name by which an agent is known and which is usually used to identify that agent.
1.5/3.1.8 [0..1] ++++ PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
1.5/3.1.9 [0..1] +++++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
1.5/3.1.10 [0..1] +++++ Department ISO20022 rule
Identification of a division of a large organisation or building.
1.5/3.1.11 [0..1] +++++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
1.5/3.1.12 [0..1] +++++ StreetName ISO20022 rule
Name of a street or thoroughfare.
SEPAmailNorme1206–ÉditiondeJuin2015 Page179
1.5/3.1.13 [0..1] +++++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
1.5/3.1.14 [0..1] +++++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
1.5/3.1.15 [0..1] +++++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
1.5/3.1.16 [0..1] +++++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
1.5/3.1.17 [0..1] +++++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.5/3.1.18 [0..7] +++++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
1.5/3.1.19 [0..1] ++++ Other ISO20022 rule
Unique identification of an agent, as assigned by an institution, using an identification scheme.
1.5/3.1.20 [1..1] +++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
1.5/3.1.21 [0..1] +++++ SchemeName ISO20022 rule
Name of the identification scheme.
1.5/3.1.22 [1..1] | ++++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
1.5/3.1.23 [1..1] | ++++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
1.5/3.1.24 [0..1] +++++ Issuer ISO20022 rule
Entity that assigns the identification.
SEPAmailNorme1206–ÉditiondeJuin2015 Page180
1.5/3.1.25 [0..1] +++ BranchIdentification ISO20022 rule
Identifies a specific branch of a financial institution
1.5/3.1.26 [0..1] ++++ Identification ISO20022 rule
Unique and unambiguous identification of a branch of a financial institution.
1.5/3.1.27 [0..1] ++++ Name ISO20022 rule
Name by which an agent is known and which is usually used to identify that agent.
1.5/3.1.28 [0..1] ++++ PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
1.5/3.1.29 [0..1] +++++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
1.5/3.1.30 [0..1] +++++ Department ISO20022 rule
Identification of a division of a large organisation or building.
1.5/3.1.31 [0..1] +++++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
1.5/3.1.32 [0..1] +++++ StreetName ISO20022 rule
Name of a street or thoroughfare.
1.5/3.1.33 [0..1] +++++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
1.5/3.1.34 [0..1] +++++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
SEPAmailNorme1206–ÉditiondeJuin2015 Page181
1.5/3.1.35 [0..1] +++++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
1.5/3.1.36 [0..1] +++++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
1.5/3.1.37 [0..1] +++++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.5/3.1.38 [0..7] +++++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
2.0 [1..1] + OriginalGroup-InformationAndStatus
ISO20022 rule
Original group information concerning the group of transactions, to which the status report message refers to.
2.1 [1..1] ++ OriginalMessageIdentification
ISO20022 rule
Point to point reference, as assigned by the original instructing party, to unambiguously identify the original message.
MAP FROM rule
Each occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /GrpHdr /MsgId] (1.1) within the [RUBIS Payment Activation Request] message must be copied into the relevant occurrence of this structure in order to allow the reconciliation of the PaymentActivationRequest and the PaymentActivationReport.
2.2 [1..1] ++ OriginalMessage-NameIdentification
ISO20022 rule
Specifies the original message name identifier to which the message refers.
SEPAMAIL rule
Must be valued with "pain.013.001.01"
2.3 [0..1] ++ OriginalCreationDateTime
ISO20022 rule
Date and time at which the original message was created.
MAP FROM rule
This structure must be either omitted or copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /GrpHdr /CreDtTm] (1.2) within the [RUBIS Payment Activation Request] message.
SEPAmailNorme1206–ÉditiondeJuin2015 Page182
2.4 [0..1] ++ OriginalNumberOfTransactions
ISO20022 rule
Number of individual transactions contained in the original message.
MAP FROM rule
This structure must be either omitted or copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /GrpHdr /NbOfTxs] (1.3) within the [RUBIS Payment Activation Request] message.
2.5 [0..1] ++ OriginalControlSum
ISO20022 rule
Total of all individual amounts included in the original message, irrespective of currencies.
MAP FROM rule
This structure must be either omitted or copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /GrpHdr /CtrlSum] (1.4) within the [RUBIS Payment Activation Request] message.
2.6 [0..1] ++ GroupStatus
ISO20022 rule
Specifies the status of a group of transactions.
Code Name Definition
ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Customer profile check was also successful.
ACSC AcceptedSettlementCompleted
Settlement on the debtor's account has been completed. Usage : this can be used by the first agent to report to the debtor that the transaction has been completed. Warning : this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement
ACSP AcceptedSettlementInProcessAll preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
ACTC AcceptedTechnicalValidation Authentication and syntactical and semantical validation are successful.
ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as date or remittance not sent.
PART PartiallyAccepted A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status.
PDNG Pending Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.
RCVD Received Payment initiation has been received by the receiving agent.
RJCT Rejected Payment initiation or individual transaction included in the payment initiation has been rejected.
ISO20022 rule
R1 GroupAndTransactionStatus1Rule If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to ACTC, ACCP, ACSP or ACSC, ACCR or ACWC, then transactionInformationAndStatus/TransactionStatus must be different from RJCT.
SEPAmailNorme1206–ÉditiondeJuin2015 Page183
ISO20022 rule
R3 GroupAndTransactionStatus3Rule If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to RJCT, then TransactionInformationAndStatus/TransactionStatus must be different from ACTC, ACCP, ACSP, ACSC, ACCR, ACWC or PDNG.
ISO20022 rule
R8 StatusReasonInformationRule If GroupStatus is present and is different from RJCT or PDNG then StatusReasonInformation/AdditionalInformation must be absent. On Condition /StatusReasonInformation[1] is present And /StatusReasonInformation[*]/AdditionalInformation[*] is present And /GroupStatus is present Following Must be True /GroupStatus Must be equal to value 'Pending' Or /GroupStatus Must be equal to value 'Rejected'
ISO20022 rule
G1 NumberOfTransactionPerStatusGuideline OriginalGroupInformationAndStatus/NumberOfTransactionsPerStatus should only be present if GroupStatus equals 'PART'.
ISO20022 rule
StatusReasonInformationRule If GroupStatus is present and is different from RJCT or PDNG then StatusReasonInformation/AdditionalInformation must be absent.
SEPAMAIL rule
The status, reason code and additional information can be set - at group level, providing all the transactions are in the same state - at transaction level, in any case Setting these data at both level is also allowed
2.7 [0..*] ++ StatusReasonInformation ISO20022 rule
Set of elements used to provide detailed information on the status reason.
2.8 [0..1] +++ Originator
ISO20022 rule
Party that issues the status.
SEPAMAIL rule
Optional for SEPAmail.
See details below
SEPAmailNorme1206–ÉditiondeJuin2015 Page184
2.9 [0..1] +++ Reason ISO20022 rule
Specifies the reason for the status report.
2.10 [1..1] | ++++ Code
ISO20022 rule
Reason for the status, as published in an external reason code list.
ISO20022 rule
R9 StatusReasonRule If Reason/Code is equal to NARR, then AddititionalInformation must be present. On Condition /Reason/Code is equal to value 'Narrative' And /Reason is present And /Reason/Code is present Following Must be True /AdditionalInformation[1] Must be present
SEPAMAIL rule
Please refer to the RUBIS PaymentActivationRequest Implementation Guideline to get the reason codes to be used for the different checks.
SEPAMAIL rule
Can be used here, if all transactions have the same status.
2.11 [1..1] | ++++ Proprietary SEPAMAIL rule
Not Allowed for SEPAmail
2.12 [0..*] +++ AdditionalInformation
ISO20022 rule
Further details on the status reason. Usage: Additional information can be used for several purposes such as the reporting of repaired information.
ISO20022 rule
R8 StatusReasonInformationRule If GroupStatus is present and is different from RJCT or PDNG then StatusReasonInformation/AdditionalInformation must be absent. On Condition /StatusReasonInformation[1] is present And /StatusReasonInformation[*]/AdditionalInformation[*] is present And /GroupStatus is present Following Must be True /GroupStatus Must be equal to value 'Pending' Or /GroupStatus Must be equal to value 'Rejected'
SEPAmailNorme1206–ÉditiondeJuin2015 Page185
ISO20022 rule
R9 StatusReasonRule If Reason/Code is equal to NARR, then AddititionalInformation must be present. On Condition /Reason/Code is equal to value 'Narrative' And /Reason is present And /Reason/Code is present Following Must be True /AdditionalInformation[1] Must be present
ISO20022 rule
StatusReasonInformationRule If GroupStatus is present and is different from RJCT or PDNG then StatusReasonInformation/AdditionalInformation must be absent.
2.13 [0..*] ++ NumberOfTransactions-PerStatus
SEPAMAIL rule
Not Allowed for SEPAmail
3.0 [0..*] + OriginalPayment-InformationAndStatus
ISO20022 rule
Information concerning the original payment information, to which the status report message refers.
3.1 [1..1] ++ OriginalPayment-InformationIdentification
ISO20022 rule
Unique identification, as assigned by the original sending party, to unambiguously identify the original payment information group.
MAP FROM rule
Each occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /PmtInfId] (2.1) within the [RUBIS Payment Activation Request] message must be copied into the relevant occurrence of this structure.
3.2 [0..1] ++ OriginalNumberOfTransactions SEPAMAIL rule
Not Allowed for SEPAmail
3.3 [0..1] ++ OriginalControlSum SEPAMAIL rule
Not Allowed for SEPAmail
3.4 [0..1] ++ PaymentInformationStatus SEPAMAIL rule
Not Allowed for SEPAmail
3.5 [0..*] ++ StatusReasonInformation SEPAMAIL rule
Not Allowed for SEPAmail
3.11 [0..*] ++ NumberOfTransactions-PerStatus
SEPAMAIL Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page186
rule
3.15 [0..*] ++ Transaction-InformationAndStatus
ISO20022 rule
Set of elements used to provide information on the original transactions to which the status report message
3.16 [0..1] +++ StatusIdentification SEPAMAIL rule
Not Allowed for SEPAmail
3.17 [0..1] +++ OriginalInstructionIdentification
ISO20022 rule
Unique identification, as assigned by the original instructing party for the original instructed party, to unambiguously identify the original instruction.
MAP FROM rule
Each occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /PmtId /InstrId] (2.22) within the [RUBIS Payment Activation Request] message must be copied into the relevant occurrence of this structure.
3.18 [0..1] +++ OriginalEndToEndIdentification
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction.
MAP FROM rule
Each occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /PmtId /EndToEndId] (2.23) within the [RUBIS Payment Activation Request] message must be copied into the relevant occurrence of this structure.
MAP TO rule
This structure must not be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /PmtId /EndToEndId] (2.3) within the [SEPA Inter-Bank Credit Transfer] message which shall instead contain the debtor end-to-end reference. It is reminded that the creditor end-to-end reference will be enclosed within the first block of 35 characters of the unstructured remittance information tag. This first block shall be right padded with space characters.
3.19 [0..1] +++ TransactionStatus
ISO20022 rule
Specifies the status of a transaction, in a coded form.
ISO20022 rule
Specifies the status of a transaction, in a coded form.
Code Name Definition
ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Customer profile check was also successful.
ACSC AcceptedSettlementCompletedSettlement on the debtor's account has been completed. Usage : this can be used by the first agent to report to the debtor that
SEPAmailNorme1206–ÉditiondeJuin2015 Page187
the transaction has been completed. Warning : this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement
ACSP AcceptedSettlementInProcessAll preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
ACTC AcceptedTechnicalValidation Authentication and syntactical and semantical validation are successful.
ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as date or remittance not sent.
PDNG Pending Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.
RJCT Rejected Payment initiation or individual transaction included in the payment initiation has been rejected.
ISO20022 rule
R1 GroupAndTransactionStatus1Rule If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to ACTC, ACCP, ACSP or ACSC, ACCR or ACWC, then transactionInformationAndStatus/TransactionStatus must be different from RJCT.
ISO20022 rule
R3 GroupAndTransactionStatus3Rule If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to RJCT, then TransactionInformationAndStatus/TransactionStatus must be different from ACTC, ACCP, ACSP, ACSC, ACCR, ACWC or PDNG.
ISO20022 rule
R10 PaymentInformationStatusAcceptedRule If OriginalPaymentInformationAndStatus/PaymentInformationStatus is present and is equal to ACTC, ACCP, ACSP, ACSC or ACWC, then TransactionInformationAndStatus/TransactionStatus must be different from RJCT. On Condition /PaymentInformationStatus is present And /PaymentInformationStatus is within DataType [Code] ValidationGroupStatus1Code And /TransactionInformationAndStatus[1]/TransactionStatus is present Following Must be True /TransactionInformationAndStatus[*]/TransactionStatus Must be different from value 'Rejected'
ISO20022 rule
R12 PaymentInformationStatusRejectedRule If OriginalPaymentInformationAndStatus/PaymentInformationStatus is present and is equal to RJCT, then TransactionInformationAndStatus/TransactionStatus, if present, must be equal to RJCT. On Condition /PaymentInformationStatus is present And /PaymentInformationStatus is equal to value 'Rejected' And
SEPAmailNorme1206–ÉditiondeJuin2015 Page188
/TransactionInformationAndStatus[1]/TransactionStatus is present Following Must be True /TransactionInformationAndStatus[*]/TransactionStatus Must not be within DataType [Code] ValidationGroupStatus2Code
SEPAMAIL rule
The status, reason code and additional information can be set - at group level, providing all the transactions are in the same state - at transaction level, in any case Setting these data at both level is also allowed
SEPAMAIL rule
Mandatory. Usage rules : following values are accepted: * ACSC (Accepted with settlement complete), * ACSP (Accepted by debtor), * ACWC (Accepted with Change -- the change can be either payment date, amount or anything else), * RJCT (Rejected). In the future, the "ACCP" code will also be usable. To indicate guarantee of payment, the PmtGuarantee element, in the non-ISO part, must be used.
3.20 [0..*] +++ StatusReasonInformation
ISO20022 rule
Set of elements used to provide detailed information on the status reason.
ISO20022 rule
StatusReasonRule If Reason/Code is equal to NARR, then AddititionalInformation must be present.
3.21 [0..1] ++++ Originator
ISO20022 rule
Party that issues the status.
SEPAMAIL rule
Optional for SEPAmail.
See details below
3.22 [0..1] ++++ Reason
ISO20022 rule
Specifies the reason for the status report.
SEPAMAIL rule
Please refer to the RUBIS PaymentActivationRequest Implementation Guideline to get the reason codes to be used for the different checks.
3.23 [1..1] | +++++ Code ISO20022 rule
Reason for the status, as published in an external reason code list.
SEPAmailNorme1206–ÉditiondeJuin2015 Page189
ISO20022 rule
R9 StatusReasonRule If Reason/Code is equal to NARR, then AddititionalInformation must be present. On Condition /Reason/Code is equal to value 'Narrative' And /Reason is present And /Reason/Code is present Following Must be True /AdditionalInformation[1] Must be present
3.24 [1..1] | +++++ Proprietary SEPAMAIL rule
Not Allowed for SEPAmail
3.25 [0..*] ++++ AdditionalInformation
ISO20022 rule
Further details on the status reason. Usage: Additional information can be used for several purposes such as the reporting of repaired information.
ISO20022 rule
R9 StatusReasonRule If Reason/Code is equal to NARR, then AddititionalInformation must be present. On Condition /Reason/Code is equal to value 'Narrative' And /Reason is present And /Reason/Code is present Following Must be True /AdditionalInformation[1] Must be present
3.26 [0..*] +++ ChargesInformation SEPAMAIL rule
Not Allowed for SEPAmail
3.29 [0..1] +++ AcceptanceDateTime ISO20022 rule
Point in time when the payment order from the initiating party meets the processing conditions of the account servicing agent. This means that the account servicing agent has received the payment order and has applied checks such as authorisation, availability of funds.
3.30 [0..1] +++ AccountServicerReference SEPAMAIL rule
Not Allowed for SEPAmail
3.31 [0..1] +++ ClearingSystemReference SEPAMAIL rule
Not Allowed for SEPAmail
3.32 [0..1] +++ OriginalTransactionReference ISO20022 rule
Set of key elements used to identify the original transaction that is being referred to.
SEPAmailNorme1206–ÉditiondeJuin2015 Page190
3.33 [0..1] ++++ InterbankSettlementAmount
ISO20022 rule
Amount of money moved between the instructing agent and the instructed agent.
ISO20022 rule
CurrencyAmount The number of fractional digits (or minor unit of currency) must comply with ISO 4217. Note: The decimal separator is a dot.
[1..1] +++++ Currency ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
3.34 [0..1] ++++ Amount ISO20022 rule
Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party.
3.35 [1..1] | +++++ InstructedAmount
ISO20022 rule
Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party.
ISO20022 rule
CurrencyAmount The number of fractional digits (or minor unit of currency) must comply with ISO 4217. Note: The decimal separator is a dot.
SEPAMAIL rule
This must match exactly the original amount in ActivationRequest message (2.36)
MAP FROM rule
Each occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /Amt /InstdAmt] (2.36) within the [RUBIS Payment Activation Request] message must be copied into the relevant occurrence of this structure.
MAP TO rule
This structure must not be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /InstdAmt] (2.31) within the [SEPA Inter-Bank Credit Transfer] message which is a white field within EPC Implementation Guidelines. If the amount has not been modified by the debtor (tag B2.5.2 not present), the value must be used to set the relevant [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /IntrBkSttlmAmt] (2.18) within the [SEPA Inter-Bank Credit Transfer] message.
[1..1] | ++++++ Currency ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
SEPAmailNorme1206–ÉditiondeJuin2015 Page191
3.36 [1..1] | +++++ EquivalentAmount SEPAMAIL rule
Not Allowed for SEPAmail
3.39 [0..1] ++++ InterbankSettlementDate
ISO20022 rule
Date on which the amount of money ceases to be available to the agent that owes it and when the amount of money becomes available to the agent to which it is due.
MAP TO rule
This structure must not be forwarded into [ /Document /FIToFICstmrCdtTrf /GrpHdr /IntrBkSttlmDt] (1.7) within the [SEPA Inter-Bank Credit Transfer] message.
3.40 [0..1] ++++ RequestedCollectionDate
ISO20022 rule
Date and time at which the creditor requests that the amount of money is to be collected from the debtor.
SEPAMAIL rule
If present, this field MUST contain the RequestedExecutionDate (2.14) from ActivationRequest message
MAP FROM rule
This structure must be either omitted or copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /ReqdExctnDt] (2.14) within the [RUBIS Payment Activation Request] message
3.41 [0..1] ++++ RequestedExecutionDate
ISO20022 rule
Date at which the initiating party requests the clearing agent to process the payment. Usage: This is the date on which the debtor's account is to be debited. If payment by cheque, the date when the cheque must be generated by the bank.
SEPAMAIL rule
If present, contains the date at which debtor requires execution.
SEPAMAIL rule
Must be either omitted or valued by the debtor to indicate to his bank his requested execution date.
MAP TO rule
This structure must not be forwarded into [ /Document /FIToFICstmrCdtTrf /GrpHdr /IntrBkSttlmDt] (1.7) within the [SEPA Inter-Bank Credit Transfer] message.
3.42 [0..1] ++++ CreditorSchemeIdentification SEPAMAIL rule
Not Allowed for SEPAmail
3.43 [0..1] ++++ SettlementInformation SEPAMAIL rule
Not Allowed for SEPAmail
3.55 [0..1] ++++ PaymentTypeInformation ISO20022 Set of elements used to further specify the type of transaction.
SEPAmailNorme1206–ÉditiondeJuin2015 Page192
rule
3.56 [0..1] +++++ InstructionPriority SEPAMAIL rule
Not Allowed for SEPAmail
3.57 [0..1] +++++ ClearingChannel SEPAMAIL rule
Not Allowed for SEPAmail
3.58 [0..1] +++++ ServiceLevel SEPAMAIL rule
Not Allowed for SEPAmail
3.61 [0..1] +++++ LocalInstrument SEPAMAIL rule
Not Allowed for SEPAmail
3.64 [0..1] +++++ SequenceType SEPAMAIL rule
Not Allowed for SEPAmail
3.65 [0..1] +++++ CategoryPurpose
ISO20022 rule
Specifies the high level purpose of the instruction based on a set of pre-defined categories. Usage: This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain.
MAP FROM rule
Each occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /PmtTpInf /CtgyPurp] (2.11) within the [RUBIS Payment Activation Request] message must be copied into the relevant occurrence of this structure.
MAP TO rule
This structure may be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /PmtTpInf /CtgyPurp] (2.15) within the [SEPA Inter-Bank Credit Transfer] message.
3.66 [1..1] | ++++++ Code ISO20022 rule
Category purpose, as published in an external category purpose code list.
3.67 [1..1] | ++++++ Proprietary ISO20022 rule
Category purpose, in a proprietary form.
3.68 [0..1] ++++ PaymentMethod ISO20022 rule
Specifies the means of payment that will be used to move the amount of money.
Code Name Definition
CHK Cheque Written order to a bank to pay a certain amount of money from one person to another person.
DD DirectDebit Collection of an amount of money from the debtor's bank account by the creditor. The
SEPAmailNorme1206–ÉditiondeJuin2015 Page193
amount of money and dates of collections may vary.
TRA TransferAdviceTransfer of an amount of money in the books of the account servicer. An advice should be sent back to the account owner.
TRF CreditTransfer Transfer of an amount of money in the books of the account servicer.
MAP FROM rule
Each occurrence of this structure must be either omitted or copied with the relevant occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /PmtMtd] (2.2) within the [RUBIS Payment Activation Request] message.
3.69 [0..1] ++++ MandateRelatedInformation SEPAMAIL rule
Not Allowed for SEPAmail
3.86 [0..1] ++++ RemittanceInformation SEPAMAIL rule
Only unstructured remittance information is allowed
3.87 [0..*] +++++ Unstructured
ISO20022 rule
Information supplied to enable the matching/reconciliation of an entry with the items that the payment is intended to settle, such as commercial invoices in an accounts' receivable system, in an unstructured form.
SEPAMAIL rule
One occurrence must be present and must hold the concatenation of:
a first block, that contains the End-To-End Reference originated by the debtor and is right-padded with space characters up to 35 characters.
a second block, that contains, either the remittance information of the creditor, or an updated version provided by the debtor. This block is up to 105 characters long.
MAP FROM rule
Each occurrence of this structure must be valued with the concatenation of the two following values * the end-to-end reference provided by the Debtor and padded up to 35 characters with space characters * and, within a limit of 105 characters that may need truncation: ** either a value given by the debtor ** or the copy of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /RmtInf /Ustrd] (2.83) within the [RUBIS Payment Activation Request] message.
MAP TO rule
This structure must be forwarded into the [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /RmtInf /Ustrd] (2.76) within the [SEPA Inter-Bank Credit Transfer] message with replacement of the first 35 characters long block with the creditor end-to-end reference. This reference shall be padded with space characters.
3.88 [0..*] +++++ Structured SEPAMAIL rule
Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page194
3.118 [0..1] ++++ UltimateDebtor
ISO20022 rule
Ultimate party that owes an amount of money to the (ultimate) creditor.
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /UltmtDbtr] (2.18) within the [RUBIS Payment Activation Request] message. However, the copy of the substructures is only mandatory for data that will be eventually forwarded within the SEPA Credit Transfer Core Mandatory Subset (*). The other data may optionally be copied.
MAP TO rule
This structure must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /UltmtDbtr] (2.47) within the [SEPA Inter-Bank Credit Transfer] message with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset (*).
See details below
3.119 [0..1] ++++ Debtor
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Party that owes an amount of money to the (ultimate) creditor.
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /Dbtr] (2.15) within the [RUBIS Payment Activation Request] message.
MAP TO rule
This structure must not be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /Dbtr] (2.49) within the [SEPA Inter-Bank Credit Transfer] message that must be filled with the debtor's bank own customer data, with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset.
See details below
3.120 [0..1] ++++ DebtorAccount
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction.
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /DbtrAcct] (2.16) within the [RUBIS Payment Activation Request] message, though the copy of the following substructures is optional:
SEPAmailNorme1206–ÉditiondeJuin2015 Page195
- Type - Currency - Name
MAP TO rule
This structure must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /DbtrAcct] (2.50) within the [SEPA Inter-Bank Credit Transfer] message with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset (*).
3.120/1.1.0 [1..1] +++++ Identification ISO20022 rule
Unique and unambiguous identification for the account between the account owner and the account servicer.
3.120/1.1.1 [1..1] | ++++++ IBAN
ISO20022 rule
International Bank Account Number (IBAN) - identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions.
ISO20022 rule
A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.
SEPAMAIL rule
Mandatory. IBAN or QXBAN
3.120/1.1.2 [1..1] | ++++++ Other SEPAMAIL rule
Not Allowed for SEPAmail
3.120/1.1.8 [0..1] +++++ Type ISO20022 rule
Specifies the nature, or use of the account.
3.120/1.1.9 [1..1] | ++++++ Code
3.120/1.1.10 [1..1] | ++++++ Proprietary
3.120/1.1.11 [0..1] +++++ Currency
ISO20022 rule
Identification of the currency in which the account is held. Usage: Currency should only be used in case one and the same account number covers several currencies and the initiating party needs to identify which currency needs to be used for settlement on the account.
ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
SEPAmailNorme1206–ÉditiondeJuin2015 Page196
3.120/1.1.12 [0..1] +++++ Name ISO20022 rule
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account. Usage: The account name is different from the account owner name. The account name is used in certain user communities to provide a means of identifying the account, in addition to the account owner's identity and the account number.
3.121 [0..1] ++++ DebtorAgent
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Financial institution servicing an account for the debtor.
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /DbtrAgt] (2.17) within the [RUBIS Payment Activation Request] message.
SELF-MAP rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /GrpHdr /DbtrAgt] (1.4) and this structure refer to same actor, respectively at group and transaction level.
MAP TO rule
This structure must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /DbtrAgt] (2.51) within the [SEPA Inter-Bank Credit Transfer] message with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset (*).
3.121/3.1.0 [1..1] +++++ FinancialInstitutionIdentification ISO20022 rule
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
3.121/3.1.1 [0..1] ++++++ BICFI
ISO20022 rule
Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAMAIL rule
BICFI Valid BICs for financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE and BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
SEPAMAIL Mandatory
SEPAmailNorme1206–ÉditiondeJuin2015 Page197
rule
3.121/3.1.2 [0..1] ++++++ ClearingSystem-MemberIdentification
SEPAMAIL rule
Not Allowed for SEPAmail
3.121/3.1.7 [0..1] ++++++ Name SEPAMAIL rule
Not Allowed for SEPAmail
3.121/3.1.8 [0..1] ++++++ PostalAddress SEPAMAIL rule
Not Allowed for SEPAmail
3.121/3.1.19 [0..1] ++++++ Other SEPAMAIL rule
Not Allowed for SEPAmail
3.121/3.1.25 [0..1] +++++ BranchIdentification SEPAMAIL rule
Not Allowed for SEPAmail
3.122 [1..1] ++++ CreditorAgent
ISO20022 rule
Financial institution servicing an account for the creditor.
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /CdtrAgt] (2.63) within the [RUBIS Payment Activation Request] message, though the copy of the following substructures is optional: - ClearingSystemMemberIdentification - Name - PostalAddress - Other - BranchIdentification
SELF-MAP rule
[ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /RepCompl /Report /GrpHdr /CdtrAgt] (1.5) and this structure refer to same actor, respectively at group and transaction level.
MAP TO rule
This structure must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /CdtrAgt] (2.53) within the [SEPA Inter-Bank Credit Transfer] message with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset (*).
3.122/3.1.0 [1..1] +++++ FinancialInstitutionIdentification ISO20022 rule
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
SEPAmailNorme1206–ÉditiondeJuin2015 Page198
3.122/3.1.1 [0..1] ++++++ BICFI
ISO20022 rule
Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAMAIL rule
BICFI Valid BICs for financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE and BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
SEPAMAIL rule
Mandatory
3.122/3.1.2 [0..1] ++++++ ClearingSystem-MemberIdentification
ISO20022 rule
Information used to identify a member within a clearing system.
3.122/3.1.3 [0..1] +++++++ ClearingSystemIdentification ISO20022 rule
Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.
3.122/3.1.4 [1..1] | ++++++++ Code ISO20022 rule
Identification of a clearing system, in a coded form as published in an external list.
3.122/3.1.5 [1..1] | ++++++++ Proprietary ISO20022 rule
Identification code for a clearing system that has not yet been identified in the list of clearing systems.
3.122/3.1.6 [1..1] +++++++ MemberIdentification ISO20022 rule
Identification of a member of a clearing system.
3.122/3.1.7 [0..1] ++++++ Name ISO20022 rule
Name by which an agent is known and which is usually used to identify that agent.
3.122/3.1.8 [0..1] ++++++ PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
SEPAmailNorme1206–ÉditiondeJuin2015 Page199
3.122/3.1.9 [0..1] +++++++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
3.122/3.1.10 [0..1] +++++++ Department ISO20022 rule
Identification of a division of a large organisation or building.
3.122/3.1.11 [0..1] +++++++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
3.122/3.1.12 [0..1] +++++++ StreetName ISO20022 rule
Name of a street or thoroughfare.
3.122/3.1.13 [0..1] +++++++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
3.122/3.1.14 [0..1] +++++++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
3.122/3.1.15 [0..1] +++++++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
3.122/3.1.16 [0..1] +++++++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
3.122/3.1.17 [0..1] +++++++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.122/3.1.18 [0..7] +++++++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
SEPAmailNorme1206–ÉditiondeJuin2015 Page200
3.122/3.1.19 [0..1] ++++++ Other ISO20022 rule
Unique identification of an agent, as assigned by an institution, using an identification scheme.
3.122/3.1.20 [1..1] +++++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
3.122/3.1.21 [0..1] +++++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.122/3.1.22 [1..1] | ++++++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
3.122/3.1.23 [1..1] | ++++++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
3.122/3.1.24 [0..1] +++++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.122/3.1.25 [0..1] +++++ BranchIdentification ISO20022 rule
Identifies a specific branch of a financial institution
3.122/3.1.26 [0..1] ++++++ Identification ISO20022 rule
Unique and unambiguous identification of a branch of a financial institution.
3.122/3.1.27 [0..1] ++++++ Name ISO20022 rule
Name by which an agent is known and which is usually used to identify that agent.
3.122/3.1.28 [0..1] ++++++ PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
3.122/3.1.29 [0..1] +++++++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address.
SEPAmailNorme1206–ÉditiondeJuin2015 Page201
MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
3.122/3.1.30 [0..1] +++++++ Department ISO20022 rule
Identification of a division of a large organisation or building.
3.122/3.1.31 [0..1] +++++++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
3.122/3.1.32 [0..1] +++++++ StreetName ISO20022 rule
Name of a street or thoroughfare.
3.122/3.1.33 [0..1] +++++++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
3.122/3.1.34 [0..1] +++++++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
3.122/3.1.35 [0..1] +++++++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
3.122/3.1.36 [0..1] +++++++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
3.122/3.1.37 [0..1] +++++++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.122/3.1.38 [0..7] +++++++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
3.123 [1..1] ++++ Creditor
ISO20022 rule
Party to which an amount of money is due.
SEPAMAIL rule
Mandatory
SEPAmailNorme1206–ÉditiondeJuin2015 Page202
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /Cdtr] (2.64) within the [RUBIS Payment Activation Request] message.
MAP TO rule
This structure must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /Cdtr] (2.55) within the [SEPA Inter-Bank Credit Transfer] message with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset (*).
See details below
3.124 [0..1] ++++ CreditorAccount
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction.
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /CdtrAcct] (2.65) within the [RUBIS Payment Activation Request] message, though the copy of the following substructures is optional: - Type - Currency - Name
MAP TO rule
This structure must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /CdtrAcct] (2.56) within the [SEPA Inter-Bank Credit Transfer] message with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset (*).
3.124/1.1.0 [1..1] +++++ Identification ISO20022 rule
Unique and unambiguous identification for the account between the account owner and the account servicer.
3.124/1.1.1 [1..1] | ++++++ IBAN
ISO20022 rule
International Bank Account Number (IBAN) - identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions.
ISO20022 rule
A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.
SEPAMAIL rule
Mandatory
SEPAmailNorme1206–ÉditiondeJuin2015 Page203
3.124/1.1.2 [1..1] | ++++++ Other SEPAMAIL rule
Not Allowed for SEPAmail
3.124/1.1.8 [0..1] +++++ Type ISO20022 rule
Specifies the nature, or use of the account.
3.124/1.1.9 [1..1] | ++++++ Code
3.124/1.1.10 [1..1] | ++++++ Proprietary
3.124/1.1.11 [0..1] +++++ Currency
ISO20022 rule
Identification of the currency in which the account is held. Usage: Currency should only be used in case one and the same account number covers several currencies and the initiating party needs to identify which currency needs to be used for settlement on the account.
ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
3.124/1.1.12 [0..1] +++++ Name ISO20022 rule
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account. Usage: The account name is different from the account owner name. The account name is used in certain user communities to provide a means of identifying the account, in addition to the account owner's identity and the account number.
3.125 [0..1] ++++ UltimateCreditor
ISO20022 rule
Ultimate party to which an amount of money is due.
MAP FROM rule
This structure must be copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /UltmtCdtr] (2.66) within the [RUBIS Payment Activation Request] message. However, the copy of the substructures is only mandatory for data that will be eventually forwarded within the SEPA Credit Transfer Core Mandatory Subset (*). The other data may optionally be copied.
MAP TO rule
This structure must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /UltmtCdtr] (2.57) within the [SEPA Inter-Bank Credit Transfer] message with respect of the limits of the SEPA Credit Transfer Core Mandatory Subset (*).
See details below
SEPAmailNorme1206–ÉditiondeJuin2015 Page204
Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/GrpHdr/InitgPty element (previously indexed as 1.3)
Ref. Mult. Ch. Depth Message element Requirements
1.3/4.1.0 [0..1] + Name
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
SEPAMAIL rule
Name is mandatory if it is not a bank
1.3/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
1.3/4.1.2 [0..1] ++ AddressType
ISO20022 rule
Identifies the nature of the postal address.
ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
1.3/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
1.3/4.1.4 [0..1] ++ SubDepartment ISO20022 Identification of a sub-division of a large organisation or building.
SEPAmailNorme1206–ÉditiondeJuin2015 Page205
rule
1.3/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
1.3/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
1.3/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
1.3/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
1.3/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
1.3/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.3/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
1.3/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
1.3/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
1.3/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE,
SEPAmailNorme1206–ÉditiondeJuin2015 Page206
COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
SEPAMAIL rule
BIC (in Id) is mandatory if it is a bank
1.3/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
1.3/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
1.3/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
1.3/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
1.3/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
1.3/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
1.3/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
1.3/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
1.3/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
1.3/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 Province where a person was born.
SEPAmailNorme1206–ÉditiondeJuin2015 Page207
rule
1.3/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
1.3/4.1.26 [1..1] | ++++ CountryOfBirth
ISO20022 rule
Country where a person was born.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.3/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
1.3/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
1.3/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
1.3/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
1.3/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
1.3/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
1.3/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
1.3/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
SEPAmailNorme1206–ÉditiondeJuin2015 Page208
1.3/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
1.3/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
1.3/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
1.3/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
1.3/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
1.3/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
1.3/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlGrpInfAndSts/StsRsnInf/Orgtr element (previously indexed as 2.8)
Ref. Mult. Ch. Depth Message element Requirements
2.8/4.1.0 [0..1] + Name
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
SEPAMAIL rule
Name is mandatory if the originator is not a bank
2.8/4.1.1 [0..1] + PostalAddress SEPAMAIL rule
Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page209
2.8/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
2.8/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
2.8/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
SEPAMAIL rule
BIC is mandatory if the originator is a bank
2.8/4.1.15 [0..*] | +++ Other SEPAMAIL rule
Not Allowed for SEPAmail
2.8/4.1.21 [1..1] | ++ PrivateIdentification SEPAMAIL rule
Not Allowed for SEPAmail
2.8/4.1.33 [0..1] + CountryOfResidence SEPAMAIL rule
Not Allowed for SEPAmail
2.8/4.1.34 [0..1] + ContactDetails SEPAMAIL rule
Not Allowed for SEPAmail
Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/StsRsnInf/Orgtr element (previously indexed as 3.21)
Ref. Mult. Ch. Depth Message element Requirements
SEPAmailNorme1206–ÉditiondeJuin2015 Page210
3.21/4.1.0 [0..1] + Name
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
SEPAMAIL rule
Name is mandatory if the originator is not a bank
3.21/4.1.1 [0..1] + PostalAddress SEPAMAIL rule
Not Allowed for SEPAmail
3.21/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
3.21/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
3.21/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
SEPAMAIL rule
BIC is mandatory if the originator is a bank
3.21/4.1.15 [0..*] | +++ Other SEPAMAIL rule
Not Allowed for SEPAmail
3.21/4.1.21 [1..1] | ++ PrivateIdentification SEPAMAIL rule
Not Allowed for SEPAmail
3.21/4.1.33 [0..1] + CountryOfResidence SEPAMAIL Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page211
rule
3.21/4.1.34 [0..1] + ContactDetails SEPAMAIL rule
Not Allowed for SEPAmail
Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/UltmtDbtr element (previously indexed as 3.118)
Ref. Mult. Ch. Depth Message element Requirements
3.118/4.1.0 [0..1] + Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.118/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
3.118/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
3.118/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
3.118/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
3.118/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
3.118/4.1.6 [0..1] ++ BuildingNumber ISO20022 Number that identifies the position of a building on a street.
SEPAmailNorme1206–ÉditiondeJuin2015 Page212
rule
3.118/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
3.118/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
3.118/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
3.118/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.118/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
3.118/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
3.118/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
3.118/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
SEPAmailNorme1206–ÉditiondeJuin2015 Page213
3.118/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
3.118/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
3.118/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.118/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
3.118/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
3.118/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.118/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
3.118/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
3.118/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
3.118/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 rule
Province where a person was born.
3.118/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
3.118/4.1.26 [1..1] | ++++ CountryOfBirth
ISO20022 rule
Country where a person was born.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
SEPAmailNorme1206–ÉditiondeJuin2015 Page214
3.118/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
3.118/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
3.118/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.118/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
3.118/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
3.118/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.118/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.118/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
3.118/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
3.118/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.118/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
SEPAmailNorme1206–ÉditiondeJuin2015 Page215
3.118/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
3.118/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
3.118/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
3.118/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/Dbtr element (previously indexed as 3.119)
Ref. Mult. Ch. Depth Message element Requirements
3.119/4.1.0 [0..1] + Name
SEPAMAIL rule
Mandatory for SEPAmail
ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.119/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
3.119/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
SEPAmailNorme1206–ÉditiondeJuin2015 Page216
3.119/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
3.119/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
3.119/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
3.119/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
3.119/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
3.119/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
3.119/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
3.119/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.119/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
3.119/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
3.119/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
3.119/4.1.14 [0..1] | +++ AnyBICIdentifier ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
SEPAmailNorme1206–ÉditiondeJuin2015 Page217
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
3.119/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
3.119/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
3.119/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.119/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
3.119/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
3.119/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.119/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
3.119/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
3.119/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
3.119/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 Province where a person was born.
SEPAmailNorme1206–ÉditiondeJuin2015 Page218
rule
3.119/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
3.119/4.1.26 [1..1] | ++++ CountryOfBirth
ISO20022 rule
Country where a person was born.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.119/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
3.119/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
3.119/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.119/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
3.119/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
3.119/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.119/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.119/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
SEPAmailNorme1206–ÉditiondeJuin2015 Page219
3.119/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
3.119/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.119/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
3.119/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
3.119/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
3.119/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
3.119/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/Cdtr element (previously indexed as 3.123)
Ref. Mult. Ch. Depth Message element Requirements
3.123/4.1.0 [0..1] + Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.123/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
SEPAmailNorme1206–ÉditiondeJuin2015 Page220
3.123/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
3.123/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
3.123/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
3.123/4.1.5 [0..1] ++ StreetName ISO20022 rule
Name of a street or thoroughfare.
3.123/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
3.123/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
3.123/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
3.123/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
3.123/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.123/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
SEPAmailNorme1206–ÉditiondeJuin2015 Page221
3.123/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
3.123/4.1.13 [1..1] | ++ OrganisationIdentification
ISO20022 rule
Unique and unambiguous way to identify an organisation.
SEPAMAIL rule
Mandatory for ICQX@SCHEME registered users.
3.123/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify: - the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
3.123/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
3.123/4.1.16 [1..1] | ++++ Identification
ISO20022 rule
Identification assigned by an institution.
MAP FROM rule
[ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /Cdtr /Id /OrgId /Othr /Id] (2.64/4.1.16) within the [RUBIS Payment Activation Request] message, when containing an ICQX, must be forwarded into this structure
3.123/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.123/4.1.18 [1..1] | | +++++ Code SEPAMAIL rule
Not Allowed for SEPAmail
SEPAmailNorme1206–ÉditiondeJuin2015 Page222
3.123/4.1.19 [1..1] | | +++++ Proprietary
ISO20022 rule
Name of the identification scheme, in a free text form.
SEPAMAIL rule
Must contain the value "SEPAMAIL.EU" when present
MAP FROM rule
[ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /CdtTrfTx /Cdtr /Id /OrgId /Othr /SchmeNm /Prtry] (2.64/4.1.19) within the [RUBIS Payment Activation Request] message, if valued with "SEPAMAIL.EU", must be forwarded into this structure.
3.123/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.123/4.1.21 [1..1] | ++ PrivateIdentification SEPAMAIL rule
Not Allowed for SEPAmail
3.123/4.1.33 [0..1] + CountryOfResidence SEPAMAIL rule
Not Allowed for SEPAmail
3.123/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
3.123/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
3.123/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.123/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
3.123/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
3.123/4.1.39 [0..1] ++ FaxNumber ISO20022 Collection of information that identifies a FAX number, as defined by telecom services.
SEPAmailNorme1206–ÉditiondeJuin2015 Page223
rule
3.123/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
3.123/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/UltmtCdtr element (previously indexed as 3.125)
Ref. Mult. Ch. Depth Message element Requirements
3.125/4.1.0 [0..1] + Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.125/4.1.1 [0..1] + PostalAddress
ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services.
ISO20022 rule
Postal address of a party.
3.125/4.1.2 [0..1] ++ AddressType ISO20022 rule
Identifies the nature of the postal address.
Code Name Definition
ADDR Postal Address is the complete postal address. BIZZ Business Address is the business address. DLVY DeliveryTo Address is the address to which delivery is to take place. HOME Residential Address is the home address. MLTO MailTo Address is the address to which mail is sent. PBOX POBox Address is a postal office (PO) box.
3.125/4.1.3 [0..1] ++ Department ISO20022 rule
Identification of a division of a large organisation or building.
3.125/4.1.4 [0..1] ++ SubDepartment ISO20022 rule
Identification of a sub-division of a large organisation or building.
3.125/4.1.5 [0..1] ++ StreetName ISO20022 Name of a street or thoroughfare.
SEPAmailNorme1206–ÉditiondeJuin2015 Page224
rule
3.125/4.1.6 [0..1] ++ BuildingNumber ISO20022 rule
Number that identifies the position of a building on a street.
3.125/4.1.7 [0..1] ++ PostCode ISO20022 rule
Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
3.125/4.1.8 [0..1] ++ TownName ISO20022 rule
Name of a built-up area, with defined boundaries, and a local government.
3.125/4.1.9 [0..1] ++ CountrySubDivision ISO20022 rule
Identifies a subdivision of a country such as state, region, country.
3.125/4.1.10 [0..1] ++ Country
ISO20022 rule
Nation with its own government.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.125/4.1.11 [0..7] ++ AddressLine ISO20022 rule
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
3.125/4.1.12 [0..1] + Identification ISO20022 rule
Unique and unambiguous identification of a party.
3.125/4.1.13 [1..1] | ++ OrganisationIdentificationISO20022 rule
Unique and unambiguous way to identify an organisation.
3.125/4.1.14 [0..1] | +++ AnyBICIdentifier
ISO20022 rule
Code allocated to a financial institution or non financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)".
ISO20022 rule
AnyBIC Only a valid Business identifier code is allowed. Business identifier codes for financial or non-financial institutions are registered by the ISO 9362 Registration Authority in the BIC directory, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: INSTITUTION CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The institution code, country code and location code are mandatory, while the branch code is optional. Warning: ISO 9362 has been modified in 2013 in order to specify:
SEPAmailNorme1206–ÉditiondeJuin2015 Page225
- the first four characters as the PARTY PREFIX (previously INSTITUTION CODE) - the two following characters as the COUNTRY CODE - the two following characters as the PARTY SUFFIX (previously COUNTRY CODE) - the three last characters as the BRANCH IDENTIFIER (previously BRANCH CODE)
3.125/4.1.15 [0..*] | +++ Other ISO20022 rule
Unique identification of an organisation, as assigned by an institution, using an identification scheme.
3.125/4.1.16 [1..1] | ++++ Identification ISO20022 rule
Identification assigned by an institution.
3.125/4.1.17 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.125/4.1.18 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
3.125/4.1.19 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
3.125/4.1.20 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.125/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule
Unique and unambiguous identification of a person, eg, passport.
3.125/4.1.22 [0..1] | +++ DateAndPlaceOfBirth ISO20022 rule
Date and place of birth of a person.
3.125/4.1.23 [1..1] | ++++ BirthDate ISO20022 rule
Date on which a person is born.
3.125/4.1.24 [0..1] | ++++ ProvinceOfBirth ISO20022 rule
Province where a person was born.
3.125/4.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule
City where a person was born.
3.125/4.1.26 [1..1] | ++++ CountryOfBirth ISO20022 Country where a person was born.
SEPAmailNorme1206–ÉditiondeJuin2015 Page226
rule
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.125/4.1.27 [0..*] | +++ Other ISO20022 rule
Unique identification of a person, as assigned by an institution, using an identification scheme.
3.125/4.1.28 [1..1] | ++++ Identification ISO20022 rule
Unique and unambiguous identification of a person.
3.125/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule
Name of the identification scheme.
3.125/4.1.30 [1..1] | | +++++ Code ISO20022 rule
Name of the identification scheme, in a coded form as published in an external list.
3.125/4.1.31 [1..1] | | +++++ Proprietary ISO20022 rule
Name of the identification scheme, in a free text form.
3.125/4.1.32 [0..1] | ++++ Issuer ISO20022 rule
Entity that assigns the identification.
3.125/4.1.33 [0..1] + CountryOfResidence
ISO20022 rule
Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
ISO20022 rule
Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.125/4.1.34 [0..1] + ContactDetails ISO20022 rule
Set of elements used to indicate how to contact the party.
3.125/4.1.35 [0..1] ++ NamePrefix ISO20022 rule
Specifies the terms used to formally address a person.
Code Name Definition
DOCT Doctor Title of the person is Doctor or Dr. MADM Madam Title of the person is Madam. MISS Miss Title of the person is Miss. MIST Mister Title of the person is Mister or Mr.
SEPAmailNorme1206–ÉditiondeJuin2015 Page227
3.125/4.1.36 [0..1] ++ Name ISO20022 rule
Name by which a party is known and which is usually used to identify that party.
3.125/4.1.37 [0..1] ++ PhoneNumber ISO20022 rule
Collection of information that identifies a phone number, as defined by telecom services.
3.125/4.1.38 [0..1] ++ MobileNumber ISO20022 rule
Collection of information that identifies a mobile phone number, as defined by telecom services.
3.125/4.1.39 [0..1] ++ FaxNumber ISO20022 rule
Collection of information that identifies a FAX number, as defined by telecom services.
3.125/4.1.40 [0..1] ++ EmailAddress ISO20022 rule
Address for electronic mail (e-mail).
3.125/4.1.41 [0..1] ++ Other ISO20022 rule
Contact details in another form.
Non-ISO part This part is only used by the SEPAmail/RUBIS system, to provide additional services both to creditor and debtor. Ref. Mult. Ch. Depth Message element Requirements
B2.1 [0..1] + OtherPmtMtd SEPAMAIL rule
This field must be used if the debtor prefers another payment method than the one requested by the creditor.
B2.1.1 [1..1] ++ PaymentMethod SEPAMAIL rule
Payment method chosen by debtor. Possible values are CHK (check), TRF (Transfer), DD (Direct Debit), and CARD (payment card). If this field is present, the PaymentMethod field, in the ISO part, will be ignored.
B2.1.2 [0..1] ++ PmtMtdId SEPAMAIL rule
Payment method-specific identifier: mandatory for CARD (the card number), it is optional in all other cases. For TRF payment, this field can be used to indicate another IBAN to be used for the transfer. For CHK or DD, it may hold an internal reference number.
B2.2 [0..1] + PmtGuarantee SEPAMAIL rule
Should be set to true if the bank guarantees the related payment
B2.3 [1..1] + ImmPmt SEPAMAIL rule
Mandatory. Reflects the decision of the Debtor about accepting immediate payment, if proposed by the creditor.
SEPAmailNorme1206–ÉditiondeJuin2015 Page228
MAP FROM rule
This structure is set to «False» if [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Complements /PmtCond /ImmPmtAccepted] (B2.2.2) within the [RUBIS Payment Activation Request] message was set to «False». Otherwise, ImmPmt is set to true (accepts) or false (does not accept) according to the choice of the debtor.
B2.4 [0..1] + ImmPmtRebate MAP FROM rule
This structure must be either omitted or copied from [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Complements /PmtCond /ImmPmtRebate] (B2.2.4) within the [RUBIS Payment Activation Request] message.
B2.5 [0..*] + PmtModif
SEPAMAIL rule
Debtor modified the amount to be paid, whether more or less than the instructed amount. This is possible only if the creditor accepts it (B2.2.1 true in the Request message). Each modified sum must be indicated by a PmtModif element and the associated PmtId.
MAP FROM rule
This structure is only set if the relevant [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Complements /PmtCond /PmtModifAccepted] (B2.2.1) within the [RUBIS Payment Activation Request] message was set to «True».
B2.5.1 [1..1] ++ PaymentIdentification
SEPAMAIL rule
The related PaymentIdentification, as it appears in the Request message.
MAP FROM rule
Each occurrence of this structure must be copied from the relevant occurrence of [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Request /PmtInf /PmtInfId] (2.1) within the [RUBIS Payment Activation Request] message in case of modification of the amount by the debtor.
B2.5.2 [1..1] ++ Amount
ISO20022 rule
CurrencyAmount The number of fractional digits (or minor unit of currency) must comply with ISO 4217. Note: The decimal separator is a dot.
SEPAMAIL rule
This structure must be set by the debtor in case of modification in order to specify the accepted amount, possibly with a currency code attribute.
MAP TO rule
This structure, if present, must be forwarded within each relevant [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /IntrBkSttlmAmt] (2.18) within the [SEPA Inter-Bank Credit Transfer] message.
[1..1] +++ Currency ISO20022 rule
ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged.
B2.6 [0..1] + TrfNature SEPAMAIL rule
The nature of the requested transfer. Possible values are IMMED and TERM. This field must match exactly the TrfNature field of the associated ActivationRequest message.
SEPAmailNorme1206–ÉditiondeJuin2015 Page229
MAP FROM rule
This structure must exactly match [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Complements /TrfNature] (B2.6) within the [RUBIS Payment Activation Request] message.
B2.7 [0..3] + CustRef
SEPAMAIL rule
Customer reference, delivered by the creditor, unambiguously identifying the debtor in the creditor reference system. If several ReportComplements are present, this field must have the same value in all structures.
MAP FROM rule
This structure must exactly match [ /PaymentActivationRequest /sepamail_message_payment_activation_request_001 /ReqCompl /Complements /CustRef] (B2.7) within the [RUBIS Payment Activation Request] message.
B2.8 [0..1] + DecisionDate SEPAMAIL rule
This structure is valued by the debtor bank with the date of the debtor's decision. This value is mandatory when the report notifies a decision of the debtor.
(*) The SEPA Credit Transfer Core Mandatory Subset to which several [MAP TO] rules refer in this document is the subset specified through the yellow shaded elements within the SEPA Credit Transfer Scheme Inter-Bank Implementation Guidelines produced by the European Payment Council.
SEPAmailNorme1206–ÉditiondeJuin2015 Page230
5.15. IGRubisActivationEnroll
These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the colour coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail message used by a debtor or his bank to
subscribe, or cancel a subscription, to a payment activation scheme.
The full name of this message is sepamail_message_payment.activation_PaymentActivationEnroll.
This message should be generated and sent by the debtor's bank, following a direct action from
the debtor.
No equivalent of this message exists in ISO schemas. Thus, the message only includes a non-ISO
part, described here.
Abstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
The actual contents of the ActivationEnroll element must be any one of the
sepamail_message_payment_activation_enroll_xxx structures.
Currently, only one such structure is defined, the 001.
ActivationEnrollbody
Ref Mult Message Element SEPAmail requirement
A1 [1..1] ++ CreDtTm Creation date and time, ISO format
A2 [1..1] ++ CdtrICQX Identifier of the creditor
A3 [1..1] ++ DbtrName First name + last name of the debtor. For a company, legal name.
A4 [1..1] ++ DbtrDsplName Debtor's displayed name (commercial name, alias ...)
A5 [1..1] ++ DbtrAcct Mandatory : IBAN (or QXBAN)
A6 [1..1] ++ DbtrAgt Mandatory : BIC
A7 [1..3] ++ CustRef
Customer references, delivered by the creditor, unambiguously
identifying the debtor in the creditor reference system for one
given contract.
A8 [1..1] ++ MyPmtMtd This field describes the debtor's preferred payment method.
A8.1 [1..1] +++ PmtMtd
Payment method chosen by debtor. Possible values are CHK
(check), TRF (Transfer), DD (Direct Debit), and CARD (payment
card).
Within 1206 version, the only usable value is TRF.
A8.2 [0..1] +++ PmtMtdId Payment method-specific identifier: mandatory for CARD (the card
number), it is optional in all other cases. For TRF payment,
SEPAmailNorme1206–ÉditiondeJuin2015 Page231
this field can be used to indicate another IBAN to be used for
the transfer. For CHK or DD, it may hold an internal reference
number.
Within 1206 version, this tag is never used and must be absent.
A9 [0..1] ++ CommCond
A9.1 [1..1] +++ Enrolled
Indicates that the debtor, regarding the relevant creditor:
- either commits or updates (with another QXBAN) his enrolment
(value=true)
- or cancels a previous enrolment (value=false)
In case of enrolment updating, the new QXBAN replaces the
previous one.
A9.2 [0..1] +++
SendFullInvoice
Indicates if the debtor wants to receive full invoices included
in the payment requests. (default : invoice extracts only)
SEPAmailNorme1206–ÉditiondeJuin2015 Page232
6. L'applicationGEMME
SEPAmailNorme1206–ÉditiondeJuin2015 Page233
6.1. GEMMEGEMME est une application SEPAmail de gestion dématérialisée des mandats de prélèvements pour
les créanciers et les débiteurs.
Son sigle est GEMME@SEPAmail. GEMME est l'acronyme anglais de "Global European Mandate
Management and Exchange"
L'application permet d'initier des mandats de prélèvements ainsi que tous les flux autour du
prélèvement : pré-notification des échéances, acceptation ou refus d'échéance, acceptation ou
refus de l'autorisation de mandat de prélèvement, demande de copie.
SEPAmailNorme1206–ÉditiondeJuin2015 Page234
6.2. Lesprincipesgénéraux(GEMME) GEMME est une application SEPAmail permettant l'interaction entre un créancier et un
débiteur autour du prélèvement national et du prélèvement SEPA :
1. échanges électroniques de mandats de prélèvements (demande, acceptation, modification, révocation)
2. vérification du consentement du client et signature à distance
3. gestion des prénotifications (envoi, refus total ou partiel)
4. information du créancier en cas de révocation par le débiteur auprès de la banque
5. gestion des demandes de copie (request for copy)
GEMME est motorisé par SEPAmail pour l'échange des messages. Ceux-ci sont fondés sur les
formats ou le dictionnaire ISO 20022. Les messages de GEMME peuvent s'adapter à tous les
systèmes de prélèvement :
prélèvement national (MINOS en France)
prélèvement SEPA : CORE ou B2B
SEPAmailNorme1206–ÉditiondeJuin2015 Page235
6.3. Lesavantagespourleclient(GEMME)Pourlecréancier
relation commerciale et de confiance maintenue avec sa banque
une automatisation de l'envoi des mandats de prélèvement
une capacité de faire signer électroniquement les mandats de prélèvement
une automatisation d'envoi des copies de mandats de prélèvements en cas de demandes
une dématérialisation des courriers de notification d'échéance
une transparence dans l'évaluation du risque "mandat SDD non signé" auprès de sa banque
Pourledébiteur
relation commerciale et de confiance maintenue avec sa banque
une capacité de gérer, c'est à dire approuver et révoquer, les mandats de prélèvements
via les canaux mis à disposition par sa banque
capacité à recevoir les avis de notifications d'échéances via les canaux mis à
disposition par sa banque
une suppression des délais de prise en compte des services nécessitant un prélèvement
SEP
Pour
fonc
Pour
prél
Pour
AmailNorm
6.4. r les créa
ction des
Face à
1.
2.
À dista
1.
2.
r la banqu
lèvement à
mandat
idéal)
mandat
qu'aprè
mandat
Mandat
r les mand
capacit
le prél
me1206–Éd
Casd'unciers, le
technologi
face :
terminal d
signature
ance
réception
enregistre
données cl
e du créan
gérer :
signé avec
déclaré si
ès une véri
non signé
tsignéélec
ats signés
té de routa
lèvement SE
ditiondeJui
usageses cas d'us
ies employé
de contract
d'un manda
postale de
ement, par
lient pour
ncier ces d
c capacité
igné, c'es
ification
où tout r
troniquem
s électroni
age du man
EPA CORE m
in2015
(GEMMsages se st
ées :
tualisation
at papier
e mandat pa
un centre
initialisa
différents
de vérifi
t à dire s
manuelle v
este à fai
ment
iquement, G
dat de pré
ais reste
ME)tructurent
n et de si
(commerçan
apier (abo
d'appel o
ation d'un
cas d'usa
ication aut
signé manue
vis à vis d
ire pour qu
GEMME prés
élèvement :
indispensa
suivant l
gnature él
ts sans ou
nnements a
u au trave
mandat
ges se rés
tomatique d
ellement do
d'une signa
u'il ait un
ente l'ava
: cette fon
able pour l
'interacti
ectronique
utils élect
aux journau
ers d'un si
ument à tr
de la signa
ont la val
ature dépos
n minimum d
ntage suiv
nction n'es
le SDD B2B
ion avec le
e
troniques)
ux par exem
ite interne
rois types
ature (a p
idité n'es
sée
de valeur
vant :
st pas néc
et pour l
Page
e client en
mple)
et, des
de mandats
priori le c
t effectiv
cessaire po
e prélèvem
e236
n
s de
cas
ve
our
ment
SEP
Dans
GEMM
déb
En p
prél
L'ad
pren
créa
AmailNorm
nationa
fixée à
Mandat
s cette co
la sign
smartph
l'envoi
lendema
la pris
éviter
Mandat
ME offre l
iteurs.
particulie
lèvement.
Conclus
daptabilit
ndre en ch
ancier que
me1206–Éd
al. Pour ce
à début 20
tdéclarésig
nfiguratio
nature immé
hone
i sur la ba
ain
se en compt
un rejet
tnonsigné
a capacité
r, GEMME p
sion:uneg
é des mess
arge tous
du point
ditiondeJui
e dernier
14
gné
on, GEMME p
édiate, si
anque à di
te par la
é de signat
peut offrir
gestionmul
sages GEMME
les cas d'
de vue déb
in2015
la portée
peut permet
le client
stance pou
banque du
ture du man
r une solut
lti‐canauxd
E ainsi que
usage de m
biteur.
de cette n
ttre :
t-débiteur
ur contre-s
débiteur p
ndat par m
tion à la
desmandat
e la capac
mise en œu
nécessité e
possède un
signature u
pour autori
ise à disp
vente sur
ts
ité multi-
vre du pré
est réduite
ne applicat
ultérieure
iser a prio
osition au
Internet d
canal de S
lèvement t
e car la e
tion SEPAm
le soir o
ori le pré
uprès des c
de produit
SEPAMAIL pe
tant du poi
Page
end-date es
mail sur
ou le
élèvement e
clients
payable pa
ermettent d
int de vue
e237
st
et
ar
de
SEP
Le p
au S
Le r
Cell
On y
Ces
soum
AmailNorm
6.5. prélèvemen
SEPA.
rulebook S
le-ci est
y trouve :
1. les saimandat
2. la mise
3. la vali
4. les not
5. le refu
6. la dema
7. le prél
8. le reto
différent
mises à de
le prél
prévoit
1.
2.
me1206–Éd
Laprobt est un m
DD 33 du SE
synthétisé
isies des d
de prélève
e à disposi
idation/sig
tifications
us d'échéan
ande de cop
lèvement ef
our/rejet p
es interac
s règles e
lèvement na
t :
un mandat
créancier
que l'exem
ditiondeJui
blématmoyen de pa
PA Direct
ée sur le s
données cr
ement.
ition du m
gnature du
s d'échéan
nce ou la
pie de man
ffectif pa
par la ban
ctions, que
et à une lo
ational fr
double ave
et un exem
mplaire de
in2015
tiquedaiement en
Debit prés
schéma suiv
éancier/dé
andat de p
mandat de
ces émises
révocation
dat de pré
r le créan
que du déb
e l'on retr
ogique prop
ançais, lo
ec 2 signat
mplaire pou
la banque
esfluxforte évo
sente bien
vant :
ébiteurs pa
prélèvement
e prélèveme
s par le cr
n temporair
élèvement p
ncier
biteur
rouve dans
pres à cha
ogique comm
tures clie
ur la banq
du débite
autourlution, ce
la problém
ar chacune
t pour vali
ent par le
réancier
re ou perma
par le débi
tous les
que systèm
munément ap
nt pour av
ue du débi
ur soit en
rduprlle-ci éta
matique gé
des partie
idation/sig
débiteur
anente du m
iteur en ca
systèmes d
me :
ppelé Debto
voir un exe
teur
nvoyé par l
rélèvemant princip
énérale du
es pour in
gnature
mandat de
as de récl
de prélèvem
tor Mandate
emplaire ch
le créancie
Page
mentpalement du
prélèvemen
nitier un
prélèvemen
amation
ments, sont
e Flow (DMF
hez le
er
e238
ue
nt.
nt
t
F)
SEPAmailNorme1206–ÉditiondeJuin2015 Page239
3. ce mandat ne comporte pas de numéro
le prélèvement SDD CORE, logique connue sous le nom de Creditor Mandate Flow (CMF)34
prévoit :
1. un mandat unique gardé par le créancier donc pas d'envoi à la banque du débiteur
2. un numéro unique par créancier-mandat imprimé sur le mandat
3. le transport de ce numéro dans le flux de prélèvements
le prélèvement SDD B2B prévoit :
1. une validation systématique du mandat par le débiteur ET une connaissance par la banque du débiteur
2. le transport des numéros de mandats dans les flux de prélèvements qui ne peuvent plus être refusés puisqu'il y a assurance de validité du mandat
Ces trois logiques doivent rester compatibles dans les traitements pour assurer une migration
fluide du prélèvement national vers le prélèvement SDD CORE et pouvoir réaliser des synergies
entre les développements pour le SDD CORE et le SDD B2B. L'utilisation du circuit CMF, même si
elle est plus simple en première approche, impose la création d'une procédure de demande de
copie pour les réclamations. Compte tenu du nombre de prélèvements, il ne paraît pas
souhaitable de conserver une procédure manuelle entre les banques.
La transposition de la Directive des Services de Paiement (DSP) a prévu la continuité des
demandes et autorisations de prélèvements français en mandats SDD CORE. Hélas, l'archivage
papier est réparti : une partie chez le créancier, une partie chez la banque du débiteur. Ceci
fait qu'il est matériellement très difficile de retrouver les deux parties d'un mandat en cas
de nécessité judiciaire.
De plus, les notifications d'échéances (pré-notifications) sont aujourd'hui sous format papier,
ce qui rend la gestion des refus totaux ou partiels impossible.
SEP
GEMM
mand
rése
Sur
AmailNorm
6.6. ME propose
dat de pré
eau SEPAma
ce concep
1. le fluxou le s
me1206–Éd
Lagest que l'ens
lèvement,
il.
t les inte
x commercia
service, le
ditiondeJui
tiondesemble des
se fassent
eractions i
al entre l
e mode de
in2015
sflux(interactio
t sous form
initiales p
e client e
paiement p
(GEMMons, entre
me de mess
peuvent se
et le créan
par prélève
E)le débite
ages struc
représent
ncier se co
ement et l'
ur et le c
turés et d
er sur le
onclut par
échange de
créancier c
dédiés au t
schéma sui
un accord
e l'IBAN
Page
concernant
travers du
ivant :
d sur le bi
e240
le
ien
SEPAmailNorme1206–ÉditiondeJuin2015 Page241
2. le créancier formate un mandat avec le numéro et tous les éléments constitutifs dont l'IBAN et donne le tout à sa banque
3. celle-ci le route vers la banque du débiteur facilement avec SEPAmail car elle connait l'IBAN
4. cette dernière met le mandat à disposition du client-débiteur dans la banque à distance ou tout autre canal de son choix (choix de la banque du débiteur). Le débiteur peut donc
valider, avec les moyens d’authentification proposés par la banque, le mandat. Le
routage vers la banque du créancier puis vers le créancier complétera le processus.
5. le créancier peut envoyer les notifications d'échéances sous un format électronique : l'adresse de son client reste l'IBAN ; le débiteur peut recevoir directement, par sa
banque à distance ou tout autre canal mis à disposition par sa banque, les notifications
et y répondre rapidement en cas de désaccord
6. un message complémentaire de “Demande de Copie” permet de compléter le dispositif. En
effet si un client réclame car il indique ne pas avoir signé de mandat pour un
prélèvement, sa banque prend l'IBAN du créancier dans le prélèvement et est ainsi
capable de formater un message de demande de copie vers la banque du créancier.
SEPAmailNorme1206–ÉditiondeJuin2015 Page242
6.7. Lesnormesutilisées(GEMME)Anticipant la fin des prélèvements nationaux européens, GEMME se base sur les formats ISO 20
022 :
“Demande de Création de Mandat” : pain.009
“Réponse à Demande de Création de Mandat” : pain.012
Pour les autres messages (“Prénotification” et “Demande de Copie”), seul le dictionnaire
ISO 20 022 a été utilisé, en l'absence de messages déjà définis.
SEP
Voic
AmailNorm
6.8. ci les mes
message
prélève
message
ou révo
message
message
débiteu
me1206–Éd
Lerécasages poss
e SEPAmail
ement ou de
e SEPAmail
ocation par
e SEPAmail
e SEPAmail
ur
ditiondeJui
apitulasibles pour
“Demande e modifica
“Réponse r le débit
“Prénoti
“Demande
in2015
tifdesr GEMME :
e de Créatition de ma
e à Demandeeur de man
ification”
e de Copie”
messag
ion de Mandandat
e de Créatindat de pré
: notific
” : demand
ges(GE
dat” : env
ion de Mandélèvement
cation des
de de copie
EMME)
voi par le
dat” : acc
échéances
e de mandat
créancier
ceptation,
et refus
t par la b
Page
r de mandat
modificat
des échéan
banque du
e243
t de
tion
nces
SEPAmailNorme1206–ÉditiondeJuin2015 Page244
6.9. Lesrèglesmétier(GEMME)Objetdudocument
Ce document décrit l'écosystème de messages GEMME de gestion de mandats électroniques, dans le
cadre du mécanisme global SEPAmail. Il est destiné à des interlocuteurs fonctionnels, en
complément des éléments contenus dans les directives d'implémentation (implementation
guidelines).
Présentationgénérale
GEMME vise à établir un ensemble de règles et d'outils permettant de gérer des mandats de
prélèvement, de façon totalement sécurisée. La gestion de mandats de prélèvement inclut
notamment :
leur création, généralement réalisée par le créancier
leur validation par le débiteur, sous plusieurs formes
la gestion d'un échéancier de paiements, avec possibilité d'acceptation ou de refus de
chaque échéance par le débiteur
les modifications du mandat de prélèvement (changement de domiciliation bancaire
notamment)
et plus généralement toute forme de communication entre le créancier et le débiteur,
associée à un mandat de prélèvement.
MessagesdelafamilleGEMME
Le nom usuel GEMME (Global European Mandate Management and Exchange) correspond à l'écosystème direct.debit35.
Dans cette famille, quatre messages ont été définis à ce jour :
Le message “Demande de Création de Mandat”
Le message “Réponse à Demande de Création de Mandat”
Le message “Prénotification”
Le message “Demande de Copie”
Nous allons décrire en détail l'utilisation des messages liés à GEMME.
Lemessage“DemandedeCréationdeMandat”
Ce message est utilisé dans les cas suivants, à l'initiative du créancier :
création d'un mandat de prélèvement
modification d'un mandat de prélèvement existant
Ce message est fondé sur le message MandateInitiationRequest (pain.009) de la norme ISO 20022, mais comporte également des informations complémentaires, spécifiques à GEMME, qui ne figurent
pas dans le pain.009.
Lemessage“RéponseàDemandedeCréationdeMandat”
Ce message est utilisé dans les cas suivants, à l'initiative du débiteur :
validation (acceptation ou refus) d'un mandat de prélèvement
changement d'IBAN pour un mandat de prélèvement existant
SEPAmailNorme1206–ÉditiondeJuin2015 Page245
L'interface mise à disposition du débiteur par sa banque doit permettre d'accéder aux mandats
de prélèvement en attente de validation (messages “Demande de Création de Mandat” reçus), et
d'opter explicitement pour son acceptation ou refus. Cette décision déclenche alors l'envoi
d'un message SEPAmail “Réponse à Demande de Création de Mandat”.
Ce message est fondé sur le message MandateAcceptanceReport (pain.012) de la norme ISO 20022, mais comporte aussi quelques informations complémentaires, spécifiques à GEMME.
Lemessage“Prénotification”
Ce message peut être envoyé par un créancier à un débiteur dans deux occasions :
de façon générale, pour indiquer l'échéancier de paiement prévisionnel
de façon locale, pour aviser le débiteur du prochain prélèvement
De plus, ce même message est utilisé par le débiteur pour accepter ou refuser une ou plusieurs
échéances, parmi celles proposées par le créancier. Ceci est réalisé en reprenant un ou
plusieurs éléments "Trs" de la demande, en conservant le "TrsId" pour permettre le
rapprochement, et en y ajoutant des éléments "Accepted" valant true ou false selon que l'échéance est acceptée ou refusée.
Règles associées à la prénotification :
Il n'est pas obligatoire de reprendre toutes les échéances dans le message de réponse
Toute échéance absente du message de réponse est réputée refusée par le débiteur.
L'effet réel de ce refus dépend des relations contractuelles entre créancier et
débiteur.
Le message “Prénotification” reprend certains éléments du message pain.009 de l'ISO 20022, et
y ajoute les informations nécessaires à GEMME.
Lemessage“DemandedeCopie”
Ce message est utilisé à l'initiative du débiteur ou de sa banque pour demander copie du mandat
relatif à un prélèvement.
Le créancier doit répondre par un autre message “Demande de Copie”, portant le même
identifiant de demande. Ce message de réponse doit impérativement comporter, soit une copie
numérisée du document papier, soit la trace de la signature électronique du débiteur.
Exemplesd'interactionsentrelesacteurs(casimpliquantuncréancierayantadoptélanormeSEPAmaildanssonintégralité)
Envoietvalidationd'unmandatdeprélèvement
Banque du débiteur Débiteur Créancier
Banque créancier
SEPAmailNorme1206–ÉditiondeJuin2015 Page246
Obtient les éléments
auprès du débiteur.
Crée un message
“Demande de Création de Mandat” avec ces
éléments, plus ses
éléments propres (BIC,
IBAN, logo …) ainsi
qu'une copie du contrat
s'il le souhaite.
Le message est
encapsulé dans une
missive nominale,
acheminée vers sa
banque
Reçoit la missive
nominale, génère une
missive d'acquittement
minimale indiquant sa
réception et indiquant
si la banque du
débiteur est ou non
connectée à SEPAmail
GEMME en interrogeant
le référentiel
bic.service@scheme.
Si la banque du
débiteur est raccordée,
la missive lui est
expédiée.
SEPAmailNorme1206–ÉditiondeJuin2015 Page247
Reçoit la missive
nominale, génère une
missive d'acquittement
avec des éléments
complémentaires
(validité du BIC/IBAN,
par exemple).
Met le mandat de
prélèvement à
disposition du débiteur
par tout moyen à sa
convenance (système de
banque à distance ...)
Prend connaissance du
mandat de prélèvement.
Si nécessaire
(validation SEPAmail),
le valide ou le
rejette.
Sur l'action du
débiteur, crée un
message “Réponse à Demande de Création de Mandat” avec les mêmes
références de mandat de
prélèvement et
l'indication de
l'action du débiteur,
l'encapsule dans une
missive nominale et
l'envoie à la banque du
créancier.
SEPAmailNorme1206–ÉditiondeJuin2015 Page248
Reçoit la missive
nominale, envoie la
missive d'acquittement
correspondante.
Met le message à
disposition du
créancier par tout
moyen à sa convenance
(système de banque à
distance ...)
Demanded'unecopie
Banque du débiteur Débiteur Créancier
Banque créancier
(optionnel) demande
justification d'un
prélèvement (via Banque
à Distance ou autre)
Crée un message
“Demande de Copie”
avec les éléments de la
transaction, du
débiteur et du
créancier, l'encapsule
dans une missive
nominale.
SEPAmailNorme1206–ÉditiondeJuin2015 Page249
Reçoit la missive
nominale, envoie la
missive d'acquittement
correspondante.
Met le message à
disposition du
créancier par tout
moyen à sa convenance
(système de banque à
distance, connecteur
entreprise ...)
Prend connaissance de
la demande, récupère
les éléments
contractuels, construit
un autre message
“Demande de Copie” et
l'encapsule dans une
missive nominale
Reçoit la missive
nominale, envoie la
missive d'acquittement
correspondante.
Transfère la missive à
la banque du débiteur.
SEPAmailNorme1206–ÉditiondeJuin2015 Page250
Reçoit la missive
nominale, envoie la
missive d'acquittement
correspondante.
Stocke les informations
relatives au mandat de
prélèvement si elle le
souhaite.
Met le message à
disposition du débiteur
par tout moyen à sa
convenance (système de
banque à distance ...)
SEPAmailNorme1206–ÉditiondeJuin2015 Page251
6.10. IGdirect.debitL'écosystème direct.debit comporte quatre messages :
Nom Directives d'implémentation Schéma
MandateAcceptanceReport Standards:IG_Gemme_MandateAcceptanceReport Schéma
MandateInitiationRequest Standards:IG_Gemme_MandateInitiationRequestSchéma
Prenotification Standards:IG_Gemme_Prenotification Schéma
RequestForCopy Standards:IG_Gemme_RequestForCopy Schéma
SEPAmailNorme1206–ÉditiondeJuin2015 Page252
6.11. IGGemmeMandateInitiationRequest These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail message used to request or indicate the
creation of a mandate.
The full name of this message is sepamail_message_direct.debit_MandateInitiationRequest.
This message must be generated on behalf of the creditor, and sent by itself or by its bank.
The generating events can be, for instance:
creation of a new mandate, associated for instance with a new contract
modification of an existing mandate
The second case occurs when the debtor wishes to change the bank account associated with the
mandate : the debtor sends a request for this change, currently as a “Mandate Acceptance Report” message, and the creditor is expected to answer with a modified “Mandate Initiation Request” message, including the new bank account. The debtor can then check and validate this
new mandate.
This message is based upon ISO 10022 pain.009 schema. For adaptability reasons, it also
includes non-ISO parts. All message parts are described in this document.
MessageRoot
Mult Message Element SEPAmail requirement
[1..1] + DirectDebitMandat
ISOandNon‐ISOparts
The "Mandat" element (A, below) has an optional attribute named id. This attribute is meant to be used when the optional signature is being used, to allow a precise designation of the
element being signed.
Ref Mult Message Element SEPAmail requirement
A [1..1] ++ Mandat MandateInitiationRequestV01, as per ISO pain.009
B [0..1] ++ DSExt Non-ISO part, described further in this document
ISOPart:MandateInitiationRequestV01
Please note : this whole part is directly copied from "EPC002-09 e-mandate service IG 4.0 Approved" and is only provided here for ease of reference.
GroupHeader
The group header contains information required for the processing of the entire message.
Ref Mult Message Element SEPA/SEPAmail requirement
SEPAmailNorme1206–ÉditiondeJuin2015 Page253
1.0 [1..1] + Group Header
1.1 [1..1] ++ Message Identification
1.2 [1..1] ++ Creation Date Time
1.3 [0..2] ++ Authorisation
1.4 {Or +++ Code
1.5 Or} +++ Proprietary (AT-60 – The reference of the validation made by
the Debtor Bank)
1.6 [0..1] ++ Initiating Party
1.7 [0..1] ++ Instructing Agent
1.8 [0..1] ++ Instructed Agent
Mandate
Ref Mult Message Element SEPA/SEPAmail requirement
2.0 [1..1] + Mandate
2.1 [0..1] ++ Mandate Identification
(AT-01 Unique Mandate Reference) Usage Rule: If
"Mandate Identification" is available at the time
of the sending of the Mandate Initiation Request
Message, then it should be given. It will be used
in all later opportunities to track messages
related to this mandate.
2.2 [1..1] ++ Mandate Request
Identification
Usage Rule: If "Mandate Identification" is
available at the time sending of the Mandate
Initiation Request Message, then "Mandate Request
Identification" may be a copy of "Mandate
Identification".
2.3 [0..1] ++ Type Mandatory
2.4 [0..1] +++ Service Level Mandatory
2.5 {Or ++++ Code (AT-20 The identification code of the Scheme)
Usage Rule : Only "SEPA" is allowed.
2.6 Or} ++++ Proprietary
2.7 [0..1] +++ Local Instrument Mandatory
2.8 {Or ++++ Code
(AT-20 The identification code of the Scheme).
Allowed values are
CORE: SDD CORE mandate
B2B: SDD B2B mandate
empty: direct debit
2.9 Or} ++++ Proprietary
2.10 [0..1] ++ Occurrences Mandatory
2.11 [1..1] +++ Sequence Type (AT-21 Transaction Type)
2.12 [0..1] +++ Frequency
2.13 [0..1] +++ Duration
2.14 [0..1] +++ First Collection Date
2.15 [0..1] +++ Final Collection Date
SEPAmailNorme1206–ÉditiondeJuin2015 Page254
Ref Mult Message Element SEPA/SEPAmail requirement
2.16 [0..1] ++ Collection Amount
2.17 [0..1] ++ Maximum Amount
2.18 [0..1] ++ Creditor Scheme
Identification Mandatory
2.18 [0..1] +++ Name
2.18 [0..1] +++ Postal Address
2.18 [0..1] +++ Identification Mandatory (AT-02 Identifier of the Creditor)
2.18 {Or ++++ Organisation
Identification
2.18 Or} ++++ Private Identification
Usage Rule: "Private Identification" is mandatory
to identify either an organisation or a private
person. Usage Rule : "Scheme Name" under "Other"
must specify "SEPA" under "Code". Usage Rule :
"Identification" under "Other" is allowed using an
identifier described in General Message Element
Specifications, Chapter 1.5.2. Usage Rule : Only
one occurrence of "Other" is allowed. The SCI
(ICS) must appear here and not in the 2.19
(Creditor) element.
2.18 [0..1] +++ Country of Residence
2.18 [0..1] +++ Contact Details
2.19 [1..1] ++ Creditor
2.19 [0..1] +++ Name
Mandatory (AT-03 Name of the Creditor) Usage
Rule : "Name" is limited to 70 characters in
length.
2.19 [0..1] +++ Postal Address (AT-05 Address of the Creditor)
2.19 [0..1] ++++ Address Type
2.19 [0..1] ++++ Department
2.19 [0..1] ++++ Sub-Department
2.19 [0..1] ++++ Street Name
2.19 [0..1] ++++ Building Number
2.19 [0..1] ++++ Postal Code
2.19 [0..1] ++++ Town Name
2.19 [0..1] ++++ Country Sub-Division
2.19 [0..1] ++++ Country
2.19 [0..7] ++++ Address Line Usage Rule : Only two occurrences are allowed.
2.19 [0..1] +++ Identification
2.19 [0..1] +++ Country of Residence
2.19 [0..1] +++ Contact Details
2.20 [0..1] ++ Creditor Account IBAN
2.21 [0..1] ++ Creditor Agent BIC
SEPAmailNorme1206–ÉditiondeJuin2015 Page255
Ref Mult Message Element SEPA/SEPAmail requirement
2.22 [0..1] ++ Ultimate Creditor
2.22 [0..1] +++ Name
(AT-38 Name of the Creditor Reference Party) Usage
Rule : "Name" is limited to 70 characters in
length.
2.22 [0..1] +++ Postal Address
2.22 [0..1] +++ Identification (AT-39 Identification code of the Creditor
Reference Party)
2.22 {Or ++++ Organisation
Identification
Usage Rule : Either "BIC or BEI" or one occurrence
of "Other" is allowed.
2.22 Or} ++++ Private Identification Usage Rule : Either "Date and Place of Birth" or
one occurrence of "Other" is allowed.
2.22 [0..1] +++ Country of Residence
2.22 [0..1] +++ Contact Details
2.23 [1..1] ++ Debtor
2.23 [0..1] +++ Name Mandatory (AT-14 Name of the Debtor) Usage Rule :
"Name" is limited to 70 characters in length.
2.23 [0..1] +++ Postal Address Mandatory (AT-09 Address of the Debtor)
2.23 [0..1] ++++ Address Type
2.23 [0..1] ++++ Department
2.23 [0..1] ++++ Sub Department
2.23 [0..1] ++++ Street Name
2.23 [0..1] ++++ Building Numb
2.23 [0..1] ++++ Post Code
2.23 [0..1] ++++ Town Name
2.23 [0..1] ++++ Country Subdivision
2.23 [0..1] ++++ Country
2.23 [0..7] ++++ Address Line Mandatory Usage Rule : Only two occurrences are
allowed.
2.23 [0..1] +++ Identification (AT-27 Debtor identification code)
2.23 {Or ++++ Organisation
Identification
Usage Rule : Either "BIC or BEI" or one occurrence
of "Other" is allowed.
2.23 Or} ++++ Private Identification Usage Rule : Either "Date and Place of Birth" or
one occurrence of "Other" is allowed.
2.23 [0..1] +++ Country of Residence
2.23 [0..1] +++ Contact Details
2.24 [0..1] ++ Debtor Account Mandatory
2.25 [1..1] ++ Debtor Agent Mandatory (AT-13 BIC of the Debtor Bank) Usage
Rule: Only BIC is allowed.
2.26 [0..1] ++ Ultimate Debtor Usage Rule: Mandatory, if provided by the Debtor
in the Mandate.
2.26 [0..1] +++ Name (AT-15 Name of the Debtor Reference Party) Usage
SEPAmailNorme1206–ÉditiondeJuin2015 Page256
Ref Mult Message Element SEPA/SEPAmail requirement
Rule : "Name" is limited to 70 characters in
length.
2.26 [0..1] +++ Postal Address
2.26 [0..1] +++ Identification (AT-37 Identification code of the Debtor Reference
Party)
2.26 {Or ++++ Organisation
Identification
Usage Rule: Either "BIC or BEI" or one occurrence
of "Other" is allowed.
2.26 Or} ++++ Private Identification Usage Rule : Either "Date and Place of Birth" or
one occurrence of "Other" is allowed.
2.26 [0..1] +++ Country of Residence
2.26 [0..1] +++ Contact Details
2.27 [0..1] ++ Referred Document
2.28 [0..1] +++ Type
2.33 [0..1] +++ Number (AT-08 Identifier of the underlying Contract)
2.34 [0..1] +++ Related Date
SEPAmailNorme1206–ÉditiondeJuin2015 Page257
Non‐ISOPart:AroundMandat
This part of the message adds information used by the SEPAmail/GEMME system, either for routing
purposes or to provide users with richer functionalities.
Ref Mult Message Element SEPAmail requirements
B1 [0..1] ++ SndMaxDT Latest validity date
B2 [1..1] ++ Status
Mandate status. Only values accepted are
“ACCP” (accepted : the mandate is validated, either through
SEPAmail or through some creditor-specific mechanism)
“PNDG” (pending : the mandate must still be validated through
SEPAmail)
B3 [1..1] ++ SignTp
Signature Type. Possible values are
“manual” : mandate has been signed by non-SEPAmail means
“sepamail” : mandate has been signed through SEPAmail.
B4 [0..1] ++ RtrPmt
Charge bearer. Possible values are “CRED” (creditor), “DEBT”
(debitor), “SHAR” (shared) and “SLEV” (depending on servce
level)
B5 [0..n] ++ Document Attached documents. The contract or other document may be
present for clarity.
B5.1 [1..1] +++ Type May be “mandate” (legal document) or “information” (other
document)
B5.2 [0..1] +++ Date Document date, ISO format
B5.3 [1..1] +++ Title Document title, max 200 characters
B5.4 [1..1] +++ Reference Document reference, max 100 characters
B5.5 [1..1] +++ Lang Mandatory, Language code for document language
B5.6 [0..1] +++ Contents
B5.6.1 [1..1] ++++ mime-type Mandatory
B5.6.2 [0..1] ++++ name document name, may or may not differ from the title above
B5.6.3 [1..1] ++++ data
actual contents of the document, may be anything depending on
MIME type. It can for example contain simply an URL where the
document is accessible.
B6 [1..1] ++ DbtrSignature Signature of debtor
B6.1 [1..1] +++ signature-
type
Type of signature, may be “handwritten”, “electronic” or
“other”
B6.2 [1..1] +++ data Actual signature, contents depending on the above type
B7 [0..1] ++ CdtrSignature
B7.1 [1..1] +++ signature-
type
Type of signature, may be “handwritten”, “electronic” or
“other”
B7.2 [1..1] +++ data Actual signature, contents depending on the above type
B8 [0..1] ++ CdtrLogo Creditor logo, will be displayed along with the mandate if
technically possible
B8.1 [1..1] +++ mime-type Mandatory
B8.2 [1..1] +++ data actual contents of the image, may be anything depending on MIME
type.
SEPAmailNorme1206–ÉditiondeJuin2015 Page258
B9 [0..1] ++ DbtFirstName First name of the debtor, used for validation
B10 [0..1] ++ DbtLastName Last name of the debtor, used for validation
B11 [0..1] ++
DbtLastNameType
Type of above last name. Can be “birthName”, “maritalName”
or “alias”. To be used only when known for sure.
SEPAmailNorme1206–ÉditiondeJuin2015 Page259
6.12. IGGemmeMandateAcceptanceReport These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail message used to indicate acceptance,
rejection or debtor-initiated modification of a mandate.
The full name of this message is sepamail_message_direct.debit_MandateAcceptanceReport.
This message must be generated and sent by the debtor's bank. The generating events can be, for
instance:
notification by the debtor of his acceptance of the mandate
notification by the debtor of his refusal of the mandate
request by the debtor for an account change, either within the same bank or to another
bank
This message is based upon ISO 10022 pain.012 schema. To allow additional features, it also
includes non-ISO parts. All message parts are described in this document.
MessageRoot
Mult Message Element SEPAmail requirement
[1..1] + DirectDebitMandateAcceptance
ISOandNon‐ISOparts
Ref Mult Message Element SEPAmail requirement
A [1..1] ++ Report MandateAcceptanceReportV01, as per ISO pain.012
B [0..1] ++ DSExt Non-ISO part, described further in this document
SEPAmailNorme1206–ÉditiondeJuin2015 Page260
ISOPart:MandateAcceptanceReportV01
Please note : this whole part is directly copied from "EPC002-09 e-mandate service IG 4.0 Approved" and is only provided here for ease of reference.
GroupHeader
The group header contains information required for the processing of the entire message.
Ref Mult Message Element SEPA/SEPAmail requirement
1.0 [1..1] + Group Header
1.1 [1..1] ++ Message Identification
1.2 [1..1] ++ Creation Date Time
1.3 [0..2] ++ Authorisation
1.4 {Or +++ Code
1.5 Or} +++ Proprietary (AT-60 – The reference of the validation made by
the Debtor Bank)
1.6 [0..1] ++ Initiating Party
1.7 [0..1] ++ Instructing Agent
1.8 [0..1] ++ Instructed Agent
UnderlyingAcceptanceDetails
Ref Mult Message Element SEPA/SEPAmail requirement
2.0 [1..1] + Underlying Acceptance
Details
2.1 [0..1] ++ Original Message
Information Mandatory
2.1 [1..1] +++ Message Identification The value MUST be taken from the Gemme
MandateInitiationRequest message (field 1.1)
2.1 [1..1] +++ Message Name
Identification
2.1 [0..1] +++ Creation Date Time
2.2 [1..1] ++ Acceptance Result
2.3 [1..1] +++ Accepted (AT-61 Result of the Debtor validation)
2.4 [0..1] +++ Reject Reason
2.5 {Or ++++ Code See Message Element Specifications below.
2.6 Or} ++++ Proprietary
2.7 [0..n] +++ Additional Reject Reason
Information
2.8 [1..1] ++ Original Mandate
2.9 {Or +++ Original Mandate
Identification
2.10 Or} +++ Original Mandate
2.11 [1..1] ++++ Mandate Identification
(AT-01 Unique Mandate Reference) Usage Rule: If no
"Mandate Identification" is available at the time
that the acceptance/validation report is sent,
SEPAmailNorme1206–ÉditiondeJuin2015 Page261
Ref Mult Message Element SEPA/SEPAmail requirement
"Mandate Identification" is to be populated with
the text "NOTPROVIDED".
2.12 [0..1] ++++ Mandate Request
Identification
2.13 [0..1] ++++ Type
2.14 [0..1] +++++ Service Level Mandatory
2.15 {Or ++++++ Code (AT-20 Identification code of the Scheme) Usage
Rule : Only "SEPA" is allowed.
2.16 Or} ++++++ Proprietary
2.17 [0..1] +++++ Local Instrument Mandatory
2.18 {Or ++++++ Code
(AT-20 The identification code of the Scheme)
Allowed values are
CORE: SDD CORE mandate
B2B: SDD B2B mandate
empty: direct debit
2.19 Or} ++++++ Proprietary
2.20 [0..1] ++++ Occurrences Mandatory
2.21 [1..1] +++++ Sequence Type (AT-21 Transaction type (recurrent, one-off)
2.22 [0..1] +++++ Frequency
2.23 [0..1] +++++ Duration
2.24 [0..1] +++++ First Collection Date
2.25 [0..1] +++++ Final Collection Date
2.26 [0..1] ++++ Collection Amount
2.27 [0..1] ++++ Maximum Amount
2.28 [0..1] ++++ Creditor Scheme
Identification Mandatory
2.28 [0..1] +++++ Name
2.28 [0..1] +++++ Postal Address
2.28 [0..1] +++++ Identification Mandatory (AT-02 Identifier of the Creditor)
2.28 {Or ++++++ Organisation
Identification
2.28 Or} ++++++ Private Identification
Usage Rule: Private Identification is used to
identify either an organisation or a private
person. Usage Rule : "Scheme Name" under "Other"
must specify "SEPA" under "Code". Usage Rule :
"Identification" under "Other" must be used with
an identifier described in General Message Element
Specifications, Chapter 1.5.2. Usage Rule : Only
one occurrence of "Other" is allowed.
2.28 [0..1] +++++ Country of Residence
2.28 [0..1] +++++ Contact Details
2.29 [1..1] ++++ Creditor
SEPAmailNorme1206–ÉditiondeJuin2015 Page262
Ref Mult Message Element SEPA/SEPAmail requirement
2.29 [0..1] +++++ Name
Mandatory (AT-03 Name of the Creditor) Usage
Rule : "Name" is limited to 70 characters in
length.
2.29 [0..1] +++++ Postal Address Mandatory (AT-05 Address of the Creditor)
2.29 [0..1] ++++++ Address Type
2.29 [0..1] ++++++ Department
2.29 [0..1] ++++++ Sub Department
2.29 [0..1] ++++++ Street Name
2.29 [0..1] ++++++ Building Number
2.29 [0..1] +++++ Post Code
2.29 [0..1] ++++++ Town Name
2.29 [0..1] ++++++ Country Sub Division
2.29 [0..1] ++++++ Country
2.29 [0..7] ++++++ Address Line Mandatory Usage Rule : Only two occurrences are
allowed.
2.29 [0..1] +++++ Identification
2.29 [0..1] +++++ Country of Residence
2.29 [0..1] +++++ Contact Details
2.30 [0..1] ++++ Creditor Account
2.31 [0..1] ++++ Creditor Agent
2.32 [0..1] ++++ Ultimate Creditor
2.32 [0..1] +++++ Name
(AT-38 Name of the Creditor Reference Party) Usage
Rule : "Name" is limited to 70 characters in
length.
2.32 [0..1] +++++ Postal Address
2.32 [0..1] +++++ Identification (AT-39 Identification code of the Creditor
Reference Party)
2.32 {Or ++++++ Organisation
Identification
Usage Rule : Either "BIC or BEI" or one occurrence
of "Other" is allowed.
2.32 Or} ++++++ Private Identification Usage Rule : Either "Date and Place of Birth" or
one occurrence of "Other" is allowed.
2.32 [0..1] +++++ Country of Residence
2.32 [0..1] +++++ Contact Details
2.33 [1..1] ++++ Debtor
2.33 [0..1] +++++ Name Mandatory (AT-14 Name of the Debtor) Usage Rule :
"Name" is limited to 70 characters in length.
2.33 [0..1] +++++ Postal Address Mandatory (AT-09 Address of the Debtor)
2.33 [0..1] ++++++ Address Type
2.33 [0..1] ++++++ Department
2.33 [0..1] ++++++ Sub Department
SEPAmailNorme1206–ÉditiondeJuin2015 Page263
Ref Mult Message Element SEPA/SEPAmail requirement
2.33 [0..1] ++++++ Street Name
2.33 [0..1] ++++++ Building Number
2.33 [0..1] ++++++ Post Code
2.33 [0..1] ++++++ Town Name
2.33 [0..1] ++++++ Country Subdivision
2.33 [0..1] ++++++ Country
2.33 [0..7] ++++++ Address Line Mandatory Usage Rule : Only two occurrences are
allowed.
2.33 [0..1] +++++ Identification (AT-27 Debtor identification code)
2.33 {Or ++++++ Organisation
Identification
Usage Rule : Either "BIC or BEI" or one occurrence
of "Other" is allowed.
2.33 Or} ++++++ Private Identification Usage Rule : Either "Date and Place of Birth" or
one occurrence of "Other" is allowed.
2.33 [0..1] +++++ Country of Residence
2.33 [0..1] +++++ Contact Details
2.34 [1..1] ++++ Debtor Account (AT-07 Account Number of the Debtor) Usage Rule :
Only IBAN is allowed.
2.35 [1..1] ++++ Debtor Agent (AT-13 BIC of the Debtor Bank) Usage Rule: Only
BIC is allowed.
2.36 [0..1] ++++ Ultimate Debtor
2.36 [0..1] +++++ Name
(AT-15 Name of the Debtor Reference Party) Usage
Rule : "Name" is limited to 70 characters in
length.
2.36 [0..1] +++++ Postal Address
2.36 [0..1] +++++ Identification (AT-37 Identification code of the Debtor Reference
Party)
2.36 {Or ++++++ Organisation
Identification
Usage Rule : Either "BIC or BEI" or one occurrence
of "Other" is allowed.
2.36 Or} ++++++ Private Identification Usage Rule : Either "Date and Place of Birth" or
one occurrence of "Other" is allowed.
2.36 [0..1] +++++ Country of Residence
2.36 [0..1] +++++ Contact Details
2.37 [0..1] ++++ Referred Document
2.38 [0..1] +++ Type
2.43 [0..1] +++ Number (AT-08 Identifier of the underlying Contract)
2.44 [0..1] +++ Related Date
Non‐ISOPart:AroundAcceptance
This part of the message adds information used by the SEPAmail/GEMME system, either for routing
purposes or to provide users with richer functionalities.
In the current version, they are only used when the debtor wishes to alter the bank account to
which the mandate is related.
SEPAmailNorme1206–ÉditiondeJuin2015 Page264
Ref Mult Message Element SEPAmail requirement
B1 [0..1] ++ BIC Mandatory when the mesage is used for an account change
B2 [0..1] ++ IBAN Mandatory when the mesage is used for an account change
SEPAmailNorme1206–ÉditiondeJuin2015 Page265
6.13. IGGemmePrenotification These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail message used to notify a debtor of one or
several payments.
The full name of this message is sepamail_message_direct.debit_Prenotification.
This message must be generated and sent by the creditor, via its bank. The reply, if any, is
also done through a Gemme MandateInitiationRequest message. The actual use of this message is
left to the discretion of the creditor, and depends on its relations with its debtors. It could
for instance be used in such cases :
initial notification, after mandate acceptance, of the full (or annual) schedule for
payments
annual schedule of payments, every year
advance notification for each single payment
acceptance or rejection of each payment by the debtor
This message is not based upon any existing ISO schema, since no such message exists in their
model. Thus, it only includes a non-ISO part, described here.
Please note that this message will be separated into a request message and a report message in
the next version of the SEPAmail standard, to conform to the general SEPAmail organization.
Messageroot
Mult Message Element SEPAmail requirement
[1..1] DirectDebitPrenotif
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
Mult Message Element SEPAmail requirement
[1..1] sepamail_message_direct_debit_prenotif_001 First version of the structure
MessageBody
Ref Mult Message Element SEPAmail requirement
A [1..1] ++ GrpHdr
B [1..1] ++ Notif
GroupHeader
The group header contains information related to the message itself.
Ref Mult Message Element SEPAmail requirement
SEPAmailNorme1206–ÉditiondeJuin2015 Page266
A1 [1..1] +++ MsgId
Identifier of the request, may be any string. However, when this
message is used as an answer to a request, this field must be
set to the same identifier as the request.
A2 [1..1] +++ CreDtTm Mandatory: Creation date and time, ISO format
A3 [0..1] +++ NbOfTxs Number of transactions described, defaults to 1
A4 [1..1] +++ Grpg
Grouping. Accepted values are
*GRPD grouped
*MIXD mixed
*SNGL single
Prenotification
This part of the message actually describes the payments that will take place, as well as the
related mandate.
Ref Mult Message Element SEPAmail requirement
B1 [1..1] +++ PntId
Payment Identification. This is freely usable by the creditor,
but it is strongly recommended that payment Ids should be
unique for a given mandate.
B2 [1..1] +++ MndtId
Mandate Identification. This must be the same identifier given
upon mandate creation (see Gemme MandateInitiationRequest
message)
B3 [1..1] +++ CtrRef Creditor Reference. Internal reference the creditor associates
with the mandate, or the payment schedule described here
B4 [1..1] +++ Cdtr
B4.1 [0..1] ++++ Nm Mandatory
B4.2 [0..1] ++++ PstlAdr
B4.3 [0..1] ++++ Id
B4.3.1 {Or +++++ OrgId
B4.3.2 Or} +++++ PrvtId
B4.4 [0..1] ++++ CtryOfRes
B4.5 [0..1] ++++ CtctDtls
B5 [0..1] +++ CdtrAcct
B6 [0..1] +++ CdtrAgt
B7 [0..1] +++ UltmtCdtr
B8 [1..1] +++ Dbtr
B8.1 [0..1] ++++ Nm Mandatory
B8.2 [0..1] ++++ PstlAdr
B8.3 [0..1] ++++ Id
B8.3.1 {Or +++++ OrgId
B8.3.2 Or} +++++ PrvtId
B8.4 [0..1] ++++ CtryOfRes
B8.5 [0..1] ++++ CtctDtls
B9 [0..1] +++ DbtrAcct
SEPAmailNorme1206–ÉditiondeJuin2015 Page267
Ref Mult Message Element SEPAmail requirement
B9.1 [1..1] ++++ Id
B9.1.1 {Or +++++ IBAN Mandatory
B9.1.2 Or} +++++ Other
B9.2 [0..1] ++++ Tp
B9.3 [0..1] ++++ Ccy
B9.4 [0..1] ++++ Nm
B10 [0..1] +++ DbtrAgt
B10.1 [1..1] ++++ FinInstnId
B10.1.1 [0..1] +++++ BIC Mandatory
B10.1.2 [0..1] +++++ ClrSysMmbId
B10.1.3 [0..1] +++++ Nm
B10.1.4 [0..1] +++++ PstlAdr
B10.1.5 [0..1] +++++ Other
B11 [1..1] +++ Trans
B11.1 [1..n] ++++ Trs As many such elements as indicated in the NbOfTxs element.
B11.1.1 [1..1] +++++ TrsDate ISO format
B11.1.2 [1..1] +++++ TrsAmt Mandatory. Usage rule: Currency attribute must be set to
"EUR".
B11.1.3 [0..1] +++++ TrsId Mandatory to allow matching between request and reply
B11.1.4 [0..1] +++++ Accepted Mandatory in the reply message
SEPAmailNorme1206–ÉditiondeJuin2015 Page268
6.14. IGGemmeRequestForCopy These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail message used by a debtor -- or his bank --
to request from the creditor a copy of the mandate associated with a given transaction.
The full name of this message is sepamail_message_direct.debit_RequestForCopy.
This message should be generated and sent by the debtor's bank, possibly following a direct
request from the debtor him/herself.
The message must be answered by the creditor with another “Request for Copy” message, with
the same request identifier, and giving all required information and all necessary legal proof
(copy of the contract, or digital signature evidence, as the case may be)
This message is derived from ISO schemas, but is not an actual extension of an existing ISO
message. Thus, it only includes a non-ISO part, described here.
Please note that this message will be separated into a request message and a report message in
the next version of the SEPAmail standard, to conform to the general SEPAmail organization.
Messageroot
Mult Message Element SEPAmail requirement
[1..1] DirectDebitRFCopy
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
The actual contents of the DirectDebitRFCopy element must be any one of the following
structures.
Mult Message Element SEPAmail requirement
[1..1] sepamail_message_direct_debit_request_for_copy_001 First version of the structure
GroupHeader
The group header contains information related to the message itself.
Ref Mult Message Element SEPAmail requirement
A [1..1] ++ GrpHdr
A1 [1..1] +++ RequestId
Identifier of the request, may be any string. However, when this
message is used as an answer to a request, this field must be
set to the same identifier as the request.
A2 [1..1] +++ CreDtTm Mandatory: Creation date and time, ISO format
Request
This part of the message actually describes the transaction upon which the request is based --
or at least the actors of this transaction.
SEPAmailNorme1206–ÉditiondeJuin2015 Page269
Ref Mult Message Element SEPAmail requirement
B [1..1] ++ Request
B1 [1..1] +++ CustRef
Customer Reference. Internal reference the creditor associates
with the debtor, mandate, or the payment schedule described
here
B2 [1..1] +++ Cdtr
B2.1 [0..1] ++++ Nm Mandatory
B2.2 [0..1] ++++ PstlAdr
B2.3 [0..1] ++++ Id
B2.3.1 {Or +++++ OrgId
B2.3.2 Or} +++++ PrvtId
B2.4 [0..1] ++++ CtryOfRes
B2.5 [0..1] ++++ CtctDtls
B3 [0..1] +++ CdtrAcct IBAN of creditor
B4 [0..1] +++ CdtrAgt BIC of creditor
B5 [0..1] +++ UltmtCdtr Used when there is an intermediate creditor, acting for an
ultimate creditor
B6 [1..1] +++ Dbtr
B6.1 [0..1] ++++ Nm Mandatory
B6.2 [0..1] ++++ PstlAdr
B6.3 [0..1] ++++ Id
B6.3.1 {Or +++++ OrgId
B6.3.2 Or} +++++ PrvtId
B6.4 [0..1] ++++ CtryOfRes
B6.5 [0..1] ++++ CtctDtls
B7 [0..1] +++ DbtrAcct
B7.1 [1..1] ++++ Id
B7.1.1 {Or +++++ IBAN Mandatory
B7.1.2 Or} +++++ Other
B7.2 [0..1] ++++ Tp
B7.3 [0..1] ++++ Ccy
B7.4 [0..1] ++++ Nm
B8 [0..1] +++ DbtrAgt
B8.1 [1..1] ++++ FinInstnId
B8.1.1 [0..1] +++++ BIC Mandatory
B8.1.2 [0..1] +++++ ClrSysMmbId
B8.1.3 [0..1] +++++ Nm
B8.1.4 [0..1] +++++ PstlAdr
B8.1.5 [0..1] +++++ Other
B9 [1..1] +++ Trans
SEPAmailNorme1206–ÉditiondeJuin2015 Page270
Ref Mult Message Element SEPAmail requirement
B9.1 [1..1] ++++ TrsDate Mandatory, ISO format
B9.2 [1..1] ++++ TrsAmt Mandatory. Usage rule: Currency attribute must be set to
"EUR".
B9.3 [0..1] ++++ TrsId Optional. Must be present only if known for sure -- this
reference must come from a Gemme Prenotification message.
B9.4 [0..1] ++++ Accepted MUST be omitted in this message
B10 [0..1] +++ Mandate Any type of document or URL giving access to the original
mandate. This field is mandatory only in the answer message.
SEPAmailNorme1206–ÉditiondeJuin2015 Page271
7. L'applicationDIAMOND
SEPAmailNorme1206–ÉditiondeJuin2015 Page272
7.1. DIAMONDDIAMOND est une application SEPAmail.
Son sigle est DIAMOND@SEPAmail.
DIAMOND est l'acronyme de Direct Identity control for Account Management ON Demand.
L'application permet de fiabiliser les coordonnées bancaires données par un titulaire de compte
à un donneur d'ordre de virement ou de prélèvement dans le cadre du processus de domiciliation.
Pour mémoire, le processus de domiciliation consiste, pour un titulaire de compte, à fournir
ses coordonnées bancaires. L’établissement teneur du compte offre pour cela la possibilité de
visualiser et d’obtenir l’impression de ces coordonnées sur différents supports (via la
Banque en ligne, via son chéquier, …). Ces coordonnées contiennent en général le nom, le
prénom, l’IBAN et le BIC.
SEPAmailNorme1206–ÉditiondeJuin2015 Page273
7.2. Lesprincipesgénéraux(DIAMOND)Lesacteurs
DIAMOND est une application SEPAmail permettant de contrôler la fiabilité de coordonnées
bancaires données par un titulaire de compte à un donneur d'ordre de virement ou de prélèvement
(processus de domiciliation). Elle met en scène quatre acteurs :
Le titulaire du compte dont on cherche à vérifier la domiciliation,
Le Prestataire de Services de Paiement (PSP) teneur du compte de ce titulaire,
Le donneur d’ordre du paiement qui désire effectuer la vérification de la
domiciliation,
Le PSP teneur du compte de ce donneur d’ordre
L'application
L'application DIAMOND a pour objet de détecter les erreurs de saisie, les falsifications de
relevés d'identité bancaire et de maintenir la fiabilité des données gérées par les donneurs
d'ordre de paiement. DIAMOND permet ainsi d’éviter des rejets ou des mauvaises imputations
lorsque les paiements sont émis sur des données erronées.
Lecontexted’utilisation
Ce service s'adresse aux donneurs d’ordre, sous réserve qu’ils soient détenteurs d’un ICQX
valide. Ces donneurs d’ordre agissent soit en tant que créanciers (contrôle des coordonnées
bancaires du débiteur avant émission d'un prélèvement) soit en tant que débiteurs (contrôle des
coordonnées bancaires du bénéficiaire avant émission d'un virement).
L'utilisation de l'application DIAMOND est modulable à la main du donneur d’ordre en fonction
des champs qu’il renseigne dans sa demande, dans la limite des critères prévus par
l'algorithme communautaire de fiabilisation. La réponse qu’il recevra dépend toutefois des
choix effectifs du PSP teneur du compte du titulaire dans sa mise en œuvre de l'algorithme
communautaire.
Comme pour toute application SEPAmail, le donneur d’ordre peut préciser l'urgence à obtenir
une réponse au travers de la balise <MsvPri> (Missive Priority) de la missive SEPAmail.
L'application DIAMOND est d'une utilisation totalement autonome par rapport aux autres
applications SEPAmail. Par exemple, un contrôle de coordonnées bancaires peut être réalisé au
travers de DIAMOND, en préalable à la mise en place d'un mandat de prélèvement réalisée, quant
à elle, au travers de GEMME.
SEPAmailNorme1206–ÉditiondeJuin2015 Page274
7.3. Casd'usage(DIAMOND)DIAMOND doit permettre notamment :
De détecter une erreur de saisie, par vérification de conformité de la structure de
l’IBAN
De détecter si l’IBAN existe vraiment, s’il correspond à un compte ouvert
De vérifier si l’IBAN correspond bien au Titulaire présumé du compte
De vérifier, au moment de la demande, si le type de compte associé à l’IBAN est
compatible avec l’ordre de paiement futur, c’est-à-dire suivant le cas :
1. Un virement sur ce type de compte est-il possible ?
2. Un prélèvement sur ce type de compte est-il possible ?
SEPAmailNorme1206–ÉditiondeJuin2015 Page275
7.4. Gestiondesflux(DIAMOND)Schémadesflux
(*) Le Titulaire du compte dispose d’un droit d’accès, de rectification et d’opposition
auprès du donneur d’ordre et auprès de son PSP des données traitées respectivement par chacun
d’entre eux dans le cadre de DIAMOND conformément à la loi N°78-17 modifiée du 6 janvier 1978
relative à l’informatique, aux fichiers et aux libertés.
Descriptiondétaillée
1. Le titulaire du compte fournit ses coordonnées bancaires à un donneur d’ordre en vue
d’une opération de virement ou de prélèvement
2. Le donneur d’ordre transmet à son PSP (selon une forme convenue entre eux) les
coordonnées bancaires du titulaire du compte à vérifier
3. Le PSP tenant le compte du donneur d’ordre transmet le message de demande de
vérification des coordonnées bancaires au PSP tenant le compte du titulaire
4. Le PSP tenant le compte du titulaire vérifie, au travers de l’algorithme communautaire,
les données de la demande reçue par rapport à ses propres données. Il transmet alors au
PSP tenant le compte du donneur d’ordre le message de réponse à la demande de
vérification.
5. Le PSP tenant le compte du donneur d’ordre transmet cette réponse au donneur d’ordre
selon une forme convenue entre eux.
SEPAmailNorme1206–ÉditiondeJuin2015 Page276
7.5. Lesrèglesmétier(DIAMOND)Objetdudocument
Ce document décrit le mécanisme global du système SEPAmail de demande de vérification de
coordonnées bancaires.
Il est destiné à des interlocuteurs fonctionnels, les éléments techniques figurant dans les
directives correspondantes (implementation guidelines).
Présentationgénérale
DIAMOND vise à établir un ensemble de règles et d'outils permettant de gérer des demandes de
vérification de coordonnées bancaires:
création des demandes de vérification par le donneur d'ordre
application de l'algorithme communautaire de contrôle de coordonnées bancaire
création des réponses aux demandes de vérification par le Prestataire de Services de
Paiement (PSP) teneur du compte du titulaire
MessagesdelafamilleDIAMOND
DIAMOND est l'application SEPAmail utilisant l'écosystème identification.verification.
Dans cet écosystème, deux messages ont été définis à ce jour :
VerificationRequest : message de demande de vérification
VerificationReport : message de réponse à une demande de vérification
Lemessagededemandedevérification
Ce message est utilisé, à l'initiative d'un utilisateur SEPAmail (le donneur d'ordre), pour
demander la vérification de coordonnées bancaires du titulaire.
Le message est fondé sur le message acmt.023.001.01 de la norme ISO 20022,
IdentificationVerificationRequestV01, auquel sont ajoutées des informations spécifiques à
DIAMOND.
Le donneur d'ordre maîtrise par les champs qu'il complète dans son message de demande les
critères qu'il souhaite voir contrôler par le PSP teneur du compte (sous réserve de l'offre
effective de ce PSP sur la totalité des critères de l'algorithme communautaire).
Lemessagederéponseàdemandedevérification
Ce message est utilisé, à l'initiative du PSP teneur du compte du titulaire, pour répondre à la
demande de vérification de coordonnées bancaires qu'il a reçue.
Le message est fondé sur le message acmt.024.001.01 de la norme ISO 20022,
IdentificationVerificationReportV01, auquel sont ajoutées des informations spécifiques à
DIAMOND.
Dans le message de réponse, le résultat est fourni par:
un indicateur de réponse global valorisé à TRUE ou FALSE:
1. TRUE lorsque tous les champs soumis sont intégralement corrects, c'est-à-dire qu'ils sont vrais dans le cas des contrôles élémentaires, égaux à la note la plus
élevée dans le cas des calculs de note de pertinence et que le dernier champ testé
par l'algorithme avant la détermination de l'indicateur de réponse global
n'aboutit pas à un résultat "test impossible"
2. FALSE dans tous les autres cas avec nécessité de lire les codes raisons en complément.
SEPAmailNorme1206–ÉditiondeJuin2015 Page277
un code raison par donnée testée construit sur 5 positions (fourni dans la partie non
ISO) indiquant:
1. en positions 1 et 2 : le n° du contrôle effectué
1. 01 IBAN
2. 02 customer type
3. 03 SIREN
4. 04 SIRET
5. 05 TVA intracomm
6. 06 birth date
7. 07 birth city
8. 08 birth country
9. 09 name
10. 10 other_name
11. 11 idcard / pass
2. en positions 3, 4 et 5 : le résultat obtenu sur ce contrôle
1. Ce résultat est, en fonction des contrôles, soit une note de pertinence, comprise entre 0 et 400, pour les contrôles nécessitant une réponse nuancée (contrôles 09
et 10), soit un indice pour les contrôles plus élémentaires (contrôles autres que
09 et 10) avec les valeurs suivantes :
1. 000 FAUX
2. 001 VRAI
3. 002 FAUX sur une donnée de repli
4. 003 VRAI sur une donnée de repli
5. 020 contrôle impossible
Il est restitué au donneur d'ordre autant de codes raison par IBAN que de données effectivement
testées. En revanche, compte tenu de la dépendance de certains tests entre eux, toutes les
données fournies pour contrôle ne seront pas obligatoirement testées, conformément à
l'algorithme ci-dessous.
La liste exhaustive des codes retours est décrite dans le guide d'implémentation.
L'algorithmecommunautairedefiabilisation
Contexted'utilisation
L'algorithme permet de fiabiliser les coordonnées bancaires du titulaire du compte dont l'IBAN
est fourni. Il compare les données fournies par le donneur d’ordre et celles dont le PSP
teneur du compte du titulaire de compte dispose. Le donneur d’ordre doit donc prendre en
compte les contraintes suivantes :
SEPAmailNorme1206–ÉditiondeJuin2015 Page278
les données bancaires sont généralement basées sur les pièces d'identité, et de ce fait,
il est préférable pour le donneur d’ordre d'utiliser lui aussi des données venant de
pièces d'identité
en aucun cas le PSP teneur du compte du titulaire ne communiquera les éléments
d'identification du compte dont il dispose (nom, date/lieu de naissance, SIREN..etc..)
il est à la charge du donneur d’ordre de transmettre les éléments liés aux seules
coordonnées bancaires de domiciliation et non les coordonnées commerciales.
Si le donneur d’ordre dispose, pour le titulaire, d’un relevé d'identité bancaire sécurisé,
par 2D-DOC par exemple, l'utilisation de l'algorithme permettra essentiellement le contrôle des
opérations autorisées sur le compte et le statut de ce compte (ouvert/fermé).
Cet algorithme prévoit par ailleurs des contrôles différents pour les particuliers et pour les
personnes morales.
Caractéristiquesdel'algorithme
Tous les adhérents SEPAmail utilisent le même algorithme pour avoir une cohérence vis-à-
vis des donneurs d’ordre. Néanmoins :
1. l'algorithme est susceptible d'évoluer
2. les adhérents ne seront pas à même de faire les migrations le même jour
Il en résulte que l'algorithme possède un numéro de version qui est véhiculé dans les messages
retour (partie non ISO).
Les données gérées par l'algorithme sont :
1. IBAN
2. type de titulaire
3. SIREN, SIRET, N° de TVA Intracommunautaire
4. N° d'une pièce d'identité et date de délivrance
5. noms
6. date, ville et pays de naissance
7. opérations autorisées sur le compte
Contenudel'algorithme
1èreétape,communeàtoustypesdetitulairesdecompte:ContrôleIBANvalideetexistant,comptenonsoldé
Le 1er contrôle vérifie que l’IBAN transmis est correctement constitué (MOD 97-10, cf.
ISO7604) et que le compte existe. Ce contrôle intègre le contrôle de compte soldé ou clôturé.
2èmeétape,communeàtoustypesdetitulairesdecompte:Contrôledutypedetitulaire
Le 2ème contrôle vérifie que le type de titulaire transmis (entreprise/pro ou particulier) est
identique à celui enregistré dans la base Tiers du PSP tenant le compte. Ce contrôle est
binaire. Il ne s'appuie pas directement sur une donnée "type de titulaire du compte" fournie
par le donneur d’ordre mais il vérifie le type transmis en fonction de la présence des index
OrganisationIdentification ou PrivateIdentification.
La présence de OrganisationIdentification est considérée comme un type de titulaire
'entreprise/professionnel/association'.
SEP
Ce t
Si a
3ème
Le 3
poss
de T
tena
En c
AmailNorm
La prés
'partic
type est c
aucun de c
e étape co
3ème contrôl
sèdent un
TVA Intrac
ant le com
cas de SIR
me1206–Éd
sence de Pr
culier'.
ontrôlé av
es 2 index
ncernant l
3èmpossSIRE
le, concer
SIREN, SIR
ommunautai
pte.
ET fourni
ditiondeJui
rivateIden
vec la base
x n'est pré
les particu
meétape,consèdentunSIEN/SIRETou
nant les e
RET ou N°
ire transmi
et résulta
in2015
tification
e Tiers du
ésent, l'al
uliers - so
ncernantlesIREN,SIRETuN°deTVA
entreprises
de TVA Int
is est iden
at KO, un c
n est consi
PSP tenan
lgorithme
ous-étape B
sentreprisesTouN°deTVAIntracomm
s, professi
tracommunau
ntique à c
contrôle d
idérée comm
t le compt
se poursui
B.
s,professionVAIntracommunautaire
ionnels et
utaire, vé
elui enreg
e repli su
me un type
e.
t par une
nnelsetassommunautair
associati
rifie que
istré dans
r le SIREN
de titula
étape équi
ociationsqure:Contrôle
ons quand
le SIREN,
s la base T
N est effec
Page
aire
ivalente à
uandellesdu
elles
SIRET ou N
Tiers du PS
ctué.
e279
la
N°
SP
SEP
Conc
cont
(L'I
(pas
Ce c
PSP
du c
date
caté
Sur
AmailNorm
cernant le
trôle incl
le type
le n°
la date
présenc
obligat
IG du mess
ss_number;
contrôle e
sur les p
compte en
e- la date
égorie 11)
ce contrô
Le code
donneur
le comp
Le code
d’ordr
compte,
Le code
est imp
me1206–Éd
3èmd'ide
s particul
ut:
e de la piè
de la pièc
e de délivr
ce renforce
toire)
age Verifi
pass_date
ffectué su
ièces d'id
cas de com
pouvant ê
et un seu
le:
e résultat
r d’ordre
pte, pour c
e résultat
re ne corre
pour ce c
e résultat
possible pa
ditiondeJui
meétape,conentité
liers, le c
èce
ce
rance de l
e la fiabi
icationRequ
e) et la ca
ur le titul
dentité enr
mpte joint.
être non re
ul code sur
'VRAI' (0
correspon
ce compte.
'FAUX' (0
espond à l
compte.
020 est a
ar le PSP
in2015
ncernantles
contrôle de
a pièce (l
lité du co
uest prévoi
arte nation
laire princ
registrées
Le résult
enseignée)
r 5 positio
01) est at
d à un des
00) est at
'un des tr
ttribué si
teneur du
sparticulier
e fiabilit
la date de
ontrôle pou
it à ce jou
nale d'iden
cipal du c
dans sa b
tat du con
est rendu
ons.
ttribué si
s triplets
ttribué si
riplets pré
i aucun tri
compte.
s‐sous‐étap
é se fait
délivrance
ur le donne
ur ces don
ntité (idc
ompte doit
ase Tiers
trôle du o
sous une
au moins u
présents d
aucun des
ésents dans
iplet n'est
peA:Contrô
sur une pi
e peut être
eur d’ordr
nées pour
ard_number
également
pour l'ens
u des trip
et une seu
un des trip
dans la bas
triplets f
s la base T
t fourni ou
ôledel'une
ièce d'iden
e communiq
re mais n’
le passepo
r; idcard_d
t être effe
semble des
plet(s) (ty
ule catégor
plets four
se Tiers d
fournis pa
Tiers du P
u bien si
Page
despièces
ntité. Ce
quée; sa
est pas
ort
date)).
ectué par l
co-titula
ype; n°;
rie (la
rnis par le
du PSP tena
ar le donne
PSP tenant
le contrôl
e280
le
ires
e
ant
eur
le
le
SEPAmailNorme1206–ÉditiondeJuin2015 Page281
En cas de code 001 ou 000, l'étape 3 est terminée.
En cas de code 020, l'étape 3 se poursuit par un contrôle sur le nom du titulaire du
compte.
3èmeétape,concernantlesparticuliers‐sous‐étapeB:Contrôledesnoms
Algorithme spécifique de contrôle du nom Les données gérées par l'algorithme sont :
le nom
le prénom
un autre nom (qui inclut le cas du nom d'usage / nom marital)
le nom joint et le prénom joint (nom et prénom du co-titulaire du compte dans le cas
d'un compte joint)
L’algorithme suppose :
que les adhérents SEPAmail gèrent dans leur base Tiers des champs distincts pour la zone
NOM et la zone PRENOM (ceci s'appliquant au titulaire principal mais également aux
autres titulaires: champs distincts pour la zone AUTRE NOM, la zone NOM JOINT et la zone
PRENOM JOINT etc..).
que le donneur d’ordre envoie une zone unique (champ Name ISO 20 022) contenant le nom
et le prénom.
Le PSP tenant le compte du titulaire effectue successivement trois comparaisons pour chacune
desquelles il calcule une note de pertinence :
le champ Name ISO, ci-après dénommé champ CLIENT avec les champs NOM et PRENOM de sa
base Tiers
le champ CLIENT avec les champs AUTRE NOM et PRENOM de sa base Tiers
le champ CLIENT avec le NOM JOINT et PRENOM JOINT de sa base Tiers
Par souci d'optimisation, les comparaisons sont interrompues dès la note de pertinence maximale
obtenue.
SEP
Prin
Calc
Défi
Étap
1. N
AmailNorm
ncipes de l la note
la note
avec de
1.
2.
l'ordre
1.
2.
la note
résulta
la note
cul de la note d
nitions
Le cham
Le cham
Le cham
pes préalables
Normalisat
me1206–Éd
la note de e de pertin
e de pertin
es espaces
Le Goff do
de La Font
e des mots
Goffle ne
la fontain
e de pertin
at que DELA
e de pertin
de pertinence
mp CLIENT c
mp NOM corr
mp PRENOM c
au calcul
ion du cha
ditiondeJui
pertinencenence ne d
nence est
onne le mêm
taine donne
est impor
donne pas
ne de ne do
nence ne d
AFONTAINE
nence donn
sur les champ
correspond
respond au
correspond
amp CLIENT
in2015
e épend pas
identique
me résultat
e le même r
tant :
le même ré
onne pas le
épend pas
e le même
ps "NOM" et "
au champ
champ lu
au champ
du nombre
suivant qu
t que Lego
résultat q
ésultat qu
e même rés
de la cass
résultat l
"PRENOM" d
envoyé par
dans la ba
lu dans la
de mots ou
u'un nom co
off
ue delafon
e Legoff
ultat que
se des mots
lorsque le
de la base Tier
r le donneu
ase Tiers d
a base Tier
u de lettre
omposé soit
ntaine
delafontai
s : de La F
nom et le
rs
ur d’ordre
du PSP tena
rs du PSP t
es contrôl
t écrit to
ine
Fontaine d
prénom so
e.
ant le com
tenant le
Page
és
out attaché
donne le mê
ont inversé
mpte.
compte.
e282
é ou
ême
és
SEPAmailNorme1206–ÉditiondeJuin2015 Page283
1. le champ CLIENT est transformé en lettres CAPITALES non accentuées
2. le champ CLIENT doit être séparé en mots signifiants
1. un mot signifiant est une chaîne de caractères séparée par un caractère de ponctuation . { : / \ , ; - _ " " (espace)} ou tout autre caractère utilisé
pour mettre en évidence une séparation
2. Jean-françois.Le-Goff devient {JEAN ; FRANCOIS ; LE ; GOFF}
3. à l'issue de ce traitement le champ CLIENT devient une liste de mots signifiants que nous allons identifier sous forme CLIENTi (i variant de 1 à n), n étant le
nombre de mots trouvés dans le champ CLIENT
2. Concaténation du champ NOM
1. le champ NOM est transformé en lettres CAPITALES non accentuées
2. les caractères de ponctuation (les mêmes que ceux identifiés pour la normalisation du champ CLIENT) sont supprimés
3. LE GOFF devient LEGOFF
3. Concaténation du champ PRENOM
1. le champ PRENOM est transformé en lettres CAPITALES non accentuées
2. les caractères de ponctuation (les mêmes que ceux identifiés pour la normalisation du champ CLIENT) sont supprimés
3. Jean_Francois devient JEANFRANCOIS
Calcul de la note
La note de pertinence est mise à zéro en début de procédure
Chaque mot CLIENTi est comparé au champ NOM dans l'ordre croissant de l'index i
en cas de correspondance, le champ NOM (correspondance stricte) ou les lettres du champ
NOM (correspondance par inclusion) sont mis de côté
si l'ensemble des lettres du champ NOM a été mis de côté à la fin de la procédure (pour
i=n) alors la note de pertinence est augmentée de +200
si seulement une partie des lettres a été mise de côté, alors la note de pertinence est
augmentée au prorata : (nombre de lettres mises de côté)*200/(nombre de lettres totales
du champ NOM)
Ainsi, dans notre exemple,
1. JEAN (CLIENT1) est comparé à LEGOFF => +0
2. FRANCOIS (CLIENT2) est comparé à LEGOFF => +0
3. LE (CLIENT3) est comparé à LEGOFF => (les lettres LE sont mises de côté)
4. GOFF (CLIENT4) est comparé à GOFF => (les lettres GOFF sont mises de côté)
5. toutes les lettres du champ NOM (L E G O F F) ont été mises de côté => +200
SEPAmailNorme1206–ÉditiondeJuin2015 Page284
Chaque mot CLIENTi est comparé au champ PRENOM dans l'ordre croissant de l'index i
en cas de correspondance, le champ PRENOM (correspondance stricte) ou les lettres du
champ PRENOM (correspondance par inclusion) sont mis de côté
si l'ensemble des lettres du champ PRENOM a été mis de côté à la fin de la procédure
(pour i=n) alors la note de pertinence se voit augmentée de +200
si seulement une partie des lettres a été mise de côté, alors la note de pertinence est
augmentée au prorata : (nombre de lettres mises de côté)*200/(nombre de lettres totales
du champ PRENOM)
Ainsi, dans notre exemple,
1. JEAN (CLIENT1) est comparé à JEANFRANCOIS => (les lettres JEAN sont mises de côté)
2. FRANCOIS (CLIENT2) est comparé à FRANCOIS => (les lettres FRANCOIS sont mises de
côté)
3. LE (CLIENT3) est comparé à vide => +0
4. GOFF (CLIENT4) est comparé à vide => +0
5. toutes les lettres du champ PRENOM ont été mises de côté => +200
Pour chaque mot CLIENTi restant,
soustraire 50 de la note de pertinence
Ainsi, dans notre exemple,
1. tous les CLIENTi ont été utilisés donc aucune soustraction
2. la note de pertinence est alors égale à 400
Calcul de la note de pertinence sur les champs "AUTRE NOM" et "PRENOM" de la base Tiers
Les étapes préalables et l'algorithme décrits précédemment sont appliqués à l'identique en
remplaçant le champ NOM par le champ AUTRE NOM, mais en gardant le champ PRENOM original.
Une nouvelle note de pertinence est déterminée.
Calcul de la note de pertinence sur les champs "NOM JOINT" et "PRENOM JOINT" de la base Tiers
Les étapes préalables et l'algorithme décrits précédemment sont appliqués à l'identique en
remplaçant le champ NOM par le NOM JOINT et le PRENOM par le PRENOM JOINT. Une nouvelle note
de pertinence est déterminée.
Note retenue en cas de comparaison multiple
Selon les notes réellement calculées, le code de réponse fourni au donneur d’ordre sera le
maximum des notes des comparaisons respectives entre les champs (NOM, PRENOM), (AUTRE NOM,
PRENOM) et (NOM JOINT, PRENOM JOINT). Ce code est fourni sous la catégorie 09.
Extension de contrôle du nom en cas de champ supplémentaire complété par l'émetteur Lorsque le donneur d’ordre renseigne en complément du champ NOM, les champs Identification et
Issuer pour le type de donnée "other_name", les 3 types de comparaison précédemment identifiés
sont appliqués en remplaçant le CLIENT par la donnée présente sous "other_name" dénommée CLIENT
B.
SEPAmailNorme1206–ÉditiondeJuin2015 Page285
Une note de pertinence est calculée pour chacune des 3 comparaisons.
Le code de réponse fourni au donneur d’ordre sera le maximum des notes des comparaisons
respectives des champs (NOM, PRENOM), (AUTRE NOM, PRENOM) et (NOM JOINT, PRENOM JOINT).
Ce code est fourni sous la catégorie 10.
Impact des catégories 09 et 10 dans la détermination de l'indicateur de réponse global
Dans le cas où un code a été déterminé sous la catégorie 09 et sous la catégorie 10, le code
concourant à la détermination de l'indicateur de réponse globale est le maximum de la note
obtenue sous chaque catégorie.
3èmeétape,concernantlesparticuliers‐sous‐étapeC:contrôledeladateetlieudenaissance
Le contrôle du nom peut être complété par un contrôle sur:
la date de naissance
la ville de naissance
le pays de naissance
NB: l'utilisation de l'index ISO DateAndPlaceOfBirth dans le message VerificationRequest rend
obligatoire (schéma ISO) le renseignement des sous-index BirthDate, CityOfBirth et
CountryOfBirth. Chacun de ces 3 éléments correspond à une catégorie réponse (respectivement 06,
07 et 08).
Attention, ces données doivent être contrôlées par le PSP tenant le compte avec celles
attachées au nom pour lequel il a obtenu la note de pertinence maximale.
4èmeétape,communeàtoustypesdetitulaires:Contrôledesopérationsautoriséessurlecompte
Le 4ème contrôle vérifie que le n° de compte (IBAN) transmis est ouvert aux opérations
mentionnées par l'émetteur dans sa requête (partie NON ISO):
virements reçus (crédit du compte objet du contrôle IBAN)
virements émis (débit du compte objet du contrôle IBAN)
demandes de paiement RUBIS (débit du compte objet du contrôle IBAN)
prélèvements / SDD (débit du compte objet du contrôle IBAN)
prélèvements / SDD retour (crédit du compte objet du contrôle IBAN)
crédits : virements reçus et retour de prélèvement
débits : virements émis, présentation de pied de factures et prélèvements/SDD
débits et crédits
Il existe un contrôle par catégorie d'opération mentionnée par le donneur d’ordre dans sa
requête. Attention, ces contrôles ne concourent pas à la détermination de l'indicateur de
réponse global et n'aboutissent pas à un code raison sur 5 positions à la différence des autres
contrôles de l'algorithme. Chaque contrôle effectué sur une catégorie d'opération fait l'objet
d'une réponse spécifique true/false dans la partie non ISO du Report.
SEPAmailNorme1206–ÉditiondeJuin2015 Page286
7.6. Lerécapitulatifdesmessages(DIAMOND)Voici les messages possibles pour DIAMOND :
message SEPAmail “Demande de Vérification”
message SEPAmail “Réponse à Demande de Vérification”
SEPAmailNorme1206–ÉditiondeJuin2015 Page287
7.7. Lesaspectsjuridiques(DIAMOND)Relationscontractuellesentrelesdifférentsacteursdusystème
LarelationentreletitulaireducompteetsonPSP
Sur un plan contractuel, le PSP du titulaire du compte devra adapter la convention de compte
pour expliquer que DIAMOND fait désormais intégralement partie de la tenue de compte :
Le Titulaire du compte sera ainsi informé que le traitement de ses données personnelles
se voit affecter une finalité supplémentaire: la fiabilisation des coordonnées bancaires
Le Titulaire du compte consentira de la sorte à la levée du secret professionnel afin
que son PSP puisse répondre aux demandes qui lui sont adressées
En complément, le titulaire du compte pourra obtenir des informations sur le détail du
fonctionnement, en particulier :
le détail des traitements est conforme à la norme "fiabilisation des coordonnées
bancaires avec SEPAmail"
les résultats de ces traitements ne sont accessibles qu'à des donneurs d'ordre dûment
authentifiés grâce aux fonctionnalités de la messagerie SEPAmail, ayant signé un contrat
de service avec un PSP participant au système. En particulier, ce contrat oblige le
donneur d'ordre à n'effectuer que des contrôles sur les coordonnées bancaires fournies
au préalable par le titulaire en vue d’une future opération de paiement.
le titulaire peut demander le résultat des traitements effectués sur son compte auprès
de son PSP suivant une procédure définie par le PSP (La liste des messages reçus avec
les données répondues, suffit à l’information du client).
La modification des conventions de compte pourra se faire dans les conditions prévues aux
articles L 312-1-1 ou L. 314-13 du Code monétaire et financier. Pour la mise en place du
service :
s’agissant des nouveaux clients, le client signera une convention modifiée,
s’agissant des anciens clients, le titulaire du compte acceptera la modification de la
convention par voie d’acceptation tacite, après expiration d’un délai de préavis.
Par ailleurs, les PSP effectueront une déclaration auprès de la CNIL pour la mise en œuvre du
traitement DIAMOND (algorithme et conservation des données pour preuve).
Larelationentreledonneurd’ordreetsonPSP
Le PSP tenant le compte du donneur d’ordre, en plus de son rôle d’acquisition et
d’authentification des flux, doit faire signer un contrat (le cas échéant spécifique) à son
client. Le donneur d’ordre, en échange de la possibilité de faire des transactions DIAMOND,
doit s’engager sur les principes suivants :
Avoir un ICQX demandé auprès de SEPAmail.eu, permettant au PSP du titulaire de
consolider les demandes qui lui seront envoyées (En effet, la seule consolidation sur
l’IBAN du donneur d’ordre ne permet pas d’indiquer clairement et sans ambiguïté au
titulaire qui a réalisé une demande de fiabilisation),
N’effectuer des contrôles que sur des coordonnées bancaires fournies au préalable et
directement par des titulaires de compte,
SEPAmailNorme1206–ÉditiondeJuin2015 Page288
Avoir bien compris les limites du système, en particulier les incertitudes concernant le
traitement algorithmique du nom et du prénom du titulaire,
Respecter la législation en vigueur sur le traitement des données à caractère personnel
(notamment quant aux formalités préalables),
Effectuer ces contrôles uniquement pour son propre compte ou le compte d’entités
l’ayant dûment mandaté à cet effet (L’ICQX présent dans le message DIAMOND doit
appartenir à l’entité qui demande effectivement ce contrôle, entité responsable en cas
d’abus de contrôle),
Mettre en place l’organisation nécessaire pour que son système ne soit pas détourné ou
utilisé à son insu pour réaliser des transactions DIAMOND hors de son objet initial.
Larelationentreledonneurd’ordreetletitulaireducompte
Si les règles régissant les relations entre ces deux acteurs ne relèvent pas de la compétence
des PSP adhérents de SEPAMAIL, les donneurs d’ordre seront tenus de remplir les formalités
nécessaires auprès de la CNIL pour mettre en place les traitements associés au service DIAMOND.
LesrelationsentrelesPSPdéfiniesauseindeSEPAmail.eu
Les relations entre les PSP sont définies dans le cadre du respect de la norme et des règles
opérationnelles formalisées dans le contrat d’adhésion.
SEPAMAIL.EU enregistre et maintient le référentiel des entités « donneurs d’ordres » pouvant
effectuer des transactions DIAMOND.
SEPAmailNorme1206–ÉditiondeJuin2015 Page289
7.8. IGidentification.verificationL'écosystème identification.verification comporte deux messages :
Nom Directives d'implémentation Schéma
VerificationReport Standards:IG_Diamond_VerificationReport Schéma
VerificationRequest Standards:IG_Diamond_VerificationRequestSchéma
SEPAmailNorme1206–ÉditiondeJuin2015 Page290
7.9. IGDiamondVerificationRequest
These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail/DIAMOND message used to request
verification of an identity.
The full name of this message is
sepamail_message_identification.verification_IdentificationVerificationRequest.
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
The actual contents of the VerificationRequest element must be any one of the
sepamail_verification_request_xxx structures.
Mult Message Element SEPAmail requirement
[1..1] sepamail_verification_request_001 First version of the message
MessageBody
This message contains a mandatory ISO part and an optional non-ISO part.
Ref Mult Message Element SEPAmail requirement
A [1..1] + Request IdentificationVerificationRequestV01, as per ISO acmt.023
B [0..1] + Complement Non-ISO part. Must be present only if transaction verifications
are requested.
ISOpart:IdentificationVerificationRequestV01
The general guiderule in this message is : among optional fields, only fill in those that you
want checked. For instance, even if you know your customer's birth date, but don't want it
checked, don't fill in field 3.1.23.
In any case, actual checking of all fields is directed by the general algorithm, described
here.
Please note : the ISO part is mostly copied from ISO20022 documents, and is provided here for
ease of reference. The indices in first column match the ones in this document.
However, the rules described in the last column, which complement the ISO rules, refer to
actual SEPAmail/DIAMOND usage.
Ref Mult Message Element SEPAmail requirement
1.0 [1..1] ++ Assignment
1.1 [1..1] +++ MessageIdentification
1.2 [1..1] +++ CreationDateTime
SEPAmailNorme1206–ÉditiondeJuin2015 Page291
Ref Mult Message Element SEPAmail requirement
1.3 [0..1]
+++ Creator
Mandatory. Designates the party which
initially creates the request, ie the
requesting creditor.
1.4 {or ++++ Party See below for full details about this element.
1.5 or} ++++ Agent
1.5.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
1.5.2 [0..1] +++++ BranchIdentification
1.6 [1..1]
+++ Assigner Designates the party from which the current
message originates (point-to-point)
1.7 {or ++++ Party
1.8 or} ++++ Agent
1.8.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
1.8.2 [0..1] +++++ BranchIdentification
1.9 [1..1]
+++ Assignee
Designates the party for which this messags is
intended (creditor's bank when the message is
created by the creditor, debtor's bank when it
is created by the creditor's bank ...)
1.10 {or ++++ Party
1.11 or} ++++ Agent
1.11.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
1.11.2 [0..1] +++++ BranchIdentification
2.0 [1..n] ++ Verification
2.1 [1..1] +++ Identification
2.2 [1..1]
+++
PartyAndAccountIdentification
2.3 [0..1] ++++ Party
3.1.0 [0..1]
+++++ Name For a private person, first name + last name.
In other cases, legal name or commercial name.
3.1.1 [0..1] +++++ PostalAddress
3.1.12 [0..1] +++++ Identification
3.1.13 [1..1] {Or ++++++
OrganisationIdentification
MUST be used if the party is not a private
person.
3.1.14 [0..1] +++++++ BICOrBEI
3.1.15 [0..n] +++++++ Other
3.1.16 [0..1]
++++++++ Identification Use this to store identification numbers (cf.
3.1.20)
3.1.17 [0..1] ++++++++ SchemeName
3.1.18 [1..1] {{Or +++++++++ Code
3.1.19 [1..1] Or}} +++++++++ Proprietary
3.1.20 [0..1]
++++++++ Issuer Type of data. Allowed values :
SIREN
SEPAmailNorme1206–ÉditiondeJuin2015 Page292
Ref Mult Message Element SEPAmail requirement
SIRET
TVA_intracomm
3.1.21 [1..1] Or} ++++++ PrivateIdentification MUST be used if the party is a private person
3.1.22 [0..1] +++++++ DateAndPlaceOfBirth
3.1.23 [1..1] ++++++++ BirthDate
3.1.24 [0..1] ++++++++ ProvinceOfBirth
3.1.25 [1..1] ++++++++ CityOfBirth
3.1.26 [1..1] ++++++++ CountryOfBirth
3.1.27 [0..n]
+++++++ Other Use one or several such elements to indicate
values to be checked.
3.1.28 [1..1] ++++++++ Identification Data itself
3.1.29 [0..1] ++++++++ SchemeName
3.1.30 [1..1] {{Or +++++++++ Code
3.1.31 [1..1] Or}} +++++++++ Proprietary
3.1.32 [0..1]
++++++++ Issuer
Type of data. Allowed values :
other_name (first name + last name, possibly
prepended by civility)
pass_number
pass_location
pass_date
idcard_number
idcard_location
idcard_date
3.1.33 [0..1] +++++ CountryOfResidence
3.1.34 [0..1] +++++ ContactDetails
2.4 [0..1] ++++ Account Mandatory
2.4.1 [1..1] {{Or +++++ IBAN
2.4.2 [1..1] Or}} +++++ Other
2.5 [0..1] ++++ Agent
2.5.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
2.5.2 [0..1] +++++ BranchIdentification
SEPAmailNorme1206–ÉditiondeJuin2015 Page293
This is the detail of fields under Creator element (1.3 above).
Ref Mult Message Element SEPAmail requirement
4.1.0 [0..1] ++++ Name
4.1.1 [0..1] ++++ PostalAddress
4.1.2 [0..1] +++++ AddressType
4.1.3 [0..1] +++++ Department
4.1.4 [0..1] +++++ SubDepartment
4.1.5 [0..1] +++++ StreetName
4.1.6 [0..1] +++++ BuildingNumber
4.1.7 [0..1] +++++ PostCode
4.1.8 [0..1] +++++ TownName
4.1.9 [0..1] +++++ CountrySubDivision
4.1.10 [0..1] +++++ Country
4.1.11 [0..7] +++++ AddressLine
4.1.12 [0..1] ++++ Identification Mandatory
4.1.13 [1..1] {Or +++++
OrganisationIdentification
4.1.14 [0..1] ++++++ AnyBIC
4.1.15 [0..*]
++++++ Other
Must contain the ICQX (first occurrence)
and, if applicable, an ICS (second
occurrence).
4.1.16 [1..1] +++++++ Identification ICQX / ICS.
4.1.17 [0..1] +++++++ SchemeName
4.1.18 [1..1] {{Or ++++++++ Code
4.1.19 [1..1] Or}} ++++++++ Proprietary
Must contain the value "SEPA" if 4.1.16
contains an ICS, and "SEPAMAIL.EU" if it
contains an ICQX.
4.1.20 [0..1] +++++++ Issuer
4.1.21 [1..1] Or} +++++ PrivateIdentification
4.1.22 [0..1] +++++ DateAndPlaceOfBirth
4.1.23 [1..1] ++++++ BirthDate
4.1.24 [0..1] ++++++ ProvinceOfBirth
4.1.25 [1..1] ++++++ CityOfBirth
4.1.26 [1..1] ++++++ CountryOfBirth
4.1.27 [0..*] +++++ Other
4.1.28 [1..1] ++++++ Identification
4.1.29 [0..1] ++++++ SchemeName
4.1.30 [1..1] {{Or +++++++ Code
4.1.31 [1..1] Or}} +++++++ Proprietary
4.1.32 [0..1] ++++++ Issuer
SEPAmailNorme1206–ÉditiondeJuin2015 Page294
4.1.33 [0..1] ++++ CountryOfResidence
4.1.34 [0..1] ++++ ContactDetails
Non‐ISOpart
This part allows the requester to add complementary test conditions. It is optional, and SHOULD
never be included if it is empty.
Ref Mult Message Element SEPAmail requirement
B1 [0..1] ++ MinCheckVersion Minimum version of name-checking algorithm. If
absent, any version is accepted.
B2 [0..1] ++ MaxCheckVersion Maximum version of name-checking algorithm. If
absent, the most recent version is accepted.
B3 [0..n] ++ VrfComplement One such element may be present for each
Verification (2.0) in the ISO part.
B3.1 [1..1] +++ VerifId
Identifier of the associated Verification
element. MUST match one of the
VerificationIdentification (2.1) indices.
B3.2 [0..1] +++ BusRef Business reference provided by the creditor to
ascertain its relation with the debtor.
B3.2.1 [1..1] ++++ Type Type of this reference. Can be "RUM" or
"other".
B3.2.2 [1..1] ++++ Value Value of this reference.
B3.3 [0..n] +++ TransactionTest
One such element for each operation to be
checked. Can be (meaning: is the account
allowed to) :
in_trf ('credits by incoming transfer)
out_trf (debits by outgoing transfer)
out_sepamail_trf (debits by outgoing SEPAmail
transfer)
out_dd (debits by incoming direct debit)
in_dd_return (credits by direct debit return)
in_all (credits)
out_all (debits)
inout_all (all operations)
SEPAmailNorme1206–ÉditiondeJuin2015 Page295
7.10. IGDiamondVerificationReport
These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the SEPAmail/DIAMOND message used to reply to a Diamond
VerificationRequest message.
It is used only in response to this message.
The full name of this message is
sepamail_message_identification.verification_IdentificationVerificationReport.
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
The actual contents of the VerificationReport element must be any one of the
sepamail_verification_report_xxx structures.
Mult Message Element SEPAmail requirement
[1..1] sepamail_verification_report_001 First version of the message
MessageBody
This message contains a mandatory ISO part, and a mandatory non-ISO part.
Ref Mult Message Element SEPAmail requirement
A [1..1] + Report IdentificationVerificationReportV01, as per ISO acmt.024
B [1..1] + Complement Non-ISO part.
SEPAmailNorme1206–ÉditiondeJuin2015 Page296
ISOpart:IdentificationVerificationReportV01
Please note : this whole part is directly copied from ISO20022 documents, and is only provided
here for ease of reference. The indices in first column match the ones in this document.
However, the rules described in the last column, which complement the ISO rules, refer to
actual SEPAmail/DIAMOND usage.
Ref Mult Message Element SEPAmail requirement
1.0 [1..1] ++ Assignment
1.1 [1..1] +++ MessageIdentification
1.2 [1..1] +++ CreationDateTime
1.3 [0..1]
+++ Creator Designates the party which initially
created the message.
1.4 {or ++++ Party
1.5 or} ++++ Agent
1.5.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
1.5.2 [0..1] +++++ BranchIdentification
1.6 [1..1]
+++ Assigner Must match the Assignee from the
“Demande de Vérification” (1.9)
1.7 {or ++++ Party
1.8 or} ++++ Agent
1.8.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
1.8.2 [0..1] +++++ BranchIdentification
1.9 [1..1]
+++ Assignee Must match the Assigner from the
“Demande de Vérification” (1.6)
1.10 {or ++++ Party
1.11 or} ++++ Agent
1.11.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
1.11..2 [0..1] +++++ BranchIdentification
2.0 [0..1] ++ OriginalAssignment Mandatory
2.1 [1..1] +++ MessageIdentification
2.2 [1..1] +++ CreationDateTime
3.0 [1..n]
++ Report
One such block (and only one) must be
present for each Verification block
(2.0) in the Diamond
VerificationRequest message
3.1 [1..1] +++ OriginalIdentification
3.2 [1..1]
+++ Verification
True iff all fields are correct. False
in all other cases, details in non-ISO
part.
3.3 [0..1] +++ Reason
3.4 [0..1] {Or ++++ Code
3.5 [0..1] Or} ++++ Proprietary
3.6 [0..1] +++
SEPAmailNorme1206–ÉditiondeJuin2015 Page297
Ref Mult Message Element SEPAmail requirement
OriginalPartyAndAccountIdentification
3.7 [0..1] ++++ Party
3.8 [0..1] ++++ Account
3.9 [0..1] ++++ Agent
3.9.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
3.9.2 [0..1] +++++ BranchIdentification
3.10 [0..1]
+++
UpdatedPartyAndAccountIdentification
3.11 [0..1] ++++ Party
3.12 [0..1] ++++ Account
3.13 [0..1] ++++ Agent
3.13.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
3.13.2 [0..1] +++++ BranchIdentification
Non‐ISOpart
This part is used to indicate additional information about the performed checks.
Ref Mult Message Element SEPAmail requirement
B1 [1..1] ++ CheckVersion
Indicates which version of the checking
algorithm was used. MUST be between the
incoming MinCheckVersion (B1) and
MaxCheckVersion (B2) of the request message,
inclusively, if these elements were present.
B2 [1..n] ++ VrfReportCompl One such element must be present for each
Verification (2.0) in the incoming message.
B2.1 [1..1] +++ VerifId Verification identifier. MUST match one of the
identifiers of the incoming message (2.1).
B2.2 [1..n] +++ ReturnCode One such element must be present for each 5-
digit code returned by the performed checks.
B2.3 [0..1] +++ BusRef Must be present if it was provided by the
Creditor in the request message (B3.2).
B2.3.1 [1..1] ++++ Type Type of this reference. Can be "RUM" or
"other".
B2.3.2 [1..1] ++++ Value Value of this reference.
B2.4 [0..n] +++ TrsInfo
One such element must be present for each
TrsTest element in the Diamond
VerificationRequest message, except if the
check could not be performed.
B2.4.1 [1..1] ++++ Transaction
Type of transaction, see TrsTest element in
Diamond VerificationRequest message for
possible values.
B2.4.2 [1..1] ++++ Allowed Contains true or false to indicate whether or
not this transaction is allowed on checked
SEPAmailNorme1206–ÉditiondeJuin2015 Page298
account. Repeat B2.4.1 and B2.4.2 as needed. A
transaction that could not be checked must be
absent from the TrsInfo element.
Verificationcodes
Here is the full list of allowed verification codes (index B2.2).
The codes are built as follows :
chars 1 and 2 indicate the data being verified
1. 01 IBAN
2. 02 customer type
3. 03 SIREN
4. 04 SIRET
5. 05 TVA intracomm
6. 06 birth date
7. 07 birth city
8. 08 birth country
9. 09 name
10. 10 other_name
11. 11 id card / pass
chars 3 to 5 indicate the result of the verification
1. for a simple check, 0 indicates false and 1 indicates true
2. for a more complex check, these chars will hold a score between 0 and 400
The detailed algorithm can be found here.
SEPAmailNorme1206–ÉditiondeJuin2015 Page299
Reasoncodes
Code Meaning
01000 invalid or non existant IBAN
01001 existant and valid IBAN
02000 incorrect customer type
02001 correct customer type
02020 impossible check of customer type
03000 incorrect SIREN
03001 correct SIREN
04000 incorrect SIRET
04001 correct SIRET
04002 incorrect SIRET, and included SIREN incorrect
04003 incorrect SIRET, but included SIREN correct
05000 incorrect TVA intracomm
05001 correct TVA intracomm
06000 incorrect birth date
06001 correct birth date
07000 incorrect birth city
07001 correct birth city
07020 impossible check of birth city
08000 incorrect birth country
08001 correct birth country
08020 impossible check of birth country
09XXX name control, XXX is a score between 0 and 400
(see above)
10XXX other name control, XXX is a score between 0
and 400 (see above)
11000 all provided identity documents incorrect
11001 at least one of the provided identity documents
correct
11020 impossible check of identity documents
SEPAmailNorme1206–ÉditiondeJuin2015 Page300
8. L'écosystèmeTEST
SEPAmailNorme1206–ÉditiondeJuin2015 Page301
8.1. IGtestL'écosystème test réunit les messages SEPAmail permettant de mettre en œuvre des tests.
Il comporte pour l'instant seulement deux messages, la demande et la réponse :
Nom Directives d'implémentation Schéma
SimpleTestRequest Standards:IG_Test_SimpleTestRequestSchéma
SimpleTestReport Standards:IG_Test_SimpleTestReport Schéma
SEPAmailNorme1206–ÉditiondeJuin2015 Page302
8.2. IGTestSimpleTestRequest These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the colour coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This message is the simplest of all test messages -- and currently, the only one. It is
designed to allow any party to test its SEPAmail communication, without generating any undue
traffic.
This message may be sent by anyone to anyone, in a nominal missive. It must be accepted by any
SEPAmail member, and an acknowledgement missive must of course be sent. The answer to this
message is a Test SimpleTestReport message.
This message must be signed and crypted as any other SEPAmail message.
MessageBody
This message is strictly non-ISO. It can hold two kinds of contents, text or binary, or
possibly both.
In the body of the message, only the Id is mandatory. All elements will be sent back unchanged
by the report.
Ref Mult Message Element SEPAmail requirement
A [1..1] +
SimpleTestRequest Base element
A1 [1..1] ++ TestId Unique identifier for current test.
A2 [0..1] ++ Text Textual part
A3 [0..1] ++ Data Binary part, base64 coded
SEPAmailNorme1206–ÉditiondeJuin2015 Page303
8.3. IGTestSimpleTestReport These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the colour coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This message is used to confirm proper reception of a Test SimpleTestRequest message, and
correlatively, to allow the sender of the request message to test the receiving end of his
SEPAmail implementation.
This message must only be used in these circumstances. It is mandatory, and must contain
exactly all elements of the incoming messages, without any change.
This message must be signed and crypted as any other SEPAmail message.
MessageBody
This message is strictly non-ISO. It can hold two kinds of contents, text or binary, or
possibly both.
All elements sent in the request must be resent without any change. No element may be added.
Ref Mult Message Element SEPAmail requirement
A [1..1] +
SimpleTestRequest Base element
A1 [1..1] ++ TestId Unique identifier for current test.
A2 [0..1] ++ Text Textual part
A3 [0..1] ++ Data Binary part, base64 coded
SEPAmailNorme1206–ÉditiondeJuin2015 Page304
9. L'écosystèmeSECURE
SEPAmailNorme1206–ÉditiondeJuin2015 Page305
9.1. IGsecureL'écosystème secure comporte trois messages :
Nom Directives d'implémentation Schéma
EnrollAdvise Standards:IG_Secure_EnrollAdvise Schéma
EnrollReport Standards:IG_Secure_EnrollReport Schéma
EnrollRequest Standards:IG_Secure_EnrollRequestSchéma
SEPAmailNorme1206–ÉditiondeJuin2015 Page306
9.2. IGSecureEnrollAdvise These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the Sepamail message used to advise all actors of the
enrollment of a new member, either bank or creditor.
The full name of this message is sepamail_message_secure_EnrollAdvise.
This message can only be generated and sent by an organization receiving an EnrollRequest
message, whether this message has been sent by a bank joining the Sepamail system, or by an
individual or corporation wishing to use its services.
The EnrollAdvise message has two aims :
transmitting the certificate(s) for the new member to existing members, after all due
verification has been made on them. This allows all other members to accept these
certificates without any further checks, if they wish. Typically, this message would be
transmitted by the scheme manager. Similarly, this message can be used to advise other
members of the removal or deactivation of some certificates.
notifying all members that a new party has enrolled. This allows all other members, in
the case of a BIC, to send delayed messages with this BIC as recipient.
This message is not based upon any existing ISO schema, since no such message exists in their
model. Thus, it only includes a non-ISO part, described here.
Rootelement
To facilitate upgrades, an indirection level has been inserted at the root of this element.
The root element is fixed, but it can be of different types. Currently, only the
sepamail_message_secure_enroll_advise_001 type is available.
Mult Message Element Sepamail requirement
[1..1] EnrollAdvise
EnrollAdvisebody
This part of the message describes the identification of the person/corporation having just
enrolled, and the associated certificate(s).
Ref Mult Message Element Sepamail requirement
A1 [1..1] ++ CreDtTm Creation date and time, ISO format
A2 [1..1] ++ Sndr Mandatory : identification of sender
A3 [1..1] ++ SndrBIC Mandatory : BIC of sender
A4 [1..1] ++ CdtrQxCard Mandatory, description of new Creditor (or party)
A4.1 [1..1] +++ PartyName Mandatory, text-only identifier of party. This should be
SEPAmailNorme1206–ÉditiondeJuin2015 Page307
Ref Mult Message Element Sepamail requirement
the legal identifier (registered name, for instance)
A4.9 [0..1] +++ DisplayName Party name, as will be displayed
A4.2 [1..1] +++ RIS2D Mandatory
A4.3 [0..1] +++ Test should be set to “true” if this is a testing-only party
A4.4 [1..1] +++ QXBAN Mandatory, standard IBAN2007 format, QXBAN recommended.
A4.5 [0..1] +++ ICQX
A4.6 [0..n] +++ Services Describes Sepamail applications supported by party.
Possible values are "GEMME", "RUBIS" and "JADE
A4.7 {Or +++ DbtrElements Debtor-specific elements, currently none.
A4.8 Or} +++ CdtrElements Creditor-specific elements
A4.8.1 [0..1] ++++ Logo
A4.8.2 [0..1] ++++ Thumbnail
A4.8.3 [0..n] ++++ customerHelp Elements describing where the customer reference8 may be
found by the debtors
A4.8.3.1 [1..1] +++++ identifierName Mandatory, used to differentiate identifiers
A4.8.3.2 [1..n] +++++ helpText Textual parts
A4.8.3.3 [0..n] +++++ helpImage Illustrations, if necessary
A5 [1..n] ++
CommunicationElement
Mandatory. One such element must be present for each
certificate the sender wishes to communicate to the
receivers. Normally, all certificates submitted by the
member should be sent to all other members.
A5.1 [1..1] +++ CertifId Mandatory. This identifier must be present but is not used
in the current flow of messages.
A5.2 [1..1] +++ Allow
Mandatory. This boolean indicates whether the certificates
is being added to the Sepamail system (true), or removed
from the system (false). Although it is possible, in the
same message, to remove some certificates and add some
other ones, this practice is discouraged.
A5.3 [1..1] +++ SignKey Mandatory. Contains the signing certificate.
A5.3.1 [0..1] ++++ KeyName
Mandatory. Indicates the element upon which the
certificate is based. For inter-bank enrollment, this
should be a mail address. For other cases, other
identifiers are possible.
A5.3.2 [0..1] ++++ KeyValue
A5.3.3 [0..1] ++++ RetrievalMethod
A5.3.4 [0..1] ++++ X509Data Mandatory, with all available sub-elements filled in.
A5.3.5 [0..1] ++++ PGPData
A5.3.6 [0..1] ++++ SPKIData
A5.3.8 [0..1] ++++ Other
A5.4 [1..1] +++ CryptKey Mandatory. Contains the ciphering certificate.
A5.4.1 [0..1] ++++ KeyName Mandatory. Indicates the element upon which the
SEPAmailNorme1206–ÉditiondeJuin2015 Page308
Ref Mult Message Element Sepamail requirement
certificate is based. For inter-bank enrollment, this
should be a mail address. For other cases, other
identifiers are possible.
A5.4.2 [0..1] ++++ KeyValue
A5.4.3 [0..1] ++++ RetrievalMethod
A5.4.4 [0..1] ++++ X509Data Mandatory, with all available sub-elements filled in.
A5.4.5 [0..1] ++++ PGPData
A5.4.6 [0..1] ++++ SPKIData
A5.4.7 [0..1] ++++ MgmtData
A5.4.8 [0..1] ++++ Other
A5.5 [1..n] +++ Family
Mandatory. Designates the message ecosystem(s) for which
the certificate will be used.
Possible values are test, secure, direct.debit and
payment.activation
SEPAmailNorme1206–ÉditiondeJuin2015 Page309
9.3. IGSecureEnrollRequest These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the Sepamail message used to register one or several
new certificates.
The full name of this message, which is part of the secure ecosystem, is sepamail_message_secure_EnrollRequest.
This message must be generated and sent by the person or organization wishing to enroll, ie
become part of the Sepamail community. This includes mostly three cases :
addition of a new bank to the Sepamail "bank pool"
subscription to the system, by a new individual or corporate entity
removal from the system of a user, or of a certificate
Once this message has been received and accepted, by means of an EnrollReport message, the new
person or organization's credentials are known to the Sepamail system and accepted by it, so
that it can now send any kind of messages, belonging to the declared message families, to the
Sepamail system through any exchange mechanism.
If the message is used to remove a certificate or a user, if must also be replied with an
EnrollReport message, acknowledging the removal of the required certificates.
It must be remembered that, in the Sepamail system, two certificates are used for each message:
one for signing, and one for ciphering. In this message, certificates are always handled as
pairs, to facilitate things.
This message is not based upon any existing ISO schema, since no such message exists in their
model. Thus, it only includes a non-ISO part, described here. Please note that this non-ISO
part is based on the XMLSignature standard.
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
Mult Message Element Sepamail requirement
[1..1] sepamail_message_secure_enroll_request_001 First version of this message
EnrollRequestbody
This part of the message actually describes the identification of the party wishing to enroll,
and the associated certificates.
Ref Mult Message Element Sepamail requirement
A1 [1..1] ++ CreDtTm Creation date and time, ISO format
A2 [0..1] ++ SndrRef Sender Reference. Internal reference the sender associates
with this request
SEPAmailNorme1206–ÉditiondeJuin2015 Page310
Ref Mult Message Element Sepamail requirement
A3 [1..1] ++ EnrollCode Code generated by requestor, and used later to check
his/her identity.
A4 [1..1] ++ Sndr Sender description
A4.1 [0..1] +++ Nm Mandatory
A4.2 [0..1] +++ PstlAdr
A4.3 [0..1] +++ Id
A4.3.1 {Or ++++ OrgId
A4.3.2 Or} ++++ PrvtId
A4.4 [0..1] +++ CtryOfRes
A4.5 [0..1] +++ CtctDtls
A4.6 [0..1] +++ CdtrAcct
A5 [1..1] ++ SndrBIC Mandatory, standard BIC format
A6 [1..1] ++ SndrQxCard Mandatory
A6.1 [1..1] +++ PartyName Mandatory, text-only identifier of party. This should be
the legal identifier (registered name, for instance)
A6.9 [0..1] +++ DisplayName Party name, as will be displayed
A6.2 [1..1] +++ RIS2D Mandatory
A6.3 [0..1] +++ Test should be set to "true" if this is a testing-only party
A6.4 [1..1] +++ QXBAN Mandatory, can be an IBAN if the QXBAN is not available.
A6.5 [0..1] +++ ICQX
A6.6 [0..n] +++ Services Describes Sepamail services supported by party. Possible
values are "GEMME", "RUBIS" ...
A6.7 {Or +++ DbtrElements Debtor-specific elements, currently none.
A6.8 Or} +++ CdtrElements Creditor-specific elements
A6.8.1 [0..1] ++++ Logo
A6.8.2 [0..1] ++++ Thumbnail
A6.8.3 [0..n] ++++ customerHelp Elements describing where the customer references may be
found by the debtors
A6.8.3.1 [1..1] +++++ identifierName Used to differentiate between identifiers
A6.8.3.2 [1..n] +++++ helpText Textual parts
A6.8.3.3 [0..n] +++++ helpImage Illustrations, if necessary
A7 [1..n] ++
CommunicationElement
Mandatory. One such element must be present for each
certificate the sender wishes to register. (Reminder :
Sepamail messages are grouped into ecosystems, and each
ecosystem can use a different certificate.)
A7.1 [1..1] +++ CertifId
Mandatory. This identifier can contain anything ; it will
be used in the EnrollReport message to identify this
particular certificate.
A7.2 [1..1] +++ Allow
Mandatory. This boolean indicates whether the certificates
must be added to the Sepamail system (true), or removed
from the system (false). Although it is possible, in the
SEPAmailNorme1206–ÉditiondeJuin2015 Page311
Ref Mult Message Element Sepamail requirement
same message, to remove some certificates and add some
other ones, this practice is discouraged.
A7.3 [1..1] +++ SignKey Mandatory. Contains the certificate for which enrollment
is requested. This is the signing certificate.
A7.3.1 [0..1] ++++ KeyName
Mandatory. Indicates the element upon which the
certificate is based. For inter-bank enrollment, this
should be a mail address. For other cases, other
identifiers are possible.
A7.3.2 [0..1] ++++ KeyValue
A7.3.3 [0..1] ++++ RetrievalMethod
A7.3.4 [0..1] ++++ X509Data Mandatory, with all available sub-elements filled in.
A7.3.5 [0..1] ++++ PGPData
A7.3.6 [0..1] ++++ SPKIData
A7.3.7 [0..1] ++++ MgmtData
A7.3.8 [0..1] ++++ Other
A7.4 [0..1] +++ CryptKey
Contains the certificate, if any, for which enrollment is
requested. This is the ciphering certificate. If the third
party only communicates through HTTPS exchange mechanisms,
this certifcate may be absent.
A7.4.1 [0..1] ++++ KeyName
Mandatory. Indicates the element upon which the
certificate is based. For inter-bank enrollment, this
should be a mail address. For other cases, other
identifiers are possible.
A7.4.2 [0..1] ++++ KeyValue
A7.4.3 [0..1] ++++ RetrievalMethod
A7.4.4 [0..1] ++++ X509Data Mandatory, with all available sub-elements filled in.
A7.4.5 [0..1] ++++ PGPData
A7.4.6 [0..1] ++++ SPKIData
A7.4.7 [0..1] ++++ MgmtData
A7.4.8 [0..1] ++++ Other
A7.5 [1..n] +++ Family
Mandatory. Designates the message ecosystem(s) for which
the certificate will be used. Possible values are "test",
"secure", "scheme", "direct.debit" and
"payment.activation".
It must be noted that the same ecosystem may be present
more than once, among all CommunicationElement elements.
This allows for instance the use of two certificates for
the same ecosystem: one with a password, and one without
password.
SEPAmailNorme1206–ÉditiondeJuin2015 Page312
9.4. IGSecureEnrollReport These implementation rules shall be applied in accordance with ISO20022 and SEPA own
implementation rules. Thus, unless explicitly specified, data contained within a field
or XML structure of a SEPAmail message must comply with the constraints related to the
equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
Introduction
This document describes the contents of the Sepamail message used to accept or reject a new
certificate.
The full name of this message, which belongs to the SAPPHIRE service family, is
sepamail_message_secure_EnrollReport.
This message must be generated and sent by the organization receiving an EnrollRequest message,
whether this message has been sent by a bank joining the Sepamail system, or by an individual
or corporation wishing to use its services.
The EnrollReport message has two aims:
accepting or rejecting each pair of certificates submitted by the sender
transmitting the receiver's own certificate(s) for the related message ecosystems
It can also be used to transmit additional data to the sender, such as a Sepamail Identifier
(RIS).
This message is not based upon any existing ISO schema, since no such message exists in their
model. Thus, it only includes a non-ISO part, described here.
Internalabstractionlevel
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
Mult Message Element Sepamail requirement
[1..1] sepamail_message_secure_enroll_report_001 First version of this message
SEPAmailNorme1206–ÉditiondeJuin2015 Page313
EnrollReportbody
This part of the message indicates the result of the enrollment, and if positive, carries
additional information for the new member.
Ref Mult Message Element Sepamail requirement
A1 [1..1] ++ CreDtTm Creation date and time, ISO format
A2 [1..1] ++ SndrRef Sender Reference. This reference must be the one used in the
same element of the EnrollRequest message.
A3 [1..n] ++ Report Mandatory. One such element must be present for each
CommunicationElement in the EnrollRequest message.
A3.1 [1..1] +++ CertifId Mandatory. Must match the referred CommunicationElement.
A3.2 [1..1] +++ Accepted
Mandatory. true means the certificates are accepted as
valid, and will be used from now on for the related message
ecosystem(s). false means the certificates are rejected, and
cannot be used. Other certificates will have to be submitted
by the sender. The false value must also be used when
replying to a removal request, to confirm deactivation of
the certificates.
A3.3 [0..1] +++ Reason Optional, but strongly recommended if the certificate is
rejected : human-readable explanation of rejection.
A4 [0..1] ++ OtherIdentif May be used to return a Sepamail Identifier to the sender
A5 [0..n] ++
CommunicationElement
Mandatory, except when replying to a removal request. One
such element must be present for each certificate the
replier wishes to communicate to the sender. Normally,
certificates should be sent for each message ecosystem
requested by the sender and supported by the receiver.
A5.1 [1..1] +++ CertifId Mandatory. This identifier must be present but is not used
in the current flow of messages.
A5.2 [1..1] +++ Allow Mandatory, and must be set to true in this case.
A5.3 [1..1] +++ SignKey Mandatory. Contains the signing certificate.
A5.3.1 [0..1] ++++ KeyName
Mandatory. Indicates the element upon which the certificate
is based. For inter-bank enrollment, this should be a mail
address. For other cases, other identifiers are possible.
A5.3.2 [0..1] ++++ KeyValue
A5.3.3 [0..1] ++++ RetrievalMethod
A5.3.4 [0..1] ++++ X509Data Mandatory, with all available sub-elements filled in.
A5.3.5 [0..1] ++++ PGPData
A5.3.6 [0..1] ++++ SPKIData
A5.3.7 [0..1] ++++ MgmtData
A5.3.8 [0..1] ++++ Other
A5.4 [1..1] +++ CryptKey Mandatory. Contains the ciphering certificate.
A5.4.1 [0..1] ++++ KeyName
Mandatory. Indicates the element upon which the certificate
is based. For inter-bank enrollment, this should be a mail
address. For other cases, other identifiers are possible.
A5.4.2 [0..1] ++++ KeyValue
SEPAmailNorme1206–ÉditiondeJuin2015 Page314
Ref Mult Message Element Sepamail requirement
A5.4.3 [0..1] ++++ RetrievalMethod
A5.4.4 [0..1] ++++ X509Data Mandatory, with all available sub-elements filled in.
A5.4.5 [0..1] ++++ PGPData
A5.4.6 [0..1] ++++ SPKIData
A5.4.7 [0..1] ++++ MgmtData
A5.4.8 [0..1] ++++ Other
A5.5 [1..n] +++ Family
Mandatory. Designates the message ecosystem(s) for which the
certificate will be used.
Possible values are test, secure, direct.debit and
payment.activation
SEPAmailNorme1206–ÉditiondeJuin2015 Page315
10. Sourcesetcontributeursdel’articleValidation 1206 Source: http://documentation.sepamail.org/index.php?oldid=7323 Contributeurs: Herve.Robache Contributeurs 1206 Source: http://documentation.sepamail.org/index.php?oldid=7426 Contributeurs: Herve.Robache, Olivier.jousselin Présentation générale Source: http://documentation.sepamail.org/index.php?oldid=6626 Contributeurs: Herve.Robache, Manfred.olm, Olivier.jousselin Errata 1206 Source: http://documentation.sepamail.org/index.php?oldid=7408 Contributeurs: Herve.Robache, Olivier.jousselin Présentation et principes Source: http://documentation.sepamail.org/index.php?oldid=7279 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin Les mécanismes d'échange Source: http://documentation.sepamail.org/index.php?oldid=7452 Contributeurs: Brigitte.nozay, Herve.Robache, Manfred.olm, Olivier.jousselin Spécification de l'échange des enveloppes SEPAmail Source: http://documentation.sepamail.org/index.php?oldid=7436 Contributeurs: Herve.Robache, Manfred.olm, Olivier.jousselin Les mécanismes d'identification Source: http://documentation.sepamail.org/index.php?oldid=7478 Contributeurs: Brigitte.nozay, Herve.Robache, Manfred.olm, Olivier.jousselin ICQX Source: http://documentation.sepamail.org/index.php?oldid=6726 Contributeurs: Herve.Robache, Olivier.jousselin, 1 modifications anonymes RIS2D Source: http://documentation.sepamail.org/index.php?oldid=7453 Contributeurs: Herve.Robache, Olivier.jousselin Algorithme de génération du QXBAN Source: http://documentation.sepamail.org/index.php?oldid=6738 Contributeurs: Herve.Robache, Manfred.olm La vision métier Source: http://documentation.sepamail.org/index.php?oldid=7482 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin Principes de sécurité Source: http://documentation.sepamail.org/index.php?oldid=6574 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin SMIRK CRY1203, la cryptographie Source: http://documentation.sepamail.org/index.php?oldid=7454 Contributeurs: Brigitte.nozay, Herve.Robache, Manfred.olm, Olivier.jousselin La norme Source: http://documentation.sepamail.org/index.php?oldid=6575 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin IG General rules Source: http://documentation.sepamail.org/index.php?oldid=6743 Contributeurs: Herve.Robache, Olivier.jousselin IG color coding Source: http://documentation.sepamail.org/index.php?oldid=6747 Contributeurs: Herve.Robache, Olivier.jousselin SMIRK MIS1202, la missive dans les échanges interbancaires Source: http://documentation.sepamail.org/index.php?oldid=7459 Contributeurs: Brigitte.nozay, Herve.Robache, Manfred.olm, Olivier.jousselin IG missive Source: http://documentation.sepamail.org/index.php?oldid=6755 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin Missive de service Source: http://documentation.sepamail.org/index.php?oldid=7441 Contributeurs: Brigitte.nozay, Cyril.vignet, Herve.Robache, Olivier.jousselin Horodatage des missives Source: http://documentation.sepamail.org/index.php?oldid=4326 Contributeurs: Brigitte.nozay, Olivier.jousselin Statistiques Source: http://documentation.sepamail.org/index.php?oldid=7442 Contributeurs: Herve.Robache, Lise.mahaut, Olivier.jousselin IG missive returnCodes Source: http://documentation.sepamail.org/index.php?oldid=6761 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin IG message Source: http://documentation.sepamail.org/index.php?oldid=6767 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin SMIRK MES1102, le message dans le réseau interbancaire Source: http://documentation.sepamail.org/index.php?oldid=6774 Contributeurs: Brigitte.nozay, Herve.Robache, Manfred.olm, Olivier.jousselin SMIRK APP1103, l'application SEPAmail Source: http://documentation.sepamail.org/index.php?oldid=7460 Contributeurs: Herve.Robache, Olivier.jousselin SMIRK REF1104, les référentiels Source: http://documentation.sepamail.org/index.php?oldid=7445 Contributeurs: Herve.Robache, Lise.mahaut, Olivier.jousselin, 1 modifications anonymes SMIRK REF1201, le référentiel icqx@scheme Source: http://documentation.sepamail.org/index.php?oldid=7463 Contributeurs: Herve.Robache, Manfred.olm, Olivier.jousselin, 2 modifications anonymes RUBIS 1206 Source: http://documentation.sepamail.org/index.php?oldid=7222 Contributeurs: Herve.Robache, Olivier.jousselin Les principes généraux (RUBIS) Source: http://documentation.sepamail.org/index.php?oldid=6582 Contributeurs: Brigitte.nozay, Herve.Robache, Herve.neuman, 1 modifications anonymes Les avantages pour le client (RUBIS) Source: http://documentation.sepamail.org/index.php?oldid=6583 Contributeurs: Brigitte.nozay, Herve.Robache, Manfred.olm, 1 modifications anonymes Cas d'usage (RUBIS) Source: http://documentation.sepamail.org/index.php?oldid=7465 Contributeurs: Brigitte.nozay, Cyril.vignet, Herve.Robache, Olivier.jousselin La gestion des inscriptions des débiteurs (RUBIS 1206) Source: http://documentation.sepamail.org/index.php?oldid=7479 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut, Olivier.jousselin La gestion des flux (RUBIS) Source: http://documentation.sepamail.org/index.php?oldid=7467 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin Les normes utilisées par RUBIS Source: http://documentation.sepamail.org/index.php?oldid=6587 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin Le lettrage des virements (RUBIS) Source: http://documentation.sepamail.org/index.php?oldid=6588 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin Les règles métier (RUBIS) Source: http://documentation.sepamail.org/index.php?oldid=7468 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin La gestion des refus après acceptation et avant échéance (RUBIS) Source: http://documentation.sepamail.org/index.php?oldid=6589 Contributeurs: Brigitte.nozay, Herve.Robache Le récapitulatif des messages (RUBIS 1206) Source: http://documentation.sepamail.org/index.php?oldid=7214 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin IG payment.activation Source: http://documentation.sepamail.org/index.php?oldid=6795 Contributeurs: Herve.Robache, Olivier.jousselin IG Rubis ActivationRequest Source: http://documentation.sepamail.org/index.php?oldid=7115 Contributeurs: Bot.maj.ig, Herve.Robache, Lise.mahaut, Olivier.jousselin IG Rubis ActivationReport Source: http://documentation.sepamail.org/index.php?oldid=6806 Contributeurs: Bot.maj.ig, Herve.Robache, Lise.mahaut, Olivier.jousselin IG Rubis ActivationEnroll Source: http://documentation.sepamail.org/index.php?oldid=6812 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin GEMME Source: http://documentation.sepamail.org/index.php?oldid=6591 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin, 1 modifications anonymes Les principes généraux (GEMME) Source: http://documentation.sepamail.org/index.php?oldid=6592 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut Les avantages pour le client (GEMME) Source: http://documentation.sepamail.org/index.php?oldid=6593 Contributeurs: Brigitte.nozay, Cyril.vignet, Herve.Robache, Lise.mahaut Cas d'usages (GEMME) Source: http://documentation.sepamail.org/index.php?oldid=7469 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut La problématique des flux autour du prélèvement Source: http://documentation.sepamail.org/index.php?oldid=7470 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut, Olivier.jousselin La gestion des flux (GEMME) Source: http://documentation.sepamail.org/index.php?oldid=7471 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut, Olivier.jousselin Les normes utilisées (GEMME) Source: http://documentation.sepamail.org/index.php?oldid=6597 Contributeurs: Brigitte.nozay, Cyril.vignet, Herve.Robache, Olivier.jousselin Le récapitulatif des messages (GEMME) Source: http://documentation.sepamail.org/index.php?oldid=7472 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut, Manfred.olm, Olivier.jousselin Les règles métier (GEMME) Source: http://documentation.sepamail.org/index.php?oldid=6824 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut, Olivier.jousselin, 1 modifications anonymes IG direct.debit Source: http://documentation.sepamail.org/index.php?oldid=6819 Contributeurs: Herve.Robache, Manfred.olm IG Gemme MandateInitiationRequest Source: http://documentation.sepamail.org/index.php?oldid=6827 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin IG Gemme MandateAcceptanceReport Source: http://documentation.sepamail.org/index.php?oldid=6833 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin IG Gemme Prenotification Source: http://documentation.sepamail.org/index.php?oldid=6839 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin IG Gemme RequestForCopy Source: http://documentation.sepamail.org/index.php?oldid=6843 Contributeurs: Bot.maj.ig, Herve.Robache, Olivier.jousselin DIAMOND Source: http://documentation.sepamail.org/index.php?oldid=6600 Contributeurs: Brigitte.nozay, Herve.Robache, Manfred.olm, 1 modifications anonymes Les principes généraux (DIAMOND) Source: http://documentation.sepamail.org/index.php?oldid=6601 Contributeurs: Brigitte.nozay, Cyril.vignet, Herve.Robache, Lise.mahaut, Olivier.jousselin Cas d'usage (DIAMOND) Source: http://documentation.sepamail.org/index.php?oldid=6848 Contributeurs: Herve.Robache Gestion des flux (DIAMOND) Source: http://documentation.sepamail.org/index.php?oldid=6852 Contributeurs: Herve.Robache Les règles métier (DIAMOND) Source: http://documentation.sepamail.org/index.php?oldid=6856 Contributeurs: Brigitte.nozay, Herve.Robache, Lise.mahaut, Olivier.jousselin Le récapitulatif des messages (DIAMOND) Source: http://documentation.sepamail.org/index.php?oldid=6605 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin Les aspects juridiques (DIAMOND) Source: http://documentation.sepamail.org/index.php?oldid=6860 Contributeurs: Herve.Robache IG identification.verification Source: http://documentation.sepamail.org/index.php?oldid=6864 Contributeurs: Brigitte.nozay, Herve.Robache, Olivier.jousselin IG Diamond VerificationRequest Source: http://documentation.sepamail.org/index.php?oldid=6867 Contributeurs: Bot.maj.ig, Herve.Robache, Lise.mahaut, Olivier.jousselin IG Diamond VerificationReport Source: http://documentation.sepamail.org/index.php?oldid=6871 Contributeurs: Bot.maj.ig, Herve.Robache, Lise.mahaut, Olivier.jousselin IG test Source: http://documentation.sepamail.org/index.php?oldid=6878 Contributeurs: Herve.Robache, Olivier.jousselin, 2 modifications anonymes IG Test SimpleTestRequest Source: http://documentation.sepamail.org/index.php?oldid=6881 Contributeurs: Bot.maj.ig, Herve.Robache, Manfred.olm, Olivier.jousselin IG Test SimpleTestReport Source: http://documentation.sepamail.org/index.php?oldid=6886 Contributeurs: Bot.maj.ig, Herve.Robache, Manfred.olm, Olivier.jousselin IG secure Source: http://documentation.sepamail.org/index.php?oldid=6891 Contributeurs: Herve.Robache, Manfred.olm IG Secure EnrollAdvise Source: http://documentation.sepamail.org/index.php?oldid=6894 Contributeurs: Bot.maj.ig, Herve.Robache, Manfred.olm, Olivier.jousselin IG Secure EnrollRequest Source: http://documentation.sepamail.org/index.php?oldid=6900 Contributeurs: Bot.maj.ig, Herve.Robache, Manfred.olm, Olivier.jousselin IG Secure EnrollReport Source: http://documentation.sepamail.org/index.php?oldid=6904 Contributeurs: Bot.maj.ig, Herve.Robache, Manfred.olm, Olivier.jousselin
SEPAmailNorme1206–ÉditiondeJuin2015 Page316
11. Sourcedesimages,licencesetcontributeursImage:SEPAmail_espaceIndependantSecurite.png Source: http://documentation.sepamail.org/index.php?title=Fichier:SEPAmail_espaceIndependantSecurite.png Licence: inconnu Contributeurs: Manfred.olm Image:GASEM_cyv_2011_fr_diapo_041.png Source: http://documentation.sepamail.org/index.php?title=Fichier:GASEM_cyv_2011_fr_diapo_041.png Licence: inconnu Contributeurs: Manfred.olm Image:SEPAmailMessageBanque.png Source: http://documentation.sepamail.org/index.php?title=Fichier:SEPAmailMessageBanque.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Manfred.olm Image:SEPAmail_mecanismeEchange.png Source: http://documentation.sepamail.org/index.php?title=Fichier:SEPAmail_mecanismeEchange.png Licence: inconnu Contributeurs: Manfred.olm Image:EnveloppeSepamail.png Source: http://documentation.sepamail.org/index.php?title=Fichier:EnveloppeSepamail.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Manfred.olm Image:ReseauInternetSepamail.png Source: http://documentation.sepamail.org/index.php?title=Fichier:ReseauInternetSepamail.png Licence: inconnu Contributeurs: Manfred.olm Image:Messagerie-identification-gemme.png Source: http://documentation.sepamail.org/index.php?title=Fichier:Messagerie-identification-gemme.png Licence: inconnu Contributeurs: Cyril.vignet Image:exempleRIS2D.png Source: http://documentation.sepamail.org/index.php?title=Fichier:ExempleRIS2D.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Manfred.olm, Olivier.jousselin Image:PeigneQXBAN.png Source: http://documentation.sepamail.org/index.php?title=Fichier:PeigneQXBAN.png Licence: inconnu Contributeurs: Manfred.olm Image:Messagerie-métier-desserte.png Source: http://documentation.sepamail.org/index.php?title=Fichier:Messagerie-métier-desserte.png Licence: inconnu Contributeurs: Cyril.vignet Image:EspaceSecuriteIndependant.png Source: http://documentation.sepamail.org/index.php?title=Fichier:EspaceSecuriteIndependant.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Manfred.olm Image:Perimetre_specification.png Source: http://documentation.sepamail.org/index.php?title=Fichier:Perimetre_specification.png Licence: inconnu Contributeurs: Cyril.vignet Image:MissiveService.png Source: http://documentation.sepamail.org/index.php?title=Fichier:MissiveService.png Licence: inconnu Contributeurs: Cyril.vignet, Olivier.jousselin Image:RUBISRéférentielFlux.png Source: http://documentation.sepamail.org/index.php?title=Fichier:RUBISRéférentielFlux.png Licence: inconnu Contributeurs: Cyril.vignet, Olivier.jousselin Image:RUBISSchemaFlux.png Source: http://documentation.sepamail.org/index.php?title=Fichier:RUBISSchemaFlux.png Licence: inconnu Contributeurs: Manfred.olm, Olivier.jousselin Image:RUBISFluxNormes.png Source: http://documentation.sepamail.org/index.php?title=Fichier:RUBISFluxNormes.png Licence: inconnu Contributeurs: Cyril.vignet, Olivier.jousselin Image:RUBIS-lettrage.png Source: http://documentation.sepamail.org/index.php?title=Fichier:RUBIS-lettrage.png Licence: inconnu Contributeurs: Cyril.vignet Image:RUBISMessagesListe.png Source: http://documentation.sepamail.org/index.php?title=Fichier:RUBISMessagesListe.png Licence: inconnu Contributeurs: Cyril.vignet, Olivier.jousselin Image:MessageGEMME201203.png Source: http://documentation.sepamail.org/index.php?title=Fichier:MessageGEMME201203.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Manfred.olm Image:particuliers.png Source: http://documentation.sepamail.org/index.php?title=Fichier:Particuliers.png Licence: inconnu Contributeurs: Herve.Robache Image:Flux_Diamond.png Source: http://documentation.sepamail.org/index.php?title=Fichier:Flux_Diamond.png Licence: inconnu Contributeurs: Herve.Robache Image:TestGlobalDIAMOND.png Source: http://documentation.sepamail.org/index.php?title=Fichier:TestGlobalDIAMOND.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Olivier.jousselin Image:TestPersonneMoraleDIAMOND.png Source: http://documentation.sepamail.org/index.php?title=Fichier:TestPersonneMoraleDIAMOND.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Olivier.jousselin Image:TestPersonnePhysiqueDIAMOND.png Source: http://documentation.sepamail.org/index.php?title=Fichier:TestPersonnePhysiqueDIAMOND.png Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Olivier.jousselin
SEPAmailNorme1206–ÉditiondeJuin2015 Page317
12. LicenceLa documentation de SEPAmail est mis à disposition selon les termes de la licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé. Les autorisations au-delà du champ de cette licence peuvent être obtenues sur la page dédiée Public:Licence
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/
![International Labour Organization - Modifications proposées du … · 2017. 3. 20. · GB.329/LILS/3(Rev.) GB329-LILS_3(Rev.)_[NORME-170316-3]-Fr.docx 1 Introduction 1. En juin 2014,](https://img.pdfslide.us/doc/110x75/60f8c07b4eba23506171f925/international-labour-organization-modifications-proposes-du-2017-3-20-gb329lils3rev.jpg)
