PSD2 / Starke Kundenauthentifizierung:
Kryptografie für Open Banking und den Zahlungsverkehr
| Region | EU/EWR, von jedem Mitgliedstaat in nationales Recht umgesetzt |
| Anwendbarkeit | Zahlungsdienstleister für die Kontoführung (ASPSPs): Banken und Institute, die Zahlungskonten führen und verpflichtet sind, sichere APIs bereitzustellen und die SCA durchzusetzen ; Zahlungsauslösungs- und Kontoinformationsdienstleister (PISPs/AISPs): Drittanbieter , die im Rahmen von Open Banking auf Konten zugreifen; Kartenaussteller und Acquirer: wenden die SCA bei Ferntransaktionen ohne physische Vorlage der Karte an , üblicherweise über EMV 3-D Secure |
| Relevante Abschnitte | Richtlinie (EU) 2015/2366, Artikel 97: Anforderung der starken Kundenauthentifizierung Delegierte Verordnung (EU) 2018/389: Technische Regulierungsstandards (RTS) zur starken Kundenauthentifizierung (SCA) und zur gemeinsamen und sicheren Kommunikation RTS Artikel 5–9: Dynamische Verknüpfung, Unabhängigkeit der Authentifizierungselemente und Ausnahmen |
Übersicht
Die Anforderungen der PSD2 an die starke Kundenauthentifizierung gelten seit dem 14. September 2019 gemäß den technischen Regulierungsstandards der Europäischen Bankenaufsichtsbehörde. Sie schreiben für die meisten elektronischen Fernzahlungen und den Fernzugriff auf Konten eine Authentifizierung vor, bei der mindestens zwei unabhängige Elemente aus den drei Kategorien „Wissen“, „Besitz“ und „Inhärenz“ verwendet werden müssen, wobei der daraus resultierende Authentifizierungscode dynamisch an den jeweiligen Zahlungsbetrag und den Zahlungsempfänger gekoppelt ist.
Die PSD3 und eine begleitende Zahlungsdiensterichtlinie durchlaufen derzeit den EU-Gesetzgebungsprozess; mit einer realistischen Umsetzung wird zwischen 2026 und 2028 gerechnet. Es wird erwartet, dass sie den Rahmen für Ausnahmeregelungen präzisieren und die Authentifizierungsanforderungen im Bereich Open Banking verschärfen werden, doch die zugrunde liegende SCA-Verpflichtung bleibt bestehen.
Warum das wichtig ist
Verstöße gegen die SCA, insbesondere Fehler bei der dynamischen Verknüpfung und der Missbrauch der Ausnahmeregelung zur Transaktionsrisikoanalyse, gehören nach wie vor zu den häufigsten Feststellungen im Rahmen der Aufsicht durch die nationale zuständige Behörde. Nicht konforme Authentifizierungsabläufe können die Haftung für nicht autorisierte Transaktionen auf den Zahlungsdienstleister verlagern und diesen direkten Durchsetzungsmaßnahmen aussetzen.
Open Banking hat den Umfang der Bereiche erweitert, die kryptografischen Schutz erfordern: Die APIs, die ASPSPs gegenüber AISPs und PISPs offenlegen, müssen unabhängig voneinander dieselben Sicherheitsstandards für die Kommunikation erfüllen wie die kundenorientierten Kanäle, in der Regel durch qualifizierte Zertifikate gemäß eIDAS.
Wie sich dies auf die Kryptografie auswirkt
PSD2 / Die starke Kundenauthentifizierung befasst sich mit Kryptografie anhand mehrerer miteinander verknüpfter Kontrollbereiche. Die wichtigsten Bereiche mit direkten Auswirkungen auf die Kryptografie sind:
| Abschnitt | Funktion | Was dort steht | Zugehörige Produkte |
| RTS, Artikel 5 | Dynamische Verknüpfung von Authentifizierungscodes | Ein kryptografisch gebundener Authentifizierungscode, der an den jeweiligen Zahlungsbetrag und den Zahlungsempfänger geknüpft ist und so eine Wiederholung oder Manipulation der Transaktionsdaten verhindert. | EJBCA |
| RTS, Artikel 9 | Unabhängigkeit der Authentifizierungselemente | Ein zertifikats- oder schlüsselbasierter Besitzfaktor, der kryptografisch von den gleichzeitig verwendeten Wissens- und Inhärenzfaktoren isoliert ist. | EJBCA |
| RTS, Artikel 30, 35 | Sichere Kommunikation für Open-Banking-APIs | Qualifizierte Zertifikate für die Website-Authentifizierung und elektronische Siegel (QWACs/QSealCs) sowie gegenseitige TLS zur Authentifizierung von API-Sitzungen zwischen ASPSP und TPP. | EJBCA |
| RTS, Artikel 22–23 | Vertraulichkeit und Integrität personalisierter Zugangsdaten | Lebenszyklusmanagement der Zertifikate und Schlüssel, die personalisierte Sicherheitszugangsdaten vor Offenlegung oder Missbrauch schützen. | Keyfactor Command |
| RTS, Artikel 18 | Nachweise zur Transaktionsrisikoanalyse | Kryptografische und Authentifizierungsnachweise, die den dokumentierten Berechnungen der Betrugsquote zugrunde liegen, die für die Beantragung einer TRA-Ausnahme erforderlich sind. | AgileSec |
| Leitlinien zur Unterstützung von Secure-Element und App-Integrität | Integrität von Zahlungsanträgen | Signierte Versionen von Mobile-Banking- und Zahlungsanwendungen, die die Integrität des von ihnen implementierten Besitzfaktors gewährleisten. | SignServer |
Prüfungsbereitschaft
Bewertungen und Prüfungen – unabhängig davon, ob sie intern durchgeführt, von einer Aufsichtsbehörde vorgenommen oder von einem unabhängigen Gutachter überprüft werden – konzentrieren sich auf nachgewiesene Fakten und nicht allein auf Grundsatzerklärungen. Zu den wichtigsten Bereichen, die Prüfer und Gutachter üblicherweise untersuchen, gehören:
- Implementierung der dynamischen Verknüpfung: Ist der Authentifizierungscode bei jeder betreffenden Zahlung kryptografisch an den jeweiligen Transaktionsbetrag und den jeweiligen Zahlungsempfänger gebunden?
- Unabhängigkeit der Authentifizierungsfaktoren: Werden die für die SCA verwendeten Elemente „Besitz“, „Wissen“ und „Inhärenz“ tatsächlich voneinander unabhängig gehalten?
- Verwendung qualifizierter Zertifikate für Open-Banking-APIs: Werden QWACs und QSealCs für die API-Kommunikation zwischen ASPSP und TPP verwendet und auf dem neuesten Stand gehalten?
- Unterlagen zur TRA-Ausnahme: Sind die Berechnung der Betrugsquote und die Belege für eine etwaige Ausnahme aufgrund der Transaktionsrisikoanalyse dokumentiert und auf dem neuesten Stand?
- Individuelles Lebenszyklusmanagement für Zugangsdaten: Werden die Zertifikate und Schlüssel, die individuelle Sicherheitszugangsdaten schützen, im Rahmen der Ausstellung, Erneuerung und Sperrung ordnungsgemäß verwaltet?
- PSD3-/PSR1-Bereitschaft: Verfolgt die Organisation den Gesetzgebungsprozess zu PSD3 und PSR1 im Hinblick auf Änderungen des SCA und des Ausnahmeregelungsrahmens?
LEITEN SIE DIES AN DIE GESCHÄFTSFÜHRUNG WEITER
Fehler bei der dynamischen Verknüpfung und der Missbrauch der Ausnahmeregelung zur Transaktionsrisikoanalyse gehören auch sieben Jahre nach Inkrafttreten der SCA weiterhin zu den häufigsten Feststellungen bei nationalen Aufsichtsprüfungen. Hier Fehler zu machen, ist kein theoretisches Risiko: Es verlagert die Haftung für nicht autorisierte Transaktionen auf uns.
PSD3 steht bevor, doch da es die Kernverpflichtung der SCA beibehält, anstatt sie zu ersetzen, gibt es keinen Grund, damit zu warten, bevor wir die uns bereits bekannten Lücken schließen – insbesondere hinsichtlich der Verknüpfung unserer Authentifizierungscodes mit den Transaktionsdetails und der Dokumentation unserer Nachweise für die TRA-Ausnahme.
Zugehörige Compliance-Vorgaben
Datenschutz-Grundverordnung (DSGVO)
Gesetz zur digitalen Betriebsresilienz (DORA)
