Application Programming Interface w „oczach” EBA, czyli IV wyjaśnienia grupy roboczej ds. API

Open Banking to ostatnio bardzo nośny temat, który opiera się w znacznej mierze na wykorzystywaniu tzw. Application Programming Interfaces, czyli popularnych API. W czwartkowym artykule poruszyłem ten temat w kontekście wymogów jakie pakiet PSD2 stawia bankom udostępniających swoje interfejsy podmiotom trzecim. W piątek z kolei Europejski Urząd Nadzoru Bankowego (EBA) opublikował już czwarty dokument zawierający wyjaśnienia do wielu palących kwestii związanych z wykorzystaniem API. Wśród omawianych tematów znalazły się m.in. takie zagadnienia jak potwierdzenie wykonania transakcji czy dostęp Third Party Providers (TPP) do informacji odnośnie rachunku nie płatniczych. Zapraszam na krótkie podsumowanie tych zagadnień.

Zanim przejdziemy do konkretów krótkie przypomnienie. Od 14 września wszyscy dostawcy usług płatniczych udostępniający dostęp do rachunku (głównie banki) muszą „wystawić” tzw. produkcyjne API, czyli otworzyć swoje interfejsy dla TPP, tak aby te podmioty (po uzyskaniu zgody i uwierzytelnieniu klienta banku) mogły one wykonać jedną z usług „fintechowych”, jak np. inicjacja płatności czy agregacja informacji o rachunku. Przepisy regulujące obowiązki po stronie TPP oraz banków znalazły się w Rozporządzeniu 2018/389 (art. 30-36).

Potwierdzenie wykonania transakcji

Usługa Payment Initation Service (PIS) polega na zleceniu TPP wykonania przelewu z określonego rachunku płatniczego należącego do użytkownika. Ponieważ w tym przypadku mam „pośrednika” przepisy ustawy o usługach płatniczych (m.in. 59r ust. 4) obligują bank do niezwłocznego przekazania TPP określonych informacji o transakcji (o jej zainicjowaniu oraz wszelkie dostępne informacje dotyczące wykonania transakcji). Z kolei art. 59q ust. 1 zobowiązuje TPP do przekazania określonych informacji płatnikowi, w tym informacji o kwocie transakcji czy potwierdzenia o prawidłowym złożeniu zlecenia.

W najnowszym dokumencie EBA pojawiło się pytanie odnośnie tego czy bank powinien przekazywać TPP świadczącemu usługę PIS informacje dotyczące zainicjowania i wykonania transakcji, co z resztą było już przedmiotem odpowiedzi EBA w jednym z lipcowych QnA. Z tego też względu EBA nie przeprowadziła dodatkowej analizy, a odesłała do rzeczonego QnA. Unijny nadzorca zauważył, że bank nie ma dostępu do informacji odnośnie tego czy dana transakcja zostanie zrealizowana czy też nie (przynajmniej nie zaraz po otrzymaniu zlecenia) i z tego względu nie ma obowiązku przekazywania takiej informacji do TPP. Niezależnie jednak od tego, jeżeli TPP złoży żądanie udostępnienia informacji odnośnie dostępnych środków na rachunku, to bank powinien niezwłocznie przekazać informację „tak/nie” w tym zakresie.

Biometria i uwierzytelnianie na aplikacjach mobilnych!

To bardzo ważna kwestia, którą poruszyła EBA w swoich wyjaśnieniach. Generalnie chodzi o to czy bank powinien udostępnić wszystkie metody uwierzytelniania dostępne dla klientów tego banku w ramach interfejsów dostępowych (API), w tym metod obejmujących wykorzystanie TouchID/FaceID na aplikacjach mobilnych (co ma szczególnie istotne znacznie w kontekście braku możliwości „transferu” danych uwierzytelniających obejmujących biometrię, tak jak ma to miejsce w przypadku haseł czy kodów PIN.

Art. 30 ust. 2 Rozporządzenia 2018/389 nakazuje bankom udostępnienie wszystkich metod uwierzytelniania dostępnych dla klienta na potrzeby realizacji usług typu PIS czy AIS. Jeżeli więc klient może korzystać z biometrii na potrzeby dostępu do rachunku, to TPP powinien mieć możliwość udostępnienia użytkownikowi tej metody uwierzytelnienia. O ile nie ma trudności z zapewnieniem „transferu” indywidualnych danych uwierzytelniających (IDU) obejmujących np. hasła, to w przypadku biometrii mamy pewne wyzwanie. Jedyną możliwością byłoby zastosowanie metody redirection (przekierowania) polegającej na „przerzucenia” użytkownika z interfejsu TPP na interfejs banku, gdzie ten użytkownik mógłby dokonać uwierzytelnienia. W następnym kroku bank musi zapewnić bezpieczną komunikację z TPP pozwalającą na wymienią informacji odnośnie zgodności wzorca biometrycznego z IDU niezbędnymi do wykonania określonej usługi.

Dostęp do informacji „nie płatniczych”

To oczywiście skrót myślowy. Może zdarzyć się sytuacja, że TPP (szczególnie świadczących usługę Account Information Service – AIS) będzie musiał skorzystać z metody screen-scrapping (jako opcja zapasowa na wypadek awarii – przy braku tzw. fall-back mechanism), która polega na wykorzystaniu IDU użytkownika i uzyskania „bezpośredniego” dostępu do interfejsu użytkownika. Tutaj EBA wskazała na jedną z ważnych kwestii, że od 14 września 2019 r. screep-scrapping będzie zakazany (czy EBA zapomniała tutaj o art. 33 ust. 4?).

EBA w swoich wyjaśnieniach wskazała na przesłanki jakimi należy kierować się przy ocenie czy mamy do czynienia z dostępem do rachunku płatniczego, bo tylko taki rachunek może być objęty reżimem PSD2 (powołała tutaj się na wyrok Trybunału C-191/17 – przy okazji kolejnego artykułu przybliżę to zagadnienie). Unijny nadzorca podkreślił również, że to po stronie TPP (a nie banku) lezy obowiązek zapewnienia, że ma on dostęp (i nie przechowuje) innych danych niż te niezbędne do wykonania określonej usługi. Musi również zapewnić spełnienie wszystkich wymogów Rozporządzenia 2016/679 (RODO) – obowiązek również po stronie banku.

Pamiętajmy jednak, że bank może w ramach takiego środka awaryjnego „okroić” TPP dostęp do danych niezbędnych do wykonania tej usługi, co znacznie ogranicza ryzyko po obu stronach (banku oraz TPP).

Czy stress-testy na potrzeb uzyskania zezwolenia z ustanawiania mechanizmu awaryjnego mogą być przeprowadzane w środowisku zbliżonym do produkcyjnego?

Można. Warunkiem jest jednak, aby to środowisko spełniało wymogi określone w wytycznej 4.1 dokumentu EBA w sprawie zwolnienia z fall-back mechanism. Oznacza to, że bank musi posiadać taką infrastrukturę jak dla środowiska produkcyjnego, w tym w zakresie dostępności.

Czy bank musi wskazywać w swoim certyfikacie eIDAS informację odnośnie roli jaką pełni?

Bank może świadczyć usługi w ramach swojego „ogólnego” zezwolenia bez uzyskiwania dodatkowych „zgód” czy zezwoleń (na naszym rynku dostrzegalna jest inna praktyka). Jeżeli więc bank zamierza świadczyć jedną z usług PIS, AIS lub potwierdzenie dostępności środków na rachunku (Confirmation of Availability of Funds – CBPII), to certyfikat powinien zawierać informacje odnośnie tych wszystkich „ról”. Jeżeli z kolei bank będzie występował w roli „dostawcy” rachunku, to odpowiednia „adnotacja powinna znaleźć się w „treści” certyfikatu.

Dostęp do rachunku 4 razy na dobę?

TPP świadczących usługę AIS może uzyskiwać dostęp – bez udziału użytkownika – do informacji na rachunku maksymalnie cztery razy na 24 godziny (aktywność użytkownika liczona jest poprzez tzw. „aktywne sesje komunikacyjne”). EBA dopuszcza jednak możliwość zwiększenia tej częstotliwości, jednakże wymaga to umowy pomiędzy bankiem a TPP oraz zgody użytkownika rachunku.

Czy bank ma obowiązek udostępniania numerów rachunków klientów?

Ma obowiązek udostępniać tylko te informacje, które są niezbędne do wykonania usługi PIS, w szczególności nie musi udostępniać listy dostępnych rachunków użytkownika (chyba, że byłoby to przeszkodą do wykonania usługi).