Europejski Urząd Nadzoru Bankowego o minimalizacji przetwarzanych danych, PSD2 vs RODO

Zacznę od art. 5 ust. 1 lit. c) Rozporządzenia 2016/679 (RODO), który wyznacza zasadę tzw. minimalizacji danych, czyli zapewnienia, że przetwarzane dane są adekwatne, stosowne oraz ograniczone do tego, co niezbędne do celów, dla 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?

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, 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.

Czytaj także: RODO a PSD2 w praktyce świadczenia usług finansowych

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

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.

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

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).

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ładowo 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ówiłem już we wcześniejszych artykułach.