logo
Bericht von der Front: Erste Erfahrungen aus realen Open-Banking-Projekten

Aus einem Gespräch mit unserem Solution Berater Dr. Michael Thulke 

 

Über Open Banking wird zurzeit viel gesprochen und viel geschrieben. Darüber, wie ein reales Open-Banking-Projekt abläuft, hört man hingegen nur wenig. An welchen konkreten Projekten hat andrion mitgearbeitet?

 

Im ersten Mandat haben wir eine Vorstudie mitsamt Projektsetup für die Einführung einer offenen Integrationsschicht erstellt: Open Integration Layer; mein Chef hat dafür die griffige Abkürzung OIL eingeführt. Diese Integrationsschicht sieht neben Daten- und Messagetransfers auch eine API vor. „Offen“ heisst in diesem Fall, dass auch Systeme aus anderen Divisionen der Bank und externe Systeme hierüber interagieren können. Kunde war eine Schweizer Grossbank und – wie ich gehört habe – ist das Vorhaben inzwischen auch umgesetzt worden.

Im zweiten, aktuell noch laufenden Mandat implementieren wir Open Banking und integrieren es in die Bankensoftware-Lösung des Herstellers DXC Technology, die u. a. bei einer grossen Kantonalbank eingesetzt wird. andrion hat in diesem Projekt den technischen Lead.

Hinzu kommen bei diesem Mandat noch Applikationen von externen Software-Herstellern – zumeist Fintechs –, die daran angedockt werden sollen. Und da fängt es schon an, knifflig zu werden: Denn nur im Idealfall ist seitens API-Provider (das wird die Bank bzw. der Bankensoftwarehersteller sein) nichts anzupassen, wenn eine Fintech-Applikation angedockt werden soll. In der Praxis sieht das aber oft anders aus, insbesondere wenn wir uns mit dem Onboarding von Fintechs noch am Anfang befinden.

 

Was für eine API kommt dort zum Einsatz?

 

Wir stützen uns auf einen Standard, nämlich auf die Swiss NextGen API des Konsortiums OpenBankingProject.ch.

 

Was hat es damit auf sich?

 

Es würde hier zu weit führen, die Initiative OpenBankingProject.ch vorzustellen. Nur so viel: OpenBankingProject.ch hat sich zur Aufgabe gesetzt, Standards im Open Banking zu erarbeiten, die – beispielsweise im Zahlungsverkehr – die Schweizer Spezialitäten mitabdecken. Hierbei hat man den – meiner Ansicht nach – klugen Ansatz gewählt, auf einen schon existierenden Standard aufzusetzen, nämlich auf den Standard der Berlin Group, der im EU-Raum weit verbreitet ist und der wiederum (die im EU-Raum verbindlichen) PSD2-Vorgaben umsetzt.

Für die fachliche Domäne Zahlungsverkehr ist diese Definitionsarbeit abgeschlossen. Die Firma adorsys, ein Softwarehaus aus Nürnberg, hat diese «helvetisierte» Open Banking API implementiert und wir sind nun dabei, diese in die Banken-Software zu integrieren.

 

Was läuft bei einem Open-Banking-Projekt anders als bei einem «normalen» Projekt?

 

Zunächst einmal muss man betonen, dass auch ein noch so innovatives und dynamisches Open-Banking- oder Fintech-Projekt immer noch ein Projekt ist. Und deshalb haben die (vermutlich weniger coolen) Methoden des Projektmanagements auch hier ihre Berechtigung. Aber natürlich gibt es Eigenheiten, z. B. was die Stabilität der Anforderungen betrifft, was die sinnvolle Vorgehensmethode angeht, was das Scope-Management betrifft und so weiter.

 

Was muss man denn punkto Anforderungsstabilität erwarten?

 

Weil das Thema so angesagt ist, werden Sie erleben, dass Personen aus den verschiedensten Bereichen der Organisation neue Ideen haben oder potentielle Fintechs mitbringen, um diese auf Ihre Plattform zu onboarden. Sie brauchen eine Rangliste der potentiellen Fintechs. Sie werden erleben, dass diese Liste recht häufig ändert, dass also – kurz gesagt – auf Ihren Projektscope und sogar auf Ihr Projektziel ständig Änderungswünsche einprasseln.

 

Und wie geht man damit um?

 

Zunächst einmal hilft es, wenn der Projektleiter*) versteht, dass er sich mit seinem Umsetzungsprojekt in einem Spannungsverhältnis befindet: Von aussen kommen ständig neue kreative Änderungswünsche und Ideen, sein Umsetzungsprojekt aber braucht stabile Anforderungen.

Wichtig ist, dass er den Scope und die Stakeholder sauber managt – dafür sollte er sich schon mal Zeit freihalten; und ebenso für die dazu notwendige Kommunikationsarbeit.

Konkret sollte er sich eng mit dem Auftraggeber bzw. dem Business-Projektleiter abstimmen, um beim Projektziel und -scope synchron zu bleiben. Und wenn es zu Changes kommt, diese dann ganz klassisch managen: Impact analysieren und aufzeigen, Entscheid herbeiführen, Entscheid kommunizieren, Pläne/Dokumente/Backlog anpassen. Und ja, das Abwehren von unnötigen Änderungen gehört manchmal auch dazu…

 

Inwieweit besteht das Risiko, dass man Dinge für den Papierkorb produziert?

 

Ja, das ist ein nennenswertes Risiko – wie wohl bei allen Projekten in einem volatilen Umfeld.

In der Frühphase des Projektes besteht die Kunst darin, ein Gespür dafür zu entwickeln, welche Anforderungen am stabilsten sind. Dort haben wir im Projekt angefangen zu arbeiten.

 

Für welche Vorgehensmethode haben Sie sich entschieden?

 

Nur weil Open Banking neu und innovativ ist, heisst das noch lange nicht, dass Sie agil vorgehen müssen. Wie bei jedem Projekt sollte man auch hier anhand der Rahmenbedingungen entscheiden, welches Vorgehen am besten geeignet ist. Auch hilft es sicherlich, wenn Sie in der Wahl Ihrer Liefertermine frei und nicht an starre Release-Raster gebunden sind; und ausserdem ist es völlig unangebracht, schon zu Beginn des Projektes einen Plan mit definiertem Scope und definierten Terminen festzuschreiben – dafür ist, wie ich schon erwähnt habe, das Thema zu volatil.

 

Und was heisst das für das Verhältnis zum Auftraggeber des Projekts?

 

Erläutern Sie ihm ausführlich, dass Sie zu einem guten Teil auf Sicht fliegen müssen. Schlagen Sie ihm auch vor, auf Times&Material-Basis statt auf Festpreis-Basis zu arbeiten – das ist der Situation angemessener.

 

Weitere Empfehlungen?

 

Sehen Sie unbedingt eine Sandbox vor. Unter Sandbox verstehe ich hier ein isoliert laufendes System, das im Kern aus der Open-Banking-API besteht mitsamt einem kleinen Dummy-Corebanking, einem kleinen Dummy-e-Banking, einer Administrationsoberfläche und einem Developer-Portal, das Testdaten und andere Hilfsmittel für Entwickler bereitstellt. Diese «Spielwiese» können dann beispielsweise Fintechs nutzen, um sich mit dem API-Verhalten vertraut zu machen und um zu testen, ob Ihre Applikation sauber mit der API interagiert.

Eine solche Sandbox ist viel schneller bereitgestellt als eine voll integrierte Open-Banking-API, kann also schon sehr frühzeitig genutzt werden. Das reduziert die Anzahl der negativen Überraschungen beim späteren End-to-End-Test.

 

Wie geht es weiter?

 

Wir werden fortfahren, die Open-Banking-API zu implementieren und an das Corebanking-System anzuschliessen. Danach werden wir Fintech-Applikationen onboarden.

Wir sprechen gerade mit dem Testteam. Wenn Sie eine API bauen, benötigen Sie natürlich auch einen Client zum Testen; stellen Sie sicher, dass Sie so etwas verfügbar haben. Und ebenso bietet sich hier Testautomatisierung an.

Auf jeden Fall bleibt die Situation dynamisch – und auch spannend. Wir stossen gerade die Tür auf und ein weites Spektrum von neuen Möglichkeiten liegt vor uns: Anbindung von Buchhaltungssystemen, von Cash-Management-Systemen, Multibanking, neue Bezahllösungen, Banking-as-a-service, etc.

 

– Fortsetzung folgt –

 

*) Wenn hier die männliche Form benutzt wird, so ist damit zugleich auch die weibliche Form gemeint.

Projektmanagement
Open Banking
Banking Standards
Banking API
Cloud
Sandboxes
Bericht von der Front: Erste Erfahrungen aus realen Open-Banking-Projekten
icon_loader