EBICS-Echtzeiteinreichung oder – wer überweist Millionen Euro mit PayPal?

Zugegeben, was die Entwicklung der FinTechs in den letzten Jahren auf den Markt gebracht haben, ist smart, schlank und vor allem schnell. Direktes Feedback auf mobilen Endgeräten unterwegs am Point-of-Sale oder auf dem Sofa beim Onlineshopping ist heute völlig normal, und moderne Shopper möchten dies auch nicht mehr missen.

Aber stellen Sie sich vor, Sie müssen große Geldmengen transferieren oder haben die Verantwortung für fremde Gelder Ihres Unternehmens. Welche Maßstäbe legen Sie hier an die Sicherheit und zuverlässige, transparente Abwicklung Ihrer Zahlungen? Volumina nicht nur in der Geldsumme, sondern auch technische Größen der Dateiverarbeitung bei Massenzahlungen, setzen andere Verfahren voraus, die lange erprobt und mit vertrauten Partnern der Banken etabliert sind. EBICS mit Batchverarbeitung großer Sammeldateien ist der europäische Bankenstandard, auf den alle Zahlungsexperten setzen, und der Schritt für Schritt von mehr europäischen Ländern verbindlich eingeführt wird. Diese etablierten EBICS-Konzepte wurden nun auf Echtzeiteinreichung und Instant-Zahlungen für eine innovative Onlineverarbeitung adaptiert.

Sicherheit schließt Schnelligkeit nicht aus
Die Kommunikation mit Ihren etablierten Banken und der sichere Transfer Ihrer Zahlungsdateien wird jetzt auch mit EBICS als Echtzeiteinreichung bereitgestellt. Basierend auf der mit der EBICS-Echtzeitspezifikation eingeführten WebSocket-Schnittstelle werden erfasste Zahlungen oder hochgeladene Zahlungsdateien mit der Auftragsart WIP (oder entsprechendem BTF mit EBICS 3.0) beim Bankserver eingereicht. Im EBICS-Client erhält der Anwender sofort eine aktive Erfolgsmeldung als Pushnachricht über die Verarbeitung der Zahlung bei der Bank als C5N-Avise. Die Standard-Protokollrückmeldungen des Statusreports pain.002 der Bank werden selbstverständlich zusätzlich bedient. All das ist möglich, wenn alle beteiligten Produkte im durchgängigen Prozess perfekt aufeinander abgestimmt und integriert sind. Auch mobile EBICS-Apps für die Zahlungsfreigabe unterwegs bilden diese Echtzeitprozesse ab.

Sicher auf der Überholspur
Erste Banken gehen mit diesem Feature in Produktion, um Ihren Kunden gewohnte Qualität und Sicherheit bei innovativer Schnelligkeit zur Verfügung zu stellen. Bis in den Buchhaltungen der Unternehmen die großen Geldtransfers vom Sofa aus „smart“ und schnell überwiesen werden, mag zwar nach etwas dauern.

Aber wer weiß, welche Gewohnheiten sich mittlerweile in manchem Homeoffice eingeschlichen haben. Das dezentrale Arbeiten hat auf jeden Fall eine neue Dimension erreicht. Die meisten Firmen bieten nun Homeoffice an, und auch Abteilungsleiter und Prokuristen arbeiten von zu Hause. Freigaben großer Zahlungen mit verteilten Unterschriften werden also genauso von dort in Echtzeit eingereicht und sofort bestätigt.

Das WebSocket-Protokoll bietet darüber hinaus die Zusatzoption, auch Benachrichtigungen von der Bank an die Nutzer der Zahlungsanwendung zu pushen. Neben den einfachen Statusrückmeldungen zu Zahlungen kommuniziert die Bank so zusätzlich in Textnachrichten mit ihren Kunden. Die Nachrichten tauchen auf Wunsch des Anwenders als FlyIn an der Oberfläche auf und werden in einem eigenen Postfach zum Nachlesen und Herunterladen gesammelt.

APIs hin oder her: Smart und schnell bei gewohnten Sicherheitsstandards Ihrer Bank – mit EBICS auch kein Problem!

Autor: Christian Veith

Weiterlesen

Gelebte Digitalisierung – Schlüsseltausch per INI-Briefverfahren

Seit der Einführung von kryptografischem Schlüssel im Onlinebanking, sowohl bei Privatkunden als auch bei Firmenkunden, ist der Prozess des Austauschs der öffentlichen Schlüssel von Bank und Nutzer immer ein langwieriger und komplizierter Prozess – zugegeben: für die Nutzer ist er besonders beschwerlich; für den Rest der Menschheit der Brief mit sieben Siegeln:

Etabliert hat sich dabei das INI-Briefverfahren. Seit mehr als 15 Jahren im Gebrauch, ist es immer wieder der Hemmschuh, der eine Nutzung z. B. von EBICS behindert. Schlüssel erzeugen, diese senden, dann den papierhaften INI-Brief drucken, unterschreiben und an die Bank übergeben, ist für viele kompliziert und langwierig. Auch die Bearbeitung in der Bank selbst, wo ein Mitarbeiter den INI-Brief erhält, dann den zugehörigen Kundenkontakt im EBICS-System aufruft und dort die Kontrollwerte der elektronischen Übertragung mit den Werten auf dem INI-Brief vergleicht oder gar eintippen muss, ist aufwendig. Natürlich muss auch noch die Unterschrift geprüft werden, die auf dem Kontoblatt oder dem Vertrag hinterlegt ist. Klingt so gar nicht nach der Digitalisierung, die heute doch unsere Geschäftsprozesse begleiten soll.

Freigabe der EBICS-Schlüssel vereinfachen
Dabei ginge alles auch sehr viel einfacher, wenn Banken den obigen Prozess von den eigenen Mitarbeitern lösen, ihn komplett digitalisieren und damit an den Nutzer selbst delegieren würden. Der erste Schritt, der umzusetzen ist, ist die zweifelsfreie Erkennung des jeweiligen Nutzers durch Austausch eines gemeinsam vereinbarten Geheimnisses (z. B. TAN) oder – wenn bereits vorhanden – eine aktivierte Onlinesession, die sicherstellt, dass der Nutzer auch die richtige Person ist. Das trifft i.d.R. auf jede angemeldete Onlinebankingsession bereits zu! Wenn wir nun annehmen, dass das Banksystem nach einer erfolgreichen Schlüsseleinreichung den Nutzer online und aktiv, z. B. per Smartphone mit SMS oder App oder über eine Onlinebanking Session erreichen kann, dann wäre es doch auch möglich, dass dieser Nutzer die Richtigkeit seiner Schlüsselübertragung selbst bestätigen kann und somit seine EBICS-Schlüssel innerhalb kürzester Zeit freigeben kann.

Nur er!
Der Nutzer darf dies selbst tun, weil das Banksystem – zum Beispiel durch die Korrektheit der abgefragten TAN – die Identität des Nutzers zur Freigabe ermittelt hat. Der Nutzer vergleicht dann nur noch die Kontrollwerte von INI-Brief und Anzeige im Banksystem und bestätigt die Korrektheit. Vielleicht muss er diese auch noch mal selbst eingeben. Also genau das, was der Mitarbeiter bei der Bank auch tut. Natürlich protokolliert das Banksystem diese Freigabe durch den Nutzer, um später den Nachweis zu haben, dass der Nutzer den Vorgang geprüft hat.

Gelebte Digitalisierung
Der Nutzer des EBICS-Protokolls kann innerhalb weniger Minuten seinen neuen Zugang nutzen. Aufwendiger Ausdruck und Übergaben an die jeweilige Bank werden nicht mehr nötig sein. Die Wartezeit von Tagen wird auf Minuten reduziert. Die Bank spart sich aufwendige und teure manuelle Inhouseprozesse der Schlüsselfreigabe. Übergebene Dokumente – der INI-Brief – müssen nicht mehr archiviert werden. Die digitale Protokollierung des neuen Verfahrens reicht aus und bedarf keiner manuellen Erfassung/Digitalisierung des INI-Briefes mehr. Die Kundenzufriedenheit und die Akzeptanz des EBICS-Verfahrens werden gestärkt, die Banken sparen sich Kosten für Mitarbeiter und manuelle Nachbearbeitung. Gelebte Digitalisierung, eine ganz klare Win-win-Situation!

Autor: Michael Schunk

Weiterlesen

Ein wichtiger Schritt in Richtung Einheit

Ab Ende 2023 erweitert sich der Nutzerkreis des Electronic Banking Internet Communication Standard (EBICS): Im November kommenden Jahres beginnt in Österreich die Migration der Zahlungsverkehrssysteme vom bisher genutzten proprietären Multi Bank Standard (MBS). Für die Unternehmen in der Alpenrepublik bedeutet die Umstellung zunächst einmal Arbeit, hat aber am Ende klare Vorteile. Denn mit EBICS existiert ein nahtloser Anschluss an den größten europäischen Zahlungsverkehrsraum rund um Deutschland und Frankreich. Außerdem lassen die Banken ihre Kunden beim Umstieg natürlich nicht allein. Zunächst allerdings müssen die Institute selbst ihre Hausaufgaben machen. Über Zeitplan, Vorteile und Vorgehensweisen sprechen in einem gemeinsamen Interview Thomas Bargehr, Produktmanager Banking Solutions and Payment Services, Hypo Vorarlberg Bank AG, und Michael Lembcke, Leading Product Manager, PPI AG.

 

1. Herr Bargehr, im Juli 2020 hat die österreichische Kreditwirtschaft ihren Beitritt zur EBICS-Gesellschaft erklärt, seitdem läuft die Einführung bei den Banken. Wie weit ist Ihr Haus, wie sieht der weitere Fahrplan aus?
   Aktuell stimmen wir in der PSA (Payment Service Austria) die Anforderungen an automatische Migrationsschnittstellen ab. Über diese sollen die Daten und Autorisierungsmethoden aus den Altprogrammen und den MBS-Stammdaten transportiert werden. Damit ist ein benutzerfreundlicher Wechsel von MBS zu EBICS möglich. Die Migration selbst soll nach dem nationalen Projektplan ab November 2023 folgen. Ab dem Zeitpunkt müssen dann auch alle Geschäftskunden auf EBICS wechseln.
   
   
2. Herr Lembcke, deutsche Banken nutzen EBICS schon geraume Zeit, von Problemen ist nichts zu hören. Welche Vorteile hat dieser Standard für die Kreditinstitute, verglichen mit MBS?
   Für Firmenkunden ist vor allem eine länderübergreifende Multibankfähigkeit wichtig. Zu viele unterschiedliche nationale Standards oder Verfahren verursachen Mehraufwand und stören die Abläufe. Eine Vereinheitlichung fördert zudem eine mögliche Prozessautomatisierung im Sinne eines Straight-Through-Processing (STP). Auf der Architekturebene ermöglicht EBICS eine innovative, zeitgemäße Auslegung von Zahlungsverkehrssystemen.
   
   
3. Herr Bargehr, die Weiterentwicklung des MBS ist eingestellt, die Unternehmenskunden müssen also irgendwann zu EBICS wechseln. Das verursacht bei Ihren Unternehmenskunden Arbeit, womit ist das zu rechtfertigen?
   Der Zahlungsverkehr und damit einhergehend die von der Kundensoftware zu unterstützenden Formate sind seit der Euro-Einführung einem ständigen Wandel unterworfen. Dass sich alle paar Jahre etwas ändert, sind die Unternehmen also schon gewohnt. Die Hersteller von Enterprise-Ressource-Planing-Software begleiten diese Entwicklungen in der Regel rechtzeitig und qualitativ sehr gut. Gleiches gilt natürlich auch für unser eigenes Haus, das sich immer als verlässlicher Partner an der Seite der Kunden versteht.
    
4.  Herr Lembcke, die PPI AG ist Marktführer von EBICS-Lösungen und hat den Standard von Anfang an begleitet. Wie läuft aus der Sicht eines Zahlungsverkehrsberaters die Einführung in Österreich?
   Bislang sind keine signifikanten Probleme erkennbar. Die Herausforderung liegt allenfalls darin, den Übergang für alle Beteiligten so reibungslos wie möglich zu gestalten. Da sind wir natürlich auch als Hersteller von EBICS-Software gefragt, Lösungen zu liefern. Natürlich gab es mit MBS in Österreich auch bisher schon einen funktionierenden eBanking-Standard. Aber zukünftig haben die Institute und Firmenkunden in Österreich einen europäischen Multibank-Standard, der auf State-of-the-Art Architekturen beruht und den Zahlungsverkehr im Land langfristig zukunftsfest macht.
   
   
5. Herr Bargehr, eine solche Migration von Datenverarbeitungsstandards ist keineswegs eine triviale Angelegenheit. Wie stellen Sie sicher, dass nichts schiefgeht und es keine Downtimes gibt?
   Wir erheben bereits weit vor Migrationsbeginn den aktuellen Status des Kunden und stellen so frühzeitig besondere Anforderungen hinsichtlich Technik und Betreuung fest. Entsprechend begleiten wir die Unternehmen dann bis zum Wechsel. Schlüssel zum Erfolg sind eine saubere Übertragung der Kundenzugänge auf den EBICS-Server, ein kurzer und zugleich handhabbarer Übergangszeitraum sowie ein qualitativ hochwertiger Kundenservice.
   
   
6. Herr Lembcke, die PPI AG hat zahlreiche Migrationsprojekte in Richtung EBICS begleitet. Welche Vorgehensweise empfehlen Sie einem Finanzinstitut?
   Hier gibt es keine One-Size-Fits-All-Lösung. Das Vorgehen hängt stark von der Strategie und der Kundenstruktur des einzelnen Instituts ab. So ist durchaus eine Big-Bang-Migration denkbar, bei der alle Kunden auf einmal umgezogen werden. Schrittweise Migrationsszenarien haben aber genauso ihre Berechtigung, auch wenn dabei natürlich ein Parallelbetrieb von EBICS und MBS notwendig wird. Wichtig ist der Austausch mit den eigenen Unternehmenskunden, deren Migrationsplanungen abgefragt werden sollten. Für Downtimes gibt es jedenfalls keine Veranlassung, eine Migration im laufenden Betrieb ist absolut machbar.
    
7. Herr Bargehr, EBICS kennt durchaus regionale Unterschiede, so hat beispielsweise Frankreich auf einige lokale Anpassungen bestanden. Gibt es auch in Österreich Abweichungen vom EBICS-Normalfall?
   Auch wenn EBICS in Österreich noch kein Standard ist, betreiben die meisten Banken aufgrund der Marktanforderungen bereits heute entsprechende Server und Clients. Dabei gehen sie aber unterschiedlich vor: Manche kaufen sich Lösungen von der Stange und betreiben diese ohne weitere Anpassungen an nationale Besonderheiten. Andere dagegen – hier zählt die Hypo Vorarlberg dazu – analysieren eben jene lokalen Anforderungen und berücksichtigen sie bei der Auslegung ihrer Kundensysteme. Für uns hat die PPI die jeweiligen Sonderfälle in die Zahlungsverkehrslösungen eingebaut. Daher sind wir seit 2017 bereits vollständig EBICS-ready.
    
8. Herr Lembcke, hat EBICS 3.0 das Potenzial, die Diskussion um die Notwendigkeit zusätzlicher, PSD2-konformer APIs zu beenden?
   Das ist letztlich eine Diskussion, bei der es kein Ergebnis im Sinne eines Entscheides geben kann. Denn genauso wie EBICS ein etablierter, von allen Instituten beherrschter Standard ist, sind APIs aufgrund ihrer Anzahl ebenfalls ein fester Bestandteil der IT-Landschaft. Beides wird noch länger nebeneinander existieren.
    
9. Herr Bargehr, welchen Weg wird die Hypo Vorarlberg Bank gehen? Bieten Sie zusätzliche Schnittstellen an oder setzen Sie erstmal voll auf EBICS?
   Kleinstkunden können wie gewohnt weiter unser Onlinebanking nutzen. Kleine und mittelständische Unternehmen sowie Großkunden werden bei uns aber künftig ausschließlich mit EBICS arbeiten. Wir nehmen die EBICS-Migration zum Anlass, nach und nach alte Zahlungsverkehrs- und Banking-Systeme abzuschalten und damit Doppelgleisigkeiten zu vermeiden.
    
10. Herr Lembcke, im europäischen Zahlungsverkehr tut sich derzeit ohnehin einiges, als Beispiele lassen sich die SWIFT-Umstellung oder Request to Pay (RTP) nennen. Wie ist EBICS hier einzuordnen?
    Der Standard erfüllt alle wichtigen Voraussetzungen, um die absehbaren Veränderungen im europäischen Zahlungsverkehr miteinander zu harmonisieren. Schon deswegen sollte alles getan werden, EBICS in weiteren Ländern offiziell einzuführen. Dabei ist auch auf eine Vereinheitlichung der Nutzungsweise zu achten, um die Akzeptanz zu erhöhen. Die Einsatzbereiche sind bereits jetzt vielfältig. SEPA Instant Payments lässt sich beispielsweise mit EBICS abwickeln, im Interbankenaustausch wird RTP unterstützt. Für die Teilnahme am Zahlungsverkehr der Zukunft ist EBICS die Eintrittskarte!

Weiterlesen

Paukenschlag zur TRAVIC-Usergroup 2022 - Payments-as-a-Service im Doppelpack

Die TRAVIC-Usergroup hat nach dreijähriger Zwangspause endlich wieder live stattgefunden. Dabei wurden Neuerungen rund um die TRAVIC-Suite und produktbezogene Workshops auf das Parkett gebracht und in einem gemeinschaftlichen Rahmen auf Bedürfnisse und Fragestellungen im Deep Dive eingegangen. Aber: Das war noch nicht alles – die mit Spannung erwarteten Guest Speaker Alexander Merkel (Deutsche Bundesbank) und Nico Frommholz (Hamburg Commercial Bank) ließen aufhorchen: Herr Merkel skizzierte den Status quo und wagte einen Blick über den Tellerrand, indem er beleuchtete, welche Erwartungen, Chancen und Risiken es bei dem Thema „Crypto Currencies / Digitaler Euro“ im Auge zu behalten gilt. Herr Frommholz, seines Zeichens Director Head of Payment Operations, hat das Schwerpunktthema Payments-as-a-Service mit dem Vortrag "SEPA ist live" eröffnet – ein Thema, das PPI AG verstärkt in den Fokus nimmt und zusätzlich zu EBICS, mit aller Kraft um- und antreibt.

Mit dem Go-live der HCOB gelingt es PPI AG, nachweislich eine bedeutungsvolle Lücke am Payments-as-a-Service-Markt zu besetzen. Aber es kommt noch besser: Die britische Internet-Direktbank Revolut setzt für ihre Expansion in den EU-Raum auf die Datenaustauschlösung TRAVIC-Interbank und auch auf das Payment-as-a-Service-Modell – cloudbasiert und von der PPI AG. Die 2015 in London gegründete Neobank Revolut zählt aktuell rund 18 Millionen Privatkunden, die die Finanz-App des Unternehmens nutzen. Im Januar 2022 startete Revolut in Deutschland und neun weiteren europäischen Ländern ihr Bankdienstleistungsangebot. Für die offensive Erschließung des EU-Marktes benötigt Revolut als Nicht-EU-Bank eine Verbindung zur European Banking Authority (EBA) sowie den technischen Anschluss an das EBA Clearing – insbesondere an das Echtzeitzahlungssystem RT1 für SEPA Instant Payments und die STEP2-Plattform für den regulären SEPA-Zahlungsverkehr. Realisiert wird dieser Anschluss durch die Datenaustauschlösung TRAVIC-Interbank sowie das Payments-as-a-Service-Modell.

Das Hamburger Beratungs- und Softwarehaus PPI AG wird so zum Rundum-Dienstleister im europäischen Zahlungsverkehrsgeschäft. Die Payments-as-a-Service-Lösung erweitert die Sparten Consulting und Softwareprodukte um ein Komplettangebot und rundet damit das Leistungsportfolio des Hamburger Unternehmens ab. Somit zählt PPI mit seinen Teams an spezialisierten Beratern und seiner TRAVIC-Suite zu den europäischen Marktführern im Zahlungsverkehr. „Wir sind nun in der Lage, Payments-as-a-Service in der gesamten Bandbreite der Zahlungsabwicklung für Banken anzubieten. Diese können dadurch ihre IT-Abteilungen entlasten, ihre Ressourcen effizient einsetzen und damit ihre Wettbewerbsfähigkeit verbessern“, befand Dr. Thorsten Völkel, Vorstandsvorsitzender der PPI AG. Ein Prachtexempel dafür, dass die TRAVIC-Suite nicht nur die zentrale Softwarelösung dafür ist, sondern vor allem die Zukunft bildet, für eine standardisierte, mehrmandantenfähige, moderne und gehostete Zahlungsverkehrsplattform für den europäischen Bankenmarkt! Mit diesen Leistungen ermöglicht die PPI AG Banken und Versicherungen den Betrieb ganzer Wertschöpfungsketten als Software-as-a-Service. Das modulare Portfolio reicht von der Bereitstellung und dem Betrieb der IT-Infrastruktur bis hin zu vielfältigen Services und begeistert nicht nur auf Grund seiner Internationalität, seiner technischen Komplexität, sondern vor allem auch auf der Compliance- und Legal-Ebene.

Anhand dieser Erfolgsmeldungen sieht man klar, was uns verbindet: die Leidenschaft für exzellente Payments-Software und -Beratungsleistung. Wir sind überglücklich, mit der Usergroup 2022 diesem Streben Ausdruck verliehen zu haben. Wie wir alle gelernt haben, ist es eine Selbstverständlichkeit gewesen, Fakten und Lösungen zu Fragestellungen in digitalen Meetings und Calls auszutauschen. Aber gerade die gegenseitige und gemeinschaftliche Inspiration, von der die Weiterentwicklung der TRAVIC-Produkte seit jeher profitiert, die durch den lebendigen, lebhaften und leibhaftigen Austausch von Angesicht zu Angesicht geprägt ist, vermissten wir. Umso größer war die Freude, an diese symbiotischen Schwingungen wieder feierlich anknüpfen zu können und zwei Tage lang die geschätzte PPI-Kundschaft mit einem prall gefüllten und abwechslungsreichen Programm zu beehren: von der Vorstellung neuer TRAVIC-Produkt-Releases, über Use Cases und jüngste Erfahrungsschätze, bis hin zu vertiefenden Diskussionen mit den Kunden im Rahmen der produktspezifischen Workshops.

Autor: Andreas Löwe

 

Weiterlesen

Prüfung von EBICS-Zertifikaten in Frankreich ohne vertrauenswürdige Drittanbieter

Elektronisches Zertifikat und Anwendungen
Das elektronische Zertifikat ist ein wesentliches Element beim Aufbau von geschützten Bereichen. Es ermöglicht seinem Inhaber, sich zu authentifizieren (Authentifizierungszertifikat), eine Unterschrift zu leisten (Signaturzertifikat), eine sichere Verbindung herzustellen, usw. Für die Funktionen zur Zugangs- und Unterschriftskontrolle verwenden die Anwendungen ein Zertifikat für die Authentifizierung des Inhabers und für die Kontrolle der Informationsintegrität. Es gibt heute zahlreiche Zertifikatsaussteller (Bankensektor, Verwaltung, Unternehmen ...).

Die Anwendungen für die Digitalisierung von Datenströmen sind vielfältig und betreffen alle Wirtschaftsbereiche. Sie setzen die Einrichtung von geschützten Bereichen voraus, in denen es möglich sein muss, die verschiedenen Akteure technisch zu identifizieren und zu authentifizieren sowie die Qualität der Transaktionen und ihrer Aussteller zu überprüfen.
 
Eine Anwendung muss in der Regel Zertifikate von verschiedenen Zertifizierungsstellen akzeptieren können, denn in einer globalen Welt wäre es zu kostspielig und gleichermaßen zu restriktiv, von einem Inhaber ein Zertifikat pro Anwendung zu verlangen.

EBICS und signierte Zertifikate
Um mit Finanzinstituten zu kommunizieren, müssen EBICS-Teilnehmer mit einem T- oder TS-Profil X.509-Zertifikate verwenden. Wenn der Teilnehmer von einer Zertifizierungsstelle (CA) signierte Zertifikate verwendet, müssen diese beim Download der Schlüssel und beispielsweise bei Aufträgen der Auftragsart FUL validiert werden. Die Auftragsarten für die Einreichung und Änderung von Zertifikaten (INI, HIA, H3K, PUB, HCA und HCS) unterstützen sowohl ein einzelnes Zertifikat, als auch Zertifikatsketten.

Validierung des CA-basierten Zertifikats
Die Validierung des CA-basierten Zertifikats kann extern oder intern (für EBICS TS) durchgeführt werden. Ab sofort ist es möglich, intern eingereichte Zertifikate in TRAVIC-Corporate zu prüfen. Dazu werden die Anmerkungen der Sperrliste mithilfe von Zertifikatssperrlisten (Certificate Revocation Lists, CRL) überprüft. Die Zertifikatssperrlisten müssen aus dem Internet heruntergeladen werden. Um die SWIFT-Zertifikatssperrlisten herunterzuladen, ist in der Regel ein Client-Zertifikat für die TLS-Kommunikation erforderlich.

Schnittstelle zur Prüfung interner Zertifikate von TRAVIC-Corporate für EBICS TS
Neben anderen Parametern umfasst die Providerschnittstelle von TRAVIC-Corporate die Prüfung von Zertifikaten, eine Caching-Strategie, die Speicherung von Non-Repudiation-Dateien und die Vorabprüfung von EU-Berechtigungen (EBICS TS) gemäß den CFONB-Spezifikationen. Der Provider kann über den Namen seiner Klasse angegeben und aktiviert werden.

Die Zertifikate werden gegen einen in TRAVIC-Corporate gespeicherten Truststore geprüft. Die gesamte Zertifikatskette wird jeweils bis zum gültigen Root-Zertifikat geprüft. Es werden keine externen Dienste zur Prüfung von Zertifikaten verwendet.

Als Komponenten von TRAVIC-Corporate steuern ein Job-Server und ein Parser diese Verarbeitung. Der Zahlungsauftrag wird freigegeben, wenn das Signaturprofil des EBICS-Teilnehmers mit dem Signaturprofil übereinstimmt, das auf der Ebene der Auftragsart des Kunden konfiguriert wurde.

Das Finanzinstitut kann sich somit vollständig auf seine TRAVIC-Corporate-Lösung verlassen, ohne auf Dritte zurückgreifen zu müssen, wodurch die Systemarchitektur vereinfacht und Kosten gesenkt werden.

Zaher Mahfouz

Quellen: PPI TRAVIC-Corporate, CFONB, X.509-Standards

Weiterlesen

ISO-Migration im AZV - ein Weckruf

Weltweit werden die Zahlungssysteme auf ISO-20022-Standard UNIFI (universal financial industry message scheme) umgestellt. Im Euroraum begann dieser Prozess mit der SEPA-Einführung 2007. Im kommenden November ist es auch im Individual- und Auslandszahlungsverkehr soweit. Die Finanzwelt verspricht sich viel von der Umstellung. In einer Umfrage von msgGillardon und Unifits haben 99 % der befragten Experten die ISO-Migration sehr oder eher positiv gesehen. Und tatsächlich bietet der neue Standard viele Vorteile, wenn er denn erst einmal möglichst flächendeckend unterstützt wird.

Das Thema ist also alles andere als neu, und doch ist der Weg dahin schwierig und die Einführung musste gleich mehrfach verschoben werden. Dabei setzt das Eurosystem der europäischen Zentralbank auf einen Big-Bang-Ansatz, während SWIFT für den weltweiten Zahlungsverkehr über das SWIFT-Netzwerk eine dreijährige Koexistenzphase von MT- und MX-Formaten vorsieht. Obwohl die Big-Bang-Umstellung wie das schwierigere Projekt wirkt, da alle Banken Europas mit TARGET2 oder EBA Euro1 Anschluss zeitgleich und ohne jede zeitliche Toleranz umstellen müssen, hat auch die Koexistenzphase von MT und MX ihre Tücken.

Die TARGET-MX-Migration ist zunächst viel mehr als nur eine Formatumstellung. So wird zeitgleich der technische Zugang auf ESMIG (Eurosystem Single Market Infrastructure Gateway) umgestellt. Es werden ein ISO-basierter Recall-Prozess sowie ein zentrales Liquiditätsmanagement (CLM) mit neuen Liquiditätskonten (MCA/DCA) eingeführt. Die EZB hat den Banken einen Testzeitraum von rund einem Jahr verordnet und überwacht den Umstieg laufend – bei nicht wenigen Banken stehen die eigenen TGT-MX-Projekte auf gelb oder rot. Der sichere Betrieb des Großbetragszahlungsverkehrs in Europa scheint bei einigen Instituten gefährdet zu sein.
 
Dieser Weckruf bezieht sich jedoch auf die Umstellung im Auslandszahlungsverkehr. Die SWIFT-Initiative CBPR+ (Cross-Border Payments and Reporting Plus) versucht durch die 3-jährige Übergangszeit einen weichen Übergang zu ermöglichen. Jede Bank soll im eigenen Tempo dem Ziel der ISO-Migration nachkommen können. In der Folge wird an vielen Stellen konvertiert anstatt den ISO Datenhaushalt end-to-end zu verarbeiten. Einige Banken senden und empfangen weiterhin MT-Nachrichten für die Zahlungen, andere bereits die ISO-Formate. Darüber hinaus ist die Migration je Nachrichtentyp sowieso zeitlich gestaffelt.

Bei genauer Betrachtung zeigt sich, dass der Übergangszeitraum sowohl für Banken, die noch nicht auf ISO umgestellt haben, als auch für Banken, die eigentlich ISO-ready sind, gewaltige Probleme erwarten lässt:

Banken, die nur MT verarbeiten können, riskieren langsamere Prozesse durch Konvertierungen, müssen zum Beispiel aus Compliancegründen in Übergangslösungen investieren, da in einigen Prozessen doch die Original-ISO-Formate abgeholt und geprüft werden müssen. Das größte Übel: der drohende Datenverlust, bei Adressen beispielsweise…

Andere Probleme kommen auf alle SWIFT-Teilnehmer zu: Die MT/MX-Übergangszeit führt zu einer Vielzahl neuer Szenarien und Use Cases wegen der möglichen Formate in Nachrichten einer Transaktion – Avis in MT, Deckung in MX, Gebührenforderung in MT, Recall in MX etc. Die Transaktionsüberwachung wird erschwert, unterschiedliches Mapping in beteiligten Banken kann zu Fehlinterpretationen führen.

Ein besonders kritisches Szenario möchte ich kurz darstellen: Eine im ISO-Format beauftragte Zahlung wird über eine längere Kette von Korrespondenzbanken, von denen eine nur MT-Format senden kann, ausgeführt. Der MT-Korrespondent empfängt die konvertierte ISO-Zahlung und ist zwar verpflichtet, das Original-ISO-Format abzuholen, kann die abgeschnittenen Daten im MT-Format jedoch nicht weitergeben. Der SWIFT Transaction Monitor enthält noch keine Golden Copy der Originalzahlung, und damit kann die Empfängerbank nun die verlorenen Daten weder aus der MT-Nachricht noch von SWIFT herauslesen oder abfragen. In diesem Szenario werden die Informationen also nicht vollständig vom Auftraggeber an den Empfänger transportiert, obwohl sowohl die Bank des Auftraggebers als auch die Bank des Empfängers bereits mit den ISO-Formaten umgehen können.

Meine Empfehlung ist daher, trotz des akuten Fachkräftemangels die verbliebene Zeit zu nutzen und die AZV-Umstellung mit all seinen vielen Szenarien (die in dieser Ausprägung wirklich neu sind) zu testen. Im Idealfall testen Sie insbesondere mit Ihren Korrespondenten gemeinsam und überprüfen, ob das Mapping von bilateral vereinbarten MT-Belegungen auch in der ISO-Welt noch zusammenpasst.
Schließlich sollten alle Banken, die als Transaktionsbanken agieren, zügig ohne Konvertierung den ISO Datenhaushalt end-to-end verarbeiten können.

Dem internationalen Zahlungsverkehr droht sonst eine dreijährige Zerreißprobe.

Thomas Riedel

Weiterlesen

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

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

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

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

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

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

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

Autor: Michael Schunk

Weiterlesen

EBICS und die Echtzeitbenachrichtigungen - Eine Bestandsaufnahme

 

Mittlerweile ist es schon mehr als zwei Jahre her, dass die Spezifikation „Echtzeitbenachrichtigungen“  auf der EBICS Webseite www.ebics.de veröffentlicht wurde. In einem Blogbeitrag vom Oktober 2019  hatte ich mich bereits dieses Themas angenommen. Doch was ist daraus eigentlich geworden? Und wie hat sich der Einsatz in der Praxis entwickelt?

Tatsächlich wurde die neue Schnittstelle für Echtzeitbenachrichtigungen von einigen Instituten in Deutschland im EBICS-Bankrechner implementiert und ist mittlerweile bei diesen produktiv im Einsatz. Natürlich macht der damit verbundene neue Funktionsumfang nur Sinn, wenn es EBICS-Clients gibt, die diese Schnittstelle nutzen. Unter Umständen wurde in von Banken betriebenen Firmenkundenportalen daher diese Schnittstelle ebenfalls clientseitig implementiert.

Wir erinnern uns. Der Mehrwert dieser neuen Schnittstelle liegt in der potenziell schnelleren Rückmeldung bei SEPA Instant Payments im EBICS-Kanal sowie generell bei der Einsparung von Hoffnungsabfragen zu Downloaddaten. Wo stehen wir damit?

Einige Kreditinstitute in Deutschland haben das Konzept umgesetzt. Jedoch nicht jedes Kreditinstitut ist heute in der Lage, diesen neuen Service anzubieten. Unter Umständen ist es bankseitig für EBICS auch nicht oder noch nicht im Fokus. Neben der neuen Schnittstelle zur Echtzeitbenachrichtigung in Richtung Kunde ist nämlich auch die zeitnahe Bereitstellung der Downloaddaten im Bankrechner eine der Voraussetzungen, um Kunden einen Mehrwert für EBICS bieten zu können. Diese kontinuierliche und zeitnahe Bereitstellung aus den Backendsystemen heraus für den EBICS-Kanal muss dafür bei den Kreditinstituten zur Verfügung stehen.

Kundenseitig ist die Push-Benachrichtigung insbesondere für Firmenkunden von Interesse, bei denen die Aktualität und die Nähe zur Echtzeit zunehmend relevant ist. Diese EBICS-Kunden haben die Echtzeitbenachrichtigung auf der Clientseite zum Teil bereits implementiert. Andere, die z. B. ein geeignetes Firmenkundenportal des Kreditinstituts nutzen, kommen ggf. auch ohne eigenes Zutun in den Genuss des neuen Services. Dennoch verfügt nicht jeder EBICS-Client über die neue Websocket-Schnittstelle zur Echtzeitbenachrichtigung.

Fazit ist, dass die Funktion der Echtzeitbenachrichtigung im Jahr 2022 noch nicht in der Breite bei den EBICS-Kunden angekommen ist. Bisher sind es gerade spezialisierte Firmenkunden und institutionelle EBICS-Kunden, die auf Echtzeitbenachrichtigung im EBICS-Kanal setzen. Für sie stellt die Echtzeit in den Zahlungsverkehrsprozessen einen besonderen Mehrwert dar, für den sich auch die eine oder andere Investition lohnt. Die Kreditinstitute dieser Kunden bieten den passenden Service an.

Wir sehen, dass generell das Thema Echtzeit im Zahlungsverkehr noch Wachstumspotenzial hat. Somit ist davon auszugehen, dass auch das Thema Echtzeitbenachrichtigung in Verbindung mit EBICS noch an Bedeutung gewinnen wird. Bleiben wir also gespannt!

Autor: Michael Lembcke

Weiterlesen

Tipps für einen reibungslosen Übergang zu EBICS 3.0

EBICS 3.0 ist seit November 2021 offiziell bei den Banken eingeführt und kann von Firmenkunden genutzt werden. Daneben ist die letzte Vorgängerversion weiterhin gültig. Eine der Änderungen in EBICS 3.0 betrifft den Wegfall der dreistelligen Auftragsarten bzw. der FileFormat-Parameter in Frankreich für operative Geschäftsvorfälle. Diese werden nun über die sogenannten Business Transaction Formats (BTF) abgebildet. BTFs umfassen jeweils acht Parameter: Service Name, Service Scope, Service Option, Service Message Name, Service Message Name Version, Service Message Name Format, Service Message Name Variant und Service Container.

Innerhalb einer Kundenvereinbarung muss unabhängig von der EBICS-Version die zentrale Vereinbarung für den jeweiligen Geschäftsvorfall berücksichtigt werden können. Die Kompatibilität und Interoperabilität zwischen den Vorgängerversionen sind für EBICS vorgegeben. Wenn zwei elektronische Unterschriften für eine SEPA-Überweisung vereinbart sind, ist es beispielsweise irrelevant, ob Einreichungen hierzu per BTF oder Auftragsart bzw. FileFormat-Parameter erfolgen. Diese Bedingung erfordert ein internes Mapping alter und neuer Geschäftsvorfälle im Bankrechner und ggf. auch in Client-Systemen. Bisher sind für die Standardgeschäftsvorfälle diese Mappings offiziell spezifiziert.

Die dem EBICS vor- und nachgelagerten Verarbeitungen bei den Kreditinstituten und bei den Firmenkunden orientieren sich i. d. R. noch an den bisherigen EBICS-IDs, wie den dreistelligen Auftragsarten und in Frankreich an den bis zu 40-stelligen FileFormat-Parametern. Solange ein Mapping existiert, besteht aber auch keine Notwendigkeit daran etwas zu ändern. Was ist jedoch, wenn für einen Geschäftsvorfall keine Auftragsarten/FileFormat-Parametern mehr spezifiziert sind und die Geschäftsvorfälle ausschließlich mit BTF gelten? Will man seine angrenzenden Verarbeitungsprozesse nicht an die BTF anpassen, kann man natürlich ein Mapping beibehalten. Für die nicht spezifizierten Mappings sollte man dann allerdings individuelle, passende IDs festlegen.

Im Außenverhältnis in der Kunde-Bank-Beziehung sollte man beachten, dass dem Kunden bzw. Client-System die Vorgaben des Bankrechners hinsichtlich Geschäftsvorfällen und Mappings auf verschiedenen Wegen mitgeteilt werden. Dabei kommen zudem die unterschiedlichen Darstellungen aus Sicht des Kunden, Teilnehmers und Zeitpunkts zum Tragen. Ein Teilnehmer nutzt immer eine konkrete EBICS-Version, während die Kundenvereinbarung alle gültigen Versionen abbilden muss. Außerdem spielt der Zeitpunkt der Information eine Rolle. So ist vor der Initialisierung des Teilnehmers dem Kreditinstitut i. d. R. nicht bekannt, welche EBICS-Version dieser nutzen wird.

Das BPD-Blatt (BPD=Bankparameterdaten), das bei der Einrichtung des Teilnehmers auf dem Bankrechner angelegt wird, muss daher die Optionen aller unterstützten EBICS-Versionen inkl. evtl. BTF-Mapping-Vorgaben abbilden. Gleiches gilt zumindest auch für die Auftragsart HKD, mit der die Vereinbarungen auf Kundenebene vom Client abgerufen werden können. Wird bei bestimmten Geschäftsvorfällen in der Kunde-Bank-Beziehung ungeachtet der internen Nutzung kein Mapping mehr angeboten, so sollte die jeweilige Information  das Mapping entsprechend ausschließlich per BTF abbilden. Für die interne Administration und Pflege ist es hilfreich, wenn bei einem internen Mapping die ausschließlich intern genutzten individuellen IDs sichtbar sind (z. B. individuelle Auftragsarten mit eigenem BTF-Mapping), aber sich von den externen IDs unterscheiden.

Zusammenfassend lässt sich sagen, dass die Herausforderung darin besteht, bei der neuen Vielfalt an Informationen den Übergang zu EBICS 3.0 für alle Beteiligten so leicht wie möglich zu machen. Mit der richtigen Konfiguration und unter Beachtung einiger Maßgaben bei der Bedienung, ist der Umstieg auf die neue EBICS-Version allerdings gar nicht so schwierig. Sollten Sie Hilfe beim Umstieg auf EBICS 3.0 benötigen oder Fragen dazu haben, sprechen Sie uns gern an.

Autor: Michael Lembcke

Weiterlesen

API - ein Türöffner für Bankanwendungen

Die Abkürzung API ist zurzeit allgegenwärtig. Die drei Buchstaben stehen für Application Programming Interface, also eine Programmierschnittstelle für Anwendungen. Mit allen APIs ist die Hoffnung verbunden, möglichst einfach und schnell über eine standardisierte Schnittstelle viele bankfachliche Anwendungsfälle umsetzen zu können. Die Zahl der dafür genutzten Anwendungsfälle wächst stetig. Eine Vielzahl von Stellen treibt diese Entwicklung voran, so dass APIs den Bankenmarkt grundlegend verändern könnten.

Die PSD2 als ein Kristallisationskeim für APIs in den letzten Jahren hat dazu geführt, dass verschiedene Initiativen in Europa eine Access-to-Account-API spezifiziert haben. Die wichtigsten dieser Initiativen sind sicherlich „The Berlin Group“, „STET“  und „PolishAPI“. Aber auch außerhalb von Europa hat die PSD2 ausgestrahlt. In der Schweiz wurde das „OpenBankingProject“ (https://www.openbankingproject.ch/en/) ins Leben gerufen, welches sich mit der SwissNextGenAPI an die API der Berlin Group anlehnt. Im Vereinigten Königreich ist die „Open Banking“-Initiative  entstanden. Alle Initiativen und deren APIs setzen auf die PSD2, und alle eint der Wunsch nach einer hohen Effizienzgewinnung.

Die Realität dämpft diese Hoffnung etwas. Natürlich gibt es die oben beschriebenen Standardisierungsinititiativen. Aber erstens gibt es nicht die eine Spezifikation, zweitens sind Banken nicht verpflichtet, sich an diese zu halten, und drittens lassen die Spezifikationen Freiraum in der Implementierung (Stichwort Implementor Options). Möchte nun ein Marktteilnehmer, ob Bank oder Drittdienstleister, die Access-To-Account-API der Banken nutzen, steht er vor einer Herausforderung. PPI hat diese Herausforderung angenommen und mit dem Produkt TRAVIC-Payment-Client-API eine Bibliothek geschaffen, die die skizzierte Heterogenität hinter einer einzigen Schnittstelle verbirgt. Durch Verwendung von TRAVIC-Payment-Client-API können während der Anbindung der Access-to-Account-Schnittstellen der Banken Risiken minimiert und die Entwicklungszeit verkürzt werden. Das Produkt ist bei der Atruvia AG produktiv im Einsatz. Mehr darüber und wie z. B. die Atruvia AG davon profitiert hat, lesen Sie hier.

Aus Sicht von PPI ist das Thema API im Kontext Payments nicht mehr wegzudenken. Punktuell durch die PSD2 angetrieben, wurden erste Schritte bankseitig gemacht. Aber es ist abzusehen, dass es nicht dabei bleiben wird. Die Berlin Group hat längst das openFinance API Framework spezifiziert, das die Anwendungsfälle der Access-to-Account Schnittstelle erweitert. Und, soweit bekannt, sind für 2022 weitere Erweiterungen an der Spezifikation geplant. Diese Mehrwertdienste, die natürlich über APIs bereitgestellt werden, werden in einem zunehmenden Umfang auf den Entwicklerportalen der großen Banken angeboten. Einige dieser APIs richten sich nicht mehr nur an Drittdienstleister, sondern auch direkt an Unternehmen. Damit wird deutlich, dass das Thema API nicht auf PSD2-relevante Use-Cases beschränkt ist, sondern sich zunehmend als eigenständiger Kanal für unterschiedliche Stakeholder etablieren wird. Folglich wird es voraussichtlich über kurz oder lang neben EBICS, FinTS und Access-to-Account weitere APIs geben. 

Nicht nur die Berlin Group ist in Sachen API unterwegs. Das European Payments Council (EPC) hat eine Arbeitsgruppe auf europäischer Ebene ins Leben gerufen, die ein Rulebook für den Zugriff auf SEPA Zahlungsverkehrskonten über APIs erarbeiten soll (https://www.europeanpaymentscouncil.eu/news-insights/news/call-candidates-sepa-payment-account-access-multi-stakeholder-group-spaa-msg), an der PPI teilnimmt. Außerdem hat das EPC in der kürzlich veröffentlichen Ankündigung zum „SEPA Request to Pay scheme rulebook 2.0“ sogar angekündigt, dass der Austausch von SRTP-Nachrichten über APIs in Zukunft verpflichtend sein wird. 

Viel Bewegung im Markt, aber eines wird dabei deutlich: Die Liste bestehender und zukünftiger Initiativen rund um APIs ist lang, und eine Reihe von Innovationen ist in diesem Umfeld denkbar. PPI hat mit dem Produkt TRAVIC-Payment-Client-API den ersten Schritt gemacht und bietet dieses insbesondere auch As-a-Service an. Darüber hinaus konzipiert PPI weitere Angebote rund um das Thema API.

Autor: Christian Wenz

Weiterlesen

Aus einer Hand!

Ein IT-Outsourcingprojekt bringt in aller Regel eine ganze Menge Experten vieler verschiedener Beteiligter an einen Tisch: Da ist einmal das auslagernde Unternehmen selbst, dann noch der Outsourcinganbieter als zukünftiger Betreiber, außerdem häufig die Entwickler der genutzten Software, dazu Migrationsexperten und nicht selten ein Beratungshaus für die Gesamtprojektleitung. Dieser Aufwand vermag an sich nicht zu verwundern, handelt es sich doch im Grundsatz um hochgradig komplexe Vorgänge, die mit einer Reihe von Interdependenzen zurechtkommen müssen und – gerade im Bereich Zahlungsverkehr – nahezu keine Fehlertoleranzen haben. Durchaus erlaubt ist da die Frage, ob es nicht gelegentlich angenehmer wäre, wenn ein einzelner Partner für mehrere Projektteile verantwortlich zeichnet. Schließlich ist es eine Binsenweisheit, dass die Friktionen zunehmen, je mehr Beteiligte koordiniert werden müssen.

Nicht zuletzt vor diesem Hintergrund haben wir uns seitens der PPI AG entschlossen, ab sofort nicht nur Beratungsleistungen und Software im Bereich Zahlungsverkehrsabwicklung anzubieten, sondern auch den Betrieb entsprechender Plattformen. Mit diesem Payments-as-a-Service-Modell (PaaS-Modell) vollziehen wir einen weiteren Schritt zum Rundum-Dienstleister im europäischen Zahlungsverkehrsgeschäft.

Was heißt das konkret? Unsere Kunden können ihre PPI-Software in der Cloud ab jetzt direkt von uns betreiben lassen. Sie bekommen damit sämtliche Leistungen aus einer Hand – die Software, aber auch alles von der Beratung bis hin zum Betrieb der Zahlungsverkehrssysteme. Unser Angebot deckt so die gesamte Bandbreite der Zahlungsabwicklung ab. Das entlastet die IT-Abteilungen unserer Kunden und versetzt die Finanzinstitute in die Lage, ihre Ressourcen effizienter zu nutzen und wettbewerbsfähiger zu werden.

Warum steigen wir in den Betrieb von Softwarelösungen ein? Die Antwort ist simpel: Weil es unseren Kunden hilft, sich in einem insgesamt engen Marktumfeld zu behaupten. Und weil wir es können: Wir sind seit mehr als 30 Jahren erfolgreich im Beratungs- und Softwaregeschäft tätig und haben die Trendwende hin zu einer verstärkten Nutzung von Cloudtechnologien richtigerweise antizipiert. Bereits vor mehr als einem Jahr sind wir daher eine Kooperation mit Broadridge Financial Solutions eingegangen, einem Spezialisten für Anlegerkommunikation und technologieorientierte Lösungen für Banken. Auch dank dieser Zusammenarbeit können wir unsere führende Technologie als PaaS anbieten.

Alles nur graue Theorie? Nein, unser Rundum-Angebot ist bereits praxiserprobt: Die Hamburg Commercial Bank (HCOB) setzt auf die PaaS-Lösung. Die Ausgangskonstellation des Projekts war klassisch. Das Institut wollte im Rahmen eines Second-Generation-Outsourcings alle Kunden auf eine zentrale Zahlungsverkehrsplattform migrieren und gleichzeitig die eigenen Geschäftsprozesse einfacher gestalten. Kernstück der neuen Architektur bei der HCOB ist unsere TRAVIC-Suite als standardisierte, multimandantenfähige, moderne und gehostete Zahlungsverkehrsplattform. Unsere Betriebsumgebung haben wir den Wünschen des Kunden entsprechend so konfiguriert, dass wir den Zahlungsverkehr der Bank End-to-End steuern und überwachen können. Die Vorteile eines solchen Outsourcingprojekts aus einem Guss haben sich ganz deutlich gezeigt, denn die Systeme für den Auslandszahlungsverkehr waren bereits nach zwölf Monaten in das neue Betriebsmodell überführt – deutlich schneller als die geplanten eineinhalb Jahre. Und – das sollte nicht in Vergessenheit geraten – dies in Zeiten der Coronapandemie.

Die bei PPI einzigartige Symbiose aus tiefgehender fachlicher Expertise und umfassendem Entwicklungs-Know-how macht derartige Leistungen möglich. Zukünftig auch Betriebsmodelle anzubieten, war vor dem Hintergrund der Outsourcingtendenzen nur folgerichtig. Und damit nicht zu viele Projektbeteiligte für Friktionen sorgen, begleiten wir unsere Projekte von der ersten Planung bis zum dauerhaften Betrieb aus einer Hand – ein vollständiges Rundum-Paket für Zahlungsverkehrsdienste.

Mehr Informationen zu unseren Payment-as-a-Service-Leistungen finden Sie hier!

Ihr
Hubertus von Poser

Weiterlesen

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

Weiterlesen

Mehr Komfort für EBICS-Kunden

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

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

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

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

Autor: Michael Schunk

Weiterlesen

EBICS 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

Weiterlesen

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

Weiterlesen

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

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

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

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

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

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

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

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

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

Autor: Michael Schunk

Weiterlesen

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 

Weiterlesen