Kto ponosi ryzyko wypłaty środków z rachunku bankowego na rzecz osoby nieuprawnionej: klient, którego komputer został zainfekowany wirusem, wskutek czego z jego konta zniknęły pieniądze? Czy bank, którego system informatyczny jest nieodporny na ataki hakerów?
wyrok Sądu Apelacyjnego w Białymstoku z 14 czerwca 2023 r. (I AGa 36/22)
Ryzyko dokonania wypłaty z rachunku bankowego na rzecz osoby nieuprawnionej oraz dokonania rozliczenia pieniężnego na podstawie dyspozycji wydanej przez osobę nieuprawnioną, obciąża bank.
Sprawa zaczęła się od wyprowadzenia z konta bankowego spółki pieniędzy, a to poprzez dwa — potwierdzone eTokenem — przelewy. Zdaniem prezesa żadna z tych transakcji nie była przez niego autoryzowana, zatem zwrócił się do banku o zwrot środków utraconych w ataku hakerskim.
W ocenie banku do przejęcia danych dostępowych doszło wskutek nagannego i lekkomyślnego zaniedbania klienta (pewne niejasności dostrzegł sam bank i zadzwonił do klienta z informacją, spółka dopiero wówczas dostrzegła problem, złożyła reklamację i zawiadomiła policję; postępowanie umorzono ze względu na niewykrycie sprawców), zatem sprawa trafiła do sądu.
W toku postępowania ustalono, że przelewy zostały wykonane dzięki zainfekowaniu komputera klienta wirusami i przełamaniu indywidualnych zabezpieczeń instrumentu płatniczego. Feralne transakcje poszły tuż po operacjach prawidłowo potwierdzonych przez klienta, acz z innego adresu IP (bank zwrócił uwagę, że z tego samego adresu wyszedł jeszcze jeden przelew, którego spółka nie reklamowała). W opinii biegłego pojawiło się sformułowanie, iż system nie zareagował, ponieważ „z jego punktu widzenia ścieżka logowania w systemie jak i autoryzacja działań była poprawna” — aczkolwiek nieudane próby zalogowania się były zgłaszane bankowi, jednak bank nie zareagował na te problemy (jest więc „wysoce prawdopodobne, iż to zaniechanie pracownika banku umożliwiło transfer przestępczych poleceń przelewów”).
Odnosząc się do tych okoliczności sąd przypomniał, iż wskutek zawarcia umowy rachunku bankowego bank zobowiązuje się do przechowywania wpłaconych pieniędzy, nabywając ich własność (żeby mógł nimi obracać, musi być ich właścicielem), z obowiązkiem rozliczenia się na każde zlecenie klienta (ściśle: przysługuje mu wierzytelność o zwrot takiej samej kwoty). Stąd też ryzyko wypłaty z rachunku do rąk osoby nieuprawnionej obciąża bank, przeto jego powinnością jest dołożenie szczególnej staranności dla zapewnienia bezpieczeństwa przechowywanych pieniędzy
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ą
art. 43 ust. 1 pkt 1 uup
Dostawca wydający instrument płatniczy jest obowiązany do:
1) zapewnienia, że indywidualne dane uwierzytelniające nie są dostępne dla osób innych niż użytkownik uprawniony do korzystania z tego instrumentu,
art. 44 ust. 1-2 uup
1. Użytkownik niezwłocznie powiadamia dostawcę o stwierdzonych nieautoryzowanych, niewykonanych lub nienależycie wykonanych transakcjach płatniczych.
2. Jeżeli użytkownik nie dokona powiadomienia, o którym mowa w ust. 1, 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ą.
art. 46 ust. 1 uup
Z zastrzeżeniem art. 44 ust. 2, 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. W przypadku gdy płatnik korzysta z rachunku płatniczego, dostawca płatnika przywraca obciążony rachunek płatniczy do stanu, jaki istniałby, gdyby nie miała miejsca nieautoryzowana transakcja płatnicza. Data waluty w odniesieniu do uznania rachunku płatniczego płatnika nie może być późniejsza od daty obciążenia tą kwotą.
Sposobem zabezpieczenia transakcji płatniczej jest wymóg uzyskania prawidłowej autoryzacji, tj. potwierdzenia operacji zgodnej z wolą użytkownika. Konsekwencją wykonania nieautoryzowanej płatności jest obowiązek bezzwłocznego zwrotu pieniędzy klientowi (chyba że do transakcji doszło wskutek karygodnego zaniedbania w zapobieżeniu indywidualnych danych uwierzytelniających). Przyjmuje się przy tym, iż bank nie może zwolnić się z odpowiedzialności z powołaniem się na zachowanie szczególnej staranności.
Tymczasem zaistniałe fakty potwierdzają, że bank nie zapewnił prawidłowego bezpieczeństwa konta (nb. kilka tygodni przed atakiem bank wprowadził możliwość autoryzacji operacji esemesowymi kodami; sąd uznał, że jeśli zrobił tak dlatego, że uważał je za bezpieczniejsze, to powinien był zaproponować klientom przejście na taki sposób potwierdzania). Nie sposób przy tym ataku zarzucać, by klient przyczynił się do powstania szkody: raz, że w komputerze było zainstalowane oprogramowanie antywirusowe, zapora, etc., dwa, że brak bezzwłocznego zgłoszenia ataku hakerskiego nie miał na nic wpływu, ponieważ pieniędzy już nie było (a jeśli ta okoliczność była jakkolwiek istotna, to strona pozwana jej nie wykazała).
Stwierdzając, iż w przypadku wyprowadzenia pieniędzy przez hakera bank ponosi odpowiedzialność zarówno ex contractu, jak też ex delicto — ponieważ oznacza to zarówno niewywiązanie się z warunków zawartej umowy, jak też zawinione wyrządzenie szkody — sąd prawomocnie uwzględnił powództwo i zasądził zwrot dochodzonej kwoty.
Zamiast komentarza: troszkę szkoda, że w uzasadnieniu nie został rozwinięty wątek włamu i użycia eTokena przez hakera. Wszystko jednak wskazuje, że omawiany przypadek jest zupełnie inny niż te, które można skwitować „dałem się omotać, zatwierdziłem operację, chociaż powinienem był dostrzec, że nie wcale tego nie chciałem”.