Repozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium. Warszawa,10 luty 2014

Transkrypt

1 Repozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium Warszawa,10 luty 2014

2 Agenda Ogólna koncepcja sytemu zapewnienie poufności i bezpieczeństwa Dokumentacja i obsługa komunikatów Rekoncyliacja Zgłoszenie transakcji Zmiana raportu Rozwiązanie kontraktu 2

3 Ogólna koncepcja systemu do obsługi repozytorium Rynek regulowany Rynek regulowany Rynek OTC Instytucje nadzoru Rynek OTC Instytucja nadzoru SLL VPN Uwierzytelnienie/ certyfikat MQ XML A2A Moduł ról i uprawnień SLL VPN Uwierzytelnienie/ certyfikat Dedykowana witryna U2A Witryna www formatka, zaciąganie plików XML Moduł obsługi certyfikatów elektronicznych Kontrola formalna i merytoryczna Baza danych Informacja o transakcjach Baza danych użytkowników 3

4 Zapewnienie poufności W celu zapewnienia bezpieczeństwa danych, przesyłanych pomiędzy aplikacją uczestnika i aplikacją RT KDPW, zastosowano następujące mechanizmy: Poufność oraz integralność transmisji danych dzięki zastosowaniu technologii tunelowania. W ramach dostępów U2A i A2A wykorzystywanie certyfikatu SSL witryny. W przypadku dostępu A2A za pomocą MQ zestawiany jest tunel VPN. Uwierzytelnienie uczestnika/użytkownika w aplikacji realizowane jest na podstawie certyfikatów elektronicznych wydawanych przez Głównego Poręczyciela, będącego pracownikiem KDPW, zgodnie z Regulaminem Głównego poręczyciela (certyfikaty imienne i firmowe). Autoryzacja i kontrola dostępu do poszczególnych funkcjonalności za pomocą uprawnień zdefiniowanych w module ról i uprawnień. 4

5 Obsługa Komunikatów Repozytorium KDPWdokumentacja Dokumentacja opisująca sposób tworzenia komunikatów i wymiany z systemem Repozytorium. Struktura i schematy komunikatów XML Diagramy przepływów komunikatów między uczestnikami a systemem Repozytorium Wypełnienie komunikatu trar.ins sposób i zakres wypełniania pól dla poszczególnych rodzajów zmian Przykładowe wypełnienie komunikatu wartościami dane słownikowe Kody błędów generowane przez system Repozytorium 5

6 Typy komunikatów Komunikaty służące do składania raportów Komunikat podstawowy trar.ins zgłoszenie nowych transakcji zgłaszanie zmian do konkretnego złożonego raportu Komunikaty zbiorcze (służą do zgłaszania zmian do złożonych raportów) trar.ins zbiorcze raportowanie wyceny trar.ins zbiorcze raportowanie zabezpieczeń trar.ins zbiorcze raportowanie terminacji instrumentu finansowego/pozycji trar.ins zbiorcze raportowanie zmian danych kontrahenta Komunikat zgłoszenia przepytującego - trar.rgs Komunikaty zwrotne: trar.sts komunikat ze statusem zgłoszenia trar.sts komunikat ze statusem przetworzenia komunikatu Komunikat o rozbieżności w raportach - trar.rcn Komunikat służący do publikacji danych zagregowanych trar.ifr udostępniany jest do pobrania w serwisie www 6

7 Struktura i schematy komunikatów XML - identyfikatory komunikacyjne Struktura i dokumentacja wszystkich komunikatów zamieszczone zostały na stronie internetowej KDPW w zakładce Repozytorium zgodne z EMIR Komunikaty są budowane zgodnie z obowiązującym w KDPW standardem. Każdy komunikat rozpoczyna się od sekcji KDPWDocument - Dokument systemu KDPW w ramach którego zawarte są czteroznakowe kody komunikacyjne: Sndr nadawcy komunikatu Rcvr - odbiorcy komunikatu Kody te są różne od kodów przypisanych obecnym uczestnikom systemu depozytowo rozliczeniowego i zaczynają się od litery R : RXXX. Repozytorium KDPW został przypisany kod R001. Kodem wystawcy komunikatu (tag TRRprtId) jest kod pre-lei. Każdy uczestnik raportujący jest zobowiązany przekazać ten numer KDPW w momencie występowania o produkcyjne udostępnienieśrodowiska. Krotność Tag-ów - pól i sekcji. Pola w komunikatach dzielą się na: obowiązkowe [1..1] opcjonalne [0..1] 7

8 Wypełnienie komunikatu trar.ins Legenda dokumentu zastosowane oznaczenia M pole obowiązkowe» Pole wymagane. W przypadku braku podania wartości lub pominięcia Tagu komunikat nie zostanie zaczytany do systemu Repozytorium KDPW O- pole opcjonalne» W przypadku podania wartości w polach opcjonalnych zostaną one zapisane w bazie Repozytorium transakcji.» W przypadku pominięcia opcjonalnych sekcji: Dla AT N pole w bazie będzie nie wypełnione W przypadku modyfikacji w danym polu pozostanie wartość dotychczas zapisana w bazie transakcji I - pole ignorowane» W przypadku podania wartości zostanie ona zignorowana, wartości przekazane w dozwolonych komunikatach zostaną przepisane F-pole, które nie może wystąpić, zabronione» W przypadku wypełnienia Tagu komunikat zostanie odrzucony Przykładowe wypełnienie Tagu Nazwa Tag N N BACK M E E (PUR) C Z V O Quantity Qty M M O I I I M I M 8

9 Przykładowe wypełnienie komunikatu wartościami Sposób wypełnienia wartościami komunikatu trar.ins W szczególności pragniemy zwrócić uwagę na wartości jakie powinny być wprowadzane w polach dodatkowych w stosunku do standardów technicznych BckldgInd Znacznik backloading u. Pole pozwalające na jednoznaczne wskazanie czy dany raport związany jest z trybem backloading u (inne badanie terminowości zgłoszeń) czy tez jest to raport bieżący. Dopuszczalne wartości: Y/N OthrCtrPtyInd wskazanie czy druga strona transakcji jest osobą fizyczną, która nie jest zobowiązana do raportowania. Dopuszczalne wartości: Y/N EligDt data obowiązywania zgłoszenia. Pole pozwala na precyzyjne wyznaczenie momentu obowiązywania zgłoszenia w bazie Repozytorium. Dopuszczalne wartości data: np IssrCtry kod kraju emitenta instrumentu bazowego. Pole powołane w związku z koniecznością wywiązania się z obowiązku udostępniania danych wynikającego z art. 2 RTS nr 151/201. Pozwala na jednoznaczną identyfikację kraju emitenta. Dopuszczalne wartości kod kraju, np. PL ClrAcct identyfikator konta rozliczeniowego. Pole powołane w celu umożliwienia segregowania transakcji i dokonywania zbiorczej termniacji. Np

10 Kody błędów generowane przez system Repozytorium W procesie weryfikacji komunikatów wyróżnia się dwa rodzaje błędów Formalne» Plik nie jest plikiem w formacie XML lub nie przechodzi walidacji z XSD» Nadawca komunikatu niezgodny z polem Sndr z XML-a» Typ komunikatu nieobsługiwany przez Repozytorium Transakcji Merytoryczne Każdy błąd merytoryczny posiada odrębne oznaczenie kodowe. Wyróżnia się następujące kategorie błędów:» Brak wypełnienia pola lub sekcji» Błędne wypełnienie pola lub sekcji» Brak możliwości odnalezienia transakcji na podstawie podanych referencji» Brak uprawnień do składania danych raportów lub zapytań» Wykrycie niezgodności w raportach przekazanych przez strony oddzielnie 10

11 Rekoncyliacja ogólne założenia Uzgodnienie szczegółów transakcji spoczywa na stronach transakcji Kluczowe jest uzgodnienie identyfikatora transakcji musi on być unikalny dla danej pary kontrahentów Repozytoria porównują jedynie transakcje, w których strony oznaczone są identyfikatorami LEI Repozytoria wspomagają proces rekoncyliacji wykonując porównanie danych w raportach składanych przez strony oddzielnie Rekoncyliacji nie podlegają transakcje zawarte z osobami fizycznymi i kontrahentami z poza EOG. 11

12 Rekoncyliacja zasady i zakres porównywania Sprawdzanie zgodności danych realizowane jest w dwóch etapach parowanie raportów szukanie raportu złożonego przez drugą stronę LEI obu Kontrahentów + UTI porównanie raportów porównanie szczegółów transakcji W przypadku wykrycia niezgodności komunikatem trar.rcn przekazywany jest kod błędu wskazujący, w którym polu wykryto rozbieżność Uwaga! Nie jest przekazywana wartość jaka została zaraportowana przez drugą stronę. Rekoncyliacja przebiega zarówno w przypadku złożenia oddzielnych raportów dotyczących tej samej transakcji do jednego, jak i do różnych repozytoriów Parowanie i porównanie raportów za dzień T przeprowadzane są w dniu T

13 Składanie raportów nowa transakcja Komunikat służący do składania raportów. Komunikat podstawowy trar.ins AT = N Sprawdzenie uprawnień uczestnika do raportowania Badanie czy kontrahenci posługują się numerem LEI Badanie unikalności klucza: LEI Kontrahenta LEI drugiego kontrahenta Identyfikator transakcji (UTI) Sprawdzenie czy data zawarcia transakcji jest równa dacie bieżącej lub jest mniejsza od daty bieżącej Sprawdzenie czy data obowiązywania = dacie zawarcia transakcji: ExecDtTm = EligDt Uwaga! wyjątkiem jest raportowanie transakcji już zamkniętych w trybie backloadingu. Wówczas data obowiązywania musi być równa dacie terminacji: TrmntnDt = EligDt 13

14 Składanie raportów zmiana raportu Aby odwołać się do już zgłoszonego raportu należy podać referencje W przypadku komunikatu podstawowego trar.ins Dla AT M, V, Z, E SMR poprzedniego raportu lub Klucz transakcji LEI CP1 + LEI CP2 + UTI transakcji Dla AT O badany jest klucz transakcji i dodatkowo większość szczegółów transakcji. W przypadku komunikatów zbiorczych odwołanie odbywa się przez: Identyfikator produktu w przypadku zmiany wyceny (ewentualnie wskazanie strony transakcji i/lub uczestnika raportującego) Kod portfela w przypadku zmiany zabezpieczeń Identyfikator uczestnika rozliczającego i ID konta rozliczeniowego w przypadku zbiorczej terminacji LEI kontrahenta w przypadku zbiorczej modyfikacji danych kontrahenta 14

15 Składanie raportów rozwiązanie kontraktu Rozwiązanie kontraktu AT = C Data terminacji musi być równa dacie obowiązywania i nie może być przyszła TrmntnDt = EligDt Sposoby raportowania: Rozwiązanie pojedynczej transakcji wskazanie daty rozwiązania w komunikacie podstawowym. W komunikacie tym ignorowane są wszystkie inne pola poza TrmntnDt. Zbiorcza terminacja kontraktów komunikatem trar.ins Rozwiązanie kontraktów rozliczanych przez danego uczestnika rozliczającego i na danym koncie rozliczeniowym i/lub na danym instrumencie. Uwaga! System Repozytorium dokonuje automatycznej terminacji kontraktów na podstawie terminu zapadalności MtrtyDt. 15

16 Dziękuję bardzo za uwagę Marcin Wrona Starszy Specjalista