Nie taki diabeł straszny, czyli komunikat KNF w sprawie zwolnienia z obowiązku stosowania mechanizmu awaryjnego (API)

Komisja Nadzoru Finansowego opublikowała wczoraj bardzo wyczekiwany komunikat w sprawie zwolnienia z obowiązku ustanawiania tzw. mechanizmu awaryjnego (fall-back mechanism). Ma to ścisły związek z masowym uruchomianiem środowisk produkcyjnych API (Application Programming Interface), o którym pisałem m.in. tutaj. Nie będę zagłębiał się w podstawowe kwestie dotyczące mechanizmu awaryjnego (zainteresowane osoby zapraszam do przeczytania tego artykułu), natomiast skupię się na analizie samego komunikatu i tego jakie konsekwencje niesie on dla sektora bankowego. Komunikat jest raczej pozytywny przekaz, choć dla niektórych może być przysłowiowym „kijem w mrowisko”. Dlaczego? Zapraszam do lektury.

Po pierwsze art. 33 ust. 6 Rozporządzenia 2018/389 oraz wytyczne EBA w sprawie zwolnienia z obowiązku stosowania fall-back mechanism. KNF wyraźnie wskazał jakie ma oczekiwania wobec dostawcy usług płatniczych, który ma obowiązek wystawienia specjalnego interfejsu dostępowego (lub interfejsu użytkownika, ale w takiej sytuacji nie rozważamy w ogóle opcji fall-back). Te warunki zostały określone w przytoczonym już art. 33 ust. 6 oraz wytycznych i jest to m.in. API aktywne od trzech miesięcy czy „bezproblemowość” tego interfejsu.

W jaki sposób można uzyskać zwolnienie?

Tutaj mamy właśnie największe wyzwanie. UKNF potwierdził to o czym pisałem w czerwcu (dokładnie tutaj), że zwolnienie będzie udzielane przez KNF w drodze decyzji i zastosowaniem postępowania administracyjnego (wnioskowego). W tym kontekście UKNF wyraźnie wskazał, że przepisy Rozporządzenia 2018/389 stosuje się od 14 września 2019 r. (art. 38 ust. 2), a więc aby mówić o skutecznym złożeniu wniosku o zwolnienie, musiałoby ono nastąpić po 13 września 2019 r.

Faktem jest, że przepisy Rozporządzenia 2018/389 rozróżniają datę wejścia w życie (zgodnie z art. 38 ust. 1 – 14 marca 2018) oraz termin, od którego się je stosuje (14 września 2019 r. – z wyłączeniem tzw. testowego API, które powinno zostać uruchomienie 14 marca 2019 r.).

Czy to właściwa interpretacja?

Trudno jednoznacznie określić. Czytając te wyjaśnienia (w zupełnie innej sprawie) można nabrać pewnych wątpliwości. Można bowiem dojść do wniosku, że data stosowania danego aktu prawnego oznacza jego wpływ na skuteczne egzekwowanie przez właściwe organy obowiązków wobec „affected parties” (pytanie czy Urząd „podpada” pod to określenie, czy też raczej chodzi o podmioty, do których bezpośrednio adresowane są konkretne obowiązki). Samo wejście w życie aktu oznacza jednocześnie, że jest on obowiązujący (ciekawe spostrzeżenia można w zakresie rozróżnienia tych dwóch terminów można znaleźć również tutaj).

Przyjąć można, że wejście w życie aktu prawnego powoduje, że nabywa on mocy prawnej. W takim przypadku w dużej mierze od organów, które powinny stosować dane przepisy zależy, czy skorzystają z takiej „uprzedniej” możliwości (oczywiście w granicach określonych uprawnień). Wydaje się, że w omawianej sprawie, o ile UKNF nie mógłby żądać od dostawców usług płatniczych spełnienia wybranych obowiązków przed 14 września 2019 r., to jednak – w przypadku spełnienia „ustawowych” przesłanek i złożenia wniosku, teoretycznie możliwe byłoby udzielenie stosownego zezwolenia w drodze postępowania administracyjnego. Interesujące argumenty można znaleźć tutaj (szczególnie na str. 68-69), choć dotyczą one „obowiązywania”, a nie „stosowania” aktu prawnego. Nie chcę jednak rozstrzygać tej kwestii, ponieważ przepisy, orzecznictwo i doktryna rzeczywiście pozostawiają duże pole do interpretacji.

Czyli co?

KNF dał wyraźnie do zrozumienia, że będzie wspierał dostawców usług płatniczych. Z komunikatu możemy wyczytać, że Urząd dopuszcza możliwość sprawdzenia spełnienia warunków do uzyskania zwolnienia w toku bieżącego nadzoru i przed złożeniem wniosku. Jest to więc jedynie „opcja”, z której dostawcy mogą skorzystać. Jeżeli wynik takiej kontroli będzie pozytywny, to można założyć, że tworzenie mechanizmu awaryjnego nie będzie konieczne (tym bardziej, że we wcześniejszym komunikacie UKNF sam wskazał, że preferuje nieudostępnianie przez banki interfejsów klientowskich.

Teoretycznie więc można spać spokojnie

Niestety, tylko teoretycznie. Czytając dalej komunikat dochodzimy do zdania, w którym UKNF podkreśla, że „(…) nawet w przypadku ostatecznego zwolnienia zainteresowanego ASPSP z opcji fallback, ryzyko związane z nawet przejściowym niewypełnieniem obowiązku jej posiadania po 13 września 2019 r. i w związku z tym uniemożliwieniem TPP świadczenia jego usług obciążać będzie obowiązany ASPSP (…)”.

Jeżeli więc bank nie utworzy mechanizmu awaryjnego, a jego specjalny interfejs dostępowy przestanie działać, co uniemożliwi Third Party Providers świadczenie usług dla klientów, to pojawia się ryzyko regulacyjne (art. 32 ust. 3 oraz 33 ust. 4 Rozporządzenia 2018/389), a tym samym ryzyko sankcji z art. 138 Prawa bankowego czy – zaleceń.

Jest jeszcze bezpieczeństwo danych klientów

KNF uczulił, że mechanizm awaryjny (w formie interfejsu klientowskiego) podlega szczególnym obowiązkom ze względu na fakt, że jest udostępniany podmiotom trzecim. Taki interfejs musi więc zapewniać, że TPP uzyskać dostępy do danych identyfikujących i uwierzytelniających na potrzeby komunikacji elektronicznej z bankiem (i tylko tych uzgodnionych z TPP).

TPP powinien mieć ponadto dostęp tylko do tych danych użytkownika oraz informacji o jego produktach, które miałby przy użyciu „standardowego” interfejsu. Nie powinien mieć więc dostępu np. do informacji odnośnie produktów inwestycyjnych.

Jeżeli doszłoby do sytuacji, w której takie „dodatkowe” informacje udostępnione zostały TPP, to bank ponosi odpowiedzialność za wynikłe stąd szkody, a dodatkowo powinien wymusić na użytkowniku zmianę danych uwierzytelniających (wraz ze stosowną komunikacją zawierającą uzasadnienie). Bank musi więc posiadać odpowiednie mechanizmy bezpieczeństwa, w tym monitorowania przepływu informacji i ryzyka z tym związanego.

Innymi słowy – TPP w ramach mechanizmu awaryjnego powinien uzyskać dostęp jedynie do okrojonego interfejsu użytkownika (np. poprzez wyłączenie widoczności niektórych funkcji).

Artykuł stanowi moją prywatną opinię i nie może być utożsamiany ze stanowiskiem jakiejkolwiek instytucji z którą jestem lub byłem związany.

 

.