Millennium Exchange Migration Oslo Brs cash equities and fixed - - PowerPoint PPT Presentation

Millennium Exchange Migration

– Oslo Børs cash equities and fixed income markets

Developer Forum - Oslo, 1 March 2012

Agenda

• 12:15-12:25 Introduction to the project, project plan
• 12:30-12:40 Different protocols and gateways
• 12:45-13:05 Trading
• 13:10-13:20 Market data
• 13:25-13:35 Pause
• 13:35-13:45 Equities
• Order types
• Order validity types
• Order behavior & management (cancel on disconnect)
• Order priority and execution (icebergs, hidden orders, pegged orders)
• Internalisering
• 13:50-14:00 Fixed income (same as equities)
• 14:05-14:20 Reference data
• 14:25-14:35 Enablement, trader groups and participant structure
• 14:40-14:50 Testing
• 14:50-15:00 Network
• Participants’ feedback on further activity for the Oslo Børs developer forum
• Participants’ feedback on the project plan

2

3

Oslo Børs Migration to Millennium Exchange

3

What? Why? When? Migration from TradElect to Millennium Exchange, covering

• Listed equities (shares, equity certificates, ETPs, warrants)
• Fixed income
• First step: LSE/Oslo Børs strategic partnership launched Q1

2009

• Second step: Oslo Børs migrated to SOLA Q4 2009 & to

TradElect Q2 2010

• Third step: LSE migrated to Millennium Q1 2011
• Next step:
• Borsa Italiana will migrate to Millennium in Q2 2012
• Oslo Børs plans to migrate to Millennium Q4 2012
• To continue on the same trading platform as LSE
• State-of-the-art system
• Facilitate common memberships LSE-Oslo Børs

Migration to Millennium Q4 2012

4

Q1/2012 Q2/2012 Q3/2012 Q4/2012

Define Market Model & Functionality ISVs and Customers Testing 3 Dress Rehearsals

Dialogue with Customers and ISVs (Independent Software

Vendors) Design & Development Network & Infrastructure Upgrade Integrating Millennium to Oslo Børs

Time schedule is subject to market and system readiness and will be confirmed in May 2012.

ISVs and Customers Conformance

Millennium Main Milestones

Q4 2012 Go Live September 2012 All Customers Conformed May 2012 Go Live Date Confirmed May 2012 Customer Test Environment opened (CDS) February / March 2012 Documentation published

5

To-Do for customers / members

• Software/systems – adapt to become compatible with Oslo Børs

Millennium

• Members’ internal development and ISVs (Independent Software Vendors)
• Network /infrastructure - implement any needed changes
• New enablements - connect to Oslo Børs Millennium customer test

service (CDS)

• Test – utilise the planned test services
• Including planned evening and weekend tests
• Carry out mandatory conformance before the first dress rehearsal
• Conformance based on self certification
• New enablements - connect to Oslo Børs Millennium production

environment

• Participate actively in all dress rehearsals (mandatory)
• 3 DRs planned in September/October (Saturdays)

6

7

Communication during the migration process

• All important material will be posted on the

“Delta web”

• www.oslobors.no/ob_eng/Oslo-Boers/Trade/

Delta/Millennium-Exchange

• Subscription service – enter your e-mail address

at the website to receive information

• Technical helpdesk:
• technicalsupport@oslobors.no / Tel. +47 22 34 19 90
• Member Reference Group
• Developer Forum for ISVs, vendors & members with internal

development

• Information meetings will be organised in Oslo and London
• Members, vendors and ISVs will be invited
• Held in advance of important events
• Further group meetings and 1:1 meetings will be organised

Documentation

9

Documentation

General OSLMIT Oslo Børs Market Model Equities OSLMIT Oslo Børs Market Model Fixed Income Trading OSLMIT 201 Guide to New Trading System OSLMIT 202 FIX Trading Gateway (FIX 5.0 SP2) OSLMIT 203 Native Trading Gateway OSLMIT 204 Post Trade Gateway (FIX 5.0 SP2) OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) Market Data OSLMIT 302 FIX/FAST Gateway OSLMIT 303 ITCH Gateway OSLMIT 306 FIX/FAST News and Indices Gateway OSLMIT 401 Reference Data Other OSLMIT 501 Testing OSLMIT 502 Guide to Application Certification OSLMIT 504 Guide to Customer Enablement OSLMIT 601 Guide to Trading Services Disaster Recovery OSLMIT 602 Network Guide OSLMIT 603 Business Parameters OSLMIT 604 Technical Parameters OSLMIT 605 Live Environment Connectivity OSLMIT 606 CDS Environment Connectivity

Documentation - structure

• Separate market models for equities and fixed income
• All technical parameters (e.g. logon limitations):
• OSLMIT 604 Technical Parameters
• All business parameters (e.g. off-book trade types):
• OSLMIT 603 Business Parameters
• All IP adresses:
• OSLMIT 605 Live Environment Connectivity
• OSLMIT 606 CDS Environment Connectivity

10

Documentation - status

11

Released OSLMIT Oslo Børs Market Model Fixed Income OSLMIT 202 FIX Trading Gateway (FIX 5.0 SP2) OSLMIT 203 Native Trading Gateway OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) OSLMIT 303 ITCH Gateway OSLMIT 401 Reference Data OSLMIT 602 Network Guide To be released the next week OSLMIT 204 Post Trade Gateway (FIX 5.0 SP2) OSLMIT 302 FIX/FAST Gateway OSLMIT 306 FIX/FAST News and Indices Gateway OSLMIT Oslo Børs Market Model Equities To be released in March OSLMIT 201 Guide to New Trading System OSLMIT 501 Testing OSLMIT 502 Guide to Application Certification OSLMIT 504 Guide to Customer Enablement OSLMIT 601 Guide to Trading Services Disaster Recovery OSLMIT 603 Business Parameters OSLMIT 604 Technical Parameters OSLMIT 605 Live Environment Connectivity OSLMIT 606 CDS Environment Connectivity

Trading: Different gateways and protocols

Protocols

Trading:

• FIX (also for Drop Copy and Post Trade)
• Native

Market data:

• FIX/FAST
• Native/ITCH

Reference data:

• File based, both XML and CSV
• FIX/FAST and ITCH has some, limited reference data

13

14

Please note that the FIX Trading Gateway may be used for both equities and fixed income

Trading Gateways – common information

• The FIX Trading Gateway may be used for both equities and

fixed income

• The Native Trading Gateway may only be used for equities
• All timestamps will be in UTC
• Millennium supports more than one partition (matching

engine), you will find references to partitions in all the interface documents. Oslo Børs will from go-live only use

• ne partition

15

Trading Gateways – common information: ClientOrderId

• Order ID created by the client, unique per order across

trading days

• Failure to comply with the uniqueness requirement can have

a serious impact for the client, e.g. if you have two orders will the same ClientOrderId you will only be able to cancel the last of the two orders

• May be used for requests on both Drop Copy and Post Trade

as well

16

Trading Gateways – common information: Free text fields

• TraderID
• Limited to 11 characters
• The first character should define the trade flow (like trader groups does

in TradElect), e.g.:

• 0 = Manual trading
• 1 = DMA
• 2 = Algo
• 3 = tbd
• Definitions to be decided and documented later
• The next 10 characters is free text
• Supports ASCII characters 0-127
• Account
• Limited to 10 characters
• Supports ASCII characters 0-127 + 145(æ), 146(Æ), 155(ø), 157(Ø),

134(å) and 143(Å)

17

FIX Trading Gateway

• Order handling
• Unsolicited order updates
• Connecting with a CompID, just login privileges
• Entering/modifying orders on behalf of a trader group

18

FIX Trading Gateway: Mass Order Cancellation

• ClientOrderID is mandatory
• Order mass cancellations, may be used to cancel orders for:
• An instrument
• A segment
• A trader group
• A firm
• A combination of the options above
• Order cancellation messages for a Mass Order

Cancellation will be sent to the client on the protocol the

• rder was first entered

19

Native Trading Gateway

• Order handling
• Unsolicited order updates
• Logging in and entering/amending with username
• Mass cancellations

20

Native Trading Gateway: Mass Order Cancellation

• ClientOrderID is optional, but recommended (if provided, it

will be reflected in all response messages)

• Order mass cancellations may be used to cancel orders for:
• An instrument
• A segment
• A trader group
• A firm
• A combination of the options above
• Order cancellation messages for a Mass Order

Cancellation will be sent to the client on the protocol the

• rder was first entered

21

Drop Copy Gateway

• Provides a copy of all order updates
• The identity of the CompID that transmitted the order a

particular drop copy relates to will be specified in the header field OnBehalfOfCompID(115).

• Both real-time and query based
• May be used for recovery purposes by using the Order

Mass Status Request

22

Drop Copy Gateway

Real time connection:

• Execution reports
• Different exec types
• Open order download

Query based connection:

• Open order download

23

Drop Copy Gateway: Open Order Download

• Order Mass Status may be requested for:
• All open orders for a specified instrument
• All open orders for a specified segment
• All open orders for a specified trader group
• The number of times per day you are able to do an Order

Mass Status Request is limited per CompId. Please refer to OSLMIT 604 Technical Parameters

24

Drop Copy Gateway: Resend Request

• May be used if you have lost real time drop copy messages
• Regular ResendRequests by the FIX standard
• The number of messages you may recover is defined by the

gateways’ message cache size. This will be defined in the OSLMIT 604 Technical Parameters document

25

Post Trade Gateway

• Both real-time and query based
• Provides real-time updates on trades
• Off-book management
• May be used for recovery purposes by sending a Trade

Capture Report Request

26

Post Trade Gateway: Trade feed

• Real-time information on trades. All updates, including

cancellations

• Both on-book and off-book

27

Post Trade Gateway: Query based

• Off-book management
• Trade cancellation
• Request for copies of TradeCaptureReports, for:
• All trades
• Matching a specified trade type
• Matching a specified order
• Matching a specified instrument
• Etc. (more examples given in OSLMIT 204 Post Trade Gateway)
• The number of times per day you are able to request for

copies of TradeCaptureReports is limited per CompID. Please refer to OSLMIT 604 Technical Parameters

28

Post Trade Gateway: Off-book management

• Trade reporting
• Equities: Two-party report
• Fixed income: One-party report for pass through
• Pre-releasing
• Cancellation
• Cancel a confirmed pre-negotiated trade
• Cancel an unconfirmed pre-negotiated trade

29

Post Trade Gateway: Equity Trade Reporting

• The only supported trade reporting mechanism for equities

is the Two-Party Report (also known as single-sided trade report from TradElect)

• The trade is reported by only one of the counterparties
• If the trade is confirmed by the matching engine, the server

will transmit a TradeCaptureReport to each of the two counterparties

• The default CompID of the counterparty will receive the

confirmation

30

Post Trade Gateway: Fixed income Trade Reporting

• The only supported trade reporting mechanism for fixed

income is the one-party report for pass through (also known as dual-side trade reporting from TradElect)

• The trade is initially reported by one of the counterparties

via a TradeCaptureReport which will include the identity

• f both firms. The other counterparty will then have to

confirm or reject the request.

• The default CompID of the counterparty will receive the

request, and final TradeCaptureReport if the trade is confirmed

31

Post Trade Gateway: Trade Cancellation

• Both on and off-book trades may be cancelled by the

participants

• The Oslo Børs market supervision team may aslo be

requested to cancel trades on behalf of a participant

• Requests, notifications and confirmations will be sent to all

relevant clients

32

Post Trade Gateway: ResendRequest

• May be used if you have lost real time post trade messages
• Regular ResendRequests by the FIX standard
• The number of messages you may recover is defined by the

gateways’ message cache size. This will be defined in the OSLMIT 604 Technical Parameters document

33

Market Data

ITCH

• Native binary format on all messages
• Uses multicast/UDP for broadcasting all real-time messages
• All real-time messages will be disseminated twice via two

different gateways

• All participants should listen to both streams in order to

minimize the risk of losing messages

• A TCP-based replay service will be provided to recover the

last 150,000 last messages

• A TCP-based recovery service will be provided to let you

recover from bigger outage

35

ITCH

• Both the OrderID and TradeID is base62-encoded
• You are able to map them back and forth by doing basic

encoding/decoding explained in the OSLMIT 604 Technical Parameters document

36

ITCH Full Depth

• Equities only (for fixed income, see FAST)
• Incremental full depth
• Gives you order updates and all trades
• Limited information about the instruments
• Instrument status messages for all session changes
• Indicative auction price and the associated trade volume
• Open/Close/Previous day’s close prices

37

ITCH – Trade Only Gateway

• New gateway set up to provide enhanced trade information
• Uses the EnhancedTrade message
• Includes auction information
• Includes information about the parties involved in the trade
• Excludes the trade identifiers, to maintain order anonymity

in the equity market

• You are able to recover all trades from the whole day (not

limited to 150,000 messsages, as the regular ITCH gateway)

38

ITCH Replay Channel

• Permits clients to request the retransmission of up to

150,000 messages.

• Should be used to recover from a minor data loss
• Please note that the count field in the ReplayRequest

message is a 16 bit unsigned integer, which supports less than 150,000. You may get around this limitation by send more than one request

39

ITCH Recovery Channel

• Permits clients to recover from a large-scale data loss, if

you have lost more than 150,000 messages

• Provides a snapshot of the order book for the active

instruments

• Snapshots may be requested per segment or instrument
• You may also request the list of all active instruments, and

statistics

40

FIX/FAST Gateway

• Uses FAST-encoded FIX 5.0SP2 messages
• Uses multicast/UDP for broadcasting all real-time messages
• All real-time messages will be disseminated twice via two

different gateways

• All participants should listen to both streams in order to

minimize the risk of losing messages

• A TCP-based replay service will be provided to recover the

last 150,000 last messages

• A TCP-based recovery service will be provided to let you

recover from bigger outage

41

FIX/FAST Gateway

• Both Incremental and Snapshot mode
• Incremental mode will be used for fixed income
• Incremental mode will give you all updates as they happen
• Snapshot mode will only be used for equities
• Snapshot mode will give you a full refresh snapshot every

100ms

42

FIX/FAST Gateway

• Gives you order updates and statistics
• Trades will only be disseminated for equities (see the Trade

Only Gateway)

• Limited information about the instruments
• Instrument status messages for all session changes
• Indicative auction price and the associated trade volume

43

FIX/FAST Trade Only Gateway

• New gateway set up to provide trade information
• Used only for fixed income
• Includes auction information (not for issuing and buyback

instruments)

• You are able to recover all trades from the whole day (not

limited to 150,000 messsages, as the regular ITCH gateway)

44

FAST Replay Channel

• Permits clients to request the retransmission of up to

150,000 messages.

• Should be used to recover from a minor data loss
• You are able to request for messages either by specifying

ApplBegSeqNum(1182) and ApplEndSeqNum(1183). You may set the ApplEndSeqNum(1183) to ’0’ to receive ’all messages after ApplBegSeqNum’

45

FAST Recovery Channel

• Permits clients to recover from a large-scale data loss, if

you have lost more than 150,000 messages

• Provides a snapshot of the order book for the active

instruments

• Snapshots may be requested per segment or instrument
• You may also request the list of all active instruments, and

statistics

46

Disaster recovery

• ITHC market data will be made available on FTP, as binary

files, at EOD, for:

• Equities
• Warrants
• ETFs
• FIX/FAST market data will be made available on FTP, as

binary files at EOD, for:

• Fixed income incremental service

47

Equities

Order types

• Market
• Persist in order book during auctions only
• Limit
• Iceberg
• Minimum peak size still applies
• May be market or limit order

49

Order types (2)

• Hidden Limit
• Note: Minimum Execution Size not available
• Minimum order size still applies (MiFID)
• Hidden Pegged
• Note: Peg to ’visible BBO mid’ only
• Minimum order size as Hidden Limit
• Market or Limit order
• DAY and GTT only
• Pegged orders do not participate in auctions, and will expire when the

closing auction call starts

• If entered during an auction, order is parked until after uncross

50

Order validity

Millennium TradElect IOC Immediate-or-cancel ENE – Execute and eliminate FOK Fill-or-kill GTD Good-till-date GTT order may specify date & time GTT Good-till-time

• Does NOT expire during an auction

ATC At-the-close

• Expires at EOD

ATC may be carried forward to next day OPG At-the-open

• May be entered during Opening

Auction Call only OPG may be carried forward to next day GFA Good-for-auction GFA may be carried forward to next day DAY Good-for-day GFD

51

Order amendment

• Amendable attributes:
• Quantity (total and disclosed)
• Price
• Expiry date (GTD) or time (GTT)
• Account (”Order reference”)
• NOT amendable:
• Validity
• Quantity increase or price change:
• Order re-aggresses order book and loses time priority

52

Automatic order cancel

• Order cancel on disconnect / logout
• May be set per CompID by Oslo Børs. Options are:
• Logout
• Do not cancel (default)
• Cancel
• Cancel, but exclude GTD orders
• Disconnect
• Do not cancel (default)
• Cancel
• Cancel, but exclude GTD orders
• Disconnect delay (ms)
• May override per order

53

Order execution

• Order priority:
• 1. Price
• 2. Counterparty (preferencing)
• 3. Visibility

1.

Fully visible incl iceberg peaks (Note: If preferencing, the hidden part of an iceberg is executed first)

2.

Hidden part of icebergs

3.

Hidden limit

4.

Hidden pegged

• 4. Time
• Note regarding Icebergs:
• If all visible volume is executed, and the remaining aggressive volume

is not sufficient to execute against the total hidden iceberg volume, the remaining aggressive volume is pro-rated over all remaining iceberg volume relative to the remaining total volume

54

Order execution – iceberg example

Hidden Visible Order A 5,000 1,000 Order B 3,000 500 Order C 20,000 100 Order D 100,000

55

1. Visible quantities are executed: 1. Order A: 1,000 2. Order B: 500 3. Order C: 100 2. Remaining 13,400 is allocated pro rata to icebergs 1. Order A: 5/28 x 13,400 = 2,393 2. Order B: 3/28 x 13,400 = 1,436 3. Order C: 20/28 x 13,400 = 9,571 Aggressing order: 15000 @ same price

Order execution - auctions

• Auction price and volume is calculated to maximize the

executable volume

• Disseminated when changed
• Hidden limit orders are included
• Hidden pegged orders are not included
• An auction may be extended due to a Price Monitoring

Extension (PME) and/or Market Order Extension (MOE)

• Closing call may trigger 2 PMEs
• Random uncrossing in a 5 or 30 seconds interval

56

Clearing

• Trades which are to be cleared will be sent directly (real

time) to the CCP

• The following still applies:
• Auto executed trades only
• All shares, equity certificates, ETFs
• NOT Warrants, ETNs, temporary instruments (e.g. subscription rights)

which must be settled bilaterally

• New feature (member’s choice): Internalization
• When a member trades with itself the trade will not be cleared and will

not be sent to the CCP

• Prerequisite:
• Both parties (trader groups) are in the same internalization group (configured

by OB)

57

Fixed income

The trading day

OB Automatch OB Call OB Issuing Auction and OB Buyback Auction Oslo ABM OB Telephone and Oslo ABM Telephone

Start trade reporting 8:15 8:15 N/A 8:15 8:15 Start order entry/ maintenance 8:15 8:15 10:15 9:00 9:00 Opening auction 9:00 9:00 N/A N/A N/A Start of continuous trading 9:00 9:00 N/A 9:00 9:00 Intraday auctions 11:10 N/A N/A Closing auction N/A 16:00 N/A N/A N/A Stop order maintenance 16:00 16:00 N/A 16:00 16:00 Stop trade reporting 16:00 16:00 N/A 16:00 16:00 Stop trade cancellation 16:15 16:15 11:30 16:15 16:15

59

Order types and order validity

60

Order Types Order Validity Limit orders Day, GTC, GTD, GTT, GFA, OPG, IOC, FOK Iceberg orders Day, GTC, GTD, GTT, OPG, IOC, FOK

In addition to the available order validities on equity orders the GTC, good till cancel, is available for fixed income. No maximum number of days limit. ATC, at the close, is not available for fixed income instruments. Availability of order types and order validity depends on segment and session GTT: Validity intraday only

Order execution

• Order priority:
• 1. Price
• 2. Counterparty (preferencing)
• 3. Visibility
• Fully visible including iceberg peaks (Note: If preferencing, the hidden part
• f an iceberg is executed first)
• 4. Time
• Note regarding Icebergs:
• If all visible volume is executed, and the remaining aggressive volume

is not sufficient to execute against the total hidden iceberg volume, the remaining aggressive volume is pro-rated over all remaining iceberg volume relative to the remaining total volume

61

Other order information

• Algorithm for opening and closing auction: as for equities,

except for Price Monitoring Extensions and Market Order Extensions

• Order cancel on disconnect / logout: as for equities
• Order amendment: as for equities
• Dealing capacity
• Agency or Principal

62

Issuing and buyback auctions

• Allocation algorithm as in TradElect
• Both Dutch and American auctions will be supported

63

Off-book trade reporting (1)

• Trade reporting available 8:15 – 16:00
• Trades reported with delayed dissemination are published at

16:00

• Dual-sided reporting
• One party reports, the other party will receive a notification to the

default CompID and confirm the trade

• Counterparty = other member firm or ”NMBR”
• Capacity: Agency, Principal

64

Off-book trade reporting (2)

• No change in off-book Trade Types
• Deferred publication managed via Trade Type
• Pre-release available
• Members may cancel - both the buying and the selling

member must cancel their side before the trade is cancelled.

• During post trade session only the exchange may cancel trades.

65

Market data

• FAST/FIX – Trades and trade related statistics are published via a

trade only gateway, while orderbook updates are published on an

• rderbook information gateway
• Pre trade: All orders are published with:

price visible volume member ID yield* During auctions indicative auction price is published (except during issuing- and buy back auctions)

• Post trade: Each single trade is published with:

price volume yield* This applies even during auctions (i.e. no ”Auction Trade” message) Trades are not published with member ID

* Yield to be calculated for fixed rate bullet bonds and zero coupon bills

66

Orderbooks

• Instruments with availability for orders and manual trades

have two separate orderbooks.

• Three available types:
• On-book – have order entry and automatic trading.
• Off-book - have manual trade reporting.
• Bulletin board - have order entry, but no automatic trading.
• Security Status message distributes MDSupbBookType

and relevant status for the orderbooks via FAST FIX.

• One orderbook per instrument is marked as primary

67

Statistics fixed income

• The specified primary orderbook distributes the official

combined statistics for the fixed income instruments.

• Price statistics:
• Combination of on-book (automatched and uncrossed trades) and

some off-book trades (O and OK)

• Only updated for current day
• Volume statistics:
• Combination of on-book and all-book trades
• Only updated for current day
• Note: A single Repo (OR and DR) trade represents two transactions and

volume, turnover and number of trades should be doubled. For repo trades turnover equals volume

68

Matador Fixed Income - MFI

• A migration offer to Millenium Exchange has been

distributed to the fixed income members

• The decision to upgrade or discontinue the trading terminal

will be made as soon as necessary feedback from members has been received by Oslo Børs

69

Reference Data

Instrument ID

• Instrument ID is a unique identifier of an instrument
• Instrument ID is a UInt32 data type and used across all

gateways in Millennium

• Each unique 4-way key (Tradable Instrument Code, Country

Of Register, Segment Code, Currency Code) used in TradElect will be replaced by a single Instrument ID

• Instrument IDs are disseminated by the:
• FAST-UDP Market Data gateway in the Security Definition message
• This message also provide ISIN, Segment and Status.
• ITCH-UDP Market Data gateway in the Symbol Directory message
• This message also provide ISIN, Segment, Status and Priceband/Circuit Breaker limits.
• FTP/SFTP Reference Data solution
• Privides a set of reference data files that clients can download for enrichment and supplement

purposes in order to assist trading

• Instrument ID will be the same as SID used in many existing

products offered by Oslo Børs Market Data

Reference data files - overview

Instrument File

• Instrument definitions (Ticker, segment,

currency, status, clearing, various dates, EMS..)

• Reference to calender, post trade and

trading parameters Calendar File

• Calendar containing trading dates

Post Trade Parameter File

• Price validation, trading modell (single,

dual)

• Reference to trade types

Trade Type File

• Trade type def. (map to FIX enums)

Trading Parameter File

• Various params such as Circuit Breaker

limits, Price band, Maximum Order Duration

• Reference til Price Tick def.
• Reference to Session Parameter def.

Price Tick File

• Max, min and tick size values

Session Parameter File

• Various parameters for each trading session

(Start of trading, Opening Auction, Cont. Trading…) Participant File

• Map from member ID to name.

Index File

• Map from ISIN to symbol and name

Instrument File Calendar File Price Tick File Post Trading parameter File Trade Type File Trading parameter File Session parameter File Participant File Index File

FTP/SFTP Reference data solution

• The reference data files for the next trading day are published

each trading day after market close

• Under normal circumstances the files are available for download

from 18:45 CET the day before next trading day

• The files can be downloaded via FTP/SFTP from the same

network connection used for trading services

• Both CSV and XML formatted files are available
• The file content is basically the same
• XSD schema for each XML file
• Intraday updates must be supported by clients. Intraday

updates will not be used as a part of normal daily operations

• The content of the reference data files are described in OSLMIT

401 Reference Data

• Access to the FTP/SFTP is done trough the standard enablement

form

FTP/SFTP Reference data solution

• XSD schemas will soon be published to the delta site
• Sample files for XML and CSV files will be published mid April

ahead of CDS launch

• Username and password will be the same for CDS and

Production

• Old files will be moved to archive folders (5 days archive)
• Any address in the subnet of the enabled member IP will

have access

Enablement

Enablement

What you will need to decide, requirements for:

• CompIDs
• TraderGroups
• FIX / Native
• Auto cancel on disconnect, different tradetypes
• What kind of market data information do you need
• Everyone will by default be set up with one Drop Copy and
• ne Post Trade user, you can request for more
• Everyone will by default be set up with one Trade Only user

per relevant Trade Only gateway

76

Participant structure

77

Member ID

Node

FIX Trading GW (CompID)

TraderGroup (entered via FIX)

Native trading user (TraderGroup) FIX PostTrade user FIX DropCopy user

Trader IDs / Type of trading activity

Enablement – Post Trade & Drop Copy

• Enable yourself or GCMs/custodians/etc. to receive copies of

all or some of your orders and/or trades

78

Testing

Testing - CDS

• Go-live in May
• ISVs and vendors will be prioritized for enablement
• Order generator in place to make traffic
• 1-1.5 month with ”disturbance free” test environment
• ”Disturbance scripts” from end of June

80

Testing – disturbance scripts

From end of June

• Trading gateways failover (including Drop Copy and Post

Trade)

• Market data failover
• Market data sequence number gaps
• Service interruption during Own Order Book Download
• Please refer to OSLMIT 501 Testing for more information, the document

will be made available before CDS go-live

81

Testing - conformance

• ”Self” certification
• You do the testing based on written instructions from our

Delta web

• You tell us when you’re done
• We check our logs to conform
• Both mandatory and optional steps
• Your application will have to be conformed before a

customer may use it in production!

• Please refer to OSLMIT 502 Guide to Application Certification for more
• guidance. Will be made available before CDS go-live

82

Testing – high volume tests

• Two times a week, after EOD of regular market
• Not mandatory, but remember the limitations of rerequest!

83

Testing – dress rehearsals

• Have to be conformed to continue
• All enablement should be done in advance
• 3 DRs

84

Network

MIT Network changes

• Multicast delivered in two

separate streams with full

• diversity. The two streams

carry identical data

• This is a mechanism to

reduce the need to centrally re-request lost packets with tcp

• A missing packet should be

retrieved from stream B if it is missing on stream A

Some importantant notes:

• Stream A and B should be delivered with full diversity all the

way to the trading application. This is important to plan when implementing Millennium infrastructure with regards to switches and routers

• Intra-second microbursts will be atleast twice as high due to

the much faster trading plattform

• 2*20 Mbps (one for each stream) will be sufficient for all

services, but low bandwidths will make routers buffers very

• critical. Buffering also adds latency
• Packetlosses must be avoided due to stricter rules for re-

requests of missed data in Millennium compared to TradElect

• More info in OSLMIT 602 Network Guide

Any questions?