This document is an excerpt from the EUR-Lex website
Document 32010O0012
2010/593/EU: Guideline of the European Central Bank of 15 September 2010 amending Guideline ECB/2007/2 on a Trans-European Automated Real-time Gross settlement Express Transfer system (TARGET2) (ECB/2010/12)
2010/593/UE: Wytyczne Europejskiego Banku Centralnego z dnia 15 września 2010 r. zmieniające wytyczne EBC/2007/2 w sprawie transeuropejskiego zautomatyzowanego błyskawicznego systemu rozrachunku brutto w czasie rzeczywistym (TARGET2) (EBC/2010/12)
2010/593/UE: Wytyczne Europejskiego Banku Centralnego z dnia 15 września 2010 r. zmieniające wytyczne EBC/2007/2 w sprawie transeuropejskiego zautomatyzowanego błyskawicznego systemu rozrachunku brutto w czasie rzeczywistym (TARGET2) (EBC/2010/12)
Dz.U. L 261 z 5.10.2010, p. 6–26
(BG, ES, CS, DA, DE, ET, EL, EN, FR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)
No longer in force, Date of end of validity: 31/12/2012; Uchylony przez 32012O0027
5.10.2010 |
PL |
Dziennik Urzędowy Unii Europejskiej |
L 261/6 |
WYTYCZNE EUROPEJSKIEGO BANKU CENTRALNEGO
z dnia 15 września 2010 r.
zmieniające wytyczne EBC/2007/2 w sprawie transeuropejskiego zautomatyzowanego błyskawicznego systemu rozrachunku brutto w czasie rzeczywistym (TARGET2)
(EBC/2010/12)
(2010/593/UE)
RADA PREZESÓW EUROPEJSKIEGO BANKU CENTRALNEGO,
uwzględniając Traktat o funkcjonowaniu Unii Europejskiej, w szczególności jego art. 127 ust. 2,
uwzględniając Statut Europejskiego Systemu Banków Centralnych i Europejskiego Banku Centralnego, w szczególności jego art. 3 ust. 1 oraz art. 17, 18 i 22,
a także mając na uwadze, co następuje:
(1) |
Rada Prezesów Europejskiego Banku Centralnego (EBC) przyjęła wytyczne EBC/2007/2 z dnia 26 kwietnia 2007 r. w sprawie transeuropejskiego zautomatyzowanego błyskawicznego systemu rozrachunku brutto w czasie rzeczywistym (TARGET2) (1) regulujące działanie systemu TARGET2, który charakteryzuje się pojedynczą platformą techniczną zwaną jednolitą wspólną platformą (Single Shared Platform, SSP). |
(2) |
W wytycznych EBC/2007/2 należy wprowadzić zmiany: a) uwzględniające aktualizacje wersji 4.0 systemu TARGET2, w szczególności mające na celu umożliwienie uczestnikom dostępu do jednego lub większej ilości rachunków w PM przez Internet; oraz b) odzwierciedlające szereg zmian technicznych spowodowanych wejściem w życie Traktatu o funkcjonowaniu Unii Europejskiej oraz wyjaśniające niektóre zagadnienia, |
PRZYJMUJE NINIEJSZE WYTYCZNE:
Artykuł 1
W wytycznych EBC/2007/2 wprowadza się następujące zmiany:
1) |
art. 1 ust. 1 otrzymuje brzmienie: „1. TARGET2 umożliwia rozrachunek brutto w czasie rzeczywistym płatności w euro, przeprowadzany w pieniądzu banku centralnego. System ten został stworzony i funkcjonuje w oparciu o SSP, za pośrednictwem której na tych samych zasadach technicznych następuje składanie i przetwarzanie wszystkich zleceń płatniczych oraz otrzymywanie płatności.”; |
2) |
w art. 2 wprowadza się następujące zmiany:
|
3) |
art. 6 ust. 1 i 2 otrzymuje brzmienie: „1. Uczestniczące KBC przyjmują postanowienia wprowadzające zharmonizowane warunki uczestnictwa w TARGET2 określone w załączniku II oraz uzupełniające i zmodyfikowane zharmonizowane warunki uczestnictwa w TARGET2 z wykorzystaniem dostępu przez Internet określone w załączniku V. Postanowienia te regulują w sposób wyłączny stosunki pomiędzy danym uczestniczącym KBC a jego uczestnikami w zakresie przetwarzania płatności w PM. Dostęp do rachunku w PM można uzyskać, korzystając z dostępu przez Internet albo za pośrednictwem dostawcy usług sieciowych. Powyższe dwa sposoby dostępu do rachunku w PM wzajemnie się wykluczają; uczestnik może jednakże zdecydować się na posiadanie większej liczby rachunków w PM, z których każdy będzie dostępny albo przez Internet, albo za pośrednictwem dostawcy usług sieciowych. 2. EBC przyjmuje warunki uczestnictwa w systemie TARGET2-ECB, dokonując implementacji załącznika II, z zastrzeżeniem, iż dostęp do systemu TARGET2-ECB jest ograniczony do organizacji rozliczeniowo-rozrachunkowych, w tym podmiotów z siedzibą poza EOG, o ile podlegają one nadzorowi systemowemu właściwego organu i na ich dostęp do TARGET2-ECB wyraziła zgodę Rada Prezesów.”; |
4) |
art. 8 ust. 1 otrzymuje brzmienie: „1. BC Eurosystemu świadczą na rzecz systemów zewnętrznych usługi przelewu środków w pieniądzu banku centralnego w PM, z dostępem za pośrednictwem dostawcy usług sieciowych lub, o ile ma to zastosowanie w czasie okresu przejściowego, na rachunkach typu home. Usługi takie podlegają porozumieniom dwustronnym między BC Eurosystemu a danymi systemami zewnętrznymi.”; |
5) |
art. 10 ust. 1 otrzymuje brzmienie: „1. Rada Prezesów określa zasady i wymagania dotyczące bezpieczeństwa oraz narzędzia kontroli dla SSP oraz – podczas okresu przejściowego – dla infrastruktury technicznej rachunku typu home. Rada Prezesów określa ponadto zasady mające zastosowanie do bezpieczeństwa certyfikatów używanych przy dostępie przez Internet.”; |
6) |
art. 16 ust. 2 otrzymuje brzmienie: „2. Uczestniczące KBC przesyłają do EBC do dnia 31 lipca 2007 r. albo w terminie określonym przez Radę Prezesów projekty aktów prawnych, za pomocą których zamierzają zastosować się do niniejszych wytycznych.”; |
7) |
załączniki do wytycznych EBC/2007/2 podlegają zmianom zgodnie z załącznikiem I do niniejszych wytycznych. |
8) |
do wytycznych EBC/2007/2 dodaje się załącznik V zgodnie z załącznikiem II do niniejszych wytycznych. |
Artykuł 2
Wejście w życie
Niniejsze wytyczne wchodzą w życie dwa dni po ich przyjęciu. Niniejsze wytyczne stosuje się od dnia 22 listopada 2010 r.
Artykuł 3
Adresaci i środki wykonawcze
1. Niniejsze wytyczne są adresowane do wszystkich banków centralnych Eurosystemu.
2. Uczestniczące KBC przesyłają do EBC do dnia 7 października 2010 r. projekty aktów prawnych, za pomocą których zamierzają zastosować się do niniejszych wytycznych.
Sporządzono we Frankfurcie nad Menem dnia 15 września 2010 r.
W imieniu Rady Prezesów EBC
Jean-Claude TRICHET
Prezes EBC
(1) Dz.U. L 237 z 8.9.2007, s. 1.
ZAŁĄCZNIK I
1. |
W załączniku I do wytycznych EBC/2007/2 wprowadza się następujące zmiany: W załączniku I punkt 7 tabeli otrzymuje brzmienie:
|
2. |
W załączniku II do wytycznych EBC/2007/2 wprowadza się następujące zmiany:
|
3. |
W załączniku III do wytycznych EBC/2007/2 wprowadza się następujące zmiany:
|
4. |
W załączniku IV do wytycznych EBC/2007/2 wprowadza się następujące zmiany:
|
ZAŁĄCZNIK II
Dodaje się załącznik V w brzmieniu:
„ZAŁĄCZNIK V
UZUPEŁNIAJĄCE I ZMODYFIKOWANE ZHARMONIZOWANE WARUNKI UCZESTNICTWA W TARGET2 Z WYKORZYSTANIEM DOSTĘPU PRZEZ INTERNET
Artykuł 1
Zakres regulacji
Do uczestników korzystających z dostępu przez Internet do jednego albo większej liczby rachunków w PM stosuje się warunki określone w załączniku II z zastrzeżeniem postanowień niniejszego załącznika.
Artykuł 2
Definicje
Dla celów niniejszego załącznika, w uzupełnieniu definicji zawartych w załączniku II, stosuje się następujące definicje:
— »organy certyfikacyjne«– jeden lub większa liczba KBC wyznaczonych jako takie przez Radę Prezesów do podejmowania w imieniu Eurosystemu działań w zakresie wydawania, cofania i odnawiania certyfikatów elektronicznych oraz zarządzania tymi certyfikatami,
— »certyfikaty elektroniczne« albo »certyfikaty«– wydany przez organy certyfikacyjne elektroniczny plik łączący klucz publiczny z tożsamością, używany w następujących celach: dla weryfikacji, że klucz publiczny należy do określonej osoby, dla potwierdzenia tożsamości posiadacza, dla sprawdzenia podpisu tej osoby albo dla zaszyfrowania komunikatu adresowanego do tej osoby. Certyfikaty przechowuje się na fizycznie istniejącym urządzeniu, takim jak karta chipowa albo pamięć USB, przy czym ilekroć mowa jest o certyfikatach, rozumie się przez to również takie fizycznie istniejące urządzenia. Certyfikaty pełnią zasadniczą rolę w procesie identyfikacji użytkowników uzyskujących dostęp do systemu TARGET2 przez Internet i przekazujących komunikaty płatnicze albo kontrolne,
— »posiadacz certyfikatu«– osoba określona z imienia i nazwiska, zidentyfikowana i wskazana przez uczestnika systemu TARGET2 jako uprawniona do dostępu przez Internet do rachunku uczestnika w systemie TARGET2. Wniosek uczestnika o certyfikaty podlega weryfikacji przez KBC państwa, w którym ma siedzibę uczestnik, oraz przekazaniu organom certyfikacyjnym, które z kolei wydają certyfikaty wiążące klucz publiczny z danymi potwierdzającymi tożsamość uczestnika,
— »dostęp przez Internet«– wybór przez uczestnika rachunku w PM dostępnego jedynie przez Internet, przy czym uczestnik przekazuje komunikaty płatnicze albo komunikaty kontrolne do systemu TARGET2 za pośrednictwem Internetu,
— »dostawca usług internetowych«– przedsiębiorstwo lub organizacja, tj. brama sieciowa, z której uczestnik TARGET2 korzysta w celu uzyskiwania dostępu do swojego rachunku w TARGET2 z wykorzystaniem dostępu przez Internet.
Artykuł 3
Przepisy niemające zastosowania
Następujących przepisów załącznika II nie stosuje się do dostępu przez Internet:
art. 4 ust. 1 lit. c) oraz ust. 2 lit. d); art. 5 ust. 2, 3 i 4; art. 6 i 7; art. 11 ust. 8; art. 14 ust. 1 lit. a); art. 17 ust. 2; art. 23–26; art. 41 oraz dodatki I, VI i VII.
Artykuł 4
Postanowienia uzupełniające i zmodyfikowane
Następujące przepisy załącznika II stosuje się do dostępu przez Internet z uwzględnieniem zmian wskazanych poniżej:
1) |
art. 2 ust. 1 otrzymuje brzmienie: »1. Następujące dodatki stanowią integralną część niniejszych Warunków i są stosowane do uczestników korzystających z dostępu przez Internet do rachunku w PM: Dodatek IA do załącznika V: Specyfikacje techniczne przetwarzania zleceń płatniczych dla dostępu przez Internet Dodatek IIA do załącznika V: Taryfa opłat i fakturowanie dla dostępu przez Internet Dodatek II: System rekompensat w TARGET2 Dodatek III: Ramowa treść opinii o zdolności i opinii krajowej Dodatek IV, z wyłączeniem pkt 7 lit. b): Procedury zapewniania ciągłości działania i postępowania w sytuacjach awaryjnych Dodatek V: Harmonogram operacyjny«; |
2) |
w art. 3 wprowadza się następujące zmiany:
|
3) |
art. 4 ust. 2 lit. e) otrzymuje brzmienie:
|
4) |
w art. 8 wprowadza się następujące zmiany:
|
5) |
w art. 9 wprowadza się następujące zmiany:
|
6) |
w art. 10 wprowadza się następujące zmiany:
|
7) |
w art. 11 wprowadza się następujące zmiany:
|
8) |
art. 12 ust. 7 otrzymuje brzmienie: »7. Każdemu uczestnikowi korzystającemu z tej usługi [nazwa BC] udostępnia dzienne wyciągi z rachunku.«; |
9) |
art. 13 lit. b) otrzymuje brzmienie:
|
10) |
art. 14 ust. 1 lit. b) otrzymuje brzmienie:
|
11) |
art. 16 ust. 2 otrzymuje brzmienie: »2. Uczestnicy korzystający z dostępu przez Internet nie mogą korzystać z funkcji grupy AL w odniesieniu do swoich rachunków w PM dostępnych przez Internet, ani łączyć tych rachunków w PM dostępnych przez Internet z jakimikolwiek innymi posiadanymi przez nich rachunkami w TARGET2. Limity mogą być oznaczone jedynie w odniesieniu do grupy AL jako całości. Limity nie mogą być ustalane w odniesieniu do pojedynczego rachunku w PM uczestnika grupy AL.«; |
12) |
art. 18 ust. 3 otrzymuje brzmienie: »3. W przypadku posłużenia się wskaźnikiem najpóźniejszego terminu obciążenia przyjęte zlecenie płatnicze podlega zwrotowi jako niewykonane, jeżeli nie może zostać rozliczone do wskazanego terminu obciążenia. Na 15 minut przed określonym terminem obciążenia uczestnik zlecający zostaje powiadomiony przez ICM, zamiast wysyłania automatycznego zawiadomienia za pośrednictwem ICM. Uczestnik zlecający może również posłużyć się wskaźnikiem najpóźniejszego terminu obciążenia wyłącznie w charakterze ostrzegawczym. W takim przypadku dane zlecenie płatnicze nie podlega zwrotowi.«; |
13) |
art. 21 ust. 4 otrzymuje brzmienie: »4. Na wniosek płatnika [nazwa BC] może postanowić o dokonaniu zmiany pozycji w kolejce oczekujących zleceń płatniczych bardzo pilnego zlecenia płatniczego (z wyjątkiem bardzo pilnych zleceń płatniczych w zakresie procedury rozrachunkowej 5 i 6), o ile taka zmiana nie wpłynie na sprawny rozrachunek przez systemy zewnętrzne w TARGET2 lub w inny sposób nie zwiększy ryzyka systemowego.«; |
14) |
w art. 28 wprowadza się następujące zmiany:
|
15) |
art. 29 otrzymuje brzmienie: »Artykuł 29 Korzystanie z ICM 1. ICM:
2. Dalsze szczegóły techniczne dotyczące ICM w zakresie korzystania w związku z dostępem przez Internet zawiera dodatek IA do załącznika V.«; |
16) |
w art. 32 wprowadza się następujące zmiany:
|
17) |
art. 34 ust. 4 lit. c) otrzymuje brzmienie:
|
18) |
art. 39 ust. 1 otrzymuje brzmienie: »1. Przyjmuje się, że uczestnicy są świadomi wszystkich obowiązków ciążących na nich w związku z przepisami o ochronie danych, o zapobieganiu praniu pieniędzy i finansowaniu terroryzmu, działalności łączącej się z ryzykiem rozprzestrzeniania broni jądrowej oraz rozwoju środków przenoszenia broni jądrowej i są oni obowiązani do ich spełniania, w szczególności poprzez podejmowanie odpowiednich środków dotyczących płatności obciążających lub uznających ich rachunki w PM. Przed nawiązaniem stosunku umownego z dostawcą usług internetowych uczestnicy korzystający z dostępu przez Internet są obowiązani do zaznajomienia się z zasadami przechowywania danych stosowanymi przez dostawcę usług internetowych.«; |
19) |
art. 40 ust. 1 otrzymuje brzmienie: »1. O ile niniejsze Warunki nie stanowią inaczej, wszelkie zawiadomienia wymagane lub dopuszczalne zgodnie z niniejszymi Warunkami przekazuje się pocztą poleconą, faksem lub w inny sposób na piśmie. Zawiadomienia kierowane do [nazwa BC] przekazuje się dyrektorowi [departamentu systemu płatniczego lub innej odpowiedniej jednostki organizacyjnej BC] [nazwa BC], [adres BC], lub do [adres BIC BC]. Zawiadomienia kierowane do uczestnika przekazuje się na adres, numer faksu lub na jego adres BIC, zgłaszany przez uczestnika [nazwa BC] i aktualizowany.«; |
20) |
art. 45 otrzymuje brzmienie: »Artykuł 45 Odrębność postanowień Jeżeli którekolwiek z postanowień niniejszych Warunków lub załącznika V jest lub stanie się nieważne, okoliczność taka nie wyklucza stosowania wszystkich pozostałych postanowień Warunków oraz załącznika V.«. |
Dodatek IA
SPECYFIKACJE TECHNICZNE PRZETWARZANIA ZLECEŃ PŁATNICZYCH DLA DOSTĘPU PRZEZ INTERNET
W uzupełnieniu zharmonizowanych warunków, do przetwarzania zleceń płatniczych z wykorzystaniem dostępu przez Internet stosuje się następujące zasady:
1. Wymagania techniczne związane z uczestnictwem w systemie TARGET2-[oznaczenie BC/kraju] w zakresie infrastruktury, sieci oraz formatów
1) |
Uczestnicy korzystający z dostępu przez Internet przyłączają się do ICM systemu TARGET2, korzystając z klienta lokalnego, systemu operacyjnego oraz przeglądarki internetowej określonych w załączniku »Uczestnictwo przez Internet – Wymagania systemowe dla dostępu przez Internet« (Internet-based participation - System requirements for Internet access) do Szczegółowej specyfikacji funkcjonalnej użytkownika (User Detailed Functional Specifications, UDFS), ze zdefiniowanymi ustawieniami. Rachunek w PM każdego z Uczestników jest identyfikowany za pomocą 8- lub 11-cyfrowego kodu BIC. Ponadto przed dopuszczeniem do uczestnictwa w systemie TARGET2-[oznaczenie BC/kraju] każdy uczestnik przechodzi serię testów potwierdzających jego przygotowanie techniczne i operacyjne. |
2) |
Przy składaniu zleceń płatniczych i wymianie komunikatów płatniczych w PM korzysta się z BIC platformy TARGET2, TRGTXEPMLVP, jako nadawcy/odbiorcy komunikatu. Zlecenia płatnicze wysyłane do uczestnika korzystającego z dostępu przez Internet powinny identyfikować tego uczestnika otrzymującego w polu instytucji beneficjenta (beneficiary institution). Zlecenia płatnicze składane przez uczestnika korzystającego z dostępu przez Internet będą identyfikować tego uczestnika jako instytucję składającą zlecenie (ordering institution). |
3) |
Uczestnicy korzystający z dostępu przez Internet korzystają z usług infrastruktury klucza publicznego określonych w publikacji »User Manual Internet Access for the public-key certification service« (Podręcznik użytkownika dotyczący dostępu przez Internet do usług certyfikacji klucza publicznego). |
2. Typy komunikatów płatniczych
1) |
Uczestnicy z dostępem przez Internet mogą dokonywać następujących rodzajów płatności:
Uczestnicy korzystający z dostępu przez Internet do rachunku w PM mogą dodatkowo otrzymywać zlecenia obciążenia bezpośredniego. |
2) |
Uczestnicy przestrzegają określeń pól zdefiniowanych w rozdziale 9.1.2.2 UDFS, księga 1. |
3) |
Zawartość pól podlega zatwierdzeniu na poziomie systemu TARGET2-[oznaczenie kraju/BC], zgodnie z wymaganiami zawartymi w specyfikacji UDFS. Uczestnicy mogą uzgodnić między sobą szczegółowe zasady dotyczące zawartości pól. Jednak w ramach systemu TARGET2-[oznaczenie kraju/BC] przestrzeganie tych zasad przez uczestników nie będzie badane. |
4) |
Uczestnicy korzystający z dostępu przez Internet mogą dokonywać przez TARGET2 płatności pokrywających, tzn. płatności dokonanych przez banki korespondentów w celu rozliczenia (pokrycia) komunikatów polecenia przelewu, które zostają przekazane bankowi klienta za pomocą innych, bardziej bezpośrednich środków. Zawartych w tych płatnościach pokrywających szczegółów dotyczących klienta nie wyświetla się w ICM. |
3. Test na dwukrotne wprowadzenie
1) |
Wszystkie zlecenia płatnicze przechodzą test na dwukrotne wprowadzenie, którego celem jest odrzucenie zleceń płatniczych, które zostały wprowadzone omyłkowo więcej niż jeden raz. |
2) |
Sprawdzeniu podlegają następujące pola poszczególnych typów komunikatów:
|
3) |
Jeżeli wszystkie pola opisane w ust. 2 są dla nowo składanego zlecenia płatniczego identyczne jak w przypadku zlecenia płatniczego, które zostało już przyjęte, nowo składane zlecenie płatnicze podlega zwróceniu. |
4. Kody błędów
W przypadku odrzucenia zlecenia płatniczego udostępnia się przez ICM zawiadomienie o przerwaniu, wskazujące za pomocą kodów błędów przyczyny odrzucenia. Kody błędów są opisane w rozdziale 9.4.2 UDFS.
5. Określenie terminu rozrachunku z wyprzedzeniem
1) |
Dla zleceń płatniczych wykorzystujących wskaźnik najwcześniejszego terminu obciążenia używa się słowa kodowego »/FROTIME/«. |
2) |
Dla zleceń płatniczych wykorzystujących wskaźnik najpóźniejszego terminu obciążenia dostępne są dwie możliwości: a) słowo kodowe »/REJTIME/«: jeżeli rozrachunek transakcji nie może nastąpić przed wskazanym terminem obciążenia, zlecenie płatnicze podlega zwróceniu; b) słowo kodowe »/TILTIME/«: jeżeli rozrachunek zlecenia płatniczego nie może nastąpić przed wskazanym terminem obciążenia, zlecenie płatnicze nie podlega zwróceniu, ale zostaje umieszczone w odpowiedniej kolejce. W obydwu przypadkach, jeżeli zlecenie płatnicze zawierające wskaźnik najpóźniejszego terminu obciążenia nie zostanie wykonane 15 minut przed wskazanym terminem, za pośrednictwem ICM automatycznie udostępnia się zawiadomienie. |
3) |
W przypadku posłużenia się słowem kodowym »/CLSTIME/« płatność traktuje się tak samo jak zlecenie płatnicze, o którym mowa w ust. 2 lit. b). |
6. Rozrachunek zleceń płatniczych we wstępnej próbie przetwarzania
1) |
W celu umożliwienia szybkiego i oszczędzającego płynność rozrachunku brutto zleceń płatniczych zlecenia płatnicze wprowadzone do wstępnej próby przetwarzania poddaje się testowi na możliwość kompensowania lub, jeżeli jest to właściwe, rozszerzonemu testowi na możliwość kompensowania (zdefiniowanym w ust. 2 i 3). |
2) |
Test na możliwość kompensowania służy sprawdzeniu, czy zlecenia płatnicze odbiorcy płatności znajdujące się na czele kolejki płatności oczekujących oznaczonych jako bardzo pilne, lub – jeżeli takich brak – jako pilne, mogą być przedmiotem kompensowania ze zleceniem płatniczym płatnika (dalej »płatności podlegające kompensowaniu«). Jeżeli płatność podlegająca kompensowaniu nie zapewnia wystarczających środków na pokrycie odpowiedniego zlecenia płatniczego płatnika we wstępnej próbie przetwarzania, ustala się, czy na rachunku w PM płatnika znajduje się wystarczająca dostępna płynność. |
3) |
Jeżeli wynik testu na możliwość kompensowania jest negatywny, [nazwa BC] może zastosować rozszerzony test na możliwość kompensowania. Rozszerzony test na możliwość kompensowania służy sprawdzeniu, czy w którejkolwiek z kolejek płatności oczekujących należących do odbiorcy płatności znajdują się płatności podlegające kompensowaniu, niezależnie od chwili ich umieszczenia w danej kolejce. Jeżeli jednak w kolejce płatności oczekujących należących do odbiorcy płatności znajdują się zlecenia płatnicze oznaczone wyższym priorytetem zaadresowane do innych uczestników TARGET2, od zasady FIFO można odstąpić, wyłącznie gdy rozliczenie zlecenia płatniczego podlegającego kompensowaniu prowadziłoby do zwiększenia płynności odbiorcy płatności. |
7. Rozrachunek zleceń płatniczych w ramach kolejki zleceń oczekujących
1) |
Zlecenia płatnicze umieszczone w kolejkach zleceń oczekujących są traktowane w zależności od priorytetu, za pomocą którego dane zlecenie płatnicze zostało oznaczone przez uczestnika składającego instrukcję. |
2) |
Zlecenia płatnicze znajdujące się w kolejkach płatności oczekujących oznaczonych jako bardzo pilne i pilne podlegają rozrachunkowi przy wykorzystaniu testów na możliwość kompensowania, o których mowa w punkcie 6, poczynając od zlecenia płatniczego znajdującego się na czele kolejki, w przypadku gdy prowadzi to do wzrostu płynności lub w przypadku gdy następuje ingerencja w ramach kolejki (zmiana pozycji w kolejce, terminu rozrachunku lub priorytetu, lub odwołanie zlecenia płatniczego). |
3) |
Zlecenia płatnicze oczekujące w kolejce płatności oznaczonych jako zwykłe podlegają rozrachunkowi w sposób ciągły, włącznie z wszystkimi zleceniami płatniczymi oznaczonymi jako bardzo pilne i pilne, które nie zostały jeszcze poddane rozrachunkowi. Stosuje się różne mechanizmy optymalizacji (algorytmy). Jeżeli zastosowanie algorytmu okaże się skuteczne, objęte nim zlecenia płatnicze podlegają rozrachunkowi; jeżeli algorytm okaże się nieskuteczny, objęte nim zlecenia płatnicze pozostają w kolejce. Stosuje się trzy algorytmy (1 do 3) w celu kompensowania przepływów płatności. Użycie algorytmu 4 umożliwia wykorzystanie procedury rozrachunkowej 5 (określonej w rozdziale 2.8.1 UDFS) dla rozrachunku instrukcji płatniczych systemów zewnętrznych. W celu optymalizacji rozrachunku na subkontach uczestników transakcji systemów zewnętrznych oznaczonych jako bardzo pilne stosuje się specjalny algorytm (algorytm 5).
|
4) |
Zlecenia płatnicze wprowadzone do wstępnej próby przetwarzania po uruchomieniu któregokolwiek z algorytmów 1 do 4 mogą mimo wszystko podlegać rozrachunkowi natychmiast we wstępnej próbie przetwarzania, jeżeli pozycje i limity właściwych rachunków w PM uczestników TARGET2 umożliwiają zarówno rozrachunek tych zleceń płatniczych, jak i rozrachunek zleceń płatniczych w ramach bieżącej procedury optymalizacji. Nie jest jednak możliwe równoczesne stosowanie dwóch algorytmów. |
5) |
W czasie przetwarzania dziennego algorytmy stosowane są według ustalonej kolejności. O ile nie jest w toku równoczesny rozrachunek wielostronny systemu zewnętrznego, kolejność ta jest następująca:
Jeżeli równoczesny rozrachunek wielostronny (»procedura 5«) systemu zewnętrznego jest w toku, stosuje się algorytm 4. |
6) |
Algorytmy stosuje się w sposób elastyczny dzięki określonemu z góry odstępowi czasowemu między uruchomieniami poszczególnych algorytmów w celu zapewnienia minimalnej przerwy między działaniem dwóch algorytmów. Następstwo czasowe podlega automatycznej kontroli. Możliwa jest również interwencja ręczna. |
7) |
Po objęciu zlecenia płatniczego działaniem algorytmu nie jest możliwa zmiana jego pozycji w kolejce ani jego odwołanie. Wnioski o zmianę pozycji w kolejce lub odwołanie zlecenia płatniczego zostają umieszczone w kolejce do czasu zakończenia działania algorytmu. Jeżeli dane zlecenie płatnicze zostanie poddane rozrachunkowi w czasie działania algorytmu, wniosek o zmianę pozycji w kolejce lub odwołanie zlecenia podlega odrzuceniu. Jeżeli rozrachunek zlecenia płatniczego nie został dokonany, wnioski uczestnika uwzględnia się niezwłocznie. |
8. Wykorzystywanie ICM
1) |
Moduł ICM może być wykorzystywany do wprowadzania zleceń płatniczych. |
2) |
Moduł ICM może być wykorzystywany do pozyskiwania informacji i zarządzania płynnością. |
3) |
Z wyjątkiem przechowywanych zleceń płatniczych oraz informacji dotyczących danych statycznych, w ICM dostępne są tylko dane dotyczące bieżącego dnia operacyjnego. Treść ekranów dostępna jest wyłącznie w języku angielskim. |
4) |
Informacje udostępniane są w trybie »na żądanie«, co oznacza, że każdy uczestnik musi zwrócić się o udostępnienie mu informacji. Uczestnicy regularnie sprawdzają w ciągu dnia operacyjnego, czy w ICM nie pojawiły się ważne komunikaty. |
5) |
Uczestnicy korzystający z dostępu przez Internet mają dostęp tylko do trybu użytkownika-aplikacja (user-to-application mode, U2 A). Tryb U2 A umożliwia bezpośrednią komunikację pomiędzy uczestnikiem a ICM. Informacje wyświetlane są w przeglądarce działającej na PC. Dalsze szczegóły zawarte są w Podręczniku użytkownika ICM. |
6) |
Każdy użytkownik dysponuje przynajmniej jednym stanowiskiem z dostępem do Internetu w celu uzyskania dostępu do ICM w trybie U2 A. |
7) |
Prawa dostępu do ICM przyznaje się za pomocą certyfikatów, z których korzystanie opisano w pełniejszy sposób w ust. 10–13. |
8) |
Uczestnicy mogą również używać ICM do przekazywania płynności:
|
9. Specyfikacja UDFS oraz publikacje »ICM User Handbook« i »User Manual: Internet Access for the Public Key Certification Service«
Dalsze informacje szczegółowe oraz przykłady objaśniające powyższe zasady zawarte są w specyfikacji UDFS oraz w publikacji »ICM User Handbook« (Podręcznik użytkownika ICM), okresowo aktualizowanych i publikowanych w języku angielskim na stronach internetowych [nazwa BC] oraz systemu TARGET2, a także w publikacji »User Manual: Internet Access for the Public Key Certification Service« (Podręcznik użytkownika dotyczący dostępu przez Internet do usług certyfikacji klucza publicznego).
10. Wydawanie, zawieszanie, reaktywacja, cofnięcie i odnawianie certyfikatów
1) |
Uczestnicy zwracają się do [nazwa BC] o wydanie certyfikatów w celu umożliwienia im dostępu do TARGET2-[oznaczenie BC/kraju] z wykorzystaniem dostępu przez Internet. |
2) |
Uczestnicy zwracają się do [nazwa BC] o zawieszenie i reaktywację certyfikatów, jak również o cofnięcie i odnowienie certyfikatów, w przypadku gdy posiadacz certyfikatu nie zamierza już mieć dostępu do TARGET2 lub jeżeli uczestnik zaprzestaje swojej działalności w TARGET2-[oznaczenie BC/kraju] (np. w wyniku połączenia lub przejęcia). |
3) |
Uczestnik dochowuje należytej ostrożności i podejmuje wszelkie środki organizacyjne w celu zapewnienia, aby certyfikaty były wykorzystywane wyłącznie w sposób zgodny ze zharmonizowanymi warunkami. |
4) |
Uczestnicy niezwłocznie powiadamiają [nazwa BC] o jakichkolwiek zmianach w zakresie treści jakichkolwiek informacji zawartych w formularzach złożonych do [nazwa BC] w związku z wydaniem certyfikatów. |
5) |
Uczestnik może posiadać nie więcej niż 5 aktywnych certyfikatów dla każdego rachunku w PM. Na żądanie, [nazwa BC] może również złożyć według swojego uznania o wydanie kolejnych certyfikatów wniosek przez organy certyfikacyjne. |
11. Postępowanie uczestnika z certyfikatami
1) |
Uczestnik zapewnia bezpieczne przechowywanie certyfikatów i podejmuje skuteczne środki organizacyjne i techniczne w celu uniknięcia poszkodowania osób trzecich oraz zapewnienia używania certyfikatów wyłącznie przez posiadacza certyfikatu, któremu został on wydany. |
2) |
Uczestnik dostarcza niezwłocznie wszelkich informacji żądanych przez [nazwa BC] i gwarantuje rzetelność tych informacji. Uczestnik ponosi również ciągłą i pełną odpowiedzialność za stałą dokładność informacji dostarczanych [nazwa BC] w związku z wydawaniem certyfikatów. |
3) |
Uczestnik ponosi pełną odpowiedzialność za zapewnienie, aby wszyscy wskazani przez niego posiadacze certyfikatów przechowywali przydzielone im certyfikaty oddzielnie od tajnych kodów PIN i PUK. |
4) |
Uczestnik ponosi pełną odpowiedzialność za zapewnienie, aby żaden ze wskazanych przez niego posiadaczy certyfikatów nie korzystał z certyfikatów w innych celach lub funkcjach niż te, dla których certyfikaty zostały wydane. |
5) |
Uczestnik informuje niezwłocznie [nazwa BC] o jakichkolwiek wnioskach o zawieszenie, reaktywację, cofnięcie lub odnowienie certyfikatów oraz o powodach tych czynności. |
6) |
Uczestnik niezwłocznie zwraca się do [nazwa BC] o zawieszenie jakichkolwiek certyfikatów lub zawartych w nich kluczy, które dotknięte zostały defektem albo nie są już w posiadaniu wskazanych przez niego posiadaczy certyfikatów. |
7) |
Uczestnik informuje niezwłocznie [nazwa BC] o jakimkolwiek przypadku utraty lub kradzieży certyfikatów. |
12. Wymogi dotyczące bezpieczeństwa
1) |
System komputerowy używany przez uczestnika do uzyskiwania dostępu do TARGET2 z wykorzystaniem dostępu przez Internet powinien znajdować się w lokalu będącym własnością uczestnika, lub którego najemcą jest uczestnik. Dostęp do TARGET2-[oznaczenie BC/kraju] dozwolony jest jedynie z takiego lokalu, przy czym, dla uniknięcia wątpliwości, nie zezwala się na dostęp zdalny. |
2) |
Uczestnik korzysta z wszelkiego oprogramowania na systemach komputerowych zainstalowanych i posiadających indywidualne ustawienia zgodne z aktualnymi międzynarodowymi standardami bezpieczeństwa IT, które powinny co najmniej zawierać wymogi określone w pkt 12 ust. 3 i pkt 13 ust. 4. Uczestnik przyjmuje odpowiednie środki, w tym w szczególności zapewniające ochronę przed wirusami i złośliwym oprogramowaniem, zapobiegające wykradaniu haseł, jak również procedury podnoszenia poziomu bezpieczeństwa oraz wprowadzania poprawek do oprogramowania. Uczestnik regularnie aktualizuje wszelkie takie środki i procedury. |
3) |
Uczestnik zakłada zaszyfrowane połączenie komunikacyjne z TARGET2-[oznaczenie BC/kraju] dla dostępu przez Internet. |
4) |
Konta użytkowników na stacjach roboczych uczestnika nie mają uprawnień administratora. Uprawnienia przyznaje się zgodnie z zasadą »jak najmniejszych uprawnień«. |
5) |
Uczestnicy zapewniają ciągłą ochronę systemów komputerowych używanych dla dostępu przez Internet do TARGET2-[oznaczenie BC/kraju] w następujący sposób:
|
6) |
Uczestnicy zapewniają ciągłe przestrzeganie przez wskazanych przez nich posiadaczych certyfikatów zasad bezpiecznego korzystania z Internetu, w tym:
|
7) |
Dla ograniczenia ryzyka dla swojego systemu uczestnik stale stosuje się do następujących zasad zarządzania:
|
13. Dodatkowe wymogi dotyczące bezpieczeństwa
1) |
Uczestnik w sposób ciągły zapewnia, przez stosowanie odpowiednich środków organizacyjnych lub technicznych, aby nie dochodziło do nadużywania danych identyfikacyjnych użytkownika ujawnionych w celu kontroli uprawnień dostępu (procedura przeglądu uprawnień dostępu – Access Right Review), w szczególności, aby wiedzy o nich nie uzyskiwały osoby nieuprawnione. |
2) |
Uczestnik stosuje procedurę administracji użytkownikami w celu zapewnienia niezwłocznego i trwałego usunięcia danych identyfikacyjnych użytkownika w przypadku, gdy pracownik lub inny użytkownik systemu w lokalu uczestnika opuszcza instytucję uczestnika. |
3) |
Uczestnik stosuje procedurę administracji użytkownikami i niezwłocznie i trwale blokuje dane identyfikacyjne użytkownika, które zostały w jakikolwiek sposób zagrożone, w tym w przypadku utraty lub kradzieży certyfikatów, jak również wykradzenia hasła. |
4) |
Jeżeli uczestnik nie jest w stanie usunąć usterek w zakresie bezpieczeństwa lub błędów konfiguracji (np. wynikających z zainfekowania systemu złośliwym oprogramowaniem), po ich trzykrotnym wystąpieniu BC dostarczający SSP może trwale zablokować dane identyfikacyjne wszystkich użytkowników od danego uczestnika. |
Dodatek IIA
TARYFA OPŁAT I FAKTUROWANIE DLA DOSTĘPU PRZEZ INTERNET
Opłaty dla uczestników bezpośrednich
1. |
Opłata miesięczna za przetwarzanie zleceń płatniczych w systemie TARGET2-[oznaczenie BC/kraju] wynosi dla uczestników bezpośrednich 70 EUR za rachunek w PM opłaty za dostęp przez Internet, 100 EUR opłaty za rachunek w PM oraz jednolitą opłatę za każdą transakcję (obciążenie rachunku) w wysokości 0,80 EUR. |
2. |
Od uczestników bezpośrednich, którzy nie życzą sobie publikacji BIC ich rachunków w TARGET2 directory, pobierana będzie dodatkowa miesięczna opłata w wysokości 30 EUR od każdego rachunku. |
Fakturowanie
3. |
W przypadku uczestników bezpośrednich stosuje się następujące zasady fakturowania. Uczestnik bezpośredni otrzymuje fakturę za poprzedni miesiąc określającą opłaty do zapłaty nie później niż piątego dnia operacyjnego kolejnego miesiąca. Zapłata następuje najpóźniej dziesiątego dnia operacyjnego tego miesiąca na rachunek wskazany przez [nazwa BC] i zostaje ona pobrana z rachunku w PM danego uczestnika. |