Bank 4.0 a Open Banking? Jak zrealizować postulat „otwarcia” i jednocześnie chronić klienta banku?
Jakiś czas temu rozpocząłem serię artykułów dotyczących transformacji do banku 4.0 (część 1; część 2; część 3). Z dotychczasowej analizy wyłania nam się obraz tej zmiany jako wymagającej dobrego przygotowania, czasu oraz cierpliwości (na co wpływ ma zakres regulacji, które nieco spowalniają ten proces). W tej odsłonie się to nie zmieniło. Dzisiaj zmierzę się z kolejnym punktem z listy Bretta Kinga, który dotyczy przede wszystkim open bankingu (i wykorzystania Application Programming Interface). Skupię się więc na koncepcji Open Banking, której regulacyjne „granice” wyznacza Rozporządzenie 2018/389 (na OB warto jednak patrzeć szerzej, a nie tylko przez pryzmat obowiązującego prawa).
Pamiętajmy jednak, że Brett King odnosi się tutaj wyłącznie do banków detalicznych, podczas gdy znaczna część banków ma również „komponent” korporacyjny, który rządzi się jednak nieco innymi prawami. Skupmy się jednak na Retail Digital Banku 4.0.
Autor „Bank 4.0. Banking Everywhere, Never at a Bank” zwraca uwagę, że otwarcie się na podmioty trzecie (Third Party Providers) to warunek konieczny na drodze do prawdziwej przemiany w zwinnego motyla (to akurat zaczerpnięte z Raportu Citi, o którym pisałem tutaj). Jest to zgodne z koncepcją Open Bankingu, która w lepszy lub gorszy sposób znalazła swoje odzwierciedlenie w pakiecie PSD2, a w szczególności Rozporządzeniu 2018/389 (zachęcam do przeczytania tego oraz tego artykułu).
API, TPP i spore problemy…
Współpraca pomiędzy różnymi podmiotami na rynku finansowym jest potrzebna, szczególnie jeżeli myślimy 
poważnie o tzw. financial inclusion, czyli finansowym włączeniu nieubankowionej części społeczeństwa. Ta współpraca musi się jednak odbywać na równych zasada i z poszanowaniem reguł bezpieczeństwa danych i środków klientów. Nie może to być więc „bezrefleksyjne” otwarcie wszelkich systemów na podmioty trzecie.
Dlatego właśnie mamy Rozporządzenie 2018/389, które porządkuje te zasady. Wymaga ono od banków „wystawienia” własnych API – od 14 marca w wersji testowej, a od 14 września w wersji produkcyjnej – które umożliwiają „podłączenie się” przez upoważnione (licencjonowane/zarejestrowane przez regulatorów jak np. KNF) podmioty świadczące usługi płatnicze, jak np. inicjowanie transakcji płatniczych czy usługi dostępu do informacji o rachunku) i wykonywanie operacji w imieniu klientów (relacja TPP-klient-bank klienta).
Takie API to nic innego jak zestaw procedur i procesów, które pozwalają na zintegrowanie się z bankowością elektroniczną i bezpieczne przesyłanie danych (w tym indywidualnych danych uwierzytelniających) niezbędnych do np. wykonania transakcji płatniczej. Sama integracja technologiczna to jednak jedynie pierwszy krok na drodze do skorzystaniu z otwartej bankowości.
Co musi bank?
Ponieważ w artykule odnoszę się do transformacji banku, to i o obowiązkach banku będzie mowa. Przepisy 
Rozporządzenia 2018/389 stawiają przed tymi instytucjami szereg obowiązków, w tym w zakresie identyfikacji TPP z użyciem certyfikatów eIDAS (więcej o tym zagadnieniu tutaj). W tym kontekście pojawia się dość istotne wyzwanie po stronie banków, na które uwagę zwraca m.in. Europejski Urząd Nadzoru Bankowego (EBA) w swojej opinii, czyli aktualności/nieaktualności danych „zaszytych” w tych certyfikatach.
Certyfikaty…
Takie certyfikaty muszą spełniać wymogi art. 34 oraz Rozporządzenia 910/2014, co oznacza że muszą w sposób wyraźny informować odbiorcę certyfikatu o posiadanej przez podmiot zgłaszający żądanie odpowiedniej licencji lub rejestracji oraz roli jaką pełni dostawca. Są one wystawiane przez dostawców usług zaufania, jak np. Krajową Izbę Rozliczeniową. Wyzwaniem przed którym stoją banki jest jednak „potwierdzanie” aktualności takiego certyfikatu.
Łatwo wyobrazić sobie bowiem sytuację, w której certyfikat nie został jeszcze zaktualizowany (a więc informuje o posiadaniu stosownego zezwolenia), podczas gdy organ nadzoru cofnął takie zezwolenie. Jeżeli więc TPP złożył w imieniu klienta określone żądanie (request), a bank je zrealizuje zgodnie z informacjami zawartymi w certyfikacie, to z punktu widzenia banku będzie to działanie zgodne z przepisami, jednak ryzyko dla klienta potencjalnie mogłoby się zmaterializować.
Sam numer rejestrowy TPP jest pozyskiwany z rejestrów prowadzonych przez krajowe organy nadzoru, które 
nie zawsze są aktualizowane w czasie rzeczywistym. EBA uruchomiła również centralny rejestr podmiotów objętych PSD2, jednakże jest to rejestr, który podlega aktualizacji tylko w przypadku przesłania stosownego żądania przez krajowy organ nadzoru. Dane tam umieszczone nie zawsze muszą odzwierciedlać więc stan faktyczny. Ponadto, identyfikacja TPP w ramach środowiska produkcyjnego będzie musiała odbywać się w taki sposób, aby nie tworzyć dodatkowych opóźnień w realizacji usługi (powinna być ona zrealizowana jak dla „normalnego” użytkownika). Manualne sprawdzenie w rejestrze (abstrahując od „skuteczności” takiego działania) mogłoby stanowić takie opóźnienie.
Ochrona danych klientów
Realizacja usług typu Payment Initation Service (PIS) czy Account Information Service (AIS) wiąże się z udostępnieniem wrażliwych danych klientów, stanowiących tajemnicę bankową i dlatego muszą być należycie chronione. Z tego względu m.in. art. 36 Rozporządzenia 2018/389 określa rygorystyczne (choć opisane bardzo ogólnie) wymogi w zakresie zabezpieczenia całej komunikacji pomiędzy bankiem a TPP (w pewnym – ograniczonym – zakresie dotykają tej sfery przepisy ustawy o usługach płatnicznych, Dział IIIB).
Po pierwsze, w przypadku wystąpienia błędu lub incydentu uniemożliwiającego wykonanie operacji zgłoszonej 
przez TPP, bank musi wysłać stosowne zawiadomienie do tego podmiotu wraz z wyjaśnieniem przyczyny niepowodzenia. Tutaj istotne jest również ustanowienie odpowiedniego mechanizmu komunikacji.
Po drugie, bank musi wdrożyć i stosować takie mechanizmy, które zapobiegają dostępowi do informacji innych niż wymagane do wykonania określonej usługi PIS, AIS lub Confirmation of Availability of Funds (tzw. potwierdzenie dostępności środków na rachunku) i objętych zgodą użytkownika (posiadacza) rachunku. Banki muszą również posiadać odpowiednie mechanizmy awaryjne (np. w ramach tzw. fall-back mechanism – więcej o podejściu KNF do tej kwestii tutaj) na wypadek wystąpienia incydentów operacyjnych, w tym związanych z wyciekiem danych. W ramach ww. mechanizmów muszą być wdrożone odpowiednie rozwiązania w zakresie cyberbezpieczeństwa (pewne wytyczne znajdziemy tutaj).
Ważne jest więc posiadanie i dostosowanie odpowiednich procedur, które uwzględniają ten dodatkowy element w postaci udziału TPP w łańcuchu realizacji transakcji. Ten fakt zazwyczaj znajduje również odzwierciedlenie w stosownej dokumentacji klientowskiej, jak np. w regulaminach i/lub umowach.
Co więc z tym Open Bankingiem?
Zgadzam się z Brettem Kingiem, że Bank 4.0 powinien być bankiem otwartym. Nie możemy jednak zapominać, 
że to „otwarcie” musi podlegać odpowiednim regułom bezpieczeństwa wyznaczanym nie tylko przez regulacje, ale również komórki kontroli wewnętrznej, w tym audyt i compliance. Liczba podmiotów, które korzystają w ostatnim czasie z tzw. arbitrażu regulacyjnego stale rośnie, co potencjalnie zwiększać może ryzyka związane z pojawieniem się nowych rozwiązań na rynku. Ważne jest nie tylko rozsądne podejście regulatora, ale również świadomość klientów.