Standards talk:SMIRK APP1501 v2, l'application AIGUE-MARINE

Saisissez toutes les discussions sur Aigue-Marine ci-dessous SVP !

Business modèle

Je sais que nous sommes encore sur la définition du périmètre et des cinématiques, mais néanmoins le sujet de la facturation du service doit se poser clairement dès le début pour lever les incertitudes et permettre aux acteurs industriels de se positionner. Par ailleurs, cette question peut avoir des impacts sur les cinématiques s'il n'y a pas de consensus. Est-ce que la répartition des frais du service Aigue-Marine est clair entre les différentes banques (accueil, origine et celles des émetteurs) ?

--Karim Jouhari (Worldline) (discussion) 10 juin 2015 à 11:26 (CEST)

La discussion ici doit être purement technique et normative. Le business model est l'affaire de chaque acteur, et il est hors de question que nous en parlions ici.

SUJET CLOS

-- Olivier.jousselin (discussion) 10 juin 2015 à 17:21 (CEST)

proposition de corrections de texte

identifier ses créanciers (SDD) et ses débiteurs (SCT)

changer dans le schéma "émetteurs" par "donneur d'ordre" (de préférence au signulier) changer dans le schéma "banque de l'émtteur" par "banque du donneur d'ordre" numéroter tous les flux y compris le flux "info"

C. Vignet

Première modification réalisée. Le schéma sera corrigé demain matin.

-- Olivier.jousselin (discussion) 16 juin 2015 à 13:36 (CEST)

Le schéma a été modifié et clarifié.

-- Olivier.jousselin (discussion) 16 juin 2015 à 21:25 (CEST)

Je vous propose de modifier "identifier ses créanciers (SDD) et ses débiteurs (SCT)" par : identifier ses créanciers et ses débiteurs pour les prélèvements récurrents (SDD) ainsi que ses émetteurs et ses bénéficiaires de virements récurrents SCT). Ces notions sont reprisent plus bas dans la SMIRK. -- [[Utilisateur:Georges Deguimp / Azzana Consulting] 19 juin 2015 à 21:25 (CEST)

• Proposition de revoir une formule du § Cas d'usage

"De nombreux établissements bancaires proposent actuellement un service d’aide à la mobilité pour faciliter ce changement" --Jacques.baillon (discussion) 22 juin 2015 à 10:10 (CEST)

• Proposition dans le § Glossaire et Acteurs d'aligner la définition du "client migrant" sur la FBF avec les seuls cas de mobilité traité par le projet mobilité

Remplacer "Ce peut également être un ensemble de particuliers, pour un compte joint ou un compte indivis. " par :

"Les cas de transfert autorisés sont les suivants, toutes les autres possibilités étant non prévues

1. d'un compte individuel vers un compte individuel si le titulaire est le même
2. d'un compte joint vers un compte joint si tous les titulaires sont les mêmes
3. d'un compte en indivision vers un compte en indivision si tous les titulaires sont les mêmes
4. d'un compte individuel vers un compte joint si le titulaire du compte individuel est l'un des titulaires du compte joint"

--Jacques.baillon (discussion) 22 juin 2015 à 10:18 (CEST)

• Proposition dans le § Glossaire et Acteurs d'aligner la définition du DO

Remplacer " Donneur d'Ordre (ou 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. " par :

"Donneur d'Ordre (ou DO) : entité économique (entreprise ou particulier) qui émet des demandes de prélèvement sur le compte bancaire en tant que créancier, ou donne des ordres de virement au crédit du compte bancaire, du Client Migrant dans sa Banque d'Origine. Le terme de Donneur d'Ordre, qui prête moins à confusion dans la cadre de la messagerie SEPAmail, sera retenu en général. A noter qu'il est appelé parfois Emetteur dans les schémas de la FBF de début 2015 et que le GT CFONB du 15/06 a retenu l’intitulé Donneur D’Ordre pour les émetteurs de virements et Créanciers pour les émetteurs de prélèvements."

--Jacques.baillon (discussion) 22 juin 2015 à 10:30 (CEST)

• Proposition dans le § Glossaire et Acteurs d'enrichir avec la notion fondamentale de la loi Macron, le Mandat de Mobilité ainsi que la notion de la FBF de Dossier de Mobilité

"Mandat de Mobilité : Le mandat de mobilité est un contrat entre le client et la banque d’accueil qui prévoit que la banque d’origine agisse sur instruction de la banque d’accueil. La date de signature du mandat de mobilité valide du client migrant déclenche les délais des schémas de flux présentés. Un socle interbancaire juridique commun est en cours d'analyse juridique par la FBF."

"Dossier de Mobilité : Après signature du Mandat de Mobilité, il s'agit du dossier ouvert par la Banque d'Accueil identifié par un Numéro unique de dossier de mobilité. Cet identifiant ainsi que la Date de signature du mandat de mobilité font partie des éléments transmis à la Banque d'Origine, à l'exclusion du Mandat de Mobilité qui reste dans la banque d'accueil."

--Jacques.baillon (discussion) 22 juin 2015 à 10:39 (CEST)

• Proposition dans le § Principes de corriger le wording qui est incorrect :

Remplacer "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)" par :

"Il reste 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 Banque d'Accueil - Banque d'Origine) / le changement de domiciliation bancaire (flux 4, 4bis et 5 plus retour, dialogue Banque d'Accueil - Banques de DO voire DO eux-mêmes)"

--Jacques.baillon (discussion) 22 juin 2015 à 11:05 (CEST)

• Proposition dans le § Les opérations récurrentes de paiement de corriger le wording sur les opérations concernées

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

Par :

"Le Client Migrant 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 émis récurrents, SCT reçus récurrents , SDD reçus récurrents (les SDD One-Off ne sont pas pris en compte)/ Les chèques non débités sur les chéquiers, utilisés au sens qu'au moins un chèque du carnet a été utilisé et encaissé auprès de sa banque d'origine qui en a donc la trace, pendant les 13 mois au moment de la demande "

La suppression sur les SDD émis par le client particulier est proposée pour simplifier au démarrage, ce cas étant assez rare et peut être traité en option.

--Jacques.baillon (discussion) 22 juin 2015 à 11:18 (CEST)

• Proposition dans le § Les opérations récurrentes de paiement de préciser le wording sur le message de réponse

Aprés "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é. " Ajouter la précision suivante : "Si la demande de mobilité ne peut pas être traitée par la Banque d’Origine, un message de réponse particulier est prévu pour permettre à la Banque d’Origine d’indiquer qu’il lui est impossible de traiter la demande du Dossier de mobilité qui lui a été adressée par la Banque d’Accueil. Il contient le ou les motifs de rejet. (Par exemple : RIB incorrect, compte déjà clos, motif réglementaire, ...). Il est à noter que les analyses juridiques sont en cours à ce stade et que dès lors qu’un dossier fait l’objet d’un rejet, un nouveau dossier sera à présenter par la banque d’accueil si besoin (avec un nouveau n° unique)."

--Jacques.baillon (discussion) 22 juin 2015 à 11:28 (CEST)

• Proposition de changer le nom du § L'ordre de modification d'une opération de paiement

Le remplacer par le terme qui nous semble plus clair de "Le changement de domiciliation bancaire"

--Jacques.baillon (discussion) 22 juin 2015 à 11:31 (CEST)

• Proposition de correction dans le § L'ordre de modification d'une opération de paiement

Suppression de organisme qui présuppose une entreprise/personne morale : il ne faut pas oublier les DO PART. Remplacer "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. " Par : "Le Client Migrant désire modifier automatiquement sa domiciliation bancaire chez chacun des donneurs d’un ordre récurrent sur son compte bancaire. Le migrant souhaite savoir si ce changement de domiciliation est pris en compte et quelle est la date d’effet de cette modification."

--Jacques.baillon (discussion) 22 juin 2015 à 11:36 (CEST)

Clôture de compte

Dans le cas d'usage, il est indiqué que l'utilisation d'un service de mobilité automatique n'oblige en aucun cas le Client migrant à clôturer l'ancien compte. J'avais compris qu'il devait nécessairement le clôturer au maximum 3 mois après l'activation de mobilité. Est-ce un oubli ou bien la règle a changée ou est encore en discussion ? Hugues LECLERE

1) Toujours en cours de discussion 2) Hors scope SEPAmail (flux 6)

--Noël Dumand (Société Générale) (discussion) 12 juin 2015 à 16:01 (CEST)

Sauf erreur, la situation actuelle est que le Client Migrant dispose d'un certain délai pour clôturer son compte après signature du mandat de mobilité, s'il souhaite bénéficier du flux 6.

Et de toute façon, c'est effectivement hors de notre périmètre.

-- Olivier.jousselin (discussion) 16 juin 2015 à 13:36 (CEST)

Délais

L'expression des délais mentionnés dans le schéma des Principes ne me semble pas claire. Flux 2 il est écrit 2 J.O après étape 1, est-ce la date d'enregistrement, la date de signature qui est à prendre en compte ? Flux 3 : est-ce 5 J.O. après la date de réception de la demande de la banque d'accueil ou est-ce par rapport à la date de référence (date de signature ?) ? Remarque valable pour tous les flux. Hugues LECLERE

La date de signature du mandat de mobilité est la date "0". Flux 2 > La banque d'accueil a donc 2 jo après réception du mandat signé pour effectuer la demande d'informations auprès de la banque d'origine. Flux 3 > la banque d'origine a 5 jo après réception du flux 2 pour envoyer les informations demandées à la banque d'accueil

--Noël Dumand (Société Générale) (discussion) 15 juin 2015 à 10:21 (CEST)

Demande de modification directe entre Banque d'Accueil et Donneur d'Ordre

Comme vu lors de notre dernière réunion, il semble difficilement envisageable qu'un DO prenne en charge un flux automatisé (ici la demande de modification) en provenance d'une autre banque que l'une de ses banques partenaires. Du coup, ce flux (sous forme papier, mail ...) serait traité manuellement par le DO et demanderait un contact client avant de pouvoir être considéré comme fiable/traitable. Les délais me semblent alors difficlement applicables. Hugues LECLERE

Les délais imposés semblent désormais non modifiables et ne sont pas fixés par SEPAmail.

--Noël Dumand (Société Générale) (discussion) 15 juin 2015 à 10:11 (CEST)

Si je me souviens bien de ce qui a été dit par le représentant de l'AFTE lors de la dernière réunion, le point fondamental pour les DO est que les flux provenant de sources éventuellement diverses soient tous au même format, pour ne pas avoir N moulinettes à développer.

Mais évidemment les canaux de transmission restent à définir au cas par cas ...

-- Olivier.jousselin (discussion) 16 juin 2015 à 13:34 (CEST)

Sur cet écosystème banque DO, il y a plusieurs points de vue dans la loi Hamon et dans la loi Macron, sans compte la remarque de l'AFte reprise par Olivier à laquelle j'adhère. Néanmoins, il est important de rester sur le schéma le plus simple possible quitte à l'enrichier en,suite. Aussi, je suggère que nous établissions 2 catégories : - ce qui est obligatoire, soit à cause de la loi, soit parce que la FBF l'impose, soit parce que SEPAmail l'impose - ce qui est hors périmètre. Il est certain que la loi/FBF impose/ra de passer par les banques le message de demande de modification. Cependant, le seul qui devrait être en trait pleins, c'est à dire obligatoire au sens Norme, à ce stade, est celui entre la banque d'accueil et la banque du DO. Si l'AFTE s'engage pour tous les Do de France y compris les particuliers qui versent des pensions ... et qui sont des DO, alors il faut le rendre obligatoire entre Banque du DO et DO ; je doute que l'AFTE puisse s'engager, c'est d'ailleurs ce qu'a dit son représentant le 4 juin.

De même sur les messages de retour, si le Donneur d’ordre aura l’obligation d’informer son client migrant de la prise en compte de son changement de domiciliation, il n’a pas d’obligation de passer par sa banque pour le faire comme le laisse penser le schéma. En tout état de cause, ces flux doivent rester en pointillés et devraient être sortis de la V1 de la SMIRK, ou indiqués pour plus tard sinon dans les règles opérationnelles.

Enfin, la phrase "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" risque de devenir incorrecte avec le terme "substituer" via le décret HAMON à venir : s'il impose que ce soit bien l’émetteur Donneur d'Ordre qui doive en informer le client sur sa prise en compte.

--Jacques.baillon (discussion) 22 juin 2015 à 11:52 (CEST)

• Modification et remarques sur un paragraphe sur les cas particuliers

Remplacer ou revoir le § suivant : "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. 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. "

PAR :

"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 en France n'est pas encore raccordée à un système automatique de mobilité bancaire.

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 est laissé à l'iniative des deux parties."

Le canal évoqué "entre le Banque d'Accueil et le DO" semble hors sujet : la communication est beaucoup plus facile entre la banque DO et son DO qu’entre la banque d’accueil et le DO qui peuvent n’avoir aucune relation ! En particulier, le canal EBICS est peu envisageable si le DO n’est pas un client de la banque d’Accueil.

--Jacques.baillon (discussion) 22 juin 2015 à 12:01 (CEST)

Formulation "client migrant désire"

La formulation le client migrant "désire" peut être trompeuse et suggérer que le client peut choisir entre obtenir les informations sur les opérations concernées et/ou demander la migration de ses coordonnées. Dans les faits, le client qui va signer un mandat de mobilité aura les 2 aspects traités de facto, et pas l'un ou l'autre.

Par ailleurs, le client va récupérer la totalité des opérations de paiement réalisées sur les 13 derniers mois, et non "certaines opérations de paiements".

--Noël Dumand (Société Générale) (discussion) 15 juin 2015 à 11:18 (CEST)

Texte modifié aux deux endroits pour clarifier la situation.

-- Olivier.jousselin (discussion) 16 juin 2015 à 13:31 (CEST)

SCT émis

Dans les opérations récurrentes de paiement, la FBF précise "virements permanents émis" et non "SCT émis", ce n'est pas la même chose.

--Noël Dumand (Société Générale) (discussion) 17 juin 2015 à 14:25 (CEST)

Écosystèmes

Il y a un réel besoin de pouvoir répartir les messages en fonction de leur nature, et notamment du rôle dont ils relèvent : Banque d'Accueil, Banque d'Origine, Banque de DO.

Toutefois, cette répartition ne passe pas forcément par des écosystèmes distincts. Tous les messages peuvent appartenir au même écosystème, le tri étant réalisé à l'arrivée, par exemple grâce à un en-tête SMTP spécifique ("X-SEPAmail-mobility = accueil").

La notion d'écosystème étant multi-formes dans SEPAmail, il est très délicat de privilégier l'un des usages (celui de l'adressage) sur l'autre (celui du regroupement de messages). Le point crucial est que le certificat – ou plus exactement les certificats puisqu'il y en a deux à chaque fois – dépendent de l'écosystème.

Concrètement, il y a deux possibilités qui ont un sens :

• un seul écosystème, avec une séparation des messages à l'arrivée, par exemple comme décrit ci-dessus. Ceci permet bien de traiter les rôles de façon distincte, mais si certains messages doivent être lus par un prestataire externe, celui-ci devra disposer des clés de l'écosystème mobility. Cette clé est certes sous la responsabilité de l'adhérent, mais il n'est pas forcément aberrant qu'elle soit confiée à un prestataire dans un cadre précis.
• trois écosystèmes, les messages arrivant alors dans 3 boîtes à lettres. Ceci nécessite trois certificats (en fait 6), mais permet de donner seulement l'une des clés à un éventuel prestataire.

Dans les deux cas, le fait que des missives soient traitées hors du périmètre du MTA récepteur crée des difficultés techniques, notamment pour l'envoi de la missive d'acquittement. Une solution simple pourrait être que le MTA de l'adhérent joue le rôle de relais de mail pour cette missive. Une autre solution serait de déchiffrer la missive lors de son arrivée chez l'adhérent, et de router le message vers un prestataire par un canal défini de façon bilatérale, et de procéder de façon similaire pour l'acquittement.

Au vu de ces éléments, il me semble plus logique de conserver un seul écosystème pour la mobilité.

De façon plus générale, une réflexion est en cours sur le routage au sein de SEPAmail, permettant à chaque adhérent de disposer de plusieurs plates-formes SMART pour gérer les applications SEPAmail de façon souple et facilement évolutive.

• Pour une aide au choix

La souplesse de l'architecture avec ou sans prestataires, voir réversibilité, pousse à plusieurs ensembles permettant le tri, à l'arrivée ( plaide pour 1, 2 ou 3 avec en-tête SMTP spécifique) mais aussi au départ (plaide pour 2 ou 3). L'évolutivité de l’écosystème pour la banque du DO va entrainer des évolutions et des comportements sur des services optionnels, alors que les dialogues entre Banque du Débiteurs (Origine ou Accueil), par leur symétrie de rôles et leur encadrement légal et FBF sont très centrés et peu susceptibles, et c'est souhaitable, d'évoluer à court terme. 2 écosystèmes serait ils un compromis ? A partir des raisonnements logiques et des discussions riches de la précédente version sur ce thème, et de la maturité des échanges, serait-il possible de disposer d'un récapitulatif des avantages/inconvénients des trois solutions 1, 2, ou 3 ecosystème ? qui permette de trancher rapidement ? --Jacques.baillon (discussion) 22 juin 2015 à 15:01 (CEST)

Comme indiqué lors de la dernière réunion du "club mobilité", nous n'envisageons pas de discuter et de "trancher" ce point structurant pour notre infrastructure en dehors d'une instance ad'hoc réunissant des experts techniques. Cela ne remet pas en cause l'utilité d'un tableau récapitulatif des avantages/inconvénients de chaque solution qui pourra servir de support à cette instance dédiée.

--Noël Dumand (Société Générale) (discussion) 22 juin 2015 à 15:12 (CEST)

nouvelle obligation de la loi Macron

Le texte de l'amendement à la loi Macron sur la mobilité bancaire validé en deuxième séance du parlement a introduit le paragraphe suivant relatif au solde du compte d'origine.

« L’établissement de départ transfère tout solde positif éventuel du compte, sous réserve de disposer des informations permettant d’identifier l’établissement d’arrivée et le nouveau compte du client. Ce transfert est opéré à la date sollicitée par le client qui correspond à au moins six jours ouvrés après la réception de la demande de clôture du compte. » ;

Cette nouvelle obligation fera t-elle l'objet d'un flux supplémentaire dans Aigue-Marine entre la banque d'accueil et la banque d'origine ou est-elle hors scope ? Comment faut-il entendre la date sollicitée par le client ?

Catherine Gondelmann, Explain le 18 juin 2015 à 17:00 (CEST)

En cours de discussion côté FBF.

--Noël Dumand (Société Générale) (discussion) 22 juin 2015 à 10:27 (CEST)

la demande d'informations

La définition du mandat de mobilité appelé autorisation dans la Directive compte de paiement (voir extrait ci-dessous) permet au consommateur d'identifier les opérations à transférer sur le nouveau compte. Des discussions de la réunion du 4 juin, il ressortait que la demande d'information à la banque d'origine concernait l'ensemble des opérations de virement et prélèvement émises vers le compte d'origine, de même que l'extraction et la transmission de cet ensemble à la banque d'accueil. La banque d'accueil pouvant alors proposer un service additionnel (mentionné dans le présent texte) au client migrant consistant à sélectionner les opérations qu'il souhaite migrer.

L'approche aigue-marine est compatible avec l'esprit de la Directive mais propose un choix au client migrant a posteriori. Dès lors, ce service additionnel ne deviendrait-il pas obligatoire pour la banque d'accueil sous la plume de la transposition par le législateur français ?

Autre question plus problématique, l'autorisation devrait contenir la date à partir de laquelle le client migrant souhaite que les ordres permanents de virement et les mandats de prélèvement doivent être exécutés à partir du compte de paiement. Aigue-Marine en ignorant cette date dans le mandat, répond au dispositif de la loi française qui ne la mentionne pas. Ne s'agit-il pas, de fait, d'une solution à vocation purement nationale ?

• Extrait de la Directive compte de paiement (92/2014 EU) : "L’autorisation permet au consommateur d’identifier spécifiquement les virements entrants, les ordres permanents de virement et les mandats de prélèvement qui doivent être transférés. Elle permet également aux consommateurs de préciser la date à partir de laquelle les ordres permanents de virement et les mandats de prélèvement doivent être exécutés à partir du compte de paiement ouvert ou détenu auprès du prestataire de services de paiement destinataire. Cette date est fixée à au moins six jours ouvrables à compter de la réception, par le prestataire de services de paiement destinataire, des documents communiqués par le prestataire de services de paiement transmetteur en vertu du paragraphe 4. Les États membres peuvent exiger que l’autorisation donnée par le consommateur le soit par écrit et qu’une copie en soit remise à ce dernier."

Catherine Gondelmann, Explain le 18 juin 2015 à 17:33 (CEST)

Pour moi, les deux questions sont dans les mains de la FBF aujourd'hui :

• Pour le choix des opérations, il est effectivement dit que ce serait du tout ou rien, ce qui n'empêche en effet pas la banque d'offrir ce service à son client. Ce n'est pas "a posteriori", puisque rien n'a encore été transmis aux DO, donc ce n'est à mon avis pas contraire à la directive UE.
• Pour la date, une date de fin de collecte figure actuellement parmi les informations à transmettre par la Banque d'Accueil, mais sa présence définitive n'avait pas encore été validée lors de notre dernière réunion.

-- Olivier.jousselin (discussion) 18 juin 2015 à 17:38 (CEST)

La mobilité bancaire française ne correspond pas de façon totalement équivalente à la mobilité de la PAD. Le principe du tout ou rien reste problématique car effectivement dans la PAD le client peut choisir à l'initialisation de sa mobilité (dans l'autorisation) quelles opérations il souhaite migrer de son ancien compte vers son nouveau compte. Avec le tout ou rien de la mobilité française, et à moins de réintroduire d'autres flux (surtout pour les ordres de virements permanents), il sera compliqué à postériori selon les souhaits du client, pour la banque d'origine de garder une partie des opérations et pour la banque d'accueil de garder l'autre partie.

Pour la date de fin de collecte, de notre point de vue c'est différent de la date prévue dans la PAD (date à laquelle le transfert doit être effectif entre les 2 banques).

Nous dressons donc le même constat, à savoir qu'on s'oriente ici vers une mobilité bancaire "nationale" qu'il faudra probablement adapter pour être en adéquation avec la PAD. Cela n'est toutefois pas du ressort de SEPAmail.

--Noël Dumand (Société Générale) (discussion) 19 juin 2015 à 09:37 (CEST)

De mon point de vue le mandat couvre la banque du migrant pour effectuer une demande d’information vers la banque quittée. Néanmoins, je pense qu’à ce stade de la réflexion, le client doit valider que les opérations que la banque quittée a transmise sont bien les opérations qu’ils souhaitent migrer sur son nouveau compte (même dans un contexte de migration globale). Si le principe est acceptable pour le groupe de travail, sur le schéma il est nécessaire de matérialiser cette validation. Même si il est dit plus bas que les flux entre les clients migrants et les banques sont exclus du périmètre actuel (les flux 1, 3bis et 3 ter sont des flux entre le migrant et la banque d’accueil).

--Utilisateur: Georges Deguimp Azzana Consulting19/06/2015

Nous sommes ici sur le principe du "tout ou rien". Par défaut, la banque d'accueil va remettre en place la totalité des opérations sur le nouveau compte à partir des informations reçues de la banque d'origine. Autant pour les prélèvements, la banque d'accueil pourrait éventuellement faire un filtrage (à la demande du client) vers les banques de créanciers pour permettre de sélectionner les opérations, idem pour les virements reçus avec les banques de donneur d'ordre. Autant pour les virements permanents émis, comme indiqué dans mon commentaire précédent, si le client fait une demande de filtrage à postériori cela impliquera la mise en place d'un nouveau flux vers la banque d'origine ce qui ne parait pas souhaitable à ce stade, ni envisagé par la FBF. Pour pouvoir faire un filtrage "efficace", il aurait été plus simple de reprendre ce qui est envisagé par la PAD, c'est à dire indiquer directement dans le mandat de mobilité les opérations à laisser dans la banque d'origine et celles à migrer. Mais ce n'est pas le dispositif retenu pour la mobilité bancaire française.

--Noël Dumand (Société Générale) (discussion) 22 juin 2015 à 09:51 (CEST)

Je suis en phase avec Noel. la banque d'accueil pourrait éventuellement faire des choses et en fera surement pour celles qui ont et des moyens et du temps. Néanmoins, pour ce projet, il est impératif de rester sur le principe du "tout ou rien", non pas pour ne pas répondre au besoin, qui existe, mais pour respecter la simplicité de la version initiale de Ambre/Aigue-Marine, qui doit être prête dans quelques mois pour construction, les acteurs ont intérêt à ne pas compliquer le besoin, qui reste entre les mains de la FBF. Les SVA de tels ou tels, une fois la smirk sont à voir ultérieurement. --Jacques.baillon (discussion) 22 juin 2015 à 10:59 (CEST)

proposition de nom pour le projet

Nous vous proposons un nouveau nom : "AMBre" acronyme français de « Accompagnement de la Mobilité BancaiRE », c’est une pierre organique certe mais l'acronyme semble cohérent. --Utilisateur: Georges Deguimp Azzana Consulting19/06/2015

Bien que tardif 2 idées de pierres EMERAUDE Ecosystème de MobilitE bancaire par Echange RAtionnels entre Utilisateurs DE SEPAmail MARBRE Mobilité Automatisée paR les Banques, opérateuRs et Emetteurs donneur d'ordre

--Jacques.baillon (discussion) 23 juin 2015 à 11:13 (CEST)

Besoins des acteurs

Les besoins des deux clients de « aigue marine » sont maintenant posés, ne faut il pas se poser la question des données qui seront nécessaires pour répondre a ces besoins ? Cela permettra, par la suite, de s’assurer que le format que va proposer la FBF sera bien en adéquation avec les besoins de SEPAmail. --Utilisateur: Georges Deguimp Azzana Consulting19/06/2015

Le groupe CFONB sur la mobilité bancaire définit actuellement les données et les formats.

--Noël Dumand (Société Générale) (discussion) 22 juin 2015 à 09:41 (CEST)

• Corrections sur ce paragraphe § Besoins des acteurs

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

Par : "Les besoins du Client Migrant sont identifier ses DO Créanciers (SDD) et ses Donneurs d'Ordres (SCT)" " Les besoins du DO sont identifier de façon unique et non ambigüe ses débiteurs (SDD) ou ses bénéficiaires (SCT)."

--Jacques.baillon (discussion) 22 juin 2015 à 10:45 (CEST)

Remarques

Nous pensons que ce paragraphe doit être revu.

Actuellement il est composé de : "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."

• Wording

Dans le cas d’un ordre de virement -> Pourquoi faire un cas particulier d’un ordre de virement ? Dans les 2 cas (virement et prélèvement), il est indispensable que le DO identifie de manière certaine le client migrant.

• Diamond

L'idée de proposer au DO de fiabiliser les coordonnées bancvaires en utilisant Diamond est excellente à notre sens. Nous suggérons que cette remarque soit également intégré et mise en avant du coté de l'éco-système Banque d'Accueil pour s'assurer de la recevabilité de la demande de Mandat de mobilité par une interrogation préalable via Diamond sur le compte à migrer. Cela éviterait ainsi d'avoir des rejets pour raison de rejet de rib incorrect par exemple. Cette idée serait à mettre également dans le § coté validation du mandat de mobilité BA BO

--Jacques.baillon (discussion) 22 juin 2015 à 12:14 (CEST)

Application, ecosystème et besoins transverses

Dans ce paragraphe, nous avons deux remarques :

• Sur l'annuaire

Est-ce que le besoin d'atteignabilité, via SEPAmail du DO que va avoir la banque d'accueil, ne nécessiterait pas un Annuaire central de ceux qui seront début 2017 atteignables via SEPAmail (en nombre restreint probablement, ICQX ?, ICS ?, ... à charge pour la banque du DO de le renseigner). Cela évitera d'envoyer à la banque du DO des demandes qui ne pourront aboutir de toute façon (cas des PME qui ne sont pas connectée), sachant qu'un très grand nombre de DO ne le sera pas (cas des particuliers DO). Et au contraire, facilitera la gestion des grands créanciezrs/DO qui auront fait la connexion à leur banque pour automatiser.

• Sur les statistiques

Il pourrait y avoir des besoins complémentaires de statistiques, non pas liées au volume de messages échangés qui sont celles par défaut mais au nombre d'information sur les domiciliations retournés pour chaque type de paiement.

--Jacques.baillon (discussion) 22 juin 2015 à 13:15 (CEST)

Sur l'annuaire, et compte tenu du fait que SEPAmail est à ce jour une messagerie interbancaire exclusivement, nous ne pensons pas qu'il soit utile d'instruire ce point d'atteignabilité du DO via SEPAmail. Pour les banques d'accueil qui devront joindre des DO hors France (flux 4 bis) ou des banques du DO qui adresseront des petits et moyens créanciers, et même des grandes entreprises, nous pensons qu'il faudra prévoir les moyens ad'hoc (évolutions des banques à distance "entreprises/pro", voir des banques à distance "particuliers" pour les émetteurs particuliers ou autres moyens appropriés, canaux sécurisés EBICS/SWIFTNet pour les moyens et grands créanciers/DO ).

--Noël Dumand (Société Générale) (discussion) 22 juin 2015 à 16:54 (CEST)

SEPAmail est une messagerie certes inter PSP, et à finalité 4 coins dont l'objet reste de faire dialoguer des acteurs économiques par échange de documents commerciaux (cf préambule du contrat d'adhésion et objet social de la société). Les "évolutions des banques à distance ou autres moyens appropriés, canaux sécurisés" de l'ensemble du marché seraient souhaitables en 1, 5 an si le cout en vaut la chandelle. Sinon, une solution simple et rapide pour répondre à l'obligation légale d'informer le DO par la BA reste pour nous à discuter car facilite le développement : 1) si dans la liste message 2) sinon adressage par tous moyens ? Cela apporterait des économies et d'échelle et de temps, ce qui pour un projet à date contrainte est impératif. Dit autrement si 10 créanciers sont capables de traiter des messages relayés dans 2 ans, autant les connaitre. On peut imaginer aussi que chaque acteur se gère ces 10 noms dans son système, et les relations contractuelles associées... et effectivement ne pas l'instruire dans la Smirk est possible. Pour échange. --Jacques.baillon (discussion) 22 juin 2015 à 17:19 (CEST)

Informations complémentaires : Autour du mandat

• Proposition de revoir le wording et de compléter le paragraphe avec les précisions FBF structurantes

Modifier le sous-titre et ajouter "Autour du Mandat de Mobilité"

Par ailleurs, le texte d'origine est : "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."

Nous proposons la modification et l'enrichissement suivant : "La Banque d'Accueil doit pouvoir, dans certains cas, prouver à la Banque d'Origine et au donneur d’ordre qu’elle dispose bien du Mandat de Mobilité de son client, lequel est aussi client, et en ce sens seulement client "commun", de la Banque d'Origine et du Donneur d'ordre dans des relations contractuelles distinctes. Des cas particulier, et fréquents, 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 la Banque d'Accueil autour du Mandat de mobilité est de : - transporter vers la Banque d'Origine la référence unique du Dossier de mobilité ouvert par la Banque d'Accueil, ainsi que la date de signature du Mandat de Mobilité et autres informations détaillées qui seront précisés 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 la Banque d'Accueil et son client. Le reste est couvert par la loi.

En option, notamment lorsque Sepamail ne serait pas utilisé, il peut être prévue en option un champ optionnel pour véhiculer un document en pièce jointe (codé en base 64, type PDF ou autre norme Cerfa à venir). En option également, afin de diminuer les rejets pour RIB inatteignable, il pourrait en option être utile de vérifier au moment de la validité du RIB de l’ancien compte par l'utilisation de l'application Diamond, si la banque d'origine adhère à cette application."

--Jacques.baillon (discussion) 22 juin 2015 à 13:40 (CEST)

Informations complémentaires : Prise en compte du QXBAN

Ces éléments ne nous semble pas prioritaires au vu du déploiement probable au démarrage et devrait rester optionnel, au démarrage. De même que pour les prélèvements récurrents liés à des remboursements de crédits, ou de carte bancaires, sont hors périmètre, alors que très fréquents, ce devrait être au client de faire son affaire des changements de référence auprès de sa Banque d'Accueil et de son Donneur d'Ordre qui a recueilli son consentement pour le service Rubis avec un identifiant dit QXBAN.

• Sur option ,"On devrait intégrer la possibilité de demander des informations sur la base d'un QXBAN et non seulement d'un IBAN."

• Proposition de supprimer compte tenu de l'explication ci-dessus : "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."

--Jacques.baillon (discussion) 22 juin 2015 à 13:49 (CEST)

Informations complémentaires : Services additionnels

"À terme, elle pourrait proposer au Client Migrant : a)de sélectionner les opérations qu'il souhaite migrer b)de migrer les opérations à partir de plusieurs comptes bancaires"

Nous souhaiterions supprimer ou à tout le moins, modifier le phrasé qui laisse penser que la loi va évoluer sur les deux idées de services additionnels : a) Le service de mobilité repose sur le principe du « tout ou rien ». Il n'y a pas de picking possible par le client. b) le service de mobilité et la loi qui l'encadre par le "Mandat de Mobilité" concerne un et un seul compte.

--Jacques.baillon (discussion) 22 juin 2015 à 13:56 (CEST)