Silne uwierzytelnianie klienta (SCA): PSD2 i PCI DSS razem

Silne Uwierzytelnianie Klienta (SCA – Strong Customer Authentication) wprowadzone przez PSD2 i wymagania PCI DSS dla uwierzytelniania wieloskładnikowego (MFA) to dwa różne, ale nakładające się wymogi. Europejscy sprzedawcy muszą spełnić oba jednocześnie – dla różnych podmiotów (EBA i sieci kart) i w różnych kontekstach. Ten artykuł wyjaśnia, jak te wymagania się łączą i jak tokenizacja wpisuje się w ten krajobraz.

Czym jest SCA według PSD2

Silne Uwierzytelnianie Klienta (SCA) jest wymagane przez Dyrektywę PSD2 (art. 97) i precyzowane przez Regulacyjne Standardy Techniczne EBA (RTS on SCA). SCA wymaga, aby uwierzytelnianie przy inicjowaniu transakcji elektronicznej opierało się na co najmniej dwóch z trzech elementów: wiedza (coś, co klient wie: hasło, PIN), posiadanie (coś, co klient posiada: telefon, token fizyczny), inherencja (coś, czym klient jest: biometria). W praktyce dla płatności kartą online, SCA jest typowo implementowane przez 3DS2 (3D Secure version 2).

Kiedy SCA jest wymagane i kiedy stosuje się zwolnienia

SCA jest wymagane dla transakcji elektronicznych (e-commerce) inicjowanych przez klienta. Jednak PSD2 i wytyczne EBA przewidują szereg zwolnień: transakcje poniżej 30 euro (ale z limitem kumulatywnym), transakcje o niskim ryzyku (analiza ryzyka transakcji – TRA), subskrypcje i transakcje cykliczne z stałą kwotą (zwolnienie MIT – Merchant Initiated Transactions), zaufani beneficjenci dodani do listy przez klienta. Zwolnienia muszą być stosowane przez PSP lub bank – sprzedawca może je inicjować przez odpowiednie flagi 3DS2.

Transakcje inicjowane przez sprzedawcę (MIT) a SCA

Transakcje inicjowane przez sprzedawcę (MIT) – subskrypcje, odnawialne obciążenia – są zwolnione z SCA przy każdej kolejnej transakcji, pod warunkiem że pierwsza transakcja z daną kartą przeszła SCA z wyraźną zgodą klienta na przyszłe MIT. Tokenizacja card-on-file PCI Proxy EU jest kompatybilna z przepływem MIT: token jest generowany po pierwszej transakcji z SCA, kolejne obciążenia przez token są inicjowane przez sprzedawcę z odpowiednią flagą MIT w protokole 3DS2. PSP akceptuje te transakcje bez ponownego SCA.

PCI DSS MFA vs. SCA PSD2: różne wymagania, podobne cele

PCI DSS v4.0 Wymaganie 8.4.2 wymaga MFA dla wszystkich kont z dostępem do CDE (środowisko danych kart). SCA PSD2 wymaga uwierzytelniania wieloskładnikowego dla transakcji płatniczych klientów. To dwa różne wymagania o podobnej logice bezpieczeństwa: MFA PCI DSS chroni dostęp administratorów i deweloperów do infrastruktury płatniczej; SCA PSD2 chroni transakcje klientów przed nieautoryzowanym użyciem. Sprzedawca musi wdrożyć oba – MFA dla wewnętrznych systemów (PCI DSS) i obsługę SCA przez 3DS2 dla transakcji klientów (PSD2).

3DS2 a tokenizacja: jak współpracują

3DS2 (3D Secure version 2) to protokół uwierzytelniania transakcji, który umożliwia bankom weryfikację tożsamości klienta przy transakcjach kartą online. Tokenizacja i 3DS2 są komplementarne: token PCI Proxy EU zastępuje PAN w systemach sprzedawcy, przy inicjowaniu transakcji tokenem, PCI Proxy EU detokenizuje i przekazuje PAN do PSP, PSP inicjuje przepływ 3DS2 z rzeczywistym PAN (lub tokenem sieciowym dla zaawansowanych integracji). Sprzedawca operuje wyłącznie na tokenach – proces 3DS2 jest przezroczysty z jego perspektywy i obsługiwany przez PSP.

PSD3 i przyszłość SCA w Europie

PSD3 (oczekiwana w 2025-2026 roku) ma rozszerzyć i doprecyzować wymagania SCA. Planowane zmiany: wzmocnienie wymagań SCA dla transakcji wysokiego ryzyka, nowe zasady dotyczące odpowiedzialności za nieautoryzowane transakcje, rozszerzenie wymagań na nowe metody płatności (portfele cyfrowe, pay-by-bank). Dla sprzedawców korzystających z tokenizacji PCI Proxy EU i PSP obsługujących 3DS2/3DS3, adaptacja do PSD3 będzie prostsza – cała złożoność SCA pozostaje po stronie PSP.

---