14 września coraz bliżej, czyli wybrane problemy związane ze stosowaniem silnego uwierzytelnienia klienta (SCA)

W jednym z ostatnich artykułów, ktory jest dostępny tutaj, poruszyłem kilka zagadnień związanych ze stosowaniem silnego uwierzytelniania klienta (Strong Customer Authentication – SCA), m.in. w zakresie wyłączenia (exemption) w odniesieniu do tzw. listy zaufanych odbiorców (więcej tutaj). Sam obowiązek zaimplementowania rozwiązań w tym zakresie będzie miał zastosowanie od 14 września br., jednakże już teraz wiele banków dokonuje przeglądu swoich procesów i procedur, tak aby w dniu „0” być gotowym i spełniać wymogi wynikające z Rozporządzenia 2018/389 (RTS). W kolejnym artykule chciałbym wskazać na kilka obszarów, które mogą stanowić wyzwanie dla banków w tym kontekście. Skupię się tutaj na konkretnych problemach, natomiast zainteresowanych bardziej podstawową wiedzą zapraszam do prześledzenia wcześniejszych artykułów.

Sam wymóg stosowania silnego uwierzytelniania wynika zasadniczo z art. 32i ustawy o usługach płatniczych, natomiast przepisy uszczegóławiające znajdziemy w art. 4-9 Rozporządzenia 2018/389. Nie bez znaczenia pozostaje również opinia Europejskiego Urzędu Nadzoru Bankowego w zakresie implementacji RTS, która stanowi istotną wskazówkę interpretacyjną.

Warto nadmienić, że art. 33 uUP nie pozwala na wyłączenie stosowania obowiązków w zakresie SCA w odniesieniu do niekonsumentów.

Wyzwanie biznesowo-komunikacyjne

Wdrożenie SCA to dla banków niewątpliwie duże wyzwanie finansowe i operacyjno-organizacyjne. Wiele z dotychczas stosowanych rozwiązań w zakresie uwierzytelniania klientów wymagać może przeglądu i ewentualnego dostosowania do nowych wymagań regulacyjnych, w tym w zakresie posiadanych już procedur i procesów.

Z jednej strony wiązać się to może z koniecznością poniesienia znaczących kosztów, np. wobec potrzeby stworzenia nowych rozwiązań technologicznych czy wymianą instrumentów płatniczych, które na dziś potencjalnie nie spełniają wymogów regulacyjnych. Z drugiej strony rodzi to po stronie banków potrzebę „wyedukowania” własnych klientów, szczególnie konsumentów. Zmieniający się sposób identyfikowania klientów którzy przyzwyczajeni są do bezproblemowego i błyskawicznego procesu (np. w odniesieniu do płatności one-click a’la Amazon), może na początku budzić pewne zdziwienie, o ile nie frustrację. Potrzeba komunikacji będzie również pochodną zmian, które mogą pojawić się w dokumentacji z klientem (regulaminy czy umowy) w związku ze stosowaniem SCA.

Dostosowanie portfolio do wymogów SCA

Rozwiązania w zakresie uwierzytelniania klientów stosowane przez większość banków są bezpieczne. Świadczyć może o tym chociażby fakt, że jako państwo jesteśmy w światowej czołówce, jeżeli chodzi o najniższy wskaźnik oszustw dokonanych z użyciem instrumentów płatniczych. SCA jest jednak wymogiem, który banki muszą spełnić (nieco inaczej kształtuje się sytuacją w przypadku transakcji „korporacyjnych”, o czym w dalszej części). Dwa z trzech faktorów (elementów) to po prostu „must have” po 14 września.

W tym kontekście warto wskazać na pierwszy problem, który pojawia się w kontekście wyboru elementów na potrzeby stosowania SCA. RTS wymaga, aby SCA opierało się na dwóch z trzech faktorów, tj. wiedzy, posiadaniu i/lub cechach klienta i prowadziło do wygenerowania kodu uwierzytelniającego. Art 4 RTS nie wskazuje przy tym, że muszą to być dwa różne elementy. EBA w swojej opinii wskazała jednak, że „[p]ayment service providers therefore need to devise an authentication method that uses two elements from two different categories, for instance one element categorised as knowledge (such as a password) and one as inherence (such as fingerprints)”. Tym samym nie jest przykładowo możliwe zastosowania rozwiązania opierającego się na użyciu mobilnego tokenu (zainstalowanego na smartfonie) oraz kodu jednorazowego przesyłanego w formie sms czy wiadomości push (tutaj pojawia się odrębny problem w zakresie zakwalifikowania takiej wiadomości jako „posiadania”). Oba elementy można bowiem zaliczyć do kategorii „posiadanie” i to korzystające z tego samego urządzenia (smartfona). PS. Taki kod jednorazowy nie jest „wiedzą”, ale właśnie posiadaniem, ponieważ jest „przypisany” do konkretnej karty SIM z numerem potwierdzonym na potrzeby kontaktów z bankiem.

Czy zastosowanie tych dwóch elementów byłoby mniej bezpieczne niż zastosowanie tokenu oraz kodu PIN („wiedza”)? Pytanie pozostawiam otwarte, ponieważ tak naprawdę wszystko zależy od szeregu innych czynników związanych z bezpieczeństwem, np. procesami i procedurami w zakresie wykrywania nieautoryzowanych transakcji.

Kwalifikacja elementów do konkretnych kategorii

Wiele wątpliwości pojawia się w odniesieniu do kategoryzacji konkretnych rozwiazań w kontekście SCA. O ile PIN czy hasło do bankowości elektronicznej bezsprzecznie zaliczyć mozna do kategorii „wiedza” (numeru identyfikacyjnego klienta już nie), to czy kod CVV/CVV2 znajdujący się z tyłu karty będzie takim faktorem? Zdaniem EBA – niestety nie (jest widoczny dla większej liczby „odbiorców”). Pojawiają się jednak wątpliwości czy tzw. dynamic CVC (kod zmieniający się np. co godzinę) będzie takim elementem. W Wielkiej Brytanii pojawiają się głosy, że jak najbardziej tak. Jest to jednak rozwiązanie drogie z punktu widzenia klienta i banków, a więc chyba raczej niepraktyczne.

Innym ciekawym przykładem jest kwestia określenia czym jest „posiadanie”. Przepisy wymagają, aby dostawca stosował odpowiednie metody weryfikacji (walidacji), czy dane urządzenie rzeczywiście należy do osoby „dla której” przeprowadzane jest silne uwierzytelnianie, np. poprzez identyfikację oprogramowania na smartfonie lub w inny podobny sposób. Interesującym rozwiązaniem może być metoda tzw. „device fingerprint”, którą w skrócie można opisać jako „uwierzytelnienie” urządzenia (zebranie danych dotyczących BIOS, parametrów procesora etc.), np. laptopa, jako należącego do konkretnej osoby i tym samym spełniającego wymogi RTS. Stosowanie tej metody może mieć znaczenie w przypadku osób korzystających z bankowości elektronicznej z poziomu przeglądarki (taki dostęp jest często wymagany dla transakcji „wysokokwotowych”.)

FaceID/TouchID – biometria „na drodze” SCA

W jednym z artykułów poświęconych planom względem PSD3 poruszyłem kwestię wykorzystania TouchID (linie papilarne) oraz FaceID (biometria twarzy) na potrzeby stosowania SCA. Wyzwaniem nie jest tutaj zakwalifikowanie tych elementów do kategorii „cecha” klienta, ale kwestii ustalenia podmiotu odpowiedzialnego za weryfikację poprawności tych danych.

Przykładowo, wykorzystanie FaceID (dostępnego np. w Iphone X) do dokonania płatności, co do zasady, odbywa się na zasadzie weryfikacji danych biometrycznych przez „urządzenie” i/lub podmiot trzeci, a nie dostawcę usługi płatniczej, np. bank. Weryfikacja przebiega więc niejako poza „świadomością” i systemami banku, a więc nie ma 100% pewności, że uwierzytelnienie przebiegło zgodnie z wymogami RTS. W takim przypadku, aby mieć tą pewność konieczne byłoby zawarcie odpowiedniej umowy outsourcingowej, która takie bezpieczeństwo by „zbudowało”.

W innym ujęciu teoretycznie możliwe byłoby przeprowadzenie takiej weryfikacji przez urządzenie, ale powinny temu towarzyszyć odpowiednie rozwiązania w zakresie zarządzania ryzykiem. Trudno jednak powiedzieć jakie to mogłyby być rozwiązania.

Wydaje się, że w tym obszarze pomocna byłaby jednoznaczna interpretacja EBA lub innego regulatora. Temat jest bardzo istotny z punktu widzenia banków i ich użytkowników, szczególnie wobec rosnącego „zapotrzebowania” na usługi typu Apple Pay.

Czy to wszystko?

Oczywiście nie. Problemów interpretacyjnych związanych ze stosowaniem SCA jest znacznie więcej. Przykładowo pojawiają się kwestie związane z odpowiedzialnością dostawców za transakcje bez użycia SCA (gdy dostawca znajduje się poza Europejskim Obszarem Gospodarczym) czy problematyka dynamicznego łączenia. Wraz ze zbliżającą się datą 14 września pojawiać się będzie zapewne coraz więcej interpretacji regulatorów, ale i więcej problemów po stronie rynku. Będę śledził te zmiany i z pewnością informował o postępach.