Payments before Christmas – Weihnachtseinkäufe mit Request to Pay?

Die Weihnachtszeit. Nicht ganz so weiß, nicht ganz so besinnlich und nicht ganz so friedlich, wie es in den Geschichten immer heißt – aber auf ihre Art doch ganz reizvoll. Mitunter allerdings ein wenig verwirrend, vor allem wenn ich auf meine Kontoauszüge der vorweihnachtlichen Einkaufsabenteuer schaue.

Die meisten werden es kennen: Das gut gemeinte „…aber dieses Jahr schenken wir uns wirklich nichts!“ hat eine noch geringere Halbwertszeit als die bald darauf zu fassenden Neujahrsvorsätze. Und auch wenn Weihnachten gefühlt im Herbst mit den ersten Lebkuchen in den Regalen beginnt, wird die Zeit für den Einkauf der Präsente dann doch auf kurz vor knapp verschoben. Und so finde auch ich mich dieses Jahr wieder im Shoppingwahn gefangen. Eltern, Schwester, Großeltern, Familie des Partners mit fünf Geschwistern – und die nächste Generation steht auch schon vor der Tür. Die verschiedenen Wunschzettel, Einkaufslisten und Planungen mit meinen Kontoauszügen in Einklang zu bringen, gleicht einer Aufgabe für Sisyphos persönlich.

Meine bevorzugten Onlinekaufhäuser haben ein Lastschriftmandat von mir bekommen, in anderen digitalen Läden funktioniert nur die Zahlung per Kreditkarte, die Konzertkarten bezahle ich mit PayPal und die analog und „offline“ erstandenen Güter bekamen die Händler per Girocard vergütet.
All diese Positionen auf meinem viel zu langen Kontoauszug wiederzuerkennen, erinnert mich daran, dass ich für meine Tante ja noch ein dreitausend Teile Puzzle bestellen muss. Ist das Teeservice für die Oma eigentlich schon bezahlt oder wird das noch abgebucht? Wann wird eigentlich diesen Monat der Betrag meiner Telefonrechnung eingezogen? Das ist doch sonst auch immer so um diese Woche, oder? Und was ist eigentlich der „XY Shop“, und wofür bekam der 90 € von mir?

Wie jedes Jahr habe ich das Gefühl, dass mir der Einkaufswahnsinn durch die Finger gleitet und ich den Überblick verliere. Der zeitliche Versatz von Bestellung und Zahlung sowie die vielen unterschiedlichen Fristen lassen mich mit einem unguten Gefühl im Bauch zurück – gerade in dieser Zeit der unüblichen Abbuchungen von meinem Konto kann schnell etwas durchgehen. Was nützt es mir, dass ich eine per Lastschrift erfolgte Abbuchung zurückfordern kann, wenn ich sie nicht mehr zuordnen kann? Welche Kreditkartenzahlung habe ich wirklich autorisiert?

Es sollte einfacher sein. Es sollte geordneter sein. Es sollte unmittelbarer sein. Nächstes Jahr um diese Zeit?

Ich stelle mir vor, wie ich das neue Radio für meine Mutter bestelle und im Moment der Bestellung in meiner Banking App aufgefordert werde, den genauen Betrag dafür freizugeben. Die kitschigen Weihnachtspullover mit der Rentiernase werden in zwei verschiedenen Größen geordert, anprobiert. Und im Moment der Rücksendung des viel zu großen Exemplars fragt mich mein Onlinebanking, ob ich die Zahlung für den passenden Pulli freigebe.

Es liegen drei Pakete für mich in der Packstation. Um die Klappe öffnen zu können, weise ich nach Aufforderung die Zahlung an. Der XY Shop will schon wieder 90€ von mir? Abgelehnt! Dort habe ich doch gar nichts bestellt. Und meine Telefonrechnung ist im Dezember scheinbar höher als üblich gewesen und darum die Zahlungsaufforderung nicht automatisch bestätigt worden. Ich prüfe den Verbindungsnachweis und autorisiere dann per Hand – stimmt, ich habe mit den Verwandten in England telefoniert.

Die Aufforderung zur Zahlung, der Request-to-Pay. Ob meine nächste Weihnachtszeit besinnlicher oder friedlicher dadurch wird, wer weiß. Aber mehr Kontrolle über meine Zahlungen zu bekommen, bevor diese tatsächlich stattgefunden haben, und mir so meine Verwirrung beim Blick auf das Konto zu nehmen, das klingt doch fast so schön wie weiße Weihnacht.

Autor: Anuschka Clasen

XS2A ohne Drittdienstanbieter? Warum nicht!

Im Rahmen der PSD2 wurde europaweit eine Schnittstelle für Drittdienstanbieter (XS2A-API) eingeführt. Die EU als Initiator strebt damit an, den Zugang zu den Bankkonten der Kunden für Dritte zu öffnen und damit den Wettbewerb im Markt zu fördern. Seit dem 14.09.2019 ist die XS2A-API fristgerecht in Europa von den Banken in Produktion genommen worden. Seither orientieren sich die Marktteilnehmer neu, adjustieren die XS2A-API an die Bedürfnisse der Stakeholder und arbeiten intensiv an Diensten sowohl für Verbraucher als auch für Firmen.

Als regulatorisches Must-have ist die XS2A-API für Banken zunächst einmal ein Kostentreiber. Jedoch wurden von Anbeginn Mehrwertdienste angedacht und z. B. von der Berlin Group bereits spezifiziert, um den Banken eine Einnahmequelle zu ermöglichen. Doch den Phantasien hinsichtlich der Einnahmequellen, von denen es im aktuellen API-Hype viele gibt, sind keine Grenzen gesetzt.

Wir reiten also für den Moment die Hype-Welle mit und stellen uns die XS2A-API als alternativen Zugangskanal für Firmen vor. Warum nicht. Aus technischer Sicht sollten die Hürden gering sein. Eine Firma könnte sich wie ein Drittdienstanbieter durch ein eIDAS-Zertifikat ausweisen. Das Zertifikat würde sich nur in den spezifischen Feldern für Drittdienstanbieter unterscheiden. Ähnlich zu EBICS können eingereichte Aufträge oder Anfragen mit einer Signatur versehen werden, an Hand derer der Empfänger die Unversehrtheit der Nachricht prüfen kann. Die Sicherheit auf dem Transportweg wird durch die Verwendung von TLS gewährleistet.

Aus fachlicher Sicht können mit Hilfe des Use Cases „Zahlung initiieren“ sowohl Einzel- als auch Sammelzahlungen ausgeführt werden. Für die Freigabe werden den Verbrauchern die gängigen Autorisierungsverfahren aus dem Online-Banking angeboten (z. B. photoTAN, pushTAN). Für Firmen wäre das wahrscheinlich ungeeignet, sodass eher Corporate Seals zum Einsatz kommen würden, was zu spezifizieren ist. Ebenso die Abfrage von Kontoinformationen (Salden, Transaktionen, Details) ist über die XS2A-API möglich. Die dafür erforderliche Einwilligung (consent) könnte in diesem speziellen Fall, wo zwischen Firma und Bank ein Vertrauensverhältnis besteht, durch eine dauerhaft gültige Einwilligung gelöst werden.

Aus der mittleren Flughöhe gesehen wäre die XS2A-API also eine valide Alternative, die auch bereits in verschiedenen Foren angedacht wird. Hier wird die Idee mit Attributen wie „günstiger, bequemer, echtzeitfähig sowie flexibler bei Anpassungen“ belegt. Jedoch holt uns der Status quo auf den Boden der Tatsachen zurück. Die prägende Spezifikation, die der Berlin Group, lässt den Banken viele Freiräume, die API zu implementieren. In der Bestrebung, alle Banken in Europa über XS2A zu erreichen, stellen diese Freiräume für alle Marktteilnehmer aktuell eine Herausforderung dar. Ein Zustand, der für Firmen nicht einladend ist, noch nicht. Jedoch ist der Grundstein für eine Alternative gelegt.


Autor: Christian Wenz

Benachrichtigung bei SEPA-Instant-Payments-Zahlungseingängen – ein elementarer Baustein der Zahlungsprozesskette

Neben der kurzen Dauer einer finalen Echtzeitüberweisung ist die umgehende Information des Zahlungsempfängers bei Zahlungseingängen ein Kernelement des SCT Inst-Zahlungsablaufs und damit verbundener weiterer Prozessschritte.

Was in der Online-Transaktionsabwicklung zwischen Verbrauchern oder im Händler-Kunden-Verhältnis mittlerweile gut umsetzbar ist, stellt – wie im Blog-Artikel „Echtzeitbenachrichtigungen und EBICS - Schluss mit den „Hoffnungsabfragen“ von Michael Lembcke beschrieben – die beteiligten Akteure im EBICS-Corporate-Umfeld vor Herausforderungen: Zwar haben Umsatz-Notifications mittlerweile Einzug in die ab November 2019 gültige Anlage 3 des DFÜ Abkommens gehalten und sind dort als camt.054-Nachrichten, die mittels der EBICS Auftragsart C5N abgeholt werden können, spezifiziert, allerdings müssen diese aktiv vom Zahlungsempfänger bei der Bank abgeholt werden. Eine aktive Push-Benachrichtigung des Zahlungsempfängers war bislang nicht vorgesehen. Mittlerweile konnte diese funktionale Lücke allerdings geschlossen werden, indem die EBICS-Spezifikation um eine auf dem WebSocket-Protokoll basierende Information vom Bankrechner an den Kunden erweitert worden ist. Somit können Umsatzinformationen dann zeitnah abgeholt werden, sobald der zugrunde liegende Zahlungseingang stattgefunden hat. Erfolglose „Hoffnungsabfragen“ entfallen somit.

Da mit einer direkten Benachrichtigung über den Zahlungseingang auch schnellere und effizientere Gesamtabläufe im Corporate-Umfeld möglich sind, ist es an der Zeit, diese wichtige Funktion genauer zu betrachten.

Ausgangspunkt der Reise in die Instant-Notification-Welt ist die globale Vernetzung der Gesellschaft. Nahezu zu jeder Zeit und an jedem Ort der Welt sind digitale Services verfügbar: zunehmend in Echtzeit – „always on, always instant“. Waren früher prozessbedingte Wartezeiten durch klassische Bezahlvorgänge, die je nach Empfängerland mehrere Tage in Anspruch nehmen konnten, und langsame logistische Prozesse beim Versand der Waren der Standard, ermöglicht die fortschreitende Digitalisierung immer durchgängigere Prozessketten ohne Medienbrüche und Wartezeiten und sorgt für ein hohes Wachstum im Bereich neuer digitaler Angebote.

Einige aufeinander aufbauende Schritte der Kette lassen sich nicht ohne Weiteres in die Instant-Welt überführen, da prozessuale Abhängigkeiten zur nicht digitalen Welt bestehen. Andere Schritte hingegen sind heute schon 24/7/365 verfügbar – teilweise mit Finalität innerhalb weniger Sekunden. Hierzu zählt u.a. der Bestell- und der anschließende Bezahlprozess.

Das Zauberwort hierfür heißt Instant Payments, die eine sofortige Gutschrift des Zahlbetrages beim Empfänger vorsehen und somit auch eine sofortige Leistung nach Bezahlung ermöglichen können. Was in Bezug auf digitale Produkte funktioniert, gestaltet sich im Bereich des Versandhandels schwieriger: Hier ist zwar eine Beschleunigung des Gesamtprozesses durch einen schnellen Zahlungseingang beim Händler möglich, eine direkte Verfügbarkeit der bestellten Ware lässt sich nur schwerlich darstellen und der Kunde tritt über einen, wenn auch verkürzten Zeitraum, in Vorleistung.
Ein Kauf auf Rechnung wäre aus Sicht des Kunden die risikoärmste Variante. Für den Händler/Lieferanten birgt sie jedoch erhöhte Risiken, da dieser in Vorleistung tritt und nicht von einer zeitnahen Begleichung der offenen Forderung ausgegangen werden kann. Vorkasse mittels klassischer Bezahlmethoden inkl. Karten führt lediglich zu einer Umkehr der Risikoposition, jedoch nicht zu einer optimalen Risikoaufteilung zwischen Händler und Käufer. Diesem Umstand kann derzeit nur ein Intermediär begegnen, der als für den Händler und Käufer vertrauenswürdige Instanz die Übergabe der Ware und den Bezahlvorgang zeitgleich abwickelt. Keine Bezahlung – keine Ware und umgekehrt. Klassischer Nachnahmeprozess also.

Welche Rolle spielt hierbei nun die Notification des Zahlungsempfängers? Ohne eine umgehende Benachrichtigung des Begünstigten über den Zahlungseingang sind beschleunigte Abläufe und damit verbunden auch neue innovative Produkte, die auf einer direkten Bezahlung basieren, undenkbar. Nur mittels einer in den Zahlungsprozess integrierten oder unmittelbar daran anschließenden Information an den Begünstigten kann das zugrunde liegende Geschäft abgeschlossen oder zumindest der nächste Schritt in der Prozesskette gegangen werden – sei es mittels eines Online-Prozesses über eine API, die von der Bank hierfür bereitgestellt wird, oder durch die Nutzung des EBICS-Kanals in Verbindung mit einem Push-Service.

Bislang erfolgten Umsatzbenachrichtigungen i.d.R. mittels untertägigen Kontoinformationen (Umsatzinfo MT942) oder im Kontoauszug (MT940), der mit einem Versatz von einem Tag bereitgestellt wurde. Durch die im SCT Inst verankerte verpflichtende umgehende Rückmeldung bei einem Instant-Payments-Zahlungseingang ist erst der vollumfängliche Abschluss des Zahlungsvorgangs möglich. Insbesondere für den Einsatz von Instant Payments am POS ist dies unerlässlich. Lange Wartezeiten bis zum Abschluss der Transaktion würden eine Kundenakzeptanz verhindern. Die Benchmark hierfür ist die Dauer einer Kartenzahlung.

Doch nicht nur am POS ist eine umgehende Benachrichtigung relevant: Bestehende Bezahlverfahren wie z. B. Rechnungsbegleichung mittels Instant Payments im Online-Banking oder auch die klassische Nachnahme an der Haustür profitieren hiervon. Im ersten Fall liegt der Vorteil in einem beschleunigten Gesamtablauf für alle Beteiligten und in letzterem handelt es sich insbesondere um die Substitution klassischer Zahlungsinstrumente wie Bargeld oder Karten.

Aber auch bei der Entwicklung zukünftiger Bezahlverfahren wie z.B. Request to Pay wird die Notification eine tragende Rolle spielen. In diesem Zusammenhang möchte ich gerne auf einen weiteren EBICS-Blog-Artikel meines Kollegen Eric Waller verweisen, der sich mit diesem Thema beschäftigt: „Request to Pay verändert den Zahlungsverkehr – erste Use Cases“.

Autor: René Keller

Formatfehler bei EBICS-Aufträgen – Testservices können helfen

EBICS wurde speziell für den sicheren und performanten Datenaustausch von Dateien beliebiger Größe im Banken-Firmenkundengeschäft konzipiert. Für Zahlungsverkehrsaufträge gilt, dass eine Datei, die zum EBICS- Server hochgeladen wird, inhaltlich stets dem definierten Geschäftsvorfall (Auftragsart, FileFormat-Parameter oder BTF) und den dafür spezifizierten Formatvorgaben entsprechen muss. Bei Zahlungsverkehrseinreichungen sind Sammeldateien mit Einzeltransaktionen, die nach Auftraggeberkonten gruppiert sind, gängige Praxis. Die Protokollierung (HAC und PTK) der serverseitigen EBICS-Vorgänge ist für Zahlungsverkehrsaufträge z. T. formatspezifisch. Die Berechtigungsprüfungen und die Protokollierung erfordern es daher, dass der EBICS-Bankrechner das Einreichungsformat zumindest in den relevanten Stellen kennt und auslesen kann (z. B. Auftraggeberkonto und Betrag). Zum Auslesen der Informationen führt der EBICS-Bankrechner eine Formatprüfung durch. Bereits bei dem ersten erkannten Formatfehler bricht der EBICS-Bankrechner üblicherweise die Prüfung ab. Der Auftrag wird mit Formatfehler abgelehnt und im Kundenprotokoll dokumentiert.

Weshalb wird keine vollständige Prüfung der Datei durchgeführt, und weshalb werden die Fehlerdetails nicht ins Kundenprotokoll geschrieben?

Dafür gibt es verschiedene Gründe. Zunächst umfasst die übliche Servicevereinbarung für das E-Banking per EBICS die Einreichung und zügige Verarbeitung von korrekten Dateien. Eine umfangreiche Formatverifikation mit Fehlerprotokoll ist nicht inbegriffen und auch nicht Kernaufgabe eines EBICS-Bankrechners. Zudem sollen die Bankrechnerkapazitäten für die unverzügliche Abarbeitung formatkonformer Aufträge genutzt werden und nicht für die Analyse von ohnehin fehlerhaften Dateien.

Wie aber kann eine Bank ihren Firmenkunden einen Service anbieten, der die Qualität von Zahlungsverkehrsaufträgen in Bezug auf Format und Fachlichkeit steigert, ohne dabei den EBICS-Bankrechner unnötig zu belasten?

Dafür könnten Kunden Testservices wie die ISO-20022-Testplattform nutzen. Im Rahmen der Harmonisierung des Schweizer Zahlungsverkehrs bieten bereits heute Schweizer Banken ihren Kunden eine Testplattform zum Test von Ein- und Auslieferungsformaten des Zahlungsverkehrs an.
Die Testplattform ahmt die spezifische Produktion der Bank nach. Mit der Testplattform können unter anderem XML-basierte Kunde-Bank-Meldungen validiert und die Schnittstelle Bank-an-Kunde simuliert werden.

Eine Erweiterung der ISO-20022-Testplattform um die Prüfung von Zahlungsverkehrsaufträgen auf spezifizierte Formatvorgaben und Fachlichkeit kann die Qualität der Datei noch erheblich verbessern. Durch eine im Voraus durchgeführte umfassende Formatverifikation von Zahlungsverkehrsaufträgen können Fehler mithilfe eines detaillierten Fehlerprotokolls schnell und einfach identifiziert werden.
Dateien, die hinsichtlich Format und Fachlichkeit nicht korrekt sind, können so schon in einer Vorabprüfung durch einen Testservice erkannt und korrigiert werden, bevor sie zum EBICS-Server hochgeladen werden.


Autoren: Aline Wendler und Michael Lembcke

Request to Pay verändert den Zahlungsverkehr – erste Use Cases

Die Zahlungsanforderung oder fachlich Request to Pay (R2P) ist ein neues Zahlungsinstrument, das den Zahlungsverkehr nachhaltig verändern wird. Ich habe im Whitepaper „Request to Pay komplettiert den elektronischen Zahlungsverkehr“ bereits den Zusammenhang zwischen elektronischen Rechnungen, Instant Payments und dem eben bisher fehlenden Zahlungsinstrument Request to Pay hergestellt.

In diesem Blogbeitrag möchte ich mich nun einigen ersten von zahlreichen Use Cases widmen, die durch Request to Pay einfach an ein bestehendes Bankkonto adressiert werden können:

  • Request to Pay bei bereits versandter Warenrechnung: Ein einfacher Use Case ist, dass die Rechnung bereits klassisch auf dem bisherigen Weg versandt wurde und zusätzlich im Anschluss ein Request to Pay versandt wird. Dieser Use Case zielt in erster Linie darauf ab, die Zahlung der fälligen Rechnung durch den Zahlungspflichtigen zu beschleunigen, indem ihm die Erfassung der Rechnungsdaten erspart bleibt. Der Request to Pay zu der ihm bereits vorliegenden Rechnung wird ihm in seinem Online- oder Mobile-Banking präsentiert und Empfängerdaten, Zahlungsbetrag und Verwendungszweck sind bereits ausgefüllt. Der Zahlungspflichtige braucht nur noch die Ausführung zu bestätigen und mit seinen Credentials zu signieren.
  • Request to Pay in Kombination mit einer Warenrechnung: Der zuvor beschriebene Use Case ist natürlich auch dahingehend vorstellbar, dass sowohl eine elektronische Rechnung als auch der zugehörige Request to Pay dem Zahlungspflichtigen gemeinsam in seinem Online- oder Mobile-Banking präsentiert werden. So wird zusätzlich der konventionelle Postversand eingespart und der Zahlungspflichtige kann seine Rechnung digital sichten und komfortabel zahlen. Gleichzeitig bietet diese Variante auch die Möglichkeit, die Rechnung in einem Bankingarchiv digital abzulegen und jederzeit einer Zahlung wieder digital zuzuordnen.
  • Request to Pay im Zug-um-Zug-Geschäft: Natürlich kann Request to Pay nicht nur bei räumlicher Trennung der Beteiligten eingesetzt werden. Es ist daher auch vorstellbar, den bisherigen Nachnahmeprozess mit Barzahlung zu digitalisieren. Der Paketbote adressiert hierbei eine Request-to-Pay-Nachricht an den Paketempfänger, dieser prüft die Warenlieferung und löst einen Instant-Payments-Auftrag als Antwort auf den Request aus. Der Paketbote wiederum erhält eine sogenannte Notification über den Eingang der Zahlung und gibt die Ware frei.
  • Request to Pay im stationären Handel: Ähnlich wie im zuvor geschilderten Fall ist es auch denkbar, Request to Pay in Kombination mit Instant Payments und Notification im stationären Handel einzusetzen. In diesem Fall wird nicht die Rechnung, sondern der Einkaufsbeleg gemeinsam mit der Request-to-Pay-Nachricht transportiert und kann gemeinsam mit der Buchung in einem digitalen Archiv am Konto abgelegt werden. Das Kassenpersonal gibt den Einkauf natürlich auch hier erst dann frei, wenn die Notification eingetroffen ist.
So sind Zahlungsanforderungen in zahlreichen Branchen einsetzbar und daher wird aus meiner Sicht das neue Zahlungsinstrument Request to Pay den Zahlungsverkehr in seiner bisherigen Form nachhaltig verändern. Ich  werde an dieser Stelle regelmäßig über neue Entwicklungen und natürlich weitere Use Cases berichten.    

Autor: Eric Waller

Moderatorenbeitrag: Erweiterung PPI EBICS-Blog – all about Payments!

Liebe Leserinnen und Leser,

wir freuen uns, Sie heute über die Erweiterung unseres EBICS-Blogs zu informieren.

Im PPI EBICS-Blog "All about Payments" möchten wir Sie zukünftig noch umfassender über Trends und aktuelle Themen rund um den Zahlungsverkehr in den Bereichen EBICS, SEPA, SWIFT sowie Regulierung und Digitalisierung auf dem Laufenden halten.

Ab sofort wird der EBICS-Blog von zwei Autorenteams und im 2-wöchigen Rhythmus für Sie bespielt. Unser Ziel: Ihnen über die Sichtweisen und Erfahrungen unserer Produkt- sowie Consulting-Experten aus Kundenprojekten, Studien und Whitepapern im Hinblick auf aktuelle und zukünftige Anforderungen im Zahlungsverkehrsmarkt aus erster Hand zu berichten.

Wir freuen uns auf Ihr Feedback und wünschen Ihnen weiterhin viel Spaß beim Lesen!

Ihr PPI Autoren-Team

Echtzeitbenachrichtigungen und EBICS - Schluss mit den „Hoffnungsabfragen“ bei Downloads

Wie bereits in meinem Blog-Beitrag im Dezember 2018 vorgestellt, findet auch das Thema Echtzeitüberweisungen (Instant Payments) im Firmenkundengeschäft über das neue Bulk-Format Einzug in die EBICS-Welt. Für die Einreichung von Echtzeitüberweisungen gelten dabei für die EBICS-Transferphase nicht die engen synchronen Zeitregeln des Instant Payments. Die Uhr beginnt erst hinter dem EBICS-Bankrechner zu ticken.

Und wie sieht es mit der Rückrichtung für Instant-Payments-Geschäftsvorfälle im EBICS aus? Immerhin sollte ein Geld-Eingangsbenachrichtigung (Credit Notification), wenn schon nicht in Echtzeit möglich, dennoch möglichst zeitnah dem Zahlungsempfänger zugeführt werden. Im Standard-Rollenverhältnis in der Kunde-Bank-Beziehung holt der EBICS-Client bekanntlich stets die Informationen vom Bankrechner ab. Ein aktiver Versand durch die Bank per EBICS ist hier nicht vorgesehen. Hier hat insbesondere die Wirtschaft die Banken und Die Deutsche Kreditwirtschaft zu einer pragmatischen Lösung einer Push-Möglichkeit gedrängt. Ziel sollte es letztendlich sein, eine Lösung zu entwickeln, die sich ohne Änderungen des EBICS-Protokolls und ohne Veränderung des Rollenverhältnisses umsetzen lässt.

Herausgekommen ist die Idee einer neuen Websocket-basierten Standardschnittstelle, die EBICS-Clients über die Bereitstellung von neuen Informationen für den Download informiert. Hierzu gehört auch die Information über eine neue Bereitstellung einer Credit Notification. Auf diesem neuen Push-Kanal werden somit keine sensiblen Daten übertragen. Die Abholung der relevanten sensiblen Daten erfolgt nach wie vor über den sicheren EBICS-Kanal.

Mittlerweile hat Die Deutsche Kreditwirtschaft diese neue Schnittstelle in der “Spezifikation Echtzeitbenachrichtigungen” spezifiziert und in der Version 1.0 am 18.07.2019 auf der deutschen EBICS-Webseite (www.ebics.de) veröffentlicht.

Nun gilt es, diese Schnittstelle in den EBICS-Clients und in den EBICS-Bankrechnern standardkonform und zeitnah umzusetzen. Bieten sich dadurch doch neue Möglichkeiten zur Optimierung des Firmenkundengeschäftes auch unabhängig vom Instant Payments. So lassen sich z. B. für sämtliche Abholprozesse die häufigen und permanenten “Hoffnungsabfragen” von automatisierten EBICS-Clients einsparen, wie sie u. a. bei Kontoauszugsabrufen durchgeführt werden. Dadurch können sowohl EBICS-Client-Nutzer als auch Bankrechnerbetreiber mit Lastreduzierung rechnen. Das sind doch gute Neuigkeiten, oder?

Autor: Michael Lembcke

Ist das EBICS-Protokoll von der starken Authentifizierung (SCA) im Sinne der PSD2 befreit?

Diese Frage wurde uns wiederholt von französischen und europäischen Finanzinstituten gestellt und es war nicht immer ganz einfach, eine ausreichend formelle Antwort zu geben.
Vor kurzem hat die Banque de France eine offizielle Antwort verfasst, in der sie das EBICS-Protokoll auf die Liste der Verfahren und Protokolle setzt, die gemäß Artikel 17 der delegierten Verordnung (UE) 2018/389 von der starken Authentifizierung befreit sind. Die Verordnung besagt: "Bei juristischen Personen, die elektronische Zahlungsvorgänge über dedizierte Zahlungsprozesse oder -protokolle auslösen, die nur Zahlern zur Verfügung stehen, bei denen es sich nicht um Verbraucher handelt, können Zahlungsdienstleister von der Vorgabe einer starken Kundenauthentifizierung absehen, wenn die zuständigen Behörden der Auffassung sind, dass diese Prozesse oder Protokolle mindestens ein vergleichbares Sicherheitsniveau wie das in der Richtlinie (EU) 2015/2366 vorgesehene gewährleisten." 
 
Das bedeutet jedoch nicht, dass EBICS die starke Authentifizierung nicht unterstützt - weit gefehlt! Die Gewissheit, dass das EBICS-Protokoll mindestens vergleichbare Sicherheitsniveaus garantiert, wie sie in der Richtlinie vorgesehen sind, ist schon seit langem gegeben. Vor diesem Hintergrund möchte ich Sie dazu einladen, den Artikel EBICS und PSD2 – Wie kommt das zusammen? zu lesen oder erneut zu lesen, der vor einigen Monaten in diesem Blog veröffentlicht wurde.

Autor: Marc Dutech

Verifizierung der Hashwerte der Bankschlüssel beim EBICS-Initialisierungsrequest

EBICS-Transaktionen werden in unterschiedliche Phasen unterteilt: Initialisierung, Datentransfer und Quittierung (letztere ist nur für Downloadtransaktionen vorgesehen).

Im Rahmen der Initialisierung werden u. a. folgende Aspekte geprüft:

  • Auftragsart
  • Authentifikationssignatur
  • Hashwerte der Bankschlüssel
  • teilnehmerbezogene Berechtigungen

Die Transaktion wird mit der Transferphase, in der die eigentlichen Auftragsdaten verschickt werden, nur dann fortgesetzt, wenn die Initialisierung erfolgreich durchlaufen wurde. Die Hashwerte der Bankschlüssel werden bei der Initialisierung geprüft, um sicherzustellen, dass der Client die aktuellen Bankschlüssel verwendet. Bei einer nicht erfolgreichen Prüfung sendet der Server den Returncode EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Für den Client ist dies ein Indiz dafür, dass die neuesten Bankschlüssel mithilfe der Auftragsart HPB abgeholt werden sollten.

Vor der Harmonisierung durch EBICS 3.0 konnten die Bankschlüssel direkt oder in Zertifikate verpackt verwendet werden. Gemäß EBICS-Spezifikation müssen bis EBICS 3.0 in der Transaktionsinitialisierung die Hashwerte der öffentlichen Bankschlüssel angegeben werden – unabhängig davon, ob mit der Bank Zertifikate oder Schlüssel ausgetauscht wurden.

Ab EBICS 3.0 sind Zertifikate beim Schlüsselmanagement verpflichtend. In diesem Zuge wurde festgelegt, dass sowohl bei Uploads als auch bei Downloads in den EBICS-Initialisierungsrequests zukünftig die Hashwerte der Zertifikate angegeben werden müssen.

Die Hersteller von EBICS-Bankrechnern ermöglichen ihren Kunden in der Regel einen weichen Übergang, indem sie sowohl die Angabe der Bankschlüssel als auch die Angabe der Zertifikate im DER-Format erlauben. Das bedeutet, dass Kunden nach der Migration auf EBICS 3.0 keine Abholung per Auftragsart HPB ausführen müssen. Sowohl Schlüssel als auch Zertifikate können entweder in spezifikationskonformer HEX-Darstellung oder in alternativer Base64-Darstellung angegeben werden. Eine Mischung beider Darstellungen in einem Request ist üblicherweise nicht vorgesehen.

Übrigens: Mit EBICS 3.0 wurde das Schlüsselmanagement nicht nur für Bankschlüssel, sondern auch für Teilnehmerschlüssel vereinheitlicht. So ist es jetzt nicht mehr nur in Frankreich (CFONB) verpflichtend, Teilnehmer mit Zertifikaten zu initialisieren, sondern in allen Ländern. Auch hier ermöglichen EBICS-Bankrechner in der Regel einen weichen Übergang: Teilnehmerschlüssel mit einer Mindestlänge von 2.048 Bit können auch für EBICS 3.0 verwendet werden, und für die Schlüsselaktualisierung (Auftragsarten HCA, HCS und PUB) können die neuen Zertifikate üblicherweise mit den Schlüsseln der älteren EBICS-Versionen unterschrieben werden.
CA-basierte Zertifikate finden bisher weiterhin nur in Frankreich Verwendung. Aus Sicht der Bankrechner sollte einer Einführung in anderen Ländern allerdings nichts im Wege stehen.


Autor: Hendrik Chlosta

GPI und EBICS – Wie geht das zusammen?

Ist GPI nicht ein reines SWIFT-Thema? Auf den ersten Blick nun einmal ja. Die Abkürzung kommt von SWIFT und steht für „Global Payments Innovation“. Die Initiative für GPI wurde Ende 2015 schon mit breiter Unterstützung von vielen globalen Banken gestartet.

Die Basis von GPI ist die eineindeutige Referenz, kurz UETR (Unique End-to-End Transaction Reference), die eine Zahlung durch die manchmal lange Korrespondenzbankkette begleitet. So eine Referenz ist zwar ein Ungetüm von 36 Zeichen in der nach einem allgemeingültigen Algorithmus definierten Form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, aber das Ungetüm sichert die Eineindeutigkeit ohne zentrale „Vergabestelle“. Wurde die UETR anfänglich nur in einer CUG (Closed User Group) für (Firmen-)Kundenzahlungen in MT103-Nachrichten verwendet, haben inzwischen alle Zahlungen im FIN-Netzwerk so eine Referenz – gleichbleibend vom Anfang bis zum Ende der gesamten Zahlungskette.

Der zweite wesentliche Baustein von GPI ist der sogenannte Tracker. Der Tracker ist eine zentrale Datensammlung bei SWIFT zu allen GPI-Zahlungen. Er stellt den beteiligten Banken umfassende Informationen zum Status einer Zahlung in der Korrespondenzbankkette, zu Gebühren und zu Währungsumrechnungskonditionen bereit. Während der FIN-Transport diese Informationen aus den transportierten Nachrichten selbst herausliest, können non-FIN-Banken den Tracker auch aktiv informieren. In der aktuellen Diskussion ist die sogenannte Confirmation – die Meldung der Gutschrift auf dem Konto des Begünstigten am Ende der Zahlungskette. Auf die Confirmation sollen ab 2020 alle FIN-Banken verpflichtet werden.

Aber warum der ganze Aufwand? Transparenz und Schnelligkeit – die beiden wesentlichen Herausforderungen im Korrespondenzbankgeschäft werden mit GPI angegangen. Durch die umfassende Verwendung von UETR liegen nun Statistiken vor: Durchschnittlich 40 Prozent der GPI-Überweisungen werden den Endbegünstigten innerhalb von fünf Minuten gutgeschrieben, innerhalb von 30 Minuten sind es 50 Prozent, innerhalb von sechs Stunden 75 Prozent und innerhalb von 24 Stunden nahezu alle. So eine Aussage war vor GPI einfach unmöglich. Hingegen kann jeder Treasurer Fälle berichten, bei denen Zahlungen spät oder gar nicht ankamen, mit hohen, unerklärlichen Gebühren, mit unklaren oder sogar ohne Verwendungszweckinformationen.

Neben den technischen Details wie UETR und Tracker gehört zu GPI ein Regelwerk, in dem die möglichst taggleiche Weitergabe einer Zahlung mit vollständigem Verwendungszweck, unter Angabe von abgezogenen Gebühren und Währungsumrechnungsdetails vorgeschrieben ist. Da es ja keine globale Transparenzrichtlinie gibt, muss dies auf multilateralem Vertragswerk begründet durchgesetzt werden. Und das ist auch gut so – Zeit dafür ist es schon lange.

Der (Firmen-)Kunde soll besseren Service im grenzüberschreitenden Zahlungsverkehr bekommen. Neben der Schnelligkeit und Transparenz ist ein weiterer Punkt die Quittung. So etwas gibt es ja eigentlich nur bei einer Barzahlung, im elektronischen Zahlungsverkehr war bisher das Motto: „shoot and forget“. Wenn es keine Beschwerden gibt, ist das Geld wohl angekommen. In den letzten Jahren hat es im SEPA eine beachtliche Entwicklung gegeben, und mit den Instant Payments nach dem Schema SCTinst gibt es auch hier nun eine Quittung. Mit SWIFT GPI ist die Erstellung einer derartigen Quittung ebenfalls möglich, auch wenn dies (noch) eine vollständige FIN-Kette in der Abwicklung voraussetzt. Es ist jedoch noch ein Stück Weg dorthin: Bisher wird an den breiten, erst einmal bankinternen, Umsetzungen gearbeitet. Die Anbindung der Kundensysteme für einen Zugriff auf die Informationen oder gar die Weitergabe von Status und Gebühreninformationen an Kundensysteme befindet sich noch am Anfang. Aber schon die Möglichkeit, im Falle eines Zweifels durch den Zugriff auf eine zentrale Stelle prüfen zu können, wo sich die Zahlung befindet, ist im großen Korrespondenzbanknetz ein erheblicher Fortschritt.

Geht das nur in FIN? Natürlich nicht. Die aktuellen Entwicklungen, z. B. die Migration der Großbetragssysteme (RTGS) wie TARGET2, EURO1 oder CHAPS von MT hin zu Nachrichten in XML nach ISO-20022-Standard, gehen diesen Weg. Die (neueren) ISO-Nachrichtenformate enthalten dedizierte Felder für die UETR, und so wird die Referenz auch außerhalb des FIN-Netzes transportiert. Und erst kürzlich verbreitete SWIFT die Meldung: „SWIFT trials instant cross-border gpi payments through TIPS“[1].

Für eine Anbindung von GPI-Rückmeldungen an Kundensysteme wie TMS oder ERP sind Nachrichten in Form von PSR (payment status report, also pain.002) effizienter als manuelle Prozesse. Aber schon diese Selfservice-Funktionen sind ein bedeutender Schritt hin zu mehr Transparenz. Übrigens sind die Standards zu diesen Rückmeldungen, also Felder (tags) und Codes, in der Harmonisierungsinitiative CGI-MP multibankfähig abgestimmt. In dieser Initiative wirkt PPI nun auch aktiv mit.

Des Weiteren steht auch die Erweiterung an, dass der Kunde seine Referenz in der Zahlung als UETR initiiert – im pain.001.001.03 in besonderen Feldern gemäß der CGI-MP oder auch schon in aktuelleren ISO-Versionen in dedizierten Feldern.

Und genau hier, an der Schnittstelle Kunde-Bank bzw. Bank-Kunde, werden sowohl Kundenzahlungen als auch PSR-Rückmeldungen ja auch oft mit EBICS transportiert. Somit stehen GPI und EBICS nicht im Widerspruch zueinander, sondern ergänzen einander sinnvoll – wie so oft im Zahlungsverkehr.

Autor: Dr. Mario Reichel

[1] Quelle: https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tipshttps://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips

EBICS-Tests mit Kunden im produktiven Bankrechner?

Seit EBICS 2.4 ist es in Frankreich möglich, Geschäftsvorfälle – nicht wie u. a. in Deutschland üblich – über dreistellige Auftragsarten sondern über die bis zu 40-stelligen FileFormat-Parameter auszutauschen. Diese sind bekanntlich jeweils mit den Auftragsarten FUL bzw. FDL einzuleiten. Dabei ist es möglich, ein sogenanntes Test-Flag anzugeben. Darüber kann ein EBICS-Kunde im produktiven Betrieb z. B. beim Senden einer Datei der Bank eine Testeinreichung signalisieren. Vorausgesetzt, es besteht eine bilaterale Vereinbarung über die Nutzung des Test-Flags, kann die Bank den Auftrag annehmen, als Testfall werten und vor der echten Verarbeitung aussteuern. Die Nutzung eines Test-Flags in Produktion ist bei den Banken nicht unumstritten. Eine solche Option wird von deutschen Banken derzeit überwiegend abgelehnt.

Mit der aktuellen EBICS-Version 3.0 und der einheitlichen Nutzung der BTFs anstelle von Auftragsarten und FileFormat-Parametern entfällt das bestehende Test-Flag in der EBICS-Spezifikation. Zudem wurde mit dem EBICS-CR EB-17-01 Element Group Parameter eine verschärfte Prüfung auf die Nutzung von nicht bilateral vereinbarten Angaben in den generischen Parametern des BTFs eingeführt. Unerlaubte Angaben werden nun mit dem EBICS-Returncode 09-0-0-06: EBICS_UNSUPPORTED_REQUEST_FOR_ORDER_INSTANCE abgelehnt.

Als Hilfestellung für die EBICS-3.0-Einführung in Frankreich hat der französische CFONB einen eigenen Migrationsleitfaden erstellt (EBICS 3.0 Aide à la migration BTF & Table de correspondance File Format/BTF). Da in Frankreich das Test-Flag von Banken in der Vergangenheit genutzt wurde und auch weiterhin der Bedarf an einer solchen Option besteht, hat der CFONB für die BTF-Migration die Nutzung des Test-Modus für BTF definiert und als optionale Funktion in den Leitfaden aufgenommen. Somit kann bei bilateraler Vereinbarung zwischen Bank und Kunde auch bei BTF der Parameter TEST für Testfälle genutzt werden. Bei abweichender Parameterangabe erfolgt eine Ablehnung mit dem o. g. Returncode. EBICS-Bankrechner, und EBICS-Clients können diese Funktion optional mit anbieten.

Unabhängig davon gibt es bei EBICS auch die Alternative, für Testeinreichungen eigene speziell für den Test bilateral vereinbarte Geschäftsvorfälle (BTFs) zu nutzen.

Letztendlich bleibt aber festzuhalten, dass bei Nutzung der Testoption in der Produktionsumgebung immer das Risiko besteht, dass Testdateien die Produktion negativ beeinflussen oder gar unerwartet Eingang in die Produktionsdaten finden können.

Sicherer ist da dann doch eine eigene EBICS-Bankrechner-Installation für EBICS-Tests mit Kunden. Warum nicht?


Autor: Michael Lembcke

Standardisierung und Automatisierung in der Beziehung mit externen Vermögensverwaltern dank EBICS

Externe Vermögensverwalter (EVV) oder External Asset Manager (EAM) bieten ihren vermögenden Privatkunden oder institutionellen Kunden wie Pensionskassen und Versicherungen verschiedenste Services an (zum Beispiel Steuer- und Immobilienberatung, Handels- und Anlagegeschäfte). Die Kundenkonten liegen meist auf einer oder mehreren Depotbanken. Die Interaktion mit den Finanzinstituten ist dabei oft weder standardisiert noch automatisiert. Die Kommunikation über Briefpost, Telefon, E-Mail und teilweise auch noch Fax dominiert den Geschäftsalltag.

Wenige, grosse Vermögensverwalter verfügen über einen SWIFT-Anschluss und benutzen diesen für die Abwicklung von Treasury- und Fremdwährungsgeschäften (Meldungskategorie 3), Wertschriftengeschäften (Meldungskategorie 5), Edelmetallgeschäften (Meldungskategorie 6) oder Cash-Management-Geschäften (Meldungskategorie 9). Einige haben proprietäre System-zu-System-Verbindungen realisiert, beispielsweise mittels FTP, um Finanzmeldungen auszutauschen. In der Schweiz beobachten wir einen Trend, dass EBICS sich in diesen Fällen als alternative Anbindungsvariante durchsetzen könnte.

Im Rahmen des PPI-Frühstücks im April 2019 in Lausanne hat ein Vertreter von Credit Suisse das Angebot «Private swift Network (PsN)» vorgestellt. Es handelt sich dabei um die Erweiterung des EBICS-Angebots in der Art und Weise, dass ca. 20 neue EBICS-Auftragsarten (Reports für den Download) aus den oben genannten EAM-Anwendungsfällen zur Verfügung stehen. Dank der Kooperation mit führenden Softwareherstellern von Portfolio-Management-Systemen (wie etwa Allocare oder Expersoft) erreicht die Credit Suisse in der Interaktion mit ihren Partnern eine signifikante Steigerung des Standardisierungs- und Automatisierungsgrads. Konkret können die SWIFT-Meldungen der oben genannten Meldungskategorien jetzt auch über EBICS transportiert werden.

Da das EBICS-Protokoll flexibel bezüglich des transportierten Inhalts ist, bietet Credit Suisse darüber hinaus auch weitere Formate wie beispielsweise CSV oder XML für Rapportierung der Transaktionen und Vermögenswerte an, inklusive Stammdaten der entsprechenden Kundendepots. Von dem neuen Angebot profitieren alle Akteure: Vermögensverwalter können vermehrt Banken kostengünstig via EBICS anbinden und ihre Prozesse automatisieren, Softwarehersteller ihren Funktionsumfang sinnvoll erweitern und Banken ihre Attraktivität für EAM steigern. Über alle Stellen und Prozesse gesehen sinkt auch die Fehlerrate und es steigt die Umsetzungsgeschwindigkeit durch den Wegfall von manuellen Eingriffen.

Schweizer Banken, welche aktuell Projekte in diesem Umfeld umsetzen, planen bereits die nächsten Ausbaustufen im EBICS-Angebot. So sollen in Zukunft nicht nur die Reporting-Funktionen (EBICS-Download), sondern auch die Auftragsfunktionen (EBICS-Upload) angeboten werden. Insbesondere Aufträge im Handel (SWIFT-Meldungskategorie 5) sind gut geeignet für die Einreichung via EBICS. Konkret sollen Börsenaufträge (etwa SWIFT MT502) mittels einer eigener Auftragsart vom Vermögensverwalter an die Bank übermittelt werden. Analog der bekannten Zahlungsauftragsschnittstellen werden bankseitig die Börsenorderschnittstellen angebunden. In diesem Kontext ist auch der Einsatz einer VEU denkbar.

Fazit:
Erste Banken in der Schweiz weiten ihr EBICS-Angebot über die Anwendungsfälle des Zahlungsverkehrs hinaus aus. Das Angebot von Credit Suisse für mittlere und grössere Vermögensverwalter setzt im Markt der EAM-Kundschaft ein Zeichen und wird wohl Nachahmer auf den Plan rufen. Softwarehersteller von Portfolio-Management-Systemen lernen langsam aber sicher das EBICS-Protokoll kennen und erweitern ihre Connectivity-Möglichkeiten um diese Anbindungsvariante. Der Phantasie, welche Formate und Standards in Zukunft über EBICS transportiert werden, sind keine Grenzen gesetzt. Es ist davon auszugehen, dass EBICS auch in anderen Domänen ausserhalb des Zahlungsverkehrs für ein bestimmtes Kundensegment eine echte Alternative zur Kommunikation über das SWIFT-Netz darstellt.

Carsten Miehling

Sie sind Bankkunde und nutzen EBICS: Funktioniert Ihr EBICS-Monitoring auch noch mit EBICS 3.0?

Für das Monitoring der EBICS-Prozesse und -Ergebnisse steht seit EBICS 2.5 den EBICS-Clients neben dem rein textbasierten Kundenprotokoll auch ein XML-basiertes Protokoll für das fachliche EBICS-Monitoring zur Verfügung. Letzteres eignet sich insbesondere für maschinelle Auswertungen. Das textbasierte Protokoll kann durch den EBICS-Client mit der Auftragsart PTK und das XML-basierte Protokoll mit der Auftragsart HAC vom EBICS-Server heruntergeladen werden. Mit EBICS-Version 3.0 ist das textbasierte Protokoll nicht mehr Bestandteil der Spezifikation. Zudem gibt es Änderungen im HAC-Protokoll, die bei der maschinellen Ergebnisauswertung zu berücksichtigen sind. Diese Änderungen wirken sich wegen der erforderlichen übergreifenden Versionsinteroperabilität z. T. auch auf EBICS-Clients niedriger EBICS-Versionen aus, sobald ein EBICS-Bankrechner EBICS Version 3.0 unterstützt.

Für Software-Hersteller und EBICS-Nutzer gilt daher, dass man sich bei den EBICS-Clients, die bereits über Funktionen der maschinellen Kundenprotokoll-Auswertung verfügen, auf Änderungen einstellen muss. Zunächst sollte für maschinelle Auswertungen in EBICS-Clients der Wechsel vom PTK zum HAC vollzogen werden. Außerdem gilt für diejenigen, die bereits das HAC-Protokoll nutzen, dass mit EBICS 3.0 das finale Ergebnis im HAC-Protokoll anders abgebildet wird.

Bisher informierte das HAC-Ende-Kennzeichen mit den Angaben ORDER_HAC_FINAL_POS und ORDER_HAC_FINAL_NEG direkt darüber, ob das Ergebnis der Einreichung positiv oder negativ war. Mit EBICS 3.0 gibt es lediglich noch ein HAC-Ende-Kennzeichen ORDER_HAC_FINAL, welches den Ausgang der Einreichung ausschließlich in Verbindung mit dem letzten Reason Code ausdrückt. Demnach weist dann beispielsweise der finale Code DS04 darauf hin, dass der Auftrag abgelehnt wurde und DS05, dass der Auftrag erfolgreich eingereicht und an die Banksysteme weitergeleitet wurde. Weitere Reason Codes sind zu berücksichtigen.

Also, damit Ihr EBICS-Monitoring auch weiterhin die korrekten Ergebnisse liefert, empfehle ich auf das HAC-Kundenprotokoll zu setzen und sich auf die Auswertung der Reason Codes zu konzentrieren. So behalten Sie auch zukünftig den Überblick in der EBICS-Kommunikation mit Ihrer Bank.


Michael Lembcke
 

Migration zu EBICS 3.0 in Frankreich

EBICS 3.0 ist in Frankreich am 27. November letzten Jahres in Kraft getreten. Gut zwei Monate sind seitdem vergangen und so ist es an der Zeit zu schauen, wie weit die Migration zur neuen Version fortgeschritten ist.

Gegenstand dieser neuen Version ist die Harmonisierung von EBICS mit den folgenden Zielen:
 
  • eine einheitliche EBICS-Version in allen Ländern, in denen EBICS zum Einsatz kommt
  • eine einheitliche Identifizierung der Geschäftsvorfälle und Formate (auch BTF genannt: Business Transaction Format)
  • ein einheitliches X.509-Format für die Schlüsselablage

Das Datum für das Inkrafttreten betrifft nur die französischen Banken und Kreditinstitute und ist nicht verpflichtend für Firmenkunden. Diese können selbst entscheiden, wann sie migrieren möchten.

Die großen französischen Banken arbeiten seit einigen Monaten an den Migrationsprojekten und die meisten können ihren Kunden den EBICS-3.0-Kanal ab sofort anbieten. Die anderen sind in der letzten Testphase und die Öffnung des EBICS-3.0-Kanals steht unmittelbar bevor.

Die kleineren Banken sind noch nicht so weit. Nur wenige haben mit den Migrationsprojekten begonnen.Es ist deshalb sehr wahrscheinlich, dass diese Institute erst in einigen Monaten, vielleicht sogar erst 2020, den EBICS-3.0-Kanal anbieten können.

Diese Unterschiede in der zeitlichen Umsetzung sollten die Firmenkunden, die demnächst auf EBICS 3.0 migrieren wollen, jedoch nicht bremsen. Denn auch die Banken, die schon auf EBICS 3.0 migriert haben, werden in einer mehr oder weniger langen Übergangsphase noch die Version 2.4.2 unterstützen, die seit der Einführung von EBICS in Frankreich in Kraft ist (in Deutschland wird aktuell die Version 2.5 genutzt). Diese Übergangsphase gibt den Firmenkunden Zeit, ihre Client-Software zu aktualisieren.

Vor allem mangelndes Interesse der Firmenkunden an der neuen Version könnte jedoch dafür sorgen, dass die Übergangsphase sich hinzieht. Um dem entgegenzuwirken, können die Banken ihren Firmenkunden zusätzliche Services anbieten, die mit den Erweiterungen der neuen Version möglich werden. Dazu gehören unter anderem das einfachere Einrichten von Transfers und die verteilte elektronische Unterschrift. Sie ermöglicht es Firmenkunden, Aufträge asynchron nach dem Transfer der Datei zu unterschreiben (in der Version 2.4.2 musste die elektronische Unterschrift zusammen mit der Auftragsdatei geschickt werden), und verhilft ihnen so zu mehr Mobilität.

Das wird sich vor allem dann bemerkbar machen, wenn die X.509-Zertifikate komplett virtuell sind, so dass die mobile Unterschrift wirklich nutzbar ist. Experten arbeiten an diesem Thema und so sollte es in einigen Monaten effiziente Lösungen geben…

Marc Dutech

Wie sich EBICS verbessern lässt Teil 10 – Gezielte EBICS-Downloads mit Datum und Uhrzeit

Im Zahlungsverkehr und insbesondere mit der Einführung neuer Verfahren, wie etwa den Instant Payments, wird es für den Bankenkunden immer wichtiger, auch untertägig über die Zahlungsbewegungen auf dem Laufenden gehalten zu werden. Diese Entwicklung stellt im Firmenkundengeschäft auch den EBICS-Standard vor neue Herausforderungen zumal diese Informationen üblicherweise von den EBICS-Kunden aktiv vom Bankrechner abgerufen werden müssen. Insbesondere, wenn Firmenkunden mehrere EBICS-Clients nutzen, ist die heute gängige sog. historische Abholung mit Datumsangabe die geeignete Download-Methode. Da jedoch die historische Abholung durch EBICS lediglich tagesgenau spezifiziert ist, werden die Daten in der Praxis untertägig in großem Umfang mehrfach abgeholt. Zudem hängen fachliche Zeitstempel für EBICS vom Bereitstellungsformat ab und sind damit bestenfalls tagesgenau und schlimmstenfalls auf dem Bankrechner einfach nicht vorhanden. Den abholenden Clients steht daher dann die Aufgabe zu, die redundant abgeholten Daten automatisiert zu filtern. Dieses Verhalten führt derzeit zu einer deutlichen Mehrbelastung aller beteiligten Systeme sowohl auf Seiten der Kunden, als auch auf Seiten der Banken.

Folgende Verbesserung in EBICS könnte bei entsprechender Spezifikation Abhilfe schaffen und gezielte zeitgesteuerte Abholungen erlauben.

Sinnvoll wäre es, wenn der EBICS-Server per Spezifikation eine zusätzliche Variante der historischen Abholung unterstützen würde. Im Gegensatz zur bisherigen standardisierten historischen EBICS-Abholung würde nun bei Start- und Endzeitpunkt jeweils auch die Uhrzeit berücksichtigt. Außerdem sollten sich die angegebenen Zeitpunkte immer auf den Bereitstellungszeitpunkt beziehen. Damit könnte dann der EBICS-Server alle Datensätze liefern, die innerhalb des angegebenen Zeitraums bereitgestellt wurden. Zur flexibleren Handhabung sollte es auch zulässig sein, bei Abholanfragen nur jeweils einen der beiden Zeitpunkte anzugeben. Ansonsten verhält sich die Abholung auch hinsichtlich der Quittungsphase wie die bisherige Standardabholung.

Ich denke, eine solche Lösung einheitlich für alle EBICS Nutzer im EBICS-Standard zu spezifizieren, könnte den Abholprozess für EBICS verfeinern, die Rechnerauslastung reduzieren und insbesondere im Hinblick auf die wachsende Bedeutung von Aktualität deutlich verbessern. Bisher bereits eingesetzte proprietäre Lösungen in den EBICS-Produkten wären überflüssig.

Michael Lembcke

EBICS und die API-Diskussionen – Ein Statusupdate aus der Schweiz

Seitdem SIX Interbank Clearing (SIC) als Repräsentant des Finanzplatzes Schweiz im Frühling 2015 als offizielles Mitglied in die EBICS SCRL aufgenommen wurde, hat sich im Bereich der Firmenkundenschnittstellen bei Banken (Neudeutsch auch „Corporate Communication Interfaces“) einiges getan. Und aktuell rumort es ebenfalls wieder auf dem Gebiet der elektronischen Schnittstellen, sodass es sich lohnt, in diesem Blog wieder einmal einen Blick auf die aktuelle Situation in diesem Bereich in der Eidgenossenschaft zu werfen.

Natürlich soll hier auch die Rede von APIs (Application Programming Interfaces) sein, denn in manchen Geschäftsleitungs-Etagen bei Banken erscheinen diese drei Buchstaben als der große Heilsbringer in der Digitalisierungsstrategie. Haben also APIs, insbesondere für die Abfrage von Kontoinformationen oder die Beauftragung von Zahlung das Potential, die altgedienten Dateitransferprotokolle wie EBICS obsolet zu machen? Insbesondere vor dem Hintergrund, dass gerade neue Startups und FinTechs diese schlanken APIs dem doch etwas aufwändig zu implementierenden EBICS bevorzugen?

Um diese Frage für die Schweiz beantworten zu können, benötigt der mit dem Finanzplatz Schweiz weniger vertraute Leser aktuelle Hintergrund-Informationen. Zunächst einmal ist festzuhalten, dass die Schweiz als Nicht-EU-Mitglied in keiner Weise an die PSD2 (Payment Service Direktive) gebunden ist. Womit ein großer Treiber, die Pflicht eine API anzubieten, für Banken erstmal wegfällt. Des Weiteren gibt es in der Schweiz auch keine standardisierte Schnittstelle fürs Onlinebanking à la FinTS wie in Deutschland. Nichtsdestotrotz ist die frohe Botschaft der Europäischen Union natürlich auch in der Schweiz vernommen worden.

Bevor wir uns etwas vertiefter mit den zurzeit heiß diskutierten API-Initiativen beschäftigen, soll noch einmal die EBICS-Verbreitung gewürdigt werden. In den letzten gut fünf Jahren hat sich das Protokoll nach dem Vorbild der deutschen Implementierung bei allen größeren Instituten als Standardangebot für den elektronischen Austausch von Daten mit Firmenkunden durchgesetzt. Die Protokolleigenschaften, sehr große Volumina transferieren zu können sowie neuerdings auch der Einsatz der VEU (Verteilte Elektronische Unterschrift), werden von mittleren und größeren Firmenkunden sehr geschätzt. Auch alle namhaften Schweizer Softwareanbieter mit Lösungen im Electronic Banking haben EBICS im Angebot.

Soweit so gut, könnte man meinen. Wie eingangs erwähnt, ist hierzulande die API-Diskussion ebenfalls in vollem Gange und wir beobachten momentan drei erwähnenswerte Initiativen, welche nachfolgend kurz vorgestellt werden. Um es an dieser Stelle vorweg zu nehmen, aus Sicht des Autors sind diese Initiativen kein Ersatz für EBICS, sondern ergänzen ein Schnittstellen-Angebot eines Finanzinstitutes für ein bestimmtes Kundensegment (in der Regel kleinere Firmenkunden, die über eine Cloud-Lösung mit der Bank Informationen in beide Richtungen austauschen).

Sehr vielversprechend erscheint momentan „Corporate API“, die Initiative von SIX und den Schweizer Banken. Unter diesem Namen entwickelt die SIX zusammen mit Vertretern der Banken und Software-Hersteller nicht nur einen frei verfügbaren Standard, sondern gleich noch die passende Plattform dazu. Diese Plattform erlaubt eine sehr einfache Teilnahme an einem neu entstehenden Öko-System, das Services weit über den PSD2-Rahmen (AIS, PIS) hinaus anbieten wird.

Als Formate werden bei der „Corporate API“ JSON und ISO20022 XML angeboten. Die JSON-Variante wird dabei sehr einfach und rasch zu implementieren sein und zielt auf SW-Anbieter, welche nicht die Komplexität der ISO20022-Meldungen benötigen. Die ISO20022 XML-Variante unterstützt das gesamte Spektrum der aus der Migration ZV CH bekannten Möglichkeiten. Bereits gegen Ende 2018 werden erste Tests mit Pilot-Banken und -herstellern durchgeführt werden.

Ein weiteres Projekt läuft unter dem Namen „Common API“. Das Common API der SFTI (Swiss Fintech Innovations) lehnt sich stärker an PSD2 bzw. die Implementierung der BerlinGroup an. Gegenüber der Corporate API-Variante formuliert die Spezifikation der SFTI das API allgemeiner und überlässt die Wahl der Zielgruppe dem Service Provider. Gemäß Informationen der SFTI sind bei der Entwicklung dieses Standards die großen Bankapplikations-Anbieter mit an Bord. SIX hat den Entwicklungsprozess der SFTI-Spezifikation von Anfang an begleitet und wird zukünftig die Ergebnisse der SFTI-Arbeitsgruppe weiterführen. Gut möglich also, dass aus zumindest in Teilen die Standards kompatibel ausfallen werden.

Die Situation für Softwarehersteller ist somit in der Schweiz nicht gerade einfach, da einerseits mit EBICS ein etabliertes produktives Protokoll zur Verfügung steht und neue Initiativen in den Startlöchern stehen. Je nach Kundensegment und Geschäftsmodell stellt sich für Lösungsanbieter die Frage, eine oder allenfalls auch gleich mehrere Implementierungen anzubieten. Kommt hinzu, dass einige Banken bereits proprietäre Interfaces publiziert haben (etwa die Hypothekarbank Lenzburg, welche als sehr innovative Fintech-Bank auftritt). Weitet man das Einsatzgebiet auf Europa aus, dann kommen noch bereits bekannte Initiativen wie „Berlin Group“, „STET“ oder „Open Banking“ dazu. Typischerweise hat der Finanzplatz Schweiz keinen existierenden Standard übernommen, da hierzulande das „Swiss Finish“ immer noch hoch im Kurs ist.

Carsten Miehling