Source: https://finregtech.pl/2019/06/24/no-i-jest-opinia-europejskiego-urzedu-nadzoru-bankowego-eba-w-sprawie-silnego-uwierzytelniania-klientow-sca-jakie-wyzwania-stoja-przed-dostawcami-uslug-platniczych-w-kontekscie-biometrii-i-metod/
Timestamp: 2020-04-08 21:27:13
Legal References Found: art. 22
 art. 4
 art. 24
 art. 24
 art. 25
 art. 46
 art. 2
 art. 4

Document Content:
No i jest. Opinia Europejskiego Urzędu Nadzoru Bankowego (EBA) w sprawie silnego uwierzytelniania klientów (SCA). Jakie wyzwania stoją przed dostawcami usług płatniczych w kontekście biometrii i metod behawioralnych? - www.finregtech.pl
Przeglądasz:Strona główna»Regulacje»PSD2»No i jest. Opinia Europejskiego Urzędu Nadzoru Bankowego (EBA) w sprawie silnego uwierzytelniania klientów (SCA). Jakie wyzwania stoją przed dostawcami usług płatniczych w kontekście biometrii i metod behawioralnych?
Przez Michał Nowakowski	 24 czerwca 2019 Brak komentarzy
Problematyka stosowania silnego uwierzytelniania klientów (Strong Customer Authentication – SCA) to w zasadzie tradycja na www.finregtech.pl. Wyzwania dla banków, które stawia przed nimi ustawa o usługach płatniczych oraz Rozporządzenie 2018/389, to temat, który z pewnością nie zniknie przynajmniej do 14 września. W ostatni piątek Europejski Urząd Nadzoru Bankowego (EBA) wydał opinię dotyczącą stosowania tej metody zabezpieczenia klientów. Jest to opinia o tyle istotna, że przynajmniej częściowo rozwiewa wiele wątpliwości związanych z SCA, choć niektóre zagadnienia nie zostały rozstrzygnięte. W kolejnych artykułach przejdę przez te problemy oraz skonfrontuję je ze znanymi interpretacjami UKNF (nadal czekamy jeszcze na oficjalne stanowisko Urzędu) oraz wcześniejszą opinią EBA. Osoby zainteresowane pogłębieniem podstaw w zakresie stosowania SCA zachęcam do innych moich artykułów (link1; link2). Na pierwszy ogień „cecha” (inherence).
Zanim przejdziemy do analizy poszczególnych faktorów SCA, warto nadmienić, że opinia EBA ma znaczenie również w kontekście potencjalnego podejścia regulatorów do (nie)stosowania SCA po 14 września (jako wariant przejściowy). EBA podkreśliła bowiem, że na zasadzie wyjątku, organy nadzoru mogą podjąć decyzję o współpracy z dostawcami usług płatniczych oraz innymi zainteresowanymi stronami, w tym klientami oraz sprzedawcami czy ich dostawcami w celu wydłużenia terminu na dostosowanie. Wymaga to jednak przedstawienia regulatorowi i wykonania w należyty sposób odpowiedniego planu „migracji” do pełnego SCA.
W tym kontekście EBA podkreśla również potrzebę komunikacji do użytkowników końcowych (jak i innych podmiotów, które muszą dostosować swoje rozwiązania do wymogów SCA, w tym Third Party Providers) – wspominałem już o takiej potrzebie m.in. tutaj. Czekamy na ruch naszego regulatora.
Zacznijmy od „cechy”
Czym jest owa cecha („inherence”)? Generalnie można stwierdzić, że to to kim użytkownik jest i co go wyróżnia spośród innych jednostek. EBA wskazuje na konkretne przykłady, jak np. biometria (odcisk palca, siatkówka oka), w tym także wzorce zachowań (behawioralne), jak np. specyficzny styl poruszania rękami. To czy dany element będzie zaliczony jako faktor SCA jest uzależnione zasadniczo od spełnienia następujących warunków:
1. Dane pozwalające na określenie „unikalności” użytkownika są na tyle wysokiej jakości, że praktycznie bez wątpliwości można stwierdzić, że należą one do tej właśnie osoby;
2. Urządzenia, jak i stosowane oprogramowanie, muszą posiadać odpowiednie zabezpieczenia uniemożliwiające „odkrycie” przez osoby niepowołane elementów uwierzytelniających z kategorii cecha (art. 8 ust. 1 Rozporządzenia 2018/389), np. ujawnienie wzorca;
3. Urządzenia dostępowe i oprogramowanie posiadają odpowiednie zabezpieczenia chroniące przed nieuprawnionym wykorzystaniem elementów biometrycznych (art. 8 ust. 2 Rozporządzenia 2018/389);
4. Zastosowane rozwiązania pozwalają na przyjęcie, że ryzyko uwierzytelnienia osoby trzeciej posługującej się np. skradzionym urządzeniem, jako płatnika jest bardzo niskie a także
5. Wypełnione są warunki z art. 22-27 Rozporządzenia 2018/389, o których niekiedy zapomina się przy ocenie elementów składowych silnego uwierzytelniania klienta, a które mają kolosalne znaczenie w przypadku „inherence”.
Największym wyzwaniem jest właśnie punkt 4. Dlaczego?
Biometria na smartfonie
W dzisiejszych czasach coraz częściej korzystamy z aplikacji mobilnych banków, które instalujemy na naszych smartfonach czy tabletach. Wiele z metod biometrycznych, które wykorzystujemy na potrzeby logowania się do aplikacji bazuje na rozwiązaniach technicznych „zaszytych” na tych urządzeniach. Oznacza to (w pewnym uproszczeniu), że wzorzec biometrycznych nie jest przekazywany do dostawcy usług płatniczych i tam analizowany pod kątem zgodności z wcześniej przekazanym elementem, ale to niejako aplikacja bazuje na potwierdzeniu, które to urządzenie jej przekazuje (po własnej – dość prostej – weryfikacji).
Potencjalny problem, który pojawia się w tym kontekście, to kwestia ustalenia czy przetwarzanie wzorca biometrycznego na urządzeniu niepowiązanym z np. aplikacją (bez możliwości weryfikacji ich autentyczności i prawidłowego powiązania z użytkownikiem przez dostawcę usług płatniczych) będzie spełniało restrykcyjne wymogi Rozporządzenia 2018/389, w tym art. 4 oraz art. 24, które wskazują, że to dostawca stosuje silne uwierzytelnianie (i bada poprawność indywidualnych danych uwierzytelniających). Wydaje się, że najbezpieczniejszym, ale mało realnym, rozwiązaniem byłoby „outsource’owanie” autentykacji wzorca biometrycznego (poza samodzielną weryfikacją). Pytanie kto jednak za to miałby odpowiadać, tj. dostawca urządzenia (Samsung, Apple, Huawei) czy może dostawca oprogramowania (Android, iOS)?
Wobec tych wątpliwości i braku wskazówek ze strony regulatorów należy przyjąć, kierując się m.in. art. 24 ust. 2(a) Rozporządzenia 2018/389, że takie powiązanie i wykorzystanie wzorca, odbywa się na zasadzie ryzyka i to dostawca powinien zapewnić odpowiednie mityganty (very low risk probability of an unauthorised party being authenticated as the payer) nieuprawnionego wykorzystania tych elementów (tutaj wchodzimy dodatkowo w kwestię obowiązków, o których mowa w art. 25 ust. 2(c) Rozporządzenia 2018/389). Jest to jednak temat nierozstrzygnięty i nadal pozostawiający pewne wątpliwości.
„Dozwolone” przez EBA przykłady wykorzystania biometrii
EBA zaproponowała kilka przykładowych rozwiązań, które można zakwalifikować jako „inherence” na potrzeby SCA.
O ile nie budzi wątpliwości możliwość wykorzystania odcisku palca, siatkówki (retina) czy tęczówki (iris) oka czy rozpoznawania głosu, to już np. rozpoznawanie przepływu krwi, geometria dłoni czy metoda polegająca na „ocenie” unikalności użytkownika w oparciu o szybkość pisania, budzić mogą pewien sceptycyzm. Podobne wątpliwości pojawiają się przy przykładach EBA dotyczących rytmu serca, sposobu poruszania się czy trzymania urządzenia dostępowego.
Tutaj EBA wskazuje, że zastosowanie tego typu rozwiązań (biometria plus metody behawioralne) wymaga wysokich standardów bezpieczeństwa, które zapewnią bardzo niski poziom ewentualnego ryzyka oszustwa (fraudu). Ryzyko będzie więc po stronie dostawcy usług płatniczych (i ewentualna odpowiedzialność wynikająca z art. 46 ust. 4a ustawy o usługach płatniczych) i wiele będzie zależało od skuteczności zastosowanych algorytmów (machine learning oraz artificial intelligence).
Osobiście wydaje mi się jednak, że „unikalność” niektórych propozycji, jak np. kąt trzymania urządzenia czy tzw. keystroke dynamics (wpisywanie na klawiaturze, ruchy myszką), może niekiedy być wątpliwa. No i pojawia się jeszcze jeden problem. Aby zastosować ten element musimy uprzednio zebrać dostateczną liczbę wiarygodnych danych na temat użytkownika i tych jego „cech”, aby w ogóle opracować wzorzec zachowania. Oznacza to, że dostawca musiałby uprzednio je zebrać (uzyskując uprzednią zgodę, w tym na przetwarzanie) i dopiero po określonym czasie zaoferować tego typu rozwiązanie. Istotne będzie również rozszerzenie polityki zarządzania ryzykiem, outsourcingu (jeżeli rozwiązanie jest „na zewnątrz”), a także wyznaczenie osób odpowiedzialnych za weryfikację poprawności działania odpowiednich algorytmów.
3DS 2.0 a EBA
EBA w swojej opinii de facto nie przesądziła o losie EMV 3D Secure 2.0, nawet jeżeli w tabeli widnieje, że nie spełnia on wymogów SCA. Rozwiązanie oferowane przez Visa oraz Mastercard opiera się na analizę ryzyka transakcji (na wzór monitoringu transakcji, o którym mowa w art. 2 oraz 18 Rozporządzenia 2018/389).
W dużym uproszczeniu można wskazać, że odpowiednie algorytmy (oferowane przez ww. Visa oraz Mastercard) dokonują w czasie rzeczywistym analizy ryzyka transakcji bazując na wcześniej wykonanych przez użytkownika transakcjach. W opinii EBA takie rozwiązanie nie korzysta de facto z metod behawioralnych – „typowość” określonych kategorii transakcji nie świadczy o tym, że jest to cecha klienta. EBA nie wyklucza jednak, że to w przyszłości się zmieni i dostawcy rozszerzą zakres danych, na których bazują odpowiednie algorytmy. Jeżeli taka zmiana zajdzie, to nie jest wykluczone, że 3DS 2.0 będzie spełniał wymogi SCA.
Stanowisko EBA w zakresie biometrii można uznać za w miarę liberalne. Wiele z „cech” klienta, które nawet dla mnie wydają się dość „ryzykowne” zostały zakwalifikowane przez Urząd jako spełniające kryteria SCA. To o czym jednak należy pamiętać, to to, że Rozporządzenie 2018/389 stawia przed dostawcami usług płatniczych szersze wymagania niż te wskazane w art. 4 czy 8. To obowiązki w zakresie monitoringu, w tym samych algorytmów, bezpieczeństwo transakcji i wzorców biometrycznych, a także liczne rozwiązania organizacyjne. Podejście EBA do biometrii pokazuje, że unijny nadzorca stawia na innowacyjność. Zobaczymy w którym kierunku pójdzie rynek.
W kolejnym artykule poruszę kwestię „posiadania” w kontekście SCA oraz inne element “ogólne” wypływające z opinii..
Poprzedni artykułDlaczego banki uruchamiają produkcyjne API, czyli o postępowaniu w sprawie zwolnienia z fall-back mechanism
Następny artykuł Dwa faktory z tej samej kategorii oraz wyzwania dla płatności eCommerce, czyli opinia Europejskiego Urzędu Nadzoru Bankowego w sprawie stosowania silnego uwierzytelniania klienta.