Posts mit dem Label Payment Products werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Payment Products werden angezeigt. Alle Posts anzeigen

EBICS und PSD2 – Wie kommt das zusammen?

Die Zahlungsdiensterichtlinie PSD (Payment Services Directive) des Europäischen Parlaments ist die rechtliche Grundlage für den EU-weiten einheitlichen Binnenmarkt im Zahlungsverkehr. Die aktuelle Version PSD2 wurde am 23.12.2015 im Amtsblatt der Europäischen Union veröffentlicht und muss bis zum 13.01.2018 in nationales Recht umgesetzt sein. Welche Auswirkungen hat die PSD2 auf EBICS?


Ziele der PSD2 sind insbesondere:
  • strengere Sicherheitsanforderungen an den elektronischen Zahlungsverkehr
  • Schutz der Finanzdaten von Verbrauchern
  • Öffnung des Markts für Zahlungsverkehrsdienstleister, insbesondere bei den Diensten für Verbraucher und Unternehmen
  • Stärkung der Verbraucherrechte, z. B. bei der Haftung für nicht autorisierte Zahlungen und Erstattungen bei Lastschriften in Euro
  • Untersagung der Berechnung von Aufschlägen, unabhängig vom Zahlungsinstrument
Strengere Sicherheitsanforderungen an den elektronischen Zahlungsverkehr fordern, dass der Zugriff auf Kundenkonten sicher ist. Die Identifikation eines Zahlungsdienst-Nutzers oder einer Transaktion erfordert eine starke Authentifizierung. EBICS erfüllt diese Voraussetzungen mit den asymmetrischen benutzerbezogenen Schlüsselverfahren. Der praktischen Umsetzung einer starken Authentifizierung steht somit nichts entgegen.

Die drei Grundpfeiler einer starken Authentifizierung sind bekanntlich Besitz, Inhärenz und Wissen. Mindestens zwei dieser Kriterien sind den Nutzern beim Zugang zur EBICS-Autorisierung anzubieten. Beispielsweise ermöglicht eine Chipkarte (Besitz) als EBICS-Schlüsselmedium über einen Chipkartenleser per PIN-Eingabe (Wissen) eine Autorisierung. Dies muss in der Schnittstelle zum Nutzer also client-seitig umgesetzt sein.

Neben den EBICS-Mitteln zur eindeutigen Identifikation und Authentifizierung der Person kann die Bank zusätzliche verstärkende Prüfungen vorsehen (Inhärenz), z. B. ob in der Kommunikation die zuvor vereinbarten IP-Adressen genutzt werden. Eine nicht passende IP-Adresse verhindert bei ansonsten passender Authentifizierung den Zugang.

Die geforderte Dynamik in der Authentifizierung bildet EBICS durch das elektronische Signaturverfahren ab, denn die Signatur wird stets über den Hashwert der Originaldatei und einen Timestamp gebildet.

Zudem ermöglicht es die EBICS-Funktion der Verteilten Elektronischen Unterschrift (VEU), auf Seiten der Zahlungsdienst-Nutzer die Infrastrukturen für Zahlungseinreichungen und Autorisierungen zu trennen. So kann z. B. die Einreichung über einen Automaten per EBICS unautorisiert erfolgen und die vorgeschriebenen Autorisierungen nachträglich per Mobile-App, EBICS-Portal oder mit sonstigen EBICS-Clients, also räumlich und zeitlich getrennt. Außerdem können die Autorisierungsbedingungen vorschreiben, dass mehrere Personen beteiligt sind. Dies bieten heutige EBICS-Lösungen wie EBICS-Portale, EBICS-Browserlösungen, EBICS-Mobile-Clients sowie sonstige EBICS-Clients bereits. Es gilt, diese Techniken für die PSD2 konsequent anzubieten und zu nutzen.

Den Zahlungsverkehrsmarkt für Zahlungsverkehrsdienstleister zu öffnen, bedeutet, dass Banken den Anwendungen von Drittanbietern den Zugang zu Kundendaten geben müssen – wenn der Kunde dem zustimmt. Um diese Anforderung umzusetzen, sind Schnittstellen gefragt. Eine nutzbare Schnittstelle bietet der EBICS-Standard selbst. Sofern der Drittanbieter sich die Informationen nicht direkt über den Standard-EBICS-Zugang beschaffen kann, sind u. a. schnelle und flexible APIs gefragt, die die geforderten Daten bedarfsgerecht austauschen. Dabei sind Einheitlichkeit und Mehrfachnutzbarkeit wünschenswert.

In der Praxis werden Nutzeraktivitäten und insbesondere Autorisierungen in E-Banking- und ZV-Anwendungen bereits aufgezeichnet. Die mit der PSD2 angestrebte Stärkung der Verbraucherrechte fordert allerdings von den Dienstleistern und Banken, die Zahlungsverkehrsabläufe und Autorisierungen im Nutzerkontext nachvollziehbar und nachweisbar möglichst vollständig zu protokollieren und aufzubewahren. Dies gilt im Kontext von EBICS für Banken, aber auch für Diensteanbieter, die z. B. EBICS-Client-Anwendungen betreiben.

Zusammengefasst hat die PSD2 zunächst keinen direkten Einfluss auf die EBICS-Spezifikation selbst. Allerdings müssen EBICS-Nutzer die PSD2 im Nutzungskontext berücksichtigen. Die Anforderungen der PSD2 sind also für den Betrieb und die Nutzung von EBICS-Lösungen frühzeitig zu definieren und umzusetzen. Die Zeit läuft.

Michael Lembcke

“Offline Zahlungs-Software im Visier von Hackern – Schweizer Unternehmen betroffen”

Obige Schlagzeile ist der Mitteilung der Melde- und Analysestelle Informationssicherung MELANI im Juli dieses Jahres entnommen. Sie beschreibt eine neue Art von Hacker-Angriff auf Unternehmen in der Schweiz.

Firmen verwenden heute für die Abwicklung von Massenzahlungen, insbesondere bei Multibank-Verbindungen, in der Regel eine sog. Offline-Software für die Übermittlung, Freigabe und Ausführung von elektronischen Zahlungsaufträgen. Dabei werden Überweisungen automatisiert direkt aus der ERP-Software ausgelöst und über sichere Protokolle an die Bank übermittelt. Diese Art der Zahlungsverkehrsabwicklung macht den Großteil der heute in der Schweiz elektronisch eingereichten Aufträge aus.


Die in der Meldung von MELANI beschriebene Schadsoftware „Dridex“, die sich über schädliche Microsoft Office Dokumente in E-Mails von vermeintlich legitimen Absendern verbreitet, fokussiert seit neuestem genau diese Offline-Software-Lösungen. Dabei werden gezielt Hersteller attackiert, die im Schweizer Markt eine gewisse Verbreitung haben. Viele Firmen sind aktuell etwas verunsichert, wie sicher ihre Lösung in Tat und Wahrheit noch ist und wie sie sich gegen ähnliche Hacker-Angriffe schützen können.

Zunächst gelten einmal die von MELANI seit langem publizierten Sicherheitshinweise wie Verwendung dedizierter Computer, Ignorierung von Mails mit verdächtigen Attachments, regelmäßige Aktualisierung von Betriebssystemen und Virenschutzprogrammen etc., um die Absicherung der eigenen Infrastruktur zu gewährleisten. Ein Hinweis fällt dabei ins Auge, nämlich der, dass Kollektiv- anstelle von Einzelunterschriften eingesetzt werden sollen. Wie funktioniert das in der Praxis, wo ja keine Papier-Aufträge mehr physisch von den Bevollmächtigten der Firma signiert und an die Bank versendet werden?

Die Banken bieten hier grundsätzlich zwei Lösungen an (teilweise auch in Kombination). Einerseits ist die Freigabe über einen anderen Kanal möglich. Das heißt, die Datei mit den Zahlungsaufträgen wird beispielsweise über das Protokoll EBICS (Electronic Banking Internet Communication Standard) direkt aus der Offline-Software an die Bank übermittelt, wobei der Auftrag aber noch nicht zur Ausführung autorisiert wurde. Mittels Freigabe im Online-Banking der Bank können die Aufträge dann definitiv von einer zweiten Person freigegeben werden.

Eine weitere, sichere und flexible Art der Kollektiv-Unterschrift ist der Einsatz der im EBICS-Standard enthaltenen „Verteilten elektronischen Unterschrift“ (VEU). Der Standard sieht hierbei die Unterschriften-Modelle „Transport“- (keine Autorisierung), „Einzel“-, „Kollektiv A“- und „Kollektiv B“-Unterschriften vor. Pro Auftrag kann zudem auf Seiten der Bank ein Tageslimit definiert werden (wahlweise pro Kunde, Konto und Auftragsart). Die VEU erlaubt dem Kunden eine 1:1 Abdeckung der Unterschriftenregelung seiner Unternehmung und führt in Verwendung mehrerer Kanäle (z. B. Erteilung der zweiten Unterschrift über ein Mobile Device) zu einem sehr hohen Sicherheitsniveau.
Immer mehr Banken in der Schweiz führen die EBICS VEU als Angebot ihrer E-Banking-Lösungen ein. Erkundigen Sie sich bei Ihrem Institut explizit danach oder stellen Sie Ihre Fragen an info@ppi.ch, wenn Sie noch mehr Information zur EBICS VEU benötigen.

Original-Meldung MELANI: https://www.melani.admin.ch/melani/de/home/dokumentation/newsletter/offline-payment-software.html

Carsten Miehling 

EBICS mobil – jederzeit und überall

Michael Schunk, Product Manager, PPI AG

Das EBICS-Protokoll ist dafür ausgelegt, große Datenmengen zu übertragen, Kontoinformationen abzurufen und Aufträge zu autorisieren. Das sind die Grundbedürfnisse eines Schatzmeisters, die EBICS erfüllt und die den Erfolg von EBICS garantieren.
Im Zeitalter der Digitalisierung werden immer mehr Informationen immer schneller bereitgestellt. Dieser Anforderung kann sich auch EBICS nicht entziehen. Die Antwort darauf sind mobile EBICS-Apps, die den Kunden schnell informieren.

Der Geschwindigkeitsvorteil von EBICS-Apps resultiert aus zwei Aspekten:
  • Push-Nachrichten
    Gezielte Push-Nachrichten ersparen dem Nutzer die Abfragen. Er wird aktiv über ein Ereignis informiert, z. B. eine Freischaltung oder einen Zahlungseingang.
  • Ortsunabhängigkeit
    Smartphones erlauben einen fast grenzenlosen Zugriff auf Informationen. So kann man eine EBICS-Signatur beispielsweise während eines Meetings leisten.
Die ersten EBICS-Apps hatten gravierende Fehler, die einem den Gebrauch vermiesen:
  • Download
    Um eine Datei zu unterschreiben, muss die gesamte Datei heruntergeladen werden. Das können viele Megabytes sein. Dabei vergeht einem jede Lust am Unterschreiben, und das monatliche Download-Volumen ist schnell aufgebraucht.
  • Performance
    Beim Abruf der Kontoinformation muss eine XML-CAMT-Nachricht zuerst analysiert (neudeutsch: geparst) werden. Die kleine CPU des Smartphones zieht dabei so viel Strom, dass der Akku heiß wird und sich schnell entleert. In der Wartezeit kann man nicht einmal Mails abrufen, da das Smartphone voll ausgelastet ist.
  • Sicherheit
    Alle drei EBICS-Schlüssel werden auf dem Smartphone oder auf einem Server gehalten. Wird das Smartphone gestohlen, sind Angriffen Tür und Tor geöffnet. Die Schlüssel auf dem Server zu speichern, widerspricht allen Sicherheitsanforderungen.
Achten Sie beim Kauf von EBICS-Apps auf diese Kinderkrankheiten. Es sind immer noch zu viele davon auf dem Markt.

Doch zurück zum Schatzmeister. Was benötigt dieser?
  • aktuelle Informationen über Zahlungseingänge und -ausgänge
  • Autorisierung von Zahlungen
  • aktive Benachrichtigung, z. B. bei Freischaltungen oder erwarteten Zahlungseingängen
Der Schatzmeister will und muss stets auf dem Laufenden sein. Was mit klassischen EBICS-Kundensystemen noch unmöglich erscheint, wird durch EBICS-Apps Realität. Push-Services benachrichtigen den Kunden aktiv. Ist der Kunde nicht unterwegs oder möchte keine Push-Nachrichten empfangen, kann er per E-Mail informiert werden.

Die Abbildung zeigt die neue EBICS-App der HSH Nordbank für ihre Firmenkunden. Immer mehr Banken nutzen die digitalen Möglichkeiten und machen damit EBICS noch attraktiver.

Michael Schunk

Hacker-Angriffe auf den SWIFT-Zahlungsverkehr

81 Millionen US-Dollar – diese Riesensumme haben Kriminelle von der Zentralbank Bangladesch gestohlen. Nicht bei einem filmreifen Überfall, sondern ganz still mit einem Hacker-Angriff. Die Diebe veranlassten mehr als 30 Überweisungen vom Konto der Bangladesh Bank bei der New Yorker Federal Reserve Bank (Fed) auf philippinische Konten. Dieser und weitere Fälle zeigen: Der Interbanken-Zahlungsverkehr ist ein lohnendes Angriffsziel. Und die Sicherheit des internationalen Finanznetzes SWIFT ist verletzlich. Der Aufwand, dort einzudringen, ist sicherlich groß, aber die zu erwartende Beute noch größer. Angesichts solch professioneller Attacken steht die Sicherheit des Zahlungsverkehrs erneut ganz oben auf der Agenda.


Die Bangladesh Bank wurde im Februar 2016 auf zwei Ebenen angegriffen. Offensichtlich waren die IT-Sicherheitseinrichtungen mangelhaft: Die Zentralbank verfügt angeblich über keine Firewall und nur über veraltete Netzwerktechnik. Durch diese Tür gelangten die Diebe in das Banknetz und dort an die Zugangsdaten für Überweisungen. Im SWIFT-Client Alliance Access konnten sie sich damit als Auftraggeber der Transaktionen autorisieren. Für die Fed traten die Urheber als Zentralbank von Bangladesch auf.

Die Sicherheitslücke erlaubte es den Angreifern laut BAE Systems auch, eine eigens programmierte Schadsoftware im SWIFT-Alliance-Server zu installieren. Diese Software manipulierte die Bestätigungsnachrichten des SWIFT-Netzes und schaltete den Zugriffsschutz für die Datenbank aus. Die ausgeführten Transaktionen wurden nicht korrekt protokolliert, um die Spuren zu verwischen.
Der Hacker-Angriff hebelte die Sicherheitsmechanismen von SWIFT komplett aus und eröffnete den Dieben nahezu unbegrenzte Möglichkeiten. Die Gesamtsumme der angeforderten Transaktionen belief sich gar auf 951 Millionen US-Dollar. Ein ungewöhnlicher Tippfehler in einer Nachricht ließ eine beteiligte Bank in Bangladesch nachfragen, ob die Überweisung so gewünscht sei. Nur dadurch fiel der gesamte Betrug überhaupt auf. Da waren die 81 Millionen aber bereits überwiesen und in philippinischen Kasinos und Privathänden verschwunden. In der Folge mussten Atjur Rahman, der Chef der Zentralbank Bangladesch, und seine Stellvertreter im März 2016 zurücktreten.

SWIFT selbst hat eingeräumt, dass in den letzten Monaten mehrfach betrügerische Nachrichten über das Netz gesendet worden sind. Im Mai 2016 war eine Geschäftsbank von einem ähnlichen Betrugsfall betroffen: Kriminelle sind in die IT-Systeme eingedrungen, haben Nutzerdaten abgegriffen und Nachrichten manipuliert. Nun sollen Updates die Sicherheitslücken in der SWIFT-Software schließen.

Auch wenn SWIFT betont, der Angriff stelle nicht die Sicherheit des Netzes infrage, sondern die des Zugangssystems, zeigt der Fall das Dilemma geschlossener internationaler Netze. Auch mit hohem technischem Aufwand lassen sie sich nicht absolut abschotten. Außer der Software des Netzbetreibers können auch die umgebenden Banksysteme eine Schwachstelle sein. Ganz zu schweigen von kriminellen Mitarbeitern, die beim Betrug mithelfen. Und sind die Angreifer erstmal drinnen, steht ihnen die ganze Welt offen. Das schafft Anreize. Ein Verfahren wie EBICS nutzt das offene Internet und verfolgt ein Sicherheitskonzept, das stark auf Schlüsseln für die Kryptografie und Authentifizierung basiert. Das kann eine Alternative zum geschlossenen Netz sein.

Angesichts der potenziell sehr großen Schäden muss der Interbanken- und Firmenkunden-Zahlungs­verkehr umfassend geschützt werden. Es ist zu erwarten, dass Cyber-Attacken wie die hier beschriebene zunehmen. Letztlich müssen die Sicherheitsmechanismen des Verfahrens, der Bank-IT und für das Personal lückenlos ineinander greifen.

Michael Lembcke 

Wie sich EBICS verbessern lässt, Teil 8 – Doppeleinreichungen mit EBICS-Mitteln verhindern: Was geht da?

Schnell ist es passiert. Die Zahlungsverkehrsaufträge wurden per EBICS versehentlich doppelt zur Bank übertragen. Keiner hat es bemerkt. Gleich mehrere solcher Fehlerfälle fallen einem da ein:
  1. In der Zahlungserfassung wird eine Zahlung doppelt erfasst und gesendet.
  2. Die Datei mit den Zahlungsaufträgen wird erneut und damit doppelt übertragen.
  3. Die Zahlungsdatei wird aus technischen Gründen doppelt übertragen, da der Übertragungsstatus des ersten Transfers unklar war.
Wesentlich für eine Doppeleinreichung ist, dass ein Kunde eine Zahlung bzw. Datei mit identischen Angaben in einem festgelegten Zeitraum erneut bei der Bank einreicht. Aber ist eine identische Einreichung stets eine generell abzulehnende Doppeleinreichung? Nein, denn manche Zahlungen werden vom Einreicher bewusst mehrfach ausgestellt und übertragen.


Wie also kann die Bankseite echte Doppeleinreichungen sicher erkennen und einen Schaden für den Kunden abwenden?

Es ist möglich, zumindest offensichtliche Doppeleinreichungen bereits bei der Einreichung im EBICS-Bankrechner zu erkennen und abzulehnen.

Im Fall der technischen Doppeleinreichungen (siehe 3.) erkennt das EBICS-Protokoll bis zur EBICS-Version 2.4, wenn ein Kunde eine vom EBICS-Client vergebene Order-ID in einem definierten Zeitraum erneut verwendet. Ab EBICS V2.5 vergibt der EBICS-Bankrechner bereits beim Aufbau der Kommunikation eine eindeutige Order-ID. Ein Doppeleffekt wie bei EBICS V2.4 kann somit nicht auftreten.

Der Fall, dass eine Datei oder ein Auftrag aber versehentlich mit einem neuen Transfervorgang und somit einer neuen Order-ID noch einmal gesendet wird (siehe 2.), kann mit den bestehenden EBICS-Mitteln auf dem EBICS-Bankrechner derzeit nicht ausgeschlossen werden. Um dafür eine effektive Doppeleinreichungsprüfung auf Dateiebene zu ermöglichen, soll mit der nächsten EBICS-Version der EBICS-CR EB-14-08 DoubleUploadControl umgesetzt werden.

Dieser CR verpflichtet den EBICS-Client, einen Hashwert über die Zahlungsdatei an den EBICS-Bankrechner zu übermitteln. Der Client erstellt diesen Hashwert ohnehin für die Signaturerzeugung. Der EBICS-Bankrechner muss prüfen, ob der Hashwert im betreffenden Zeitraum schon mal vorgekommen ist, und den Auftrag bei Doppeleinreichung ablehnen.

Eine weitergehende Doppeleinreichungsprüfung, z. B. auf Einzeltransaktionsebene (Fall 1.) ist schon komplizierter und muss nach wie vor außerhalb von EBICS gelöst werden. Ggf. muss ein Bankmitarbeiter in Rücksprache mit dem Kunden ermitteln, ob die doppelte Einreichung nicht doch gewollt ist.

Mit dem geplanten EBICS-CR EB-14-08 DoubleUploadControl wird EBICS um eine weitere sinnvolle Funktion ergänzt und verbessert. Dies ist auch erforderlich. Versehentliche Doppeleinreichungen können so frühzeitig verhindert werden. Allerdings kommt damit kein Allheilmittel. Die Bankanwendungen können auf weitergehende Doppelprüfungen nach wie vor nicht verzichten.

Michael Lembcke 

UBS goes EBICS

Patrik Giger, Head Payment Connectivity Services, UBS Switzerland AG

Bereits zum fünften Mal in Folge konnte UBS im Rahmen des von Euromoney durchgeführten Cash Management Surveys 2015 die Auszeichnung als "Best Domestic Cash Manager Switzerland" entgegennehmen. Dieser Erfolg beruht auf langjährigem Fokus auf Kundenbedürfnisse und optimaler Produkt- und Servicequalität.

Ein Bestandteil dieses Serviceangebots ist die Infrastruktur für die Direktanbindung von Kundensystemen. Hier hat sich über Jahre eine Schnittstelle bewährt, welche auf einem proprietären Datenaustausch basiert. Diese Direktanbindung wird von Kunden in der Schweiz genutzt. International nutzen Kunden vorwiegend eine Anbindung über SWIFT for Corporates oder Multibank-Angebote, um Zahlungsdaten und Reportings mit ihrem Finanzinstitut auszutauschen.

UBS-Kunden können bereits heute ihre globalen Finanzgeschäfte - vor allem auch für internationale Niederlassungen - sicher abwickeln. Ein grosses Ziel mit der neuen Infrastruktur ist, die Anbindung an Finanzinstitute noch sicherer, komfortabler und standardisierter zu gestalten.


Harmonisierung Zahlungsverkehr als Chance – und Herausforderung

Mit dem Gemeinschaftsvorhaben "Harmonisierung Zahlungsverkehr" haben sich die Schweizer Banken auf Plan geeinigt, bis im Jahre 2020 den Zahlungsverkehr in der Schweiz auf den internationalen ISO-20022-Standard zu heben (Details siehe http://www.paymentstandards.ch).
Konkret werden sich in den nächsten 4 Jahren bestehende Formate und Prozesse verändern, um Synergien in der Wertschöpfungskette zwischen Zahlungsverkehrsdienstleistern, Finanzinstituten und den Konsumenten nachhaltig ausschöpfen zu können. Diese Synergien werden schlussendlich zu Vorteilen für alle involvierten Akteure im Zahlungsverkehr führen. Der zu begehende Weg dahin ist nicht nur steil. Auch die Zeitvorgabe, um das Ziel zu erreichen, wurde sportlich berechnet. Was oft unterschätzt wird, sind die Auswirkungen, die diese Transformation auf Kunden haben wird. So wird die Formatveränderung mit grosser Sicherheit auch Veränderungen in den Prozessabläufen bei Firmenkunden nach sich ziehen.

Software-Partner als Drehscheibe der Harmonisierung

Die Informatikabteilung der Kunden sowie die IT-Berater respektive Software-Häuser spielen eine tragende Rolle bei der Migration des schweizerischen Zahlungsverkehrs. So verwenden über 90 Prozent der UBS-Kunden eine Standard-Software eines im Markt etablierten Herstellers für die Direktanbindung an ihre Banken. Kunden haben hier die klare Erwartung, dass die entsprechenden ERP (Enterprise Ressource Planning) respektive TMS (Treasury Management Software) Programme zeitgerecht und verlässlich mit den neuen ISO-Formaten umgehen können. Um den Software-Häusern den Weg zu den neuen ISO-20022-Formaten zu vereinfachen, stellt UBS eine dedizierte Testplattform zur Verfügung. Über diese können sowohl mittels manuellem Upload als auch über einen EBICS-Kanal Testdateien hochgeladen und validiert werden. Testergebnisse enthalten nebst den standardisierten Fehlercodes sehr detaillierte Informationen über allfällige Fehler oder suboptimale Nachrichtengestaltungen. Die Testplattform bietet Software-Anbietern auch einen "Readiness Test" an, welcher ihnen und ihren Kunden die ISO-20022-Fähigkeiten attestiert.

Bewährte proprietäre Lösung wird ersetzt

Bereits seit 2013 bietet UBS ihren Kunden EBICS als Kommunikationskanal an. Dieses Angebot wurde vereinzelt von Kunden mit sehr spezialisierter Finanz-Software gewählt. Die Mehrzahl der Kunden setzt nach wie vor die proprietäre Lösung ein. Dies ist vor allem darauf zurückzuführen, dass der Zahlungsverkehr in der Schweiz sehr stabil ist und sich über Jahrzehnte sehr wenig verändert hat. Es gab keinen Grund für Kunden, wie auch für lokale Software-Anbieter, die bestehenden und funktionierenden Lösungen im Bereich Zahlungsverkehr anzupassen. Das gleiche galt auch für Banken.

EBICS als idealer Kanal für ISO 20022

Weshalb nun zu den Formaten auch noch gleichzeitig die Kommunikationskanäle verändern? Analysen haben ergeben, dass der Aufwand sowohl auf Kunden- als auch auf Software-Partner- und Bankseite vergleichbar hoch ist, die neuen Formate im alten (proprietären) Kanal einzubauen, beziehungsweise die Bereitstellung über den neuen standardisierten EBICS-Kanal sicherzustellen. Führende Schweizer Finanzdienstleister bieten die Anbindung über EBICS bereits an oder sind in der Planung, diese Anbindung in naher Zukunft anzubieten.

Der Vorteil des EBICS-Standards liegt auf der Hand: Kunden werden davon profitieren, dass "Banken die gleiche Sprache sprechen". In der Schweiz haben wir zudem den Vorteil, dass wir auf bereits Bewährtes zählen können, denn EBICS hat sich in den letzten 10 Jahren, seit der Einführung in Deutschland, als stabiler und verlässlicher Kommunikationsstandard etabliert. Mit dem Beitritt der Schweiz als drittes Mitgliedsland in die EBICS-Gesellschaft (neben Deutschland und Frankreich) ist ein klares Signal gesetzt, dass die Schweizer Finanzdienstleister EBICS nicht als Nebenprodukt, sondern als strategischen Kommunikationskanal fördern.

Ringen um standardisierte Auftragsarten

Betreffend der Auftragsarten hat sich in der Schweiz der deutsche Ansatz durchgesetzt (Angabe des Inhaltes mit der Auftragsart), verglichen mit dem französischen Ansatz, der als Auftragsart lediglich "Upload" und "Download" kennt. Die Auftragsarten in der "Schweizer Empfehlung" werden weitestgehend harmonisiert. Durch die Migration des Zahlungsverkehrs besteht die grosse Chance, hier noch einen Schritt weiter zu gehen. So ist aktuell die Schweizer EBICS-Auftragsart "XE2" für Inlandüberweisungen sowie für SEPA- und für Auslandüberweisungen gültig. UBS setzt sich dafür ein, dass künftig die Auftragsarten ausgebaut werden, um den vollen Synergieeffekt von ISO 20022 und EBICS erzielen zu können. Konkret diskutiert man separate EBICS-Auftragsarten für Inlandzahlungen, Auslandzahlungen und SEPA-Zahlungen. Dieser Vorschlag wird innerhalb der relevanten Gremien intensiv diskutiert und UBS hofft, dass sich hier eine Standardisierung mit zusätzlichem Synergieeffekt erzielen lässt.

UBS goes EBICS – Globally!

UBS hat sich entschieden, die bestehende Kommunikations-Infrastruktur für den Massenzahlungsverkehr in der Schweiz mit einer standardisierten EBICS-Infrastruktur zu ersetzen. UBS geht noch einen Schritt weiter und plant EBICS auch als künftiges Protokoll für ihre Kunden in den globalen Buchungszentren sowohl in Europa als auch in Asien und den USA. Wichtig für diese Umsetzung ist, dass die Infrastruktur stabil und standardisiert ist. Durch die enge Zusammenarbeit mit der Firma PPI sind wir zusätzlich in der Lage, Kunden ohne EBICS-fähige Software künftig ein Plug-in zu empfehlen, welches für die Software des Kunden die Kommunikation übernimmt. Ausserdem wird zukünftig die Möglichkeit des EBICS-Portals "UBS KeyPort Web" als Alternative angeboten, wenn Kunden ihre Transaktionen als Dateien manuell über ein Internetportal hoch- beziehungsweise die Reporting Meldungen herunterladen wollen.

Das EBICS-Angebot von UBS richtet sich in erster Linie an Kunden, welche das Bedürfnis nach einer Direktanbindung an ihre ERP- und TMS-Systeme haben und in zweiter Linie an Kunden, welche ein "Multi-Booking-Center"-fähiges Portal für ihre Massenzahlungen benötigen. Für Individualtransaktionen und zusätzliche Informationen steht unseren Kunden nach wie vor das moderne und sehr vielseitige UBS e-banking zur Verfügung.

EBICS muss sich weiterentwickeln

UBS wird sowohl den deutschen (DK) als auch den französischen Standard unterstützen. Die Dringlichkeit einer weiteren Harmonisierung ist gegeben, denn schon mit drei Mitgliedern der EBICS-Gesellschaft ist die Vielzahl der unterschiedlichen Implementierungen hoch. Eine entsprechende weitere Harmonisierung wird von der EBICS-Gesellschaft unter dem Projektnamen BTF vorangetrieben (vgl. Artikel in diesem Blog von Sabine Wenzel, EBICS SCRL, http://www.ebicsblog.com/de/international-harmonisch-mit-ebics-btf/). Aus Sicht des Autors ist es essentiell, dass diese Harmonisierung mit sehr hoher Priorität vorangetrieben wird. Wir sind zuversichtlich, dass sich EBICS weiter global als Kommunikationsstandard ausbreiten wird. UBS ist hier an vorderster Front mit dabei und setzt auf EBICS in der Schweiz, in Deutschland, in Europa, in Asien und in den USA.

Patrik Giger

EBICS und TLS 1.2 – etwas sicherer, aber nicht ohne Tücken

Curd Reinert, Projektleiter EBICS-Kernel, PPI AG


Wer einen Blick in die aktuelle EBICS-Spezifikation wirft, stellt womöglich überrascht fest, dass dort für die Transport Layer Security (TLS) noch die Version 1.0 vorgeschrieben ist. Das war mal eine sehr kluge Wahl: Bei Veröffentlichung der EBICS-Spezifikation war TLS 1.0 der Stand der Technik. Man hat sich also vor allem gegen SSL entschieden. Und damit waren die Hersteller und Betreiber z. B. bei POODLE fein raus: EBICS schließt SSL aus, die EBICS-Anwendungen waren vor POODLE sicher. Ohnehin hätte POODLE bei einem EBICS-Client kaum eine Chance: Der Angreifer bringt den Client dazu, tausende Anfragen an den HTTPS-Server zu schicken, um z. B. an das Session-Cookie zu kommen. Bei EBICS wird aber weder ein Session-Cookie genutzt, noch sind die Clients Web-Anwendungen, die man per JavaScript dazu bringen kann, tausende Anfragen zu schicken. Aber erklären Sie das mal der Revision!


Und das war ja auch nur einer der bösen Angriffe mit den lustigen Namen: HEARTBLEED nutzte einen Fehler in der TLS-Implementierung von OpenSSL aus. Und dann ist da noch BEAST. Wie schon bei POODLE eignet sich EBICS auch nicht für den BEAST-Angriff. Aber der Ruf von TLS 1.0 ist nachhaltig beschädigt, und alle Seiten raten zum sicheren Nachfolger TLS 1.2.

Das hat man auch bei EBICS erkannt und entsprechende Change Requests für die nächste Version vorgesehen, um TLS 1.2 zu unterstützen. Leider verzögert sich diese nächste Version, und in der Zwischenzeit fragen die Revisoren: Wieso macht ihr mit EBICS noch TLS 1.0? „Weil es so in der Spezifikation steht“, reicht als Argument kaum noch aus, wenn das BSI offiziell vor dieser Version warnt. Auf der offiziellen EBICS-Seite stehen darum jetzt Sicherheitsempfehlungen, die zu TLS 1.2 raten – ohne zu erklären, wie sich das mit der Spezifikation vereinbaren lässt.

Wir haben 82 EBICS-Server in Deutschland und Frankreich getestet: Gerade einmal 52 Server konnten mit uns TLS 1.2 sprechen. Wenn Sie sich also als Kundenprodukthersteller heute dazu entschließen, TLS 1.0 gar nicht mehr zu unterstützen, dann können Sie sich mit ca. einem Drittel der EBICS-Server nicht mehr verbinden. Server-Betreibern dürfte es mit den Kundenprodukten in den unterschiedlichsten Versionen noch schlechter ergehen.



Was kann man dann tun? Man kann TLS 1.2 anbieten, ohne TLS 1.0 zu verbieten. Das geht sowohl als Client als auch als Server, und im TLS-Handshake einigen sich beide Seiten auf die sicherste gemeinsame Variante – so die Theorie. Bei immerhin 28 der getesteten Server hat das auch funktioniert. Leider haben wir aber auch zwei Server gefunden, die die Kommunikation rigoros abbrechen, wenn der Client TLS 1.2 vorschlägt. Das ist für die Hersteller von Kundenprodukten sehr unangenehm, weil die Clients dann nicht einfach „auf Verdacht“ TLS 1.2 vorschlagen können – oder sie nehmen in Kauf, dass die Kommunikation mit einigen wenigen Servern scheitert.

Wir haben die Betreiber der beiden EBICS-Server benachrichtigt. Da unser Test aber nicht alle EBICS-Server umfasst, sollte jeder Betreiber das Verhalten seines EBICS-Servers selbst prüfen.
Eine Frage drängt sich noch auf: Wie gefährlich wäre eine Entschlüsselung des TLS-Layers in EBICS überhaupt; welche Daten wären sichtbar? Die Auftragsdaten selber werden ein zweites Mal verschlüsselt und bleiben für den Angreifer unsichtbar. Es bleibt der XML-Rahmen um die Auftragsdaten, oder wie man es in der Post-Snowden-Ära nennt: Metadaten. Das sind vor allem die Auftragsart bzw. das Fileformat, die Kunden- und die Teilnehmer-ID. Mit anderen Worten: nicht besonders viel. Ob man damit die Gemüter beruhigen kann, steht auf einem ganz anderen Blatt.

Curd Reinert

EBICS auf der iberischen Halbinsel

2014 haben die meisten portugiesischen Banken einen EBICS-Kanal eröffnet, der auf der Version 2.4.2 des Protokolls basiert. Tatsächlich eingesetzt wird bis dato allerdings nur das T-Profil, obwohl viele Unternehmen persönliche Signaturen verwenden möchten. Dies lässt darauf schließen, dass das TS-Profil in Kürze bereitgestellt wird.

Bis heute bieten nur sehr wenige spanische Banken ihren Firmenkunden die Möglichkeit, ihren Zahlungsverkehr über das EBICS-Protokoll abzuwickeln. Die Nachfrage danach nimmt jedoch immer stärker zu. Das beweist auch die hohe Teilnehmerzahl an einer Veranstaltung, die der Spanische Verband der Unternehmensfinanzierer (ASSET) am 20. Januar 2016 organisiert hat.
Einer der Gründe für das steigende Interesse liegt darin, dass bei den spanischen Unternehmen, wie bei den übrigen europäischen Unternehmen auch, der Bedarf wächst, Transaktionen mit Banken außerhalb der iberischen Halbinsel haben durchzuführen.

Die Veranstaltung, die von Gerardo de la Mata, Direktor von ASSET und Leiter des Ausschusses Zahlungsverkehr, geleitet wurde, beinhaltete verschiedene Vorträge, die den anwesenden Unternehmen, Banken und Herstellern den Nutzen von EBICS näherbrachten. Hierfür haben die Redner verschiedene und einander ergänzende Themen aufgegriffen, wie z. B.:
  • Axel Weiß, EBICS-Chairman, sprach zunächst über die Entstehung von EBICS und stellte anschließend dessen wichtigste Eigenschaften und Vorteile vor, bevor er die Arbeitsweise von EBICS SCRL erläuterte.
  • Thomas Stosberg, Deutsche Bank, referierte insbesondere die Gründe für die Einführung von EBICS und gab einen Überblick über die bisherigen Erfahrungen und die zukünftigen Weiterentwicklungen im Rahmen von BTF[1].
  • Mein Vortrag beleuchtete bestimmte Aspekte, z. B. die Sicherheit und die Anwendungsfälle in Frankreich und Deutschland – sowohl beim Zahlungsverkehr zwischen Unternehmen und Banken als auch im Interbankenverkehr. Außerdem habe ich dargelegt, wie EBICS in Frankreich implementiert worden und wie die Migration abgelaufen ist.
Die Fragen der Zuhörer betrafen im Wesentlichen den Punkt, ob man sich für eines der aktuell in Spanien verwendeten Protokolle (Editran, SWIFT) oder EBICS entscheiden solle. Hierfür gibt es vernünftige Entscheidungskriterien.

Es stimmt, dass in Spanien Editran im großen Umfang eingesetzt wird. Jedoch wird es von Banken und Unternehmen außerhalb Spaniens nur selten bzw. überhaupt nicht unterstützt. Deshalb entspricht Editran nicht den Bedürfnissen von Unternehmen und Banken, die grenzüberschreitenden Zahlungsverkehr abwickeln müssen.

Dafür müssen ein oder mehrere Protokolle verwendet werden, die den grenzüberschreitenden Datenaustausch unterstützen. Je nach Kontext ist die parellele Verwendung von EBICS und SWIFT durchaus vorstellbar, wie beispielsweise in Frankreich. EBICS könnte für die Kommunikation mit der wachsenden Anzahl von Banken, die Standorte in mehreren Staaten Europas haben, verwendet werden und SWIFT für die Kommunikation mit den anderen Banken.

Die Kosten für die Nutzung sind ebenfalls ein wichtiges Entscheidungskriterium. Unternehmen könnten (sollten) die Kosten durch den Einsatz des preisgünstigsten Standards optimieren.
Ein Thema, das ebenfalls auf reges Interesse der Teilnehmer stieß, war die verteilte elektronische Unterschrift (VEU) mit EBICS, insbesondere über das Handy, deren Einsatz in Deutschland bereits gang und gäbe ist. Daran ist nichts erstaunlich. Viel erstaunlicher ist hingegen die Tatsache, dass die VEU in Frankreich noch keine breite Anwendung findet.

Eine ähnliche Veranstaltung wird am 24. Februar in Barcelona stattfinden. Dafür haben sich bereits jetzt schon zahlreiche Teilnehmer angemeldet. Dies ist ein weiterer Beleg dafür, dass die Finanzindustrie unbedingt ein standardisiertes, universelles und effizientes Austauschverfahren wie EBICS benötigt (falls es solch eines Beweises überhaupt noch bedarf).

[1] Business Transactions & Formats

Marc Dutech 

International harmonisch mit EBICS BTF

Sabine Wenzel, EBICS Secretary, EBICS SCRL


Im Jahr 2010 haben sich der französische CFONB und die Deutsche Kreditwirtschaft (DK) in der EBICS-Gesellschaft zusammengeschlossen. Eine Vision ist die Harmonisierung von EBICS. Unterschiedliche Vorgängerverfahren in den Ländern haben die EBICS-Spezifikation beeinflusst und erschweren die EBICS-Implementierungen. Deutschland und Frankreich verfolgen abweichende Ansätze zur (Kurz-)Identifizierung von Geschäftsvorfällen und für die zu verwendenden Formate. Neuen Zug hat dieses Thema seit dem Beitritt der Schweiz zur EBICS SCRL. Es wurde ein Harmonisierungsprojekt angeregt mit dem Ziel einer EBICS-weit einheitlichen Vorgehensweise. Diese Konsolidierung heißt EBICS BTF.


Als sicheres Kommunikationsverfahren sorgt EBICS in erster Linie dafür, dass alle Daten korrekt authentifiziert, verschlüsselt und autorisiert übertragen werden.



Banken und Firmenkunden müssen erkennen können, welcher Service mit dem Auftrag tatsächlich zu erbringen ist. Dementsprechend muss der EBICS-Server z. B. überprüfen
  • ob der Kunde grundsätzlich das richtige Datenformat verwendet, ggf. in der passenden Version (Variante) des Standards und/oder entsprechend speziellen Implementierungsrichtlinien
  • ob Anliefervorschriften beachtet werden und Verarbeitungskennzeichen gesetzt sind
    • Kennzeichen, wie viele Elektronische Unterschriften dem Auftrag beigefügt worden sind und ob der Kunde ggf. eine zusätzlich benötigte Unterschrift per VEU leisten kann
    • Kennzeichen, dass der Auftrag in einen Container gepackt worden ist
  • ob für den Service ergänzende Optionen angegeben sind, z. B. für die DK der Verweis auf das SRZ-Verfahren oder für Frankreich der dort gängige Testmodus
Diese Prüfungen erfordern eine kompakte Angabe, um welchen Geschäftsvorfall es geht und ob die Sendung im korrekten Format angeliefert wurde. Dieser „Aufkleber“ am EBICS-Auftrag sieht aktuell in den Ländern noch unterschiedlich aus.

In Deutschland werden dreistellige Buchstabenkürzel verwendet. Frankreich hat lediglich zwei Standard-Auftragsarten definiert (für Upload und Download), ergänzt um einen Dateiformatparameter. Beide Ansätze reichen für eine internationale Nutzung, aktuell also in der Schweiz, nicht aus. Das uneinheitliche Vorgehen steht der Ausbreitung von EBICS im Weg.
Das EBICS Board of Directors (BoD) hat daher der EBICS Working Group (besetzt mit EBICS-Experten aus Deutschland, Frankreich und der Schweiz) den Auftrag erteilt, eine einheitliche und strukturierte Lösung für die Identifizierung von „Business Transactions & Formats“ (BTF) zu erarbeiten. EBICS BTF soll Bestandteil der nächsten EBICS-Version sein.

Aktuell besteht das BTF-Konzept aus drei Blöcken (Elementgruppen):
  • Content – verwendetes Format/Formatstandard (ggf. verwendete Version)
  • Processing – Kennzeichen zur EU und VEU, verwendete Container
  • Service – Information über das Zielsystem (ggf. mit 1..n Optionen)
Der Vorteil dieser gemeinsamen Entwicklung: Alle Beteiligten haben das gleiche Verständnis von der Belegung der XML-Elemente und –Attribute. Somit wird der „Aufkleber“ bei Standard-Geschäftsvorfällen (z. B. für die SEPA-Überweisung) in allen Ländern gleich belegt. Bei länderspezifischen Ausprägungen werden die BTF-Elemente abweichend gesetzt. Damit sind Unterschiede transparent und schnell zu erkennen.

Für diese einheitliche Denkweise waren intensive fachliche Diskussionen erforderlich – auch darüber, welche Informationen zur Identifizierung und korrekten Weitergabe des Auftrags wirklich benötigt werden. Die Angaben sollen vollständig sowie redundanz- und widerspruchsfrei sein. Insbesondere war man sich einig, möglichst mit externen Codelisten zu agieren (entsprechende Codes für die Datenelemente werden dafür gemeinsam abgestimmt und in der EBICS SCRL weitergepflegt).
In der EBICS Working Group wird diese Lösung als sehr stabil angesehen und hat eine hohe Akzeptanz. Letztendlich müssen die EBICS-Communities entscheiden, in welcher Form und mit welchem Zeitplan sie EBICS BTF in den nächsten Jahren anwenden. Für diese Frage sind Anfang 2016 nationale Konsultationen vorgesehen, die von der EBICS Working Group begleitet werden.

Sabine Wenzel

EBICS – Chancen der Internationalisierung

Thomas Stosberg, GTB Product Management, Deutsche Bank AG

Die Schweiz ist als drittes Land neben Deutschland und Frankreich der EBICS-Gesellschaft beigetreten und markiert damit den nächsten Schritt zur Internationalisierung von EBICS. Hat EBICS das Potenzial zu einem internationalen Standard und ist dieser im Interesse von Kunden und Banken?


Die verschiedenen Gremien eines Landes, die sich mit der Abwicklung von (nationalem) Zahlungsverkehr beschäftigen, sind bestrebt, im Interesse von Kunden und Banken eine stabile und standardisierte Zahlungsverkehrslösung anzubieten. Die Adaption eines neuen Standards setzt immer eine starke Motivation voraus – meistens resultierend aus Problemen mit der technischen Sicherheit und/oder den Kosten für den Betrieb der bisherigen Lösung; oder anders formuliert: Länder mit einer praktikablen Lösung für alle lokalen Marktteilnehmer werden sich mit hoher Wahrscheinlichkeit nicht mit der Adaption eines neuen Standards auseinandersetzen. Für alle Länder, die sich aber mit einem neuen Standard beschäftigen, könnte EBICS eine geeignete Option sein.

Die Kunden-Sicht

Die Zielkunden von EBICS – Unternehmen jeder Größe, von Kleinstbetrieben bis zu internationalen Konzernen – suchen eine Zahlungsverkehrslösung, die zwei Grundvoraussetzungen erfüllt: zum einen geringe Kosten und zum anderen eine einfache, sichere, revisionskonforme, automatisierte und standardisierte Anbindung der eigenen Infrastruktur an alle Banken (bezogen auf die Bankkommunikation und die genutzten Zahlungsverkehrsformate). Letztere erlaubt eine gleichartige Integration aller Bankpartner mit der Möglichkeit, den Zahlungsverkehr flexibel auf verschiedene Banken zu verteilen und auf technische Probleme im Rahmen einer Notfallplanung reagieren zu können.

EBICS kann diese Anforderungen aus Kundensicht vollständig erfüllen. Bezogen auf die Implementierung in Deutschland kann sogar die vollständige Prozessautomatisierung durch den Einsatz digitaler Signaturen ohne Nutzung von Zertifikaten und einer „Corporate Seal“-Autorisierung erreicht werden.

Die Weiterentwicklung, im deutschen Markt das CGI-MP-XML-Format für die Abwicklung von weltweitem Zahlungsverkehr anzubieten, hat zusätzlich die Grundlage geschaffen, EBICS als globale Bankkommunikation alternativ zu einer SWIFT- bzw. einer Host-to-Host-Anbindung für Kunden zu etablieren.

Die Bank-Sicht

Banken können zukünftig nicht mehr mit proprietären technischen Lösungen am Markt bestehen. Eine bankindividuelle technische Lösung (Bankkommunikation und Zahlungsverkehrsformat) wird von Kunden weder positiv als Alleinstellungsmerkmal und Verkaufsargument wahrgenommen, noch kann sie aus Bankensicht als betriebswirtschaftlich rentable Lösung eingesetzt und gepflegt werden.
Entsprechend wird der Wettbewerb zwischen Banken ausschließlich auf der Grundlage von angebotenen Bankdienstleistungen und deren Preis stattfinden. Die Erwartungshaltung der Kunden ist, dass die zugrundeliegende technische Lösung für Zahlungsverkehr ähnlich standardisiert ist wie Strom aus der Steckdose.

Die Einführung von EBICS in Frankreich hat gezeigt, dass die Auswirkungen eines gemeinsamen Standards auf die eigene Kundenbasis und die Erträge eher gering sind. Dies hängt damit zusammen, dass die Kundenschnittstellen beider Länder unterschiedlich sind und generell Kunden die Auswahl ihrer Bankbeziehungen nicht von den angebotenen Zugangskanälen abhängig machen.
Bezogen auf die Kundenschnittstelle bietet EBICS für Banken die Möglichkeit, einen solchen standardisierten Service für mehrere Länder anzubieten. Daneben kann EBICS auch als Clearing-Zugang für SEPA-Zahlungen verwendet werden.


EBICS als Chance zur Internationalisierung 
      
EBICS ist aus Kundensicht eine attraktive Bankkommunikation. Für Banken bietet sich mit EBICS die Möglichkeit einen standardisierten Zugang für mehrere Länder auf Grundlage einer Infrastruktur anzubieten. Dies ist auch dann zutreffend, wenn eine Bank primär nur in einem Land tätig ist, da man eigene Kunden mit Niederlassungen im SEPA-Raum ohne größere Investitionen unterstützen könnte. Durch die bereits erfolgte Adaption von EBICS in den beiden größten europäischen Ländern und der Schweiz gibt es schon jetzt eine signifikante Anzahl von EBICS-Nutzern außerhalb der Kernmärkte, die sich stetig erhöht und ebenfalls zur offiziellen Etablierung in anderen Ländern und bei weiteren Banken beitragen wird. Eine weitere Verbreitung von EBICS wäre zum Vorteil aller Marktteilnehmer und ist für Länder mit entsprechendem Handlungsdruck die mit Abstand beste Option für die Neugestaltung der Abwicklung des Zahlungsverkehrs.

Thomas Stosberg

Wie sich EBICS verbessern lässt, Teil 7 – Automatisches Bankschlüssel-Update: Geht das überhaupt?



Gemäß EBICS-Spezifikation werden Daten stets signiert und verschlüsselt übertragen. Dies gilt für beide Kommunikationsrichtungen: Kunde > Bank und Bank > Kunde. In Deutschland sind die dafür verwendeten Schlüssel theoretisch unbegrenzt gültig. In Frankreich ist zumindest die Gültigkeit der Zertifikate limitiert. Aus Sicherheitsgründen ist es unabdingbar, dass die Schlüssel regelmäßig erneuert werden. Für die Kundenseite bringt EBICS bereits Funktionen für einen automatisierten Schlüsselwechsel eines einmal initialisierten EBICS-Teilnehmers mit. Die automatisierte Erneuerung der Bankschlüssel hingegen gestaltet sich in der Praxis schwieriger. Ein „weicher Schlüsselwechsel“ ist eine Lösung.



Weshalb Banken ihre EBICS-Schlüssel ungern wechseln

Das EBICS-Kundensystem kann die öffentlichen Bankschlüssel zur Authentifikation (Identifikation der Bank) und Verschlüsselung der Datei-Einreichungen mit der Auftragsart HPB bei der Bank herunterladen. Falls das Kundensystem ungültige oder nicht mehr aktuelle Bankschlüssel nutzt, erhält es gemäß der EBICS-Spezifikation den negativen Return-Code EBICS_BANK_PUBKEY_UPDATE_REQUIRED.

Dies zieht folgende Probleme nach sich:
  • Sobald der EBICS-Client den Return-Code EBICS_BANK_PUBKEY_UPDATE_REQUIRED erhält, sollte er die aktuellen Bankschlüssel per HPB abholen. Dieser Prozess wird von EBICS-Clients nicht immer hinreichend unterstützt.
  • Nach einer erneuten Abholung der Bankschlüssel müssen Schlüssel, die nicht CA- und zertifikatsbasiert sind, im EBICS-Client manuell per Hashwert-Eingabe freigeschaltet werden.
  • EBICS-Clients sind häufig automatisiert im Einsatz. Die Notwendigkeit, bei der Erneuerung der Bankschlüssel manuell eingreifen zu müssen, z. B. erneute Schlüsselabholung oder Schlüsselfreischaltung, wird meistens nicht oder zu spät erkannt. Störungen sind somit vorprogrammiert.
Aus diesen Gründen schrecken Betreiber von EBICS-Bankrechnern vor einem Wechsel der Bankschlüssel zurück. Die folgenden Maßnahmen können Abhilfe schaffen.

Der Weg zum unbeschwerten Bankschlüssel-Wechsel

Um Bankschlüssel und ‑zertifikate ohne Probleme regelmäßig erneuern zu können, sollte zunächst ein „weicher Schlüsselwechsel“ ermöglicht werden. Das heißt, nicht alle Kunden müssen von einem auf den anderen Tag ihre Bankschlüssel aktualisieren.

Ein solcher weicher Schlüsselwechsel ist möglich, wenn der EBICS-Bankrechner mit alten und neuen Bankschlüssel-Paaren parallel arbeiten kann. EBICS-Clients, die einen Wechsel erkennen und die Aktualisierung (ggf. auch automatisch) durchführen, nutzen den neuen Schlüssel, die anderen Clients weiter den alten. Im letzteren Fall kann die Bank die betreffenden Kunden ansprechen.

Als weitere Maßnahme muss der EBICS-CR EB-14-12 auf Client- und Serverseite umgesetzt werden. Der CR ist für die nächste EBICS-Spezifikation beschlossen und sieht u. a. vor, dass bei der Bankschlüssel-Abholung die neuen Bankschlüssel mit dem alten Bank-Authentifikationsschlüssel signiert sind (siehe www.ebics.org). Lediglich bei der ersten Bankschlüssel-Abholung ist dann noch eine manuelle Freischaltung im EBICS-Client erforderlich. Bei jedem weiteren HPB-Auftrag wird die Signatur geprüft, und die Bankschlüssel werden somit nach erfolgreicher Prüfung im EBICS-Client automatisch freigeschaltet.

Mit diesem Funktionsumfang ist es möglich, die Bankschlüssel vollautomatisiert zu erneuern.

Michael Lembcke 

SIBOS 2015: Zahlungsverkehr in Bewegung



Auf der SIBOS in Singapur spielt traditionell SWIFT die Hauptrolle und EBICS eine Nebenrolle. Dennoch war das Interesse am Einsatz und der zukünftigen Entwicklung von EBICS groß. Mehr als 8.000 Besucher kamen zur Ausstellung ins Sands Expo and Convention Centre. Damit war die SIBOS in Singapur die größte in Asien und die zweitgrößte insgesamt. Die beherrschenden Themen zeigen: Es kommen weitere große Veränderungen auf den Zahlungsverkehr zu.


EBICS BTF



Mit dem Beitritt der Schweiz zur EBICS-Gesellschaft hat die Verbreitung von EBICS weiter Fahrt aufgenommen. Bisher sind zwei EBICS-Dialekte gebräuchlich: in Deutschland und in Frankreich. Die Schweizer werden einen weiteren Dialekt hinzufügen. Damit EBICS sich für weitere Länder öffnet, steht eine Vereinheitlichung an: EBICS BTF.

Hinter EBICS BTF steht der Wille aller drei Länder, einen einheitlichen EBICS-Standard zu entwickeln. Die Arbeiten dazu laufen auf Hochtouren. Mehr Informationen zu EBICS BTF lesen Sie bald in diesem Blog.

Digitalisierung



Der Zahlungsverkehr ist in einigen Ländern hochautomatisiert. Die Prozesse im Zahlungsverkehr sind fast vollständig digitalisiert, beziehen ein oder mehrere Partner ein und reichen weit über die eigenen Systemgrenzen hinaus. Typische Beispiele sind SWIFT oder EBICS, mit denen man strukturiert Informationen zwischen Partnern austauschen kann.

Andere Bereiche im Bankwesen können von der Erfahrung des Zahlungsverkehrs profitieren. Der hohe Grad der Digitalisierung lässt sich beispielsweise auf Kredite, Avale oder dokumentäres Geschäft übertragen. Dies scheint der Trend für die nächsten Jahre zu sein.

Backup der Zahlungsverkehrsströme



Die Geldmengen im Zahlungsverkehr sind astronomisch. TARGET 2 setzt fast eine Billarde Euro pro Jahr um – eine Eins mit fünfzehn Nullen! Es ist klar, diese Räder dürfen im Zahlungsverkehr nicht still stehen.

Daher wird der Ruf nach einem Backup für den Transport der Zahlungsströme immer lauter. EBICS bietet sich quasi als natürlicher Partner von SWIFT an. Es kursieren die ersten Gerüchte, dass Empfehlungen – noch werden es nur Empfehlungen sein – ausgesprochen werden, den digitalen Geldtransport durch ein zweites Verfahren abzusichern.

Regulatorische Veränderungen



In der Vergangenheit haben die regulatorischen Anforderungen den Zahlungsverkehr dominiert. Die besten Beispiele sind SEPA und ISO 20022. Nach unserer Einschätzung werden in den nächsten zwei Jahren ca. 30 neue Trends und Vorhaben im Zahlungsverkehr kommen – die meisten davon durch den Regulator getrieben. Die Auswirkungen auf die IT reichen von den Einlieferungssystemen über das Clearing bis zum Kernbanksystem. Insgesamt sind alle Systeme im Zahlungsverkehr betroffen. Es wird also nicht langweilig.

Michael Lembcke 

Migration Zahlungsverkehr Schweiz: echte End-to-End-Tests mit EBICS

Auf dem Finanzplatz Schweiz arbeiten die Banken mit Hochdruck an den Umsetzungsprojekten für die Harmonisierung des Schweizer Zahlungsverkehrs nach ISO 20022. Softwarehersteller und Firmenkunden fordern Testmöglichkeiten für die neuen Zahlungsformate. Gesucht ist ein End-to-End-Testszenario, das die produktive Verarbeitung seitens der Bank bestmöglich abbildet. In der Schweiz können die wenigsten Banken solche Tests anbieten. Dabei kann EBICS helfen.


Die SIX Interbank Clearing, verantwortlich für die Publikation der Schweizer Implementierung, bietet eine sogenannte Validierungsplattform an. Dort können die jeweiligen Meldungen (pain und camt) bezüglich Syntax und einfachen Business-Regeln validiert werden. In der Regel ist dies die erste Anlaufstelle für Tests in der neuen ISO-Welt. Für Hersteller und Kunden reicht diese Prüfung jedoch nicht aus, um anschliessend die produktiven Zahlungsläufe mit ihrer Bank umzustellen.

Taugliche End-to-End-Tests umfassen die Aufträge als Buchungen in die elektronischen Kontoauszüge (z. B. MT940 oder camt.053) und Avisierungen (z. B. MT942 oder camt.052) inklusive Saldo-Nachführung sowie ein Fehlerverhalten, welches der Produktion entspricht (Ausweisung entsprechender Status-Rapporte und Storno-Buchungen). „Die Schwierigkeit von Tests ist oft die Avisierung, welche aufgrund der eingelieferten Daten sich entsprechend verhält“, weiß Christoph Schenker von der PostFinance. „Die Testplattplattform http://isotest.postfinance.ch bietet alle Möglichkeiten, welche der Softwarehersteller für Ein- und Auslieferungen benötigt, um seine Software für den Kunden ‚ISO-ready‘ zu machen.“

Gerade den Fehlerfall möchte der Kunde vor der Einführung simulieren, um seine internen Prozesse der Ausnahmebehandlung zu testen. Typischerweise sind dies Fehler wie „ungenügende Deckung“, „falsches Begünstigtenkonto“ und ähnliche Ausnahmefälle, welche in der Folge im produktiven Betrieb auftreten können.

Fasst man End-to-End etwas weiter, wäre es für den Firmenkunden ideal, wenn er direkt aus seiner ERP-Software mittels EBICS einen Zahlungslauf an eine Testinfrastruktur senden und wiederum mittels EBICS die dazugehörigen Downloads ausführen kann. Nur dann ist ein echter „proof of the pudding“ möglich. Simuliert werden müssen insbesondere die Rückmeldungen bei Fehlern und die Verarbeitung realer Dateigrössen – d. h. ein produktiver Kreditorenlauf mit einigen hundert Zahlungen oder mehr, nicht nur eine Testzahlung. So ist die nötige Sicherheit für einen Produktionsstart gegeben. Die direkte Anbindung einer Testplattform über EBICS ermöglicht es, Testzyklen zu automatisieren und via EBICS-Protokoll grosse Dateien zu übermitteln. Dies ist mit einer Testplattform, welche nur über eine manuelle Web-Upload-Schnittstelle verfügt, nur schwer möglich.

Innovative Schweizer Banken sehen in der Kombination von ISO 20022 und EBICS das ideale Tandem, um ihre Kunden in der Harmonisierung des Zahlungsverkehrs zu unterstützen. Institute, welche zusätzlich eine echte End-to-End-Testmöglichkeit anbieten können, bieten ihren Kunden einen echten Mehrwert. „SAP unterstützt den Credit Transfer mit ISO 20022 schon seit mehreren Jahren. Gute Testplattformen und direkte Ansprechpartner bei Finanzinstituten unterstützen die weitere Umsetzung von ISO20022-Meldungen in der Schweiz“, sagt Rainer Hofmeister vom Hersteller SAP.

Carsten Miehling

Wie sich EBICS verbessern lässt, Teil 6 – eindeutige Identifikation der handelnden Person

Kann es vorkommen, dass ein Zahlungsverkehrsauftrag, der in EBICS eigentlich von zwei unterschiedlichen Personen autorisiert werden muss, doch nur von einer Person freigegeben wird? Ja, unter bestimmten Umständen ist das möglich. Bei manchen Vertragskonstellationen zwischen dem Kreditinstitut und dem Firmenkunden lässt sich die handelnde Person nicht eindeutig identifizieren. 


Die Falle steckt im EBICS-Datenmodell

Das Berechtigungsmodell des Firmenkunden für die EBICS-Kommunikation orientiert sich am Datenmodell von EBICS. Dieses unterscheidet zwischen dem Kunden und seinem Mitarbeiter als EBICS-Teilnehmer.

Firmenkunden kommunizieren per EBICS mit ihrer Bank über eine unternehmensweit gültige EBICS-Kunden-ID und die Teilnehmer-ID des handelnden Mitarbeiters. Die IDs vergibt die Bank bei der Einrichtung für den Kunden und seinen Mitarbeiter; der Kunde benötigt sie für die Verbindung zum Bankrechner in den Zugängen der EBICS-Clients. Nun ist eben diese Teilnehmer-ID nicht immer eindeutig. Wie kann das sein?

Firmenkunden nutzen verschiedene EBICS-Clients

Größere Firmenkunden setzen auch mal mehrere EBICS-Clients unterschiedlicher Hersteller ein. Dabei nutzt ein Mitarbeiter je nach Funktionsumfang auch verschiedene Clients parallel. Ein Beispiel ist der Mitarbeiter, der mit einem EBICS-PC-Produkt Zahlungen autorisiert und einreicht – und der gleichzeitig Zahlungen, die aus seiner ERP-Lösung für die in Deutschland übliche Verteilte Elektronische Unterschrift direkt zur Bank gesendet worden sind, per EBICS-Mobile-Lösung autorisiert.

Schlüssel und Zertifikate sind häufig nicht wiederverwendbar

Da die teilnehmerbezogenen Schlüssel bzw. Zertifikate je nach Kundensystem und EBICS-Land unterschiedlich abgelegt sind, kann ein Mitarbeiter sie in den meisten Fällen nicht für alle EBICS-Clients übergreifend nutzen. Sprich, das EBICS-PC-Produkt und die EBICS-Mobile-Lösung erfordern jeweils eigene Schlüssel für den Teilnehmer. Daher hat der Mitarbeiter für seinen EBICS-Zugang zur Bank in jedem Client eine andere Teilnehmer-ID, die dann die Verbindung zu seinen jeweiligen Schlüsseln bzw. Zertifikaten sicherstellt.

Da das Datenmodell von EBICS aber den EBICS-Teilnehmer als eindeutige handelnde Person definiert, kann theoretisch eine Person mit mehreren Teilnehmer-IDs Zahlungen freigeben, die eigentlich von mehreren Personen autorisiert werden müssen. Im EBICS-Datenmodell ist die Zuordnung einer Person zu mehreren Teilnehmer-IDs nicht vorgesehen.

Um einen derartigen Missbrauch zu verhindern verfügen EBICS-Bankrechner mittlerweile über zusätzliche individuelle Berechtigungsfunktionen, dennoch ist eine einheitliche Lösung im EBICS-Standard selbst wünschenswert.

Einheitliches Austauschformat für Schlüssel und Zertifikate

Eine Möglichkeit wäre es z. B., im EBICS-Standard das Austauschformat bzw. die Ablage der Schlüssel und Zertifikate einheitlich vorzuschreiben, z. B. einen Software-Token mit der Ablage im PKCS12-Format. In diesem Fall ist die Teilnehmer-ID eindeutig nutzbar, um die handelnde Person zu identifizieren. Schlüssel und Zertifikate können somit in Verbindung mit der Teilnehmer-ID auf mehreren Clients genutzt werden.

Michael Lembcke 

Wie steht es mit EBICS in Marokko?

Der Vormarsch von EBICS in Europa ist inzwischen unumstritten. Wie entwickelt sich der Standard jedoch jenseits der Grenzen der Europäischen Union? Ein Kontinent, der sich in meinen Augen besonders für die Verwendung eines modernen, leistungsfähigen und universellen Protokolls für den elektronischen Zahlungsverkehr wie EBICS eignet, ist Afrika. Genauer gesagt denke ich hier zuallererst an Marokko. Warum?


Seit langem schon orientieren sich die marokkanischen Banken und Finanzinstitute an europäischen Praktiken im Bankwesen, insbesondere an denen französischer Banken. So folgten in den neunziger Jahren die marokkanischen Banken den französischen, indem sie sich im elektronischen Zahlungsverkehr zwischen Unternehmen und Banken für das ETEBAC-Protokoll entschieden. Auf diese Weise wurden die marokkanischen Unternehmen in die Lage versetzt, effiziente Cash Management-Lösungen einzusetzen.

Ebenso orientierte man sich bei dem vom marokkanischen Bankensektor verwendeten Austauschformat für Kontoauszüge, Überweisungen und Lastschriftverfahren stark an den CFONB-Formaten.

Momentan wird in Marokko noch immer das ETEBAC-Protokoll verwendet. Allerdings läuft es unter X.28 über private PADs und die Unternehmen müssen asynchrone Analog-Modems verwenden, die kaum noch zu finden sind. Somit wird es nahezu unmöglich, die Anzahl der Unternehmen zu steigern, die den ETEBAC-Kanal verwenden. Mögliche Ersatzlösungen sind:
  • das Internet-Banking, das jedoch für Unternehmen mit Konten bei mehreren Banken bzw. Unternehmen mit erheblichem Transaktionsvolumen ungeeignet ist,
  • SWIFT, was zu wiederkehrenden Zusatzkosten führt, die nicht unerheblich sind,
  • weniger gebräuchliche Protokolle wie PeSIT, die künftigen Anforderungen nicht gerecht werden.
Der durch marokkanisches Gesetz vorgegebene Rechtsrahmen für den Austausch und Schutz digitaler Daten fördert die Verwendung sicherer Datenaustauschprotokolle mit elektronischer(n) Unterschrift(en). Dadurch werden die Banktransaktionen mit den für sie geforderten Sicherheitsfunktionen wie Authentifizierung, Unveränderlichkeit und Integrität, Geheimhaltung, keine Wiederverwendbarkeit der Unterschrift sowie Nichtabstreitbarkeit ausgestattet. Diese Funktionen werden standardmäßig vom EBICS-Protokoll abgedeckt.

Die marokkanischen Banken, die in Afrika eine Vorreiterrolle einnehmen und in 22 Ländern des Kontinents vertreten sind, benötigen zuverlässige und bewährte Systeme zur Finanzdatenübermittlung zwischen den Banken und über Grenzen hinweg, um unter anderem dafür zu sorgen, dass Marokko zum Drehkreuz von Banktransfers wird und ein Maximum an Transaktionen an sich zieht, die auf sichere und moderne Art und Weise durchgeführt werden. Hierfür bietet sich EBICS als das Mittel der Wahl an.

Übrigens erlaubt EBICS nicht nur, das bestehende Angebot von Diensten für Unternehmen auszubauen, es stellt für die marokkanischen Banken auch eine echte Innovationsmöglichkeit dar, um ganz neue Dienste (z. B. e-Invoicing) anzubieten.

Und vergessen wir nicht zwei weitere Bereiche, in denen EBICS seine Wirkung voll entfalten könnte:
  1. In Europa wird EBICS für den intereuropäischen elektronischen Zahlungsverkehr zwischen den Banken bereits sehr erfolgreich angewandt. Die marokkanischen Finanzinstitutionen könnten nachziehen und hätten somit die Möglichkeit, die Widerstandsfähigkeit und die hohe Verfügbarkeit im bankenübergreifenden Zahlungsverkehr zu verbessern und nebenbei dessen Kosten zu optimieren.
  2. EBICS kann bei Datentransfers für staatliche Digitalisierungsprojekte eingesetzt werden, insbesondere im Zusammenhang mit Sozialdaten, medizinischen und dienststellenübergreifenden Daten.
Ausgehend von obigen Ausführungen erscheint mir das EBICS-Protokoll, das sich – wie der Leser des Blogs mittlerweile hat feststellen können – dank seiner Universalität, seiner einfachen Anwendung, seinem hohen Sicherheitsniveau und der Tatsache, dass mit seiner Verwendung keine wiederkehrenden Kosten verbunden sind, in Europa schnell ausbreitet, eine ideale Alternative für den Business-to-Bank- und Bank-to-Bank-Zahlungsverkehr. Würden zudem die marokkanischen Banken die Anwendung des ISO-20022-Standards in Betracht ziehen, wäre dies ein großer Schritt in Richtung Harmonisierung und Standardisierung des elektronischen Finanzdatenaustauschs, was zu einer Vereinfachung und Optimierung der Transaktionen mit Europa führen würde. Dieser Punkt erscheint mir auch deshalb so wichtig, weil die marokkanische Wirtschaft durch zahlreiche Standortverlagerungen europäischer Unternehmen von der geographischen Nähe Marokkos zum europäischen Kontinent profitiert hat.

Stellt sich schließlich die Frage der Migration nach EBICS. Ist die Migration ein solch komplexes Unterfangen, dass sie sich als ein echtes Hindernis für die Verwendung dieses Protokolls erweisen könnte? Bedenkt man, wie die Migration in Frankreich vonstattenging, ist das meiner Meinung nach nicht der Fall. Die in diesem Zusammenhang nicht nur von den Herstellern für Banken- und Unternehmenssoftware, sondern auch von den in Marokko ansässigen französischen Banken gesammelten Erfahrungen würden eine sanfte Migration ohne große Anfangsschwierigkeiten sicherstellen.

Marc Dutech 

Luzerner Kantonalbank AG bietet Firmenkunden erweiterte Lösungen rund um EBICS und ISO 20022

Raphael Häfliger, Cash Management Services, Luzerner Kantonalbank AG

Die Luzerner Kantonalbank AG (LUKB) bietet in der Schweiz seit 2014 den Kommunikationsstandard EBICS an und hat damit ein umfassendes Angebot für den professionellen Zahlungsverkehr im Markt platziert. Nach der erfolgreichen EBICS-Einführung steht nun der nächste Schritt an: Als erstes Finanzinstitut auf dem Finanzplatz Schweiz wird die LUKB ab Herbst 2015 mit der Pilotphase für die Lancierung der "Verteilten Elektronischen Unterschrift" (VEU) starten. 


Das Konstrukt der VEU entspricht einem immer grösser werdenden Bedürfnis von Schweizer Firmenkunden. Kunden können Zahlungsaufträge mit der VEU an die LUKB übermitteln und je nach Vollmachtskonstrukt von den dafür zuständigen Personen im Unternehmen final freigegeben lassen. Dieser zusätzliche Prozessschritt unterscheidet sich von der in der Schweiz üblichen EBICS-Ausgestaltung, bei welcher die Schnittstelle mit einer Einzelunterschrift fungiert und die Berechtigungen innerhalb des firmeneigenen ERPs geregelt werden. In Deutschland gehört die VEU bereits zum Standard, in der Schweiz hingegen ist dies bislang ein Novum.

Mit dem Angebot der VEU sieht die LUKB eine Chance, sich als Finanzinstitut flexibel und kundenorientiert zu positionieren. Zur Realisierung einer EBICS-VEU führt die LUKB mit den Kunden den Dialog, um das passende Unterschriftenmodell zu evaluieren. Geplant sind unter anderem folgende Spezifika:
  • kollektiv zu zweit
  • kollektiv zu dritt
  • Gruppen mit A- und B-Unterschriften
  • weitere individuelle Rollen für Debitoren- und/oder Kreditorenbuchhaltung
  • flexible Zuordnung/Ausschluss von einzelnen Auftragsarten
Es gibt jedoch weitere Gründe sich mit der VEU zu beschäftigen. Aufgrund von operationellen Risiken kann es sinnvoll sein, die für die Auftragserteilung zuständigen Personen im EBICS zu identifizieren. Über die weit verbreiteten Corporate Seals, bei welchen nur die Firma selber authentifiziert wird, ist dies nicht möglich. Zudem könnte künftig auch der Druck seitens des Regulators oder auch der Revisionsgesellschaften in dieser Angelegenheit zunehmen.
In der Startphase ist damit zu rechnen, dass insbesondere die Kunden mit europäischen Softwarelösungen das Angebot nutzen. Weiter geht die LUKB davon aus, dass die lokalen Softwarehersteller mittelfristig ebenfalls VEU-Lösungen in ihre Clients integrieren werden.
In der Firmenkunden-Kommunikation geht die LUKB noch einen Schritt weiter und wird ab Dezember 2015 das Format ISO 20022 über EBICS transportieren. Konkret werden die Meldungen pain.001, pain.002, camt.052 und camt.053 implementiert. Camt.054 folgt voraussichtlich im Frühjahr 2016 und vervollständigt damit das ISO-Angebot. Mit diesem Vorhaben wird die LUKB zu den ersten Anbietern einer produktiven Lösung im Projekt "Harmonisierung Zahlungsverkehr Schweiz" gehören. Neben den Schweizer Empfehlungen wird die LUKB auch die ISO- und DK-Schemas (Deutschland) für die Auftragserteilung in ISO 20022 unterstützen. Weitere Schemen wie das französische oder österreichische Format werden je nach Kundenanforderungen individuell geprüft.

Mit den weitreichenden Angeboten rund um die EBICS-VEU und ISO 20022 ist die LUKB im Schweizer Firmenkundenmarkt bestens auf die kommenden Herausforderungen vorbereitet.

www.lukb.ch/harmonisierung-zv
www.lukb.ch/direkt-ebics

Raphael Häfliger

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 5 – Kunden verwalten Konten und Teilnehmer selbst

EBICS bringt von Haus aus nützliche Auftragsarten für die Abfrage von Kunden- und Teilnehmerinformationen mit (welche notabene nicht alle Hersteller konsequent in ihren Produkten anbieten). Gemeint sind hier z. B. die Auftragsarten HKD (Kundendaten abrufen) und HTD (Teilnehmerdaten abrufen). Nach den Wünschen der Schweizer Grossbanken sollte es möglich sein, diese Stammdaten nicht nur abzufragen, sondern selbst zu verwalten und auch zu verändern.



Eine Besonderheit der Schweizer Implementierung ist aktuell die Beschränkung auf die Unterschriftsarten „T“ und „E“. Im ersten Fall erfolgt die notwendige zusätzliche Freigabe über einen separaten Kanal (z. B. Onlinebanking). Im zweiten Fall wird der Auftrag augenblicklich verarbeitet, da der Auftraggeber selbst für die notwendigen Sicherheitsvorkehrungen zu sorgen hat. In der Regel ist die Person, die signiert hat, im Fall „E“ nicht bekannt, sondern lediglich der Kunde respektive die auftraggebende Firma.

Als wichtigster Grund, die VEU in der Schweiz nicht anzuwenden, wird der zu hohe Aufwand für die Administration der VEU-Rechte auf Teilnehmern und Konten angeführt. Da die Kundenstammdaten der Bank oft nicht direkt mit dem EBICS-Produkt verknüpft sind, fallen Doppelerfassungen an, welche bei einer gewissen Anzahl von Kunden und Veränderungen der Berechtigungen ins Gewicht fallen. Gesucht ist ein Mechanismus im Sinne eines Electronic Bank Account Management (eBAM).
Im Standard ISO 20022 sind für diese Zwecke bereits fünfzehn Meldungen modelliert (siehe Meldungskategorie acmt). Die ISO-Meldungen können als Basis dienen, das EBICS-Protokoll so zu erweitern, dass der Kunde die Konten und Teilnehmer zumindest teilweise selbst verwalten kann. Die mehrfache Bestätigung mittels Signaturen auf Kundenseite und ein Vier-Augen-Prinzip auf Bankseite könnten je nach Sicherheitsanforderung entsprechend kombiniert werden. Der Kunde müsste beispielsweise eine heikle Transaktion doppelt prüfen, und die Bank müsste die Transaktion als letzten Schritt manuell freigeben (jedoch nicht mehr selbst komplett erfassen).

Mit einer institutsspezifischen Auftragsart (XYZ) für die Übermittlung von XML-Konto- und Teilnehmerdaten wäre dies bereits heute möglich. Bankseitig würden die Berechtigungen entsprechend geprüft und mittels Schnittstelle zum EBICS-Produkt (z. B. Webservices) automatisiert angewendet. Aus Schweizer Sicht herrscht diesbezüglich aktuell eher etwas Zurückhaltung, hat man doch bereits zahlreiche Schweizer Auftragsarten auf diese Art und Weise eingeführt, die man in naher Zukunft durch ein generelles Konzept auf Basis der französischen Anwendung von FUL/FDL ablösen möchte. Wir würden es begrüssen, wenn diese Anforderung in eine zukünftige Auftragsbeschreibung in EBICS einfliessen könnte. Von mehr Automation würden sowohl der Kunde wie auch die Bank profitieren.

Carsten Miehling 

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 4 – jeder Person die eigenen Kontoauszüge

Ein großer Teil der Daten, die ich als Firmenkunde mit EBICS von einem Bankrechner abhole, hat einen Kontobezug. Wie kann ich aber für diese Daten bereits bei der Abholung steuern, welcher meiner Mitarbeiter welche Kontoauszüge bekommen darf? Dabei kann eine bankrechnerseitige Steuerung helfen.


EBICS regelt die Einreichung und die Abholung von beliebigen Daten per Auftragsarten bzw. Formatparameter. Das mit der Auftragsart verbundene Datenformat entscheidet dabei letztendlich über die Verarbeitungsmöglichkeiten im EBICS-Bankrechner. Die Inhalte der Datenbereitstellung und Abholung selbst sind jedoch nicht durch EBICS geregelt; sie können daher von EBICS-Bankrechner zu EBICS-Bankrechner und von Kreditinstitut zu Kreditinstitut abweichen.

Welcher EBICS-Teilnehmer bekommt welche Kontoinformationen?

Die Daten, die Mitarbeiter als EBICS-Teilnehmer abholen, werden üblicherweise pro Kunde auf dem Bankrechner zum Download bereitgestellt. Jeder EBICS-Teilnehmer des Kunden, der über die passende Auftragsart verfügt, erhält alle Daten, die für den Kunden bereitstehen. Das gilt ebenso für kontobezogene Daten wie Kontoauszüge und Vormerkposten. Bei der EBICS-Abholung wird die Kontoberechtigung des EBICS-Teilnehmers nicht geprüft, bei der Einlieferung von Zahlungsverkehrsaufträgen in der Kunde-Bank-Beziehung dagegen sehr wohl. EBICS selbst sieht zudem keine Kontoangaben in der EBICS-Nachricht vor. Kontobezogene Prüfungen und Verarbeitungen hängen von der Implementierung des Bankrechners ab – und im Wesentlichen auch davon, ob die Kontoangaben der bereitzustellenden Daten vollständig sind und die Konten gefunden werden.

Kontoberechtigung für Abholungen

In bestimmten Fällen sollte ein EBICS-Teilnehmer lediglich Informationen zu bestimmten Konten bekommen. Eine naheliegende Lösung wäre es, die Daten statt pro Kunde pro Teilnehmer bereitzustellen. Da die Daten allerdings auf den Firmenkunden bezogen sind, führt dies bei mehreren Teilnehmern pro Kunde zu redundanten Daten und somit einem erhöhten Datenvolumen. Vorzuziehen ist daher, die Daten wie üblich je Kunde abzulegen und die Abholung über die Kontoberechtigung am Teilnehmer zu steuern (sofern es sich um kontenbezogene Daten handelt). So bekommt der Teilnehmer stets genau die Daten aller Konten, für die er berechtigt ist.
Sinnvoll wäre zusätzlich eine EBICS-Erweiterung, die es erlaubt, im EBICS-Request ein oder gar mehreren Konten anzugeben – ähnlich der Angabe eines Zeitraums beim historischen Abruf. Mit dieser EBICS-Funktion könnte ein EBICS-Teilnehmer optional auch Daten von bestimmten Konten abrufen. Für den Teilnehmer ist es nicht immer wichtig, dass die Kontoinformationen aller Konten aktuell sind. Eine entsprechende EBICS-Erweiterung ermöglicht eine gezieltere Abholung und bietet dem Kunden letztendlich mehr Flexibilität im Kontenabruf.

Michael Lembcke 

EBICS – auf dem Weg zum europäischen Marktstandard

Axel Weiß, Chairman of Board of Directors EBICS

Für Firmenkunden ist es in Deutschland schon seit 1995 möglich, Zahlungsverkehr mit einem Standardprodukt und einer Elektronischen Signatur mit jedem Kreditinstitut sicher abzuwickeln.

Bereits im Jahre 2003 wurde die Erweiterung des DFÜ-Abkommens um eine internetbasierte Variante initiiert. Diese Variante des DFÜ-Verfahrens wurde als EBICS "Electronic Banking Internet Communication Standard" bezeichnet. Mit dieser Erweiterung erfüllte die deutsche Kreditwirtschaft die Forderung von Kunden und Instituten nach internetbasierten Lösungen im Electronic Banking.


Ziel dieser Erweiterung war es, den einheitlichen und multibankfähigen Bankenstandard "DFÜ mit Kunden" für Übertragungsmöglichkeiten im Internet auszubauen und die damit verbundenen Anwendungsmöglichkeiten zu erweitern. Hierfür werden den aktuellen Sicherheitsanforderungen entsprechende Sicherungsmechanismen wie HTTPS mit einer zusätzlichen starken Authentifizierung für die Kommunikationssicherheit eingesetzt.

EBICS zeichnet sich durch folgende Eigenschaften aus:
  • ein Standard für alle Kreditinstitute und Kunden, d. h. Firmenkunden erreichen mit einer Software jedes Kreditinstitut, das EBICS anbietet
  • offener Standard, d. h. Firmenkunden können Standardprodukte oder  individuelle Software einsetzen
  • moderne Technologie, lizenzfreie internationale Standards wie XML, HTTPS, TLS, ZIP
  • höchste Sicherheitsstandards, z. B. Verschlüsselung auf Transportebene und Ende-zu-Ende
  • ein Transportmittel für alle Geschäftsprozesse wie Lastschriften, Überweisungen, Kontoauszüge, Cash-Management, Wertpapierorder und vieles mehr
  • Einbeziehung von Dienstleistern durch mehrstufiges Unterschriftskonzept
  • standortunabhängige Freigabe von Aufträgen
  • Preis und Leistung bestimmen den Wettbewerb, nicht die Technik und die mit einem Wechsel der Bankverbindung verbundenen Umstellungsaufwände
Neben der Kunde-Bank-Kommunikation wird EBICS in Deutschland und zunehmend auch in anderen Ländern der EU für den sicheren und sehr kostengünstigen Austausch von Zahlungstransaktionen zwischen den Banken eingesetzt. Nicht zuletzt die Bereitstellung eines Auflieferungskanals für EBICS-Transaktionen bei der EBA Clearing führte zu einer signifikanten Steigerung der über EBICS im Interbankenbereich ausgetauschten Transaktionen, sodass mittlerweile rund fünf Prozent aller von der EBA Clearing verarbeiteten SEPA-Transaktionen über die EBICS-Kommunikation abgewickelt werden. Neben dem Einsatz im bilateralen Clearing von Zahlungen wird EBICS zunehmend auch als Backup-Lösung neben den bereits bestehenden Kommunikationskanälen, wie z. B. SWIFT sie anbietet, genutzt.

Die im Jahr 2003 gewählte englische Bezeichnung „EBICS“ unterstrich bereits damals den Anspruch, mit diesem Kommunikationsstandard nicht nur auf nationaler Ebene, sondern vielmehr auch auf europäischer Ebene eine sowohl für Banken als auch für deren Kunden interessante Alternative zu bestehenden Verfahren anzubieten.

In Deutschland bestand bereits seit 1. Januar 2008 die bankseitige Verpflichtung zur Unterstützung von EBICS. Der alte Standard FTAM wurde hier mittlerweile vollständig durch EBICS ersetzt.
Im Jahr 2008 wurde ein Kooperationsabkommen zwischen Deutschland und Frankreich hinsichtlich EBICS geschlossen. Die französische Kreditwirtschaft hatte im Vorfeld nach einer umfangreichen make-or-buy-Analyse erkannt, dass EBICS die Anforderung der französischen Banken und deren Kunden am umfassendsten abdeckt und somit das größte Potenzial für eine Ablösung des bis dahin verwendeten ETEBAC-Kommunikationsstandards besaß. Schnell kristallisierte sich für die beteiligten Banken und Verbände heraus, dass eine rechtssichere Verwendung von EBICS durch alle Nutzer am besten durch Gründung einer gemeinsamen EBICS-Gesellschaft sichergestellt werden kann. Der Zweck der EBICS-Gesellschaft liegt dabei vor allem in der Weiterentwicklung und Pflege des EBICS-Standards und dem Halten der Markenrechte.

Nach intensiven Verhandlungen zwischen der deutschen und der französischen Kreditwirtschaft konnte im Juni 2010 die EBICS-Gesellschaft gegründet werden. Bei der Gestaltung der nach belgischem Recht gegründeten EBICS SCRL wurde streng darauf geachtet, dass die Gesellschaft nicht profitorientiert ist und sehr schlank, d.h. zu minimalen laufenden Kosten, aufgesetzt wird. Zudem wurde dafür gesorgt, dass die Gesellschaft offen für den Zugang anderer an EBICS interessierter Kreditwirtschaften ist.

Mit der Gründung der Gesellschaft wurde somit die Basis für den europaweiten Einsatz und damit der Weiterentwicklung des EBICS-Verfahrens hin zu einem europäischen Marktstandard geschaffen. Im April dieses Jahres erfolgte mit der Beitrittserklärung der SIX Interbank Clearing als Vertreter der Schweizer Kreditwirtschaft ein weiterer wichtiger Schritt in Richtung Europäisierung von EBICS.
Erklärtes Ziel ist es nunmehr, auch Kreditwirtschaften in anderen EU-Ländern von den Vorteilen einer Nutzung und vor allem Mitgestaltung von EBICS zu überzeugen – die Türen für eine Beteiligung an der EBICS-Gesellschaft stehen weit offen.

Axel Weiß