Dyrektywa PSD2 (Second Payment Services Directive – Dyrektywa Parlamentu Europejskiego i Rady (UE) 2015/2366 z dnia 25 listopada 2015 r.) to drugi po RODO gorący temat bieżącego roku. Jest on ściśle związany z sektorem bankowym. W wielu mediach przedstawiane są skrajne opinie o tej dyrektywie. W niniejszym artykule postaram się rozwiać wątpliwości i możliwie jak najwierniej przedstawić opis dyrektywy. Przesłanie jest proste – bezpieczeństwo transakcji nie może zostać wystawione na próbę.

Polska była zobowiązana do dostosowania swojego prawa do dyrektywy unijnej do stycznia 2018 roku. Dnia 9 stycznia 2018 roku rząd przyjął nowelizację ustawy. Jej celem jest:

  • zapewnienie większej przejrzystości i spójności prawa w zakresie usług płatniczych
  • stworzenie podwalin do jednolitego rynku płatności w Unii Europejskiej
  • rozwój obrotu bezgotówkowego i zwiększenie szybkości realizacji płatności

W związku z dyrektywą, pojawiają się w przepisach informacje o funkcjonowaniu nowych usługodawców na rynku usług płatniczych – tzw. podmioty trzecie (TPP – Third Party Provider). Ich zakres działania obejmuje:

  • inicjowanie transakcji płatniczych (PIS – Payment Initation Service)
  • dostęp do informacji o rachunku (AIS – Account Information Service)

Stanowi to wstęp do budowy nowoczesnych usług płatniczych opartych o API (Application Programming Interface). Wszystko powyższe ma się wpisywać w ideę „otwartej bankowości” i przyświecać rozwojowi sektora w obrębie obsługi sfery finansowej i niefinansowej (poprzez integrację).

Oczywiście, jak pewnie się domyślacie, największym echem od kilku miesięcy odbija się informacja o podmiotach trzecich (TPP). Słusznie? O tym w kolejnej części artykułu. A tutaj poniżej krótkie wideo autorstwa Deloitte Luxembourg, które w sposób bardzo zrozumiały przedstawia powiązania pomiędzy podmiotami trzecimi a bankami.

 

 

Prawa i obowiązki podmiotów trzecich

W ramach Payment Initiation Service usługodawcy będą mieli dostęp do rachunku płatnika w celu sprawdzenia dostępności środków pieniężnych oraz inicjacji płatności (w imieniu płatnika). Obsługiwana ma być dowolna liczba rachunków płatniczych i dowolna liczba dostawców usług płatniczych. Po wszystkim zobligowani są do przedstawienia płatnikowi potwierdzenia.

Account Information Service to nic innego jak usługa do zarządzania swoimi finansami w ramach jednego systemu. Mowa tutaj również o dowolnej liczbie rachunków płatniczych i dowolnej liczbie dostawców usług płatniczych.

Analizując zakres praw TPP na pewno macie pewne obawy w stosunku do bezpieczeństwa dostępu, a w konsekwencji bezpieczeństwa swoich środków na rachunkach płatniczych. Oczywiście organy ustawodawcze nie pominęły tego faktu. Wprowadziły obowiązek silnego uwierzytelniania użytkownika (SCA). To nic innego, jak wymóg identyfikacji użytkownika za pomocą trzech niezależnych metod uwierzytelniania – np. kod SMS + zabezpieczenie biometryczne + PIN.

 

Dostawca będzie musiał stosować silne uwierzytelnianie w przypadku, gdy płatnik: uzyskuje dostęp do swojego rachunku w trybie online; inicjuje elektroniczną transakcję płatniczą; przeprowadza czynność za pomocą kanału zdalnego, która może się wiązać z ryzykiem oszustwa płatniczego lub innych nadużyć. To rozwiązanie znacznie poprawi bezpieczeństwo płatności elektronicznych.

Centrum Informacyjne Rządu, 09.01.2018 [12]

 

Niektórzy mogą pomyśleć, że prawo napędzi rozwój tzw. FinTechów (firmy działające na styku finansów i nowych technologii; TPP). Osobiście do tego rozwoju podchodzę nieco bardziej zachowawczo. Oczywiście rola tych firm zwiększy się kosztem udziału banków, ale obowiązki bezpieczeństwa, jakie są przed nimi stawiane na pewno nie pozwolą nonszalancko traktować klientów. Banki znacząco utracą kontakt z klientem. Teraz to klient będzie mógł skorzystać z TPP, aby kontrolować swoje finanse i to wymusi na bankach zmianę strategii biznesowych.

W praktyce klient musi TPP dać jednoznaczną zgodę na korzystanie z ich usług (PIS i/lub AIS). Natomiast TPP już prawnie z bankiem nie musi podpisywać żadnej umowy. Wszystko ma się odbywać poprzez API banku z zaimplementowanym silnym uwierzytelnianiem.

Jesteście już przekonani? Ja niestety tylko częściowo.

 

Ryzyko i konsekwencje

Mój sceptycyzm nie bierze się z wymysłów. Oczywiście to klient wyraża zgodę by TPP uzyskał wgląd w finanse. Pozwolenie podmiotom trzecim na zbieranie informacji (AIS) będzie zapewne wygodne, jednak nasza historia finansowa w tym momencie będzie podlegać replikacji. Teraz warto zadać sobie pytanie – czy lepiej przechowywać wrażliwe dane w jednym miejscu (serwery banków) czy w kilku (serwery banków i serwery TPP, którym daliśmy zgodę na analizę danych)? Oczywiście po cichu liczę na to, że w związku z RODO ryzyko tutaj jest mocno minimalizowane, ale zawsze trzeba mieć ograniczone zaufanie do „strony trzeciej” – zawsze!

W myśli przyświecającej idei PSD2 kluczową rolę odgrywało bezpieczeństwo wszystkich usług świadczonych drogą elektroniczną. Wykorzystywane do tego miały być nowoczesne technologie, będące w stanie zagwarantować bezpieczne uwierzytelnianie użytkownika i sposób ograniczający w najwyższym stopniu ryzyko oszustw. Wcześniej wspomniane silne uwierzytelnianie miało (i będzie) oznaczać konieczność pokonania przynajmniej dwóch różnych zabezpieczeń- przed finalizacją transakcji – odnoszących się do następujących kategorii:

  • wiedzy (np. hasła, kody bezpieczeństwa)
  • posiadania (np. telefon, na który dostarczane jest hasło)
  • cech klienta (np. odcisk palca/ów, wzór tęczówki oka, układ żył w dłoni)

Wierzę, że przesłanie bezpieczeństwa transakcji spełni się i ryzyko niekontrolowanego odpływu finansów z kont płatniczych zostanie zminimalizowane niemal do zera, ale pozostają kwestie danych wrażliwych i/lub prywatnych (np. raporty finansowe, które niepowiązane z żadną osobą są wyłącznie danymi statystycznymi, ale już powiązane to nic innego jak profilowanie klienta).

W mojej ocenie PIS jest godny uwagi o ile dane przechowywane przez TPP będą ograniczone do minimum (logowanie transakcji i operacji z zachowaniem wysokiego poziomu bezpieczeństwa danych wrażliwych – ewentualny wyciek takich danych nie zaszkodzi ani usługodawcy, ani klientowi, ani bankowi). Jeśli jednak w ramach PIS  bazy TPP będą „puchnąć” od nadmiaru informacji to problem z czasem będzie narastać. W przypadku AIS rozrost bazy danych TPP jest nieunikniony i do takich usług na chwilę obecną nie jestem przekonany, chociaż kuszą one mocno niejednego człowieka, niczym „rajskie jabłko”.

 

Dodatkowo TPP będą zwolnione z części wymogów, którym podlegają instytucje płatnicze (takich jak posiadanie funduszy własnych i wymogi ochrony środków pieniężnych klienta). Istotna jest tu informacja, że TPP nie będą wchodzić na żadnym etapie świadczenia swoich usług w posiadanie środków pieniężnych płatnika. Niemniej TPP będą mieć obowiązek posiadania ubezpieczenia od odpowiedzialności cywilnej.

PSD2 — nowa dyrektywa dotycząca usług płatniczych [21]

 

RTS – wytyczne techniczne

W ogólności projekt ten opiera się scenariusze, które operatorzy finansowi zmuszeni są respektować. Standard został opisany w dzienniku urzędowych UE z dnia 13.03.2018 roku – patrz [17].

Mechanizmy monitorujące transakcje

Algorytmy (tudzież przepływ informacji) muszą brać pod uwagę wszystkie znane elementy ryzyka. Wykrycie braku jakichkolwiek informacji (niezbędnych), naruszenie uwierzytelniania, niezgodność kwoty transakcji, manipulacje kontem docelowych transakcji lub innych znanych schematów oszustw powodować ma analizę próby wykonawczej i zabezpieczenie przed niekontrolowanym wypływem środków. Oczywiście są to, wydawać by się mogło, wszystkim dobrze znane prawdy podstawowe, o których nie powinno się wspominać.

Każda rezygnacja operatora z silnego uwierzytelniania obliguje go do nadzoru:

  • ścieżki transakcyjnej
  • historii operacji
  • lokalizacji użytkownika, urządzenia dostępowego i oprogramowania
  • anomalii w ścieżkach transakcyjnych (w stosunku do zapisów historycznych)
  • czasu logowania
  • nietypowego użycia urządzenia lub oprogramowania

 

Raz w roku operator ma obowiązek przeprowadzić audyt
skuteczności mechanizmów i ich zgodności z aktualną wersją
Regulacji. Wyniki audytu muszą być stale dostępne do wglądu
organów kontrolnych.

Apilogic – Odszyfruj RTS. Regulatory Technical Standards do Dyrektywy PSD2 (w pigułce) – ebook [19]

 

Silne uwierzytelnianie klienta

Tutaj nie ma żartów. Weryfikacja 3-składnikowa to już nie byle jakie zabezpieczenie. Pierwszy składnik należy do grupy posiadania – telefon komórkowy, token. Operatorzy muszą dołożyć wszelkich starań by wykryć przejęcie telefonu/tokenu przez osoby niepowołane, wykryć skopiowanie urządzenia i/lub oprogramowania wykorzystywanego do wykonywania operacji (transakcji). Drugi składnik należy do grupy cech klienta – odcisk palca, szablon głosu, skan tęczówki oka, układ żył dłoni. W tym przypadki dostawcy usług zobligowani są do wszelkich działań na rzecz wykrycia prób podszycia. Trzeci składnik należy do grupy wiedzy – kod PIN, hasło dostępu. W tym przypadku operatorzy muszą podjąć wszelkie starania w celu utajnienia wiedzy w procesie weryfikacji. Myślę, że dobrym działaniem jest w tym miejscu określenie okresu ważności takiej wiedzy, ale czy takie mechanizmy zostaną wdrożone zależy już bezpośrednio od dostawców.

Interpretując wszelkie informacje na temat SCA często napotykam zapisy o przynajmniej 2-składnikowej weryfikacji. Powyżej przedstawiona została 3-składnikowa. Już wyjaśniam dlaczego. Otóż RTS przewiduje generowanie kodów dostępu do wszystkich stref wrażliwych podatnych na oszustwa i wyłudzenia. W przypadku, gdy wystąpi problem z wygenerowaniem kodu dostępu, związany z niespełnieniem podstawowych wymogów bezpieczeństwa, wówczas wymagana jest weryfikacja 3-składnikowa!

Regulacje obejmują kilka wyjątków od silnego uwierzytelniania (w trybie online):

  • sprawdzanie konta bankowego
  • transakcje płatnicze w okresie do 90 dni od ostatniego SCA (powiem szczerze, że ten zapis nieszczególnie kładzie nacisk na bezpieczeństwo)

… ale wyjątki te nie mają zastosowania, gdy zajdą poniższe okoliczności:

  • operacja jest wykonywana po raz pierwszy przez klienta
  • minęło 90 dni od ostatniego SCA

Wyjątki w przypadku transakcji zbliżeniowych

  • transakcja jest zbliżeniowa do 50€
  • od ostatniego uwierzytelnienia nie było więcej niż 5 transakcji i ich suma przekracza 150€

Dodatkowo do wyjątków zaliczamy

  • płatność za parking w terminalach parkingowych lub bilety w terminalach transportu

Pozostałe odstępstwa od silnego uwierzytelniania (PSP w tych przypadkach jest zwolniony z SCA):

  • odbiorca jest zapisany w naszej bazie kontaktów
  • transakcja na taką samą kwotę jak kilka poprzednich do tego samego odbiorcy
  • przelewy własne
  • kwota transakcji do 30€ (transakcja zdalna)
  • suma kwot maksymalnie 5 transakcji nie przekracza 100€ (transakcja zdalna)

Operatorzy płatności mają spore pole manewru jednak opuszczenie SCA, bądź jego wymóg zawsze zależy mechanizmu bezpieczeństwa, które weryfikując każdą operację określa zasadność silnego uwierzytelnienia – tzw. ryzyko operacji.

 

Operatorzy PSP, pod rygorem zablokowania wyłączenia SCA, muszą monitorować następujące dane: transakcje nieautoryzowane (wartość), wszystkie transakcje wraz z współczynnikiem oszustw każdej z nich, średnie wartości transakcji z SCA i bez SCA, liczbę transakcji autoryzowanych i nieautoryzowanych. Rzeczonej blokady mogą dokonać upoważnione organy kontrolne. Blokada nie jest permanentna. Zdjęcia jej dokonują te same organy po przesłaniu raportu z wymaganymi informacji.

Jeśli kontrole wykażą, że zagrożenie oszustwem bądź wyłudzeniem
wzrosło dla tego PSP, mogą wymagać Silnego Uwierzytelniania nawet w przypadkach, gdzie wcześniej było stosowane wyłączenie. 

Apilogic – Odszyfruj RTS. Regulatory Technical Standards do Dyrektywy PSD2 (w pigułce) – ebook [19]

 

Dotychczas szeroko stosowane kody SMS w weryfikacji transakcji nie są zgodne z PSD2. Trudno się temu dziwić, biorąc chociażby pod uwagę ostatnie niepokojące informacje o aplikacji, która pozwalała przechwytywać dane wrażliwe i w konsekwencji przelewy. Więcej o tym tutaj.

 

Blokada konta

Sesja zweryfikowanego użytkownika musi wygasnąć po 5 minutach braku aktywności. Co jednak w przypadku, kiedy próbujemy (bądź osoba o nieczystych zamiarach) przejść autoryzację bez skutku? Mamy 5 prób, po ich wykorzystaniu narzędzie musi nałożyć tymczasową lub permanentną blokadę. Przed całkowitą blokadą użytkownik musi zostać wyraźnie poinformowany. Tutaj nałożenie blokady całkowitej zależy od operacji i analizy ryzyka mechanizmu zabezpieczeń.

 

RTS – podsumowanie

Standardy RTS można rozdzielić na 3 główne grupy:

  1. Neutralność technologiczna rozwiązań – przesłaniem jest uniwersalność wytycznych, które nie mają być dotknięte piętnem czasu
  2. Wyjątki od stosowania silnego uwierzytelniania – uzależnienie zabezpieczenia operacji/transakcji od sytuacji oraz stopnia ryzyka wyliczonego poprzez mechanizm systemowy
  3. Warunki dostępu do TPP i standardy komunikacji – wymuszenie szczegółowej dokumentacji każdej transakcji, automatycznej obsługi transakcji dla zminimalizowania prób oszustw oraz samych oszustw

Dokument RTS i jego objaśnienia zawierają mnóstwo cennych informacji. Większość jest kluczowa wyłącznie dla podmiotów trzecich (TPP). Powyżej starałem się w pigułce zawrzeć najcenniejsze dane, aby zobrazować mechanizm działania i zarysować trochę sytuację, która czeka nas niebawem. Mówi się, że API bankowe będzie wykorzystywane na porządku dziennym do 2020 roku. Już teraz Związek Banków Polskich celuje w finalizację polskiego API do końca 2019 roku. Jak czytamy na stronie uczestnikami projektu są „Związek Banków Polskich wraz ze stowarzyszonymi bankami komercyjnymi i spółdzielczymi, Spółdzielcze Kasy Oszczędnościowo-Kredytowe, Polska Organizacja Niebankowych Instytucji Płatności wraz ze stowarzyszonymi firmami, Polska Izba Informatyki i Telekomunikacji, Polska Izba Ubezpieczeń, Krajowa Izba Rozliczeniowa, Biuro Informacji Kredytowej, Polski Standard Płatności.”

Konsultacje publiczne odbyły się w styczniu 2018. Pozostaje czekać na postępy. Sam jestem ciekawy zastosowanych rozwiązań, jak i skutków wykorzystania ich przez podmioty trzecie.

 

Wpływ na przyszłość świata technologii

Dyrektywa odbija się szerokim echem w mediach, jednak mam wrażenie, że booom informacyjny nastąpi kiedy banki przygotują swoje API do współpracy z TPP i odczujemy rzeczywiście jej wynik na własnej skórze. Przecież o RODO, o którym powstał poprzedni artykuł aż tak głośno (niestety) nie było i teraz firmy się spieszą z wdrożeniem mechanizmów zgodnych z ustawą implementującą dyrektywę unijną.

W kontekście dyrektywy i wytycznych RTS najbardziej rozwojowy będzie sektor fintech, o którym kilkukrotnie już wspomniałem. Jednak takie zmiany w bankowości (API) pozwolą na powstanie bardzo ciekawych rozwiązań dla klientów:

  1. Usługi księgowe i parki kont bankowych
  2. Zarządzanie ryzykiem jako usługa (w końcu dlaczego wewnętrzny mechanizm przeliczania ryzyka ma pozostać wewnętrzny?)
  3. Uwierzytelnianie w oparciu o model AaaS (Authentication as a Service)
  4. Serwisy płatności pokroju PayU (czeka nas duże zamieszanie na rynku takich serwisów)
  5. Rozwój nowych modeli płatności (smartfon już dzisiaj staje się kartą płatniczą poprzez wykorzystanie NFCPSD2 przyczyni się do wyparcia z użycia kart płatniczych i w końcu gotówki – jednak moim skromnym zdaniem w Polsce to tak szybko nie nastąpi)

 

Jak wspomniałem w sekcji „Ryzyko i konsekwencje” wszystko wygląda fajnie dopóki nie przerazimy się jak wiele wiedzą o nas TPP. Uwagę zaczniemy do tego przywiązywać jak będzie już za późno. Chociaż cały czas świat dąży do tego, by wszystko było „smart”, to życie nas uczy, że aby coś otrzymać musimy coś dać od siebie. Tutaj będziemy mieli do czynienia z profilowaniem na poziomie „master” i całe szczęście, że pojawiło się RODO, bo od teraz mamy jakiekolwiek prawo i szansę do bycia zapomnianym. Czy aby w praktyce wszystkie dane znikną z chmur danych i serwerów, na które trafiły „przez przypadek” lub przez niedopatrzenie?! Na to już każdy musi odpowiedzieć sobie sam.

 

 

Bibliografia:

[1] https://fintek.pl/psd2-blizej-przyjal-projekt-ustawy/

[2] https://fintek.pl/otwarta-bankowosc-cos-wiecej-niz-psd2/

[3] https://www.polskieradio.pl/42/276/Artykul/1985345,Dyrektywa-PSD2-jak-zmieni-sie-rynek-uslug-platniczych-Rzad-przyjal-nowelizacje-ustawy

[4] http://www.polska2041.pl/finanse/news-psd2-co-z-kontrowersyjna-metoda-dostepu-do-banku,nId,2484899

[5] https://www.pwc.pl/pl/branze/bankowosc-ubezpieczenia/psd2.html

[6] https://www.bankier.pl/wiadomosc/Rzad-za-dostosowaniem-prawa-do-unijnej-dyrektywy-PSD2-4057199.html

[7] https://subiektywnieofinansach.pl/psd2-co-zmieni-w-naszych-portfelach-banki-sie-boja/

[8] http://www.finanse.egospodarka.pl/145940,PSD2-szansa-i-zagrozenie,1,63,1.html

[9] https://www2.deloitte.com/pl/pl/pages/doradztwo-prawne/topics/PSD2.html#

[10] https://www2.deloitte.com/pl/pl/pages/financial-services/articles/newsletter/finanse-i-bankowosc-grudzien-2017/Dyrektywa-PSD2.html

[11] https://www2.deloitte.com/pl/pl/pages/doradztwo-prawne/articles/dyrektywa-PSD2/pytania-i-odpowiedzi.html

[12] https://www.premier.gov.pl/wydarzenia/decyzje-rzadu/projekt-ustawy-o-zmianie-ustawy-o-uslugach-platniczych-oraz-niektorych-2.html

[13] https://www.payu.pl/blog/jak-dyrektywa-psd2-zrewolucjonizuje-platnosci-online

[14] https://blog.bzwbk.pl/2017/05/rewolucja-w-zakresie-platnosci

[15] https://fintek.pl/ustawa-o-psd2-przyjeta-przez-komisje-finansow-publicznych/

[16] https://fintek.pl/ustawy-o-uslugach-platniczych-po-trzecim-czytaniu/

[17] https://eur-lex.europa.eu/legal-content/PL/TXT/HTML/?uri=CELEX:32018R0389&from=EN

[18] https://apilogic.pro/psd2-rts-standardy-rts-do-psd2/

[19] https://apilogic.pro/wp-content/uploads/2017/11/APILOGIC_ebook_RTS-do-PSD2_Standardy_Techniczne_do_dyrektywy_w_pigułce.pdf

[20] https://apilogic.pro/otwarte-api-i-otwarta-bankowosc-7-pomyslow-na-nowe-produkty/

[21] http://payarto.pl/psd2-nowa-dyrektywa-dotyczaca-uslug-platniczych/