Posts mit dem Label Products werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Products werden angezeigt. Alle Posts anzeigen

Schneller und einfacher - Automatisierungsfortschritt beim Einrichten von EBICS-Bankzugängen

Der Zahlungsverkehr mit EBICS verbreitet sich weiter in Europa. Zuletzt hat sich nun auch Österreich zum sicheren Standard für Firmenzahlungsverkehr bekannt. Doch höchste Sicherheit erfordert die Einhaltung des Standards und eine genaue Prüfung beim Einrichten der digitalen Geschäftsbeziehung. Bei der Erstinitialisierung der EBICS-Bankzugänge legen einige Schritte den Ablauf fest: Der EBICS-Client erzeugt bei der Initialisierung eines EBICS-Bankzugangs einen Teilnehmerbankschlüssel, der an den Bankrechner gesendet wird. Zusätzlich wird auf dem Postweg ein vom Teilnehmer unterschriebener Brief mit dem öffentlichen Bankschlüssel zur persönlichen Identifikation an die Bank gesendet und dort geprüft. Ist alles korrekt, gibt die Bank den eingerichteten Bankzugang frei und sendet dem Teilnehmer ein Begrüßungsschreiben, das einen recht langen Hashwert zum Abgleich enthält. Diesen Hashwert gibt der Anwender manuell in der Konfigurationsmaske des EBICS-Clients ein. 

Eine erfolgreiche Schlüsselfreigabe erfordert natürlich, dass der Hashwert fehlerfrei abgetippt wird. Der Papierbrief sichert zwar „getrennte Kanäle“ der Prozesse, wird jedoch von vielen Anwendern als sehr mühsam und zeitaufwändig empfunden. Und der finale Freischaltungsprozess durch die Bank kann einige Tage dauern, bis der Teilnehmer schließlich den EBICS-Bankzugang im EBICS-Client nutzen kann.

Kann man das nicht einfacher und schneller erledigen und den Anwender entlasten?
Banken, die webbasierte Firmenkundenanwendungen betreiben, können das Vertrauen, das ihnen entgegengebracht wird, nutzen. Sie können die ihnen bereits bekannten Hashwerte der unterschiedlichen EBICS-Banken zentral in ihrer Webanwendung speichern und damit für alle ihre Kunden nutzbar machen. Unbekannte oder falsch hinterlegte Hashwerte werden ignoriert und die Freischaltung des Teilnehmers bleibt, wie sie war. 

Die manuelle Eingabe der Hashwerte jeder EBICS-Bankverbindung durch den Anwender könnte damit entfallen. Sobald sich der Anwender an diesem Bankzugang initialisiert und von der Bank freigeschaltet ist, werden die Hashwerte der öffentlichen EBICS-Bankschlüssel automatisch abgeholt und mit den hinterlegten Werten im Hintergrund abgeglichen. Ist diese Prüfung erfolgreich, können die zugeordneten Auftragsarten des Teilnehmers automatisch per HTD abgeholt werden. Der Anwender kann nach Abholung der Auftragsarten den Bankzugang sofort nutzen. Das spart Zeit und schont die Nerven des Anwenders durch den Wegfall der Eingabe des bis zu 32 Zeichen langen Hashwerts.
All das wurde in TRAVIC-Port mit Version 4.6 der PPI AG realisiert und ist bei ersten Betreibern im Einsatz.
 

<!--[if gte mso 9]>

Seit Version 4.6 von TRAVIC-Port laufen die letzten Schritte im Initialisierungsprozess zum Hashwertabgleich bei Nutzung der Zusatzlizenz automatisiert ab.

Die Beschleunigung und Vereinfachung dieser Prozesse kommen bei den Anwendern gut an. Der initialisierte Bankzugang sichert den Firmenzahlungsverkehr nach wie vor mit allen Vorzügen des EBICS-Standards. Und für die Banken bedeutet dies einen weiteren Schritt in der Prozessbeschleunigung durch Automatisierung im Firmenzahlungsverkehr.

Autor: Christian Veith


Mehr Komfort für EBICS-Kunden

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

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

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

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

Autor: Michael Schunk

EBICS 3.0 auf der Zielgeraden

Spätestens zum 22. November dieses Jahres ist es so weit. Von diesem Tag an sind deutsche Zahlungsverkehrsdienstleister verpflichtet, ihren Firmenkunden EBICS 3.0, genau genommen EBICS 3.0.1, parallel zur bisherigen Version 2.5 anzubieten. Für die Schweiz hat die SIX ebenfalls eine Empfehlung für die Unterstützung von EBICS 3.0 ab November 2021 abgegeben, und in Frankreich kann EBICS 3.0 bereits seit Januar 2018 offiziell von Finanzdienstleistern angeboten werden.
Die Deutsche Bundesbank hat angekündigt, ab dem 22. November 2021 für eine Übergangszeit von einem Jahr vollständig auf EBICS 3.0 umzustellen. Ähnlich positioniert sich die EBA Clearing bei ihren EBICS Diensten.

Was bedeutet die EBICS-Umstellung nun für alle EBICS-Beteiligten?

Banken und Finanzdienstleister rüsten sich für November 2021. EBICS-3.0-fähige Systeme sind hier bereits in vielen Fällen im Einsatz. Eventuell ist EBICS 3.0 lediglich noch nicht für die Nutzung freigeschaltet.

Für die Übergangszeit von EBICS 2.x auf EBICS 3.0 müssen auf Seiten der Bank- und Firmenkunden die spezifizierten bzw. vereinbarten BTF- und Auftragsarten-Mappings hinterlegt sein. Diese können später einmal entfallen, wenn für neue EBICS Geschäftsvorfälle in Zukunft keine Auftragsarten bzw. FileFormat-Parameter mehr spezifiziert werden. 

Alle Parteien sollten bereits vor der Migration auf EBICS 3.0 den Crypto LifeCycle (siehe Crypto LifeCycle auf www.ebics.de) für EBICS berücksichtigen. Damit verbunden sind Mindestschlüssellängen, Schlüsselverfahren und TLS-Vorgaben, die erfüllt sein müssen. EBICS 2.3 ist durch die darin definierten Schlüsselverfahren automatisch ab dem 22. November hinfällig.
All das setzt aktuelle EBICS-Software voraus. Firmenkunden sollten sich daher frühzeitig um ein EBICS-3.0-Update ihrer EBICS-Clients kümmern, um so auf die EBICS-Umstellung der Banken reagieren zu können. Um eine aufwändige Neuinitialisierung zu vermeiden, sollten bereits vor der bankseitigen Abschaltung von Schlüsselverfahren und -längen sowie EBICS-Versionen clientseitig entsprechende EBICS- und Schlüssel-Updates abgeschlossen sein.  Die Schlüssel-Updates sind u. U. Voraussetzung für die Migration auf EBICS 3.0.

Da für EBICS 3.0 das textbasierte Kundenprotokoll (Auftragsart PTK) nicht mehr spezifiziert ist, kann es sein, dass Banken dieses für EBICS 3.0 nicht mehr anbieten. Sollte das Kundenprotokoll-Monitoring von Firmenkunden noch auf dem PTK basieren, ist für diese eine frühzeitige Umstellung auf das XML-basierte HAC zu empfehlen.

Firmenkunden können sich zudem über ein paar neue Funktionen freuen, die ihnen EBICS 3.0 jetzt bietet. Dazu zählen u.a. die technische Doppeleinreicherkontrolle, die optionale Angabe des Originaldateinamens beim Upload und das VEU-Flag (VEU= Verteilte Elektronische Unterschrift), mit dem der Firmenkunde direkt steuern kann, ob sein eingereichter Auftrag in den VEU-Prozess laufen soll oder direkt zu prüfen ist. 

So viel zu einigen relevanten Punkten, die ich für einen erfolgreichen Zieleinlauf mit auf den Weg geben möchte. Letztlich gilt es, auf die nahende EBICS-Umstellung vorbereitet zu sein und die notwendigen Vorkehrungen zu treffen.

Und wie sieht es bei Ihnen aus? Haben Sie auch schon den Zielspurt zu EBICS 3.0 eingeleitet?


Autor: Michael Lembcke

Digitalisierung des Kontolebenszyklus? Einfach mit eBAM und EBICS!

B07? B13? Auch wenn diese Werte wie Flughafen-Gates für den nächsten Flug aussehen, so ist dies hier nicht gemeint.

Vielleicht haben Sie diese Bezeichnungen bereits bei den geplanten Änderungen für die Mappingtabelle der DK von BTF auf Auftragsarten gesehen. Sie bezeichnen zwei der für 2021 neu eingeführten Geschäftsvorfälle für den Bereich „Electronic Bank Account Management“ (eBAM). In einem vergangenen Beitrag haben wir das Thema eBAM bereits allgemein betrachtet und uns für eine standardisierte Nutzung im Rahmen des DFÜ-Abkommens ausgesprochen.

eBAM bietet Nachrichten für die Kontoeröffnung, –pflege, –schließung und das Kontoberichtswesen. Der Fokus liegt hierbei auf einer existierenden Kundenbeziehung. Sonst wären noch ergänzende Herausforderungen zu berücksichtigen.

Mit eBAM verbinden sich konkrete Potenziale für die Verwaltung von Konten im Firmenkundenumfeld. Dort überwiegen aktuell manuelle Tätigkeiten, Medienbrüche und ein generell papierbasiertes Vorgehen. Kontoeröffnungen oder Vollmachtsänderungen bedeuten auf Kunden- und Bankseite großen Aufwand und dauern Tage bis Wochen bis zur vollständigen Abwicklung. Von fehlenden Standards über verschiedene Banken hinweg ganz zu schweigen.


 

Das Electronic Bank Account Management ermöglicht die Digitalisierung der Kontoverwaltung. Wie im Schaubild dargestellt, werden die papierbasierten Abläufe und Medienbrüche durch standardisierte ISO20022-XML-Formate (acmt.*) ersetzt, die über einen elektronischen Kanal zwischen Firmenkunde und Kreditinstitut ausgetauscht werden. Voraussetzung ist, dass wesentliche Bank- und Kontostammdaten, Vollmachten und andere Dokumente in entsprechenden Systemen des Firmenkunden verwaltet werden. Dokumentanhänge und Digitale Signaturen werden ebenso unterstützt, da diese in bestimmten Fällen erforderlich sein könnten.

Einen neuen Kanal braucht es nicht, da die eBAM-Nachrichten auch über EBICS übertragen werden können. Außerdem sind sie im EBICS-Kanal bereits autorisiert. Diese Abläufe sind vom Zahlungsverkehr, z. B. der Übertragung von Überweisungen und Statusreports, durchaus wohlbekannt und etabliert. Eine Übertragung über andere Kanäle ist auch denkbar.
Innerhalb des Instituts können die notwendigen Bearbeitungsprozesse durch automatisierte Unterstützung schneller und effizienter durchgeführt werden. 

Am Markt sind bei einigen wenigen Kreditinstituten eBAM-Angebote vorhanden, die mitunter jedoch auf einzelne Anwendungsfälle oder Kanäle beschränkt sind. Demgegenüber steht das deutlich wahrnehmbare Interesse der Firmenkunden, etwa den Treasury-Abteilungen großer Unternehmen, nach genau einer solchen digitalen Kontoverwaltung. Sie wünschen sich insbesondere einen besseren Überblick und eine reduzierte Bearbeitungsdauer, bei gleichzeitig bequemer Verwaltung ihrer Konten.
Zugleich ergeben sich auch große Vorteile für die Kreditinstitute. So können die Komplexität von IT und Prozessen erheblich reduziert sowie Prozesskosten gesenkt werden. 

eBAM besitzt verschiedene Berührungspunkte im Fachbereich und der IT, sodass bei einer Konzeption und Umsetzung Fragestellungen ganzheitlich zu betrachten sind. Etwa auch bei verbundenen Themen wie KYC (Know Your Customer), Elektronischen Signaturen, Regulatorik oder Prozessmangement.
Für die Umsetzung von eBAM in den IT-Systemen ist zu betrachten, welche Aufgaben im Bankrechner erfolgen sollen und welche in den nachfolgenden Systemen. Was ist bei den neuen Formaten und ihren aktuellen sowie zukünftigen Versionen zu beachten? Wie kann eine Nachrichtenvalidierung und Erzeugung von Rückmeldungen erfolgen? Wie erfolgt die Verarbeitung der eBAM-Nachrichten und Übernahme in die Stammdatensysteme?

PPI kann Kreditinstituten hierfür auf Basis der TRAVIC-Suite entsprechende Funktionalitäten offerieren, um die Einführung eines eBAM-Angebots zu vereinfachen. Das umfasst die Annahme von Nachrichten im EBICS-Bankrechner TRAVIC-Corporate ebenso wie die zentrale Verarbeitung in einer spezifischen eBAM-Komponente an der Schnittstelle zwischen TRAVIC-Corporate und den nachfolgenden Systemen. Doch auch eine Web-gestützte Kontenverwaltung im Firmenkundenportal TRAVIC-Port bietet Potenzial für das eigene eBAM-Offering. Und per Echtzeitbenachrichtigung könnte über den TRAVIC-Push-Server sofort über wichtige Ereignisse informiert werden.
Durch die technische und fachliche Expertise aus einer Hand kann PPI bei Bedarf die eBAM-Einführung ganzheitlich begleiten.

Ich bin überzeugt, dass die Bedeutung von eBAM immer weiter zunehmen wird. Diejenigen Institute, die hier frühzeitig agieren, werden sich rechtzeitig Marktvorteile durch innovative Angebote sichern können.

Was meinen Sie?

Autor: Dr.-Ing. Thomas Stuht

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

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

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

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

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

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

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

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

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

Autor: Michael Schunk

Kartenzahlungen: Besonderheiten des französischen Marktes

Das Ökosystem des elektronischen Zahlungsverkehrs in Frankreich besteht aus einer Vielzahl von Akteuren (Banken, Karteninhaber, Händler, Labore, Hersteller, Kartenherausgeber, Prozessoren, Kartennetzwerke, Regulierungsbehörden) mit einem spezifischen Zahlungssystem, das auf der EMV-Technologie (Standard Europay Mastercard Visa) basiert. Das von den Mitgliedern unterzeichnete multilaterale Kooperationsabkommen ermöglicht Nutzern den Zugang zu allen freigegebenen Einrichtungen (POS-Terminals, Geldautomaten usw.) der Mitglieder des Zahlungssystems.

In Frankreich werden Bankkartenzahlungen über die Kartennetzwerke CB, Visa oder Mastercard an die Autorisierungssysteme übertragen. Das Clearing erfolgt über das CORE-Clearingsystem der französischen STET-Initiative und das Settlement über den Abrechnungsdienst der Banque de France / Europäischen Zentralbank / Bank für Internationalen Zahlungsausgleich. Einige Vorgänge können über das inländische CB-Netzwerk (wenn der französische Karteninhaber Transaktionen in Frankreich durchführt) oder über die internationalen Netzwerke von Visa oder Mastercard (für internationale Zahlungen oder für französische Bankkarten, die nicht über CB laufen) durchgeführt werden.

 

In Frankreich wird zwischen sofortigen Debitkarten und Kreditkarten (mit verzögerter Abbuchung) unterschieden. Bei einigen Karten wird eine systematische Autorisierung (online) durchgeführt, andere werden offline autorisiert. Eine französische Bankkarte mit Visa- oder Mastercard-Co-Branding wird auf der ganzen Welt akzeptiert. Ausländische Bankkarten mit Visa- oder Mastercard-Co-Branding werden auch in Frankreich aufgrund des Interoperabilitätsprinzips oder einer Vereinbarung zwischen den Banken akzeptiert. Wenn ein französischer Kunde jedoch vor dem 9. Juni 2016 mit seiner CB-Bankkarte bezahlte, die von Visa oder Mastercard unterstützt wird, wählte das POS-Terminal automatisch das Inlandsnetzwerk (CB) aus. Aber seitdem hat der Karteninhaber die Möglichkeit, zwischen CB, Visa und Mastercard zu wählen (EU-Verordnung 2015/751).


Die Probleme im Zusammenhang mit Bankkartenzahlungen äußern sich in mehreren Herausforderungen (strukturell, organisatorisch, technologisch und regulatorisch (1) ), mit denen die Akteure konfrontiert sind und die sie zwingen, ihre Organisationsstrukturen und Betriebsketten so zu überarbeiten, dass diese den europäischen Anforderungen gerecht werden. Diese Herausforderungen haben dazu geführt, dass sich der Anwendungsbereich von E-Banking ausgeweitet hat und neue Formen von Bankgeschäften entstanden sind. Mit der Bankkarte können nun mehrere Arten von Transaktionen mit unterschiedlichen Sicherheitsstufen durchgeführt werden: mobiles Bezahlen (NFC/QR-Code), kontaktlos, biometrisch (Gesichtserkennung/Fingerabdruck) usw.

Im Jahr 2019 wurden 54 Millionen Debitkarten und 39,3 Millionen Kredit- und Zahlungskarten ausgegeben, wovon CB-Karten 27,5 Millionen bzw. 70 % ausmachten (France Cards & Payments: Opportunities and Risks to 2024, S. 33; 52; 60). Nach Angaben derselben Quelle sind 77 % der auf dem französischen Markt im Umlauf befindlichen Karten Co-Branding-Karten und nur 23 % sind Karten eines rein internationalen Netzwerks. Auf die fünf größten Banken entfallen 86 % des Gesamtwerts der Transaktionen im Jahr 2019 (France Cards & Payments: Opportunities and Risks to 2024). Im Jahr 2018 gab es in Frankreich mehr als 1,8 Millionen POS-Terminals und fast 55 Tausend Geldautomaten (Statista, 2021).

Obwohl Kartenzahlungen nach wie vor die am häufigsten verwendete Zahlungsmethode in Frankreich (2) sind und in den kommenden Jahren weiter zunehmen werden, haben mit der PSD2 zusammenhängende Vorschriften eine technologische und strategische Revolution ins Rollen gebracht, die es den verschiedenen Akteuren (Neueinsteigern, Banken usw.) ermöglicht, sich von den Interbankennetzwerken zu befreien und innovative Dienste zu geringeren Kosten anzubieten. Vielmehr werden sie sich auf die Internet-Infrastruktur und nicht auf private Strukturen verlassen. Basierend auf den neuen Geschäftsmodellen entwickeln sich neue Dienste (mobile kontaktlose Zahlungen, P2P (Peer-to-Peer), usw.), die neue Anwendungsfälle mit einer neuen Benutzererfahrung bedienen (Payments Cards and Mobile, 2021). Das auf ISO-20022 basierende Verfahren Request to Pay (RTP) ergänzt diese Zahlungsmethoden als leistungsstarkes End-to-End-Zahlungstool, das neue Services bietet und Mehrwert für Kunden schafft.

Die Verbreitung mehrerer Zahlungskanäle und die zunehmende Dematerialisierung des Zahlungsverkehrs könnten neue Möglichkeiten für das Acquiring mit verstärktem Wettbewerb auf der Acquirer-Seite eröffnen, was zweifellos zu niedrigeren Gebühren und besserem Service führen wird. All dies wird eng mit der Kombinierbarkeit der Lösungen verknüpft sein, denn es liegt im Interesse des Händlers, so viele Zahlungsmethoden wie möglich auf demselben Gerät zu den geringsten Kosten verfügbar zu machen, um so die Chance zu erhöhen, dem Kunden seine bevorzugte Zahlungslösung anbieten zu können.

(1) Starke Authentifizierung (PSD2-Richtlinie, 2018); Kartenzahlungen (PCI DSS); Interbankenentgelte (EU-Verordnung 2015/751).

(2) Im Jahr 2019 bevorzugte mehr als die Hälfte der französischen Bevölkerung, nämlich 58,6 %, die Zahlung per Bankkarte. (Statista, 2021)

 

Autor: Tite-Voltaire Soupene 




Unterbrechungsfreier Zahlungsverkehr – wer wünscht sich das nicht?

Es gibt Softwaresysteme, die so kritisch sind, dass höchste Ansprüche an die Verfügbarkeit erforderlich sind. Zugegeben: Im Finanzbereich geht es normalerweise nicht gleich um Leben oder Tod. Aber bei Echtzeitbezahlverfahren oder Echtzeit-Autorisierungsprozessen werden immer höhere Anforderungen definiert und insbesondere Wartungsfenster nicht länger akzeptiert. Und dies zu Recht: Führt ein Wartungsfenster dazu, dass man den Kontoauszug eine Stunde später bekommt oder das Portal eine Stunde nicht erreichbar ist, mag das ärgerlich, aber zu verschmerzen sein. Kann der Bankkunde hingegen am Point of Sale plötzlich nicht mehr bezahlen oder seine Zahlung nicht in Echtzeit autorisieren, gewinnt der Ausfall eine dramatische Relevanz.

Daher ist mit Einführung von Instant Payments in Europa nach dem Autorisierungsprozess für Kartenzahlungen auch die Echtzeitüberweisung zu einem Einsatzbereich unterbrechungsfreier Systeme geworden.

Kommen wir zunächst zum Begriff der Unterbrechungsfreiheit. Ein unterbrechungsfreier Betrieb wird durch zwei verschiedene Eigenschaften beschrieben:

  1. Vermeidung geplanter Nichtverfügbarkeit
    Das System ist im Normalbetrieb permanent funktionsbereit. Es hat also keine periodischen Zeiten eingeschränkter Funktionalität, wie bei Tagesende oder Reorganisation.
    Das System ist so konstruiert, dass auch Releasewechsel während des Betriebs durchgeführt werden können und keine Downtime verursachen.
     
  2. Reduzierung der ungeplanten Nichtverfügbarkeit
    Das System ist auch bei Fehlerszenarien hoch verfügbar. Es gewährleistet also mit hoher Wahrscheinlichkeit den Betrieb trotz Ausfalls einzelner Komponenten. Diese Ausfallwahrscheinlichkeit wird berechnet oder gemessen als das Verhältnis der Produktionszeit zur Laufzeit, also der Zeit inklusive der Ausfallzeit, beispielsweise 99,99 Prozent. Insbesondere die Robustheit in Überlastszenarien ist hier von Interesse. Obwohl jedes System seine Grenzen hat, ist es eben ein Unterschied, ob jenseits der Belastungsgrenze alles zusammenbricht oder nur die zusätzliche Last nicht im Rahmen der Vorgaben abgearbeitet werden kann.

Die Begeisterung für das Thema lässt meistens beim Betrachten der Kosten erheblich nach. Es lohnt daher, architektonische Antworten zu finden und nicht alles nur auf die Infrastruktur zu verlagern. Dennoch wird auch die beste Software nur dann laufen können, wenn die Systemumgebung verfügbar ist. Ich möchte hier nicht näher auf hochverfügbare Infrastruktur, Betriebssysteme, Datenbanksysteme und Message Broker eingehen – all dies ist Grundvoraussetzung für ein unterbrechungsfreies Gesamtsystem. Ich möchte den Fokus auf die Softwarearchitektur legen. Diese kann es ermöglichen, Verfügbarkeitsanforderungen gezielt umzusetzen und dabei die Kosten im Griff zu behalten. 

Da Hochverfügbarkeit teuer ist, müssen zuallererst die kritischen Prozesse identifiziert werden. Es gilt also, die Frage zu beantworten, welche Prozesse wirklich immer funktionieren müssen und welche durchaus auch nachgeholt werden können. Im Echtzeitzahlungsverkehr sind beispielsweise die Sammlerprozesse weniger kritisch als die Einzelzahlungen.

Falls große Komponenten unter die kritischen Prozesse fallen, sollte analysiert werden, ob diese überbrückt werden können. Kann also eine alternative Komponente die kritischen Aufgaben einer großen nicht hochverfügbaren Komponente für die Zeit des Ausfalls ersetzen? Im Zahlungsverkehr kann etwa das Buchungssystem ein derartiges großes, nicht hochverfügbares System sein und die Onlinedisposition der kritische Prozess, den es zu überbrücken gilt.

Zahlungsverkehr als Ganzes ist selbstredend kein zustandsloser Prozess: Geld kann leider immer nur einmal ausgegeben werden, der Kontostand ist also ein relevanter Zustand und eine Bankensoftware muss dies natürlich genau abbilden können. Das führt in unserem Fall immer zum Einsatz von Datenbanken und zum Bedarf einer Persistenz vor und nach jeder relevanten Zustandsänderung. Gerade das Design des Datenbankmodells gibt den Ausschlag darüber, ob wir unser Ziel erreichen oder nicht. Hochverfügbare Prozesse sollen mit stabilen bzw. migrationsfreien Datenstrukturen arbeiten. Nur so kann vermieden werden, dass kritische Prozesse für eine Änderung des Datenbankschemas heruntergefahren werden müssen.

Bleibt das Thema Robustheit. In der Wissenschaft spricht man auch von Resilienz, wenn beschrieben wird, dass Störungen oder Teilausfälle von technischen Systemen nicht dazu führen, dass diese vollständig versagen. Im Zahlungsverkehr können solche Störungen Lastspitzen oberhalb vereinbarter Grenzen sein oder Umsysteme, die nicht so schnell antworten wie vereinbart. Auch Ausfälle bei Geschäftspartnern und damit ausfallende Quittungen in größerer Menge können Ausfälle verursachen. Wir haben in der reaktiven Programmierung ein Paradigma gefunden, das die gewünschte Robustheit durch die Orientierung an Datenflüssen ermöglicht. Eine Überlast kann so auf betroffene Bereiche gekapselt werden und dem störungsfreien Betrieb der restlichen Daten – in unserem Falle Zahlungen – steht nichts im Wege.


Autor: Thomas Riedel

EBICS als SaaS – EBICS in der Cloud

Ob bei Banken, Firmenkunden, Zahlungsdienstleistern oder Internetdienstanbietern: In all diesen Bereichen kommt heute in Europa EBICS zum Einsatz. Warum ist das so? Zum einen ist EBICS auf die im Firmenkundengeschäft üblichen Massenzahlungen ausgerichtet, zum anderen ist EBICS als eBanking-Standard in Europa etabliert. 

 

Ich benötige EBICS-Connectivity – muss ich EBICS selbst betreiben? 

All die EBICS-Markteilnehmer haben eines gemeinsam: Ihr Kerngeschäft liegt i.d.R. eben nicht primär im Betrieb und in der Abwicklung der EBICS-Kommunikation, sondern z. B. im Angebot und Verkauf der Bankprodukte, den Zahlungsverkehrsdienstleistungen und dem Internetgeschäft. Die Kommunikation muss funktionieren, und dabei will man sich auf einen Standard verlassen, um nicht mit jedem Partner eigene Verbindungslösungen aufbauen und unterhalten zu müssen.  
Damit man sich voll auf das Kerngeschäft konzentrieren kann, könnte es interessant sein, über das Konzept „Software as a Service“ für alle Leistungen rund um EBICS nachzudenken. So gibt es auch verschiedene Ansätze, EBICS-Services in der Cloud betreiben zu lassen. Servicenehmer könnten unter Umständen einiges an Kosten einsparen und so von einer höheren Flexibilität profitieren, da sich eine EBICS-Lösung schneller einführen lässt und zudem leichter erweitert oder reduziert werden kann.   
Gerade Banken mit einer kleineren Anzahl von potenziellen EBICS-Kunden scheuen die hohen Initialkosten, um einen EBICS-Bankrechner zu installieren und selbst zu betreiben. Lohnt sich dieser Aufwand und dessen Kosten für die anfänglich wenigen, vielleicht 50 – 100 Firmenkunden?

EBICS in der Cloud

Warum also den Service selbst betreiben? Weshalb nicht einen Dienstleister beauftragen, der das EBICS-Geschäft schon von Anfang an begleitet und damit in all seinen Facetten beherrscht?
Einen kompletten EBICS-Bankrechner als Service günstig einkaufen, das wäre es doch. Am besten dazu dann gleich auch das Web-basierte Firmenkundenportal, damit die Kunden schnell und ohne viel Aufwand in den Genuss des neuen Service kommen. Sowohl die Banken als auch die Firmenkunden können diese Services dann nutzen.

EBICS ist kein Service, bei dem es nur um einen entscheidenden Vorteil im Wettbewerb mit anderen Banken geht. Ein Angebot von EBICS und den entsprechenden Services des Zahlungsverkehrs gehört zum „Must-have“ einer Bank. Also warum sich nicht mit anderen die Initialkosten teilen und einen günstigeren Service in der Cloud nutzen?

EBICS in der Cloud: Vielleicht eine lohnende Handlungsoption. Oder?

Autor: Michael Lembcke

Request to Pay – kein Problem dank EBICS

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

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

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

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

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

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

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

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

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

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

Autor: Michael Schunk

Neue Datenformate und die Notwendigkeit eines EBICS-Updates für die Schweiz – Was ist zu beachten?

Neue Datenformate und die Notwendigkeit eines EBICS-Updates für die Schweiz – Was ist zu beachten?
Mit der SIX-Publikation Swiss Market Practice Guidelines EBICS für EBICS V3.0 vom Juni 2020, die die Empfehlungen für die Umsetzung des EBICS-Standards für den Finanzplatz Schweiz enthält, zieht nun auch die Schweiz nach und passt den Standard an das europäisch harmonisierte Protokoll an. Haupttreiber der Harmonisierung waren die Mitglieder der EBICS-Gesellschaft, namentlich die Finanzplätze Deutschland, Frankreich und die Schweiz (neuestes Mitglied ist Österreich).

Per Definition werden auch in der Schweiz jeweils zwei Versionen von EBICS unterstützt, d. h. in Zukunft die Version 2.5 und die Version 3.0. Somit könnte man auf den ersten Blick meinen, dass seitens der Kunden und Softwarehersteller kein akuter Handlungsbedarf besteht, da die bisherige Version ja noch angeboten wird. Gäbe es in der Schweiz da nicht diesen Absatz 2.2.1 EBICS Timeline im SIX-Dokument mit folgendem Hinweis: „Für die Unterstützung der ISO 20022 Schema-Migration auf die Version 2019 ist die Verwendung von EBICS 3.0 erforderlich.“

Wie gut informierte Fachleute wissen, soll die ISO-Version 2019 ab 2022 auch in der Kunde-Bank-Schnittstelle eingeführt werden. Per 2024 sollen dann die aktuellen Versionen nicht mehr unterstützt werden. Dies entspricht dem Trend der globalen Migration auf diese neue Version, z. B. in den Vorhaben SEPA-, SWIFT MX- oder der TARGET2-Migration. Nicht zuletzt auch vor dem Hintergrund der geplanten Einführung von Instant Payments in der Schweiz per 2023 ist diese Migration von grosser Wichtigkeit.

Der Finanzplatz Schweiz hat sich also entschieden, den Upgrade der EBICS-Version mit dem Upgrade der ISO-Version zu verknüpfen. Für Kunden und Softwarehersteller ergeben sich vor diesem Hintergrund ein paar Fragen und auch nicht zu unterschätzende Herausforderungen. Die wichtigsten Punkte werden in den nachfolgenden Absätzen beleuchtet, und es werden – wo immer möglich – auch gleich Lösungsansätze aufgezeigt.

EBICS 3.0 spätestens ab November 2021 auch in der Schweiz 

Die EBICS-Kommunikation hat sich in der Schweiz mittlerweile voll etabliert und ist aus dem Finanzsektor nicht mehr wegzudenken. Bisher wird die EBICS-Version 2.5 von der Mehrheit der Finanzinstitute in der Schweiz angeboten.

Wie bereits eingangs erwähnt, wird mit den Empfehlungen für die Umsetzung des EBICS-Standards für den Finanzplatz Schweiz (Version 1.0 vom 01.06.2020 der SIX, www.six-group.com) die neuere EBICS-Version 3.0 in der Schweiz ab November 2021 offiziell für das Firmenkundengeschäft mit Finanzinstituten eingeführt.

Festlegungen der Schweiz für den Umgang mit den neuen Geschäftsvorfällen in EBICS

Mit der Einführung der neuen Version V3.0 soll die Vorgängerversion EBICS 2.5 dann noch bis Ende 2024 offiziell von Finanzinstituten unterstützt werden. Zudem wird für die Entgegennahme der neuen Schweizer ISO20022-Formate in der Version 2019 EBICS 3.0 vorausgesetzt. Dies bedeutet für Firmenkunden, dass jeder, der seine Schweizer ISO-Formate einmal aktualisiert hat, nicht mehr ohne Weiteres noch EBICS 2.5 dafür nutzen kann.

Es ist an der Zeit, zu planen

Diese anstehenden Aktualisierungen erfordern es, rechtzeitig eine Anpassung der Softwarelösungen einzuplanen und vorzunehmen. Hier sind die Finanzinstitute, Firmenkunden und Softwarehersteller gefragt.

Die Aktualisierung der ISO20022-Datenformate auf die Version 2019 ist da nur eine Sache. Nicht zu unterschätzen sind jedoch die Änderungen des EBICS-Protokolls, die mit der Version 3.0 umzusetzen sind. Die wichtigsten Anforderungen sind:

  • Das neue Business Transaction Format (BTF) löst die bisherigen Auftragsarten und Fileformat-Parameter ab.
  • Der Transport der öffentlichen Schlüssel erfolgt einheitlich jetzt mit Zertifikaten.
  • Die kryptografischen Verfahren sind verbessert.
  • Der Umgang mit Bankschlüsseln ist verbessert.
  • Es gibt zusätzliche Steuerungsparameter zur elektronischen Unterschrift.
  • Eine Prüfung auf Doppeleinreichung findet auf Dateiebene statt.

Wie also mit diesen neuen Anforderungen umgehen?

Nicht nur die Banken, auch die Softwarehersteller von EBICS-Clients, haben die Aufgabe, ihre Softwarelösungen um EBICS 3.0 zu erweitern, so dass die Firmenkunden frühzeitig Updates durchführen und produktiv setzen können.

Es müssen alle Besonderheiten von EBICS 3.0 im Client berücksichtigt sein, und u. U. muss ein Mischbetrieb von unterschiedlichen EBICS-Versionen je nach Bankzugang und EBICS-Usern möglich sein. Zudem sollten dem Anwender unterstützende Migrationsoptionen für die EBICS-Umstellung angeboten werden, die nach Möglichkeit eine erneute Initialisierung vermeiden (Stichwort Erhöhung von Minimal-Schlüssellängen).

Die EBICS-API – Entkopplung von Fachlichkeit und Technik

Aus eigener Erfahrung wissen wir, dass die Migration auf die Version 3.0 nicht einfach ein Mapping von Auftragsarten zu BTF-Kombinationen darstellt. Es gibt viele weitere Knackpunkte zu lösen, respektive neu zu programmieren. Insbesondere, wenn die Bank, der Softwarehersteller und der Kunde diese Migration möglichst automatisiert durchführen möchten. PPI bietet schon seit Jahren den TRAVIC-EBICS-Kernel, eine API-Lösung für die Integration in eigene EBICS-Clients, an. Dieser ist in Europa bei fast jeder zweiten EBICS-Client-Software der zentrale Baustein für die Abwicklung der EBICS-Kommunikation.

Mit der aktuellsten Version sind natürlich auch die neuen Spezifika rund um EBICS 3.0 bereits implementiert. Richtig angebunden, wickelt die API das eBanking für den Client transparent in all seinen Ausprägungen und Versionen ab. TRAVIC-EBICS-Kernel entlastet somit den Softwarehersteller von eBanking- und Zahlungsverkehrsanwendungen bei der Implementierung des Standardprotokolls und deren Syntax sowie bei Sicherheitsverfahren. Diese Lösung bildet die EBICS-Spezifikation vollständig ab und bietet eine einfach zu integrierende Schnittstelle, die Softwarehersteller als komfortablen und schnell nutzbaren Kommunikationsbaustein in ihre Softwareprodukte einbinden können.

Betrachtet man das Aufwand-/Ertragsverhältnis bei der Integration des TRAVIC-EBICS-Kernels, ist es nicht verwunderlich, dass dieses Produkt so ein Bestseller ist. Softwarehersteller, welche nicht den Kernel einsetzen, können sich jederzeit mit uns in Verbindung setzen und den Erhalt einer Testlizenz anfragen. Der Zeitpunkt dazu war noch nie so gut wie vor der bevorstehenden Umstellung auf EBICS 3.0.

Autoren: Carsten Miehling und Michael Lembcke

Mehr Informationen:
Webseite: EBICS 3.0 | challenge accepted

Flyer: EBICS 3.0 – Was ändert sich?

EBICS einrichten – einfach Schritt für Schritt

Als Standard bietet EBICS maximale Sicherheit für den reibungslosen europäischen Zahlungsverkehr. Dafür muss jedoch auch von allen Beteiligten etwas getan werden. Das Initialisieren und Einrichten von Bankzugängen, Teilnehmern und Rechten ist notwendig und erfordert aufmerksame Konfigurationsschritte. Das hohe Potenzial des Multibankings benötigt wiederholte Schritte, die normalerweise an den unterschiedlichen Stellen verteilt und dezentral ausgeführt werden. Komplexe, vernetzte Anwendungen auf lineare, einfache Abfolgen für den Nichttechniker zu reduzieren ist dabei die Kunst der Konzeption nutzerorientierter Software.
Dass sich dies auch komfortabel, einfach und schnell durchführen lässt, beweist der kompakte Einrichtungsassistent, den PPI für sein Firmenkundenportal TRAVIC-Port entwickelt hat. Die Zielgruppe ist hier der Administrator auf Kundenseite - denn Self-Service ist Trumpf in modernen Kunde-Bank-Beziehungen. Den direkten Zugriff auf essenzielle Administrationsvorgänge zu erlauben, schafft schnelle Prozesse ohne Umwege über den Anbieter.

Zugegeben: Wer einen neuen EBICS-Benutzer anlegen möchte, muss ziemlich häufig klicken, aber eben Schritt für Schritt zielgerichtet geführt. Das gilt auch für die PPI-Produktwelt, namentlich TRAVIC-Port. Das System benötigt von jedem einzelnen Benutzer eine Kennung, die Stammdaten sowie das Startpasswort und ein für die spätere Anmeldung verwendetes Sicherheitsmedium. Jeder Benutzer nimmt zudem verschiedene Rollen ein, verfügt über unterschiedliche Berechtigungen und häufig mehr als eine Bankverbindung. Da TRAVIC-Port multibankenfähig ist, müssen auch die jeweiligen Bankzugänge angelegt werden. Häufig übernimmt auch die Hauptbank für ihre EBICS-Firmenkunden diese Aufgabe – und das bedeutet meist lange Telefonate, in denen der Bankmitarbeiter all diese Informationen abfragt.

Der Anwender des Portals findet einen neuen Eintrag direkt auf der Startseite (vgl. Abb. 1) Über diesen Link springt er direkt in den Einrichtungsassistenten und macht sich den Einstieg in die sichere EBICS-Welt deutlich einfacher. Über Dialoge fragt ein Assistent alle nötigen Daten ab, um einen neuen EBICS-Benutzer anzulegen.




Der Assistent sorgt auch dafür, dass die Daten jeweils an den richtigen Stellen eingetragen werden. Das ist deshalb besonders komfortabel, weil das System etwa die Abholautomaten über einen anderen Menüpunkt einrichtet als Bankzugänge und Benutzer. Was logisch Sinn ergibt, erfordert jedoch das Wechseln in vielen Reitern und Menüpunkten und damit insgesamt mehr Zeit. Dialoge im Einrichtungsassistenten verhindern, dass wichtige Daten fehlen und ermöglichen so, auch auf einen Blick zu erkennen, welche Informationen überhaupt erforderlich sind. Zuerst gilt es beispielsweise, einen neuen Bankzugang einzurichten – ob das die Bank oder ein Administrator auf Kundenseite macht, ist übrigens egal. Der Dialog fragt alle zugehörigen Informationen ab und zeigt an, wie viel Arbeit noch vor einem liegt. Bei einem neuen Bankzugang kommen immerhin sieben Dialoge zusammen (vgl. Abb. 2).

Sind alle Bankzugänge eingerichtet, folgen üblicherweise die einzelnen Benutzer. Eine kleine Kanzlei möchte etwa für die Inhaberin, zwei angestellte Anwälte und eine Assistentin Kontoberechtigungen einrichten – und zwar individuell verschiedene. Die Chefin möchte natürlich über alle Rechte verfügen, Transaktionen ohne Limit beauftragen und freigeben können und etwa über eine verteilte elektronische Unterschrift für ihre Kollegen Freigaben erteilen. Die beiden angestellten Anwälte dürfen dagegen nur Transaktionen bis zu einer gewissen Höhe alleine freigeben – und die Assistentin darf zwar Zahlungen erfassen, aber nicht freigeben. Alle vier wiederum sollen die Kontoauszüge sehen können, die vom EBICS-Bankrechner abgeholt werden. All das erleichtert ein Dialog, der neue Kollegen für einen bereits erstellten Firmenkunden anlegen kann (vgl. Abb. 3).



Der Start und das Arbeiten mit EBICS im Zahlungsverkehr lässt sich also sehr gut vereinfachen, ohne auf Sicherheit und die Einhaltung von Standards zu verzichten. Der Einrichtungsassistent ist in der Praxis erprobt und bei namhaften Großkunden im Einsatz. Wenn Sie mehr über dieses Feature in TRAVIC-Port wissen möchten, sprechen Sie uns gern an. Wir machen EBICS gemeinsam einfacher.

Autor: Christian Veith