Implementing XML TH400B

1
Implementing XMLTH4-00B

• Mark Baumgardner
• Vice President, Product and Business
  DevelopmentThe Options Clearing Corporation
• Ed Gogol
• Director, Systems Development, Clearing
  HouseChicago Mercantile Exchange
• Matt Simpson
• Associate Director, Clearing ITChicago
  Mercantile Exchange
• David Sternberg
• Director, Clearing TechnologyNew York Board of
  Trade

2
Agenda

• NYBOT XML usage and plans
• David Sternberg
• CME XML usage and plans
• Ed Gogol
• Matt Simpson
• The OCC XML usage and plans
• Mark Baumgardner
• Question and Answers
• Arranged to permit audience members a chance to
  ask specific questions of the clearing house
  plans for FIXML and XML in general

3
CME APIs for 2004Post-Trade Message Model

• SLEDS, EFPs and Blocks
• Via FIXML
• November 6, 2003

4
SLEDS, EFP and Block DialogueTwo-sided entry and
Match
Sell Side
Clearing House
Buy Side
Trade Capture Report TradeTransTypeNEW
TradeReportTypeSUBMIT
Trade Capture Report TradeTransTypeNEW
TradeReportTypeSUBMIT
Trade Capture ACK TradeTransTypeNEW Trade
ReportTypeSUBMIT
Trade Capture ACK TransTypeNEW
TradeReportTypeSUBMIT
Trade Capture ACK TradeTransTypeNEW TradeReportSt
atusREJECT rejected by clearing house
Trade Capture ACK TradeTransTypeNEW TradeReportSt
atusREJECT rejected by clearing house
Trade Capture Report TradeTransTypeNEW TradeRepor
tType ACCEPT MatchStatusMATCH
Trade Capture Report TradeTransTypeNEW TradeRepor
tTypeACCEPT MatchStatusMATCH
M
5
SLEDS, EFP and Block DialogueRequest for
Pre-Match Change
Sell Side
Clearing House
Buy Side
Trade Capture Report TradeTransTypeREPLACE
TradeReportTypeSUBMIT
Trade Capture ACK TradeTransTypeREPLACE TradeRepo
rtStatusREJECT rejected by clearing house
Trade Capture Report TradeTransTypeREPLACE TradeR
eportType ACCEPT
Trade Capture Report TradeTransTypeREPLACE TradeR
eportTypeACCEPT
6
SLEDS, EFP and Block DialogueRequest for
Cancellation
Sell Side
Clearing House
Buy Side
Trade Capture Report TradeTransTypeCANCEL
TradeReportTypeSUBMIT
Trade Capture ACK TradeTransTypeCANCEL TradeRepor
tStatusREJECT rejected by clearing house
Trade Capture Report TradeTransTypeCANCEL TradeRe
portType ACCEPT
Trade Capture Report TradeTransTypeCANCEL TradeRe
portTypeACCEPT
7
Position Services DialogueExercise Notice Request
Firm
Clearing House
Customer
Position Maint Request PosTransTypeNEW
PosMaintActionEXER
Customer1 Exercise
Customer2 Exercise
Position Maint Request PosTransTypeREPLACE
PosMaintActionEXER
Customer2 Exercise
Position Maint Request PosTransTypeREPLACE PosMai
ntActionEXER
Position Maint Report PosTransTypeNEW/REP PosMain
tActionEXER PosStatusERR
Customer1 Confirm
Customer2 Confirm
Postion Maint Report PosTransTypeNEW/REP PosMaint
ActionEXER PosStatusPROCESSED
Customer2 Confirm
8
Position Services DialogueRequest for Position
Firm
Clearing House
Backoffice
Position Request RequestTypeP TransportTypeINBA
ND
BackOffice Request for Position
Position Request ACK RequestTypeP TransportTypeI
NBAND PositionResultPROCESSED
BackOffice Point Balance
Position Report RequestTypeP (Position
Information)
Trade Capture Report TradeTransTypeNEW TradeRepor
tType ACCEPT MatchStatusMATCH
9
FIXML Extensibility Support for Multileg
Instruments
10
Encore Data Distribution Services

• Mark Baumgardner

11
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

12
Industry Challenges
Increasing Transaction Volumes
Industry Move To STP
Customer Demands for Real-time Information
Real-Time Data Receipt
Reality of a global marketplace
Improved Flexibility
13
ODS to DDS Mapping

Intracs
1 Transaction layout
15 Trade and Post Trade layouts
1 Position layout
3 Positions layouts
2 Delivery Activity layout
6 E/A and Delivery Settlement layouts
4 Product Masterfile layout
7 Series, Open Interest, and Dividends layouts
1 Prices layout
3 Prices layouts
34 Intracs Layouts
9 Encore Layouts !
14
DDS Process Overview
DDS Subscriber
PUSH DDS Subscriber receives Post Trade Messages
immediately
CMTA Transfer entered into ENCORE
PULL DDS Subscriber opens MQ channel or downloads
file when they are ready to process
CMTA Transfer is validated and posted to positions
Post Trade Message
Messages are loaded onto subscriber MQ or FTP
server
CMTA Transfer is translated into FIXML format
15
DDS - Event Driven Processing

• 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

16
Subscriber - Recipient Profiles

• 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

17
DDS Packages

• 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 OCCs
  server and
• recipients systems
• 2). batch file - to be pushed to or pulled by
  recipients 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

18
Delivery Mechanisms

• For real-time transmissions the only supported
  mechanism will be MQ Series
• For subscribers that subscribe to transmissions
  real-time and already have MQ in house, the setup
  of a proper MQ channel will be necessary
• For batch delivery, multiple communication lines
  are supported (leased lines, dial-up, internet,
  etc)
• As we are in the process of testing various
  batch delivery software, details related to this
  subject will be forthcoming

19
Implications - Performance and Storage
Requirements

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

20
Implications - Real Time Processing Challenges

• Subscribers must have the ability to check for
  duplicate messages based on a supplied unique
  key(s) for each transmission
• Subscribers 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

21
Implications - Separate Product and Contract
Transmissions

• 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
• An incremental version for these messages will be
  available in real time and batch mode
• The incremental message formats will contain a
  FROM section and a TO section allowing the
  retrieval of existing product/contract definition
  using the business keys from the FROM section
  and the update with the full definition supplied
  in the TO section
• The 2 incremental message types will be delivered
  over the same MQ queue or in the same batch file
  in the chronological order of the occurrence of
  adds, modifies or deletes

22
Implications - Date Driven Processing

• 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

23
Implications - Adherence To Standards Tradeoffs

• 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 expects to participate in a proposal process
  which involves submitting the necessary
  documentation to FPL to include the customized
  fields in FIX
• The FPL committees and other FIX members will
  validate the viability of the content and
  representation of customized fields
• OCC will periodically transition its FIXML
  messages to future FIX releases
• OCC plans to provide at any time support for 2
  concurrent FIXML releases

24
DDS Timeline
Publish Formats and Technical Specifications
Decommission current data service
DDS Go Live
12 month overlap between DDS and current data
service
Q3 2005
Q3 2004
Q4 2003
Data Distribution Systems
25
Next Steps

• 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_at_theocc.com questions or comments related
  to DDS

26
Contact Information

• Contact your OCC CM Representative
• or
• email to ddshelp_at_theocc.com