1. 1 Options Clearing Corporation Encore Data Distribution Services April 22, 2004

2. 2 What is DDS?  Data Distribution Services (DDS) - ENCORE outbound data processing implementation  Replaces all Data Files (Data Service, Series, Prices, etc.)  Takes advantage of new and more flexible technologies: - XML based messages - Event Driven Processing - Real Time Delivery

3. 3  A FIX message, also referred to as a report, represents a group of fields used to describe a common functionality  The number of distinct message formats will decrease from 34 current data service layouts to 9 FIX messages  When OCC’s data service content does not map to any existing FIX messages customized fields or messages will be used  Customizations will be formalized through a proposal process with the goal of receiving an approval from the FPL (FIX Protocol Limited) committees Current Data Service to DDS Mapping

4. 4 DDS Process Overview DDS Subscriber CMTA Transfer entered into ENCORE CMTA Transfer is validated and posted to positions PUSH DDS Subscriber receives Post Trade Messages immediately PULL DDS Subscriber opens MQ channel or downloads file when they are ready to process Post Trade Messag e CMTA Transfer is translated into FIXML format Messages are loaded onto subscriber MQ or FTP server

5. 5  Real Time processing - transactional data will be available as soon as it is processed in the Encore system  Real Time outbound transmissions examples: trades and post trades  DDS will also offer real time subscription to master file data (product and contract data service records)  Batch data will be packaged and delivered as soon as it becomes available DDS - Event Driven Processing

6. 6  Subscriber - entity (clearing member, exchange, regulatory agency) that represents the final beneficiary of DDS data  Recipient - entity (clearing member, exchange, regulatory agency or service bureau) that owns the systems where DDS data will be delivered  A recipient can receive both real-time and batch transmissions  Possible setup scenarios: 1). a given entity can act as a subscriber and recipient at the same time 2). a given subscriber can have its data distributed to one or more recipients 3). a given recipient can receive data for multiple subscribers Subscriber - Recipient Profiles

7. 7  A subscriber can choose to have one or more transmissions bundled as one package  Every package will be associated with one or more recipient destinations of the following type: 1). real time - an MQ channel between OCC’s server and recipient’s systems 2). batch file - to be pushed to or pulled by recipient’s systems  Data level security can be applied to the transmission packages (e.g. a package can contain data related to a specific group of tier accounts)  Packages to be delivered in batch mode will become available when processing of the last transmission in the package has completed DDS Packages

8. 8  For real-time transmissions the only supported mechanism will be MQ Series  For subscribers of real-time transmissions that already have MQ in house, the setup of a proper MQ channel will be required  For batch delivery, multiple communication lines are supported (leased lines, dial-up, internet, etc) Delivery Mechanisms

9. 9  DDS FIXML message sizes will increase compared to ODS data service records by a certain expansion ratio  The latest efforts of reduction in message size(transport optimization) are reflected in the FIXML 4.4 Schema version  The main enhancements are a heavier usage of attribute based fields and the abbreviations of field names  Moving from COBOL fixed length records to XML is a more fundamental system change than simply changing a record layout  To enhance performance, XML parsers that can pipeline content rather than require the hierarchy of the XML document to be formed should be considered Implications - Performance and Storage Requirements

10. 10  Subscribers must have the ability to check for duplicate messages based on a supplied unique key(s) for each transmission  Subscriber’s systems need to be able to support multiple iterations of a transaction and take the appropriate actions  Example: - A trade is received and processed within Encore and subsequently sent as a FIXML message to subscribers - If the same trade gets busted (deleted) by an exchange, a new DDS message will be sent indicating that a backout needs to be applied for the given trade Implications - Real Time Processing Challenges

11. 11  Redundant data will be reduced by offering Product Issue transmissions and Option Series/Futures Contract transmissions separately  The message at the product level will be more detailed (delivery components and listing exchanges will be included)  Subscribers are advised to be able to process the Product updates independent of the Series/Contract updates  This information will be available in real time and batch mode Implications - Separate Product and Contract Transmissions

12. 12  FIX standard encourages the use of dates to drive processing and OCC views the usage of dates as a critical factor in the processing of DDS data.  OCC will provide clearing business dates on all transactional and positions based data  For all security master transmissions, OCC will provide activate and inactivate/expiration dates as well as listing dates for each exchange  Subscriber back office and/or order routing processes may need to be modified to interrogate these dates when receiving transmissions  OCC expects that subscribers will use inactivation/expiration dates to drive purge processing when applicable Implications - Date Driven Processing

13. 13  The final schema used for all DDS messages will be an extension to the current FIXML schema version at the time of DDS implementation  OCC will periodically transition its FIXML messages to future FIX releases  OCC plans to provide at any time support for 2 concurrent FIXML releases Implications - Adherence To Standards Tradeoffs

14. 14 DDS Timeline Q3 2005 Data Distribution Systems Publish Formats and Technical Specifications Q1 2004 Q3 2004 DDS Go Live Decommission current data service 12 month overlap between DDS and current data service

15. 15  Plan a project to accommodate processing of new DDS data service  Understand benefits and implications to your organization presented in the DDS external documentation  Get accustomed to the new layouts in FIXML format  Participate as a pilot user in the implementation of DDS  Plan for a testing phase of DDS transmissions between OCC and your organization  Contact your OCC CM Representative or email to ddshelp@theocc.com questions or comments related to DDS Next Steps