Blog-Serie: Wie sich EBICS verbessern lässt, Teil 1 – Kundenauftragsreferenz

Mit dieser Blog-Serie möchte ich eine Reihe starten, in der über mögliche und wünschenswerte Erweiterungen von EBICS nachgedacht wird. Die Vorschläge haben einen konkreten fachlichen oder technischen Hintergrund, aus dem sich die Lösungsvariante ableitet. Beginnen möchte ich die Blog-Serie mit der Kundenauftragsreferenz.

Von Kunden wurde die Möglichkeit nachgefragt, einem Auftrag eine Referenz mitzugeben, zum Beispiel einen Dateinamen oder eine beliebige ID. Wichtig ist dabei die Eindeutigkeit der Referenz. Somit kann der Kunde gezielt den Auftragsstatus über die Referenz abfragen, egal ob der Auftrag noch in Bearbeitung ist oder schon vor Tagen abgearbeitet wurde. Des Weiteren kann über diese Referenz auch eine Doppeleinreichungskontrolle erfolgen.

An dieser Stelle sollte klar sein, dass die existierende 4-stellige Order-ID nicht das richtige Mittel ist, um die oben genannten Anforderungen abzudecken. Die Order-ID wird seit der EBICS-Version 2.5 vom EBICS-Server vergeben und ist nicht eindeutig.

Die Anforderungen können durch die Einführung einer Kundenauftragsreferenz (Customer Order Reference) abgedeckt werden, die den EBICS-Standard erweitern würde. Konkret könnte dies so umgesetzt werden:

• Eine individuelle Kundenauftragsreferenz mit einer Länge von zum Beispiel 512 Zeichen wird eingeführt. Die Kundenauftragsreferenz kann vom Kunden frei vergeben werden. Sie kann zum Beispiel der Dateiname, eine beliebige ID oder eine Kombination aus beidem sein. Die Kundenauftragsreferenz muss im Protokoll (PTK/HAC) aufgeführt werden.
• Die Kundenauftragsreferenz wird innerhalb von zum Beispiel 90 Tagen im EBICS-Server der Bank pro Kunde auf Eindeutigkeit geprüft. Wird ein Auftrag mit einer Kundenauftragsreferenz eingereicht, für die bereits ein erfolgreicher Upload erfolgte, wird der neue Auftrag abgelehnt. Erfolgt hingegen ein zweiter Upload mit der gleichen Kundenauftragsreferenz während der erste Upload noch läuft, wird der erst (ältere) Upload fehlerhaft beendet. Damit kann die Kundenauftragsreferenz auch verwendet werden, wenn ein Transfer hängen bleibt. Die Ablehnung wird in jedem Fall im PTK/HAC vermerkt.
• Wenn die PTK/HAC-Einträge des EBICS-Servers der Bank durch Einträge zum Beispiel aus dem Clearing ergänzt werden, so sollten die ergänzenden PTK/HAC-Einträge ebenfalls die entsprechende Kundenauftragsreferenz enthalten, soweit sie sich auf eine Einreichung beziehen.

Als Abfragen wären folgende Aufträge denkbar:

• Der Kunde kann das PTK/HAC gezielt für eine oder mehrere Kundenauftragsreferenzen abrufen. Dabei wird dem Kunden das bis zu dem Zeitpunkt fertige PTK/HAC zurückgegeben. Der Abholstatus von PTK bzw. HAC bleibt dabei unverändert.
• Alle bereits eingereichten Kundenauftragsreferenzen können abgefragt werden. Dabei kann der Zeitraum analog zur historischen Abholung eingegrenzt werden. Diese wäre eine Servicefunktion für die Kundenauftragsreferenzen.

Mit der Einführung einer Kundenauftragsreferenz, der individuellen Abfrage nach bestimmten Kundenauftragsreferenzen und der daraus resultierenden Doppeleinreichungskontrolle hätte man ein starkes Instrument geschaffen. Der Kunde könnte einzelne Einreichungen recherchieren und hätte die Möglichkeit, eine effektive Doppeleinreichungskontrolle zu etablieren. Die Bank würde die Recherchemöglichkeiten für den Kunden erweitern und könnte damit Anfragen bei der Bank reduzieren. Eine Doppeleinreichungskontrolle wäre sogar an den Kunden delegiert. Somit wäre die Einführung einer Kundenauftragsreferenz eine Win-Win-Situation für die Banken und für die Kunden. Was wollen wir mehr?

Michael Lembcke 

Weiterlesen

Startschwierigkeiten beim Onboarding von Schweizer EBICS-Kunden

In früheren Blogbeiträgen haben wir bereits über den Start von EBICS in der Schweiz berichtet. Erste Kreditinstitute bieten inzwischen den multibankfähigen Standard an, weitere befinden sich noch in der Angebotsplanung. Der Fokus richtet sich daher nun langsam auf die Firmenkundschaft, die die neuen Schnittstellen nutzen möchte, genauer gesagt auf die dort einzusetzende EBICS-Client-Software.

Die erste Umfrage Anfang dieses Jahres in der Schweizer Softwarehersteller-Gemeinde zum Support von EBICS in ihren Client-Produkten war durchweg positiv. Die Mehrzahl der Anbieter hat EBICS als Protokoll bereits implementiert und kann produktive Verbindungen mit den beiden Großbanken vorweisen. Um dem Kunden das Aufschalten einer neuen Schnittstelle zu vereinfachen, bieten einige der Softwarelösungen sogenannte EBICS-Profile für das jeweilige Institut in ihren Installationsprogrammen an. Der Kunde entscheidet vor der Initialisierung, mit welcher Bank er sich verbinden will und das Programm belegt automatisch Institut-spezifisch die wichtigsten Verbindungs- und Konfigurationsparameter (Version, EU-Verfahren, Hostname, Zertifikat-Aussteller, unterstützte Auftragsarten, URL, etc.).

Möchte nun der Kunde eine weitere Bank anbinden, welche EBICS neu anbietet, benötigt er oftmals eine neue Softwareversion des Herstellers, welche gemäß dem soeben beschriebenen Verfahren die neue Institut-spezifische Konfiguration enthält. Das an sich kundenfreundliche Setup verkehrt sich hier auf einmal ins Gegenteil, denn wer möchte nur wegen einer neuen Bankverbindung gleich die gesamte Software updaten? Gewünscht wäre an dieser Stelle ein konfigurativer Ansatz, bei welchem ich als Kunde die relevanten EBICS-Parameter für die neue Verbindung selbst erfassen kann.
Wenn der Hersteller dann für solche Updates noch Releasegebühren verlangt, wird man den Eindruck nicht los, dass hier auf Kosten des Kunden für ein eigentlich triviales Problem gerne Kasse gemacht wird. Es liegt jetzt wohl an den Banken, sich einen Überblick über die jeweiligen Lösungen zu verschaffen und dieses dann in der Kundenberatung entsprechend einfließen zu lassen, wenn es um die Frage geht, welche EBICS-Software am besten für den Anschluss an das eigene Institut geeignet ist.

Für Schweizer Hersteller, welche noch kein EBICS-Protokoll installiert haben, hier zum Abschluss noch ein Tipp: Die Konfiguration einer neuen EBICS-Verbindung sollte kein „Hexenwerk“ sein, wenn von Anfang an darauf geachtet wird, dass diese z.B. über einen Dialog vom Kunden selbst wahrgenommen werden kann. Für die Einbindung des EBICS-Protokolls sei an dieser Stelle auch noch auf den EBICS-Kernel von PPI verwiesen (siehe Softwarebausteine auf der PPI-Homepage), der den gesamten Umfang von EBICS in Form einer Software-Library zur Verfügung stellt.

Carsten Miehling 

Weiterlesen

SEPA Card Clearing – Was hat das mit EBICS zu tun?

Von der Vereinheitlichung des Zahlungsverkehrs innerhalb der SEPA Single Euro Payment Area sind neben den Geschäftsvorfällen Credit Transfer und Direct Debit in gewisser Weise auch die Kartenzahlungen betroffen. Was dies mit EBICS zu tun hat, verrät der folgende Artikel.

Die Kartenzahlungen wurden bisher in nationalen Formaten ausgetauscht. Am Point-of-Sale unterscheidet man generell zwei Arten:

1. ELV*-Lastschriften, die durch eine manuelle Unterschrift des Kunden autorisiert werden
2. Lastschriften, die durch eine PIN-Eingabe im Kartenlesegerät autorisiert werden
Die ELV-Lastschriften werden als normale SEPA Direct Debits verarbeitet. Die Lastschriften mit PIN-Eingabe am Kartenlesegerät werden nicht automatisch von SEPA geregelt. Es ist jedoch sinnvoll, auch hier die nationalen Formate durch ISO20022-Formate zu ersetzen. Diese ISO-Formate werden im SEPA Card Clearing oder kurz SCC spezifiziert. Dabei unterteilt sich das SCC wie folgt:

• Firmenkunde-Bank-Geschäft
• Interbankenzahlungsverkehr

In beiden Regimen sind besondere Anforderungen an den Prozess, den Clearing- und Settlement-Mechanismus sowie die auszutauschenden Datenformate zu berücksichtigen. Das EPC (European Payment Council) hat Vorgaben für das SEPA Card Clearing gemacht. Die Berlin Group (www.berlin-group.org), eine Initiative von Zahlungssystemen und Organisationen aus ganz Europa, hat einheitliche Vorgaben basierend auf dem Standard ISO20022 im Detail spezifiziert. Diese Spezifikation, die derzeit in der Version 2.0 vorliegt, unterstützt gleichfalls die Anforderungen des EPC an das SEPA Card Clearing.

Zu den Vertretern der Berlin Group gehören Teilnehmer aus: Belgien, Bulgarien, Dänemark, Deutschland, Estland, Europa, Finnland, Frankreich, Griechenland, Großbritannien, Irland, Island, Italien, Kroatien, Lettland, Litauen, Luxemburg, Niederlande, Norwegen, Portugal, Schweden, Serbien, Spanien, Türkei und Ungarn. Damit ist die SCC-Spezifikation der Berlin Group eine europaweite Initiative. Man ist derzeit dabei, das SCC umzusetzen. In Deutschland hat der DK (Deutsche Kreditwirtschaft) beschlossen, die Verrechnung von kartenbasierten Umsätzen, die nicht ELV-basiert sind, von den Altformaten auf die Formate und Prozesse des SCC der Berlin Group umzustellen. Von den Umstellungen von Altformaten auf SCC sind Firmenkunden, Kartenherausgeber, Kartenakzeptanten, technische Dienstleister (z. B. Netzbetreiber) sowie Kreditinstitute und Zahlungsverkehrsabwickler betroffen. Vor einer Umstellung sollte das Sizing der IT-Systeme überprüft und ggf. neu ausgelegt werden, da bei SCC – analog zu SEPA – auch wieder höhere Datenvolumina erwartet werden.

Was hat das Ganze nun mit EBICS zu tun? Vom DK wurde die Nutzung von SCC mit EBICS beschlossen. Zum 23. April 2014 wurden im Anhang 2 der EBICS-Spezifikation die Geschäftsvorfälle um die des SCC erweitert. Die EBICS-Erweiterung betrifft den Interbankenverkehr und das Firmenkunde-Bank-Geschäft. Es wurden neue Geschäftsvorfälle für den Datenaustausch in Form neuer Auftragsarten und Formate in die EBICS-Spezifikation aufgenommen. Die Auftragsarten und Formate im Interbankenverkehr sind z. B. für die Deutsche Bundesbank über EBICS für den neuen SCC-Dienst des SEPA-Clearers enthalten. Dabei plant die Deutsche Bundesbank auch hier die Abschaltung des Altformates DTA. Gleichfalls wurden in EBICS Erweiterungen für das europäische SCC im Interbankenzahlungsverkehr aufgenommen. Die EBA-Clearing bietet europaweit im Interbankenverkehr mit diesen Geschäftsvorfällen das STEP2 Card Clearing über EBICS an. Aktuell laufen verbreitet die Tests zum SCC. Die Abnahmetests mit den Clearingstellen EBA-Clearing und Deutsche Bundesbank sollen bis Frühjahr 2015 abgeschlossen sein. Eine vollständige Umstellung von DTA auf SEPA und somit auf das SEPA Card Clearing soll in 2016 erfolgen. Inwieweit dieses auch von Banken in anderen europäischen Ländern von Interesse ist, wird sich zeigen. Die Zusammensetzung der Teilnehmer der Berlin Group ist jedenfalls vielversprechend.

---

* Elektronisches Lastschriftverfahren

Michael Lembcke 

Weiterlesen

Zürcher Kantonalbank entscheidet sich für EBICS

Die Zürcher Kantonalbank hat sich für ihren elektronischen Zahlungsverkehr für eine besonders stabile und multibankfähige Software entschieden. Die größte Schweizer Kantonalbank bietet ihren Firmenkunden zukünftig den internetbasierten Electronic-Banking-Standard EBICS an, den die Schweizer Kreditinstitute als multibankfähigen Standard vereinbart haben. In einer Ausschreibung konnte sich die PPI AG mit dem Electronic-Banking-System TRAVIC-Corporate gegen zahlreiche Wettbewerber durchsetzen.

Nach der Entscheidung der Schweizer Kreditwirtschaft für den besonders sicheren Electronic Banking Internet Communication Standard (EBICS) tritt die Schweiz der europäischen EBICS-Gesellschaft bei, um sich gemeinsam mit Deutschland und Frankreich an dessen Weiterentwicklung zu beteiligen. Derzeit setzt sich EBICS als Zahlungsverkehrsstandard im Firmenkundensegment auch an anderen europäischen Finanzplätzen durch.

Das EBICS-Protokoll wird von Unternehmen als integraler Bestandteil ihrer Zahlungssysteme benutzt, um den elektronischen Zahlungsverkehr abzuwickeln. Typische Transaktionen sind das Erteilen von Zahlungsaufträgen oder das Beziehen von Kontoauszügen, Statusreports und Zahlungsavis. Für die Freigaben lassen sich elektronische Unterschriften verwenden. Als hoch verfügbarer und kostengünstiger Standard kann EBICS auch sehr grosse Datenvolumen sicher und schnell bewältigen.

Für Firmen hat das Verfahren den Vorteil, dass europaweit immer mehr Banken EBICS anbieten, das sich mittlerweile nebst dem einheitlichen europäischen Zahlungsformat SEPA als kongruentes Übertragungsprotokoll durchsetzt.

Bereits Anfang 2014 hatte sich die Luzerner Kantonalbank für TRAVIC-Corporate von PPI entschieden. Weitere Schweizer Großbanken interessieren sich verstärkt für das System des Marktführers für EBICS-Lösungen. Die Zürcher Kantonalbank nutzt das neue Übertragungsprotokoll der PPI AG auf Basis von TRAVIC-Corporate. „Wir arbeiten eng mit der Bank zusammen und sorgen so für eine maßgeschneiderte Integration in die bestehenden Banksysteme“, sagt Michael Lembcke, Produktmanager bei PPI und zuständig für das Integrationsprojekt der Zürcher Kantonalbank und RECON.

„Die Zürcher Kantonalbank wird das System direkt an die zentrale Benutzerverwaltung anbinden, was den Administrationsaufwand reduziert und die Sicherheit der Gesamtsystemlandschaft erhöht“, so Carsten Miehling, Geschäftsleiter bei RECON, dem Vertriebspartner der PPI AG in der Schweiz.

Michael Lembcke 

Weiterlesen

EBICS ist nicht gleich EBICS – von Auftragsarten und Formatparametern

Auch wenn es eine einheitliche Spezifikation für EBICS gibt: Bei der Einreichung und bankseitigen Berechtigungsprüfung von Zahlungsverkehrsaufträgen wird EBICS  in Europa unterschiedlich genutzt. Zum Beispiel nutzt man in Deutschland ausschließlich die Auftragsarten, in Frankreich Formatparameter. Aber muss der Kunde diese Unterschiede kennen? Wie bereits in meinem letzten Beitrag angekündigt, hier mehr dazu.


Mit der EBICS-Auftragsart gibt ein Client an, welchen Geschäftsvorfall er auf dem Bankrechner einreichen möchte. Ist die Auftragsart auf dem Bankrechner bekannt und ist der Einreicher hierzu berechtigt, wird eine für diese Auftragsart spezifizierte Formatverarbeitung durchgeführt.
Bei den dreistelligen Auftragsarten wird in EBICS grundsätzlich zwischen der Initiierung von Uploads und Downloads unterschieden. Zudem kann es sich um operative oder administrative Auftragsarten handeln. Unter administrativ sind diejenigen zu verstehen, die das  EBICS-Protokoll selbst steuern, zum Beispiel HIA und INI für den Schlüsselaustausch oder HVU zum Abruf der VEU-Übersicht. Die operativen Auftragsarten hingegen kennzeichnen den fachlichen Inhalt eines Dateitransfers, etwa CCT für Zahlungen im Format des SEPA Credit Transfer. Auf diesem Wege wird bei operativen Auftragsarten die Art der formatspezifischen Verarbeitung bestimmt.

Mit EBICS ist eine Liste der zu nutzenden operativen Auftragsarten spezifiziert sowie die damit zu verwendenden Geschäftsvorfälle und Formate. Diese operativen Auftragsarten werden derzeit vorrangig in Deutschland genutzt.

In Frankreich nutzt man für operative Aufträge unabhängig vom Dateninhalt generell genau eine Auftragsart für Uploads (FUL) und eine Auftragsart für Downloads (FDL). Um dem Bankrechner dann aber Hinweise auf das enthaltene Format mitzugeben, wird vom Client der Auftragsart noch ein bis zu 40-stelliger Formatparameter mitgegeben. Dessen Aufbau ist ebenfalls mit EBICS spezifiziert.

Wie gut verstehen sich Bankrechner und Client?

Sowohl für die deutsche als auch für die französische Art der Auftragsarten-Nutzung lassen sich bankseitige formatspezifische Berechtigungsprüfungen hinterlegen. Dabei ermöglichen einerseits die Formatparameter eher eine detailliertere Vereinbarung zwischen Kunde und Bank über die Art der auszutauschenden Inhalte (zum Beispiel SEPA-Version, Länderausprägung), andererseits sind die Auftragsarten für einen Kunden gegebenenfalls einfacher zu handhaben, da dieser sich um die Formatdetails im EBICS keine Gedanken machen muss. Wichtig ist aber, dass EBICS-Bankrechner und Client sich verstehen. Dazu muss der Kunde sehr wohl wissen, was sein Gegenüber, der Bankrechner, versteht.

Beide Arten des Austausches von operativen Daten zwischen EBICS-Client und EBICS-Bankrechner haben ihre Vor- und Nachteile. Letztendlich entscheidet der Firmenkunde, und  der hat möglicherweise Konten bei mehreren Kreditinstituten in unterschiedlichen Ländern. Dieser Kunde fordert ein einheitliches Vorgehen. Der Erfolg von EBICS entscheidet sich daher gleichfalls in der Einheitlichkeit der Nutzung beziehungsweise in der  Interoperabilität der Nutzungsvarianten von EBICS. Hier sind die Spezifizierer gefragt. Wie der Beitrag von Carsten Miehling vom 9.9.2014 zeigt, ist hier der Prozess bereits in Bewegung.

Michael Lembcke 

Weiterlesen

Serverseitige Erneuerung der EBICS-Zertifikate

Was die französische Version des EBICS-Protokolls anbelangt, so wurden die EBICS-Server überwiegend Ende 2009 sowie im Laufe des Jahres 2010 in Betrieb genommen. Viele von ihnen verwenden selbstsignierte X.509-Zertifikate mit einer Laufzeit von fünf Jahren, weshalb einige Institute bereits mit deren Erneuerung begonnen haben bzw. sich andere darauf vorbereiten.



Auf Kundenseite sieht das EBICS-Protokoll bei der Zertifikatserneuerung entsprechende EBICS-Nachrichten (PUB-, HCA- und HCS-Nachrichten) mit einer entsprechenden client- und serverseitigen Verarbeitung vor, so dass manuelle Eingriffe prinzipiell entfallen (signierte Nachrichten, die keiner zusätzlichen Validierung bedürfen). Bei der serverseitigen Erneuerung der Bankzertifikate verhält es sich jedoch anders: Lediglich die HPB-Nachricht ist dafür derzeit in EBICS verfügbar. Die Validierung der Bankzertifikate umfasst einen manuellen Schritt, nämlich den Abgleich des entsprechenden Hash-Werts. Ein weiterer beträchtlicher Unterschied liegt in der Tragweite des Vorgangs, der sich auf mehrere Tausend Kundenzugänge gleichzeitig auswirken kann.

Um diesen Eingriff im Umgang mit Zertifikaten in EBICS zu erleichtern, sind eine Reihe von Vorkehrungen und Vorsichtsmaßnahmen erforderlich.

Aus unseren Erfahrungen in der Entwicklung und Implementierung von EBICS-Software auf Kunden- wie auf Bankseite konnten wir für die Zertifikatserneuerungen einige Erkenntnisse ableiten. Wir möchten daher denjenigen, die sich mit der EBICS-Server-Administration befassen, folgende Empfehlungen geben:

- Erkundigen Sie sich bei Ihrem Software-Anbieter, nach welchem Verfahren die Zertifikate generiert und aktualisiert werden.

- Meiden Sie bei der Auswahl von Datum und Uhrzeit solche Zeiträume, in denen üblicherweise hohe Belastungen herrschen (Monatsende, Cut-off-Zeiten etc.) oder nur wenige Mitarbeiter auf Kundenseite verfügbar sind (am späten Abend, nachts, in den Schulferien etc.). Da das Ablaufdatum der Zertifikatsgültigkeit vorhersehbar ist, können vorbereitende Maßnahmen schon im Vorfeld ergriffen werden, um sich einen zeitlichen Spielraum zu verschaffen.

- Informieren Sie die Kunden langfristig im Voraus über Datum und Uhrzeit für den Wechsel der Bankzertifikate. Es ist sinnvoll, einige Tage vor dem Termin ein Erinnerungsschreiben zu versenden. Nachfolgend einige Punkte, die ein solches Schreiben unserer Ansicht nach enthalten sollte:

• Dem Kunden die Kontaktaufnahme mit seinem Softwareanbieter nahelegen, damit der Kunde sicherstellt, dass seine Software die Erneuerung der Bankzertifikate unterstützt und er eine Ablaufbeschreibung der Zertifikatserneuerung erhält, sofern er noch keine besitzt. Wir haben ermittelt, dass zwei verschiedene Kundenprodukte diesen Vorgang nicht zulassen. In beiden Fällen waren die Kunden gezwungen, ihre Zugänge vollständig neu anzulegen.
• Den Kunden bitten, das Schreiben vom Softwarehersteller ggf. an den Dienstleister weiterzuleiten, dem er einen DFÜ-Zugang übertragen hat. Denn der vorgenannte Punkt gilt für den Dienstleister gleichermaßen.
• Den Hash-Wert des neuen Bankzertifikats angeben, damit der Kunde den Hash angleichen kann. Die übliche Darstellung als Matrix aus 4 Zeilen zu je 8 Bytes lässt sich durch eine lineare Darstellung (die 32 Bytes in derselben Zeile ohne Trennzeichen) ergänzen, um das Kopieren und Einfügen in die Software des Kunden zu vereinfachen.
• Den Kunden darauf hinweisen, dass, sofern er seine Einstellungen nicht rechtzeitig aktualisiert, der erste Transfer unter Ausgabe eines Fehlercodes mit dem Wert 091008 und der Kennzeichnung EBICS_BANK_PUBKEY_UPDATE_REQUIRED fehlschlägt. Vor einem erneuten Anstoßen der fehlgeschlagenen Transfers muss er zunächst die neuen Bankzertifikate einspielen.
• Dem Kunden empfehlen, sich mit dem echten Zertifikatswechsel vorab vertraut zu machen, indem er das aktuelle Bankzertifikat wiederholt abholt (HPB). So lässt sich der Zertifikatswechsel der Bank mit der Client-Software jederzeit simulieren.

Die aktuellen Möglichkeiten zur Erneuerung der EBICS-Bankzertifikate gewährleisten derzeit keinen reibungslosen Ablauf. Ich bin mir sicher, dass es der EBICS-Gesellschaft so wie im Falle der Order-ID gelingt, in der nächsten Zeit Abhilfe zu schaffen und den Standard so weiterzuentwickeln, dass auch dieses Problem gelöst ist.

Marc Dutech 

Weiterlesen

Mehr Sicherheit, geringere Kosten: STEP2 Clearing mit EBICS

Seit Ende letzten Jahres bietet die EBA Clearing neben SWIFT auch EBICS als Zugangskanal für STEP2 an. Die Blaupause dafür stammt von der Deutschen Bundesbank, die bereits 2008 ihren SEPA-Clearer über SWIFT und EBICS zugänglich machte. Was sind die Gründe, warum EBA Clearing neben einem SWIFT- auch noch einen EBICS-Zugang anbietet? Der Anstoß dazu kam von einigen Banken und Sparkassen aus Deutschland. Die Motivation waren die Kosten: Bei EBICS fallen keine Transaktionskosten für den Transport an.


Im bilateralen Clearing zwischen den Banken, das in Deutschland auch als "Garagen-Clearing" bekannt ist und extensiv genutzt wurde, fallen für den Transport und das Clearing keine Kosten an. Die jeweils beteiligten Banken tragen die Kosten für den Transport und das Clearing selbst. Bei der Umstellung auf ein zentrales Clearing fallen natürlich Kosten für das Clearing an. Um die Kosten nicht noch weiter in die Höhe zu treiben, sollten die Kosten für den Transport, die jedes Kreditinstitut selbst trägt, so gering wie möglich gehalten werden. Daher fiel die Entscheidung auf EBICS, da bei EBICS – abgesehen von reinen Betriebskosten – keine Transaktionskosten für den Transport anfallen.
Ein zweiter Aspekt wird zudem immer wichtiger: Sicherheit! Im Interbankenzahlungsverkehr liegen die täglichen Geldmengen im Milliardenbereich. Eine Störung des Geldflusses von wenigen Stunden führt bereits zu Verwerfungen, die erhebliche Auswirkungen für die Wirtschaft haben können. Daher wird zunehmend die Frage nach einem Backup-Transportverfahren für das Clearing im Interbankenzahlungsverkehr gestellt. Auch dafür würde sich EBICS hervorragend eignen, beispielsweise EBICS als Backup für SWIFT. EBICS und SWIFT werden bereits bei einigen Banken parallel für das Clearing eingesetzt. Es scheint zudem unwahrscheinlich, dass sich der Regulierer auf Dauer mit einem einzigen Transportverfahren begnügt. In fast allen Bereichen der Bank wurden die Sicherheitsanforderungen deutlich verschärft, zum Beispiel durch die PSD II. Eine zukünftige Verschärfung der Sicherheitsanforderungen im Interbankzahlungsverkehr scheint daher nicht ausgeschlossen zu sein.

Weiterlesen

Meeting EBICS Working Group: Schweiz sorgt für neuen Schwung bei EBICS

Die Schweizer EBICS-Arbeitsgruppe will noch im September ihre Ideen, insbesondere zu den Auftragsarten, beschreiben. Das ist ein Kernergebnis des Treffens der EBICS Working Group am 28. August. Erstmals seit Bestehen der Deutsch-Französischen EBICS-Kooperation fand es in der Schweiz statt. Hintergrund ist, dass mit der Schweiz ein weiterer Kandidat für die Beteiligung an der EBICS-Gesellschaft in den Startlöchern steht. In Gehdistanz zum Schweizer Antragsteller SIX Interbank Clearing diskutierten die Experten aus den drei Ländern im Hotel Renaissance in Zürich die aktuelle Situation der Schweiz und die geplanten Erweiterungen am neuen elektronischen Zahlungsverkehrsstandard.


Schon der Start der Debatte verlief recht fulminant, stand doch wieder einmal die Frage im Raum, ob die Schweiz eher das Auftragsartenmodell Deutschlands oder die Fileparameter-Variante (FUL/FDL) Frankreichs für die nationale Anwendung verwenden sollte. Albert Apolloner, Leiter der Schweizer EBICS-Arbeitsgruppe stellte in seiner Präsentation die Vor- und Nachteile der jeweiligen Lösung aus Schweizer Sicht dar. Sein Fazit favorisierte die Fileparameter-Variante, welche bereits grundlegende Anforderungen des Schweizer Finanzmarktes abdeckt und als flexibler beurteilt wird. Die deutschen Vertreter verwiesen auf ihre Lösung, mit der jede Transaktionsart einem Issuer, zum Beispiel der Schweiz oder einer größeren Bank, zugeordnet werden kann.

Aus der Diskussion entsprang die Idee, alle deutschen Transaktionsarten gemäß der Fileparameterlogik zu übersetzen. Die Clientsoftwarehersteller würden dann ausschließlich diese Logik in ihren Clients implementieren, was insbesondere im Hinblick auf die Ausweitung in neuen Märkten wie die Schweiz, Spanien, Portugal und andere Kandidaten interessant wäre. Um die Aufwände seitens der deutschen Institute zu minimieren (die bekannten dreistelligen Auftragsarten werden aktuell bis weit in die Verarbeitung weitergereicht), könnte man sich ein Mapping in den Bankrechnerprodukten vorstellen. Aus der Transaktionsart AZV würde dann zum Beispiel pain.xxx.azv. In Kombination mit dem Ländercode und dem sogenannten "Name-/Value-Pair" könnten die Anforderungen jedes Landes und sogar weitere Merkmale großer Marktteilnehmer, wie zum Beispiel „es handelt sich um eine Datei in der Ausprägung Credit Suisse“, abgedeckt werden.
Man kann sich vorstellen, dass auf deutscher Seite nicht gerade ein Begeisterungssturm für die Idee ausgelöst wurde. Als zukünftige Vision für eine EBICS-Harmonisierung könnte man sich aber ein solche Migration durchaus vorstellen. In der Umsetzung könnten sicherlich beide Verfahren für einen Übergangszeit als Standard weiterbestehen. Neue Märkte würden zum eigenen Vorteil gleich auf die universellere Variante FUL/FDL setzen.

Im zweiten Teil des Meetings kam das Thema Sicherheit auf den Tisch, bei dem Deutschland und Frankreich ebenfalls andere Wege gehen. Alain Hiltgen (UBS) regte an, im EBICS Implementation Guide die Verwendung von Hardtokens für das Aufbewahren von Schlüsseln und Zertifikaten zu empfehlen.

Nach dem Mittagessen präsentiert Sabine Wenzel (SIZ) den Schweizer Teilnehmern die EBICS-Gesellschaft, die Organisation und die Entscheidungsprozesse für zukünftige Erweiterungen. Gemäß der aktuellen Planung wäre es bis Ende November 2014 möglich, noch Change Requests für das Release 2.6 (wahrscheinliche Inkraftsetzung 2016) einzureichen. Die Schweizer Arbeitsgruppe will sich noch im September treffen und ihre Ideen, insbesondere zu den Auftragsarten, beschreiben. Idealerweise können diese dann bereits beim nächsten Meeting der internationalen EBICS Working Group im November in Paris diskutiert werden.

Fazit: Ein sehr interessantes Forum für alle EBICS-Begeisterten. Es hinterlässt den Eindruck, dass ein neuer Spieler im Team etwas Schwung in die EBICS-Weiterentwicklung bringen könnte. Fortsetzung folgt.

Carsten Miehling 

Weiterlesen

Das Schlüssel-Birchermüsli

Wie bereits im Blogbeitrag vom 25.07.14 „EBICS auch in der Schweiz angekommen“ erwähnt, gesellt sich nun langsam aber sicher auch der Finanzplatz Schweiz zur EBICS-Gemeinde der beiden großen Nachbarn Deutschland und Frankreich. Bekanntlich interpretieren die Franzosen EBICS etwas anders als die Deutschen und die Schweizer Akteure fragen sich, welche Variante für sie wohl die bessere sei. Bei den Auftragsarten geht die Tendenz aktuell Richtung Frankreich, also FUL/FDL in Verbindung mit den Formatparametern anstelle der vielfältigen Sammlung an Auftragsarten in Deutschland. Komplizierter wird es bei der Anwendung der elektronischen Unterschriften: Wie sollen diese konkret beim Kunden implementiert werden? 

Die deutsche Variante der selbstgenerierten Schlüsselpaare für die Verschlüsselung (E002), Authentisierung (X002) und eben für die Signatur (A005/A006) ist die aktuell in der Schweiz produktiv eingesetzte Variante, wobei das bisher in Deutschland genutzte Konzept der VEU (Verteilte Elektronische Unterschrift) erst in der Planung ist. Dieses erlaubt Unterschriftsmodelle mit mehreren personenbezogenen Signaturen, die mit oder auch nach dem Auftragsversand erstellt und eingereicht werden können. Die Großbanken der Schweiz setzen allerdings aktuell nur die Einzel- und Transportunterschrift ein. Bei der Einzelunterschrift handelt es sich in der Regel um eine sogenannte „Corporate Seal“, d.h. es wird eine Firma identifiziert und nicht die Person, welche tatsächlich den Auftrag freigegeben hat. Die Verwaltung der Nutzung dieser „Corporate Seal“ wird in der Software des Kunden geregelt. Bei der Transportunterschrift erfolgt die Freigabe auf einem separaten Kanal, jedoch nicht wie in Frankreich noch verbreitet manuell mittels Begleitzettel, sondern via Zugriff über Onlinebanking.

Diese Praxis gerät allerdings zunehmend in die Kritik der Rechts- und Sicherheitsabteilungen der Schweizer Finanzinstitute, welche eine eindeutige Authentisierung der Person verlangen, die den Auftrag signiert hat. Die VEU wäre in diesem Fall sicher ein geeignetes Mittel, wobei die Banken aktuell noch die zusätzlichen Prozessaufwände scheuen, welche die Verwaltung der Unterschriftenregeln auf Bankseite mit sich bringen würde.

Als attraktive Kombination wird dabei das Modell TS (Transport and Signature) in Frankreich mit den CA-basierten Zertifikaten für die elektronische Signatur angesehen, da hierbei das Problem der unbeschränkten Gültigkeit der Schlüssel entfällt und die zentrale Sperrung über die CA das Sicherheitsrisiko zu vermindern scheint. Idealerweise wird das Ganze dann noch kombiniert mit einem Hardtoken, welcher nur durch die Person, die den Auftrag erteilt, eingesetzt werden kann. „Wenn schon, denn schon“, ist man versucht zu sagen, aber so sind wir Schweizer eben. Wenn ein Standard solche Funktionalitäten hergibt, warum sollte man sie nicht nutzen? Hinzu kommt, dass es seitens des Regulators auch in die Richtung zu gehen scheint, dass Finanzinstitute in Zukunft nicht einfach mit einem Disclaimer im Vertrag die Risiken beim Einsatz von „Corporate Seals“ von sich weisen können (siehe dazu auch das Dokument der EZB „Assessment Guide for the Security of Internet Payments“).

Einheitliche Rezeptur gewünscht 

Das Problem hierbei ist die Vielfalt der EBICS-Varianten, die sich jetzt ergeben und die Frage, welche Variante dann im Markt von den Teilnehmern - Kunde, Softwarehersteller und Bank - umgesetzt werden soll. Gibt es jetzt CA-basierte Zertifikate und falls ja, für welche Art von Schlüssel? Welche CAs werden bankübergreifend akzeptiert? Welche Qualität sollte so ein Zertifikat aufweisen? Gilt die Anwendung von Hardwaretokens nur für die Signatur (A005/A006) oder auch für die anderen Schlüssel zur Authentisierung und Verschlüsselung? Wäre auch ein Einsatz von Hardtokens ohne CA denkbar, also nur die externe Aufbewahrung der Schlüssel beim signierenden Auftraggeber?

Das Ganze erinnert etwas an unser Birchermüsli, wo es ebenfalls die verschiedensten Varianten und Rezepte gibt. Die EBICS-Gesellschaft verfolgt ja das Ziel, den Standard in Europa zu etablieren. Hier wäre eine einheitliche Rezeptur für das Schlüssel-Birchermüsli sicher ein Pluspunkt, den auch die Anwender schätzen würden. Ansonsten wird es schwierig mit dem länderübergreifenden Standard. Meiner Meinung nach sollte dieser Punkt auf der Agenda der EBICS Working Group einen prominenten Platz einnehmen.

Carsten Miehling 

Weiterlesen

Portugal im Zeitalter von EBICS

So wie die französischen Banken 2009 und die deutschen Banken 2008 wollen nun auch zahlreiche portugiesische Banken im Finanzverkehr mit Unternehmen auf das EBICS-Protokoll umstellen.

Diese Umstellung hat zwei Hauptgründe:

1. die von Portugal Telecom geplante Abschaltung des X.25-Netzwerks zum 30. Juni 2014,

2. der Umstand, dass einige bisher verwendete Protokolle nicht in der Lage sind, Dateien mit Datensätzen variabler Größe zu übertragen, wie dies bei SEPA-Formaten der Fall ist.
Folglich mussten portugiesische Banken ihren Unternehmenskunden einen alternativen Übertragungskanal anbieten, der gut zugänglich, sicher, kostengünstig und grenzüberschreitend zugleich ist.


Angesichts der positiven Erfahrungen in Deutschland und Frankreich mit der Migration auf EBICS sowie mit dem täglichen Gebrauch des EBICS-Protokolls haben sich die portugiesischen Banken entschlossen, ihr Serviceangebot um den EBICS-Kanal zu erweitern. Einige unter ihnen haben sich dazu für die Lösung TRAVIC-Corporate entschieden, einen Bankserver von PPI.

Dabei fiel die Wahl auf die EBICS-Version 2.4, welche gegenwärtig auch in Frankreich verwendet wird. Betriebsbereit ist bis heute nur das T-Profil.

Die über den EBICS-Kanal vermittelten Daten können unterschiedlichster Art sein: Inlandszahlungen im Format PS2, Überweisungsaufträge im SWIFT-Format MT101, SEPA-Überweisungen (SCT) und SEPA-Lastschriften (SDD), Kontoauszüge, Confirming, Devisenkurse und -notierungen, proprietäre Formate für Schreiben mit abtrennbarem Scheck sowie für das Factoring etc.

Des Weiteren boten einige in Portugal ansässige Hersteller bereits vor mehreren Monaten unternehmensspezifische Softwarelösungen an, die das EBICS-Protokoll unterstützen. Dies gilt insbesondere für MetaCase, den portugiesischen Partner von PPI, der mit Target One ein System zur EBICS-Verwaltung in die von ihm herausgebrachte Verwaltungsplattform implementiert hat. Dass diese Implementierung des EBICS-Protokolls noch erfolgte, bevor portugiesische Banken ihren Kanal öffneten, ist dem Wunsch einiger portugiesischer Unternehmen geschuldet, Finanzdaten mit deutschen und/oder französischen Banken austauschen zu können.

Die von den meisten portugiesischen Banken getroffene Wahl verdeutlicht, wie sehr sich das EBICS-Protokoll für einen großflächigen Einsatz in Europa eignet und so zu einem sicheren, leichteren und kostengünstigen Datenaustausch zwischen Unternehmen und Banken innerhalb des SEPA-Raums beitragen kann.

Marc Dutech 

Weiterlesen

Vereinheitlichung des Zahlungsverkehrs durch SEPA ist noch Zukunftsmusik

Jetzt haben wir in Europa zwar schon SEPA für den einheitlichen Zahlungsverkehr eingeführt, aber dennoch lassen sich SEPA-Zahlungen nicht einfach elektronisch an jede beliebige Bank in Europa schicken. In Deutschland nutzen Unternehmen die Auftragsart CCT für die Einreichung der SEPA-Überweisung (SEPA Credit Transfer) bei Kreditinstituten. Weshalb sind SEPA-Überweisungen aus beliebigen Euro-Ländern mit dieser Auftragsart nicht ohne weiteres möglich?

Die XML-basierten SEPA-Datenformate wurden mittlerweile flächendeckend in den beteiligten europäischen Ländern eingeführt. Ziel war und ist es, nach der Einführung der einheitlichen Währung jetzt auch die Datenformate und Regularien im Zahlungsverkehr zu vereinheitlichen und so einen einfacheren innereuropäischen elektronischen Zahlungsverkehr zu ermöglichen.

Basierend auf den ISO20022 XML-Formaten und den Vorgaben des European Payments Council (EPC) wurden jedoch die Umsetzungen in den europäischen Ländern unter Berücksichtigung nationaler Ausprägungen des Zahlungsverkehrs separat ausspezifiziert. Als Ergebnis haben wir heute für die gleichen Geschäftsvorfälle länderspezifisch ausgeprägte SEPA-Formate.
Die Unterschiede beginnen bereits im Namensraum der Formate. Während zum Beispiel Deutschland für SEPA-Überweisungen mit pain.001.002.03 eine eigene Datenformatvariante eingeführt hat, nutzen andere Länder die pain.001.001.03 des EPC. Auch im Namespace des XML werden hier nationale Unterschiede deutlich. Zudem gelten national abweichende Belegungsregeln.
In Deutschland werden die SEPA-Zahlungen mittels EBICS mit den dreistelligen Auftragsarten gekennzeichnet und übertragen (zum Beispiel CCT für SEPA-Überweisung). Bei dem mit der Auftragsart verbundenen Format geht man laut Spezifikation  von der Formatausprägung der Deutschen Kreditwirtschaft (DK) aus. Was ist aber, wenn ein ausländischer Kunde in seinem nationalen Format eine SEPA-Überweisung an eine deutsche Bank schickt? Weder die Auftragsart noch der Namespace im XML liefern dabei einen verlässlichen Hinweis auf die verwendeten Formatbesonderheiten. Die Bank muss aber auf diese Besonderheiten reagieren, wenn sie grenzüberschreitend Zahlungsverkehr abwickeln will. Wie also können Banken die unterschiedlichen Formatausprägungen erkennen und entsprechend bearbeiten?

Mögliche Lösung: Issuer-Kennzeichen für EBICS

Solange keine vollständige Vereinheitlichung der SEPA-Formate, die zwischen Unternehmen und Kreditinstituten ausgetauscht werden, auf europäischer Ebene erfolgt, muss die Lösung an anderer Stelle gefunden werden. Dafür gibt es verschiedene Ansätze. Ein Ansatz fordert die Softwarehersteller heraus, die intelligente Formatparser oder spezielle Stammdatenerweiterungen im Bankrechner entwickeln müssten. Ein anderer und sicher langfristig sinnvollerer Ansatz ist, sich die Vorteile des EBICS-Standards zunutze zu machen.

In Frankreich hat man das Problem bereits gelöst, durch Nutzung der Formatparameter und des mit EBICS übermittelten Country Codes. Aus dem Country Code kann der EBICS-Bankrechner die länderspezifische Formatausprägung ableiten und somit eigene Verarbeitungswege initiieren. In Deutschland ist der Einsatz von Formatparametern allerdings nicht üblich. Daher wird derzeit in Deutschland die Einführung eines Issuer-Kennzeichens für EBICS diskutiert. Dieses würde zu dem Geschäftsvorfall den Herausgeber des Formats und somit die Formatausprägung mitliefern. Ein Bankrechner kann daran erkennen, ob beispielsweise für die angegebene Formatkonstellation Vereinbarungen und Prüfregeln existieren. Wenn sich das französische Modell der Formatparameter mit Country Code nicht in Deutschland einführen lässt, so sollte zumindest das Issuer-Kennzeichen an der Auftragsart bald mit EBICS umgesetzt werden. Eine solche Lösung ist sinnvoll und hoffentlich bald mit EBICS verfügbar. Bis dahin müssen Banken und deren Kunden sich wohl noch mit anderen individuellen Lösungen begnügen.

Auf die Besonderheiten in der Nutzung der dreistelligen EBICS-Auftragsarten in Deutschland und der Formatparameter in Frankreich  werde ich in einem Folgebeitrag eingehen.

Michael Lembcke 
 

Weiterlesen

EBICS auch in der Schweiz angekommen

Werfen wir zunächst einen Blick zurück zum siebten Petersberger Electronic-Banking-Forum am 10. November 2011: Christian Schwinghammer von SIX Interbank Clearing Schweiz hielt dort einen Vortrag zum Thema „EBICS goes Europe – Wo steht die Schweiz?“. Christian Schwinghammer, seines Zeichens ein großer Kenner des Finanzplatzes Schweiz, war schon damals recht zuversichtlich, dass der Standard sich auch bei den Schweizer Finanzinstituten durchsetzen wird, zumal mit UBS und Credit Suisse bereits zwei Schwergewichte den Kommunikationskanal EBICS im Angebot hatten.

Wie so oft will aber auch in diesem Fall gut Ding Weile haben. Die oftmals angekündigte Annährung zwischen der EBICS-Gesellschaft und den Schweizer Vertretern wurde ein ums andere Mal verschoben und kam nur harzig in die Gänge. Seitens der Bankmanager trat das Thema EBICS angesichts der intensiven Steuerdebatten mit Europa (Abgeltungssteuer) und den USA (FATCA) in den Hintergrund.

Nichtsdestotrotz konnte die EBICS-Arbeitsgruppe mit Vertretern der Schweizer Großbanken Anfang 2012 eine erste Version des „Implementation Guides EBICS“ zum Review versenden.

Schweizer Alleingang bei Implementierungsrichtlinien

Die Schweizer Implementierungsrichtlinien wurden damals unabhängig von der EBICS-Arbeitsgruppe erstellt, was in der Folge für Diskussionsstoff gesorgt hat und auch noch weiter sorgen wird. So bediente sich die Arbeitsgruppe für die Schweizer EBICS-Auftragsarten nach deutschem Vorbild bei den frei verfügbaren dreistelligen Auftragsarten. Konkret wurde dem Schweizer Datenträger-Austauschverfahren beispielsweise die Auftragsart „XKD“ zugewiesen. Weil sich UBS und Credit Suisse mehrheitlich an der deutschen Implementierung orientiert haben und die dreistelligen Auftragsarten bereits bei den Kunden im Einsatz sind, ist dieses Modell „de facto“ als Standard für die Schweiz gesetzt.

Trotzdem erscheint vielen Schweizern das französische „FUL/FDL“-Modell als flexiblere und architektonisch elegantere Variante. Ihr haftet nicht die deutsche Historie der dreistelligen Auftragsarten an, die schon im Vorgängerprotokoll FTAM verwendet wurden. Zudem scheint bei einer weiteren Ausweitung von EBICS auf zusätzliche Länder in Europa und der Welt der Vorrat an dreistelligen Kombinationen zur Neige zu gehen. Eine Umstellung auf das französische Modell wäre allerdings mit enormem Aufwand verbunden.

Obwohl in diesem Punkt also noch Uneinigkeit herrscht, scheint EBICS definitiv in der Schweiz angekommen zu sein. Die Einführung bei den Kantonalbanken von Luzern im Herbst dieses Jahres und Zürich Anfang nächsten Jahres wird der Verbreitung in der Schweiz den notwendigen Schub verleihen. Dem Vernehmen nach stehen bereits weitere Kantonalbanken in den Startlöchern und evaluieren EBICS-Lösungen für ihre Kunden. Auch in Bezug auf den Beitritt zur EBICS-Gesellschaft ist die Alpenrepublik einen grossen Schritt weiter gekommen: Es liegen konkrete Angebote zum Beitritt in die Gesellschaft vor und ein erstes Dreiländer-Treffen der EBICS-Arbeitsgruppe ist im August in Zürich geplant.

Es wird spannend zu beobachten sein, wie sich die „Ménage-à-trois“ in der Praxis bewähren wird. Den Schweizern könnte hier eine wichtige Rolle zukommen, sind sie doch bekannt für ihr diplomatisches Geschick und ihre Mehrsprachigkeit. Gerüchten zufolge war die Beziehung der deutschen und französischen Akteure in der Vergangenheit nicht immer nur harmonisch. Die Verwendung der bereits erwähnten frei verfügbaren Auftragsarten in der Schweiz ist unter anderem auch ein Auslöser für einen konkreten Change Request zu Händen der EBICS-Gesellschaft (EB-14-DK-int04 OrderType with issuer). Die Verwendung eines „Issuer Codes” zur jeweiligen Auftragsart soll die Verwendung von gleichen Auftragsarten in einer anderen Community erleichtern. Die Schweizer Auftragsart für einen Auftrag im Format pain.001 (CCT) könnte somit zum Beispiel eindeutig von derjenigen in Frankreich und Deutschland unterschieden werden, indem ein „Issuer Code“ für die Schweiz angefügt werden würde.

Weiterlesen

Die Luzerner Kantonalbank setzt auf EBICS

EBICS wird nun erstmals in vollem Umfang von einer Schweizer Kantonalbank unterstützt. Damit setzt die Luzerner Kantonalbank (LUKB) ein Ausrufezeichen in der Schweiz. EBICS soll schon in 2014 von der LUKB live eingesetzt werden. Es freut mich, dass sich EBICS weiter verbreitet und nun auch in der Schweiz deutlich an Fahrt gewonnen hat. Dazu hat auch die LUKB als First-Mover beigetragen.

Dass sich EBICS in der Schweiz so schnell durchgesetzt hat, hat aus meiner Sicht folgende Gründe:

1. EBICS nutzt das Internet als Übertragungsmedium, das im Prinzip in jedem Unternehmen vor-handen ist. Damit ergeben sich für Firmen günstige Übertragungskosten. Zudem können EBICS-Produkte für Firmen in einem relativ großen Markt erworben werden, was wiederum ein gutes Preis-Leistungsverhältnis begünstigt.
2. In der Schweiz gab es bis dato keinen einheitlichen Standard für die elektronische Kommunikation zwischen Firmenkunde und Bank. Hätte man sich entscheiden, einen Standard selbst zu entwickeln, wäre das Ergebnis dem EBICS-Standard höchstwahrscheinlich sehr ähnlich gewesen. Deshalb lag es nahe, sich des Originals zu bedienen.
3. EBICS ist ein Standard, der von Banken für Banken gemacht wurde. Daher passt der EBICS-Prozess grundsätzlich auch zu Schweizer Geldinstituten. Mit einem Beitritt in die EBICS-Gesellschaft eröffnet sich für sie zudem die Möglichkeit, eigene Änderungsvorschläge einzubringen.
4. Innovativ an EBICS ist vor allem die Multibankfähigkeit. Auch wenn das Für und Wider hier ausführlich diskutiert wurde: Ausschlaggebend war letztlich die Verbesserung des Services für den Kunden, die auch für die Schweizer Banken im Vordergrund steht.
5. Ebenso kontrovers diskutiert wurde die Verteilte Elektronische Unterschrift (VEU). Anders als in Deutschland kann in der Schweiz jede Bank individuell entscheiden, ob sie diesen Service den Kunden anbieten möchte oder nicht. Dass die Geldinstitute hier frei wählen dürfen, erleichtert die Einführung von EBICS.
6. Natürlich war für die Schweiz auch ein entscheidender Faktor, dass Deutschland und Frankreich schon EBICS einsetzen und europäisch agierende Firmen nach EBICS fragen. Zudem können so auch international neue Kunden gewonnen werden, ohne dass die Infrastruktur der Firmenkunden geändert werden muss.

Ich denke, dass dies auch die wesentlichen Gründe für die LUKB waren, EBICS zu nutzen. Besonde-res Augenmerk muss man auf die VEU legen: Es wird sehr interessant zu beobachten sein, wie sie sich entwickelt, wenn die ersten Banken bzw. deren Kunden sie nutzen.

Weiterlesen