Automatyczny rozrachunek zleceń w częściach

KDPW S.A.
Automatyczny rozrachunek zleceń
w częściach
Partial Settlement
2011-05-16
Rozrachunek zleceń w częściach
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 ........................... 10
1.
Zlecenie rozrachunku transakcji ................................................................. 10
2.
Status zlecenia rozrachunku ...................................................................... 10
3.
Potwierdzenie rozrachunku zlecenia........................................................... 11
4.
Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach .......... 11
V.
Zestawienie standardów komunikatów wykorzystywanych w procesie RwC ....... 12
VI.
Dostosowania komunikatów do wymagań informacyjnych RwC ....................... 13
1.
Zlecenie rozrachunku transakcji ................................................................. 13
1.1 ISO 20022................................................................................................. 13
1.2 ISO 15022................................................................................................. 13
1.3 Komunikaty własne kdpw_stream .............................................................. 13
2.
3.
4.
Status zlecenia rozrachunku ...................................................................... 14
2.1.
IS020022 ........................................................................................... 14
2.2.
ISO15022 ........................................................................................... 15
2.3.
Komunikat własny kdpw_stream .......................................................... 15
Potwierdzenie rozrachunku zlecenia........................................................... 17
3.1.
ISO 20022 .......................................................................................... 17
3.2.
ISO15022 ........................................................................................... 18
3.3.
Komunikaty własne systemu Kdpw_stream........................................... 19
Komunikat modyfikacji wartości wskaźnika rozrachunku w częściach; ......... 20
ISO 20022 ...................................................................................................... 20
ISO 15022 ...................................................................................................... 20
Komunikat kdpw_stream ................................................................................. 21
5.
Zestawienie Analizy ................................................................................... 22
str. 2
Rozrachunek zleceń w częściach
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
Rozrachunek zleceń w częściach
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
Rozrachunek zleceń w częściach
Rozrachunek w częściach
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Zlecenie rozrachunku, którego rozrachunek następuje w częściach nie podlega
anulowaniu (odrzuceniu) przez system rozrachunkowy.
System przechowuje referencje do oryginalnego zlecenia rozrachunku i przekazuje
je w komunikatach informujących o statusie i potwierdzeniu rozrachunku
poszczególnych części.1
System będzie przekazywał informację o statusie zlecenia oczekującego na
rozrachunek pozostałej części - status ‘rozrachowane częściowo” (“Partially
Settled”).
Rozrachunek częściowy będzie stosowany do transakcji typu DVP.
System rozrachunku będzie akceptował zlecenia rozrachunku zawierające wskaźnik
rozrachunku w częściach. Wskaźnik ten nie będzie stanowił kryterium zestawiania.
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.
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.
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.
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.
Wartość progowa dla rozrachunku w częściach (ang. thresholds) wyznacza wartość,
poniżej której transakcja nie podlega podziałowi.
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”.
ISO20022 instrukcja rozrachunkowa zawiera <TxId> tylko jednoznaczną identyfikację transakcji. W
systemie T2S instrukcja rozrachunkowa poza identyfikatorem transakcji <TxID> zawiera również
identyfikator dokumentu (komunikatu) <DocId>
1
str. 3
Rozrachunek zleceń w częściach
12.
13.
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.
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
Rozrachunek zleceń w częściach
Objaśnienie symboli
str. 5
Rozrachunek zleceń w częściach
Opis aktywności
W systemie uczestnika
W systemie kdpw_stream
Polecenie rozrachunku zlecenia - Typowy proces;
wg. standardowych działań z wyjątkiem opcji
wypełnienia wartości dla elementu ‘wskaźnik
RwC’.
Przyjęcie kontrola merytoryczna - Typowy
proces; wg. Standardowych działań z wyjątkiem
rozszerzenia schematu zlecenia o element
‘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.
standardowych działań
Zestawianie zleceń - Typowy proces; wg.
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
proces; wg. standardowych działań
Aktualizacja statusu zestawiania
proces; wg. Standardowych działań
- Typowy
- Typowy
Monitorowanie rozrachunku – W odniesieniu do
standardowego rozrachunku w przypadku RwC
wymagana będzie dodatkowa obsługa statusu
rozrachunku zlecenia „część transakcji oczekuje
na rozrachunek” oraz obsługa potwierdzenia
rozrachunku części zlecenia.
Rozrachunek transakcji - w wyniku zestawienia
instrukcji dostawy i instrukcji przyjęcia zostanie
wygenerowany
dokument
ewidencyjny
(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
informacji o zawieszeniu rozrachunku zlecenia
albo zlecenia rozrachowanego częściowo.
Aktualizacja
statusu
rozrachunku;
przygotowanie i przekazanie informacji o
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
Rozrachunek zleceń w częściach
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’.
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 częściowy zlecenia - zapis na
kontach , przekazanie informacji stronom
rozrachunku oraz przekazanie informacji do
procesu głównego Rozrachunek transakcji.
Rozrachunek zlecenia – zapis na koncie i zmiana
statusu zlecenia rozrachowane.
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
Rozrachunek zleceń w częściach
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
Rozrachunek zleceń w częściach
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
Rozrachunek zleceń w częściach
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.
1.2. 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.
2.1.
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
Rozrachunek zleceń w częściach
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 zlecenia2.
3.2.
wskazanie czy przekazywane potwierdzenie dotyczy zlecenia pozostającego w
rozrachunku (rozrachowanego w części), czy też rozrachunek zlecenia został
zakończony.
3.3.
potwierdzenie liczby papierów i wartości aktualnie zrealizowanego rozrachunku na
danej sesji rozrachunkowej.
3.4.
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 SMPG3 , będą
przekazywane przez T2S).
3.5.
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.
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
2
str. 11
Rozrachunek zleceń w częściach
V.
Zestawienie standardów
procesie RwC
komunikatów wykorzystywanych w
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 ISO20022. W
opracowaniu jest wariant standardów ISO 20022 dla systemu T2S z założenia w obszarze
Settlement and Reconcilation będą to identyczne komunikaty.
Funkcja
Kdpw_stream
ISO 15022
ISO20022
komunikatu
standard
Zlecenie
Sese.ins.001.01
MT 540-544 Settlement
Sese.023.002.02
rozrachunku
Instrukcja
Instructions (Free
SecuritiesSettlementTra
rozliczeniowa
/Receive Deliver
nsactionInstruction
/Against Payment)
Informacja o
Sese.sts.001.02 –
MT548 – Settlement
Sese.024.002.02 –
statusie
Status instrukcji
Status and Processing
SecuritiesSettlementTra
zlecenia i
rozliczeniowej
Advice,
nsactionStatusAdvice.4
Potwierdzenie
Sese.sts.001.02 –
MT544-547 –
Sese.025.002.02 –
rozrachunku
Status instrukcji
Confirmation (Free
SecuritiesSettlementTra
rozliczeniowej
/Receive Deliver
nsactionConfirmation5
rozrachunku
/Against Payment)
Modyfikacja
Sese.tech.001.01 –
MT530 Transaction
Sese.030.002.02
warunków
instrukcja techniczna
Processing Command
SecuritiesSettlementCon
rozrachunku
ditionsModificationRequ
est
4
5
(z wyłączeniem Securities Financing Transactions)
(z wyłączeniem Securities Financing Transactions)
str. 12
Rozrachunek zleceń w częściach
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 20022 SR6 2011, ISO 15022 SR 2010 oraz systemu
kdpw_stream.
1. Zlecenie rozrachunku transakcji
1.1 ISO 20022
Komunikat SecuritiesSettlementTransaction (sese.023.002.02) 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 15022
Securities settlement instructions MT540-544
W komunikatach rozrachunku transakcji MT540-544 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 MT540-544 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.001.01.xml
6
SR akronim odpowiadający “Standard Release”
str. 13
Rozrachunek zleceń w częściach
Brak
odpowiedniego
pola
w
schemacie
zlecenia
rozrachunku
kdpw_stream
sese.ins.001.01.xsd.
Dostosowanie schematu komunikatu sese.ins.001.01.xsd polegałoby na dodaniu w bloku
szczegółów rozliczenia <SttlmDtls> opcjonalnego elementu7 pozwalającego na stosowanie
wskaźnika RwC w postać analogicznej jak jest w komunikacie ISO 20022 sese.023.002.02.
2. Status zlecenia rozrachunku
2.1.
IS020022
Komunikaty
odpowiadające
schematowi
SecuritiesSettlementTransactionStatusAdvice
(sese.024.002.02.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
Rozrachunek zleceń w częściach
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.
2.2.
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.
2.3.
Komunikat własny kdpw_stream
W funkcji informacji o statusie
rozrachunku transakcji stosowany jest schemat Status
instrukcji rozliczeniowej sese.sts.001.02.xsd .
str. 15
Rozrachunek zleceń w częściach
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. 2.1
8
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 20022. 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
Rozrachunek zleceń w częściach
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.001.02.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 20022
SecuritiesSettlementTransactionConfirmation Sese.025.002.02.xsd
Wymagania
określone
w
pkt.
3
są
uwzględnione
w
strukturze
schematu
Sese.025.002.02.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 komunikatu9
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,
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).
9
str. 17
Rozrachunek zleceń w częściach
"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).
3.2.
ISO15022
W funkcji potwierdzenia rozrachunku transakcji stosowane są komunikaty MT544-547
Settlement Confirmation.
Ad 3.110 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:
10 10
Powołania dotyczą punktów omówionych w cz IV.
str. 18
Rozrachunek zleceń w częściach
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.
3.3.
Komunikaty własne systemu Kdpw_stream
W funkcji potwierdzenia rozrachunku transakcji stosowany jest komunikat odpowiadający
schematowi sese.sts.001.02.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.001.02.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 15022.
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
Rozrachunek zleceń w częściach
Ad 3.3, 3.4, 3.5
W komunikacie sese.sts.001.02.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.001.02.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 20022
W standardzie ISO 20022 jest to komunikat oparty na schemacie Sese.030.002.02.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 15022
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
Rozrachunek zleceń w częściach
Komunikat kdpw_stream
Komunikat generowany w oparciu o schemat sese.enr.001.01.xsd.
Brak wskaźnika RwC .
Wymagana zmiana schematu komunikatu. Wskaźnik powinien zostać dodany
w bloku
SttlmDtls.
str. 21
Rozrachunek zleceń w częściach
5. Zestawienie Analizy
Element informacji biznesowej
Kdpw_stream standard
ISO 15022
ISO20022
Zlecenie rozrachunku
Wskaźnik RwC;
PartialSettlementIndicator
Sese.ins.001.01
MT 540-544
X - brak
22F::STCO//
NPART)
Sese.023.002.02
(PART
albo <PrtlSttlmInd> jest typu
"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
Status rozrachunku
Sese.sts.001.02
MT548
Sese.024.002.02
W bloku Status
:25D::SETT//PENF
PendingStatus (<Pdg>),
<SttlmInstrSts> istnieje
„Instruction
pole Kod statusu <StsCd>.
is failing.
at
the
settlement
no
longer
Settlement
Brak kodu.
instructed
Kod PENF jest stosowany w date
is
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> :16R:REAS
istnieje
pole
Kod :24B::PENF//PART
przyczyny
<RsnTp>
,
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
Rozrachunek zleceń w częściach
(S001, IS01).
Dodatkowe
wyjaśnienie <RsnTxt>,
(opcjonalna informacja)
Liczba
wartościowych
:70D::REAS//
Tekst 6*35x
PendingReason <Rsn>
<AddtlRsnInf>
papierów Liczba
instrumentów :36B::SETT
finansowych
<ReqdSttlmQty>,
SettlementQuantity <SttlmQty>
Wartość
należności Wartość rozliczenia i kod :19A::SETT
zobowiązania pieniężnego
waluty <SttlmAmt>
SettlementAmount <SttlmAmt>
Potwierdzenie rozrachunku
Sese.sts.001.02
Referencje do
przekazanego
potwierdzenia
częściowego
MT544-547
Sese.025.002.02
poprzednio Brak
pola
o :20C::PREV// identyfikator PreviousPartialConfirmationIdentification
komunikatu funkcjonalności referencja poprzednio przekazanego <PrvsPrtlConfId> . (wymagane dostosowanie schema
rozrachunku do
poprzednio komunikatu potwierdzenia
komunikatu potwierdzania rozrachunku – obecnie
wystawionego komunikatu.
nie zawiera ona identyfikatora dokumentu )
Informacje
o
tym
czy Brak pola typu wskaźnik.
potwierdzenie dotyczy zlecenia
rozrachowanego w części albo
zlecenia, którego rachunek w
częściach został zakończony.
pole Indicator :22F:
:22F::PARS//PAIN
:22F::PARS//PARC
Liczba papierów
rozrachowanych i
potwierdzana tym
komunikatem,
pola Quantity of Financial SettledQuantity <SttldQty>
Instrument :36B:
:36B::ESTT
<ReqdSttlmQty>
Łączna
liczba
papierów Brak
rozrachowana i potwierdzona
poprzednio ( opcjonalnie wg
SMPG , wymagane w T2S)
:36B::PSTT
PartialSettlement <PrtlSttlm> dopuszczalne kody ISO:
PAIN, PARC
PreviouslySettledQuantity <PrevslySttldQty>
str. 23
Rozrachunek zleceń w częściach
Łączna wartość transakcji Brak.
rozrachowana i poprzednio
potwierdzona ( opcjonalnie wg
SMPG , wymagane w T2S)
Brak
Liczba papierów oczekująca na Brak
rozrachunek, ( opcjonalnie wg
SMPG , wymagane w T2S)
:36B::RSTT
PrevslySttledAmount <PrevslySttldAmt>
RemainingToBeSettledQuantity
<RmngToBeSttldQty>
Wartość transakcji
pozostająca do rozrachunku
( opcjonalnie wg SMPG ,
wymagane w T2S)
Brak
Brak odpowiedniego kodu RemainingToBeSettledAmount <RmngToBeSttldAmt>
kwalifikatora.
Wartość rozrachowana i
potwierdzona tym
komunikatem
<SttlmAmt Ccy="AAA">
:19A::ESTT
SettledAmount <SttldAmt>.
Modyfikacja warunków rozrachunku
Sese.enr.001.01
MT530
Transaction Sese.030.002.02
Processing Command
SecuritiesSettlementConditionsModificationRequest
Referencja do identyfikatora PrvsRef - Identyfikator :20C::PREV// modyfikowanego
zlecenia wzbogacanej
instrukcji
rozrachunku
rozliczeniowej
<AcctOwnrTxId>
Zmiana
RwC
Pole <PrtlSttlmInd> może przyjmować jedną z
wartości ISO :NPAR, PARC, PART, PARQ. Kody:
wartości
wskaźnika Brak wskaźnika RwC.
:22F::PRTL//PART,
:22F::PRTL//NPAR
PARC, PARQ nie będą obsługiwane w kdpw_stream.
str. 24