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.
Was ist PSD2?
PSD2 ist die zweite Zahlungsdiensterichtlinie der EU (Richtlinie (EU) 2015/2366), die seit dem 13. Januar 2018 gilt. Sie trat an die Stelle der ersten Zahlungsdiensterichtlinie. Sie öffnete Zahlungskonten für zugelassene Dritte und legte Sicherheitsvorschriften für elektronische Zahlungen fest, darunter die starke Kundenauthentifizierung.
Was ist die starke Kundenauthentifizierung (SCA)?
Die SCA erfordert mindestens zwei unabhängige Authentifizierungselemente aus drei Kategorien: Wissen, Besitz und inhärente Merkmale. Seit dem 14. September 2019 gilt sie gemäß den RTS der EBA für die meisten elektronischen Fernzahlungen und den Zugriff auf Konten.
Was ist dynamische Verknüpfung?
Bei der dynamischen Verknüpfung wird der Authentifizierungscode kryptografisch mit einem bestimmten Zahlungsbetrag und einem bestimmten Zahlungsempfänger verknüpft. Jede Änderung an einem dieser beiden Elemente macht den Code ungültig, wodurch eine Wiederholung und Manipulation der Transaktionsdaten verhindert wird.
Was sind QWACs und QSealCs?
Beides sind qualifizierte Zertifikate, die gemäß eIDAS ausgestellt werden. Ein QWAC (qualifiziertes Zertifikat zur Website-Authentifizierung) identifiziert Endpunkte und sichert den Kanal „ TLS “. Ein QSealC (qualifiziertes Zertifikat für elektronische Siegel) versiegelt API-Daten, um deren Herkunft und Integrität nachzuweisen.
Welche RTS-Artikel sind für die Kryptografie am wichtigsten?
Die Artikel 4 bis 9 befassen sich mit dem Authentifizierungscode, der dynamischen Verknüpfung, den Elementkategorien und der Unabhängigkeit. Die Artikel 18 bis 20 behandeln die TRA-Ausnahme und den Nachweis der Betrugsquote. Die Artikel 22 bis 27 befassen sich mit dem Schutz personalisierter Zugangsdaten. Die Artikel 28, 30, 34 und 35 befassen sich mit der Identifizierung und der sicheren Kommunikation für Open-Banking-APIs.
Was ist die TRA-Ausnahmeregelung?
Die Transaktionsrisikoanalyse ermöglicht es einem Anbieter, bei Zahlungen mit geringerem Risiko auf die SCA zu verzichten. Sie ist nur zulässig, wenn die dokumentierten Betrugsraten unter den RTS-Schwellenwerten bleiben und dies durch kryptografische Nachweise sowie Authentifizierungsnachweise belegt wird.
Inwiefern unterscheidet sich PSD3 von PSD2?
PSD3 verbindet eine Richtlinie mit einer unmittelbar geltenden Zahlungsverkehrsverordnung. PSD3 fasst zudem E-Geld-Institute in einem einzigen Zulassungssystem zusammen und ersetzt damit die EMD2. In Bezug auf die Authentifizierung wird erwartet, dass die Zahlungsdiensterichtlinie (PSR) im Text festlegt, dass die SCA beim Hinzufügen einer Karte zu einer digitalen Geldbörse gilt, und dass sie Authentifizierungsmethoden unterstützt, für die kein Smartphone erforderlich ist. Die tatsächliche Umsetzung wird für Ende 2027 bis 2028 erwartet. Die zentrale SCA-Verpflichtung bleibt bestehen.
Warum ist die Zertifikatsverwaltung für die PSD2-Konformität von Bedeutung?
PSD2 basiert auf qualifizierten Zertifikaten und Schlüsseln, die eine Gültigkeitsdauer haben und ordnungsgemäß validiert, erneuert und widerrufen werden müssen. Die automatisierte Erkennung, Erneuerung und Verwaltung verhindert Ausfälle, unterstützt Audits und sorgt dafür, dass Open-Banking-APIs vertrauenswürdig bleiben.
Erfordert das RTS eine gegenseitige Identifizierung ( TLS)?
Das RTS erfordert qualifizierte Zertifikate zur Identifizierung und eine gesicherte Kommunikationssitzung, wobei die gegenseitige Identifizierung ( TLS ) die gängige Marktpraxis ist, beispielsweise in der Spezifikation der Berliner Gruppe.
