Migration der Bankenkommunikation - Von ISDN FTAM auf EBICS

Aus Winfwiki

1 Einleitung

Onlinebanking ist aus der heutigen Welt nicht mehr wegzudenken. Viele Bankkunden nutzen die Möglichkeit über öffentliche Netzwerke mit ihrer Bank zu kommunizieren. Durch weitere Verbreitung der Telekommunikationswege, hierbei vor allem das Internet, wurde eine neue Form der Privatkunden- Bank überhaupt erst möglich. Früher wurden alle Bankgeschäfte in der Filiale getätigt. Bei Direktbanken ist dies gar nicht mehr möglich, da diese Banken auf ein weit gestreutes Filialnetz verzichten. Alle Transaktionen werden daher über das Internet oder Telefon abgeschlossen. Da kein teures Filialnetz unterhalten werden muss, können Direktbanken gegenüber anderen Banken insbesondere jüngere Kunden über einen günstigeren Preis abwerben.

Private Kunden übermitteln in der Regel ihre Zahlungsaufträge an ihre Bank und holen ihre Umsatzdaten ab. Hierfür gibt es zwei Möglichkeiten. Zum Einen ist dies über die Web- Portale der Banken möglich, zum anderen über eine Software, die mehrere Konten bei verschiedenen Instituten verwalten kann.

Aufgrund verschiedener Anforderungen und Interessen zwischen Privat- und Geschäftskunden wurden vom ZKA (Zentraler Kreditausschuss) verschiedene Protokolle erstellt. Der ZKA ist ein Zusammenschluss der Oberverbände der deutschen Kreditwirtschaft (des deutschen Bankgewerbes). Über diesen Verband stimmen die deutschen Banken in Deutschland unter anderem gültige Standards für das Onlinebanking ab. Für den Privatkunden Bereich gibt es hierzu das Verfahren FinTS (Financial Transaction Services), welches aber im Rahmen dieser Arbeit nicht weiter untersucht werden wird.

Im Folgenden werden die Bankkommunikationswege, die im Bereich der Geschäftskunden zum Einsatz kommen untersucht. Ein besonderer Fokus liegt hierbei auf den vom ZKA vereinbarten Standards. Zuerst wird der aktuelle Standard ISDN- FTAM (File Transfer and Access Management) und danach der Nachfolgestandard, EBICS ( Electronic Banking Internet Communication Standard) untersucht. Einen Weitereren Weg für Geschäftskunden stellt das SWIFT (Society for Worldwide Interbank Financial Telecommunication)- Netz dar. Das SWIFT- Netz ist das Interbanken Kommunikationsnetz. Mittlerweile wird es auch den Bankkunden ermöglicht, einen Anschluss zu diesem Netzwerk zu erhalten. Der Vorteil ist hier vor allem, das jede In- und Ausländische Bank über ihre SWIFT Adresse zu erreichen ist.

Bei Einsatz der ZKA Protokolle ist dies nicht möglich, da es sich um nationale Vereinbarungen handelt, und auch nur nationale Zahlungsverkehrsformate zum Einsatz kommen. Um auf diesem Weg ausländische Banken zu erreichen, muss mit einer deutschen Bank vereinbart werden, dass diese die Kontoinformationen im Ausland einholt und bereitstellt. Ein SWIFT Zugang bietet sich daher vor allem für große international ausgerichtete Unternehmen an. Zusätzlich sind über das SWIFT- Netz weitere Informationen mit den Banken austauschbar. Problem dieser Lösung ist insbesondere der große Investitionsbetrag, sowie die hohen laufenden Kosten.

2 Beschreibung eines möglichen Einsatzszenarios für Geschäftskunden

Aktuell wird die Kommunikation mit den Banken über den ISDN- FTAM Standard realisiert. Um die gewünschte Kommunikationsmöglichkeit einzurichten, muss zuerst mit jeder Bank eine entsprechende Vereinbarung getroffen werden. Zusätzlich wird eine Software benötigt. Bei Unternehmen mit mehreren Kontenverbindungen sollte die Software zusätzlich Multibankenfähig sein. Über den Bankenverband wird hierfür die Software Multicash vertrieben. Multicash ist ein Produkt der Firma Omikron. Nach dem Abruf der Kontoauszüge erstellt die Software Weiterverarbeitungsdateien. Die erstellten Weiterverarbeitungsdateien müssen danach im Unternehmensnetzwerk den Stellen bereit gestellt werden, die diese Daten benötigen.

Ein Computer, der Daten an Banken senden bzw. von ihnen empfangen soll, braucht daher sowohl eine ISDN Karte für die Datenkommunikation als auch einen Netzwerkanschluss, um die Informationen im Unternehmensnetzwerk zu verteilen. Es empfiehlt sich hierbei, nur einen Computer für Datenkommunikation aufzustellen, da in der Regel jeder ISDN Anschluss separat zu bezahlen ist.

Je nach Unternehmensrichtlinie ist der Vorgang der Datenverteilung zu differenzieren. Darf der Computer sowohl über einen aktiven Netzwerkanschluss als auch über einen aktiven ISDN Anschluss verfügen, so ist der Datentransfer direkt nach der Datenkommunikation möglich. Wird dies allerdings durch Unternehmensrichtlinien unterbunden, ist der Datentransfer komplizierter. Ein Grund hierfür könnte sein, dass über den ungeschützten ISDN Weg jemand in das über eine Firewall geschützte Netzwerk eindringen könnte. Diese mögliche Hintertür zum Unternehmensnetzwerk müsste dann geschlossen sein. Um sicherzustellen, dass immer nur ein Zugang aktiv ist, könnte mit Hardwareprofilen gearbeitet werden, welche jedoch den Nachteil haben, dass vor jedem Datentransfer der Computer neu zu starten ist.

Wenn die entsprechenden Transfer Programme so arbeiten, dass alle Informationen zusammen transferiert werden können, ist der zeitliche Mehraufwand eher gering. Muss allerdings für jeden Empfänger der Daten ein eigenes Paar Weiterverarbeitungsdateien bereitstehen, wird der Transfer erschwert, da Multicash Programme immer nur eine Umsatz.txt^[1] und eine Auszug.txt^[1] erstellen. Erst wenn keine Weiterverarbeitungsdateien mehr im Programmverzeichnis hinterlegt sind, wird ein neues Paar angelegt. Ein Transfer Programm müsste also entweder in der Lage sein, eine gesamt Datei zu unterteilen, sodass verschiedene Dateien entstehen, oder der Transfer muss nach jedem empfängerspezifischen Abruf ausgeführt werden. Wenn dann jedes Mal ein Neustart des Computers notwendig ist, wird ein hoher Zeitaufwand in den Abruf und die Verteilung der Daten investiert.

Dieser Weg ist seit über zehn Jahren erprobter Standard. Ein Wechsel dieses bisher gut funktionierenden Kommunikationsstandards könnte bei den Anwendern jedoch Vorbehalte verursachen. Der neue Standard EBICS ist von den deutschen Banken ab dem 01.01.08^[2] zu unterstützen. Der bisherige Standard muss bis zum 31.12.2010^[2] unterstützt werden. Wobei im Einzelfall geprüft werden könnte, ob die Banken eines Unternehmens den ISDN- FTAM weg auch länger anbieten. Denn die Banken könnten diesen Weg auch länger unterstützen. Sie sind hierzu jedoch nicht verpflichtet.

Aufgrund der zeitlichen Eingrenzung könnte die Migration der Bankenkommunikation auf einen Zeitpunkt in 2010 verschoben werden. Um einen Probezeitraum zu haben, sollte die Migration früher durchgeführt werden. Falls bei der neuen Technologie technische Probleme auftauchen, könnte wieder auf den bisherigen Standard gewechselt werden. Zusätzlich bietet sich der ISDN- FTAM Weg als Fall back an. Ein weiterer Wechselgrund könnte in der bisherigen Vorgehensweise zu finden sein, wenn Unternehmensrichtlinien, wie zuvor beschrieben, den gleichzeitigen Netzwerk- und ISDN- Anschluss verhindern. Durch den Einsatz des neuen Standards EBICS werden in dieser Hinsicht Verbesserungen erwartet. Da die Bankenkommunikation über das TCP/IP Protokoll läuft, kann die vorhandene Unternehmensinfrastruktur genutzt werden. Ein Neustarten des PC nach jedem Abruf sollte danach nicht mehr nötig sein. Zusätzlich könnte man durch die Tatsache, dass weniger ISDN- Anschlüsse benötigt werden, Kosten einsparen. Ein Anschluss sollte als Fall- Back Variante erhalten bleiben. Computer in einem Firmennetzwerk verfügen über einen Netzwerkanschluss. Hierbei ist dann sicherzustellen, dass im Unternehmensnetzwerk das Protokoll TCP/IP verwendet wird. Über diesen Anschluss ließe sich dann zeitgleich der Internetanschluss realisieren. Der Vorteil ist hierbei zudem, dass der Datentransfer zwischen Bank und Kunde über einen gesicherten Kanal des Unternehmensnetzwerks abläuft. Um Vor- und Nachteile einer Migration abzuwägen, werden im Folgenden die beiden Standards untersucht und verglichen.

Der SWIFT- Netz Anschluss wird hierbei nicht weiter berücksichtigt. Vorteile dieses Anschlusses sind vielfältige Transaktionsmöglichkeiten, sowie die Bereitstellung der Daten anstelle des Abrufes der Daten. Dem stehen allerdings hohe Mehraufwendungen^[3] bei der Einrichtung und höhere laufende Kosten entgegen, die nur bei der Nutzung einer Mehrzahl der angebotenen Transaktionen lohnenswert sind, oder wesentliche Geschäftsverbindungen mit Auslandsbanken bestehen.

3 ISDN- FTAM

Das FTAM Verfahren kann über verschieden Kommunikationswege genutzt werden. Es werden Anschlüsse auf Basis des Protokolls X.25 (Produktname in Deutschland Datex P) sowie ISDN Anschlüsse unterstützt.

3.1 Technische Grundlagen

3.1.1 FTAM im OSI Schichtenmodell

Als Grundlage des Datenaustausches dienen die Standards FTAM und ACSE (application Control Service Element)^[4] . FTAM und ACSE befinden sich gemäß ISO OSI Modell auf der Anwendungsschicht. Die Kommunikationswege, ISDN und X.25, liegen auf den Schichten eins bis drei (Physical Layer, Data Link Layer, und Network Layer). Dieser Zusammenhang wird in Abbildung 1 verdeutlicht.

In Anlehnung an: FTAM- Spezifikation S.4 Abbildung 1: OSI Schichtenmodell

3.1.2 Verbindungsaufbau und Datenaustausch

Der Datentransfer des FTAM Verfahrens ist dahingehend geregelt, dass eine Verbindung von einer Seite initiiert werden muss. Der FTAM Initiator ist hierbei in der Regel der Bankkunde. Dem FTAM Initiator ist es möglich sowohl Daten zu empfangen als auch zu senden. Der Gegenpart des Initiators ist der FTAM Responder. Auch dieser kann Daten schicken und empfangen.^[5]

Klassische Anwendungsbeispiele sind hierbei der Kontoauszugsabruf sowie die Übermittlung von Zahlungsverkehrsdateien. In beiden Fällen initiiert der Kunde die Kommunikation. Beim Kontoauszugsabruf ist der Kunde der Empfänger von Daten, welche von der Bank übermittelt werden. Bei der Übertragung der Zahlungsverkehrsdateien übermittelt der Kunde die Daten an die Bank, welche demnach der Empfänger ist. Da verschiedene Betriebssysteme die Dateiverwaltung unterschiedlich handhaben, muss, um eine Kompatibilität zu erreichen, eine Lösung gesucht werden. Im Falle des FTAM Verfahrens wird ein sogenannter Virtual Filestore^[6] genutzt. In diesem Filestore werden die Daten übermittelt, bzw. abgeholt. Dieses wird in Abbildung 2 verdeutlicht.

In Anlehnung an: FTAM- Spezifikation S.5 Abbildung 2: Darstellung der Kommunikationswege

3.2 Elektronische Unterschrift

In FTAM wird für die EU (Elektronische Unterschrift) aktuell die EU vom Typ A004 verwendet. Die vorherige EU in der Version A003 muss von den Banken seit dem 31.12.2004 ^[7] nicht mehr unterstützt werden. Die Elektronische Unterschrift A004 muss seit dem 1.4.2002 ^[8] angeboten werden. Für fast zwei Jahre waren demnach zwei Unterschriftsvarianten vom Kunden nutzbar. In diesem Zeitraum hatte der Kunde die Möglichkeit, oder die Pflicht, seine Infrastruktur entsprechend neuen technischen Vorgaben zu aktualisieren.

Die elektronische Unterschrift muss bestimmte Anforderungen erfüllen.^[9] Es muss sichergestellt werden, dass nur der berechtigte Unterzeichner die Unterschrift leisten kann. Zusätzlich muss jeder Empfänger in der Lage sein zu prüfen, ob die Unterschrift echt ist. Die Unterschrift muss für jeden möglichen Kontext und auf allen gebräuchlichen Betriebssystemen, sowohl beim Kunden als auch bei der Bank, einsetzbar sein. Für Anbieter von Verschlüsselungsmechanismen ist zudem zu beachten, dass alle Datenstrukturen und mathematischen Berechnungen kostenlos offenzulegen sind. Hierdurch haben verschiedene Hersteller die Möglichkeit kompatible Produkte anzubieten.^[10]

Die zur elektronischen Unterschrift berechtigten sind in der Regel auch die Mitarbeiter eines Unternehmens, die generell eine Unterschriftsberechtigung haben. Dies sind zum z.B. intern und mit den Empfängern vereinbarte Unterschriftsberechtigte, z.B. bei einer Handlungsvollmacht. Hinzu kommen alle Unterschriftsberechtigten gemäß dem Handelsregister, wie z.B. Prokuristen. Für jeden, der neben der handschriftlichen Unterschrift auch eine elektronische Unterschrift leisten soll, muss dies dem entsprechenden Kreditinstitut mitgeteilt werden. Nach den Vorbereitungen innerhalb der Bank können die Unterschriftsschlüssel im Kundenunternehmen erstellt und an die Bank übermittelt werden.

Die Schlüssellänge der elektronischen Unterschrift ist bei der Version A004 1024 Bit und basiert auf RSA Signaturen. ^[11] Unterschriften werden nicht innerhalb der Auftragsdateien abgelegt, sondern in einer separaten Unterschriftsdatei. Beide Dateien werden nach erfolgreicher Unterschrift an die Bank übertragen. In der Unterschriftsdatei wird dann unter anderem auf die unterschriebene Auftragsdatei verwiesen. Der Aufbau der Unterschriftsdatei laut ZKA ist wie folgt:

Tabelle 1: Aufbau der Unterschriftsdatei

In Anlehnung an: FTAM- Spezifikation S. 78

Nach der Initialisierung wird der Initialisierungsbrief ^[12] erstellt. Dieser muss unterschrieben der Bank zugestellt werden. Die EU kann erst eingesetzt werden, nachdem der Brief bei der Bank eingegangen und geprüft worden ist. Ist die Prüfung positiv, kann die Unterschrift in den Banksystemen als gültig hinterlegt werden.

3.3 Verschlüsselung der Kommunikation

Vor der Verschlüsselung der Kommunikation muss zuerst zwischen Bank und Kunde festgelegt werden, welche Daten ausgetauscht werden. Die nachfolgende technische Lösung muss auf beiden Systemen, sowohl bei der Bank als auch beim Kunden, mit den dort eingesetzten Systemen kompatibel sein.^[13]

Zur Kommunikation wird das „hybridische Verfahren“ ^[14] eingesetzt. Bei diesem Verfahren werden die Public Keys ausgetauscht. Den Anfang macht hierbei der Kunde. Hier wird eine VPK (Verschlüsselungs- Public- Key- Kunde)^[15] - Datei an das Kreditinstitut übermittelt. Die übermittelte Datei muss gegenüber der Bank verifiziert werden. Das Verifizieren der VPK- Datei kann über zwei Wege erfolgen. Zum einen über eine elektronische Unterschrift, zum anderen über den postalisch übermittelten Initialisierungsbrief, welcher vor dem Versand zu unterschreiben ist. Die Verschlüsselung der Kommunikation ist im ISDN- FTAM Verfahren jedoch nicht zwingend implementiert. Die Übertragungssicherheit ist ansonsten ausschließlich vom Bankrechnerzugangskennwort, dem FTAM- Passwort abhängig.^[16]

Der Aufbau der VPK- Datei ist ebenfalls vom ZKA vorgegeben.^[17] Die Datei ist 1024 Bytes groß. Die einzelnen Informationen inklusive der Größe der Informationen werden in folgender Tabelle dargestellt.

Tabelle 2: Aufbau der VPK Datei

In Anlehnung an: FTAM- Spezifikation S. 85

Nach erfolgreicher Übertragung und Verifizierung der Datei übermittelt die Bank ihrerseits die VPB (Verschlüsselungs- Public- Key- Bank)- Datei. Der Aufbau der Datei ist ähnlich dem Aufbau der VPK Datei. Die Felder Verschlüsselungsverfahren, Zeitstempel der Generierung sowie die EU- Datei entfallen. Anstelle der Kunden-ID ist das Feld Host-ID beinhaltet. In diesem Feld wird der Name des Bankrechners übermittelt. Die übrigen Felder liegen auch in der VPK Datei vor, und haben die gleiche Größe und Inhalt.^[18]

4 EBICS

4.1 Technische Grundlagen

Der Aufbau von EBICS gemäß dem OSI Schichtenmodell gestaltet sich wie folgt: Auf der Anwendungsprotokollebene liegt EBICS inklusive der Anwendungsprotokollsprache XML(Extensible Markup Language). Darunter folgt die Anwendungsschicht mit dem Kommunikationsprotokoll https(Hypertext Transfer Protocol Secure). Diese beiden Schichten sind anwendungsorientiert. Auf der folgenden Schicht wird die Transportverschlüsselung durchgeführt. In diesem Fall wird hierfür TLS verwendet. Die transportorientierten Schichten sind demnach die Transportschicht mit dem Protokoll TCP, und die Netzwerkschicht mit dem Protokoll IP. Abschließend wird die Nachricht auf der Bitübertragungsebene über Ethernet gesendet oder empfangen. Die folgende Abbildung dient der besseren Übersichtlichkeit.^[19]

In Anlehnung an: EBICS- Spezifikation S.17 Abbildung 3: vereinfachtes OSI Modell für das EBICS- Protokoll

Während die Kommunikation beim FTAM Verfahren noch auf X.25 oder ISDN begrenzt war, so ist es über EBICS möglich, die in vielen Fällen vorhandene Netzwerkstruktur zu benutzen. Dies liegt darin begründet, dass das TCP/IP Protokoll unterstützt wird. Bei der ISDN FTAM Kommunikation wurde ein Bankrechner über eine Telefonnummer erreicht. Nun werden neben der Host- ID noch die URL (Uniform Resource Locator) benötigt. Diese Daten werden dem Kunden von der entsprechenden Bank zur Verfügung gestellt.^[20]

Die Transportverschlüsselung ist in dem Konzept zwar vorgesehen, aber in der EBICS Version H003 ist diese nicht verpflichtend implementiert. In diesem Fall wurde die Sicherheit zugunsten einer besseren Marktakzeptanz vernachlässigt. Ein Einsatz der Transportverschlüsselung in einer späteren EBICS Version ist aber weiterhin möglich.^[21]

Zur Kommunikation wird das Protokoll http(s) verwendet. Die weiteste Verbreitung findet sich im Internet, wo vor allem das http (Hypertext Transfer Protocoll) Protokoll zum Aufruf von Webseiten eingesetzt wird. Das https Protokoll ist eine Weiterentwicklung dieses Protokolls. Hierbei wurden insbesondere höhere Sicherheitsstandards festgelegt, so dass dieses Protokoll zur sicheren Kommunikation eingesetzt wird. Bei diesem Protokoll können Daten auf zwei Wegen übermittelt werden und zwar über die Methoden POST und GET. Bei EBICS wird die POST Variante angewandt. Bei einer POST Anfrage werden die Daten zum http- Header hinzugefügt.^[22]

4.2 Elektronische Unterschrift

Elektronische Unterschriften werden auch in EBICS bisher nur durch den Bankkunden durchgeführt, damit dieser Aufträge gegenüber der Bank legitimieren kann. Die EU der Kreditinstitute ist vorgesehen, aber in der aktuellen Version von EBICS noch nicht implementiert. Das EBICS Protokoll unterstützt vier Unterschriftstypen. Dies sind in absteigender Stärke:

- E -> Einzelunterschrift

- A -> Erstunterschrift

- B -> Zweitunterschrift

- T -> Transportunterschrift

Als bankfachliche EU s dienen hierbei nur die drei erstgenannten. Die Transportunterschrift ist im EBICS- Protokoll neu aufgenommen worden. Diese dient der Authentifikation des Kunden, wenn dieser Daten abholt und sendet. Bei ISDN- FTAM mussten nur Aufträge unterschrieben werden; diese dann allerdings rechtsverbindlich. Beim EBICS- Protokoll werden neben dem übermitteln der Aufträge auch Datenabrufe durch eine Transportunterschrift signiert.

Die EU in der Version A004, welche mindestens für EBICS eingesetzt werden muss^[23], ist nur noch bis zum 1.9.2009 bankseitig verpflichtend zu unterstützen.^[24] Dies entspricht so zwar nicht genau der Realität, faktisch wird diese Version bis heute noch genutzt. Dies ist vor allem dem Umstand geschuldet, dass mit der sich im Einsatz befindlichen aktuellen Multicash Version der neue Signaturschlüssel noch gar nicht erzeugen lässt. Auch sind die Kreditinstitute noch nicht in der Lage die neuen Signaturschlüssel flächendeckend anzubieten. Aber sowohl die Kreditinstitute als auch die Softwarehersteller sind dabei, ihre Systeme bzw. ihre Produkte auf den nächsten Unterschriftenstandard vorzubereiten.

Den neuen Standard werden die Unterschriften der Version A005/A006 setzen. Die Anforderungen an die elektronische Unterschrift haben sich gegenüber den FTAM Anforderungen nicht wesentlich geändert. Die Unterschriftsversionen A005/A006 sind nicht zwei aufeinanderfolgende Versionen, sondern sind einander gleichwertig. Der Unterschied liegt nur bei einem unterschiedlichen Padding- Verfahren.^[25]

Die Schlüssellänge ist gegenüber der Version A004 erheblich vergrößert worden. So beträgt die Schlüssellänge nun mindestens 1536 Bit und darf bis zu 4096 Bit groß sein. Sie gewährleistet somit eine deutliche Verbesserung hinsichtlich der Verhinderung mißbräuchlicher Nutzung. Auch der Aufbau der Unterschriftsdatei wurde geändert. Die Unterschriftsdatei weist nun eine XML- Struktur auf.^[26]

4.3 Verschlüsselung der Kommunikation

Im EBICS Protokoll sind zwei Verschlüsselungen vorgesehen. Zum einen zwischen der Transport und Anwendungsebene, die TLS- Ebene. Hierdurch wird der Schutz und die Integrität der Daten zwischen Kunden und Bank gewährleistet.^[27]

Hinzu kommt eine Verschlüsselung auf Anwendungsebene. Hierbei werden Auftragsdaten verschlüsselt den EBICS Daten hinzugefügt. Es werden in diesem Verfahren ausschließlich Auftragsdaten und EU verschlüsselt. Diese Informationen werden zuerst komprimiert (ZIP- Komprimierung), danach verschlüsselt und abschließend mit base64-kodiert der EBICS- Nachricht hinzugefügt.^[28]

Im Folgenden werden die zwei Arten des Nachrichtenaustausches unterschieden. Wenn der Kunde Daten hoch- lädt, wird ein symmetrischer Schlüssel generiert, welcher dann wiederum mit dem öffentlichen Schlüssel des Bankrechners verschlüsselt wird. Dies soll die Sicherheit dahingehend erhöhen, dass nur das entsprechende Institut die Daten entschlüsseln kann. Bei der Download Variante durch den Kunden, ist das Verfahren an sich vergleichbar. Nur wird hier die Nachricht durch den öffentlichen Schlüssel des Teilnehmers codiert, damit dieser die Nachricht wieder decodieren kann.

5 Vergleich ISDN- FTAM und EBICS

Eine tabellarische Übersicht, in denen ISDN-FTAM und das EBICS miteinander verglichen werden, bietet der ZKA^[29] an, wobei einzelne im Folgenden erläutert werden.

Die Multibankfähigkeit sowie das Erstellen der Auftragsdaten bleibt unverändert. Auch die Medien zur Erstellung der Unterschrift können weiter genutzt werden, sodass hier keine weiteren Investitionen zu tätigen sind. Die Elektronische Unterschrift hat sich in ihrem bisherigen Prinzip nicht verändert. Lediglich ältere Unterschriftsversionen, älter als der Typ A004, werden nicht mehr unterstützt.

Die offensichtlichste Verbesserung wurde bei der Steigerung der Übertragungsgeschwindigkeit erreicht. Über ISDN konnten Geschwindigkeiten bis zu 128 kbit/s erreicht werden. Aber auch dieses war nur mit Kanalbündelung möglich. Die Übertragungsgeschwindigkeit pro Kanal liegt bei 64 kbit/s. Bei heute gebräuchlichen Internetanschlüssen ist eine weit höhere Übertragungsgeschwindigkeit zu erreichen. Zudem ist beim EBICS- Protokoll eine Komprimierung der Daten verpflichtend, welches zusätzlich zu einer höheren Geschwindigkeit führt und durch das daraus resultierende kleinere Datenvolumen günstiger ist. Darüber hinaus ist kein weiterer Anschluss nötig, da die meisten Unternehmen über einen Internetanschluss verfügen.

Durch die Internetfähigkeit des Protokolls sind außerdem neue Kommunikationsmöglichkeiten gegeben. Beim Einsatz von ISDN- FTAM war der Kunde darauf angewiesen, eine lokale Software einzusetzen. Durch das EBICS- Protokoll ist es dem Geschäftskunden wie dem Privatkunden nun möglich, Online Portale oder weiterhin eine Software zu nutzen.

Den größten Unterschied zwischen den beiden Verfahren gibt es allerdings im Bereich der Sicherheit. Und gerade dies ist in dieser Thematik von großer Bedeutung. Die Sicherheitsanforderungen sind beim EBICS- Protokoll deutlich strenger als noch beim ISDN- FTAM verfahren. Die Verschlüsselung, die bei ISDN-FTAM nur optional war, ist in EBICS zur Pflicht geworden. Sowohl die Verschlüsselung der Daten an sich als auch der Übertragung sind verpflichtend. Die Anmeldung am Bankrechner war zuvor nur vom FTAM- Passwort abhängig. Bei EBICS wird zur Authentifizierung des Kunden am Bankrechner eine Signatur verlangt.

6 Fazit

Das ISDN- FTAM Protokoll wird in naher Zukunft aus den Produktivumgebungen sowohl der Unternehmen als auch auf der Bankenseite verschwinden. Wann dies passieren wird, ist zum Großteil von den Banken abhängig. Solange den Kunden dieser Weg angeboten wird und Unternehmen keinen Druck zur Migration verspüren, wird ISDN- FTAM weiterhin aus Gründen der Opportunität eingesetzt werden.

Aber selbst für Kunden die bereits auf EBICS migriert sind bieten sich durch einen Parallelbetrieb Vorteile. Der ISDN Weg lässt sich als Alternative beibehalten. So können Daten mit den Banken selbst dann ausgetauscht werden, wenn lediglich der Internetzugang blockiert ist. Aber auch wenn es auf Bankenseite zu Störungen kommt, bietet sich ein Alternativsystem an. So kann es sein, dass eine Bank zwar über EBICS nicht zu erreichen, aber über den ISDN- FTAM weg noch erreichbar ist. Daher gibt es eigentlich keinen Grund die Migration weiter hinaus zuschieben. Der Investitionsaufwand ist überschaubar, bzw. tendiert gegen null, da alle bisherigen Medien weiterverwendet werden können. Es ist lediglich eine Software nötig, bzw. ein Update der eingesetzten Software.

Aber Gründe dafür, ein funktionierendes System zu ändern sind nicht ausschließlich die geringen Investitionskosten, sondern eher der Nutzen, der sich daraus ergibt. Der Nutzen ist hierbei zum Beispiel die Tatsache, dass die Geschwindigkeiten des Datenaustausches im Vergleich zu ISDN höher sind. Zusätzlich werden Daten verpackt verschickt. Dieses und der mögliche Wegfall eines ISDN- Anschlusses helfen Kosten einzusparen.

Bei allen Überlegungen, gleich auf welcher Abwicklungsebene, ist immer vordringlich zu beachten, dass mittels dieser Tools erhebliche Geldmengen transferiert werden und dabei Besitzwechsel stattfinden. Die Sicherheitsschwelle gegen eine missbräuchliche Verwendung hat daher jederzeit eine übergeordnete Bedeutung. Im EBICS- Verfahren wird diese Anforderung sowohl durch den längeren Unterschriftsschlüssel, die Verschlüsselung des Kommunikationsweges und der Daten, sowie durch die Signatur aller Aufträge weitaus besser erfüllt, als es im ISDN- FTAM Verfahren der Fall war.

Eine Migration von ISDN- FTAM zu EBICS sollte daher zeitnah umgesetzt werden.

7 Abkürzungsverzeichnis

8 Abbildungsverzeichnis

9 Tabellenverzeichnis

10 Fußnoten

1. ↑ ^{1,0 1,1} Vgl. Multicash Lexikon
2. ↑ ^{2,0 2,1} Vgl. DFUE Verfahren
3. ↑ Vgl. Swift Preisübersicht
4. ↑ Vgl. FTAM Spezifikation S.9
5. ↑ Vgl. FTAM Spezifikation S.4
6. ↑ Vgl. FTAM Spezifikation S.4
7. ↑ Vgl. FTAM Spezifikation S.54
8. ↑ Vgl. FTAM Spezifikation S.69
9. ↑ Vgl. FTAM Spezifikation S.53
10. ↑ Vgl. FTAM Spezifikation S.53
11. ↑ Vgl. FTAM Spezifikation S.77
12. ↑ Vgl. FTAM Spezifikation S.79
13. ↑ Vgl. FTAM Spezifikation S.84
14. ↑ Vgl. FTAM Spezifikation S.84
15. ↑ Vgl. FTAM Spezifikation S.85
16. ↑ Gegenüberstellung ISDN- FTAM und EBICS
17. ↑ Vgl. FTAM Spezifikation S.85
18. ↑ Vgl. FTAM Spezifikation S.86
19. ↑ Vgl. EBICS Spezifikation S.17
20. ↑ Vgl. EBICS Spezifikation S.17
21. ↑ Vgl. EBICS Spezifikation S.18
22. ↑ Vgl. EBICS Spezifikation S.20
23. ↑ Vgl. EBICS Spezifikation S.287
24. ↑ Vgl. EBICS Spezifikation S.344
25. ↑ Vgl. EBICS Spezifikation S.330
26. ↑ Vgl. EBICS Spezifikation S.343
27. ↑ Vgl. EBICS Spezifikation S. 152
28. ↑ Vgl. EBICS Spezifikation S. 152
29. ↑ Vgl. Gegenüberstellung ISDN- FTAM und EBICS

11 Literatur und Quellenverzeichnis