Open Banking in der DACH-Region: Über die PSD2-Compliance hinaus

Open Banking in der DACH-Region hat seit der erstmaligen Umsetzung der Kontenzugangsbestimmungen der PSD2 eine erhebliche Transformation durchlaufen. Was als regulatorische Compliance-Übung begann – Banken, die widerwillig APIs öffneten, um ihren Pflichten nach Art. 65-67 PSD2 nachzukommen – entwickelt sich zu einem genuinen Ökosystem datengetriebener Finanzdienstleistungen. Die Entwicklung unterscheidet sich jedoch deutlich von der britischen Erfahrung, geprägt durch unterschiedliche Marktstrukturen, regulatorische Ansätze und Verbrauchereinstellungen in Deutschland, Österreich und der Schweiz.

Das Verständnis dieser Landschaft ist für jedes Fintech-Unternehmen relevant, das einen DACH-Markteintritt oder eine Expansion plant, denn der Unterschied zwischen einem compliance- und einem kundengetriebenen Open-Banking-Ansatz entscheidet oft darüber, ob ein Produkt bedeutende Skalierung erreicht. Die technischen Schnittstellen allein sind der Startpunkt; die eigentliche Arbeit liegt darin, rohen Datenzugriff in belastbare, differenzierte Wertversprechen zu überführen.

Das PSD2-Fundament

Die PSD2 (Richtlinie (EU) 2015/2366), in deutsches Recht durch das Zahlungsdiensteaufsichtsgesetz (ZAG) und in österreichisches Recht durch das ZaDiG 2018 umgesetzt, führte zwei neue Kategorien regulierter Zahlungsdienstleister ein: Kontoinformationsdienstleister (AISPs) und Zahlungsauslösedienstleister (PISPs). Banken – als kontoführende Zahlungsdienstleister (ASPSPs) – wurden verpflichtet, dedizierte Schnittstellen bereitzustellen, die diesen Drittanbietern mit ausdrücklicher Zustimmung des Kunden den Zugang zu Zahlungskontodaten und die Auslösung von Zahlungen ermöglichen. Ein dritter Dienst, die Kontodeckungsabfrage für kartenausgebende Zahlungsdienstleister (CBPII), steht als engerer Baustein neben den beiden Hauptdiensten.

Die Technischen Regulierungsstandards (RTS) der Europäischen Bankenaufsichtsbehörde (EBA) zur starken Kundenauthentifizierung und zur gemeinsamen und sicheren Kommunikation, verabschiedet als Delegierte Verordnung (EU) 2018/389 und anwendbar seit September 2019, definierten die technischen Anforderungen an diese Schnittstellen. In der Praxis war die anfängliche Qualität der Bank-APIs in der DACH-Region uneinheitlich. Viele Institute implementierten die minimal erforderliche Schnittstelle, was Reibung für Drittanbieter erzeugte und den praktischen Nutzen der regulatorischen Zugangsrechte einschränkte.

Die drei PSD2-Dienste

Der Kontoinformationsdienst (AIS) erlaubt lizenzierten Anbietern die Aggregation von Kontodaten mehrerer Banken – Grundlage für Anwendungsfälle von Personal Financial Management bis zur Kreditwürdigkeitsprüfung. Der Zahlungsauslösedienst (PIS) erlaubt die direkte Auslösung von Überweisungen vom Konto des Kunden und kann in einzelnen Fällen die Kosten der Zahlungsakzeptanz für Händler reduzieren. Der Dienst Kontodeckungsabfrage liefert eine einfache Ja/Nein-Bestätigung darüber, ob ausreichend Deckung für eine Kartentransaktion besteht.

Der deutsche Markt: Größe, Fragmentierung und das FinTS-Erbe

Die deutsche Bankenlandschaft stellt für Open Banking gleichermaßen Chance und Herausforderung dar. Mit mehr als 1.300 Kreditinstituten – darunter große Geschäftsbanken, öffentlich-rechtliche Sparkassen, genossenschaftliche Volksbanken und Raiffeisenbanken sowie eine Vielzahl spezialisierter Institute – bietet der Markt enormes Datenpotenzial, erfordert aber Integrationen über eine fragmentierte Landschaft von IT-Systemen und API-Implementierungen. Jede der Bankensäulen hat ihren eigenen IT-Dienstleister, eine eigene Governance und einen eigenen Veröffentlichungszyklus für APIs.

Schon vor PSD2 hatte Deutschland mit FinTS (Financial Transaction Services) – dem direkten Nachfolger von HBCI – einen eigenen nationalen Standard für den Kontozugriff durch Drittsoftware aufgebaut. FinTS erlaubt es Kunden, mit Drittanbieter-Software auf ihre Konten zuzugreifen, abhängig von der bankspezifischen PIN/TAN-Authentifizierung. Nach PSD2 bestehen FinTS und PSD2-APIs nebeneinander, mit unterschiedlichen Nutzungsprofilen: FinTS bleibt in Personal-Finance-Software mit etablierter Nutzerbasis verbreitet, während PSD2-APIs zum Standard für neue Fintech-Markteinsteiger geworden sind.

NextGenPSD2 als dominanter API-Standard

Das NextGenPSD2-Framework der Berlin Group hat sich als dominierender API-Standard im deutschen Markt durchgesetzt, übernommen von der Mehrheit deutscher Banken entweder direkt oder über ihre IT-Dienstleister – Finanz Informatik für den Sparkassen-Sektor und Atruvia für Genossenschaftsbanken. Diese Standardisierung hat die Interoperabilität gegenüber der frühen Post-PSD2-Phase deutlich verbessert, obwohl Implementierungsunterschiede bestehen bleiben. Drittanbieter müssen weiterhin kleine, aber relevante Unterschiede in der Interpretation optionaler Felder, im Umgang mit Grenzfällen und in der Gestaltung der Einwilligungsflows berücksichtigen.

Kontoaggregation hat sich als reifster AIS-Anwendungsfall etabliert. Mehrere deutsche Fintech-Unternehmen bieten Multibank-Kontoüberblicke für Privat- und Geschäftskunden und treiben Dashboards, Personal-Finance-Tools und Buchhaltungsintegrationen an. Zahlungsauslösung, obwohl technisch ermöglicht, hat eine langsamere Adoption erfahren – was sowohl Verbraucherpräferenzen für etablierte Zahlungsmethoden (insbesondere SEPA-Lastschriften und die Girocard) als auch verbleibende Reibung im Prozess der starken Kundenauthentifizierung (SCA) bei ausgelösten Zahlungen widerspiegelt.

Österreich: Spiegelregime mit kleinerem Markt

Die österreichische Open-Banking-Landschaft spiegelt angesichts der gemeinsamen PSD2-Rechtsgrundlage im Wesentlichen den deutschen Regulierungsrahmen wider. Österreichische Banken haben dedizierte Schnittstellen über das ZaDiG 2018 implementiert und überwiegend den NextGenPSD2-Standard übernommen. Der Markt unterstützt eine wachsende Zahl von AISP- und PISP-lizenzierten Anbietern, doch die geringere Marktgröße bedeutet, dass die Erreichung kommerzieller Skalierung allein in Österreich herausfordernd ist. Die meisten Anbieter operieren grenzüberschreitend und kombinieren österreichischen Datenzugriff mit einer breiteren DACH- oder EU-Strategie.

Die strukturelle Überlappung zwischen dem österreichischen und deutschen Bankensektor – Genossenschaftsbanken, Regionalbanken und große Geschäftsinstitute – bedeutet, dass Unternehmen, die die technische Integration für Deutschland gelöst haben, oft mit moderatem Zusatzaufwand nach Österreich expandieren können. Umgekehrt kann Österreich als risikoärmeres Testfeld für einen kleineren Rollout dienen, bevor man sich der vollen Komplexität des deutschen Marktes stellt.

Schweiz: Ein freiwilliger Entwicklungspfad

Die Position der Schweiz ist grundlegend anders. Als Nicht-EU/EWR-Mitglied gilt die PSD2 nicht. Es gibt kein regulatorisches Mandat für Schweizer Banken, Drittanbieter-API-Zugang bereitzustellen. Open Banking in der Schweiz wird daher ausschließlich durch Marktkräfte und freiwillige Initiativen getrieben. Die Schweizerische Bankiervereinigung und die Initiative OpenBankingProject.ch haben die API-Standardisierung gefördert, aber die Adoption bleibt freiwillig und im Markt ungleichmäßig.

SIX – der Betreiber der Schweizer Finanzmarktinfrastruktur – hat mit Schweizer Banken an gemeinsamen API-Definitionen gearbeitet, insbesondere für Zahlungsauslösung und Kontoinformation. Mehrere größere Schweizer Banken haben API-Programme für ausgewählte Partner entwickelt, vorwiegend im Wealth Management, Asset Management und Corporate Banking. Das breite, verbraucherorientierte Open-Banking-Ökosystem, wie es in Großbritannien existiert oder in Deutschland entsteht, hat sich in der Schweiz jedoch nicht materialisiert. Wo Zugang besteht, beruht er meist auf bilateralen kommerziellen Vereinbarungen statt auf standardisiertem offenem Zugriff.

PSD3, PSR und der vorgeschlagene FiDA-Rahmen

Die Europäische Kommission hat im Juni 2023 die PSD3 (eine überarbeitete Richtlinie) und die Zahlungsdienste-Verordnung (PSR) vorgeschlagen; am 27. November 2025 haben sich Parlament und Rat vorläufig auf beide Texte geeinigt, die förmliche Verabschiedung steht noch aus. Das Paket entwickelt das Open-Banking-Rahmenwerk erheblich weiter. Parallel hat die Kommission die Financial Data Access (FiDA) Verordnung vorgeschlagen, die Datenzugangspflichten über Zahlungskonten hinaus auf eine breitere Palette von Finanzprodukten ausdehnen würde. Wesentliche Änderungen mit Relevanz für den DACH-Markt umfassen:

• Eine Pflicht für Banken, ein permanentes „Dashboard“ bereitzustellen, über das Kunden Drittanbieter-Zugriffsberechtigungen zentral verwalten können
• Erweiterte API-Leistungsanforderungen, einschließlich vorgeschriebener Verfügbarkeits- und Antwortzeitstandards, um die unter PSD2 entstandene uneinheitliche Erfahrung zu beseitigen
• Ausweitung des Datenzugangs über Zahlungskonten hinaus auf Sparkonten, Hypotheken, Anlageprodukte und Altersvorsorgeprodukte im Rahmen der vorgeschlagenen FiDA-Verordnung
• Verschärftes Verbot von Hindernissen beim Kontozugang mit klareren Durchsetzungsmechanismen für nationale Aufsichtsbehörden
• Ausdehnung der Empfängerüberprüfung (IBAN-Namensabgleich), die für Euro-Überweisungen im Euroraum bereits seit dem 9. Oktober 2025 nach der Instant-Payments-Verordnung Pflicht ist, auf alle übrigen Überweisungen
• Ein klareres Haftungsrahmenwerk, das Verluste zwischen Zahlern, Banken und Drittanbietern in SCA-bezogenen Streitfällen verteilt

Diese Regeln werden nach ihrer förmlichen Verabschiedung erheblichen Umsetzungsaufwand von Banken und Drittanbietern in Deutschland und Österreich erfordern. Die erweiterte Datenabdeckung unter FiDA könnte insbesondere die Bandbreite tragfähiger Open-Banking-Anwendungsfälle deutlich erweitern und die Grenze zwischen Open Banking und dem breiteren Paradigma „Open Finance“ verwischen. Unternehmen sollten mit einer mehrjährigen Übergangsphase rechnen, nicht mit einem einzelnen Stichtag.

Haftung und Verbraucherschutz

Das Haftungsrahmenwerk der PSD2 – in Deutschland umgesetzt über die §§ 675u bis 675z BGB – verteilt die Verantwortung für nicht autorisierte oder fehlerhafte Zahlungstransaktionen zwischen dem Zahler, der kontoführenden Bank und beteiligten Drittanbietern. Grundsätzlich ist die Bank des Zahlers verpflichtet, eine nicht autorisierte Transaktion unverzüglich zu erstatten und Regress gegenüber anderen Beteiligten zu suchen. Dieses verbraucherfreundliche Rahmenwerk ist eine wichtige Vertrauensgrundlage für Open Banking, da Kunden wissen, dass die Auslösung einer Zahlung über einen lizenzierten PIS-Anbieter ihre Rechte nicht beeinträchtigt.

Der BGB-Rahmen verteilt die Schadenstragung auch in Fällen grober Fahrlässigkeit des Zahlers – etwa das Aufschreiben einer PIN oder die Weitergabe eines SCA-Codes – und setzt klare Grenzen für die Haftung des Kunden in Konstellationen ohne grobe Fahrlässigkeit. Diese Regeln sind ein zentraler Treiber für das Verbrauchervertrauen in Open Banking, weil sie sicherstellen, dass die Komplexität zwischen Zahler, Bank und Drittanbieter nicht in Unklarheit darüber umschlägt, wer den Kunden letztlich entschädigt. AISPs und PISPs müssen gleichwohl robuste operative und sicherheitsrelevante Kontrollen unterhalten, denn ihre Haftung gegenüber der kontoführenden Bank – und letztlich gegenüber dem Kunden – kann erheblich sein, wenn der Drittanbieter das Problem verursacht hat.

Datenumfang: Zahlungskonten und der Schritt zu Financial Data Access

Unter der PSD2 ist der Anwendungsbereich des verpflichtenden Datenzugangs eng: Er bezieht sich auf „Zahlungskonten“ im Sinne der Richtlinie, was in erster Linie Girokonten und Konten umfasst, die zur Ausführung von Zahlungstransaktionen genutzt werden. Sparkonten, Anlagekonten und Hypothekenkonten liegen in der Regel außerhalb dieses Rahmens; bei Kreditkartenkonten kommt es darauf an, ob über das Konto Zahlungen an Dritte ausgeführt und von Dritten empfangen werden können (EBA Q&A 2019_4856). Für DACH-Banken bedeutet das praktisch, dass ein erheblicher Teil der Finanzdaten ihrer Kunden in Silos verbleibt und für Drittanbieter nicht zugänglich ist, solange keine separaten kommerziellen Schnittstellen bereitgestellt werden.

Die vorgeschlagene FiDA-Verordnung würde dies durch einen breiteren Rahmen für Financial Data Access ändern, der eine deutlich größere Bandbreite an Finanzdatentypen abdeckt. Nach dem Vorschlag wären regulierte Finanzinstitute verpflichtet, autorisierten „Financial Information Service Providern“ maschinenlesbaren Zugang zu einem definierten Satz von Kundendaten zu gewähren, sobald eine Einwilligung des Kunden vorliegt. Das Rahmenwerk ist so gestaltet, dass es die PSD2 in ihrer Einwilligungsgrundlage spiegelt, den Datenumfang aber deutlich über Zahlungskonten hinaus erweitert.

Für Fintechs sind die Auswirkungen erheblich. Dieselben Architekturen und Zulassungskategorien, die heute PSD2-Anwendungsfälle tragen, dürften für FiDA erweitert und angepasst werden. Unternehmen, die bereits verlässliche, konforme Integrationen in den deutschen, österreichischen und (freiwillig) schweizerischen Bankensektor betreiben, werden gut positioniert sein, um FiDA-basierte Datenquellen hinzuzufügen, sobald die Verordnung anwendbar wird. Der Zeitpunkt des Inkrafttretens von FiDA hängt vom Gesetzgebungsprozess ab, doch Unternehmen sollten mit einer mehrjährigen Übergangsphase planen, nicht mit einem einzelnen Stichtag.

Regulatorische Sandboxes und Testumgebungen

In Deutschland betreibt die BaFin keine regulatorische Sandbox; Österreich hat seit dem 1. September 2020 eine gesetzlich verankerte Regulatory Sandbox bei der FMA (§ 23a FMABG). Beide Jurisdiktionen bieten zudem Wege für einen frühen aufsichtlichen Dialog. Die BaFin ermutigt Unternehmen, sich früh im Zulassungsprozess an sie zu wenden, und hat Hinweise zu ihren Erwartungen an AISP- und PISP-Antragsteller veröffentlicht. In Österreich verfolgt die FMA einen vergleichbar offenen Ansatz in Bezug auf frühe Gespräche. Schweizer Unternehmen operieren in einem anderen Umfeld, doch der Fintech-Desk der FINMA bietet einen beratenden Kanal für Unternehmen, die die aufsichtliche Sicht auf neuartige Geschäftsmodelle verstehen möchten.

Neben aufsichtlichen Sandboxen spielen die technischen Testumgebungen der Banken und ihrer IT-Dienstleister in der Praxis eine große Rolle. Die Fähigkeit eines Fintechs zur effizienten Integration hängt von Qualität, Stabilität und Abdeckung dieser Testumgebungen ab. Produktionsparität, realistische Testdaten und reaktionsschnelle Support-Kanäle entscheiden über den Unterschied zwischen einem reibungslosen Rollout und einem langgezogenen Integrationsprogramm. Unternehmen sollten diese Aspekte in ihre Anbieterbewertung und Projektplanung einfließen lassen.

Technische Integrationsrealität

Auch mit einem dominanten Standard wie NextGenPSD2 ist die Integration über die deutschen Bankensäulen hinweg keine einheitliche Erfahrung. Unterschiede entstehen im Umgang mit Grenzfällen: teilweise Transaktionshistorien, schwebende Transaktionen, Währungsumrechnungen, Gemeinschaftskonten, Geschäftskonten mit mehreren Zeichnungsberechtigten und Konten mit ungewöhnlichen Saldostrukturen. Auch die Qualität der Fehlermeldungen variiert erheblich, was direkt beeinflusst, wie schnell Drittanbieter Produktionsstörungen diagnostizieren und beheben können.

Die Mechanik der Einwilligungsflows unterscheidet sich ebenfalls. Banken haben verschiedene Varianten des SCA-Prozesses für AIS und PIS implementiert – redirect-basierte Flows, entkoppelte Flows und eingebettete Flows. Drittanbieter müssen in der Regel mehrere Flow-Typen unterstützen, um eine möglichst breite Marktabdeckung zu erreichen. Die Auswirkungen auf die Nutzererfahrung sind erheblich: Ein gut gewählter Flow kann die Conversion bei der Zahlungsauslösung deutlich verbessern, während ein schlecht gewählter Flow den Dienst praktisch unbenutzbar machen kann.

Reauthentisierung: von 90 auf 180 Tage

Nach den ursprünglichen RTS war beim Zugriff über einen Kontoinformationsdienst alle 90 Tage eine neue starke Kundenauthentifizierung nötig. Seit dem 25. Juli 2023 gilt die geänderte Fassung (Delegierte Verordnung (EU) 2022/2360, neuer Art. 10a der RTS): Banken müssen beim Zugriff über Kontoinformationsdienste auf die starke Kundenauthentifizierung verzichten, solange seit der letzten nicht mehr als 180 Tage vergangen sind. Künftige Reformen im Rahmen von PSD3/PSR könnten die Regeln erneut verändern. Praktisch bedeutet das, dass Unternehmen, die auf langlebigen Datenzugang angewiesen sind (etwa Buchhaltungsplattformen oder Multibank-Treasury-Tools), Reauthentisierungsflows bauen müssen, die Nutzerreibung minimieren und zugleich konform bleiben.

API-Performance, Verfügbarkeit und das Zuverlässigkeitsproblem

Selbst bei reifen APIs bleibt Zuverlässigkeit ein relevantes Thema. In verkehrsintensiven Einzelhandelsphasen oder zu Monatsenden bei Geschäftskunden zeigen manche Bank-APIs erhöhte Latenzen oder echte Ausfälle. Diese Vorfälle kaskadieren: Eine langsame AIS-Antwort wird zum langsamen Dashboard für Endkunden, während PIS-Ausfälle unmittelbar zu fehlgeschlagenen Zahlungen am Händler-Checkout führen. Drittanbieter müssen Fallback-Strategien, ein geordnetes Degradationsverhalten und klare Fehlermeldungen gestalten, um das Nutzervertrauen auch unter schwierigen Bedingungen zu wahren. PSD3/PSR dürfte die Leistungsanforderungen an Banken verschärfen und die Häufigkeit solcher Störungen über die Zeit reduzieren.

Von Open Banking zu Open Finance: Die Anwendungsfall-Landschaft

Mit der Reifung des Ökosystems erweitert sich der Kreis tragfähiger Anwendungsfälle über die ursprünglichen PSD2-Dienste hinaus. Frühe Adoption konzentrierte sich auf Kontoaggregation für Consumer-PFM und Multibank-Business-Dashboards. Die zweite Welle expandierte in automatisierte Buchhaltung, Steuervorbereitung und KMU-Kreditwürdigkeitsprüfung, wo Transaktionsdaten ein reicheres Signal liefern als traditionelle Bonitätsdaten allein.

Neuere Anwendungsfälle umfassen Embedded-Finance-Integrationen mit nicht-finanziellen Plattformen (E-Commerce, Marktplätze, Immobilienverwaltung), Treasury-Management- und Cash-Visibility-Tools für mittelständische Unternehmen sowie auf Zahlungsauslösung basierende Checkout-Erfahrungen, die kostenseitig mit Karten-Flows konkurrieren. Der Schritt zu Open Finance – über FiDA – wird dieses Muster auf Investment-Analysen, Altersvorsorge-Aggregation und differenziertere Versicherungsdistribution ausdehnen.

Kreditscoring und KMU-Underwriting

Transaktionsdaten sind besonders wertvoll im KMU-Underwriting, wo traditionelle Bonitätssignale dünn oder veraltet sein können. Ein Zwölfmonatsblick auf Cashflow, Saisonalität, Kundenkonzentration und Zahlungsverhalten kann die Kreditentscheidung für kleine Unternehmen erheblich verbessern. Der Haken: Unternehmen, die Open-Banking-Daten für Kreditentscheidungen nutzen, fallen in den Anwendungsbereich sektorspezifischer Regulierung und – sofern die Entscheidung KI-gestützt ist und eine natürliche Person betrifft, etwa einen Einzelunternehmer oder Freiberufler – auch in die Hochrisikoklasse des EU AI Act für Kreditwürdigkeitsprüfungen (Anhang III Nr. 5 Buchst. b); die Bonitätsprüfung juristischer Personen erfasst diese Klasse nicht. Governance, Erklärbarkeit und menschliche Aufsicht müssen von Beginn an mitgedacht werden.

Treasury und Cash Management für Unternehmen

Mittelständische Unternehmen mit mehreren Bankbeziehungen profitieren erheblich von Multibank-Cash-Visibility und automatisierter Abstimmung auf Basis von Open Banking. Der Business Case ist klar: Reduktion manuellen Aufwands für das Herunterladen und Konsolidieren von Auszügen, Beschleunigung des Monatsabschlusses und Entlastung der Finanzteams für höherwertige Arbeit. Für Fintechs, die dieses Segment bedienen, liegt die Herausforderung weniger im reinen Datenzugriff (den die PSD2 als gesetzlichen Anspruch vorsieht) als in der Bereitstellung einer enterprise-tauglichen Nutzererfahrung, der Integration mit ERP- und Buchhaltungsplattformen und robusten Sicherheits- und Audit-Kontrollen auf dem Niveau, das große Unternehmen erwarten.

Kommerzielle Modelle jenseits des verpflichtenden Zugangs

Eine wichtige Unterscheidung liegt zwischen dem nach PSD2 kostenfrei verpflichtenden Zugang zu Zahlungskonten und den kommerziellen Premium-APIs, die einige Banken zusätzlich anbieten. Wo ein Fintech Daten oder Fähigkeiten jenseits der PSD2-Baseline benötigt – reichere Transaktions-Metadaten, Zugriff auf Nicht-Zahlungskonten, geringere Latenzen oder erweiterte Fehlerbehandlung – können kommerzielle Vereinbarungen erforderlich sein. Diese unterliegen nicht dem PSD2-Rahmen, sondern dem allgemeinen Vertragsrecht. Unternehmen, die produktionsreife Dienste planen, sollten früh prüfen, welche Anwendungsfälle mit dem verpflichtenden Zugang abgedeckt sind und welche ausgehandelte kommerzielle Vereinbarungen erfordern.

Praktische Umsetzungshinweise

Fintechs, die in den DACH-Open-Banking-Markt eintreten, sollten einen überlegten, phasenweisen Ansatz planen. Die erste Phase umfasst die Erlangung und Aufrechterhaltung der passenden Erlaubnis als Zahlungsauslösedienst oder Registrierung als Kontoinformationsdienst (§§ 10, 34 ZAG; oder der entsprechenden Ausnahme, wo relevant), was ein operatives Programm, IT-Governance-Dokumentation und einen Nachweis der Berufshaftpflichtversicherung erfordert. Die zweite Phase ist die technische Integration – typischerweise mit den großen Bankensäulen beginnend, dann in den Long Tail hinein. Die dritte Phase ist die Produktdifferenzierung: rohen Datenzugriff in ein Wertversprechen zu überführen, das ein konkretes Kundenproblem besser löst als jede Alternative.

Über alle drei Phasen hinweg sollten Unternehmen ihre regulatorische, technische und kommerzielle Arbeit als ineinandergreifend und nicht sequentiell verstehen. Regulatorische Entscheidungen (etwa Lizenzumfang, geografische Reichweite und Passporting-Strategie) prägen unmittelbar, welche Banken und Kundensegmente das Unternehmen adressieren kann. Technische Entscheidungen (Integrationspartner, API-Strategie, Design der Einwilligungsflows) bestimmen die Kosten für das Hinzufügen neuer Banken und die Qualität der Nutzererfahrung. Kommerzielle Entscheidungen (Preisgestaltung, Zielsegmente, Vertriebskanäle) entscheiden darüber, welche regulatorischen und technischen Entscheidungen sich schließlich auszahlen.

Fazit: Open Banking als Infrastruktur für eine neue Servicegeneration

Open Banking in der DACH-Region ist längst keine Compliance-Geschichte mehr, sondern eine Infrastrukturgeschichte. Die Unternehmen, die es als solche behandeln – und in robuste Integrationen investieren, den Regulierungsrahmen ernst nehmen und Produkte bauen, die den angebotenen Datenzugang wirklich nutzen – werden das nächste Jahrzehnt der Finanzdienstleistungen in Deutschland, Österreich und der Schweiz prägen. Diejenigen, die es als Pflichtübung betrachten, werden ihre Kunden und ihre Aufsichtsbehörden gleichermaßen weiterhin enttäuschen.

Der wichtigste strategische Hebel in den nächsten Jahren dürfte die Verbindung zwischen Open-Banking-Daten und der breiteren Open-Finance-Welt sein. Wer heute eine saubere, dokumentierte und skalierbare Datenplattform aufbaut, schafft die Grundlage, auf der später auch FiDA-Datenquellen, sektorspezifische Integrationen und neue Anwendungsfälle aufsetzen können – ohne dass das gesamte System neu gedacht werden muss. Umgekehrt wird jede kurzfristige Abkürzung später mit Zinsen bezahlt, sei es in Form technischer Schulden, regulatorischer Nacharbeit oder verpasster Gelegenheiten.

Die Aegiron Capital Group unterstützt Fintech-Akteure bei diesem Weg – von der regulatorischen Lizenzstrategie über die Anbieterauswahl bis zur kommerziellen Positionierung im DACH-Markt. Unsere Arbeit erfolgt als spezialisierte strategische Beratung; konkrete Rechtsfragen klärt die Kanzlei, die Sie beauftragen. Unternehmen, die tiefes regulatorisches Wissen mit starker technischer Umsetzung kombinieren, erhöhen die Wahrscheinlichkeit, Wert zu schaffen, während das Ökosystem reift. In vielen Fällen liegt die entscheidende Arbeit nicht in einer einzelnen technischen oder regulatorischen Entscheidung, sondern in der kohärenten Ausrichtung aller Teile auf ein klares Kundenproblem. Fintechs, die diese Kohärenz erreichen, werden die Schlüsselrollen im kommenden DACH-Open-Banking- und Open-Finance-Ökosystem einnehmen – nicht weil sie am lautesten kommunizieren, sondern weil ihre Produkte zuverlässig funktionieren und ihre Regulierungsposition nachhaltig tragfähig ist.