EBA mówi co jest, a co nie jest przeszkodą dla fintechów korzystających z API, czyli Opinion on obstacles to the provision of third party provider ser
Europejski Urząd Nadzoru Bankowego opublikował dzisiaj ważny dokument na który czekała pewnie spora część fintechowego środowiska. Mowa tutaj o opinii w sprawie przeszkód, które mogą pojawić się w przypadku korzystania ze specjalnego interfejsu dostępowego – API. Jest tam kilka ciekawych wątków, ale na pełną analizę przyjdzie jeszcze pora. Ważne jest to, że EBA poruszyła wątek możliwości zablokowania dostępu dla TPP poprzez żądanie użytkownika rachunku płatniczego. Przejdźmy szybko przez najważniejsze elementy dokumentu.
Od razu zaznaczam, że bardziej szczegółową analizę przygotuję pewnie w przyszłym tygodniu, więc podsumowanie może być obarczone pewnym (niewielkim) ryzykiem błędu w interpretacji.
Dokument ma duże znaczenie w kontekście art. 41 ust. 5 ustawy o usługach płatniczych, czyli możliwości odmowy wykonania usługi AIS lub PIS przez bank.
I jeszcze jedna uwaga. Opinia ma zastosowanie do specjalnych interfejsów dostępowych, a więc – z natury rzeczy – nie odnosi się do wariantu dostępu przez interfejs dostępny dla użytkowników banku (ASPSP).
Są bariery, są problemy
Rynek niebankowych dostawców (choć pewnie w tej grupy znalazły się też banki) dostrzega pewne problemy związane z otwartą bankowością, w szczególności w kontekście powszechnego “wymuszania” metody redirection, która nieco “psuje” customer experience i utrudnia stworzenie atrakcyjnej oferty przez fintechy.
EBA wskazuje tutaj, że sama metoda redirection nie stanowi przeszkody, co pokrywa się z wcześniejszymi opiniami. Może być jednak przeszkodą w sytuacji, gdy powoduje dodatkowe utrudnienia po stronie klienta, a także jeżeli API udostępnia tylko taką metodę, chociaż użytkownik ma więcej metod uwierzytelniania.
To z resztą kolejny punkt opinii. Bank powinien udostępnić TPP wszystkie metody uwierzytelnienia dostępne dla klienta, w tym autentykację z użyciem biometrii. I Tutak kolejna ważna uwaga:
Given that biometrics are not transmittable credentials, this means that these ASPSPs should enable their PSUs to authenticate with the ASPSP in an AISP or PISP journey using biometrics, by supporting decoupled authentication or app-to-app redirection to the ASPSP’s authentication app, and secure transmission of the ASPSP’s app authentication status to the ASPSP
Bardzo ważna informacja rozwiązująca chyba wiele problemów. Jeżeli bank nie udostępnia wszystkich metod, to niestety może to być przeszkoda.
Idźmy dalej
Mamy więc wskazanie, że wymuszanie dodatkowego silnego uwierzytelnienia (multiple SCA) będzie przeszkodą. Znowu, co do zasady. EBA dopuszcza bowiem sytuacją gdzie wymagane jest “podwójne” SCA, np. w przypadku stosowania jednocześnie dwóch usług – PIS oraz AIS. No chyba, że mamy jakieś wyłączenie.
Znalazło się i miejsce dla ponownego uwierzytelnienia po upływie 90 dni (wyłączenie z obowiązku stosowania SCA po upływie 90 dni). Nie jest to oczywiście przeszkoda, ale wymaganie dokonania tej czynności częściej niż po upływie 90 dni już tak.
Oczywiste jest też stwierdzenie, że wymuszanie od użytkownika, aby wpisywał “z palca” nr rachunku (IBAN) z którego chce dokonać płatności lub sprawdzić saldo z użyciem TPP będzie przeszkodą. Ale też ważna informacja:
ASPSP is not required to share with PISPs the list of all the PSU’s payment accounts. In fact, a PISP is not entitled under PSD2 to access the list of all the PSU’s payment accounts, as this information goes beyond the scope of data that PISPs have the right to access
Dodatkowe zgody, dodatkowe rejestracje
Oczywiście nie ma możliwości wymuszania dodatkowych zgód (również w przypadku klientów korporacyjnych i wielu upoważnionych użytkowników) czy rejestracji (ani po stronie użytkownika, ani samego TPP). Rejestracja może być jednak uzasadniona względami technicznymi. Wtedy jest ok.
EBA przypomina również, na co wskazywałem na początku artykułu, że klient może wyrazić zgodę (chęć) na zablokowanie dostępu do swoich rachunków płatniczych dla wybranego lub wszystkich TPP. I pamiętajmy o wymogach art. 41 ust. 5-8 ustawy o usługach płatniczych, czyli m.in. o obowiązkach informacyjnych. Ja to tak rozumiem.
I to tyle. Na bardziej szczegółową analizę przyjdzie pora.