Zasady walidacji transakcji kierowanych do KDPW_CCP poprzez

Zasady walidacji transakcji
kierowanych do KDPW_CCP poprzez
SWIFT Accord
Tabela zmian
wersja
Zmiana
1.0
Dokument utworzony
1.1
Usunięte ostatnie zdanie z pkt 2.1, dodany punkt 3
1.2
Mapping of IDs
1. SWIFT + SWIFT Accord
W przypadku transakcji przekazywanych do KDPW_CCP ze SWIFT Accord obowiązują
następujące zasady:
1.1. Komunikacja z systemem kdpw_otc
Instytucja musi ustanowić SWIFT Accord na jednym ze swoich kodów BIC (może być to nowy
kod BIC lub obecnie używany). O tym fakcie informuje KDPW_CCP oraz nadaje uprawnienia dla
KDPW_CCP do przeglądania wszystkich transakcji na tym kodzie BIC oraz zmiany pola User
Status.
1.2. Transakcje widoczne z poziomu KDPW_CCP
Kdpw_otc wysyła zapytania wyłącznie o transakcje, które wskazują KDPW_CCP jako CCP
(obydwa pola 57A mają wpisane KCCPPLPW) oraz transakcja posiada status matched. Żadne
inne transakcje nie są widoczne z poziomu kdpw_otc I z tego powodu żadne inne transakcje nie
mogą zostać pobrane. W przypadku gdy bank posiada dedykowany kod BIC do transakcji
rozliczanych przez KDPW_CCP, kdpw_otc posiada dostęp tylko do tego kodu BIC. Przykład
oznaczenia transakcji przeznaczonej do rozliczeń w kdpw_otc:
:57A:KCCPPLPW
1.3. Transakcja jest przyjmowana jednokrotnie
Pierwsze zestawienie poprawnych instrukcji skutkuje ich przekazaniem do rozliczeń w
KDPW_CCP i zapisaniem identyfikatora nadanego przez SWIFT Accord w systemie kdpw_otc w
przypadku nowacji transakcji. Dla transakcji, która została wystawiona do SWIFT Accord i
otrzymała status “Accepted” niedozwolona jest operacja “unmatch”. Każda kolejna próba
dokonania unmatch oraz dokonania ponownego zestawienia nie ma żadnego wpływu na
transakcję już przekazaną do rozliczeń.
Wersja 1.2 z grudnia 2012
1.4. Ustalony niestandardowy kupon dla pierwszego okresu odsetkowego
W przypadku gdy istnieje pierwszy niestandardowy ustalony kupon dla pierwszego okresu
odsetkowego powinien on być wskazany w zestawionym potwierdzeniu transakcji. KDPW_CCP
ustanowiło standard, że informacja ta powinna być wskazana w polu 37N poprzedzona Tagiem
/INITREFIX/. Przykład użycia jest wskazany poniżej:
:37N:/INITREFIX/6,
1.5. Wskazywanie kont
Uczestnik rozliczający powinien wskazywać swoje konto w pierwszym dostępnym polu 72. Nie
powinien wskazywać konta swojego kontrpartnera. Wskazane konto jest następnie tłumaczone
na format:
PA-XXXX-1234567890
Gdzie XXXX jest kodem UR a 1234567890 jest przekazanym numerem konta. Przykład użycia:
:72:/ACCT/1234567890
1.6. MTOL
Niedozwolone jest stosowanie przez Uczestnika Rozliczającego jakiejkolwiek tolerancji na
wartość nominalną transakcji. W przypadku zastosowania tolerancji transakcja jest odrzucana.
1.7. MOBD
Niedozwolone jest stosowanie przez Uczestnika Rozliczającego jakiejkolwiek tolerancji na datę
zawarcia transakcji. W przypadku zastosowania tolerancji transakcja jest odrzucana.
1.8. CSU
Uczestnik rozliczający nie powinien stworzyć żadnej zasady CSU. W przypadku zastosowania
zasady CSU transakcja jest odrzucana.
1.9. Potwierdzenie transakcji w imieniu innego podmiotu
W przypadku gdy zachodzi potrzeba potwierdzenia transakcji w imieniu innego podmiotu
rzeczywiste pierwotne strony transakcji powinny być wskazane w polach 82A, 87A. Inne
zasady walidacji pozostają niezmienione. Należy zwrócić uwagę, że po nowacji powstaną
następujące stosunki prawne początkowej transakcji pomiędzy A i jego klientem C:
KDPW_CCP – A
KDPW_CCP – B (Uczestnik Rozliczający dla C)
B–C
1.10.
Rekomenduje się wypełnianie pól 82A oraz 87A za pomocą opcji A.
Rekomenduje się wypełnianie pól 82A oraz 87A za pomocą opcji A (pole podlega zestawianiu).
1.11.
Poprawność kont
KDPW_CCP sprawdza, czy konto wskazane w polu 72 jest poprawnym istniejącym kontem
wewnątrz struktury kont wysyłającego Uczestnika Rozliczającego.
1.12.
Dany typ instrumentu jest rozliczany przez KDPW_CCP
Do rozliczeń przyjmowane są wyłącznie instrumenty rozliczane przez KDPW_CCP. Szczegółowy
opis zasad walidacji poszczególnych instrumentów jest opisany w załączniku do
Szczegółowych Zasad Systemu Rozliczeń OTC.
1.13.
Umowa (pole 77H, oraz 77D dla IRS)
Pole to jest wyłącznie mapowane, nie jest walidowane.
Wersja 1.2 z grudnia 2012
1.14.
Regularność dat płatności dla transakcji IRS
Może istnieć wyłącznie jedna nieregularna płatność w kontrakcie IRS - pierwsza. Kolejne muszą
być regularne. Proszę zwrócić uwagę, że daty płatności muszą być nie skorygowane. Daty
płatności mogą być wyznaczone także na koniec określonych miesięcy.
1.15.
Daty płatności nie później niż data zakończenia kontraktu.
Żadna data płatności nie powinna być późniejsza niż data zakończenia kontraktu.
1.16.
Ponowne wysłanie transakcji
Istnieje możliwość ponownego wysłania transakcji do kdpw_otc. Operacja ta powinna być
wykonywana wyłącznie w przypadku, gdy transakcja początkowo otrzymała status Rejected
z powodu podania złego konta.
Transakcja jest wysyłana ponownie poprzez przesłanie komunikatu AMND (z poprawnymi
kontami) przez obydwie strony transakcji do zestawionej transakcji. Operacja ta zastępuje User
Status za pomocą pustego obiektu (“EMPTY”). Należy mieć na uwadze, że ponowne wysłanie
transakcji przyjętej transakcji spowoduje wygenerowanie komunikatu o odrzuceniu transakcji z
powodu zdublowanych numerów referencyjnych.
2. Zasady specyficzne dla kontraktów OIS w SWIFT
2.1. Daty płatności
Powinna być wyszczególniona wyłącznie jedna data płatności, równa dacie wyszczególnionej w
polu 30P – data końca kontraktu.
2.2. Szczegóły stopy procentowej (Pole 37N)
Dla transakcji OIS, pole to musi zawierać /OIS/ w pierwszej linijce.
2.3. Reset Date Specification (Pole 14J)
Dla transakcji OIS, pole to musi zawierać wartość OTHER.
2.4. Designated Maturity (Pole 38E)
Dla transakcji OIS, pole to musi być wypełnione zgodnie z konwencją 'other', co oznacza, że
liczba musi być ustawiona na 0 (zero) oraz okres musi być 'O'. Przykład użycia:
38E: 0O
3. Tabela mapowania nazw
SWIFT
Kdpw_otc
Trade date
tradeDate
Effective Date
effectiveDate
Termination Date
expiryDate
terminationDate
Sender's Reference
externalTradeIdentifier
Combined Spaghetti of both
participants ID given by SWIFT Accord
externalId
Wersja 1.2 z grudnia 2012