14 września – usługi bankowe po nowemu
Po 14 września dostępne będą dwa uregulowane scenariusze, które odpowiednio wdrożone nie pozostawiają miejsca na jakąkolwiek przerwę czy spadek jakości w dostarczaniu usług opartych na dostępie do informacji o rachunku płatniczym (ang. Account Information Service).
Połączenie po API
W scenariuszu zaplanowanym przez Parlament Europejski, który uchwalił Dyrektywę PSD2, najpóźniej 14 września Banki mają obowiązek udostępnienia API, dzięki którym licencjonowane TPP będą miały możliwość uzyskania dostępu do rachunków płatniczych klienta czy inicjowania w jego imieniu płatności.
Siła mechanizmu jest bardzo prosta i była już niejednokrotnie opisywana przy okazji wyjaśniania efektów wprowadzenia dyrektywy PSD2. W przypadku usługi AIS użytkownik potwierdza zgodę na dostęp do informacji o rachunku logując się na stronie banku na swoje konto z zachowaniem wszystkich wynikających z dyrektywy (pośrednio lub bezpośrednio) standardów bezpieczeństwa (SCA, protokół OAuth 2.0), a TPP po potwierdzeniu swojej tożsamości certyfikatami eIDAS, pobiera informacje o rachunku płatniczym dzięki połączeniu z API. Szybki, sprawny i wygodny dla użytkownika proces, który umożliwia korzystanie z szeregu usług oferowanych przez banki i fintechy.
Zagrożenia?
To co może stanąć na drodze sprawnemu świadczeniu usług w ramach otwartej bankowości to problemy z terminowością i jakością wdrożeń API przez banki obserwowane na rynkach europejskich. Przerwy w działaniu, problemy techniczne lub w skrajnych przypadkach niedostępne API, mogą podważyć zaufanie klientów i zachwiać całą ideą otwartej bankowości. Zabezpieczeniem przed tego typu scenariuszem dla TPP jest wprowadzony w dyrektywie mechanizm fallback.
Scenariusz awaryjny – mechanizm fallback i bezpośredni dostęp
Mechanizm fallback jest wyjściem awaryjnym, które może być zastosowane w sytuacji, gdy API bankowe będzie niedostępne. Polega on na umożliwieniu bezpośredniego dostępu do rachunku klienta.
Oczywiście bezpośredni dostęp do rachunku jest podejściem wciąż budzącym niechęć. Owiany złą sławą, w związku z koniecznością udostępniania danych logowania (ang. credential sharing), zawsze wzbudzał kontrowersje.
Skąd zatem pojawienie się tej technologii w kontekście dyrektywy PSD2, której jednym z głównych założeń jest podniesienie poziomu bezpieczeństwa użytkowników? Otóż dyrektywa PSD2 określa zasady, które muszą być spełnione, aby zapewnić ciągłość działania.
Problem z dzieleniem się danymi dostępowymi
W ramach stosowania mechanizmu fallback TPP będzie musiał uwierzytelnić się przed bankiem certyfikatem eIDAS potwierdzającym posiadanie licencji i zarazem odpowiednich uprawnień do wykonania określonej usługi. Dzięki temu bank będzie miał pewność, że licencjonowany i uprawniony do tego podmiot odpytuje o dane jego klienta.
Cały czas pozostaje jednak problem dzielenia się danymi dostępowymi. W Polsce z inicjatywy Związku Banków Polskich ten scenariusz ma być zastąpiony przekierowaniem użytkownika na stronę banku. Oznacza to całkowite pozbycie się problemu “credential sharing”.
Dodatkowo z perspektywy użytkownika końcowego nie byłoby różnicy między połączeniem po API, a połączeniem wykorzystującym bezpośredni dostęp.
PSD2 to ogromna szansa, której potencjał należy wykorzystać, a mogące się pojawić problemy z API są do rozwiązania po stronie banków i dostawców połączeń.
Bez względu na rodzaj scenariusza, jaki zostanie zastosowany do uzyskania dostępu do informacji o rachunkach płatniczych i niezależnie od kondycji API, ciągłość oferowanych usług powinna być zapewniona. Ich jakość zależeć będzie od jakości usług dostarczanych przez TPP i ich gotowości do implementacji połączeń z API oraz gotowości do stosowania mechanizmu fallback.
