mercredi 30 mai 2012

Vocabulaire SEPAmail : mode d'échange canonique versus flash

Le standard SEPAmail définit la structuration de l'information échangée, une organisation pour l'adressage, les séquences d'envoi/réception.
Concernant l'échange à proprement parler de l'information, la documentation cite de deux modes : le mode canonique et le mode flash.

Le mode d'échange canonique

L'adjectif canonique doit être compris dans son utilisation usuelle en mathématiques comme en informatique, c'est à dire standard ou encore naturel et instinctif.
SEPAmail est une messagerie sur internet, le mode d'échange canonique est donc celui de la messagerie électronique, c'est à dire le mécanisme d'échange proposé par le protocole SMTP.

Ce protocole met en œuvre le transfert direct de serveur à serveur et le relais si besoin. Il repose sur des protocoles tiers tels que le DNS, IP, TCP, ainsi qu'un mécanisme d'extensions du protocole qui permet notamment l'implémentation de priorité.
Enfin, il définit une liste de commandes pour permettre de dialoguer entre deux serveurs et, si besoin, différer la remise effective du message.
Cette souplesse protocolaire permet d'éviter de perdre des messages si l'un des composants automates de la messagerie n'est pas joignable.

En théorie, un message peut être distribué à son destinataire plusieurs jours après l'émission par son expéditeur. En pratique, la messagerie électronique est souvent très rapide; nous sommes habitués depuis des années à recevoir nos messages électroniques dans un temps très court (souvent plus rapide que les SMS) et c'est même cette particularité qui a fait le succès et la généralisation de la messagerie électronique.

Pour être efficientes dans la mise en œuvre du protocole SMTP, la plupart des applications dédiées à l'échange des messages (applications dites MTA comme Mail Tranfert Agent) ont mis en place un mécanisme efficace de files d'attente et c'est ce mécanisme qui permet une bonne articulation entre des applications différentes avec des contraintes souvent divergentes.

SEPAmail repose nativement sur le protocole SMTP pour la structuration de l'information (enveloppe SEPAmail = enveloppe SMTP).
SEPAmail repose aussi nativement sur le protocole SMTP pour l'échange de cette information.
Ainsi, une enveloppe SEPAmail peut transiter par les systèmes de messagerie électronique sans aucune modification de ces systèmes.
Avec le mode d'échange canonique, SEPAmail est totalement compatible avec la messagerie électronique existante.

Le mode d'échange flash

Le mode d'échange canonique ne garantit pas un temps très court pour l'échange des données.
SEPAmail définit donc, lorsqu'il est important d'échanger rapidement une enveloppe SEPAmail, un mode d'échange flash.

Celui-ci repose sur un mécanisme de services web avec une garantie de réponse courte dite flash, de l'ordre de quelques secondes, comme en monétique.

C'est ce mode d'échange qui est en cours d'expérimentation dans l'esprit  qui peut le plus peut le moins. Cette expérimentation permet de bien s'assurer des délais raisonnables bout à bout que l'on peut garantir selon la charge et l'organisation des systèmes d'information bancaires ainsi que les coûts maximums de l'infrastructure flash.

Quelques réflexions sur le mode d'échange batch

La monétique et les systèmes informatiques bancaires en général sont assez friands de traitements par lots (batch processing) à des temps programmés à l'avance (vacations) et donc non à la demande comme les traitements transactionnels sur requêtes d'un client. Certains acteurs bancaires adhérents de SEPAmail mettent en œuvre de tels traitements au sein de leur système d'information.

Ce mode d'échange n'est pas souhaité entre les adhérents pour plusieurs raisons :
  • il va à l'encontre de la logique message unitaire de SEPAmail
  • il induit une gestion centralisée et pilotée de la charge alors que SEPAmail privilégie une gestion répartie pair à pair de l'échange.
  • il repose sur un mode non transactionnel alors que SEPAmail utilise le réseau IP, transactionnel par nature

Le web service sur internet et l'illusion du temps réel

Le temps réel est à la mode dans le monde internet et le service web semble être l'objet de toutes les attentions actuelles pour mettre en œuvre du temps réel.

Cependant, derrière ce terme se cache des contradictions qui sont rarement mises en avant.

Un système temps réel est généralement défini par sa capacité à délivrer un résultat dans un temps fini et garanti, ce qui oblige toute la chaîne des procédés utilisés à être en temps réel.

Or, le réseau IP repose aujourd'hui :
  • sur des machines dont les système d'exploitation ne sont pas des systèmes temps réel
  • sur des protocoles qui ne peuvent garantir le résultat et encore moins en temps fini
Le réseau IP repose sur le paradigme du best of qui est peu compatible avec le temps réel.

On devrait donc parler de temps court au lieu de temps réel. On peut parler aussi de temps synchrone entre deux automates, dans la transaction entre le serveur et le client.

Le mode flash SEPAmail est un mode synchrone alors que le mode canonique est un mode asynchrone.

Le service web (web services) peut être vu comme une généralisation du service de page web à l'internaute.
Les protocole de la famille tcp/ip (dont http) ont permis dans un premier temps à des automates de servir de l'information sous forme de pages html à des êtres humains organisés.

Très vite, des automates programmables doués d'ubiquité se sont substitués aux internautes pour transformer, traiter l'information et la restituer autrement (opérés de façon exceptionnelles par exemple par google, yahoo, kelkoo). Les services webs sont apparus pour permettre la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

Les services webs présentent des particularités souvent oubliées et qu'il convient de bien appréhender dans le cadre de SEPAmail. Ils sont généralement en mode client/serveur avec une structure de coût essentiellement déportée sur le serveur. Ils sont plutôt gros consommateurs de ressources par rapport à d'autres implémentations. Ils sont souvent concurrentiels sur le réseau IP des transactions hommes/machines et l'articulation avec les échanges homme/machine est rarement facile à mettre en place.

L'engouement pour les architecture reposant sur des appels de procédures à distances (RPC ou Remote Procedure Call) a permis de régler quelques problématiques liés au secret de fabrication, au coûts d'intégration ou encore aux contraintes de distribution des services.

C'est dans ce contexte que SEPAmail a conçu un mode flash de cette messagerie sécurisée qui, devrait, à terme, n'être utilisé que pour les messages à forte valeur ajoutée pour les clients finaux.

vendredi 25 mai 2012

Actualité : un rapport sur les moyens de paiements qui cite SEPAmail

Le rapport l'avenir des moyens de paiements en France cite page 72 le dispositif SEPAmail dans le cadre du virement SEPA (SEPA Credit Tranfert ou SCT).
"Avec le SEPA la banque teneur de compte ne reçoit que le mandat de prélèvement (SDD) de la part du créancier. Ce créancier peut désormais également être un établissement de paiement qui gère les paiements effectués entre les consommateurs et les entreprises en dehors des circuits bancaires habituels.
Pour accompagner cette évolution, plusieurs banques de la Place ont proposé SEPAMAIL, une innovation technologique qui facilite la migration en dématérialisant les échanges entre le créancier et le débiteur. Outre le confort de gestion, ce service offre une meilleure sécurité par un contrôle des IBAN en temps réel. Pour autant il pourrait être à l'origine d'une certaine attrition des revenus bancaires dans la mesure où des transactions réglées par carte feraient l'objet de prélèvements SEPA moins rémunérateurs en termes de commissions."
Auteurs : George Pauget, Emmanuel Constans
Rapporteur : Jean-Marc Lherm
mars 2012 (version pdf)

Quelques remarques sur le rapport

Le contrôle de l'IBAN en temps réel est un service intégré dans l'application GEMME dans sa phase expérimentale et assuré par l'application DIAMOND.
Cette application DIAMOND, proposée à la communauté en mars 2012 par le CM-CIC, permet, non seulement de vérifier l'identifiant bancaire d'un compte mais aussi les informations détenues sur le titulaire du compte.

SEPAmail est implémenté sur le réseau internet pour l'échange des données entre les adhérents SEPAmail. SEPAmail dispose de deux modes d'échanges de l'information : un mode flash sous la forme de services web et un mode canonique utilisant la messagerie électronique. La charge des systèmes internet et les protocoles utilisés ne garantissent pas un système temps réel au sens strict.
Par contre, le protocole d'envoi des missives SEPAmail permet d'assurer un temps très court dans le cas du mode flash et un temps de l'ordre de celui de nos courriels pour le mode canonique.

L'application GEMME permet de dématérialiser les échanges de documents liés au mandat de prélèvement. Elle n'est donc pas concurrente du moyen de paiement par carte mais permet, en facilitant le prélèvement, de faire diminuer le nombre de paiements par TIP ou par chèque.

L'application RUBIS initie des demandes de règlement qui peuvent déclencher un paiement par virement mais aussi un paiement par carte ou par tout autre moyen autorisé dans la norme ISO20022.
RUBIS permet à un utilisateur SEPAmail de dire à un autre utilisateur SEPAmail : "Je vous demande de me régler telle somme dans telle devise à telle date pour telle raison" et de transmettre un document justificatif et explicatif de cette demande.
L'utilisateur SEPAmail destinataire de la demande de règlement peut répondre: "Oui, je vais vous payer telle somme par tel moyen de paiement". Si la banque de cet utilisateur est en capacité d'enclencher ce paiement avec ce moyen de paiement et qu'elle a contractualisé cette action avec son client, alors, elle peut réaliser le paiement.
SEPAmail n'est donc pas en concurrence du moyen de paiement carte bancaire et ne devrait donc pas être à l'origine d'une attrition des revenus par carte bancaire.

Précisions sur SEPAmail

L'objet de SEPAmail se centre sur l'automatisation, la dématérialisation et la sécurité:
  • l'automatisation: la banque enclenche des paiements au passage des flux
  • la dématérialisation: la banque achemine des messages structurés, autoporteurs avec une pièce jointe lisible dans une logique "user friendly", la plus simple pour l'utilisateur
  • la sécurité: la banque authentifie les utilisateurs SEPAmail et garantit l'identité de ceux-ci, le dispositif SEPAmail assure l'intégrité des messages et la confidentialité du contenu sur internet et de bout en bout si besoin.
SEPAmail est respectueux :
  • du lien contractuel entre le client (utilisateur de SEPAmail) et sa banque (adhérente de SEPAmail)
  • du canal habituel utilisé par le client avec sa banque tout en favorisant les canaux dématérialisés (banque à distance, DAB, centre appel, version mobile)
La messagerie SEPAmail est un dispositif utile pour tous et non un moyen de paiement.

jeudi 24 mai 2012

SEPAmail est une messagerie sécurisée

SEPAmail est une messagerie sécurisée, notamment car :
  • elle permet d'authentifier tous les acteurs
  • elle assure la confidentialité et l'intégrité des messages
  • elle n'expose sur le réseau internet que des renseignements génériques, notamment elle permet la confidentialité de l'expéditeur et du destinataire du message
  • elle renforce le mécanisme de l'accusé de réception
Précisons ces points.

Les acteurs du dispositif SEPAmail sont des adhérents au réseau (principalement des banques) et des utilisateurs (des clients ou des agents des adhérents).
Les utilisateurs sont tous identifiés par un identifiant SEPAmail, le QXBAN.
Ce QXBAN fera l'objet d'un billet ultérieur pour en expliquer  l'intérêt et le principe.
Les utilisateurs sont toujours authentifiés par l'adhérent. Le niveau d'authentification dépend du service et du besoin fonctionnel.
Au passage, notons que SEPAmail a permis de spécifier SAPPhire, standard simple pour l'authentification dans un cadre générique.
Les adhérents SEPAmail sont identifiés par un identifiant bancaire, le BIC.
Les adhérents SEPAmail sont mutuellement authentifiées.

La messagerie utilise entre chaque partie (émetteur, récepteur, relais) des protocoles standards de cryptographie permettant nativement des fonctions de confidentialité, intégrité et authentification.

Ne sont exposés sur le réseau IP entre deux adhérents SEPAmail que des adresses de courriel du type [ecosystem]@[BIC].sepamail.eu et une priorité, comme décrit dans la documentation.

Enfin, un protocole d'acquittement des envois complète l'organisation de la messagerie. Cet acquittement n'est pas technique. Entres autres, il ne dépend pas des infrastructures. Il fait partie de la couche métier de la messagerie. Il est désynchronisé de l'envoi, complété par un procédé de renvoi et d'escalade en cas de non retour, au cœur d'une organisation de type automate fini.

mercredi 23 mai 2012

Vocabulaire SEPAmail : l'écosystème

Définition

Un écosystème SEPAmail est un ensemble de types de message ayant le même sujet.
Par exemple, les messages autour du mandat de prélèvement sont regroupés au sein de l'écosystème direct.debit.

Un type de message SEPAmail doit et ne peut appartenir qu'à un seul écosystème.

L'ensemble des écosystèmes SEPAmail forme donc une partition des messages SEPAmail.

Utilité

Les écosystèmes sont utilisés pour l'organisation de la messagerie :
  • le routage avec un aiguillage des enveloppes SEPAmail, d'après une adresse de courriel liée à l'écosystème selon le masque [ecosystem]@[bic].sepamail.eu
  • la sécurité avec des bi-clés liées à l'adresse de courriel de l'écosystème
  • les interfaces avec les systèmes d'information des adhérents SEPAmail et des utilisateurs SEPAmail selon l'écosystème
  • le classement des types de messages et des schémas selon l'écosystème

Les écosystèmes SEPAmail

Il a été défini à ce jour dix écosystèmes :
  • credit.activation, autour de l'avis de virement
  • digital.signature, autour de la signature numérique
  • direct.debit, autour du prélèvement
  • generic, autour du message générique
  • identification.verification, la vérification d'identité bancaire
  • payment.activation, autour de la demande de règlement
  • scheme, tout ce qui concerne l'organisation, notamment les référentiels
  • secure, tout ce qui concerne la sécurité, notamment l'inscription aux services et la mise en place des espaces de confiance
  • test , pour réaliser des tests
  • trade.service, autour des services commerciaux, dont la transmission de la facture
Le nom d'un écosystème est toujours en langue anglaise et les mots le composant sont séparés par le délimiteur point [.].

L'écosystème s'appelait de 2008 à 2011 la famille, ce qui n'avait pas d'équivalent naturel en anglais, d'où le changement de vocabulaire fin 2011, proposé par le groupe de travail "fonctionnel et études" de la communauté SEPAmail.

Lien avec les applications SEPAmail.

Trois écosystèmes correspondent à des fonctions transverses : scheme, test et secure.
Les autres sont liés chacun à une application SEPAmail selon la correspondance :
  • credit.activation ~ JADE
  • digital.signature ~ JASPE
  • direct.debit ~ GEMME
  • generic ~ AGATE
  • identification.verification ~ DIAMOND
  • payment.activation ~ RUBIS
  • trade.service ~ IOLITE
Il est possible que plusieurs applications utilisent des messages du même écosystème mais ce n'est pas le cas pour le moment.

Par nature, un écosystème regroupe les messages autour du même sujet alors que plusieurs applications peuvent voir le jour selon les besoins de la communauté.

Le concept de l'application SEPAmail est donc orienté "besoin métier" alors que le concept de l'écosystème est orienté "organisation de la messagerie".

mardi 22 mai 2012

Où trouver de l'information sur SEPAmail ?

SEPAmail, inventé par Cyril Vignet en 2008 (CNCE), dispose d'une documentation croissante depuis quelques mois.

La communauté SEPAmail a mis à disposition une documentation évolutive sous la forme d'un wiki sur internet, motorisé par mediawiki, le moteur de l'encyclopédie wikipedia.
L'adresse est simple à retenir : https://documentation.sepamail.eu.
Il est à noter qu'une version mobile existe, détectée automatiquement par le moteur de wiki.

Pour ceux qui connaissent un peu le protocole SEPAmail et le monde bancaire, le préfixe documentation ne peut pas être un BIC. Il devenait donc possible de réserver ce sous-domaine.

Remarque : pour information, les préfixes test, scheme, qxoo, www ont été également réservés pour des usages de publication.

Voici les quelques endroits à visiter, si vous vous intéressez à SEPAmail:

lundi 21 mai 2012

Vocabulaire SEPAmail : SMIRK ou la demande de commentaires

Historique de l'acronyme

SMIRK est l'acronyme de SEPAMail Internal Request for Komment, ce qui pourrait signifier en français  "demande interne de commentaires SEPAmail".

Cet acronyme a été trouvé par Olivier Jousselin lors d'une réunion en novembre 2011 à la Banque de France.
Ces documents -en cours de rédaction- étaient appelés depuis quelques semaines RFC pour "Request for Comment" mais ce nom ne plaisait pas à tous les membres de la communauté SEPAmail  au motif qu'il était trop lié aux RFC de l'IETF et donc pouvait amener de l’ambiguïté.

Dans le même temps, nous étions quelques uns à baptiser des composants fonctionnels par des noms de code étant des mots anglais commençant par SM (pour SEPAmail) de 5 ou 6 lettres : smart, smile, smurf, smog, smite, smoothy, smoke...

Il fallait l'idée de la demande de commentaire et internaliser le concept dans SEPAmail sans ambiguïté pour l'IETF.

C'est donc avec un petit sourire satisfait qu'Olivier nous a suggéré à voix basse SMIRK.

Le nom s'est vite imposé, le genre un peu moins vite et certains considèrent encore le SMIRK comme un acronyme féminin.

Où peut-on trouver les SMIRKs ?

Les SMIRKS se retrouvent sur l'espace documentaire de SEPAMail à l'adresse http://documentation.sepamail.org/wiki/Standards:Demandes_de_commentaires.

Elles font partie des standards ouverts de la communauté et sont généralement une œuvre collective publiée sous une licence creatives commons avec utilisation commerciale paternité à l'identique.

Il y a actuellement sept SMIRKs publiées dont les deux premières en statut "validé" et les cinq suivantes en statut "discussion":
Quatre autres SMIRKs ont été prévues mais ne sont pas encore soumises à la communauté:
  • SMIRK la qualité de service
  • SMIRK l'escalade
  • SMIRK le pilotage
  • SMIRK l'organisation

Utilité

Les SMIRKs définissent les concepts utilisés et les règles à respecter par la communauté SEPAmail. Elles contribuent donc au standard SEPAmail.

Comme autres documents  du standard, on trouve également :
  • les règles métier (BR pour Businness Rules) pour chacune des applications SEPAmail
  • les directives d'implémentation (IG pour Implementation Guidelines) pour chacun des types de messages SEPAmail
  • un schéma d'architecture fonctionnelle décrivant les couches utilisées et/ou définies par SEPAmail.

Organisation

Les SMIRK font d'abord l'objet d'un brouillon (draft).

Tout le monde peut écrire un brouillon. Ils n'ont donc aucune valeur, notamment normative.

Après avoir écrit un brouillon, on peut le soumettre au SCHEME (ou son bureau opérationnel, le QXOO).
Tous les brouillons n'étant pas dignes d'intérêt, ils ont une date de péremption. Si le brouillon attire l'intérêt de la communauté, un groupe de travail peut être créé pour la rédaction d'un SMIRK.

Quelques SMIRK finissent par devenir des standards de SEPAmail.


vendredi 18 mai 2012

Vocabulaire SEPAmail : enveloppe, missive et message

La double encapsulation

SEPAmail met en œuvre une double encapsulation :
  • le message SEPAmail est encapsulé dans une missive SEPAmail
  • la missive SEPAmail est encapsulée dans une enveloppe SEPAmail

Le message SEPAmail

Le message contient le signifiant à échanger entre les utilisateurs SEPAmail expéditeur et destinataire.
Il appartient forcément à un type défini (voir le type MessageType du schéma XML type_sepamail_message.xsd).
Un message est toujours une information structurée dans un format XML selon un schéma XMLSchema publié dans un espace de nom dédié de la communauté SEPAmail.

La missive SEPAmail

La missive SEPAmail sert à :
  • l'adressage,
  • l'identification des destinataire et expéditeur
  • l'acheminement du message et notamment son horodatage
La missive est aussi construite dans un format XML.

La missive respecte toujours la structure suivante :
  • un identifiant
  • un type
  • un ordre
  • une priorité
  • un entête contenant lui même l'adressage
  • l'information à échanger (le message, l'acquittement, la commande, le résultat...) et une signature facultative de cette information si besoin
La missive peut être vue comme le support de toutes les indications d'acheminement de l'information.

L'enveloppe SEPAmail

L'enveloppe SEPAmail garantit :
  • l'authentification du relais d'acheminement,
  • la confidentialité de la missive,
  • le transport de la missive sans révéler son adressage.
Pour cela SEPAmail utilise une enveloppe SMTP+S-MIME comme container de la missive chiffrée, la signature numérique de l'expéditeur, un adressage de type SMTP (par exemple [ecosystem]@[BIC].sepamail.eu) et une priorité.
Ainsi, cette enveloppe peut être envoyée et relayée telle quelle sur le réseau de la messagerie électronique (mode canonique) ou par un service web, même basique (mode flash).

Remarque : il existe aussi une enveloppe fichier afin de permettre le transport de plusieurs missives à la fois au sein d'un système d"information quand il n'y a pas de besoin d'authentification et de confidentialité. Pour bien distinguer ces deux enveloppes, seule l'enveloppe SMTP+S-MIME est appelée enveloppe SEPAmail.

Pour aller plus loin

Nous préciserons dans d'autres billets les différents types de messages et de missives et leurs usages.
Sur ces sujets, nous conseillons la lecture de :

jeudi 17 mai 2012

La norme ISO UNIFI 20022, norme de référence de SEPAmail

L'ISO 20022, c'est quoi ?

ISO 20022 est une norme qui succède à l'ISO 15022 dénommée aussi UNIFI ou "Financial Services - Universal financial industry message scheme".
Avec la norme ISO 20022, les prestataires de services financiers simplifient les transactions nationales et internationales en partageant une série de messages unifiés, des représentations communes de processus métier par grand segment.

On y trouve notamment les segments :
  • acmt "Account Management" Gestion de compte
  • admi "Administration" Administration
  • auth "Authorities" Autorités
  • caaa  "Acceptor to Acquirer Card Transactions" Transactions de l'accepteur à l'acquéreur
  • camt "Cash Management" Gestion de trésorerie
  • catm  "Terminal Management"
  • pacs  "Payments Clearing and Settlement"
  • pain  "Payments Initiation" Initiation du règlement
  • reda  "Reference Data" Données de référence
  • seev  "Securities Events" 
  • semt  "Securities Management" Gestion des titres
  • sese  "Securities Settlement" 
  • setr  "Securities Trade"
  • trea  "Treasury" Trésor
  • tsin  "Trade Services Initiation"
  • tsmt  "Trade Services Management"

SEPAmail et l'ISO 20022

SEPAmail est fondé sur le principe de ne rien inventer qui existe déjà et d'utiliser le plus possible des standards déjà largement répandus.
Il était donc naturel d'utiliser les messages de l'ISO 20022 pour décrire les échanges d'information dans les applications SEPAmail.

Toutes les applications SEPAmail qui sont des applications de paiement documentaire sont accrochées à un segment de l'ISO 20022 et plus particulièrement à quelques messages.
Ainsi, RUBIS utilise le pain.013 et le pain.014.

Afin d'intégrer des besoins que n'a pas encore prévu l'organisme de normalisation, la plupart des messages SEPAmail encapsulent le message de l'ISO tel quel et les autres besoins dans une partie dite non-ISO bien distincte.

La liaison entre les applications SEPAmail et l'ISO 20022

On retrouve ci-dessous un tableau récapitulatif des applications SEPAmail et le segment et les messages d'UNIFI qui sont utilisés.



Application
SEPAmail
Description iso 22022
RUBIS la demande de règlement pain.013
pain.014
GEMME le mandat de prélèvement pain.009
pain.012
DIAMOND vérification d'identifiant bancaire acmt.023
acmt.024
JADE l'avis de virement pain.001
IOLITE la transmission de facture tsin.xxx

Références

 On trouvera tout ce qu'il faut savoir sur l'ISO 20022 sur son site à l'adresse http://www.iso20022.org.

mercredi 16 mai 2012

Vocabulaire SEPAmail : la messagerie SEPAmail, les applications SEPAmail

Il ne faut pas confondre la messagerie SEPAmail et les applications SEPAmail qui utilisent la messagerie SEPAmail.

 

La messagerie SEPAmail

La messagerie SEPAmail est un dispositif permettant à deux entités économiques européennes de s'échanger de l'information de façon sécurisée.
Ce dispositif est mis en place par un réseau d'adhérents, essentiellement des banques européennes.
Il repose sur des standards de l'internet (IP, DNS, SMTP, S/MIME, syslog).
Un modèle en couches (enveloppe/missive/message) est proposé comme standard par la communauté SEPAmail. Ce modèle permet de spécifier de façon assez élégante des règles autour de l'échange, de l'adressage, du routage et de la sécurité.

 

Les applications SEPAmail

Les applications SEPAmail ont des noms de pierres précieuses.
A ce jour, on compte 7 applications :
  • AGATE, la pièce jointe générique
  • DIAMOND, la vérification d'identifiant bancaire
  • GEMME, le mandat de prélèvement
  • IOLITE, la transmission de facture
  • JADE, l'avis de virement
  • JASPE, la signature de document
  • RUBIS, la demande de règlement
Une application SEPAmail utilise la messagerie SEPAmail pour échanger des messages structurés entre les parties dans un dialogue de type question/réponse avec la possibilité de joindre des documents. Comme la banque est un relais de cet échange, elle peut, si le contrat avec son client le précise, enrichir les flux et automatiser des opérations, notamment de paiement (carte, virement, prélèvement).

Avec cette messagerie sécurisée et des applications partagées entre les adhérents SEPAmail, la dématérialisation, l'automatisation et la sécurisation sont beaucoup plus aisées à mettre en œuvre pour les entités économiques.

La mise en place de SEPAmail  dans les relations entre les entités économiques présage ainsi des réductions de coûts très importantes.

 

Pour aller plus loin :

mardi 15 mai 2012

Bienvenue sur ce blog


Nous sommes des utilisateurs de SEPAmail.

Certains d'entre nous ont participé à la rédaction du standard depuis 2008, d'autres sont arrivés plus tard et participent depuis à nos débats sur l'utilité du standard et les outils implémentés autour.

Nous souhaitons partager avec nos lecteurs nos informations, les actualités et nos réflexions sur SEPAmail.

Ce blog n'est pas le blog officiel de la communauté SEPAmail. Il n'engage donc pas les adhérents SEPAmail ou les entreprises pour lesquelles nous travaillons.

Si c'est ce que vous cherchez, vous trouverez la documentation officielle de SEPAmail ici : https://documentation.sepamail.eu.

Nous vous souhaitons bonne lecture et lirons vos commentaires avec plaisir.