Document de cadrage (AIGUE-MARINE)

Cette page est abandonnée.

Elle ne fait pas partie de la norme SEPAmail, ni de la documentation officielle. Elle n'est laissée dans le Wiki qu'à titre d'historique.

Merci de ne pas la modifier, ni utiliser l'onglet discussion.

Introduction

Ce document décrit la proposition de SEPAmail.eu pour implémenter, dans le cadre de la norme SEPAmail, un système de mobilité bancaire conforme aux demandes des instances légales et réglementaires.

Il décrit quelques éléments techniques, mais surtout le projet global que SEPAmail.eu souhaite mettre en place, avec la participation de toute la communauté SEPAmail.

Schéma de base

Voici un schéma récapitulant le fonctionnement global de la mobilité bancaire :

Le schéma précédent met en évidence les différents acteurs :

• la banque d'accueil, en relation avec le client, et initiatrice du service de mobilité
• la banque d'origine, devant répondre aux sollicitations de la banque d’ac­cueil dans un délai réglementaire
• la banque du donneur d'ordres, ou plus précisément les banques des donneurs d'ordres pour un client donné
• les donneurs d'ordres liés à ce client, c’est-à-dire potentiellement toute entreprise, collectivité, organisme social ou association, émettant des virements et/ou des prélèvements
• le client qui demande le service de mobilité, c’est-à-dire potentiellement tout particulier ayant un compte dans une banque française

Pour les banques, l'ensemble du projet est ouvert à toutes les banques établies en France, (adhérentes ou non de SEPAmail aujourd'hui). Plus généralement même, il est ou­vert à tous les PSP établis en France.

Périmètre

Le projet SEPAmail-Mobilité se concentre sur l’ensemble des flux entre les acteurs ban­caires.

Cependant, compte tenu du délai court, il apparaît indispensable de faciliter les connexions entre la banque de l’émetteur et l’émetteur et pour ce faire, de faciliter la re­prise des infrastructures existantes.

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.

Création dans SEPAmail de l’application Aigue-Marine

Flux entre les acteurs bancaires

Il faut ajouter à SEPAmail une application pour gérer la cinématique décrite dans le sché­ma général ci-dessus, et définir les règles opérationnelles associées.

Cette application décrira les flux suivants :

• Flux 2 : demande des opérations
• Flux 3 : fourniture de la liste des opérations
• Flux 4 : changement de domiciliation du client

Normalisation de l'application

Nous proposons de reprendre l'application AIGUE-MARINE, pour laquelle Isilis a proposé une SMIRK et des Implementation Guidelines. Nous ferons évoluer de façon collaborative ces documents pour aboutir à une normalisation conforme au schéma décrit ici, et qui convienne à tous les acteurs.

Flux vers les émetteurs

Pour prendre en compte le flux 4bis et une normalisation à terme du flux 5, SEPAmail pro­posera un guide de mise en œuvre de ces flux. L’utilisation n’en sera que préconisée, pour faciliter l’utilisation des infrastructures déjà existantes avec les émetteurs.

Cette préconisation sera fondée :

• Sur le flux 4, flux à l’origine du flux 5
• Dans une formulation indépendante de son acheminement technique (EBICS, SWIFTNet, SEPAmail Hors SEPAmail3, email, ftp, …)

Le transport du mandat

L’application Aigue-Marine incorporera nativement le transport de fichier PDF dans tous les messages, permettant ainsi, entre tous les acteurs, l’achemine­ment du mandat signé par le client.

Flux complémentaires

Forts de notre expérience avec RUBIS et GEMME (2 applications de SEPAmail), nous esti­mons nécessaire de proposer la normalisation de quelques flux complémentaires :

• Flux 6, non dans le périmètre natif du schéma général mais tout à fait dans l’es­prit de la messagerie SEPAmail
• Les flux de réponses pour les flux 4 et 5. En effet, il est impératif de prévoir dès le démarrage ces flux car l’absence de « bouclage » dans la cinématique pro­posée créera forcément des difficultés dans la gestion des messages.

Création de trois écosystèmes

Quasiment toutes les banques devront mettre en place les 3 fonctions : banque d’accueil, banque d’origine, banque de l’émetteur.

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.

Bien évidemment, la plupart des banques auront les trois rôles, et devront implémenter l'ensemble des messages, mais cette séparation permet de scinder les plates-formes techniques pour chaque fonction, sans pour autant empêcher ni complexifier l’implémen­tation pour une banque qui souhaite une plate-forme unique.

Une telle souplesse rend possible par exemple :

• de mettre en place en interne la fonction banque d’accueil, fonction avec des interactions fortes avec la banque à distance
• de sous-traiter totalement la fonction « banque de l’émetteur » à un acteur ayant déjà des connexions techniques avec des émetteurs
• de choisir un « clé en main » du marché pour la fonction « banque d’ori­gine ».

Accueil de tous les établissements bancaires

À ce jour, SEPAmail.eu a défini une procédure d’adhésion, ouverte à tous les PSP, dans le cadre d‘une utilisation de l’ensemble des services offerts par SEPAmail : RUBIS, GEMME, DIAMOND, …

Bien entendu, cette adhésion est possible pour tout PSP, mais ses coûts sont à la hauteur des enjeux de tous les services potentiels de SEPAmail.

Pour que le service de mobilité de SEPAmail soit accessible à tous les acteurs bancaires français, nous proposons de spécialiser des règles d'adhésion uniquement à ce service : le contrat d'adhésion « mobilité » sera une version simplifiée du contrat d’adhésion « tous services » actuels. Il sera soumis à une tarification spécifique, compte tenu de sa restriction au seul service de mobilité.

Mobilisation de tous les acteurs

Un projet de cette ampleur ne peut réussir qu’au travers de la mobilisation des tous les acteurs, directs mais aussi indirects, c’est-à-dire les prestataires des banques et des émetteurs.

Pour concrétiser et entretenir cette mobilisation, SEPAmail.eu va mettre en place diffé­rents outils techniques et organisationnels, détaillés ici.

Chef de projet dédié

Un chef de projet connaissant bien le projet et la norme SEPAmail, ainsi que l’organisation de projet, sera en charge du projet jusqu'à la mise en place finale. Il pourra répondre aux différentes sollicitations et rapportera directement au Directeur Général de SEPAmail.eu.

Partage des travaux

Dans la lignée de l’organisation de SEPAmail, les travaux de normalisation seront publiés sous licence Creative Commons et mis à disposition sur le Wiki de SEPAmail, comme toute la norme SEPAmail, pour recevoir les commentaires de tous les acteurs. Les travaux de développement seront mis à disposition sur un référentiel adapté, également sous li­cence libre.

Dans tous les cas, nous observerons une transparence complète quant à la norme bien sûr, mais aussi quant aux spécifications des développements que nous réaliserons.

Statut de « partenaire de mobilité »

Un statut de « partenaire mobilité » sera défini et permettra aux acteurs techniques ou opérationnels existants (ceux qui n’ont pas le statut de PSP) de participer aux travaux et d’y contribuer pour apporter leur expérience.

Une inscription minimum sera demandée pour accéder aux ressources techniques : mur de rebond et banque de référence. Ceci doit permettre à ces entités de préparer la conception d’offres pour les banques et de paralléliser les développements.

Cette organisation a pour but d’aider des sociétés non PSP à proposer des solutions « sur étagères » aux banques souhaitant mutualiser leurs investissements sur ces services.

Kit mobilité

Pour faciliter l'envoi et la réception de messages de mobilité par toutes les banques, un kit mobilité sera disponible à partir de fin 2015.

Ce kit, fondé notamment sur une extension du client de messagerie Thunderbird et un token cryptographique, permettra à n'importe quel PSP de devenir opérationnel en 3 étapes simples :

• souscrire une « adhésion mobilité », en indiquant l'adresse de leur serveur de mail (MTA)
• télécharger les logiciels du kit, les installer, de préférence sur un poste dédié, et les configurer, ainsi que le MTA, selon la procédure fournie
• installer le token cryptographique et l'associer au logiciel.

Ceci fait, des messages des écosystèmes mobility pourront être envoyés et reçus à partir de ce poste.

Ce kit sera complètement opérationnel, mais simple, et sa maintenance ne sera assurée que pendant une durée limitée, le temps que des offres commerciales au moins équivalentes soient disponibles. En tout état de cause, nous veillerons à ne pas empiéter sur les offres du marché. De plus, notre transparence sur nos spécifications facilitera l'émergence d'offres plus complètes et plus intégrées.

Club mobilité

Un « club mobilité » sera créé, auquel les adhérents, partenaires et autres acteurs concernés (membres du CCSF, CFONB, …) pourront librement participer, les réunions se tenant sur une base mensuelle :

• Revue de l’avancement des travaux
• Commentaires, interrogations et avis des acteurs
• Possibilité de groupes de travail dédiés le cas échéant

Mur de rebond

Sur une organisation similaire à celle utilisée pour RUBIS, un outil de tests « mur de mobi­lité » sera mis à disposition des adhérents et partenaires. Le guide de recette associé sera formalisé et mis à disposition sans conditions préalables (voir partage des travaux).

Ce mur de rebond doit permettre à tous les acteurs, y compris les émetteurs voulant mettre en place les flux 5, de tester facilement l'ensemble de l'application.

Une extension de ce mur permettra le jeu du guide de recette pour offrir une certification aux adhérents et prestataires techniques.

Banque Virtuelle de Mobilité

En complément du mur de rebond, SEPAmail.eu mettra à disposition une plate-forme de re­cette « Banque Virtuelle de Mobilité », offrant les trois fonctions « banque de l’émetteur », « banque d’origine » et « banque d’accueil ». En d'autres termes, ce sera une messagerie SEPAmail, capable de recevoir et d'émettre tous les messages des écosystèmes mobility, dans un cadre SEPAmail, avec des certificats de recette.

Cette plate-forme apparaîtra sous la forme d'une banque de test, qui disposera de certificats dûment enregistrés auprès du scheme pour pouvoir effectivement tester toutes les couches de la communication.

Elle inclura une liste de « clients » virtuels, correspondant à la plupart des cas de fonctionnement nominal de la mobilité.

Elle sera complétée par des outils simples permettant de générer une sollicitation d’émission de flux par cette banque virtuelle.

Elle sera réalisée sous forme de composants modulaires, qui seront mis en open-source pour que chacun puisse les reprendre, les enrichir, les adapter à ses besoins propres si nécessaire. Là encore, le rôle de la communauté sera important.

Calendrier

Dans l'état actuel des choses, le calendrier prévisionnel est le suivant :