Otwarty dostęp do rachunków płatniczych w ramach OpenAPI a standardy bezpieczeństwa cz. 1. Dostęp oraz środki awaryjne

Bezpieczeństwo danych, zarówno w aspekcie danych osobowych, jak i płatniczych, to ostatnio hot topic. Otwarcie bankowości, o czym pisałem tutaj, powoduje że coraz częściej użytkownicy kont płatniczych zadają sobie pytanie o to, czy ich środki i tożsamość będą tak samo bezpieczne. Oczywiście każde udostępnienie danych wymaga naszej zgody, ale czy banki i dostawcy z kategorii Third Party Providers (TPP) mają i stosują odpowiednie środki by zapewnić spokojny sen swoich klientów? Muszą, jeżeli chcą być zgodni z regulacjami unijnymi oraz krajowymi. EBA pracuje obecnie na QnA do Rozporządzenia 2018/389, które rozwieje wiele wątpliwości w tym zakresie, choć nie wiadomo kiedy ujrzy ono światło dzienne.

Dostęp do rachunku płatniczego na rzecz TPP (m.in. dostawcy oferujący usługę dostępu do informacji – AISP oraz dostawcy oferujący usługę inicjowania płatności PISP) może odbywać się w dwóch wariantach (na co z resztą wskazuje Rozporządzenie 2018/389), tj. za pośrednictwem specjalnego interfejsu lub – w pewnym uproszczeniu – poprzez udzielenie dostępu do analogicznego systemu uwierzytelniania użytkowników tych rachunków.

Niedyskryminujący dostęp

Wprowadzenie specjalnego interfejsu wiąże się z obowiązkiem utrzymywania takich rozwiązań, które zapewniają ciągłość i efektywność komunikacji na tym samym poziomie co interfejsy dostępne dla użytkowników. Wiąże się z tym inny obowiązek określenia przejrzystych wskaźników efektywności dla tych interfejsów. Co ciekawe całokształt działań dostawcy rachunku płatniczego może być (i będzie) przedmiotem monitoringu oraz stress-testów prowadzonych przez organy nadzoru. Jest to więc bardzo istotny element “nowej” działalności banków w kontekście PSD2. 

Jednym z kluczowych elementów PSD2 jest zapewnienie niedyskryminującego dostępu do rachunków na rzecz TPP. Z tego względu przy wprowadzaniu specjalnego interfejsu niezwykle istotne jest zagwarantowanie, aby zaimplementowane rozwiązania nie tworzyły przeszkód w takim dostępie. Przykładowo bank nie może wymuszać na TPP przekierowania (redirection) czy wprowadzać dodatkowych zgód. Dostęp ma być prosty i analogiczny jak dla klientów takiego banku. Otwarta bankowość w pełnej krasie. Na marginesie. Dostawcy prowadzący rachunki mają obowiązek kwartalnego raportowania statystyk dotyczących dostępności i efektywności specjalnego interfejsu na stronie internetowej.

Alert, alert, czyli awaria interfejsu dostępowego.

Nie zawsze uda się jednak utrzymać ciągłość działania systemu (tj. na 5 żądań dostępu brak odpowiedzi w ciągu 30 sekund). Przyczyną mogą być problemy techniczne czy udział osób trzecich. Dążąc do minimalizowania negatywnych konsekwencji takiej sytuacji należy wprowadzić strategię i plany środków awaryjnych, które zapewnią przede wszystkim odpowiednią komunikację z TPP.

Na wypadek tych nieprzewidzianych zdarzeń dostawca udostępniający interfejs (dla uproszczenia przyjmijmy, że jest to bank) musi poinformować dostawców o środkach, które podejmie w celu przywrócenia usługi oraz o alternatywach w zakresie dostępu. TPP oraz banki muszą również poinformować organ nadzoru (KNF) o występujących problemach z dostępem do interfejsu. W wariancie tym udostępnia się TPP interfejsy udostępnione użytkownikom rachunków.

Wymaga to umożliwienia TPP zidentyfikowania się względem banku oraz spełnienia przez TPP odpowiednich wymogów w zakresie bezpieczeństwa, w tym w kontekście uwierzytelniania. TPP nie może mieć dostępu do danych, nie może też ich przetwarzać i przechowywać, w innych celach niż świadczenie usług tego TPP. Dodatkowo, TPP muszą spełniać wszystkie warunki określone w dyrektywie PSD2 (dla AISP – art. 67 ust. 2 oraz dla PISP – 66 ust. 3). Warunki te dotyczą głównie ochrony danych oraz bezpieczeństwa środków użytkowników. TPP muszą również rejestrować dane, które podmioty te otrzymały w ramach tego środka awaryjnego. Taki rejestr należy udostępnić na każde żądanie KNF. Na żądanie nadzorcy TPP muszą również informować o przyczynach stosowania tego interfejsu “awaryjnego”, a także komunikować się z bankami.

A może tak wyłączenie?

To najbezpieczniejsze rozwiązanie. KNF, po konsultacji z EBA (tutaj czekamy również na odpowiednie wytyczne, które obecnie znajdują się na etapie konsultacji), może zapewnić wyłączenie z obowiązku stosowania środków awaryjnych przez dostawcę prowadzącego rachunek. Nastąpi to jedynie w przypadku spełnienia wszystkich warunków, o których mowa w art. 33 ust. 6 Rozporządzenia 2018/389. Taki specjalny interfejs musi więc (i) spełniać wszystkie warunki w zakresie dostępności i efektywności; (ii) być przetestowany i spełniający oczekiwania TPP (spełniający wymogi w zakresie niedyskryminującego dostępu, np. odpowiednia dokumentacja); (iii) być utrzymywany przez okres co najmniej trzech miesięcy i stosowany przez TPP (AISP, PISP oraz dostawców świadczących usługę płatności realizowanych przez kartę); oraz (iv) wszystkie problemy z tym interfejsem rozwiązano bez zbędnej zwłoki (tutaj wyznacznikiem może być liczba skarg na działanie interfejsu). Jeżeli te warunki są spełnione to istnieje duże prawdopodobieństwo zastosowania wyłączenia. Może ono jednak zostać cofnięte, jeżeli bank nie będzie spełniał tych warunków przez okres dłuższy niż 2 następujące po sobie tygodnie. Wciąż czekamy na informacje odnośnie procedury uzyskiwania wyłączenia.

Podsumowując. Zastosowanie środków awaryjnych to jeden z elementów zapewnienia bezpieczeństwa. Takie bezpieczeństwo gwarantują również ograniczenia względem TPP, które określa m.in. dyrektywa PSD2. Obecnie czekamy na wyjaśnienia EBA do rozporządzenia, gdyż wiele z postanowień jest dość niejasnych. Na pewno napiszę o nich jak tylko zostaną one opublikowane.

W kolejnej części przyjrzymy się certyfikatom, bezpieczeństwie sesji oraz wymianie danych pomiędzy dostawcami.

 

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *