Centralne rozliczenia transakcji OTC - prezentacja 2

Centralne rozliczenia transakcji OTC
w usłudze KDPW_CCP
WARSZTATY
19 luty 2015 r.
Agenda
•
•
•
•
Monitoring ryzyka
• Limity
• Transakcja hipotetyczna
Aukcja - obsługa niewypłacalności UR
• Etapy aukcji
• Przepływ komunikatów
Usługi dodatkowe
• Umarzanie przeciwstawnych pozycji
• Obsługa terminacji na żądanie
Komunikaty EOD
• Standardowe komunikaty systemu kdpw_otc (w tym dotyczące raportowania)
• Komunikaty dedykowane (konfigurowane na żądanie UR)
2
Monitoring ryzyka
3
Limit zabezpieczeń
•
-
Limit zabezpieczeń (CL)
wartość zabezpieczeń wniesionych przez uczestnika na konta zabezpieczeń klientów i konto
własne,
zabezpieczenia z kont klientów uznawane do wysokości do wartości naliczonych zobowiązań,
zabezpieczenia wniesione na konto własne uczestnika rozliczającego uznawane w całości.
𝐶𝐿 =
𝑚𝑖𝑛(𝐼𝑀𝑅𝑃𝐵 , 𝐶𝑜𝑙𝑙𝑃𝐵 ) + 𝐶𝑜𝑙𝑙𝐻𝑜𝑢𝑠𝑒
𝑃𝐵 𝐶𝑙𝑖𝑒𝑛𝑡
•
Wymaganie depozytowe na konto
𝐼𝑀𝑅𝑃𝐵 = 𝑚𝑎𝑥 𝐼𝑀𝑃𝐵 + 𝑂𝑢𝑡𝑀𝑡𝑀𝑃𝐵 + 𝑆𝐴𝑑𝑗𝑃𝐵 ,0

𝐼𝑀𝑃𝐵
- właściwy depozyt zabezpieczający obliczony na konto zabezpieczeń PB

𝑆𝐴𝑑𝑗𝑃𝐵
- kwota korygująca wynikająca z zaakceptowanych ofert uczestnika biorącego udział
w operacji automatycznego zamykania pozycji lub zamykania pozycji na żądanie

𝑂𝑢𝑡𝑀𝑡𝑀𝑃𝐵
- wartość przyjętych do rozliczeń w dniu bieżącym transakcji, zawartych przed dniem (R)
ustalenia tej wartości
4
Przekroczenie limitu zabezpieczeń
•
Dostępny limit zabezpieczeń dla uczestnika
- różnica pomiędzy limitem zabezpieczeń a sumą zobowiązań wynikających z wymagań depozytowych.
𝐴𝐿 = 𝐶𝐿 −
𝐼𝑀𝑅𝑃𝐵
𝑃𝐵
•
W przypadku przekroczenia limitu zabezpieczeń, gdy limit zabezpieczeń jest niższy od limitu kredytowego
przekroczenie
skutkuje
przekazaniem
uczestnikowi
komunikatu
participantNotification
z informacją o poziomie przekroczenia limitu zabezpieczeń wzywając uczestnika do zlikwidowania przekroczenia
w ciągu 30 minut.
•
Transakcja powodująca przekroczenie limitu zabezpieczającego, a nie powodująca przekroczenia limitu
kredytowego zostanie przyjęta do KDPW_CCP do rozliczeń.
•
Niedoprowadzenie w wymaganym czasie do stanu zgodności z limitem jest przypadkiem naruszenia i może
skutkować uznaniem uczestnika rozliczającego za niewypłacalnego.
•
W sytuacji przekroczenia limitu uczestnik może:

przekazać do systemu rozliczeń OTC transakcje redukującą
na danym koncie w celu obniżenia poziomu wymagań depozytowych

przekazać do systemu rozliczeń OTC komunikat colr.ins.001.01 w celu uzupełnienia środków na koncie
zabezpieczeń
całkowitą
wartość
zobowiązań
5
Limit kredytowy
•
•
Uczestnikowi może być przyznany dodatkowy limit - limit kredytowy.
Limit kredytowy – suma wartości limitu zabezpieczeń uczestnika oraz wartości wynikającej z
oceny wiarygodności kredytowej uczestnika dokonanej przez KDPW_CCP.
 limit kredytowy stanowi całkowity poziom limitu do wykorzystania przez uczestnika w
momencie przekazania transakcji do rozliczeń
 limit kredytowy jest zawsze większy bądź równy limitowi zabezpieczeń
Aktualnie KDPW_CCP przewiduje, stosować podejście, w którym limit kredytowy ustalony
zostanie na poziomie limitu zabezpieczeń.
6
Przekroczenie limitu kredytowego
•
W przypadku, gdy limit zabezpieczeń jest równy limitowi kredytowemu wówczas przekroczenie
limitu zabezpieczeń traktowane jest jak przekroczenie limitu kredytowego.
•
Przekroczenie limitu kredytowego następuje w momencie
przekazania do rozliczeń
do systemu OTC transakcji, powodującej że zobowiązania z tytułu depozytów
zabezpieczających obliczone w stosunku do wszystkich transakcji przekazanych do rozliczeń do
KDPW_CCP przez uczestnika przekroczą wartość limitu kredytowego.
•
Przekazanie przez uczestnika rozliczającego do systemu rozliczeń OTC transakcji powodującej
przekroczenie limitu kredytowego skutkuje przekazaniem uczestnikowi komunikatu
participantNotification (N.1) z informacją o przekroczeniu tego limitu wraz
z poziomem wymaganego zabezpieczenia i informacją o nieprzyjęciu transakcji
do rozliczeń.
•
W sytuacji przekroczenia limitu uczestnik może:

przekazać do systemu rozliczeń OTC transakcje redukującą całkowitą wartość zobowiązań na
danym koncie w celu obniżenia poziomu wymagań depozytowych

przekazać do systemu rozliczeń OTC komunikat colr.ins.001.01 w celu uzupełnienia środków
na koncie zabezpieczeń
7
Monitoring ryzyka – hipotetyczna transakcja
•
KDPW_CCP umożliwia uczestnikom przekazanie do systemu rozliczeń transakcji
lub portfela transakcji w ramach „hipotetycznej transakcji”, w celu oceny wpływu, jaki zawarcie
tych transakcji będzie miało na poziom wymaganych zabezpieczeń uczestnika i stopień
wykorzystania limitów.
•
Hipotetyczna transakcja umożliwia :
 wyznaczenie
wymaganego
poziomu
właściwego
depozytu
zabezpieczającego
z tytułu transakcji, które uczestnik zamierza przekazać do rozliczeń do systemu OTC
 bieżące monitorowanie ryzyka, jakie powstaje w wyniku zawierania przez uczestnika
transakcji
 optymalne zarządzanie poziomem utrzymywanych zabezpieczeń z tytułu zawartych
transakcji, gdzie uczestnik może wycofać zabezpieczenia wciągu dnia, jeśli uzna, iż w wyniku
zawartych transakcji poziom wymagań depozytowych obniżył się w stosunku do poziomu
limitu zabezpieczeń.
•
Opłata za sprawdzenie wpływu hipotetycznej transakcji na stopień wykorzystania limitu
zabezpieczeń – 5 zł (bez względu na wartość transakcji i liczbę transakcji
w portfelu transakcji)
8
Obsługa hipotetycznej transakcji
•
Zapytanie o poziom wymaganych depozytów dla hipotetycznej transakcji -przesłanie przez
Uczestnika Rozliczającego do KDPW_OTC do systemu OTC komunikatu W.1
hypotheticalPortfolioRequest (otcd.rqi.001.01)
•
Odpowiedź na zapytanie: komunikat N.1 participantNotification (otcd.rsi.001.01), z
następująco polami:
– Reason == Hypothetical Trade
– Source == WHAT IF
•
Komunikat potwierdzający zawiera: informacje o hipotetycznie zawartej transakcji,
w tym aktualny wymóg depozytowy lub ostrzeżenie o przekroczeniu limitu zabezpieczeń lub
limitu kredytowego uczestnika rozliczającego, status transakcji, informacje o ewentualnym
odrzuceniu lub zawieszeniu transakcji
9
Obsługa transakcji po zamknięciu
•
•
Kolejkowanie transakcji przesłanych po 17:00 a przed 9:00
Przetworzenie transakcji na otwarciu systemu (o 9:00)
– Wysyłany jest jeden komunikat otcd.ntf.001.01 participantNotification
– Badany jest łączny wpływ wszystkich transakcji na poziom zabezpieczeń
10
Aukcja - obsługa niewypłacalności UR
11
Aukcja - charakterystyka
•
•
•
•
•
Godzina otwarcia, zamknięcia i prezentacji wyników
Styl aukcji
Kwotowanie zawsze w dwie strony
W przypadku niewypłacalności:
• podział nominału transakcji na wiele jednostek
• obowiązek kwotowania minimalnej liczby jednostek dla UR
• wiele segmentów
Typowe problemy po stronie UR:
• Brak możliwości kwotowania kilku segmentów po kilku cenach na raz (problem techniczny)
• Wczytywanie przesłanych segmentów do systemu banku i ich wycena zwłaszcza w
przypadków swapów (interpretacja strony BUY/SELL)
• Rozliczenia i rozrachunek
• Cena powinna uwzględnić wszystkie koszty (także przyjęcia transakcji do CCP)
12
Rozpoczęcie aukcji
Niewypłacalność
Terminacja
Wszyscy UR otrzymują:
•
otcd.ntf.001.01 auctionNotification
– Przybliżone godziny aukcji
– Zakres produktów
•
otcd.ntf.001.01 auctionDetail
– W jednym komunikacie zawsze
jedna aukcja
– Podział na wiele segmentów w
jednej aukcji (brak maksimum)
– Szczegóły transakcji z wyceną
UR żądający terminacji:
•
otcd.ntf.001.01 onDemandTerminationResult
Wszyscy pozostali UR:
•
otcd.ntf.001.01 auctionDetail
– Podział na 2 segmenty
– Szczegóły transakcji z wyceną
13
Składanie ofert
UR wysyła:
•
otcd.rqi.001.01 auctionQuoteRequest
– Kwotowanie jest w walucie segmentu
– „-1000” oznacza, że UR oczekuje 1000 PLN za dany segment
– Sugeruje się wysłanie wcześniej hypotheticalPortfolioRequest.
UR otrzymuje:
•
otcd.rsi.001.01 auctionError (odrzucone) lub otcd.rsi.001.01 (przyjęte)
– INVALID_AUCTION
– INVALID_TIME
– INVALID_SEGMENT
– INSUFFICIENT_UNITS (niewypłacalność)
– INVALID_UNITS
– INVALID_ACCOUNT
– * FAILED_ELIGIBILITY_CHECK (terminacja)
– * INVALID_PARTICIPANT_STATE (terminacja)
14
Zakończenie aukcji
Tylko przy niewypłacalności:
•
otcd.ntf.001.01 auctionTimeout
Tylko przy terminacji:
•
otcd.ntf.001.01 onDemandTerminationResult
•
otcd.rqi.001.01 onDemandTerminationAcceptance
•
otcd.rsi.001.01
•
•
otcd.ntf.001.01 auctionResult
– Jest wysyłany do UR wygrywających transakcje (nie jest wysyłany do UR zamykającego
pozycję)
otcd.ntf.001.01 participantNotification
15
Rozliczenie aukcji
•
A.2: UR otrzymuje 4 segmenty
•
podzielone każdy na 100 jednostek.
Minimum do zakwotowania to 3j. Wycena
transakcji w segmentach wg CCP:
–
–
–
–
•
tys.*
tys.
tys.
tys.
1:
6,5
2: -6,5
3: 78,8
4: -78,8
tys.
tys.
tys.
tys.
–
–
–
–
@ -8,5 tys.
@
4,5 tys.
@ -82,8 tys.
@ 76,8 tys.
&
&
&
&
10j
10j
10j
10j
@ -10,0 tys.
@
3,0 tys.
@ -84,8 tys.
@ 74,8 tys.
•
Przy aukcji standardowej UR rozliczy się kwotą:
–
1&2: 5j @ -2 tys.; 10j @ -3,5 tys.
3:
5j @ -4 tys.; 10j @ -6 tys.
•
4:
5j @ -2 tys.; 10j @ -4 tys.
* wszystkie wyceny są podane ze strony CCP
5j
5j
5j
5j
Prawdziwe były segmenty 1 & 4. CCP
zdecydowało się na przyjęcie 7j z segmentu 1 i 8j z
segmentu 2 od danego UR.
Marża UR
–
–
–
1:
2:
3:
4:
•
UR wycenia segmenty:
–
–
–
–
•
1: +4
2: -4
3: 79
4: -79
Kwotowanie:
5*(-8,5)+2*(-10)+5*76,8+3*74,8=545,9 tys (UR
zapłaci 545,9 tys. PLN)
W przypadku aukcji drugiej ceny:
–
7*(-10)+8*74,8=528,4 tys. PLN
aa
aa
16
Rozliczenie aukcji cd.
•
Przy aukcji standardowej rozliczenie
kwotowania wyniesie +545,9 tys PLN
•
Przy następujących wycenach EOD
portfela:
– 1: 6 tys PLN
– 4: -79 tys PLN
•
UR otrzyma wyrównanie w wysokości:
– 7*6+8*(-79)=-590 tys
•
Łączne rozliczenie aukcji wyniesie:
– 545,9 tys – 590 tys = -44,1 tys
•
•
Komunikaty z rozliczeniem aukcji UR otrzyma
od razu po aukcji (A.6)
•
Komunikaty z rozliczeniem wyrównania do
rynku transakcji (VM) i rozliczenie aukcji UR
otrzyma wieczorem tego samego dnia podczas
EOD (E.1 & E.2)
•
Rozrachunek odbędzie się następnego dnia
rano poprzez automatyczne uznanie konta UR
do godziny 9.
Wynik UR na aukcji to 44,1 tys PLN
17
Usługi dodatkowe
18
Terminacja pozycji na żądanie
• Narzędzie umożliwiające uczestnikowi rozliczającemu zamknięcie pozycji (własnej, klienta, UNR)
poprzez mechanizm aukcji.
• Alternatywa do zawierania transakcji przeciwstawnej na rynku międzybankowym i przekazywania jej
do rozliczenia w KDPW_CCP.
• Opłata w wysokości 500 zł pobierana miesięcznie za każde zainicjowanie procesu zamykania pozycji
na żądanie.
Proces obsługi zamykania pozycji na żądanie
• Zmiana przez UR ustawień odpowiedniego konta PA, zezwalających na rozpoczęcie procesu, poprzez
wysłanie do KDPW_CCP komunikatu U.1.accountMaintenaceRequest
(<enableAutomaticTermination>true</enableAutomaticTermination>).
• Zainicjowanie aukcji przez UR za pomocą komunikatu T.1 onDemandTerminationRequest
(otcd.rqi.001.01), na który KDPW_CCP odpowiada:
- komunikatem T.2 onDemandTerminationResponse (otcd.rsi.001.01), informującym o odmowie
rozpoczęcia aukcji lub
- pustym komunikatem bez określonego typu, a następnie komunikatem T.2.
onDemandTerminationResponse (otcd.ntf.001.01), w którym przekazywana jest informacja
o rozpoczęciu terminacji na żądanie.
19
Terminacja pozycji na żądanie
• Wymiana komunikatów A.2-A.4 między KDPW_CCP a wszystkimi UR, analogicznie jak w przypadku
automatycznego zamykania pozycji.
• Po ustaleniu wyniku aukcji wysłanie przez KDPW_CCP uczestnikowi zlecającemu przeprowadzenie
terminacji na żądanie komunikatu T.3. onDemandTerminationResult (otcd.ntf.001.01).
• Zaakceptowanie lub odrzucenie przez UR wyniku aukcji za pomocą komunikatu T.4
onDemandTerminationAcceptance (otcd.rqi.001.01).
• Powiadomienie UR, który wygrał aukcję o wynikach za pomocą komunikatu A.6 auctionResult
(otcd.ntf.001.01) oraz wysłanie N.1 participantNotification (otcd.ntf.001.01), potwierdzającym zawarcie
przez UR nowych transakcji.
20
Umorzenie przeciwstawnych pozycji
•
Umożliwia redukcję liczby transakcji.
•
Umarzane są pozycje jednakowe co do typu instrumentu i parametrów rozliczeniowych
z wyłączeniem nominału oraz strony transakcji.
•
Transakcje mogą podlegać umorzeniu w całości lub w części.
•
Wykonywane jest każdego dnia roboczego w czasie sesji kompensacyjnej na dedykowanych
kontach uczestników.
•
Uczestnik Rozliczający przekazuje do KDPW_CCP komunikat accountMaintenanceRequest (U.1),
w którym wskazuje konto oraz właściwy atrybut zezwalający na uczestnictwo w
procesie: <enableAutomaticTermination>true</enableAutomaticTermination>.
•
Do uczestników, których pozycje zostały umorzone na koniec dnia wysyłany jest komunikat
automaticTerminationSummary (E.3) informujący o zmianach.
•
Jeżeli więcej niż jedna z pozycji przeciwstawnych zarejestrowanych na wskazanym przez uczestnika
koncie spełnia kryteria umorzenia, w pierwszej kolejności umarzane będą pozycje, dla których
rejestracja na koncie rozliczeniowym nastąpiła wcześniej.
•
Usługa jest bezpłatna.
•
Planowane jest udostępnienie usługi kompresji portfela – TriOptima.
21
Komunikaty EOD
22
Komunikaty EOD
•
Komunikat otcd.ntf.001.01 (E.1) positionBalanceSettlements
• wysyłany po zarejestrowaniu pierwszych transakcji na koncie
• kolejne konta powodują dodanie kolejnego elementu (zawsze jeden komunikat)
• kolejne waluty powodują dodanie kolejnego elementu (zawsze jeden komunikat)
•
Komunikat colr.mrg.003.01 (E.2)
• planowane zmiany w związku z uwzględnieniem rozliczeń w EUR
23
Sposoby raportowania
•
Cechy raportów:
•
„CSV” opakowane w XML
•
Duża elastyczność
•
Rodzaje raportów:
•
Standardowe reporty generowane EOD
•
Indywidualne raporty generowane EOD
•
Raporty na żądanie
24
Standardowe raporty
•
Raporty generowane każdego dnia podczas procesu EOD:
• CM Trade Variation Margin
• CM Settled trades
• CM Coupons (payment)
• CM Coupons (fixing)
• CM New trade
•
Na żądanie UR KDPW_CCP może wyłączyć generowanie części raportów.
http://www.kdpwccp.pl/pl/kdpw_ccp/rozwoj/otc_clearing/Documents/Raporty%20w%20systemie%20
kdpw%20otc%201%200.pdf
25
Raporty na żądanie
•
•
•
•
otcd.rqi.001.01 executeReportRequest
otcd.rsi.001.01 externalReport
Tylko raporty indywidualne mogą być wywoływane na życzenie
Wymagają wcześniejszej konfiguracji w systemie KDPW_CCP
Raporty tworzone są na indywidualną prośbę UR wysłaną na [email protected]
Raporty zostaną utworzone o ile:
•
Zostanie przedstawiony uzasadniony wniosek
•
Nie ma raportów o zbliżonej zawartości
•
Wykonanie raportu będzie możliwe od strony technicznej
26
Dziękujemy za uwagę
Zapraszamy do dyskusji
[email protected]