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

Der digitale Euro und die Alternative zum Bargeld

Die Europäische Zentralbank (EZB) beobachtet nicht erst seit der Covid-19-Pandemie, dass Verbraucherinnen und Verbraucher im Euroraum seltener Bargeld nutzen. Der Einsatz von Zahlungsmethoden hat sich bereits durch den zunehmenden E-Commerce, digitale Zahlungsmethoden und Homebanking verändert.

Das dennoch innige Verhältnis vieler Europäer zum Bargeld wird getrieben durch die Begleichung kleinerer Beträge: Ob das Bezahlen im Restaurant, den wöchentlichen Einkauf auf dem Wochenmarkt oder die Euro-Münze für die Nutzung des Einkaufswagens – das Bargeld ist nicht komplett wegzudenken.

Darüber hinaus bietet das Bargeld weitere Vorteile für Bürger:

  • Zahlungen bleiben anonym, und es gibt kaum datenschutzrechtliche Bedenken.
  • Es ist sicher – beispielsweise vor einer Bankeninsolvenz.
  • Es wird nicht durch den Staat versteuert oder durch negative Zinsen belastet.
  • Bargeld ist in der Akzeptanz weit verbreitet und kann leicht transportiert werden.


Neben Bargeld haben Verbraucher die Möglichkeit, digital zu bezahlen – etwa mit dem Smartphone am Point of Sale, ihrer Kredit- oder Debitkarte oder Onlinezahlungsmethoden im E-Commerce. Diese Zahlungen werden jedoch überwiegend mit Geschäftsbankengeld, also Geld, welches durch Banken herausgegeben wird, durchgeführt. Eine digitale Alternative des Bargelds, das durch die EZB vergeben wird, gibt es derzeit nicht.

Die wichtigen Aspekte des Bargelds und die Differenzierung zu digitalen Zahlungsmethoden will die EZB für die Einführung einer europäischen Digitalwährung untersuchen. Mit dem kürzlichen Start einer zweijährigen Analysephase wird die Arbeit an einem digitalen Euro erstmals konkret. Als Ergebnis der Analyse soll unter anderem entschieden werden, ob und in welcher Form die genannten Aspekte berücksichtigt werden.

Dabei gilt die Prämisse, dass der digitale Euro das Bargeld nicht ablösen, sondern ergänzen soll. Aus Verbrauchersicht muss die digitale Alternative ein Höchstmaß an Anonymität und Sicherheit darstellen. Verbraucher fordern, die digitale Alternative des Euros so zu gestalten, dass anonymes Bezahlen – zumindest kleinerer Beträge am Point of Sale – weiterhin möglich ist.

Neben Datenschutz und Sicherheit ist die Bereitstellung, Verfügbarkeit und Interoperabilität von hoher Bedeutung. Nach aktuellem Kenntnisstand will die EZB Geschäftsbanken und Payment Service Provider (PSPs) einbinden. Sie sollen als Vermittler zwischen Zentralbanken und Verbrauchern tätig bleiben. Aufgaben wie die Identifizierung, das Onboarding und die Bereitstellung der Wallet müssen bewerkstelligt werden. Schaut man jedoch genauer hin, bleiben viele offene Fragen bisher unbeantwortet:
 

  • Wie viele Bezahl-Wallets dürfen Verbraucher besitzen?
  • Welche Bereitstellungsmethoden wird es geben (Mobile Wallet, physische Karte, Bezahlarmbänder, etc.)?
  • Wie können Offlinezahlungen sichergestellt werden?
  • Kann mit dem digitalen Euro auch im E-Commerce gezahlt werden?
  • Welche Höchstbeträge für einzelne Zahlungen und die gesamte Haltung wird es geben?


Wie diese Fragen beantwortet werden und sich der digitale Euro schlussendlich von baren oder bestehenden digitalen Zahlungen abhebt, wird die EZB voraussichtlich erst in zwei Jahren bekannt geben. Nach einer anschließenden dreijährigen Entwicklungsphase könnte der digitale Euro 2026 pilotiert werden.

Wir von PPI verfolgen dieses Thema mit großer Begeisterung und sehen die eindeutige Abgrenzung der Nutzung für Privatpersonen zwischen dem digitalen Bargeld und digitalen Bezahlmethoden als essenzielles Element der Analysephase. Um Sie über aktuelle Entwicklungen auf dem Laufenden zu halten, werden wir Sie im kommenden Jahr auf diesem Wege regelmäßig über Neuigkeiten zum digitalen Euro informieren.

Autor: Philipp Schröder


Ein Jahr bis zur TARGET2-Umstellung – Sind Sie bereit?

In weniger als zwölf Monaten ist es so weit. Am 21. November 2022 stellt TARGET2 von MT auf MX um, ein Jahr später als ursprünglich geplant. Nach Angaben der Bundesbank betrifft die Migration ca. 1220 Teilnehmer, von denen sich 955 im Co-Management befinden (https://www.die-bank.de/news/fachtagung-zahlungsverkehr-der-zukunft-update-19327/). Zeitgleich beginnt die Übergangsphase der ISO-Migration von SWIFT. Nach der Schweiz und Japan ist das TARGET2-(EUR)-System eines der nächsten Systeme, welches auf ISO20022 migriert. Im Jahr 2023 folgen Großbritannien und die USA, die die Umsetzung sicher genau beobachten werden.  

Der straffe Zeitplan der Konsolidierung wird neben dem Tagesgeschäft und weiteren Projekten, wie der ISO-Migration von SWIFT, eine Herausforderung für viele Banken, die ihre IT auf MX umstellen. Die Zeit ist schnell vergangen, und das zusätzliche Jahr war von weiteren Vorbereitungen geprägt. Die Fachkonzepte sind geschrieben, die Umsetzung und internen Tests im vollen Gange. 

 Ein kurzer Blick zurück

Bereits Anfang September wurde mit den Connectivity-Tests gestartet. Das E-Ordering für die technische Registrierung für die TARGET-Services erfolgte mit dem jeweiligen Network Service Provider (NSP): SWIFT oder SIA. Einige Banken konnten so schon Anfang Oktober z. T. eine U2A- oder A2A-Verbindung mit ESMIG herstellen. Jeder Teilnehmer ist dabei verpflichtet, seine Testergebnisse selbst der Bundesbank mitzuteilen. Diese Verpflichtung besteht auch, sollte die Anbindung über einen Dritten, beispielsweise durch ein SWIFT-Service-Büro, durchgeführt werden. Alle Nachweise waren bis zum 30. November zu erbringen. Die Anbindungstests an ESMIG waren bis zum 1. Dezember vorzunehmen.

Der Blick nach vorne

Mit Umsetzung der verbleibenden Meilensteine in den nächsten Monaten werden die Teilnehmer optimal auf die Migration vorbereitet. Das bedeutet aber auch, dass spätestens ab jetzt Mitarbeiter den Tests zugewiesen werden sollten, die mit höchster Priorität die Einhaltung dieser letzten Meilensteine sicherstellen. 

Die anstehenden Connectivity- und Community-Tests wurden in den Schulungen der Bundesbank im Oktober und November weiter beleuchtet. Mit Einreichung des Formulars für die Anlage der Stammdaten werden seitens der Bundesbank automatisch die notwendigen Einstellungen im Testsystem vorgenommen und Benutzerdaten angelegt. 

Vom Teilnehmer sind dann alle Stammdaten 1x für das Testsystem und danach 1x für das Produktionssystem zu erfassen. Es werden keine Stammdaten aus den bestehenden Systemen übernommen. Die entsprechenden Einträge können also im Testsystem verinnerlicht werden, und die Teilnehmer können sich mit den Anwendungen vertraut machen. 

Ab Anfang Dezember, nach Anlage der ersten Stammdaten aus dem Formular durch die Bundesbank, sind die weiteren Stammdaten durch den Teilnehmer verpflichtend anzulegen. Diese bilden die Grundlage für die weiteren „Mandatory Test Cases“, die ab dem 1. Januar 2022 durchgeführt werden können. Im November wurde für das „Operational Related Testing“ ein Information Guide for TARGET Participants zur Verfügung gestellt. Insgesamt 7 Monate können darüber hinaus selbstdefinierte Tests durchgeführt werden, um die Funktionalitäten aller TARGET-Services und deren Zusammenspiel zu prüfen. 

Eine Übersicht der wichtigsten Termine

  • Der nächste Meilenstein „Community Test“ startet Anfang Dezember und deckt das „Business Day Testing“ (inklusive T2S und TIPS) und das „Operational Related Testing“ (u.a. ECONSII) ab.

  • Im Jahr des Big Bangs 2022 findet in der Woche vom 28. März – 01. April das „Migration Week Rehearsal“ (MWR) statt. Diese Tests finden unter der Woche statt und stellen sicher, dass die Stammdaten korrekt eingestellt worden sind. Die Initialisierung der Salden auf T2 wird geprüft.

  • Die „Migration Weekend Dress Rehearsals“ (MWDR) finden am 8. Juli, 23. September und optional am 15. Oktober statt. Hier werden weitere Funktionalitäten am Wochenende geprüft. Für alle Teilnehmer sind die von der Bundesbank veröffentlichten Termine für das MWR und die MWDR verpflichtend.   

Von der Bundesbank werden zusätzlich Tutorials, d. h. Videos für die Testdurchführung, bereitgestellt. In den Schulungen wurde beispielsweise auf die unterschiedlichen Eingaben der U2A- und A2A-DN hingewiesen. Hier unterstützt das Tutorial und führt den Teilnehmer Schritt für Schritt durch die Eingaben. Für Fragen rund um das Thema Test hat die Bundesbank zusätzlich die E-Mail-Adresse targetservices-test@bundesbank.de zur Verfügung gestellt.

Testnachweise für verschiedene „Mandatory Tests“ sollten möglichst zusammen versendet werden. Einzelne Testnachweise können aber auch nachgereicht werden. Sollten Testfälle nicht durchgeführt werden können, weil diese für die Bank nicht relevant sind, z. B. wenn diese kein RTGS DCA besitzt, so ist in Abstimmung mit der Bundesbank auch kein Test durchzuführen. Eine schriftliche Erklärung zu dem einzelnen Fall muss der Bundesbank gegenüber erbracht werden.

Die Schulungen haben einen Teil der Komplexität aufgezeigt, die es jetzt umzusetzen gilt. Dabei reicht es nicht mehr aus, nur eine grobe Einschätzung in Form einer Ampelfarbe zum Stand der Umsetzung der TARGET2-Konsolidierung zu geben. Jetzt sind Nachweise der Testergebnisse gefragt, und es wird sich zunächst zeigen, wem die technische Umsetzung gelungen ist. 

Ungefähr ein Viertel bis Drittel der Zentralbanken, „Closely Monitored Participants“ und „Regularly Monitored Participants“ meldeten bisher gelb und sehen somit Risiken, die ihre TARGET2-Migration schwieriger gestalten könnten (https://www.ecb.europa.eu/paym/intro/events/shared/pdf/fs12/2021-09-30-focussession-t2t2sconsolidation-marketreadiness.pdf, https://www.ecb.europa.eu/paym/intro/events/shared/pdf/fs11/T2-T2S_Consolidation_Market_Readiness.pdf). Obwohl Ende August die internen Tests der Teilnehmer beendet sein sollten, sind viele Teilnehmer mitten in der Testphase. Eine Abgrenzung der einzelnen Meilensteine scheint daher schwierig. Alle TARGET2-Teilnehmer müssen besonders jetzt darauf achten, mit Beendigung des Meilensteins diesen auch erfüllt zu haben. 


Autorinnen: Viktoria Liehmann, Sabine Aigner


Startschuss für SEPA 2.0

SEPA 2.0, also die Umstellung der SEPA-Formate auf die ISO-Version 2019 des ISO-20022-Standards, startet im November 2021. Die drohende Dreifachumstellung – bestehend aus TARGET2-Konsolidierung, SWIFT MT auf MX und SEPA 2.0 – ist durch eine stufenweise Umstellung für SEPA 2.0 abgewandt. Die verbleibende Zeit gilt es nun für Vorbereitungen intensiv zu nutzen.

Hinweis: Unterscheidung zwischen DK und EPC gilt für Deutschland

*https://www.europeanpaymentscouncil.eu/what-we-do/other-schemes/sepa-request-pay-scheme

 

 

Die Umstellung der ab November geltenden Formatspezifikation der Deutschen Kreditwirtschaft betrifft zunächst die Echtzeitüberweisung (pain001.001.09), das Haben-Avis für eingehende SCT Inst auf Basis von ISO 2019 (camt.054.001.08) sowie die Formate für Kontoinformationen (camt.052, camt.053 und camt.054). Die Version 09 für Echtzeitüberweisungen stellt hierbei eine Erweiterung der SCT-Inst-Formate dar, da die bisherigen Spezifikationen (pain.001.001.03 ohne Uhrzeit und pain.001.001.08 mit Uhrzeit) unverändert gültig bleiben. Ein aufwändiger Austausch bestehender Formate an der Kunde-Bank-Schnittstelle mit umfangreicher Endkundeneinbindung wird hierbei also zunächst nicht erforderlich und auf einen späteren Zeitpunkt vertagt.

Im November 2022 wird die ISO-Version 2019 mit der Aufnahme der Formatspezifikation für Request to Pay (RTP) in das DFÜ-Abkommen fortgesetzt. Da dieser neue Standard zunächst optional ins DFÜ-Abkommen aufgenommen wird, ist eine Parallelaktivität zur TARGET2-Konsolidierung nicht explizit vorgegeben, sondern bleibt den Banken vorbehalten, die in die Verbesserung des Kundenerlebnisses investieren möchten.

Der größte Aufwand für die Einreichung durch Endkunden wird im November 2023 entstehen, da zu diesem Zeitpunkt die Umstellung der SEPA-Formate für Überweisungen und Lastschriften vorgesehen ist. Die verbleibende Zeit sollte für die Vorbereitung der dafür erforderlichen Kundeneinbindung genutzt werden, um eine Verschiebung von Umstellungszeitpunkten analog zur verpflichtenden SEPA-Einführung im Jahr 2014 zu vermeiden. 

Eine intensive Vorbereitung gemeinsam mit involvierten Kunden ist auch für das Finale der SEPA-2.0-Umstellung dringend geraten. Im November 2025 entfallen die Formate MT940 für Kontoinformationen vom Vortag und MT942 für tagaktuelle Kontoinformationen als DK-Standard. Kunden, die auf diese Informationen für ihre Buchhaltung angewiesen sind, müssen ab diesem Zeitpunkt die Kontoinformationen in den camt-Formaten in der Version ISO 2019 verarbeiten können, was auf der Endkundenseite einen erheblichen Aufwand und somit einer langen und intensiven Vorbereitung bedarf.

Die Veränderungen, die mit der Umsetzung von SEPA 2.0 einhergehen, beeinflussen das Zusammenspiel von Formaten in der Verarbeitungskette und somit auch die Funktionsweise von Zahlverfahren. Alle bankinternen Systeme, die änderungsrelevante Formate produzieren und/oder entgegennehmen, sowie die zuliefernden bzw. empfangenden Kunden sind maßgeblich betroffen. Das Risiko einer fehlerhaften Weiterverarbeitung oder auch das Risiko von Zahlungsablehnungen lässt sich durch eine frühzeitige Auseinandersetzung mit der Thematik begrenzen. Es können sogar vielmehr Mehrwerte geschaffen, Prozesse ganzheitlich optimiert und Systemfunktionalitäten durch Anpassung und Verzahnung von Banksystemen gesteigert werden.

Wir stehen aktuell in den Startlöchern für die SEPA-2.0-Umstellung. Der Aufwand für die Umstellung wird durch die skizzierte Entzerrung der Umstellungsschritte zwar insgesamt nicht geringer, aber zumindest besser planbar. Wir werden die Umsetzung eng begleiten und über aktuelle Entwicklungen an dieser Stelle berichten.  

Rebecca Stannull, Eric Waller



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


Der digitale Euro - Mehr Fragen als Antworten?

Die Europäische Zentralbank wird sich in den kommenden Jahren intensiv mit digitalen Währungen beschäftigen. Die Gestaltungsmöglichkeiten sind dabei vielfältig und werfen Fragen auf.

Diesen Monat (Okt. 2021) soll es losgehen. Die Europäische Zentralbank (EZB) startet ein zweijähriges Analyseprojekt, welches bewerten soll, wie der digitale Euro gestaltet werden könnte. Als Ergebnis der Analysephase soll entschieden werden, ob und in welcher Form die EZB den digitalen Euro bereitstellen wird.

Aus bisherigen Diskussionen und Veröffentlichungen wird jedoch deutlich: Der digitale Euro wird wenig Parallelen zu Funktionen aktueller privater Kryptowährungen aufweisen. Blockchain-Infrastrukturen und deren Vorteile werden im Kontext des digitalen Euros kaum berücksichtigt. Die Europäische Zentralbank wird den Fokus auf alternative Ansätze zum Bargeld und die Auswirkungen auf das Geldsystem legen.

Die (Umsetzungs-)Varianten sind dennoch vielfältig, sodass Spielraum für spannende Diskussionen entsteht. Potenzielle Formen und Auswirkungen müssen verstanden und intensiv bewertet werden.
Folgende Leitfragen können als eine erste Grundlage dienen:

 

  • Welche Mehrwerte und Anwendungsfälle entstehen für die verschiedenen Stakeholder?
    • Banken, Payment Service Provider, Privatpersonen, Handel, Industrie, Europäische Zentralbank
  • Wie sieht die technische Gestaltung des digitalen Euros aus?
    • Wird die digitale Währung auf einer Konten- oder Tokeninfrastruktur aufgebaut?
    • Wie erfolgt der Übertrag der Werte zwischen den teilnehmenden Parteien?
    • Wird den Benutzern ausschließlich ein digitales Produkt zur Verfügung gestellt? 
  • Wie wird die Nutzung für die Privatperson gestaltet?
    • Wie wird Anonymität sichergestellt?
    • Wird es Betragsgrenzen für die Nutzung und Verwahrung geben?
  • Wie und durch wen erfolgt das Onboarding und die Bereitstellung?
    • Welche regulatorischen Anforderungen werden entstehen?
    • Wie werden Banken und Payment Service Provider eingebunden?    
    •  …


Auch wenn das Analyseprojekt erst startet, viele Trends lassen sich bereits jetzt ableiten. PPI verfolgt dieses Thema mit großer Begeisterung und hat bereits einige Thesen zu diesen Fragen aufgestellt. In den kommenden Wochen werden wir diese mit Ihnen teilen und diskutieren.

Autor: Philipp Schröder

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