Wyjaśnienia interpretacyjne i rekomendacje sektora bankowego w zakresie przepisów: 1) ustawy z dnia 10 maja 2018 r. - o zmianie ustawy o usługach płatniczych oraz niektórych innych ustaw (UZUP), 2) dyrektywy parlamentu europejskiego i rady (UE) 2015/2366 z dnia 25 listopada 2015 r. w sprawie usług płatniczych w ramach rynku wewnętrznego, zmieniającej dyrektywy 2002/65/WE, 2009/110/WE, 2013/36/UE i rozporządzenie (UE) nr 1093/2010 oraz uchylającej dyrektywę 2007/64/WE (PSD2) oraz 3) ustawy z dnia 19 sierpnia 2011 r. o usługach płatniczych (UUP)

W związku z wejściem w życie z dniem 13 stycznia 2016 r. dyrektywy Parlamentu Europejskiego i Rady (UE) 2015/2366 z dnia 25 listopada 2015 r. w sprawie usług płatniczych w ramach rynku wewnętrznego, zmieniającej dyrektywę 2002/65/WE, 2009/110/WE, 2013/36/UE i rozporządzenie (UE) nr 1093/2010 oraz uchylającej dyrektywę 2007/64/WE (dalej: PSD2), implementowanej do polskiego porządku prawnego ustawą z dnia 10 maja 2018 r. o zmianie ustawy o usługach płatniczych oraz niektórych innych ustaw (Dz. U. z 2018 r. poz. 1075), która weszła w życie 20 czerwca 2018 r., w ZBP została powołana grupa robocza, której zadaniem było zidentyfikowanie problemów oraz uzgodnienie jednolitej interpretacji przepisów związanych z wdrożeniem PSD2.

Niniejszy materiał został wypracowany w trakcie łącznie kilkudziesięciu godzin spotkań, konsultacji i debat w gronie łącznie ponad stu kilkudziesięciu przedstawicieli Banków-Członków Związku Banków Polskich uczestniczących w pracach Rady Prawa Bankowego oraz Zespołu interpretacyjnego ds. wdrożenia PSD2 przy wsparciu prawnym ze strony ekspertów z kancelarii Sołtysiński Kawecki & Szlęzak. Intencją członków Zespołu nie było przy tym stworzenie kompleksowego komentarza do ww. regulacji prawnej, lecz udostępnienie Bankom (w szczególności zespołom projektowym ds. wdrożenia PSD2) rekomendowanych odpowiedzi na pytania, które pojawiały się w trakcie prowadzonych przez nich prac przygotowawczych dotyczących wdrożenia PSD2. Konsekwencją takiego podejścia jest przyjęta konstrukcja "Wyjaśnień i rekomendacji", które zostały sformułowane w postaci pytań i odpowiedzi pogrupowanych w następujących obszarach tematycznych:

I. Problematyka silnego uwierzytelnienia (strong customer authentication - SCA);

II. Problematyka związana z nieautoryzowanymi transakcjami płatniczymi;

III. Problematyka związana ze zwolnieniem z obowiązku stosowania interfejsu awaryjnego (fallback option);

IV. Problematyka związana z Account Information Service (AIS);

V. Pozostałe zagadnienia związane z wdrożeniem PSD2.

Od samego początku działania Zespołu, jego celem było wypracowanie interpretacji przede wszystkim tych przepisów, które budziły wątpliwości w konfrontacji z praktyką funkcjonowania banków, oraz wprowadzenie jednolitych standardów postępowania banków w relacjach z konsumentami w obszarach objętych przepisami PSD2. W ten sposób starano się podnieść poziom jakości obsługi klientów w sektorze bankowym w zakresie objętym nową regulacją.

Wszelkie opinie wyrażone w "Wyjaśnieniach i rekomendacjach" zostały zaakceptowane przez wszystkich uczestników prac Zespołu interpretacyjnego. Kwestie, w odniesieniu do których nie udało się osiągnąć konsensusu, nie zostały ujęte w finalnej wersji dokumentu. Decyzja o kształcie wdrożenia nowych przepisów leży bowiem w wyłącznej kompetencji poszczególnych banków.

"Wyjaśnienia i rekomendacje" niewątpliwie nie stanowią zbioru wyczerpującego wszelkie potencjalne wątki debaty na temat nowej regulacji prawnej. Nie można zatem wykluczyć, iż wraz z uzyskiwaniem przez banki kolejnych doświadczeń związanych z nowymi obowiązkami, wynikającymi z PSD2, zostaną one w przyszłości rozszerzone o kolejne kwestie lub też zmodyfikowane w stosunku do niniejszej wersji. Zawarte w poniższym dokumencie interpretacje przepisów będą również na bieżąco monitorowane pod kątem ich zgodności z pojawiającą się doktryną oraz orzecznictwem.

Podsumowując, poniższe "Wyjaśnienia i rekomendacje" stanowią próbę rozstrzygnięcia najistotniejszych wątpliwości interpretacyjnych zidentyfikowanych na tle przepisów wdrażających PSD2.

I. Problematyka silnego uwierzytelnienia (strong customer authentication - SCA)

A. Elementy silnego uwierzytelnienia

1. Uznanie urządzenia zweryfikowanego metodą Device Fingerprinting (DFP) za element silnego uwierzytelnienia (SCA) z kategorii "posiadanie".

Element SCA z kategorii "posiadanie" został określony w następujących regulacjach prawnych:

a) Dyrektywie Parlamentu Europejskiego i Rady (UE) 2015/2366 z dnia 25 listopada 2015 r. (PSD2),

b) Rozporządzeniu Delegowanym Komisji (UE) 2018/389 z dnia 27 listopada 2017 r. uzupełniające dyrektywę Parlamentu Europejskiego i Rady (UE) 2015/2366 w odniesieniu do regulacyjnych standardów technicznych dotyczących silnego uwierzytelniania klienta i wspólnych i bezpiecznych otwartych standardów komunikacji (RTS),

c) Ustawie z dnia 19 sierpnia 2011 r. o usługach płatniczych (UUP).

Zawarte w ww. aktach prawnych definicje kategorii "posiadania" wskazują, że jest to coś, co posiada wyłącznie użytkownik:

- art. 4 pkt 30 Dyrektywy PSD2:

"Na potrzeby niniejszej dyrektywy stosuje się następujące definicje:

(...)

"silne uwierzytelnianie klienta" oznacza uwierzytelnianie w oparciu o zastosowanie co najmniej dwóch elementów należących do kategorii: wiedza (coś, co wie wyłącznie użytkownik), posiadanie (coś, co posiada wyłącznie użytkownik) i cechy klienta (coś, czym jest użytkownik), niezależnych w tym sensie, że naruszenie jednego z nich nie osłabia wiarygodności pozostałych, które to uwierzytelnianie jest zaprojektowane w sposób zapewniający ochronę poufności danych uwierzytelniających."

- pkt 6 Preambuły RTS:

"Aby zagwarantować stosowanie silnego uwierzytelniania klienta, konieczny jest również wymóg zapewnienia odpowiednich zabezpieczeń w przypadku elementów silnego uwierzytelniania klienta, którymi to zabezpieczeniami mogą być: w przypadku elementów należących do kategorii "wiedza" (coś, co wie wyłącznie użytkownik) - długość lub złożoność; w przypadku elementów należących do kategorii "posiadanie" (coś, co posiada wyłącznie użytkownik) - specyfikacja algorytmu, długość klucza i entropia informacyjna; oraz w przypadku urządzeń i oprogramowania do odczytu elementów należących do kategorii "cechy klienta" (coś, czym jest użytkownik) - specyfikacja algorytmu, zabezpieczenia czytnika i wzorca biometrycznego, przy czym zabezpieczenia te są szczególnie istotne w celu ograniczenia ryzyka, że elementy te zostaną odkryte przez osoby niepowołane, ujawnione takim osobom lub przez nie wykorzystane (...)."

- art. 2 ust. 26aa) UUP:

"Użyte w ustawie określenia oznaczają:

(...)

26aa) silne uwierzytelnianie użytkownika - uwierzytelnianie zapewniające ochronę poufności danych w oparciu o zastosowanie co najmniej dwóch elementów należących do kategorii:

Ponadto, European Banking Authority (EBA) wskazuje w punkcie 35 Opinii z 13 czerwca 2018 r. (Opinion of the European Banking Authority on the implementation of the RTS on SCA and CSC (EBA-Op-2018-04)), że:

" (...) For a device to be considered possession, there needs to be a reliable means to confirm possession through the generation or receipt of a dynamic validation element on the device".

Z kolei w Opinii EBA z dnia 21 czerwca 2019 r. dot. SCA w pkt 24 podkreśliła, że element posiadania nie oznacza tylko posiadania w rozumieniu fizycznym, ale może również odnosić się np. do aplikacji:

"Article 4 (30) of PSD2 defines possession as 'something only the user possesses'. Possession does not solely refer to physical possession but may refer to something that is not physical (such as an app). Recital 6 of the RTS refers to the requirement to have adequate security features in place and provides examples of possession, 'such as algorithm specifications, key length and information entropy'. Article 7 of the RTS refers to the requirement for PSPs to have mitigation measures to prevent unauthorised use and to have measures designed to prevent the replication of the elements."

W tym miejscu trzeba wyjaśnić, że jednym z rozwiązań w obszarze bezpieczeństwa jest zabezpieczenie zlecanych przez klientów banku operacji poprzez wdrożenie weryfikacji urządzenia klienta metodą "Device Fingerprinting" (DFP). Metoda ta polega na badaniu określonego zestawu cech urządzenia (PC, laptop, smartfon, tablet, itp.), które potwierdzą, że jest to urządzenie, z którego następowały poprzednie logowania klienta i były przez niego zlecane transakcje płatnicze. Na tego typu rozwiązania zwróciła uwagę EBA, która wyraźnie podkreśliła znaczenie wiązania (device-binding) m.in. aplikacji na potrzeby uznania ich za element posiadania (pkt 26 Opinii EBA z dnia 21 czerwca 2019 r.):

"The EBA is of the view that approaches relying on mobile apps, web browsers or the exchange of (public and private) keys may also be evidence of possession, provided that they include a devicebinding process that ensures a unique connection between the PSU's app, browser or key and the device. This may, for instance, be through hardware crypto-security, web-browser and mobile-device registration or keys stored in the secure element of a device. By contrast, an app or web browser that does not ensure a unique connection with a device would not be a compliant possession element."

Należy podkreślić, że wskazane przez EBA cechy mają charakter przykładowy.

DFP stanowi mechanizm pozwalający na weryfikację i identyfikację urządzenia klienta pracującego w sieci internet. Parametry przekazywane do analizy mogą obejmować m.in.:

Istnieje możliwość konfiguracji parametrów oraz ich wagi w przeprowadzanej przez systemy banków ocenie.

W świetle przytoczonych wyżej przepisów, określających element "posiadania" jako coś, co posiada wyłącznie użytkownik, urządzenie zweryfikowane wykorzystywanym przez banki mechanizmem DFP mogłoby być traktowane jako taki element silnego uwierzytelnienia klienta (SCA) po spełnieniu dodatkowych, opisanych niżej, warunków:

Spełnienie powyższych warunków pozwoli uznać urządzenie zweryfikowane metodą DFP za element SCA oparty o coś, co posiada wyłącznie użytkownik, czyli o zaufane, wykorzystywane wyłącznie przez klienta, urządzenie, którego używał on wcześniej i z którego loguje się do serwisu transakcyjnego banku lub aplikacji mobilnej. Przy spełnieniu wskazanych przesłanek możliwym jest uznanie urządzenia zweryfikowanego metodą DFP za element "posiadania", w rozumieniu przywołanych wyżej przepisów, który może stanowić jeden z dwóch faktorów stosowanych przez banki przy SCA.

Niezależnie od powyższego, warto zaznaczyć, że jeżeli nie zostaną spełnione ww. przesłanki, nie będzie możliwym przypisanie urządzenia zweryfikowanego metodą DFP do kategorii "posiadania". Nie wyklucza to jednak możliwości wykorzystywania przez bank metody DFP, jako dodatkowego sposobu zabezpieczenia transakcji, jednak nie jako jednego z elementów SCA.

Mając na uwadze powyższy opis DFP oraz wskazane w przepisach określenia elementu "posiadanie", należałoby uznać zaliczenie urządzenia zweryfikowanego metodą DFP do kategorii "posiadanie", pod warunkiem spełnienia opisanych powyżej warunków.

2. Możliwość stosowania elementów SCA z tej samej kategorii.

Jednym z celów PSD2 było stworzenie ram umożliwiających rozwój nowoczesnych technologii w obszarze płatniczym. PSD2 i UUP wprowadziły wymagania dotyczące silnego uwierzytelniania w oparciu o elementy wiedzy, posiadania oraz cechy klienta. EBA, na podstawie delegacji zawartej w dyrektywie, przystąpiła do opracowania RTS (regulacyjne standardy techniczne) w tym zakresie. W toku prac w odniesieniu do metod SCA, EBA zdecydowała się na określenie ich ogólnych ram i kryteriów bez wskazywania konkretnych rozwiązań. W dokumentach konsultacji publicznych instytucja ta wskazywała, że zbyt szczegółowe wskazanie konkretnych rozwiązań sprzeciwiałoby się rozwojowym celom PSD2.

W publikacjach EBA z 2018 r. 1 można zauważyć pewien wyłom w tej logice, kreujący sprzeczności wobec przepisów UUP, a także art. 6-9 PSD2. Powyższe rozbieżności mogą doprowadzić w bankach do wadliwej implementacji przepisów poprzez konkretne wdrożenia rozwiązań.

Zarówno dyrektywa PSD2 jak i UUP nie narzucają wprost ograniczeń co do doboru elementów silnego uwierzytelnienia spośród trzech zdefiniowanych kategorii. Utrzymane są kryteria techniczne oraz pozostawia się dobór elementów podmiotowi świadczącemu usługę płatniczą. Podmiot ten ma tak dobrać elementy silnego uwierzytelniania, aby zostały spełnione założone kryteria bezpieczeństwa.

Jeżeli chodzi o warstwę językową UUP i PSD2, to prawodawca nie wykluczył wprost możliwości oparcia procedury SCA o elementy należące do tej samej kategorii (np. posiadanie + posiadanie).

Należy wskazać, że takie elastyczne podejście nie oznacza niższego bezpieczeństwa. Przykładowo, dedykowany token sprzętowy i urządzenie końcowe, na które przesyłany jest kod uwierzytelniający (telefon/SIM etc.) to elementy z kategorii "posiadanie". Konstrukcja silnego uwierzytelniania opartego na tych elementach jest bezpieczna, ponieważ spełnione są wymagania niezależności, rozdzielności i poufności. Innym przykładem bezpiecznego wykorzystania elementów z jednej kategorii jest zastosowanie w parze elementów biometrii twarzy i głosu, a więc faktorów pochodzących z kategorii biometrycznych ("cecha").

Uwzględniając jednocześnie przytoczone wcześniej rozbieżności w interpretacji przepisów, koniecznym wydaje się ujednolicenie podejścia instytucji w zakresie stosowania silnych rozwiązań uwierzytelniających bazujących na dwóch elementach z tej samej kategorii. Podkreślić należy przy tym raz jeszcze, że stosowanie dwóch elementów z tej samej kategorii nie budzi wątpliwości co do ich skuteczności i wysokiego poziomu bezpieczeństwa. Tym samym, w świetle literalnego brzmienia przepisów PSD2 i UUP należałoby dopuścić korzystanie przez dostawców na potrzeby SCA z elementów należących do tej samej kategorii. Wprowadzenie wymogu stosowania w tym celu elementów różnych kategorii należałoby uznać jako nadmiarowe i zarazem nieuzasadnione z punktu widzenia celu regulacji.

Należy jednak podkreślić, że zarówno EBA w opinii z 13 czerwca 2018 r., jak i KNF w piśmie kierowanym do ZBP z 21 listopada 2018 r. podały pod wątpliwość możliwość oparcia procedury SCA na elementach należących do tej samej kategorii. Organy nadzoru powołują się w tym zakresie na konieczność odtworzenia sensu normatywnego PSD2 oraz RTS.

W najnowszej publikacji EBA nawiązała do poprzedniej opinii z czerwca 2018 r. ponownie wskazując na zgodność z SCA w przypadku stosowania elementów z dwóch różnych kategorii (pkt 44 opinii EBA z 21 czerwca 2019 r., pkt 44).

W świetle powyższych uwag i niejasności interpretacyjnych na gruncie językowej wykładni przepisów PSD2, RTS oraz UUP nie należy odrzucać dopuszczenia obu przedstawionych powyżej wariantów interpretacyjnych. W przypadku procedury SCA opierającej się na elementach należących do jednej kategorii, dostawca usług płatniczych powinien być jednak w stanie wykazać (lub uprawdopodobnić), że stosowana przez niego procedura uwierzytelniania zapewnia porównywalny poziom bezpieczeństwa do procedury opartej na dwóch elementach należących do różnych kategorii.

3. Dane karty płatniczej w kanale internet traktowane jako element silnego uwierzytelnienia użytkownika.

W ocenie EBA (Opinia EBA z 13 czerwca 2018 r., pkt 35), dane karty płatniczej (w tym numer karty, data ważności oraz CVV) nie mogą być uznane za elementy z kategorii "wiedza". EBA podkreśliła dalej, że aby określone urządzenie uznać za element z kategorii posiadanie, konieczne jest, aby umożliwiało ono potwierdzenie tego posiadania (aktywnie) poprzez generowanie lub otrzymanie elementów dynamicznie walidujących to urządzenie.

Stanowisko to zostało potwierdzone w późniejszej opinii EBA z dnia 21 czerwca 2019 r. (pkt 28 i 33). Rozważając jednak funkcjonowanie kart z dynamicznym CVV EBA doszła do wniosku, że taka karta z dynamicznym CVV (Card with possession evidenced by a dynamic card security code) może potwierdzać posiadanie (pkt 28 opinii).

W efekcie należałoby przyjąć, że w ocenie EBA, dane karty płatniczej nie stanowią ani elementu z kategorii "wiedza", ani elementu z kategorii "posiadanie".

Powołując się na stanowisko EBA z 13 czerwca 2018 r., KNF wskazała, że w jej ocenie karta płatnicza - niezależnie od kanału przeprowadzenia transakcji - zawsze powinna być traktowana jako element z kategorii posiadanie.

Trzeba zatem przyjąć, że wytyczne EBA i KNF stoją ze sobą w pewnej rozbieżności.

Ze względów celowościowych i funkcjonalnych, a także biorąc pod uwagę dotychczasowe rozwiązania rynkowe, które stanowiły podstawę do rozwoju koncepcji SCA (np. uwierzytelnianie 3D-secure), należy przyjąć, że dane, których nośnikiem jest karta płatnicza, przyjmują zmienną kwalifikację kategorii elementu silnego uwierzytelniania, w zależności od miejsca i sposobu inicjowania transakcji. W przypadku transakcji inicjowanej w ATM lub POS (card present), karta i jej dane mają charakter elementu "posiadania". Elementem tym jest w praktyce chip EMV (por. stanowisko EBA na etapie prac konsultacyjnych nad RTS, gdzie wskazano, że: "The EBA remarks that a payment order is generally based upon EMV DDA which authentication includes dynamic codes in a way that would appear to comply with the principle of SCA"). Nie da się wykonać takiej transakcji bez posiadania karty i fizycznego odczytu jej danych w wyspecjalizowanym czytniku. Użycie karty w czytniku może nie dać szansy na wpisanie wszystkich wymaganych danych potrzebnych do skutecznego uwierzytelnienia, gdyż wymusza to użycie informacji zapamiętanych przez klienta (a nie do wszystkich ma dostęp, jedynie do tych widocznych na karcie). Tak więc karta i jej dane w ww. przypadkach nie mogą być kwalifikowane jako element z kategorii wiedza.

W przypadku transakcji inicjowanych w Internecie (transakcje CNP; card not present), dane karty płatniczej nie mogą być uznane za element z kategorii wiedza (zgodnie z stanowiskami EBA). W pewnych okolicznościach (karta z dynamicznym CVV), w przypadku transakcji zdalnych karta może być jednak uznana za element z kategorii "posiadanie". Dynamiczny CVV może w takim przypadku stanowić element umożliwiający potwierdzenie posiadania (karty).

4. Czy za element z kategorii "cecha" można uznać dane biometryczne weryfikowane przez dostawcę usług informatycznych (np. touch ID, face ID)?

Ze względu na brak podstaw do jednoznacznego przesądzenia jednego właściwego podejścia do powyższego zagadnienia należałoby alternatywnie dopuścić dwa warianty interpretacyjne.

Z jednej strony można argumentować w ten sposób, że skoro proces uwierzytelnienia jest procesem przeprowadzanym przez bank (por. art. 32i ust. 1 UUP oraz art. 4 ust. 1 RTS), to bank powinien dysponować wzorcem cechy biometrycznej klienta, który jest w stanie poddać stosownej weryfikacji (podobnie jak w przypadku weryfikacji hasła nadanego do systemów banku). Weryfikacja przeprowadzona przez dostawcę rozwiązania technologicznego (czytnika) w urządzeniu (np. Apple) nie będzie de facto weryfikacją przeprowadzoną przez bank. W takim przypadku bank nie ma bowiem pewności, czyje dane biometryczne są weryfikowane (podobne stanowiska interpretacyjne występują w praktyce; por.m.in. interpretacja UL Transaction Security w odpowiedzi na pytanie nr 4 - link). Przy założeniu tego wariantu interpretacyjnego należałoby uznać za dopuszczalne stosowanie przez bank czynności w zakresie weryfikacji wzorca biometrycznego. Kwestia ta poruszona została także w odpowiedzi na pytanie nr 2018_4047 z dnia 9 sierpnia 2019 r., 2 w którym EBA wyraźnie stwierdza, że dla potrzeb SCA dostawcy mogą korzystać z technologii zewnętrznych dostawców, takich jak czytniki linii papilarnych, na zasadzie outsourcingu oraz zapewniając odpowiedni poziom bezpieczeństwa procesów. Za powyższym wariantem interpretacyjnym przemawiają przede wszystkim wyniki wykładni celowościowej (bezpieczeństwo świadczonych usług płatniczych).

Z drugiej strony, w praktyce prezentowane są także podejścia bardziej liberalne. Wynikają one przede wszystkim z funkcjonalnej wykładni obowiązków z zakresu stosowania silnego uwierzytelniania klienta. Przykładowo brytyjski organ nadzoru (FCA) wskazał, że dane biometryczne użytkownika usług płatniczych mogą być uznawane za element z kategorii "cecha" także w przypadku, gdy uwierzytelnienie przeprowadzone jest na poziomie urządzenia końcowego (ang. even when hosted at device level, eg using fingerprint authentication on a moblie phone). W takim jednak przypadku dostawca powinien podjąć stosowne środki ograniczające ryzyko, których celem jest należyte powiązanie klienta z konkretnym urządzeniem 3 . Należy przyjąć, że taki wariant interpretacyjny również jest dopuszczalny w świetle regulacji PSD2/RTS/UUP.

5. Sekwencja elementów silnego uwierzytelniania (art. 4 RTS) - czy kod uwierzytelniający musi być wynikiem użycia dwóch z trzech elementów?

Należy przyjąć, że kod uwierzytelniający niekoniecznie musi być czasowym następstwem użycia przez użytkownika dwóch z trzech elementów uwierzytelnienia. Wystarczy, żeby kod uwierzytelniający był nieodłącznym elementem procesu uwierzytelnienia jako pewnej całości. Za taką interpretacją przemawiają m.in. następujące argumenty:

6. Czy w procesie zlecania w bankowości internetowej operacji, dla której wymagane jest SCA (np. przelew do nowego odbiorcy), użytkownik powinien każdorazowo użyć standardowego hasła (tego samego co do logowania) oraz drugiego czynnika (hasło sms/token/autoryzacja mobilna itp.), czy też wystarczy wprowadzenie tylko drugiego czynnika (hasło wprowadzone w ramach logowania klienta do BI możemy "zaliczyć" jako element SCA przy zlecaniu operacji)?

Z art. 4 ust. 1 RTS wynika, że jeżeli dostawca stosuje SCA, to opiera się ono na zastosowaniu co najmniej dwóch elementów należących do kategorii "wiedza", "posiadanie" i "cechy klienta" oraz prowadzi do wygenerowania kodu uwierzytelniającego. W związku z tym, zarówno przy uzyskiwaniu dostępu do rachunku w trybie on-line (logowanie do kanału bankowości internetowej), jak i przy inicjowaniu elektronicznej transakcji płatniczej (dokonywanie płatności z poziomu bankowości internetowej) należy zastosować tzw. dwa faktory uwierzytelniania.

Zgodnie z art. 32i ust. 1 UUP:

Dostawca stosuje silne uwierzytelnianie użytkownika, w przypadku gdy płatnik:

Z powyższego wynika, że dostawca zobowiązany jest do zastosowania SCA (czyli dwóch elementów z wymienionych w art. 4 RTS kategorii) w sytuacji, w której płatnik uzyskuje dostęp on-line do rachunku oraz w sytuacji, gdy inicjuje transakcję np. w kanale bankowości internetowej. Potwierdza to pkt 36 opinii EBA z dnia 13 czerwca 2018 r. 4 dotyczącej implementacji RTS dot. SCA:

"SCA has to be applied to access to payment account information and to every payment initiation, including within a session in which SCA was performed to access the account data, unless an exemption under the RTS applies."

Przytoczony pkt 36 opinii EBA wymaga podczas inicjowania elektronicznej transakcji płatniczej, za pośrednictwem kanału bankowości internetowej, każdorazowego podania przez płatnika dwóch elementów, np. hasła znanego tylko płatnikowi (element wiedzy) oraz przepisania kodu SMS (element posiadania).

Jak z tego wynika, wymóg silnego uwierzytelnienia należy stosować do każdego z ww. przypadków z art. 32i UUP z osobna, w związku z tym, dwuelementowe SCA powinno być stosowane najpierw przy uzyskiwaniu przez użytkownika dostępu do rachunku on-line, a następnie w celu zainicjowania w danej sesji elektronicznej transakcji płatniczej (tutaj również jest wymagane dwuelementowe SCA). Uwierzytelnienie danej sesji w trybie on-line częściowo uwierzytelnia jednak transakcję płatniczą, która ma być wykonana w tej sesji poprzez wykorzystanie elementu SCA użytego podczas uzyskiwania dostępu do rachunku w trybie on-line - operacja nie może bowiem być przeprowadzona bez wcześniejszego uwierzytelnienia. W związku z tym, możliwe do zastosowania jest rozwiązanie, w którym jeden element SCA może zostać wykorzystany na potrzeby użycia kolejnego SCA np. podczas inicjowania elektronicznej transakcji płatniczej oraz pozostałych operacji wskazanych w art. 32i UUP poprzez kanał bankowości internetowej, jako jeden z elementów SCA zastosowany będzie element, który został wykorzystany przez płatnika podczas uzyskiwania w trybie SCA dostępu do rachunku w trybie on-line (np. hasło znane tylko klientowi), pod warunkiem że takie działanie doprowadzi do wygenerowania kodu uwierzytelniającego, na zasadach określonych w art. 4 RTS, oraz spełni warunki tzw. dynamicznego łączenia (art. 5 RTS).

Możliwość ponownego użycia elementu SCA (reused) w ramach tej samej sesji dla potrzeb przeprowadzenia SCA w celu zainicjowania zlecenia płatniczego została ponadto potwierdzona przez EBA:

a) w Opinii dot. SCA z dnia 21 czerwca 2019 r. (pkt 40) - "The EBA also notes (as published in Q&A 4141) that an element used for the purpose of SCA may be reused within the same session for the purpose of applying SCA at the time that a payment is initiated, provided that the other element required for SCA is carried out at the time of the payment initiation and that the dynamic linking element is present and linked to that latter element."

b) W Q&A nr 2018_4141 - "The Commission Delegated Regulation does not prescribe a time limit for the provision of the two authentication elements necessary for SCA while within a session. When initiating a payment, SCA may therefore be performed when one of the elements used at the time the customer accessed its payment account online (including via a mobile app) is reused in compliance with Article 4, and the other element of SCA is carried out at the time the payment is initiated, provided that the dynamic linking element required under Article 97 (2) PSD2 and detailed under Article 5 of the Delegated Regulation is present and linked to that latter element."

W świetle powyższego należy również zauważyć, że RTS nie wprowadza ograniczeń czasowych dotyczących odstępu pomiędzy wprowadzeniem pierwszego i drugiego elementu SCA oraz nie uniemożliwia wykorzystania jednego z elementów SCA na potrzeby użycia kolejnego SCA. W związku z tym, wydaje się możliwym rozwiązanie, w którym podczas inicjowania elektronicznej transakcji płatniczej, jako jeden z elementów SCA zastosowany będzie element, który w ramach procedury SCA został wykorzystany przez płatnika podczas uzyskiwania dostępu do rachunku w trybie on-line (np. hasło znane tylko klientowi), pod warunkiem że (1) dla potrzeby zainicjowania transakcji dostawca dołoży kolejny element uwierzytelniania (np. posiadanie - telefon/SIM), (2) uwierzytelnienie doprowadzi do wygenerowania kodu uwierzytelniającego, na zasadach określonych w art. 4 RTS, oraz (3) spełnione zostaną warunki tzw. dynamicznego łączenia (art. 5 RTS).

7. Silne uwierzytelniania w kontekście wymogów dynamicznego łączenia w przypadku paczek zleceń płatniczych.

Zgodnie z przepisami dot. dynamicznego łączenia (dynamic linking):

" (3)Zważywszy na fakt, że elektroniczne zdalne transakcje płatnicze obarczone są większym ryzykiem oszustwa, należy wprowadzić dodatkowe wymogi dotyczące silnego uwierzytelniania klienta w przypadku tych transakcji, zapewniające, aby elementy objęte uwierzytelnieniem dynamicznie łączyły transakcję z kwotą i odbiorcą określonymi przez płatnika w momencie zainicjowania transakcji.

(4)Dynamiczne łączenie można uzyskać poprzez generowanie kodów uwierzytelniających, które podlega zestawowi restrykcyjnych wymogów bezpieczeństwa. Aby zapewnić neutralność pod względem technologicznym, nie należy wymagać stosowania konkretnej technologii do celów wdrożenia kodów uwierzytelniających. Kody uwierzytelniające powinny zatem opierać się na takich rozwiązaniach, jak: generowanie i walidacja jednorazowych haseł, podpisy cyfrowe lub innego rodzaju metody stwierdzania ważności oparte na mechanizmach kryptograficznych z zastosowaniem kluczy lub materiału kryptograficznego przechowywanego w elementach uwierzytelnienia, z zastrzeżeniem spełnienia wymogów bezpieczeństwa."

Dodatkowo, przepis art. 5 ust. 3 lit. b RTS wprowadza szczególne wymogi związane z informowaniem o parametrach transakcji realizowanych w paczkach (batch payments):

"w stosunku do transakcji płatniczych, w odniesieniu do których płatnik udzielił zgody na przeprowadzenie serii zdalnych elektronicznych transakcji płatniczych na rzecz jednego odbiorcy lub wielu odbiorców, kod uwierzytelniający jest przypisany do całkowitej kwoty serii transakcji płatniczych oraz do określonych odbiorców."

W świetle obowiązków wynikających z RTS pojawia się wątpliwość, jakie mechanizmy, w przypadku paczek zleceń płatniczych (produkt dedykowany głównie dla klientów biznesowych) zawierających zlecenia do różnych odbiorców, spełniają uwarunkowania dynamicznego połączenia.

Należy podkreślić, że RTS nie precyzują w jaki sposób należy powiadomić użytkownika o parametrach transakcji realizowanych w paczce. Przepis art. 5 ust. 3 lit. b RTS nie wprowadza żadnych modyfikacji w stosunku do ogólnego obowiązku informacyjnego określonego w art. 5 ust. 1 lit. a RTS, tj. obowiązku powiadomienia o kwocie transakcji płatniczej oraz o odbiorcy. RTS nie przesądzają zatem o tym, że informacja o całkowitej kwocie transakcji w paczce oraz o określonych odbiorcach powinna być zaprezentowana użytkownikowi w określony sposób (np. w treści wiadomości SMS etc.).

Należy przyjąć, że na gruncie art. 5 ust. 3 lit. b RTS obowiązkiem dostawcy jest zapewnienie, że użytkownik wyrażający zgodę na zainicjowanie transakcji, będzie miał możliwość użycia kodu uwierzytelniającego w związku z całkowitą kwotą transakcji i określonymi odbiorcami. Jedynie w sposób pośredni obowiązek ten wymusza, aby użytkownik był powiadomiony przez dostawcę o tych parametrach. W konsekwencji należy uznać, że dopuszczalne jest każde rozwiązanie, którego skutkiem będzie przedstawienie użytkownikowi wymaganych parametrów transakcji (łącznej kwoty oraz określonych odbiorców) i które w aspekcie funkcjonalnym pozwoli klientowi powiązać kod uwierzytelniający z tymi parametrami.

Przykładowym rozwiązaniem technologicznym, które mogłoby czynić zadość ww. obowiązkowi informacyjnemu, jest wykorzystanie tzw. kodu "sumy kontrolnej" wygenerowanej na podstawie listy wszystkich odbiorców, do których realizowane są transakcje w paczce. Dopuszczalne są także inne rozwiązania.

B. Kanały silnego uwierzytelnienia

1. Stosowanie SCA dla transakcji wpłaty gotówkowej przy użyciu wpłatomatu.

Zgodnie z art. 32i ust. 1 pkt 2 UUP, dostawca jest zobowiązany stosować silne uwierzytelnienie klienta (SCA), kiedy inicjuje elektroniczną transakcję płatniczą. UUP definiuje transakcję płatniczą jako zainicjowaną przez płatnika lub odbiorcę: wpłatę, transfer lub wypłatę środków pieniężnych.

UUP nie definiuje elektronicznej transakcji płatniczej. W PSD2 również nie ma definicji elektronicznej transakcji płatniczej, pojawia się za to definicja sieci łączności elektronicznej:

"Sieć łączności elektronicznej" oznacza sieć zdefiniowaną w art. 2 lit. a dyrektywy 2002/21/WE Parlamentu Europejskiego i Rady."

"Sieć łączności elektronicznej" oznacza systemy transmisyjne, oraz stosownie do okoliczności, urządzenia przełączające i routingowe oraz inne zasoby, które umożliwiają przekazywanie sygnałów przewodowo, za pomocą radia, środków optycznych lub innych elektromagnetycznych środków, w tym sieci satelitarnych, stacjonarnych (komutowanych i pakietowych, w tym Internetu) i naziemnych sieci przenośnych, elektrycznych systemów kablowych, w takim zakresie, w jakim są one wykorzystywane do przekazywania sygnałów, w sieciach nadawania radiowego i telewizyjnego oraz sieciach telewizji kablowej, niezależnie od rodzaju przekazywanej informacji."

Transakcja płatnicza wykonana za pośrednictwem bankomatu lub wpłatomatu będzie elektroniczną transakcją płatniczą, ponieważ z reguły wymaga użycia instrumentu płatniczego opartego na chipie (lub innego elektronicznego instrumentu płatniczego). Tym samym, transakcja płatnicza polegająca na wpłacie środków pieniężnych we wpłatomacie powinna, zgodnie z art. 32i ust. 1 pkt 2 UUP, zostać objęta SCA.

Jednocześnie, RTS wprowadza w art. 10-18 katalog wyłączeń od obowiązku stosowania przez dostawców SCA. Wśród tego katalogu można znaleźć między innymi, transakcje nisko kwotowe, transakcje zbliżeniowe, transakcje chrakteryzujące się niskim poziomem ryzyka. W tym katalogu nie ujęto wprost transakcji wpłat środków we wpłatomacie.

Dla uniknięcia wątpliwości należy wskazać, że tzw. wpłaty zamknięte do wyrzutni (w tym wrzutni nocnych), jako element obrotu w pełni gotówkowego, korzystają z wyłączenia spod zakresu przedmiotowego UUP. Tym samym czynności "wpłaty" gotówki dokonywane za pomocą wrzutni nie są objęte wymogami z zakresu SCA.

2. Kwalifikacja kanału call center w świetle wymogów SCA

Zmiany potrzeb klientów, istniejące trendy rynkowe oraz postępująca zmiana technologii dały możliwość powszechnego zaoferowania klientom zlecania transakcji za pośrednictwem kanałów zdalnych (w tym elektronicznych). Funkcjonalność transakcji zlecanych przez tzw. Centra Telefoniczne (call center) rozwijała się w Polsce dość długo, uwzględniając przy tym tworzące się równolegle przepisy prawa regulujące ten obszar. Z czasem ukształtował się w miarę jednolity biznesowy schemat identyfikacji i uwierzytelniania transakcji zlecanych i dokonywanych tym kanałem.

Jednocześnie, rozbudowano funkcjonalność przedmiotowego kanału, rozdzielając transakcje na realizowane:

Tak ukształtowana praktyka rynkowa powinna zostać dostosowana do nowych regulacji prawnych stanowiących wdrożenie PSD2, w szczególności powinna odpowiadać wymogom stosowania SCA w przewidzianych prawem przypadkach.

Na gruncie UUP, SCA stosowane jest do zainicjowania elektronicznej transakcji płatniczej (art. 32i ust. 1 pkt 2 UUP). Ponadto, zgodnie z art. 32i ust. 2 UUP:

"Jeżeli płatnik inicjuje elektroniczną transakcję płatniczą z wykorzystaniem połączenia z siecią Internet lub za pośrednictwem środków, które mogą być wykorzystywane do porozumiewania się na odległość, dostawca stosuje silne uwierzytelnianie użytkownika obejmujące elementy, które dynamicznie łączą transakcję płatniczą z określoną kwotą transakcji oraz określonym odbiorcą."

Z kolei art. 97 ust. 2 PSD2 stanowi:

"W odniesieniu do inicjowania elektronicznych transakcji płatniczych, o którym mowa w ust. 1 lit. b, państwa członkowskie zapewniają, by - w przypadku elektronicznych zdalnych transakcji płatniczych - dostawcy usług płatniczych stosowali silne uwierzytelnianie klienta obejmujące elementy, które dynamicznie łączą transakcję z określoną kwotą i określonym odbiorcą."

Natomiast, zgodnie z motywem 95 PSD2:

"Bezpieczeństwo płatności elektronicznych ma podstawowe znaczenie dla zapewnienia ochrony użytkowników i stworzenia solidnego otoczenia dla handlu elektronicznego. Wszystkie usługi płatnicze oferowane drogą elektroniczną powinny być wykonywane w sposób bezpieczny, z użyciem technologii będących w stanie zagwarantować bezpieczne uwierzytelnianie użytkownika i w jak największym stopniu ograniczyć ryzyko oszustw. Silnemu rozwojowi płatności realizowanych przez internet i za pośrednictwem urządzeń przenośnych powinno towarzyszyć ogólne wzmocnienie środków bezpieczeństwa. Usługi płatnicze oferowane za pośrednictwem internetu lub innych kanałów na odległość, których funkcjonowanie nie zależy od fizycznej lokalizacji urządzenia wykorzystywanego do zainicjowania transakcji płatniczej lub wykorzystywanego instrumentu płatniczego, powinny zatem obejmować uwierzytelnianie transakcji przy użyciu kodów dynamicznych, tak by użytkownik zawsze był świadomy kwoty i odbiorcy autoryzowanej transakcji."

W związku z powyższym, aby przesądzić, czy do transakcji inicjowanych przez call center należy stosować SCA, należy ustalić, czy takie transakcje mieszczą się w kategorii "elektronicznych transakcji płatniczych".

Przepisy krajowe nie definiują pojęcia elektronicznej transakcji płatniczej. Można w nich odnaleźć definicję świadczenia usług drogą elektroniczną. Zgodnie z ustawą z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną, należy przez to rozumieć:

"wykonanie usługi świadczonej bez jednoczesnej obecności stron (na odległość), poprzez przekaz danych na indywidualne żądanie usługobiorcy, przesyłanej i otrzymywanej za pomocą urządzeń do elektronicznego przetwarzania, włącznie z kompresją cyfrową, i przechowywania danych, która jest w całości nadawana, odbierana lub transmitowana za pomocą sieci telekomunikacyjnej w rozumieniu ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne."

Jednocześnie, zgodnie z ww. ustawą, środki komunikacji elektronicznej to:

"rozwiązania techniczne, w tym urządzenia teleinformatyczne i współpracujące z nimi narzędzia programowe, umożliwiające indywidualne porozumiewanie się na odległość przy wykorzystaniu transmisji danych między systemami teleinformatycznymi, a w szczególności pocztę elektroniczną."

Z kolei definicję środków porozumiewania się na odległość zawiera UUP, która wskazuje, że są to środki, które mogą być wykorzystane do zawarcia umowy o usługę płatniczą, które nie wymagają jednoczesnej obecności dostawcy i użytkownika.

Dodatkowo, według art. 1 pkt 3 dyrektywy Komisji 2002/77/WE z dnia 16 września 2002 r. w sprawie konkurencji na rynkach sieci i usług łączności elektronicznej:

"Usługi łączności elektronicznej oznaczają usługi normalnie świadczone za wynagrodzeniem, które obejmują w całości lub głównie przesyłanie sygnałów za pomocą sieci łączności elektronicznej, w tym usługi telekomunikacyjne i usługi transmisji w sieciach używanych do nadawania, ale z wyłączeniem usług polegających na zapewnianiu lub wykonywaniu kontroli redaktorskiej nad treścią przekazywaną za pomocą sieci i usług łączności elektronicznej; nie obejmuje to usług społeczeństwa informacyjnego, określonych w art. 1 dyrektywy 98/34/WE, które nie polegają w całości lub głównie na przesyłaniu sygnałów w sieciach łączności elektronicznej".

Ponadto, PSD2 określa następujące definicje:

W powyższym kontekście trzeba zwrócić uwagę na Discussion paper wydany przez EBA z dnia 8 grudnia 2015 r., zgodnie z którym:

a) "with regard to (b) above, the initiation of electronic payment transactions would cover all payment transactions within the scope of PSD2 (such as card payments, credit transfers, e-money transactions, direct debits), except where the payment instruction is not electronic (such as physical mail-order, paper based credit transfer or paper based direct debits or telephone orders);

b) Considering the scope of Article 97 and the fact that PSD2 excludes paper-based transactions, mail and telephone order, the EBA has so far not identified circumstances that would justify considering exemptions based on the payment channel used for the execution of the transaction. Moreover, the EBA observes that a number of providers can, when receiving an authorisation request, not necessarily identify the payment channel (e.g. mobile versus internet payments)."

Przytoczone stanowisko EBA zdaje się wskazywać, że pomimo ww. przepisów PSD2 oraz UUP, transakcje płatnicze inicjowane kanałem call center nie są objęte obowiązkiem stosowania SCA. Stanowisko w tym zakresie EBA zajęła również w ramach opublikowanych Q&A, nr 2018_4058:

"In accordance with recital 95 of PSD2, payment transactions initiated or executed outside electronic platforms or electronic devices, such as mail orders or telephone orders do not seem to necessitate the same level of guarantees regarding safe authentication as electronic payments. Recital 95 of PSD2 further specifies that "payment services offered via internet or via other at-distance channels, the functioning of which does not depend on where the device used to initiate the payment transaction or the payment instrument used are physically located, should include the authentication of transactions through dynamic codes, in order to make the user aware, at all times, of the amount and the payee of the transaction that the user is authorising."

Payment transactions initiated through a telephone order with the use of an automated solution such as Interactive Voice Response seem to be similar to a regular telephone order. However, where such technology is used to initiate an electronic payment transaction through internet or any other at-distance channels, the provisions on strong customer authentication apply."

Stanowisko to wspiera także pogląd zaprezentowany przez KNF w piśmie z 21 listopada 2018 r. (DRB-W3.7111.2.2018), gdzie w pkt 5. wskazano, że na gruncie dyrektywy PSD2, transakcje inicjowane z wykorzystaniem zlecenia telefonicznego są wyłączone z obowiązku art. 97 ust. 2 PSD2. Co za tym idzie, w ocenie KNF standardowa rozmowa call center nie jest objęta wymogami SCA.

C. Pozostałe zagadnienia SCA

1. Czy użytkownik zalogowany bez SCA (np. ze względu na to, iż w ciągu ostatnich 90 dni logował się z pełnym SCA) może zlecać jakiekolwiek przelewy w trakcie tej sesji - np. do zaufanego odbiorcy bez SCA, a inne z SCA? Czy też w wypadku zalogowania bez SCA, wszystkie funkcje płatnicze powinny być całkowicie zablokowane podczas tej sesji?

W przepisach art. 10-18 RTS zostały określone wyłączenia z obowiązku stosowania silnego uwierzytelnienia klienta. W art. 10 RTS wprowadzono wyłączenia odnoszące się do dostępu do określonych informacji. Według art. 10 ust. 1 RTS, dostawcy usług płatniczych mogą nie stosować silnego uwierzytelniania klienta, z zastrzeżeniem spełnienia wymogów określonych w art. 2 RTS i w art. 10 ust. 2 RTS, w przypadku gdy dostęp użytkownika usług płatniczych ogranicza się do dostępu do jednej z wymienionych niżej pozycji w trybie online lub do obu tych pozycji bez ujawniania szczególnie chronionych danych dotyczących płatności:

Zgodnie z art. 10 ust. 2 RTS, do ww. celów dostawcy usług płatniczych nie podlegają wyłączeniu z obowiązku stosowania silnego uwierzytelniania klienta, jeżeli spełniony jest którykolwiek z następujących warunków:

Natomiast, art. 11-18 RTS określają wyłączenia w odniesieniu do poszczególnych rodzajów transakcji płatniczych, w szczególności transakcji zbliżeniowych w punktach sprzedaży, transakcji w terminalu samoobsługowym służącym uiszczaniu opłat za przejazd i opłat za postój, transakcji do zaufanych odbiorców, transakcji cyklicznych, niskokwotowych transakcji zdalnych czy transakcji zdalnych o niskim poziomie ryzyka.

Według opinii EBA z 13 czerwca 2018 r. (pkt 41) wyłączenia dotyczące poszczególnych rodzajów transakcji płatniczych są oddzielne i niezależne od siebie, a dla określonej transakcji należy stosować tylko jedno wyłączenie, nawet jeżeli ta transakcja kwalifikowałaby się do objęcia więcej niż jednym wyłączeniem:

"The exemptions in relation to payment transactions are separate and independent from one another, and only one exemption needs to be applied for any given transaction, even if the given transaction could qualify for more than one exemption".

Jeśli chodzi o możliwość połączenia wyłączenia spod SCA dotyczącego dostępu do informacji o rachunku płatniczym (art. 10 RTS) z wyłączeniem dotyczącym określonego rodzaju transakcji płatniczej (np. do zaufanego odbiorcy - art. 13 RTS) trzeba zauważyć, że obowiązek stosowania SCA został wprowadzony (art. 32i ust. 1 UUP), gdy płatnik:

Wskazuje to na wymóg stosowania silnego uwierzytelnienia oddzielnie w stosunku do sytuacji, gdy płatnik uzyskuje dostęp do rachunku on-line, oraz w stosunku do sytuacji, gdy płatnik inicjuje transakcję płatniczą (SCA należy stosować na obu tych etapach, z tym że jeden element SCA może zostać wykorzystany na potrzeby użycia kolejnego SCA).

Powyższe nie oznacza jednak automatycznie, że można skorzystać z wyłączenia SCA najpierw podczas uzyskiwania dostępu do rachunku on-line, a następnie z wyłączenia SCA dotyczącego zainicjowania w trybie on-line danego rodzaju transakcji płatniczej. Trzeba bowiem zwrócić uwagę, że dostęp do rachunku w trybie on-line, dla którego wymagane jest SCA, stanowi innego typu dostęp niż dostęp on-line do określonych informacji o rachunku bez ujawniania szczególnie chronionych danych dotyczących płatności (art. 10 RTS). Ten drugi jest węższy niż dostęp do rachunku on-line, który obejmuje nie tylko saldo rachunku i transakcje z ostatnich 90 dni, ale wszelkie informacje o rachunku, w tym szczególnie chronione dane dotyczące płatności. Oznacza to, że wyłączenie SCA wprowadzone w art. 10 RTS nie odnosi się do przypadku, gdy płatnik uzyskuje generalny dostęp do swojego rachunku w trybie on-line, a jedynie do przypadku, gdy dostęp ten jest ograniczony do ściśle określonych informacji ("szybki podgląd rachunku"). W konsekwencji, płatnik, który zaloguje się bez SCA do systemu bankowości elektronicznej w ramach szybkiego podglądu rachunku, nie powinien mieć możliwości zainicjowania elektronicznej transakcji płatniczej do zaufanego odbiorcy. Wymagałoby to bowiem uzyskania dostępu do informacji o liście zaufanych odbiorców, co wykraczałoby poza granice art. 10 RTS. Jeżeli natomiast płatnik, w ramach dostępu on-line do rachunku w zakresie informacji wymienionych w art. 10 RTS, chciałby zainicjować transakcję płatniczą do odbiorcy, którego numer rachunku wpisze samodzielnie w systemie bankowości elektronicznej, wówczas mógłby to uczynić zarówno używając silnego uwierzytelnienia, jak i bez SCA, jeśli w tym wypadku znajdowałoby zastosowanie któreś z wyłączeń wymienionych w art. 11-18 RTS.

2. Czy kod uwierzytelniający (art. 4 RTS) może być kodem "w tle" tj. nie być widzialny z perspektywy użytkownika usług płatniczych?

Należy przyjąć, że kod uwierzytelniający może funkcjonować niejako "w tle" danego połączenia, tj. może być niewidoczny dla klienta uzyskującego dostęp do rachunku online, inicjującego elektroniczną transakcję płatniczą lub przeprowadzającego czynność za pomocą kanału zdalnego, który może rodzić ryzyko oszustwa lub innych nadużyć.

Za taką interpretacją przemawiają m.in. następujące argumenty:

Techniczną implementację kodu uwierzytelniającego należy rozumieć przede wszystkim w ujęciu, m.in.:

II. Problematyka związana z nieautoryzowanymi transakcjami płatniczymi

1. Co oznacza nieautoryzowana transakcja w świetle UUP/PSD2 - czy każda zareklamowana przez klienta transakcja, jako nie realizowana przez niego jest nieautoryzowaną? Jeśli tak, to czy w każdym przypadku bank będzie zmuszony przywracać saldo najpóźniej następnego dnia roboczego do poziomu sprzed transakcji?

1.1. Wykładnia pro-unijna.

Przepisy UUP dotyczące transakcji nieautoryzowanych należy interpretować z uwzględnieniem treści dyrektywy.

W pierwszej kolejności należy zwrócić uwagę na pojęcia autoryzacji i uwierzytelnienia.

Autoryzacja (authorisation) to zgoda na wykonanie transakcji płatniczej wyrażona przez płatnika w sposób przewidziany w umowie (por. wyjaśnienia służb Komisji Europejskiej, PSD1 Q&A, pytanie nr 77.).

Uwierzytelnienie (authentication) to procedura umożliwiająca dostawcy usług (bankowi) na weryfikację tożsamości użytkownika lub ważności stosowania konkretnego instrumentu płatniczego, łącznie ze stosowaniem indywidualnych danych uwierzytelniających tego użytkownika.

Zgodnie z art. 45 UUP odnoszącym się do obowiązków dostawcy (banku), w sytuacji gdy płatnik twierdzi, że transakcja była nieautoryzowana, dostawca musi wykazać:

Tymczasem art. 72 dyrektywy PSD2 - implementowany w art. 45 UUP - stanowi, że w sytuacji gdy płatnik twierdzi, że transakcja była nieautoryzowana, dostawca musi wykazać:

Przepis ustawy wymaga od dostawcy (banku) wykazania autoryzacji transakcji, zaś przepis PSD2 - uwierzytelnienia. Problem w implementacji PSD2 istniał już na gruncie PSD1 (błędne tłumaczenie dyrektywy PSD1 na język polski). Biorąc pod uwagę jednoznaczne brzmienie przepisów PSD1 i PSD2, należy przyjąć, że dowodami autoryzacji ze strony dostawcy - na gruncie art. 45 UUP - są następujące okoliczności:

Konieczna jest wykładania ustawy zmierzająca do zapewnienia zgodności z PSD2. Co więcej, żądanie od dostawcy wykazania, że transakcja była autoryzowana jest żądaniem niemożliwym do spełnienia - dostawca nie ma ku temu narzędzi. Dostawca jest w stanie jedynie wykazać że doszło (lub nie) do uwierzytelnienia - ponieważ jest to procedura stosowana przez samego dostawcę.

Mając na uwadze zasady składania oświadczeń woli, warto zauważyć, że skoro autoryzacja jest "zgodą" na dokonanie transakcji, to zgoda ta musi przybrać jakąś widoczną dla otoczenia formę. W przypadku transakcji płatniczych taką formę stanowi użycie instrumentu płatniczego - które to użycie jest poprzedzone uwierzytelnieniem (ewentualnie użycie i uwierzytelnienie następują jednocześnie).

Oświadczenia woli składane w obrocie cywilno-prawnym (w tym wypadku zgoda) muszą przyjmować określone formy (zachowania), by mogły być odebrane przez otoczenie. Tylko po wyrażeniu, uzewnętrznieniu określonego oświadczenia woli można stwierdzić, że doszło do jego złożenia.

Przepis UUP niepoprawnie, wbrew treści PSD2 odwołuje się do wykazania "zgody" - a nie wykazania jej zewnętrznego przejawu, jakim jest uwierzytelnienie.

Na dostawcy spoczywa zatem obowiązek wykazania, że transakcja była uwierzytelniona, oraz należycie zarejestrowana w księgach, a także, że nie miała na nią wpływu awaria.

Oznacza to, że samo twierdzenie klienta (płatnika, użytkownika), iż transakcja nie była autoryzowana, nie stanowi obowiązku uznania, iż tak było rzeczywiście, a co za tym idzie, nie oznacza obowiązku przywrócenia rachunku do stanu, jaki istniałby, gdyby do transakcji nie doszło, w terminie do dnia następnego po zgłoszeniu nieautoryzowanej transakcji - o ile dostawca wykaże wyżej opisane okoliczności. Warto tutaj wskazać na:

Należałoby zatem przyjąć, że w przypadku stwierdzenia wystąpienia nieautoryzowanej transakcji płatniczej lub otrzymania stosownego zgłoszenia od klienta, dostawca może odmówić zwrotu środków w terminie D+1 w następujących przypadkach:

(1) wbrew twierdzeniom płatnika, transakcja była autoryzowana, na co dostawca posiada dowody wskazane w przepisach (art. 45 UUP oraz art. 72 PSD2 tj. transakcja była uwierzytelniona, nastąpił jej prawidłowy zapis w systemie oraz brak było awarii lub innej usterki), a płatnik poza samym zakwestionowaniem transakcji (jako nieautoryzowanej) nie przedstawił dowodów świadczących o braku autoryzacji;

(2) transakcja była nieautoryzowana - o czym dostawca wie albo przed upływem terminu zwrotu (D+1) nie jest w stanie podjąć decyzji o uznaniu transakcji za autoryzowaną zgodnie z pkt (1), powyżej, a jednocześnie:

(i) roszczenie użytkownika wygasło na skutek upływu terminu zawitego (zob. art. 46 ust. 1 w zw. z art. 44 ust. 2 UUP oraz art. 73 ust. 1 w zw. z art. 71 PSD2); lub

(ii) dostawca ma uzasadnione i należycie udokumentowane podstawy, aby podejrzewać oszustwo (ze strony użytkownika) oraz, gdy poinformuje o tym w formie pisemnej organy powołane do ścigania przestępstw (zob. art. 46 ust. 1 UUP oraz art. 73 ust. 1 PSD2).

1.2. Podejrzenie oszustwa.

Co do wykazania "oszustwa" - po pierwsze, nie każda nieautoryzowana transakcja (wedle twierdzeń płatnika/użytkownika) będzie transakcją oszukańczą. Mogą też mieć miejsce np. transakcje dokonane przez osoby, którym płatnik/użytkownik udostępnił instrument płatniczy - wbrew umowie z dostawcą (bankiem), lub nierzadkie sytuacje, w których płatnik/użytkownik zapomniał o dokonywaniu takiej transakcji.

Po drugie - jeśli zachodzi podejrzenie, że doszło do oszustwa, to ani językowa, ani też celowościowa wykładnia normy wynikającej z art. 46 ust. 1 UUP nie pozwala przyjąć, że w terminie D+1 dostawca powinien także dokonać zawiadomienia organów ścigania. Termin D+1 jest terminem zastrzeżonym dla czynności dostawcy polegającej na dokonaniu zwrotu kwoty transakcji płatnikowi. Zawiadomienie do organów ścigania należy złożyć po wstępnym zweryfikowaniu sprawy, by nie składać zawiadomień o czynach de facto nie będących czynami zabronionymi.

Trzeba też zwrócić uwagę na to, że przepis art. 46 ust. 1 UUP mówi o "podejrzeniu oszustwa". Powstaje pytanie, jakie czyny zabronione kryją się pod tym pojęciem. Co prawda dostawca (bank) składając zawiadomienie do organów ścigania nie jest zobowiązany do wskazania przepisu, który typizuje czyn opisany w zawiadomieniu, to jednak istotne jest określenie zakresu pojęcia "oszustwo", aby bank miał jasność co do tego, czy w danej sytuacji zachodzi wyjątek od obowiązku zwrotu płatnikowi kwoty nieautoryzowanej transakcji płatniczej, określony w art. 46 ust. 1 u.u.p.

Jak się wydaje - nie budzi wątpliwości, że są to czyny stypizowane w art. 286 k.k. (oszustwo) i 287 k.k. (oszustwo komputerowe), jednak już nie czyny z art. 284 k.k. (przywłaszczenie) czy 278 k.k. (kradzież).

Odnosząc się do pojęcia "oszustwa" na gruncie art. 46 ust. 1 UUP należy jednak przyjąć szersze niż tylko przyjęte w art. 286 i 287 k.k. jego rozumienie, tj. rozumienie ogólne, potoczne. Przemawia za tym okoliczność, że także dyrektywa PSD2, której wdrożenie stanowi m.in. przepis art. 46 ust. 1 UUP, a która obowiązuje we wszystkich krajach UE, poprzestaje na ogólnym odniesieniu do "oszustwa" (fraud), nie odnosząc się do szczegółowych pojęć ujętych w systemach prawa karnego poszczególnych państw UE. Przemawia za tym także brzmienie motywu (71) do PSD2, na gruncie którego prawodawca europejski zamiennie posłużył się określeniem "nieuczciwych zamiarów" użytkownika.

Należałoby zatem przyjąć, że "oszustwem" w rozumieniu UUP, jest działanie płatnika, którego celem jest doprowadzenie dostawcy usług płatniczych do niekorzystnego rozporządzenia mieniem w celu osiągnięcia przez płatnika korzyści majątkowej (wyłudzenie środków). Jako oszustwo będzie mógł zatem być zakwalifikowany zarówno czyn z art. 286 k.k., jaki i wykroczenie o podobnych znamionach (poniżej kwoty granicznej przy tzw. "czynach przepołowionych").

Mając powyższe na uwadze nie tylko czyny stypizowane w k.k. jako oszustwo mogą stanowić podstawę do złożenia zawiadomienia do organów ścigania.

1.3. Niezachowanie obowiązków przez płatnika, rażące niedbalstwo płatnika, umyślność działania płatnika.

Rozważając brzmienie art. 46 UUP, należy się także zastanowić, czy określony w art. 46 ust. 1 UUP obowiązek przywrócenia rachunku do stanu sprzed nieautoryzowanej transakcji jest wyłączony także w warunkach z art. 46 ust. 3 UUP, tj. gdy płatnik doprowadził do nieautoryzowanej transakcji umyślnie albo w wyniku umyślnego lub będącego skutkiem rażącego niedbalstwa naruszenia co najmniej jednego z obowiązków, o których mowa w art. 42 UUP.

Literalnie przepis art. 46 ust. 1 UUP wskazuje na możliwość odmowy zwrotu kwoty nieautoryzowanej transakcji płatniczej tylko w przypadku, gdy dostawca podejrzewa oszustwo.

W oparciu o wykładnię gramatyczną, można zatem twierdzić, że fakt doprowadzenia przez płatnika do wystąpienia nieautoryzowanej transakcji płatniczej z powodu np. będącego skutkiem rażącego niedbalstwa naruszenia co najmniej jednego z obowiązków, o których mowa w art. 42 UUP, nie powinien mieć wpływu na obowiązek dostawcy do dokonania zwrotu (obowiązek dalej istnieje). Jest to bowiem w dalszym ciągu transakcja nieautoryzowana, lecz spowodowana umyślnością lub rażącym niedbalstwem po stronie użytkownika.

Biorąc jednak pod uwagę cel i funkcję omawianej regulacji, trudno byłoby wskazać na logiczny sens dokonywania zwrotu przez dostawcę kwoty nieautoryzowanej transakcji spowodowanej przykładowo rażącym niedbalstwem po stronie klienta, skoro płatnik ponosząc w takim przypadku pełną odpowiedzialność za nieautoryzowaną transakcję (art. 46 ust. 3 UUP) będzie musiał oddać dostawcy nienależnie przyznane mu środki.

Wykładnia celowościowa przemawia zatem za wyłączeniem ustanowionego w art. 46 ust. 1 UUP obowiązku zwrotu użytkownikowi kwoty nieautoryzowanej transakcji płatniczej nie tylko w przypadku podejrzenia oszustwa, ale także w sytuacji, gdy płatnik doprowadził do nieautoryzowanej transakcji umyślnie albo w wyniku umyślnego lub będącego skutkiem rażącego niedbalstwa naruszenia co najmniej jednego z obowiązków, o których mowa

w art. 42 UUP.

W tym wypadku kluczowe znaczenie ma zdobycie informacji od użytkownika o sposobie przechowywania instrumentu płatniczego, ale także o sposobie posługiwania się nim - szczególnie gdy mowa o instrumentach, na które składają się zbiory procedur - i tu warto pamiętać, że także karty w przypadku płatności on-line są de facto zbiorami procedur.

Mając powyższe na uwadze, po otrzymaniu informacji o nieautoryzowanej transakcji, bank powinien podjąć bezzwłoczny kontakt z klientem w celu ustalenia czy wykonywał on należycie swoje obowiązki, w szczególności w zakresie sposobu przechowywania instrumentu płatniczego oraz danych uwierzytelniających (w tym sposobu korzystania z instrumentu). Pomocne mogłoby być przygotowanie zestawu pytań do klientów na potrzeby takich sytuacji.

W tym kontekście warto też rozważyć przegląd treści umów dotyczących instrumentów płatniczych pod kątem opisania w nich (lub w zasadach bezpieczeństwa, stanowiących załączniki, integralne części umów) zasad posługiwania się instrumentami płatniczymi, ich przechowywania czy np. zasady ustalania haseł (np. zakaz ustalania kodu PIN/ hasła składającego się z jakiejkolwiek części daty urodzenia). Takie postanowienia mogłyby być pomocne w ustalaniu czy płatnik/ użytkownik nie dopuścił się rażącego niedbalstwa.

Podsumowując, twierdzenie płatnika/użytkownika, iż transakcja jest nieautoryzowana nie oznacza "automatycznej" konieczności zwrotu kwoty transakcji, za czym dodatkowo przemawiają argumenty wynikające z interpretacji motywów i przepisów PSD2, tj. art. 72 ust. 1 i 73 ust. 1 PSD2:

"Art. 72 ust. 1 zd. 1. Państwa członkowskie nakładają wymóg, zgodnie z którym w przypadku gdy użytkownik usług płatniczych zaprzecza, że autoryzował wykonaną transakcję płatniczą, lub twierdzi, że transakcja płatnicza została wykonana nieprawidłowo, do dostawcy usług płatniczych należy udowodnienie, że transakcja ta została uwierzytelniona, dokładnie zapisana, ujęta w księgach i że na transakcję nie miała wpływu awaria techniczna ani innego rodzaju usterka związana z usługą świadczoną przez danego dostawcę usług płatniczych."

"Art. 73 ust. 1. Państwa członkowskie zapewniają, aby - bez uszczerbku dla art. 71 - w przypadku nieautoryzowanej transakcji płatniczej dostawca usług płatniczych płatnika dokonywał na rzecz płatnika zwrotu kwoty nieautoryzowanej transakcji płatniczej, bezzwłocznie, a w każdym razie nie później niż do końca następnego dnia roboczego, po odnotowaniu danej transakcji lub po otrzymaniu stosownego zgłoszenia, z wyjątkiem sytuacji gdy dostawca usług płatniczych płatnika ma uzasadnione podstawy, by podejrzewać oszustwo, i poinformuje na piśmie o tych podstawach odpowiedni organ krajowy. W stosownych przypadkach dostawca usług płatniczych płatnika przywraca obciążony rachunek płatniczy do stanu, jaki istniałby, gdyby nie miała miejsca nieautoryzowana transakcja płatnicza. Obejmuje to również zapewnienie, by data waluty w odniesieniu do uznania rachunku płatniczego płatnika nie była późniejsza od daty obciążenia tą kwotą."

oraz motywy (70) i (71) do dyrektywy PSD2;

" (70) Aby ograniczyć ryzyka i konsekwencje nieautoryzowanych lub nieprawidłowo wykonanych transakcji płatniczych, użytkownik usług płatniczych powinien jak najszybciej poinformować dostawcę usług płatniczych o wszelkich reklamacjach dotyczących rzekomo nieautoryzowanych lub nieprawidłowo wykonanych transakcji płatniczych, pod warunkiem że dostawca usług płatniczych wypełnił swoje obowiązki z zakresu informowania zgodnie z niniejszą dyrektywą. Jeżeli użytkownik usług płatniczych dokona zgłoszenia w terminie, powinien mieć możliwość dochodzenia tych roszczeń zgodnie z krajowymi okresami przedawnienia. Niniejsza dyrektywa nie powinna wpływać na inne roszczenia między użytkownikami usług płatniczych a dostawcami usług płatniczych. (patrz: art. 44 ust. 2 UUP - jeżeli użytkownik nie dokona powiadomienia dostawcy o stwierdzonych nieautoryzowanych, niewykonanych lub nienależycie wykonanych transakcjach płatniczych w terminie 13 miesięcy od dnia obciążenia rachunku płatniczego albo od dnia, w którym transakcja miała być wykonana, roszczenia użytkownika względem dostawcy z tytułu nieautoryzowanych, niewykonanych lub nienależycie wykonanych transakcji płatniczych wygasają).

(71) W przypadku nieautoryzowanej transakcji płatniczej dostawca usług płatniczych powinien bezzwłocznie zwrócić płatnikowi kwotę tej transakcji. Jeżeli jednak zachodzi duże prawdopodobieństwo nieautoryzowanej transakcji wynikającej z działania użytkownika usług płatniczych w nieuczciwych zamiarach, a podejrzenie to opiera się na obiektywnych podstawach zgłoszonych odpowiedniemu organowi krajowemu, przed dokonaniem zwrotu na rzecz płatnika dostawca usług płatniczych powinien być w stanie przeprowadzić w rozsądnym terminie dochodzenie. (...)".

1.4. Analiza Rzecznika Finansowego: "Nieautoryzowane transakcje - zasady i główne problemy".

W dniu 18 czerwca 2019 r. na stronie internetowej Rzecznika Finansowego została opublikowana Analiza "Nieautoryzowane transakcje - zasady i główne problemy" (dalej także: Analiza) poruszająca m.in. problem właściwej implementacji nowych rozwiązań wynikających z PSD2, w tym w zakresie autoryzacji. Trzeba wskazać, że swoje rozważania Rzecznik Finansowy oparł wyłącznie na przepisach art. 45-46 UUP, dochodząc tym samym do błędnych wniosków co do właściwego określenia obowiązków dostawców usług płatniczych. W Analizie w ogóle nie przytoczono treści przepisu art. 72 PSD2, w związku z czym należy ocenić ją jako wadliwą i przesadnie uproszczoną, gdyż pomija ona brzmienie przepisów dyrektywy i opiera się wyłącznie na błędnym przyjęciu istnienia obowiązku dostawców usług płatniczych do wykazania faktu autoryzowania danej transakcji płatniczej.

Ponadto, w Analizie sformułowana została teza zgodnie z którą ustalenie zasad ewentualnej odpowiedzialności płatnika za nieautoryzowaną transakcję następuje dopiero po zwrocie środków - zdaniem Rzecznika Finansowego ustalenie zasad odpowiedzialności płatnika za nieautoryzowaną transakcję płatniczą powinno odbywać się w toku postępowania sądowego; dostawca powinien zatem pozwać klienta o zwrot kwoty transakcji, którą według jego oceny, powinien być obciążony płatnik.

Biorąc pod uwagę możliwe skutki związane z udostępnieniem Analizy, Związek Banków Polskich uznał za zasadne i konieczne podjęcie polemiki z zaprezentowaną przez Rzecznika Finansowego interpretacją zagadnienia nieautoryzowanych transakcji. W polemice wskazano, że błędne wnioski płynące z Analizy mogłyby przełożyć się na nieuprawnione obciążanie banków odpowiedzialnością za wszelkie przypadki wystąpienia nieautoryzowanych transakcji płatniczych, co w sposób oczywisty będzie krzywdząco oddziaływać na wyroki zapadające w tego typu sprawach.

W ww. stanowisku, opierając się na argumentacji zaprezentowanej w niniejszych Wyjaśnieniach interpretacyjnych, zakwestionowano uznanie, iż dostawca usług płatniczych w przypadku zgłoszenia nieautoryzowanej transakcji płatniczej powinien wykazać fakt jej autoryzacji, a nie uwierzytelnienia.

Jeżeli chodzi o rozważania Rzecznika Finansowego dotyczące konieczności dokonania automatycznego zwrotu kwoty transakcji płatnikowi i możliwości ustalenia jego odpowiedzialności dopiero w wyniku pozwania go przez dostawcę, trzeba zauważyć, że takie stanowisko nie tylko nie wynika z powszechnie obowiązujących przepisów prawa, ale jest nie do pogodzenia z obowiązkiem dostawców do dokonania zwrotu środków w tzw. terminie D+1 z możliwością powołania się na określone w przepisach wyjątki od tej zasady.

Jednocześnie żaden z przepisów ustawy o usługach płatniczych nie przewiduje konieczności dochodzenia przez dostawcę zwrotu nieautoryzowanej transakcji wyłącznie na drodze postępowania sądowego. Wręcz przeciwnie, na brak obowiązku zwrotu ograniczonej lub pełnej kwoty nieautoryzowanej transakcji płatniczej wskazuje również umiejscowienie przepisów dotyczących tego obowiązku w jednej jednostce redakcyjnej (art. 46 UUP) z przepisami określającymi przesłanki ograniczonej oraz pełnej odpowiedzialności płatnika za nieautoryzowaną transakcję płatniczą, co świadczy o wprowadzeniu przez ustawodawcę w art. 46 ust. 2-3 UUP wyjątków od zasady zwrotu określonej w art. 46 ust. 1 UUP.

Dostawca ma szereg instrumentów, aby domagać się od klienta zwrotu środków, którymi według jego oceny powinien być obciążony płatnik (np. poprzez uprzednie wezwanie do zapłaty i dobrowolną spłatę zadłużenia). To bank zna okoliczności faktyczne sprawy i to bank dysponuje materiałem dowodowym, aby w pierwszej kolejności ustalić, czy płatnik jest odpowiedzialny za nieautoryzowaną transakcję płatniczą (np. wskutek rażącego niedbalstwa). Również dostawca, wbrew twierdzeniom Rzecznika Finansowego jest obowiązany w ramach zgłoszonej reklamacji ustalić zasady ewentualnej współodpowiedzialności płatnika za nieautoryzowaną transakcję i dokonać oceny faktycznej i prawnej pewnych zdarzeń. Na obowiązek ten wskazuje art. 9 pkt 1 i 2 ustawy z dnia 5 sierpnia 2015 r. o rozpatrywaniu reklamacji przez podmioty rynku finansowego i o Rzeczniku Finansowym, do której stosuje się przepisy w zakresie nieuregulowanym w art. 15a ust. 2-4 UUP. Zgodnie z jego brzmieniem, w odpowiedzi na reklamację, dostawca usług płatniczych ma obowiązek zawrzeć uzasadnienie faktyczne i prawne (o ile reklamacja nie została rozpatrzona zgodnie z wolą klienta) oraz wyczerpującą informację na temat stanowiska podmiotu rynku finansowego w sprawie skierowanych zastrzeżeń.

W świetle powyższych ustaleń, niezrozumiałe jest stanowisko Rzecznika Finansowego wskazujące na ustalanie zasad współodpowiedzialności płatnika dopiero po dokonaniu zwrotu środków (innymi słowy - konieczność pozwania klienta o zwrot kwoty transakcji) i korespondujący z tym pogląd, jakoby w innej sytuacji bank miał być "sędzią we własnej sprawie". Powyższe, notabene, kłóci się z kolejną tezą Analizy o niewywiązywaniu się przez banki - zdaniem Rzecznika Finansowego - z obowiązku udowodnienia i udokumentowania swoich twierdzeń na etapie reklamacyjnym, czy w trakcie postępowań interwencyjnych.

Dodatkowo, patrząc na skutki stricte procesowe przyjęcia rozwiązania zaproponowanego przez Rzecznika Finansowego, trzeba wyjaśnić, że dochodzenie przez bank od klienta zasadnych roszczeń o zwrot kwot nieautoryzowanych transakcji płatniczych, za które odpowiedzialność ponosiłby zgodnie z ww. przepisami klient, narażałoby tego ostatniego na konieczność poniesienia kosztów przegranego procesu, ponieważ powództwo banku zapewne zostałoby uwzględnione w całości. Trudno zatem zgodzić się, że przyjęcie prostej zasady automatycznego zwrotu środków, a następnie wytaczanie powództw przeciwko płatnikom jest rozwiązaniem korzystnym dla klientów.

2. Jak należy liczyć termin, o którym mowa w art. 46 ust. 1 UUP, w przypadku gdy na rachunku widnieje blokada środków pod daną transakcję, ale jeszcze nie doszło do rozliczenia transakcji, zaś płatnik/użytkownik dokonuje zgłoszenia transakcji nieautoryzowanej?

Zgodnie z art. 46 ust. 1 zd. 1 UUP, z zastrzeżeniem art. 44 ust. 2 UUP (niepowiadomienie dostawcy przez użytkownika o stwierdzonych nieautoryzowanych, niewykonanych lub nienależycie wykonanych transakcjach płatniczych w odpowiednim terminie), w przypadku wystąpienia nieautoryzowanej transakcji płatniczej dostawca płatnika niezwłocznie, nie później jednak niż do końca dnia roboczego następującego po dniu stwierdzenia wystąpienia nieautoryzowanej transakcji, którą został obciążony rachunek płatnika, lub po dniu otrzymania stosownego zgłoszenia, zwraca płatnikowi kwotę nieautoryzowanej transakcji płatniczej, z wyjątkiem przypadku gdy dostawca płatnika ma uzasadnione i należycie udokumentowane podstawy, aby podejrzewać oszustwo, i poinformuje o tym w formie pisemnej organy powołane do ścigania przestępstw.

Odpowiednikiem ww. przepisu UUP jest art. 73 ust. 1 zd. 1 PSD2:

"Państwa członkowskie zapewniają, aby - bez uszczerbku dla art. 71 - w przypadku nieautoryzowanej transakcji płatniczej dostawca usług płatniczych płatnika dokonywał na rzecz płatnika zwrotu kwoty nieautoryzowanej transakcji płatniczej, bezzwłocznie, a w każdym razie nie później niż do końca następnego dnia roboczego, po odnotowaniu danej transakcji lub po otrzymaniu stosownego zgłoszenia, z wyjątkiem sytuacji gdy dostawca usług płatniczych płatnika ma uzasadnione podstawy, by podejrzewać oszustwo, i poinformuje na piśmie o tych podstawach odpowiedni organ krajowy.".

Artykuł 46 ust. 1 UUP odnosi się do dnia "obciążenia rachunku" płatnika lub dnia otrzymania "stosownego zgłoszenia". Pojawia się zatem pytanie, jak powinien postąpić bank, w przypadku gdy na rachunku płatnika już widnieje blokada środków pod daną transakcję, ale jeszcze nie doszło do obciążenia rachunku (rozliczenia transakcji). W praktyce zablokowana kwota transakcji jest już bowiem niedostępna dla klienta (płatnika/użytkownika), pomimo tego, że nie doszło jeszcze do obciążenia rachunku (rozliczenia transakcji).

Bank, po dokonanym zgłoszeniu, powinien podjąć możliwe kroki w celu niedopuszczenia do realizacji transakcji. W takim przypadku mogłoby bowiem dojść do wykonania transakcji nieautoryzowanej.

Warto też wyjaśnić, że dyrektywa PSD2 nie odnosi się do "obciążenia rachunku", ale jedynie do "odnotowania danej transakcji". To ostatnie określenie zostało wprowadzone na gruncie UUP jako "stwierdzenie wystąpienia nieautoryzowanej transakcji" i nie należy odnosić go do zastosowanego na gruncie UUP określenia "obciążenia rachunku". Wprowadzając w art. 46 ust. 1 UUP określenie "obciążenie rachunku", polski prawodawca doprecyzował jedynie, że przez transakcję zrealizowaną należy rozumieć transakcję, w wyniku której doszło do obciążenia rachunku użytkownika (wystąpiła nieautoryzowana transakcja płatnicza).

Nie powinno jednak ulegać wątpliwości, że początek biegu terminu na zwrot kwoty nieautoryzowanej transakcji płatniczej (D+1) może być skutkiem zarówno zgłoszenia dokonanego przez użytkownika, jak również stwierdzenia wystąpienia nieautoryzowanej transakcji przez dostawcę (bez uprzedniego zgłoszenia ze strony użytkownika). "Stwierdzenie wystąpienia nieautoryzowanej transakcji płatniczej", o którym mowa w art. 46 ust. 1 UUP, odnosi się od samodzielnego ustalenia tego faktu przez dostawcę.

III. Problematyka związana ze zwolnieniem z obowiązku stosowania interfejsu awaryjnego (fallback option)

1. Udostępnienie API wyłącznie na środowisku testowym a spełnienie wymagania powszechnego stosowania (tzw. wide usage).

Zgodnie z art. 33 ust. 6 lit. c RTS, jednym z warunków uzyskania przez ASPSP zwolnienia spod obowiązku ustanowienia mechanizmów awaryjnych (tzw. opcja fallback) jest zapewnienie powszechnego stosowania specjalnego interfejsu dostępowego przez okres co najmniej 3 miesięcy. W związku z tym, iż wiele ASPSP chciałoby uzyskać zwolnienie ze stosowania interfejsu specjalnego przed rozpoczęciem stosowania RTS, pojawiło się pytanie dotyczące rozumienia sformułowania powszechnego stosowania.

Zgodnie z wytyczną nr 7.3. Wytycznych EBA z 4 grudnia 2018 r., trzymiesięczny okres, o którym mowa w art. 33 ust. 6 lit. c RTS, może biec jednocześnie z okresem testów, o których mowa w art. 30 ust. 5 RTS (por. także pkt 39 ostatecznego raportu EBA ws. Wytycznych z 4 grudnia 2018 r. oraz pkt 55 dokumentu konsultacyjnego z 13 czerwca 2018 r.). Stanowisko to zostało potwierdzone w piśmie KNF z 22 marca 2019 r. (s. 2).

Należy podkreślić, że o ile środowisko testowe nie opiera się na wymianie prawdziwych danych klientów (non-real PSU data - por. wytyczna nr 6.5. Wytycznych EBA z 4 grudnia 2018 r.), o tyle środowisko produkcyjne (które należy utożsamiać z tzw. fazą "powszechnego stosowania", ang. wide usage) powinno opierać się na wymianie prawdziwych danych klientów (por.m.in. pkt 35 ostatecznego raportu EBA ws. Wytycznych z 4 grudnia 2018 r. oraz odpowiedź EBA na pyt. nr 101 do ostatecznego raportu ws. Wytycznych EBA). Co istotne, w okresie "powszechnego stosowania" pomiędzy ASPSP i TPP może dochodzić do wymiany prawdziwych (żywych) danych klientów jedynie w przypadku, gdy TPP posiada stosowne zezwolenie organu nadzoru lub wpis do właściwego rejestru, uprawniający go do świadczenia usług płatniczych.

Powyższe stanowisko zostało potwierdzone w piśmie KNF z 22 marca 2019 r. (s. 6).

2. Komunikacja przez API w kontekście spełnienia wymogów PSD2 poprzez zaimplementowanie metody uwierzytelnienia/autoryzacji klienta, podczas wydawania zgody na AIS/PIS/CAF z użyciem metody redirection, bez implementowania alternatywy w postaci zewnętrznego narzędzia autoryzacyjnego (decoupled).

Zgodnie z art. 32 ust. 3 RTS, dostawcy usług płatniczych prowadzący rachunek, którzy wprowadzili specjalny interfejs (API), zapewniają, aby interfejs ten nie stwarzał przeszkód (obstacles) w świadczeniu usług inicjowania płatności (PIS) i usług dostępu do informacji o rachunku (AIS). Przeszkody takie mogą obejmować m.in. uniemożliwianie dostawcom usług płatniczych, o których mowa w art. 30 ust. 1 RTS, wykorzystywania danych uwierzytelniających wydanych przez dostawców usług płatniczych prowadzących rachunek ich klientom, wymuszanie przekierowania (redirection) do mechanizmu uwierzytelniania lub innych funkcji dostawcy usług płatniczych prowadzącego rachunek, wymóg uzyskania dodatkowych zezwoleń oraz dodatkowych rejestracji oprócz tych przewidzianych w art. 11, 14 i 15 dyrektywy (UE) 2015/2366 lub wymóg dodatkowej weryfikacji zgody udzielonej dostawcom usług inicjowania płatności i usług dostępu do informacji o rachunku przez użytkowników usług płatniczych.

Powyższy przepis był początkowo interpretowany jako konieczność stosowania oprócz redirection także innej metody dostępu do procedur uwierzytelnienia, jednakże obecnie odmienne stanowisko zajmuje w tym przedmiocie EBA. W wytycznych: Guidelines on the conditions to be met to benefit from an exemption from contingency measures under Article 33 (6) of Regulation (EU) 2018/389 (RTS on SCA & CSC) z dnia 4 grudnia 2018 r. EBA odniosła się do art. 32 ust. 3 RTS w następujący sposób:

Guideline 5: Obstacles

"5.1 The ASPSP should provide the competent authority with:

Jak wynika z powyższego, obecnie EBA stoi na stanowisku, że nie jest wykluczone stosowanie w ramach specjalnego interfejsu dostępowego jednej metody dostępu do procedur uwierzytelnienia (redirection/ decoupled/ embedded), pod warunkiem, że bank wyjaśni, dlaczego ta metoda nie stanowi przeszkody, o której mowa w art. 32 ust. 3 RTS, oraz wskaże w jaki sposób metoda ta umożliwia TPP oparcie się na wszelkich procedurach uwierzytelniania zapewnianych użytkownikowi przez bank. Bank powinien ponadto udowodnić, że specjalny interfejs dostępowy nie powoduje nieuzasadnionych (zbędnych) opóźnień oraz nie utrudnia użytkownikowi korzystania z usług TPP oraz że interfejs ten nie wywołuje innych cech, w tym zbędnych lub niepotrzebnych czynności, użycia niejasnych lub zniechęcających sformułowań, które bezpośrednio albo pośrednio zniechęcałyby użytkownika do korzystania z usług PISP, AISP oraz CBPII.

Co więcej, EBA wprost dopuściła, że jedyną stosowaną przez ASPSP metodą dostępu do uwierzytelniania, może być metoda redirection (por. ostateczny raport ws. Wytycznych EBA z 4 grudnia 2018 r., pkt 25 i 27).

3. Problematyka formy, w jakiej należy dostarczyć do KNF wniosek o zwolnienie z obowiązku stosowania interfejsu awaryjnego oraz problematyka związana z koniecznością potwierdzenia informacji zawartych we wniosku przez audyt (zgodnie z art. 3 RTS), (audyt wewnętrzny banku, czy też audyt zewnętrzny).

Zgodnie z wytyczną nr 6.1. Wytycznych EBA z 4 grudnia 2018 r., ASPSP w celu uzyskania zwolnienia spod obowiązku ustanowienia mechanizmów awaryjnych (tzw. fallback) ma obowiązek wykazać zgodność specjalnego interfejsu dostępowego z mającymi zastosowanie ramami prawnymi.

Ponadto, zgodnie z pkt 64 z EBA Consultation Paper z dnia 13 czerwca 2018 r.:

"Article 33 (6) requires that CAs exempt firms from the fall back 'after consultation' with the EBA. This is to ensure a consistent application of the four conditions for exemption. The format in which a CA requires information from the ASPSP is a decision for the CA to take; whether the CA will require audit reports from the ASPSP or other supporting information on which to determine its exemption assessment. The role of the EBA is to contribute to the consistent application of the exemption conditions and to highlight and address divergent approaches between CAs."

Zgodnie z uwagami przedstawionymi przez EBA w ramach dokumentu konsultacyjnego ws. Wytycznych, krajowe ograny nadzoru mogą oczekiwać - dla potrzeb udzielenia zwolnienia spod tzw. opcji fallback - przedstawienia dodatkowych informacji i dokumentów, w stosunku do tych, które są wprost sugerowane przez EBA. EBA wskazuje jako przykład możliwość oczekiwania przez krajowe organu nadzoru, że ASPSP przeprowadzą stosowne audyty zewnętrzne oraz przedstawią organowi wyniki z przeprowadzonego audytu.

W ramach prowadzonych wcześniej rozmów dot. implementacji PSD2 do krajowego porządku prawnego, KNF sygnalizowała potrzebę przeprowadzenia przez ASPSP stosownych audytów zewnętrznych, które pozwolą na ocenę zgodności z prawem wprowadzonych przez ASPSP rozwiązań z zakresu specjalnych interfejsów dostępowych. KNF wskazywała, że byłoby to uzasadnione ze względu na wysoki poziom wyspecjalizowania mających zastosowanie ram prawnych, w szczególności RTS, oraz z uwagi na konieczność dołożenia możliwych starań w celu zapewnienia bezpieczeństwa obrotu, w tym bezpieczeństwa użytkowników usług płatniczych.

Ww. stanowisko KNF zostało ostatecznie potwierdzone w piśmie z 22 marca 2019 r. (s. 7-8). W ocenie KNF, wymóg przedkładania przez ASPSP raportów z audytów zewnętrznych przy składaniu wniosków o uzyskanie zwolnienia z tzw. opcji fallback jest jak najbardziej uzasadniony.

KNF będzie oczekiwał od ASPSP przedłożenia:

4. Interpretacja motywu 24 oraz art. 33 ust. 6 RTS w kontekście obowiązku wdrożenia (zaimplementowania do systemów) interfejsu awaryjnego ASPSP na dzień 14 września 2019 r.

Motyw 24 RTS stanowi:

"Niektórzy dostawcy usług płatniczych prowadzący rachunek zostaną wyłączeni z obowiązku zapewnienia takiego mechanizmu rezerwowego za pośrednictwem stosowanego przez nich interfejsu widocznego dla klienta, jeżeli właściwe organy, którym podlegają, stwierdzą, że specjalne interfejsy spełniają szczegółowe warunki zapewniające niezakłóconą konkurencję. Jeżeli specjalne interfejsy objęte wyłączeniem nie spełniają koniecznych warunków, odpowiednie właściwe organy cofają udzielone wyłączenia."

Artykuł 33 ust. 6 RTS stanowi:

"Właściwe organy - po przeprowadzeniu konsultacji z EUNB w celu zapewnienia spójnego stosowania następujących warunków - obejmują wyłączeniem z obowiązku ustanowienia mechanizmów awaryjnych opisanych w ust. 4 tych dostawców usług płatniczych prowadzących rachunek, którzy zdecydowali się na wprowadzenie specjalnego interfejsu, jeżeli specjalny interfejs spełnia wszystkie następujące warunki (...)."

Z motywu 24 RTS oraz art. 33 ust. 6 RTS wynika, że ASPSP w przypadku uzyskania zwolnienia od KNF z obowiązku stosowania mechanizmu awaryjnego nie musi mieć zaimplementowanego mechanizmu awaryjnego do systemów ASPSP.

Należy jednak mieć na uwadze, że:

Warto wskazać, że KNF w swoim komunikacie opublikowanym 1 lipca 2019 r. wyjaśniła, że "Uwzględniając cel regulacji art. 33 ust. 6 RTS, jakim jest przede wszystkim zwolnienie ASPSP, którego API spełnia określone w tym przepisie warunki, z obowiązku tworzenia, wdrażania i utrzymywania opcji fallback, KNF informuje, że sprawdzenie spełniania tych warunków będzie mogło być dokonane w toku bieżącego nadzoru, jeszcze przed złożeniem wniosku o zwolnienie z opcji fallback i wydaniem przez KNF decyzji w tym zakresie. Sprawdzenie to powinno umożliwić ASPSP zainteresowanemu zwolnieniem z opcji fallback dokonanie oceny zasadności posiadania tych rozwiązań na dzień rozpoczęcia stosowania RTS i podjęcia decyzji co do ich przygotowania i wdrożenia. Oceniając w tym kontekście zgodność działalności ASPSP z przepisami RTS, niezależnie od ostatecznego rozstrzygnięcia w przedmiocie zwolnienia z opcji fallback, KNF będzie brać pod uwagę ustalenia poczynione w toku bieżącego nadzoru. Podkreślić należy, że nawet w przypadku ostatecznego zwolnienia zainteresowanego ASPSP z opcji fallback, ryzyko związane z nawet przejściowym niewypełnieniem obowiązku jej posiadania po 13 września 2019 r. i w związku z tym uniemożliwieniem TPP świadczenia jego usług obciążać będzie obowiązany ASPSP."

5. Ostateczny termin na złożenie wniosku do krajowego organu nadzoru o zwolnienie ze stosowania interfejsu awaryjnego gwarantujący otrzymanie decyzji przed 14 września 2019 r.

UUP ani RTS nie określają ani maksymalnego terminu, w jakim należy złożyć wniosek do KNF o udzielenie zwolnienia ze stosowania interfejsu awaryjnego, ani też terminu na rozpatrzenie wniosku przez KNF.

Również KNF w piśmie z dnia 22 marca 2019 r. nie wskazała maksymalnego terminu, w którym należy przedłożyć KNF wniosek o zwolnienie spod opcji fallback, tak by móc liczyć na wydanie przez KNF decyzji przed 14 września 2019 r.

Jeżeli chodzi o termin rozpoznania wniosku przez KNF - należy stosować przepisy ogólne (art. 35 § 3 k.p.a.: załatwienie sprawy wymagającej postępowania wyjaśniającego powinno nastąpić nie później niż w ciągu miesiąca, a sprawy szczególnie skomplikowanej - nie później niż w ciągu dwóch miesięcy od dnia wszczęcia postępowania, zaś w postępowaniu odwoławczym - w ciągu miesiąca od dnia otrzymania odwołania).

Należy ponadto zwrócić uwagę, że zgodnie z wytyczną nr 9.2 Wytycznych EBA, do dnia 31 grudnia 2019 r. KNF może udzielić zwolnienia ze stosowania mechanizmów awaryjnych bez wcześniejszej konsultacji z EBA. Wystarczające będzie tutaj zawiadomienie EBA przez KNF o zamiarze udzielenia zwolnienia. Tym samym nie jest konieczne, aby przed udzieleniem zwolnienia (w okresie do 31 grudnia 2019 r.), KNF odczekał miesiąc, o którym mowa w wytycznej nr 9.1. Wytycznych EBA.

KNF podkreślił jednak, że składany przez ASPSP wniosek powinien być kompletny. Oznacza to, że wniosek i załączona do niego dokumentacja powinny potwierdzać, że stosowany przez ASPSP specjalny interfejs dostępowy spełnia przesłanki określone w art. 33 ust. 6 RTS (por. pismo KNF z 22 marca 2019 r., s. 2).

6. Możliwość złożenia do KNF wniosku o zwolnienie ze stosowania tzw. interfejsu awaryjnego przed upływem 6 miesięcznego okresy testowego, np. po 5 miesiącach testów, w tym 3 miesiącach powszechnego stosowania.

Zasady uzyskania zwolnienia spod obowiązku ustanowienia mechanizmów awaryjnych (tzw. opcja fallback) zostały określone w art. 33 ust. 6 RTS. Wśród przesłanek do uzyskania zwolnienia są wymienione m.in. następujące:

Przesłanka z lit. b odwołuje się do art. 30 ust. 5 RTS, który nakłada na ASPSP obowiązek udostępnienia środowiska testowego na sześć miesięcy przed udostępnieniem środowiska specjalnego. Ponadto, lit. c nakłada obowiązek powszechnego stosowania, które zostało omówione w pkt 3 niniejszego opracowania. Przepis ten wskazuje, że środowisko testowe powinno służyć do testowania połączenia i udostępnianych funkcjonalności oraz powinno zostać udostępnione na 6 miesięcy przed udostępnieniem interfejsu specjalnego. W związku z tym można wnioskować, że w celu uzyskania zwolnienia ze stosowania interfejsu awaryjnego należy m.in.:

Ani RTS, ani Wytyczne EBA z 4 grudnia 2018 r. nie dają jasnej odpowiedzi na pytanie, czy ASPSP może wystąpić do krajowego organu nadzoru (KNF) z wnioskiem o udzielenie zwolnienia spod obowiązku ustanowienia mechanizmów awaryjnych (tzw. opcja fallback) przed upływem 6-miesięcy od chwili udostępnienia tzw. dostawcom trzecim dokumentacji specjalnego interfejsu dostępowego oraz środowiska testowego (art. 30 ust. 3 i 5 RTS) oraz przed upływem 3-miesięcy tzw. powszechnego stosowania specjalnego interfejsu dostępowego (art. 33 ust. 6 lit. c RTS).

Stanowisko w tym zakresie zajęła jednak KNF w komunikacie z dnia 1 lipca 2019 r. Wskazano w nim, że "Zwolnienie przez KNF z opcji fallback następować będzie w drodze decyzji administracyjnej wydanej indywidualnie dla każdego podmiotu po przeprowadzeniu postępowania administracyjnego, na wniosek zainteresowanego ASPSP spełniającego wymagania, o których mowa w art. 33 ust. 6 RTS. W tym kontekście należy zwrócić uwagę na dyspozycję art. 38 ust. 2 i 3 RTS, zgodnie z którym RTS (za wyjątkiem art. 30 ust. 3 i 5, które mają zastosowanie od 14 marca 2019 r.) stosuje się od 14 września 2019 r. W świetle przepisów prawa administracyjnego oznacza to, że wniosek o wszczęcie postępowania administracyjnego w sprawie wydania decyzji zwalniającej z obowiązku posiadania opcji fallback, może być skutecznie złożony dopiero po 13 września 2019 r. Z tych względów, decyzja może być wydana przez KNF dopiero po tym terminie".

Niezależnie od powyższego, warto wskazać, że KNF dopuściła możliwość składania tzw. "pre-wniosków" o zwolnienie spod opcji fall-back jako informacji o spełnieniu warunków zwolnienia, obejmującą jak najwięcej załączników i informacji zawartych we wzorze opublikowanym przez KNF w styczniu 2019 r., z jednoczesną informacją, że dany bank zamierza wystąpić z właściwym wnioskiem po 13 września 2019 r.

IV. Problematyka związana z Account Information Service (AIS)

1. Zagadnienie dotyczące zgody na usługi dostępu do informacji o rachunku (AIS).

Zgodnie z art. 59s ust. 2 pkt 1 UUP, AISP jest obowiązany świadczyć usługi wyłącznie na podstawie zgody użytkownika wyrażonej w sposób niebudzący wątpliwości, zaś zgodnie z art. 59s ust. 2 pkt 4 UUP, AISP (TPP) może uzyskać dostęp wyłącznie do informacji dotyczących wyznaczonych rachunków płatniczych i związanych z nimi transakcji płatniczych.

W związku z powyższym powstała wątpliwość dotycząca momentu wyrażenia zgody na usługę AIS i jej treści.

Należy wyjaśnić, że Wersja 2.1 5 Specyfikacji interfejsu na potrzeby usług świadczonych przez strony trzecie w oparciu o dostęp do rachunków płatniczych - PolishAPI, dostępna na stronie internetowej (dalej: Specyfikacja) 6 , przewiduje trzy procesy udzielenia zgody na AIS:

a) Udzielenie zgody oraz pobranie informacji o rachunku z ręcznym wprowadzeniem numeru rachunku - uwierzytelnienie po stronie ASPSP/uwierzytelnienie w zewnętrznym narzędziu autoryzacyjnym,

b) Udzielenie zgody oraz pobranie informacji o rachunku z wyborem rachunku po stronie ASPSP - uwierzytelnienie po stronie ASPSP,

c) Udzielenie zgody oraz pobranie informacji o rachunku z pobraniem listy rachunków - uwierzytelnienie po stronie ASPSP/uwierzytelnienie w zewnętrznym narzędziu autoryzacyjnym.

Wyrażenie zgody na świadczenie usługi AIS przez TPP następuje we wszystkich opisanych wyżej przypadkach po dokonaniu przez klienta wyboru określonego banku z listy przedstawionej przez TPP, a przed wyborem/wpisaniem numeru określonego rachunku bankowego, którego ma dotyczyć usługa AIS. Przedmiotowa zgoda obejmuje całość usługi AIS, która obejmuje dostęp do informacji dotyczących wyznaczonych rachunków płatniczych (przy czym wyznaczenie rachunku może nastąpić także przez wskazanie banku prowadzącego rachunki dla użytkownika) i związanych z nimi transakcji płatniczych. Przez wyznaczone rachunki płatnicze należy rozumieć rachunki wyznaczone przez klienta i objęte treścią zgody - niezależnie od tego, czy ich wskazanie następuje po stronie TPP czy po stronie banku (pkt 4.2.3 Specyfikacji).

Zgoda, o której mowa w art. 59s ust. 2 pkt1 UUP nie musi obejmować wyznaczenia rachunków płatniczych, o której to czynności mowa w art. 59s ust. 2 pkt 4 UUP, ale wyznaczenie tych rachunków jest konieczne dla świadczenia usługi AIS. W konsekwencji możliwe jest świadczenie usługi AIS na podstawie jednej zgody nawet gdy użytkownik zmienił wyznaczone rachunki płatnicze na inne, z zastrzeżeniem, że treść zgody AIS powinna wyraźnie wskazywać na takie ukształtowanie zakresu zgody.

2. Wykonywanie usługi AIS przez pełnomocnika.

Na tle art. 59s UUP powstały wątpliwości dotyczące zlecania przez pełnomocników posiadaczy rachunków usługi przewidzianej w tym przepisie w sytuacji faktycznej, w której osoba będąca pełnomocnikiem posiadacza rachunku prowadzonego przez jednego z dostawców jest zarazem posiadaczem rachunku prowadzanego przez innego dostawcę usług płatniczych.

W takiej sytuacji osoba ta działać będzie jednocześnie dla dwóch użytkowników: jako pełnomocnik posiadacza rachunku i jako inny posiadacz innego rachunku. Dla uproszczenia można założyć, że udzielone tej osobie pełnomocnictwo będzie pełnomocnictwem upoważniającym do zlecenia usługi dostępu do informacji do rachunku przewidzianej art. 59s UUP (pełnomocnik będzie umocowany do działania w takim samym zakresie, w jakim jest umocowany do działania posiadacz rachunku) i obydwa rachunki dostępne będą on-line.

Problem ten, jak mogłoby się wydawać, nie wystąpi przy usłudze inicjacji transakcji płatniczych, bowiem co do zasady pełnomocnik będzie umocowany do złożenia w imieniu posiadacza zlecenia płatniczego. Z tej racji problem został zawężony tylko do usługi art. 59s UPP (AIS).

Wydaje się, że dla wykładni art. 59s UUP znaczenie może mieć także motyw 28 Dyrektywy (PSD2), który przewiduje, że usługa AIS dotyczy informacji o "swojej sytuacji finansowej".

Motyw 28:

" (28) Ponadto, postęp technologiczny doprowadził do pojawienia się w ostatnich latach wielu usług uzupełniających, takich jak usługi dostępu do informacji o rachunku. Usługi te zapewniają użytkownikowi usług płatniczych zagregowane informacje online o rachunku płatniczym lub rachunkach płatniczych posiadanych u dostawcy lub dostawców usług płatniczych, które to informacje udostępniane są w internecie poprzez interfejs dostawcy usług płatniczych prowadzącego rachunek. W ten sposób użytkownik usług płatniczych ma możliwość uzyskania w danym momencie natychmiastowego ogólnego obrazu swojej sytuacji finansowej. Usługi te należy również włączyć w zakres stosowania niniejszej dyrektywy, aby zapewnić konsumentom odpowiednią ochronę ich danych dotyczących płatności i rachunku, a także pewność prawa w odniesieniu do statusu dostawców świadczących usługę dostępu do informacji o rachunku."

Wydaje się, że przepis art. 59s UUP należy rozumieć w ten sposób, że usługa dostępu do informacji o rachunku wymaga tylko odpowiedniego uprawnienia dostępu do rachunku (jako pełnomocnik albo jako posiadacz rachunku). Przez użytkownika, o którym mowa w art. 59s ust. 1, należy wówczas rozumieć nie tylko posiadacza rachunku, lecz także pełnomocnika do rachunku/rachunków tego posiadacza.

Na usługę AIS (dostęp do informacji o rachunku) składają się dwa, niezależne od siebie, stosunki prawne: relacja pomiędzy "wnioskodawcą" (posiadaczem rachunku albo pełnomocnikiem) a TPP oraz relacja pomiędzy bankiem a TPP. Potwierdza to - jak się wydaje - treść ustępu 4 przepisu art. 59s UUP, zgodnie z którym, korzystanie przez użytkownika z usług dostępu do informacji o rachunku nie może być uzależnione od istnienia stosunku umownego między dostawcą świadczącym usługę dostępu do informacji o rachunku a dostawcą prowadzącym rachunek.

Taka interpretacja powołanych powyżej kwestii, oznaczałaby, że usługa AIS może być wykonywana również dla danej osoby działającej jako pełnomocnik lub użytkownik.

Odrębną kwestię stanowi "wyróżnienie" zagregowanych rachunków, tak, aby wynikało z niego, jaki rachunek jest rachunkiem, do którego "wnioskodawca" posiada uprawnienia jako posiadacz, a do jakiego rachunku jest tylko uprawniony jako pełnomocnik. Możliwość takiego "wyróżnienia" eliminowałaby ewentualne nadużycia. Możliwość taka istnieje w ramach standardu PolishAPI, który przewiduje przekazanie wraz z informacją o rachunku informacji o jego posiadaczu.

Niemniej jednak, nawet brak możliwości rozróżnienia rachunków posiadacza i pełnomocnika po stronie TPP nie stanowi problemu po stronie banków, bowiem wspomniana relacja pomiędzy TPP a wnioskodawcą (to u TPP są agregowane rachunki), nie ma związku z relacją pomiędzy TPP i bankami. W przypadku banków, będących TPP taka sytuacja w praktyce raczej nie będzie miała miejsca, bowiem banki mają oznaczone statusy rachunków (statusy uprawnień).

Reasumując, przy takim podejściu, usługa AIS (dostęp do informacji o rachunku) może być świadczona na rzecz pełnomocnika do rachunku.

3. Czy świadcząc usługę AIS należy obligatoryjnie zaprezentować klientowi wyniki agregacji?

Ani na gruncie PSD2, ani UUP nie zostało wprost przesądzone, że dostawca usługi AIS powinien bezwzględnie, niezależnie od woli klienta, prezentować mu w każdym przypadku wyniki przeprowadzonej agregacji.

Pewne wątpliwości może budzić w tym zakresie jedynie instrukcyjny opis usługi AIS przedstawiony w ramach motywów do PSD2 (por. motyw 28 PSD2), zgodnie z którym usługa AIS zapewnia użytkownikowi usług płatniczych "zagregowane informacje online o rachunku płatniczym lub rachunkach płatniczych posiadanych u dostawcy lub dostawców usług płatniczych". Takie sformułowanie hipotetycznie może sugerować, że użytkownik powinien mieć możliwość wglądu (w trybie online) do wyników przeprowadzonej agregacji. Oparcie się wyłącznie na szczątkowej, a w dodatku opisowej regulacji motywów PSD2 nie jest tutaj argumentem wystarczającym. Co więcej, nie oznacza to, że taki dostęp należy umożliwić klientowi w każdym przypadku (niezależnie od dyspozycji klienta).

Należy przyjąć, że konieczność prezentacji klientowi danych z przeprowadzonej agregacji zależeć będzie w każdym przypadku od umowy pomiędzy dostawcą a klientem tj. innymi słowy od konkretnej dyspozycji klienta. Jeżeli klient nie chce uzyskać takiego dostępu, to dostawca nie będzie do tego zobowiązany.

V. Pozostałe zagadnienia związane z wdrożeniem PSD2

1. Dopuszczalność stosowania opcji kosztowej OUR na wniosek klienta (art. 37a UUP).

Analizując problematykę związaną z dopuszczalnością stosowania opcji kosztowej OUR na wniosek klienta (art. 37a UUP), należałoby wskazać na dwie dopuszczalne interpretacje tego zagadnienia.

Zgodnie z pierwszym wariantem interpretacyjnym można argumentować, że przepis art. 37a UUP wprowadza jedynie domyślną, modelową opcję kosztową (opcję SHA). Użytkownik usług płatniczych mógłby jednak z własnej woli postanowić o wzięciu na siebie ciężaru wszystkich opłat związanych z realizacją transakcji płatniczej (opcja OUR). Taka interpretacja opiera się na założeniu, że nie można w sposób oczywisty i odgórny (na poziomie ustawy) przesądzić o tym, że opcja kosztowa OUR, która stosowana jest przez bank na wyraźny wniosek klienta, stanowi rozwiązanie mniej korzystne niż opcja kosztowa SHA. Co za tym idzie, zakaz stosowania postanowień umowy mniej korzystnych dla użytkowników, niż te które wynikają z UUP (zasada semiimperatywności - art. 8 UUP), nie znajdowałby tutaj zastosowania.

W praktyce, część uczestników europejskiego rynku usług płatniczych opowiedziała się za powyższą interpretacją, por.m.in.:

W sytuacji zastosowania opcji OUR na wniosek klienta, klient ten jest poinformowany o zastosowaniu tej opcji w tym również o tym, że realizacja polecenia przelewu z opcją OUR może skutkować zwrotem płatności, jednostronną zmianą opcji kosztów przez banki trzecie, w tym bank beneficjenta, oraz dodatkowymi wyższymi kosztami.

Zgodnie z drugim wariantem interpretacyjnym można argumentować, że opcja kosztowa SHA została odgórnie narzucona przez ustawodawcę w zakresie transakcji określonych w art. 37a UUP. Dotyczy to także klienta profesjonalnego z uwagi na brak możliwości wyłączenia zastosowania tego przepisu - zob. art. 33 UUP. Co za tym idzie, w przypadku transakcji wskazanych w art. 37a dostawca nie mógłby zastosować innego modelu opłat niż opcja SHA.

Warto w tym miejscu zwrócić uwagę, że obowiązkowy model opłat SHA obowiązywał już na gruncie PSD1 w stosunku do transakcji, które nie wiążą się z przeliczaniem waluty (por. dotychczasowy art. 38 UUP). W porównaniu z dotychczasowym rozwiązaniem zmiany polegają na: (i) objęciu obowiązkową opcją SHA transakcji zakładających przeliczenie waluty oraz (ii) objęciu obowiązkową opcją SHA także transakcji w walutach państw spoza EOG, jeżeli transakcja ma charakter "both legs".

Warto także zaznaczyć jaki jest cel nowej regulacji na gruncie PSD2. Zgodnie z motywem 65 PSD2:

"Co się tyczy opłat, zebrane doświadczenia pokazują, że podział opłat między płatnikiem a odbiorcą jest najbardziej wydajnym systemem, jako że ułatwia on bezpośrednie przetwarzanie płatności. W związku z tym należy ustanowić przepis, zgodnie z którym opłaty będą pobierane, w zwykłych okolicznościach, bezpośrednio od płatnika i odbiorcy przez ich odnośnych dostawców usług płatniczych. Kwota wszelkich pobieranych opłat może także wynosić zero, ponieważ przepisy niniejszej dyrektywy nie powinny mieć wpływu na praktykę, zgodnie z którą dostawca usług płatniczych nie obciąża konsumentów opłatą za uznanie ich rachunku. Podobnie, w zależności od warunków umowy, dostawca usług płatniczych może obciążyć opłatą za skorzystanie z usługi płatniczej jedynie odbiorcę (akceptanta); w takim przypadku na płatnika nie są nakładane żadne opłaty. Istnieje możliwość nakładania przez systemy płatności opłat w drodze opłaty abonamentowej. Przepisy dotyczące transferowanej kwoty lub wszelkich pobieranych opłat nie mają bezpośredniego wpływu na ustalanie cen pomiędzy dostawcami usług płatniczych lub ewentualnymi pośrednikami".

Przywołany powyżej motyw PSD2 może sugerować, że intencją prawodawcy europejskiego było ujednolicenie modelu kosztowego stosowanego na rynku europejskim i - w konsekwencji - narzucenie modelu SHA, jako modelu najbardziej wydajnego (w ocenie prawodawcy).

Prezentowany tutaj wariant interpretacyjny potwierdza także stanowisko służb Komisji Europejskiej wyrażone na gruncie dyrektywy PSD1. Zgodnie z kilkoma odpowiedziami służb Komisji Europejskiej na pytania zadane przez uczestników rynku w ramach dokumentu Q&A, art. 52 ust. 2 PSD1 (odpowiednik art. 62 ust. 2 PSD2) wprowadza dla określonych transakcji opcję SHA jako obowiązkową i tylko ten model podziału kosztów jest dopuszczalny. Co więcej, Komisja Europejska wprost wyłączyła w takim przypadku możliwość użycia opcji OUR, por.m.in.:

2. Czy w świetle art. 29 ust. 2 pkt 2 UUP należy dopuścić możliwość wypowiedzenia przez klienta umowy ze skutkiem wstecznym?

W ocenie sektora bankowego wypowiedzenie przez klienta umowy ramowej ze skutkiem wstecznym tj. ze skutkiem na dzień przed datą otrzymania przez dostawcę oświadczenia o wypowiedzeniu, należałoby uznać za niedopuszczalne.

Literalne brzmienie art. 29 ust. 2 pkt 2 UUP mogłoby sugerować, że w przypadku wprowadzenia przez dostawcę zmian w umowie ramowej, klient może wypowiedzieć umowę ramową przed datą proponowanego wejścia w życie zaproponowanych zmian, ze skutkiem na dowolnie wybrany przez siebie dzień, który nie może być jednak dniem późniejszym niż dzień, w którym zmiany zostałyby zastosowane, ani dniem wcześniejszym niż dzień, w którym otrzymał on informacje o proponowanych zmianach.

Poprzestanie wyłącznie na wynikach wykładni językowej nie jest jednak uzasadnione.

Prawidłowa interpretacja normy wynikającej z przepisu art. 29 ust. 2 pkt 2 UUP wymaga sięgnięcia do wyników wykładni celowościowej. Wydaje się, że przepis ten należy czytać w ten sposób, że użytkownik, który został poinformowany o proponowanych zmianach w umowie ramowej może, przed datą proponowanego wejścia w życie tych zmian, wypowiedzieć umowę ze skutkiem na dowolnie wybrany przez siebie dzień, który nie może być jednak dniem późniejszym niż dzień, w którym zmiany zostałyby zastosowane, ani dniem wcześniejszym niż dzień, w którym otrzymał on informacje o proponowanych zmianach, przy czym nie może to być także dzień wcześniejszy niż dzień, w którym oświadczenie o wypowiedzeniu umowy ramowej zostało otrzymane przez dostawcę usług płatniczych. Za taką interpretacją przemawia, po pierwsze, norma wynikająca z art. 61 § 1 k.c., który stanowi o obowiązującej teorii doręczenia oświadczenia woli, a po drugie, ogólne założenie skuteczności ex nunc oświadczeń o wypowiedzeniu (w przeciwieństwie np. do odstąpienia na podstawie przepisu ustawy, które skuteczne jest ex tunc).

3. Czy klient może bezpośrednio w banku odwołać zlecenie płatnicze dotyczące transakcji z datą przyszłą, które zostało zainicjowane za pośrednictwem TPP (art. 51 ust. 4 UUP)?

Brak jest podstaw normatywnych, które zabraniałyby użytkownikowi usług płatniczych odwołać zlecenie płatnicze z datą przyszłą (art. 49 ust. 3 UUP), które zostało złożone za pośrednictwem TPP, bezpośrednio u dostawcy prowadzącego rachunek (w banku).

Przepis art. 51 ust. 4 UUP stanowi lex specialis w stosunku do ogólnej zasady wynikającej z art. 51 ust. 2 UUP.

Zgodnie z art. 51 ust. 4 UUP, w przypadku zleceń płatniczych z odroczonym terminem ich wykonania, użytkownik może odwołać zlecenie płatnicze nie później niż do końca dnia roboczego poprzedzającego uzgodniony dzień realizacji zlecenia.

W ocenie sektora bankowego, płatnik może - przy zachowaniu ogólnych zasad wynikających z UUP - odwołać każde złożone przez niego zlecenie płatnicze, niezależnie od tego, czy jest ono składane bezpośrednio przez użytkownika, czy też za pośrednictwem TPP.

Podobne stanowisko zajęła EBA, wskazując, że w przypadku transakcji inicjowanych za pośrednictwem TPP, użytkownikowi należy zapewnić możliwość odwołania zainicjowanej transakcji, w tym transakcji cyklicznej ("...possibility of cancelling an initiated transaction in accordance with PSD2, including recurring transactions" - por. tabela nr 1 na str. 3 Opinii EBA).

Możliwość zainicjowania transakcji za pośrednictwem TPP stanowi jedynie jeden z kanałów (form) inicjowania transakcji płatniczych. Rozwiązania w tym zakresie nie pozbawiają zatem użytkownika jego ogólnych praw wynikających z UUP - w tym także praw związanych z możliwością odwołania zlecenia płatniczego.

Dopiero odwołanie przez płatnika zlecenia płatniczego po terminie określonym w art. 51 ust. 4 UUP (tj. później niż do końca dnia roboczego poprzedzającego uzgodniony dzień), wymagałaby zgodnie z art. 51 ust. 5 UUP zgody TPP.

Podobną interpretację zaprezentował European Credit Sector Associations (EBF, ESBG, EACB), na gruncie prac roboczych nad rekomendowanymi funkcjonalnościami specjalnych interfejsów dostępowych (w ramach API Evaluation Group) 9 .

4. Jak należy intepretować wymóg pre-autoryzacji (art. 49b UUP) w przypadku transakcji w walutach obcych?

Zgodnie z art. 49b UUP, w przypadku gdy transakcja płatnicza jest inicjowana przez odbiorcę lub za jego pośrednictwem w związku z transakcją płatniczą realizowaną w oparciu o kartę płatniczą, a jej dokładna kwota nie jest znana w momencie, w którym płatnik wyraża zgodę na wykonanie transakcji płatniczej, dostawca płatnika może dokonać blokady środków pieniężnych na rachunku płatniczym płatnika wyłącznie w przypadku, gdy płatnik wyraził zgodę na blokadę określonej kwoty środków pieniężnych (pre-autoryzacja).

Zważywszy na powyższe rozważania należałoby przyjąć, że zgoda pre-autoryzacyjna dotyczy transakcji w określonej walucie.

Jeżeli zatem płatnik wyrazi zgodę pre-autoryzacyjną przykładowo na kwotę 100 EUR po kursie 4,2 PLN (tj. płatnik wyraził zgodę na transakcję 420 PLN), a następnie kurs EUR/PLN ulegnie zmianie na 4,3 PLN, co w efekcie doprowadzi do zwiększenia wartości transakcji do 430 PLN, to transakcja będzie autoryzowana w świetle art. 49b UUP. Płatnik wyraził bowiem zgodę na wykonanie transakcji płatniczej w wysokości 100 EUR.

5. Czy działalność TPP ma zastosowanie do indywidualnych systemów komunikacji z klientami korporacyjnymi (np. host-to-host)?

Działalność TPP ma zastosowanie wyłącznie do rachunków płatniczych dostępnych online i tym samym, że nie ma ona zastosowania do szczególnych kanałów dostępu do rachunku wykorzystywanych w ramach bankowości korporacyjnej (np. host-to-host).

Zgodnie z art. 3 ust. 5 UUP, usługa PIS oznacza usługę polegającą na zainicjowaniu zlecenia płatniczego przez dostawcę świadczącego usługę inicjowania transakcji płatniczej na wniosek użytkownika z rachunku płatniczego użytkownika prowadzonego przez innego dostawcę. Zgodnie z art. 3 ust. 6 UUP, usługa AIS oznacza usługę on-line polegającą na dostarczaniu skonsolidowanych informacji dotyczących rachunku płatniczego użytkownika prowadzonego u innego dostawcy albo rachunków płatniczych użytkownika prowadzonych u innego dostawcy albo u więcej niż jednego dostawcy. Zgodnie z kolei odpowiednio z art. 59r. ust. 1 oraz art. 59s ust. 1 UUP, użytkownik może korzystać z usług PIS i AIS, chyba że rachunek płatniczy nie jest dostępny on-line.

Ani PSD2, ani RTS nie przesądzają o tym, co należy rozumieć przez rachunki płatnicze dostępne "online". Należy przyjąć, że chodzi tutaj o rachunki płatnicze, do których dostęp jest zapewniony w ramach powszechnie świadczonych usług bankowości internetowej, z wykorzystaniem stron internetowych i aplikacji mobilnych, oraz w przypadku których klient może uzyskać dostęp do rachunku przy użyciu komputera, telefonu, tabletu lub innych podobnych urządzeń (podobnie The FCA's role under the Payment Services Regulations 2017..., pkt 17.14).

Należałoby zatem przyjąć, że jeżeli dostęp do rachunku płatniczego co prawda odbywa się z wykorzystaniem szeroko rozumianej sieci internet, ale dostęp ten wymaga przy tym zastosowania specjalnych urządzeń, protokołów lub programów, to dostawca nie jest obowiązany zapewnić TPP świadczenia usług z wykorzystaniem takich kanałów.

VI. Terminy implementacji wdrożenia obowiązków wynikających z PSD2

Zgodnie z art. 12 ustawy UZUP dostawcy usług płatniczych prowadzący w dniu wejścia w życie niniejszej ustawy działalność w zakresie usług płatniczych są obowiązani, w terminie 6 miesięcy od dnia wejścia w życie ustawy, dostosować swoją działalność w zakresie usług płatniczych do przepisów ustawy o usługach płatniczych w zakresie zmienionym ustawą, czyli do 20 grudnia 2018 r.

Wyjątek stanowi art. 22 ust. 1 UUP, zgodnie z którym wymogi wskazane w art. 32i UUP (silne uwierzytelnienie) oraz wymogi wynikające z RTS, powinny być stosowane od dnia 14 września 2019.

W artykułach 49a, 59q oraz 59s UUP, które nie zostały wymienione w art. 12 UZUP, ustawodawca wskazuje na konieczność wdrożenia usług COF, PIS i AIS.

Jednocześnie w art. 22 UZUP ustawodawca wskazuje konieczność stosowania silnego uwierzytelnienia zgodnie z wymogami RTS od 14 września 2019 r. przy jednoczesnym zastrzeżeniu iż do tego czasu (tj. 14 września 2019), dostawca usług płatniczych ma stosować "dotychczasowe przepisy w zakresie bezpieczeństwa płatności".

Bezpieczne udostępnienie usług COF, AIS i PIS wymaga silnego uwierzytelnienia. W związku z tym wydaje się, iż do 14 września 2019 r. lub do momentu wdrożenia silnego uwierzytelnienia przez bank i TPP (cokolwiek nastąpi wcześniej) Banki nie mogą udostępnić usług COF, AIS lub PIS.

W nawiązaniu do powyższej problematyki ustawa zmieniająca jest wewnętrznie sprzeczna, a kwestia związana z terminami wprowadzanymi nową ustawą wymagałaby nowelizacji, tak aby zsynchronizować terminy wdrożeń związanych z wymogami silnego uwierzytelniania w stosunku do oferowanych usług COF, PIS i AIS.

Jedyne wyjaśnienie w odniesieniu do tematu, ustawodawca wskazał w uzasadnieniu do ustawy: "Dostawca, wykonując obowiązki, o których mowa w art. 32i stosuje właściwe w tym zakresie rozporządzenie Delegowane Komisji (UE) uzupełniające dyrektywę Parlamentu Europejskiego i Rady (UE) 2015/2366 w odniesieniu do regulacyjnych standardów technicznych dotyczących uwierzytelniania i komunikacji. Obowiązki określone w ww. rozporządzeniu dostawca jest obowiązany stosować nie później niż po upływie 18 miesięcy od dnia wejścia w życie tego rozporządzenia. Do czasu obowiązywania tego rozporządzenia, dostawcy prowadzący rachunki płatnicze są obowiązani stosować dotychczasowe regulacje w zakresie bezpieczeństwa płatności, w tym obowiązujące rekomendacje KNF."

Biorąc pod uwagę fakt, że bezpieczne udostępnienie usług COF, AIS i PIS wymaga silnego uwierzytelnienia, nie pozostaje de facto inne rozwiązanie interpretacyjne jak przyjęcie (i tym samym potwierdzenie Państwa stanowiska), że w związku z tym do 14 września 2019 r. lub do momentu wdrożenia silnego uwierzytelnienia przez bank i TPP (cokolwiek nastąpi wcześniej) Banki nie mogą udostępnić usług COF, AIS lub PIS.

Po dopełnieniu formalności (uzyskaniu zezwolenia KNF albo skorzystaniu z grandfatheringu na podstawie przepisów przejściowych) TPP mogą legalnie działać. Do rozważenia interpretacja, zgodnie z którą do września 2019 r. (albo wcześniejszego wdrożenia SCA i API) Bank nie ma podstaw dla bezpośredniego dopuszczania TPP do rachunku na zasadach wynikających z PSD2 / RTS. Nie wyklucza to jednak możliwości dopuszczenia na innych zasadach, zgodnych z dotychczasowymi regulacjami, np. poprzez pay-by-link czy po ustanowieniu przez klienta TPP jako pełnomocnika do rachunku (z zachowaniem wymaganej formy).

Biorąc jednak pod uwagę, że przepisy art. 59r. ust. 5 oraz art. 59s ust. 4 UUP nie zostały objęte dodatkowym okresem przejściowym (do września 2019 r.), za niedopuszczalne należałoby uznać wymuszanie przez bank na TPP zawierania jakichkolwiek umów w tym zakresie.

Przepis intertemporalny art. 115 ust. 4 PSD2 ma charakter lex specialis. Przepis ten wyznacza szczególną "datę stosowania" w zakresie środków bezpieczeństwa, o których mowa w art. 65 (CoF), 66 (PIS), 69 (AIS) i 97 (SCA). "Data stosowania" to wytyczna skierowana do państw członkowskich (adresatów normy), aby przepisy krajowe były tak skonstruowane, że data ich wejścia w życie/stosowania była określona na dany punkt w czasie (w przeciwieństwie od np. daty implementacji, która jest datą maksymalną/ nieprzekraczalną).

Do tej pory należy stosować obowiązujące przepisy w zakresie bezpieczeństwa (zob. art. 22 ust. 3 ustawy implementującej) oraz krajowe ramy regulacyjne określające zasady świadczenia usług przez dostawców COF, PISP i AISP (zob. art. 115 ust. 5 PSD2). Obecnie polskie prawo nie przewiduje ram regulacyjnych dla działalności dostawców trzecich.

Cel ww. regulacji był taki, aby w okresie przejściowym (przed RTS) państwa członkowskie nie wprowadzały zakazów (wbrew dotychczas istniejących u nich regulacjom), które ze względu na konieczność dostosowania do nowych zasad bezpieczeństwa, uniemożliwiałyby w tym okresie świadczenie usług przez TPP. Nie oznacza to jednak, że w państwach, których brakowało ram regulacyjnych dla TPP lub sektor zakładał niedopuszczalność takiej działalności, należy bezwzględnie umożliwić TPP prowadzenie działalności przed okresem przejściowym.

Względy celowościowe oraz funkcjonalne: trudno byłoby uznać za racjonalną wykładnię, w świetle której (1) do czasu wejścia w życie przepisów implementujących PSD2 zakazane byłoby ujawnianie przez klientów ich indywidualnych danych uwierzytelniających w celu świadczenia usług przez podmioty trzecie; (2) po wejściu w życie tych przepisów - świadczenie tego typu usług nie podlegałoby żadnym ograniczeniom, co realizowałoby cele dyrektywy, oraz (3) dopiero po upływie 18 miesięcy od wejścia w życie RTSów zasady dostępu TPP do rachunków musiałyby być zgodne ze standardami RTSów.