3. Wytyczne

1.1. Właściwe organy powinny uznać, że dostawca usług płatniczych prowadzący rachunek (ang. account servicing payment service provider — ASPSP) spełnia cztery warunki podane w art. 33 ust. 6 RTS, gdy ten dostawca usług spełnia wymogi podane w wytycznych 2 – 8, z zastrzeżeniem spełnienia wymogów określonych w PSD2 oraz RTS.

1.2. Dostawcy usług płatniczych prowadzący rachunek powinni dostarczyć właściwym organom informacje niezbędne do tego, aby właściwy organ mógł stwierdzić, że spełniono wymogi podane w wytycznych 2 – 8.

2.1. Dostawca usług płatniczych prowadzący rachunek powinien określić kluczowe wskaźniki efektywności (ang. Key Performance Indicator — KPI) oraz cele w zakresie gwarantowanego poziomu usług, w tym wskaźniki i cele odnoszące się do procesu rozwiązywania problemów, wsparcia technicznego poza zwykłymi godzinami pracy, monitorowania, planów awaryjnych oraz utrzymania rozwiązań zapewniających efektywność specjalnego interfejsu, przynajmniej w równym stopniu rygorystyczne co wymogi dotyczące interfejsów udostępnianych własnym użytkownikom usług płatniczych (ang. payment service user — PSU) w celu umożliwienia bezpośredniego dostępu do ich rachunków za pośrednictwem Internetu.

2.2. Dostawca usług płatniczych prowadzący rachunek powinien określić przynajmniej następujące KPI dotyczące dostępności specjalnego interfejsu:

• a. czas nieprzerwanej pracy wszystkich interfejsów w ciągu dnia; oraz
• b. przestoje wszystkich interfejsów w ciągu dnia.

2.3. Oprócz KPI dotyczących dostępności, ujętych w wytycznej 2.2, ASPSP powinien podać przynajmniej następujące KPI dotyczące działania specjalnego interfejsu:

• a. średni dzienny czas (w milisekundach) przypadający na jedno żądanie, po którym ASPSP przekazuje dostawcy świadczącemu usługę inicjowania płatności (ang. payment initiation service provider — PISP) wszystkie wymagane informacje zgodnie z art. 66 ust. 4 lit. b) PSD2 oraz art. 36 ust. 1 lit. b) RTS;
• b. średni dzienny czas (w milisekundach) przypadający na jedno żądanie, po którym ASPSP przekazuje dostawcy świadczącemu usługę dostępu do informacji o rachunku (AISP) wszystkie wymagane informacje zgodnie z art. 36 ust. 1 lit. a) RTS;
• c. średni dzienny czas (w milisekundach) przypadający na jedno żądanie, po którym ASPSP przekazuje wydawcy instrumentu płatniczego opartego na karcie (ang. card-based payment instrument issuer — CBPII) lub PISP potwierdzenie w formie „tak/nie” zgodnie z art. 65 ust. 3 PSD2 oraz art. 36 ust. 1 lit. c) RTS; (RTS) DOTYCZĄCYCH SILNEGO UWIERZYTELNIANIA KLIENTA I WSPÓLNYCH I BEZPIECZNYCH OTWARTYCH STANDARDÓW KOMUNIKACJI)
• d. dzienny wskaźnik reakcji na błąd — obliczony jako liczba komunikatów o błędach dotyczących błędów, które można przypisać ASPSP, wysłanych w ciągu dnia przez tego dostawcę do PISP, AISP oraz CBPII zgodnie z art. 36 ust. 2 RTS, podzielona przez liczbę żądań otrzymanych w tym samym dniu przez ASPSP od AISP, PISP i CBPII.

2.4. W celu obliczenia określonych w wytycznej 2.2 wskaźników dostępności dotyczących specjalnego interfejsu ASPSP powinien:

• a. obliczyć odsetek czasu nieprzerwanej pracy w postaci: 100 proc. minus odsetek przestojów;
• b. obliczyć odsetek przestojów za pomocą łącznej liczby sekund, w czasie których specjalny interfejs nie działał w ciągu 24 godzin od północy do północy;
• c. w obliczeniach przyjmować, że interfejs nie działa, gdy po pięciu kolejnych żądaniach dostępu do informacji w celu świadczenia usług inicjowania płatności, usług dostępu do informacji o rachunku albo potwierdzenia dostępności środków nie uzyska się odpowiedzi w łącznym czasie 30 sekund, niezależnie od tego, czy żądania te pochodzą od jednego, czy od większej liczby PISP, AISP lub CBPII. W takiej sytuacji ASPSP powinien obliczyć czas przestoju od chwili otrzymania pierwszego z pięciu kolejnych żądań, na które nie udzielono odpowiedzi w ciągu 30 sekund, pod warunkiem że w tych pięciu żądaniach nie było żadnego udanego, na które nastąpiła reakcja.

3.1 Ze względu na art. 32 ust. 4 RTS ASPSP powinien przedstawić swemu właściwemu organowi plan cokwartalnej publikacji dziennych statystyk dotyczących dostępności i efektywności specjalnego interfejsu zgodnie z wytycznymi 2.2 i 2.3 oraz udostępnienia każdego z interfejsów własnym PSU, aby umożliwić bezpośredni dostęp do ich rachunków za pośrednictwem Internetu, wraz z informacjami o tym, gdzie statystyki te zostaną opublikowane, oraz z datą pierwszej publikacji.

3.2 Publikacja, o której mowa w powyższej wytycznej 3.1, powinna umożliwić PISP, AISP, CBPII oraz PSU porównanie dostępności i efektywności specjalnego interfejsu z dostępnością i efektywnością każdego z interfejsów udostępnionych przez ASPSP swoim PSU w celu zapewnienia bezpośredniego dostępu do swoich rachunków płatniczych za pośrednictwem Internetu w dowolny dzień.

4.1 Na potrzeby testów warunków skrajnych, o których mowa w art. 32 ust. 2 RTS, ASPSP powinien opracować procesy pozwalające ustalić i ocenić efektywność specjalnego interfejsu, gdy działa w warunkach skrajnie dużej liczby żądań od PISP, AISP oraz CBPII, pod względem wpływu takich warunków skrajnych na dostępność i efektywność specjalnych interfejsów i określonych celów w zakresie gwarantowanego poziomu usług. (RTS) DOTYCZĄCYCH SILNEGO UWIERZYTELNIANIA KLIENTA I WSPÓLNYCH I BEZPIECZNYCH OTWARTYCH STANDARDÓW KOMUNIKACJI)

4.2 Dostawca usług płatniczych prowadzący rachunek powinien przeprowadzić odpowiednie testy specjalnego interfejsu w warunkach skrajnych, obejmujące między innymi następujące działania i funkcje:

• a. zdolność zapewnienia dostępu dla wielu PISP, AISP oraz CBPII;
• b. zdolność przetwarzania skrajnie dużej liczby żądań od PISP, AISP oraz CBPII w krótkim czasie i niezawodnie;
• c. użycie skrajnie dużej liczby jednocześnie otwartych sesji w celu inicjowania płatności, uzyskania informacji o rachunku oraz żądania potwierdzenia dostępności środków; oraz
• d. żądania dużych ilości danych.

4.3 Dostawca usług płatniczych prowadzący rachunek powinien dostarczyć właściwemu organowi podsumowanie wyników testów warunków skrajnych, w tym założenia przyjęte za podstawę takiego testowania każdego z elementów ujętych w punktach od a) do d) powyższej wytycznej 4.2 oraz informacje o sposobie rozwiązania każdego z wykrytych problemów.

5.1 Dostawca usług płatniczych prowadzący rachunek powinien przekazać właściwemu organowi:

• a. zbiorczy opis metod wykonywania procedur uwierzytelnienia PSU, obsługiwanej przez specjalny interfejs, czyli przekierowywania, uwierzytelniania w zewnętrznym narzędziu autoryzacyjnym (tzw. decoupled), wbudowanych mechanizmów uwierzytelniania lub ich kombinacji; oraz
• b. wyjaśnienie, dlaczego metody wykonywania procedur uwierzytelnienia użytkownika usług płatniczych, o których mowa w pkt a) nie są przeszkodą w rozumieniu art. 32 ust. 3 RTS, oraz w jaki sposób metody te pozwalają PISP oraz AISP polegać na procedurach uwierzytelniania zapewnionych przez ASPSP swoim PSU, wraz z dowodami, że specjalny interfejs nie powoduje zbędnej zwłoki i nie utrudnia korzystania z funkcji dostępnych dla PSU, gdy uzyskują dostęp do rachunku za pośrednictwem PISP, AISP lub CBPII, ani nie wywołuje innych cech, w tym zbędnych lub niepotrzebnych czynności, użycia niejasnych lub zniechęcających sformułowań, które bezpośrednio albo pośrednio zniechęcałyby PSU do korzystania z usług PISP, AISP oraz CBPII.

5.2 W ramach wyjaśnienia, o którym mowa w lit. b) wytycznej 5.1, ASPSP powinien dostarczyć właściwemu organowi potwierdzenie, że:

• a. specjalny interfejs nie uniemożliwia PISP ani AISP polegania na procedurze uwierzytelnienia zapewnionej swoim PSU przez ASPSP;
• b. od PISP, AISP ani CBPII nie wymaga się żadnych dodatkowych zezwoleń ani rejestracji, poza tymi, które określono w art. 11, 14 i 15 PSD2;
• c. dostawca usług płatniczych prowadzący rachunek nie stosuje wymogów dodatkowej weryfikacji zgody udzielonej przez PSU na rzecz PISP lub AISP w celu uzyskania dostępu do (RTS) DOTYCZĄCYCH SILNEGO UWIERZYTELNIANIA KLIENTA I WSPÓLNYCH I BEZPIECZNYCH OTWARTYCH STANDARDÓW KOMUNIKACJI)

informacji o rachunkach prowadzonych przez ASPSP albo w celu zainicjowania płatności; oraz

• d. nie stosuje się wymogów dodatkowej weryfikacji zgody udzielonej przez PSU na rzecz CBPII, zgodnie z art. 65 ust. 2 lit. a) PSD2.

6.1 W celu udokumentowania zgodności z wymogiem ujętym w art. 33 ust. 6 lit. b) RTS co do opracowania specjalnego interfejsu ASPSP powinien przedstawić właściwemu organowi:

• a. dowód na to, że specjalny interfejs spełnia wymogi prawne co do dostępu i danych ujęte w PSD2 oraz RTS, w tym:
• i. opis rozwiązań funkcjonalnych i technicznych zastosowanych przez ASPSP;
• ii. podsumowanie, w którym opisano, w jaki sposób wdrożenie tych rozwiązań spełnia wymogi PSD2 i RTS;
• b. informacje o tym, czy — a jeśli tak, to w jaki sposób — ASPSP nawiązał współpracę z PISP, AISP oraz CBPII.

6.2 Na potrzeby niniejszych wytycznych przyjęto, że „inicjatywa rynku” oznacza grupę interesariuszy, którzy opracowali specyfikację funkcjonalno - techniczną specjalnych interfejsów, przy czym, pracując nad tym, uzyskali informacje od PISP, AISP oraz CBPII.

6.3 W przypadku gdy ASPSP wdraża normę opracowaną przez inicjatywę rynku:

• a. informacje, o których mowa w wytycznej 6.1 lit. a) ppkt (i), mogą obejmować informacje o tym, która norma inicjatywy rynku jest wdrażana przez ASPSP, niezależnie od tego, czy odbiega on w jakimś konkretnym aspekcie od takiej normy, a jeśli tak, to pod jakim względem odbiega od takiej normy i w jaki sposób spełnia wymogi PSD2 i RTS;
• b. informacje, o których mowa w wytycznej 6.1 lit. a) ppkt (ii), mogą zawierać, gdy są dostępne, wyniki testów zgodności opracowanych przez inicjatywę rynku, które potwierdzają zgodność interfejsu z odpowiednią normą przyjętą przez inicjatywę rynku.

6.4 Ze względu na ujęty w art. 33 ust. 6 lit. b) RTS wymóg co do testowania specjalnego interfejsu ASPSP powinien udostępnić specyfikacje techniczne specjalnego interfejsu upoważnionym PISP, AISP oraz CBPII lub dostawcom usług płatniczych, którzy wystąpili do właściwych organów o stosowne zezwolenie zgodnie z art. 30 ust. 3 RTS, w tym przynajmniej publikując podsumowanie specyfikacji specjalnego interfejsu na swojej stronie internetowej zgodnie z akapitem trzecim art. 30 ust. 3 RTS.

6.5 Ośrodek prowadzący testy powinien umożliwić ASPSP, upoważnionym PISP, AISP oraz CBPII lub dostawcom usług płatniczych, którzy wystąpili do właściwych organów o stosowne zezwolenie na przetestowanie specjalnego interfejsu w bezpiecznym, specjalnym środowisku testowym z nieautentycznymi danymi PSU: (RTS) DOTYCZĄCYCH SILNEGO UWIERZYTELNIANIA KLIENTA I WSPÓLNYCH I BEZPIECZNYCH OTWARTYCH STANDARDÓW KOMUNIKACJI)

• a. stabilne i bezpieczne połączenie;
• b. zdolność ASPSP oraz upoważnionych PISP, AISP i CBPII do wymiany stosownych certyfikatów zgodnie z art. 34 RTS;
• c. zdolność do wysyłania i otrzymywania powiadomień o błędach zgodnie z art. 36 ust. 2 RTS;
• d. zdolność PISP do wysyłania, a ASPSP — do otrzymywania zleceń inicjowania płatności oraz zdolność ASPSP do udzielania informacji żądanych zgodnie z art. 66 ust. 4 lit. b) PSD 2 oraz art. 36 ust. 1 lit. b) RTS;
• e. zdolność AISP do wysyłania, a ASPSP — do otrzymywania żądań dostępu do danych o rachunku płatniczym oraz zdolność ASPSP do udzielania informacji żądanych zgodnie z art. 36 ust. 1 lit. a) RTS;
• f. zdolność CBPII i PISP do wysyłania, a ASPSP — do otrzymywania żądań od CBPII i PISP oraz zdolność ASPSP do wysyłania potwierdzenia w formie „tak/nie” do CBPII i PISP zgodnie z art. 36 ust. 1 lit. c) RTS; oraz
• g. możliwość polegania przez PISP i AISP na wszystkich procedurach uwierzytelniania zapewnionych przez ASPSP swoim PSU.

6.6 Dostawca usług płatniczych prowadzący rachunek powinien dostarczyć właściwemu organowi podsumowanie wyników testów, o których mowa w art. 30 ust. 5 RTS, dotyczące każdego z elementów poddawanych testom zgodnie z powyższą wytyczną 6.5 lit. a) – g), w tym liczbę PISP, AISP i CBPII, którzy wykorzystali środowisko testowe, informacje zwrotne otrzymane przez ASPSP od tych PISP, AISP i CBPII, wykryte problemy oraz opis, w jaki sposób je rozwiązywano.

6.7 W celu ustalenia, czy ASPSP spełnia wymogi określone w art. 33 ust. 6 lit. b) RTS, właściwy organ może także wziąć pod uwagę wszelkie problemy zgłaszane mu przez PISP, AISP oraz CBPII w związku z wytyczną 6.5.

7.1 W celu udokumentowania spełnienia wymogu ujętego w art. 33 ust. 6 lit. c) RTS ASPSP powinien przedstawić właściwemu organowi:

• a. opis użycia specjalnego interfejsu przez okres, o którym mowa w art. 33 ust. 6 lit. c), obejmujący między innymi następujące dane:

1. liczbę PISP, AISP oraz CBPII, którzy wykorzystali interfejs, aby świadczyć usługi klientom; oraz

2. liczbę żądań przesłanych przez tych PISP, AISP i CBPII do ASPSP za pośrednictwem specjalnego interfejsu, na które ASPSP zareagował;

• b. dowód, że ASPSP podjął wszelkie uzasadnione starania, aby zapewnić powszechne stosowanie swojego specjalnego interfejsu, m.in. poprzez informowanie o jego dostępności za pośrednictwem odpowiednich kanałów, w tym, w stosownych (RTS) DOTYCZĄCYCH SILNEGO UWIERZYTELNIANIA KLIENTA I WSPÓLNYCH I BEZPIECZNYCH OTWARTYCH STANDARDÓW KOMUNIKACJI)

przypadkach, strony internetowej ASPSP, mediów społecznościowych, organizacji branżowych, konferencji oraz bezpośredniej współpracy ze znanymi podmiotami rynku.

7.2 Oprócz dowodów, o których mowa w punkcie 7.1 niniejszych wytycznych, właściwy organ powinien wziąć pod uwagę informacje otrzymane w związku z wytycznymi 6 oraz 8, gdy dokonuje oceny, czy ASPSP spełnia wymóg określony w art. 33 ust. 6 lit. c) RTS.

7.3 Trzymiesięczny okres, o którym mowa w art. 33 ust. 6 lit. c) RTS, może biec jednocześnie z okresem prowadzenia testów, o których mowa w art. 30 ust. 5 RTS.

8.1 W celu spełnienia wymogów ujętych w art. 32 ust. 1 oraz w art. 33 ust. 6 lit. d) RTS ASPSP powinien przedstawić właściwemu organowi:

• a. informacje o systemach lub procedurach stosowanych do wykrywania, rozwiązywania i usuwania problemów, szczególnie tych zgłaszanych przez PISP, AISP i CBPII; oraz
• b. wyjaśnienie problemów, szczególnie tych zgłaszanych przez PISP, AISP i CBPII, których nie rozwiązano zgodnie z celami w zakresie gwarantowanego poziomu usług określonymi w wytycznej 2.1.

9.1 Konsultując się z EUNB zgodnie z art. 33 ust. 6 RTS, właściwe organy powinny przekazać EUNB formularz oceny podany w załączniku 1 dotyczący każdego wniosku o wyłączenie, które zamierzają przyznać. Właściwe organy nie powinny podejmować żadnych decyzji w związku z wyłączeniem przed otrzymaniem komentarzy EUNB w sprawie wniosku lub przed upływem miesiąca od konsultacji właściwego organu z EUNB. Właściwe organy powinny należycie wziąć pod uwagę komentarze EUNB przy podejmowaniu wszelkich decyzji w sprawie wniosku.

9.2 Na zasadzie odstępstwa od wytycznej 9.1, do 31 grudnia 2019 r. właściwe organy, które powiadomiły EUNB o tym, że spełniają wymogi określone w niniejszych wytycznych, mogą następnie przyznać wyłączenie, pod warunkiem że skonsultowały to z EUNB, informując o zamiarze przyznania wyłączenia przy użyciu formularza oceny z załącznika 1. W takiej sytuacji właściwe organy mogą przesłać formularz oceny dotyczący jednego ASPSP lub większej liczby ASPSP.

9.3 Właściwe organy, które odmówiły wyłączenia ASPSP z obowiązku utworzenia mechanizmów awaryjnych, o których mowa w art. 33 ust. 4 RTS, gdyż ich specjalny interfejs nie spełnia warunków określonych w art. 33 ust. 6 RTS ani wymogów ujętych w wytycznych 2 – 8 , powinny przekazać EUNB formularz oceny z załącznika 1 bez zbędnej zwłoki. Należy przedłożyć negatywne oceny wszystkich odrzuconych wniosków o przyznanie wyłączenia zgodnie z art. 33 ust. 6 RTS.

9.4 W przypadku gdy ASPSP należy do grupy mającej spółki zależne w różnych państwach członkowskich, które będą stosowały ten sam specjalny interfejs, każdy z właściwych organów tych państw członkowskich powinien: (RTS) DOTYCZĄCYCH SILNEGO UWIERZYTELNIANIA KLIENTA I WSPÓLNYCH I BEZPIECZNYCH OTWARTYCH STANDARDÓW KOMUNIKACJI)

• a. poinformować bez zbędnej zwłoki pozostałe stosowne właściwe organy, czy zamierza odmówić przyznania wyłączenia; oraz
• b. na wniosek pozostałych właściwych organów, nie naruszając zobowiązań do zachowania poufności, poinformować pozostałe właściwe organy, dlaczego zamierza odmówić przyznania wyłączenia, oraz, w stosownych przypadkach, o problemach zgłaszanych właściwym organom przez PISP, AISP i CBPII. (RTS) DOTYCZĄCYCH SILNEGO UWIERZYTELNIANIA KLIENTA I WSPÓLNYCH I BEZPIECZNYCH OTWARTYCH STANDARDÓW KOMUNIKACJI)