Opisywana metoda, przed wejściem w życie dyrektywy PSD2, była przeważnie wykorzystywana przez dostawców usług płatniczych w celu dostarczenia użytkownikom informacji o ich saldach na kontach w różnych bankach lub w celu przyspieszenia procedury oceny ich zdolności kredytowej. Realizacja tych usług wymagała jednak uzyskania przez takich dostawców dostępu do informacji o rachunkach płatniczych użytkowników. Każdy, kto chciał skorzystać z podobnych usług, musiał więc podać dane logowania do swojego konta bankowego zupełnie obcemu podmiotowi, który następnie realizował zleconą usługę, podając się za samego użytkownika.

Screen scraping zasadniczo umożliwiał więc dostawcom usług płatniczych innym niż bank użytkownika uzyskanie dostępu do wszelkich danych, które znajdują się w posiadaniu tego banku i dotyczą konkretnej osoby. Dostawcy ci mogli więc np. ustalić dokładne zarobki użytkownika, jego historię wydatków, a pośrednio nawet jego preferencje zakupowe i sytuację życiową. Mogło to prowadzić do naruszeń danych osobowych, niechcianego profilowania oraz zagrożeń związanych z cyberbezpieczeństwem systemów informatycznych dostawców usług płatniczych (podobne stanowisko dotyczące zagrożeń screen scrapingu konsekwentnie prezentuje Europejska Federacja Bankowa).

Przede wszystkim z tych powodów metoda screen scrapingu została uznana przez Komisję Nadzoru Finansowego za wysoce ryzykowną, a nawet niezgodną z przepisami (zobacz np. komunikat KNF dot. ryzyka związanego z podawaniem innemu bankowi danych do logowania do rachunku bankowego oraz rekomendacja dot. bezpieczeństwa transakcji płatniczych). W konsekwencji przeważająca część banków oraz innych instytucji prowadzących rachunki płatnicze podjęła próby zablokowania korzystania z tej metody. Wpłynęło to bezpośrednio na działalność wielu podmiotów z sektora FinTech, które nie mogły już dłużej świadczyć usług płatniczych w oparciu o screen scraping.

Sytuacja zmieniła się wraz z przyjęciem dyrektywy PSD2, która uregulowała zasady świadczenia usług wymagających dostępu do rachunku użytkownika. Dyrektywa wprowadziła w tym celu nowe rodzaje usług płatniczych: usługę inicjowania transakcji płatniczej, usługę dostępu do informacji o rachunku oraz usługę potwierdzania dostępności środków na rachunku płatniczym. Dyrektywa zobowiązała dostawców prowadzących rachunki (np. banki) do zapewnienia dostępu i przygotowania interfejsu dla podmiotów świadczących nowe usługi płatnicze. Dzięki temu instytucje świadczące nowe rodzaje usług płatniczych mogą wejść w posiadanie danych o użytkowniku (w zakresie niezbędnym do zrealizowania tych usług). Techniczne warunki dostępu dla tych podmiotów określone zostały w rozporządzeniu delegowanym Komisji (UE) 2018/389 odnoszącym się do regulacyjnych standardów technicznych dotyczących silnego uwierzytelniania klienta oraz wspólnych i bezpiecznych otwartych standardów komunikacji (tzw. RTS).

Screen scraping a regulacja RTS

Regulacja RTS wskazuje, że dostawcy usług płatniczych prowadzący rachunki płatnicze, aby zapewnić innym dostawcom usług płatniczych dostęp do danych swoich użytkowników, mogą albo stworzyć dedykowany interfejs (Application Programming Interface – API), albo zmodyfikować interfejs już istniejący (pierwotnie przewidziany dla uwierzytelniania i komunikacji z własnymi użytkownikami). Zmodyfikowany interfejs użytkownika musi jednak umożliwiać uwierzytelnienie się dostawców usług płatniczych przed dostawcą prowadzącym rachunek. Dla celów identyfikacji dostawcy usług płatniczych mają polegać na instrumentach ustanowionych rozporządzeniem 910/2014 w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym (eIDAS), tj. kwalifikowanych certyfikatach pieczęci elektronicznych oraz kwalifikowanych certyfikatach uwierzytelniania witryn internetowych.

Udostępnienie już istniejących interfejsów użytkowników stanowi furtkę umożliwiającą stosowanie screen scrapingu w nowej, zmodyfikowanej formie. Ponieważ wcześniejsza metoda screen scrapingu musi zostać odpowiednio przekształcona i wzbogacona o nowe funkcje (obowiązek uwierzytelnienia się dostawcy), nowa wersja, dopuszczona przez regulację RTS, określana jest często jako screen scraping plus.

Dodatkowe wymagania stawiane tej metodzie mają zneutralizować wady, które wcześniej dyskwalifikowały ją w opinii organów regulacyjnych. W szczególności obecna regulacja ma uniemożliwić dostawcy zewnętrznemu podawanie się za posiadacza rachunku, zadbać o bezpieczeństwo danych użytkownika oraz uchronić go przed niechcianym profilowaniem.

Wybór jednej z dwóch metod komunikacji pozostawiono dostawcom usług prowadzącym rachunki. Komisja Nadzoru Finansowego w swoim komunikacie z 12 stycznia 2018 r. (o którym pisaliśmy już wcześniej) jasno wskazała jednak, że z punktu widzenia zapewnienia efektywnej kontroli nad zakresem udostępnianych danych bezpieczniejszym rozwiązaniem jest stworzenie interfejsu dedykowanego API. Oczywiście jeśli dostawca prowadzący rachunek zdecyduje się na korzystanie z API, zewnętrzni dostawcy usług płatniczych nie będą mogli żądać dostępu w oparciu o metodę screen scrapingu plus.

Nawet jednak decydując się na wdrożenie API (co może być trudniejsze i bardziej kosztowne niż dostosowanie już posiadanego interfejsu) dostawca prowadzący rachunek musi dodatkowo zapewnić odpowiednie środki awaryjnego dostępu.

Screen scraping plus w koniecznych środkach awaryjnych dla dedykowanego interfejsu API

Zgodnie z regulacją RTS dostawca prowadzący rachunek, który korzysta z dedykowanego interfejsu, w sytuacji jego nieplanowanej niedostępności lub awarii ma niezwłoczny obowiązek zapewnienia alternatywy, z której inni dostawcy mogą skorzystać w czasie trwania awarii. Alternatywnym środkiem dostępu w takiej sytuacji jest interfejs udostępniony użytkownikom na potrzeby ich uwierzytelnienia i komunikacji z dostawcą. Dla takich potrzeb musi on zostać odpowiednio zmodyfikowany o m.in. środki ograniczające dostęp do danych, możliwość identyfikacji pomiotu trzeciego oraz rejestracji danych, do których uzyskano dostęp. Jest to więc kolejna furtka dla korzystania ze screen scrapingu plus.

Regulacja RTS umożliwia jednak także wyłączenie od obowiązku zapewnienia mechanizmu awaryjnego. Możliwe jest to po otrzymaniu zgody Urzędu Komisji Nadzoru Finansowego (która ewentualne wyłączenie konsultuje z Europejskim Urzędem Nadzoru Bankowego) oraz spełnienia warunków dotyczących interfejsu dedykowanego, które obejmuje przede wszystkim jego właściwą implementację oraz odpowiednie działanie przez okres co najmniej trzech miesięcy poprzedzających złożenie wniosku.

Do kiedy należy dostosować się do obowiązków?

Mimo że zgodnie z wcześniej wspomnianym komunikatem KNF z 12 stycznia 2018 r. preferowaną przez polskiego regulatora formą komunikacji pomiędzy dostawcami usług płatniczych jest korzystanie z dedykowanego API (polskie prace nad przygotowaniem wspólnych standardów technologicznych takiego rozwiązania można śledzić tu), to zgodnie z obowiązującymi przepisami możliwe jest również zastosowanie drugiej z metod, opartej na zmodyfikowanym interfejsie użytkownika. Pojawia się jedynie pytanie, czy KNF w już zapowiedzianych działaniach nadzorczych nie będzie traktował preferencyjnie tych rozwiązań komunikacyjnych, które opierają się na interfejsie dedykowanym.

Ważne daty

Niezależnie od wyboru interfejsu pierwsze obowiązki wynikające z regulacji RTS powinny były zostać spełnione do 14 marca 2019 r. Do tego dnia dostawcy prowadzący rachunki mieli zapewnić zgodność swoich interfejsów ze standardami komunikacji publikowanymi przez międzynarodowe lub europejskie organy normalizacyjne oraz przygotować niezbędną dla innych dostawców dokumentację systemów komunikacji, a ich streszczenie udostępnić na stronie internetowej. Dostawcy prowadzący rachunki płatnicze powinni począwszy od powyższej daty umożliwić dostęp do środowiska służącego do testowania połączenia i funkcjonalności, aby pozwolić innym dostawcom na zbadanie oprogramowania oraz przetestowanie swoich aplikacji wykorzystywanych do świadczenia usług płatniczych.

Ostateczna data, od której stosowane będą wszystkie obowiązki wynikające z regulacji RTS (np. przepisy dotyczące silnego uwierzytelniania użytkowników), została wyznaczona na 14 września 2019 r. Jednak zgodnie ze stanowiskiem KNF urząd będzie oczekiwał od dostawców prowadzących rachunek posiadania interfejsów spełniających wymogi przewidziane w RTS w możliwie jak najszybszym terminie.

Adam Polanowski, Przemysław Gruchała