[PDF] [PDF] La norme Principes généraux de la norme - documentation SEPAmail

[PDF] Les relevés de comptes transmis via ces protocoles respectent la

Pour de plus amples précisions, se référer à la documentation CFONB Chaque enregistrement 2 (mouvement) peut être suivi d'un (ou plusieurs) enregistrement( s) 2 bis Prélèvements SEPA rejetés/impayés émis (par le débiteur ou sa

[PDF] EvolutionRelevéComptes V2_0 - Millennium bcp

pour les opérations de virements et de prélèvements SEPA MARS 2010 dans le relevé de compte électronique au format CFONB En effet, tant Il s'agit de l' enregistrement « mouvement » (Code 04) du format 120 caractères Légende :

[PDF] CONVENTION DEMISSION DE PRELEVEMENTS SEPA « CORE »

18 fév 2014 · vement SEPA et de la brochure CFONB « le prélèvement SEPA » qui s' appliquent ARTICLE 4 – MODALITES DE TRANSFERT ET D'EXECU-

[PDF] La norme Principes généraux de la norme - documentation SEPAmail

17 juil 2012 · identifiant dédié banque en ligne) mais la proximité du SEPA et la promesse de du processus les références qui lui permettront de traiter le mouvement de Normes Bancaires CFONB pour la définition des relevés 

[PDF] LISTE INTERBANCAIRE CODES MOTIFS DE REJET/RETOUR

17 nov 2012 · interbancaires définis par le CFONB/GUF pour la version de novembre 2012 des "schemes" de l'EPC (virement SEPA V6, prélèvement

[PDF] Guide_Parametrage_Releves_comptes_protocole_EDIpdf

Chaque enregistrement 2 (mouvement) peut être suivi d'un ou plusieurs) enregistrement(s) 2 bis (com- Code motif de rejet (voir brochure CFONB "Liste interbancave des TDN Prélèvements SEPA interentreprises rejetés/impayés

[PDF] Conseils pour lexploitation des relevés de Comptes reçus en

Chaque enregistrement 2 (mouvement) peut être suivi d'un (ou plusieurs) enregistrement(s) 2 font l'objet d'un relevé séparé le CFONB (voir zone 2b- M)

[PDF] Normes MPB CFONB - WebLine - Monte Paschi Banque

22 avr 2009 · ENREGISTREMENT MOUVEMENT 25 Montant du mouvement (cadré à droite , complété à gauche par des communiqué sous pli séparé

[PDF] cfonb format

[PDF] cfonb "codes opérations interbancaires"

[PDF] code rejet 99 hsbc

[PDF] format cfonb relevé bancaire

[PDF] si c'est possible je souhaiterai

[PDF] liste interbancaire des codes motif de rejets

[PDF] est ce que c'est possible de m'envoyer

[PDF] portail authentification cerbere

[PDF] portail cerbere vtc

[PDF] relevé de navigation

[PDF] spls

[PDF] acces portail cerbere

[PDF] registre des vtc

[PDF] avantage et inconvenient educateur sportif

[PDF] moniteur educateur avantage et inconvenient

PDF générés en utilisant léatelier en source ouvert " mwlib ». Voir http://code.pediapress.com/ pour plus déinformations.PDF generated at: Thu, 19 Jul 2012 10:22:29 UTCSEPAmailNorme 1202

Norme SEPAmaiI 1202

Cette norme est mise à disposition selon les termes de la licence Creative Commons Paternité - Partage à

l'Identique 3.0 non transposé.

Auteurs

Lise MAHAUT —Crédit Mutuel CIC

Manfred OLM - DECIBI pour BPCE

Eric MEVEL—Euro INFORMATION pour Crédit Mutuel CIC Olivier JOUSSELIN — SOLAGO pour BPCE Jean-Philippe NAUDOT - Euro INFORMATION pour Crédit Eric VERONNEAU - BPCE

Mutuel CIC

Cyril VIGNET - BPCE

Contributeurs

Marc RAINTEAU

- Crédit Mutuel CIC Rui VAZ - BNPPARIBAS

Jean-Louis GLORIAN

- Crédit Mutuel CIC Thierry PONS - BNPPARIBAS

Tony CROIZER— Euro INFORMATION

Bertrand SANDOZ— BNPPARIBAS

Marc NORLAIN

- AriadNext Hervé NEUMAN - SOCIETE GENERALE

Tristan DENMAT

- AriadNext Frédérique FORTIN - SOCIETET GENERALE

Guillaume DESPAGNE

- AriadNext Théa SIEMONS -Groupe CREDIT AGRICOLE

Nicolas MUHADRI

- STREAM MIND Frédéric ALBOUY - BPCE

Maxime TOHIER

- STREAM MIND Lionel CHEMLA - BPCE

Jean-François BAUDIN

- TURBO S.A Nicolas BARTHELEMY - NATIXIS PAIEMENTS

Chloé BOIVIN

- NATIXIS PAIEMENTS

Approuvée par le Comité de coordination

Christine GUILLAUMET

- Représentante BNPPARIBAS

Animatrice Comité Expérimentation

Lise MAHAUT —Animatrice Comité Normes

Arnaud-Louis CHEVALLIER

- Représentant SOCIETE

GEN ERALE

Luc LAFFON

- Représentant Groupe CREDIT

AGRICOLE

Laurent MARECHAL

- co-animateur Groupe de travail

Sécurité

Nicolas MUHADRI —Animateur Groupe de travail

Architecture

Marc RAINTEAU

- Représentant Crédit Mutuel CIC

Régis ROCROY

- co-animateur Groupe de travail

Sécurité

Cyril BPCE

Creative Commons

Creative Commons License Deed

Paternité - Partage dans les Mêmes Conditions 3.0 non transposé (CC BY-SA 3.0)

Avertissement

Le Résumé Explicatif n'est pas une licence mais simplement une source pratique pour faciliter la

compréhension de la version complète de la licence (le Code Juridique) - il exprime en termes courants

les principales notions juridiques de la licence. Envisagez-le comme une interface conviviale et simplifiée

pour lire la licence. Ce résumé explicatif n'a pas de valeur juridique, son contenu n'apparaît pas sous

cette forme dans le contrat.

Creative Commons n'est pas un cabinet d'avocats et ne délivre pas de conseils juridiques. La distribution,

l'affichage ou l'établissement d'un lien vers ce résumé explicatif ne constitue pas une relation juridique

entre vous et Creative Commons. Ceci est le résumé explicatif "lisible par les humains" du Code Juridique (la version intégrale de la licence).

Avertissement

Vous êtes libre de :

Selon les conditions suivantes :

partager - reproduire, distribuer et communiquer l'oeuvre remixer - adapter l'oeuvre d'utiliser cette oeuvre à des fins commerciales que signifie "Attribuer cette oeuvre" ? La page web d'où vous venez contenait des métadonnées de licence incluses, y compris la manière dont l'auteur souhaite se voir attribuer en cas de réutilisation. Vous pouvez utiliser le présent code HTML pour citer l'oeuvre. En procédant ainsi, vous incorporerez aussi des métadonnées sur votre page web afin que d'autres puissent ainsi retrouver l'oeuvre originale. Attribution - Vous devez attribuer l'oeuvre de la manière indiquée par l'auteur de l'oeuvre ou le titulaire des droits (mais pas d'une manière qui suggérerait qu'ils vous approuvent, vous ou votre utilisation de l'oeuvre). Partage dans les Mêmes Conditions - Si vous modifiez, transformez ou adaptez cette oeuvre, vous n'avez le droit de distribuer votre création

que sous une licence identique ou similaire à celle-ci. Page 1 of 2Creative Commons — Paternité - Partage dans les Mêmes Conditions 3.0 non transpo

comprenant bien que :

Remarque - A chaque réutilisation ou distribution de cette oeuvre, vous devez faire apparaître

clairement au public la licence selon laquelle elle est mise à disposition. La meilleure manière de

l'indiquer est un lien vers cette page web. • Que signifie "les conditions peuvent être levées" ?

Les licences CC prévoient qu'un titulaire de droits peut vouloir lever l'application d'une condition

spécifique.

En apprendre plus.

Que signifie "domaine public" ?

Une oeuvre est dans le domaine public quand elle est libre d'utilisation par quiconque pour tout usage

sans restriction de droit d'auteur.

En apprendre plus.

Que signifie "exceptions et limitations aux droits exclusifs" ?

Toutes les juridictions autorisent certaines utilisations limitées d'oeuvres couvertes par le droit d'auteur et

droit voisin sans autorisation préalable. Les licences CC n'affectent pas les droits des utilisateurs des

oeuvres sous licences Creative Commons en vertu de ces limitations et exceptions, dans la mesure où

elles sont applicables.

En apprendre plus.

Que sont les "droits moraux" ?

En plus du droit des titulaires de droits de demander le retrait de leur nom de l'oeuvre quand elle est

utilisée dans une Oeuvre Collective ou Dérivée qu'ils n'approuvent pas, les lois sur le droit d'auteur et le

droit voisin accordent dans la plupart des juridictions du monde (avec l'exception notable des États-Unis

sauf dans certains états dans des circonstances très limitées) aux créateurs des "droits moraux" dont

l'atteinte peut donner lieu à réparation si une oeuvre dérivée représente un "traitement outrageant" de

l'œuvre du titulaire.

En apprendre plus.

Que sont les "droits à l'image" ?

Le droit à l'image autorise les personnes à contrôler la manière dont leur voix, image ou apparence est

utilisée en public à des fins commerciales ou non. Si une oeuvre sous licence CC inclut la voix ou l'image

de toute autre personne que le titulaire des droits, il est possible que l'utilisateur de l'oeuvre doive

demander la permission de ces personnes avant d'utiliser l'oeuvre à des fins commerciales ou non. Renonciation - N'importe laquelle des conditions ci-dessus peut être

levée si vous avez l'autorisation du titulaire de droits. Domaine Public - Là où l'oeuvre ou un quelconque de ses éléments est dans le domaine public selon le droit applicable, ce statut n'est en aucune façon affecté par la licence. Autres droits - Les droits suivants ne sont en aucune manière affectés par la licence : Vos prérogatives issues des exceptions et limitations aux droits exclusifs ou fair use;

Les droits moraux de l'auteur;

Droits qu'autrui peut avoir soit sur l'oeuvre elle-même soit sur la façon dont elle est utilisée, comme le droit à l'image ou les droits à

Page 2 of 2Creative Commons — Paternité - Partage dans les Mêmes Conditions 3.0 non transpo...

ContenusArticlesPrésentation générale1La messagerie2Présentation et principes2Les mécanismes d'échange4Les mécanismes d'identification9Standards:Spécification de l'échange des enveloppes SEPAmail13La vision métier18La norme20La norme20Standards:SMIRK MIS110121Standards:IG missive31Missive de service36Standards:IG missive returnCodes37Standards:SMIRK MES110238Standards:IG message41Standards:SMIRK APP110344Standards:SMIRK REF110447Standards:IG General rules50L'application RUBIS (validée)52RUBIS52Les principes généraux (RUBIS)52Les avantages pour le client (RUBIS)53Cas d'usage (RUBIS)54La gestion des flux (RUBIS)58Les normes utilisées par RUBIS62Le lettrage des virements (RUBIS)63Standards:Les r"gles métier (RUBIS)64Le récapitulatif des messages (RUBIS)66Standards:IG payment.activation67Standards:IG Rubis ActivationRequest67Standards:IG Rubis ActivationReport74

L'application GEMME (validée)82GEMME82Les principes généraux (GEMME)83Cas d'usages (GEMME)83La problématique des flux autour du prél"vement85La gestion des flux (GEMME)86Les normes utilisées (GEMME)87Le récapitulatif des messages (GEMME)88Standards:Les r"gles métier (GEMME)89Standards:IG direct.debit93Standards:IG Gemme MandateAcceptanceReport94Standards:IG Gemme MandateInitiationRequest100Standards:IG Gemme Prenotification107Standards:IG Gemme RequestForCopy110La sécurité114Principes de sécurité114Charte de l'adhérent115Standards:SMIRK CRY1211118Le protocole SAPPHIRE (en discussion)121SAPPHIRE121Les principes généraux (SAPPhire)121Le récapitulatif des messages (SAPPhire)122L'application AGATE (en discussion)123AGATE123Les principes généraux (AGATE)123Les avantages pour le client (AGATE)123Cas d'usage (AGATE)124La gestion des flux (AGATE)124Les normes utilisées par AGATE124L'application DIAMOND (en discussion)125DIAMOND125Les principes généraux (DIAMOND)125Algorithme de pertinence des identités129Le récapitulatif des messages (DIAMOND)132

Standards:IG Diamond VerificationRequest132Standards:IG Diamond VerificationReport136L'application IOLITE (en discussion)140IOLITE140Les principes généraux (IOLITE)140Les avantages pour le client (IOLITE)141Cas d'usage (IOLITE)141Les normes utilisées (IOLITE)141L'application JADE (en discussion)142JADE142Les principes généraux (JADE)142Les avantages pour le client (JADE)143Cas d'usage (JADE)143La gestion des flux (JADE)144Les normes utilisées (JADE)145L'application JASPE (en discussion)146JASPE146Les principes généraux (JASPE)146Les avantages pour le client (JASPE)147Cas d'usage (JASPE)147La gestion des flux (JASPE)148Les normes utilisées par JASPE150RéférencesSources et contributeurs de léarticle151Source des images, licences et contributeurs153Licence des articlesLicence154

Présentation générale

1

Présentation généraleSEPAmail est un service de messagerie sécurisée pour l'ensemble des entités économiques européennes.SEPAmail utilise des flux XML sécurisés utilisant le BIC et léIBAN comme identifiant de référence.

En valorisant Internet et les normes du W3C, le réseau SEPAmail permet, à coût réduit, la réalisation d

échanges

complexes entre les clients des banques à un niveau mondial.Ce nouveau réseau interbancaire se veut une contribution de léindustrie bancaire à léagenda de Lisbonne et Europe2020 en facilitant les échanges dématérialisés entre les entités économiques.

Historique

SEPAmail est un projet d

innovation démarré en 2008 dans le but de proposer une messagerie interbancaire sécurisée

principalement pour une utilisation pour des documents non comptables autour des paiements (factures, mandats,

devis, avis,...)Ce concept a été décliné techniquement et une série de messages structurés pour les flux autour des prélèvements aété définie. Sur la base de ce concept un partenariat a été signé avec SFR pour la mise en oeuvre déun pilote sur fluxréel.

Pré-requisPour comprendre la documentation présente dans ce Wiki, un certain nombre de notions doivent être connues, voiremaîtrisées. Voici une liste de ce qui est supposé connu :

••avant tout, le fonctionnement d'un wiki : comment il marche, comment interagir avec ...

••le fonctionnement du courrier électronique : sa structure (RFC 822 et suivants, ainsi que ceux relatifs à S/MIME),son mode d'acheminement (de MTA à MTA), les erreurs protocolaires pouvant survenir ...

••le fonctionnement de DNS•de bonnes notions de cryptographie, en provenance par exemple du portail de la cryptologie [1] de WikipediaRéférences[1]http:/ / fr. wikipedia. org/ wiki/ Portail:Cryptologie

2La messageriePrésentation et principesLe système SEPAmail se compose :

•déun réseau interbancaire sécurisé assurant le transport de messages structurés conformément aux normespartagées par les utilisateurs de SEPAmail. Le réseau SEPAmail se déploie par léinterconnexion entre serveursconformes à la norme installés dans chaque établissement adhérent.

•de services métiers à valeur ajoutée, supportés par le système SEPAmail au travers de léutilisation déune famille demessages structurés liés à chaque service métier mis en ligne sur ce réseau.

SEPAmail décrit également les connecteurs permettant aux entreprises d'envoyer, de recevoir et de gérer des

messages - ou plus exactement, en termes SEPAmail, des missives

à travers diverses formes d'interfaces :

courriel, Web service, et même échange de fichiers.

Les espaces de confiance

Pour assurer une parfaite sécurisation des échanges et des données, SEPAmail repose sur trois espaces de confiance

complètement distincts et indépendants :•Léespace expéditeur " banque de léexpéditeur, dont la sécurité repose sur les systèmes en place : banque à distanceet authentification associée, remise de fichiers ...

••Le réseau interbancaire SEPAmail dont la sécurité repose sur :

•Un nom de domaine unique géré par le " scheme-manager » et associant léadresse BIC.sepamail.eu à la bonneadresse physique de routage de la banque possédant le BIC•Une déclaration au scheme-manager de la clé publique qui sera utilisée par S/MIME, déclaration faite enmême temps que la fourniture de léadresse IP de la banque•Léespace banque du destinataire " destinataire, dont la sécurité repose également sur les systèmes en place :banque à distance et authentification associée, remise de fichiers, ...

La structuration du syst"me

L'élément de base pour les échanges d'informations, dans SEPAmail, est la missive. Quelque soit le canal d'échange,

et quels que soient l'expéditeur et le destinataire, toutes les informations circulant dans le système sont

systématiquement structurées en missives. Il existe quatre types de missives, qui seront décrites en détail par la suite

••la missive nominale, qui sert d'acheminement à un message

••la missive d'acquittement, élément essentiellement protocolaire qui permet notamment à l'expéditeur d'être sûr dela réception des informations transmises••la missive de service, permettant d'échanger des commandes et des réponses entre des éléments actifs du système.Elle ne peut pas être utilisée en interbancaire.••la missive d'interfaçage (SMAPI), permettant à l'éditeur d'une solution SEPAmail de donner accès à des fonctionsinternes de sa plate-forme. Elle ne peut être utilisée qu'en intrabancaire.

La missive est sécurisée par des mécanismes de signature et de chiffrement. Elle peut être vue comme une

enveloppe, dont le contenu peut être quelconque, mais n'est accessible qu'au destinataire. Dans la plupart des cas, et

notamment dans le cas des missives nominales, le contenu d'une missive est un message SEPAmail. Le message

Présentation et principes

3

contient des informations relatives au service mis en jeu, la nature de ces informations variant bien entendu selon le

message. L'ensemble des éléments de SEPAmail, missives et messages, sont des fichiers XML. Tous les éléments

sont décrits par des schémas XML précis, s'appuyant, dans la mesure du possible, sur la norme et le dictionnaire de

données ISO 20022. Enfin, les missives sont échangées, entre les acteurs du système SEPAmail, par le biais d'un

mécanisme d'échange. Trois mécanismes, qui sont détaillés par ailleurs, sont actuellement définis et implémentés

dans le système :

••le courrier électronique••un web-service••un système d'échange de fichiers.Le schéma ci-dessous récapitule les éléments de structure du système SEPAmail:

Rappel S/MIME

••Le standard S/MIME repose sur le principe de chiffrement à clé publique. S/MIME permet ainsi de chiffrer lecontenu des messages mais ne chiffre pas la communication.••Les différentes parties d'un message électronique, codées selon le standard MIME, sont chacune chiffrées à l'aided'une clé de session.

••Dans chaque en-tête de partie est insérée la clé de session, chiffrée à l'aide de la clé publique du destinataire. Seulle destinataire peut ainsi ouvrir le corps du message, à l'aide de sa clé privée, ce qui assure la confidentialité etl'intégrité du message reçu.

••Par ailleurs, la signature du message est chiffrée à l'aide de la clé privée de l'expéditeur. Toute personneinterceptant la communication peut lire le contenu de la signature du message, mais cela permet de garantir audestinataire l'identité de l'expéditeur, car seul l'expéditeur est capable de chiffrer un message (avec sa clé privée)déchiffrable à l'aide de sa clé publique.

Source :

http:/ www. commentcamarche. net/ contents/ crypto/ s-mime. php3#q=smime cur=1 url=%2F

Les mécanismes d'échange

4

Les mécanismes d'échange

Cette page est » l'état de validation.Elle est en cours de révision par les instances officielles, et devrait devenir une norme définitiveprochainement.

Précisions sur les échanges

Dans son acceptation initiale, SEPAmail gère uniquement une interface interbancaire, c'est à dire celle des flux

échangés entre les banques.

Dans la pratique, il se peut qu'une banque utilise soit le protocolE SEPAmail, soit la structure SEPAmail (missive),

soit les 2 dans ses échanges avec ses propres clients (interface client). Plus généralement, une banque peut aussi

utiliser en interne (interface intrabancaire) les normes SEPAmail. Trois mécanismes d'échanges ont été définis : courriel, web service, fichier.

Parmi ces mécanismes d'échange disponibles, seul le canal courriel est obligatoire, et doit être supporté par tous les

adhérents à SEPAmail en interbancaire. Le mécanisme d'échange interbancaire fondé sur les Web services est

facultatif (même si c'est celui mis en oeuvre dans l'expérimentation).Un troisième mécanisme (fichier) a été défini pendant la phase d'expérimentation, initialement pour des besoinsintrabancaires, et ne concerne JAMAIS l'interface interbancaire. Il peut être utilisé pour l'interface client oul'interface intrabancaire.

La description donnée ici des mécanismes d'échange est essentiellement fonctionnelle, et légèrement technique. Des

spécifications techniques complètes, traitant notamment des problématiques d'adressage, sont disponibles

ici

Le courrier électroniquePrincipe

Le mécanisme d'échange fondé sur le courrier électronique a été le premier implémenté, et le système SEPAmail en

tire d'ailleurs son nom. Le principe en est simple : tous les éléments sont acheminés comme des messages mail.Le contenu du mail doit donc être conforme au RFC 3851 [1][2], le corps du mail étant obligatoirement une missiveSEPAmail, apparaissant comme un attachement au format S/MIME (RFC 5321 [3][4]).

L'expéditeur et le destinataire du mail sont obligatoirement de la forme : <écosyst"me>@.sepamail.eu<écosystème> correspond à un ensemble de messages acheminés.Quatre écosystèmes sont actuellement supportés :••direct.debit, qui est utilisé par l'application GEMME••payment.activation, qui permet la création de virements de proximité, et est utilisé par l'application RUBIS

••secure, qui permet l'échange d'éléments de sécurité (certificats ou messages) entre tous les intervenants dusystème SEPAmail

••test, destiné comme son nom l'indique à des tests de configuration et/ou de communication

bic

> est le BIC de l'expéditeur (ou du destinataire). Dans le cas d'un échange interbancaire, les deux adresses

doivent présenter ce BIC. Dans le cas d'un échange entre client et banque, l'adresse de l'expéditeur peut comporter un

IBAN au lieu du BIC.

Les mécanismes d'échange

5

Les messages doivent être, d'une part signés en utilisant le certificat de l'expéditeur, d'autre part chiffrés en utilisant

la clé publique du destinataire.Les adresses IP des serveurs de mail doivent être déposées au préalable auprès du scheme manager de SEPAmail,ainsi que les certificats utilisés pour le chiffrement des messages.

Utilisation du canal courriel

En-dehors de l'utilisation d'adresses IP fixes et pré-déclarées pour router les messages, les messages acheminés par

ce canal suivent les règles habituelles du courriel. Il est donc de la responsabilité de l'expéditeur de s'assurer de la

bonne émission des messages qu'il envoie : les notifications d'erreur ou de non-remise sont acheminées par le canal

standard entre MTA, et l'expéditeur doit prendre en charge la réexpédition éventuelle dans ce cas.constitution de l'enveloppe SEPAmail échangée dans le cas du courrier électronique ou du service WEB

Le Web servicePrincipe

Cette méthode d'échange a été initialement prévue pour permettre à un émetteur de gérer ses messages de façon plus

synchrone et plus directe que le courrier électronique.Dans l'état actuel du système, il est déployé pour les échanges entre banques (connecteur interbancaire) et pour leséchanges entre les entreprises et leurs banques (connecteur entreprise).Le principe du Web service est similaire à celui du courrier électronique : le message envoyé comporte un en-têtebasique, et un corps, respectant le format S/MIME, contenant une missive SEPAmail, signée et chiffrée.

Dans l'en-tête comme dans la missive, l'identifiant de l'expéditeur peut être une adresse mail quelconque, gérée par le

créancier, mais doit correspondre précisément au certificat utilisé pour chiffrer la missive. À défaut, la transmission

sera rejetée. Le destinataire, lui, est de la même forme que pour le canal mail : < ecosystème @BIC.sepamail.eu où le BIC est celui de la banque du créancier.

Les mécanismes d'échange

6

La connexion avec le Web service se fait en utilisant le protocole HTTP, donc sans chiffrement de la liaison, ce qui

ne pose pas de problème puisque les données elles-mêmes sont chiffrées. Les données sont transmises en utilisant le

protocole MTOM. Comme pour tous les autres mécanismes d'échange pouvant être ouverts vers l'extérieur, les

messages doivent être, d'une part signés en utilisant le certificat de l'expéditeur, d'autre part chiffrés en utilisant la clé

publique du destinataire. Tous les types de missives peuvent figurer dans un message WebService.

Ceci ouvre donc de nombreuses possibilités à l'entreprise utilisant ce canal :••envoyer des nouveaux éléments (mandats, notifications ...) à SEPAmail, en utilisant des missives nominales

••se connecter pour gérer les messages reçus (acquittements, modifications de coordonnées bancaires ...), par lebiais de missives de service

••dans des versions futures, modifier ses informations ou sa relation avec le système SEPAmail

Dans tous les cas, le Web service n'est prévu que pour fonctionner en mode "pull" : un client doit se connecter au

Web service à son initiative pour communiquer.

Utilisation du Web service

SEPAmail est un système asynchrone par architecture. De ce fait, l'acheminement des messages n'est soumis à aucun

engagement quant au temps de transit.

Dans un cadre intrabancaire (communication créancier-banque du créancier notamment), l'utilisation de la missive

de service sur le Web Service peut se substituer entièrement à la connexion SMTP. Le serveur SEPAmail joue alors

le rôle de serveur de messagerie pour ses clients, ce qui n'est pas son rôle fondamental.

Dans ce cadre, il est donc de la pleine et entière responsabilité de l'entreprise ou du créancier :••de se connecter à intervalles suffisamment fréquents pour recevoir les nouveaux messages.••de gérer correctement une éventuelle absence de réponse de la part du serveur (time-out)

••d'exploiter ces messages, étant entendu que SEPAmail n'assure qu'un rôle de stockage et non d'exploitation, saufpour les données concernant strictement le système SEPAmail (état des mandats dans la base de données interne,par exemple)••de gérer les messages présents sur le serveur, notamment en supprimant ceux qui ne sont plus utiles. Ceci a pourbut, d'une part de faciliter la gestion des messages restants en réduisant leur nombre, d'autre part de limiter laplace occupée sur les serveurs SEPAmail, dont la vocation n'est pas à proprement parler de servir des messages.Précisons que l'archivage est assuré par SEPAmail de façon interne. Le fait de supprimer un message par le biais duWeb service le rend donc inaccessible par ce même canal, mais ne le détruit pas entièrement des données deSEPAmail.

L'échange de fichiersPrincipe

Ce troisième canal d'échange est conçu pour être utilisé uniquement sur une interface interne à la banque, notamment

parce que les données sont transférées sans être chiffrées. Il est donc avant tout destiné à s'interfacer avec des

systèmes d'informations bancaires partageant tout ou partie de l'infrastructure avec celle de SEPAmail. Dans ce

canal, les éléments à acheminer sont stockés dans des fichiers, aussi bien en entrée qu'en sortie. Ceci permet donc

d'organiser des traitements en batch des données. Les fichiers seront au format XML, conformément au schéma

fourni par SEPAmail.

L'en-tête du fichier contient trois éléments, tous obligatoires :••la date et heure de constitution du fichier.

••l'identification du tiers avec lequel l'échange se déroule. Dans tous les cas, c'est un BIC. Pour un fichier entrant,c'est le BIC de l'émetteur et, pour un fichier sortant, c'est celui du destinataire.

Les mécanismes d'échange

7 ••le nombre de missives contenues dans le fichier.

Si le nombre de missives effectivement présentes après l'en-tête du fichier est différent de celui indiqué dans

l'en-tête, une erreur protocolaire sera déclenchée, aucune des missives ne sera traitée, et elles feront toutes l'objet

d'un acquittement négatif.Un fichier non conforme à la norme ou au schéma peut être purement et simplement ignoré : aucun acquittementprotocolaire, au niveau fichier, n'existe dans ce canal. Comme pour les autres canaux, l'expéditeur qui ne reçoit pasles missives d'acquittement correspondant à ses missives nominales doit prendre en charge leur réémission.

Utilisation du canal fichiers

L'organisation du canal fichiers et ses détails précis sont laissés à l'initiative de l'éditeur de solutions SEPAmail,

notamment en ce qui concerne :

••les noms des fichiers••les emplacements où ils se trouvent••la fréquence de leur intégration et/ou de leur production••l'obligation ou non de produire un fichier si aucun élément ne doit être transmis.Exemple de fonctionnement

A titre d'exemple, nous décrivons ici un mode de fonctionnement de ce canal adopté lors de l'une des

expérimentations, avec l'une des implémentations de SEPAmail :

Chaque tiers souhaitant utiliser un connecteur fichiers dispose d'un répertoire spécifique pour ses échanges de

fichiers. Ce répertoire comportera deux sous-répertoires, l'un pour les fichiers entrants et l'autre pour les fichiers

sortants, afin de séparer clairement les deux flux.

Le nom des fichiers sera de la forme <

date heure _ BIC application direction

.xml• est la date de création sous la forme aaaammjj• est l'heure de création sous la forme HHMM• est le BIC de l'émetteur ou du destinataire, selon les cas

• est l'application associée aux messages contenus dans ce fichier, par exemple gemme, rubis, test ...Elle peut également prendre la valeur ALL si le fichier contient des messages destinés à (ou provenant de)plusieurs applications.

• peut prendre deux valeurs :••in si le fichier est entrant dans SEPAmail, donc produit par un tiers••out s'il est produit par SEPAmail, donc à destination d'un tiers.

Un fichier peut contenir un nombre quelconque de missives, y compris 0. Il sera donc composé d'un en-tête, puis

d'un nombre quelconque de missives, de type Missive.Il est recommandé que la date de création figurant dans l'en-tête du fichier corresponde au nom du fichier lui-même,mais ceci n'est pas obligatoire.

Le système SEPAmail vérifiera le contenu du sous-répertoire des fichiers entrants toutes les heures, à 5 minutes

après l'heure juste. Il produira ensuite un fichier dans le répertoire des fichiers sortants, contenant toutes les missives

disponibles pour ce destinataire à ce moment. Ce fichier sera disponible chaque heure, au plus tard 35 minutes après

l'heure juste. Un fichier devra être généré à chaque heure, aussi bien par le système SEPAmail que par le tiers, et ce,

même s'il n'y a aucune missive à transmettre. Chaque partie a la responsabilité de supprimer ou d'archiver les fichiers après traitement.

SEPAmail archivera les fichiers entrants, et le tiers gèrera les fichiers sortants. En tout état de cause, un fichier datant

de plus de quatorze jours pourra être purement et simplement supprimé par SEPAmail, afin d'éviter l'engorgement du

Les mécanismes d'échange

8 système.le lien entre les enveloppes, les missives et les messages

Références[1]http:/ / www. ietf. org/ rfc/ rfc3851. txt[2]http:/ / www. ietf. org/ rfc/ rfc3851. txt[3]http:/ / www. ietf. org/ rfc/ rfc5321. txt[4]http:/ / www. ietf. org/ rfc/ rfc5321. txt

Les mécanismes d'identification

9 Les mécanismes d'identificationLe BIC et léIBAN

La problématique de l

adressage dans une messagerie repose sur le partage des identifiants. SEPAmail a apporté une

double réponse, non dans une approche technique, mais dans une vision métier :•La messagerie étant plutôt pour une sécurisation au travers de banques, le BIC est léidentifiant du »»fournisseurdéaccès SEPAmailéé

•Léidentifiant du client de la banque peut être choisi parmi plusieurs (numéro de compte, numéro de carte,identifiant dédié banque en ligne) mais la proximité du SEPA et la promesse de services autour des paiementsrendent le choix de léIBAN, paneuropéen, une évidence.

Même si le sigle

IBAN@BIC

est utilisé, il ne correspond qu

à une vue

métier et non à une vue technique. Du point de vue métier :

•Le BIC, identifiant des banques, néest pas sensible et donc circule en clair•léIBAN, identifiant des clients, est sensible et circule forcément sous un format confidentielle BIC : des contraintes pour les clientsDe plus, la première expérimentation avec SFR a mis en évidence :

••le créancier peut facilement retrouver l'IBAN à partir du numéro de compte client (BBAN en anglais), par unalgorithme connu

••le créancier ne dispose pas de moyen fiable de trouver un BIC.

Prenant en compte la réalité du terrain, anticipant aussi la pression réglementaire et projetant la norme SEPAmail

dans une utilisation client-banque, SEPAmail a proposé de ne pas obliger le client à fournir de BIC mais uniquement

un IBAN, charge à la banque SEPAmail de fournir l'enrichissement.

Une identification non figée

Dés le début de SEPAmail, les standards et la mise en oeuvre se sont attachés à ne pas solidifier l usage du BIC et de l

IBAN pour être en mesure d

utiliser d autres types d identification pouvant répondre à des besoins complémentaires à ceux du SEPA. En effet dans le SEPA, l'utilisation de l

IBAN ne couvre que les paiements par virement ou

prélèvement. De manière plus générale, toute identification de type identifiant@bic peut devenir intéressante pour SEPAmail.

Cette caractéristique, couplée à la notion précédente d'enrichissement, permet de proposer toute une gamme

d'identifiant dans SEPAmail. Identification par PAN : Primary Account Number, ou tout simplement numéro de carte bancaire

le numéro de carte est un identifiant au moins aussi, voire plus, connu que l'IBAN. Il a aussi l'avantage d'être souvent

présent avec le client, le porteur de carte , plus que le Relevé d'identité bancaire !quotesdbs_dbs13.pdfusesText_19