PSR: Viel Zeit auf dem Papier – wenig Zeit in der Praxis
Die Payment Services Directive 3 (PSD3) und die Payment Services Regulation (PSR) stehen kurz vor ihrer Finalisierung, auch wenn sich der Zeitplan kürzlich noch einmal um einige Monate verschoben hat: Die Verabschiedung der Gesetze wird unserer Erwartung nach im Dezember 2026 geschehen – mit einer Veröffentlichung im Amtsblatt der EU im Januar 2027. Dann gilt ein Zeitraum von 21 Monaten bis zum Inkrafttreten der großen Mehrzahl der PSR-Anforderungen. Ausreichend Zeit für ein „Update“ der PSD2, würde man meinen.
Weiter abzuwarten, etwa bis die neuen EBA RTS (spätestens im Januar 2028) veröffentlicht werden und alle jetzt noch offenen Details geklärt sind, wäre jedoch fatal. Die PSR führt eine Reihe von Anforderungen ein, die grundlegend neu sind – und alles andere als trivial. Drei Beispiele:
Beispiel 1: Transaktionsüberwachung – vom RTS-Standard zur haftungsbewehrten Pflicht
Ist-Setup unter PSD2: Die Grundlagen der Transaktionsüberwachung stammen bislang größtenteils nicht aus der PSD2 selbst, sondern aus den technischen Regulierungsstandards zur starken Kundenauthentifizierung (SCA-RTS). Die Überwachung dient primär dazu, die SCA zu unterstützen und risikobasierte Ausnahmen (TRA) zu ermöglichen. Sie ist im Wesentlichen zahlerseitig gedacht; eine explizite Pflicht für den Zahlungsempfänger-PSP (Payments Service Provider) existiert nicht. Auch eine ausdrückliche Haftungsfolge bei unterlassener Transaktionsüberwachung fehlt, ebenso wie eine klar definierte, geschlossene Liste zulässiger Datenkategorien als datenschutzrechtliche Grundlage.
Was die PSR ändert: Die PSR hebt die Überwachungspflicht auf Ebene des Basisrechtsakts und erweitert sie in mehrfacher Hinsicht:
- Zahlungsempfängerseitige Pflicht (Art. 83(1a)): Der PSP des Zahlungsempfängers muss eingehende Zahlungen vor Gutschrift überwachen – eine völlig neue Pflicht, gedacht insbesondere gegen Finanzagenten-Konten („Mule Accounts“).
- Explizite Haftung: Unterbleibt die Überwachung und entsteht dem Zahler dadurch ein Schaden, haftet der betroffene PSP unmittelbar – eine Haftungsnorm, die es unter PSD2 in dieser Form nicht gab.
- Beweislastverteilung: Der PSP des Zahlers muss im Streitfall nachweisen, dass die Überwachung auf beiden Seiten stattgefunden hat – also auch beim PSP des Empfängers. Fehlt dieser Nachweis, ist der Betrag zu erstatten.
- Verpflichtender Betrugsdatenaustausch (Art. 83a): PSPs müssen künftig strukturiert Betrugsdaten mit anderen PSPs austauschen, inklusive Pflicht zur Datenschutz-Folgenabschätzung und gegebenenfalls vorheriger Konsultation der Aufsichtsbehörde.
- Geschlossene Datenkategorienliste: Die PSR listet erstmals explizit auf, welche Datenkategorien für Überwachungszwecke verarbeitet werden dürfen – das schafft Rechtssicherheit, verlangt aber auch ein Audit bestehender Monitoring-Engines gegen diese Liste.
Der Gap: Banken, deren Monitoring heute primär auf die Zahlerseite und auf SCA-Unterstützung ausgerichtet ist, benötigen eine zusätzliche Überwachungslogik auf der Empfängerseite, belastbare Nachweisprozesse gegenüber Korrespondenz-PSPs sowie eine Dateninfrastruktur für den Betrugsdatenaustausch – inklusive der zugehörigen Datenschutz-Governance.
Beispiel 2: Haftung – von einer Logik zu drei parallelen Regimen
Ist-Setup unter PSD2: Die Haftung für Zahlungsvorgänge läuft heute im Kern über eine einzige Spur: die nicht autorisierte Transaktion (PSD2 Art. 73/74). Der PSP muss bei Verdacht auf Betrug oder grobe Fahrlässigkeit „vernünftige Gründe“ nachweisen und diese der zuständigen Behörde mitteilen.
Was die PSR ändert: Neben der modifizierten Logik für nicht autorisierte Transaktionen treten zwei vollständig neue, parallele Haftungsregime hinzu:
- VoP-Fehlerhaftung (Art. 57): Schlägt die Zahlungsempfänger-Verifizierung fehl und führt dies zu einer fehlerhaften Ausführung, muss der PSP des Zahlers unverzüglich erstatten – und sich anschließend beim verursachenden PSP schadlos halten.
- Identitätsbetrug/Spoofing (Art. 59/60): Gibt sich ein Betrüger als der PSP eines Verbrauchers aus (gefälschte Domain, Telefonnummer, E-Mail) und wird der Kunde dadurch zu einer autorisierten, aber betrügerisch veranlassten Zahlung verleitet, muss der PSP den vollen Betrag erstatten – vorausgesetzt, der Kunde hat den Vorfall unverzüglich sowohl dem PSP als auch der Polizei gemeldet.
Jede dieser Logiken hat eigene Auslösebedingungen, eigene Fristen (häufig, aber nicht durchgängig, 15 Geschäftstage), eigene Beweislastregeln und einen eigenen Streitbeilegungspfad. Der Rahmenvertrag muss künftig alle drei Haftungsregime getrennt ausweisen – zuvor genügte der Verweis auf eine einzige Norm.
Der Gap: Was heute ein Streitbeilegungsprozess mit einer Entscheidungslogik ist, wird zu drei parallelen Prozessen mit unterschiedlichen Nachweispflichten, unterschiedlichen Fristuhren und unterschiedlichen Eskalationswegen. Das betrifft Fraud-Teams, Rechtsabteilung, Kundenservice und die Vertragsgestaltung gleichermaßen – nicht nur eine Anpassung bestehender Formulare.
Beispiel 3: Open Banking – von der Kann- zur Muss-Schnittstelle
Ist-Setup unter PSD2: Nach der SCA-RTS konnten kontoführende Zahlungsdienstleister zwischen zwei Optionen wählen: einer dedizierten Schnittstelle oder einer angepassten Kundenschnittstelle. Zudem existierte ein automatischer Fallback-Mechanismus: Fiel die dedizierte Schnittstelle wiederholt aus (typischerweise definiert über Schwellenwerte wie mehrere gescheiterte Zugriffe in kurzer Zeit), durften AISP/PISP auf die Kundenschnittstelle ausweichen. Gleichzeitig definieren technische Standards am Markt die Art der Interpretation vieler Details der RTS, die sich beispielsweise auf die Verfügbarkeit, Sicherheitsstandards oder Bereitstellung von Daten und Rechte von PSPs beziehen.
Was die PSR ändert: Die PSR macht die dedizierte Schnittstelle auf Ebene des Basisrechtsakts verpflichtend; die Alternative der angepassten Kundenschnittstelle entfällt als generelle Option. Gleichzeitig wird der automatische RTS-Fallback deutlich eingeschränkt: Der reflexartige Wechsel auf die Kundenschnittstelle bei technischen Störungen ist nicht mehr in der bisherigen Form vorgesehen; Zugriff über eine „andere sichere und effiziente Schnittstelle“ ist nur noch die Ausnahme. Zusätzlich gelten verschärfte und neue Pflichten: Protokollierung mit dreijähriger Aufbewahrungsfrist, Konkretisierung der angebotenen Zahlungsauslösemöglichkeiten (Daueraufträge, terminierte Zahlungen, Mehrfachempfängerzahlungen) oder stärkere Einschränkungen der Wartungsfenstern und Dokumentation von Nutzungsstatistiken. Die vielleicht umfangreichste Änderung stellt das Consent-Dashboard dar, das Kunden jederzeit die aktiven Zugriffsberechtigungen von TPPs verwalten lässt.
Der Gap: Banken, die heute auf die angepasste Kundenschnittstelle oder auf den klassischen RTS-Fallback setzen, müssen ihr Zielbild überdenken: Entweder der Aufbau einer vollwertigen dedizierten Schnittstelle mit den erweiterten PIS-Fähigkeiten, oder ein belastbarer Antrag auf die enger gefasste Ausnahme – inklusive der zusätzlichen Protokollierungs- und Dashboard-Pflichten. Beides ist mit spürbarem technischen und organisatorischen Vorlauf verbunden, nicht mit einer kurzfristigen Konfigurationsänderung. Aufwandstreiber sind ebenso die vielen detaillierten Anpassungen, die Handlungsbedarf in der Schnittstelle, den Prozessen sowie am Kundeninterface bedeuten und dessen Aufwände sich schnell summieren.
Ein bunter Strauß an Themen, keine Einzelmaßnahme
Die drei Beispiele – Transaktionsüberwachung, Haftung, Open Banking – stehen dabei nicht für sich. Sie sind eher Ausschnitte aus einem ganzen Strauß an Themen, den die PSR zusammenbindet: neue Datenflüsse für den Betrugsdatenaustausch, neue Beweislast- und Dokumentationspflichten, neue Schnittstellenanforderungen, neue Fristen für Kundenkommunikation, neue Vorgaben für Schulung und Governance. Jeder einzelne Stiel in diesem Strauß berührt andere Systeme, andere Prozesse und andere organisatorische Einheiten – von Fraud/Risk über Recht und IT bis zu Kundenservice und Produktmanagement. Genau darin liegt die eigentliche Komplexität: nicht in einer einzelnen anspruchsvollen Anforderung, sondern in der Zahl der Stellen in der Bank, die gleichzeitig etwas verändern müssen, ohne dass es dafür bereits eine eingespielte Choreografie gibt.
Der gestaffelte Zeitplan verstärkt diesen Effekt eher, als ihn zu entschärfen: Während die ersten EBA-Vorgaben bereits nach zwölf Monaten konkretisiert werden, laufen Systemaufbau, Prozessdesign und organisatorische Abstimmung parallel weiter – und die zusätzlichen sechs Monate bei VoP zeigen, dass selbst der Regulierungsgeber die Aufbauzeit für neue Infrastruktur als knapp einschätzt.
Warum jetzt der richtige Zeitpunkt ist
Genau deshalb lohnt es sich, die gefühlte Verschnaufpause nicht als solche zu begreifen, sondern als Gelegenheit, Gap-Analysen gegenüber dem heutigen PSD2-Setup, Identifizierung und Quantifizierung der wichtigsten Maßnahmenpakete sowie eine Planung des/r Umsetzungsprojekte(s) unter Einbezug aller betroffenen Abteilungen durchzuführen. Auch die konkrete Konzeption sollte beginnen, bevor die RTS veröffentlicht werden – auch wenn das heißt, an manchen Stellen mit einem „moving target“ zu arbeiten.
Hinzu kommt: Die PSR sollte nicht isoliert betrachtet werden. Besonders offensichtlich ist das Zusammenspiel mit eIDAS 2.0 und dem EUDI-Wallet, aber auch mit der neue EU-Geldwäscheverordnung gibt es Brührungspunkte. Zudem bietet die PSR die Möglichkeit, Pflicht und Chance zu verbinden und bei einem Upgrade von Systemen und Prozessen über die Regulatorik hinaus strategische Ziele mit einzubeziehen.
Wie wir unterstützen können
Wir haben Banken bereits durch genau diese Art der Bewertung begleitet – von der strukturierten Gap-Analyse gegenüber dem bestehenden PSD2-Setup über funktionsübergreifende Impact-Workshops bis zur priorisierten, umsetzbaren Roadmap. Die Komplexität der PSR ist real, aber mit der richtigen Struktur und dem richtigen Startpunkt gut zu bewältigen.
Der wertvollste Schritt in diesem Quartal: Ein klares Bild davon, wie groß der Strauß an Themen im eigenen Haus tatsächlich ist – und wo die größten Lücken liegen. Dieses Gespräch lohnt sich jetzt, solange noch Zeit ist, auf die Ergebnisse zu reagieren.
