Co niesie za sobą Dyrektywa PSD II?

W drugiej połowie XX wieku rozpoczęła się rewolucja technologiczna, która ułatwiła powstawanie i wymianę informacji na niespotykaną wcześniej skalę. Podobno w ciągu ostatnich dwóch lat stworzyliśmy więcej danych niż od początku istnienia ludzkości. Co sekundę w internecie generowanych jest 30 GB nowych danych.

W tym zalewie danych ważne jest uzyskanie informacji naprawdę istotnych. Za takie niewątpliwie uchodzą przechowywane przez bank dane związane z naszymi transakcjami. Już od kilku lat funkcjonują na rynku europejskim podmioty, które, dzięki pozyskaniu i wykorzystaniu tych danych, są w stanie zaoferować klientom nowe usługi finansowe. Mowa głównie o dwóch usługach:

  1. Usługa inicjowania płatności (PIS) – większość z nas płatności w internecie kojarzy z Pay-by-linkami. PIS, z punktu widzenia klienta, może wydawać się podobny. Od Pay-by-linków odróżnia go jednak to, że podmiot świadczący PIS nie wchodzi w żadnym momencie w posiadanie kwoty transakcji. On tylko przekazuje odbiorcy płatności informację, że transakcja została zlecona (a wie o tym, bo to on ją za nas inicjuje);
  2. Usługa dostępu do informacji o rachunku (AIS) – usługa ta polega na pobraniu historii naszych transakcji z co najmniej jednego rachunku i przedstawienia ich klientom w sposób, który ma ułatwić zapoznanie się ze stanem finansów.

Jak widać, obie powyższe usługi oparte są na wykorzystaniu danych (PIS – na wykorzystaniu danych o zainicjowaniu transakcji, AIS - o historii wszystkich transakcji klienta). PIS i AIS wymagają, aby klienci posiadali dostęp on-line do swoich rachunków (czyli co do zasady muszą mieć bankowość elektroniczną). W praktyce klienci podawali tym podmiotom (podmioty te nazywane są Third Party Providers, w skrócie TPP) swoje dane uwierzytelniające do bankowości elektronicznej, żeby TPP mogły wykonać odpowiednie czynności lub pobrać informacje. Wywoływało to szereg kontrowersji związanych z bezpieczeństwem, ochroną konkurencji oraz zgodnością z prawem. Zauważyły to w odpowiednie służby Komisji Unii Europejskiej, co znalazło odzwierciedlenie w treści Dyrektywy 2015/2366 w sprawie usług płatniczych w ramach rynku wewnętrznego, znanej szerzej jako PSD II.

W PSD II objęto TPP nadzorem i nałożono na nie szereg obowiązków (w tym identyfikowanie się wobec dostawców usług płatniczych prowadzących rachunki i posiadanie odpowiednich środków bezpieczeństwa). W zamian dostawcy usług płatniczych prowadzący rachunki on-line (czyli w zasadzie banki), muszą zapewniać upoważnionym TPP dostęp do informacji o rachunku klienta i możliwość inicjowania płatności w imieniu klienta (oczywiście jeżeli posiadają wyraźną zgodę klienta). Zabroniono również dyskryminowania TPP przez dostawców prowadzących rachunek.

TPP oraz dostawcy usług płatniczych prowadzący rachunki muszą zgodnie z PSD II porozumiewać się ze sobą za pomocą bezpiecznych i wydajnych kanałów komunikacji. W praktyce uważa się, że najlepiej ten wymóg spełni API czyli Application Programming Interface. API jest to zestaw funkcji i procedur umożliwiających dostęp do danych lub usług w celu zapewnienia większej funkcjonalności użytkownikowi danej aplikacji. API może być używane do określenia, która funkcjonalność jest dostępna, jak musi być używana i jakie formaty akceptuje jako dane wejściowe lub dane wyjściowe.

Szczegółowe wymogi w zakresie bezpiecznej komunikacji mają określać  Regulacyjne Standardy Techniczne (RTS) przyjęte w formie rozporządzenia  Unii Europejskiej. Ostatecznej treści tego rozporządzenia nadal nie znamy. Wiadomo, że ma ono zacząć obowiązywać po upływie 18 miesięcy od jego wejścia w życie.

Ustawa implementująca w Polsce PSD II na pewno wejdzie w życie wcześniej niż wspomniany RTS. Kiedy dokładnie, nadal nie wiadomo. PSD II wymaga, aby implementacja nastąpiła najpóźniej 13 stycznia 2018 r., ale projekt zmian do ustawy o usługach płatniczych nadal jest konsultowany i wydaje się, że realna data to połowa przyszłego roku.

Między wejściem w życie zmian w ustawie o usługach płatniczych implementujących PSD II a wejściem w życie RTS dotyczącego bezpiecznych zasad komunikacji, powstanie około roczna luka (tzw. okres przejściowy). W tym czasie nie wiadomo do końca w jaki sposób powinny z sobą wymieniać dane TPP i dostawcy świadczący usługę dostępu do rachunku. Moim zdaniem rozwiązania są dwa. Dostawcy świadczący usługę dostępu do rachunku mogą albo udostępnić swoje API, albo powinni „znosić” wykorzystanie screen scrapingu przez upoważnionych TPP do czasu wejścia w życie RTS. Po stronie TPP powstaje wątpliwość czy w razie udostępnienia API w okresie przejściowym przez dostawcę świadczącego usługę dostępu do rachunku, TPP musi korzystać z tego API czy też może wykorzystywać nadal screen scraping w kontaktach z tym dostawcą. Uważam, że pośrednio odpowiada na ten problem art. 35j ust. 5, który ma zostać dodany do ustawy o usługach płatniczych w ramach implementacji PSD II. Artykuł ten odnosi się problemu, jakim jest kwestia uwierzytelniania klienta. Na ten moment można wyróżnić dwa warianty uwierzytelniania:

  1. 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);
  2. 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.

Wspomniany art. 35j ust. 5 stanowi, że dostawca świadczący usługę dostępu do rachunku może ustanowić zasady komunikacji zgodne z modelem redirection (a model ten jest raczej nie do zastosowania bez API). Jeżeli dostawca ten skorzysta z modelu redirection to TPP będą, moim zdaniem, zmuszone się do niego dostosować zarówno w okresie przed wejściem w życie RTS, jak i po ni. Istnieje jednak jeden wyjątek: najpóźniej do końca okresu przejściowego (albo 6 miesięcy od wejścia w życie ustawy jeżeli TPP nie złoży wniosku o wpis do rejestru dostawcy świadczącego wyłącznie usługę dostępu do informacji o rachunku), TPP świadczące usługi AIS, mogą świadczyć swoje usługi w sposób, w jaki były one świadczone przed dniem wejścia w życie projektowanej nowelizacji ustawy o usługach płatniczych (tak art. 10 ust. 3 projektu ustawy o zmianie ustawy o usługach płatniczych oraz niektórych innych ustaw). Dlaczego tylko TPP świadczące usługi AIS otrzymały to uprawnienie oraz czy faktycznie uniemożliwia ono „wymuszenie” na nich w okresie przejściowym drugiego modelu uwierzytelniania, pozostaje kwestią otwartą i powinny moim zdaniem zostać doprecyzowane na dalszym etapie prac nad ustawą.

Oprócz powyższych prac trwają jednocześnie prace nad stworzeniem powszechnego na polskim rynku standardu API tzw. Polish API. Prace są prowadzone w ramach Związku Banków Polskich. Na potrzeby Polish API ma powstać Hub (na ten moment ma nim być KIR), który ma m.in. zarządzać technicznie Polish API i je utrzymywać. Polish API ma korzystać z modelu uwierzytelniania redirection i zapewnić uproszczony mechanizm świadczenia dodatkowych usług w ramach API (tj. nie objętych PSD II). Uniwersalny standard ma w założeniu przyczynić się do większego bezpieczeństwa danych oraz do zaoszczędzenia czasu i kosztów, zarówno po stronie banków (nie będą musiały od zera tworzyć własnych standardów), jak i TPP (nie będą musiały łączyć się z wieloma różnymi API). Takie ogólnokrajowe standardy powstają również w innych państwa Unii Europejskiej np. Berlin Group, STET we Francji, Open Banking w Wielkiej Brytanii oraz CAPS, który nie ogranicza się do jednego państwa.

Zarówno PSD II, jak i przepisy projektowanej nowelizacji ustawy o usługach płatniczych, nie wykluczają takich uniwersalnych standardów. Istotne jest jednak, żeby spełniały one wymogi PSD II, w tym ogólne zasady jak np. zasada niedyskryminacji zleceń płatniczych lub wniosków o udostępnienie informacji przekazanych przez TPP.

r. pr. Marcin Bieliński

Już 21 i 22 września 2017 w Warszawie odbędzie się konferencja „Dyrektywa PSD 2  - kluczowe zmiany na rynku usług płatniczych”,  podczas której Pan Marcin Bieliński będzie prelegentem. Szczegóły na stronie konferencje.pb.pl.

Źródło:

Newsletter Bankier.pl

Dodałeś komentarz Twój komentarz został zapisany i pojawi się na stronie za kilka minut.

Jeszcze nikt nie skomentował tego artykułu - Twój komentarz może być pierwszy.

Nowy komentarz

Anuluj

Porównaj oferty

Sprawdź, które banki pożyczą pieniądze na najlepszych warunkach, i ile wyniesie miesięczna rata kredytu.

Znajdź najbardziej zyskowną lokatę bankową. Określ najważniejsze cechy, a wyszukiwarka wybierze najlepsze oferty.

Zapisz się na bezpłatny newsletter Bankier.pl