Nasze dane mniej bezpieczne od września?

W połowie września wchodzi w życie unijna dyrektywa PSD2, która rozpoczyna erę tzw. open bankingu. Banki muszą zapewnić dostęp do niektórych danych klientów zewnętrznym podmiotom tzw. TPP czyli  na przykład fintechom, które z kolei na ich podstawie będą mogły tworzyć i oferować produkty klientom.

Nadal jednak nie wiadomo czy głównym narzędziem będzie bezpieczne API, czyli rodzaj wtyczki przez którą dane będą przekazywane w kontrolowany sposób, czy też nie zostanie dopuszczone drugie - tzw. procedura awaryjna (fallback option), która podmiotom trzecim daje zupełnie swobodny dostęp do danych klienta (poprzez tzw. screen scraping). Robert Trętowski, wiceprezes KIR liczy, że nadzorcom unijnym i krajowym uda się jednak przewalczyć bezpieczniejszą procedurę. Pozostaje też problem tego, że po wakacjach na rynku finansowym idą wielkie zmiany, a na razie nie wiadomo jak one będą w praktyce wyglądać i w związku z tym co należy i jak tłumaczyć klientom.

- Polski sektor bankowy przez lata wypracował już bardzo dobre, bezpieczne i sprawdzone rozwiązania do płatności w internecie. PSD2 zaimplementowane w bankach oznacza, że ten cykl płatności będzie wyglądał inaczej, więc trzeba będzie na nowo tłumaczyć co jest bezpieczne, a co niebezpieczne - mówi wiceprezes KIR. Podkreśla jeszcze jedną bardzo istotną rzecz, o której się zapomina: ułatwienia jakie dyrektywa daje pozabankowym firmom nie dotyczą tylko płatności.

- W kontekście PSD2 wszyscy się skupiają na płatnościach, a ja uważam, że temat udostępniania danych bankowych, historii rachunków będzie wielkim novum. Pytanie czy klienci świadomie będą podejmować decyzję o udostępnianiu swoich danych, często bardzo wrażliwych jak dochody, spłaty kart, albo informacje o tym czy mają czy nie mają kredyty hipoteczne - mówi Robert Trętowski.

- Te dane po wejściu dyrektywy PDSD2 będą mogły być udostępniane tzw. podmiotom trzecim, czyli niebankowym i trzeba będzie zawierzać, że one mają wysoki poziom zabezpieczenia i usuną te dane, wtedy gdy nie będą im już potrzebne - dodaje. Dyrektywa teoretyczne to powinna gwarantować, ale w praktyce może wyglądać to różnie. - Zweryfikowanie takiego podmiotu przez klienta będzie wymagało dużej aktywności i determinacji. Dyskutujemy też o tym, żeby być może na stronie bankowej, gdy nastąpi przekierowanie, publikować informacje na temat danego podmiotu - dodaje Trętowski.

Czy bank może odmówić danych klienta podmiotowi TPP, który spełnia formalne wymogi i prosi o dane klienta? - Dyrektywa wręcz narzuca na bank konieczność zastosowania swoich systemów antyfraudowych, więc jeśli będzie jakieś  niewiarygodne, nietypowe zachowanie, to  będzie mógł odrzucić, ale będzie musiał udokumentować dlaczego tak zrobił- wyjaśnia ekspert KIR.

Dodaje, że właśnie dlatego wierzy w sektorowe rozwiązania, które proponuje KIR, dzięki którym  banki będą mogły między sobą podzielić się wiedzą który TPP jest wiarygodny, a który nie.

- Chodzi tu nie tylko o wiarygodność samego podmiotu, ale o to czy nie ma ataku na TPP, bo przecież może być sytuacja w której nastąpił atak na jego infrastrukturę albo ktoś się pod niego podszywa - wyjaśnia.

Duże ryzyko jest związane z możliwością stosowania procedury awaryjnej bazującej na tzw. screen scrapingu.  Interfejs awaryjny bazuje bowiem na screen scrappingu oraz tzw. credential sharing  (narzędzia uwierzytelniania i autentykacji jak login i hasło), czyli dwóch mechanizmach, których staramy się w sektorze bankowym nie używać.

Jeśli udostępnimy wspomniane elementy to nie mamy kontroli nad tym co się z nimi dzieje i nie mamy kontroli nad tym, czy TPP wchodząc na konto i czytając interfejs użytkownika czyta tylko to na co się użytkownik zgodził czy wszystko co się znajduje w bankowości elektronicznej łącznie z adresem mail, numerem dowodu itd.

- Liczymy na to, że jednak znajdziemy sposób żeby zarówno krajowy jak i unijny nadzorca przychylił się do wniosków zwalniających z opcji fallback (procedura awaryjna) i żebyśmy w Polsce bazowali przede wszystkim na API - dodaje ekspert.

Polish API wprowadza pewien standard i w oparciu o to jest przygotowana komunikacja do klientów, co jest bezpieczne a co niebezpieczne. W sytuacji gdy trzeba będzie otworzyć drugi  interfejs, konieczna będzie nowa i inna komunikacja do klientów. Mnogość interfejsów, zwłaszcza jeśli są dwa tak skrajnie różne, będą wprowadzały mętlik w głowach klientów. - My jesteśmy zdeterminowani do tego żeby jednak próbować obronić standard Polish API jako jedyny spełniający wszystkie normy i postarać się nie implementować metody awaryjnej - podkreśla Trętowski. Zaznacza jednak, że sektor przygotowuje się też na gorszy scenariusz i pracuje nad tym jak dodatkowo zabezpieczyć procedurę awaryjną.

Monika Krześniak-Sajewicz