Warsztaty „Otoczenie prawne otwartej bankowości: wytyczne EBA i KNF”

10 maja 2021 Zespół DLK w całości poprowadził pierwszy dzień warsztatów online „Otoczenie prawne otwartej bankowości – nowe obowiązki instytucji finansowych: wytyczne EBA i KNF”, zorganizowanych przez MM Conferences S.A.

„Konsekwencje prawne niezapewnienia bezpieczeństwa transakcji na podstawie PSD2” (dr Krzysztof Korus, partner w DLK Legal)

  1. Pierwsze wystąpienie na temat konsekwencji prawnych niezapewnienia bezpieczeństwa transakcji na podstawie PSD2 poprowadził dr Krzysztof Korus (radca prawny, partner w DLK Legal), poruszono w nim m.in. problematykę związaną z wymogiem stosowania silnego uwierzytelnia klienta – SCA, stosowania wyłączeń od SCA przez wydawcę i agenta rozliczeniowego, monitoringiem transakcji czy odpowiedzialnością dostawcy za niespełnienie wymogów SCA.
    W projekcie rozporządzenia Parlamentu Europejskiego i Rady w sprawie operacyjnej odporności cyfrowej sektora finansowego i zmieniającego rozporządzenia (WE) nr 1060/2009, (UE) nr 648/2012, (UE) nr 600/2014 oraz (UE) nr 909/2014 („DORA”) i rozporządzenia Parlamentu Europejskiego i Rady w sprawie rynków kryptoaktywów i zmieniającego dyrektywę (UE) 2019/1937 („MiCA”) przewiduje się nadzór organów paneuropejskich, a nie krajowych, dla podmiotów o największej skali działania.
  2. Obecnie trwają prace nad SEPA API Access Scheme, czyli ogólnoeuropejskim schemacie (nie standardzie) dostarczania ujednoliconych usług opartych na API, na zasadach znanych ze schematów kartowych. Dr Krzysztof Korus jako członek zarządu Europejskiej Federacji Instytucji Płatniczych, z ramienia Polskiej Organizacji Niebankowych Instytucji Płatności, przewodniczy Grupie Roboczej ds. wyznaczenia operatora schematu. Na czerwcowym posiedzeniu Euro Retail Payments Board grupa SEPA API przedstawi do zatwierdzenia projekt schematu. SEPA API reguluje dostarczanie usług Premium Value przez podmioty prowadzące rachunki (ASPSP w PSD2, w ramach systemu określane „Asset Holders”) na rzecz podmiotów świadczących usługi PSD2 (TPP w PSD2, w ramach systemu określane „Asset Brokers”), w tym odpłatnej gwarancji zapłaty dla usługi PIS czy identyfikacji posiadacza rachunku dla usługi AIS. Na bazie usług płatniczych nastąpi rozszerzenie na inne usługi (tzw. „Asset Classes”). W zakresie usług PSD2 funkcje Premium Value w ramach schematu dostępne będą wyłącznie dla Asset Holders – ASPSP, których usługi warstwy Compliance funkcjonują zgodnie z regulacjami.
  3. Klient musi pokryć koszt nieautoryzowanej transakcji, jeśli można mu wykazać rażące niedbalstwo lub umyślność. Jeśli transakcja wymagała silnego uwierzytelnienia, a jej nie przeprowadzono, klienta można obciążyć wyłącznie w przypadku umyślności. Dyrektywa i ustawa nie wyłączają wymogu silnego uwierzytelnienia wobec transakcji one-leg.
  4. Silnego uwierzytelnienia nie stosuje się w transakcjach inicjowanych przez odbiorcę. Transakcje te obejmują polecenie zapłaty oraz transakcje tzw. MIT (merchant initiated transactions). Polecenie zapłaty nie wymaga SCA, ale jest bezwarunkowo odwoływalne. Różni się ono od innych transakcji MIT tym, że zgoda oraz obciążenie dotyczy rachunku, tymczasem w MIT dotyczy ona instrumentu płatniczego.
  5. Agent rozliczeniowy nie musi stosować własnego silnego uwierzytelnienia płatnika, wystarczające jest wykonanie silnego uwierzytelnienia współdzielonego z wydawcą instrumentu. Jeśli agent rozliczeniowy żąda od wydawcy transakcji bez silnego uwierzytelnienia ze wskazaniem na art. 18 RTS, wydawca nie ma obowiązku weryfikować, czy agent rozliczeniowy spełnia warunki art. 18 RTS.

„Projekt rozporządzenia DORA: wpływ na dostawców usług płatniczych i cloud computing w sektorze finansowym” (dr Michał Mostowik, adwokat, starszy prawnik w DLK Legal)

  1. Drugie wystąpienie poprowadził dr Michał Mostowik (adwokat, starszy prawnik w DLK Legal). Tematem było rozporządzenie DORA oraz jego wpływ na dostawców usług płatniczych i cloud computing w sektorze finansowym. Podczas warsztatów poruszono kwestie związane m.in. z bezpieczeństwem ICT w sektorze finansowym, nowymi obowiązkami instytucji finansowych czy nadzorem nad outsourcingiem i chmurą w sektorze finansowym.
  2. DORA będzie stanowić „kodeks” dla obszaru technologii w sektorze finansowym. DORA uzupełnia dotychczasowe regulacje, ale nie można wykluczyć dostosowania np. rekomendacji D lub prawa bankowego do nowych przepisów (w niektórych obszarach byłoby to celowe, np. w zakresie ograniczeń dotyczących łańcucha outsourcingowego)
  3. DORA wymaga złożonego systemu zarządzania ryzykiem ICT. W ramach systemu niezbędne jest wdrożenie dokumentacji (m.in. Digital Resilience Strategy), przegląd procesów, wdrożenie sformalizowanych zasad testowania systemów i aplikacji.
  4. W zakresie providerów zewnętrznych DORA rezygnuje z pojęcia outsourcingu i dotyczy wszystkich projektów współpracy z podwykonawcami. Procesy inne niż outsourcing (HR, zarządzanie najmem, flota samochodów etc.) również podlegają pod DORA.
  5. DORA wprowadza zasady nadzoru nad krytycznymi dostawcami ICT (CTPP). Wpis na listę CTPP będzie albo z urzędu (po spełnieniu kryteriów określonych przez ESA) albo na wniosek podmiotu, który chce zostać objęty nadzorem. Instytucje finansowe nie mogą podjąć współpracy z providerem spoza EOG, który spełnia kryteria CTPP, ale nie jest objęty nadzorem. Struktura nadzoru jest złożona i opiera się na wyznaczeniu Lead Overseer spośród ESA (EBA, ESMA, EIOPA). Organy unijne proponują natomiast powołanie wspólnej, wyspecjalizowanej komórki do celów takiego nadzoru nad CTPP. Nadzór jest ukierunkowany na harmonizację zasad świadczenia usług chmurowych i innych krytycznych usług IT dla sektora finansowego w skali EOG.
  6. Jednym z głównych zarzutów wobec DORA jest niekonsekwentne stosowanie zasady proporcjonalności. ESA wzywają do większej elastyczności stosowania przepisów. EESC postuluje wyłączenie stosowania części przepisów DORA nie tylko dla mikroprzedsiębiorców, ale także dla małych przedsiębiorców. Polski rząd prezentuje stanowisko, aby DORA nie stosowała się do instytucji płatniczych. Czeski parlament natomiast obawia się wykluczenia małych instytucji i providerów IT z rynku.
  7. AI Act został niedawno opublikowany i jako innowacyjna regulacja może być jeszcze przedmiotem dość dużych zmian. Obecnie przewiduje jednak szeroką definicję AI, przez co może objąć nawet te systemy, które nie zawsze są na co dzień traktowane jako AI. Z tego powodu część usług open banking może podlegać pod AI Act (np. systemy scoringu kredytowego wykorzystujące usługi AIS). W ramach AI Act przewidziany jest złożony system zarządzania ryzykiem oraz zarządzania jakością, włącznie m.in. z regulacją data governance, testowaniem, zgłaszaniem ryzyk organom nadzoru i dokumentacją systemu.

„Outsourcing usług open banking (PIS, AIS) w świetle rekomendacji EBA oraz stanowiska KNF” (dr Michał Mostowik wraz z Aleksandrą Księżak (prawnik w DLK Legal)

  1. Trzecie wystąpienie poprowadził dr Michał Mostowik (adwokat, starszy prawnik w DLK Legal) wraz z Aleksandrą Księżak (prawnik w DLK Legal), którzy skupili się na outsouringu usług open banking w świetle rekomendacji EBA oraz stanowiska KNF. W swoim wystąpieniu wskazali oni m.in. kiedy współpraca z dostawcą technologii jest outsourcingiem, jak wygląda specyfika relacji outsourcingowej przy świadczeniu usług open banking oraz czy wymogi stawiane umowie outsourcingowej mają odzwierciedlenie w praktyce rynkowej.
  2. Współpraca banku z zewnętrznym dostawcą w celu outsourcingu usług TPP może przybierać rozmaite formy, w zależności od zakresu usług, które mają podlegać powierzeniu. Ustalenie modelu współpracy jest decyzją do pojęcia przed otwarciem negocjacji umowy. W zależności od zakresu współpracy, do umowy będą miały zastosowanie odmienne regulacje (przepisy, softlaw). Dla ułatwienia procesu negocjowania umowy należy w pierwszej kolejności podjąć decyzję co do architektury regulacyjnej współpracy oraz ustalić, które z palety wymogów regulacyjnych będą miały do niej zastosowanie.
  3. Cześć modeli współpracy banku z dostawcami zewnętrznymi przy wdrażaniu usług TPP nie będzie stanowiła outsourcingu w rozumieniu żadnych z obowiązujących regulacji. Niezależnie od tego warto w tych umowach zadbać szczególnie o prawidłową regulację przedmiotu świadczenia, praw własności intelektualnej, potencjalnego świadczenia usług serwisu czy o przyjęcie adekwatnego do charakteru umowy i apetytu banku na ryzyko modelu opłat.
  4. Dla sprecyzowania oczekiwań banku wobec kontrahenta i dla prawidłowego wdrożenia outsourcingu TPP konieczne jest kompleksowe oszacowanie ryzyka po stronie banku. Szacowanie powinno objąć, kwestie związane bezpośrednio z wykonywaniem zlecanej usługi, jak i ryzyka związane ze świadczeniem własnych usług banku na bazie usług dostarczonych do niego w wykonaniu umowy outsourcingowej.
  5. Na bazie szacowania ryzyka bank powinien sprecyzować jakie SLA powinny zostać umieszczone w umowie. SLA mają odzwierciedlać przyjęty model współpracy z kontrahentem i dotyczyć każdej z usług składowych, do których wykonania kontrahent zobowiązuje się w ramach umowy outsourcingowej.
  6. Prawidłowo przeprowadzona ocena ryzyka i odpowiednio sprecyzowane SLA ułatwią przygotowanie BCP dopasowanego do potrzeb banku i planowanej umowy. BCP powinno być przygotowane tak, żeby realnie zabezpieczać bank na wypadek zarówno problemów z działaniem usługi dostawcy jak i problemów wynikających z technicznych ograniczeń usług TPP. Długofalowa strategia z BCP powinna być spójna ze strategią zakończenia współpracy banku z dostawcą. Przy uzgadnianiu postanowień umownych dotyczących wycofania banku z umowy outourcingu z TPP warto uwzględnić wysoce techniczny charakter takiego outsourcingu i zapewnić w szczególności jasne zasady przekazania komponentów technicznych umożliwiających bankowi korzystanie z oprogramowania po zakończeniu współpracy

„Odpowiedzialność za transakcje nieautoryzowane i obsługa reklamacji klienta w PSD2” (Bartosz Wyżykowski, radca prawny, starszy prawnik w DLK Legal)

  1. Ostatnie wystąpienie w tym dniu poprowadził Bartosz Wyżykowski (radca prawny, starszy prawnik w DLK Legal). Przedmiotem była odpowiedzialność za nieautoryzowane transakcje oraz obsługa reklamacji klienta w świetle regulacji PSD2. W trakcie wystąpienia uczestnicy mogli dowiedzieć się m.in. jaki podział odpowiedzialności za nieautoryzowane transakcje płatnicze został przewidziany w PSD2 oraz zaznajomić się z przeglądem orzecznictwa w sprawie nieautoryzowanych transakcji płatniczych.
  2. 1 lipca 2021 wchodzi w życie nowelizacja ustawy o rozpatrywaniu reklamacji i o Rzeczniku Finansowym (URR) wprowadzająca zmiany w zasadach składania i odpowiadania na reklamacje przez podmioty rynku finansowego, w tym przez dostawców usług płatniczych. Wprowadzana jest m.in. możliwość składania przez klientów reklamacji na piśmie na adres doręczeń elektronicznych w rozumieniu nowej ustawy o doręczeniach elektronicznych. W związku z tym do 1 lipca 2021 r. podmioty rynku finansowego obowiązane są zapewnić zgodność z nowym brzmieniem URR. Zmianie nie ulega natomiast sama ustawa o usługach płatniczych (UUP ).
  3. W teorii i praktyce w dalszym ciągu pojawiają się wątpliwości na gruncie właściwego rozumienia uwierzytelnienia i autoryzacji transakcji i ciężarów dowodowych z tym związanych. Uwierzytelnianie, a w tym SCA służy temu, aby dostawca płatnika miał pewność, że komunikuje się z płatnikiem. Polega więc na zweryfikowaniu jego tożsamości lub ważności stosowania instrumentu płatniczego. Autoryzacja polega natomiast na wyrażeniu przez płatnika zgody na wykonanie transakcji płatniczej. Na gruncie przepisów unijnych należałoby przyjąć, że na dostawcy spoczywa ciężar udowodnienia, że zastosował uwierzytelnienie. Na skutek błędnej implementacji PSD1 z literalnego brzmienia przepisów UUP wynika jednak, że na dostawcy spoczywa obowiązek udowodnienia, że transakcja została autoryzowana.
  4. Z przepisów UUP  jasno wynika, że w przypadku transakcji wykonanej z podaniem przez użytkownika nieprawidłowego unikatowego identyfikatora, dostawca nie ponosi odpowiedzialności na podstawie przepisów tej ustawy. Niemniej z praktyki orzeczniczej sądów wynika, że sprawa może się okazać znacznie bardziej skomplikowana. Przykładowo w wyroku SA w Białymstoku z dnia 5 kwietnia 2019  I AGa 176/18, LEX nr 2716949, sąd ten uznał, że wykonanie zlecenia płatniczego zgodnie z treścią art. 143 UUP  nie przesądza jeszcze o braku odpowiedzialności dostawcy płatnika, jeżeli uzasadnione okażą się w stosunku do tego dostawcy zarzuty naruszenia obowiązków wynikających z tej ustawy bądź umowy. Wyrok wydany został w sprawie, w której wskutek działania złośliwego oprogramowania doszło do nieprzewidzianej i niezamierzonej (przestępczej) modyfikacji numeru rachunku bankowego odbiorcy wbrew rzeczywistej woli płatnika.
  5. Ustawa o usługach płatniczych stanowi, że płatnik odpowiada za nieautoryzowane transakcje płatnicze w pełnej wysokości, jeżeli doprowadził do nich umyślnie albo w wyniku umyślnego lub będącego skutkiem rażącego niedbalstwa naruszenia co najmniej jednego z obowiązków, o których mowa w art. 42 UUP. Z przeglądu orzecznictwa polskich sądów wynika, że sądy te na tle różnych stanów faktycznych najczęściej orzekają o odpowiedzialności dostawcy z tytułu nieautoryzowanej transakcji płatniczej, choć zdarzają się również rozstrzygnięcia odmienne. W większości przypadków sądy nie dopatrują się umyślnego ani rażąco niedbałego naruszenia przez płatników obowiązków określonych w art. 42 UUP.
  6. PSD2 wprowadziła znaczące zmiany w przepisach regulujących odpowiedzialność z tytułu nieautoryzowanych transakcji płatniczych, aczkolwiek istota rozwiązań w tym zakresie pozostała bez zmian. Kluczowym z perspektywy potencjalności dostawców jest obowiązek stosowania SCA zgodnie z wymogami wynikającymi z UUP oraz RTS. W przypadku gdy dostawca płatnika nie wymaga SCA, płatnik nie ponosi bowiem odpowiedzialności za nieautoryzowane transakcje płatnicze, chyba że działał umyślnie.

Bankowość & Finanse

Zobacz sektor

Bankowość & Finanse

IT & Outsourcing

Zobacz sektor

IT & Outsourcing

Online & eCommerce

Zobacz sektor

Online & eCommerce

Proponowane wpisy

MiCA, blockchain i tokenizacja, 26.03.2024: Podsumowanie

26.03.2024

Za nami wydarzenie: MiCA, blockchain i tokenizacja którego organizatorem jest ...

MiCA, blockchain i tokenizacja, 26.03.2024: Podsumowanie

Rozporządzenie w sprawie płatności natychmiastowych – EUR-Lex

20.03.2024

W Dzienniku Urzędowym opublikowano rozporządzenie Parlamentu Europejskiego i Rad...

Rozporządzenie w sprawie płatności natychmiastowych – EUR-Lex

Polecamy: MiCA, blockchain i tokenizacja, 26.03.2024, online

20.03.2024

W imieniu Organizatorów oraz swoim polecamy wydarzenie: MiCA, blockchain i toke...

Polecamy: MiCA, blockchain i tokenizacja, 26.03.2024, online

Skontaktuj się

Biuro Warszawa

Ogrodowa City Gate
ul. Ogrodowa 58
00-876 Warszawa

mapa > +48 22 652 26 18

Biuro Kraków

ul. Jana Kilińskiego 2
30-308 Kraków

mapa > +48 12 31 51 841