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

Glossaire et Acteurs

• Précisions apportées sur la définition Mandat de Mobilité

"le Mandat de Mobilité prévoit également que le Client Migrant accepte que ses nouvelles coordonnées bancaires soient transmises à tout tiers concerné par le changement de domiciliation pour des paiements récurrents reçus ainsi qu’à sa Banque d’Origine."

• Précisions apportées sur l'importance de la Date de signature du Mandat dans la définition du Dossier de Mobilité

"La Date de Signature du Mandat de mobilité transmise à la Banque d'origine détermine la date de fin de collecte des informations comptabilisées par la Banque d’Origine."

--Jacques.baillon (discussion) 7 juillet 2015 à 18:17 (CEST)

Besoins des Acteurs

• précisions et complément à apporter aux 2 premiers besoins exprimés pour le client migrant

- Remplacer la phrase "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 permanents (SCT)" par "identifier ses créanciers pour les prélèvements récurrents reçus(SDD), ses émetteurs de virements récurrents reçus (SCT) ainsi que ses bénéficiaires de virements permanents émis(SCT)"

- Ajouter la précision sur le 2ème besoin Ajouter paiements "reçus"

- Apporter un 3ème besoin sur les virements permanents émis Ajouter un tiret en dessous de demander que les paiements

"- demander ou non la reconduction des virements permanents émis et ses modalités (automatique ou à la carte)"

• précisions à apporter aux 2 premiers besoins exprimés pour le client DO

- Ajouter "(SDD)" derrière débiteurs - Ajouter "(SCT)" derrière bénéficiaires

--Jacques.baillon (discussion) 7 juillet 2015 à 18:37 (CEST)

Flux retours

La mise en place de flux retours peut susciter un certain nombre de réserves, surtout si on souhaite viser la cible "simple et efficace" :

- La typologie des donneurs d'ordre (particuliers, pro, entreprises de toutes tailles, associations...) démontre que la plupart d'entre eux ne seront déjà pas en mesure de traiter un flux 5 automatisé. Les banques de DO devront proposer d'autres moyens d'échanger. De facto, les mêmes ne pourraient pas générer un flux 8. Pour une banque d'accueil, la communication vis-à-vis du client migrant serait donc contrainte : pour tel donneur d'ordre oui je peux vous indiquer que le changement de compte a été effectué, pour tel autre non je ne peux rien vous dire. Cela complexifiera les traitements en tant que banque d'accueil puisqu'en dehors des flux 3bis et 3ter, il faudrait aussi rajouter ici un flux 10 (information sur les changements de comptes effectués par les donneurs d'ordre).

- La loi impose(ra) aux donneurs d'ordre uniquement de traiter un flux 7 (quelque soit sa forme) et de prévenir directement les clients migrants de la bonne prise en compte de la mobilité bancaire effectuée. Il parait donc complexe de pouvoir leur imposer, pour les DO qui pourront déjà recevoir un flux 5, d'émettre (en plus du flux 7), un nouveau flux 8 qui couvrira, les concernant, le même besoin. De plus, nous ne sommes pas persuadés que le flux 8 puisse se substituer au flux 7 juridiquement parlant d'une part, et d'autre part, on reprendrait en tant que banque d'accueil en bout de chaîne, la responsabilité d'information du client migrant s'il y a le moindre litige ou problème technique dans la chaine (le donneur d'ordre n'arrive pas à émettre le flux 8, la banque de donneur d'ordre n'arrive pas à recevoir et intégrer le flux 8 et à générer le flux 9, la banque d'accueil n'arrive pas à recevoir et intégrer le flux 9...).

- Pour les cas techniques cités pour le flux 9, et en particulier pour DO inconnu ou impossibilité de le contacter, la question a été également soulevée côté FBF/CFONB de savoir ce qu'il conviendrait de faire dans ce cas de figure. Selon la décision prise, cela peut influencer également la réflexion sur l'existence du flux 9 pour ce cas spécifiquement (si le CFONB indique que les banques de DO et d'accueil n'auraient pas à traiter ce type de cas, ce serait un non sens de l'imposer côté SEPAmail).

De notre point de vue, imposer des flux de retour va complexifier la chaîne pour les DO, les banques de DO et les banques d'accueil et tous les tenants et aboutissants devraient être étudiés avant d'envisager une obligation quelconque (cf. l'introduction d'un flux 10 comme démontré ci-dessus). Par contre, des accusés de réception "technique" et non "fonctionnels" pourraient être utiles dans un but de traçabilité (flux 8 = simple accusé de réception du flux 5, flux 9 = suivi du flux 8 pour que la banque d'accueil ait au moins l'information sur le fait que le donneur d'ordre a bien réceptionné (mais pas forcément traité) le flux 5.

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

Je suis d'accord sur le fait que les cas "métier" doivent être définis par la FBF, de préférence. Mais en tout état de cause, il me semble fondamental qu'il y ait une communication à double sens entre la BA et la BDO.

Je vais déplacer la partie "retour DO -> BDO -> BA" vers les extensions futures, car en effet elle a des impacts juridiques et autres, et non seulement bipartites mais multi-partites.

Mon but est de faire simple, mais pas simpliste.

-- Olivier.jousselin (discussion) 1 juillet 2015 à 17:55 (CEST)

Concernant les flux 8 et 9, je partage que l'intérêt fonctionnel est lié à l'émission d'un flux 10 tel que décrit par Noël. Néanmoins,je ne suis pas certain qu'ils puissent être remplacés par des acquittements protocolaires. En effet, le flux 8 entre le DO et sa banque n'utilisera pas forcément le canal SEPAmail (toute solution de transfert de fichier sécurisé pourrait être utilisée en fonction de la relation contractuelle entre le DO et sa banque). L'acquittement de bonne réception sera ainsi conforme au protocole utilisé. En première analyse, le flux 9 ne me parait pas pouvoir correspondre à une missive d'acquittement au sens SEPAmail.

-- Lionel.chemla (discussion) 9 juillet 2015

Je suis d'accord avec l'intérêt de ce fameux flux 10, mais il est complètement en-dehors de notre périmètre. L'absence des flux 8 et/ou 9 interdit la BA de communiquer les infos au Client Migrant, alors que leur présence rend ceci possible. Cela ne crée pas d'obligation particulière pour elle, évidemment. Mais si le CM l'appelle, elle pourra au moins, dans certains cas, lui répondre en ayant davantage d'informations (un genre de flux 10 en pull, en somme...)

Quant à la partie protocolaire, n'oublions pas que le flux 4 donne obligatoirement lieu à l'émission d'une missive d'acquittement par la BDO. Mais comme le flux 5 est en effet a priori hors SEPAmail, on pourrait imaginer une sorte d'acquittement protocolaire pour lui. D'où les 3 possibilités que je propose pour le flux 9 : - immédiat si la BDO sait qu'elle ne pourra pas contacter le DO - sur réception d'un flux 8 dans le délai prévu, canal indifférent bien sûr. - en cas d'absence de réception de flux 8 dans ce délai -- soit parce que le DO n'a pas répondu, soit parce que la BDO et le DO n'ont pas mis en place un canal de réponse.

Dans ce cadre, la BA reçoit exactement un et un seul flux 9 de chaque BDO, ce qui est pratique à traiter. -- Olivier.jousselin (discussion) 9 juillet 2015 à 18:05 (CEST)

Nous sommes en phase avec la proposition de définition de flux N°9 d'information métier (d'information et non flux retour ou d'acquittement protocolaire) tel qu'exprimé par Olivier. L'exigence d'information est ainsi bouclée dans un workflow clair et efficace à notre sens. --Jacques.baillon (discussion) 9 juillet 2015 à 19:13 (CEST)

Le changement de domiciliation bancaire

• remarque de forme

Afin de relier ce paragraphe aux principes, il serait utile de revoir la forme en cohérence (pointillé ou plein selon un code clair) et de mettre les numéros dans ceux-ci et de s'assurer du séquencement avec un message 9 indiquant clairement la remise, sa date ou sa non remise pour la simple raison que le DO est inatteignable.

• principes de cohérence de la messagerie et du fonctionnel

- Il est effectivement simple et cohérent comme indiqué dans le paragraphe "Principes" qu'une information soit donnée en retour (8 ou 9) d'un flux aller d'information de changement de domiciliation bancaire (4 ou 5). De plus, la cohérence fonctionnelle pousse à rester dans l'expression des besoins décrits au "§ Besoins des acteurs" qui dans un premier temps reste basique et strictement conforme à la simple "demande de transfert ...". pour la SMIRK, je reprends texto la proposition de Noel : "flux 8 = simple accusé de réception du flux 5, flux 9 = suivi du flux 8 pour que la banque d'accueil ait au moins l'information sur le fait que le donneur d'ordre a bien réceptionné (mais pas forcément traité) le flux 5."

• proposition de modification dans la page "Extensions Ultérieures"

En conséquence, nous proposons de déplacer, de modifier et d'enrichir dans la page "Extensions Ultérieures", (merci Noel)

- 2ème phrase : l'expression du besoin du début de ce paragraphe "Le Client Migrant souhaite savoir si cet ordre de modification (plutôt cette information de demande changement de domiciliation bancaire) est pris en compte et quelle est la date d’effet de cette modification".

- 3ème phrase : le caractère nécessaire du "message de confirmation de demande de modification" en enrichissant le fonctionnement avec la suggestion à discuter suivante :

"Les limites et cas d'usage de ce dialogue seront définies ultérieurement en tenant compte :

- de la typologie des Donneurs d'Ordre (particuliers, pro, entreprises de toutes tailles, associations...) et leur capacité à traiter un flux 5 de façon automatisée et les moyens alternatifs,

- de la capacité de la Banque d'Accueil, en propre, ou via des moyens communs tel un annuaire des DO atteignables par exemple, à gérer la diversité des cas en amont des demandes ou en aval,

- de l'opportunité d'ajouter un flux 10 d'information sur les changements de comptes effectués par les donneurs d'ordre avec les dates,

- de la décision côté FBF/CFONB générale relatives à l'obligation ou non pour les banques de DO et d'Accueil de traiter ce type de cas (en particulier pour les DO inconnus ou impossibles à contacter et donc inatteignables),

- de la décision à caractère légal sur l'application du décret de la Loi Hamon à venir qui imposerait à certains DO, d'informer leur client de la prise en compte du changement de domiciliation entrainant de fait une particularité sur les cas de substitution par ces flux retours selon la typologie du DO (grands facturiers ou personne physique par exemple)."

• simple précision sur le canal

proposition de retirer la portion de phrase "- ou entre la banque d'Accueil et le DO -" car il est peu probable que ce canal évoquant un canal électronique existe ... ou alors proposition de préciser que "ce canal peut être non électronique" et parler alors comme la loi de "moyen approprié" qui laisse ouvert à des voies diverses (courrier, ...).

• simple précision sur le § remarques

proposition de compléter "Dans le cas d'un ordre de virement ou de mandat de prélèvement" car dans les deux cas, il est indispensable que le DO identifie de manière certaine le Client migrant, dont les coordonnées bancaires font l'objet d'un changement de domiciliation bancaire de compte.

--Jacques.baillon (discussion) 7 juillet 2015 à 19:24 (CEST)

Opérations récurrentes de paiement

Pour le paragraphe : Les virements émis suite à une Demande de Règlement envoyée par RUBIS sont explicitement hors du périmètre pour éviter toute transmission accidentelle de l'IBAN du Client Migrant à des interlocuteurs qui ne disposent que de son QXBAN

Nous souhaitons qu'il soit précisé : Les virements émis suite à une Demande de Règlement envoyée par RUBIS (dans le contexte P2P exclusivement (particulier à particulier), les autres cas d'utilisation de RUBIS étant par principe hors périmètre de la mobilité bancaire) sont explicitement hors du périmètre pour éviter toute transmission accidentelle de l'IBAN du Client Migrant à des interlocuteurs qui ne disposent que de son QXBAN

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

La clarification me convient, je vais l'appliquer tout de suite.

Si quelqu'un est opposé à la nouvelle formulation, merci de prolonger ce sujet.

-- Olivier.jousselin (discussion) 1 juillet 2015 à 17:56 (CEST)

Mandat de Mobilité

Concernant sa description dans le glossaire, à ma connaissance, rien n'est encore tranché.

-- Chantal Roux, BNP-Paribas 8 juillet 2015 à 22:43 (CEST)