Europäische Händler navigieren in einem komplexen Regulierungsraum mit mindestens drei überschneidenden Anforderungsrahmen: PSD2 (Zahlungsdiensterichtlinie 2), PCI DSS (Payment Card Industry Data Security Standard) und DSGVO. Von diesen ist die Starke Kundenauthentifizierung (SCA) unter PSD2 am häufigsten missverstanden: Viele Händler verwechseln SCA mit PCI DSS-Anforderungen oder glauben, dass SCA-Compliance PCI DSS-Compliance impliziert. Dies ist ein gefährlicher Irrtum.
Was ist Starke Kundenauthentifizierung (SCA)?
SCA (Strong Customer Authentication, auf Deutsch: Starke Kundenauthentifizierung) ist eine Anforderung aus PSD2, die von der Europäischen Bankenaufsichtsbehörde (EBA) durch Technische Regulierungsstandards (RTS) konkretisiert wurde. SCA verlangt, dass elektronische Zahlungen durch mindestens zwei von drei Kategorien authentifiziert werden:
- Wissen: Etwas, das nur der Nutzer weiß (PIN, Passwort)
- Besitz: Etwas, das nur der Nutzer besitzt (Smartphone, Hardware-Token)
- Inhärenz: Etwas, das der Nutzer ist (Fingerabdruck, Gesichtserkennung)
In der Praxis ist SCA am häufigsten als 3D Secure 2.0 (3DS2) implementiert, das Protokoll, das Visa (Visa Secure) und Mastercard (Identity Check) für die Zwei-Faktor-Authentifizierung bei Online-Transaktionen verwenden.
SCA (PSD2) vs. PCI DSS: Die wichtigsten Unterschiede
SCA und PCI DSS haben unterschiedliche Ziele und Geltungsbereiche:
- PSD2/SCA: Europäisches Gesetz, das von Zahlungsdienstleistern die starke Authentifizierung von Zahlern verlangt. Schützt den Zahlenden vor unautorisierter Nutzung seiner Zahlungsmethode. Gilt für den Authentifizierungsmoment der Transaktion.
- PCI DSS: Industriestandard, der von Kartennetzwerken verlangt, dass Kartendaten sicher gespeichert, verarbeitet und übertragen werden. Schützt die Kartendaten während des gesamten Lebenszyklus. Gilt für alle Systeme, die Kartendaten berühren.
SCA-Compliance bedeutet nicht PCI DSS-Compliance. Ein Händler kann 3DS2 korrekt implementiert haben (SCA-konform) und gleichzeitig Kartendaten unsicher in einer Datenbank speichern (PCI DSS-verletzend). Beide Anforderungen müssen separat erfüllt werden.
Wie 3DS2 in PCI DSS-Scope-Überlegungen passt
Die Implementierung von 3DS2 kann PCI DSS-Implikationen haben, je nachdem, wie sie technisch umgesetzt wird:
- Wenn der 3DS2-Flow durch Ihren eigenen Server geleitet wird (Server-seitige 3DS2-Implementierung), müssen diese Server in Ihren PCI DSS-Scope einbezogen werden.
- Wenn 3DS2 vollständig durch das JavaScript SDK des Zahlungsdienstleisters auf der Client-Seite abgehandelt wird, ohne dass Kartendaten Ihren Server berühren, verlässt dieser Teil die CDE.
- Eine Tokenisierungslösung, die auch 3DS2 integriert (wie PCI Proxy EU), ermöglicht die vollständige SCA-Implementierung ohne eigene Server in der CDE.
SCA-Ausnahmen und ihre PCI DSS-Implikationen
PSD2 und die RTS der EBA definieren mehrere SCA-Ausnahmen, die keine 3DS2-Authentifizierung erfordern:
- Geringe Transaktionswerte: Transaktionen unter 30 € (mit kumulativen Limits)
- Risikoanalyse (TRA): Transaktionen mit niedrigem Betrugsprofil, die von der Issuer-Bank als geringes Risiko eingestuft werden
- Vertrauenswürdige Begünstigte: Händler auf einer Whitelist des Karteninhabers
- Wiederkehrende Transaktionen: Abonnements mit festem Betrag und Empfänger (erste Transaktion erfordert SCA)
- MOTO-Transaktionen: Telefonisch initiierte Zahlungen (außerhalb des SCA-Scopes, aber PCI DSS-relevant)
MOTO-Transaktionen (Telefonbestellungen) sind besonders wichtig: PSD2/SCA gilt nicht für MOTO, aber PCI DSS gilt uneingeschränkt. Händler, die MOTO-Transaktionen durchführen, müssen sicherstellen, dass Kartendaten nicht telefonisch empfangen und in interne Systeme eingegeben werden.
Tokenisierung als gemeinsamer Nenner
Tokenisierung ist die Technologie, die SCA-Implementierung und PCI DSS-Compliance am elegantesten verbindet:
- Ein Tokenisierungsanbieter kann den gesamten Zahlungsflow abwickeln: Kartendaten-Erfassung, 3DS2-Authentifizierung, Autorisierung und Token-Ausgabe.
- Ihre Systeme erhalten nur den Token und den Transaktionsstatus, niemals den PAN oder die 3DS2-Authentifizierungsdaten.
- SCA-Ausnahmen (TRA, wiederkehrende Zahlungen) werden vom Tokenisierungsanbieter verwaltet, der die notwendige Verbindung mit den Acquiring-Banken hat.
Häufig gestellte Fragen
Wenn ein Kunde 3DS2-authentifiziert, bin ich gegen Chargebacks geschützt?
In der Regel ja. Wenn eine Transaktion erfolgreich durch 3DS2 authentifiziert wurde, verschiebt sich die Haftung für Betrug (Fraud Liability Shift) vom Händler zur kartenausgebenden Bank. Das bedeutet nicht, dass Chargebacks völlig ausgeschlossen sind (z.B. bei Nichtlieferung), aber fraudbasierte Chargebacks sollten vom Liability Shift abgedeckt sein. Konsultieren Sie Ihren Acquirer für die genauen Bedingungen.
Gilt PSD2/SCA auch für B2B-Transaktionen?
PSD2 gilt hauptsächlich für Verbrauchertransaktionen. B2B-Transaktionen, bei denen beide Parteien Unternehmen sind (d.h. kein Endverbraucher beteiligt), können von bestimmten PSD2-Anforderungen ausgenommen sein, je nach Implementierung des nationalen Rechts. PCI DSS gilt jedoch unabhängig davon, ob die Transaktion B2B oder B2C ist: Wenn Kartendaten verarbeitet werden, gelten die PCI DSS-Anforderungen.
SCA und PCI DSS gemeinsam meistern: PCI Proxy EU integriert 3DS2-Authentifizierung und Tokenisierung in einem einzigen Compliance-freundlichen Flow. PCI Proxy EU entdecken.