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 SEPAmailmessagerie bancaire sécurisée.". 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 SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail., 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.euSociété gestionnaire de la norme et du scheme SEPAmail, 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 SEPAmailmessagerie bancaire sécurisée.
  • pour être sûr que les banques aient quelque chose à disposition à la date butoir. SEPAmail.euSociété gestionnaire de la norme et du scheme SEPAmail 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.euSociété gestionnaire de la norme et du scheme SEPAmail 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 SEPAmailmessagerie bancaire sécurisée. 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érentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée. ? (voir point atteignabilité dans les commentaires de la SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail. 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 PSPPrestataire de Service de Paiement, banque ou autre) minimale.


Justement, la question se pose pour un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). qui souhaiterait proposer l'accès à SEPAmailmessagerie bancaire sécurisée. à un participant indirect ne faisant pas parti du même groupe de PSPPrestataire de Service de Paiement, banque ou autre.

--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 SEPAmailmessagerie bancaire sécurisée., 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 SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail. AIGUE-MARINEApplication SEPAmail autour de la mobilité bancaire 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éancierle créancier est une entité économique (secteur privé, associatif ou institutionnel), soit disposant d'un ICS au niveau SEPA, soit inscrit comme créancier SEPAmail..

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 SEPAmailmessagerie bancaire sécurisée. 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 SDDSEPA Direct Debit ou prélèvement SEPA est un prélèvement exécuté dans la zone SEPA en euros, reposant notamment sur le principe d’un mandat unique délivré par le débiteur au créancier (contrairement au double mandat français). « 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'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail

  • 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 SEPAmailmessagerie bancaire sécurisée. 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’applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail 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èmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail. 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 SEPAmailmessagerie bancaire sécurisée. 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 PSPPrestataire de Service de Paiement, banque ou autre/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 RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail) et DIAMONDApplication SEPAmail permettant la vérification d'un IBAN et des données associées, acronyme de Direct Identity control for Account Management ON Demand, 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 DIAMONDApplication SEPAmail permettant la vérification d'un IBAN et des données associées, acronyme de Direct Identity control for Account Management ON Demand.

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 IBANInternational Bank Account Number, norme ISO 13616:2003 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 (;-)…)