Czy klient bankowości elektronicznej powinien choć trochę znać się na bezpieczeństwie systemów teleinformatycznych, czy jednak wystarczy, że umie znaleźć „zieloną kłódeczkę” i „https”? Czy bank może od niego wymagać wiedzy o potencjalnych ryzykach — jeśli mu tej wiedzy w żaden sposób nie przekazuje? Czy przelew potwierdzony wyłudzonym przez hakera kodem ze zdrapki jest operacją autoryzowaną przez klienta? Jak wygląda odpowiedzialność banku za nieautoryzowaną transakcję płatniczą? (wyrok Sądu Apelacyjnego w Białymstoku z 3 października 2019 r., I ACa 228/19).
Zaczęło się od podpisanej przez małżeństwo w 2014 r. umowy o prowadzenie rachunku bankowego; klienci jako sposób autoryzacji transakcji wybrali „zdrapki”. Przy otwieraniu konta udzielono im wyjaśnień dotyczących korzystania z systemu bankowości elektronicznej, ale dostali szczegółowych informacji odnośnie jego bezpieczeństwa (np. zabezpieczenia sprzętu i potencjalnych niebezpieczeństw wynikających z ataków hakerskich). Klienci wiedzieli, że muszą zwracać uwagę na „zieloną kłódkę” i prefiks https, które oznaczają, że połączenie jest szyfrowane, a więc można bezpiecznie korzystać z usług banku (zwłaszcza, że do wszystkiego używał własnego komputera).
art. 40 ust. 1 ustawy o usługach płatniczych
Transakcję płatniczą uważa się za autoryzowaną, jeżeli płatnik wyraził zgodę na wykonanie transakcji płatniczej w sposób przewidziany w umowie między płatnikiem a jego dostawcą. Zgoda może dotyczyć także kolejnych transakcji płatniczych.
Pewnego dnia mężczyzna otrzymał od kuriera listela z informacją o otrzymaniu paczki; ponieważ nie oczekiwał na taką przesyłkę, uznał, że to zwykła pomyłka i wiadomość zignorował.
Po pewnym czasie mężczyzna zalogował się do banku, sprawdził czy połączenie jest bezpieczne („zielona kłódka” + SSL), ale po kilku chwilach korzystania wyświetlił mu się komunikat, że ze względu na „przebudowę” strony musi podać określony kod ze zdrapki. Komunikatu nie dało się zamknąć, więc klient przepisał cyferki; teraz strona się zawiesiła i pojawił się komunikat, że o czasowym braku dostępu do serwisu.
art. 42 ust. 1 ustawy o usługach płatniczych
Użytkownik uprawniony do korzystania z instrumentu płatniczego jest obowiązany:
1) korzystać z instrumentu płatniczego zgodnie z umową ramową oraz
2) zgłaszać niezwłocznie dostawcy lub podmiotowi wskazanemu przez dostawcę stwierdzenie utraty, kradzieży, przywłaszczenia albo nieuprawnionego użycia instrumentu płatniczego lub nieuprawnionego dostępu do tego instrumentu.
W ciągu kolejnych 3 dni przestępcom udało się wytransferować z rachunku 112 tys. złotych (w trzech przelewach; natomiast bank wykrył i zablokował próby wykonania szybkich przelewów). Przez cały ten czas klient nie logował się do banku i nie miał przy sobie komórki, który kilka dni wcześniej posiał w aucie szwagra. Rozładowany telefon odzyskał dopiero dwa dni później (po włączeniu nie sygnalizował jakichkolwiek nieudanych prób połączenia). Tego samego dnia zadzwonił pracownik banku celem „potwierdzenia (autoryzowania) — choć tak naprawdę w celu weryfikacji” przelewów na znaczne kwoty; mężczyzna odmówił potwierdzenia transakcji, ale w rozmowie przyznał, że otrzymał dziwnego listela dotyczącego paczki, której nie zamawiał i poprosił o zablokowanie konta. Pracownik banku zasugerował, że przydałoby się sformatować dysk komputera i przeinstalować system, ale nie poinformował go o wyprowadzeniu pieniędzy, więc klient uznał, że była to informacja o nieudanej próbie włamania na konto, zatem jego zablokowanie będzie wystarczającym zabezpieczeniem pieniędzy — i nie sprawdził stanu środków. Dzień później poszedł do serwisu komputerowego, gdzie (zgodnie z sugestią banku) przeinstalowano mu system (w uzasadnieniu podkreśla się, iż w ten sposób uległo zatarciu szereg kluczowych informacji, w tym dotyczących używanego systemu operacyjnego, oprogramowania antywirusowego, etc.).
Tego samego dnia bank złożył zawiadomienie o podejrzeniu popełnienia przestępstwa, w jego treści zasugerował, że do nieuprawnionych transakcji doszło wskutek zainfekowania komputera klienta; do tego czasu pieniądze zostały już przelane na inne rachunki, jednak kwotę 14,9 tys. złotych udało się zablokować (art. 106a ust. 3-4 pr.bank.).
Dopiero po kolejnych kilku dniach żona poszła do banku celem odblokowania rachunku, jednak okazało się że pomimo dyspozycji telefonicznej dostęp nie został zablokowany — no i że pieniądze już dawno opuściły ich konto. Po tym jak bank nie uwzględnił reklamacji sprawa o zwrot wyprowadzonych pieniędzy trafiła do sądu.
art. 45 ust. 1 i 2 ustawy o usługach płatniczych
1. Na dostawcy użytkownika spoczywa ciężar udowodnienia, że transakcja płatnicza została autoryzowana i prawidłowo zapisana w systemie służącym do obsługi transakcji płatniczych dostawcy oraz że nie miała na nią wpływu awaria techniczna ani innego rodzaju usterka związana z usługą płatniczą świadczoną przez tego dostawcę, w tym dostawcę świadczącego usługę inicjowania transakcji płatniczej.
2. Wykazanie przez dostawcę zarejestrowanego użycia instrumentu płatniczego nie jest wystarczające do udowodnienia, że transakcja płatnicza została przez użytkownika autoryzowana albo że płatnik umyślnie albo wskutek rażącego niedbalstwa doprowadził do nieautoryzowanej transakcji płatniczej albo umyślnie albo wskutek rażącego niedbalstwa dopuścił się naruszenia co najmniej jednego z obowiązków, o których mowa w art. 42. Ciężar udowodnienia tych okoliczności spoczywa na dostawcy.
Sąd prawomocnie uwzględnił całość roszczeń: dostawca usług płatniczych (bank) ma prawo wykonać transakcję tylko w przypadku jej prawidłowej autoryzacji przez płatnika (klienta), przy czym operację uważa się za autoryzowaną jeśli klient wyraził zgodę na jej wykonanie w sposób przewidziany w umowie — zaś ciężar dowodu, iż operacja została prawidłowo autoryzowana (a także, że nie była efektem awarii czy usterki) obciąża bank. W przeciwnym razie bank ponosi odpowiedzialność za nieautoryzowaną transakcję płatniczą — nieautoryzowaną, bo niepotwierdzoną przez posiadacza rachunku.
W sprawie nie ma wątpliwości, że klienci nie autoryzowali zakwestionowanych operacji. Wątpliwości tych nie ma nawet bank — bo złożył zawiadomienie o popełnionym przez hakerów przestępstwie. Użycie wyłudzonego od klienta kodu nie oznacza, że doszło do autoryzacji transakcji w rozumieniu przepisów o usługach płatniczych, zaś pozwany bank nie udowodnił także, iżby do operacji doszło z winy klientów (wskutek umyślnego lub wynikającego z rażącego niedbalstwa naruszenia obowiązków — zaś przeprowadzenie dowodu dotyczącego zabezpieczenia komputera było niemożliwe, bo przecież klient przeinstalował system…
Sąd podkreślił, iż rażącym niedbalstwem ze strony posiadacza konta (art. 42 uup) nie jest brak informacji o niestandardowym działaniu serwisu transakcyjnego. Klient bankowości elektronicznej nie musi się domyślać, że zawieszenie się strony internetowej oznacza atak hakerski (wszakże cały czas była „zielona kłódeczka” i „https”), a bank nie może wymagać od klienta wiedzy o tego rodzaju zagrożeniach, skoro użytkownikom podawał tylko podstawowe informacje dotyczące bezpieczeństwa i uczulał na ataki z użyciem wyłudzonych kodów. Owszem, istotne jest to czy klient stosował prawidłowe zabezpieczenia komputera — ale skoro bank podpowiedział, iż należy sformatować dysk i postawić cały system od nowa, a klient to zrobił, to jakikolwiek dowód jest niemożliwy do przeprowadzenia, czego skutki obciążają bank.
W konsekwencji w sprawie przyjąć należy odpowiedzialność banku za nieautoryzowaną transakcję płatniczą — nieautoryzowaną, bo niepotwierdzoną przez klienta — co oznacza, że bank ma obowiązek zwrócić klientowi całą kwotę wyprowadzoną z rachunku (art. 46 ust. 1 uup).