new.nsd.runew.nsd.ru/.../en/repository_rules_2020_04_06_en.docx · Web viewfor the provision of Repository Services, Client’s and Repository’s rights and obligations, and a

APPROVEDby the Chairman of the Executive Board(Order No. 228 dated 31 October 2016)

RULES FOR THE PROVISION

OF REPOSITORY SERVICES BY NSD REPOSITORY

Table of Contents

1. TERMS AND DEFINITIONS................................................................................................2

2. GENERAL PROVISIONS......................................................................................................2

2.1. Subject Matter of the Rules.............................................................................................2

2.2. Obligations of the Repository and Clients.......................................................................2

2.2.1. The Repository shall:...............................................................................................2

2.2.2. A Client shall:..........................................................................................................2

2.3. Rights of the Repository and Clients...............................................................................2

2.3.1. The Repository may:...............................................................................................2

2.3.2. The Client may:.......................................................................................................2

2.4. Participants and Their Functions.....................................................................................2

2.4.1. Reporting Agent......................................................................................................2

2.4.2. Clients......................................................................................................................2

2.4.3. The Repository........................................................................................................2

2.5. Services Provided by the Repository...............................................................................2

2.6. Payment for Repository Services....................................................................................2

2.6.1. General Provisions...................................................................................................2

2.6.2. Billing Process and Payment for Services...............................................................2

2.7. Responsibility and Liability of the Repository and Clients.............................................2

2.7.1. Responsibility and Liability of the Repository............................................................2

2.7.2. Responsibility of a Client........................................................................................2

2.7.3. Liability of the Parties.............................................................................................2

2.8. Amendments to the Rules................................................................................................2

2.9. Termination of the Repository Services Agreement.......................................................2

3. DOCUMENTS TO BE SUBMITTED TO THE REPOSITORY FOR THE PURPOSE OF IDENTIFICATION OF PARTICIPANTS......................................................................................2

4. GENERAL DATA INTERCHANGE PROCESS...................................................................2

4.8. Timing of Repository Operations Execution...................................................................2

4.9. Refusal to Accept Documents and Make Data Entries in the Contracts Register...........2

4.10. Delivery of Reports Following the Execution of Repository Operations....................2

4.11. Receipt by a Client of Repository’s Reports on an Electronic Medium..................2

5. METHODS OF MAKING DATA ENTRIES IN THE CONTRACTS REGISTER..............2

2

5.1. Bilateral Entry of Information in the Contracts Register.................................................2

5.1.5. Reconciliation Process.............................................................................................2

5.1.6. Consecutive Confirmation Process..........................................................................2

5.1.7. Matching Confirmation Process..............................................................................2

5.1.8. Combined Confirmation of Reporting Forms.........................................................2

5.2. Unilateral Entry of Information in the Contracts Register..............................................2

5.2.5. Procedures to be followed by a Client where the second party to a Master Agreement/Contract is a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to provide information to the Contracts Register...2

5.2.6. Procedures to be followed by a Client where the second party to a Master Agreement/Contract is a person who is, in accordance with the effective Russian laws, neither obliged to report information to the Repository, nor is a Repository’s Client............2

6. REPOSITORY OPERATIONS...............................................................................................2

6.1. Registration of, or Making Changes to, a Participant’s Details..........................................2

6.2. Assignment of Identification Codes................................................................................2

6.3. Registration of the Appointment / Revocation of the Appointment / Resignation of a Reporting Agent..........................................................................................................................2

6.3.1. Registration of the Appointment by a Client of a Reporting Agent............................2

6.3.2. Registration of the Revocation of the Appointment / Resignation of a Reporting Agent 2

6.4. General Provisions of the Contracts Register Keeping Procedure..................................2

6.4.1. General Provisions.................................................................................................2

6.4.2. Section 1 of the Contracts Register (the Messages Log).........................................2

6.4.3. Making Data Entries in Section 2 of the Contracts Register...................................2

6.4.4. Section 3 of the Contracts Register (the Registration Log).....................................2

6.5. Registration of information on a Master Agreement, Amendments to a Master Agreement, or Termination of a Master Agreement...................................................................2

6.6. Registration of Information on a Contract / Amendments to a Contract in the Contracts Register........................................................................................................................................2

6.7. Registration of Information on the Status of Obligations under a Contract, Including Termination or Discharge of Obligations (Termination of a Contract).......................................2

6.8. Registration of a Credit Support Annex Reporting Form................................................2

6.9. Registration of a Credit Support Transfer Reporting Form.............................................2

6.10. Registration of Information on Mark to Market Valuation.........................................2

6.11. Registration of Information on Technical Repo Transactions, FX Swap Transactions, and Foreign Exchange Spot Transactions.............................................................2

3

6.12. Making Corrective Entries in the Contracts Register..................................................2

6.12.1 Making Corrective Entries in the Contracts Register in Connection with Objections Raised by a Reporting Agent/Client......................................................................2

6.12.2. Making Corrective Entries in the Contracts Register in Connection with Corrections Made by a Reporting Agent.................................................................................2

6.13. Procedure for, and Time Limits of, Provision of Information from the Contracts Register 2

6.13.1. Provision of Information from the Contracts Register to a Reporting Agent on a Regular Basis...........................................................................................................................2

6.13.2. Provision of the Contracts Register to the Financial Market Regulator on a Daily Basis 2

6.13.3. Procedure for, and Time Limits of, Provision of Information from the Contracts Register upon an Interested Person’s Written Request............................................................2

7. ELECTRONIC COMMUNICATION........................................................................................2

7.1. General Provisions...........................................................................................................2

7.2. Electronic Communication via the NSD EDI System....................................................2

7.3. Electronic Communication via Web Channels................................................................2

7.4. Electronic Communication via the SWIFT System........................................................2

Appendix 1..............................................................................................................................2

Forms of Messages to Be Submitted in Hard Copy or in Electronic Format in the Course of Data Interchange with the Repository...............................................................2

Appendix 2..............................................................................................................................2

Guidelines on Completion of Message Forms to Be Sent to the Repository....................2

1. Completion of Common Fields in Messages to Be Sent to the Repository...............2

Appendix 3..............................................................................................................................2

DECLARATION OF ACCESSION TO THE RULES FOR THE PROVISION OF REPOSITORY SERVICES..................................................................................................2

4

1. TERMS AND DEFINITIONS

1.1. The defined terms used herein shall include, inter alia, the following:

“NSD’s Web-service” means a communication channel that supports interface between a Client’s and/or a Reporting Agent’s software and the Repository Software on the basis of the prescribed protocol.

“Excerpt from the Contracts Register” means a document containing information on Master Agreements and Contracts made by Clients under Master Agreements, as well as Contracts made other than under Master Agreements, as recorded in the Contracts Register as at the issuance date of such Excerpt.

“Master Agreement” means an agreement entered into by a Client other than on an established market and setting out general principles of entering into, performing and/or terminating derivative contracts or any other types of contracts to be reported to the Repository in accordance with the effective Russian laws and/or Financial Market Regulator’s regulations.

“Contract” means a contract made other than on a stock exchange, whether or not under a Master Agreement, which is to be reported to the Repository to make a data entry in the Contracts Register pursuant to the effective Russian laws and Financial Market Regulator’s regulations, or a contract made other than on a stock exchange, whether or not under a Master Agreement, which is reported by the Client to make a data entry in the Contracts Register other than in accordance with the reporting requirements of the effective Russian laws and Financial Market Regulator’s regulations.

“EDI Agreement” means an agreement that sets out the terms and conditions of, and the procedure for, electronic data interchange between the Repository and a Reporting Agent in the course of their performance under the Repository Services Agreement between them.

“Repository Services Agreement” means an agreement entered into between the Repository and a Client and setting out the general procedure for the provision of Repository Services, Client’s and Repository’s rights and obligations, and a dispute resolution procedure. A Repository Services Agreement shall be a standard form agreement and shall be entered into by signing a Declaration of Accession hereto.

“Identification Code” or “Repository Code” means a unique combination of characters assigned by the Repository to a Client / a Reporting Agent / the Repository for the purpose of identifying such persons in the Repository’s recordkeeping system.

“Reporting Agent” means a person who has entered into an EDI Agreement and a Repository Services Agreement with the Repository and who is appointed by a Client(s), being a party (parties) to the relevant Master Agreement and/or Contract, as the person responsible to report information to the Repository.

“Client” means a person who has entered into a Repository Services Agreement with the Repository in the manner provided for hereby.

“Client not obliged to report information to the Repository” means a person who is a party to a Contract made other than on a stock exchange, whether or not under a Master Agreement, the information of which is to be entered in the Contracts Register, and who is, at the same time, a

5

Repository’s Client who, in accordance with the Financial Market Regulator’s regulations, is not obliged (released from the obligation) to report information to the Repository.

“Repository Services User Committee” or “Committee” means a standing body made up of representatives of Repository’s Clients, which is established for the purpose of taking account of Clients’ interests when drafting and negotiating Repository’s internal regulations and fee schedules, and which operates in accordance with the Regulations on the Repository Services User Committee.

“Legal Entity Identifier” or “LEI” means an international legal entity identifier assigned in accordance with the ISO standards.

“Repository’s Business Hours” or “Business Hours” means a period of time determined by NSD’s authorized body, during which Repository Services are provided to Clients.

“Repository Operation” (“Operation”) means a series of steps taken by the Repository to process information in Repository’s registers or Reporting Agents’ and/or Clients’ messages, scanned copies of documents provided by Reporting Agents and/or Clients, or other additional information provided by Reporting Agents and/or Clients for the purpose of making data entries in the Contracts Register, as well as for subsequent registration and safekeeping thereof at the Repository.

“Regulations on the Repository Services User Committee” means the Repository’s internal regulations that describe the establishment and operation procedures of the Services User Committee, the Committee’s decision-making process, and responsibilities of Committee’s members. The regulations shall be drafted by the Repository and approved by the Bank of Russia in accordance with the procedure set forth by the Bank of Russia's regulations.

“Rules” means these Rules for the Provision of Repository Services by NSD Repository.

“NSD’s Electronic Data Interchange Rules” or “EDI Rules” means the rules set out in Appendix 1 to the EDI Agreement.

“Repository Software” means NSD’s software designed to support the provision of Repository Services, which includes clients’ local interfaces, a server (Repository’s database), and a message converting tool.

“Registration Number” or “Repository Number” means a unique combination of characters assigned by the Repository to identify a document (Reporting Form / Report / Application / Confirmation or any other document) submitted by a Client / Reporting Agent to make a data entry in the Contracts Register and registered by the Repository in the Contracts Register.

“Financial Market Regulator” means the Central Bank of the Russian Federation (Bank of Russia).

“Contracts Register” means the register (electronic database) intended for recording information reported by Clients or Clients’ Reporting Agents for the purpose of making data entries in the Contracts Register, including information on all Master Agreements and Contracts. The Contracts Register comprises three sections (Section 1, Section 2, and Section 3).

“Repository” means National Settlement Depository (NSD).

6

“Repository Services” means services provided by the Repository to a Client and/or to a Reporting Agent in accordance herewith.

“Reconciliation” means the process of matching by the Repository of messages received from Reporting Agents of the parties to a Master Agreement/Contract for the purpose of entering information of Contracts/Master Agreements in the Contracts Register.

“Internal Instruction” means a Repository’s document signed by a Repository’s authorized representative and constituting the basis for making a Repository Operation.

“Participants Reference Guide” means a list of Participants containing details of each Participant (as per the list of details set out in the Participants Reference Guide Form available on the Repository’s official web site at www.nsd.ru), which is to be used by a Client and/or a Reporting Agent for the purpose of generating messages to be sent to the Repository.

CMS (Collateral Management System) means NSD’s automated system responsible for finding collateral and selection of securities.

“Fee schedule” means the Fee Schedule for Repository Services.

“IT Failure” means an emergency resulting in a disruption of a Reporting Agent’s or Repository’s software.

“Unique Trade Identifier” or “UTI” means an identifier generated in accordance with the particular rules and assigned to a Contract by a generating party when entering into the Contract in order to unambiguously identify the Contract for the purpose of reporting it to the Repository.

“Participant” means a Client and/or a Reporting Agent and/or the Repository.

“Participants” means Clients, Reporting Agents, and the Repository taken together.

1.2. Any other terms used herein shall be construed in accordance with the effective Russian laws and, to the extent related to electronic data interchange, the EDI Rules.

1.3. A term in the singular shall be construed as including the plural; a term that is a noun derived from a verb shall equally apply to the verb from which it is derived; and a term that is a noun shall equally apply to an adjective derived from such noun.

1.4. In these Rules, unless the context requires otherwise, any references to clauses shall be construed as references to clauses hereof and any references to an Appendix shall be construed as references to such Appendix hereto.

2. GENERAL PROVISIONS

2.1. Subject Matter of the Rules

2.1.1. These Rules for the Provision of Repository Services (the “Rules”) set out the procedure for, and terms and conditions of, the provision by the Repository of services for registration in the Contracts Register of information reported by a person(s) designated by a Client being a party to a Contract, as well as services for the provision of information from the Contracts Register and/or other related services.

7

2.1.2. These Rules shall be approved by the Repository Services User Committee following the receipt by the Repository of a relevant license and establishment of the Repository Services User Committee in accordance with the effective Russian laws and/or Financial Market Regulator’s regulations.

2.1.3. The entering into a Repository Services Agreement by a Client being a party to a Master Agreement or Contract shall be made by the Client’s acceding hereto by executing and submitting to the Repository of a hard-copy Declaration of Accession to the Rules for the Provision of Repository Services (Appendix 3 hereto).

2.1.4. Where a Client already has an Agreement on the Terms and Conditions for the Provision of Repository Services with the Repository, the Client shall be deemed to have entered into the amended and restated Repository Services Agreement, unless the Client, within thirty (30) calendar days of the date when the Declaration of Accession to the Rules for the Provision of Repository services is posted on the Repository’s official web site, gives notice to the Repository in which the Client expressly refuses to accede to these Rules (such notice to be given in the form of a notice of termination of the relevant Agreement on the Terms and Conditions for the Provision of Repository Services), subject to the requirements hereof concerning termination or discharge of obligations under any Contract recorded in the Contracts Register as at the termination date.

2.1.5. In the event of any inconsistencies between the provisions of the relevant Agreement on the Terms and Conditions for the Provision of Repository Services and these Rules, relationships between the Repository and the Client shall be governed by the provisions hereof.

2.1.6. Where a Payer violates the payment schedule for a period exceeding 2 (two) months, the Repository has the right to terminate the Repository Services Agreement. Further interaction with such Payer shall be governed by NSD’s Regulations for Accounts Receivable.

The Repository has a right to deny Client entering into the Repository Services Agreement in case when such agreement was terminated previously with such a client due to nonpayment for the services. In order to enter the Repository Services Agreement the Repository has a right to demand payment of the arrears in full under previous agreement.

2.1.7. A Repository Services Agreement shall contain the Legal Entity Identifier (LEI) of the Client (party to a Contract) and the LEI of the Reporting Agent.

2.1.8. The Repository shall provide Repository Services in accordance with the Federal Law “On the Securities Market”, Financial Market Regulator’s regulations, other regulations, and these Rules.

2.1.9. The procedure for approval hereof and making amendments hereto shall be governed by the Federal Law “On the Securities Market” and Repository’s internal regulations.

2.1.10. The Repository may enter into any other agreement (in particular, supplemental agreements) with a Client, which shall govern the provision of Repository Services. Such agreements must be consistent herewith.

2.1.11. These Rules shall be of a public nature and shall be posted on the Repository’s official web site at www.nsd.ru or made available upon request by any interested party.

2.1.12. These Rules set out:

8

- procedures to be followed by Clients, Reporting Agents, and the Repository to perform operations under the Repository Services Agreement;

- basis for making Repository Operations;

- templates of documents and specifications of electronic messages that are to be received by the Repository from Clients and/or Reporting Agents;

- templates of documents and specifications of electronic messages that are to be provided by the Repository to Clients and/or Reporting Agents;

- time limits for Repository Operations; and

- procedure and time limits for the provision of information from the Contracts Register by the Repository to Clients and/or Reporting Agents, or to any other persons referred to herein.

2.1.13. Participants Reference Guides required to enable communication between the Repository and Clients/Reporting Agents in the course of Repository Services shall be maintained and updated by the Repository and posted on the Repository’s official web site at www.nsd.ru. Participants Reference Guides available on the web site shall be updated automatically at the end of the Business Hours (if amended in the Repository’s database).

2.1.14. In compliance with the Russian laws, the Repository has in place and applies measures aimed at prevention of and fight against corruption. The Repository does not make anything that would be treated in accordance with the Russian laws as the giving or acceptance of a bribe or commercial bribery, and neither the Repository pays or provides or offers to pay or provide any cash or valuables, either directly or indirectly, to any person to exert influence on such person’s behaviour or decisions with a view to obtaining any undue advantages or achieving any other inappropriate goals, or makes any other thing in a violation of the Russian anticorruption laws.

2.2. Obligations of the Repository and Clients

2.2.1. The Repository shall :

2.2.1.1. Register all messages received by the Repository in connection with its activities, within the time limits and in the manner required hereby.

2.2.1.2. Check integrity of received messages and documents connected with the keeping of the Contracts Register, and ensure integrity of information recorded in the Contracts Register, its protection against distortion and unauthorized access, and security of electronic signatures throughout the retention periods required hereby.

2.2.1.3. Make data entries in the Contracts Register within the time limits and in the manner required hereby.

2.2.1.4. Register the making of data entries, and each refusal to make a data entry, in the Contracts Register within the time limits and in the manner required hereby.

2.2.1.5. No later than the business day next to the date when a data entry is made in the Contracts Register (Section 2 of the Contracts Register), provide an Excerpt from the Contracts Register to the relevant Reporting Agent.

9

2.2.1.6. Not use any information on Clients or Reporting Agents or any information from the Contracts Register for any purpose that prejudices or is likely to prejudice legitimate rights and interests of any Client or Reporting Agent.

2.2.1.7. Give notice to Clients/Reporting Agents of any and all amendments hereto or to the Fee Schedule for Repository Services within the time limits and in the manner required hereby.

2.2.1.8. Review any objection raised against any data entry made in the Contracts Register within the time limits required by the Financial Market Regulator’s regulations following the receipt of such objection, and either make necessary corrective data entries in the Contracts Register or send a motivated refusal to accept the objection to the Reporting Agent or Client.

2.2.2. A Client shall:

2.2.2.1. Submit to the Repository necessary documents, subject to the terms and conditions and as per the list set out herein.

2.2.2.2. Submit the Client’s details for initial registration in the manner set forth hereby.

2.2.2.3. Report, in a timely fashion, updated information to be recorded in NSD’s recordkeeping systems in accordance herewith, and any other information that is material to the performance by the Repository of its obligations to the Client under the Repository Services Agreement.

2.2.2.4. Appoint at least one Reporting Agent authorized to communicate and deal with the Repository. In appointing a Reporting Agent, the Client shall take account of the Repository’s requirements to Reporting Agents.

2.2.2.5. Provide the Repository with the details of the Client’s Reporting Agent(s) in the manner set forth hereby. A new Client shall be treated as a Reporting Agent for such Client's messages, with respect to each of the Participant Identification Codes assigned to the Client, until the Client appoints a Reporting Agent(s).

2.2.2.6. Notify, in a timely fashion, the Repository of the revocation of the appointment of any Reporting Agent authorized to communicate with the Repository on behalf of the Client. The Repository shall not be liable for any action taken hereunder on the basis of a message received from a Reporting Agent whose appointment was revoked by the Client, provided that such action was taken before the Repository was notified by the Client of the revocation of the Reporting Agent’s appointment.

2.2.2.7. Where the appointment of a Reporting Agent(s) is revoked or the Reporting Agent resigns, and provided that the Repository does not have information on at least one Reporting Agent appointed by the Client (confirmed to be acting as a Reporting Agent (which can be the Client himself)), the Repository will not communicate and deal with the Client until the Client appoints a Reporting Agent (which can be the Client himself).

2.2.2.8. Ensure the performance by the Client’s Reporting Agents of their functions set out herein.

10

2.3. Rights of the Repository and Clients

2.3.1. The Repository may :

2.3.1.1. Refuse to make a data entry in the Contracts Register in the cases and in accordance with the procedure set forth hereby.

2.3.1.2. At its own discretion and without further consent from Clients, amend these Rules and the Fee Schedule by giving notice of such amendments to Clients and Reporting Agents in accordance with clause 2.8.2 hereof, subject to the approval procedures applicable hereto and to the Fee Schedule, as provided for by the Federal Law “On the Securities Market” and/or Financial Market Regulator’s regulations.

2.3.2. The Client may :

2.3.2.1. Take steps provided for hereby.

2.3.2.2. In the cases stipulated hereby, receive information or documents provided for hereby, either on his own account or through any Reporting Agent appointed by the Client.

2.3.2.3. Either on his own account or through any Reporting Agent appointed by the Client, give reasoned objections as to any information entered in the Contracts Register, in accordance with the procedure and within the time limits set forth hereby.

2.3.2.4. Appoint a Reporting Agent and change the Reporting Agent’s scope of authority. The appointment of any Reporting Agent may be revoked on any ground provided for by the Russian laws. To revoke the appointment of any Reporting Agent, the Client shall give notice to the Repository of such revocation and the appointment of a replacement Reporting Agent(s) by submitting a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto).

2.3.2.5. Refuse reporting information to the Contracts Register in the cases provided for by the Russian laws, Financial Market Regulator’s regulations, and these Rules.

2.4. Participants and Their Functions

2.4.1. Reporting Agent

2.4.1.1. A Reporting Agent shall be appointed by the parties to a Contract. The Reporting Agent shall report Master Agreements and/or Contracts to the Repository and receive Repository's reports regarding information on any Master Agreements/Contracts recorded in the Contracts Register, with respect to which the Reporting Agent is appointed as such.

2.4.1.2. A Reporting Agent shall act for and on behalf of the Client who appointed the Reporting Agent, within the scope of authority given by the Client.

2.4.1.3. Any Client himself may act as a Reporting Agent.

2.4.1.4. Where both parties to a Master Agreement/Contract appoint one of the parties thereto or any other person to act as a Reporting Agent, such Reporting Agent will unilaterally report the Master Agreement and/or Contracts or amendments thereto.

2.4.1.5. Where both parties to a Contract appoint NSD to act as a Reporting Agent (in the cases provided for hereby or by any other NSD’s regulations), such Reporting Agent will unilaterally report Contracts or amendments thereto.

11

2.4.1.6. With respect to repo transactions with securities basket concluded on the OTC market under the terms of Master agreement with the Bank of Russia or with the Federal Tresury where NSD performs CMS services, functions of the Reporting agents are exercised by the NSD.

2.4.1.7. With respect to repo transactions concluded by the clients on the OTC market where NSD performs CMS services, NSD exercises Reporting agent’s functions when collateral is managed by the NSD.

2.4.1.8. Where one of the parties to a Master Agreement/Contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client, or a person who has refused to report information to the Repository and failed to appoint a Reporting Agent, a Reporting Agent shall be appointed by the party to such Master Agreement/Contract who is obliged to report (and reports) information to the Repository.

2.4.1.9. A Reporting Agent, other than NSD, shall be required to be a Repository’s Client and to have an EDI Agreement with the Repository.

2.4.1.10. A Reporting Agent shall be required to have an Identification Code to be used to identify the Reporting Agent in the Repository’s recordkeeping system. Where a Client acts as a Reporting Agent, the Reporting Agent’s Identification Code and the Client’s Identification Code can be the same.

2.4.1.11. A Reporting Agent shall be required to have a LEI.

2.4.1.12. The details of a Reporting Agent shall be provided to the Repository by the appointing Client by submitting a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto), stating the scope of authority given to the Reporting Agent.

2.4.1.13. A Reporting Agent shall give or refuse to give his consent to act for and on behalf of the appointing Client in accordance with the scope of authority given to the Reporting Agent by submitting to the Repository a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto) or a Disagreement Notification (Form CM002 in Appendix 1 hereto).

2.4.1.14. Where a Reporting Agent decides to resign, the Reporting Agent shall submit to the Repository a Reporting Agent Resignation Application (Form CM017 in Appendix 1 hereto).

2.4.1.15. Reporting Agent’s functions shall include:

- reporting information on Master Agreements, their amendments or termination, and reporting information on Contracts, changes in their terms and conditions, or changes in obligations thereunder;

- submitting objections to the Repository as to any information recorded in the Contracts Register;

- receiving Excerpts from the Contracts Register from the Repository;

-

- receiving Repository’s reports regarding information recorded in the Contracts Register;

- paying for Repository Services;

- liaising with the Repository with regard to any claims made by the Client in connection with Repository Services; and

12

- receiving any other Repository’s services provided for hereby on behalf of the Client.

2.4.1.16. The scope of a Reporting Agent’s authority shall be determined by the Client in the relevant Reporting Agent Appointment Application submitted to the Repository.

2.4.1.17. Any document submitted to the Repository by a Reporting Agent shall contain the Reporting Agent’s Identification Code and the Identification Code of the Client on whose behalf the Reporting Agent acts.

2.4.1.18. Where a Master Agreement provides for the possibility to make trades of various types, the parties to the Master Agreement may appoint a Reporting Agent for each trade type provided for by the Master Agreement.

2.4.1.19. Where the parties to a Master Agreement/Contract agreed that information on the Master Agreement/Contracts would be reported by two Reporting Agents, each party may appoint only one Reporting Agent for the Master Agreement/Contracts. This restriction shall not affect the parties' right to designate any other person to report information on Contracts, whether or not such Contracts are made under a Master Agreement, to any repository incorporated and existing under the laws of a foreign jurisdiction.

2.4.1.20. A Reporting Agent shall provide the appointing Client with any reports received from the Repository and addressed to the Client.

2.4.1.21. A Reporting Agent shall retain any underlying documents on the basis of which the relevant documents submitted by the Reporting Agent to the Repository were prepared.

2.4.1.22. The Repository shall not be liable to any Client for any losses sustained by the Client as a result of any actions or omissions by the Reporting Agent appointed by the Client.

2.4.2. Clients

2.4.2.1. When entering into the Repository Services Agreement, a Client may appoint at least one Reporting Agent in accordance with the procedure set forth hereby and provide such Reporting Agent with the relevant authority (if such Reporting Agent is a third party), or the Client may act as a Reporting Agent himself. Where a Client elects to act as a Reporting Agent himself, the Client shall not be required to submit a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto). A Client acting as a Reporting Agent must meet the Repository’s requirements to Reporting Agents.

2.4.2.2. Where a Client has submitted a Reporting Agent Appointment Application to the Repository, but the Repository’s recordkeeping system does not contain a confirmation from the relevant Reporting Agent of his willingness to act for and on behalf of the Client in accordance with the scope of authority given to the Reporting Agent, or the Reporting Agent refuses to act for and on behalf of the Client in accordance with the scope of authority given to the Reporting Agent, the Client shall, for the purposes of communicating with the Repository, either appoint a new Reporting Agent or elect to act as a Reporting Agent himself by submitting a Reporting Agent Appointment Application to the Repository, stating the new Reporting Agent’s details or the Client’s own details (as the case may be).

2.4.2.3. A Client may appoint more than one Reporting Agent and provide all of them with the relevant scope of authority, provided that it shall not be allowed to provide different Reporting Agents with similar authority.

13

2.4.2.4. Where a Client is an individual, the Client shall submit to the Repository a Reporting Agent Appointment Application for at least one legal entity and provide it with the relevant scope of authority. Such legal entity must meet the requirements to Reporting Agents, as set out herein.

2.4.2.5. A Client not obliged to report information to the Repository may refuse to report information to the Contracts Register. To do this, the Client shall submit a Reporting Refusal Notification (Form CM012 in Appendix 1 hereto). However, a Client not obliged to report information to the Repository may:

- remain being the Repository’s Client and have the Client’s rights and obligations provided for hereby; or

- terminate the Repository Services Agreement with the Repository in accordance with the procedure set forth hereby.

2.4.2.6. Procedures to be followed by a Client not obliged to report information to the Repository and who has refused to provide information to the Repository, but has not terminated the Repository Services Agreement

2.4.2.6.1. Where a Client not obliged to report information to the Repository is willing to refuse to report information to the Contracts Register but does not terminate the Repository Services Agreement, the Client shall submit a Reporting Refusal Notification (Form CM012 in Appendix 1 hereto) and notify his counterparty that he has refused to report information to the Repository.

2.4.2.6.2. A Reporting Refusal Notification shall be submitted to the Repository in hard copy only.

2.4.2.6.3. Where a Client not obliged to report information to the Repository and who has two or more Repository Codes has submitted a Reporting Refusal Notification, such Reporting Refusal Notification shall apply to all of the Client’s Repository Codes without any exception.

2.4.2.6.4. Upon receipt of a Reporting Refusal Notification, the Repository shall make the relevant data entries in its recordkeeping systems. At the same time, the Repository shall make changes to the Participants Reference Guide available on NSD’s official web site by making the relevant note against all Repository Codes of the Client who is not obliged and has refused to report information to the Repository. A Reporting Refusal Notification shall be processed by the Repository in accordance with the procedure set out in Section 4 (General Data Interchange Process) hereof.

2.4.2.6.5. The details of a Client not obliged to report information to the Repository shall be entered in the Participants Reference Guide and Repository’s recordkeeping systems no later than the business day immediately next to the date of receipt by the Repository of the relevant Reporting Refusal Notification, provided that the Reporting Refusal Notification is received no later than 5.00 pm. Where the Reporting Refusal Notification is received after 5.00 pm, the details of the Client shall be entered in the Participants Reference Guide and Repository’s recordkeeping systems no later than T+2 date, where T is the date of receipt of the Reporting Refusal Notification.

14

2.4.2.6.6. Where a Client refuses to report information to the Contracts Register, the appointment of all Reporting Agents appointed by the Client shall be deemed to have been revoked.

2.4.2.6.7. A Client who has refused to report information to the Contracts Register shall retain the right to view and receive, through the Web-client, information entered in the Contracts Register regarding any registered/amended Master Agreements and Contracts, whether or not such Contracts are made under Master Agreements, or Credit Support Annexes, as well as information regarding credit support transfers, mark to market valuations, or status of obligations under Contracts if the Client is a party to such Contracts/Master Agreement.

2.4.2.6.8. To resume reporting information to the Contracts Register, a Client who is not obliged and has refused to report information to the Repository shall submit to the Repository a Document Cancellation Notification (Form CM013 in Appendix 1 hereto), and appoint a Reporting Agent by submitting to the Repository a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto).

2.4.2.6.9. Where, in the cases stipulated by the Russian laws, a Client who is not obliged and has refused to report information to the Repository is required to report information on certain Contracts (certain Contract types) upon the achievement of the applicable threshold amounts of transactions made by the Client, the Client shall, in order to resume/start reporting information to the Repository, submit to the Repository a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto), stating the Identification Code(s) of the Reporting Agent(s) and the scope of authority given to the Reporting Agent(s) to report a Contract(s) information on which the Client intends to report to the Repository, or the Client shall state its own Identification Code where the Client elects to act as a Reporting Agent himself.

2.4.2.6.10. Where the reporting of information to the Repository is resumed other than in accordance with the requirements of the Russian laws upon the achievement of the applicable threshold amounts of transactions made by a Repository’s corporate Client who is generally not obliged and has refused to report information to the Repository, the provisions of clause 2.4.2.6.9 above shall not apply. In such cases, for the Client to resume reporting information to the Repository the Client shall act in accordance with clause 2.4.2.6.8.

2.4.2.7. Procedures to be followed by a Client not obliged to report information to the Repository and who is willing to terminate the Repository Services Agreement

2.4.2.7.1. Where a Client not obliged to report information to the Repository refuses to report information to the Contracts Register and is not willing to remain the Repository’s Client, he shall:

- submit a Repository Services Agreement Termination Notification (Form CM014 in Appendix 1 hereto);

- if necessary, close all of the Contracts and Master Agreements registered in the Contracts Register for the Client and having an active status; and

- terminate the Repository Services Agreement.

15

2.4.3. The Repository

2.4.3.1. The Repository shall be engaged in repository business on the basis of a notification of the intention to keep a contracts register, as posted on the Bank of Russia’s official web site, and, after the expiry of 365 days of the effective date of Federal Law No. 430-FZ dated 30 December 2015, on the basis of a license to be issued by the Financial Market Regulator.

2.4.3.2. In accordance herewith, the Repository shall:

- register Clients/Reporting Agents in the Repository’s recordkeeping systems;

- make data entries in the Contracts Register regarding registration, amendment, or termination of Master Agreements;

- make data entries in the Contracts Register regarding registration, amendment, or termination of Contracts, whether or not such Contracts are made under a Master Agreement;

- make data entries in the Contracts Register regarding the status/performance of obligations under Contracts, whether or not such Contracts are made under a Master Agreement; and

- make data entries in the Contracts Register regarding any other information reported by Clients either in accordance with the requirements of the effective Russian laws to report information to the Contracts Register, or other than in accordance with such requirements, provided that in doing so Clients comply with the requirements hereof to the form/formats of information reported by Clients.

2.4.3.3. The Repository shall:

- provide reports (Excerpts from the Contracts Register) to Clients and/or Reporting Agents;

- provide the Contracts Register to the Financial Market Regulator;

- provide information from the Contracts Register upon standard requests to Clients and/or Reporting Agents; and

- make corrective data entries.

2.4.3.4. The Repository shall perform Repository Operations in the manner and within the time limits set forth hereby.

2.5. Services Provided by the Repository

2.5.1. The Repository shall provide services of keeping the Contracts Register.

2.5.2. The Repository shall provide related services consistent with the requirements of the Russian laws or other regulations that govern repository business. The Repository shall provide related services in the manner, within the time limits, and on the grounds set forth by the Rules for the Provision of Repository’s Related Services.

2.6. Payment for Repository Services

2.6.1. General Provisions

2.6.1.1. Repository Services shall be paid for by Payers in accordance with the Fee Schedule in effect as at the date when the relevant Repository Services are provided. The

16

Repository’s Fee Schedule shall be approved by the Repository Services User Committee following the obtainment by the Repository of a necessary license and establishment of the Repository Services User Committee in accordance with the effective Russian laws and/or Financial Market Regulator’s regulations. Payers for Repository Services shall be either Reporting Agents or Clients themselves in the cases stipulated hereby and/or by the Fee Schedule for Repository Services.

2.6.1.2. The fees set out in the Fee Schedule shall be exclusive of value added tax (VAT) payable on top of the cost of Repository Services in the amount required by the Russian laws.

2.6.1.3. The Repository may, at its own discretion, amend the Fee Schedule by giving notice to Clients and Reporting Agents no later than ten (10) calendar days prior to the effective date of the amended Fee Schedule, by placing the relevant information on the Repository’s official web site at www.nsd.ru. Where the Repository increases any fee set out in the Fee Schedule, the relevant amendments shall take effect ninety (90) calendar days of their posting on the Repository’s official web site.

2.6.1.4. Payers for Repository Services shall be determined as follows:

The service entitled “Recordkeeping of registered Contracts in the Contracts Register" shall be paid for by the relevant Reporting Agent as at the end of the reporting period.

Where a Payer designated in a Contract Reporting Form is the same for both parties, the fee shall be charged to the Payer only once.

Where the parties have designated different Payers in a Contract Reporting Form, the fee shall be charged to each Payer.

A Payer whose Repository Services Agreement was terminated in a reporting period shall pay for the service entitled “Recordkeeping of registered Contracts in the Contracts Register" with respect to those Contracts that were terminated on or before the termination date of the Repository Services Agreement.

Services, other than those connected with the collection, recording, processing, safekeeping, and recordkeeping of information on Contracts, shall be paid for by a Client who has submitted the relevant request, notification, or application in the manner stipulated by the Repository.

In all other cases provided for hereby, the Payer shall be a Reporting Agent who is then authorized to report information on each particular document submitted to the Repository.

2.6.1.5. Changes to the list of Repository Services payable by a Payer, or a change-over to a new Fee Schedule shall take effect on the first day of the month next to the month when the relevant document giving rise to such change was submitted (such as a Reporting Refusal Notification (Form CM012 in Appendix 1 hereto), Declaration of accession to the fee schedule or a Document Cancellation Notification (Form CM013 in Appendix 1 hereto)).

2.6.1.6. The Repository shall issue a bill for the Repository Services to be paid for, a Statement of Services, and an invoice (collectively, “billing documents”) in the cases required by the Russian laws. Billing documents shall be issued to the relevant Payer and submitted in

17

electronic format in accordance with the specifications and in the manner required by the EDI Agreement, subject to the applicable terms and conditions hereof.

2.6.1.7. Payment for the Repository services order may be changed under agreement with a Client.

2.6.1.8. Where a Client needs to change an Identification Code to which billing documents in electronic format are to be sent via EDI channels, the Client shall submit the relevant request to the Repository. A request template is posted on the Repository’s official web site at www.nsd.ru.

2.6.1.9. Billing documents shall be sent in electronic format to the indicated Identification Code starting from the month immediately next to the month when the request for sending billing documents to such Identification Code was submitted, provided that the valid EDI Details Form is linked to such Identification Code in the Repository’s recordkeeping systems.

2.6.2. Billing Process and Payment for Services

2.6.2.1. The Repository shall, no later than the fifth business day of the month immediately next to the billing month, issue to Payers billing documents for the Repository Services provided during the billing month. Billing documents shall be sent in electronic format to Payers. Billing documents in hard copies shall be sent to the mailing address specified in the Payer’s details form. Any Payer may receive billing documents in hard copy at the Repository’s office through a mailbox.

2.6.2.2. A Payer shall receive billing documents and pay the relevant amount for the Repository Services no later than the last day of the month immediately next to the billing month, using the bank account details specified in the bill.

2.6.2.3. In the event of a failure to comply with the terms and conditions hereof regarding the payment for Repository Services, the Repository may charge a late fee of one per cent (1%) of the overdue amount (inclusive of VAT) for each day of delay, but in any event no more than ten per cent (10%) of such amount.

2.6.2.4. Where the Repository identifies any mistake in billing documents for any previous billing period, the Repository may make corrective entries in billing documents for the current period and provide relevant explanations upon approval by the Payer in writing or oral.

2.6.2.5. Where a Payer fails to pay a bill within the time limits set out in clause 2.6.2.2 above, the Repository may suspend the provision of Repository Services to the Client hereunder until the bill has been paid.

2.6.2.6. Where a Payer violates the payment schedule set in the clause 2.6.2.2 for a period exceeding 2 (two) month, the Repository has a right to terminate the Repository Services Agreement without complying with the clauses 2.9.1 and 2.9.4.

18

2.7. Responsibility and Liability of the Repository and Clients

2.7.1. Responsibility and Liability of the Repository

2.7.1.1. The Repository shall be liable to a Client for non-performance or improper performance of Repository’s obligations under the Repository Services Agreement and/or these Rules. In particular the Repository, shall be:

- responsible for preservation of documents or messages received, and data entries made by the Repository in accordance herewith, as well as for ensuring integrity of data recorded in the Contracts Register;

- liable for corruption of documents or messages received, making erroneous data entries in the Contracts Register, and responsible for protection of information against unauthorized access;

- responsible for security of the electronic signature throughout the retention period applicable to the relevant information or documents in accordance herewith; and

- responsible for ensuring timely performance of its obligations under the Repository Services Agreement.

2.7.1.2. Where the Repository identifies any erroneous data entries in the Contracts Register, the relevant Client acknowledges and agrees that the Repository may make corrective data entries by providing relevant reports to the Client’s Reporting Agent in the manner set forth hereby.

2.7.2. Responsibility of a Client

A Client shall be responsible for ensuring:

- accuracy and timeliness of information reported by a Reporting Agent to the Repository; and

- accuracy and timeliness of payment for services provided by the Repository.

2.7.3. Liability of the Parties

2.7.3.1. A Client and the Repository (collectively, the “Parties”) shall be held liable in accordance with the applicable Russian laws for failure to perform or improper performance of their respective obligations under the Repository Services Agreement and/or these Rules.

2.7.3.2. The Repository shall not be liable to the Client if any information on Contracts has been received by the Repository after the deadlines set out herein, resulting in the information on such Contracts not being factored in for the purpose of calculating net obligations upon termination or discharge of obligations under the Contracts due to the initiation of bankruptcy proceedings. The Repository also shall not be liable to the Client if information on any Contract, which is to be reconciled with information received from the other party’s Reporting Agent, has not been entered in the Contracts Register due to the impossibility to make such reconciliation in the manner set forth hereby.

2.7.3.3. The Repository shall be liable to compensate losses sustained by the Client as a result of the Repository failing to perform or improperly performing its obligations under the Repository Services Agreement and/or these Rules, such compensation being equal to the amount paid for the Repository Services provided to the Client over the year preceding the date

19

of incurrence of such losses, unless the Repository proves that such losses have been caused by a force majeure event or through the fault of the Client or his Reporting Agent.

2.7.3.4. The Parties shall be released from liability for failure to perform, whether in full or in part, their respective obligations under the Repository Services Agreement, provided that such failure has been caused by a force majeure event occurring after the date of the Repository Services Agreement or by an emergency that the Parties could neither foresee, nor prevent.

2.7.3.5. Should a force majeure event occur, the period of time during which the Parties shall perform their respective obligations under the Repository Services Agreement and these Rules shall be extended to cover the period of time during which such force majeure event and its consequences continue.

2.7.3.6. A Party to the Repository Services Agreement who is affected by a force majeure event shall immediately give notice to the other Party of the Repository Services Agreement of the occurrence, scope, nature, and cessation of the force majeure event.

2.7.3.7. Where, in the event of the affected Party’s unreasonable delay in giving notice referred to in clause 2.7.3.6 above, the other Party to the Repository Services Agreement incurs losses, the delaying Party shall indemnify such other Party against such losses. The responsibility to prove existence of a force majeure event shall lie on the Party to the Repository Services Agreement who refers to such force majeure event.

2.7.3.8. Upon cessation of a force majeure event, the Parties to the Repository Services Agreement shall make every reasonable effort to mitigate its consequences and resulting damages.

2.7.3.9. Should a force majeure event continue for more than two (2) months, either Party to the Repository Services Agreement may terminate the Repository Services Agreement.

2.8. Amendments to the Rules

2.8.1. The Repository may, at its own discretion, amend these Rules or Appendices hereto.

2.8.2. Where any amendment is made hereto, the Repository shall, upon registration by the Bank of Russia of such amendment and no later than ten (10) calendar days prior to the effective date of the amended and restated Rules, give notice of such amendment to Clients/Reporting Agents by posting the relevant information on the Repository’s official web site at www.nsd.ru.

2.8.3. All general notifications applicable to all Clients/Reporting Agents and relating to amendments to the Repository Services Agreement or Appendices thereto, or these Rules or Appendices hereto, or explanations regarding the procedure for filling in document forms, shall be posted on the Repository’s official web site at www.nsd.ru. A notification shall be deemed to have been made on the date when the relevant information is posted on the Repository’s official web site. The Repository shall be responsible for ensuring that any such information is so posted in a timely fashion. Clients and Reporting Agents shall be solely responsible for monitoring relevant notifications posted on the Repository’s official web site. Clients and/or Reporting Agents shall be responsible for getting acquainted with such information in a timely fashion. Where a Client and/or a Reporting Agent is not able to view and receive any information posted on the Repository’s official web site, such Client and/or Reporting Agent shall apply to the Repository in any manner available to the Client and/or Reporting Agent and get such

20

application registered for the purpose of receiving necessary information. In this case, the relevant information may be delivered to the Client and/or Reporting Agent within three (3) business days of the application registration date either by mail, or by fax, or by e-mail, or using special communication channels. In this case, the delivery of such information shall be made at the Client's/Reporting Agent’s cost.

2.8.4. Where an amendment made hereto that governs the procedure for keeping the Contracts Register is made to reflect the relevant amendments made to the Russian laws or Financial Market Regulator’s regulations or regulations of any other Russian governmental authority, such amendment shall take effect on the effective date of the relevant amendments to such laws and/or regulations, unless different timing is set out therein.

2.9. Termination of the Repository Services Agreement

2.9.1. The Repository Services Agreement may be terminated by either Party thereto on any ground provided for hereby or by Russian laws, provided that obligations under all Contracts entered in the Contracts Register have been terminated or discharged. Provisions of this clause do not apply to the cases when the agreement is terminated by the Repository in accordance with the clause 2.6.2.6 of the Rules.

2.9.2. The Repository Services Agreement shall be terminated by signing and delivering a notice of termination in the form of an official hard-copy letter signed by an authorized representative of the Party giving such notice of termination. A Client who, in accordance with the effective Russian laws, is not obliged to report information to the Repository may terminate the Repository Services Agreement in accordance with the relevant section hereof (Procedures to be followed by a Client not obliged to report information to the Repository and who is willing to terminate the Repository Services Agreement).

2.9.3. The Repository shall discontinue making data entries in the Contracts Register with respect to Master Agreements/Contracts information on which is received from the Client’s Reporting Agent on or after the date when the Repository Services Agreement with the Client is deemed to have been terminated.

2.9.4. The Repository Services Agreement shall be deemed to have been terminated no later than thirty (30) calendar days of the date of the notice of termination, provided that obligations under all of the Client’s Contracts entered in the Contracts Register have been terminated or discharged. Provisions of this clause do not apply to the cases when the agreement is terminated by the Repository in accordance with the clause 2.6.2.6 of the Rules.

2.9.5. The Repository Services Agreement shall terminate in the event of liquidation of the Client.

2.9.6. Where the Repository Services Agreement is terminated, the Client shall pay for all Repository Services provided by the Repository before the termination date. Termination of the Repository Services Agreement shall not release the Parties thereto from their respective obligations that arose before the termination date.

2.9.7. Termination of the Repository Services Agreement other than as a result of a breach of any terms and conditions set out herein shall not be treated by either Party as a violation of its

21

rights and legitimate interests. Neither Party shall claim that the other Party pay any possible damages that can be caused by such termination of the Repository Services Agreement.

2.9.8. Upon termination of the Repository Services Agreement, and provided that the Repository Services have been paid for, the Client may request that information from the Contracts Register be provided to any other person providing repository services, provided that the other Party to the relevant Master Agreement/Contract who is a Repository's Client gives his consent in writing. The terms and conditions of handover of the Contracts Register, payment, and other terms and conditions shall be set out in a supplemental agreement to be entered into between the Repository and the Client.

3. DOCUMENTS TO BE SUBMITTED TO THE REPOSITORY FOR THE PURPOSE OF IDENTIFICATION OF PARTICIPANTS

3.1. Upon entering into the Repository Services Agreement, a Client shall submit to the Repository documents listed in the list of documents approved by the Repository and posted on the Repository’s official web site at www.nsd.ru. In addition, upon entering into the Repository Services Agreement, the Client shall provide the LEI assigned to the Client (or confirmed on the date of its provision).

3.2. A Client shall notify the Repository, in a timely fashion, of any and all changes in any document submitted to the Repository for the purpose of the Client identification, and submit to the Repository documents evidencing such changes. Where a Client fails to notify the Repository of any changes in any document or provides incomplete or inaccurate information on any changes in any document, the Repository shall not be liable for any resulting losses that may be incurred by the Client.

3.3. Where a Client has already submitted any of the above documents to the Repository, the Client shall not be required to re-submit such documents.

3.4. A Client shall submit to the Repository powers of attorney issued in the name of any individual authorized to act on behalf of the Client in connection with submission of a set of documents required to enter into a Repository Services Agreement, as well as in connection with submission or receipt of any other hard-copy documents provided for hereby.

3.5. Where the Client revokes the appointment of any authorised representative, the Client shall revoke his/her power of attorney and issue a new power of attorney in the name of the replacement authorized representative. Until the date when such new power of attorney is received, documents shall be accepted from / provided to the Client’s authorized representative whose power of attorney is kept on file with the Repository.

3.6. Upon submitting any document or information provided for hereby to the Repository, a Client shall ensure the obtainment of personal data subjects’ consent to the processing and use of their respective personal data.

3.7. A new Client shall be registered no later than two business days following the date of submission by the Client to the Repository of all documents required hereby and execution of the Repository Services Agreement.

22

4. GENERAL DATA INTERCHANGE PROCESS

4.1. A Repository Operation shall be made on the basis of a document signed by a Reporting Agent and/or a Client and submitted to the Repository.

4.2. In accordance herewith, the Repository and Clients/Reporting Agents may interchange data in the form of:

a) documents in hard copy; or

b) documents in electronic format (electronic documents, electronic data interchange).

4.3. Electronic data interchange shall be the principal method of communication between the Repository and Clients/Reporting Agents.

4.4. Electronic documents shall be accepted from or delivered to a Client/Reporting Agent in accordance with the EDI Agreement between the Repository and such Client/Reporting Agent and these Rules.

4.5. The Repository Services Agreement may be signed by a Client and delivered to the Repository, and documents in hard copy may be accepted from / delivered to such Client, either at the Repository’s office or at the office of a Repository’s regional agent. Documents shall be accepted/delivered on the basis of the relevant power of attorney issued in the name of a Client’s authorized representative.

4.6. A Repository Operation initiated by the Repository shall be executed on the basis of an Internal Instruction signed by Repository’s authorized officers. The Repository shall execute a Repository Operation on the basis of an Internal Instruction where such Repository Operation has to be made in accordance with the requirements of the effective Russian laws and/or the terms and conditions of the Repository Services Agreement.

4.7. The list of documents to be submitted to the Repository by Clients or Reporting Agents for the purpose of execution of particular Repository Operations, guidelines for completing such documents, and the list of reports to be provided by the Repository to Clients/Reporting Agents upon completion of Repository Operations are set out in the Appendices hereto. The Repository may request that a Client/Reporting Agent submit any other documents and/or information, and impose additional requirements as to the form of documents to be submitted (such as notarization requirement, etc.). The data fields in a document submitted in hard copy shall be the same as the data fields in a document issued using the Repository Software. Formats (specifications) of electronic documents are set out in Appendix 3 to the EDI Rules and posted on the web site at repository.nsd.ru/en (NSD’s Trade Repository Messages Specifications). The terms and conditions of using the SWIFT System for data interchange are set out in Section 7 hereof.

4.8. Timing of Repository Operations Execution

4.8.1. The time of any and all actions governed hereby shall be Moscow time.

4.8.2. Time limits set out herein shall be in calendar days, unless otherwise specifically stipulated.

4.8.3. Where a document in hard copy is received before 5.00 pm on a business day of the Repository, Repository Operations to which such document relates shall be executed on the same

23

business day of the Repository. A document in hard copy received by the Repository after 5.00 pm on a business day can be executed on the immediately next business day.

4.8.4. The times of acceptance of electronic documents from Reporting Agents or Clients for execution of certain Repository Operations, the times of delivery of reports, and the time restrictions applicable to the execution are set out in the provisions hereof, as relating to the execution of the relevant Repository Operation.

4.8.5. Documents in hard copy shall be provided to the Repository by a Client’s/Reporting Agent’s authorized representative in two originals.

4.8.6. Following the registration of any such document with the Repository, the second original of such hard-copy document marked with the acceptance date by the Repository shall be returned to the Client’s/Reporting Agent’s authorized representative.

4.8.7. The Repository shall execute Repository Operation at times (either on a date or within a period of time) set out herein.

4.8.8. In these Rules, day “T” shall mean the date when the relevant document is registered with the Repository.

4.8.9. Where a Repository Operation is to be executed within a particular period of time, the Repository may execute (or, for certain Repository Operations, proceed to the execution of) such Repository Operation on one of the days covered by such period, following the occurrence of an event triggering its execution.

4.8.10. Information on beginning and end of Business hours is disclosed on the Repository’s website.

4.9. Refusal to Accept Documents and Make Data Entries in the Contracts Register

4.9.1. The Repository shall refuse to accept a document if:

- the document is completed inaccurately (in particular, if the document is not in the form required, or its data fields are different from the ones that are required, or any mandatory data fields are not completed, or any completed data fields do not match the reference values), or the document submitted in hard copy contains any alterations, corrections, or the like;

- the signature put on the document is different from the specimen signature kept by the Repository on file, or there are significant and reasonable doubts as to the authenticity of the signature on the document (if the document is submitted in hard copy);

- the seal impression on the document is different from the specimen seal impression kept by the Repository on file (if the document is submitted in hard copy);

- the procedure for electronic signature verification and document format and specification control has failed for the document received in electronic format, and/or the text of such document is corrupted so that the meaning of the document cannot be understood, as well as in other cases set out in the EDI Agreement between the Repository and the Client/Reporting Agent. For the purposes hereof, "electronic signature” shall have the same meaning as set out in the EDI Agreement;

24

- the validity period of the authority (the power of attorney issued in the name of) the Client's/Reporting Agent’s authorized representative signing the document has expired, and/or the power of attorney is issued improperly;

- the document is not accompanied by all other documents (their copies) where such documents are required by the Russian laws and/or these Rules for execution of the relevant Repository Operation, or information contained in such other documents is inconsistent with any information contained in the principal document;

- the document is submitted to the Repository other than in accordance with the requirements set forth hereby;

- any details contained in the document initiating a Repository Operation does not match the Client’s/Reporting Agent's details kept by the Repository on file in accordance herewith, or does not match the details of other Clients or Reporting Agents as contained in the document; or

- the operation specified in the document is not provided for hereby, or the terms and conditions of the execution of the Repository Operation specified in the document, as set out in the Repository Services Agreement and these Rules, have not been complied with.

The Repository shall refuse to make a data entry in the Contracts Register (Section 2) if:

- there is no matching document available from the other Reporting Agent/Client, as may be required to execute the relevant Repository Operation (where the bilateral confirmation process is applicable to such document);

- the details in the document do not match the details contained in the matching document from the other Reporting Agent/Client, which are to be reconciled (where the bilateral confirmation process is applicable to such document);

- the Reporting Agent’s/Client’s message contains information on a Contract made under a Master Agreement, where the information on such Master Agreement is neither entered in the Contracts Register (Section 2), nor reported concurrently with the reporting of information on the Contract (by the end of the Repository’s Business Hours);

- the Reporting Agent’s/Client’s message is signed by a person who is not an authorized signatory;

- the information on the Contract, as contained in the Reporting Agent’s/Client’s message, has already been entered in the Contracts Register (Section 2);

- the message is received from a person who is neither a party to the Contract, nor designated as a Reporting Agent;

- the Reporting Agent’s message is issued other than in accordance with the requirements set forth hereby;

- the message does not include the LEI(s) of a party (the parties) to the Contract who is (are) obliged to report information to the Contracts Register in accordance with the effective Russian laws, and the LEI(s) of the Reporting Agent(s) where the information is actually reported by the Reporting Agent;

- the message does not include the UTI of the Contract/Master Agreement;

- the purpose of the message is to change the UTI of the Contract/Master Agreement;25

- the message contains an UTI of the Contract/Master Agreement, which is contained in a data entry earlier made in Section 2 of the Contracts Register, unless the purpose of the message containing such UTI of the Contract/Master Agreement is to change any information on the Contract/Master Agreement, the data entry regarding which has already been made in Section 2 of the Contracts Register; or

- the purpose of the message is to change the Identification Code (Repository Code) of a party in the Master Agreement Reporting Form / Contract Reporting Form registered in Section 2 of the Contracts Register (unless the purpose is to replace the value "NONREF" (where the party was not a Repository's Client as at the Reporting Form registration date) by the valid Identification Code (Repository Code) (where the party is a Repository’s Client as at the time when the requested changes are to be made).

4.9.2. Where a document submitted in hard copy is not accepted for execution, the document shall be returned with the reason of the refusal to accept it to be stated. Where a document submitted in electronic format is not accepted for execution in accordance wit the EDI Agreement and/or Section 7 hereof, the Client shall be given a Notification of Non-Acceptance of an Electronic Document for Execution stating the reason of non-acceptance. Where a Repository Operation is not executed, the Repository shall give to the Reporting Agent/Client a Registration/Execution Rejection Advice stating the reason of non-execution. Where necessary, the reasons of non-acceptance of a document for execution or of non-execution of a Repository Operation, as stipulated herein, can be explained to the Reporting Agent/Client in more detail in a report delivered to the Reporting Agent/Client. In such cases, the Repository shall be deemed to have performed its obligations with respect to such Repository Operation. Upon taking measures to remedy the situation due to which the execution of the Repository Operation was rejected, the Reporting Agent/Client shall submit to the Repository a new document initiating such Repository Operation.

4.10. Delivery of Reports Following the Execution of Repository Operations

4.10.1. The time limits within which Repository Operations shall be executed are set out in the section hereof entitled “Timing of Repository Operations Execution”, as well as in the description of particular Repository Operations. Reports in hard copy shall be delivered to a Reporting Agent/Client at the Repository’s office on the business day immediately next to the date of the Repository Operation execution. When preparing reports listed in Appendix 1 hereto and delivered to Reporting Agents/Clients in hard copy, it shall be allowed to use a facsimile signature of a Repository’s authorized officer. A Client/Reporting Agent who has an EDI Agreement with the Repository shall be provided with reports in electronic format no later than the business day immediately next to the date of the Repository Operation execution by the Repository. Where it becomes impossible to deliver a report in electronic format following the execution of a Repository Operation, the Repository may deliver a report in hard copy in the manner and within the time limits set forth for the delivery of reports in hard copy.

4.10.2. The time within which a Repository Operation shall be executed shall start running on the date when all the documents required to execute the Repository Operation are submitted to the Repository.

4.10.3. Reports in hard copy intended to be delivered to a Reporting Agent/Client shall be retained by the Repository for at least six months of the date of their issuance by the Repository

26

in accordance herewith. To receive an Excerpt from the Contracts Register in hard copy after the expiry of the six-month period, a Reporting Agent/Client shall submit to the Repository a Request for an Excerpt from the Contracts Register (Form CM004 in Appendix 1 hereto), stating a reporting date (period). To receive any other report (Registration Advice or Execution/Registration Rejection Advice) in hard copy after the expiry of the six-month period, a Reporting Agent/Client shall submit to the Repository a request for documents in hard copy (in the form of an official letter).

4.10.4. A Reporting Agent’s/Client’s complaint (objections) with respect to a Repository Operation completed shall be submitted within three business days of the date when the Repository’s report on such Repository Operation is delivered.

4.10.5. Time limits for the delivery of reports requested with respect to periods/dates in the previous quarter or earlier may differ from the general time limits set out herein, but may not exceed “T+5” (five business days of the receipt of the relevant request).

4.10.6. A report in hard copy issued following the Repository Operation completed during the Business Hours shall be delivered to the Client/Reporting Agent on the next business day, during the period of 9.30 am to 5.00 pm. When preparing reports listed in Appendix 1 hereto and delivered to Clients/Reporting Agents in hard copy, it shall be allowed to use a facsimile signature of a Repository’s authorized officer.

4.10.7. For a Reporting Agent who uses electronic data interchange, reports in electronic format issued following the execution of a Repository Operation shall be made available as soon as the Repository Operation is executed, and an Excerpt from the Contracts Register regarding Contracts registered during the day shall be made available after the Business Hours.

4.10.8. The electronic data interchange procedure to be used for communications between the Repository and Reporting Agents/Clients is described in Section 7 hereof, as well as in agreements that set out terms and conditions of electronic data interchange between the Repository and Participants.

4.10.9. The list of Repository’s reports that can be issued following the execution of Repository Operations is set out in Appendix 1 hereto.

4.11. Receipt by a Client of Repository’s Reports on an Electronic Medium

4.11.1. Where a Reporting Agent/Client needs to receive a Repository’s report on an electronic medium, such report shall be delivered at the Repository’s office on an electronic medium provided by the Repository on the basis of a Reporting Agent’s/Client’s hard copy request for a report (Form CM005 in Appendix 1 hereto), Reporting Agent’s/Client’s request for a report, as submitted earlier in hard copy or electronic format (Form CM004 in Appendix 1 hereto), a power of attorney issued in the name of a Reporting Agent’s/Client’s authorized representative, and the passport of such Reporting Agent’s/Client’s authorized representative.

4.11.2. Where a Repository delivers a report on an electronic medium, a Report Handover Certificate (Form RM008 in Appendix 1 hereto) shall be drawn up. Such certificate shall be drawn up in two originals, signed and certified by a Repository’s authorized officer and a Reporting Agent’s/Client’s authorized representative. One original certificate shall be retained by the Repository, and the second one, stating its date, shall be delivered to the Reporting Agent’s/Client’s authorized representative.

27

4.11.3. Payment for a report delivered on an electronic medium shall be made in accordance with the effective Fee Schedule.

5. METHODS OF MAKING DATA ENTRIES IN THE CONTRACTS REGISTER

A unilateral entry of information in the Contracts Register shall mean the service of making data entries in the Contracts Register on the basis of a message sent to the Repository by a single Reporting Agent appointed either by both parties to a Master Agreement/Contract, or by one party to a Master Agreement/Contract where one of the parties to the Contract is a person not obliged to report information to the Repository and is not a Repository’s Client, or is a Repository’s Client who has submitted a Reporting Refusal Notification (Form CM012 in Appendix 1 hereto) and has not appointed a Reporting Agent.

A bilateral entry of information in the Contracts Register with a consecutive confirmation shall mean the service of making data entries in the Contracts Register where a message received from a Reporting Agent of one party to a Master Agreement/Contract is sent by the Repository for confirmation to a Reporting Agent of the second party to the Master Agreement/Contract, and upon receipt of a confirmation message from the Reporting Agent of the second party to the Master Agreement/Contract such confirmation message is reconciled by the Repository with the initial message (consecutive confirmation method).

A bilateral entry of information in the Contracts Register with a matching confirmation shall mean the service of making data entries in the Contracts Register where the Repository, with respect to a message received from a Reporting Agent of one party to a Master Agreement/Contract, searches for a matching message received from a Reporting Agent of the second party to the Master Agreement/Contract, and then reconciles the data fields in such matching messages (matching confirmation method).

A bilateral entry of information in the Contracts Register with a combined confirmation shall mean the service of making data entries in the Contracts Register where the Repository first uses the matching confirmation method and then, if such method returns no result (i.e., if there are no matching reporting forms available at the Repository), the Repository uses the consecutive confirmation method for reporting forms.

5.1. Bilateral Entry of Information in the Contracts Register

5.1.1. Bilateral entry of information in the Contracts Register shall be made if both parties to a Master Agreement/Contract are Repository’s Clients and have different Reporting Agents.

5.1.2. Bilateral entry of information in the Contracts Register shall be made using either the consecutive confirmation method, or the combined confirmation method, or the matching confirmation method.

5.1.3. Master Agreement Reporting Forms shall be entered in the Contracts Register by bilateral entry of information using the consecutive confirmation method only.

5.1.4. Contract Reporting Forms shall be entered in the Contracts Register by bilateral entry of information using either the combined confirmation method (the principal method), or the matching confirmation method. A Client shall, at his own discretion, choose a Contract confirmation method in the “confirmationMethod” field.

28

5.1.5. Reconciliation Process

5.1.5.1. A reconciliation process with respect to Master Agreement Reporting Forms shall be performed for ‘full reconciliation’ fields only. A reconciliation process with respect to Contract Reporting Forms shall be performed either for ‘general fields', or for ‘full reconciliation’ fields. A Client shall, at his own discretion, choose a Contract reconciliation type in the “reconciliation Type” field.

5.1.5.2. Where a Client chooses the ‘full reconciliation’, the Repository shall perform a reconciliation for all data fields (mandatory reconciliation fields, additional reconciliation fields, special reconciliation fields, and special additional reconciliation fields) in a message. Where no discrepancies are discovered, the reconciliation process shall be deemed successful. Where the reconciliation process discovers any discrepancies, the Repository shall send a Notification of Reporting Form Discrepancies (Form RM006 in Appendix 1 hereto) to the Reporting Agents.

5.1.5.3. Where a Client chooses the ‘general field reconciliation’, the Repository shall perform a reconciliation for the mandatory reconciliation fields and special reconciliation fields in a message. Where no discrepancies are discovered in such fields, the reconciliation process shall be deemed successful. Where the reconciliation process discovers any discrepancies, the Repository shall send a Notification of Reporting Form Discrepancies (Form RM006 in Appendix 1 hereto) to the Reporting Agents.

5.1.6. Consecutive Confirmation Process 5.1.6.1. Where the Repository receives a message in electronic format containing information on a Contract/Master Agreement, the Repository shall send an acknowledgment of receipt issued in accordance with the EDI Agreement to the Reporting Agent who has sent such message to the Repository.

5.1.6.2. In the course of the message processing, the Repository shall check the message for uniqueness, accuracy and completeness, and availability of authority to report information, and, if any errors are discovered, the Repository shall send a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) to the Reporting Agent who has sent such message to the Repository.

5.1.6.3. Where the message is found correct, the Repository shall send to the relevant Reporting Agent a Reporting Form Status Advice (Form RM003 in Appendix 1 hereto) to inform that the message has been entered in Section 1 of the Contracts Register (the Messages Log). In this case, the message received from the first party’s Reporting Agent shall be assigned the ‘pending’ status, and the Repository shall perform the consecutive confirmation process.

5.1.6.4. For this purpose, the Repository shall issue and send to the second party’s Reporting Agent a Confirmation Request (Form RM005 in Appendix 1 hereto) and, at the same time, send to the first party’s Reporting Agent a Reporting Form Status Advice (Form RM003 in Appendix 1 hereto) to inform that a Confirmation Request has been sent to the counterparty (second party’s Reporting Agent).

29

5.1.6.5. To confirm the message, the second party’s Reporting Agent shall send to the Repository a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto).

5.1.6.6. Upon receipt of a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto) from the second party’s Reporting Agent, the Repository shall perform a reconciliation of the messages (the message received from the first party’s Reporting Agent and the Confirmation Agreed Notification received from the second party’s Reporting Agent).

5.1.6.7. Should the reconciliation process be successful, the Repository shall enter the matching information contained in the messages in the Contracts Register (Section 2) and send a Registration Advice (Form RM001 in Appendix 1 hereto) to the Reporting Agents.

5.1.6.8. Should the reconciliation process fail, the Repository shall issue a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) and send it to the Reporting Agent who has submitted to the Repository the Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto); however, the original Reporting Form shall retain the ‘pending’ status. Upon receipt of the Advice (Form RM002 in Appendix 1 hereto), the second party’s Reporting Agent may correct the Confirmation Agreed Notification and re-submit it to the Repository. Further processing of the Confirmation Agreed Notification received shall be made in accordance with clauses 5.1.6.6 – 5.1.6.7 hereof.

5.1.6.9. Where the second party’s Reporting Agent submits a Disagreement Notification (Form CM002 in Appendix 1 hereto), the Repository shall send a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) to the Reporting Agents.

5.1.6.10. Where the Repository does not receive a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto) from the second party’s Reporting Agent within thirty (30) calendar days or receives a Disagreement Notification (Form CM002 in Appendix 1 hereto) from the second party’s Reporting Agent , the relevant message shall be cancelled, the relevant data entry confirming such cancellation shall be made in Section 1 of the Contracts Register (the Messages Log), and the Reporting Agents shall be sent a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto).

5.1.7. Matching Confirmation Process 5.1.7.1. Where the Repository receives a message in electronic format containing information on a Contract/Master Agreement, the Repository shall send an acknowledgment of receipt issued in accordance with the EDI Agreement to the Reporting Agent who has sent such message to the Repository.


5.1.7.3. Where the message is found correct, the Repository shall send to the relevant Reporting Agent a Reporting Form Status Advice (Form RM003 in Appendix 1 hereto) to inform that the message has been entered in Section 1 of the Contracts Register (the Messages

30

Log). In this case, the message received from the first party’s Reporting Agent shall be assigned the ‘pending’ status, and the Repository shall search for a matching message.

5.1.7.4. For this purpose, the Repository shall check whether a message containing information on the Contract/Master Agreement, as received from the other party’s Reporting Agent, is available in the system. A matching message shall be searched for in accordance with the “Procedure for Determination of Uniqueness of Messages to Be Registered and Search for Matching Reporting Forms for the Purpose of Messages Matching”. Where the necessary parameters in the message received from the first party's Reporting Agent and in the found message received from the second party's Reporting Agent match, such messages shall be treated as matching messages, and the Repository shall start the messages reconciliation process.

5.1.7.5. Should the reconciliation process be successful, the Repository shall enter the matching information contained in both messages in the Contracts Register (Section 2) and send a Registration Advice (Form RM001 in Appendix 1 hereto) to the Reporting Agents.

5.1.7.6. Should the reconciliation process fail, the Repository shall issue a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) and send it to the Reporting Agents.

5.1.7.7. Where the search for a matching message returns no result, or where the Repository does not receive a matching message from the second party’s Reporting Agent within 30 (thirty) calendar days, the message received from the first party’s Reporting Agent shall be cancelled, the relevant data entry confirming such cancellation shall be made in Section 1 of the Contracts Register (the Messages Log), and the first party’s Reporting Agent shall be sent a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto).

5.1.8. Combined Confirmation of Reporting Forms 5.1.8.1. Where the Repository receives a message in electronic format containing information on a Contract/Master Agreement, the Repository shall send an acknowledgment of receipt issued in accordance with the EDI Agreement to the Reporting Agent who has sent such message to the Repository.


5.1.8.3. Where the message is found correct, the Repository shall send to the relevant Reporting Agent a Reporting Form Status Advice (Form RM003 in Appendix 1 hereto) to inform that the message has been entered in Section 1 of the Contracts Register (the Messages Log). In this case, the message received from the first party’s Reporting Agent shall be assigned the ‘pending’ status, and the Repository shall perform the combined confirmation process.

5.1.8.4. For this purpose, the Repository shall check whether a message containing information on the Contract/Master Agreement, as received from the other party’s Reporting Agent, is available in the system. A matching message shall be searched for in accordance with

31

the “Procedure for Determination of Uniqueness of Messages to Be Registered and Search for Matching Reporting Forms for the Purpose of Messages Matching”. Where the necessary parameters in the message received from the first party's Reporting Agent and in the found message received from the second party's Reporting Agent match, such messages shall be treated as matching messages, and the Repository shall start the messages reconciliation process.


5.1.8.6. Should the reconciliation process fail, the Repository shall issue a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) and send it to the Reporting Agents.

5.1.8.7. Where the search for a matching message returns no result, the Repository shall perform the consecutive confirmation process.

5.1.8.8. For this purpose, the Repository shall issue and send to the second party’s Reporting Agent a Confirmation Request (Form RM005 in Appendix 1 hereto) and, at the same time, send to the first party’s Reporting Agent a Reporting Form Status Advice (Form RM003 in Appendix 1 hereto) to inform that a Confirmation Request has been sent to the second party’s Reporting Agent.

5.1.8.9. To confirm the message, the second party’s Reporting Agent shall send to the Repository a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto).

5.1.8.10. Upon receipt of a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto) from the second party’s Reporting Agent, the Repository shall perform a reconciliation of the messages (the message received from the first party’s Reporting Agent and the Confirmation Agreed Notification received from the second party’s Reporting Agent).


5.1.8.12. Should the reconciliation process fail, the Repository shall issue a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) and send it to the Reporting Agent who has submitted to the Repository the Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto); however, the original Reporting Form shall retain the ‘pending’ status. Upon receipt of the Registration/Execution Rejection Advice, the second party’s Reporting Agent may correct the Confirmation Agreed Notification and re-submit it to the Repository. Further processing of the Confirmation Agreed Notification received shall be made in accordance with clauses 5.1.6.6 – 5.1.6.7 hereof.

5.1.8.13. Where the second party’s Reporting Agent submits a Disagreement Notification (Form CM002 in Appendix 1 hereto), the Repository shall send a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) to the Reporting Agents.

32

Where the Repository does not receive a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto) from the second party’s Reporting Agent within thirty (30) calendar days or receives or receives a Disagreement Notification (Form CM002 in Appendix 1 hereto) from the second party’s Reporting Agent, the relevant data entry confirming cancellation of the message shall be made in Section 1 of the Contracts Register (the Messages Log), and the Reporting Agents shall be sent a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto).

5.2. Unilateral Entry of Information in the Contracts Register

5.2.1. Unilateral entry of information in the Contracts Register shall be made if:

5.2.1.1. one of the parties to a Master Agreement/Contract is not a Repository’s Client or has refused to report information to the Repository; or

5.2.1.2. both parties to a Master Agreement/Contract are Repository’s Clients and have the same Reporting Agent.

5.2.2. Where the Repository receives a message in electronic format containing information on a Contract/Master Agreement, the Repository shall send an acknowledgment of receipt issued in accordance with the EDI Agreement to the Reporting Agent who has sent such message to the Repository.

5.2.3. In the course of the message processing, the Repository shall check the message for uniqueness, accuracy and completeness, and availability of authority to report information, and, if any errors are discovered, the Repository shall send a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) to the Reporting Agent who has sent such message to the Repository.

5.2.4. Where the message is found correct, the Repository shall send to the relevant Reporting Agent a Reporting Form Status Advice (Form RM003 in Appendix 1 hereto) to inform that the message has been entered in Section 1 of the Contracts Register (the Messages Log), enter information on the Master Agreement/Contract to the Contracts Register (Section 2), and send a Registration Advice (Form RM001 in Appendix 1 hereto) to the Reporting Agent.

5.2.5. Procedures to be followed by a Client where the second party to a Master Agreement/Contract is a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to provide information to the Contracts Register

5.2.5.1. Where one of the parties to a Master Agreement/Contract is a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to report information to the Repository, information to the Contracts Register shall be unilaterally entered by a Reporting Agent of the Client being the second party to the Master Agreement/Contract.

5.2.5.2. Where a Client has reported information on a Contract/Master Agreement, his counterparty being a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to report information to the Repository shall be identified by indicating the Repository Code of the Client not obliged to report information to the Repository, pursuant to the Participants Reference Guide.

33

5.2.6. Procedures to be followed by a Client where the second party to a Master Agreement/Contract is a person who is, in accordance with the effective Russian laws, neither obliged to report information to the Repository, nor is a Repository’s Client

5.2.6.1. Where one of the parties to a Master Agreement/Contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client, information to the Contracts Register shall be unilaterally entered by a Reporting Agent of the Client being the second party to the Master Agreement/Contract.

5.2.6.2. Where a Client has reported information on a Contract/Master Agreement, his counterparty being a person who is neither obliged to report information to the Repository, nor is a Repository’s Client shall be identified by indicating one of the permissible values of identification codes of the party who is neither obliged to report information to the Repository, nor is a Repository’s client, as taken from a reference guide.

6. REPOSITORY OPERATIONS

In accordance with these Rules, the Repository shall make the following Repository Operations:

- Registration of, or making changes to, a Client’s (Reporting Agent’s) details, assignment of an Identification Code;

- Registration of the appointment / revocation of the appointment / resignation of a Reporting Agent;

- Registration of information on a Master Agreement, or on amendments to a Master Agreement, or on termination of a Master Agreement;

- Registration of information on a Contract or amendments to a Contract;

- Registration of information on the status of obligations under a Contract, including termination or discharge of obligations (termination of a Contract);

- Registration of information on credit support transfers;

- Registration of information on mark to market valuation;

- Registration of information on a Credit Support Annex;

- Corrective operations;

- Making corrective entries; and

- Delivery of reports:

Delivery of daily Excerpts from the Contracts Register regarding Master Agreements/Contracts to a Reporting Agent;

Delivery of the Contracts Register to the Financial Market Regulator on a daily basis; and

Provision of information from the Contracts Register upon a Reporting Agent’s / Client’s requests.

34

6.1. Registration of, or Making Changes to, a Participant’s Details

6.1.1. The Repository shall register or change a Participant’s details to reflect in the Repository’s recordkeeping systems the Participant’s information required for the Repository to be able to perform its obligations under the Repository Services Agreement.

6.1.2. The Repository shall register details of each new Participant.

6.1.3. A Client shall be registered on the basis of the executed Repository Services Agreement and a set of documents provided by the Client as per the NSD-approved List of Documents to Be Submitted by a Client. Where the Client has already submitted such documents to NSD, the Client shall not be required to re-submit them.

6.1.4. A Reporting Agent shall be registered in the Repository’s recordkeeping system on the basis of the Repository Services Agreement entered into with the Repository, the Client’s Reporting Agent Appointment Application, the Reporting Agent’s confirmation of its willingness to act as a Reporting Agent for certain type of information and the particular Client’s information (where the Reporting Agent’s functions are performed by a third party or by the second party to the Contract/Master Agreement), an Application for Identification Code Assignment, and a set of documents to be provided by the Client as per the NSD-approved list of documents. Where any such documents have already been submitted to the Repository, it shall not be required to re-submit them

6.1.5. A Participant’s details shall be changed if the Repository receives information evidencing that the Participant’s details recorded in the Repository’s recordkeeping systems have been changed.

6.1.6. The registration of, or making changes to, a Client’s details shall be initiated by the Client. The registration of, or making changes to, a Reporting Agent’s details shall be initiated by the Reporting Agent.

6.1.7. The operation of registration of, or making changes to, a Participant’s details shall be executed by the Repository.

6.1.8. A Participant’s details shall be registered or changed within the standard time limits applicable to Repository Operations.

6.1.9. Where a Participant has any other effective agreements with NSD that govern their relationships not connected with the provision of Repository Services, changes to such Participant’s details shall be made under such other agreements with NSD, with the concurrent introducing of changes to the Participant's details in the Repository's recordkeeping system. In this case, the Participant shall not be required to separately submit any documents for the purpose of making such changes to the Participant’s details.

6.2. Assignment of Identification Codes

6.2.1. To be assigned an Identification Code that will be used by the Repository to identify such Client/Reporting Agent, the Client/Reporting Agent shall undergo the procedure for the assignment of a Participant Identification Code (an “Identification Code”).

6.2.2. A legal entity acting as a Client/Reporting Agent may have (be assigned) more than one Identification Code.

35

6.2.3. Where a Client/Reporting Agent wishes to use as an Identification Code(s) a code(s) earlier assigned to him under any other agreement with NSD, the Client/Reporting Agent shall specify such code(s) upon submission of an Application for Identification Code Assignment (Form CM006 in Appendix 1 hereto).

6.2.4. Where the Client elects to acts as a Reporting Agent himself, it shall be allowed to use any of the Identification Codes assigned to the Client as the Reporting Agent’s Identification Code.

6.2.5. Where a Participant does not have an Identification Code or does not wish to use any of the earlier assigned codes, the Participant shall submit an Application for Identification Code Assignment (Form CM006 in Appendix 1 hereto).

6.2.6. An Application for Identification Code Assignment shall be submitted to the Repository in hard copy only.

6.2.7. Where it is necessary to be assigned more than one Identification Code, it shall be allowed to submit a single Application for Identification Code Assignment.

6.2.8. An Identification Code shall be assigned to a Client/Reporting Agent by the Repository upon registration of such Participant in the Repository’s recordkeeping system and delivered to the Client/Reporting Agent together with a copy of the Application for Identification Code Assignment (bearing a stamp confirming the acceptance of the Application for Registration and the Identification Code(s) assigned) signed by a Repository’s authorized officer.

6.2.9. The purpose of an Identification Code shall be determined by the Repository upon submission by the Client of a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto), in which the Client shall specify the Identification Code(s) and the scope of authority given for each Identification Code.

To change the purpose of an Identification Code earlier assigned by the Repository, the Client shall submit to the Repository a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto) stating the new Identification Codes and the scope of authority given for each Identification Code.

6.2.10. To discontinue using an Identification Code upon making data entries in the Contracts Register for new Master Agreements and Contracts, the Client/Reporting Agent shall submit to NSD an Application for Identification Code Use Discontinuance (Form CM009 in Appendix 1 hereto) with respect to the Client’s/Reporting Agent’s Identification Code.

6.2.11. In documents addressed to the Repository, a Client/Reporting Agent may indicate any of his valid Identification Codes to identify himself as a Client/Reporting Agent, subject to the Reporting Agent Appointment Applications (Form CM016 in Appendix 1 hereto) registered in the Repository’s system.

6.2.12. A Client/Reporting Agent may register in the NSD EDI System, in accordance with the EDI Agreement, for each of his Identification Codes an electronic signature verification key certificate(s) correspondent to such Identification Code and an email address(es) from which electronic messages may be sent to the Repository and to which the Repository may send messages to such Client/Reporting Agent.

36

6.3. Registration of the Appointment / Revocation of the Appointment / Resignation of a Reporting Agent

6.3.1. Registration of the Appointment by a Client of a Reporting Agent

6.3.1.1. For the purposes of communicating with the Repository, a Client shall appoint a Reporting Agent. A Client may act as a Reporting Agent himself with respect to a Master Agreement/Contract to which the Client is a party.

6.3.1.2. A document initiating the appointment of a Reporting Agent shall be a Client’s Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto) stating the scope of authority given to the Reporting Agent. Where a Client himself acts as a Reporting Agent with respect to all Master Agreements/Contracts to which the Client is a party, if a third party or the second party to the Contract/Master Agreement was earlier appointed by the Client to act as a Reporting Agent, the Client shall be required to submit to the Repository a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto) stating the Client’s Identification Code.

6.3.1.3. The operation of Reporting Agent appointment shall be executed by the Repository.

6.3.1.4. Upon receipt of a Client’s Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto) in electronic format, the Repository shall send to such Client an acknowledgment of receipt issued in accordance with the EDI Agreement. Then the Repository shall check the received message for accuracy and completeness and, if any errors are discovered, shall send a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) to such Client. Where the message is found correct, the Repository shall send to such Client a Reporting Form Status Advice (Form RM003 in Appendix 1) to inform that the Reporting Agent Appointment Application has been entered in Section 1 of the Contracts Register (the Messages Log).

6.3.1.5. The Client’s message shall be assigned the ‘pending’ status, and the Repository shall send a Confirmation Request (Form RM005 in Appendix 1 hereto) to each Reporting Agent named in the Reporting Agent Appointment Application with respect to such Reporting Agent’s scope of authority only.

6.3.1.6. A Reporting Agent shall give his consent to act for and on behalf of the Client in accordance with the scope of authority given to such Reporting Agent by submitting a Confirmation Agreed Notification (Form CM001 in Appendix 1 hereto) to the Repository.

6.3.1.7. Upon receipt of a Confirmation Agreed Notification from the Reporting Agent named by the Client in the Reporting Agent Appointment Application, the Repository shall reconcile the details contained in the message received from the Client and those contained in the Confirmation Agreed Notification received from the Reporting Agent, and, provided that no discrepancies are discovered, enter the relevant information in the Repository’s recordkeeping systems, following which the Repository Agent shall be able to deal with the Repository within the scope of the Repository Agent's authority. Should any discrepancies in the messages be discovered, the Repository shall send a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) to the Reporting Agent, and the Reporting Agent may correct the Confirmation Agreed Notification and re-submit it to the Repository.

37

6.3.1.8. Where the Repository does not receive a Confirmation Agreed Notification from the Reporting Agent named by the Client in the Reporting Agent Appointment Application, or where the Reporting Agent named by the Client in the Reporting Agent Appointment Application sends a Disagreement Notification (Form CM002 in Appendix 1 hereto), the Repository shall send a Registration Advice Rejection (Form RM002 in Appendix 1 hereto) to the Client. In this case, the Reporting Agent shall be deemed to have not been appointed by the Client and will not be authorized to report information to the Contracts Register.

6.3.1.9. Where a Client submits a Reporting Agent Appointment Application to the Repository, but the Reporting Agent named by the Client therein does not confirm acceptance of the authority given to the Reporting Agent, such Client shall be deemed to have not appointed a Reporting Agent and shall not be able to act himself as a Reporting Agent with respect to any Master Agreement/Contract to which the Client is a party until the Client submits to the Repository a new Reporting Agent Appointment Application containing the Client’s own details required for him to act as a Reporting Agent.

6.3.2. Registration of the Revocation of the Appointment / Resignation of a Reporting Agent

6.3.2.1. Registration of the Revocation of the Appointment by a Client of a Reporting Agent

6.3.2.1.1. To revoke the appointment of a Reporting Agent, the Client shall submit to the Repository a Reporting Agent Appointment Application (Form CM016 in Appendix 1 hereto) containing the details of a new Reporting Agent and the scope of his authority. Where, upon the revocation of the appointment of a Reporting Agent, the Client elects to act as a Reporting Agent himself, the Client shall include his own details in such Reporting Agent Appointment Application.

6.3.2.1.2. As soon as the details of the newly appointed Reporting Agent are entered in the Repository’s recordkeeping systems and the Reporting Agent confirms acceptance of the authority given to him, the appointment of the previous Reporting Agent shall be deemed to have been revoked, and the newly appointed Reporting Agent shall be able to deal with the Repository within the scope of such Reporting Agent’s authority.

6.3.2.2. Registration of the Resignation of a Reporting Agent

6.3.2.2.1. To resign as a Reporting Agent, a Reporting Agent shall submit to the Repository a Reporting Agent Resignation Application (Form CM017 in Appendix 1 hereto).

6.3.2.2.2. Upon receipt of a Reporting Agent’s Reporting Agent Resignation Application (Form CM017 in Appendix 1 hereto) in electronic format, the Repository shall send to such Reporting Agent an acknowledgment of receipt issued in accordance with the EDI Agreement. Then the Repository shall check the received message for accuracy and completeness and, if any errors are discovered, shall send a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) to such Reporting Agent. Where the message is found correct, the Repository shall send to such Reporting Agent a Reporting Form Status Advice (Form RM003 in Appendix 1) to inform that the message has been entered in Section 1 of the Contracts Register (the Messages Log).

38

6.3.2.2.3. Upon registration of the message in the Contracts Register and upon making the relevant changes in the Repository’s recordkeeping system, the Repository shall send a Reporting Agent Resignation Notification (Form RM010 in Appendix hereto) to the Client who appointed the resigning Reporting Agent, and a Registration Advice (Form RM001 in Appendix 1 hereto) to the resigning Reporting Agent. To be able to deal with the Repository, the Client whose Reporting Agent has resigned shall either appoint a new Reporting Agent or elect to act as a Reporting Agent himself by submitting to the Repository a Reporting Agent Appointment Application containing either the details and scope of authority of the new Reporting Agent, or the Client’s own details required for the Client to act as a Reporting Agent with respect to all Master Agreements/Contracts to which the Client is a party.

6.4. General Provisions of the Contracts Register Keeping Procedure

6.4.1. General Provisions

6.4.1.1. As part of its repository activities, the Repository shall keep the Contracts Register comprising the following three sections:

- Section 1 of the Contracts Register (the Messages Log) intended to record information on all messages received by the Repository in connection with the matters described herein;

- Section 2 of the Contracts Register (the Contracts Register) intended to record information on Master Agreements and Clients’ Contracts, whether or not such Contracts are made under Master Agreements. Section 2 is intended to make a data entry containing information that meets the Financial Market Regulator’s requirements to information on Master Agreements and Contracts, as well as the requirements to information on a particular type of contracts;

- Section 3 of the Contracts Register (the Registration Log) intended to register data entries made or refused to be made by the Repository in the Contracts Register.

6.4.1.2. The Contracts Register shall be maintained in electronic format, provided that it is possible to provide information contained in the Contracts Register in hard copy.

6.4.1.3. Data entries shall be made in the Contracts Register on the basis of a message, i.e., a document signed by a Reporting Agent and submitted to the Repository in electronic format or (where such message cannot be sent via an electronic communication channel due to an IT Failure on the side of the Repository or the Reporting Agent, provided that such IT Failure is not remedied by the last day of the timeframe provided for hereby) in hard copy.

6.4.1.4. All messages received from a Reporting Agent for the purpose of making data entries in the Contracts Register (including scanned PDF copies of such documents if sent in electronic format) shall be retained by the Repository throughout the effective term of the Master Agreement and/or Contract and for five (5) years of the termination date of the Repository Services Agreement entered into with the Client on whose behalf the Reporting Agent reported information to the Contracts Register.

6.4.1.5. Documents in hard copy received by the Repository from a Client and/or Reporting Agent for the purpose of making data entries in the Contracts Register (including copies of such documents) shall be retained by the Repository throughout the effective term of

39

the Master Agreement and/or Contract and for five (5) years of the termination date of the Repository Services Agreement entered into with the Client on whose behalf the Reporting Agent (including being the Client himself) reported information to the Contracts Register.

6.4.1.6. The Contracts Register shall be maintained by the Repository in electronic format, provided that it is possible to provide information contained in the Contracts Register in hard copy.

6.4.1.7. The Repository shall ensure the safekeeping and protection of all information entered in the Contracts Register, including by creating a backup copy of the Contracts Register and implementing procedures aimed at preventing IT failures or errors and unauthorized access to the Contracts Register.

6.4.1.8. The Repository shall ensure the issuance of an Excerpt from the Contracts Register as at the end of the Business Hours on each business day and the issuance of information on any data entry made in the Contracts Register as at any time. The Repository shall also ensure the issuance of documents containing information on all or some of the Master Agreements/Contracts entered in the Contracts Register (“Excerpts from the Contracts Register”) as at any date or for any time period.

6.4.1.9. The Repository shall enter in the Contracts Register information required by the effective Russian laws and/or Financial Market Regulator’s regulations that govern the provision of repository services, details of messages regarding Master Agreements/Contracts, and information additionally reported by Reporting Agents/Clients for entering in the Contracts Register either in the form of hard copies of documents (provided that such hard copies have the form/format required for repository messages) or scanned PDF copies of documents on electronic media.

6.4.1.10. The Repository shall retain information recorded in the Contracts Register throughout the period while the Contracts Register is maintained and for at least five years after the maintenance of the Contracts Register is discontinued.

6.4.1.11. Information shall be entered in the Contracts Register in Russian. Where information on a Master Agreement and/or Contract is reported in a foreign language, such information as the name of a party to the Master Agreement or Contract, the Reporting Agent’s name, and a scanned copy of the attached document can be entered in the Contracts Register in such foreign language.

6.4.1.12. Information reported in a foreign language for the purpose of making data entries in the Contracts Register shall be transliterated using the Latin alphabet.

6.4.2. Section 1 of the Contracts Register (the Messages Log)

6.4.2.1. Section 1 of the Contracts Register shall be intended to make a data entry regarding messages received by the Repository and containing information on Contracts and/or Master Agreements.

6.4.2.2. Data entries shall be made in Section 1 of the Contracts Register by the Repository no later than the business day immediately next to the date of the receipt of the message.

40

6.4.2.3. A data entry made in Section 1 of the Contracts Register shall contain the following details:

1) the name of the message and its consequential number assigned at the time of its registration (incoming number);

2) the date and time of message registration in Section 1 of the Contracts Register;

3) the sequential (reference) number and date of sending of the message (if any); and

4) the reference number and date of a response (if any) to the message.

6.4.3. Making Data Entries in Section 2 of the Contracts Register

6.4.3.1. Upon receipt of a message containing information on a Master Agreement and/or Contract for initial registration, the Repository shall, before entering such information in Section 2 of the Contracts Register, verify whether the message is unique and whether duplicate information is contained in the Contracts Register. The process of verification of such message in the Repository’s recordkeeping system shall be performed in accordance with the “Procedure for Determination of Uniqueness of Messages to Be Registered and Search for Matching Reporting Forms for the Purpose of Messages Matching”.

6.4.3.2. Information on a Contract made under a Master Agreement shall only be entered in Section 2 of the Contracts Register after entering in Section 2 of the Contracts Register information on the Master Agreement under which such Contract is made.

6.4.3.3. Where a data entry is made in Section 2 of the Contracts Register in response to a message sent to the Repository in the form of an electronic document issued in accordance with the EDI Agreement, the Reporting Agent shall be sent a Registration Advice in electronic format stating the number assigned to the said message by the Repository.

6.4.3.4. Where the Repository refuses to make a data entry in Section 2 of the Contracts Register in response to a message sent to the Repository in the form of an electronic document issued in accordance with the EDI Agreement, the Reporting Agent shall be sent a Registration/Execution Rejection Advice in electronic format, stating the reason of such refusal. Where necessary, the reason of refusal can be explained in more detail in a document delivered to the Reporting Agent. In such cases, the Repository shall be deemed to have performed its obligations with respect to such Reporting Agent’s message.

6.4.3.5. Where the Repository refuses to make a data entry in Section 2 of the Contracts Register, the Reporting Agent may make changes to the message and send a new message to the Repository within three business days of the receipt of the Registration/Execution Rejection Advice, unless the Repository refuses to make a data entry in Section 2 of the Contracts Register due to the fact that no UTI is specified in the message and/or the fact that the purpose of the Reporting Agent’s message is to change the UTI of the Contract. In this case, the time limits for sending such message shall be deemed to have not been exceeded, unless the Repository again refuses to make a data entry in Section 2 of the Contracts Register.

41

6.4.3.6. The Repository shall make, or take a decision to refuse to make, a data entry in Section 2 of the Contracts Register no later than the business day immediately next to the date of receipt of the message from the Reporting Agent, or, where both parties to the relevant Master Agreement/Contract are Reporting Agents, no later than the business day immediately next to the date of receipt of the last of the messages, provided that the details contained in the messages received from the Reporting Agents of the parties to such Master Agreement/Contract match.

6.4.3.7. Information on a Master Agreement (or on amendments thereto, or performance of obligations thereunder) or information on a Contract (or on amendments thereto, or changes to codes of obligation status, or performance of obligations thereunder), where the parties to such Master Agreement/Contract are required to report information to the Contracts Register in accordance with the effective Russian laws, shall only be entered in Section 2 of the Contracts Register provided that both such parties have entered into the Repository Services Agreement with the Repository.

6.4.3.8. For the purpose of making data entries in Section 2 of the Contracts Register, a Reporting Agent shall send messages in electronic format. Where the Repository or a Reporting Agent is not able to issue, receive and/or send duly prepared messages/documents in electronic format by the last day of the time limits within which such message is to be sent, such messages/documents can be submitted to the Repository in hard copy.

6.4.3.9. Where information is reported to the Repository in hard copy, the relevant document shall be signed by both Reporting Agents appointed by the Clients being parties to the Master Agreement/Contract. Where both parties have the same Reporting Agent, the document shall be signed by such Reporting Agent only.

6.4.3.10. A document in hard copy submitted to the Repository by a Client/Reporting Agent whose counterparty is a Client not obliged to report information to the Repository and who has submitted to the Repository a Reporting Refusal Notification shall be signed only by the Client/Reporting Agent of the Client being the party to the Master Agreement/Contract who is obliged to report information to the Repository (or of the Client being the party to the Master Agreement/Contract who is not obliged to report information to the Repository, is a Repository’s Client, and has not refused to report information to the Repository).

6.4.4. Section 3 of the Contracts Register (the Registration Log)

6.4.4.1. The Repository shall register, in Section 3 of the Contracts Register, each data entry made, and each refusal to make a data entry, in Section 2 of the Contracts Register.

6.4.4.2. Information regarding a data entry made or refused to be made in Section 2 of the Contracts Register shall be registered in the Registration Log (Section 3 of the Contracts Register) at the same time when such data entry is made or refused to be made in Section 2 of the Contracts Register.

6.4.4.3. A data entry made in Section 3 of the Contracts Register shall contain the following details:

1) the registration number assigned to a Master Agreement/Contract by the Repository;

42

2) the LEI of the party to the Master Agreement/Contracts, as well as the LEI of the Reporting Agent;

3) the date, time, and number of the data entry made in Section 2 of the Contracts Register, or the date of notification of the refusal to make a data entry in Section 2 of the Contracts Register;

4) the type of the data entry made in Section 2 of the Contracts Register (initial data entry or changes to an earlier data entry);

5) information on the fact of making the data entry in Section 2 of the Contracts Register, or the basis of the refusal to make a data entry in Section 2 of the Contracts Register; and

6) the UTI of the Contract/Master Agreement.

6.5. Registration of information on a Master Agreement, Amendments to a Master Agreement, or Termination of a Master Agreement

6.5.1. The Repository shall register information on a Master Agreement, or amendments to a Master Agreement, or termination of a Master Agreement for the purpose of recording, in the Repository’s recordkeeping systems, information on Master Agreements under which Clients make Contracts information on which is to be entered in the Contracts Register.

6.5.2. The registration of information on a Master Agreement shall be performed with respect to any new information that was not earlier registered in the Repository’s recordkeeping system with respect to Master Agreements.

6.5.3. Changes to information on a Master Agreement shall be entered in the Contracts Register to reflect amendments made to the Master Agreement information on which was earlier entered in the Contracts Register.

6.5.4. Information on a Master Agreement shall be entered on the basis of a Master Agreement Reporting Form (Form CM010 in Appendix 1 hereto). Along with a Master Agreement Reporting Form, a Reporting Agent may submit a copy of the Master Agreement to which the Master Agreement Reporting Form relates. Where a Master Agreement Reporting Form is submitted to the Repository in electronic format, the Repository may, in addition to the file containing the Master Agreement Reporting Form, include a scanned PDF copy of the Master Agreement in the electronic documents package issued in accordance with the EDI Agreement and Section 7 hereof.

6.5.5. Information on amendments to a Master Agreement shall be entered in the Contracts Register on the basis of a Master Agreement Reporting Form that must specify its purpose (being “making amendments”) and the details of the Master Agreement Reporting Form (date and registration number) that is to be changed.

6.5.6. Information on termination of a Master Agreement shall be entered in the Contracts Register either on the basis of a Master Agreement Termination Reporting Form (Form CM011 in Appendix 1 hereto) or on the basis of an excerpt from the Russian Unified State Register of Legal Entities received by the Repository and containing information on liquidation of the Repository’s Client being a party to the Master Agreement.

43

6.5.7. Following the registration, or rejection of registration, of a Master Agreement Reporting Form, or of changes to a Master Agreement Reporting Form, or of a Master Agreement Termination Reporting Form, the relevant data entries shall be made in the Contracts Register, and the Repository shall issue a Registration Advice (Form RM001 in Appendix 1 hereto) or a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) stating the reason of rejection.

6.5.8. The registration of information on a Master Agreement, or of amendments to a Master Agreement, or of termination of a Master Agreement shall be initiated by a Reporting Agent authorized by the Client to report the relevant information to be entered in the Contracts Register.

6.5.9. The registration of a Master Agreement Reporting Form, or of changes to a Master Agreement Reporting Form, or of a Master Agreement Termination Reporting Form shall be made by the Repository.

6.5.10. Information on a Master Agreement may be entered in the Contracts Register either before the receipt by the Repository of information on a Contract made under such Master Agreement and to be registered in the Repository’s recordkeeping system, or concurrently with information on the Contract made under such Master Agreement.

6.5.11. Where information on a Master Agreement under which a Contract is made is reported concurrently with information on the Contract, such information shall be reported within three (3) business days of the date when such Contract is made.

6.5.12. Where any amendments are made to a Master Agreement information on which was entered in the Contracts Register, information on such amendments shall be reported to the Repository within three (3) business days of the effective date of such amendments.

6.5.13. Where a Master Agreement information on which was entered in the Contracts Register is terminated, information on termination of the Master Agreement shall be reported to the Repository within three (3) business days of the termination date of the Master Agreement.

6.5.14. Where a Master Agreement is terminated due to the liquidation of the Repository’s Client, information on termination of the Master Agreement may be entered in the Contracts Register on the basis of a Repository’s Internal Instruction by the Repository’s submission of a Master Agreement Termination Reporting Form stating “Liquidation” as the reason of the Master Agreement termination (“Deregistration of a Master Agreement by the Repository in the event of a Client’s liquidation”) with respect to each of the Master Agreements registered and not closed in the Contracts Register for the Client information on whose liquidation (an Excerpt from the Russian State Register of Legal Entities) has been received by the Repository. Upon registration in the Contracts Register of a Master Agreement Termination Reporting Form, all the Contracts registered in the Contracts Register under such Master Agreement and not closed as at the time when the Repository enters information on the Master Agreement termination shall be closed by default with status “D”.

6.5.15. A data entry regarding a new Master Agreement (which was not earlier registered in the Repository’s recordkeeping system) shall be made in the Contracts Register within the standard time limits applicable to Repository Operations upon receipt of the relevant message from the

44

Client being a party to the Master Agreement, regardless of whether a similar message is received by the Repository from the Client being the second party to the Master Agreement.

6.5.16. Information on a new Master Agreement, or on termination of a Master Agreement, or on amendments to a Master Agreement registered earlier shall be entered in the Contracts Register within the standard time limits applicable to Repository Operations, in accordance with the provisions hereof which describe the procedure for registration of information on a Master Agreement, or amendments to a Master Agreement, or termination of a Master Agreement in the Contracts Register.

6.5.17. Where each party to a Master Agreement has separately appointed a Reporting Agent (for bilateral entry of information in the Contracts Register), the process of confirmation of messages containing information on execution/amendment/termination of the Master Agreement shall be performed, by default, using the consecutive confirmation method.

6.5.18. Where both parties to a Master Agreement has appointed the same (a single) Reporting Agent (for unilateral entry of information in the Contracts Register), information on execution/amendment/termination of the Master Agreement shall be entered in accordance with the procedure for unilateral entry of information in the Contracts Register.

6.5.19. Where one of the parties to a Master Agreement is a Repository’s Client who is not obliged to report information to the Repository, has refused to report information to the Repository, and has not appointed a Reporting Agent, data entries in the Contracts Register shall be made in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the Master Agreement/Contract is a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to report information to the Contracts Register.

6.5.20. Where one of the parties to a Master Agreement is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client, data entries in the Contracts Register shall be made in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the Master Agreement/Contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client.

6.6. Registration of Information on a Contract / Amendments to a Contract in the Contracts Register

6.6.1. Information on a Contract / amendments to a Contract made under a Master Agreement, or information on a Contract / amendments to a Contract made other than under a Master Agreement, shall be entered by the Repository for the purpose of recording, in the Contracts Register, information on Contracts made by Clients, whether or not such Contracts are made under a Master Agreement.

6.6.2. The registration of information on a Contract shall be performed with respect to any new information that was not earlier registered in the Repository’s recordkeeping system with respect to such Contract.

45

6.6.3. Changes to information on a Contract shall be entered in the Contracts Register to reflect amendments made to the Contract information on which was earlier entered in the Contracts Register.

6.6.4. Information on a Contract shall be entered on the basis of a Contract Reporting Form (Forms CM021 – CM081 in Appendix 1 hereto). Along with a Contract Reporting Form, a Reporting Agent may submit a copy of the Contract to which the Contract Reporting Form relates. Where a Contract Reporting Form is submitted to the Repository in electronic format, the Repository may, in addition to the file containing the Contract Reporting Form, include a scanned PDF copy of the Contract in the electronic documents package issued in accordance with the EDI Agreement and Section 7 hereof.

6.6.5. Information on amendments to a Contract shall be entered in the Contracts Register on the basis of a Contract Reporting Form that must specify its purpose (being “making amendments”) and the details of the Contract Reporting Form (date and registration number) that is to be changed.

6.6.6. Following the registration, or rejection of registration, of information on a Contract or of amendments to a Contract, whether or not such Contract is made under a Master Agreement, the Repository shall make the relevant data entries in Section 2 and Section 3 of the Contracts Register and issue a Registration Advice (Form RM001 in Appendix 1 hereto) or a Notification of Execution/Registration Rejection (Form RM002 in Appendix 1 hereto) stating the reason of rejection.

6.6.7. The registration of information on a Contract, or of amendments to a Contract, shall be initiated by a Reporting Agent authorized by the Client to report the relevant information to be entered in the Contracts Register.

6.6.8. The registration of a Contract, or of amendments to a Contract, shall be made by the Repository.

6.6.9. For a Contract made under a Master Agreement, where both information on a Contract and information on a Master Agreement under which the Contract is made is concurrently reported to the Repository, the Repository shall register the Master Agreement in accordance herewith, and shall record the Contract Reporting Form for the Contract made under such Master Agreement in the Repository’s recordkeeping system with the ‘pending Master Agreement registration’ status.

6.6.10. Where the Repository cannot register the Master Agreement Reporting Form within 30 calendar days, the Repository shall issue and send to the Reporting Agent(s) a Registration/Execution Rejection Advice for the Master Agreement Reporting Form and a Registration/Execution Rejection Advice for the Contract Reporting Form.

6.6.11. Where the Repository, by the end of the Business Hours, does not receive information on the Master Agreement under which the Contract was made to which an earlier submitted Contract Reporting Form relates, such Contract Reporting Form will be cancelled by the Repository at the end of the Business Hours.

6.6.12. Where both information on a Contract and information on a Master Agreement under which the Contract is made is concurrently reported to the Repository, the data field “Related Document Number” (block <parentCorrelationId> in an XML message) must be completed. This

46

data field shall contain the correlation identifier corresponding to the message containing information on the Master Agreement.

6.6.13. Where both the data field “Related Document Number” and the data field “Master Agreement Number” are completed by a Reporting Agent in a Contract Reporting Form upon the concurrent reporting of information on a Contract and information on a Master Agreement under which the Contract is made, the Repository shall issue and send to the Reporting Agents a Registration/Execution Rejection Advice.

6.6.14. Upon successful registration of the Master Agreement Reporting Form, the Repository shall proceed to the registration of the Contract Reporting Form using the method chosen by the parties to the Contract for confirmation of the Contract’s details.

6.6.15. For a Contract made other than under a Master Agreement, the Repository shall not check whether information on a Master Agreement is available in the Repository’s recordkeeping systems, but immediately proceed to the recording of the Contract Reporting Form in the Contracts Register.

6.6.16. Information on a Contract, or on amendments to a Contract, shall be reported to the Repository within three (3) business days of the execution date of the Contract or of the effective date of the amendments to the Contract, respectively.

6.6.17. Where, in the cases stipulated by the Russian laws, information on a corporate Client’s Contracts is reported to the Repository upon the achievement of the applicable threshold amounts of transactions made by the Client, for the purposes of making the relevant data entries in the Contracts Register, information on such Contracts shall be reported within the following time limits:

where a Contract is made for an amount equal to or exceeding the threshold set by the Russian laws – within three (3) business days of the execution date of the Contract;

where a series of Contracts are made for a total amount exceeding the threshold set by the Russian laws during the accounting period – within the month following the accounting period; and

where a Contract is made for any amount starting from the first day of the month following the accounting period, during which the total amount of the series of Contracts exceeded the threshold set by the Russian laws – within three (3) business days of the execution date of such Contract.

6.6.18. Information on a Contract, or on amendments to a Contract, shall be entered in the Contracts Register within the standard time limits applicable to Repository Operations.

6.6.19. Where each party to a Contract has separately appointed a Reporting Agent (for bilateral entry of information in the Contracts Register), the process of confirmation of messages containing information on execution/amendment of the Contract shall be performed using either the combined confirmation method or the matching confirmation method, as may be indicated by the Reporting Agents in the Contract Reporting Form.

6.6.20. Where both parties to a Contract has appointed the same (a single) Reporting Agent (for unilateral entry of information in the Contracts Register), information on execution/amendment

47

of the Contract shall be entered in accordance with the procedure for unilateral entry of information in the Contracts Register.

6.6.21. Where one of the parties to a Contract is a person who is not obliged to report information to the Repository, has refused to report information to the Repository, but is a Repository’s Client, data entries in the Contracts Register shall be made in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the Master Agreement/Contract is a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to report information to the Contracts Register.

6.6.22. Where one of the parties to a Contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client, data entries in the Contracts Register shall be made in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the Master Agreement/Contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client.

6.7. Registration of Information on the Status of Obligations under a Contract, Including Termination or Discharge of Obligations (Termination of a Contract)

6.7.1. Information on the status of obligations under a Contract, including termination or discharge of obligations, shall be registered by the Repository to record the status of obligations under the Contract in the Repository’s recordkeeping systems.

6.7.2. Information on the status of obligations under a Contract shall be entered in the Contracts Register in the event of any changes in the status of obligations or termination/discharge of obligations under the Contract.

6.7.3. Information on the status of obligations under a Contract or termination/discharge of obligations (termination of the Contract) shall be entered on the basis of a Contract Obligation Status Reporting Form (Form CM093 in Appendix 1 hereto).

6.7.4. Following the registration, or rejection of registration, of a Contract Obligation Status Reporting Form, the relevant data entries shall be made in Section 2 and Section 3 of the Contracts Register, and the Repository shall issue a Registration Advice (Form RM001 in Appendix 1 hereto) or a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) stating the reason of rejection.

6.7.5. The registration of information on the status of obligations under a Contract or termination/discharge of obligations (termination of the Contract) shall be initiated either by a Reporting Agent authorized by the Client to report the relevant information to be entered in the Contracts Register, or by the Repository where the Repository is authorized by the Client to make data entries in the Contracts Register regarding termination of the Contract due to the occurrence of its termination date.

6.7.6. The registration of a Contract Obligation Status Reporting Form shall be made by the Repository.

48

6.7.7. Information on termination of a Contract shall be reported to the Repository within three (3) business days of the date of termination or fulfillment of the Contract. In the event of any change in a code of Contract obligation status, information on such change shall be reported to the Repository within three (3) business days of the effective date of such change and/or of the occurrence of the relevant event. A data entry regarding termination of the Contract due to the occurrence of its termination date shall be made in the Contracts Register by the Repository no earlier than three (3) business days of the Contract termination date specified by the Client in the Contract Reporting Form.

6.7.8. Information on the status of obligations under a Contract, including termination/discharge of obligations, shall be entered in the Contracts Register within the standard time limits applicable to Repository Operations.

6.7.9. Where each party to a Contract has separately appointed a Reporting Agent (for bilateral entry of information in the Contracts Register), the process of confirmation of messages may be performed using the combined confirmation method.

6.7.10. Where both parties to a Contract has appointed the same (a single) Reporting Agent (for unilateral entry of information in the Contracts Register), information shall be entered in accordance with the procedure for unilateral entry of information in the Contracts Register.

6.7.11. Where one of the parties to a Contract is a person who is not obliged to report information to the Repository, has refused to report information to the Repository, but is a Repository’s Client, data entries regarding the status of obligations shall be made in the Contracts Register in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the Master Agreement/Contract is a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to report information to the Contracts Register.

6.7.12. Where one of the parties to a Contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client, data entries regarding the status of obligations shall be made in the Contracts Register in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the Master Agreement/Contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client.

6.7.13. Data entries regarding termination of a Contract due to the occurrence of its termination date shall be made by the Repository unilaterally, provided that both parties to the Contract who are Repository’s Clients has authorized the Repository to make data entries regarding the Contract termination in the Contracts Register.

6.8. Registration of a Credit Support Annex Reporting Form

6.8.1. Information on a security of obligations shall be reported for the purpose of entering such information in the Contracts Register where the parties to a Master Agreement/Contract has entered into a Credit Support Annex.

49

6.8.2. Information on a security of obligations shall be entered in the Contracts Register on the basis of a Credit Support Annex Reporting Form (Form CM015 in Appendix 1 hereto).

6.8.3. Following the registration, or rejection of registration, of a Credit Support Annex Reporting Form, the relevant data entries shall be made in Section 2 and Section 3 of the Contracts Register, and the Repository shall issue a Registration Advice (Form RM001 in Appendix 1 hereto) or a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) stating the reason of rejection.

6.8.4. The registration of a Credit Support Annex Reporting Form shall be initiated by a Reporting Agent authorized by the Client to report the relevant information to be entered in the Contracts Register.

6.8.5. The registration of a Credit Support Annex Reporting Form shall be made by the Repository.

6.8.6. Information on a Credit Support Annex shall be reported within three (3) business days of the date of such Annex.

6.8.7. A Credit Support Annex Reporting Form shall be registered in the Contracts Register within the standard time limits applicable to Repository Operations.

6.8.8. Where each party to a Credit Support Annex has separately appointed a Reporting Agent (for bilateral entry of information in the Contracts Register), the process of confirmation of information contained in the Credit Support Annex Reporting Form shall be performed using either the combined confirmation method or the matching confirmation method, as may be indicated by the Reporting Agents in the Credit Support Annex Reporting Form.

6.8.9. Where both parties to a Credit Support Annex has appointed the same (a single) Reporting Agent (for unilateral entry of information in the Contracts Register), information on the Credit Support Annex shall be entered in accordance with the procedure for unilateral entry of information in the Contracts Register.

6.8.10. Where one of the parties to a Credit Support Annex is a person who is not obliged to report information to the Repository, has refused to report information to the Repository, but is a Repository’s Client, data entries in the Contracts Register shall be made in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the contract is a person who is not obliged to report information to the Repository, is a Repository’s Client, and has refused to report information to the Contracts Register.

6.8.11. Where one of the parties to a Credit Support Annex is a person who is not obliged to report information to the Repository, has refused to report information to the Repository, and is not a Repository’s Client, data entries in the Contracts Register shall be made in accordance with the procedure for unilateral entry of information in the Contracts Register, subject to the specific procedure to be followed by a Client/Reporting Agent in connection with the making of data entries in the Contracts Register where the second party to the contract is a person who is neither obliged to report information to the Repository, nor is a Repository’s Client.

50

6.9. Registration of a Credit Support Transfer Reporting Form

6.9.1. Information on credit support transfers shall be reported to the Repository for the purpose of entering such information in the Contracts Register where the parties have entered into a floating margin payment agreement.

6.9.2. Information on credit support transfers made under a Contract shall be entered in the Contracts Register on the basis of a Credit Support Transfer Reporting Form (Form CM092 in Appendix 1 hereto).

6.9.3. Following the registration, or rejection of registration, of a Credit Support Transfer Reporting Form, the relevant data entries shall be made in Section 2 and Section 3 of the Contracts Register, and the Repository shall issue a Registration Advice (Form RM001 in Appendix 1 hereto) or a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto) stating the reason of rejection.

6.9.4. A Credit Support Transfer Reporting Form shall be submitted to the Repository by a Reporting Agent of each party to a Contract, whether or not such Contract is made under a Master Agreement, and shall be entered in the Contracts Register without running the confirmation process.

6.9.5. A Credit Support Transfer Reporting Form shall be registered by the Repository.

6.9.6. Information on credit support transfers shall be reported within first five (5) business days of the month immediately next to the month in which credit support payment claims and/or obligations arose as at the date when such claims and/or obligations arose. Where no credit support payment claims and/or obligations arise, no information on credit support transfers shall be reported to the Repository.

6.9.7. A Credit Support Transfer Reporting Form shall be registered in the Contracts Register within the standard time limits applicable to Repository Operations.

6.10. Registration of Information on Mark to Market Valuation

6.10.1. Information on mark to market valuation shall be reported to the Repository for the purpose of entering such information in the Contracts Register.

6.10.2. Information on mark to market valuation shall be entered in the Contracts Register on the basis of a Mark to Market Valuation Reporting Form (Form CM094 in Appendix 1 hereto).

6.10.3. Following the registration, or rejection of registration, of a Mark to Market Valuation Reporting Form, the relevant data entries shall be made in Section 2 and Section 3 of the Contracts Register, and the Repository shall issue a Registration Advice (Form RM001 in Appendix 1 hereto) or a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto).

6.10.4. A Mark to Market Valuation Reporting Form shall be submitted to the Repository by a Reporting Agent of each party to a Contract and shall be entered in the Contracts Register without running the confirmation process.

6.10.5. A Mark to Market Valuation Reporting Form shall be registered by the Repository.

51

6.10.6. Information on mark to market valuation shall be reported to the Repository upon mark to market valuation within first five (5) business days of the month immediately next to the month when such mark to market valuation took place.

6.10.7. A Mark to Market Valuation Reporting Form shall be registered in the Contracts Register within the standard time limits applicable to Repository Operations.

6.11. Registration of Information on Technical Repo Transactions, FX Swap Transactions, and Foreign Exchange Spot Transactions

6.11.1 Information on technical repo transactions, FX swap transactions, and foreign exchange spot transactions shall be reported to the Repository for the purpose of entering such information in the Contracts Register.

6.11.2. Information on technical repo transactions, FX swap transactions, or foreign exchange spot transactions shall be entered in the Contracts Register on the basis of a Repo Bulk Report, FX Swap Bulk Report, or Foreign Exchange Spot Bulk Report, respectively (Forms CM083 – CM085 in Appendix 1 hereto).

6.11.3. Following the registration, or rejection of registration, of a Report, the relevant data entries shall be made in Section 2 and Section 3 of the Contracts Register, and the Repository shall issue a Registration Advice (Form RM001 in Appendix 1 hereto) or a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto).

6.11.4. A Repo Bulk Report, FX Swap Bulk Report, and/or Foreign Exchange Spot Bulk Report shall be submitted to the Repository by a Reporting Agent of each party to a Contract and shall be entered in the Contracts Register without running the confirmation process.

6.11.5. A Repo Bulk Report, FX Swap Bulk Report, or Foreign Exchange Spot Bulk Report shall be registered by the Repository.

6.11.6. A Mark to Market Valuation Reporting Form shall be registered in the Contracts Register within the standard time limits applicable to Repository Operations.

6.12. Making Corrective Entries in the Contracts Register

6.12.1 Making Corrective Entries in the Contracts Register in Connection with Objections Raised by a Reporting Agent/Client

6.12.1.1. A Reporting Agent/Client may submit to the Repository rejections as to a data entry made in the Contracts Register no later than the third (3rd) business day of the receipt of the Repository’s message regarding such data entry made in the Contracts Register.

6.12.1.2. Objections as to data entries made in the Contracts Register shall be submitted to the Repository in the form of an official letter in hard copy.

6.12.1.3. Objections as to data entries made in the Contracts Register shall be signed by a Reporting Agent’s / Client’s authorized representative. Where there are two Reporting Agents, objections as to data entries made in the Contracts Register will only be reviewed by the Repository if the Repository receives a hard-copy letter containing objections from each Reporting Agent/Client, signed by a Reporting Agent's / Client’s authorized representative.

52

6.12.1.4. Objections raised by a Reporting Agent / Client as to data entries made in the Contracts Register shall be reviewed by the Repository no later than the deadline required by the Financial Market Regulator’s regulations for reviewing objections. Where the Repository decides to make a corrective entry other than by a standard Repository Operation (correction of the Contracts Register), the Repository shall either make the relevant changes to the Contracts Register and send a response describing the steps taken to the Reporting Agent / Client, or reject the objections and send a written notification of refusal to make changes to the Contracts Register, stating the reason of such rejection. Where a corrective entry is made in the Contracts Register, the Repository shall give notice of such corrective entry to the Financial Market Regulator.

6.12.2. Making Corrective Entries in the Contracts Register in Connection with Corrections Made by a Reporting Agent

6.12.2.1. A Reporting Agent may correct information entered in the Contracts Register.

6.12.2.2. To correct information provided earlier, the Reporting Agent shall submit to the Repository a document that meets the requirements hereof to forms/formats of messages to be sent by Reporting Agents/Clients to the Repository, subject to the provisions of clause 6.12.2 hereof.

6.12.2.3. The Reporting Agent may correct the following forms:

Master Agreement Reporting Forms;

Contract Reporting Forms;

Credit Support Annex Reporting Forms;

Contract Obligation Status Reporting Forms; and

Master Agreement Termination Reporting Forms.

6.12.2.4. Correcting Master Agreement Reporting Forms, Contract Reporting Forms, or Credit Support Annex Reporting Forms

6.12.2.4.1. To correct any Reporting Form referred to in clause 6.12.2.4 above, it shall be required to submit to the Repository the relevant Reporting Form containing the word “correction”.

6.12.2.4.2. A correction of a Reporting Form referred to in clause 6.12.2.4 above shall be possible either before the time of deregistration (closing) of the relevant Master Agreement/Contract/Credit Support Annex or following its deregistration (closing).

6.12.2.5. Making Corrective Entries in respect of a Contract Obligation Status Reporting Form

6.12.2.5.1. A correction of a Contract Obligation Status Reporting Form shall be made by submitting to the Repository a new Contract Obligation Status Reporting Form.

6.12.2.6. Making Corrective Entries in respect of a Master Agreement Termination Reporting Form

53

6.12.2.6.1. A correction of a Master Agreement Termination Reporting Form shall be made by submitting to the Repository a new Master Agreement Termination Reporting Form stating the reason “Reopen”.

6.12.2.7. Reporting Agents shall make corrections in the Contracts Register by using the confirmation method agreed upon by the parties to the relevant Master Agreement/Contract and permitted hereby.

6.2.12.8. The Repository shall either make the relevant corrective entry in the Contracts Register and send a Registration Advice (Form RM001 in Appendix 1 hereto) to the Reporting Agent, or refuse to make a corrective entry and send an Execution/Registration Rejection Advice (Form RM002 in Appendix 1 hereto) to the Reporting Agent where the correcting Reporting Form (i.e., the Reporting Form containing the word “correction” / new Contract Obligation Status Reporting Form / new Master Agreement Termination Reporting Form stating the reason “Reopen”) is issued other than in accordance with the required format of repository messages.

6.12.2.9. Where it is impossible to submit a corrective Reporting Form through the EDI System (due to a Reporting Agent’s / Repository’s software failure), the Reporting Agent(s) shall make the correction by submitting the relevant Reporting Form in hard copy, signed by authorized representatives of the Reporting Agent of each party to the Master Agreement/Contract (for bilateral entry of information in the Contracts Register), or signed by an authorized representative of the Reporting Agent of one of the parties to the Master Agreement/Contract (for unilateral entry of information in the Contracts Register).

6.13. Procedure for, and Time Limits of, Provision of Information from the Contracts Register

6.13.1. Provision of Information from the Contracts Register to a Reporting Agent on a Regular Basis

6.13.1.1. No later than the business day immediately next to the date when a data entry is made in the Contracts Register, the Repository shall provide an Excerpt from the Contracts Register containing information on registrations/changes made in the Contracts Register.

6.13.1.2. A message containing information on changes made in the Contracts Register shall be issued and sent to a Reporting Agent(s) in the form of an Excerpt from the Contracts Register (Form RM004 in Appendix 1 hereto).

6.13.1.3. An Excerpt from the Contracts Register sent to a Reporting Agent shall include information on registered/amended Master Agreements, Contracts (whether or not such Contracts are made under Master Agreements), Credit Support Annexes, Credit Support Transfer Reporting Forms, Mark to Market Valuation Reporting Forms, and status of obligations under Contracts (whether or not such Contracts are made under Master Agreements), as registered in the Contracts Register as at the issuance date of the Excerpt from the Contracts Register, with respect to which the said Reporting Agent acts as such.

6.13.1.4. An Excerpt from the Contracts Register shall be issued at the end of the Repository’s Business Hours and shall contain all information registered in the Contracts Register during such Business Hours.

54

6.13.5. An Excerpt from the Contracts Register issued on a daily basis to a Reporting Agent shall not include scanned copies of any documents (Master Agreements/Contracts) agreed upon by the parties to a Master Agreement/Contract and submitted for the purpose of making data entries in the Contracts Register, as well as Reporting Agent Appointment Applications. To receive an Excerpt from the Contracts Register containing scanned copies of such documents registered in the Contracts Register, the Reporting Agent shall submit a written request (in any form whatsoever) for an Excerpt from the Contracts Register containing scanned copies of necessary documents, stating the type of documents, such as a Master Agreement(s) and/or Contracts made under a Master Agreement / Contracts made other than under a Master Agreement, and/or information on Credit Support Annexes and/or Credit Support Transfer Reporting Forms, Mark to Market Valuation Reporting Forms, and/or information on the status of obligations under Contracts made under a Master Agreement or the status of obligations under Contracts made other than under a Master Agreement, a registration number(s) of a Master Agreement(s) under which Contracts are made, or a registration number(s) of a Contract(s) made other than under a Master Agreement, information on which and scanned copies of which are registered in the Contracts Register.

6.13.2. Provision of the Contracts Register to the Financial Market Regulator on a Daily Basis

6.13.2.1. Each business day of a month, as at the end of the Business Hours, the Repository shall provide the Contracts Register to the Financial Market Regulator.

6.13.2.2. The Contracts Register provided by the Repository to the Financial Market Regulator on a daily basis shall include information on all registered and amended Master Agreements and Contracts (whether or not such Contracts are made under a Master Agreement), Credit Support Annexes, Credit Support Transfer Reporting Forms, Mark to Market Valuation Reporting Forms, and information on the status of obligations under Contracts (whether or not such Contracts are made under a Master Agreement), as registered in the Contracts Register as at the end of the Business Hours.

6.13.2.3. The Contracts Register shall be provided as a zip file containing xml Excerpts from the Contracts Register with information listed in clause 6.13.2.2, and Excel files containing Section1 and Section 3 of the Contracts Register. Alternatively, the Contracts Register shall be provided by granting the Bank of Russia uninterrupted, secured access to the Repository’s database tables.

6.13.2.4. The Contracts Register shall be provided to the Financial Market Regulator in the manner stipulated by the Financial Market Regulator.

6.13.2.5. Additional information which is received under the Repository Services Agreement but is different from the Contracts Register (in terms of information structure, period covered, etc.) shall be provided by the Repository to the Financial Market Regulator at a Financial Market Regulator’s request stating necessary parameters. Additional information which is received under the Repository Services Agreement but is different from the Contracts Register shall be provided to the Financial Market Regulator within 5 business days following the receipt by the Repository of the relevant request.

55

6.13.2.6. The Contracts Register provided by the Repository to the Financial Market Regulator on a daily basis shall not include scanned copies of any documents (Master Agreements/Contracts) agreed upon by the parties to a Master Agreement/Contract and registered in the Contracts Register. To receive the Contracts Register containing scanned copies of such documents registered in the Contracts Register, the Financial Market Regulator shall submit a separate written request (in any form whatsoever) for the Contracts Register containing scanned copies of necessary documents, stating the type of documents, such as a Master Agreement(s) and/or Contracts made under or other than under a Master Agreement, a Registration Number(s) of a Master Agreement(s) and/or a Contract(s) assigned by the Repository upon making the relevant data entries in the Contracts Register, information on which and scanned copies of which are registered in the Contracts Register.

6.13.3. Procedure for, and Time Limits of, Provision of Information from the Contracts Register upon an Interested Person’s Written Request

6.13.3.1 The Repository shall provide information from the Contracts Register upon written requests submitted by Clients, Reporting Agents, or any other person referred to in Financial Market Regulator’s regulations governing Repository’s activities.

6.13.3.2. To receive information from the Contracts Register, a Client, or a Reporting Agent, or any other person referred to in Financial Market Regulator’s regulations shall submit to the Repository a Request for an Excerpt from the Contracts Register (Form CM004 in Appendix 1 hereto).

6.13.3.3. A Client, or a Reporting Agent, or any other person referred to in Financial Market Regulator’s regulations governing Repository’s activities may request an Excerpt from the Contracts Register (including from Section 1 of the Contracts Register) with respect to a particular Master Agreement / Contract (whether or not such Contract is made under a Master Agreement), stating in such request the necessary criteria in accordance with which the Excerpt from the Contracts Register is to be issued, subject to the possible values of the ‘StatementType’ data field.

6.13.3.4. No later than the business day immediately next to the date when the request is received, the Repository shall issue an Excerpt from the Contracts Register (Form RM004 in Appendix 1 hereto) / an Excerpt from Section 1 of the Contracts Register (Form RM009 in Appendix 1 hereto) and send it to the relevant Client, Reporting Agent, or such other person referred to in Financial Market Regulator’s regulations.

6.13.3.5. Where it is impossible to issue an Excerpt from the Contracts Register (including from Section 1 of the Contracts Register), the Repository shall issue a Registration/Execution Rejection Advice (Form RM002 in Appendix 1 hereto).

6.13.3.6. To receive additional information from the Contracts Register, the Financial Market Regulator shall submit to the Repository a request for information from the Contracts Register, stating request parameters, form of information provision, dates, and a medium on which such information is to be provided (in hard copy and/or on an electronic medium).

6.13.3.7. Within the time limits set out in the request, which must not be less than five (5) business days, the Repository shall issue and send to the Financial Market Regulator a response containing parameters of information requested, in the form requested.

56

6.13.3.8. Where the preparation of information in the amount, in the format, and within the time limits requested requires more time, the Repository shall give notice to the Financial Market Regulator, stating the time required to prepare information requested and the date when such information will be provided.

6.13.3.9. The Repository shall also provide information from the Contracts Register (including from Section 1 of the Contracts Register) upon a written request by an insolvency practitioner (liquidation committee) appointed with respect to an obligor being a party to a Contract.

6.13.3.10. Along with a request for information from the Contracts Register (including from Section 1 of the Contracts Register), an insolvency practitioner (liquidation committee) shall submit documents containing information on the appointment of insolvency practitioner (liquidation committee), the date of revocation (cancellation) of the banking license, and details of a representative of the State Corporation “Deposit Insurance Agency” appointed to act as a receiver (liquidator), if the State Corporation “Deposit Insurance Agency” is appointed to act as such (in the event of bankruptcy (liquidation) of a credit organization). In addition, the request shall be accompanied by documents evidencing the authority of the insolvency practitioner (liquidation committee) or of the trustee (liquidator) appointed in the event of bankruptcy (liquidation), or a copy of his/her passport.

6.13.3.11. The Repository shall verify the requester’s authority as per the documents submitted and review the insolvency practitioner’s / liquidation committee’s / receiver’s request for an Excerpt from the Contracts Register (including from Section 1 of the Contracts Register) within five (5) business days of the receipt of such request. Upon review of the request, the Repository shall send to the insolvency practitioner (liquidation committee) / receiver a response containing information on the Contracts registered on behalf of the Client being an obligor under such Contracts, as per the requested parameters and in hard copy. Where the Repository cannot provide information requested from the Contracts Register (including from Section 1 of the Contracts Register), the Repository shall issue and send, in any form whatsoever, a response stating the reason, and such response can be challenged by its recipient in court.

7. ELECTRONIC COMMUNICATION

7.1. General Provisions

7.1.1. In the course of Repository Services, the Repository and Participants shall maintain electronic communication via the NSD EDI System and/or SWIFT system in the manner set out in the EDI Agreement, subject to the provisions hereof.

7.1.2. For the purpose of electronic communication with Participants via the NSD EDI System in the course of repository operations, NSD shall use the following electronic message formats:

XML — the eXtensible Markup Language that defines a set of general syntax rules recommended by World Wide Web Consortium. XML is a text format designed for storing structured data and exchanging data between applications;

FpML – the Financial products Markup Language based on the Extensible Markup Language (XML). FpML is an XML protocol that supports electronic commercial transactions in the financial market. FpML is used to exchange information on

57

derivative transactions, exchange transaction confirmations, change terms and conditions of transactions, etc., as well as to communicate information on OTC derivative transactions in the global market, and to communicate information on portfolio valuations and reports on such transactions to national regulators. In the future, all types of OTC derivatives are expected to be covered by this standard;

PDF (Portable Document Format) — a cross-platform format of electronic messages which is created by Adobe Systems using a number of PostScript language capabilities. With effect from 1 July 2008, PDF is an open ISO standard (ISO 32000). The PDF format allows one to implement necessary fonts (interlinear text), bitmap (raster) and vector images, forms, and multimedia;

DBF (dBase-file) — a data storage format used as a standard method for data storage and retrieval by database management systems, spreadsheets, etc. A DBF file consists of a header section for describing the structure of the data and the number of the entries in the file, and the data storage area in the form of a sequentially arranged table containing fixed-length entries, which, in turn, are divided into fixed-length fields.

7.1.3. Electronic documents interchanged between the Repository and Participants in the course of electronic communication hereunder shall be issued in the above formats in accordance with the specifications set out in the NSD EDI Rules.

7.1.4. The Repository may, at its own discretion, make changes to the list of formats or to the specifications of electronic documents being used in connection with Repository Services by giving notice to Participants in accordance with these Rules and the NSD EDI Rules.

7.1.5. To view and print out electronic documents received via the NSD EDI System and/or SWIFT system (to display an electronic copy of a hard-copy document), Participants may use the NSD EDI System Local Interface and/or standard software.

7.1.6. Where the operation of any communication channel is interrupted due to any technical reason, it shall be allowed to interchange electronic documents using other channels selected by the Repository and the Participant in accordance with the EDI Agreement and these Rules until the operation of the interrupted communication channel is resumed.

7.1.7. Where it becomes impossible to maintain electronic communication between a Participant and the Repository for any reason whatsoever, the Parties may, if necessary, start interchanging documents in hard copy, in forms set out herein, on a temporary basis, until the causes on electronic communication interruption are remedied.

7.1.8. Documents in hard copy shall be submitted and received at the Repository’s office under the applicable powers of attorney and a Report Handover Certificate (Form RM008 in Appendix 1 hereto).

7.2. Electronic Communication via the NSD EDI System

7.2.1. The issuance, transmission, acceptance, and processing of electronic documents via the NSD EDI System shall be performed in accordance with the EDI Agreement and these Rules. For the purpose of electronic communication via the NSD EDI System, the Repository and Participants may use E-mail and/or Web channels (Web-service and/or Web-client).

58

7.2.2. In addition to internal electronic documents listed in the EDI Agreement, Participants and the Repository may issue, in electronic format, and send to the other Party (via the NSD EDI System) documents listed in the NSD EDI Rules. The first character in the name of the file containing an electronic document (or of the file containing an electronic document package) shall be “F”.

7.2.3. In all other respects, files containing an electronic document (or files containing an electronic document package) shall be named in accordance with the general requirements set out in the EDI Agreement.

7.2.4. The following categories of electronic documents shall be used:

electronic documents issued by a Participant – category “Г”; and

electronic documents issued by the Repository – category “В”.

7.2.5. The Repository shall send electronic documents to a Participant at an e-mail address(es) designated by the Repository under the EDI Agreement for the purpose of receipt of Repository’s reports, as well as via Web-client.

7.2.6. The Repository shall ensure the possibility of receipt of such documents via the Web-service.

7.2.7. The authority to sign electronic documents in the NSD EDI System shall be determined by a Participant in accordance with the EDI Agreement.

7.3. Electronic Communication via Web Channels

7.3.1. A Participant shall communicate with the Repository via Web channels, using Web-service and/or Web-client, in the manner set forth the EDI Agreement, these Rules, Web-client User Manual and Web-service User Manual.

7.3.2. The URL addresses of the Web-service and Web-client to be used by the Repository and a Participant for the purpose of communication via Web channels are specified in the NSD Details Form for EDI purposes posted on NSD’s official web site.

7.3.3. A Participant who meets the conditions set forth for the maintenance of electronic data interchange with NSD via the NSD EDI System under the EDI Agreement shall be granted access to Web-service.

7.3.4. To receive the right to use NSD’s software for electronic communication with the Repository, a Participant shall enter into a license agreement with NSD.

7.3.5. For the purposes of electronic communication with the Repository via Web Service, a Participant may use the File Gateway, a dedicated software package that ensures automated transmission of a Participant’s messages to the Repository and receipt of Repository’s documents (the “File Gateway”). Where cryptographic tools are available, the File Gateway performs cryptographic processing of outgoing and incoming messages.

Repository’s messages will be downloaded from Web-service automatically in accordance with the settings of the File Gateway download timer. Each downloaded message will be processed in accordance with the particular rules depending on the message type. The procedure for getting access to, installing, setting, and using the File Gateway is described in the File Gateway User

59

Manual. The distributive package and the user manual for the File Gateway are available on NSD’s official web site.

7.3.6. A Participant shall be:

responsible for ensuring that only Participant’s authorized representatives have access to the Web channels;

responsible for ensuring the security of any passwords and logins and ensuring the secure use of cryptographic tools and cryptographic keys being used by Participant’s authorized representatives to access the Web channels; and

liable for any and all actions by Participant’s authorized representatives when interacting with the Repository via the Web channels.

7.3.7. Where a Web channel is accessed by a Participant’s authorized representatives using any password, login, cryptographic tools, or cryptographic keys, the Web channel shall, in any case, be deemed to have been accessed by the Participant; and any electronic documents sent/received via the Web Channel shall be deemed to have been sent/received by the Participant.

7.3.8. The Repository will not be liable for any losses sustained by a Participant as a result of any unauthorized use of any password, login, cryptographic tools, or cryptographic keys.

7.3.9. Participants shall communicate with the Repository via a Web channel using electronic signatures and encryption. Specific procedures for using electronic signatures and encryption shall be set out in the relevant user manuals.

7.3.10. Electronic documents and messages to be sent by a Participant or the Repository via a Web channel shall be issued in formats and in accordance with specifications prescribed by the NSD EDI Rules and these Rules.

7.3.11. Any information received via a Web Channel and displayed on a screen shall be used for reference only and shall not have any legal implications (including if printed out).

7.3.12. At night time (from 10.00 pm to 6.00 am Moscow time), the Repository may conduct scheduled works resulting in communication via a Web channel being impossible.

7.4. Electronic Communication via the SWIFT System

7.4.1. For the purposes of electronic communication via the SWIFT System, the Repository and a Participant shall use the SWIFTNet FileAct service in accordance with the SWIFT Rules and subject to the provisions of the EDI Agreement and this section.

7.4.2. A Participant interacting with SWIFT shall subscribe to the SWIFTNet FileAct service.

7.4.3. Electronic documents to be transmitted via the SWIFT System shall be issued in the same manner, in the same formats, and in accordance with the same specifications, as are applicable to transmission of electronic documents via the NSD EDI System, excluding cryptographic processing (i.e., without using electronic signatures and encryption). Cryptographic processing of electronic messages being transmitted shall be performed by SWIFT, and SWIFT shall ensure authorship, integrity, and confidentiality of such electronic messages.

60

7.4.4. For the purposes of communicating with the Repository via the SWIFTNet FileAct service, electronic document packages shall be issued and transmitted in the manner set forth by the EDI Agreement, excluding cryptographic processing.

7.4.5. To send messages to the Repository via the SWIFT System, a Participant shall issue repository messages in the form of a single zip file being referred to as a repository package. A repository package shall contain all messages being sent to the Repository. The following rules shall apply:

if a repository message is transmitted without a scanned image, the xml file corresponding to the message shall be included in the repository package without preliminary processing;

if a repository message is transmitted together with a scanned image, the xml file corresponding to the message and containing the scanned image file shall be zipped and the resulting zip file shall be included in the repository package.

7.4.6. Participants and the Repository shall communicate via the SWIFTNet FileAct service using the following BIC of the Repository: MICURUMM.

7.4.7. The following Message Identifier shall be specified for all messages transmitted to the Repository via the SWIFTNet FileAct service: 'defp.xxx.nsd.rpz'.

61

Appendix 1

to NSD’s Rules for the Provision of Repository Services

Forms of Messages to Be Submitted in Hard Copy or in Electronic Format in the Course of Data Interchange with the Repository

1. Forms of Messages Addressed to the Repository

62

63

Document Type Form Code

Master Agreement Reporting Form CM010

Master Agreement Termination Reporting Form СМ011

Credit Support Annex Reporting Form СМ015

FX Swap Contact Form CM021

Foreign Exchange Spot Transaction Form CM022

Currency Option Form CM023

FX Digital Option Form CM024

Forward Rate Agreement Form CM031

Interest Rate Swap Form CM032

Interest Rate Collar Form CM033

Swaption Form CM034

Repo Form CM041

Bond Spot Transaction Form CM042

Bond/Index Forward Form CM043

Bond Option Form CM044

Index/Bond Basket Option Form CM045

Equity Simple Transaction Form CM046

Equity Forward Form CM047

Equity Option Form CM048

Commodity Forward Form CM051

Commodity Option Form CM052

Commodity Swap Form CM053

Commodity Swaption Form CM054

Bond Return Swap Form CM061

Equity Return Swap Form CM062

Credit Default Swap Form CM071

2. Forms of Messages Sent by the Repository

Document Type Form Code

Registration Advice RM001

Registration/Execution Rejection Advice RM002

Reporting Form Status Advice RM003

Excerpt from the Contracts Register RM004

Confirmation Request RM005

Notification of Reporting Form Discrepancies RM006

Pending Status Advice RM007

Electronic Format Report Handover Certificate (hard copy only)

RM008

Excerpt from Section 1 of the Contracts Register (the Messages Log)

RM009

Reporting Agent Resignation Notification RM010

64

3. Forms of Messages to Be Submitted in Hard Copy

65

Код формы СМ005/Form СМ005

ЗАПРОС на предоставление отчетных документов Репозитария в электронной форме / REQUEST for Repository’s Reports in Electronic Format

«___» ____________ 20__

Параметры документа / Details of the document

Отправитель / Sender:

Репозитарный код / Repository code Краткое наименование / Short name

Получатель / Receiver:


Исходящий номер запроса/Outgoing reference number of the request:Дата формирования/ Date of preparation

Просим предоставить дубликаты отчетных документов из Реестра договоров Репозитария / Please provide duplicates of reports from the Contracts Register maintained by the Repository

За дату / for the date Дата / Date: ___________________________________

За период / for the period Период / Period: с (from) _____________ по (to) ____________

(Должность / Title) (ФИО / Full name) (Подпись / signature)

м.п. / l.s.

ОТМЕТКИ РЕПОЗИТАРИЯ / REPOSITORY’S NOTES:

Заполняется уполномоченным лицом Репозитария / to be filled out by the authorized representative of the Repository

Рег. номер документа / Document registration number

Дата ввода документа / Document entry date:

Дата приема документа / Document receipt date

Время приема документа / Document receipt time

Уполномоченное лицо / Authorized representative


Извещение о регистрации/отказе № / Registration /Rejection Advice

No.

Дата / Date: « » :

Подпись / signature

66

Код формы CM006/Form CM006

(оформляется на бланке организации / to be printed on the company’s letterhead)

ЗАЯВКА на присвоение Идентификационного кода Репозитария / Application for Identification Code Assignment

«___» ____________ 20__ «_______________________________________________________________

_________ (полное наименование организации / Ф.И.О физического лица / full name of the company / surname,

first and, patronymic of the individual) ________________________________________________________________

________, именуем___ в дальнейшем «Участник», прошу / hereinafter referred to as

the “Participant” hereby requests: использовать коды / to use the following codes:

Идентификационный код / Identification Code

(заполняется Участником / to be filled out by the Participant)

Назначение / Purpose*


67

присвоить мне новые Идентификационные коды / to assign to me new Identification Codes: Идентификационный

код / Identification Code (заполняется НКО АО НРД / to be filled

out by NSD)



68

Участник / Participant

________________ ___________________________________(Подпись / signature) (фамилия, инициалы / surname and initials)

м.п. / l.s.ОТМЕТКИ РЕПОЗИТАРИЯ / REPOSITORY’S NOTES:

Заполняется уполномоченным лицом Репозитария / to be filled out by the authorized representative of the Repository Рег. номер документа / Document registration number






Подпись / signature Подпись / signature

Извещение о регистрации/отказе № /

Registration / Rejection Advice No.

Дата / Date:

«

»

Контролер / Controller:


69

*Указывается, в каких случаях использовать данный код для идентификации Участника в сообщениях Репозитария / Specify in which cases the identification code is to be used for the identification of the Participant in the Repository’s messages

Код формы CM007/Form CM007 (оформляется на бланке организации / to be printed on the company’s letterhead)

ЗАЯВКА на изменение назначения Идентификационного кода Репозитария / Application for Identification Code Purpose Change

«___» ____________ 20__

«________________________________________________________________________

(полное наименование организации / Ф.И.О физического лица / full name of the company / surname, first and, patronymic of the individual)

________________________________________________________________

________, именуем___ в дальнейшем «Участник», прошу изменить назначение

Идентификационного (-ых) кода (-ов), присвоенного (-ых) ранее Репозитарием / hereinafter referred to as the “Participant” hereby requests to change the purpose of the Repository Identification code(s) previously assigned by the Repository:

Идентификационный


out by NSD)



70













Дата / Date:

«

»




71

Код формы RM008/ Form RM008

Акт приема-передачи отчетных документов Репозитария в электронной форме /Electronic Format Report Handover Certificate

«___» ____________ 20__

Мы, нижеподписавшиеся / We, the undersigned


именуемый в дальнейшем Клиент, и Репозитарий, составили настоящий акт о том, что Клиент принял, а Репозитарий передал в полном объеме дубликаты отчетных документов, сформированные в соответствии с запросом № ____ от / dated ___________. / hereinafter referred to as the “Client”, and the Repository have executed this certificate to confirm that the Client has accepted and the Repository has handed over all duplicates of the reports prepared pursuant to Request No. ___ dated ____ .

Данный акт составлен в двух экземплярах, по одному экземпляру для каждой из сторон. / This certificate is made in two copies, one for each party.

От Клиента / For the Client От Репозитария / For the Repository

________________________________ ______________________________ (Подпись / signature) (Подпись / signature)

м.п. / l.s.

72

Код формы CM007/Form CM007 (оформляется на бланке организации / to be printed on the company’s letterhead)

ЗАЯВКА на изменение назначения Идентификационного кода Репозитария /

Application for Identification Code Purpose Change

«___» ____________ 20__

«_____________________________________________________________________

(полное наименование организации / Ф.И.О физического лица / full name of the company / surname, first and, patronymic of the individual)

________________________________________________________________

______, именуем___ в дальнейшем «Участник», прошу изменить назначение

Идентификационного (-ых) кода (-ов), присвоенного (-ых) ранее Репозитарием / hereinafter referred to as the “Participant” hereby requests to change the purpose of the Identification code(s) previously assigned by the Repository:

Идентификационный


out by NSD)



73













Дата / Date:

«

»




74

Код Формы СM009/ Form СM009

(оформляется на бланке организации / to be filled on the company’s letterhead)Заявка на приостановление использования Идентификационного кода/ Application for Identification Code Use Discontinuance

«_______»_____________ 201____г.

(полное наименование организации full name of the company / surname, first and patronymic name of the individual)

именуем___ в дальнейшем «Участник», прошу: / hereinafter referred to as the ‘Participant’ hereby requests:

□– не использовать код указанный в заявке на присвоение идентификационного кода от _____ №_____ Идентификационный код Участника- not to use the code indicated in Application for Identification Code Assignment No. ___ dated ______ (Participant’s Identification Code)

Идентификационный код / Identification code *(заполняется участником / to be filled out by the Participant)

при взаимодействии по внесению сведений в Реестр договоров Репозитария по новым генеральным соглашениям и договорам, а также исключить информацию об этом коде из Справочника Участников*/- for the purpose of making data entries in the Repository’s Contracts Register regarding new master agreements and contracts and delete the above code from the Participants Reference Guide.*.


(подпись Участника / signature of the Participant) (фамилия, инициалы / surname and initials)м.п. / l.s.

Отметки Репозитария / Repository’s notes:

(заполняется уполномоченным лицом Репозитария / to be filled out by the authorized representative of the Repository)

Регистрационные номер документа / Document registration number

Дата ввода документа / Document entry date





подпись / signature подпись / signature

Извещение о регистрации / отказе №Registration / rejection advice No. Дата / Date:Контролер / Controller:

подпись / signature*Исключение Идентификационного кода Участника из Справочника Участников происходит не ранее, рабочего дня, следующего за днем получения Репозитарием документа /*The Participant’s Identification Code will be deleted from the Participants Reference Guide no earlier than the business day following the receipt by the Repository of the document .

75

(оформляется на бланке организации / to be filled on the company’s letterhead)

Код Формы СM012/ Form СM012

«_____»___________201___г.

Уведомление об отказе от предоставления сведений в Репозитарий / Reporting Refusal Notification

Исх. № ____ от ____ ____________________ 201__ / Ref. No. ____ dated ___________

(полное наименование организации / Ф.И.О. физического лица /full name of the company / surname, first and patronymic name of the individual)

Договор об оказании репозитарных услуг (номер и дата)*: /Repository Services Agreement (date and number)*:

именуем___ в дальнейшем «Участник», /hereinafter referred to as the ‘Participant’ hereby informs NSD Repository that the Participant refuses to submit information on contracts to NSD Repository.

Настоящим информирует Репозитарий НКО АО НРД об отказе от предоставления сведений о договорах в Репозитарий НКО АО НРД.

The Participant agrees that the information on this refusal will be disclosed to Repository’s other clients through the Participants Reference Guide and NSD’s website (www.nsd.ru) in accordance with Appendix 7 to the Rules for the Provision of Repository Services by NSD.

Участник выражает свое согласие с тем, что информация о настоящем отказе будет доведена до других клиентов Репозитария путем размещения в Справочнике Участников и на сайте НКО АО НРД по адресу: (www.nsd.ru) в сети Internet, в соответствии с форматом, установленным Приложением 7 к Правилам осуществления репозитарной деятельности НКО АО НРД.


(подпись Участника / signature of the Participant)

(фамилия, инициалы / surname and initials)

м.п. / l.s.

* Указывается дата и номер Соглашения об условиях оказания репозитарных услуг, если последнее было заключено до 27.06.2016 / Specify the date and number of the Agreement on the Terms and Conditions for the Provision of Repository Services if it was entered into before 27 June 2016.

76

Код формы СM013/ Form СM013

Уведомление об отмене документа / Document Cancellation Notification

(полное наименование организации/full name of the company)

Настоящим сообщаем об отмене (отзыве) следующего документа/Hereby we inform that we cancel (revoke) the following document

Наименование документаDocument name

Исх. №Ref. No.

ДатаDate

Дополнительная информация

Additional information

_____________________ _____________________ _________________(должность) (title) (Ф.И.О) (name) М.П.(stamp) (подпись)(signature)

Действует на основании:_______________________________________________________Acting on the basis:

Контактное лицо: (Contact person)Ф.И.О. (name)Телефон (phone)

Отметки Репозитария / Repository’s notes Вх. номер: Ref No. Дата ввода:

Entry date Дата регистрации: Registration date

“___” ___________ 20___ г. Время ввода: Entry time

Время регистрации:Registration time

Подпись (Signature) Подпись (Signature)

77

(оформляется на бланке организации / to be filled on the company’s letterhead)

Код формыСM014/ Form СM014

Уведомление о намерении расторгнуть Договор об оказании репозитарных услуг/ Notification of Repository Services Agreement Termination

Исх. № ____ от ____ ____________________ 201__Ref No. dated

(полное наименование организации / Ф.И.О. физического лица /full name of the company / surname, first and patronymic name of the individual)

LEI код/ СНИЛС (для физического лица) LEI code /Personal Pension Account NumberДоговор об оказании репозитарных услуг (номер и дата): /Repository Services Agreement (date and number):

именуем___ в дальнейшем «Участник», /hereinafter referred to as the ‘Participant’ Прошу расторгнуть со мной Договор об оказании репозитарных услуг .

hereby requests to terminate the Repository Services Agreement entered into with the Participant.

Настоящим подтверждаю, что в соответствии с действующим законодательством являюсь лицом, не обязанным предоставлять информацию в Репозитарий

The Participant hereby confirms that the Participant is a person not obliged to report information to the Repository under the effective laws.


(подпись Участника / signature of the Participant)

(фамилия, инициалы / surname and initials)

м.п. / l.s.

78

Appendix 2


Guidelines on Completion of Message Forms to Be Sent to the Repository

1. Completion of Common Fields in Messages to Be Sent to the Repository

1.1. Rules of Completion of Fields Containing Information on a Message

Data Field Mandatory / Optional /

Conditionally Mandatory

Completion Rules

Message identifier M A unique identifier assigned to the message by the message sender. No more than 35 characters (digits and Latin characters).

Message sender M Message sender’s Repository Code. Taken from the external Participants Reference Guide.

Message receiver M Message receiver’s (NSD Repository’s) Repository Code. Always NDC000000000.

Message creation time

M Message creation date and time. The difference between the permitted date of message receipt by the Repository and the date of message creation by the Participant must not exceed 3 business days. Format: "YYYY-MM-DDThh:mm:ss".

Specification version

M Version of the Repository’s message format specifications underlying the message. The last version, as per the reference guide, must be specified.

Correction message mark

M “True/false” flag indicating whether the current message corrects an earlier message. “False” is to be used by default for new messages.

Related document reporting form reference number

O The reference number of the Master Agreement Reporting Form assigned by its sender. To be completed in a Contract Reporting Form if the Master Agreement Reporting Form and the Contract Reporting Form (for a Contract made under such Master Agreement) are submitted for registration at the same time, i.e., if there is no registered Master Agreement Reporting Form currently available. This field must contain <correlationId> of the Master Agreement Reporting Form created earlier. A normalize-space character string.

Messages chain identifier

M An identifier intended to link several messages (to indicate that such messages relate to the same business process).Identifier format: [sender’s Repository code]-[year]-[message identifier].This identifier must be specified for the first time in a message sent for initial registration of a Contract Reporting Form, and then must be repeated in each subsequent message responding to the initial message (CM001, CM002, CM003, RM001, etc.).

79

1.2. Rules of Completion of Fields Containing Common Parameters of a Contract / Master Agreement / Report in Messages to be Sent to the Repository

Event’s actual date M Date of the event being reported:For initial registration of a Contract/Master Agreement: the date of the Contract/Master Agreement – (tradeDate);For registration of amendments to a Contract/Master Agreement: date of amendments (supplemental agreements) to the Contract/Master Agreement – (agreementDate);For registration of a Master Agreement Termination Reporting Form: the termination date of the Master Agreement – (endAgreementDate);For registration of a Contract Obligation Status Reporting Form: the date of the event (e.g., execution T);For registration of a Credit Support Transfer Reporting Form: the last business day of the reporting month;For registration of a Mark to Market Valuation Reporting Form: the last business day of the reporting month.Format: "YYYY-MM-DD".

Registration number assigned by the Participant

M A group of elements including the Registration Numbers assigned by the Repository, Party 1, Party 2, and UTI Generating Party.

Participant M The identifier of a Party who has assigned the Registration Number to the Master Agreement/Report: “TradeRepository”, “Party1”, “Party2”, “UTIGeneratingParty”.

Registration number M The Contract / Master Agreement / Report Registration Number assigned by the Participant named in the ‘Participant’ field. If the Registration Number assigned by the Participant is unknown, or if the Registration Number to be assigned by the Repository is not yet assigned (in the event of initial registration), indicate “NONREF”. When sending a message regarding any changes made, this Registration Number must be indicated in accordance with the relevant Registration Advice.

Master Agreement Registration Number

CM The Master Agreement Registration Number intended to link messages regarding a Contract made under such Master Agreement. Indicate the Master Agreement Registration Number assigned by the Repository in accordance with the relevant Registration Advice. To be completed only in the group that describes the Registration Number assigned by the Repository.

Credit Support Annex Registration Number

CM The Credit Support Annex Registration Number assigned by the Participant named in the ‘Participant’ field. If the Registration Number assigned by the Participant is unknown, or if the identifier to be assigned by the Repository is not yet assigned (if Form CM015 is not yet registered), indicate “NONREF”. When sending a message regarding any changes made, this Registration Number must be indicated in accordance with the relevant Registration Advice (RM001).

Reporting regime name

O In the current specifications, always "RussianFederation".

Contract made other than under a Master Agreement

CM “True/false” flag indicating whether the Contract is made other under a Master Agreement.

Trade venue O The trade venue. Taken from the external reference guide.Trade date M Date of the Contract/Master Agreement. Format: "YYYY-MM-DD".

For registration of amendments to the Contract/Master Agreement – initial date of the Contract/Master Agreement.

80

Scanned image file name

CM Document name corresponding to the name of the pdf file attached. Must be specified if a document is attached to the Reporting Form. A character string.

Collateral type for the trade

M Collateral type for the Contract (margin requirements) pursuant to a Floating Margin Payment Agreement as per the reference guide. If no Floating Margin Payment Agreement exists, include character ‘U’ indicating that no Floating Margin Payment Agreement has been entered into.

Form of collateral M Collateral form for the Contract pursuant to a Floating Margin Payment Agreement as per the reference guide. If no Floating Margin Payment Agreement exists, include character ‘U’ indicating that no Floating Margin Payment Agreement has been entered into.

In-portfolio date O The date when the Contract was included in a contract portfolio. Format: "YYYY-MM-DD". Omit this field, if not applicable.

Out-of-portfolio date O The date when the Contract was excluded from a contract portfolio (Credit Support Annex). Format: "YYYY-MM-DD". Omit this field, if not applicable.

Broker code O If the trade is made through a broker, and the broker is not a party to the trade, indicate the broker’s LEI. Omit this field, if not applicable.

Central clearing requirement

M Central clearing requirement:Y – central clearing is required for the Contract;N – central clearing is not required for the Contract.

Clearing organization code

CM Must be completed, if the trade is to be settled upon simple clearing. Indicate the clearing organization’s LEI.

Cleared date CM Date when the Contract obligations were included in a clearing pool. Format: "YYYY-MM-DD".

Clearing date and time

O Contract clearing date and time, as recorded in Section 1 of the Contracts Register. Format: "YYYY-MM-DDThh:mm:ss".

CCP code CM Must be completed, if the trade is to be settled upon central clearing. Indicate the CCP’s LEI.

Clearing participant code

CM Indicate the clearing participant’s LEI.

Cleared date CM Date when the Contract obligations were included in a clearing pool. Format: "YYYY-MM-DD".

Clearing date and time

O Contract clearing date and time, as recorded in Section 1 of the Contracts Register. Format: "YYYY-MM-DDThh:mm:ss".

Reconciliation type M Reporting Form reconciliation type as per the reference guide.<FULL> means that reconciliation must be made for all data fields.<GENF> means that reconciliation must be made for general fields only.

Settlement type M Type of settlements under the Contract as per the reference guide.Settlement method M Method of settlements under the Contract as per the reference guide.Reporting Form confirmation method

M Reporting Form confirmation method as per the reference guide.

Party 1 and Party 2 Affiliation

CM To be completed if Party 1 and Party 2 are affiliated, as per the reference guide.

Trade regulatory type O Contract type as per the reference guide.Contract start date CM Indicate the date defined by the parties as the “Contract effective

date”. Format: "YYYY-MM-DD". Omit this field, if not applicable.Contract end date CM Indicate the expiry date of the Contract. Format: "YYYY-MM-DD".

If the Contract provides for a potential extension that can be triggered by a certain circumstance or event, such extension period shall be disregarded when indicating the Contract end date.

Information about a Party’s client

M A group of elements that describe information on Parties’ clients. This group is a repetitive, i.e., it must be completed for each party

81

(Party 1 and Party 2) to the Contract.Party servicing a client

M Identifier of the Party to the Contract: “Party 1” or “Party 2”. This identifier identifies the Party information on whose client is provided in the ‘Information about a Party’s client’ group.

Own party trade CM Always ‘true’ if the client type specified in the ‘Party servicing a client’ field is N, meaning that the Contract is made not in the interests of a client.

Client type CM A Party’s client type, as per the reference guide.

Client identifier CM The identifier of the client of a party to the Contract, which allows to unambiguously identify the client. To be completed in accordance with the identification rules.

Client name CM A party’s client’s short name in Russian or English (official corporate name or individual full name).

Client’s country code CM A client’s country code as per the client’s registered office address. The code is to be taken from the reference guide as per the ISO 3166 standard. To be taken from the external reference guide.

Information on a person in whose interests the Contract is made is unavailable

CM This field can be completed in the event of unilateral registration. Always ‘true’. Otherwise, this field must be omitted.

Reporting Form Parties

M A group of elements that identify the parties to the Reporting Form being submitted: "TradeRepository", "Party 1", "Party 2", "Sender", and "UTIGeneratingParty".

Party identifier M The identifier of the relevant party to the Contract. To be repeated twice for each party ("TradeRepository", "Party 1", "Party 2", "Sender", "UTIGeneratingParty"). The first identifier must be the Repository Code taken from the Participant Reference Guide. If a party is not a Repository’s client, indicate “NONREF”. The second identifier must be an additional code as per the identification rules.

Party name M A short corporate name or an individual’s last name, first name, and patronymic name (if any), in Russian or English.

Industry classification

CM A Party’s industry classification. To be completed for “Party 1” and “Party 2” only, as per the reference guide.

Country CM A Party’s country code as per the Party’s registered office address. The code is to be taken from the reference guide as per the ISO 3166 standard. To be completed for “Party 1” and “Party 2” only.

Party type CM A Party type. To be completed for “Party 1” and “Party 2” only, as per the reference guide.

2. Rules of Completion of Special Fields in Messages to be Sent to the Repository

Special fields in messages to be sent to the Repository shall be completed in accordance with the requirements set out in the Financial Market Regulator’s regulations (guidelines).

82

Appendix 3


DECLARATION OF ACCESSION TO THE RULES FOR THE PROVISION OF REPOSITORY SERVICES

The City of ___________ Date: __ _______ 20__

______________________________________________________________________________________________________(Client's full name as per the Articles of Association/Charter)

represented by __________________________________________________________________________________________ acting under _________________________________________________________________ (the “Client”), in accordance with article 428 of the Russian Civil Code, hereby fully and unconditionally accedes to the Rules for the Provision of Repository Services by National Settlement Depository (the “Rules”) and agrees to comply with the requirements of the Repository Services Agreement (the “Agreement”)1, starting from the date of acceptance of this Declaration by National Settlement Depository (the “Repository”).

By signing this Declaration, the Client acknowledges that the Client has:

read the requirements of the Rules and accepts the procedure for the provision of repository services;

read the Repository’s Fee Schedule.

The Client shall be deemed to have acceded to the Rules / to have entered into the Repository Services Agreement with effect on the registration date of this Declaration by the Repository.

This Declaration marked by the Repository as registered constitutes a document evidencing the entering into the Agreement.

The Client:

Registered office: _________________________________________________________________________

Address for correspondence:______________________________________________________________

Principal State Registration Number (OGRN):_________________________

Taxpayer Identification Number (INN): ________________________

Tax Registration Reason Code (KPP): _____________________

LEI: _____________________

Current account No.:_________________________________ with __________________________________________

Correspondent account No.:___________________________________ BIC:_________________________________

Contact telephone number:_______________________________________________________________________

E-mail:______________________________________________________________________

________________________________ ______________ /_________________________________________/ (position) (signature) (full name) Seal

To be completed by the Repository (in the event of entering into the Repository Services Agreement):(to be completed by NSD’s authorized employee)

This Declaration is registered by NSD on _____ _______________20__._____________________ _____________________ ________________________________ (position) (signature) (full name)

1 The Repository Services Agreement comprises this Declaration of Accession and the Rules for the Provision of Repository Services.

83