NASDAQ CSD SERVICE DESCRIPTION

Transcription

1 NASDAQ CSD SERVICE DESCRIPTION

2 Please note that the service description is provided to the stakeholders of the Nasdaq CSD for information purposes and document does not establish the procedures of the services provided by the CSD to their participants. The CSD reserves the right to revise and update this document from time to time in order to document the availability of new products and other improved services. 1

3 Document Revisions Version Date Version history st version Annual review version 1.3 2

4 Content plan Abbreviations... 6 Introduction Nasdaq CSD Nasdaq CSD securities account structure... 7 Nasdaq CSD participants Account operator Cash agent Issuer agent Fund administrator Nasdaq CSD participants in T2S T2S connectivity options Directly connected party Indirectly connected party Account management Securities account opening and maintenance Securities account types in Nasdaq CSD Notary and central maintenance services Registration of financial instruments Maintenance of financial instruments Corporate actions Clearing and Settlement Settlement instruction types Parties related to settlement instruction Settlement instruction linkage Settlement priority Settlement instruction lifecycle Input Trade capture Validation Matching Tolerance matching Allegement Removal of an allegement notification Cancellation of an allegement

5 6.4.5 Maintenance of settlement instruction Amendment Hold/Release Cancellation Recycling Portfolio transfer Open-ended fund units Subscription of fund units Redemption of fund units Swap of fund units Settlement process in T2S Partial settlement Conditional settlement Nasdaq CSD operational day with T2S Settlement process outside T2S Technical netting Settlement optimization Holidays Cross-border links Restrictions Blocking Pledging securities balance on an account Pledging a securities account Cash management Cash settlement in T2S Dedicated cash accounts Link between DCA and RTGS account Link between DCA and Securities Account Credit Memorandum Balance DCAs cash management T2S auto-collateralisation Cash settlement outside T2S Cash forecasts Cash forecast from CSD system T2S cash forecast

6 Reporting Report subscriptions Queries Message subscriptions Market specificities Securities holders disclosure Latvian Initial Register Non-T2S eligible securities settlement Deposit account Account opening Securities transfer (portfolio transfer) from deposit account Selling securities from deposit account Pledging of securities on deposit account Screening of deposit account owners Closing of deposit account ANNE 1 Transaction types eligible for allegement process ANNE 2 Overview of availability of main functionality in the CSD system s GUI and A2A mode ANNE 3 Table of ISO20022 messages ANNE 4 T2S settlement flow ANNE 5 Local settlement flow (both counterparties in Nasdaq CSD)

7 Abbreviations Abbreviation Explanation ANNA Association of National Numbering Agencies BIC Bank Identification Code CAJWG Corporate Actions Joint Working Group CB/NCB Central Bank/National Central Bank CeBM Central Bank Money CFI Classification of Financial instrument CMB Credit Memorandum Balance CoBM Commercial Bank Money CoSD Conditional Settlement CSD Central Securities Depository. The CSD throughout the document refers to the Nasdaq CSD CSDR Regulation (EU) No 909/2014 on securities settlement and on Central Securities Depositories DCA Dedicated Cash Account DCP Directly Connected Party EOD End of Day FATCA Foreign Account Tax Compliance Act GIIN FATCA Global Intermediary Identification Number GUI Graphical User Interface ICP Indirectly Connected Party ICSD International CSD ISD Intended Settlement Date MQ Message Queue Nasdaq CSD Nasdaq Central Securities Depository in Baltic NNA National Numbering Agency. The organization in each country responsible for issuing ISINs NTS Night-time Settlement OTC Over-the-counter or off-exchange Trading PM Payment Module (TARGET2) PoA Power of Attorney RTGS Real-time gross settlement SME Security Maintaining Entity SMPG Securities Market Practice Group STP Straight-through Processing T2, TARGET2 Pan-European real-time gross settlement (RTGS) payment system owned and operated by the Eurosystem (Trans-European Automated Real-time Gross settlement Express Transfer system) T2S, TARGET2- Pan-European platform for securities settlement, operated by the Eurosystem Securities T2S UDFS T2S User Detailed Functional Specifications CSD system CSD system throughout the document refers to the CSD s securities clearing, settlement and registry system 6

8 Introduction This service description gives a general overview of the CSD system s functionality and services provided by the CSD. This document is addressed to participants of the CSD. The service description includes the following areas: Account management, Notary and central maintenance services, Corporate actions, Clearing and settlement, Stock exchange trade capture Cash management, Participation types, CSD business with T2S, Market specificities. Please note that the processes and functionality described in the service description do not include a description of the ancillary systems interfacing with the CSD system. All times indicated in this document are in Baltic local time zone (CET+1), unless stated otherwise. 1.1 Nasdaq CSD The Nasdaq CSD SE (registration No ) was established in 2017 as a result of the cross-border merger of the three former Baltics CSDs: Akciju sabiedrība "Latvijas Centrālais depozitārijs" (the Latvian depository) in the Republic of Latvia; AS Eesti Väärtpaberikeskus (the Estonian depository) in the Republic of Estonia; and Lietuvos centrinis vertybinių popierių depozitoriumas (the Lithuanian depository) in the Republic of Lithuania. Nasdaq CSD completed the reauthorization of the new entity under the CSDR, accomplished full IT replatforming and connected to T2S as well as launched new CSD operating model. Local businesses and client servicing are ensured in all three countries. There is one IT platform for the participants of the CSD, meaning that interactions between the CSD system and CSD participants are centralized and are not bounded by geographical location. 1.2 Nasdaq CSD securities account structure The Nasdaq CSD participant s operational account (securities account), opened in the CSD system, displays, in a consolidated manner, the balance of all legal accounts associated with it within one or more SSSs. The Nasdaq CSD plans to accommodate a variety of combinations of legal accounts to enable the SSSs to make up one securities account, but in all cases a securities account may contain an aggregation of legal accounts of only one type either segregated nominee legal accounts, or nominee legal accounts, or owner legal accounts, see Figure 1 below. 7

9 CSD system Participant A Nominee account (operational account #1) EE ISIN1 EE ISIN2 LV ISIN1 LV ISIN2 LT ISIN1 LT ISIN2 Participant B Owner account (operational account #2) EE ISIN1 EE ISIN2 LV ISIN1 LV ISIN2 Participant C Omnibus account (operational account #3) LV ISIN1 LV ISIN2 T2S Participant A Nominee account (operational account #1) EE ISIN1 EE ISIN2 LV ISIN1 LV ISIN2 LT ISIN1 LT ISIN2 Participant B Owner account (operational account #2) EE ISIN1 EE ISIN2 LV ISIN1 LV ISIN2 Participant C Omnibus account (operational account #3) LV ISIN1 LV ISIN2 T2S holds mirror of all participant accounts specified in CSD system (above) Figure 1: Overview of operational account structure in Nasdaq CSD Only the legal account of a participant within a certain SSS can establish a legal entitlement of that participant towards a security (whether an ownership entitlement or a custody holding entitlement for the benefit of a client). One legal account can only be associated with one securities account in the same category as the legal account. The identification of a legal account consists of: the number of the relevant securities account, and the ISIN of the relevant security held on that legal account (which is used to attribute the securities to the legal account that is a part of EE SSS, LV SSS or LT SSS). Settlement of the securities transfers within an SSS takes place according to the law applicable to the SSS in which the legal account belongs. For example, a CSD participant has opened a securities account ( ) in the CSD system. The CSD participant holds following instruments on its securities account ( ): ISIN Total Balance LV EE LT Table 1: CSD participant s securities account ( ) holdings 8

10 As the CSD participant has Latvian, Estonian and Lithuanian instruments on its securities account, it means that there are three legal accounts, each in respective SSS. In Latvian SSS it is LV , in Estonian SSS EE and in Lithuanian SSS LT All operational accounts of the Nasdaq CSD were migrated to T2S on a one-to-one basis. From an operational perspective, each securities account constitutes a single account in the T2S. For legal purposes and settlement finality purposes, positions of securities in securities accounts (EE, LV, and LT ISINs) are attributed to the legal accounts that are held within the respective SSS. Any T2S eligible securities settlement transactions performed on an SSS via a securities account are settled in the T2S. Nasdaq CSD participants There are four participant roles in the CSD system: Account operator, Cash agent, Issuer agent, Fund administrator. An organization can become a CSD participant if its application has been accepted by the CSD and it meets the participation criteria stipulated in the Nasdaq CSD rules that are in compliance with applicable laws. A CSD participant may have one or multiple participant roles in the CSD. A CSD participant is identified in the system primarily through a unique BIC11. Also reference data such as organization name, registration number, address, country of registration, GIIN, etc. is set up in the CSD system. CSD participants are created by the CSD. The CSD assigns the CSD participant applicable role or roles in the system and grants the rights for underlying CSD services. The CSD assigns a representative of the participant the administrator rights. The administrator is authorized to create and maintain the participant s users in the system. The participant role(s) allows differentiating GUI users access to the information and therefore impose Chinese Walls; the users have permission to access/view only restricted set of data. 2.1 Account operator A CSD participant authorized as an account operator is responsible for the following: Setting up and maintaining of securities accounts in the CSD system; o Maintaining relations with their clients and following know-your-client (KYC) and other requirements. Intermediating settlement instructions (also CA instructions) to the CSD, i.e. sending settlement instructions, amendments and cancellations to the system and receiving feedback on these settlement instructions from the system in the form of status updates and advice, allegements and confirmations. Fulfillment of settlement in the form of payment of cash or delivery of securities derived from settlement instructions sent to the CSD. Cash settlement in the CSD is guaranteed by an appointed cash agent. 9

11 Maintaining and monitoring cash and securities settlement obligations of their clients in the CSD. Registration, modification and release of pledges. Verifying and ensuring the correctness of information communicated to the CSD. Account operators users access to operations can be segregated to ensure that each account operator s own activities and activities arisen from account operator services are performed independently, i.e. it is possible to restrict access to some type of data by assigning only relevant operations to user accounts. 2.2 Cash agent A CSD participant authorized as a cash agent is responsible for the following: Guaranteeing and providing liquidity for settlement of CSD participants cash leg of securities settlement and corporate action transactions proceeds in the CSD, if those securities are non-t2s eligible securities or are issued in non-t2s eligible currency. o Monitoring the settlement obligations of the account operator(s) that the cash agent provides liquidity services to and transferring sufficient cash to enable settlement for those account operator(s). Cash agents can provide their services for their own account operator and/or also to other CSD participants that are not themselves authorized as a cash agent in the CSD. 2.3 Issuer agent A CSD participant authorized as an issuer agent is responsible for the following: Servicing the issuer of financial instruments, according to local market practices. The Issuer agent role depends on local market practice and legal requirements. Distributing the securities to the investors during the initial offering of the respective security s issue. 2.4 Fund administrator A CSD participant authorized as a fund administrator is responsible for the following: Fund administrator is responsible for communication with the CSD and is acting on behalf of the Fund Manager. Fund administrator as a CSD participant is granted with the right to instruct on a dedicated issuance account in order to increase (issuance and subscription) or decrease (redemption) the quantity of fund units in circulation. In order to communicate to the CSD settlement instructions (subscription or/and redemption of open-ended fund units), the fund administrator also has to have account operator role (see section 6.6 for more information about open-ended fund units settlement). 2.5 Nasdaq CSD participants in T2S The CSD participants are set up as T2S parties in order to be able to interact with T2S. See Table 2 below for further details. The CSD set account operators up as T2S parties with the party type of CSD Participant in T2S. Cash agents are set up as Payment Banks by the respective national central bank in T2S. CSD participants are identified in T2S by combination of the CSD BIC (BIC11) and their own BIC (BIC11). 10

12 One legal entity that represents several roles in T2S is set up multiple times in T2S. This means if an account operator is also a Payment Bank in T2S, it is set up twice: - as a CSD Participant by the CSD in which it is the participant (participant is identified by CSD BIC11 and own BIC11) and - as a payment bank by the central bank (participant is identified by NCB BIC11 and own BIC11). The same legal entity can establish multiple business relationships with different parties in T2S using the same BIC11. T2S differentiates parties on the level of their respective CSD/CB; therefore, it is possible to use the same BIC11 as a party identifier. Participant in Nasdaq CSD T2S CSD T2S CSD Participant T2S Payment Bank T2S External CSD Linked CSD - Account operator Cash agent Issuer agent Fund administrator Table 2: Possible relations between CSD participants and T2S parties Example 1: an account operator in the CSD is a CSD participant in T2S. Example 2: a cash agent in the CSD can be a Payment Bank in T2S. Example 3: a CSD participant with two participant roles, account operator and cash agent, is set up to interact with T2S as follows: (i) Account operator to match T2S CSD Participant; (ii) Cash agent to match T2S Payment Bank T2S connectivity options There are two ways how CSD participants can technically interact with T2S directly or indirectly. Regardless of the connection chosen, all CSD participants retain their business and legal relationships with the CSD. T2S Indirect connection Nasdaq CSD Direct connection Participant A Participant B Figure 2: Participant communication with T2S 11

13 Directly connected party T2S directly connected parties (DCPs) are able to communicate directly with the T2S using a T2S authorized network service provider. To access all services (other than T2S services) DCPs maintain a connection with the CSD. This means that according to their needs or in order to manage non settlement services, DCPs also send instructions to the CSD system. Depending on DCPs subscription, reports are either sent from T2S or the CSD. The same participant may use both direct and indirect communication channels with T2S, depending on their business needs. Such participants are still considered to be T2S directly connected parties. Indirectly connected party Indirectly connected parties (ICPs) are not directly connected to the T2S; they only interact with T2S via the CSD system. ICPs send their messages to the CSD system using the provided communication means (A2A and GUI) and receive reports from the CSD only. The ICP s connection with T2S is provided and managed by the CSD. This document describes functionality towards the CSD system and T2S from the ICPs perspective. 12

14 Account management 3.1 Securities account opening and maintenance All securities accounts are deemed to hold both T2S and non-t2s eligible securities and are replicated to T2S. Securities accounts opening and maintenance requests are given to the CSD by account operators using either CSD system s GUI or ISO messaging. Account opening or maintenance requests are forwarded to T2S and after successful confirmation finalized in the CSD system. This means that account maintenance in the CSD system triggers an immediate replication to T2S and is only processed after technical and business validation processes are passed in both the CSD system and T2S. If any issues are encountered in T2S, the account opening or maintenance will be suspended for further investigation. The status of the replication is shown to the user in the CSD system s GUI and via messaging. All accounts are opened as T2S accounts even if the securities account only has non T2S-eligible securities in the account, this means that the account will have no balances in T2S. All actions are logged and traceable in the audit logs of the relevant systems. Accounts in T2S CSD participants maintain securities accounts in the CSD. Any modification or account opening requests are performed via the CSD that intermediates changes to T2S. Any newly opened securities accounts are instantly replicated in T2S as part of the account opening process. Securities account structures and set-up in both the CSD and T2S are configured as follows: For each account operator there is a corresponding T2S Party - CSD participant - in T2S, and For each securities account there is a corresponding T2S Securities Account (T2S SAC). Latvian Initial Register beneficial owner accounts were not migrated to T2S. There is one securities account in T2S that holds aggregated securities balances from all the investors in the Latvian Initial Register. All securities operations regarding the Latvian Initial Register are made via this securities account in T2S. 13

15 CSD Participant Nasdaq CSD T2S Request to open a securities account AccountOpeningInstruction acmt.001 A securities account is opened in the T2S AccountDetailsConfirmation acmt.002 Response about successful securities account opening AccountManagementStatusReport acmt.006 Response about unsuccessful securities account opening Request to modify securities account information AccountModificationInstruction acmt.003 Securities account information is modified AccountDetailsConfirmation acmt.002 Response about securities account modification AccountManagementStatusReport acmt.006 Response about unsuccessful securities account modification Requests securities account infomation from CSD ProprietaryGetAccountDetails AccountDetailsConfirmation acmt.002 Response to account information request Request to close a securities account AccountModificationInstruction acmt.003 Securities account is closed Account is closed also in CSD participant s proprietary system AccountDetailsConfirmation acmt.002 Response about closing of a securities account Figure 3: Account management communication overview 14

16 Only certain modifications of securities accounts attributes are replicated to T2S such as closing date, hold default indicator, negative position indicator, end investor flag and pricing scheme (for further information please refer to T2S UDFS). Account numbering in the CSD system and in T2S The harmonized account numbering algorithm is applied to all newly opened securities accounts in the CSD system. In T2S, all the CSDs have agreed to use the following structure for naming/numbering the T2S securities account: The first 4 digits = the BIC4 (LCDE) of the CSD; The subsequent 31 digits: free text/ 31 characters to be defined by the CSD. For example: BIC4+ securities account number/id. Thus, in T2S, Nasdaq CSD securities accounts have a Securities Account ID which represents the securities account number in the CSD system prefixed by the 4 first letters of the CSD s BIC. In order to minimize the T2S impact on CSD participants, the CSD converts (when communicating with T2S) Nasdaq CDS s securities account number to the T2S securities account number for its participants who are indirectly connected to T2S. It means that indirectly connected CSD participants must instruct with the CSD s operational account number and not the T2S account number when sending settlement instructions. The CSD passes the settlement instruction to T2S with the T2S securities account number. However, T2S securities account number is available for each securities account in the CSD system s GUI, and it is used by the CSD to pass instruction to T2S. Settlement instructions from participants containing the T2S securities account number are rejected by the CSD system. Directly connected participants are required to use T2S securities account numbers when communicating directly with T2S (the T2S securities account must be in compliance with the abovementioned high-level naming structure). 3.2 Securities account types in Nasdaq CSD The following securities account types for individual client are available in the CSD system: Owner account An owner account is a securities account that is registered in the name of the client (a natural or legal person) of an account operator for holding securities belonging to that client and evidencing the ownership rights of that client with respect to the securities on that account. There are several additional sub-types of Owner securities accounts: Joint owner account - A securities account declared to only hold the assets belonging to a number of clients, held jointly in the proportion indicated on the joint-ownership relationship. Co-owner account A securities account declared to only hold the assets belonging to a number of clients, each declared owner having an equal share in the benefits accruing. Owner pledge account A securities account declared to hold assets of a single client (Pledgor), pledged in support of an external collateral arrangement with a Pledgee. An Owner account must always contain information of the client, including the client s country of residency and, when required, other tax information. It is also possible to set up a preferred communication language (Baltic countries national languages and English) on an Owner account for reporting purposes. 15

17 Nominee account A nominee securities account is a securities account that is registered in the name of a nominee on behalf of their clients. Holdings, safe kept in a nominee securities account, belong to the nominee s clients. The breakdown of holdings of the individual clients of the nominee is maintained in the nominee s proprietary system. Segregated nominee account A segregated nominee securities account is registered in the name of a nominee and has holdings for a specific client who might or might not be the end investor. Abovementioned nominee securities accounts must always contain information on the nominee and nominee s country of residency and, when required, other tax information. It is also possible to set up a preferred communication language (Baltic countries national languages and English) on a nominee account for reporting purposes. The following account types are available for an account operator as the owner of the securities: Participant own account an account that is registered in the name of an account operator and is used for holding securities belonging to the account operator; Participant pledge account - an account that is registered in the name of an account operator and is used for holding securities belonging to the account operator as a pledgor. The following account type is available for an account operator or a CSD to hold securities that belong to multiple clients in the same securities account: Omnibus account - an account that is registered in the name of an account operator and is used for holding securities of account operator's multiple clients, or in the name of a Foreign CSD to allow holding of securities held with one or more Settlement Systems for the purposes of CSD link arrangement concluded with the CSD. The CSD is an account operator with the authorization to open, maintain and close technical accounts. The following accounts are the CSD s technical accounts: Issuance account is used for the issuance of securities. For example, issuance accounts are opened for fund administrators. Distribution account could be opened for issuer agents to support distribution of unplaced instruments during the initial offering or initial issuance. Distribution accounts are also used for the distribution of corporate action entitlements in the form of instruments. T2S SECURITIES ACCOUNTS Nasdaq CSD account types Nominee Account Segregated Nominee Account Owner Account Joint Owner Account Co-Owner Account Owner pledge Account Participant own account Participant pledge account CSD Participant Account CSD Omnibus Account Omnibus account Issuance Account 16

18 Distribution account Issuance account Table 3: Nasdaq CSD account types mapped to T2S account types for general overview (T2S Technical accounts are not described in the service description) The CSD Participant Account in the T2S is a fixed account type for any account opened by an account operator in the CSD system. The CSD Omnibus Account in the T2S is only available to a CSD and is used for cross-csd settlement. T2S allows the opening of securities accounts with the default hold/release indicator specified in static data. This means that participants can use this feature if they want automatically to put all settlement instructions related to this particular securities account on hold by default. The hold/release mechanism is the same as described in section When a new securities account is created, a link(s) with one (or more) T2S DCA(s) has to be provided in the CSD/T2S. The DCAs are under the responsibility of the National Central Banks; therefore account operators must inform the CSD about the DCAs to be used for settlement in EUR and/or T2S Autocollateralization. For more information, see section Link between DCA and Securities Account. 17

19 Notary and central maintenance services The CSD s notary and central maintenance services include the following: Initial recording of financial instruments in a book-entry system and allocation of ISIN codes; Processing distribution of financial instruments to securities accounts in connection with the issuance and allocation of the financial instruments; Maintenance of financial instruments, including processing of corporate actions, tax, general meetings and information services; Services related to shareholders registers; Maintaining securities accounts in relation to the settlement service, collateral management. The CSD also provides reports to supervisory authorities, and offers the provision of data and statistics to market participants. 4.1 Registration of financial instruments The CSD records securities issues in the book-entry form and allocates an International Securities Identification Number (ISIN) to each securities issue. The CSD is the national numbering agency and has the authority to assign ISINs to financial instruments issued in Estonia, Latvia, and Lithuania. ISIN codes are assigned according to ISO 6166 and ANNA (Association of National Numbering Agencies) guidelines. It is possible to register following financial instruments in the CSD equities, debt instruments, rights, options. Registration of any other financial instruments are subject to demand from customers. The instrument type is represented by the following instrument attributes: Asset class value from asset class classifiers defined in the system, Classification of financial instrument (CFI code). Asset class values are defined according to the ISO standard. Financial instruments are primarily classified by the CFI code, but in certain cases other additional classification can be used. Financial instruments issued in the CSD have their issuer information kept in the CSD system, and it is available via the GUI. Nasdaq CSD participants are able to view static data of the financial instrument registered in the Nasdaq CSD via the CSD system s GUI or by requesting a corresponding report (Proprietary Securities Reference Data Message) in A2A mode (using the agreed format of Proprietary Securities Reference Data Query Message). All financial instruments registered or maintained in the Nasdaq CSD are divided into two types of financial instruments: Financial instruments that are maintained and settled in T2S, i.e. T2S eligible securities; Financial instruments that are maintained and settled in the CSD system, i.e. non T2S-eligible securities. Whether the instrument is T2S eligible or not determines the process flows of various events that involve the financial instruments. The differences between such flows are described where applicable throughout this document. Each financial instrument contains a flag in its static data indicating whether the instrument is a T2S eligible instrument or not. For each T2S eligible financial instrument, there is a single CSD, which is in charge of creating and maintaining the data for that instrument in T2S by taking the role of Securities Maintaining Entity (SME). 18

20 The Nasdaq CSD is the SME for all financial instruments that are registered with the Nasdaq CSD as Issuer CSD and are eligible for settlement in T2S. At the time of registration, T2S eligible securities are first registered in the CSD system and then replicated in T2S as part of the financial instrument registration process. Financial instruments that cannot be transferred and settled in T2S (i.e. non-t2s eligible instrument) are registered, maintained, and settled only in the CSD system; such financial instruments are: Latvian Government Saving Notes and Special Purpose Bonds; Lithuanian Government Saving Notes Maintenance of financial instruments Financial instrument maintenance includes maintaining any changes of the financial instrument details and/or status of the financial instrument. The CSD maintains financial instrument data for instruments registered in the CSD and for instruments where it acts as SME in T2S. All financial instrument changes and updates are processed via corporate actions. For example, if there is a name change of the financial instrument, it is processed as a corporate action with the corresponding corporate action attributes. Financial instruments have different states that indicate the status of the instrument and influence actions that can be executed on the instrument. The possible states of financial instruments can be active, suspended, inactive or deactivated. For example, if a financial instrument is suspended, it is not possible to execute any non-ca related settlement involving the financial instrument. Inactive status means that a financial instrument is not yet valid for settlement (i.e. current date is not within instrument's validity period). Deactivated status means that financial instrument is closed and unavailable for settlement. Changes of financial instrument states are executed by the CSD. It also maintains the financial instrument states in T2S, when applicable. 19

21 Corporate actions The CSD executes corporate actions according to standards defined by the following groups: Corporate Actions Joint Working Group (CAJWG); T2S Corporate Action Subgroup (CASG); Securities Market Practice Group (SMPG); Market standards for General Meetings. In order to facilitate harmonization of corporate actions within the European markets, T2S has developed T2S corporate actions standards. These are the T2S corporate actions on flows (i.e. pending settlement transactions in T2S) which are based on the market corporate actions standards (CAJWG standards). The standards indicate the best T2S market practice that all the participating parties should follow. CAJWG standards and the T2S corporate actions standards declare that all corporate actions should be processed by the respective CSD and settled in T2S (for T2S eligible instruments). The CSD follows these standards and is the entity that notifies, calculates and executes the settlement of corporate action proceeds (both cash and securities) for all corporate action event types identified by SWIFT and in accordance with the above listed market practice standards. It also supports corporate actions acting as an Investor CSD for the linked Issuer CSDs. All corporate action notifications, entitlements and confirmations are visible in the CSD system s GUI and are sent as ISO standard messages. All corporate actions are grouped by CAJWG standards as follows: Corporate actions on stock : Distributions: o Cash distributions (e.g. cash dividend, interest payment); o Securities distributions (e.g. stock dividend, bonus issue); o Distributions with options (e.g. optional dividend). Reorganisations: o Mandatory reorganisations with options (e.g. conversion); o Mandatory reorganisations (e.g. stock split, redemption); o Voluntary reorganisations (e.g. tender offer). Corporate actions on flows : Transaction Management: o Market Claims (Distributions); o Transformations (Reorganisations); o Buyer Protection (Elective Corporate Actions). The following groups of corporate actions are supported: Mandatory (MAND): The holder of instruments eligible for a mandatory corporate action has no choice as to whether to participate in the event or not. A mandatory corporate action can be followed by a connected voluntary corporate action. Mandatory with options (CHOS): Offers the instrument holder a choice of how to participate in the corporate action according to set options. The holder of instruments receives options as to the combination of instruments and/or cash that can be received as a result of the corporate action. A default option is executed by the CSD if no instruction or an instruction that does not cover the whole eligible holding of a securities account is received. The lifecycle of a mandatory with options corporate action 20

22 incorporates the steps of a mandatory corporate action and, in addition, incorporates steps to manage the instrument holder s choice as to the instruments and/or cash to be received. Voluntary (VOLU): Participation in a corporate action is based on the choice of the instrument holder according to set options. The instrument holder can choose to take no action i.e. not participate or choose the combinations of instrument and/or cash to be received if their choice is to participate. The lifecycle of a voluntary event is similar to that of a mandatory with options event. Please see the Nasdaq CSD Corporate action service description for further details on general principles of corporate action related processing. 21

23 Clearing and Settlement Settlement services of T2S eligible Baltic instruments are outsourced to the T2S. Settlement instructions are settled in T2S if, and only if, the financial instrument in the instruction is a T2S eligible security. In all other cases, the CSD system is used for settlement. Securities settlement in the CSD is described in more detail in the following chapters. 6.1 Settlement instruction types The following settlement instruction types are supported by CSD: Free of Payment instruction (FOP) the movement of securities (deliver / receive) without cash movement [also known as deliver free of payment (DFP) and receive free of payment (RFP)], Delivery versus Payment (DVP) / Receive versus payment (RVP) movement of securities against cash, Delivery with Payment (DWP) / Receive with payment (RWP) movement of cash and securities from one party to another, Payment Free of Delivery (PFOD) exchange of cash without the movement of securities, where the settlement quantity is equal to zero and the settlement amount is greater than zero, Parties related to settlement instruction According to ISO standard settlement instruction is related to several different parties so that each party has a specific role in the context of a settlement instruction. A single party (legal entity) may act in different roles. For example, the instructing party and the settlement party are typically the same party. Party Role Sender Instructing Party CSD of Receiving Party CSD of Delivering Party Receiving (Settlement) Party / Receiving Agent (REAG) Delivering (Settlement) Party / Delivering Agent (DEAG) Client of Receiving Party Client of Delivering Party Э Role Description The party sending in (via messaging), inputting (in GUI) or generating the instruction on behalf of the instructing party. The sender can be the account operator or CSD. The party creating and maintaining the settlement instruction. The instructing party can receive all instruction lifecycle messaging (status advices) from the CSD. The instructing party can be the account operator or CSD. The instructing party can also be the Sender of the instruction. The CSD of which the receiving party is a participant. The CSD of which the delivering party is a participant. The party that requests receive the financial instruments. The receiving party must be the account operator of the instructed account. The party that delivers the financial instruments. The delivering party must be the account operator of the instructed account. A client of the receiving settlement party (intermediary, securities account owner). A client of the delivering settlement party (intermediary, securities account owner). Э 22

24 Table 4: Overview of parties related to settlement instruction 6.2 Settlement instruction linkage A settlement instruction can be linked to other settlement instructions. Such linked instructions are submitted to specific rules during business validation and the settlement process. The T2S allows the linking of settlement instructions in two ways: The settlement instruction is linked to another settlement instruction, with a processing position code corresponding to: o Before (BEFO) the settlement instruction must be settled before or at least at the same time as the linked instruction, o After (AFTE) the settlement instruction must be settled after or at least at the same time as the linked instruction, o All-or-none (WITH) the settlement instruction must be settled at the same time with the linked instruction, o Information (INFO) the settlement instructions are linked for informational purposes only. There is no processing applied to informational links. INFO link is used mainly by T2S internally linking settlement instruction, i.e. realignment process, etc. (for further information please refer to T2S UDFS). A Pool Reference the settlement instruction is added to a uniquely identified pool (group) of settlement instructions, to be settled on an all-or-none basis. Settlement instructions with non T2S eligible Baltic instruments can be linked together with the all-ornone (WITH) processing position code only. 6.3 Settlement priority It is possible to assign a settlement priority for a settlement instruction. By using settlement priority levels, settlement instructions compete for using the same securities and/or cash resources in the settlement optimization process. Instructions with highest level of priority are preferred in the optimization process during real-time and T2S night-time settlement periods. Settlement instruction priority can be amended during settlement instruction lifecycle, but only before the final settlement. The available priority levels are (from the highest to the lowest): 1 Reserved priority used only by CSDs and NCBs, e.g. settlement instructions generated from corporate actions, 2 Top priority used only by trading platforms and CCPs. Settlement instructions can be assigned top priority if they are sent to T2S by trading platforms and/or CCPs directly; therefore, top priority is not used by Nasdaq CSD participants, 3 High priority available for participants; assigned by default to settlement instructions from trade capture but can also be assigned to OTC transactions, 4 Normal priority available for participants, assigned to transactions by default. For matched settlement instructions, the applicable level of priority is determined by the system based on the highest level of priority used for each settlement instruction. Normal priority is used if no level of priority is indicated in the settlement instruction. 23

25 If both matched settlement instructions indicate a different level of priority, the highest level of priority is used for both matched settlement instructions; this means that if one party indicates normal priority or no priority and counterparty indicates high priority, the settlement engine will take the highest priority. Same settlement priority logic is applied also to non T2S eligible Baltic instruments settlement instructions. 6.4 Settlement instruction lifecycle The full lifecycle process of a settlement instruction can be managed via GUI and ISO messaging and the process is the same in each case. Settlement Instructions Instruction Cancellations Instruction Amendments Hold/Release Instruction Validation Matching & Allegements Instruction Cancellation Instruction Amendment Hold/Release Instruction Settlement & Optimisation Instruction Recycling System Processes Figure 4: Overview of settlement instruction lifecycle processes Input The settlement instruction lifecycle starts when instructions are input to the CSD system. Settlement instructions can be input by several means: Manually in GUI; Via MQ or SWIFTNet using ISO standard messages; Internally generated by the system (corporate action settlement, market claims, transformations, auto-collateralization, other purposes); Generated by trade capture. CSD participants can input (via messaging or GUI) single instruction containing data for two already matched instructions. If this is the case, the CSD system validates whether the instructing party is allowed to debit and credit securities accounts indicated in the already matched settlement instruction. 24

26 6.4.2 Trade capture The CSD captures trades from the Baltic Stock Exchanges. The trade capture solution is developed in order to establish a harmonized Baltic market practice, allowing enriching trade feeds of the Baltic Stock Exchanges with settlement information and enabling automatic generation of settlement instructions, which are sent to the CSD. Trade capture service that is provided by the CSD to its participants is optional and settlement instructions with the necessary settlement details can be sent to the CSD system by the corresponding CSD participants themselves. The CSD receives feed from the Baltic Stock Exchanges and generates settlement instructions for CSD participants who are using the trade capture functionality. Trade capture also handles trades originated from the auctions. The Stock Exchange Member appoints one single account operator to settle all its trades at the CSD. The agreement between Member and their appointed account operator is communicated to the Baltic Stock Exchanges. Members have to fill in a special form that must be sent to the CSD and CSD has to receive a confirmation from indicated account operator that there is a valid agreement between them. If a participant has decided not to use the trade capture functionality, then the CSD participant has to instruct the CSD themselves using regular settlement instructions (Stock Exchange Member has to provide its account operator with the relevant settlement information). When instructing such settlement instructions the CSD participant must make sure he gets all the required information from the Member in order to settle the trade in the CSD. For example, for matching purposes such settlement instruction shall comply with the mandatory matching fields related to settlement instruction are described in section However, the CSD suggests using trade number as common reference (optional matching field) as this ensures settlement instruction matching with correct counter-instruction. If a participant has decided using trade capture functionality, then information from the trade feed is presented in the CSD system s GUI and becomes accessible for him. It is possible to enrich a trade with following limited set of information via GUI: securities account number, securities account number of the client (relevant in omnibus markets), client information, participant reference and confirmation flag. Additionally it is possible to enrich and confirm trade via messaging (Proprietary trade capture transaction instruction). When a trade leg is confirmed, the settlement instruction is created and becomes accessible for account operators in CSD system s GUI and if subscribed account operator is notified with SecuritiesSettlementTransactionGenerationNotification (sese.032). Such settlement instructions are forwarded to T2S for matching (if unmatched) and settlement. Trade capture solution generated settlement instructions can be modified according to the standard settlement instruction modification rules, see section In case non-modifiable information shall be changed in the settlement instruction, account operators are advised to cancel a settlement instruction and send new corrected settlement instruction, if needed. In the Stock Exchange system it is not possible to add the partial settlement indicator to a trade. Nevertheless, the partial settlement indicator can be added by the account operator to a settlement instruction (see section ). Trade legs are received via trade capture and as soon as a trade leg is enriched and /or confirmed by the account operator it will become a settlement instruction and the account operator can set the partial settlement indicator on this settlement instruction. The account operator can maintain only settlement instructions not trade legs. 25

27 In the Stock Exchange system Opt in/opt out and Cum/Ex fields are not available. However, those fields are mapped from trade leg to settlement instruction and by default are fixed to <blank>. It means that when a trade leg is enriched and confirmed, settlement instruction is created and Opt in/opt out and Cum/Ex fields are with value <blank>. When those fields are left blank and settlement instructions are matched, then those instructions are included in the transformation and market claim detection Validation Settlement instruction validation consists of two parts: technical validation and business validation. Technical validation makes sure that the settlement instruction data is input and received correctly and according to the standard accepted by the CSD system. Therefore, the following is validated during a technical validation: Message structure message format and structure must conform to technical rules of the respective standard (ML schemas of ISO messages as set in the Nasdaq CSD Message Usage Guidelines); Data types the value of each attribute must match the expected data type of the attribute (e.g. that text is not entered where numbers are expected, that decimal numbers are entered correctly, that dates and times are entered correctly, etc.); Data lengths minimum and maximum data lengths must be honored; Character sets if a textual attribute has a defined set of allowed characters then the input value must be within the defined character set; ISO message rules single and cross-element rules defined in ISO are verified. Business validation is only started after technical validation has been successfully passed. Business validation uses a set of business rules stored in the CSD system static data to validate that the information in the settlement instruction is correct for settlement. Business validation is carried out as initial validation before accepting new settlement instruction. Revalidation is carried out after instruction maintenance or changes to related reference data in the system before every settlement attempt. Therefore, pending settlement instructions are submitted for the revalidation process. Rejected, cancelled or settled instructions (except if partially settled: for those, the unsettled part is still subject to revalidation) are excluded from the revalidation process. If the business validation fails during the T2S revalidation of a settlement instruction, then it is cancelled by the system with the reason cancelled by system (CANS) and cancellation is communicated (sese.024) to the sender of the instruction. Both, the CSD and T2S perform the validation process after receiving settlement instructions. This means instructions received from ICP clients are first validated by the CSD system. Part of the business validation is to derive the application where the settlement takes place (the CSD system or T2S). If T2S is the application of settlement, then the instruction, successfully validated by the CSD system, is transmitted to T2S, where it passes the T2S validation process and only then the status (accepted or rejected) is assigned to the settlement instruction. As participants in the T2S DCP mode send instructions directly to T2S, their settlement instructions only go through T2S validation. 26