CZĘSTO ZADAWANE PYTANIA (FAQ) Pytania i odpowiedzi podzielone są na następujące kategorie: Kwestie regulacyjne pytania 1-18 Raportowanie transakcji do KDPW_TR pytania 19-42 Opłaty pytania 43-45 Identyfikatory używane w procesie raportowania pytania 46-51 Proces rekoncyliacji danych pytania 52-54 Pytania dotyczące kwestii regulacyjnych 1. Z jakich regulacji wynika zobowiązanie do raportowania transakcji pochodnych? Obowiązek zgłaszania szczegółowych informacji na temat każdego zawartego kontraktu pochodnego wynika bezpośrednio z Art. 9 rozporządzenia Parlamentu Europejskiego i Rady (UE) NR 648/2012 z dn. 4 lipca 2012 r. w sprawie instrumentów pochodnych będących przedmiotem obrotu poza rynkiem regulowanym, kontrahentów centralnych i repozytoriów transakcji (rozporządzenie EMIR). Pełna treść rozporządzenia dostępna jest na stronach internetowych EUR-Lex oraz ESMA. Linki: http://eur-lex.europa.eu/lexuriserv/lexuriserv.do?uri=oj:l:2012:201:0001:0059:pl:pdf http://www.esma.europa.eu/page/european-market-infrastructure-regulation-emir Również na stronie www.knf.gov.pl znajduje się sekcja poświęcona rozporządzeniu EMIR: http://www.knf.gov.pl/o_nas/wspolpraca_miedzynarodowa/unia/regulacje_i_dokumenty_powiazane/emir.html 2. Czy poza rozporządzeniem EMIR funkcjonują inne akty prawne określające zakres i sposób raportowania? Tak, są to tzw. standardy techniczne rozporządzenia ITS/ RTS, czyli rozporządzenia wykonawcze i implementacyjne, które określają zakres oraz format podstawowych danych, jakie powinny być raportowane. Najistotniejsze dla doprecyzowania obowiązku raportowego są: rozporządzenie delegowane nr 148/2013 oraz rozporządzenie wykonawcze nr 1247/2012. 3. Kiedy wszedł w życie obowiązek raportowania? Obowiązek raportowania transakcji pochodnych dla wszystkich klas instrumentów pochodnych wszedł w życie 12 lutego 2014 r. Obowiązek raportowania aktualizacji wycen oraz zabezpieczeń wszedł w życie 11 sierpnia 2014 r. 4. Jakie podmioty zobowiązane są do raportowania transakcji? Do raportowania zobowiązane są wszystkie podmioty prowadzące działalność gospodarczą (przedsiębiorcy), niezależnie od formy prawnej, w jakiej ta działalność jest wykonywana, o ile są stronami transakcji na kontraktach pochodnych zdefiniowanych w rozporządzeniu EMIR. 5. Czy obowiązkowi raportowania podlegają osoby fizyczne prowadzące działalność gospodarczą? Zgodnie ze stanowiskiem Komisji Europejskiej, wyrażonym w dokumencie z dnia 18 grudnia 2013 r. EMIR: Frequently Asked Questions, obowiązki wynikające z art. 9 rozporządzenia EMIR mają zastosowanie również do osób fizycznych prowadzących działalność gospodarczą. 6. Jakie podmioty zwolnione są z obowiązku raportowania? Z obowiązku raportowania transakcji zgodnie z art. 9 rozporządzenia EMIR zwolnione są osoby fizyczne nie prowadzące działalności gospodarczej. Ponadto z obowiązku raportowania aktualizacji wyceny i zabezpieczeń zwolnieni są kontrahenci niefinansowi poniżej progu rozliczania ustalonego na mocy ust. 3 art. 10 rozporządzenie EMIR.
7. Czy obowiązkiem raportowania objęte są transakcje w instrumentach pochodnych zawarte na rynku regulowanym? Tak. Obowiązek raportowania obejmuje wszelkie transakcje w instrumentach pochodnych bez względu na rynek, na jakim zostały one zawarte. 8. Czy biuro maklerskie podlega obowiązkowi raportowania transakcji z rynku regulowanego? Tak. Zarówno w przypadku transakcji własnych jak i transakcji klientów, zgodnie z wytycznymi opublikowanymi przez ESMA w dokumencie Questions and Answers w dniu 20 grudnia 2013 r. biuro maklerskie jest zobowiązane do raportowania zawieranych transakcji pochodnych. Biuro maklerskie może delegować obowiązek raportowania na KDPW_CCP, jak i na inny podmiot świadczący usługi raportowania delegowanego. 9. Które instrumenty pochodne objęte są obowiązkiem sprawozdawczym pod EMIR? Obowiązkiem sprawozdawczym objęte są wszystkie instrumenty finansowe wymienione w sekcji C pkt. 4-10 załącznika I do dyrektywy 2004/39/WE (MiFID) (zgodnie z definicją kontraktu/instrumentu pochodnego zawartą w Art. 2 pkt 5 Rozporządzenia EMIR). 10. Kiedy wszedł w życie obowiązek raportowania wyceny i zabezpieczeń? Obowiązek raportowania wyceny i zabezpieczeń wszedł w życie po upływie 180 dni od momentu wejścia w życie obowiązku raportowego dla danej klasy instrumentów. Oznacza to, że datą wejścia w życie obowiązku jest 11 sierpnia 2014 r. z pierwszymi raportami wymaganymi nie później niż 12 sierpnia 2014 r. wskazującymi stan wyceny i/lub zabezpieczeń na koniec dnia 11 sierpnia 2014 r. 11. Kto jest zobowiązany do raportowania wyceny i zabezpieczeń? Do raportowania wyceny oraz zabezpieczeń zobowiązani są kontrahenci finansowi (FC) oraz kontrahenci niefinansowy, którzy przekroczyli próg wiążący się z obowiązkiem rozliczania (clearing treshold) (NFC+). 12. Kto jest zwolniony z obowiązku raportowania wyceny oraz zabezpieczeń? Obowiązkiem raportowania wyceny oraz zabezpieczeń nie są objęci kontrahenci niefinansowi, którzy nie przekroczyli progu wiążącego się z obowiązkiem rozliczania (clearing treshold) (NFC-). 13. Czy raportowanie transakcji z rynku OTC różni się od raportowania transakcji z rynku regulowanego? Tak. Zgodnie z wytycznymi ESMA przekazanymi w dokumencie Question and Answers raporty przekazywane do TR różnią się w zależności od rynku, na jakim zawierana jest transakcja. Raporty zawierają wprawdzie ten sam zestaw informacji wymaganych w rozporządzeniu EMIR oraz standardach technicznych, jednak odmienny jest zakres podmiotów zobowiązanych do raportowania. Szczegółowe scenariusze wraz ze wskazaniem podmiotów rozumianych jako strony transakcji znajdziecie Państwo w dokumencie Question and Answers część IV oraz V. 14. Czy istnieje obowiązek uczestnictwa w repozytorium? Nie. Podmioty zobowiązane do raportowania mogą raportować transakcje pochodne samodzielnie do wybranego przez siebie, zarejestrowanego przez ESMA repozytorium, bądź wypełniać ten obowiązek za pośrednictwem innego uczestnika raportującego (raportowanie delegowane). W przypadku wyboru KDPW_TR, aby raportować transakcje pochodne samodzielnie, należy uzyskać uczestnictwo w typie GUR lub ZUR. 15. Czy można delegować obowiązek raportowania na KDPW_CCP? Tak. KDPW_CCP może pośredniczyć w raportowaniu transakcji rozliczanych przez Izbę. W takich sytuacjach wymogiem KDPW_CCP jest konieczność dostarczenia wszelkich danych umożliwiających wykonywanie tej usługi. Czyli przekazanie danych zawartych w RTS/ITS charakteryzujących stronę transakcji oraz wskazanie konta rozliczeniowego, którego transakcje mają podlegać raportowaniu przez KDPW_CCP. Więcej szczegółów w zakresie delegowania obowiązku raportowego na KDPW_CCP znajdziecie Państwo on-line na stronie: KDPW_CCP. 16. W jakim terminie należy raportować do repozytorium? Zgodnie z art. 9 pkt. 1 rozporządzenia EMIR, zgłaszanie szczegółowych informacji na temat każdego zawartego kontraktu pochodnego oraz na temat wszelkich zmian lub rozwiązania tego kontraktu powinno odbywać się nie później niż w dniu roboczym następującym po zawarciu, zmianie lub rozwiązaniu kontraktu.
17. Na czym polega backloading? Procedura backloadingu dotyczy raportowania transakcji, które zostały zawarte przed wejściem w życie obowiązku raportowego. Kryteria wyznaczania tych transakcji i terminy zgłoszenia do TR przestawiają się następująco: transakcje, które zostały zawarte przed dniem 16 sierpnia 2012 r. i jednocześnie obowiązujące w tym dniu oraz w dalszym ciągu obowiązujące w momencie wejścia w życie obowiązku raportowego podlegają zaraportowaniu w terminie 90 dni od wejścia w życie obowiązku raportowego; transakcje, które zostały zawarte w dniu 16 sierpnia 2012 r. lub po tym dniu oraz obowiązujące w momencie wejścia w życie obowiązku raportowego podlegają obowiązkowi zaraportowania bez opóźnienia, tj. w dniu wejścia w życie obowiązku raportowego powinny zostać zaraportowane wg stanu na dzień poprzedni (11/02/2014); transakcje, które zostały zawarte w dniu 16 sierpnia 2012 r. lub po tym dniu i które nie obowiązują już w dniu rozpoczęcia dokonywania zgłoszeń lub po tej dacie, są zgłaszane do repozytorium transakcji w terminie 3 lat od daty rozpoczęcia dokonywania zgłoszeń dla danej klasy instrumentów pochodnych. Zgodnie z wskazówkami ESMA (TR Q&A 4 (a)), transakcje, które wygasły przed datą wejścia w życie obowiązku raportowego, powinny być raportowane w swoim stanie finalnym, tj. w stanie obowiązywania na datę przesłania raportu nt. danej transakcji. 18. Czy możliwe jest zaraportowanie transakcji dwukrotnie na bazie tego samego UTI? Nie, nie jest możliwe powtórne przekazanie danych na bazie tego samego klucza transakcji, nawet jeśli uprzednio zgłoszony raport został anulowany. Powyższe założenia wynikają bezpośrednio z wymagań ESMA. Pytania dotyczące raportowania transakcji do KDPW_TR 19. Na czym w praktyce polega raportowanie do RT? Jest to dostarczenie do systemu repozytorium kompletu informacji o transakcji pochodnej (lub informacji o zmianie warunków/charakterystyki transakcji, jej wycenie, itd.) w formie komunikatu xml. Komunikaty z raportami dostarczane są w zależności od preferencji podmiotu raportującego za pośrednictwem aplikacji internetowej (U2A) lub bezpośrednio z serwera na serwer (A2A). 20. Jak zostać uczestnikiem KDPW TR? Podmiot zamierzający uzyskać wybrany status uczestnika Repozytorium Transakcji KDPW_TR (GUR, ZUR lub PUR) składa wniosek o uczestnictwo, zgodny ze wzorem zamieszczonym na stronie internetowej www.kdpw.pl (wzory dokumentów). Do wniosku należy dołączyć dokumenty wskazane w Regulaminie KDPW TR. Po przyjęciu w poczet uczestników (na mocy uchwały Zarządu KDPW S.A.), aby móc raportować należy pobrać, co najmniej jeden, certyfikat U2A umożliwiający dostęp do aplikacji KDPW_TR. Certyfikaty pobierane są przez uczestnika on-line: certyfikat elektroniczny U2A. 21. Kim jest GUR? Generalny Uczestnik Raportujący (GUR), to podmiot uprawniony do przekazywania do repozytorium transakcji raportów o kontraktach w imieniu własnym lub w imieniu innego kontrahenta, w tym raportów o kontraktach, których ten uczestnik nie jest stroną. Uprawnienia GUR-a to: zgłaszanie transakcji do repozytorium; przeglądanie transakcji zgłoszonych przez siebie do repozytorium (niezależnie czy GUR jest ich stroną czy nie); przeglądania wszystkich własnych transakcji zgłoszonych do KDPW TR (niezależnie od tego kto je zaraportował); zgłaszanie konieczności korekty raportu uznanego za błędnie przekazany (niezależnie od tego kto daną transakcję zaraportował); budowanie relacji z KUR-em w celu udostępnienia danych o transakcjach, w którym dany uczestnik jest stroną; 22. Kim jest ZUR? Zwykły Uczestnik Raportujący (ZUR), to podmiot uprawniony do raportowania transakcji, w których jest stroną oznacza to, że może również zaraportować za kontrpartnerów takich transakcji. Uprawnienia ZUR-a to: zgłaszanie transakcji do repozytorium; przeglądanie transakcji zgłoszonych przez siebie do repozytorium; przeglądanie wszystkich własnych transakcji zgłoszonych do KDPW TR (niezależnie od tego kto je zaraportował);
zgłaszanie konieczności korekty raportu uznanego za błędnie przekazany (niezależnie od tego kto daną transakcję zaraportował); budowanie relacji z KUR-em w celu udostępnienia danych o transakcjach, w których dany uczestnik jest stroną. 23. Kim jest PUR? Pośredni Uczestnik Repozytorium (PUR), to podmiot nie będący uczestnikiem raportującym. Raportowanie transakcji w imieniu PUR-a dokonywane jest przez ZUR a lub GUR a. Uprawnienia PUR-a to: przeglądanie wszystkich własnych transakcji zgłoszonych do KDPW TR przez uczestników raportujących; zgłaszanie konieczności korekty raportu uznanego za błędnie przekazany; budowanie relacji z KUR-em w celu udostępnienia danych o transakcjach, w którym dany uczestnik jest stroną. 24. Kim jest KUR? Komercyjny Użytkownik Repozytorium (KUR), to podmiot, który uzyskuje dostęp do transakcji, których stroną jest uczestnik KDPW_TR, na podstawie uzyskanego od tego uczestnika upoważnienia. Użytkownik KUR zobowiązany jest do podpisania umowy w sprawie dostępu do informacji o kontraktach oraz o zachowaniu poufności (wzór dokumentu dostępny jest na stronie WWW link: KUR). 25. Jakie klasy instrumentów można raportować do KDPW TR? Do KDPW_TR można raportować transakcje pochodne dla wszystkich klas instrumentów pochodnych, niezależnie od miejsca zawarcia kontraktu (rynek regulowany lub rynek OTC): Towarowy instrument pochodny (CO); Kredytowy instrument pochodny (CR); Walutowy instrument pochodny (CU); Instrument pochodny na akcje (EQ); Instrument pochodny na stopę procentową (IR); Inny instrument pochodny (OT).. 26. Jakie kanały dostępu zostały przewidziane dla usługi KDPW TR? Z repozytorium można komunikować się za pośrednictwem dwóch kanałów: U2A zapewniającym dostęp do aplikacji internetowej, oferującym graficzny interfejs (wypełnienie formatki) oraz funkcjonalność polegającą na możliwości importu komunikatów z plików zapisanych lokalnie u użytkownika; A2A kanał oparty na kolejce MQ, umożliwiający automatyczną wymianę plików xml poprzez połączenie aplikacjaaplikacja. 27. Dla kogo dedykowany jest kanał U2A, a dla kogo A2A? Kanał U2A jest podstawowym kanałem dostępu, który gwarantuje wszystkim podmiotom możliwość raportowania transakcji w kontraktach pochodnych na dwa sposoby: z wykorzystaniem graficznego interfejsu, w którym bezpośrednio wpisuje się dane kontrahentów i szczegóły transakcji oraz poprzez import uprzednio przygotowanego pliku xml, zawierającego dane kontrahentów i szczegóły transakcji. Są to rozwiązania dedykowane dla uczestników raportujących stosunkowo małą liczbę transakcji jak i podmiotów dopiero przygotowujących się do obsługi plików xml owych, bądź obsługujących je w sposób niezautomatyzowany. Kanał A2A jest bezpośrednim kanałem wymiany komunikatów xml pomiędzy systemami i przeznaczony jest dla uczestników nastawionych na raportowanie dużych ilości danych. Konfiguracja oraz obsługa tego kanału wymaga po stronie uczestnika KDPW_TR pewnego nakładu pracy IT w budowę infrastruktury aplikacji oraz w budowę dedykowanego kanału VPN. 28. Czy możliwe jest, w przypadku komunikacji A2A z systemem KDPW TR, wykorzystanie funkcjonujących kanałów VPN? KDPW rekomenduje zbudowanie osobnej komunikacji z KDPW TR w oparciu o dedykowany kanał VPN zestawiony poprzez sieć Internet. Przy czym nie jest wykluczone wykorzystanie obecnych kanałów cyfrowych do komunikacji z KDPW TR, należy jednak pamiętać, że inna będzie adresacja IP oraz inna będzie wykorzystywana w tym celu kolejka MQ.
29. Czy dostęp do repozytorium KDPW TR jest zabezpieczony? Tak, aplikacja KDPW_TR jest zabezpieczona. Aby uzyskać dostęp do systemu, podmiot musi uzyskać uczestnictwo, a następnie pozyskać certyfikat elektroniczny pozwalający na zalogowanie do aplikacji. 30. Czy każdy użytkownik ma taki sam dostęp do aplikacji? Zakres dostępu do aplikacji może być dywersyfikowany na podstawie przyznanego, w ramach certyfikatu indywidualnego (U2A), zakresu uprawnień. 31. W jakich godzinach/dniach można zgłaszać raporty do KDPW_TR? Raporty przyjmowane są 24 godziny na dobę, przez 7 dni w tygodniu, z wyłączeniem okresów wskazanych jako przerwy techniczne. Wsparcie teleinformatyczne dostępne jest od 6.00 do 20.00. Dział Repozytorium transakcji pracuje w dni robocze w godzinach od 8.00 do 17.00. Dzień roboczy to każdy dzień tygodnia, który nie jest dniem ustawowo wolnym od pracy, sobotą oraz innym dniem wskazanym przez Zarząd KDPW, jako dzień wolny. 32. Na czym polega raportowanie dwustronne? Taki sposób raportowania polega na przesłaniu raportu w imieniu obu kontrahentów przez jeden podmiot raportujący w jednym zgłoszeniu. Raport taki charakteryzuje się koniecznością podwójnego wypełnienie sekcji dotyczącej danych kontrahenta i/lub sekcji dotyczącej wyceny i zabezpieczeń oraz pojedynczego wypełnienia sekcji dotyczącej danych o transakcji. Raportowanie dwustronne jest zalecane w regulacjach (patrz: art. 1 pkt. 3 RTS 148/2013), przy czym możliwe jest również przesłanie dwóch raportów za każdą ze stron transakcji odrębnie z jednokrotnie wypełnionymi sekcjami: pierwszą i drugą. 33. Czy możliwe jest rejestrowanie wielu transakcji jednym komunikatem w KDPW_TR? Tak. Jednym komunikatem do KDPW TR można przesłać maksymalnie do 10 000 transakcji. 34. Czego dotyczą komunikaty zbiorcze KDPW_TR i kto może z nich korzystać? Komunikaty zbiorcze dedykowane są do aktualizacji wyceny, zabezpieczenia, danych kontrahenta oraz terminacji portfela/ instrumentu finansowego na wielu raportach jednocześnie. 35. W jakiej kolejności będą obsługiwane zgłoszenia do KDPW TR? Sposób przetwarzania danych i wysyłanie zwrotnie komunikatów ze statusem zgłoszenia do Repozytorium oparty został na zasadzie FIFO (first in first out), co oznacza, że zgłoszenia będą obsługiwane zgodnie z kolejnością wejścia do kolejki MQ. 36. Co się stanie, jeżeli dwie strony tej samej transakcji (w odrębnie zgłaszanych raportach) posłużą się innym Trade ID? W przypadku, kiedy dojdzie do takiego raportowania, KDPW TR potraktuje te raporty jako raporty o odrębnych transakcjach, co oznacza, że nie zostaną one sparowane w procesie rekoncyliacji danych. Podkreślenia wymaga fakt, iż ESMA w swoich regulacjach jednoznacznie wskazuje na konieczność uzgodnienia tego identyfikatora i posługiwania się nim przez obie strony transakcji. 37. Jak kontrolowane są daty obowiązywania w poszczególnych rodzajach raportów? Sposób kontroli pól dat wynika z walidacji publikowanych przez ESMA oraz wymagań systemowych aplikacji KDPW_TR. Ponad walidacje wynikające z tabeli VL2 zaimplementowane zostały następujące kontrole dat w poszczególnych rodzajach zmian: AT = N Data obowiązywania (Eligibility date) musi być równa wartości w polu Znacznik czasu realizacji transakcji (Execution timestamp); AT = N Back Data obowiązywania (Eligibility date) musi być równa wartości w polu Data rozwiązania (Termination date); AT = V (aktualizacja wyceny) Data obowiązywania (Eligibility date) musi być równa wartości w polu Data wyceny (Valuation date); AT = C oraz Z (terminacja oraz kompresja) Data obowiązywania (Eligibility date) musi być równa wartości w polu Data rozwiązania (Termination date).
38. Jakie walidacje zaimplementowało KDPW_TR w procesie kontroli merytorycznej raportu? Zgodnie z wymogami ESMA, w procesie kontroli poprawności raportu zaimplementowane zostały walidacje Level 1 oraz Level 2, ponadto zaimplementowano dodatkowe kontrole wymagane prze architekturę systemu, np. kontrole dat obowiązywania dla poszczególnych rodzajów zmian (AT=N, AT=V, AT=Z oraz AT=C). 39. Jak raportować poszczególne wartości w polu 22 Collateralisation (zabezpieczenie)? Zabezpieczenia raportowane są zawsze z punktu widzenia kontrahenta raportowanej transakcji w stosunku do drugiej strony transakcji. Pola dotyczące zabezpieczeń wypełniane są wtedy, kiedy strona transakcji złożyła zabezpieczenie na rzecz drugiego kontrahenta. PC wypełniamy, gdy kontrakt jest częściowo zabezpieczony, OC wtedy, kiedy jest pełne zabezpieczenie, ale tylko z jednej strony, U kontrakt niezabezpieczony, gdy nie ma żadnego zabezpieczenia, zaś FC - to wskazanie, iż dwie strony dokonują pełnego zabezpieczenia kontraktu. Dodatkowe wskazówki dot. sposobu raportowania wskazane zostały w Q&A - TR question 33. 40. Jak badana jest terminowość raportowania? Badanie terminowości zgłoszeń polega na porównaniu daty raportowania z określoną dla danego rodzaju zmiany datą (datami). Na podstawie raportów o transakcjach w instrumentach pochodnych, oznaczonych jako przeterminowane, na koniec każdego dnia roboczego powstaje zbiorczy raport o transakcjach zaraportowanych ze zwłoką, który udostępniany jest właściwym organom nadzoru. 41. Jak obsługiwane są niepoprawne (niezgodne ze schemą lub kontrolami) komunikaty xml? Komunikaty niezgodne ze schema xsd oraz te, które nie przeszły poprawnie przez zaimplementowane kontrole są odrzucane. W odpowiedzi na niepoprawny komunikat, zwrotnie system KDPW_TR generuje komunikat informujący o błędzie: admi.err.001.01 jeśli komunikat jest niezgodny ze schemą lub trar.sts.003.01 o statusie ERRO z informacją o kodzie błędu wskazującą na niepoprawnie wypełnione/pominięte pole. Jeżeli w komunikacie była raportowana więcej niż jedna transakcja, wówczas odrzucona zostanie tylko ta transakcja, której raport zawierał błędy. 42. Co to są walidacje poziomu pierwszego (Level 1) i walidacje poziomu drugiego (level 2)? Walidacje to inaczej reguły kontroli merytorycznej sposobu wypełniania poszczególnych pól w ramach raportu, ustanowione przez ESMA (European Securities and Markets Association). Walidacje poziomu pierwszego (L1V) zostały opublikowane 24/10/2014, wdrożone przez repozytoria 01/12/2014 i określają czy poszczególne dane są obowiązkowe (tzn. czy mogą być pominięte w raporcie) i czy można wypełnić je wartością NA (nie dotyczy/ niedostępne). Walidacje poziomu drugiego (L2V) zostały opublikowane 27/04/2015, wdrożone przez repozytoria 01/11/2015 i określają dopuszczalne dla poszczególne pól formaty danych oraz zależność/ warunkowość wypełnienia poszczególnych pól w zależności od charakterystyki transakcji dla poszczególnych klas derywatów Tabela reguł walidacyjnych publikowana jest on-line przez ESMA link: emir validation table.
Pytania dotyczące opłat 43. Jakie opłaty ponoszą uczestnicy raportujący? KDPW_RT pobiera od uczestników raportujących 3 rodzaje opłat: za uczestnictwo, za zgłoszenie transakcji, za utrzymanie raportów. Opłata za uczestnictwo: W zależności od typu uczestnictwa pobierana jest opłata roczna w wysokości: GUR 40 tys. rocznie; ZUR 10 tys. rocznie oraz PUR 2 tys. rocznie. Jeżeli podmiot uzyskał uczestnictwo w drugiej połowie roku, opłata pobierana jest w ½ wysokości. W przypadku ustania uczestnictwa, w związku ze zmianą typu uczestnictwa, w pierwszym półroczu roku kalendarzowego, opłata roczna pobierana jest w ½ wysokości opłaty należnej z tytułu dotychczasowego typu uczestnictwa oraz w ½ wysokości opłaty należnej z tytułu nowego typu uczestnictwa. Opłata za zgłoszenie transakcji do repozytorium: za zgłoszenie transakcji, której przedmiotem jest kontrakt ETD (giełdowy): 0,05 PLN (ok. 0,01 EUR) od każdej transakcji, za zgłoszenie transakcji, której przedmiotem jest kontrakt inny niż ETD: 0,15 PLN (ok. 0,03 EUR) od każdej transakcji. Opłata za utrzymanie raportów: Opłata miesięczna za utrzymywanie w repozytorium informacji o transakcji: 0,05 PLN (ok. 0,01 EUR) od każdej aktywnej transakcji. 44. Czy RT stosuje zniżki lub rabaty? Nie. Zgodnie z regulaminem RT, nie ma możliwości stosowania żadnych zniżek i rabatów, jednakże regulamin RT przewiduje maksymalną wysokość opłat, czyli tzw. CAP. CAP to maksymalna wysokość sumy opłat za: zgłoszenie transakcji do repozytorium oraz z tytułu utrzymywania w repozytorium informacji o kontraktach. Pułap ten został wyznaczony na poziomie 250 tys. zł dla kontraktów jednego kontrahenta raportowanych przez jednego uczestnika raportującego. Powyższe ograniczenie wysokości opłat ma zastosowanie tylko w przypadku, gdy w danym roku uczestnik raportujący zaraportował nie więcej niż 25 mln transakcji na rzecz danego kontrahenta. Dla każdej pary uczestnik raportujący + kontrahent, naliczany jest oddzielny cap. W sytuacji, kiedy dla danej pary przekroczona zostanie liczba 25 mln transakcji, KDPW_TR ponownie rozpoczyna naliczanie opłat za raportowanie oraz utrzymanie danych, do momentu osiągnięcia kolejnego cap a (250 tys. PLN) naliczanie dalszych opłat zostaje wstrzymane do momentu osiągnięcia 50 mln transakcji dla danej pary uczestnik raportujący + kontrahent.
45. Jak naliczany są opłaty za raportowanie i utrzymanie informacji o raporcie? Przykład 1 Podmiot przekazuje co miesiąc raporty o zawarciu 10.000 transakcji OTC, każda z tych transakcji jest terminowana na koniec dnia jej zawarcia. Opłaty w tym przypadku przedstawiać się będą następująco: miesiąc liczba transakcji zawartych w miesiącu liczba transakcji obowiązujących opłata za zaraportowanie opłata za utrzymanie (miesięcznie) suma naliczeń za dany miesiąc suma opłat narastająco styczeń 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 2 000 luty 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 4 000 marzec 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 6 000 kwiecień 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 8 000 maj 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 10 000 czerwiec 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 12 000 lipiec 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 14 000 sierpień 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 16 000 wrzesień 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 18 000 październik 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 20 000 listopad 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 22 000 grudzień 10.000 OTC 10.000 OTC 10.000 *0,15=1.500 10.000 *0,05=500 2 000 24 000 Suma pobranych opłat w danym roku wyniesie 24 tys. zł. Przykład 2 Podmiot przekazuje co miesiąc raporty o zawarciu 100.000 transakcji ETD oraz 100.000 transakcji OTC, każda z tych transakcji jest transakcją własną podmiotu i zawierana jest na 3 miesiące, następnie jest wygaszana. Opłaty w tym przypadku przedstawiać się będą następująco: miesiąc liczba transakcji zawartych w miesiącu liczba transakcji obowiązujących opłata za zaraportowanie opłata za utrzymanie (miesięcznie) suma naliczeń za dany miesiąc suma opłat narastająco styczeń 100.000 *0,05+ 100.000 * 0,05=10.000 30 000 30 000 luty 200.000 ETD 200.000 OTC 200.000 *0,05+ 200.000 * 0,05=20.000 40 000 70 000 marzec 50 000 120 000 kwiecień 50 000 170 000 maj 50 000 220 000 czerwiec 50 000 250 000 CAP (!) lipiec sierpień wrzesień październik listopad grudzień Suma pobranych opłat w danym roku wyniesie 250 tys. zł.
Pytania dotyczące identyfikatorów używanych w procesie raportowania 46. Co to jest UPI? UPI (Unique Product Identifier) to globalny identyfikator produktu. Obecnie identyfikator ten nie jest używany, w toku są prace nad przygotowaniem standardu tego kodu, pod kierownictwem CPMI-IOSCO Harmonization Group. 47. Co to jest UTI? UTI (Unique Trade Identifier) to globalny identyfikator transakcji. ESMA, publikując rekomendacje dotyczące zasad generowania oraz sposobu budowania UTI, oczekuje, iż identyfikator ten będzie uzgadniany między stronami transakcji. W dokumencie Question and Answers, ESMA opublikowała wytyczne obejmujące zasady budowania przez strony transakcji identyfikatora UTI na potrzeby procesu raportowania (vide: TR question 18 oraz 19). W toku są prace nad przygotowaniem standardu tego kodu, pod kierownictwem CPMI-IOSCO Harmonization Group. 48. Co to jest kod LEI? LEI (Legal Entity Identifier) to globalny identyfikator podmiotu jest to 20-znakowy kod alfanumeryczny, który jednoznacznie identyfikuje podmiot. Identyfikator ten przypisywany jest kontrahentom będącym osobami prawnymi zgodnie ze standardem ISO 17442. Wobec powszechności i dostępności stosowania LEI, kod ten winien być bezwzględnie wykorzystywany w procesie raportowania, do identyfikacji: stron transakcji, podmiotu raportującego, beneficjenta transakcji, brokera oraz członka rozliczającego, przez wszystkie podmioty mogące uzyskać taki kod. 49. Czy kod LEI jest obowiązkowy w procesie raportowania do repozytorium? Tak, kod LEI wskazany został przez ESMA jako identyfikator podmiotu w procesie raportowania do repozytorium w odniesieniu do wszelkich podmiotów, które ten identyfikator mogą pozyskać. Jedynie podmioty niezobowiązane do raportowania i nieposiadające kodu LEI mogą być w procesie raportowania identyfikowane kodem klienta, co jest uznawane za merytorycznie poprawne. Raporty, w których kontrahent lub drugi kontrahent oznaczeni są identyfikatorem innym niż kod LEI nie są włączane do procesu rekoncyliacji danych (parowanie i porównywanie raportów). 50. Jak zaktualizować ID podmiotu z typu OTHR na kod LEI? Mimo publikacji przez ESMA wytycznych w zakresie modyfikacji kodu klienta na identyfikator LEI (TR question 40), trwają uzgodnienia pomiędzy ESMA a repozytoriami, co do szczegółów tego rozwiązania. KDPW_TR zaproponował aktualizację danych z kodu klienta na kod LEI za pomocą dedykowanego komunikatu zbiorczego trar.ins.006.01, niemniej jednak z uwagi na trwający proces uzgodnień procedury z ESMA, funkcjonalność ta została zawieszona. 51. Czy obie strony transakcji muszą posługiwać się tym samym UTI? Tak. Identyfikator UTI (Trade ID) to niepowtarzalny numer transakcji, nadawany przez strony transakcji we wzajemnym uzgodnieniu. Umożliwia on sparowanie i porównanie zaraportowanych danych w sytuacji, kiedy raporty przekazywane są jednostronnie, w szczególności przez każdego z kontrahentów oddzielnie. Z tego powodu obie strony transakcji muszą użyć tego samego UTI. Pytania dotyczące rekoncyliacji danych 52. Na czym polega rekoncyliacja danych wykonywana przez repozytoria? Rekoncyliacja jest procesem wykonywanym przy współpracy wszystkich zarejestrowanych zgodnie z rozporządzeniem EMIR repozytoriów i polega na parowaniu i porównywaniu raportów zgłoszonych przez strony oddzielnie. Szczegółowy opis procesu wraz ze wskazaniem statusów oraz ich znaczenia dostępny jest on-line: Opis rekoncyliacji 53. W jaki sposób RT informuje uczestników o wynikach rekoncyliacji? KDPW_TR informuje o wynikach rekoncyliacji za pośrednictwem komunikatu trar.rcn.001.02 z uwzględnieniem statusu procesu rekoncyliacji. Raporty, w których nie stwierdzono żadnego błędu lub stwierdzono tylko błędy kategorii 3 oznaczane są statusem MACH. Raporty, w których stwierdzono tylko błędy kategorii 2 lub 3 oznaczane są statusem ERR2. Raporty,
w których stwierdzono błędy kategorii 1 oznaczane są statusem ERR1. Raporty z błędnymi identyfikatorami bądź znacznikami kontrahenta oznaczane są statusem ERCD. 54. Do czego zobowiązany jest raportujący po otrzymaniu w komunikacie trar.rcn.001.02 poszczególnych statusów raportów? Informacje o zaraportowanych transakcjach zawarte w plikach trar.rcn.001.02 mogą przyjąć jeden ze statusów: {ERCD; ERR1; ERR2; MACH; NPAR}. Status MACH oznacza, że proces parowania i porównania danych zakończy się sukcesem. Ten status nie wymaga od uczestnika żadnych działań. Status NPAR oznacza, że dla raport drugiego kontrahenta nie został odnaleziony. W takiej sytuacji zalecany jest kontakt z drugą stroną transakcji, celem wyjaśnienia czy podmiot ten zaraportował transakcję do jednego z repozytoriów oraz czy wysłany raport został oznaczony tym samym identyfikatorem transakcji. Status ERR1 lub ERR2 oznacza, że raporty zostały sparowane, jednak wykryte zostały rozbieżności w danych zaraportowanych przez każdego z kontrahentów. W takiej sytuacji w raporcie wylistowane są pola o rozbieżnych wartościach kontrahent powinien skontaktować się z drugą stroną transakcji w celu uzgodnienia szczegółów bądź zmodyfikować swój raport przyjmując wartości zaraportowane przez drugiego kontrahenta za obowiązujące. Status ERCD wskazuje na konieczność modyfikacji danych decydujących o uwzględnieniu raportu w procesie parowania danych: Błąd E003 wskazuje, że w raportach kontrahentów niezgodne jest pole strona transakcji. Uczestnik powinien zmodyfikować dane tak, aby strony transakcji dla obu kontrahentów były przeciwstawne; Błąd CPCT wskazuje, że pole Kontrakt z kontrahentem spoza EOG (tag NonEEACtrPty) wypełniono niepoprawnie w stosunku do raportu drugiego kontrahenta. Uczestnik powinien zmodyfikować dane zaraportowane w polu oznaczającym Kontrakt z kontrahentem spoza EOG ; Błędy ERL1 i/lub ERL2 wskazują, że kod LEI kontrahenta/ drugiego kontrahenta jest niepoprawny (kod nieważny lub nieistniejący w bazie GLEIF). Uczestnik powinien zweryfikować kod LEI użyty w procesie raportowym i w razie omyłki anulować transakcję i zaraportować ją ponownie na bazie poprawnych identyfikatorów kontrahentów; Błąd ERUT wskazuje, że w raporcie podano niepoprawny identyfikator transakcji (w efekcie transakcja ta nie zostanie włączona do procesu rekoncyliacji). Kody błędów wraz z krótkimi opisami udostępniane są on-line w dokumencie Kody błędów generowane przez system KDPW_TR link: Kody błędów rekoncyliacji.