Compendium EBICS - EBICS-Blog

Transcription

Compendium EBICS
Electronic Banking Internet Communication Standard
Version du document :
4.2.3
Date :
01.11.2013
Informations supplémentaires :
Michael Lembcke
[email protected]
4.2.3 – Electronic Banking Internet Communication Standard
Préface
A l'occasion du salon du CeBIT 2006, l'organisme de normalisation bancaire
allemand (ZKA - aujourd'hui comité central de crédit allemand [DK]) annonçait
un changement dans les procédures DFÜ avec la venue d'un nouveau standard, il s'agissait bien d'EBICS (Electronic Banking Internet Communication
Standard). Aujourd'hui, ce standard s'est positionné avec succès et, dans sa
version actuelle 2.5, il présente de bonnes chances de devenir le standard européen pour le traitement des opérations de paiement et les transactions interbancaires.
En Allemagne, EBICS est obligatoire pour les banques depuis le 1er janvier
2008 et remplace le protocole FTAM depuis début 2011. En France, la migration du protocole ETEBAC vers EBICS a officiellement démarré en novembre
2009.
Le 17. juin 2010, la société EBICS SCRL a été créée à Bruxelles, une société
qui s'est donné l'objectif de protéger la marque et de promouvoir le standard
EBICS. Les membres de EBICS SCRL viennent des fédérations bancaires allemandes, regroupées dans le Comité Central de Crédit (DK) et des banques
françaises, représentées par le Comité Français d’Organisation et de Normalisation Bancaire (CFONB).
Bien plus qu'un simple protocole de communication bancaire sur le réseau Internet, EBICS propose de nouvelles fonctionnalités telles que la signature distribuée (VEU) ou la signature d'authentification et permet également l'utilisation de certificats. La version actuelle EBICS 2.5 s'appuie justement sur une
infrastructure de type PKI (Public Key Infrastructure).
Version du document 4.2.3 du 01.11.2013
Le présent compendium donne au lecteur un aperçu des fonctions d'EBICS.
Les exigences techniques d'EBICS qui ont été décisives pendant la phase de
développement du standard et qui font vraiment la particularité d'EBICS seront
présentées dans un premier temps. Ensuite vient une description structurée
des fonctionnalités d'EBICS. Un positionnement par rapport aux autres standards comme FinTS ou SWIFT complétera l'examen d'EBICS. Pour conclure,
nous illustrerons la mise en œuvre d'EBICS sur l'exemple de la ligne de produit TRAVIC.
L'objectif de ce document est de donner une vision claire de ce que signifie le
passage à EBICS pour vous et votre entreprise. Nous avons essayé de vous
exposer de manière aussi compréhensible que possible des contextes qui
sont toutefois assez complexes. Nous vous souhaitons une bonne lecture!
PPI AG Informationstechnologie, Octobre 2013
1
Sommaire
1
2
3
Introduction .......................................................................................................... 4
1.1
Exigences EBICS ............................................................................................................ 4
1.2
Structure de la spécification .......................................................................................... 6
Scénario d'ensemble EBICS ............................................................................... 8
2.1
Interaction des protocoles ............................................................................................. 8
2.2
Prise en considération des produits ............................................................................. 9
2.3
Portails ............................................................................................................................. 9
2.4
2.4.1
Migration .......................................................................................................................... 9
Migration EBICS en France............................................................................................. 10
Communication et protection de l'infrastructure ........................................... 11
3.1
HTTPS et TLS – Transport Layer Security .................................................................. 11
3.2
XML – Extensible Markup Language ........................................................................... 11
3.3
Optimisation de la communication.............................................................................. 13
Modèle de données ........................................................................................... 14
5
Sécurité ............................................................................................................... 16
4
6
5.1
Sécurité de l'infrastructure ........................................................................................... 16
5.2
5.2.1
5.2.2
Procédure de signature ................................................................................................ 17
Signature d'authentification X001 ou X002...................................................................... 17
Signatures d'ordre (SE) selon A004 ou A005/A006 ........................................................ 18
5.3
5.3.1
5.3.2
Initialisation ................................................................................................................... 19
Certificats en France ....................................................................................................... 19
5.3.1.1
Le profil de remise T sur la base de certificats.......................................... 20
5.3.1.2
Profil d'autorisation TS .............................................................................. 20
5.3.1.3
Lettre INI comme scénario de repli ........................................................... 20
Lettre INI en Allemagne................................................................................................... 21
5.4
5.4.1
5.4.2
Procédure de chiffrement ............................................................................................. 21
TLS – Transport Layer Security ...................................................................................... 21
Chiffrement E001 et E002 ............................................................................................... 22
Fonctions techniques d'EBICS ......................................................................... 23
2
Types d'ordres............................................................................................................... 23
Opérations de paiement domestiques et internationales / relevés quotidiens ................. 23
Les opérations de paiement SEPA.................................................................................. 24
Types d'ordres standard pour Upload et Download FUL et FDL ..................................... 25
Autres types d'ordres ...................................................................................................... 26
6.2
Signature électronique distribuée (VEU) .................................................................... 26
6.3
Systèmes de portail ......................................................................................................29
6.4
6.4.1
6.4.2
Fonctions optionnelles ................................................................................................. 29
Examen préalable ........................................................................................................... 29
Données participants....................................................................................................... 30
6.5
EBICS pour les échanges interbancaires ................................................................... 30
7
Séquences EBICS .............................................................................................. 32
8
Positionnement à une échelle internationale .................................................. 34
9
6.1
6.1.1
6.1.2
6.1.3
6.1.4
8.1
FinTS .............................................................................................................................. 34
8.2
SWIFT ............................................................................................................................. 35
8.3
ETEBAC ......................................................................................................................... 36
8.4
Perspective .................................................................................................................... 36
Mise en œuvre .................................................................................................... 38
9.1
TRAVIC-Corporate......................................................................................................... 39
9.2
TRAVIC-Link .................................................................................................................. 39
9.3
EBICS-Mobile................................................................................................................. 40
9.4
API TRAVIC-Services pour EBICS ............................................................................... 41
9.5
TRAVIC-Web .................................................................................................................. 41
9.6
TRAVIC-Port .................................................................................................................. 41
Bibliographie ............................................................................................................... 43
Liste des abréviations ................................................................................................ 44
Liste des illustrations ................................................................................................. 46
3
1
Introduction
1.1
Exigences EBICS
La devise "évolution au lieu de révolution" résume à elle seule l'objectif que
l'on s'était fixé avec la création du nouveau standard EBICS.
Dès le départ, la spécification EBICS, qui entre-temps a été intégrée dans des
produits standards, fut conforme à cette devise; en effet, en raison du foisonnement d'idées innovatrices, il fallait s'assurer que le thème de la multibancarisation ne soit en aucun cas perdu de vue. La mise en oeuvre d'EBICS en Allemagne et en France le montre bien. Il n'est donc pas étonnant que la spécification se concentre concrètement sur le domaine de la communication, sur
les fonctionnalités cryptographiques pour la sécurité et sur quelques nouvelles
fonctionnalités nécessaires ou particulièrement intéressantes comme la signature électronique distribuée (VEU). Il n'est également pas surprenant que le
standard EBICS en Allemagne ait toujours été traité sous le couvert légal de
l'accord DFÜ, tout à fait reconnaissable dans la structure de la spécification.
Si la fonctionnalité de multibancarisation avait été entièrement ou même partiellement abandonnée, cela aurait eu pour conséquence un morcellement du
marché, ce qui n'aurait pas été dans l'intérêt des personnes impliquées.
Les exigences à respecter dans la norme EBICS pour succéder au standard
BCS (Allemagne) et au standard ETEBAC (France) sont en détail :
Exigences
Description
Internet
EBICS s'appuie fondamentalement sur les technologies Internet. A l'origine uniquement motivé par le
domaine de la communication, cet aspect s'étend à
travers toute la spécification et concerne aussi,
outre les standards de communication comme
HTTP et TLS, des standards comme XML ou signatures XML. Tous les standards Internet fiables et
appropriés doivent être utilisés.
Sécurité
Aujourd'hui, Internet et le thème de la sécurité sont
devenus indissociables. Si la sphère de sécurité
des réseaux quasiment fermés et utilisés jusqu'à
présent, devait être abandonnée, alors cela doit se
faire sans que la sécurité soit compromise. Cela
concerne certains aspects de la mise en œuvre, à
savoir les structures pare-feux de même que la signature et le chiffrement, mais aussi le fait que, parallèlement à la standardisation, un concept de sécurité a été établi et approuvé.
4
Exigences
Description
Largeur de bande
Un des principaux avantages devait être le découplage du protocole de communication du réseau
physique pour pouvoir profiter de plus de flexibilité
et surtout de débits de ligne plus élevés.
Performance et
rentabilité
A première vue, on pourrait penser que des aspects
comme la performance et les ressources ne sont
pas compatibles avec une spécification métier. Mais
au deuxième coup d'œil, on s'aperçoit qu'il est décisif pour la mise en œuvre de savoir comment un
protocole de communication est structuré car les
processus de traitement en dépendent. Dans l'idéal,
le protocole devrait être conçu pour pouvoir traiter
de grandes quantités de données et pour aider à
traiter ces données de manière rapide, sûre et économique. Un autre point résulte de l'utilisation de
standards dans leur forme originaire. De cette manière, il est possible, dans le domaine des platesformes, de recourir à des produits standards ou à
des composantes largement répandus (par
exemple, la compression ZIP), ce qui garantit un
traitement optimal et économique.
Technicité
EBICS introduit de nouvelles fonctionnalités, la principale étant la signature électronique distribuée
(VEU) sur le plan local et temporel. Vu que la plupart des produits standards ont intégré cette fonctionnalité, elle s'est établie entre-temps auprès des
clients et devrait désormais pouvoir être utilisée sur
le plan multibancaire.
Migration
La question de la migration est décisive pour l'expansion d'EBICS à vocation européenne. Il existe
dans beaucoup de pays européens des particularités nationales, en général l'ancien protocole est
maintenu en parallèle au nouveau, il est donc nécessaire de rendre la migration la plus souple possible côté client-entreprise et côté banque.
5
1.2
Exigences
Description
Engagements
Dès le départ, les fédérations bancaires allemandes
se sont fixées pour mission de développer le standard EBICS sous le couvert du DK (et aujourd'hui
de la société EBICS). Sur cette base, il fallait aussi
prendre des engagements concrets : à partir de
quand EBICS serait-il implanté globalement et
quand les anciens standards de communication seraient-ils abandonnés? Cela vaut aussi bien pour
l'Allemagne que pour la France.
Structure de la spécification
En conclusion de cette introduction, voici un aperçu de la structure de la spécification et des documents annexes faisant partie de la documentation.
Autres documents sur EBICS:
ANNEXE 1
Spécification pour la
connexion à EBICS
Notes 1: Returncodes
Notes 2: Types d‘ordres
EBICS
Common
Implementationguide
EBICS
Concept de
sécurité
Accord
DFÜ
V2.5
ANNEXE 3
Spécification des
formats de données
Figure 1:
(
)
ANNEXE 2
Spécification pour la
connexion à FTAM
Structure de la documentation sur le protocole EBICS
L'annexe 1 „EBICS“ est rédigé sous l'égide de la société EBICS et publié sur
ebics.org. La spécification est rédigée nativement en anglais, puis traduite en
allemand et en français. Ces documents se trouvent sur ebics.de ou cfonb.fr.
En plus de la spécification dans l'annexe 1, il est possible de recevoir un
"Guide d'implémentation" et en Allemagne – sur demande auprès du DK – un
concept de sécurité. Pour la version 2.5, le guide d'implémentation est devenu
un document générique et remplace les versions antérieures françaises et al-
6
lemandes. La souplesse de migration, la facilité de déploiement, la sécurité du
système d'exploitation répondent aux exigences demandées.
L'annexe 3 de l'accord DFÜ est consacré aux formats de données SWIFT ou
SEPA en Allemagne, et ne concerne pas les activités EBICS à l'échelle européenne. Le nom de l'annexe 3 correspond par hasard à la version EBICS actuelle V2.5.
L'annexe 2 consacré au protocole FTAM n'est plus d'actualité mais complète
la documentation par soucis d'exhaustivité.
7
2
Scénario d'ensemble EBICS
Dans ce chapitre, un scénario d'ensemble est présenté à titre d'exemple.
Cette approche doit aider à comprendre comment il est possible de migrer de
manière souple et sans interruption une infrastructure existante stable tout
comme une plate-forme Internet déjà établie sur la base de produits standards
vers un système ciblé EBICS. En Allemagne, la migration de FTAM vers
EBICS est terminée. Cependant, l'exemple suivant illustre la migration d'un
standard national vers EBICS.
2.1
Interaction des protocoles
Pour monter un tel scénario, il doit, en principe, être possible d'exploiter parallèlement un ancien standard (par exemple BCS-FTAM) et EBICS du côté
banque sur une période plus longue. La figure suivante présente une possible
configuration :
BANQUE
RNIS
Client BCS
FTAM
BCS/FTAM
Gestion des données de base
Format VEU
11
0 11
1 01
1
0
Plafond
TCP/IP TLS
Client EBICS
EBICS
Infrastructure
Internet
Compte
EBICS
Engine
Security
Progiciel client
Figure 2:
TCP/IP SSL
spécifique
au produit
Spécifique
au produit
1
1
Données
0 11
de
1 0base
1
1
0
Système transfert de paiement
CLIENT
ORDINATEUR
BANCAIRE
Scénario d'ensemble BCS/EBICS pour illustrer la migration
d'un ancien protocole vers EBICS
Dans la configuration présentée, il est clair que - à l'exception des composants d'accès - de nombreux éléments sont exploités conjointement dans les
deux systèmes. Comme la procédure de sécurité A004 et les formats sont
identiques aux deux systèmes, il n'est pas nécessaire de les séparer et donc
un scénario d'ensemble est envisageable sur une durée plus longue, si l'on
fait abstraction des frais d'exploitation surélevés engendrés par l'utilisation
8
double des composants. Mais de toute façon, la feuille de route déterminée
dans l'accord DFÜ limite cette période totale à fin 2010.
2.2
Prise en considération des produits
Dès la première lecture, on s'aperçoit que la spécification EBICS est vraiment
cadrée sur les cas d'utilisation métiers. Cela vient également du fait que la
spécification a pu faire ses preuves dans les produits standards disponibles
sur le marché, offrant ainsi une preuve de concept. Le point commun de tous
ces produits étaient qu'ils présentaient des options pour traiter les paiements
de masse pour les clients entreprises sur les plates-formes Internet. De plus,
chaque produit a élargi son champ d'application et son périmètre fonctionnel.
De cette manière, le standard EBICS a pu puiser les meilleures solutions dans
ce portfolio. Ceci explique pourquoi, lors de l'introduction d'EBICS, des problèmes tels que la segmentation de grands messages avaient déjà été résolus, ou pourquoi le concept de la signature électronique distribuée était déjà
disponible et ne nécessitait pas d'être complété ou optimisé après la phase de
déploiement.
2.3
Portails
Depuis quelques années, chaque banque propose dans sa palette de services
des portails entreprises basés sur navigateur Internet. Vu que EBICS s'appuie
sur une technologie Internet, il est évident que EBICS comme protocole de
transfert peut bien s'accorder avec un portail web d'entreprise. Cela est le cas
tant qu'on communique avec le portail web d'une banque. En ce qui concerne
l'intégration de tiers juridiquement indépendants, quelques problèmes juridiques subsistent même sous EBICS, si j'utilise le portail web de ma banque
comme portail client pour la communication avec des banques tiers.
2.4
Migration
Ce paragraphe examine de plus près la réalisation d'une migration typique de
BCS vers EBICS du côté client. Etant donné que les banques sont obligées
de proposer EBICS depuis le 1er janvier 2008, en tout cas en ce qui concerne
l'Allemagne, ce paragraphe décrit le scénario d'utilisation côté client.
Remarque:
Dans les réflexions suivantes sur la migration, on présume que la
version de produit client BCS utilisée est la version actuelle.
L'infrastructure actuelle doit supporter les signatures de la version
A004, par exemple, afin de ne pas devoir introduire une nouvelle
procédure de sécurité en plus du renouvellement /complément de
l'infrastructure de communication. Par conséquent, on présume
également que le passage aux nouvelles procédures de sécurité
A005 ou A006 à partir de la version EBICS 2.5 a lieu séparément
de la migration.
9
D'autre part, on présuppose qu'une infrastructure Internet est déjà
disponible, comme cela est obligatoire pour d'autres applications
Internet.
Si les exigences administratives sont remplies, la migration idéale du côté
client doit alors se limiter à une simple mise à jour du produit client actuel.
Bien que les données de base client ou participant (voir paragraphe sur le
modèle des données) sont conservées, les données de communication sont
modifiées. Les paramètres requis pour la connexion sont indiqués dans les
données contractuelles EBICS et sont délivrés par la banque.
Après l'installation de la mise à jour et une fois la configuration effectuée, il est
alors possible d'établir une connexion avec la banque via Internet.
Il ne faut pas sous-estimer la compréhension de nouvelles fonctionnalités
comme l'examen préalable, dans la mesure où la configuration du produit est
impliquée. De même, l'utilisation de nouvelles fonctionnalités comme la signature électronique distribuée exige une compréhension profonde du protocole
EBICS. Les chapitres de ce compendium donnent les éléments essentiels de
compréhension.
L'un des problèmes qui reste à résoudre est l'initialisation EBICS d'un participant déjà initialisé par le biais de FTAM. Celui-ci possède évidemment déjà
une clé privée pour la signature d'ordres, mais il ne dispose pas de paires de
clé pour l'authentification et le chiffrement. EBICS propose alors d'utiliser le
type d'ordres HSA permettant à un participant ayant le statut Nouveau_FTAM
de remettre ses nouvelles clés EBICS avec sa signature électronique activée
pour FTAM. Ce procédé optionnel permet d'adopter les participants dans
EBICS sans difficulté et sans qu'une nouvelle initialisation au moyen de la
lettre INI ne soit requise.
2.4.1
Migration EBICS en France
En France, le réseau X.25 va être bientôt abandonné. Cela signifie que le protocole ETEBAC 3 largement répandu ne pourra plus être utilisé et qu'une migration vers EBICS est devenue nécessaire.
Théoriquement une solution intermédiaire serait envisageable en utilisant le
protocole ETEBAC 5 déjà basé sur TCP/IP, mais cela ne remet pas en question l'introduction d'EBICS. Le standard ETEBAC-5 basé sur un système de
certification est largement moins répandu.
10
3
Communication et protection de l'infrastructure
Ce paragraphe se consacre à la pièce maîtresse du standard EBICS : la
communication via Internet.
Dans les ouvrages d'introduction à l'Internet sur les protocoles de communication, on cherche toujours à situer le protocole TCP/IP dans le modèle OSI
(Open Systems Interconnection) afin d'établir une comparabilité historique.
Jusqu'à un certain degré, cette comparaison est possible et justifiée, mais elle
est sans intérêt dans le cas du standard EBICS. Cette orientation vers des
plates-formes Internet est décisive de part l'utilisation des infrastructures disponibles aussi bien du côté client que du côté banque, et aussi parce qu'elle
fournit un degré de performance bien plus élevé qu'avec la solution actuelle.
L'ancien standard BCS utilisait le réseau RNIS comme moyen de transmission, ce qui de nos jours est devenu pour le transfert de gros fichiers de paiement par exemple.
De plus, l'utilisation de la technologie Internet permet à EBICS de se rapprocher d'autres applications. Comme les clients entreprises ont de nombreux
champs d'application (à l'exception des paiements de masse) dans le domaine des transactions ou dans l'interface graphique, une interaction est indispensable avec d'autres services comme par exemple le deuxième standard
significatif du comité DK, le FinTS (Financial Transaction Services) en Allemagne. Ce qui est fortement simplifié par l'usage de plates-formes communes.
Enfin, l'utilisation de cette technologie a aussi pour effet qu'un nombre bien
plus important de composants et de produits est disponible que cela était le
cas avec les anciens standards tels que BCS ou ETEBAC.
3.1
HTTPS et TLS – Transport Layer Security
Alors que le protocole TCP/IP est dédié par exemple au routage dynamique
en cas de défaillance d'une section de ligne, HTTP contrôle la session entre
deux partenaires. EBICS n'utilise que la variante sécurisée HTTPS, ce qui se
reconnaît, par exemple, à l'affichage d'un cadenas dans le coin inférieur du
navigateur. La protection est fournie par le dispositif TLS (Transport Layer Security) qui complète et doit prendre la relève à moyen terme du dispositif plus
connu, le SSL (Secure Socket Layer).
TLS garantit une transmission sécurisée entre le système client et le premier
serveur HTTP ou serveur Web de la banque. Bien que ce dispositif remplisse
cette fonction tout à fait correctement et de manière sûre, cela ne suffisait pas
aux responsables du standard EBICS, comme nous le verrons dans un des
chapitres suivants.
3.2
XML – Extensible Markup Language
Pour faciliter la compréhension des chapitres suivants, le langage XML est
expliqué dans ce qui suit. Avec BCS, les comptes-rendus pouvaient être ca-
11
chés dans le nom du fichier, mais avec EBICS, une enveloppe de compterendu séparée est générée. Dans le cadre de la technologie Internet, il est judicieux d'utiliser le langage de description des données XML – Extensible
Markup Language.
Dans EBICS, chaque demande (request) ou réponse (response) est composée d'un ordre qui est analogue aux types d'ordres définis et à une enveloppe
XML. Il s'agit donc d'un genre de système hybride, dont le noyau demeure les
formats bancaires DTA, SEPA ou SWIFT, mais qui est complété par des
structures XML. La surcharge d'information engendrée par cette technique est
minimale, car il s'agit typiquement de paiements de masse et le fichier de
paiement représente un multiple de l'enveloppe XML.
La figure suivante illustre tous les schémas XML définis dans EBICS. Vous les
trouverez – conformément au concept namespace XML – aux adresses respectives http://www.ebics.de.
Namespace H000
ebics_hev.xsd
schéma pour le type d‘ordre EBICS HEV
Namespace H004
ebics_request_H004.xsd
schéma de protocole EBICS pour les demandes
ebics_response_H004.xsd
schéma de protocole EBICS pour les réponses
ebics_orders_H004.xsd
contient les éléments de référence relatifs aux ordres et les définitions de types relatifs aux ordres pour
EBICS
ebics_types_H004.xsd
contient les définitions de types simples pour EBICS
ebics_keymgmt_request_H004.xsd
schéma de protocole EBICS pour les demandes de gestion de clés
(HIA, HPB, HSA, INI, SPR, H3K)
ebics_keymgmt_response_H004.xsd
schéma de protocole EBICS pour les messages de réponse de gestion de clés
(HIA, HPB, HSA, INI, SPR, H3K)
ebics_H004.xsd
contient les schémas restants, pour assurer une cohérence dans le namespace
Figure 3:
Schémas XML EBICS
Vous pouvez constater que les schémas sont structurés de manière claire, et
que les définitions de type sont séparées des schémas de comptes-rendus
techniques.
Le premier schéma présente une particularité. H000 sert à la gestion des versions et permet de savoir quelles versions de compte-rendu la banque supporte.
12
Le namespace S001 contenant le schéma de signature EBICS ne figure pas
dans la liste. Les versions actuelles des schémas EBICS se trouvent aux
pages officielles ebics.org et ebics.de.
3.3
Optimisation de la communication
Une série d'optimisations dans le domaine de la communication a permis de
prendre en compte les propriétés spécifiques à l'Internet.
Il est possible avec le standard EBICS de comprimer les données de transfert.
EBICS utilise un algorithme ZIP gratuit et largement répandu.
Afin d'éviter de bloquer les capacités des instances Internet du côté banque,
le protocole EBICS offre la possibilité de segmenter de grandes quantités de
données.
La capacité (optionnelle) de récupération permet aussi une reprise intelligente
de la transaction lorsqu'un transfert de fichiers a été interrompu. Des segments déjà transmis ne doivent donc pas être doublement envoyés.
Par l'intermédiaire de Nonce et Timestamp, EBICS met aussi à disposition
un procédé qui permet de détecter les doubles remises (replays). Pour cela,
un produit client génère une valeur fortuite "Nonce" (valeur "ad hoc") qui est
reprise avec la date/l'heure dans l'enveloppe EBICS. Une liste des valeurs déjà utilisées par le participant pour Nonce et Timestamp est présentée du côté
banque, ce qui permet de vérifier le caractère unique d'un ordre.
13
4
Modèle de données
Ce chapitre s'intéresse de plus près au modèle de données utilisé par EBICS.
Ce modèle est intégré dans la gestion des données de base des produits utilisés et est quasi-identique pour les deux standards, comme cela a déjà été
mentionné dans les caractéristiques de la migration.
De manière schématique, le modèle de données présente les entités suivantes :

client

compte

participant

type d'ordre
Dans la nomenclature, un client constitue le point de départ. C'est le terme
générique pour une entreprise qui, d'une part, possède plusieurs comptes
dans une banque et qui, d'autre part, autorise l'accès à ces comptes à plusieurs participants.
Un participant peut, par exemple, être un employé d'une entreprise qui
agit sur ordre du client. Une classe de signature lui est attribuée. Celle-ci détermine si le participant a le droit d'autoriser des ordres, en agissant seul ou
avec d'autres participants.
Les classes de signature suivantes existent :
Classe de signature E
Signature individuelle
Aucune autre signature n'est requise pour l'autorisation de l'ordre.
Classe de signature A
Première signature
Au moins une autre signature de la catégorie B
est requise.
Classe de signature B
Deuxième signature
L'ordre doit déjà disposer d'une signature de la
catégorie A.
Classe de signature T
Signature de transport
Indique qu'il s'agit d'une signature d'authentification, par exemple, un participant technique.
Un participant avec classe de signature E, A ou B obtient le droit de signature
pour certains comptes de l'entreprise et on lui attribue les types d'ordres pour
lesquels il est autorisé.
Ainsi, un système de compétence flexible est créé qui est ensuite reproduit du
côté client et du côté banque dans les produits respectifs.
14
La figure suivante est une représentation simplifiée du modèle de données :
CLIENT
Catégorie de signature
Accord


Participant


STA
IZV
Individuelle
Première
Deuxième
Transport
Types
AZV
d'ordre
Compte 2
Compte 1
Comptes-client
Figure 4:
Modèle de données
Lorsqu'on évoque le modèle de données, il ne faut pas oublier de mentionner
les données contractuelles EBICS et les données de l'utilisateur. Toutes les
informations concernant l'accès bancaire ainsi que les fonctions optionnelles
proposées par la banque sont mentionnées dans les données contractuelles
EBICS qui vous sont fournies par le serveur EBICS. Par exemple, on y trouve
l'adresse de communication (URL). Les données de l'utilisateur proposées en
option par la banque contiennent des informations spécifiques au client et au
participant comme les comptes ou les types d'ordres autorisés.
15
5
Sécurité
La version précédente V2.4 avait introduit de nouvelles procédures de sécurité A005 et A006 ou X002 et E002. Mais plus important encore, sont les stipulations concernant l'obligation de mettre en place ces procédures – une nouveauté avec l'introduction du standard EBICS.
Les supports de stockage en soi (carte à puce, disquette ou clé USB) ne sont
pas pris en compte. A ce sujet, le standard EBICS ne donne aucune consigne
et laisse les clients ou éditeurs faire leur choix. A l'aide de la classification suivante, le système client peut déterminer le support de stockage utilisé par le
client :
5.1

Aucune indication

Disquette

Carte à puce

Autre support de stockage

Support de stockage non interchangeable
Sécurité de l'infrastructure
Pour obtenir un haut niveau de sécurité de l'infrastructure, EBICS a mis en
place un concept global pour la signature et le chiffrement. Avec EBICS, les
signatures de client sont obligatoires. Les signatures bancaires sont prévues
et seront définies de manière concrète une fois que les questions légales auront été résolues (une signature bancaire se rapportant à des personnes par
opposition à un cachet de l'entreprise). De plus, une signature supplémentaire
est requise, la signature d'authentification X001 ou X002.
A l'exception du chiffrement impératif avec TLS sur le plan du transport, la
procédure de chiffrement propre au standard EBICS (E001 ou E002) est obligatoire pour garantir une sécurité de bout en bout.
Dans une étape d'initialisation spéciale, au cours de laquelle des examens
préalables optionnels peuvent être effectués, un ID de la transaction est notamment attribuée pour l'ensemble de la transaction. Cela permet de créer
une parenthèse de transaction, condition préalable pour la segmentation lors
du transfert de quantités importantes de données.
Ces stipulations permettent d'obtenir un degré de sécurité conforme aux besoins d'une entreprise utilisant l'Internet, et dont la fiabilité a été analysée et
prouvée dans un concept de sécurité correspondant.
 Vous trouverez plus de détails sur les propriétés de protocole
au chapitre Séquences EBICS à la page 32.
16
5.2
Procédure de signature
EBICS connaît deux signatures différentes :

les signatures d'authentification pour l'identification du remettant

les signatures pour autoriser un ordre, la signature électronique (SE) pour
l'autorisation bancaire des ordres
Les deux types de signature se distinguent très nettement comme vous pouvez le constater dans la figure suivante :
Signature d’authentification
Redondance
Initialisation
EBICS SE
Ordres
Hachage
Redondance
Hachage
Signature XML
EBICS SE
Figure 5:
5.2.1
Procédure de signature EBICS
Signature d'authentification X001 ou X002
La signature d'authentification sert à identifier le remettant de manière univoque. La signature d'authentification est vérifiée dans le cadre de l'étape
d'initialisation ainsi que dans toute autre étape de la transaction, c'est-à-dire
avant même que les données de l'ordre soient transmises (voir chapitre Séquences EBICS, page32 ).
Les participants, qui sont exclusivement chargés de la remise des ordres,
peuvent avoir la classe de signature T avec laquelle il est également possible
de configurer de simples "participants techniques" qui sont uniquement autorisés à la remise des ordres.
La signature d'authentification est créée selon une procédure courante dans le
domaine des transactions. Les ordres sont complétés par des informations
17
dynamiques (par exemple, ID de session, heure/date ou informations similaires) qui permettent ainsi d'obtenir avec les mêmes données d'utilisateur différentes signatures correspondant à une situation spéciale. Les spécialistes
du chiffrement de données appellent cela la redondance. Une somme de contrôle chiffrée, la valeur de hachage, est établie sur toute la structure. Sa principale caractéristique est de générer précisément une valeur avec les données qui sont fournies ; cette valeur ne peut être générée à partir d'aucune
autre combinaison de données. Il existe donc une conformité parfaite entre les
données et la valeur de hachage.
Sur la base de cette valeur de hachage et avec l'aide d'une clé de signature,
une signature numérique est créée. Pour être complet, Il faut préciser que les
données sont saisies avant la formation de la valeur de hachage selon un algorithme défini et à une longueur minimum déterminée (padding) ; ainsi,
même lorsqu'il s'agit de petites quantités de données, le mécanisme fonctionne.
Comme ce procédé est courant dans le monde des transactions, il est aussi
supporté sous cette forme dans le standard de signature XML W3C. Par conséquent, EBICS supporte la signature d'authentification analogique XMLSignature comme standard X001 ou X002.
5.2.2
Signatures d'ordre (SE) selon A004 ou A005/A006
La signature électronique (SE) d'un ordre du côté client (à l'avenir aussi du côté banque) est réalisée depuis la version EBICS V2.4 avec la procédure de signature A005 et A006. Contrairement à la génération de la signature d'authentification, les étapes pour la génération de redondance et de valeur de hachage sont ici inversées. L'utilisation de la valeur de hachage de fichier
comme "représentant" direct des données d'origine permet de créer cette valeur sans redondance directement depuis le fichier d'ordre et peut être ainsi
vérifiée de manière directe quelque soit sa position.
Pour des raisons de migration, EBICS requière la signature RSA selon A004
comme point de départ (les anciennes variantes de signature de l'accord DFÜ
n'étant pas supportées). La version A004 était déjà conçue pour l'utilisation de
la carte de signature, largement utilisées par les banques allemandes, avec
SECCOS comme système d'exploitation, mais comme déjà mentionné, l'utilisation de disquettes ou de clés USB est également possible.
Avec la version A004, SECCOS supporte un profil composé des algorithmes
suivants :

Signature RSA avec longueurs de clé de 1.024 bits

Padding selon ISO9796-2

Procédure de valeur de hachage RIPEMD160
18
Aujourd'hui tout à fait courant et depuis EBICS V2.4 rendu obligatoire, les procédures de SE A005 et A006 ont les attributs suivants:
A005
A006
Longueur de clé
1.536 – 4.096 bits
1.536 – 4.096 bits
Procédure de valeur de
hachage
SHA-256
SHA-256
Procédure de padding
PKCS#1
PSS
Le tableau montre qu’A005 et A006 se distinguent uniquement dans la procédure de padding.
A première vue, lorsqu'on regarde le concept de sécurité et la partie concernant le système d'exploitation des cartes à puces SECCOS, on pourrait penser que la spécification EBICS reste plutôt un standard allemand. Cela n'est
pourtant pas le cas. La stratégie adoptée par le DK pour l'usage des cartes
respecte strictement les normes de l'office allemand de la sécurité des technologies de l'information BSI, qui s'oriente aux normes européennes pour l'usage
des SE (signature électronique) et garantie donc son utilisation au niveau international.
5.3
Initialisation
Avant de pouvoir utiliser une paire de clé, l'authenticité des partenaires doit
d'abord être établie sur la base d'un procédé adapté. Pour cela, on utilise des
certificats ou bien des procédés alternatifs suivants d'autres voies. Le support
de certificats selon X.509 est certes prévu par EBICS, mais, actuellement en
Allemagne, on utilise la lettre d'initialisation. En France, une infrastructure PKI
existait déjà à l'introduction du standard EBICS. Il est possible d'utiliser des
certificats dans le cadre de l'initialisation, ce qui est supporté dans la version
V2.5 du protocole EBICS.
Les deux concepts seront présentés dans les chapitres suivants, donnant la
possibilité de mixer les deux concepts, comme le montre le scénario de repli
utilisé en France.
5.3.1
Certificats en France
La base du principe de validation par certificat est d'avoir une procédure de
sécurité appropriée. Il faut donc pouvoir vérifier l'origine des certificats pour
estimer leur degré de sécurité. En France, il existe des normes bien précises
pour l'utilisation des certificats dans EBICS. L'utilisation de certificats attestés
par une autorité de certification représente le plus haut niveau de sécurité
conformément aux normes de signature européennes. En France, il est également possible d'échanger des fichiers de paiements à un degré de sécurité
moins élevé comme expliqué ci-après.
19
En France, les classes de signature utilisées sont T et E. Pour le moment, la
signature distribuée n'est pas supportée. Au lieu de cela, il existe deux profils
pour la remise (T) et l'autorisation (E).
Pour la remise de certificats, il est possible à partir de la version 2.5 de remettre des certificats en utilisant le nouveau type d'ordre H3K. Le processus
d'initialisation d'un client n'a pas été modifié.
5.3.1.1 Le profil de remise T sur la base de certificats
Pour le moment, on utilise en France uniquement la classe de signature T,
c'est à dire que l'ordre est remis via EBICS, puis autorisé par fax dans un second temps. Cela correspond à la méthode de validation employée dans le
standard ETEBAC 3 qui est largement répandu.
L'initialisation ne doit pas forcément être réalisée au travers d'une autorité de
certification (AC), il est également possible d'utiliser des certificats auto-signés
avec une lettre INI.
Par contre, si le certificat a été délivré par une autorité de certification, celui-ci
doit faire partie d'une liste de confiance.
5.3.1.2 Profil d'autorisation TS
On utilise dans ce cas les signatures électroniques pour le transport et la signature. La procédure correspond en gros au protocole plus récent ETEBAC
5. Dans ce cas, le certificat pour la clé de signature doit être délivré par une
autorité de certification et signé et doit faire partie d'une liste de confiance. Les
certificats pour les clés d'authentification et de chiffrement peuvent être également auto-signés.
La vérification du certificat est obligatoire pour la clé de signature, pour les
clés d'authentification et de chiffrement, la vérification et validation des certificats se fait par une AC, si les certificats ont été délivrés par une AC.
5.3.1.3 Lettre INI comme scénario de repli
En France, l'utilisation de certificats n'exclue pas pour autant l'envoi de lettres
INI pendant le processus d'initialisation. Indépendamment de l'utilisation de
certificats, le client doit au départ envoyer une lettre INI.
Les certificats qui ne sont pas délivrés par une AC sont uniquement activés
par une lettre INI. Les certificats délivrés par une AC doivent toujours être vérifiés par une AC. Quand la vérification du certificat par l'AC est positive, les
données du certificat doivent également être comparées aux indications
transmises par le remettant. Si des différences sont constatées, l'activation
manuelle peut toujours se faire sur la base d'une lettre INI.
Après vérification et activation, le certificat du client est sauvegardé dans le
système de l'application. De cette manière, le contrôle de la non révocation du
20
certificat peut être effectué – le client n'a besoin de remettre le certificat
qu'une seule fois.
5.3.2
Lettre INI en Allemagne
Lors de la procédure de validation par lettre INI, un participant génère une
paire de clés et communique à la banque sa clé publique avec le type d'ordres
INI (ou HIA s'il s'agit d'une clé publique pour la signature d'authentification ou
pour le chiffrement). Parallèlement à cela, une lettre d'initialisation est imprimée ; elle contient les données administratives, la clé publique et la valeur de
hachage correspondante. Cette lettre d'initialisation est signée manuellement
par le participant, puis envoyée par courrier ou par fax à la banque avant
d'être comparée avec les données transmises par voie électronique. Lorsqu'identique, la clé est activée et peut être alors utilisée par le participant. Le
même procédé peut être exécuté dans le sens inverse si la signature de la
banque est introduite à une date ultérieure. Le participant a ici pour mission de
comparer les données de clé transmises par voie électronique et postale, et
de confirmer qu'elles sont identiques.
5.4
Procédure de chiffrement
EBICS utilise un double chiffrement selon TLS ainsi que le chiffrement EBICS
E001 ou E002 afin de permettre à la fois un chiffrement standard dans HTTPS
et un chiffrement de bout en bout. A partir de 2009, le procédé AES recommandé par BSI sera introduit pour E002.
5.4.1
TLS – Transport Layer Security
TLS prend la relève d'un standard largement répandu, le SSL. Ces deux protocoles de chiffrement ont pour caractéristique de garantir à la fois l'authentification et le chiffrement sur une voie de transport. Des réglages correspondants se font du côté client dans le navigateur Internet, par exemple, et du côté banque dans les serveurs Web courants.
Lorsqu'une connexion TLS est établie, les partenaires échangent certificats et
procédés soutenus, ce qui sert alors de base à la création d'une session.
Selon un principe communément admis, EBICS utilise uniquement l'authentification de serveur à partir de TLS et ne supporte actuellement aucun certificat
de client TLS. Les certificats Internet employés généralement par les banques
sont utilisés comme certificats de serveur (qui sont, par exemple, certifiés par
VeriSign).
Le chiffrement a lieu dans les deux sens. Seules les procédures de chiffrement puissantes ou cybersuites sont supportées. Le standard désigne quatre
cybersuites qui doivent être supportées par chaque partenaire EBICS.
21
5.4.2
Chiffrement E001 et E002
Pour le chiffrement E001 et E002, il s'agit d'une procédure hybride ainsi nommée car elle est composée d'algorithmes asymétriques et symétriques. Le
principe de base consiste à utiliser une clé RSA asymétrique en tant que clé
de chiffrement. Pour des raisons de performance, le message même est crypté symétriquement. Comme clé, on utilise une clé dynamique qui est échangée (sécurisée avec la clé de chiffrement).
E001 utilise une clé de chiffrement longue de 1.024 Bit et l'algorythme Padding PKCS#1.
La version EBICS V2.4 a introduit la procédure E002. Il s'agit là du passage
de Triple-DES à AES (recommandation de BSI depuis 2009).
22
6
Fonctions techniques d'EBICS
Pour l'essentiel, EBICS est identique au standard BCS-FTAM en ce qui concerne la technicité. Ainsi, les types d'ordres définis dans BCS sont conservés
dans EBICS, tant qu'ils ne se réfèrent pas à FTAM comme protocole de communication et qu'ils ne sont donc pas obsolètes.
Mais EBICS est bien supérieur à BCS sur de nombreux points et ouvre de
nouveaux champs d'application pour le client.
6.1
Types d'ordres
Dans l'accord DFÜ, vous avez plusieurs types d'ordres à votre disposition
pour réaliser vos virements et prélèvements :
6.1.1

Les opérations de paiement domestiques sur la base de différents formats DTA

Les opérations de paiement SEPA

Les opérations de paiement internationales avec DTAZV

Les opérations sur valeurs mobilières

Les accréditifs

Les informations de relevé de compte quotidien avec MT940/MT942 pour
les opérations comptabilisées et les avis des opérations de compte
Opérations de paiement domestiques et internationales / relevés quotidiens
L'aperçu suivant liste quelques exemples de types d'ordres standardisés en
Allemagne :
AZV
Envoyer un ordre de paiement international en format disquette
AZ2
Envoyer un ordre de paiement international en format bande magnétique (champ longueur d'enregistrement 2 octets)
AZ4
Envoyer un ordre de paiement international en format bande magnétique (champ longueur d'enregistrement 4 octets)
ESU
Envoyer un virement standard européen (type de règlement 13)
DTE
Envoyer un ordre urgent (ordre de paiement domestique en format
DTAUS0)
IZG
Envoyer un ordre de paiement domestique (seulement virements)
IZL
Envoyer un ordre de paiement domestique (seulement prélèvements)
IZV
Envoyer un ordre de paiement domestique
23
6.1.2
MC2
Envoyer un ordre de paiement domestique en format bande magnétique (champ longueur d'enregistrement 2 octets)
MC4
Envoyer un ordre de paiement domestique en format bande magnétique (champ longueur d'enregistrement 4 octets)
STA
Télécharger relevés quotidiens SWIFT (SWIFT MT940)
VMK
Télécharger transactions prévisionnelles à court terme (SWIFT
MT942)
VML
Télécharger transactions prévisionnelles à long terme (SWIFT
MT942)
Les opérations de paiement SEPA
EBICS supporte des types d'ordres pour les opérations de paiement SEPA
client-banque et banque-banque (banque centrale allemande et interbanque
STEP2). Voici les messages SEPA qui sont supportés actuellement pour
l'interface client-banque :

SEPA Credit Transfer Initiation

SEPA Direct Debit Initiation

Restitution avant settlement (Rejects)
Ces messages se reflètent dans les types d'ordres EBICS correspondants,
bien que la particularité suivante doive aussi être prise en compte.
Lors de la conversion des messages SEPA pour les banques allemandes, on
a constaté l'utilité d'introduire, en plus du format SEPA, des formats élargis
pouvant être utilisés suivant la banque ou le cas d'application. Plus précisément, il s'agit ici d'ordres collectifs avec plusieurs formations de groupe, par
exemple, des comptes du donneur d'ordres ou des données d'exécution qui
peuvent être traitées différemment (exemple : le traitement de plusieurs
comptes de donneur d'ordres) :

Format standard SEPA
Utilisation du format standard SEPA avec une restriction : seuls les ordres
pour un compte de donneur d'ordre sont possibles. Pour pouvoir exécuter
les ordres de plusieurs comptes de donneur d'ordres avec cette option, il
faut remettre plusieurs ordres dans le format standard SEPA.

Container SEPA
Elargissement du périmètre fonctionnel du protocole conformément aux
normes du DK pour permettre la remise de plusieurs formats SEPA pour
plusieurs comptes de donneur d'ordres dans le cadre d'un type d'ordres.

Option de groupage élargie
Format standard SEPA pour lequel, en profitant des options de groupage
élargies dans le format SEPA, il est possible de remettre des ordres pour
plusieurs comptes de donneur d'ordre.
24
Cette répartition sur plusieurs variantes se justifie par le mode de traitement
optimisé des différentes sociétés de service en informatique.
Quelques-uns des types d'ordres SEPA utilisés en Allemagne sont énumérés
dans le tableau suivant en tenant compte de certaines particularités :
Option
Type
d'ordre
Dénomination SEPA
Formats des
données
SEPA
CRZ
Payment Status Report for Credit Transfer
CDZ
Payment Status Report for Direct Debit
Container
CCC
Credit Transfer Initiation
CRC
Payment Status Report for Credit Transfer
CDC
Direct Debit Initiation
CBC
Payment Status Report for Direct Debit
CCT
Credit Transfer Initiation
CDD
Direct Debit Initiation
Option de
groupage
élargie
En plus des types d'ordres SEPA mentionnés, d'autres types d'ordres ont été
développés avec des caractéristiques différentes de format pour traiter les
transactions commerciales spécifiques du comité de crédit central allemand. Il
s'agit notamment de types d'ordres pour le traitement de la procédure SRZ.
Pour être tout à fait complet à ce sujet, il faut ajouter que pour la transmission
des données SEPA dans le cadre des relevés quotidiens SWIFT avec le type
d'ordres STA, les formats SWIFT MT940 et 942 ont été adaptés.
Pour reproduire les transactions de paiements d'ordres SEPA sans perte, de
nouveaux types d'ordres de téléchargement pour les formats camt (C52, C53
et C54) ont été introduits comme équivalent pour les messages MT94x (STA
et VMK) et les informations sur le chiffre d'affaires DTAUS (DTI).
Pour obtenir plus de détails sur les formats SEPA et leur utilisation en Allemagne, veuillez consulter l'annexe 3 des procédures DFÜ.
6.1.3
Types d'ordres standard pour Upload et Download FUL et FDL
Ces types d'ordres sont surtout utilisés en France et servent au transfert
transparent de fichiers de quelque format qu'ils soient. Contrairement aux
types d'ordres allemands, il n'est pas de savoir quel type de format est transporté. Le type d'ordre FUL ou selon FDL transporte un paramètre de format
plus long, qui donne une instruction spéciale. Ces types d'ordre sont disponibles depuis la version EBICS V2.4. Le type d'ordre FUL (File Upload) est
destiné à la remise et le type d'ordre FDL (File Download) au relevé.
25
6.1.4
Autres types d'ordres
En plus des types d'ordres standards, il est possible d'effectuer la classification suivante concernant l'utilisation dans EBICS :

Types d'ordres déterminés par le système – spécialement pour EBICS
Par exemple : types d'ordres en rapport avec la signature électronique
distribuée (VEU)

Autres types d'ordres supportés déterminés par le système
Par exemple : PTK pour le téléchargement de comptes-rendus client

Types d'ordres réservés pour l'échange de fichiers inter-entreprises
Par exemple : FIN pour l'envoi de EDIFACT-FINPAY


Autres types d'ordres réservés utilisant des formats non standardisés, par
exemple :

FTB pour l'envoi/le téléchargement de fichiers quelconques

FTD pour l'envoi/le téléchargement de fichiers de texte libre
Types d'ordres EBICS optionnels
Par exemple : HVT pour l'appel de détails de transaction VEU

Types d'ordres qui ne sont plus supportés par EBICS
Par exemple : PWA pour l'envoi de modification du mot de passe, puisqu'EBICS n'utilise pas de mot de passe par télétransmission de données.
6.2
Signature électronique distribuée (VEU)
Parmi les nouvelles fonctions que le standard EBICS propose, la signature
électronique distribuée est la plus importante d'entre elles. Sous l'influence
des différents produits disponibles sur le marché, cette évolution fit son apparition dans la spécification DK.
La signature électronique distribuée permet de séparer la remise d'un ordre,
qui est éventuellement déjà porteur d'une première signature, de la validation
effective. La remise d'un fichier de signature peut avoir lieu à un autre moment
et en un autre endroit que la remise de l'ordre. Un numéro d'ordre ou une
identification d'ordre permet d'établir la liaison entre les deux fichiers.
Le procédé se déroule comme suit :
1.
Un participant remet un ordre de type IZV, par exemple, et il ajoute, le cas
échéant, sa propre signature électronique bancaire de catégorie A.
2.
La banque examine l'ordre et vérifie si d'autres signatures sont requises.
Si oui, l'ordre y compris la valeur de hachage est temporairement enregistrée dans la banque.
3.
Un deuxième participant souhaite désormais valider l'ordre et il a obtenu
les données requises telles que le numéro d'ordre et la valeur de hachage
par un autre moyen (la restitution du numéro d'ordre et de la valeur de
26
hachage est externe à EBICS et ne fait pas partie intégrante des composants du serveur du côté banque).
Les options suivantes s'offrent désormais à lui :

Il consulte avec le type d'ordres HVU ou HVZ la liste d'ordres en attente de sa signature et obtient un aperçu indiquant entre autres le
type d'ordres, les signatures portées et manquantes et la longueur de
l'ordre non compressé.

A partir du type d'ordres HVD, il peut obtenir des détails supplémentaires comme les informations de l'abrégé de l'ordre et la valeur de
hachage concernant les ordres.
Cette étape n'a pas lieu lorsque l'aperçu a été relevé avec le type
d'ordres HVZ ; en effet, il fournit déjà toutes les informations détaillées nécessaires.

Après analyse des ordres existants, le participant a désormais la possibilité de

signer avec le type d'ordres HVE

ou d'annuler à l'aide de HVS
4.
Le type d'ordres optionnel HVT permet à la banque de fournir au participant toutes informations concernant les opérations de l'ordre, le libellé de l'opération et l'intégralité de l'ordre.
27
La figure suivante est inspirée de la représentation dans Specification EBICS
[1] à la page 142 et donne une vue d'ensemble compréhensible de cas d'utilisation pourtant assez complexes :
Banque
Signataire
Nouvel ordre
(Signatures supplémentaires
requises)
Donneur d‘ordre / Remettant
(Autorisation SE
complète)
Supprimer
l‘ordre
de la procédure de
traitement
des VEU
Sauvegarde de
l‘ordre dans la
procédure de
traitement des VEU
HVU
(pas d‘ordres à signer)
Exécution
de l‘ordre
(Ordres à signer)
HVD
(fichier d‘ordre
complet requis)
(HVT est supporté)
(HVT
n‘est pas
supporté)
Supprimer l‘ordre
de la procédure de
traitement des VEU
(Détails de l‘ordre
requis)
HVT
(Détail de l‘ordre)
(Valeur de hachage de l‘ordre dans HVD)
HVS
HVT
(fichier d‘ordre complet)
(Annulation)
(Signature
de l‘ordre)
HVE
(pas de signature)
Figure 6:
Déroulement de la procédure VEU
Alors que la VEU est très répandue en Allemagne, elle n'est pas courante en
France.
En France, il est courant d'envoyer les signatures avec l'ordre. Avec le profil
EBICS TS, l'envoi d'un ordre se passe de la manière suivante suivant le
nombre de signatures requises :
Une signature : l'ordre est autorisé avec une signature et est exécuté.
Deux signatures : le système de l'application vérifie si une deuxième signature
est requise et si l'ordre peut être autorisé. Par exemple, il est décidé si un
ordre peut être exécuté dans le cas où une des deux signatures n'est pas
autorisée.
Une signature, deux signatures suivant le plafond : le système de l'application
vérifie, si l'ordre peut être autorisé ou si en fonction du plafond autorisé une
deuxième signature est devenue nécessaire.
28
6.3
Systèmes de portail
Bien que le terme portail n'apparaisse pas de manière explicite dans la spécification EBICS, l'utilisation de la signature d'authentification permet d'intégrer
des tiers lors de la remise d'ordres. EBICS ne va pas aussi loin que le standard FinTS dans lequel les opérateurs de portail ou les intermédiaires sont
pourvus d'un rôle qui leur est propre. La séparation du remettant (participant
technique) et du/des donneur(s) d'ordre permet toutefois de construire des
scénarios de portails simplifiés. En utilisant la catégorie de signature T, cette
instance de transport est aussi accompagnée de règles adaptées à ces systèmes.
6.4
Fonctions optionnelles
Dans les chapitres précédents, nous avons souvent évoqué le fait que certaines fonctions telles que la récupération ou la demande détaillée avec VEU
présentent un caractère optionnel. Certaines des fonctions appartenant à ce
portefeuille sont brièvement décrites dans les paragraphes suivants.
6.4.1
Examen préalable
Conformément à la description détaillée du chapitre Séquences EBICS à la
page 32 une transaction EBICS se déroule en deux étapes. Dans la première
étape, un transfert de fichier (éventuellement très volumineux) est préparé au
moyen d'un bref message et de l'initialisation.
Dans cette étape, il est possible d'effectuer des examens préalables optionnels pour des transactions Upload à volume défini et d'éviter ainsi qu'un transfert non justifié soit autorisé. Les détails suivants peuvent être vérifiés dans le
cadre de l'examen préalable :

Vérification de l'autorisation du compte

Vérification de limite

Vérification de la signature électronique sur la base de la valeur de hachage du fichier
Le volume possible pour l'examen préalable dépend des facteurs suivants :
lesquelles de ces vérifications sont concrètement supportées par la banque et
quelles informations sont livrées ou peuvent être livrées par le produit du
client. Il ne s'agit donc pas ici de se défendre contre des attaques mais d'une
fonctionnalité permettant d'augmenter la sécurité et d'optimiser les besoins en
ressources puisque les uploads incorrects de fichier ne sont même pas démarrés.
29
6.4.2
Données participants
Les types d'ordres suivants permettent au client de télécharger des informations concernant les accords conclus avec la banque :

HAA – Télécharger les types d'ordres disponibles

HPD – Télécharger les données contractuelles EBICS

HKD – Télécharger les données du client et les données du participant du
client

HTD – Télécharger les données du client et les données du participant du
participant
Grâce à ces types d'ordres optionnels, un participant peut configurer son produit pour l'accès bancaire, adapter son environnement en affichant par
exemple seulement les types d'ordres supportés.
Lors du transfert, en plus des paramètres d'accès comme l'URL et le nom de
la banque, les fonctions optionnelles (comme l'examen préalable ou la récupération) supportées par la banque sont également transmises.
Les données du client et du participant renseignent sur les détails suivants
des accords commerciaux :

Informations sur le client, son adresse, par exemple

Informations sur les comptes, numéros de compte et devises, par
exemple

Types d'ordres autorisés

Attributs du participant, identification du participant et catégorie de signature, par exemple
A partir de ces informations très détaillées, un produit du client peut réaliser
une configuration entièrement automatique de l'environnement local. Des informations sur le statut permettent une analyse précise en cas d'erreur.
6.5
EBICS pour les échanges interbancaires
EBICS est également utilisé pour les échanges interbancaires et STEP2.
En Allemagne, les solutions de fournisseurs (par exemple, RVS et Connect:Direct) sont de plus en plus souvent remplacées dans la compensation
bilatérale par EBICS comme standard ouvert.
Un champ d'application dans les échanges interbancaires est la connexion
des instituts à la banque centrale allemande. La banque centrale allemande
propose avec SEPA uniquement deux interfaces :

EBICS avec messages SEPA pacs

SWIFT FileAct
30
La banque centrale allemande a introduit ses propres types d'ordres dans
EBICS et spécifié des formats, par exemple pour PTK.
Un autre champ d'application dans les échanges interbancaires pour les
paiements SEPA est la connexion de banques à STEP2 de EBA Clearing. Fin
2013, EBA Clearing fournit cet accès aux banques connectées également via
EBICS comme alternative à l'accès SWIFT. EBA Clearing a également introduit ses propres types d'ordres dans EBICS et spécifié des formats pour
l'échange de données via EBICS.
Pour l'échange bilatéral entre banques, il n'y a pas encore de consignes.
31
7
Séquences EBICS
Suite à cette description des fonctionnalités d'EBICS, le dernier paragraphe
technique s'intéresse aux séquences réelles du protocole.
Une unité de traitement achevée est qualifiée de transaction. EBICS fait la distinction entre les transactions "upload" et "download". Les transactions upload
servent, par exemple, à remettre des ordres alors que les transactions download sont utilisées pour télécharger les relevés de compte.
Les transactions sont divisées en phases et étapes de transaction. Les
phases de transaction suivantes sont possibles :
Transaction upload
Transactions download
Initialisation
Initialisation
Transfert de données
Transfert de données
Validation
Les phases de transaction peuvent être composées de plusieurs étapes, chacune d'elles consistant d'une demande (EBICS-Request) et d'une réponse
(EBICS-Response) correspondante. Alors que la phase d'initialisation est
constituée d'une seule étape, la phase de transfert de données peut, pour des
raisons de segmentation, contenir plusieurs étapes.
Une transaction est généralement initiée par le produit du client. Le système
du côté banque peut seulement intervenir par initiation, par exemple, en
communiquant une récupération au système du client après une interruption.
La connexion des différentes phases de transaction entre elles se fait à partir
d'une identification de transaction qui est générée par le système de la
banque et communiquée dans la réponse (Response) de l'initialisation.
Chaque demande (EBICS-Request) et chaque réponse (EBICS-Response)
incluent la signature d'authentification du client/participant ou de la banque.
32
La figure suivante présente la séquence d'une transaction EBICS:
UPLOAD
DOWNLOAD
Transaction EBICS
Initialisation
Initialisation
Examen préalable
Examen préalable
Demande
Demande
 Client/
 Client/
participant
participant
Initialisation
Initialisation
 Type d’ordres
 Type d’ordres
Réponse (TrxID)
Réponse (TrxID)
 Compte
Cycle
Cycle
Données de transaction  Limite
Données de transaction
 SE
Demande
Demande
Réponse
Réponse
Validation
Demande
Validation
Réponse
Figure 7:
Déroulement d'une transaction EBICS
Après cette description très théorique sur les séquences de transaction
EBICS, le paragraphe suivant se consacre au positionnement d'EBICS à une
échelle nationale et internationale.
33
8
Positionnement à une échelle internationale
Avec EBICS, le périmètre des procédures DFÜ s'est agrandi, les spécifications concernant la communication et la sécurité règlementent les paiements
de masse dans les offres de services bancaires aux entreprises. A la fois au
niveau national et au niveau international, on trouve des standards qui viennent compléter ou bien qui se recoupent avec EBICS. Certains de ces standards seront brièvement présentés par la suite et seront mis en relation avec
EBICS.
Ce chapitre conclut en offrant une perspective sur l'importance qu'aura ce
standard et sur les développements à suivre.
8.1
FinTS
FinTS (Financial Transaction Services) est également un standard DK ; cependant, l'accent est ici mis sur la banque en ligne avec les clients privés et
professionnels. Les origines de FinTS remontent au système de télétexte
classique, mais, avec l'arrivée de HBCI (Homebanking Computer Interface),
FinTS fut alors complètement découplé de ce standard de communication.
Dans sa forme classique, FinTS reproduit donc des dialogues entre le client et
la banque et traite des transactions individuelles qui sont orientées sur les
messages. FinTS inclut des fonctionnalités telles que données de paramètres
de banque ou d'utilisateur qui sont comparables à celles d'EBICS.
Dans sa version la plus récente 4.0., FinTS mise aussi de manière conséquente sur les standards Internet comme HTTP ou XML. Quant aux procédés
de communication, ils ont été enrichis par des datagrammes sans dialogue et
la communication banque  client.
Dans le domaine de la sécurité, FinTS supporte à la fois les signatures électroniques ainsi que le procédé PIN/TAN dans diverses variantes.
Comme dans EBICS, les formats courants des opérations de paiements
(DTA, DTAZV, SEPA et SWIFT) sont aussi supportés par FinTS ; ils sont qualifiés d'opérations commerciales. Le comité DK veille à ce que les versions et
les contenus de ces formats soient utilisés de la même manière par les deux
standards. En outre, FinTS a la possibilité de définir de nombreuses opérations commerciales allant de l'ordre de virement permanent, en passant par
l'argent à terme, jusqu'aux messages libres avec la banque. Ces opérations
commerciales permettent (au moins) d'établir un standard national là où il
n'existe aucune définition internationale.
Dans le domaine des clients professionnels, le client FinTS dispose de sa
propre implémentation de la signature électronique distribuée (VEU), sauf
pour les opérations commerciales identiques à EBICS, par exemple, pour collecteurs ou opérations de compte. Ce qui manque actuellement au standard,
ce sont toutes les possibilités de paiements de masse comme la segmentation
ou la récupération.
34
En résumé, il faut considérer FinTS comme un complément à EBICS. Cela est
valable pour tous les contextes où clients professionnels et clients-entreprises
sont une cible commune, étant donné qu'ils réalisent leurs transactions financières dans les deux mondes. Ainsi, une entreprise réalisera des paiements
de masse mais sera aussi active dans le négoce de valeurs ou les opérations
sur titre. Pour certains types d'opération, le lieu de l'opération sera même déterminant (dans le service de la comptabilité ou par un gérant de société en
déplacement, par exemple).
Les nouveaux produits se sont déjà adaptés à cette situation et proposent
avec BCS-FTAM et FinTS deux protocoles de communication.
Pour un examen plus profond du standard FinTS, nous recommandons la lecture du compendium FinTS qui peut être téléchargé sous fints.org :
www.fints.org
8.2
SWIFT
Si vous utilisez non seulement EBICS mais aussi SWIFT, voici les structures :

les formats classiques FIN pour les opérations de paiement internationales

les activités XML- et ISO de SWIFT

SWIFTNet comme propre standard de communication

SWIFT FileAct comme standard de transfert de fichiers
Il y a peu à dire sur les formats FIN classiques tels que MT904. Ils sont
stables et seulement soumis à des modifications légales ; ils sont intégrés de
manière identique dans le protocole respectif des deux principaux standards
allemands EBICS et FinTS. Cela engendre une certaine indépendance de
SWIFT, dans la mesure où le travail s'effectue seulement à partir de référencements.
Le fait qu'une version des formats basée sur XML soit disponible avec SWIFT
XML ne modifie en rien la séparation stricte des tâches entre les standards.
Avec la création des formats XML, SWIFT a procédé de manière très abstraite
et a quasiment effectué un "Reverse Engineering" du monde existant. Suite à
un travail méticuleux sur plusieurs années utilisant UML, des modèles de processus pour les opérations de paiement internationales ont été confectionnés
; aujourd'hui, ils servent à générer les formats FIN et XML. Grâce à cette approche méthodique, SWIFT s'est hissé vers le haut dans le domaine des
standards internationaux d'opération financière et a réussi à positionner les
composantes centrales de ces modèles comme standard ISO 20022.
Cette présence au plan international permet à SWIFT d'être associé à d'autres
standards internationaux tels que TWIST, IFX ou SEPA. Il est aussi en partie
responsable pour l'évolution des "Payment-Kernels" comme modèle d'opération financière généralisé sous le patronage du OAGi.
35
Alors que les efforts ISO de SWIFT devraient influencer très fortement l'évolution des formats d'opération financière, le protocole de transport correspondant, servant de base à SWIFTNet, est plutôt d'importance secondaire et doit
être considéré comme une évolution propriétaire. SWIFTNet possède certainement un taux de pénétration stable dans les opérations interbancaires, mais
ne joue quasiment aucun rôle dans la relation client-banque.
Ainsi, la principale caractéristique du standard SWIFT est d'agir en tant qu'instance pour la publication et la mise à jour des formats de paiements; cela décrit sa position par rapport à EBICS, qui devrait rester stable dans les années
à venir.
Vu que la France est engagée dans SEPA, le réseau SWIFT a également une
certaine influence en France. SWIFT FileAct est également de plus en plus
utilisé comme protocole de transfert de fichiers. Cependant, on peut conclure
que SWIFT et EBICS peuvent aisément cohabiter.
www.swift.com
8.3
ETEBAC
Le standard français ETEBAC (Echange Télématique Banque-Clients) peut
être considéré comme standard complémentaire d'EBICS. L'exécution de
paiements de masse et le téléchargement des montants sont également possibles. Les entreprises, qui sont implantées en France, utilisent souvent des
produits avec un module ETEBAC.
La France a décidé d'utiliser le protocole EBICS pour remplacer ETEBAC
quand le réseau X.25 aura disparu début 2012. La plupart des banques françaises sont déjà passées au protocole EBICS. EBICS V2.5 contient toutes les
fonctionnalités nécessaires pour une migration de ETEBAC vers EBICS.
C'est avec beaucoup d’impatience qu'on attend la réaction des autres pays de
l'UE concernant EBICS après avoir franchi cette première étape sur le plan international.
www.etebac.org
8.4
Perspective
Cette description des standards nous permet de conclure qu'il n'existe au jour
d'aujourd'hui aucun standard industriel comparable (pas même sur le plan international).
On peut donc en déduire que EBICS sera le standard de référence pour les
opérations de paiement de masse.
Dans ce contexte, il est important de rappeler qu'EBICS a élargi le périmètre
fonctionnel du standard et apporte des solutions aux faiblesses que pouvait
présenter les anciens standards. L'introduction d'EBICS a été rapide et généralisée, la souplesse du concept de migration joue un rôle décisif.
36
Une autre question intéressante est de savoir comment le standard va être
adopté au sein de l'Union Européenne et par les banques européennes.
Quelques projets sont connus mais il n'est pas encore possible pour le moment de donner des informations précises à ce sujet.
Le dernier chapitre illustre à titre d'exemple la mise en œuvre d'EBICS et sa
migration sur la base d'une famille de produit concrète.
37
9
Mise en œuvre
Après l'aperçu des fonctionnalités d'EBICS et la représentation du scénario
d'ensemble, ce dernier chapitre s'attache à illustrer une mise en œuvre du
standard et de quelle manière l'ancien et le nouveau standard interagissent.
A cet effet, la famille de produit TRAVIC (Transaction Services), dont les différents modules peuvent servir à structurer un tel scénario d'ensemble, est présentée.
TRAVIC est composé des éléments suivants, qui peuvent être combinés suivant le besoin :
Composants
Description
TRAVIC-Corporate
comprend toutes les fonctionnalités centrales côté
banque pour BCS-FTAM et EBICS ou encore
EBICS interbancaire.
TRAVIC-Link
met à disposition un portefolio de transfert de fichiers qui permet, par exemple, de transmettre à
une banque via EBICS des ordres avec signatures
électroniques bancaires.
EBICS-Mobile
permet aux utilisateurs de valider/signer des fichiers d'ordre pour des opérations de paiement nationales et internationales disponibles auprès de
l'institut financier lorsque, par exemple, en déplacement.
TRAVIC-Services
API qui contient toutes les fonctions EBICS du côté
client – intégré dans les produits du client.
TRAVIC-Web
propose un Client EBICS complet basé en Java en
interaction avec les composants de TRAVICCorporate.
TRAVIC-Port
mise en œuvre d'un portail EBICS pour l'exécution
d'opérations de paiement à l'aide d'une infrastructure Portlet
TRAVIC-Retail
complète la structure et met à disposition toutes les
fonctionnalités centrales pour un système FinTS du
côté banque.
A l'exception du composant Retail qui n'est pas pris en considération dans ce
contexte, les différents modules sont présentés de manière plus détaillée dans
ce qui suit.
38
9.1
TRAVIC-Corporate
Les fonctionnalités de TRAVIC-Corporate couvrent EBICS ainsi que BCSFTAM. Dans la mesure du possible, on veille à une récupérabilité de manière
à permettre une migration souple et une administration commune, comme le
montre la figure suivante :
CLIENT
TRAVIC-Link
BCS-FTAM
ONGUM/IP
TCP/IP
Infrastructure
Internet
Format
Plafond
Compte
ONGUM/IP
EBICS
1
TC/IP / TLS
EBICS
TRAVIC-Web
TRAVIC-Port
Navigateur
Figure 8:
HTTPS
HTML
11
0 11
1 01
TRAVIC-Port
0
Engine
Security
TRAVICCorporate
TRAVIC-Link
EBICS-Kernel
VEU
Serveur EBICS
Client-EBICS
Système transfert de paiement
RNIS
FTAM
BCS-FTAM
Client-BCS
BANQUE
Composants de la famille de produit TRAVIC
TRAVIC-Corporate met à disposition toutes les fonctions décrites dans
EBICS, notamment les composants optionnels comme l'adoption de clé de
l'environnement BCS, par exemple. Des outils fournis séparément permettent
aussi l'adoption de données de base et de clés cryptographiques provenant
des mises en œuvre BCS d'autres fabricants dans le cadre d'une migration.
TRAVIC-Corporate est disponible sur plusieurs plates-formes UNIX et pour
IBM z/OS afin de pouvoir sélectionner l'environnement optimal pour chaque
type d'utilisation.
9.2
TRAVIC-Link
TRAVIC-Link est un produit de transfert de fichiers universel pouvant être intégré dans divers scénarios.
39
Dans le cadre des opérations de paiement électroniques pour les clients entreprises, TRAVIC-Link occupe le rôle du système client conformément à l'accord DFÜ avec les clients. Dans ces scénarios, TRAVIC-Link supporte les
standards BCS et EBICS. TRAVIC-Link complète les systèmes de comptabilité financière au niveau du transfert automatique des ordres et du téléchargement automatique et du routage des relevés. Les fichiers d'ordre à transmettre
à une banque peuvent être porteurs de signatures électroniques avant même
que le transfert n'ait eu lieu.
Le protocole de communication ONGUM-IP intégré dans TRAVIC-Link permet
des transferts de fichiers à contenus quelconques entre plusieurs systèmes
TRAVIC-Link.
Une autre fonctionnalité de TRAVIC-Link est la communication par l'intermédiaire de ce qu'on appelle logiciel standard. TRAVIC-Link propose les interfaces correspondantes.
Les procédés ou modules de communication suivants sont actuellement supportés par TRAVIC-Link.



9.3
e-banking dans l'environnement des clients-entreprises

EBICS

BCS-FTAM

SWIFT FileAct

SWIFT FIN
Protocoles de transfert de fichiers intégrés

ONGUM-IP

Secure-FTP

FTPS

FTAM (natif)
Logiciel standard intégrable via interfaces

rvs (gedas deutschland GmbH)

CONNECT :Direct (Sterling Commerce)

UDM (Stonebranch)

CFT (Axway)
EBICS-Mobile
EBICS-Mobile est une application mobile pour la signature d'ordres de paiement qui ont été soumis auprès des instituts financiers par procédure EBICS.
Les informations de compte (soldes et transactions) continuent d'être affichées.
40
L'application est destinée aux banques et grandes entreprises qui veulent offrir à leurs clients ou leurs salariés la possibilité de valider des ordres de
paiement de façon mobile, c'est-à-dire en dehors du site de l'entreprise.
EBICS-Mobile
9.4

est multi-bancaire car équipé d'interfaces standardisées et du protocole
d'échange EBICS sur le serveur Gateway

peut être configuré selon vos besoins

offre une sécurité d'exploitation par des signatures électroniques et des
transferts de messages cryptés

intègre une fonction push pour les banques qui opèrent TRAVICCorporate
API TRAVIC-Services pour EBICS
Alors que les fabricants de mises en œuvre d'ordinateurs bancaires s'appliquent ardemment à adapter leurs produits au standard EBICS, les fabricants
de produits du client doivent faire face au problème suivant :
Des centaines de pages de documentation doivent être modifiées et intégrées
seulement dans le but d'ajouter une nouvelle voie de transport à un produit
d'opération financière, par exemple. A l'heure actuelle, nous ne savons pas
dans quelle proportion les caractéristiques optionnelles d'EBICS seront utilisées et donc si on doit les prendre en compte dès le départ.
Une interface API TRAVIC-Services pour EBICS aide à résoudre ce problème
; elle met à disposition une Suite EBICS complète et ergonomique pour une
parfaite intégration côté client.
9.5
TRAVIC-Web
Pour les clients qui recherchent un produit client disposant de fonctions de
Cash-Management, TRAVIC-Web est la solution. L'application Java sert à
saisir et à gérer des clients, des participants, des banques et des ordres pour
les envoyer ensuite par EBICS à la banque. Cela comprend également le
support de dispositifs de sécurité comme les cartes à puce ou les disquettes.
9.6
TRAVIC-Port
Dans le domaine de la signature distribuée et lorsque le nombre d'ordres à
saisir et à remettre n'est pas important, une intégration de type portail avec
EBICS est le complément idéal d'une gamme de prestation proposée par une
banque. Par conséquent, il n'est pas étonnant que de plus en plus de
banques intègrent des portails de clients-entreprises dans leur portefolio d'ebanking.
TRAVIC-Port utilise EBICS-Kernel comme noyau central de la communication
multibancaire pour mettre en place le protocole EBICS. Ces fonctions princi-
41
pales sont enrichies par des services Web pour mettre en place la structure
technique permettant de réaliser des opérations de paiement et de gérer le
profil des utilisateurs, ce qui permet aux clients d'effectuer les tâches administratives.
Pour faciliter l'intégration dans des solutions de e-banking déjà installées, la
visualisation des fonctions du portail a lieu par des interfaces de services
Web. Cela signifie que la présentation peut être effectuée par la banque ou
son prestataire de technologie de l'information. TRAVIC-Port dispose aussi de
la fonctionnalité Single-sign-on qui permet l'intégration de portails dans
TRAVIC-Port et inversement. TRAVIC-Port est également fournie avec sa
propre interface d'utilisateur basée sur portlet.
Avec ces moyens, il est possible d'édifier, avec peu d'efforts de mise en
œuvre, la partie transactionnelle d'un portail de clients-entreprises et de l'enrichir par d'autres fonctions techniques. En outre, l'utilisation de la technologie
Portlet offre au client une représentation attractive et flexible.
42
Bibliographie
DFÜ-Abkommen
Appendix 1: Specification EBICS
Version 2.5 from 16. May 2011
ZKA (Organisme de normalisation bancaire allemand)
[2]
DFÜ-Abkommen
Appendix 2: Specification FTAM
Version 2.0 from 3. Nov 2005 (obsolete since 1. January 2011)
[3]
DFÜ-Abkommen
Appendix 3: Specification of Data Formats
Version 2.7 from 25. March 2013
[4]
EBICS Implementation Guide
EBICS-Version 2.5 from 16. May 2011
[5]
Security concept EBICS
Version 1.4 from 17. August 2005
[6]
FinTS V4.0
Version 4.0 from 22. June 2004
[1]
43
Liste des abréviations
BCS
Banking Communication Standard
BPD
Bank Parameter Data (données contractuelles EBICS)
CFONB
Comité Français d’Organisation et de Normalisation Bancaire
DFÜ
Datenfernübertragung (télétransmission de données)
DK
Comité Central de Crédit allemand (précédemment ZKA)
DTA
Datenträgeraustausch (échange du support de données)
EBICS
Electronic Banking Internet Communication Standard
ETEBAC
Echange TElematique BAnque-Clients
SE
Signature électronique
FIX
Financial Information Exchange
FTP
Filetransfer Protocol
HTTP
Hypertext Transport Protocol
FinTS
Financial Transaction Services
FTAM
Filetransfer Access and Management
HBCI
HomeBanking Computer Interface
IFX
Interactive Financial Exchange
TI
Technologie de l'information
ISO
International Standards Organisation
OAGi
Open Application Group
OFX
Open Financial Exchange
OSI
Open Systems Interconnect
SEPA
Single European Payment Area
SRZ
Centre de traitement de données
SSL
Secure Socket Layer
44
Transport Communication Protocol/Internet Protocol
TLS
Transport Layer Security
UML
Unified Modelling Language
TWIST
Transaction Workflow Innovation Standards Team
VEU
Verteilte Elektronische Unterschrift (signature électronique distribuée)
W3C
Consortium WWW, commission de standardisation Internet
XML
Extensible Markup Language
ZKA
Zentraler Kreditausschuss (Organisme de normalisation bancaire
allemand - aujourd'hui DK)
TCP/IP
45
Liste des illustrations
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Structure de la documentation sur le protocole EBICS ...................... 6
Scénario d'ensemble BCS/EBICS pour illustrer la migration d'un
ancien protocole vers EBICS ............................................................. 8
Schémas XML EBICS ...................................................................... 12
Modèle de données .......................................................................... 15
Procédure de signature EBICS ........................................................ 17
Déroulement de la procédure VEU .................................................. 28
Déroulement d'une transaction EBICS ............................................. 33
Composants de la famille de produit TRAVIC .................................. 39
46
Moorfuhrtweg 13
22301 Hamburg
Tel.: +49 40 227433-0
Fax: +49 40 227433-333
E-Mail: [email protected]
Internet: www.ppi.de
Copyright
Ce document établi par PPI AG Informationstechnologie bénéficie de la législation sur les droits d'auteur par rapport aux
tiers. Tous les droits, également ceux relatifs à la traduction, la reproduction ou la copie du document, que ce soit intégralement ou partiellement, nécessitent l'autorisation de PPI AG Informationstechnologie.
Dans la plupart des cas, les désignations de logiciel et de matériel mentionnées dans le présent manuel sont également
des marques déposées et soumises en tant que telles aux dispositions légales.

Compendium EBICS - EBICS-Blog

Transcription

Documents pareils

EN BREF EN DETAIL

Logiciel Sage Moyens de Paiement Banque Liberté

ebics ts - Banque Kolb

Logiciel web et mobile pour votre gestion multi-bancaire

Communiqué de presse