Cyfrowe uwierzytelnianie użytkownika usługi płatniczej

Monitor Prawa Bankowego 2022/07-08 Lipiec - Sierpień

Celem artykułu jest podzielenie się spostrzeżeniami, które ujawniają się po pierwszych latach obowiązywania przepisów nakładających na dostawców usług płatniczych (dalej: „dostawcy”) obowiązek stosowania procedur uwierzytelniania, w tym silnego uwierzytelniania użytkownika (dalej: „SCA”)[1].

Bartosz Wyżykowski

Etap inicjowania transakcji płatniczej, a w ślad za tym problematyka stosowania SCA, ma kluczowe znaczenie dla rozkładu ryzyka i odpowiedzialności za wykonanie przez dostawcę transakcji nieautoryzowanej. Pomijając sytuacje szczególne (np. błędy w działaniu infrastruktury lub oprogramowania dostawcy, przestępcze zachowania jego pracowników), podstawową przyczyną wykonania takich transakcji jest nieprawidłowe ustalenie (weryfikacja) przez dostawcę tożsamości osoby składającej zlecenie płatnicze[2]. W związku z tym, że w ostatnich latach następuje dynamiczny rozwój płatności inicjowanych elektronicznie lub zdalnie, kluczowego znaczenia nabierają cyfrowe metody uwierzytelniania użytkowników. Problematyka ta jest niezwykle rozległa, stale ewoluuje i obejmuje liczne zagadnienia techniczne, technologiczne oraz prawne. Stąd niniejszy artykuł stanowi jedynie przyczynek, poruszający wybrane wątki problemowe.  

Z art. 32i ust. 1 u.u.p.[3] wynika, że  dostawca zobowiązany jest stosować SCA w trzech przypadkach, a mianowicie gdy płatnik: 1) uzyskuje dostęp do swojego rachunku w trybie online, 2) inicjuje elektroniczną transakcję płatniczą lub 3) przeprowadza za pomocą kanału zdalnego czynność, która może wiązać się z ryzykiem oszustwa związanego z wykonywanymi usługami płatniczymi lub innych nadużyć. Dodatkowo, art. 24 ust. 2 lit. b RTS stanowi, że dla celów określonych w art. 24 ust. 1 RTS, dostawcy obowiązani są zapewnić, aby powiązanie tożsamości użytkownika usług płatniczych z indywidualnymi danymi uwierzytelniającymi, urządzeniami uwierzytelniającymi lub oprogramowaniem uwierzytelniającym za pomocą kanału zdalnego przeprowadzane było z zastosowaniem SCA. Z kolei art. 46 ust. 4a zd. 1 u.u.p. stanowi, że brak wymagania przez dostawcę płatnika SCA wyłącza odpowiedzialność płatnika z tytułu nieautoryzowanej transakcji płatniczej, chyba że działał on umyślnie. Jednocześnie na podstawie art. 33 u.u.p. dostawca i użytkownik niebędący konsumentem mogą uzgodnić, że określonych przepisów u.u.p. (w tym wspomnianego art. 46 ust. 4a zd. 1 u.u.p.) nie stosuje się w całości lub części. Zastosowanie znajdują wówczas ogólne przepisy prawa cywilnego[4].

Ustalenie, czy dostawca należycie zastosował SCA, determinuje zatem rozkład ryzyka i odpowiedzialności z tytułu nieautoryzowanej transakcji płatniczej (choć oczywiście o odpowiedzialności tej przesądzać mogą również inne przesłanki[5]). Ma to kluczowe znacznie wówczas, gdy art. 46 ust. 4a zd. 1 u.u.p. znajduje zastosowanie. W razie jego wyłączenia na mocy wspomnianego art. 33 u.u.p., a więc gdy zastosowanie znajdują normy ogólne wynikające z przepisów k.c.[6], a w przypadku banków dodatkowo odtwarzane na podstawie przepisów p.b.[7], okoliczność, czy dostawca należycie uwierzytelnił użytkownika, pozostaje również istotna dla ustalenia, czy dostawca taki jest zobowiązany zwrócić płatnikowi kwotę transakcji nieautoryzowanej lub przywrócić rachunek do stanu, który istniałby, gdyby taka transakcja nie miała miejsca, czy też uprawnione będzie przerzucenie ryzyka wynikającego z takiej transakcji na płatnika.

Warto już na wstępie odnotować subtelną różnicę w pojęciach, którymi posługują się, odpowiednio, art. 32i ust. 1 i 2 oraz art. 46 ust. 4a u.u.p. Pierwszy przepis nakłada obowiązek stosowania SCA przez dostawców. Drugi wyłącza odpowiedzialność płatnika z tytułu nieautoryzowanej transakcji płatniczej, gdy dostawca płatnika nie wymaga SCA (art. 46 ust. 4a zd. 1 u.u.p.), oraz określa odpowiedzialność regresową odbiorcy i jego dostawcy, gdy podmioty te nie akceptują SCA (art. 46 ust. 4a zd. 2 u.u.p.). Należy uznać, że to dostawca płatnika (dostawca prowadzący rachunek) – jako podmiot wydający użytkownikowi indywidualne dane uwierzytelniające[8] lub instrument płatniczy – stosuje (wymaga) SCA, gdy określone w art. 32i ust. 1 u.u.p. czynności (w tym transakcje) inicjowane są z udziałem płatnika. Obejmuje to również transakcje inicjowane za pośrednictwem odbiorcy[9]. Brak jest natomiast obowiązku stosowania SCA, gdy transakcje inicjowane są wyłącznie przez odbiorcę (np. polecenie zapłaty)[10]. Odbiorca i jego dostawca akceptują SCA, wykonując odpowiednie czynności w imieniu dostawcy płatnika lub na jego rzecz bądź umożliwiając ich wykonywanie przez niego za swoim pośrednictwem. Odbiorca z założenia nie ma statusu dostawcy, a zatem nawet odwołując się do literalnego brzmienia art. 32i ust. 1 i 2 u.u.p., nie spoczywa na nim obowiązek stosowania SCA. Mimo że z art. 32i ust. 1 i 2 u.u.p. (a także art. 97 ust. 1 i 2 PSD2) lege non distinguente mogłoby wynikać, że SCA stosują również dostawcy świadczący usługę inicjowania transakcji płatniczej (dalej: „PISP”) oraz dostawcy świadczący usługę dostępu do informacji o rachunku (dalej: „AISP”), Europejski Urząd Nadzoru Bankowego (dalej: „EUNB”) zdaje się prezentować odmienne stanowisko[11].

Na gruncie art. 17 RTS na płaszczyźnie normatywnej można dodatkowo wyodrębnić metody uwierzytelniania, które jakkolwiek zapewniają (mają zapewniać) poziom bezpieczeństwa równoważny co najmniej poziomowi przewidzianemu w PSD2, nie stanowią SCA w rozumieniu przepisów tej dyrektywy, u.u.p. ani RTS. Przywołany przepis określa jedno z wyłączeń zwalniających dostawcę z nakazu stosowania SCA, zarazem nakładając na niego równoległy obowiązek stosowania odpowiednio bezpiecznych procedur uwierzytelniania, które jednak nie stanowią SCA. Jakkolwiek regulacja ta ma charakter niszowy, dostawcy (w szczególności banki) nierzadko rozważają skorzystanie z tego wyłączenia. Dotychczas w piśmiennictwie pojawiły się jedynie nieliczne wypowiedzi odnoszące się do tego przepisu[12]. Istnieje, co prawda, szereg wypowiedzi EUNB[13], niemniej znikoma literatura uzasadnia nieco bardziej poszerzoną analizę tej materii.

Identyfikacja a uwierzytelnianie użytkownika

Zgodnie z art. 2 pkt 33b u.u.p. uwierzytelnianie oznacza procedurę umożliwiającą dostawcy weryfikację tożsamości użytkownika lub ważności stosowania konkretnego instrumentu płatniczego, łącznie ze stosowaniem indywidualnych danych uwierzytelniających. Podobnie w art. 2 pkt 24a lit. a u.u.p. mowa jest o uwierzytelnieniu instrumentu płatniczego lub użytkownika tego instrumentu.

Do celów uwierzytelniania dostawca zobowiązany jest zapewnić użytkownikowi szczególny rodzaj danych, tj. indywidualne dane uwierzytelniające[14]. Jest to nowe pojęcie wprowadzone w wyniku implementacji PSD2. Zastąpiło ono pojęcie „indywidualnych zabezpieczeń”, którym posługiwały się PSD1[15] oraz przepisy u.u.p. w pierwotnym brzmieniu wynikającym z implementacji PSD1, przed wprowadzeniem zmian określonych w PSD2)[16]. W niemieckiej doktrynie – oprócz uwierzytelnienia (niem. Authentifizierung) – wyróżnia się również pojęcie Authentisierung (które w wolnym tłumaczeniu można określić jako „poświadczenie”), przez które rozumie się przedłożenie środków uwierzytelniających w celu poświadczenia tożsamości z perspektywy osoby (...)