Repozytorium transakcji Specyfikacja funkcjonalna i techniczna

Transkrypt

1 Specyfikacja funkcjonalna i techniczna

2 Zawartość 1. Ogólna charakterystyka OBSZARY ZASTOSOWANIA REPOZYTORIUM TRANSAKCJI ZAKRES GROMADZONYCH INFORMACJI O TRANSAKCJACH FUNKCJONALNOŚĆ REPOZYTORIUM TRANSAKCJI Specyfikacja technologiczna ARCHITEKTURA SYSTEMU INFORMATYCZNEGO, REALIZUJĄCEGO REPOZYTORIUM TRANSAKCJI INTERFACE DO POZYSKIWANIA DANYCH Z SYSTEMU KDPW_STREAM INTERFACE DO POZYSKIWANIA DANYCH Z SYSTEMU SENTINEL INTERFACE EKSPORT DANYCH BILINGOWYCH RAPORTOWANIE TRADE REPOSITORIES TABLE OF FIELDS... 15

3 1. Ogólna charakterystyka 1.1. Obszary zastosowania Uruchomienie ma na celu zgromadzenie w dedykowanym miejscu informacji o transakcjach derywatami z rynku regulowanego, o transakcjach derywatami OTC rozliczanych przez KDPW_CCP oraz transakcjach derytywami nierozliczanymi przez KDPW_CCP, zgłaszanymi przez instytucje zobowiązane Definicja transakcji oraz zakres definiujących je informacji wynika z Regulaminu Wykaz kontrahentów, upoważnionych do rejestrowania transakcji w Repozytorium KDPW wynika z Regulamu Minimalny zakres funkcjonalności Repozytorium, udostępniony kontrahentom zobowiązanym do rejestrowania realizanych transakcji wynika z Regulamu Uruchomienie zostanie zrealizowane w dwóch etapach: I etap: (do listopada 2012) uruchomienie systemu z minimalną funkcjonalnością; II etap: (po ustabilizowaniu wymagań technicznych ESMA oraz instytucji nadzorującej Repoozytorium KDPW) automatyzacja wybranych procesów; rozszerzenie zakresu informacji dotyczących rejestrowanych transakcji.

4 1.2. Zakres gromadzonych informacji o transakcjach W będą gromadzone informacje o transakcjach, określone przez organizację ESMA. Minimalny zakres informacji stanowić będą informacje o transakcjach posiadane obecnie w systemie kdpw_stream. w przypadku braku poszczególnych informacji o transakcjach w systemie kdpw_stream lub Sentinel w stosunku do wymagań ESMA, zostanie podjęta decyzja, czy rozszerzyć zakres obecnie pozyskiwanych informacji od uczestników. W przypadku aplikacji witryny WWW będzie pozyskiwany komplet informacji wymaganych przez ESMA Zakres informacji o transakcji. Zakres informacji wymaganych przez ESMA został zawarty w załączniku.

5 1.3. Funkcjonalność Zakłada się, że będzie funkcjonowało jako zbiór informacji o transakcjach zasilany z trzech źródeł: systemu kdpw_stream (rynek regulowany) systemu Sentinel (rynek OTC rozliczany przez KDPW_CCP) aplikacji witryny WWW (rynek OTC nie rozliczany przez KDPW_CCP) Repozytorium wewnętrzne Rejestr kontrahentów Kdpw_stream Centralna baza danych Hub komunikacyjny XML/MQ message POP3/SMTP ESDI MQ Message ESDK SWIFT ISO15022 Bond Spot Transakcje Repo XML/SWIFT Repozytorium wewnętrzne Sentinel Risk Manager Moduł konwersji Sieć publiczna Banki/Klienci Repozytorium wewnętrzne Portal WWW KDPW Repozytorium transakcji Żródła danych Aktualizacja danych Ze względu na zaniechanie budowy automatycznych interfejsów do zasilania danymi głównego Repozytorium pochodzącymi z systemu Sentinel, kdpw_stream i aplikacji witryny WWW, integracja danych z trzech środowisk: Sentinel, aplikacja witryny WWW i kdpw_stream będzie realizowana w trybie manualnym. Tryb do ustalenia. Optymalnym momentem integracji danych wydaje się etap tworzenia raportu na wniosek instytycji nadzorczej Przegląd i modyfikacja zarejestrowanych transakcji Zakłada się, że kontrahenci rejestrujący transakcje za pośrednictwem kdpw_stream lub Sentinel będą mogli przeglądać i modyfikować informacje o zarejestrowanych transakcjach wyłacznie za pomocą funkcjonalności oferowanych przez te systemy (kdpw_stream i Sentinel).

6 Kontrahenci rejestrujący transakcje za pośrednictwem witryny WWW będą mogli przeglądać, modyfikować i usuwać informacje o zarejestrowanych transakcjach za pomocą funkcjonalności aplikacji witryny WWW Funkcjonalność aplikacji witryny WWW Rejestracja kontrahenta W celu zarejestrowania kontrahenta, upoważnionego przez instytucję posiadającą właściwe relacje z KDPW (określone w Regulaminie repozytorium) do rejestrowania, przeglądania i modyfikowania transakcji w Repozytorium KDPW, zostanie zastosowana procedura rejestracji kontrahenta analogiczna jak w aplikacji do obsługi WZ. Weryfikacja tożsamości kontrahentów W celu identyfikacji kontrahenta w aplikacji witryny WWW, zostanie zastosowana procedura weryfikacji tożsamości kontrahenta analogiczna jak w przypadku aplikacji do obsługi WZ. Rejestrowanie transakcji Przewiduje się dwie metody rejestrowania transakcji za pośrednictwem aplikacji witryny WWW: o za pomocą formularza dostępnego na witrynie, umożliwiającego bezpośrednie wprowadzenie informacji o pojedyńczych transakcjach o przesyłając zbiór w zdefiniowanej strukturze, zawierający zestaw informacji o rejestrowanej transakcji lub wielu transakcji. Na witrynie powinien znaleźć się szczegółowy opis wymaganych informacji o transakcji i opis struktury zbioru). Weryfikacja wprowadzanych informacji o transakcji W obydwu przypadkach, przed zarejestrowaniem transakcji w Repozytorium transakcji, wprowadzone dane powinny zostać zweryfikowane pod kątem ich zgodności ze zdefiniowaną strukturą. Zarejestrowana powinna zostać tylko transakcja zawierająca wymagane dane, o ustalonej strukturze. Przegląd/modyfikacja/usunięcie zarejestrowanych transakcji Kontrahent będzie mógł dokonać przeglądu/modyfikacji/usunięcia tylko transakcji zarejestrowanych przez siebie (transakcji instytucji, w imieniu której rejestruje transakcje), za pomocą aplikacji witryny WWW. Zarejestrowana transakcja powinna posiadać skojarzoną historię zmian, prezentowaną wraz z innymi informacjami o transakcji. Histioria zmian transakcji powinna być szczególnie chroniona przed nieautoryzowaną zmianą Raportowanie W pierwszym etapie projektu, raportowanie będzie realizowane narzędziami i metodami developerskimi. Nie przewiduje się automatyzacji tego procesu

7 Po okresie stabilizacji regulacji definiujących zasady funkcjonowania repozytoriów oraz wypracowaniu praktyk w relacjach nadzorca - KDPW w tym zakresie, zostaną podjęte działania w celu automatyzacji procesu raportowania,

8 2. Specyfikacja technologiczna 2.1. Architektura systemu informatycznego, realizującego Zakłada się, że zostanie zrealizowane na platformie IBM i5 i Share Point: Na platformie IBM i5 zostanie utworzony dedykowany, główny zbiór bazodanowy, zasilany danymi o transakcjach, pochodzącymi z trzech źródeł: kdpw_stream, Sentinel oraz aplikacji portalu WWW. Na platformie Share Point zostanie wykonana aplikacja, realizująca: o rejestrację i weryfikację tożsamości kontrahenta; o rejestrację, przegląd i modyfikację danych dotycących transakcji; o weryfikację wprowadzanyc danych; o prowadzenie historii zmian niezależnie dla każdej transakcji Zasilanie danymi Repozytorium Główny zbiór bazodanowy będzie zasilany danymi przekazywanymi przez system kdpw_stream, Sentinel i aplikację witryny WWW. Formaty danych przekazywanych do głównego zbioru bazodanowego zostana określone na etapie projektu technicznego. W pierwszym etapie nie zakłada się budowy automatycznych interfejsów pomiędzy aplikacją witryny WWW i głównym zbiorem bazodanowym oraz systemem Sentinel i głównym zbiorem bazodanowym. Sposób przekazywania informacji pomiędzy systemem kdpw_stream i głównym zbiorem bazodanowym zostanie określony na etapie projektu technicznego. Wymiana danych o kontrahentach będzie realizowana analogicznie jak w przypadku aplikacji do obsługi WZ.

9 Aplikacja witryny WWW Obsługa transakcji Rejestracja Przegląd Modyfikacja Zarządzanie kontrahentami Baza kontrahentów Wewnętrzna baza danych Import danych z Sentinel Raportowanie Import danych z kdpw_stream Baza danych i5 IBM i5 Ogólny schemat

10 2.2. Interface do pozyskiwania danych z systemu kdpw_stream Do uzgodnienia z DRSI

11 2.3. Interface do pozyskiwania danych z systemu Sentinel W pierwszym etapie projektu nie przewiduje się budowy automatycznego interfejsu do wymiany danych pomiędzy głównym zbiorem bazodanowym i systemem Sentinel Zakłada się opracowanie funkcjonalności systemu Sentinel, uruchamianej okresowo/cyklicznie/podczas wykonywania raportu, polegającej na przygotowaniu dedykowanego zbioru zawierającego wymagane dane o transakcjach Zbiór wyeksportowany z systemu Sentinel będzie przenoszony manualnie na platformę IBM i5, w celu wczytania danych do głównego zbioru bazodanowego Sposób importu danych z systemu Sentinel do Repozytorium zostanie określony na etapie projektu technicznego.

12 2.4. Interface WWW W pierwszym etapie projektu nie przewiduje się budowy automatycznego interfejsu do wymiany danych pomiędzy głównym zbiorem bazodanowym i aplikacją witryny WWW Zakłada się opracowanie funkcjonalności w ramach aplikacji witryny WWW, uruchamianej okresowo/cyklicznie/podczas wykonywania raportu, polegającej na przygotowaniu dedykowanego zbioru zawierającego wymagane dane o transakcjach Zbiór wyeksportowany z aplikacji witryny WWW będzie przenoszony manualnie na platformę IBM i5, w celu wczytania danych do głównego zbioru bazodanowego Sposób importu danych z aplikacji witryny WWW do Repozytorium zostanie określony na etapie projektu technicznego.

13 2.5. Eksport danych bilingowych Zakłada się, że eksport danych bilingowych będzie wykonywany w ramach funkcjonalności raportujących, realizowanych w oparciu o dane zawarte w głównym zbiorze bazodanowym Przewiduje się ręczną obsługę procesu fakturowania w systemie fakturującym Do ustalenia: Jakie dane o transakcji będą niezbędne dla systemu fakturującego.

14 2.6. Raportowanie Raportowanie będzie realizowane na bazie informacji zawartych w głównym zbiorze bazodanowym, za pomoca narzędzi i metod developerskich Po okresie stabilizacji regulacji definiujących zasady funkcjonowania repozytoriów oraz wypracowaniu praktyk w relacjach nadzorca - KDPW w tym zakresie (II etap) zostaną podjęte działania w celu automatyzacji procesu raportowania.

15 2.7. Trade Repositories table of fields Table 1 -Counterparty Data Lp CONTENT [RTS] FORMAT [ITS] Dane w kdpw_stream Dane w Sentinel UWAGI Parties to the contract 1 ISO 8601 date format / UTC Reporting timestamp Date and time of reporting CONTENT [RTS] time formatformat [ITS] 2 The reporting counterparty shall be identified by Legal Entity Identifier (LEI), BIC ID of C/P an unique code or, in the case of individuals, by a or Client Code client code NKK (pyt. do KNF) 3 Unique identifier for the other counterparty of the Legal Entity Identifier (LEI), BIC ID of the other C/P transaction or Client Code j.w. 4 Free Text, 50 alphanumerical Corporate name of C/P i.e. name of financial C/P; Name of C/P digits. If in the LEI, no need for non-financial C/P; or individual. this field j.w. 5 Information on the registered office, consisting of Free Text, 500 alphanumerical Domicile of C/P street name, street number, postal code, city and country. digits. If in the LEI, no need for this field j.w. 6 Corporate sector of C/P Nature of the company activities / status (bank, insurance company, etc.) 7 Financial or Non- Indicate if the C/P a financial or non-financial Financial nature of counterparty in accordance with Article 2 (6) and C/P 2(7) of EMIR 8 In case C/P uses a broker to execute the ID of broker of C/P transaction, this broker shall be identified by an unique code 9 ID of the reporting entity ID of the reporting party or a third reporting party 10 ID of the clearing member e.g. in case of give-up 11 If the beneficiary of the contract is not a C/P to Beneficiary this contract it has to be identified by an unique code or, in case of individuals, by a a client code Taxonomy (B=Bank, I=Insurance company, etc.), if Katalog sektorów not in the LEI database F=Financial Counter-party / N = Non-Financial Counterparty Legal Entity Identifier (LEI) or BIC BIC Legal Entity Identifier (LEI) or KDPW, CCP lub wprowadzający via www BIC Legal Entity Identifier (LEI) or Uczestnik izby (clearing member BIC or LEI) BIC Legal Entity Identifier (LEI), BIC Pyt. Do KNF z prośbą o przykład or Client Code 12 Trading capacity Identifies whether the transaction was executed P=Principal A=Agent Brak informacji w stream ie

16 on own account (on own behalf or behalf of a client) or for the account of, and on behalf of, a client 13 C/P side Identifies whether the contract was a buy or a sell from the reporting C/P's perspective B=Buyer / S=Seller 14 Trade with non-eea Counterparty In case the C/P has entered into a trade with a non-eea C/P who is not subject to the reporting obligation Y=Yes / N=No 15 Directly linked to commercial activity or treasury financing For non-financial C/P; Information on whether the contract is objectively measurable as directly linked to the non-financial counterparty's commercial or treasury financing activity Y=Yes / N=No; changes over the lifetime of a contract need to be reported. In case the hedge is no longer justified, the report should be amended. Wie tylko strona transakcji 16 Clearing threshold Information whether the contract is above the clearing threshold Y=above / N=below Wymaga doprecyzowania, czy to są limity izby Strona 16 z 21

17 Table 2 -Common Data Both counterparties will need to report this data however where one counterparty reports on behalf of the other counterparty, the data only needs to be reported once. lp CONTENT [RTS] FORMAT [ITS] UWAGI Section 2a - Contract type 1 Taxonomy The used taxonomy for describing the Taxonomy, to be de-fined classification of the reported contract. either by the industry or ESMA 2 Product ID The contract shall be identified by using an unequivocally product identifier if available. UPI 3 Underlying The underlying shall be identified by using an unequivocally identifier for this underlying. In case ISO 6166 International Securities Identifying Number of baskets or indices an indication for this basket (ISIN) / Legal Entity Identifier or index shall be used in case an unequivocal (LEI) / B= Basket / I=Index. identifier for this product doesn't exist. Indication of the currency of the notional; 4 in FX derivatives the ISO 4217 Currency Code. ISO Currency Code cur-rency to be delivered. Section 2b - Details on the transaction 1 Trade ID Unique identifier for a trade as assigned by the two C/Ps or by the trading platform of execution. likely up to 20 numeri-cal digit. Numer instrukcji rozliczeniowej The venue of execution shall be identified by an 2 Venue of execution / unequivocal code for this venue. If the contract is ISO Market Identifier OTC executed outside an identified venue, it should Code (MIC) or XXXX (OTC). refer to as OTC RM=Regulated Mar-ket; MTF= Multilateral Trading Facility; 3 Type of venue of OTF=Organised Trad-ing To identify the type of venue execution Facility; SI=Systemic Internaliser XXXX=OTC Format (C=Cash, 4 Price / rate / spread The price per derivative excluding, where applicable, commission and accrued interest. amount P=Percentage, Spread=S) and (xxxx,yy). 5 Notional amount Face value of the transaction, i.e. value of the up to 10 numerical digits Strona 17 z 21

18 deliv-erables. (xxxx,yy). 6 Price multiplier The number of derivatives represented by one con-tract. up to 10 numerical digits. 7 Quantity Number of contracts included in the transaction. up to 10 numerical digits. 8 Up-front payment Amount of any up-front payment. numerical digits in the format xxxx,yy.? Do wyjaśnienia 9 Delivery type Identifies whether the contract is settled C=Cash / P=Physical / physically or in cash. O=Option Available to C/P. 10 Execution timestamp The time and date a contract was executed or ISO 8601 date format / UTC modi-fied, indicating timezone, expressed as time format. Coordinated Universal Time (UTC). 11 Effective date Date when obligations under the contract come into effect. ISO 8601 date format. 12 Maturity date Date when contract expires / exercise date. ISO 8601 date format. 13 Termination date TBD, if different from maturity ISO 8601 date format. 14 Settlement date Date of settlement of the underlying. ISO 8601 date format. In the interest of legal standardisation, reference Master Agreement 15 type Master Agreement 16 date 1 Confirmation Confirmation 2 timestamp 3 Collateralisation 1 Clearing obligation to any master agreement, if existent (e.g. ISDA Master Agreement; Master Power Purchase and Sale Agreement; International ForEx Master Agreement; European Master Agreement,...). Reference to the date of the master agreement ISO 8601 date format. ver-sion, if any (e.g. 1992, 2002,...). Section 2c - Risk mitigation / Reporting Indicates whether the transaction was electronically confirmed, non-electronically confirmed or remains unconfirmed. Date and time of the confirmation. Indicates whether exchange of collateral occurred to cover the transaction. Section 2d Clearing Indicates whether the reported contract is to be mandatorily cleared. Y=Non-electronically confirmed / N=Nonconfirmed / E=Electronically confirmed. ISO 8601 date format / UTC Data zawarcia transakcji time format. Zawsze Y, ze strony nie wiadomo co wpiszą Y=Yes / N=No. Y=Yes / N=No. Y, ze strony N 2 Cleared Indicates whether clearing took place. Y=Yes / N=No. j.w. 3 Clearing timestamp Time and date clearing took place. ISO 8601 date format / UTC Strona 18 z 21

19 4 CCP 5 Intragroup TBD time format. In case of a bilateral transaction that becomes novated after reporting the original transaction Legal Entity Identifier code (LEI) shall be kept and the indication whether it has or BIC of the CCP clearing the been cleared reported in this field by using an contract. unique code for the CCP that has cleared the contract. Indicates whether the contract was concluded as an intra-group transaction, defined in Art. 2a of Y=Yes / N=No. Regu Section 2e - Equity Derivatives b.d. Section 2f - Interest Rates If a UPI is reported and contains all the in-formation below, this is not required to be reported P=Payer of fixed rate, R=Receiver of fixed rate, U=Unspecified, For derivatives Indicates whether the reporting counterparty is in gen-eral-if the principal is 1 Direction receiving or paying the fixed rate. In case of floatto-float or fixed-to-fixed contracts this field has to rate. For float-to-float and paying or receiving the fixed B.d be filled as unspecified. fixed-to-fixed, it is unspecified. For non-swap or swap-tions, the instrument that was bought or sold. 2 Fixed rate Indicates the level of the fixed rate leg. numerical digits in the format xxxx,yy. b.d. 3 The actual number of days in the relevant Fixed Fixed rate day count numerical digits in the format Rate Payer Calculation Period in respect of which fraction xxx/360. pay-ment is being made divided by 360. b.d. 4 D=daily, W=weekly, Fixed leg payment Indicates the frequency of payments for the fixed M=monthly, Q=quarterly, fre-quency rate leg. S=semi-annually, A=annually. b.d. 5 D=daily, W=weekly, Floating rate Indicates the frequency of payments for the M=monthly, Q=quarterly, payment frequency floating rate leg. S=semi-annually, A=annually. b.d. 6 Floating rate reset Indicates the frequency of floating rate leg resets. D=daily, W=weekly, b.d. Strona 19 z 21

20 fre-quency M=monthly, Q=quarterly, S=semi-annually, A=annually. 7 Floating rate to floating rate Floating to floating rate. b.d. 8 Fixed rate to fixed rate Fixed to fixed rate. b.d. Section 2g - Currency / Forex If a UPI is reported and contains all the in-formation below, this is not required to be reported 1 Currency 2 The cross currency, as different from the currency of delivery. ISO 4217 Currency Code. b.d. 2 Exchange rate 1 At the moment of trade/agreement. b.d. 3 Exchange rate 2 At the moment of trade/agreement. b.d Section 2h - Com-modities Section 2i Credit 1 Option type Option style 2 (exercise) Strike price 3 (cap/floor rate) 1 Log Other Exposures Section 2j Options If a UPI is reported and contains all the in-formation below, this is not required to be reported Indicates whether the contract is a call or a put P=Put / C=Call. from the reporting counterparty's perspective. Indicates whether the option may be exercised only at a fixed date (European, Bermudan and A=American, B=Bermudan, Asian style) or at any time during the life of the E=European, S=Asian. contract (American style). numerical digits in the format The strike price of the option. xxxx,yy. Section 2k - Modifications to the con-tract Free Text, the RTS will need to specify that when any of the In order to build a trail of amendments and above information related to a entities reporting those, the date and the relevant single transaction changes, the informa-tion on the amendment, to allow the TR to counter-parties and the CCP register the amendment to a previously registered should make sure that those trade while keeping a log of changes per date. changes are re-ported and a log of the changes kept. Open field TBD b.d. Strona 20 z 21

21 Strona 21 z 21