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

Open Banking: EBICS versus API

Open Banking ist einer der Megatrends, den viele Banken angeblich zu verschlafen drohen. Weil kaum eine PSD2-Schnittstelle marktreif zu sein scheint, hat die Bankenaufsicht jetzt bis Dezember 2020 eine Übergangsfrist eingeräumt. Doch das Problem liegt woanders: Viele Institute verspüren nur wenig Lust, viel Geld in die Hand zu nehmen, um Anbietern von Open-Banking-Schnittstellen das Leben zu erleichtern – zumal etablierte Protokolle wie FinTS und EBICS viel mehr leisten als die „APIisierung“ des Bankgeschäfts bisher hervorgebracht hat.

Beide Protokolle, FinTS und EBICS, umfassen heute schon fast alle Bereiche des Bankings, vom Zahlungsverkehr über den Wertpapierhandel bis hin zum Kreditgeschäft. Insgesamt stehen weit mehr als 200 Prozesse bereit, die sowohl die fachlichen Schnittstellen verbindlich beschreiben als auch die technische Kommunikation der beteiligten Partner untereinander. Seit den 90er-Jahren geben HBCI und FinTS bereits die Richtung für offene Standards in der Kommunikation mit Banken vor. EBICS ist von der Deutschen Kreditwirtschaft (DK), beziehungsweise deren Vorläufer, schon vor mehr als zehn Jahren als verbindlicher Standard für die Kommunikation mit Firmenkunden eingeführt worden. Open Banking ist also seit vielen Jahren bereits Realität in Deutschland.

Keine einheitliche PSD2-Schnittstelle in Sicht

So gut die Idee von Open Banking auch ist. Die auch durch PSD2 forcierte Debatte lässt viele Banken, selbst die willigen, ratlos zurück. Einerseits soll unter anderem durch PSD2 ein Open-Banking-Standard für ganz Europa entstehen. Andererseits hat der Gesetzgeber bewusst offengelassen, wie die Kommunikation genau stattfinden soll und wie sie abzusichern ist. Die Folge: Anbieter von Open-Banking-APIs drängen die Banken dazu, ihre Lösungen zu implementieren und ihre ureigenen Interpretationen von Open Banking zu übernehmen, nur um ja nichts zu verpassen. Hinzu kommt, dass verschiedene Initiativen in den unterschiedlichen Ländern Protokolle zur technischen/fachlichen Nutzung entwickeln, die zu einem Wildwuchs an API-Dialekten führen werden. Länderübergreifende Konzeptionen dagegen sind noch bei weitem nicht in Sicht.

All dies kann sich für die Institute zu einem Fass ohne Boden entwickeln, wenn nicht bald eine einheitliche PSD2-Spezifikation vorliegt, an der sich jede Bank orientieren kann. Solange das nicht passiert, dürften viele Open-Banking-Träumereien unerfüllte Wünsche bleiben. Denn die Öffnung hat per Gesetz kostenlos und frei von Diskriminierung zu erfolgen. Damit Geld verdienen wollen andere. Was also soll die Motivation für eine Bank sein, immer neue API-Dialekte kostenfrei anzubinden, nur damit Drittanbieter ihre Apps leichter unter das Volk mischen können? Damit degradieren sich die Institute selbst zum reinen Serviceanbieter. Viel naheliegender ist doch, auf längst etablierte Standards zurückzugreifen.

EBICS: Open Banking für Firmenkunden

Einer dieser Standards ist EBICS. Und dieser Standard ist weit verbreitet: Neben Deutschland spricht auch Frankreich EBICS. Zwischen der Deutschen Kreditwirtschaft und ihrem französischen Pendant, dem CFONB, besteht ein Kooperationsabkommen. Diese beiden größten Zahlungsverkehrsmärkte in Euroland decken das Firmenkunden- und das Interbankengeschäft mit EBICS ab. Die Schweiz (SIX) zählt ebenfalls zu den EBICS-Fans. Österreich (STUZZA) überlegt einzusteigen. Statt im API-Sumpf unterzugehen, lohnt es sich zu fragen, wie sich EBICS PSD2-konform ausbauen lässt. Die Antwort: mit einer Fernsignatur (vgl. Abb.1). Ein modernes EBICS-Portal kann aus eingehenden Daten wie dem Code einer PhotoTAN oder einer QR-TAN Hardware-basiert die Signatur erstellen und an den EBICS-Bankrechner senden.

Abb. 1: Wie Fernsignaturen EBICS zu einer PSD2-konformen Open-Banking-Lösung erweitern

EBICS bietet Firmenkunden viele Vorteile. Unternehmen, die über einen EBICS-Client verfügen, können sicheres Multibanking betreiben und auch die Verteilte Elektronische Unterschrift nutzen (VEU). Damit lassen sich Rollen- und Rechtemodelle abbilden (Signaturen T, A, B und E), um etwa zu bestimmen, ob eingereichte Zahlungsaufträge von autorisierten Personen stammen und ob die jeweilige Person über die entsprechenden Berechtigungen verfügt, um diese Zahlungsaufträge freizugeben. Ähnlich wie bei FinTS gilt auch für EBICS: Die nötige Infrastruktur, um Open Banking zu verwirklichen, existiert bereits. Schon allein deshalb lässt sich nachvollziehen, dass viele Institute damit hadern, jetzt zu investieren. Niemand garantiert, dass sie sich für den richtigen API-Anbieter entscheiden oder dass der Gesetzgeber keine neuen Vorschriften erlässt, die bereits getätigte Investitionen obsolet machen.

Linktipps:
•    Erwartung trifft auf Realität: PSD2 Schnittstellen sind weiterhin nicht marktreif
•    Open Banking: Mit FinTS und EBICS gegen den API-Wildwuchs (PSD2/XS2A-Lösung)

Autor: Michael Schunk

Weiterlesen

XS2A ohne Drittdienstanbieter? Warum nicht!

Im Rahmen der PSD2 wurde europaweit eine Schnittstelle für Drittdienstanbieter (XS2A-API) eingeführt. Die EU als Initiator strebt damit an, den Zugang zu den Bankkonten der Kunden für Dritte zu öffnen und damit den Wettbewerb im Markt zu fördern. Seit dem 14.09.2019 ist die XS2A-API fristgerecht in Europa von den Banken in Produktion genommen worden. Seither orientieren sich die Marktteilnehmer neu, adjustieren die XS2A-API an die Bedürfnisse der Stakeholder und arbeiten intensiv an Diensten sowohl für Verbraucher als auch für Firmen.

Als regulatorisches Must-have ist die XS2A-API für Banken zunächst einmal ein Kostentreiber. Jedoch wurden von Anbeginn Mehrwertdienste angedacht und z. B. von der Berlin Group bereits spezifiziert, um den Banken eine Einnahmequelle zu ermöglichen. Doch den Phantasien hinsichtlich der Einnahmequellen, von denen es im aktuellen API-Hype viele gibt, sind keine Grenzen gesetzt.

Wir reiten also für den Moment die Hype-Welle mit und stellen uns die XS2A-API als alternativen Zugangskanal für Firmen vor. Warum nicht. Aus technischer Sicht sollten die Hürden gering sein. Eine Firma könnte sich wie ein Drittdienstanbieter durch ein eIDAS-Zertifikat ausweisen. Das Zertifikat würde sich nur in den spezifischen Feldern für Drittdienstanbieter unterscheiden. Ähnlich zu EBICS können eingereichte Aufträge oder Anfragen mit einer Signatur versehen werden, an Hand derer der Empfänger die Unversehrtheit der Nachricht prüfen kann. Die Sicherheit auf dem Transportweg wird durch die Verwendung von TLS gewährleistet.

Aus fachlicher Sicht können mit Hilfe des Use Cases „Zahlung initiieren“ sowohl Einzel- als auch Sammelzahlungen ausgeführt werden. Für die Freigabe werden den Verbrauchern die gängigen Autorisierungsverfahren aus dem Online-Banking angeboten (z. B. photoTAN, pushTAN). Für Firmen wäre das wahrscheinlich ungeeignet, sodass eher Corporate Seals zum Einsatz kommen würden, was zu spezifizieren ist. Ebenso die Abfrage von Kontoinformationen (Salden, Transaktionen, Details) ist über die XS2A-API möglich. Die dafür erforderliche Einwilligung (consent) könnte in diesem speziellen Fall, wo zwischen Firma und Bank ein Vertrauensverhältnis besteht, durch eine dauerhaft gültige Einwilligung gelöst werden.

Aus der mittleren Flughöhe gesehen wäre die XS2A-API also eine valide Alternative, die auch bereits in verschiedenen Foren angedacht wird. Hier wird die Idee mit Attributen wie „günstiger, bequemer, echtzeitfähig sowie flexibler bei Anpassungen“ belegt. Jedoch holt uns der Status quo auf den Boden der Tatsachen zurück. Die prägende Spezifikation, die der Berlin Group, lässt den Banken viele Freiräume, die API zu implementieren. In der Bestrebung, alle Banken in Europa über XS2A zu erreichen, stellen diese Freiräume für alle Marktteilnehmer aktuell eine Herausforderung dar. Ein Zustand, der für Firmen nicht einladend ist, noch nicht. Jedoch ist der Grundstein für eine Alternative gelegt.


Autor: Christian Wenz

Weiterlesen

EBICS und die API-Diskussionen – Ein Statusupdate aus der Schweiz

Seitdem SIX Interbank Clearing (SIC) als Repräsentant des Finanzplatzes Schweiz im Frühling 2015 als offizielles Mitglied in die EBICS SCRL aufgenommen wurde, hat sich im Bereich der Firmenkundenschnittstellen bei Banken (Neudeutsch auch „Corporate Communication Interfaces“) einiges getan. Und aktuell rumort es ebenfalls wieder auf dem Gebiet der elektronischen Schnittstellen, sodass es sich lohnt, in diesem Blog wieder einmal einen Blick auf die aktuelle Situation in diesem Bereich in der Eidgenossenschaft zu werfen.

Natürlich soll hier auch die Rede von APIs (Application Programming Interfaces) sein, denn in manchen Geschäftsleitungs-Etagen bei Banken erscheinen diese drei Buchstaben als der große Heilsbringer in der Digitalisierungsstrategie. Haben also APIs, insbesondere für die Abfrage von Kontoinformationen oder die Beauftragung von Zahlung das Potential, die altgedienten Dateitransferprotokolle wie EBICS obsolet zu machen? Insbesondere vor dem Hintergrund, dass gerade neue Startups und FinTechs diese schlanken APIs dem doch etwas aufwändig zu implementierenden EBICS bevorzugen?

Um diese Frage für die Schweiz beantworten zu können, benötigt der mit dem Finanzplatz Schweiz weniger vertraute Leser aktuelle Hintergrund-Informationen. Zunächst einmal ist festzuhalten, dass die Schweiz als Nicht-EU-Mitglied in keiner Weise an die PSD2 (Payment Service Direktive) gebunden ist. Womit ein großer Treiber, die Pflicht eine API anzubieten, für Banken erstmal wegfällt. Des Weiteren gibt es in der Schweiz auch keine standardisierte Schnittstelle fürs Onlinebanking à la FinTS wie in Deutschland. Nichtsdestotrotz ist die frohe Botschaft der Europäischen Union natürlich auch in der Schweiz vernommen worden.

Bevor wir uns etwas vertiefter mit den zurzeit heiß diskutierten API-Initiativen beschäftigen, soll noch einmal die EBICS-Verbreitung gewürdigt werden. In den letzten gut fünf Jahren hat sich das Protokoll nach dem Vorbild der deutschen Implementierung bei allen größeren Instituten als Standardangebot für den elektronischen Austausch von Daten mit Firmenkunden durchgesetzt. Die Protokolleigenschaften, sehr große Volumina transferieren zu können sowie neuerdings auch der Einsatz der VEU (Verteilte Elektronische Unterschrift), werden von mittleren und größeren Firmenkunden sehr geschätzt. Auch alle namhaften Schweizer Softwareanbieter mit Lösungen im Electronic Banking haben EBICS im Angebot.

Soweit so gut, könnte man meinen. Wie eingangs erwähnt, ist hierzulande die API-Diskussion ebenfalls in vollem Gange und wir beobachten momentan drei erwähnenswerte Initiativen, welche nachfolgend kurz vorgestellt werden. Um es an dieser Stelle vorweg zu nehmen, aus Sicht des Autors sind diese Initiativen kein Ersatz für EBICS, sondern ergänzen ein Schnittstellen-Angebot eines Finanzinstitutes für ein bestimmtes Kundensegment (in der Regel kleinere Firmenkunden, die über eine Cloud-Lösung mit der Bank Informationen in beide Richtungen austauschen).

Sehr vielversprechend erscheint momentan „Corporate API“, die Initiative von SIX und den Schweizer Banken. Unter diesem Namen entwickelt die SIX zusammen mit Vertretern der Banken und Software-Hersteller nicht nur einen frei verfügbaren Standard, sondern gleich noch die passende Plattform dazu. Diese Plattform erlaubt eine sehr einfache Teilnahme an einem neu entstehenden Öko-System, das Services weit über den PSD2-Rahmen (AIS, PIS) hinaus anbieten wird.

Als Formate werden bei der „Corporate API“ JSON und ISO20022 XML angeboten. Die JSON-Variante wird dabei sehr einfach und rasch zu implementieren sein und zielt auf SW-Anbieter, welche nicht die Komplexität der ISO20022-Meldungen benötigen. Die ISO20022 XML-Variante unterstützt das gesamte Spektrum der aus der Migration ZV CH bekannten Möglichkeiten. Bereits gegen Ende 2018 werden erste Tests mit Pilot-Banken und -herstellern durchgeführt werden.

Ein weiteres Projekt läuft unter dem Namen „Common API“. Das Common API der SFTI (Swiss Fintech Innovations) lehnt sich stärker an PSD2 bzw. die Implementierung der BerlinGroup an. Gegenüber der Corporate API-Variante formuliert die Spezifikation der SFTI das API allgemeiner und überlässt die Wahl der Zielgruppe dem Service Provider. Gemäß Informationen der SFTI sind bei der Entwicklung dieses Standards die großen Bankapplikations-Anbieter mit an Bord. SIX hat den Entwicklungsprozess der SFTI-Spezifikation von Anfang an begleitet und wird zukünftig die Ergebnisse der SFTI-Arbeitsgruppe weiterführen. Gut möglich also, dass aus zumindest in Teilen die Standards kompatibel ausfallen werden.

Die Situation für Softwarehersteller ist somit in der Schweiz nicht gerade einfach, da einerseits mit EBICS ein etabliertes produktives Protokoll zur Verfügung steht und neue Initiativen in den Startlöchern stehen. Je nach Kundensegment und Geschäftsmodell stellt sich für Lösungsanbieter die Frage, eine oder allenfalls auch gleich mehrere Implementierungen anzubieten. Kommt hinzu, dass einige Banken bereits proprietäre Interfaces publiziert haben (etwa die Hypothekarbank Lenzburg, welche als sehr innovative Fintech-Bank auftritt). Weitet man das Einsatzgebiet auf Europa aus, dann kommen noch bereits bekannte Initiativen wie „Berlin Group“, „STET“ oder „Open Banking“ dazu. Typischerweise hat der Finanzplatz Schweiz keinen existierenden Standard übernommen, da hierzulande das „Swiss Finish“ immer noch hoch im Kurs ist.

Carsten Miehling

Weiterlesen