Eine Spezifikation ist noch lange kein Produkt…

…oder was wir von Instant Payment und PSD2-APIs lernen können

AKTUELL WIRD VIEL ÜBER NEUE THEMEN IM ZAHLUNGSVERKEHR GESPROCHEN. NEBEN PSD2 UND DEN ZUGEHÖRIGEN APIS AUF BANKENSEITE AUCH VIEL ÜBER SEPA INSTANT PAYMENT. DAS IST SUPER, DRINGEND NOTWENDIG UND AUCH AN DER ZEIT.

Was mir allerdings in vielen der Diskussionen auffällt: Spezifikationen werden, vor allem von Experten, in der Sache sehr häufig zum Produkt gemacht. Und diese Betrachtungsweise ist aus meiner Sicht GRUNDLEGEND falsch! Warum: Spezifikationen sind die Grundlage / der Standard für Produkte, sozusagen der ersten Schritt auf dem Weg zu einer echten Lösung.

Oder hart gesagt: Spezifikationen sind der Wunsch, Produkte die Realität.

Bei Instant Payment haben wir genau diese Herausforderung schon mehrfach hier im Blog betrachtet und z.B. die Frage gestellt, ob Instant Payments ein Produkt oder ein Feature sind. Ich gehe sogar noch einen Schritt weiter: Es ist nichts von beidem, sondern eben lediglich eine Spezifikation und ein generelles Themengebiet. Ähnliche Entwicklungen sehen wir aktuell, bei dem für viele Fachleute spannendem Thema PSD2-APIs für Banken. Die sehr begrüßenswerte Aktivität beispielsweise der BerlinGroup wird aktuell von vielen Seiten als die Lösung aller Probleme auf Seiten der Banken gefeiert. Und ja: Auch hier ist eine einheitliche Definition einer Spezifikation sinnvoll aber wieder nur der erste Schritt. (Wobei hinzu kommen wird, dass viele der Spezifikationen im darauf aufbauenden Produkt wieder unterschiedlich interpretiert werden.)

Was bedeutet das: Sowohl Instant Payment als auch PSD2-APIs müssen aus dem Spezifikationsstadium raus, um sich zu eigenen Produkten oder zu Bestandteilen von echten Produkten entwickeln zu können. Das ist die Voraussetzungen für einen erfolgreichen Markteintritt und für entstehende Relevanz. Zwei Beispiele für Spezifikationen aus der Vergangenheit, die erst durch Produkte zum Erfolg wurden:

• MP3
  • Perfektes Beispiel für eine Spezifikation aus dem Fraunhofer-Institut, die aber allein noch kein Produkt war, sondern erst von innovativen Anbietern zu einem echten Markt-Produkt gemacht worden ist.
  • Das Fraunhofer-Institut selbst hat die Grundlage gelegt, aber den Erfolg haben andere ermöglicht wie z.B. Apple mit iTunes und dem iPod.
• HBCI
  • Mitte der 90er von der Deutschen Kreditwirtschaft spezifiziert und mit viel Engagement vorgestellt worden. Leider waren die ersten Produkte auf Basis der Spezifikation so weit weg vom Markt, dass sich HBCI in seiner Ursprungsform (Diskette oder Chipkarte) nie in der Breite hat durchsetzen können. Hier zeigt sich, dass es Sinn machen kann, bereits in der Anfangsphase sehr genau den Markt und seine Bedürfnisse im Blick zu haben und nicht das zu machen, was vermeintlich das sinnvollste und technisch Mögliche ist.
  • Erst mit der Öffnung von HBCI für das marktbeherrschende Sicherungsmedium PIN/TAN und der Umbenennung zu Fin/TS hat das System als Vorläufer einer Bank-API eine echte Nutzung durch den Markt erfahren.
  • Und wichtig ist auch hier, dass nicht Fin/TS das Produkt geworden ist, sondern die Produkte waren und sind ein Banken-Server auf der einen Seite (in der Bank) und Anwendungen wie Apps für den User auf der anderen Seite.

Was ist notwendig, um den angesprochenen Move von der Spezifikation zum Produkt zu schaffen:

• Relevante Marktplayer, die das Thema spannend finden und eine Spezifikation haben wollen um darauf Produkte zu bauen.
• Ein echter Need auf der Nutzerseite, die von den Machern der Produkten auf Basis der Spezifikation adressiert werden können.
• Die Macher der Spezifikation müssen ihre Zielgruppen auf Produkt- und End-User Ebene im Blick haben.
• Ausprobieren, um zu lernen und so schnell und agil notwendige Anpassungen vor allem in der Startphase vornehmen zu können.
• Offenheit gegenüber möglichen Multiplikatoren, um Breitenrelevanz zu erlangen.
• Geringe Einstiegshürden (Testumgebung etc) und gerade im Tech-Umfeld eine sehr Developer-freundliche Denke.

Werbung: Wir bei figo haben es ein Stück weit am eigenen Unternehmen erlebt, was es bedeutet, auf Basis einer Spezifikation (HBCI/FinTS) ein Produkt zu bauen. Sehr klar ist dabei geworden, dass eine Dokumentation einer API (docs.figo.io) maximal der erste kleine Schritt ist, der eigentliche Mehrwert aber in Komponenten drum herum liegt (Betrieb, SDKs, Support, Fehlermapping etc.) und geringe Einstiegshürden sowie aktive Austauschformate unter den Nutzern der Technologie Erfolgsfaktoren sind. Dies ist auch einer der Gründe, warum wir uns entschieden haben, auf Basis der vorhandenen figo- Infrastruktur und Erfahrungen als Banking-API ein neues Produkt für Banken zu bauen – den figo xs2a enabler. Hier werden die in der Entstehung befindlichen PSD2-API-Spezifikationen ein Teil des Produktes sein, aber vor allem sind es die Funktionen drum herum, die das Ganze erst zu einem runden Produkt werden lassen, welches Banken fern der reinen Spezifikationen neue Chancen eröffnet. Dabei bleiben Spezifikationen wie bspw. die der Berlin Group wiederum eine der möglichen Grundlagen. Wer sich in dem Zusammenhang ein eigenes Bild über die Möglichkeiten der PSD2 machen will, dem sei der kommende Bankathon nächste Woche in Berlin ans Herz gelegt – dieser steht unter dem Motto “PSD2 and …?! – Insurance, Identity, Travel, Health und SME”