|
3.10.2009
|
PL
|
Dziennik Urzędowy Unii Europejskiej
|
L 260/31
|
WYTYCZNE EUROPEJSKIEGO BANKU CENTRALNEGO
z dnia 17 września 2009 r.
zmieniające wytyczne EBC/2007/2 w sprawie transeuropejskiego zautomatyzowanego błyskawicznego systemu rozrachunku brutto w czasie rzeczywistym (TARGET2)
(EBC/2009/21)
(2009/734/WE)
RADA PREZESÓW EUROPEJSKIEGO BANKU CENTRALNEGO,
uwzględniając Traktat ustanawiający Wspólnotę Europejską, w szczególności jego art. 105 ust. 2 tiret pierwsze i czwarte,
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 nową wersję SSP; b) w celu wyjaśnienia szczególnych zasad dotyczących miejsca położenia instytucji sprawujących nadzór systemowy, do których przestrzegania obowiązane są podmioty świadczące usługi w euro; c) wprowadzające wyłączenia dotyczące porozumień dwustronnych z systemami zewnętrznymi, które zakładają rachunki w PM i nie podlegają roszczeniom z tytułu zastawu lub potrącenia wierzytelności; d) uwzględniające szereg innych zmian i wyjaśnień o charakterze technicznym i redakcyjnym; oraz e) skreślające nieobowiązujące już postanowienia dotyczące migracji do TARGET2,
|
PRZYJMUJE NINIEJSZE WYTYCZNE:
Artykuł 1
W wytycznych EBC/2007/2 wprowadza się następujące zmiany:
|
1)
|
w art. 2 definicja „systemu zewnętrznego” otrzymuje brzmienie:
|
„—
|
»system zewnętrzny« system zarządzany przez podmiot mający siedzibę w EOG i podlegający nadzorowi ostrożnościowemu (supervision) lub nadzorowi systemowemu (oversight) właściwego organu, spełniający wymogi nadzorcze dotyczące miejsca położenia infrastruktury świadczącej usługi w euro, okresowo nowelizowane i ogłaszane na stronie internetowej EBC (2), w przypadku gdy w systemie takim odbywa się obrót płatnościami lub instrumentami finansowymi, względnie rozliczanie takiego obrotu, przy czym rozrachunek powstających w ten sposób zobowiązań pieniężnych następuje w TARGET2 zgodnie z niniejszymi wytycznymi oraz umową dwustronną między danym systemem zewnętrznym a odpowiednim BC Eurosystemu,
|
|
|
2)
|
w art. 8 dodaje się ust. 4 w brzmieniu:
„4. W drodze wyjątku od postanowień ust. 3 porozumienia dwustronne z systemami zewnętrznymi stosującymi interfejs użytkownika, które dokonują rozrachunku transakcji płatniczych jedynie na rzecz swoich klientów, powinny być zgodne z:
|
a)
|
załącznikiem II, z wyjątkiem tytułu V, art. 36 oraz dodatków VI i VII; oraz
|
|
b)
|
art. 18 załącznika IV.”;
|
|
|
4)
|
artykuł 15 otrzymuje brzmienie:
„Artykuł 15
Postanowienia różne oraz przejściowe
1. Rachunki otwarte poza PM przez uczestniczący KBC dla instytucji kredytowych oraz systemów zewnętrznych podlegają regułom danego uczestniczącego KBC, z zastrzeżeniem postanowień niniejszych wytycznych odnoszących się do rachunków typu home oraz innych decyzji Rady Prezesów. Rachunki otwarte poza PM przez uczestniczący KBC dla podmiotów innych niż instytucje kredytowe oraz systemy zewnętrzne podlegają regułom danego uczestniczącego KBC.
2. Podczas okresu przejściowego każdy BC Eurosystemu może w dalszym ciągu dokonywać na swoich rachunkach typu home rozrachunku transakcji płatniczych i innych transakcji, w tym:
|
a)
|
płatności między instytucjami kredytowymi;
|
|
b)
|
płatności między instytucjami kredytowymi a systemami zewnętrznymi; oraz
|
|
c)
|
płatności dotyczących operacji otwartego rynku Eurosystemu.
|
3. Z upływem okresu przejściowego ustają:
|
a)
|
rejestracja adresowalnego posiadacza BIC przez BC Eurosystemu – w przypadku podmiotów, o których mowa w art. 4 ust. 1 lit. a) i b) załącznika II;
|
|
b)
|
uczestnictwo pośrednie za pośrednictwem BC Eurosystemu; oraz
|
|
c)
|
rozrachunek na rachunkach typu home wszystkich płatności, o których mowa w ust. 2 lit. a)–c).”;
|
|
|
5)
|
Załączniki II, III i IV do wytycznych EBC/2007/2 podlegają zmianie zgodnie z załącznikiem do niniejszych wytycznych.
|
Artykuł 2
Wejście w życie
1. Niniejsze wytyczne wchodzą w życie z dniem 22 września 2009 r.
2. Artykuł 1 ust. 1 oraz pkt 1 ust. 1 lit. a), pkt 1 ust. 2 i pkt 2 załącznika do niniejszych wytycznych stosuje się od dnia 23 października 2009 r.
3. Pozostałe przepisy niniejszych wytycznych stosuje się od dnia 23 listopada 2009 r.
Artykuł 3
Adresaci i sposób implementacji
1. Niniejsze wytyczne stosuje się do wszystkich banków centralnych Eurosystemu.
2. Krajowe banki centralne państw członkowskich, które przyjęły euro, informują EBC o środkach, za pomocą których zamierzają zastosować się do niniejszych wytycznych najpóźniej do dnia 9 października 2009 r.
Sporządzono we Frankfurcie nad Menem dnia 17 września 2009 r.
W imieniu Rady Prezesów EBC
Jean-Claude TRICHET
Prezes EBC
(1) Dz.U. L 237 z 8.9.2007, s. 1.
(2) Obecna polityka Eurosystemu w zakresie miejsca położenia infrastruktury określona jest w następujących komunikatach, dostępnych na stronie internetowej EBC pod adresem www.ecb.europa.eu: a) »Policy statement on euro payment and settlement systems located outside the euro area« z dnia 3 listopada 1998 r.; b) »The Eurosystem’s policy line with regard to consolidation in central counterparty clearing« z dnia 27 września 2001 r.; c) »The Eurosystem policy principles on the location and operation of infrastructures settling in euro-denominated payment transactions« z dnia 19 lipca 2007 r.; oraz d) »The Eurosystem policy principles on the location and operation of infrastructures settling euro-denominated payment transactions: specification of ‘legally and operationally located in the euro area’ « z dnia 20 listopada 2008 r.”;
ZAŁĄCZNIK
|
1.
|
W załączniku II do wytycznych EBC/2007/2 wprowadza się następujące zmiany:
|
1)
|
w art. 1 wprowadza się następujące zmiany:
|
a)
|
definicja terminu „system zewnętrzny” otrzymuje brzmienie:
|
„—
|
»system zewnętrzny« – system zarządzany przez podmiot mający siedzibę w Europejskim Obszarze Gospodarczym (EOG) i podlegający nadzorowi ostrożnościowemu (supervision) lub nadzorowi systemowemu (oversight) właściwego organu, spełniający wymogi nadzorcze dotyczące miejsca położenia infrastruktury świadczącej usługi w euro, okresowo nowelizowane i ogłaszane na stronie internetowej EBC (1), w przypadku gdy w systemie takim odbywa się obrót płatnościami lub instrumentami finansowymi, względnie rozliczanie takiego obrotu, przy czym rozrachunek powstających w ten sposób zobowiązań pieniężnych następuje w TARGET2 zgodnie z wytycznymi EBC/2007/2 oraz umową dwustronną między danym systemem zewnętrznym a odpowiednim BC Eurosystemu,
|
|
|
b)
|
definicja terminu „techniczna niesprawność TARGET2” otrzymuje brzmienie:
|
„—
|
»techniczna niesprawność TARGET2« (technical malfunction of TARGET2) – jakiekolwiek trudności, awarie bądź błędy w funkcjonowaniu infrastruktury technicznej lub systemów komputerowych używanych przez TARGET2-[oznaczenie BC/kraju] lub jakiekolwiek inne zdarzenie powodujące niemożliwość wykonania i zakończenia przetwarzania płatności w TARGET2-[oznaczenie BC/kraju]w tym samym dniu.”;
|
|
|
|
2)
|
artykuł 4 ust. 2 lit. d) otrzymuje brzmienie:
|
„d)
|
podmioty zarządzające systemami zewnętrznymi i działające w tym charakterze; oraz”;
|
|
|
3)
|
w art. 9 wprowadza się następujące zmiany:
|
a)
|
ustęp 2 otrzymuje brzmienie:
„2. Przy braku odmiennych wniosków uczestnika w tym zakresie, jego BIC publikuje się w TARGET2 directory.”;
|
|
b)
|
dodaje się ust. 5 w brzmieniu:
„5. Uczestnicy przyjmują do wiadomości, że [nazwa BC] oraz inne BC są uprawnione do publikowania nazw oraz BIC uczestników. Publikowane mogą być także nazwy i BIC uczestników pośrednich zarejestrowanych przez uczestników, przy czym uczestnicy zapewniają zgodę uczestników pośrednich na taką publikację.”;
|
|
|
4)
|
artykuł 12 ust. 1 otrzymuje brzmienie:
„1. [Nazwa BC] otwiera i prowadzi co najmniej jeden rachunek w PM dla każdego uczestnika. Na żądanie uczestnika działającego jako bank rozrachunkowy [nazwa BC] otwiera jedno lub większą ilość subkont w TARGET2-[oznaczenie BC/kraju], do wykorzystywania przy dedykowaniu płynności.”;
|
|
5)
|
dodaje się art. 14 ust. 3 w brzmieniu:
„3. SSP określa znacznik czasu w ramach przetwarzania zleceń płatniczych w oparciu o chwilę otrzymania i przyjęcia danego zlecenia płatniczego.”;
|
|
6)
|
artykuł 15 otrzymuje brzmienie:
„Artykuł 15
Zasady ustalania priorytetów
1. Uczestnik zlecający oznacza każde zlecenie płatnicze przy pomocy jednego z poniższych oznaczeń:
|
a)
|
zwykłe zlecenie płatnicze (priorytet klasy 2);
|
|
b)
|
pilne zlecenie płatnicze (priorytet klasy 1); lub
|
|
c)
|
bardzo pilne zlecenie płatnicze (priorytet klasy 0).
|
Zlecenia płatnicze niezawierające oznaczenia priorytetu traktuje się jako zlecenia płatnicze zwykłe.
2. Zlecenie płatnicze może być oznaczone jako bardzo pilne tylko przez:
|
b)
|
uczestników – w przypadkach płatności pochodzących lub przekazywanych na rzecz CLS International Bank oraz przekazań płynności dotyczących rozrachunku systemu zewnętrznego korzystającego z interfejsu systemu zewnętrznego.
|
Wszystkie instrukcje płatnicze przekazywane przez system zewnętrzny za pomocą interfejsu systemu zewnętrznego w celu obciążenia lub uznania rachunku PM uczestników są uznawane za bardzo pilne zlecenia płatnicze.
3. Zlecenia przekazania płynności inicjowane za pośrednictwem ICM uznawane są za pilne zlecenia płatnicze.
4. W przypadku pilnych i zwykłych zleceń płatniczych płatnik może ze skutkiem natychmiastowym dokonać zmiany priorytetu za pośrednictwem ICM. Nie jest możliwa zmiana priorytetu zlecenia płatniczego oznaczonego jako bardzo pilne.”;
|
|
7)
|
artykuł 17 ust. 5 otrzymuje brzmienie:
„5. Po otrzymaniu wniosku o ustanowienie rezerwy [nazwa BC] sprawdza, czy kwota płynności na rachunku w PM uczestnika jest wystarczająca dla ustanowienia rezerwy. Jeżeli tak nie jest, ustanawia się rezerwę tylko na kwocie płynności dostępnej na rachunku w PM. Pozostała część wnioskowanej rezerwy ustanawiana jest w razie udostępnienia dodatkowej płynności.”;
|
|
8)
|
dodaje się art. 17a w brzmieniu:
„Artykuł 17a
Stałe instrukcje ustanawiania rezerwy oraz dedykowania płynności
1. Uczestnicy mogą określić domyślną kwotę płynności zarezerwowanej na realizację pilnych lub bardzo pilnych zleceń płatniczych za pośrednictwem ICM. Taka stała instrukcja lub zmiany takiej instrukcji są skuteczne od następnego dnia operacyjnego.
2. Uczestnicy mogą określić za pośrednictwem ICM domyślną kwotę płynności przeznaczonej na rozrachunek systemu zewnętrznego. Taka stała instrukcja lub zmiany takiej instrukcji są skuteczne od następnego dnia operacyjnego. Uznaje się, że uczestnik złożył [nazwa BC] instrukcję dedykowania płynności w swoim imieniu w razie zgłoszenia takiego żądania przez system zewnętrzny.”;
|
|
9)
|
artykuł 21 otrzymuje brzmienie:
„Artykuł 21
Rozrachunek i zwrot zleceń płatniczych oczekujących w kolejce
1. Zlecenia płatnicze, które nie zostają natychmiast rozliczone w ramach wstępnej próby przetwarzania, umieszczane są w kolejkach zleceń oczekujących według ich priorytetów określonych przez danego uczestnika zgodnie z art. 15.
2. W celu optymalizacji rozrachunku oczekujących zleceń płatniczych [nazwa BC] może stosować procedury optymalizacyjne określone w dodatku I.
3. Za wyjątkiem bardzo pilnych zleceń płatniczych, płatnik może dokonać zmiany pozycji w kolejce oczekujących zleceń płatniczych (tzn. zmieniać ich kolejność) za pomocą ICM. Zlecenia płatnicze mogą być przenoszone ze skutkiem natychmiastowym na początek albo na koniec kolejki zleceń oczekujących w dowolnym momencie przetwarzania dziennego, o którym mowa w dodatku V.
4. Na wniosek płatnika [nazwa BC] lub – w przypadku grupy AL – BC menedżera grupy AL może zadecydować o dokonaniu zmiany pozycji w kolejce oczekujących zleceń płatniczych bardzo pilnego zlecenia płatniczego (za 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.
5. Zlecenia przekazania płynności inicjowane za pomocą ICM będą niezwłocznie zwracane jako nierozliczone w razie braku wystarczających środków. Inne zlecenia płatnicze będą zwracane jako nierozliczone, jeżeli nie mogą zostać rozliczone przed końcową granicą czasową dla danego rodzaju komunikatu, określoną w dodatku V.”;
|
|
10)
|
artykuł 24 ust. 7 otrzymuje brzmienie:
„7. Do procedury uzyskiwania zgody na stosowanie trybu CAI stosuje się odpowiednio procedurę uzyskiwania zgody na stosowanie trybu AL określoną w art. 25 ust. 4 i 5. Menedżer grupy CAI nie przekazuje zarządzającemu KBC egzemplarza porozumienia w sprawie stosowania trybu CAI.”;
|
|
11)
|
ustępy 2 i 3 w art. 37 otrzymują brzmienie:
„2. [Nazwa BC] dokona blokady salda subkonta uczestnika po otrzymaniu wiadomości od systemu zewnętrznego (za pomocą komunikatu o rozpoczęciu cyklu). O ile ma to zastosowanie, [nazwa BC] następnie zwiększa lub zmniejsza zablokowane saldo poprzez uznawanie lub obciążanie subkonta płatnościami rozrachunku międzysystemowego lub uznawanie subkonta transferami płynności. Blokada salda wygaśnie z chwilą otrzymania wiadomości od systemu zewnętrznego (za pomocą komunikatu o zakończeniu cyklu).
3. Potwierdzając dokonanie blokady salda subkonta uczestnika, [nazwa BC] gwarantuje systemowi zewnętrznemu płatność do wysokości kwoty w danym saldzie. O ile ma to zastosowanie, poprzez potwierdzenie zwiększenia lub zmniejszenia zablokowanego salda po uznaniu lub obciążeniu subkonta płatnościami rozrachunku międzysystemowego lub uznaniu subkonta transferami płynności następuje automatyczne zwiększenie lub zmniejszenie gwarancji o kwotę płatności. Z zastrzeżeniem wskazanych powyżej przypadków zwiększenia lub zmniejszenia gwarancji, gwarancja jest nieodwołalna, bezwarunkowa oraz płatna na pierwsze żądanie. Jeśli [nazwa BC] nie jest BC systemu zewnętrznego, to uznaje się, że [nazwa BC] otrzymał polecenie udzielenia wspomnianej gwarancji BC systemu zewnętrznego.”;
|
|
12)
|
w dodatku I wprowadza się następujące zmiany:
|
a)
|
w pkt 2 wprowadza się następujące zmiany:
|
(i)
|
tabela w ust. 1 otrzymuje brzmienie:
|
„Rodzaj komunikatu
|
Rodzaj użycia
|
Opis
|
|
MT 103
|
Obowiązkowy
|
Płatność klientowska
|
|
MT 103+
|
Obowiązkowy
|
Płatność klientowska – przetwarzanie bezpośrednie (STP)
|
|
MT 202
|
Obowiązkowy
|
Płatność międzybankowa
|
|
MT 202COV
|
Obowiązkowy
|
Płatności pokrywające
|
|
MT 204
|
Opcjonalny
|
Płatność z tytułu obciążenia bezpośredniego
|
|
MT 011
|
Opcjonalny
|
Zawiadomienie o dostarczeniu
|
|
MT 012
|
Opcjonalny
|
Zawiadomienie wysyłającego
|
|
MT 019
|
Obowiązkowy
|
Zawiadomienie o przerwaniu
|
|
MT 900
|
Opcjonalny
|
Potwierdzenie obciążenia
|
|
MT 910
|
Opcjonalny
|
Potwierdzenie uznania
|
|
MT 940/950
|
Opcjonalny
|
Komunikat zawierający wyciąg z rachunku (klienta)”;
|
|
|
(ii)
|
dodaje się ust. 5 w brzmieniu:
|
„5)
|
Komunikatu MT 202COV używa się w celu przeprowadzania płatności pokrywających, tzn. płatności przeprowadzanych 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. Szczegółów dotyczących klienta zawartych w komunikacie MT 202COV nie wyświetla się w ICM.”;
|
|
|
|
b)
|
w pkt 8 wprowadza się następujące zmiany:
|
(i)
|
ustęp 4 lit. b) otrzymuje brzmienie:
|
„b)
|
tryb użytkownik-aplikacja (user-to-applicaton mode, U2A)
Tryb U2A umożliwia bezpośrednią komunikację pomiędzy uczestnikiem a ICM. Informacje wyświetlane są w przeglądarce działającej w systemie PC (SWIFT Alliance WebStation lub inny interfejs, który może być wymagany przez SWIFT). Dla uzyskania dostępu w trybie U2A infrastruktura informatyczna musi obsługiwać „ciasteczka” (cookies) i JavaScript. Dalsze szczegóły zawarte są w Podręczniku użytkownika ICM.”;
|
|
|
(ii)
|
ustęp 5 otrzymuje brzmienie:
|
„5)
|
Każdy użytkownik dysponuje przynajmniej jedną SWIFT Alliance WebStation lub innym interfejsem, który może być wymagany przez SWIFT, w celu uzyskania dostępu do ICM w trybie U2A.”;
|
|
|
|
|
13)
|
w dodatku II wprowadza się następujące zmiany:
Punkt 2 otrzymuje brzmienie:
„2. Warunki ofert rekompensaty
|
a)
|
Płatnik może zgłosić roszczenia o opłatę administracyjną oraz rekompensatę odsetkową, jeżeli w wyniku technicznej niesprawności TARGET2 rozrachunek danego zlecenia płatniczego nie nastąpił w dniu operacyjnym, w którym zlecenie to zostało przyjęte.
|
|
b)
|
Odbiorca płatności może zgłosić roszczenie o opłatę administracyjną, jeżeli w wyniku technicznej niesprawności TARGET2 nie otrzymał płatności, którą miał otrzymać w danym dniu operacyjnym. Odbiorca płatności może także zgłosić roszczenie o rekompensatę odsetkową, jeżeli spełniony jest co najmniej jeden z poniższych warunków:
|
(i)
|
w przypadku uczestników mających dostęp do kredytu banku centralnego na koniec dnia (marginal lending facility): w wyniku technicznej niesprawności TARGET2 odbiorca płatności musiał skorzystać z kredytu banku centralnego na koniec dnia; lub
|
|
(ii)
|
w przypadku wszystkich uczestników: uzyskanie przez niego odpowiednich środków na rynku pieniężnym było niemożliwe z powodów technicznych lub refinansowanie w ten sposób było niemożliwe z innych obiektywnie uzasadnionych powodów.”;
|
|
|
|
14)
|
w dodatku III wprowadza się następujące zmiany:
Punkt 3.6.a w Ramowej treści opinii krajowych dla uczestników TARGET2 spoza EOG otrzymuje brzmienie:
„3.6.a. Przelew lub przeniesienie praw lub aktywów na zabezpieczenie (assignment of rights or deposit assets for collateral purposes); zastaw (pledge) oraz transakcje odwracalne (repo)
Przelew lub przeniesienie praw na zabezpieczenie będą ważne i skuteczne na podstawie przepisów prawa [jurysdykcja]. W szczególności ustanowienie lub realizacja zastawu bądź zawarcie i wykonanie transakcji odwracalnej zgodnie z [dodać odniesienie do odpowiednich postanowień umowy z bankiem centralnym] będzie ważne i skuteczne na podstawie przepisów prawa [jurysdykcja].”;
|
|
15)
|
w dodatku IV wprowadza się następujące zmiany:
Punkt 1 lit. b) otrzymuje brzmienie:
|
„b)
|
Ilekroć w niniejszym dodatku określa się dokładny czas, należy przez to rozumieć czas lokalny w siedzibie EBC, tzn. czas środkowoeuropejski (CET (2)).
|
|
|
16)
|
dodatek V otrzymuje brzmienie:
„Dodatek V
HARMONOGRAM OPERACYJNY
|
1.
|
TARGET2 działa we wszystkie dni za wyjątkiem sobót, niedziel, Nowego Roku, Wielkiego Piątku oraz Poniedziałku Wielkanocnego (według kalendarza obowiązującego w miejscu siedziby EBC), 1 maja, pierwszego dnia Bożego Narodzenia oraz 26 grudnia.
|
|
2.
|
Czasem odniesienia dla systemu jest czas lokalny w siedzibie EBC, tzn. CET.
|
|
3.
|
Bieżący dzień operacyjny rozpoczyna się wieczorem poprzedniego dnia operacyjnego i przebiega zgodnie z następującym harmonogramem:
|
Godzina
|
Opis
|
|
6.45–7.00
|
Przerwa w działalności na przygotowanie operacji dziennych (3)
|
|
7.00–18.00
|
Przetwarzanie dzienne
|
|
17.00
|
Końcowa granica czasowa dla płatności klientowskich (tj. płatności, w przypadku których zleceniodawca lub beneficjent płatności nie jest uczestnikiem bezpośrednim lub pośrednim; identyfikuje się je w systemie poprzez użycie komunikatu MT 103 lub MT 103+)
|
|
18.00
|
Końcowa granica czasowa dla płatności międzybankowych (tj. płatności niebędących płatnościami klientowskimi)
|
|
18.00–18.45 (4)
|
Przetwarzanie na koniec dnia
|
|
18.15 (4)
|
Ogólna końcowa granica czasowa korzystania z operacji Banku Centralnego na koniec dnia (standing facilities)
|
|
(Krótko po) 18.30 (5)
|
Dane konieczne do dokonania aktualizacji systemów księgowych są dostępne dla BC
|
|
18.45–19.30 (5)
|
Rozpoczęcie przetwarzania dziennego (nowy dzień operacyjny)
|
|
19.00 (5)–19.30 (4)
|
Dostarczenie płynności na rachunek w PM
|
|
19.30 (5)
|
Komunikat o rozpoczęciu procedury i rozliczenie zleceń stałych w celu przekazania płynności z rachunków w PM na subkonta/konta lustrzane (rozrachunek związany z systemami zewnętrznymi)
|
|
19.30 (5)–22.00
|
Realizacja dodatkowych transferów płynności za pośrednictwem ICM zanim system zewnętrzny przekaże komunikat o rozpoczęciu cyklu; okres rozrachunku nocnych operacji systemów zewnętrznych (tylko dla procedury rozrachunkowej 6 dla systemów zewnętrznych)
|
|
22.00–1.00
|
Faza obsługi technicznej
|
|
1.00–6.45
|
Procedura rozrachunku nocnych operacji systemów zewnętrznych (tylko dla procedury rozrachunkowej 6 dla systemów zewnętrznych)
|
|
|
4.
|
Przekazywanie płynności za pośrednictwem ICM jest możliwe od godz. 19.30 (6) do godz. 18.00 dnia następnego, za wyjątkiem fazy obsługi technicznej od godz. 22.00 do godz. 1.00.
|
|
5.
|
Godziny operacyjne mogą zostać zmienione w razie podjęcia środków zapewnienia ciągłości działania na podstawie pkt 5 dodatku IV.
|
|
|
|
2.
|
W załączniku III do wytycznych EBC/2007/2 wprowadza się następujące zmiany:
Punkt 2 lit. e) otrzymuje brzmienie:
|
„e)
|
podmiotom innym niż te, o których mowa w lit. a) i b), które zarządzają systemami zewnętrznymi i działają w tym charakterze, o ile uzgodnienia w sprawie udzielania takim podmiotom kredytu w ciągu dnia zostały uprzednio przedstawione Radzie Prezesów i zostały przez nią zatwierdzone.”.
|
|
|
3.
|
W załączniku IV do wytycznych EBC/2007/2 wprowadza się następujące zmiany:
|
1)
|
punkt 11 ust. 5 otrzymuje brzmienie
|
„5)
|
Banki rozrachunkowe i systemy zewnętrzne mają dostęp do informacji za pośrednictwem ICM. Systemy zewnętrzne są powiadamiane o dokonaniu rozrachunku albo jego niedojściu do skutku w oparciu o wybraną opcję – zawiadomienie pojedyncze lub globalne. Banki rozrachunkowe są powiadamiane o skutecznym dokonaniu rozrachunku za pomocą komunikatu SWIFT MT 900 albo MT 910 w razie zgłoszenia przez nie takiego żądania.”;
|
|
|
2)
|
punkt 14 ust. 7 lit. c) otrzymuje brzmienie:
|
„c)
|
zlecenia SWIFT przechodzące przez komunikat MT 202, które mogą być składane wyłącznie w czasie trwania procedury rozrachunkowej 6 i tylko podczas przetwarzania dziennego. Takie zlecenia podlegają natychmiastowemu rozrachunkowi.”;
|
|
|
3)
|
punkt 14 ust. 9 otrzymuje brzmienie:
|
„9)
|
W procedurze rozrachunkowej 6 płynność dedykowana na subkontach podlega zamrożeniu na czas trwania cyklu przetwarzania systemu zewnętrznego (rozpoczynającego się komunikatem o rozpoczęciu cyklu i kończącego się komunikatem o zakończeniu cyklu, przy czym oba komunikaty są wysyłane przez system zewnętrzny) i uwolnieniu po zakończeniu cyklu. Saldo podlegające zamrożeniu może się zmienić w czasie trwania cyklu przetwarzania w wyniku płatności rozrachunku międzysystemowego lub jeżeli bank rozrachunkowy przekazuje płynność ze swojego rachunku w PM. Bank centralny systemu zewnętrznego zgłasza systemowi zewnętrznemu zmniejszenie lub zwiększenie płynności na subkoncie powstałe na skutek płatności rozrachunku międzysystemowego. Na żądanie systemu zewnętrznego bank centralny systemu zewnętrznego zgłasza systemowi zewnętrznemu także zwiększenie płynności na subkoncie powstałe w wyniku transferu płynności przez bank rozrachunkowy.”;
|
|
|
4)
|
punkt 14 ust. 12 otrzymuje brzmienie
|
„12)
|
Rozrachunek międzysystemowy pomiędzy dwoma systemami zewnętrznymi stosującymi model interfejsowy może zostać zainicjowany wyłącznie przez system zewnętrzny (lub w jego imieniu przez odpowiedni bank centralny systemu zewnętrznego), którego uczestnika subkonto podlega obciążeniu. Rozrachunek instrukcji płatniczej polega na obciążeniu subkonta uczestnika systemu zewnętrznego inicjującego instrukcję płatniczą kwotą wskazaną w instrukcji płatniczej oraz uznaniu subkonta uczestnika innego systemu zewnętrznego.
System zewnętrzny inicjujący instrukcję płatniczą oraz drugi wspomniany system zewnętrzny powiadamia się o zakończeniu rozrachunku. Banki rozrachunkowe powiadamia się o skutecznym dokonaniu rozrachunku za pomocą komunikatu SWIFT MT 900 albo MT 910 w razie zgłoszenia przez nie takiego żądania.”;
|
|
|
5)
|
punkt 14 ust. 13 otrzymuje brzmienie:
|
„13)
|
Rozrachunek międzysystemowy z systemu zewnętrznego stosującego model interfejsowy do systemu zewnętrznego stosującego model zintegrowany może zostać zainicjowany przez system zewnętrzny stosujący model interfejsowy (lub w jego imieniu przez odpowiedni bank centralny systemu zewnętrznego). Rozrachunek instrukcji płatniczej polega na obciążeniu subkonta uczestnika systemu zewnętrznego stosującego model interfejsowy kwotą wskazaną w instrukcji płatniczej oraz uznaniu konta lustrzanego systemu zewnętrznego stosującego model zintegrowany. Instrukcja płatnicza nie może zostać zainicjowana przez system zewnętrzny stosujący model zintegrowany, którego konto lustrzane ma zostać uznane.
System zewnętrzny inicjujący instrukcję płatniczą oraz drugi wspomniany system zewnętrzny powiadamia się o zakończeniu rozrachunku. Banki rozrachunkowe powiadamia się o skutecznym dokonaniu rozrachunku za pomocą komunikatu SWIFT MT 900 albo MT 910 w razie zgłoszenia przez nie takiego żądania.”;
|
|
|
6)
|
punkt 14 ust. 17 otrzymuje brzmienie:
|
„17)
|
Rozrachunek międzysystemowy pomiędzy dwoma systemami zewnętrznymi stosującymi model zintegrowany może zostać zainicjowany wyłącznie przez system zewnętrzny (lub w jego imieniu przez odpowiedni bank centralny systemu zewnętrznego), którego konto lustrzane podlega obciążeniu. Rozrachunek instrukcji płatniczej polega na obciążeniu konta lustrzanego systemu zewnętrznego inicjującego instrukcję płatniczą kwotą wskazaną w instrukcji płatniczej oraz uznaniu konta lustrzanego innego systemu zewnętrznego. Instrukcja płatnicza nie może zostać zainicjowana przez system zewnętrzny, którego konto lustrzane ma zostać uznane.
System zewnętrzny inicjujący instrukcję płatniczą oraz drugi wspomniany system zewnętrzny powiadamia się o zakończeniu rozrachunku. Banki rozrachunkowe powiadamia się o skutecznym dokonaniu rozrachunku za pomocą komunikatu SWIFT MT 900 albo MT 910 w razie zgłoszenia przez nie takiego żądania.”;
|
|
|
7)
|
punkt 14 ust. 18 otrzymuje brzmienie:
|
„18)
|
Rozrachunek międzysystemowy z systemu zewnętrznego stosującego model zintegrowany do systemu zewnętrznego stosującego model interfejsowy może zostać zainicjowany przez system zewnętrzny stosujący model zintegrowany (lub w jego imieniu przez odpowiedni bank centralny systemu zewnętrznego). Rozrachunek instrukcji płatniczej polega na obciążeniu konta lustrzanego systemu zewnętrznego stosującego model zintegrowany kwotą wskazaną w instrukcji płatniczej oraz uznaniu subkonta uczestnika innego systemu zewnętrznego. Instrukcja płatnicza nie może zostać zainicjowana przez system zewnętrzny stosujący model interfejsowy, którego uczestnika subkonto ma zostać uznane.
System zewnętrzny inicjujący instrukcję płatniczą oraz drugi wspomniany system zewnętrzny powiadamia się o zakończeniu rozrachunku. Banki rozrachunkowe powiadamia się o skutecznym dokonaniu rozrachunku za pomocą komunikatu SWIFT MT 900 albo MT 910 w razie zgłoszenie przez nie takiego żądania.”;
|
|
|
8)
|
punkt 15 ust. 3 otrzymuje brzmienie:
|
„3)
|
Czas rozrachunku (»do«) umożliwia przeznaczenie ograniczonego czasu na rozrachunek w systemie zewnętrznym dla uniknięcia zablokowania lub opóźnienia rozrachunku innych transakcji związanych z systemem zewnętrznym albo transakcji w TARGET2. Jeżeli instrukcja płatnicza nie zostanie rozliczona do osiągnięcia chwili »do« lub w ciągu zdefiniowanego okresu rozliczeniowego, instrukcja ta podlega zwrotowi albo, w procedurach rozrachunkowych 4 i 5, może zostać uruchomiony mechanizm funduszu gwarancyjnego. Czas rozrachunku (»do«) można określić dla procedur rozrachunkowych 1–5.”
|
|
|
(1) Obecna polityka Eurosystemu w zakresie miejsca położenia infrastruktury określona jest w następujących komunikatach, dostępnych na stronie internetowej EBC pod adresem www.ecb.europa.eu: a) »Policy statement on euro payment and settlement systems located outside the euro area« z dnia 3 listopada 1998 r.; b) »The Eurosystem’s policy line with regard to consolidation in central counterparty clearing« z dnia 27 września 2001 r.; c) »The Eurosystem policy principles on the location and operation of infrastructures settling in euro-denominated payment transactions« z dnia 19 lipca 2007 r.; oraz d) »The Eurosystem policy principles on the location and operation of infrastructures settling euro-denominated payment transactions: specification of ‘legally and operationally located in the euro area’« z dnia 20 listopada 2008 r.”;
(2) CET uwzględnia zmianę na czas letni środkowoeuropejski (Central European Summer Time).”;
(3) Operacje dzienne oznaczają przetwarzanie dzienne i przetwarzanie na koniec dnia.
(4) Kończy się 15 minut później w ostatnim dniu okresu rezerwy minimalnej Eurosystemu.
(5) Rozpoczyna się 15 minut później w ostatnim dniu okresu rezerwy minimalnej Eurosystemu.
(6) Rozpoczyna się 15 minut później w ostatnim dniu okresu rezerwy minimalnej Eurosystemu.”.
Już nie obowiązuje, Data zakończenia ważności: 31/12/2012; Uchylony przez 32012O0027