USER GUIDE FOR SWIFT MESSAGES IN THE CLEARING AND SETTLEMENT SYSTEM

Transcription

1 USER GUIDE FOR SWIFT MESSAGES IN THE CLEARING AND SETTLEMENT SYSTEM Zagreb, November 2017

2 Table of contents TABLE OF CONTENTS... 2 INTRODUCTION... 3 SERVICE ACTIVATION... 4 RECEIVING INSTRUCTIONS (MT540,541,542,543)... 4 CHECKING MESSAGE ELEMENTS... 5 INSTRUCTION ENTRY... 6 REJECTING AN INSTRUCTION ENTRY... 6 STANDARD SWIFT REJECTION CODES FOR MT PREDEFINED CDCC REJECTION CODES FOR MT INSTRUCTION CANCELLATION (MT540,541,542,543)... 9 TRANSACTION SETTLEMENT (MT544,545,546,547) EXAMPLES OF INSTRUCTIONS EXAMPLE OF INSTRUCTION ENTRY INSTRUCTION ENTRY SETTLEMENT EXAMPLE OF REPURCHASE INSTRUCTION ENTRY REPURCHASE INSTRUCTION ENTRY REPURCHASE INSTRUCTION SETTLEMENT EXAMPLE OF INSTRUCTION CANCELLATION EXAMPLE OF REPURCHASE INSTRUCTION CANCELLATION EXAMPLE OF CROSS-BORDER SETTLEMENT INSTRUCTION ENTRY EXAMPLE OF INSTRUCTION ENTRY TOWARDS MEMBER X

3 Introduction The system of Central Depository And Clearing Company Inc. (hereinafter: CDCC) enables the use of SWIFT infrastructure and the processing of SWIFT messages type 54x (for clearing and settlement) according to ISO standard. By this decision, members have been provided with another interface for conducting activities of entering instructions to deliver/receive. This service covers automatic processing of messages type MT54x enabling business processes of entering and cancelling instructions to deliver and receive, with and without payment, as well as reporting on instruction statuses (accepted, rejected, matched, expired) and transactions arising from these instructions (settled). Automatic processing of SWIFT messages by CDCC system has been enabled for that purpose, as follows: Receiving messages o MT540 Receipt without payment (FoP) o MT541 Receipt with payment (RvP) o MT542 Delivery without payment (FoP) o MT543 Delivery with payment (DvP) Sending messages o Message status report o MT578 Notification of counterparty s instruction o MT544 Confirmation of receipt without payment o MT545 Confirmation of receipt with payment o MT546 Confirmation of delivery without payment o MT547 Confirmation of delivery with payment The relevant manner of operating the sub-system of contracted transfers of entry does not change the existing manner of operation through application solution called Deprin. Both solutions are complementary in the way that members can use both solutions at the same time, depending on their needs. This means that a member who has an activated service of sending SWIFT instructions for contracted transfer of entry can still enter contracted transfers of entry through the form for their entry in application Deprin. It should be pointed out that in the case of entering an instruction through application solution Deprin, the member will not get SWIFT messages with the message status report () and messages about receipt/delivery confirmation upon transaction settlement (MT544-MT547) from CDCC but the existing internal messages through the application solution. The complete exchange of messages is conducted by using CDCC s SWIFT address SDAHHR22. 3

4 Service activation The service is activated by using the order for member data entry (SPN-CLN) on which the following data are filled out: Service activation (YES/NO) Automatic extension (YES/NO) the service is activated for a period of one year. Upon expiry, the service is extended for another year by selecting this service option. SWIFT BIC address BIC address from which a member sends messages and to which CDCC will send status messages to the member has to be stated When a message for instruction entry arrives, it is checked whether the service for that member is activated, whether the date of the message is within the member s service activation period and whether SWIFT address (BIC) of the message sender is the same as the one entered for that member. In case the data regarding the address do not correspond or the member cannot be identified or the service usage date is expired, the message is not processed further and the system discontinues any further processing for that message. Receiving instructions (MT540,541,542,543) The process of entering and subsequently the process of matching instructions begin by receiving the instruction to receive or deliver with or without payment. In addition to this functionality, the message can also contain an instruction to cancel the previously entered instruction. 4

5 Checking message elements In order for the message to be semantically correct it has to contain all necessary elements and their content has to be in accordance with the rules governing the entry of instruction for contracted transfer of entry as an addition to the rules of the standard itself. Mandatory and optional elements are described in the table below: Element name 1. Purpose of message 2. Reference to sender 3. Delivery/ Receipt 4. Payment/ without payment 5. Settlement date Mandatory Block Tag Qualifier Value GENL :23G: - NEWM entry of new instruction or CANC for the cancellation of previous instruction GENL :20C: SEME 16 characters. Defined by the sender. Has to be unique MT540 and MT541 receipt, MT542 and MT543 delivery MT540 and MT542 without payment, MT541 and MT543 with payment TRADDET :98A: SETT Date in format YYYYMMDD 6. Security TRADDET :35B: ---- Word ISIN, then one space and ISIN code of the security (12 characters). In total, 17 characters long. 7 Description field TRADDET :70C: PACO Additional description field (equivalent to Note in Deprin). 8 Quantity FIAC :36B: SETT Code word FAMT (for bonds) or UNIT (for shares), and then the amount of maximum 13 digits + decimal comma. Example: 100 shares 9. Code of the member and of the message sender s account 10. Type of transaction 11. Counterparty member 12. Counterparty investor s account 13. Buyer/Seller BIC 14. Buyer / Seller Account FIAC :97A: SAFE Code of the member sending the message in format CCCC-C, and then space and the investor s account number Example: :97A::SAFE//PBZ-S SETDET :22F: SETR TRAD SETDET/ SETPRTY SETDET/ SETPRTY SETDET/ SETPRTY SETDET/ SETPRTY :95Q: REAG or DEAG Code of the member counterparty CCCC-C e.g. ZABA-B :97A: SAFE Account number of maximum 13 digits, corresponds to the field for the ordering party s account on Deprin form for contracted transfers of entry. One of the conditions for instruction matching. :95P: BUYR or SELL Buyer/seller BIC. This field is mandatory in cross-border settlement instructions and in instructions towards central counterparty. Example: :95P::BUYR//CCPHHR20XXX :97A: SAFE Buyer/seller account in foreign depository or central counterpary. This field is mandatory in cross-border settlement instructions and in instructions towards central counterparty. Example: :97A::SAFE//

6 Element name 15. Place of settlement 16. Amount for settlement Mandatory Block Tag Qualifier Value SETDET/ SETPRTY SETDET/ AMT :95P: PSET SDAHHR22 or CDCC s BIC (i.e. SDAHHR20 if it is a test) is always entered :19A: SETT ISO currency code and the amount for settlement with mandatory decimal comma and maximum 13 digits and two decimal places. The field is not mandatory if the transactions are without payment. Otherwise, it is mandatory. Example: :19A::SETT//HRK1000, 17. Return date REPO :98A: TERM Return date in repurchase agreement. Format YYYYMMDD 18. Return amount Instruction entry REPO :19A: TRTA The amount for return transaction settlement. ISO currency code and the amount for settlement with mandatory decimal comma and maximum 13 digits and two decimal places. Example :19A::TRTE//HRK12345,12 Upon checking all message elements, provided all data are correct, the system automatically enters an instruction for contracted transfer of entry. Upon its entry, the instruction acquires status Approved and is matched as such, if possible. If the matching does not succeed, SWIFT message MT578 with all data on the entered instruction is sent to the counterparty. message with status IPRC/PACK is sent to the member who initiated the entry of the instruction. After the instruction is successfully matched with the counterparty s instruction, the system creates a transaction (or two transactions in the case of a repurchase agreement). In this case, message with status MTCH/MACH is sent to both parties. also contains all data on the entered instruction. Rejecting an instruction entry In the case of an error in one or more elements from the messages for instruction entry, the system does not enter the instruction but sends message with status IPRC/REJT (or CPRC/REJT in the case of cancellation) back to the sender, with explanation of the reason for the rejection by using standard SWIFT rejection codes or predefined CDCC codes as explained in tables in section below. 6

7 Standard SWIFT rejection codes for MT CASY Impossible Cash Settlement System Cash Settlement System is not CDCC. DDAT Settlement Date Rejection Invalid settlement date. DEPT Place of Settlement Rejection CDCC is not place of settlement DMON Settlement Amount Rejection Settlement amount must be greater than zero DQUA Quantity Rejection Invalid Quantity Type Code or Quantity Type Code and Financial Instrument's Attributes mismatch. Insufficient Quantity for Certified Sell. DSEC Security Rejection Security does not exist in CDCC, is inactive or is not accepted for settlement in CDCC. ICAG Agent Rejection Unrecognised or invalid receiving or delivering agent or safekeeping account. IEXE Buyer or Seller Rejection Unrecognised or invalid buyer or seller. MINO Minimum Settlement Quantity Settlement quantity must be greater than zero. NRGN Not Found Cancellation or Transaction Processing Command request has been rejected since the instruction could not be found. REPA Termination Transaction Amount Rejection Return settlement amount must be greater than zero. SAFE Safekeeping Account Rejection Unrecognised or invalid message sender's safekeeping account. Participant's Clearing Account is not allowed as safekeeping account. Invalid Account Type for given Participant Type. TERM Closing Date/Time Rejection Invalid or nonexistent return settlement date. VALR Rule Rejection Account servicer validation rule rejection. These codes are used in in following fashion: :25D::IPRC//REJT :16R:REAS :24B::REJT//VALR :16S:REAS 7

8 Predefined CDCC rejection codes for MT HR0001 Function Rejection Function of the message is not allowed HR0002 Sender BIC Rejection Sender BIC does not match CDCC participant HR0003 Safekeeping Account Rejection Trading not allowed for safekeeping account HR0004 Clearing Account Rejection Unknown or incorrect clearing account HR0005 Trade Cancellation Rejection Unknown or incorrect trade cancellation request HR0006 Trade Rejection Unknown trade HR0007 Cancellation/Amendment Request Error Error during trade cancellation/amendment request insert HR0008 Cancellation/Amendment Error Error during trade cancellation/amendment HR0009 Counterparty Instruction Not Found Unknown counterparty instruction HR0010 Too Many Counterparty Instructions Too many counterparty instructions HR0011 Create Instruction Error Error during creating delivery/receipt instruction HR0012 Cancellation Rejection Unknown instruction for cancellation/amendment HR0013 DVP Not Allowed DVP is not allowed HR0014 Sender BIC Rejection Sender BIC does not match place of settlement HR0015 Instruction Match Error Error during instruction matching HR0016 Trade Allocation Error Error during trade allocation These codes are used in in following fashion: :25D::IPRC//REJT :16R:REAS :24B::REJT//VALR :70D::REAS//HR0001 :16S:REAS 8

9 Instruction cancellation (MT540,541,542,543) By receiving an instruction to cancel a previously entered instruction to receive or deliver with or without payment, the system checks the availability of the service in accordance with the process of receiving instructions, and afterwards passes through the control of message elements. The system recognises the instruction to cancel according to the sent value regarding the purpose of the message (block GENL, element :23:) which has to be CANC. A new block (LINK) with a reference to the previous message is also sent with that value, as follows: Element name 1. Purpose of message 2. Reference to previous message Mandatory Block Tag Qualifier Value GENL :23G: - CANC for the cancellation of previous instruction LINK :20C: PREV SEME from previous message or instruction intended for cancellation All other message elements have to be identical to elements from the previous message intended for cancellation in order to be able to carry out the cancellation procedure. If the instruction intended for cancellation has not been matched (has status Entered or Approved ), that is, a transaction has not occurred yet, and if there is an instruction with the stated reference and all message elements are identical to the previous message, the system will change the instruction status to Cancelled without any necessary approval from the counterparty. Upon changing the status, message about the cancellation confirmation and message MT578 about the cancellation of the instruction entered for the counterparty are sent to that counterparty. If the cancellation has not been successful, the member who initiated the cancellation is notified through message of the reason for the cancellation rejection. If the instruction has already been matched and a transaction has occurred, cancellation is conducted on the level of transaction. In the process, if the aforementioned conditions for reference are met and the data are identical to the ones in the initial instruction, the transaction cancellation is conducted in accordance with official documents of CDCC. When SWIFT message for the cancellation of matched instruction arrives, after it has been checked and verified that all of the stated conditions are met, request for status Approved is entered next to the requests for transaction cancellation. Then CDCC sends message (status CPRC/PACK) to the member, and MT578 message to the counterparty. The transaction will be cancelled only when requests for cancellation from both parties are matched. In such case, the counterparty can send the request for cancellation through a SWIFT message or through the existing form in the system (as it has been done thus far). If it sends a SWIFT message, after the requests are matched both parties will receive message with status CPRC/CAND (transaction cancelled). If the counterparty sends the request for cancellation through the system, it will receive the message about request matching and thus about the successful transaction cancellation through the system, whereas the member who initiated the cancellation will receive message with status CPRC/CAND. 9

10 In this case, if the transaction for some reason is not cancelled, both parties will receive message with status CPRC/REJT and a description of the reason for the unsuccessful transaction cancellation. Transaction settlement (MT544,545,546,547) With the settlement of transactions which were a result of matching the instructions of contracted transfers of entry, for which members who are parties have the activated service of sending instructions of contracted transfers of entry through SWIFT, the system automatically sends SWIFT messages about settlement confirmation to members. Therefore, we distinguish the following messages: MT544 Settlement confirmation of receipt without payment MT545 Settlement confirmation of receipt with payment MT546 Settlement confirmation of delivery without payment MT547 Settlement confirmation of delivery with payment These messages contain certain elements from initial instructions to deliver or receive, with added link to the reference to the initial instruction and elements with information on settlement. The process of sending messages, which has been initiated with members instructions to receive or deliver securities, ends with the settlement of transactions and with the sending of SWIFT messages about the settlement confirmation. 10

11 Examples of instructions Example of instruction entry PBZ-S receives 100 shares of INA-R-A to investor s account ZABA-B delivers 100 shares of INA-R-A to investor s account Intended settlement date: 30 June 2007 Transaction without payment. PBZ-S is the initiator (the first to send the instruction to enter). MT540 receipt without payment Sent by PBZ-S :20C::SEME//MT540 PBZ-S :23G:NEWM :97A::SAFE//PBZ-S :97A::SAFE//67890 :95P::PSET//SDAHHR22 MT542 delivery without payment Sent by ZABA-B :20C::SEME//MT542 ZABA-B :23G:NEWM :97A::SAFE//ZABA-B :97A::SAFE//12345 :95P::PSET//SDAHHR22 MT541 message is identical to MT540 message, except that field :19A::SETT//, where the amount for settlement is entered (considering that it is a transaction with payment), is in SETDET block, AMT sub-block. The same is applicable to MT542 message and MT543 message. In the examples of MT540 message and MT542 message, except in the example of the entry of REPURCHASE instruction MT540, description field (optional) has been left out and it can be used, when required, as Note in application Deprin. It is within TRADDET block: :70C::PACO//Description note 11

12 Instruction entry After a message is processed in CDCC, depending on the accuracy of the filled out fields, CDCC sends the following messages: a) MT540 message is correct and instruction is entered in contracted transfers of entry with status Approved. There is still no instruction from the counterparty. message is sent to the initiator (PBZ-S) and MT578 to the counterparty (ZABA-B). MT578 :20C::SEME//R * :23G:INST :20C::RELA//MT540 PBZ-S Sent by CDCC to ZABA-B :20C::SEME//R :23G:NEWM :25D::IPRC//PACK - approved :22H::REDE//RECE 16S:GENL 16R:SETTRAN 35B:ISIN HRINA0RA0007 :97A::SAFE//67890 the ordering 36B::SETT//UNIT/100, party's account 97A::SAFE//PBZ-S F::SETR//TRAD :22H::REDE//RECE :97A::12345 :97A::67890 :16S:SETTRAN * SEME message sent by CDCC has the following form: addmmggxxx where is a=r or D (receive or deliver) ddmmgg = the transaction entry date xxx = the number of contracted transfer of entry in CDCC system 12

13 b) MT540 message (received from PBZ-S) is incorrect, is sent together with the reason for rejection and status Rejected. Depending on rejection reason, one of two mentioned below is sent to participant: :20C::SEME//internal_code_CDCC :23G:INST :20C::RELA//MT540 PBZ-S :20C::SEME//internal_code_CDCC :23G:INST :20C::RELA//MT540 PBZ-S :25D::IPRC//REJT - rejected :25D::IPRC//REJT - rejected :16R:REAS :16R:REAS :24B::REJT//NARR :24B::REJT//DDAT :70D::REAS//HR0001 :16S:REAS :16S:REAS 16S:GENL 16S:GENL instruction elements instruction elements 13

14 c) If there already is an entered message from the counterparty and instruction matching takes place and transaction is made, both parties receive messages with status Matched. The transaction number and trade date are forwarded in description field :70E: of the following form :SPRO//DDMMYYYY-xxxxx, where DDMMYYYY represents trade date and xxxxx represents the newly occurred transaction number. :20C::SEME//R :23G:INST :20C::RELA//MT540 PBZ-S Sent by CDCC to ZABA-B :20C::SEME//D :23G:INST :20C::RELA//MT542 ZABA-B :25D::MTCH//MACH - matched :25D::MTCH//MACH - matched :16R:SETTRAN :16R:SETTRAN :97A::SAFE//PBZ-S :97A::SAFE//ZABA-B :22H::REDE//RECE :22H::REDE//DELI :70E::SPRO// :70E::SPRO// :16S:SETTRAN :16S:SETTRAN 14

15 Settlement a) settlement successful MT544 is sent to PBZ-S, and MT546 to ZABA-B. The status of contracted transfer of entry becomes Settled. MT544 :20C::SEME//internal_code_CDCC :23G:NEWM :13A::LINK//540 :20C::RELA//MT540 PBZ-S :98A::TRAD// :98C::ESET// MT546 Sent by CDCC to ZABA-B :20C::SEME//internal_code_CDCC :23G:NEWM :13A::LINK//542 :20C::RELA//MT542 ZABA-B :98A::TRAD// :98C::ESET// :36B::ESTT//UNIT/100, :36B::ESTT//UNIT/100, :97A::SAFE/PBZ-S :97A::SAFE/ ZABA-B :22F::SETR// :97A::SAFE//67890 :95P::PSET//SDAHHR22 :22F::SETR// :97A::SAFE//12345 :95P::PSET//SDAHHR22 15

16 b) settlement failed, settlement date passed with status Expired is sent to the initiating member, and MT578 with REMO code to the counterparty MT578 Sent by CDCC to ZABA-B :20C::SEME//R :20C::SEME//R :23G:INST :23G:REMO :20C::RELA//MT540 PBZ-S :13A::LINK//578 :20C::RELA//R :25D::IPRC//PENF - expired 16S:GENL 16R:SETTRAN :22H::REDE//RECE 35B:ISIN HRINA0RA B::SETT//UNIT/100, 97A::SAFE//PBZ-S F::SETR//TRAD :22H::REDE//RECE :97A::SAFE/67890 :22F::SETR// :97A::SAFE//12345 :16S:SETTRAN :97A::SAFE//

17 Example of REPURCHASE instruction entry PBZ-S receives 100 shares of INA-R-A to the investor s account ZABA-B delivers 100 shares of INA-R-A to the investor s account Intended settlement date: 30 June 2007 Transaction without payment. Return date: 15 July 2007 PBZ-S is the initiator (the first to send the instruction to enter). MT540 receipt without payment Sent by PBZ-S :20C::SEME//MT540R PBZ-S :23G:NEWM MT542 delivery without payment Sent by ZABA-B :20C::SEME//MT542R ZABA-B :23G:NEWM :97A::SAFE//PBZ-S :97A::SAFE//ZABA-B :70C::PACO//xxxxxxxx :16R:REPO :16R:REPO :98A::TERM// :98A::TERM// :19A::TRTE//HRK110, :19A::TRTE//HRK110, :16S:REPO :16S:REPO :97A::SAFE//67890 :95P::PSET//SDAHHR22 :97A::SAFE//12345 :95P::PSET//SDAHHR22 MT541 message is identical to MT540 message, except that the amount for settlement (considering that it is a transaction with payment) is entered in fields :19A: (block SETDET, subblock AMT). The same is applicable to MT542 message and MT543 message. 17

18 REPURCHASE instruction entry After a message is processed in CDCC, depending on the accuracy of the filled out fields, CDCC sends the following messages: a) MT540 message is correct and instruction is entered in contracted transfers of entry with status Approved. There is still no instruction from the counterparty. message is sent to the initiator (PBZ-S), and MT578 to the counterparty (ZABA-B). MT578 :20C::SEME//R :23G:INST :20C::RELA//MT540R PBZ-S Sent by CDCC to ZABA-B :20C::SEME//R :23G:NEWM :25D::IPRC//PACK - approved :22H::REDE//RECE 16S:GENL 16R:SETTRAN 35B:ISIN HRINA0RA B::SETT//UNIT/100, 97A::SAFE//PBZ-S F::SETR//TRAD :22H::REDE//RECE :16S:SETTRAN :97A::SAFE//67890 :16R:REPO :98A::TERM// :19A::TRTE//HRK110, :16S:REPO :97A::SAFE//12345 :97A::SAFE//

19 b) MT540 message (received from PBZ-S) is incorrect and is not entered in contracted transfers of entry. with status Rejected and the reason for rejection is sent to the initiator. :20C::SEME//internal_code_CDCC :23G:INST :20C::RELA//MT540R PBZ-S :20C::SEME//internal_code_CDCC :23G:INST :20C::RELA//MT540R PBZ-S :25D::IPRC//REJT - rejected :25D::IPRC//REJT - rejected :16R:REAS :16R:REAS :24B::REJT//NARR :24B::REJT//VALR :70D::REAS// HR0002 :16S:REAS :16S:REAS 16S:GENL 16S:GENL instruction elements instruction elements 19

20 c) If there already is an entered message from the counterparty and instruction matching takes place, both parties receive messages with status Matched. The status of contracted transfer of entry is updated to Matched. Then two transactions occur (one is for return). The transaction number and trade date are forwarded in description field :70E: of the following form :SPRO//DDMMYYYY-xxxxx:DDMMYYYY-zzzzz, where DDMMYYYY represents trade date and xxxxx represents the newly occurred transaction number, and zzzzz the number of the recurring transaction that occurs in case of repurchase agreement. :20C::SEME//R :23G:INST :20C::RELA//MT540R PBZ-S Sent by CDCC to ZABA-B :20C::SEME//R :23G:NEWM :20C::RELA//MT542R ZABA-B :25D::MTCH//MACH - matched :25D::MTCH//MACH - matched 16S:GENL 16S:GENL 16R:SETTRAN 16R:SETTRAN 35B:ISIN HRINA0RA B:ISIN HRINA0RA B::SETT//UNIT/100, 36B::SETT//UNIT/100, 97A::SAFE//PBZ-S A::SAFE//ZABA-B F::SETR//TRAD 22F::SETR//TRAD :22H::REDE//RECE :22H::REDE//DELI :70E::SPRO// : :70E::SPRO// : :16S:SETTRAN :16S:SETTRAN 20

21 REPURCHASE instruction settlement a) settlement successful MT544 is sent to PBZ-S, and MT546 to ZABA-B. The status of contracted transfer of entry is updated to Settled. MT544 :20C::SEME//internal_code_CDCC :23G:NEWM :13A::LINK//540 :20C::RELA//MT540R PBZ-S :98A::TRAD// :98C::ESET// MT546 Sent by CDCC to ZABA-B :20C::SEME//internal_code_CDCC :23G:NEWM :13A::LINK//542 :20C::RELA//MT542R ZABA-B :98A::TRAD// :98C::ESET// :36B::ESTT//UNIT/100, :36B::ESTT//UNIT/100, :97A::SAFE/PBZ-S :97A::SAFE/ ZABA-B :22F::SETR// :97A::SAFE//67890 :95P::PSET//SDAHHR22 :22F::SETR// :97A::SAFE//12345 :95P::PSET//SDAHHR22 21

22 b) settlement failed, settlement date passed with status Expired is sent to the initiating member, and MT578 with REMO code to the counterparty. The status of contracted transfer of entry is updated to Expired. MT578 Sent by CDCC to ZABA-B :20C::SEME//R :20C::SEME//R :23G:INST :23G:REMO :20C::RELA//MT540R PBZ-S :13A::LINK//578 :20C::RELA//R :25D::IPRC//PENF - expired 16S:GENL 16R:SETTRAN :22H::REDE//RECE 35B:ISIN HRINA0RA B::SETT//UNIT/100, 97A::SAFE//PBZ-S F::SETR//TRAD :22H::REDE//RECE :97A::SAFE/67890 :22F::SETR// :97A::SAFE//12345 :16S:SETTRAN :97A::SAFE//67890 After the return transaction is settled, members will receive MT544 and MT546 messages confirming the return transaction settlement. 22

23 Example of instruction cancellation PBZ-S wants to cancel a previously sent instruction with reference MT540 PBZ-S. It sends MT540 message which is referenced to the previous message and has the same mandatory elements: MT540 cancellation of receipt without payment Sent by PBZ-S :20C::SEME// MT540C PBZ-S :23G:CANC :20C::PREV//MT540 PBZ-S :97A::SAFE//PBZ-S :97A::SAFE//67890 :95P::PSET//SDAHHR22 MT541 message is identical to MT540 message, except that field :19A::SETT//, in which the amount for settlement is entered (considering that it is a transaction with payment), is in block SETDET, sub-block AMT. The analogy for MT542 and MT543 messages is applicable in the same way, except that REAG identifier is entered in field 95Q. 23

24 After the accuracy of the entered message is verified in CDCC, it is checked whether there already is an entered instruction with the same data. Afterwards, the status of contracted transfer of entry based on which the cancellation will be made, either on the level of instruction or on the level of transaction, is checked. The following scenarios are possible: a) There is an instruction with the stated reference and identical data, and the status of contracted transfer of entry is Approved cancellation is made on the level of instruction. message is sent to the initiating member, and MT578 to the counterparty. The status is updated to Cancelled in contracted transfers of entry. :20C::SEME//R * :23G:CAST :20C::RELA//MT540C PBZ-S :25D::CPRC//CAND :16R:SETTRAN :97A::SAFE//PBZ-S :22H::REDE//RECE :16S:SETTRAN - cancelled MT578 Sent by CDCC to ZABA-B :20C::SEME//R :23G:REMO :20C::LINK//578 :20C:: PREV//R :22H::REDE//RECE :97A::SAFE//67890 :97A::SAFE//12345 :97A::SAFE//

25 b) Instruction cannot be cancelled because there is no initial instruction with the stated reference and identical data or the transaction arising from contracted transfer of entry which is distributed to individual settlement has already been settled or the intended settlement date is effective if the transaction is distributed to contracted settlement. message with the reason for rejection is sent to the initiating member, and no message is sent to the counterparty. :20C::SEME// internal_code_cdcc :23G:CAST :20C::RELA//MT540C PBZ-S :25D::CPRC//REJT - rejected :16R:REAS cancellation :24B::REJT//NARR :70D::REAS//HR0012 :16S:REAS :16R:SETTRAN :97A::SAFE//PBZ-S :22H::REDE//RECE :16S:SETTRAN 25

26 c) There is an initial instruction with the stated reference and identical data, but the contracted transfer of entry arising from the initial instruction was matched and thus a transaction occurred. The transaction was distributed to the individual settlement procedure and has not been settled yet or it was distributed to the contracted settlement procedure and the intended settlement date is still not effective cancellation is made on the level of transaction. message with status CPRC/PACK is sent to the initiating member, and the request is entered in requests for the cancellation of transaction with status Approved. MT578 message is sent to the counterparty. MT578 :20C::SEME//R :23G:CAST :20C::RELA//MT540C PBZ-S :25D::CPRC//PACK - request for cancellation entered Sent by CDCC to ZABA-B :20C::SEME//R :23G:CANC :20C::LINK//578 :20C:: PREV//R elementi instrukcije... :22H::REDE//RECE :97A::SAFE//67890 :97A::SAFE//12345 :97A::SAFE//

27 d) Counterparty should send an instruction for cancellation. After that, the counter-request for transaction cancellation will be entered. When those two requests are matched, the transaction will be cancelled and both parties will receive messages with status CPRC/CAND. :20C::SEME//R :23G:CAST :20C::RELA//MT540_OPOZ PBZ-S :25D::CPRC//CAND - cancelled Sent by CDCC to ZABA-B :20C::SEME//R :23G:CAST :20C::RELA//MT542_OPOZ ZABA-B :25D::CPRC//CAND - cancelled... instruction elements instruction elements... 27

28 Example of REPURCHASE instruction cancellation PBZ-S wants to cancel a previously sent instruction with reference MT540 PBZ-S. It sends MT540 message which is referenced to the previous message and has the same elements: MT540 cancellation of receipt without payment Sent by PBZ-S :20C::SEME//MT540_OPOZ PBZ-S :23G:CANC :20C::PREV//MT540 PBZ-S :97A::SAFE//PBZ-S :16R:REPO :98A::TERM// :19A::TRTE//HRK110, :16S:REPO :97A::SAFE//67890 :95P::PSET//SDAHHR22 MT541 message is identical to MT540 message, except that the amount for settlement (considering that it is a transaction with payment) is entered in field :19A: (block SETDET, subblock AMT). The analogy for MT542 and MT543 messages is applicable in the same way, except that REAG identifier is entered in field 95Q. In REPURCHASE instructions, cancellation can be made only on the level of instructions since cancellation on the level of transaction is not allowed. After the accuracy of the entered message is verified in CDCC, it is checked whether the instruction can be cancelled: 28

29 a) Instruction can be cancelled (which means that the status of contracted transfer of entry is Approved ) message is sent to the initiating member, and MT578 to the counterparty. The status is updated to Cancelled in contracted transfers of entry. :20C::SEME//R * :23G:CAST :20C::RELA//MT540C PBZ-S :25D::CPRC//CAND - cancelled :16R:SETTRAN :97A::SAFE//PBZ-S :22H::REDE//RECE :16S:SETTRAN MT578 Sent by CDCC to ZABA-B :20C::SEME//R :23G:REMO :20C::LINK//578 :20C:: PREV//R :22H::REDE//RECE :97A::SAFE//67890 :16R:REPO :98A::TERM// :19A::TRTE//HRK110, :16S:REPO :97A::SAFE//12345 :97A::SAFE//

30 b) Instruction cannot be cancelled (because it has already been matched or there is no initial instruction with that reference or because of some other reason). message with the reason for cancellation rejection is sent to the initiating member, and no message is sent to the counterparty. :20C::SEME//interna_oznaka_CDCC :23G:CAST :20C::RELA//MT540C PBZ-S :25D::CPRC//REJT -odbijen opoziv :16R:REAS :24B::REJT//NARR :70D::REAS//HR0012 :16S:REAS :16R:SETTRAN :97A::SAFE//PBZ-S :22H::REDE//RECE :16S:SETTRAN 30

31 Example of cross-border settlement instruction entry PBZ-S receives 1000 certificates with ISIN code ATEGB0SA0001 to the investor s account from a foreign depository counter-account (member OEKB-C, account ) BIC and account of final deliverer in the foreign depository: GIBAATWGXXX Intended settlement date: 17 February 2010 Transaction without payment. MT540 Sent by PBZ-S to CDCC :20C::SEME// MT540_cross_border :23G:NEWM :35B:ISIN ATEGB0SA0001 :36B::SETT//UNIT/1000, :97A::SAFE//PBZ-S :95P::PSET//SDAHHR22 :95Q::DEAG//OEKB-C :97A::SAFE// :95P::SELL//GIBAATWGXXX final deliverer of security :97A::SAFE//

32 Example of instruction entry towards member X ZABA-B delivers 100 shares of INA-R-A from investor s account for position account in CCP (usage of 00 or 01 in front of position account number is mandatory). CCP-X receives 100 shares of INA-R-A to the investor s account Intended settlement date: 30 June 2007 Transaction without payment. Return date: 15 July 2007 ZABA-B is the initiator (the first to send the instruction to enter). MT542 delivery without payment Sent by ZABA-B :20C::SEME// MT542 ZABA-B :23G:NEWM MT540 receipt without payment Sent by CCP-X :20C::SEME// MT540 CCP-X :23G:NEWM :97A::SAFE//ZABA-B :97A::SAFE//CCP-X :95P::PSET//SDAHHR22 :95Q::REAG//CCP-X :97A::SAFE//11111 :95P::SELL//CCPHHR22 :97A::SAFE// :22F::RTGS//YRTG :95P::PSET//SDAHHR22 :97A::SAFE//22222 :95Q::REAG//CCP-X :97A::SAFE//11111 :95P::BUYR//CCPHHR22 :97A::SAFE//

33 This version 1.4., which was adopted by the Management Board of CDCC on its th meeting held on 3 November 2017, supersedes version 1.3 from 17 September This version comes into effect on 3 November MANAGEMENT BOARD No: U-303/17-2/IB Zagreb, PRESIDENT OF THE MANAGEMENT BOARD Vesna Živković, B.Sc. (Econ.) 33