Source: https://finregtech.pl/2020/01/09/rodo-a-psd2-jakie-wyzwania-dla-third-party-providers-oraz-bankow-w-kontekscie-otwartej-bankowosci-cz-1-dostep-do-informacji-o-rachunku/
Timestamp: 2020-02-22 03:55:31
Legal References Found: art. 59
 art. 59
 art. 3
 art. 12
 art. 94
 art. 9
 art. 59
 art. 6
 art. 7
 art. 7

Document Content:
RODO a PSD2. Jakie wyzwania dla Third Party Providers oraz banków w kontekście otwartej bankowości? Cz. 1. Dostęp do informacji o rachunku - www.finregtech.pl
Przeglądasz:Strona główna»Regulacje»PSD2»RODO a PSD2. Jakie wyzwania dla Third Party Providers oraz banków w kontekście otwartej bankowości? Cz. 1. Dostęp do informacji o rachunku
Przez Michał Nowakowski	 9 stycznia 2020 Brak komentarzy
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ą efektywny przepływ informacji i zwiększą ich wartość analityczną. W jednym z raportów Banku Rozliczeń Międzynarodowych (pisałem o nim tutaj), że znalezienie równowagi pomiędzy regulacjami sektorowymi jak PSD2 a prawem ochrony danych osobowych będzie warunkiem sukcesu (lub porażki) Open Bankingu (o wyzwaniach w tym kontekście więcej w artykułach – klik1; klik2; klik3). W kolejnym artykule chciałbym przybliżyć nieco kwestię „wykorzystania” danych osobowych klientów w przypadku usługi dostępu do informacji o rachunku i inicjowania transakcji płatniczych. Zaczynamy!
A zaczniemy od możliwości wykorzystania danych „zbieranych” przez dostawcę usługi dostępu do rachunku (więcej na ten temat w tym artykule). 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.
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 (o czym za chwilę). 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 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 „RODOwskich” są dość restrykcyjny 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 – klik) 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ę.
Poprzedni artykułUKNF a fintechy w ramach Cyfrowej Agendy Nadzoru. Czy czeka nas rewolucja?
Następny artykuł Międzynarodowy Fundusz Walutowy o tworzeniu ekosystemu prawnego dla fintechów, czyli raport Institutional Arrangements for Fintech Regulation…