RODO a PSD2. Wyzwania dla TPP oraz banków w kontekście otwartej bankowości

Bezpieczne Finanse / Bezpieczny Klient / Komentarze ekspertów

Ochrona danych
Fot. Stock.Adobe.com / Sergey Nivens

Prawdziwe otwarcie bankowości nastąpi jedynie wtedy, gdy będziemy mieli bezpieczny, ale i efektywny dostęp do danych. To zaś wymaga tworzenia międzysektorowych regulacji, które zapewnią przepływ informacji i zwiększą ich wartość analityczną.

#MichałNowakowski: W tej chwili mamy pewien zgrzyt pomiędzy rozwiązaniami user-friendly, a pełną – zdaniem prawodawców i regulatorów – przejrzystością i bezpieczeństwem #RODO #PSD2 #OchronaDanych #TPP #OpenBanking @FinregtechPL

W jednym z raportów Banku Rozliczeń Międzynarodowych stwierdzono, że znalezienie równowagi pomiędzy regulacjami sektorowymi jak PSD2 − a prawem ochrony danych osobowych będzie warunkiem sukcesu (lub porażki) Open Bankingu. Chciałbym więc przybliżyć nieco kwestię „wykorzystania” danych osobowych klientów w przypadku usługi dostępu do informacji o rachunku i inicjowania transakcji płatniczych.

Zacznę od możliwości wykorzystania danych zbieranych przez dostawcę usługi dostępu do rachunku. Chciałbym jeszcze w tym miejscu podkreślić, że sam artykuł traktuję jako wstęp do dyskusji nad tym zagadnieniem, które nie jest przecież łatwe, a zarazem istotne dla całego sektora.

Punkt wyjścia

Patrząc przez pryzmat art. 59s ust. 1 pkt 4 ustawy o usługach płatniczych dostawca usługi dostępu do informacji o rachunku (AISP) może uzyskać dostęp wyłącznie do informacji dotyczących wyznaczonych rachunków płatniczych i związany z nimi transakcji płatniczych.

Dodatkowo mamy pkt 5, który stanowi, że AISP nie może żądać szczególnie chronionych danych dotyczących płatności powiązanych z rachunkami płatniczymi – zakres tych danych określa pkt 26c) słowniczka do uUP, czyli de facto indywidualne dane uwierzytelniające. Mamy więc zakres „dozwolonych” danych.

Z kolei art. 59 ust. 1 pkt 6 wskazuje, że AISP nie może używać, uzyskiwać ani przechowywać danych do celów innych niż wykonanie usługi na podstawie:

− umowy z użytkownikiem lub

− zgody użytkownika.

Sugerowałoby to, że nie jest możliwe wykorzystanie (przetworzenie, udostępnienie) danych pozyskanych w ramach realizacji usługi AIS do innych – np. analitycznych – celów i w tym miejscu w zasadzie można byłoby zakończyć analizę.

Jeżeli jednak zagłębimy się w szczegóły…

…to możemy dojść do nieco odmiennych wniosków

Umowa może bowiem zawierać dodatkowe postanowienia, które upoważniają do przetworzenia pozyskanych danych dla innych celów niż wykonanie usługi AIS. Warto jednak zastanowić się, jaki „cel” ma usługa AIS?

Patrząc przez pryzmat definicji z art. 3 ust. 6 uUP − to usługa, polegająca na dostarczaniu skonsolidowanych informacji o rachunkach. Czy więc przetworzenie tych danych i pokazanie bardziej zindywidualizowanych informacji będzie jeszcze realizacją tej usługi, czy też będzie już wykraczała poza ramy prawne?

Wydaje się, że przyjęcie bardziej restrykcyjnego podejścia byłoby tutaj niezgodne z założeniami samej usługi (samą konsolidację informacji raczej trudno też „zmonetyzować”), a także „duchem” Rozporządzenia 2016/679.

Wracając jednak do meritum. Umowa może przewidywać, że AISP po „pokazaniu” ich użytkownikowi będzie z nich korzystał, np. w celach analitycznych.

Jeżeli będzie je przekazywał dalej, to mamy dodatkowe wymagania typowo „RODOwskie” oraz art. 12 ust. 1 pkt 4 umożliwiający przekazanie danych innemu podmiotowi za zgodą użytkownika.

Nie jest to już więc przetwarzanie na potrzeby świadczenia konkretnej usługi, przynajmniej w rozumieniu uUP, bo przecież może to być część „jakiejś” usługi o charakterze płatniczym.

I tutaj dochodzimy do dwóch kwestii:

    czy rzeczywiście można wykorzystać takie dane do innych celów

oraz

    w jakim „reżimie” prawnym musimy się poruszać (RODO versus PSD2)?

Na ratunek art. 94 ust. 2 PSD2?

Wyżej wskazany przepis, o ile mi wiadomo, nie został przeniesiony na grunt uUP w podobnej formie. Przepis ten brzmi następująco:

„Dostawcy usług płatniczych uzyskują dostęp jedynie do danych osobowych niezbędnych do świadczenia swoich usług płatniczych, przetwarzają te dane i zatrzymują je za wyraźną zgodą użytkownika usług płatniczych”.

Umożliwiałby on tym samym przetwarzanie pobranych danych do celów innych niż usługa AIS pod warunkiem uzyskania wyraźnej zgody użytkownika.

Problemem, na który można tutaj natrafić jest kwestia oceny − czym jest ta wyraźna zgoda, bo chyba nie do końca chodzi o „wyraźną zgodę” z art. 9 ust. 2 lit a Rozporządzenia 2016/679 (zgoda dla danych szczególnie chronionych).

Wydaje się jednak, że po prostu chodzi o wyróżnienie dwóch rodzajów zgód, których musi udzielić użytkownik usługi AIS – jednej na realizację tej usługi i drugiej na udostępnienie i przetwarzanie zebranych danych „poza AIS”.

Posiłkować się możemy tutaj także art. 59s ust. 1 pkt 1, który wskazuje, że zgoda na realizację usługi AIS musi być świadczona wyłącznie na podstawie zgody użytkownika wyrażonej w sposób niebudzący wątpliwości.

A jeżeli nie mamy transpozycji?

Możemy przyjąć, że podobne zasady zastosujemy w przypadku konstrukcji umownej zakładającej wykorzystanie tych danych. W takim wypadku wydaje się jednak, że zgoda na udostępnienie i przetwarzanie danych odbywałaby się na podstawie art. 6 ust. 1 lit. a Rozporządzenia 2016/679 (a może i lit. b?).

W takim wypadku, w kontekście wyrażanej zgody, mamy warunki z art. 7 powyższego Rozporządzenia, co z resztą znacznie komplikuje sprawę.

Komplikuje, bo wymogi w zakresie uzyskiwania zgód „RODO-wskich” są dość restrykcyjne i niezbyt user-friendly. W samej treści powinniśmy wyraźnie określić cel przetwarzania (co należy skorelować z zakresem umowy zawieranej z użytkownikiem).

W praktyce więc, w przypadku świadczenia usługi AIS, przy okienku z udzielaniem zgody powinniśmy mieć dwa thickbox’y:

− zgoda na realizację usługi; ta nie może budzić wątpliwości i ciężar udowodnienia, że użytkownik o niej wiedział będzie ciążyć na dostawcy; warto zwrócić uwagę na opinię EBA w sprawie „przyszłości” usług bankowych online) oraz

− zgoda na „inne” przetwarzanie danych; tutaj z zachowaniem zasad określonych w art. 7 Rozporządzenia 2016/679.

Nie jest więc tak źle

Więc można. Nie znaczy to jednak, że jest to rozwiązanie bezsporne i efektywne. Od jakiegoś czasu toczy się dyskusja nad „lepszym” ukształtowaniu przepisów, które bardziej „otworzą” bankowość.

W tej chwili mamy pewien „zgrzyt” pomiędzy rozwiązaniami user-friendly a pełną – zdaniem prawodawców i regulatorów – przejrzystością i bezpieczeństwem. Wiele zależy więc od tego czy uda się osiągnąć niezbędną równowagę.

Michał Nowakowski, https://pl.linkedin.com/in/michal-nowakowski-phd-35930315, Counsel w Citi Handlowy, założyciel www.finregtech.pl

Opinie wyrażone w artykule są osobistymi opiniami Autora i nie mogą być utożsamiane z jakąkolwiek instytucją, z którą Autor jest lub był związany.

Źródło: FinregtechPl
Udostępnij artykuł: