Rynek Finansowy: Wątpliwości pozostają

BANK 2018/01

Uogólnione zapisy PSD2 wydają się bardzo trudne do wprowadzenia – a to ze względu na różny stopień zaawansowania regulacyjnego i technologicznego państw członkowskich UE. Dla przykładu – aktualne rekomendacje KNF odnośnie wytycznych co do używania osobistych danych uwierzytelniających w Polsce wyraźnie przestrzegają przed ich udostępnianiem podmiotom trzecim. Tymczasem sama dyrektywa PSD2 wydaje się dopuszczać takie scenariusze.

Marcin Złoch

Pod koniec listopada 2017 r. zostały opublikowane regulacyjne standardy techniczne (RTS – Regulatory Technical Standards) dla dyrektywy PSD2. Niestety przedstawiciele banków dość niechętnie wypowiadają się na temat tych zapisów.

– Nie chcemy komentować szczegółowo tych tematów na tym etapie, gdyż to bardziej pytania do regulatorów. Analizujemy projekt polskiej ustawy oraz technicznych standardów regulacyjnych, które będą szczegółowo określały zasady i sposób wymiany informacji o rachunku i jego historii oraz inicjowania płatności. Nasze działania w tym zakresie powiązane są z pracami sektora bankowego, m.in. uczestniczymy w pracach Związku Banków Polskich mających na celu wypracowanie standardu open API dla banków – informuje Joanna Majer-Skorupa z Biura Prasowego ING Banku Śląskiego .

– Zapoznajemy się z wymaganiami zawartymi w RTS i analizujemy rozwiązania pozwalające dostosować się do nowych przepisów – dodaje Marcin Sereda, ekspert ds. bezpieczeństwa informacji w Departamencie Bezpieczeństwa Informacji Banku Credit Agricole.

Bez zaskoczeń

Czy takich zapisów się spodziewano? Oczywiście różni zainteresowani oczekują różnych zapisów, dlatego stanowiska mogą odbiegać od siebie w zależności od tego, czy zapytamy banki, czy fintechy, czy też dostawców oprogramowania. Zdaniem Grażyny Dadej, Technical Sales Manager w IBM Polska, niektóre zmiany są zgodne z oczekiwaniami banków i integratorów (np. zakaz screen scrapingu), inne dalej nie wprowadziły jednoznaczności interpretacji. Widać to szczególnie, gdy z poziomu ogólnych dyskusji schodzimy do realnej implementacji technicznej.

– Wymagania zawarte w RTS nie zaskoczyły nas. Spodziewaliśmy się ich właśnie w takim kształcie – twierdzi Marcin Sereda.

Od jakiegoś czasu mówiło się, że nowe zapisy w RTS w stosunku do tych z lutego 2017 r., będą zmierzały do jeszcze większego ułatwienia korzystania z dostępu do usług bankowych przez TPP (ang. Third Party Provider). – Część zmian, jak np. obowiązek publikacji przez bank dokumentacji API i stworzenia dla TPP środowiska testowego na sześć miesięcy przed udostępnieniem interfejsu było zgodnych z przewidywaniami. Natomiast warunkowe utrzymanie możliwości używania tzw. screen scrapingu było raczej niespodziewane. Szczególnie środowiska bankowe spodziewały się, że jedynym sposobem uwierzytelniania klienta będzie zastosowanie tzw. metody „redirect”. Tymczasem rozporządzenie zakazuje zmuszania TPP do zastosowania tylko takiej metody – zauważa Tomasz Leś, Senior Product Manager w Asseco Poland.

Zgodnie z oczekiwaniami banków nowa wersja RTS zabrania definitywnie screen scrapingu (umożliwia on bezpośredni dostęp do rachunku klienta np. przez interfejs kliencki, przy założeniu, że klient udostępnia login i hasło), który w Polsce był zabroniony przez KNF, ale na świecie jest stosowany m.in. przez firmy zajmujące się płatnościami.

Jednocześnie zaskoczyło zdefiniowanie tzw. alternatywnych opcji działania dla TPP w przypadku niedostępności API, np. poprzez interfejs konsumencki. RTS nie dają bowiem wyraźnej odpowiedzi na pytanie, jak ma działać model bezpośredniego dostępu, skoro screen scraping nie będzie dozwolony.

– Dużo zamieszania wprowadzi też prawdopodobnie ograniczenie wykorzystania modelu „redirect” w procesie uwierzytelnienia klienta w banku. Dzisiaj jest on z powodzeniem wykorzystywany w płatnościach „pay-by-link”, z którymi stykamy się, płacąc m.in. przez PayU, Przelewy24 czy Dotpay. Model ten jest sprawdzony, jasny dla klientów i z moich doświadczeń wiem, że wiele banków zakładało użycie go również w implementacji wymagań PSD2 – zauważa Grażyna Dadej.

Jak informuje przedstawicielka dostawcy technologii, wiele z banków zakładało wykorzystanie „redirection” jako jednego z kroków procesu uwierzytelnienia. Pozwalało to nie tylko ograniczać użycie bankowych danych uwierzytelniających w aplikacjach firm trzecich, ale dawało również możliwość większej kontroli i analiz antyfraudowych. Mogłyby one bowiem opierać się na analizach behawioralnych, wynikających zarówno z obserwacji samego sposobu poruszania się klienta w aplikacji, a także urządzenia i środowiska wywołania aplikacji oraz analizy typów transakcji i dzięki temu budować trwały profil zachowania, który można by wykorzystać w celu ułatwienia użytkownikom dostępu do usług oraz zabezpieczenia przed nieuprawnionym dostępem. Ograniczenie możliwości wykorzystania modelu „redirect” sprawiło, że wiele banków musi od nowa zdefiniować swoje podejście do uwierzytelniania i do analizy ryzyk.

W niektórych przypadkach państwa członkowskie mają możliwość zadecydowania, czy określony artykuł dyrektywy ma obowiązywać, czy też nie – mogą np. wybrać, czy mikroprzed-siębiorstwa mają być traktowane jako „klienci korporacyjni”, czy jako „klienci detaliczni”.

Tematy co najmniej dyskusyjne

Innym dyskusyjnym punktem jest zdefiniowanie alternatywnych sposobów dostępu w przypadku, gdyby API nie działało w odpowiedni sposób (co będzie podlegało ocenie nadzorcy), wykorzystującego np. dostęp przez interfejs konsumencki. Po pierwsze, niejasne jest, jak interpretować problemy wynikające nie z samego API, ale związane z niedostępnością sieci. Innym zagadnieniem jest przygotowanie systemów, np. bankowości elektronicznej, do rozpoznawania, czy loguje się klient, czy też podmiot trzeci w jego imieniu, co może oznaczać konieczność zmodyfikowania modułów autoryzacji tych systemów.

Przy tym zagadnieniu pojawia się kolejne pytanie: jak w przypadku bezpośredniego dostępu ograniczyć dojście do danych klienta na rachunku, tylko i wyłącznie do tych, które są niezbędne do zrealizowania transakcji. Przy obecnie funkcjonujących systemach TPP, w momencie gdy skorzysta z tradycyjnego interfejsu konsumenckiego, miałby dostęp do różnych danych klienta. RTS określają oczywiście zasady ich składowania i przetwarzania, ale wiele banków ma jednak pytania co do zgodności z GDPR, które to rozporządzenie mówi, że zgoda na przetwarzanie musi być wyraźnie wyrażona poprzez użytkownika i możliwa do odróżnienia od innych elementów procesu, np. transakcyjnego. Dodatkowo użytkownik powinien mieć możliwość wycofania zgody w sposób równie prosty, jak ją wyraził. Pytanie więc, kto ma zarządzać tymi zgodami: TPP, bank, czy też obydwie instytucje?

Czy zatem zapisy RTS mogą mieć wpływ na wprowadzenie dyrektywy PSD2? Zdaniem ekspertów raczej nie wpłyną one na termin jej wprowadzenia, choć mogą nieco utrudnić bankom konieczne modyfikacje, niemniej nie spodziewają się one z tego powodu istotnych zagrożeń. Jednakże opóźnienia w opublikowaniu RTS wpłynęły na poślizg w definiowaniu lokalnych regulacji, również Polish API. Przesuwa to też proces wdrażania HUB PSD2 realizowanego przez KIR. A wiele banków planuje go wykorzystać do implementacji PSD2. Mamy tu pewien efekt domina, którego wyniku nie ­potrafimy jeszcze ­określić, ale większość zainteresowanych jest zgodna co do tego, że nie uniknie się opóźnień w stosunku do inicjalnych założeń.

Zgodnie z oczekiwaniami banków nowa wersja RTS zabrania defini­tywnie screen scrapingu (umożli­wia on bezpośredni dostęp do ra­chunku klienta np. przez interfejs kliencki, przy założeniu, że klient udostępnia login i hasło), który w Polsce był zabroniony przez KNF, ale na świecie jest stosowany m.in. przez firmy zajmujące się płatno­ściami.

Wspólny model

W przypadku dyrektywy PSD2 dość często pojawia się pytanie o to, czy jednym rozporządzeniem można uregulować różnorodne rynki krajów UE? Tomasz Leś jest zdania, że w przypadku PSD2, pomimo istniejących jeszcze wielu wątpliwości, powinno się to udać. Z kolei Marcin Sereda zwraca uwagę, że zgodnie z obowiązującym prawem można uregulować różnorodne rynki jednym rozporządzeniem, spójne prawo UE pozwala podmiotom na prowadzenie niczym nie ograniczonej i mniej skomplikowanej działalności. Pewne wymagania zawarte w RTS mogą być różne od powszechnie przyjętych rozwiązań w danym kraju.

Uogólnione zapisy dyrektywy PSD2 wydają się trudne do wprowadzenia ze względu na różny stopień zaawansowania regulacyjnego i technologicznego różnych państw członkowskich UE. Dla przykładu, odnośnie wytycznych co do używania w Polsce osobistych danych uwierzytelniających (takich jak login i hasło) aktualne rekomendacje KNF wyraźnie przestrzegają przed udostępnianiem tych danych podmiotom trzecim, natomiast sama dyrektywa PSD2 wydaje się dopuszczać takie scenariusze.

W niektórych przypadkach państwa członkowskie mają możliwość zadecydowania, czy określony artykuł dyrektywy ma obowiązywać, czy też nie – mogą np. wybrać, czy mikroprzedsiębiorstwa mają być traktowane jako „klienci korporacyjni”, czy jako „klienci detaliczni”. – Dlatego transpozycja przepisów dyrektywy PSD2 do prawa krajowego (która powinna nastąpić do stycznia 2018 r.) jest złożonym przedsięwzięciem – przekonuje Grażyna Dadej.

Warto wiedzieć

W zapisach dyrektywy PSD2 pojawia się nowa kategoria usługodawców na rynku usług płatniczych. Obok banków, instytucji płatniczych, operatorów pocztowych, pojawią się instytucje określane jako TPP (ang. Third Party Provider), które będą mogły świadczyć dwa typy nowych usług płatniczych: usługi inicjowania płatności (tzw. payment initiation services – PIS) oraz usługi dostępu do informacji na rachunku (tzw. account information services – AIS). Obydwie usługi polegają na uzyskiwaniu dostępu do rachunku przez osoby trzecie (TPP). Żeby zagwarantować bezpieczeństwo transakcji, ustalono na ten moment dwa warianty uwierzytelniania: tzw. credential sharing – klient podaje swoje dane uwierzytelniające TPP, a TPP przesyła je do dostawcy świadczącego usługę dostępu do rachunku (model stosowany dzisiaj przez TPP wykorzystujących screen scraping) oraz tzw. redirection – klient jest przekierowywany przez TPP na stronę dostawcy świadczącego usługę dostępu do rachunku w celu uwierzytelnienia, a potem jest przekierowywany z powrotem na stronę TPP. W tym modelu dane uwierzytelniające klienta nie są udostępniane TPP.

Screen scraping bazuje na powierzaniu przez klientów loginu i hasła do systemu transakcyjnego innej instytucji. Takie zachowanie stoi w sprzeczności z podstawowymi zasadami bezpiecznego korzystania z bankowości w sieci. Na dokładnie takim samym mechanizmie oparte są bowiem m.in. ataki phishingowe.

Udostępnij artykuł: