Source: https://finregtech.pl/2019/10/01/odmowa-dostepu-do-rachunku-dla-uslugodawcow-pis-lub-ais-przez-bank-kiedy-i-na-jakich-zasadach/
Timestamp: 2019-10-18 10:08:59
Legal References Found: art. 41
 art. 35
 art. 46
 art. 41
 Art. 30
 art. 33
 art. 30
 art. 33
 art. 41
 art. 32
 art. 41
 art. 41
 art. 46
 art. 41
 art. 41

Document Content:
Odmowa dostępu do rachunku dla usługodawców PIS lub AIS przez bank. Kiedy i na jakich zasadach? - www.finregtech.pl
Przeglądasz:Strona główna»Regulacje»PSD2»Odmowa dostępu do rachunku dla usługodawców PIS lub AIS przez bank. Kiedy i na jakich zasadach?
Przez Michał Nowakowski	 1 października 2019 Brak komentarzy
Rozwój Open Bankingu związany ze wdrożeniem pakietu PSD2 to z pewnością szansa na zwiększenie dostępności usług finansowych (financial inclusion) a zarazem potencjalnie ryzyko dla wrażliwych danych klientów oraz ich środków (i związanych z nimi oszustw). Na arenę finansową wchodzą coraz to nowe podmioty, który swój „rodowód” mają w technologii, które dopiero „później” skupiają się na świadczeniu usług finansowych, takich jak inicjowanie płatności (więcej na temat usługi w tym artykule) czy agregacja informacji o rachunku (więcej tutaj). Zanim jednak będą one mogły świadczyć usługi płatnicze czeka je długa ścieżka z uzyskiwaniem zezwolenia lub rejestracji i spełnienie szeregu wymogów, m.in. w zakresie bezpieczeństwa. Posiadanie stosownej licencji, co do zasady, powinno umożliwić nieskrępowane korzystanie z interfejsów bankowych, jednakże są też sytuacje, w których bank może odmówić takiego dostępu. Kiedy i na jakich zasadach może się to wydarzyć?
Generalnie kwestię odmowy dostępu do indywidualnego rachunku reguluje art. 41 ust. 5-7 ustawy o usługach płatniczych (uUP), choć nie należy zapominać o przepisach Rozporządzenia 2018/389 (m.in. art. 35 i 36) oraz art. 46 ust. uUP.
Przesądza o tym art. 41 ust. 5, który umożliwia banki dokonania odmowy dostępu do danego rachunku z obiektywnie uzasadnionych i należycie udokumentowanych przyczyn związanych z nieuprawnionym lub nielegalnym dostępem do rachunku, co obejmuje również nieuprawnione zainicjowanie transakcji. Przesłanki są więc mocno ocenne i dlatego wymagają oceny indywidualnego przypadku. Tym bardziej że, co jest również bardzo istotne z punktu widzenia odpowiedzialności banku, taka odmowa musi dotyczyć konkretnego rachunku, a nie odmowy dostępu do całego interfejsu bankowego (co swoją drogą może być dużym wyzwaniem dla banku – o czym w dalszej części).
No właśnie. Art. 30 ust. 6 Rozporządzenia 2018/389 nakazuje, aby organy nadzoru zapewniały, że banki (lub inni dostawcy rachunków płatniczych) stale przestrzegali obowiązków wynikających z Rozporządzenia w zakresie stosowanych interfejsów API (klientowskich oraz specjalnych). Rozciąga się to na zakaz stwarzania przeszkód i zakłóceń w działaniu interfejsów, co mogłoby uniemożliwić świadczenie usługi PIS lub AIS.
Jest jednak wyjątek. Jeżeli dostawca usługi PIS lub AIS nie spełnia warunków z art. 33 ust. 5 Rozporządzenia 2018/389 (przepis odnosi się nota bene do stosowania środków awaryjnych – więcej w tym artykule), to teoretycznie możliwe jest „odłączenie” ich od interfejsu. Pojawia się jednak pytanie jak odczytywać art. 30 ust. 6 oraz art. 33 ust. 5. Patrząc przez literalną wykładnię (wobec braku „odpowiedniego stosowania”) takie „wyjęcie wtyczki” mogłoby mieć miejsce jedynie w przypadku wystawienia przez bank interfejsu awaryjnego (na co wskazuje użycie sformułowania „w celu”) i braku spełnienia przesłanek w zakresie bezpieczeństwa danych (co mogłoby być zweryfikowane dopiero na etapie korzystania przez TPP z tego interfejsu).
Takie rozwiązanie wydaje się jednak nielogiczne. Co w przypadku, gdy bank powziął informację o cofnięciu zezwolenia danemu TPP (sprawdzając np. w rejestrze organu nadzoru), natomiast certyfikat eIDAS służący do identyfikacji nadal jest ważny (niezaktualizowany)? Na takie przypadki wskazywała już wcześniej grupa robocza ds. API przy Europejskim Urzędzie Nadzoru Bankowego (EBA). Czy w takiej sytuacji bank mógłby odmówić w ogóle dostępu TPP do swojego interfejsu czy też musiałby powoływać się na art. 41 ust 5 uUP, czyli każdorazowo odmawiać wykonania pojedynczych żądań (co może być trudne ze względu na automatyzm i bardzo krótki czas odpowiedzi na żądania liczony w ms)?
A mamy jeszcze art. 32 ust. 3 Rozporządzenia 2018/389, który zabrania stwarzania przeszkód dla TPP w przypadku wprowadzenia specjalnego interfejsu dostępowego. Takie przeszkody to przykładowo wymaganie dodatkowej weryfikacji zgody czy uzyskania dodatkowych zezwoleń lub rejestracji. Czy odmowa dostępu w przypadku, gdy TPP ma poprawny certyfikat eIDAS byłaby w tym przypadku przeszkodą?
Wróćmy do przesłanek z art. 41 ust. 5
Nie rozstrzygając tego zagadnienia, bo wydaje się, że praktyka zweryfikuje „jakość” przepisów (a może i moją interpretację, która może być przecież błędna), przejdźmy na grunt art. 41 ust. 5. Jak wspomniałem powyżej odmowa dostępu do rachunku może nastąpić jedynie z obiektywnych przyczyn. Pomocne w tym przypadku może być takie rozumienie „obiektywizmu” jakie wykorzystuje się w przypadku art. 46 ust. 1 uUP – czyli odmowy refundacji kwoty nieautoryzowanej transakcji, jeżeli bank podejrzewa oszustwo.
Nie wchodząc w rozważania filozoficzno-doktrynalne można stwierdzić, że obiektywną (i należycie udokumentowaną) przyczyną będzie np. stwierdzenie cofnięcia zezwolenia/rejestracji TPP (na podstawie ww. danych z rejestru organu nadzoru), brak zgodności certyfikatu eIDAS czy też przekroczenie limitu żądań dostępu (bez zgody użytkownika) do informacji o rachunku (art. 36 ust. 5 lit b) Rozporządzenia 2018/389). Można również wskazać na wejście w posiadanie przez TPP danych uwierzytelniających klienta w sposób nieuprawniony, np. wobec wycieku danych czy użycia malware. Każdą przyczynę takiej odmowy należy jednak „zważyć” i udokumentować, aby uniknąć ewentualnej odpowiedzialności z tytułu niewykonania usługi (m.in. odpowiedzialność odszkodowawcza).
Warto jeszcze zwrócić uwagę na jedną kwestię. Odmowa nie może wynikać z przyczyn leżących po stronie banku, np. technologicznych (co wynika wprost z treści samego przepisu – mówimy tutaj o nieuprawnionym lub nielegalnym dostępie TPP). Z drugiej strony, jeżeli na przeszkodzie stoi przyczyna technologiczna, która mogłaby doprowadzić do „nieuprawnionego” dostępu, to teoretycznie mogłoby to być możliwe.
Po pierwsze należy poinformować użytkownika (w sposób określony w umowie lub regulaminie). Taka informacja powinna zostać przekazana (najlepiej) przed odmowa dostępu (mało prawdopodobne), a najpóźniej bezzwłocznie po takiej odmowie i nie później niż w dniu roboczym następującym po odmowie.
Jest możliwe „wstrzymanie” się z przekazaniem takiej informacji, jeżeli jest to wskazane z obiektywnie uzasadnionych względów bezpieczeństwa lub jest sprzeczne z odrębnymi przepisami. Przykładem może być podejrzenie oszustwa, które wymaga złożenia zawiadomienia do właściwych organów.
Kolejnym (lub równoległym) krokiem jest przekazanie do KNF informacji o takim incydencie. W zgłoszeniu należy przekazać wszystkie istotne okoliczności zdarzenia oraz opis i przyczyn podjętych działań wraz z uzasadnieniem. W praktyce należy wykazać, że spełnione zostały przesłanki z art. 41 ust. 5 uUP.
Jeżeli przyczyna ustała, to bank powinien niezwłocznie umożliwić TPP dostęp do rachunku. W takiej sytuacji, choć nie wynika to wprost z przepisów uUP zasadnym byłoby poinformowanie TPP o przyczynie odmowy.
Ponieważ KNF otrzymuje informacje odnośnie incydentu, to może również stwierdzić, że odmowa była niezgodna z przesłankami art. 41 ust. 5. W takiej sytuacji może wydać decyzję o nakazaniu bankowi udostępnienie rachunku. Taki dostęp powinien zostać przyznany bez zbędnej zwłoki.
Poprzedni artykułUsługa inicjowania płatności, czyli Payment Initation Service – czym jest i jakie wymogi prawne ciążą na dostawcy? Część 1. Ustawa.
Następny artykuł Utworzenie odpowiedniego środowiska prawnego dla sztucznej inteligencji jako priorytet. Komisja Europejska oraz unijni nadzorcy wytyczają priorytety dla AI. Część 1.
Usługa inicjowania płatności, czyli Payment Initation Service – czym jest i jakie wymogi prawne ciążą na dostawcy? Część 1. Ustawa.