Rekomendacja National Market Practice Group PL w zakresie stosowania identyfikatora klienta w procesie zestawiania instrukcji rozliczeniowych (wersja 1.0 obowiązuje od 2.07.2012 r.) W celu zapewnienia lepszej efektywności procesu zestawiania, w tym unikania niewłaściwego zestawiania instrukcji (cross-matching), wprowadza się obowiązek zamieszczenia w instrukcjach rozliczeniowych identyfikatorów klientów. Zestawianie pola klient odbywa się według następujących zasad: 1. Zalecanym formatem identyfikacji klienta jest kod BIC11. Dopuszczalnym formatem jest również kod BIC8, jednakże podczas zestawiania nie będą przeprowadzane konwersje różnych wariantów kodów BIC (np. dodawanie lub usuwanie znaków XXX na końcu kodu). Kody BIC muszą zostać podane przez obie strony transakcji w dokładnie taki sam sposób. 2. Do identyfikacji domu maklerskiego, będącego stroną transakcji dla klienta ma zastosowanie wyłącznie kod BIC. 3. W przypadku, gdy identyfikator instytucji w postaci kodu BIC (pole 95P w komunikacie MT lub jego odpowiednik w komunikacie xml systemu kdpw_stream) nie stanowi jednoznacznej identyfikacji klienta, w instrukcji powinien być dodatkowo podany identyfikator rachunku klienta (pole 97A w komunikacie MT lub jego odpowiednik w komunikacie xml systemu kdpw_stream). W przypadku gdyby zostały podane w instrukcji obydwie wartości prawidłowo, wówczas zestawienie w systemie kdpw_stream będzie się odbywać na podstawie danych we wszystkich polach. 4. Jeżeli klient nie posiada kodu BIC do identyfikacji klienta należy wykorzystać identyfikator rachunku klienta. Rachunek klienta powinien być przekazywany bez pomijania zer wiodących lub kończących. 5. Podanie różnych wartości lub formatów identyfikatorów klienta przez obie strony transakcji powoduje zablokowanie możliwości zestawiania. Uczestnicy KDPW będą dążyć do formatowania instrukcji rozliczeniowych zgodnie z niniejszą rekomendacją Przyjmuje się, iż procesowanie bez zachowania zasada wspomnianych w rekomendacji może zostać zakwalifikowane jako nonstp. 6. Obie strony transakcji powinny podawać identyfikatory klientów zarówno po stronie sprzedającej, jak i kupującej. 7. Identyfikator klienta podany w postaci nazwy (pole 95Q w komunikacie MT lub jego odpowiednik w komunikacie xml systemu kdpw_stream) nie jest przedmiotem zestawiania. W przypadku zastosowania formatu 95Q konieczne jest również wypełnienie identyfikatora rachunku klienta. 1
8. W przypadku stosowania komunikatów xml systemu kdpw_stream identyfikator klienta podawany jest w polach: (a) Klient posiada kod BIC dla strony dostarczającej: o DlvrgSdDtls/SellrDtls/BIC (kod BIC) o DlvrgSdDtls/SellrDtls/SafAcct (identyfikator rachunku jeżeli kod BIC nie stanowi jednoznacznego identyfikatora klienta) o RcvgSdDtls/BuyrDtls/BIC (kod BIC) o RcvgSdDtls/BuyrDtls/SafAcct (identyfikator rachunku jeżeli kod BIC nie stanowi jednoznacznego identyfikatora klienta) (b) Klient nie posiada kodu BIC dla strony dostarczającej: o DlvrgSdDtls/BuyrDtls/PrtryId (nazwa podawana opcjonalnie - nie podlega zestawianiu) o DlvrgSdDtls/SellrDtls/SafAcct (identyfikator rachunku obowiązkowo) o RcvgSdDtls/BuyrDtls/PrtryId (nazwa podawana opcjonalnie - nie podlega zestawianiu) o RcvgSdDtls/BuyrDtls/SafAcct (identyfikator rachunku obowiązkowo) 9. W przypadku stosowania komunikatów ISO15022 identyfikator klienta podawany jest w polach: (a) Klient posiada kod BIC dla strony dostarczającej: o 95P::SELL// (kod BIC) o 97A::SAFE// (identyfikator rachunku jeżeli kod BIC nie stanowi jednoznacznego identyfikatora klienta) o 95P::BUYR// (kod BIC) o 97A::SAFE// (identyfikator rachunku jeżeli kod BIC nie stanowi jednoznacznego identyfikatora klienta) (b) Klient nie posiada kodu BIC dla strony dostarczającej: o 95Q::SELL// (nazwa nie podlega zestawianiu) o 97A::SAFE// (identyfikator rachunku obowiązkowo) o 95Q::BUYR// (nazwa nie podlega zestawianiu) o 97A::SAFE// (identyfikator rachunku obowiązkowo) 2
Przykład Instytucja oznaczona kodem BIC AAAAPLPWXXX sprzedaje papiery PL123456789 instytucji CUSTOMER1. AAAAPLPWXX dokonuje rozrachunku za pośrednictwem uczestnika CSD oznaczonego lokalnym kodem AAAA i posiadającego w CSD konto ABCD. Kupujący CUSTOMER1 jest klientem uczestnika CSD oznaczonego kodem BBBB i posiadającego w CSD konto 1213. CUSTOMER1 posiada w instytucji BBBB konto oznaczone jako CUST1ACC2. Instrukcje zestawią się dzięki zgodnemu wypełnieniu pól: klient strony dostarczającej i klient strony przyjmującej. Dla strony dostarczającej kod klienta został podany w postaci kodu BIC, a dla strony przyjmującej podano identyfikator rachunku klienta. 3
Instrukcje w formacie systemu kdpw_stream zawiązane z powyżej opisanym przykładem będą miały następującą postać: <?xml version="1.0" encoding="utf-8"?> <KDPWDocument Sndr="09AA" Rcvr="0001" xmlns = "urn:kdpw:xsd:sese.ins.001.01"xmlns:xsi=http://www.w3.org/2001/ XMLSchema-instance sese.ins.001.01.xsd"> <sese.ins.001.01> <GnlInf> <InstrTp>DP</InstrTp> <SndrMsgRef>A INS1</SndrMsgRef> <FuncOfMsg>NEWM</FuncOfMsg> </GnlInf> <TradDtls> <ISIN>PL1234567890</ISIN> <ReqdSttlmQty> <Unit>1100</Unit> </ReqdSttlmQty> </TradDtls> <SttlmDtls> <SttlmTxTp>TRAD</SttlmTxTp> <SttlmDtTm> <Dt>2010-11-18</Dt> </SttlmDtTm> <DlvrgSdDtls> <SellrDtls> <BIC>AAAAPLPWXXX</BIC> </SellrDtls> <DlvrgAgtDtls> <KDPWMmbId>AAAA</KDPWMmbId> <KDPWSafAcct>ABCD</KDPWSafAcct> </DlvrgAgtDtls> </DlvrgSdDtls> <RcvgSdDtls> <BuyrDtls> <PrtryId>CUSTOMER1</PrtryId> <SafAcct>CUST1ACC2</SafAcct> </BuyrDtls> <RcvgAgtDtls> <KDPWMmbId>BBBB</KDPWMmbId> <KDPWSafAcct>1213</KDPWSafAcct> </RcvgAgtDtls> </RcvgSdDtls> <SttlmAmt Ccy="PLN">200000.4</SttlmAmt> </SttlmDtls> </sese.ins.001.01> </KDPWDocument> <?xml version="1.0" encoding="utf-8"?> <KDPWDocument Sndr="09BB" Rcvr="0001" xmlns = "urn:kdpw:xsd:sese.ins.001.01"xmlns:xsi=http://www.w3.o rg/2001/xmlschema-instance sese.ins.001.01.xsd"> <sese.ins.001.01> <GnlInf> <InstrTp>PP</InstrTp> <SndrMsgRef>B INS1</SndrMsgRef> <FuncOfMsg>NEWM</FuncOfMsg> </GnlInf> <TradDtls> <ISIN>PL1234567890</ISIN> <ReqdSttlmQty> <Unit>1100</Unit> </ReqdSttlmQty> </TradDtls> <SttlmDtls> <SttlmTxTp>TRAD</SttlmTxTp> <SttlmDtTm> <Dt>2010-11-18</Dt> </SttlmDtTm> <DlvrgSdDtls> <SellrDtls> <BIC>AAAAPLPWXXX</BIC> </SellrDtls> <DlvrgAgtDtls> <KDPWMmbId>AAAA</KDPWMmbId> <KDPWSafAcct>ABCD</KDPWSafAcct> </DlvrgAgtDtls> </DlvrgSdDtls> <RcvgSdDtls> <BuyrDtls> <PrtryId>CUSTOMER1</PrtryId> <SafAcct>CUST1ACC2</SafAcct> </BuyrDtls> <RcvgAgtDtls> <KDPWMmbId>BBBB</KDPWMmbId> <KDPWSafAcct>1213</KDPWSafAcct> </RcvgAgtDtls> </RcvgSdDtls> <SttlmAmt Ccy="PLN">200000.4</SttlmAmt> </SttlmDtls> </sese.ins.001.01> </KDPWDocument> 4
Analogiczne komunikaty ISO15022 będą miały następującą postać: MT543 :16R:GENL :20C::SEME//A INS1 :23G:NEWM :16S:GENL :16R:TRADDET :98A::SETT//20101108 :35B:ISIN PL1234567890 :16S:TRADDET :16R:FIAC :36B::SETT//UNIT/1100, :95R::ACOW/KDPW/AAAA :97A::SAFE//ABCD :16S:FIAC :16R:SETDET :22F::SETR//TRAD :16R:AMT :19A::SETT//PLN200000,4 :16S:AMT :16S:SETDET :95Q::BUYR//CUSTOMER1 :97A::SAFE//CUST1ACC2 :95P::SELL//AAAAPLPWXXX :95R::REAG/KDPW/BBBB :95C::PSET//KDPWPLPW MT541 :16R:GENL :20C::SEME//B INS1 :23G:NEWM :16S:GENL :16R:TRADDET :98A::SETT//20101108 :35B:ISIN PL1234567890 :16S:TRADDET :16R:FIAC :36B::SETT//UNIT/1100, :97R::ACOW/KDPW/BBBB :97A::SAFE//1213 :16S:FIAC :16R:SETDET :22F::SETR//TRAD :16R:AMT :19A::SETT//PLN200000,4 :16S:AMT :16S:SETDET :95Q::BUYR//CUSTOMER1 :97A::SAFE//CUST1ACC2 :95P::SELL//AAAAPLPWXXX :95R::DEAG/KDPW/AAAA :95C::PSET//KDPWPLPW 5
Poniżej przedstawiono w skróconej formie kilka innych przykładów prawidłowego i błędnego użycia pola klient: Instrukcja kupna Instrukcja sprzedaży Zestawienie Uwagi 95P::BUYR//ABCDPLPW 95P::BUYR//ABCDPLPWXXX Nie BIC11 nie zestawia się z BIC8 95P::BUYR//ABCDPLPW 95P::SELL//XYZZUS33 (brak odpowiednika) 95P::SELL//XYZZUS33 Tak Brak wypełnienia pola jest dozwolony 95Q::SELL//CUSTOMER1 95P::SELL//XYZZUS33 Nie Różne formaty pola 95P::BUYR//ABCDPLPWAA1 95Q::SELL//12345 95P::BUYR//ABCDPLPWAA1 95Q::SELL//12345 Tak Identyfikator klienta może być podawany jako BIC (opcja P) lub identyfikator dowolny (opcja Q) 6