Otwarta bankowość puka do drzwi. Jakie wyzwania czekają banki w najbliższych miesiącach w kontekście „testowego” API?

Jednym z największych wyzwań dla banków związanych z wejściem w życie pakietu PSD2 (dyrektywa oraz Rozporządzenie 2018/389) jest otwarcie bankowości na podmioty trzecie (Third Party Providers). Open banking poza oczywistymi zmianami w zakresie infrastruktury, oprogramowania, procesów oraz procedur, wymusza na bankach podjęcie szeregu decyzji biznesowych. Dodatkowo, wiele z przepisów m.in. ze względu na swoją neutralność technologiczną wywołuje szereg niejasności, które należy rozstrzygnąć przed okresem stosowania określonym w ustawach i rozporządzeniach. Jakie więc problemy napotykają banki w związku z bankową r(e)wolucją?

O wymogach w zakresie interfejsów dostępowych oraz wyłączeniu z obowiązku stosowania środków awaryjnych pisałem m.in. tutaj i tutaj. Z tego względu w dalszej części artykułu skupię się na tych obszarach, które stanowią obecnie największe wyzwanie.

Open API a przepisy

Punktem wyjścia dla analizy są przepisy Rozporządzenia 2018/389 (RTS) oraz częściowo ustawy o usługach płatniczych (zasadniczo w odniesieniu do wymogów stawianych TPP, tj. Account Information Service Providers oraz Payment Initiation Service Providers). Duże znaczenie ma również opinia Europejskiego Urzędu Nadzoru Bankowego (EBA) w sprawie implementacji RTS oraz wytyczne EBA w sprawie zwolnienia z obowiązku stosowania fall-back mechanism.

Środowisko testowe – praktyczne problemy

Banki najpóźniej do 14 marca powinny uruchomić środowisko testowe, które pozwoli TPP na przygotowanie swoich interfejsów dostępowych do integracji z API banków. Jednym z elementów związanych z tym obowiązkiem jest konieczność udostępnienia dokumentacji technicznej podmiotom trzecim, tak aby mogły one de facto uczestniczyć w testowaniu. Dokumentacja taka jest udostępniania na wniosek. Streszczenie jest publikowane na stronie internetowej banku.

RTS wymaga, aby banki udostępniały środowisko testowe oraz dokumentację zarówno podmiotom, które posiadają stosowne zezwolenie lub rejestrację, jak również tym, które dopiero złożyły taki wniosek do regulatora i czekają na jego rozpatrzenie.

Rodzić to może pewne ryzyka. W jaki sposób banki powinny (i czy w ogóle) weryfikować czy dany podmiot złożył stosowny wniosek o zezwolenie lub rejestrację? Jeżeli bank w swoim interfejsie dostępowym zaimplementował odpowiednią funkcjonalność pozwalającą na identyfikację TPP z użyciem eIDAS (więcej w tym artykule), to jak identyfikować podmioty, które jeszcze nie mają takich certyfikatów? Czy wystarczą certyfikaty testowe?

Wydaje się, że jednym z rozwiązań mogłoby być wydawanie przez UKNF stosownych „potwierdzeń” złożenia wniosku na potrzeby uczestnictwa w testowaniu środowiska API (i oczywiście szerzej – na potrzeby licencji/rejestracji). Wprawdzie na TPP ciążyć będzie obowiązek udowodnienia spełnienia przesłanek z RTS, jednakże na banku również ciąży obowiązek upewnienia się, że są one spełnione (nawet jeżeli w ramach środowiska testowego nie dochodzi do wymiany danych szczególnie chronionych).

W kwestii certyfikatów eIDAS oraz identyfikacji podmiotów trzecich przez interfejs dostępowy w ramach testów wydaje się, że o ile bank nie zdecyduje się na implementację takiego rozwiązania (nawet jeżeli na etapie testów mogłoby to nie być zgodne z wytycznymi i RTSami), identyfikacja powinna przebiegać z użyciem innych środków i certyfikatów testowych (np. wydawanych przez KIR). Inną sprawą jest kwestia oceny, czy taki interfejs bez stosownego rozwiązania spełniałby wymogi określone do zwolnienia z obowiązku stosowania fall-back mechanism.

Co z silnym uwierzytelnianiem klienta (SCA) w kontekście środowiska testowego

Pojawia się pytanie czy takie środowisko testowe powinno posiadać wszelkie rozwiązania w zakresie SCA (odnosi się to przede wszystkim do usługi PIS, ale również AIS). Wydaje się, że ze względu na możliwość uzyskania zwolnienia na stosowanie środków awaryjnych jest to pożądane, o ile nie wymagane. Ponadto, skoro od 14 września banki muszą w określonych przypadkach (jak np. dostęp do rachunku online czy elektroniczne płatności) stosować SCA, to tworzenie środowiska testowego bez SCA byłoby nieefektywne.

Przyjąć więc należy, że choć przepisy nie wymagają tego wprost (abstrahując od możliwości polegania przez TPP na procesach i procedurach uwierzytelniania użytkownika – PSU – banku), to wskazane jest udostępnienie testowego API z wbudowaną funkcjonalnością pod docelowe procedury uwierzytelniania z użyciem SCA.

Fall-back mechanism a środowisko testowe

Istotnym zagadnieniem, które spędza sen z powiek wielu banków, jest kwestia uzyskania zgody na zwolnienie ze stosowania środków awaryjnych (w praktyce taki środek polega na udostępnieniu TPP interfejsu dostępowego PSU). Z opinii EBA wynika, że taki wniosek można złożyć już w trakcie okresu 6 miesięcy pomiędzy wprowadzeniem środowiska testowego a docelowego rozwiązania w zakresie interfejsów dostępowych (przy czym należy pamiętać o okresie 3-miesięcznym w kontekście przesłanki widely used – to z resztą kolejne wyzwanie stawiane przed bankami).

EBA wskazuje również, że okres trzymiesięczny testowania API może zostać „zaliczony” na potrzeby exemption. Jeżeli więc bank chciałby z takiego zwolenienia skorzystać, to musi liczyć się z koniecznością stworzenia takiego API, które spełnia wymogi określone we wspomnianej opinii EBA, a także podjąć działania m.in. w zakresie upowszechnienia dostępu i poszerzenia świadomości TPP w tym zakresie (wymóg widely used).

Sama procedura została określona bardzo ogólnie. Decyzja o wyłączeniu następuje na wniosek zainteresowanego podmiotu złożony do regulatora (w Polsce UKNF), który po konsultacji z EBA (dopuszczalna jest milcząca zgoda po 1 miesiącu), zwalnia lub nie z obowiązku utrzymywania fall-back mechanism. Do 31 grudnia 2019 r. EBA przyjęła nieco mniej restrykcyjne wymogi, które obligują regulatora jedynie do poinformowania Urzędu o przyznaniu lub odmowie exemption (co odbywa się poprzez przesłanie specjalnego formularza). Ważna jest również współpraca organów nadzoru przy grupach transgranicznych.

UKNF nadal nie wypowiedział się w kwestii sposobu składania wniosku, jednakże Związek Banków Polskich przygotował odpowiedni projekt, który zasadniczo odzwierciedla wymogi EBA w zakresie zwolnienia (ZBP przygotował nawet stosowne szkolenie). Nadal jednak czekamy na dalsze kroki ze strony regulatora, który zaakceptuje taki wzór wniosku. Na pewno poruszę tą kwestię w kolejnym artykule.

Inne wyzwania związane z API

W tym artykule skupiłem się na potencjalnych wyzwaniach związanych przede wszystkim ze środowiskiem testowym, jednakże nie wyczerpuje to zagadnień z którym sektor bankowy będzie musiał się zmierzyć.

Wiele niejasności budzi kwestia stosowania SCA w różnych kanałach płatności lub dostępu do rachunku. Niemniej ważne są tematy związane ze stosowaniem wyłączeń z wymogu stosowania silnego uwierzytelnienia i konsekwencji takich wyłączeń dla TPP.

Banki będą musiały się również zmierzyć z trudnym zagadnieniem ewentualnej odmowy dostępu do interfejsu dostępowego, w szczególności wobec rosnącej liczby zagrożeń z tym związanych (tutaj niezwykle istotne będą odpowiednie procedury bezpieczeństwa, w tym identyfikacji PISP i AISP, oraz monitorowanie ryzyk związanych z cyberbezpieczeństwem).

Wydaje się jednak, że dopiero praktyka i bardziej konkretne stanowiska UKNF pozwolą na podjęcie bardziej skonkretyzowanych działań. Banki już teraz intensywnie przygotowują się do implementacji wszystkich wymogów, jednakże powstające wątpliwości powodują, że niepewność regulacyjna nadal jest znacząca.

 

Dodaj komentarz

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