Aus dem Unterricht des CAS Digital Finance mit Mathias Gläser berichtet Marco Peter:

Jeder von uns kennt sie, die Preisvergleichsportale, wo auf Knopfdruck der günstigste Flug von Zürich nach London inklusive Hotel gesucht und gebucht werden kann. Keines dieser Portale würde ohne Schnittstellen zu den Datenprovidern, in unserem Fall Airlines und Hotels, existieren. Anstelle von Schnittstellen spricht man auch von Interface bzw. noch spezifizierter von API. Aber was ist nun genau ein API?

API

API = Application Programming Interface oder zu Deutsch „Programmierschnittstelle“. Über das API kann eine Applikation Daten anderen Applikationen zur Verfügung stellen, bzw. über das API kann ein Frontend mit dem Backend kommunizieren. Ein Frontend ist im Übertragenen Sinne z.B ein Kellner in einem Restaurant. Diesem gebe ich eine Bestellung auf und die Küche ist das Backend, welches die Bestellung umsetzt. Mehr dazu in folgenden Video.

Open API

Gerade im Finanzumfeld werden oftmals «All in one» Lösungen eingesetzt. Dies ist somit ein Produkt, welches sich um die gesamte Palette der Bankdienstleistung kümmert. Solche Lösungen verfügen dann zwar auch über einen API Layer, welcher das Frontend mit dem Backend verbindet, aber oftmals ist es so, dass solche Produkte keine offenen Schnittstellen (Open API’s) anbieten. Die Open APIs ermöglichen dem System Interaktionen mit Services von Drittparteien. So könnte z.B. ein Reporting Produkt eines Drittanbieters einfach integriert werden, da dieses über die offene Schnittelle auf die relevanten Daten zugreifen kann. Falls diese Möglichkeit bei der «All in one» Lösung nicht angeboten wird, ist man auf «Gedeih und Verderb» dem Produktehersteller ausgeliefert. In diesem Fall bestimmt er, welche zusätzlichen Services zu welchem Preis angeboten werden. Dies muss nicht per se schlecht sein, es ist aber Wert, sich darüber eine klare Meinung zu bilden.

Wachstum der API’s

  1. Ursprünglich wurden IT Systeme in der Bank oft als sogenannten «Silo-Applikationen» gebaut, welche sehr eingeschränkten Kontakt zu anderen Silos hatten. Änderungen waren immer mit gossen Kosten verbunden. Zudem wurde auch die IT Infrastruktur «in House» betrieben.
  2. Auf Grund von immer stärkerem Kostendendruck wurden die Silos zerteilt und untereinander verknüpft, also mit API’s versehen. Dadurch wurden Anpassungen schon wesentlich kostengünstiger.
  3. Damit man aber noch mehr Kosten sparen konnte, wurde ein Teil der Applikationen in Clouds ausgelagert und die Infrastruktur wurde durch Service Provider zu Verfügung gestellt. Dies war aber nur dank den API’s möglich, über welche man wieder auf die Services und Daten zugreifen konnte.

Es war aber nicht der Kostendruck alleine, welche die Anzahl der API’s explodieren liess. Die Verbreitung der Smartphones trug auch massgeblich dazu bei. Dies lässt sich einfach an der Korrelation der beiden Grafiken erkennen.

Business Modelle

API’s dienen aber nicht nur dazu den Betrieb billiger zu gestalten, sondern um mit Partnern und Kunden Geschäfte zu machen. Heute liegt der Fokus nicht mehr auf der IT Architektur, sondern viel mehr auf der Unternehmensarchitektur. Sprich welche Services will ich wem anbieten oder von wo will ich gewisse Services beziehen.

Als Unternehmen muss ich somit API’s anbieten, damit ich meine Ziele im Markt erreichen kann. Ganz am Anfang des Blogs erwähnte ich das Beispiel mit dem Preisvergleichsportal. Wenn nun die Airline nicht ganz bewusst API’s zur Verfügung gestellt hätte, würden sie jetzt kaum Flüge verkaufen können. Wer würde sich schon die Mühe machen, jede Airline Seite einzeln anzuschauen?

Die Digitalisierung nimmt «Reibungsverlust» (Kosten / Zeit) aus den Prozessen, welche sonst die Reichweite in der Wertschöpfungskette und der Skalierung bremst. Die API’s gehören somit zu den grössten Hebeln, um diesen Reibungsverlust aus den Prozessen zu entfernen.

Salesforce.com generiert z.B. 50% ihres Umsatzes dank API’s. Dritt-Parteien können auf dem Marktplatz von Salesforce zusätzliche Funktionen/Apps anbieten, welche die Kunden von Salesforce nutzen können. So kann sich Salesforce auf den Kern der Lösung konzentrieren und ihren Kunden trotzdem nützliche Features über den Marktplatz bieten und generiert entsprechende Nutzungsgebühren.

Expedia.com erwirtschaftet sogar über 90% Ihres Umsatzes dank der API‘s, da sie per-se ja «nur» Informationen von Dritt-Anbietern (Flug, Hotel, Autovermietung usw.) abfragen und dem Kunden konsolidiert zur Verfügung stellen. Ohne die API’s könnten sie nicht existieren.

Schweizer Banken und die API’s

Aktuell gibt es nur wenige CH Banken, die effektiv auf den API Zug aufgesprungen sind und sich aktiv geöffnet haben. Klar nutzen etliche bereits Services von dritten oder haben untereinander dedizierte Lösungen wie z.B Twint geschaffen. Der Umwelt aber Zugriff auf eigene Daten / Services zu geben, das ist manchen noch zu viel des Guten. Zu gross ist die Angst vor der Veränderung. Viele befürchten den direkten Kontakt zum Kunden zu verlieren, da Drittanbieter plötzlich in der ersten Reihe stehen.

In Europa wurde die Öffnung der Banken im Bereich des Zahlungsverkehrs bereits durch die PSD2 (Payment Services Directives 2) Initiative vollzogen. Gemäss dieser Richtlinie müssen Banken Dritten Zugriff auf die Kundendaten ermöglichen. Dies lässt sich einfach an folgendem Beispiel veranschaulichen:

Vor PSD2 musste ein Kunde in das jeweilige E-Banking seiner Bank einloggen, um seine Kontoinformationen zu sehen. Mit PSD2 kann z.B. ein Fintech eine App anbieten, welche dank der standardisierten API’s einfach auf die Daten des Kunden bei seinen verschiedenen Banken zugreifen kann.

AISP = Account Information Service Provider

Gemäss Andreas Kubli (Head Multichannel Management & Digitalization UBS Schweiz) hat PSD2 in der Schweiz keine Rechtskraft und somit keine direkten Auswirkungen. Das ganze Interview gibt es auf moneytoday.

Somit bleibt es spannend, wie es auf dem Bankenplatz Schweiz mit den (Open) API’s weitergeht.