Zakres zmian dla uczestników wynikający z wymogów wdrażanego przez GPW systemu UTP

Transkrypt

1 Załącznik Zakres zmian dla uczestników wynikający z wymogów wdrażanego przez GPW systemu UTP Wersja 1.0 Warszawa, marzec 2011 r Spis treści Wstęp... 2 Brak walidacji w zleceniu maklerskim danych dotyczących uczestnika rozliczającego i identyfikatora konta podmiotowego... 2 Ograniczenie możliwości wskazywania identyfikatorów kont do 10 znaków w zleceniu maklerskim... 4 Blokada członka giełdy na podstawie dyspozycji uczestnika rozliczającego Data rozrachunku w instrukcjach rozliczeniowych Wartość transakcji, ceny transakcyjne Występowanie w instrukcjach rozliczeniowych z systemu UTP tzw. pseudokodów ISIN i AMR do oznaczania instrumentów finansowych Miejsce i tryb obrotu w instrukcjach rozliczeniowych z systemu UTP Identyfikatory transakcji i zleceń Komunikaty z obszaru Clearing w systemie kdpw_stream Anulowanie transakcji Sposób wdrożenia

2 Wstęp Dokument zawiera opis zmian wprowadzanych przez system UTP, które mają bezpośredni wpływ na system kdpw_stream, a co za tym idzie na systemy uczestników KDPW. Materiał uwzględnia również wcześniejsze wydzielenie działalności rozliczeniowej do KDPW_CCP. Dokument zawiera specyfikację zmian wymaganych do wprowadzenia przez uczestników KDPW w celu poprawnej współpracy z systemem kdpw_stream po wdrożeniu przez GPW systemu UTP. W celach informacyjnych w dokumencie zawarto również opis zmian wymuszonych wdrożeniem systemu UTP, które dotyczą sposobu obsługi procesów biznesowych przez kdpw_stream, ale które nie niosą wymogów zmian w systemach uczestników. Brak walidacji w zleceniu maklerskim danych dotyczących uczestnika rozliczającego i identyfikatora konta podmiotowego Uczestnicy domyślni i domyślne konta rozliczeniowe W związku z tym, że na poziomie systemu UTP nie będzie walidacji zleceń w zakresie danych o uczestniku rozliczającym i identyfikatorze konta podmiotowego, Krajowy Depozyt wprowadzi z dniem wdrożenia UTP na rynkach kasowym i terminowym obowiązek wskazywania domyślnego uczestnika rozliczającego i zestawu domyślnych kont rozliczeniowych dla każdego uczestnika rozliczającego. Standardowo konta rozliczeniowe dzielą się na 3 zasadnicze typy: Proprietary, Agency, Market Maker (czasem można napotkać w różnych materiałach nieco inne nazewnictwo; w dokumentacji UTP funkcjonuje tzw. typ konta: House, Client, Liquidity Provider). W systemie kdpw_stream podobny podział opiera się na atrybutach: Typ własności (wartości: 0-Nie dotyczy, 1-Własne, 2-Klient, 3-Rachunek pw.) oraz Typ uczestnictwa (wartości: 01-Działalność podstawowa, 02-Animator, 03-Sponsor emisji, 06-Pośrednik techniczny). Określa się następujące definicje: Jeżeli typ uczestnictwa dla konta ma wartość 02-Animator, to konto rozliczeniowe jest traktowane jako Market Maker, niezależnie od typu własności. W przeciwnym przypadku, jeżeli typ własności ma wartość 2-Klient, to konto rozliczeniowe jest traktowane jako Agency. W każdym innym przypadku konto rozliczeniowe traktowane jest jako Proprietary. 2

3 W systemie kdpw_stream dla rynku kasowego zostaną zdefiniowane 3 odrębne domyślne konta rozliczeniowe odpowiednio dla działalności w rodzaju: Agency, Proprietary i Market Maker. Dla rynku derywatów będzie to 6 kont ze względu na przyjęte założenie tworzenia odrębnych kont domyślnych dla pozycji długich i krótkich. Obecnie zdefiniowane konta domyślne w systemie kdpw_stream będą pełnić rolę: - domyślnych kont rozliczeniowych dla instrukcji pochodzących z rynków nie przekazujących w instrukcjach wyżej wymienionych typów konta (BondSpot). - domyślnych kont rozrachunkowych, wykorzystywanych przy obsłudze instrukcji przez CSD. Wzory dokumentów zgłoszeniowych dotyczących kont domyślnych zostaną odpowiednio zmienione. Obsługa transakcji zawartych w systemie UTP W przypadku, gdy w instrukcji rozliczeniowej nie będzie wskazany uczestnik rozliczający lub będzie wskazany niepoprawny (wg baz referencyjnych kdpw_stream), to system kdpw_stream uzupełni właściwą stronę instrukcji kodem domyślnego uczestnika rozliczającego w danym segmencie rynku (rynek kasowy, rynek terminowy). W przypadku, gdy w instrukcji rozliczeniowej nie będzie wskazany identyfikator konta podmiotowego (konto rozliczeniowe) lub będzie wskazany niepoprawny (wg baz referencyjnych kdpw_stream), to system kdpw_stream uzupełni właściwą stronę instrukcji domyślnym kontem rozliczeniowym (wg typu konta z transakcji) przypisanym rozliczającemu w danym segmencie rynku. Na rynku terminowym sprzedaż będzie przypisana do domyślnego konta rozliczeniowego dla pozycji krótkich, a kupno do domyślnego konta rozliczeniowego dla pozycji długich. W sytuacji gdy intencją składającego zlecenie było rozliczenie transakcji u innego uczestnika rozliczającego lub na innym koncie podmiotowym, uczestnicy rozliczający (przekazujący i otrzymujący) powinni wykonać transfer na dzień rozrachunku transakcji poprzez wystawienie zgodnych instrukcji podlegających zestawieniu w systemie kdpw_stream wg regulacji i procedur ewidencyjnych obecnie funkcjonujących. 3

4 Konto ewidencyjne Konto podmiotowe Konto formalne Ograniczenie możliwości wskazywania identyfikatorów kont do 10 znaków w zleceniu maklerskim Przyjmuje się, że każde konto formalne w systemie kdpw_stream może pełnić jedną z następujących funkcji: Konto rozliczeniowe rozpoznawane na poziomie CCP; Konto rozrachunkowe rozpoznawane na poziomie CSD; Konto rozliczeniowo-rozrachunkowe łączące funkcje konta rozliczeniowego i rozrachunkowego. Każde konto podmiotowe otwarte w ramach danego konta formalnego będzie miało taką samą funkcję rozliczeniowo-rozrachunkową jak odpowiadające mu konto formalne. Po wprowadzeniu rozróżnienia kont ze względu na funkcję rozliczeniowo-rozrachunkową, pełna lista atrybutów kont formalnych, podmiotowych oraz ewidencyjnych przedstawia się w następujący sposób: Poziom konta Kod instytucji Typ własności Atrybut Typ uczestnictwa Identyfikator umowy reprezentacji Funkcja rozliczeniowo-rozrachunkowa konta Rodzaj konta Numer klasyfikacyjny klienta /klientów (NKK) Numer portfela ISIN Status aktywów 4

5 Przyjmuje się, że w zakresie w jakim uczestnik posiada status uczestnika rozliczającego prowadzone dla niego konta w systemie kdpw_stream mają charakter rozliczeniowo-rozrachunkowy. Pozostałe konta w systemie kdpw_stream mają charakter rozrachunkowy. Na podstawie złożonego przez podmiot aplikujący wniosku o rozpoczęcie określonej działalności KDPW będzie mógł określić funkcję rozliczeniowo-rozrachunkową nowo otwieranego konta formalnego. Komunikaty tworzenia kont podmiotowych (acmt.rqa ) oraz odpowiadające im komunikaty statusu (acmt.sta ), w których strukturach zawarte są atrybuty konta formalnego, zostaną rozbudowane o opcjonalne pole: Funkcja rozliczeniowo-rozrachunkowa konta. Brak wypełnienia tego pola w komunikacie acmt.rqa będzie oznaczać żądanie utworzenia konta rozliczeniowo-rozrachunkowego. Składający zlecenie maklerskie w systemie UTP napotka następujące ograniczenia przy wskazywaniu identyfikatora konta podmiotowego (konta rozliczeniowego lub rozliczeniowo-rozrachunkowego): - dla UTP dla rynku kasowego dostępne jest pole o formacie 12 A; - dla UTP dla rynku terminowego dostępne jest pole o formacie 14A, jednakże brak jest odrębnego pola do wskazywania uczestnika rozliczającego, co oznacza konieczność wprowadzania w tym polu zarówno uczestnika rozliczającego, jak i identyfikatora konta. Tak więc, mając na uwadze to, że stosowanie długich identyfikatorów kont jest obecną, powszechną praktyką przede wszystkim na rynku terminowym, pojawia się konieczność migracji kont rozliczeniowo-rozrachunkowych na identyfikatory kont nie dłuższe niż 10 znaków. Krajowy Depozyt proponuje uczestnikom dwie ścieżki przeprowadzenia w kdpw_stream migracji dla kont rozliczeniowo-rozrachunkowych o obecnej długości większej niż 10 znaków: 5

6 1. Migracja kont wg własnego planu W tym przypadku uczestnik powinien dostarczyć do KDPW tabelę przejścia pomiędzy dotychczasowymi identyfikatorami i nowymi. Tabela powinna być dostarczona w odpowiednim formacie (CSV) określonym przez KDPW. Opis tej tabeli zostanie przekazany w terminie późniejszym. 2. Migracja kont wg algorytmu KDPW Obecnie konta podmiotowe w systemie kdpw_stream mają identyfikatory o maksymalnej długości 16 znaków. W trakcie migracji z systemu DEP do systemu kdpw_stream identyfikatory kont na rynku instrumentów pochodnych zostały utworzone poprzez sklejenie atrybutów kont systemu DEP. Identyfikatory te miały długość 16 znaków o strukturze: ttrrkknnnnnnnnpp, gdzie: tt typ uczestnictwa w systemie DEP (2 znaki), RR rodzaj konta w systemie DEP (2 znaki), kk typ uczestnictwa rynku kasowego w systemie DEP (2 znaki), NNNNNNNN identyfikator klienta w systemie DEP (8 znaków), pp numer portfela w systemie DEP (2 znaki). Zdecydowana większość identyfikatorów kont w dalszym ciągu zachowała strukturę określoną podczas migracji do systemu kdpw_stream. Otwiera to drogę do algorytmicznej zmiany identyfikatorów wykorzystującej zaobserwowane w rzeczywistych danych nadmiarowości, w postaci powtarzających się znaków we wszystkich lub w dominującej większości obecnie stosowanych identyfikatorów. Proponowany algorytm migracji identyfikatorów 1. Pierwsze 8 znaków identyfikatora zostaje zastąpionych 2-znakowym oznaczeniem. 2-znakowe oznaczenia nadawane będą kolejno dla każdej 8-znakowej kombinacji, poczynając od wartości 01. Dla kilku najczęściej występujących kombinacji zastosowane będą specjalne oznaczenia odpowiadające wprost typowi uczestnictwa w systemie DEP. 6

7 2. Pozostałe 8 znaków identyfikatora konta pozostaje bez zmian. Poniżej przedstawiono tabelę zawierającą 2-znakowe kody, które zastąpią każdą z występujących obecnie w systemie 8-znakowych kombinacji stanowiących początek identyfikatora konta. Tabela konwersji 8 pierwszych znaków id konta w oznaczenie 2-znakowe Pierwsze 8 znaków Nowe dwuznakowe dotychczasowego konta oznaczenie typu konta (pierwsze 2 znaki konta 10-znakowego)

8 Konta krótsze niż 16 znaków i dłuższe niż 10 znaków _ _ Struktura identyfikatora konta po migracji będzie miała postać: ttnnnnnnpp, gdzie: tt nowy typ konta (2 znaki), NNNNNN identyfikator klienta w systemie DEP (6 ostatnich znaków), pp numer portfela w systemie DEP (2 znaki). Przykłady identyfikatorów kont przed i po migracji Identyfikator źródłowy Konwersja identyfikator wynikowy (10-znakowy)

9 Data migracji (wg wybranej przez uczestnika ścieżki migracji kont) może być ustalana indywidualnie dla każdego uczestnika, ale nie później niż miesiąc przed wdrożeniem UTP dla rynku kasowego (zakłada się, że wdrożenie UTP kasowy jest nie później niż UTP terminowy). W dniu migracji kont danego uczestnika, uczestnik ten powinien zwrócić się do Giełdy o usunięcie z karnetu zleceń po sesji giełdowej niezrealizowanych zleceń przechodzących na następny dzień. Na miesiąc przed wdrożeniem UTP dla rynku kasowego planowane jest dla kont rozliczeniowych i rozrachunkowo-rozliczeniowych wprowadzenie blokady otwierania kont dłuższych niż 10 znaków (format pola pozostaje 16A), natomiast dla kont rozrachunkowych blokada ta nie będzie obowiązywać. 9

10 Blokada członka giełdy na podstawie dyspozycji uczestnika rozliczającego System UTP uniemożliwia blokowanie członka giełdy dla wskazanego uczestnika rozliczającego lub wskazanego konta. Istnieje jedynie możliwość blokady członka giełdy. W związku z tym, że relacje członków giełdy z uczestnikami rozliczającymi nie są jednoznaczne tzn. zarówno członkowie giełdy mogą mieć relacje z więcej niż jednym uczestnikiem rozliczającym jak również uczestnicy rozliczający mogą mieć relacje z więcej niż jednym członkiem giełdy wprowadzone zostaną następujące zasady. 1. Zdalny Członek Giełdy może mieć umowę na rozliczanie zawartych transakcji z tylko jednym uczestnikiem rozliczającym, bez względu na to, czy działa na rynku kasowym czy terminowym. 2. Tzw. lokalny broker może mieć umowę na rozliczanie zawartych transakcji z wieloma uczestnikami rozliczającymi. Jednakże, jest zobowiązany do pełnienia roli tzw. domyślnego uczestnika rozliczającego dla transakcji zawieranych przez siebie lub powinien wskazać innego uczestnika rozliczającego, który wyraża zgodę na pełnienie funkcji uczestnika domyślnego. Mając na uwadze powyższe zasady stosowane będzie następujące rozwiązanie: 1. Jeśli dany członek giełdy według bazy danych KDPW ma tylko jednego uczestnika rozliczającego, to ten uczestnik rozliczający może zablokować tego członka giełdy KDPW przesyła od uczestnika rozliczającego blokadę na Giełdę. 2. Jeśli dany członek giełdy wg według bazy danych KDPW ma kilku uczestników rozliczających, to tylko domyślny uczestnik rozliczający może zablokować tego członka giełdy KDPW przesyła od uczestnika rozliczającego blokadę na Giełdę. 3. Jeśli dany członek giełdy wg według bazy danych KDPW ma kilku uczestników rozliczających, to uczestnicy, którzy nie są domyślnym uczestnikiem rozliczającym, mogą przesłać blokadę, ale którą przetworzy wyłącznie kdpw_stream (blokada nie jest wysyłana na Giełdę). Z chwilą przetworzenia komunikatu blokady w bazach danych kdpw_stream zostanie ustawiona pewna flaga, która od chwili jej ustawienia spowoduje, że w transakcjach przychodzących do kdpw_stream po tym czasie transakcje uczestnika rozliczającego, który zlecił blokadę członka giełdy, będą przypisywane uczestnikowi domyślnemu. Uczestnicy rozliczający powinni mieć na uwadze, że w zakresie przekazywania zleceń blokady nie będzie komunikacji on-line pomiędzy GPW i KDPW. KDPW w relacji z uczestnikami rozliczającymi utrzymuje dotychczasową formę przekazywania zlecenia 10

11 blokady (zmianie ulegnie zawartość merytoryczna i specyfikacja komunikatu). Natomiast w relacji KDPW GPW komunikaty będą przekazywane drogą ową, a samo zlecenie blokady będzie przetwarzane po stronie GPW w sposób ręczny przez operatora systemu. Powyższe może spowodować opóźnienia w procesie zarówno ustanawiania samej blokady członka giełdy jak również w procesie usuwania zleceń tego członka giełdy z karnetu zleceń. W specyfikacji komunikatów związanych z obsługą blokad zachodzą następujące zmiany. 1. komunikat blokady uczestnika (acmt.blr ) Usuwa się ze specyfikacji komunikatu pola: - typ blokady (BlckTp); istnieje możliwość wykonania tylko jednego rodzaju blokady członka giełdy; - kod uczestnika rozliczającego (ClrgMmbld); - Numer klasyfikacyjny klienta (ClntTp); - identyfikator konta podmiotowego (KDPWSafAcct). Brak możliwości systemowego zapytania o stan blokady. Stąd zbiór wartości stosowanych kodów w polu Funkcja komunikatu (FuncOfMsg) zostaje zawężona do dwóch kodów: NEWM (nowy komunikat blokady), CANC (odwołanie blokady). 2. Potwierdzenie obsługi komunikatu blokady (acmt.bls ) Usuwa się ze specyfikacji komunikatu pola: - typ blokady (BlckTp); - kod uczestnika rozliczającego (ClrgMmbld); - Numer klasyfikacyjny klienta (ClntTp); - identyfikator konta podmiotowego (KDPWSafAcct); - Stan blokady (BlckSts); brak możliwości systemowego zapytania o stan blokady. Zbiór wartości stosowanych kodów w polu Funkcja komunikatu (FuncOfMsg) zostaje zawężona do dwóch kodów: NEWM (nowy komunikat blokady), CANC (odwołanie blokady). W związku ze zmianami w zakresie obsługi blokad zawężono zbiór wartości kodów stanu przetworzenia otrzymanego komunikatu blokady (StsCd). Specyfikacja nowych wersji komunikatów acmt.blr i acmt.bls zamieszczono na stronach internetowych KDPW. 11

12 Data rozrachunku w instrukcjach rozliczeniowych Dla transakcji przekazywanych z Giełdy bez wskazanej daty rozrachunku system kdpw_stream automatycznie wyznaczy datę planowanego rozrachunku i uzupełni jej brak w instrukcji rozliczeniowej. Wyznaczenie daty będzie odbywać się w oparciu o stały cykl rozliczeniowy dla danego typu instrumentu (T+2 papiery dłużne, T+3 pozostałe papiery, T+0 derywaty) zgodnie z regulacjami KDPW. Dla transakcji z rynku kasowego (np. transakcji pakietowych), w których Giełda będzie wskazywać datę rozrachunku, ale nie będzie jej weryfikować, system kdpw_stream wykona następujące czynności: a) jeśli data jest datą bieżącą lub przyszłą zdefiniowaną w kalendarzu rozrachunku dla rynku kasowego dla danej waluty data z transakcji jest uznawana jako data planowanego rozrachunku; b) jeśli data jest datą bieżącą lub przyszłą niezdefiniowaną w kalendarzu rozrachunku dla rynku kasowego wyznaczana (i wpisana do instrukcji rozliczeniowej) jest data z kalendarza rozrachunku rynku kasowego dla danej waluty, która jest datą najbliższą, większą od pierwotnej daty z transakcji; c) jeśli data jest datą przeszłą wyznaczana (i wpisana do instrukcji rozliczeniowej) jest najbliższa data z kalendarza rozrachunku rynku kasowego dla danej waluty, na której możliwy jest rozrachunek transakcji. 12

13 Wartość transakcji, ceny transakcyjne System UTP w instrukcjach rozliczeniowych nie będzie wprost określał wartości transakcji i cen transakcyjnych. Niemniej jednak, dla uczestników rozliczających system kdpw_stream będzie wyliczał te wartości i uzupełniał ich brak w instrukcjach rozliczeniowych. Postępowanie to odnosi się też do transakcji w obligacjach, dla których kdpw_stream będzie wyznaczał wartość transakcji w oparciu o tabelę odsetkową otrzymywaną z Giełdy. 13

14 Występowanie w instrukcjach rozliczeniowych z systemu UTP tzw. pseudokodów ISIN i AMR do oznaczania instrumentów finansowych W instrukcjach rozliczeniowych przekazywanych z systemu UTP nie zawsze będzie wskazywany kod ISIN instrumentu finansowego. Na rynku kasowym instrumenty notowane na podstawowym segmencie rynku będą identyfikowane za pomocą kodu ISIN, natomiast dla każdej kolejnej linii notowań tego samego instrumentu (np. transakcje blokowe, IPO, wezwania) będzie stosowany tzw. pseudokod ISIN, w którym ostatni znak kodu ISIN instrumentu (12-ty znak) zostanie zastąpiony literą (wg normy ISO 6166 ostatni 12-znak jest cyfrą kontrolną kodu ISIN). Na rynku terminowym instrumenty będą identyfikowane za pomocą 15-znakowego identyfikatora AMR. W związku z powyższym system kdpw_stream odbierając instrukcje rozliczeniowe z systemu UTP dokona automatycznej konwersji pseudokodów ISIN i AMR na odpowiadające im kody ISIN i uzupełni ich brak w instrukcjach rozliczeniowych. W komunikatach CCP secl i secl (patrz załącznik Zasady wymiany komunikatów ISO20022 w systemie kdpw_stream; Obszar: Clearing) oprócz kodu ISIN będzie przekazywany, w przypadku wystąpienia w instrukcji rozliczeniowej z systemu UTP, pseudokod ISIN i AMR. W pozostałych komunikatach XML w kdpw_stream (obecnie funkcjonujących) nie będzie informacji o pseudokodach ISIN i AMR. 14

15 Miejsce i tryb obrotu w instrukcjach rozliczeniowych z systemu UTP Krajowy Depozyt utrzyma w instrukcjach rozliczeniowych dotychczasową klasyfikację wg kodu rynku i trybu obrotu (w komunikacie sese.sts tagi <KDPWPlcOfTrad> i <KDPWTradMode>) określając ich wartości w momencie przyjęcia instrukcji rozliczeniowych z systemu UTP. Giełda, która będzie wyróżniać rynki za pomocą kodu MIC (kod rynku w standardzie ISO 10383), ma obecnie do dyspozycji dwa kody: - XWAR - Rynek Giełdowy; - XNCO - NewConnect. Ze względu na to, że dotychczas operacyjnie dla transakcji z Giełdy stosowane są trzy oznaczenia wyróżniające rynki: - XG rynek regulowany giełdowy; - XA alternatywny system obrotu organizowany przez Giełdę Papierów Wartościowych w Warszawie S.A.; - XX - transakcje zawierane na podstawie zlecenia złożonego w ramach subskrypcji papierów wartościowych realizowanej przy wykorzystaniu systemu informatycznego Giełdy Papierów Wartościowych w Warszawie S.A; przyjmuje się następujące rozwiązania: - kod rynku XG jest odpowiednikiem kodu MIC XWAR; - kod rynku XA jest odpowiednikiem kodu MIC XNCO; - kod rynku XX zostanie usunięty; Giełda dla tych transakcji będzie stosować kod MIC XWAR lub XNCO w zależności od tego na jakim rynku docelowo będzie w obrocie dany instrument finansowy. 15

16 Ponadto, system kdpw_stream będzie przekazywał dodatkowo informację o kodzie MIC (na podstawie informacji od danego organizatora rynku) w tagu <PlcOfTrad> w komunikacie sese.sts Nie wymaga to zmiany ani specyfikacji, ani XMLSchema tego komunikatu. 16

17 Identyfikatory transakcji i zleceń System UTP wprowadza różnego rodzaju identyfikatory w odniesieniu do ich przeznaczenia, nazewnictwa i formatów w zależności od stosowanego przez brokera protokołu komunikacyjnego (protokół FIX, Binary), rynku (kasowy i terminowy) i notowania (podstawowa linia notowania i kolejne linie notowania). Krajowy Depozyt otrzymał zapewnienie od Giełdy, że w przypadku identyfikatora określającego numer transakcji identyfikator ten przyjmuje wartości numeryczne od 1 do Numeracja ta utrzymywana jest w ramach dnia sesyjnego, czyli będzie rozpoczynać się od 1 w każdym kolejnym dniu, co oznacza praktyczne dopasowanie do pola MktRef o formacie 16 A w komunikatach sese.ins , sese.sts i sese.sts Mając na względzie: odmienność i różnorodność ww. identyfikatorów w stosunku do obecnie stosowanych jednolitych zasad i formatu referencji (pola 16 A zgodne z iso15022); docelowe rozwiązanie, zgodnie z którym CCP na podstawie instrukcji rozliczeniowych z rynku przesyła instrukcje do rozrachunku, zatem to on jest ich wystawcą; możliwość nettowania instrukcji do rozrachunku (jako opcja), wprowadza się następujące zmiany. W komunikacie sese.sts dotyczącym statusu instrukcji z rynku skierowanej do rozrachunku w polu MktRef umieszczany będzie numer transakcji. Specyfikacja ww. komunikatu, w tym jego pola MktRef (format 16 A) nie ulega zmianie. Ponadto, w polu AddtInf (komentarz) tego komunikatu zostaną umieszczone oryginalne wartości identyfikatorów z instrukcji rozliczeniowych z systemu UTP, dla których występuje niedopasowanie formatów. Wypełnienie informacji w komentarzu komunikatu sese.sts zapisywane będzie w notacji wartości przypisanych odpowiednim wartościom tagów. Tag wskazuje na znaczenie merytoryczne wielkości podanej po znaku = (CM=12345 oznacza, że dla tagu CM przypisana jest wartość alfanumeryczna 12345). Poszczególne tagi oddzielone są znakiem 17

18 pionowej kreski ( ) znak ten nie ogranicza dziedziny znaków przewidzianych dla pól alfanumerycznych w UTP ( 0 9 a...z A...Z # $ & ( ) + -., / : ; < = [ ] ^ _ ` ~ { } ). Ostatni element w ciągu także powinien zostać zakończony separatorem. W poniższej tabeli zebrane zostały wszystkie możliwe dane merytoryczne, dla których występuje niedopasowanie formatów. Pole Długość pola Tag Uczestnik rozliczający 4A CM Id zlecenia nadawany przez zawierającego 30A BO Rynkowy numer zlecenia 24A MO Maksymalna długość wypełnienia pole komentarz dla takiej notacji to 70 znaków, przy czym w kdpw_stream w polu komentarz można wpisać do 140 znaków. Należy mieć na uwadze, że w przypadku stosowania nettingu instrukcji rozliczeniowych (jako opcja) dla danego uczestnika, pola MktRef i AddInf instrukcji skierowanej do rozrachunku nie będą wypełniane. W komunikacie sese.sts (status instrukcji rozliczeniowej, który obecnie w trybie on-line powiadamia zainteresowanych uczestników rozliczających o transakcjach z rynku) zostanie przyjęte analogiczne rozwiązanie jak dla komunikatu sese.sts (numer transakcji w polu MktRef, pozostałe identyfikatory w AddtInf). 18

19 Komunikaty z obszaru Clearing w systemie kdpw_stream Spośród obecnie stosowanych komunikatów systemu kdpw_stream do obszaru Clearingu można zaliczyć komunikaty sese.sts , semt.ssf , camt.smt Nie przewiduje się żadnych zmian w specyfikacji tych komunikatów w związku z wdrożeniem systemu UTP (poza wprowadzeniem wypełniania pola AddtInf w komunikacie sese.sts ). Zainteresowani uczestnicy rozliczający będą mogli w dalszym ciągu otrzymywać ww. komunikaty. Jednocześnie rekomendujemy wykorzystanie nowej rodziny komunikatów (komunikaty secl.xxx.xxx.xx) zaprojektowanych specjalnie do obsługi procesów Clearingu zgodnych z ISO20022, które wprowadzimy z chwilą wdrożenia systemu UTP. Informacje o nowych komunikatach przedstawiono w odrębnym załączniku: Zasady wymiany komunikatów ISO20022 w systemie kdpw_stream; Obszar: Clearing. W związku z rozdzieleniem procesów rozliczeń i rozrachunku w obsłudze systemu ESDK, funkcjonującego w ramach SWI ( System Wymiany Informacji), w kdpw_stream wprowadza się dodatkową kontrolę odbiorcy komunikatu przekazywanego przez uczestników. Kontrola będzie dotyczyć zawartości kodu uczestnika w polu ID Adresata. Pole to, zgodnie ze specyfikacją zawiera informacje zapisaną zgodnie z następującym formatem: ID Nadawcy: identyfikator nadawcy, w formacie SDK.TTTTNN, gdzie: TTTT - kod uczestnika, NN - numer kolejny identyfikatora dla danego uczestnika. Wprowadzona kontrola kontrolować będzie zawartość elementu TTTT pod kątem jego zgodności ze zbiorem dopuszczalnych wartości ( 0001 oraz 0010 ). Brak zgodności będzie powodował zgłoszenie błędu o kodzie ERRCTL0005 Nieprawidlowy ID Adresata". Kod ten podlegać będzie również weryfikacji pod kątem zgodności z odbiorcą komunikatu wskazanym w treści komunikatu XML przekazywanego do kdpw_stream (atrybut Sndr głównego elementu dokumentu tag KDPWDocument). W przypadku wykrycia niezgodności do wystawcy komunikatu skierowany zostanie komunikat admi.err z kodem błędu X005 Niepoprawny kod odbiorcy komunikatu przekazany w nagłówku pliku. 19

20 W związku z potencjalnym dodatkowym strumieniem danych dotyczących statusów instrukcji rozliczeniowych (sese.sts lub secl ) przekazywanych on-line zainteresowanym uczestnikom rozliczającym (ze względu m.in. na ewentualną potrzebę śledzenia procesu anulacji transakcji, uzupełniania instrukcji rozliczeniowych o kody domyślnych uczestników rozliczających, domyślnych identyfikatorów kont, dat planowanego rozrachunku, wartości i cen transakcyjnych oraz kodów ISIN), KDPW zaleca uczestnikom weryfikację parametrów połączeń komunikacyjnych z KDPW pod kątem ich bieżącej utylizacji i rozważenie możliwości zwiększenia pasma gwarantowanego tak aby zminimalizować ewentualne opóźnienia w procesie przetwarzania statusów instrukcji rozliczeniowych. 20

21 Anulowanie transakcji Giełda umożliwia w systemie UTP stronom zawartej transakcji jej anulowanie w dniu zawarcia transakcji. Krajowy Depozyt przyjmuje następujące zasady unieważnienia transakcji na podstawie otrzymanej anulacji z Giełdy. I Rynek kasowy Instrukcje rozliczeniowe z systemu UTP mogą być anulowane po stronie KDPW do momentu przekazania ich w kdpw_stream do rozrachunku. Transakcje z datą rozrachunku różną od dnia zawarcia transakcji przekazywane są do rozrachunku po zakończeniu bieżącej sesji na rynku. Transakcje z datą rozrachunku równą dacie bieżącej przekazywane są do rozrachunku niezwłocznie po ich wpłynięciu do kdpw_stream. Innymi słowy, w dniu zawarcia transakcji mogą być anulowane wszystkie transakcje poza tymi T+0. Jednocześnie transakcje przeznaczone do rozrachunku w T+n (n>0) będą mogły być usuwane jedynie w dniu ich przekazania przez GPW do CCP. II Rynek terminowy Instrukcje rozliczeniowe z systemu UTP mogą być anulowane po stronie KDPW do momentu rozpoczęcia sesji rozliczeniowej IRO. Informacja o anulacji danej transakcji zostanie przekazana do uczestnika rozliczającego za pomocą komunikatu sese.sts (status PENF kod przyczyny IC01) i secl

22 Sposób wdrożenia Zakłada się, że wdrożenie UTP kasowy nastąpi nie później niż UTP terminowy. W tej sytuacji w następującej kolejności planowane są przedsięwzięcia: 1. wprowadzenie nowego systemu kont domyślnych z dniem wdrożenia UTP kasowy (patrz rozdział: Brak walidacji w zleceniu maklerskim danych dotyczących uczestnika rozliczającego i identyfikatora konta podmiotowego); 2. wykonanie migracji kont i zablokowanie możliwości otwierania kont dłuższych niż 10 znaków nie później niż na miesiąc przed dniem wdrożenia UTP kasowy (patrz rozdział: Ograniczenie możliwości wskazywania identyfikatorów kont do 10 znaków w zleceniu maklerskim); 3. zmiana funkcjonalności obsługi blokad w odniesieniu do rynku kasowego z dniem wdrożenia UTP kasowy; zmiana funkcjonalności w odniesieniu do rynku terminowego z dniem wdrożenia UTP terminowy (patrz rozdział: Blokada członka giełdy na podstawie dyspozycji uczestnika rozliczającego); 4. wprowadzenie nowych komunikatów z rodziny secl.xxx.xxx.xx i możliwości anulowania transakcji w obszarze rynku kasowego i terminowego odpowiednio z dniem wdrożenia UTP kasowy i terminowy; 5. wprowadzenie dodatkowej kontroli odbiorcy komunikatu z dniem wdrożenia UTP kasowy (patrz: Komunikaty z obszaru Clearing w systemie kdpw_stream). 22