Czy wejście w życie rozwiązań przewidzianych w Dyrektywie PSD2 oznacza zmierzch tradycyjnego modelu biznesowego bankowości spółdzielczej?

W listopadzie 2015 r. Parlament Europejski uchwalił dyrektywę regulującą rynek płatności – Payment Services Directive 2 (PSD2). Dyrektywa weszła w życie 1 stycznia 2016 r. i zastąpiła dotychczasową Dyrektywę PSD. Poszczególne kraje członkowskie UE miały obowiązek jej implementacji do krajowych porządków prawnych do 13 stycznia 2018 r.

Jedną z konsekwencji wdrożenia Dyrektywy PSD2 będzie pojawienie się na rynku nowych usług płatniczych, takich jak:

• usługa dostępu do informacji o rachunku (AIS, Account Information Services),

• usługa inicjowania płatności (PIS, Payment Initiation Services),

• usługa potwierdzania dostępności na rachunku płatniczym płatnika kwoty niezbędnej do wykonania transakcji płatniczej (CAF, Confirmation of the Availability of Funds).

Poszerzony zostanie także katalog dostawców usług płatniczych o nową kategorię podmiotów – dostawców usług płatniczych będących stronami trzecimi (third party payment service provider – TPP).

Nowi dostawcy usług płatniczych – TPP

TPP świadcząc usługi dostępu do informacji o rachunku (AIS), zapewnią klientowi online zagregowane informacje o jednym lub kilku rachunkach płatniczych, prowadzonych przez jednego lub kilku dostawców usług płatniczych. Dzięki temu klient otrzyma możliwość natychmiastowego uzyskania informacji o swojej aktualnej sytuacji finansowej.

Usługi inicjowania płatności (PIS) polegać będą na udzieleniu TPP dostępu online do rachunku klienta w celu sprawdzenia dostępności środków pieniężnych, zainicjowania płatności, a następnie przedstawienia informacji o dokonaniu płatności. Istotne jest przy tym to, iż TPP będzie mógł w imieniu klienta uzyskać dostęp do jego rachunku przez specjalnie stworzony w tym celu interfejs (API), który będzie otwarty dla wszystkich podmiotów zewnętrznych. Banki mają obowiązek zbudować taki interfejs i umożliwić za jego pośrednictwem dostęp TPP do rachunków klientów po tym, jak TPP uzyska od klienta zgodę na taki dostęp. Jednocześnie TPP po podpisaniu umowy z klientem nie będzie musiał podpisywać jakichkolwiek umów z bankiem/bankami, które prowadzą rachunek tego klienta.

Zgodnie z treścią opublikowanych przez Komisję Europejską Regulacyjnych Standardów Technicznych (RTS) stanowiących uzupełnienie Dyrektywy PSD2, każdy dostawca usług płatniczych prowadzący rachunek dostępny za pośrednictwem Internetu zobowiązany będzie zapewnić co najmniej jeden interfejs komunikacji z TPP. Udostępniony interfejs powinien pozwalać TPP na wzajemną identyfikację z dostawcą prowadzącym rachunek przed rozpoczęciem świadczenia usługi na zlecenie klienta. Dostawcy prowadzący rachunki, a więc przede wszystkim banki, mogą zapewnić interfejs komunikacji z TPP poprzez:

• utworzenie dedykowanego interfejsu komunikacji (tzw. API), który będzie zawierał wszystkie niezbędne informacje i funkcje dla podmiotów świadczących usługi dostępu do rachunku, lub
• modyfikację posiadanego systemu bankowości internetowej, poprzez rozszerzenie jego funkcjonalności w zakresie możliwości identyfikowania się TPP w banku.

W opinii Urzędu Komisji Nadzoru Finansowego, z punktu widzenia zapewnienia efektywnej kontroli nad zakresem danych udostępnianych podmiotom trzecim, bezpieczniejszym rozwiązaniem jest utworzenie dedykowanego interfejsu komunikacji z TPP (komunikat UKNF odnoszący się do tematu dostosowywania się banków do wymogów Dyrektywy PSD2 można znaleźć pod adresem: https://www.knf.gov.pl/o_nas/komunikaty?articleId=60679&p_id=18 ).

Standard PolishAPI

W polskim sektorze bankowym podjęta została inicjatywa stworzenia wspólnego dla wszystkich banków standardu API. Wdrożenie ogólnokrajowego standardu API daje szansę, by – z jednej strony – banki jak najniższym kosztem zrealizowały nakładane na nie przez Dyrektywę PSD2 wymagania, z drugiej strony zaś mogły wykorzystać zmiany, jakie w obszarze płatności wprowadza Dyrektywa do kreowania nowych produktów, czy szerzej – przebudowy swoich modeli biznesowych.

Do nowych przepisów będą się musieli dostosować wszyscy uczestnicy rynku płatniczego. Warto jednak podkreślić, że wymóg pojawienia się otwartych API daje szansę, by w ramach jednego standardu, relatywnie niskim kosztem (przy okazji wymaganego przez Dyrektywę PSD2 wdrożenia API) zaoferować również usługi, które nie są wymagane przez przepisy. Z tego powodu w ramach polskiego standardu API przewidziane zostały następujące rodzaje usług:

• usługi zgodności – czyli usługi wymagane przez PSD2,

• usługi premium – czyli usługi wykraczające poza wymogi PSD2.

18 września 2018 r. opublikowana została wersja 2.1 standardu (można ją znaleźć po adresem: https://docs.polishapi.org/files/ver2.1/PolishAPI-spec-v2.1.pdf ). Każdy bank i TPP może skorzystać z PolishAPI jak z otwartego standardu. Jednocześnie korzystanie ze standardu nie jest obowiązkowe. Każdy z podmiotów działających na rynku w oparciu o dyrektywę PSD2, może stosować dowolne rozwiązanie, zgodne z PSD2 oraz powiązanymi aktami prawnymi.

Standard PolishAPI definiuje trzy kategorie podmiotów, które mogą wziąć udział w procesach w nim zdefiniowanych. Są to:

a) użytkownik rachunku płatniczego, którego dotyczy dana transakcja płatnicza, czyli klient banku (tzw. Payment Service User, PSU)

b) dostawca prowadzący rachunek płatniczy i udostępniający interfejs dla TPP, czyli m.in. bank (tzw. Account Servicing Payment Service Provider, ASPSP),

c) podmiot korzystający z interfejsu na podstawie i w ramach zgód wyrażonych przez klienta banku (tzw. Third Party Provider, TPP).

Warto podkreślić, że bank może występować również jako TPP i korzystać z interfejsów wystawionych przez inne banki, a co za tym idzie – uzyskiwać dostęp do informacji i do inicjowania transakcji na rachunkach płatniczych klientów prowadzonych przez inne banki.

W standardzie PolishAPI wyspecyfikowane zostały wymagania, jakie powinny spełniać podmioty, które z tego standardu korzystają. Przewidziano w nim m.in., że:

a) bank korzystający ze standardu PolishAPI musi wdrożyć zgodny z nim interfejs. Bank może wdrożyć również inne standardy interfejsów, nie są one jednak objęte zakresem dokumentu opisującego standard,

b) interfejsy wdrożone przez banki muszą być zgodne z PSD2, Ustawą o Usługach Płatniczych oraz aktami powiązanymi, w szczególności z RTS,

c) TPP musi być zarejestrowane w przynajmniej jednym rejestrze w kraju członkowskim Unii Europejskiej w roli, w której chce występować podczas realizacji komunikacji opartej na standardzie PolishAPI,

d) TPP oraz bank muszą posiadać ważny certyfikat, służący do wzajemnej identyfikacji w interfejsie zgodnym ze standardem PolishAPI, otrzymany od kwalifikowanego dostawcy usług zaufania, spełniającego wymogi regulacyjne w obszarze usługa zaufania oraz identyfikacji elektronicznej.

Standard PolishAPI dopuszcza dwa mechanizmy uwierzytelnienia klienta. Wybór mechanizmów pozostaje wyłącznie w gestii banku. Może to być:

• mechanizm uwierzytelniania po stronie banku – standard PolishAPI dopuszcza wykorzystanie mechanizmu uwierzytelniania po stronie banku, zakładającego przekierowanie na stronę internetową banku podczas realizowania usług AIS, PIS i CAF, co oznacza, że dane uwierzytelniające i autoryzacyjne klienta podawane są wyłącznie na stronie internetowej banku, lub

• mechanizm uwierzytelniania w zewnętrznym narzędziu autoryzacyjnym – standard PolishAPI dopuszcza wykorzystanie mechanizmu uwierzytelniania w zewnętrznym narzędziu autoryzacyjnym podczas realizowania usług AIS i PIS, co oznacza, że dane uwierzytelniające i autoryzacyjne klienta podawane są w zewnętrznym narzędziu autoryzacyjnym. Jest to narzędzie, którego minimalną funkcjonalnością jest zdolność do przeprowadzenia silnego uwierzytelnienia klienta, w rozumieniu technicznych wymogów dyrektywy PSD2.

W standardzie mogą zostać opisane inne, spełniające wymogi regulacyjne mechanizmy uwierzytelniania. Publikowane one będą w kolejnych wersjach dokumentu opisującego standard PolishAPI.

Zgodnie z PSD2, TPP może wykonywać usługi na rzecz klienta jedynie za jego zgodą i w zakresie objętym tą zgodą. W związku z tym w standardzie PolishAPI zdefiniowane zostały ramy udzielania oraz odwoływania zgód przez klienta oraz opisany został proces udzielania zgody klienta na wykonanie usługi PIS i AIS.

Według założeń standardu PolishAPI banki mogą korzystać z dowolnego wybranego przez siebie systemu silnego uwierzytelnienia klienta ( Strong Customer Authentication – SCA), a standard nie definiuje ani nie rekomenduje żadnego ze sposobów przeprowadzania tej procedury. Ponadto, decyzja o zwolnieniu danej transakcji z obowiązku realizacji procedury SCA pozostaje w wyłącznej gestii banku.

Na mocy Dyrektywy PSD2 oraz powiązanych aktów prawnych każdy bank jest zobowiązany do udostępniania usług w zakresie zgodności. Realizacja tych usług nie wymaga relacji umownej pomiędzy bankiem a TPP.

Każdy bank sam podejmuje decyzję o udostępnianiu usług w zakresie premium oraz – w przypadku decyzji o rozpoczęciu ich oferowania – kształtuje ich zakres. Realizacja usług w zakresie premium wymaga relacji umownej pomiędzy bankiem a TPP.

W interfejsie API bank udostępnia rachunki płatnicze, tj. takie, które spełniają łącznie dwa kryteria:

• rachunek prowadzony dla jednego lub większej liczby użytkowników służący do wykonywania transakcji płatniczych (zgodnie z definicją UUP),

• klient posiada dostęp do rachunku online.

Obecnie standard PolishAPI definiuje zakres zgodności dla usług AIS, PIS i CAF. Zakłada się stały rozwój standardu w odpowiedzi na zmiany regulacyjne, technologiczne i biznesowe na rynku polskim oraz europejskim. Zmiany będą publikowane jako kolejne wersje specyfikacji standardu PolishAPI.

W zakresie założeń technicznych zakres PolishAPI specyfikuje m.in.:

• sposób wyrażenia zgody na wykonywanie przez TPP operacji w imieniu klienta,

• zakres operacji i uprawnień,

• adres internetowy pod jakim dana usługa jest dostępna,

• standardowy zakres parametrów w podziale na usługi,

• mechanizmy zabezpieczeń,

• zasady komunikacji,

• obsługę błędów.

Równocześnie PolishAPI nie specyfikuje m.in.:

• pełnego zakresu funkcjonalności, które mają być udostępnione przez banki oraz które z nich będą w usługach zgodności,

• pełnej specyfikacji pól w podziale na usługi dla każdego banku,

• opisu infrastruktury klucza publicznego wykorzystywanej na potrzeby uwierzytelnień stron.

W dokumencie opisującym standard PolishAPI zawarte zostały także ogólne wymagania bezpieczeństwa, istotne z punktu widzenia kreowania standardu oraz projektowania na jego podstawie ekosystemu rozwiązań informatycznych zgodnych z PolishAPI. Szczegółowe wymagania bezpieczeństwa, obejmujące dodatkowo kwestie bezpieczeństwa implementacji, operacji i utrzymania systemów opartych na PolishAPI zostaną opisane w oddzielnym dokumencie, a jego opracowanie zostanie poprzedzone przygotowaniem szczegółowego modelu zagrożeń. Będą zatem odpowiedzią na zidentyfikowane konkretne zagrożenia, miejsca potencjalnej materializacji tych zagrożeń, a także ocenę poziomu istotności oraz prawdopodobieństwa i wpływu przypadków materializacji zagrożeń na bezpieczeństwo i ciągłość działania ekosystemu PolishAPI.

Podmioty TPP muszą zostać poprawnie uwierzytelnienie przed udzieleniem im dostępu do interfejsu działającego w standardzie PolishAPI tak, aby zapewnić wysoki poziom ochrony zarówno przed podszyciem się nieuprawnionych podmiotów pod TPP, jak i przed nieuprawnioną eskalacją poziomu autoryzacji przez TPP mających legalny dostęp do interfejsu. Uwierzytelnienie następuje w oparciu o certyfikaty klucza publicznego w procesie wzajemnego uwierzytelnienia, a błędy uwierzytelnienia muszą skutkować odmową dostępu do interfejsu.

Implementacja standardu PolishAPI powinna uwzględniać mechanizmy ochrony przez nadmiarem żądań ze strony użytkowników (uprawnionych i nieuprawnionych), w szczególności celowo wygenerowanych z zamiarem spowodowania niedostępności zasobu (DoS/DDoS), przez zastosowanie mechanizmów limitujących liczbę obsługiwanych żądań w jednostce czasu.

Nowe modele biznesowe w kontekście rozwiązań Dyrektywy PSD2

Sprostanie przez banki, w tym w szczególności banki spółdzielcze, obowiązkom nałożonym na nie przez Dyrektywę PSD2 i RTS’y, to nie tylko kwestia regulacyjna. Jeszcze bardziej donośnym skutkiem omawianych zmian może być powstawanie nowych modeli biznesowych. Wdrażanie Dyrektywy PSD2 może skutkować, w bankach spółdzielczych, niedostatecznie przygotowanych do tych zmian, istotnym ryzykiem osłabienia, bądź nawet utraty relacji z dotychczasowymi klientami na rzecz innych banków, które w ramach swoich systemów bankowości internetowej, będą zdolne udostępniać klientom, także banków spółdzielczych, informacje oraz realizację płatności z rachunków prowadzonych dla tych klientów dotychczas przez banki spółdzielcze. Co więcej, zjawisko to spodziewane jest także przy wzrastającym udziale lub na rzecz podmiotów już dziś wchodzących agresywnie w obszary zarezerwowane dotychczas dla banków (fintech).

Banki komercyjne oraz inne podmioty rynku płatniczego widzą możliwości szerszego rozwoju usług niż tylko w zakresie zgodności z przepisami. Ponieważ wszelkie inne usługi niż usługi zgodności będą wymagały relacji prawnej między podmiotami, w celu uproszczenia mechanizmów możliwe jest podpisanie umów zarówno przez banki, jak i TPP z podmiotem pośredniczącym (tzw. hubem). Taki mechanizm pozwoliłby uprościć model, zarządzanie API i sposób rozliczania między stronami, a w przyszłości ułatwiłby integrację z innymi standardami w Europie.

Dla banków spółdzielczych ewentualne skorzystanie z rozwiązania przygotowywanego przez hub oznaczałoby brak konieczności przygotowywania własnych rozwiązań w tym zakresie, a więc możliwość rezygnacji z własnych, kosztownych platform API i wykorzystanie usług huba w celu doprowadzenia do stanu zgodności z PSD2.

Ustawa zmieniająca ustawę o usługach płatniczych oraz niektórych innych ustaw (Dz.U. z 2018 r., poz. 1075), na mocy której do krajowego porządku prawnego zostały wdrożone przepisy dyrektywy PSD2, została uchwalona w dniu 10 maja br. i weszła w życie 20 czerwca br. Zgodnie z nią dostawcy usług płatniczych prowadzący w dniu wejścia w życie ustawy działalność w zakresie usług płatniczych są obowiązani w terminie 6 miesięcy od dnia jej wejścia w życie dostosować swoją działalność w zakresie usług płatniczych do przepisów ustawy. Wskazany termin upłynie 20 grudnia br. Wśród nowych obowiązków nałożonych na banki należy wymienić przede wszystkim obowiązek porozumiewania się z dostawcami świadczącymi usługę AIS oraz PIS, zgodnie z wymogami określonymi w RTS’ach w zakresie dotyczącym silnego uwierzytelniania klienta i wspólnych, bezpiecznych otwartych standardów komunikacji. Banki będą obowiązane umożliwić dostawcy świadczącemu usługę inicjowania transakcji płatniczej i dostawcy świadczącemu usługę dostępu do informacji o rachunku świadczenie przez nich usług w oparciu o tzw. silne uwierzytelnienie, stosowane dotychczas w relacji między klientem a bankiem.

O ile przepisy dotyczące nowych usług zaczną obowiązywać już za chwilę, o tyle wymogi dotyczące spełnienia standardów bezpiecznej komunikacji i silnego uwierzytelnienia banki są obowiązane spełnić dopiero od dnia 14 września 2019 r. Przed upływem tego terminu, dostawcy usług płatniczych będą stosować dotychczasowe przepisy w zakresie bezpieczeństwa płatności. Warto przy tym jednak dodać, iż czasu na dostosowanie się do wymogów nałożonych na banki przez Dyrektywę PSD2 i RTS’y pozostało mniej, gdyż część wymogów z Regulacyjnych Standardów Technicznych wejdzie w życie pół roku wcześniej. Dotyczy to wymagania, by już w marcu 2019 r. banki udostępniły tak zwane „środowisko testowe”, służące do weryfikacji połączenia i funkcjonalności, aby umożliwić TPP usługę inicjowania płatności. Wtedy też banki zostaną zobowiązane do zaprezentowania dokumentacji technicznej swojego oprogramowania tak, aby można ją było dopasować do innych podmiotów na rynku.

Dostrzegając wagę tego tematu dla sektora bankowości spółdzielczej Krajowy Związek Banków Spółdzielczych włączył się w prace nad stworzeniem standardu PolishAPI. W przygotowaniu standardu brali także udział przedstawiciele obu banków zrzeszających. Poza uczestnictwem przedstawicieli KZBS w grupach roboczych dedykowanych przygotowaniu polskiego standardu API, Związek brał także udział w konsultacjach rządowych dotyczących kierunków implementacji Dyrektywy PSD2 do polskiego porządku prawnego, zainicjowanych przy Ministerstwie Finansów. KZBS podejmuje również działania edukacyjne i informacyjne w zakresie Dyrektywy PSD 2, mające na celu jak najbardziej rzetelne i pełne przedstawienie bankom spółdzielczym wdrażanych zmian i ich skutków na modele biznesowe banków spółdzielczych, w tym w szczególności na relacje z klientami. W pierwszej połowie przyszłego roku planowane są kolejne szkolenia dotyczące tej tematyki, do udziału w których już teraz zapraszamy przedstawicieli wszystkich banków spółdzielczych.

Jacek Rapcia

Autor jest doradcą Prezes Zarządu KZBS. Od ponad 25 lat związany z sektorem bankowym, w którym odpowiadał za modele biznesowe, strategie i finanse. Był m.in. Wiceprezesem Zarządu KIR, dyrektorem zarządzającym PKO BP, dyrektorem departamentu w BPH i PBK, kierownikiem zespołu w Banku Handlowym, członkiem rad nadzorczych w Kredobanku i internetowym banku Inteligo.

Artykuł został opublikowany w numerze 5/2018 „Głosu Banków Spółdzielczych”.

Czasopismo jest dostępne w  prenumeracie.