Rzeczywistość technologiczna zawsze jest o kilka kroków przed regulacjami, które z coraz większym trudem nadążają za zmianami. Ostatnia pochodząca z 2007 r. dyrektywa dotycząca usług płatniczych PSD (Payment Services Directive), nie wytrzymała próby czasu. Po blisko dekadzie obowiązywania ramy prawne nijak się miały do tego, co dzieje się na rynku płatności. Dlatego w styczniu 2016 r. weszła w życie nowa dyrektywa PSD2, która ma przywrócić związek przepisów z rzeczywistością rynkową.

Co nowego wnosi PSD2? W dużym skrócie: obowiązek udostępnienia przynajmniej jednego otwartego interfejsu API (Application Programming Interface), za którego pomocą podmioty trzecie, tzw. TPP (Third Party Provider) będą mogły realizować na rzecz klientów operacje finansowe, głównie płatnicze.

Zobacz również:

• Rząd Ghany pracuje nad regulacjami dotyczącymi AI

Teoretycznie to nic nowego, tak przecież już się dzieje. W Polsce chociażby bardzo dobrze rozwija się obszar pay-by-link, jeden z rodzajów szybkich e-płatności, który już teraz jest przez klientów wybierany nawet częściej niż płatności kartą (jeśli te dwie metody są dane do wyboru). O ile jednak do tej pory podmioty trzecie zawierały indywidualne umowy z bankiem (lub bankami) na świadczenie usług w imieniu klienta, o tyle po wejściu w życie ustawy wprowadzającej PSD2 do krajowego porządku prawnego każdy uprawniony TPP będzie mógł skorzystać z wystawionego przez bank otwartego API bez zawierania z nim jakichkolwiek umów. W Polsce podmioty trzecie będą przy tym musiały uzyskać zezwolenie Komisji Nadzoru Finansowego, z wyjątkiem usług dostępu do informacji o rachunku, gdzie wymagana będzie tylko rejestracja u regulatora.

Pewna jest tylko zmiana

„Regulacja ta z komfortowej sytuacji wypycha nas na trudniejszy rynek. Korzystny dla klienta, ale dla nas trudniejszy” – stwierdza Michał Paprocki, szef ING Services Polska.

„To zmiana, do której się trzeba dobrze przygotować, zarówno w wymiarze technicznym, jak i biznesowym” – dodaje Patryk Nowakowski, CIO BZ WBK

„Jako banki musimy być zgodni z dyrektywą. Pracujemy nad implementacją zaleceń, analizujemy. Myślę, że mimo wszystko to są szanse. Wiem, że opinie są podzielone, ale nie da się tego uniknąć, ponieważ to klasyczny opór przeciwko zmianom. A w dzisiejszych czasach tylko jedno jest pewne: zmiana” – wtóruje Paweł Reichelt, dyrektor Departamentu Bankowości Elektronicznej Plus Bank.

Wdrożenie PSD2 można podzielić na dwa etapy. Pierwszy to wdrożenie obowiązków wynikających z PSD2, drugi zaś, późniejszy: wypełnienie wymogów RTS (Regulacyjnych Standardów Technicznych, Regulatory Technical Standards – wykładni dyrektywy PSD2 wydanej przez Europejski Urząd Nadzoru Bankowego). To wdrożenie już przesuwa się w czasie, ponieważ opóźniło się opiniowanie standardów. Finalny kształt regulacyjnych standardów technicznych dla dyrektywy PSD2 (RTS) poznamy najprawdopodobniej w listopadzie br.. Pozostawi to bankom i innym zainteresowanym instytucjom kolejne 18 miesięcy na wdrożenie wytycznych. Wtedy faktycznie banki będą zmuszone do wystawienia API dla TPP.

W Polsce najprawdopodobniej będzie to lokalnie wypracowany standard Polish API. „Aktywnie uczestniczymy w Polish API, by wymogi regulacyjne zdefiniowane w RTS-ach były implementowane w sposób jednolity w ramach sektora” – mówi Adam Marciniak, wiceprezes PKO BP, nadzorujący Obszar Informatyki i Usług. „Komisja Nadzoru Finansowego oczekuje, aby ten standard powstał jak najszybciej. Następnie planujemy przejść do fazy implementacyjnej, wykorzystując infrastrukturę sektorową w ramach KIR, który może pełnić rolę huba API, gdzie wszystkie TPP mogłoby się wpinać do sektora w celu konsumpcji usług” – dodaje.

Niektórzy eksperci uważają, że gdyby inne kraje unijne znajdowały się na takim poziomie rozwoju bankowości jak Polska, dyrektywa PSD2 nie byłaby potrzebna jako narzucana odgórnie norma. Polskie banki od dawna mają API dla firm zewnętrznych, a Polacy aktywnie korzystają z takich rozwiązań. Wiele aplikacji bankowych wykorzystuje API, np. pod wyszukiwarką aplikacyjną typu „znajdź najbliższy bankomat” kryje się API z Google Maps.

Klamka zapadła

Szansa czy zagrożenie? Takie pytanie zadają sobie bankowcy, po cichu mówiąc, że gdyby zapytać, co naprawdę banki sądzą o PSD2… Klamka jednak zapadła, a do nowych przepisów należy się przygotować/

Co banki mogą zyskać? Na pewno nowe możliwości biznesowe. Niedaleka przyszłość to nie tylko transakcje, ale także usługi dodane, usługi premium, które na bazie API mogłyby być świadczone i stać się nowym strumieniem dochodów dla banków. Można sobie wyobrazić sytuację, że w momencie wysyłania przelewu bank w imieniu firmy wykonującej przelew poświadcza i powiadamia drugą stronę operacji, że środki właśnie zostały przesłane. Poza tym szereg usprawnień, m.in. stworzenie agregatorów, jakie w ramach bankowości elektronicznej danego banku będą pokazywać wszelkie inne rachunki z innych banków, co do których dyspozycję wydał klient.

Ciekawą perspektywą wydaje się też możliwość dostępu klienta niezwiązanego z danym bankiem do swoich rachunków w innym banku, ale za pomocą aplikacji mobilnej banku, która podoba mu się bardziej, czy której funkcjonalność ceni sobie bardziej. Klient będzie mógł głosować nogami, z jakim bankiem i w jakim zakresie układać swoją współpracę. Łatwiej będzie też przenieść rachunek z historią i sprawami, które klienta z danym bankiem wiążą – zlecenia stałe, polecenia zapłaty, rachunki odbiorców.

Co prawda ograniczeniem jest numer rachunku, obecnie numer IBAN ma zaszyty numer rozliczeniowy banku, ale nie jest niemożliwe rozliczanie transakcji w wybranym banku, pomimo że numer rozliczeniowy wskazuje na inny bank. Jednak do sytuacji, jaka nastąpiła z uwolnieniem numerów telefonów na rynku telefonii komórkowej, jeszcze daleko.

Wystawiając API, banki będą spinać się z aplikacjami zewnętrznymi, ale same także uzyskają możliwość budowania aplikacji, które mogą pełnić funkcję integratorów (Personal Finance Management). API działa bowiem dwukierunkowo, pozwalając na działania defensywne, ale i ofensywne.

Niebezpieczne drapanie ekranu

Kwestią, która spędza sen z powiek bankowym specjalistom IT, jest zapewnienie swoim klientom bezpieczeństwa. W momencie otwarcia się banków na zewnątrz poprzez API na pewno pojawią się nowe rodzaje ataków, o których trzeba myśleć już dziś. „Jako banki na pewno będziemy chcieli mieć świadomość, co się dzieje w warstwie API, kto je wywołuje i w jakim celu. Będziemy dbali o bezpieczeństwo, ponieważ otwarcie API to poniekąd otworzenie bezpośredniego dostępu do bankowych systemów transakcyjnych, i to musi być bardzo dobrze chronione” – stwierdza Patryk Nowakowski.

Stosując screen scraping, klient godzi się, by podmiot inny niż jego bank dysponował jego rachunkiem. Takie rozwiązanie działa na Zachodzie, w Polsce w 2015 roku KNF wydała negatywną opinię co do stosowania screen scrapingu, m.in. przez mBank, Alior Bank czy Idea Bank.

Udostępnianie usług i danych podmiotom trzecim, wpisujące się w trend określany jako Ekonomia API, wiąże się z kilkoma potencjalnie niebezpiecznymi hasłami. Jednym z nich jest screen scraping, polegający na udostępnianiu przez klienta banku innemu bankowi lub podmiotowi swoich danych do logowania. Klient w ten sposób, świadomie lub nie, godzi się, by podmiot inny niż jego bank dysponował jego rachunkiem. Takie rozwiązanie działa na Zachodzie, w Polsce w 2015 r. KNF wydała jednoznaczną, negatywną opinię co do stosowania screen scrapingu, m.in. przez mBank, Alior Bank czy Idea Bank. Sprawa screen scrapingu wróciła też później, przy wykorzystaniu go przez niektóre banki do dostępu do PUE ZUS w imieniu klientów, co nadszarpnęło zaufanie do sektora bankowego i reputację środowiska.

Złodziej czy TPP?

Wielu polskich bankowców jest do idei screen scrapingu nastawionych co najmniej sceptycznie, uważając, że to narażanie bezpieczeństwa klienta. Powierzanie loginu i hasła podmiotowi trzeciemu, jakkolwiek dane te zabezpieczono, wydaje się nadużywać zaufanie, przy okazji łamiąc podstawową zasadę: nie udostępniaj swojego loginu i hasła nikomu. Dyrektywa PSD2 pozwala przy wystawieniu API na ograniczenie dostępu do poszczególnych rachunków i dotyczy instrumentów płatniczych. Screen scraping zaś to całkowity wgląd w portfel klienta: kredyty hipoteczne, gotówkowe, rachunki bieżące, podpięte rachunki maklerskie. Klient może nie chcieć udostępniać swój portfel w zamian za możliwość zrobienia szybkiego przelewu.

Jeśli ustawa wymusi, że klient będzie mógł podawać swój login i hasło podmiotowi trzeciemu, wieloletnia edukacja prowadzona przez banki pójdzie na marne. Klient nie będzie wiedział, czy hasło podaje certyfikowanemu TPP czy podszywającemu się złodziejowi.

Należy przyznać, że polskie banki, reprezentowane przez ZBP, mocno lobbowały, by zmienić zapis dotyczący m.in. wykorzystania screen scrapingu. Obecnie screen scraping w PSD2 nie jest wprost zabroniony, ale też nie jest narzucony. W RTS-ach istnieje zapis, że jest to rozwiązanie awaryjne – bank powinien dostarczyć interfejs do komunikacji, który powinien być przez regulatora zatwierdzony. Jeżeli bank nie jest w stanie, albo nie chce wystawić interfejsu, w ostateczności może pozwolić na screen scrapping, ale TPP, który będzie chciał z takiej możliwości skorzystać, powinien móc się przedstawić, by było jasne, kto dostaje się w danym momencie przez serwis – klient czy TPP. Jest to na pewno jakaś wola kontroli strony trzeciej.

To, czego się nie udało, to rezygnacja z credential sharing. O jego utrzymanie podobno zabiegały pozaeuropejskie duże fintechy. „W tym przypadku jest wprost w PSD2 napisane, że nie może to być jedyna opcja, w związku z tym w ramach Polish API zaproponujemy konkretne, alternatywne rozwiązanie do naszego działającego standardu opartego na redirection. Myślimy o czymś w rodzaju one-timepassword, np. wykorzystanie SMS do logowania poza bankiem, by klienci do autentyfikacji nie musieli używać narzędzi stosowanych obecnie” – wyjaśnia Adam Marciniak.

Jeśli ustawa wymusi, że klient będzie mógł podawać swój login i hasło podmiotowi trzeciemu, wieloletnia edukacja prowadzona przez banki pójdzie na marne. Klient nie będzie wiedział, czy hasło podaje certyfikowanemu TPP czy podszywającemu się złodziejowi.

Banki chcą dążyć do rozwiązań sektorowych, by zabezpieczyć się w nowej rzeczywistości. Moment jest dobry, ponieważ będzie wchodziła w życie ustawa o STIR (System Teleinformatyczny Izby Rozliczeniowej), dająca możliwość blokowania kont bankowych, które mogłyby być wykorzystywane przez przestępców. Jeśli KIR miałby być hubem dla API i jednocześnie być platformą dla STIR,gdzie gromadzone będą informacje o rachunkach, to niewiele już brakuje, by na tej bazie powstał efektywny antyfraud, pilnujący naszych pieniędzy.