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



Gleichberechtigung für EBICS – Anwendungsfall Instant Payments Bulk

Auch wenn es auf den ersten Blick merkwürdig erscheint: In Deutschland werden derzeit auch für die Kunde-Bank-Beziehung Instant-Payments-Anwendungsfälle für das dateibasierte EBICS-Transferprotokoll diskutiert und spezifiziert. Die Anwendungsfälle konzentrieren sich in diesem Fall auf das Firmenkundengeschäft. Insbesondere größere Firmenkunden haben die Anforderung, Sammeleinreichungen an die Banken übermitteln zu können. Daher hat man sich hierzu in der DK etwa für die SEPA-Credit-Transfer-Einreichung auf die spezielle Form der Sammeleinreichung von Instant Payments (Instant Payments Bulk) verständigt, basierend auf dem XML-Format ISO pain.001. Auch für die Rückrichtung der Zahlungsinformationen in der Zahlungskette – vom Empfänger beziehungsweise den Banken – werden entsprechende Geschäftsvorfälle und Formate (etwa Payment Status im Format pain.002) festgelegt. Die so spezifizierten Geschäftsvorfälle und Formatvorgaben werden in Deutschland voraussichtlich ab November 2019 offiziell gültig sein und können von Banken optional angeboten werden.

Was ist die Besonderheit von Instant Payments Bulk? 

Der Unterschied zu reinen Instant-Payments-Prozessen, die beispielsweise am „Point of Sale“ synchron ausgeführt werden, liegt im Fall Instant Payments Bulk über EBICS darin, dass die Einreichung selbst hier nicht als „instant“ gilt. Vielmehr handelt es sich um eine Einreichung zur Ausführung als Instant Payments (SCTINST). Die ausführende Bank des Einreichers zerlegt die Sammeldatei in die einzelnen Transaktionen und führt die Zahlungen als SCTINST aus, sofern der Zahlungsempfänger auf diesem Wege erreichbar ist. Erst ab diesem Zeitpunkt gelten die Bedingungen für die SCTINST. Die Daten der Rückrichtung werden dann von der Bank des Einreichers wieder auf dem EBICS-Kanal an den Einreicher zurückgeliefert. Das bedeutet konkret in diesem Fall für den Standardweg, dass die Daten von der Bank zur Abholung im EBICS-Bankrechner bereitgestellt werden. Im Firmenkundengeschäft nimmt die Bank in der für EBICS definierten Beziehung zwischen Kunde und Bank bekanntlich ausschließlich die passive Rolle ein. Eine aktive Benachrichtigung an den Sender über EBICS ist daher im Firmenkundengeschäft derzeit nicht vorgesehen.

Instant Payments Bulk weil es dringend ist? 

Firmenkunden wollen mit den neuen Geschäftsvorfällen Zahlungen gesammelt und gleichzeitig kurzfristiger einreichen. Auf diese Weise kann mit dem Geld bis zur Einreichung länger gearbeitet werden. Zudem sind die Zahlungen dann sofort garantiert und ausgeführt. Hierbei ist wie für die Empfangsseite auch für den Rückweg eine unverzügliche Benachrichtigung gewünscht. Da im EBICS-Rollenmodell derzeit eine aktive Benachrichtigung des Kunden durch die Bank nicht vorgesehen ist, werden dafür derzeit in Deutschland verschiedene Schnittstellen (APIs) und Verfahren (etwa E-Mail-Push) diskutiert. Dabei ist es eigentlich doch relativ einfach: Warum nicht das bilaterale EBICS nutzen, wie es heute bereits im Interbankenverkehr etabliert ist. Beide Parteien, Kunde und Bank, haben dabei gleichberechtigte Sende- und Empfangsrollen. Es bedarf lediglich der Erweiterung der EBICS-Kundenanwendungen um vereinfachte EBICS-Server-Funktionen. Die Firmenkunden, die Instant-Payments-Bulk-Zahlungen einreichen, könnten dann Daten aus diesen Prozessen auch aktiv empfangen. Solche Anwendungen sind sogar bereits am Markt verfügbar. Die neuen Geschäftsvorfälle sind somit vollständig über den bestehenden Standard und mit den bestehenden Lösungen umsetzbar. Zeit- und aufwandsträchtige Diskussionen über zusätzliche Schnittstellen, Protokolle und Vereinbarungen können entfallen.

Michael Lembcke