JSE UPDATE COMMUNICATION SESSION - CAPE TOWN Leanne Parsons 16 November 2006

1. JSE UPDATE COMMUNICATION SESSION - CAPE TOWNLeanne Parsons 16 November 2006

2. AGENDAJSE Update • Orion Project • Status of Release A • Status of Release B • Status of Release C • Equities Trading System Replacement Project • Functional Summary • Technical Summary • Project Timeline • Customer Testing • User Documentation • JSE Managed Network (JSE & MTN) • Project Background and Objectives • MTN NS and Solution Overview • Internet Phase • International Links Phase • Customer Network Phase • Environment • Draft Costing

3. Release A: Migration Plan System Test & UAT (Corporate Actions) Internal ETE Business ETE Development and Testing Parallel Run Prep Parallel Run Start 10 days of Client Specific Test-File Generation Generation of Generic Test-File PotentialGo-Live

4. Release A: Progress Made to Date • In terms of Release A, efforts on the project have centred around: • Preparation for End to End Testing • Ongoing testing in the production environment, including the closure of functional and technical errors from previous UAT phases • Ongoing system performance testing and tuning • Re-design, build and testing of Corporate Actions functionality • Statistics verification and checking • Creation of updated test conditions, scenarios and scripts • Execution of 3 passes of internal ETE testing • Business End to End Testing (UAT) • Execution of 2 full cycles of business ETE • Results verification and confirmation • Error correction and close out • Operational Readiness (Parallel) Preparation • Start of Parallel Run

5. Release A: Next Steps • A further set of system generated non-client specific EOD Equity Dissemination files were made available during the week of the 9 October 2006. • At the completion of ETE on Friday 10 November 2006, the project has moved into the operational readiness phase. During this time, new Orion systems will be run in parallel with the legacy applications to ensure operational readiness. This is a cautious approach to ensure that we do not impact our existing services. Should operational readiness be proven quickly it is likely that the JSE will be ready for implementation of Release A on either 27 November 2006 or 11 December 2006. • The JSE did commit to provide new client-specific EOD files for a minimum of ten business days (in addition to the current files) prior to the formal implementation (Go-Live) of Release A. This parallel phase officially commenced on Monday, 13 November. • The first set of client specific EOD test files were already provided on Sunday evening, which contained the data for Friday, 10 November. • Any queries on the files should be sent to: eodspec@jse.co.za

6. Release B: Migration Plan Vendor Development and System Testing System /Integration Test JSE Formal Integration Testing Formal User Testing Dress Rehearsal Training POSSIBLEGO-LIVE

7. Release B: Progress Made to Date • MSS Update: • Design Close-out: • A total of 33 functional specifications have been signed off. • Reports Functional Design has been signed off and Reports Technical specifications are complete and agreed with FRI. • The following Design activities are complete: • Interface Design • Batch Design • Data Integrator (the MSS loader tool for file interfaces) and Technical Architecture • All Dissemination Designs • Update on Code Delivery: • FRI has delivered 10 code drops to date. • Testing: • Progress with installation of FRI code drops into the test environment. • System Test Models signed-off for 70% of all Functional System Test Models, expected to be completed during 2006.

8. Release B: Progress Made to Date (Cont.) • MSS Workgroups Update • Two successful screen demonstration sessions were done on some of the new system screens with the Orion Core Group. • Demonstration of the screens to the entire market at a later stage (only applicable to Johannesburg). • All members have signed the required Non-disclosure Agreements – every staff member should have access to the functional specifications. • TWG Sessions were held for developers involved in downstream applications: • To discuss new dissemination files and API’s • To provide an overview of fundamental functional changes • To provide a demonstration of new functional screens • MSS Training Update • The JSE will be offering Conceptual and User Training in Cape Town during 2007, prior to Go-Live.

9. Release B: Progress Made to Date (Cont.) • Equities Clearing Update • Design Close-out: • Functional specifications completed and signed-off. • Technical interface specifications completed. • This concludes all of the design portions for the Equities Clearing application. • Update on Code Delivery: • Final code drop, including bug fixes, has been received and installed. • Training: • Internal training with the Clearing and Settlement Division has commenced on the installed application. • Clearing training is due to commence early 2007. • ECS training manuals have been delivered and are currently under internal review.

10. Release B: Progress Made to Date (Cont.) • Data Conversion Update: • Conversion design specifications for the Market Services Solution Corporate Actions module are still in progress. Specifications for data covering the rest of the Market Services Solution’s modules have all been finalised. • Specifications detailing the Data Reconciliation requirements are currently in progress. These specify the data extracts and reporting metrics that will be used to verify the converted data between the source systems and the Market Services Solution. • Activities covering the build and unit test of the numerous components to source and transform the data for these modules that have completed design, is well underway • Conversion testing activities are currently in progress where data from select brokers is being converted into the Market Services Solution based upon the conversion rules specified in the conversion design specifications.

11. Release B: Progress Made to Date (Cont.) • Surveillance System Update: • User Functional Specifications have been signed off. • Technical Specification development in progress. • Business Functions to be tested across all Surveillance modules have been identified. • Update on Technical Specifications to the Market: • MSS API Specs • All the interface specifications have been published and are final • All MSS Dissemination Specs are final • Please forward any queries relating to: • Dissemination Specs: orion_spec_mssdis@jse.co.za; and • API Specs: orion_spec_mssapi@jse.co.za • Testing Update: • ECS Systems Test Preparation and Execution by Accenture is completed for all ECS modules. • System Test Preparation of Test Models and Test Scripts for all other Release B systems are in progress. • System Test Execution for other Release B systems expected to start Q1 2007.

12. Bandwidth Requirements:Context & Assumptions of the Testing • LANmetrix (LMX) conducted a bandwidth test on the MSS on 23/11/2005. • The test was conducted on the Market Services Code Drop Environment utilising a network sniffer that was inserted into the Local Area Network and configured to record all traffic flowing between the user workstation and the MSS terminal server. • On 27 February 2006, representative workload scenarios were constructed and agreed to represent a typical workload of an MSS user, during a typical day, in a fully deployed MSS environment. • LMX has conducted a new simulation/modelling exercise which combines the recorded transactions with the new scenarios. • MSS is being deployed over Microsoft terminal services which will result in a Bandwidth (BW) increase over BDA. • The BW consumption of the application would be related to the intensity of use and the usage patterns of the MSS. • Reporting usage patterns will have a significant impact on the BW consumption. • The BW usage would naturally increase with the number of users concurrently operating across the network. • Therefore the approach was to simulate a series of scenarios which are believed to be representative of typical user scenarios in the application. • Further details on the testing and on the scenarios can be made available on request.

13. Bandwidth Requirements(Cont.) • Application Performance - Summary of Simulation Results

14. Bandwidth Requirements(Cont.) Summarized Conclusions of the Testing Exercise: • In summary the recommendations coming out of the test were: • For less than 2 users, a 64kbps link is sufficient. • For 3-40 users, bandwidth requirements increase in increments of 128kbps for every 5 additional users or less. • For more than 40 users, requirements grow in increments of 64kbps of bandwidth per 5 users over and above the 1Mbps link required for the 40 users. • The recommendations above can be used to calculate the required bandwidth to support any number of users. • E.g. BW for 57 users = [40/5*128] + [17/5*64] • = [8 * 128] + [4 * 64] • = 1280 kbps

15. QUESTIONS? Refer all Release B queries to Orion_Info@jse.co.za

16. We are here Release CTime Line JSE Demarcation STT Detail Design STT Development and System Testing Config H/W Core Systems Final Code drop Prep Env. JSE Internal Integration Testing Operational Readiness JSE Formal Integration Testing JSE Internal Training Formal User Testing (FE & API) Informal User Testing Important upcoming activities User Training Draft API Specs Final API Specs Weekend Dress Rehearsals Draft IP Readiness Requirements Final IP Readiness Requirements Contingency C C Proposed APD deployment Proposed FDD deployment Final EOD Specs Draft EOD Specs

17. RELEASE CStatus Update • JSE internal testing for Release C commenced in November 2006. • The training approach for members will be distributed to the market before 15 December 2006. • The training booking requirements document will be distributed by end January 2007, highlighting the training dates and timeslots. The JSE intends to start training by end February 2007 • We would like to remind all users to review the API Specification and User Connectivity documentation. • The final API Specification document is expected to be issued mid-December 2006.

18. RELEASE CConnectivity Requirements • New connectivity requirements in terms of Release C of project Orion entails the following: • All trading members are able to access the new system via their existing lines to SAFEX. The new system runs off TCP/IP, trading members need to in conjunction with the JSE, load the TCP/IP protocol on these circuits. Routers currently support the IP protocol thus it should only be a configuration issue. • The JSE has contracted an external company to conduct independent testing and verification of bandwidth requirements. Once these are complete the JSE will publish the bandwidth requirements which may result in members having to increase their line capacities.

19. RELEASE CConnectivity Requirements cont. • Similarly a user may want to use their existing circuit for trading (on the current SAFEX system) and testing on the new system until go live mid 2007 – this may also require the increase in their bandwidth (perhaps only temporarily) or to schedule their testing outside of core trading hours as not to impact their production systems. • The JSE is proposing to offer a potential solution for members using the managed network through MTN Network Solutions. This will ultimately result in members having more flexible ways of connecting to the JSE (e.g. 3G, ADSL, leased line to a local POP of MTN to reduce line costs, etcetera). Details of this will also be communicated shortly here after.

20. QUESTIONS? Refer all Derivative queries to Derivative_Info@jse.co.za

21. JSE EQUITIES TRADING SYSTEM REPLACEMENTMARKET COMMUNICATION SESSION – CAPE TOWN16 November 2006 Leanne Parsons

22. AGENDA Equities Trading System - Market Communication • Background & Objectives • Functional Summary • Technical Summary • Project Timeline • Customer Testing • User Documentation • General • Connectivity • Online FAQ’s • Technical Workgroup Meetings • Further Market Communication Sessions • Questions?

23. AGENDA Equities Trading System - Market Communication • Background & Objectives • Functional Summary • Technical Summary • Project Timeline • Customer Testing • User Documentation • General • Connectivity • Online FAQ’s • Technical Workgroup Meetings • Further Market Communication Sessions • Questions

24. JSE EQUITIES TRADING SYSTEMBackground & Objectives • The current technology and business agreements between the JSE Limited (‘the JSE’) and the London Stock Exchange (‘the LSE’) expire in May 2007. • The London Stock Exchange (‘the LSE’) is nearing completion of a four year technology roadmap strategy to deliver systems offering increased performance, scalability and reliability. • During 2005, the JSE Executive and Board agreed to retain the LSE as the preferred supplier for the Equities Trading Solution, based on their current track record of service delivery, reliability, robustness and functionality. • Negotiations are currently in progress to refine and extend these contracts. • Key technical and functional changes available in the new system will provide more functionality and flexibility. • The JSE therefore needs to align itself to the LSE TRM project and phases.

25. JSE EQUITIES TRADING SYSTEM Background & Objectives • The LSE Technology Roadmap (TRM) is being phased in 4 releases:-

26. JSE EQUITIES TRADING SYSTEM Benefits • Equities Trading System will be the same technology running InfoWiz today - a Microsoft .NET solution • Enhancements as a result of the new technology includes: • Performance • Reduce end-to-end latency • Increase message throughput and processing • Greater transparency • Scalability • Adding capacity seamlessly • Message throughput • Functionality • Multi-product hooks – multiple markets across multiple assets can be added later • Multi-Functional – support for integrated cash and derivatives trading can be added later • Global capability – Full multi time zone, multi currency • Open standards - able to support current interfaces as well as emerging standards

27. JSE EQUITIES TRADING SYSTEMBenefits • Enhancements as a result of the new technology includes: • Impact • Three common application interfaces unchanged (MC, SII, IRI) • Fixed-width message formats and BDGs unchanged • Availability • InfoWiz has proven that new technology is robust to continue an outstanding level of availability • Extensive Internal Testing to prove the solution • Active-Active, Active-Passive components across LSE data centers • Sub-second automated fail-over of service and components • Loss of a full site – Less than 5 second interruption of service, automatic recovery to just single site operation, market put into selected period rule state

28. AGENDA Equities Trading System - Market Communication • Background & Objectives • Functional Summary • Technical Summary • Project Timeline • Customer Testing • User Documentation • General • Connectivity • Online FAQ’s • Technical Workgroup Meetings • Further Market Communication Sessions • Questions

29. JSE EQUITIES TRADING SYSTEMFunctional Summary • Functionality Enhancements applicable to the JSE Market • Market Structure • Order Book Enhancements • Trade Reporting • Settlement Information • Broadcast Interface • Quote Book Enhancements (N/A to JSE market but included in JSE Guidance Notes for completeness)

30. Functional Summary contd.Enhanced Market Configuration • The new trading system builds upon the current structure to introduce Exchange and Market tiers. This enhances the ability to differentiate between multi-market, asset class and product: NEW Market Used to describe the geographical elements of a trading environment - its business calendar and time zone the Market is operating in. JSE Segment The Segment tier is used to define a set of Instruments that follow the same trading model, e.g. an electronic anonymous order-driven market. ZA01 Sector The Sector provides a more granular level that defines the group of Instruments within the Segment that follow the same trading schedule. J1H1 Instrument The lowest tier is used to describe the individual tradable instrument itself. AGL

31. 5OX- Period Rules for Mkt segment 5OX- Period Rules for Market Segment 5OB- Instrument in Market Segment 5IS- Instrument Trading Data 5MS- Member in Segment 5OK - Participant in Market Segment Market segment 5TY Trade Type for Segment Periods Market segment Periods 5TM Tick Size Matrix for Segment/ Currency Old System New System Segment contains: Participants Periods Instruments Segment contains: Members Instruments Trade types Tick sizes Functional Summary contd.Segment Population

32. Member ID The highest level Participant “entity”, intended to correspond to the existing Participant Code (BIC Code) ABC NEW Trader Group JSE default configuration for go-live is to assign the same Member ID to the Trader Group Code. Trader Groups will be disseminated on existing public messages as opposed to the Member ID. Trader Groups must be populated on the header of SII messages. ABC01 Trader ID Trader IDs will be validated on the new trading solution. Trader IDs must be submitted into the system via the header of secure interactive enter messages and will be returned on secure interactive acknowledgement messages. 54365 Functional Summary contd.New Participant Structure • The new trading system introduces an optional 2 tiers to the Participant hierarchy which support the identification of desks and/or individuals within a trading entity:

33. Functional Summary contd.Normal Market Size (NMS) • NMS - Normal Market Size (REDEFINED) • Normal Market Size will be the MiFID defined threshold used on an EU wide basis. For JSE market, field will be left blank. • SMS - Standard Market Size (NEW) • Standard Market Size is a new MiFID average order size threshold for firms conducting in-house business (internalisation). For JSE market, field will be left blank. • EMS - Exchange Market Size (NEW) • Exchange Market Size represents the value currently published as the NMS for JSE market. Used to validate the Order/Quote size. EMS replaces all multipliers and obligations associated with NMS and ensures publication of trades is in accordance with current practise. • PTS - Publication ThresholdSize (NEW) • Publication Threshold Size allows a separate figure to be used for setting the volume at which a Trade Report has its publication to the market delayed. Can have separate delay times for different multiples of the PTS (e.g. immediate publication, one hour or one day delay). Delay can be defined as being dependent on either volume and/or consideration. • EG. In the JSE market , OP trades are delayed for 24 hours (unless pre-released) if the value is greater than R500 000 and the volume is greater than 6 X NMS (on TRM this will be 6 X EMS, where 6 is captured as the PTS)

34. Functional Summary contd.Dynamic Tick Sizes • Dynamic tick sizes is new functionality available – however will not be implemented for Go live of the JSE market. • This provides a range of price levels for each Segment, each associated with a lower and upper band.  • When submitting an order, the price must be a multiple of the tick size allocated to the range it belongs to. If the price of an order does not match the tick size associated to that price level it will be rejected. • The JSE: • will continue to use the static Price Format Code of "W” (whole) • will continue with automated trading in whole cents only • Consider use of Dynamic Tick Sizes on an instrument by instrument basis for a future release

35. Functional Summary contd.Order book Enhancements - Order Handling • The new trading system supports four different order types to cover every Market NEW

36. Validity is categorised into 3 different types:- Execution based validity (‘Execute & Eliminate’ and ‘Fill or Kill’) Time based validity (Good Till Time - GTT & Good Till Cancelled - GTC) and Period based validity (introduces the concept of Parked Orders) Functional Summary contd.Order Book Enhancements - Validity Types NEW Period based validity types

37. The new AB version of the 5DS ‘Delete Single Order’ message will return a 5D2 ‘Acknowledge Order Delete’ message that identifies the size of the order that was removed (Remaining Order Size Before Deletion) Functional Summary contd. Order Book Enhancements - Order modification and deletion • Persistence of market orders – New system will automatically remove all unexecuted market orders prior to moving into continuous trading • Order modification – The Table shows the differences in the way private order codes and price/time priority are handled in the new system. Order modification

38. Functional Summary contd.Order Book Enhancements - Basket Messages • Optional functionality for the JSE market, can be implemented into trading front-ends as and when user solutions are ready. • New system supports the ability to enter multiple orders through the use of a single 5BO ‘Basket Instruction for Enter Order’ message. • Each individual order must belong in the same Segment (as Segment Code is identified in the message header). • Each order will be processed and acknowledged individually using 5E4 ‘Acknowledge Order Details’ message, and each provided with individual order codes. • It is possible to submit a basket modification using the 5BM ‘Basket Instruction for Modify Order’ message. This will be acknowledged with a 5M7 ‘Acknowledge Basket Instruction for Modify Order’ message. These will be treated as individual modifications to the orders specified.

39. Decommissioned Messages 5DT ‘Delete all orders for a Tradable Instrument/Currency’ message will no longer be supported by the new system. 5DA ‘Delete all orders for Participant in Sector’message will no longer be supported by the new system. Replacement Message 5DO ‘Delete all orders for Trader Group in Segment’ message enhances current functionality to offer the ability to extend the breadth of orders included in the request (from Sector to Segment), and to narrow the Participant wide impact down to an individual Trader Group. NOTE: Current single order delete functionality remains as is. Functional Summary contd.Order Book Enhancements - Mass order deletions

40. Eligible trade types for segment Currently restricting the range of trade types within a particular segment impacts all participants enabled in that segment eg: the NX trade type can not be used in JSE Segments (ZA01, ZA02, ZA03 and ZA04). Note applied currently in the JSE market – however an extension of functionality – the new system introduces a further restriction through the use of ‘role’ e.g. a Marker maker registered in the security being given sole use of the block trade type for this instrument. Price Validation Validation of the Price submitted for a Trade Report against a pre-determined tolerance around the previous closing price. If the price falls outside of this range it will be rejected. This validation is based on a multiplier; i.e. if the multiplier was 10 and closing price was 300 ZAC, the system will reject any price less than 30 ZAC (300/10) and any price greater than 3000 ZAC (300*10). The JSE will NOT implement this functionality from Go-live but will consider it for a future release. Functional Summary contd.Trade Reporting – Trade Type Validation

41. Currently you cannot link the public contra CT trade type to the original trade cancelled by a participant, as the CT is assigned a new trade code. In the new system, for an automatic trade (AT) the contra is handled differently and will allow specific identification (linking) of the erroneous trade. The new system will treat the contra as a status change to the original trade, specifying the original trade code. This will be accomplished through the publication of a ‘cancel trade report’ message, with a broadcast update action of D (DELETE) – rather than today, where a new ‘CT’ trade report is published with a broadcast update action of A (ADD). Functional Summary contd.Trade Reporting – Trade Cancellations

42. The current JSE Dual Sided Trade Reporting process will remain as is. The current JSE Single Sided Trade Reporting process remains as is, however the valid counterparty codes will change to “INTRAFIRM1” and “NON-MEMBER1”. Functional Summary contd.Trade Reporting – Dual-Sided Trade Reports

43. Settlement Account is a mandatory field on the new 5EO (Enter Order) messages and must be set to "S" for the JSE market Settlement venue must be left blank on the new 5EO (Enter Order) messages for the JSE market. It will be defaulted by the trading system to an agreed JSE value (JCP). Functional Summary contd.Settlement Information - Settlement Account and Venue The new system provides the ability to submit a Settlement Account and Venue on an Order record which can be used downstream for routing Settlement information to a specific settlement venue

44. Functional Summary contd.Broadcast Interface - Disaster Recovery • Today, in a disaster scenario, the 5RD ‘Disaster Recovery’ message is used to flag when messages should be processed regardless of whether the sequence number has been processed previously and the recovery process having been invoked. • The new system will ensure that all messages are synchronised with the alternative site, and guarantees that all re-sent messages will have the same sequence number. • This removes the requirement to flag those messages newly originating from the alternate site; therefore this message and process of recovering will be decommissioned. • In the event of a total site failure, the JSE may still opt to invoke a HALT period.

45. Functional Summary contd.Period Rules • The trading system currently allows a maximum of 3 auction extensions and these follow a strict sequence of combinations, which in turn are dependant on what extensions have already been triggered. • The new system functionality treats the method of extensions differently, with no such restrictions on the number of extensions and allowing these extensions to be triggered according to market conditions at the time • A Market Order extension will continue to take priority over Price Monitoring extensions. However, for markets that have a maximum of three extensions to an auction, a Market Order extension can now take place, even after two Price Monitoring extensions have occurred. • NOTE: Current JSE period extension rules will apply for go live, the JSE will re-visit the above for a future release.

46. AGENDA Equities Trading System - Market Communication • Background & Objectives • Functional Summary • Technical Summary • Project Timeline • Customer Testing • User Documentation • General • Connectivity • Online FAQ’s • Technical Workgroup Meetings • Further Market Communication Sessions • Questions

47. Technical SummaryMessage Impact Summary NOTES: DR – indicates BDG’s where the only change to the BDG, is the removal of the ‘DR’ message. (included in total counts) Messages included in more than 1 BDG have been included in totals for both BDG’s SII – totals include all messages counts, including Quotes and & Enhanced Dual Sided Trade Reports not implemented in the JSE market

48. Technical Summary contd.Interactive Services • Service Codes - Only certain messages and message versions are enabled for certain Service Codes. Current JSE service codes are T01 and T02. As part of TRM, the JSE will use T02, T03 and T04. T01 will be decommissioned for JSE users. • Unsolicited connection status - This field is included in the business header for all interactive messages sent from the Exchange to the Participant. This field indicates that the Participant has stopped acknowledging unsolicited messages and will therefore no longer receive them • Own Order Book Download (OOBD) - A new AB version of the 5RO ‘Request Order Download’, 5OF ‘First Order Download response’ and 5S1 ‘Subsequent Download Response’ messages that provide additional information not currently included with the AA version • Own trades book download (OTBD) - OTBD is a new service offering similar functionality to the current Own Order Book Download (OOBD). This provides a Trader Group the ability to request a download of their Trade book (automated and reported) The new systemincludes a number of enhancements identified during customer consultation in order to facilitate trading:

49. Technical Summary contd.High Level Impact Summary The current BDGs will remain unchanged with the exception that some messages will be decommissioned and new messages being introduced. Broadcast Data Groups Bandwidth Bandwidth allocation is reviewed on an ongoing basis but is not expected to increase specifically for the changes described in this document. IP Addresses The existing IP Addresses and Ports will be maintained for the production environment. New enablements and IP addresses will be used for the new testing services. Service Codes New Service Codes will be introduced for the Interactive and Secure Interactive Interfaces. Participant Code Participant Codes will be replaced with Member ID and Trader Group. However to minimise impact, these can both be set to reflect the current Participant Code. User Service Access Point Existing USAPs can continue to be used, although they may be changed during the migration, if required. The current method of authentication will be supported on the new system and all existing keys will remain valid for testing and production purposes. KEKs will remain associated with a specific USAP regardless of how many Trader Groups are configured. Key Encryption Keys (KEK’s) Interface Specification The existing Broadcast, Interactive and Secure Interactive interfaces will continue to be used. No additional interfaces are being introduced.

50. Message Specification The underlying specification is unchanged from today. New message protocols such as FIX may be introduced in addition to the current specification at a later stage. All existing headers will continue in their current format. A number of reserved fields are being used but will not impact the size of the header message. Message Headers Message Types & Versions Many of the existing messages will continue to be used. A number of new message types and versions are being introduced, and some are being decommissioned. Field Descriptions New fields are being introduced for new and existing messages and some existing fields are being renamed with new descriptions defined. Advisory Codes New session and application advisory codes are being introduced; existing codes may be used in a different context to today and may be received in a different order. Segment Codes No changes or new Segments for the JSE market. Sector Codes No changes or new Sectors for the JSE market. Period Names New Period Names and Codes will be introduced in addition to existing Periods, with some periods being deleted. Technical Summary contd.High Level Impact Summary