How To Create A Futures Trading System

Transcription

1 Futures Trading Requirements John Freed This document contains the business requirements for enhancing our equity trading system to allow futures trading. The first phase of this project will allow us to trade on the CME and ICE. Other exchanges will be added in later phases. ASJ International, Inc. November 10, 2012

2 Copyright 2012 ASJ International, Inc. ASJ International, Inc. 32 Bergen Ridge Rd., Suite 1 North Bergen, NJ ASJ@asjinternational.com Futures Trading BRD 11/19/2012 Page 2 of 47

3 Contents 1 Executive Summary: Project Scope: In Scope: Out of Scope: System SLAs: Required Changes to Existing Systems: Required Trading System Changes: Client Order Handler Changes: Required Exchange Connectivity Layer Changes: Booking Trades: Regulatory Changes: Order Validation: Symbology: Price Validation: Risk Validation: Lot and Tick Size: Account Validation: Login ID: Order and Execution Handling: GTC Handling: Other Order Handling Issues: Spread Execution Handling: Exception Cases: Client Onboarding: Non-functional Requirements: System Audit Requirements: System Control Requirements Failover Batch Processing Disaster Recovery High Availability Futures Trading BRD 11/19/2012 Page 3 of 47

4 11.6 Local Storage Management Performance and Requirements System Capacity System Latency System Scalability Information Security Requirements Authorisation and Access Control Audit Logging and Alerts Regulatory, Audit and Data Retention Requirements Documentation Requirements Production Support: Appendix 1 - Open Issues: Appendix 2 Spread Trading Issues: Appendix 3 FIX Message Differences Between Exchanges: Appendix 4 Exchanges we will Eventually Connect to: Appendix 5 Areas the CFTC will Create New Regulations in: Appendix 6 Exchange Symbol Formation: Appendix 7 Tick Size: Appendix 8 Price Factors: Appendix 9 Order Type and Time in Force (TIF) Tags by Exchange: Appendix 10 Later Phases Appendix 11 FIX Messages: New Order - Single Order Cancel Request Order Cancel Replace Request Don t Know Trade Order Cancel Reject Execution Report Futures Trading BRD 11/19/2012 Page 4 of 47

5 1 Executive Summary: The goal of this project is enable our firm to trade futures electronically. In the first release, we will focus on trading on the Chicago Mercantile Exchange (CME) and the Intercontinental Exchange (ICE). The requirements of recent regulatory changes will also need to be included in the project as those changes are finalized. The key phase-1 requirements of the project are: 1) Support Outrights (single leg products) in the first phase 2) Calendar Spreads will be supported in the second phase 3) The system must be available when our clients need it and must not have significant down time The project will require changes to our existing online trading system to allow it to handle Futures derivative products (currently it handles cash equities only). Additionally, our Direct Market Access handler (which accepts client orders to be forwarded to the exchanges) will need to be enhanced to validate orders and verify risk limits have not been violated for futures trading. 2 Project Scope: 2.1 In Scope: The following tasks need to be done in phase one: 1) Make available products trading on GLOBEX, including KCBT, CME, CBOT, NYMEX and COMEX contracts 2) It is required that outrights (single leg trades) and calendar spreads be available for trading. Single leg orders will be handled in phase one and calendar spreads will be handled in phase 2 3) Our Security Master System will deliver product information on spreads in time for this project to include spreads in the second release 4) Perform symbol validation 5) Create Risk Validations as described in this BRD 6) Non-functional requirements as described in this BRD must be complied with 2.2 Out of Scope: The following tasks are out of scope in release one: 1) Single stock futures 2) VIX futures 3) All exchanges other than the CME and ICE 4) Algorithmic trading strategies 5) Allocation Handling 6) Price factor validation Futures Trading BRD 11/19/2012 Page 5 of 47

6 3 System SLAs: The futures trading system will be brought down at 6:30 pm ET and brought back up at 4:00 am ET in Phase 1. The FIX sequence numbers need to be reset every weekday after 6:30 pm ET for ICE. They should be reset once a week (every Fri) after 6:30 pm ET for CME. Production support needs to start at 3:00 am each day (to account for the security master initialization). We anticipate initial volumes to be about: 1) An average of 3,500 orders per day for CME 2) 400 order per day for ICE 3) 7,000 executions per day for CME 4) 1,000 executions per day for ICE 5) Burst rates are 200 orders per second for CME and 300 orders per second for ICE. This is the most the exchanges will allow. 4 Required Changes to Existing Systems: The goal is to send orders from external clients and from our proprietary trading systems to the CME and ICE exchanges in Phase 1. Therefore the external client order handlers will need to be enhanced, as will the proprietary trading systems. Futures Trading BRD 11/19/2012 Page 6 of 47

7 DMA Client System Flow (High-Level) Security Master Client Order Handler Data Warehouse Connectivity Layer ICE CME 4. 1 Required Trading System Changes: The development team believes that changes will need to be made to the following components: a) Order Router b) Order Handler c) Execution Handler d) Fix Tag Database e) Transaction Database f) Application Database g) Administrative Application Futures Trading BRD 11/19/2012 Page 7 of 47

8 EOD statistics (volume and latency) should include futures data. When ASJ International Trading loses connectivity to an exchange, the system must reject any incoming orders for that exchange. 4.2 Client Order Handler Changes: The following changes are needed: 1) Client order handlers must be updated to get futures data from the security master system for order validation. 2) For spread orders, the order handlers will return all executions to the client s system. This means that we will need to handle three or more execution reports per spread execution (the Summary execution and two or more leg executions); this is a phase 2 requirement 3) Cfore will always send symbols in the Exchange symbology. 4) The risk validation checks detailed in this BRD will be done by the order handlers 4.3 Required Exchange Connectivity Layer Changes: The exchange connectivity layer must be modified to route orders to the CME and ICE. 5 Booking Trades: 1) Derivative trades currently flow into Clearvision and GMI. Clearvision is a system that matches executions and allocations. GMI is the books and records of the firm. 2) Drop copy contact at the CME is: CME Globex Account Management, (U. S.); (Europe) and (Asia) 3) The back office operations department is responsible for fully defining the booking process 4) The back office system will need to handle Average Price and Give Up notices from the exchanges 6 Regulatory Changes: We must be aware of new regulatory changes that are expected soon and make sure that we comply with them as well. Compliance must keep us informed of these changes Data must be retained for seven years. The data warehouse will be responsible for this Data must be sent to the futures data warehouse so that Compliance Department can conduct proper surveillance. Futures Trading BRD 11/19/2012 Page 8 of 47

9 7 Order Validation: Each system that is sending orders to the exchange connectivity layer must perform the validations listed in the next few subsections (7.1 through 7.6). 7.1 Symbology: ASJ International s trading system must route orders to exchanges using exchange symbol only. The order handlers will always send exchange symbols to the exchange connectivity layer. Hence the connectivity layer will not need to do any symbology conversion in Phase 1. Each order handler needs to be able to look up certain information about the product being traded, so there will need to be a record in the security master system for each outright contract listed on futures exchanges globally (this is already in place). There must also be a record in the security master for each spread that can be traded (this needs to be done for phase 2). The following information from the security master system must be received for outrights and spreads: a) Tick Size (numeric: 15,8 characters) b) Reuters, Bloomberg and Reuters Symbol c) A descriptive symbol name (Up to 20 characters) d) Contract Size / Multiplier e) Test Symbol Flag f) Exchange traded on g) ICE product ID (ICE expects a product ID to be sent, not the actual symbol) the security master currently cannot provide this, but it is a requirement h) Decimal Locator / Price Factor (for CME products) The security master cannot provide the following data: a) Lot Size (not needed for Futures as it is always 1) b) Trading Times of each contract not needed c) Local identifiers (CUSIP, ISIN, etc.) not needed in Phase 1 d) Local currency (trading currency) not needed in Phase 1 e) Total Volume for the prior business day is not needed The security master will send a flat file with the product data to our trading system every morning (as early as 3 am ET) and we will load product data from the flat file into its own look up table (when the system is down) and use it for the trading day. If the flat file does not arrive on any given day, the prior business day s data will be used. The Futures Trading BRD 11/19/2012 Page 9 of 47

10 approximate size of the daily flat file will be 10 MB (100,000 records of 100 characters each). The internal look up table will be truncated after it is confirmed that the new data is available and in the correct format. This will ensure that previous day s data is available in case of a failure scenario. Also data can be loaded into primary and backup security master tables. EMEA uses the same approach for loading the Security Master. Note that expired products are not deleted from the security master database, so over time our product download will become much larger and slower. To avoid this problem, we need to tell our call to the product API to select only those records where the Operational Indicator is equal to Y. This will cause only the products that are still trading to be downloaded (expired contracts will be ignored). Also note that a product that has expired will not have its Operational Indicator set to N for about 10 business days after the expiration. This means that we will download expired contracts each day for a couple of weeks after expiration. Product data lookup will be used, in part, to determine where the order will be routed. We will not try to smart route to several exchanges since almost every future is listed on only a single exchange. One exception to this is Eurodollar futures, which are fungible on the CME and on Singapore. This product will be routed only to the CME however. Note that downloading the ICE Product File daily and putting the Product Code in the cache will obtain the ICE Product Code. To do this, we must send a Product Definition Request FIX message to ICE. Here is a sample Product Definition Request and the response from ICE: SecurityDefintionRequest 8=FIX.4.2^A9=71^A35=c^A49=807^A56=ICE^A52= :27:57^A34=9^A320=1^A321=3^A48=29^A167=FUT^A10=155^A SecurityDefintionResponse 8=FIX.4.2^A9=1040^A35=d^A49=ICE^A34=9^A52= :37:58.051^A56=807^A57=16^A322=1^A323=4^A320=1^A15=USD^A393=4^A82=1^A67=1^A 146=4^A311=126106^A309=CR FMZ0010!^A305=8^A307=RJ/CRB Index Futures - NYCC - Dec10^A313=201012^A314=10^A9013=0.1^A9014=1.0^A9017=50^A326=17^A9083=2^A9084= 0^A9061=1198^A9030=1^A9031=1^A9032=0.1^A9091=RJ/CRB Index^A9092=1^A9093=0^A9094=1.0^A9095=Futures^A311=126122^A309=CI FMF0011!^A305 =8^A307=CCI Index Futures - NYCC - Jan11^A313=201101^A314=14^A9013=0.05^A9014=1.0^A9017=500^A326=17^A9083=2^A9084 =0^A9061=1196^A9030=1^A9031=1^A9032=0.05^A9091=CCI Index^A9092=1^A9093=0^A9094=1.0^A9095=Futures^A311=126121^A309=CR FMH0011- CR FMZ0010^A305=8^A307=RJ/CRB Index Spr - NYCC - Dec10/Mar11^A313=201012^A314=10^A9013=0.1^A9014=1.0^A9017=50^A326=17^A9083=2^ A9084=0^A9061=1199^A9030=1^A9031=1^A9032=0.1^A9091=RJ/CRB Index^A9092=1^A9093=0^A9094=1.0^A9095=Spreads^A9004=126118^A9005=126106^A311= ^A309=CR FMH0011!^A305=8^A307=RJ/CRB Index Futures - NYCC - Mar11^A313=201103^A314=11^A9013=0.1^A9014=1.0^A9017=50^A326=17^A9083=2^A9084= Futures Trading BRD 11/19/2012 Page 10 of 47

11 0^A9061=1198^A9030=1^A9031=1^A9032=0.1^A9091=RJ/CRB Index^A9092=1^A9093=0^A9094=1.0^A9095=Futures^A10=218^A 7.2 Price Validation: In the first release we will not check the reasonability of the entered price (other than verifying the price factor see below in this section). So if the S&P 500 is trading at and the client enters a buy order with a limit of , ASJ will send the order to GLOBEX. In this case, the order will be rejected by GLOBEX because it is outside the no-bust range for the contract. This means that we are relying on GLOBEX to check the reasonability of the limit price on any order submitted to the exchange. The CME, by convention, does not use decimal points in order prices for certain products. So an order for S&P E-Minis with a limit price of would be sent to the exchange as If the order is sent with the decimal it will be rejected by GLOBEX. However, Eurodollar futures do require the decimal point. So if an order is entered for Eurodollars at a limit of 99.60, the decimal point must be present (a price of 9960 would be rejected). The security master team can obtain specifics on which products require the decimal point from the CME s product file, which can be downloaded via FTP daily. Each product record sent from the CME has a field called Decimal Locator that tells where the decimal point must be placed (if one is required). We must enter the decimal point on any order that is to be sent to ICE. 7.3 Risk Validation: Risk limits are defined by the futures business. If we determine that an order violates a risk validation, the order will be rejected. 1) A client might want to give us a total daily position above which no more orders can be accepted. This check will work as follows: a) A running total will be kept by account and product group. By product group we mean (for example) all contracts listed for the S&P 500 E-Mini (ES). We would not keep totals by individual contract (ESZ3, ESM3, etc.). b) Quantities in net long products will be increased by the quantity on a buy order (even if that quantity has not been executed). The quantity of a net short product will be increased when a sell order is received. The quantity of a net long position will be reduced when sell execution or a confirmed buy order cancellation is received. The quantity of a net short position will be reduced when a buy execution or a confirmed sell order cancellation are received. c) Position limits should be reset at 5:00 p.m. (NY time) currently, but we will need to revisit this when EMEA and APAC exchanges are brought online. 2) A client may want to give us a limit to the number of contracts that can be sent on an outright order. No limit will be given to us for spreads in the first release. Futures Trading BRD 11/19/2012 Page 11 of 47

12 The exchange also does certain risk validations for us automatically: 1) Prices are banded such that if an order is entered for a price more than a certain amount above or below yesterday s last sale, the order will be rejected by the exchange. 2) If a product is trading limit up or limit down the exchange will reject orders that would violate the limit up / down price (a buy order higher than the limit up price or a sell order below the limit down price) 3) The CME also has a protection set up, which keeps market orders from getting an extremely bad fill. For example, if a trade sends a market buy order for a product that has 600 points of protection, the order will take all sell limit orders from the GLOBEX book until the price moves up 600 points. The remaining balance of the buy order will then be entered on the order book as a buy limit at the highest price allowed by the protection 7.4 Lot and Tick Size: The lot size on all futures contracts on all futures exchanges globally is one. This means that there are no odd-lot issues to contend with. See Appendix 7 for information on tick size. 7.5 Account Validation: We will not do account validation. ASJ will send the account to the exchange and they will reject the order if the account is invalid. Accounts need to be set up at the exchange before orders can be entered for the account. The middle office support team will handle this. 7.6 Login ID: Each order must have the login ID of the person who entered the order into the system. This is mandated by the CME since some of the volume discounts they give us on exchange fees are based on login ID. The trading system should pass the login ID to the exchange and allow them to reject the order if the login is invalid. ICE requires static values per FIX session (FIX tags 115, 116 and 144). We will store proper values and populate the required tags on each order going to ICE. Futures Trading BRD 11/19/2012 Page 12 of 47

13 8 Order and Execution Handling: 8.1 GTC Handling: The system will need to cancel GTC orders when the underlying future expires: From the CME we will receive a FIX Message with tag 35 = 8 (Execution Report) and Tag 150 and Tag 39 = C (Order Expired). The order handlers will need to notify the person who entered the order of the cancelation. From ICE we will receive a cancellation of the GTC order with tag 39 populated with a Other Order Handling Issues: If we lose connectivity to an exchange, ASJ will reject incoming orders. When we lose connectivity with the exchanges the default behavior of the exchange is: 1) ICE Cancel on Disconnect for day orders (GTCs left in place) 2) CME do NOT cancel day orders on disconnect. We can have the CME configure us to cancel the day orders on a disconnect. Outs will flow to us from the exchange when ASJ re-connects. If the loss of connectivity will be for a lengthy period of time (such that we cannot receive executions, etc. via the FIX connection) or for ICE if the down time is over 30 minutes, production support will need to get a file of executions, cancellations, etc. from the exchange and send them to the client. Different futures end their trading session at different times, even on the same exchange. No orders will be rejected based on the closing time of any given product. Orders will be routed to the order to the exchange and the exchange can reject the order if it is entered outside of the product s trading hours. The CME has a quirk in their New Order Single message that we need to handle. They want the actual symbol being traded (ESZ3 for instance) in tag #107. In tag #55 they want the product group ( ES in this case). For spread orders it works the same, they require the full symbol in tag #107 ( ESH1 M1 for instance) and the product group ( ES ) in tag # Spread Execution Handling: In theory, we will receive three execution reports back for a spread trade, a summary report for the spread and one report for each leg. Futures Trading BRD 11/19/2012 Page 13 of 47

14 For instance, suppose we have the following situation: 1) We submitted a spread order to buy the ESM3-ESU3 spread (sell the June S&P 500 E-Mini and buy the September S&P 500 E-Mini) 2) The spread was executed with a $12.05 price differential 3) SPM3 closed yesterday at ) The spread was executed at a time when the ESM3 contract was at ) The ESU3 contract had just traded at 1245 at the time the spread was executed. In actual practice, things can be far more complicated. Here are some possible scenarios: 1) 10 Lot Order a) Summary for 10 lots price 10 b) Sell leg for 10 lots price 100 c) Buy leg for 8 lots price of 110 d) Buy leg for 2 lots price of 110 Create a new execution by combining legs C and D. Send the new leg to the client. Store legs C and D in database for future reference, if ever required 2) 10 Lot Order a) Summary for 10 lots price 10 b) Sell leg for 8 lots price 100 c) Sell leg for 2 lots price 100 d) Buy leg for 10 lots price 110 Create a new execution by combining legs C and B. Send the new leg to the client. Store legs C and B in database for future reference, if ever required 3) 12 Lot Order a) Summary for 10 lots price 10 b) Sell leg for 8 lots price 100 c) Sell leg for 2 lots price 100 d) Buy leg for 10 lots price 110 e) Summary for 2 lots price 10 f) Sell leg for 2 lots price 100 g) Buy leg for 1 lot price 110 h) Buy leg for 1 lot price 110 Match first summary by combining legs B and C. Send first summary, leg D and combination of legs B and C. Save legs B and C in database. Now match the second summary by combining legs G and H. Send second summary, leg F and combination of legs G and H. Save legs G and H to the database 4) 20 Lot Order a) Summary for 20 lots price 10 b) Buy leg for 10 lots price 110 Futures Trading BRD 11/19/2012 Page 14 of 47

15 c) Buy leg for 10 lots price 110 d) Sell leg for 15 lots price 100 e) Sell leg for 5 lots price 100 Combine legs B and C to create a new buy execution. Combine legs D and E to create a new sell execution. Send the summary and the two new (combined) executions. Save legs B, C, D and E to the database 5) 7 Lot Order a) Summary for 2 lots price 10 b) Summary for 5 lots price 10 c) Buy leg for 7 lots price 110 d) Sell leg for 2 lots price 100 e) Sell leg for 5 lots price 110 Match summary A by splitting leg C into two executions (one for 2 lots and one for 5 lots). Send summary A, leg D and the 2 lot split off from leg C. Then send summary B, leg E and the 5 lot split off from leg C. As usual, save the original legs in the database 6) 6 Lot Order a) Summary for 1 lot price 10 b) Summary for 2 lot price 10 c) Summary for 3 lot price 10 d) Sell leg for 6 lots price 100 e) Buy leg for 1 lot price 110 f) Buy leg for 2 lots price 110 g) Buy leg for 3 lots price 110 Handle the same as #6, but split leg D into three separate sexecutions. 7) 173 Lot Order a) Summary for 143 lots price 10 b) Buy leg for 143 lots price 110 c) Summary for 30 lots price 10 d) Sell leg for 143 lots price 100 e) Sell leg for 30 lots price 100 f) Buy leg for 10 lots price 110 g) Buy leg for 10 lots price 110 h) Buy leg for 10 lots price 110 Send summary A, leg B and leg D. Then combine legs F, G and H and match the combined buy legs with summary C and leg E. 8) 50 Lot Order a) Summary for 50 lots price 10 b) Buy leg for 10 lots price 110 c) Buy leg for 40 lots price 110 d) Sell leg for 15 lots price 101 e) Sell leg for 35 lots price 100 Futures Trading BRD 11/19/2012 Page 15 of 47

16 These legs cannot be matched because the price of leg D does not allow the buy and sell legs to net to 10 (the summary price). We will send all of these legs to the client after 30 seconds. These legs then need to be resolved manually by contacting the exchange. Note that the execution price of the two legs has no relationship whatsoever with the actual last sale of the futures contracts that make up the spread. The CME does not report prices based on the last sale of the individual legs. Instead they report: 1) The difference in price between the contract bought and the contract sold (in this case the $12.05 on the spread execution report). This is the price that the client actually cares about. 2) The ESM3 leg is reported with an execution price equal to yesterday s close of the S&P 500 future with the same expiration month as the mini future we are trading (1246 in this case). 3) The ESU3 leg is shown with an execution price that is equal to yesterday s close (1246) plus the differential price on the spread report ($12.05). This means (in this case) that the ESU0 leg will have an execution price of a contract. It is important to note again, that the execution prices on the leg reports are completely artificial and bear no relationship at all to where the contracts are trading at the time the spread is executed. 9 Exception Cases: The following exception conditions need to be handled: 1) In the event that a future is limit up, any buy orders entered above the limit will be rejected by GLOBEX. There is no reason to code for this, so we will allow the exchange systems to handle this. 2) In the event that a future is limit down, any sell orders entered below the limit will be rejected by GLOBEX. There is no reason to code for this, so we will allow the exchange systems to handle this. 3) If a client DKs a futures trade it should be relayed to the trader supporting the flow. 4) We will handle error conditions (rejections by the exchange, symbol validation failures, etc.) by returning a rejection message back to the order originator. 10 Client Onboarding: There are a number of requirements for client onboarding. The technical and business support will be handled by the back office support team. 1) All of the client s accounts need to be registered on any futures exchange they will trade on. The futures business will handle this. Futures Trading BRD 11/19/2012 Page 16 of 47

17 2) The client may need to be registered with the CFTC or other regulatory body. They may also need special registration as an FCM. This will be handled by the futures business. 3) Clients need to be notified what will happen to their day orders if we lose connectivity to a given exchange and they must agree to this. We cannot handle this differently for each client as the exchanges cancel (or do not cancel) on a firm wide basis. The back office support team will handle this. 4) Risk limits (position limits, order size limits, etc.) need to be agreed upon with the client and set-up within the system. This will be done by the futures business. 5) A client must inform us if they are sending prices with or without decimals (Price Factors). The futures business should provide us with this information 11 Non- functional Requirements: The following non-functional items will also need to be done as a part of the project 11.1 System Audit Requirements: The system will log all events in a clear, consistent and standard format. Error messages must clearly state the cause, and if possible, related processes. Messages will include date, time, application name, component name and severity. Events to be logged include but are not limited to: (a) Software and hardware related incidents (b) Failed dependencies (c) Failover attempts (d) Recovery attempts (e) Start up commencement and completion (f) Shutdown commencement and completion (g) Commencement of start of day (SOD)/end of day (EOD) processing (h) Completion of SOD/EOD processing, with the appropriate return code and message indicating success or failure of each individual component Net IQ will be used for server side checking of the system System Control Requirements The system will be brought up and down using Windows scheduler. Additionally, the system will provide control points that include but are not limited to: (a) System health check. (b) Current system status verification (e.g. running, recovering, stopping, starting) of each system component. (c) Start up and shutdown Individual components will start and stop independently and alerts will be generated when there are missing dependencies. The specific order in which components are to be started or shutdown will be documented in an operations manual. Futures Trading BRD 11/19/2012 Page 17 of 47

18 (d) All individual components are responsible for synchronising with respect to other internal components and external systems. (e) Failover and fail-back (recovery) In addition to automated mechanisms, failover and recovery processes may be triggered manually. The System Management Component will handle these operations Failover For purposes of monitoring, the system will use our existing SMA/Admin App model, as it is a mature model with a lot of functionality. This provides for monitoring of health of all applications, monitoring of log messages, and admin requests. It provides a heartbeat mechanism to each application, and because it is a TCP connection, it has the advantage that on a hard failure of an application, the monitoring tool will immediately know that the application is down as opposed to having to wait for heartbeat loss. Production Support will use the existing Admin App and Admin Request functionality for handling failover operations. Initiating failover, including the selection of the specific Backup process to be promoted, should be made as seamless and automated as possible for the Support team. During process failover, the Backup changes its role to Recovering. While in this state, it must suspend normal activity and buffer incoming messages while recovery caches are examined and processed. Once it has resumed processing incoming messages normally, its status becomes Primary. Note that what processing is actually done during the recovery period will vary based on application and the details will be provided for each component in its recovery section Batch Processing Any SOD/EOD batch processing must be integrated with checkpoints or another method for allowing re-start of individual failed components. Ensure that the batch cycle is in place (cleanup jobs, backup jobs for data archival, etc.) 11.4 Disaster Recovery There should be support for the reactivation of the system at the Disaster Recovery site after a catastrophic event at the primary production site. Technology Recovery Time Objective (TRTO) is less than 4 hours. Futures Trading BRD 11/19/2012 Page 18 of 47

19 11.5 High Availability For purposes of monitoring, ASJ will use our existing SMA/Admin App model, as it is a mature model with a lot of functionality. This provides for monitoring of health of all applications, monitoring of log messages, and admin requests. It provides a heartbeat mechanism to each application, and because it is a TCP connection, it has the advantage that on a hard failure of an application, the monitoring tool will immediately know that the application is down as opposed to having to wait for heartbeat loss. Production Support will use the existing Admin App and Admin Request functionality for handling failover operations. Initiating failover, including the selection of the specific Backup process to be promoted, should be made as seamless and automated as possible for the Support team. During process failover, the Backup changes its role to Recovering. While in this state, it must suspend normal activity and buffer incoming messages while recovery caches are examined and processed. Once it has resumed processing incoming messages normally, its status becomes Primary. Note that what processing is actually done during the recovery period will vary based on application and the details will be provided for each component in its recovery section Local Storage Management The system will support automated management of local log files and temporary state files. This will take into consideration the following requirements: Maintenance of recent log files that are no older than a configurable interval. Automated purge of log files that are older than a configurable interval. Purging intervals should be cognisant of the prevailing file backup regime to ensure statutory data retention periods are respected. File system usage needs to be integrated into normal system processing Performance and Requirements System Capacity The following indicative capacities are projected for 2010: Order Handling Number of client connections: 150 Average message rate: 20/sec upstream and 20/sec downstream Maximum number of simultaneous open orders: 10,000 An average of 3,500 orders per day for CME 400 order per day for ICE 7,000 executions per day for CME 1,000 executions per day for ICE Futures Trading BRD 11/19/2012 Page 19 of 47

20 Burst rates are 200 orders per second for CME and 300 orders per second for ICE Market Data Instruments: 27,000 (including about 1,600 equities) Message burst rate: 6,000 messages/second for 5 seconds Average message rate: 200 messages/second Peak aggregate daily message load: 50,000,000 Typical aggregate daily message load: 8,000,000 It is likely that the order handling loads described above would be split across two deployments the co-location deployment and the regular deployment at our premises. The co-location deployment might transact around 50% of the stated load, but achieve this servicing only a very small number of connections. Market data loads would need to be handled by both deployments. Ideally, the requirements stated herein would provide projections out to at least 12 months beyond the expected go-live date in mid Unfortunately, this period coincides with the anticipated market reforms that are expected to have profound impacts on transaction and market data loads. Due to this uncertainty, no longer-term projections have been furnished System Latency The system shall meet the following latency constraints: Order Handling 50 th percentile latency through system on path to and from trading venue 1 : < 1.0 millisecond 90 th percentile latency through system on path to and from trading venue 2 : < 1.1 millisecond 95 th percentile latency through system on path to and from trading venue 3 : < 1.5 millisecond Worst case latency through system on path to and from trading venue 4 : 2 milliseconds These numbers are internal latency numbers and are NOT round trip (to the exchange and back) numbers. 1 This is the aggregate elapsed time within the Lava platform (From OR to XH and vice versa) for processing a new order message and the corresponding order acknowledgement from the exchange. It does not include the time on the wire to/from the exchange nor the processing time at the exchange. 2 Measured as defined above. 3 Measured as defined above. 4 Measured as defined above. Futures Trading BRD 11/19/2012 Page 20 of 47

21 Market Data 95 th percentile latency for an order book change received from the trading venue to be available to the system 5 : < 2 milliseconds 11.9 System Scalability Scalability will follow the standard system procedures. Here s an extract from the relevant documentation: The ASJ International trading system architecture consists of the following three tiers: The first tier is the client connectivity tier and consists of external clients connecting to the Client Order Routers and Drop Copy providers. This tier is organized by client. The second tier is the order-processing tier and consists of Order Handlers and Database Writers. This tier is organized by symbol to distribute processing of market data, the most intensive input into the system. The third tier is the venue tier and consists of Execution Handlers, the Smart Server, CME and ICE. This tier is organized by venue. The following table shows how the system will scale to address growth in various areas: Scenario Increase in number of customers / users Increase in order traffic from customers Increase in order traffic to and from a venue Increase in market data Scalability Solution Deploy additional Order Routers Deploy additional LTF Application Servers if needed for front-end users Deploy additional Order Router / Order Handler server groups If necessary, work with customers to split order flow across multiple inbound FIX sessions Create a dedicated Execution Handler instance for each Order Router / Order Handler server group Increase the number of Order Handlers in a server group to allow for further partitioning of market data Various processes/sub-processes will require partitioning information: The OrderRouter2 process needs it to determine which channel to use to send an order to an Order Handler. The ExecHandler2 framework needs it to determine which channel to use to send a GTC execution to an Order Handler. The CME / ICE ExecHandler2 processes need it to determine which channel to use to send an order to CME / ICE. Probably many other entities need partitioning information. 5 This is the elapsed time taken for an order book change to be received by the system from the relevant market data feed handler until the data is available to the system compliance functions. Futures Trading BRD 11/19/2012 Page 21 of 47

22 Partitioning information will be available in the ApplicationDB for these entities. This partitioning information will be updated as needed, prior to the system s processes starting in the morning Information Security Requirements Authorisation and Access Control All user interfaces will be protected from unauthorised access through appropriate security mechanisms. The system will implement access controls that ensure that users are only granted those privileges and entitlements necessary to perform their function Audit Logging and Alerts User interfaces should log all non-read only actions taken by the user to a secure audit trail. Each entry should identify the date, time, SOE user id and details of the operation performed Regulatory, Audit and Data Retention Requirements Regulatory Requirements The system must abide by all regulatory requirements stipulated by the CFTC initially. It will need to comply with other regulatory body requirements as we roll out new changes. It will be the responsibility of the Compliance Department to inform us of any new regulations that ASJ needs to comply with. They will also be required to sign off on the changes after they are made. Audit Requirements Retained logs must have a complete date/time-stamped record of all transactions with upstream clients and the corresponding messages on downstream exchange interfaces. Information must be fed to the futures data warehouse. We will keep this information be kept in the data warehouse team for seven years. The data warehouse team will be required to prepare all reports required by Compliance or any other internal department. Per CFTC rule 27.12A the following data points must be kept for each order: 1) Date and time of order entry (to at least one one-hundredth of a second) 2) Date and time of order receipt (to at least one one-hundredth of a second) 3) Date and time of order modifications and cancellations (to at least one onehundredth of a second) 4) Contract (exchange root symbol) Futures Trading BRD 11/19/2012 Page 22 of 47

23 5) Expiration Month 6) Buy / Sell indicator 7) Futures or option indicator 8) Put / call designation for options 9) Quantity 10) Reserve quantity (if applicable) 11) Order Type 12) Price 13) Stop Price (if applicable) 14) Strike Price (if option) 15) Time-in-force 16) Clearing Member ID 17) Account Number 18) Customer Type Indicator 19) Login ID 20) Authorized trader tags (tags 115 On behalf of comp ID, 116 On behalf of Sub ID and 144 On behalf of location ID) 21) Client Order Identification 22) Exchange Order Identification 23) Order Status Data Retention Requirements All trading message logs must be retained for a minimum of 7 years by the data warehouse team Documentation Requirements A run book will be provided for the system. This run book will be in the format of the standard system run book and will include at least the following information: (a) Installation and configuration guide (b) Operator procedure guide Daily maintenance tasks Start up and shutdown procedures Data integrity verification procedures Health check and consistency verification procedures Detailed incident recovery procedures for all applicable components Data and system configuration to be backed up (c) Administrator procedure guide Detailed architecture and component description Detailed description of command line and graphical user interfaces Troubleshooting procedures Start up and shutdown Individual components will start and stop independently and alerts will be generated when there are missing Futures Trading BRD 11/19/2012 Page 23 of 47

24 dependencies. The specific order in which components are to be started or shutdown will be documented in an operations manual. Scalability guide Production Support: The Technology Support Team will be responsible for production support. Production support needs to start at 4:00 a. m. each day. Appendix 1 - Open Issues: 1) We may need to register ourselves as an FCM with the regulators. Compliance will make this decision 3) ICE product ID (ICE expects a product ID to be sent, not the actual symbol) SMC currently cannot provide this, but it is a requirement. The Security Master Team will have to obtain the data and send it to us 4) Trade booking process needs to be determined. Back-office management is to provide this information 5) The interface to the futures data warehouse must be defined and it must be determined how information will be sent to the data warehouse. Does the interface need to be real-time or can it be batch? Back-office management is to provide this information 6) We can build and manage a custom holiday calendar for the CME and ICE. The system can either use it or not use a holiday calendar at all (and let exchanges reject orders on holidays if they are up, or CB2 connection to terminate after a time out if applicable). Which is the right way to go? Appendix 2 Spread Trading Issues: Spread trading consists of buying one future and selling another. But there are wrinkles to this not only by exchange, but also by product within each exchange. For instance, the CME lists the following Calendar Spreads: Buy / Sell Spread Type Product Group Contract Contract Sold Spread Bought Buy SP All Products Buy Near Sell Far Buy FX FX Buy Near Sell Far Buy EQ Equities Sell Near Buy Far Note that buying the EQ spread results in selling the near month and buying the far month, while the SP and FX calendar spreads result in the opposite (buy the near month and sell the far month). Futures Trading BRD 11/19/2012 Page 24 of 47

25 A larger problem with spread trading is product data. Spread symbols are not in the security master system. This will be resolved by downloading the CME and ICE product data daily. Appendix 3 FIX Message Differences Between Exchanges: There are a number of differences between the ICE and CME exchanges in so far as their FIX messages are concerned. The list below is not exhaustive, but is meant to illustrate some of the issues: Tag Tag Name ICE CME 40 Order Type No support for the Market Limit order type 59 Time in Force Does not support Good Until Date Orders 59 Time in Force Supports Fill or Kill orders Supports Market Limit order type Supports Good until Date Orders Fill or Kill orders are entered by setting the Time in Force tag to 3 (IOC) and setting tag 110 (Minimum Qty) equal to Order Quantity 9208 CTI Code Required Field CME uses Tag 9702 for this information 9708 CMTA Give Up Code Not used Can be used to indicate that this order is fungible against a Singapore contract (Eurodollars) Appendix 4 Exchanges we will Eventually Connect to: Exchange LIFFE EUREX Futures Trading BRD 11/19/2012 Page 25 of 47

26 Sydney Futures Exchange (Australian Stock Exchange) MEFF (Spain) Singapore Montreal Amsterdam (Euronext) Paris (Euronext) OSE (Osaka) TSE (Tokyo) HKFE (Hong Kong) ISE (Istanbul) CBOE (CFE) CME ICE Warsaw Appendix 5 Areas the CFTC will Create New Regulations in: Below is a list of various areas where regulations may change as a result of the recent financial reform bill passed by Congress. All members of the project team need to be mindful of regulatory changes as this project goes forward. New Registration Requirements for Foreign Boards of Trade Rule Certification & Approval Procedures (applicable to DCMs, DCOs, SEFs) Data Recordkeeping & Reporting Requirements Real Time Reporting Anti-Manipulation Disruptive Trading Practices Whistleblowers Position Limits, including Large Trader Reporting, Bona Fide Hedging Definition & Aggregate Limits Volcker Rule Appendix 6 Exchange Symbol Formation: The exchange symbol consists of two parts: a) Root Symbol tells which futures contract is being traded ( ES = S&P 500 E-Mini). b) Symbol Suffix this tells the specific month and year of expiration ( Z3 = December of 2013, Z4 = December of 2014). The letter to use for the expiration month is determined by the following table: Futures Trading BRD 11/19/2012 Page 26 of 47

27 Letter Month Abbreviation Month F Jan January G Feb February H Mar March J Apr April K May May M Jun June N Jul July Q Aug August U Sep September V Oct October X Nov November Z Dec December Table 1 One character month codes The root symbol and symbol suffix are then joined to make up the final exchange symbol (ESZ3 for example). When trading calendar spreads, the exchange symbol will be different as it must reflect the fact that we are trading two contracts at a time, not just one. It will look something like ESH3 ESM3 (spread the S&P 500 E-Mini March 2013 contract against the June contract). Appendix 7 Tick Size: Futures contracts trade with a minimum price differential, called a minimum tick. Each contract is different, and the minimum tick for spread orders is frequently different from the minimum tick size of outright orders. Below is a table that illustrates some of the issues involved. NOTE: we could send orders to the CME and ICE without checking for the correctness of the Minimum Tick. If the order is submitted with an invalid minimum tick, the exchange s system will reject it. Exchange Exchange Root Symbol Spread Tick Size CME ES Final two digits of price can only be 00, 25, 50, or 75 CME (CBOT YM Tick size can only be a full Outright Tick Size Final two digits of price can only be a multiple 0f.25 Tick size can only be a full number (no Futures Trading BRD 11/19/2012 Page 27 of 47

28 Division) number (no decimal places allowed) CME EMD Final two digits can be a multiple of.05 CME NQ Final two digits can be a multiple of.05 CME NKD No decimals in this contract and the whole number must be a multiple of 5 (15785, 15790, 15795, etc.) CME NIY No decimals in this contract and the whole number must be a multiple of 5 (15785, 15790, 15795, etc.) CME (CBOT Division) CME (CBOT Division) DD ZD Price must be a whole number, no decimal portion permitted Final 2 digits can be a multiple of 0.25 decimal places allowed) Final two digits can only be a multiple of.10 for outrights Final two digits of price can only be a multiple of.25 No decimals in this contract and the whole number must be a multiple of 5 (15785, 15790, 15795, etc.) No decimals in this contract and the whole number must be a multiple of 5 (15785, 15790, 15795, etc.) Price must be a whole number, no decimal portion permitted Final 2 digits can be a multiple of 0.25 CME MD Final two digits can only be a multiple of.05 Final two digits can only be a multiple of.05 CME ND Final two digits can only be a multiple of.05 Final two digits of price can only be a multiple of.25 CME SMC Final two digits can only be a multiple of.05 Final two digits can only be a multiple of.10 for outrights CME SMP Final two digits can only be a multiple of.05 Final two digits can only be a multiple of.05 CME SP Final two digits can only be a multiple of.05 Final two digits of price can only be a multiple of.10 ICE DX A multiple A multiple of.005 Futures Trading BRD 11/19/2012 Page 28 of 47

29 (NYBOT Division) ICE (NYBOT Division) ICE (NYBOT Division) of.005 RF A multiple of.05 A multiple of.05 TF A multiple of.05 A multiple of.10 Appendix 8 Price Factors: Price factors for futures work as follows: a) The S&P 500 trades currently at in the real-world b) On the CME it trades at (no decimal point) c) Currently, if we send an order with a limit price of , the price factor will be used (which is 100 for the S&P 500) to change the price to before sending it to GLOBEX d) If we send a price of , it currently would be forwarded to GLOBEX unchanged Exchange Exchange Root Symbol GLOBEX Price Format Decimal Equivalent Price Factor CME ES CME (CBOT Division) YM CME EMD CME NQ CME NKD CME NIY CME (CBOT Division) CME (CBOT Division) DD ZD CME MD CME ND CME SMC CME SMP CME SP ICE DX Futures Trading BRD 11/19/2012 Page 29 of 47

30 (NYBOT Division) ICE (NYBOT Division) ICE (NYBOT Division) RF TF If price factor checking is built into this system, the table above will be needed to find the price factor for a given root symbol. Also, the Client Setup Table will need a flag (see Section 3 above) to tell us if the client sends the price format the exchange expects ( Price Factor Needed field = N ) or if they send us a price that needs to have the price factor applied ( Price Factor Needed field = Y ). Appendix 9 Order Type and Time in Force (TIF) Tags by Exchange: Exchange Tag Number Tag Name Allowed Values ICE 40 Order Type 1 = Market 2 = Limit 3 = Stop (with protection) 4 = Stop Limit ICE 59 Time in Force 0 = Day 1 = GTC 3 = IOC (Immediate or Cancel) 4 = FOK (Fill or Kill) CME 40 Order Type 1 = Market (with protection) 2 = Limit 3 = Stop (with protection) 4 = Stop Limit K = Market-Limit CME 59 Time in Force 0 = Day 1 = GTC 3 = Fill and Kill (Immediate or Cancel) 6 = Good Until Date Note: FOK order can Futures Trading BRD 11/19/2012 Page 30 of 47

31 be replicated by Setting Tag 59 = 3 and setting the value of the Minimum Qty tag = the Order Qty OneChicago 40 Order Type 1 = Market Order 2 = Limit 4 = Stop Limit K = Market Order Appendix 10 Later Phases The following items will not be in the first or second phase of the project, but will be required in a later phase: Support for single stock futures trading Down time for the system in the same calendar day (e.g. 10:00 pm - 10:30 pm) GTD orders Real-time drop copy of messages from the system to the data warehouse APAC and EMEA futures Futures spreads that are more complex than calendar spreads (butterflies, strips, etc.) Non-futures derivatives Side-by-side trading of listed and OTC products will be available in a later phase After considering the issues below, it has been decided to deliver single stock and VIX futures in a later release. 1) Single Stock Futures are traded on OneChicago, not on the CME 2) VIX futures are traded on the Chicago Futures Exchange, not on the CME 3) Effective August 28, 2010 single stock futures cannot be traded at the CME. 4) Effective August 28, 2010, all single stock futures must be cleared at the OCC Single stock futures can be executed via any of several third party vendors, via a connection to OneChicago (that would need to be built and tested) or via CBOE Direct. If we choose CBOE Direct, it would add latency (extra hop) to go to OneChicago. Building a direct connection to OneChicago can be done, but will add to the time required to deliver the project. Futures Trading BRD 11/19/2012 Page 31 of 47