„Bankinterne Strukturen sind die Grundlage für erfolgreiche APIs.“
Jasmin Sessler via Pixabay
Joris Hensen, Gründer des API-Programms, erklärt im Interview mit IT-Finanzmagazin die Technologie hinter den APIs und wie sie die Prozesse und Strukturen in der Finanzbranche und in Unternehmen unausweichlich verändern – für mehr Geschwindigkeit und ein besseres Nutzererlebnis über Branchen und Industrien hinweg.
Herr Hensen, zunächst der Kontext: Welche Vorteile ergeben sich für Banken, Partnerunternehmen und Konsumenten generell durch Embedded Finance?
Dank Embedded Finance können Unternehmen Finanzprodukte oder -dienstleistungen direkt in ihre eigenen digitalen Angebote integrieren. Das ist heute wichtiger denn je, denn für Verbraucherinnen und Verbraucher ist es inzwischen fast selbstverständlich, dass Zahlungen, Kredite und andere Finanzdienstleistungen nahtlos in ihre Lieblings-Apps eingebettet sind, sprich genau dort, wo sie die Dienste gerade benötigen. Wir sehen hier großes Potenzial. Der Embedded-Finance-Markt wird bis 2030 voraussichtlich ein Volumen von 7,2 Billionen US-Dollar erreichen – das entspricht dem Gesamtwert der 30 weltweit größten Banken.
Es gibt verschiedene Architekturstile und Technologien wie REST, GraphQL oder SOAP. Welche sollten beim Aufbau von API-Plattformen zum Einsatz kommen?
Wir haben uns für RESTful-APIs über HTTP mit JSON-Nachrichten entschieden. REST ist eine Architektur, die gut über HTTP funktioniert und auf Einfachheit, gute Skalierung und eine Entkoppelung von Client und Server setzt. REST ist weit verbreitet und mit vielen Programmiersprachen kompatibel, das macht es für uns ideal. Unsere API-Endpunkte repräsentieren immer JSON-Datenobjekte, die mit HTTP-Standardmethoden wie GET, POST, PUT oder PULL abgerufen werden können.
GraphQL ist hingegen für komplexe und dynamische Datenabfragen interessant, beispielsweise wenn zur Laufzeit Abfragen individuell angepasst werden, um die Datenmenge zu verkleinern oder zu vergrößern. Diese Dynamik macht es möglich, auch komplexe Datenbeziehungen zu steuern.”
SOAP ist wiederum ein Protokoll, das einen Standard für einen strukturierten Informationsaustausch zwischen Web-Services mittels XML definiert. Man findet es häufig in Enterprise-Umgebungen im Zusammenspiel mit Legacy-Systemen. SOAP-APIs sind allerdings meist komplexer als andere Alternativen und deshalb bei Neuentwicklungen eher nicht die erste Wahl.
Darüber hinaus existieren noch weitere Ansätze mit spezifischen Stärken – es hängt also vom konkreten Anwendungsfall ab, welche API-Architektur gewählt werden sollte..
Und wie muss man sich die Entwicklung von Apps mit APIs in der Praxis vorstellen? Geht das immer vom jeweiligen Fintech oder der Bank aus?
Tatsächlich kommen immer mehr Unternehmen von selbst auf uns zu, weil sie erkannt haben, was für ein Wertschöpfungspotenzial in unseren Daten steckt. Wir gehen aber auch proaktiv auf den Markt und machen beispielsweise über unser Developer-Portal oder über Produktseiten auf uns aufmerksam, etwa indem wir bestehende oder potenzielle Use Cases vorstellen.
Durch Embedded Finance entsteht insgesamt eine neue Art der Zusammenarbeit zwischen den Beteiligten, sowohl innerhalb einer Organisation als auch nach außen. Es ist zum Beispiel wichtig, dass wir bereits bei der Entwicklung unserer APIs gemeinsam mit Partnern prüfen, welche Bedürfnisse bei den Endkunden bestehen und welche Anwendungsfälle sich daraus ergeben.
Was ist die Grundlage dieser Zusammenarbeit und wie gestaltet sich das Produktmanagement?
Embedded Finance macht es erforderlich, dass verschiedene Bereiche Hand in Hand arbeiten und IT und Geschäftsbereiche eng verzahnt sind. Für eine reibungslose Zusammenarbeit benötigen Banken deshalb eine möglichst unternehmensweite API-Plattform. Das Ziel ist es, die einzelnen Komponenten eines Finanzprodukts als Bausteine zu entwickeln und für unterschiedliche Zwecke wiederzuverwenden. Dann können zum Beispiel einzelne Module einer digitalen Kontoeröffnung auch für die Entwicklung einer neuen Kreditkartenstrecke genutzt werden.
So verändert Embedded Finance auch das Produktmanagement. Die Rolle des Produktmanagers wird technischer und die Fähigkeiten der Teams umfassender.”
Und während früher Bankdienste meist durch Vertriebspartner in wenige ausgewählte Angebote integriert wurden, gibt es zukünftig eine deutlich größere Zahl von Märkten, Produkten und Partnern. Banken nutzen interne Technologien bewusster, was spannende Perspektiven und Chancen für die Produktbereiche mit sich bringt..
Wie sieht denn die rechtliche Lage bei hier entstehendem Code aus? Gibt es da eine Art Datenbank und einen Austausch oder wem gehört das Produkt?
An dieser Stelle müssen wir unterschiedliche Szenarien unterscheiden. Wenn sich ein Partner für die reine Integration unserer Bankdaten entscheidet, um seinen Kunden damit mehr Funktionalität zu bieten, schließen wir eine Nutzungsvereinbarung für die Daten. Das Urheberrecht liegt in diesem Fall beim Partner. Möchte der Partner unsere Produkte vertreiben oder hat Interesse an einer engeren und gemeinsamen Produktgestaltung, dann greifen unsere Partnerschaftsverträge. In diesen werden die jeweiligen Eigentumsrechte, aber auch die Verpflichtungen der Vertragsparteien im Einzelnen geklärt. Generell versuchen wir, diese Prozesse im Sinne eines schnellen Onboardings so schlank wie möglich zu gestalten, und wir halten die Vereinbarungen mit den Kunden auf unserer Plattform nach.
Deutsche Bank
Joris Hensen hat das API-Programm der Deutschen Bank Anfang 2015 mitbegründet. In seiner mehr als zehnjährigen Tätigkeit für die Deutsche Bank war er als Projekt- und Innovationsmanager in verschiedenen internationalen Projekten tätig. Joris Hensen versteht sich als Intrapreneur und widmet sich der Frage, wie Open-Banking- und Embedded-Finance-Lösungen das Leben der Menschen verändern und verbessern können.
Haben Sie ein paar spannende Beispiele, was derzeit für Apps mit Hilfe Ihrer API entstehen und sehen Sie da Trends??
Ein konkreter Anwendungsfall ist Finanzguru, ein Start-up, in das wir auch selbst investiert haben. Die Finanzguru-App ist ein persönlicher Finanzassistent, in dem die Nutzer automatisch eine Übersicht über ihre Einnahmen und Ausgaben erhalten, ihr Finanzverhalten analysieren und Budgets erstellen können. Auch Verträge erkennt Finanzguru automatisiert und bietet neben Wechselvorschlägen und Spartipps die Möglichkeit, sie direkt aus der App heraus zu kündigen.
Ein weiteres Beispiel ist die Kooperation zwischen Eintracht Frankfurt und der Deutschen Bank. Der Fußball-Bundesligist hat eine digitale Geldbörse in seine vereinseigene App „mainaqila“ integriert. Damit können Fans ihre virtuelle Eintracht-Frankfurt-Karte an rund 70 Millionen Standorten weltweit einsetzen. Die technische Grundlage hierfür ist unsere „Decoupled Wallet“, eine White-Label-Payment-Lösung, die Unternehmen einfach in ihre mobilen Anwendungen integrieren können.
Gerade haben wir auch eine neue API entwickelt, mit der Drittanbieter eine Kreditantragsstrecke für mittelgroße Unternehmen integrieren können. Plattformen für Unternehmenskunden können den Prozess für die Kreditvergabe in Zukunft direkt online nahtlos und ohne Medienbruch anbieten.
Grundlage für Embedded Finance ist die EU-Richtlinie zur Regulierung von Zahlungsdiensten und Zahlungsdienstleistern PSD2 beziehungsweise deren Weiterentwicklung in Form der anstehenden PSD3. Welche Erfahrungen haben Sie im Embedded-Finance-Kontext sammeln können und welche Features wünschen Sie sich diesbezüglich für die Weiterentwicklung?
Mit der PSD2 wurde die rechtliche Grundlage für einen immer intensiveren Datenaustausch zwischen Unternehmen und Finanzinstituten geschaffen – und das über Landesgrenzen hinweg. Nun liegt auch der Entwurf der Europäischen Kommission zum Open-Finance-Framework vor. Dieser Vorschlag enthält eine weitere Öffnung von Daten, für deren Nutzung auch Preismodelle eingeführt werden können. Für uns ist es interessant zu sehen, dass dies genau dem Ansatz folgt, den wir mit unserem API-Programm von Anfang an gewählt haben, nämlich Datenprodukte zu entwickeln, die weit über die regulatorischen Vorgaben von PSD2 hinausgehen. Aus diesem Angebot an Premium-APIs können sich unsere Partner schon heute bedienen.
Doch bei aller Regulatorik sollten wir nicht vergessen, dass Embedded-Finance-Produkte letztlich darauf beruhen, bankintern flexible und nahtlos digitalisierte Prozesse aufzubauen. Und genau darin liegt die Herausforderung.”
Wenn wir nach vorne schauen, wird es sicherlich spannend, das bestehende Portfolio weiter auszubauen und zu ergänzen – sei es rund um grundlegende Bankprodukte, datenbasierte Mehrwertdienste oder spezielle Angebote wie Risiko- oder Kontrollprozesse.
Was mich jetzt noch interessiert: Wie kann eine Bank schließlich die Absprungrate seitens der Kunden reduzieren – oder kurz: Wie schafft man Vertrauen?
Ein erfolgreiches Embedded-Finance-Modell basiert meiner Meinung nach etwa zur Hälfte auf den technischen Grundlagen. Bei den restlichen 50 Prozent geht es zum einen darum, durch einen intensiven Kurationsprozess sicherzustellen, dass wir nur vertrauenswürdige Partner anbinden.
Es geht aber auch darum, den Kundinnen und Kunden einen echten Mehrwert mit einer optimalen Nutzererfahrung zu bieten. Banken und ihre Partnerunternehmen müssen sich dafür frühzeitig gegenseitig in den Entwicklungsprozess einbeziehen und die Bedürfnisse und „Schmerzpunkte“ der Konsumentinnen und Konsumenten genau identifizieren.”
Für die ersten Tests muss nicht zwingend schon eine technische Umsetzung stattfinden. Vielmehr geht es darum, Hypothesen frühzeitig zu validieren und den weiteren gemeinsamen Entwicklungsprozess anhand dieser Erkenntnisse auszurichten. Nur so wird eine langfristige Zusammenarbeit für beide Seiten gewinnbringend und schafft für unsere Kundinnen und Kunden wertvolle und relevante Produkte.
Herzlichen Dank für das Gespräch! tw
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/155290
Schreiben Sie einen Kommentar