W najbliższy poniedziałek Komisja Europejska opublikuje rozporządzenie do dyrektywy PSD II w sprawie bezpiecznego porozumiewania się oraz silnego uwierzytelnienia użytkownika (SCA – strong customer authentication), jakie stosować będą musiały banki i inni dostawcy usług płatniczych. Rozporządzenie zostało przygotowane na bazie projektu regulacyjnych standardów technicznych, czyli tzw. RTS, przedstawionego przez Europejski Urząd Nadzoru Bankowego w lutym 2017 r. PSD II nakazuje zastosować rozporządzenie 18 miesięcy po jego ogłoszeniu.

Kluczowym elementem dokumentu są wyjątki od stosowania SCA. Gdyby ich nie było, za 18 miesięcy dzisiejsze hasło jednorazowe wysyłane np. SMS-em byłoby wymagane przy każdym logowaniu do rachunku w internecie czy transakcji w sieci, a kod PIN lub podpis własnoręczny byłby wymagany podczas każdej transakcji zbliżeniowej czy płatności za przejazd autostradą.

Przeczytajcie także: • Dyrektywa PSD II zmieni sposób korzystania z kart

Wśród wyjątków kluczowe jest wyłączenie od silnego uwierzytelnienia zdalnych, elektronicznych transakcji niskiego ryzyka, możliwe w sytuacji gdy np. bank korzysta z analizy płatności w czasie rzeczywistym. Wyłączenie to uratuje metodę płatności kartą zwaną "card-on-file". Przy tym procesie raz zarejestrowaną kartą u danego sprzedawcy można w przyszłości płacić bez konieczności wykonywania jakichkolwiek czynności. Tak to działa np. w aplikacji Uber. Najprawdopodobniej jednak w końcowym RTS nie zobaczycie rozwiązania, o które miesiącami walczył sektor e-commerce, czyli aby o zastosowaniu tego wyłączenia mógł decydować nie wydawca karty, ale akceptant i aby jego decyzja była wiążąca dla wydawcy.

Spodziewane jest odrębne wyłączenie od wymogu silnego uwierzytelnienia dla transakcji w bankowości korporacyjnej, dokonywanych w określonym kanale komunikacji z bankiem dostępnym tylko dla klientów niebędących konsumentami. Warunkiem będzie pozytywna opinia krajowego organu nadzoru, potwierdzająca, że dany kanał komunikacji zapewnia porównywalne bezpieczeństwo jak w przypadku silnego uwierzytelnienia wymaganego przez PSD II.

Ponadto w proponowanym przez Komisję Europejską rozporządzeniu doprecyzowane zostaną zasady, na których dostawcy rachunków – a w Polsce to głównie banki i spółdzielcze kasy oszczędnościowo-kredytowe – będą musieli udostępnić podmiotom trzecim, a więc np. fintechom, interfejs do prowadzonych przez siebie rachunków. Najczęściej w tym kontekście dyskutuje się o zastosowaniu technologii API. Zakres danych udostępnianych przez interfejs, jego wydajność i niezawodność powinna być zasadniczo analogiczna do parametrów interfejsu udostępnianego klientom bankowości elektronicznej. To oznacza bardzo duże koszty dla banków i SKOK-ów jeśli ich baza klientów liczy się w milionach, gdyż ruch generowany przez podmioty trzecie najprawdopodobniej nie będzie się rozkładał tak jak ruch klientów.

Przeczytajcie także: • Chmury nad chmurą obliczeniową

Alternatywnie banki i SKOK-i będą mogły zapewnić podmiotom trzecim możliwość korzystania z interfejsu używanego przez klientów bankowości elektronicznej. Będą musiały go jednak zmodyfikować w ten sposób, by można było spełnić kluczowe wymogi PSD II. Chodzi tu głównie o łatwą identyfikację podmiotu trzeciego wobec banku oraz o to, by zakres danych udostępnianych w ten sposób był ograniczony. To ukłon w stronę pierwotnej dyskusji o drugim komplecie danych do logowania na rachunek.

Jeśli dostawca rachunku zastosuje interfejs API dla podmiotów trzecich, zasadniczo będzie musiał zaoferować na stałe mechanizm zastępczy, na wypadek gdyby API trwale lub czasowo nie działało poprawnie. Z tego obowiązku bank będzie mógł jednak zostać zwolniony przez krajowy organ nadzoru, jeśli zastosowany interfejs zagwarantuje poprawne działanie. Prawdopodobnie będzie musiało powstać ciało opiniujące takie zwolnienia, składające się z przedstawicieli firm komercyjnych i nadzoru.

Natomiast gdy interfejs API nie będzie działał poprawnie a dostawcy rachunków nie zaoferują stałego mechanizmu zastępczego, podmioty trzecie będą mogły skorzystać z jeszcze innego mechanizmu zastępczego, a więc dostępu w trybie emulacji użytkownika. W tym celu będą jednak musiały zidentyfikować się przed dostawcą rachunku, rejestrować zdarzenie oraz powiadomić o skorzystaniu z tego mechanizmu krajowy organu nadzoru, czyli w polskiej sytuacji Komisję Nadzoru Finansowego.

Dostęp do rachunku w inny sposób będzie niedopuszczalny. Banki będą mogły go blokować, a podmioty trzecie nie będą mogły podejmować takich prób bez narażania się na sankcje. Natomiast na potrzeby osiemnastomiesięcznego okresu przejściowego oczekuje się, że rozporządzenie KE potwierdzi dopuszczalność stosowania przez podmioty trzecie dotychczasowych metod dostępu (w tym screen scraping) oraz brak konieczności identyfikowania się w tym modelu w sposób określony przez PSD II.

Rozporządzenie KE zostanie teraz przedstawione do dyskusji innym organom Unii Europejskiej, w tym przede wszystkim Parlamentowi Europejskiemu. Oczekuje się, że ostateczne zakończenie prac nad rozporządzeniem nastąpi w marcu 2018 r. Gdyby do tego doszło, to rozporządzenie obowiązywałoby finalnie od września 2019 r.

---

Dr Krzysztof Korus, dLK Legal
Artykuł powstał przy współpracy z kancelarią dLK Legal

Autor jest radcą prawnym, doktorem nauk prawnych i ekonomistą. Ekspert w zakresie usług płatniczych, prawa nowych technologii oraz prawa bankowego. Uczestniczy w pracach strumienia "Blockchain i kryptowaluty" przy Ministerstwie Cyfryzacji w ramach programu "Od papierowej do cyfrowej Polski". Współautor raportów "Study Impact of the PSD" oraz "Principles, Definitions and Model Rules of European Private Law" dla Komisji Europejskiej. Członek European Payments Consulting Association i rady programowej miesięcznika "Monitor Prawa Bankowego" oraz ekspert prawny Polskiej Organizacji Niebankowych Instytucji Płatności.