Standards talk:IG AigueMarine AccountSwitchingInformationServiceNotify
Bonjour,
Nous souhaitons que la mention "obligatoirement" soit supprimée de la phrase ci-après tant que les différentes instances de SEPAmail.eu n'auront pas statué sur le caractère oubligatoire ou non de ce flux.
Il intervient "obligatoirement" en réponse à un message SwitchingForward envoyé par la BA.
Noël Dumand SOCIETE GENERALE
Comme cela a été dit en réunion, l'approche de SEPAmail est de rendre ce flux obligatoire, et il est donc proposé sous cette forme dans la version actuelle de l'IG. Lorsque le Club AM aura terminé ses travaux, il appartiendra effectivement aux instances de SEPAmail.eu (Comité Normes notamment) de valider ou non ce que nous lui soumettrons.
Olivier.jousselin (discussion) 16 novembre 2015 à 12:27 (CET)
De notre point de vue il est nécessaire de déterminer l’apport fonctionnel de ce message par rapport aux accusés de réception technique déjà existant.
Par exemple ce message peut permettre aux donneurs d’ordre de confirmer la prise en compte effective des nouvelles coordonnées bancaires. Dans ce cas, ce message doit être optionnel car certains donneurs d’ordre ont déjà leurs propres canaux de communication avec leurs clients (site internet, courrier, mails…).
Si toutefois vous souhaitiez quand même implémenter ce flux, voici 2 remarques sur la SMIRK : 1 : Il est nécessaire de positionner le flux 9 sur le schéma du CFONB ou sur un schéma similaire. 2 : Les délais de réponse des différents acteurs doivent tous faire mention de « au plus tard 10 jours ouvrables ».
Georges Deguimp Azzana Consulting
L'apport fonctionnel a été discuté en réunion, mais a en effet sans doute besoin d'être précisé ici. Le cas indiqué ici est exact mais n'est pas le seul...
Ceci dit, SEPAmail ne peut absolument pas rendre obligatoire le flux 8 (Émetteur -> BE). C'est bien du flux 9 (BE -> BA) qu'il s'agit ici.
Et il est effectivement sur un schéma très voisin de celui du CFONB, comme indiqué dans le texte (et comme on le voit dans les documents).
Olivier.jousselin (discussion) 16 novembre 2015 à 15:17 (CET)
J'ai ajouté des éléments sur les apports fonctionnels.
Olivier.jousselin (discussion) 16 novembre 2015 à 17:24 (CET)
Remarques de CA
Si ce flux 9 doit être mis en place pour répondre au principe de fonctionnement de la messagerie SEPAmail (réponse fonctionnelle positive ou négative pour chaque flux reçu), il doit être produit systématiquement par tous les établissements émetteurs. Il appartient ensuite à l’établissement d’arrivée de décider de l’exploiter ou non. A noter qu’a minima, l’établissement d’arrivée doit prévoir de recevoir ce flux dans ses traitements et de le mettre de côté s’il ne souhaite pas l’utiliser.
Ce flux 9 doit se limiter à rendre compte du traitement du flux 4 (AccoutSwitchingInformationServiceForward) par l’établissement émetteur : traitement du flux uniquement entre 2 acteurs bancaires utilisateurs de la messagerie SEPAmail (établissement émetteur et établissement d’arrivée).
- Dans sa forme actuelle, il ne peut être utilisé pour rendre compte du traitement du changement de domiciliation par l’émetteur et nous suggérons de revoir le texte de la SMIRK afin de limiter son usage uniquement au retour de la banque de l’émetteur (en réponse au flux 4). Il est d’ailleurs peu probable que les émetteurs indiquent à leur établissement bancaire s’ils ont été en mesure de prendre en compte ou non le changement de domiciliation puisque la loi les oblige à communiquer directement avec leurs clients sur la prise en compte de leurs changements de domiciliation.
- Si toutefois à plus long terme, il fallait envisager d’informer l’établissement d’arrivée sur le traitement effectué par l’émetteur sur les changements de domiciliation qui lui ont été adressés, il faudrait faire évoluer le format de ce message, pour prendre en compte des cas complexes (plusieurs contrats entre le même client et le même émetteur, notamment).
Rappel remarques SG
Dans la pratique, et même pour la version simplifiée du flux 9, nous ne voyons toujours pas comme être conclusif sur le sujet.
Comme indiqué ci-dessus, la version simplifiée est donc décrite de la façon suivante :
Ce cas se réduit donc à deux cas d'usage :
> positif : message transmis à l'émetteur > négatif : message non transmis, pour une raison à préciser, par exemple - émetteur inconnu - émetteur non joignable
Je rappelle le périmètre des émetteurs concernés
- Emetteurs de virements récurrents (2 dans les 13 derniers mois) SEPA ou internationaux
- Emetteurs de prélèvements SEPA
Les émetteurs sont "tout marché", c'est à dire : - des particuliers - des associations - des pros - des entreprises de toute taille - le secteur public
> Avec des émetteur français rattachés à des banques françaises (flux 5) (non soumis à l'obligation des 10j) > Avec des émetteurs non français rattachés à des banques françaises (flux non apparent sur le schéma mais prévu, et sans l'obligation des 10j pour ces émetteurs) > Avec des émetteurs français rattachés à des banques non françaises (obligation des 10j pour les émetteurs, mais pas d'obligation pour les banques non françaises d'accepter le dispositif prévu par la place française) > Avec des émetteurs non français derrière des banques non françaises.
En tant que banque d'émetteurs, nous serons donc obligés d'utiliser des canaux distincts pour joindre ces différentes typologies d'émetteurs.
Notre constat est donc le suivant :
=>>> Pour un flux 9 positif (message transmis à l'émetteur) : > En tant que banque d'émetteur il faudrait : - alimenter ce flux à partir des différentes sources (canaux) utilisées pour joindre les émetteurs, à savoir des usines courriers, des flux véhiculés par télétransmission et/ou des banques à distances ou tout autre canal propre à chaque banque d'émetteur concernée.
A noter que pour les émetteurs (français ou non), rattachés à des banques non françaises (flux 4 bis), il n'y aura pas de flux 9 possible du tout. En conséquence cela implique des régles de filtrage complémentaires (de façon simplifiée, si émetteur français+banque émetteur française alors flux 9, si banque émetteur non française = pas de flux 9)
> En tant que banque d'arrivée : - Etre en capacité de recevoir le flux 9 positif reçu - Faire un rapprochement avec le flux 4 (sinon quel intéret du flux 9), et s'il n'y a pas de rapprochement pour tous les émetteurs des flux 4, que doit faire la banque d'arrivée ? relancer la banque d'émetteur ? - Quid du flux 4 bis ? on aurait donc un rapprochement du flux 4 avec le flux 9 mais pour les flux 4 bis, pas de flux 9 par nature, donc pas de rapprochement, nouvelle régle de gestion à mettre en place. - autres régles de gestion : recevoir un flux 9 c'est bien, en faire quelque chose c'est mieux. Rappel des discussions précédentes, que va faire la banque d'arrivée à réception du flux 9, en toute logique, elle pourrait prévenir le client, mais au fil de l'eau ? tel émetteur a été prévenu, tel autre non ? Et au final, les émetteurs ont certes l'obligation des 10j, mais comment les banques pourront t'elles être totalement sûres qu'ils auront bien fait les changements de domicilition bancaire, quelle est dans ce cas la pertinence de prévenir le client ?
Et si on ne prévient pas le client du tout, quel est l'intérêt du flux 9 si ce n'est une faible garantie pour la banque d'arrivée (j'ai transmis le flux 4 à la banque d'émetteur, et cette dernière l'a bien transmis aux émetteurs (flux 5), mais encore une fois pas pour tous les émetteurs (flux 4 bis) mais en aucun cas la banque d'arrivée ne pourra prouver grace a ce flux 9 que l'émetteur a bien reçu le changement de domiciliation d'une part (cf. la typologie des émetteurs concernés) et l'a traité d'autre part.
=>>> Pour un flux 9 négatif (émetteur inconnu ou non joignable) :
> En tant que banque d'émetteur, cela signifie que le flux 4 reçu adresse un émetteur qui n'apparait pas dans les bases. Concrétement, cela pourrait correspondre à un émetteur qui a lui même changé de banque, ou qui a disparu (faillite ou autre cas) dans les 13 derniers mois. Donc la banque d'émetteur peut envoyer un flux 9 vers la banque d'arrivée si elle se retrouve dans cette situation. (je n'arrive pas à trouver de cas d'usage pour le "compte inexistant" sauf une erreur dans le flux 3, donc côté banque d'origine, et auquel cas que faire ?)
> En tant que banque d'accueil, on retrouve les mêmes contraintes que celles exprimées ci-dessus. Avec un risque d'erreur d'interprétation supplémentaire non négligeable.
Si l'émetteur a changé de banque durant les 13 derniers mois, mais qu'il a continué à émettre des virements ou des prélèvements vers le client via sa nouvelle banque d'émetteurs, il ne faut pas oublier que la banque d'origine enverra toutes ces informations via le flux 3 à la banque d'arrivée, et que la banque d'arrivée va elle meme envoyer des flux 4, pour le même client et le même émetteur du coup, vers 2 banques d'émetteurs différentes (l'ancienne et la nouvelle). En tant que banque d'arrivée, à réception d'un flux 9 négatif, il ne faudrait surtout pas tirer de conclusions hatives (faux négatif en quelque sorte), car le client lui aura bien eu normalement sa mobilité des virements ou prélèvements reçus de son émetteur.
Devant ce constat et ces multiples interrogations / incohérences parfois soulevées par la mise en place éventuelle de ce flux 9, nous restons alignés sur notre position déjà exprimée à plusieurs reprises dans toutes les instances interbancaires ayant traité du même sujet : il y a trop de variables à prendre en compte, en tant que banque d'émetteur et en tant que banque d'arrivée, avec des coûts informatiques conséquents, pour un résultat au final non garanti dans les faits pour un grand nombre de cas.
L'acquittement technique et des échanges bilatéraux (non automatisés) entre banque d'arrivée et banque d'émetteurs permettront de toute façon de parvenir aux mêmes résultats.
Enfin le législateur reconnait implicitement que certains émetteurs puissent ne pas avoir été prévenus ou n'aient pas appliqué les demandes de changements de domiciliation transmises par la mention dans l'article L312-1-7 du paragraphe IV (ce qui correspond au flux 6) :
1) :IV.-En cas de clôture du compte dans l'établissement de départ, celui-ci informe gratuitement, durant une période de treize mois à compter de la date de clôture du compte, par tout moyen approprié et dans un délai de trois jours ouvrés, le titulaire du compte clôturé ayant bénéficié du service d'aide à la mobilité défini au III : 1° De la présentation de toute opération de virement ou prélèvement sur compte clos. Cette information est faite au moins une fois par émetteur impliqué ;
PS : je n'aborderai pas la version non simplifiée du flux 9, mais il va de soit que ce sera encore plus coûteux et pas forcément plus efficace, toujours compte tenu des multiples variables à prendre en compte.
Pour un opérateur de mobilité bancaire, tout élément permettant d’affiner les causes d’échec d’un changement de domiciliation bancaire est bienvenu. Le flux 4 R constitue à ce titre un apport utile. En effet, si le retour OK ne signifie pas que le changement de domiciliation bancaire a été pris en compte par l’émetteur, il signifie tout de même que l’émetteur existe chez la banque d’émetteur et que cette dernière a bel et bien reçu le flux 4, converti celui-ci en flux 5 avant de le transmettre à l’émetteur. Cette information aide au diagnostic en cas de non aboutissement du changement de domiciliation bancaire (signalé par exemple par le consommateur). Dans ce cas en effet, les actions en vue de remédier à cette défaillance se tourneront vers l’émetteur. En conclusion, nous considérons que le flux 4 R ne doit pas être considéré comme une garantie de bonne fin mais comme un élément contribuant utilement à l’atteinte d’un haut niveau de fiabilité de la mobilité bancaire par le canal interbancaire. Georges Kammermann Isilis