Wie sich EBICS verbessern lässt, Teil 9 – EBICS ist für den Dateitransfer beliebig großer Dateien geeignet. – Ja, aber …

Auch mit SEPA ändert sich das Datenverhalten im Zahlungsverkehr weiterhin. Neue Prozesse führen dazu, dass Dateien im Austausch zwischen Kunden und Banken sowie im bilateralen Austausch immer größer werden. Insbesondere in der Kunde-Bank-Beziehung spielt die Downloadfunktion für Datenabholungen (z. B. Kontoauszüge) über EBICS eine wichtige Rolle. Und zumindest hier scheint es noch Optimierungsbedarf zu geben. Bei besonders großen Dateien wird es mit dem erfolgreichen Download aus verschiedenen Gründen schwierig.


Um das Problem genauer zu beschreiben, muss man zunächst etwas tiefer in das EBICS-Protokoll einsteigen. Datenabholungen (Downloads) über EBICS erfolgen segmentweise immer für alle zur Clientanfrage passenden Daten. Ein EBICS-Client legt beim Empfang einer Anfrage alle Daten für eine Abholung immer in genau einer physischen Datei ab.

Im Downloadprozess von EBICS ermittelt der EBICS-Server nach Empfang eines Abholauftrages zunächst die Anzahl der Segmente, in denen die zu übertragende Datei an den Client übergeben wird. Diese Angabe wird mit dem ersten Segment an den Client zurückgegeben. Sie ist in EBICS verpflichtend. Anschließend ruft der Client jedes Folgesegment sequentiell nacheinander ab und legt die Datei bei sich an.

Bereits der Vorgang zum Zusammenstellen des ersten Segments mit der Gesamtanzahl auf dem EBICS-Server kann je nach Dateigröße und Auslieferungsart (z. B. ZIP-Archiv) längere Zeit beanspruchen. Es muss erst die vollständige Datei komprimiert und verschlüsselt erzeugt werden, damit in der ersten EBICS-Response die korrekte Anzahl an Segmenten an den EBICS-Client mitgeliefert werden kann. Bis der Client in der Initialisierungsphase eine Rückmeldung über die Segmentanzahl bekommt, kann es somit bei großen Datenmengen in der EBICS-Verbindung zu Timeout-Situationen und damit zu Abbrüchen kommen.

Hier liegt das Problem. Daher muss es zukünftig möglich sein, die EBICS-Response auf die EBICS-Initialisierungsanfrage zu beschleunigen.

Die Anzahl der Segmente, die mit dem ersten Segment an den Client zurückgegeben wird, muss heute für den Start der Übertragung nach Möglichkeit korrekt sein. Laut EBICS-Spezifikation 2.5 (siehe Abschnitt 7.2 Umsetzung in den EBICS-Nachrichten, Seite 159) sollte sich der EBICS-Client bei falscher Angabe der Segmentanzahl jedoch tolerant verhalten. In einem solchen Fall müsste der EBICS-Client die laufende Transaktion ordnungsgemäß mit der Quittungsphase fortsetzen, auch wenn der EBICS-Server weniger Segmente liefert, als er in der initialen EBICS-Response angegeben hat. Damit der EBICS-Server bei großen Dateien schneller zu einer Rückmeldung an den Client kommt und ein Timeout vermieden wird, sollte es möglich sein, eine geschätzte Segmentanzahl zu ermitteln und zurückzugeben.

Grundsätzlich wäre eine Erweiterung der EBICS-Spezifikation mit folgenden zwei Teillösungen wünschenswert.

Der EBICS-Client initiiert einen Download mit unbestimmter Größe zur Vermeidung von Timeouts bei großen Datenmengen

Der Bankrechner liefert in seiner Response zusammen mit dem ersten Segment eine Segmentanzahl der zu erwartenden Daten zurück. Wenn es sich um Daten mit der Möglichkeit einer schnellen Zusammenstellung handelt, kann der Bankrechner die Segmentanzahl wie bisher genau liefern. Handelt es sich jedoch um eine größere Datenmenge mit ggf. längerer Aufbereitungszeit (z. B. ZIP), darf auch eine ungefähre Segmentanzahl zurückgeliefert werden.
In jedem Fall muss sich der EBICS-Client so verhalten, dass er so lange Segmente abruft, bis er die Ende-Nachricht bekommt.

Um nun bei Abholungen Timeouts während der Sammel-/Aufbereitungsphase des EBICS-Bankrechners zu vermeiden, sollte der Bankrechner beim Abruf eines Folgesegments auch einen Wert zurückgeben dürfen, der aussagt, dass er mit der Datenzusammenstellung noch nicht fertig ist. Der EBICS-Client kann das gewünschte Segment wiederholt anfragen, bis er es bekommt.

Optionale Begrenzung der abzuholenden Datenmenge durch den EBICS-Client, um zu große Dateien zu vermeiden

Der Download von großen Datenmengen kann aber auch durch Bedingungen problematisch sein, die nicht im Einflussbereich des EBICS-Servers bzw. dessen Betreibers liegen. Ursachen können in der Systemauslegung des Clients oder in der Infrastruktur liegen. In solchen Fällen kann es u. U. helfen, wenn die abzurufende Datenmenge kundenseitig über die heutigen Möglichkeiten hinausgehend (historischer Abruf) weiter eingeschränkt werden kann.

Zum Beispiel wäre es wünschenswert, wenn der EBICS-Client einen Download unter Angabe einer maximalen Größe initiieren kann. Denkbar ist ein neuer optionaler Parameter für die Größe der Abholdaten. Beim Download liefert der EBICS-Bankrechner dann immer vollständige Datenblöcke (z. B. Kontoauszug) und davon mindestens einen. Die Größenbegrenzung sollte stets als Richtwert interpretiert werden, den der Bankrechner auch überschreiten darf. Damit gäbe es auch clientseitig neben der historischen Abholung eine weitere Möglichkeit, die Größe der Abholdaten selbst zu steuern.

Mit diesen beiden Erweiterungen ist EBICS auch zukünftig für die wachsenden Datenmengen gerüstet.

Michael Lembcke

Softwarehersteller und Finanzinstitut fördern EBICS in der Schweiz

Seit 2013 bieten Schweizer Grossbanken ihren Firmenkunden den Kommunikationsstandard EBICS an. Die Schweiz ist seit Mai 2015 offizielles Mitglied der EBICS-Gesellschaft, welche sich zum Ziel gesetzt hat, den Standard in ganz Europa und darüber hinaus zu verbreiten und zu unterhalten. Um EBICS definitiv zum Durchbruch zu verhelfen, bilden der führende EBICS-Hersteller und die Schweizer Grossbank Credit Suisse eine Arbeitsgemeinschaft zur Förderung von EBICS in der Schweiz (AFES). Schweizer Softwarehersteller profitieren von einer Aktion, welche ihnen den Einstieg in EBICS erleichtert.


Zahlungsaufträge aufgeben oder elektronische Kontoauszüge beziehen sind typische EBICS-Transaktionen. Insbesondere im Multibanking ist EBICS sehr beliebt, da Firmen mit nur einer Identifikation verschiedene Banken ansteuern können. In den letzten Jahren sind vermehrt auch mittelgrosse und kleinere Banken in der Schweiz auf den EBICS-Zug aufgesprungen, und die proprietären Schnittstellen verschwinden langsam aber sicher vom Markt. Kürzlich aufgedeckte Internet-Betrugsfälle bei Firmen beflügeln den Standard zusätzlich, denn der EBICS-Mechanismus der verteilten elektronischen Unterschrift (VEU) reduziert das Risiko einer Attacke deutlich.

Die Initiative AFES bietet interessierten Herstellern den bewährten EBICS Kernel von PPI – eine Software-Library, wahlweise in Java- oder C-Code – als Startpaket zu sehr günstigen Konditionen an. Sobald das Wartungsmodell und ein Onboarding-Paket (wahlweise mit Zugang zu einem EBICS-Testserver) vereinbart sind, kann es direkt losgehen. Credit Suisse übernimmt dabei die Rolle des Vermittlers und stellt seine Infrastruktur für Trainings zur Verfügung. So entsteht für alle Akteure eine Win-Situation, und der Finanzplatz Schweiz profitiert von der erwarteten Vereinheitlichung der Corporate-Banking-Schnittstellen.

Die Initiatoren erhoffen sich eine schnellere Verbreitung des Standards in der Schweiz. Dies kommt allen zu Gute, auch ausländischen Finanzinstituten in Europa, welche bereits EBICS als Schnittstelle anbieten. Die Erfahrung hat gezeigt, dass Standardisierung die Basis für mehr Wettbewerb ist und die Bankkunden letztendlich am meisten davon profitieren. Dies zeigen auch die aktuellen Diskussionen in Europa, wonach Banken zunehmend zu offenen Schnittstellen verpflichtet werden sollen. EBICS ist in diesem Zusammenhang sicher ein wichtiger Baustein, und sicher werden weitere Softwarehersteller und Banken gemeinsame Initiativen starten.

Mehr Informationen zur Initiative: www.ebics-initiative.ch.

Carsten Miehling

Instant Payments auf der Sibos

Dieses Jahr gastierte die Sibos in dem beschaulichen Genf. Der Flughafen lag direkt nebenan und man konnte die Flugzeuge mit voller Geschwindigkeit starten sehen. Und genauso hob auch Instant Payments ab. Es war eines der beherrschenden Themen auf der Sibos. Die Vorbereitungen für die Einführung laufen auf Hochtouren.


Instant Payments ist wahrscheinlich eine disruptive Technologie, die Volumina von anderen Zahlungsverkehrsmitteln abschöpfen wird. Dazu gehören der Massenzahlungsverkehr, der heute beispielsweise über EBICS läuft, aber auch Kartenzahlungen – Debitkarten- und Kreditkartenzahlungen am POS. Des Weiteren wird erwartet, dass vermehrt Zahlungen im Internet über Instant Payments abgewickelt werden. Ein Angriff auf PayPal und Co?

Was im ersten Moment harmlos aussieht, kann die Welt des Zahlungsverkehrs umkrempeln. „The New Normal“ wurde Instant Payments auf der Sibos genannt, obwohl es noch nicht einmal in Europa richtig abgehoben ist. Dies zeigt aber deutlich, was für ein Potenzial in Instant Payments vermutet wird. Die „neuen“ Player von gestern, wie z. B. PayPal und Co., könnten die Verlierer von morgen werden.

Die bisherigen Instant-Payments-Lösungen sind rein nationale Lösungen. Natürlich werden sich die wesentlichen Volumina im Zahlungsverkehr mit Instant Payments rund um den Kirchturm abspielen. Aber das muss nicht so bleiben. Mit einem Instant Payments, das europaweit funktioniert, könnten schnell neue Services entstehen. Dabei werden die Banken eine größere Rolle spielen als beim Bezahlen mit Kreditkarte oder über PayPal. Sie würden dabei ihren Anspruch, im Zahlungsverkehr führend zu sein, verteidigen und vielleicht sogar wieder Boden gutmachen können.

Die Grenzen von 15.000 € pro Instant-Payments-Transaktion werden schnell erhöht. Man munkelt von mittleren 6-stelligen Beträgen. Europäische Bankgruppen stehen in den Startlöchern, um dieses Limit innerhalb ihrer Gruppe von Beginn an aufzubrechen. Dies könnte auch für Firmenkunden interessant sein. Industriegüter, Dienstleistungen und Waren werden heute noch recht altmodisch bezahlt und damit teuer und langwierig. Mit Instant Payments könnte sich das ändern. Natürlich darf eine Zahlung per Instant Payments einige Sekunden länger oder sogar einige Minuten dauern, wenn beispielsweise der Betrag Millionen überschreitet und wenn Embargo-Prüfungen, AML und Settlement synchron ablaufen. Auch hier könnten sich wieder fundamentale, disruptive Änderungen ergeben.

Instant Payments ist übrigens nicht durch die PSD II initiiert. Was für eine vergebene Chance. Die EZB hat hier die Feder geführt und den Schritt hin zu einem europäischen Instant Payments nicht gewagt. Die Interoperabilität mit nationalen Instant-Payments-Lösungen ist derzeit noch unklar. Vielleicht schafft die PSD III, die schon in der PSD II angekündigt ist, den passenden rechtlichen Rahmen. Derzeit ist noch alles freiwillig und die Auswirkungen – auch auf den Massenzahlungsverkehr mit EBICS – sind noch nicht klar. Fest steht, dass die Europäisierung von Instant Payments Chancen bietet. Und die sollten wir nutzen.

Michael Lembcke

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