VALIDATION LEVEL 2

Transkrypt

VALIDATION LEVEL 2

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 w procesie raportowania
 Relacje z ESMA
 Zmiany w obsłudze AT, identyfikacji oraz procesie rekoncyliacji
 Identyfikacja – kody LEI, aktualizacja identyfikatora do kodu LEI
 LEI – walidacja level 2, step 2 – konsekwencje
 Zmiany w procesie rekoncyliacji
 Krytyczne zmiany w procesowaniu raportów
 Zmiany w obsłudze AT
 Nowe funkcjonalności
 Nowe pola, walidacje level 2, zmiany w komunikatach xml
 Nowe pola
 Nowe kontrole – tabela walidacji level 2
 Zmiany w komunikatach
2
Zmiany – informacje ogólne
3
KDPW_TR STATYSTYKI (na dzień 19 czerwca 2015 r.) 1/4
Liczba uczestników KDPW_TR – 210
 Generalni Uczestnicy Raportujący (GUR) – 15
 Zwykli Uczestnicy Raportujący (ZUR) – 55
 Pośredni Uczestnicy Raportujący (PUR) – 140
 Komercyjni Użytkownicy Repozytorium (KUR) – 5
 Liczba nadzorców – 11, w tym ESMA
Liczba kontrahentów
objętych raportami: 9 432
4
KDPW_TR STATYSTYKI 2/4
Liczba raportów otrzymanych przez KDPW_TR od lutego 2014 r. do 19 czerwca 2015 r:
5
Wzrost odrzucanej liczby raportów po wprowadzeniu walidacji poziomu 1;
6
 Odsetek transakcji anulowanych AT=E oraz ponownie raportowanych na bazie tego
samego klucza, które powinny zostać obsłużone w alternatywny sposób: 0,27%
 Odsetek parowania/ matchowania transakcji w procesie rekoncyliacji.
-
39% raportów (ok. 17 mln) nie wymaga udziału w rekoncyliacji – brak obowiązku
raportowania drugiej strony;
-
Z tych które wymagają zestawiania, ok. 24% (ok. 10 mln) to raporty, w których jedna lub
obie strony transakcji nie są identyfikowane ważnym kodem LEI;
-
Do rekoncyliacji włączane jest codziennie ok. 16,5 mln raportów, z czego wewnętrznie
paruje się ok. 95%, a status MACH otrzymuje ok. 95%;
-
Do rekonycliacji z innymi RT trafia codziennie ok. 800 tys. raportów (tj. niecałe 2%
wszystkich raportów przechowywanych w RT), z czego paruje się ok. 15%, status MACH –
0%;
7
VALIDATION LEVEL 2
 Walidacje poziomu 2 zostały opublikowane przez ESMA dnia 27/04/2015.
Jednocześnie ESMA opublikowała aktualizację dokumentu „Question &
Answers”.
 Walidacje poziomu 2 – zakres.
 Nowe kontrole zależne od typu raportowanego kontraktu pochodnego.
 TR question 20b – proponowany sposób wdrożenia walidacji poziomu 2.
 Utrzymanie równolegle dwóch sposobów kontroli raportów – konsekwencje.
 Wdrożenie jednolitego sposobu walidacji – konsekwencje.
8
NOWE FUNKCJONALNOŚCI 1/2
 Możliwość aktualizacji identyfikatora kontrahenta/ drugiego kontrahenta w
przesłanych już raportach do kodu LEI.
 Zmiany w komunikatach – uspójnienie komunikatów xml z zakresem
walidacji poziomu 2.
 Zmiany w procesowaniu błędnych raportów (AT=E), konsekwencje tych
zmian.
 Zastąpienie AT=E (PUR) poprzez AT=O (PUR).
9
NOWE FUNKCJONALNOŚCI 2/2
 Zmiany w przebiegu obsługi poszczególnych typów komunikatów (AT)
(zakres wypełniania komunikatów, notyfikacja).
 Update historii, uzupełnienie historii raportu (EligDt).
 Podział na transakcje zapadłe (maturity date, AT=T) oraz sterminowane
(termination date, AT=C).
 Powołanie nowych pól, udostępnianie statusów raportów, wykorzystanie w
komunikacie funkcji delete=Y.
10
DALSZE ZMIANY – INFORMACJE OGÓLNE C.D.
 Planowane rozszerzenie kontroli identyfikatorów LEI o ich status (step 2).
 Kody LEI dla osób fizycznych prowadzących działalność gospodarczą – etap
uzgodnień z ROC.
 Relacje z ESMA – wdrożenie nowych standardów technicznych.
 Potwierdzenie przyjęcia raportów do przetworzenia.
11
Zmiany w obsłudze AT, identyfikacji oraz
procesie rekoncyliacji
12
Zmiana wymagań przy w identyfikacji raportów
W związku z walidacją Level 2 znacząco rozszerzy się zakres potencjalnie
odrzucanych raportów. W szczególności wynikać będzie to z dwóch
czynników.
 Zmiana podejścia do raportów AT=E. Po zgłoszeniu AT=E, żadna ze stron
danej transakcji nie będzie mogła użyć tego samego TID do zaraportowania
transakcji między sobą.
 Odrzucanie raportów w przypadku użycia nieważnego kodu LEI, na skutek:
 Niezgodności z normą ISO 17442 LEI Standard w zakresie formatu i
cyfry kontrolnej;
 Nieważnego Statusu Rejestracji kodu. Bardzo prawdopodobne jest
również, iż wymóg ten, zdefiniowany w step 2 do walidacji Level 2,
zostanie wdrożony równolegle z wszystkimi innymi zmianami.
13
Nowa obsługa AT=E w procesie raportowania
Zgłoszenie AT=E ograniczone jest wyłącznie do jednej funkcjonalności –
całkowite usunięcie danego raportu z bazy Repozytorium.
 W wyniku przetworzenia AT=E nie będzie możliwości ponownego zaraportowania
transakcji z tymi samymi TID; CP1 i CP2.
 Jedynym akceptowanym raportem złożonym przez drugą stronę, będzie AT=E do
raportu drugiego Kontrahenta.
 W praktyce AT=E powinno być stosowane wyłącznie gdy błąd dotyczył tzw. Klucza
transakcji, czyli któregoś z trzech identyfikatorów: TID; CP1, CP2.
 Przestaje funkcjonować AT=E zgłaszane dotychczas do zmian raportów, czyli do
zgłoszeń różnych od AT=N. Ewentualne błędy czy sprostowania w polach z poza
Klucza będzie można realizować przez merytorycznie właściwy AT, tym samym
udostępniona zostanie funkcjonalność:
 Modyfikowania wszystkich pól poza Kluczem transakcji;
 Nadpisywania fragmentu historii transakcji.
14
Odstąpienie od AT=E wykonywanego przez PUR
Konsekwencje jakie niesie za sobą zaraportowanie AT=E wymusiły zmiany w obsłudze
zgłoszeń błędów dokonywanych przez PUR
 Możliwość zgłoszenia AT=E przysługuje jedynie Uczestnikom Raportującym (UR), tym
samym PUR traci tą funkcjonalność.
 W zamian PUR uzyskuje możliwość poinformowania UR o konieczności korekty raportu.
 Funkcjonalność ta będzie dostępna dla PUR wyłącznie via U2A;
 Zgłoszenie będzie realizowana przez AT=O.
 Po zgłoszeniu AT O przez PUR system Repozytorium wygeneruje do UR
komunikat notyfikujący trar.ntf.001.01 z odpowiednim statusem i kodem przyczyny
oraz z kodem LEI Kontrahenta kwestionującego raport.
 Komunikat notyfikujący do UR zostanie wysłany przez kanał, którym została
zgłoszona dana transakcja.
 W kanale U2A zostanie powołana dedykowana zakładka „Counterparty
notifications” do której trafiać będą komunikaty notyfikacyjne informujące o
zgłoszeniu PUR.
15
LEI – rozszerzenie kontroli kodów w raportach – krok 1
 Obecnie Repozytorium kontroluje kody LEI dla CP1 i CP2, w przypadku gdy kod jest
nieważny do UR komunikatem statusowym wysyłana jest stosowna informacja.
Raport jest jednak przyjmowany.
 Wraz z wdrożeniem Validacji level 2 sprawdzana będzie długość identyfikatora (= 20
znaków alfanumerycznych) i cyfra kontrolna (zgodnie z ISO 17442). Komunikat nie
spełniający tych kryteriów będzie odrzucany.
 Walidacje Level 2 rozszerzają zakres kontrolowanych pól o wszystkie pozycje
występujące w Standardach Technicznych, w których używany jest kod LEI, czyli:
 CP1 (w typie LEIC),
 CP2 (w typie LEIC),
 Clearing Member ID (w typie LEIC),
 Broker ID (w typie LEIC),
 Beneficiary ID (w typie LEIC),
 CCP,
 Underlying (w type L-LEI).
16
LEI – rozszerzenie kontroli kodów w raportach – krok 2
 W opublikowanym przez ESMA dokumencie Validation 2 zdefiniowany został Step 2 dla
walidacji kodów LEI, oparty o Status Rejestracji kodu LEI, który zakłada odrzucanie
raportów, w których Kontrahent identyfikowany jest nieaktywnym kodem LEI.
 Wdrożenie tego kroku nastąpi trzy miesiące od decyzji ESMA o zaimplementowaniu tych
kontroli, o czym niezwłocznie Państwa poinformujemy. Bardzo prawdopodobna jest
sytuacja, w którym kontrola ta wejdzie jednocześnie z innymi walidacjami Level 2.
 Kontrola przeprowadzana będzie w oparciu o Statusy Rejestracji kodów LEI zamieszczone
w Globalnym Repozytorium Kodów LEI prowadzonym przez GLEIF.

Akceptowane będą raporty z poniższymi Statusami Rejestracji:
 Dla pola CP1: ISSUED, PEDNING TRANSFER, PENDING ARCHIVAL.
 Dla pól CP2 , Clearing Member ID, Broker, Beneficiary ID, CCP:
ISSUED, PEDNING TRANSFER, PENDING ARCHIVAL , LAPSED.
Raporty nie spełniające tych kryteriów będą odrzucane!
17
Podstawowe zmiany w procesie Rekoncyliacji
Do procesu rekoncyliacji włączane są tylko te raporty, w których podano poprawne kody LEI
obu Kontrahentów oraz poprawny identyfikator UTI.
 TID - maksymalnie 52 alfanumerycznych znaków oraz:
 Dozwolone znaki specjalne w tym polu to: ":", ".", "-", " _";
 Dla raportów przesłanych przed końcem grudnia 2015 r. dozwolona jest również
spacja;
 Znaki specjalne nie mogą wystąpić na początku i na końcu pola.
 Identyfikator LEI walidowany będzie zgodnie z Centralnym Repozytorium LEI na
przyjęciu transakcji. Statusy kodów akceptowane dla CP1 i CP2 przedstawione zostały
na poprzednim slajdzie.
 Powtórna walidacja LEI jest przeprowadzana każdego dnia przy generowaniu rejestru
rekoncyliacji.
 W
procesie
rekoncyliacji uwzględniane są kody LEI ze
statusem:
ISSUED,
TRANSFERRED, PEDNING TRANSFER, PENDING ARCHIVAL i LAPSED.
18
Dalsze zmiany w procesie Rekoncyliacji
 Nowe statusy koncyliacyjne do oznaczenie błędnych kodów LEI Kontrahentów:
 Nieprawidłowy kod LEI 1 – status ERL1;
 Nieprawidłowy kod LEI 2 – status ERL2;
 Dodatkowa kontrola dla transakcji zgłaszanych jednostronnie, w których wskazano, że druga
strona jest spoza EOG.
 Co do zasady, jak to ma miejsce obecnie raporty nie wchodzą do Rekoncyliacji gdy CP2
jest oznaczony jako podmiot z poza OEG;
 Jeżeli jednak odnaleziony zostanie raport drugiej strony i jednocześnie w raporcie tym
Kontrahent jest oznaczony kodem kraju ze strefy EOG, wówczas transakcja jest
odzyskiwana dla procesu rekoncyliacji, a do właściwego UR kierowany jest komunikat
trar.rcn.001.01 z kodem błędu: CPCT „Błędne wypełnienie pola NonEEACtrPty”.
 Rekoncyliacji podlegają wyłącznie transakcje. Tym samym wyłączone zostają z niej pozycje,
czyli:
 Raporty głoszone ze znacznikiem Compression „Y”;
 Transakcje zmodyfikowane przez AT=Z.
19
Zmiana identyfikatora Kontrahenta
Uczestnik Raportujący będzie mógł zmodyfikować identyfikator Kontrahenta danego
podmiotu we wszystkich zaraportowanych przez siebie transakcjach w związku z
przejściem z identyfikatora własnego na kod LEI.
 Funkcjonalność ta nie będzie służyć do modyfikowania Klucza transakcji z uwagi na
wystąpienie błędu w trakcie raportowania. Służy jedynie do zmiany Identyfikatora
Kontrahenta typu Interim na LEI w związku z wejściem podmiotu w jego posiadanie.
 Zmiana realizowana będzie dedykowanym komunikatem trar.ins.006.01, w którym
definiowany będzie stary i nowy identyfikator. Po przetworzeniu zgłoszenia UR otrzyma
trat.sts.002.01 ze statusem PACK lube ERRO.
 Zmiana obejmować będzie zarówno pola CP1 jak i CP2 w obrębie transakcji
zaraportowanych przez danego UR.
 Po przetworzeniu komunikatu założona zostanie nowa mutacja transakcji (At M) z nowym
identyfikatorem Kontrahenta. Wszystkie dotychczasowe mutacje zostaną nadpisane.
20
Aktualizacja danych w przesłanych raportach
Co zamiast AT=E do mutacji/części historii?
Modyfikacja odpowiednim AT, czyli nadpisanie historii zaraportowanej transakcji
Opcja 1: Od podanej daty (Eligibility Date From)
Opcja 2: W podanym okresie czasu (od Eligibility Date From do Eligibility Date To)
Uwaga!: Nie wymagane jest anulowanie uprzednio przesłanych raportów.
Dopuszcza się modyfikację wszystkich pól, z wykluczeniem klucza transakcji (tj. CP1+CP2+TradID).
21
Eligibility Date -> Eligibility Date From + Eligibility Date To
Zasady:
•
Data Eligibility Date From będzie wymagana w każdym komunikacie.
•
Jeśli data Eligibility Date To nie jest wypełniona a data Eligibility Date From jest większa od daty
obowiązywania ostatniej mutacji to tworzony jest kolejny wpis obowiązujący od daty Eligibility Date From
(Przykład1).
•
Jeśli data Eligibility Date To jest wypełniona to historia transakcji zostanie nadpisana w podanym
zakresie od Eligibility Date From do Eligibility Date To – działa tylko dla AT=M, V lub Z, w pozostałych AT
Eligibility Date To jest ignorowana (Przykład 2).
•
Jeśli data Eligibility Date To nie jest wypełniona a data Eligibility Date From jest mniejsza lub
równa od daty obowiązywania ostatniej mutacji to tworzony jest wpis obowiązujący od daty
Eligibility Date From, a dotychczasowa historia od daty Eligibility Date From przestanie być
obowiązująca i widoczna (Przykład 3).
•
Dotyczy to zarówno komunikatów podstawowych trar.ins.001, jak i komunikatów zbiorczych trar.ins.02,
trar.ins.03, trar.ins.04.
22
Przykład 1
Do tej pory:
Po wprowadzeniu zmian:
Przykładowy raport historii transakcji:
•
•
•
•
•
AT=N, EligDt=2015-05-01, SMR1, Valuation1….
AT=V, EligDt=2015-05-02, SMR2, Valuation2 ….
…
Dodanie wyceny z dnia 2015-05-05:
•
•
AT=N, EligDtFrom=2015-05-01, SMR1, Valuation1….
•
AT=V, EligDtFrom=2015-05-02, SMR2, Valuation2 ….
•
AT=V, EligDtFrom=2015-05-03, SMR3, Valuation3
•
AT=V, EligDtFrom=2015-05-04, SMR4, Valuation4 ….
•
…
•
…
Dodanie wyceny z dnia 2015-05-05:
•
AT=V, EligDtFrom=2015-05-05, EligDtTo=NULL, SMR5, Valuation5 ….
•
•
•
•
•
•
•
•
•
•
•
•
…
…
23
Przykład 2
Do tej pory:
Przykładowy raport historii transakcji po modyfikacji:
•
•
•
•
•
•
•
•
•
•
•
•
AT=V, EligDt=2015-05-05, SMR5. Valuation5 ….
…
AT=V, EligDt=2015-05-03, SMR3, Valuation3_1 ….
…
Aby zmodyfikować wycenę SMR3 i zachować dalszą
historię bez zmian należy przesłać:
•
AT=E do SMR5, SMR4, SMR3.
oraz:
•
AT=V, EligDt=2015-05-03, SMR6, Valuation3_1,…
•
AT=V, EligDt=2015-05-04, SMR7, Valuation4, ….
•
AT=V, EligDt=2015-05-05, SMR8, Valuation5, …
24
Przykład 2 c.d.
Po wprowadzeniu zmian:
•
•
•
•
•
•
•
•
•
•
•
•
…
AT=V, EligDt=2015-05-03, SMR3, Valuation3_1 ….
…
Aby zmodyfikować wycenę SMR3 i zachować dalszą historię bez zmian
należy przesłać:
•
AT=V, EligDtFrom=2015-05-03, EligDtTo=2015-05-03, Valuation3_1
25
Przykład 3
Po wprowadzeniu zmian: przesłanie komunikatu z niewypełniona datą EligDtTo usuwa historię
od podanej daty EligDtFrom
•
•
•
•
•
•
•
•
•
•
…
…
Komunikat AT=V, EligDtFrom=2015-05-03, EligDtTo=NULL, SMR6, Valuation 6
26
Zmiany związane z terminacją i wygasaniem transakcji
Definicje
•
•
Wygaśnięcie – zakończenie aktywności danej transakcji/pozycji w dniu wygaśnięcia podanej w
polu Maturity date;
Terminacja
 Terminacja częściowa – zakończenie aktywności części kontraktów danej transakcji/pozycji
w dniu terminacji podanej w polu Termination Date;
 Terminacja całkowita - zakończenie aktywności wszystkich kontraktów danej
transakcji/pozycji w dniu terminacji podanej w polu Termination Date;
27
Terminacja - zmiany

W przypadku terminacji raportowane są wolumen i wartość pozostające po wygaszeniu
części bądź wszystkich kontraktów, a nie terminowane wolumen i wartość kontraktów.

W przypadku obu terminacji podanie daty terminacji jest obowiązkowe, przy czym data ta nie
może być większa niż Maturity date (o ile podano).

Dodatkowe kontrole dla pól Notional Amount i Quantity

Status transakcji całkowicie sterminowanej - N (nieaktywny)

Uwaga: Terminacja zbiorcza zawsze traktowana jest jak terminacja całkowita.
28
Automatyczne wygaszanie transakcji
•
Nowo powołany techniczny rodzaj zmiany AT=T.
•
Zakres:
Procesem objęte są wszystkie raporty, w których ostatnia mutacja ma wypełnioną datę Maturity Date.
•
Czas:
Proces uruchamiany będzie każdego dnia roboczego, analogicznie jak dotychczasowe AT=C
wykonywane automatycznie przez Repozytorium KDPW.
•
Działanie:
Dla wszystkich transakcji, w których ostatnia obowiązująca mutacja ma wypełnioną i mniejszą od
daty dzisiejszej datę Maturity Date, tworzony jest wpis AT=T (kod techniczny) z datą obowiązywania
Maturity Date o SMR=’TR_T_’+TrnKeyId. Wszystkie zaraportowane dane zostają bez zmian, a pola
Notional Amount i Quantity są zerowane. Mutacja taka dostaje status rekordu =”N” (nieaktywny).
•
Zmiana w udostępnianiu danych uczestnikom:
O fakcie wygaszenia transakcji uczestnicy są informowani poprzez przesłanie komunikatu
notyfikacyjnego trar.ntf.001.01. Uczestnicy będą poinformowani o technicznym kodzie AT=T oraz o
statusach rekordu = ‘N’.
29
Raportowanie do transakcji nieaktywnych
•
Możliwe jest przesłanie modyfikacji danych (AT=M,V, C) z datą obowiązywania nie późniejszą
niż data wygaśnięcia/terminacji;
•
Modyfikacja daty terminacji odbywa się tylko i wyłącznie za pomocą AT=C, przy zachowaniu
walidacji daty terminacji w stosunku do maturity date, przy czym usunięcie niepoprawnie
przekazanej daty terminacji, możliwa jest jedynie za pomocą AT=M z atrybutem delete=’Y’;
•
Modyfikacja daty wygaśnięcia odbywa się tylko i wyłącznie za pomocą AT=M, przy
zachowaniu wszystkich stosownych kontroli. Zmiana maturity date powoduje powstanie nowej
mutacji o statusie rekordu A-aktywny.
•
Usunięcie terminacji – ‘Restore’ (czyli obecny AT=E do AT=C) - komunikat trar.ins.001,
AT=M, w którym tag Termination Date oznaczony jest atrybutem delete=’Y’ oraz pola Notional
Amount i Quantity wypełniane są niezerowymi wartościami.
30
Nowe pola, kontrole level 2, zmiany w komunikatach
xml
31
VALIDATION LEVEL 2 – zmiany kontroli 1/6
 Rozszerzenie kontroli kodów LEI używanych w procesie raportowania.
UWAGA!
ESMA opublikowała również zakres step 2 walidacji kodów LEI obejmujący
kontrolę statusu kodu i konieczność odrzucania raportów z kodami nie
spełniającymi kryteriów walidacji.
Step 2 wdrożony zostanie w terminie 3 miesięcy od daty decyzji ESMA.
32
 Kontrole związane z identyfikacją kontraktu: Txnm, PrdctId1, PrdctId2 oraz
VenueOfExc.
Txnm
U – skutkować będzie odrzuceniem komunikatu;
I – jeśli wartość pola VenueOfExc nie zawiera się w MIFID database Regulated
Markets lub MIFID database MTF, komunikat będzie odrzucony;
E – jeśli wartość pola VenueOfExc wypełnione jest wartością XOFF lub kodem
MIC z listy MIFID database Regulated Markets, komunikat będzie odrzucony;
PrdctId1
Jeśli w polu Txnm jest wartość I to pole ProductID1 musi być wypełnione kodem
ISIN lub Exchange Product Code.
Jeśli w polu Txnm jest wartość E to dozwolone są tylko wartości: CO, CR, CU,
EQ, IR lub OT.
PrdctId2
Jeśli w polu Txnm jest wartość I to pole ProductID2 musi zawierać kod CFI
zgodny z ISO 10962.
Jeśli w polu Txnm jest wartość E to dozwolone są tylko wartości: CD, FR, FU,
FW, OP, SW lub OT.
33
VenueOfExc
Jeśli pole jest wypełnione wartością ‘XXXX’ lub ‘XOFF’, to komunikat jest
przyjmowany;
W przeciwnym przypadku, jeśli pole wypełnione jest wartością MIC
niezgodną z ISO 15022 to komunikat jest odrzucany;
Jeśli pole wypełnione jest wartością MIC zgodną z ISO 15022 to:
Jeśli kraj wskazany w ISO jest spoza obszaru EEA to komunikat jest
przyjmowany;
Jeśli kraj wskazany w ISO jest z obszaru EEA to:
Jeśli pole jest wypełnione wartością MIC umieszczoną na liście MIFID
database Regulated Markets lub umieszczoną na liście MIFID database
MTF, to komunikat jest przyjmowany; w przeciwnym przypadku komunikat
jest odrzucany.
34
 Kontrole dla pól Underlying i nowego pola Underlying type.
Dla pola Underlying zostaje powołane nowe pole techniczne Underlying type
określające rodzaj użytego w polu Underlying identyfikatora.
Dopuszczalne wartości pola Underlying type:
 I – ISIN
 L – LEI
 B – Basket
 X – Index
 N – Not available
Pole Underlying staje się polem opcjonalnym dla kontraktów identyfikowanych za
pomocą klasyfikacji przejściowej, w których w polu Product ID 1 występuje wartość CO
(towarowy instrument pochodny), IR (instrument pochodny na stopę procentową) bądź
CU (walutowy instrument pochodny).
Dla wartości CO oraz CU tagi opisujące instrument bazowy muszą pozostać puste.
 Underlying technical – pole umożliwiające zaraportowanie instrumentu bazowego poza
standardem na potrzeby danego podmiotu raportującego (np. na potrzeby wyceny
zbiorczej).
35
 Kontrola UTI.
Zgodnie z zasadami omawianymi przy procesie rekoncyliacji.
 Kontrola pola Price Multiplier.
Dozwolone jest raportowanie wartości większych niż zero.
 Kontrola pola Quantity.
 Kontrola pól związanych z datami:
 Effective date;
 Termination date;
 Clearing Timestamp.
 Kontrola pola CCP.
36
 Zasady kontroli poszczególnych pól w sekcji Interest rate.
 Zasady kontroli poszczególnych pól w sekcji Foreign Exchange.
 Zasady kontroli poszczególnych pól w sekcji Commodity.
 Zasady kontroli poszczególnych pól w sekcji Options.
 Umożliwienie raportowania wartości ujemnych w polach:
 Mark to market value of contract




Price/ rate
Notional amount
Up-front payement
Fixed rate of leg 1 (funkcjonalność dostępna uprzednio)
 Fixed rate of leg 2 (funkcjonalność dostępna uprzednio)
 Exchange rate 1
 Forward exchange rate
37
Zmiany w komunikatach xml 1/4
 Zmiany numeracji wersji komunikatów oraz zmiany związane z referencjami:
 odejście od możliwości anulowania pojedynczego wpisu (likwidacja referencji po SMR
komunikatu)
 wzrost znaczenia dat Eligibility Date From oraz Eligibility Date To, które definiują zakres
rekordów objętych zmianą
 Wymagalność pól dla poszczególnych AT:
 AT=N
Wymagalność dotychczasowych pól dla AT=N pozostaje bez zmian. Dodatkowo pojawiają
się nowe pola (Eligibility Date To i Underlying Type) oraz dodatkowe kontrole
implementowane w ramach poszczególnych sekcji dla konkretnych klas kontraktów.
 AT=M
Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID) oraz daty/dat
obowiązywania.
Podawane są wszystkie pola, które mają być modyfikowane.
Wartości pól dotąd wypełnionych, a w komunikacie pominiętych są przepisywane.
Jeśli w komunikacie wystąpi dla modyfikowalnego pola atrybut delete=’Y’, wówczas wartość
uprzednio w tym polu przekazana jest czyszczona.
38
Wymagalność pól dla poszczególnych AT c.d.
 Dla AT={M, C, Z, V}
Istotną zmianą jest sposób obsługi komunikatów dla poszczególnych AT – sekcje
dotąd ignorowane zostały przedefiniowane i określone dla poszczególnych
rodzajów zmian tak, aby wypełnienie sekcji/ tagów nie dotyczących danego AT
skutkowało odrzuceniem komunikatu.
Dokument „Sposób i zakres wypełniania danych dla poszczególnych rodzajów
zmian (AT)” obrazuje poprawny zakres danych oczekiwany dla poszczególnych
rodzajów zmian.
 AT= E
Wymagane jest podanie w referencjach klucza transakcji (CP1+CP2+TID); AT=E
usuwa całą historię i uniemożliwia ponowne zaraportowanie raportu o takim
samym kluczu.
Restrykcja ta dotyczy obu stron transakcji.
39
Anulowanie wartości raportowanych zbiorczo
Co zamiast AT=E do wartości raportowanych zbiorczo?
 AT=C
Usunięcie terminacji zbiorczej odbywa się pojedynczo na transakcję,
trar.ins.001.01 z oznaczeniem atrybutem delete=’Y’ tagu Termination Date.
komunikatem
 AT=V
Usunięcie wyceny lub zabezpieczenia wysłanego zbiorczo odbywa się poprzez wysłanie
odpowiedniego komunikatu zbiorczego, w którym tag sekcji 2.2. (dla trar.ins.002.01) lub sekcji
2.3. i 2.4 (dla trar.ins.003.01) oznaczony jest atrybutem delete=’Y’.
Przyjęcie komunikatu do KDPW_RT powoduje anulowanie wszystkich wycen lub zabezpieczeń
objętych działaniem komunikatu.
40
 Raportowanie na datę lub za wskazany okres czasu.
 Formant delete=Y dla tagu – zasady używania i konsekwencje.
 Udostępnienie statusów raportów.
 Zmiany w interfejsie graficznym – nowe zakładki:
 Transakcje anulowane
 Notyfikacje
41
Dziękujemy za uwagę
Dział Repozytorium Transakcji KDPW_TR
Kontakt:
E-mail: [email protected]
Internet: www.kdpw.pl
Telefon:
Repozytorium Transakcji: + 48 22 537 91 47, + 48 22 537 95 72

VALIDATION LEVEL 2

Transkrypt

Podobne dokumenty

electric castle!

Otwarcie konta internetowego i złożenie wniosku o kod LEI

Formularz badania przeciwciał wścieklizny u psów i

Swoją przygodę, związaną ze studiowaniem architektury

Prace ręczne