EBICS als europäischer Standard für Mobile Payments?

Angesichts der aktuellen Entwicklungen beim Thema Mobile Payments verliert man leicht den Überblick. Neue Lösungsanbieter schiessen fast täglich aus dem Boden, und die technischen Standards wuchern vielfältig. Die Banken laufen Gefahr, in einem wachsenden Geschäftsfeld abgehängt zu werden. Könnte ein europäischer Standard wie EBICS da helfen?


Für mobile Zahlungen gelten dieselben Regeln wie für den transaktionsbasierten EBICS-Zahlungsverkehr: Es geht um sichere Kommunikation, eindeutige Authentisierung und die Vertraulichkeit von Auftrags- und Stammdaten. Bei Mobile Payments heißt das dann „Secure Element“ (SD-Karte, SIM, HCE, etc.), und es ist die Rede von den verschiedenen Übertragungstechniken (QR-Code, Barcode, NFC, BLE etc.). Nichts scheint aktuell geregelt zu sein, zumal verschiedenste Akteure in den Markt eintreten: von den grossen Kreditkarten-Anbietern über Hardware-Produzenten (Apple, Samsung) bis hin zu spezialisierten Dienstleistern wollen im Moment alle den Banken den Zahlungsverkehr streitig machen. Für Banken ist die Aufgabe sehr anspruchsvoll, denn nicht alle Institute werden auf alle Pferde gleichzeitig setzen können.
Für einheitliche und sichere Transaktionen im Zahlungsverkehr bräuchten App-Entwickler und Kunden ein Standardprotokoll wie EBICS oder FinTS. Solche Standards sind im übrigen Payments-Umfeld gut etabliert, und mit dem Format ISO 20022 und SEPA als Regelwerk wären ca. 400 Millionen europäische Kontoinhaber sofort erreichbar. Erste Umsetzungen von Standards für mobile Zahlungen finden sich z. B. in der Lösung Jiffy von SIA Italien, die komplett auf SEPA setzt.
Für Konsumenten und Banken hätte dies zudem den Vorteil, dass keine Dritten an den Transaktionsgebühren partizipieren, wie das insbesondere bei Kreditkartenzahlungen – und zusätzlich bei ApplePay – der Fall ist. Die Institute bekämen die Kontrolle über den Markt zurück. Organisationen wie das European Payments Council (EPC) könnten den Standard in Europa einführen und weiterentwickeln.

Vielleicht ist es etwas gewagt, EBICS als Standard für Mobile Payments zu bezeichnen, da EBICS in erster Linie für die asynchrone Verarbeitung entwickelt worden ist. Meine Blog-Kollegen haben jedoch schon auf entsprechende Erweiterungspotenziale von EBICS hingewiesen: Die Interaktionen müssten in Echtzeit ablaufen. Pro Einzeltransaktion wäre eine synchrone Rückmeldung erforderlich. Wenn dann in naher Zukunft noch das Realtime-Clearing in ganz Europa etabliert sein wird, ergibt das Ganze vielleicht Sinn. Auf Rückmeldungen bin ich gespannt.

Carsten Miehling 

Warum Banken alte EBICS-Versionen abschalten sollten

Haben Sie noch den Überblick über die verfügbaren EBICS-Versionen? Auf welchem Stand ist Ihr EBICS-Client? Welche Versionen lässt der Bankrechner zu? Dieser Artikel gibt einen Überblick und erklärt, was ein Wildwuchs an Versionen für die Nutzer zur Folge hat.


EBICS wird in Deutschland seit dem 1. Januar 2008 mit der Version 2.3 offiziell eingesetzt. Davor wurden bereits EBICS-Leistungen ab der Version 2.0 von einigen Kreditinstituten angeboten. Die erste gemeinsam mit Frankreich entwickelte Version ist die Version 2.4, die in der finalen Fassung 2.4.2 seit dem 16. Februar 2010 gültig ist. Die aktuelle verfügbare EBICS-Version ist die Version 2.5 vom 16. Mai 2011, die vorrangig in Deutschland und der Schweiz von den Kreditinstituten angeboten wird. Eine neue Version 2.6 ist voraussichtlich für 2016 derzeit in Vorbereitung. Zählt man nun alle veröffentlichten Versionen zusammen, so kommt man auf insgesamt 6 (ohne die zukünftige 2.6), zu denen es passende Bankrechner- und Kundensystem-Implementierungen gab und gibt.

Kunde und Bank benötigen eine gemeinsame EBICS-Version

Das EBICS-Protokoll basiert auf XML-Strukturen. Eine neue EBICS-Version ist neben den inhaltlichen Änderungen und Neuerungen im Wesentlichen durch eine neue XML-Schema-Version gekennzeichnet. Ein EBICS-Kundensystem kann mittels der Auftragsart HEV auf Basis der neutralen Schema-Version H000 die vom jeweiligen Bankrechner unterstützen Versionen abfragen und dann im positiven Fall die Kommunikation mit der aktuellsten gemeinsamen Version fortführen. Ein EBICS-Bankrechner und ein EBICS-Kundensystem können demnach nur dann fehlerfrei miteinander kommunizieren, wenn sich beide auf Basis der gleichen EBICS-Version austauschen. Wäre die Vielfalt der zulässigen Versionen zu groß, würde das Risiko steigen, dass die Kommunikationspartner nicht über eine gemeinsame Version verfügen. Ein Datenaustausch wäre nicht möglich.
Ein EBICS-Bankrechner, der immer alle möglichen EBICS-Versionen unterstützt, wäre mindestens wartungsaufwendig. Außerdem würden sämtliche Verbesserungen, die nur neuere Versionen beinhalten, durch die Nutzung alter Versionen unterlaufen, darunter auch wichtige Sicherheitsfunktionen. Daher hat man sich bei der EBICS-Spezifikation darauf verständigt, bankseitig immer nur die aktuelle und die vorherige EBICS-Version zwingend zu unterstützen.

Updates werden verschlafen – das birgt Risiken

In der Praxis kann das anders aussehen. Kunden versäumen es, zum Teil auch aus Unkenntnis, ihr EBICS-System auf die aktuelle Version zu aktualisieren. Banken versäumen es, die Kunden darauf hinzuweisen und lassen weiterhin auch ältere EBICS-Versionen zu. Der Überblick geht verloren und das beschriebene Risiko nimmt zu.

Daher empfehlen wir den Kreditinstituten, neben den eigenen auch die von ihren Firmenkunden genutzten EBICS-Versionen im Auge zu behalten und ggf. Kunden rechtzeitig zu Updates zu raten. Alte Versionen sollten von den Kreditinstituten bewusst nicht mehr unterstützt und sogar abgeschaltet werden. Firmenkunden selbst sollten von sich aus die Versionen ihrer EBICS-Software auf dem aktuellen Stand halten und regelmäßige Updates einplanen.

Wichtig dabei ist, den Überblick über die genutzten EBICS-Versionen zu behalten und Risiken durch regelmäßige Updates zu reduzieren. Denn im nächsten Jahr wird es voraussichtlich heißen: „EBICS 2.6 gilt“.

Michael Lembcke 

“EBICS as a Service” – Ein Betriebsmodell für mittlere und kleinere Finanzinstitute

Dass sich EBICS als Protokoll im Transaction Banking in der Schweiz durchsetzen wird, ist eigentlich unbestritten. Großbanken und größere Kantonalbanken bieten es bereits an oder sind dabei, eine EBICS-Schnittstelle für Ihre Firmenkunden zu implementieren. Der nächste Schritt wäre eine gemeinsam nutzbare „EBICS as a Service“-Plattform, für die sich jedoch noch ein Anbieter finden muss. 


Die Vorteile einer sicheren, standardisierten und kostengünstigen Punkt-zu-Punkt-Kommunikation sind offensichtlich, so dass das Thema inzwischen auch auf der Agenda von kleineren und mittleren Finanzinstituten auftaucht. Je nach Institut und der anvisierten Anzahl Kunden, welche über EBICS angebunden werden sollen, erscheint manchem Management der Initialaufwand für die Beschaffung, die Installation und den Betrieb eines EBICS-Produktes als sehr hoch.

Fairerweise muss man diesen Bedenken auch als Produktanbieter Rechnung tragen, denn die Umsetzung eines EBICS-Projektes resultiert in einem fünf- bis sechsstelligen Betrag – für manch kleinere Bank ein bedeutender Posten im Budget. Insbesondere in der Schweiz, wo es rund hundert Institute in diesem Segment gibt, wie zum Beispiel kleinere Kantonal- oder Privatbanken, stellt sich die Frage: Warum bietet noch kein Anbieter „EBICS as a Service“ im hiesigen Markt an? Die Vorteile der gemeinsamen Nutzung einer EBICS-Plattform liegen eigentlich auf der Hand und es gäbe auch prädestinierte Anbieter im Markt, welche so ein Angebot auf die Beine stellen könnten.
Analog der Outsourcing-Services für den Betrieb von Banken-Plattformen könnte ein mandantenfähiges EBICS-Modell implementiert werden. Bereits ab einer geringen Anzahl Bankteilnehmer rechnet sich der Business Case und es entsteht eine Win-Win-Situation für alle Akteure. Der Anbieter der Lösung kann mit einem erweiterten Service-Angebot auftreten und amortisiert bei steigender Verbreitung und Nutzung des Standards die Investition in Kürze. Kunden, in dem Fall Banken, können zu geringen Investitions- und reduzierten Betriebskosten ihren Firmenkunden diesen Zugang anbieten und somit in Bezug auf die Anschlussmöglichkeiten zu den Großbanken aufschließen.

Was braucht es jetzt noch? Natürlich ein entsprechendes Produkt, welches auf den Mandanten-Betrieb ausgelegt und bezüglich Operating-Funktionalitäten auf den Betrieb im Rechenzentrum optimiert ist. Des Weiteren einen innovativen Anbieter für Banken-IT-Lösungen, welcher hier als erster in die Bresche zu springen bereit ist. Kandidaten gäbe es in der Schweiz wie gesagt einige, angefangen bei den Betreibern von Avaloq- oder Finnova-Lösungen über klassische Rechenzentren bis hin zu Insourcing-Lösungen größerer Institute.

Wir sind gespannt, wer sich diese Option im Schweizer Markt sichern wird.

Carsten Miehling 

EBICS-Event stößt in Luxemburg auf großes Interesse

Der EBICS-Standard ist dabei, sich in Europa weiter zu verbreiten. Mit Interesse schauen Fachleute daher auch auf den Finanzplatz Luxemburg. Am 28. Januar 2015 versammelten sich dort Zahlungsverkehrsexperten aus dem Fachbereich und der IT der Luxemburgischen Banken, um mehr über EBICS zu erfahren. Zu dem Event mit dem Titel „EBICS – A New Communication Protocol for Payment Activities“ hatte die Luxemburgische Bankenvereinigung ABBL geladen.


Im Mittelpunkt stand die Frage, ob EBICS für Luxemburg von Interesse sein könnte. Die Agenda war auf diese Fragestellung ausgerichtet, vertreten waren folgende Sprecher und Themen:
  • Welcome, Serge Wagener, Banque et Caisse d’Epargne de l’Etat
  • EBICS at a Glance - Security, Use and Implementations, Hermann Fürstenau, PPI AG
  • EBICS - a chance to harmonise customer-to-bank communication standards for electronic banking in Europe, Axel Weiß, EBICS Chairman
  • EBICS Strategy of Deutsche Bank, Thomas Stosberg, Deutsche Bank
  • STEP2 and EBICS, Katja Heyder, EBA Clearing
EBICS wurde dabei unter den Gesichtspunkten Kunde-Bank- und Interbank-Kommunikation beleuchtet, mit besonderem Fokus auf der sicheren Datenübertragung mit EBICS über das Internet. Zu den relevanten Themen für die luxemburgischen Experten zählten auch die Verteilte Elektronische Unterschrift sowie die Unterschiede zwischen der französischen und der deutschen EBICS-Ausprägung.

Der STEP2-Zugang über EBICS zur europäischen Zahlungsverkehrsdrehscheibe war ebenfalls von besonderem Interesse für die Luxemburgische Banken-Community, weil sich dadurch die Kosten reduzieren lassen und ein Backup die Ausfallsicherheit erhöht. Die möglichen Einsatzszenarien für STEP2 und EBICS müssen individuell für jede Bank einzeln betrachtet werden. Wenn ein Backup allerdings unter regulatorischen Maßgaben gefordert werden sollte – was derzeit möglich erscheint – ist EBICS die beste Lösung. Bereits heute schon operieren einige Banken aus Sicherheitsgründen mit zwei unterschiedlichen Infrastrukturen: SWIFT und EBICS. Die komplementären Netz-Topologien von EBICS und SWIFT eignen sich hervorragend als gegenseitiges Backup. Aber auch die Kosten sind häufig ein ausschlaggebender Grund für die Nutzung von EBICS.

Eine wesentliche Motivation für die Luxemburgischen Banken ist natürlich, dass Deutschland und Frankreich einen gemeinsamen EBICS-Standard entwickelt haben. Darüber hinaus wird der EBICS-Standard von einer schlanken EBICS-Gesellschaft mit Sitz in Brüssel weiterentwickelt und weiter verbreitet. Die Schweiz ist dabei, in die EBICS-Gesellschaft aufgenommen zu werden. Vielleicht könnte ja Luxemburg als 4. Mitglied folgen.

Die Idee eines "Global EBICS" ist für einige Banken von strategischer Bedeutung, was auch während der Diskussion in Luxemburg deutlich wurde. "Global EBICS" – oder kurz GBICS – geht mit einem einheitlichen ISO20022-Format à la CGI (Common Global Implementation) einher. CGI dient dabei als einheitlicher Formatstandard und GBICS als einheitlicher Transportstandard und das weltweit. Spannend war in diesem Zusammenhang die Frage nach einem weltweiten Konkurrenzstandard zu EBICS: Gibt es einen vergleichbaren Standard wie EBICS in der Welt, beispielweise in Asien oder Amerika? Diese Frage muss klar mit nein beantwortet werden. Es scheint, wenn überhaupt, nur nationale Standards zu geben, die größtenteils schon sehr betagt sind. Das technische und fachliche Handwerkszeug, was EBICS mitbringt, ist außer Frage hervorragend. Damit hat EBICS – oder besser gesagt GBICS – wirklich das Potential, zu einem weltweiten Standard aufzusteigen.

Michael Lembcke 

Die Rolle von EBICS beim Datenaustausch über SEPAmail™ zwischen Banken und Unternehmen

SEPAmail™ wurde auf Initiative französischer Großbanken (BPCE, CM-CIC, Société Générale, BNP Paribas, Crédit Agricole) konzipiert, um Unternehmen den elektronischen Austausch nicht buchungsrelevanter Zahlungsdokumente wie Rechnungen, Anweisungen, Avise usw. zu erleichtern. Mit dieser Secure-Messaging-Lösung für den Interbankenaustausch lassen sich die herkömmlichen Zahlungsvorgänge (Überweisung, Abbuchung usw.) um neue kundenorientierte Zahlungsdienste ergänzen.


Dazu gehören:
  • Begleichung elektronischer Rechnungen
  • Erhöhung der Zuverlässigkeit von IBAN-Daten und Bekämpfung von IBAN-Betrug
Alle weiteren Informationen über SEPAmail™ finden Sie unter www.sepamail.eu.
Entsprechend dem 4-Corner-Modell, auf dem die SEPAmail™-Norm basiert, gliedert sich der Austausch in zwei Typen:
  • den Austausch von Nachrichten im Interbankenverkehr (gemäß der SEPAmail™-Terminologie über „Briefe“ bzw. „Missives“): Webservice oder S/MIME
  • den Austausch von Dateien zwischen Banken und Firmenkunden
Als Kanal für den Dateiaustausch hat sich PPI France sehr früh für SEPAmail™ interessiert und seit Dezember 2012 an einem Test mitgewirkt, um die Eignung von EBICS für die Zwei-Wege-Übertragung von SEPAmail™-Daten zu bestätigen.
Der Test bestand aus folgenden Schritten:
  • einen Brief sowie einen Briefstapel mit Auftragseinreichungen über die Auftragsart FUL übertragen,
  • einen Brief sowie einen Briefstapel mit Bestätigungen über die Bearbeitung einer eingereichten Datei vom Typ pain.002 über die Auftragsart PSR abrufen
  • einen Briefstapel mit Transaktionsauszügen über die Auftragsart FDL herunterladen
Nachdem sowohl das Kundensystem als auch der Bankserver entsprechend konfiguriert waren (TRAVIC-Software), hat der erfolgreiche Datenaustauschs bestätigt, dass Banken und Kunden ihre EBICS-Systeme gleichermaßen für den Austausch über SEPAmail™ nutzen können.
Dank dieses Tests können wir einige Empfehlungen geben. Hierzu gehören insbesondere:
  • ein Dokument zur vereinfachten Benennung der Dateien
  • ein Leitfaden über die gemeinsame Umsetzung von SEPAmail™ und EBICS für Banken, Unternehmen und Dienstleister
Einige zuverlässige Dienstleister und Betreiber haben übrigens schnell erkannt, wie wichtig es ist, eine SEPAmail™-Lösung anzubieten, die den EBICS-Kanal unterstützt. Der Hersteller GFI bietet seinen Bank- und Unternehmenskunden die erste vollständig normkonforme Lösung an.
„Die Strategie unseres Angebots beruht auf drei Grundprinzipien: 

  • Einfachheit: minimale Auswirkung auf das Informationssystem unserer Kunden
  • Effizienz: beschleunigte Markteinführung
  • Kostenkontrolle: die Erstinvestitionen der Kunden möglichst gering halten, um den Aufbau eines Geschäftspartnernetzes zu erleichtern
Vor diesem Hintergrund hat sich uns die Verwendung des EBICS-Kanals förmlich aufgedrängt. Dieser Kanal gewährleistet das notwendige Maß an Schutz und Rückverfolgbarkeit beim Austausch über SEPAmail™, und das Verfahren ist unseren Kunden aus dem Datenverkehr zwischen Banken und Firmenkunden vertraut “, erklärt uns Lionel Chemla, der Angebotsleiter für SEPAmail™ bei GFI.

Und so, wie sich EBICS außer in Deutschland und Frankreich auch in Portugal, in der Schweiz, in Österreich und demnächst in weiteren europäischen Staaten verbreitet, wird in Zukunft zweifellos auch SEPAmail™ auf der Grundlage der ISO-Norm 20022 das Interesse von europäischen Unternehmen außerhalb Frankreichs wecken...

Marc Dutech 

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 3 – EBICS jetzt auch online

Ist es wirklich so, dass die Anforderungen von Firmenkunden im eBanking ausschließlich auf den dateibasierten Datenaustausch abzielen? Oder sind hier nicht auch Online-Geschäftsvorfälle gefragt? Warum sonst nutzen insbesondere kleinere Firmenkunden häufig eBanking-Lösungen aus dem Anwendungsumfeld für Privatkunden?


Das EBICS-Protokoll hat sich historisch gesehen aus dem Filetransfer heraus entwickelt und ist hervorragend für den sicheren und performanten Austausch großer Dateien zwischen Firmenkunden und Banken sowie im Interbankenverkehr geeignet. Die auszutauschenden Dateien sind je nach Geschäftsvorfall mit Auftragsarten oder Formatparametern gekennzeichnet. Diese steuern dann den jeweiligen Prozess.

Beim Einreichen von Daten über EBICS wird die Datenverbindung bei erfolgreicher Teilnehmer-Authentifizierung ausschließlich für die Dauer der Datenübertragung offen gehalten. Die eigentliche Verarbeitung erfolgt üblicherweise offline. Die Verarbeitungsergebnisse müssen anschließend über einen separaten Geschäftsvorfall heruntergeladen werden (PTK/HAC). Ebenso werden auf dem Bankrechner abzuholende Daten, zum Beispiel Umsatzinformationen, regelmäßig offline für Abholungen bereitgestellt. Diese Daten können dann als Datei über EBICS abgeholt werden.
Für die Online-Erfassung von Zahlungsverkehrsaufträgen und deren Autorisierung sowie die Online-Abfrage von Kontoinformationen ist der EBICS-Standard derzeit nicht ausgelegt. Diese Funktionen werden von proprietären Web-Portalen im Privatkundengeschäft sowie von nationalen Standards unterstützt, in Deutschland etwa HBCI/FinTS. Möchte ein Firmenkunde heute unter Berücksichtigung der verfügbaren Standards und Verfahren die Vorzüge von Online-Geschäftsvorfällen und EBICS gleichermaßen nutzen, so muss er unter Umständen unterschiedliche Lösungen mit verschiedenen Zugängen einsetzen.

Daher wäre es sinnvoll, den EBICS-Standard um die relevanten Online-Prozesse zu erweitern, zum Beispiel:
  • Auskunft über Kontensalden: Über das EBICS-Protokoll könnte eine Online-Auskunft über aktuelle Kontensalden geliefert werden. Dabei wird in EBICS die Verbindung zur Abfrage offen gehalten. Hiermit verfügt der Firmenkunde stets zeitnah über den aktuellen Kontenstand.
  • Auskunft über Status- und Verarbeitungsergebnissen zu Einreichungsaufträgen: Der Kunde benötigt einen Status des jeweils eingereichten Auftrages. In Verbindung mit einer neu einzuführenden Kundenauftragsreferenz (siehe Blogbeitrag vom 18.12.2014) macht eine Online-Einzelabfrage zum Auftragsstatus den Auswertungsprozess für den Firmenkunden erheblich einfacher und klarer. Gegebenenfalls erübrigt sich dann auch so mancher Anruf zur Statusauskunft bei der Bank.
Natürlich gäbe es noch weitere Einsatzmöglichkeiten. Wichtig ist aber, dass es hier nicht um eine Konkurrenz zu anderen Standards oder Verfahren im Privatkundensektor geht. Vielmehr sollte es das Ziel sein, den EBICS-Standard auf die eBanking-Bedürfnisse der Banken und der Firmenkunden anzupassen und so EBICS zukunftssicher weiterzuentwickeln.

Michael Lembcke 

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 2 – mit EBICS und der VEU Autorisierungen delegieren

Mit diesem Artikel setzen wir unsere im Dezember begonnene Serie über mögliche Verbesserungen in EBICS fort. Dieser Artikel widmet sich nun folgendem Problem: Wenn man heute per EBICS einen Zahlungsverkehrsauftrag einreicht, hat der Einreicher im Standardfunktionsumfang keine Möglichkeit mehr, auf die weitere Autorisierung Einfluss zu nehmen. In manchen Fällen ergibt sich aber erst mit der Einreichung, wer für die weitere Autorisierung in Frage kommt und man möchte die Autorisierung situativ delegieren.

Im aktuell spezifizierten Funktionsumfang von EBICS sind Bankrechner-seitig unterschiedliche Berechtigungsmodelle für die Einreichung und Autorisierung von Auftragsdateien durch Firmenkunden anwendbar. Diese Modelle beruhen in der Praxis stets auf den Unterschriftsklassen E, A, B und T, der Anzahl erforderlicher Unterschriften sowie der personenbezogenen Berechtigung für eine physische Datei. Darüber hinaus haben die Kreditinstitute und Softwarehersteller die Berechtigungsmodelle im Laufe der Zeit so erweitert, dass sie sich für verschiedene Einsatzszenarien eignen. Beispiele für solche Erweiterungen sind:
  • Berechtigungen bezogen auf eine Person und einen Auftrag in Kombination mit Unterschriftsklassen,  Auftragsarten (also bestimmten Geschäftsvorfällen) und Konten.
  • Verschiedene Limit-Konzepte, zum Beispiel über Beträge, Anzahl der Transaktionen, für Zeitfenster, geltend für Personen, Konten und/oder Kunden sowie nach Unterschriftsklassen gestaffelte.
  • Gruppenkonzepte in Verbindung mit Unterschriftsklassen, zum Beispiel  zur Berechtigung der Autorisierung von Personen ausschließlich verschiedener oder ausschließlich gleicher Gruppen.
  • Proprietäre Unterschriftsklassen, die eigene Wertungen für eine Autorisierung berücksichtigen.
  • Verfahren für Service-Rechenzentren (SRZ-Verfahren), in denen die Prozesse der Einreichung und Autorisierung auf Kundenebene getrennt ablaufen.
All diese Modelle sind als relativ statisch anzusehen. Das heißt, wenn ein EBICS-Kunde einen Auftrag einreicht, kann er nur bedingt beeinflussen, wie die Bank den Geschäftsvorfall abwickelt. Es gelten stets die bankseitig eingerichteten Stammdaten als Grundlage für die Berechtigungsprüfung, Formatprüfung und Autorisierung. In den Fällen, in denen eine eindeutige Herleitung der Berechtigungen im EBICS-Umfeld bankseitig möglich ist,  mag dies sinnvoll und auch gewollt sein. Allerdings können im EBICS-Prozess Einreichungs-Aufträge, die vom Sachverhalt her unterschiedliche Behandlungen erfordern, nicht in verschiedener Weise abgewickelt werden. Bei gleichförmigen SEPA-Einreichungen mit der Auftragsart CCT zugunsten eines bestimmten Kontos wären zum Beispiel stets alle für dieses Konto und diese Auftragsart im Bankrechner zur verteilten elektronischen Unterschrift (VEU) berechtigen Personen zur Autorisierung berechtigt.

Wäre es nicht sinnvoll, wenn man als Kunde bei Bedarf mit der Einreichung in EBICS bereits die Personen benennen könnte, an die man die Autorisierung delegieren möchte? Diese Personen müssen natürlich bankseitig grundsätzlich über die entsprechende Basis-Berechtigung verfügen. Der Vorteil wäre, dass die nicht benannten Personen mit der ansonsten gleichen Basis-Berechtigung den Auftrag nicht zur VEU gestellt bekommen und somit auch nicht einsehen können. Dieses Modell ist zum Beispiel für Fälle geeignet, in denen über ein bestimmtes Konto sowohl beliebige Zahlungen, als auch Gehälter oder Gagen-ähnliche Zahlungen abgewickelt werden und die Zahlungen gleichzeitig über keine besondere Kennzeichnung verfügen. Solche Kennzeichnungen sind ohnehin weitestgehend format- und länderspezifisch. Mit einer entsprechenden Erweiterung des EBICS-Standards wäre somit eine formatunabhängige Lösung umsetzbar.

Michael Lembcke