MONEY MARKET MODULE 3. Version 5

Transcription

1 MONEY MARKET MODULE 3 Version 5 Date June 2014

2 1 Document Information Copyright Notice Contents of this document are protected under South African copyright law. No part of this document may be copied, completely or partly, either electronically or manually, without the written consent of Strate Ltd. This document remains the sole property of Strate Ltd. Disclaimer Although this document is the result of extensive analysis and research, it is subject to changes which may emanate from the audience or any supporting or endorsing party. The revisions and editions will be recorded and indicated per the Version Numbers that are released. 1

3 Important Notice The Strate Rules and Directives which are relevant to Money Market Module III are free and must be downloaded from the Strate website at and form part of this module s learning material. Reports and Queries does not form part of the material which will be examined as part of the Strate examinations specifically Strate Money Market Module 3 examination. This information is not included in this material but is contained within Annexure A to the Strate MM Module III Learning Material and can be obtained, free-of charge, from the Strate website by following the link ww.strate.co.za and click on the Training link. 2

4 Table of Contents 1 Document Information 1 Table of Contents 3 1 MESSAGE FROM THE CEO 5 2 STRATE S VISION, PURPOSE AND OBJECTIVES Vision Error! Bookmark not defined. 2.2 Purpose Error! Bookmark not defined. 2.3 Objectives 8 3 ACKNOWLEDGEMENT 10 4 THE ELECTRONIC TRADE MATCHING ENGINE Trade Reporting and Electronic Trade Matching Engine (ETME) Background Trade Reporting of Dematerialised MM Securities Modification/Cancellation of Trades Reported to the ETME Trade Reporting Information for Matching Electronic Trade Matching Engine (ETME) 19 5 TRADE CLEARING AND SETTLEMENT The standard Settlement Concepts and Principles Trade and Settlement Scenarios Exception Handling Procedures Strate Rules and Directives 62 3

5 6 MONEY MARKET CAPITAL EVENTS Coupon Payments Maturity Payments Coupon and Maturity Payments on Public Holidays Settling Bank Confirmations for Coupon and Maturity Payments Capital Event Process Flows Strate Directives 94 7 PLEDGE AND RELEASE PLEDGE Background CSD Rules that relate to Pledge Pledging MM Securities Pledge Process Flows 98 8 SARB TRANSACTIONS Role of the South African Reserve Bank (SARB) SARB / National Treasury Tender and Auction Process Reports and Queries ERROR CODES GLOSSARY OF TERMS 124 4

6 1 MESSAGE FROM THE CEO The journey we have taken with the market in introducing an electronic Money Market has been a challenging one and most certainly, an exciting one. All the parties involved in the development of the electronic Money Market have together, in a collaborative manner, developed functionality, systems, policies and procedures which will result in a reduction in the risks and increase the efficiencies in this arena. This participative approach has ensured that the wide interests of the market have been taken into consideration. This Money Market Learning Material encapsulates the understanding of the electronic Money Market and introduces the reader and examination candidate to a wide variety of new concepts and functionality. The most exciting innovation is the introduction into the Central Securities Depository (CSD) of a Securities Ownership Register (SOR), where Money Market Securities are held in individual accounts at Beneficial Ownership and foreign Nominee level. We are also excited about the introduction of the Electronic Trade Matching Engine (ETME) and providing the market with a trade reporting and matching platform in place of a formal Exchange. We are grateful for everyone s time and effort in designing this solution and for the endless hours discussing bulks, allocations and Ban numbers. Strate realises that there is always a need for companies to improve the skills in their organisations. Strate has embarked upon a process to assist our stakeholders in achieving such an important and worthwhile initiative. This Learning Material and the associated Money Market workshops, seminars and examinations that we offer, will compliment and assist you to achieve your training objectives. Because our target audience requires different levels of training, Strate has adopted a modular approach and can tailor the content of the course material to the needs of the trainees. We are sure that you will enjoy reading this material as much as we have enjoyed creating it. We value your input and we are committed to meeting customers needs in an ongoing process of improvement. Please submit any training requirements or suggestions to improve what we do, to the Strate Training Division, via (strate-training@strate.co.za). 5

7 I leave you with some wise words of a poem I once read: Do not undermine your worth by Comparing yourself with others. It is because we are different That each of us is special. Do not set your goals by what Other people deem important. Only you know what is best for you. Do not take for granted the things Closest to your heart. Cling to them as you would your life, for without them, life is meaningless. Do not let your life slip through your fingers By living in the past nor for the future. By living your life one day at a time, You live all the days of your life. Do not give up when you Still have something to give. Nothing is really over until the Moment you stop trying. It is a fragile thread that Binds us to each other. Do not be afraid to encounter risks. It is by taking chances That we learn how to be brave. Do not shut love out of your life by Saying it is impossible to find. 6

8 The quickest way to receive Love is to give love; The fastest way to lose love Is to hold it too tightly; In addition, the best way to keep Love is to give it wings. Do not dismiss your dreams. To be without dreams Is to be without hope; To be without hope Is to be without purpose. Do not run through life So fast that you forget Not only where you have been, But also where you are going. Life is not a race, But a journey to be savoured Each step of the way. Monica Singer Strate, Chief Executive Officer 7

9 2 STRATE S VISION, PURPOSE AND OBJECTIVES Please note that this sub-section of this Learning Material is for information purposes only and will not be examined. 2.1 Vision We are the leading independent South African provider of innovative post-trade products and services. We facilitate risk management, enabling transparency and efficiencies for the financial markets. 2.2 Purpose Strate s purpose is to provide post-trade services for the securities market, enabling end-to-end pragmatic, reliable, innovative solutions that facilitate the management of risk and the realisation of value for all stakeholders. 2.3 Objectives Strategic objective # 1: To ensure operational excellence and the effective management of risk while driving innovation and market best practice. Strategic intent: Maintain and enhance internal systems, infrastructure and governance. Continuously enhance Strate s operational capabilities. Retain the CSD and Clearing House licenses. Meet Transformation targets. Drive market best practice. Strategic objective # 2: - To be Stakeholder Centric Strategic intent: To expand the Client base by introducing new Clients or new services to existing clients. To build the Strate brand globally. To manage stakeholder relationships with excellence. 8

10 Strategic objective # 3: To be profitable Strategic intent: Increase revenue from new income streams Provide superior products and services at a commensurate price. Ensure Strate s financial self sustainability. Meet shareholder s financial expectations on returns. Ensure operational costs are effectively contained. Strategic objective # 4: To be a learning organization, enabling Corporate and Personal growth. Strategic intent: To strive for personal growth and the development of skills amongst Strate staff. Maintain an appropriately skilled, competent employee base within Strate. Provide thought leadership. 9

11 3 ACKNOWLEDGEMENT Strate takes this opportunity to thank Anthony Van Eden and Beverley Furman for their valuable contribution, both in information and time, to the writing of this Money Market Learning Material. Without their involvement and willingness to assist, this Learning Material would not have been as comprehensive. 10

12 4 THE ELECTRONIC TRADE MATCHING ENGINE 4.1 Trade Reporting and Electronic Trade Matching Engine (ETME) Definitions Some specific definitions for this chapter of the Money Market Learning Material are listed below: BAN Bi-lateral Allocation Number is a unique reference assigned by the ETME to link both the delivery of Securities and settlement of cash legs of each underlying bi-lateral allocation to the bulk transaction and thereby assuring settlement on a principal-to-principal basis. ETME Electronic Trade Matching Engine matches executed trade information reported separately by both trade counterparties. ITR Internal Trade Reference, is a reference number generated by a Traders own back-office proprietary trading or accounting system or the MMFE if this interface is used to report trade information. MMFE Money Market Front End, is the Strate front end portal provided to Strate Business Partners and Participants to provide users direct user access to all functionality of the Strate Money Market Settlement System (MMSS). UTRN Unique Trade Reference Number is a unique reference number generated by the ETME linking the buy and sell leg of a trade. 4.2 Background The Money Market environment is an over-the-counter market with no Automatic Trading System (ATS). In the paper market and in the dematerialized environment, trades are executed telephonically between Issuers and investors which may be trading on a principal basis or on behalf of their Clients on an agency basis. Throughout this chapter the use of Trader is synonymous and interchangeable with each of these parties. In the paper environment Trading Parties may execute trades on a principal-to-principal basis, i.e. one-to-one. Often in the case of Investment Managers, orders on behalf of their Client portfolios may be aggregated ( bulked ) 11

13 and executed with a counterparty on a bulked basis. This is often the case where Investment Managers tender for SARB primary Security auctions or other primary Money Market issues on behalf of their Clients and/or for their own proprietary positions. In the paper environment executed trades are manually matched/confirmed and counterparty settlement details are exchanged between the middle or back offices of Traders and Issuers. Settlement instructions are mostly manually communicated to custodians/settlement agents to expedite the settlement process. Traders and Issuers required an ETME with the relevant efficient functionality to match executed trade information reported at a bulked level by counterparties which included functionality to bilaterally allocate underlying trades to the bulk amounts reported by counterparties and provide the platform for real-time settlement of trades on a gross principal-to-principal basis. The Money Market ETME is used as a bulk matching and trade allocation tool that sits between the Business Partners with a Trader role reporting trades for settlement by the electronic Money Market Settlement System (MMSS). The ETME is fully integrated into the MMSS. In addition, the broad objectives of the ETME are to: satisfy the broad Money Market principles detailed in Strate s MM Module One Learning Material; facilitate efficient settlement of MM Securities in a T+ 0 environment; reduce operational and settlement risk; and provide enhanced straight through processing opportunities. 4.3 Trade Reporting of Dematerialised MM Securities All transactions in dematerialised MM Securities which lead to a change in Beneficial Ownership, whether against payment or free of payment, must be reported to the ETME for bulk matching and bi-lateral allocation of trades underlying the bulk, to facilitate settlement or action in the MMSS. This is essential in order to maintain an Securities Ownership Register (SOR) in the CSD. 12

14 In the dematerialised environment: Dematerialised MM Securities cannot be traded on Maturity Date; Roll-overs must be handled as a maturity and a new issue/isin; and Book-overs must be reported to the ETME as trades in order to reflect the correct Beneficial Owner in the SOR. Traders must only submit their bulk trade details (elaborated on in sections which follow,) including any underlying allocations, and not any underlying allocations of its counterparty. Trades can only be reported by Business Partners with a Trader role, either through their integrated back office systems or through the Strate MMFE. There is no distinction between Primary Issues and secondary trades for matching and allocation purposes. That means that all Primary Issues are reported by the Issuer to the ETME as a sale. The Strate Trade Reporting Windows are set out in Strate Directive SE.3. NOTE: The reader of this material must refer to this Directive which is available from the Strate website on Candidates who have registered for the Strate exams, must be fully aware of the ambit and conditions contained in this Directive. Same day settlement i.e. T+0 trades, reported before the Trade Reporting Window is open, will pool in the system until the Trade Reporting Windows open. Same day settlement trades reported after the window has closed will be rejected. Trades can be reported for matching and allocation on a T+n basis. The trade reporting cut-off time will be checked only on the day of settlement. All trade legs which remain unmatched at the close of the Trade Reporting Window will timeout and be failed at the EOD batch run in the MMSS and a Status Intimation or reports detailing this, will be sent to the Trader or its Trade Reporting Party. The diagram below highlights the information flow between Trading Parties and the ETME. This example is used to highlight the functions of the ETME which follows in this chapter. 13

15 Electronic Trade Reporting and Matching Buy Leg ( RVP ) Trader 1 Trader bulks Trader bulks orders Trade Executed orders R30mil 1 at Bulk 1 R30mil Trader Sell Leg ( DVP ) Back Office Back Office Client A R10mil Client A Participant-ABSA R0mil (PARTIC- ABSA ) 2 5 Failed Timed Out 5 2 Client X R18mil Client X Participant-SBSA R18mil (PARTIC- SBSA) Client B R9mil R9il Participant-NED (PARTIC - NED) IPANT Client C R11mil Participant-FNB MMSS Bulk Trade Details Allocated 5 N 3 ETME Bulk Trade matching Bi - lateral Alloc Y 4 Bulk Trade Details Allocated Client Y lient Y R12mil R12mil Participant-COMPS (PARTIC - COMPS) IPANT Information flows Contractual relationship BAN notifications optional 4 Trade details, ITR & UTRN MATCHED 4 MMSS 63 4 Trade details, ITR & UTRN BAN notifications optional Notes (1) A trade is executed telephonically between counterparty Traders at a bulk (aggregate) level with underlying allocations. (This would not change for trades without any allocations underlying the trade.) (2) Each Trading Party reports only its executed bulk trade details and ALL relevant underlying allocations electronically to the ETME using Trade Reporting messages (from the Trader s own back-office systems), or captured into the Strate Money Market Front-End (MMFE). The Trade Reporting message could also be sent via another Business Partner. Corporate Participants, in their Trader role, can report sell transactions including a Pre-Commit indicator; similarly for Full Participants reporting trades on behalf of their Clients. The bulk trade must include at least one allocation BEFORE being reported to the ETME even if there is only a single allocation, i.e. a principal-to-principal trade. (3) The ETME performs validation checking of the static trade data reported against the MMSS Master File Administration (MFA), except for the Trader s Internal Trade Reference number (ITR). Matching is done on the bulk level (Nominal and Consideration/Settlement Amount) and not on underlying allocated amounts. Only once the trade legs are matched, the ETME assigns a Unique Trade Reference Number (UTRN) and the Bilateral Allocation process/clearing takes place. 14

16 (4) Once the trade is matched on a bulk level, the ETME will send a Matched Status Confirmation to the Traders, if they are Direct Business Partners or the Traders Trade Reporting Party, either directly to the MMFE, or through the Trader s back office system. The Status Confirmation will include all the trade details (the Trader s Internal Trade Reference number (ITR) if reported from the Trader s back-office systems, or if reported from the MMFE, an assigned reference number and the assigned UTRN number). The Bilateral Allocation Numbers (BAN) Notification may be requested, at the Trader s option, to be sent immediately thereafter. (5) Where a trade reported is not matched by the close of business, the trade is failed at the EOD batch run and reported to the Trader in a Status Intimation notification as Failed Unmatched. The ITR reported from the Traders back-office systems or captured in the MMFE, will be included in the Status Intimation notification. 4.4 Modification/Cancellation of Trades Reported to the ETME The ETME is able to receive trade modifications (sent as a Replacement message) and cancellation instructions from Trade Reporting Parties. Before trade matching: A Replacement message can be sent to the ETME to modify information in a trade which has already been reported. The Trader must include the ITR number used to report the original trade information, together with modified trade information. The ETME sends a confirmation of the modification to the party reporting the trade. A cancellation request, detailing the original ITR number, can be reported by the Trading Party to the ETME. A cancellation confirmation will be sent by the ETME to the reporting party. After trade matching: Once trades have been matched, they cannot be replaced or cancelled (except for the second leg of a Sell and Buy Back transaction). Note: Money Market Sell and Buy Back transactions are explained further on in this Learning Material. 15

17 4.5 Trade Reporting Information for Matching Trade Types The following Trade Types can be reported through the ETME: DVP/RVP: DFP/RFP: DPL/RPL: DRL/RRL: Deliver/Receive versus Payment (Primary and Secondary trades) Deliver/Receive Free of Payment Deliver/Receive Pledge Deliver/Receive Release Pledge Transaction Types The following Transaction Types, which are specific trade types, are catered for in the ETME: Sell and Buy Back (Type 60) (Trade Type - DVP/RVP) Sell and Buy Back - Second Leg Cancellation (Type 61) (Trade Type - DVP/RVP) Portfolio Movements (Type 31) (Trade Type - DFP/RFP) Account Transfers (Type 30) (Trade Type - DFP/RFP) Incorrectly formatted messages or invalid trade data reported will be rejected and reported to the Trade Reporting Party including the ITR number and error code for rectification and resubmission. Note: For information on error codes, please refer to Chapter 10. All trade information reported to the ETME for matching and settlement must include the bulk (aggregate) of the Nominal and Consideration (settlement) amount in South African Rands. It also must include at least one underlying allocation to the bulk trade (so for principal-to-principal trades there would only be one underlying allocation.) Pledges, Release Pledges, Portfolio Movements and Account Transfers must be reported with the relevant Transaction Type to the ETME by Participants in their role as Trader for matching and settlement. 16

18 4.5.3 Tap Top-up/Reduction Indicator Issuers who wish to increase the amount of an ISIN in issue and simultaneously trade the increased amount, can make use of the Tap Top-up function by reporting the Tap Top-up indicator as Y in the trade reporting message and including the Nominal Amount by which the ISIN it has issued should be increased by. If the Tap Top-up indicator is not marked in a trade, it is defaulted to N when the trade reporting message is received into the ETME. The effect of marking the indicator is that the ETME will instruct the MMSS to increase the amount of the ISIN in issue in the Securities Register and simultaneously move the increased amount into the Issuer s Free Balance in its SOR Securities Account before settlement. Similarly where an Issuer wishes to reduce the amount of an ISIN it has issued, it would mark the Tap Reduction as Y and include the Nominal Amount by which the Issued Amount in the Securities Register should be reduced. The MMSS would reduce the amount in the Issuer s Free Balance in its SOR Securities Account once the trade has settled. By implication, all Issuers would require the role of Trader. 17

19 4.5.4 Mandatory Trade Information The following mandatory trade information, which must be reported by both counterparties for matching and bi-lateral allocation, comprises: Trade Data Validated Example ISIN : ZAM Trade Type : DVP/RVP Transaction Type : 60 Trade Date : 14/12/2009 Settlement Date : 14/12/2009 Nominal Value (bulk) : R ,00 Consideration (bulk) : R ,00 Repurchase Date 14/06/2010 Repurchase Consideration/Amount ,00 Trading Party (Trader BPID no) : ZA Trading Counterparty (Trader BPID no) : ZA Internal Trade Reference(ITR) : ZA600234/ Original ITR : ITR Nominal Values (for each of Client A,B,C) : R10mil,R9mil, R11mil Consideration (for each of Clients A,B,C) : R11mil,R10mil,R12mil SOR account numbers (of Clients A,B,C ) : , , : Bulk trade details : Allocations underlying the Bulk trade information (Even if the bulk represents a One to One trade, one level of allocation must be reported.) :Only applicable for Sell and Buy Back transaction type. 18

20 The Trader s ITR must be reported with its trade details for bulk matching purposes but is not a matching criterion. It is also used by the Trader to cancel or modify a trade reported before matching in the ETME. The Status Intimation sent to the Trader can notify it of: invalid trade information rejected; trade Matched status; trades which have not matched and have Timed Out ; failed trades at the EOD procedures in the MMSS. The ITR may be used by the Trader s back-office to match to the original trade information reported by it to the ETME for its proprietary systems. 4.6 Electronic Trade Matching Engine (ETME) The ETME includes bulk matching and bi-lateral allocation functionality and is fully integrated into the MMSS. The ETME includes extensive validation to the Master File Administration (MFA) database in the MMSS of trade details reported to the ETME. The validation process ensures that allocated trades supporting bulk reported trades for settlement will, as far as possible, be free of static data errors, which will enhance straight through processing required in a generally T+ 0 trading environment. 19

21 4.6.1 ETME Validation of trade information submitted. The following trade information is validated:- TRADE DATA VALIDATED Example BULK INFORMATION ISIN Trade Type ZAM DVP Transaction Type 00 Trade Date 04/09/2008 Settlement Date 04/09/2008 Trader BPID Trader Counterparty BPID ZA ZA UNDERLYING TRADE ALLOCATION INFORMATION Nominal Value traded Consideration R10mil, R9mil, R11mil R11mil, R10mil,ZAR12mil SOR account numbers (for each allocation A,B,C) , , Valid ISIN, Trading Party and counterparty BP ID s, SOR accounts of the underlying allocations must be active (Not Frozen) and valid in the MFA. If any of these are inactive/ invalid, or the SOR accounts are frozen, the trade will be rejected by the ETME. Trade Date must be equal or less than Current Date. Trade Date must be less than Maturity Date. Trade Date must be a Business Date. The following rules apply for the Settlement Date with exception of the second leg of an open Sell and Buy Back type transaction:- - Settlement Date must be equal or greater than Current Date; - Settlement Date must be equal or greater than Trade Date; and - Settlement Date must not be equal to or greater than Maturity Date of the traded ISIN. The bulk Nominal and Consideration is in South African Rand. 20

22 The bulk Nominal and the Nominal of the allocations underlying the bulk, must be in the minimum tradable denominations of the ISIN traded. If not, the trade information will be rejected and a Status Intimation message will be sent back to the Trading Party. The ETME validates that there is at least one allocation underlying the bulk trade information. If there are no allocation(s) supporting the bulk, the trade reporting will be rejected and a Status Intimation message will be sent back to the Trading Party. The ETME will also aggregate the Nominal and Consideration amounts of the allocated trades reported for underlying Clients and compare the total to the bulk Nominal and Consideration amounts to ensure there is no over/under allocation. If trades are sent as pre-committed, the ETME further validates that the Trader in question also has a role of Participant, and that the SOR accounts listed in the underlying allocations belong to that Participant. If not, the ETME rejects the trade reported. A stand alone Trader cannot report a precommitted trade. If the Tap Top-up/Reduction indicator is set to Yes, the ETME checks that the Trader so utilizing this functionality is also the Issuer of the ISIN against which the trade is being booked. Pledges and Release Pledges, Account Transfers and Portfolio Movements booked by Traders must also have the role of Participant Bulk matching of key trade information reported Bulk matching is undertaken only on the common trade information to the trade and not the Traders ITR or any of the information of the allocations underlying the bulk. The executed bulk trade legs must contain the following mandatory information to allow the ETME to match the buyer and seller trade legs at a bulk level (the illustrative information used in is used below): 21

23 Electronic Trade Matching Buy Leg ( RVP ) UTRN: AAA123 Sell Leg ( DVP ) MATCHING ENGINE (4) Trader 1 Trader 2 ISIN : ZAM ISIN : ZAM Trade Date : 14/02/2010 Trade Date : 14/02/2010 Trade type : RVP Trade type : DVP Transaction Type : Transaction Type : Settlement date : 14/02/2010 Nominal Value (bulk) : ,00 Settlement date : 14/02/2010 Nominal Value (bulk) : ,00 Bulk Consideration (bulk) : ,00 Consideration (bulk) : ,00 Trader BPID : ZA Trader BPID : ZA Trader Counterparty BPID : ZA Trader Counterparty BPID : ZA Trader Internal reference no. : ITR Trader Internal reference no. : ITR Original Trader ITR (initial cancelled) : Original ITR (Initial cancelled) : Nominal Values (Client A,B,C)) : R10mil,R9mil, R11mil Nominal Values (Client X,Y)) : R18mil,R12mil Consideration (Client A,B,C) : R11mil,R10mil,R12mil SOR account numbers (Clients A,B,C ) : , , Consideration (Client X, Y) : R20mil, R13mil SOR account numbers (Clients X, Y) : ; Allocation s Send Matched Status Intimation Message to Traders 65 A Unique Trade Reference Number (UTRN) linking the relevant legs of the trade will be generated by the ETME post bulk trade matching. Once the trade information in both trade legs reported are matched, the ETME will assign a UTRN and then send a Matched Status Intimation message back to both Trade Reporting Parties detailing the ITR, UTRN and all the trade details reported. The Bi-lateral Allocation Numbers (BANs) will only be sent in a separate message if requested in the Trader s Standing Instructions per its Strate Business Partner BP application form. The ETME stores all UTRNs issued which links the buy and sell legs of the trade. The UTRN consists of 3 alpha characters followed by 3 digits (i.e. 6 characters in total). Once issued, a UTRN cannot be reissued. 22

24 All trade legs which remain unmatched at the close of the Trade Reporting Window (refer to Strate Directive SE.3) will time-out and be failed at the EOD batch run in MMSS and a Status Intimation / Reports detailing this will be sent to the Trader or its Trade Reporting Party. All four legs of the trade information of a Sell and Buy Back transaction must match or else the first and second leg of the Sell and Buy Back transaction reported are considered unmatched and will fail during the EOD process on Settlement Date Matching Tolerance Matching Tolerance There will be a ZERO tolerance on matching of the bulk Nominal Values. A tolerance for matching the Bulk Consideration amount of R50,00 has been agreed with the market and detailed in Strate Directive SE.4 covering Trade Reporting and Matching. Should there be a mismatch in the consideration which is within the tolerance level, then the Buying party s consideration will be amended by the ETME to equate to that of the Selling party s - the differential being pro-rated across the underlying allocations by the ETME prior to bi-lateral allocation. Should the consideration mismatch be outside the tolerance limit, the trade will not match Trade Leg Reporting From the time a transaction is reported to the ETME, the counterparty to the transaction has 120 (one hundred and twenty) minutes in which to report its leg of the transaction. This 120 (one hundred and twenty) minutes window is only applicable from 08h00. Any trade that has been reported but not yet matched within 120 minutes will lead to a Status Intimation message being sent by the ETME to the Trade Reporting Party to notify it that no match has been found. The Status Intimation message will include all the bulk trade information reported. It is then the responsibility of the Trade Reporting Party to check its trade details with its counterparty Trader and confirm that its counterparty Trader has reported its leg of the trade. 23

25 At this stage no fines will be levied for late reporting of trade legs but adherence to the operational windows (Strate Directive SE.3) is being closely monitored by STRATE Supervision. As mentioned, the trade leg reporting requirements will only commence from 08H00 on settlement day; i.e. T+n trades reported will only be subject to these rules on day n. Un-matched trades will roll over in the same status until the Settlement Date. If they are still un-matched at EOD of the Settlement Date, then they will be failed during EOD process of Settlement Date. For T+n trades, the trade reporting cut-off time will be checked only on the day of settlement. For T+0 trades, the cut-off time will be checked on the day the trade is received. Free of payment trades, Account Transfers, Portfolio Movements and Pledges/Pledge Release transactions will not be subject to the trade leg reporting timeframe of 120 (one hundred and twenty) minutes. 24

26 4.6.5 Trade Matching Exception Handling The diagram below explains exception handling. Trade Matching Exception Handling Check Trade Details and resubmit or contact counterparty 3 3 Trader 1 Reporting Party 7 Trader 2 Counterparty FAILED End of Day Agreed time Interval ETME 6 Match MMSS 64 Notes: 1. Trader 1 submits executed trade information to the ETME. 2. If after the prescribed 120 minutes the ETME is unable to find a matching trade leg, it will send a Status Intimation to the Trading Party to notify it that no match had been found. The Status Intimation message will include all the bulk trade information reported. 3. It is then the responsibility of the Trade Reporting Party to check its trade details with its Counterparty Trader. Should the Trading Party be satisfied with the accuracy of its trade details it should confirm with its counterparty Trader that the counter leg of the trade has been reported. 4. Should the Trading Party have made an error in the trade details originally reported, it should modify the trade details by sending a Replacement Message to the ETME. 5. Should the Counterparty Trader have made an error in the trade information it reported, it should modify the trade details by sending a Replacement Message to the ETME. 25

27 6. The normal matching process will be carried out. 7. Once a match has been made and a UTRN assigned, the ETME will send the matched allocated trades to the MMSS for settlement and a Status Intimation - Matched to the Trading Parties. (This message is optional in terms of each Traders Standing Instructions.) 8. Should the Reporting Party s trade not match by the end of the Business Day, the trade reported will be failed and a Status Intimation - Failed will be sent to the Trader Bi-lateral allocation of trades underlying the bulk Once the bulk trade information has been matched and the UTRN assigned by the ETME, the ETME will then proceed with the bilateral allocation of underlying trades. A suitable efficient algorithm is used in the ETME to facilitate bi-lateral allocation of trades underlying the reported bulk trade legs to ensure gross principal-to-principal settlement i.e. mini-trades. If the bulk level is on a one-to-one level, the ETME will still carry out the bilateral allocation and assign one BAN to the single underlying allocation. If there are no allocation(s) supporting the bulk, the trade reporting will be rejected and a Status Intimation message will be sent back to the Trading Party. Bi-lateral allocations to the bulk will be assigned a unique Bi-lateral Allocation Number (BAN) by the ETME which will link delivery of Securities against payment on a principal-toprincipal basis. The BAN together with the UTRN is fundamental to the settlement process as will be seen in Chapter 5, dealing with settlement. The Trader s ITR is included in the Settlement Confirmation messages from the MMSS to the Participants and provide enhanced STP opportunities. 26

28 The following diagram illustrates the philosophy of the bi-lateral allocation process: Bi-lateral Trade Allocation Buy Leg ( RVP ) ABSA (Client A) R11m Cash Payment Securitie s receipt NEDBANK (Client B)R10m Cash Payment Securitie s receipt FNB (Client C) R12m Cash Payment R 11 R11 mil mil (X) (X) R 10 R mil 10 (X) mil (X) R R 9 mil 9 mil (X) (X) R R 1 mil 1 MIL (Y) (Y) R R 8 mil 8 mil (X) (X) R 1 mil (X) R 12 mil (Y) UTRN: AAA123 ETME SBSA (Client X) R20m R11 R 11 mil mil (A) (A) R9 R MIL 9 mil (B) (B) R10 R mil (A) R R 8 mil 8 mil (B) (B) R12 MIL (C) R1 R 1 MIL mil (B) R 11 mil (C) Cash Receipt Securities delivery COMPS (Client Y) R13m R 1 1 MIL mil (B) Sell Leg ( DVP ) Cash Receipt Securities delivery Securitie s receipt R 11 mil (Y) 68 Cash movement Securities Movement Notes: 1. Each BAN together with the UTRN pertaining to the bulk, is included in the Matched Status Intimation messages as well as all messages related to the settlement process. 2. Reconciliation of the bi-lateral allocations of Securities and cash settlements (one-tomany and many-to-many) to the bulk traded will be handled outside of the MMSS by arrangement between the Traders and their appointed Participants Trade Settlement Strate Reference Number The UTRN and BAN is referred to as the Strate Reference or Trade Settlement Reference Number which is carried in every message throughout the settlement processing and outside the MMSS. (This is similar to the Capital Event Reference number used for settlement of Capital Events). The structure of the reference numbers has been selected to ensure uniqueness as well as a sufficient pool of numbers before having to start recycling the numbers. Furthermore, the M 27

29 between the UTRN and the BAN is utilised by the SAMOS system as a trigger to send a Confirmation Message to Strate once settlement inter-bank has been affected. Settlement Reference Numbers Strate Reference Number USED IN EACH MESSAGE THROUGHOUT THE SETTLEMENT CYCLE Character fields A A A N N N M A A A N N N N N N Unique Trade reference no. Bi-lateral unique Safires order number numbers numbers Security type Key A Alpha SAMOS Settlement REC CODE: MPDEM M MM security identifier N Numerical Trade Reporting Window and Business Calendar Trades must be reported within the timeframes detailed in the Strate Directive SE.3 -Operational Windows. The operational windows are parameter driven to allow the windows to be moved when so required by the market to support business practices. Trades reported outside the Trade Reporting Windows will queue until the windows open, whereupon they will be processed. The normal Business Calendar for trade reporting is Monday to Friday. Exceptions Any exceptions to the Trade Reporting Window and the Business Calendar will only be considered where the circumstances are considered exceptional. For trade reporting on Saturdays, the Trading Parties must provide Strate and the market at least one day s notice for exceptionally opening the Trade Reporting Windows. If prior notice has not been received by 28

30 Strate, any trade reported to the ETME will be rejected and a notification message sent to the related party Sell and Buy Back transactions Background A Buy Back is synonymous with a Repurchase Agreement (Repo), Reverse Repurchase Agreements (Resale agreements) and Carry trades. Buy Backs are often considered as a short-term collateralized loan or a deposit given to the seller for the market value of the Security sold, using the underlying Security as collateral, and the seller buys back the ISIN at the price which he sold it back with interest on the implicit loan. Fixed A Buy Back is the sale of an existing Security at an agreed price, coupled with an agreement by the seller to repurchase the same Security on a specified future date (the Settlement Date) at an agreed price. All Buy Backs are typically executed under an ISMA (International Securities Market Association) Global Master Repurchase Agreement. Open If there is no Settlement Date stipulated for the Second Leg, then the Buy Back is called an Open Buy Back and is treated like a call account in terms of interest (i.e. interest paid monthly, usually on the 1st of the month, if the period is longer than a month). The principal invested is an amount that is secured by the Securities delivered. The interest rate of the Open Buy Back is variable, agreed daily between the parties and can be changed daily. The interest rate (i.e. Buy Back Rate) is not related to the underlying value of the Security used as collateral. If the Buy Back is closed (i.e. the balance gets drawn to zero), then the interest that is accrued for the month is paid either at the time the Buy Back is closed or at the end of the month. Any interest which accrues from the date the Buy Back is closed to the end of the month is handled outside the MMSS. Reverse Repurchase Agreement. (The buyer) A reverse repurchase agreement is an agreement to buy an existing Security and sell it back again to the same counterparty for settlement on a later date at an agreed price. 29

31 Typically in the paper market the Securities used for Buy Backs are bearer instruments which the buyer keeps in safe custody. Delivery in the Second Leg requires the return of the Securities with the identical characteristics to those delivered in the First Leg. This is normally achieved by drawing the Securities delivered in the First Leg from safe custody. However, there is no requirement that the same certificate numbers of the instruments initially delivered in the First Leg be returned but Securities returned in the Second Leg must have exact characteristics as those which were delivered in the First Leg. Securities lending transactions have similar characteristics to a Buy Back with the main exception being that the Securities are lent and not sold to the counterparty. All lending transactions are typically executed under a Lending Agreement. Lending transactions are normally undertaken for the following two main reasons:- Collateralised loan (no change in Beneficial Owner); or Trading strategy (change in Beneficial Owner). If the intention in a Buy Back or a Security lending represents a change in Beneficial Ownership, then these transactions must be booked as Buy Backs. Should the intention not represent a change in Beneficial Ownership, it must be booked as a pledge using the Pledge processes Basic principles relating to Sell and Buy Back transactions The following assumptions were made when the market agreed to the core functionality of Buy Back transactions. These assumptions are the basic principles which underpin Buy Back transactions. Only generic Categories 1 and 2 MM Securities will be accommodated for Buy Back transactions during Phase 1 of the dematerialization of Money Market Securities project, i.e.:- o Generic Category 1: Discounted Securities with a fixed Maturity Date. o Generic Category 2: Fixed interest bearing Securities with a fixed Maturity Date. Beneficial Ownership changes with a Buy Back trade. Repos and Carries which have the same characteristics as Buy Backs will be reported and processed as Buy Back transactions. 30

32 Security lending and Repos and Carries which are transacted as collateralized loans, with the intention that the Security lent cannot be on-sold or lent will be reported and processed as Pledges. All Buy Back transactions MUST be reported by BOTH Business Partners with a Trader role to the ETME for bulk matching and bi-lateral allocation ( one to one) for settlement in the MMSS. All four legs (the two legs in the near trade and two legs in the far trade) of the trade information of a Sell and Buy Back must match or else the First and Second Leg of the Sell and Buy Back reported are considered unmatched will fail during the EOD process on Settlement Date. The ETME will validate that the Settlement Date of the Second Leg (where a Fixed Buy Back) is not after Reconciliation Date of the underlying ISIN. All Buy Back trade information will be reported with ONLY a single underlying allocation. Both legs of the Buy Backs, and all subsequent activity, will be uniquely linked by one UTRN. Buy Back transactions with an Open Settlement Date will be accepted and validated in the ETME. Any interest payments arising on the settlement terms of accrued interest subsequent to the settlement of an Open Buy Back will be handled outside the MMSS. Only single ISINs will be used for Buy Back transactions. Buy Backs requiring multiple ISINs underpinning the cash must be split and reported to the ETME as multiple separate Buy Backs per ISIN. Fixed Buy Back transactions will be transacted to mature on or before Reconciliation Date. (Closing position at the end of day before Payment Day). Open Buy Back transactions will automatically be failed by the system at end of day batch run on Reconciliation Date. The Second Leg of the Buy Back can be cancelled and replaced with a new Second Leg. The close out of an Open Buy Back will be affected by the cancellation of the original Second Leg reported and the reporting of a new Second Leg with the Repurchase Date. Coupon and maturity payments will be made to the Beneficial Owner as recorded on Reconciliation Date and payable on Payment Date. All required legal documentation, tax and accounting reporting will be handled by Business Partners outside the MMSS. 31

33 High Level Information Flows The following diagram depicts the flow of information and messages in a typical Buy Back transaction. Buy Backs - Trade Matching Trader 1 Trade Information Trade type DVP/RVP Client type 60 ITR S ETME Match 4 Trader 2 Trade Information Trade Type RVP/DVP Client type 60 ITR P Leg 1 60 DVP t+0 UTRN AAA123 Leg 1 60 RVP t+0 UTRN AAA123 UTRN BAN BBB BAN BBB AAA123 ITR S3456 ITR P UTRN generated Client Type 60 also used for Client Type 61 ITR S Leg 1 60 DVP/RVP t+0 UTRN AAA123 BAN BBB Leg 2 61 Leg 2 61 RVP t+n UTRN AAA123 BAN BBB ITR S3456 ITR P98750 DVP t+n UTRN AAA123 BAN BBB ITR P98750 ITR S Leg 2 61 RVP/DVP t+n UTRN AAA123 BAN BBB ITR P98750 UTRN AAA123 UTRN generated Client Type 60 also used for Client Type 61 Settlement Leg 1 t+0; DVP Trader1/ RVP Trader2 MMSS Settlement Leg 2 t+n RVP Trader1/ DVP Trader2 Notes 1. Traders report trade information for both legs of the Buy Back in a single Trade Reporting message to the ETME including an ITR and Transaction Type 60 and a single allocation underlying each leg. 2. The ETME will carry out normal validation on the trade information reported by both Trading Parties and commence the bulk matching process. 3. If the information in all four legs of the Buy Back matches in the ETME, it will then assign a UTRN to the DVP/RVP of the First Leg, recorded in ETME as Client Type 60. The same UTRN is also assigned to the Second Leg, recorded in the ETME as Client Type 61. Thus, all four legs, two settlements, carry the same unique UTRN which is 32

34 used to link all Buy Back legs and any future activity for this Buy Back. The bi-lateral allocation processes will follow. 4. A Matched Status Intimation will be sent by ETME to both Traders once all four legs of the bulk trade information has been matched, which will include the Trader s ITR and the UTRN assigned by the ETME to both settlement legs (DVP/RVP and RVP/DVP.) The communication of the BANs is optional. 5. The ETME sends the settlement information including the assigned UTRN and BANs for both settlement legs, (DVP/RVP First and Second Legs) to the MMSS for settlement on the relevant Settlement Dates. Allegement messages for the Second Leg are only sent to the Participants on the Settlement Date of the Second Leg, i.e. Repurchase Date Replacement / Cancellation of Buy Back Transactions Before matching: Buy Back trade details can be replaced/ cancelled in ETME before it is matched. Replacement / Cancellation of Buy Back transactions trades must be reported by the Trading Party to the ETME with the Original ITR number reported together with a New ITR number and the Buy Back trade details to be replaced /cancelled. After matching: The Second Leg of a Buy Back transaction trade can be modified ONLY by cancellation of the Second Leg in ETME before settlement using the original UTRN, reported with the initial Buy Back, providing both parties to the trade report the information which must match or else the cancellation will be failed and the counterparties sent Failed Status Intimation messages. The Second Leg of the Buy Back can be modified before settlement by both parties reporting Cancellation Requests with their original ITR reported in the initial Buy Back to the ETME which must match. The ETME will derive the UTRN common to the two parties ITR numbers reported and cancel the settlement of the Second Leg. Both Trading Parties will then report new Second Leg trade details to the ETME with the new ITR numbers and Client Type 61. After matching, the ETME will send 2 new trade legs to replace the Second Leg of the Buy Back in the MMSS. 33

35 The information flow and required functionality for the cancellation of the Second Leg of the Buy Back is detailed in the diagram and notes below: Buy Backs - Cancellation Second Leg Trader 1 Cancellation Information Trade type RVP Client Type - 61 Original ITR S ETME Match 4 Trader 2 Cancellation Information Trade Type DVP Transaction Type - 61 Original ITR P ETME FIND ORIGINAL UTRN common to ITR S3456 and ITR P98750 reported in INITIAL BB Assign UTRN to Cancellation instruction MMSS 6 t+n SOR Leg 2 61 RVP/DVP t+n ITR S3456 UTRN AAA123 ITR P98750 BAN BBB Notes 1. Traders report cancellation information for the Second Leg of the Buy Back, including the ITR reported for the original Buy Back transaction and the transaction type of the Second Leg (61) to be cancelled, to the ETME. 2. The ETME will carry out normal validation on the cancellation information reported by both Trading Parties and commence the matching process, which MUST match. 3. If the information in both Legs of the Cancellation Request matches in the ETME it will search the allocated UTRN database in the ETME to find the original UTRN allocated to the original Buy Back transaction. The original ITRs, which were included in the trade information of both 34

36 counterparties when the Buy Back was originally reported, are used for this purpose. If the UTRN linked to both Traders ITR matches, this UTRN will be assigned to the Cancellation Request. 4. A Cancelled Status Intimation will be sent by ETME to both Traders once steps 2 and 3 above have been successfully completed, which will include the Traders original Buy Back ITR and the UTRN assigned to the original Buy Back. 5. The ETME sends the cancellation information including the original UTRN to MMSS to cancel the Second Leg of the Buy Back (in MMSS in matched status.). 6. The Second Leg of the Buy Back transaction is cancelled. 35

37 The diagram and information flow, required functionality and notes for the booking of the new Second Leg of the Buy Back is as follows: Buy Backs New Second Leg TRADER CANNOT USE THE SAME ITR USED TO REPORT INITIAL BUY BACK Trader 1 Trade Information - NEW 2 nd Leg Trade type RVP Client type 61 New ITR -S4600 Original BB ITR S ETME 2 4 Match 4 1 Trader 2 Trade Information NEW 2 nd Leg Trade Type DVP Transaction type 61 New ITR P98900 Original BB ITR P UTRN RVP t+n 61 DVP t+n 61 UTRN AAA123 UTRN AAA123 3 AAA123 BAN BBB BAN BBB New ITR S4600 New ITR Original ITR S3456 Original ITR P UTRN AAA12 3 New ITR S4600 Original ITR S RVP/DVP t+n 61 UTRN AAA123 BAN BBB New ITR Original ITR P98750 ETME find ORIGINAL UTRN common to ITR S3456 and ITR P98750 reported in INITIAL BB. Assign UTRN to (new) matched trade type 61 MMSS Notes 1. Traders report trade information to the ETME for the new Second Leg of the Buy Back, including a new ITR for this new Second Leg trade; the same trade type applicable to the cancelled Second Leg; Transaction Type 61 the Original ITR reported in the original Buy Back trade information and a single allocation underlying the new Second Leg bulk. 2. The ETME will carry out normal validation on the trade information reported by both Trading Parties and commence the bulk matching process. 3. If the information in both legs of the new Second Leg trade matches in the ETME, it will search the allocated UTRN data base in the ETME to find the original UTRN allocated to the original Buy Back transaction. The 36

38 original ITR, which was included in both the counterparty s trade information when the Buy Back was originally reported, is used for this purpose. If the UTRN linked to both Traders ITR matches, this UTRN will be assigned as the Second Leg UTRN. This methodology will keep all transactions to the Buy Back linked. The bi-lateral allocation processes will follow. 4. A Matched Status Intimation will be sent by ETME to both Traders once steps 2 and 3 above have been successfully completed, which will include the Trader s ITR for the new Second Leg and the UTRN, which was assigned to the original Buy Back. 5. The ETME will forward the matched trade information details and the assigned UTRN (initially assigned to the Buy Back) and BAN to the MMSS for settlement on the Settlement Date. Allegement messages for the Second Leg are only sent to the Participants on the Repurchase Date. 37

39 5 TRADE CLEARING AND SETTLEMENT This chapter of the Learning Material will give a detailed explanation of the settlement process flows for various trade types and Capital Events (i.e. coupons and maturity) in the electronic Money Market. Diagrams are used to explain the different settlement scenarios for trade types and Capital Events. In the second part of this chapter a list is given of the specific Strate Rules and Directives pertaining to the Money Market Trade, Clearing and Settlement and Capital Events. 5.1 The standard Settlement Concepts and Principles There will be no partial settlements or settlements carried over to the next Business Day in the dematerialised Money Market environment. The MMSS will not automatically settle matched trades. The settlement process includes a number of messages facilitated by the MMSS. As mentioned in the section on Trade Matching, each and every BAN is settled separately as a mini principal-to-principal trade under the bulk trade according to one of the settlement models mentioned below. All settlement messages in the settlement models carry all the trade detail, and must include the Strate Reference (UTRN, M and BAN) and the Trader s ITR. Settlement Allegements A Settlement Allegement is a notification sent by the MMSS, once the trade has matched, to the trading parties Participants to advise them of their Client s trade which must be settled. Confirmation Notifications (Commits) The Full Participant for both the Buyer and Seller must send Confirmation Notifications (i.e. Commits) to the CSD to initiate settlement. Commits must be received by the MMSS from Full Participants within the operational windows stipulated in Strate Directive SE.3. Full Participants that report their own institutions trades or trades booked on behalf of their Clients, can Pre-Commit to the delivery of Securities or settlement by setting the Pre-Commit indicator to Y (i.e. known as AFFI in the settlement messages). The effect of this is that the Participant will not have to send a separate Commit message. 38

40 Corporate Participants will always report their Sell trades Pre-Committed but can never report Purchase trades Pre-Committed. Where the trading parties both use Full Participants, when the Commits have been received by the MMSS from both the Full Participants, the requisite Securities are moved from the Seller s Free Balance to its Trading Reserve Balance in the SOR Securities Account and a Request for Payment message is sent by the MMSS to the Buyer s Participant to facilitate cash settlement. For Traders which are also Corporate Participants, when it reports a sell trade it will be Pre- Committed, so its Securities are reserved/locked in its SOR Securities Account immediately upon the trade being matched in the ETME without any Commit required from them. When the Corporate Participant reports a buy trade, it CANNOT Commit to the settlement of funds because it is not a Settling Bank. Status Intimations These are messages sent by the MMSS to notify Participants of the status of the settlement process. The type of status messages are elective and are set in the standing settlement instructions at the discretion of the Participant. Final and Irrevocable For trades where funding is required (i.e. a RVP trade) the Full Participant must notify their Settling Bank, which must fund the SAMOS RTL to facilitate the settlement. Similarly the Corporate Participant must notify its Settling Bank to do the same. When Settling Banks fund the SAMOS RTL they will also send a Payment Advice to the Settling Bank of the Seller notifying it of the settlement. Where the trading parties use the same Settling Bank, the Settling Bank will not fund the SAMOS RTL but will move the funds between the Buyer and Sellers account within the Settling Bank by journal entry. This is termed an On-us settlement. Once funds have cleared in SAMOS or settled On-us, settlement is considered final and irrevocable. 39

41 Simultaneous Delivery Versus Payment (DvP) SAMOS RTL, or a Settling Bank in the case of an On-us settlement, will send a confirmation message to the MMSS when the funds have been settled. The MMSS will immediately transfer the requisite Securities sold from the Seller s SOR Securities Account Trading Reserve Balance to the Buyer s SOR Securities Account Free Balance. The trading parties Participants will be informed of the completed settlement by the MMSS. Operating Windows Any deviation from the operational windows set out in Strate Directive SE.3 may result in the trade being failed or a monetary fine being imposed. 40

42 5.2 Trade and Settlement Scenarios The following diagrams provide an explanation of the different trade clearing and settlement scenarios Free of Payment Trades Buyer and Seller have different Participants. Buyer and Seller have different Participants Trader1 DFP (Sell) 2 1 Trader2 RFP (Buy) 2 3 Strate ETME Seller s Participant Strate MMSS 5 3 Buyer s Participant Notes 1. Traders strike a deal. 2. The trade is recorded in the Back-Office systems of the Traders. 3. The recorded trade legs are reported to the ETME where Trade Matching takes place. 4. The ETME sends Trade Confirmation messages to the Back-Office systems of the Traders including the UTRN, ITR and BAN if requested. 5. The ETME sends each allocated trade legs to the MMSS for clearing and settlement. 41

43 6. The MMSS sends Settlement Allegements to the Participants. 7. The Back-Office systems of the Traders send Settlement Instructions to their Participants (optional). 8. The Settlement Instructions from the Traders systems are matched with the Settlement Allegements from the MMSS by the Participant Back-Office system, where this is required by the Client concerned (optional). Buyer and Seller have different Participants Trader DFP Trader RFP 6 6 Selle s Participant Strat 4 Buyer s 3 SOR Participant 5 5 Notes 1. The clearing process (ensuring that the relevant party in the trade has the necessary Securities available for settlement) is completed by the Participant. 2. Participants send Commits to the MMSS, to initiate the Trade Settlement process. 3. Once both the Commit instructions are received, the MMSS checks in the Sellers SOR Securities Account to ensure that there are sufficient Money Market Securities to 42

44 be delivered. If requisite Money Market Securities are available then the MMSS settles the Money Market Securities; i.e. the Buyer s SOR Securities Account is credited and the Seller s SOR Securities Account is debited. 4. The MMSS sends the Participants a Status Intimation to confirm settlement. 5. The Participants settle in their Back-Office systems. 6. The Participants send Settlement Confirmations to the Traders/Clients (optional) Buyer and Seller have Same Participant Buyer and Seller have same Participants Trader1 DFP (Sell) 2 1 Trader2 RFP (Buy) 2 3 Strate ETME Strate 6 Seller s Participant Buyer s MMSS Participant 5 3 Notes 1. Traders strike a deal. 2. The trade is recorded in the Back-Office systems of the Traders. 3. The recorded trade legs are reported to the ETME where Trade Matching takes place. 4. The ETME sends Trade Confirmation messages to the Back-Office systems of the Traders including the UTRN, ITR and the BAN if requested. 5. The ETME send the allocated trade legs to the MMSS for clearing and settlement. 6. The MMSS sends Settlement Allegements to the Participant. 43

45 7. The Back-Office systems of the Traders send Settlement Instructions to their Participant (optional). 8. The Settlement Instructions from the Traders Back-Office systems are matched with the Settlement Allegements from the MMSS by the Participant Back-Office system (optional). Buyer and Seller have same Participants Trader1 DFP (Sell) Trader2 RFP (Buy) Seller s 4 Strate 4 Buyer s Participant 3 Participant 5 SOR 5 Notes 1. The clearing process (ensuring that the relevant party in the trade has the necessary Securities available for settlement) is completed by the Participant. 2. The Participant sends Commits to the MMSS to initiate the Trade Settlement process. 3. Once both Commit instructions are received, the MMSS checks in the Sellers SOR Securities Account, the Money Market Securities to be delivered. If requisite Money Market Securities are available then the MMSS settles the Money Market Securities; i.e. the Buyer s SOR Securities Account is credited and the Seller s SOR Securities Account is debited. 4. The MMSS sends the Participant settled Status Intimations. 5. The Participant settles in their Back-Office system. 6. The Participant sends settlement confirmations to the Traders/Clients (optioanal). 44

46 5.2.2 Versus Payment Trades (DVP and RVP) Trade Settlement Information Flows Full Participant TRADE Settlement information flows FULL PARTICIPANT (Excluding any effect On- us ) DVP(SELL) 7 SAMOS RTL 7 6 RVP(BUY) Treasury Settling Bank Participant Treasury Settling Bank 5 Participant SOR Strate Notes 1. Settlement Allegement messages sent from MMSS to Participants. 2. Participants send Commit messages to the MMSS committing to deliver Securities/settle the cash leg of a trade for their Client. 3. On receipt of both Commits from the Participants for both Securities and cash, the MMSS checks availability of Securities and then locks/reserves the Securities. 4. Once the Securities have been locked, the MMSS sends a Request for Payment message to the paying Participant. 5. The Participant will send a payment message to the Settling Bank instructing payment. 6. The Paying Settling Bank sends a Settlement Instruction to SAMOS RTL to credit the beneficiary Participant s Settling Bank and simultaneously a Payment Advice to the Receiving Settling Bank. 7. SAMOS notifies the MMSS of the settlement and simultaneously notifies both the Settling Bank paying and Settling Bank receiving of the settlement. 45

47 8. On receipt of the settlement confirmation from SAMOS, instantaneously the MMSS moves the Securities locked in the SOR Securities Account of the Seller to the new Beneficial Owner s Free Balance in its SOR Securities Account and sends Status Intimation messages to the trading parties Participants to advise them of the Securities movement Trade Settlement Information Flows where the Trade was Pre-Committed - Full Participants. Full Participant Pre- Commits Trades Reported in their Trader Role on behalf of their Clients - (Excluding any effect of On-us ) DVP(SELL) 6 SAMOS RTL 6 5 RVP(BUY) Treasury 5 Treasury 6 Settling Bank Settling Bank 4 Participant 7 7 Participant SOR Strate 3 2 Notes 1. Full Participants, in their role as Trader, report the trade legs for their Clients Pre- Committed. Once the trade details have been matched and allocated in the ETME, the Securities are immediately locked/ reserved in the Seller s SOR Securities Account. 2. Settlement Allegement messages sent from the MMSS to Participants. No Commit messages are necessary from the Participants because they booked the trade with a Pre- Commit. 3. MMSS sends a Request for Payment message to the paying Participant. 4. The Participant will send a payment message to their Settling Bank instructing payment. 46

48 5. The Paying Settling Bank sends a Settlement Instruction to SAMOS RTL to credit the beneficiary Participant s Settling Bank and simultaneously a Payment Advice to the Receiving Settling Bank. 6. SAMOS notifies the MMSS of the settlement and simultaneously notifies both the Settling Bank paying and Settling Bank receiving, of the settlement. 7. On receipt of the settlement confirmation from SAMOS, instantaneously the MMSS moves the Securities locked in the SOR Securities Account of the Seller to the new Beneficial Owner s Free Balance in its SOR Securities Account and sends Status Intimation messages to the trading parties Participants to advise them of the Securities movement Trade Settlement Information Flows Common Full Participant On-us Settlements of Trades Common Full Participant On-us DVP(SELL) RVP(BUY) Treasury Treasury Settling Bank A Settling Bank A 4 4 Full Participant 3 3 Full Participant 2 1 SOR Strate 2 1 Notes 1. Settlement Allegement messages sent from the MMSS to the same Full Participant. 2. Full Participant sends Commit messages to the MMSS committing to deliver Securities/settle the cash leg of a trade for both of their Clients. 47

49 3. Once both Commit messages for the delivery of Securities and the settlement of cash are received from the Participant, the MMSS will check the availability of Securities in the Sellers SOR Securities Account and moves the Securities from the Sellers SOR Securities Account to the new Beneficial Owner s Free Balance. The MMSS sends Status Intimation messages to the Full Participant to advise it of the Securities movement. 4. The Full Participant moves cash between the accounts intra-bank (journal entry) on receipt of the Status Intimation Trade Settlement Information flows Trades Pre-Committed by Common Full Participant reporting on behalf of Trading Parties - On-us Settlements of Trades Pre-Committed Trades - Common Full Participant - On-us DVP(SELL) RVP(BUY) Treasury Treasury Settling Bank A Settling Bank A 4 4 Full Participant 3 3 Full Participant 2 1 SOR Strate 1 Notes 1. Settlement Allegement messages sent from the MMSS to the same Full Participant. 2. The MMSS will check the availability of Securities in the Sellers SOR Securities Account and moves the Securities from the Sellers SOR Securities Account to the new Beneficial 48

50 Owner s Free Balance. The MMSS sends Status Intimation messages to the Full Participant to advise it of the Securities movement. 3. The Full Participant moves cash between the accounts intra-bank (journal entry) on receipt of the Status Intimation Trade Settlement Information Flows Corporate Participant Buying (excluding On-us ) Corporate Participant Buying (excluding On-us ) DVP(SELL) Treasury Settling Bank 6 5 SAMOS RTL Y Credit checks or mapping procedures Settling Bank RVP(BUY) 5 Full Participant Strate 3 2 SOR 1 Corporate Participant Notes 1. The MMSS sends a Settlement Allegement message to the Full Participant for the party delivering Securities (DVP). 2. The Full Participant sends a Commit message to the MMSS and the MMSS checks availability of Securities which are then locked/ reserved in the Seller s SOR Account. 3. The MMSS will send a Request for Payment message to the Corporate Participant to settle (this message is sent on the understanding by the Corporate Participant that the relevant Securities have been locked in the Seller s SOR Securities Account). 49

51 4. The Corporate Participant will send a payment instruction to its Settling Bank. 5. The Settling Bank will carry out its credit checks and mapping procedures. If the Settling Bank agrees to fund the cash required for settlement, the Paying Settling Bank sends a Settlement Instruction to SAMOS RTL to credit the beneficiary Participant s Settling Bank and simultaneously a Payment Advice to the receiving Settling Bank. If the decision is not to fund the cash required for settlement, the Settling Bank will send a message to the Corporate Participant notifying it of its decision not to settle. (At this stage the exception handling procedures will be implemented). 6. SAMOS notifies the MMSS of the settlement and simultaneously notifies both the Settling Bank paying and Settling Bank receiving of the settlement. 7. On receipt of the settlement confirmation from SAMOS, the MMSS immediately moves the Securities locked in the SOR Securities Account of the Seller to the new Beneficial Owner s Free Balance and sends Status Intimation messages to the trading parties Participants to advise them of the Securities movement. 8. The Settling Bank will send a settlement message to the Corporate Participant if required. 50

52 Trade Settlement Information Flows Corporate Participants Sell/Delivering Securities and Full Participant buying (excluding On-us ) Corporate Participant Selling (excluding any affect of On-Us ) DVP(SELL) 7 SAMOS RTL 6 7 RVP(BUY) Settling Bank 6 Treasury 6 5 Settling Bank 9 Full Participant Corporate Participant Strate SOR Notes 1. Once the trade has matched, the MMSS will check the availability of Securities in the Corporate Participant s SOR Securities Account and lock /reserve the relevant Securities immediately. Should the Seller not be in a position to deliver at this stage the exception handling procedures will be implemented. 2. The MMSS sends a Settlement Allegement message to the Full Participant for the party settling /receiving Securities. No Settlement Allegement sent to the Corporate Participant which always reports its trades Pre-Committed. 3. The Full Participant sends a Commit message for the settlement to the MMSS. 4. The MMSS sends a Request for Payment message to the paying Full Participant for settlement. 5. The Full Participant will send a payment message to their Settling Bank instructing payment. 51

53 6. The Paying Settling Bank sends a Settlement Instruction to SAMOS RTL to credit the beneficiary Participant s Settling Bank and simultaneously a Payment Advice to the Receiving Settling Bank. 7. SAMOS notifies the MMSS of the settlement and simultaneously notifies both the Settling Bank paying and Settling Bank receiving of the settlement. 8. On receipt of the settlement confirmation from SAMOS, instantaneously the MMSS moves the Securities locked in the SOR to the new Beneficial Owner s Free Balance and sends Status Intimation messages to the trading parties Participants to advise them of the Securities movement. 9. The Settling Bank will send a settlement message to the Corporate Participant if required Trade Settlement Information Flows Corporate Participant Buying On-us Settlement Corporate Participant Buying On-us DVP(SELL) RVP(BUY) Full Participant 8 Settling Bank Treasury Credit checks or mapping procedures Strate SOR Corporate Participant Notes 1. The MMSS sends a Settlement Allegement message to the Full Participant for the trading party selling/delivering Securities. 2. Full Participant sends a Commit message to the MMSS committing to deliver Securities on Settlement Date. 52

54 3. Once the MMSS has checked availability of Securities in the Seller s SOR Securities Account, they are then locked/ reserved. 4. The MMSS will send a payment message to the Corporate Participant to settle. 5. The Corporate Participant will send a Payment Instruction to its Settling Bank to settle. 6. Once the Settling Bank has carried out their credit checks or mapping procedures it will decide whether the Corporate Participant has the ability to settle. If the decision is to fund the settlement, the Settling Bank sends a Settlement Confirmation message to the MMSS confirming that settlement has taken place between its two Clients intra-bank. If the decision is not to fund the cash for settlement, the Settling Bank will send a message to the Corporate Participant notifying it of its decision not to settle. (The exception handling process would be implemented). 7. On receipt of the Settlement Confirmation message from the Settling Bank, MMSS immediately unlocks and moves the Securities locked in the Seller s SOR Securities Account to the new Beneficial Owner s Free Balance and sends Status Intimation messages to the Corporate Participant and the counterparty Full Participant to advise them of the Securities movement. 8. The Settling Bank moves cash to the affected Client on receipt of the Status Intimation. 9. The Settling Bank will send a settlement confirmation to the Corporate Participant, if required by the Client concerned. 53

55 Trade Settlement Information Flows Corporate Participant Selling On-us Settlement On-us Corporate Selling On-Us DVP(SELL) RVP(BUY) Corporate Participant 8 6 Settling Bank Strate SOR Full 5 Participant Notes 1. Once the trade has been matched and allocated in the ETME, the MMSS will check the availability of Securities in the Sellers SOR account and lock /reserve the relevant Securities immediately pending the settlement message from the Buyer's Settling Bank. Should the Seller not be in a position to deliver at this stage the exception handling procedures will be implemented. 2. The MMSS sends a Settlement Allegement message to the Full Participant for the trading party buying/receiving Securities. No allegement is sent to the Corporate Participant which always reports its selling transactions Pre-Committed. 3. The Full Participant sends a Commit message to the MMSS committing to settle and receive Securities. 4. The MMSS sends a Request for Payment message to the Full Participant. 5. The Full Participant will send a payment message to their Settling Bank instructing payment. 54

56 6. The Settling Bank sends a Settlement Confirmation message to the MMSS confirming that settlement has taken place On-us/intra-bank. 7. The MMSS immediately unlocks the Securities in the SOR and moves to the new Beneficial Owner s Free Balance and sends Status Intimation messages to the Corporate Participant and the Full Participant to advise them of the Securities movement. 8. The Settling Bank will send a settlement confirmation to the Corporate Participant if required Trade Settlement Information Flows Corporate Participant Trades with Corporate Participant - On-us Settlement Corporate Participant Trades with Corporate Participant On-us Settlement DVP(SELL) Common Settling Bank RVP(BUY) Corporate Participant B 6 4 Settling Bank A 4 Credit checks or mapping procedures Strate 2 1 SOR Corporate Participant A Notes 1. Once the trade has been matched and allocated in the ETME, the MMSS will check the availability of Securities in the Sellers SOR account and lock /reserve the relevant Securities immediately pending the settlement message from the Buyer's Settling Bank. Should the Seller not be in a position to deliver at this stage the exception handling procedures will be implemented. 2. The MMSS will send a payment message to Corporate Participant A to settle. 55

57 3. Corporate Participant A will send a Payment Instruction to its Settling Bank. 4. Once the Settling Bank has carried out their credit checks or mapping procedures it will decide whether the Corporate Participant has the ability to settle. If the decision is to fund the settlement, the Settling Bank sends a Settlement Confirmation message to the MMSS confirming that settlement has taken place between its two Clients intra-bank. If the decision is not to fund the cash for settlement, the Settling Bank will send a message to Corporate Participant A notifying it of its decision not to settle. (The exception handling process would be implemented). 5. On receipt of the Settlement Confirmation message from the Settling Bank, the MMSS immediately unlocks and moves the Securities locked in the SOR to the new Beneficial Owner s Free Balance and sends Status Intimation messages to the Corporate Participants to advise them of the Securities movement. 6. The Settling Bank will send a settlement confirmation to the Corporate Participants if required. 56

58 Trade Settlement Information Flows - Full Participants Using Same Settlement Bank On-us Settlement Non-Bank Participant Delivering Securities Different Participants Same Settling Bank On-us - Non Bank Participant Delivering Securities DVP(SELL) RVP(BUY) Full Participant 8 Treasury NOT Settling Bank Settling Bank A 7 Full Participant SOR Strate Notes 1. Settlement Allegement messages are sent from the MMSS to the Participants once trade details reported by Traders are matched in the ETME. 2. Participants send Commit messages to the MMSS committing to deliver Securities/settle the cash leg of a trade for their Clients. 3. Once both Commits have been received the Securities of the Seller are locked /reserved in its SOR Securities Account. 4. The MMSS sends a Request for Payment message to the paying Participant. 5. The Participants Settling Bank sends a Settlement Confirmation to the MMSS. 6. The MMSS moves the Securities from the Seller s Reserve Balance SOR Account Balance to the new Beneficial Owner s Free Balance and sends Status Intimation messages to the Participants to advise them of the Securities movement. 7. Participants move funds between the counterparties intra-bank/on-us between the accounts on receipt of the Status Intimation from the MMSS. 8. Settling Bank notifies the delivering party of the cash movement, if required. 57

59 Trade Settlement Information Flows - On-us Full Participants using Same Settling Bank Non-Bank Participant Settling Funds/Receiving Securities Full Participants Same Settling Bank On Us Non-Bank Settling Funds/Receiving Securities DVP(SELL) 5 RVP(BUY) Credit checks Treasury or mapping procedures 9 Full Participant Settling Bank A 8 Full Participant NOT Settling Bank SOR Strate 2 1 Notes 1. Settlement Allegement messages sent from the MMSS to the Participants once trade details reported by Traders is matched in the ETME. 2. Participants send Commit messages to the MMSS committing to deliver Securities/settle the cash leg of a trade for their Clients (Non-Bank Participant has facility in place to allow the Commit to funding). 3. Once both Commits have been received the Securities of the Seller are locked /reserved in its SOR account. 4. The MMSS sends a Request for Payment message to the paying Participant. 5. Participant sends a Payment Instruction to its Settling Bank. 6. The Participants Settling Bank sends a Settlement Confirmation to the MMSS. 7. The MMSS moves the Securities from the Seller s Reserve Balance to the new Beneficial Owner s Free Balance and sends Status Intimation messages to the Participants to advise them of the Securities movement. 58

60 8. Participants move funds between the counterparties intra-bank/on-us between the accounts on receipt of the Status Intimation. 9. Settling Bank notifies the Buyers Participant of the cash movement, if required 5.3 Exception Handling Procedures The table below lists the exception handling procedures adopted in the electronic Money Market. Exception Solution SWIFT down (infrequently and not for extended periods) MMSS down SAMOS settlement window closed All Business Partners and Participants to extend business hours. Strate and SARB to extend windows WAN infrastructure can be used as alternative messaging platform. Strate Disaster Recovery and Business Continuity Procedures to be implemented. Settlement will fail and trades will have to be reported again the next Business Day SAMOS down SAMOS to extend settlement windows. Strate, Participants and Business Partners to extend business hours. Insufficient Securities to deliver Status intimation overdue lack of Securities sent to Participants. Insufficient cash/credit/funding to settle Trade will fail at EOD. 59

61 Further exception handling procedures include: a) Settlement Allegements Settlement Allegements NOT Committed on Settlement Date will be failed by the MMSS EOD procedures and Status Intimations will be sent by the MMSS to both Participants who will have to inform the Traders (its Clients). b) Uncommit by Full Participant A Full Participant can uncommit IF:- Securities are NOT locked in SOR (i.e. Both Commits not received by the (MMSS); and A Full Participant is on both RvP/DvP legs of a trade for settlement. A Full Participant cannot uncommit IF:- The counterparty is a Corporate Participant because if :- The Corporate Participant on RvP (buy) leg and Full Participant on DvP (sell) leg, once the Commit for Securities is received from the Full Participant, Securities are locked immediately and the MMSS sends a Request for Payment message to the Corporate Participant. The Corporate Participant is on DvP (sell) leg and Full Participant on RvP (buy) leg, once the Commit for cash settlement is received from Full Participant, the MMSS immediately sends a Request for Payment message to the Full Participant because the Corporate Participant reports it s sell trades Pre-Committed and its Securities are locked immediately after matching during the settlement process. c) Insufficient Securities to Deliver Settlements committed but no Securities available in SOR Securities Account for locking:- Status intimations sent:- overdue lack of Securities to Participant on DvP leg lack of Securities of counterparty to Participant on RvP leg Securities locking process re-queued until Securities are available:- Once Securities are available, Securities are locked and settlement process continues. If overdue lack of Securities status remains until the end of the Business Day, settlement failed by the MMSS in EOD procedures and Status Intimations will be sent to both Participants which will then have to inform the Traders (its Clients). 60

62 d) Insufficient Cash/Credit/Funding to Settle Settlement Committed and Securities locked in SOR: If settlement declined by Full Participants Treasury or Corporate Participants Settling Bank declines settlement, the Seller cannot wait for the MMSS to fail the settlement at EOD because Seller s Securities are still locked in its SOR Securities Account. If BOTH Participants want Strate to centrally unlock the Securities in the Seller s SOR and cancel the settlement, then: Participant to notify their Trader/Client. Both Participants to send Notice to Cancel to Strate Custody and Settlement division (C & S division) which upon receipt of written notifications from both Participants (in which the Participants need to include the relevant BAN/(s), the C&S division will:- o manually ensure that the same BAN/(s) is/are intimated by both Participants in the Notice to Cancel ; and o initiate the cancellation on BAN/(s) level using a MMSS panel and unlock the Securities. The effect of the cancellation is that the Securities will be unlocked and the BAN/(s) in the MMSS will move into a Cancelled status. Status Intimations MT 548 will be sent by the MMSS to both Participants who will have to inform the Traders (its Clients). 61

63 5.4 Strate Rules and Directives Strate Rules The following Strate Rules are specific to this chapter of the Learning Material and the settlement of Money Market Securities. 7.6 Commitment to settle 7.6 In the event that a Participant who has committed to settle a transaction fails to ensure that it is in a position to settle such transaction on settlement day, the CSD may, in its sole discretion (notwithstanding any action taken in accordance with Rule 7.7.2), impose a fine on that Participant in accordance with a schedule as stipulated by Directive or proceed in terms of the disciplinary procedures set out in terms of the Rules. 7.7 Settlement of transactions Settlement of transactions in MM Securities must take place in the manner stipulated by Directive and in accordance with the Rules Any Settlement of MM Securities which fails as a result of a Participant being unable to meet its commitment to such Settlement or its failure to adhere to the stipulated timelines or operational requirements shall be deemed to be a failed Settlement and will be dealt with in accordance with the Rules and Directives Strate Directives Several Money Market settlement Directives have been published by Strate. The reader of this Learning Material must refer to the Strate website and obtain copies of the latest versions of the key settlement Directives detailed below. The content of any Directive is not repeated in the Learning Material. 62

64 The following Strate Directive is specifically relevant to this chapter of this Learning Material: Directive SE.3 Operational Money Market Windows This Directive caters for the operational time frames for issuing, transaction reporting, clearing, commitment and settlement of MM Securities transactions, and processing of Capital Events. The times stipulated in this Directive is very important. The current times must be sourced from the Strate website Directive SE.4 Electronic Trade Reporting, Matching, Clearing, Commitment and Settlement Money Market Securities This Directive provides details of the procedure that needs to be adhered to for electronic reporting, matching, clearing, commitment and settelement of transactions in MM Securities. 63

65 6 MONEY MARKET CAPITAL EVENTS This chapter of the Money Market Learning Material will provide the reader with an explanation of Capital Events in the Electronic Money Market. (Capital Events are also referred to as Corporate Actions in the Equities and Bonds markets). This chapter is split into four sub-sections namely:- 1) An overview of Money Market Coupon Payments; 2) An overview of Money Market Maturity Payments; 3) Process flows of the two types of Capital Events explained in sub-sections 1 and 2 above; and 4) Applicable Strate Directives. PART ONE 6.1 Coupon Payments A coupon is defined as the amount of interest an Issuer has agreed to pay through the life of the Money Market Security to the investor. Coupon Payments are made at specific intervals throughout the life of the Money Market Security. The Coupon Interval can be: Days Monthly Quarterly Bi-annually Annually Term (in this scenario the Coupon Payment is made on Maturity Date only). In the Strate / electronic environment, Coupon Payments (and Maturity Payments) will not be made on non-business Days. Non-Business Days include Sundays and Public Holidays. When a Coupon Payment (or Maturity Date) falls on a non-business Day, these payments will take place on the next Business Day. 64

66 6.1.1 Coupon Payment Day If Coupon Payment Day is not specified when the Money Market Security is first issued, then the default values will be for: Generic Categories 2 and 3: The day of the month on which the Issue occurred. Generic Category 4: On the 1 st of the month. The following rules apply for all generic categories when Coupon Payment Day falls in a month which has more than 28 days: If the current month is any month except February then the Coupon Payment Day will be the specified Coupon Payment Day of the month. If the current month is February, then either the 28 th or 29 th will be Coupon Payment Day, depending on whether it is a leap year or not. If 30: If the current month is April, June, September or November then the Coupon Payment Day will be the 30 th of the month. If 31: If the current month is January, March, May, July, August, October or December then the Coupon Payment Day will be the 31 st of the month. It must be noted that in respect of generic category 2 and 3 type Money Market Securities, the Maturity Date is the final Coupon Payment Date for all such Money Market Securities. The default for generic category 4 type Money Market Securities, the final Coupon Payment Date, is the first occurrence after Maturity Date of Coupon Payment Day. 65

67 6.1.2 Coupon Payment Period The Coupon Payment Period is the number of days on which the Coupon Payment Calculation is based. Below is an explanation of the different types of Coupon Payment Periods which may occur in the electronic Money Market Monthly If the Coupon Payment Day is equal to Issue Day then: The first Coupon Payment Period is based on the Coupon Payment Interval calculated from the date of issue of the Money Market Security to the day before the Coupon Payment Date, inclusive; Any additional interim Coupon Payment Periods are based on the Coupon Payment Interval calculated from the last Coupon Payment Date to the day before the current Coupon Payment Date, inclusive; The final Coupon Payment Period is based on the number of days from the last Coupon Payment Date to the day before Maturity Date, inclusive. An example of this is stated below: Coupon Payment Day = 25 th of the month Issue Date = 25/06/2003 Maturity Date = 12/06/2004 Coupon Interval = Monthly The first and all interim Coupon Payment Periods will be the days between the 25 th of the previous month and the 24 th of the current month inclusive. The final Coupon Payment Period will be made on Maturity Date, based on the number of days between 25/05/2004 of the previous month and 11/06/2004 inclusive. 66

68 If the Coupon Payment Day does is not equal to Issue Day then: The first Coupon Payment Period is based on the number of days from the date of issue of the Money Market Security to the day before the Coupon Payment Date, inclusive (This could be a short period); Any additional interim Coupon Payment Periods are based on the Coupon Payment Interval calculated from the last Coupon Payment Date to the day before the current Coupon Payment Date, inclusive; The final Coupon Payment Period is based on the number of days from the last Coupon Payment Date to the day before Maturity Date, inclusive. An example of this is stated below: Coupon Payment Day = 1 st of the month Issue Date = 25/06/2003 Maturity Date = 25/06/2004 Coupon Interval = Monthly The first Coupon Payment Period will be based on the days between the 25/06/2003 and 30/06/2003 inclusive. The interim Coupon Payment Periods will be based on the number of days in the month. The final Coupon Payment Period will be made on Maturity Date, based on the number of days between 01/06/ /06/2004 inclusive Quarterly / Bi-annually / Annually If the Coupon Payment Day Indicator is based on the Issue Date then the Coupon Payment Day will be equal to the Issue Day. The first Coupon Payment Period is based on the Coupon Payment Interval calculated from the date of issue of the Money Market Security to the day before the Coupon Payment Date, inclusive; Any additional interim Coupon Payment Periods are based on the Coupon Payment Interval calculated from the last Coupon Payment Date to the day before the current Coupon Payment Date, inclusive; 67

69 The final Coupon Payment Period is based on the number of days from the last Coupon Payment Date to the day before Maturity Date, inclusive. If the Coupon Payment Day Indicator is based on a Calendar then the Coupon Payment Day will be equal to 01. The first Coupon Payment Period is based on the number of days from the date of issue of the Money Market Security to the day before the Coupon Payment Date, inclusive (This could be a short period); Any additional interim Coupon Payment Periods are based on the Coupon Payment Interval calculated from the last Coupon Payment Date to the day before the current Coupon Payment Date, inclusive; The final Coupon Payment Period is based on the number of days from the last Coupon Payment Date to the day before Maturity Date, inclusive Days The first Coupon Period will be from the Issue Date to number of calendar days specified in the days field. The Coupon Period for the interim cycles will be from the Coupon Payment Date of the previous cycle to number of calendar days specified in the Days field. The final Coupon Period will be from the Coupon Payment Date of the previous cycle to one Calendar Day before Maturity Date (This could be a short period) Term The Coupon Period will be from the Issue Date to one Calendar Day before the Maturity Date. 68

70 6.1.3 Calculations of Coupon Payments For all generic categories, on a daily basis, at the end of the Business Day, Money Market Securities that have Coupon Payment Dates or Maturity Dates falling on or before the next Business Day, where the Issuer has elected to have Automated Coupon Payment Calculation, the Coupon Payments will be calculated for all associated holdings in the Securities Ownership Register (SOR). The following will apply for the automated calculation of all Coupon Payments: 1. The Coupon Payments calculated will be recorded in the SOR per Beneficial Owner (or Foreign Nominee), per SOR Securities Account. NOTE: Late payments will be handled outside of the CSD system. The coupon or maturity event will be withdrawn by Strate, but the holdings in the SOR will not be wiped out of the Securities Account of the holder. The ISIN will become inactive on BOD on Maturity Payment Day Coupon Payment Calculation Methods (per SOR balance) There are various methods of calculating the Coupon Payment. Some examples of these methods are listed below: a) Coupon Payment Calculation Method 1 (Minimum Tradable Denomination) Coupon Payment per SOR = {[(Minimum Tradable Denomination * Coupon Rate * No. Days at Coupon Rate) / 365] rounded to 2 decimal places} * [(SOR Nominal Value / Minimum Tradable Denomination)] rounded to 2 decimal places NOTE: The Minimum Tradable Denomination must be greater than or equal to 100,000 for Coupon Payment Calculation Method 1. b) Coupon Payment Calculation Method 2 (using Nominal Value of 1 Rand) Coupon Payment per SOR = [(SOR Nominal Value * Coupon Rate * No. Days at Coupon Rate) / 365] rounded to 2 decimal places. 69

71 c) Coupon Payment Calculation Method 3 (Issuer Agent Calculated) The Coupon Payment Method used when the Issuer Agent has calculated the Coupon Payments and is supplying the Total Coupon Payment as the basis from which Beneficial Ownership level Coupon Payments are calculated. Coupon Payment per SOR = [(SOR Nominal Value / Total Issued Nominal Value) * Total Coupon Payment Amount supplied by the Issuer] rounded to 2 decimal places. d) Fixed Coupon Rates: Generic Category 2 The Coupon Payments are calculated as per the specified Coupon Payment Calculation Method per Money Market Security. e) Variable Coupon Rates: Generic Categories 3 and 4 Where the Issuer elects to have the CSD calculate the Coupon Payments based on a Variable Coupon Rate, it is the responsibility of the Issuer to ensure that the variable Coupon Rates used for the automated calculation of the Coupon Payments per ISIN are updated whenever the variable rates change. f) Variable Coupon Rate Changes In order to ensure that the Issuer and the CSD are holding the same Variable Coupon Rates, there will be an automatic reconciliation process (for the Total Coupon Payment Amount as at the next Coupon Payment Date for the ISIN in question), between the Issuer and the CSD triggered by the following events: Change of the Coupon Rate. Coupon Payment Date. The Participants will be informed of the Variable Coupon Rate changes. 70

72 g) Variable Coupon Rate Changes (Error Correction) Should it happen that an incorrect Coupon Rate was added, the replacement of the incorrect Coupon Rate must be facilitated. The automatic reconciliation process (for the Total Coupon Payment Amount as at the next Coupon Payment Date for the ISIN in question), between the Issuer and the CSD will be triggered. The Participants will be informed of the Variable Coupon Rate changes. h) Generic Category 3 Variable Coupon Rates on Coupon Interval Only The Coupon Rate is linked to an underlying rate/s, and/or a combination of rates and other factors, as of the close of business on the day prior to the Coupon Payment. The resultant rate may be compared to a minimum (Floor) and/or a maximum (Cap) rate and translated into the relevant limit rate if it exceeds these boundaries. i.e. If the Cap Rate is exceeded then the Coupon Rate = the Cap Rate or if the extracted Coupon Rate is less than the Floor Rate, then the Coupon Rate = the Floor Rate. Note: The Cap and Floor Rate functionality will not be implemented until the linkages to the various rates have been implemented and the formulae for deriving the actual rates have been built as a series of parameters. 1. The Money Market Security is issued with an initial rate for the first Coupon Period and the first Coupon Payment is calculated based on this rate. 2. On the first and each subsequent Coupon Interval Day (the Coupon Payments Day for the previous Coupon Period), the Coupon Rate for the next Coupon Period must be added. 3. The Coupon Payments are calculated as per the specified Coupon Payment Calculation Method per Money Market Security. 71

73 i) Generic Category 3 Variable Coupon Rates throughout the Coupon Period The Money Market Security is issued with an initial rate and is linked thereafter, on a daily basis to an underlying rate/s, and/or a combination of rates and other factors (i.e. the Coupon Rate can change on a daily basis). The resultant rate may be compared to a minimum (Floor) and/or a maximum (Cap) rate and translated into this rate if it exceeds these boundaries. i.e. If the Cap Rate is exceeded then the Coupon Rate = the Cap Rate or if the extracted Coupon Rate is less than the Floor Rate, then the Coupon Rate = the Floor Rate. Note: The Cap and Floor Rate functionality will not be implemented until the linkages to the various rates have been implemented and the formulae for deriving the actual rates have been built as a series of parameters. The Coupon Payment is calculated as per the specified Coupon Payment Calculation Method, for each day in the payment period, using the rate extracted on that day, and the results accumulated for the full Coupon Period. For public holidays and non-business Days, the rate used on the previous Business Day applies. j) Generic Category 4 Variable Coupon Rates throughout the Coupon Period The Money Market Security is issued with an initial rate and the rate can be re-negotiated on an ad hoc basis (i.e. the Coupon Rate can change on a daily basis). Note: The Cap and Floor Rate functionality will not apply to Generic Category 4 Money Market Securities. The Coupon Payment is calculated as per the specified Coupon Payment Calculation Method, for each day in the payment period, using the rate applicable on that day, and the results accumulated for the full Coupon Period. 72

74 For public holidays and non-business Days, the rate used on the previous Business Day applies Coupon Reconciliation Date The Coupon Reconciliation Date (also known simply as the Reconciliation Date) is the number of days before Coupon Payment Date. In Strate, the Reconciliation Date will be one (1) Business Day before Coupon Payment Day. If the Coupon Payment Date falls on a Saturday or Monday, the Reconciliation Date will be on a Friday. If Friday is not a Business Day, then the Reconciliation Date will be on the previous Business Day. On Reconciliation Date, Strate will undertake the following activities within the Money Market system: Calculate the Coupon Payment Amounts at SOR Securities Account Total Holding level per ISIN. Accumulate the Total Coupon Payment Amount per ISIN per Participant. Accumulate the Total Coupon Payment Amount per ISIN per Issuer. This information and the event details will be disseminated to the Issuer Agents and Participants. Participants may elect to receive, per event, the information in the following formats: 1. Coupon Payment Amounts per SOR Securities Account. 2. Total Coupon Payment Amount per Participant and Issuer per ISIN. 3. Issuer Agent may only receive it at Total Amount. Note: The Participants may choose to receive any combination of the above options. Should the Total Coupon Payment Amount calculated by the CSD, not agree with that calculated by the Issuer due to a missing or incorrect Variable Coupon Rate or a rounding discrepancy, then the reason for the difference must be established. In such circumstances the Variable Coupon Rate must be added/amended, and the Coupon Payment Amounts recalculated by the CSD. The Issuer Agents must confirm that 73

75 the rounding discrepancy is acceptable. If not acceptable, the payments must be made outside the CSD and the CSD must be notified accordingly Automated Coupon Payments It is not possible to facilitate the automatic payment of the Coupon Payment Amounts into the bank accounts nominated by the Participant Clients. The Coupon Payments per Participant will be calculated per ISIN and these amounts will be paid to the Participants via SAMOS or intrabank where settlement is On-us. The Participants will allocate the individual Coupon Payment Amounts as per the downloaded data. Note: For Money Market Securities in all generic categories, Coupon Payments will not be made for Issuers own holding in the SOR in the Issuers own Money Market Security. Issuer Agents have to inform the CSD if there are Coupon Payments that will not be paid on Payment Date and request Strate to remove these from the system. The various methods of automated Coupon Payments are detailed below: a) Payment of Total Coupon Amounts to Participants For all Money Market Securities where the Issuer has elected to have Automated Coupon Payment Calculation option, the following will be automated: the payment of the Coupon Amount to the Participants via their Settling Bank (via SAMOS or intra-bank). the notification to Participants of the disbursement amounts. b) Payment of Total Coupon Amounts to Participants (No Calculations) For each Money Market Security in Generic Category 2, 3 and 4, the Issuer can elect to pay the Participants via SAMOS, without having the Coupon Payments calculated by the CSD. The Issuer Agent must supply the Total Coupon Payment Amount to the CSD. 74

76 The following will be automated: the payment of the Coupon Amounts per ISIN to the Participants via their Settling Bank (via SAMOS or intra-bank). the notification to Participants of the SOR holdings in the Money Market Security at Beneficial Ownership (or foreign Nominee) level Final Coupon Payment Date Final Coupon Payments that fall after the Maturity Date will only be flagged as paid on the Final Coupon Payment Date when the payments have been processed Coupon Payments for Pledged Holdings A Participant may record pledges for their Clients. This service is provided to prevent trades being executed against the Pledged Holdings. (Please refer to the Pledge chapter 7 of the Learning Material for more information on pledge). On Coupon Payment Date, the Coupon Payments for Pledged To holdings will be automatically made to the Beneficial Owner (or foreign Nominee) of the SOR Securities Account in question. 75

77 PART TWO 6.2 Maturity Payments The maturity of a Security refers to date on which the Security redeems. The Maturity Date is also known as Redemption Date and is the closing date at which the contract ends on the last payment Maturity Reconciliation Date The Reconciliation Date for Securities which are maturating is one (1) Business Day prior to Maturity Date. If the Maturity Payment Date falls on a Saturday or Monday, the Reconciliation Date will be on a Friday. If Friday is not a Business Day, then the Reconciliation Date will be on the previous Business Day. On Reconciliation Date, Strate will undertake the following activities within the Money Market system; Accumulate the Total Maturity Payment Amount per ISIN per Participant. Accumulate the Total Maturity Payment Amount per ISIN per Issuer. This information and the event details will be disseminated to the Participants. Participants may elect to receive, per event, the information in the following formats: 1. Total Maturity Amount per Participant / Issuer per ISIN. 2. Maturity Amounts per SOR Securities Account. Note: The Participants may elect to receive any combination of these options Automated Maturity Payments The total value of the Maturity Payments per Participant will be accumulated and these total amounts paid to the Participants via SAMOS or intra-bank. The Participants will allocate the individual Maturity Payment Amounts as per the downloaded data. 76

78 All Maturity Payments for all generic categories will be automated except where on an ad-hoc maturity in respect of generic category 4 Securities, the Issuer elects to pay the maturity outside of the system. Note: 1. On Maturity Date, the Issuers own holding in the SOR in his own Money Market Security Account will be cleared to zero without initiating a Maturity Payment. 2. No trading in a Money Market Security will be permitted on its Maturity Date. For all generic categories, on a daily basis, at the end of the Business Day, the Money Market system will establish which Money Market Securities have Maturity Dates falling before or on the next Business Day. The Maturity Payments are equal to the Nominal Value of the Money Market Security holdings in the SOR at Beneficial Ownership (or foreign Nominee) level and are made on Maturity Date. The following will be automated on Maturity Date: the payment of the Total Maturity Amounts to the Participants via their Settling Banks (via SAMOS). the notification to Participants of the disbursement amounts at Beneficial Ownership (or foreign Nominee) level, if required. When the Maturity Date is reached and the Maturity Payments have been paid to Participants, the associated Money Market Security holdings in the SOR, on receipt of confirmation from SAMOS/Settling Bank that payment of the Maturity Amount was effected, will be set to zero and the Money Market Security will be flagged as no longer active in the Money Market Security Register. Where Coupon Payments are still outstanding, these will be made on the relevant Coupon Payment Date Maturity Payments for Pledged Holdings A Participant may record pledges for their Clients. This service is provided to prevent trades being executed against the Pledged Holdings. (Please refer to the Pledge chapter 7 of the Learning Material for more information on pledge). 77

79 Three days prior to Maturity the CSD will send a report to the relevant Participants indicating that Money Market Securities that have been pledged will mature in three days time. The onus is on the Participants in question to follow up on these pledges with their Clients. On Maturity Date, holdings that are pledged will be automatically released and the Maturity Payments made to the Beneficial Owner (or foreign Nominee) of the SOR Securities Account in question. The associated Money Market Security holdings in the SOR will be set to zero Ad hoc Maturity (Out of Scope for Phase 1 & 2) It is possible for an Issuer to initiate Maturity for a Money Market Security on an ad hoc basis (Generic Category 4 only). There are three possible scenarios: 1. The Money Market Security will mature on the following Business Day. 2. The Money Market Security will mature on the current day. 3. The Issuer will buy back all the holdings in the Money Market Security via a normal trade/s. If the Issuer elects to handle the ad hoc Maturity outside the CSD, the Issuer must inform the CSD that the Money Market Security has been matured and the Money Market Security must be automatically updated as Matured and the Coupon Payments as fully paid up. (i.e. The Issuer will handle the Final Coupon Payment outside the system). The Participants will be informed. These three scenarios are explained in more detail below. a) Money Market Security matures on the following Business Day The Maturity Date must be updated to the following Business Day. If the Issuer has elected Automated Coupon Payment Calculation for the Money Market Security in question, the standard daily processes will cater for all final Coupon Payment and Maturity Payment requirements, and associated processing. 78

80 b) Money Market Security matures on the current day If the Issuer has elected Automated Coupon Payment Calculation for the Money Market Security in question, the Maturity Date must be updated to the current day, and the Issuer must immediately initiate the Maturity process. The following will be automated as a result of the initiation of the Maturity process: The Coupon Payment Amounts due on the next Coupon Payment Dates will be calculated and stored against the SOR holdings at Beneficial Ownership (or foreign Nominee) level for the Money Market Security in question. Payment of the outstanding Coupon Payment Amounts to the Participants, if Coupon Payments are due on Maturity Date. Payment of the Maturity Amounts to the Participants via their Settling Banks (via SAMOS). Notification to Participants of the disbursement amounts. c) Issuer Repurchases all Holdings in Money Market Security If the Issuer buys back the total Money Market Security holdings, then no Coupon and Maturity Payments will be made for the Money Market Security in question. If the Money Market Security has no Maturity Date (generic category 4), the repurchase of all holdings in the Money Market Security will not equate with Maturity and the Maturity Date must be set, if the Issuer wishes to withdraw the Money Market Security from the market. 6.3 Coupon and Maturity Payments on Public Holidays The validation criteria for the creation of a Money Market ISIN ensure that at the time of issue, the Maturity Date of the Money Market Security will not fall on a weekened (Saturdays and Sundays) or a Public Holiday. 79

81 This ensures that Maturity Date and Maturity Payment Date always fall on the same date. (Saturdays are no longer seen by SAMOS as a normal processing day). Maturity Payments that take place after Maturity Date, because the date in question is not a Business Day would be due to a new or an ad hoc Public Holiday (e.g. an election day) being declared after the issue of the Money Market Security. This will be a rare circumstance. The declaration of a new or an ad hoc Public Holiday can also result in a Coupon Date or a Coupon and/or Maturity Payment Date that fell on a Business Day when the Money Market Security was issued, now falling on a Public Holiday. Coupon and Maturity Payment Dates that fall on a non-business Day (as the result of the declaration of a new or an ad hoc Public Holiday), will be paid on the first Business Day after the actual Coupon or Maturity Dates. 6.4 Settling Bank Confirmations for Coupon and Maturity Payments An Issuer must appoint their own Issuer Agent, Participant and Settling Bank and these can all be different institutions, but they must all be accepted as Business Partners by Strate and have the appropriate roles in the MMSS. The following requirements are catered for in the MMSS: The relationship between the Issuer and their elected Issuer Agent, Participant and Settling Bank is maintained. The Issuer is able to change these relationships i.e. the Issuer is able to appoint a different Issuer Agent, Participant or Settling Bank as and when required and these changes are immediately reflected in the MMSS. The Settling Bank is able to send settlement confirmations to the CSD for On-us settlement of trades in respect of a Corporate Participant and coupons and maturities. 80

82 (Many of the Money Market Issuers are Banks and SAMOS Participants. These Money Market Issuers would appoint their own organisations as their Settling Banks). NOTE: An Issuer can appoint more than one Issuer Agent and may have several other institutions acting as their Issuer Agents and actively issuing Money Market Securities on their behalf. An Issuer can only appoint one Participant and one Settling Bank to actively act on their behalf. In other words, an Issuer can be linked to many Issuer Agents, one Participant and one Settling Bank. 81

83 PART THREE 6.5 Capital Event Process Flows The below process flows diagrammatically explain the various Coupon and Maturity Payment options. NOTE: The Capital Event number is carried / referenced in all messages Coupon - Cash Settling information flows Issuer/Issuer Agent IS Settling Bank CSD Calculates and Issuer Agent agrees Settlements of Coupons COUPON Payment - Cash Settling information flows Issuer/Issuer Agent IS Settling Bank CSD Calculates Coupons Issuer Agent/ Settling bank 4 By Particiant Settling Banks/ Participant TOTAL By Participant 1 2 Strate Aggregate Reconcile By Participant Participant On- us By By Participant ByParticipant 5 SAMOS RTL By Participant 82

84 1. Strate sends a Coupon Amount Notification Message to the Issuer Agent (IA) after the cut off time for the settlement for free and against payment trades on Reconciliation Date which will include: the unique Capital Event number generated and allocated to the specific event by Strate; and the Total Coupon Amount to be paid by the Issuer. Strate also notifies at the same time the Participants of the Coupon Amount and event number at Participant level or at SOR level depending on the standing instruction. 2. The IA will check the calculation and send a Confirmation of Coupon Payment message to Strate. 3. On BOD of Payment Date, Strate sends a payment message to the IA, broken down by Participant, for the coupon calculation. 4. The Issuer s Settling Bank will pay the relevant coupon, aggregated at Participant level and the IA s Settling Bank sends settlement instructions to SAMOS RTL for each Participant to be paid and simultaneously a payment instruction to each of the Settling Banks of the Participants to be credited. 5. SAMOS will send Confirmation of Payment messages, for each Participant, to both the paying and receiving Settling Banks as well as Strate. 6. The Settling Bank sends a Settlement Confirmation Message to Strate to confirm the transfer of funds intra-bank between itself and its Participant. 7. Strate will aggregate the Confirmation of Payment messages received for each Participant settled and reconcile to the Total Coupon Payment Amount. 8. Strate will send Coupon Confirmation message to the IA for the Total Coupon Amount, and to each Participant the amount paid to them at Participant level or at SOR level depending on the standing instruction. 83

85 6.5.2 Coupon - Cash Settling information flows Issuer/Issuer Agent IS Settling Bank CSD Calculates and Issuer Agent disagrees Settlements of Coupons COUPON Payment - Settlement information flows Issuer/Issuer Agent IS Settling Bank - CSD Calculates and IA disagrees Issuer Agent/ Settling bank Strate Participant 3 1. Strate sends a Coupon Amount Notification Message to the Issuer Agent (IA) after the cut off time for the settlement for free and against payment trades on Reconciliation Date which will include: the unique Capital Event number generated and allocated to the specific event by Strate; and the total coupon amount to be paid by the Issuer. Strate also notifies at the same time the Participants of the Coupon Amount and event number at Participant level or at SOR level depending on the standing instruction. 2. The IA will check the calculation and disagrees with the Coupon Amount calculated by Strate. 3. Strate sends a Capital Event Withdrawal message to the IA and Participants. 84

86 6.5.3 Coupon - Cash Settling information flows Issuer/Issuer Agent IS Settling Bank Issuer Agent Calculates Settlements of Coupons COUPON Payment - Cash Settling information flows Issuer/Issuer Agent IS Settling Bank IA Calculates Coupons Issuer Agent/ Settling bank 5 By Participant Settling Banks/ Participant TOTAL By Participant 1 2 Strate Aggregate Reconcile By Participant Participant On-us By Participant By Participant 6 SAMOS RTL By Participant 1. Strate sends a Coupon Event Notification Message to the Issuer Agent (IA) after the cut off time for the settlement for free and against payment trades on Reconciliation Date, which will include: the unique Capital Event number generated and allocated to the specific event by Strate. 2. The IA will perform the calculation for Capital Event and send a Coupon Amount Notification message to Strate. 3. On Reconciliation Date, Strate will then send a Coupon Amount Notification message to the Participant at the SOR level or at the Participant level depending on the standing instruction. 4. On BOD of Payment Date, Strate sends a payment message to the IA, broken down by Participant, for the coupon calculation. 85

87 5. The Issuer s Settling Bank will pay the relevant coupon, aggregated at Participant level and the IA s Settling Bank sends settlement instructions to SAMOS RTL for each Participant to be paid and simultaneously a payment instruction to each of the Settling Banks of the Participants to be credited. 6. SAMOS will send Confirmation of Payment messages, for each Participant, to both the paying and receiving Settling Banks as well as Strate. 7. The Settling Bank sends a Settlement Confirmation Message to Strate to confirm the transfer of funds intra-bank between itself and its Participant. 8. Strate will aggregate the Confirmation of Payment messages received for each Participant settled and reconcile to the Total Coupon Payment Amount. 9. Strate will send Coupon Confirmation message to the IA for the Total Coupon Amount, and to each Participant the amount paid to them at Participant level or at SOR level depending on the standing instruction. 86

88 6.5.4 Coupon - Cash Settling information flows Issuer NOT a Settling Bank- CSD Calculates and Issuer Agent Agrees Settlements of Coupons COUPON - Cash Settling information flows Issuer Agent NOT Settling Bank CSD Calculates Coupons Issuer Agent Issuer Settling Banks/ Participant TOTAL By Participant 9 By Participant M 1 2 Strat Aggregate Reconcile 8 7 SAMOS 3 Participant By Participant On- us By Participant Mandate between Issuer and Settling Bank to settle payment instructions from Strate Issuer s Settling Bank 1. Strate sends a Coupon Amount Notification Message to the Issuer Agent (IA) after the cut off time for the settlement for free and against payment trades on Reconciliation Date which will include: the unique Capital Event number generated and allocated to the specific event by Strate; and the Total Coupon Amount to be paid by the Issuer. Strate also notifies at the same time the Participants of the Coupon Amount and event number at Participant level or at SOR level depending on the standing instruction. 87

89 2. The IA will check the calculation and send a Confirmation of Coupon Payment message to Strate. 3. On BOD of Payment Date, Strate sends a payment message to the IA, broken down by Participant, for the coupon calculation. 4. The IA will send a settlement instruction to the Issuer s Settling Bank instructing payment. Should the Issuer choose to send the settlement instruction to its Settling Bank itself, then the Issuer would have to obtain the detail of the settlement amounts broken down by Participant from the IA. 5. The Issuer s Settling Bank will pay the relevant coupon, aggregated at Participant level and the IA s Settling Bank sends settlement instructions to SAMOS RTL for each Participant to be paid and simultaneously a payment instruction to each of the Settling Banks of the Participants to be credited. 6. SAMOS will send Confirmation of Payment messages, for each Participant, to both the paying and receiving Settling Banks as well as Strate. 7. Strate will receive Settlement Confirmation Messages to confirm the transfer of funds intra-bank for On-us payment transactions and from SAMOS for non On-us payment transactions. 8. Strate will aggregate the Confirmation of Payment messages received for each Participant settled and reconcile to the Total Coupon Payment Amount. 9. Strate will send Coupon Confirmation message to the IA for the Total Coupon Amount, and to each Participant the amount paid to them at Participant level or at SOR level depending on the standing instruction. 88

90 6.5.5 COUPON - Cash Settling information flows Issuer NOT a Settling Bank- Issuer Agent Calculates Settlements of Coupons COUPON Payment - Cash Settling information flows Issuer Agent IS NOT Settling Bank IA Calculates Coupons IssuerAgent Issuer Settling Banks/ Participant TOTAL By Participant 10 By Participant M 1 2 Strate Aggregate Reconcile 9 8 SAMOS RTL 4 Participant By Participant ON US By Participant Mandate between Issuer and Settling Bank to settle payment instructions from Strate Issuer s Settling Bank 1. Strate sends a Capital Event Notification Message to the Issuer Agent (IA) after the cut off time for the settlement for free and against payment trades on Reconciliation Date which will include: the unique Capital Event number generated and allocated to the specific event by Strate. 2. The IA will perform the calculation and send a Coupon Payment message to Strate. 89

91 3. On Reconciliation Date, Strate will then send a Coupon Amount Notification message to the Participant at the SOR level or at the Participant level depending on the standing instruction. 4. On BOD of Payment Date, Strate sends a payment message to the IA, broken down by Participant, for the coupon calculation. 5. The IA will send a settlement instruction to the Issuer s Settling Bank instructing payment. Should the Issuer choose to send the settlement instruction to its Settling Bank itself, then the Issuer would have to obtain the detail of the settlement amounts broken down by Participant from the IA. 6. The Issuer s Settling Bank will pay the relevant coupon, aggregated at Participant level and the IA s Settling Bank sends settlement instructions to SAMOS RTL for each Participant to be paid and simultaneously a payment instruction to each of the Settling Banks of the Participants to be credited. 7. SAMOS will send Confirmation of Payment messages, for each Participant, to both the paying and receiving Settling Banks as well as Strate. 8. Strate will receive Settlement Confirmation messages to confirm the transfer of funds intra-bank for On-us payment transactions and from SAMOS for non On-us payment transactions. 9. Strate will aggregate the Confirmation of Payment messages received for each Participant settled and reconcile to the Total Coupon Payment Amount. 10. Strate will send Coupon Confirmation message to the IA for the Total Coupon Amount, and to each Participant the amount paid to them at Participant level or at SOR level depending on the standing instruction. 90

92 6.5.6 Maturity Payment- Cash Settling information flows Issuer Agent IS NOT Settling Bank 1. Strate sends a Maturity Amount Notification Message to the Issuer Agent (IA) after the cut off time for the settlement for free and against payment trades on Reconciliation Date which will include: the unique Capital Event number generated and allocated to the specific event by Strate; and the Maturity Amount to be paid by the Issuer. Strate also notifies at the same time the Participants of the Maturity Amount and event number at Participant level or at SOR level depending on the standing instruction. 91

93 2. On BOD of Payment Date, Strate sends a payment message to the IA, broken down by Participant, for the Maturity Amount. 3. The IA will send a settlement instruction to the Issuer s Settling Bank instructing payment. Should the Issuer choose to send the settlement instruction to its Settling Bank itself, then the Issuer would have to obtain the detail of the settlement amounts broken down by Participant from the IA. 4. The Issuer s Settling Bank will pay the relevant maturity, aggregated at Participant level and the IA s Settling Bank sends settlement instructions to SAMOS RTL for each Participant to be paid and simultaneously a payment instruction to each of the Settling Banks of the Participants to be credited. 5. SAMOS will send Confirmation of Payment messages, for each Participant, to both the paying and receiving Settling Banks as well as Strate. 6. Strate will receive Settlement Confirmation Messages to confirm the transfer of funds intra-bank for On-us payment transactions and from SAMOS for non On-us payment transactions. 7. Strate will aggregate the Confirmation of Payment messages received for each Participant settled and reconcile to the Total Maturity Payment Amount. 8. Strate will send Maturity Confirmation message to the IA for the Total Maturity Amount, and to each Participant the amount paid to them at Participant level or at SOR level depending on the standing instruction. 92

94 6.5.7 Maturity Payment- Cash Settling information flows Issuer/Issuer Agent IS Settling Bank 1. Strate sends a Maturity Amount Notification Message to the Issuer Agent (IA) after the cut off time for the settlement for free and against payment trades on Reconciliation Date, which will include: the unique Capital Event number generated and allocated to the specific event by Strate. Strate also notifies at the same time the Participants of the Maturity Amount and event number at Participant level or at SOR level depending on the standing instruction 2. On BOD of Payment Date, Strate sends a payment message to the IA, broken down by Participant, for the Maturity Payment. 3. The Issuer s Settling Bank will pay the relevant maturity, aggregated at Participant level and the IA s Settling Bank sends settlement instructions to SAMOS RTL for each 93