Standards:SMIRK APP1501 v2, l'application AIGUE-MARINE
Elle ne fait pas partie de la norme SEPAmail, ni de la documentation officielle. Elle n'est laissée dans le Wiki qu'à titre d'historique.
Merci de ne pas la modifier, ni utiliser l'onglet discussion.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 opérateur pour être le tiers de confiance de sa mobilité.
Le changement de domiciliation bancaire consiste pour un 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 de la présente application, 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, nous décrivons les principes puis l’application elle-même.
La description précise des messages et les directives d’implémentation associées font l’objet de documents séparés.
L’application ne s’adresse qu’aux opérations de paiement de type prélèvement SEPA (SDD), virement SEPA (SCT) et chèques.
Glossaire et Acteurs
Client Migrant (CM) : 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. Ce peut également être un ensemble de particuliers, pour un compte joint ou un compte indivis.
Donneur d'Ordre (DO) : entité économique (entreprise ou particulier) qui donne des ordres de prélèvement ou de virement sur le compte bancaire du Client Migrant dans sa Banque d'Origine. Il est appelé Émetteur dans les schémas de la FBF, mais nous conserverons ici le terme de Donneur d'Ordre, qui prête moins à confusion dans la cadre de la messagerie SEPAmail.
Banque d'Accueil (BA): l'établissement bancaire ou PSP dans lequel le Client Migrant ouvre un compte, vers lequel il souhaite transférer ses opérations bancaires. C'est la Banque d'Accueil qui propose et coordonne le service de mobilité bancaire.
Banque d'Origine (BO): l'établissement bancaire ou PSP dans lequel le Client Migrant détient un compte, et qu'il ne souhaite plus utiliser pour ses opérations de virements récurrents et prélèvements.
Banque du Donneur d'Ordre (BDO): l'établissement bancaire ou PSP par le biais duquel un DO réalise des prélèvements ou virement sur le compte bancaire du Client Migrant dans sa Banque d'Origine.
Il faut noter que chaque banque est en fait appelée à jouer les trois rôles de Banque d'Accueil, de Banque d'Origine et de Banque de DO -- dans des proportions différentes selon les établissements.
Opérateur de Mobilité : Actuellement, il agit en tant que sous-traitant de la Banque d'Accueil pour coordonner et traiter le service de mobilité. Son rôle est amené à évoluer dans le cadre de cette application, de sorte qu'il ne sera pas davantage mentionné en tant que tel dans le présent document. Il peut avoir vocation à intervenir en tant que sous-traitant ou prestataire à divers endroits, mais la définition de la forme et de la nature de ces prestations est clairement en-dehors du périmètre de cette norme.
Besoins des Acteurs
Les besoins du Client Migrant sont :
- identifier ses créanciers (SDD) et ses débiteurs (SCT)
- demander que les paiements associés à ces créanciers et émetteurs soient transférés automatiquement sur son nouveau compte.
- pouvoir suivre l'avancement de sa mobilité
Les besoins du DO sont :
- identifier de façon unique et non ambigüe ses débiteurs ou bénéficiaires.
- 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 process existants, compte tenu d'une part du nombre assez faible de flux prévisible, d'autre part de la nécessité légale de fournir ce service gratuitement au Client Migrant.
Principes
Le périmètre complet de la mobilité 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 Migrants restent en contact avec leur Banque d'Accueil et avec leur Banque d'Origine si nécessaire, par les canaux habituels (banque à distance, mail, téléphone...). Les flux entre les Clients Migrants et les banques sont donc exclus du périmètre actuel.
En excluant ce qui ne relève pas du périmètre, nous obtenons donc ce schéma simplifié :
Il reste donc fondamentalement deux dialogues à standardiser entre les acteurs :
- la récupération des opérations de paiement récurrentes (flux 2 et 3, dialogue Banque d'Accueil - Banque d'Origine)
- l’ordre de modification d’une opération de paiement (flux 4, 4bis et 5 plus retour, dialogue Banque d'Accueil - Banques de DO voire DO eux-mêmes)
Les opérations récurrentes de paiement
Le Client Migrant doit pouvoir récupérer automatiquement toutes les 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 émis
- SCT reçus
- SDD reçus
- SDD émis (en cours de validation, mais doivent être prévus)
- Les chèques non encaissés
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 Migrant mandate sa Banque d'Accueil pour réaliser le service de mobilité. Il signe donc un mandat de mobilité avec elle. C'est ce mandat qui permet aux autres acteurs de s'assurer de l'authenticité de la demande, et les messages envoyés par la Banque d'Accueil doivent donc comporter suffisamment d'éléments à cet effet.
Rappelons que les échanges entre la Banque d'Accueil et le Client Migrant sont hors du périmètre de SEPAmail.
Le document de référence ne prévoit que le transport de la référence et de la date de ce mandat, mais nous préconisons, dans la mesure du possible, de transporter systématiquement l'intégralité du mandat pour améliorer la lutte anti-fraude. Si ce mandat est signé sous forme électronique, ce qui à terme pourrait se généraliser, cela ne représentera qu'une contrainte négligeable.
Il est du ressort de la Banque d'Origine de s'assurer du droit que le Client Migrant a à demander une mobilité bancaire, notamment :
- le compte n'est pas déjà clôturé
- le Client Migrant est bien le titulaire du compte sur lequel la demande porte
Le message de réponse à demande d'informations devra donc contenir un certain nombre d'éléments permettant d'indiquer l'impossibilité de la mobilité.
Marc Delesalle : le SDD émis est hors du scope : le débiteur n'a pas à être informé du changement de compte bancaire du créancier, cette information ne faisant pas partie du mandat de prélèvement qu'il a signé.
L’ordre de modification d’une opération de paiement
Le Client Migrant désire modifier automatiquement sa domiciliation bancaire chez chacun des organismes donneur d’un ordre récurrent sur son compte bancaire.
Le migrant souhaite savoir si cet ordre de modification 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 confirmation de modification
Nous pouvons décrire ce dialogue par le diagramme de séquence suivant :
La confirmation de modification ne figure pas parmi les obligations légales des DO 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 elle fera donc partie intégrante de l'application AIGUE-MARINE.
En outre, elle permet à la Banque du DO de proposer à celui-ci un service complémentaire : le DO étant tenu d'informer son client, elle peut se substituer à lui pour l'exécution de cette obligation si elle reçoit un rapport de modification.
Dans certains cas, la Banque d'Accueil peut être amenée à communiquer directement avec le DO :
- si la Banque du DO est située hors de France
- si la Banque du DO n'est pas encore raccordée à un système automatique de mobilité bancaire.
Dans ce cas, le diagramme d'échange est le suivant :
Avec toujours la confirmation de modification facultatif au sens légal du terme.
Dans tous les cas, le canal de communication entre la Banque de DO et le DO – ou entre le Banque d'Accueil et le DO – est laissé à l'iniative des deux parties. Cela peut être de l'extension de norme ("SEPAmail hors SEPAmail"), un canal EBICS... Ce qui compte est que le message transmis ait toujours le même contenu et la même structure, quels que soient les banques et les DO concernés.
Remarques
Dans le cas d’un ordre de virement, le Donneur d’Ordre 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. 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.
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 de Banque d'Accueil, Banque d'Origine et Banque de DO.
Au moins un écosystème SEPAmail dédié est créé et il s’appelle « mobility ».
D'autres pourraient venir en complément ou en substitution, ce point est toujours en discussion.
Il n’y a pas besoin d’annuaire, ni pour les Clients Migrants, ni pour les Donneurs d’Ordre.
Les statistiques remontées au scheme (ad-hoc de ce nouvel écosystème) pour la surveillance du réseau sont celles par défaut.
Le respect des principes de la messagerie SEPAmail
SEPAmail repose sur des principes que toute application de SEPAmail doit respecter. Nous listons ci-dessous ces principes et le respect de l’application.
| Dialogue au minimum 4 coins | Oui | Le modèle 4 coins est respecté dans les 2 échanges, même si dans certains cas le nombre d'acteurs se réduit à deux. |
| Dialogue structuré avec une portée globale | Oui | La portée des dialogues proposés concernent les utilisateurs mobiles, les tiers de confiance, les organismes concernés par la mobilité, quel que soit le pays. Ils ont donc une portée globale. |
| L’accusé de réception automatique pour le compte du destinataire de chacun des messages est utilisé | Oui | |
| L’authentification des personnes physiques liés à un identifiant (QXBAN) est garantie sans compromission des autres identifiants | Oui | Les identifiants éventuellement transportés par les messages le sont sous mandat de l’utilisateur émetteur de l’information. |
| Application permettant à un adhérent de proposer des services autour du flux dans l’espace compétitif | Oui | Quel que soit l’adhérent concerné, il est possible pour lui de proposer des services à valeur ajoutée à son client.
La Banque d'Origine peut ainsi sécuriser un service obligatoire et réglementaire dans de nombreux pays. La Banque du DO peut proposer des services à fortes valeurs ajoutées sur les flux d’ordre de paiement et les rejets. |
| Garantie du respect des règles | Oui | En-dehors des adhérents SEPAmail qui se sont engagés à les respecter, les DO, qui interviennent en quelque sorte en extension de la norme, devront également s'engager sur ces règles. |
| Les messages sont auto-porteurs de l’information | ??? | Ceci n'est pas dans le périmètre de la SMIRK, mais devra être vérifié lorsqu'ils seront disponibles. |
| Le canal d’échange de l’information et la méthode d’authentification ne sont pas présumés | Oui | |
| L’extension de l’application « pair à pair » est possible | Oui | Les messages peuvent être tous utilisés dans un contexte « pair à pair » |
| L’application doit pouvoir fonctionner nativement dans le mode canonique | Oui |
Contenu des messages
Cas général
SEPAmail n'est utilisé -- ce qui est normal -- que comme une messagerie. Le contenu des messages sera défini par la FBF, et leur structure 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 (de Banque du DO à Banque d'Accueil notamment) est hors périmètre légal, et ne sera pas normalisé par le CFONB.
Il sera donc défini par SEPAmail lorsque les autres messages seront disponibles, sur la base évidemment du message de demande de modification.
Les éléments qu'il devra contenir en complément sont:
- un état de la demande : acceptée ou refusée
- une raison en cas de refus
- une date de prise en compte en cas d'acceptation
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]
La Banque d'Accueil doit pouvoir, dans certains cas, prouver à la Banque d'Origine et à l’organisme donneur d’ordre qu’il a bien le mandat de leur client commun.
Cette preuve de mandat peut être transportée (ou non) par les flux mis en œuvre. Elle doit donc être électronique, interprétable par un agent automate ou humain.
En l’absence de norme d’ordre général portant sur le mandat, nous avons retenu, au sein de ce document, la possibilité de transporter un fichier au format pdf contenant à la fois le descriptif de l’acte mandaté, la signature du mandant et l’authentification du producteur du document initial.
Nous avons utilisé le document SEPAmail de type mandat au format pdf.
Les risques de fraude au sujet de ce mandat sont :
- l’usurpation d’identité du mandant. Ce risque est garanti par la Banque d'Accueil dans le cadre de la messagerie SEPAmail, puisqu'elle est adhérente du réseau SEPAmail.
- une faille de sécurité opérationnelle du système d’information de la Banque d'Accueil
- une mauvaise gestion de la nature même du mandat. Ce risque est couvert par la faible quantité et la lisibilité des mandats proposés. À terme, le mandat devrait faire l’objet d’une normalisation européenne (type cerfa).
Mandat SEPA
La modification des coordonnées bancaires du Client Migrant constitue un amendement du mandat de prélèvement SEPA. Il revient au DO de gérer cet amendement comme le règlement SEPA le prévoit.
Extensions possibles
Nous décrivons ici des possibilités d'extension future, non prises en compte dans l'état actuel de la SMIRK pour respecter les contraintes légales.
Prise en compte du QXBAN
On devrait intégrer la possibilité de demander des informations sur la base d'un QXBAN et non seulement d'un IBAN. En effet, les virements émis par le biais de RUBIS arrivent sur le QXBAN du débiteur et non son IBAN, de sorte qu'il serait possible de les migrer directement via une portabilité du QXBAN -- qui n'existe pas actuellement.
De plus, le système actuel implique de fournir le nouvel IBAN du débiteur au DO, alors qu'il ne le connaît pas s'il ne dispose que de son QXBAN.
Services additionnels
La Banque d'Accueil, en tant que responsable de ses relations avec son nouveau client, doit lui donner une vision sur sa mobilité bancaire en cours. C'est évidemment à elle qu'il appartient de définir cette visibilité (canal et contenu).
À terme, elle pourrait proposer au Client Migrant :
- de sélectionner les opérations qu'il souhaite migrer
- de migrer les opérations à partir de plusieurs comptes bancaires
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 |