Silne uwierzytelnienie klienta dla płatności korporacyjnych? A może zwolnienie z art. 17? Jakie wyzwania?
Jednym z wyzwań przed którymi stają obecnie banki to stosowanie tzw. silnego uwierzytelnienia klientów (SCA). Temat ten został już omówiony w wielu publikacjach (klik1; klik2; klik3; klik4). Wiele wątpliwości budzi nadal stosowanie biometrii na urządzeniach końcowych, sensowne rozwiązania dla e-Commerce kartami płatniczymi czy stosowanie niektórych zwolnień z obowiązku stosowania SCA. Niewiele miejsca poświęca się jednak tematowi płatności korporacyjnych dokonywanych zazwyczaj w inny sposób niż ma to miejsce w przypadku klientów detalicznych. Tematyka ta jest też dość „skąpo” opisana w samym Rozporządzeniu 2018/389, które zasadniczo odnosi się do niej w art. 17 traktującym o zwolnieniu z obowiązku stosowania SCA. Celem artykułu jest raczej wywołanie dyskusji niż jednoznaczne stawianie tez.
Choć tematykę zwolnienia z obowiązku stosowania SCA dla płatności reguluje wyłącznie art. 17 Rozporządzenia 2018/389, to w praktyce zastosowania mają praktycznie wszystkie artykuły dotyczące bezpieczeństwa transakcji (w tym dotyczące monitoringu oraz integralności danych). Szczególne znaczenie ma również art. 5 dotyczący dynamicznego łączenia, który stanowi duże wyzwanie dla wielu płatności korporacyjnych, np. dla tzw. payrolli, czyli płatności dla pracowników. Znaczenie ma również rekomendacja D KNF (w zakresie bezpieczeństwa teleinformatycznego) oraz Rekomendacja SecurePay KNF.
Jak wyglądają transakcje korporacyjne?
Zupełnie inaczej niż dla klientów detalicznych czy nawet mikroprzedsiębiorców. Generalnie można wyróżnić dwa 
sposób w jaki klienci korporacyjni „łączą” się z bankiem w celu wykonania określonych czynności:
- Application Programming Interface (API);
- Host-to-host.
Oba rozwiązania niekiedy nazywa się WebServices. Pierwsze rozwiązanie opiera się na integracji z systemami bankowymi, które umożliwiają wymianę komunikatów, w tym dotyczących transakcji, m.in. z użyciem systemów ERP (rozumiany jako system księgowy). Jest to rozwiązanie bardzo praktyczne, jednakże nie do końca efektywne dla płatności zawierających znaczną liczbę odbiorców. Inny, co do zasady, jest też sposób identyfikowania się klienta z systemami (z użyciem certyfikatów, np. eIDAS).
Rozwiązanie host-to-host również oparte jest na unikalnej komunikacji z bankiem i także może wykorzystywać szyfrowane klucze lub certyfikaty. Inny jest jednak sposób w jaki klient korporacyjny tego dokonuje. Zazwyczaj wygląda to w ten sposób, że klient otrzymuje dedykowany adres serwera (zabezpieczonego, np. poprzez https) za pomocą której może dokonać uploadu (wysłania) pliku z np. płatnościami (zazwyczaj plik ma format xml). Następnie po stronie banku podlega on przetworzeniu i wykonaniu i/lub przekazaniu komunikatu o błędach.
Tego typu rozwiązania pozwalają na uproszczenie i przyśpieszenie dokonywania transakcji dla rozbudowanych list odbiorców, co może mieć szczególne znaczenie przy zbiorczych płatnościach za faktury, czy wynagrodzenie pracowników. Jest jeszcze SWIFT, ale to odrębny temat.
Jaki jest z nimi problem?
Rozporządzenie 2018/389 w art. 5 nakłada na dostawców usług płatniczych obowiązek wprowadzenia tzw. 
dynamicznego łączenia. W pewnym uproszczeniu (po więcej zapraszam do tego artykułu) polega ono na poinformowaniu użytkownika (płatnika) o kwocie i odbiorcach danej płatności (np. poprzez SMS z kodem autoryzującym). I tutaj pojawia się największy problem. Trudno bowiem wyobrazić sobie rozwiązanie, które sensownie adresuje ten wymóg. Na rynku pojawiają się różne propozycje, jak np. generowanie szyfrowany plików pdf dostępnych w elektronicznej bankowości oraz przesyłanie plików kontrolnych. W praktyce jest to jednak duże wyzwanie.
Innym powodem dla którego przewidziano możliwość „wyłączenia” stosowania SCA dla tej szczególnej kategorii podmiotów jest oczywiście inny kanał komunikacji pomiędzy bankiem a klientem (nie oznacza, że mniej bezpiecznym – wręcz przeciwnie), a także możliwość bardziej swobodnego kształtowania relacji kontraktowych. Wprowadzenie rozwiązań typu API czy host-to-host to uproszczenie całego procesu, a stosowanie silnego uwierzytelnienia to jednak dodatkowy etap, który wpływa na całokształt czynności. Ma to ścisły związek z profesjonalnym charakterem prowadzonej działalności po obu stronach.
A więc mamy art. 17
Z pomocą przychodzi wspomniany art. 17 Rozporządzenia 2018/389, który dopuszcza możliwość „wyłączenia” stosowania silnego uwierzytelniania w odniesieniu do procesów lub protokołów, które udostępnia się wyłącznie płatnikom niebędącym konsumentami. Z dwoma zastrzeżeniami:
- Wyłączenie stosuje się wobec klienta będącego osobą prawną oraz
- Dostawca usług płatniczych (bank) uzyska ocenę regulatora, w której to stwierdzone zostanie, że ww. procesy i protokoły gwarantują poziom bezpieczeństwa równoważny co najmniej poziomowi przewidzianemu w PSD2 (w praktyce Rozporządzeniu 2018/389 oraz ustawie o usługach płatniczych).
Z lektury tego przepisu wyłania się kilka kwestii wymagających wyjaśnienia.
Tylko osoby prawne?
Literalne brzmienie art. 17 „nakazuje” ograniczyć wyłączenie zwolnienia wyłącznie do osób prawnych. Co to 
oznacza w praktyce? Z komercyjnego punktu widzenia ograniczamy się więc do spółek kapitałowych (akcyjna, z o.o.), spółdzielni oraz przedsiębiorstw państwowych (mamy tutaj oczywiście kategorie podmiotów publicznych, ale chyba nie do końca o to chodziło prawodawcy). Rozsądnym podejście jest więc przyjęcie, że zwolnienie odnosi się do szerokiej kategorii podmiotów (przedsiębiorców) o charakterze zbliżonym do osób prawnych, a więc np. do spółek osobowych, które wykazują równie profesjonalny charakter.
Pytaniem otwartym do dyskusji jest czy takie zwolnienie obejmowałoby również osoby fizyczne prowadzące działalność gospodarczą. Z jednej strony ich działalność ma charakter profesjonalny, jednakże teoretycznie znajdują się one na mniej uprzywilejowanej pozycji.
Czy płatności kartami korporacyjnymi łapią się pod zwolnienie?
Patrząc przez pryzmat analizowanego przepisu – to zależy. Jeżeli dostawca usług płatniczych jest w stanie 
wykazać, że stosowane przez niego protokoły i procesy są udostępnianie klientom (płatnikom – tutaj pojawia się problem czy np. pracownik korzystający z karty korporacyjnej jest płatnikiem, czy też jego pracodawca) niebędącym konsumentami i są oczywiście tak samo bezpieczne jak te dla SCA, to teoretycznie tak. W praktyce wydaje mi się jednak, że nie jest możliwe ze względu na konstrukcję art. 17 oraz praktyczne trudności w wykazaniu tej kwestii (płatności kartą dokonywane są poza obiegiem zamkniętym w terminalach „nieobsługiwanych” przez dostawcę – choć można wyobrazić sobie zastosowanie bardziej rozbudowanych konstrukcji) przed regulatorem.
Jakie wymogi należy spełnić?
To kolejny trudny temat. EBA wypowiedziała się dwukrotnie w swoich QnA w tym przedmiocie (klik1; klik2) oraz w swojej opinii z 2018 r., jednak są to bardzo skąpe informacje i ograniczają się raczej do stwierdzenia, że Rozporządzenie 2018/389 nie przesądza o wymaganiach dla takich procesów i protokołów (to dostawca oraz regulator – ostatecznie – dokonują oceny bezpieczeństwa).
A te procesy i protokoły muszą być równie (co nie oznacza, że takie same) bezpieczne jak te przewidziane dla płatności z SCA. Wymaga to więc bardzo dokładnej analizy procesów, procedur wewnętrznych (bezpieczeństwa, kontroli wewnętrznej, zarządzania ryzykiem i fraudami) oraz zewnętrznych, a także określenie zasad odpowiedzialności i eskalacji w przypadku zidentyfikowanych zagrożeń, w tym wykrycia nieautoryzowanych transakcji. Ważne jest posiadanie odpowiedniego systemu monitorowania transakcji, o którym mowa chociażby w art. 2 czy audytowanie tych rozwiązań (i określenie tych zasad zgodnie z art. 3).
Nie należy zapominać, że w tych ramach mieści się również konieczność zapewnienia odpowiednich rozwiązań 
w zakresie szyfrowania, maskowania i przesyłania danych uwierzytelniających, a także kontroli i zapisu logów. Szczególne znaczenie będą miały art. 28 oraz 29 Rozporządzenia 2018/389, które odnoszą się do wymogów względem komunikacji pomiędzy urządzeniami klientami a systemami banku.
Jaka procedura? Co z odpowiedzialnością?
Szczegółowa procedura nie została w żaden sposób określona. Oznacza to, że w zasadzie każda forma wyrażenia przez regulatora aprobaty dla stosowanych rozwiązań powinna być akceptowalna. Bazując na komunikacie Komisji Nadzoru Finansowego (KNF) w sprawie zwolnienia z obowiązku stosowania mechanizmu awaryjnego (fall-back) (pisałem o nim tutaj) można dojść do następujących wniosków:
- 17 Rozporządzenia może stanowić samoistną podstawę do udzielenia zwolnienia, ale może on być stosowany dopiero od 14 września 2019 r.;
- Po 14 września zasadnym byłoby więc złożenie wniosku o takie zwolnienie w trybie administracyjnym, tj. z powołaniem się na wspomniany art. 17;
- Do tego czasu mamy dwa wyjścia:
- Czekać na 14 września i tworzyć jednocześnie odpowiednie rozwiązania w zakresie SCA lub
- Na zasadzie analogii do procedury wskazanej w ww. komunikacie – złożyć do KNF prośbę o zbadanie tych rozwiązań w ramach bieżącego nadzoru (zgodnie z Prawem bankowym) i jednocześnie po 14 września – złożyć ponownie wniosek (pytanie czy KNF wyda w tym przedmiocie decyzję administracyjną czy rozstrzygnie tę kwestię w inny sposób).
To na co warto jednak zwrócić uwagę to kwestia odpowiedzialności za nieautoryzowane transakcje (pomocny 
będzie tu inny komunikat KNF w sprawie eCommerce, o którym pisałem tutaj). Ponieważ w przypadku pozostałych wyłączeń z obowiązku stosowania silnego uwierzytelnienia nie ma wątpliwości co do zakresu odpowiedzialności za nieautoryzowane transakcje (ryzyko jest po stronie dostawcy stosującego wyłączenie – art. 46 ust. 4a ustawy o usługach płatniczych). Co jednak w przypadku, gdy mamy oficjalne potwierdzenie ze strony regulatora, że rozwiązania są bezpieczne? Czy to nie zmienia nieco ostatecznej oceny i nie powinno wpłynąć na złagodzenie tego reżimu prawnego (oczywiście abstrahujemy tutaj od możliwości uwolnienia się od odpowiedzialności na co zezwala art. 33 ustawy o usługach płatniczych)? Ten temat jest również otwarty i z pewnością zostanie poruszony w przyszłości.