Za kilka dni rusza kongres Impact z udziałem przedstawicieli KIR-u, którzy będą mówić tam między innymi o wpływie dyrektywy PSD II na rynek finansowy w Polsce. Zbiega się to w czasie z opublikowanym właśnie przez Komisję Europejską rozporządzeniem wykonawczym do PSD II. Decyduje ono w znacznym stopniu o interfejsie API, za pośrednictwem którego banki będą udzielać fintechom dostępu do prowadzonych przez siebie rachunków. KIR bierze udział w pracach w tym zakresie. Jak Pana zdaniem takie bankowe API w polskich warunkach powinno wyglądać?
Od wielu lat, właściwie od początku bankowości elektronicznej na polskim rynku, działające tu instytucje komercyjne i państwowe, w szczególności nadzorcze, kładą duży nacisk na edukację klientów w zakresie cyberbezpieczeństwa. Jednym z głównych jej elementów, na którym jest ona w gruncie rzeczy zakotwiczona, jest zasada, by nigdy i nikomu nie przekazywać loginu i hasła do rachunku internetowego. W moim przekonaniu to właśnie praca włożona w edukację użytkowników bankowości elektronicznej przez banki i Komisję Nadzoru Finansowego stoją za tym, że na polskim rynku cyberprzestępcy mają trudne życie, a systemy bankowe skutecznie opierają się atakom.
Jednocześnie, w odróżnieniu od innych rynków, w Polsce dostęp integratorów płatności do inicjowania płatności z rachunku bankowego, dzięki współpracy z bankami i wypracowaniu bezpiecznego modelu pay by link, był i jest szeroki, a pay by link jest dominującym instrumentem płatniczym w polskim e-commerce. Dlatego uważam, że sposób dostępu do rachunków bankowych realizowany na rzecz podmiotów trzecich powinien odbywać się poprzez API uwzględniające tę specyfikę polskiego rynku. Wyjdzie to na dobre zarówno sektorowi jak i samym konsumentom. Dodam, że takie stanowisko prezentują nie tylko banki, ale jest ono podzielane przez integratorów płatności, którzy również doceniają wagę bezpieczeństwa w tym obszarze.
A jak korzystanie z takiego API będzie wyglądało w praktyce?
W dużym stopniu będzie przypominać proces wykorzystywany dzisiaj podczas wykonywania przelewu pay by link. Klient, korzystający z usług zewnętrznego dostawcy, wybiera na jego stronie internetowej logo swojego banku, a następnie jest przekierowywany do witryny bankowości elektronicznej. W bezpiecznym środowisku bankowym podaje swoje hasło i login do rachunku, a następnie potwierdza transakcję. Analogicznie może to wyglądać przy wykorzystaniu API. Z tym że dziś firmy świadczące usługi typu pay by link muszą zawierać umowy bilateralne z każdym z banków. Dzięki PSD II nie będzie to konieczne, bo banki będą zobowiązane umożliwić komunikację swoich systemów z systemami podmiotów trzecich, właśnie za pośrednictwem interfejsu API.
Należy zwrócić tu uwagę na stosowaną również u nas modyfikację standardowej metody pay by link, opartą o kod jednorazowy Blik. W ostatnim czasie bardzo zyskuje ona na popularności i nie wymaga przekierowania na stronę banku, zapewniając jednocześnie najwyższe standardy bezpieczeństwa. Standardowy pay by link jest jeszcze najbardziej uniwersalny i powszechny, kod Blik jednak szybko zdobywa popularność dzięki prostocie, znakomitej wygodzie korzystania i bezpieczeństwu rozwiązania. Na pewno jednak obie te metody są nieporównanie lepsze i w szczególności bardziej bezpieczne, niż te wymagające przekazywania przez klienta danych dostępu do rachunku bankowego stronom trzecim, w większości zresztą nieznanym klientowi.
Jaką rolę w procesie inicjowania płatności przez API może spełniać KIR?
KIR, w ramach swojej podstawowej działalności pełni funkcję integratora technologicznego. Powinien być zatem swego rodzaju platformą łączącą banki z zewnętrznymi dostawcami usług płatniczych i nie tylko. Kierowana przeze mnie firma, jako spółka infrastrukturalna należąca do banków, jest w tym zakresie naturalnym wyborem dla sektora. Wspierając banki i podmioty trzecie dbamy o bezpieczeństwo i sprawność integracji. Zapewniamy serwis wyrównujący dostępność – taką samą dla większych, ale i dla mniejszych podmiotów, dla których integracja z wieloma bankami może być szczególnie dużym wyzwaniem.
Oczywiście nie zamierzamy rościć sobie praw do jakkolwiek pojmowanej wyłączności – KIR nie musi być autorem jedynej tego rodzaju platformy. Ze względu na potrzebę ochrony klientów banku, za najważniejszy uznajemy aspekt bezpieczeństwa i w tym wymiarze nie widzimy miejsca na kompromisy.
Ale Polish API to niejedyny projekt, nad którym obecnie pracuje KIR, a który wykracza poza główny biznes Pana spółki, za jaki uważam rozliczenia międzybankowe. Tym projektem jest mojeID, czyli rozwiązanie umożliwiające potwierdzanie tożsamości w kontaktach z firmami komercyjnymi oraz instytucjami publicznymi. Na jakiem etapie jesteście Państwo z realizacją mojegoID?
Po stronie KIR mamy potwierdzoną techniczną gotowość. Rozpoczęliśmy testy z tzw. dostawcami tożsamości, w których uczestniczy kilka banków. Do testów przygotowują się także dostawcy usług – podmioty sektora komercyjnego. Zainteresowanie jest duże, prowadzimy rozmowy z kilkudziesięcioma firmami z takich branż jak m.in. ubezpieczenia, medycyna czy telekomunikacja. Wkrótce ruszamy z pilotem i mam nadzieję, że w ciągu najbliższych miesięcy mojeID wystartuje komercyjnie. Liczymy także, że dzięki zmianom w prawie mojeID wkrótce zyska możliwość potwierdzania tożsamości klientów banków także w kontaktach z administracją publiczną. Pilotaż w tym zakresie również rozpocznie się wkrótce.
Właśnie, ustawa o tzw. węźle krajowym, czyli rozwiązaniu pozwalającym na logowanie się do urzędów za pośrednictwem loginów i haseł bankowych utknęła i nie wiadomo kiedy prace nad nią ruszą. Czy to nie stanowi bariery we wdrażaniu mojegoID?
Jesteśmy zainteresowani integracją z węzłem krajowym, bo to pozwoli na zaoferowanie pełnej funkcjonalności usługi mojeID, jako jednego uniwersalnego narzędzia zdalnego uwierzytelniania w usługach prywatnych i publicznych. Jeśli chodzi o zastosowanie tego rozwiązania do logowania na stronach firm prywatnych, to zmiany w prawie nie są konieczne. Komercyjne potwierdzanie tożsamości bazuje na zapisach eIDAS i umowie między firmami, nie wymaga więc dodatkowych regulacji w polskim prawodawstwie.
Wiemy, że zdalne uwierzytelnianie jest warunkiem koniecznym do rozwoju usług cyfrowych. Z perspektywy banków mojeID przyczyni się do zwiększenia lojalności klientów. Będzie także potencjalnym źródłem przychodów od firm, które dzięki zdalnej weryfikacji tożsamości będą mogły pozyskiwać nowych klientów i zwiększać skalę działania.
KIR kończy też prace nad podpisem cyfrowym w chmurze. Proszę powiedzieć na czym to rozwiązanie będzie polegać i czym będzie różnić się dla konsumenta np. w porównaniu z logowaniem w przychodni zdrowia za pomocą mojegoID?
mojeID służy do weryfikacji tożsamości i potwierdzenia kto np. występuje o dostęp do danych w przychodni. Natomiast podpis w chmurze to narzędzie równoważne podpisowi własnoręcznemu. Dzięki temu, że jest integralnie związany z danymi, do których jest dołączony, wiadomo dokładnie nie tylko "kto", ale też i "co" oświadczył. Odnosząc to do usług medycznych, podpis w chmurze może być użyty do elektronicznego podpisania np. zgody na wykonanie jakiegoś zabiegu.
Usługi mojeID i podpis w chmurze wzajemnie się uzupełniają i pozwalają na pełną elektronizację biznesu. Do tego możemy dodawać kolejne elementy, takie jak elektroniczny znacznik czasu, który jest wiarygodnym i prawnie uznawanym mechanizmem potwierdzającym istnienie danej informacji, bądź dokumentu w danym momencie. Znacznik czasu dołożony do podpisanej elektronicznie zgody na zabieg daje możliwość zweryfikowania podpisanego dokumentu za rok, dwa, a nawet 20 lat.
W mediach bardzo modnym tematem jest ostatnio blockchain. Technologia ta nie jest też obca KIR-owi. Chcecie ją wykorzystać przy budowie systemu do wymiany dokumentów między bankami i ich klientami. Czy Pana zdaniem blockchain rzeczywiście jest najlepszym rozwiązaniem do budowy tego systemu?
Uważam, że blockchain – jako technologia – ma w sobie duży potencjał. Dlatego jest uwzględniany w pracach nad trwałym nośnikiem. Wydaje się jednak, że systemu tego nie można oprzeć wyłącznie na blockchainie. Proszę pamiętać, że dokumenty jakie banki wysyłają do klientów, to nie tylko jednakowe dla wszystkich regulaminy czy tabele opłat i prowizji, ale także umowy i aneksy podpisywane indywidualnie z każdym klientem. Masa tych dokumentów powoduje problemy wydajnościowe dla technologii blockchain.
Dlatego sądzimy, że najlepszym rozwiązaniem będzie połączenie różnych technologii, a każdy bank będzie decydować w jakim momencie z jakiego rozwiązania skorzystać. Obecnie prowadzimy testy typu "proof of concept" mające na celu weryfikację takiego hybrydowego rozwiązania. Jeszcze w grudniu zamierzamy przygotować raport z tych testów i przedstawić go zespołowi pracującemu nad rozwiązaniem kwestii trwałego nośnika przy Związku Banków Polskich. Mamy nadzieję, że raport pozwoli bankowcom podjąć właściwą decyzję co do modelu optymalnego zarówno pod względem funkcjonalności, jak i kosztów.
Dziękuję za rozmowę
