NASDAQ CSD SERVICE DESCRIPTION€¦ · NASDAQ CSD SERVICE DESCRIPTION . 1 ... CMB Credit Memorandum Balance ... T2S UDFS T2S User Detailed Functional Specifications

1. Nasdaq Central Securities Depository in Baltic 2. TARGET2-Securities operation phase 3. v 1.2. 4. April 2017

NASDAQ CSD SERVICE DESCRIPTION

1

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.

2

Content plan Abbreviations ................................................................................................................................................ 4 1 Introduction ......................................................................................................................................... 5

1.1 Nasdaq CSD .................................................................................................................................. 6 1.2 Nasdaq CSD securities account structure .................................................................................... 6 1.3 Key changes ................................................................................................................................. 8

2 Nasdaq CSD participants .................................................................................................................... 10 2.1 Account operator....................................................................................................................... 10 2.2 Cash agent ................................................................................................................................. 11 2.3 Issuer agent ............................................................................................................................... 11 2.4 Fund administrator .................................................................................................................... 11 2.5 Nasdaq CSD participants in T2S ................................................................................................. 12

2.5.1 T2S connectivity options ..................................................................................................... 12 2.5.1.1 Directly connected party ............................................................................................. 13 2.5.1.2 Indirectly connected party .......................................................................................... 13

3 Account management ........................................................................................................................ 14 3.1 Securities account opening and maintenance .......................................................................... 14 3.2 Securities account types in Nasdaq CSD .................................................................................... 16

4 Notary and central maintenance services .......................................................................................... 19 4.1 Registration of financial instruments ........................................................................................ 19

4.1.1 Maintenance of financial instruments ................................................................................ 20 4.1.2 Latvian and Lithuanian debt instrument conversion .......................................................... 21

5 Corporate actions ............................................................................................................................... 22 6 Clearing and Settlement ..................................................................................................................... 24

6.1 Settlement instruction types ..................................................................................................... 24 6.1.1 Parties related to settlement instruction ........................................................................... 24

6.2 Settlement instruction linkage .................................................................................................. 25 6.3 Settlement priority .................................................................................................................... 25 6.4 Settlement instruction lifecycle ................................................................................................. 26

6.4.1 Input .................................................................................................................................... 27 6.4.2 Trade capture ...................................................................................................................... 27 6.4.3 Validation ............................................................................................................................ 29 6.4.4 Matching ............................................................................................................................. 31

6.4.4.1 Tolerance matching ..................................................................................................... 33 6.4.4.2 Allegement .................................................................................................................. 34 6.4.4.3 Removal of an allegement notification ....................................................................... 35 6.4.4.4 Cancellation of an allegement .................................................................................... 35

6.4.5 Maintenance of settlement instruction .............................................................................. 36 6.4.5.1 Amendment ................................................................................................................ 36 6.4.5.2 Hold/Release ............................................................................................................... 37 6.4.5.3 Cancellation ................................................................................................................. 38

6.4.6 Recycling ............................................................................................................................. 40 6.5 Portfolio transfer ....................................................................................................................... 40 6.6 Open-ended fund units ............................................................................................................. 41

6.6.1 Subscription of fund units ................................................................................................... 42 6.6.2 Redemption of fund units ................................................................................................... 42 6.6.3 Swap of fund units .............................................................................................................. 42

3

6.7 Settlement process in T2S ......................................................................................................... 44 6.7.1 Partial settlement ............................................................................................................... 46 6.7.2 Conditional settlement ....................................................................................................... 48 6.7.3 Nasdaq CSD operational day with T2S ................................................................................ 49

6.8 Settlement process outside T2S ................................................................................................ 51 6.8.1 Technical netting ................................................................................................................. 53 6.8.2 Settlement optimization ..................................................................................................... 53

6.9 Holidays ..................................................................................................................................... 54 6.10 Cross-border links ...................................................................................................................... 54

7 Restrictions ......................................................................................................................................... 56 7.1 Blocking ..................................................................................................................................... 56 7.2 Pledging securities balance on an account ................................................................................ 57 7.3 Pledging a securities account .................................................................................................... 57

8 Cash management .............................................................................................................................. 58 8.1 Cash settlement in T2S .............................................................................................................. 58

8.1.1 Dedicated cash accounts ..................................................................................................... 59 8.1.1.1 Link between DCA and RTGS account ......................................................................... 59 8.1.1.2 Link between DCA and Securities Account ................................................................. 59 8.1.1.3 Credit Memorandum Balance ..................................................................................... 60

8.1.2 DCAs cash management ..................................................................................................... 60 8.1.3 T2S auto-collateralisation ................................................................................................... 61

8.2 Cash settlement outside T2S ..................................................................................................... 62 8.3 Cash forecasts ............................................................................................................................ 64

8.3.1 Cash forecast from CSD system .......................................................................................... 64 8.3.2 T2S cash forecast ................................................................................................................ 65

9 Reporting ............................................................................................................................................ 66 9.1 Report subscriptions .................................................................................................................. 67 9.2 Queries ...................................................................................................................................... 67

10 Message subscriptions ....................................................................................................................... 69 11 Market specificities ............................................................................................................................ 70

11.1 Shareholders’ disclosure............................................................................................................ 70 11.2 Latvian Initial Register ............................................................................................................... 70 11.3 Non-T2S eligible securities settlement ...................................................................................... 70

ANNEX 1 – Transaction types eligible for allegement process ................................................................... 71 ANNEX 2 – Overview of availability of main functionality in the CSD system’s GUI and A2A mode .......... 73 ANNEX 3 – Table of ISO20022 messages .................................................................................................... 75 ANNEX 4 – T2S settlement flow .................................................................................................................. 74 ANNEX 5 – Local settlement flow (both counterparties in Nasdaq CSD) ................................................... 75

4

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-Securities

Pan-European platform for securities settlement, operated by the Eurosystem

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

5

Introduction 1 The post-trade industry in Europe is undergoing a major transition due to regulatory changes and new initiatives (e.g. CSDR, launch of TARGET2-Securities) that cause changes in post-trade business models and operations.

The CSDR liberalizes the European Union market for CSD services, brings more cross-border uniformity and standardization, and, at the same time, introduces strict prudential requirements and tighter supervision of the CSD market, including full re-authorization of existing CSDs. One of the key areas of CSD re-authorization covers compliance of the CSD systems with the new requirements, as the regulations demand a high level of STP and versatile functionality of the CSD platforms. From this perspective, technology has a direct pan-European impact on both CSDs and market participants. The single settlement infrastructure, TARGET2-Securities (T2S), is driving towards standardization, higher levels of automation and interconnectivity across Europe.

All three Baltic CSDs have signed the T2S framework agreement and will outsource settlement to T2S in the Final wave of the T2S migration – September 2017. In relation to the T2S and a number of established regulatory requirements, the Baltic CSDs will reshape CSD organization within the legal and technical framework as follows:

Consolidation of the three Baltic CSDs to one Nasdaq CSD, licensed under CSDR and operating 3 securities settlement systems (SSSs), each governed by national jurisdiction in Estonia, Latvia and Lithuania respectively.

The outsourcing of matching and settlement services to the T2S by operating of three securities settlement systems will be serviced by a single IT platform, which has the same procedures available for any of the three SSSs.

Nasdaq CSD will upgrade the securities settlement and registry system called DEPEND that is currently used in Estonia, and implement it in all 3 Baltic countries.

The CSD system enables the Baltic markets and participants to meet upcoming changes in the securities industry including developments pursuant to pan-European legislation, standards and other harmonization initiatives.

The CSD system’s functionality is developed to serve CSD operations both in and out of T2S, i.e. matching and settlement functions are outsourced to T2S for T2S eligible securities or processed in the CSD system for other securities.

This service description gives a general overview of the CSD system’s functionality and major changes compared to the current Baltic legacy systems. This document is addressed to Baltic CSD participants and the respective supervisory authorities.

The service description includes the following areas:

6

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.

Service description and additional documents will be available on the project web page at http://www.nasdaqbaltic.com/en/csds/csdsystem/ .

1.1 Nasdaq CSD The Baltic CSDs have initiated the process of consolidation of the three Baltic CSDs into one licensed legal entity with two branches. The legal seat of the consolidated Nasdaq CSD will be domiciled in Latvia, with branches operating in Estonia and Lithuania.

The combined entity will be reauthorized under the CSDR and will be supervised by Baltic regulators cooperating in accordance with the CSDR. The consolidation is subject to regulatory approvals and shall be carried out in the form of a cross-border merger to ensure transferability of the current business and contractual relations of the Baltic CSDs.

Local businesses and client servicing will continue in all three countries as before. There will be one IT platform connected to the Baltic market, meaning that interactions between the CSD system and CSD participants are centralized and are not bounded by geographical location.

The timeline for carrying out the reorganization and reauthorization of the Baltic CSDs aims to match the re-platforming plan - migration to the common CSD system platform and joining T2S.

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

http://www.nasdaqbaltic.com/en/csds/csdsystem/

7

nominee legal accounts, or nominee legal accounts, or owner legal accounts, see Figure 1 below.

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

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

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 will consist 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 (123456789) in the CSD system. The CSD participant holds following instruments on its securities account (123456789):

ISIN Total Balance

LV0000100659 500 000

EE3100004466 40 000

LT0000102337 500

8

Table 1: CSD participant’s securities account (123456789) holdings

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 123456789LV0000100659, in Estonian SSS 123456789EE3100004466 and in Lithuanian SSS 123456789LT0000102337.

All operational accounts of the Nasdaq CSD will be 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 will be settled in the T2S.

1.3 Key changes Pursuant to the changes in legislation, implementation of T2S, and the Baltic CSDs’ harmonization initiative, below are outlined the following key changes compared to the current market practice.

General

o Settlement of T2S eligible securities is outsourced to T2S and the CSD’s data

accuracy and freshness will depend on the messaging frequency between the

T2S and CSD system.

Account maintenance

o Latvian and Lithuanian participants have the possibility to open and maintain

securities accounts directly without the CSD’s mediation.

o New account types are introduced to all Baltic markets.

o Securities account opening will automatically facilitate the three SSS approach of

separating legal and operational accounts. Only operational accounts are

migrated to T2S.

o Portfolio transfers will be done by submitting separate settlement instructions in

accordance with the general settlement procedures. There will also remain the

possibility to instruct on portfolio transfers using specific transfer orders as

currently available in the Estonian market. Latter solution is changed as part of

T2S adaptation. Main difference compared to current solution is that as a result

of the confirmed portfolio transfer orders, settlement instructions are created,

and standard settlement procedure is used to make the transfer.

9

Notary and central maintenance services

o Latvian and Lithuanian debt instruments are planned to be converted to FAMT

before migrating to T2S.

Settlement procedure

o T2S settlement will follow T2S rules, procedures, and time schedule.

o Night-time settlement is introduced for T2S eligible securities.

o Partial settlement is available to increase settlement probability for T2S eligible

securities.

o Tolerance matching is introduced in all settlement currencies.

o Additional settlement instructions maintenance features, including priorities,

hold/release mechanism, linking, etc., are introduced.

o Conditional Settlement is available to facilitate certain settlement options.

o Cash leg settlement differs depending on the settlement place – T2S or CSD

system. T2S settlement will take place in T2S DCAs that fall under the TARGET2

perimeter. Other instruments’ cash settlement will remain in the CSD system.

Pledging

o The pledging procedure will change to facilitate T2S requirements. Both pledge

agreement parties need to submit their matching pledge instructions to the CSD.

Pledge is executed in T2S as an intra position movement (pledging securities

balance on an account). The pledge is registered on the pledgor’s account on

behalf of the pledgee. The other option is to transfer the pledged instruments to

a separate pledge account (in case of financial collateral).

Corporate actions (please see the Nasdaq CSD Corporate action service description for

further details)

o Corporate actions are further aligned to be processed according to standards.

o Corporate actions on flows are introduced.

Messaging

o ISO 20022 messaging is introduced for the entire Baltic market.

o The participant can manage their subscriptions for the reports, etc. in the CSD

system’s GUI.

Other

o The CSD system has a GUI. Most of the functionalities are available in both GUI

and messaging.

o User maintenance will become more flexible. The CSD will grant a representative

of the participant the User Administrator role that enables them to create and

maintain users in the system.

10

Nasdaq CSD participants 2 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.

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.

11

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.

Issuer agent’s role as a CSD participant is currently used in the Latvian and Lithuanian market.

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).

12

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 will 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).

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 X X - X

Account operator - X - -

Cash agent - - X -

Issuer agent - X - -

Fund administrator - X - -

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.

2.5.1 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.

13

T2S

Nasdaq CSD

Participant A Participant B

Indirect connection

Direct connection

Figure 2: Participant communication with T2S

Directly connected party 2.5.1.1 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 2.5.1.2 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.

14

Account management 3

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 20022 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.

After migration to T2S all new 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.

Migration of existing accounts to T2S

After migration to T2S, authorized CSD participants continue to maintain securities accounts managed by them in the CSD. Any modification or account opening requests are still performed via the CSD that intermediates changes to T2S.

The CSD will migrate all securities accounts with an “active” account status during the last T2S migration weekend dress rehearsal. However, accounts that were closed before T2S go-live will also be closed in T2S.. All closed accounts are still visible in the CSD system even though all closed accounts are not migrated 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 will be configured as follows:

For each account operator there will be a corresponding T2S Party - CSD participant - in T2S, and

For each securities account there will be a corresponding T2S Securities Account (T2S SAC).

Latvian Initial Register beneficial owner accounts will not be migrated to T2S. There will be 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.

15

Response about unsuccessful securities account opening

A securities account is opened in the T2S

Requests securities account infomation from CSD

Request to close a securities account

Request to modify securities account information

Request to open a securities account

Securities account information is modified

CSD Participant T2S

Securities account is closed

Response about securities account modification

Response about closing of a securities account

AccountOpeningInstruction acmt.001

AccountManagementStatusReport acmt.006

AccountModificationInstruction acmt.003

ProprietaryGetAccountDetails

Account is closed also in CSD participant’s proprietary

system

Response about successful securities account opening

AccountDetailsConfirmation acmt.002

AccountModificationInstruction acmt.003



Response about unsuccessful securities account modification

AccountManagementStatusReport acmt.006

Nasdaq CSD

Response to account information request


Figure 3: Account management communication overview

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 Already existing securities accounts numbers will not be affected by the CSD system change.

The harmonized account numbering algorithm will be applied to all newly opened securities accounts in the CSD system. This changed account numbering practice affects both Latvian and Lithuanian market participants, because the new account numbering means that the previously built account numbering “business logic” will not be applied anymore. For Estonian market participants, there will not be any changes.

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+existing securities account number/ID.

Thus, in T2S, Nasdaq CSD securities accounts will 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 will convert (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 will pass 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 will be 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.

17

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.

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.

18

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 CSD Participant Account

CSD Omnibus Account

Issuance Account

Nominee Account X

Segregated Nominee Account X

Owner Account X

Joint Owner Account X

Co-Owner Account X

Owner pledge Account X

Participant own account X

Participant pledge account X

Omnibus account X X

Distribution account X

Issuance account X

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.

One of the new T2S features 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 6.4.5.2.

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 Auto-collateralization. For more information, see section 8.1.1.2 Link between DCA and Securities Account.

19

Notary and central maintenance services 4 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 10962 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;

20

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). 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.

Only active T2S eligible securities are migrated to T2S and made available for settlement.

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:

Estonian III pillar pension fund units, until those are moved to Estonian Pension Information System EPIS;

Lithuanian Government Saving Notes.

4.1.1 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.

21

4.1.2 Latvian and Lithuanian debt instrument conversion Currently all debt instruments in the Estonian CSD and the Lithuanian CSD are registered in face amount, however, in the Latvian CSD these instruments are registered in units.

Latvian debt instruments conversion from units to face amount is planned together with T2S migration. Detailed information on this topic will be communicated to participants separately.

22

Corporate actions 5 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 20022 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:

23

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 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.

24

Clearing and Settlement 6

With migration to T2S, 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,

6.1.1 Parties related to settlement instruction According to ISO 20022 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 Role Description

Sender 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.

Instructing Party 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.

CSD of Receiving Party The CSD of which the receiving party is a participant.

CSD of Delivering Party The CSD of which the delivering party is a participant.

Receiving (Settlement) Party / Receiving Agent

The party that requests receive the financial instruments. The receiving party must be the account operator of the instructed account.

25

Party Role Role Description

(REAG)

Delivering (Settlement) Party / Delivering Agent (DEAG)

The party that delivers the financial instruments. The delivering party must be the account operator of the instructed account.

Client of Receiving Party

A client of the receiving settlement party (intermediary, securities account owner).

Client of Delivering Party

A client of the delivering settlement party (intermediary, securities account owner).

Cash Agent Cash agents are responsible for settling cash obligations resulting from settlement instructions. Depending on the payment direction of the settlement instruction, either a debtor payment agent or a creditor payment agent may be represented.

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-or-none (WITH) processing position code only.

6.3 Settlement priority

26

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.

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

27

The full lifecycle process of a settlement instruction can be managed via GUI and ISO 20022 messaging and the process is the same in each case.

Validation

Settlement Instructions

Instruction Cancellations

Instruction Amendments

Hold/ReleaseInstruction

Matching & Allegements

Settlement & Optimisation

Instruction Cancellation

Instruction Amendment

Hold/ReleaseInstruction

Instruction Recycling

System Processes

Figure 4: Overview of settlement instruction lifecycle processes

6.4.1 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 20022 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.

6.4.2 Trade capture

28

The CSD will continue capturing trades from the Baltic Stock Exchanges. Compared to the previous service, there are several adjustments affecting Stock Exchange Members and CSD participants.

The new 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 will also handle trades originated from the auctions. Irrespective of the CSD service, the Baltic Stock Exchanges continue providing protocols to its Members. However member daily trade files provided by Nasdaq Riga and Nasdaq Vilnius will be discontinued. In addition, Nasdaq Baltic offers Nasdaq INET Member Trade File to Members.

The Stock Exchange Member will appoint 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 will have to fill in a special form that will be sent to CSD and CSD will have 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 6.4.4. 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).

Deadline for confirming trades will be changed (currently it is on ISD at 11:00). Since the T2S business day will start already on ISD-1 due to nighttime settlement, confirmation needs to be given earlier.

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

29

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 6.4.5. 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 6.4.5.1). 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.

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.

6.4.3 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 (XML schemas of ISO 20022 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 20022 are verified.

30

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.

Settlement Instruction

Validation

CSD system processes T2S processes

Validation






RecyclingRecycling

CSD system

ICP/DCP DCP

T2S

Figure 5: Overview of settlement instruction validation

31

After successful validation, the settlement instruction is accepted and the acceptance is communicated to the sender of the instruction. Accepted settlement instruction is submitted to the matching process. If validation fails, then the settlement instruction is rejected. Rejection state together with rejection reason is communicated to the sender of the instruction. Rejection is a final state of a settlement instruction; this means no further processing or modification of that particular settlement instruction is possible.

Note: The settlement instruction’s lifecycle processing continues in the application (the CSD system or T2S) which was derived during the business validation.

6.4.4 Matching Matching is a process where two settlement instruction details are compared to ensure that the deliverer and receiver of the securities agree on the terms of the settlement. Whether matching is executed in the CSD system or in T2S is determined by where the settlement should happen. All settlement instructions that settle in T2S (except settlement instructions sent to T2S with a matching status set as “Matched”) are matched in T2S. Even though the application where the matching is executed may be different for different settlement instructions, the matching rules are the same for the settlement instructions to be settled in the CSD system and for the settlement instructions to be settled in T2S.

For two settlement instructions to match, the mandatory matching fields must be present in both settlement instructions and their values should be the same for the corresponding delivering and receiving settlement instructions (exception: a settlement amount in DVP and PFOD instructions for which a tolerance might apply; Credit/Debit Code (CRDT/DBIT) and Securities Movement Type Deliver/Receiver (DELI/RECE), those values match opposite).

Non-mandatory matching fields are classified as either additional or optional matching fields.

Additional matching fields only match in case both counterparties have provided the same value in the same additional matching field. In case no value is provided in the counter instruction, then the settlement instructions do not match.

Optional matching fields match in case both counterparties have provided the same value in the same optional matching field or in case one of the counterparties has provided a value in the optional matching field. In case one party leaves the field empty, the settlement instructions still match. Matching fields Current market

practice Nasdaq CSD with T2S

Mandatory for all instructions

Securities movement type EE, LT yes

Payment type EE, LT yes

32

Matching fields Current market practice

Nasdaq CSD with T2S

ISIN code EE, LV, LT yes

Trade date EE, LV, LT yes

Settlement quantity EE, LV, LT yes

Intended settlement date EE, LV, LT yes

Delivering (settlement) party EE, LV, LT yes

Receiving (settlement) party EE, LV, LT yes

CSD of Delivering party EE, LT yes

CSD of Receiving party EE, LT yes

Mandatory for instructions involving payments (DVP/PFOD)

Currency EE, LV, LT yes

Settlement amount EE, LV, LT yes

Credit/debit indicator EE, LT yes

Additional (values have to match if the value has been provided by one instruction)

Opt out indicator1 yes

Cum/Ex indicator2 yes

Currency3 yes

Settlement amount3 yes

Credit/debit indicator3 yes

Optional (values have to match if provided by both instructions, matching against blank allowed)

Common reference EE, LV yes

Client of delivering party EE yes

1 Opt out indicator is used with corporate actions on flows. It enables the counterparties in a transaction to opt-out

from any corporate actions transaction management arrangements (as per CAJWG standards). 2 Cum/ex indicator can be used to establish an entitlement outside of regular entitlement dates; e.g. the trade was

executed Cum coupon or Ex coupon. 3 The attributes Currency, Settlement amount and Credit/debit indicator are defined as additional matching fields

for FOP instructions in order to minimise the risk of mismatching of settlement instructions containing cash leg in a non T2S currency.

33

Matching fields Current market practice

Nasdaq CSD with T2S

Client of receiving party EE yes

Securities account of delivering party (counterparty’s account specified in the instruction)

EE yes

Securities account of receiving party (counterparty’s account specified in the instruction)

EE yes

Table 5: Settlement instruction matching fields gap analysis

Throughout the operational day, the matching process continuously tries to match the settlement instructions. Also, settlement instructions that are on hold enter the matching process. Unmatched settlement instructions are recycled until they expire (meet the end of their recycling period).

T2S matching reporting is limited to essential information about the status of each single settlement instruction (i.e. matched or unmatched). However, T2S will not report any reason code regarding unmatched instructions; thus, no such reasons are reported to the CSD participants. However, after the first unsuccessful matching attempt, T2S will send an allegement message (after having waited a certain period of time) to inform the counterparty that there is a settlement instruction alleged against it. The allegement process is described in section 6.4.4.2. After the first unsuccessful matching attempt the CSD system sends out a settlement instruction status advice message sese.024 with the matching status “NMAT – Unmatched”. The same matching status is also visible in GUI. There also will not be unmatched reason code reporting for non T2S settlement instructions.

In case there are several suitable settlement instructions (all the matching fields are the same) the settlement instruction is matched to the one with the closest4 system time of entry.

As soon as matching is executed (either in T2S or in the CSD system) those participants that have subscribed for status advice messages receive a sese.024 message with a “MACH – Matched” status and the corresponding matching reference. Such information is also visible in the CSD system’s GUI irrespective of the subscription settings.

Tolerance matching 6.4.4.1 Tolerance matching is applied if the settlement amounts input by the buyer and the seller in the settlement instruction differ by a predefined tolerance.

4 Closest entry time to the system means that two instructions with the smallest time difference in the entry time

are selected for matching.

34

The amount of acceptable tolerance depends on the settlement amount indicated in the settlement instructions as shown in Table 6 below.

Settlement amount Tolerance

≤ EUR 100 000 EUR 2

> EUR 100 000 EUR 25

Table 6: Tolerance matching

Tolerance amount is harmonized with the T2S standards and can be defined per each currency. Other currencies follow the standard, and tolerance amounts are equivalent to approximate counter-value; e.g. for retail transactions with values up to and including EUR 100 000 or counter-value in any other currency, the applicable tolerance amount should be EUR 2 or an approximate counter-value in other currencies, i.e. USD 2.40.

In case there are several settlement instructions that could potentially match and have the only difference in settlement amount within the tolerance matching range, the settlement instruction with the smallest settlement amount of difference will match. Such matched settlement instructions are submitted for settlement and a settlement amount that is indicated by the seller (Deliverer) of the securities is used. Participant that has sent the buy settlement instruction is informed of the new settlement amount through sese.024 containing the new tolerance matched settlement amount.

If the settlement amount is out of the tolerance range, the settlement instructions will not match.

Same tolerance matching logic is applied also to non T2S eligible Baltic instruments settlement instructions.

Allegement 6.4.4.2 A settlement allegement is sent when a settlement instruction received by the corresponding settlement system cannot find a matching settlement instruction during the first matching attempt or pre-defined time period. Consequently, the counterparty indicated in the first settlement instruction receives an allegement notification (in GUI and sese.028 if subscribed) that informs them about the unmatched settlement instruction in the settlement system. The provider of the allegement and its content is either T2S or the CSD system depending on where the settlement of the security happens.

The allegement contains data that is copied from the counterparty’s settlement instruction. In the CSD system’s GUI, it is possible to re-use the allegement data to create a corresponding matching settlement instruction. Data from the allegement is prefilled in the new corresponding settlement instruction creation window. Some matching attribute values indicated in Table 5 are swapped to create a matching instruction (e.g. a DELI instruction is created from a RECE allegement). The participants are able to change the prepared settlement instruction details and input values of other attributes that are not available in the allegement.

35

Some T2S eligible settlement instructions are not subject to the allegement process. Such settlement instructions are determined by the ISO transaction type. Only settlement instructions with a transaction type that is available in an ISO allegement notification message definition are subject to the allegement process. A list of the ISO transaction types that are subject to the allegement process can be found in ANNEX 1 – Transaction types eligible for allegement process.

Removal of an allegement notification 6.4.4.3 If a participant responds to an allegement and sends a corresponding settlement instruction, and the settlement instructions match, the corresponding settlement system generates the removal of the previously sent allegement as it is no longer relevant. When removed, the previously received allegement is no longer active in the CSD system’s GUI and a sese.029 message is sent to the respective participant, if subscribed.

Instructing Party 2 Instructing Party 1 CSD system T2S

SecuritiesSettlementTransactionAllegementNotification sese.028

SecuritiesSettlementTransactionStatusAdvice [Accepted] sese.024

SecuritiesSettlementAllegementRemovalAdvice sese.029

SecuritiesSettlementTransactionInstruction sese.023



SecuritiesSettlementTransactionStatusAdvice [Matched] sese.024

SecuritiesSettlementTransactionStatusAdvice [Matched] sese.024

Figure 6: Messaging Workflow – sending settlement allegement and removal of an allegement message

Cancellation of an allegement 6.4.4.4

In case the initial unmatched settlement instruction is cancelled either by a participant, the CSD or by the settlement system, the counterparty receives a cancellation of the allegement (semt.020). The settlement system cancels an unmatched settlement instruction either when it is pending for a longer period than its recycling period, or the settlement instruction does not pass revalidation (if the static data has been updated in a way that affects the settlement instruction or during the start of day revalidation in T2S). When cancelled, the previously

36

received allegement is no longer active in the CSD system’s GUI allegement section and a semt.020 message is sent to the respective participant, if subscribed.

6.4.5 Maintenance of settlement instruction

Maintenance can be performed on settlement instructions that have not been settled or cancelled. Maintenance is performed by the instructing party of the settlement instruction by submitting maintenance instructions.

The following instructions can be submitted for maintenance of a settlement instruction:

Amendment instruction for the amendment of a limited set of attributes of a settlement instruction before its settlement or cancellation;

Hold/release instruction for suspending or allowing settlement eligibility of a settlement instruction. Hold/release instructions are considered to be a subtype of amendment instructions and therefore all requirements on amendment instructions implicitly apply to hold/release instructions as well;

Cancellation request for the cancellation of a settlement instruction before its settlement.

Amendment 6.4.5.1 Participants can only amend the following process indicators of settlement instruction (in the CSD system’s GUI or by submitting sese.030):

settlement priority,

partial settlement indicator, and

linkage information. Amendment of partially settled instructions is not possible, with the exception of a settlement priority of the unsettled part of the partially settled settlement instruction.

It is possible to modify only one process indicator per amendment instruction. After amendment the new state of the settlement instruction is communicated (GUI or sese.024 if subscribed). The maintained settlement instruction is submitted for revalidation of the business rules.

It is possible to amend either both settlement instruction legs at the same time or only one leg of already matched settlement instructions that were both input as a single instruction depending on the reference used in the amendment instruction:

If maintenance instruction references settlement instruction with the same instruction reference shared by both instructions, then maintenance (including cancellation) is applied to both already matched instructions;

37

If maintenance instruction references settlement instruction with a CSD-assigned unique reference, then maintenance is applied only to a single instruction (delivery side or receive side).

Such functionality does not apply to the already matched settlement instructions if they were matched in the CSD system.

Instructing Party CSD system T2S



SecuritiesSettlementConditionModificationRequest sese.030

SecuritiesSettlementConditionModificationStatusAdvice [Reject/Accept/Complete] sese.031

SecuritiesSettlementTransactionStatusAdvice sese.024 (*)

Figure 7: Messaging Workflow – Amending (also hold/release) settlement instructions

(*) Securities settlement transaction status advice is sent to participant only if Hold/Release indicator was amended with securities settlement condition modification request.

Hold/Release 6.4.5.2 Each party (instructing party, CSD) can hold and release settlement instruction using Hold and Release instructions (GUI or sese.030). Settlement instruction can be initially sent with the Hold indicator (GUI or sese.023 HoldIndicator “true” and relevant Hold code). There are several Hold indicators on settlement instruction.

Party Hold – used by the instructing party, e.g. if the CSD participant’s client lacks securities or cash, the CSD participant can put settlement instruction on hold so that the settlement system does not try to settle it.

CSD Hold – used by the CSD only, e.g. for processing CA.

CSD Validation Hold – used only by CSD e.g. CSD additional validation.

CoSD Hold – used only for conditional settlement in T2S

Hold indicators are independent, e.g. the same settlement instruction can be set on hold by a participant and set on hold by a CSD; therefore, T2S and the CSD allow the putting of settlement instruction on hold by different parties. Settlement instructions with the Hold

38

indicator are not eligible for the settlement process and are pending until they are released by all involved parties.

Settlement instruction on hold can be matched, amended and cancelled. Released settlement instruction is submitted for the settlement eligibility process. After a hold or release, the new state of the settlement instruction is communicated for the instruction (GUI or sese.024).

If settlement instruction remains on Hold at the end of its Intended Settlement Date, the system recycles the instruction following the standard recycling rules.

Cancellation 6.4.5.3 Participants can send cancellation instruction to cancel pending unsettled settlement instructions (GUI or sese.020). CSD operator can also cancel settlement instruction when needed5.

An unmatched settlement instruction is cancelled unilaterally (immediately).

A matched pair of settlement instructions can only be canceled bilaterally, i.e. cancellation requests are required from both counterparties. If a cancellation request is only received from one counterparty, both instructions remain eligible for settlement.

Matched settlement instructions remain active and continue a normal lifecycle until both counterparties submit a valid cancellation request. Cancellation of partially settled instructions results in the cancellation of the remaining unsettled quantity only.

Cancellation is the final status of a settlement instruction; cancelled settlement instructions cannot be changed in any way. During pending cancellation and after successful cancellation the new status of the settlement instruction is communicated (GUI or sese.027).

5 CSD would cancel settlement instructions only in exceptional cases e.g. erroneous transaction.

39


SecuritiesSettlementTransactionStatusAdvice [Cancelled] sese.024

SecuritiesMessageCancellationAdvice semt.020

SecuritiesTransactionCancellationRequestStatusAdvice [Rejected/Accepted/Cancelled] sese.027

SecuritiesTransactionCancellationRequest sese.020

SecuritiesSettlementTransactionAllegementNotification sese.028



Figure 8: Messaging Workflow – Cancelling unmatched settlement instructions



SecuritiesTransactionCancellationRequestStatusAdvice [Accepted] sese.027


SecuritiesTransactionCancellationRequestStatusAdvice [PendingCancellation] sese.027

SecuritiesSettlementTransactionStatusAdvice [CancellationRequested] sese.024


SecuritiesTransactionCancellationRequestStatusAdvice [Accepted] sese.027

SecuritiesTransactionCancellationRequestStatusAdvice [Cancelled] sese.027

SecuritiesTransactionCancellationRequestStatusAdvice [Cancelled] sese.027


40

Figure 9: Messaging Workflow – Cancelling matched settlement instructions

6.4.6 Recycling At end of each settlement day the system recycles all matched pending settlement instructions so that they are submitted to the settlement eligibility process on the next settlement day. The intended settlement date of the settlement instruction is not changed due to recycling. Matched settlement instructions are recycled for an unlimited time until settled or cancelled. The recycling process is the same in both settlement systems – the CSD system and T2S.

All unmatched settlement instructions are also recycled at the end of each settlement day so that they are submitted to the matching process on the next settlement day. The Recycling period of unmatched settlement instructions is 20 business days and after that settlement instructions expire. The recycling period starts from the Intended Settlement Date or the date of the last status change of the instruction. An expired settlement instruction is immediately cancelled by the system (processing status set to Cancelled), cancellation reason “Cancelled by system” is assigned and cancellation is communicated (GUI or sese.024 with CANS code).

6.5 Portfolio transfer Portfolio transfers are transfers of all holdings from one securities account to another securities account, within same account operator or between two account operators. The securities account that is used as the destination in a portfolio transfer needs to be opened with the receiving account operator prior to the transfer.

There are two alternative options to make portfolio transfers.

Portfolio transfer using FOP instructions and

Portfolio transfer using the CSD system’s portfolio transfer functionality.

The message type that is used for portfolio transfer is sese.023 SecuritiesSettlementTransactionInstruction with the relevant Transaction Code – OWNI or OWNE. Account operators can enter settlement instructions either via GUI or messaging and assign them transaction type:

OWNI for portfolio transfer within the same account operator;

OWNE for portfolio transfer between two account operators;

OWNE for external portfolio transfer – between a securities account in the Nasdaq CSD and a securities account in another CSD.

Portfolio transfer can either be initiated by the delivering or receiving account operator. One message per ISIN is required from the delivering party and one message per ISIN is required from the receiving party respectively. Settlement of such instructions follows the standard settlement process in the CSD system or T2S.

41

After completing a portfolio transfer, the delivering securities account may (but does not have to) be closed by the account operator.

Portfolio transfer using the CSD system’s portfolio transfer functionality is commenced using the following principles.

Both delivering and receiving account operators can initiate the portfolio transfer in a special GUI screen.

All securities kept on delivering securities account are subject to transfer.

The counterparty has to accept the delivery in order to the transfer to take place. There may be an additional CSD confirmation6 in place if the delivering and receiving holders are not the same person, etc.

The intended settlement day of the transfer will be the same day when the counterparty’s confirmation is received.

Underlying settlement instructions are created automatically by the CSD system based on the current balance in the deliverer’s securities account in the CSD system (no reconciliation of balances with T2S). Transfer types will be the same as indicated above.

The settlement will follow standard settlement procedures.

After completing the portfolio transfer (successful settlement), the delivering securities account will be closed if the account operator has indicated so when inserting the order.

Portfolio transfer functionality can only be used in order to transfer all securities from a securities account. It is not suitable for transferring part of the balance (e.g. one client’s holdings) from an omnibus account or a nominee account.

6.6 Open-ended fund units

The open-ended fund unit processing service is offered in all three Baltic CSDs. After the migration to T2S, the CSD will provide open-ended fund units settlement service to fund administrators (issuer agent of the investment fund) directly in the CSD system.

Fund administrator acts on behalf of fund unit issuers/managers and offers distribution and settlement services to them. Fund administrators are CSD participants that have been granted the right to instruct on dedicated issuance account in order to increase/decrease the amount of fund units.

Account operators are CSD participants that intermediate investors’ subscription/redemption instructions to the CSD.

Issuance account is a technical account in the CSD system that is used for the subscription (issuance and distribution) and redemption of fund units. The balance of the issuance account

6 CSD system performs validation check on Holder name and ID code of Holder specified on the account. If those

parameters do not match, portfolio transfer order will get status CSD confirmation needed. A CSD operator will check if the CSD participant used a wrong account by mistake or if there is just spelling mistake in the Holder’s name and confirms the portfolio transfer order.

42

represents the total amount of fund units in circulation. Distribution account is not used for open-ended fund units.

Open-ended fund units’ subscription and redemption settlement instructions can be submitted either via messaging or via the CSD system’s GUI. Settlement instructions are validated, matched and settled as per the standard settlement process. All matched settlement instructions are eligible for settlement as soon as the intended settlement date is reached.

A CSD participant that is granted both account operator’s and fund administrator’s role can submit already matched settlement instructions for transfers between the issuance accounts and securities accounts it services. For example, this is the case where the same CSD participant services the investor’s securities account and is the fund administrator and is authorized to debit/credit both –deliverer and receiver – accounts in the CSD system.

6.6.1 Subscription of fund units Fund unit subscription process consists of issuance and distribution of open-ended fund units. The fund administrator can process subscription of open-ended fund units in the CSD system by registering a settlement instruction, to be matched with receiving counterparty’s instruction. Open-ended fund units are issued/distributed from the issuance Account with the Deliver Free of Payment (DFP) or Deliver versus Payment (DVP) settlement instructions of transaction type SUBS.

The settlement instruction from the fund administrator debits the issuance Account. The matching settlement instruction credits a securities account.

6.6.2 Redemption of fund units The fund administrator can initiate redemption of open-ended fund units by registering a settlement instruction, to be matched with delivering counterparty’s instruction. Open-ended fund units are redeemed by submitting settlement instructions with transaction type REDM.

In case of redemption, the open-ended fund units are returned to the fund administrator’s issuance account. The settlement instruction from the fund administrator credits the issuance account and the matching settlement instruction debits a securities account.

6.6.3 Swap of fund units Swap of fund units is process where fund units of one fund are substituted with another fund. This process consists of two actions:

redemption of one fund’s units, and

subscription of another fund’s units.

43

In this case settlement instructions (REDM and SUBS) are linked and settled in accordance with the standard settlement process.

44

6.7 Settlement process in T2S

The processing of settlement instructions results in the transfers of securities and cash assets between accounts. 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 the settlement system.

Considering that the management of securities and cash balances is split between the T2S on one hand, and the CSD system itself on the other hand, a settlement instruction must be dispatched to the correct settlement system, where matching (if necessary), maintenance and settlement is performed.

Figure 10 below describes how standard settlement happens in T2S, when both counterparties are T2S parties and cash leg settlement happens via T2S DCAs.


sese.024 [Accepted/Rejected]

sese.023


sese.024 [Matched]

sese.032

sese.024 [Matched]

T2S automated realignment process, only if counterparty is in different CSD

Settlement day

sese.023

sese.025

sese.025

sese.024 [Matched]

Figure 10: Messaging workflow – standard T2S settlement

The following Figure 11 describes the settlement process, when the counterparty is a linked Investor CSD set up as an external CSD in T2S.

45

Instructing Party 2 - Investor CSD participant

Instructing Party 1 – Nasdaq CSD participant

CSD system T2S


sese.023


sese.024 [Matched]

sese.032

sese.024 [Matched]

T2S automated realignment process, on omnibus account of non-T2S Investor CSD

Settlement day

sese.023

sese.025

sese.025

sese.024 [Matched]

Figure 11: Messaging workflow – counterparty is a linked Investor CSD setup as an external CSD in T2S.

In some cases the CSD system has to contribute in the processing, for instance by settling the cash leg or by settling in some external CSD, and in such cases, its activities are conducted by the T2S. The following Figure 12 highlights the settlement of instructions in T2S and how T2S interacts with the CSD system


Validation

CSD system processes T2S processes


Manage CoSD process

Realign technical accounts

ICP/DCP DCP

Update status and notify generation


Conditional settlement

Automated realignments


Validation

Recycling

T2S

CSD system

Figure 12: T2S and CSD system interaction (high level)

46

6.7.1 Partial settlement

The partial settlement process settles only a fraction of the original quantity or amount when full settlement is not possible due to a lack of securities or cash.

A matched pair of settlement instructions is eligible for partial settlement with the following characteristics:

They are FOP, DVP or DWP settlement instructions;

The partial settlement indicator is not set to " NPAR " in any of the settlement instructions;

They are not linked to any other settlement instruction by a link type “Before”, “After” “With” or by a pool reference.

A settlement instruction is partially settled, in case there are insufficient securities to settle the full quantity and provided the following conditions are met:

The partial settlement window is running, as a partial settlement is active in T2S within specified time periods during the settlement day;

The settlement instructions are eligible to settle partially;

The partial settlement threshold criterion is fulfilled.

The partial settlement indicator is set to allow (or disallow) the partial settlement of a settlement instruction (GUI or sese.023 PartialSettlementIndicator with the relevant value).

According to the ISO standard the partial settlement indicator can take four different values:

Partial settlement is allowed (sese.023 PartialSettlementIndicator “PART”) ;

Partial settlement is not allowed (sese.023 PartialSettlementIndicator “NPAR”);

Partial settlement is allowed but must satisfy a cash value minimum (value defined in static data) (sese.023 PartialSettlementIndicator “PARC”);

Partial settlement is allowed but must satisfy a minimum quantity of securities (quantity defined in instrument definition) (sese.023 PartialSettlementIndicator “PARQ”).

The latter two values specify that a threshold is to be used. There are two partial settlement thresholds that are defined as:

A threshold in “quantity” – meaning the partial settlement cannot take place for a quantity lower than an applicable value, which is the minimum settlement unit of the instrument for the first partial settlement and the settlement unit multiple (lot) for each next partial settlement;

A threshold in “cash value” – meaning the partial settlement cannot take place for an amount lower than an applicable value that can be defined for each currency per each market.

Threshold in quantity is set on instrument level (by CSD) to all T2S eligible instruments and following fields are mandatory static data elements in T2S

minimum settlement unit (MSU) - minimum quantity or nominal of the security for settlement and

47

settlement unit multiple (SUM) - settlement quantity or nominal must be a multiple of the value in this data item. The value must be greater than zero.

In T2S, the threshold in cash value is set by the T2S operator per T2S settlement currency (equivalent to 10 000.00 EUR) and common to all T2S parties. A threshold in “quantity” is defined per financial instrument (minimum settlement unit and settlement unit multiple).Note! If one of the settlement instructions holds the “NPAR” indicator, partial settlement is not possible.

If both parties allow partial settlement with different indicators or with "blank" value, the default threshold is applicable:

The default threshold for FoP instructions is PARQ.

The default threshold for DVP or DWP is PARC. However, if both parties entered PARQ, partial settlement is performed on the quantity threshold.

In any other combination the PARC applies.

Settlement instructions that are settled partially (in two or more parts) still remain as a single instruction in the system – the quantity of already settled and the quantity of remaining unsettled securities is tracked with the instruction.

This means that when the settlement instruction settles partially, sese.025 with the code PAIN is sent (if subscribed) indicating the settled quantity and the settled amount and specifying that there is a part of the settlement instruction that remains unsettled. Partially settled settlement instruction’s settlement history is available and can be tracked using the CSD system’s audit trail.

As the settlement instruction remains unsettled due to lack of cash or securities, sese.024 with code PART is sent (if subscribed) informing about pending status and the unsettled quantity and amount of settlement instruction.

When the last partial settlement takes place, sese.025 with the code PART is sent (if subscribed) confirming settlement of the remaining part of the settlement instruction that was previously partially confirmed.

Instructions that are eligible for submission to partial settlement processing (marked accordingly) and pending due to lack of cash or securities can be settled only during partial settlement windows.

It is foreseen that settlement instructions settle during NTS and those that do not settle due to lack of cash or securities can be settled during RTGS (when lack of cash/securities is eliminated). Settlement instruction with partial settlement indicator will settle partially only if it cannot be settled fully, and only during the below windows dedicated to partial settlement in the T2S settlement day:

RTGS Between 11:00-11:15 RTGS Between 13:00-13:15 RTGS Between 15:00-15:15 RTGS Between 16:45-17:00

48

Since the CSD system’s own settlement engine does not support partial settlement, non T2S eligible Baltic instruments cannot be settled partially.

6.7.2 Conditional settlement

Conditional settlement (CoSD) allows settlement in T2S with the requirement of fulfilling condition outside of T2S before the final (booking) settlement.

The following conditions trigger CoSD in T2S:

When the settlement currency is not a T2S settlement currency (e.g. USD), such a settlement is only possible if both settlement parties are from the same CSD. It is not possible to settle in T2S cross-CSD DVP in a foreign non-T2S currency;

When the settlement counterparty is with a linked (technical) Issuer CSD that is not using T2S.

On the intended settlement date, T2S automatically detects and performs conditional settlement based on such CoSD cases. Settlement instruction that facilitates CoSD is put on “CoSD Hold” and securities are blocked in the deliverer’s securities account. As soon as the external condition (e.g. settlement in USD) is completed, the settlement instruction is released by the CoSD administrating parties (administering party is the party who manages fulfilment of external settlement condition, i.e. CSD.) and the settlement process in T2S is completed.

T2S does not support settlement of non-EUR currencies; all such DVPs are rejected by T2S. In such cases when settlement instruction’s cash leg must settle outside of T2S, ICPs instruct DVP in the respective foreign currency; in turn, the CSD system generates a FOP settlement instruction with the settlement currency, the settlement amount, all other attributes unchanged and sends it to T2S where the CoSD rule is triggered on the intended settlement date, provided that FOP is matched against the counterparty’s settlement instruction. After CoSD activation information is received from T2S, the CSD can settle cash via the cash settlement account provided that the required amount is secured by the cash agent in the respective cash account.

Note: the CSD system retains the original payment type of settlement instruction in the slave copy (in the CSD system), and does not create a separate settlement instruction; the CSD will only adjust the payment type in the message that is sent to T2S. The status advice (and other) messages sent by T2S contain all the reference fields from the original instruction sent by the CSD also including the T2S own reference. The CSD will use those references in order to “link” the status advice with the original instruction, and update the status of the underlying instruction in the CSD system.

In DCP mode, the participant has to forward settlement instructions in non-EUR currencies as FOP instructions, indicating also the settlement currency and settlement amount in the settlement instruction to T2S. In order to secure that such DVP matches the correct counterparty’s instruction in T2S, both settlement parties are advised to use a common reference (optional matching field).

49

Note: DVP settlement instruction in non T2S currency is transformed to FOP settlement instruction (as described above) that contains settlement amount. To avoid cross matching with another regular FOP instruction, T2S introduced a set of following additional matching fields: “Currency”, “Amount” and “Credit/Debit” Indicator for such non-T2S currency FOP instructions.

During CoSD processing, T2S automatically generates settlement restrictions to block and then unblock assets in the CSD participant account. In T2S terminology, those are called Intra-Position Movement Instructions and Intra-Balance Movement Instructions for securities and cash respectively. Please note that Intra position (balance) movement messages from T2S will be sent to the CSD only.

In order to keep participants informed of CoSD progress, the CSD system uses the standard status advice and confirmation messaging on the initial settlement instruction of the CSD participant.

The recycling of CoSD activated instructions is managed automatically by T2S. If cash was blocked, then it is automatically unblocked at the end of the day and re-blocked at the beginning of the following day. If securities were blocked, they remain so from one day to the next, until settlement takes place or CoSD administrating parties send rejection. If the attempt to block securities or cash was unsuccessful, it is recycled and attempted the next day.

Every change to settlement and amendment instructions, including status attributes and associated reasons, is communicated to the sender and instructing party through settlement status advice, settlement confirmation or cancellation request status advice messages (the whole process was described in previous sections).

6.7.3 Nasdaq CSD operational day with T2S

T2S offers continuous securities settlement in two periods: night-time settlement (NTS) and real-time settlement (RTGS). There is a maintenance window when all T2S services are unavailable due to maintenance purposes. Start of Day and End of Day periods are reserved for T2S technical processes preparing for the settlement day or following up on the settlement day. T2S settlement day schedule consist of five major periods as seen on the Figure 13 below (times provided in CET).

50

18:45-20:00 20:00-03:00 ~03:00-05:00 05:00-18:00 18:00-18:45

Start of day Night-time settlement Maintenance window Real-time settlement End of day

Change of Business Date

Deadline (19:00) to accept data feeds from CMS and Payment Banks

Static Data update Instruction

Revalidation based on current static data and Business Date

Valuation of securities positions

and eligible collateral

First cycle Liquidity transfers Settlement

sequences End of Sequence

reporting Static Data update Maintenance

instructions

System maintenance tasks and emergency fixes

No processes running

Real-time settlement Liquidity transfers Partial Settlement

period Real-time Closure

period DVP cut-off Release of EOD

cash restrictions EOD intraday

credit reimbursment

Inbound Liquidity Transfer cut-off

EOD cash sweep Securities

restriction cut-off

FOP cut-off

Stop settlement Recycling and

purging Securities Accounts

consistency check Statement and

reports

Last cycle Partial Settlement End of Sequence

reporting Multiple Liquidity

Provider reimbursement at end of cycle

Real-time settlement if end of last night-time settlement cycle < 03:00

Figure 13: T2S settlement day schedule

The Nasdaq CSD follows the T2S business day after migration to T2S in Final wave in September 2017. The CSD will adopt its operational day to timings set by T2S, see Table 7 below. Events/Deadlines Current practice Timeline with T2S

Start of Day EE – 09:00 LV – 08:00 LT – 08:00

19:45-21:00

Night-time settlement EE, LV, LT – N/A 21:00-04:007

Maintenance window EE, LV, LT – N/A 04:00-06:00

Real-time settlement EE – 09:00-18:00 LV – 08:00-19:00 LT – 08:00-18:00

06:00-19:00

Partial settlement EE, LV, LT – N/A 4 windows: 11:00-11:15 13:00-13:15 15:00-15:15 16:45-17:00

DVP cut-off EE – 16:008 LV – 18:00 LT –17:45

17:00

7 In case the NTS completes before 03:00 then the real-time settlement period starts before the start of the

maintenance window at 03:00. 8 DVP cut-off can be extended until 18:00 if the participants request.

51

Events/Deadlines Current practice Timeline with T2S

FOP cut-off EE – 18:00 LV – 18:00 LT – 18:00

19:00

Mandatory cash sweeps EE – 16:15; 18:15 LV – N/A LT –N/A

18:45 (17:30 optional)

End of Day processes EE – 18:00 LV – 19:00 LT - 18:00

19:00-19:45

Table 7: CSD operational day with T2S

6.8 Settlement process outside T2S In general settlement takes place in the CSD system if counterparties want to settle the settlement instruction with non-T2S eligible securities. Counterparties might be:

Both local participants in the Nasdaq CSD (local settlement) or

One of the counterparties is not a local participant - settlement is available through the Issuer CSD outside of T2S (cross-border settlement).

Settlement of cash leg of those previously mentioned settlement instructions is reflected in cash settlement accounts in the CSD system as described in section 8.2 Cash settlement outside T2S.

Settlement of Lithuanian Government Saving Notes settlement instructions follow the regular settlement process in the CSD system. Estonian III pillar pension fund units settle in a separate ancillary system.

Figure 14 describes the workflow when both participants are local Nasdaq CSD participants.

52

Instructing Party 2 Instructing Party 1 CSD systemCommercial

bank/T2

sese.025

Party 1 Bank

Party 2 Bank

sese.023sese.024 [Accepted/

Rejected]


sese.023

sese.024 [Matched]

Transfer

Confirmation of credit

Settlement day

Credit transfer

Confirmation of debit Transfer

sese.024 [Matched]

sese.025

Figure 14: Messaging workflow – Both counterparties are Nasdaq CSD participants (local settlement)

Note that Figure 14 shows a flow using external cash/commercial bank money. In case of EUR settlement in TARGET2, cash can be settled directly in the cash settlement account without the necessity of transferring cash in and out in between each DVP instructions.

DVP settlement may occur in any of the available currencies provided that both participants/cash agents are set up in the CSD system with a valid cash settlement account in the specific currency.

To support cross-border settlement of non-T2S eligible securities available through Issuer CSDs outside of T2S, there must be a corresponding mirror securities account in the CSD system and the CSD has to have a cash agent at the Issuer CSD to be able to settle against payment. There is at least one mirror securities account for each existing link with an Issuer CSD.

Settlement instructions that are not able to settle on the intended settlement date are recycled according to section 6.4.6 Recycling.

CSD system supports the following settlement methods which are described in more detail below:

Real-time gross: settlement instructions are settled in real time;

Technical netting with optimization: Settles the batch if netting is successful. If the netting is not successful, then the batch is optimized;

Account operators are able to monitor settlement instructions in the CSD system’s GUI or via messaging. If the settlement attempt of the matched pair of settlement instructions is unsuccessful, then the system reports appropriate status reason codes. Each settlement instruction entered in the system passes through eligibility checking, provision checking and posting of cash and securities.

53

A settlement instruction is eligible for settlement at the intended settlement date if it is valid according to (business) validation rules:

settlement instruction is matched,

settlement instruction is not on hold,

intended settlement date is before or equals to the current settlement day and no applicable cut-off is reached,

there are no restrictions related to the securities account, security or party.

If at least one of these eligibility conditions is not fulfilled, the system will report appropriate status reason codes via GUI or messaging (sese.024). Processing of the settlement instruction is stopped until all of the eligibility criteria are met.

If all eligibility criteria are fulfilled, settlement instructions are submitted to provision checking process.

Provision checking is successful if available holdings of cash and securities are sufficient, the cash settlement account is valid for the corresponding currency. If provision checking is unsuccessful, the system will report appropriate status reason codes.

After successful provision checking, the system performs simultaneous and irrevocable securities and cash postings.

6.8.1 Technical netting Technical netting is used to limit the resources needed for settlement by grouping settlement instructions and calculating net quantities and amounts to be settled on an all-or-none basis. Available resources are checked against the net quantities and amounts and thereby reduce the resources needed for settlement. The CSD system performs technical netting for settlement batches consisting of local Nasdaq CSD participant’s eligible settlement instructions (those that have passed the eligibility check). If the settlement instructions are pending due to unsuccessful technical netting, the system will report pending status reason codes.

6.8.2 Settlement optimization When technically netted settlement instructions cannot be settled due to a lack of cash and/or securities, the optimization process can be used to try to exclude settlement instructions that are overdrawing securities and/or cash accounts. Settlement optimization is only performed by the CSD system for local Nasdaq CSD participant’s settlement instructions.

For all excluded settlement instructions status reason code is reported by the system. Settlement instructions that were excluded from the batch are available for the eligibility process in any forthcoming settlement attempt.

54

6.9 Holidays The CSD is open for settlement on the T2S opening days i.e. the CSD system can be used during local holidays if T2S is open on that day.

As T2S facilitates EUR settlement in central bank money, the T2S calendar follows the TARGET2 calendar. Additionally, since the T2S facilitates non-EUR settlement, it operates in accordance with the operating days of the relevant central bank(s).

In general, T2S is opened for settlement from Monday to Friday. T2S is closed for any type of settlement on the following days in all currencies:

All Saturdays;

All Sundays;

25th December (Christmas Day);

26th December (Christmas Holiday);

1st January (New Year’s Day). The free of payment (FOP) settlement of securities is possible on the following TARGET2 holidays:

Good Friday;

Easter Monday;

1st May (Labour Day). For the financial instruments that are only settled locally (not in T2S), the respective market holidays are taken into account, it means that each SSS will follow domestic holidays.

However, according to Eurosystem User Assessment Framework, a CSD must be open whenever Central Bank is opened, therefore whenever the CSD is open, FOP settlement is possible. DVP settlement is possible on the opening days of the respective cash system, i.e. TARGET2 for EUR and, cash correspondent bank’s for respective foreign currency.

Cash settlement in foreign currencies is possible on business days of commercial banks in the respective currency provided that it is also a business day of the Nasdaq CSD. Cross-border settlement in the linked non-T2S Issuer CSD is only possible on matching business days of the Nasdaq CSD and respective Issuer CSD.

6.10 Cross-border links The Nasdaq CSD will have to make amendments to the set-up of the Investor CSD link with Clearstream Banking Luxembourg (CBL) as T2S-out CSD. Settlement with CBL will take place outside T2S. Nasdaq CSD link with CBL enables CSD participants to access non-T2S eligible securities (like US securities, Eurobonds), using CoBM settlement via CBL.

The Nasdaq CSD will have to make amendments to the set-up of the Issuer CSD link with Polish Central Securities Depository (KDPW) that enables KDPW participants to gain access to certain

55

Baltic securities. KDPW will be set up as CSD Participant in T2S and settlement will take place in T2S.

After migration to T2S, Nasdaq CSD is planning to expand its Investor CSD role in T2S by opening an Investor CSD link to Clearstream Frankfurt (CBF). As CBF intends to establish link connections with all CSDs in T2S, provided there is a positive business case Nasdaq CSD participants will be able to request access to all, or nearly all, T2S eligible securities.

56

Restrictions 7

Restrictions cover actions made to prevent or control the movement of holdings in securities accounts. Holdings or a securities account can be restricted for the following reasons:

Court judgment;

Court ruling or an order from an investigative body;

Order of a bailiff;

Plegdor’s and pledgee’s contractual agreement;

Other grounds prescribed in legislation.

In general the restriction application procedure is as follows for the T2S eligible securities:

Restriction instructions are created in the CSD system and immediately mirrored to T2S. Although blocking or pledging order may contain several instruments at the same time, one restriction instruction refers to a single instrument in T2S.

Instructions are validated, and settled in T2S as intra position movements by moving securities from the available position to the restricted position.

o Restriction instructions can be settled either fully or partially depending on the intended purpose (pledge, account arrest, etc.).

Restriction instructions are settled fully or recycled until they can be settled fully or until they are cancelled. No partial settlement is allowed. This is equivalent to T2S blocking as described in T2S UDFS.

Restriction instructions are settled partially, the remaining quantity (if any) is recycled and pre-empted until settled in full or cancelled. Pre-emption means that the partially settled restriction instruction is settled before anything else whenever a new balance becomes available in the account. This is equivalent to T2S reservation as described in T2S UDFS.

The following restriction types are implemented in the CSD system: blocking, pledging, and T2S specific restrictions (e.g. CoSD).

The CSD receives status advice and settlement confirmation from T2S and mirrors it in the CSD system.

7.1 Blocking

The blocking of securities positions or a securities account is the making of an entry concerning a temporary restriction on the disposal of the securities or the securities account. Selected securities balances or a complete securities account may be restricted in order to secure the performance of an act and, in the cases of and pursuant to the procedure provided by legislation, to make a claim for payment or to secure an action. Blocking can be initiated either by account operators or the CSD depending on the nature of the restriction.

57

7.2 Pledging securities balance on an account

Pledging is the process of blocking an investor’s (pledgor) holding on behalf of the pledge contract counterparty (pledgee). The securities are restricted in the plegdor’s account (intra-position movement to a restricted sub-balance in T2S) and cannot be used for any other transaction.

The pledging procedure has specific processing in the system. The CSD system requires two matching instructions, one from the pledgor and one from the pledgee, in order to register a pledge or carry out any other operations on it. These instructions will be entered by the account operators connected to each party in the pledge contract. The CSD has right to intervene in the pledging process in order to fulfil its obligations as the system provider, e.g. in case of the execution of corporate actions, etc.

The following actions can be performed with pledges:

Pledge can be amended unilaterally only if it is not yet matched. An already registered pledge is subject to confirmation by matching against a similar instruction from the pledge’s counterparty’s account operator.

Pledge can be released by the pledgee’s account operator.

Pledged securities can be transferred to a third party (new pledgor) by the pledgor account operator. Pledged securities transferred in this way remain pledged.

Pledges can be executed only by the pledgee’s account operator. Execution by appropriation involves transferring the pledged securities to a new account under the control of the pledgee’s account operator, unblocking them as part of the process.

7.3 Pledging a securities account

A pledge can be registered on a securities account type – a pledge account. The pledge account is opened in the name of the pledgor and any holdings in this account belong to the pledgor. The pledgee is registered in the pledge account as an interested party that may have, but does not have to have, the right to dispose of the holding in case of the plegdor’s failure to fulfil their contractual obligations. All securities balances in the pledge account are automatically covered by the pledge in favor of the pledgee, meaning that securities balances in the pledge account are not moved to the restricted sub-balance.

Settlement restrictions originating from T2S (including reserved, blocked and CoSD blocked securities positions) in the CSD system are described in other sections of this service description.

58

Cash management 8

With migration to T2S, there are the following changes related to cash settlement:

For all T2S eligible securities cash settlement in EUR currency is settled in T2S in DCAs, including corporate action proceeds, except the accrued cash related with deregistered Latvian T2S eligible securities will be paid out to the respective participants as today;

For all T2S eligible securities cash settlement in foreign currency is settled outside T2S using CSD’s commercial banks for respective currency;

For Baltic non-T2S eligible securities cash settlement in EUR currency is settled in T2;

For non-Baltic non-T2S eligible securities cash settlement is managed by the respective Issuer CSD (for example, Clearstream Luxembourg).

Note! In order to provide cash leg settlement in commercial bank money (i.e. through accounts opened with a credit institution) CSD either

needs to become authorized as a credit institution; or

designate one or more credit institutions meeting the requirements Article 54 (4) of the CSDR.

Nasdaq CSD has no intention to become authorized as a credit institution. Thus it is important to note that services requiring the settlement of cash leg in non-EUR currencies in commercial bank money shall be available by using credit institution(s) designated by Nasdaq CSD and is based on reasonable commercial terms. The designated credit institution shall meet requirements of Article 54 (4) of the CSDR in case the total value of such non-EUR cash settlement through account(s) opened with that credit institution(s), calculated over a one-year period, is more than one per cent of the total value of all securities transactions against cash settled in the books of the CSD and exceeds a maximum of EUR 2.5 billion per year.

All changes and new functionality of T2S cash management are described in more detail in the following chapters.

8.1 Cash settlement in T2S Currently, each Baltic CSD has a different EUR cash clearing procedure in TARGET2. After migration to T2S, the Nasdaq CSD follows the T2S cash settlement process on the DCAs.

After migration to T2S, the following clearing and settlement process applies:

Securities leg settlement on T2S securities accounts is administered by the CSD;

Cash leg settlement in central bank money on T2S DCAs is administered by National Central Banks.

59

T2S will check whether there are sufficient securities positions available in the securities accounts and liquidity or credit limit headroom on DCAs prior to settlement. Therefore, T2S Payment Banks have to transfer the necessary liquidity for settlement to DCAs before the start of night-time settlement and, if required, during day time settlement.

During the end of day cash management process in T2S, liquidity from DCAs is automatically transferred to the respective T2 RTGS accounts. This action is also referred as an automated cash sweep in T2S.

The Nasdaq CSD will support CSD participants’ (that are also T2S Payment Bank) liquidity management needs in T2S by offering services mentioned in section 8.1.2 DCAs cash management.

8.1.1 Dedicated cash accounts

T2S DCAs are denominated in a specific T2S settlement currency (at the launch of the T2S, only EUR currency) and used for the settlement of cash transactions arising from T2S, such as cash leg settlement of settlement instructions, corporate actions etc. T2S DCAs are opened by any National Central Bank participating in T2S.

Link between DCA and RTGS account 8.1.1.1

RTGS Payment Module (PM) accounts and DCAs fall under the legal perimeter of TARGET2. Therefore, T2S DCAs are opened by National Central Banks to entities that are eligible to open PM accounts, meaning that entities that are eligible to open PM accounts are also eligible to open DCAs. Central Banks are responsible for the maintenance of DCAs and linking DCAs and RTGS PM accounts (main PM account) to which the liquidity from the DCA is reimbursed after the end of each settlement day.

DCAs are also used by the Central Bank for provision of intraday credit through T2S auto-collateralisation. Due to that, T2S requires the creation of Credit Memorandum Balance (CMB) whenever a new cash account is set up by the relevant Central Bank.

Link between DCA and Securities Account 8.1.1.2

The CSD is responsible for setting up the links between securities accounts and DCAs in T2S, for the settlement of the cash leg of the settlement instructions related to the given securities account. As T2S DCAs are under the responsibility of the National Central Banks; therefore, CSD participants must inform the CSD about the DCAs to be used to settle securities against cash in T2S. Securities accounts that are T2S accounts must have at least one DCA, but there can be more than one DCA per securities account in the CSD system. The main rule is that a default DCA is set in the CSD system on participant level (via GUI) for each account operator. If there are DCAs

60

in different currencies, the account operator must assign a default DCA for each applicable currency.

Whenever an account operator opens a new securities account without specifying the DCA, the CSD links the default DCA to this new securities account in T2S. If the account operator does not want to apply a default DCA to the securities account, then it is possible to assign alternative DCA after the securities account opening in the CSD system’s GUI. If the account operator has several DCAs linked to single securities account in T2S, T2S uses the default DCA of that securities account during cash settlement. Should T2S use other than default DCA a CSD participant is required to specify the respective DCA in the settlement instruction.

Credit Memorandum Balance 8.1.1.3 Credit Memorandum Balance (CMB) is a tool that T2S uses to monitor securities settlement and track the provision of credit from central bank to payment bank via the primary CMB (for CB auto-collateralization), or payment bank to their clients via the secondary CMB (for client collateralization).

Granting intraday credit by a central bank to its payment banks entails the creation of the primary CMB linking the DCAs of a Payment bank with the relevant collateral receiving securities accounts, where the Central Bank receives the securities.

The secondary CMB is created when the payment bank grants intraday credit to its clients holding securities accounts but no DCAs. As one or more securities accounts can be linked to the same DCA, the payment bank must configure a secondary CMB for each client authorized to use the payment bank’s DCA, meaning that the DCA may be linked to several secondary CMBs.

A CMB is a necessary static data element for each DCA; the DCA is always linked to the securities account by a primary CMB. The CSD is responsible for creating and administrating links via the CMB between DCAs and securities accounts in T2S.

8.1.2 DCAs cash management At the start of the T2S business day, DCAs are empty due to a cash sweep at the EOD. Just before the EOD period, at 18:45, all remaining cash on DCAs is automatically swept to the linked main RTGS account.

Payment Banks are responsible for liquidity management in T2S. Therefore, it is necessary that DCAs hold sufficient liquidity in time for the start of NTS DVP settlement.

Payment Banks are able to handle liquidity directly in T2S (by being cash DCP), via TARGET2 (using T2 value added services) or via the Nasdaq CSD. It means that Payment Banks can monitor DCA information via T2, where available balance is displayed, or via the CSD system where participants are able to make a query to get the most recent information from T2S e.g. T2S DCAs current and forecast cash balance.

61

The CSD offers the following services to support their customer’s cash management in T2S:

Liquidity Transfers o Internal Liquidity transfers between T2S DCAs of the same Payment Bank o Outbound Liquidity transfers from T2S DCA to main RTGS account

CSD participants (that are also T2S Payment Bank) that are set up as ICP or DCP in T2S are able to use the aforementioned liquidity transfers functionality in the CSD system’s GUI. After CSD participant submits the liquidity transfer in the CSD system’s GUI, the system sends the corresponding (camt.050) liquidity transfer request to T2S. T2S responds by (camt.025) either confirming or rejecting the initiated liquidity transfer. CSD participant is able to follow the status of liquidity transfers in the CSD system’s GUI.

T2S DCAs current and forecast cash balance

CSD participant is able to request a view of the latest information about the current balance of a T2S DCA in the CSD system’s GUI, and about the forecast balance of such an account. After CSD participant submits request, the system creates a DCA balances query to T2S (camt.003) and displays the full set of response data received from T2S in the CSD system’s GUI (camt.004).

T2S DCA postings T2S query which gives the latest settled cash transactions information. When CSD participant has requested to view the latest information from T2S in the CSD system’s GUI, the system creates a T2S DCA posting query (camt.005) to T2S and displays the response data (camt.006) received from T2S. It is possible to export displayed data to a spreadsheet file.

In order to use CSD cash management services, the CSD needs to be authorized by the respective DCA holder (T2S Payment Bank) or their liquidity providing RTGS account holder to have access to the respective DCA.

8.1.3 T2S auto-collateralisation T2S auto-collateralisation is a service offered by T2S to the central bank and payment/settlement banks to provide intraday credit to cover a lack of cash for securities transactions settlement (in the exchange of eligible securities).

There are two types of intraday credit provision procedures using T2S auto-collateralisation offered by:

Central bank (central bank collateralisation) covering lack of cash on the T2S DCA managed in its books;

Payment bank (client-collateralisation) covering insufficient external guarantee headroom for their clients.

62

Central Banks have to determine the collateralisation procedure in T2S which they opt for in all their central bank collateralisation operations. According to CSD information on T2S auto-collateralisation, all three Baltic Central Banks have chosen the REPO procedure.

For client-collateralisation operations, T2S only supports the REPO procedure.

In the REPO procedure, selected collateral is transferred from the securities account where it is held to a securities account of the credit provider.

Before offering intraday credit through auto-collateralization in T2S, credit providers (Central Bank or Payment Bank) must configure static data of securities accounts and eligible securities for collateral. National Central Banks are responsible for setting up the Central Bank collateralization in T2S.

To make use of central bank auto-collateralization, the DCA holder must have their own RTGS account (that belongs to the same legal entity) in the books of the same central bank as the DCA. Consequently, a party that does not currently have its own RTGS account has to open one to benefit from central bank auto-collateralization in T2S.

Central banks have to determine the securities account where the selected collateral has to be stored in case of intraday credit provision for each T2S DCA held in their books. The CSD of the credit consumer of an intraday credit through auto-collateralization must set links between the T2S DCA and the securities account which can be used to supply the collateral needed.

Central banks are required to provide T2S the list of securities accepted as collateral and, on each settlement day, the associated prices in the currency of the intraday credit.

Central bank auto-collateralization is triggered when the buyer’s DCA balance is insufficient to settle the settlement instruction. Liquidity obtained from auto-collateralization is used immediately by T2S to settle pending instructions due to lack of cash.

The credit provided in auto-collateralisation can be secured using securities already held by the buyer ("collateral on stock") or the securities that are being purchased ("collateral on flow”). Automatic reimbursement of central bank auto-collateralisation is triggered automatically by T2S at 16:30 (CET).

8.2 Cash settlement outside T2S The CSD system supports EUR settlement of non T2S-eligible securities, settlement of foreign currencies between CSD participants or with counterparts in a linked Investor CSD and DVP settlement for all the currencies supported by a linked Issuer CSD, including EUR, USD and others of cross-CSD instructions with counterparts in a linked Issuer CSD.

The Nasdaq CSD operates several bank accounts held at a commercial or central bank in order to receive, hold and transfer cash used in the various CSD processes, each in the relevant currency, to support the abovementioned settlement to CSD participants.

For that reason, the CSD uses the following bank accounts:

63

A Central Bank: for EUR (to settle in the CSD system, settlement instructions of non T2S-eligible instruments).

A Commercial Bank: for USD or possible other currencies in future, in order to settle instructions in those currencies between CSD participants or with counterparts in a linked Investor CSD.

A CSD’s cash correspondent (bank or linked CSD holding banking license) in the Issuer CSD: for EUR, USD and any other supported currencies, in order to settle DVP cross-CSD instructions with counterparts in a linked Issuer CSD.

Cash agents have to provide the required settlement cash amount in the respective CSD’s bank account on the expected settlement date of the settlement instruction. In those cash settlement accounts, the CSD keeps the following sub-bookkeeping records:

Records related to cash amounts transferred to the CSD’s bank account by the cash agent (liquidity transfer in);

Cash debits and credits as a result of settlement (DVP or corporate actions);

Records related to cash amounts transferred out from the CSD’s bank account to the cash agent’s external cash account (liquidity transfer out).

The balances on the cash settlement accounts are always swept out during the settlement day as part of the DVP settlement or Corporate action proceeds settlement (for T2S eligible Baltic instruments in foreign currency and for foreign instruments that are settled in the Issuer CSD) and/or at the end of the settlement day to the linked external bank account of the cash agent (for non-T2S Baltic instruments in EUR).

It is important to note that the DVP settlement of T2S eligible Baltic instruments in foreign currency, which is accepted as settlement currency in the CSD, is commenced on gross basis separately for each DVP. The settlement amount is transferred from the CSD’s cash account in the commercial bank to the seller’s CSD participant’s cash agent’s external cash account for the respective currency.

The CSD will provide the following liquidity management services to cash agents:

Liquidity transfers: o transfer-in: from an external bank account to a cash settlement account within

the CSD; o liquidity return: from a cash settlement account within the CSD to an external

bank account.

Cash forecast and monitoring cash usage by account operators or cash agents, based on the known information in the CSD system.

A cash agent can also provide cash agent services to account operators who are not themselves authorized as cash agents in the CSD or who are not authorized to settle in that specific currency.

Through cash forecasts and the CSD system’s GUI, cash agents can monitor the net settlement amounts of the account operators that the cash agent provides liquidity services to.

64

Before settlement starts on ISD, cash agents transfer sufficient cash to the CSD’s account in TARGET2 or to commercial bank or to the cash account opened in the linked Issuer CSD, i.e. CBL to enable settlement for those account operators. These types of cash transfers can take place before the start of settlement on ISD but can also happen multiple times during ISD depending on, and triggered by, account operators’ intraday settlement obligations during the settlement cycle on ISD.

If cash agents have a demand of excess cash from CSD at the end of ISD and intraday, the cash amount is automatically returned by the CSD to the cash agent’s pre-defined cash account with TARGET2. Also cash agents can request for intraday transfer of excess cash to their external cash accounts.

All liquidity transactions (transfer-in, liquidity out) are mirrored in the respective cash agent’s cash settlement account in the CSD system.

8.3 Cash forecasts In order to simplify the funding of cash for settlement, cash forecast is provided to customers by the Nasdaq CSD.

8.3.1 Cash forecast from CSD system The cash forecast provides CSD participants information on their cash settlement needs and, based on that, they are able to provide and use liquidity effectively. The cash forecast only considers known information that is in the CSD system and is available for cash agents and settlement parties in GUI. The cash forecast includes the following information:

Net total of accepted pending settlement instructions (irrespective of place of settlement – the CSD system or T2S);

Cash balance of the cash settlement account (only information on the cash balances in the CSD system are included). The information is available to the cash agent only;

Expected cash balance – which is the sum of cash balance and net total of pending settlement instructions.

As stated above the cash forecast also includes pending settlement instructions that are pending settlement in CSD system or T2S. It should be noted, as settlement takes place continuously during the day in T2S and, additional incoming information from T2S might cause delays in reflecting changes in the cash forecast available from the CSD system.

For T2S settlement cash forecast includes information gathered from accepted pending settlement instructions in the CSD system.

65

The cash forecast on non-T2S settlement is calculated according to settlement instructions information and cash information available in the CSD system. As securities and cash settlement happens in the CSD system, cash agents are able to receive up to date information at all times during the business day.

8.3.2 T2S cash forecast In order to get the most precise data from T2S, the CSD will provide the possibility for a CSD participant – Payment Bank in T2S to query T2S cash forecast, T2S DCA cash balance and T2S DCA cash postings. The queries are available in the CSD system GUI and responses from T2S are also displayed in GUI. This service is available, provided that the Payment Bank has authorized the CSD via PoA and the respective NCB has made the relevant configuration in the T2S.

T2S cash forecast query provides information on the cash need of the T2S party DCA, based on the current DCA cash balance, liquidity transfer orders, cash needs for pending DVP transactions, as well as the amount of outstanding intraday credit from auto-collateralisation.

CSD participants, who are also Payment Banks in T2S, will be able to request the following cash forecast queries from T2S via the CSD system GUI:

Current Settlement Day Cash Forecast Query , returns information about cash needs for transactions pending to settle during the current settlement day;

Following Settlement Day Cash Forecast Query, returns information for the next settlement day and considers instructions that are expected to be settled the following settlement day.

The forecast is calculated based on the settlement instructions of T2S party securities accounts linked to the respective DCA. DCA holders have to grant access to the CSD via PoA to query and receive such information from T2S.

66

Reporting 9 The CSD system provides CSD participants various types of standardized reports and outbound messages which they can subscribe to. A spectrum of ISO20022 messages are offered for the following service areas:

Account set up and maintenance;

Securities settlement;

Statements, reconciliation.

For information where T2S is the settlement application, the CSD system is updated as soon as the respective message with the latest status is received from T2S by the CSD system.

T2S is considered the settlement application for the following:

Settlement instructions, maintenance instructions, created in T2S or after they are sent by the CSD system to T2S;

Allegements created in T2S;

Restriction instructions created in T2S or after they are sent by the CSD system to T2S;

Securities balances of T2S eligible securities;

Financial instruments, where CSD is not the SME in T2S;

T2S DCAs.

The following settlement related statements are available in the CSD system’s GUI and via messaging:

Securities Holdings;

Posted Securities Transactions;

Pending Instructions;

Allegements;

Cash Balances;

Posted Cash Transactions;

Cash Forecast.

The following settlement related statements are only available in the CSD system’s GUI:

Short position report.

All the above listed statements will return data available in the CSD system, regardless of whether the CSD system or T2S is the settlement application.

Note: Statement of pending transactions communicates pending reason codes only if the settlement instruction is matched and pending and pending reason code is provided (either lack of cash, lack of securities, settlement instruction on hold, etc.). For settlement instructions that are unmatched, no reason code is provided by T2S and subsequently by the CSD system.

67

9.1 Report subscriptions A CSD participant is able to set up any required subscriptions in the CSD system’s GUI. CSD participants can set up report subscription:

on their CSD participant level (subscription applies to all data, e.g. securities accounts, of the participant);

on the securities account level (subscription apply to the specific securities account and overrides or is addition to subscriptions on the participant level).

Both level subscriptions can exist in parallel for the same recipient. For example, a recipient subscribes to receive the same statement on a participant level every month, but for a specific account every day.

The following statements are available for subscription:

Statement of Holdings (semt.002);

Statement of Transactions (semt.017);

Statement of Settlement Allegements (semt.019);

Statement of Pending Instructions (semt.018);

Issuers and Instruments Reference Data (Proprietary Securities Reference Data Message - containing information on financial instrument data that can be held on accounts serviced by an account operator).

All the above listed reports will return data available in the CSD system, regardless of whether the CSD system or T2S is the settlement application.

Statements are generated at configured predefined frequency or are triggered by activity; for example a CSD participant has subscribed to receive the Statement of Transactions on a daily basis irrespective of whether there has been any activity. If no posted transactions have been reported, a participant will receive an empty statement.

9.2 Queries By using a query message (semt.021) a CSD participant can request from the CSD system the following statements on an ad hoc basis:

Statement of Holdings (semt.002);

Statement of Transactions (semt.017);

Statement of Pending Instructions (semt.018);

Statement of Settlement Allegements (semt.019).

CSD participants are able to make a query in the CSD system’s GUI to get the most recent information from T2S on the following:

T2S cash forecast (see section 8.3.2 T2S cash forecast for more details);

68

T2S DCA cash balance (see section 8.1.2 DCAs cash management for more details);

T2S DCA postings (see section 8.1.2 DCAs cash management for more details);

69

Message subscriptions 10 Subscriptions are a way used to request the CSD to deliver, according to conditions outlined in the subscription, messages and reports to the specified recipient.

CSD participants can configure set of outbound messages from the pre-defined list in the CSD system that they, investor or any interested party want to receive from the CSD system. The configuration of message subscriptions provides flexibility as participant can configure different recipients of the same message (provided that recipient is authorized to receive the subscribed information), frequency (mostly applicable to reports which can be generated on daily, weekly etc. basis), whether complete9 or delta10 report or empty report shall be sent and specify optional validity period for each subscription.

A CSD participant is able to set up required message subscriptions in the CSD system’s GUI. CSD participants can set up message subscription:

on their CSD participant level (subscriptions will apply to all data, e.g. all securities accounts of the participant);

on the securities account level (subscription applies to the specific securities account and overrides or is addition to subscriptions on the participant level).

Both level subscriptions can exist in parallel for the same participant.

Note, not all the messages are available to be subscribed on the account level, for example, settlement allegement messages which are created based on the counterparty’s accepted settlement instruction must be subscribed on the participant level as it is not mandatory for a participant’s settlement counterparty to indicate the participants securities account.

As an exception to the subscriptions the CSD system sends out following messages regardless whether the recipient has subscribed to this specific message or not:

Reactions on erroneous inbound messages, for example: o Technical error reporting (MessageReject); o Status advice messages (sese.024, sese.027, sese.031, seev.034, seev.041)

related with rejection of the instruction; o Query status advice (sese.022); o Account management status report (acmt.006) sent due to rejection.

Request-response messaging. This means that a message from the CSD system is sent to a participant only as a response to a request received from a participant – never initiated by the CSD system itself. For example, the participant can query report and CSD system will generate and send the requested report.

9 Complete reports cover the current business day and contain information at the time of the creation of the

report. 10 Delta reports also cover the current business day, but contain information that was changed after the previous

report was created.

70

Market specificities 11

11.1 Shareholders’ disclosure

The Latvian and Lithuanian CSDs are operating in the indirect holding market where end-investor information is not available at the CSD level. In this case, an issuer, issuers’ agent or authorized third party can request the CSD to compile a full list of holders of securities as of a specific date. Special system ESIS is used for processing shareholders disclosure requests and compiling the full list of shareholders. ESIS has a separate web based GUI that will allow issuers, issuer agents and account operators to request disclosure of shareholders list. ESIS GUI is not integrated with the CSD system and therefore will have separate users and user authentication in the system. Communication with ESIS is available in A2A mode and via GUI. The account operators will receive the shareholders’ disclosure request (in the agreed format of Proprietary Shareholder Disclosure Request) from the ESIS system via MQ. In order to send to the CSD list of holders as of the record date, a participant sends the shareholders’ disclosure message (in the agreed format of Proprietary Shareholder Disclosure) via MQ to the ESIS system. The ESIS system produces status advice messages to the participants, informing them if the disclosure message is rejected, accepted or missing. Detailed information on the messaging to be used to request and disclose holders is available in the Nasdaq CSD Message Usage Guidelines. Issuers, issuers’ agents, the CSD itself or any other authorized institution can receive the full list of shareholders by downloading it from the ESIS or via messaging (if subscribed).

11.2 Latvian Initial Register The Nasdaq CSD remains the holder and administrator of the Latvian Initial Register. CSD participants are able to execute de-registration from the Initial Register by sending a regular settlement instruction (via GUI or sese.023 message) with certain set of mandatory values.

In case a settlement instruction does not contain all the mandatory attributes or the attributes contain incorrect information, it will not be considered as a settlement instruction intended for de-registration. CSD participant will only receive status advice (sese.024), that CSD has accepted settlement instruction. The CSD will not respond with a matching settlement instruction, meaning that CSD participant will not receive status advice message (sese.024) with status Matched, and the settlement will not be executed. If settlement instruction is not valid then such instruction will be rejected by CSD and CSD participant will receive error message with rejection reason.

11.3 Non-T2S eligible securities settlement Lithuanian Government Saving Notes settle just like any other security, meaning that settlement instructions follow the regular settlement process in the CSD system. Estonian III pillar pension fund units settle in a separate ancillary system.

71

ANNEX 1 – Transaction types eligible for allegement process ISO Code Name Name ISO Definition

CNCB CentralBankCollateralOperation Relates to a collateral delivery/receipt to a national central bank for central bank credit operations.

BSBK BuySellBack Relates to a buy sell back transaction.

COLI CollateralIn Relates to a collateral transaction, from the point of view of the collateral taker or their agent.

COLO CollateralOut Relates to a collateral transaction, from the point of view of the collateral giver or their agent.

NETT Netting Relates to the netting of settlement instructions.

OWNE ExternalAccountTransfer Relates to an account transfer involving more than one instructing party (message sender) and/or account servicer (message receiver).

OWNI InternalAccountTransfer Relates to an account transfer involving one instructing party (message sender) at one account servicer (message receiver).

PAIR PairOff Relates to a pair-off: the transaction is paired off and netted against one or more previous transactions.

PLAC Placement Relates to the placement/new issue of a financial instrument.

PORT PortfolioMove Relates to a portfolio move from one investment manager to another and/or from an account servicer to another. It is generally charged differently than another account transfer, hence the need to identify this type of transfer as such.

REAL Realignment Relates to a realignment of positions.

REDM Redemption Relates to a redemption of funds (funds industry only).

REPU Repo Relates to a repurchase agreement transaction.

RVPO ReverseRepo Relates to a reverse repurchase agreement transaction.

SECB SecuritiesBorrowing Relates to a securities borrowing operation.

72

ISO Code Name Name ISO Definition

SECL SecuritiesLending Relates to a securities lending operation.

SUBS Subscription Relates to a subscription to funds (funds industry only).

TRAD Trade Relates to the settlement of a trade.

TRPO TripartyRepo Relates to a triparty repurchase agreement.

TRVO TripartyReverseRepo Relates to a triparty reverse repurchase agreement.

TURN Turnaround Relates to a turnaround: the same security is bought and sold to settle the same day, to or from different brokers.

AUTO AutoCollateralisation Relates to an auto-collateralisation movement.

CLAI MarketClaim Relates to a market claim.

CORP CorporateAction Relates to a corporate action.

ETFT ExchangeTradedFunds Relates to an ETF creation or redemption.

73

ANNEX 2 – Overview of availability of main functionality in the CSD system’s GUI and A2A mode Service/Functionality CSD system’s GUI A2A

Settlement instructions

Create settlement instructions X X

Settlement instruction maintenance X X

Settlement instruction cancellation X X

Instruction status X X

Settlement status and confirmation X X

Allegement management X X

Stock exchange trade settlement

Information on the trade legs captured from the trading system

X

Confirmation and enrichment of the trade legs

X X

Settlement instruction generation notification

X X

Hold and release of settlement instruction

X X

Settlement status and confirmation X X

Liquidity management

CSD system cash forecast X X

T2S cash forecast X

Liquidity transfer request X

Liquidity monitoring X

Account restrictions

Pledging X

Create pledge instructions X

Pledge instruction maintenance X

Pledge instruction cancellation X

Pledge instruction status X

Pledge transfer X

Corporate actions

Corporate action notifications X X

Corporate action preliminary movement advice

X X

Corporate action confirmations X X

Corporate action election instructions, status and cancellation

X X

Information on the tax withheld per account

X

Detected market claims and transformations

X X

74

Service/Functionality CSD system’s GUI A2A

Standard reporting and reconciliation X X

Securities reference data X X

Account maintenance X X

Message subscription maintenance X

CSD system user account maintenance11 X

11

CSD participant with administrator user account

75

ANNEX 3 – Table of ISO20022 messages Message ID Message name Section

Securities settlement

sese.023 SecuritiesSettlementTransactionInstruction 6.7; 6.8

sese.024 SecuritiesSettlementTransactionStatusAdvice 6.7; 6.8

sese.025 SecuritiesSettlementTransactionConfirmation 6.7; 6.8

sese.020 SecuritiesTransactionCancellationRequest 6.4.5.3

sese.027 SecuritiesTransactionCancellationRequestStatusAdvice 6.4.5.3

sese.028 SecuritiesSettlementTransactionAllegementNotification 6.4.4.2

sese.029 SecuritiesSettlementAllegementRemovalAdvice 6.4.4.3

sese.030 SecuritiesSettlementConditionsModificationRequest 6.4.5

sese.031 SecuritiesSettlementConditionModificationStatusAdvice 6.4.5

sese.032 SecuritiesSettlementTransactionGenerationNotification 6.4.2

semt.020 SecuritiesMessageCancellationAdvice 6.4.4.4

Account management

acmt.001 AccountOpeningInstruction 3.1

acmt.002 AccountDetailsConfirmation 3.1

acmt.003 AccountModificationInstruction 3.1

acmt.004 GetAccountDetails 3.1

acmt.006 AccountManagementStatusReport 3.1

Reconciliation

semt.002 SecuritiesBalanceCustodyReport 9

semt.017 SecuritiesTransactionPostingReport 9

semt.018 SecuritiesTransactionPendingReport 9

semt.019 SecuritiesSettlementTransactionAllegementReport 9

semt.021 SecuritiesStatementQuery 9

sese.021 SecuritiesTransactionStatusQuery 9

sese.022 SecuritiesStatusStatementQueryStatusAdvice 9

Cash management (T2S)

camt.003 GetAccount 8.1.2

camt.004 ReturnAccount 8.1.2

camt.005 GetTransaction 8.1.2

camt.006 ReturnTransaction 8.1.2

camt.025 Receipt 8.1.2

camt.050 LiquidityCreditTransfer 8.1.2

ANNEX 4 – T2S settlement flow

Delivery/receive versus payment settlement (both counterparties in T2S)

Paym

ent

Ban

kA

ccou

nt

Ope

rato

rC

SDT2

ST2

Abbreviations: SI - settlement instruction, T2 - Target2, T2S - Target2-Securities, DCA - dedicated cash account

Receive instruction from client

SI receipt and validation

Receive settlement confirmation

SI eligible for settlement?

Enough cash& securities?

Transfer cash to T2S DCA (through T2)

Send settlement confirmation

SI to CSD

Settlement

Receive cash to T2S DCA

Is matching possible?

Allegement to counterparty

Send pending SI report

SI to T2S


Matching

Receive pending SI report

Perform relevant adjustments

(provide SI, cash, securities)

Posting balances based on settled SIs

Send status update

Receive status update



yes

no

yes

no

74

ANNEX 5 – Local settlement flow (both counterparties in Nasdaq CSD)

Delivery/receive versus payment settlement (both counterparties in Nasdaq CSD)Pa

ymen

t B

ank

2A

ccou

nt

Ope

rato

rC

SD s

yste

mT2

Paym

ent

Ban

k 1

Abbreviations: SI - settlement instruction, T2 - Target2, CSA – cash settlement account

Receive instruction from client



SI eligible for settlement?

Enough cash& securities?

Transfer cash to CSA (through T2)

Send settlement confirmation

SI to CSD

Settlement

Receive cash to CSA

Is matching possible?

Allegement to counterparty

Send pending SI report

Matching

Receive pending SI report

Perform relevant adjustments

(provide SI, cash, securities)

Send status update

Receive status update



yes

no

yes

no

Transfer cash from CSA (through T2)

Receive cash

75

NASDAQ CSD SERVICE DESCRIPTION€¦ · NASDAQ CSD SERVICE DESCRIPTION . 1 ... CMB Credit Memorandum Balance ... T2S UDFS T2S User Detailed Functional Specifications

Documents