Zderzenie RODO i PSD2 w projekcie wytycznych EDPB
Wczoraj Europejska Rada Ochrony Danych (EDPB) opublikowała bardzo ważny dokument (projekt) Guidelines 06/2020 on the interplay of the Second Payment Services Directive and the GDPRWczoraj Europejska Rada Ochrony Danych (EDPB) opublikowała bardzo ważny dokument Guidelines 06/2020 on the interplay of the Second Payment Services Directive and the GDPR, który porusza wiele ciekawych wątków dotyczących zależności (lub ich braku) pomiędzy pakietem PSD2 a Rozporządzeniem 2016/679 (RODO). O niektórych z tych zagadnień pisałem tutaj i tutaj przy okazji omawiania usługi dostępu do informacji o rachunku, a część dotyczy niezwykle istotnych problemów praktycznych jak przetwarzanie danych przez tzw. silent parties. Dokument sam w sobie nie jest obszerny, ale analizę podzielę na części. Obecnie trwają konsultacje publiczne. Zaczynamy!
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 b) 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ę 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 tutaj jak ważne jest minimalizowanie kategorii danych, które są wykorzystywane przez dostawcę. Mniej znaczy więcej.
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).
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.
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).
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. RODOwską oraz tą pod PSD2. Zdaniem nadzorcy zgoda, o której mowa w art. 94 ust. 2 PSD2, czyli ogólna podstawa do przetwarzania danych przez dostawcę n 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.
Co w kolejnym „odcinku”?
Zajmiemy się silent parties i pozostałymi zagadnieniami podniesionymi przez EDPB, ale to już w przyszłym tygodniu.