Mittlerweile ist die API-Thematik auch in der Schweizer Finanzindustrie angekommen. Inspiriert durch die PSD2-Richtlinien, welche den EU-Instituten bestimmte Services vorschreiben, entstehen in der Schweiz durch die Markteilnehmer erstellte, eigene Standards.
Nachdem die SIX mit ihrem Corporate API gleich eine Plattform lanciert, hat nun auch die SFTI am letzten Donnerstag (20.09.2018) ihre Version einer API-Spezifikation veröffentlicht. In beiden Organisationen arbeiten Vertreter der Finanzdienstleister und Software-Anbieter mit.
Zeit also, die aktuellen API-Initiativen einem Vergleich zu unterziehen und herauszufinden, ob sich eine bestimmte Variante durchsetzen wird.
Und zu guter Letzt …. was bedeutet API überhaupt? (Nicht das, was Sie jetzt vielleicht grad meinen…)
Gute Software-Architektur besteht unter anderem darin, Bedienungsoberflächen und Business- Funktionen zu trennen. Mit diesem Ansatz lassen sich unterschiedliche Applikationen generieren, welche über Schnittstellen die gleichen Business-Funktionen nutzen. Somit lassen sich Applikationen für die verschiedensten Geräte-Typen und Betriebssysteme einfacher und effektiver realisieren.
In einem weiteren Schritt werden diese Schnittstellen extern zugänglich gemacht, sodass Dritt-Hersteller ihre eigenen Applikationen mit den Business-Funktionen eines Service Providers ergänzen können.
Konsequent zu Ende gedacht könnte dies bedeuten, dass eine Bank gar kein eigenes e-Banking mehr betreibt, sondern lediglich die entsprechenden Funktionen mittels einer Schnittstelle verschiedenen Software-Herstellern zur Verfügung stellt.
Diese Schnittstellen sind nun also diese sogenannten APIs, Application Programming Interfaces. Gegenüber rein internen Schnittstellen, bei welchen keine Rücksicht auf externe Anbieter genommen werden muss, gelten an APIs erhöhte Anforderungen, insbesondere an die Sicherheit.
Schnittstellen unterscheiden sich unter anderem dadurch, ob sie die beteiligten Systeme eng oder lose aneinanderbinden. Eng gekoppelt bedeutet, dass die beteiligten Komponenten exakt aufeinander abgestimmt sind. Eine Anpassung in einem System hat Auswirkungen auf die Schnittstelle und das andere System. Die Wartung und Weiterentwicklung von eng gekoppelten Systemen wird daher um einiges höher. Dafür aber gewinnt man eine erhöhte Performance und eine niedrigere Komplexität der Schnittstelle.
Lose gekoppelte Systeme haben aber entscheidende Vorteile, insbesondere denjenigen, dass die beteiligten Systeme unabhängig voneinander aktualisiert werden können. In der heutigen, schnelllebigen (agilen) Welt ist das meistens eine zwingende Anforderung.
Das bedeutet aber auch, dass die Schnittstellen komplexer werden. Unter anderem müssen sie flexibler werden, verschiedene Versionen gleichzeitig unterstützen, plattformübergreifend funktionieren und ja, sie sollen auch schnell sein (performant). In diesem Punkt arbeitet die Zeit für die Service Provider. Mit der immensen Performance, welche uns heutzutage zur Verfügung steht, sinkt das Bedürfnis, eng gekoppelte Systeme betreiben zu müssen. Selbst ein Smartphone hat die mehrfache Leistungsfähigkeit eines früheren Super-Computers.
Zugegeben, auf dem Cray liess es sich aber so gemütlich sitzen wie auf einem wohlig warmen Kachelofen….
Letztendlich müssen APIs auch stetige Veränderungen und Erweiterungen zulassen, ohne gleich die gesamte Schnittstellen-Struktur auf den Kopf zu stellen. Service Provider müssen in der Lage sein, ihr Angebot laufend den Bedürfnissen des Marktes anzupassen (innovativ).
Zusammengefasst ist dies die eigentliche Bedeutung von API: Agil - performant - innovativ
Alle diese Anforderungen an externe Schnittstellen haben dazu geführt, dass eine eigentliche Schnittstellen-Industrie entstanden ist. Auf dem Markt sind verschiedenste Werkzeuge und Applikationen zu finden, welche die Veröffentlichung von APIs ermöglichen oder erleichtern. Ziel dieser Lösungen (API-Gateways) ist es, dass sich der Service Provider auf die Implementation der Business-Funktionalität konzentrieren und die externe Schnittstelle (API) sehr flexibel gegen aussen zur Verfügung stellen kann. Die eingangs erwähnte Frage, welche API-Variante sich schlussendlich durchsetzen wird, rückt somit in den Hintergrund. Wenn die Business-Funktionalität vorhanden ist, können mittels API-Gateways die verschiedenen API-Varianten damit verbunden werden. Der Aufwand, eine Funktion sowohl im Rahmen des Corporate API als auch Common API im Markt anzubieten, reduziert sich daher auf ein Minimum. Selbst eine BerlinGroup-Variante kann somit relativ einfach realisiert werden.
PSD2 - BerlinGroup
Naturgemäss unterscheiden sich die API-Varianten nicht sehr stark. Das API der BerlinGroup implementiert die Anforderungen aus der PSD2-Richtlinie. Diese beinhaltet den Zugriff auf Bankkonten für die Abfrage von Salden und Transaktionen (AIS - Account Information Service) sowie die Möglichkeit, Zahlungen im Auftrag des Kontoinhabers auszulösen (PIS - Payment Initiation Service). Den dritten Service, welcher es erlaubt, für eine bestimmte Karten-Transaktion die Verfügbarkeit des benötigten Betrags zu prüfen, wird in den Schweizer Versionen nicht vorgesehen.
Als Zahlungsformate kommen JSON oder ISO20022 XML zum Einsatz, wobei keine Vorschriften gemacht werden, welches Format die Service Provider anbieten müssen. Das API der BerlinGroup unterscheidet sogenannte Payment-Products in den Ausprägungen SEPA, SEPA-Instant, Target2 und Cross-Border. Zudem werden sogenannte ”community specific payment product definitions” zugelassen, welche von Nicht-EUR-Ländern (z.B. Norwegen) genutzt werden können. Im März 2019 müssen die Finanzinstitute den Dritt-Hersteller (TPP - Third Party Providers) das Testing ermöglichen. Bereits im Oktober 2019 müssen produktive Lösungen im Markt angeboten werden.
Corporate API
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, welches Services weit über den PSD2-Rahmen (AIS, PIS) hinaus anbieten wird. Ausgerichtet ist diese Plattform auf Firmenkunden, unterstützt aber auch Lösungen im Retail-Kundensegment.
Als Formate werden 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. Ungefähr Mitte 2019 werden dann die ersten Teilnehmer an dieser Plattform produktiv arbeiten.
Common API
Das Common API der SFTI 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. 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 sich der Entscheid ”Corporate API oder Common API” gar nicht stellt, sondern es sich als sinnvoll erweisen wird, sowohl als auch anzubieten. Mit dem passenden API-Gateway kein Ding der Unmöglichkeit.
Allen API-Initiativen gemeinsam ist die Verwendung des RESTful API. Dies bedeutet, dass Standard-HTTP-Funktionen wie GET, POST, PUT und DELETE zum Einsatz kommen. Mit dieser Technologie sind inzwischen alle SW-Hersteller vertraut, es gehört heutzutage zum Handwerk eines SW-Herstellers, Lösungen nach diesem Entwurfsmuster zu erstellen. Als Provider ist es wichtig, sein Angebot auch nach diesem Muster zu erstellen.
PPI Schweiz unterstützt Sie bei der Evaluation, Entwicklung und Implementation Ihrer API-Lösung.
Dieser Blog wurde von Rolf Zumsteg verfasst
#API #APIGateway #CorporateAPI #CommonAPI #BerlinGroup #agil #performant #innovativ #ecosystem #REST
0 Kommentare:
Kommentar veröffentlichen