PSD3 und die PSR: Wie Payment-nahe SaaS ihre Architektur vorbereiten sollten

Wenn dein SaaS-Produkt Geld berührt, ohne eine Bank zu sein - Rechnungsstellung, Marktplatz-Auszahlungen, Subscription-Billing, Spesenmanagement, Embedded Checkout - hast du dir vermutlich gesagt, dass Zahlungsregulierung das Problem deines Payment-Providers ist. PSD3 und die Payment Services Regulation (PSR) werden diese Annahme auf die Probe stellen. PSD3 Compliance verschärft nicht nur die Regeln für lizenzierte Zahlungsinstitute; das Paket zieht die Grenze zwischen "reguliertem Zahlungsdienst" und "technischem Dienstleister" neu, und manche Produkte, die bequem außerhalb von PSD2 saßen, finden sich im neuen Perimeter wieder - oder werden von ihren Bankpartnern zumindest vertraglich hineingezogen.

Dieser Post erklärt, was das PSD3/PSR-Paket ändert, wie du testest, ob dein Produkt im Scope liegt, und welche Architekturentscheidungen sich jetzt lohnen, solange du noch Spielraum hast.

Was PSD3 und die PSR eigentlich sind

Die Europäische Kommission hat das Paket im Juni 2023 als Nachfolger von PSD2 vorgeschlagen. Es teilt die alte Richtlinie in zwei Instrumente auf, und diese Aufteilung ist wichtiger, als sie zunächst wirkt:

• PSD3 ist eine Richtlinie, die auf die Lizenzierung und Aufsicht von Zahlungsinstituten zielt. Sie absorbiert das E-Geld-Regime, sodass E-Geld-Institute und Zahlungsinstitute in einem einzigen Zulassungsrahmen zusammenlaufen, den die Mitgliedstaaten in nationales Recht umsetzen.
• Die PSR ist eine Verordnung, das heißt, sie gilt direkt und einheitlich in jedem Mitgliedstaat ohne nationale Umsetzung. Die Verhaltensregeln - starke Kundenauthentifizierung, Open-Banking-Zugang, Betrugshaftung, Transparenzanforderungen - stehen hier.

Der zweite Punkt ist der strategische. Unter PSD2 haben nationale Regulierer die Regeln unterschiedlich ausgelegt, und viele Grenzfall-Produkte überlebten dank einer wohlwollenden nationalen Lesart der Ausnahme für "technische Dienstleister". Eine direkt anwendbare Verordnung nimmt einen Großteil dieses Spielraums weg. Die Auslegung, die zählt, wird die EU-weite sein.

Das Paket durchläuft noch den EU-Gesetzgebungsprozess, und das finale Anwendungsdatum wird etwa 18 Monate nach der Verabschiedung liegen. Das klingt komfortabel. Ist es nicht. Die unten beschriebenen Architekturänderungen gehören zu der Sorte, deren gute Umsetzung mehrere Quartale dauert, und deine Partnerbanken werden aktualisierte Vertragsanforderungen lange vor jeder Deadline an dich weiterreichen - genau wie bei DORA.

Der Scope-Test: Bist du wirklich Payment-nah?

Die PSD2-Ausnahme, auf die sich die meisten SaaS-Produkte verlassen, ist der Carve-out für technische Dienstleister: Du unterstützt die Erbringung von Zahlungsdiensten, ohne jemals in den Besitz der Gelder zu gelangen. PSD3 und die PSR behalten das Konzept, schärfen aber die Kanten. Drei Fragen sagen dir das meiste von dem, was du wissen musst:

1. Liegen Gelder jemals auf einem Konto, das du kontrollierst? Marktplatzmodelle mit Auszahlungsverzögerungen, Wallet-artige Guthaben oder "Store Credit"-Features sind die klassische Falle. Wenn Geld bei dir ruht, auch nur kurz, erbringst du wahrscheinlich einen Zahlungsdienst, der eine Zulassung oder eine sauber dokumentierte Ausnahme braucht.
2. Löst du Zahlungen aus oder aggregierst du Kontodaten? Zahlungsauslösung und Kontoinformationsdienste bleiben regulierte Tätigkeiten. Wenn dein Produkt Zahlungen vom Bankkonto eines Nutzers anstößt oder seine Transaktionshistorie abruft, bist du im Open-Banking-Territorium mit eigenen Zugangs- und Sicherheitsregeln.
3. Betreibst du die kundenseitige Authentifizierungsstrecke? Die PSR verschiebt Pflichten rund um die Ergebnisse der starken Kundenauthentifizierung in Richtung dessen, der die User Journey kontrolliert. Auch als unregulierter technischer Dienstleister solltest du erwarten, dass deine regulierten Partner dir SCA-bezogene Anforderungen vertraglich auferlegen, denn die PSR sieht die Haftungsverteilung zwischen Zahlungsdienstleistern und den technischen Parteien, auf die sie sich stützen, ausdrücklich vor.

Wenn du eine dieser Fragen mit Ja beantwortet hast, behandle PSD3-Readiness als Produktanforderung, nicht als juristische Fußnote. Ein Code-Qualitäts- und Architektur-Audit, das abbildet, wo Geld und Zahlungsdaten tatsächlich durch dein System fließen, ist der günstigste erste Schritt - denn die Lücke zwischen dem, was dein Architekturdiagramm behauptet, und dem, was der Code tut, ist genau das, was die Due Diligence einer Partnerbank findet.

Was PSD3 Compliance bei der starken Kundenauthentifizierung ändert

Das SCA-Regime bleibt bestehen, aber mit Korrekturen, die auf die Friktions- und Betrugsmuster zielen, die PSD2 hervorgebracht hat:

• Ergebnisbasierte Ausnahmen. Das Paket bewegt sich dahin, Authentifizierung nach Betrugsergebnissen zu beurteilen, statt einen starren Challenge-Flow vorzuschreiben - das belohnt Anbieter mit guten Risk Engines und sauberen Daten.
• Barrierefreiheitsanforderungen. SCA muss für Nutzer ohne Smartphone und für Nutzer mit Behinderungen funktionieren. Wenn dein Produkt eine Authentifizierungsstrecke einbettet, die einen App-basierten Authenticator voraussetzt, brauchst du alternative Pfade.
• Haftung bei Impersonationsbetrug. Die PSR erweitert die Haftung für autorisierten Push-Payment-Betrug, einschließlich Fällen, in denen Betrüger Bankmitarbeiter imitieren. Banken werden darauf reagieren, indem sie von jeder vorgelagerten Partei - auch deinem Produkt - reichhaltigeren Transaktionskontext für ihre Fraud-Modelle verlangen.
• Verification of Payee. IBAN-Namensabgleich wird Standard für Überweisungen. Wenn dein SaaS Auszahlungs-Batches einreicht, musst du Match/No-Match/Close-Match-Antworten in deinem Auszahlungsflow verarbeiten und sie Nutzern so anzeigen, dass ein sauberer Audit-Trail entsteht.

Die Engineering-Konsequenz: Authentifizierungs- und Auszahlungsflows, die du heute als Fire-and-Forget-API-Calls behandelst, werden zu zustandsbehafteten Konversationen mit der Bank, deren Ergebnisse du speichern, anzeigen und verarbeiten musst.

Open Banking bekommt einen Performance-Vertrag

Für Produkte, die auf Kontoinformation oder Zahlungsauslösung aufbauen, ersetzt die PSR die PSD2-Debatte um Fallback-Schnittstellen durch einen klareren Deal: Banken müssen dedizierte Schnittstellen mit definierter Verfügbarkeit und Performance bereitstellen, plus Berechtigungs-Dashboards, über die Kunden Datenzugriffe sehen und widerrufen können. Im Gegenzug schrumpft die Grauzone des Screen Scraping weiter.

Praktisch heißt das: Deine Integrationsschicht sollte von API-only-Zugang ausgehen, den Berechtigungsstatus von Drittanbietern als jederzeit von außen widerrufbar behandeln und deine lokalen Consent-Datensätze gegen den Zustand im Bank-Dashboard abgleichen. Ein Consent-Modell, das nur als Boolean-Spalte in deiner Users-Tabelle existiert, wird das nicht überleben.

Fünf Architektur-Schritte für dieses Quartal

Du brauchst keinen finalen Gesetzestext, um anzufangen, denn diese Entscheidungen sind unter jedem plausiblen Ausgang wertvoll:

1. Isoliere die Payment-Schicht hinter einer internen Schnittstelle. Wenn Billing, Auszahlungen und Checkout deinen PSP von einem Dutzend Stellen aus aufrufen, konsolidiere sie hinter einem einzigen internen Service oder Modul. Scope-Fragen, Audits und Provider-Migrationen werden alle handhabbar, wenn Payments eine einzige Eingangstür haben. Das ist Standardpraxis in gut geführten Custom-Software-Projekten, und dieses Muster nachzurüsten ist weit günstiger, als Compliance in verstreute Aufrufstellen nachzurüsten.
2. Baue die Geldfluss-Karte als lebendes Artefakt. Dokumentiere jeden Pfad, auf dem Gelder, Zahlungsdaten oder Kontodaten durch dein System laufen, und halte das Dokument im Repository direkt neben dem Code, damit es sich mit dem Code ändert. Dieses eine Dokument beantwortet die Hälfte jedes Fragebogens von Regulierern oder Partnerbanken.
3. Mache Consent- und Mandats-Status zu First-Class-Entitäten. Modelliere Nutzer-Einwilligungen (Datenzugriff, Zahlungsmandate, gespeicherte Zugangsdaten) als explizite Entitäten mit Lifecycle-Events, nicht als Flags. Du wirst die Historie brauchen, nicht nur den aktuellen Wert.
4. Behandle Verification-of-Payee- und SCA-Ergebnisse als gespeicherte Events. Lege die Tabellen und Event-Typen jetzt an, auch wenn du diese Antworten heute verwirfst. Einen Audit-Trail nachträglich aufzufüllen ist unmöglich; einen aufzuzeichnen ist billig.
5. Entscheide bewusst, ob du außerhalb des Perimeters bleibst. Manchmal hält dich eine kleine Produktänderung - ein Guthaben-Feature entfernen, eine Auszahlungsverzögerung verkürzen, den Geldfluss vollständig zum PSP verlagern - sauber im Territorium des technischen Dienstleisters. Das ist eine strategische Entscheidung über deinen Tech-Stack und deine Produktrichtung, und sie verdient einen expliziten Beschluss statt Drift.

Häufig gestellte Fragen

Ist PSD3 schon in Kraft? Nein. Das Paket wurde im Juni 2023 vorgeschlagen und durchläuft noch den EU-Gesetzgebungsprozess. Die Anwendung folgt etwa 18 Monate nach der Verabschiedung. Das Vorbereitungsfenster ist real, aber kürzer als es aussieht, weil Partnerbanken Anforderungen vertraglich weitergeben, bevor gesetzliche Fristen greifen.

Wir berühren nie Gelder. Können wir die PSR ignorieren? Nicht ganz. Die Ausnahme für technische Dienstleister bleibt, aber regulierte Partner werden Pflichten vertraglich an dich durchreichen, insbesondere rund um SCA-Unterstützung, Betrugsdaten, Incident-Meldungen und Audit-Zugang. Rechtlich außerhalb des Scope zu sein heißt nicht, kommerziell außerhalb zu sein.

Ersetzt PSD3 die SCA? Nein. Die starke Kundenauthentifizierung bleibt, mit Anpassungen: mehr ergebnisbasierte Ausnahmelogik, Barrierefreiheitsanforderungen und engere Verknüpfung zwischen Authentifizierungsnachweisen und Betrugshaftung.

Wie verhält sich das zu DORA? DORA regelt die operative Resilienz von Finanzunternehmen und ihren ICT-Dienstleistern; PSD3/PSR regelt das Verhalten bei Zahlungsdiensten. Wenn du in EU-Finanzdienstleistungen verkaufst, wirst du wahrscheinlich beiden begegnen, und beide belohnen dieselbe Architektureigenschaft: ein System, dessen Datenflüsse und Abhängigkeiten du tatsächlich nachweisen kannst.

Bereite dich vor, solange es noch günstig ist

Die Teams, die unter PSD2 und DORA gelitten haben, waren nicht die mit den am stärksten regulierten Produkten; es waren die, die ihre Pflichten aus dem Fragebogen einer Partnerbank erfahren haben - mit 90 Tagen Antwortfrist. Das PSD3/PSR-Paket ist der seltene Fall, in dem du die Anforderungen Jahre im Voraus kommen siehst.

Wenn du ein zweites Paar Augen darauf willst, wo dein Produkt relativ zum neuen Perimeter steht, oder Hilfe dabei, deine Payment-Schicht zu isolieren, bevor die vertraglichen Anforderungen eintreffen, schreib an hello@wolf-tech.io oder besuche wolf-tech.io. Wir auditieren Payment-nahe Architekturen, kartieren die Geldflüsse und bauen den Modernisierungsplan gemeinsam mit deinem Team.