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 określającej swoją tożsamość[17].

Warto odnotować, że choć zarówno w u.u.p., jak i PSD2 mowa jest o uwierzytelnianiu i co więcej, prawodawca zdecydował się na wprowadzenie definicji legalnej tego pojęcia[18], w istocie wspomniane przepisy nie nakładają na dostawców samoistnego obowiązku stosowania uwierzytelnienia. Artykuł 32i ust. 1 i 2 u.u.p. określają okoliczności, w których dostawcy zobowiązani są stosować SCA, czyli jedną z postaci uwierzytelniania. Jedynie w zakresie, w jakim przepisy nakładają na dostawców określone ciężary dowodowe, mowa jest ogólnie o uwierzytelnianiu. Paradoksalnie – wobec braku samoistnego obowiązku przeprowadzania uwierzytelniania – utrudnia to właściwą wykładnię i stosowanie tych przepisów. Można wywodzić, że ciężar udowodnienia uwierzytelniania inkorporuje w sobie ciężar udowodnienia, że dostawca w sposób prawidłowy zastosował SCA. Przyjęcie odmiennego poglądu w istocie czyniłoby ten obowiązek pustym i bezcelowym. Inna sprawa, jak szeroko ujmować ciężar udowodnienia przez dostawcę, że zastosował SCA, tj. w ścisłym rozumieniu tego pojęcia, jak zdefiniowano je w art. 2 pkt 26aa u.u.p., lub uwzględniając pozostałe – wszystkie lub niektóre (a jeżeli tak, to które) – wymogi odnoszące się do SCA określone w RTS. Sprawę dodatkowo komplikuje fakt, że polski ustawodawca – jak należy sądzić – dokonał błędnej implementacji tych przepisów do polskiego porządku prawnego (odwołując się do literalnego brzmienia art. 45 u.u.p., na dostawcach spoczywa obowiązek udowodnienia, że płatnik autoryzował transakcję, tzn. że wyraził zgodę na jej wykonanie)[19].

Od uwierzytelniania użytkownika należy odróżnić jego identyfikację. Przepisy u.u.p. nie regulują tej kwestii, natomiast warto pokrótce nakreślić obowiązki dostawców w tym zakresie wynikające z przepisów odrębnych. Główną rolę odgrywają tu przepisy u.p.p.p.[20]. Zobowiązują one dostawców – jako instytucje obowiązane (art. 2 ust. 1 pkt 1 u.p.p.p.) – do stosowania środków bezpieczeństwa finansowego, w tym do identyfikacji klientów (w przypadku dostawców chodzi o użytkowników) oraz weryfikacji ich tożsamości (art. 34 ust. 1 pkt 1 u.p.p.p.). Błędna identyfikacja klienta (użytkownika)[21] oznacza, że z usług płatniczych korzysta osoba, której tożsamości dostawca nie zna.

Trudno uznać, aby błędy na etapie identyfikowania klienta (użytkownika), a więc błędy w czynnościach, które dostawcy zobowiązani są podejmować na podstawie przepisów u.p.p.p., przekładały się na sam proces uwierzytelnienia. Innymi słowy, z faktu dokonania błędnej identyfikacji nie sposób automatycznie wywodzić, że każde uwierzytelnienie, w tym SCA dokonane w ramach umowy o świadczenie usługi płatniczej (umowy ramowej), wykonane zostało nienależycie. Mimo błędnej identyfikacji, zachowanie się każdej ze stron podlega ocenie pod kątem tego, czy wywiązuje się ona w sposób należyty z obowiązków na podstawie umowy i przepisów, z zastrzeżeniem że dostawca pozostaje w błędzie co do tożsamości klienta (użytkownika), na rzecz którego świadczy usługi.

Analogicznie, gdy dostawca zastosował SCA w sposób nienależyty bądź w ogóle go nie zastosował, gdy wymagały t (...)