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

Chicago Mercantile Exchange Inc.

Straight-through-processingClearing API’s

&FIXML

_____________________Positions Services Pilot

December 6, 2002 Clearing-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


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.


iClear API’s

Firm Personnel

Straight-Through-Processing Illustrated

Firm EntryFirm Bookkeeping

System

Clearing 21 Entry CME ClearingSystem

One form of Non-Direct Processing is double entry which results in additionalpoints of failure, greater opportunity for operator error, and redundancy ofeffort

Non-direct Processing


Clearing API’s

Firm PersonnelFirm Entry

Straight-thru-processing

CME ClearingSystem

Firm BookkeepingSystem

One form of STP is single entry which promotes single entry andinteroperability of disparate systems.


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.



• 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.


iClear Messaging API

CME Clearing Services

Receive and Disseminate Interface Layer

Tibco MQ-Series

Transport MechanismTCP/IP, UDP, LU6.2

Firms and Exchanges



•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.




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




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.



CME Tib Bus

ApplicationQueue

CTIOConsumer

MQBroker

Receive and DisseminateApplication Function Flow

ClearingFirm

ClearingFirm

RDGateway

MQ-Series

Tibco

RD Message Sphere

RDGateway

CTIOProducer

Client 2

CTIOConsumer

CTIOConsumer

ApplicationQueue

CTIOProducer

Client 1

RMI

Assign Topic

RMI

ApplicationQueue

CTIOProducer

Client 3

RMI CFMR

iLink

OracleDB

JNDI

Admin Agent

JMSHeartbeat

CLIOStartup

R/D UI

Message Store

MQ/Tib

Route SelectionRules DefinitionMessage Replay

Firm Routing

MQ-SeriesMQ-Series

Receive and Disseminate Message Flow




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.



•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.




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.



• iClear/Receive and Disseminate Features

Clearing Gateway

Message Translation

Message Replay

Business Rule-based Routing


Producer Consumer Model


Exchange and Firm Support

• Flexibility in adding new messaging support for Firms and Exchanges

LegacyLegacy

• 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 submission

iCleariClear

• 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


Routing Rules Maintenance

LegacyLegacy

• Done programmatically. Routing Rules are de-centralized and hard-coded in individual sub-systems.

• Changes to routing rules requires program changes

iCleariClear

• 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.



LegacyLegacy

• No centralized firm routing rules exist.

• Firms and CH Support must maintain routing requirements across a number of routing tables.

iCleariClear

• Firm routing rules will be maintained in a centralized routing database.

• Provides the advantage of reduced maintenance and centralized control.


Message Replay

LegacyLegacy

• Message replay for firms requires manual intervention on the part of Clearing-IT staff

• No existing user interface

iCleariClear

• Allows firm to request message replay. Clearing-IT intervention no longer necessary

• Provides intuitive browser interface for internal and external use.


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.

Documents

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