Outils personnels

Discussion:Document de cadrage (AIGUE-MARINE)

De documentation SEPAmail.

Le mot-clé SEPAMAIL.EU n'est pas surligné, permettant une courte explication sur ce qu'est cet élément : Ne faudrait-il pas décrire ce qu'est SEPAMAIL.EU par lien direct ? (à moins que cette description existe, mais non trouvé)

Je l'ai ajouté au glossaire. Je ne suis pas sûr qu'une présentation plus complète soit utile, si ? Olivier.jousselin (discussion) 15 mai 2015 à 11:02 (CEST)

coquille virements1

Corrigé Olivier.jousselin (discussion) 15 mai 2015 à 11:02 (CEST)

Sommaire

coquille

"Directeur Général de SEPAmail". préciser " de SEPAMAIL.EU". cf aussi remarque précédente sur ce qu'est SEPAMAIL.EU. Suggestion de rerouter vers le site institutionnel de SEPAMAIL (l'autre).

J'ai ajouté .eu à l'endroit incriminé et un lien en début de la page. Olivier.jousselin (discussion) 15 mai 2015 à 11:02 (CEST)

Prise en compte des chèques

Par rapport à la SMIRK, il est ici question des chèques. Ce point sera à éclairer.

Hugues Leclere

Comme le schéma de la FBF l'indique, le traitement des formules de chèque non débitées se résume à les porter à la connaissance du client. Aucun traitement n'est à réaliser pour ces éléments.

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

Certes concernant les chèques il ne s'agit que d'information vers les clients sur les formules chèques non débitées mais dans les flux 2 et 3, il y aura bien des données à traiter spécifiquement pour les chèques.

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

Kit de mobilité

L’existence de ce kit pourrait être un frein à l’émergence d’offres commerciales.

Hugues Leclere

Comme il est dit dans ce document, nous (SEPAmail.eu, donc) veillerons à ne pas empiéter sur les offres du marché. Ce kit sera développé pour deux raisons :

  • pour que nous puissions en disposer en interne, donc en tant que partie de notre boîte à outils SEPAmail
  • pour être sûr que les banques aient quelque chose à disposition à la date butoir. SEPAmail.eu s'engage à fournir ce kit, alors que bien évidemment nous ne pouvons pas nous engager à la place des éditeurs.

Je répète que ce kit n'a absolument pas vocation à se substituer à un produit d'éditeur : il sera uniquement fourni pour Thunderbird, ne bénéficiera d'aucune intégration, ne sera pas supporté durablement ... Il nous semble vraiment assez peu probable qu'une banque l'utilise en production, si d'autres possibilités existent.

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

  • La "Durée limitée" versus la réponse "pas durablement" pose la question suivantes

-> Qui définira la durée ? Selon quels critères ?

GT Mobilité

Est t'il bien prévu de monter un GT Mobilité Bancaire au sein de SEPAmail.eu afin d’échanger sur la mobilité bancaire dans son ensemble, afin de commenter par exemple ce document de cadrage ?

En effet, pour nous la priorité serait plus de pouvoir prouver dans les meilleurs délais que SEPAmail est adapté en termes d’atteignabilité des 400 banques dans les 18 mois, et donc d’étudier, voir de proposer rapidement un draft du contrat d’adhésion « mobilité » et un poc du Kit de mobilité tels que proposés dans la note.

Nous souhaiterions également que soit étudiée dans ce GT Mobilité les possibilités éventuelles de « sous-participant » derrière un adhérent SEPAmail ? (voir point atteignabilité dans les commentaires de la SMIRK AIGUE MARINE).

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

Nous pensons que le terme de "sous-participant" rappelle trop les paiements. Le terme de "participant" est défini dans le contrat d'adhésion ne remplit il pas le rôle souhaité ? Que faut il lui ajouter ? En d'autres termes, recevoir une demande en tant que banque d'origine d'une banque d'accueil, Participant derrière un Adhérent, garantit la confiance (meme groupe de PSP) minimale.


Justement, la question se pose pour un adhérent qui souhaiterait proposer l'accès à SEPAmail à un participant indirect ne faisant pas parti du même groupe de PSP.

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

Mandat

Les différentes instances impliquées (CCSF, FBF, CFONB) n’ont pas prévu à ce stade une dématérialisation et donc un échange du mandat de mobilité sous format électronique.

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

Pour autant, la banque d'accueil est obligée d'envoyer ce mandat à ses interlocuteurs, donc il semble pertinent de l'inclure dans tous les messages. Ceci dit, c'est la FBF qui définit le contenu exact des messages...

-- Olivier.jousselin (discussion) 29 mai 2015 à 10:45 (CEST)

Pour être précis, dans ce qui est prévu actuellement par la FBF, la banque d'accueil aura seulement à traiter le mandat puis véhiculer certaines données du mandat. Il n'y a pas d'obligation à envoyer le mandat complet (sous une forme dématérialisée ou non) ni à la banque d'origine, ni à la banque du donneur d'ordre.

--Noël Dumand (Société Générale) (discussion) 29 mai 2015 à 11:02 (CEST)

L'échange systématique du mandat pourrait permettre de limiter la fraude...

D'un point de vue technique, il pourrait être joint aux messages dans le Header des messages SEPAmail, il y a un champ Document pour cela.

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

A ce stade la FBF n'a pas demandé l'échange systématique du mandat. Sauf changement de position, le mandat ne sera donc pas échangé.

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

Flux vers les émetteurs

Serait-il possible d’intégrer à la SMIRK AIGUE-MARINE la définition des formats du flux 5 (banque <-> émetteurs) ?

Ceci permettrait d'uniformiser les échanges, quelles que soient les banques du donneur d'ordre, et faciliterait ainsi l'adoption de la solution par les créancier.

Essayons d'éviter la situation actuellement rencontrée sur Rubis, où chaque banque utilise un format différent, ce qui nuit à mon sens à l'adoption de SEPAmail par les créanciers.

-- Frédéric BORRY (Lyra Network) (discussion) 1er Juin 2015 à 21:54 (CEST)

Pour information le CFONB a pour mission de proposer une normalisation du flux 5 également.

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

  • commentaire sur "normalisation"

Point d’attention : la mission du CFONB inclue la normalisation ders flux 4 et 5.

Schéma de base

a) Il faut modifier la notion de DO. proposition "Les donneurs d'ordres liés à ce client, c’est-à-dire potentiellement toute entreprise, collectivité, organisme social ou association, incluant ainsi que les particuliers émettant des

b) Le périmètre détaillé des opérations doit être précisé. proposition : créer un § dédié dans le document de cadrage intitulé «Liste des opérations

  • Prélèvements reçus :

Externes : y c organisme de crédit conso par ex. non lié à la banque

	Exception :
		Le cas des prélèvements internes à la banque liés par exemple à des crédits sera traité ultérieurement (aspects juridiques)
		Le SDD « one off » n’est pas concerné
  • Virements récurrents reçus
  • Virements permanents émis
  • Chèques non débités sur les chéquiers utilisés sur les 13 derniers mois"

Périmètre

  • Élément de la liste à puces

"Reprise des infa existantes" : Nous comprenons la relation banque-client entreprise existante (EBICS, SWIFTNET, EDI, PORTAIL, …).

  • Élément de la liste à puces

Supprimer "ils ne sont pas directement concernés par la proposition." dans le § suivant

Les clients, quant à eux, restent en contact direct avec leurs banques (d'accueil et d'ori¬gine) par les canaux habituels (BAD, téléphone, mail...), ils ne sont pas directement concernés par la proposition.


Flux entre acteurs bancaires

Reprendre la dénomination des Flux à partir du CFONB/FBF

Normalisation de l'application

  • commentaire sur "nous ferons évoluer"

Le terme « faire évoluer » sera confirmé après l’analyse détaillée des écarts entre la version d’origine et la version tenant compte de la Loi Macron


Le transport du mandat

  • Proposition de suppression  :

Il n’est pas prioritaire de transporter le mandat de mobilité entre banques, ce concept est absolument étranger à la loi Macron. Ce qui est obligatoire avec le schéma FBF est (Cf Flux 2) que «  Le Numéro unique du dossier de mobilité et la Date de signature du mandat de mobilité » soient transportés.

  • En cible, il faudra préconiser fixer une des normes de formats PDF retenus par les instances franco-allemande notamment (PDF A3 mixte) plutôt qu’un flou peu efficace du terme générique PDF.


Flux complémentaires

  • phrase relative au flux 6 à supprimer :

Il n’est pas à normaliser (cf mission CFONB) même si c’est désormais un flux obligatoire car repris dans la loi Macron :

« 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 I : »

Si le flux est obligatoire, son automatisation est complexe dans le délai du projet et ne doit pas être une obligation pour les acteurs. Par ailleurs, L’utilisation de SEPAmail pour cet échange nécessite de conserver un contrat de service avec un client, qui a clôturé son compte !

  • Phrase relative au flux 4 et 5 supprimer "il est impératif " et le schéma

La loi n’impose pas aux banques ces flux de réponses. Si on le fait, sont-ce des acquittements de bonne réception ou des accusés de prise en compte du changement de domiciliation ? Le schéma est soit à supprimer soit à modifier (et le rendre lisible aussi (;-))

  • paragraphe "pour faciliter et les écosystèmes" : remplacer le conditionnel "pourrait"

"Toujours pour faciliter les choix d’implémentation par chaque banque en fonction de son contexte existant, l’application Aigue-Marine pourrait s'appuyer sur 3 écosystèmes complémentaires mais séparés : • accueil.mobility pour la banque d'accueil • origine.mobility pour la banque d'origine • emetteur.mobility pour la banque d'émetteur. "

Du point de vue stratégique

Les raisons suivantes plaident pour 3 écosystèmes pour des raisons de simplicité et d’efficacité : Chaque écosystème correspond à des intérêts, des processus notamment juridique, choix d’usage, marché de client , espace temps, … différents. De plus et en conséquence, une famille de message peut exister ou se développer sans l'autre. Evident pour le rôle banque de donneur d’ordre, cela est vrai aussi pour l’apparent dialogue entre banque origine et banque d’accueil. Le dialogue n’est que technique sur le schéma, en fait il est à dissocier car les traitements des données sont de natures complètement différentes : - dans un cas il faut aller extraire dans les données de la banque d'origine en appliquant des critères de sélection en cours de définition - dans l'autre il faut analyser le ou les flux renvoyés, les découper et les dispatcher.

Du point de vue technique

S’ils sont séparés, ils n’en restent pas moins sur le plan métier dépendant de messages échangés. Il faudra examiner la question des relations entre 3 rôles de banques (en réalité (1x1xnbanques), car il n’y a que 2 types de relations - type 1- 1.1banque accueil –1.2 banque origine - type2- banque accueil – banque donneur d’ordre il conviendra de valider la conception technique d’un dialogue entre Ecosystème (novation SEPAmail sur ce point)

Du point de vue métier

Les relations induites en 1.1 constituent en soi un système avec sa logique idem en 1.2. Les dépendances existent mais sont centrées sur le rôle de banque d’accueil (1.1), évidemment car la finalité métier est au service du citoyen qui est accueilli dans sa nouvelle banque.

  • Paragraphe "3 rôles"
Du point de vue stratégique

Il faut moduler cette formulation qui reflète peu la diversité des cas du marché : 1) Les grands groupes bancaires certainement

2) la majorité des petites ou banques moyennes de particulier (y compris de grands groupe) ne seront concernées que par les deux premiers rôles, n’ayant pas de clientèle ou d’appétence ni d’offre flux à vocation des grandes entreprises

3) Une minorité de PSP/banques n’auront que le rôle de banque de flux donc le rôle Emetteur/DO les intéressera exclusivement

Au-delà du rôle, les stratégies pourront varier, le rôle « Accueil » est primordial et entre dans une logique d’entrée en relation plus globale.

Du point de vue technique

Ceci nécessitera une évolution de la Norme concernant le paramétrage des infrastructures (MemberBic) et des Bic de routage (InternalRouteBIC). Cette évolution impactera également tous les écosystèmes dont RUBIS et DIAMOND, sans développement lourd, a priori.

Important : Cela rejoint le souhait et sujet identifié « Lien Infrastructure de traitement/ Participant / ServiceId (autorisation de multi infrastructures par Participant, notamment pour des Services différents) » qui restent à traiter dans le cadre d'une future édition de la Norme DIAMOND.

Accueil de tous les établissements bancaires

  • compléter les caractéristiques de la "tarification" au delà du seul "spécifique"

-> Proposition d’ajouter « et évolutives ». Des modalités d’utilisation élargies par la suite aux autres services seront à prendre en compte, sans repayer cette partie liée à la connexion de base. Il faut laisser ouvert l’accès à d’autres services par la suite (exemple Diamond pourra en cible utilement compléter et fiabiliser la procédure avant l’envoi des données mandat de mobilité en vérifiant les IBAN de la banque d’Accueil et faire gagner un temps précieux).

  • souligner l'importance du délai par ajout d'une phrase, en plus du nombre

-> proposition d'ajout de : "Il est important de démontrer que SEPAMAIL aura la capacité à mettre à disposition dans un délai très court de 18 mois le service de mobilité pour les 400 banques de la place, c’est-à-dire d’être présentée comme une solution de place."


Chef de projet dédié

  • commentaire sur "l'organisation du projet"

Un pilotage renforcé pour le déploiement jusqu'à la mise en place sera probablement nécessaire pour coordonner la mobilisation et cadencer les travaux de tous les acteurs de place : 400 banques Role 1 + 400 banques Role 2 + 400 banques Role 3 x n émetteurs > 1000 projets en moins de 1,5 an. Le cadre d’un projet de place devra certainement prioriser des phases à convergences plus courtes concernant le plus grand nombre ou des partitions pour atteindre une masse critique avec les acteurs d'importance systémique.


Banque virtuelle de mobilité

  • Modifier le schéma, il est impossible à lire en l'état et donc à commenter

Calendrier

  • précision sur échéance FBF, ligne "interbancaire"

Par exemple, on pourrait suggérer un pointeur vers un document qui serait hébergé sur le site du CFONB / Comité de Pôle N°3/ GT « Formats d’échanges service de mobilité bancaire » ?

  • ajouter une ligne sur le calendrier législatif, y compris les clauses de revoyure de consultation de la BDF/CCSF

Par exemple, on pourrait suggérer un pointeur vers un document qui serait hébergé sur le site du CCSF et indiquant de façon macro les étapes pluri-annuelles connues (vote, promulgation, rendez vous officiel, obligation 2017, décalage (;-)…)