Unijna dyrektywa: Nowe standardy i duże zamieszanie

Choć unijne regulacje są już dawno przygotowane, to do końca nie jest pewne jak finalnie mają działać. To problem dla banków, które muszą przygotowywać procedury, systemy informatyczne i testować aplikacje, ale niektóre wytyczne techniczne zmieniają się jeszcze w ostatniej chwili. Dla klientów będzie to oznaczać dużo nowości. Firmy pozabankowe, ale również i banki (działające jako podmiot trzeci, tzw. TPP) będą mogły świadczyć usługi inicjowania płatności (PIS) lub usługi dostępu do informacji o rachunku (AIS) wykorzystując dane klienta banku (ale tylko za jego zgodą). Zmiana jest przełomowa, bo po raz pierwszy dane bankowe, które do tej pory były szczelnie chronione będą mogły wyjść poza system bankowy.

Podstawowym sposobem udostępniania tych danych jest tzw. API (specjalny interfejs, za pomocą którego bank komunikuje się z TPP), które praktycznie eliminuje możliwość ujawnienia danych dostępowych klienta do systemu bankowości elektronicznej. Pozostają one znane wyłącznie klientowi i bankowi. Przed wprowadzeniem regulacji dotyczących świadczenia usług przez TPP, usługi tego typu świadczone były w taki sposób, że w procesie ich wykonywania klient podawał takiej firmie dane dostępowe do bankowości elektronicznej (tzw. metoda screen scrapingu). W Polsce, przede wszystkim na skutek działań samoregulujących banków oraz ogólnych zaleceń i rekomendacji Komisji Nadzoru Finansowego, korzystanie z tego mechanizmu zostało praktycznie wykluczone.

Dlatego nad standardem API długo i żmudnie pracowali bankowcy w ramach specjalnego zespołu przy Związku Banków Polskich. Jak tłumaczy Urząd Komisji Nadzoru Finansowego, API są skonstruowane również w taki sposób (wymuszając na TPP identyfikację i "wylegitymowanie się" certyfikatem), że bank, w którym klient posiada rachunek płatniczy dostępny on-line, jest w stanie określić, czy logowanie do systemu bankowości elektronicznej wykonywane jest bezpośrednio przez klienta (przez podstawowy interfejs dostępowy) czy też klient loguje się do niego za pośrednictwem podmiotu trzeciego (TPP).

Jednak w dyrektywie PSD2 i w jej technicznych wytycznych przeforsowano również mniej bezpieczny wariant awaryjny czyli tzw. interfejs zapasowy, na wypadek gdyby podstawowy (czyli API) nie zadziałał. Na szczęście banki mogą być zwolnione z obowiązku wystawiania takiego mniej bezpiecznego narzędzia, a decyzję czy tak można zrobić podejmuje KNF. Pytane przez nas duże banki potwierdzają, że starają się o zwolnienie z konieczności wystawiania interfejsu zapasowego.

Dlaczego chcą tego za wszelką cenę uniknąć? Bo w skrócie łamałoby to podstawową zasadę, czyli nieudostępniania haseł i loginów osobom czy podmiotom trzecim.

Jednak bankowcy przyznają, że w związku z bardzo późnym wydawaniem potrzebnych wytycznych na poziomie europejskim, wciąż muszą "na wszelki wypadek" równolegle pracować zarówno nad testowaniem API jak i przygotowywać się do wystawienia interfejsu zapasowego.

- Jest z tym duża trudność, ponieważ warunek jest taki, że API ma być szeroko testowane. Tymczasem banki, które je wystawiły są w gotowości, ale na razie nie ma chętnych firm TPP, które by chciały wykonać usługę przy wykorzystaniu tego API, a tylko wówczas można byłoby sprawdzić czy to w realu działa, a jeśli są ujawniłyby się błędy, to je poprawić - mówi jeden z bankowców. Podobny dylemat mają też inni rozmówcy.

Większość dużych banków wystawiała tzw. API produkcyjne (nie zrobiły tego PKO BP, który na razie testuje to narzędzie wewnętrznie i ING Bank Śląski). Te banki jednak, które wystawiły i tak mówią, że na razie trudno mówić o rzeczywistym sprawdzaniu w praktyce.

Dlaczego tak ważne jest by banki nie musiały wystawiać interfesju zapasowego czyli takiego, w którym firma zewnętrzna bezpośrednio zagląda na konto klienta?

Opcja fallback polega na tym, że bank, w przypadku nieplanowanej niedostępności lub awarii dedykowanego API, na potrzeby uwierzytelniania i komunikacji z TPP, umożliwia mu korzystanie z kanałów dostępu do bankowości elektronicznej udostępnionych klientom.

W skrócie można powiedzieć tak: to dużo większe ryzyko wystąpienia sytuacji, że jeśli w posiadanie danych wejdzie TPP to może nastąpić ich wyciek i wówczas będą one "krążyć" po świecie.

Jeśli będą to mało wrażliwe dane np. jedna dana z historii transakcji to jeszcze pół biedy, ale gorzej jeśli podmiot trzeci wszedłby w posiadanie kluczowych danych np. dostępowych.

Dlatego według polskiego nadzorcy, jeżeli w wyniku zastosowania opcji fallback doszłoby do ujawnienia jakimkolwiek podmiotom trzecim, w tym TPP, danych uwierzytelniających użytkownika (wielorazowego hasła dostępowego), dane te powinny być traktowane jako skompromitowane, a przy próbie następnego logowania bank powinien wymusić zmianę tych danych przez klienta.

Monika Krześniak-Sajewicz

O tym jak ma działać API i dlaczego zarówno bankom jak i nadzorowi zależy na tym, by banki nie musiały używać procedury zapasowej, czyli tzw. fallback opowiada Katarzyna Maja Tomaszewska - specjalistka w Departamencie SKOK i Instytucji Płatniczych UKNF.

Monika Krześniak-Sajewicz, Interia: Zgodnie z drugą dyrektywą w sprawie usług płatniczych, podmioty zewnętrzne (TPP) będą mogły za zgodą klienta pobierać dane dotyczące jego rachunku bankowego, np. mieć wgląd w historię transakcji, w podstawowym wariancie przez API. Jak to będzie działać?

Katarzyna Maja Tomaszewska, specjalista w Departamencie SKOK i Instytucji Płatniczych UKNF: - Zacznijmy od tego, czym są TPP i jaka jest ich rola. TPP, z j. ang. Third Party Providers, to podmioty trzecie, które na zlecenie klienta i wyłącznie z jego upoważnienia, za pośrednictwem Internetu, w tym infrastruktury bankowości elektronicznej, uzyskują dostęp do prowadzonego on-line rachunku płatniczego (bankowego) klienta w celu wykonania m.in. usługi inicjowania płatności (PIS) lub usługi dostępu do informacji o rachunku (AIS).

- Mówiąc o API, trzeba podkreślić, że stosowanie przez bank specjalnego interfejsu, za pomocą którego komunikuje się on z TPP, praktycznie eliminuje możliwość ujawnienia danych dostępowych klienta do systemu bankowości elektronicznej. Pozostają one znane wyłącznie klientowi i bankowi. Przed wprowadzeniem regulacji dotyczących świadczenia usług przez TPP, usługi tego typu świadczone były w taki sposób, że w procesie ich wykonywania klient podawał TPP dane dostępowe do bankowości elektronicznej (tzw. metoda screen scrapingu). W Polsce, na skutek działań edukacyjnych i samoregulujących banków oraz ogólnych zaleceń i rekomendacji nadzoru, korzystanie z tego mechanizmu zostało praktycznie wykluczone.

- Co do zasady, API ma więc służyć uniknięciu sytuacji, w której klient ujawnia swój login i hasło (dane dostępowe) osobie trzeciej. Dodatkowo służyć ma wystandaryzowaniu kanału komunikacyjnego pomiędzy różnymi TPP a bankiem. API są skonstruowane również w taki sposób (wymuszając na TPP identyfikację i "wylegitymowanie się" certyfikatem), że bank, w którym klient posiada rachunek płatniczy dostępny on-line, jest w stanie określić, czy logowanie do systemu bankowości elektronicznej wykonywane jest bezpośrednio przez klienta (przez podstawowy interfejs dostępowy) czy też klient loguje się do niego za pośrednictwem TPP.

Czy UKNF zakłada, że na polskim rynku dominującą metodą będzie przekazywanie danych przez API i banki są do tego przygotowane w wystarczającym stopniu, by nie trzeba było korzystać z tzw. opcji fallback?

- Opcja fallback polega na tym, że bank, w przypadku nieplanowanej niedostępności lub awarii dedykowanego API, na potrzeby uwierzytelniania i komunikacji z TPP, umożliwia mu korzystanie z kanałów dostępu do bankowości elektronicznej udostępnionych klientom. Chodzi o to, żeby dostęp TPP do rachunku płatniczego klienta prowadzonego przez bank był stale na takim samym poziomie dostępności i efektywności jaki daje dedykowany API.

- Zasadą wypracowaną przez polski sektor bankowy i nadzór jest nieudostępnianie danych uwierzytelniających komukolwiek. Z tych względów wszystkie banki w Polsce, aby zapewnić bezpieczną komunikację z TPP, powinny udostępnić specjalny interfejs dostępowy - API. Tak jak wspomniałam, zastosowanie API pozwoli, co do zasady, na uniknięcie sytuacji w której dane dostępowe do bankowości elektronicznej ujawnione zostaną osobie trzeciej.

- Z danych ogólnodostępnych (m.in. strona PolishAPI), jak i informacji roboczych przekazywanych przez banki w kontaktach roboczych z UKNF wynika, że banki w Polsce będą stosowały API i są do tego przygotowane, z powodzeniem przeprowadzają testy interfejsów, jednocześnie udostępniając je podmiotom TPP do użytkowania w tzw. fazie produkcyjnej. Na podstawie informacji otrzymanych od banków, brak jest zgłoszeń wskazujących na awaryjność API, która powodowałaby konieczność używania tzw. opcji fallback przez banki, które będą udzielać informacji na zapytania TPP.

- W Polsce funkcjonują dobrze rozwinięte, nowoczesne kanały dystrybucji usług finansowych, szczególnie w odniesieniu do bankowości elektronicznej i mobilnej, o czym wspomniałam już wcześniej. Funkcjonalność i operacyjność tych rozwiązań w powiązaniu z dostępnymi na rynku usługami dodatkowymi takimi jak np. płatności natychmiastowe, wydają się w dużym stopniu zaspokajać potrzeby klientów w zakresie świadczenia usług płatniczych on-line. Z tego względu raczej za mało prawdopodobne należy uznać, że zainteresowanie usługami TPP w Polsce będzie na tyle powszechne, by udostępnione przez banki API miały problemy z obsługą połączeń z TPP lub by, w związku z nieoczekiwaną niedostępnością czy awarią API, banki nieposiadające zwolnienia z obowiązku stosowania tzw. opcji fallback, musiały regularnie tę opcję udostępniać.

- W komunikacie z 1 lipca br. w sprawie zwolnienia banków ze stosowania tzw. opcji fallback, Urząd KNF określił zasady jakie powinny być stosowane przez banki umożliwiające TPP uzyskanie dostępu do rachunków płatniczych klientów poprzez interfejsy użytkowe klientów, a nie dedykowane API. Banki powinny zapewnić, aby TPP korzystający z opcji fallback był za każdym razem należycie zidentyfikowany i uwierzytelniony stosownym certyfikatem elektronicznym. Ponadto, jeżeli w wyniku zastosowania opcji fallback doszłoby do ujawnienia jakimkolwiek podmiotom trzecim, w tym TPP, danych uwierzytelniających użytkownika (wielorazowego hasła dostępowego), dane te powinny być traktowane jako skompromitowane, a przy próbie następnego logowania bank powinien wymusić zmianę tych danych przez klienta.

Jakie są główne zagrożenia związane z opcją fallback?

- W mojej ocenie, głównym zagrożeniem jest ewentualne nieautoryzowane użycie skompromitowanych danych dostępowych klienta (dane logowania np. numer klienta i wielorazowe hasło), które ten ujawnił w związku z korzystaniem przez TPP z tzw. opcji fallback. Dlatego też, ważne jest, aby klient wiedział czy komunikacja między bankiem a TPP odbywa się za pośrednictwem specjalnego API, czy też dane uwierzytelniające podawane są przy zastosowaniu rozwiązań opcji fallback - bezpośrednio TPP.

Jakie są podstawowe warunki zwalniające bank z konieczności wdrożenia tzw. opcji fallback? Czy wszystkie polskie banki o to wystąpiły w wymaganych terminach? Kiedy będzie wiadomo, które banki nie muszą go wystawiać?

- Warunki dotyczące możliwości uzyskania zwolnienia z konieczności wdrożenia przez bank tzw. opcji fallback zostały określone w unijnym rozporządzeniu dotyczącym silnego uwierzytelniania klienta i bezpiecznych i otwartych standardów komunikacji. Zgodnie z tym rozporządzeniem KNF może takiego zwolnienia udzielić bankowi, jeśli spełnione zostaną następujące warunki:

1) stosowane API spełnia wszystkie określone w przepisach rozporządzenia SCA obowiązki dotyczące specjalnych interfejsów;

2) API został opracowany i przetestowany w sposób zadowalający TPP ;

3) od co najmniej trzech miesięcy API jest powszechnie stosowany w celu świadczenia usług płatniczych przez TPP;

4) wszelkie problemy związane z API rozwiązano bez zbędnej zwłoki.

- Wymogi te muszą być spełnione łącznie.

- Spełnienie tych wymagań nie musi być łatwe, zwłaszcza jeżeli bank nie odnotowuje zainteresowania swoich klientów, dla których prowadzi rachunki płatnicze, korzystaniem z usług AIS lub PIS. Należy przy tym zaznaczyć, że dotychczas nie mamy informacji o istotnej aktywności TPP na rynku polskim.