Dlaczego banki uruchamiają produkcyjne API, czyli o postępowaniu w sprawie zwolnienia z fall-back mechanism

Ostatni tydzień to okres gwałtownego wzrostu liczby tzw. produkcyjnych API uruchomianych przez banki. Oznacza to, że dostawcy usług płatniczych świadczący usługi takiej jak Account Information Services czy Payment Initation Services (Third Party Providers) mogą już integrować się z tymi bankami w celu realizacji powyższych usług dla ich klientów. Dlaczego część instytucji finansowych zdecydowała się na uruchomienie „produkcyjnego” API przed 14 września (wtedy wchodzi w życie Rozporządzenie 2018/389) i jakie wymogi musi spełniać taki specjalny interfejs? Dzisiaj odpowiedź na pierwsze pytanie. Postaram się również znaleźć odpowiedź na pytanie o tryb rozpatrywania wniosku o zwolnienie z obowiązku stosowania tzw. fall-back mechanism i to jak wpływa to na sytuację banków.

W lutym pisałem już o tzw. testowych API (dla uproszczenia poprzez API będziemy rozumieć specjalne interfejsy dostępowe), które wszystkie banki musiały „wystawić” na 14 marca. Rozporządzenie 2018/389 wprowadziło obowiązek przeprowadzania przez banki takich testów do 14 września, kiedy to powinny one uruchomić już w pełni funkcjonalne rozwiązanie, czyli wspomniane „produkcyjne” API.

14 czerwca datą graniczną…

Artykuł 33 Rozporządzenia 2018/389 przewiduje, że na wypadek awarii specjalnego interfejsu dostępowego, banki muszą udostępnić odpowiednie rozwiązania techniczne umożliwiające ciągłość działania TPP. W praktyce oznacza to – poza obowiązkami komunikacyjnymi – konieczność udostępnienia tym podmiotom interfejsów dostępowych, które są przeznaczone dla klientów banku (przynajmniej do czasu przywrócenia funkcjonalności API) – tzw. screen-scraping.

Jednocześnie Rozporządzenie 2018/389 przewiduje, że krajowy organ nadzoru, np. KNF, po konsultacji z Europejskim Urzędem Nadzoru Bankowego (EBA) może zwolnić bank z obowiązku ustanawiania takiego środka awaryjnego. Ponieważ wymogi jakie musi spełniać API, aby w ogóle można było rozpatrywać możliwość takiego zwolnienia, zostały w Rozporządzeniu 2018/389 opisane bardzo ogólnie, EBA opublikowała w grudniu ub. stosowne wytyczne.

Na gruncie tych wytycznych pojawiły się liczne wątpliwości co do korelacji terminów wynikających z Rozporządzenia 2018/389 a dokumentem unijnego nadzorcy. Jednym z wymogów jest bowiem, aby API było dostępne w wersji produkcyjnej przez okres co najmniej 3 miesięcy, co ma pozwolić na przetestowanie specjalnego interfejsu w warunkach „live”.

Te wymagania wywołały pewną konfuzję w środowisku bankowym. W kwietniowych wyjaśnieniach do Rozporządzenia 2018/389 EBA opublikowała listę z terminami, które zadeklarowały krajowe organy nadzoru w kontekście przyjmowania wniosków o zwolnienie ze stosowania ww. środka awaryjnego (tzw. fall-back mechanism). Większa część organów nadzoru zadeklarowała 15 czerwca jako ostateczny termin na uruchomienie produkcyjnego API. W tamtym czasie KNF nie wskazał preferowanej opcji.

Wyjaśnienia Urzędu – terminy

Urząd odniósł się jednak do możliwości złożenia wniosku przed terminem wejścia w życie przepisów dotyczących obowiązku udostępnienia produkcyjnego API. UKNF podkreślił, że wniosek można złożyć zasadniczo w każdym czasie od czasu wejścia w życie Rozporządzenia 2018/389. Pojawia się jednak pytanie odnośnie dwóch innych terminów, które mają znaczenie w tym kontekście.

Po pierwsze powyższe rozporządzenie stosuje się od 14 września 2019 r. (z wyłączeniem terminów na uruchomienie API testowego). Po drugie, wytyczne EBA dotyczące wyłączenia z fall-back mechanism stosuje się, co do zasady, od 1 stycznia 2020 r. (chyba, że organ nadzoru notyfikuje EBA zamiar stosowania ich wcześniej – ja nie słyszałem o takiej notyfikacji, jednakże założyć należy, że UKNF przynajmniej zamierza to zrobić przed 14 września).

Czy w takiej sytuacji, uwzględniając dodatkowo terminy administracyjne UKNF (załóżmy dwa miesiące i mieszczący się w tym miesiąc na konsultacje z EBA), Urząd rzeczywiście ma możliwość rozpatrzenia wniosków przed 14 września w „normalnym” trybie i tym samym „umożliwić” bankom rezygnację z tworzenia rozwiązań awaryjnych?

Postępowanie administracyjne

Udzielenie zwolnienia z obowiązku stosowania fall-back mechanism powinno zostać załatwione w drodze decyzji administracyjnej. Przyjmując najbardziej niekorzystne scenariusz, który zakłada, że UKNF nie notyfikował EBA zamiaru stosowania wytycznych (co powoduje, że nie można stosować „uproszczonej” formy, tj. notyfikacja versus konsultacja), Urząd będzie miał dwa miesiące na wydanie decyzji administracyjnej (załóżmy, że mamy tutaj sprawę szczególnie skomplikowaną). Wytyczne EBA zakładają, że udzielenie zezwolenia nie może nastąpić przed przekazaniem przez unijnego nadzorcę uwag lub z upływem jednego miesiąca od notyfikacji zamiaru udzielenia zezwolenia.

Zakres informacji oraz dokumentów, które podlegają ocenie organów nadzoru w kontekście zwolnienia ze stosowania mechanizmu awaryjnego jest bardzo szeroki i wymaga specjalistycznej wiedzy. Sam Urząd wskazuje, że będzie bardzo dokładnie badał składane wnioski. Analiza wniosku od chwili jego doręczenia Urzędowi powinna więc przebiegać niezwykle dynamicznie, tak aby „wyrobić” się w ustawowym terminie. I nie zapominajmy, że jest jeszcze postępowania odwoławcze, gdyby decyzja nie była satysfakcjonująca.

Wróćmy do 14 czerwca…

Rynek przyjął, że uruchamiając produkcyjne API do dnia 14 czerwca, dokładnie 14 września będzie możliwe złożenie wniosku o zwolnienie spod obowiązku ustanawiania fall-back mechanism. Jeżeli Urząd otrzyma taki wniosek na 14 września, to ewentualna decyzja może zostać wydana nawet 14 listopada. Tutaj warto zastanowić się również czy Urząd może wydać wcześniej decyzję o zwolnieniu, jeżeli Rozporządzenie 2018/389 stosujemy dopiero od 14 września? Bardziej interesujące jednak jest to co powinno nastąpić w tym okresie „przejściowym”?

Już w 2018 r. UKNF wskazał, że bezpieczniejszym rozwiązaniem (odnosząc się raczej do klienta detalicznego) jest stosowanie specjalnych interfejsów dostępowych a nie klientowskich. W tym okresie banki, patrząc przez grunt przepisów, powinny mieć ustanowiony mechanizm fall-back. Bank decydując się jednak na złożenie wniosku, jak zakładam, chciały nie tylko ograniczyć koszty ewentualnych wdrożeń, ale również „zabezpieczyć” klientów przede ewentualną koniecznością wdrożenie tego mechanizmu awaryjnego.

Inny wariant?

Możliwym wariantem, ale chyba niekoniecznie skutecznym, może być złożenie wniosku, który zawiera jeden z warunków określony jako „w toku”. Ten najbardziej problematyczny element to 3-miesięczny dostęp TPP do środowiska produkcyjnego. Teoretycznie więc, jeżeli wszystkie inne element są spełnione, to możliwe byłoby złożenie takiego „niekompletnego” wniosku z założeniem, że Urząd poprosi o uzupełnienie o brakujący element, który bank dostarczy na 14 września (lub wcześniej, jeżeli API produkcyjne było w fazie „live” już wcześniej).

Jeżeli wszystko byłoby „ok”, to znowu – teoretycznie – Urząd mógłby wydać decyzję tego samego dnia i w takiej sytuacji bank otrzymałby zwolnienie. Jest to jednak wariant bardzo teoretyczny i raczej mało prawdopodobny. Tym bardziej, że sam Urząd wskazuje na konieczność przesyłania kompletnych wniosków.

Jak więc do tego podejść?

Brakuje nieco wyraźnej komunikacji w tym zakresie. Przyjmując powyższe założenia, nawet składając wniosek w terminie pojawia się ryzyko regulacyjne. Taka sytuacja jest wypadkową wielu czynników, w tym zasadniczo krótkiego okresu na dostosowanie się banków do Rozporządzenia 2018/389 oraz braku korelacji terminów określonych w wytycznych EBA oraz tym rozporządzeniu.

To co z pewnością uspokoiłoby rynek, to bardziej szczegółowa komunikacja w zakresie podejścia nadzorcy lub nawet zastosowanie rozwiązań „przejściowych”, np. poprzez „zawieszenie” stosowania przepisów (dotyczących obowiązków banków) do czasu rozpatrzenia wniosku o zwolnienie. Przeszkodą mogą być jednak dość sztywne przepisy administracyjne. Niewątpliwie jednak liczyć należy na dobrą wolę Urzędu (patrząc szczególnie przez pryzmat komunikatu z 2018 r.).

Oczywiście najbezpieczniejszym rozwiązaniem będzie złożenie wniosku o zwolnienie i jednoczesne przygotowanie się na utworzenie fall-back mechanism. Pamiętajmy, że obowiązek udostępnienia interfejsu klientowskiego aktualizuje się dopiero z chwilą wystąpienia awarii specjalnego interfejsu dostępowego, co teoretycznie jest pewnym “ułatwieniem”.