Open Banking “pod” PSD2 nadal sprawia trudności. EBA publikuje kolejne wyjaśnienia
Zdążyliśmy już nieco zapomnieć o wyzwaniach jakie pakiet PSD2 stwarzać może dla realizacji koncepcji otwartej bankowości, chociażby w kontekście przeszkód mogących powstawać w związku z dostępem do rachunków przez tzw. podmioty trzecie (TPPs) (więcej w tym artykule). Choć można odnieść wrażenie (pisałem o swoich odczuciach tutaj), to jednak jaki progres jest widoczny. Niemniej jednak wyjaśnień czy rekomendacji w tym zakresie jest jakby mniej. Przełamując ten “trend” EBA opublikowała w ostatni piątek kolejne zestawienie pytań i odpowiedzi w zakresie realizacji OPEN BANKING. Znajdziemy tam głównie wyjaśnienia dotyczące sposobu uwierzytelniania klientów w ramach nowych usług (AIS oraz PIS), ale także bardzo interesujące rozważania dotyczące cyberbezpieczeństwa, a konkretnie oszustw z użyciem tzw. social engineering. Spójrzmy więc na to co przygotowała dla nas EBA i eksperci grupy roboczej.
Zacznijmy od dwóch zagadnień dotyczących sposobu uwierzytelniania użytkowników. Przypomnijmy, że Rozporządzenie 2018/389 (konkretnie art. 32 ust. 3) zakazuje stwarzania przeszkód dla dostawców usług dostępu do informacji o rachunku oraz inicjowania płatności , do których można zaliczyć m.in. wymaganie, aby użytkownik – w ramach takiej usługi – stosował metody uwierzytelniania inne niż przy “klasycznym” korzystaniu z usługi np. bankowości elektronicznej. Pierwsze dwa zagadnienia opracowane przez EBA dotyczą de facto sytuacji, w której dostawca rachunku płatniczego (zazwyczaj bank) wymaga jednak innego sposobu uwierzytelniania lub żąda dodatkowego kroku (EBA zwróciła na to uwagę też w ostatnim pytaniu, gdzie przypomina, że rolą organów nadzoru jest przeciwdziałanie takim praktykom). W tym przypadku mowa była przykładowo o wymaganiu złożenia dodatkowego podpisu elektronicznego przez użytkownika. Czy jest to zgodne z powyższym rozporządzeniem? Oczywiście nie, bo przecież “droga” użytkownika ma być najbardziej zbliżona do tego, co otrzymuje on w ramach standardowego procesu korzystania ze swojej aplikacji bankowej.
Dalej mamy zagadnienie związane z tzw. redirection (przekierowaniem) użytkownika wykorzystującego biometrię do uwierzytelniania za pomocą aplikacji mobilnych. Pytanie dotyczyło więc tego czy EBA nie powinna zająć się tym bardziej kompleksowo – tj. wydać stosownych standardów. Odpowiedź była w tym miejscu dość jasna – wyjaśnialiśmy przy okazji wytycznych w sprawie przeszkód i nie ma powodów, żeby tworzyć dodatkowej papierologii. Mamy więc wymogi w zakresie wymiany danych i bezpieczeństwa, a te jasno określają obowiązki po stronie zarówno dostawców rachunków, jak i wspomnianych TPP.
Kolejny temat jest bardzo ciekawy i dotyczy inżynierii społecznej, czyli de facto wykorzystywanie naszych (ludzkich) słabości. Pytanie “wychodziło” od statystyki, która wskazywała, że liczba oszustw (fraudów) inicjowanych przez dostawców usługi inicjowania transakcji była znacznie wyższa niż w przypadku transakcji inicjowanych w tradycyjny sposób. Miało to być jakoby pokłosiem tego, że dostawcy takich usług w sposób niewłaściwy informowali użytkowników na temat różnych typów oszust, a także że ich systemy monitorowania transakcji były nieefektywne. Dodatkowo dostawcy (zazwyczaj bankowi) mieliby mieć trudność w identyfikacji podejrzanych transakcji, bowiem nie otrzymują oni informacji dotyczących użytkownika (jego adresu IP czy położoenia). Nazwałbym to odwiecznym problemem – brakiem zaufania obu stron “otwartej bankowości” wobec siebie, ale spójrzmy co na to EBA.
Odpowiedź jest przy tym dość prosta. Każdy dostawca usług płatniczych ma obowiązek stosować odpowiednie rozwiązania w zakresie monitorowania transakcji, co wynika wprost z przepisów. Dodatkowo dostawcy rachunków mogą zawsze “dorzucać” dodatkowe ostrzeżenia w zakresie potencjalnych oszustw przy inicjowaniu transakcji przez TPP, ale pod warunkiem, że takie same ostrzeżenia stosują także w swoich aplikacjach – inaczej mamy przeszkodę. Rozsądnie.
Co w dalszej kolejności? Czy ASPSP (np. bank) może udzielić TPP informacji o użytkowniku, np. jego IBANie przed zainicjowaniem transakcji – co ma wspomóc przeciwdziałaniem fraudom? Otóż nie, chyba że mówimy o wykorzystaniu usługi dostępu do informacji o rachunku. Ciekawsze jest jednak to, na co EBA zwraca uwagę dalej – jeżeli WY (dostawcy usługi inicjowania transakcji) macie wątpliwości, to pamiętajcie, że przepisy dotyczące AML wymagają od Was dokonywania tzw. KYC zgodnie z odpowiednimi wymogami, w tym regulacyjnymi.
I to tyle. Niby nic, a buduje poczucie, że otwarta bankowość nie została całkowicie zapomniana. Niedługo przygotuję też raport z “pola bitwy” obrazujący jak to wygląda.