Open banking to praktyka bankowa, która umożliwia dostawcom usług finansowych trzeciej strony dostęp do danych bankowych i finansowych konsumentów za pośrednictwem interfejsów programowania aplikacji (API). Może to oferować klientom większy wybór, wygodę i kontrolę nad ich finansami, a także umożliwić bankom innowacje i skuteczniejszą konkurencję.
Jednak open banking stawia również znaczące wyzwania bezpieczeństwa, takie jak ochrona danych, weryfikacja tożsamości, zapobieganie oszustwom i zgodność z przepisami. W tym artykule skupię się na przypadku Polski, która jest jednym z krajów UE, które wdrożyły open banking w ramach Dyrektywy w sprawie usług płatniczych 2 (PSD2) i Ogólnego rozporządzenia o ochronie danych (GDPR).
Polska przyjęła ustandaryzowane API dla open banking, zwane Polskim API, które opiera się na ramach Berlin Group NextGenPSD2. To API definiuje wymagania techniczne i funkcjonalne dla komunikacji między bankami a dostawcami usług trzeciej strony (TPP), takimi jak dostawcy usług inicjowania płatności (PISP) i dostawcy usług informacji o rachunku (AISP).
Jednym z kluczowych aspektów bezpieczeństwa open banking jest uwierzytelnianie i autoryzacja klientów oraz TPP. Na mocy PSD2, banki są zobowiązane do stosowania silnego uwierzytelnienia klienta (SCA) podczas dostępu klientów do ich online kont płatniczych lub inicjowania elektronicznych transakcji płatniczych. SCA opiera się na dwóch lub więcej czynnikach: czymś, co klient zna (np. hasło), czymś, co klient posiada (np. telefon komórkowy) lub kimś, kim jest klient (np. biometria).
Ponadto banki muszą zweryfikować tożsamość i legalność TPP przed przyznaniem im dostępu do danych klienta lub usług płatniczych. Jest to realizowane przez proces zwany dynamicznym łączeniem, który polega na generowaniu unikalnego kodu dla każdej transakcji lub sesji i wysyłaniu go klientowi do potwierdzenia. Kod zawiera informacje o TPP, kwocie i odbiorcy płatności.
Polskie API używa OAuth 2.0 jako ramy autoryzacji dla open banking. OAuth 2.0 to szeroko stosowany standard, który umożliwia bezpieczne delegowanie praw dostępu do aplikacji stron trzecich. W OAuth 2.0, klienci udzielają zgody TPP na dostęp do ich danych lub usług poprzez wydanie im tokenów dostępu, które są krótkotrwałe i ograniczone zakresem. Tokeny dostępu są wydawane przez serwer autoryzacyjny, który jest zaufaną jednostką weryfikującą tożsamość i uprawnienia TPP oraz klientów.
OAuth 2.0 oferuje kilka korzyści dla bezpieczeństwa open banking, takich jak:
- Oddziela role uwierzytelniania i autoryzacji, pozwalając bankom skupić się na weryfikacji klientów i TPP, podczas gdy TPP mogą skupić się na dostarczaniu wartości dodanej usług.
- Zmniejsza ryzyko naruszenia danych, ponieważ TPP nie muszą przechowywać ani obsługiwać wrażliwych danych klienta lub poświadczeń, ale tylko tokeny dostępu.
- Umożliwia precyzyjną kontrolę nad zakresem i czasem trwania praw dostępu, pozwalając klientom w każdej chwili odwołać lub zmodyfikować swoją zgodę.
- Obsługuje wiele przepływów i typów
grantów, w zależności od przypadku użycia i poziomu zaufania między stronami.
Jednak OAuth 2.0 ma również pewne ograniczenia i wyzwania dla bezpieczeństwa open banking, takie jak:
- Opiera się na HTTPS jako protokole bezpieczeństwa warstwy transportowej, który może być podatny na ataki takie jak ataki typu man-in-the-middle czy fałszowanie certyfikatów.
- Nie definiuje standardowego sposobu implementacji SCA lub dynamicznego łączenia, pozostawiając miejsce na interpretację i niespójność między różnymi implementacjami.
- Nie adresuje niektórych specyficznych wymagań PSD2, takich jak zapewnienie śledzenia i niezaprzeczalności transakcji czy dostarczanie ustandaryzowanych kodów błędów i komunikatów.
Dlatego Polskie API uzupełnia OAuth 2.0 o dodatkowe specyfikacje i wytyczne, aby adresować te kwestie i zapewnić zgodność z PSD2 i GDPR. Na przykład:
- Wymaga od banków stosowania kwalifikowanych certyfikatów wydanych przez kwalifikowanych dostawców usług zaufania (QTSP) do identyfikacji siebie i TPP w połączeniach HTTPS.
- Definiuje specyficzny przepływ dla SCA i dynamicznego łączenia, używając typu grantu autoryzacyjnego kodu z rozszerzeniem PKCE (Proof Key for Code Exchange) i protokołu OpenID Connect (OIDC).
- Określa format i zawartość tokenów dostępu, używając tokenów Web JSON (JWT) ze standardami JWS (JSON Web Signature) i JWE (JSON Web Encryption).
- Zapewnia wspólny mechanizm obsługi błędów, używając kodów stanu HTTP i obiektów błędów JSON.
Przyjmując te standardy i najlepsze praktyki, Polskie API ma na celu zapewnienie wysokiego poziomu bezpieczeństwa dla open banking w Polsce, jednocześnie ułatwiając interoperacyjność i innowacje na rynku.
Jednak bezpieczeństwo to nie tylko kwestia techniczna, ale także prawna i organizacyjna. Open banking wiąże się z udostępnianiem wrażliwych danych osobowych i finansowych między wieloma stronami, co rodzi pytania o ochronę danych, prywatność i odpowiedzialność.
Na mocy GDPR, klienci mają prawo do dostępu, sprostowania, usunięcia, ograniczenia lub sprzeciwu wobec przetwarzania ich danych osobowych przez banki lub TPP. Mają również prawo do przenoszenia danych, co oznacza, że mogą zażądać przeniesienia swoich danych do innego dostawcy. Ponadto, banki i TPP muszą przestrzegać zasad ochrony danych, takich jak zgodność z prawem, uczciwość, przejrzystość, ograniczenie celu, minimalizacja danych, dokładność, ograniczenie przechowywania, integralność i poufność.
Aby zapewnić zgodność z GDPR, banki i TPP muszą wdrożyć odpowiednie środki techniczne i organizacyjne, aby chronić dane osobowe przed nieuprawnionym lub bezprawnym przetwarzaniem, przypadkową utratą, zniszczeniem lub uszkodzeniem. Muszą również przeprowadzać oceny wpływu ochrony danych (DPIA) w celu zidentyfikowania i złagodzenia ryzyka związanego z działaniami przetwarzania danych. Ponadto, muszą powiadomić odpowiednie organy ochrony danych i klientów o wszelkich naruszeniach danych osobowych bez nieuzasadnionej zwłoki.
Pod względem odpowiedzialności, PSD2 ustanawia jasny podział odpowiedzialności i zobowiązań między bankami i TPP
w przypadku nieautoryzowanych lub oszukańczych transakcji, błędów lub sporów. Ogólnie rzecz biorąc, banki są odpowiedzialne za wszelkie straty lub szkody spowodowane ich własną winą lub zaniedbaniem, podczas gdy TPP są odpowiedzialne za wszelkie straty lub szkody spowodowane ich własną winą lub zaniedbaniem lub winą lub zaniedbaniem ich agentów lub podwykonawców.
Jednak istnieją pewne wyjątki i niuanse tej reguły. Na przykład:
- Jeśli klient inicjuje płatność za pośrednictwem PISP, bank jest odpowiedzialny za poprawne wykonanie płatności, chyba że może udowodnić, że PISP otrzymał pełną kwotę płatności na czas.
- Jeśli klient poniesie stratę z powodu nieautoryzowanej płatności zainicjowanej przez PISP, bank musi natychmiast zwrócić klientowi środki, chyba że może udowodnić, że PISP działał oszukańczo lub nie zastosował SCA.
- Jeśli klient poniesie stratę z powodu nieprawidłowych lub niekompletnych informacji dostarczonych przez AISP, AISP jest odpowiedzialny za stratę, chyba że może udowodnić, że przekazał informacje otrzymane od banku dokładnie i bez opóźnień.
Dlatego banki i TPP muszą współpracować i efektywnie komunikować się, aby rozwiązać wszelkie problemy lub reklamacje, które mogą wyniknąć z transakcji open banking. Muszą również informować klientów o ich prawach i obowiązkach, jak również o warunkach ich usług.
Open banking to złożone i ewoluujące zjawisko, które oferuje zarówno możliwości, jak i wyzwania dla banków, TPP i klientów. Bezpieczeństwo jest jednym z kluczowych aspektów, które wymagają starannej uwagi i ciągłego doskonalenia. Przestrzegając standardów i regulacji ustanowionych przez PSD2 i GDPR, a także najlepszych praktyk przyjętych przez Polskie API, open banking w Polsce może osiągnąć wysoki poziom bezpieczeństwa, który przynosi korzyści wszystkim zaangażowanym stronom.
Comments