RODO a PSD2 w praktyce świadczenia usług finansowych

Zacznijmy od tego, że podstawą do przetwarzania danych w ramach usług płatniczych jest co do zasady art. 6 ust. 1 lit. b) RODO, czyli niezbędność do wykonania umowy lub dokonania określonych działań przed zawarciem umowy.

Co do zasady, bo niekiedy zastosowanie będzie miała inna podstawa, choć najczęściej będzie odnosiła się do czynności wykonywanych przez dostawcę jako realizacja obowiązków ustawowych (np. art. 10 ustawy o usługach płatniczych – zapobieganie oszustwom płatniczym). To czy określone dane są niezbędne do wykonania usługi będzie determinowane charakterem usługi, ale również ustaleniami pomiędzy stronami w ramach umowy.

Zagadnienie to jest o tyle istotne, że może okazać się, iż określone dane wcale nie kwalifikują się jako niezbędne do wykonania usługi (pamiętając, że poruszamy w ograniczonym katalogu usług płatniczych, które mają swoją definicję i zakres).

W swoich wytycznych EDPB wskazuje, że to na dostawcy będzie ciążył obowiązek wykazania czy przetwarzanie określonych danych było rzeczywiście niezbędne do wykonania usługi, a samo – nawet wyraźne – wskazanie w umowie nie będzie tutaj wystarczające. Unijny nadzorca podkreśla jak ważne jest minimalizowanie kategorii danych, które są wykorzystywane przez dostawcę. Mniej znaczy więcej.

Czytaj także: PSD2 w praktyce ciągle budzi wiele wątpliwości, więc EBA odpowiada

I co więcej, EDPB wskazuje, że za niedozwoloną należy uznać praktykę, w której w umowie mamy wskazany najszerszy możliwy katalog przetwarzanych danych, natomiast możliwe jest jego zawężenie ze względu na możliwość skorzystania z części lub jednej z usług płatniczych przez użytkownika, a dostawca mimo to przetwarza inne (niepotrzebne dla tej usługi) dane.

Nie oznacza to jednak, że taki dostawca ma obowiązek w umowie określać, co dokładnie będzie wykorzystywane na potrzeby konkretnej usługi. Ważny będzie moment i fakt przetwarzania i na tym poziomie dokonujemy oceny pod kątem art. 6 ust. 1 lit b).

Czytaj także: EBA o przyznawaniu kredytów z udziałem robota, wykorzystującego ML

A co dalej? Czy możemy wykorzystywać „pierwotne” dane?

Możemy jako dostawca chcieć przetwarzać pozyskane w trakcie świadczenia usługi płatniczej dane dla innych celów, np. marketingowych czy analitycznych. Jest to zresztą jedna z większych korzyści, jakie miała potencjalnie stworzyć dyrektywa PSD2.

Furtkę do takiego przetwarzania w tym przypadku stanowi jednak nie PSD2, a art. 6 ust. 4 RODO. Przepis ten określa kiedy dopuszczalne będzie „skorzystanie” z zebranych danych, abstrahując w tej chwili od obowiązków, które mogą się pojawić w kontekście wybranych usług, np. do niezwłocznego usunięcia danych.

Taka możliwość pojawia się więc, o ile nie mamy zgody osoby, co załatwia nam sprawę (lub mamy odpowiedni przepis), o ile dostawca dokona pozytywnej oceny pięciu czynników wskazanych w powyższym przepisie.

Sytuacja taka może pojawić się przykładowo przy świadczeniu usługi inicjowania płatności (PIS) czy dostępu do informacji o rachunku (AIS) ‒ odpowiednio art. 59r i 59s uUP, ‒ które mają „zaszyty” zakaz przetwarzania i przechowywania danych dla innych celów niż świadczenie danej usługi.

Czyli jeżeli nie mamy zgody użytkownika (wyraźnej i wykraczającej poza zgodę w ramach PSD2), to nie wykorzystamy tych danych np. do celów analitycznych. Kropka.

EDPB wskazuje tutaj dodatkowo, że art. 6 ust. 4 nie znajduje tutaj zastosowania, więc zgoda pod RODO, abstrahując od przepisu w prawie krajowym, jest jedynym „remedium” na ten problem, ze wszystkimi tego konsekwencjami. Chyba, że mówimy o wspomnianym już przeze mnie obowiązku ustawowym, ale to zupełnie inna bajka.

Czytaj także: Czy w Polsce klienci będą zarządzać swoimi danymi tworzonymi i pozyskiwanymi na potrzeby usług finansowych?

Ważna informacja dla banków

Choć chyba raczej oczywista. Możliwość przetwarzania danych użytkownika usług PIS i AIS na podstawie żądania dokonanego przez dostawcę tych usług wynika wprost z samej konstrukcji tych usług (art. 6 ust. 1 lit c RODO).

Bank powinien więc nie tylko je przetworzyć, ale także przekazać dostawcy. Nie będzie stanowiło to naruszenia tajemnicy bankowej/zawodowej, co w naszym – krajowym – przypadku wynika wprost z art. 105 ust. 1 pkt 1g-1i PrBank oraz 12 pkt 5) i 6) uUP.

Problematyka wyraźnej zgody

Skoro już ustaliliśmy, że do przetwarzania danych potrzebujemy wyraźnej zgody (freely given, specific, informed and unambiguous), to zastanówmy się jakie wyzwania nas jeszcze czekają, bo ocena i stworzenie warunków dla jej wyrażenia to oczywiście obowiązek dostawcy.

Brak jakiegokolwiek z elementów wskazanych powyżej powoduje, że może nam odpaść podstawa do przetwarzania danych. Stworzenie „zgody” (oświadczenia) użytkownika wymaga więc bardzo dokładnej analizy, w tym również UX-owej. Musimy też zapewnić wszelkie prawa związane z tą zgodą, a więc przykładowo umożliwić jej swobodne wycofanie, np. poprzez stosowny thickbox.

Czytaj także: Czy Rozporządzenie RODO uzasadnia zgodne z prawem wykorzystanie sztucznej inteligencji?

Ciekawe jest stwierdzenie EDPB, że „[a] controller must also beware that consent cannot be obtained through the same motion as agreeing to a contract or accepting general terms and conditions of a service”. Czyli zgodę odbieramy każdorazowo przy realizacji danej usługi i nie może ona mieć charakteru generalnego i abstrakcyjnego. A co z pełnomocnictwami?

I zgody pod PSD2

EDPB wyraźnie wyróżnia dwie zgody, tj. RODO-wską oraz tę pod PSD2. Zdaniem nadzorcy zgoda, o której mowa w art. 94 ust. 2 PSD2, to ogólna podstawa do przetwarzania danych przez dostawcę na potrzeby świadczenia usługi.

Innymi słowy, dostawca zamierzający wykonać usługę na rzecz użytkownika, która zawiera w sobie element wykraczający poza realizację tej usługi musi uzyskać dwie zgody.