WALIDACJE LEVEL 2 ZMIANY W SYSTEMIE KDPW_TR

Transkrypt

1 WALIDACJE LEVEL 2 ZMIANY W SYSTEMIE KDPW_TR Warszawa,

2 AGENDA Zmiany informacje ogólne Statystyki Tabela walidacji level 2 Nowe funkcjonalności, zmiany w obsłudze AT Komunikaty zmiany Kody LEI w procesie raportowania Relacje z ESMA Zmiany w obsłudze AT, identyfikacji oraz procesie rekoncyliacji Identyfikacja kody LEI, aktualizacja identyfikatora do kodu LEI LEI walidacja level 2, step 2 konsekwencje Zmiany w procesie rekoncyliacji Krytyczne zmiany w procesowaniu raportów Zmiany w obsłudze AT Nowe funkcjonalności Nowe pola, walidacje level 2, zmiany w komunikatach xml Nowe pola Nowe kontrole tabela walidacji level 2 Zmiany w komunikatach 2

3 Zmiany informacje ogólne 3

4 KDPW_TR STATYSTYKI (na dzień 19 czerwca 2015 r.) 1/4 Liczba uczestników KDPW_TR 210 Generalni Uczestnicy Raportujący (GUR) 15 Zwykli Uczestnicy Raportujący (ZUR) 55 Pośredni Uczestnicy Raportujący (PUR) 140 Komercyjni Użytkownicy Repozytorium (KUR) 5 Liczba nadzorców 11, w tym ESMA Liczba kontrahentów objętych raportami:

5 KDPW_TR STATYSTYKI 2/4 Liczba raportów otrzymanych przez KDPW_TR od lutego 2014 r. do 19 czerwca 2015 r: 5

6 KDPW_TR STATYSTYKI 3/4 Wzrost odrzucanej liczby raportów po wprowadzeniu walidacji poziomu 1; 6

7 KDPW_TR STATYSTYKI 4/4 Odsetek transakcji anulowanych AT=E oraz ponownie raportowanych na bazie tego samego klucza, które powinny zostać obsłużone w alternatywny sposób: 0,27% Odsetek parowania/ matchowania transakcji w procesie rekoncyliacji. - 39% raportów (ok. 17 mln) nie wymaga udziału w rekoncyliacji brak obowiązku raportowania drugiej strony; - Z tych które wymagają zestawiania, ok. 24% (ok. 10 mln) to raporty, w których jedna lub obie strony transakcji nie są identyfikowane ważnym kodem LEI; - Do rekoncyliacji włączane jest codziennie ok. 16,5 mln raportów, z czego wewnętrznie paruje się ok. 95%, a status MACH otrzymuje ok. 95%; - Do rekonycliacji z innymi RT trafia codziennie ok. 800 tys. raportów (tj. niecałe 2% wszystkich raportów przechowywanych w RT), z czego paruje się ok. 15%, status MACH 0%; 7

8 VALIDATION LEVEL 2 Walidacje poziomu 2 zostały opublikowane przez ESMA dnia 27/04/2015. Jednocześnie ESMA opublikowała aktualizację dokumentu Question & Answers. Walidacje poziomu 2 zakres. Nowe kontrole zależne od typu raportowanego kontraktu pochodnego. TR question 20b proponowany sposób wdrożenia walidacji poziomu 2. Utrzymanie równolegle dwóch sposobów kontroli raportów konsekwencje. Wdrożenie jednolitego sposobu walidacji konsekwencje. 8

9 NOWE FUNKCJONALNOŚCI 1/2 Możliwość aktualizacji identyfikatora kontrahenta/ drugiego kontrahenta w przesłanych już raportach do kodu LEI. Zmiany w komunikatach uspójnienie komunikatów xml z zakresem walidacji poziomu 2. Zmiany w procesowaniu błędnych raportów (AT=E), konsekwencje tych zmian. Zastąpienie AT=E (PUR) poprzez AT=O (PUR). 9

10 NOWE FUNKCJONALNOŚCI 2/2 Zmiany w przebiegu obsługi poszczególnych typów komunikatów (AT) (zakres wypełniania komunikatów, notyfikacja). Update historii, uzupełnienie historii raportu (EligDt). Podział na transakcje zapadłe (maturity date, AT=T) oraz sterminowane (termination date, AT=C). Powołanie nowych pól, udostępnianie statusów raportów, wykorzystanie w komunikacie funkcji delete=y. 10

11 DALSZE ZMIANY INFORMACJE OGÓLNE C.D. Planowane rozszerzenie kontroli identyfikatorów LEI o ich status (step 2). Kody LEI dla osób fizycznych prowadzących działalność gospodarczą etap uzgodnień z ROC. Relacje z ESMA wdrożenie nowych standardów technicznych. Potwierdzenie przyjęcia raportów do przetworzenia. 11

12 Zmiany w obsłudze AT, identyfikacji oraz procesie rekoncyliacji 12

13 Zmiana wymagań przy w identyfikacji raportów W związku z walidacją Level 2 znacząco rozszerzy się zakres potencjalnie odrzucanych raportów. W szczególności wynikać będzie to z dwóch czynników. Zmiana podejścia do raportów AT=E. Po zgłoszeniu AT=E, żadna ze stron danej transakcji nie będzie mogła użyć tego samego TID do zaraportowania transakcji między sobą. Odrzucanie raportów w przypadku użycia nieważnego kodu LEI, na skutek: Niezgodności z normą ISO LEI Standard w zakresie formatu i cyfry kontrolnej; Nieważnego Statusu Rejestracji kodu. Bardzo prawdopodobne jest również, iż wymóg ten, zdefiniowany w step 2 do walidacji Level 2, zostanie wdrożony równolegle z wszystkimi innymi zmianami. 13

14 Nowa obsługa AT=E w procesie raportowania Zgłoszenie AT=E ograniczone jest wyłącznie do jednej funkcjonalności całkowite usunięcie danego raportu z bazy Repozytorium. W wyniku przetworzenia AT=E nie będzie możliwości ponownego zaraportowania transakcji z tymi samymi TID; CP1 i CP2. Jedynym akceptowanym raportem złożonym przez drugą stronę, będzie AT=E do raportu drugiego Kontrahenta. W praktyce AT=E powinno być stosowane wyłącznie gdy błąd dotyczył tzw. Klucza transakcji, czyli któregoś z trzech identyfikatorów: TID; CP1, CP2. Przestaje funkcjonować AT=E zgłaszane dotychczas do zmian raportów, czyli do zgłoszeń różnych od AT=N. Ewentualne błędy czy sprostowania w polach z poza Klucza będzie można realizować przez merytorycznie właściwy AT, tym samym udostępniona zostanie funkcjonalność: Modyfikowania wszystkich pól poza Kluczem transakcji; Nadpisywania fragmentu historii transakcji. 14

15 Odstąpienie od AT=E wykonywanego przez PUR Konsekwencje jakie niesie za sobą zaraportowanie AT=E wymusiły zmiany w obsłudze zgłoszeń błędów dokonywanych przez PUR Możliwość zgłoszenia AT=E przysługuje jedynie Uczestnikom Raportującym (UR), tym samym PUR traci tą funkcjonalność. W zamian PUR uzyskuje możliwość poinformowania UR o konieczności korekty raportu. Funkcjonalność ta będzie dostępna dla PUR wyłącznie via U2A; Zgłoszenie będzie realizowana przez AT=O. Po zgłoszeniu AT O przez PUR system Repozytorium wygeneruje do UR komunikat notyfikujący trar.ntf z odpowiednim statusem i kodem przyczyny oraz z kodem LEI Kontrahenta kwestionującego raport. Komunikat notyfikujący do UR zostanie wysłany przez kanał, którym została zgłoszona dana transakcja. W kanale U2A zostanie powołana dedykowana zakładka Counterparty notifications do której trafiać będą komunikaty notyfikacyjne informujące o zgłoszeniu PUR. 15

16 LEI rozszerzenie kontroli kodów w raportach krok 1 Obecnie Repozytorium kontroluje kody LEI dla CP1 i CP2, w przypadku gdy kod jest nieważny do UR komunikatem statusowym wysyłana jest stosowna informacja. Raport jest jednak przyjmowany. Wraz z wdrożeniem Validacji level 2 sprawdzana będzie długość identyfikatora (= 20 znaków alfanumerycznych) i cyfra kontrolna (zgodnie z ISO 17442). Komunikat nie spełniający tych kryteriów będzie odrzucany. Walidacje Level 2 rozszerzają zakres kontrolowanych pól o wszystkie pozycje występujące w Standardach Technicznych, w których używany jest kod LEI, czyli: 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). 16

17 LEI rozszerzenie kontroli kodów w raportach krok 2 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. Bardzo prawdopodobna jest sytuacja, w którym kontrola ta wejdzie jednocześnie z innymi walidacjami Level 2. Kontrola przeprowadzana będzie w oparciu o Statusy Rejestracji kodów LEI zamieszczone w Globalnym Repozytorium Kodów LEI prowadzonym przez GLEIF. Akceptowane będą raporty z poniższymi Statusami Rejestracji: Dla pola CP1: ISSUED, PEDNING TRANSFER, PENDING ARCHIVAL. Dla pól CP2, Clearing Member ID, Broker, Beneficiary ID, CCP: ISSUED, PEDNING TRANSFER, PENDING ARCHIVAL, LAPSED. Raporty nie spełniające tych kryteriów będą odrzucane! 17

18 Podstawowe zmiany w procesie Rekoncyliacji Do procesu rekoncyliacji włączane są tylko te raporty, w których podano poprawne kody LEI obu Kontrahentów oraz poprawny identyfikator UTI. TID - maksymalnie 52 alfanumerycznych znaków oraz: Dozwolone znaki specjalne w tym polu to: ":", ".", "-", " _"; Dla raportów przesłanych przed końcem grudnia 2015 r. dozwolona jest również spacja; Znaki specjalne nie mogą wystąpić na początku i na końcu pola. Identyfikator LEI walidowany będzie zgodnie z Centralnym Repozytorium LEI na przyjęciu transakcji. Statusy kodów akceptowane dla CP1 i CP2 przedstawione zostały na poprzednim slajdzie. Powtórna walidacja LEI jest przeprowadzana każdego dnia przy generowaniu rejestru rekoncyliacji. W procesie rekoncyliacji uwzględniane są kody LEI ze statusem: ISSUED, TRANSFERRED, PEDNING TRANSFER, PENDING ARCHIVAL i LAPSED. 18

19 Dalsze zmiany w procesie Rekoncyliacji Nowe statusy koncyliacyjne do oznaczenie błędnych kodów LEI Kontrahentów: Nieprawidłowy kod LEI 1 status ERL1; Nieprawidłowy kod LEI 2 status ERL2; Dodatkowa kontrola dla transakcji zgłaszanych jednostronnie, w których wskazano, że druga strona jest spoza EOG. Co do zasady, jak to ma miejsce obecnie raporty nie wchodzą do Rekoncyliacji gdy CP2 jest oznaczony jako podmiot z poza OEG; Jeżeli jednak odnaleziony zostanie raport drugiej strony i jednocześnie w raporcie tym Kontrahent jest oznaczony kodem kraju ze strefy EOG, wówczas transakcja jest odzyskiwana dla procesu rekoncyliacji, a do właściwego UR kierowany jest komunikat trar.rcn z kodem błędu: CPCT Błędne wypełnienie pola NonEEACtrPty. Rekoncyliacji podlegają wyłącznie transakcje. Tym samym wyłączone zostają z niej pozycje, czyli: Raporty głoszone ze znacznikiem Compression Y ; Transakcje zmodyfikowane przez AT=Z. 19

20 Zmiana identyfikatora Kontrahenta Uczestnik Raportujący będzie mógł zmodyfikować identyfikator Kontrahenta danego podmiotu we wszystkich zaraportowanych przez siebie transakcjach w związku z przejściem z identyfikatora własnego na kod LEI. Funkcjonalność ta nie będzie służyć do modyfikowania Klucza transakcji z uwagi na wystąpienie błędu w trakcie raportowania. Służy jedynie do zmiany Identyfikatora Kontrahenta typu Interim na LEI w związku z wejściem podmiotu w jego posiadanie. Zmiana realizowana będzie dedykowanym komunikatem trar.ins , w którym definiowany będzie stary i nowy identyfikator. Po przetworzeniu zgłoszenia UR otrzyma trat.sts ze statusem PACK lube ERRO. Zmiana obejmować będzie zarówno pola CP1 jak i CP2 w obrębie transakcji zaraportowanych przez danego UR. Po przetworzeniu komunikatu założona zostanie nowa mutacja transakcji (At M) z nowym identyfikatorem Kontrahenta. Wszystkie dotychczasowe mutacje zostaną nadpisane. 20

21 Aktualizacja danych w przesłanych raportach Co zamiast AT=E do mutacji/części historii? Modyfikacja odpowiednim AT, czyli nadpisanie historii zaraportowanej transakcji Opcja 1: Od podanej daty (Eligibility Date From) Opcja 2: W podanym okresie czasu (od Eligibility Date From do Eligibility Date To) Uwaga!: Nie wymagane jest anulowanie uprzednio przesłanych raportów. Dopuszcza się modyfikację wszystkich pól, z wykluczeniem klucza transakcji (tj. CP1+CP2+TradID). 21

22 Aktualizacja danych w przesłanych raportach Eligibility Date -> Eligibility Date From + Eligibility Date To Zasady: Data Eligibility Date From będzie wymagana w każdym komunikacie. 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 (Przykład1). 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 działa tylko dla AT=M, V lub Z, w pozostałych AT Eligibility Date To jest ignorowana (Przykład 2). 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ład 3). Dotyczy to zarówno komunikatów podstawowych trar.ins.001, jak i komunikatów zbiorczych trar.ins.02, trar.ins.03, trar.ins

23 Aktualizacja danych w przesłanych raportach Przykład 1 Do tej pory: Przykładowy raport historii transakcji: AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3. AT=V, EligDt= , SMR4, Valuation4. Dodanie wyceny z dnia : AT=V, EligDt= , SMR5, Valuation5. Po wprowadzeniu zmian: Przykładowy raport historii transakcji: AT=N, EligDtFrom= , SMR1, Valuation1. AT=V, EligDtFrom= , SMR2, Valuation2. AT=V, EligDtFrom= , SMR3, Valuation3 AT=V, EligDtFrom= , SMR4, Valuation4. Dodanie wyceny z dnia : AT=V, EligDtFrom= , EligDtTo=NULL, SMR5, Valuation5. AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3. AT=V, EligDt= , SMR4, Valuation4. AT=V, EligDt= , SMR5, Valuation5. AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3. AT=V, EligDt= , SMR4, Valuation4. AT=V, EligDt= , SMR5, Valuation5. 23

24 Aktualizacja danych w przesłanych raportach Przykład 2 Do tej pory: Przykładowy raport historii transakcji: Przykładowy raport historii transakcji po modyfikacji: AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3. AT=V, EligDt= , SMR4, Valuation4. AT=V, EligDt= , SMR5. Valuation5. AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3_1. AT=V, EligDt= , SMR7, Valuation4. AT=V, EligDt= , SMR8. Valuation5. Aby zmodyfikować wycenę SMR3 i zachować dalszą historię bez zmian należy przesłać: AT=E do SMR5, SMR4, SMR3. oraz: AT=V, EligDt= , SMR6, Valuation3_1, AT=V, EligDt= , SMR7, Valuation4,. AT=V, EligDt= , SMR8, Valuation5, 24

25 Aktualizacja danych w przesłanych raportach Przykład 2 c.d. Po wprowadzeniu zmian: Przykładowy raport historii transakcji: Przykładowy raport historii transakcji po modyfikacji: AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3. AT=V, EligDt= , SMR4, Valuation4. AT=V, EligDt= , SMR5. Valuation5. AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3_1. AT=V, EligDt= , SMR4, Valuation4. AT=V, EligDt= , SMR5. Valuation5. Aby zmodyfikować wycenę SMR3 i zachować dalszą historię bez zmian należy przesłać: AT=V, EligDtFrom= , EligDtTo= , Valuation3_1 25

26 Aktualizacja danych w przesłanych raportach Przykład 3 Po wprowadzeniu zmian: przesłanie komunikatu z niewypełniona datą EligDtTo usuwa historię od podanej daty EligDtFrom Przykładowy raport historii transakcji: AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR3, Valuation3. AT=V, EligDt= , SMR4, Valuation4. AT=V, EligDt= , SMR5. Valuation5. Przykładowy raport historii transakcji po modyfikacji: AT=N, EligDt= , SMR1, Valuation1. AT=V, EligDt= , SMR2, Valuation2. AT=V, EligDt= , SMR6, Valuation6. Komunikat AT=V, EligDtFrom= , EligDtTo=NULL, SMR6, Valuation 6 26

27 Zmiany związane z terminacją i wygasaniem transakcji Definicje Wygaśnięcie zakończenie aktywności danej transakcji/pozycji w dniu wygaśnięcia podanej w polu Maturity date; Terminacja 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; 27

28 Terminacja - zmiany 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. W przypadku obu terminacji podanie daty terminacji jest obowiązkowe, przy czym data ta nie może być większa niż Maturity date (o ile podano). Dodatkowe kontrole dla pól Notional Amount i Quantity Status transakcji całkowicie sterminowanej - N (nieaktywny) Uwaga: Terminacja zbiorcza zawsze traktowana jest jak terminacja całkowita. 28

29 Automatyczne wygaszanie transakcji Nowo powołany techniczny rodzaj zmiany AT=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 Uczestnicy będą poinformowani o technicznym kodzie AT=T oraz o statusach rekordu = N. 29

30 Raportowanie do transakcji nieaktywnych Możliwe jest przesłanie modyfikacji danych (AT=M,V, C) z datą obowiązywania nie późniejszą niż data wygaśnięcia/terminacji; 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 ; 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. Usunięcie terminacji Restore (czyli obecny AT=E do AT=C) - komunikat trar.ins.001, 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. 30

31 Nowe pola, kontrole level 2, zmiany w komunikatach xml 31

32 VALIDATION LEVEL 2 zmiany kontroli 1/6 Rozszerzenie kontroli kodów LEI używanych w procesie raportowania. UWAGA! ESMA opublikowała również zakres step 2 walidacji kodów LEI obejmujący kontrolę statusu kodu i konieczność odrzucania raportów z kodami nie spełniającymi kryteriów walidacji. Step 2 wdrożony zostanie w terminie 3 miesięcy od daty decyzji ESMA. 32

33 VALIDATION LEVEL 2 zmiany kontroli 2/6 Kontrole związane z identyfikacją kontraktu: Txnm, PrdctId1, PrdctId2 oraz VenueOfExc. Txnm U skutkować będzie odrzuceniem komunikatu; I jeśli wartość pola VenueOfExc nie zawiera się w MIFID database Regulated Markets lub MIFID database MTF, komunikat będzie odrzucony; E jeśli wartość pola VenueOfExc wypełnione jest wartością XOFF lub kodem MIC z listy MIFID database Regulated Markets, komunikat będzie odrzucony; PrdctId1 Jeśli w polu Txnm jest wartość I to pole ProductID1 musi być wypełnione kodem ISIN lub Exchange Product Code. Jeśli w polu Txnm jest wartość E to dozwolone są tylko wartości: CO, CR, CU, EQ, IR lub OT. PrdctId2 Jeśli w polu Txnm jest wartość I to pole ProductID2 musi zawierać kod CFI zgodny z ISO Jeśli w polu Txnm jest wartość E to dozwolone są tylko wartości: CD, FR, FU, FW, OP, SW lub OT. 33

34 VALIDATION LEVEL 2 zmiany kontroli 3/6 VenueOfExc 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 to komunikat jest odrzucany; Jeśli pole wypełnione jest wartością MIC zgodną z ISO 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 lub umieszczoną na liście MIFID database MTF, to komunikat jest przyjmowany; w przeciwnym przypadku komunikat jest odrzucany. 34

35 VALIDATION LEVEL 2 zmiany kontroli 4/6 Kontrole dla pól Underlying i nowego pola Underlying type. Dla pola Underlying zostaje powołane nowe pole techniczne Underlying type określające rodzaj użytego w polu Underlying identyfikatora. Dopuszczalne wartości pola Underlying type: I ISIN L LEI B Basket X Index N Not available Pole Underlying staje się polem opcjonalnym dla kontraktów identyfikowanych za pomocą klasyfikacji przejściowej, w których w polu Product ID 1 występuje wartość CO (towarowy instrument pochodny), IR (instrument pochodny na stopę procentową) bądź CU (walutowy instrument pochodny). Dla wartości CO oraz CU tagi opisujące instrument bazowy muszą pozostać puste. Underlying technical pole umożliwiające zaraportowanie instrumentu bazowego poza standardem na potrzeby danego podmiotu raportującego (np. na potrzeby wyceny zbiorczej). 35

36 VALIDATION LEVEL 2 zmiany kontroli 5/6 Kontrola UTI. Zgodnie z zasadami omawianymi przy procesie rekoncyliacji. Kontrola pola Price Multiplier. Dozwolone jest raportowanie wartości większych niż zero. Kontrola pola Quantity. Kontrola pól związanych z datami: Effective date; Termination date; Clearing Timestamp. Kontrola pola CCP. 36

37 VALIDATION LEVEL 2 zmiany kontroli 6/6 Zasady kontroli poszczególnych pól w sekcji Interest rate. Zasady kontroli poszczególnych pól w sekcji Foreign Exchange. Zasady kontroli poszczególnych pól w sekcji Commodity. Zasady kontroli poszczególnych pól w sekcji Options. Umożliwienie raportowania wartości ujemnych w 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 37

38 Zmiany w komunikatach xml 1/4 Zmiany numeracji wersji komunikatów oraz zmiany związane z referencjami: odejście od możliwości anulowania pojedynczego wpisu (likwidacja referencji po SMR komunikatu) wzrost znaczenia dat Eligibility Date From oraz Eligibility Date To, które definiują zakres rekordów objętych zmianą Wymagalność pól dla poszczególnych AT: 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. 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. 38

39 Zmiany w komunikatach xml 2/4 Wymagalność pól dla poszczególnych AT c.d. Dla AT={M, C, Z, V} Istotną zmianą jest sposób obsługi komunikatów dla poszczególnych AT sekcje dotąd ignorowane zostały przedefiniowane i określone dla poszczególnych rodzajów zmian tak, aby wypełnienie sekcji/ tagów nie dotyczących danego AT skutkowało odrzuceniem komunikatu. Dokument Sposób i zakres wypełniania danych dla poszczególnych rodzajów zmian (AT) obrazuje poprawny zakres danych oczekiwany dla poszczególnych rodzajów zmian. 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. 39

40 Zmiany w komunikatach xml 3/4 Anulowanie wartości raportowanych zbiorczo Co zamiast AT=E do wartości raportowanych zbiorczo? AT=C Usunięcie terminacji zbiorczej odbywa się pojedynczo na transakcję, komunikatem trar.ins z oznaczeniem atrybutem delete= Y tagu Termination Date. 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 ) lub sekcji 2.3. i 2.4 (dla trar.ins ) oznaczony jest atrybutem delete= Y. Przyjęcie komunikatu do KDPW_RT powoduje anulowanie wszystkich wycen lub zabezpieczeń objętych działaniem komunikatu. 40

41 Zmiany w komunikatach xml 3/4 Raportowanie na datę lub za wskazany okres czasu. Formant delete=y dla tagu zasady używania i konsekwencje. Udostępnienie statusów raportów. Zmiany w interfejsie graficznym nowe zakładki: Transakcje anulowane Notyfikacje 41

42 Dziękujemy za uwagę Dział Repozytorium Transakcji KDPW_TR Kontakt: Internet: Telefon: Repozytorium Transakcji: ,