czwartek, Listopad 14

Zwolnienie z obowiązku stosowania środków awaryjnych (fallback mechanism) w świetle wytycznych EBA

Google+ Pinterest LinkedIn Tumblr +

Open Banking to duże wyzwanie dla banków, które muszą przygotować się na “przyjęcie” tzw. Third Party Providers (TPP) do swoich systemów. Rozporządzenie 2018/389 przewiduje obowiązek udostępnienia podmiotom trzecim, m.in. Account Information Service Providers (AISP) oraz Payment Initiation Service Providers (PISP), specjalnego interfejsu dostępowego (OpenAPI, o czym pisałem tutaj). W przypadku awarii konieczne jest wprowadzenie odpowiednich środków, które umożliwiają tym dostawcom dostęp do interfejsu banku, aby zapewnić ciągłość usług dla klientów. Jednym z takich środków jest obowiązek udostępnienia interfejsu, który jest w normalnych warunkach dostępny dla użytkowników rachunków banku. Jednocześnie przepisy przewidują, że KNF po konsultacji z Europejskim Urzędem Nadzoru Bankowego może zwolnić z tego obowiązku, o ile interfejs spełnia określone warunki (art. 33 ust. 6 Rozporządzenia 2018/389). Jakie to warunki?

Wyżej wskazany art. 33 ust. 6 jest bardzo ogólny i dlatego trudno wyinterpretować z niego o jakie dokładnie warunki chodzi. Z pomocą przychodzą niedawno opublikowane wytyczne EBA, które stanowią wskazówkę dla organów nadzoru, jak i banków, odnośnie elementów koniecznych do spełnienia, aby takie zezwolenie uzyskać.

Cztery podstawowe warunki

Aby w ogóle uzyskać zezwolenie, interfejs dostępowy banku musi spełniać cztery podstawowe warunki:

  1. musi być dostosowany do wymogów podstawowych Rozporządzenia 2018/389;
  2. został opracowany i przetestowany przez TPP;
  3. jest dostępny od co najmniej trzech miesięcy i jest powszechnie stosowany przez TPP;
  4. wszelkie problemy związane z dostępem do interfejsu rozwiązano bez zbędnej zwłoki.

Jak więc widać są to bardzo ogólne warunki, które zostały uszczegółowione w wytycznych. Ich spełnienie jest warunkiem uzyskania zwolnienia. To na banku ciąży obowiązek dostarczenia wszystkich niezbędnych informacji w tym zakresie.

Dostępność, efektywność oraz poziom usługi

Generalnie, interfejs dostępowy musi zapewniać taki sam poziom dostępności jak interfejs z którego korzystają użytkownicy rachunków bankowych. W celu utrzymania tego poziomu konieczne jest określenie tzw. Key Performance Indicators (KPIs) oraz docelowych poziomów usługi, które pozwolą na monitorowanie spełnienia tego wymogu. Te KPIs w odniesieniu do dostępności powinny obejmować co najmniej: (i) czas, w którym interfejs był dostępny (uptime); (ii) czas, w którym interfejs nie był dostępny (w ujęciu dziennym) (downtime).

Tzw. downtime liczyć należy jako wyrażony procentowo stosunek do czasu kiedy interfejs był dostępny dla TPP. Wytyczne precyzują również kiedy taki downtime występuje. Jest to sytuacja, w której na pięć kolejnych żądań ze strony TPP interfejs nie udzielił odpowiedzi w czasie 30 sekund. Przy czym nie ma tutaj znaczenia, czy dane żądanie pochodzi od jednego czy więcej TPP.

Z kolei w celu monitorowania efektywności bank powinien ustalić następujące KPIs:

  1. dzienny średni czas niezbędny na zwrócenie jednego żądania udostępnienia niezbędnych informacji (z podziałem na poszczególne usługi, czyli ile czasu (w milisekundach) zajęło uzyskanie dostępu do informacji niezbędnych do wykonania usługi przez TPP;
  2. dzienny wskaźnik odpowiedzi na błędy “wyrzucane” przez interfejs dostępowy, a więc błędy przypisane bankowi.

Samo monitorowanie to jeden element. Bank musi również spełnić dodatkowe obowiązki w zakresie publikowania statystyk (kwartalnych) na swojej stronie internetowej. Wiążę się z tym również konieczność przekazania KNF planu takich publikacji, w tym ze wskazaniem daty pierwszej publikacji. Ze względu na publikacja tych statystyk ma m.in. umożliwić porównanie dostępności interfejsów dla TPP z interfejsami dla użytkowników rachunków, takie informacje również powinny znaleźć się w dokumencie.

Stress-testy

Interfejs musi zostać odpowiednio przetestowany, w szczególności w warunkach licznych (extremely high) jednorazowych zapytań ze strony TPP. Takie testy powinny uwzględniać weryfikację zdolności interfejsu do:

  1. przyznania dostępu dużej liczbie TPP;
  2. obsłużenia bardzo dużej liczy zapytań w krótkim czasie i bez utraty zdolności do ich normalnego funkcjonowania;
  3. obsłużenia bardzo dużej liczby otwartych sesji dla TPP (w jednym czasie);
  4. zwrócenia dużej liczby danych na żądanie.

Wprawdzie wytyczne jak i Rozporządzenie 2018/389 milczą w sprawie okresów w jakich takie testy powinny zostać przeprowadzone, to jednak wobec konieczności ich oparcia o ww. KPIs, oczywistym wydaje się, że powinny odbywać się one przynajmniej raz na kwartał. Bank po ich przeprowadzeniu jest obowiązany do przekazania KNF odpowiedniego podsumowania zawierającego m.in. założenia, którymi się posłużył oraz w jaki sposób rozwiązano ewentualne zidentyfikowane błędy (szczególnie w przypadku aplikowania o zwolnienie)

Brak przeszkód

Jednym z obowiązków ciążących na banku jest nietworzenie przeszkód dla TPP w dostępie do interfejsu, w szczególności nie bank nie może wymuszać na TPP stosowania metody redirection, czyli przekierowania do interfejsu uwierzytelniającego dostępnego dla klientów.

W celu uzyskania zezwolenia bank powinien przekazać KNF zestawienie metod, które stosuje w celu uwierzytelnienia swoich klientów, a także wyjaśnić w jaki sposób te metody nie tworzą bariera dla TPP. W szczególności bank musi wykazać, że interfejs dostępowy nie powoduje dodatkowych opóźnień w zwracaniu wyników czy też nie powoduje innych utrudnień w dostępie dla użytkowników. Bank musi więc wykazać m.in. że nie wymaga dodatkowych rejestracji/uwierzytelnień ze strony TPP (oczywiście z wyłączeniem tych dotyczących przykładowo identyfikacji TPP względem banku), czy też zgód, które mogłyby wydłużyć cały proces.

Satysfakcja TPP oraz testy

Innym elementem, który jest z tym powiązany jest konieczność przekazywania KNF informacji odnośnie spełnienia przez interfejs dostępowy wszystkich wymogów określonych w PSD2 oraz głównie Rozporządzeniu 2018/389. Takie podsumowanie powinno zawierać m.in. opis techniczny i funkcjonalny interfejsu, jak również wyraźne określenie jak spełniają one ww. wymogi prawne. Taka informacja powinna również zawierać dane odnośnie współpracy banku z TPP.

Bardzo istotny z punktu widzenia banku jest punkt 6.3 wytycznych EBA. Jeżeli bank zdecyduje się na implementowanie któregokolwiek ze standardów OpenAPI, jak np. NextGenPSD2 czy PolishAPI, to dzięki takiemu rozwiązaniu informacje, o których mowa powyżej można de facto ograniczyć do wskazania, w których obszarach nastąpiło odstępstwo.

Ważne jest również przeprowadzenie testów z TPP. Z tego względu niezwykle istotne jest udostępnienie specyfikacji technicznej umożliwiającej upoważnionym dostawcom przygotowanie własnych interfejsów. Taka specyfikacja powinna zostać opublikowana na stronie internetowej banku (i nie później niż 14 marca 2019 r.). Podobnie sprawa ma się z koniecznością udostępnienia środowiska testowego. Takie środowisko, które umożliwia testowanie na danych niebędących danymi realnych użytkowników, powinno opierać się na stabilnymi i bezpiecznym połączeniu umożliwiającym wymianę certyfikatów (eIDAS – w kolejnym artykule), a także wysyłanie i odbieranie raportów o błędach. Środowisko musi umożliwiać realne testowanie usług i wymianę danych zgodnie z art. 36 Rozporządzenia 2018/389.

Innymi słowy, powinno stwarzać realne warunki do przetestowania usług świadczonych przez TPP. Przy ocenie, czy warunek został spełniony, KNF może korzystać z informacji przekazywanych przez TPP w kontekście ewentualnych raportów. Oczywiście podstawą będzie podsumowanie przekazane przez bank i zawierające odniesienie się do każdego z testowanych elementów.

Powszechnie stosowany

Interfejs dostępowy powinien być powszechnie dostępny i testowany przez TPP przez okres co najmniej trzech miesięcy. Bank powinien przedstawić KNF podsumowanie, w którym wykaże poziom wykorzystania interfejsu w tym okresie, który to poziom obejmuje m.in. ilość TPP (z podziałem na kategorie) która korzystała z API, ilość wysłanych żądań wraz z odpowiedziami interfejsu. Podsumowanie musi również zawierać informacje odnośnie środków, które bank podjął w celu zapewnienia “powszechnego dostępu” do interfejsu, m.in. poprzez komunikowanie faktu jego udostępnienia na stronie internetowej, z użyciem social media czy podczas konferencji. Dla banku istotne jest również, że ten okres trzymiesięczny może biec równocześnie z udostępnieniem środowiska testowego w okresie 14.03-14.09.2019 r.

Problemy rozwiązane bez zbędnej zwłoki

Ostatnim elementem podlegającym ocenie przez KNF jest to w jaki sposób bank reagował na ewentualne problemy z interfejsem dostępowym. W tym celu bank musi przygotować informację odnośnie procedur i systemów, które stosuje w celu wykrywania, rozwiązywania i “zamykania” ewentualnych problemów, a w szczególności tych, które zaraportowane zostały przez TPP. Podsumowaniu musi towarzyszyć wyjaśnienie jakie problemy nie zostały ewentualnie rozwiązane.

I jeszcze kilka słów o procedurze

Wyłączenie może nastąpić po wydaniu stosownej decyzji przez KNF po konsultacji z EBA (wysyłany jest specjalny dokument – assessment form). EBA może zgłosić zastrzeżenia lub “milczeć”. Jeżeli nastąpiło to drugie, zwolnienie może zostać wydane po upływie jednego miesiąca. Ogólnie brakuje na tą chwilę wytycznych KNF w jaki sposób będzie przebiegała cała procedura oraz jak Urząd będzie podchodził do tych kryteriów (w szczególności czy określi niektóre parametry testów lub KPIs). Należy oczekiwać, że taki dokument się pojawi, choć nie należy raczej oczekiwać, że nastąpi to wcześniej niż w 2-3 kwartale 2019 r.

 

Udostępnij.