Service description for KDD members in T2S environment

Transcription

1 Service description for KDD members in T2S environment Version 3, September 2016

2

3 CONTENTS A. GENERAL INFORMATION... 3 B. BUSINESS AND OPERATIONAL ASPECTS OF KDD S SERVICES IN T2S ENVIRONMENT STATIC DATA KDD members Securities Securities accounts and cash accounts Transposition of securities accounts structure from Central registry to T2S Securities account structure changes in Central registry... 5 Information on DCAs in Central registry INSTRUCTION PROCESSING AND SETTLEMENT Settlement day timetable T2S instruction types FOP and DVP transaction processing Instruction matching... 9 Settlement optimisation Instruction recycling... 9 Instruction linking Settlement of DVP and FOP instructions Settlement among KDD members and members of linked CSDs Stock exchange trades settlement Sale of pledged securities (booked on securities accounts opened with several members) by authorised member and usage of Registry codes Stock exchange trades settlement workflow Risk management on stock exchange settlement Use of restrictions on T2S securities accounts T2S instruction maintenance Instruction amendments Instruction cancelation Instruction Hold/Release Liquidity transfers (Auto)collateralisation Securities accounts to be used in (auto)collateralisation CORPORATE ACTIONS Corporate actions on stocks Concurrent securities issuance/deletion Issuance/deletion via interim account Reorganisations Distributions Corporate actions on flows transaction management Transformation of pending transactions Market claims C. TECHNICAL ASPECTS OF KDD SERVICES AND REQUIRED ADAPTATIONS ON MEMBERS SIDE TECHNICAL CONNECTION BETWEEN KDD AND T2S MEMBERS CONNECIVITY OPTIONS TO KDD OR T2S Indirect connection to T2S Direct connectivity to T2S CONNECTIVITY RELATED ADAPTATION REQUIREMENTS FOR MEMBERS Indirectly connected members Changes related to static data and account structure Settlement related changes Corporate actions processing Changes in communication with KDD i

4 Requirements for indirectly connected members Directly connected members Changes in services and communication with KDD T2S services available to directly connected members Requirements for directly connected members ii

5 A. GENERAL INFORMATION Document represents current version of integration model (Version 2, February 2016) depicting most relevant impact on KDD services. Further modifications, based on KDD decisions, modification of T2S functionalities or market standards are possible. Members will be informed on any further modifications and will receive final detailed description of KDD services in T2S environment and necessary modifications on members side, enabling modification of own procedures. KDD will also inform members on tests and migration procedures. When forming KDD integration model with T2S, KDD considered current services and functionalities, and anticipated modifications in own services due to T2S requirements. Model foresees direct integration of KDD s information system of central registry with T2S system, which requires opening of members technical omnibus accounts on T2S platform. This model is considered as optimal solution in terms of business efficiency, further evolution of KDD s services and Slovenian capital market. All modifications are made as to keep members adaptation costs as low as possible. Model was discussed by National T2S User Group, which gave final confirmation with no open technical or operational issues. Further information on integration of KDD infrastructure with T2S platform are available on: KDD web page including Q&A section (Slovenian version only); ECB web page Bank of Slovenia web page including minutes of National User Group meetings. 3

6 B. BUSINESS AND OPERATIONAL ASPECTS OF KDD S SERVICES IN T2S ENVIRONMENT 1. STATIC DATA KDD continues to record static data in Central registry of dematerialised securities (CRVP). In addition and to the extent necessary for T2S operations, KDD maintains static data related to KDD members, securities, securities accounts and system settings in T2S system KDD members KDD members are identified in T2S as KDD Party using BIC codes these are necessary for any KDD member. Any KDD member as KDD party is uniquely identified with both KDD BIC code (Parent BIC) and its own BIC code. KDD takes care of members static data setup in T2S. KDD member, that acts as a payment bank being Bank of Slovenia s party is uniquely identified with both Bank of Slovenia s BIC code (Parent BIC) and its own BIC code. Bank of Slovenia takes care of T2S static data of payment banks that have DCAs opened with the Bank of Slovenia Securities All securities issued with KDD are settled in T2S. KDD sets up and regularly maintains securities static data in T2S Securities accounts and cash accounts Transposition of securities accounts structure from Central registry to T2S Transposition is based on layered model, namely: Technical settlement accounts are opened on T2S platform to enable T2S settlement; KDD s Central registry largely retains pre-t2s account structure and, in addition to that, opens some dedicated accounts, both to enable Central registry bookings based on transactions settled in T2S or settled in KDD internally; KDD members (and KDD s) DCAs, supporting settlement of cash leg of transactions, are opened by the Bank of Slovenia. Technical securities accounts in T2S reflect account balances from Central registry accounts, whereby each account in Central registry is linked to one T2S technical account. Account transposition characteristics are as follows: KDD opens and configures T2S securities accounts, based on Central registry accounts characteristics; Total volume of each ISIN issued in Central registry is reflected in T2S accounts balances; Transposition of each account between Central registry and T2S is made using one of three available methods: 4

7 o 1:1 without restrictions - Respective account in Central registry is copied to T2S in 1:1 mode, whereby KDD does not allow recording of any third party rights or other legal facts to securities booked on such account in Central registry; o N:1 More accounts opened in Central registry are transposed into single T2S account. Those accounts allow recording of third party rights or other legal facts in Central registry. o 1:1 with restrictions - Respective account in Central registry is copied to T2S in 1:1 mode, whereby KDD allows recording of third party rights or other legal facts to securities booked on such account in Central registry. Each KDD member is allowed to open only one N:1 account in T2S. If custody codes are assigned to respective member, additional N:1 account will be opened for each such code. Third party rights and other legal facts recorded in Central registry are not transposed to T2S. Hence, KDD validates each transaction involving such accounts (allowing recording of third party rights or other legal facts Central registry) before settlement is attempted in T2S. Validation rule applied to respective instruction depends on securities account type: o Accounts transposed in 1:1 without restrictions mode instructions can be sent by member either to KDD or T2S as there is no validation and no pre-settlement securities reservation in KDD necessary. o Accounts transposed in 1:1 with restrictions mode and N:1 accounts instructions should be sent to KDD only. For matched instructions debiting such account, KDD attempts to reserve exact volume of securities required, before T2S settlement. Figure 1: Securities accounts transposition rules between Central registry and T2S Transposition type 1:1 without restrictions 1:1 with restrictions encumbrance marks in CRVP CRVP instructing T2S instructing Securities reservation in CRVP NO YES YES NO YES YES NO YES N:1 YES YES NO YES Securities account structure changes in Central registry Due to integration and optimisation reasons of T2S project, the following changes in Central registry account structure are done: Simplified third party rights concept, Securities account blocking option (execution via KDD only), Introduction of fiduciary account type (as a substitute for regular accounts containing fiduacirni račun in account title) Simplified third party rights concept Simplifications are as follows: Abolition of Usus fructus, Preemptive and Redemption rights recording, Pledging securities in central bank credit operations and T2S auto-collateralisation is done using dedicated account for pledged securities, Pledging securities for other reasons remains unchanged, however, only one pledge note to single security is allowed (instead of unlimited number of pledge notes to single security). 5

8 Any third party rights recorded in Central registry at the time of migration remain in the system without any impact to their lifecycle. Dedicated pledge account can be managed (opened/closed) by pledger s member, however, account opening request is usually placed by pledgee (or securities holder). Instructions for crediting such account are placed by securities holder. If already pledged securities are transferred to new dedicated pledge account, KDD deletes any former pledge evidence. Securities pledging procedure: holder s (i.e. pledger s) member opens same holder s dedicated pledge account and records pledgee s information to such account. Such a member is entitled to issue receive instructions for securities to be transferred (i.e. pledged) to that account and delivery instructions for debiting such account (i.e. release of pledged securities). Hence, member that opens dedicated pledge account controls volume of pledged securities Central registry system itself does not prevent/control pledging or releasing pledged securities. Pledging instructions in auto-collateralisation process are automatically issued by T2S. Only securities without any third party rights or other legal facts marking can be transferred to dedicated pledge account Securities account blocking Account blocking aims to prohibit holder s member to instruct transfers related to blocked account due to orders issued by authorised institutions. This functionality is harmonised with T2S securities blocking functionality. Blocking is allowed for any account type, whereby, only KDD is entitled to enter blocking instructions into the system. Account blocking is executed in T2S system for 1:1 without restrictions accounts and in Central registry system for accounts within N:1 account and 1:1 with restrictions account. Blocked account does not allow settlement of instructions debiting/crediting such account, whereby, validation and instruction matching are processed normally Fiduciary accounts This is a new account type (Nominee account marked with N) that can be opened and managed by KDD member. Account holder is recognised as shareholder, which is recorded in share ledger. Fiduciary accounts allow recording of third party rights and other legal facts to securities booked on such account, whereby, such account should be of N:1 or 1:1 with restrictions type. If fiduciary account is used as a link to (I)CSD with automated settlement in T2S, such account should be of 1:1 without restrictions type (in order to allow automated settlement without validation and securities reservations in Central registry) Information on DCAs in Central registry Each KDD member should have access to at least one T2S dedicated cash account (DCA) either as a payment bank or as a customer of a payment bank. Each T2S securities account should be linked to at least one DCA in order to enable T2S cash settlement. Each KDD member should use at least one DCA. 6

9 Each securities account opened in Central registry is linked (in static data) to at least one DCA to enable T2S settlement (DVP default). Member can opt for additional DCAs for corporate actions and on-exchange settlement (see figure below). KDD and Bank of Slovenia should configure securities accounts and DCAs as requested by respective member. As KDD member instructs DVP settlement via KDD, KDD should forward instructions to T2S with DCA to be used for settlement. Instructing scenarios for DVP transactions are as follows: If member instructs DVP settlement via KDD GUI (Klient), input of DCA is mandatory, whereby system automatically fills-in DCA stored in KDD static data for respective securities account opened in Central registry (DCA can be edited by member). KDD forwards such instruction to T2S and does not verify if DCA is linked to respective T2S securities account. DCA validation is executed in T2S if DCA indicated in settlement instruction does not match T2S DCA static data, T2S rejects such instruction. If member instructs DVP settlement in KDD via SWIFT and does not indicate DCA to be used for settlement, KDD automatically fills in DCA, as recorded in KDD static data for respective securities account. KDD settlement member is required to define single DCA to be used for settlement of onexchange trades. This DCA should be linked to all securities accounts opened in Central registry (stored in KDD static data) and to all T2S securities accounts (stored in T2S static data) to be used for settlement of on-exchange trades. Member can opt for separate DCA to be used for settlement of on-exchange trades only. If member decides to use such separated DCA, this is indicated in KDD static data and KDD automatically fills in this DCA in all on-exchange settlement instructions. If KDD member does not open such separate DCA, KDD automatically fills in DCA to be used in for DVP settlement. Entitlement payments from corporate actions (including take-overs) are aggregated and transferred separately for each T2S securities account. Member can opt for separate DCA to be used for settlement of corporate actions only. If member decides to use such separated DCA, this is indicated in KDD static data and KDD automatically fills in this DCA in all corporate actions settlement instructions. If KDD member does not open such separate DCA, KDD automatically fills in DCA to be used in for DVP settlement. Figure 1: Links between member A securities accounts and DCAs in Central registry (CRVP) and T2S Deafult DCA C Default: S/Acc A Default S/Acc H3 (1:1) DCA H Default: S/Acc H2 & H3 Default S/Acc Agg DCA LJSE S/Acc H2 (1:1R) DCA CA T2S Agg DVP Default: DCA C LJSE Default: DCA LJSE CA Default: DCA CA S/Acc H3 (1:1) DVP Default: DCA H CA Default: DCA CA S/Acc C1 DVP Default: - S/Acc C2 DVP Default: - S/Acc H1 DVP Default: DCA H CRVP (Računi Člana A) S/Acc H2 (1:1R) DVP Default: DCA H LJSE Default: DCA LJSE CA Default:DCA CA 7

10 2. INSTRUCTION PROCESSING AND SETTLEMENT As KDD connects to T2S system, settlement of each separate transaction is processed on two levels T2S settlement level and KDD level controlling certain settlement activities. As a general rule (with exception of transactions with 1:1 without restrictions accounts), KDD reserves securities (to be settled) on seller s securities account and transfers them to buyer s account once transaction is settled on T2S level. KDD initially prepares settlement instruction (to be sent to T2S) identifying members T2S technical settlement accounts and DCAs (if needed) based on static data. Once KDD receives settlement confirmation from T2S, transfers in Central registry are done from seller s to buyer s account and simultaneously updates share ledger Settlement day timetable KDD operations timetable is defined as follows: Members access is enabled from 7am to 6pm for FOP settlement and from 7am to 4pm for DVP settlement. On-exchange settlement is processed intraday; After settlement window indicated above and in line with T2S timetable, KDD processes: o Reconciliation and EOD/SOD procedures; o Corporate actions calculations/instructing for the following day; o Processing of night time settlement related T2S messages. T2S enables real time settlement from 5am to 6pm (daytime settlement) and settlement in cycles/sequences from 8pm to 3am (night time settlement). New settlement day in T2S starts at 8pm T2S instruction types T2S instruction types are as follows: Settlement Instructions settlement of securities and cash leg of transactions; Settlement Restrictions blocking, reserving and earmarking of securities and cash positions on T2S accounts; Maintenance Instructions cancel, hold/release and amendment instructions; Liquidity Transfers liquidity transfers between DCAs and DCA-T2 transfers. Use of individual functionalities and instructions listed above depends on individual member s T2S connectivity type (directly/indirectly connected party). Dedicated instruction types are used for on-exchange and corporate actions settlement. Instruction types and functionalities available to certain connectivity/settlement types are as follows: Figure 3: Instruction types and functionalities available to certain members connectivity/settlement types Indirectly connected members (FOP and DVP) Directly connected members (FOP and DVP) Stock exchange and corporate actions settlement Settlement instructions Settlement restrictions Cancel Amendment Hold/ Release YES NO YES NO YES YES currently NO YES YES YES YES NO YES as necessary as necessary 8

11 2.3. FOP and DVP transaction processing Instruction matching Matching of DVP and FOP instructions takes place in KDD or T2S, depending on member s connection to T2S: Matching takes place in KDD in following cases: o Transactions between two indirectly connected members or indirectly connected member s internal transactions; o Transactions between indirectly and directly connected members, whereas directly connected member s instruction relate to N:1 or 1:1 with restrictions account; Matching takes place in T2S if at least one instruction party is: o directly connected member instructing 1:1 without restrictions account; o member of linked CSD. KDD instruction matching fields and matching rules are fully harmonised with T2S fields/rules. KDD prepares already matched on-exchange and corporate actions instructions to be sent to T2S Settlement optimisation T2S facilitates settlement optimisation in order to increase settlement volumes employing as little securities and cash resources as possible. Optimisation methods are as follows: Partial settlement; Prioritisation; Auto-collateralisation; Technical netting; Optimisation mechanisms/algorithms. Technical netting and optimisation algorithms are automatically applied by T2S. Rules on use of further optimisation methods (dependant on KDD operations) are as follows: Partial settlement enabled for directly connected parties or members of linked CSDs both instructing T2S directly for 1:1 without restrictions accounts. This functionality is currently not enabled for instructions sent via KDD. Prioritisation - enabled for directly connected parties or members of linked CSDs both instructing T2S directly for 1:1 without restrictions accounts, whereas only High or Normal priority can be assigned. This functionality is currently not enabled for instructions sent via KDD. Auto-collateralisation - Functionality is enabled for directly and indirectly connected members Instruction recycling KDD recycling rules are harmonised with T2S rules, namely: unmatched settlement instructions are recycled for a period of 20 working days starting from the Intended Settlement Date or the date of the last status change of the instruction depending on which date is the latest; matched settlement instructions have unlimited recycling period or until they are cancelled or settled. 9

12 Instruction linking Functionality enables actors to define which instructions would settle before others (according to assigned priority level) or to settle simultaneously. KDD uses this functionality for settlement of on-exchange trades, risk management instructions related to on-exchange settlement and corporate actions. This functionality can be used by KDD members if they are directly connected parties or members of linked CSDs both instructing T2S directly for 1:1 without restrictions accounts. This functionality is currently not enabled for instructions sent via KDD Settlement of DVP and FOP instructions Settlement methods for DVP and FOP transactions depend on securities accounts type and members connection to T2S (directly/indirectly via KDD). Accounts transposed in 1:1 without restrictions mode allow direct T2S instructing without validation in KDD and pre-settlement securities reservation on delivery side accounts in Central registry. Such instructions can be sent to T2S even with insufficient securities account balance and, hence, employing T2S optimisation mechanisms. Cash leg of transactions is settled on DCAs, which are opened in T2S via Bank of Slovenia by KDD members in capacity of payment bank. If certain member does not have its own DCA, he should use payment bank services to enable settlement of cash leg of transactions. Settlement of DVP transactions is based on matched DCP instructions, which are sent to T2S via KDD or directly to T2S. DVP and FOP instructions sent to KDD are transmitted to T2S on individual basis, as soon as they are processed in Central registry. More detailed settlement workflow is presented below for the following DVP and FOP settlement scenarios: Transaction settlement between indirectly connected members; Transaction settlement between indirectly and directly connected members; Transaction settlement between directly connected members Transaction settlement between indirectly connected members 1 Both members send delivery/receive instructions to Central registry. Instructions are validated, system determines that both parties are indirectly connected parties (as evident from counterparties indicated on each instruction) and proceeds with matching in Central registry. System determines whether matched transaction is: o Internal transaction: Such transaction is recycled till ISD, when settlement is attempted. If settlement is unsuccessful due to insufficient funds on delivery securities account, transaction is further recycled. o Matched transaction should be sent to T2S: 1 Applies also to settlement between accounts opened by single member. 10

13 If delivery securities account (opened in KDD) is of 1:1 without restrictions type, KDD identifies related T2S securities accounts and DCA (if DVP) and creates matched instruction to be sent to T2S on ISD. If delivery securities account (opened in KDD) is of N:1 or 1:1 with restrictions type, KDD reserves securities in Central registry on ISD, identifies related T2S securities accounts and DCA (if DVP) and creates matched instruction to be sent to T2S as soon as reservation is successful. If reservation on delivery securities account is not successful, KDD recycles instruction until successful reservation. T2S validates and settles already matched instruction if securities and cash funds are sufficient on T2S securities accounts/dca. If settlement is not successful due to insufficient securities/funds, T2S recycles instruction and proceeds with optimisation methods. As KDD receives settlement confirmation from T2S: o Debits delivery account and credits receive account in Central registry; o Updates instruction status; o Updates share ledger (evidence of securities holders) in Central registry; o Notifies members on successful settlement Transaction settlement between (A) indirectly and (B) directly connected members (instructing T2S directly for 1:1 without restriction accounts) Member A should send deliver or receive instruction to KDD. KDD validates instruction and: o If delivery securities account (opened in KDD) is of 1:1 without restrictions type or it is a receive instruction, KDD identifies related T2S securities account and DCA (if DVP) and creates matched instruction to be immediately sent to T2S for matching and settlement. o If delivery securities account (opened in KDD) is of N:1 or 1:1 with restrictions type, KDD identifies related T2S securities accounts and DCA (if DVP), creates matched instruction with CSD Hold to be immediately sent to T2S. Member B instructs T2S directly. T2S validates such instructions and (if validated successfully) immediately attempts matching. If delivery securities account (opened in KDD) is of N:1 or 1:1 with restrictions type, KDD reserves securities in Central registry on ISD. Upon successful reservation, KDD instructs T2S to release instruction with CSD Hold status. If reservation is not successful, KDD recycles and further attempts securities reservation (instruction in T2S remains in CSD Hold status). On ISD T2S attempts settlement of all transactions without CSD Hold status. If funds/securities balance are not sufficient, instruction is recycled and proceeds with optimisation methods. As KDD receives settlement confirmation from T2S: o Debits delivery account and credits receive account in Central registry; o Updates instruction status; o Updates share ledger (evidence of securities holders) in Central registry; o Notifies members on successful settlement Transaction settlement between (A) indirectly and (B) directly connected members (instructing via KDD for N:1 and 1:1 with restriction accounts) Member A (indirectly connected) and member B (directly connected) send deliver/receive instruction to KDD. KDD proceeds with validation and matching. As instructions are matched: 11

14 o If delivery securities account (opened in KDD) is of 1:1 without restrictions type, KDD identifies related T2S securities accounts and DCAs (if DVP) and creates matched settlement instruction to be sent to T2S on ISD. o If delivery securities account (opened in KDD) is of N:1 or 1:1 with restrictions type, KDD reserves securities in Central registry on ISD, identifies related T2S securities accounts and DCAs (if DVP) and creates matched settlement instruction to be sent to T2S. If reservation is not successful, KDD recycles and further attempts securities reservation. T2S validates and settles already matched instruction if securities and cash funds are sufficient on T2S securities account/dca. If settlement is not successful due to insufficient securities/funds, T2S recycles instruction and proceeds with optimisation methods. As KDD receives settlement confirmation from T2S: o Debits delivery account and credits receive account in Central registry; o Updates instruction status; o Updates share ledger (evidence of securities holders) in Central registry; o Notifies members on successful settlement Transaction settlement between directly connected members (instructing T2S directly for 1:1 without restriction accounts) Members instruct T2S directly. T2S validates such instructions and (if validated successfully) immediately attempts matching. If matched successfully, T2S attempts settlement on ISD as securities and cash funds are sufficient on T2S securities account/dca. If settlement is not successful due to insufficient securities/funds, T2S recycles instruction and proceeds with optimisation methods. As KDD receives settlement confirmation from T2S: o Debits delivery account and credits receive account in Central registry; o Updates share ledger (evidence of securities holders) in Central registry; o Notifies members on successful settlement Transaction settlement between (A) indirectly and (B) directly connected members (instructing via KDD for 1:1 without restriction accounts) As KDD receives instruction from directly connected member (for 1:1 without restrictions account), validates such instruction and sends it to T2S. Remaining workflow is identical as by Transaction settlement between (A) indirectly and (B) directly connected members (instructing T2S directly for 1:1 without restriction accounts) Transaction settlement between (A) directly connected member instructing T2S and (B) directly connected member instructing KDD If directly connected member instructs accounts N:1 or 1:1 with restrictions, instructing scenario Transaction settlement between (A) indirectly and (B) directly connected members (instructing T2S directly for 1:1 without restriction accounts) applies. If directly connected member instructs via KDD for accounts 1:1 without restrictions, KDD validates and immediately transmits them to T2S. Remaining workflow is identical as by Transaction settlement between directly connected members (instructing T2S directly for 1:1 without restriction accounts). 12

15 Settlement among KDD members and members of linked CSDs Settlement among KDD member and member of linked T2S CSD ( Cross-CSD ) does not differ to above scenarios, even if links between KDD and other CSDs are established/modified in order to use automated Cross-CSD settlement functionality. When KDD migrates to T2S, settlement scenarios employed by existing links to other CSDs will remain unchanged (i.e. transaction settlement between indirectly connected members). KDD will notify KDD members on any possible modifications of this scenario. KDD currently does not act as Investor CSD, hence, access to foreign securities via KDD is not enabled for KDD members Stock exchange trades settlement 2 Settlement of stock exchange trades is allowed only on accounts under control of KDD i.e. N:1 or 1:1 with restrictions accounts. Settlement of stock exchange trades is done in form of individual DVP transfers. Cash transfers is executed among members DCAs and not via KDD s settlement T2 account as in pre-t2s environment. If settlement of single transaction requires transfers from several delivery securities accounts (e.g. sale of pledged securities, registry codes settlement, application of risk management procedures), additional FOP transfers are instructed. KDD receives daily list of locked-in trades from stock exchange and creates already matched instructions to be sent to T2S for daytime settlement. Reservation of securities positions to be settled is executed on delivery accounts in Central registry only N:1 or 1:1 with restrictions accounts Sale of pledged securities (booked on securities accounts opened with several members) by authorised member and usage of Registry codes As KDD generates DVP instruction related to stock exchange trades, it should consider specificities related to: sell transactions of pledged securities or marked with court orders (i.e. authorised member is not the one that opened respective securities account), and use of Registry codes. As the member, who receives cash funds is not the member(s) who delivers securities, KDD should generate additional FOP instructions (see illustrations below). 2 Stock exchange settlement workflow is based on assumption that stock exchange delivers matched instructions to KDD. 13

16 Illustration 1: Sale of pledged securities/marked with court order, several members are involved on delivery side Member A seller: delivers 100 securities against 100 Member B buyer: delivers 100 and receives 100 securities Above securities originate from accounts opened with: Member D: 50 securities Member E: 50 securities KDD generates following T2S instructions: Two FOP instructions debiting delivery T2S accounts opened with member D and E (each is linked to KDD securities account of respective end seller) and crediting single T2S N:1 account of receiving member A (no specific KDD receive account is necessary to generate these T2S instructions). DVP instruction debiting T2S N:1 securities account of member A and crediting securities account of member B. These instructions are generated for T2S settlement only and have no directly corresponding instructions in Central registry. Corresponding Central registry instructions represent two direct transfers from accounts opened with members D and E to account opened with member B. Illustration 2: Use of Registry codes on sell side (e.g. RK2) Registry code type RK2 (transfer of cash and securities obligations), whereby member A assumes cash side and member B assumes securities side. Member C instructs sell side, whereby purchase price is transferred to member A and member s B account is debited for securities. Member D instructs buy side for his house account. KDD generates following T2S instructions: FOP instruction debiting delivery T2S account opened with member B (linked to end seller account opened in KDD with member B) and crediting N:1 T2S account of member A. DVP instruction debiting T2S N:1 securities account of member A and crediting receiving securities account (linked to house account of member D in Central registry), and debiting member D DCA and crediting member A DCA. These instructions are generated for T2S settlement only and have no directly corresponding instructions in Central registry. Corresponding Central registry instructions represent two direct transfers from accounts opened with member B to house account of member D Stock exchange trades settlement workflow Ljubljana stock exchange sends to KDD a trading report with all trades concluded on respective trading day. Trades information is entered into Central registry. If respective trade is concluded for joint account, member is required to allocate such trade to client account. Members are informed on claims and liabilities from trades to be settled. KDD attempts reservation of securities positions required for settlement from trading date till T+2 in several cycles. On T+2 KDD s finally checks if securities balances on delivery accounts are sufficient. Required quantity of securities (per ISIN) on single account in Central registry is calculated as net position of all buy and sell trades. 14

17 KDD will create already matched instructions be settled in Central registry once KDD receives settlement confirmation from T2S. KDD identifies related T2S securities accounts and DCAs and creates matched settlement instruction linked all or none for settlement to be sent to T2S. T2S validates and settles all instructions on all-or-none principle if cash funds on relevant DCAs are sufficient. As KDD receives settlement confirmation from T2S: o Debits delivery account and credits receive account in Central registry; o Updates share ledger (evidence of securities holders) in Central registry; o Notifies members on successful settlement Risk management on stock exchange settlement Guarantee fund and liquidity reserve KDD collects Guarantee fund cash funds on dedicated KDD account in T2, as defined in KDD Rules. Liquidity reserve funds are also deposited on dedicated KDD account in T2. KDD transfers funds on T+2 to KDD DCA and further to members DCAs, to be used for settlement. All liquidity reserve transfers on T+2 are instructed by KDD Reservation of securities positions for stock exchange settlement Reservation of securities positions to be settled is executed on delivery accounts in Central registry (only N:1 or 1:1 with restrictions accounts) as follows: KDD starts reserving securities positions (on net basis, all trades included) on trading day. Trades without sufficient securities coverage will be eliminated. Hence, new securities positions to be reserved are calculated. KDD instructs T2S for settlement of trades with successfully reserved net positions in Central registry Trades are not allocated or insufficient balance on seller s securities account If specific trade is not allocated or there is insufficient balance on seller s securities account, KDD intervenes as follows: Elimination of trades that do not fulfil requirements (insufficient balance, unallocated). New calculation of liabilities, further reservation of securities on impacted accounts (in case of chain-trades) and informing of members. Settlement of all trades (delivery accounts have sufficient balance of securities to be reserved) as defined in rules for stock exchange settlement. Eliminated trades are treated as defined in KDD Rules after completed stock exchange settlement cycle Trades are not allocated to end-buyer accounts If specific trade is not allocated to the account of end-buyer, KDD intervenes as follows: KDD instructs T2S transfers with KDD s fiduciary account for custody services on receive side, generating the following instructions: DVP instruction crediting account of buyer s member and debiting member s DCA and 15

18 FOP instruction transferring said securities from account of buyer s member to KDD s fiduciary account for custody services. T2S settles instructions on all-or-none basis, KDD performs booking on accounts in Central registry. KDD performs all further actions as defined in KDD Rules Settlement member does not fulfil cash obligations In case of insufficient cash funds on respective DCA, T2S attempts autocollateralisation. If autocollateralisation is not feasible, the following steps are foreseen: 1. T2S does not settle said instructions (due to all-or-nothing principle) and they are set to recycling mode. In this case a respective member failed to fulfil his obligations related to settlement of stock exchange trades, whereby all trades remain in settlement process. 2. KDD transfers entire amount of defaulting member s net payment obligation from Guarantee fund deposited with Bank of Slovenia to KDD s DCA and further to member s DCA. All trades (along with cash transfer to member s DCA) are settled on all-or-none basis. KDD performs related transfers in Central registry. 3. KDD performs all further actions as defined in KDD Rules Use of restrictions on T2S securities accounts T2S enables usage of settlement restrictions on T2S securities accounts position blocking, reservation and earmarking (to be used in auto-collateralisation). Usage of settlement restrictions and position blocking/reservation/earmarking on T2S securities accounts is not enabled for indirectly connected KDD members. Furthermore, usage of blocked/reserved positions on T2S DCAs in settlement instructions is not enabled for instructing via KDD. Abovementioned functionalities shall be (solely upon request of directly connected member and if proved feasible in Central registry) enabled for directly connected members in T2S and for 1:1 without restrictions accounts only. However, KDD shall not consider such restrictions in settlement operations. If a member intends to earmark certain securities position to be used in auto-collateralisation, such marking should be applied on securities account level in T2S static data, whereas all securities booked on such account are deemed as eligible for auto-collateralisation T2S instruction maintenance T2S enables the following instruction maintenance functionalities: Instruction Amendments - enabling instruction indicator modifications; Instruction Cancellation; Instruction Hold/Release Instruction amendments T2S enables amendments of certain indicators: partial settlement indicator, priority indicator and linking (with other instructions) indicator. As partial settlement, prioritisation setting and instruction linking is not enabled for indirectly connected KDD members, related instruction amendments are also not enabled. 16

19 Instruction amendments are enabled for directly connected members only Instruction cancelation Instructions can be cancelled by: Instructing member, KDD performing its operations, T2S performing instruction revalidations. Unilateral member s cancelation of settlement instructions is enabled till instructions are matched. As instructions are matched, bilateral cancelation is required (cancelation instructions should be matched). Cancelation instructions and their statuses are visible in KDD GUI (Klient) Instruction Hold/Release Usage of instruction Hold/Release is available for KDD members to manage timing of settlement. T2S does not attempt settlement of certain instruction in Hold status until Release is instructed. Hold status has no impact on instruction matching. Members can send settlement instruction with Hold status or instruct Hold status to existing instruction, both via KDD or directly to T2S (directly connected members) Liquidity transfers Liquidity transfers of payment banks are within Bank of Slovenia s competence (Auto)collateralisation Securities accounts to be used in (auto)collateralisation The following securities accounts are used (for receiving collateral) to facilitate autocollateralisation of Eurosystem s credit operations and auto-collateralisation in relation Eurosystem counterparty: Regular central-banking credit operations conducted by Bank of Slovenia (pledge): Dedicated pledge securities accounts of counterparties (i.e. KDD members) opened with Bank of Slovenia and pledged in favour of Bank of Slovenia. These are substitutes for subaccounts of KDD members accounts, where pledges in favour of Bank of Slovenia are/were booked. Regular central-banking credit operations conducted by foreign NCBs (pledge via CCBM): Dedicated pledge securities accounts of foreign counterparties opened with Bank of Slovenia (pledged in favour of foreign NCBs) or pledging on existing sub-accounts, where pledges in favour of foreign NCBs are booked. Regular central-banking credit operations conducted by foreign central banks (REPO via CCBM): Securities accounts opened by Bank of Slovenia in the name and for the account of foreign NCBs. These are substitutes for securities accounts of foreign NCBs opened with Bank of Slovenia for REPO for NCBs that use REPO. Autocollateralisation in relation Bank of Slovenia counterparty (PLEDGE): Dedicated pledge securities accounts of counterparties (i.e. KDD members) opened with Bank of Slovenia and pledged in favour of Bank of Slovenia to insure autocollateralisation. Debits 17

20 and credits of securities account of Bank of Slovenia for autocollateralisation in T2S are based on instructions automatically generated by T2S. All abovementioned dedicated pledge accounts are of 1:1 without restrictions type which are reflected in T2S as accounts of Bank of Slovenia (Bank of Slovenia is Party ). Members accounts 1:1 without restrictions should be used for collateral delivery (collateral delivery account), whereby respective securities should be earmarked for collateral usage on securities account level respective account should be marked in static data. 3. CORPORATE ACTIONS Corporate actions related to securities issued in KDD are conducted by KDD. Due to harmonisation of KDD s procedures with international/ecb standards for corporate actions execution, KDD has changed certain procedures or introduced new ones. The following corporate actions are conducted by KDD: Corporate actions on stocks participating securities holders are determined by initiator s instruction or by record date in central registry: o Concurrent securities issuance/deletion, o Securities issuance/deletion (via interim account), o Voluntary and mandatory reorganisations, o Distributions, Corporate actions on flows: o Transformations (based on reorganisations), o Market claims (based on distributions), Buyer protection procedures (based on elective corporate actions) are not conducted by KDD and can be executed bilaterally on members level. Major changes in KDD s procedures (due to harmonisation with standards) are: Cascade execution path (»Christmas-tree model - CTM«): Any procedure (e.g. information flow, entitlement transfers) is executed in a chain from Issuer via KDD, KDD members, any further intermediaries to final beneficiary; Enhanced issuer s reporting obligation on corporate actions; Unified key-dates definitions; Introduction of corporate actions on flows (buyer protection functionality can be handled bilaterally between KDD members and is not managed centrally by KDD); Changed role of members in tax proceedings in line with CTM cash flow. KDD is considered as primary source of information on corporate actions for all participants in chain from issuer to final investor. Information distribution responsibility is shared as follows: Information flow from issuer to KDD responsibility of issuer; Information flow from KDD to KDD members responsibility of KDD; Information flow from KDD member (or further intermediary) to clients responsibility of KDD member (or intermediary). Information flow between issuer and KDD includes exchange of information and documents required for execution corporate action. Dedicated secured web page is established to support 18

21 information/documents exchange. As issuer fulfils all requirements for execution of corporate action, KDD makes announcement thereof. Announcement should be published at least 4 days before record date. KDD informs issuer also on completion of corporate action. Information flow between KDD and members is supported with new module in Klient within Central registry and distribution of files using web-services. Announcements of corporate actions are visible to all members in Klient module. In addition to filed shared among members via web-services in pre-t2s environment, KDD will additionally distribute file on persons entitled to proceeds. Cash flow is routed via KDD s T2S DCA. Settlement of cash leg of transactions is conducted on KDD s and members DCAs. Initiator should deposit any proceeds from corporate action on KDD s TARGET2 cash account before event is initiated. Cascade (Christmas tree) cash distribution model applies. KDD members (and further intermediaries) are responsible for distribution of cash proceeds to their clients Corporate actions on stocks Concurrent securities issuance/deletion Concurrent issuance/deletion is initiated as the issuer intends to issue/delete entire issuance quantity at one time. Such issuance/deletion can be executed in following ways: Issuance/deletion of securities of certain holders, as listed in issuer s order, or Issuance/deletion of securities of holders at the end of record date. As agreed with issuer and based on event complexity, KDD can block settlement with respective ISIN in T2S and KDD until process is completed. KDD informs members on following: Event announcement, Event completion Issuance/deletion via interim account Issuance/deletion via interim account is initiated as the issuer intends to issue/delete entire issuance quantity in several steps. This can be a FOP or DVP event, later requiring cash leg settlement in T2S on members DCAs Issuance/deletion process via interim account Issuance requires two steps (deletion is processed in reverse order): Issuer presents issuance order to KDD. Agreed quantity of securities is booked on interim account 3 dedicated for this issuance/isin only securities are ready to be transferred to holders accounts. As issuer intends to delete whole issue/isin, all securities with this ISIN 3 At the same time balance (issuance) account is debited balance is negative. 19

22 should be transferred from holders accounts to interim account and further from interim account to balance (issuance) account 4. Instructions for transfer of securities to be issued to holder s account are generated by issuer s agent (i.e. KDD member) and holder s KDD member. Instructions should be matched. Issuer presents issuance order to KDD. Issuance order specifies quantity of securities to be booked on interim account. KDD informs its members on this event (announcement) and enters T2S/KDD static data for respective ISIN. Once securities are booked on interim account, members can instruct transfers with such ISIN. If issuer does not have a status of KDD member, he can appoint an agent (KDD member) to enter instructions for transfer of securities between interim and holders accounts. KDD informs members on following: Event announcement; Completed securities transfer to interim account; Time interval for removing securities from holders accounts deletion of securities; Deletion of entire quantity issued and ISIN deletion Reorganisations Reorganisations result in exchange of holder s total or partial quantity of underlying ISIN for specified quantity of outturn securities and/or cash compensation. This can be mandatory or voluntary event Mandatory reorganisation As this is a mandatory event, all holders are impacted. If reorganisation requires cash compensations, the procedure is as follows: Issuer transfers cash compensations to KDD s T2 account, On payment day KDD transfers cash funds to KDD s DCA, KDD transfers cash funds to entitled members DCAs. KDD performs transformation of pending transactions (i.e. matched unsettled instructions) with underlying ISIN (see Transformations chapter). Key dates and deadlines are as follows: Public announcement: at least 4 days before event s record date. Last trading day (LTD): 2 days before RD. On-exchange trading with underlying ISIN is suspended on LTD+1. Record date RD: agreed between issuer and KDD before public announcement. Maturity date/expiry date: relates to underlying securities to be deleted in reorganizational event. RD+1=Maturity/Expiry date (marked as Inactive date in Central registry). Payment date PD: The day when settlement with underlying security is suspended and outturn securities are issued or cash compensation is paid to entitled holders. Payment date 4 This brings balance of issuance acount to 0. 20