14 września 2019 roku wchodzi w życie kluczowy RTS związany z implementacją postanowień PSD 2, dotyczący silnego uwierzytelnienia klienta („SCA”) i wspólnych i bezpiecznych otwartych standardów komunikacji – przede wszystkim interfejsów dla TPP. Wydarzenie przełomowe, bo to właśnie od tego momentu dostawcy usługi prowadzenia rachunku (ASPSP) zobowiązani są de facto do uruchomienia interfejsów umożliwiających dostęp dla zewnętrznych dostawców w zakresie inicjowania płatności (PIS), dostępu do informacji o rachunku (AIS) oraz potwierdzania salda na rachunku (CoF), zgodnych ze standardami wymaganymi dyrektywą PSD 2. Wejście w życie RTS-u ma na dobre rozpocząć erę tzw. open – bankingu.
Interfejs dla TPP
Zgodnie z postanowieniami RTS, ASPSP mają do wyboru albo udostępnić dla TPP interfejs, z którego korzystają sami użytkownicy ASPSP, albo ustanowić dla nich specjalny interfejs, dedykowany ich dostępowi. Z wielu powodów, także bezpieczeństwa, ASPSP decydują się na te drugie. Ze względu na wymogi PSD 2 i RTS muszą one jednak odpowiadać funkcjonalnościami, efektywnością i dostępnością interfejsom, które w ramach rachunków płatniczych dostępnych on-line ASPSP udostępniają bezpośrednio swoim użytkownikom. Wszak, w przeciwnym razie open-bankingbyłby fikcją. Jedną z gwarancji takiego stanu rzeczy jest obowiązek wdrożenia środków awaryjnych na wypadek zmniejszenia efektywności lub dostępności interfejsu specjalnego.
Mechanizm fall-back
W ramach postanowień opisujących wymogi co do środków awaryjnych dla specjalnego interfejsu, RTS zawiera kilka ogólnych wymogów, w tym konieczność posiadania strategii i planów na wypadek spadku lub utraty dostępności i efektywności interfejsu oraz planów komunikacji do dostawców usług płatniczych z nich korzystających oraz organów nadzoru. Kluczowe konsekwencje ma jednak obowiązek przewidujący, że w ramach mechanizmów awaryjnych ASPSP, w czasie przysłowiowej awarii specjalnego interfejsu, powinien umożliwić TPP korzystanie z interfejsów udostępnianych bezpośrednio użytkownikom ASPSP.
Mechanizm ten nazywany jest mechanizmem fall-back. Dochodzimy więc do sytuacji, w której dostawca usługi rachunku płatniczego buduje i ponosi koszt interfejsu dedykowanego dostawcom trzecim, a mimo to na potrzeby realizacji środków awaryjnych i tak musi dostosować do wymogów PSD 2 i RTS interfejsy dotychczasowe. Obowiązany jest zatem poczynić w nich takie zmiany, które umożliwią identyfikację TPP oraz udzielenie zgody na transakcję i uwierzytelnienie się użytkownika za jego pośrednictwem. A przecież, po części, wystawiając interfejs specjalny, stara się tego uniknąć.
Dość inwazyjny a zarazem surowy ten plan awaryjny. Stanowi on jednocześnie bat na oraz zachętę dla ASPSP do rzetelnego i poprawnego wdrożenia i utrzymywania specjalnych interfejsów dla TPP. Dlaczego? Ponieważ z obowiązku zapewnienia mechanizmu fall-backASPSP może się zwolnić.
Możliwość uzyskania zwolnienia
RTS pozwala ASPSP ubiegać się u organu nadzoru o decyzję o wyłączeniu z obowiązku mechanizmu fall-back. Wymaga to jednak, aby specjalny interfejs odpowiadał wymogom RTS, był testowany przez TPP przez co najmniej 6 miesięcy w wersji testowej, a także co najmniej 3 miesiące powszechnie używany był w środowisku produkcyjnym, a ewentualne problemy z nim rozwiązywane były bez zbędnej zwłoki. Przesłanki te podlegają ocenie nadzoru, a to, w jaki sposób je spełnić, przybliżają wytyczne EBA z 4 grudnia 2018 r. w sprawie warunków skorzystania z wyłączenia z obowiązku ustanowienia mechanizmu fall-back.
Zmiana reguł gry w trakcie gry
14 września 2019 r. to data stosowania RTS. Od tej daty ASPSP obowiązane są do udostępnienia TPP specjalnych interfejsów wraz z mechanizmem fall-back, chyba że przed tą datą uzyskają od organu nadzoru zwolnienie. Co powinien był zatem zrobić ASPSP chcący uniknąć dostosowywania dla TPP interfejsu podstawowego? RTS opublikowano 13 marca 2018 r. i weszły w życie następnego dnia. Wytyczne EBA doprecyzowujące przesłanki zwolnienia są natomiast z 4 grudnia 2018 r. i stosuje się je od 1 stycznia 2019 roku.
Był zatem czas, nie twierdzę, że długi, nie tylko na przygotowanie specjalnych interfejsów zgodnych z wymogami PSD 2, ale także na udostępnienie przez wymagany okres środowiska testowego oraz produkcyjnego dla TPP – czyli jedne z podstawowych warunków uzyskania zwolnienia. Początkowo, w odpowiedzi na zapytanie ZBP, KNF wskazała, że wiążąca dla dopuszczalności składania przez ASPSP wniosków o uzyskanie zezwolenia jest data wejścia w życie, zaraz po opublikowaniu, a nie stosowania RTS, i możliwe jest uzyskanie zwolnienia przed datą ich wejścia w życie (14 września 2019 r.), o ile, oczywiście, spełnione będą wszystkie przesłanki wynikające z RTS. Przede wszystkim te związane z odpowiednio długim okresem funkcjonowania specjalnego interfejsu w środowisku produkcyjnym.
Kilka miesięcy później, w komunikacie z 1 lipca 2019 r., KNF zmieniła jednak swoje wcześniejsze stanowisko. Tym razem Komisja stwierdziła, że wiążąca z perspektywy prawa administracyjnego jest data stosowania RTS, a więc 14 września 2019 r. Oznacza to, że zarówno wniosek o wszczęcie postępowania w przedmiocie zwolnienia, jak i decyzja w tym zakresie, mogą być złożone przez zainteresowany ASPSP dopiero w tej dacie. Dostawcy usługi rachunku stanęli przed sytuacją, w której nie mogą przed datą stosowania przepisów uzyskać decyzji KNF o wyłączeniu obowiązku. Choćby te warunki spełniali, na 14 września 2019 r. muszą mieć ustanowiony mechanizm fall-back.
Nie wszystko stracone
Chociaż regulator pozbawił ASPSP skutecznej możliwości uzyskania zwolnienia przed datą zastosowania przepisów RTS, dość enigmatycznie wskazał, że ocena spełnienia jego przesłanek będzie następować w drodze bieżącego nadzoru. Odpowiedzialność za ewentualną niezgodność z wymogami RTS i niedostępność lub niewłaściwą dostępność interfejsu dla TPP nadal jednak obciąża ASPSP, nawet gdyby po 13 września 2019 roku, ale przecież nie od razu, zwolnienie z mechanizmu fall-back uzyskał.
Jak w tej sytuacji najlepiej zabezpieczyć się przed taką odpowiedzialnością, jeżeli podjęto decyzję o niewdrażaniu mechanizmu? Zapewniając, że specjalny interfejs spełnia warunki do uzyskania zwolnienia, czyli jest zgodny ze wszystkimi wymogami RTS i PSD 2. Warto w tym zakresie rozważyć zewnętrzny audyt technologiczno-prawny, który tę zgodność potwierdzi. Tego rodzaju działania z reguły spotykają się z pozytywnym odbiorem nadzorcy. Zwłaszcza, że KNF wprost wskazała w swoim piśmie z 22 marca 2019 r., że zlecanie zewnętrznych audytów technologiczno – prawnych i dołączanie ich do wniosków o zwolnienie z mechanizmu fall-backjest jak najbardziej uzasadnione z uwagi na złożoność materii, a przez to bezpieczeństwo obrotu i użytkowników. Taki audyt wydaje się więc istotnym, jeśli nie koniecznym elementem wniosku do KNF, a jednocześnie ogranicza ryzyko regulacyjne w okresie od daty stosowania RTS do uzyskania zwolnienia.
Wstęp i zajawka pochodzą od redakcji.