Automatyczny rozrachunek zleceń w częściach

Transkrypt

1 KDPW S.A. Automatyczny rozrachunek zleceń w częściach Partial Settlement

2 Spis treści Wstęp... 1 I. Wymagania funkcjonalne... 2 Proces optymalizacji... 2 Rozrachunek w częściach... 3 II. Opis procesu... 4 III. Wymiana komunikatów... 8 IV. Wymagane informacje specyficzne dla obsługi procesu RwC Zlecenie rozrachunku transakcji Status zlecenia rozrachunku Potwierdzenie rozrachunku zlecenia Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach V. Zestawienie standardów komunikatów wykorzystywanych w procesie RwC VI. Dostosowania komunikatów do wymagań informacyjnych RwC Zlecenie rozrachunku transakcji ISO ISO Komunikaty własne kdpw_stream Status zlecenia rozrachunku IS ISO Komunikat własny kdpw_stream Potwierdzenie rozrachunku zlecenia ISO ISO Komunikaty własne systemu Kdpw_stream Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach; ISO ISO Komunikat kdpw_stream Zestawienie Analizy str. 2

3 Wstęp Niniejszy dokument ma na celu przedstawienie modelu biznesowego automatycznego rozrachunku w częściach i ogólnych wymagań jego realizacji. Automatyczny rozrachunek w częściach transakcji jest to rozrachunek transakcji w części wyznaczonej wysokością dostępnego salda na koncie w systemie rozrachunkowym w danym dniu rozrachunku i rozrachunek pozostałej części w kolejnych dniach. str. 1

4 I. Wymagania funkcjonalne Funkcjonalność rozrachunku w częściach jest elementem procesu optymalizacji rozrachunku. Poniżej zostaną przedstawione założenia dotyczące realizacji procesu optymalizacji a następnie założenia mechanizmu rozrachunku w częściach. Proces optymalizacji 1. Rozrachunek w częściach (dalej RwC) będzie elementem procesu optymalizacji rozrachunku. Obecnie proces optymalizacji jest realizowany poprzez funkcje: nettingu technicznego oraz udzielanie automatycznych pożyczek papierów wartościowych. 2. Proces optymalizacji rozrachunku powinien zapewnić rozrachunek maksymalnej liczby transakcji i maksymalnej ich wartości. Wymagane jest zdefiniowanie w systemie optymalnej równowagi pomiędzy dążeniem do maksymalnej liczby rozrachowanych transakcji a maksymalną wartością rozrachowanych transakcji. 3. Funkcjonalność RwC może mieć zastosowanie do wszystkich zleceń rozrachunku, dla których strona rozrachunku nie zastrzegła w warunkach rozrachunku możliwości rozrachunku w częściach. (Takie rozwiązanie zostało przyjęte przez T2S). 4. Domyślnym systemem rozrachunku w kdpw_stream jest system sesyjny. Wszystkie zlecenia rozrachunku, o ile uczestnik nie wskazał inaczej w zleceniu rozrachunku kierowane są na sesje rozrachunkowe. 5. Proces optymalizacji z wykorzystaniem funkcji RwC będzie realizowany na ostatniej płatnej sesji rozrachunkowej. 6. System rozrachunkowy w procesie optymalizacji będzie stosował kombinację trzech funkcjonalności: netting techniczny, automatyczne pożyczki oraz rozrachunek w częściach. 7. Na danej sesji rozrachunkowej, jeśli zostanie stwierdzony brak pokrycia w papierach, w pierwszej kolejności nastąpi próba udzielenia pożyczki papierów wartościowych w ramach systemu pożyczek automatycznych. Pożyczka jest udzielana tylko w przypadku, gdy zapewni ona rozrachunek danej transakcji w całości, przy czym transakcja w tym przypadku to zarówno transakcja odpowiadająca całej wartość zlecenia jak i transakcja cząstkowa wygenerowana w systemie rozrachunku na skutek rozrachunku w częściach w dniu poprzednim. 8. W następnej kolejności, w odniesieniu do transakcji, dla których nie udzielono pożyczki papierów wartościowych i dozwolony jest rozrachunek w częściach, podejmowana jest próba rozrachunku w częściach. 9. Do transakcji złożonych, których podstawą są zlecenia rozrachunku zawierające wskaźniki dowolnego typu linków (np. With, After, Before), nie będzie stosowany rozrachunek w częściach. str. 2

5 Rozrachunek w częściach 1. Zlecenie rozrachunku, którego rozrachunek następuje w częściach nie podlega anulowaniu (odrzuceniu) przez system rozrachunkowy. 2. System przechowuje referencje do oryginalnego zlecenia rozrachunku i przekazuje je w komunikatach informujących o statusie i potwierdzeniu rozrachunku poszczególnych części System będzie przekazywał informację o statusie zlecenia oczekującego na rozrachunek pozostałej części - status rozrachowane częściowo ( Partially Settled ). 4. Rozrachunek częściowy będzie stosowany do transakcji typu DVP. 5. System rozrachunku będzie akceptował zlecenia rozrachunku zawierające wskaźnik rozrachunku w częściach. Wskaźnik ten nie będzie stanowił kryterium zestawiania. 6. System rozrachunku pozwala ustawić wartość domyślną wskaźnika rozrachunku w częściach. Np. system T2S domyślnie dopuszcza RwC, więc RwC może być realizowane, jeśli w zestawianych zleceniach rozrachunku wartość wskaźnika rozrachunku wskazuje na akceptację, albo wartość ta nie została podana. 7. Wartość wskaźnika rozrachunku w częściach może być modyfikowana przez przekazanie przez uczestnika instrukcji modyfikującej warunki rozrachunku do chwili rozrachunku zlecenia w części lub w całości. 8. Jeśli wartość wskaźnika rozrachunku dla danego zlecenia została wybrana przez CCP lub CSD wybór uczestnika będzie ignorowany przez system rozrachunkowy. 9. Transakcja może być skierowana do rozrachunku w częściach pod warunkiem: spełnienia kryterium wartości progowej dla rozrachunku w częściach (def. poniżej) oraz została podana odpowiednia wartość wskaźnika rozrachunku w częściach w zleceniu. Transakcja rozrachowana częściowo, może podlegać kolejnemu podziałowi na kolejnej sesji obsługującej proces RwC, jeśli spełnia opisany warunek. 10. Wartość progowa dla rozrachunku w częściach (ang. thresholds) wyznacza wartość, poniżej której transakcja nie podlega podziałowi. 11. Informacja dotycząca zgody na rozrachunek w częściach oraz typu preferowanej wartości progowej będzie przekazywana za pomocą wskaźnika rozrachunku w częściach. Wartości wskaźnika wg ISO 20022, które będą obsługiwane w systemie kdpw_stream to: PART dopuszczony RwC i typ wartości progowej nie określony, NPAR nie dopuszczony RwC. 1 ISO20022 instrukcja rozrachunkowa zawiera <TxId> tylko jednoznaczną identyfikację transakcji. W systemie T2S instrukcja rozrachunkowa poza identyfikator dokumentu (komunikatu) <DocId> identyfikatorem transakcji <TxID> zawiera również str. 3

6 12. Anulowanie zlecenia; uczestnik może anulować rozrachunek zlecenia, w części nierozrachowanej, którego status jest Partially Settled w przypadku zawieszenia jego rozrachunku na ogólnych zasadach stosowanych do anulowania zleceń zestawionych. 13. Mechanizm Hold/Release będzie stosowany do zlecenia rozrachunku, którego status jest Partially Settled na ogólnych zasadach przyjętych w systemie rozrachunku. II. Opis procesu Diagram procesu RwC Poniższy diagram jest koncepcyjnym modelem procesu, a nie propozycją rozwiązania systemu informatycznego. Na diagramie został przedstawiony przebieg rozrachunku zleceń z zastosowaniem funkcjonalności RwC. Głównym celem diagramu jest wskazanie sekwencji procesów wspomagających rozrachunek oraz opis potwierdzania rozrachunku w przypadku zastosowania RwC do transakcji. str. 4

7 Objaśnienie symboli str. 5

8 Opis aktywności W systemie uczestnika W systemie kdpw_stream Polecenie rozrachunku zlecenia - Typowy proces; Przyjęcie kontrola merytoryczna - Typowy wg. standardowych działań z wyjątkiem opcji proces; wg. Standardowych działań z wyjątkiem wypełnienia wartości dla elementu wskaźnik rozszerzenia schematu zlecenia o element RwC. wskaźnik RwC. Przyjęte TAK/NIE-Jeśli TAK to zlecenie gotowe do dalszego przetwarzania tj. zestawiania (jeśli jest wymóg zestawiania) Aktualizacja statusu przyjęcia - Typowy proces; wg. Standardowych działań, Monitorowanie zestawiania - Typowy proces; wg. Zestawianie zleceń - Typowy proces; wg. standardowych działań Standardowych działań Zestawione TAK/NIE Jeśli TAK to przejście do monitorowania rozrachunku, NIE aktualizacja statusu zestawiania. Zestawione TAK/NIE Jeśli TAK to zlecenie gotowe do rozrachunku i aktualizacja statusu zestawiania, jeśli nie to aktualizacja statusu. Aktualizacja statusu zestawiania - Typowy Aktualizacja statusu zestawiania - Typowy proces; wg. standardowych działań proces; wg. Standardowych działań Monitorowanie rozrachunku W odniesieniu do standardowego rozrachunku w przypadku RwC Rozrachunek transakcji - w wyniku zestawienia instrukcji dostawy i instrukcji przyjęcia zostanie wymagana będzie dodatkowa obsługa statusu wygenerowany dokument ewidencyjny rozrachunku zlecenia część transakcji oczekuje na rozrachunek oraz obsługa potwierdzenia rozrachunku części zlecenia. (transakcja) z referencjami do zestawionych zleceń. Proces ten obejmuje ponad to: neting techniczny i kontrolę dostępnych środków na kontach. Rozrachowane TAK/NIE Jeśli TAK to przejście do analizy Rozrachowane w części TAK/NIE. Rozrachowana TAK/NIE - Jeśli NIE, następnym krokiem jest podjęcie próby udzielenia pożyczki oraz aktualizacja statusu rozrachunku. Aktualizacja statusu rozrachunku; obsługa Aktualizacja statusu rozrachunku; informacji o zawieszeniu rozrachunku zlecenia przygotowanie i przekazanie informacji o albo zlecenia rozrachowanego częściowo. zawieszeniu rozrachunku zlecenia albo zlecenia rozrachowanego częściowo. Pożyczki automatyczne - podjęcie próby udzielenia pożyczki z zachowaniem warunków udzielania pożyczek zgodnie z przyjętymi zasadami w KDPW. Pożyczka udzielona TAK/NIE - Jeśli TAK transakcja kierowana jest do głównego procesu Rozrachunku transakcji. Jeśli NIE to do procesu Przygotowanie do RwC jeśli jest on aktywny. Aktywacja RwC TAK/NIE Jeśli TAK to przejście do procesu Przygotowanie do RwC Przygotowanie do RwC wygenerowanie dwóch transakcji z referencjami do zleceń uczestników; jedna transakcja z uwzględnieniem liczby papierów i wartości transakcji możliwej do str. 6

9 Rozrachowane w części TAK/NIE- Jeśli NIE to do procesu Rozrachunek zlecenia jeśli TAK to do procesu Rozrachunek częściowy zlecenia. Rozrachunek częściowy zlecenia - zapis na koncie (status zlecenia rozrachunek otwarty) Rozrachunek zlecenia zapis na koncie i zmiana statusu zlecenia rozrachowane. rozrachunku na bieżącej sesji rozrachunkowej druga transakcja jest generowana na pozostałą liczbę i kwotę pozostająca do rozrachunku. Rozrachowane w części TAK/NIE- Jeśli NIE to do procesu Rozrachunek zlecenia jeśli TAK to do procesu Rozrachunek częściowy zlecenia. Rozrachunek częściowy zlecenia - zapis na kontach, przekazanie informacji stronom rozrachunku oraz przekazanie informacji do procesu głównego Rozrachunek transakcji. Rozrachunek zlecenia zapis na kontach i przekazanie informacji stronom rozrachunku. Potwierdzenie Rozrachunku - wygenerowanie potwierdzenie rozrachunku. Potwierdzenie rozrachowania zlecenia zawiera kod PARC gdy zakończono rozrachunek z zastosowaniem mechanizmu RwC, albo kod nie jest wypełniany gdy rozrachunek nastąpił bez stosowania RwC. Potwierdzenie rozrachunku częściowego zlecenia; zawiera kod PAIN. str. 7

10 III. Wymiana komunikatów Model przepływu komunikatów przyjęty w ISO2022 jest z założenia niezależny od standardu komunikatów, dlatego w opisie zastosowano nazwy funkcjonalne komunikatów. Poniższy diagram prezentuje wymianę komunikatów pomiędzy systemem uczestnika zlecającego rozrachunek a systemem realizującym rozrachunek zleceń (np. kdpw_stream). Rozrachunek w częściach polega na rozrachunku pojedynczego zlecenia w kilku częściach (co najmniej dwóch) aż zlecenie zostanie w pełni zrealizowane/rozrachowane. Prezentowany jest wariant podstawowy - uczestnik nie korzysta w nim z opcji zmiany wartości wskaźnika rozrachunku w częściach, oraz opcji anulowania nierozrachowanej części zlecenia. W tym przypadku Uczestnik zlecający przekazuje do systemu rozrachunkowego tylko dokument zlecenia rozrachunku transakcji. Diagram Wymiany komunikatów str. 8

11 Opis wymiany komunikatów 1. Uczestnik przekazuje do systemu rozrachunku kdpw_stream Zlecenie rozrachunku 2. System kdpw_stream przekazuje opcjonalnie standardowe informacje o statusie przetwarzania zlecenia, 3. System kdpw_stream przekazuje opcjonalnie standardowe informacje o statusie rozrachunku zestawionych zleceń, 4. System kdpw_stream przekazuje Potwierdzenie rozrachunku częściowego zlecenia 5. System kdpw_stream przekazuje Informację o statusie rozrachunku pozostałej części zlecenia 6. System kdpw_stream przekazuje Potwierdzenie rozrachunku pozostałej części zlecenia. str. 9

12 IV. Wymagane informacje specyficzne dla obsługi procesu RwC Poniżej zostaną przedstawione wymagane informacje specyficzne dla obsługi procesu RwC niezależnie od standardu komunikatów. 1. Zlecenie rozrachunku transakcji 1.1. Zlecenie rozrachunku zawiera standardowe dane wymagane do rozrachunku transakcji. Schemat zlecenia rozrachunku powinien umożliwiać opcjonalnie przekazanie informacji dotyczącej zezwolenia/zakazu na rozrachunek w częściach oraz typu preferowanej wartości progowej zgodnie z przyjętym określeniem - wskaźnik rozrachunku w częściach Zlecenie rozrachunku zawiera jednoznaczną identyfikację transakcji, której dotyczy zlecenie, przyjętą przez wystawcę zlecenia oraz identyfikator dokumentu (komunikatu) zawierającego zlecenie. 2. Status zlecenia rozrachunku W czasie trwania procesu RwC w komunikatach Status zlecenia rozrachunku (status advice message) przekazywana jest informacja o statusie pozostałej części transakcji do rozrachunku. Szczegóły zawarte w części dotyczącej transakcji odzwierciedlają aktualny rzeczywisty stan transakcji oczekującej na rozrachunek nie zaś oryginalną liczbę instrumentów i ich wartość rozrachunkową przekazaną w zleceniu rozrachunku. Komunikat ten informuje o statusie zawieszania rozrachunku pozostałej części zlecenia. Specyficzne wymagania dotyczące zawartości komunikatu. Aby przekazać informacje o nierozliczonej części częściowo zrealizowanego zlecenia komunikat w funkcji Status zlecenia rozrachunku powinien umożliwiać przekazywanie następujących szczególnych informacji poza standardową, o której mowa w pkt. 2.0: 2.0. Referencje do identyfikacji (oryginalnego zlecenia rozrachunku) transakcji nadanej przez wystawcę zlecenia rozrachunku oraz identyfikację transakcji nadaną przez operatora konta, którego dotyczy zlecenie Status rozrachunku Zawieszony, 2.2. Specjalny kod opisujący powód, 2.3. Dodatkowe wyjaśnienia tekst, opcjonalnie 2.4. Nierozrachowana liczba papierów wartościowych 2.5. Nierozrachowana część płatności należności/zobowiązania str. 10

13 3. Potwierdzenie rozrachunku zlecenia Poza standardowymi informacjami wymaganymi do potwierdzenia rozrachunku (identyfikator transakcji/dokumentu nadany przez wystawiającego zlecenie oraz przez operatora konta, którego dotyczy zlecenie) wymagane są następujące dodatkowe informacje w związku z rozrachunkiem RwC: 3.1. referencje do poprzednio przekazanego dokumentu potwierdzenia rozrachunku częściowego danego zlecenia wskazanie czy przekazywane potwierdzenie dotyczy zlecenia pozostającego w rozrachunku (rozrachowanego w części), czy też rozrachunek zlecenia został zakończony potwierdzenie liczby papierów i wartości aktualnie zrealizowanego rozrachunku na danej sesji rozrachunkowej o liczbie rozrachowanych papierów i odpowiadającej wartości rozrachunku, potwierdzonych w komunikacie poprzednio przekazanym wraz ze wskazaniem referencji do tego komunikatu (informacje te są opcjonalne wg SMPG 3, będą przekazywane przez T2S) o liczbie papierów i wartości oczekujących na rozrachunek (informacje te są opcjonalne wg SMPG, będą przekazywane przez T2S). 4. Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach pozwala na modyfikację wartości wskaźnika w przekazanym do systemu zleceniu rozrachunku transakcji. 2 Ponieważ w ISO20022 nie zawiera identyfikacji dokumentu (komunikatu) co jest niezgodne z ISO15022 należy zdecydować, skąd ta informacja miałaby ewentualnie pochodzić. Na obecnym etapie projektu przyjmiemy, iż komunikaty ISO20022 zostaną dostosowane, ponieważ Informacja ta jest zawarta w standardach T2S. 3 SMPG Securities Market Practice Group str. 11

14 V. Zestawienie standardów komunikatów wykorzystywanych w procesie RwC Aktualnie w procesie rozrachunku transakcji w systemach rozrachunkowych stosowane są komunikaty własne (w przypadku rynku polskiego komunikaty systemowe kdpw_stream), komunikaty MT w standardzie ISO15022, komunikaty MX w standardzie ISO W opracowaniu jest wariant standardów ISO dla systemu T2S z założenia w obszarze Settlement and Reconcilation będą to identyczne komunikaty. Funkcja Kdpw_stream ISO ISO20022 komunikatu standard Zlecenie Sese.ins MT Settlement Sese rozrachunku Instrukcja Instructions (Free SecuritiesSettlementTra rozliczeniowa /Receive Deliver nsactioninstruction /Against Payment) Informacja o Sese.sts MT548 Settlement Sese statusie Status instrukcji Status and Processing SecuritiesSettlementTra zlecenia i rozliczeniowej Advice, nsactionstatusadvice. 4 rozrachunku Potwierdzenie Sese.sts MT Sese rozrachunku Status instrukcji Confirmation (Free SecuritiesSettlementTra rozliczeniowej /Receive Deliver nsactionconfirmation 5 /Against Payment) Modyfikacja Sese.tech MT530 Transaction Sese warunków instrukcja techniczna Processing Command SecuritiesSettlementCon rozrachunku ditionsmodificationrequ est 4 (z wyłączeniem Securities Financing Transactions) 5 (z wyłączeniem Securities Financing Transactions) str. 12

15 VI. Dostosowania komunikatów do wymagań informacyjnych RwC Poniżej została przedstawiona analiza dostosowania i sposobu realizacji specyficznych wymagań związanych z procesem RwC (opisanych w części IV) w następujących standardach komunikatów: ISO SR , ISO SR 2010 oraz systemu kdpw_stream. 1. Zlecenie rozrachunku transakcji 1.1 ISO Komunikat SecuritiesSettlementTransaction (sese ) pełni funkcję zlecenia rozrachunku transakcji. Wskaźnik RwC; PartialSettlementIndicator (tag < PrtlSttlmInd >) jest zamieszczony w bloku SettlementParameters (tag <SttlmParams >), który zawiera szczegóły rozrachunku transakcji. Pole to ma charakter opcjonalny. Pole "PrtlSttlmInd" jest typu "SettlementTransactionCondition5Code" i może przyjmować jedną z wartości : PART, NPAR, PARC, PARQ. Kody : PARC, PARQ nie będą obsługiwane w kdpw_stream, ponieważ nie jest planowane stosowanie mechanizmu RwC dla transakcji typu FoP (free of payment). 1.2 ISO Securities settlement instructions MT W komunikatach rozrachunku transakcji MT znajduje się pole Settlement Transaction Condition Indicator :22F::STCO//, w którym kod może przyjmować jedną z dwóch wartości: NPAR (no partial settlement allowed) albo PART (partial settlement allowed). W komunikatach ISO15022 MT w wersji SR 2011 brak kodów odpowiadających przyjętej propozycji T2S o połączeniu informacji o preferowanym typie wartości progowej i akceptacji rozrachunku RwC w jednym polu. 1.3 Komunikaty własne kdpw_stream Instrukcja zlecenia rozrachunku sese.ins xml 6 SR akronim odpowiadający Standard Release str. 13

16 Brak odpowiedniego pola w schemacie zlecenia rozrachunku kdpw_stream sese.ins xsd. Dostosowanie schematu komunikatu sese.ins xsd polegałoby na dodaniu w bloku szczegółów rozliczenia <SttlmDtls> opcjonalnego elementu 7 pozwalającego na stosowanie wskaźnika RwC w postać analogicznej jak jest w komunikacie ISO sese Status zlecenia rozrachunku 2.1. IS Komunikaty odpowiadające schematowi SecuritiesSettlementTransactionStatusAdvice (sese xsd,) są stosowane do informowania o statusie zlecenia i statusie rozrachunku. Ad. 2.0 (Opisane w cz. IV) Schemat komunikatu w bloku TransactionIdentifications13 zawiera między innymi elementy: AccountOwnerTransactionIdentification <AcctOwnrTxId> identyfikator transakcji nadany przez wystawiającego zlecenie rozrachunku oraz AccountServicerTransactionIdentification <ACCTSvcrTxId> - identyfikator transakcji nadany przez operatora konta, którego zlecenie dotyczy. Są to informacje standardowo przekazywane w każdym komunikacie. ad 2.1, ad 2.2 ad 2.3(Opisane w cz IV) Schemat komunikatu w bloku SettlementStatus4Choice zawiera element złożony "Pdg" typu PendingStatus8Choice. Element "Pdg" jest przeznaczony do przekazywania informacji o zawieszonym rozrachunku transakcji. Element złożony "Pdg" zwiera elementy: "NoSpcfdRsn oraz "Rsn" ostatni typu PendingReason4. Element złożony "Rsn" zawierający dwa elementy: "Cd" element typu PendingReason10Choice oraz element "AddtlRsnInf"(AdditionalReasonInformation) typu pole tekstowe przeznaczone do opisu powodu nadania danego statusu. Element złożony "Cd" zawiera między innymi element "Cd" typu "PendingReason1Code" przeznaczony do specyfikacji kodu powodu zawieszenia (w przypadku opisywanego procesu jest to kod ISO PART - zawieszenie rozrachunku części transakcji w związku z RwC. ad 2.4 (w cz IV) schemat ten w bloku "TxDtls" typu TransactionDetails23 zawiera element złożony "SttlmQty"(SettlementQuantity) dedykowany do przekazywania informacji o liczbie papierów wartościowych oczekującej na rozrachunek części transakcji. 7 Typu PartialSettlementChoice str. 14

17 ad 2.5 schemat ten w bloku "TxDtls" typu TransactionDetails23 zawiera element złożony "SttlmAmt" (SettlementAmount ) pole do przekazywania płatności należności/zobowiązania oczekującej na rozrachunek części transakcji. Schemat komunikatu jest w pełni dostosowany do realizacji wymagań związanych z procesem RwC ISO15022 Ad. 2.0 W ISO15022 nie ma rozróżnienia pomiędzy identyfikacją dokumentu a identyfikacją transakcji. W przypadku zlecenia rozrachunku identyfikator zlecenia może pełnić jednocześnie funkcję identyfikatora transakcji. Identyfikator zlecenia jest przekazywany w polu :20C::SEME//. W komunikacie informującym o statusie pozostającej do rozrachunku części transakcji powołanie na identyfikator zlecenia (transakcji) jest przekazywany w polu :20C::RELA//. Ad 2.1(w cz IV) Informacja o statusie rozrachunku przekazywana jest w polu :25D::SETT// kod statusu PENF (Instruction is failing. Settlement at the instructed settlement date is no longer possible.) ad 2.2 Informacja wyjaśniająca powód w polu :24B::PENF// kod PART (Trade will settle in partials.) ad 2.3 Dodatkowe wyjaśnienia mogą być przekazywane w polu :70D::REAS// dopuszcza tekst o długości sześciu linijek po 35 znaki. ad 2.4 Informacja o liczbie instrumentów finansowych pozostająca do rozrachunku przekazywana jest w polu :36B::SETT ad 2.5 Informacja o pozostałej do rozrachunku wartości należności zobowiązania pieniężnego w polu :19A::SETT Komunikat własny kdpw_stream W funkcji informacji o statusie rozrachunku transakcji stosowany jest schemat Status instrukcji rozliczeniowej sese.sts xsd. str. 15

18 Ad. 2.0 W systemie kdpw_stream nie jest stosowane rozróżnienie pomiędzy identyfikacją dokumentu a identyfikacją transakcji. Identyfikator zlecenia jest przekazywany w polu <RltdRef>. W komunikacie informującym o statusie pozostającej do rozrachunku części transakcji powołanie na identyfikator zlecenia (transakcji) jest przekazywane w bloku <LNK> w polu <RltdRef>, w bloku tym przekazywany jest również identyfikator przyjętego zlecenia (transakcji) nadany przez kdpw_stream; <AcctSvcrRef>. Ad Schemat komunikatu posiada odpowiednie pole do przekazywania tego typu informacji o statusie rozrachunku instrukcji, jednak wymagane jest dostosowanie kodów. Kod statusu - Status <StsCd>: PENF jest wykorzystywany w systemie kdpw_stream, ale w znaczeniu innym niż w ISO W kdpw_stream Kod PENF oznacza Instrukcja przeterminowana lub odrzucona, zaś zgodnie z ISO kod PENF odpowiada Instruction is failing. Settlement at the instructed settlement date is no longer possible, a więc instrukcja nie jest odrzucona automatycznie przez system - rozrachunek jest możliwy, ale w terminie późniejszym niż wskazana data rozrachunku. W przypadku zawieszenia rozrachunku z powodu braku pokrycia w papierach albo gotówce generowany jest kod SUSP- Instrukcja zawieszona. W systemie kdpw_stream istnieje kod PART - Instrukcja przeznaczona do częściowej realizacji, ale w standardzie ISO jest to kod przyczyny a nie kod statusu rozrachunku a ponadto takie sformułowanie jest bardziej właściwe w odniesieniu do oryginalnego zlecenia rozrachunku niż do części pozostałej do rozrachunku. Ad 2.2 Schemat komunikatu posiada odpowiednie pole do przekazywania tego typu informacji, jednak wymagane jest dostosowanie kodów. Kod przyczyny "RsnTp"; ma wartość IS01 z przetwarzania w systemie MB albo kod S001 z systemu RTGS- odpowiada on informacji Brak papierów na koncie debetowanego. Ad 2.3 Schemat komunikatu posiada odpowiednie pole "RsnTxt", do przekazywania informacji typu opis przyczyny. Ad. 2.4 Schemat komunikatu posiada odpowiednie pole do przekazywania informacji o liczbie instrumentów finansowych "ReqdSttlmQty", w tym przypadku powinna to być liczba instrumentów pozostająca do rozrachunku. 8 Powołania dotyczą punktów omówionych w cz IV. str. 16

19 Ad. 2.5 Schemat komunikatu posiada odpowiednie pole do przekazywania informacji o wartości rozliczenia i kodzie waluty "SttlmAmt", w tym przypadku powinna to być wartość pozostająca do rozrachunku. Wniosek Schemat komunikatu sese.sts xsd nie wymaga zmian w związku z funkcją raportowania statusu nie rozrachowanej części zlecenia, ponieważ kody nie są zawarte w definicji schematu komunikatów kdpw_stream, w przeciwieństwie do definicji schematów ISO 20022, które zawierają również wartości kodów dozwolone w komunikatach. Nowe kody wymagają oprogramowania ich obsługi w systemie. 3. Potwierdzenie rozrachunku zlecenia 3.1. ISO SecuritiesSettlementTransactionConfirmation Sese xsd Wymagania określone w pkt. 3 są uwzględnione w strukturze schematu Sese xsd. Informacje określone w pkt. 3.1, 3.2 w części IV są przekazywane w bloku "AddtlParams" parametrów dodatkowych (AdditionalParameters) zawierającym elementy: "PrvsPrtlConfId" (PreviousPartialConfirmationIdentification) przeznaczony do zamieszczania referencje do poprzednio przekazanej identyfikacji komunikatu 9 potwierdzenia rozrachunku częściowego oraz, "PrtlSttlm " (PartialSettlement) - przeznaczone do zamieszczania informacje o tym czy potwierdzenie dotyczy zlecenia rozrachowanego w części (kod PAIN) albo zlecenia, którego rachunek został zakończony (kod PARC). Informacje określone w pkt. 3.3, 3.4, 3.5 w części IV są przekazywane w bloku informacji "QtyAndAcctDtls" (QuantityAndAccountDetails) zawierającym następujące elementy: "SttldQty" (SettledQuantity) liczba papierów rozrachowanych i potwierdzana tym komunikatem, 9 Patrz problem zasygnalizowany w odnośniku 2. Na obecnym etapie projektu przyjmiemy, iż schematy komunikatów ISO20022 zostaną dostosowane, więc powinien to być identyfikator dokumentu (komunikatu potwierdzenia). str. 17

20 "PrevslySttldQty" (PreviouslySettledQuantity) - łączna liczba papierów rozrachowana i potwierdzona poprzednio, "PrevslySttldAmt" (PrevslySttledAmount) łączna wartość transakcji rozrachowana i poprzednio potwierdzona, "RmngToBeSttldQty" (RemainingToBeSettledQuantity) - liczba papierów oczekująca na rozrachunek, "RmngToBeSttldAmt" (RemainingToBeSettledAmount) - wartość transakcji pozostająca do rozrachunku. Informacja o wartość transakcji rozrachowanej i potwierdzanej tym komunikatem jest przekazywana w bloku "SttldAmt" (SettledAmount) ISO15022 W funkcji potwierdzenia rozrachunku transakcji stosowane są komunikaty MT Settlement Confirmation. Ad W bloku Linkages ( blok ten może wystąpić wielokrotnie w jednym komunikacie) w polu Reference :20C: z kwalifikatorem PREV przekazywany jest identyfikator komunikatu potwierdzenia częściowego rozrachunku zlecenia zrealizowanego poprzednio (np. :20C::PREV//confirmation1). Poza tym standardowo przekazywane są referencja do identyfikatora zlecenia nadanego przez uczestnika w (:20C::RELA//zlecenie01). Ad 3.2 W bloku General Information dla pola Indicator :22F:, z kwalifikatorem PARS (Partial Settlement Indicator), dopuszczalne są kody PARS oraz PAIN. Kody te mają identyczne znaczenie jak w ISO. Kod PAIN jest stosowany w przypadku potwierdzania dla poszczególnych części rozrachunku (np. :22F::PARS//PAIN) z wyłączeniem ostatniej części dla której wpisywana jest wartość kodu PARC (:22F::PARS//PARC). Ad 3.3, 3.4, 3.5 W bloku Financial Instrument/Account dla pola Quantity of Financial Instrument :36B: dopuszczalne są następujące kwalifikatory: ESTT - liczba papierów rozrachowanych ; potwierdzana w tym komunikacie, PSTT łączna liczba papierów rozrachowana i potwierdzona poprzednio, RSTT - liczba papierów oczekująca na rozrachunek. Informacji o wartość transakcji rozrachowanej i potwierdzanej tym komunikatem jest przekazywana w bloku Amount (blok może być użyty wielokrotnie) w polu Amount :19A: Powołania dotyczą punktów omówionych w cz IV. str. 18

21 kwalifikator ESTT jest obowiązkowy (np. :19A::ESTT//PLN100,). W komunikatach MT nie ma dedykowanego pola do przekazywania informacji o rozrachowanej i potwierdzonej wartości transakcji wcześniejszym komunikatem oraz o wartości transakcji oczekującej na rozrachunek ewentualnie mogłoby być wykorzystane pole OTHR jednak taka decyzja wymagałaby pogłębionej analizy Komunikaty własne systemu Kdpw_stream W funkcji potwierdzenia rozrachunku transakcji stosowany jest komunikat odpowiadający schematowi sese.sts xsd Status instrukcji rozliczeniowej. Status instrukcji rozliczeniowej pełni dwie funkcje, a mianowicie informuje o statusie zlecenia rozrachunku oraz funkcję potwierdzenia rozrachunku transakcji. Rozróżnienie tych funkcji następuje na podstawie kodu statusu. Funkcję potwierdzenia rozrachunku transakcji pełni komunikat sese.sts xml, w którym wartość kodu w polu "StsCd" jest STLD. Aby określić funkcję komunikatu wymagana jest analiza zawartości komunikatu w przeciwieństwie do rozwiązań ISO, gdzie funkcja komunikatu jest określana na podstawie typu komunikatu. Ad. 3.1 Blok Lnk nie zawiera linku typu PREV to jest pola przeznaczonego na przekazywanie referencji do poprzednio przekazanego komunikatu w funkcji potwierdzenia rozrachunku zlecenia rozrachowanego w częściach (identyfikacja w ramach tego samego typu i funkcji ). Wymagane dołączenie elementu PREV w bloku Lnk. Ad 3.2 Brak pola typu wskaźnik. Ewentualnie przekazywanie informacji o tym czy potwierdzenie dotyczy zlecenia pozostającego w rozrachunku (rozrachowanego w części), czy też rozrachunek zlecenia został zakończony mogłoby być realizowane z wykorzystaniem nowych kodów w polu kod statusu "StsCd" w bloku status "SttlmInstrSts", a mianowicie : PAIN, PARC. Znaczenie tych kodów odpowiadałoby znaczeniu tych kodów opisanemu powyżej w przypadku komunikatów ISO Rozwiązanie takie funkcjonowałoby, w przypadku wyboru wariantu dostosowania komunikatów kdpw_stream do bezwzględnie wymaganych zmian. Bezpośrednią konsekwencją wprowadzenia kodów: PAIN, PARC w polu status instrukcji jest fakt, że komunikat sese.sts. w funkcji potwierdzenie rozrachunku będzie miał jeden z trzech statusów: STLD, PAIN, PARC. str. 19

22 Ad 3.3, 3.4, 3.5 W komunikacie sese.sts xml możliwe jest przekazanie informacji o aktualnie rozrachowanej liczbie papierów wartościowych w bloku "ReqdSttlmQty" (co odpowiada w ISO20022 "SttldQty") oraz aktualnie rozrachowanej wartości transakcji w bloku "SttlmAmt Ccy="AAA"" (co odpowiada w ISO20022 "SttldAmt") Wymagane by było uzupełnienie schematu sese.sts xsd o następujące elementy: "PrevslySttldQty" - łączna liczba papierów rozrachowana i potwierdzona poprzednio, "PrevslySttldAmt" łączna wartość transakcji rozrachowana i poprzednio potwierdzona, "RmngToBeSttldQty" - liczba papierów oczekująca na rozrachunek, "RmngToBeSttldAmt" - wartość transakcji pozostająca do rozrachunku. 4. Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach; Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach pozwala na modyfikację wartości wskaźnika w przekazanym do systemu zleceniu rozrachunku transakcji. ISO W standardzie ISO jest to komunikat oparty na schemacie Sese xsd SecuritiesSettlementConditionsModificationRequest. Pole PrtlSttlmInd może przyjmować jedną z czterech wartości ISO :NPAR, PARC, PARQ, PART. Kody :PARC, PARQ nie będą obsługiwane w kdpw_stream. ISO Komunikat MT530 posiada pole typu wskaźnik :22F::PRTL// w SR 2011 zarejestrowane są tylko dwa kody wartości: PART, NPART. Nie jest więc w pełni dostosowany do wymagań T2S. str. 20

23 Komunikat kdpw_stream Komunikat generowany w oparciu o schemat sese.enr xsd. Brak wskaźnika RwC. Wymagana zmiana schematu komunikatu. Wskaźnik powinien zostać dodany SttlmDtls. w bloku str. 21

24 Wstępne założenia dotyczące rozrachunku w częściach przekazane uczestnikom do konsultacji w maju 2011 r. (załącznik do pisma DO/ZW/1219/2011) 5. Zestawienie Analizy Element informacji biznesowej Kdpw_stream standard ISO ISO20022 Zlecenie rozrachunku Sese.ins MT Sese Wskaźnik RwC; X - brak 22F::STCO// (PART albo <PrtlSttlmInd> jest typu PartialSettlementIndicator NPART) "SettlementTransactionCondition5Code" i może przyjmować wartości : PART, NPAR, PARC, PARQ. Kody :PARC, PARQ nie będą obsługiwane w kdpw_stream. Informacja o statusie zlecenia i rozrachunku Sese.sts MT548 Sese Status rozrachunku W bloku Status :25D::SETT//PENF PendingStatus (<Pdg>), <SttlmInstrSts> istnieje Instruction is failing. pole Kod statusu <StsCd>. Settlement at the Brak kodu. instructed settlement Kod PENF jest stosowany w date is no longer sposób nie adekwatny do possible. potrzeby raportowania w Rozrachunek możliwy ale związku z RwC. nie we wskazanej dacie! Powód rozrachunku zawieszenia W bloku Przyczyna <Rsn> istnieje pole Kod przyczyny <RsnTp>, :16R:REAS :24B::PENF//PART W bloku PendingReason <Rsn> istnieje pole Kod <Cd>. wartość kodu w tym przypadku powinna być PART dostępne kody informują generalnie o braku papierów na rozrachunek str. 22

25 Wstępne założenia dotyczące rozrachunku w częściach przekazane uczestnikom do konsultacji w maju 2011 r. (załącznik do pisma DO/ZW/1219/2011) Dodatkowe wyjaśnienie (opcjonalna informacja) Liczba papierów wartościowych Wartość należności zobowiązania pieniężnego Referencje do poprzednio przekazanego komunikatu potwierdzenia rozrachunku częściowego Informacje o tym czy potwierdzenie dotyczy zlecenia rozrachowanego w części albo zlecenia, którego rachunek w częściach został zakończony. Liczba papierów rozrachowanych i potwierdzana tym komunikatem, (S001, IS01). <RsnTxt>, Liczba finansowych instrumentów :70D::REAS// Tekst 6*35x :36B::SETT PendingReason <Rsn> <AddtlRsnInf> SettlementQuantity <SttlmQty> <ReqdSttlmQty>, Wartość rozliczenia i kod :19A::SETT SettlementAmount <SttlmAmt> waluty <SttlmAmt> Potwierdzenie rozrachunku Sese.sts MT Sese Brak pola o :20C::PREV// identyfikator PreviousPartialConfirmationIdentification funkcjonalności referencja poprzednio przekazanego <PrvsPrtlConfId>. (wymagane dostosowanie schema do poprzednio komunikatu potwierdzenia komunikatu potwierdzania rozrachunku obecnie wystawionego komunikatu. nie zawiera ona identyfikatora dokumentu ) Brak pola typu wskaźnik. pole Indicator :22F: PartialSettlement <PrtlSttlm> dopuszczalne kody ISO: :22F::PARS//PAIN PAIN, PARC :22F::PARS//PARC <ReqdSttlmQty> pola Quantity of Financial SettledQuantity <SttldQty> Instrument :36B: :36B::ESTT Łączna liczba papierów rozrachowana i potwierdzona poprzednio ( opcjonalnie wg SMPG, wymagane w T2S) Brak :36B::PSTT PreviouslySettledQuantity <PrevslySttldQty> str. 23

26 Wstępne założenia dotyczące rozrachunku w częściach przekazane uczestnikom do konsultacji w maju 2011 r. (załącznik do pisma DO/ZW/1219/2011) Łączna wartość transakcji rozrachowana i poprzednio potwierdzona ( opcjonalnie wg SMPG, wymagane w T2S) Liczba papierów oczekująca na rozrachunek, ( opcjonalnie wg SMPG, wymagane w T2S) Wartość transakcji pozostająca do rozrachunku ( opcjonalnie wg SMPG, wymagane w T2S) Wartość rozrachowana i potwierdzona tym komunikatem Referencja do identyfikatora modyfikowanego zlecenia rozrachunku Zmiana wartości wskaźnika RwC Brak. Brak PrevslySttledAmount <PrevslySttldAmt> Brak :36B::RSTT RemainingToBeSettledQuantity <RmngToBeSttldQty> Brak Brak odpowiedniego kodu kwalifikatora. RemainingToBeSettledAmount <RmngToBeSttldAmt> <SttlmAmt Ccy="AAA"> :19A::ESTT SettledAmount <SttldAmt>. Modyfikacja warunków rozrachunku Sese.enr MT530 Transaction Processing Command PrvsRef - Identyfikator :20C::PREV// - wzbogacanej instrukcji rozliczeniowej Brak wskaźnika RwC. :22F::PRTL//PART, :22F::PRTL//NPAR Sese SecuritiesSettlementConditionsModificationRequest <AcctOwnrTxId> Pole <PrtlSttlmInd> może przyjmować jedną z wartości ISO :NPAR, PARC, PART, PARQ. Kody: PARC, PARQ nie będą obsługiwane w kdpw_stream. str. 24