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

Ajoutez ici vos commentaires, questions, remarques... Merci de signer, cela facilitera les échanges. --Olivier.jousselin (discussion) 12 mai 2015 à 21:05 (CEST)

Combien d'écosystèmes ?

Actuellement la SMIRK en prévoit un seul. Le document de cadrage en envisage 3 :

• un pour la banque d'accueil
• un pour la banque d'origine
• un pour la banque de DO

Inconvénient : cela complique un peu le fonctionnement

Avantage : les messages arrivent dans 3 boîtes à lettres (BAL) séparées, ce qui facilite le traitement par des plates-formes différentes. Techniquement, on peut aussi utiliser une BAL unique, et trier les messages par certificats, mais cela oblige de toute façon à avoir des certificats distincts.

Qu'en pensez-vous ? --Olivier.jousselin (discussion) 18 mai 2015 à 12:17 (CEST)

Pour gérer des boites aux lettres d'un même domaine, il faut tout de même une grappe unique de MTA configurée au niveau DNS par le type de record MX, donc l'avantage n'en est pas vraiment un.

Il y a d'autres façon de séparer un flux d'information en amont avec SMTP (mode canonique qui impose le cadre de la réflexion), notamment du côté des domaines utilisés (le BIC est donc un bon candidat pour les organisations radicalement différentes des adhérents actuels)

La notion d'écosystème est une notion fonctionnelle de partition et non pas une configuration de l'organisation des relais de la messagerie SEPAmail.

Je ne vois pas non plus pourquoi complexifier plus le routage de SEPAmail en introduisant des sous-écosystèmes, comme cela a été évoqué.

Pour la bonne scalabilité de cette application et notamment des autres flux éventuels de mobilité (civile, postale, électronique), je suis pour un seul écosystème.

Manfred S. OLM, cabinet deciBI (discussion) 19 mai 2015 à 12:00 (CEST)

Pour ma part ce serait plus évolutif d’avoir 3 écosystèmes car ils peuvent être vendus et évolués séparément. Je pense que l’écosystème pour la banque du créancier intitulé DO va évoluer ou comporter des services optionnels: à ce jour rien n’est prévu pour lui rerouter des mandats de SDD actualisés (le client débité a initialement donné un mandat pour un SDD sur un BIC/IBAN qui n’existe plus, il devrait logiquement en signer un nouveau et le faire suivre à son créancier. Via AIGUE Marine on pourrait très bien décider de renvoyer aussi ces mandats actualisés de manière groupée et dématérialisée)

--Bernard Gouraud

Je ne sais pas quelle sera la bonne solution mais avant d'en parler, voici comment je vois le besoin. Il est important d'offrir le plus de souplesse dans le choix par chaque PSP de sa mise en oeuvre :

• un PSP doit être en capacité de recevoir soit :
  • sur une seule infrastructure tous ses flux (Rubis, Aigue-Marine,...)
  • sur plusieurs infrastructures, c'est à dire une pour RUBIS et une pour Aigue-marine. Ceci pour lui permettre de sous-traité le cas échéant si sa planification interne n'est pas compatible avec le délai demandé
• l'infrastructure d'un PSP (member BIC) doit pouvoir accueillir le member BIC d'un autre PSP. En effet, il peut y avoir une opportunité pour plusieurs PSP de se féderer sur une même infrastructure pour des raisons de couts/délais, voir pour un adhérent actuel de proposer son infratructure à d'autres PSP :
• concernant uniquement Aigue-marine, un PSP doit pouvoir être en mesure de séparer les 3 responsabilités (banque quittée, banque d'accueil, banque de l'émetteur) sur trois infrastructures différentes s'il le juge utile (il ne faut pas que la norme soit un frein à une telle séparation).

Cyril Vignet, BPCE

J'ai un doute quant à ma compréhension de la question sur les écosystèmes. Un écosystème est, au sens SEPAmail, une famille de message. Dans ce cadre il est identifié sur la base des échanges en mode 4 coins. Dans la description de la SMIRK, je comprends qu'il y a 2 écosystèmes :

• un écosystème d'"échange des opérations récurrentes de paiement" :
  • Request : envoi du mandat signé
  • Report : retour des opérations récurrentes de paiement (si le migrant est habilité à effectuer la demande)
• un écosystème de "modification d'une opération de paiement" :
  • Request : envoi des ordres de modification
  • Report : résultat de la prise en compte de l'ordre

A ma lecture, les 3 ecosystèmes du document de cadrage semblent renvoyer plus au rôle des différents acteurs et peut-être à la notion de "service" (cf. référentiel BIC.service@Scheme). En effet, si je fais l'analogie avec le fonctionnement de RUBIS, il y a un écosystème pour émettre et recevoir des demandes de règlement. Des banques peuvent prendre des rôles différents en se positionnant uniquement en tant que banque de créancier (souscription au service "RubisSndRequest") ou banque de débiteur (souscription au service "RubisRcvRequest").

Quant à la question de 1 ou plusieurs écosystèmes, ma position serait surtout de savoir si une famille de message peut exister sans l'autre. C'est la réflexion qui me semble a prédominé dans le découpage de DIAMOND et de GEMME.

Lionel Chemla, Gfi (discussion)

Effectivement, au sens de famille de messages, on pourrait voir 2 éco-systèmes. En fait, si on en met trois, on sépare la demande d'informations et le retour, les 2 autres messages restant dans l'écosystème "banque de DO". Ceci permet néanmoins d'avoir des traitements distincts -- et surtout des plates-formes distinctes -- pour la banque d'origine et la banque d'accueil, pour lesquelles le traitement des données est complètement différent.

Un point délicat est que l'écosystème a deux significations :

• une famille de messages -- et dans ce sens, un ou à l'extrême rigueur deux écosystèmes font l'affaire
• une adresse de routage des missives (ecosystem@BIC.sepamail.eu) -- et dans ce sens il en faudrait 3

Je déporte la discussion "technique" sur le routage dans un autre paragraphe...

-- Olivier.jousselin (discussion) 26 mai 2015 à 15:30 (CEST)

Infrastructure et routage

[je reprends quelques commentaires qui figuraient ailleurs]

• un PSP doit être en capacité de recevoir soit :
  • sur une seule infrastructure tous ses flux (Rubis, Aigue-Marine,...)
  • sur plusieurs infrastructures, c'est à dire une pour RUBIS et une pour Aigue-marine. Ceci pour lui permettre de sous-traité le cas échéant si sa planification interne n'est pas compatible avec le délai demandé
• l'infrastructure d'un PSP (member BIC) doit pouvoir accueillir le member BIC d'un autre PSP. En effet, il peut y avoir une opportunité pour plusieurs PSP de se féderer sur une même infrastructure pour des raisons de couts/délais, voir pour un adhérent actuel de proposer son infratructure à d'autres PSP

Cyril Vignet, BPCE

je rejoins la remarque de Cyril en précisant néanmoins que les référentiels SEPAmail ne me semblent pas permettre à ce jour ce découpage : un "internalRouteBIC" est associé à 1 et 1 seul "MemberBIC".

Lionel Chemla, Gfi (discussion)

On peut aussi faire évoluer le référentiel BIC@scheme, pour qu'il devienne BIC.ecosysteme@scheme. On pourrait alors avoir beaucoup plus de souplesse dans le routage et la gestion...

--Olivier.jousselin (discussion) 26 mai 2015 à 12:06 (CEST)

Quels flux prendre en compte ?

Le besoin initial repose sur les discussions au sein du CCSF. Cependant SEPAmail a aussi des besoins complémentaires comme la migration des comptes SEPAmail, même si ce n'est pas à ce jour une obligation règlementaire. Ne pourrait t'on rajouter sous forme d'un complément optionnel, des données qui permettent, à la banque d'accueil, d'indiquer un QXBAN et de recevoir les idications sur les flux reçus sur ce QXBAN. En effet, ceci est presque une évidence pour RUBIS (le client change de Banque mais les message RUBIS continue d'arriver sur l'ancienne banque) mais aussi pour GEMME surtout si ce dernier est mis en oeuvre en utilisant le QXBAN pour protéger l'IBAN du débiteur (voir concept ci-dessous).

Cyril Vignet, BPCE

Revue de la terminologie

Ne faut-il pas revoir la SMIRK proposée en revoyant la terminologie pour avoir une cohérence entre le document de cadrage et la SMIRK pour un meilleur dialogue entre les différentes sources des documents (ISILIS, SEPAmail, CFONB, FBF).

Cyril Vignet, BPCE

Bien sûr. Hélas, le vocable d'émetteur utilisé par la FBF prête un peu à confusion, dans la mesure où nous parlons d'une messagerie : la banque d'accueil est l'émetteur des messages de demande d'informations et de demande de modifications. Pourrions-nous conserver celui de donneur d'ordre, qui, me semble-t-il, est clair et adapté ?

-- Olivier.jousselin (discussion) 26 mai 2015 à 15:41 (CEST)

Opérateur de mobilité

Je m’interroge sur le statut d’opérateur de mobilité. Pouvez-vous me décrire ses responsabilités SVP ? Merci d’avance. Patrick PELTIER

L'opérateur de Mobilité travaille aujourd'hui pour le compte de la banque qui accueille le nouveau client : Isilis est cité dans le SMIRK, mais il y a aujourd'hui en France à minima 3 opérateurs : Docapost est l'un des ces opérateurs depuis plus de 10 ans. Nous sommes missionnés par des banques pour prendre en charge :

1) La relation avec la banque qui initie le dossier de mobilité

2) La relation avec le client (signature de mandat, collecte des organismes, suivi du dossier...)

3) La relation avec les organismes qui prélèvent ou virent de l'argent sur l'ancien compte bancaire : information envoyée (en direct pour le moment) aux organismes pour les informer du changement de banque de leur client / assuré / adhérent ...

Ce périmètre va bien sûr évoluer dans le cadre de l'amendement Macron. [Marc Delesalle / Docapost]

Je précise que le terme est ici utilisé dans une acceptation délibérément vague : il y a effectivement 3 opérateurs principaux aujourd'hui en France, dans le schéma actuel, mais comme l'indique Marc, rien ne nous dit que d'autres ne vont pas apparaître à la faveur de la loi Macron, avec un fonctionnement et/ou un périmètre potentiellement différents.

-- Olivier.jousselin (discussion) 26 mai 2015 à 16:04 (CEST)

Contrôle du migrant

Il existe plusieurs cas d'usage (en complément des contrôles de lutte contre la fraude mentionnés dans la SMIRK) qui pourraient amener la banque d'origine (ou banque quittée) à rejeter un mandat. En effet, certains comptes possèdent des particularités qui pourraient limiter le droit du migrant à demander la mobilité (ex. compte joint pour lequel seul un des titulaires demanderait la migration, compte de personne sous tutelle...).

Pour répondre à ces usages, il semble intéressant que le message d'émission de mandat puisse porter plusieurs signatures, et que les contrôles de la banque quittée lui permettent de répondre par un refus motivé à la demande de mobilité.

Lionel Chemla, Gfi (discussion)

Il nous semble important de préciser les aspects sécurisant la précision des coordonnées bancaires par le migrant ; en effet, pour les virements, il ne s’agirait pas qu’un migrant indique un ancien compte ne lui appartenant pas ; la banque d’accueil ne peut pas effectuer le contrôle ; quel process pour la banque quittée ?

Hugues Leclere, SOPRA Banking

La signature du mandat de mobilité est hors périmètre : c'est la banque d'accueil qui doit s'assurer de l'identité de la [des] personne[s] demandant la migration et qui signe[nt] ce mandat.

En complément, il faut évidemment prévoir des cas de refus explicites (différence de titulaire, compte déjà fermé...). Je ne suis pas sûr que le process côté banque d'origine soit dans le périmètre de l'étude actuelle.

-- Olivier.jousselin (discussion) 26 mai 2015 à 16:02 (CEST)

fichiers ISO

Serait-il possible de récupérer le flux réponse au camt.060 mentionné dans la SMIRK ? Pourriez-vous préciser comment les flux s'intègrent-ils avec les travaux de normalisation du CFONB ?

Lionel Chemla, Gfi (discussion)

Que veut dire "récupérer" ? Le flux retour sera facultatif, parce que le CCSF ne le rend pas obligatoire. Toutefois, il sera chaleureusement recommandé...

Théoriquement, le CFONB doit travailler sur 4 messages, ceux présents dans la SMIRK actuelle. Je m'en assurerai.

-- Olivier.jousselin (discussion) 26 mai 2015 à 15:43 (CEST)

Vérification faite, le flux retour est hors périmètre CFONB, nous allons donc devoir le spécifier nous-mêmes. J'ajoute le nécessaire sur le Wiki demain.

-- Olivier.jousselin (discussion) 26 mai 2015 à 17:17 (CEST)

Le flux retour du camt.060 est la réponse de la banque d'origine à la banque d'accueil (ou son opérateur de mobilité puisque c'est cette banque qui doit proposer et favoriser le service)

C'est un flux (message RecurrentOperationReport) qui serait un bon candidat à l'iso20022, segment camt, peut-être dans l'intervalle 08X,

mais il n'existait pas encore au moment de la publication de la SMIRK

Son intérêt fonctionnel est de pouvoir renvoyer des agrégats sur un n-uplets d'identifiants :

* identifiant opération

* identifiant donneur d'ordre ou émetteur de la référence initiale (attention à cette notion pour l'application RUBIS@SEPAmail)

* identifiant de la zone d'identification (SEPA, etc...)

* intervalle de dates = période demandée

on retrouve sa spécification dans cette partie de la directive d'implémentation

Ce message peut donc servir à la banque d'origine pour répondre à la requête sur les opérations récurrentes et pourrait facilement s'adpater à la restitution des formules de chèques émises

Il a un intérêt en dehors du cadre de la mobilité pour transférer des données d'agrégats à des fins de reporting et d'informatique décisionnelle

Manfred S. OLM, cabinet deciBI (discussion) 28 mai 2015 à 16:04 (CEST)

Au temps pour moi en effet. Je ne peux donc que reprendre mon argument initial : ce flux étant obligatoire et dans le schéma de la FBF, c'est le CFONB qui spécifiera comment les informations spécifiées par la FBF seront organisées dans le message retour.

Mais je ne vois toujours pas ce que tu veux dire par "récupérer" le flux réponse, Lionel ?

-- Olivier.jousselin (discussion) 29 mai 2015 à 08:15 (CEST)

Diagrammes de séquence

Les 2 diagrammes de séquences présentés dans le chapitre "principes" sont difficilement lisibles (surtout celui décrivant l'échange des opérations récurrentes). Serait-il possible d'en améliorer la définition ? Merci d'avance

Lionel Chemla, Gfi (discussion)

J'ai demandé à l'auteur de nous fournir une version plus claire, je les mettrai en ligne dès que possible.

diagramme en bonne résolution ajoutés ce jour

Manfred S. OLM, cabinet deciBI (discussion) 28 mai 2015 à 15:50 (CEST)

--Olivier.jousselin (discussion) 26 mai 2015 à 11:10 (CEST)

A ce jour il n'est pas prévu par les différentes instances qu'un opérateur de mobilité puisse traiter directement avec les clients ou les donneurs d'ordre comme le laisse sous entendre les diagrammes de séquences proposés. D'autre part, seuls les PSP sont aujourd'hui autorisés à échanger sur la messagerie SEPAmail. Il n'est par contre pas exclu qu'une banque puisse sous-traiter tout ou partie de sa relation avec les clients et/ou les donneurs d'ordre.

--Noël Dumand (Société Générale) (discussion) 28 mai 2015 à 15:28 (CEST)

Message de retour

Il faudrait sans doute éclairer l’intérêt du message de retour de la part du DO de manière à voir si cela est effectivement applicable

Hugues Leclere, SOPRA Banking 27 mai 2015 à 16:20 (CEST)

L'un des intérêts est que, si le DO ne répond pas, la banque d'accueil n'a aucune information. Or c'est elle que le client va appeler pour savoir où les choses en sont, ou pourquoi cela n'a pas marché. Il semble donc pertinent qu'elle puisse lui répondre.

De plus, cela peut être un service supplémentaire qu'elle propose à ses clients DO : << vous me répondez à moi au lieu de répondre à votre client, moi je lui fais suivre l'info, donc vous êtes en règle avec la législation et c'est plus simple/moins cher >>

-- Olivier.jousselin (discussion) 28 mai 2015 à 09:31 (CEST)

Contenu du message retour des DO

Comme précisé un peu plus haut, ce message retour (banque de DO -> banque d'accueil, voire DO -> banque de DO) est hors périmètre FBF/CFONB. Toutefois, nous considérons qu'il est utile à plus d'un titre, ne serait-ce que d'un point de vue protocolaire. Nous allons donc l'inclure dans le périmètre d'Aigue-Marine et le définir par nous-mêmes.

Pour des raisons de cohérence et de respect des principes de SEPAmail, il devra inclure les informations du message aller -- le flux 4 donc. Quelles informations supplémentaires devra-t-il contenir ? En première approche, je vois :

• un statut de la demande de modification : acceptée ou rejetée
• en cas de rejet, une explication
• en cas d'acceptation, une date de prise en compte

D'autres choses ? Serait-ce pertinent de coupler ceci avec une modification de mandat SDD ?

Pour anticiper certaines remarques, je répète que je suis bien conscient que ce 4ème message n'est pas obligatoire au sens de la FBF. Mais il me semble dommageable pour SEPAmail d'avoir un message sans réponse, et je ne pense pas que la charge supplémentaire soit énorme, ni en spécification ni en développement.

-- Olivier.jousselin (discussion) 3 juin 2015 à 10:48 (CEST)

Rien n'est figé sur ce point côté FBF/CFONB, il n'est pas exclut que cet éventuel nouveau message puisse aussi être normalisé par le CFONB. Que ce soit SEPAmail ou le CFONB qui le normalise, l'important est de garder une cohérence d'ensemble par rapport aux autres messages. En terme de timing, avant d'envisager de le définir côté SEPAmail il serait peut être souhaitable d'attendre la décision finale côté FBF d'une part, et d'attendre que la structure des autres messages soit communiquée d'autre part.

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

Cas des banques de DO non adhérentes

Dans le cas d’une banque DO non encore adhérente, peut-être faudrait-il que la banque d’accueil mette en place une procédure « dégradée » de manière à assurer la totalité du service vis-à-vis de son client.

Hugues Leclere, SOPRA Banking 27 mai 2015 à 16:20 (CEST)

En théorie, la totalité des banques devraient être adhérentes, donc celles de DO aussi. Mais en effet, il semble judicieux de pouvoir communiquer avec les DO par d'autres canaux. Le flux 4bis du schéma FBF est à mon avis au moins une partie de la réponse...

-- Olivier.jousselin (discussion) 28 mai 2015 à 09:28 (CEST)

Le flux 4bis correspond en effet au canal qui existe aujourd'hui entre les opérateurs de mobilité bancaire comme Docapost et les émetteurs de virements / prélèvements. Il pourrait devoir subsister au moins au démarrage si toutes les banques DO ne sont pas prêtes. Marc Delesalle

Lien avec le QXBAN

Le QXBAN n’étant pas représentatif d’un seul compte, sans doute faudrait-il utiliser l’IBAN ; en effet, dans un établissement donné le migrant peut « quitter » un seul de ses n comptes

Hugues Leclere, SOPRA Banking 27 mai 2015 à 16:20 (CEST)

Le QXBAN est strictement associé à un compte et un seul. Je n'ai donc pas l'impression qu'il y ait un problème sur ce point, si ?

-- Olivier.jousselin (discussion) 28 mai 2015 à 09:26 (CEST)

Inclure le QXBAN dans ce sujet mobilité bancaire nous parait prématuré et hors de propos compte tenu des divergences interbancaires quant à sa définition et son usage.

--Noël Dumand (Société Générale) (discussion) 28 mai 2015 à 15:28 (CEST)

Néanmoins, dans ma compréhension du système le QXBAN est connu des créanciers du migrant et appartient à la banque d'origine du migrant. Changeant de banque, son QXBAN devrait devenir obsolète et être remplacé par un nouveau qui sera fourni par la banque d'accueil. Il semble utile que les créanciers soient informés du nouveau QXBAN. Ai-je manqué une étape dans mon raisonnement ?

--Karim Jouhari (Worldline) (discussion) 29 mai 2015 à 17:45 (CEST)

Effectivement, le QXBAN n'est, comme l'IBAN, pas "facilement" portable. Nous inclurons le sujet du QXBAN là où il semble pertinent, pour cette raison notamment -- sans pour autant le rendre obligatoire de façon prématurée, évidemment.

-- Olivier.jousselin (discussion) 29 mai 2015 à 20:22 (CEST)

A nouveau, compte tenu des divergences marquées entre banques sur la définition du QXBAN et son usage, nous n'envisageons pas de discuter de ce sujet dans le contexte de la mobilité bancaire. Encore moins d'évoquer une quelconque obligation d'utiliser cet identifiant spécifique à SEPAmail hors du contexte RUBIS.

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

mandat détenu par le créancier

suite à une opération réussie de mise à jour chez le créancier de la nouvelle domiciliation bancaire du client débité je m'interroge sur la validité du mandat SDD celui-ci n'étant pas signé pour le bon BIC/IBAN, a-t-on prévu un texte règlementaire donnant une continuité au mandat ? ou bien le créancier devra t il en demander un nouveau ? Dans ce cas il serait judicieux de prévoir soit une évolution derrière l'échange 5 prévu par la FBF soit de relancer l'usage de GEMME ?

--Bernard.gouraud (discussion) 27 mai 2015 à 18:30 (CEST)Bernard Gouraud

Sauf erreur il n'existe pas de texte réglementaire imposant de signer ou renouveller un mandat (même B2B) dans le cas de changement de domiciliation bancaire du client débité. Cela reste à la main des créanciers qui au final n'ont pas tous la même approche.

--Noël Dumand (Société Générale) (discussion) 28 mai 2015 à 15:28 (CEST)

Il s'agit d'un cas typique d'amendement du mandat. Au créancier de le répercuter via sa solution de gestion de mandat. Le créancier doit assurer l'historique des évolutions du mandat sans quoi il ne pourra pas prouver qu'il détient le droit d'émettre des SDD pour le migrant.

--Karim Jouhari (Worldline) (discussion) 29 mai 2015 à 17:52 (CEST)

Lien avec RUBIS

Nous faisons le lien avec RUBIS et nous demandons si Sepamail définirait un process automatique de transfert des inscriptions aux services Sepamil (RUBIS …) de la banque quittée vers la banque d’accueil. Dans le cas de RUBIS, quel impact pour les SCT issus de demandes de règlement acceptées et non encore exécutés

Hugues Leclere, SOPRA Banking 27 mai 2015 à 16:20 (CEST)

Services Complémentaires :

Voici quelques idées de services complémentaires à proposer :

Pour le Migrant : - visualisation d’un niveau donneur d’ordre - accès possible à toutes ses opérations de virement et de prélèvement en cours (données affichées : date de la dernière transaction, montant, libellé, référence de la dernière transaction) - possibilité de sélectionner tout ou partie de ses opérations - possibilité de migrer ses opérations sur « n » comptes bancaires

Pour le donneur d’ordre : - Possibilité de charger un fichier d’accusé de réception - Possibilité d’acquitter unitairement une demande de modification

Georges Deguimp Azzana Consulting

Compte tenu des délais imposés, il nous parait indispensable de se focaliser dans un premier temps sur les aspects obligatoires et réglementaires imposés avant d'imaginer pouvoir proposer d'autres services (même si ceux cités ci-dessus sont intéressants au demeurant).

--Noël Dumand (Société Générale) (discussion) 28 mai 2015 à 15:28 (CEST)

Lotissement ?

De notre point de vue, il parait important à ce stade de se focaliser sur ce qui est ou sera obligatoire au 01/01/2017 et de lotir tout le reste (utilisation de DIAMOND, extension au périmètre RUBIS, services complèmentaires).

Ainsi, il nous paraitrait plus logique de s’atteler dès le départ aux réflexions sur les sujets chronophages : - La gestion des messages allers/retours (gestion d’un séquencement éventuel ?) - La gestion des codes rejets …

Il est peut être un peu prématuré d'envisager un lotissement, mais compte tenu de l'expérience RUBIS pour aboutir à une norme comprise et partagée par tous, il nous parait indispensable de prioriser les chantiers répondants aux directives de la FBF avant de creuser tout autre sujet non prioritaire et potentiellement chronophage.

--Noël Dumand (Société Générale) (discussion) 28 mai 2015 à 15:28 (CEST)

Atteignabilité

Même si le sujet est brièvement abordé dans le document de cadrage, la question de l'atteignabilité des banques reste l'une des problèmatiques majeures de la mobilité "via SEPAmail" (à mettre en opposition à une mobilité via CSM ou même via SWIFT pourquoi pas). Seules 5 groupes bancaires (bientôt 6, puis 7) sont aujourd'hui équipées avec des socles SEPAmail. Certes le kit de mobilité pourrait être une solution mais compte tenu du nombre de banques à équiper (400), et des délais, il parait prudent et légitime de penser que cela ne peut être la seule solution. Quid des participants indirects via SEPAmail ? Une banque principale pourrait véhiculer les flux de mobilité bancaire vers des banques sous participantes (sur le même modèle que certains CSM). Techniquement cela parait envisageable, resterait une question juridique (seules les banques d'un même groupe peuvent aujourd'hui être représentées sur SEPAmail). Nous souhaitons que ce point et ses sous-jacents (routage, infrastructure) soient également étudiés.

--Noël Dumand (Société Générale) (discussion) 28 mai 2015 à 15:28 (CEST)

La mobilité bancaire dont nous parlons s'applique-t-elle aussi entre filiales de banques françaises (adhérentes SEPAmail) basées à l'étranger ? Par exemple, un client d'une banque française en Italie déménageant en Belgique mais au sein du même groupe bancaire ?

--Karim Jouhari (Worldline) (discussion) 29 mai 2015 à 18:15 (CEST)

Non le périmètre concerne une mobilité entre banques (françaises ou non) exerçant une activité de teneur de compte de paiement en France.

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

Périmètre des opérations visées

Concernant le périmètre des opérations visées, les opérations dont le migrant est le donneur d’ordre, soit en tant que créancier (s’il émet des prélèvements par exemple) soit en tant que débiteur (s’il émet des virements récurrents pour payer son loyer par exemple) sont-elles couvertes ?

--Matthieu Dambrin (Skillea) (discussion) 29 mai 2015 à 10:43 (CEST)

Le sujet est en cours de réflexion à la FBF. Il se pourrait que ceci soit hors périmètre, nous devrions en savoir plus le 4/06.

-- Olivier.jousselin (discussion) 29 mai 2015 à 20:23 (CEST)

Prélèvements récurrents / virements récurrents

Si on s’en tient aux opérations de prélèvement qui viennent prélever le compte du migrant et aux opérations de virements qui viennent créditer le compte du migrant, je vois bien la notion de prélèvement récurrent qui se distingue d'un prélèvement ponctuel (ONE-OFF), en revanche je ne vois pas bien la notion de virement "récurrent" notamment lorsqu’on se situe du côté de la banque du créancier (la banque du migrant dans notre cas). Comment celle-ci est-elle à même de distinguer un virement ponctuel d'un virement faisant partie d'une série ? Est-il envisagé d’informer tous les donneurs d’ordre ayant émis au moins un virement vers le compte bancaire du migrant sur une période donnée ?

--Matthieu Dambrin (Skillea) (discussion) 29 mai 2015 à 10:43 (CEST)

Le sujet est en cours de réflexion à la FBF. Nous en saurons davantage au plus tard le 4 juin, du moins je l'espère.

-- Olivier.jousselin (discussion) 29 mai 2015 à 20:23 (CEST)

Communication avec les banques

Est-ce sur la base du BIC 8 (ou BIC 11) fourni par le client que la banque d'accueil déduit l'adresse SEPAmail mobility de la banque d'origine ?

Comment un opérateur de mobilité tel que proposé dans aigue-marine sait-il qu'une banque est connectée à SEPAmail dans le cadre de la mobilité ?

-- Catherine Gondelmann (Explain)

Les référentiels de SEPAmail permettent de savoir exactement à quel BIC envoyer les messages, et, partant, si un BIC est ou non connecté pour un service de type mobilité.

-- Olivier.jousselin (discussion) 3 juin 2015 à 12:06 (CEST)

Formulation du modèle 4 coins

Je ne suis pas d'accord avec la formulation actuelle pour le dialogue 4 coins, dans le tableau "respect des principes de SEPAmail".

Je propose la reformulation suivante : « Les échanges respectent le modèle 4 coins, Réponse : Oui, Commentaires : les échanges respectent le modèle 4 coins même si pour certains échanges seuls 2 ou 3 acteurs peuvent être concernés. »

-- Pierre Bouleau (STET) 01 juin 2015 à 16:05 (CEST)