EBA: nowe wyjaśnienia do PSD2. Kilka “smaczków”​

Ostatni piątek to kilka ciekawych odpowiedzi Europejskiego Urzędu Nadzoru Bankowego na pytania związane z pakietem PSD2. Wśród omawianych tematów znalazły się takie zagadnienia jak rozdzielnie elementów silnego uwierzytelniania klienta czy „zakres” środków awaryjnych dla specjalnych interfejsów dostępowych (API). Warto zapoznać się tymi odpowiedziami, bo niektóre są bardzo interesujące. Zaczynamy! 

Pierwsze zagadnienie jest bardzo ciekawe i praktyczne i można sprowadzić do tego czy dwie aplikacje mobilne (jedna do inicjowania płatności i druga do autoryzacji) mogą spełniać wymagania Rozporządzenia 2018/389 (na marginesie zachęcam do przeczytania tego artykułu dotyczącego silnego uwierzytelniania klienta – SCA). Sprowadza się to do oceny czy spełnione mamy wymagania określone w art. 9 ust. 1 ww. rozporządzenia. Oczywiście zakładamy, że wszystkie wymagania do uznania aplikacji za posiadanie mamy spełnione.

Zdaniem EBA takie rozwiązanie może być ok, pod warunkiem, że zapewnimy wspomniane wyżej środki bezpieczeństwa (tutaj art. 9 ust. 2 i 3), czyli takie „ułożenie” elementów SCA nie doprowadzi (w przypadku próby fraudu) do np. nieautoryzowanej transakcji. Tym samym, jeżeli korzystamy z jednorazowego hasła OTP traktowanego jako „posiadanie” (taką możliwość dopuszcza opinia EBA – par. 25)  w połączeniu z elementem wiedzy (hasło) na tym samym urządzeniu oraz mamy spełnione powyższe warunki, to możemy mówić o SCA zgodnym z Rozporządzeniem 2018/389.

Przelew pomiędzy rachunkami własnymi 

To bardzo ciekawe pytanie i jeszcze bardziej ciekawa odpowiedź. Generalnie na mocy art. 15 Rozporządzenia 2018/389 dopuszczalne jest niestosowanie SCA, jeżeli robimy tzw. przelewy wewnętrzne, czyli pomiędzy rachunkami własnymi. Tutaj mamy pytanie doprecyzowujące sprowadzające się do oceny czy możemy dokonywać przelewów z naszych rachunków osobistych na rachunki firmowe (w ramach działalności gospodarczej). 

Wydawało się to oczywiste, ale chyba nie dla wszystkich. W każdym razie EBA potwierdziła oczywiście, że taki przelew jest zwolniony z obowiązku stosowania SCA (co jest oczywiście decyzją dostawcy), ale – uwaga – przelew pomiędzy rachunkami osoby fizycznej a rachunkiem osoby prawnej nie łapie się pod to wyłączenie. Nie jest to raczej specjalne zaskoczenie skoro mówimy o dwóch „różnych” osobach. No cóż 

Jak w AutoPay

Jakiś czas temu jeden z dostawców usług płatniczych wprowadził usługę AutoPay, która umożliwia płatności na bramkach autostradowych bez zbędnych (dodatkowych) czynności. To rozwiązanie oparte jest – jak zakładam – na art. 12 Rozporządzenia 2018/389, które umożliwia niestosowanie SCA dla płatności w terminalach samoobsługowych m.in. za przejazd.

I w swoim QnA Europejski Urząd Nadzoru Bankowego potwierdził w zasadzie, że to rozwiązanie jest poprawne i można je stosować. Istotne jest przy tym zastrzeżenie, że to jednak zawsze od dostawcy płatnika (kierowcy) zależy czy stosować dane wyłączenie, co ma z resztą znaczenie w kontekście odpowiedzialności za nieautoryzowane transakcje (zainteresowanych tematyką zachęcam do przeczytania tego artykułu).

Zakres środków awaryjnych

Art. 33 Rozporządzenia 2018/389 zobowiązuje dostawców prowadzących rachunki płatnicze (głównie banki), którzy wystawiają tzw. specjalne interfejsy dostępowe (API) do stosowania tzw. środków awaryjnych na wypadek awarii takiego API (więcej na ten temat w tym artykule).

Pytanie, które tutaj padło można powiązać z ostatnią opinią EBA w sprawie przeszkód dla tzw. Third Party Providers (więcej tutaj), bo dotyczy tego czy bank powinien udostępniać w ramach takiego środka awaryjnego nie tylko interfejs bankowości elektronicznej, ale również aplikację mobilną dla tej bankowości. Tutaj zastanowiłbym się także czy aplikacja mobilna nie może być traktowana jako jedynie kanał dostępu dla bankowości elektronicznej, a nie oddzielny interfejs. Może ktoś ma inne zdanie?

Jak można się domyśleć, EBA podkreśliła tutaj, że bank ma ogólnie obowiązek umożliwić TPP korzystanie z interfejsów udostępnionych użytkownikom usług płatniczych na potrzeby uwierzytelnienia i komunikacji z ich dostawcą usług płatniczych prowadzącym rachunek, ale dalej wskazuje, że nie oznacza to, że TPP będzie automatycznie otrzymywał dostęp do interfejsu aplikacji mobilnej. To bowiem od banku zależy, jak wypełni obowiązek zapewnienia tego środka awaryjnego, a więc do niego należy wybór i jak długo mamy spełnione wymagania z Rozporządzenia 2018/389, tak mówimy o poprawnym stosowaniu art. 33.

Na jak długo blokować dostęp? 

Art. 4 ust. 3 Rozporządzenia 2018/389 zobowiązuje dostawcę do blokowania możliwości uwierzytelnienia po pięciu nieudanych próbach w określonym czasie. Taka blokada może być tymczasowa lub na stałe. Pytanie na które odpowiedziała EBA odnosi się do tego „określonego czasu”.

EBA wskazała tutaj, że nie ma żadnych wytycznych, a to od decyzji banku (ASPSP) zależy jak będzie do tego podchodził (bazując na własnych systemach zarządzania ryzykami). I podobnie, to od banku zależy na jaki okres będzie dokonywał blokady.

Rejestr EBA

Przyznam szczerze, że jestem zdzwiony kolejnym pytaniem. Odnosi się ono do sposobu korzystania z rejestru PSD2 prowadzonego przez EBA. Pytania mają charakter bardzo ogólny. Zainteresowanych pogłębieniem tematyki zachęcam do przeczytania tej odpowiedzi, a także tej.

I jeszcze jedno ważne zagadnienie 

Było omawiane przez EBA wcześniej, ale warto je przytoczyć.

Pierwsze pytanie dotyczyło tego czy jest możliwe, aby ostateczna kwota transakcji była niższa lub wyższa niż wynika to uwierzytelniania dokonanego przez użytkownika. To zagadnienie istotne z „punktu widzenia” dynamicznego łączenia (art. 5 Rozporządzenia 2018/389).

EBA wskazała tutaj, że jeżeli mówimy o transakcjach płatniczych z użyciem karty i dokładna kwota transakcji nie jest znana w momencie udzielania zgody przez użytkownika, to w przypadku, gdy kwota jest wyższa niż wynika to ze zgody użytkownika, to dostawca powinien zastosować SCA lub odrzucić transakcję. Jeżeli jednak kwota jest równa lub niższa, to transakcja może zostać wykonana.