WALIDACJE LEVEL 2. Zmiany w kontroli komunikatów, procesie rekoncyliacji oraz zmiany związane z obsługą raportów. (Materiał dla uczestników)

WALIDACJE LEVEL 2 Zmiany w kontroli komunikatów, procesie rekoncyliacji oraz zmiany związane z obsługą raportów (Materiał dla uczestników) 1

Spis treści Zmiany w kontroli komunikatów, procesie rekoncyliacji oraz zmiany związane z obsługą raportów... 1 1. Zmiany ogólne... 3 1.1. Unikalność UTI pomiędzy stronami... 3 1.2. Wprowadzenie nowej funkcji komunikatu czyszczenie danych... 3 1.3. Informacja o statusie rekordu... 3 1.4. Zastąpienie daty EligibilityDate datami Eligibility Date From i Eligibility Date To.... 4 2. Zmiany w obsłudze AT=E... 10 3. Aktualizacja/zmiana danych (zamiast AT=E do mutacji)... 10 4. Umożliwienie kontrahentowi wskazania błędu w danych zgłoszonych w jego imieniu raportowanie delegowane (zastąpienie AT=E (PUR) przez AT=O (PUR))... 10 5. Zmiany związane z AT=C oraz nowy techniczny AT=T... 11 6. Usunięcie wartości raportowanych zbiorczo... 13 7. Zmiany związane z referencjami... 14 8. Wymagalność pól dla poszczególnych AT... 14 8.1. AT=N... 14 8.2. AT=M... 14 8.3. AT=C... 15 8.4. AT=Z... 15 8.5. AT=E... 15 8.6. AT=V... 15 9. Możliwość zmiany identyfikatorów stron transakcji CP1 i CP2.... 15 10. Nowe kontrole merytoryczne... 15 11. Zmiany w procesie rekoncyliacji... 20 12. Załączniki... 21 2

1. Zmiany ogólne 1.1. Unikalność UTI pomiędzy stronami Użycie tego samego UTI (TradId) pomiędzy tymi samymi stronami transakcji możliwe jest tylko raz. Próba ponownego użycia tego samego TradId pomiędzy tymi samymi stronami transakcji, będzie skutkować odrzuceniem komunikatu, nawet, jeśli poprzedni raport został całkowicie anulowany (tzn. przesłano AT=E anulujące całą transakcję). 1.2. Wprowadzenie nowej funkcji komunikatu czyszczenie danych Wprowadzona zostanie nowa funkcjonalność komunikatu, dzięki której można będzie raportować puste wartości w polach nieobowiązkowych oraz anulować wartości uprzednio w danym polu zaraportowane atrybut delete= Y dla tagu. Czyszczenie danych będzie dotyczyło tylko wartości, które nie są obowiązkowe (szczegółowy spis pól dopuszczalnych do czyszczenia w dokumencie Wypełnianie komunikatów ). Uczestnik wskazuje w komunikacie AT=M pola, które mają ulec czyszczeniu poprzez nadanie tagowi atrybutu delete= Y. Przykład: <Undrlyg delete= Y /> W efekcie, w polu Underlying pojawi się wartość pusta. Podanie takiego atrybutu dla pól, których czyszczenie nie jest możliwe skutkować będzie odrzuceniem komunikatu. Funkcja czyszczenia udostępniona zostanie dla komunikatu trar.ins.001.01 (AT=M) oraz komunikatów trar.ins.002.01, trar.ins.003.01, przy czym działanie tej funkcji dla komunikatów raportowania zbiorczego opisane jest w dalszej części materiału (pkt.6). 1.3. Informacja o statusie rekordu Każdy rekord transakcyjny (mutacja) w bazie RT posiada swój status, który może przyjąć jedną a wartości: A Aktywny (obejmuje wszystkie rekordy nieusunięte i niesterminowane) N Nieaktywny (obejmuje rekordy sterminowane) E usunięty (obejmuje rekordy usunięte). 3

W związku z dopuszczeniem możliwości częściowej terminacji oraz wprowadzeniem automatycznego wygaszania transakcji, informacja o statusie rekordu będzie udostępniania uczestnikom. W interfejsie pozostaje podział na zakładki Report Searching i Archive, przy czym pierwsza zakładka, prezentować będzie rekordy aktywne (o statusach A ), a zakładka druga nieaktywne (o statusach N ). Dodatkowo, powołana zostanie nowa zakładka Deleted reports, która prezentować będzie rekordy anulowane (o statusach E ). Zakres danych prezentowanych w zakładce ograniczony będzie do pól: TradId, Cp1, Cp2, ErrorDtTm. W komunikatach trar.rqs.001.01, trar.sts.001.01 i trar.ntf.001.01 dodane zostanie pole Status rekordu. Komunikat trar.rqs.001.01 zyskuje nową funkcjonalność odpytywanie wg statusu rekordu. 1.4. Zastąpienie daty EligibilityDate datami Eligibility Date From i Eligibility Date To. Możliwe będzie nadpisanie części historii transakcji w wybranym zakresie dat. W związku z tym przebudowie ulega data obowiązywania, która obecnie składać się będzie z zakresu dat: Eligibility Date From i Eligibility Date To. Ogólne zasady działania: 1) Data Eligibility Date From będzie wymagana w każdym komunikacie. 2) Jeśli data Eligibility Date To jest wypełniona to historia transakcji zostanie nadpisana w podanym zakresie od Eligibility Date From do Eligibility Date To, tzn. dotychczasowe wpisy z tego zakresu przestaną być obowiązujące i widoczne, a w ich miejsce powstaną nowe (zaktualizowane) wpisy. Nadpisanie części historii możliwe jest tylko za pomocą AT=M, V lub Z. Data Eligibility Date To dla pozostałych AT jest ignorowana. 3) Jeśli data Eligibility Date To nie jest wypełniona a data Eligibility Date From jest większa od daty obowiązywania ostatniej mutacji to tworzony jest kolejny wpis obowiązujący od daty Eligibility Date From. 4) Jeśli data Eligibility Date To nie jest wypełniona a data Eligibility Date From jest mniejsza lub równa od daty obowiązywania ostatniej mutacji to tworzony jest wpis obowiązujący od daty Eligibility Date From, a dotychczasowa historia od daty Eligibility Date From przestanie być obowiązująca i widoczna. PRZYKŁADY: Przykład 1 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce modyfikacja transakcji (AT=M) z podaniem daty Eligibility Date From = D3 oraz pustą datą Eligibility Date To. 4

Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; od daty D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=M. Status raportu = A aktywny D1 D3 AT=N AT=M (EligDt From = D3) Przykład 2 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce modyfikacja transakcji (AT=M) z podaniem daty Eligibility Date From = D3 oraz daty Eligibility Date To = D5. Od daty D3 do daty D5 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=M, od daty D6 ponownie obowiązują dane przekazane raportem AT=N. Status raportu = A aktywny D1 D3 D5 AT=N AT=M (EligDt From = D3 EligDt To = D5) Przykład 3 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D6 miała miejsce częściowa terminacja transakcji (AT=C) z podaniem daty Eligibility Date From = D6. Od daty D1 do daty D5 obowiązują dane przekazane raportem AT=N; od daty D6 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=C. Status raportu = A aktywny D1 D6 AT=N AT=C (EligDt From = D6) 5

Przykład 4 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce aktualizacja wyceny transakcji (AT=Vw) z podaniem daty Eligibility Date From = D3 i pustą datą Eligibility Date To, w dacie D7 miała miejsce aktualizacja zabezpieczenia transakcji (AT=Vz) z podaniem daty Eligibility Date From = D7 i pustą datą Eligibility Date To, w dacie D8 miała miejsce modyfikacja transakcji (AT=M) z podaniem daty Eligibility Date From = D8 i pustą datą Eligibility Date To. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; od daty D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=Vw; od daty D7 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=Vw oraz zabezpieczenia przekazanego raportem AT=Vz; od daty D8 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=Vw, zabezpieczenia przekazanego raportem AT=Vz oraz modyfikacji przekazanej raportem AT=M. Status raportu = A aktywny D1 D3 D7 D8 AT=N AT=Vw (EligDt From = D3) AT=Vz (EligDt From = D7) AT=M (EligDt From = D8) Przykład 5 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce aktualizacja wyceny transakcji (AT=V1) z podaniem daty Eligibility Date From = D3 oraz daty Eligibility Date To = D5, w dacie D4 transakcja została zmodyfikowana (AT=M), następnie w dniu D10 zaktualizowana została wycena transakcji (AT=V2) z podaniem daty Eligibility Date From = D10 i pustą datą Eligibility Date To. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; w dacie D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=V1; od daty D4 do daty D5 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=V1 oraz modyfikacji przekazanej raportem AT=M; od daty D6 do daty D9 obowiązują dane przekazane raportem AT=N z uwzględnieniem modyfikacji przekazanej raportem AT=M (nie obowiązuje już wycena V1); od daty D10 obowiązują dane przekazane raportem AT=N z uwzględnieniem modyfikacji przekazanej raportem AT=M oraz wyceny przekazanej raportem AT=V2. Status raportu = A aktywny 6

D1 D3 D4 D5 D10 AT=N AT=V1 (EligDt From = D3 EligDt To = D5) AT=M (EligDt From = D4) AT=V2 (EligDt From = D10) Przykład 6 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D12 miała miejsce całkowita terminacja transakcji (AT=C) z podaniem daty Eligibility Date From = D12. Od daty D1 do daty D11 obowiązują dane przekazane raportem AT=N; od daty D12 obowiązują dane przekazane raportem AT=N z uwzględnieniem terminacji przekazanej raportem AT=C. Status raportu: w dniach D1-D11 A (aktywny) od dnia D12 - N( nieaktywny) D1 D12 AT=N AT=C (EligDt From = D12) Przykład 7 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N) oraz z Maturity Date = D10, następnie w dacie D10 miało miejsce wygaszenie transakcji w dacie zapadalności (AT=T). Od daty D1 do daty D9 obowiązują dane przekazane raportem AT=N; od daty D10 obowiązują dane przekazane raportem AT=N z uwzględnieniem wygaszenia transakcji za pomocą technicznego zapisu AT=T. Status raportu: w dniach D1-D9 A (aktywny), od dnia D10 - N (nieaktywny) D1 D10 AT=N AT=T (EligDt From = Maturity Date = D10) 7

Przykład 8 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce częściowa terminacja transakcji (AT=C1) z podaniem daty Eligibility Date From = D3, w dniu D12 nastąpiła kolejna częściowa terminacja transakcji (AT=C2) z podaniem daty Eligibility Date From = D12. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; od daty D3 do daty D11 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=C1; od daty D12 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=C1 oraz zmian przekazanych raportem AT=C2. Status raportu = A aktywny D1 D3 D12 AT=N AT=C1 (EligDt From = D3) AT=C2 (EligDt From = D12) Przykład 9 Transakcja T1 została zaraportowana z datą zawarcia D1, następnie w dacie D3 miała miejsce aktualizacja wyceny z datą wyceny D3 (AT=V1) obowiązująca od D3 do D5, w dacie D5 aktualizacja wyceny z datą wyceny D4 (AT=V2) obowiązująca od D4 do D6. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; w dacie D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny V1 przekazanej raportem AT=V1; od daty D4 do daty D5 obowiązują dane przekazane raportem AT=N z uwzględnieniem aktualizacji wyceny przekazanej raportem AT=V2; od daty D6 obowiązują dane przekazane raportem AT=N (nie obowiązuje już żadna z wycen). Status raportu = A aktywny D1 D3 D4 D5 D6 AT=N AT=V1 (EligDt From = D3 EligDt To = D5) AT=V2 (EligDt From = D4 EligDt To = D6) 8

Przykład 10 Transakcja T1 została zaraportowana z datą zawarcia D1, następnie w dacie D2 miała miejsce modyfikacja daty rozliczenia (AT=M), w dacie D3 aktualizacja wyceny (AT=V1), w dacie D4 aktualizacja wyceny (AT=V2), w dacie D5 aktualizacja wyceny (AT=V3). D1 D2 D3 D4 D5 AT=N AT=M (EligDt From = D2) AT=V1 (EligDt From = D3) AT=V2 (EligDt From = D4) AT=V3 (EligDt From = D5) W dacie D6 raportujący odnotował pomyłkę w wartości wyceny zaraportowanej na datę D3 (AT=V1), przyjęte rozwiązanie pozwoli na aktualizację wartości tej wyceny poprzez przekazanie raportu AT=V z zakresem dat Eligibility Date From=D3 i Eligibility Date To=D3. Wówczas zaktualizowana zostanie tylko i wyłącznie wartość wyceny V1. D1 D2 D3 D4 D5 AT=N AT=M (EligDt From = D2) AT=V1 (EligDt From = D3 EligDt To = D3) aktualizacja wyceny V1 AT=V2 (EligDt From = D4) AT=V3 (EligDt From = D5) Jednocześnie należy mieć na względzie, iż przekazanie w powyższym przypadku raportu AT=V jedynie z datą Eligibility Date From=D3, bez wskazania daty Eligibility Date To, spowoduje zastąpienie historii wyceny od daty D3 poprzez nowy wpis. Oznacza to, że w takiej sytuacji uczestnik zastąpi nowo przesyłanymi danymi wycenę V1, V2 i V3, zatem w dniach D4 i D5 obowiązywać będzie wycena oraz wszystkie pozostałe parametry transakcji zgłoszone na dzień D3. D1 D2 D3 D4 D5 AT=N AT=M (EligDt From = D2) AT=V1 (EligDt From = D3) aktualizacja wyceny V1 i zastąpienie V2, V3 9

AT=V2 (EligDt From = D4) AT=V3 (EligDt From = D5) 2. Zmiany w obsłudze AT=E a) Po przesłaniu AT=E do danej transakcji, użycie tego samego TradId pomiędzy tymi samymi kontrahentami nie będzie możliwe. Jednocześnie jedynym raportem, który może przesłać druga strona jest również raport AT=E. b) Odejście od AT=E przesłanego do dowolnego AT. Od momentu wejścia w życie zmian związanych z walidacją poziomu 2, AT=E będzie usuwać transakcję wraz z całą jej historią. c) Odejście od AT=E zgłaszanego przez PUR a na rzecz AT=O zgłaszanego przez PUR a celem umożliwienia kontrahentowi zgłoszenia raportującemu błędu w zaraportowanych w jego imieniu danych. d) Po odebraniu poprawnego komunikatu AT=E, poza dotychczasową obsługą (anulacja transakcji), dodatkowo tworzony jest nowy rekord (mutacja) AT=E. Wpisy o transakcjach anulowanych będą prezentowane w interfejsie w nowo powołanej do tego celu zakładce (Deleted Reports). 3. Aktualizacja/zmiana danych (zamiast AT=E do mutacji) Aktualizacja/zmiana danych odbywać się będzie poprzez przesłanie komunikatu trar.ins.001.01 z odpowiednim AT, który umożliwia modyfikację zakresu danych, (np. aktualizacja wyceny poprzez komunikat AT=V, aktualizacja danych kontrahenta poprzez AT=M itd. zgodnie z dokumentem Wypełnianie komunikatów ) oraz odpowiednią datą Eligibility Date From i ew. Eligibility Date To. Dopuszczone będą modyfikacje wszystkich pól, z wykluczeniem klucza transakcji (tj. CP1+CP2+TradID). W/w dokument określa, które pola (sekcje) mogą być modyfikowane poprzez poszczególne AT. Klucz transakcji będzie mógł ulec zmianie wyłącznie w przypadku, gdy Uczestnik Raportujący zgłosi zmianę identyfikatora strony transakcji z interim na LEI patrz punkt: Możliwość zmiany Identyfikatorów stron transakcji CP1 i CP2. 4. Umożliwienie kontrahentowi wskazania błędu w danych zgłoszonych w jego imieniu raportowanie delegowane (zastąpienie AT=E (PUR) przez AT=O (PUR)) Dotychczasowe uprawnienie pośredniego uczestnika repozytorium do wykasowania (anulowania) za pomocą AT=E raportu błędnie przekazanego bądź przekazanego z błędnymi wartościami zostaje wycofane i zastąpione możliwością wskazania raportującemu błędu w danych poprzez przekazanie AT=O do transakcji. Przesłanie 10

przez PUR a zgłoszenia o konieczności korekty danych realizowane będzie wyłącznie przez wygenerowanie za pomocą formatki zamieszczonej w interfejsie komunikatu trar.ins.001.01 z AT=O, w którym wypełnione zostaną jedynie sekcje 0 i 1 komunikatu, zawierające klucz korygowanej transakcji oraz datę (zakres dat obowiązywania). Zwrotnie, uczestnik pośredni (PUR), do zakładki TR Communication otrzyma komunikat statusowy trar.sts.002.01, potwierdzający przekazanie notyfikacji o zgłoszeniu błędu do uczestnika raportującego. Po odebraniu zgłoszenia informacji od PUR, do uczestnika raportującego wysłany zostanie komunikat notyfikacyjny trar.ntf.001.01 ze wskazaniem klucza transakcji i datą (zakresem dat) obowiązywania do korekty oraz wskazaniem identyfikatora LEI podmiotu zgłaszającego tę korektę. Komunikat ten zostanie przesłany do kanału, z którego system repozytorium otrzymał ostatnią aktualizację danych dla transakcji (A2A lub U2A). W przypadku kanału A2A komunikat notyfikacyjny zostanie przesłany bezpośrednio do kolejki. Dla kanału U2A komunikat przesłany zostanie do dedykowanej zakładki. W interfejsie graficznym powołana zostanie nowa zakładka Counterparty notifications, w której uczestnik raportujący będzie miał dostęp do komunikatów notyfikacyjnych otrzymywanych od kontrahentów, zgłaszających konieczność korekty raportu. 5. Zmiany związane z AT=C oraz nowy techniczny AT=T 5.1. Definicje: Wygaśnięcie zakończenie aktywności danej transakcji/pozycji w dniu wygaśnięcia podanej w polu Maturity date; Terminacja W przypadku terminacji raportowane są wolumen i wartość pozostające po wygaszeniu części bądź wszystkich kontraktów, a nie terminowane wolumen i wartość kontraktów. Terminacja częściowa zakończenie aktywności części kontraktów danej transakcji/pozycji w dniu terminacji podanej w polu Termination Date; Terminacja całkowita - zakończenie aktywności wszystkich kontraktów danej transakcji/pozycji w dniu terminacji podanej w polu Termination Date; 5.2. Terminację (AT=C) uznajemy za częściową, jeśli w polach Notional Amount i Quantity podane są wartości większe niż 0. Terminację (AT=C) uznajemy za całkowitą, jeśli w polach Notional Amount i Quantity podane są wartości równe 0. 11

W obu przypadkach podanie daty terminacji jest obowiązkowe, przy czym następuje kontrola: jeśli w poprzednim raporcie data Maturity Date jest podana, to Termination Date musi być mniejsza niż lub równa podanej Maturity Date. Dodatkowo, następuje kontrola: jeśli wartości raportowane w polach Notional Amount i Quantity są większe lub równe wartości w mutacji obowiązującej w dniu terminacji przed przesłaniem raportu o terminacji a data terminacji nie jest oznaczona atrybutem delete= Y, to komunikat jest odrzucany. Powyższe zmiany wymagają również wprowadzenia kontroli wartości raportowanych w polach Notional Amount i Quantity komunikat, w którym tylko jedna z tych wartości jest równa zero zostanie odrzucony. Uwaga: Terminacja zbiorcza zawsze traktowana jest jak terminacja całkowita. 5.3. Automatyczne wygaszanie transakcji Zakładamy, że terminowanie transakcji/pozycji jest zgłaszane przez uczestnika, natomiast wygaszanie transakcji w związku z upływem Maturity Date jest obsługiwane codziennym procesem przez RT, przy czym wygaszanie transakcji odbywa się poprzez techniczny Action Type T. Zakres: Procesem objęte są wszystkie raporty, w których ostatnia mutacja ma wypełnioną datę Maturity Date. Czas: Proces uruchamiany będzie każdego dnia roboczego, analogicznie jak dotychczasowe AT=C wykonywane automatycznie przez Repozytorium KDPW. Działanie: Dla wszystkich transakcji, w których ostatnia obowiązująca mutacja ma wypełnioną i mniejszą od daty dzisiejszej datę Maturity Date, tworzony jest wpis AT=T (kod techniczny) z datą obowiązywania Maturity Date o SMR= TR_T_ +TrnKeyId. Wszystkie zaraportowane dane zostają bez zmian, a pola Notional Amount i Quantity są zerowane. Mutacja taka dostaje status rekordu = N (nieaktywny). Zmiana w udostępnianiu danych uczestnikom: O fakcie wygaszenia transakcji uczestnicy są informowani poprzez przesłanie komunikatu notyfikacyjnego trar.ntf.001.01. Uczestnicy będą poinformowani o technicznym kodzie AT=T oraz o statusach rekordu = N. 5.4. Umożliwienie raportowania do wygaśniętych, sterminowanych częściowo i całkowicie transakcji. 12

Transakcja sterminowana częściowo ma status rekordu A - aktywny, co oznacza, że raportowanie zmian odbywa się analogicznie jak do wszystkich aktywnych mutacji. W związku z wycofaniem możliwości anulowania pojedynczego raportu (mutacji), modyfikacja raportów oznaczonych statusem N- nieaktywny (np. po AT=C lub AT=T) odbywać się będzie poprzez kolejny raport odpowiednią datą obowiązywania, przy zachowaniu następujących warunków: - modyfikacja daty terminacji odbywa się tylko i wyłącznie za pomocą AT=C, przy zachowaniu walidacji daty terminacji w stosunku do maturity date, przy czym usunięcie niepoprawnie przekazanej daty terminacji, możliwa jest jedynie za pomocą AT=M z atrybutem delete= Y patrz pkt. 5.5; - modyfikacja daty wygaśnięcia odbywa się tylko i wyłącznie za pomocą AT=M, przy zachowaniu wszystkich stosownych kontroli. Zmiana maturity date powoduje powstanie nowej mutacji o statusie rekordu A-aktywny, niezależnie od tego czy transakcja jest aktywna czy nie (ew. wygaszenie nastąpi zgodnie z pkt. 5.3); - modyfikacja pozostałych wartości (np. wyceny czy danych dot. stron lub transakcji) jest możliwa za pomocą odpowiednich AT (V, M, Z), przy czym stosowana jest kontrola: - jeśli ostatnia mutacja jest nieaktywna, to EligDtTo przesłanego raportu musi być nie większe niż maksymalna data obowiązywania EligDtFrom nieaktywnej mutacji; 5.5. Usunięcie terminacji czyli Restore Usunięcie terminacji Restore (czyli obecny AT=E do AT=C) odbywa się poprzez komunikat trar.ins.001.01 AT=M, w którym Tag Termination Date oznaczony jest atrybutem delete= Y oraz pola Notional Amount i Quantity wypełniane są niezerowymi wartościami. W sytuacji, kiedy komunikat zawiera tag Termination Date oznaczony atrybutem delete= Y a pola Notional Amount i Quantity przyjmują wartość 0, komunikat taki jest przez system odrzucany. W przypadku odebrania komunikatu usuwającego terminację, w systemie zapisywana jest kolejna mutacja AT=M, w której data terminacji jest pusta, a wartości pól Notional i Quantity to wartości podane w komunikacie, co umożliwia uczestnikowi w szczególności modyfikację wraz z usunięciem terminacji w jednym kroku. Przesłanie komunikatu AT=M z wypełnioną datą terminacji nieoznaczoną tagiem delete= Y skutkuje odrzuceniem. Możliwość raportowania zmian do raportów wygaśniętych, sterminowanych częściowo i całkowicie odbywa się na zasadach opisanych w pkt. 5.4. 6. Usunięcie wartości raportowanych zbiorczo 6.1. AT=C 13

Usunięcie terminacji zbiorczej odbywa się pojedynczo na transakcję, komunikatem trar.ins.001.01 z oznaczeniem atrybutem delete= Y tagu Termination Date. Działanie identyczne jak w pkt. 4.5 dla wszystkich transakcji objętych działaniem tego komunikatu. 6.2. AT=V Usunięcie wyceny lub zabezpieczenia wysłanego zbiorczo odbywa się poprzez wysłanie odpowiedniego komunikatu zbiorczego, w którym tag sekcji 2.2. (dla trar.ins.002.01) lub sekcji 2.3. i 2.4 (dla trar.ins.003.01) oznaczony jest atrybutem delete= Y. Przyjęcie komunikatu powoduje zmianę statusu wszystkich wycen lub zabezpieczeń objętych działaniem komunikatu, w efekcie wyceny/ zabezpieczenia te przestają być obowiązujące i widoczne. 6.3. AT=M nie jest możliwe usuwanie, gdyż wszystkie pola modyfikowane zbiorczą M-ką są obowiązkowe (na potrzeby zmiany kodu interim na LEI powołany zostaje nowy komunikat trar.ins.006.01). 7. Zmiany związane z referencjami Odejście od możliwości anulowania pojedynczego wpisu (mutacji) dla transakcji pozwala uprościć sekcję referencji. Podawane w tej sekcji pole SMR przestaje mieć znaczenie, gdyż od momentu wprowadzenia zmian komunikat będzie łączony z transakcją tylko i wyłącznie po kluczu CP1+CP2+TID, przy czym znaczenia nabiera data Eligibility Date From oraz Eligibility Date To, które definiują zakres rekordów objętych zmianą. 8. Wymagalność pól dla poszczególnych AT 8.1. AT=N Wymagalność dotychczasowych pól dla AT=N pozostaje bez zmian. Dodatkowo pojawiają się nowe pola (Eligibility Date To i Underlying Type) oraz dodatkowe kontrole implementowane w ramach poszczególnych sekcji dla konkretnych klas kontraktów. 8.2. AT=M Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz daty/dat obowiązywania. Podawane są wszystkie pola, które mają być modyfikowane. Wartości pól dotąd wypełnionych, a w komunikacie pominiętych są przepisywane. Jeśli w komunikacie wystąpi dla modyfikowalnego pola atrybut delete= Y, wówczas wartość uprzednio w tym polu przekazana jest czyszczona. Nie jest możliwe modyfikowanie sekcji Wycena i zabezpieczenia za pomocą AT=M, a komunikat z wypełniona sekcją Wycena i zabezpieczenia jest odrzucany. Próba wyczyszczenia pól obowiązkowych dla raportu skutkuje odrzuceniem komunikatu. 14

8.3. AT=C Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz pól Notional Amount i Quantity oraz daty terminacji, pozostaje kontrola czy EligDtFrom=Termination Date. 8.4. AT=Z Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz daty/dat obowiązywania i pól Notional Amount i Quantity; 8.5. AT=E Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID); AT=E usuwa całą historię i uniemożliwia ponowne zaraportowanie raportu o takim samym kluczu. Restrykcja ta dotyczy obu stron transakcji. 8.6. AT=V Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz daty/dat obowiązywania; kontrola Valuation Timestamp=EligDtFrom(co do daty) pozostaje bez zmian. 9. Możliwość zmiany identyfikatorów stron transakcji CP1 i CP2. Do zmiany identyfikatorów na kody pre-lei/ LEI służył będzie nowy, dedykowany komunikat trar.ins.006.01, w którym jedyny dopuszczalny AT to M. Zmiana będzie dokonywana w ramach transakcji zaraportowanych przez raportującego przesyłającego komunikat i dotyczyć będzie zarówno identyfikatorów w polach CP1, jak i CP2. Referencje będą budowane na podstawie identyfikatorów raportującego i kontrahenta, przy czym zmiana identyfikatorów obejmuje zarówno pole CtrptyTRId, jak i OthrCtrptyTrId (w typach innych niż LEIC). W wyniku przetworzenia komunikatu powstanie: o Mutacja AT=M, z datą obowiązywania wskazaną w komunikacie z nowymi identyfikatorem i typem identyfikatora CP1 lub CP2 i pozostałymi danymi pochodzącymi z ostatniej obowiązującej mutacji, przy czym w polu ActionTypeDetails dodany zostanie wpis change of ID CP1 lub change of ID CP2 ; o Wszystkie obowiązujące na moment przetworzenia mutacje zostaną nadpisane. W miejsce tych mutacji powstaną rekordy z nowymi identyfikatorami i nowymi typami identyfikatorów CP1, CP2 - pozostałe wartości zostaną przepisane dla tych mutacji; W następstwie dokonanej zmiany uczestnik otrzyma komunikat trat.sts.002.01ze statusem przetworzenia komunikatu PACK lub ERRO (możliwy, gdy np. brak identyfikatora źródłowego w bazie; niedopuszczalny format nowego identyfikatora LEIC, itp.). 10. Nowe kontrole merytoryczne 15

1. Rozszerzenie kontroli kodów LEI używanych w procesie raportowania Kontrola obejmie pola: CP1 (w typie LEIC), CP2 (w typie LEIC), Clearing Member ID (w typie LEIC), Broker ID (w typie LEIC), Beneficiary ID (w typie LEIC), CCP, Underlying (w type L-LEI). Sprawdzamy długość pola (=20) i cyfrę kontrolną (zgodnie z ISO 17442). Komunikat nie spełniający tych kryteriów będzie odrzucany. Jednocześnie w opublikowanym przez ESMA dokumencie Validation 2 zdefiniowany został Step 2 dla walidacji kodów LEI, oparty o status rejestracji kodu LEI, który zakłada odrzucanie raportów, w których kontrahent identyfikowany jest nieaktywnym kodem LEI. Wdrożenie tego kroku nastąpi trzy miesiące od decyzji ESMA o zaimplementowaniu tych kontroli, o czym niezwłocznie Państwa poinformujemy w odrębnej korespondencji. 2. Kontrole związane z polami PrdctId1, PrdctId2, Venue of Execution i Underlying 2.1. Kontrole dla pola Taxonomy 2.1.1. Jeśli pole wypełnione jest wartością U to komunikat jest odrzucany; 2.1.2. Jeśli pole wypełnione jest wartością I to: - Jeśli pole Venue of Execution jest wypełnione wartością XOFF lub ważnym kodem MIC umieszczonym na liście MIFID database Regulated Markets: http://mifiddatabase.esma.europa.eu/index.aspx?sectionlinks_id=23&language=0&p agename=regulated_markets_display lub umieszczonym na liście MIFID database MTF: http://mifiddatabase.esma.europa.eu/index.aspx?sectionlinks_id=22&language=0&p agename=mtf_display&subsection_id=0 to komunikat jest przyjmowany; W przeciwnym przypadku komunikat jest odrzucany. 2.1.3. Jeśli pole wypełnione jest wartością E to: - Jeśli pole Venue of Execution jest wypełnione wartością XOFF lub ważnym kodem MIC umieszczonym na liście MIFID database Regulated Markets: http://mifiddatabase.esma.europa.eu/index.aspx?sectionlinks_id=23&language=0&p agename=regulated_markets_display to komunikat jest odrzucany; 16

W przeciwnym przypadku komunikat jest przyjmowany. 2.2. Kontrole dla pola Venue of Execution Jeśli pole jest wypełnione wartością XXXX lub XOFF, to komunikat jest przyjmowany; W przeciwnym przypadku, jeśli pole wypełnione jest wartością MIC niezgodną z ISO 15022 to komunikat jest odrzucany; Jeśli pole wypełnione jest wartością MIC zgodną z ISO 15022 to: Jeśli kraj wskazany w ISO jest spoza obszaru EEA to komunikat jest przyjmowany; Jeśli kraj wskazany w ISO jest z obszaru EEA to: Jeśli pole jest wypełnione wartością MIC umieszczoną na liście MIFID database Regulated Markets: http://mifiddatabase.esma.europa.eu/index.aspx?sectionlinks_id=23&langua ge=0&pagename=regulated_markets_display lub umieszczoną na liście MIFID database MTF: http://mifiddatabase.esma.europa.eu/index.aspx?sectionlinks_id=22&langua ge=0&pagename=mtf_display&subsection_id=0 to komunikat jest przyjmowany; w przeciwnym przypadku komunikat jest odrzucany; 2.3. Kontrole dla pola ProductID1 2.3.1. Jeśli w polu Taxonomy jest wartość I to pole ProductID1 musi być wypełnione kodem ISIN lub Exchange Product Code. To, jakim kodem powinno być wypełnione, definiują zasady: o Jeśli w polu Venue of Execution jest wartość XOFF to w polu ProductID1 musi być ISIN. o Jeśli w polu Venue of Execution jest MIC umieszczony na liście MIFID database Regulated Markets (link powyżej) to informacja o rodzaju kodu (ISIN bądź AII), który powinien być użyty w polu product ID1 czerpana jest z tej bazy, na tej podstawie następuje walidacja pola. Dla rynków bez definicji identyfikatora walidacja prowadzona jest jak dla kodów AII. o Jeśli w polu Venue of Execution jest MIC umieszczony na liście MIFID database MTF (link powyżej) to w polu ProductID1 może być ISIN lub AII. o Jeśli pole wypełnione jest kodem AII, następuje walidacja długości kodu od 1 do 12 znaków alfanumerycznych. 17

o Jeśli pole wypełnione jest kodem ISIN, następuje walidacja długości kodu dokładnie 12 znaków alfanumerycznych oraz walidacja cyfry kontrolnej kodu (zgodnie z ISO 6166). 2.3.2. Jeśli w polu Taxonomy jest wartość E to dozwolone są tylko wartości: "CO", "CR", "CU", "EQ", "IR" lub "OT". 2.4. Kontrole dla pola Product ID 2 Jeśli w polu Taxonomy jest wartość I to pole ProductID2 musi zawierać kod CFI zgodny z ISO 10962. Co najmniej 2 pierwsze znaki kodu oraz znak reprezentujący klasę instrumentu powinny zostać podane, tzn. nie mogą być X. Dla opcji (kod CFI rozpoczynający się od O ) jest to czwarty znak kodu, dla kontraktów terminowych (kod CFI rozpoczynający się od F ) jest to trzeci znak kodu. Jeśli w polu Taxonomy jest wartość E to dozwolone są tylko wartości: "CD", "FR", "FU", "FW", "OP", "SW" lub "OT". 2.5. Kontrole dla pól Underlying i nowego pola Underlying type Pola Undelying i Underlying type są obowiązkowe dla wszystkich raportów z wyjątkiem tych, w których w polu Product ID1 podano wartość CO, IR lub CU. Jeśli podano CO lub CU to oba pola muszą być puste. Jeśli pole Underlying type jest wypełnione, to dozwolone wartości to: I - ISIN, L- LEI, B- Basket, X-Index N- Not available. o o o o o Jeśli w Underlying type podano L, to sprawdzamy długość pola (=20) i cyfrę kontrolną (zgodnie z ISO 17442). Jeśli podano w Underlying type podano I to sprawdzamy długość pola (=12) i cyfrę kontrolną (zgodnie z ISO 6166). Jeśli w Underlying type podano B, to pole Underlying musi być wypełnione wartością B. Jeśli w Underlying type podano X, to pole Underlying musi być wypełnione wartością I. Jeśli w Underlying type podano N, to pole Underlying musi być wypełnione wartością NA lub puste. 3. Kontrola UTI (TradId) -Do 52 alfanumerycznych znaków, plus dozwolone znaki specjalne: ":", ".", "-", " _"; -Dla raportów przesłanych przed końcem grudnia 2015 dozwolona jest również spacja; -Znaki specjalne nie mogą wystąpić na początku i na końcu pola; 18

4. Kontrola Price Multiplier Dozwolona wartość większa niż zero. 5. Kontrola Quantity Dla wszystkich AT innych niż C, dozwolona wartość większa niż zero, dla C wartość większa lub równa zero. 6. Kontrola Effective Date Effective Date musi być większa lub równa dacie w polu Execution Timestamp dla wszystkich raportów, w których Venue of Execution jest wypełnione kodem MIC (tj. różne od XXXX i XOFF ). 7. Kontrola Termination Date Termination Date musi być większa lub równa dacie wprowadzonej w polu Execution Timestamp i mniejsza lub równa niż data Maturity Date (jeśli podano). 8. Kontrola Clearing Timestamp Pole musi być wypełnione, jeśli pole Cleared= Y ; jeśli wypełnione, musi być większe lub równe Execution Timestamp; 9. Kontrola CCP Pole musi być wypełnione, jeśli pole Cleared= Y ; 10. Sekcja Interest Rates o o o Jeśli w polu ProductID1 podano IR musi być wypełnione co najmniej jedno z pól: Fixed rate of leg 1, Fixed rate of leg 2, Floating rate of leg 1, Floating rate of leg 2; Jeśli wypełnione jest co najmniej jedno z pól: Fixed rate of leg 1, Fixed rate of leg 2, to pola: Fixed rate day count i Fixed leg payment frequency muszą być wypełnione; Jeśli wypełnione jest co najmniej jedno z pól: Floating rate of leg 1, Floating rate of leg 2, to pola: Floating rate reset frequency i Floating leg payment frequency muszą być wypełnione; 11. Sekcja Foreign Exchange Jeśli w polu ProductID1 podano CU to muszą być wypełnione następujące pola: - Currency2, - Exchange rate 1 i/lub Forward exchange rate, - Exchange rate basis; 12. Sekcja Commodities 12.1. Jeśli w polu ProductID1 podano wartość CO to muszą być wypełnione następujące pola: - Commodity base zgodnie ze słownikiem, - Commodity details zgodnie ze słownikiem; 19

12.2. Jeśli w polu Commodity details podano wartość NG lub EL, to muszą być wypełnione następujące pola: - Load type, - Delivery start date and time, - Delivery end date and time, - Contract capacity, - Quantity Unit, - Price/time interval quantities. 12.3. Delivery point or zone jeśli pole jest wypełnione to musi być wypełnione kodem zgodnym z listą EIC Area Codes Y list zamieszczoną na www: https://www.entsoe.eu/fileadmin/user_upload/edi/library//eic/ars/area.htm i wskazującym na punkt dostawy wewnątrz obszaru EU. 13. Sekcja Options Jeśli w polu ProductID2 podano wartość OP lub kod CFI rozpoczynający się na O, to następujące pola muszą być wypełnione: - Option type, - Option style (exercise), - Strike price. 14. Kontrola formatu danych znaki ujemne Umożliwione zostaje zaraportowanie wartości ujemnych we wszystkich wyszczególnionych poniżej polach: - Mark to market value of contract - Price/ rate - Notional amount - Up-front payement - Fixed rate of leg 1 (funkcjonalność dostępna uprzednio) - Fixed rate of leg 2 (funkcjonalność dostępna uprzednio) - Exchange rate 1 - Forward exchange rate 11. Zmiany w procesie rekoncyliacji 11.1. Sprawdzenie statusu kodu LEI przed włączeniem raportu do rekoncyliacji Do procesu rekoncyliacji włączane są tylko te raporty, w których podano poprawne kody LEI kontrahentów oraz poprawny identyfikator UTI. Walidacja identyfikatorów odbywa się według poniższych zasad: 20

- Identyfikator LEI walidujemy zgodnie z bazą LEI. Kod LEI uznawany będzie za ważny, jeśli jego status jest ISSUED, TRANSFERRED, PEDNING TRANSFER, PENDING ARCHIVAL lub LAPSED. - Proces walidacji kodów LEI przeprowadzany jest przy wejściu komunikatu do RT, jednakże powtórna walidacja LEI jest przeprowadzana codziennie przy generowaniu rejestru rekoncyliacji, w ten sposób wszystkie raporty, których status LEI uległ zmianie mogą być włączane do rekoncyliacji. Zmiana zostanie zaimplementowana jeszcze przed wprowadzeniem walidacji Level 2. 11.2. Raporty jednostronne, wskazujące na raport z kontrahentem spoza EEA. Dla takich raportów zaimplementowana zostanie dodatkowa kontrola. Jeśli nie odnaleziono pary takiego raportu, to raport ten dostaje status WPAR (nie podlega rekoncyliacji). Jeśli raport zostanie sparowany, to następuje sprawdzenie kraju siedziby Other Counterparty w raporcie przesłanym przez drugą stronę. Jeśli pole to jest wypełnione znacznikiem kraju z obszaru EEA, to raport otrzymuje status YPAR, ale w statusie porównywania pojawia się błąd CPCT Błędne wypełnienie pola NonEEACtrPty. 11.3. Oznaczenie pozycji i wyłączenie ich z procesu rekoncyliacji Z procesu rekoncyliacji wyłączone zostają rekordy zdefiniowane, jako pozycje, czyli takie transakcje, w których pole Compression wypełniono wartością Y a w polu CCP podano kod LEI, lub rekordy po kompresji (po przesłaniu AT=Z do transakcji); 11.4. Nowe statusy w komunikatach rcn W związku z powyższymi zmianami, w komunikatach rcn przekazywane będą za pomocą dodatkowych statusów informacje o wyłączeniu transakcji z procesu, ponieważ kod lei jednego z kontrahentów nie jest ważny: Nieprawidłowy kod LEI 1 status ERL1; Nieprawidłowy kod LEI 2 status ERL2; Oraz o błędnym wskazaniu drugiego kontrahenta jako spoza obszaru EEA: Błędne wypełnienie pola NonEEACtrPty status CPCT. 12. Załączniki 1. Wypełnianie komunikatów 2. Nowe struktury komunikatów RT 3. Słowniki 21