Encore Data Distribution Services March 18, 2003

Download Report

Transcript Encore Data Distribution Services March 18, 2003

the
options
clearing
corporation
Options Clearing Corporation
Encore Data Distribution Services
April 22, 2004
1
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
2
Current Data Service to DDS Mapping
 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

3
DDS Process Overview
CMTA Transfer
entered into
ENCORE
CMTA Transfer is validated
and posted to positions
CMTA Transfer is
translated into FIXML
format
DDS Subscriber
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
Messages are
loaded onto
subscriber MQ
or FTP server
4
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
5
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
6
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 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

7
Delivery Mechanisms

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)

8
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(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

9
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

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
10
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
This
information will be available in real time and batch mode
11
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

12
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 will periodically transition its FIXML messages to future FIX releases

OCC plans to provide at any time support for 2 concurrent FIXML releases
13
DDS Timeline
Publish
Formats and
Technical
Specifications
Decommission
current data service
DDS Go Live
12 month overlap
between DDS and current
data service
Q1 2004
Q3 2004
Q3 2005
Data Distribution Systems
14
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 [email protected]
questions or comments related to DDS

15