The NSD Trade Repository Manual for completion of the block Information about Party clients (clientdetails) in repository forms

Transcription

1 The NSD Trade Repository Manual for completion of the block (Revised )

2 Current version of the Bank of Russia s Directive 3253-U dated defines the information that must be recorded in the register maintained by the repository. According to the Appendix 1, Table 2 (General information about Contract) the information about Party clients must be included to the register. In order to comply with the regulation the repository has developed a new xsd-scheme that made the block clientdetails (Information about Party clients) mandatory for reporting. <xsd:element name="clientdetails" type="partyclientdetails" maxoccurs="2"> <xsd:annotation> <xsd:appinfo source="mre"/> <xsd:documentation source="nsdr" xml:lang="ru">информация о клиенте стороны </xsd:documentation> <xsd:documentation source="nsdr" xml:lang="en">information about Party clients </xsd:documentation> <xsd:documentation source="stdc" xml:lang="ru">информация о клиенте стороны </xsd:documentation> <xsd:documentation source="stdc" xml:lang="en">information about Party clients </xsd:documentation> </xsd:annotation> </xsd:element> This group of fields includes the following elements:

3 1. servicingparty (Party, servicing a client) Party Identifier which is indicated as Party1 or Party2 that must be completed in the block clientdetails. The number of Party is indicated in accordance with a Master agreement. 2. A choice of the Client type has three options: Branch «Own party trade» If the field owntrade (Own party trade) contains a fixed value true, completion of this branch means that Party indicated in servicingparty concluded a contract is a proprietary trade. Fixed value true replaces a value N that is required by the Directive in the Appendix 1 meaning a contract is concluded in not clients interests. <nsdext:servicingparty href="party1"/> <nsdext:owntrade>true</nsdext:owntrade> Branch «Trade is on behalf of a client» This branch means that Party indicated in the field servicingparty concluded a contract on behalf of its own name, but at client s expenses. In this case information about client must contain the following: o type (Client type) may have the following values: F - client is a professional financial market participant 1 : credit institution, broker, dealer, asset manager, depository, registrar, non-governmental pension fund, management company of investment funds, unit investment funds and non-governmental pension funds, joint-stock investment fund, trade organizer, clearing company, insurance company; L - client is classified as another legal entity type; 1 In accordance with the paragraph 1.1 of the Bank of Russia s Directive 3253-U dated 30 April,

4 o o o P - client is an individual. id (Identifier) Client code is indicated by Party of a contract that uniquely identifies client. Should be completed in accordance with the rules For residents of Russia the codes LEI or INN (Tax ID) must be indicated for legal entities and code SNILS (Insurance individual account number) for individuals. For non-residents of Russia the following code is accepted: LEI, SWIFT, Bloomberg, Thomson Reuters and Own code assigned by Party of Master agreement/contract. name (Name) Short client name of Party, in Russian or English (full legal name of the entity or full name of individual). country (Country code) The country code of the client indicated in accordance with the client legal address in accordance with the format ISO <nsdext:servicingparty href="party2"/> <nsdext:type>p</nsdext:type> <nsdext:id>snils_ </nsdext:id> <nsdext:name>иванов Иван Иванович</nsdext:name> <nsdext:country countryscheme=" 4

5 Branch «No information about client» Completion of this branch is allowed in case of unilateral registration of a message which contains information about counterparty (counterparty in an agreement) specified in the field servicingparty. At the same time counterparty can act as: - not repository client (has no repository code) and is not obliged to provide information to a repository; - specified as unwillingreportingparty in a Master agreement which does not provide information to the Repository. The noinformation field (Lack of information if a trade is done in clients interests of it is a prop trade) specified as a value true. In other case this branch is not allowed. <nsdext:servicingparty href="party1"/> <nsdext:noinformation>true</nsdext:noinformation> <nsdext:servicingparty href="party2"/> <nsdext:type>p</nsdext:type> <nsdext:id>snils_ </nsdext:id> <nsdext:name>иванов Иван Иванович</nsdext:name> <nsdext:country countryscheme=" 5

6 A group of elements clientdetails (Information about Party clients) is repeatable and completed for each Party (Party 1 and Party 2) of contract: In case of unilateral registration procedure a message sent to the repository must contain two blocks for both Parties which means that Reporting Party must compete the information about clients from both Parties of contract. <nsdext:servicingparty href="party1"/> <nsdext:owntrade>true</nsdext:owntrade> <nsdext:servicingparty href="party2"/> <nsdext:type>p</nsdext:type> <nsdext:id>snils_ </nsdext:id> <nsdext:name>иванов Иван Иванович</nsdext:name> <nsdext:country countryscheme=" 6

7 In case of two-side matching a message to the repository may contain the block at least for one Party client. In this case information about the second Party client should be indicated in a message sent by Counterparty to the repository or added when confirming trades details in negotiated sequentially. Party 1 message <nsdext:servicingparty href="party1"/> <nsdext:owntrade>true</nsdext:owntrade> Party 2 message 7

8 <nsdext:servicingparty href="party2"/> <nsdext:type>p</nsdext:type> <nsdext:id>snils_ </nsdext:id> <nsdext:name>иванов Иван Иванович</nsdext:name> <nsdext:country countryscheme=" All elements in the group clientdetails (Information about Party clients) have an indication as Special field reconciliation (sfr) meaning that elements mandatory to be filled in for successful registration, but if such elements are different in cross messages of both counterparties if these elements are filled in by both counterparties, message registration will be rejected. If only one counterparty filled in these fields, elements shall be deemed reconciled and element values will be entered in the registry. 8