Standards:SMIRK APP1501 old, l'application AIGUE-MARINE

Cette page est à l'état de discussion.

Elle n'a donc aucune valeur normative, et pourrait même disparaître du périmètre de SEPAmail.

Si vous voulez contribuer, utilisez la page de discussion SVP. Consultez également les autres pages en discussion.

Version d'origine Auteur : Isilis, avec la collaboration de Manfred Olm

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

Ce changement « dit » de domiciliation bancaire est dû la plupart du temps à un changement d’établissement bancaire désiré par le titulaire, mais cela peut-être aussi une renumérotation des comptes réalisée par la banque suite à une fusion d’établissement, de guichet, un changement d’agence, un changement de situation ou d’état civil pour le titulaire du compte.

De nombreux établissements bancaires proposent un service de facilitation de ce changement de domiciliation autour d’une organisation semi-manuelle et des formats d’échange propriétaires.

[Azzana Consulting] Le cas de la modification de coordonnés bancaires du fait de la banque est déjà traité par ailleurs. Il y a des acmt.022 à destination des Corporates et les clients finaux n’ont pas d’action particulière à mener. La fonctionnalité de mobilité bancaire doit donc se limiter à un changement de compte du fait du titulaire dans la même banque ou dans une autre banque.

[Marc Delesalle / Docapost] L'automatisation des échanges (collecte des organismes de la banque d'origine + information du changement de domiciliation vers la banque de l'organisme) va devenir obligatoire dans le cadre de l'amendement Macron relatif à la Mobilité bancaire.

[Jacques Baillon / Ca ]

• Ajout

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 ses ordres permanents vers son nouveau compte

• suppression paragraphe pour les raisons suivantes :

Renumérotation des comptes : cet événement n’étant pas à l’initiative du client ne devrait pas rentrer dans le périmètre de l’étude. Cet événement n’est pas à prendre en compte dans le cadre de la mobilité bancaire. Il est déjà géré via l’échange de CAI (Change Account Identification) en interbancaire entre la banque du client qui renumérote ses comptes et les émetteurs de virements/ prélèvement à destination des comptes renumérotés.

Etat civil : Idem événement non pris en compte dans le cadre de la mobilité bancaire. De plus incohérent avec la remarque en bas de la page qui indique que les cas de mobilité civile ne sont pas traités.

"Ce changement « dit » de domiciliation bancaire est dû la plupart du temps à un changement d’établissement bancaire désiré par le titulaire, mais cela peut-être aussi une renumérotation des comptes réalisée par la banque suite à une fusion d’établissement, de guichet, un changement d’agence, un changement de situation ou d’état civil pour le titulaire du compte.

De nombreux établissements bancaires proposent un service de facilitation de ce changement de domiciliation autour d’une organisation semi-manuelle et des formats d’échange propriétaires. "

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.

L’application ne s’adresse qu’aux opérations de paiement de type prélèvement SEPA (SDD) et virement SEPA (SCT).

La description précise des messages et les directives d’implémentation font l’objet de documents séparés.

Remarque : les cas d’usage de mobilité civile et postale ne sont pas traités dans ce document.

[ Azzana Consulting ] La partie chèque est exclue du présent wiki. Néanmoins la banque quittée à l’obligation d’informer son ancien client qu’un chèque s’est présenté sur son compte clos. La messagerie SEPAmail pourrait être un bon vecteur de communication car un changement de banque peut également impliquer des changements de coordonnées téléphonique ou postale et rendre cette obligation complexe à réaliser. De plus il n’est mentionné dans le wiki et dans le texte de la loi Macron que les opérations récurrentes. Aujourd’hui le « one off » n’est que peu utilisé, mais demain avec la disparition du TIP, les volumes peuvent augmenter, aussi ne faudrait-il pas l’inclure dans le contexte ?

[Jacques Baillon / CA] voir discussion sur ce thème dans la partie cadrage (pas de one off).

Les acteurs

Le migrant

Le migrant est une entité économique (particulier individuel, ménage, entreprise, institution, association) cherchant à migrer tout ou partie des opérations récurrentes d’un compte bancaire à un autre compte bancaire.

[ Azzana Consulting ] Les besoins du migrant sont 1- identifier ses créanciers (pour les SDD) et ses émetteurs (pour les SCT). 2- identifier le moyen de paiement que le migrant utilise avec sa contre partie 3- valider tout ou partie de sa mobilité 4- suivre l’avancé de la prise en compte de ses demandes.

[ Jacques Baillon /CA]

• proposition de revoir le paragraphe pour le Client, et abandonner le terme de "migrant"

Le Client

Le client est un particulier qui souhaite bénéficier du service de mobilité bancaire, proposé par la banque d’accueil. Ce service permet un changement automatisé des domiciliations bancaires, vers le nouveau compte, des prélèvements valides et virements récurrents du compte d’origine.

L’organisme donneur d’ordre

L’organisme donneur d’ordre (ODO sur les schémas) est une entité économique qui donne des ordres de prélèvement ou de virement sur l’un des comptes bancaires du migrant. [ Azzana Consulting ] Les besoins du donneur d’ordre sont : 1- identifier de façon unique et non ambigüe ses débiteurs ou ses bénéficiaires. 2- mettre à jour ses bases de coordonnés bancaires afin de limiter le risque de rejets au moment de l’émission de ses opérations. 3- Ne pas alourdir ses process de gestion (réception d’un flux déjà existant l’ACMT.022)

[Jacques Baillon / CA]

• Paragraphe à revoir, proposition

L’Emetteur ("organisme donneur d’ordre")

L’Emetteur, organisme donneur d’ordre (ODO sur les schémas), est une entité économique ou un particulier qui donne des ordres de prélèvement ou de virement sur le compte bancaire du Client dans la banque d’origine.

L’opérateur de mobilité

L’opérateur de mobilité est mandaté par le migrant pour exécuter toutes les demandes de modification envers les tiers concernant la mobilité désirée.

Cet opérateur de mobilité est donc un tiers de confiance entre le migrant et les autres entités concernées par la migration.

[Marc Delesalle] Le client mandate sa banque (et non l'opérateur) pour exécuter les demandes de modification. La banque confie cette prestation à un opérateur de mobilité (comme Docapost ou Isilis)

[Jacques Baillon /ca] En phase avec Marc, sauf sur le terme "confie". Aucune obligation, de fait, n‘existera dans le futur système : L’OPERATEUR PEUT ETRE EVENTUELLEMENT SOUS-TRAITANT de la Banque d’Accueil MAIS N’EST PAS MANDATE PAR LE CLIENT. -> Est-il utile d’envisager l’opérateur de mobilité dans le scheme ? -> Est il utile de considérer que l’opérateur de mobilité peut également être la banque d’arrivée en direct. Aucune obligation de sous-traiter n’existe. Si on conserve ce 4 ème acteur, il faut justifier les raisons dans la suite des dialogues de l'écosystème.

Les banques ou établissements de tenue des comptes bancaires

Plusieurs banques sont acteurs de la mobilité du migrant :

• les banques du migrant
  • la banque quittée pour les opérations migrées
  • la banque d’accueil des opérations migrées
• la banque de l’organisme donneur d’ordre (Banque ODO)

[Marc Delesalle / Docapost] Je pense qu'il serait judicieux d'utiliser la même sémantique que la FBF (Client, banque d'origine, banque d'accueil, banque de l'émetteur, émetteur...)

[Jacques Baillon / CA] En phase avec Marc et changer aussi le titre : le terme est "banque teneur de compte".

Principes

Compte-tenu du besoin, nous décrivons dans ce document deux dialogues à standardiser entre les acteurs :

• la récupération des opérations de paiement récurrentes auprès de la banque quittée
• l’ordre de modification d’une opération de paiement

[Jacques Baillon / ca]

• Révision complète et intégrale avec les éléments de "cadrage" une fois validés

Les principes et toute la suite de la SMIRK, y compris les schémas d'ailleurs peu lisibles, sont à revisiter complètement sur la base du "Cadrage" et de chacun des flux décrits et du vocabulaire de la FBF.

• Diamond

Un service en option, aurait, à terme, beaucoup de valeur pour fluidiser et fiabiliser la procédure: 1) La banque d’accueil aussi avant d'initialiser le mandat 2) La banque du DO peut demander la vérification des nouvelles coordonnées bancaires, via Diamond

Les opérations récurrentes de paiement

Le migrant désire récupérer automatiquement les opérations de paiement récurrent sur un de ses comptes bancaires pour une période déterminée.

Ce qui intéresse le migrant, ce sont les types d’opération (prélèvement, virement, autres), les contreparties, et, dans une moindre mesure, les montants et les dates des opérations.

Nous pouvons décrire ce dialogue par le diagramme ci-dessous.

Le migrant mandatant l’opérateur de mobilité est censé être le client de la banque quittée. Pour s’assurer des droits de ce migrant sur la requête, nous distinguons le client de la banque quittée et titulaire du compte bancaire interrogé et le migrant.

[Marc Delesalle / Docapost] L'amendement Macron vise à automatiser le process : le "migrant" signe un mandat avec sa banque, qui déroule ensuite (potentiellement via son "opérateur de mobilité") le process de migration, sans intervention obligatoire du client. Dans ce cadre, le flux en provenance de la banque d'origine doit contenir l'ensemble des informations permettant d'informer l'organisme : les informations citées doivent être complétées par l'identifiant du client auprès de cet organisme (RUM mandat pour un prélèvement, ref contrat...) et potentiellement par d'autres éléments techniques tel que le endtoendid de la dernière opération. L'enjeu est de permettre à l'organisme d'identifier de manière unique le client concerné. Le contenu des informations collectées de la banque d'origine sera défini par le CFONB.

L’ordre de modification d’une opération de paiement

Le migrant désire modifier automatiquement chez chacun des organismes donneur d’un ordre récurrent sur son compte bancaire une information comme : son nom d’usage, sa domiciliation bancaire, sa domiciliation postale.

Le migrant souhaite savoir si cet ordre de modification est pris en compte et quelle est la date d’effet de cette modification.

Nous pouvons décrire ce dialogue par le diagramme de séquence suivant :

Dans le cas d’un ordre de virement, l’organisme donneur d’ordre peut se satisfaire de l’authentification du migrant proposée par l’opérateur de mobilité 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. [ Azzana Consulting ] Ce 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ître du canal qu’ils souhaitent utiliser pour communiquer avec leur client. Le service via SEPAmail doit donc demeurer optionnel.

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.

Principe	Respecté ?	Commentaire
Dialogue au minimum 4 coins	Oui
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 quittée peut ainsi sécuriser un service obligatoire et réglementaire dans de nombreux pays. La banque de l’organisme donneur d’ordre 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	L’opérateur de mobilité étant un adhérent dans une vision 4 coins des dialogues, il s’engage sur sa partie et sur le respect des règles au même titre que tous les adhérents SEPAmail.
Les messages sont auto-porteurs de l’information	Oui
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 »
Le dialogue ne peut pas devenir un modèle 2 ou 3 coins	Oui	Il y a bien 4 fonctions différentes dans les dialogues proposés qui garantissent un modèle 4 coins même si le nombre d’acteurs se réduit à deux.
L’application doit pouvoir fonctionner nativement dans le mode canonique	Oui

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

L’opérateur de mobilité doit pouvoir, dans certains cas, prouver à la banque quittée 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 type 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 l’opérateur de mobilité dans le cadre de la messagerie SEPAmail, puisque l’opérateur de mobilité est adhérent du réseau SEPAmail.
• une faille de sécurité opérationnelle du système d’information de l’opérateur de mobilité.
• 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).

Utilisation de l’ISO pour les opérations de paiement récurrentes

Nous utilisons un CAMT.060 en demandant, si possible, un flux de réponse personnalisé qui n’existe pas dans l’ISO. Nous l’avons construit pour être compatible avec les autres flux de l’ISO.

En mode dégradé pour les banques quittées qui n'ont pas implémenté ce flux personnalisé, il est possible de demander un flux camt (053 ou 054).

[Marc Delesalle / Docapost] Le contenu des messages sera défini par le CFONB. A ce stade, aucun standard n'existe sur le marché. [ Azzana Consulting ] Il est nécessaire d’attendre les recommandations du CFONB pour l’inter-bancarité, néanmoins nous pouvons déjà dire que : Pour la transmission de l’information au donneur d’ordre : 1- Les grands comptes et le middle market plébiscitent l’acmt.022 pour la réception de l’information via les canaux qu’ils utilisent. Ce format est déjà connu par leurs systèmes. 2- les petites entreprises peuvent accepter une information dans leur espace bancaire. Pour l’accusé de réception de la prise en charge de la modification : 1- Les grands comptes et le middle middle market plébiscitent le maintien de leurs chaines existantes. 2- les petites entreprises peuvent utiliser leur espace bancaire pour adresser un accusé réception à leur client, sous forme de pièce jointe via une missive SEPAmail par exemple.

Utilisation de l’ISO pour l’ordre de modification d’une opération de paiement

Le ACMT.022 (CAI en remplacement du DCD) est utilisé comme base de l’ordre de modification entre l’opérateur de mobilité et la banque de l’organisme donneur d’ordre, en substitution de la banque d’accueil ou quittée. Nous rajoutons la possibilité de justificatifs dont un mandat.

Le flux retour n’existe pas dans l’iso ; il est proposé dans une version non iso. Nous rajoutons la possibilité de justificatifs.

Application, ecosystème et besoins transverses

L’écosystème SEPAmail est dédié et il s’appelle « mobility ».

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

Il n’y a pas besoin d’annuaire de migrants et d’annuaire des organismes 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.

---

[Marc Delesalle / Docapost] Le contenu des messages sera défini par le CFONB. Seul certains créanciers sont en mesure aujourd'hui de traiter un ACMT.022 partiel (sans les informations endtoendid par exemple)