WALIDACJE LEVEL 2. Zmiany w kontroli komunikatów, procesie rekoncyliacji oraz zmiany związane z obsługą raportów. (Materiał dla uczestników)
|
|
- Stanisława Grabowska
- 7 lat temu
- Przeglądów:
Transkrypt
1 WALIDACJE LEVEL 2 Zmiany w kontroli komunikatów, procesie rekoncyliacji oraz zmiany związane z obsługą raportów (Materiał dla uczestników) 1
2 Spis treści Zmiany w kontroli komunikatów, procesie rekoncyliacji oraz zmiany związane z obsługą raportów Zmiany ogólne Unikalność UTI pomiędzy stronami Wprowadzenie nowej funkcji komunikatu czyszczenie danych Informacja o statusie rekordu Zastąpienie daty EligibilityDate datami Eligibility Date From i Eligibility Date To Zmiany w obsłudze AT=E Aktualizacja/zmiana danych (zamiast AT=E do mutacji) Umożliwienie kontrahentowi wskazania błędu w danych zgłoszonych w jego imieniu raportowanie delegowane (zastąpienie AT=E (PUR) przez AT=O (PUR)) Zmiany związane z AT=C oraz nowy techniczny AT=T Usunięcie wartości raportowanych zbiorczo Zmiany związane z referencjami Wymagalność pól dla poszczególnych AT AT=N AT=M AT=C AT=Z AT=E AT=V Możliwość zmiany identyfikatorów stron transakcji CP1 i CP Nowe kontrole merytoryczne Zmiany w procesie rekoncyliacji Załączniki
3 1. Zmiany ogólne 1.1. Unikalność UTI pomiędzy stronami Użycie tego samego UTI (TradId) pomiędzy tymi samymi stronami transakcji możliwe jest tylko raz. Próba ponownego użycia tego samego TradId pomiędzy tymi samymi stronami transakcji, będzie skutkować odrzuceniem komunikatu, nawet, jeśli poprzedni raport został całkowicie anulowany (tzn. przesłano AT=E anulujące całą transakcję) Wprowadzenie nowej funkcji komunikatu czyszczenie danych Wprowadzona zostanie nowa funkcjonalność komunikatu, dzięki której można będzie raportować puste wartości w polach nieobowiązkowych oraz anulować wartości uprzednio w danym polu zaraportowane atrybut delete= Y dla tagu. Czyszczenie danych będzie dotyczyło tylko wartości, które nie są obowiązkowe (szczegółowy spis pól dopuszczalnych do czyszczenia w dokumencie Wypełnianie komunikatów ). Uczestnik wskazuje w komunikacie AT=M pola, które mają ulec czyszczeniu poprzez nadanie tagowi atrybutu delete= Y. Przykład: <Undrlyg delete= Y /> W efekcie, w polu Underlying pojawi się wartość pusta. Podanie takiego atrybutu dla pól, których czyszczenie nie jest możliwe skutkować będzie odrzuceniem komunikatu. Funkcja czyszczenia udostępniona zostanie dla komunikatu trar.ins (AT=M) oraz komunikatów trar.ins , trar.ins , przy czym działanie tej funkcji dla komunikatów raportowania zbiorczego opisane jest w dalszej części materiału (pkt.6) Informacja o statusie rekordu Każdy rekord transakcyjny (mutacja) w bazie RT posiada swój status, który może przyjąć jedną a wartości: A Aktywny (obejmuje wszystkie rekordy nieusunięte i niesterminowane) N Nieaktywny (obejmuje rekordy sterminowane) E usunięty (obejmuje rekordy usunięte). 3
4 W związku z dopuszczeniem możliwości częściowej terminacji oraz wprowadzeniem automatycznego wygaszania transakcji, informacja o statusie rekordu będzie udostępniania uczestnikom. W interfejsie pozostaje podział na zakładki Report Searching i Archive, przy czym pierwsza zakładka, prezentować będzie rekordy aktywne (o statusach A ), a zakładka druga nieaktywne (o statusach N ). Dodatkowo, powołana zostanie nowa zakładka Deleted reports, która prezentować będzie rekordy anulowane (o statusach E ). Zakres danych prezentowanych w zakładce ograniczony będzie do pól: TradId, Cp1, Cp2, ErrorDtTm. W komunikatach trar.rqs , trar.sts i trar.ntf dodane zostanie pole Status rekordu. Komunikat trar.rqs zyskuje nową funkcjonalność odpytywanie wg statusu rekordu Zastąpienie daty EligibilityDate datami Eligibility Date From i Eligibility Date To. Możliwe będzie nadpisanie części historii transakcji w wybranym zakresie dat. W związku z tym przebudowie ulega data obowiązywania, która obecnie składać się będzie z zakresu dat: Eligibility Date From i Eligibility Date To. Ogólne zasady działania: 1) Data Eligibility Date From będzie wymagana w każdym komunikacie. 2) Jeśli data Eligibility Date To jest wypełniona to historia transakcji zostanie nadpisana w podanym zakresie od Eligibility Date From do Eligibility Date To, tzn. dotychczasowe wpisy z tego zakresu przestaną być obowiązujące i widoczne, a w ich miejsce powstaną nowe (zaktualizowane) wpisy. Nadpisanie części historii możliwe jest tylko za pomocą AT=M, V lub Z. Data Eligibility Date To dla pozostałych AT jest ignorowana. 3) Jeśli data Eligibility Date To nie jest wypełniona a data Eligibility Date From jest większa od daty obowiązywania ostatniej mutacji to tworzony jest kolejny wpis obowiązujący od daty Eligibility Date From. 4) Jeśli data Eligibility Date To nie jest wypełniona a data Eligibility Date From jest mniejsza lub równa od daty obowiązywania ostatniej mutacji to tworzony jest wpis obowiązujący od daty Eligibility Date From, a dotychczasowa historia od daty Eligibility Date From przestanie być obowiązująca i widoczna. PRZYKŁADY: Przykład 1 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce modyfikacja transakcji (AT=M) z podaniem daty Eligibility Date From = D3 oraz pustą datą Eligibility Date To. 4
5 Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; od daty D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=M. Status raportu = A aktywny D1 D3 AT=N AT=M (EligDt From = D3) Przykład 2 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce modyfikacja transakcji (AT=M) z podaniem daty Eligibility Date From = D3 oraz daty Eligibility Date To = D5. Od daty D3 do daty D5 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=M, od daty D6 ponownie obowiązują dane przekazane raportem AT=N. Status raportu = A aktywny D1 D3 D5 AT=N AT=M (EligDt From = D3 EligDt To = D5) Przykład 3 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D6 miała miejsce częściowa terminacja transakcji (AT=C) z podaniem daty Eligibility Date From = D6. Od daty D1 do daty D5 obowiązują dane przekazane raportem AT=N; od daty D6 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=C. Status raportu = A aktywny D1 D6 AT=N AT=C (EligDt From = D6) 5
6 Przykład 4 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce aktualizacja wyceny transakcji (AT=Vw) z podaniem daty Eligibility Date From = D3 i pustą datą Eligibility Date To, w dacie D7 miała miejsce aktualizacja zabezpieczenia transakcji (AT=Vz) z podaniem daty Eligibility Date From = D7 i pustą datą Eligibility Date To, w dacie D8 miała miejsce modyfikacja transakcji (AT=M) z podaniem daty Eligibility Date From = D8 i pustą datą Eligibility Date To. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; od daty D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=Vw; od daty D7 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=Vw oraz zabezpieczenia przekazanego raportem AT=Vz; od daty D8 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=Vw, zabezpieczenia przekazanego raportem AT=Vz oraz modyfikacji przekazanej raportem AT=M. Status raportu = A aktywny D1 D3 D7 D8 AT=N AT=Vw (EligDt From = D3) AT=Vz (EligDt From = D7) AT=M (EligDt From = D8) Przykład 5 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce aktualizacja wyceny transakcji (AT=V1) z podaniem daty Eligibility Date From = D3 oraz daty Eligibility Date To = D5, w dacie D4 transakcja została zmodyfikowana (AT=M), następnie w dniu D10 zaktualizowana została wycena transakcji (AT=V2) z podaniem daty Eligibility Date From = D10 i pustą datą Eligibility Date To. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; w dacie D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=V1; od daty D4 do daty D5 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny przekazanej raportem AT=V1 oraz modyfikacji przekazanej raportem AT=M; od daty D6 do daty D9 obowiązują dane przekazane raportem AT=N z uwzględnieniem modyfikacji przekazanej raportem AT=M (nie obowiązuje już wycena V1); od daty D10 obowiązują dane przekazane raportem AT=N z uwzględnieniem modyfikacji przekazanej raportem AT=M oraz wyceny przekazanej raportem AT=V2. Status raportu = A aktywny 6
7 D1 D3 D4 D5 D10 AT=N AT=V1 (EligDt From = D3 EligDt To = D5) AT=M (EligDt From = D4) AT=V2 (EligDt From = D10) Przykład 6 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D12 miała miejsce całkowita terminacja transakcji (AT=C) z podaniem daty Eligibility Date From = D12. Od daty D1 do daty D11 obowiązują dane przekazane raportem AT=N; od daty D12 obowiązują dane przekazane raportem AT=N z uwzględnieniem terminacji przekazanej raportem AT=C. Status raportu: w dniach D1-D11 A (aktywny) od dnia D12 - N( nieaktywny) D1 D12 AT=N AT=C (EligDt From = D12) Przykład 7 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N) oraz z Maturity Date = D10, następnie w dacie D10 miało miejsce wygaszenie transakcji w dacie zapadalności (AT=T). Od daty D1 do daty D9 obowiązują dane przekazane raportem AT=N; od daty D10 obowiązują dane przekazane raportem AT=N z uwzględnieniem wygaszenia transakcji za pomocą technicznego zapisu AT=T. Status raportu: w dniach D1-D9 A (aktywny), od dnia D10 - N (nieaktywny) D1 D10 AT=N AT=T (EligDt From = Maturity Date = D10) 7
8 Przykład 8 Transakcja T1 została zaraportowana z datą zawarcia D1 (AT=N), następnie w dacie D3 miała miejsce częściowa terminacja transakcji (AT=C1) z podaniem daty Eligibility Date From = D3, w dniu D12 nastąpiła kolejna częściowa terminacja transakcji (AT=C2) z podaniem daty Eligibility Date From = D12. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; od daty D3 do daty D11 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=C1; od daty D12 obowiązują dane przekazane raportem AT=N z uwzględnieniem zmian przekazanych raportem AT=C1 oraz zmian przekazanych raportem AT=C2. Status raportu = A aktywny D1 D3 D12 AT=N AT=C1 (EligDt From = D3) AT=C2 (EligDt From = D12) Przykład 9 Transakcja T1 została zaraportowana z datą zawarcia D1, następnie w dacie D3 miała miejsce aktualizacja wyceny z datą wyceny D3 (AT=V1) obowiązująca od D3 do D5, w dacie D5 aktualizacja wyceny z datą wyceny D4 (AT=V2) obowiązująca od D4 do D6. Od daty D1 do daty D2 obowiązują dane przekazane raportem AT=N; w dacie D3 obowiązują dane przekazane raportem AT=N z uwzględnieniem wyceny V1 przekazanej raportem AT=V1; od daty D4 do daty D5 obowiązują dane przekazane raportem AT=N z uwzględnieniem aktualizacji wyceny przekazanej raportem AT=V2; od daty D6 obowiązują dane przekazane raportem AT=N (nie obowiązuje już żadna z wycen). Status raportu = A aktywny D1 D3 D4 D5 D6 AT=N AT=V1 (EligDt From = D3 EligDt To = D5) AT=V2 (EligDt From = D4 EligDt To = D6) 8
9 Przykład 10 Transakcja T1 została zaraportowana z datą zawarcia D1, następnie w dacie D2 miała miejsce modyfikacja daty rozliczenia (AT=M), w dacie D3 aktualizacja wyceny (AT=V1), w dacie D4 aktualizacja wyceny (AT=V2), w dacie D5 aktualizacja wyceny (AT=V3). D1 D2 D3 D4 D5 AT=N AT=M (EligDt From = D2) AT=V1 (EligDt From = D3) AT=V2 (EligDt From = D4) AT=V3 (EligDt From = D5) W dacie D6 raportujący odnotował pomyłkę w wartości wyceny zaraportowanej na datę D3 (AT=V1), przyjęte rozwiązanie pozwoli na aktualizację wartości tej wyceny poprzez przekazanie raportu AT=V z zakresem dat Eligibility Date From=D3 i Eligibility Date To=D3. Wówczas zaktualizowana zostanie tylko i wyłącznie wartość wyceny V1. D1 D2 D3 D4 D5 AT=N AT=M (EligDt From = D2) AT=V1 (EligDt From = D3 EligDt To = D3) aktualizacja wyceny V1 AT=V2 (EligDt From = D4) AT=V3 (EligDt From = D5) Jednocześnie należy mieć na względzie, iż przekazanie w powyższym przypadku raportu AT=V jedynie z datą Eligibility Date From=D3, bez wskazania daty Eligibility Date To, spowoduje zastąpienie historii wyceny od daty D3 poprzez nowy wpis. Oznacza to, że w takiej sytuacji uczestnik zastąpi nowo przesyłanymi danymi wycenę V1, V2 i V3, zatem w dniach D4 i D5 obowiązywać będzie wycena oraz wszystkie pozostałe parametry transakcji zgłoszone na dzień D3. D1 D2 D3 D4 D5 AT=N AT=M (EligDt From = D2) AT=V1 (EligDt From = D3) aktualizacja wyceny V1 i zastąpienie V2, V3 9
10 AT=V2 (EligDt From = D4) AT=V3 (EligDt From = D5) 2. Zmiany w obsłudze AT=E a) Po przesłaniu AT=E do danej transakcji, użycie tego samego TradId pomiędzy tymi samymi kontrahentami nie będzie możliwe. Jednocześnie jedynym raportem, który może przesłać druga strona jest również raport AT=E. b) Odejście od AT=E przesłanego do dowolnego AT. Od momentu wejścia w życie zmian związanych z walidacją poziomu 2, AT=E będzie usuwać transakcję wraz z całą jej historią. c) Odejście od AT=E zgłaszanego przez PUR a na rzecz AT=O zgłaszanego przez PUR a celem umożliwienia kontrahentowi zgłoszenia raportującemu błędu w zaraportowanych w jego imieniu danych. d) Po odebraniu poprawnego komunikatu AT=E, poza dotychczasową obsługą (anulacja transakcji), dodatkowo tworzony jest nowy rekord (mutacja) AT=E. Wpisy o transakcjach anulowanych będą prezentowane w interfejsie w nowo powołanej do tego celu zakładce (Deleted Reports). 3. Aktualizacja/zmiana danych (zamiast AT=E do mutacji) Aktualizacja/zmiana danych odbywać się będzie poprzez przesłanie komunikatu trar.ins z odpowiednim AT, który umożliwia modyfikację zakresu danych, (np. aktualizacja wyceny poprzez komunikat AT=V, aktualizacja danych kontrahenta poprzez AT=M itd. zgodnie z dokumentem Wypełnianie komunikatów ) oraz odpowiednią datą Eligibility Date From i ew. Eligibility Date To. Dopuszczone będą modyfikacje wszystkich pól, z wykluczeniem klucza transakcji (tj. CP1+CP2+TradID). W/w dokument określa, które pola (sekcje) mogą być modyfikowane poprzez poszczególne AT. Klucz transakcji będzie mógł ulec zmianie wyłącznie w przypadku, gdy Uczestnik Raportujący zgłosi zmianę identyfikatora strony transakcji z interim na LEI patrz punkt: Możliwość zmiany Identyfikatorów stron transakcji CP1 i CP2. 4. Umożliwienie kontrahentowi wskazania błędu w danych zgłoszonych w jego imieniu raportowanie delegowane (zastąpienie AT=E (PUR) przez AT=O (PUR)) Dotychczasowe uprawnienie pośredniego uczestnika repozytorium do wykasowania (anulowania) za pomocą AT=E raportu błędnie przekazanego bądź przekazanego z błędnymi wartościami zostaje wycofane i zastąpione możliwością wskazania raportującemu błędu w danych poprzez przekazanie AT=O do transakcji. Przesłanie 10
11 przez PUR a zgłoszenia o konieczności korekty danych realizowane będzie wyłącznie przez wygenerowanie za pomocą formatki zamieszczonej w interfejsie komunikatu trar.ins 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 , 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 ze wskazaniem klucza transakcji i datą (zakresem dat) obowiązywania do korekty oraz wskazaniem identyfikatora LEI podmiotu zgłaszającego tę korektę. Komunikat ten zostanie przesłany do kanału, z którego system repozytorium otrzymał ostatnią aktualizację danych dla transakcji (A2A lub U2A). W przypadku kanału A2A komunikat notyfikacyjny zostanie przesłany bezpośrednio do kolejki. Dla kanału U2A komunikat przesłany zostanie do dedykowanej zakładki. W interfejsie graficznym powołana zostanie nowa zakładka Counterparty notifications, w której uczestnik raportujący będzie miał dostęp do komunikatów notyfikacyjnych otrzymywanych od kontrahentów, zgłaszających konieczność korekty raportu. 5. Zmiany związane z AT=C oraz nowy techniczny AT=T 5.1. Definicje: Wygaśnięcie zakończenie aktywności danej transakcji/pozycji w dniu wygaśnięcia podanej w polu Maturity date; Terminacja W przypadku terminacji raportowane są wolumen i wartość pozostające po wygaszeniu części bądź wszystkich kontraktów, a nie terminowane wolumen i wartość kontraktów. Terminacja częściowa zakończenie aktywności części kontraktów danej transakcji/pozycji w dniu terminacji podanej w polu Termination Date; Terminacja całkowita - zakończenie aktywności wszystkich kontraktów danej transakcji/pozycji w dniu terminacji podanej w polu Termination Date; 5.2. Terminację (AT=C) uznajemy za częściową, jeśli w polach Notional Amount i Quantity podane są wartości większe niż 0. Terminację (AT=C) uznajemy za całkowitą, jeśli w polach Notional Amount i Quantity podane są wartości równe 0. 11
12 W obu przypadkach podanie daty terminacji jest obowiązkowe, przy czym następuje kontrola: jeśli w poprzednim raporcie data Maturity Date jest podana, to Termination Date musi być mniejsza niż lub równa podanej Maturity Date. Dodatkowo, następuje kontrola: jeśli wartości raportowane w polach Notional Amount i Quantity są większe lub równe wartości w mutacji obowiązującej w dniu terminacji przed przesłaniem raportu o terminacji a data terminacji nie jest oznaczona atrybutem delete= Y, to komunikat jest odrzucany. Powyższe zmiany wymagają również wprowadzenia kontroli wartości raportowanych w polach Notional Amount i Quantity komunikat, w którym tylko jedna z tych wartości jest równa zero zostanie odrzucony. Uwaga: Terminacja zbiorcza zawsze traktowana jest jak terminacja całkowita Automatyczne wygaszanie transakcji Zakładamy, że terminowanie transakcji/pozycji jest zgłaszane przez uczestnika, natomiast wygaszanie transakcji w związku z upływem Maturity Date jest obsługiwane codziennym procesem przez RT, przy czym wygaszanie transakcji odbywa się poprzez techniczny Action Type T. Zakres: Procesem objęte są wszystkie raporty, w których ostatnia mutacja ma wypełnioną datę Maturity Date. Czas: Proces uruchamiany będzie każdego dnia roboczego, analogicznie jak dotychczasowe AT=C wykonywane automatycznie przez Repozytorium KDPW. Działanie: Dla wszystkich transakcji, w których ostatnia obowiązująca mutacja ma wypełnioną i mniejszą od daty dzisiejszej datę Maturity Date, tworzony jest wpis AT=T (kod techniczny) z datą obowiązywania Maturity Date o SMR= TR_T_ +TrnKeyId. Wszystkie zaraportowane dane zostają bez zmian, a pola Notional Amount i Quantity są zerowane. Mutacja taka dostaje status rekordu = N (nieaktywny). Zmiana w udostępnianiu danych uczestnikom: O fakcie wygaszenia transakcji uczestnicy są informowani poprzez przesłanie komunikatu notyfikacyjnego trar.ntf Uczestnicy będą poinformowani o technicznym kodzie AT=T oraz o statusach rekordu = N Umożliwienie raportowania do wygaśniętych, sterminowanych częściowo i całkowicie transakcji. 12
13 Transakcja sterminowana częściowo ma status rekordu A - aktywny, co oznacza, że raportowanie zmian odbywa się analogicznie jak do wszystkich aktywnych mutacji. W związku z wycofaniem możliwości anulowania pojedynczego raportu (mutacji), modyfikacja raportów oznaczonych statusem N- nieaktywny (np. po AT=C lub AT=T) odbywać się będzie poprzez kolejny raport odpowiednią datą obowiązywania, przy zachowaniu następujących warunków: - modyfikacja daty terminacji odbywa się tylko i wyłącznie za pomocą AT=C, przy zachowaniu walidacji daty terminacji w stosunku do maturity date, przy czym usunięcie niepoprawnie przekazanej daty terminacji, możliwa jest jedynie za pomocą AT=M z atrybutem delete= Y patrz pkt. 5.5; - modyfikacja daty wygaśnięcia odbywa się tylko i wyłącznie za pomocą AT=M, przy zachowaniu wszystkich stosownych kontroli. Zmiana maturity date powoduje powstanie nowej mutacji o statusie rekordu A-aktywny, niezależnie od tego czy transakcja jest aktywna czy nie (ew. wygaszenie nastąpi zgodnie z pkt. 5.3); - modyfikacja pozostałych wartości (np. wyceny czy danych dot. stron lub transakcji) jest możliwa za pomocą odpowiednich AT (V, M, Z), przy czym stosowana jest kontrola: - jeśli ostatnia mutacja jest nieaktywna, to EligDtTo przesłanego raportu musi być nie większe niż maksymalna data obowiązywania EligDtFrom nieaktywnej mutacji; 5.5. Usunięcie terminacji czyli Restore Usunięcie terminacji Restore (czyli obecny AT=E do AT=C) odbywa się poprzez komunikat trar.ins AT=M, w którym Tag Termination Date oznaczony jest atrybutem delete= Y oraz pola Notional Amount i Quantity wypełniane są niezerowymi wartościami. W sytuacji, kiedy komunikat zawiera tag Termination Date oznaczony atrybutem delete= Y a pola Notional Amount i Quantity przyjmują wartość 0, komunikat taki jest przez system odrzucany. W przypadku odebrania komunikatu usuwającego terminację, w systemie zapisywana jest kolejna mutacja AT=M, w której data terminacji jest pusta, a wartości pól Notional i Quantity to wartości podane w komunikacie, co umożliwia uczestnikowi w szczególności modyfikację wraz z usunięciem terminacji w jednym kroku. Przesłanie komunikatu AT=M z wypełnioną datą terminacji nieoznaczoną tagiem delete= Y skutkuje odrzuceniem. Możliwość raportowania zmian do raportów wygaśniętych, sterminowanych częściowo i całkowicie odbywa się na zasadach opisanych w pkt Usunięcie wartości raportowanych zbiorczo 6.1. AT=C 13
14 Usunięcie terminacji zbiorczej odbywa się pojedynczo na transakcję, komunikatem trar.ins z oznaczeniem atrybutem delete= Y tagu Termination Date. Działanie identyczne jak w pkt. 4.5 dla wszystkich transakcji objętych działaniem tego komunikatu 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 powoduje zmianę statusu wszystkich wycen lub zabezpieczeń objętych działaniem komunikatu, w efekcie wyceny/ zabezpieczenia te przestają być obowiązujące i widoczne AT=M nie jest możliwe usuwanie, gdyż wszystkie pola modyfikowane zbiorczą M-ką są obowiązkowe (na potrzeby zmiany kodu interim na LEI powołany zostaje nowy komunikat trar.ins ). 7. Zmiany związane z referencjami Odejście od możliwości anulowania pojedynczego wpisu (mutacji) dla transakcji pozwala uprościć sekcję referencji. Podawane w tej sekcji pole SMR przestaje mieć znaczenie, gdyż od momentu wprowadzenia zmian komunikat będzie łączony z transakcją tylko i wyłącznie po kluczu CP1+CP2+TID, przy czym znaczenia nabiera data Eligibility Date From oraz Eligibility Date To, które definiują zakres rekordów objętych zmianą. 8. Wymagalność pól dla poszczególnych AT 8.1. AT=N Wymagalność dotychczasowych pól dla AT=N pozostaje bez zmian. Dodatkowo pojawiają się nowe pola (Eligibility Date To i Underlying Type) oraz dodatkowe kontrole implementowane w ramach poszczególnych sekcji dla konkretnych klas kontraktów AT=M Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz daty/dat obowiązywania. Podawane są wszystkie pola, które mają być modyfikowane. Wartości pól dotąd wypełnionych, a w komunikacie pominiętych są przepisywane. Jeśli w komunikacie wystąpi dla modyfikowalnego pola atrybut delete= Y, wówczas wartość uprzednio w tym polu przekazana jest czyszczona. Nie jest możliwe modyfikowanie sekcji Wycena i zabezpieczenia za pomocą AT=M, a komunikat z wypełniona sekcją Wycena i zabezpieczenia jest odrzucany. Próba wyczyszczenia pól obowiązkowych dla raportu skutkuje odrzuceniem komunikatu. 14
15 8.3. AT=C Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz pól Notional Amount i Quantity oraz daty terminacji, pozostaje kontrola czy EligDtFrom=Termination Date AT=Z Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz daty/dat obowiązywania i pól Notional Amount i Quantity; 8.5. AT=E Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID); AT=E usuwa całą historię i uniemożliwia ponowne zaraportowanie raportu o takim samym kluczu. Restrykcja ta dotyczy obu stron transakcji AT=V Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz daty/dat obowiązywania; kontrola Valuation Timestamp=EligDtFrom(co do daty) pozostaje bez zmian. 9. Możliwość zmiany identyfikatorów stron transakcji CP1 i CP2. Do zmiany identyfikatorów na kody pre-lei/ LEI służył będzie nowy, dedykowany komunikat trar.ins , w którym jedyny dopuszczalny AT to M. Zmiana będzie dokonywana w ramach transakcji zaraportowanych przez raportującego przesyłającego komunikat i dotyczyć będzie zarówno identyfikatorów w polach CP1, jak i CP2. Referencje będą budowane na podstawie identyfikatorów raportującego i kontrahenta, przy czym zmiana identyfikatorów obejmuje zarówno pole CtrptyTRId, jak i OthrCtrptyTrId (w typach innych niż LEIC). W wyniku przetworzenia komunikatu powstanie: o Mutacja AT=M, z datą obowiązywania wskazaną w komunikacie z nowymi identyfikatorem i typem identyfikatora CP1 lub CP2 i pozostałymi danymi pochodzącymi z ostatniej obowiązującej mutacji, przy czym w polu ActionTypeDetails dodany zostanie wpis change of ID CP1 lub change of ID CP2 ; o Wszystkie obowiązujące na moment przetworzenia mutacje zostaną nadpisane. W miejsce tych mutacji powstaną rekordy z nowymi identyfikatorami i nowymi typami identyfikatorów CP1, CP2 - pozostałe wartości zostaną przepisane dla tych mutacji; W następstwie dokonanej zmiany uczestnik otrzyma komunikat trat.sts ze statusem przetworzenia komunikatu PACK lub ERRO (możliwy, gdy np. brak identyfikatora źródłowego w bazie; niedopuszczalny format nowego identyfikatora LEIC, itp.). 10. Nowe kontrole merytoryczne 15
16 1. Rozszerzenie kontroli kodów LEI używanych w procesie raportowania Kontrola obejmie pola: CP1 (w typie LEIC), CP2 (w typie LEIC), Clearing Member ID (w typie LEIC), Broker ID (w typie LEIC), Beneficiary ID (w typie LEIC), CCP, Underlying (w type L-LEI). Sprawdzamy długość pola (=20) i cyfrę kontrolną (zgodnie z ISO 17442). Komunikat nie spełniający tych kryteriów będzie odrzucany. Jednocześnie w opublikowanym przez ESMA dokumencie Validation 2 zdefiniowany został Step 2 dla walidacji kodów LEI, oparty o status rejestracji kodu LEI, który zakłada odrzucanie raportów, w których kontrahent identyfikowany jest nieaktywnym kodem LEI. Wdrożenie tego kroku nastąpi trzy miesiące od decyzji ESMA o zaimplementowaniu tych kontroli, o czym niezwłocznie Państwa poinformujemy w odrębnej korespondencji. 2. Kontrole związane z polami PrdctId1, PrdctId2, Venue of Execution i Underlying 2.1. Kontrole dla pola Taxonomy Jeśli pole wypełnione jest wartością U to komunikat jest odrzucany; Jeśli pole wypełnione jest wartością I to: - Jeśli pole Venue of Execution jest wypełnione wartością XOFF lub ważnym kodem MIC umieszczonym na liście MIFID database Regulated Markets: agename=regulated_markets_display lub umieszczonym na liście MIFID database MTF: agename=mtf_display&subsection_id=0 to komunikat jest przyjmowany; W przeciwnym przypadku komunikat jest odrzucany Jeśli pole wypełnione jest wartością E to: - Jeśli pole Venue of Execution jest wypełnione wartością XOFF lub ważnym kodem MIC umieszczonym na liście MIFID database Regulated Markets: agename=regulated_markets_display to komunikat jest odrzucany; 16
17 W przeciwnym przypadku komunikat jest przyjmowany Kontrole dla pola Venue of Execution Jeśli pole jest wypełnione wartością XXXX lub XOFF, to komunikat jest przyjmowany; W przeciwnym przypadku, jeśli pole wypełnione jest wartością MIC niezgodną z ISO 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: ge=0&pagename=regulated_markets_display lub umieszczoną na liście MIFID database MTF: ge=0&pagename=mtf_display&subsection_id=0 to komunikat jest przyjmowany; w przeciwnym przypadku komunikat jest odrzucany; 2.3. Kontrole dla pola ProductID Jeśli w polu Taxonomy jest wartość I to pole ProductID1 musi być wypełnione kodem ISIN lub Exchange Product Code. To, jakim kodem powinno być wypełnione, definiują zasady: o Jeśli w polu Venue of Execution jest wartość XOFF to w polu ProductID1 musi być ISIN. o Jeśli w polu Venue of Execution jest MIC umieszczony na liście MIFID database Regulated Markets (link powyżej) to informacja o rodzaju kodu (ISIN bądź AII), który powinien być użyty w polu product ID1 czerpana jest z tej bazy, na tej podstawie następuje walidacja pola. Dla rynków bez definicji identyfikatora walidacja prowadzona jest jak dla kodów AII. o Jeśli w polu Venue of Execution jest MIC umieszczony na liście MIFID database MTF (link powyżej) to w polu ProductID1 może być ISIN lub AII. o Jeśli pole wypełnione jest kodem AII, następuje walidacja długości kodu od 1 do 12 znaków alfanumerycznych. 17
18 o Jeśli pole wypełnione jest kodem ISIN, następuje walidacja długości kodu dokładnie 12 znaków alfanumerycznych oraz walidacja cyfry kontrolnej kodu (zgodnie z ISO 6166) Jeśli w polu Taxonomy jest wartość E to dozwolone są tylko wartości: "CO", "CR", "CU", "EQ", "IR" lub "OT" Kontrole dla pola Product ID 2 Jeśli w polu Taxonomy jest wartość I to pole ProductID2 musi zawierać kod CFI zgodny z ISO Co najmniej 2 pierwsze znaki kodu oraz znak reprezentujący klasę instrumentu powinny zostać podane, tzn. nie mogą być X. Dla opcji (kod CFI rozpoczynający się od O ) jest to czwarty znak kodu, dla kontraktów terminowych (kod CFI rozpoczynający się od F ) jest to trzeci znak kodu. Jeśli w polu Taxonomy jest wartość E to dozwolone są tylko wartości: "CD", "FR", "FU", "FW", "OP", "SW" lub "OT" Kontrole dla pól Underlying i nowego pola Underlying type Pola Undelying i Underlying type są obowiązkowe dla wszystkich raportów z wyjątkiem tych, w których w polu Product ID1 podano wartość CO, IR lub CU. Jeśli podano CO lub CU to oba pola muszą być puste. Jeśli pole Underlying type jest wypełnione, to dozwolone wartości to: I - ISIN, L- LEI, B- Basket, X-Index N- Not available. o o o o o Jeśli w Underlying type podano L, to sprawdzamy długość pola (=20) i cyfrę kontrolną (zgodnie z ISO 17442). Jeśli podano w Underlying type podano I to sprawdzamy długość pola (=12) i cyfrę kontrolną (zgodnie z ISO 6166). Jeśli w Underlying type podano B, to pole Underlying musi być wypełnione wartością B. Jeśli w Underlying type podano X, to pole Underlying musi być wypełnione wartością I. Jeśli w Underlying type podano N, to pole Underlying musi być wypełnione wartością NA lub puste. 3. Kontrola UTI (TradId) -Do 52 alfanumerycznych znaków, plus dozwolone znaki specjalne: ":", ".", "-", " _"; -Dla raportów przesłanych przed końcem grudnia 2015 dozwolona jest również spacja; -Znaki specjalne nie mogą wystąpić na początku i na końcu pola; 18
19 4. Kontrola Price Multiplier Dozwolona wartość większa niż zero. 5. Kontrola Quantity Dla wszystkich AT innych niż C, dozwolona wartość większa niż zero, dla C wartość większa lub równa zero. 6. Kontrola Effective Date Effective Date musi być większa lub równa dacie w polu Execution Timestamp dla wszystkich raportów, w których Venue of Execution jest wypełnione kodem MIC (tj. różne od XXXX i XOFF ). 7. Kontrola Termination Date Termination Date musi być większa lub równa dacie wprowadzonej w polu Execution Timestamp i mniejsza lub równa niż data Maturity Date (jeśli podano). 8. Kontrola Clearing Timestamp Pole musi być wypełnione, jeśli pole Cleared= Y ; jeśli wypełnione, musi być większe lub równe Execution Timestamp; 9. Kontrola CCP Pole musi być wypełnione, jeśli pole Cleared= Y ; 10. Sekcja Interest Rates o o o Jeśli w polu ProductID1 podano IR musi być wypełnione co najmniej jedno z pól: Fixed rate of leg 1, Fixed rate of leg 2, Floating rate of leg 1, Floating rate of leg 2; Jeśli wypełnione jest co najmniej jedno z pól: Fixed rate of leg 1, Fixed rate of leg 2, to pola: Fixed rate day count i Fixed leg payment frequency muszą być wypełnione; Jeśli wypełnione jest co najmniej jedno z pól: Floating rate of leg 1, Floating rate of leg 2, to pola: Floating rate reset frequency i Floating leg payment frequency muszą być wypełnione; 11. Sekcja Foreign Exchange Jeśli w polu ProductID1 podano CU to muszą być wypełnione następujące pola: - Currency2, - Exchange rate 1 i/lub Forward exchange rate, - Exchange rate basis; 12. Sekcja Commodities Jeśli w polu ProductID1 podano wartość CO to muszą być wypełnione następujące pola: - Commodity base zgodnie ze słownikiem, - Commodity details zgodnie ze słownikiem; 19
20 12.2. Jeśli w polu Commodity details podano wartość NG lub EL, to muszą być wypełnione następujące pola: - Load type, - Delivery start date and time, - Delivery end date and time, - Contract capacity, - Quantity Unit, - Price/time interval quantities Delivery point or zone jeśli pole jest wypełnione to musi być wypełnione kodem zgodnym z listą EIC Area Codes Y list zamieszczoną na www: i wskazującym na punkt dostawy wewnątrz obszaru EU. 13. Sekcja Options Jeśli w polu ProductID2 podano wartość OP lub kod CFI rozpoczynający się na O, to następujące pola muszą być wypełnione: - Option type, - Option style (exercise), - Strike price. 14. Kontrola formatu danych znaki ujemne Umożliwione zostaje zaraportowanie wartości ujemnych we wszystkich wyszczególnionych poniżej polach: - Mark to market value of contract - Price/ rate - Notional amount - Up-front payement - Fixed rate of leg 1 (funkcjonalność dostępna uprzednio) - Fixed rate of leg 2 (funkcjonalność dostępna uprzednio) - Exchange rate 1 - Forward exchange rate 11. Zmiany w procesie rekoncyliacji Sprawdzenie statusu kodu LEI przed włączeniem raportu do rekoncyliacji Do procesu rekoncyliacji włączane są tylko te raporty, w których podano poprawne kody LEI kontrahentów oraz poprawny identyfikator UTI. Walidacja identyfikatorów odbywa się według poniższych zasad: 20
21 - Identyfikator LEI walidujemy zgodnie z bazą LEI. Kod LEI uznawany będzie za ważny, jeśli jego status jest ISSUED, TRANSFERRED, PEDNING TRANSFER, PENDING ARCHIVAL lub LAPSED. - Proces walidacji kodów LEI przeprowadzany jest przy wejściu komunikatu do RT, jednakże powtórna walidacja LEI jest przeprowadzana codziennie przy generowaniu rejestru rekoncyliacji, w ten sposób wszystkie raporty, których status LEI uległ zmianie mogą być włączane do rekoncyliacji. Zmiana zostanie zaimplementowana jeszcze przed wprowadzeniem walidacji Level Raporty jednostronne, wskazujące na raport z kontrahentem spoza EEA. Dla takich raportów zaimplementowana zostanie dodatkowa kontrola. Jeśli nie odnaleziono pary takiego raportu, to raport ten dostaje status WPAR (nie podlega rekoncyliacji). Jeśli raport zostanie sparowany, to następuje sprawdzenie kraju siedziby Other Counterparty w raporcie przesłanym przez drugą stronę. Jeśli pole to jest wypełnione znacznikiem kraju z obszaru EEA, to raport otrzymuje status YPAR, ale w statusie porównywania pojawia się błąd CPCT Błędne wypełnienie pola NonEEACtrPty Oznaczenie pozycji i wyłączenie ich z procesu rekoncyliacji Z procesu rekoncyliacji wyłączone zostają rekordy zdefiniowane, jako pozycje, czyli takie transakcje, w których pole Compression wypełniono wartością Y a w polu CCP podano kod LEI, lub rekordy po kompresji (po przesłaniu AT=Z do transakcji); Nowe statusy w komunikatach rcn W związku z powyższymi zmianami, w komunikatach rcn przekazywane będą za pomocą dodatkowych statusów informacje o wyłączeniu transakcji z procesu, ponieważ kod lei jednego z kontrahentów nie jest ważny: Nieprawidłowy kod LEI 1 status ERL1; Nieprawidłowy kod LEI 2 status ERL2; Oraz o błędnym wskazaniu drugiego kontrahenta jako spoza obszaru EEA: Błędne wypełnienie pola NonEEACtrPty status CPCT. 12. Załączniki 1. Wypełnianie komunikatów 2. Nowe struktury komunikatów RT 3. Słowniki 21
WALIDACJE LEVEL 2 ZMIANY W SYSTEMIE KDPW_TR
WALIDACJE LEVEL 2 ZMIANY W SYSTEMIE KDPW_TR Warszawa, 23.06.2015 AGENDA Zmiany informacje ogólne Statystyki Tabela walidacji level 2 Nowe funkcjonalności, zmiany w obsłudze AT Komunikaty zmiany Kody LEI
Bardziej szczegółowoWarszawa, 15 lipiec 2014 r. Zasady raportowania aktualizacji wyceny i zabezpieczeń do. Repozytorium Transakcji KDPW
Warszawa, 15 lipiec 2014 r. Zasady raportowania aktualizacji wyceny i zabezpieczeń do Repozytorium Transakcji KDPW 1 Spis treści Wstęp... 3 Raportowanie wyceny... 4 Raportowanie zabezpieczeń... 8 Raportowanie
Bardziej szczegółowoProjekt 3.2.1: Repozytorium transakcji
Warszawa, 1 października 2015 r. Projekt 3.2.1: Repozytorium transakcji Specyfikacja Komunikatu Zgłoszenia do Repozytorium trar.ins.001.02 Wersja 3.4 Spis treści Komunikat zgłoszenia do Repozytorium trar.ins.001.01...
Bardziej szczegółowoMateriał opisujący proces raportowania MIFIR za pośrednictwem ARM z wykorzystaniem systemu RT
Materiał opisujący proces raportowania MIFIR za pośrednictwem ARM z wykorzystaniem systemu RT 2019-01-14 wersja 2.0 1 / 15 Spis treści Historia Zmian... 3 Słownik pojęć... 3 I. Informacje ogólne.... 4
Bardziej szczegółowoOpis funkcjonalności KDPW_TR
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...
Bardziej szczegółowoOpis funkcjonalności KDPW_TR SŁOWNIK POJĘĆ... 2 UŻYTKOWNICY REPOZYTORIUM... 3
Opis funkcjonalności KDPW_TR Spis treści SŁOWNIK POJĘĆ... 2 UŻYTKOWNICY REPOZYTORIUM... 3 OBSŁUGA KOMUNIKATÓW... 5 Budowa komunikatów XML... 5 Przestrzenie nazw (namespaces)... 5 Nagłówki... 6 Zestaw znaków...
Bardziej szczegółowoWersjonowanie danych wg wersji RTS, prezentacja danych i eksport w interfejsie WEB oraz przekazywanie danych w komunikatach zwrotnych trar.sts.001.
Wersjonowanie danych wg wersji RTS, prezentacja danych i eksport w interfejsie WEB oraz przekazywanie danych w komunikatach zwrotnych trar.sts.001. Spis treści WERSJONOWANIE... 2 PRZEKAZYWANIE DANYCH W
Bardziej szczegółowoRepozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium. Warszawa,10 luty 2014
Repozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium Warszawa,10 luty 2014 Agenda Ogólna koncepcja sytemu zapewnienie poufności i bezpieczeństwa Dokumentacja i obsługa komunikatów Rekoncyliacja
Bardziej szczegółowoINSTRUKCJA OBSŁUGI GRAFICZNEGO INTERFEJSU UŻYTKOWNIKA U2A
INSTRUKCJA OBSŁUGI GRAFICZNEGO INTERFEJSU UŻYTKOWNIKA U2A 1 z 18 INSTRUKCJA OBSŁUGI GRAFICZNEGO INTERFEJSU UŻYTKOWNIKA U2A Spis treści I WSTĘP... 3 II FUNKCJONALNOŚCI REPOZYTORIUM TRANSAKCJI... 4 III WYLOGOWANIE
Bardziej szczegółowoOpis procesu rekoncyliacji danych w raportach zgłaszanych do KDPW_RT. listopad 2015
Opis procesu rekoncyliacji danych w raportach zgłaszanych do KDPW_RT listopad 015 1 Spis treści Wstęp... 3 Parowanie raportów... 3 Porównywanie szczegółów transakcji w sparowanych raportach... 5 Informacja
Bardziej szczegółowoEMIR II: Zasady raportowania do KDPW_TR po wejściu w życie nowych standardów technicznych
EMIR II: Zasady raportowania do KDPW_TR po wejściu w życie nowych standardów technicznych Dział Repozytorium Transakcji KDPW Warszawa, 26 czerwca 2017 r. AGENDA Informacje ogólne Zmiany w procesie raportowania:
Bardziej szczegółowoRepozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium. Warszawa, styczeń 2014
Repozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium Warszawa, styczeń 2014 Agenda Ogólna koncepcja sytemu zapewnienie poufności i bezpieczeństwa Dokumentacja i obsługa komunikatów Zgłoszenie
Bardziej szczegółowodot. Raportowania derywatów do repozytorium transakcji przez KDPW_CCP
CCP/ZW/137/2014 Warszawa, 4 lutego 2014 r. Uczestnicy KDPW_CCP dot. Raportowania derywatów do repozytorium transakcji przez KDPW_CCP Szanowni Państwo, w nawiązaniu do wcześniejszej korespondencji (pismo
Bardziej szczegółowoCZĘSTO ZADAWANE PYTANIA (FAQ)
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
Bardziej szczegółowoWykaz kodów błędów Stan na 11 sierpnia 2014 r.
Wykaz kodów błędów Stan na 11 sierpnia 2014 r. Oznaczenia pola: Typ F błędy natury formalnej związane z budową komunikatu, błędy natury merytorycznej związane z bazą parametrów bądź słownikową oraz kontrolami
Bardziej szczegółowoZakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW.
Zakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW. Historia zmian Lp Data zmiany Miejsce zmiany 1 27.01.2014 Kod TRN w przykładzie na str. 6
Bardziej szczegółowoWykaz kodów błędów Stan na 6 marca 2015 r.
Kody błędów generowane przez system KDPW_TR (PL) Wykaz kodów błędów Stan na 6 marca 2015 r. Oznaczenia pola: Typ F błędy natury formalnej związane z budową komunikatu, błędy natury merytorycznej związane
Bardziej szczegółowoZakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW.
Zakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW. Historia zmian Lp. Data zmiany Miejsce zmiany Powód zmiany Zmiana 1 27.01.2014 str. 8 Błędnie
Bardziej szczegółowoRepozytorium transakcji. Warunkiem zalogowania jest posiadanie ważnego certyfikatu
Warszawa, 14 maja 2013 Załącznik nr 9. Interfejs WWW skrócona instrukcja użytkownika. Logowanie użytkownika do Repozytorium transakcji W celu zalogowania się do Repozytorium transakcji, należy na stronie
Bardziej szczegółowoMateriał informacyjny schematy przepływów statusów w systemie KDPW_ARM
Materiał informacyjny schematy przepływów statusów w systemie KDPW_ARM 2017-09-28 wersja 1.0 1 / 10 Spis treści Historia zmian... 3 Słownik pojęć... 3 I. Wykaz statusów w usłudze KDPW ARM... 3 II. Cykl
Bardziej szczegółowoZakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW.
Zakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW. Historia zmian Lp. Data zmiany Miejsce zmiany Powód zmiany Zmiana 1 27.01.2014 str. 8 Błędnie
Bardziej szczegółowoZasady raportowania przez IRGiT do repozytorium KDPW S.A.
Załącznik nr 1 do Uchwały Zarządu Izby Rozliczeniowej Giełd Towarowych S.A. Nr 187/72/10/2015 z dnia 5 października 2015 roku Zasady raportowania przez IRGiT do repozytorium KDPW S.A. 1. Obowiązek sprawozdawczy
Bardziej szczegółowoKDPW_TR Step by Step
KDPW_TR Step by Step Obowiązek raportowania > Zgodnie z art. 9 EMIR 1 kontrahenci oraz CCP mają obowiązek zapewnienia, aby szczegółowe informacje na temat każdego zawartego przez te podmioty kontraktu
Bardziej szczegółowoDo raportowania zobowiązane są wszystkie podmioty, prowadzące działalność gospodarczą (przedsiębiorcy),
1. 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
Bardziej szczegółowoDot. Raportowania derywatów do repozytorium transakcji przez KDPW_CCP
CCP/ZW/91/2014 Warszawa, 24 stycznia 2014 r. Uczestnicy KDPW_CCP Dot. Raportowania derywatów do repozytorium transakcji przez KDPW_CCP Szanowni Państwo, Rozporządzenie Parlamentu Europejskiego i Rady (UE)
Bardziej szczegółowoZasady raportowania przez IRGiT do repozytorium KDPW S.A.
Załącznik nr 1 do Uchwały Zarządu Izby Rozliczeniowej Giełd Towarowych S.A. 303/71/10/2016 z dnia 7 października 2016 roku Zasady raportowania przez IRGiT do repozytorium KDPW S.A. Wchodzą w życie z dniem
Bardziej szczegółowoKDPW_TR Step by Step
KDPW_TR Step by Step Obowiązek raportowania > Zgodnie z art. 9 Rozporządzenia EMIR 1 kontrahenci oraz CCP mają obowiązek zapewnienia, aby szczegółowe informacje na temat każdego zawartego przez te podmioty
Bardziej szczegółowo7 powodów. dla których warto raportować. do Repozytorium Transakcji w KDPW
7 powodów dla których warto raportować do Repozytorium Transakcji w KDPW Rozporządzenie Parlamentu Europejskiego i Rady (UE) Nr 648/2012 z dnia 4 lipca 2012 r. w sprawie instrumentów pochodnych będących
Bardziej szczegółowoRaportowanie kontraktów pochodnych do KDPW_TR przez KDPW_CCP. Spotkanie z Uczestnikami KDPW_CCP 4 grudnia 2013r.
Raportowanie kontraktów pochodnych do KDPW_TR przez KDPW_CCP Spotkanie z Uczestnikami KDPW_CCP 4 grudnia 2013r. Agenda 1. Ramy prawne 2. Zakres raportowania 3. Zgłaszanie raportów przez KDPW_CCP 4. Techniczne
Bardziej szczegółowoRepozytorium Transakcji wersja ESMA. Warszawa, październik 2013
Repozytorium Transakcji wersja ESMA Warszawa, październik 2013 Agenda Repozytorium w KDPW uwarunkowania prawne Uczestnictwo w repozytorium Komunikacja z repozytorium i raportowanie Opłaty 2 Repozytorium
Bardziej szczegółowoSystem AIS IMPORT. Zmiany w oprogramowaniu FRAKTAL STUDIO.
System AIS IMPORT. Zmiany w oprogramowaniu FRAKTAL STUDIO. Instrukcja z 2018-10-19 Spis treści System AIS IMPORT. Zmiany w oprogramowaniu FRAKTAL STUDIO. o Dane kontrahentów o Wysyłka komunikatów zwrotnych
Bardziej szczegółowoZakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW.
Zakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW. Historia zmian Lp Data zmiany Miejsce zmiany Powód zmiany Zmiana 1 27.01.2014 Kod TRN - przykład
Bardziej szczegółowoPodstawowe zasady dotyczące potwierdzania warunków transakcji na Platformie konfirmacji.
Podstawowe zasady dotyczące potwierdzania warunków transakcji na Platformie konfirmacji. 1. Uczestnicy rozliczający KDPW_CCP przekazują do systemu kdpw_stream instrukcje konfirmacyjne do zestawienia za
Bardziej szczegółowoInstrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro.
Instrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro aktualizacja: 12 czerwca 2017 r. Spis treści: 1. Pierwsze logowanie do
Bardziej szczegółowoInstrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro.
Instrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro aktualizacja: 8 listopada 2017 r. Spis treści: 1. Logowanie do bankowości
Bardziej szczegółowoWskazanie, czy drugi kontrahent ma siedzibę poza EOG. Y = Tak / N = Nie.
LP. TAG KOMUNIKATU TRAR.INS.001.01 NAZWA KROTNOŚĆ TYP DANYCH POZYCJA W TABELI RTS148/2013 / ITS1247/2012 OPIS/ FORMAT/ DOPUSZCZALNE WARTOŚCI PRZYKŁAD/ DODATKOWY OPIS 0 KDPWDocument Komunikat systemu KDPW
Bardziej szczegółowoStruktura pliku wejściowego ippk Plik Korekt Składek
Struktura pliku wejściowego ippk Plik Korekt Składek INFORMACJE OGÓLNE... 3 STRUKTURA PLIKU... 3 STRUKTURA FORMATU... 3 DOPUSZCZALNE WARTOŚĆI W POLACH SŁOWNIKOWYCH... 4 ŁADOWANIE PLIKU... 4 INFORMACJE
Bardziej szczegółowoKDPW_ARM nowa usługa KDPW w ramach obowiązków raportowych MiFIR
KDPW_ARM nowa usługa KDPW w ramach obowiązków raportowych MiFIR Dział Repozytorium Transakcji KDPW 28-09-2017r. 28-09-2017r. AGENDA MiFID II/MiFIR - stan prawny, wybrane aspekty Korzyści z raportowania
Bardziej szczegółowoZakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW.
Zakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW. Historia zmian Lp. Data zmiany Miejsce zmiany Powód zmiany Zmiana 1 27.01.2014 str. 8 Błędnie
Bardziej szczegółowoZakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW.
Zakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW. Historia zmian Lp. Data zmiany Miejsce zmiany Powód zmiany Zmiana 1 27.01.2014 Kod TRN -
Bardziej szczegółowoObsługa aplikacji Walne Zgromadzenia. Instrukcja użytkownika. wersja 6.1
Obsługa aplikacji Walne Zgromadzenia Instrukcja użytkownika wersja 6.1 Spis treści Logowanie użytkownika do systemu... 3 Obsługa aplikacji... 5 Okno główne systemu... 5 Pobieranie wykazu osób uprawnionych
Bardziej szczegółowoKonsolidacja FP- Depozyty
Instrukcja użytkowania modułu Konsolidacja FP- Depozyty w ramach systemu BGK@24BIZNES BGK PEWNY PARTNER Kwiecień 2011 Spis Treści Wstęp... 3 Konsolidacja FP Depozyty... 3 1. Przeglądanie listy dyspozycji
Bardziej szczegółowoSpecyfikacja HTTP API. Wersja 1.6
Specyfikacja HTTP API Wersja 1.6 1. Wprowadzenie Platforma PlaySMS umożliwia masową rozsyłkę SMS-ów oraz MMS-ów marketingowych. Umożliwiamy integrację naszej platformy z dowolnym systemem komputerowym
Bardziej szczegółowoDefiniowanie filtrów IP
Definiowanie filtrów IP Spis treści 1. Klienci korporacyjni... 3 1.1. def3000/ceb... 3 2. Klienci detaliczni... 6 2.1. def2500/reb... 6 2 1. Klienci korporacyjni 1.1. def3000/ceb Dla każdego Klienta korporacyjnego,
Bardziej szczegółowoStruktura pliku wejściowego ippk Plik Składkowy
Struktura pliku wejściowego ippk Plik Składkowy INFORMACJE OGÓLNE... 3 STRUKTURA PLIKU... 3 STRUKTURA FORMATU... 3 DOPUSZCZALNE WARTOŚĆI W POLACH SŁOWNIKOWYCH... 4 ŁADOWANIE PLIKU... 4 INFORMACJE OGÓLNE
Bardziej szczegółowoZakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW.
Zakres i warunki raportowania transakcji ETD przez KDPW_CCP do repozytorium transakcji prowadzonego przez KDPW. Historia zmian Lp. Data zmiany Miejsce zmiany Powód zmiany Zmiana 1 27.01.2014 Kod TRN -
Bardziej szczegółowoStruktura pliku wejściowego ippk Plik Rejestracyjny
Struktura pliku wejściowego ippk Plik Rejestracyjny INFORMACJE OGÓLNE... 3 STRUKTURA PLIKU... 3 STRUKTURA FORMATU... 3 DOPUSZCZALNE WARTOŚĆI W POLACH SŁOWNIKOWYCH. Błąd! Nie zdefiniowano zakładki. ŁADOWANIE
Bardziej szczegółowoNowe funkcje w programie Forte Finanse i Księgowość
Forte Finanse i Księgowość 1 / 11 Nowe funkcje w programie Forte Finanse i Księgowość Spis treści : Korzyści z zakupu nowej wersji 2 Forte Finanse i Księgowość w wersji 2011.b 3 Nowe wzory deklaracji VAT
Bardziej szczegółowo1. Rejestracja 2. Logowanie 3. Zgłaszanie nowego wniosku projektowego
1. Rejestracja Dostęp do wniosku projektowego możliwy jest jedynie dla zarejestrowanych użytkowników. Aby zostać zarejestrowanym należy wypełnić formularz dostępny na stronie www.polskapomoc.gov.pl, a
Bardziej szczegółowoInstrukcja obsługi Zaplecza epk w zakresie zarządzania tłumaczeniami opisów procedur, publikacji oraz poradników przedsiębiorcy
Instrukcja obsługi Zaplecza epk w zakresie zarządzania tłumaczeniami opisów procedur, publikacji oraz poradników przedsiębiorcy Spis treści: 1 WSTĘP... 3 2 DOSTĘP DO SYSTEMU... 3 3 OPIS OGÓLNY SEKCJI TŁUMACZENIA...
Bardziej szczegółowoAdvanced Tax File Edit
JDExperts Sp. z o.o. Advanced Tax File Edit Dokumentacja modyfikacji Spis treści 1 Założenia modyfikacji... 2 1.1 Elementy rozwiązania... 2 1.2 Opis rozwiązania... 2 1.3 Ograniczenia rozwiązania... 2 2
Bardziej szczegółowoInstrukcja obsługi Generatora
Słowniczek: Wniosek wniosek składany jest po raz pierwszy w danym naborze. Wniosek (korekta) składany jest po ocenie w przypadku, gdy Wnioskodawca otrzyma uwagi do Wniosku i tym samy jest zobligowany do
Bardziej szczegółowoNowe funkcje w programie Symfonia Finanse i Księgowość
Symfonia Finanse i Księgowość 1 / 11 Nowe funkcje w programie Symfonia Finanse i Księgowość Spis treści : Korzyści z zakupu nowej wersji 2 Symfonia Finanse i Księgowość w wersji 2011.1.b 3 Nowe wzory deklaracji
Bardziej szczegółowoPOZYCJA W TABELI RTS148/2013 / ITS1247/2012 TAG KOMUNIKATU TRAR.INS.001.01 NAZWA KROTNOŚĆ TYP DANYCH LP.
LP. TAG KOMUNIKATU TRAR.INS.001.01 NAZWA KROTNOŚĆ TYP DANYCH POZYCJA W TABELI RTS148/2013 / ITS1247/2012 OPIS/ FORMAT/ DOPUSZCZALNE WARTOŚCI PRZYKŁAD/ DODATKOWY OPIS 0 KDPWDocument Komunikat systemu KDPW
Bardziej szczegółowor. Informacja uzupełniająca do Instrukcji w zakresie obsługi w Systemie AES dla użytkowników zewnętrznych, wersja 1.0
16.05.2018r. Informacja uzupełniająca do Instrukcji w zakresie obsługi w Systemie AES dla użytkowników zewnętrznych, wersja 1.0 Ministerstwo Finansów uprzejmie informuje o zmianie brzmienia Sekcji A pkt
Bardziej szczegółowoDokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK.
FK - EDeklaracje Dokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK. W założeniu przyjęto, iż użytkownik
Bardziej szczegółowo"Procedura obsługi certyfikatów dla KDPW_TR (A2A)"
"Procedura obsługi certyfikatów dla KDPW_TR (A2A)" Wersja 1.0 Spis treści Dostęp do Repozytorium transakcji KDPW_TR w trybie A2A... 3 Wymagania systemowe... 4 Wniosek certyfikacyjny... 5 Status zgłoszenia
Bardziej szczegółowoPODRĘCZNIK OBSŁUGI BUSINESSNET
PODRĘCZNIK OBSŁUGI BUSINESSNET. LOGOWANIE. AUTORYZACJA ZLECENIA. NOWY KLUCZ. PRZELEWY 5. ZLECENIA STAŁE 6. MODUŁ PRAWNY 7. DOSTĘP DO DEALINGNET 8. CERTYFIKAT KWALIFIKOWANY JAK ZALOGOWAĆ SIĘ DO BUSINESSNET
Bardziej szczegółowoMateriał informacyjny dotyczący przepływu komunikatów w systemie KDPW_ARM
Materiał informacyjny dotyczący przepływu komunikatów w systemie KDPW_ARM DATA AKTUALIZACJI WERSJA OPIS 13.09.2017 1 Powstanie dokumentu 28.09.2017 2 Aktualizacja materiału w związku z: - dodaniem przepływów
Bardziej szczegółowoOpis modułu Wnioski i Komunikacja w systemie ING BusinessOnLine
Strona 1 z 24 Opis modułu Wnioski i Komunikacja w systemie ING BusinessOnLine 13 maja 2013 roku Strona 2 z 24 1. Wnioski - Nowy wniosek Z poziomu zakładki Nowy wniosek Użytkownik ma możliwość edytowania
Bardziej szczegółowoDoładowania telefonów
Doładowania telefonów 1. Nowe doładowanie W celu zdefiniowania nowego przelewu na doładowanie telefonu pre-paid należy: Z menu systemu wybrać opcję Doładowania telefonów -> Nowe doładowanie Lub W oknie
Bardziej szczegółowoPrzekazywanie danych umożliwiających KDPW publikację informacji o zadłużeniu emitentów
emitentów Projekt: Przygotowanie KDPW do obsługi niepublicznych papierów wartościowych DATA AKTUALIZACJI WERSJA OPIS 01.03.2019 1.0 Powstanie dokumentu SPIS TREŚCI I WSTĘP...2 II PRZEKAZYWANIE DO KDPW
Bardziej szczegółowoZAŁĄCZNIK ROZPORZĄDZENIA DELEGOWANEGO KOMISJI (UE).../...
KOMISJA EUROPEJSKA Bruksela, dnia 19.10.2016 r. C(2016) 6624 final ANNEX 1 ZAŁĄCZNIK do ROZPORZĄDZENIA DELEGOWANEGO KOMISJI (UE).../... zmieniającego rozporządzenie delegowane Komisji (UE) nr 148/2013
Bardziej szczegółowoLeszek Kołakowski Wicedyrektor Działu Strategii i Rozwoju Biznesu KDPW Warszawa, 6 grudnia 2017 r.
Obowiązki w zakresie raportowania transakcji zgodnie z MIFIR/MIFIDII Leszek Kołakowski Wicedyrektor Działu Strategii i Rozwoju Biznesu KDPW Warszawa, 6 grudnia 2017 r. Agenda Art. 26 MiFIR; obowiązek raportowania
Bardziej szczegółowoPODRĘCZNIK OBSŁUGI BUSINESSNET
PODRĘCZNIK OBSŁUGI BUSINESSNET. LOGOWANIE. AUTORYZACJA ZLECENIA. NOWY KLUCZ. PRZELEWY 5. ZLECENIA STAŁE 6. MODUŁ PRAWNY 7. DOSTĘP DO DEALINGNET 8. ANKIETA MIFID 9. CERTYFIKAT KWALIFIKOWANY JAK ZALOGOWAĆ
Bardziej szczegółowoOBSŁUGA APLIKACJI WYPŁATA ŚWIADCZEŃ INSTRUKCJA UŻYTKOWNIKA
OBSŁUGA APLIKACJI WYPŁATA ŚWIADCZEŃ INSTRUKCJA UŻYTKOWNIKA Spis treści 1. Logowanie użytkownika do systemu... 3 2. Obsługa aplikacji... 5 Okno główne systemu... 5 Statusy zdarzeń... 7 3. Rejestrowanie
Bardziej szczegółowoRepozytorium transakcji. Krajowy Depozyt Papierów Wartościowych KIM JESTEŚMY?
USŁUGI KDPW_TR Krajowy Depozyt Papierów Wartościowych Repozytorium transakcji KIM JESTEŚMY? Krajowy Depozyt Papierów Wartościowych jedna z najważniejszych instytucji infrastruktury polskiego rynku finansowego
Bardziej szczegółowoPrzed przystąpieniem do czytania dokumentu, proszę o zapoznanie się z podstawowym dokumentem Instrukcja obsługi AZU dla użytkownika zewnętrznego.
Instrukcja obsługi Aplikacji Zarządzania Uprawnieniami (AZU) dla Administratorów Uprawnień Instytucji (AUI) w Zintegrowanym Systemie Zarządzania Tożsamością (ZSZT) Administrator Uprawnień Instytucji (AUI)
Bardziej szczegółowoPodręcznik Użytkownika LSI WRPO
Podręcznik użytkownika Lokalnego Systemu Informatycznego do obsługi Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2007 2013 w zakresie wypełniania wniosków o dofinansowanie Wersja 1 Podręcznik
Bardziej szczegółowoDokumentacja programu. Zoz. Uzupełnianie kodów terytorialnych w danych osobowych związanych z deklaracjami POZ. Wersja
Dokumentacja programu Zoz Uzupełnianie kodów terytorialnych w danych osobowych związanych z deklaracjami POZ Wersja 1.40.0.0 Zielona Góra 2012-02-29 Wstęp Nowelizacja Rozporządzenia Ministra Zdrowia z
Bardziej szczegółowoZałącznik nr 2 do Umowy Nr. o korzystanie z usługi Identyfikacji Przychodzących Płatności Masowych z dnia.
Załącznik nr 2 do Umowy Nr. o korzystanie z usługi Identyfikacji Przychodzących Płatności Masowych z dnia. Informacja o strukturze pliku, przekazywanego przez Bank dla Klienta za pośrednictwem systemu
Bardziej szczegółowoLista kodów statusów i błędów. w komunikatach XML (ISO 20022) w systemie kdpw_stream
Lista kodów statusów i błędów w komunikatach XML (ISO 20022) w systemie kdpw_stream Warszawa, czerwiec 2013 r. Krajowy Depozyt Papierów Wartościowych S.A. ul. Książęca 4 00-498 Warszawa T 22 537 93 43
Bardziej szczegółowoOgranicz listę klasyfikacji budżetowych do powiązanych z danym kontem księgowym
Zależności i kontrola danych budżetowych w systemie Sz@rk FK 1. Wstęp Począwszy od wersji Sz@rk FK 2011 (11.03.30) wprowadzono do programu finansowoksięgowego nowe możliwości dotyczące kontrolowania poprawności
Bardziej szczegółowoRozdział 1 Cel dokumentu... 2. Rozdział 2 Deklaracja... 3. Rozdział 3 Nagłówek... 4. Rozdział 4 Podmiot1... 6. Rozdział 5 FATCA...
Schema IFT-4(1).xsd Spis treści Rozdział 1 Cel dokumentu... 2 Rozdział 2 Deklaracja... 3 Rozdział 3 Nagłówek... 4 Rozdział 4 Podmiot1... 6 Rozdział 5 FATCA... 7 Rozdział 6 ReportingFI... 8 Rozdział 7 AccountReport...
Bardziej szczegółowoZasady budowy i przekazywania komunikatów XML w systemie kdpw_otc
Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...
Bardziej szczegółowoUWAGA!!! Przed przystąpieniem do zamknięcia roku proszę zrobić kopie bezpieczeństwa
UWAGA!!! Przed przystąpieniem do zamknięcia roku proszę zrobić kopie bezpieczeństwa Następnie należy sprawdzić czy w KOLFK w Słownik i-> Dokumenty-> znajduje się dokument BO- Bilans Otwarcia (w grupie
Bardziej szczegółowoPodręcznik użytkownika Wprowadzający aplikacji Wykaz2
Podręcznik użytkownika Wprowadzający aplikacji Wykaz2 TiMSI Sp z o o ul Czapli 63, 02-781 Warszawa tel : +48 22 644 86 76, fax: +48 22 644 78 52 NIP: 951-19-39-800 Sąd Rejonowy dla mst Warszawy w Warszawie,
Bardziej szczegółowoW N I O S E K - Tabela ACER Nr 4 i Dane Fundamentalne
Formularz - Numer. (Wypełnia TGE RRM) Kod ACER. (Wypełnia Wnioskodawca) Kod EIC. (Wypełnia Wnioskodawca) Komentarz [SP1]: Należy podać prawidłowy Kod ACER w przypadku raportowania danych fundamentalnych.
Bardziej szczegółowoPROCES AKTUALIZACJI DANYCH PODMIOTU W KRAJOWEJ BAZIE O EMISJACH GAZÓW CIEPLARNIANYCH I INNYCH SUBSTANCJI
PROCES AKTUALIZACJI DANYCH PODMIOTU W KRAJOWEJ BAZIE O EMISJACH GAZÓW CIEPLARNIANYCH I INNYCH SUBSTANCJI Instrukcja wypełniania formularza aktualizacji danych podmiotu w Krajowej bazie o emisjach gazów
Bardziej szczegółowoCZYM JEST KOD LEI? Przykładowa struktura kodu LEI na bazie identyfikatora nadanego przez KDPW. Znaki 1-4 Znaki 5-6 Znaki 7-18 Znaki 19-20
KOD LEI Krajowy Depozyt Papierów Wartościowych KOD LEI CZYM JEST KOD LEI? Kod LEI to 20 znakowy, alfa-numeryczny identyfikator podmiotu zgodny z normą ISO17442 nadawany przez tzw. jednostki LOU (Local
Bardziej szczegółowo2. Dokumenty, o których mowa w ust. 1, mają formę dokumentu elektronicznego.
Uchwała Nr 595 / 07 Zarządu Krajowego Depozytu Papierów Wartościowych S.A. z dnia 17 sierpnia 2007 r. w sprawie określenia wzoru i formy dokumentów stanowiących podstawę rozliczania transakcji oraz dokonywania
Bardziej szczegółowoSystem imed24 Instrukcja Moduł Finanse
System imed24 Instrukcja Moduł Finanse Instrukcja obowiązująca do wersji 1.8.0 Spis treści 1. Moduł Finanse... 4 1. Menu górne modułu Finanse... 4 1.1.1. Słownik towarów i usług... 4 1.1.1.1. Tworzenie
Bardziej szczegółowoSzczegółowa charakterystyka wybranych aspektów raportowania transakcji na instrumentach pochodnych część II
Szczegółowa charakterystyka wybranych aspektów raportowania transakcji na instrumentach pochodnych część II Adam W. Błasiak Departament Firm Inwestycyjnych i Infrastruktury Rynku Kapitałowego Urząd Komisji
Bardziej szczegółowoPROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest
PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ Opis działania raportów w ClearQuest Historia zmian Data Wersja Opis Autor 2008.08.26 1.0 Utworzenie dokumentu. Wersja bazowa dokumentu. 2009.12.11 1.1
Bardziej szczegółowoidentyfikator transakcji nadany przez KDPW_CCP identyfikator transakcji nadany przez platformę konfirmacji
1. Daily Variation: Current MTM Baseline MTM/Settled MTM Daily Variation/Settlement PAI/PAA Type bieżąca wycena transakcji wyrażona w walucie transakcji wycena transakcji na poprzedni dzień roboczy wyrażona
Bardziej szczegółowo1.0 v2. INSTRUKCJA OBSŁUGI SAD EC Win - Moduł Ewidencja Banderol
Usługi Informatyczne i Elektroniczne mgr inż. Jacek Cenzartowicz ul.łukasińskiego 116 pok. 125 PL 71-215 Szczecin, tel. (+48 600) 968995, 969457, 922589 tel. (+48 91) 4824-431 e-mail j.cenzartowicz@sadec.pl
Bardziej szczegółowoB2B Obsługa portalu zgłoszeniowego
B2B Obsługa portalu zgłoszeniowego Spis treści 1. Ustalenia loginu i hasła, reset hasła... 1 1.1 Ustalenia hasła przez użytkownika... 1 2. Logowanie do systemu uprawnienia pełne/uproszczone... 2 2.1 Uprawnienia
Bardziej szczegółowo1. Otwieranie kont w KDPW_CCP wykorzystywanych w celu rejestracji transakcji zestawianych na platformie konfirmacji OTC MarkitWire
1. Otwieranie kont w KDPW_CCP wykorzystywanych w celu rejestracji transakcji zestawianych na platformie konfirmacji OTC MarkitWire Uzyskanie Numerów Klasyfikacyjnych Klienta (NKK) i otwarcie kont rozliczeniowych,
Bardziej szczegółowoI. Interfejs użytkownika.
Ćwiczenia z użytkowania systemu MFG/PRO 1 I. Interfejs użytkownika. MFG/PRO w wersji eb2 umożliwia wybór użytkownikowi jednego z trzech dostępnych interfejsów graficznych: a) tekstowego (wybór z menu:
Bardziej szczegółowoZAŁĄCZNIKI ROZPORZĄDZENIA DELEGOWANEGO KOMISJI (UE) /
KOMISJA EUROPEJSKA Bruksela, dnia 13.12.2018 r. C(2018) 8332 final ANNEXES 1 to 2 ZAŁĄCZNIKI do ROZPORZĄDZENIA DELEGOWANEGO KOMISJI (UE) / uzupełniającego rozporząd Parlamentu Europejskiego i Rady (UE)
Bardziej szczegółowo1.0 v2. INSTRUKCJA OBSŁUGI SAD EC Win - Moduł Monitorowanie GRN
Usługi Informatyczne i Elektroniczne mgr inż. Jacek Cenzartowicz ul.łukasińskiego 116 pok. 125 PL 71-215 Szczecin, tel. (+48 600) 968995, 969457, 922589 tel. (+48 91) 4824-431 e-mail j.cenzartowicz@sadec.pl
Bardziej szczegółowo58 Zjazd Naukowy PTChem. Zgłaszanie abstraktów
58 Zjazd Naukowy PTChem Zgłaszanie abstraktów Przewodnik użytkownika v1.3 ptchem2015.ug.edu.pl pypassion.com - to inżynieria, nie sztuka 1/11 I. WPROWADZENIE Szanowni Państwo, Przed przystąpieniem do wypełniania
Bardziej szczegółowoKANCELARYJNY SYSTEM PODATKOWY
KANCELARYJNY SYSTEM PODATKOWY Korekta Podatku dochodowego oraz Podatku VAT związana z niezapłaconymi fakturami Opracował: Katowice, Luty 2013 Ze względu na obowiązujące od 2013 roku zmiany dotyczące obliczania
Bardziej szczegółowoAPI transakcyjne BitMarket.pl
API transakcyjne BitMarket.pl Wersja 20140402 1. Sposób łączenia się z API... 2 1.1. Klucze API... 2 1.2. Podpisywanie wiadomości... 2 1.3. Parametr tonce... 2 1.4. Limity zapytań... 3 1.5. Odpowiedzi
Bardziej szczegółowoWykaz zmian w programie SysLoger
Wykaz zmian w programie SysLoger Pierwsza wersja programu 1.0.0.1 powstała we wrześniu 2011. Funkcjonalność pierwszej wersji programu: 1. Zapis logów do pliku tekstowego, 2. Powiadamianie e-mail tylko
Bardziej szczegółowoProcedura obsługi certyfikatów KDPW_TR (A2A) I DOSTĘP DO REPOZYTORIUM TRANSAKCJI KDPW_TR W TRYBIE A2A... 2 II WYMAGANIA SYSTEMOWE...
Procedura obsługi certyfikatów KDPW_TR (A2A) Spis treści I DOSTĘP DO REPOZYTORIUM TRANSAKCJI KDPW_TR W TRYBIE A2A... 2 II WYMAGANIA SYSTEMOWE... 2 III WNIOSEK CERTYFIKACYJNY... 3 IV STATUS ZGŁOSZENIA CERTYFIKACYJNEGO...
Bardziej szczegółowoINSTRUKCJA OBŁUGI APLIKACJI ASSECO MAA
INSTRUKCJA OBŁUGI APLIKACJI ASSECO MAA 1. REJESTRACJA URZĄDZENIA AUTORYZUJĄCEGO W celu zarejestrowania urządzenia autoryzującego, w aplikacji mobilnej Asseco MAA należy wybrać przycisk [ROZPOCZNIJ]. Strona
Bardziej szczegółowoKonfiguracja i uruchomienie usługi Filtry adresów IP dla użytkowników Centrum Usług Internetowych dla Klientów Banku Spółdzielczego w Łęcznej.
Konfiguracja i uruchomienie usługi Filtry adresów IP dla użytkowników Centrum Usług Internetowych dla Klientów Banku Spółdzielczego w Łęcznej. Łęczna 2015 Historia zmian L.p. Data Autor Wersja systemu
Bardziej szczegółowoStruktura pliku wejściowego ipko biznes przelewy zagraniczne (MT103 / CSV)
Struktura pliku wejściowego ipko biznes przelewy zagraniczne (T103 / CSV) 1 Spis treści 1. Informacje ogólne... 3 2. Struktura pliku PLA/T103... 3 2.1. Opis formatu pliku... 3 2.2. Struktura pliku... 4
Bardziej szczegółowoZasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP
Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw
Bardziej szczegółowo