Standards:SMIRK APP1501, l'application AIGUE-MARINE
Introduction
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.
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.
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.
Elles sont disponibles à partir de cette page.
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 virement 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 pour réaliser sa mobilité. 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 s'il demande la clôture de son ancien 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 comporter la date de transfert du solde du compte, si 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.
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 non SEPA) et ses bénéficiaires de virements permanents émis (SCT et non SEPA)
- demander que les paiements associés à ces créanciers et émetteurs soient transférés sur son nouveau compte.
- identifier les formules de chèques non débitées sur son 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.
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)
Les opérations 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
- SCT reçus récurrents
- SDD reçus récurrents (les one-off ne sont pas pris en compte)
- Les virements permanents émis (SEPA ou non SEPA)
- Les virements non SEPA récurrents reçus
- 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é.
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 de ne pas les faire figurer dans les listes d'informations envoyées à l'Établissement d'Arrivée.
Il faut noter que ce cas ne se présente a priori aujourd'hui que dans le contexte P2P (particulier à particulier).
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 une nouvelle Référence 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.
Le changement de domiciliation bancaire
Le Client désire modifier automatiquement sa domiciliation bancaire chez chacun des donneurs d’un ordre récurrent sur son compte bancaire.
Le Client souhaite savoir si ce changement de domiciliation est pris en compte et quelle est la date d’effet de cette modification.
Deux messages sont nécessaires dans ce dialogue :
- le message de demande de modification
- le message de rapport de modification
Nous pouvons décrire ce dialogue par le diagramme de séquence suivant :
Le rapport de modification ne figure pas parmi les obligations légales des Émetteurs ni des banques, d'où son figuré en pointillés. Toutefois, les principes de SEPAmail imposent un message de réponse pour tout message de demande, et il fera donc partie intégrante de l'application AIGUE-MARINE.
Il sera décrit en détail dans la page correspondante, ainsi que ses cas d'usage et son contenu.
Il est exclu qu'une quelconque information concernant les relations entre l'Émetteur et son client puisse être transmise à l'ÉÉ, et a fortiori à l'ÉA. Le contenu du message se limitera à des informations basiques, qui seront précisées dans les IG relatives à ce message.
L'existence d'un message de retour peut permettre à l'Établissement de l'Émetteur de proposer des services complémentaires, qui relèvent strictement de possibles extensions futures.
Dans certains cas, l'Établissement d'Arrivée peut être amené à communiquer directement avec l'Émetteur. Dans tous les cas, nous sommes clairement hors du périmètre de la norme SEPAmail au sens strict.
Dans ce cas, le diagramme d'échange est le suivant :
Avec toujours le rapport de modification facultative au sens légal du terme.
Dans tous les cas, le canal de communication entre l'Établissement d'Émetteur et l'Émetteur – ou entre l'Établissement d'Arrivée et l'Émetteur – est laissé à l'initiative des deux parties, et peut ne pas être électronique. Cela peut être de l'extension de norme ("SEPAmail hors SEPAmail"), un canal EBICS... Ce qui compte est que les messages transmis, à l'aller comme au retour, aient toujours le même contenu et la même structure, quels que soient les établissements et les Émetteurs concernés.
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.
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.
Contenu des messages
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.
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 évidemment du message de demande de modification. Les IG correspondantes sont disponibles ici.
Informations complémentaires
Autour du mandat
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. »[1]
L'Établissement d'Arrivée doit pouvoir, dans certains cas, prouver à l'Établissement de Départ et à l'Émetteur qu’elle 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
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.
Auteurs et contributeurs
| Auteurs | Contributeurs |
|---|---|
| Isilis | Jacques Baillon pour Crédit Agricole |
| Olivier Jousselin pour SEPAmail.eu | Frédéric Borry pour Lyra Networks |
| Pierre Bouleau pour STET | |
| Lionel Chemla pour GFI | |
| Matthieu Dambrin pour Skillea | |
| Georges Deguimp pour Azzana Consulting | |
| Marc Delesalle pour Docapost | |
| Noël Dumand pour Société Générale | |
| Catherine Gondelmann | |
| Bernard Gouraud | |
| Karim Jouhari pour Wordline | |
| Hugues Leclere pour Sopra Banking | |
| Manfred Olm pour DeciBI | |
| Patrick Peltier pour SIB | |
| Cyril Vignet pour BPCE |