Open Banking: Ważne wskazówki dla banków oraz Third Party Providers w kontekście identyfikacji, czyli piąte wyjaśnienia grupy roboczej ds. API przy EBA

Dwa tygodnie temu opublikowałem czwarte podsumowanie prac grupy roboczej Europejskiego Urzędu Nadzoru Bankowego (EBA) ds. Application Programming Interface (API), a już mamy kolejne – piąte – wyjaśnienia. Tym razem eksperci pochylili się nad kilkoma interesującym zagadnieniami niedotyczącymi zwolnienia z obowiązku stosowania środka awaryjnego, w tym identyfikacji Third Party Providers (TPP). Jest też bardzo ważna informacja dla świata RegTech – rejestr EBA będzie w formie „machine-readable”. Zapraszam na kolejne starcie z API i Open Bankingiem. Zainteresowanych podstawami odsyłam do moich innych artykułów (link1; link2; link3). Dzisiaj zajmę się zagadnieniami, które mają szczególne znaczenie dla relacji TPP-dostawca rachunku płatniczego (bank).  

Na początek wspomniany już rejestr dostawców usług płatniczych. Obowiązek jego utworzenia wynika wprost z art. 15(1) dyrektywy PSD2 (a ściślej rzecz biorąc z Rozporządzenia 2019/411). Obejmuje on m.in. (i) dostawców usług płatniczych; (ii) instytucje płatnicze zwolnione z niektórych obowiązków; (iii) instytucje pieniądza elektronicznego czy (iv) banki oraz agentów i oddziały instytucji kredytowych. Jego największą wadą jest jednak potencjalna nieaktualność niektórych danych (ze względu na fakt, że informacje w tym rejestrze przekazywane są przez organy krajowe, co może następować ze znacznym opóźnieniem). W efekcie wydany certyfikat eIDAS (więcej tutaj) może być zwyczajnie nieaktualny na chwilę wykonania żądania TPP przez bank.

Abstrahując jednak od „wadliwości” tego rozwiązania, stanowi ono użyteczne narzędzie do przynajmniej wstępnej weryfikacji TPP w ramach (w zakresie dozwolonym przez Rozporządzenie 2018/389) onboardingu. Dostrzegając potrzeby rynku w zakresie automatyzacji, EBA opublikowała specyfikację techniczną, która umożliwia stworzenie odpowiedniego narzędzia do „zasysania” danych z tego rejestru i wykorzystania go do np. sprawdzenia certyfikatu eIDAS i wspomnianych danych w tym samym czasie. Plik jest dostępny pod tym adresem.

Czas odpowiedzi (response time)

Pytanie dotyczy wprawdzie zwolnienia z obowiązku stosowania środka awaryjnego (tutaj nieco więcej w tym temacie), ale ma znaczenie dla komunikacji w ogóle. Wytyczne EBA w sprawie wymogów odnośnie zwolnienia stawiają przed środowiskiem produkcyjnym API (specjalny interfejs dostępowy), które ma być objęte zwolnieniem rygorystyczne wymogi w zakresie obsługi TPP. Jednym z wyznaczników jest stosowanie tzw. Key Performance Indicators dla oceny efektywności interfejsu, które są co najmniej tak surowe jak dla interfejsu udostępnianego klientom.

Wielu z ekspertów podnosiło kwestię trudności w ocenie jednego ze wskaźników (response time), który odnosi się do czasu na udzielenie odpowiedzi na żądanie TPP. W szczególności wątpliwości budziło czy taki czas obejmuje również czas niezbędny na przeprowadzenie silnego uwierzytelnienia klienta czy też czas niezbędny na weryfikację zezwolenia/rejestracji TPP.

EBA wyjaśniła tutaj, że czas ten obejmuje zarówno potwierdzenie zezwolenia/rejestracji TPP (nie tylko samego certyfikatu eIDAS), jak i czas potrzebny na przeprowadzenie silnego uwierzytelnienia (musi to być jednak taki sam czas jak dla użytkownika). To dobra informacja.

Księga gości dla TPP?

Kolejny temat dotyczy trudności w jednoznacznej identyfikacji TPP w ramach środka awaryjnego i poszukiwania efektywnego narzędzia w tym zakresie. Niektórzy uczestnicy grupy zaproponowali rozwiązanie, w ramach którego tworzona byłaby tzw. guestbook, jako rejestr TPP. „Wejście” do takiego rejestru wymagałoby zidentyfikowania się z użyciem certyfikatu eIDAS i poprzedzałoby dostęp do systemu dostawcy rachunku. Kolejny – właściwy – dostęp TPP do rachunków byłby oddzielnym procesem zgodnym – jak zakładam – z Rozporządzeniem 2018/389. Przyznam szczerze, że sam mam pewne wątpliwości co do zaproponowanego rozwiązania. Co jednak na to EBA?

Przede wszystkim podkreśliła, że identyfikacja TPP powinna przebiegać z użyciem certyfikatów eIDAS. W ramach środka awaryjnego ten element nie ulega zmianie (nie ma więc znaczenia czy mamy dostęp z użyciem interfejsu klientowskiego, czy specjalnego interfejsu dostępowego). Wybór rodzaju certyfikatu (pieczęć etc.) leży po stronie dostawcy rachunku. Niemniej jednak wymuszenie na TPP dodatkowej rejestracji nie spełnia wymogów w zakresie identyfikacji (art. 34 ust. 1 Rozporządzenia 2018/389) oraz certyfikacji (art. 33 ust. 5 Rozporządzenia 2018/389). Naruszałoby to też inne wymogi, w tym w zakresie ograniczenia obowiązku identyfikacji do sytuacji, w której dana usługa jest wykonywana. Innymi słowy – taka dodatkowa identyfikacja stanowiłaby przeszkodę dla TPP i mogłaby rodzić doniosłe konsekwencje dla dostawcy rachunku.

Czy bank musi zmieniać interfejs dostępowy na potrzeby środka awaryjnego?

Odnosi się to również do zakresu danych udostępnionych – standardowo – użytkownikowi. EBA poza ogólnym wylistowaniem obowiązków dostawcy rachunku podkreśliła, że obowiązujące przepisy nie nakładają żadnych obowiązków w zakresie ograniczenia danych w ramach środka awaryjnego (za wyjątkiem informacji szczególnie chronionych – np. dane niezbędne do wykonania transakcji, w tym indywidualne dane uwierzytelniające, na co uwagę zwraca z resztą uwagę art. 36 ust. 1 Rozporządzenia 2018/389). Numer rachunku i imię oraz nazwisko użytkownika nie są zdaniem EBA „sensitive”.

Drugim ważnym elementem jest podkreślenie, że to na TPP, a nie dostawcy rachunku ciąży obowiązek zapewnienia, że nie wchodzi on w posiadanie danych, które nie są niezbędne do wykonania usługi (i które były żądane przez użytkownika). Innym słowy obowiązku nie ma, ale o ile mnie pamięć nie myli – w jednym z QnA unijny nadzorca wskazała, że wprowadzenie takiego ograniczenia jest dozwolone pod warunkiem, że nie będzie to tworzyło niedozwolonych przeszkód i umożliwi swobodne wykonanie danej usługi TPP.

Czy bank ma obowiązek dokumentować „contingency access”?

Wszystkie strategie i plany na wypadek awarii i konieczności uruchomienia interfejsu awaryjnego powinny zawierać odpowiednie informacje. Instytucja powinna mieć dodatkowo udokumentowany proces komunikacji z TPP na wypadek wystąpienia takiego zdarzenia, w tym w jaki sposób poinformuje o alternatywnych metodach. Musi to nastąpić niezwłocznie. Wszystko należy więc udokumentować w procesach i procedurach wewnętrznych oraz opracowania odpowiednie rozwiązanie umożliwiające komunikację, np. poprzez „awaryjną” stronę internetową.

Trudno o certyfikat eIDAS

To bardziej stwierdzenie niż pytanie i EBA ma tego świadomość (szczególnie wobec wielokrotnie powracającego tematu numeru rejestrowego/zezwolenia). Unijny nadzorca podkreślił jednak, że nie jest to już wyzwanie wobec licznych interpretacji w tym zakresie. Wiadomo już, że taki numer jest każdą formą krajowej identyfikacji wykorzystywanej przez krajowego nadzorcę, która pozwala na jednoznaczne zidentyfikowanie TPP.

EBA przypomniała także, że zwróciła się w licznych dokumentach do dostawców certyfikatów eIDAS oraz krajowych regulatorów o współpracę w kontekście ewentualnych cofnięć zezwoleń/rejestracji.

 

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *