Compendium EBICS

Transcription

Compendium EBICS

Compendium EBICS
Electronic Banking Internet Communication Standard
Version du document :
5
Date :
20.06.2016
Informations complémentaires :
Michael Lembcke
[email protected]
Compendium EBICS – Electronic Banking Internet Communication Standard
Préface
À 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 non
seulement sur le marché allemand, mais aussi en France et en Suisse – et
EBICS a de bonnes chances de devenir le standard européen en matière de
paiements des entreprises et d'échanges interbancaires dans de nombreux
autres pays.
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 est désormais achevée. La spécification EBICS actuelle est disponible dans sa version 2.5.
Créée le 17 juin 2010 à Bruxelles, la société EBICS SCRL s'est donné pour
objectif de protéger la marque et de promouvoir le standard EBICS. Les
membres de EBICS SCRL sont issus des fédérations bancaires allemandes,
regroupées dans le Comité Central de Crédit (DK), des banques françaises,
représentées par le Comité Français d’Organisation et de Normalisation Bancaire (CFONB), des banques helvétiques ainsi que de Swiss Infrastructure
and Exchange (SIX).
Version du document 5 du 20.06.2016
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. Les récentes versions du protocole s'appuient d'ailleurs justement sur une infrastructure de type PKI (Public Key Infrastructure).
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 notre examen. Pour conclure,
nous illustrerons la mise en œuvre d'EBICS à l'exemple de la gamme de produits 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 se révélant assez complexes. Nous vous souhaitons une agréable lecture !
PPI AG Informationstechnologie, juin 2016
1
Sommaire
1
2
3
Introduction ........................................................................................................ 5
1.1
Exigences EBICS ............................................................................................................ 5
1.2
Structure de la spécification .......................................................................................... 7
Scénario d'ensemble EBICS ............................................................................. 9
2.1
Interaction des protocoles ............................................................................................. 9
2.2
Prise en considération des produits ........................................................................... 10
2.3
Portails........................................................................................................................... 10
2.4
2.4.1
Migration........................................................................................................................ 10
Migration EBICS en France ............................................................................................ 11
Communication et protection de l'infrastructure .......................................... 12
3.1
HTTPS et TLS – Transport Layer Security .................................................................. 12
3.2
XML – Extensible Markup Language........................................................................... 12
3.3
Optimisation de la communication ............................................................................. 14
Modèle de données .......................................................................................... 15
5
Sécurité............................................................................................................. 17
4
6
5.1
Sécurité de l'infrastructure .......................................................................................... 17
5.2
5.2.1
5.2.2
Procédure de signature ................................................................................................ 18
Signature d'authentification X001 ou X002 ..................................................................... 18
Signatures d'ordre (SE) selon A004 ou A005/A006........................................................ 19
5.3
5.3.1
5.3.2
Initialisation ................................................................................................................... 20
Certificats en France....................................................................................................... 20
5.3.1.1
Le profil de remise T sur la base de certificats ......................................... 21
5.3.1.2
Profil d'autorisation TS ............................................................................. 21
5.3.1.3
Lettre INI comme scénario de repli .......................................................... 21
Lettre INI en Allemagne .................................................................................................. 22
5.4
5.4.1
5.4.2
Procédure de chiffrement ............................................................................................ 22
TLS – Transport Layer Security ...................................................................................... 22
Chiffrement E001 et E002 .............................................................................................. 23
Fonctions techniques d'EBICS ....................................................................... 24
2
Types d'ordres .............................................................................................................. 24
Les opérations de paiement SEPA ................................................................................. 24
Opérations de paiement internationales et relevés quotidiens ....................................... 26
Types d'ordres standards pour téléversement (FUL) et téléchargement (FDL).............. 26
Autres types d'ordres ...................................................................................................... 27
6.2
Signature électronique distribuée (VEU) .................................................................... 27
6.3
Systèmes de portail ...................................................................................................... 29
6.4
6.4.1
6.4.2
Fonctions optionnelles ................................................................................................ 30
Examen préalable ........................................................................................................... 30
Données participants ...................................................................................................... 30
6.5
6.5.1
6.5.2
6.5.3
EBICS pour les échanges interbancaires ................................................................... 31
Connexion au clearer SEPA de la Deutsche Bundesbank ............................................. 31
Connexion à la plateforme STEP2 d'EBA Clearing ........................................................ 31
Échanges interbancaires bilatéraux................................................................................ 32
7
Séquences EBICS ............................................................................................ 33
8
Positionnement à l'échelle internationale ...................................................... 35
9
6.1
6.1.1
6.1.2
6.1.3
6.1.4
8.1
FinTS .............................................................................................................................. 35
8.2
SWIFT............................................................................................................................. 36
8.3
ETEBAC ......................................................................................................................... 37
8.4
PeSIT-IP ......................................................................................................................... 37
8.5
SFTP et FTP(S) .............................................................................................................. 37
8.6
Perspectives .................................................................................................................. 38
Mise en œuvre .................................................................................................. 39
9.1
TRAVIC-Corporate ........................................................................................................ 40
9.2
TRAVIC-Link .................................................................................................................. 40
9.3
EBICS-Mobile ................................................................................................................ 41
9.4
API TRAVIC-Services pour EBICS ............................................................................... 42
9.5
TRAVIC-Web .................................................................................................................. 42
9.6
TRAVIC-Port .................................................................................................................. 42
Bibliographie ............................................................................................................. 44
Liste des abréviations .............................................................................................. 45
3
Liste des illustrations ............................................................................................... 47
4
1
Introduction
1.1
Exigences EBICS
La devise « évolution au lieu de révolution » résume parfaitement l'objectif
poursuivi lors de 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 œuvre 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 parties 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. À 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 le havre de sécurité des
réseaux presque fermés (qui utilisent les standards
précédents) devait être abandonné, il ne devait en
aucun cas en résulter des failles de sécurité. Cela
concerne certains aspects de la mise en œuvre,
comme 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é.
5
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é
À 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 originelle. De cette manière, il est possible, dans le domaine des platesformes, de recourir à des produits standards ou à
des composants 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 la future expansion d'EBICS. De nombreux pays européens affichent des particularités nationales. Et
presque tous ont les mêmes aspirations : maintenir
l'ancien protocole en parallèle avec le nouveau et
rendre la migration la plus simple possible pour les
clients et les banques.
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 l'égide 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.
6
1.2
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,
paramètre de format
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 spécification EBICS et intégration dans l'accord DFÜ allemand
L'annexe 1 « EBICS » et ses deux addendas sont gérés sous l'égide de la société EBICS et publiés 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
« Implementation Guide » 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 allemandes. S'agissant du secteur bancaire helvétique, SIX Payment Services
a défini l'utilisation d'EBICS en Suisse dans un guide d'implémentation ad
hoc. Un autre document intitulé « ISO 20022 Payments Business Rules
suisses » regroupe par ailleurs les règles d'utilisation des paiements
ISO 20022 en Suisse. Les exigences de souplesse de migration, de facilité de
déploiement et de sécurité du système semblent donc parfaitement respectées.
L'annexe 3 de l'accord DFÜ est consacrée aux formats de données SWIFT et
SEPA en Allemagne, et ne concerne pas les activités EBICS à l'échelle européenne.
7
L'annexe 2 consacrée au protocole FTAM n'est plus d'actualité, mais complète la documentation par souci d'exhaustivité.
8
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 standard national 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
9
fait abstraction des frais d'exploitation surélevés engendrés par l'utilisation
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 était 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 porte-folio. 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 un navigateur Internet. Comme il
s'appuie sur une technologie Internet, il est évident qu'EBICS, en tant que
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, un rôle dédié aux exploitants de portails n'étant pour l'heure pas prévu.
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. Étant 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.
10
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 restent à résoudre est l'initialisation EBICS d'un participant existant déjà initialisé auparavant 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és 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 est désormais désactivé. L'utilisation du protocole
ETEBAC 3, largement répandu, est donc devenue impossible et la migration
vers EBICS indispensable.
Théoriquement, une solution intermédiaire utilisant le protocole ETEBAC 5
(basé sur TCP/IP) était certes envisageable, mais cela n'a eu aucune influence sur l'introduction d'EBICS. Reposant sur des certificats d'authentification et utilisé par seulement quelques milliers de clients enregistrés, ETEBAC 5 était en effet bien moins populaire.
11
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 par 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 presque inconcevable 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 vient remplacer 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-
12
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.
13
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.
14
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.
15
La figure suivante est une représentation simplifiée du modèle de données :
CLIENT
Catégorie de signature
Accord
Participant




STA
11
0 11
1 01
1
Types
AZV
0
IZV
11
0 11
1 01
1
Figure 4:
Individuelle
Première
Deuxième
Transport
0
11
0 11
1 01
1
0
d‘ordre
Compte 2
Compte 1
Comptes-client
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.
16
5
Sécurité
La version précédente 2.4 d'EBICS avait introduit les nouvelles procédures de
sécurité A005 et A006, respectivement X002 et E002. Mais plus importantes
encore sont les stipulations concernant l'obligation de mettre en place ces
procédures – une nouveauté liée à l'introduction du standard EBICS.
Les dispositifs de sécurité physiques, comme les cartes à puce, les disquettes
et plus récemment les clés USB, ne sont ici pas considérés. Sur ce point également, EBICS ne formule aucune exigence et laisse les clients, ainsi que les
éditeurs des produits clients, faire leurs propres choix. À l'aide de la classification suivante, le système client peut déterminer le support de stockage utilisé
par le client :

Aucune indication

Disquette

Carte à puce

Autre support de stockage

Support de stockage non interchangeable
La France a opté pour des exigences particulières s'agissant du profil TS :
l'Implementation Guide impose ici en effet l'utilisation de tokens HW spécifiques, mis à disposition par une autorité de certification (CA). Le transfert
s'effectue de manière implicite par le biais du certificat X.509 (voir plus bas).
5.1
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 (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.
À 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é 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.
17
 Vous trouverez plus de détails sur les propriétés de protocole
au chapitre Séquences EBICS à la page 33.
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 :
Signatur d‘authentification
Redondance
Initialisation
EBICS SE
11
0 11
1 01
Hachage
Signature XML
1
Redondance
Ordres
0
Hachage
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, page33 ).
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
18
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
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 quelle que soit sa position.
Pour des raisons de migration, EBICS requiert 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ée 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
19

Procédure de valeur de hachage RIPEMD160
Aujourd'hui tout à fait courantes et depuis EBICS V2.4 rendues obligatoires,
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.
À 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 garantit donc son utilisation au niveau international.
Certains pays (comme la France et la Suisse) imposent à leurs institutions financières d'utiliser des longueurs de clé fixes (2048 bits).
5.3
Initialisation
Avant de pouvoir utiliser une paire de clés, 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 suivant 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
20
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.
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 l'heure, 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 l'ancien
standard ETEBAC 3, qui était 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 autosigné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 ETEBAC 5. Dans ce
cas, le certificat pour la clé de signature doit être délivré et signé par une
autorité de certification, qui 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'exclut 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
21
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
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. À partir de 2009, le procédé AES
recommandé par BSI sera introduit pour E002.
5.4.1
TLS – Transport Layer Security
TLS a pris la relève de 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).
22
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.
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'algorithme 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).
23
6
Fonctions techniques d'EBICS
Pour l'essentiel, EBICS n'est guère différent des standards précédents (BCSFTAM et ETEBAC) sur le plan de la technicité. Les types d'ordres définis en
Allemagne ont ainsi été conservés dans EBICS. En France en revanche, les
types d'ordres Upload et Download sont complétés par des informations spécifiques au type d'ordre par le biais de paramètres de format de fichier.
Simultanément, EBICS est souvent bien supérieur à ses prédécesseurs et
ouvre de nouveaux champs d'application pour les clients.
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 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 ou
camt-XML pour les opérations comptabilisées et les avis des opérations
de compte
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 fédérale 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.
24
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
Élargissement 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'ordre.

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.
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 de
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
25
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.2
Opérations de paiement internationales et relevés quotidiens
L'aperçu suivant présente quelques exemples de formats de types d'ordres
liés standardisés en Allemagne :
6.1.3
AZV
Envoyer un ordre de paiement international en format
disquette
AZ2
bande magnétique (champ longueur d'enregistrement
2 octets)
AZ4
bande magnétique (champ longueur d'enregistrement
4 octets)
STA
Télécharger
MT940)
VMK
Télécharger transactions prévisionnelles à court terme
(SWIFT MT942)
VML
Télécharger transactions prévisionnelles à long terme
(SWIFT MT942)
ESR
Téléchargement d'informations ESR (spécifique à la
Suisse)
relevés
quotidiens
SWIFT
(SWIFT
Types d'ordres standards pour téléversement (FUL) et téléchargement
(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, le nom du type d'ordre ne donne pas d'indication
sur le format transporté. Le type d'ordre FUL ou 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
26
Upload) est destiné à la remise et le type d'ordre FDL (File Download) au relevé. La structure et les paramètres de format à utiliser sont documentés avec
les types d'ordres en annexe de la spécification EBICS.
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
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
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é 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 ha-
27
chage par un autre moyen (la restitution du numéro d'ordre et de la valeur
de 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é.

À 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.
28
La figure suivante est inspirée de la représentation figurant dans Specification
EBICS [1] et donne une vue d'ensemble compréhensible des interrelations,
pourtant assez complexes :
Banque
Nouvel ordre
(Signatures supplémentaires
requises)
Signataire
HVZ
(pas d‘ordres à signer)
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)
(Ordres à signer)
Exécution
de l‘ordre
HVD
(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)
(Annulation)
HVT
(fichier d‘ordre
complet)
HVT
(Détail de l‘ordre)
(Valeur de hachage de l‘ordre dans HVD)
HVS
(fichier d‘ordre
complet requis)
(Signature
de l‘ordre)
HVE
(pas de signature)
Figure 6:
Déroulement de la procédure VEU
Très répandue en Allemagne, la VEU est à ce jour peu usitée 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, en fonction du
nombre de signatures requises :
Une signature : une seule signature suffi pour autoriser l'ordre et il est exécuté.
Deux signatures : l'application vérifie si une deuxième signature est requise et
si l'ordre est doté d'une autorisation suffisante. Par exemple, il est décidé si
un ordre peut être exécuté lorsque l'une des deux signatures n'est pas autorisée.
Une signature, deuxième signature en fonction du plafond : le système de
l'application vérifie si l'ordre est doté d'une autorisation suffisante ou si – en
fonction du plafond – une deuxième signature est requise.
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 stan-
29
dard 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 33, une transaction EBICS se déroule en deux étapes. Dans la première, 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.
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 paramètres bancaires
HKD
Télécharger les données du client et du participant du
client
30
HTD
Télécharger les données du client et 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
À 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.
6.5.1
Connexion au clearer SEPA de la Deutsche Bundesbank
En Allemagne, les solutions d'éditeurs (p. ex. RVS et Connect:Direct) pour le
clearing bilatéral sont de plus en plus remplacées par le standard ouvert que
constitue EBICS.
Un champ d'application dans les échanges interbancaires est la connexion
des instituts à la banque fédérale allemande. Cette dernière propose avec
SEPA uniquement deux interfaces :

EBICS avec messages SEPA pacs

SWIFT FileAct
La banque fédérale allemande a introduit ses propres types d'ordres dans
EBICS et spécifié des formats, par exemple pour PTK.
6.5.2
Connexion à la plateforme STEP2 d'EBA Clearing
Un autre champ d'application dans les échanges interbancaires pour les
paiements SEPA est la connexion de banques à STEP2 d'EBA Clearing. Depuis la fin 2013, EBA Clearing propose aux banques connectées également
31
un accès via EBICS (en tant qu'alternative à SWIFT). EBA Clearing a aussi
introduit ses propres types d'ordres dans EBICS et spécifié des formats pour
l'échange de données via EBICS.
6.5.3
Échanges interbancaires bilatéraux
La spécification EBICS ne donne pas de directives s'agissant des échanges
interbancaires bilatéraux. En principe, ce sont les partenaires qui établissent
ici les conventions bilatérales. Ces dernières concernent, outre le traitement
des retours (transactions R), également les questions d'ordre opérationnel,
comme le transfert de responsabilité et les SLA spécifiques (p. ex. la taille
maximale des fichiers).
Sur le plan des types d'ordres et des spécifications techniques, ce sont généralement les dispositions édictées par EBA Clearing pour la connexion à
STEP2 qui sont mises en œuvre.
32
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 (requête EBICS) et chaque réponse (réponse EBICS) inclut
la signature d'authentification du client/participant ou de la banque.
33
La figure suivante présente la séquence d'une transaction EBICS :
UPLOAD
Transaction EBICS
Initialisation
Demande
DOWNLOAD
Examen préalable
Initialisation
Réponse (TrxID)




Données de transaction

Client/
participant
Type d‘ordres
Compte
Limite
SE
Demande
Demande
Initialisation
Réponse (TrxID)
Examen préalable


Client/
participant
Type d‘ordres
Demande
Réponse
Initialisation
Réponse
11
0 11
1 01
1
0
11
0 11
1 01
1
Validation
0
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 à
l'échelle nationale et internationale.
34
8
Positionnement à l'é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. À 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.
35
En résumé, il faut considérer FinTS comme un complément à EBICS. Cela
est valable pour tous les contextes où clients professionnels et clientsentreprises 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 MT940. 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.
36
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 également sa position par rapport à EBICS – une situation qui ne devrait guère évoluer 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 (Échange 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 d'ETEBAC vers EBICS.
8.4
PeSIT-IP
Standard d'éditeur développé en France, PeSIT peut être considéré comme
solution complémentaire à EBICS, notamment dans les échanges interbancaires, mais aussi pour les grandes entreprises. Il permet lui aussi l'exécution
de paiements de masse et le téléchargement des montants. En France, les
entreprises utilisent bien souvent des produits dotés d'un module PeSIT-IP en
plus d'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.
8.5
SFTP et FTP(S)
En Europe, certains protocoles de transfert de fichiers basés sur FTP sont
également utilisés pour les opérations de paiement. Contrairement aux protocoles abordés précédemment, ceux-ci ne gèrent toutefois que le transport et
37
ne permettent aucune sorte de traitement. Ils ne sont en outre plus conformes
aux exigences actuelles en matière de sécurité des opérations de paiement.
Très répandus en tant que logiciels système, SFTP et FTPS sont largement
utilisés dans le transfert de fichiers.
8.6
Perspectives
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) à EBICS.
Il est donc plus que probable qu'EBICS va s'imposer en tant que standard de
référence pour les opérations de paiement de masse en Europe.
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 pouvaient
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.
Plus important encore : dans quelle proportion le standard va-t-il être adopté
au sein des États membres et des banques de l'Union européenne ?
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 produits concrète.
38
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.
À cet effet, la famille de produits 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 selon les besoins :
Composants
Description
TRAVIC-Corporate
Intègre toutes les fonctionnalités centrales côté
banque pour EBICS et EBICS interbancaire, ainsi
que les canaux PeSIT et SFTP/FTP(S).
TRAVIC-Link
Met à disposition un ensemble exhaustif de solutions de transfert de fichiers qui permet p. ex. de
transmettre des ordres dotés de signatures électroniques bancaires à une banque par le biais
d'EBICS ou d'un autre protocole de transfert.
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 alors qu'ils sont en déplacement.
EBICS-Kernel
API qui regroupe toutes les fonctions EBICS côté
client – en complément des produits clients.
TRAVIC-Web
Propose un client EBICS complet basé sur Java en
interaction avec les composants de TRAVICCorporate.
TRAVIC-Port
Met en œuvre un portail EBICS pour l'exécution
d'opérations de paiement à l'aide d'une infrastructure Portlet.
TRAVIC-Retail
Complète l'assortiment et met à disposition toutes
les fonctionnalités centrales d'un système FinTS
côté banque.
À l'exception de TRAVIC-Retail, nous reviendrons en détail sur les différents
composants dans ce qui suit.
39
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
PeSIT
SFTP,
ONGUM/IP
ftp(s)
PeSIT-IP
Infrastructure
Internet
Format
Plafond
Compte
TCP/IP
EBICS
EBICS
TRAVIC-Port
EBICS
Navigateur
Figure 8:
1
EBICS
TRAVIC-Web
HTTPS
HTML
11
0 11
1 01
TRAVIC-Port
0
Engine
Security
TRAVICCorporate
TRAVIC-Link
EBICS-Kernel
VEU
TC/IP / TLS
Serveur EBICS
Client-EBICS
Système transfert de paiement
PeSIT-IP
BCS-FTAM
Client-PeSIT
BANQUE
Composants de la gamme de produits 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.
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 comptabili-
40
té 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

PeSIT-IP
Protocoles de transfert de fichiers intégrés

ONGUM-IP

Secure-FTP

HTTP

JMS

FTP(S)
Logiciel standard intégrable via interfaces

rvs (gedas deutschland GmbH)

CONNECT :Direct (Sterling Commerce)

UDM (Stonebranch)
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.
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.
41
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 d'applications pour ordinateurs bancaires s'appliquent
ardemment à adapter leurs produits au standard EBICS, les fabricants de
produits clients 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. À 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 permet de pallier ces incertitudes : celle-ci met à disposition une solution 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 porte-folio d'ebanking.
TRAVIC-Port utilise EBICS-Kernel comme noyau central de la communication
multibanque pour mettre en place le protocole EBICS. Ces fonctions principales 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.
42
Pour faciliter l'intégration dans des solutions d'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 TRAVICPort 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.
43
Bibliographie
DFÜ Agreement
Appendix 1: Specification EBICS
Version 2.5 du 16 mai 2011
Zentraler Kreditausschuss (organisme de normalisation bancaire
allemand)
[2]
DFÜ Agreement
Appendix 2: Specification FTAM
er
Version 2.0 du 3 novembre 2005 (obsolète depuis le 1 janvier
2011)
Zentraler Kreditausschuss
[3]
DFÜ Agreement
Appendix 3: Specification of Data Formats
Version 2.8 de 2014
[4]
EBICS Implementation Guide
Basé sur EBICS version 2.5 du 16 mai 2011
[5]
Security concept EBICS
Version 1.4
[6]
FinTS V4.0
Version 4.0 du 22 juin 2004
[1]
44
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
Échange 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
45
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
46
Liste des illustrations
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Structure de la spécification EBICS et intégration dans l'accord DFÜ
allemand ........................................................................................... 7
Scénario d'ensemble BCS/EBICS pour illustrer la migration d'un
standard national vers EBICS ........................................................... 9
Schémas XML EBICS ..................................................................... 13
Modèle de données ........................................................................ 16
Procédure de signature EBICS ....................................................... 18
Déroulement de la procédure VEU ................................................. 29
Déroulement d'une transaction EBICS............................................ 34
Composants de la gamme de produits TRAVIC ............................. 40
47
Moorfuhrtweg 13
22301 Hambourg
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.
48

Compendium EBICS

Transcription

Documents pareils

EN BREF EN DETAIL

Logiciel Sage Moyens de Paiement Banque Liberté

Newsletter RDV Flux 8 - Crédit Agricole d`Ile de France

ebics ts - Banque Kolb

Logiciel web et mobile pour votre gestion multi-bancaire

Turbo Suite Entreprise - Banque Populaire du Massif Central