PSD2 und Open Banking

Die europäische Finanzlandschaft hat im letzten Jahrzehnt einen tiefgreifenden Wandel durchlaufen, der von einer einzigen regulatorischen Vorgabe angetrieben wurde: der Zahlungsdiensterichtlinie 2 (PSD2). Diese umfassende EU-Verordnung hat in Verbindung mit der allgemeinen Marktbewegung hin zu Open Banking die Art und Weise, wie Finanzinstitute, Fintech-Unternehmen und Drittanbieter mit den Zahlungsdaten von Verbrauchern und Unternehmen interagieren, grundlegend verändert. Für IT-Entscheidungsträger und Führungskräfte im Bereich der digitalen Transformation ist das Verständnis von PSD2 und Open Banking nicht mehr optional – es ist unerlässlich, um sich in der modernen Architektur von Finanzdienstleistungen zurechtzufinden, Compliance-Risiken zu managen und Innovationschancen zu nutzen.

Dieser Leitfaden bietet eine fundierte Untersuchung von PSD2 und Open Banking: ihre Ursprünge, regulatorischen Anforderungen, technische Umsetzung, geschäftliche Auswirkungen und zukünftige Entwicklung. Ob Sie nun als CTO API-Integrationsstrategien bewerten, als Compliance-Beauftragter regulatorische Verpflichtungen prüfen oder als Fintech-Gründer neue Zahlungsdienste aufbauen – dieser Artikel wird Ihnen das Wissen vermitteln, um fundierte Entscheidungen zu treffen.

Was ist PSD2 und wie funktioniert es?

Ursprung und Entwicklung — von PSD zu PSD2

Die im Jahr 2007 verabschiedete Zahlungsdiensterichtlinie (Payment Services Directive, PSD) war der erste Versuch der Europäischen Union, die Regulierung von Zahlungsdiensten in den Mitgliedstaaten zu harmonisieren. Die ursprüngliche PSD legte Grundregeln für Zahlungsdienstleister, Verbraucherschutzstandards und die Abwicklung des grenzüberschreitenden Zahlungsverkehrs fest. Bis zu den frühen 2010er Jahren hatte sich die Zahlungslandschaft jedoch drastisch verändert. Mobile Banking, Online-Handel und Fintech-Innovationen hatten sich weit schneller entwickelt, als es die Richtlinie von 2007 vorhergesehen hatte. Die Erwartungen der Verbraucher an nahtlose Zahlungen in Echtzeit waren gestiegen. Betrugsbedrohungen hatten sich weiterentwickelt. Die Wettbewerbslandschaft hatte sich fragmentiert.

Als Reaktion darauf schlug die Europäische Kommission die überarbeitete Zahlungsdiensterichtlinie 2 (PSD2) vor, die formell als Richtlinie (EU) 2015/2366 verabschiedet wurde. Die PSD2 trat am 12. Januar 2016 in Kraft und gab den EU-Mitgliedstaaten zwei Jahre Zeit, die Richtlinie in nationales Recht umzusetzen — eine Frist, die von den meisten Nationen bis Januar 2018 eingehalten wurde. Die kritischste Compliance-Anforderung — die starke Kundenauthentifizierung (SCA) — wurde jedoch erst am 14. September 2019 verbindlich, was den Zahlungsdienstleistern eine zusätzliche Übergangsfrist einräumte, um die erforderliche Sicherheitsinfrastruktur zu implementieren.

Die Entwicklung von der PSD zur PSD2 spiegelt einen grundlegenden Wandel in der Regulierungsphilosophie wider: von einer statischen Regelsetzung hin zu einer anpassungsfähigen Governance, die Innovationen fördern und gleichzeitig Verbraucher schützen und die Finanzstabilität wahren soll. Heute arbeitet die Europäische Kommission bereits an der PSD3, von der erwartet wird, dass sie den Geltungsbereich von Open Finance weiter ausbaut und die Verbraucherrechte stärkt.

Kernziele und Geltungsbereich

Die PSD2 wurde entwickelt, um vier primäre Ziele zu erreichen, die jeweils ein bestimmtes Marktversagen oder eine regulatorische Lücke schließen:

1. Schaffung eines integrierteren und effizienteren europäischen Zahlungsverkehrsmarktes. Durch die Harmonisierung der Vorschriften für Zahlungsdienste im gesamten Europäischen Wirtschaftsraum (EWR) beseitigte die PSD2 fragmentierte nationale Vorschriften, die zuvor den grenzüberschreitenden Zahlungsverkehr behindert hatten. Diese Integration verringert Reibungsverluste für multinationale Unternehmen und ermöglicht es paneuropäischen Fintech-Plattformen, effizient zu skalieren.

2. Schaffung gleicher Wettbewerbsbedingungen für Zahlungsdienstleister. Die ursprüngliche PSD hatte Markteintrittsbarrieren für Nicht-Banken-Zahlungsdienstleister geschaffen. Die PSD2 erkennt explizit neue Kategorien von Zahlungsdienstleistern an — Kontoinformationsdienstleister (AISPs) und Zahlungsauslösedienstleister (PISPs) — und gewährt ihnen einen regulierten Zugang zu den Bankkonten der Kunden (vorbehaltlich der Zustimmung des Kunden). Diese Demokratisierung der Zahlungsdienste hat es Tausenden von Fintech-Startups ermöglicht, innovative Dienste auf den Markt zu bringen, die zuvor unmöglich waren.

3. Erhöhung der Zahlungssicherheit und Reduzierung von Betrug. Die Anforderung der PSD2 zur starken Kundenauthentifizierung schreibt vor, dass alle Online-Zahlungstransaktionen mit zwei unabhängigen Authentifizierungsfaktoren verifiziert werden müssen. Diese Anforderung hat den Zahlungsbetrug im gesamten EWR drastisch reduziert, obwohl sie auch betriebliche Herausforderungen für Händler und Verbraucher mit sich gebracht hat.

4. Schutz von Verbraucher- und Unternehmensdaten. Die PSD2 legt strenge Anforderungen an die Daten-Governance fest und schreibt die ausdrückliche Zustimmung des Verbrauchers vor, bevor ein Drittanbieter auf Kontoinformationen zugreifen kann. Sie verlangt von Zahlungsdienstleistern außerdem die Implementierung robuster Cybersicherheitsmaßnahmen, die Meldung von Sicherheitsvorfällen und die Einhaltung von Standards für die betriebliche Resilienz.

Geografische und sektorale Anwendbarkeit

Die PSD2 gilt für alle Zahlungsdienstleister, die innerhalb des Europäischen Wirtschaftsraums (EWR) tätig sind, wozu alle EU-Mitgliedstaaten sowie Island, Liechtenstein und Norwegen gehören. Die Richtlinie gilt im Rahmen spezifischer Post-Brexit-Vereinbarungen auch für Zahlungsdienstleister im Vereinigten Königreich, obwohl das Vereinigte Königreich mit der Entwicklung seines eigenen regulatorischen Rahmens für Open Banking begonnen hat.

Zu den Zahlungsdienstleistern, die der PSD2 unterliegen, gehören traditionelle Banken, Zahlungsinstitute (lizenzierte Nicht-Banken-Zahlungsabwickler), E-Geld-Institute und bestimmte Fintech-Unternehmen. Drittanbieter — AISPs und PISPs — müssen bei ihrer nationalen Finanzaufsichtsbehörde registriert sein und die technischen und sicherheitsrelevanten Standards der PSD2 einhalten, selbst wenn sie keine Kundengelder halten.

Für Unternehmen, die in Mittel- und Osteuropa (MOE) tätig sind — einschließlich der Slowakei, der Tschechischen Republik und anderer EU-Mitgliedstaaten —, ist die Einhaltung der PSD2 obligatorisch. Dies hat sowohl Herausforderungen als auch Chancen mit sich gebracht: Finanzinstitute mussten erheblich in API-Infrastrukturen und Sicherheitsprotokolle investieren, während Fintech-Unternehmen neue Kanäle für Innovation und Wettbewerb gefunden haben.

Was sind die Schlüsselkomponenten der PSD2-Compliance?

Starke Kundenauthentifizierung (SCA)

Die starke Kundenauthentifizierung (SCA) ist wohl die sichtbarste und betrieblich folgenreichste Anforderung der PSD2. Die SCA schreibt vor, dass alle Online-Zahlungstransaktionen mit zwei oder mehr unabhängigen Elementen aus drei Kategorien authentifiziert werden müssen:

• etwas, das Sie wissen (Wissen, wie z. B. ein Passwort oder eine PIN),

• etwas, das Sie besitzen (Besitz, wie z. B. ein Mobiltelefon oder ein Hardware-Token),

• etwas, das Sie sind (Inhärenz, wie z. B. ein biometrischer Fingerabdruck oder Gesichtserkennung).

Die technischen Regulierungsstandards für die SCA, die von der Europäischen Bankenaufsichtsbehörde (EBA) im März 2018 veröffentlicht wurden, wurden am 14. September 2019 verbindlich. Ab diesem Datum drohten jedem Zahlungsdienstleister, der die SCA nicht implementierte, aufsichtsrechtliche Sanktionen und die Haftung für betrügerische Transaktionen.

Die PSD2 und die EBA-Leitlinien enthalten jedoch einige wichtige Ausnahmen von der SCA-Pflicht, sofern die Zahlungsdienstleister nachweisen können, dass die Transaktion in eine Kategorie mit geringem Risiko fällt:

• Transaktionen mit geringem Wert: Zahlungen unter 30 € (wobei dieser Schwellenwert von den einzelnen Mitgliedstaaten angepasst werden kann).

• Wiederkehrende Zahlungen: Transaktionen, bei denen der Zahler bereits die erste Zahlung in einer Reihe authentifiziert hat.

• Whitelisting von Händlern: Zahlungen an Händler, die der Kunde explizit genehmigt hat.

• Zahlungen an sich selbst: Überweisungen zwischen Konten desselben Kunden.

• Vertrauenswürdige Begünstigte: Überweisungen an vorab genehmigte Empfänger.

Diese Ausnahmen waren unerlässlich, um zu verhindern, dass die SCA den E-Commerce und wiederkehrende Abonnementmodelle lähmt. Sie haben jedoch auch Sicherheitslücken geschaffen: Betrüger haben die Ausnahmeregelungen ausgenutzt, und Zahlungsdienstleister müssen hochentwickelte, risikobasierte Authentifizierungssysteme implementieren, um zwischen risikoarmen Transaktionen und potenziellem Betrug zu unterscheiden.

Über die grundlegende Zwei-Faktor-Anforderung hinaus führt die PSD2 das Konzept der dynamischen Verknüpfung (dynamic linking) für kartengestützte Transaktionen ein. Die dynamische Verknüpfung erfordert, dass der Authentifizierungsprozess den Zahlungsbetrag und die Daten des Zahlungsempfängers explizit bestätigt. Dies verhindert Man-in-the-Middle-Angriffe, bei denen ein Betrüger eine Zahlung abfängt und die Transaktionsdetails nach der Authentifizierung ändert.

Open-Banking- und API-Standards

Während die SCA die Zahlungssicherheit betrifft, befassen sich die Open-Banking-Bestimmungen der PSD2 mit dem Datenzugriff und der Interoperabilität. Artikel 4 der PSD2 verlangt, dass Zahlungsdienstleister autorisierten Drittanbietern Kontoinformationen und Zahlungsauslösedienste über sichere, standardisierte APIs zur Verfügung stellen. Diese APIs müssen den „gemeinsamen und sicheren offenen Kommunikationsstandards“ entsprechen.

Die technischen Regulierungsstandards der EBA legen fest, dass diese APIs wie folgt beschaffen sein müssen:

• Standardisiert: Konsistent über alle Zahlungsdienstleister hinweg, sodass Drittanbieter Code einmal schreiben und in mehrere Banken integrieren können.

• Sicher: Geschützt durch Verschlüsselung, gegenseitige Authentifizierung und Zugriffskontrollen.

• Zuverlässig: Verfügbar in 99,5 % der Fälle (mit dokumentierten SLAs).

• Leistungsstark: In der Lage, Anfragen innerhalb definierter Antwortzeitfenster zu verarbeiten.

In der Praxis hat dies zur Entstehung von Open-Banking-API-Standards wie dem Open Banking Standard (UK), der Berlin Group NextGenPSD2-Spezifikation (Europa) und verschiedenen nationalen Implementierungen geführt. Diese Standards definieren die technische Struktur von API-Anfragen und -Antworten, Authentifizierungsprotokolle und Datenformate.

Ein kritischer Aspekt von Open-Banking-APIs ist, dass sie auf einem einwilligungsbasierten Modell basieren. Ein Drittanbieter kann nicht ohne die ausdrückliche, informierte Zustimmung des Kunden auf dessen Kontodaten zugreifen. Der Kunde muss darüber informiert werden, auf welche Daten der TPP (Third-Party Provider) genau zugreift, wie lange und zu welchem Zweck. Diese Einwilligung wird im Bankkonto des Kunden hinterlegt und kann jederzeit widerrufen werden.

Kontoinformationsdienste (AIS) und Zahlungsauslösedienste (PIS)

Die PSD2 unterscheidet zwei Hauptkategorien von Drittanbieterdiensten, die über Open-Banking-APIs betrieben werden:

• Kontoinformationsdienste (AIS): Ein AISP ist ein lizenzierter Drittanbieter, der auf die Kontoinformationen eines Kunden — Transaktionshistorie, Kontostand, Zahlungshistorie — zugreifen darf, um Finanzmanagement-, Analyse- oder Beratungsdienste bereitzustellen. Beispiele hierfür sind Apps für das persönliche Finanzmanagement (wie die Budgetierungsfunktionen von Revolut oder N26), Anwendungen zur Ausgabenverfolgung und Finanzanalyseplattformen. Ein AISP kann keine Zahlungen auslösen; er kann Kontodaten nur lesen.

• Zahlungsauslösedienste (PIS): Ein PISP ist ein lizenzierter Drittanbieter, der im Namen eines Kunden Zahlungen direkt vom Bankkonto des Kunden auslösen kann. Beispiele hierfür sind Fintech-Zahlungsplattformen (wie Wise oder die Zahlungslinks von Stripe), Rechnungszahlungsdienste und alternative Checkout-Lösungen. Ein PISP kann Zahlungen auslösen, kann aber in der Regel keine historischen Kontodaten lesen (obwohl einige Implementierungen einen eingeschränkten Datenzugriff zur Betrugsprävention erlauben).

Sowohl AIS- als auch PIS-Anbieter müssen formell bei ihrer nationalen Finanzaufsichtsbehörde registriert sein. In der EU ist dies in der Regel die nationale Zentralbank oder die Finanzmarktaufsichtsbehörde. Die Registrierung erfordert den Nachweis technischer Fähigkeiten, von Sicherheitsmaßnahmen, Governance-Strukturen und finanzieller Solidität. Einmal registriert, erhalten AIS- und PIS-Anbieter das gesetzliche Recht, auf Kundenbankkonten zuzugreifen (vorbehaltlich der Zustimmung des Kunden), und unterliegen der laufenden aufsichtsrechtlichen Überwachung.

Wie ermöglichen Open-Banking-APIs den Austausch von Finanzdaten?

API-Architektur und technische Umsetzung

Open-Banking-APIs basieren auf Standard-Webtechnologien: RESTful-HTTP-Protokollen, JSON-Datenformaten und der OAuth-2.0-Authentifizierung. Dieses technische Fundament wurde bewusst gewählt, um die Eintrittsbarrieren für Fintech-Entwickler zu senken und die Kompatibilität mit verschiedenen Bankensystemen zu gewährleisten.

Ein typischer Open-Banking-API-Ablauf funktioniert wie folgt:

1. Kunde initiiert eine Anfrage: Ein Kunde nutzt eine Fintech-App und klickt auf eine Schaltfläche wie „Verbinden Sie Ihr Bankkonto“. Die App leitet den Kunden auf die Login-Seite seiner Bank (oder die Schnittstelle eines Aggregators) weiter.

2. Kunde authentifiziert sich und erteilt seine Einwilligung: Der Kunde meldet sich mit seinen normalen Zugangsdaten bei seiner Bank an. Die Bank zeigt daraufhin einen Bildschirm zur Einwilligung an, auf dem genau zu sehen ist, auf welche Daten die Drittanbieter-App wie lange und zu welchem Zweck zugreifen wird. Der Kunde genehmigt oder lehnt die Anfrage explizit ab.

3. Bank generiert einen Autorisierungscode: Wenn die Anfrage genehmigt wird, generiert die Bank einen zeitlich begrenzten Autorisierungscode und leitet den Kunden zurück zur Fintech-App.

4. Drittanbieter-App tauscht Code gegen Zugriffstoken aus: Die Fintech-App verwendet den Autorisierungscode, um ein Zugriffstoken (Access Token) vom API-Server der Bank anzufordern. Dieser Austausch findet von Server zu Server statt, nicht über den Browser des Kunden. Dadurch wird sichergestellt, dass die App die Bankzugangsdaten des Kunden niemals sieht.

5. Drittanbieter-App fragt Kontodaten ab: Die Fintech-App verwendet das Zugriffstoken, um API-Anfragen an die Open-Banking-API der Bank zu senden, Kontoinformationen und die Transaktionshistorie abzurufen oder Zahlungen wie autorisiert auszulösen.

6. Bank gibt Daten zurück und protokolliert den Zugriff: Die Bank gibt die angeforderten Daten in einem standardisierten JSON-Format zurück und protokolliert jeden API-Zugriff für Audit- und Compliance-Zwecke.

Dieser OAuth-2.0-Ablauf stellt sicher, dass die Fintech-App niemals direkten Zugriff auf die Bankzugangsdaten des Kunden erhält. Stattdessen fungiert die Bank als vertrauenswürdiger Vermittler und gibt zeitlich begrenzte Zugriffstoken aus, die jederzeit widerrufen werden können.

Aus technischer Sicht haben Banken Open-Banking-APIs in der Regel über einen von zwei Ansätzen implementiert:

Ansatz 1: Direkte API-Integration

Die Bank baut ihre eigene Open-Banking-API direkt auf ihrem Kernbankensystem auf und macht Kontodaten und Zahlungsauslösefunktionen über standardisierte Endpunkte zugänglich. Dieser Ansatz bietet ein Maximum an Kontrolle und Anpassungsmöglichkeiten, erfordert jedoch erhebliche Investitionen in die Entwicklung.

Ansatz 2: API-Aggregationsplattform

Die Bank arbeitet mit einer externen API-Aggregationsplattform zusammen (wie Plaid, TrueLayer oder OpenBanking.org.uk), die als Schnittstelle zwischen den Altsystemen (Legacy Systems) der Bank und Drittentwicklern fungiert. Die Aggregationsplattform übernimmt die Authentifizierung, Datennormalisierung und API-Standardisierung. Dies verringert den Entwicklungsaufwand für die Bank, führt jedoch zu einer Abhängigkeit vom Aggregator.

Viele große europäische Banken haben einen hybriden Ansatz gewählt: Sie entwickeln Kern-Open-Banking-APIs intern, beteiligen sich aber gleichzeitig an branchenüblichen Plattformen, um eine breitere Kompatibilität im Ökosystem zu gewährleisten.

Verbrauchereinwilligung und Daten-Governance

Ein grundlegendes Prinzip von PSD2 Open Banking ist die ausdrückliche, informierte Einwilligung des Verbrauchers. Bevor ein Drittanbieter auf Kontodaten zugreifen oder Zahlungen auslösen kann, müssen dem Kunden klare Informationen über folgende Punkte vorgelegt werden:

• Die Identität des Drittanbieters

• Die spezifischen angeforderten Daten oder Funktionen (z. B. „Transaktionshistorie der letzten 90 Tage lesen“ oder „Zahlungen bis zu 5.000 € auslösen“)

• Die Dauer der Einwilligung (z. B. „für 90 Tage“ oder „bis auf Widerruf“)

• Der Zweck des Datenzugriffs (z. B. „um Budgetberatung anzubieten“ oder „um Rechnungszahlungen abzuwickeln“)

Dieses Einwilligungsmodell unterscheidet sich erheblich vom traditionellen Modell mit „Benutzername und Passwort“, bei dem ein Kunde seine Bankzugangsdaten an eine Drittanbieter-App übergab und ihr damit unbegrenzten Zugriff auf unbestimmte Zeit gewährte. Das Einwilligungsmodell der PSD2 ist weitaus granularer und transparenter.

Die Daten-Governance im Rahmen der PSD2 umfasst auch strenge Speicherfristen. Kontoinformationsdienstleister dürfen Transaktionsdaten in der Regel nur bis zu 90 Tage nach Ablauf der Einwilligung des Kunden aufbewahren. Dies verhindert, dass Fintech-Unternehmen ohne fortlaufende Einwilligung permanente Datenbanken mit der Finanzhistorie von Kunden aufbauen.

Darüber hinaus steht die PSD2 im Einklang mit der Datenschutz-Grundverordnung der EU (DSGVO), die Kunden zusätzliche Rechte einräumt: das Recht auf Auskunft über ihre Daten, das Recht auf Berichtigung unrichtiger Daten und das Recht auf Vergessenwerden (Datenlöschung). Diese Rechte machen die Daten-Governance noch komplexer und erfordern von Fintech-Unternehmen und Banken die Implementierung robuster Datenverwaltungs- und Löschverfahren.

Sicherheitsmaßnahmen und Betrugsprävention

Open-Banking-APIs sind lohnende Ziele für Cyberkriminelle. Eine kompromittierte API könnte Millionen von Kundentransaktionen, Guthaben und persönliche Finanzdaten offenlegen. Folglich schreibt die PSD2 strenge Sicherheitsmaßnahmen vor:

• Verschlüsselung: Jede API-Kommunikation muss über TLS-1.2-Protokolle (oder höher) verschlüsselt werden. Sensible Daten müssen sowohl bei der Übertragung (zwischen API-Client und Server) als auch im Ruhezustand (gespeichert auf den Systemen der Bank) verschlüsselt sein.

• Gegenseitige Authentifizierung: Sowohl der Drittanbieter als auch die Bank müssen sich gegenseitig authentifizieren, bevor Daten ausgetauscht werden. Dies wird in der Regel durch digitale Zertifikate und gegenseitiges TLS (mTLS) erreicht, was Man-in-the-Middle-Angriffe verhindert.

• Zugriffskontrollen: Von der Bank ausgestellte Zugriffstoken müssen in ihrem Umfang (Festlegung, welche Daten oder Funktionen genau zugänglich sind) und ihrer Dauer (Ablauf nach einem festgelegten Zeitraum, in der Regel 90 Tage) begrenzt sein. Banken müssen außerdem Rate Limiting (Ratenbegrenzung) und Anomalieerkennung implementieren, um verdächtige API-Nutzungsmuster zu identifizieren und zu blockieren.

• Transaktionsüberwachung: Bei Zahlungsauslösediensten müssen Banken alle Anträge auf Zahlungsauslösung auf Anzeichen von Betrug oder unbefugtem Zugriff überwachen. Dazu gehört der Abgleich von Transaktionsbeträgen mit historischen Mustern, die Überprüfung, ob der Zahlungsempfänger mit dem früheren Verhalten des Kunden übereinstimmt, und die Kennzeichnung ungewöhnlicher grenzüberschreitender Überweisungen oder Transaktionen mit hohem Wert.

• Meldung von Vorfällen: Wenn eine Bank oder ein Drittanbieter eine Sicherheitsverletzung erleidet, die sich auf Open-Banking-APIs auswirkt, muss der Vorfall der nationalen Finanzaufsichtsbehörde innerhalb eines definierten Zeitrahmens gemeldet werden (bei schwerwiegenden Vorfällen in der Regel innerhalb von 24 Stunden). Die EBA veröffentlicht Leitlinien zur Klassifizierung von Vorfällen und zu den Meldeverfahren.

• Penetrationstests und Sicherheitsaudits: Banken und große Drittanbieter sind verpflichtet, regelmäßige Penetrationstests und Sicherheitsaudits ihrer Open-Banking-Infrastruktur durchzuführen, in der Regel mindestens einmal jährlich. Diese Tests müssen von unabhängigen Sicherheitsfirmen durchgeführt und für die aufsichtsrechtliche Prüfung dokumentiert werden.

Welche geschäftlichen Auswirkungen haben PSD2 und Open Banking?

Auswirkungen auf Finanzinstitute

Für traditionelle Banken ist die PSD2 ein zweischneidiges Schwert gewesen. Einerseits hat sie erhebliche Kapitalinvestitionen in die API-Infrastruktur, in Sicherheitssysteme und in die Einhaltung regulatorischer Vorschriften erzwungen. Die europäischen Banken gaben kollektiv Milliarden von Euro aus, um Open-Banking-Plattformen aufzubauen, spezialisierte Talente einzustellen und Altsysteme umzugestalten, um Kontodaten über APIs bereitzustellen.

Andererseits hat Open Banking neue Umsatzmöglichkeiten geschaffen. Banken können ihre Kundenbeziehungen und Daten durch folgende Maßnahmen monetarisieren:

• API-Lizenzgebühren: Erhebung von Gebühren von Drittanbietern für den Zugriff auf Premium-Open-Banking-APIs.

• Premium-Datendienste: Angebot erweiterter Analysen, Erkenntnisse und prädiktiver Dienste für Fintech-Partner.

• White-Label-Lösungen: Bereitstellung von Open-Banking-Infrastruktur für kleinere Regionalbanken oder Fintech-Plattformen.

• Partnerschaften im Ökosystem: Aufbau strategischer Allianzen mit Fintech-Unternehmen, um das Serviceangebot zu erweitern und neue Kundensegmente zu erreichen.

Die tiefgreifendste Auswirkung der PSD2 auf Banken war jedoch die Disruption des Wettbewerbs. Fintech-Unternehmen, die mit Open-Banking-APIs ausgestattet sind, konnten innovative Zahlungs- und Finanzmanagementdienste auf den Markt bringen, ohne eine eigene Bankeninfrastruktur aufbauen zu müssen. Dies hat den Wandel hin zu Embedded Finance (eingebetteten Finanzdienstleistungen) beschleunigt, bei dem Finanzdienste direkt in nicht-finanzielle Apps integriert werden (z. B. Zahlungsoptionen in E-Commerce-Plattformen, Budgetierungstools in Buchhaltungssoftware).

Für Banken in Mittel- und Osteuropa hat die PSD2 zudem die Möglichkeit geschaffen, auf Augenhöhe mit westeuropäischen Finanzinstituten zu konkurrieren. Ein slowakisches oder tschechisches Fintech-Unternehmen kann heute Dienste aufbauen, die sich nahtlos in jede EU-Bank integrieren lassen, unabhängig von deren Größe oder geografischer Lage.

Chancen für Fintechs und Drittanbieter

Für Fintech-Unternehmen und Drittanbieter war die PSD2 bahnbrechend. Die regulatorische Vorgabe, dass Banken Open-Banking-APIs bereitstellen müssen, hat einen riesigen neuen Markt für innovative Finanzdienstleistungen geschaffen:

• Zahlungsauslösedienste: Unternehmen wie Wise, Stripe und Revolut haben Milliarden-Umsatz-Geschäfte aufgebaut, indem sie alternative Zahlungsmethoden anbieten, die die Zahlungsauslösedienste der PSD2 nutzen. Anstatt dass Kunden ihre Kartendaten auf der Website eines Händlers eingeben müssen, können sie sich direkt bei ihrer Bank authentifizieren und die Zahlung in Sekundenschnelle autorisieren.

• Persönliches Finanzmanagement: Apps wie Emma, Money Dashboard und Plaid haben Kontodaten von Tausenden von Banken über Open-Banking-APIs aggregiert, sodass Kunden alle ihre Konten an einem Ort sehen und personalisierte Finanzratschläge erhalten können.

• Kredit-Scoring und Kreditvergabe: Fintech-Kreditgeber nutzen Open-Banking-APIs, um auf Echtzeit-Transaktionsdaten zuzugreifen. Dies ermöglicht schnellere und genauere Kreditentscheidungen als traditionelle Auskunfteien. Dies hat die Kreditvergabe demokratisiert und es kleinen Unternehmen sowie Einzelpersonen mit begrenzter Kredithistorie erleichtert, Zugang zu Kapital zu erhalten.

• Rechnungs- und Gebührenzahlung: B2B-Fintech-Plattformen nutzen Zahlungsauslösedienste, um die Abläufe bei der Rechnungsbegleichung zu vereinfachen. Unternehmen können Lieferanten direkt von ihren Bankkonten aus bezahlen, ohne dass eine manuelle Dateneingabe oder papierbasierte Prozesse erforderlich sind.

Die regulatorische Verpflichtung zur Unterstützung von Open Banking hat auch die Markteintrittsbarrieren für Startups gesenkt. Ein Fintech-Gründer benötigt keine Banklizenz mehr, um einen Zahlungsdienst zu starten; er muss sich lediglich als Zahlungsauslösedienstleister registrieren und sich in bestehende Bank-APIs integrieren.

Risikomanagement und regulatorische Verpflichtungen

Trotz der Chancen haben die PSD2 und Open Banking neue Risiken und regulatorische Verpflichtungen mit sich gebracht, die Unternehmen sorgfältig verwalten müssen:

• Compliance-Aufwand: Organisationen, die AIS- oder PISP-Dienste anbieten, müssen eine aufsichtsrechtliche Registrierung erlangen, technische Standards implementieren, Sicherheitszertifizierungen aufrechterhalten und Berichte an die Aufsichtsbehörden übermitteln. Für Startups und kleine Unternehmen kann dieser Compliance-Overhead erheblich sein.

• Betriebliches Risiko: Open-Banking-APIs sind kritische Infrastrukturen. Wenn eine API ausfällt oder eine schlechte Leistung erbringt, kann dies den gesamten Fintech-Dienst stören. Banken und Drittanbieter müssen robuste Verfahren für Monitoring, Disaster Recovery und Business Continuity implementieren.

• Cybersicherheitsrisiko: Open-Banking-APIs sind lohnende Ziele für Cyberkriminelle. Eine einzige Sicherheitsverletzung könnte Millionen von Kundendatensätzen offenlegen und zu behördlichen Bußgeldern, Klagen und Reputationsschäden führen. Unternehmen müssen massiv in Sicherheitstools, Bedrohungsüberwachung und Incident-Response-Kapazitäten investieren.

• Datenschutz und DSGVO-Compliance: Drittanbieter müssen die Anforderungen der DSGVO für die Datenverarbeitung, -speicherung und -löschung erfüllen. Dies ist eine besondere Herausforderung für Unternehmen, die Daten von mehreren Banken aggregieren und zu Analysezwecken aufbewahren.

• Regulatorische Weiterentwicklung: Die PSD2 selbst entwickelt sich weiter, und die PSD3 ist bereits am Horizont erkennbar. Unternehmen müssen sich über regulatorische Änderungen auf dem Laufenden halten und bereit sein, ihre technische und betriebliche Infrastruktur entsprechend anzupassen.

Wie unterscheidet sich PSD2 von Open Banking?

Regulatorische vs. marktgetriebene Ansätze

Ein weit verbreitetes Missverständnis ist, dass PSD2 und Open Banking synonym herkömmliche Begriffe sind. Tatsächlich handelt es sich um unterschiedliche, sich jedoch überschneidende Konzepte:

PSD2 ist eine verbindliche EU-Verordnung. Alle im EWR tätigen Zahlungsdienstleister müssen die Anforderungen der PSD2 erfüllen, ob sie wollen oder nicht. Die Nichteinhaltung führt zu behördlichen Sanktionen, Bußgeldern und dem potenziellen Verlust von Betriebslizenzen.

Open Banking ist eine marktgetriebene Bewegung. Während die PSD2 vorschreibt, dass Banken Open-Banking-APIs bereitstellen müssen, geht die breitere Open-Banking-Bewegung über die Anforderungen der PSD2 hinaus. Open Banking umfasst freiwillige Initiativen von Banken und Fintech-Unternehmen, um Finanzdaten zu teilen und Innovationen von Drittanbietern zu ermöglichen, selbst in Rechtsordnungen, in denen es keine regulatorische Verpflichtung gibt.

Beispielsweise verpflichtete die Open-Banking-Initiative des Vereinigten Königreichs, die älter als die PSD2 ist, die neun größten britischen Banken zur Bereitstellung von Open-Banking-APIs, noch bevor die PSD2 verbindlich wurde. In ähnlicher Weise haben Australien und Singapur Open-Banking-Initiativen gestartet, die auf regulatorischen Vorgaben basieren, jedoch andere technische Standards und einen anderen Geltungsbereich als die PSD2 aufweisen.

Im Grunde genommen ist die PSD2 die europäische regulatorische Umsetzung des breiteren Open-Banking-Konzepts. Sie definiert das „Wie“ und „Was“ von Open Banking im EWR und legt genau fest, welche APIs bereitgestellt werden müssen, welche Sicherheitsstandards einzuhalten sind und welche Drittanbieter für den Zugriff auf Kundendaten autorisiert sind.

Geografischer Geltungsbereich und regionale Unterschiede

Die PSD2 gilt nur für Zahlungsdienstleister, die im EWR tätig sind. Außerhalb des EWR wird Open Banking im Rahmen anderer regulatorischer Rahmenbedingungen oder marktgetriebener Initiativen betrieben:

• Vereinigtes Königreich: Nach dem Brexit hat das Vereinigte Königreich ein eigenes Open-Banking-Framework entwickelt, das weitgehend an der PSD2 ausgerichtet ist, jedoch einige Unterschiede bei den technischen Standards und den Zeitplänen für die Umsetzung aufweist.

• Australien: Das Consumer Data Right (CDR)-Framework schreibt Open Banking für die vier größten Banken vor, wobei eine Erweiterung auf andere Finanzinstitute geplant ist.

• Singapur: Die Monetary Authority of Singapore (MAS) hat freiwillige Open-Banking-Initiativen mit spezifischen API-Standards und Sicherheitsanforderungen gefördert.

• Vereinigte Staaten: In den USA gibt es kein umfassendes Open-Banking-Mandat, obwohl das Consumer Financial Protection Bureau (CFPB) Open-Banking-Regeln vorgeschlagen hat, die Banken dazu verpflichten würden, Kundendaten mit Fintech-Konkurrenten zu teilen.

Für Unternehmen, die in mehreren Regionen tätig sind, führt diese Fragmentierung zu Komplexität. Ein Fintech-Unternehmen muss unter Umständen PSD2-konforme APIs für EWR-Kunden, UK-Open-Banking-APIs für britische Kunden und CDR-konforme APIs für australische Kunden implementieren — jeweils mit unterschiedlichen technischen Spezifikationen, Sicherheitsanforderungen und behördlicher Aufsicht.

Was sind die häufigsten Missverständnisse über PSD2 und Open Banking?

Missverständnis Nr. 1: PSD2 und Open Banking sind dasselbe

Fakt: Wie oben erläutert, ist die PSD2 die regulatorische Vorgabe der EU für Open Banking. Open Banking ist das breitere Marktkonzept. Sie hängen zusammen, sind aber verschieden. Das Verständnis dieser Unterscheidung ist für die Compliance und die strategische Planung wichtig.

Missverständnis Nr. 2: Open Banking ist nur für Verbraucher da

Fakt: Obwohl Open-Banking-APIs oft für Verbraucher vermarktet werden (z. B. Finanz-Apps), sind sie für Unternehmen gleichermaßen relevant. Zahlungsauslösedienste werden von B2B-Fintech-Plattformen in großem Umfang genutzt, um die Rechnungsbegleichung und das Cashflow-Management zu vereinfachen. Kontoinformationsdienste werden von Business-Intelligence-Plattformen genutzt, um Finanzanalysen in Echtzeit bereitzustellen. Regulierungsbehörden und Branchenverbände diskutieren zunehmend über Open Banking für KMU und Firmenkunden, nicht mehr nur für Verbraucher.

Missverständnis Nr. 3: SCA-Ausnahmen machen die Authentifizierung optional

Fakt: SCA-Ausnahmen (für Kleinbeträge, wiederkehrende Zahlungen etc.) sind konditioniert und risikobasiert. Ein Zahlungsdienstleister kann nicht einfach beschließen, die SCA für alle Kleinbeträge zu überspringen; er muss Risikoanalyse-Systeme implementieren, um sicherzustellen, dass die Transaktion tatsächlich die Bedingungen für eine Ausnahme erfüllt. Wenn ein Zahlungsdienstleister eine Ausnahme fälschlicherweise gewährt und ein Betrug auftritt, haftet der Dienstleister für die betrügerische Transaktion. Ausnahmen sind eng gefasst und erfordern eine sorgfältige Umsetzung.

Missverständnis Nr. 4: Der Austausch von Open-Banking-Daten ist von Natur aus unsicher

Fakt: Obwohl Open Banking den Austausch von Finanzdaten von Kunden mit Dritten beinhaltet, bieten das einwilligungsbasierte Modell der PSD2, die Verschlüsselungsanforderungen und die Zugriffskontrollen tatsächlich einen besseren Schutz als das traditionelle Modell des „Passwort-Teilens“ (Screen Scraping), das davor praktiziert wurde. Wenn ein Kunde einem Drittanbieter seine Einwilligung erteilt, gewährt er Zugriff auf einen klar definierten Datensatz für einen begrenzten Zeitraum und kann diese Einwilligung jederzeit widerrufen. Das ist weitaus granularer und transparenter, als einer App die Bankzugangsdaten zu überlassen und darauf zu hoffen, dass sie keinen Missbrauch damit treibt.

Wie sieht die Zukunft von Open Banking und PSD3 aus?

PSD3-Roadmap und erwartete Änderungen

Die Europäische Kommission hat bereits das Gesetzgebungsverfahren für die PSD3 eingeleitet, wobei die Umsetzung für den Zeitraum 2025–2026 prognostiziert wird. Während über die PSD3 noch verhandelt wird, zeichnen sich einige wichtige Änderungen ab:

• Erweiterter Geltungsbereich über den Zahlungsverkehr hinaus: Es wird erwartet, dass die PSD3 die Prinzipien des Open Banking auf andere Finanzprodukte ausweitet, einschließlich Sparkonten, Investmentdepots, Versicherungsprodukte und Hypotheken. Dieser breitere Geltungsbereich wird auch als offenes Finanzwesen (Open Finance) bezeichnet.

• Gestärkte Verbraucherrechte: Die PSD3 wird voraussichtlich die Rechte der Verbraucher stärken, auf ihre eigenen Daten zuzugreifen und ihre Finanzbeziehungen auf konkurrierende Anbieter zu übertragen. Dies könnte das Recht beinhalten, Kontodaten in standardisierten Formaten herunterzuladen und den Anbieter mit minimalem Aufwand zu wechseln.

• Höhere Sicherheit und betriebliche Resilienz: Die PSD3 wird wahrscheinlich strengere Anforderungen an die Cybersicherheit stellen, darunter verbindliche Verschlüsselungsstandards, häufigere Sicherheitsaudits und kürzere Fristen für die Reaktion auf Vorfälle.

• Echtzeitzahlungen als Standard: Die PSD3 könnte vorschreiben, dass alle Banken die Auslösung von Echtzeitzahlungen unterstützen müssen, wodurch sich die Abrechnungszeiten von Tagen auf Sekunden verkürzen.

• Vereinfachte Autorisierung und Authentifizierung: Mit der PSD3 könnten flexiblere Authentifizierungsmethoden eingeführt werden, was möglicherweise die Abhängigkeit von SCA-Ausnahmen verringert, indem eine risikobasierte Authentifizierung ermöglicht wird, die sowohl sicher als auch benutzerfreundlich ist.

Aufkommende Trends im Bereich Open Finance

Über die PSD3 hinaus prägen mehrere übergeordnete Trends die Zukunft von Open Banking und Open Finance:

• Embedded Finance: Finanzdienstleistungen werden zunehmend direkt in nicht-finanzielle Anwendungen integriert. Ein Kunde kann einen Kredit beantragen, während er auf einer E-Commerce-Plattform einkauft, oder seine Ersparnisse über eine Budgetierungs-App anlegen. Open-Banking-APIs ermöglichen dieses Modell, indem sie Drittanbieter-Apps den Zugriff auf Finanzdaten und das Auslösen von Transaktionen im Namen von Kunden erlauben.

• Echtzeitzahlungen: Sofortzahlungssysteme (wie die SEPA-Echtzeitüberweisung in der EU) werden zum Standard und ermöglichen eine Zahlungsabwicklung rund um die Uhr an jedem Tag des Jahres. Dieser Übergang von der Batch-Verarbeitung zur Echtzeit-Abrechnung verändert das Cashflow-Management und die Zahlungsabläufe grundlegend.

• Offene Daten und Finanztransparenz: Regulierungsbehörden und Verbraucherschützer fordern mehr Transparenz bei den Preisen und Bedingungen von Finanzdienstleistungen. Open-Banking-APIs könnten erweitert werden, um Preisdaten offenzulegen. Dies würde es Kunden ermöglichen, Finanzprodukte einfach zu vergleichen und den Anbieter zu wechseln.

• Grenzüberschreitendes Open Banking: Obwohl die PSD2 in erster Linie innerhalb des EWR gilt, gibt es ein wachsendes Interesse daran, Open Banking über Ländergrenzen hinweg zu ermöglichen, um global integrierte Finanzdienstleistungen anzubieten.

Häufig gestellte Fragen (FAQs)

Was ist der Hauptunterschied zwischen PSD1 und PSD2?

Die ursprüngliche PSD (2007) konzentrierte sich auf die Schaffung eines harmonisierten rechtlichen Rahmens für Zahlungen innerhalb der EU, um den Wettbewerb zu stärken und den Verbraucherschutz zu verbessern. Die PSD2 (2015) weitete diesen Rahmen aus, indem sie das Open Banking einführte (Verpflichtung für Banken, autorisierten Dritten Zugriff auf Kontodaten zu gewähren) und strengere Sicherheitsanforderungen wie die starke Kundenauthentifizierung (SCA) vorschrieb.

Wer reguliert Open-Banking-Drittanbieter (TPPs)?

Drittanbieter müssen von der zuständigen Finanzaufsichtsbehörde ihres jeweiligen Heimatlandes (wie der BaFin in Deutschland oder der FMA in Österreich) zugelassen oder registriert werden. Sobald sie in einem EU-Land registriert sind, können sie ihre Dienste im gesamten EWR über das sogenannte Passporting-Verfahren anbieten.

Kann eine Bank einem Drittanbieter den Zugriff auf mein Konto verweigern?

Eine Bank darf einem autorisierten Drittanbieter den Zugriff nur dann verweigern, wenn begründete und ordnungsgemäß nachgewiesene Bedenken hinsichtlich eines unbefugten oder betrügerischen Zugriffs bestehen. In einem solchen Fall muss die Bank den Vorfall der nationalen Aufsichtsbehörde melden. Ansonsten ist sie gesetzlich verpflichtet, den Zugang zu gewähren, sofern der Kunde seine Einwilligung erteilt hat.

Kostet die Nutzung von Open-Banking-Diensten den Endverbraucher Geld?

Gemäß den PSD2-Vorschriften müssen Banken den grundlegenden Zugang zu Kontodaten und zur Zahlungsauslösung für regulierte Drittanbieter kostenlos zur Verfügung stellen. Ob der Drittanbieter selbst für seine darauf aufbauende App oder Dienstleistung Gebühren verlangt, bleibt seinem eigenen Geschäftsmodell überlassen; viele Basisdienste für Verbraucher sind jedoch kostenlos.

Wie kann ich eine erteilte Open-Banking-Einwilligung wieder widerrufen?

Sie können Ihre Einwilligung entweder direkt in der Anwendung des Drittanbieters widerrufen oder sich in das Online-Banking Ihrer Bank einloggen. Banken sind verpflichtet, ein „Dashboard“ oder eine Übersicht bereitzustellen, in der Kunden alle aktiven Verknüpfungen mit Drittanbietern einsehen und den Zugriff mit sofortiger Wirkung sperren können.