Strukturierte Adressen – oder: die Vogel-Strauß-Taktik ist Käse

Die Zeit wird knapp, die nächste große IT-Herausforderung in den ISO-20022-Formaten steht an. Wie schon so oft beginnen die Eidgenossen mit den ersten Regelverschärfungen: Ab November 2022 werden vom Kunden eingereichte ISO-20022-Zahlungen mit unstrukturierten Adressinhalten beim Ultimate Creditor und Ultimate Debtor von den Banken abgelehnt.

Warum nun gerade diese beiden Angaben? Ganz einfach – die in der Masse der Zahlungen eher weniger häufig gefüllten Felder sind Teststrecke und Prüfstand in einem. Eher wenig Transaktionen werden betroffen sein – daher kann man sich dieser Thematik von klein auf und kalkuliert nähern.

„Gar nicht“ geht gar nicht
Für die Anwendungen und deren Entwickler ist das kleinteilige Herangehen allerdings kein gutes Vorgehen. Vieles spricht doch eher für ganz oder gar nicht – Letzteres ist aber keine Option. Dann doch eher, wenn schon strukturierte Adressen, diese bitte überall – also auch beim Creditor, Debtor und den anderen Adressangaben.

Zu kurz gedacht
Wenn Sie jetzt meinen: „Ach, das ist ja die Schweiz, das betrifft mich hier in Deutschland oder Österreich nicht“, dann ist das eine eklatante Fehleinschätzung. Auch im künftigen SWIFT-Zahlungsverkehr sollen ab 2025 ausschließlich nur noch strukturierte Adressen genutzt werden!
Und wer glaubt, dass damit die Kundenschnittstelle, also die korrekte Einlieferung der strukturierten Adressen durch die vielen Kundensysteme, nicht betroffen ist, der übersieht, dass bisher kein System existiert, das eine beliebige, unstrukturiert gelieferte Adresse richtig zerlegen und als strukturierte Adresse weiterverarbeiten kann. Die Vielfalt der internationalen Adressdaten macht dies unmöglich.

Handarbeit ist zumutbar
Also müssen wir jetzt alle ran – Kundenprodukthersteller wie auch Banken selbst. Überall müssen strukturierte Adressen erfasst und über die betroffenen Formate transportiert werden, bis sie dann irgendwann im SWIFT-Netz landen. Erfassungen müssen verändert werden, Datenbankstrukturen angepasst und die inhaltlichen Daten müssen an neuer Stelle im jeweiligen ISO-20022-Format landen. Da wie schon angedeutet eine automatische und fehlerfreie Migration/Wandlung der bisherigen unstrukturierten Adressdaten auf strukturierte Adressdaten nicht möglich ist, müssen wir es unseren Kunden und den Mitarbeitenden in der Bank zumuten, eine menschliche Kontrolle der konvertierten Adressdaten vorzunehmen – ein etwas längeres Projekt also. Für Deutschland wurde dieses schon mal für die neue ISO-Auslandszahlung im ISO-20022-Format pain.001.00.09 festgelegt, ab 2025 dann wirksam.

Zeiträume sind relativ
Wer jetzt noch glaubt, diese Umstellung wird durch ein Wunder irgendwie von selbst passieren, irrt sich: Die Zeit drängt! 3 Jahre sind für die Softwareentwicklung eine denkbar kurze Zeit, und die Arbeiten sind sehr umfangreich. Den Kopf in den Sand stecken, mag bequem erscheinen, führt jedoch schon kurzfristig zum Erblinden. Der frühe Vogel hat Budgets und Order längst vor Augen.

Autor: Michael Schunk

Weiterlesen

Mehr Komfort für EBICS-Kunden

Wenn es darum geht den Komfort für Firmenkunden zu erhöhen, die das EBICS-Protokoll nutzen, gilt es einige Hürden zu bewältigen. Die erste Herausforderung ist die Konfiguration der Kommunikationsparameter, um einen gewünschten EBICS-Bankrechner zu erreichen, die nächste ist der komplizierte Austausch der EBICS-Schlüssel per INI-Brief und Bankschlüsselfreischaltung.

Wenn wir als Kundenprodukthersteller für die erste Aufgabe, also die Konfiguration der Kommunikationsparameter, von Seiten der EBICS-Gesellschaft eine Hilfestellung bekommen könnten, wären wir schnell in der Lage die zweite Aufgabe, den Prozess zum Austausch der Schlüssel, für die Nutzer des EBICS-Protokolls sehr komfortabel zu gestalten.  

Und dieses Szenario ließe sich schnell umsetzen, indem die EBICS-Gesellschaft eine Liste aller EBICS-Banken, deren technischen Zugang und Host-ID und den zuletzt bekannten Bankschlüssel als Hashwert an die berechtigten, registrierten Hersteller liefert. Dann könnten die Kundenprodukthersteller die bereitgestellten Werte in ihre EBICS-Kundenanwendungen integrieren und die Konfiguration des technischen EBICS-Zugangs für den Nutzer erheblich vereinfachen. Eingabefehler auf Nutzerseite mit langwierigen Supportanfragen gehörten der Vergangenheit an und der Anwender hätte eine Hürde weniger zu nehmen, wenn es um die Nutzung von EBICS geht.

Mit den bereitgestellten Daten der EBICS-Gesellschaft ließe sich auch die Verifikation der Bankschlüssel in Kundenprodukten vereinfachen. Damit würde sich der komplizierte Vorgang der EBICS-Schlüsseleinreichung und die Prüfung der Bankschlüssel auf ein Minimum reduzieren. Ja, es ist denkbar, dass dann Kunden in wenigen Minuten eine Freischaltung bekämen und sofort mit der EBICS-Kommunikation beginnen könnten. Der Aufwand für die Aktivierung des EBICS-Zugangs wäre dann vergleichbar mit der Aktivierung des Online-Bankings für den Privatkunden.
Liebe EBICS-Gesellschaft, wie wäre es mit einer EBICS-Bankenliste? So wie sie die DK in ähnlicher Form schon seit Jahren für FinTS-Bankrechner zur Verfügung stellt?  

Autor: Michael Schunk

Weiterlesen

EBICS-Schlüssel: Wie lang ist der Schlüssel zum Erfolg?

Am 21.April 2021 fand ein EBICS-Herstellerworkshop der Deutschen Kreditwirtschaft (DK) statt. Inhaltlich wurden die Kernanpassungen an EBICS, die mit Version 3.0.1 kommen werden, präsentiert. Für mich aber viel interessanter sind die gleichzeitig vorgestellten kryptografischen Anpassungen, die mit November 2021 für die EBICS-Kundensysteme verpflichtend werden. EBICS nutzt in der Kommunikation 3 RSA-Schlüsselpaare: ein Paar für bankfachliche Signaturen, ein Paar für die Authentifikation des EBICS-Fragments und ein Paar für Ver-/Entschlüsselung von Nachrichten.

Für EBICS V2.5 bedeutet diese Anpassung, dass bankfachliche Signaturen (A-Schlüssel) mindestens eine 2048-Bit-Schlüsseltiefe besitzen müssen. Bei der Authentifikation (X-Schlüssel) und Verschlüsselung (E-Schlüssel) wurde ein Kompromiss von mindestens 1984 Bit gewählt. Grund hierfür sind wohl die im Markt existierenden Seccos-Chipkarten, bei denen einer der enthaltenen Schlüssel diese Länge aufweist. Der sogenannte DS-Schlüssel dieser Seccos-Karten besitzt eine 2048-Bit-Schlüssellänge und liegt im speziellen, mit alternativer PIN-geschützten, Bereich des Kartenchips.

 Ergänzend wurde allen Teilnehmern nochmals bestätigt, dass mit der Nutzung von EBICS 3.0.1 alle verwendeten Schlüssel für Authentifikation (X00x), Verschlüsselung (E00x) und bankfachlicher Signatur (A00x) nicht mehr kürzer als 2048 Bit sein dürfen.

Das bedeutet für die Kundenprodukthersteller, dass in absehbarer Zeit ein Prozess zur Schlüsselverlängerung starten muss, damit alle Kunden ab November leicht und einfach auf das neue EBICS 3.0.1 umstellen können. Wenn dies nicht geschieht, ist ein Umstieg auf EBICS 3.0.1 mit den vorhandenen – jedoch zu kurzen – Schlüssel nicht möglich.

Kundenprodukte, die keinen Schlüsselwechsel anbieten, geraten hier ins Hintertreffen. Denn ihre Nutzer müssen sich dann in einem aufwändigen und komplizierten Prozess neue, längere Schlüssel generieren, danach ihren Zugang bei der Bank zurücksetzen lassen und anschließend eine Schlüsselneueinreichung inkl. INI-Brief-Einreichung bei ihrer Bank vornehmen. Danach heißt es Warten, bis der EBICS-Zugang erneut freigeschaltet wird.

EBICS-Kundenprodukte, die ihren Kunden einen Schlüsselwechsel anbieten, haben trotzdem noch die Herausforderung, dass mit EBICS 3.0.1 nur noch X509-Zertifikate in der EBICS-Kommunikation genutzt werden dürfen. Hier kommen ganz neue interne Prozesse in den Kundenprodukten zum Einsatz. Die Umsetzung muss also gut geplant werden und wird i.d.R. nicht einfach möglich sein. Der TRAVIC-EBICS-Kernel der PPI AG hilft jedoch dabei, denn er stellt die notwendigen Funktionen für einen leichten Umstieg zur Verfügung. Ratsam wäre es, in diesem Zuge auch vom bisherigen Schlüsselformat (RDH2) auf das PKCS#12-Format (p12-Datei) für Schlüsseldateien umzustellen.

Eine Herausforderung kommt auf die Chipkarten zu, denn diese besitzen häufig nicht die notwendigen Schlüssellängen und müssen ggf. ausgetauscht werden, sofern das überhaupt möglich ist. 

Fazit:
Es wird Zeit, die Nutzer von EBICS, die mit kurzen Schlüsseln unterwegs sind, anzusprechen, damit sie ihren Schlüsselhaushalt rechtzeitig vor Umstellung auf EBICS 3.0.1 bzw. vor November 2021 aktualisieren, ihre neuen Schlüssel erzeugen und idealerweise signiert mit den bisherigen Schlüsseln bei ihren Banken einreichen. Fatal wäre eine Dysfunktionalität des EBICS-Zugangs ab November 2021, wenn Nutzer nicht mit den dann geltenden Schlüsselanforderungen kommunizieren wollen.

Autor: Michael Schunk

Weiterlesen

Request to Pay – kein Problem dank EBICS

Attraktiv für Verbraucher, wichtige Ergänzung des Kaufs am Point-of-Sale (POS) aus Geschäftskundensicht – so fallen derzeit die Bewertungen für Request to Pay (RTP) aus. Die neue Initiative für eine einheitliche Zahlungsaufforderung (EPC014-20) im europäischen Raum wurde im Juni 2020 vom European Payments Council (EPC) definiert.
Mit einer RTP-Lösung können Kunden ihren Einkauf nun auch direkt beim Kundenberater zahlen, ohne extra eine Kasse aufsuchen zu müssen. Das Einkaufserlebnis wird sich dadurch wesentlich verändern. Im Onlinehandel ist RTP im Vergleich zur Lastschrift die für den Anbieter bessere Zahlungsvariante, schließlich kann letztere gegebenenfalls widerrufen werden. Mit der aus dem RTP resultierenden Überweisung entfallen zusätzliche Gebühren, wie sie bei Kreditkarten, PayPal und ähnlichen Lösungen entstehen. Das gilt auch für darüber hinaus gehende Infrastrukturkosten der Prozessoren.

Ein weiterer Vorteil ist es, dass sich mit RTP alle Informationen transportieren lassen, die die folgende Überweisung aus Sicht des Zahlungsempfängers enthalten muss. Zielsetzung dabei ist eine möglichst vollautomatische Kontierung des Zahlungseingangs. Dies wird dadurch erreicht, dass jede der beteiligten Parteien dazu verpflichtet ist, die einmal erhaltenen Daten zur Weiterverarbeitung an die nächste Instanz weiterzureichen. Damit private Konsumenten diese neue Idee flächendeckend nutzen können, müssen aber zunächst entsprechende mobile Anwendungen für Zahlungspflichtige entstehen. Dies wird zweifelsohne passieren – wenn auch noch einige Zeit ins Land gehen dürfte.

Aktuell noch unklar ist in der EPC-Initiative, wie die propagierte universelle Erreichbarkeit des Zahlungspflichtigen einheitlich realisiert werden kann. Das Grundkonzept, dass der RTP-Empfänger beliebig adressiert werden kann, behindert in diesem Fall eine schnelle Umsetzung. Wie so häufig spricht der EPC auch diesmal davon, dass die neuen Service-Provider hier die Initiative ergreifen sollen. Viele Fragen stehen aber noch im Raum. Die Spezifikation lässt die Antworten offen und baut auf Lösungen der noch nicht vorhandenen künftigen Anbieter.

Genau hier liegt für die Banken die Chance zum aktiven Handeln – und zwar jetzt! Die EBA hat bereits einen für Europa einfachen und umfassend funktionierenden Vorschlag gemacht und setzt diesen bereits in Infrastrukturlösungen um. Das Konzept ist simpel und baut auf dem SEPA-Clearing der Europäischen Union auf. Im RTP-Netz der EBA werden die Zahlungspflichtigen eindeutig mit ihrer IBAN identifiziert. Über das ZV-Clearing der EBA lässt sich nun jede Bank des Zahlers identifizieren und erreichen. Damit erhalten die europäischen Banken wieder Kontrolle im Massenzahlungsverkehr und haben eine europaweite Alternative zu den vielen untereinander mobilen, jedoch inkompatiblen nationalen Zahlungsverfahren im Angebot, insbesondere auch PayPal.

Erhält das Finanzinstitut des Zahlers einen RTP, setzt es den Betreffenden von der Zahlungsaufforderung über bereits vorhandene Online-Banking-Kanäle in Kenntnis. Idealerweise geschieht dies direkt mittels der zugehörigen App der Bank auf einem Mobilgerät. Der Zahlungspflichtige kann dann die Ware sofort bezahlen. Hierfür sind jedoch noch Aktualisierungen der Kundensysteme bei Unternehmen und Zahlern notwendig.

Ebenso wie im B2C-Geschäft lässt sich RTP auch im B2B-Geschäft nutzen. Zumal die Einführung sehr viel einfacher und schneller möglich ist als im Konsumentengeschäft. Mit dem EBICS-Protokoll nutzen schon massenhaft Unternehmen einen Kanal, der sich sehr einfach für RTP erweitern lässt. Häufig reicht schon eine einfache Konfigurationsanpassung in Form von neuen Auftragsarten. So können nun Unternehmen durch Einreichung eines RTP-(pain.013)-Auftrags eine Zahlungsaufforderung an ein anderes Unternehmen versenden. Dieses erhält die Zahlungsaufforderung ebenfalls per EBICS. Als Zieladresse reicht einfach die IBAN, und der Rest läuft europaweit elektronisch – und zwar über die vorhandenen Netze der EBA als zentraler Clearingplattform. Somit ist im Prinzip schon mal jede Firma und jeder Kontoinhaber im SEPA-Raum erreichbar. 

Die zugehörigen Statusrückmeldungen signalisieren dem Rechnungsaussteller in kurzer Zeit, ob der Zahlungspflichtige den gesendeten RTP ablehnt oder akzeptiert. Im letzteren Fall kann die Ware versendet werden. Nicht immer muss die Zahlung sofort initiiert werden, auch Zahlungen zu einem späteren Zeitpunkt werden von der RTP-Spezifikation unterstützt. Beim RTP-Verfahren werden grundsätzlich zwei verschiedene ISO-XML-Formate (pain.013.001.07, pain.014.001.07) genutzt. Bei Bedarf lässt sich auch ein Rückruf implementieren. Alles ist einfach per EBICS transportierbar.
Für eine komfortable Nutzung von RTP können nun die EBICS-Kundensysteme und Firmenkundenportale entsprechende Erfassungs- und Upload-Funktionen umsetzen und die Statusrückmeldungen in ihren Oberflächen anzeigen. Sollte einmal keine Reaktion des RTP-Empfängers erfolgen, lässt sich der Status jederzeit aktiv nachfragen. Oder es kann durch einen Recall (pain.056) ein Rückruf des RTPs initiiert werden.

Da sich die existierenden SEPA-Überweisungen oder Instant Payments im Prozess verwenden lassen, rücken sekundenschnelle Zahlungen und Kontoeingangsmeldungen in den Bereich des Möglichen. Der Vorteil eines RTP gegenüber einer Lastschrift liegt auf der Hand: Es sind keine aufwändigen Mandate sowie deren Lagerung notwendig. Zudem sind solcherart geleistete Zahlungen per se nicht rückrufbar. Für den Händler reduziert RTP damit das Risiko eines Lastschriftwiderrufs, das sonst für einige Wochen existiert.

Für Unternehmen ist jetzt der richtige Zeitpunkt, die Voraussetzungen für RTP zu schaffen. Dann sind sie bereit, wenn die Konsumenten das neue Zahlungsformat jederzeit, mobil und ortsungebunden einsetzen können.

PPI wird in 2021 in den TRAVIC-Produkten die Voraussetzungen für einen europaweiten Erfolg des RTPs schaffen. TRAVIC-Port wird die Erfassung und den Upload von RTP ermöglichen, TRAVIC-Corporate übernimmt die Autorisierung des Einreichers und Validierung des RTP-Auftrages und der TRAVIC-Payment Hub mit TRAVIC-Interbank wird die Weitergabe in das EBA-Netz unterstützen. Banken können durch RTP ihre ehemals zentrale Bedeutung im Zahlungsverkehr, die sie an alternative Verfahren wie PayPal und ähnliche verlorenen haben, wenigstens teilweise wiedererlangen.

Autor: Michael Schunk

Weiterlesen

EBICS und VEU: Schwächen bei Gehaltszahlungen mit vertraulichen Informationen

Die Verteilte Elektronische Unterschrift (VEU) ist seit vielen Jahren eine wichtige Funktion, um Zahlungen von unterschiedlichen Personen selbst an unterschiedlichen Orten einreichen und freizeichnen zu lassen.

Die im EBICS-Protokoll dafür vorgesehenen Auftragsarten und deren fachlicher Inhalt erlauben eine Freigabe auf Basis der Gesamtdatenlage – über den Dateibegleitbeleg – oder gar auf Basis der inhaltlichen Zahlungsdaten. Dafür liefern EBICS-Server die wichtigsten Informationen für jede der enthaltenen Einzelzahlungen bereits in aufbereiteter Form. Ein Kundensystem, das diese Daten anzeigen soll, muss dazu nicht mal das konkrete Zahlungsformat kennen. Das macht die Software so komfortabel. Ausnahmsweise lässt sich sogar eine komplette Zahlungsdatei übermitteln. Doch gerade bei großen Sammelzahlungen stellt das den gerade beschriebenen Komfort wieder in Frage.

In der Zahlungsverkehrspraxis kommen nicht nur einfache Zahlungen und Lastschriften in die VEU-Mappe, sondern auch Sonderzahlungen mit sehr persönlichen Daten, die besonders zu schützen wären. Dazu gehören etwa Pensionszahlungen, Gehaltszahlungen sowie Bonuszahlungen und Gratifikationen, die nicht für die Allgemeinheit und erst recht nicht für die Einsichtnahme durch die Belegschaft eines Unternehmens bestimmt sind.

Genau an dieser Stelle wird eine Schwäche der EBICS-Spezifikation deutlich: der GVC oder PurposeCode, der festlegt, um was für eine Art Zahlung es sich handelt, fehlt, wenn die Einzelzahlungen übertragen werden. Die von Kunden eingesetzten EBICS-Produkte sind deshalb gar nicht in der Lage, selbst wenn die Unternehmen das wollten, vertrauliche Daten in einem Zahlungsauftrag zu schützen. Der Software fehlt das Kriterium, um zu entscheiden, ob Zahlungsdetails angezeigt oder ausgeblendet werden müssen.

Ohne eine Kennung im konkreten Zahlauftrag ist es nicht möglich, vertrauliche von normalen Zahlungen zu unterscheiden. Damit ist die VEU im Prinzip ungeeignet, um etwa Gehaltszahlungen zu prüfen und per VEU freizugeben, weil nicht auszuschließen ist, dass nicht berechtigte Mitarbeiter einen Blick auf die möglicherweise vertraulichen Informationen werfen.

Die EBICS-Gesellschaft sollte sich deshalb beim XML für den HVT eine Erweiterung überlegen, mit der künftig auch diese wichtigen Informationen für die Art der Zahlung übermittelt werden. Solange dies nicht geschieht, lässt sich die VEU für Gehaltszahlungen nur eingeschränkt nutzen.

Autor: Michael Schunk

Weiterlesen

PSD2: Sammlerzahlungen via EBICS absichern

Sammlerzahlungen abzusichern, war schon immer ein Thema. Die frühen Versuche, dafür einen einfachen Schutz vor Manipulation zu etablieren, waren eher halbherzig und haben deshalb auch nie zu einer verlässlichen Absicherung geführt. Beispielsweise wurde zunächst die Summe aller Empfänger-Kontonummern gebildet, um zu verhindern, dass Kriminelle nachträglich die Zahlungen verändern. Als dann die IBAN kam, war es aber selbst mit dieser äußerst simplen Methode vorbei – allein wegen der mathematischen Herausforderungen haben die Banken schließlich ganz darauf verzichtet.

Übrig geblieben sind bis heute allein die Anzahl der enthaltenen Zahlungen und die Gesamtsumme. Dass solche Werte einen wirksamen Schutz darstellen, behauptet erst gar keiner.

Vielversprechender war schon eher, über PSD2 und RTS für mehr Sicherheit bei Zahlungen zu sorgen. Doch für die gerade bei Firmenkunden geläufigen Sammelzahlungen war das noch nicht der Durchbruch. Der Grund: Empfänger, Konto und Betrag anzuzeigen und den Auftraggeber etwa via Dynamic Linking mit allen enthaltenen Daten prüfen zu lassen, ist bei Gehaltszahlungen in einem Unternehmen mit mehr als 10.000 Mitarbeiten kaum sinnvoll zu bewerkstelligen. Allein organisatorisch ist dies schon ein Ding der Unmöglichkeit und technisch kaum auf den etablierten Kanälen zu lösen.

Also wie nun sicherstellen, dass die einmal erzeugte Zahlungsdatei auch unverändert bei der Bank zur Ausführung angekommen ist?

EBICS!

EBICS ist im europäischen Firmenkundenzahlungsverkehr seit Jahren Standard – verfügbar in allen großen Ländern mit hohen ZV-Transaktionszahlen, wie Deutschland, Frankreich Österreich und der Schweiz. Weitere Länder werden folgen.

Also warum definiert die EBICS-Gesellschaft nicht einen allgemeinen und verpflichtenden Prüfstandard, der auf internationalen Hashwertverfahren (z. B. SHA-256) basiert und legt das Regelwerk dazu fest? Das Prinzip: Alle Anwendungen, die ZV-Sammlerdateien erzeugen, generieren dabei auch immer gleich den dazu passenden Hashwert und geben diesen zusammen mit der Zahlungsdatei an die Bank. Dort lässt sich dieser Kontrollwert erneut berechnen, sobald die ZV-Datei ankommt, und dem Kunden vor Freigabe zur Prüfung vorlegen. Fertig.

Einfach und sehr effektiv, weil der identische Hashwert garantiert, dass zwischen der Erstellung der Sammlerdatei und vor der Verarbeitung des Sammlers bei der Bank keine Manipulation stattgefunden hat.

Wenn wir bei der Definition des zu nutzenden Hashwertverfahrens seitens der EBICS-Gesellschaft dann auch noch an den armen Endkunden denken, könnte man statt des 32-Doppelwert-Vergleichs einen Algorithmus finden, der aus dem Hashwert eine Nummer mit 8-10 Stellen – ähnlich einer TAN – macht. Mit diesen Werten können die Kunden und Nutzer heute bereits umgehen. Kontrollwerte zu vergleichen, kostet dabei nur minimal mehr Zeit und ist einfach zu machen.

Diese Definition einfach dem Markt zu überlassen, ist übrigens keine gute Idee. Wenn jeder beteiligte Akteur sein eigenes Süppchen kocht, entsteht eine Vielzahl unterschiedlicher Verfahren, die Kunden eher verwirren als für zusätzliche Sicherheit zu sorgen.

Deshalb gehört es zu den Aufgaben der EBICS Gesellschaft, an dieser Stelle für eine verbindliche Lösung zu sorgen und dadurch endlich auch der PSD2 bei Sammlerzahlungen zu genügen.

Autor: Michael Schunk

Weiterlesen

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

Weiterlesen