SEPAmail.eu Norme 1606 - édition 1802 V3documentation.sepamail.org/images/f/fa/SEPAmail.eu_Norme_1606... · 1 Introduction 1.1 Présentation générale SEPAmail est un service de

SEPAmail Norme version 1606 – Édition 1802 Page 1

SEPAmail Norme version 1606 Edition 1802


1 Introduction ........................................................................................................................................... 5

1.1 Présentation générale ...................................................................................................... 5

1.2 Termes de références ...................................................................................................... 8

2 La messagerie ..................................................................................................................................... 11

2.1 Présentation et principes ................................................................................................ 11

2.2 Les mécanismes d'échange ........................................................................................... 15

2.3 Spécification de l'échange des enveloppes SEPAmail ................................................... 21

2.4 Les mécanismes d'identification ..................................................................................... 25

2.5 Adressage des flux SEPAmail ........................................................................................ 34

3 La sécurité ........................................................................................................................................... 38

3.1 Principes de sécurité ...................................................................................................... 38

3.2 SMIRK CRY1203, la cryptographie ................................................................................ 40

4 La norme ............................................................................................................................................. 43

4.1 Principes généraux de la norme ..................................................................................... 43

4.2 IG General Rules ............................................................................................................ 44

4.3 IG Colour Coding ............................................................................................................ 44

4.4 SMIRK MIS1202, la missive dans les échanges communautaires .................................. 45

4.5 IG missive ...................................................................................................................... 57

4.6 Missive de service .......................................................................................................... 62

4.7 Horodatage des missives ............................................................................................... 63

4.8 IG missive returnCodes .................................................................................................. 64

4.9 IG message .................................................................................................................... 65

4.10 SMIRK MES1102, le message dans le réseau communautaire ..................................... 67

4.11 SMIRK APP1103, l'application SEPAmail ...................................................................... 70

4.12 Caractéristiques des fichiers CSV échangés ................................................................ 73

5 Les Référentiels SEPAmail ................................................................................................................ 74

5.1 Introduction .................................................................................................................... 74

5.2 Référentiel « ecosystem@scheme » .............................................................................. 75

5.3 Référentiel « member@scheme » .................................................................................. 76

5.4 Référentiel « bic.message@scheme » ........................................................................... 77

5.5 Référentiel « icqx@scheme » ......................................................................................... 78

5.6 Référentiel « qxban@bic » ............................................................................................. 81

5.7 Les Référentiels externes ............................................................................................... 82

6 Les Statistiques SEPAmail................................................................................................................. 83

6.1 Gestion des statistiques ................................................................................................. 83

6.2 Statistiques sur les missives ........................................................................................... 84

6.3 Statistiques sur les messages ........................................................................................ 85

7 L'application RUBIS ............................................................................................................................ 87

7.1 Les principes généraux (RUBIS) .................................................................................... 87

7.2 Les avantages pour le client (RUBIS) ............................................................................. 89

7.3 Cas d'usage (RUBIS) ..................................................................................................... 90

7.4 La gestion des inscriptions des débiteurs ....................................................................... 94


7.5 La gestion des flux (RUBIS) ........................................................................................... 98

7.6 Les normes utilisées par RUBIS ................................................................................... 103

7.7 Le lettrage des virements (RUBIS) ............................................................................... 104

7.8 Les règles métier (RUBIS) ............................................................................................ 105

7.9 La gestion des refus après acceptation et avant échéance (RUBIS) ............................ 107

7.10 Le récapitulatif des messages ..................................................................................... 107

7.11 IG payment.activation .................................................................................................. 108

7.12 IG Rubis ActivationRequest ......................................................................................... 109

7.13 IG Rubis ActivationReport............................................................................................ 176

7.14 IG Rubis ActivationEnroll ............................................................................................. 259

8 L'application DIAMOND .................................................................................................................... 261

8.1 Les principes généraux (DIAMOND) ............................................................................ 261

8.2 Cas d'usage (DIAMOND) ............................................................................................. 262

8.3 Gestion des flux (DIAMOND)........................................................................................ 263

8.4 Les règles métier (DIAMOND) ...................................................................................... 264

8.5 IG identification.verification ........................................................................................... 266

8.6 IG Diamond VerificationRequest .................................................................................. 267

8.7 IG Diamond VerificationReport ..................................................................................... 297

9 L’application AIGUE-MARINE .......................................................................................................... 320

9.1 Présentation du sujet .................................................................................................... 320

9.2 Contenu de l'application ............................................................................................... 320

9.3 SMIRK APP1501, l'application AIGUE-MARINE ........................................................... 321

9.4 Standards:IG mobility ................................................................................................... 328

9.5 IG AccountSwitchingRequest ....................................................................................... 332

9.6 IG AccountSwitchingResponse .................................................................................... 344

9.7 IG AccountSwitchingForward ....................................................................................... 365

9.8 IG AccountSwitchingNotify ........................................................................................... 381

10 L'application GEMME (non applicable) ......................................................................................... 394

10.1 GEMME ....................................................................................................................... 394

10.2 Les principes généraux (GEMME) ............................................................................... 394

10.3 Les avantages pour le client (GEMME) ........................................................................ 394

10.4 Cas d'usages (GEMME) .............................................................................................. 395

10.5 La problématique des flux autour du prélèvement ....................................................... 397

10.6 La gestion des flux (GEMME) ...................................................................................... 399

10.7 Les normes utilisées (GEMME) ................................................................................... 400

10.8 Le récapitulatif des messages (GEMME) ..................................................................... 401

10.9 Les règles métier (GEMME) ........................................................................................ 402

10.10 IG direct.debit ............................................................................................................ 407

10.11 IG Gemme MandateInitiationRequest ........................................................................ 408

10.12 IG Gemme MandateAcceptanceReport ..................................................................... 414

10.13 IG Gemme Prenotification .......................................................................................... 421

10.14 IG Gemme RequestForCopy ..................................................................................... 425


11 L'écosystème TEST ........................................................................................................................ 429

11.1 IG test .......................................................................................................................... 429

11.2 IG Test SimpleTestRequest ......................................................................................... 429

11.3 IG Test SimpleTestReport ........................................................................................... 430

12 L'écosystème SECURE (Non applicable) ...................................................................................... 431

12.1 IG secure ..................................................................................................................... 431

12.2 IG Secure EnrollAdvise ................................................................................................ 431

12.3 IG Secure EnrollRequest ............................................................................................. 434

12.4 IG Secure EnrollReport ................................................................................................ 438


1 Introduction 1.1 Présentation générale SEPAmail 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 des identifiants de référence de type BIC et IBAN.

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 Prestataires de Services de Paiement (PSP) à un niveau mondial.

Ce nouveau réseau 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.

1.1.1 Historique SEPAmail est un projet d’innovation démarré en 2008 dans le but de proposer une messagerie 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.

1.1.2 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.

1.1.3 Evolutions de la Norme Chaque version de la norme est identifiée par un numéro à 4 chiffres, sous la forme AAMM. Ainsi, la version 1206, par exemple, datait du mois de juin 2012.

Une même version de la Norme peut par ailleurs être l’objet de plusieurs éditions successives qui ne remettent pas en cause les fondements de la version, mais en précisent ou en corrigent certains aspects.

Le SCHEME MANAGER règle la fréquence et le contenu des versions et des éditions successives.


Les évolutions de la présente version 1606 édition de février 2018 de la Norme SEPAmail, par rapport la version 1606 édition d’avril 2017 sont listées dans le tableau ci-dessous :

Thème Id.

(interne à SEPAmail.eu)

Description synthétique Principaux paragraphes modifiés

messagerie

1802-2 Modification des “Délai maximal d’acquittement” et “Délai maximal avant renvoi”

Le champ X-Priority de l’enveloppe S-MIME doit avoir la même valeur que la priorité de la missive

Suppression de l’utilisation du Routing Warning dans la missive d’acquittement pour informer l’émetteur que la missive ne sera pas traitée dans le délai attendu. Seule la valeur BAD_TIME reste utilisable dans la balise A6.7.1 de la missive d’acquittement, pour indiquer une desynchronisation. La priorité d’une missive d’acquittement doit être la meme que celle de la missive nominale qu’il acquitte.

4.4.6 4.4.9 4.5.3, 4.5.5.1

1802-3.2 Les acquittements reçus au début du mois M+1 doivent être pris pour les statistiques « message » du mois M.

6.3

1802-4 Ajout des flux intra-Adhérents dans les statistiques 6 (introduction)

1802-6 Ajustements et corrections divers : Un QXBAN doit (au lieu de peut) être utilisé à la place d’un IBAN. La relation QXBAN�IBAN est remplacée par la relation QXBAN�Client�IBAN. Les statistiques messages doivent prendre en compte uniquement les messages transportés dans les missives ayant été acquittées positivement. Modification du libellé associé au code 5.8.4 de l’acquittement : “Order number error” est remplacé par “Identification error”

2.4.3.1, 2.4.3.2, 2.4.5, 2.4.6, 2.4.7, 4.5.4 (balises A5.1.2 et 15.4.2), 4.7, 4.8.1, 8.2

DIAMOND 1802-5 Mise à jour de la méthode de calcul de l’indicateur de réponse global

8.4.3.2, 8.7.5 (balise 3.2)

Nota Bene 1 : Le tableau ci-dessus n’est là qu’à titre indicatif. Il n’a pour but que d’aider à identifier les évolutions du présent document. En particulier, la description synthétique ne se substitue pas à la rédaction précise faite dans les chapitres qui suivent.

Nota Bene 2 : Certaines évolutions de l’ordre du correctif ont été apportées à ce document. Elles ne figurent pas dans le tableau ci-dessus.


1.1.4 Contributeurs à la version 1606 édition de février 2018 Cette version a bénéficié des contributions suivantes :

o Thierry PONS (BNPP) o Rui VAZ (BNPP) o Bénédicte DUBUIS (SG) o Valérie KOCH (CMCIC) o Sandryne SEYLLER (CMCIC) o Jérôme MAILLART (BPCE) o Christine MAUCHAUSSAT (CREDIT AGRICOLE) o Frédéric LE GALL (ARKEA) o Jacques BAILLON (SEPAMAIL.EU) o Matthieu DAMBRIN (SEPAMAIL.EU) o Olivier JOUSSELIN (SEPAMAIL.EU)

La liste des contributeurs aux versions précédentes reste disponible dans les versions publiées correspondantes.


1.2 Termes de références

1.2.1 Le SCHEME SEPAmail SEPAmail est une messagerie sécurisée basée sur des standards du marché et spécifiée au sein d’un document normatif. La Norme SEPAmail est définie et maintenue au sein d’un SCHEME par une entité juridique appelée SEPAmail.eu assurant le rôle de SCHEME Manager.

Dans le réseau, le SCHEME Manager assure un rôle particulier puisqu'il n'est pas un PSP.

Les différentes applications font appel à un ou plusieurs messages spécifiés par la Norme SEPAmail. Il est généralement possible de distinguer :

• les messages de type REQUEST, permettant de transmettre une demande de service • les messages de type REPORT, permettant de répondre à une demande de service

La Norme spécifie notamment que tout message est véhiculé au travers d’une enveloppe générique appelée missive SEPAmail.

La missive est elle-même protégée au travers d’une enveloppe SEPAmail, structure SMIME signée puis chiffrée, avant son transport au travers de différents canaux techniques possibles.

1.2.2 L’Adhérent SEPAmail Tout Prestataire de Services de Paiement, détenteur d’un identifiant de type BIC et désirant utiliser un ou plusieurs services SEPAmail, doit déclarer son adhésion à la norme auprès du SCHEME Manager afin que ce dernier puisse enregistrer ce nouvel Adhérent, notamment au travers des différents référentiels SEPAmail.

L’Adhérent SEPAmail s’oblige alors à respecter l’ensemble des spécifications de la Norme SEPAmail, pour les services applicatifs qu’il désire utiliser, ainsi qu’un ensemble de Règles Opérationnelles issues ou déduites :

• Du contexte règlementaire et juridique • Des bonnes pratiques du marché ou de la profession

1.2.3 Plate-forme SEPAmail et SPI L’adhérent échange des flux SEPAmail avec les autres adhérents au travers d’une ou plusieurs infrastructures de traitement.

Chacune de ces infrastructures de traitement est identifiée de façon univoque par un SPI (SEPAmail Platform Identifier).

Ce SPI est spécifique à l’adhérent et ne peut donc être partagé entre plusieurs adhérents.

1.2.4 Terminologie et relations logiques Le tableau et le diagramme de classe ci-dessous présentent la correspondance entre les termes définis par le contrat d’Adhésion et les objets référentiels décrits dans le présent Document.


Termes définis dans le Contrat d’Adhésion

Objets référentiels décrits dans les Règles Opérationnelles

Adhérent LegalMember

Infrastructure de traitement SPI (SEPAmail Platform Identifier)

Participant InternalRoute

Prestataire Référencé SEPAmailPlatformProvider

Une infrastructure de traitement (SPI) permet de prendre en charge les flux d’au moins un Participant (InternalRoutes). Un Participant peut être pris en charge par différentes infrastructures de traitement en fonction des messages SEPAmail concernés. La table de routage bic.message@scheme permet de déterminer l’infrastructure cible pour un Participant et un type de message SEPAmail donné.

L’établissement teneur de compte peut être différent du Participant. Dans un tel cas, l’établissement teneur de compte doit respecter les obligations décrites à l’article 6.1 du contrat d’adhésion.

La plate-forme peut être exploitée par l’Adhérent SEPAmail lui-même ou par un Prestataire Référencé assurant alors un rôle de « service bureau ». Un Adhérent peut également assurer ce même rôle de « service bureau » vis-à-vis d’autres adhérents.

Si un acteur, Adhérent ou Prestataire Référencé, assure ce rôle pour le compte de plusieurs Adhérents SEPAmail, il doit garantir la bonne identification, au travers d’un SPI spécifique, et la bonne isolation des flux de chacun des Adhérents concernés.

Concernant la notion de Prestataire Référencé, se reporter à la définition mentionnée dans le contrat du même nom.


1.2.5 L’émetteur L’émetteur est une entité économique (secteur privé, associatif ou institutionnel)

• Pouvant, en tant que personne morale créancier, disposer d'un ICS au niveau SEPA • et pouvant être référencé, en tant que personne morale, comme émetteur SEPAmail au travers

d’un ICQX. Dans le cas de l’application Aigue-Marine, l’émetteur a une autre signification.

1.2.5.1 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 ou PSP du pays peuvent demander l'inscription ou la modification d'un ICS à cette entité unique nationale de gestion de l'ICS.

1.2.5.2 L'ICQX

L'ICQX est l'identifiant unique d'une personne morale dans le réseau SEPAmail.

Cet identifiant est géré par le Scheme et est unique pour une entité économique et pérenne.

Il n'est pas nécessaire, qu'un émetteur dispose d'un identifiant ICS pour obtenir un ICQX.

1.2.6 L’adresse de messagerie SEPAmail

1.2.6.1 Le QXBAN

Le QXBAN est une instance de type IBAN (International Bank Account Number) utilisé par le système SEPAmail. Il est créé pour un BIC d’Adhérent (ou de Participant pour un Adhérent multi-Participants) à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un l'IBAN pour un code pays « QX » (pas de pays avec ce code).

1.2.6.2 Le RIS2D

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

1.2.7 L'application SEPAmail Une application SEPAmail est liée à un service proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail (messagerie sécurisée).

1.2.8 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 ce document.


2 La messagerie 2.1 Présentation et principes Le système SEPAmail se compose :

• d’un réseau 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.

2.1.1 Les espaces de confiance 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 émetteur – PSP de l’émetteur (banque de l’émetteur sur le schéma), dont la sécurité repose sur les systèmes en place : “banque à distance” et authentification associée, remise de fichiers ...

• Le réseau SEPAmail entre Adhérents PSP (banque dans les schémas) dont la sécurité repose sur : 1. Un nom de domaine unique géré par le « scheme-manager » et associant l’adresse

SPI.sepamail.eu à la bonne adresse physique de routage du PSP Adhérent possédant le SPI

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 du PSP

• L’espace PSP du destinataire (banque du destinataire sur le schéma) – 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 SPI et par application SEPAmail.

2.1.2 La structuration du systè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 entre Adhérents. • 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 intraPSP.

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:


2.1.3 Rappel S/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

2.1.4 Gestion du protocole DNS

2.1.4.1 Principe de délégation DNS

Le Système des Noms de Domaines (DNS : DOMAIN NAME SYSTEM) permet la gestion des noms logiques utilisés sur Internet, notamment pour établir les relations entre ces noms et les adresses IP des machines correspondantes.

Ces noms sont organisés selon une hiérarchie récursive de domaines et sous-domaines :

• Le domaine de plus haut niveau est représenté par un point : « . », • lui sont rattachés directement les domaines de niveau supérieur : « .com », « .eu », « .fr », • viennent ensuite les domaines tels que « sepamail.eu », • et ainsi de suite…

Les informations du Système des Noms de Domaines sont gérées par des serveurs qui se répartissent les différents domaines définis.

Chaque domaine peut être pris en charge par un serveur spécifique ayant reçu délégation du serveur gérant le domaine immédiatement supérieur.

Il est également possible de gérer, sans délégation, au sein d’un même serveur un domaine et ses sous-domaines, l’ensemble constituant une zone.


Le schéma suivant décrit un exemple de recherche DNS d’un serveur de messagerie pour un sous-domaine rattaché au domaine « sepamail.eu ». La recherche est adressée à un serveur DNS dit récursif dont le rôle sera de :

• rechercher le serveur ayant délégation pour le domaine en cause • interroger ce serveur sur la base de la requête adressée par le client originel • transférer à ce client la réponse obtenue.

Le SCHEME MANAGER gère le domaine « sepamail.eu ». À ce titre, il crée les enregistrements de type « NS » permettant de définir les délégations sur les sous-domaines.

Un Adhérent SEPAmail, ayant « BANKFRPPXXX » comme SPI, devra mettre en œuvre un serveur DNS chargé d’assurer, en délégation, la gestion du domaine qui lui est rattaché : « bankfrppxxx.sepamail.eu ».

2.1.4.2 Gestion dans le cadre de test

Le SCHEME MANAGER gère par ailleurs des délégations sur le sous-domaine « test.sepamail.eu » de façon à permettre aux Adhérents SEPAmail de gérer des identifiants spécifiques dans le cadre de ces tests.

Les adresses de type SMTP basées sur ce sous-domaine doivent être utilisées de manière analogue aux règles de Production :

• Dans le cadre du protocole de transport SMTP • Dans les entêtes de l’enveloppe SMTP • Dans les certificats utilisés pour les mécanismes de gestion du chiffrement et de la signature

Un Adhérent SEPAmail, identifié par exemple par le BIC « BANKFRPPXXX » peut ainsi gérer, en délégation, le domaine de test qui lui est rattaché : « bankfrppxxx. test.sepamail.eu ».

Un Adhérent a également la possibilité d’utiliser, en test, un SPI différent de celui utilisé en production.


2.2 Les mécanismes d'échange

2.2.1 Précisions sur les échanges Dans son acceptation initiale, SEPAmail gère uniquement une interface communautaire du réseau des Adhérents PSP, c'est à dire celle des flux échangés entre les Adhérents PSP (ou banques, terme parfois utilisé).

Dans la pratique, il se peut qu'un Adhérent 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, un Adhérent peut aussi utiliser en interne (interface interne au PSP) 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. Le mécanisme d'échange entre Adhérents 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 internes au PSP, et ne concerne JAMAIS l'interface communautaire. Il peut être utilisé pour l'interface client ou l'interface interne au PSP.

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 au chapitre 2.3.

2.2.2 Le courrier électronique

2.2.2.1 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 3851, le corps du mail étant obligatoirement une missive SEPAmail, apparaissant comme un attachement au format S/MIME ( RFC 5321).

L'expéditeur et le destinataire du mail sont obligatoirement de la forme :

<ecosystem>@<spi>.sepamail.eu

• <ecosystem> correspond à un ensemble de messages acheminés. • <spi> est le SPI de l'expéditeur (ou du destinataire). Dans le cas d'un échange entre Adhérents,

les deux adresses doivent présenter ce SPI. Dans le cas d'un échange entre client et PSP, l'adresse de l'expéditeur peut comporter un identifiant de type IBAN au lieu du SPI.

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.


2.2.2.2 Utilisation du canal courriel

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.


Les échanges de flux se présentent ainsi :

2.2.3 Le Web service

2.2.3.1 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.

Dans l'état actuel du système, il est déployé pour les échanges entre PSP (connecteur communautaire) et pour les échanges entre les entreprises et leurs PSP (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, l'identifiant de l'expéditeur peut être une adresse mail quelconque, gérée par l’émetteur, 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>@SPI.sepamail.eu où le SPI est celui du PSP de l’émetteur.

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 :

SEPAmail exchange

sending receiving


• envoyer des nouveaux éléments (mandats, notifications ...) 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.

2.2.3.2 Utilisation du Web service

Dans un cadre interne au PSP (communication émetteur-PSP de l’émetteur 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 de l’émetteur :

• 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.

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.

2.2.4 L'échange de fichiers

2.2.4.1 Principe

Ce troisième canal d'échange est conçu pour être utilisé uniquement sur une interface interne au PSP, 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 du PSP 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 canaux, l'expéditeur qui ne reçoit pas les missives d'acquittement correspondant à ses missives nominales doit prendre en charge leur renvoi.

2.2.4.2 Utilisation du canal fichiers

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.

2.2.4.3 Exemple de fonctionnement

À 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.


2.3 Spécification de l'échange des enveloppes SEPAmail Au 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.

2.3.1 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://spi.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://spi.sepamail.eu/ecosystem/soap à l'aide d'une méthode sendMissive)

2.3.2 Spécifications techniques

2.3.2.1 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 (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).


2.3.2.2 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 ait plusieurs SPI pour un même système d'information.

Alors, il décidera du SPI principal (SPIp) et tous les autres SPI seront considérés comme secondaires (SPIs). 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

SPIp.sepamail.eu 86400 A IN IP1 publique SI O

SPIp.sepamail.eu 86400 MX 10 IN SPIp.sepamail.eu O

Pour chacun des BIC secondaires

SPIs.sepamail.eu 86400 CNAME IN SPIp.sepamail.eu F

SPIs.sepamail.eu 86400 MX 10 IN SPIp.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 SPI principal, • le RR (resource record) de type MX pour le SPI 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 SPI secondaires sont déclarés comme des alias du SPI principal.

L'enregistrement du service de messagerie est obligatoire. Il pointe usuellement sur le RR de type A du SPI 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.

2.3.2.3 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. • 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).


2.3.2.4 L’échange avec SMTP

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,

2.3.2.5 L’échange avec HTTPS

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.

2.3.2.6 L’échange avec HTTP

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.

2.3.2.7 Échange de l'enveloppe SEPAmail avec une mécanique simple

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://spi.sepamail.eu/ecosystem/receive-envelope-smtp.

La réponse est alors soit :

• une réponse 204 (pas de contenu) • à 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.

2.3.2.8 Échange de l'enveloppe SEPAmail avec une couche SOAP

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 intraPSP pour partager avec des systèmes d'information de clients des méthodes sur des objets SEPAmail défini dans le SI du PSP.


Dans le cas d'un échange via SOAP, alors :

• le service web SOAP est appelé sur l'url • https://spi.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.

2.3.3 Notes d'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.

2.3.3.1 La gestion des files d'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.

2.3.3.2 La gestion de la charge

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 SEPAmail, 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é.


2.4 Les mécanismes d'identification

2.4.1 Le BIC et l’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 PSP, le BIC est l’identifiant du ‘‘fournisseur d’accès SEPAmail’’

• L’identifiant du client du PSP 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 PSP, 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

2.4.1.1 Le BIC : des contraintes pour les clients

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-PSP, SEPAmail a proposé de ne pas obliger le client à fournir de BIC mais uniquement un IBAN, charge au PSP Adhérent SEPAmail de fournir l'enrichissement.

2.4.1.2 Une identification non figé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.

2.4.2 Identification par PAN : Primary Account Number, ou tout simplement numéro de carte bancaire

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 :

• 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 • le BIC et le PAN, ce dernier remplaçant l'IBAN pour identifier le client destinataire • le BIC et l'IBAN pour le client émetteur de l'envoi • associer, au niveau du PSP 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 !

2.4.3 QXBAN : une identification SEPAmail

2.4.3.1 Intérêt

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.

D’une manière générale il est donc souhaitable de ne pas favoriser la diffusion des IBAN et leur utilisation dans d’autres contextes que celui pour lequel ils ont été créés (l’identification de comptes bancaires).

Dans le contexte des applications SEPAmail, il est apparu qu’il n’était pas acceptable de dévoiler les IBAN des utilisateurs à leur contrepartie :

- l’IBAN du débiteur au créancier et l’IBAN du créancier au débiteur (dans le cadre de l’application RUBIS)

- l’IBAN du Donneur d’Ordre au titulaire du compte à vérifier ou même au PSP teneur du compte à vérifier (dans le cadre de l’application DIAMOND)

Par ailleurs :

• les bases de données voient leur sensibilité augmenter significativement (et donc les mesures de sécurité à prendre également) dès lors qu’elles contiennent des IBAN.

• il n'est pas pratique d'échanger un IBAN entre 2 personnes Enfin, l’IBAN identifiant un compte bancaire, l’utilisation de l’IBAN comme adresse de messagerie SEPAmail imposerait que tout utilisateur de la messagerie SEPAmail détienne un compte bancaire au sein de l’établissement qui lui donne accès à la messagerie SEPAmail. Ce n’est pas une contrainte qui doit être imposée. SEPAmail a donc créé le QXBAN :

• un format d'IBAN pour rester compatible avec les développements et normes SEPAmail

• une utilisation interdite en compensation, donc pas de prélèvements ou de virements 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


Illustration :

Le format du QXBAN suit la norme des IBAN avec quelques spécificités :

• le country code est QX. 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 du PSP Adhérent (si l’Adhérent est mono-Participant) ou du PSP Participant (si l’Adhérent est multi-Participants)

• le numéro de compte DOIT être un tirage aléatoire sous la responsabilité du PSP du client • le numéro de compte DOIT utiliser la longueur maximale pour augmenter le niveau d'aléa du

QXBAN.


Il est bien entendu que le PSP qui a émis un QXBAN s'engage à traiter les messages qui lui sont destinés.

Un QXBAN identifie un client. Il peut être associé à 0, 1 ou plusieurs compte(s) bancaire(s) dont ce client est titulaire.

2.4.3.2 Algorithme de génération

Le QXBAN est un code de 34 caractères composé de :

• un code QX (2 caractères) • une clé de contrôle (2 caractères), selon le calcul de clé de contrôle de l'IBAN • un BIC sur 11 caractères (avec le modèle [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}) • un identifiant interne au BIC sur 19 caractères (avec le modèle [A-Z0-9]{19}), tiré aléatoirement

On propose la séquence fonctionnelle suivante pour le tirage :

• tirage aléatoire (loi uniforme) de trois nombres • génération des QXBANs équivalents, avec calcul de la clé de contrôle • vérification si les QXBAN ainsi générés existent déjà • si non pour au moins un, alors on prend ce QXBAN • si oui pour les trois, alors on génère une exception sur la génération du QXBAN et une alerte de

densité à l'administrateur du référentiel • si oui pour deux d'entre eux, on génère une simple alerte de densité à l'administrateur du

référentiel sans exception sur la génération L'avantage de cette séquence est que :

• le coût en temps est fixe quel que soit le tirage • l'alerte de densité est bien prévue dès le départ pour l'administrateur du référentiel

2.4.4 Relevé d'identité SEPAmail : RIS2D Il est apparu une synergie intéressante des travaux sur le QXBAN et des travaux du projet 2D-DOC. Ceci a conduit à définir la notion de RIS2D ou relevé d'identité SEPAmail reprenant :

• la logique de relevé de compte bancaire mais adapté à l'identification d'un "compte SEPAmail" • la matérialisation sous forme de code-à-barre 2D tant pour une simplification de la lecture qu'au

vu du nombre de données à gérer.

2.4.4.1 Présentation

Un RIS2D (Relevé d'Identité SEPAmail 2D) est une image de type code barre 2D au format datamatrix5 contenant des données propres à l'utilisateur de SEPAmail:


• nom, • prénom, • identifiant QXBAN, • date d'expiration

2.4.4.2 Contenu

Le contenu du RIS2D est conforme à la norme 2D-DOC disponible sur le site de l'ANTS.

Les champs suivants de 2D-DOC sont obligatoires pour le RIS2D :

• bloc d'en-tête, avec un code d'identification de document à 05 • 08 - date d'expiration • 30 - qualité, nom et prénom dans l'ordre qualité/nom/prénom, en séparant les champs par des / • 31 - code IBAN, qui contiendra le QXBAN • bloc signature

2.4.4.3 Exemple

Voici un exemple de RIS2D

Le format intègre, outre le code-à-barre :

• les étoiles apportant un rappel du logo SEPAMAIL • un début de mention du prénom et du nom en clair pour pouvoir s'y retrouver.

Voici un exemple de contenu de RIS2D :

• en-tête

1. autorité émettrice : FR99

2. pas de date d'émission

3. date de signature : 26/09/2012 (4652 jours, soit 122C hex, depuis le 01/01/2000)

4. type de document : 05, RIS2D

• données 5. date d'expiration : 26/09/2013 (5017 jours, soit 1399 hex)

6. propriétaire : M. Gilles Montparnasse

7. 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é.

2.4.5 Protection des identifiants pour le paiement par virement

Le schéma suivant représente un exemple de parcours client.

Il montre comment, dans le cadre de l’application RUBIS, il est possible d'éviter de communiquer son IBAN pour le paiement par virement et donc de protéger cette donnée sensible.

1. À l'inscription de son client au service, le PSP du client génère le QXBAN, maintient la base de

données {QXBAN � client � IBAN} et le remet à son client sous forme de RIS2D (puce 1)

2. le client a ainsi donc tout le loisir de mettre à disposition du créancier ce fichier image facilement lisible et dont le créancier peut extraire le QXBAN, le nom et le prénom (puce 2)

3. le créancier peut démarrer la séquence de demande de règlement en utilisant exclusivement le QXBAN de son client (flux bleu)

4. Le PSP recevant la demande peut identifier son client grâce à sa base de données {QXBAN � client � IBAN} (puce 4) et proposer le service de validation à son client. Notons au passage que le compte qui sera débité peut être un compte quelconque de ce client si le PSP offre ce service.

5. le flux de retour (flux rouge) se fait en utilisant le QXBAN du client débiteur

6. le virement utilise l'IBAN du donneur d'ordre. Cependant cet IBAN reste dans l'enceinte du PSP du créancier car celui-ci n'a pas le droit de remettre l'IBAN du donneur d'ordre à un bénéficiaire.

2.4.6 Protection des identifiants pour le paiement par prélèvement

Le schéma suivant représente un exemple de parcours client dans le cadre de l’application GEMME (non applicable).

Base

QXBAN IBAN

client

La banque du débiteur complète l’IBAN de la contrepartie avec la base QXBAN � client � IBAN pour un virement


Le prélèvement pose une problématique certaine du fait de l'obligation de donner son IBAN au créancier. Une utilisation des identifiants (RIS2D-QXBAN) et des flux SEPAmail pourrait permettre de s'affranchir de cette contrainte. En effet la norme SEPA DIRECT DEBIT impose une référence unique de mandat (RUM) que l'on peut mettre à profit.

1. comme précédemment, le PSP du débiteur a généré et mis à disposition un RIS2D (puce 1)

2. le client débiteur donne son RIS2D ou son QXBAN au créancier tout en demandant un paiement par prélèvement. Notons au passage que cela pourrait pousser plus de clients à ce mode de paiement.

3. le créancier génère une demande de mandat avec le service GEMME@SEPAMAIL en utilisant le QXBAN et la RUM, référence unique du mandat (flux bleu)

4. Le PSP du débiteur identifie son client grâce à la base de données {QXBAN � client � IBAN}, fait choisir le compte de prélèvement désiré par son client et renvoie (flux rouge) le mandat de prélèvement accepté par son client et avec le véritable IBAN du client. En parallèle, le PSP du débiteur mémorise les RUM acceptées par son client et en gère la validité.

5. Le PSP du créancier constitue une base de données {créancier/RUM -> IBAN} et indique à son client créancier que le mandat est accepté

6. il suffira au créancier de fournir la RUM comme identifiant de paiement dans ses fichiers d'initiation de prélèvement (flux noir)

7. Le PSP du créancier complète la RUM avec l'IBAN trouvé dans la base de données {créancier/RUM -> IBAN} et émet en compensation.

Ainsi les identifiants sensibles (IBAN) restent dans les enceintes des PSP pour une meilleure protection des clients et une plus grande simplicité de gestion par le créancier.

De plus le mécanisme précédent ne crée pas de lien fort entre le PSP du créancier et le créancier. Celui-ci peut changer de PSP assez simplement :

1. le créancier envoie des avenants de mandats en utilisant le couple QXBAN/RUM en passant par son nouveau PSP

Base

QXBAN IBAN

client

4

La banque du débiteur complète l’IBAN de la contrepartie avec la base QXBAN � client � IBAN pour un virement


2. Le PSP du débiteur peut répondre immédiatement sans validation nécessaire par le débiteur puisque nous sommes dans le cas d'un amendement

3. le nouveau PSP du créancier constitue la base de données {créancier/RUM -> IBAN} et pourra ainsi compléter les flux de prélèvements

2.4.7 ICQX

2.4.7.1 Principes

Les ICQX sont destinés à gérer le référentiel des émetteurs personnes morales sur le réseau 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

2.4.7.2 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

Base

QXBAN IBAN

client


• Position 7 : un caractère alphanumérique 3. « Z » par défaut quand l’ICQX est attribué par le QXOO (ou local OO)

4. 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)


2.5 Adressage des flux SEPAmail

2.5.1 L'émetteur et le destinataire

Du point de vue technique, il y a bien un émetteur de l'envoi et un destinataire. Du point de vue métier, l'émetteur de l’envoi est surtout important pour sa réponse. De ce fait, l'émetteur de l'envoi devient le destinataire de la réponse.

Dans les premiers services envisagés, il sera donc toujours préféré l'utilisation des identifiants métiers : créancier, débiteur, donneur d'ordre, bénéficiaire.

Néanmoins pour une présentation générale, nous utiliserons les expressions « émetteur initial » et « destinataire initial » en lieu et place des expressions « émetteur » et « destinataire » ayant un double sens.

Les échanges métiers se structurent donc suivant le schéma précédent :

• L’initialisation d'un envoi réalisée par l'émetteur initial • la transmission de l'envoi vers le PSP du destinataire. Dans la structure SEPAmail, cette

transmission est nommée REQUEST (payment-request, mandate-request,...) • la mise à disposition par le PSP du destinataire, suivant le ou les canaux proposés par ce PSP • la validation par le destinataire initial. Au même titre que pour l'initialisation, les règles

d'authentification peuvent être adaptées au service sous-jacent. • Une fois la validation effectuée et contrôlée, la réponse est nommée REPORT (mandate-report,

payment-report,...)

2.5.2 Principes de desserte (reachability) SEPAmail étant une initiative privée, il n'est pas envisageable que tous les acteurs adhérents démarrent le même jour, et ceci à chaque nouvelle application ou nouvelle évolution.

De ce constat, il est important que le PSP de l'émetteur gère la desserte à 2 niveaux :


• niveau global par information qu'un réseau de PSP destinataire a ouvert le service (information qui sera organisée au niveau de la structure de gouvernance)

• niveau transaction en mettant à disposition une réponse intermédiaire (puce 2) indiquant si le PSP du destinatire dessert ses clients.

Le PSP de l'émetteur peut profiter de cette gestion de la desserte pour offrir un service complémentaire.

2.5.3 Flux nominaux

2.5.3.1 Identifiants de l’émetteur et du destinataire au sein des missives SEPAmail

Les blocs <Snd> et <Rcv> de la missive SEPAmail contiennent les identifiants de l’émetteur et du destinataire respectifs de cette missive.

Au sein de la Missive échangée entre Adhérents, ces identifiants désignent les Participants, et selon les messages, les Utilisateurs finaux.

L’Utilisateur final est renseigné selon les règles suivantes d’alimentation de la structure <Rcv>, ou de la structure <Snd>, en fonction des Applications :


2.5.3.2 Identifiants des enveloppes SEPAmail

Le SPI permet d’identifier les Infrastructures de traitement, en tant qu’émetteurs et récepteurs des enveloppes SEPAmail et de limiter le nombre de certificats à gérer dans le cadre des échanges SEPAmail à ces seules Infrastructures.

La table de routage bic.message@scheme permet pour un BIC (internalRouteBic) identifiant un Participant référencé au sein de la missive, d’en déduire le BIC (SPI) de l’Infrastructure capable de prendre en charge le flux SEPAmail considéré en fonction du type de message.

À partir de la table de routage bic.message@scheme, l’Infrastructure de traitement SEPAmail calcule les champs « FROM » et « TO » de l’enveloppe SEPAmail de la façon suivante :

• Le champ « FROM » correspond au BIC (SPI) de l’Infrastructure elle-même. • Le champ « TO » correspond au BIC (SPI) de l’Infrastructure déclarée dans le référentiel

bic.message@scheme pour le BIC (internalRouteBic) renseigné dans le champ <Rcv> de la missive et pour le type de message SEPAmail donné.

La signature de la missive est calculée au moyen de la clé privée associée au certificat de l’Infrastructure identifiée par le champ « FROM ».

Le chiffrement final de l’enveloppe S/MIME SEPAmail est effectué pour le destinataire identifié par le champ « TO ».

2.5.4 Flux d’acquittement Pour assurer le bon fonctionnement de la messagerie à un niveau métier, chaque envoi (missive nominale) doit faire l'objet par le PSP du destinataire d'une missive d'acquittement. Celle-ci peut comporter des éléments sur le niveau de service mais doit éviter les données métiers. Ces dernières sont censées faire l'objet d'une missive nominale transportant un message de type REPORT.

La missive d’acquittement n'est pas acquittée.

Application Message Alimentation des balises de la missive

<BIC> du bloc <Snd>

<IBAN> du bloc <Snd>

<BIC> du bloc <Rcv>

<IBAN> du bloc <Rcv>

RUBIS PaymentActivationRequest OUI OUI OUI OUI

PaymentActivationReport OUI OUI OUI OUI

PaymentActivationEnroll OUI OUI OUI OUI

DIAMOND VerificationRequest OUI OUI OUI NON

VerificationReport OUI NON OUI OUI

AIGUE MARINE

AccountSwitchingRequest OUI NON OUI NON

AccountSwitchingResponse OUI NON OUI NON

AccountSwitchingForward OUI NON OUI NON

AccountSwitchingNotify OUI NON OUI NON


Il n'y a aucune obligation que la missive d'acquittement passe par le même canal d'échange que la missive nominale. En particulier, il est tout à fait possible d'utiliser uniquement le canal SMTP pour toutes les missives d'acquittement.

Il convient en effet d’appliquer les règles suivantes de détermination pour

• les structures <Snd> et <Rcv> de la missive d’acquittement o La structure <Snd> de la missive d’acquittement doit reprendre intégralement les

identifiants de la structure <Rcv> de la missive nominale. o La structure <Rcv> de la missive d’acquittement doit reprendre intégralement les

identifiants de la structure <Snd> de la missive nominale. • les champs « FROM » et « TO » de l’enveloppe SEPAmail de la missive d’acquittement

o Le champ « FROM » de l’enveloppe de la missive d’acquittement doit être renseigné avec la valeur du champ « TO » de l’enveloppe de la missive nominale.

o Le champ « TO » de l’enveloppe de la missive d’acquittement doit être renseigné avec la valeur du champ « FROM » de l’enveloppe de la missive nominale.

2.5.5 Gestion des flux de réponse Dans le cas d’un message applicatif en réponse à un message applicatif initial, e.g. un « PaymentActivationReport » en réponse à un « PaymentActivationRequest » dans le cas d’une Demande de Règlement RUBIS, la construction de la missive et de l’enveloppe SEPAmail doit suivre les règles suivantes :

• La balise <Rcv> de la missive nominale contenant le Message de réponse doit être renseignée avec la valeur de la balise <Snd> de la missive nominale contenant le message initial.

• La balise <Snd> de la missive nominale contenant le Message de réponse doit être renseignée avec la valeur de la balise <Rcv> de la missive nominale contenant le message initial.

• Les champs « FROM » et « TO » de l’enveloppe doivent quant à eux être recalculés à partir des identifiants de la missive contenant le message de réponse et du type de ce message.


3 La sécurité 3.1 Principes de sécurité Il y a plusieurs principes de sécurité au sein de SEPAmail.

• Indépendance des espaces de sécurité

1. client - PSP / PSP – PSP / PSP – client

2. chaque articulation entre espaces de sécurité passe par un membre adhérent à l’espace (PSP)

• 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

3.1.1 Signature des messages 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é du PSP du créancier au PSP du débiteur peut aussi être utilisé : dans ce cadre, qui serait contractuel entre PSP, la seule réception de la missive signée par le PSP du créancier pourrait suffire. Le PSP 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.

• 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 du PSP suffit car contractuellement celle-ci s’engage devant les autres PSP à 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 le PSP du débiteur, charge à lui 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.

3.1.2 Indépendance des espaces de sé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.


3.2 SMIRK CRY1203, la cryptographie Cette 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.

3.2.1 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.

3.2.2 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.


Principes

• SEPAmail utilise la norme S/Mime

1. le contenu est inclus dans une enveloppe de signature S/MIME opaque (i.e. non-détachée)

2. cette enveloppe de signature est elle-même incluse dans une enveloppe de chiffrement S/MIME

• avec deux échanges possibles entre les adhérents SEPAmail :

1. le parcours canonique utilisant un échange via le protocole SMTP

2. un parcours flash utilisant un échange via un web service

• ainsi que les usages X509 de confidentialité et d'authentification (intégrité de fait)

• avec une signature incluse dans le contenu chiffré

3.2.3 Le certificat SEPAmail SEPAmail utilise deux certificats S/MIME pour chacune des adresses de courriels utilisées (une par SPI et par écosystème, voir la demande de commentaire autour de la missive). L'un des certificats est utilisé exclusivement pour le chiffrement, l'autre exclusivement pour la signature.

Ce certificat doit présenter les caractéristiques suivantes :

• un usage de la bi-clé pour

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]@[spi].sepamail.eu

3.2.4 Cas du parcours canonique Dans le cas du parcours canonique (privilégié), la confidentialité et la signature sont obligatoires.

3.2.5 Cas du parcours flash 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)


4 La norme 4.1 Principes généraux de la norme Au sein d'une infrastructure SEPAmail d’un Adhérent, il y a quatre classes de composants fonctionnels principaux :

• SMART qui reçoit et émet des missives dans le réseau des adhérents SEPAmail (espace inter-adhérents)

• les composants métiers : 1. RUBIS

2. DIAMOND

3. AIGUE-MARINE

4. …

• un composant de TEST • un composant optionnel SMILE qui reçoit et émet des missives dans le réseau des clients du

PSP (espace intra-adhérent) Les documents de la norme sont :

• les schémas XML et leurs directives d'implémentation • les demandes de commentaires (SMIRK) • les règles métiers (BUSINESS RULES) • des spécifications techniques et fonctionnelles

1. API SMART (file et web-service)

2. protocoles échanges

3. validation XML


4.2 IG General Rules These rules apply to all missives and messages in SEPAmail.

4.2.1 Acceptable characters The only acceptable characters are as follows:

- The characters authorized in SEPA messages : • lower case letters a - z • upper case letters A - Z • digits 0 - 9 • special chars / : - ? ( ) . , ' + • space

- The characters @ and _

4.2.2 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, please refer to Operational Rules of each application

4.2.3 Date and time fields All date, time or date and time fields are in ISO 8601 format. The time zone indicator MUST be used, in any of the formats supported by the standard.

4.3 IG Colour Coding In the applicative message Implementation Guides, some fields are coloured according to the following significances.

Colour Context

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

The message implementation guidelines, that are related to the AIGUE-MARINE application, do not use this coding.


4.4 SMIRK MIS1202, la missive dans les échanges communautaires

4.4.1 Introduction et gé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 intraPSP, 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)

4.4.2 Les principes La missive est un flux XML respectant le schéma sepamail_missive (Cf. http://xsd.sepamail.eu), 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.

Dans les échanges entre Adhérents, 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 communautaire. Elle ne fait donc pas partie de ce SMIRK.

4.4.3 Le routage Le routage se sert d'un adressage de type « courriel » sur le domaine sepamail.eu (le nom de domaine sepamail.eu est géré par le scheme SEPAmail) de la forme :

<ecosystem>@<spi>.sepamail.eu

ou

<ecosystem>@<xx.scheme>.sepamail.eu

où :


• <ecosystem> est une famille SEPAmail du référentiel ecosystem@scheme • <spi> est un SPI du référentiel bic.message@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.)

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 :

4.4.3.1 Règles de routage à la réception

Un adhérent n'accepte des missives que pour les SPI 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 SPI 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.

4.4.3.2 Règles de routage à l'émission

Un adhérent n'envoie des flux au sein du réseau SEPAmail qu'à un adhérent SEPAmail pour un SPI déclaré dans le référentiel bic.message@scheme.

4.4.4 L'acquittement d'une missive 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.

En particulier, si un Adhérent reçoit une missive nominale d'ordre n après avoir reçu une missive nominale d'ordre m (différent de n, supérieur ou inférieur), il doit acquitter la missive d'ordre n. La missive d'ordre n ne doit pas être acquittée négativement pour la seule raison qu'une même missive ayant un numéro d'ordre différent a déjà été reçue. En revanche, la missive d'ordre n doit être ignorée après réception et acquittement pour ne pas générer un doublon d'un point de vue Métier.

• l'acquittement doit être mis en œuvre selon la priorité et en respectant les délais maximaux de la priorité

• un seul acquittement doit être émis pour une missive nominale reçue

4.4.5 Le séquencement La séquence d'un échange de missives est :


• 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 et une seule missive d'acquittement destinée à l'adhérent A en réponse à

la missive nominale • l'adhérent A reçoit la missive 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 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 »

4.4.6 Renvoi d'une missive Un système de renvoi d'une missive doit ê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.

Dans le cas où une missive nominale n'est pas acquittée pendant le délai maximal d’acquittement précisé dans le tableau ci-après, le renvoi de missive doit être mis en œuvre. Les règles suivantes s’appliquent :

• Le renvoi de la missive doit avoir lieu après le "Délai maximal d’acquittement" et avant le "Délai maximal avant renvoi" indiqués dans le tableau ci-dessous.

• L'Adhérent doit renvoyer la missive autant de fois que nécessaire jusqu'à réception de l'acquittement, dans la limite de 3 renvois (le troisième renvoi correspondant à une missive d'ordre 4).

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é.


Délai maximal d’acquittement et Délai maximal avant renvoi en fonction de la priorité de la missive

Priorité Délai maximal

d’acquittement Délai maximal avant renvoi

1 la plus haute (HIGHEST) 5 sec 10 sec

2 haute (HIGH) 10 sec 20 sec

3 normale (NORMAL) 1 h 2 h

4 basse (LOW) 3 h 6 h

5 la plus basse (LOWEST) 12 h 24 h

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+10 sec et T+20 sec. Si elle est envoyée à T+15 sec, la missive d'ordre 3 (toujours en l'absence d'acquittement) pourra être envoyée entre T+25 sec et T+35 sec, et ainsi de suite.

Le délai maximal d'acquittement, le délai maximal avant renvoi et le nombre maximal de renvois indiqués plus haut 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.

4.4.7 Le procédé d'escalade Dans le cas où une missive ne serait pas acquittée, l'adhérent peut procéder à l'escalade prévue par le scheme dès que le délai maximum d'acquittement de la missive d'orde 1 a été dépassé.

L’escalade consiste à prendre contact par mail ou téléphone avec l’Adhérent destinataire de la missive nominale. Après instruction bilatérale, l'Adhérent responsable de l'incident alerte le Scheme Manager si l'incident risque de perturber d'autres Adhérents.

4.4.8 Le contenu 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 adjoindre une signature électronique du signataire, client du PSP 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é

4.4.9 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, doit avoir la même valeur que la priorité de la missive (balise A4).

4. SUBJECT vide par défaut, sans information signifiante sur le contenu du message

• un corps reprenant deux parties 5. la missive, chiffrée avec la clé privée du certificat S/MIME liée à l'adresse FROM

6. 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.

4.4.10 La sécurité : authentification, confidentialité et horodatage 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é.

La confidentialité est assurée par le chiffrement de la missive par l'émetteur avec la clé publique du destinataire. Ainsi, seul le destinataire pourra déchiffrer le flux avec sa clé privée.


La missive est horodatée en émission et en réception par une marque de temps de type date/heure. Les principes détaillés d'horodatage applicables à SEPAmail, inspirés des bonnes pratiques de la FNTC (http://www.fntc.org/, section guide), sont décrits dans cette page.

Si un horodatage de type « contremarque de temps signée » est nécessaire, alors cet horodatage est réalisé sur l'enveloppe SMTP (et non seulement la missive) par un service tiers certifié, juste avant l'émission ou juste après la réception.

4.4.11 Le protocole d'échange des missives

L'échange des missives se fait nativement sur le réseau IP via la couche de transport TCP.

Sur ces couches, SEPAmail implémente deux parcours avec deux protocoles de communication différents :

• SMTP • HTTPS+SOAP

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

4.4.11.1 La qualité de service

La qualité du service est soumise à un cadre faisant l'objet d'un document séparé 18.


4.4.11.2 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.

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.

4.4.11.2.1 Réception d'une missive nominale

4.4.11.2.1.1 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).

4.4.11.2.1.2 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.

4.4.11.2.1.3 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.

4.4.11.2.1.4 Vérification des SPI

Il faut extraire les sous-domaines des adresses FROM et TO.

Ces deux sous-domaines doivent être ceux d'un SPI appartenant à bic.message@scheme.

Celui correspondant au destinataire (TO) doit également être l'un des SPI rattachés à l'adhérent destinataire dans le référentiel member@scheme.

4.4.11.2.1.5 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.

4.4.11.2.1.6 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.

4.4.11.2.1.7 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).

4.4.11.2.1.8 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.

4.4.11.2.1.9 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.

4.4.11.2.1.10 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).

4.4.11.2.1.11 Extraction en-tête

On extrait l'en-tête de la missive afin de permettre les vérifications suivantes.


4.4.11.2.1.11.1 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.

4.4.11.2.1.11.2 Vérification champ Rcv

Le champ Rcv contient au moins :

• un identifiant de l'adhérent SEPAmail (BIC ou code entité SCHEME) ou d’un participant SEPAmail si l’adhérent est multi-participants

• et, selon le message transporté, une adresse de messagerie SEPAmail (QXBAN)

4.4.11.2.1.12 Acquittement

L'acquittement fait l'objet d'une émission de missive avec des règles qui ont été définies plus haut.

4.4.11.2.1.13 Routage interne de la missive

La missive est routée vers l'application du PSP ou le dispositif technique lié à l'écosystème SEPAmail concerné.

4.4.11.2.2 Réception d'une missive d'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.

4.4.11.2.2.1 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 ?

4.4.11.2.2.2 Routage interne de la missive vers le SI

La missive est routée vers l'application du PSP ou le dispositif technique lié à l'écosystème SEPAmail si la logique du SI du PSP le nécessite.


4.4.11.2.3 Émission d'une missive nominale

4.4.11.2.3.1 Récupération ordre émission/information

Une missive nominale est émise sur ordre d'émission d'une application du PSP.

La missive peut être récupérée telle quelle, auquel cas elle est vérifiée avant signature/chiffrement et envoi.

La missive peut être construite par l'automate.

Dans les deux cas, les vérifications suivantes sont réalisées.


4.4.11.2.3.2 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.

4.4.11.2.3.3 Vérification de l'écosystème

L'écosystème peut-être déduit du message contenu dans la missive ou transmis par l'application du PSP (souhaitable). Ce doit être un écosystème géré par le réseau SEPAmail, appartenant à ecosystem@scheme.

4.4.11.2.3.4 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.

4.4.11.2.3.5 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é.

4.4.11.2.3.6 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.

4.4.11.2.3.7 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.

4.4.11.2.3.8 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.

4.4.11.2.3.9 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é.

4.4.11.2.3.10 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.


4.4.11.2.3.11 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).

4.4.11.2.3.12 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.

4.4.11.2.3.13 Chiffrement

Le chiffrement de la missive est réalisé à l'aide de la clé publique de chiffrement du destinataire.

4.4.11.2.3.14 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.

4.4.11.2.3.15 Envoi selon priorité

La priorité de la missive est reprise pour le transport

4.4.11.2.4 Émission d'une missive d'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.


4.5 IG missive • These implementation rules shall be applied in accordance with ISO 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 ISO messages.

• for an explanation of the colour coding used in the tables below, see the related paragraph • for general rules applying to all fields, see the related paragraph

4.5.1 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.

4.5.2 Internal abstraction level 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

4.5.3 Missive Identification 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 The missive identifier MUST be unique for a given sender, except for acknowledgement missives.

A sender of a missive is identified by the two XML tags <Snd><BIC> and <Snd><IBAN> of the missive header (see below the definition of missive header).

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. 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". For an acknowledgement missive, the priority will be the one of the missive it acknowledges.

4.5.4 Missive header The header contains elements about the routing of the missive. It is mandatory in every missive, regardless of its type.




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 must be used instead of 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 client. 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 must be used instead of 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

4.5.5 Acknowledgement element 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

4.5.5.1 Use of the acknowledgement missive

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.

The missive identifier and rank, in the missive header, must match exactly those of the nominal missive it acknowledges.

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.

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.


A full list of allowed return codes is available below



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. The only allowed value is : BAD_TIME: sending time is slightly incorrect

A6.7.2 [0..1] +++ Descr Human-readable explanation and details.

4.5.6 Service element 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.




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.

4.5.7 Missive body 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.



A8 [0..1] + MsvBdy Can be any type of SEPAmail message

4.5.8 Missive signature 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.


4.6 Missive de service Le fonctionnement standard de la messagerie SEPAmail repose sur 2 types de missives :

• La missive nominale qui permet l’envoi des données • La missive d’acquittement, systématiquement envoyé par le destinataire pour toute réception de

missive nominale En communautaire, ces 2 missives suffisent amplement car chaque adhérent a une obligation d’être toujours (24/24 – 7/7) à l’écoute en réception.

SEPAmail est une norme qui a vocation à être utilisée avec les entreprises, et il est apparu pendant l’expérimentation qu’il était difficile d’imposer aux entreprises d’être toujours en écoute. Pour contourner cette contrainte et permettre une utilisation de la norme SEPAmail dans un contexte autre que communautaire, la missive de service a été créée.

La missive de service permet à une entreprise d’être systématiquement à l’initiative de la connexion avec l’adhérent, que ce soit pour l’envoi des missives nominales ou d'acquittement (cas identique à celui de l’espace communautaire interAdhérents) mais aussi pour la réception de missives (nominales ou acquittement).

Comme tous les éléments de la relation entre un adhérent et ses clients, l’utilisation et la mise en œuvre de cette missive est facultative.


4.7 Horodatage des missives L'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 5.3.3

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 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

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.


4.8 IG missive returnCodes

4.8.1 Annex: return codes for the acknowledgement missive Toute missive nominale reçue doit être acquittée sauf dans les cas listés ci-dessous :

- le déchiffrement de la missive est impossible

- la donnée MissiveId (balise A1) n'est pas renseignée

Une missive nominale peut également ne pas être acquittée lorsqu'un virus a été détecté par l'Adhérent l'ayant reçue.

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 indicates success

Class 5 indicates an error

The full list of codes appears in the following table.

Code Description

Subject addresses

5.1.1 Unknown BIC sender

5.1.2 Unknown BIC receiver

2.1.9 Missive well received

Subject mailbox

5.2.3 Missive too long

Subject system

5.3.3 Sending date+time incorrect, and outside of the margin. (Missive has not been handled).

Subject Security and cryptography

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


Code Description

5.8.4 Identification error

If the missive identifier and the missive order of the nominal missive are the same than a previous nominal missive received during past year

OR

If the missive order is 0. In this case, and only in this case, the order of the acknowledgment missive can and must be 0.

OR

If the missive order is more than the maximum number of sending of a same nominal missive.

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.

Rappel : Une missive nominale doit faire l'objet d'un et un seul acquitement.

Dans le cas où plusieurs raisons justifient d'acquiter négativement une missive, il n'y a pas de règles de priorité obligeant l'utilisation d'un code plutôt qu'un autre dans l'acquittement négatif.

4.9 IG message • 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

4.9.1 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).


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.



[1..1] sepamail_message_001 First version of the message structure

4.9.3 Message Header The message header contains information required for the processing of the entire message.



A [1..1] ++ MsgHdr

A1 [1..1] +++ MsgId The message identifier MUST be unique for a given sender.

A sender of a message is identified by the two XML tags <Snd><BIC> and <Snd><IBAN> of the missive header (see above the definition of missive header).

A2 [1..1] +++ MsgTyp The general form is “message@ecosystem”. See each message IG .

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.

4.9.4 Message Body The message body depends on the type of message, as defined in the MsgTyp element. At this level, it contains only one element.



B [1..1] ++ MsgBdy Can be any of the messages belonging to the SEPAmail system : payment.activation_ActivationRequest, direct.debit_MAndateAcceptanceReport ...


4.10 SMIRK MES1102, le message dans le réseau communautaire

4.10.1 Introduction et généralités Le message SEPAmail est l'information élémentaire transmise.

Dans l'espace coopératif communautaire, 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, 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é (Cf. SMIRK APP1103).

4.10.2 Les principes

4.10.2.1 Non confidentialité

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 du PSP s'entend : le PSP 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.

4.10.2.2 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.

4.10.2.3 Structuration de l'information

Le message SEPAmail répond aux règles suivantes :

• Il est typé (ActivationRequest, MandateAcceptanceReport ...). • 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.

4.10.2.4 Nommage du type

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.


4.10.2.5 É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.

4.10.2.6 Complétude de l'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.

4.10.2.7 Durée de validité du message

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)

4.10.2.8 Le dialogue « Question/Réponse » au cœur de l'échange SEPAmail

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, la modélisation des échanges préfère le « Question/Réponse » simple et sobre.

4.10.3 Le contenu 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

4.10.3.1 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...)

4.10.3.2 Le corps

Le corps du message dépend du type de message.

Il existe un schéma XML pour chaque type de message

4.10.3.3 Les pièces jointes (incluses dans le corps du message)

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.


4.11 SMIRK APP1103, l'application SEPAmail Cette demande de commentaires (SMIRK) spécifie la structuration spécifique d'un dialogue de messages SEPAmail (SMIRK MES110224) : l'application SEPAmail.

4.11.1 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.

4.11.2 Les principes

4.11.2.1 La fonctionnalité métier

C'est une fonctionnalité métier, 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.

4.11.2.2 Le nommage de la famille

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.

4.11.2.3 Les messages

Le message est obligatoirement conforme à la SMIRK MES1102.

4.11.2.4 Le dialogue

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.

4.11.2.5 La vue statutaire de l'application

Il y a des messages qui :


• 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.

4.11.2.6 L'utilisateur de l'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.

4.11.2.7 Le contenu

Une application est définie par :

• un nom, • un objectif d'échange 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.


4.11.2.8 Application au cœur de l'architecture de SEPAmail

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.

DIAMOND

API API

DIAMOND


4.12 Caractéristiques des fichiers CSV échangés Les Référentiels communs nécessaires aux Applications des Adhérents, au routage par exemple, et les élements Statistiques de fonctionnement sont échangés dans des fichiers structurés au format informatique ouvert dit « CSV » (Comma-separated values).

L’ensemble des fichiers échangés entre les Adhérents au SCHEME SEPAmail et le SCHEME MANAGER présentent les caractéristiques suivantes :

• La ligne d’entête décrivant les noms des champs est obligatoire. • Le jeu de caractères utilisé est le jeu ISO-8859-15 permettant de prendre en charge l’ensemble

des caractères des langues européennes à l’exception des alphabets grec et cyrillique. • Les fins d’enregistrement sont déterminées par la séquence

o Retour-chariot (caractère codé par la valeur hexadécimale 0x0D) o Nouvelle-ligne (caractère codé par la valeur hexadécimale 0x0A)

• Les champs sont délimités par des guillemets droits doubles (caractères codés par la valeur hexadécimale 0x22).

• Le séparateur décimal est le point (caractère codé par la valeur hexadécimale 0x2E). • Dans le cas de présence d’un délimiteur de champ au sein d’une valeur, ce délimiteur est

doublé afin de lever toute ambiguïté o Ainsi la valeur :

Lieu-dit du "bois-joli"

o Sera convertie comme suit : "Lieu-dit du ""bois-joli"""

• Au sein d’un enregistrement, les champs sont séparés par des points-virgules (caractères codés par la valeur hexadécimale 0x3B)


5 Les Référentiels SEPAmail 5.1 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.

5.1.1 La gestion des référentiels Certains référentiels sont gérés globalement par le SCHEME Manager qui assure la synchronisation des informations communes à tous les acteurs SEPAmail.

Les référentiels fonctionnels sont échangés sous forme de fichiers CSV entre les Adhérents au SCHEME SEPAmail et le SCHEME MANAGER.

Deux ensembles distincts de référentiels sont gérés :

• Un, dit de production, pour la gestion des flux opérationnels • Un, dit de test, destiné à permettre aux Adhérents

o de tester leurs procédures de mises à jour et de prise en compte des référentiels.

o d’effectuer les tests de conformité avec le SCHEME MANAGER o d’effectuer les tests inter-Adhérents

D’autres référentiels sont purement locaux à chaque adhérent SEPAmail, qui en assure individuellement la gestion, indépendamment des autres acteurs.

5.1.2 Le nommage des référentiels SEPAmail 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


5.2 Référentiel « ecosystem@scheme »

5.2.1 Définition 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. Ce référentiel a pour vocation de décrire l’ensemble des écosystèmes relatifs au SCHEME SEPAmail.

5.2.2 Structure Les noms de champ suivis d’un astérisque (*) peuvent servir de base à la création d’un index primaire.

Nom du champ Type et contraintes Description

ecosystemId

Donnée obligatoirement renseignée

Chaîne de 35 caractères au maximum.

Identifiant d’un écosystème SEPAmail.

Cet identifiant apparaît dans les adresses <FROM> et <TO> des enveloppes SEPAmail.

ecosystemType Donnée obligatoirement renseignée

Chaîne de 16 caractères au maximum pouvant prendre les valeurs suivantes : - applicative - transverse

Type de l’écosystème.

Description Donnée obligatoirement renseignée


Description littérale de l’écosystème SEPAmail.

sepamailMessage (*) Donnée obligatoirement renseignée


Identifiant d’un des messages SEPAmail attaché à l’écosystème.

Chaque message est donc l’objet d’un enregistrement distinct au sein du fichier CSV.

Plusieurs enregistrements peuvent donc concerner un même écosystème.

5.2.3 Cycle de vie Ce référentiel est directement alimenté par le SCHEME MANAGER sur la base écosystèmes définis dans la Norme SEPAmail.


5.3 Référentiel « member@scheme »

5.3.1 Définition Ce référentiel a pour vocation de décrire l’ensemble des Adhérents au SCHEME SEPAmail.

5.3.2 Structure Les noms de champ suivis d’un astérisque (*) peuvent servir de base à la création d’un index primaire.


legalMemberBic Donnée obligatoirement renseignée

Chaîne de caractères respectant l’expression régulière suivante : [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}

Identifiant BIC, formaté avec onze caractères, de l’Adhérent au SCHEME SEPAmail.

SPI Donnée obligatoirement renseignée

Chaîne de caractères respectant l’expression régulière suivante :

[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}

Identifiant BIC permettant de déterminer l’adresse de l’Infrastructure en charge du traitement des flux SEPAmail.


SPIDescription Donnée obligatoirement renseignée

Chaîne de 70 caractères au maximum

Description littérale de l’Infrastructure de traitement des flux SEPAmail.

sepamailCommunityId (*) Donnée obligatoirement renseignée


Identifiant de la Communauté SEPAmail à laquelle appartient l’Adhérent au SCHEME SEPAmail.

La seule Communauté SEPAmail actuellement référencée est identifiée par la valeur :

sepamail.eu

sepamailCommunityDescription Donnée obligatoirement renseignée


Description littérale de la Communauté SEPAmail à laquelle appartient l’Adhérent au SCHEME SEPAmail.

5.3.3 Cycle de vie Ce référentiel est directement alimenté par le SCHEME MANAGER sur la base des demandes de mise à jour envoyées par les Adhérents :

� Création � Suppression � Modifications � …


5.4 Référentiel « bic.message@scheme »

5.4.1 Définition Ce référentiel a pour vocation de décrire l’ensemble des Participants joignables au travers de la messagerie SEPAmail et des Infrastructures de traitement qui en assurent la prise en charge. Il permet de calculer l’infrastructure de traitement destinataire d’un message en fonction du type de message et du Participant destinataire.

5.4.2 Structure La structure des fichiers de déclaration par les Adhérents est strictement identique à celle du fichier utilisé pour la diffusion par le SCHEME MANAGER du référentiel consolidé.

Les noms de champ suivis d’un astérisque (*) peuvent servir de base à la création d’un index primaire.


internalRouteBic (*) Donnée obligatoirement renseignée


Identifiant BIC, formaté à onze caractères, et description littérale d’une entité routable pouvant recevoir des flux SEPAmail au travers de l’Infrastructure de traitement des flux SEPAmail.

Plusieurs enregistrements peuvent donc concerner une même Infrastructure de traitement.

Message Donnée obligatoirement renseignée

Chaîne de caractères respectant l'expression régulière suivante :

[A-Za-z]{1,35}

Nom d'un message SEPAmail, tel qu'il apparaît dans la Norme (PaymentActivationRequest, SimpleTestReport...)

SPI Donnée obligatoirement renseignée


Identifiant BIC permettant de déterminer l’adresse de l’Infrastructure de réception en charge du traitement du message SEPAmail désigné dans la colonne précédente.


5.4.3 Cycle de vie Chaque Adhérent déclare les entités routables prises en charge par chacune de ses Infrastructures de traitement au travers de ce fichier CSV qu’il adresse au SCHEME MANAGER.

Ce transfert intervient à chaque modification des entités routables (ajout, suppression, modification) et comprend systématiquement l’ensemble des informations concernées.

Le SCHEME MANAGER consolide les déclarations des différents Adhérents en vue de la publication du fichier global.


5.5 Référentiel « icqx@scheme »

5.5.1 Définition Le référentiel des ICQX « icqx@scheme » est maintenu par le Scheme.

Ce référentiel a pour vocation de décrire l’ensemble des créanciers, agissant en tant que personne morale, référencés auprès du SCHEME Manager. Par extension, ce référentiel peut être amené à décrire également certaines personnes morales en tant que débiteurs (e.g. entreprises émettant des requêtes DIAMOND). Les créanciers, agissant en tant que personne physique, ne sont inscrits dans aucun référentiel.

Chaque PSP 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.

Ce référentiel est mis à jour à l'initiative du PSP du créancier, à la demande de ce dernier, 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 est transmise par l'adhérent SEPAmail dont dépend le créancier, et est faite sous la responsabilité de cet Adhérent.

L'ICQX est attribué par le SCHEME Manager et 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 PSP ...). 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.

5.5.2 Inscription à un service Lorsqu'un créancier est présent dans le référentiel, il peut demander son inscription à un ou plusieurs services.

Le référentiel « icqx@scheme » recense les services attribués à chaque créancier ainsi que la période de validité de cette attribution.

Le seul service pouvant actuellement faire l’objet d’une inscription est « RUBIS inscription ».

5.5.3 Structure La structure des fichiers de déclaration par les Adhérents est strictement identique à celle du fichier utilisé par le SCHEME MANAGER pour la diffusion du référentiel consolidé.

Chaque ICQX peut être de plus accompagné d’un ou plusieurs fichiers graphiques :

• logo, • vignette • texte d’aide

Les noms de champ suivis d’un astérisque (*) peuvent servir de base à la création d’un index primaire.



Icqx (*) Donnée pouvant être non renseignée (cf. remarque 1)

Chaîne de 35 caractères au maximum et respectant l’expression régulière suivante : QX[0-9]{2,2}[A-Z]{2,2}[a-zA-Z0-9]{7,29}

Identifiant d’un créancier enregistré par le SCHEME MANAGER au sein de la Communauté sepamail.eu.

validFrom Donnée obligatoirement renseignée. Le SCHEME MANAGER vérifie au moment du traitement du fichier que la date renseignée n’est pas antérieure de plus de cinq jours à la date courante et rejette le fichier dans le cas contraire.

Date au format ISO YYYY-MM-DD

Date de début et de fin de validité de l’identifiant créancier au sein de la Communauté sepamail.eu.

validTo Donnée obligatoirement renseignée si la date de fin de validité est connue. La date ValidTo doit être supérieure à la date ValidFrom.


partyName Donnée obligatoirement renseignée


Appellation juridique du créancier

displayName Donnée obligatoirement renseignée


Nom courant du créancier

AdrLine1 Donnée obligatoirement renseignée


Deux lignes d’adresse du siège du créancier

AdrLine2 Donnée pouvant être non renseignée


PstCd Donnée obligatoirement renseignée


Code Postal du siège du créancier

TwnNm Donnée obligatoirement renseignée


Ville du siège du créancier

Ctry Donnée obligatoirement renseignée

Chaîne de deux caractères correspondant à un code pays ISO

Pays du siège du créancier

APE Donnée obligatoirement renseignée

Chaîne de 16 caractères au maximum. Seul le code APE NAF 2008 est utilisable

Code APE du créancier

SIREN Donnée pouvant être non renseignée (cf. remarque 2)


Code SIREN du créancier

SIRET Donnée pouvant être non renseignée (cf. remarque 2)


Code SIRET du créancier



IntraComVAT Donnée pouvant être non renseignée (cf. remarque 2)


Code de TVA intra-communautaire du créancier

Other Donnée pouvant être non renseignée (cf. remarque 2)

Chaîne de 35 caractères au maximum respectant l’expression régulière suivante : [a-zA-Z0-9]+:[a-zA-Z0-9]+

Autre identifiant du créancier composé : - d’un type - d’une valeur Les deux éléments sont séparés par un double point

updatedAt Donnée pouvant être non renseignée (cf. remarque 1)


Date de mise à jour des informations du créancier

updatedBy Donnée pouvant être non renseignée (cf. remarque 1)


Identifiant de l’Infrastructure de traitement de l’Adhérent au SCHEME SEPAmail.eu à l’origine de la mise à jour.

activeForRubisExcRegistr Donnée obligatoirement renseignée

Booléen pouvant prendre les valeurs suivantes : - true - false

Indique si le créancier est actif pour le service RubisExcRegistr

globalForRubisExcRegistr Donnée obligatoirement et exclusivement renseignée si le créancier est actif pour le service RubisExcRegistr.

Booléen pouvant prendre les valeurs suivantes : - true - false

Indique si la portée est globale ou locale pour le service RubisExcRegistr

QxbanForRubisExcRegistr Donnée obligatoirement et exclusivement renseignée si le créancier est actif pour le service RubisExcRegistr

Chaîne de caractères respectant l’expression régulière suivante : QX[0-9]{2,2}[a-zA-Z0-9]{1,30}

QXBAN devant être utilisé pour le service RubisExcRegistr

CustomerReferenceLabelForRubisExcRegistr

Donnée obligatoirement et exclusivement renseignée si le créancier est actif pour le service RubisExcRegistr


Intitulé de la référence du client

CustomerReferenceHelpForRubisExcRegistr

Donnée obligatoirement et exclusivement renseignée si le créancier est actif pour le service RubisExcRegistr


Texte d’aide associé à la référence du client

RubisExcRegistrUpdatedAt Donnée obligatoirement et exclusivement renseignée si le créancier est actif pour le service RubisExcRegistr


Date de mise à jour des informations pour le service RubisExcRegistr.



RubisExcRegistrUpdatedBy Donnée obligatoirement et exclusivement renseignée si le créancier est actif pour le service RubisExcRegistr


Identifiant (formaté avec onze caractères) de l’Infrastructure de traitement de l’Adhérent au SCHEME SEPAmail.eu à l’origine de la mise à jour des informations pour le service RubisExcRegistr.

Remarque 1 : Certaines données ne peuvent être renseignées que par le SCHEME MANAGER

Remarque 2 : Le créancier doit être obligatoirement identifié par le renseignement d’au moins une des balises suivantes :

� SIREN � SIRET � IntraComVAT � Other

Les identifiants SIRET et SIREN ne peuvent coexister au sein d’une même déclaration.

Le fichier CSV transmis par un Adhérent pour la déclaration de création ou de modification d'un ICQX est de type incrémental (seuls les ICQX nouveaux ou modifiés sont présents).

� Dans le cas d'une création, le champ ICQX n'est pas renseigné. � Dans le cas d'une modification, par exemple inscription à un service, le champ ICQX

est renseigné ainsi que toutes les autres informations, modifiées ou non. � Dans tous les cas, les informations de mise à jour (date et BIC de l'Adhérent

d'origine) ne doivent pas être renseignées. � Les champs d’identification de la demande d’ICQX (APE, SIREN, SIRET,

IntraComVAT, QXBAN) ne doivent pas présenter de formatage particulier incluant des espaces intermédiaires destinés à faciliter la lecture ou la saisie. Le SCHEME MANAGER supprimera les éventuels espaces intermédiaire avant enregistrement des données de la demande de façon à ce que la diffusion ultérieure du référentiel ne fasse pas apparaître d’espaces au sein de ces identifiants

Parallèlement, l’Adhérent peut transmettre au SCHEME MANAGER une liste de fichiers graphiques optionnels (logo, vignette, image d’aide).

Le fichier CSV de réponse du SCHEME MANAGER à l’Adhérent reprend le fichier transmis par ce dernier en appliquant les modifications suivantes :

� les ICQX effectivement créés sont renseignés � les informations de mise à jour (date, BIC de l'Adhérent d'origine) sont complétées

Le SCHEME MANAGER intègre et consolide les données en vue de la publication du fichier global. Le fichier CSV transmis pour la diffusion du référentiel par le SCHEME MANAGER à l'ensemble des Adhérents au SCHEME SEPAmail comprend l’ensemble des informations des créanciers référencés.

Parallèlement, le SCHEME MANAGER diffuse pour chacun des créanciers référencés la liste de fichiers graphiques qu’il a pu obtenir.

5.6 Référentiel « qxban@bic » Chacun des PSP adhérents SEPAmail doit mettre en œuvre un référentiel des QXBAN de ses clients. Étant à la main du PSP, 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 chacun des PSP de mettre en œuvre pour tout nouveau client la génération de son QXBAN selon l'algorithme du Scheme.


5.7 Les Référentiels externes

5.7.1 La nomenclature des BICS Standard BIC (ISO 9362)

5.7.2 La nomenclature des ICS (Externe par pays, Banque de France pour la France)

5.7.3 Les nomenclatures officielles gé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)


6 Les Statistiques SEPAmail Les Adhérents transmettent leurs statistiques de fonctionnement, au SCHEME Manager, sur la base de fichiers CSV.

Ces statistiques sont de deux sortes :

• des statistiques de niveau "missive" • des statistiques de niveau "message"

Les statistiques devant être remontées au SCHEME MANAGER par les adhérents au SCHEME concernent les flux inter-adhérents mais également les flux intra-adhérent (= les flux échangés entre deux Participants d’un même Adhérent et les flux intra-Participant) dès lors que la messagerie SEPAmail a été utilisée et que les BIC émetteur et destinataire sont tous les deux dans le référentiel BIC.MESSAGE@SCHEME.

6.1 Gestion des statistiques

6.1.1 Envoi des statistiques par les Adhérents Deux fichiers permettront de consolider sur l’ensemble du mois échu :

• Les statistiques de niveau missive • Les statistiques de niveau message

6.1.2 Principes gé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.


6.2 Statistiques sur les missives 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.


date YYYY-MM-DD (ISO8601) Ceci doit correspondre à la partie date de la balise SndDtTm de la missive

flow Énumération "Sending" ou "Receiving"

reportingSPI Chaîne de caractères respectant l’expression régulière suivante : [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}{0,1}

BIC de l’Infrastructure (SPI) produisant la donnée statistique

senderBIC Chaîne de caractères respectant l’expression régulière suivante : [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}

BIC indiqué dans le balise <Snd><BIC> de la missive (que ce soit pour les messages en réception ou en émission)

receiverBIC Chaîne de caractères respectant l’expression régulière suivante : [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}

BIC indiqué dans le balise <Rcv><BIC> de la missive (que ce soit pour les messages en réception ou en émission)

type Énumération Type de missive, "Nominal" ou "Acknowledgement"

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. (class.subject.detail)

priority Énumération Peut prendre 5 valeurs : HIGHEST, HIGH, NORMAL, LOW, LOWEST

mode Énumération 2 valeurs possibles : "Canonical" et "Flash"

missivesCount Entier Total du nombre de missives concernées

volume Entier total du volume de ces missives (en k-octets), pièces jointes comprises, mais sans prendre en compte l'enveloppe S/MIME


6.3 Statistiques sur les messages Contrairement aux autres statistiques, celles-ci ne doivent être réalisées que pour les missives nominales ayant fait l’objet d’un acquittement positif (champ A6.1, AcqSta, de la missive d'acquittement, valant "ACK") par le destinataire.

Nota Bene : Les acquittements à prende en compte sont les acquittements reçus au cours du mois ainsi que les acquittements reçus au cours des deux premiers jours du mois suivant, de manière à ce que les missives nominales émises en fin de mois et acquittées positivement au début du mois suivant soient prises en compte.


date YYYY-MM-DD (ISO8601) Ceci doit correspondre à la partie date de la balise SndDtTm de la missive

flow Énumération " Sending " ou "Receiving"

reportingSPI Chaîne de caractères respectant l’expression régulière suivante : [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}

BIC de l’Infrastructure (SPI) produisant la donnée statistique

senderBIC Chaîne de caractères respectant l’expression régulière suivante : [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}

BIC indiqué dans le balise <Snd><BIC> de la missive transportant le message (que ce soit pour les messages en réception ou en émission)

receiverBIC Chaîne de caractères respectant l’expression régulière suivante : [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9][A-Z0-9]{3,3}

BIC indiqué dans le balise <Rcv><BIC> de la missive transportant le message (que ce soit pour les messages en réception ou en émission)

version Entier sur 4 chiffres Version de SEPAmail utilisée par le message.

ecosystem Énumération Écosystème auquel le message appartient

messageType Énumération Type du message dans son écosystème.



returnCode Chaîne Cette donnée n’est à alimenter que pour les messages suivants :

• Application AIGUE-MARINE :

o AccountSwitchingResponse traduisant un refus de la demande (i.e. avec la balise 2.1 AccountSwitchingRefusal instanciée)

o AccountSwitchingNotify traduisant un refus de la demande (i.e. avec la balise 2.1 AccountSwitchingRefusal instanciée)

o AccountSwitchingNotify traduisant une acceptation de la demande (i.e. avec la balise 2.1 AccountSwitchingConfirmation instanciée)

• Application RUBIS :

o PaymentActivationReport

• Application DIAMOND :

o VerificationReport traduisant un rejet de la demande (i.e. avec la balise 3.3 Reason instanciée)

Les règles d’alimentation de cette donnée sont les suivantes :

• Pour les messages de type AccountSwitchingResponse traduisant un refus de la demande, cette donnée est à alimenter avec la valeur de la balise 2.3 AccountSwitchingRefusal/Reason/Code (ou 2.4 AccountSwitchingRefusal/Reason/Proprietary si 2.3 non renseigné)

• Pour les messages de type AccountSwitchingNotify traduisant un refus de la demande, cette donnée est à alimenter avec la valeur de la balise 2.3 AccountSwitchingRefusal/Reason/Code

• Pour les messages de type AccountSwitchingNotify traduisant une acceptation de la demande, cette donnée est à alimenter avec la valeur de la balise 2.3 AccountSwitchingConfirmation/Reason/Code

• Pour les messages de type PaymentActivationReport, cette donnée est à alimenter avec la valeur de la balise 3.19 TransactionStatus

• Pour les messages de type VerificationReport (DIAMOND) traduisant un rejet de la demande, cette donnée est à alimenter avec la valeur de la balise 3.4 Verification/Reason/Code

• Pour les autres messages, cette donnée doit rester vide (aucun caractère entre les deux ;) :

- Application AIGUE-MARINE : AccountSwitchingRequest, AccountSwitchingResponse positif, AccountSwitchingForward

- Application DIAMOND : VerificationRequest, VerificationReport (DIAMOND) traduisant une acceptation de la demande (i.e. avec la balise 3.3 Reason non instanciée)

- Application RUBIS : PaymentActivationRequest

transactionsCount Entier Nombre de messages

transactionsAmount Réel Ne concerne que l'application RUBIS

Si le message est de type PaymentActivationRequest : Somme des valeurs indiquées dans la balise 2.36 InstructedAmount des messages (somme des montants des demandes de règlement)

Si le message est de type PaymentActivationReport : Somme des valeurs indiquées dans la balise B2.5.2 Amount (ou 3.35 InstructedAmount, si la balise B2.5.2 n'est pas présente) des messages ayant un statut (balise 3.19 TransactionStatus) égal à ACSP ou ACWC (somme des montants acceptés par les débiteurs).

NB : les éventuels cas de DDR acceptées plusieurs fois (exemple : acceptation puis refus puis acceptation) ne seront pas comptabilisés différemment. Ils sont jugés trop peu fréquents pour influencer sensiblement les chiffres.

attachmentsCount Entier Ne concerne que l’application RUBIS.

Total du nombre de pièces jointes à ces messages


7 L'application RUBIS RUBIS 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.

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é".

7.1 Les principes généraux (RUBIS)

7.1.1 Contexte d’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.

7.1.2 Un service complet RUBIS comporte trois composantes majeures :


• un service d'inscription auprès des facturiers qui utilisent RUBIS o 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é

o 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.

o ce service, ainsi que le référentiel, n'est pas disponible pour les règlements occasionnels de particuliers à particuliers ou avec des entreprises

• une transmission électronique des demandes de règlements comportant un message XML et de façon optionnelle, un fichier PDF

o directement émis par le créancier (celui-ci peut être un particulier, un facturier ou une entreprise) à son propre PSP

o mis à disposition du débiteur (particulier ou entreprise) par son propre PSP et permettant ainsi une validation électronique authentifiée par le PSP du débiteur

o un message de confirmation dès lors que la validation est effective • un virement SEPA (SCT) envoyé au PSP du créancier

o avec une copie à l'identique des éléments fondamentaux de la demande de règlement initiale

o 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.


7.2 Les avantages pour le client (RUBIS)

7.2.1 Pour le créancier • la relation commerciale et de confiance maintenue avec son PSP • 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.

7.2.2 Pour le débiteur • la relation commerciale et de confiance maintenue avec son PSP • 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 son PSP, 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 : o par une protection de ses coordonnées bancaires car il ne diffuse qu'un alias d'IBAN o 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.


7.3 Cas d'usage (RUBIS) RUBIS peut potentiellement prendre en compte de nombreux cas d'usage bien au-delà de sa cible initiale.

7.3.1 Cœur de cible RUBIS RUBIS a été conçu pour répondre au besoin exprimé du Ministère des Finances d'un moyen de paiement à la main du client. RUBIS a pour vocation de remplacer le chèque ou le TIP dans deux cas d'usage :

• le paiement de factures, quittances,... présentant une certaine régularité, pour les personnes, morales ou physiques, pour qui le prélèvement ne peut pas convenir

• le transfert de fonds entre particuliers, qui mobilise à ce jour plus le chèque que le virement, compte tenu de la complexité de saisir des IBAN sur une banque en ligne.

7.3.2 RUBIS pour les flux urgents Le virement étant par nature du système SCT à au moins 1 jour, l'immédiateté de mise à disposition des fonds n'est pas native dans RUBIS. L'application RUBIS n'est donc pas disponible en l'état pour des flux urgents et nécessiterait, en tout cas, un accord explicite préalable des PSP participants.

Il est cependant possible d'imaginer une future version de RUBIS ou l'immédiateté est atteinte, non pas au travers de l'accélération du virement, mais dans le traitement de la réponse après validation du client : cette réponse pourrait avoir valeur de transfert auprès du PSP du créancier. Ceci est possible dès aujourd'hui dans les messages RUBIS. Il serait néanmoins nécessaire

• de mettre en place des règles particulières entre PSP sur ce sujet • que chaque PSP de débiteur définisse un système de gestion du risque entre une réponse

immédiate et un virement décalé : serveur d'autorisation comme pour la monétique ? comptabilité temps réel ? réservation préalable des fonds ? voire un mix de ces solutions.

Ce point serait similaire à l'utilisation du système monétique ou le flux d'autorisation est considéré comme assurance de paiement alors que le flux effectif de compensation interviendra plus tard, avec une vitesse similaire à celle du virement.

7.3.3 Commerce électronique Le commerce électronique met en évidence des besoins multiples :


• une sécurité des paiements • une ergonomie simple pour pallier l'absence d'humains • une vitesse du paiement ou d'assurance du paiement (voir paragraphe précédent) lorsque la

livraison doit être déclenchée très rapidement (vente d'information ou de logiciels) • de multiples cas d'interactions avec le client : centre d'appel, web, smartphone.

Le positionnement de RUBIS sur le commerce électronique se base sur :

• une interaction à la main du client pour la mise en relation : 1. inscription préalable du client-débiteur sur le site de commerce électronique

2. une transmission en direct du RIS2D (format code-à-barre du QXBAN)

• une validation au travers de sa propre banque à distance (ou de l'application smartphone de son PSP) pour la validation du paiement

Schéma comparatif entre le paiement par carte et le paiement RUBIS en e-commerce.

L'inscription préalable a pour avantage de permettre l'utilisation du canal "centre d'appel" ensuite, et présente une limite d'utilisation pour les achats "compulsifs". Pour ces derniers, la nécessaire transmission du QXBAN (30 caractères) ou du RIS2D limite fortement cette compulsivité.

7.3.4 Paiements de niches RUBIS pourrait résoudre aussi des paiements complexes tels que :

• paiement contre livraison, souvent appelé au cul du camion, paiements qui posent de nombreux soucis en inter-entreprises

• paiements fléchés, c'est-à-dire mettant en œuvre des contrôles très spécifiques (réseau de santé par exemple)

• frais professionnels avec transfert directement à la comptabilité de l'entreprise des factures


7.3.5 Paiement de billet électronique RUBIS, couplé avec une application d'envoi de billet électronique (message secure ou message dédié) peut permettre une automatisation complète de ce cas de vente.

• Les flux de 1 à 5 sont les flux de base de RUBIS

• à l'arrivée du flux 5, le vendeur de billet peut à son tour envoyer un billet électronique sous forme de code-à-barres pour une lecture simplifiée par exemple, ou un PDF imprimable directement de manière sécurisée (flux 6, 7, 8)


7.3.6 L'ardoise électronique en commerce de proximité utilisable par un tiers

Le concept ci-dessous reprend le principe d'ardoise sur la base des services RUBIS.

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'un PSP à créer des nouveaux services compétitifs indépendamment des autres PSP.


7.4 La gestion des inscriptions des débiteurs 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.

7.4.1 Constitution du référentiel RUBIS 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 PSP.

L'inscription auprès d'un PSP 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, un PSP 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 PSP, 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 :


• le créancier demande l'activation du service RUBIS inscription selon la procédure définie par

son PSP (puce 1). Cette procédure peut être manuelle ou électronique et/ou basée sur les messages d'un écosystème SEPAmail (secure ou scheme, par exemples). Cette phase suppose que le créancier dispose d'un ICQX, et donc qu'il ait déjà été créé au niveau du Scheme.

• Le PSP du créancier DOIT valider les éléments remis par le créancier, en particulier la validité de l'ICQX, des images et logos transmis (puce 2).

• Une fois la validation effectuée, le PSP du créancier informe les autres PSP et le Scheme Manager de cette nouvelle entrée dans le référentiel RUBIS (puce 3). Cette information se fait grâce au message CreditorActivationAdvise de la famille scheme.

• Le PSP du créancier attend les accusés de réception des différents PSP et peut informer son créancier de la finalisation de la diffusion (puce 4).

7.4.2 Partage du référentiel RUBIS Le référentiel RUBIS est partagé entre les PSP au travers de messages spécifiques de l'écosystème scheme dédiés au référentiel icqx@scheme. Tous les adhérents SEPAmail peuvent accéder aux informations concernant un créancier inscrit dans le référentiel icqx@scheme, soit localement, soit à travers le Scheme qui est le gestionnaire du référentiel.

7.4.3 Obligations du PSP du débiteur concernant le service d'inscription RUBIS

Chaque PSP de débiteur adhérent à RUBIS doit mettre en place les fonctions nécessaires :

• à la présentation du référentiel RUBIS auprès des débiteurs sur au moins un canal (la banque en ligne est à privilégier)

• à offrir la capacité aux débiteurs de s’inscrire auprès d'un créancier pour lui signifier son accord de réception des demandes de règlements par RUBIS. Cette fonction permet l'envoi des coordonnées du débiteur (QXBAN) au moyen du message ActivationEnroll de la famille RUBIS.


Le message d'inscription permet de véhiculer un champ représentant la référence de ce client chez le créancier. En effet, une telle information est nécessaire au créancier, en plus du nom et du prénom qui peuvent avoir une homonymie, pour qu'il puisse affecter le QXBAN reçu à la bonne référence client. Il reste bien sûr à la charge du créancier la vérification de cette affectation.

Pour aider le débiteur à saisir la bonne référence, il a été prévu que le référentiel RUBIS contienne des éléments de communication avec le débiteur, dont au moins une image indiquant où le débiteur peut trouver cette référence.

Deux exemples possibles dans l'image suivante.


Cette image, fournie par le créancier, doit faire l'objet d'un contrôle par le PSP du créancier lors de la demande d'activation du service RUBIS inscription par le créancier.

7.4.4 Désinscription auprès d'un créancier Le même message ActivationEnroll, utilisé pour informer le créancier de l'inscription d'un débiteur, peut aussi servir en cas de désinscription souhaitée de celui-ci. En première analyse, cette fonction, si elle est proposée à un débiteur, doit être couplée avec une gestion adéquate des messages suivants venant de ce créancier. Les règles devront être précisées en fin d'expérimentation.

7.4.5 Gestion souple en l'absence d'inscription préalable du débiteur Lorsqu'un créancier est présent dans le référentiel RUBIS et qu'il émet une demande de règlement vers un débiteur ne s'étant pas inscrit auprès de lui par un message ActivationEnroll, le PSP du débiteur ne doit pas rejeter d'emblée la demande de règlement reçue au seul motif de l'absence du message ActivationEnroll préalable.


7.5 La gestion des flux (RUBIS)

7.5.1 Initiation de la transaction 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.

7.5.2 Circulation des flux entre créancier et débiteur La circulation des flux se fait en respectant le modèle 4 coins : créancier, PSP du créancier, PSP du débiteur, débiteur.


• Envoi de la demande de paiement comportant o 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) o Le montant o Le compte du créancier à créditer o D’éventuelles informations complémentaires sur la livraison des biens ou la mise à

disposition du service • Acceptation par le débiteur en donnant un ordre de règlement à son PSP • Génération d’un message de retour en confirmant l’acceptation par le donneur d’ordre (débiteur) • virement de fonds réalisé par le PSP du débiteur vers le PSP du créancier • Réception des fonds • Contrôle et dénotage du virement, de la confirmation de règlement vis-à-vis de la demande de

règlement émise par le créancier

7.5.3 Le principe de fonctionnement RUBIS Les flux précédents sont mis en œuvre en utilisant la messagerie SEPAmail, ce qui présente le double intérêt :

• sécuriser les flux de demande de règlement et de réponse entre le créancier et le débiteur • articuler ces flux avec ceux liés au virement


• le créancier et le débiteur adhèrent chacun au système auprès de leur PSP respectif o garantissant ainsi l'authentification des acteurs pour le service

• le créancier (futur payé) envoie un message "demande de règlement" au débiteur (payeur o 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

o charge au PSP du débiteur de mettre en œuvre les outils permettant cette validation • le créancier est informé de la validation du débiteur

o suivant les cas cette information peut être de différentes natures : ordre donné à son PSP par le débiteur de procéder au transfert, transfert en exécution, assurance donnée par le PSP du débiteur que le transfert sera réalisé

• le règlement se fait directement entre le PSP du débiteur et le PSP 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 o 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 • le PSP du débiteur envoie les références de dénotage fournies par le créancier

o 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

7.5.4 Les flux entre un créancier et son dé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.


• 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.

• Le PSP du créancier complète avec le BIC et route vers le PSP du débiteur (puce 2) o Le PSP 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, …)

• Le PSP 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 du PSP du débiteur et hors du champ de RUBIS. Le choix du compte du virement est un service pouvant être offert par le PSP du payeur.

• Une fois validé, une confirmation de l’ordre de règlement (payment-report, puce 4) est envoyée au PSP 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.

o une réponse protocolaire SEPAmail est envoyée au PSP du débiteur par le PSP du créancier (puce 4bis)

• Le PSP du créancier route vers le créancier la confirmation (puce 5). • Le PSP 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). • 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 un PSP et son créancier • domaine coopératif SEPAmail entre le PSP du créancier et le PSP du débiteur • domaine concurrentiel entre le PSP du débiteur et le débiteur • domaine coopératif SEPA

7.5.5 Les flux entre deux particuliers 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.



7.6 Les normes utilisées par RUBIS RUBIS fait appel à différents normes et standards existants.

• Normes SEPA, pour les virements SCT • Normes SEPAmail-messagerie, pour les échanges communautaires des flux de demandes de

règlements et d'annuaires • Normes SEPAmail pour l'identification des acteurs au travers du QXBAN • Normes bancaires pour l'identification des acteurs au travers de l'IBAN • Normes SEPAmail-RUBIS pour la structuration des données communautaires • Normes SEPAmail-RUBIS pour la structuration des données dans la relation PSP-client. Bien

que la relation PSP-client soit dans le domaine compétitif, SEPAmail-RUBIS définit un standard principalement à l'usage des entreprises pour éviter à celle-ci l'évolution de leurs systèmes en cas de changement de PSP.

Les normes suivantes sont utilisées :

• SEPAmail - RUBIS ActivationRequest pour la demande initiale et la transmission par le PSP du créancier

• SEPAmail - RUBIS ActivationReport pour la confirmation par le PSP du créancier • PACS 008 si virement effectif


7.7 Le lettrage des virements (RUBIS) La troisième composante de RUBIS, outre le référentiel et la demande de règlement électronique, est la capacité pour un créancier de lettrer en automatique les virements à partir d'une demande RUBIS.

Pour garantir cette composante, le PSP du débiteur a dans l'obligation de respecter les normes RUBIS décrivant le lien entre :

• l'ActivationRequest (comportant un ou plusieurs pain.013) émis par le créancier (puce 1 dans le schéma)

• l'ActivationReport (comportant un ou plusieurs pain.014) renvoyé par le PSP du débiteur (puce 4 dans le schéma)

• le virement SEPA au format pacs.008 (puce 6 dans le schéma)


7.8 Les règles métier (RUBIS)

7.8.1 Objet du document 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).

7.8.2 Présentation générale Le système SEPAmail se compose :

• d’un réseau communautaire 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

7.8.3 Messages de la famille RUBIS 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.

7.8.3.1 Le message de demande de rè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, ...).

7.8.3.2 Le message de réponse à demande de rè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 du PSP 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 le PSP, virement exécuté par le PSP … 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 du PSP du débiteur impose alors que le PSP du créancier soit informé 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.

7.8.3.3 Le message d'inscription au service

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.


7.9 La gestion des refus après acceptation et avant é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 un PSP 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 à son PSP 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, le PSP 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. Le PSP du débiteur devrait prévoir ce point tant dans ses interfaces avec ses clients que dans sa relation contractuelle.

7.10 Le récapitulatif des messages Voici les messages possibles pour RUBIS :

• message SEPAmail Demande de règlement

• message SEPAmail Réponse à demande de règlement

• message SEPAmail Inscription d'un débiteur auprès d'un créancier


7.11 IG payment.activation L'écosystème payment.activation comporte trois messages :

Ecosystem Message MsgTyp

payment.activation PaymentActivationEnroll [email protected]

PaymentActivationReport [email protected]

PaymentActivationRequest [email protected]


7.12 IG Rubis ActivationRequest

• These implementation rules shall be applied: o In accordance, unless explicitly specified, with ISO20022 own implementation rules. o In compliance with the relevant European Regulation, especially regulation related to the credit transfers when data from the Report are

forwarded in a SCT message. • 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 • Each of the IG tables specifies the following items:

o Ref.: Index of the XML element within a message, either based on ISO20022 original index or specified by SEPAmail.eu. This index is used to facilitate the location of the element without having to use the full XPATH.

o Mult.: This indicates how many occurrences of the element can be present within a given message. o Ch.: This indicates that the element is embedded, directly or through one of its ancestors, within one or more CHOICE XML structures. The

count of CHOICE structures is given by the count of "|". Thus, the scope of a CHOICE is materialised by the presence of this character for each child element.

o Depth: This indicates the depth of the element within the XML message. The count of "+" reminds the count of parent-child relationships being used from the root of the message unto the relevant element.

o Message element: This is a simple denomination of the element. o Requirements: This is the list of the requirements that are specified, either by ISO20022 or by SEPAmail.eu, and that must be applied on the

element itself or its children.

7.12.1 Reference 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].

7.12.2 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

7.12.3 Header Ref. Mult. Ch. Depth Message

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 rule

This structure must not be copied into [ /PaymentActivationReport /sepamail_message_payment_activation_report_001 /Header /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 #1606 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).


Ref. Mult. Ch. Depth Message element

Requirements

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 rule language used on the document, 2-letter code

A3.6 [0..1] +++ Contents



Requirements

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 #106 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).

7.12.4 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:



Requirements

B [1..*] + ReqCompl SEPAMAIL rule

Mandatory for SEPAmail

SEPAMAIL rule

In #1606 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

7.12.5 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).

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 #1606 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' (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.

ISO200 2 rule

R5 PaymentTypeInformationRule 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 #1606 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.

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.

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 rule

Date at which the initiating party requests the clearing agent to process the payment. If payment by cheque, the 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 '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.

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

2.17/3.1.8 [0..1] ++++ PostalAddress SEPAMAIL rule


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.

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. Note: The decimal separator is a dot.

ISO20022 rule


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


• 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.

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


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


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 - Other - BranchIdentification

2.63/3.1.0 [1..1] ++++ FinancialInstitution-Identification

ISO20022 rule




2.63/3.1.1 [0..1] +++++ BICFI ISO20022 rule


SEPAMAIL rule


• 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.



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.

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


ISO20022 rule




2.63/3.1.29 [0..1] ++++++ AddressType

ISO20022 rule









2.63/3.1.30 [0..1] ++++++ Department ISO20022 rule


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


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


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




2.63/3.1.37 [0..1] ++++++ Country ISO20022 rule Nation with its own government.

ISO20022 rule


2.63/3.1.38 [0..7] ++++++ AddressLine ISO20022 rule


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.



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


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 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.


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


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


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


2.73/6.1.10 [0..*] +++++ Information ISO20022 rule Additional details that cater for specific dom stic regulatory requirements.

2.74 [0..1] +++ Tax SEPAMAIL rule Not Allowed for SEPAmail

2.75 [0..10] +++ RelatedRemittance-Information


2.82 [0..1] +++ RemittanceInformation ISO20022 rul

Information su plied 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


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


7.12.5.1 Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/GrpHdr/InitgPty element (previously indexed as 1.5)


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









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 rule

Name of a built-up area, with defined boundaries, and a local government.

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


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] | ++ OrganisationIdentification ISO20022 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.

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


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


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.

1.5/4.1.29 [0..1] | ++++ SchemeName ISO20022 rule


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


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.


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


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.

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.

7.12.5.2 Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/Dbtr element (previously indexed as 2.15)


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.2 [0..1] ++ AddressType

ISO20022 rule










2.15/4.1.4 [0..1] ++ SubDepartment ISO20022 rule







2.15/4.1.7 [0..1] ++ PostCode ISO20022 rule





2.15/4.1.10 [0..1] ++ Country ISO20022 rule


ISO20022 rule










ISO20022 rule






2.15/4.1.18 [1..1] | | +++++ Code ISO20022 rule



2.15/4.1.20 [0..1] | ++++ Issuer ISO20022 rule












ISO20022 rule


2.15/4.1.27 [0..*] | +++ Other ISO20022 rule













ISO20022 rule



2.15/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule







2.15/4.1.36 [0..1] ++ Name ISO20022 rule











7.12.5.3 Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/UltmtDbtr element (previously indexed as 2.18)








2.18/4.1.2 [0..1] ++ AddressType

ISO20022 rule









2.18/4.1.3 [0..1] ++ Department ISO20022 rule


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


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.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




2.18/4.1.10 [0..1] ++ Country ISO20022 rule Nation with its own government.

ISO20022 rule


2.18/4.1.11 [0..7] ++ AddressLine ISO20022 rule


2.18/4.1.12 [0..1] + Identification ISO20022 rule Unique and unambiguous identification of a party.

2.18/4.1.13 [1..1] | ++ OrganisationIdentification ISO20022 rule

Unique and unambiguous way to identify an organisation.



ISO20022 rule





2.18/4.1.16 [1..1] | ++++ Identification ISO20022 rule Identification assigned by an institution.







2.18/4.1.21 [1..1] | ++ PrivateIdentification ISO20022 rule

Unique and unambiguous identification of a person, eg, passport.










ISO20022 rule


2.18/4.1.27 [0..*] | +++ Other ISO20022 rule











ISO20022 rule





2.18/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule







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.

7.12.5.4 Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/CdtTrfTx/Cdtr element (previously indexed as 2.64)




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


ISO20022 rule


2.64/4.1.2 [0..1] ++ AddressType

ISO20022 rule























ISO20022 rule







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).





ISO20022 rule






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.18 [1..1] | | +++++ Code

SEPAMAIL rule


• 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).




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 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


2.64/4.1.21 [1..1] | ++ PrivateIdentification SEPAMAIL rule Not Allowed for SEPAmail

2.64/4.1.33 [0..1] + CountryOfResidence SEPAMAIL rule





2.64/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule














2.64/4.1.41 [0..1] ++ Other ISO20022 rule


7.12.5.5 Details of fields under /PaymentActivationRequest/sepamail_message_payment_activation_request_001/ReqCompl/Request/PmtInf/CdtTrfTx/UltmtCdtr element (previously indexed as 2.66)








ISO20022 rule


2.66/4.1.2 [0..1] ++ AddressType

ISO20022 rule






















2.66/4.1.10 [0..1] ++ Country ISO20022 rule


ISO20022 rule










ISO20022 rule






2.66/4.1.18 [1..1] | | +++++ Code ISO20022 rule



2.66/4.1.20 [0..1] | ++++ Issuer ISO20022 rule












ISO20022 rule


2.66/4.1.27 [0..*] | +++ Other ISO20022 rule













ISO20022 rule



2.66/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule







2.66/4.1.36 [0..1] ++ Name ISO20022 rule











7.12.6 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».

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 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 ignor d.

• If check d, 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 a tomatically 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.

• 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 identi ying 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.

7.12.7 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).

(*) 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.


7.13 IG Rubis ActivationReport

• These implementation rules shall be applied: o In accordance, unless explicitly specified, with ISO20022 own implementation rules. o In compliance with the relevant European Regulation, especially regulation related to the credit transfers when data from the Report are

forwarded in a SCT message. • 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 • Each of the IG tables specifies the following items:







7.13.1 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].

7.13.2 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


7.13.3 Header Ref. Mult. Ch. Depth Message


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.

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



Requirements

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

7.13.4 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 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 :



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

7.13.5 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.



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.

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 rule Usage Rule: Only BIC is allowed

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


1.4/3.1.1 [0..1] ++++ BICFI ISO20022 rule


SEPAMAIL rule






1.4/3.1.7 [0..1] ++++ Name SEPAMAIL rule


1.4/3.1.8 [0..1] ++++ PostalAddress SEPAMAIL rule Not Allowed for SEPAmail

1.4/3.1.19 [0..1] ++++ Other SEPAMAIL rule


1.4/3.1.25 [0..1] +++ BranchIdentification SEPAMAIL rule Not Allowed for SEPAmail



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




1.5/3.1.1 [0..1] ++++ BICFI ISO20022 rule


SEPAMAIL rule




1.5/3.1.3 [0..1] +++++ ClearingSystemIdentification ISO20022 rule


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.


1.5/3.1.9 [0..1] +++++ AddressType

ISO20022 rule









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


1.5/3.1.12 [0..1] +++++ StreetName ISO20022 rule Name of a street or thoroughfare.

1.5/3.1.13 [0..1] +++++ BuildingNumber ISO20022 rule




1.5/3.1.14 [0..1] +++++ PostCode ISO20022 rule


1.5/3.1.15 [0..1] +++++ TownName ISO20022 rule


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


ISO20022 rule


1.5/3.1.18 [0..7] +++++ AddressLine ISO20022 rule


1.5/3.1.19 [0..1] ++++ Other ISO20022 rule Unique identification of an agent, as assigned by an institution, using an identification scheme.


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


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.

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.


1.5/3.1.29 [0..1] +++++ AddressType

ISO20022 rule











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


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


1.5/3.1.34 [0..1] +++++ PostCode ISO20022 rule


1.5/3.1.35 [0..1] +++++ TownName ISO20022 rule


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


ISO20022 rule


1.5/3.1.38 [0..7] +++++ AddressLine ISO20022 rule


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.

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.


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 AcceptedSettlementInProcess All 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.

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


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

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'

ISO20022 rule


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




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


3.3 [0..1] ++ OriginalControlSum SEPAMAIL rule Not Allowed for SEPAmail

3.4 [0..1] ++ PaymentInformationStatus SEPAMAIL rule


3.5 [0..*] ++ StatusReasonInformation SEPAMAIL rule Not Allowed for SEPAmail

3.11 [0..*] ++ NumberOfTransactions-PerStatus

SEPAMAIL 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




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.


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 AcceptedSettlementInProcess All 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




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.

ISO20022 rule


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


3.26 [0..*] +++ ChargesInformation SEPAMAIL rule




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


3.32 [0..1] +++ OriginalTransactionReference ISO20022 rule Set of key elements used to identify the original transaction that is being referred to.

3.33 [0..1] ++++ InterbankSettlementAmount ISO20022 rule

Amount of money moved between the instructing agent and the instructed agent.

ISO20022 rule


[1..1] +++++ Currency

ISO20022 rule


3.34 [0..1] ++++ Amount ISO20022 rule




3.35 [1..1] | +++++ InstructedAmount ISO20022 rule


ISO20022 rule


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


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


3.55 [0..1] ++++ PaymentTypeInformation ISO20022 rule Set of elements used to further specify the type of transaction.

3.56 [0..1] +++++ InstructionPriority SEPAMAIL rule


3.57 [0..1] +++++ ClearingChannel SEPAMAIL rule Not Allowed for SEPAmail

3.58 [0..1] +++++ ServiceLevel SEPAMAIL rule




3.61 [0..1] +++++ LocalInstrument SEPAMAIL rule Not Allowed for SEPAmail

3.64 [0..1] +++++ SequenceType SEPAMAIL rule


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.


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 amount of money and dates of collections may vary.

TRA TransferAdvice Transfer 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


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. Case the debtor does not provide this item lor refuses the payment request, a default value “NOTPROVIDED” must be used by the debtor’s Bank.

• 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




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: - Type - Currency - Name

MAP TO rule

This structure MUST NOT be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /DbtrAcct] (2.50) within the [SEPA Inter-Bank Credit Transfer] message. Only the IBAN chosen by the debtor to pay must be forwarded into [ /Document /FIToFICstmrCdtTrf /CdtTrfTxInf /DbtrAcct] (2.50) within the [SEPA Inter-Bank Credit Transfer] message.


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



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 ISO 0022 rule


ISO20022 rule




3.120/1.1.12 [0..1] +++++ Name

ISO20022 rule


3.121 [0..1] ++++ DebtorAgent SEPAMAIL rule


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 r 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 iden ifier code (BIC)".

SEPAMAIL rule


SEPAMAIL rule

Mandatory

3.121/3.1.2 [0..1] ++++++ ClearingSystem-MemberIdentification


3.121/3.1.7 [0..1] ++++++ Name SEPAMAIL rule


3.121/3.1.8 [0..1] ++++++ PostalAddress SEPAMAIL rule Not Allowed for SEPAmail

3.121/3.1.19 [0..1] ++++++ Other SEPAMAIL rule


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




3.122/3.1.1 [0..1] ++++++ BICFI ISO20022 rule


SEPAMAIL rule


SEPAMAIL rule

Mandatory

3.122/3.1.2 [0..1] ++++++ ClearingSystem-MemberIdentification


3.122/3.1.3 [0..1] +++++++ ClearingSystemIdentification ISO20022 rule


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


ISO20022 rule


3.122/3.1.9 [0..1] +++++++ AddressType

ISO20022 rule









3.122/3.1.10 [0..1] +++++++ Department ISO20022 rule


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




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


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


3.122/3.1.17 [0..1] +++++++ Country ISO20022 rule Nation with its own government.

ISO20022 rule


3.122/3.1.18 [0..7] +++++++ AddressLine ISO20022 rule


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


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


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


ISO20022 rule




3.122/3.1.29 [0..1] +++++++ AddressType

ISO20022 rule









3.122/3.1.30 [0..1] +++++++ Department ISO20022 rule


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


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


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




3.122/3.1.37 [0..1] +++++++ Country ISO20022 rule Nation with its own government.

ISO20022 rule


3.122/3.1.38 [0..7] +++++++ AddressLine ISO20022 rule


3.123 [1..1] ++++ Creditor ISO20022 rule

Party to which an amount of money is due.

SEPAMAIL rule

Mandatory

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 (*).


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



SEPAMAIL rule Mandatory

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


ISO20022 rule




3.124/1.1.12 [0..1] +++++ Name

ISO20022 rule


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

7.13.5.1 Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/GrpHdr/InitgPty element (previously indexed as 1.3)






SEPAMAIL rule Name is mandatory if it is not a bank



ISO20022 rule


ISO20022 rule




1.3/4.1.2 [0..1] ++ AddressType ISO20022 rule Identifies the nature of the postal address.

ISO20022 rule























ISO20022 rule











ISO20022 rule


SEPAMAIL rule

BIC (in Id) is mandatory if it is a bank





1.3/4.1.18 [1..1] | | +++++ Code ISO20022 rule















ISO20022 rule


1.3/4.1.27 [0..*] | +++ Other ISO20022 rule













ISO20022 rule



1.3/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule







1.3/4.1.36 [0..1] ++ Name ISO20022 rule











7.13.5.1 Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlGrpInfAndSts/StsRsnInf/Orgtr element (previously indexed as 2.8)



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







ISO20022 rule


SEPAMAIL rule BIC is mandatory if the originator is a bank

2.8/4.1.15 [0..*] | +++ Other SEPAMAIL rule



2.8/4.1.33 [0..1] + CountryOfResidence SEPAMAIL rule


2.8/4.1.34 [0..1] + ContactDetails SEPAMAIL rule Not Allowed for SEPAmail


7.13.5.2 Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/StsRsnInf/Orgtr element (previously indexed as 3.21)


3.21/4.1.0 [0..1] + Name ISO20022 rule


SEPAMAIL rule

Name is mandatory if the originator is not a bank









ISO20022 rule


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


3.21/4.1.33 [0..1] + CountryOfResidence SEPAMAIL rule Not Allowed for SEPAmail

3.21/4.1.34 [0..1] + ContactDetails SEPAMAIL rule


7.13.5.3 Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/UltmtDbtr element (previously indexed as 3.118)






ISO20022 rule


3.118/4.1.2 [0..1] ++ AddressType

ISO20022 rule























ISO20022 rule











ISO20022 rule






3.118/4.1.18 [1..1] | | +++++ Code ISO20022 rule



3.118/4.1.20 [0..1] | ++++ Issuer ISO20022 rule












ISO20022 rule


3.118/4.1.27 [0..*] | +++ Other ISO20022 rule













ISO20022 rule



3.118/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule







3.118/4.1.36 [0..1] ++ Name ISO20022 rule











7.13.5.4 Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/Dbtr element (previously indexed as 3.119)








3.119/4.1.2 [0..1] ++ AddressType

ISO20022 rule























ISO20022 rule









ISO20022 rule























ISO20022 rule


3.119/4.1.27 [0..*] | +++ Other ISO20022 rule











ISO20022 rule





3.119/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule














3.119/4.1.41 [0..1] ++ Other ISO20022 rule


7.13.5.5 Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/Cdtr element (previously indexed as 3.123)







ISO20022 rule


3.123/4.1.2 [0..1] ++ AddressType

ISO20022 rule























ISO20022 rule







SEPAMAIL rule

Mandatory for ICQX@SCHEME registered users.





ISO20022 rule





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.18 [1..1] | | +++++ Code SEPAMAIL rule Not Allowed for SEPAmail




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.21 [1..1] | ++ PrivateIdentification SEPAMAIL rule



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
















3.123/4.1.41 [0..1] ++ Other ISO20022 rule


7.13.5.6 Details of fields under /PaymentActivationReport/sepamail_message_payment_activation_report_001/RepCompl/Report/OrgnlPmtInfAndSts/TxInfAndSts/OrgnlTxRef/UltmtCdtr element (previously indexed as 3.125)







3.125/4.1.2 [0..1] ++ AddressType

ISO20022 rule























ISO20022 rule









ISO20022 rule























ISO20022 rule


3.125/4.1.27 [0..*] | +++ Other ISO20022 rule











ISO20022 rule





3.125/4.1.35 [0..1] ++ NamePrefix

ISO20022 rule














3.125/4.1.41 [0..1] ++ Other ISO20022 rule


7.13.6 Non-ISO part This part is only used by the SEPAmail/RUBIS system, to provide additional services both to creditor and debtor.



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.

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


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


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.

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.


7.14 IG Rubis ActivationEnroll

• 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

7.14.1 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.

7.14.2 Abstraction level 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.


7.14.3 ActivationEnroll body 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 : 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 1606 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, 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 1606 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)


8 L'application DIAMOND DIAMOND est une application SEPAmail.

Son sigle est DIAMOND@SEPAmail.

DIAMOND est l'acronyme de Direct Identity control for Account Management ON Demand.

L'application DIAMOND permet à un donneur d’ordre de virements ou de prélèvements de fiabiliser les coordonnées bancaires données par une (et une seule) personne - physique ou morale - dans le cadre du processus de domiciliation bancaire.

L’application DIAMOND a pour objectif d’effectuer un contrôle de cohérence entre les informations fournies par un client / fournisseur / bénéficiaire à un Donneur d’Ordre (DO) et les informations détenues par le Prestataire de Services de Paiement (PSP) qui tient le compte bancaire de ce client / fournisseur / bénéficiaire.

Le contrôle effectué par le PSP tenant le compte du client / fournisseur / bénéficiaire s’appuie sur un algorithme communautaire et donne lieu à un compte-rendu détaillé qui se trouve dans ce qu’on appelle la réponse à la demande de vérification.

Une demande de vérification DIAMOND permet de vérifier les informations relatives à un et un seul prétendu titulaire de compte mais ne permet pas d’effectuer simultanément des vérifications sur plusieurs prétendus titulaires d’un même compte bancaire.

Le Donneur d’Ordre (DO) émettant une demande de vérification doit justifier d’une relation contractuelle naissante ou établie avec la personne faisant l’objet de la demande de vérification.

8.1 Les principes généraux (DIAMOND)

8.1.1 Les acteurs L’application DIAMOND met en scène quatre acteurs :

• La personne (physique ou morale) dont on cherche à vérifier les coordonnées bancaires,

• Le Prestataire de Services de Paiement (PSP) teneur du compte à vérifier,

• Le donneur d’ordre du paiement qui demande la vérification des coordonnées bancaires,

• Le PSP de ce donneur d’ordre

8.1.2 Objectifs L'application DIAMOND a pour objet de détecter les erreurs de saisie, les falsifications de relevés d'identité bancaire (RIB) 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.

8.1.3 Le contexte d’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 en vue de l’émission d'un prélèvement) soit en tant que débiteurs (contrôle des coordonnées bancaires du bénéficiaire en vue de l’émission d'un virement).

L'utilisation de l'application DIAMOND est modulable par le 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.

L'application DIAMOND est d'une utilisation totalement autonome par rapport aux autres applications SEPAmail.


8.2 Cas d'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 est bien détenu par le prétendu titulaire du compte

• De vérifier 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 ?

Demande de vérification DIAMOND Résultat

Etape 1 de l’algorithme :

Contrôle du compte IBAN Vrai ou Faux ou Contrôle impossible

Contrôles sur le type de titulaire et les noms de la personne physique faisant l’objet de la demande

Le titulaire du compte est-il de type « personne physique »

Vrai ou Faux

Nom Note de pertinence

Autre nom Note de pertinence

Contrôles sur d’autres informations concernant la personne physique faisant l’objet de la demande

Date de naissance Vrai ou Faux ou Contrôle impossible

Ville de naissance Vrai ou Faux ou Contrôle impossible

Pays de naissance Vrai ou Faux ou Contrôle impossible

Etape 2 de l’algorithme :

Vérification des types d’opérations autorisés sur le compte

IBAN Vrai ou Faux (par type d’opération)

La réalisation des étapes 1 et 2 requiert que le PSP Teneur du compte propose le service de fiabilisation des coordonnées bancaires. L’ensemble des contrôles effectués au cours de l’étape 1 concourent à la détermination d’un indicateur global (Vrai ou Faux). L’exécution de l’étape 2 est conditionnée par le résultat de l’étape 1.

Exemple appliqué au cas d’une personne physique


8.3 Gestion des flux (DIAMOND)

8.3.1 Schéma des flux

8.3.2 Description détaillée 1. Le prétendu 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 les coordonnées bancaires et l’identité de la personne faisant l’objet de la demande

3. Le PSP du donneur d’ordre transmet le message de demande de vérification des coordonnées bancaires au PSP teneur du compte à vérifier

4. Le PSP teneur du compte à vérifier vérifie, au travers de l’algorithme communautaire, les données de la demande reçue par rapport à ses propres données.

5. Le PSP teneur du compte transmet au PSP du donneur d’ordre le résultat de la vérification via le message de réponse à la demande de vérification.

6. Le PSP du donneur d’ordre transmet cette réponse au donneur d’ordre.

IBAN Nom prénom

/ SIREN

Restitution

- Donneur d’ordre - - Titula ire du com pte - - Personne Morale -

- Personne Physique - - Personne Morale -

PSP Teneur de compte

PSP Donneur d’ordre

Noms

IBAN type client

Initialisation 2

Remise IBAN 1

Demande de vérification 3

Réponse à demande de vérification 5

Existence Cohérence

6

4

Principes

• La transaction commerciale

ou de service entre le client/fournisseur et le Donneur d’ordre nécessite de la part du 1er la communication de ses coordonnées bancaires via la Remise de son IBAN (1 )

• Le Donneur d’ordre communique à son Prestataire de Service de Paiement (PSP) une Demande de vérification concernant les données du client/fournisseur (2 )

• Le PSP du Donneur d’ordre route (3 ) la Demande de vérification vers le PSP Teneur du compte à vérifier

• Le PSP teneur du compte effectue les contrôles (4 )

• Il restitue le résultat des contrôles au PSP du Donneur d’ordre (5 )

• Le PSP du Donneur d’Ordre transmet le résultat au Donneur d’Ordre (6 )


8.4 Les règles métier (DIAMOND)

8.4.1 Objet du chapitre Ce chapitre décrit le mécanisme global du système SEPAmail de demande de fiabilisation de coordonnées bancaires.

Il est destiné à des interlocuteurs fonctionnels, les éléments techniques figurant dans les directives correspondantes (implementation guidelines).

8.4.2 Présentation gé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 aux fins de fiabilisation :

• Création de la demande de vérification par le donneur d'ordre • Contrôle de la demande de vérification par le Prestataire de Services de Paiement (PSP) du

donneur d’ordre • Communication de la demande de vérification par le PSP du donneur d’ordre au PSP teneur de

compte du compte à vérifier • Contrôle de la demande de vérification par le PSP teneur du compte à vérifier • Application de l'algorithme communautaire de contrôle de coordonnées bancaires, par le PSP

teneur du compte à vérifier, par confrontation de la demande de vérification aux données de son Système d’Information

• Création de la réponse par le PSP teneur du compte à vérifier et communication de celle-ci au PSP du donneur d’ordre.

• Fourniture de la réponse au donneur d’ordre par le PSP du donneur d’ordre.

8.4.3 Messages de l’application DIAMOND 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

8.4.3.1 Le message de demande de vérification

Ce message est utilisé, à l'initiative d'un utilisateur SEPAmail (le donneur d'ordre), pour demander la vérification des coordonnées bancaires d’une personne (physique ou morale).

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 renseigne dans son message de demande les critères qu'il souhaite voir contrôler par le PSP teneur du compte à vérifier.

Le Donneur d’Ordre n’a la possibilité d’envoyer une demande de vérification de coordonnées bancaires que dans le cadre d’une relation contractuelle naissante ou établie avec le prétendu titulaire du compte. Il a l’obligation de matérialiser cette relation en rensiegnant la référence de celle-ci dans la demande de vérification.

8.4.3.2 Le message de réponse à demande de vé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:


• TRUE lorsque :

� Dans le cas d’une personne morale : Tous les contrôles donnent le résultat VRAI

� Dans le cas d’une personne physique :

o Le contrôle du « Nom » OU le contrôle de l’ « Autre Nom » donne une note de pertinence égale à 400

ET

o Tous les autres contrôles donnent le résultat VRAI

• FALSE :

� dans tous les autres cas, avec nécessité de lire le ou les codes retour non ISO en complément

� et si la demande est rejetée, avec nécessité de lire le code raison ISO20022 du rejet

ET

• un code retour par donnée testée, construit sur 5 caractères (fourni dans la partie non ISO) indiquant:

1. en positions 1 et 2 : le n° du contrôle effectué

1. 00 Validité de la demande de Vérification (utilisé en cas de rejet de la DDV)

2. 01 IBAN

3. 02 customer type

4. 03 SIREN

5. 04 SIRET

6. 05 TVA intracomm

7. 06 birth date

8. 07 birth city

9. 08 birth country

10. 09 name

11. 10 other_name

12. 11 idcard / pass

2. en positions 3, 4 et 5 : le résultat obtenu sur ce contrôle

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 :

• 000 FAUX

• 001 VRAI

• 002 FAUX sur une donnée de repli

• 003 VRAI sur une donnée de repli

• 020 Contrôle impossible

Il est restitué dans la réponse remontée au donneur d'ordre autant de codes retour par IBAN que de données effectivement testées. En revanche, compte tenue de la dépendance de certains tests entre eux, toutes les données fournies pour contrôle ne seront pas obligatoirement testées.

La liste exhaustive des codes retours est décrite dans le guide d'implémentation.


8.5 IG identification.verification L'écosystème identification.verification comporte deux messages :


identification.verification VerificationRequest [email protected]

VerificationReport [email protected]


8.6 IG Diamond VerificationRequest

• These implementation rules shall be applied: o In accordance, unless explicitly specified, with ISO20022 own implementation rules.

• 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 • Each of the IG tables specifies the following items:







8.6.1 Reference document The underlying message, acmt.023.001.01, is described by an ISO 20022 document, entitled "Modification Advice and Verification Identification Information: Message Definition Report", in its December 2009 version, with which the reader should be familiar.

8.6.2 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.

8.6.3 Internal abstraction level

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.



[1..1] + sepamail_verification_request_001 SEPAMAIL rule First version of the message

8.6.4 Message Body This message contains a mandatory ISO part and a non-ISO part.


Requirements

A [1..1] + Request ISO20022 rule

The IdentificationVerificationRequest message is sent by an assigner to an assignee. It is used to request the verification of party and/or account identification information.

ISO20022 rule

The IdentificationVerificationRequest message is sent before the sending of one or several transactions messages. The IdentificationVerificationRequest message can contain one or more verification requests.

SEPAMAIL rule IdentificationVerificationRequestV01, as per ISO acmt.023

B [0..1] + Complement SEPAMAIL rule

Non-ISO part. This part allows the requester to add complementary informations. Must be present.


8.6.5 ISO part: 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.


1.0 [1..1] + Assignment ISO20022 rule Identifies the identification assignment.

1.1 [1..1] ++ MessageIdentification

ISO20022 rule

Point to point reference, as assigned by the assigner, and sent to the next party in the chain to unambiguously identify the message. Usage: The assigner has to make sure that MessageIdentification is unique per assignee for a pre-agreed period.

MAP TO rule

This structure must be copied into [ /VerificationReport /sepamail_verification_report_001 /Report /OrgnlAssgnmt /MsgId] (2.1) within the [DIAMOND Verification Report] message.

1.2 [1..1] ++ CreationDateTime ISO20022 rule Date and time at which the identification assignment was created.

MAP TO rule

This structure must be copied into [ /VerificationReport /sepamail_verification_report_001 /Report /OrgnlAssgnmt /CreDtTm] (2.2) within the [DIAMOND Verification Report] message.



1.3 [0..1] ++ Creator SEPAMAIL rule Mandatory for SEPAmail

ISO20022 rule Party that created the identification assignment.

SEPAMAIL rule

Designates the party which initially creates the request, ie the party which intends to further initiate a payment transaction.

1.4 [1..1] | +++ Party ISO20022 rule Identification of a person or an organisation.

SEPAMAIL rule See below for full details about this element.

See details below

1.5 [1..1] | +++ Agent SEPAMAIL rule Not Allowed for SEPAmail



1.6 [1..1] ++ Assigner ISO20022 rule

Party that assigns the identification assignment to another party. This is also the sender of the message.

MAP TO rule

This structure must be copied into [ /VerificationReport /sepamail_verification_report_001 /Report /Assgnmt /Assgne] (1.9) within the [DIAMOND Verification Report] message

1.7 [1..1] | +++ Party SEPAMAIL rule Not Allowed for SEPAmail

1.8 [1..1] | +++ Agent ISO20022 rule Identification of a financial institution.

1.8/2.1.0 [1..1] | ++++ FinancialInstitution-Identification ISO20022

rule


ISO20022 rule Usage rule : only BIC is allowed



1.8/2.1.1 [0..1] | +++++ BIC ISO20022 rule

Bank Identifier Code. Code allocated to financial institutions by the Registration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier Codes).

ISO20022 rule

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, 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

Must be an SEPAmail InternalRouteBic

• If checked, when the BIC is not a SEPAmail InternalRouteBic, then the Reason Code to use within the REJECT is 'RC11' (InvalidIntermediaryAgent).

1.8/2.1.2 [0..1] | +++++ ClearingSystem-MemberIdentification




1.8/2.1.7 [0..1] | +++++ Name SEPAMAIL rule Not Allowed for SEPAmail

1.8/2.1.8 [0..1] | +++++ PostalAddress SEPAMAIL rule Not Allowed for SEPAmail


1.8/2.1.25 [0..1] | ++++ BranchIdentification SEPAMAIL rule Not Allowed for SEPAmail

1.9 [1..1] ++ Assignee ISO20022 rule

Party that the identification assignment is assigned to. This is also the receiver of the message.

MAP TO rule

This structure must be copied into [ /VerificationReport /sepamail_verification_report_001 /Report /Assgnmt /Assgnr] (1.6) within the [DIAMOND Verification Report] message.






rule





1.11/2.1.1 [0..1] | +++++ BIC ISO20022 rule


ISO20022 rule


SEPAMAIL rule

Must be an SEPAmail InternalRouteBic

• If checked, when the BIC is not a SEPAmail InternalRouteBic, then the Reason Code to use within the REJECT is 'RC11' (InvalidIntermediaryAgent).











2.0 [1..*] + Verification ISO20022 rule

Information concerning the identification data that is requested to be verified.

SEPAMAIL rule

Only one occurrence of this structure is allowed for SEPAmail.

• If checked, when more than one occurence are present, each unwanted occurence must be rejected, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).

MAP TO rule

One, and only one occurrence of [ /VerificationReport /sepamail_verification_report_001 /Report /Rpt] (3.0) within the [DIAMOND Verification Report] message must be set for each occurrence of this structure

MAP TO rule

One occurrence of [ /VerificationReport /sepamail_verification_report_001 /Complement /VrfReportCompl] (B2) within the [DIAMOND Verification Report] message must be set for each occurrence of this structure



2.1 [1..1] ++ Identification ISO20022 rule

Unique identification, as assigned by a sending party, to unambiguously identify the party and account identification information group within the message.

MAP TO rule

This structure must be copied into [ /VerificationReport /sepamail_verification_report_001 /Report /Rpt /OrgnlId] (3.1) within the [DIAMOND Verification Report] message.

MAP TO rule

Each occurrence of [ /VerificationReport /sepamail_verification_report_001 /Complement /VrfReportCompl /VerifId] (B2.1) within the [DIAMOND Verification Report] message must be copied from the relevant this structure.

2.2 [1..1] ++ PartyAndAccount-Identification

ISO20022 rule

Party and/or account identification information for which verification is requested.

MAP TO rule

This structure must be copied into [ /VerificationReport /sepamail_verification_report_001 /Report /Rpt /OrgnlPtyAndAcctId] (3.6) within the [DIAMOND Verification Report] message. If some parts of information, not allowed by rules or regulations, are present the must not be embedded during the copy.



2.3 [0..1] +++ Party ISO20022 rule

Account owner that owes an amount of money or to whom an amount of money is due.

See details below

2.4 [0..1] +++ Account SEPAMAIL rule Mandatory for SEPAmail

ISO20022 rule Unambiguous identification of the account of a party.

SEPAMAIL rule Only IBAN is allowed



2.4/1.1.0 [1..1] | ++++ IBAN

ISO20022 rule


• If checked, when the IBAN value is invalid, then the Reason Code to use within the REJECT is 'AC01' (IncorrectAccountNumber).

ISO20022 rule

A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.

2.4/1.1.1 [1..1] | ++++ Other SEPAMAIL rule Not Allowed for SEPAmail

2.5 [0..1] +++ Agent ISO20022 rule Financial institution servicing an account for a party.

2.5/2.1.0 [1..1] ++++ FinancialInstitution-Identification ISO20022

rule





2.5/2.1.1 [0..1] +++++ BIC ISO20022 rule


ISO20022 rule




2.5/2.1.7 [0..1] +++++ Name SEPAMAIL rule Not Allowed for SEPAmail

2.5/2.1.8 [0..1] +++++ PostalAddress SEPAMAIL rule Not Allowed for SEPAmail



2.5/2.1.19 [0..1] +++++ Other SEPAMAIL rule Not Allowed for SEPAmail

2.5/2.1.25 [0..1] ++++ BranchIdentification SEPAMAIL rule Not Allowed for SEPAmail

8.6.6 Details of fields under /VerificationRequest/sepamail_verification_request_001/Request/Assgnmt/Cretr/Pty element (previously indexed as 1.4)


1.4/3.1.0 [0..1] + Name ISO20022 rule







1.4/3.1.2 [0..1] ++ AddressType

ISO20022 rule






HOME ResidentialAddress is the home address.














ISO20022 rule




1.4/3.1.12 [0..1] + Identification SEPAMAIL rule Mandatory for SEPAmail

ISO20022 rule Unique and unambiguous identification of a party.




1.4/3.1.14 [0..1] | +++ BICOrBEI

ISO20022 rule



1.4/3.1.15 [0..*] | +++ Other ISO20022 rule

Unique identification of an organisation, as assigned by an institution, using an identification scheme.

SEPAMAIL rule

Must contain the ICQX (first occurrence) and, if applicable, an ICS (second occurrence).




SEPAMAIL rule

ICQX.

• If checked, when a first occurence is present but does not contain an registered and active ICQX, then the Reason Code to use within the REJECT is 'BE05' (UnrecognisedInitiatingParty).

• If checked, when there is no occurrence of this structure, then the Reason Code to use within the REJECT is 'BE05' (UnrecognisedInitiatingParty).


SEPAMAIL rule


• If checked, when this structure is not present, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).

1.4/3.1.18 [1..1] | | +++++ Code SEPAMAIL rule Not Allowed for SEPAmail




SEPAMAIL rule

Must contain the value "SEPA" if 3.1.16 contains an ICS, and "SEPAMAIL.EU" if it contains an ICQX.

• If checked, when the value is not equal to "SEPAMAIL.EU" while the relevant identifier is an ICQX, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).








1.4/3.1.35 [0..1] ++ NamePrefix

ISO20022 rule







1.4/3.1.36 [0..1] ++ Name ISO20022 rule











8.6.7 Details of fields under /VerificationRequest/sepamail_verification_request_001/Request/Vrfctn/PtyAndAcctId/Pty element (previously indexed as 2.3)


2.3/3.1.0 [0..1] + Name ISO20022 rule


SEPAMAIL rule

Mandatory for a private person, contains the first name(s) and the last name of the person.

• If checked, when the name is missing although the request applies on a private person, then the Reason Code to use within the REJECT is 'BE21' (MissingName).




SEPAMAIL rule

MUST be used if the party is not a private person.

MUST NOT be used if the party is a private person



2.3/3.1.14 [0..1] | +++ BICOrBEI SEPAMAIL rule Not Allowed for SEPAmail

2.3/3.1.15 [0..*] | +++ Other ISO20022 rule


SEPAMAIL rule

An organisation must be identified by a SIREN

• If checked, when the SIREN identifier is missing, then the Reason Code to use within the REJECT is 'BE15' (InvalidIdentificationCode).


2.3/3.1.17 [0..1] | ++++ SchemeName SEPAMAIL rule Not Allowed for SEPAmail




SEPAMAIL rule

MUST be used if 2.3/3.1.16 Identification is present

Type of data. Allowed values : SIREN SIRET TVA_intracomm

• If checked, when the value is not allowed, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).



2.3/3.1.23 [1..1] | ++++ BirthDate ISO20022 rule Date on which a person is born.

2.3/3.1.24 [0..1] | ++++ ProvinceOfBirth SEPAMAIL rule Not Allowed for SEPAmail

2.3/3.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule City where a person was born.




ISO20022 rule


2.3/3.1.27 [0..*] | +++ Other ISO20022 rule


SEPAMAIL rule

Use one or several such elements to indicate values to be checked.

Only one occurrence is allowed for a given Issuer (2.3/3.1.32)

• If checked, when there is more than one occurence for a given Issuer (2.3/3.1.32), then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).






SEPAMAIL rule

MUST be used if 2.3/3.1.28 Identification is present

Type of data. Allowed values : other_name (first name + last name) pass_number pass_location pass_date idcard_number idcard_location idcard_date

• If checked, when the value is not allowed, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).



8.6.8 Non-ISO part Ref. Mult. Ch. Depth Message


B1 [0..1] + MinCheckVersion SEPAMAIL rule Minimum version of name-checking algorithm. If absent, any version is accepted.



Requirements

B2 [0..1] + MaxCheckVersion SEPAMAIL rule

Maximum version of name-checking algorithm. If absent, the most recent version is accepted.

B3 [0..*] + VrfComplement SEPAMAIL rule One such element must be present for each Verification (2.0) in the ISO part.

SEPAMAIL rule

Only one occurrence is allowed

• If checked, when there is not one single occurrence of this structure, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).

B3.1 [1..1] ++ VerifId

SEPAMAIL rule

Identifier of the associated Verification element. MUST match one of the VerificationIdentification (2.1) indices.

• If checked, when the value does not match any of the Verification Identification that has been specified within the ISO part, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).



Requirements

B3.2 [0..1] ++ BusRef

SEPAMAIL rule


• If checked, when this structure is not present, then the Reason Code to use within the REJECT is 'FF01' (Invalid File Format).

SEPAMAIL rule

Business reference provided by the party which intends to further initiate a payment transaction, in order to ascertain its relation with the owner of the account to be verified.

MAP TO rule

This structure, must be copied into [ /VerificationReport /sepamail_verification_report_001 /Complement /VrfReportCompl /BusRef] (B2.3) within the [DIAMOND Verification Report] message.

B3.2.1 [1..1] +++ Type SEPAMAIL rule

Type of this reference. Allowed values :

RUM

other

B3.2.2 [1..1] +++ Value SEPAMAIL rule Value of this reference.



Requirements

B3.3 [0..*] ++ TransactionTest

SEPAMAIL rule

One such element for each operation to be checked.

Allowed values (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)

MAP TO rule

One occurrence of [ /VerificationReport /sepamail_verification_report_001 /Complement /VrfReportCompl /TrsInfo] (B2.4) within the [DIAMOND Verification Report] message must be set for each occurrence of this structure, unless the check could not be performed.

MAP TO rule

[ /VerificationReport /sepamail_verification_report_001 /Complement /VrfReportCompl /TrsInfo /Transaction] (B2.4.1) within the [DIAMOND Verification Report] message must be copied from the relevant this structure


8.7 IG Diamond VerificationReport

• These implementation rules shall be applied: o In accordance, unless explicitly specified, with ISO20022 own implementation rules.

• 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 • Each of the IG tables specifies the following items:







8.7.1 Reference document The underlying message, acmt.024.001.01, is described by an ISO 20022 document, entitled "Modification Advice and Verification Identification Information: Message Definition Report", in its December 2009 version, with which the reader should be familiar.

8.7.2 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.

8.7.3 Internal abstraction level

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.



[1..1] + sepamail_verification_report_001 SEPAMAIL rule First version of the message.

8.7.4 Message Body

This message contains a mandatory ISO part and a non-ISO part.


A [1..1] + Report SEPAMAIL rule IdentificationVerificationReportV01, as per ISO acmt.024.

B [1..1] + Complement SEPAMAIL rule Non-ISO part.

8.7.5 ISO part : 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.



1.0 [1..1] + Assignment ISO20022 rule Identifies the identification assignment.


ISO20022 rule


1.2 [1..1] ++ CreationDateTime ISO20022 rule Date and time at which the identification assignment was created.

1.3 [0..1] ++ Creator ISO20022 rule Party that created the identification assignment.

SEPAMAIL rule

Designates the party which initially created the message, i.e. the PSP which initialy received the verification request and is supposed to hold the relevant account to be checked. In fact this party is also the assigner of the message.





SEPAMAIL rule Usage rule : only BIC is allowed


rule




1.5/2.1.1 [0..1] | +++++ BIC ISO20022 rule


ISO20022 rule










1.6 [1..1] ++ Assigner ISO20022 rule

Party that assigns the identification assignment to another party. This is also the sender of the message.

MAP FROM rule

[ /VerificationRequest /sepamail_verification_request_001 /Request /Assgnmt /Assgne] (1.9) within the [DIAMOND Verification Request] message must be copied into this structure.




rule





1.8/2.1.1 [0..1] | +++++ BIC ISO20022 rule


ISO20022 rule










1.9 [1..1] ++ Assignee MAP FROM rule

[ /VerificationRequest /sepamail_verification_request_001 /Request /Assgnmt /Assgnr] (1.6) within the [DIAMOND Verification Request] message must be copied into this structure




rule





1.11/2.1.1 [0..1] | +++++ BIC ISO20022 rule


ISO20022 rule










2.0 [0..1] + OriginalAssignment SEPAMAIL rule Mandatory for SEPAmail

ISO20022 rule Provides for the reference to the original identification assignment.


ISO20022 rule


MAP FROM rule

[ /VerificationRequest /sepamail_verification_request_001 /Request /Assgnmt /MsgId] (1.1) within the [DIAMOND Verification Request] message must be copied into this structure.



2.2 [0..1] ++ CreationDateTime ISO20022 rule Date and time at which the message was created.

MAP FROM rule

[ /VerificationRequest /sepamail_verification_request_001 /Request /Assgnmt /CreDtTm] (1.2) within the [DIAMOND Verification Request] message must be copied into this structure.

3.0 [1..*] + Report ISO20022 rule

Information concerning the verification of the identification data for which verification was requested.

MAP FROM rule

One, and only one occurrence of this structure must be set for each occurrence of [ /VerificationRequest /sepamail_verification_request_001 /Request /Vrfctn] (2.0) within the [DIAMOND Verification Request] message

3.1 [1..1] ++ OriginalIdentification ISO20022 rule

Unique identification, as assigned by a sending party, to unambiguously identify the party and account identification information group within the original message.

MAP FROM rule

[ /VerificationRequest /sepamail_verification_request_001 /Request /Vrfctn /Id] (2.1) within the [DIAMOND Verification Request] message must be copied into this structure.



3.2 [1..1] ++ Verification ISO20022 rule Identifies whether the party and/or account information received is correct.

ISO20022 rule

One of the following IdentificationVerificationIndicator values must be used: - MeaningWhenTrue: Indicates that the identification information received is correct. - MeaningWhenFalse: Indicates that the identification information received is incorrect.

SEPAMAIL rule

TRUE if :

� For an organisation : All verified fields are true

� For a private person :

o ‘name’ control score OR ‘other_name’ control score is 400

AND

o All other verified fields are true

FALSE if the request is rejected, details in ISO part

FALSE in all other cases, details in non-ISO part



3.3 [0..1] ++ Reason ISO20022 rule Specifies the reason why the verified identification information is incorrect.

SEPAMAIL rule

Only Code must be used in order to specify the reason. Please refer to the DIAMOND IdentificationRequest Implementation Guideline to get the reason codes to be used for the different checks

3.4 [1..1] | +++ Code ISO20022 rule

Reason why the verified identification information is incorrect, as published in an external reason code list.

3.5 [1..1] | +++ Proprietary ISO20022 rule

Reason why the verified identification information is incorrect, in a proprietary form.

SEPAMAIL rule


3.6 [0..1] ++ OriginalPartyAnd-AccountIdentification

ISO20022 rule

Provides party and/or account identification information as given in the original message.

MAP FROM rule

[ /VerificationRequest /sepamail_verification_request_001 /Request /Vrfctn /PtyAndAcctId] (2.2) within the [DIAMOND Verification Request] message must be copied into this structure. If some parts of information, not allowed by rules or regulations, are present they must not be embedded during the copy.



3.7 [0..1] +++ Party ISO20022 rule

Account owner that owes an amount of money or to whom an amount of money is due.

See details below

3.8 [0..1] +++ Account ISO20022 rule Unambiguous identification of the account of a party.

SEPAMAIL rule Only IBAN is allowed

3.8/1.1.0 [1..1] | ++++ IBAN

ISO20022 rule


ISO20022 rule

A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.

3.8/1.1.1 [1..1] | ++++ Other SEPAMAIL rule Not Allowed for SEPAmail

3.9 [0..1] +++ Agent ISO20022 rule Financial institution servicing an account for a party.



3.9/2.1.0 [1..1] ++++ FinancialInstitution-Identification ISO20022

rule



3.9/2.1.1 [0..1] +++++ BIC ISO20022 rule


ISO20022 rule






3.9/2.1.7 [0..1] +++++ Name SEPAMAIL rule Not Allowed for SEPAmail

3.9/2.1.8 [0..1] +++++ PostalAddress SEPAMAIL rule Not Allowed for SEPAmail

3.9/2.1.19 [0..1] +++++ Other SEPAMAIL rule Not Allowed for SEPAmail

3.9/2.1.25 [0..1] ++++ BranchIdentification SEPAMAIL rule Not Allowed for SEPAmail

3.10 [0..1] ++ UpdatedPartyAnd-AccountIdentification


8.7.6 Details of fields under /VerificationReport/sepamail_verification_report_001/Report/Rpt/OrgnlPtyAndAcctId/Pty element (previously indexed as 3.7)


3.7/3.1.0 [0..1] + Name ISO20022 rule







3.7/3.1.14 [0..1] | +++ BICOrBEI SEPAMAIL rule Not Allowed for SEPAmail

3.7/3.1.15 [0..*] | +++ Other ISO20022 rule







3.7/3.1.23 [1..1] | ++++ BirthDate ISO20022 rule Date on which a person is born.



3.7/3.1.24 [0..1] | ++++ ProvinceOfBirth SEPAMAIL rule Not Allowed for SEPAmail

3.7/3.1.25 [1..1] | ++++ CityOfBirth ISO20022 rule City where a person was born.


ISO20022 rule


3.7/3.1.27 [0..*] | +++ Other ISO20022 rule









8.7.7 Non-ISO part Ref. Mult. Ch. Depth Message


B1 [1..1] + CheckVersion SEPAMAIL rule

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..*] + VrfReportCompl MAP FROM rule

One occurrence of this structure must be set for each occurrence of [ /VerificationRequest /sepamail_verification_request_001 /Request /Vrfctn] (2.0) within the [DIAMOND Verification Request] message

B2.1 [1..1] ++ VerifId MAP FROM rule

Each occurrence of this structure must be copied from the relevant [ /VerificationRequest /sepamail_verification_request_001 /Request /Vrfctn /Id] (2.1) within the [DIAMOND Verification Request] message.

B2.2 [1..*] ++ ReturnCode SEPAMAIL rule

One such element must be present for each 5-digit code returned by the performed checks. When the message Is rejected (reason code present), only one occurrence must be present ( “00000”).

B2.3 [0..1] ++ BusRef MAP FROM rule

[ /VerificationRequest /sepamail_verification_request_001 /Complement /VrfComplement /BusRef] (B3.2) within the [DIAMOND Verification Request] message, must be copied into this structure.

B2.3.1 [1..1] +++ Type SEPAMAIL rule Type of this reference. Can be "RUM" or "other".



Requirements

B2.3.2 [1..1] +++ Value SEPAMAIL rule Value of this reference.

B2.4 [0..*] ++ TrsInfo MAP FROM rule

One occurrence of this structure must be set for each occurrence of [ /VerificationRequest /sepamail_verification_request_001 /Complement /VrfComplement /TransactionTest] (B3.3) within the [DIAMOND Verification Request] message, unless the check could not be performed.

B2.4.1 [1..1] +++ Transaction MAP FROM rule

This structure must be copied from the relevant [ /VerificationRequest /sepamail_verification_request_001 /Complement /VrfComplement /TransactionTest] (B3.3) within the [DIAMOND Verification Request] message

B2.4.2 [1..1] +++ Allowed SEPAMAIL rule

Contains "true" or "false" to indicate whether or not the relevant transaction is allowed on the checked account.

8.7.8 Return codes

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 o 00 VerificationRequest o 01 IBAN o 02 customer type o 03 SIREN o 04 SIRET o 05 TVA intracomm o 06 birth date o 07 birth city o 08 birth country o 09 name


o 10 other_name o 11 id card / pass

• chars 3 to 5 indicate the result of the verification o for a simple check,

� 000 indicates false � 001 indicates true � 002 indicates false when computed on a related data � 003 indicates true when computed on a related data � 020 indicates that the control could not be achieved

o for a more complex check, these chars will hold a score between 0 and 400


Code Meaning

00000 Request could not be processed

01000 invalid or non-existing IBAN

01001 existing and valid IBAN

01020 impossible check of IBAN

02000 incorrect customer type

02001 correct customer type

02020 impossible check of customer type

03000 incorrect SIREN

03001 correct SIREN

03002 incorrect computed SIREN

03003 correct computed SIREN

03020 Impossible check of SIREN

04000 incorrect SIRET

04001 correct SIRET

04002 incorrect SIRET and incorrect computed SIREN

04003 incorrect SIRET, but correct computed SIREN

04020 impossible check of SIRET

04022 impossible check of SIRET and incorrect computed SIREN


Code Meaning

04023 impossible check of SIRET, but correct computed SIREN

05000 incorrect intracomm VAT

05001 correct intracomm VAT

05020 impossible check of intracomm VAT

06000 incorrect date of birth

06001 correct date of birth

06020 impossible check of date of birth

07000 incorrect city of birth

07001 correct city of birth

07020 impossible check of city of birth

08000 incorrect country of birth

08001 correct country of birth

08020 impossible check of country of birth

09XXX name control, XXX is a score between 0 and 400

10XXX other name control, XXX is a score between 0 and 400

11000 all provided identity documents incorrect

11001 at least one of the provided identity documents correct

11020 impossible check of identity documents


9 L’application AIGUE-MARINE 9.1 Présentation du sujet AIGUE-MARINE est une application SEPAmail. Son sigle est AIGUE-MARINE@SEPAmail.

AIGUE-MARINE n'a aucune signification en tant qu'acronyme, mais ses initiales correspondent à celles de « Aide à la Mobilité »

L'application AIGUE-MARINE est celle qui, dans SEPAmail, permettra de gérer les messages associés à la mobilité bancaire.

La mobilité bancaire est le processus qui permet à un particulier de changer facilement de compte et d'établissement bancaire.

Ce processus implique l'échange d'informations entre les différents intervenants : établissement d'arrivée, établissement de départ, émetteurs et leurs établissements bancaires. Il doit se dérouler rapidement et automatiquement ; il est mis en place à la demande expresse du client auprès de son nouvel établissement bancaire.

9.2 Contenu de l'application Comme le mode de fonctionnement de SEPAmail le prévoit, l'application est décrite précisément dans la SMIRK correspondante.

Cette SMIRK est complétée par des IG (Implementation Guidelines), définissant la structure et le contenu exacts des messages.

L'application AIGUE-MARINE se plaçant dans un cadre législatif et réglementaire extrêmement précis, la plupart des éléments de cette application sont fournis par la Profession :

• le schéma de base de la SMIRK est celui de la FBF (Fédération Bancaire Française), • la structure des messages et les IG associées sont basées sur celles fournies par le CFONB,

(Comité Français d'Organisation de de Normalisation Bancaires) • les flux sont définis par SEPAMAIL.


9.3 SMIRK APP1501, l'application AIGUE-MARINE

Afin de permettre une fluidité des opérations de mobilité bancaire, les acteurs ont besoin de standardiser, d’automatiser et de sécuriser les échanges d’information.

Ce document décrit une application de la messagerie SEPAmail qui permet de répondre à ce besoin, l’application AIGUE-MARINE.

9.3.1 Cas d’usage

Le cas d’usage de la domiciliation bancaire fait apparaître des échanges de données entre de nombreuses parties. Ces échanges sont répétitifs. Ils sont laborieux s’ils sont manuels. Ils concernent essentiellement des opérations récurrentes.

Structurer et standardiser ces échanges permet :

• l’automatisation, • la possibilité de mandater un tiers de confiance pour mettre en œuvre sa mobilité.

Le changement de domiciliation bancaire consiste essentiellement, pour le titulaire d’un compte bancaire, à informer chacun des émetteurs de prélèvements ou virements récurrents sur ce compte que les coordonnées de celui-ci ont changé et à basculer ces virements et prélèvements vers son nouveau compte.

Dans le périmètre d'AIGUE-MARINE, ce changement est dû exclusivement à un changement d’établissement bancaire à l'initiative du ou des titulaires du compte. Les cas de mobilité civile et postale sont explicitement exclus de ce périmètre.

De nombreux établissements bancaires proposent actuellement un service d'aide à la mobilité pour faciliter ce changement, autour d’une organisation semi-manuelle et de formats d’échange propriétaires.

Il est précisé également que l'utilisation d'un service de mobilité automatique n'oblige en aucun cas le Client migrant à clôturer l'ancien compte.

9.3.2 Présentation générale

Après avoir inventorié les acteurs de l’application, les principes puis l’application elle-même seront décrits.

La description précise des messages et les directives d’implémentation associées sont basées sur la version du 5 mars 2016 du CFONB et sont complétées par celle du Flux 4R avec le message « AccountSwitchingNotify ».

9.3.3 Glossaire et Acteurs

Client (Cl) : c'est un particulier qui souhaite ouvrir un compte dans un établissement bancaire, et mandater cet établissement pour le faire bénéficier du service de mobilité bancaire. Tous les cas de transfert ne sont pas autorisés, des documents juridiques (IG ou autres) préciseront les cas admis.

Émetteur : entité économique (entreprise ou particulier) qui émet des demandes de prélèvement sur le compte bancaire en tant que créancier, ou émet des ordres de virement au crédit du compte bancaire du Client dans son Établissement de Départ.

Établissement d'Arrivée (ÉA): l'établissement bancaire ou PSP dans lequel le Client ouvre un compte, vers lequel il souhaite transférer ses opérations bancaires. C'est l'Établissement d'Arrivée qui propose et coordonne le service de mobilité bancaire.


Établissement de Départ (ÉD): l'établissement bancaire ou PSP dans lequel le Client détient un compte, et qu'il ne souhaite plus utiliser pour ses opérations de virements récurrents et prélèvements.

Établissement de l'Émetteur (ÉÉ): l'établissement bancaire ou PSP par le biais duquel un Émetteur réalise des prélèvements ou virements sur le compte bancaire du Client dans son Établissement de Départ.

Il faut noter que chaque établissement est en fait appelé à jouer les trois rôles d'Établissement d'Arrivée, d'Établissement de Départ et d'Établissement d'Émetteur -- dans des proportions différentes selon les établissements.

Mandat de Mobilité : Le Mandat de Mobilité est un contrat entre le Client et l'Établissement d’Arrivée, introduit par la Loi française, qui prévoit que l’établissement d’arrivée agisse à la place du client afin de réaliser son changement de domiciliation bancaire. La date de signature du Mandat de Mobilité valide du Client déclenche les délais des schémas de flux présentés. Un socle juridique commun est en cours de mise au point par la FBF.

Le Mandat de Mobilité prévoit également que le Client accepte que ses nouvelles coordonnées bancaires soient transmises à tout tiers concerné par le changement de domiciliation pour des paiements concernés, ainsi qu’à son Établissement de Départ, si le client souhaite clôturer son compte.

Le Mandat de Mobilité comporte une référence unique et une date de signature, qui devront être transmis à l'Établissement de Départ lors de la demande d'informations.

Il comporte également la date de fin d'émission des virements permanents par l'ÉD, si de tels virements existent. Il peut également contenir la date de transfert du solde de son compte dans le cas où le client demande la clôture de son compte dans l’établissement de départ.

La date de signature du Mandat de Mobilité, transmise à l'Établissement de Départ, détermine la date de fin de collecte des informations comptabilisées par l'Établissement de Départ.

9.3.4 Besoins des Acteurs

Les besoins du Client sont :

• identifier ses créanciers pour les prélèvements récurrents reçus (SDD), ses émetteurs de virements récurrents reçus (SCT) et ses bénéficiaires de virements permanents émis (SCT et internationaux)

• Identifier les formules de chèques non encore débittées sur le compte • demander que les paiements associés à ces créanciers et émetteurs soient transférés sur son

nouveau compte. • pouvoir suivre l'avancement de sa mobilité

Il est précisé que le transfert des virements permanents émis n'est pas dans le périmètre de la présente application. Il appartient à l'Établissement d'Arrivée de proposer ou non au Client, dans le cadre du Mandat de Mobilité, un service autour de ces opérations.

Les besoins de l'Émetteur sont :

• identifier de façon unique et non ambiguë ses débiteurs (SDD) ou bénéficiaires (SCT). • mettre à jour ses bases de coordonnés bancaires afin de limiter le risque de rejets au moment de

l’émission de ses opérations.


L'ensemble des acteurs souhaitent en outre modifier au minimum leurs processus existants, compte tenu d'une part du nombre assez faible de flux prévisibles, d'autre part de la nécessité légale de fournir ce service gratuitement au Client.

9.3.5 Principes Le périmètre complet de la mobilité, d'après la profession, et les flux associés sont définis par le schéma ci-dessous :

Les délais indiqués entre crochets sont en jours ouvrés, et ils sont cumulatifs : chaque étape dispose de son délai propre, indépendamment du temps utilisé pour l'étape précédente.

Les Clients restent en contact avec leur Établissement d'Arrivée et avec leur Établissement de Départ si nécessaire, par les canaux habituels (banque à distance, mail, téléphone...). Les flux entre les Clients et les établissements sont donc exclus du périmètre de la Norme.

En ajoutant le flux retour ÉÉ -> ÉA indispensable pour la cohérence de la messagerie, nous obtenons donc ce schéma du périmètre SEPAmail pour AIGUE-MARINE :


Il y a donc fondamentalement deux dialogues à standardiser entre les acteurs :

• la récupération des informations liées aux opérations de paiement récurrentes (flux 2 et 3, dialogue Établissement d'Arrivée - Établissement de Départ)

• le changement de domiciliation bancaire (flux 4 et 4R, dialogue Établissement d'Arrivée - Établissements d'Émetteurs)

9.3.5.1 Les opérations récurrentes de paiement

Le Client doit pouvoir récupérer automatiquement les informations concernant certaines opérations de paiements d'un périmètre donné, sur un de ses comptes bancaires, pour une période déterminée, fixée ici à 13 mois.

Les opérations concernées sont :

• Les opérations SEPA o SCT reçus récurrents o SDD reçus récurrents (les one-off ne sont pas pris en compte)

• Les virements permanents émis • Les virements internationaux reçus récurrents • Les chèques non débités sur les chéquiers.

Un virement reçu est dit récurrent s'il est présenté au moins deux fois, par le même émetteur, au cours de la période de 13 mois couverte par la mobilité.

Nota Bene : Il faut noter que le cas particulier ci-dessous ne se présente a priori aujourd'hui que dans le contexte P2P (particulier à particulier). Il existe potentiellement des virements reçus par un créancier personne physique, suite à une Demande de Règlement envoyée par RUBIS. Pour éviter toute transmission accidentelle de l'IBAN de ce créancier à des interlocuteurs qui ne disposent que de son QXBAN, il est de la responsabilité de l'Établissement de Départ de décider de filtrer les opérations de ce type, et ne pas les faire figurer dans les listes d'informations envoyées à l'Établissement d'Arrivée.

2. demande de liste d'opérations sur 13 mois [2 jo]

3. fourniture de la liste [5 jo, total 7jo]

Etablissement de Départ

Etablissement d'Arrivée

Etablissement(s) d'Émetteur(s)

Émetteur

Client Migrant

1. Mandat + RIB ancien compte

0. info sur mobilité [3jo]

3bis. Liste des réponses reçues et transmises aux émetteurs, des formules de chèques non débitées

4. demande de changement de domiciliation [2jo, total 9 jo]

5. demande de changement de domiciliation [3 jo, total 12jo]

4bis. demande de changement de domiciliation si PSP hors de France

3ter. Traitement des virements permanents

6. Info sur opérations arrivées sur compte clos [3jo aprés réception, 13 mois]

7. information de mise en place et d'effet [10 jo, total 22jo]

Flux 2 = AccountSwitchingRequest Flux 3 = AccountSwitchingResponse

Flux 4 = AccountSwitchingForward Flux 4R = AccountSwitchingNotify 2jo]

Périmètre SEPAmail


Deux messages sont nécessaires dans ce dialogue :

• le message de demande d'informations • le message d'envoi d'informations

Nous pouvons décrire ce dialogue par le diagramme ci-dessous.

Le Client mandate son Établissement d'Arrivée pour réaliser le service de mobilité. Il signe donc un Mandat de Mobilité avec lui. C'est ce mandat qui permet aux autres acteurs de s'assurer de l'authenticité de la demande, et les messages envoyés par l'Établissement d'Arrivée doivent donc comporter suffisamment d'éléments à cet effet.

Rappelons que les échanges entre l'Établissement d'Arrivée et le Client sont hors du périmètre de SEPAmail.

Il est du ressort de l'Établissement de Départ de s'assurer du droit que le Client a à demander une mobilité bancaire, notamment :

• le compte n'est pas déjà clôturé • le Client est bien le titulaire du compte sur lequel la demande porte

Si la demande de mobilité ne peut pas être traitée par l'Établissement de Départ, le message de réponse lui permettra d’indiquer à l'Établissement d'Arrivée qu’il lui est impossible de traiter cette demande de mobilité. Ce message contient le ou les motifs de rejet, par exemple : RIB incorrect, compte déjà clos, motif réglementaire...

Les analyses juridiques précises sur ces sujets sont hors du périmètre de la SMIRK. Il faut toutefois préciser que, dès lors qu’une demande fait l’objet d’un rejet, une nouvelle demande sera à présenter par l'Établissement d’Arrivée si besoin, avec un nouveau Numéro de Mandat.

Les règles suivantes s'appliquent aux messages d'envoi d'informations :

• Le nombre de messages d'envoi d'informations, en réponse à un seul message de demande d'informations, est laissé au choix de l'expéditeur, et pourra donc être compris entre 1 et 4.

• Il doit impérativement y avoir, en cumul sur l'ensemble des messages d'envoi d'informations, 4 blocs d'informations : virements permanents émis, virements récurrents reçus, prélèvements reçus, chèques.

• Chaque message devra comporter au minimum un bloc


• Un bloc pour lequel il n'y a aucune information à transmettre devra néanmoins être présent dans un message, et renseigné à zéro.

9.3.5.2 Remarques

Dans le cas d’un ordre de virement ou de mandat de prélèvement, l'Émetteur peut se satisfaire de l’authentification du migrant proposée par l’expéditeur au sein du réseau SEPAmail ou demander une confirmation dans son propre environnement d’authentification de son client, par exemple en demandant à sa banque de réaliser une transaction de l’application de SEPAmail DIAMOND.

Un service d’accusé de réception est déjà en place et automatisé chez beaucoup de Corporates. Il est donc indispensable de les laisser maîtres du canal qu’ils souhaitent utiliser pour communiquer avec leur client. Le service via SEPAmail doit donc demeurer optionnel.

9.3.6 Application, ecosystème et besoins transverses

L’application de SEPAmail s’appelle AIGUE-MARINE, dont les initiales correspondent à celles de "Aide à la Mobilité"

Elle comprend deux dialogues distincts permettant une automatisation du besoin de changement de domiciliation bancaire. Elle pourrait s’enrichir dans une version ultérieure d’autres besoins liés à d’autres mobilités.

Un écosystème SEPAmail dédié est créé, nommé mobility.

Il est fondamental de donner à l'ensemble des acteurs un très haut niveau de souplesse pour faciliter l'adoption de cette norme, notamment en leur permettant de séparer et/ou sous-traiter et/ou externaliser les fonctions d'Établissement d'Arrivée, Établissement de Départ et Établissement d'Émetteur. Ceci est pris en compte par une évolution du routage général de SEPAmail, et non de façon locale à AIGUE-MARINE.

Il n’y a pas besoin d’annuaire, ni pour les Clients, ni pour les Émetteurs.

Les statistiques remontées au scheme (ad-hoc de ce nouvel écosystème) pour la surveillance du réseau sont celles par défaut, pour la première version du moins.

9.3.7 Contenu des messages

9.3.7.1 Cas général

SEPAmail n'est utilisé -- ce qui est normal -- que comme une messagerie. Le contenu et la structure des messages ont été définis par le CFONB. Ces sujets ne sont donc pas dans le périmètre de la présente SMIRK.

9.3.7.2 Cas particulier du rapport de modification

Le message de réponse à demande de modification (d'Établissement d'Émetteur à Établissement d'Arrivée notamment) est hors périmètre légal, et n'a pas été spécifié par le CFONB.

Il a donc été défini par SEPAmail, sur la base du message de demande de modification. Les IG correspondantes sont disponibles ici.


9.3.8 Informations complémentaires

9.3.8.1 Autour du mandat de mobilité

Le mandat « en droit des obligations, est un contrat par lequel une personne, le mandant, donne à une autre personne, le mandataire, le pouvoir de faire un ou des actes juridiques en son nom et pour son compte. »[2]

L'Établissement d'Arrivée doit pouvoir, dans certains cas, prouver à l'Établissement de Départ et à l'Émetteur qu’il dispose bien du Mandat de Mobilité du Client, lequel est aussi client, et en ce sens seulement client "commun", de l'Établissement de Départ et de l'Émetteur dans des relations contractuelles distinctes. Des cas particuliers où les titulaires de compte changent de périmètre à l'occasion d'une mobilité bancaire prévue par la Loi (par exemple, un compte individuel vers un compte joint pour un client qui change de situation civile et se marie) ont été précisés dans le glossaire.

Le minimum pour l'Établissement d'Arrivée autour du Mandat de Mobilité est de :

• transporter vers l'Établissement de Départ la Référence unique du Mandat de mobilité reçu par l'Établissement d'Arrivée, ainsi que sa date de signature et autres informations détaillées qui seront précisées dans les IG

• conserver le Mandat de mobilité.

Les règles de la messagerie bancaire sécurisée, si ce canal est utilisé, couvrent les risques, et le Mandat de Mobilité n’a pas à être véhiculé car il ne concerne que l'Établissement d'Arrivée et son client. Le reste est couvert par la loi.

Si toutefois une disposition légale ou réglementaire devait imposer ce transport, SEPAmail pourrait s'y conformer de façon native grâce à l'en-tête standard de ses messages.

Les risques de fraude au sujet de ce mandat sont :

• l’usurpation d’identité du mandant. Ce risque est couvert par l'Établissement d'Arrivée, puisqu'il est adhérent du réseau SEPAmail.

• une faille de sécurité opérationnelle du système d’information de l'Établissement d'Arrivée

9.3.8.2 Mandat SEPA

La modification des coordonnées bancaires du Client constitue un amendement du mandat de prélèvement SEPA. Il revient à l'Émetteur de gérer cet amendement comme le règlement SEPA le prévoit.


9.4 Standards:IG mobility

L'écosystème mobility comporte quatre messages :


mobility AccountSwitchingRequest accountswitching.request@mobility

AccountSwitchingResponse accountswitching.response@mobility

AccountSwitchingForward Accountswitching.forward@mobility

AccountSwitchingNotify accountswitching.notify@mobility

9.4.1 Le message AIGUE-MARINE AccountSwitchingRequest

Ce message est envoyé par l'Établissement d'Arrivée (ÉA) à l'Établissement de Départ (ÉD). Il lui transmet les éléments du Mandat de Mobilité, et lui demande de communiquer les informations sur les opérations comprises dans le périmètre de la mobilité.

Le message a été spécifié par le CFONB, il est simplement inclus dans un message SEPAmail standard pour être transporté.

9.4.2 Le message AIGUE-MARINE AccountSwitchingResponse

Ce message est envoyé par l'Établissement de Départ (ÉD) à l'Établissement d'Arrivée (ÉA), en réponse à un message AccountSwitchingRequest.

Il contient :

• soit un rejet de la demande, auquel cas il en précise la raison • soit une acceptation de la demande, auquel cas il contient également les informations sur les

opérations contenues dans le périmètre de la mobilité.

Les règles d'usage de ce message sont les suivantes :

• Le nombre de messages AccountSwitchingResponse, en réponse à un seul message AccountSwitchingRequest, est laissé au choix de l'expéditeur (ÉD), et pourra donc être compris entre 1 et 4.

• Il doit impérativement y avoir, en cumul sur l'ensemble des messages d'envoi d'informations, 4 blocs d'informations : virements permanents émis, virements récurrents reçus, prélèvements reçus, chèques.

• Chaque message devra comporter au minimum un bloc • Un bloc pour lequel il n'y a aucune information à transmettre devra néanmoins être présent dans un

message, et renseigné à zéro.

Ce message a été spécifié par le CFONB, il est simplement inclus dans un message SEPAmail standard pour être transporté.

9.4.3 Le message AIGUE-MARINE AccountSwitchingForward

Ce message est envoyé par l'Établissement d'Arrivée (ÉA) vers chacun des Établissements d'Émetteurs (ÉÉ). Il reprend les informations obtenues de l'Établissement de Départ (ÉD) sur les opérations devant être modifiées par les émetteurs.

Le message a été spécifié par le CFONB, il est simplement inclus dans un message SEPAmail standard pour être transporté.


9.4.4 Le message AIGUE-MARINE AccountSwitchingNotify

9.4.4.1 Généralités

Ce message est envoyé par l'Établissement d'Émetteur (ÉÉ) à l'Établissement d'Arrivée (ÉA).

Il intervient obligatoirement en réponse à un message AccountSwitchingForward envoyé par l'ÉA.

9.4.4.2 Besoin fonctionnel

Même s'il n'est pas prévu dans le schéma de la Profession, ce flux retour est indispensable dans le cadre d'une messagerie correctement structurée. En effet, le destinataire d'un message doit au minimum disposer d'un moyen d'indiquer que le contenu d'un message n'est pas correct.

Nous ne parlons pas ici de réponse protocolaire ou technique, qui est assurée par la missive d'acquittement, mais bien d'une réponse métier.

Voici par exemple un cas dans lequel ce message est indispensable :

• si l'établissement d'émetteur reçoit un message pour un émetteur qu’il ne peut pas joindre, par exemple parce qu’il n'est plus parmi ses clients, alors qu'il est responsable de l'acheminement de l'information vers cet émetteur, il doit pouvoir informer l'ÉA, pour que celui-ci puisse faire parvenir cette information à l’émetteur concerné et remplir ainsi son obligation légale.

Pour des raisons de responsabilité des uns et des autres, il est donc nécessaire d'avoir un flux retour.

9.4.4.3 Cas d'usage

Dans le cadre actuel, pour simplifier la mise en place du flux 4R, seuls les messages à l'initiative de l'ÉÉ sont prévus.

Voici les deux cas d'usage concernés :

• positif : message pouvant être transmis à l'émetteur • négatif : message non transmis, pour une raison à préciser, par exemple

o émetteur inconnu o émetteur non joignable

9.4.4.4 Fonctionnement du message

L'ÉÉ doit envoyer un et un seul message AccountSwitchingNotify par message AccountSwitchingForward reçu.

Il doit être envoyé aussitôt que possible, c'est-à-dire dès que les éléments internes à l'ÉÉ permettent de déterminer si l'émetteur est connu et si le message pourra lui être transmis.

Il n'est pas nécessaire que le message ait été effectivement envoyé à l'émetteur pour envoyer le message AccountSwitchingNotify positif.

Le délai opérationnel d'envoi du flux retour sera donc de deux jours ouvrables.


9.4.4.5 Contenu du message

Le contenu du message est simple :

• le rappel des éléments de la demande, selon les principes de SEPAmail (messages auto-portés) • une réponse, positive ou négative • si elle est négative, éventuellement une précision sur son statut (pourquoi est-elle négative ?)

Rappelons que les éléments de nature commerciale, du genre "plus de relation entre l'émetteur et son client", doivent rester strictement dans la sphère des relations entre l'Émetteur et le Client.

Le message a été conçu selon les mêmes lignes que ceux du CFONB, en ajoutant simplement un bloc 2 au message AccountSwitchingForward que l'ÉÉ reçoit. Ce bloc 2 peut donc avoir deux contenus, selon que le message est positif ou négatif.

Dans le cas positif, le contenu est fixe (code de retour positif TS01), l'ÉÉ conservant la possibilité d'ajouter des précisions dans le champ AdditionalInformation.

Dans le cas négatif, le code de retour peut prendre l'une des 3 valeurs suivantes :

• BE01 (InconsistentWithEndCustomer, message incorrect) • BE06 (UnknownEndCustomer, émetteur inconnu ou ne pouvant être joint) • MS03 (NotSpecifiedReasonAgentGenerated, autres cas)

9.4.4.6 Extensions futures

Dans des versions ultérieures, explicitement exclues du périmètre actuel de SEPAmail, il pourrait être possible de prendre en compte d'autres cas d'usage de ce message, notamment à l'initiative de l'émetteur :

• le cas négatif o Client inconnu (ou plus de contrat en cours) o Modification déjà réalisée

• le cas positif o client identifié, modification réalisée

9.4.5 Schémas XML

Voici les schémas XML des 4 messages de l'écosystème mobility. Là aussi, les trois premiers proviennent du CFONB.

Nom Schéma

AccountSwitchingRequest Schéma

AccountSwitchingResponse Schéma

AccountSwitchingForward Schéma

AccountSwitchingNotify Schéma

Les valeurs renseignées dans la colonne « Statut FR » des guides d’implémentations des messages ont les significations suivantes spécifiées dans le tableau ci-dessous :


Code Signification Commentaires

M Obligatoire

(Mandatory)

Obligatoire dans le message.

Utilisation : S'applique aux éléments dont le caractère obligatoire ne fait pas l'objet d'un choix marqué par un "ou exclusif" (XOr)

R Requis

(Required)

Dans le standard noté optionnel [0..1], mais rendu obligatoire dans le guide par la communauté française.

Utilisé également quand la norme identifie une information comme optionnelle retenue par la communauté française (N si non retenue) mais composée de deux sous-composants obligatoires avec un « ou exclusif » {Or [1..1] Or [1..1] }.

D Dépendant

(Dependent)

Obligatoire sous certaines conditions, en particulier en fonction d'autres données dans le message.

Utilisation : Lorsqu’il s’agit d’un sous-composant coté [1..1] dépendant d’un composant retenu comme optionnel.

S'applique également aux éléments obligatoires qui dépendent par exemple d'un choix marqué par un "ou exclusif" (XOr).

A Recommandé ou Conseillé

(Advised)

Utilisation vivement conseillée (l'information est utile pour l'un des intervenants ou pour son destinataire).

Utilisation : S'applique uniquement aux éléments optionnels.

O Optionnel

(Optional)

Peut être utile pour le destinataire mais n'est pas nécessaire au le traitement.

Utilisation : S'applique uniquement aux éléments optionnels.

N Non utilisé

(Not used)

Donnée non utilisée dans les messages de mobilité.

Utilisation : S'applique uniquement aux éléments optionnels


9.5 IG AccountSwitchingRequest

Index Or Level Message item XML Tag Mult. DataType Définition Statut FR

Commentaires

Message Root <AcctSwtchngInfSvcReq> [1..1] Composed M

1.0 Assignment <Assgnmt> [1..1] Composed Identifie le message de demande

M

1.1 � MessageIdentification <MsgId> [1..1] Max35Text Référence point à point, telle que fournie par l'assigneur et envoyée à la partie suivante dans la chaîne afin d'identifier de façon non ambiguë le message

M Référence du message

1.2 � CreationDateTime <CreDtTm> [1..1] ISODateTime Date et heure de création du message

M Date du message

1.3 � Creator <Cretr> [0..1] Composed Partie ayant créé la demande

O Etablissement d'arrivée Règle de formatage : A utiliser si l'établissement d'arrivée n'est pas l'émetteur ("assigner") du message

1.4 Or } �� Agent <Agt> [1..1] Composed Identification d'une institution financière

R

1.5 �� FinancialInstitutionIdentification <FinInstnId> [1..1] Composed Set d'éléments utilisés pour identifier de façon unique et non ambiguë une institution ou "branche" d'une institution financière

M



Commentaires

1.6 �� BICFI <BICFI> [0..1] BICFIIdentifier

Code d'identification d'une institution financière

R BIC de l'établissement d'arrivée

1.7 � Assigner <Assgnr> [1..1] Composed Partie qui assigne la demande à une autre partie. Il s'agit aussi de l'émetteur du message

M


R Banque émettrice du message


M



R BIC Banque émettrice

1.11 � Assignee <Assgne> [1..1] Composed Partie à laquelle la demande est assignée. Il s'agit aussi du récepteur du message.

M


R Banque réceptrice du message


M



Commentaires



R BIC de la banque réceptrice

2.0 AccountSwitchingInformationRequest <AcctSwtchngInfReq> [0..1] Composed Demande d'informations pour la mobilité bancaire

R

2.1 � AccountSwitchingReference <AcctSwtchngRef> [1..1] Composed Référence de mobilité M Donne la référence du mandat de mobilité et la date de signature du mandat pour la gestion de la preuve

2.2 �� AccountSwitchingIdentification <AcctSwtchngId> [1..1] Max35Text Identifiant de mobilité M Référence du mandat de mobilité telle que créée par l'établissement d'arrivée

2.3 �� DateOfSignature <DtOfSgntr> [1..1] ISODate Date de signature M Date de signature du mandat de mobilité

2.4 � StandingOrder <StndngOrdr> [0..1] Composed Ordre de virement permanent

O Règle de formatage :

Obligatoire si le client a des ordres de virements permanents en place dans l’établissement de départ



Commentaires

2.5 �� ToDate <ToDt> [1..1] ISODate Jusqu'à cette date M Date demandée par le client en mobilité à laquelle l'établissement de départ doit cesser d'exécuter les virements permanents pour le compte du client en mobilité

2.6 � BalanceSwitchingRequest <BlSwtchRqust> [0..1] Composed Demande de virement de solde

O Date indiquée par le client en mobilité à laquelle l'établissement de départ devra virer le solde du compte du client en mobilité vers l'établissement d'arrivée

2.7 �� RequestedExecutionDate <ReqdExctnDt> [1..1] ISODate Date demandée de virement de solde

M

2.8 � AccountOwner <AcctOwnr> [1..n] Composed Détenteur(s) du compte

M Règle de formatage : A répéter pour chaque détenteur pour les comptes en indivision ou les comptes joints

2.9 {Or �� Party <Pty> [1..1] Composed Identification d'une personne ou organisation

R

2.10 �� Name <Nm> [0..1] Max140Text Nom utilisé pour identifier une partie

R Règle de formatage : Limité à 70 caractères



Commentaires

2.11 �� PostalAddress <PstlAdr> [0..1] Composed Adresse de la partie A Règle de formatage : A renseigner obligatoirement si différente de UpdatedPartyAccountAndIdentification -> Party -> PostalAddress

2.12 �� Country <Ctry> [0..1] CountryCode Code pays ISO de l'adresse

R

2.13 �� AddressLine <AdrLine> [0..7] Max70Text Ligne d'adresse en format libre.

R Règle de formatage : 2 occurrences maximum

2.14 �� Identification <Id> [0..1] Composed Identification unique et non ambiguë d'une partie

R

2.15 Or } �� PrivateIdentification <PrvtId> [1..1] Composed Identification unique et non ambiguë d'une personne physique

R Obligatoirement un particulier

2.16 �� DateAndPlaceOfBirth <DtAndPlcOfBirth> [0..1] Composed Date et lieu de naissance

R

2.17 �� BirthDate <BirthDt> [1..1] ISODate Date de naissance M

2.18 �� CityOfBirth <CityOfBirth> [1..1] Max35Text Lieu de naissance M

2.19 �� CountryOfBirth <CtryOfBirth> [1..1] CountryCode Pays de naissance M

2.20 �� ContactDetails <CtctDtls> [0..1] Composed Set d'éléments utilisés pour indiquer comment contacter la partie

O Règle de formatage : Si contact details est présent, au moins une des sous-balise suivantes doit-être renseignée



Commentaires

2.21 �� PhoneNumber <PhneNb> [0..1] PhoneNumber

Numéro de téléphone O

2.22 �� MobileNumber <MobNb> [0..1] PhoneNumber

Numéro de téléphone mobile

O

2.23 �� EmailAddress <EmailAdr> [0..1] Max2048Text

Adresse pour l'envoi de message électronique (e-mail)

O

2.24 � MandateHolder <MndtHldr> [0..n] Composed Personne ou organisation ayant autorité sur le compte

O Utilisable pour les mandataires légaux uniquement (cas de comptes sous tutelles, ou cas de représentation)

2.25 {Or �� Party <Pty> [1..1] Composed Identification d'une personne physique ou d'une organisation

M


R Règle de formatage : Limité à 70 caractères

2.27 �� PostalAddress <PstlAdr> [0..1] Composed Adresse de la partie R


R

2.29 �� AddressLine <AdrLine> [0..7] Max70Text Ligne d'adresse en format libre


2.30 �� Identification <Id> [0..1] Composed Identification unique et non ambiguë d'une partie

R



Commentaires

2.31 {Or �� OrganisationIdentification <OrgId> [1..1] Composed Moyen unique et non ambigu d'identifier une organisation

M Règle de formatage : A utiliser lorsqu'une personne morale est mandataire sur le compte en mobilité uniquement (cas d'associations par exemple)

2.32 �� Other <Othr> [0..n] Composed Autre identifiant O Règle de formatage : Limité à 1 occurrence seulement

2.33 �� Identification <Id> [1..1] Text Fournit l'identification de la partie

M

2.34 �� SchemeName <SchmeNm> [0..1] Composed Nom du scheme d'identification, sous forme de code ou de texte libre

O

2.35 {{Or �� Code <Cd> [1..1] ExternalOrganisation Identification1Code

Code identifiant le type de scheme utilisé pour l'identification

M

2.36 Or}} �� Proprietary <Prtry> [1..1] Max35Text Codification propriétaire

M

2.37 �� Issuer <Issr> [0..1] Max35Text Emetteur de l'identifiant

O

2.38 Or } �� PrivateIdentification <PrvtId> [1..1] Composed Identification unique et non ambiguë d'une personne physique

M

2.39 �� DateAndPlaceOfBirth <DtAndPlcOfBirth> [0..1] Composed Date et lieu de naissance

R



Commentaires

2.40 �� BirthDate <BirthDt> [1..1] ISODate Date de naissance M

2.41 �� CityOfBirth <CityOfBirth> [1..1] Max35Text Lieu (ville) de naissance

M

2.42 �� CountryOfBirth <CtryOfBirth> [1..1] CountryCode Pays de naissance M

2.43 �� ContactDetails <CtctDtls> [0..1] Composed Set d'éléments utilisés pour indiquer comment contacter la partie

O Règle de formatage : Si contact details est présent, au moins une des sous-balises suivantes doit-être renseignée

2.44 �� PhoneNumber <PhneNb> [0..1] PhoneNumber

Numéro de téléphone O

2.45 �� MobileNumber <MobNb> [0..1] PhoneNumber

Numéro de téléphone mobile

O

2.46 �� EmailAddress <EmailAdr> [0..1] Max2048Text

Adresse pour l'envoi de message électronique (e-mail)

O

3.0 Modification <Mod> [1..n] Composed Information concernant la donnée modifiée

M Règle de formatage : Une seule occurrence de "modification" est autorisée

3.1 � Identification <Id> [1..1] Max35Text Identification unique, telle qu'assignée par la partie émettrice, pour identifier de façon non ambiguë l'information de modification au sein du message

M



Commentaires

3.2 � OriginalPartyAndAccountIdentification <OrgnlPtyAndAcctId> [0..1] Composed Identification d'origine de la partie et du compte

R Informations issues du Relevé d'Identité Bancaire de l'établissement d'origine

3.3 �� Party <Pty> [1..1] Composed Identification d'une personne physique ou d'une organisation

M


R Intitulé du compte tel que sur le Relevé d'Identité Bancaire Règle de formatage : Limité à 70 caractères

3.5 �� PostalAddress <PstlAdr> [0..1] Composed Adresse de la partie D Adresse du relevé d'identité bancaire de l'établissement de départ

Règle de formatage :

Si présente sur Relevé d’Identité Bancaire


R



3.8 �� Account <Acct> [0..1] Composed Identification non ambiguë du compte de la partie

R Numéro de compte du client en mobilité dans l'établissement de départ



Commentaires

3.9 {Or �� IBAN <IBAN> [1..1] IBAN2007Identifier

International Bank Account number (IBAN) - Identifiant international de compte

M IBAN du client dans l'établissement de départ

3.10 �� Agent <Agt> [0..1] Composed Identification d'une institution financière

R Etablissement de départ


M



R BIC établissement de départ

3.13 � UpdatedPartyAndAccountIdentification <UpdtdPtyAndAcctId> [1..1] Composed Identification de la partie et/ou du compte dans l'établissement d'arrivée

M Informations issues du Relevé d'Identité Bancaire de l'établissement d'arrivée


M


R Intitulé du compte dans l'établissement d'arrivée Règle de formatage : Limité à 70 caractères



Commentaires

3.16 �� PostalAddress <PstlAdr> [0..1] Composed Adresse de la partie A Adresse du relevé d'identité bancaire de l'établissement d'arrivée


à ne renseigner que si présente dans le relevé


R



3.19 �� Account <Acct> [0..1] Composed Identification non ambiguë du compte d'une partie

D Numéro de compte du client en mobilité dans l'établissement d'arrivée Règle de formatage : Présence obligatoire si demande de virement de solde



R IBAN du client dans l'établissement d'arrivée



Commentaires


D Etablissement d'arrivée

Règle de formatage : Présence obligatoire si demande de virement de solde


M



R BIC Etablissement d'arrivée


9.6 IG AccountSwitchingResponse

Index Or Level Message Item XML Tag Mult. DataType Définition

Stat

ut

FR

Commentaires

Message Root <AcctSwtchngInfSvcRptV01> [1..1] Composed M

1.0 Assignment <Assgnmt> [1..1] Composed Identifie le message de réponse

M


M

1.2 � CreationDateTime <CreDtTm> [1..1] ISODateTime Date et heure de création du du message

M

1.3 � Creator <Cretr> [0..1] Composed Partie ayant créé la demande de mobilité

O Etablissement d'arrivée Règle de formatage : A utiliser si l'établissement d'arrivée n'est pas le destinataire ("assignee") du message et/ou si "creator" était renseigné dans le flux 2 reçu par l'établissement de départ


R



Stat

ut

FR

Commentaires


M





M




M






Stat

ut

FR

Commentaires

1.11 � Assignee <Assgne> [1..1] Composed Partie à laquelle la demande est assignée. Il s'agit aussi du récepteur du message

M




M



R BIC banque réceptrice

2.0 AccountSwitchingInformationDetails <AcctSwtchngInfDtls> [0..1] Composed Information sur le type de réponse, positive ou négative

R Si Account Switching Refusal non utilisé, alors réponse positive et TransactionReport requis

2.1 � AccountSwitchingRefusal <AcctSwtchngRefsl> [0..1] Composed Set d'éléments indiquant une réponse négative à la demande de mobilité (refus de réponse) et sa motivation

D Règle de formatage : A utiliser uniquement en cas de refus de la demande par l'établissement de départ. Dans ce cas, l'établissement de départ ne fournit pas la liste des opérations à l'établissement d'arrivée et motive son refus Note : Dans ce cas, le Multiple Message Indicator n'est pas utilisé



Stat

ut

FR

Commentaires

2.2 �� Reason <Rsn> [1..1] Composed Motif du refus M Règle de formatage : Seuls les codes prévus par le CFONB sont utilisables

2.3 {Or �� Code <Cd> [1..1] Code Code de refus M Utiliser les listes externes ReturnReason et StatusReason

2.4 Or} �� Proprietary <Prtry> [1..1] Max35Text Code propriétaire M Règle de formatage : A n'utiliser que si code non présent dans les listes externes ReturnReason et StatusReason

2.5 �� AdditionalInformation <AddtlInf> [0..*] Max105Text Information additionnelle sur le motif de refus

O Détail du motif de rejet de la demande

2.6 � OriginalMessageNameIdentification <OrgnlMsgNmId> [0..1] Max35Text Nom du message d'origine

R Règle de formatage : Seul AcctSwtchngInfSvcReq (pour "AccountSwitching InformationServiceRequest") est autorisé

2.7 � OriginalMessageIdentification <OrgnlMsgId> [0..1] Max35Text Identifiant du message d'origine

R

2.8 � MultipleMessageIndicator <MltplMsgInd> [0..1] Composed Indicateur permettant de spécifier si la réponse est scindée en plusieurs messages

D Règle de formatage : Utilisable seulement si account switching refusal n'est pas utilisé. Pour indiquer si réponse en plusieurs messages

2.9 �� Indicator <Ind> [1..1] TrueFalseIndicator

Indicateur M Règle de formatage : Si true = réponse se découpe en plusieurs messages, si false = réponse unique



Stat

ut

FR

Commentaires

3.0 Modification <Mod> [1..*] Composed Information concernant la donnée modifiée

M Règle de formatage : Par défaut, une seule occurrence de "modification" est autorisée ; Si dans les 13 mois la banque a procédé à une renumérotation des comptes (fusion…), une seconde occurrence est autorisée pour renseigner l'"OriginalPartyAndAccountIdentification" correspondant à l'autre numéro de compte


M

3.2 � AccountSwitchingReference <AcctSwtchngRef> [1..1] Composed Référence de mobilité

M Donne la référence du mandat de mobilité et la date de signature du mandat pour la gestion de la preuve

3.3 �� AccountSwitchingIdentification <AcctSwtchngId> [1..1] Max35Text Identifiant de mobilité

M Référence du mandat de mobilité telle que créée par l'établissement d'arrivée



R Informations telles que fournies dans le message reçu par l'établissement de départ


M



Stat

ut

FR

Commentaires


R Intitulé du compte dans l'établissement de départ Règle de formatage : Limité à 70 caractères

3.8 �� PostalAddress <PstlAdr> [0..1] Composed Adresse de la partie

D Règle de formatage :

Si présente dans le flux 2 reçu


R

3.10 �� AddressLine <AdrLine> [0..7] Max70Text Lignes d'adresse en format libre



R N° de compte du client en mobilité dans l'établissement de départ







M



R BIC de l'établissement de départ



Stat

ut

FR

Commentaires


M Informations telles que fournies dans le message reçu par l'établissement de départ


M


R Intitulé du compte dans l'établissement d'arrivée Règle de formatage : Limité à 70 caractères

3.19 �� PostalAddress <PstlAdr> [0..1] Composed Adresse de la partie


Si présente dans le flux 2 reçu


R

3.21 �� AddressLine <AdrLine> [0..7] Max70Text Lignes d'adresse en format libre.

R Règle de formatage : 2 occurrences maximum.


D Numéro du compte du client en mobilité dans l'établissement d'arrivée Règle de formatage :

Si présent dans le flux 2 reçu



R IBAN du client dans l'établissement d'arrivée



Stat

ut

FR

Commentaires


D Etablissement d'arrivée


Si présent dans le flux 2 reçu


M



R BIC établissement d'arrivée

3.27 � AdditionalInformation <AddtlInf> [0..1] Max140Text Information

complémentaire

O Pour compléter si besoin

l'information liée à la

modification

4.0 � TransactionReport <TxRprt> [0..n] Composed Liste des types

d'opérations

reprises dans cette

réponse.


Requis si account switching

refusal n'est pas utilisé ;

utilisable autant de fois que de

familles d'opérations

rapportées, soit au maximum 4

fois par message

4.1 �� TransactionsSummary <TxsSummry> [0..1] Composed Ensemble d'information sur les écritures

R

4.2 �� TotalEntriesPerBankTransactionCode <TtlNtriesPerBkTxCd> [0..n] Composed Total des écritures par code opération bancaire

R



Stat

ut

FR

Commentaires

4.3 �� NumberOfEntries <NbOfNtries> [0..1] Max15NumericText

Nombre total d'écritures pour ce code opération

R

4.4 �� BankTransactionCode <BkTxCd> [1..1] Composed Code opération bancaire

M Code générique à ce niveau ; les BTCs sont exprimés sens vu du client de l'établissement de départ

4.5 �� Domain <Domn> [0..1] Composed Domaine. R

4.6 �� Code <Cd> [1..1] ExternalBankTransactionDomain1Code

Code M Règle de formatage : Renseigner avec "PMNT"

4.7 �� Family <Fmly> [1..1] Composed Famille M

4.8 ��

�

Code <Cd> [1..1] ExternalBankTransactionFamily1Code

Code M Règle de formatage : Renseigner avec "RDDT" pour prélèvement reçus, "RCDT" pour virement reçu "ICDT" pour virement émis, "ICHQ" pour chèque

4.9 ��

�

SubFamilyCode <SubFmlyCd> [1..1] ExternalBankTransactionSubFamily1Code

Sous famille M Règle de formatage : Renseigner avec "OTHR" pour un code générique

5.0 �� TransactionDetails <TxDtls> [0..n] Composed Niveau Opération R


R Code spécifique à ce niveau ; les BTCs sont exprimés sens vu du client de l'établissement de départ

5.2 �� Domain <Domn> [0..1] Composed Domaine. R



Stat

ut

FR

Commentaires


"PMNT" pour Paiement (Payment)

M Règle de formatage : Renseigner avec "PMNT"


5.5 �� Code <Cd> [1..1] ExternalBankTransactionFamily1Code

Code famille M Règle de formatage : Renseigner avec : "RDDT" pour prélèvement reçus, "RCDT" pour virement reçu "ICDT" pour virement émis, "ICHQ" pour chèque

5.6 �� SubFamilyCode <SubFmlyCd> [1..1] ExternalBankTransactionSubFamily1Code

Code sous famille M Règle de formatage : Renseigner avec : "ESDD" pour prélèvement SEPA (Core SDD) "BBDD" pour prélèvement SEPA interentreprises (B2B SDD) "ESCT" pour virement SEPA "XBCT" pour virement international "STDO" pour les virements permanents. "UPCQ" pour les chèques non encaissés (Unpaid Cheque)

5.7 �� References <Refs> [0..1] Composed Références de la transaction

D Obligatoire si figure dans les opérations reçues. Obligatoire pour les chèques

5.8 �� EndToEndIdentification <EndToEndId> [0..1] Max35Text Référence de bout-en-bout

D Règle de formatage : Dépend du type d'opération ; obligatoire pour les opérations SEPA

5.9 �� MandateIdentification <MndtId> [0..1] Max35Text Identifiant du mandat de prélèvement

D Règle de formatage : Dépend du type d'opération ; obligatoire pour les prélèvements SEPA, Référence unique du mandat (RUM), renseignée par le créancier



Stat

ut

FR

Commentaires

5.10 �� ChequeNumber <ChqNb> [0..1] Max35Text Numéro du chèque D Règle de formatage : Dépend du type d'opération ; obligatoire pour les chèques

5.11 �� StandingOrderDetails <StndngOrdrDtls> [0..1] Composed D Règle de formatage : Dépend du type d'opération ; fournit les détails des ordres de virements permanents

5.12 �� Amount <Amt> [1..1] CurrencyAndAmount

Montant du virement permanent

M

5.13 �� Frequency <Frquncy> [1..1] Max4Text Frequence à laquelle le virement permanent est exécuté (par exemple mensuelle)

M Règle de formatage : Texte ou Frequency Code, voir http://www.iso20022.org/standardsrepository/public/wqt/Description/mx/dico/codesets/_asTIqdp-Ed-ak6NoX_4Aeg_-2101415313

5.14 �� Day <Day> [1..1] Number Jour dans la période où le virement permanent doit être exécuté

M

5.15 �� EndDate <EndDt> [0..1] ISODate Date de fin du virement permanent

O Date du dernier virement à émettre pour ce virement permanent

5.16 �� RelatedParties <RltdPties> [0..1] Composed Entités concernées par la transaction

R

5.17 �� Debtor <Dbtr> [0..1] Composed Information sur le débiteur

D Règle de formatage : Dépendant du type de transaction ; virement reçus seulement

5.18 �� Name <Nm> [0..1] Max140Text Nom du débiteur R Règle de formatage : Limité à 70 caractères



Stat

ut

FR

Commentaires

5.19 �� Identification <Id> [0..1] Composed Identifiant du débiteur

O

5.20 {Or �� OrganisationIdentification <OrgId> [1..1] Composed Identifiant de personne morale

M

5.21 ��

�

AnyBIC <AnyBIC> [0..1] AnyBICIdentifier

BIC D Règle de formatage : Si présent, "Other" non renseigné

5.22 ��

�

Other <Othr> [0..n] Composed Autre identifiant D Règles de formatage : Limité à 1 occurrence seulement Si présent, AnyBIC non renseigné

5.23 ��

��

Identification <Id> [1..1] Max35Text Identifiant M

5.24 ��

��

SchemeName <SchmeNm> [0..1] Composed Nom du scheme d'identification, sous forme de code ou de texte libre

O

5.25 {{Or ��

Code <Cd> [1..1] Code Code M

5.26 Or}} ��

Proprietary <Prtry> [1..1] Max35Text Codification propriétaire

M

5.27 ��

��

Issuer <Issr> [0..1] Max35Text Emetteur de l'identifiant

O

5.28 Or} �� PrivateIdentification <PrvtId> [1..1] Composed Identifiant de personne physique

M

5.29 ��

�

DateAndPlaceOfBirth <DtAndPlcOfBirth> [0..1] Composed Date et lieu de naissance

O

5.30 ��

��

BirthDate <BirthDt> [1..1] ISODate Date de naissance M



Stat

ut

FR

Commentaires

5.31 ��

��

CityOfBirth <CityOfBirth> [1..1] Max35Text Ville de naissance M

5.32 ��

��

CountryOfBirth <CtryOfBirth> [1..1] CountryCode Pays de naissance M

5.33 ��

�

Other <Othr> [0..n] Composed Autre identifiant O Règle de formatage : Limité à 1 occurrence seulement

5.34 ��

��


5.35 ��

��


O

5.36 �� DebtorAccount <DbrtAcct> [0..1] Composed Compte du débiteur


5.37 �� Identification <Id> [1..1] Composed Identifiant du compte

M



D Règle de formatage : Si utilisé, "Other" ne peut pas être renseigné

5.39 Or} �� Other <Othr> [1..1] Composed Autre identifiant de compte

D Règle de formatage : Utilisable seulement si IBAN non disponible (émetteur étranger de virements)

5.40 ��

�

Identification <Id> [0..1] Max34Text Identifiant de compte en format libre

R

5.41 �� UltimateDebtor <UltmtDbtr> [0..1] Composed Identification du tiers débiteur




Stat

ut

FR

Commentaires

5.42 �� Name <Nm> [0..1] Max140Text Nom du tiers débiteur

O Règle de formatage : Limité à 70 caractères

5.43 �� Identification <Id> [0..1] Composed Identifiant du tiers débiteur

O


M

5.45 ��

�



5.46 ��

�


5.47 ��

��


5.48 ��

��


O

5.49 {{Or ��


5.50 Or}} ��


M

5.51 ��

��


O


M

5.53 ��

�


O



Stat

ut

FR

Commentaires

5.54 ��

��


5.55 ��

��


5.56 ��

��


5.57 ��

�


5.58 ��

��


5.59 ��

��


O

5.60 �� Creditor <Cdtr> [0..1] Composed Informations sur le créancier

D Règle de formatage : Dépendant du type de transaction ; prélèvement reçu ou virement permanent émis seulement

5.61 �� Name <Nm> [0..1] Max140Text Nom du créancier R Règle de formatage : Limité à 70 caractères

5.62 �� Identification <Id> [0..1] Composed Identifiant du créancier : ICS pour un prélèvement SEPA

D Règles de formatage : Dépendant du type de transaction

Obligatoire si prélèvement reçu : ICS créancier sous PrivateIdentification


M Règles de formatage : Dépendant du type de transaction

Utilisable pour les bénéficiaires de virements permanents



Stat

ut

FR

Commentaires

5.64 ��

�



5.65 ��

�


5.66 ��

��


5.67 ��

��


O

5.68 {{Or ��


5.69 Or}} ��


M

5.70 ��

��


O

5.71 Or} �� PrivateIdentification <PrvtId> [1..1] Composed Identifiant de personne physique, ou identifiant créancier SEPA (ICS) pour les prélèvements SEPA

M Règles de formatage : Dépendant du type de transaction

ICS créancier pour les prélèvements Utilisable également pour les bénéficiaires de virements permanents

5.72 ��

�


O Utilisable pour les bénéficiaires de virements permanents

5.73 ��

��




Stat

ut

FR

Commentaires

5.74 ��

��


5.75 ��

��


5.76 ��

�

Other <Othr> [0..n] Composed Autre identifiant O Règles de formatage : Limité à 1 occurrence seulement Obligatoire pour les créanciers de prélèvements SEPA

5.77 ��

��

Identification <Id> [1..1] Max35Text Identififant du créancier.

M ICS pour un prélèvement SEPA

5.78 SchemeName <SchmeNm> [0..1] Composed Nom du scheme d'identification, sous forme de texte libre

O

5.79 Or} Proprietary <Prtry> [1..1] Max35Text Code propriétaire R Règle de formatage : Valorisé à "SEPA" pour les ICS

5.80 ��

��


O

5.81 �� CreditorAccount <CdtrAcct> [0..1] Composed Compte du créancier

D Règles de formatage :

Dépendant du type de transaction

Prélèvement reçu ou virement permanent émis


M



Stat

ut

FR

Commentaires



D Règles de formatage :

Obligatoire pour les prélèvements

Pour les virements permanents, ne pas renseigné si « Other » est utilisé

5.84 Or} �� Other <Othr> [1..1] Composed Autre identifiant

de compte


Pour les virements

permanents seulement, et

uniquement pour compte

bénéficiaire hors SEPA

5.84a ��

�

Identification <Id> [0..1] Max34Text Identifiant de compte en format libre.

R

5.85 �� UltimateCreditor <UltmtCdtr> [0..1] Composed Informations sur le tiers créancier


Dépendant du type de transaction ; prélèvement reçu ou virement permanent

5.86 �� Name <Nm> [0..1] Max140Text Nom du tiers créancier


5.87 �� Identification <Id> [0..1] Composed Identifiant du tiers créancier

O


M

5.89 ��

�



5.90 ��

�

Other <Othr> [0..n] Composed Autre identifiant D Règles de formatage : Une seule occurrence Si présent, "AnyBIC" non renseigné



Stat

ut

FR

Commentaires

5.91 ��

��


5.92 ��

��


O

5.93 {{Or ��


5.94 Or}} ��


M

5.95 ��

��


O


M

5.97 ��

�


O

5.98 ��

��


5.99 ��

��


5.100 ��

��


5.101 ��

�

Other <Othr> [0..n] Composed Identifiant O Règle de formatage : Limité à 1 occurrence seulement

5.102 ��

��


5.103 ��

��

Issuer [0..1] Max35Text Emetteur de l'identifiant

O



Stat

ut

FR

Commentaires

5.104 �� RelatedAgents <RltdAgts> [0..1] Composed R

5.105 �� DebtorAgent <DbtrAgt> [0..1] Composed Information sur la banque du débiteur

D Règle de formatage : Dépendant du type de transaction, renseigné pour virement reçu seulement


M



R BIC de la Banque du donneur d'ordre

5.108 �� CreditorAgent <CdtrAgt> [0..1] Composed Identification de la banque du créancier

D Règle de formatage : Dépendant du type de transactions, renseigné pour le prélèvement reçu et le virement permanent émis

5.109 �� FinancialInstitutionIdentification <FinInstnId> [1..1] Composed Identifiant de la banque du créancier

M



R BIC de la banque du créancier (prélèvement), BIC de la Banque du bénéficiaire (destinataire du virement)



Stat

ut

FR

Commentaires

5.111 �� RemittanceInformation <RmtInf> [0..1] Composed Motif du paiement D Règles de formatage : dépendant du type de transaction

Pas pour chèques Soit Unstructured soit Structured ; pas les deux ensembles

5.112 �� Unstructured <Ustrd> [0..n] Max140Text Motif du paiement sous forme non structurée

D Règle de formatage : Limité à 1 occurrence seulement

5.113 �� Structured <Strd> [0..n] Composed Motif du paiement sous forme structurée utilisé uniquement en cas de réception de prélèvement au format XML (pour le détail de la structure, cf. le guide prélèvement)

D Règle de formatage : Limité à 1 occurrence seulement. Uniquement pour les opérations SEPA

5.114 �� CreditorReferenceInformation <CdtrRefInf> [0..1] Composed Référence fournie par le créancier

R

5.115 �� Type <Tp> [0..1] Composed Type de référence O

5.116 ��

�

CodeOrProprietary

<CdOrPrtry> [1..1] Composed Code ou propriétaire

M

5.117 {Or ��

Code <Cd> [1..1] DocumentType3Code

Code R Règle de formatage : La valeur "SCOR" est obligatoire (StructuredCommunicationReference)

5.118 �� Reference <Ref> [0..1] Max35Text Référence R


9.7 IG AccountSwitchingForward


Stat

ut

FR

Commentaires

Message Root <AcctSwtchngInfSvcRptV01> [1..1] Composed M

1.0 Assignment <Assgnmt> [1..1] Composed Identifie le message de transmission

M


M

1.2 � CreationDateTime <CreDtTm> [1..1] ISODateTime Date et heure de création du message

M

1.3 � Creator <Cretr> [0..1] Composed Partie ayant créé la demande de mobilité

O Etablissement d'arrivée. Règle de formatage : A utiliser si l'établissement d'arrivée n'est pas l'"assigner" du message


R


M



Stat

ut

FR

Commentaires





M




M




1.11 � Assignee <Assgne> [1..1] Composed Partie à laquelle la demande est assignée. Il s'agit aussi du récepteur du message

M





Stat

ut

FR

Commentaires


M





M Règle de formatage 1 : Par défaut une seule occurrence de "modification" est autorisée Règle de formatage 2 : Une seconde occurrence est autorisée si elle figure dans le message de "AccountSwitchingInformationServiceResponse" reçu


M

3.2 � AccountSwitchingReference <AcctSwtchngRef> [1..1] Composed Identifaréférence du mandat de mobilité et la date de signature du mandat pour la gestion de la preuve

M Donne la référence du mandat de mobilité et la date de signature du mandat pour la gestion de la preuve



Stat

ut

FR

Commentaires

3.3 �� AccountSwitchingIdentification <AcctSwtchngId> [1..1] Max35Text Identifiant de mobilité

M Référence du mandat de mobilité telle que créée par l'établissement d'arrivée



R Informations issues du Relevé d'Identité Bancaire de l'établissement d'origine


M

3.7 �� Name <Nm> [0..1] Max140Text

Nom utilisé pour identifier une partie











Stat

ut

FR

Commentaires


M





M Informations issues du Relevé d'Identité Bancaire de l'établissement d'arrivée


M


R Intitulé du compte dans l'établissement d'arrivée. Règle de formatage : Limité à 70 caractères


R compte du client en mobilité dans l'établissement d'arrivée



M IBAN du client dans l'établissement d'arrivée



Stat

ut

FR

Commentaires

3.18 �� Agent [0..1] Composed Identification d'une institution financière

R Etablissement d'arrivée


M




3.21 � AdditionalInformation <AddtlInf> [0..1] Max140Text Information complémentaire, format libre, pour compléter l'information liée à la modification

O

4.0 � TransactionReport <TxRprt> [0..n] Composed Liste des types d'opérations reprises dans cette réponse

R Règle de formatage : Utilisable autant de fois que de familles d'opérations rapportées, soit au maximum 2 fois par message

4.1 �� TransactionsSummary <TxsSummry> [0..1] Composed Ensemble d'information sur les écritures

R

4.2 �� TotalEntriesPerBankTransactionCode <TtlNtriesPerBkTxCd> [0..n] Composed Total des écritures par code opération bancaire

R

4.3 �� NumberOfEntries <NbOfNtries> [0..1] Max15NumericText

Nombre total d'écritures pour ce code opération

R



Stat

ut

FR

Commentaires


M Code générique à ce niveau. Les BTC sont exprimés sens vu de l'émetteur

4.5 �� Domain <Domn> [0..1] Composed Domaine R


Code M Règle de formatage : Renseigner avec "PMNT"


4.8 ��

�

Code <Cd> [1..1] ExternalBankTransactionFamily1Code

Code M Règle de formatage : Renseigner avec "IDDT" pour prélèvement émis, "ICDT" pour virement émis

4.9 ��

�

SubFamilyCode <SubFmlyCd> [1..1] ExternalBankTransactionSubFamily1Code

Sous famille M Règle de formatage : Renseigner avec "OTHR" pour un code générique

5.0 �� TransactionDetails <TxDtls> [0..n] Composed Niveau Opération R


R Code spécifique à ce niveau. Les BTC sont exprimés sens vu de l'émetteur

5.2 �� Domain <Domn> [0..1] Composed Domaine R


"PMNT" pour Paiement (Payment)

M Règle de formatage : Renseigner avec "PMNT"


5.5 �� Code <Cd> [1..1] ExternalBankTransactionFamily1Code

Code famille M Règle de formatage : Renseigner avec "IDDT" pour prélèvement émis, "ICDT" pour virement émis



Stat

ut

FR

Commentaires

5.6 �� SubFamilyCode <SubFmlyCd> [1..1] ExternalBankTransactionSubFamily1Code

Code sous famille M Règle de formatage : Renseigner avec "ESDD" pour prélèvement SEPA (Core SDD) "BBDD" pour prélèvement SEPA Interentreprises (B2B SDD)

"XBCT" pour virements internationaux "ESCT" pour virement SEPA

5.7 �� References <Refs> [0..1] Composed Références de la transaction

R

5.8 �� EndToEndIdentification <EndToEndId> [0..1] Max35Text Référence de bout-en-bout Utilisé notamment pour les opérations SEPA

D Règle de formatage : Obligatoire pour opérations SEPA

5.9 �� MandateIdentification <MndtId> [0..1] Max35Text Concerne les prélèvements SEPA. Référence unique du mandat (RUM), renseignée par le créancier

D Règle de formatage : Dépendant du type de transaction. Obligatoire pour prélèvement émis

5.10 �� RelatedParties <RltdPties> [0..1] Composed Entités concernées par la transaction

R Règle de formatage :

Un seul compte d’émetteur possible ; DebtorAccount et/ou CreditorAccount doivent toujours être le même

5.11 �� Debtor <Dbtr> [0..1] Composed Information sur le débiteur

D Règle de formatage : Dépendant du type de transaction Obligatoire pour virement émis

5.12 �� Name <Nm> [0..1] Max140Text Nom du débiteur R Règle de formatage : Limité à 70 caractères



Stat

ut

FR

Commentaires

5.13 �� Identification <Id> [0..1] Composed Identifiant du débiteur

O


M

5.15 ��

�


BIC D Règle de formatage : Si présent, Other non renseigné

5.16 ��

�

Other <Othr> [0..n] Composed Autre identifiant D Règle de formatage : Limité à 1 occurrence seulement Si présent, AnyBIC non renseigné

5.17 ��

��


5.18 ��

��


O

5.19 {{Or ��


5.20 Or}} ��


M

5.21 ��

��


O


M

5.23 ��

�


O

5.24 ��

��


5.25 ��

��




Stat

ut

FR

Commentaires

5.26 ��

��


5.27 ��

�

Other [0..n] Composed Autre identifiant O Règle de formatage : Limité à 1 occurrence seulement

5.28 ��

��

Identification [1..1] Max35Text Identifiant M

5.29 ��

��

Issuer [0..1] Max35Text Emetteur de l'identifiant

O

5.30 �� DebtorAccount <DbrtAcct> [0..1] Composed Compte du débiteur

D Règle de formatage : Dépendant du type de transaction. Obligatoire pour virement émis


M



D Règle de formatage : Si utilisé, "Other" ne peut pas être renseigné

5.33 Or} �� Other <Othr> [1..1] Composed Autre identifiant de compte utilisable si IBAN non disponible (émetteur étranger de virements)

D Règle de formatage : Utilisable seulement si IBAN non disponible (émetteur étranger de virements)

5.34 ��

�

Identification <Id> [0..1] Max34Text Identifiant de compte en format libre

R

5.35 �� UltimateDebtor <UltmtDbtr> [0..1] Composed Identification du tiers débiteur

D Règles de formatage : Dépendant du type de transaction Virement émis seulement



Stat

ut

FR

Commentaires

5.36 �� Name <Nm> [0..1] Max140Text Nom du tiers débiteur


5.37 �� Identification <Id> [0..1] Composed Identifiant du tiers débiteur

O


M

5.39 ��

�



5.40 ��

�


5.41 ��

��


5.42 ��

��


O

5.43 {{Or ��


5.44 Or}} ��


M

5.45 ��

��


O


M

5.47 ��

�


O

5.48 ��

��




Stat

ut

FR

Commentaires

5.49 ��

��


5.50 ��

��


5.51 ��

�


5.52 ��

��


5.53 ��

��


O

5.54 �� Creditor <Cdtr> [0..1] Composed Informations sur le créancier

D Règles de formatage : Dépendant du type de transaction.

Obligatoire pour prélèvement émis

5.55 �� Name <Nm> [0..1] Max140Text Nom du créancier R Règle de formatage : Limité à 70 caractères

5.56 �� Identification <Id> [0..1] Composed Identifiant du créancier : ICS pour un prélèvement SEPA


Obligatoire pour les prélèvements


R Règle de formatage :

Obligatoire pour les prélèvements : ICS créancier

5.58 ��

�

Other <Othr> [0..n] Composed Autre identifiant R Règle de formatage : Limité à 1 occurrence seulement

5.59 ��

��

Identification <Id> [1..1] Max35Text Identififant M ICS du créancier



Stat

ut

FR

Commentaires

5.60 ��

��

SchemeName <SchmeNm> [0..1] Composed Nom du scheme d'identification, sous forme de texte libre

O

5.61 Or} ��

Proprietary <Prtry> [1..1] Max35Text Code propriétaire R Règle de formatage : Valorisé à "SEPA"

5.62 �� CreditorAccount <CdtrAcct> [0..1] Composed Compte du créancier

D Règles de formatage : Dépendant du type de transaction Obligatoire pour prélèvement émis


M

5.64 {Or �� IBAN

<IBAN> [1..1] IBAN2007Identifier


R

5.65 �� UltimateCreditor <UltmtCdtr> [0..1] Composed Informations sur le tiers créancier.

D Règle de formatage : Dépendant du type de transaction ; prélèvement émis seulement

5.66 �� Name <Nm> [0..1] Max140Text Nom du tiers créancier


5.67 �� Identification <Id> [0..1] Composed Identifiant du tiers créancier

O


M

5.69 ��

�





Stat

ut

FR

Commentaires

5.70 ��

�


5.71 ��

��


5.72 ��

��


O

5.73 {{Or ��


5.74 Or}} ��


M

5.75 ��

��


O


M

5.77 ��

�


O

5.78 ��

��


5.79 ��

��


5.80 ��

��


5.81 ��

�

Other [0..n] Composed Autre identifiant O Règle de formatage : Limité à 1 occurrence seulement

5.82 ��

��

Identification [1..1] Max35Text Identifiant M



Stat

ut

FR

Commentaires

5.83 ��

��


O

5.84 �� RelatedAgents <RltdAgts> [0..1] Composed R

5.85 �� DebtorAgent <DbtrAgt> [0..1] Composed Information sur la banque du débiteur

D Règle de formatage : Dépendant du type de transaction, virement émis seulement


M



R BIC de la Banque du débiteur (émetteur du virement)

5.88 �� CreditorAgent <CdtrAgt> [0..1] Composed Identification de la banque du créancier

D Règle de formatage : Dépendant du type de transactions, prélèvement émis seulement

5.89 �� FinancialInstitutionIdentification <FinInstnId> [1..1] Composed Identifiant de la banque du créancier

M



R BIC de la Banque du créancier (émetteur du prélèvement).



Stat

ut

FR

Commentaires

5.91 �� RemittanceInformation <RmtInf> [0..1] Composed Motif du paiement D Selon ce qui aura été reçu dans le flux 3 Règle de formatage : Soit Unstructured soit Structured ; p Pas les deux ensembles

5.92 �� Unstructured <Ustrd> [0..n] Max140Text Motif du paiement sous forme non structurée. Limité à une occurrence

D Règle de formatage : Limité à 1 occurrence

5.93 �� Structured <Strd> [0..n] Composed Motif du paiement sous forme structurée utilisé uniquement en cas de réception de prélèvement au format XML (pour le détail de la structure cf le guide prélèvement)

D Règles de formatage : Limité à 1 occurrence seulement Uniquement pour les opérations SEPA

5.94 �� CreditorReference Information <CdtrRefInf> [0..1] Composed Référence fournie par le créancier

R

5.95 �� Type <Tp> [0..1] Composed Type de référence O

5.96 ��

�

CodeOrProprietary <CdOrPrtry> [1..1] Composed Code ou propriétaire

M

5.97 {Or ��

Code <Cd> [1..1] DocumentType3Code

La valeur "SCOR" est obligatoire (StructuredCommunicationReference)

M Règle de formatage : La valeur "SCOR" est obligatoire (StructuredCommunicationReference)

5.98 �� Reference <Ref> [0..1] Max35Text Référence R


9.8 IG AccountSwitchingNotify

9.8.1 Réponse Positive Index Or Level Message Item XML Tag Mult. DataType Définition Utilisation

FR

Commentaires

1.0 Assignment <Assgnmt> [1..1] Composed Identifie la référence de la réponse

M

1.1 → MessageIdentification <MsgId> [1..1] Max35Text Référence point à point, telle que fournie par l'assigneur et envoyée à la partie suivante dans la chaîne afin d'identifier de façon non ambiguë le message.

M

1.2 → CreationDateTime <CreDtTm> [1..1] ISODateTime Date et heure de création du message

M

1.3 → Creator <Cretr> [0..1] Composed Partie ayant créé la demande de mobilité

O Établissement d'arrivée. Règle de formatage : A utiliser si l'établissement d'arrivée n'est pas le destinataire ("assignee") du message et/ou si "creator" était renseigné dans le flux 4 reçu par l'établissement d’émetteur.

1.4 Or }

→→ Agent <Agt> [1..1] Composed Identification d'une institution financière

M

1.5 →→→ FinancialInstitutionIdentification <FinInstId> [1..1] Composed Set d'éléments utilisés pour identifier de façon unique et non ambiguë une institution ou "branche" d'une institution financière

M BIC de l'établissement d'arrivée

1.6 →→→→ BICFI <BICFI> [0..1] BICFIIdentifier Code d’identification d’une institution financière

R


Index Or Level Message Item XML Tag Mult. DataType Définition Utilisation

FR

Commentaires

1.7 → Assigner <Assgnr> [1..1] Composed Partie qui assigne la demande à une autre partie. Il s'agit aussi de l'émetteur du message.

M

1.8 Or }

→→ Agent <Agt> [1..1] Composed identification d'une institution financière

M Banque émettrice du message

1.9 →→→ FinancialInstitutionIdentification <FinInstId> [1..1] Composed set d'éléments utilisés pour identifier de façon unique et non ambiguë une institution ou "branche" d'une institution financière

M



1.11 → Assignee <Assgne> [1..1] Composed Partie à laquelle la demande est assignée. Il s'agit aussi du receveur du message.

M

1.12 Or }


M Banque réceptrice du message

1.13 →→→ FinancialInstitutionIdentification <FinInstId> [1..1] Composed Set d'éléments utilisés pour identifier de façon unique et non ambiguë une institution ou "branche" d'une institution financière

M



FR

Commentaires



2.0 AccountSwitchingNotificationDetails <AcctSwtchngNtfDtls> [0..1] Composed Fournit la réference du message d'origine

R A n'utiliser qu'en cas d'acceptation de la demande par la banque de l'émetteur

2.1 → AccountSwitchingConfirmation <AcctSwtchngCfrm> [0..1] Composed Set d'éléments permettant de justifier une réponse positive à la demande de mobilité

R Dans ce cas, la banque de l'émetteur restitue la liste des opérations à l'établissement d'arrivée et indique l’état.

2.2 →→ Reason <Rsn> [1..1] Composed Détails. M

2.3 {Or →→→ Code <Cd> [1..1] Code (ExternalReturnReasonCode List)

Code d'état M Seul le code TS01 est accepté pour indiquer que l’Établissement d’Émetteur peut et va joindre l’émetteur.

2.4 →→ AdditionalInformation <AddtlInf> [0..*] Max105Text Information additionnelle sur les conditions d'acceptation

O Détails de la transmission

2.5 → OriginalMessageNameIdentification <OrgnlMsgNmId> [0..1] Max35Text Nom du message d'origine

R Seul "AcctSwtchngInfSvcFwd" est autorisé

2.6 → OriginalMessageIdentification <OrgnlMsgId> [0..1] Max35Text Identifiant du message d'origine.

R Doit comporter l'identifiant du message reçu pour faciliter l'appariement


M Règle de formatage 1 : Par défaut une seule occurrence de "modification" est autorisée. Règle de formatage 2 : Une seconde occurrence est autorisée si elle figure dans le message de "AccountSwitchingInformationServiceResponse" reçu



FR

Commentaires

3.1 → Identification <Id> [1..1] Max35Text identification unique, telle qu'assignée par la partie émettrice, pour identifier de façon non ambiguë l'information d'identification au sein du message.

M

3.2 → AccountSwitchingReference <AcctSwtchngRef> [1..1] Composed Référence de mobilité

M Donne la référence du mandat de mobilité et la date de signature du mandat pour la gestion de la preuve.

3.3 →→ AccountSwitchingIdentification <AcctSwtchngId> [1..1] Max35Text Identifiant de mobilité

M Référence du mandat de mobilité telle que créée par l'établissement d'arrivée.

3.4 →→ DateOfSignature <DtOfSgntr> [1..1] ISODate Date de signature M Date de signature du mandat de mobilité.

3.5 → OriginalPartyAndAccountIdentification <OrgnlPtyAndAcctId> [0..1] Composed fournit les données à jour relatives à l'identification de la partie et/ou du compte

R Informations du client (intitulé du compte, N° de compte) en mobilité dans l'établissement de départ

3.6 →→ Party <Pty> [1..1] Composed identification de la personne ou organisation

M

3.7 →→→ Name <Nm> [0..1] Max140Text Nom utilisé pour identifier une partie


3.8 →→ Account <Acct> [0..1] Composed identification non ambiguë du compte de la partie


3.9 {Or →→→ IBAN <IBAN> [1..1] IBAN2007Identifier International Bank Account number (IBAN) - identifiant utilisé, au niveau international, par les institutions financières pour identifier de façon unique le compte d'un client

M



FR

Commentaires

3.10 →→ Agent <Agt> [0..1] Composed institution financière teneuse de compte pour une partie

R


M



3.13 → UpdatedPartyAndAccountIdentification <UpdtdPtyAndAcctId> [1..1] Composed fournit les données à jour relatives à l'identification de la partie et/ou du compte

M Informations du client (intitulé du compte, N° de compte) dans l'établissement d'arrivée.


M



3.16 →→ Account <Acct> [0..1] Composed identification non ambiguë du compte d'une partie

R compte du client en mobilité dans l'établissement d'arrivée.

3.17 {Or →→→ IBAN <IBAN> [1..1] IBAN2007Identifier International Bank Account number (IBAN) - identifiant utilisé, au niveau international, par les institutions financières pour identifier de façon unique le compte d'un client

M



FR

Commentaires

3.18 →→ Agent [0..1] Composed identification d'une institution financière

R Établissement d'arrivée


M



3.21 → AdditionalInformation <AddtlInf> [0..1] Max140Text information complémentaire, format libre, pour compléter l'information liée à la modification.

O

4.0 → TransactionReport <TxRprt> [0..n] Composed Liste des types d'opérations reprises dans cette réponse.

R Doit être recopié à l’identique du flux 4 (Switching Forward), y compris le ou les blocs 5 inclus.


9.8.2 Réponse Négative Index

Or Level Message Item XML Tag Mult. DataType Définition Utilisation FR

Commentaires

1.0 Assignment <Assgnmt> [1..1] Composed Identifie la référence de la réponse

M

1.1 → MessageIdentification <MsgId> [1..1] Max35Text Référence point à point, telle que fournie par l'assigneur et envoyée à la partie suivante dans la chaîne afin d'identifier de façon non ambiguë le message.

M

1.2 → CreationDateTime <CreDtTm> [1..1] ISODateTime Date et heure de création du message

M

1.3 → Creator <Cretr> [0..1] Composed Partie ayant créé la demande de mobilité

O Établissement d'arrivée. Règle de formatage : A utiliser si l'établissement d'arrivée n'est pas le destinataire ("assignee") du message et/ou si "creator" était renseigné dans le flux 4 reçu par l'établissement d’émetteur.

1.4 Or }

→→ Agent <Agt> [1..1] Composed Identification d'une institution financière

M

1.5 →→→ FinancialInstitutionIdentification

<FinInstId> [1..1] Composed Set d'éléments utilisés pour identifier de façon unique et non ambiguë une institution ou "branche" d'une institution financière

M BIC de l'établissement d'arrivée


R


Index


Commentaires

1.7 → Assigner <Assgnr> [1..1] Composed Partie qui assigne la demande à une autre partie. Il s'agit aussi de l'émetteur du message.

M

1.8 Or }


M Banque émettrice du message


<FinInstId> [1..1] Composed set d'éléments utilisés pour identifier de façon unique et non ambiguë une institution ou "branche" d'une institution financière

M



1.11 → Assignee <Assgne> [1..1] Composed Partie à laquelle la demande est assignée. Il s'agit aussi du receveur du message.

M

1.12 Or }


M Banque réceptrice du message


<FinInstId> [1..1] Composed Set d'éléments utilisés pour identifier de façon unique et non ambiguë une institution ou "branche" d'une institution financière

M


Index


Commentaires



2.0 AccountSwitchingNotificationDetails <AcctSwtchngNtfDtls>

[0..1] Composed Fournit la réference du message d'origine

R A n'utiliser qu'en cas de refus de la demande par la banque de l'émetteur

2.1 → AccountSwitchingRefusal <AcctSwtchngRefsl>

[0..1] Composed Set d'éléments permettant de justifier une réponse négative à la demande de mobilité

R Dans ce cas, la banque de l'émetteur restitue la liste des opérations à l'établissement d'arrivée et motive son refus.

2.2 →→ Reason <Rsn> [1..1] Composed Détails. M

2.3 {Or

→→→ Code <Cd> [1..1] Code (ExternalReturnReasonCode List)

Code d'état M Seuls les codes prévus par SEPAmail sont utilisables : BE01, BE06 ou MS03

2.4 →→ AdditionalInformation <AddtlInf> [0..*] Max105Text Information additionnelle sur le motif de refus

O Détails du motif de rejet de la demande

2.5 → OriginalMessageNameIdentification <OrgnlMsgNmId> [0..1] Max35Text Nom du message d'origine

R Seul "AcctSwtchngInfSvcFwd" est autorisé

2.6 → OriginalMessageIdentification <OrgnlMsgId> [0..1] Max35Text Identifiant du message d'origine.

R Doit comporter l'identifiant du message reçu pour faciliter l'appariement


M Règle de formatage 1 : Par défaut une seule occurrence de "modification" est autorisée. Règle de formatage 2 : Une seconde occurrence est autorisée si elle figure dans le message de "AccountSwitchingInformationServiceResponse" reçu


Index


Commentaires

3.1 → Identification <Id> [1..1] Max35Text identification unique, telle qu'assignée par la partie émettrice, pour identifier de façon non ambiguë l'information d'identification au sein du message.

M

3.2 → AccountSwitchingReference <AcctSwtchngRef>

[1..1] Composed Référence de mobilité

M Donne la référence du mandat de mobilité et la date de signature du mandat pour la gestion de la preuve.

3.3 →→ AccountSwitchingIdentification <AcctSwtchngId> [1..1] Max35Text Identifiant de mobilité

M Référence du mandat de mobilité telle que créée par l'établissement d'arrivée.

3.4 →→ DateOfSignature <DtOfSgntr> [1..1] ISODate Date de signature

M Date de signature du mandat de mobilité.

3.5 → OriginalPartyAndAccountIdentification <OrgnlPtyAndAcctId>

[0..1] Composed fournit les données à jour relatives à l'identification de la partie et/ou du compte

R Informations du client (intitulé du compte, N° de compte) en mobilité dans l'établissement de départ


M



3.8 →→ Account <Acct> [0..1] Composed identification non ambiguë du compte de la partie



Index


Commentaires

3.9 {Or

→→→ IBAN <IBAN> [1..1] IBAN2007Identifier International Bank Account number (IBAN) - identifiant utilisé, au niveau international, par les institutions financières pour identifier de façon unique le compte d'un client

M

3.10 →→ Agent <Agt> [0..1] Composed institution financière teneuse de compte pour une partie

R



M



3.13 → UpdatedPartyAndAccountIdentification <UpdtdPtyAndAcctId>

[1..1] Composed fournit les données à jour relatives à l'identification de la partie et/ou du compte

M Informations du client (intitulé du compte, N° de compte) dans l'établissement d'arrivée.


M


Index


Commentaires



3.16 →→ Account <Acct> [0..1] Composed identification non ambiguë du compte d'une partie

R compte du client en mobilité dans l'établissement d'arrivée.

3.17 {Or

→→→ IBAN <IBAN> [1..1] IBAN2007Identifier International Bank Account number (IBAN) - identifiant utilisé, au niveau international, par les institutions financières pour identifier de façon unique le compte d'un client

M

3.18 →→ Agent [0..1] Composed identification d'une institution financière

R Établissement d'arrivée



M




Index


Commentaires

3.21 → AdditionalInformation <AddtlInf> [0..1] Max140Text information complémentaire, format libre, pour compléter l'information liée à la modification.

O

4.0 → TransactionReport <TxRprt> [0..n]

Composed Liste des types d'opérations reprises dans cette réponse.

R Doit être recopié à l’identique du flux 4 (Switching Forward), y compris le ou les blocs 5 inclus.


10 L'application GEMME (non applicable) Les spécifications de cette application ne sont données qu’à titre indicatif, car elles n’ont pas fait l’objet d’une validation formelle.

10.1 GEMME GEMME 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.

10.2 Les principes gé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

10.3 Les avantages pour le client (GEMME)

10.3.1 Pour le cré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

10.3.2 Pour le dé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


10.4 Cas d'usages (GEMME) Pour les créanciers, les cas d'usages se structurent suivant l'interaction avec le client en fonction des technologies employées :

• Face à face :

1. terminal de contractualisation et de signature électronique

2. signature d'un mandat papier (commerçants sans outils électroniques)

• À distance

1. réception postale de mandat papier (abonnements aux journaux par exemple)

2. enregistrement, par un centre d'appel ou au travers d'un site internet, des données client pour initialisation d'un mandat

Pour la banque du créancier ces différents cas d'usages se résument à trois types de mandats de prélèvement à gérer :

• mandat signé avec capacité de vérification automatique de la signature (a priori le cas idéal)

• mandat déclaré signé, c'est à dire signé manuellement dont la validité n'est effective qu'après une vérification manuelle vis à vis d'une signature déposée

• mandat non signé où tout reste à faire pour qu'il ait un minimum de valeur

10.4.1 Mandat signé électroniquement Pour les mandats signés électroniquement, GEMME présente l'avantage suivant :

• capacité de routage du mandat de prélèvement : cette fonction n'est pas nécessaire pour le prélèvement SEPA CORE mais reste indispensable pour le SDD B2B et pour le prélèvement national. Pour ce dernier la portée de cette nécessité est réduite car la end-date est fixée à début 2014


10.4.2 Mandat déclaré signé Dans cette configuration, GEMME peut permettre :

• la signature immédiate, si le client-débiteur possède une application SEPAmail sur smartphone

• l'envoi sur la banque à distance pour contre-signature ultérieure le soir ou le lendemain

• la prise en compte par la banque du débiteur pour autoriser a priori le prélèvement et éviter un rejet

10.4.3 Mandat non signé GEMME offre la capacité de signature du mandat par mise à disposition auprès des clients débiteurs.

En particulier, GEMME peut offrir une solution à la vente sur Internet de produit payable par prélèvement.

10.4.4 Conclusion : une gestion multi-canaux des mandats L'adaptabilité des messages GEMME ainsi que la capacité multi-canal de SEPAMAIL permettent de prendre en charge tous les cas d'usage de mise en œuvre du prélèvement tant du point de vue créancier que du point de vue débiteur.


10.5 La problématique des flux autour du prélèvement Le prélèvement est un moyen de paiement en forte évolution, celle-ci étant principalement due au SEPA.

Le rulebook SDD 33 du SEPA Direct Debit présente bien la problématique générale du prélèvement. Celle-ci est synthétisée sur le schéma suivant :

On y trouve :

1. les saisies des données créancier/débiteurs par chacune des parties pour initier un mandat de prélèvement.

2. la mise à disposition du mandat de prélèvement pour validation/signature

3. la validation/signature du mandat de prélèvement par le débiteur

4. les notifications d'échéances émises par le créancier

5. le refus d'échéance ou la révocation temporaire ou permanente du mandat de prélèvement

6. la demande de copie de mandat de prélèvement par le débiteur en cas de réclamation

7. le prélèvement effectif par le créancier

8. le retour/rejet par la banque du débiteur

Ces différentes interactions, que l'on retrouve dans tous les systèmes de prélèvements, sont soumises à des règles et à une logique propres à chaque système :

• le prélèvement national français, logique communément appelé Debtor Mandate Flow (DMF) prévoit :

1. un mandat double avec 2 signatures client pour avoir un exemplaire chez le créancier et un exemplaire pour la banque du débiteur

2. que l'exemplaire de la banque du débiteur soit envoyé par le créancier

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.


10.6 La gestion des flux (GEMME) GEMME propose que l'ensemble des interactions, entre le débiteur et le créancier concernant le mandat de prélèvement, se fassent sous forme de messages structurés et dédiés au travers du réseau SEPAmail.

Sur ce concept les interactions initiales peuvent se représenter sur le schéma suivant :

1. le flux commercial entre le client et le créancier se conclut par un accord sur le bien ou le service, le

mode de paiement par prélèvement et l'échange de l'IBAN

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.

10.7 Les normes utilisé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.


10.8 Le récapitulatif des messages (GEMME) Voici les messages possibles pour GEMME :

• message SEPAmail “Demande de Création de Mandat” : envoi par le créancier de mandat de prélèvement ou de modification de mandat

• message SEPAmail “Réponse à Demande de Création de Mandat” : acceptation, modification ou révocation par le débiteur de mandat de prélèvement

• message SEPAmail “Prénotification” : notification des échéances et refus des échéances

• message SEPAmail “Demande de Copie” : demande de copie de mandat par la banque du débiteur


10.9 Les règles métier (GEMME)

10.9.1 Objet du document 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).

10.9.2 Présentation gé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.

10.9.3 Messages de la famille GEMME 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.

10.9.3.1 Le message “Demande de Création de Mandat”

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.

10.9.3.2 Le message “Réponse à Demande de Création de Mandat”

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

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.


10.9.3.3 Le message “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.

10.9.3.4 Le message “Demande de Copie”

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.


10.9.4 Exemples d'interactions entre les acteurs (cas impliquant un créancier ayant adopté la norme SEPAmail dans son intégralité)

10.9.4.1 Envoi et validation d'un mandat de prélèvement

Banque du débiteur Débiteur Créancier

Banque créancier

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.



Banque créancier

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.



Banque créancier

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 ...)

10.9.4.2 Demande d'une copie


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.


Met le message à disposition du créancier par tout moyen à sa convenance (système de banque à distance, connecteur entreprise ...)



Banque créancier

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.


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 ...)

10.10 IG direct.debit L'écosystème direct.debit comporte quatre messages :


direct.debit MandateInitiationRequest [email protected]

MandateAcceptanceReport [email protected]

Prenotification [email protected]

RequestForCopy [email protected]


10.11 IG Gemme MandateInitiationRequest • These implementation rules shall be applied in accordance with ISO20022 and SEPA own


• for an explanation of the color coding used in the tables below, see this page


10.11.1 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.

10.11.2 Message Root Mult Message Element SEPAmail requirement

[1..1] + DirectDebitMandat

10.11.3 ISO and Non-ISO parts 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.



A [1..1] ++ Mandat MandateInitiationRequestV01, as per ISO pain.009

B [0..1] ++ DSExt Non-ISO part, described further in this document

10.11.3.1 ISO Part : 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.

10.11.3.1.1 Group Header

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

10.11.3.1.2 Mandate


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.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

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.20 [0..1] ++ Creditor Account IBAN

2.21 [0..1] ++ Creditor Agent BIC

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] +++ 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.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.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 Rule : "Name" is limited to 70 characters in length.


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.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


10.11.3.2 Non-ISO Part : 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.


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



SEPAmail requirements

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.

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.

10.12 IG Gemme MandateAcceptanceReport • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




10.12.1 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.


10.12.2 Message Root Mult Message Element SEPAmail requirement

[1..1] + DirectDebitMandateAcceptance

10.12.3 ISO and Non-ISO parts Ref Mult Message


A [1..1] ++ Report MandateAcceptanceReportV01, as per ISO pain.012

B [0..1] ++ DSExt Non-ISO part, described further in this document


10.12.3.1 ISO Part : 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.

10.12.3.1.1 Group Header

The group header contains information required for the processing of the entire message.


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

10.12.3.1.2 Underlying Acceptance Details


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.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, "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

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.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] +++++ Identification (AT-39 Identification code of the Creditor Reference Party)


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.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

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.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] +++++ Identification (AT-37 Identification code of the Debtor Reference Party)






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

10.12.3.2 Non-ISO Part : 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.



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


10.13 IG Gemme Prenotification • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




10.13.1 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.

10.13.2 Message root Mult Message Element SEPAmail requirement

[1..1] DirectDebitPrenotif




[1..1] sepamail_message_direct_debit_prenotif_001 First version of the structure

10.13.4 Message Body Ref Mult Message


A [1..1] ++ GrpHdr

B [1..1] ++ Notif

10.13.4.1 Group Header

The group header contains information related to the message itself.




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

10.13.4.2 Prenotification

This part of the message actually describes the payments that will take place, as well as the related mandate.



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.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

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


10.14 IG Gemme RequestForCopy • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




10.14.1 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.


10.14.2 Message root Mult Message Element SEPAmail requirement

[1..1] DirectDebitRFCopy


The actual contents of the DirectDebitRFCopy element must be any one of the following structures.


[1..1] sepamail_message_direct_debit_request_for_copy_001 First version of the structure

10.14.3.1 Group Header

The group header contains information related to the message itself.



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

10.14.3.2 Request

This part of the message actually describes the transaction upon which the request is based -- or at least the actors of this transaction.



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.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.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




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.


11 L'écosystème TEST 11.1 IG test L'é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 :


test SimpleTestReport simple.report@test

SimpleTestRequest simple.request@test

11.2 IG Test SimpleTestRequest • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




11.2.1 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.

11.2.2 Message Body 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


11.3 IG Test SimpleTestReport • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




11.3.1 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.

11.3.2 Message Body 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


12 L'écosystème SECURE (Non applicable) Les spécifications de cette application ne sont données qu’à titre indicatif, car elles n’ont pas fait l’objet d’une validation formelle.

12.1 IG secure L'écosystème secure comporte trois messages :


secure EnrollAdvise enroll.advise@secure

EnrollReport enroll.report@secure

EnrollRequest enroll.request@secure

12.2 IG Secure EnrollAdvise • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




12.2.1 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.


12.2.2 Root element 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

12.2.3 EnrollAdvise body 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


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 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.2 [0..1] ++++ KeyValue



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


12.3 IG Secure EnrollRequest • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




12.3.1 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.




[1..1] sepamail_message_secure_enroll_request_001 First version of this message

12.3.3 EnrollRequest body This part of the message actually describes the identification of the party wishing to enroll, and the associated certificates.



A2 [0..1] ++ SndrRef Sender Reference. Internal reference the sender associates with this request

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


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 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.2 [0..1] ++++ KeyValue



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.2 [0..1] ++++ KeyValue



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.


12.4 IG Secure EnrollReport • These implementation rules shall be applied in accordance with ISO20022 and SEPA own




12.4.1 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).





[1..1] sepamail_message_secure_enroll_report_001 First version of this message

12.4.3 EnrollReport body This part of the message indicates the result of the enrollment, and if positive, carries additional information for the new member.



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


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.2 [0..1] ++++ KeyValue





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.2 [0..1] ++++ KeyValue



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