Chicago Mercantile Exchange Inc. Straight-through-processing Clearing API’s & FIXML _____________________ Positions Services Pilot December 6, 2002Clearing-IT

© 2001 Chicago Mercantile Exchange Inc. All rights reserved CME Presents iClear API’s I.Objectives of STP II.An Overview of Positions Services IV.New Architecture w/ MQSeries V.Position Services message model w/current means of entry VI. FIXML Message Examples VII.Conclusion

© 2001 Chicago Mercantile Exchange Inc. All rights reserved CME’s API Objectives The CME will provide a base set of Message-based Services which are offered to firms, exchanges and other business partners. These Services will extend the CME’s Clearing Services beyond the traditional screen and browser based offering. The Services will provide a message-based interface into a core set of Clearing Services. The gateway into CME Clearing Services will allow firms to “connect” their back-office systems to CME Clearing Systems. Trade and Position Maintenance performed in a firm’s back-office system will be seamlessly integrated and transacted in the CME clearing systems. Integration of Firm Back-office Applications with CME Clearing services via message- based API will reduce redundant maintenance. Firms will no longer need to perform maintenance in their systems and again in CME Clearing Systems. Message-based Clearing Services will promote Straight-thru-processing, reduce the risk of exposure of the CME and firms, and allow greater financial transparency. These Positions Services are offered as a part of the iClear Suite. They will provide an open-systems architecture which will host a firm’s access to the Clearing Services which will allow firms to interface with the API’s via MQ-Series. All API messages, will receive responses as confirmation of the fact that the transaction has been received and applied successfully or non-successfully.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear API’s

© 2001 Chicago Mercantile Exchange Inc. All rights reserved Clearing API’s

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure iClear Strategic Objectives  Serve as the overarching message framework for Clearing Information Technology - All exchanges, firms, clients and applications that are included under the clearing umbrella and which either receive or produce messages will eventually be serviced by this new framework.  Act as the Enterprise Gateway - core Clearing Services will be accessed through the enterprise gateway. All Firm and Exchange communication will flow through this gateway to CME Clearing Services and back out again.  Application Integration Management - centralizes the dynamics of transaction flow between Clearing Applications.  Straight-thru-processing (STP) by enabling uninhibited transaction flow from top to bottom. Seamless integration of disparate platforms (MVS, Unix, NT) allows uninterrupted transaction flow.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure iClear Architectural Objectives  Goal 1: Abstract and remove reliance on any middleware - All architectural features have been designed to be independent of the middleware technology that is implemented.  Goal 2: Construct an interface layer that insulates clients from the complexity of middleware - the interface layer will provide all the benefits of an enterprise messaging infrastructure while allowing the client to concentrate on the execution of business functionality.  Goal 3: Build a flexible and solid foundation on which CME Global Clearing can offer its suite of clearing services - expose the functionality that is currently inaccessible to CME’s external partners and internal sub-systems.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging API

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure Receive and Disseminate Overview  Business Model Support  Flexible Systems Integration Services  Multi-Clearing Organization and Exchange support  A common API provides support for both Front-end and Back-end transaction submission  Support for TREX, M1 and XML at outset  Routing rules defined in meaningful business terms which will be used as criteria to produce and consume messages.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure Receive and Disseminate Overview  Flexible Rules-based Routing A flexible rules-based routing database which can be updated to dynamically alter the criteria for message delivery. The following routing rules will be supported:  Exchange Code  Clearing Organization  Message Source  Firm  Product  Product Group  Trade Status  Trade Business Date  Edit Status  Allocate Claim API Action  Allocate Claim Indicator  Mutual Offset Indicator  Average Price Indicator  Exchange for Physical Indicator  Block Trade Indicator

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure Receive and Disseminate Overview  Producer/Consumer Model  Message delivery between applications, firms and exchanges is based on a “Producer/Consumer” model.  MQ-Series Publish and Subscribe feature will be used to “broadcast” the message to multiple users of the message.  Provides a flexible routing-rule repository used to send messages from one application to another, or from an application to an exchange or firm.  Routing rules are defined at two levels: 1. Master routes are defined using message values, tagged with a business identifier, and assigned to an application. 2. Application-level routes are then defined where one application is the producer with one or more applications as consumers.  The R/D Rules Browser will provide the ability to add, change, delete and view Producer/Consumer Rules using common business criteria.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure Receive and Disseminate Message Flow

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure Receive and Disseminate Overview  Format Translation  An intelligent format translation feature will allow an application to send and receive in disparate formats. This is useful for providing exchanges, firms, or internal applications messages in the format they require.  Multiple inbound and outbound formats will be supported per application based on the preference of the sender and receiver.  Firms, exchanges, and other business partners will be able to send transactions in a format that best suits their processing needs. The new framework will permit the CME to offer an interface tailored to the needs of specific firms without a large amount of work.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure Receive and Disseminate Overview Message Replay Receive and Disseminate will allow immediate ad hoc re-routing of messages to selected applications, firms or exchanges. A browser interface will be built to support this.  A browser interface will allow the messages to be viewed and selected for “replay”. Messages can only be “replayed” to the consumer to which they were originally intended.  The browser will provide the ability to filter and replay based on the following attributes: Business date, Exchange code, Clearing Organization, firm id, trade date, price, broker, timestamp, subject name.  Messages will be stored for 5 business days and can be selected for re-routing during this time.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure Receive and Disseminate Overview Centralized Firm Routing Receive and Disseminate will provide a central repository for firm and exchange routings. It will be the function of Receive and Disseminate, not the individual applications, to determine if a firm is to receive a particular routing.  Customized Firm Routing requirements will be maintained through a flexible browser interface. Routing selections can be specified using the following criteria:  Message confirm types - for example, a firm may elect to receive allocations and accepts, but not rejects and deletes.  Application, Changed Field, Product, Product Group, Trade Type, Account Number, Trade Time.  Message Transport can be determined at the firm level and can take place using MQ-Series or Tibco.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear Messaging Infrastructure iClear/Receive and Disseminate Features

© 2001 Chicago Mercantile Exchange Inc. All rights reserved Exchange and Firm Support Flexibility in adding new messaging support for Firms and Exchanges Legacy Requires program changes to support interface from new exchange or firm source Requires program changes to support new format No support currently exists for Back-end transaction submissioniClear NO program changes are required to support new exchange or firm interface New message formats require no changes to application processes. Common API for managing Back-end transaction submission

© 2001 Chicago Mercantile Exchange Inc. All rights reserved Routing Rules Maintenance Legacy Done programmatically. Routing Rules are de- centralized and hard- coded in individual sub- systems. Changes to routing rules requires program changesiClear Routing rules maintained at business level in rules database. There is no impact to enterprise code-base Routing Rules can be changed dynamically by business users.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved Centralized Firm Routing Legacy No centralized firm routing rules exist. Firms and CH Support must maintain routing requirements across a number of routing tables.iClear Firm routing rules will be maintained in a centralized routing database. Provides the advantage of reduced maintenance and centralized control.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved Message Replay Legacy Message replay for firms requires manual intervention on the part of Clearing-IT staff No existing user interfaceiClear Allows firm to request message replay. Clearing-IT intervention no longer necessary Provides intuitive browser interface for internal and external use.

© 2001 Chicago Mercantile Exchange Inc. All rights reserved iClear in Conclusion iClear is the new Messaging Infrastructure that will accomplish the following: 1. Link together internal applications by integration into an enterprise messaging hub. 2. Achieve a higher degree of STP. 3. Externalize the business criteria used to perform message routing. 4. Make Clearing Services more accessible through an API Gateway. 5. Provide a centralized command and control that can be used across all applications. 6. Reduce technical complexity by encapsulating messaging function in the Receive and Disseminate application.