Opis funkcjonalności KDPW_TR wrzesień 2016 1
Spis treści Użytkownicy Repozytorium... 4 Obsługa komunikatów... 6 Budowa komunikatów XML... 6 Przestrzenie nazw (namespaces)... 6 Nagłówki... 7 Zestaw znaków... 7 Przepływ komunikatów pomiędzy Uczestnikami a Repozytorium... 7 Dostęp do KDPW_TR... 14 Zakres informacji przechowywanych w KDPW_TR... 16 Identyfikatory transakcji i zgłoszenia w systemie TR... 17 Kluczowe daty związane z procesem raportowania... 18 Identyfikatory podmiotów stosowane w KDPW_TR... 19 Kontrola rodzajów zmian... 22 Rodzaje zmian... 23 AT=N (New)... 26 AT=M (Modify)... 26 AT=E (Error)... 28 AT=C (Termination)... 29 AT=Z (Compression)... 32 AT=V (Valuation and collateral update)... 33 AT=O (Other)... 34 AT=T (Technical)... 35 RAPORTOWANIE DO TRANSAKCJI NIEAKTYWNYCH... 35 WYCOFANIE TERMINACJI... 36 Raportowanie niezwiązane z pojedynczą transakcją (zbiorcze)... 36 Terminacja zbiorcza... 37 Wycena i zabezpieczenia zbiorcze... 37 USUNIĘCIE WARTOŚCI RAPORTOWANYCH ZBIORCZO... 38 Znacznik pozycja/transakcja... 39 Kontrole komunikatów i obsługa błędów... 39 Funkcjonalności TR w zakresie dostępu do danych... 40 2
Rekoncyliacja danych... 41 Dostęp do danych zagregowanych i informacji publicznych... 41 ZAŁĄCZNIK przykłady... 42 3
Użytkownicy Repozytorium Można wyróżnić następujące klasy podmiotów, których działanie jest rozróżnione poziomem ich uprawnień: 1) Operator repozytorium osoba z TR, której uprawnienia wynikają z roli nadanej w referencyjnych bazach TR: administrator, operator, audyt wewnętrzny. 2) Nadzorca (Supervisor) - podmiot przewidziany w Rozporządzeniu Parlamentu Europejskiego i Rady (UE) Nr 648/2012 z dnia 4 lipca 2012 r. (art. 81 ust. 3), który posiada dostęp do danych zawartych w TR, nadany zgodnie z zasadami zawartymi w regulacjach. Nadzorcy posiadają nie tylko dostęp do danych transakcyjnych, ale także do raportów wynikających z regulacji i wymogów ESMA. 3) Generalny uczestnik raportujący (GUR) podmiot uprawniony do raportowania w imieniu własnym lub w imieniu innego podmiotu, jako instytucja pośrednicząca (nie będąca stroną transakcji); posiada uprawnienia do wprowadzania, modyfikowania, usuwania raportów, w których występuje, jako podmiot raportujący (działając w imieniu własnym lub innego podmiotu zawierającego transakcję), jednocześnie ma możliwość przeglądania danych o transakcjach, które zaraportował oraz danych o transakcjach zaraportowanych przez innych raportujących, w których jest stroną; może wykorzystywać zarówno kanał WEB jak i kanał MQ. 4) Zwykły uczestnik raportujący (ZUR) podmiot uprawniony do raportowania we własnym imieniu lub w imieniu kontrpartnera pod warunkiem, iż jest stroną transakcji; posiada uprawnienia do wprowadzania, modyfikowania, usuwania danych, w których występuje, jako raportujący, jednocześnie ma możliwość przeglądania danych o transakcjach, które zaraportował oraz danych o transakcjach zaraportowanych przez innych raportujących, w których jest stroną; może wykorzystywać zarówno kanał WEB jak i kanał MQ. 5) Pośredni uczestnik repozytorium (PUR) podmiot, który sam nie zgłasza danych o zawartych przez siebie transakcjach, ale jest zainteresowany przeglądaniem transakcji i ewentualnym zgłaszaniem błędów w transakcjach zaraportowanych, w których jest podmiotem zawierającym (stroną transakcji); może wykorzystywać zarówno kanał WEB jak i kanał MQ; 6) Komercyjny użytkownik repozytorium (KUR) - podmiot, który za zgodą kontrahenta, będącego uczestnikiem repozytorium uzyskuje dostęp do danych o jego transakcjach. Jednocześnie zakłada się, iż podmiot ten bez względu na relację z KDPW_TR będzie oznaczony oddzielnym uprawnieniem KUR (czyli nie ma znaczenia, że ten podmiot 4
może mieć już uprawnienie ZUR lub GUR). KUR jest identyfikowany przez TR w momencie rejestracji uprawnień. Korzysta z kanału Web i MQ. Repozytorium zobowiązane jest do udostępnienia kontrahentom, rozumianym jako strony transakcji (zgodnie z art. 80 EMIR), możliwości weryfikowania poprawności zarejestrowanych transakcji. W praktyce oznacza to konieczność przyznania wszystkim chętnym podmiotom zidentyfikowanym przez uczestników zgłaszających, jako strony transakcji, podglądu do danych ich dotyczących. Dostęp ten możliwy jest poprzez stronę WWW (U2A) jak i kanałem A2A, i jest ograniczony wyłącznie do transakcji, w których dana instytucja występuje, jako kontrpartner. Taki dostęp przewidziany jest dla PUR - stron transakcji. W przypadku uczestników pośrednich przeglądanie informacji o zaraportowanych transakcjach jest w rzeczywistości obok oznaczenia raportu o transakcji jako błędnego i, jedyną możliwą aktywnością w ramach TR. i Funkcjonalność w przygotowaniu. 5
Obsługa komunikatów Budowa komunikatów XML Nazewnictwo komunikatów KDPW_TR opiera się na zaleceniach normy ISO20022: Nazwa komunikatu posiada następującą postać: yyyy.aaa.bbb.xx gdzie: yyyy aaa bbb xx - prefix komunikatów: trar przedrostek komunikatów wykorzystywanych przez system TR; admi komunikat wystąpienia błędu formalnego; rodzaj komunikatu związany z jego funkcją: ins- zgłoszenie; rqs zapytanie; sts odpowiedź; rcn rekoncyliacja; err komunikat wystąpienia błędu formalnego; ntf notyfikacja. kod określający wariant funkcji komunikatu numeryczny; wersja komunikatu w postaci numerycznej. Nazwy i struktury powołanych komunikatów XML zostały zamieszczone na witrynie KDPW. Przestrzenie nazw (namespaces) W komunikatach KDPW_TR wykorzystywane są cztery przestrzenie nazw: Domyślna przestrzeń nazw (defaultnamespace) Jej nazwa składa się z części stałej w postaci: urn:std:kdpw: oraz części zmiennej zbudowanej według schematu: xsd:identyfikatorkomunikatu (np.: urn:std:kdpw:xsd:trar.ins.001.02) xs: standardowa przestrzeń nazw dla W3C XML schema xsi: standardowa przestrzeń nazw dla W3C XML schemainstance 6
docelowa przestrzeń nazw (target namespace) taka sama jak przestrzeń domyślna Nagłówki Pierwszy element każdego komunikatu posiada zawsze nazwę: <KDPWDocument>. Element ten zawiera następujące obowiązkowe atrybuty: Sndr (sender) nadawca komunikatu w postaci kodu uczestnika KDPW_TR lub kodu KDPW_TR (R001); Rcvr (receiver) odbiorca komunikatu w postaci kodu uczestnika KDPW_TR lub kodu KDPW_TR (R001). Drugi element (bezpośredni potomek elementu głównego) posiada zawsze nazwę tożsamą z nazwą komunikatu. Przykład: <KDPWDocumentSndr= kod wystawcy Rcvr= =R001 xmlns="urn:std:kdpw:xsd: yyyy.aaa.bbb.xx" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" <yyyy.aaa.bbb.xx> <GnlInf> </GnlInf> </yyyy.aaa.bbb.xx> </KDPWDocument> Zestaw znaków Komunikaty KDPW_TR wykorzystują zestaw kodowania znaków UTF-8. Przepływ komunikatów pomiędzy Uczestnikami a Repozytorium W ramach obsługi rynku przez KDPW_TR wykorzystywane są następujące typy komunikatów: 7
1) Komunikat zgłoszenia do systemu TR - trar.ins.001.xx (gdzie xx to aktualna wersja komunikatu), 2) Raportowanie wyceny - trar.ins.002.xx (gdzie xx to aktualna wersja komunikatu), 3) Raportowanie zabezpieczeń - trar.ins.003.xx (gdzie xx to aktualna wersja komunikatu), 4) Raportowanie terminacji instrumentu lub pozycji na koncie - trar.ins.004.xx ii (gdzie xx to aktualna wersja komunikatu), 5) Raportowanie zmian danych kontrahenta - trar.ins.005.xx i (gdzie xx to aktualna wersja komunikatu), 6) Komunikat zmiany identyfikatora kontrahenta na LEI trar.ins.006.xx i (gdzie xx to aktualna wersja komunikatu), 7) Notyfikacja - trar.ntf.001.xx (gdzie xx to aktualna wersja komunikatu), 8) Komunikat przyjęcia komunikatu do systemu TR po kontroli formalnej (zwrotny I stopnia) trar.ack.001.xx (gdzie xx to aktualna wersja komunikatu) 9) Komunikat błędu formalnego admi.err.001.xx (gdzie xx to aktualna wersja komunikatu) 10) Komunikat ze statusem zgłoszenia do systemu TR po kontroli merytorycznej dla komunikatu podstawowego (zwrotny II stopnia) - trar.sts.003.xx (gdzie xx to aktualna wersja komunikatu), 11) Komunikat ze statusem zgłoszenia do systemu TR po kontroli merytorycznej dla komunikatu zbiorczego oraz komunikatu przepytującego (zwrotny II stopnia) - trar.sts.002.xx (gdzie xx to aktualna wersja komunikatu), 12) Komunikat ze statusem przetworzenia zgłoszenia do systemu TR po kontroli merytorycznej dla komunikatu zbiorczego oraz komunikatu przepytującego (zwrotny III stopnia) - trar.sts.002.xx (gdzie xx to aktualna wersja komunikatu), 13) Komunikat potwierdzający przetworzenie i zapis w systemie TR (zwrotny III stopnia) - trar.sts.001.xx (gdzie xx to aktualna wersja komunikatu), 14) Komunikat zgłoszenia przepytującego - trar.rqs.001.xx (gdzie xx to aktualna wersja komunikatu), 15) Komunikat informujący o nieskutecznym parowaniu lub porównaniu raportów - trar.rcn.001.xx (gdzie xx to aktualna wersja komunikatu). Do KDPW_TR przekazywane są (za pomocą komunikatów trar.ins.xxx.xx) raporty o zawarciu transakcji oraz pozostałe raporty związane z modyfikacją zgłoszeń. Każdy przyjęty komunikat jest przetwarzany w systemie i na każdym poziomie jego przetwarzania wysyłana jest do ii Komunikat w opracowaniu. 8
nadawcy odpowiedź z informacją (o ile uczestnik wyraził taką potrzebę w deklaracji uczestnika). Poziom I kontrola formalna W przypadku błędu formalnego będzie to komunikat admi.err.001.xx, ze wskazaniem kodu i opisu błędu oraz wskazaniem miejsca błędu. Do błędów formalnych zaliczamy następujące rodzaje błędów: komunikat niezgodny ze schemą XSD bądź nadawca niezgodny z nadawcą podanym w polu Identyfikator TR wystawcy komunikatu (TRRprtId) w komunikacie. W odpowiedzi na przesłany komunikat, w którym nie wykryto błędów formalnych, system zwrotnie wygeneruje jeden komunikat trar.ack.001.xx potwierdzający odebranie komunikatu oraz pozytywne przejście kontroli formalnej bez względu na ilość transakcji przekazanych w tym komunikacie. Poziom II kontrola merytoryczna Informacja o wyniku kontroli merytorycznej przekazywana jest komunikatem trar.sts.003.xx z odpowiednim statusem ( PACK w przypadku poprawnego komunikatu, ERRO w przypadku błędu). Poziom III zapis w bazie danych KDPW_TR Po przetworzeniu raportu i zapisaniu danych w bazie danych KDPW_TR, do uczestnika raportującego wysyłany jest komunikat potwierdzający dane zapisane w bazie KDPW_TR na podstawie przesłanego raportu (trar.sts.001.xx, status PACK). Ponadto do uczestników wysyłane są komunikaty notyfikacyjne, generowane z systemu TR w następujących przypadkach: Wskazanie przez PUR raportu do korekty funkcja w interfejsie: Data Correction (AT=O) komunikat notyfikacyjny trar.ntf.001.xx przesyłany jest do uczestnika raportującego, informując go o zgłoszeniu niepoprawności zaraportowanej transakcji przez PUR-a iii ; Komunikat informujący o wynikach rekoncyliacji trar.rcn.001.xx. Komunikat ten zawiera informacje o statusach parowania i porównywania oraz rozbieżnościach w szczegółach sparowanej, porównywanej transakcji w raportach złożonych przez zobowiązanych kontrahentów; Komunikat informujący o wygaszeniu transakcji (AT=T) w dacie jej zapadalności (trar.ntf.001.xx); iii W opracowaniu. 9
Komunikat informujący o anulowaniu (AT=E) transakcji przez drugiego kontrahenta (trar.ntf.001.xx) iv ; Wszystkie komunikaty wchodzące do KDPW_TR, są niezwłocznie przyjmowane, a komunikaty zwrotne kierowane są w ten sam kanał, którym zostały przekazane. Prezentowane poniżej diagramy opisują przepływy komunikatów w KDPW_TR: iv W opracowaniu. 10
11
12
Wszystkie komunikaty, bez względu na kanał wejścia (interfejs graficzny WWW U2A czy też interfejs A2A patrz punkt Dostęp do KDPW_TR ) obsługiwane są zgodnie z zasadą FIFO [first in first out]. System TR przetwarza komunikaty w kolejności ich przekazania. Oznacza to, że możliwe będzie przekazanie dwóch kolejnych komunikatów dotyczących tej samej transakcji (np. rejestracja AT=N i kompresja AT=Z) bez oczekiwania na potwierdzenie przetworzenia pierwszego z nich. Zgodnie z tą zasadą nigdy nie dojdzie do sytuacji, gdy system TR zarejestruje kompresję przed przetworzeniem komunikatu rejestrującego zawarcie transakcji, jeśli zawarcie zostało zgłoszone przed kompresją. 13
Dostęp do KDPW_TR Podstawową funkcją repozytorium transakcji jest rejestracja zgłoszeń transakcji. Rejestracja dokonywana jest na podstawie zdefiniowanych komunikatów przesyłanych do repozytorium transakcji przez uczestnika raportującego, przy czym komunikaty te mogą być przekazywane przy wykorzystaniu: o Interfejsu U2A (User to Application): graficzny interfejs użytkownika, wspierający manualną wymianę danych z aplikacją TR. Zrealizowany na bazie aplikacji dostępnej w ramach witryny internetowej www.kdpw.pl. Interfejs jest udostępniony w sieci Internet. Do współpracy z aplikacją niezbędna jest przeglądarka Internet Explorer v. 10 (i wyższa) bądź Chrome. Panele wyboru dotyczące danych ogólnodostępnych KDPW_TR działają w przeglądarce Internet Explorer v. 10 i wyższej bądź Chrome. o Kanału A2A (Application to Applicaction): kanału wspierającego automatyczną wymianę danych pomiędzy aplikacją TR po stronie KDPW i aplikacjami Uczestników KDPW_TR. Zrealizowany na bazie wymiany zdefiniowanych komunikatów XML za pomocą oprogramowania IBM WebSphere MQ. Kanał A2A jest udostępniony w sieci Internet, z wykorzystaniem bezpiecznego tunelu VPN (VPN concentrator lub router komunikacyjny) oraz w ramach sieci Extranet, zbudowanej na bazie kanałów cyfrowych operatorów Polpak i Exatel. Parametry konfiguracyjne kanału komunikacyjnego oraz nazwa kolejki MQ, kanału komunikacji MQ są udostępnione na stronie internetowej. Dalsze szczegóły, profil dostępowy oraz hasło zostają przekazane zainteresowanym użytkownikom po wystąpieniu o udostępnienie środowiska w trybie A2A i po pobraniu certyfikatu elektronicznego, który służy do uwierzytelnienia kanału komunikacyjnego, zestawianego w oparciu o wyposażenie telekomunikacyjne. W ramach interfejsu obsługiwane jest oprogramowanie w IBM WebSphere MQ w wersji Client i w wersji Server. KDPW nie pośredniczy w dystrybucji tego oprogramowania. Komunikaty związane z rejestracją informacji w KDPW_TR są zbudowane w oparciu o zakres informacyjny określony przez regulatorów. Zawierają one zestaw danych wymaganych przez Repozytorium do właściwego identyfikowania transakcji oraz właściwej obsługi procesów rejestracji. Komunikat wchodzący do systemu TR (niezależnie od rodzaju zmiany w nim zadeklarowanego) posiada jednolitą strukturę, przy czym opracowane zostały również uproszczone komunikaty zbiorcze pozwalające na alternatywną obsługę konkretnych rodzajów 14
zmian. Zakres wymaganych i przetwarzanych danych jest uzależniony od typu rejestracji i został opisany w dalszej części materiału. W przypadku raportowania za pośrednictwem komunikatów XML w oparciu o interfejs A2A lub U2A, istnieje możliwość zgłaszania wielu transakcji za pośrednictwem jednego pliku. Wówczas w komunikatach zwrotnych znajdować się będzie informacja o statusie przetworzenia każdego z raportów, a w przypadku błędu podany zostanie również kod tego błędu. W przypadku użycia formularza graficznego, komunikaty zwrotne kierowane są do dedykowanego folderu (TR Communication), gdzie można je pobrać w formacie *.xml. W ramach tej funkcjonalności obsługiwane są również przypadki informowania uczestnika raportującego o zgłoszeniu błędu przez PUR-a (AT=O) v, o anulowaniu transakcji przez drugiego kontrahenta (AT=E) v oraz o rozbieżności wykrytej w procesie rekoncyliacji. Komunikaty te są kierowane do interfejsu WWW, wyłącznie w sytuacji, gdy okaże się, iż transakcja, której dotyczą, była zgłaszana przez interfejs U2A. Generalną zasadą jest wysyłanie komunikatów zwrotnych w kanał, którym przesłane zostały zgłoszenia raportów. v W opracowaniu. 15
Zakres informacji przechowywanych w KDPW_TR Komunikaty związane z rejestrowaniem transakcji posiadają wyodrębnione sekcje danych: Sekcja 1 - Informacje ogólne, Sekcja 2 - Informacje dotyczące stron transakcji; Sekcja 3 - Wycena i zabezpieczenia; Sekcja 4 - Szczegóły transakcji o Identyfikacja transakcji; o Typ kontraktu; o Dalsze szczegóły transakcji; o Ograniczanie ryzyka / zgłaszanie ryzyka o Rozliczanie o Stopy procentowe (sekcja wypełniana/raportowana dla kontraktów na stopę procentową) o Transakcje walutowe (sekcja wypełniana dla kontraktów na walutę) o Transakcje towarowe (sekcja wypełniana dla kontraktów towarowych) o Opcje (sekcja wypełniana dla kontraktów opcyjnych) Zgodnie z wymogami (Regulatory Technical Standards RTS oraz Implementing Technical Standards - ITS) możliwe jest przekazanie komunikatu zgłoszenia za obydwie strony jednocześnie konstrukcja komunikatu wymaga w takich przypadkach dwukrotnego przekazania danych z sekcji 2 oraz ewentualnie 3 oraz jednokrotnego przekazania danych z sekcji 4. Na podstawie takiego zgłoszenia, w bazie danych KDPW_TR zakładane są dwa nowe rekordy z informacjami odpowiadającymi przekazanym danym, za każdą ze stron odrębnie. W przypadku raportowania za jedną ze stron, dane wszystkich sekcji powinny być wypełnione jednokrotnie, a weryfikacja istnienia raportu złożonego przez drugą stronę kontraktu przeprowadzona zostaje w odrębnym procesie parowania i porównywania raportów (tzw. proces rekoncyliacji), który jest opisany w odrębnym dokumencie Opis procesu rekoncyliacji udostępnianym na stronie internetowej KDPW_TR. W przypadku raportu dwustronnego, każda ze stron kontraktu ma dostęp do informacji zapisanych w jednym raporcie, w którym występuje jako kontrahent (CounterpartyID), natomiast nie widzi raportu zgłoszonego za drugą stronę transakcji, tj. do tego w której występuje jako drugi kontrahent (OtherCounterparty ID). Jedynie podmiot raportujący ma dostęp do informacji w obu zgłoszonych przez siebie rekordach. 16
Identyfikatory transakcji i zgłoszenia w systemie TR Podstawowe identyfikatory transakcji z punktu widzenia Uczestnika KDPW_TR to: Identyfikator komunikatu nadawany przez raportującego - Sender Message Reference (SMR), Identyfikator transakcji - Trade ID (TradId), Identyfikator kontrahenta Counterparty ID (CtrPtyTRId), Identyfikator drugiego kontrahenta Other counterparty ID (OthrCtrPtyTRId). Podstawowe identyfikatory zgłoszenia z punktu widzenia bazy systemu TR to: Identyfikator zgłoszenia (IZ TrnEntryId), unikalny dla danego raportu, Identyfikator rekordu (IR TrnKeyId), unikalny dla każdej mutacji przetworzonej i zapisanej w bazie. Wszystkie powyższe identyfikatory to klucze, czyli pola, których modyfikacje (zmiany) są niedopuszczalne dla żadnego z użytkowników systemu TR. Identyfikatory zgłaszane przez raportującego: Identyfikator komunikatu nadawany przez raportującego - Sender Message Reference (SMR) Identyfikator zgłoszenia przekazanego do TR nadawany przez raportującego w zgłoszeniu. SMR służy raportującemu, jako identyfikator zapisu w historii danej transakcji. TR nie kontroluje unikalności tego identyfikatora. Kod reprezentowany jest poprzez 16 znakowe pole alfanumeryczne. Identyfikator transakcji - Trade ID (TradId) Unikalny identyfikator (UTI) uzgadniany przez obie strony transakcji, zgodnie z dokumentem ESMA Question and Answer (TR question/ answer 18 i 19). TR kontroluje unikalność tego identyfikatora w obrębie klucza transakcji (w którego skład wchodzą TID i identyfikatory stron). 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, skutkuje odrzuceniem komunikatu, nawet, jeśli poprzedni raport został całkowicie anulowany (tzn. przesłano AT=E anulujące całą transakcję). W trakcie kolejnych modyfikacji transakcji identyfikator ten pozostaje niezmienny. Kod reprezentowany jest poprzez 52 znakowe pole alfanumeryczne. 17
Identyfikator kontrahenta - Counterparty ID (CtrPtyTRId) Unikalny identyfikator kontrahenta, docelowo 20 znakowy alfanumeryczny kod LEI vi. Identyfikator drugiego kontrahenta Other Counterparty ID (OthrCtrPtyTRId) Unikalny identyfikator drugiego kontrahenta: 20 znakowy alfanumeryczny kod LEI bądź w przypadku podmiotów niezobowiązanych do raportowania zgodnie z Art. 9 rozporządzenia EMIR, 50 znakowy alfanumeryczny kod klienta. Identyfikatory nadawane przez system TR Identyfikator rekordu (IR) [TrnKeyId] Unikalny identyfikator rekordu w bazie danych nadawany wewnętrznie przez system TR każdemu zgłoszeniu/mutacji raportu. Nie jest on prezentowany podmiotom, w szczególności podmiotowi raportującemu. Identyfikator zgłoszenia (IZ) [TrnEntryId] Identyfikator zgłoszenia transakcji jest kodem nadawanym zgłoszeniu, niezmiennym w trakcie życia transakcji i w ramach kolejnych jego mutacji. Jest on nadawany wewnętrznie przez system TR. Nie jest on prezentowany podmiotom, w szczególności podmiotowi raportującemu. Kluczowe daty związane z procesem raportowania W procesie raportowania istotne są następujące daty: Czas zaraportowania (Reporting timestamp) - data i czas przekazania raportu do KDPW_TR, wartość niepochodząca bezpośrednio z komunikatu, lecz z systemu TR i oznaczająca datę i czas przyjęcia komunikatu do kolejki MQ; Czas utworzenia raportu (Creation timestamp) - data i czas utworzenia raportu przez raportującego. Data ta nie jest obowiązkowa w komunikacie i nie jest wykorzystywana do jego przetwarzania przez Repozytorium; Data i czas wyceny (Valuation timestamp) - data i czas wyceny; Data i czas zawarcia transakcji (Execution timestamp); vi Do czasu wdrożenia przez ESMA bezwzględnego wymogu identyfikacji za pomocą kodów LEI, dopuszcza się użycie kodu klienta. 18
Data wejścia w życie (Effective date) - data wejścia w życie obowiązków wynikających z kontraktu; Data zapadalności (Maturity date) - data wygaśnięcia zgłaszanego kontraktu. W polu tym nie zgłasza się wcześniejszego rozwiązania kontraktu; Data rozwiązania (Termination date) - data wcześniejszego rozwiązania zgłaszanego kontraktu; Data obowiązywania (Eligibility date) - data obowiązywania zapisu dotyczącego transakcji. Pole niewyszczególnione w standardach technicznych, data określająca od którego dnia obowiązują dane zawarte w przesłanym do systemu KDPW_TR zgłoszeniu; w przypadku niektórych typów zgłoszeń uznaje się jej tożsamość z elementami charakterystyki transakcji; Data rozrachunku (Settlement date) - data rozrachunku instrumentu bazowego. W bazie repozytorium zakłada się, iż w komunikacie w dedykowanym polu, uczestnicy mogą raportować kolejne daty rozrachunku składając kolejne zgłoszenia, każda z kolejnych dat zostaje zachowana w bazie danych repozytorium. Identyfikatory podmiotów stosowane w KDPW_TR Kod wystawcy komunikatu Kod odbiorcy komunikatu Kod identyfikacyjny podmiotu dokonującego zgłoszenia (Reporting entity ID) Kod identyfikacyjny kontrahenta (Counterparty ID) Kod identyfikacyjny drugiego kontrahenta (ID of the other counterparty) Kod identyfikacyjny maklera (Broker ID) Kod identyfikacyjny członka rozliczającego (Clearing member ID) Kod identyfikacyjny beneficjenta (Beneficiary ID) Kod wystawcy komunikatu Kod wystawcy komunikatu komunikacyjny, 4 znakowy alfanumeryczny kod podmiotu raportującego, wykorzystywany do właściwej adresacji przesyłki zgodnie z przyjętymi zasadami obsługi komunikatów w KDPW. W przypadku komunikatów przekazywanych od uczestników raportujących bezpośrednio kanałem MQ jest to kod skojarzony z wydanym certyfikatem. W komunikatach wysyłanych z TR do uczestników raportujących umieszczany jest kod identyfikujący Repozytorium (R001). 19
Kod odbiorcy komunikatu Kod odbiorcy komunikatu komunikacyjny, 4 znakowy alfanumeryczny kod, wykorzystywany do właściwej adresacji przesyłki zgodnie z przyjętymi zasadami obsługi komunikatów w KDPW. W przypadku komunikatów przekazywanych do TR pole powinno zawierać kod Repozytorium (R001). W komunikatach wysyłanych z TR do uczestników raportujących umieszczany jest komunikacyjny kod identyfikujący uczestnika raportującego. Kod identyfikacyjny podmiotu dokonującego zgłoszenia (Identyfikator TR wystawcy komunikatu - TRRprtId). Podmiot raportujący musi być zarejestrowany w bazach TR w jednym z dostępnych typów uczestnictwa. Podczas konfiguracji uczestnika raportującego w systemie podawany jest kod LEI, który jest polem obowiązkowym i jedynym dopuszczalnym identyfikatorem w każdym komunikacie przesyłanym przez uczestnika. Jest to 20 znakowy kod alfanumeryczny. Na podstawie tego kodu, w złożeniu z kodem kontrahenta (Counterparty ID) przeprowadzana jest weryfikacja uprawnień związanych z przekazywaniem raportów do Repozytorium. Jeśli raport wysyłany jest we własnym imieniu (GUR lub ZUR) pole to powinno być zgodne z kodem kontrahenta (Counterparty ID). Kod ten w historii transakcji może ulec zmianie jedynie w przypadku zmiany uczestnika raportującego. Kod identyfikacyjny kontrahenta (Counterparty ID) Niepowtarzalny kod identyfikujący kontrahenta będącego stroną kontraktu, zgodny z RTS/ ITS (docelowo 20 znakowy alfanumeryczny kod LEI vii ). Pole to określa stronę transakcji i może być zgodne z kodem uczestnika w typie GUR lub ZUR, jeśli ten raportuje za siebie. Identyfikator ten wchodzi w skład klucza transakcji (wraz z identyfikatorem drugiego kontrahenta i numerem TradId). Zawartość pola nie może być modyfikowana w trakcie obowiązywania transakcji od jej zgłoszenia do wygaśnięcia/ terminacji. Wyjątkiem jest zmiana identyfikatora stosowanego tymczasowo do oznaczenia strony transakcji na kod LEI viii. Kod identyfikacyjny drugiego kontrahenta (ID of the othercounterparty) vii Do czasu wdrożenia przez ESMA bezwzględnego wymogu identyfikacji za pomocą kodów LEI, dopuszcza się użycie kodu klienta. viii Zastrzeżenie: Q&A TR Q40 jeśli wdrożone zostanie rozwiązanie zaproponowane przez ESMA, wówczas identyfikator kontrahenta będzie modyfikowalny również w przypadku fuzji lub przejęcia podmiotu. 20
Niepowtarzalny kod identyfikujący drugiego kontrahenta kontraktu, zgodny z RTS/ ITS (kod LEI lub kod klienta dopuszczony w przypadku osób fizycznych nieprowadzących działalności gospodarczej). Pole to określa drugą stronę transakcji. Pole wchodzi w skład klucza transakcji (wraz z identyfikatorem kontrahenta i numerem TradId). Zawartość pola nie może być modyfikowana w trakcie obowiązywania transakcji od jej zgłoszenia do wygaśnięcia/ terminacji. Wyjątkiem jest zmiana identyfikatora stosowanego tymczasowo do oznaczenia strony transakcji, na kod LEI. Kod identyfikacyjny maklera (Broker ID) Jeżeli makler działa jako pośrednik kontrahenta dokonującego zgłoszenia, nie stając się przy tym kontrahentem, kontrahent dokonujący zgłoszenia określa tego maklera za pomocą niepowtarzalnego kodu w polu BrokerId. Kod ten nie podlega uzgodnieniu z drugą stroną transakcji, jest wykorzystywany jedynie jako charakterystyka transakcji. Zawartość pola może być modyfikowana w trakcie obowiązywania transakcji od jej zgłoszenia do wygaśnięcia/ terminacji. Poprawny kod identyfikujący maklera to kod LEI. Kod identyfikacyjny członka rozliczającego (Clearing member ID) Jeżeli kontrahent dokonujący zgłoszenia nie jest członkiem rozliczającym, w tym polu wskazuje się niepowtarzalny kod członka rozliczającego transakcję. Kod ten nie podlega uzgodnieniu z drugą stroną transakcji, wykorzystywany jest jedynie jako charakterystyka transakcji. Zawartość pola może być modyfikowana w trakcie obowiązywania transakcji od jej zgłoszenia do wygaśnięcia/ terminacji. Poprawny kod identyfikujący członka rozliczającego to kod LEI. Kod identyfikacyjny beneficjenta (Beneficiary ID) Strona będąca podmiotem praw i obowiązków wynikających z kontraktu raportowana jest w polu BnfcryId. Kod ten nie podlega uzgodnieniu z drugą stroną transakcji, wykorzystywany jest jedynie jako charakterystyka transakcji. Zawartość pola może być modyfikowana w trakcie obowiązywania transakcji od jej zgłoszenia do wygaśnięcia/ terminacji. 21
Kontrola rodzajów zmian Statusy wpisów mutacji Identyfikator rekordu TrnEntryId (IR) Każdy raport przesłany do KDPW_TR, który poprawnie przejdzie wszystkie kontrole, skutkuje powstaniem w bazie danych: jednego (w przypadku zgłoszeń jednostronnych) lub dwóch (w przypadku zgłoszeń dwustronnych), zapisów. Każdy nowy zapis transakcji w bazie TR otrzymuje unikalny identyfikator transakcji (TrnEntryId) oraz unikalny identyfikator rekordu (TrnKeyId), a kolejne raporty modyfikacje raportu, zapisywane są pod tym samym identyfikatorem TrnEntryId, otrzymując nowe TrnKeyId. Obydwa te identyfikatory służą jedynie do wewnętrznych procesów TR i nie są udostępniane podmiotom raportującym. Każde zgłoszenie (rekord) w bazie danych TR posiada przyporządkowaną datę obowiązywania EligDt, która w bazie zapisywania jest jako okres obowiązywania od MXDateFrom do MXDateTo. W bazie danych TR, każdy rekord posiada dwa statusy: RecordState (RS) oraz EntryState (ES), w których przechowywana jest informacja o aktywności i obwiązywaniu danego rekordu. Każdy rekord transakcyjny (mutacja) w bazie TR posiada swój status (RS), który może przyjąć jedną z wartości: A aktywny; N nieaktywny; E usunięty (w wyniku przesłania AT = E). Status zapisu EntryState (ES) może przyjmować wartości: A zapis obowiązujący; C - zapis nieobowiązujący. W związku z dopuszczeniem możliwości częściowej terminacji oraz wprowadzeniem automatycznego wygaszania transakcji, informacja o statusie rekordu udostępniania jest uczestnikom. Informacje o raportach dostępne są w interfejsie w 3 zakładkach: - Active reports - prezentuje rekordy aktywne (o statusach A ), - Non-active reports - prezentuje rekordy nieaktywne (o statusach N ), - Deleted reports - prezentuje rekordy anulowane (o statusach E ). 22
Zakres danych prezentowanych w zakładce Deleted reports zostaje ograniczony do pól: TradId, Counterparty ID, Other Counterparty ID. Przesłanie anulacji (AT=E) do transakcji przez jedną z dwóch stron kontraktu powoduje blokadę raportu drugiej strony, tzn. jakiekolwiek modyfikacje tego raportu nie są możliwe. Raporty zablokowane można jedynie anulować (AT=E). W komunikatach trar.rqs.001.02, trar.sts.001.02 i trar.ntf.001.01 informacja o statusie transakcji prezentowana jest w polu Status rekordu, a komunikat trar.rqs.001.02 pozwala na wybór transakcji aktywnych/nieaktywnych czyli odpytywanie wg statusu rekordu. RS ES Status A A Rekord aktywny i obowiązujący. Te zapisy widoczne są w zakładce Active reports oraz udostępniane uczestnikom i nadzorcom. N A Rekord nieaktywny i obowiązujący. Powstaje po AT=T, Z, i C (całkowitym) oraz dla AT=N w backloadingu. Zapisy widoczne dla użytkowników KDPW_TR w zakładce Non-active reports. N C Rekord nieaktywny, nieobowiązujący. Zapis powstaje po nadpisaniu nieaktywnego rekordu np. po przesłaniu AT=M z pustą datą terminacji do transakcji sterminowanej. A C Rekord aktywny, ale nieobowiązujący. Zapis o takim statusie jest niewidoczny dla uczestników i nadzorców. Powstaje w wyniku nadpisania danej mutacji przez kolejny wpis na tą samą datę. E C Rekord usunięty (błędny). Zapis niewidoczny dla uczestników i nadzorców. Powstaje w wyniku przesłania AT=E do danej transakcji dla wszystkich mutacji usuniętych. E A Rekord usunięty i obowiązujący. Tym statusem oznacza się mutację AT=E. Zapisy widoczne dla użytkowników w zakładce Deleted Reports. Rodzaje zmian Każdy rodzaj zmian (AT) upoważnia do zarejestrowania ściśle określonych zmian/informacji. Kontrole funkcjonujące w tym zakresie opisane zostały w komunikatach xml, słownikach, zasadach wypełniania komunikatu trar.ins.001.xx oraz tabeli walidacyjnej opublikowanej przez ESMA. W bazie Repozytorium podczas zapisu raportu przesłanego przez raportującego zachowywane są informacje o: czasie przesłania raportu CreDtTm (Reporting Timestamp) 23
czasie dokonania zapisu MXCreateDate, ID przekazującego komunikat, na podstawie którego dokonywany jest zapis - kod identyfikacyjny raportującego (TRRprtId). Ponadto w bazach TR zapisywane są następujące dodatkowe informacje: kanał wejścia komunikatu (A2A/U2A), oznaczenie terminowości zgłoszenia (RptOverdue: flaga Y/N), oznaczenie, czy zgłaszany raport wynika z obowiązku backloading u (BckldgInd: flaga Y/N, w przypadku braku flagi uznaje się, że raport nie wynika z backloading u). Edytowanie transakcji za pośrednictwem interfejsu WWW możliwe jest po odszukaniu w odpowiedniej zakładce transakcji podlegającej modyfikacji. W tym celu udostępnione są narzędzia umożliwiające filtrowanie transakcji po interesujących użytkownika polach - TRN, TID, data obowiązywania, rodzaj zmiany, itp. Szczegółowe zasady działania interfejsu graficznego opisane zostały w dokumencie Instrukcja użytkownika (U2A). Zasady wypełniania komunikatu dla poszczególnych rodzajów zmian (AT) zostały szczegółowo opisane w dokumentach Dane słownikowe dopuszczalne dla komunikatów KDPW_TR oraz Specyfikacja Komunikatu Zgłoszenia do Repozytorium trar.ins.001.xx. Czyszczenie (usuwanie) zaraportowanych informacji w rodzajach zmiany M i V Usuwanie wartości odbywa się poprzez rodzaj zmiany M (lub V). W interfejsie umożliwia to specjalny checkbox umieszczony w odpowiedniej sekcji lub przy polu, natomiast w komunikacie służy do tego celu atrybut DeltnInd=Y wskazany dla odpowiedniego tagu, przy czym wartość podana w tagu musi spełniać warunki kontroli, tzn. tag nie może być pusty. Czyszczenie danych dotyczy tylko wartości, które nie są obowiązkowe (szczegółowy spis pól dopuszczalnych do czyszczenia dostępny jest w dokumencie Wypełnianie komunikatów ). Przykład: <CollPrtfl DeltnInd= Y >2500041</CollPrtfl> W efekcie, w polu CollPrtfl (kod portfela zabezpieczeń) pojawi się wartość pusta. Podanie takiego atrybutu dla pól, których czyszczenie nie jest możliwe skutkuje odrzuceniem komunikatu. 24
Funkcja czyszczenia udostępniona została dla komunikatu trar.ins.001.02 (AT=M lub AT=V) oraz komunikatów trar.ins.002.02, trar.ins.003.02, przy czym działanie tej funkcji dla komunikatów raportowania zbiorczego opisane jest w dalszej części materiału. Raportowanie zmian/aktualizacji w rodzajach zmian M, V, C (częściowe) 1) Data Eligibility Date jest wymagana w każdym komunikacie. 2) Obsługiwane są następujące przypadki aktualizacji danych: Dopisanie nowych mutacji po już istniejących, tzn. aktualizacja danych od daty większej niż ostatni obowiązujący dla danej transakcji wpis o statusie = A; Nadpisanie istniejącej historii, czyli uzupełnienie danych niejako w środku życia transakcji aktualizacja danych w zakresie od daty większej lub równej dacie pierwszego obowiązującego zapisu dla danej transakcji i mniejszej lub równej dacie ostatniego obowiązującego wpisu (komunikaty z AT=M, V lub C częściowe); przesłanie komunikatu AT=M, V lub C częściowe na daną datę obowiązywania aktualizuje rekord obowiązujący od podanej w komunikacie daty do końca obowiązywania danego rekordu; Zmiana (za pomocą AT=M) Execution Timestamp i dopisanie historii obowiązującej przed zaraportowaną, tzn. aktualizacja danych od daty mniejszej niż minimalna data obowiązywania historii dla danej transakcji (dla wszystkich obowiązujących wpisów o statusach = A); Aktualizacja (za pomocą AT=M) danych zaraportowanych w polach: Execution timestamp, Underlying technical, Compression, Maturity date oraz Counterparty side od minimalnej daty obowiązywania historii dla danej transakcji (dla wszystkich obowiązujących wpisów o statusach = A); Szczegółowe działania na mutacjach i datach opisane są w załączniku do niniejszego materiału na przykładach. 25
AT=N (New) Komunikat rejestracji (N) wykorzystywany jest tylko i wyłącznie do zarejestrowania nowej transakcji w Repozytorium. W ramach tego komunikatu podmiot raportujący obowiązany jest przekazać komplet danych wymaganych do rejestracji transakcji. Po przejściu przez kontrole, na podstawie komunikatu, system KDPW_TR rejestruje nową transakcję i wysyła potwierdzenie tego faktu do raportującego zgodnie z konfiguracją raportów zwrotnych. Wymagalność wypełnienia poszczególnych pól wynika wprost z zasad walidacji level 1 i 2 opublikowanych przez ESMA. Szczególnym przypadkiem jest raport backloading owy o kontrakcie nieaktywnym, w którym umożliwia się wypełnienie daty terminacji i którego kontrola opisana została szczegółowo w dokumencie Kontrola Formalna i Merytoryczna. W wyniku AT= N powstaje mutacja ze statusami wpisu: RS = A aktywny lub N nieaktywny (dla backloadingu z wypełnioną datą terminacji); ES = A zapis obowiązujący. Mutacja powstała w rodzaju zmiany N nie może być nadpisywana rodzajem zmiany N. Skorygowanie błędnych informacji w AT=N umożliwia rodzaj zmiany AT=M, a w przypadku stwierdzenia że transakcja o podanym UTI (TradId) nie miała miejsca, można do niej wysłać AT=E, co skutkuje usunięciem wszystkich mutacji powstałych dla danego identyfikatora transakcji (TrnEntryId) i uniemożliwia ponowne przesłanie raportu z tym samym UTI (kluczem transakcji). W interfejsie U2A zgłoszenie transakcji odbywa się za pośrednictwem dostępnego formularza odpowiadającego strukturze bazy transakcji KDPW_TR, bądź za pomocą funkcji Import XML, która pozwala zaimportować do KDPW_TR plik XML z rodzajem zmiany N. W zakładce Reporting service' udostępniona została funkcja zgłoszenia transakcji, gdzie po wyborze opcji Action Type New pojawia się formularz służący do wprowadzenia szczegółów transakcji. Po wprowadzeniu wartości, użytkownik zatwierdza zgłoszenie. W przypadku pojawienia się błędu merytorycznego w komunikacie, w zakładce TR Communication udostępniany jest komunikat zwrotny o statusie ERRO, natomiast brak błędów potwierdza komunikat o statusie PACK. W przypadku pozytywnego przetworzenia, transakcja zostaje zarejestrowana w TR. AT=M (Modify) Komunikat zmiany szczegółów informacji (M) wykorzystywany jest do zarejestrowania zmian w już zgłoszonej do KDPW_TR transakcji. Z powyższego wynika, że transakcja, której zmiana jest 26
zgłaszana, musi znajdować się już w systemie TR (musi być wcześniej zarejestrowana przy pomocy zgłoszenia z rodzajem zmiany N). W ramach komunikatu AT=M, podmiot raportujący zobowiązany jest przekazać klucz transakcji pozwalający na identyfikację odpowiedniej, poddawanej modyfikacji transakcji oraz datę obowiązywania zmian. W komunikacie AT=M podawane są wszystkie pola, które mają być zmodyfikowane. Wartości pól dotąd wypełnionych, a w komunikacie pominiętych nie są zmieniane. Jeśli w komunikacie wystąpi dla modyfikowalnego pola atrybut DeltnInd=Y, wówczas wartość uprzednio w tym polu przekazana jest czyszczona. Próba wyczyszczenia pól obowiązkowych dla raportu skutkuje odrzuceniem komunikatu. W przypadku modyfikacji pól, dla których zdefiniowane zostały kontrole warunkowe opisane w tabeli walidacji level 2 ESMA, niezbędne jest podanie kompletu pól składającego się na tę walidację np. modyfikacja pola PrdctId1 wiąże się z koniecznością wypełniania pola VenueOfExc, Txnm oraz sekcji obowiązkowej wynikającej ze sposobu zdefiniowania pola PrdctId1. W ramach rodzaju zmiany M można dokonać szerokiego zakresu zmian z wyłączeniem: Pól związanych z wyceną i zabezpieczeniami w komunikacie nie może wystąpić sekcja Informacje o wycenie i zabezpieczeniach, w przypadku jej wypełnienia komunikat taki zostanie odrzucony; modyfikacje pól z tej sekcji umożliwia rodzaj zmiany V. Identyfikatorów wykorzystywanych w RT: Counterparty ID, ID of the other counterparty z zastrzeżeniem, iż pole to może się zmienić w szczególnym przypadku: modyfikacji kodu innego niż LEI na kod LEI za pośrednictwem dedykowanego komunikatu trar.ins.006.01, TradID oraz wszystkich innych pól wskazanych w dokumencie Sposób i zakres wypełniania danych dla poszczególnych rodzajów zmian (AT) jako I-ignorowane. AT=M umożliwia modyfikacje bieżące, historyczne dla całej historii transakcji (w zakresie danych o ExecDtTm, CtrPtySd, TechUndrlyg, Cmprssn oraz MtrtyDt) oraz historyczne dla wycinka historii transakcji (obowiązujące od raportowanej daty EligDt do daty obowiązywania zapisanej już w bazie mutacji, której data obowiązywania jest większa niż EligDt raportowanej modyfikacji). 27
Pomyłkę w kluczu transakcji, należy zgłosić za pomocą AT=E, co spowoduje usunięcie transakcji wraz z całą jej historią. Nowa, poprawna transakcja powinna dostać nowy identyfikator UTI (TradId) uzgodniony pomiędzy stronami. W wyniku przysłania AT =M powstaje mutacja ze statusami wpisu: RS = A aktywny lub N nieaktywny (dla transakcji sterminowanych); ES = A - zapis obowiązujący. W przypadku, gdy M jest nadpisaniem już funkcjonującej mutacji (ta sama data obowiązywania EligDt dla danego TrnEntryId) wówczas nadpisywana mutacja uzyskuje statusy wpisu: RS = A - aktywny; ES = C - zapis nieobowiązujący. Wprowadzając zgłoszenie należy podać unikalny SMR komunikatu, który zostanie przypisany do AT=M. Podanie SMR umożliwi odwołanie do zgłoszonego raportu w zwrotnym komunikacie statusowym. W przypadkach, gdy uczestnik raportujący zgłosił transakcję w imieniu obu stron, modyfikacji może podlegać wybrany raport jednej strony (jeśli podano sekcję Referencje), bądź dwa raporty za obie strony kontraktu (jeśli sekcja Referencje występuje dwukrotnie). Możliwe jest również zbiorcze modyfikowanie danych teleadresowych danego kontrahentaix. W takich sytuacjach zmiany zgłoszone przez danego raportującego na danym kodzie kontrpartnera prowadzić będą do dopisania zgłaszanych zmian dla wszystkich aktywnych transakcji zaraportowanych przez danego raportującego. W celu obsługi tego procesu powołany został dedykowany komunikat: Raportowanie zmian danych kontrahenta (trar.ins.005.xx). Wszystkie nowe mutacje powstałe na skutek zastosowania komunikatu zbiorczego będą miały datę obowiązywania wskazaną w komunikacie zbiorczym oraz wskazany tam SMR. AT=E (Error) Komunikat anulowania zgłoszenia (E) wykorzystywany jest do usunięcia zarejestrowanej w bazie KDPW_TR transakcji. Wymagane jest podanie w referencjach klucza transakcji (Counterparty Id+ Other Counterparty Id +TradId); AT=E usuwa całą historię i uniemożliwia ix W opracowaniu. 28
ponowne zaraportowanie raportu o takim samym kluczu. Restrykcja ta dotyczy obu stron transakcji. Usunięcie transakcji oznacza, że w bazie KDPW_TR dopisany zostanie rekord z AT=E, o statusie E/A z datą obowiązywania równą dacie obowiązywania usuwanego AT=N, zaś wszystkie mutacje dla danej transakcji opatrzone zostaną statusami E/C. Anulowana transakcja jest widoczna dla uczestników Repozytorium w zakładce Deleted reports. Anulowanie transakcji przez jedną ze stron powoduje blokadę raportowania jakichkolwiek zmian poza AT=E dla drugiej strony. Informacja o zablokowanych raportach (tzn. anulowanych przez drugą stronę) przesyłana jest do raportującego, za pośrednictwem komunikatu notyfikacyjnego x o odpowiednio wypełnionych wartościach w polach Status Code/Reason code. AT=C (Termination) W przypadku terminacji raportowane są wolumen i wartość kontraktów pozostające po wygaszeniu części bądź wszystkich kontraktów, a nie terminowane wolumen i wartość kontraktów. DEFINICJE: Terminacja częściowa zakończenie aktywności części kontraktów transakcji/pozycji w dniu terminacji podanej w polu Termination Date; Terminacja całkowita - zakończenie aktywności wszystkich kontraktów transakcji/pozycji w dniu terminacji podanej w polu Termination Date. Terminację (AT=C) uznajemy za częściową, jeśli w polach Notional Amount i Quantity podane są wartości większe niż 0. Taki zapis otrzymuje status A/A. Terminację (AT=C) uznajemy za całkowitą, jeśli w polach Notional Amount i Quantity podane są wartości równe 0. Taki zapis otrzymuje status N/A. WYMAGANIA: W obu przypadkach podanie w referencjach klucza transakcji (Counterparty Id+ Other Counterparty Id +TradId) oraz pól Notional Amount i Quantity oraz daty terminacji jest obowiązkowe, przy czym przeprowadzane są następujące kontrole: x W opracowaniu. 29
1. Termination Date =EligDt; 2. jeśli w poprzednim raporcie data Maturity Date jest podana, to Termination Date musi być mniejsza niż lub równa podanej Maturity Date; w przeciwnym przypadku komunikat jest odrzucany; 3. 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 DeltnInd=Y, to komunikat jest odrzucany. Wyjątek: jeśli wartość w polu Quantity=1 w mutacji obowiązującej w dniu terminacji przed przesłaniem raportu o terminacji, wówczas dopuszcza się raport częściowej terminacji, w którym Quantity=1; 4. komunikat, w którym tylko jedna z wartości w polach Notional Amount i Quantity jest równa zero zostanie odrzucony; 5. jeśli w zgłoszeniu wartość wskazana w polu Termination Date jest późniejsza niż data raportowania, zgłoszenie zostaje odrzucone przez system TR. Uwaga: Terminacja zbiorcza zawsze traktowana jest jak terminacja całkowita. Raport o terminacji częściowej na datę obowiązywania większą lub równą dacie realizacji transakcji powoduje: w przypadku AT=C częściowego historycznego tj. z datą obowiązywania wcześniejszą aniżeli ostatnia obowiązująca dla danej transakcji mutacja, dodanie rekordu obowiązującego od daty podanej w raporcie do dnia poprzedzającego datę obowiązywania kolejnej mutacji dla danej transakcji z uwzględnieniem zmian w polach Notional amount oraz Quantity, które są efektem AT=C częściowego. Jeśli wartości Notional amount oraz Quantity modyfikowane za pomocą AT=C są większe aniżeli obowiązujące w dotychczas zaraportowanej na datę AT=C częściowego mutacji, komunikat taki zostanie przez system odrzucony. Jeśli zmiany wynikające z AT=C częściowego miałyby obowiązywać na dalszej historii transakcji (już zaraportowanej), powinny zostać zaraportowane przez podmiot raportujący za pomocą oddzielnego komunikatu AT=M na każdą datę obowiązywania kolejnych mutacji dla transakcji; w przypadku AT=C częściowego bieżącego, tj. z datą obowiązywania większą lub równą ostatniej obowiązującej dla danej transakcji mutacji, dodanie nowej obowiązującej mutacji dla danej transakcji. Raport o terminacji częściowej na datę obowiązywania mniejszą niż data realizacji transakcji skutkować będzie odrzuceniem komunikatu. 30
Raport o terminacji całkowitej (wyzerowanie wartości NmnlAmt oraz Qty) na datę obowiązywania większą lub równą dacie realizacji transakcji skutkować będzie dopisaniem na tę datę rekordu AT=C oraz wygaszeniem wszystkich mutacji obowiązujących od daty obowiązywania terminacji. Jednocześnie, wartości w polach Notional Amount i Quantity są przepisywane z ostatniej obowiązującej mutacji (czyli niezerowe). Raport o terminacji całkowitej na datę obowiązywania mniejszą niż data realizacji transakcji skutkować będzie odrzuceniem komunikatu. W wyniku przesłania AT= C częściowego powstaje rekord ze statusami wpisu: RS = A aktywny; ES = A zapis obowiązujący. W wyniku przesłania AT= C całkowitego powstaje rekord ze statusami wpisu: RS = N nieaktywny; ES = A zapis obowiązujący. 31
AT=Z (Compression) Kompresja rozumiana jest, jako redukcja portfela kontraktów/transakcji. AT=Z oznacza zamknięcie transakcji i powstanie pozycji, dlatego w przypadku raportowania kompresji należy wprowadzić wartości zerowe w polach Quantity oraz Notional Amount oraz podać Termination Date, która co do daty musi być równa dacie obowiązywania danego zgłoszenia. Pozycja powstała po AT=Z powinna być zaraportowana jako AT=N ze znacznikiem kompresji= Y oraz EligDt= Execution Timestamp = data kompresji. WYMAGANIA: Wymagane jest podanie w referencjach klucza transakcji (Counterparty Id+ Other Counterparty Id +TradId) oraz daty/dat obowiązywania, daty terminacji i wyzerowanie wartości przekazanych w polach Notional Amount i Quantity, przy czym przeprowadzane są następujące kontrole: 1. jeśli w poprzednim raporcie data Maturity Date jest podana, to Termination Date musi być mniejsza niż lub równa podanej Maturity Date; 2. jeśli wartości raportowane w polach Notional Amount i Quantity są większe niż zero a data terminacji nie jest oznaczona atrybutem DeltnInd=Y, to komunikat jest odrzucany; Raport o kompresji na datę obowiązywania większą lub równą dacie realizacji transakcji skutkować będzie dopisaniem rekordu AT=Z oraz wygaszeniem wszystkich mutacji obowiązujących od daty obowiązywania kompresji. Jednocześnie, wartości w polach Notional Amount i Quantity są przepisywane z ostatniej obowiązującej mutacji (czyli niezerowe). Raport o kompresji na datę obowiązywania mniejszą niż data realizacji transakcji skutkować będzie odrzuceniem komunikatu. W wyniku przesłania AT= Z powstaje rekord ze statusami wpisu: RS = N nieaktywny; ES = A zapis obowiązujący. 32
AT=V (Valuation and collateral update) W ramach rodzaju zmiany V można dokonać aktualizacji danych nt. zabezpieczenia i/lub wyceny danej transakcji. Wymagane jest podanie w referencjach klucza transakcji (Counterparty Id+ Other Counterparty Id +TradId) oraz daty/dat obowiązywania, przy czym następuje kontrola Valuation Timestamp=EligDt (co do daty). Na skutek zaraportowania rodzaju zmiany V w bazie danych TR zmianie ulec mogą jedynie wartości wyceny oraz zabezpieczeń wykazane w polach sekcji 3 Informacje o wycenie i zabezpieczeniach. Wartości podawane w sekcjach 2 i 4 komunikatu spowodują jego odrzucenie przez system. Ponadto w ramach rodzaju zmiany V sprawdzane jest istnienie późniejszych wycen/ zabezpieczeń - każdorazowo, gdy w przypadku obsługi zgłoszenia modyfikacji wykryte zostaną zapisy dla transakcji z późniejszą datą obowiązywania (EligDt), system TR umożliwia przesłanie wyceny/ zabezpieczenia ze wskazaną datą obowiązywania, niemniej zmiany te obowiązują tylko i wyłącznie do daty o dzień wcześniej niż kolejna (później obowiązująca) mutacja. W wyniku przysłania AT =V powstaje mutacja ze statusami wpisu: RS = A - aktywny; ES = A - zapis obowiązujący. W przypadku, gdy V jest nadpisaniem już funkcjonującej mutacji (ta sama data obowiązywania EligDt dla zabezpieczenia bądź ta sama data wyceny dla wyceny) wówczas nadpisywana mutacja uzyskuje statusy wpisu: RS = A - aktywny; ES = C - zapis nieobowiązujący. Identyfikacja portfela, którego dotyczy aktualizacja zabezpieczenia, w przypadku raportowania aktualizacji zabezpieczeń na poziomie portfela: Kod portfela i kod raportującego Identyfikacja klasy instrumentu, której dotyczy komunikat wyceny: 33
Złożenie pól: Taxonomy, Product id 1, Product id 2, Technical underlying (wskazany zestaw pól, wraz z datą wyceny, wykorzystywany jest także do powiązania wyceny z konkretnymi zapisami dotyczącymi transakcji). AT=O (Other) xi Przesłanie przez PUR a zgłoszenia o konieczności korekty danych realizowane będzie przez wygenerowanie za pomocą formatki zamieszczonej w interfejsie, komunikatu trar.ins.001.xx 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.001.xx, 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ą oznaczenia raportu, jako 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. W formatce dotychczasowa opcja Action type Error umieszczona w zakładce Reporting service zostanie zastąpiona opcją Action type O Data Correction. Po naciśnięciu tej opcji, tak jak dotychczas wyświetlona zostanie lista raportów dostępnych dla uczestnika a na dole przycisk Error zamieniony zostanie na Data Correction. Po wybraniu odpowiednego raportu i naciśnięciu przycisku Data Correction system pokaże okienko, w którym uczestnik powinien nadać SMR generowanemu komunikatowi. Po naciśnięciu OK system wygeneruje mutację AT=O, zgodnie z powyżej opisanymi zasadami. Zgłoszenie poprawki danych przez raportującego spowoduje zapisanie nowych danych w bazie RT ze statusem EntryState=A oraz flagą oznaczenia korekty Y. Opcjonalnie: system xi W opracowaniu. 34