PSD2 und starke Kundenauthentifizierung: Kryptografie für Open Banking und den Zahlungsverkehr

Warum die Kryptografie nun im Mittelpunkt der PSD2 steht

Die Einhaltung der PSD2 und der SCA ist eine kryptografische Verpflichtung und keine bloße Abhakaufgabe. Die starke Kundenauthentifizierung (SCA) gilt seit dem 14. September 2019 für die meisten elektronischen Fernzahlungen gemäß der Delegierten Verordnung (EU) 2018/389 der Kommission und den von der Europäischen Bankenaufsichtsbehörde entwickelten technischen Regulierungsstandards (RTS). Mehrere nationale Behörden führten bis ins Jahr 2020 hinein eine schrittweise Umstellung für den kartenbasierten E-Commerce durch. Hinter jedem konformen Authentifizierungsablauf steht ein Satz von Schlüsseln, Zertifikaten und kryptografischen Verknüpfungen, die korrekt funktionieren und auf dem neuesten Stand bleiben müssen.

Open Banking hat den Umfang der Bereiche erweitert, die diesen Schutz benötigen. Mit der PSD2 wurden Zahlungskonten für zugelassene Dritte geöffnet, sodass Banken nun APIs bereitstellen, die denselben Sicherheitsstandards für die Kommunikation entsprechen müssen wie die Kanäle mit direktem Kundenkontakt. Dieser Leitfaden erläutert die Anforderungen der Vorschriften und die Kryptografie, die den jeweiligen Kontrollmaßnahmen entspricht.

Was die PSD2 und die starke Kundenauthentifizierung tatsächlich erfordern

Die Kernregel ist einfach. Die SCA schreibt für die meisten elektronischen Fernzahlungen und den Fernzugriff auf Konten eine Authentifizierung vor, bei der mindestens zwei unabhängige Elemente aus drei Kategorien verwendet werden müssen. Bei Fernzahlungstransaktionen muss der Authentifizierungscode dynamisch mit dem jeweiligen Betrag und dem jeweiligen Zahlungsempfänger verknüpft sein.

Die drei Kategorien von Authentifizierungsfaktoren

Die drei Kategorien sind Wissen, Besitz und Inhärenz:

• Wissen: etwas, das nur der Benutzer weiß, wie beispielsweise ein Passwort oder eine PIN.
• Besitz: Etwas, das ausschließlich der Benutzer besitzt, wie beispielsweise ein registriertes Gerät oder ein auf einem Sicherheitselement gespeicherter Schlüssel.
• Inhärenz: etwas, das den Nutzer ausmacht, wie beispielsweise ein Fingerabdruck oder ein Gesichtsscan.

„Zwei unabhängige Elemente“ bedeutet, dass die Faktoren aus mindestens zwei dieser Kategorien stammen müssen. Sie müssen zudem unabhängig voneinander sein, sodass die Beeinträchtigung eines Faktors keine Auswirkungen auf die anderen hat. Diese Unabhängigkeit ist eine technische Eigenschaft und nicht nur eine grundsätzliche Aussage.

Die regulatorischen Anker

Die Verpflichtung ergibt sich aus den genannten Rechtsakten. Die grundlegende Anforderung ist Artikel 97 der Richtlinie (EU) 2015/2366. Die technischen Einzelheiten sind in der Delegierten Verordnung (EU) 2018/389 der Kommission, den technischen Regulierungsstandards (RTS) zur starken Kundenauthentifizierung sowie zur gemeinsamen und sicheren Kommunikation, geregelt.

Innerhalb der RTS kommt einer Reihe von Artikeln besondere Bedeutung zu. Die Artikel 4 bis 9 befassen sich mit der Authentifizierung von Code und dessen dynamischer Verknüpfung sowie mit der Unabhängigkeit von Authentifizierungselementen. Die Voraussetzungen für Ausnahmen sind in den Artikeln 10 bis 21 geregelt. Die nachfolgenden Artikel regeln die sichere Kommunikation und den Schutz personalisierter Sicherheitszugangsdaten.

Wer fällt in den Geltungsbereich?

Die PSD2 betrifft verschiedene Akteure, und für jeden von ihnen steht bei dem Ergebnis etwas auf dem Spiel, was die Kryptografie betrifft.

Zahlungsdienstleister für die Kontoführung (ASPSPs)

ASPSPs sind die Banken und Institute, die Zahlungskonten führen. Sie müssen lizenzierten Dritten sichere APIs zur Verfügung stellen und bei Kontozugriffen und Zahlungen die SCA durchsetzen. Außerdem legen sie fest, wie ihre Schnittstelle die sich mit ihr verbindenden Parteien authentifiziert.

Zahlungsauslösungs- und Kontoinformationsdienstleister (PISPs und AISPs)

PISPs veranlassen Zahlungen im Namen eines Nutzers, und AISPs bündeln Kontoinformationen. Bei beiden handelt es sich um Drittanbieter, die im Rahmen von Open Banking auf Konten zugreifen. Um eine Verbindung herzustellen, müssen sie sich gegenüber dem ASPSP mithilfe qualifizierter Zertifikate identifizieren und über einen gesicherten Kanal kommunizieren. Auch Emittenten kartenbasierter Zahlungsinstrumente (CBPIIs) greifen auf Konten zu, um die Verfügbarkeit von Guthaben zu überprüfen, und unterliegen denselben Vorschriften hinsichtlich Identifizierung und sicherer Kommunikation.

Kartenaussteller und Acquirer

Kartenaussteller und Acquirer wenden die SCA bei Fernzahlungen ohne physische Vorlage der Karte an. In der Praxis erfolgt dies üblicherweise über EMV 3-D Secure. Dieses Protokoll übernimmt die Authentifizierung sowie die dynamische Verknüpfung zwischen Händler, Acquirer und Kartenaussteller.

Wie sich die PSD2 auf die Kryptografie bezieht – Maßnahme für Maßnahme

Dies ist der analytische Kern. Jeder RTS-Kontrollbereich entspricht einem bestimmten kryptografischen Mechanismus. Jeder der folgenden Unterabschnitte ist in sich abgeschlossen; beantworten Sie diese zunächst.

Dynamische Verknüpfung von Authentifizierungscodes (RTS-Artikel 4 und 5)

Bei der dynamischen Verknüpfung wird der Authentifizierungscode an eine bestimmte Zahlung gebunden. Der Code ist kryptografisch an den genauen Betrag und den Zahlungsempfänger geknüpft, sodass jede Änderung an einem dieser beiden Elemente ihn ungültig macht. Dies verhindert Replay-Angriffe und verhindert, dass ein Angreifer die Transaktionsdaten nach der Genehmigung manipulieren kann.

Unabhängigkeit der Authentifizierungselemente (RTS Artikel 9)

Durch die Unabhängigkeit werden die Faktoren kryptografisch voneinander getrennt. Ein zertifikats- oder schlüsselbasierter Besitzfaktor ist von den parallel dazu verwendeten Wissens- und Inhärenzfaktoren isoliert. Sollte ein Kanal oder ein Element kompromittiert werden, verhindert diese Isolierung, dass die anderen ebenfalls kompromittiert werden.

Sichere Kommunikation für Open-Banking-APIs (RTS-Artikel 28, 30, 34 und 35)

Open-Banking-APIs müssen beide Seiten authentifizieren und die Daten während der Übertragung schützen. Die RTS stützt sich auf qualifizierte Zertifikate, die gemäß eIDAS ausgestellt wurden. Dabei kommen zwei Arten zum Einsatz: qualifizierte Zertifikate für die Website-Authentifizierung (QWACs) und qualifizierte Zertifikate für elektronische Siegel (QSealCs).

Die beiden Zertifikatstypen erfüllen unterschiedliche Aufgaben. Ein QWAC identifiziert die Endpunkte und sichert den Kommunikationskanal, während ein QSealC die Anwendungsdaten versiegelt, um deren Herkunft und Integrität nachzuweisen. Anschließend wird die API-Sitzung zwischen ASPSP und TPP mittels gegenseitiger Authentifizierung ( TLS ) authentifiziert.

Die APIs, die ASPSPs gegenüber AISPs und PISPs bereitstellen, müssen denselben Sicherheitsstandards für die Kommunikation genügen wie ihre kundenorientierten Kanäle.

Vertraulichkeit und Integrität personalisierter Zugangsdaten (RTS Artikel 22 bis 27)

Personalisierte Sicherheitszugangsdaten müssen über ihren gesamten Lebenszyklus hinweg geschützt werden. Das bedeutet eine konsequente Verwaltung der Zertifikate und Schlüssel, die diese Zugangsdaten vor Offenlegung oder Missbrauch schützen. Mängel bei der Ausstellung, Speicherung oder Erneuerung dieser Schlüssel untergraben jede darauf aufbauende Authentifizierung.

Nachweis der Befreiung von der Transaktionsrisikoanalyse (RTS Artikel 18 bis 20)

Die Ausnahmeregelung zur Transaktionsrisikoanalyse (TRA) ermöglicht es einem Anbieter, bei Zahlungen mit geringerem Risiko auf die SCA zu verzichten, allerdings nur bei Vorlage entsprechender Nachweise. Die dokumentierten Berechnungen der Betrugsquote, die einem TRA-Antrag zugrunde liegen, stützen sich auf kryptografische Daten und Authentifizierungsdaten. Steigt die erfasste Betrugsrate über die in den RTS festgelegten Schwellenwerte, erlischt das Recht auf Inanspruchnahme der Ausnahmeregelung.

Integrität von Zahlungsanträgen (RTS Artikel 9 Absatz 3)

Der Besitzfaktor ist nur so vertrauenswürdig wie die App, die ihn umsetzt. Artikel 9 Absatz 3 schreibt auf Mehrzweckgeräten getrennte, sichere Ausführungsumgebungen sowie Mechanismen vor, die bestätigen, dass die software oder das Gerät nicht verändert wurde. Signierte Versionen von Mobile-Banking- und Zahlungsanwendungen schützen diese Integrität. Durch die Codesignierung kann ein Gerät überprüfen, ob eine Version tatsächlich vom Anbieter stammt und während der Übertragung nicht verändert wurde.

Worauf Prüfer achten: Prüfungsbereitschaft

Bei Aufsichtsprüfungen stehen nachweisbare Fakten im Mittelpunkt, nicht allein Grundsatzerklärungen. Eine sinnvolle Vorbereitung besteht darin, sich selbst anhand der Kontrollmechanismen zu überprüfen, die ein Prüfer untersuchen wird. Behandeln Sie jeden Punkt so, als müssten Sie ihn nachweisen können – nicht nur beschreiben.

• Dynamische Verknüpfung: Zeigen Sie, dass der Authentifizierungscode an den Betrag und den Zahlungsempfänger gebunden ist und dass Änderungen ihn ungültig machen.
• Unabhängigkeit der Faktoren: Zeigen Sie, dass der Besitzfaktor kryptografisch von den anderen Elementen isoliert ist.
• Qualifizierte Zertifikate: Weisen nach, dass QWACs und QSealCs für Open-Banking-APIs gültig, aktuell und korrekt verwendet sind.
• Unterlagen zur TRA-Befreiung: Legen Sie Nachweise zur Betrugsquote vor, die jede geltend gemachte Befreiung belegen.
• Lebenszyklus von Anmeldedaten: Nachweis, dass Zertifikate und Schlüssel, die personalisierte Anmeldedaten schützen, durchgängig verwaltet werden.
• PSD3- und PSR-Bereitschaft: Legen Sie einen Plan für die bevorstehende Aktualisierung des Rahmens für Ausnahmeregelungen und Authentifizierung vor.

Was auf dem Spiel steht: Haftung, Durchsetzung und Risiken im Zusammenhang mit Open Banking

Fehler bei der SCA haben konkrete Konsequenzen. Verstöße gegen die SCA, insbesondere Fehler bei der dynamischen Verknüpfung und der Missbrauch der TRA-Ausnahme, gehören nach wie vor zu den häufigsten Feststellungen bei der Aufsicht durch die nationalen zuständigen Behörden. Gemäß Artikel 74 Absatz 2 der PSD2 trägt der Zahler, sofern der Zahlungsdienstleister des Zahlers keine SCA verlangt, keinen finanziellen Verlust, sofern kein Betrug seitens des Zahlers vorliegt, und ein Zahlungsempfänger oder dessen Zahlungsdienstleister, der die SCA nicht akzeptiert, entschädigt den Zahlungsdienstleister des Zahlers.

Open Banking erhöht das Risiko noch weiter. Jede API, die eine Bank Dritten zur Verfügung stellt, ist ein weiterer Kanal, der dieselben kryptografischen Anforderungen erfüllen muss. Ein abgelaufenes qualifiziertes Zertifikat bei einer dieser APIs bedeutet sowohl einen Ausfall als auch eine Compliance-Lücke und kann direkte Durchsetzungsmaßnahmen nach sich ziehen.

Ausblick: PSD3, PSR und Post-Quantum-Bereitschaft

PSD2 ist nicht das letzte Wort. Das Europäische Parlament und der Rat haben am 27. November 2025 eine vorläufige politische Einigung über PSD3 und die Zahlungsdiensterichtlinie (PSR) erzielt, und der Rat hat am 23. April 2026 die endgültigen Kompromisstexte veröffentlicht. Die formelle Verabschiedung und die Veröffentlichung im Amtsblatt stehen noch aus. Die zentralen Verhaltensregeln der PSR gelten etwa 18 bis 21 Monate nach Inkrafttreten, sodass mit einer realistischen Anwendung Ende 2027 bis 2028 zu rechnen ist. Bis dahin bleibt die PSD2 der geltende Rechtsrahmen.

Diese Maßnahmen sollen den Rahmen für Ausnahmeregelungen präzisieren und die Authentifizierung im Rahmen des Open Banking stärken. Die zugrunde liegende SCA-Verpflichtung bleibt bestehen.

Parallel dazu rückt eine zweite Frist näher. Das NIST hat die Standards FIPS 203, 204 und 205 im August 2024 endgültig verabschiedet. Der Zeitplan für die Umstellung ist in einem separaten Dokument, NIST IR 8547, festgehalten, das sich noch im Stadium eines ersten öffentlichen Entwurfs befindet. Demnach werden quantenangreifbare Algorithmen für öffentliche Schlüssel, darunter RSA, ECDSA, ECDH und Diffie-Hellman im endlichen Körper, nach 2030 als veraltet eingestuft und nach 2035 nicht mehr zugelassen.

Am 13. Januar 2026 veröffentlichte die G7-Cyber-Expertengruppe unter dem Vorsitz des US-Finanzministeriums und der Bank of England einen abgestimmten Fahrplan für die Umstellung auf Post-Quanten-Technologie im Finanzsektor. Darin werden sechs Phasen dargelegt, die von der Sensibilisierung und Vorbereitung über die Bestandsaufnahme, Risikobewertung, Planung und Umsetzung bis hin zur Validierung reichen, und es wird darauf hingewiesen, dass der Fahrplan weder Leitlinien noch regulatorische Erwartungen festlegt.

Der Zeitplan für die Zahlungsinfrastruktur ist enger, als es auf den ersten Blick scheint. SWIFT hat angekündigt, dass SwiftNet 8.0 im Jahr 2027 postquantenfest sein soll, wobei den teilnehmenden Instituten ein Migrationszeitraum von 15 Monaten eingeräumt wird. Jüngste Umfragen zeigen jedoch, dass nur ein geringer Prozentsatz der Finanzinstitute weltweit bereits mit der eigentlichen Migration begonnen hat.

Die erfassten Daten können später entschlüsselt werden, sodass der Zeitrahmen für die Vertraulichkeit der Daten die eigentliche Frist vorgibt. Daher ist Krypto-Agilität bereits heute eine Priorität im Zeitalter der PSD2 und nicht erst in der Zukunft.

Wie „ Keyfactor “ die Einhaltung der PSD2- und SCA-Vorschriften unterstützt

Keyfactor unterstützt regulierte Zahlungsdienstleister dabei, das kryptografische Vertrauen zu verwalten, von dem die Einhaltung der PSD2- und SCA-Vorschriften abhängt. Die Zuordnung von RTS-Kontrollmaßnahmen zu den Produkten erfolgt direkt.

EJBCA Sie stellt die Zertifikate für dynamische Verknüpfung, Faktorenunabhängigkeit und gegenseitige TLS aus und verwaltet diese, einschließlich der Ausstellung von QWAC- und QSealC-Zertifikaten. Es handelt sich um eine standardkonforme PKI, die für postquanten- und hybride Zertifikate vorbereitet ist.

SignServer unterzeichnet Zahlungsanträge und Freigaben für das Mobile Banking und gewährleistet so die Integrität des Besitzfaktors, den diese Apps umsetzen. AgileSec ermittelt und erfasst kryptografische Ressourcen und liefert damit die Faktengrundlage für die TRA-Dokumentation und die Post-Quantum-Planung.

Keyfactor Command führt ein aktuelles Verzeichnis aller Zertifikate und Schlüssel, die personalisierte Zugangsdaten und Open-Banking-APIs schützen. Die Verlängerung erfolgt automatisch rechtzeitig vor Ablauf, sodass ein qualifiziertes Zertifikat niemals zu einem Ausfall oder einem Beanstandungspunkt bei einem Audit führt.

Die „ Keyfactor “-Trust-Control-Plane vereint all dies in einer einzigen Plattform, die alle kryptografischen Assets und Maschinenidentitäten in den Bereichen Kernbankwesen, Zahlungsverkehr und Open-Banking-Infrastruktur überwacht, analysiert, bereitstellt, orchestriert und steuert, sodass die von jedem Rahmenwerk geforderten Nachweise aus einem einzigen System of Record stammen. Dies ist die Grundlage, an der sowohl die heutige PSD2 als auch die künftige PSD3 gemessen werden.

Zusammenfassung und nächste Schritte

SCA ist eine kryptografische Funktion und keine einmalige Sicherheitsmaßnahme. Die Regeln lassen sich in konkrete Elemente umsetzen: an Transaktionsdaten gebundene Authentifizierungscodes, isolierte Besitzfaktoren, qualifizierte Zertifikate an jeder Open-Banking-Schnittstelle sowie dokumentierte Nachweise zur Betrugsrate.

Unabhängig davon, wo eine Einrichtung derzeit steht, gelten vier praktische Ansatzpunkte:

• Erstellen Sie eine Bestandsaufnahme der Zertifikate und Schlüssel, die der Authentifizierung und den Open-Banking-APIs zugrunde liegen.
• Stellen Sie sicher, dass die dynamische Verknüpfung funktioniert und dass die Authentifizierungsfaktoren tatsächlich unabhängig voneinander sind.
• Sorgen Sie dafür, dass qualifizierte Zertifikate für Open-Banking-APIs gültig und auf dem neuesten Stand bleiben.
• Dokumentieren Sie die Betrugsquote und die kryptografischen Nachweise, die jeder TRA-Ausnahme zugrunde liegen.

Da es sich hierbei eher um ein fortlaufendes Programm als um ein Projekt handelt, sorgt diese Grundlage dafür, dass jede neue Anforderung – sei es PSD3, PSR oder eine Post-Quantum-Frist – auf eine Infrastruktur trifft, die diese bereits erfüllt. Demo anfordern

Haben Sie Fragen zu PSD2 und SCA? Wir haben die Antworten.

What is PSD2?
PSD2 is the EU’s Second Payment Services Directive, Directive (EU) 2015/2366, applicable since January 13, 2018. It replaced the first Payment Services Directive. It opened payment accounts to licensed third parties and set security rules for electronic payments, including Strong Customer Authentication.

What is Strong Customer Authentication (SCA)?
SCA requires at least two independent authentication elements from three categories: knowledge, possession, and inherence. It has applied to most remote electronic payments and account access since September 14, 2019, under the EBA’s RTS.

What is dynamic linking?
Dynamic linking cryptographically ties the authentication code to a specific payment amount and payee. Any change to either invalidates the code, which prevents replay and tampering with the transaction details.

What are QWACs and QSealCs?
Both are qualified certificates issued under eIDAS. A QWAC (qualified website authentication certificate) identifies endpoints and secures the TLS channel. A QSealC (qualified electronic seal certificate) seals API data to prove its origin and integrity.

Which RTS articles matter most for cryptography?
Articles 4 to 9 cover the authentication code, dynamic linking, the element categories, and independence. Articles 18 to 20 cover the TRA exemption and its fraud-rate evidence. Articles 22 to 27 cover personalized credential protection. Articles 28, 30, 34, and 35 cover identification and secure communication for open banking APIs.

What is the TRA exemption?
Transaction risk analysis lets a provider skip SCA on lower-risk payments. It is allowed only where documented fraud rates stay below RTS thresholds, backed by supporting cryptographic and authentication evidence.

How is PSD3 different from PSD2?
PSD3 pairs a directive with a directly applicable Payment Services Regulation.  PSD3 also folds e-money institutions into a single licensing regime, replacing EMD2. On authentication, the PSR is expected to state in the text that SCA applies to adding a card to a digital wallet, and to support authentication methods that do not require a smartphone. Realistic application is late 2027 to 2028. The core SCA obligation remains.

Why does certificate management matter for PSD2 compliance?
PSD2 depends on qualified certificates and keys that expire and must be validated, renewed, and revoked correctly. Automated discovery, renewal, and governance prevent outages, support audits, and keep open banking APIs trusted.

Does the RTS require mutual TLS?
The RTS requires qualified certificates for identification and a protected communication session, and that mutual TLS is the common market implementation, for example in the Berlin Group specification.