czwartek, Październik 1

PSD2 vs RODO: minimalizacja danych, rozliczalność oraz bezpieczeństwo w projektowanych wytycznych EDPB

Google+ Pinterest LinkedIn Tumblr +

W ostatnich dwóch artykułach poruszyliśmy wiele istotnych wątków dotyczących istotnych zależności pomiędzy PSD2 a RODO wyrażonych w projektowanych wytycznych EDPB (klik1klik2). Dzisiaj, zgodnie z obietnicą, przejdziemy przez ostatnie zagadnienia tam wskazane, w tym dotyczące przejrzystości, bezpieczeństwa czy rozliczalności. Zakończymy nimi analizę projektu i nie pozostaje nic innego jak czekać na ich ostatni kształt, choć nie można zapominać, że być może Europejski Urząd Nadzoru Bankowego „dorzuci” swoje pięć groszy do tej debaty w związku z projektem Digital Finance Strategy opracowywanej przez Komisję (UE). Nie przedłużając. Zaczynamy!

Dzisiaj zaczniemy od art. 5 ust. 1 lit. c) Rozporządzenia 2016/679 (RODO), który wyznacza nam zasadę tzw. minimalizacji danych, czyli zapewnienia, że przetwarzane dane są adekwatne, stosowne oraz ograniczone do tego, co niezbędne do celów, których są przetwarzane. W tym miejscu EDPB podkreśla raz jeszcze, że to jakie dane będą przetwarzane przez dostawcę usług płatniczych wyznacza przede wszystkim cel danej usługi, jak i (wspólnie) uzgodniony cel zawarty w umowie.

W konsekwencji, projektując i wdrażając określone rozwiązania, które związane są z przetwarzaniem danych osobowych, musimy zawsze uwzględniać również zasadę minimalizacji danych (i to na każdym etapie). Taki obowiązek wyznacza nam art. 25 RODO (data protection by design and default). Wszystko oczywiście z zachowaniem zasad zdrowego rozsądku (proporcjonalności).

Jak zasadę minimalizacji danych widzi EDPB?

No alt text provided for this image

Przede wszystkim nie tylko bank, ale również Third-Party Provider (TPP) musi stosować się do tej zasady. Jeżeli więc określone dane nie są niezbędne do świadczenia danej usługi, to powinny one zostać „wyłączone” z usługi. EDPB wskazuje tutaj chociażby na dane identyfikujące tzw. Silent parties, o których pisałem w ostatnim artykule, ale także “transaction characteristics” (?). Konia z rzędem temu, kto dokładnie wie jakie dane mogą być „niepotrzebne” do realizacji takiej usługi, tym bardziej, że zakres danych „wchodzących” w skład usługi Account Information Service (AIS) nie jest zbyt precyzyjnie określony (art. 36 ust. 1 lit a) Rozporządzenia 2018/389).

W konsekwencji, EDPB sugeruje tutaj zastosowanie takich rozwiązań technicznych, które będą umożliwiać lub wspierać TPP w zakresie uzyskania dostępu tylko do tych niezbędnych danych. Jakie mogą to być rozwiązania? Odpowiednia polityka ochrony danych czy cyfrowe filtry pozwalające na “odsianie” niepotrzebnych danych. Tutaj od razu przychodzi mi na myśl konieczność przebudowania API udostępnianych przez banki. Ciekawie. O kosztach wdrożenia takiego rozwiązania niestety ani słowa 

Dalej EDPB przypomina, że banki mogą udostępniać jedynie te informacje, które dotyczą rachunku płatniczego i nie ma możliwości (podstawy prawnej), aby udostępniać informacje dotyczące innych rachunków, np. oszczędnościowych, kredytowych czy inwestycyjnych. Musimy więc również tutaj zastosować odpowiednie rozwiązania techniczne. EDPB przypomina także, że dane powinny być przechowywane jedynie przez czas określony przez użytkownika (w uproszczeniu).

Dodatkowo, jeżeli umowa pomiędzy AISP a użytkownikiem zakłada przekazywanie danych osobowych do stron trzecich, to tylko te dane, które są niezbędne do wykonania umowy mogą być tym stronom przekazane, a dodatkowo – uwaga – podmioty, których dane dotyczą, powinny być poinformowane o tym, że te dane zostaną przekazane. Nie jestem pewien czy dobrze odczytałem projektowane wytyczne, ale czy nie znajdzie tutaj zastosowania zasada ‘Impossibilium nulla obligatio est’? 

Bezpieczeństwo danych 

No alt text provided for this image

Krótko. Administrator danych, a więc np. dostawca usług płatniczych musi podjąć wszelkie kroki, aby odpowiednio zabezpieczyć dane. Im wyższe ryzyko związane z przetwarzaniem, tym „lepsze” zabezpieczenia, ale co do zasady mamy obowiązek stosowania najwyższych standardów, w tym również w odniesieniu do silnego uwierzytelniania czy infrastruktury technicznej. Wiele z tych elementów mamy określonych w wytycznych EBA w sprawie ryzyk ICT I bezpieczeństwa (więcej w tym artykule).

Przejrzystość i rozliczalność

Czyli fundamenty RODO określone odpowiednio w art. 5 ust. 1 lit a oraz art. 5 ust. 2 RODO. Nie mam tutaj żadnego „rocket science”, choć jest kilka ciekawych wątków. Oczywistym jest, że dla usług „pod” PSD2 stosujemy art. 13 oraz 14 RODO (obowiązki informacyjne). Tutaj EDPB podkreśla, że musimy zawsze dać użytkownikowi możliwość cofnięcia zgody w każdym czasie czy też dokonania zmian w zakresie przetwarzanych danych. Ciekawe jest to, że EDPB wskazuje tutaj, że użytkownik może zgłosić się do banku w celu zablokowania dostępu do swoich rachunków dla jednego lub więcej TPP (to w zasadzie pokrywa się z niedawną opinią EBA w sprawie przeszkód – więcej tutaj).

No alt text provided for this image

Jeżeli chodzi zaś o rozliczalność, to oczywiście musimy mieć odpowiednie rozwiązania techniczne i organizacyjne (wspomniane przeze mnie wytyczne EBA całkiem nieźle to „tłumaczą”). Musimy także pamiętać o tym, że obowiązuje nas wykazanie, że “nasze” przetwarzanie jest zgodne z art. 5 ust. 1 RODO. I to w zasadzie tyle.

Profilowanie?

Ostatnie już zagadnienie w projektowanych wytycznych. Jeżeli przy świadczeniu usług płatniczych dochodzi do profilowania, to musimy pamiętać o przejrzystości, szczególnie w odniesieniu do stosowanych rozwiązań zautomatyzowanych (wykorzystujących AI czy ML). Musimy przykładowa wskazać jaką logiką „kierowało” się rozwiązanie, a także jak wpłynęło to na ostateczną decyzję (konieczne będzie też zapewnienie odpowiednich praw, np. na wzór tych w art. 105 ust. 1a Prawa bankowego).

Dalej EDPB wskazuje na znaczenie prawa do odmowy poddania się zautomatyzowanym narzędziom opierających się wyłącznie np. o profilowanie pozbawione udziału człowieka. Organ wskazuje też na istotną kwestie, tj. kiedy możliwe jest wykorzystywanie danych wrażliwych w kontekście takich zautomatyzowanych narzędzi. Może to być więc sytuacja określona w art. 22 ust. 4 RODO oraz art. 9 ust. 2 lit. a lub g RODO, tematykę tą omówiliśmy już we wcześniejszych artykułach.

Udostępnij.

Zostaw komentarz