Oslo Børs Holding · This document has been produced by Oslo Børs to assist customers in the use of the Millennium platform on the Oslo Børs market place. Part of the documentation

Millennium Exchange - Oslo Børs cash equities and fixed income markets

OSLMIT 302 FIX/FAST

Issue 4.2 28 April 2015

Oslo Børs | OSLMIT 302 FIX/FAST 2

Important note This document has been produced by Oslo Børs to assist customers in the use of the Millennium platform on the Oslo Børs market place. Part of the documentation is based on documentation from Millennium IT and the London Stock Exchange Group. Where the document title includes a number (i.e. OSLMIT 201), the number corresponds to similar documentation from The London Stock Exchange and/or from Borsa Italiana. For more details, please see references in the appendix. If you have any general queries relating to this document, please email: [email protected] Further copies of this document can also be downloaded from the Oslo Børs website: http://www.oslobors.no/ob_eng/Oslo-Boers/Trading/Trading-systems/Millennium-Exchange/Technical-documentation

Disclaimer This document has been prepared on the basis of the best information available. Oslo Børs has taken reasonable efforts to ensure that the information in this publication is correct at the time of publication, but shall not be liable for decisions made in reliance on it. Oslo Børs will seek to provide notice to customers of changes being made to this document, but this notice cannot be guaranteed. Therefore, please note that this publication may be updated at any time. The information contained is therefore for guidance only. This document does not form part of the contractual documentation between the Oslo Børs and its customers.

mailto:[email protected]


Change log This document can be updated at any time, and has been through the following iterations: Issue Date Description

4.0 01 December 2014 New release of the document to include all North Sea changes. 4.1 23 February 2015 Added Yield as a possible PriceType in the Security Definition

message.

4.2 28 April 2015 Removed references to the Burgundy market. Updated description of the field HaltReason.

Please note that only the latest issue of this document will be available from the Oslo Børs website. Details of the changes made in each issue since issue 4.0 of the document are described in the appendix.

Changes from the previous issue of the document are indicated by a left margin bar.


Content Important note ........................................................................................................................................ 2

Disclaimer ................................................................................................................................................ 2

Change log ............................................................................................................................................... 3

Content .................................................................................................................................................... 4

1. Introduction ..................................................................................................................................... 9

1.1 Purpose .................................................................................................................................... 9

1.2 Readership ............................................................................................................................... 9

1.3 Document Series ..................................................................................................................... 9

1.4 Definitions, Acronyms and Abbreviations ............................................................................. 11

2. Overview ........................................................................................................................................ 12

2.1 FIX/FAST Standard ................................................................................................................. 12

2.1.1 Frame Length Encoding .................................................................................. 12

2.2 Gateway Overview ................................................................................................................ 13

2.2.1 Snapshot Services .......................................................................................... 13

2.2.2 Fixed Income Incremental Service ................................................................... 13

2.2.3 Central Bank Incremental Service .................................................................... 14

2.2.4 Full Days Incremental Recovery (File Based) ..................................................... 14

2.3 IP Addresses and Ports .......................................................................................................... 14

2.4 Business parameters for the services .................................................................................... 14

2.5 Technical parameters for the services .................................................................................. 14

3. Service Description ........................................................................................................................ 15

3.1 Architecture ........................................................................................................................... 15

3.1.1 Real-Time Channel ......................................................................................... 15

3.1.2 Recovery (Snapshot) Channel .......................................................................... 16

3.1.3 Replay Channel .............................................................................................. 17

3.2 Message Overview ................................................................................................................ 18

3.3 Overview of a Trading Day .................................................................................................... 19

3.3.1 Trading on the Order Book .............................................................................. 19

3.3.2 Trade Reporting ............................................................................................. 19

3.3.3 List of Instruments ......................................................................................... 19

3.3.4 Trading Status ............................................................................................... 20

3.3.5 Intra-day Auction Call ..................................................................................... 20

3.3.6 No Active Session .......................................................................................... 21


3.3.7 Trading Halt .................................................................................................. 21

3.3.7.1 Temporary Halt .......................................................................................................... 21

3.3.7.2 Longer Term Halt ....................................................................................................... 21

3.3.8 Instrument Suspension ................................................................................... 22

3.3.9 Intra-Day Session Updates .............................................................................. 22

3.3.9.1 Extension of an Auction Call Session ......................................................................... 22

3.3.9.2 Adjustment by Market Operations ............................................................................ 22

3.3.10 New Instruments ........................................................................................... 23

3.4 Order Book Management (Price Depth) – Equity/ETF/Warrant ........................................... 23

3.4.1 Snapshot ...................................................................................................... 23

3.4.2 Market Orders ............................................................................................... 23

3.5 Order Book Management (Order Depth) – Fixed Income Services ....................................... 23

3.5.1 Incremental Refresh ....................................................................................... 24

3.5.2 Adding an Order ............................................................................................ 24

3.5.3 Updating an Order ......................................................................................... 24

3.5.4 Deleting an Order .......................................................................................... 25

3.5.5 Named Orders ............................................................................................... 25

3.6 Trade Management ............................................................................................................... 25

3.6.1 Auction Trades............................................................................................... 25

3.6.2 Off-Book Trades ............................................................................................. 26

3.6.2.1 Distributing Settlement Date on Market Data .......................................................... 26

3.6.3 Pegged Order Trades ...................................................................................... 26

3.6.4 Trade Cancellation ......................................................................................... 26

3.7 Indicative Auction Information ............................................................................................. 27

3.8 Statistics................................................................................................................................. 27

3.9 Updating Statistics on Trade Cancellations ........................................................................... 32

3.10 Updating and Publishing Statistics as per Market Segment – Fixed Income ........................ 33

3.10.1 Fixed Income Automatch Segment ................................................................... 33

3.10.2 Fixed Income – SE Retail Segment ................................................................... 35

3.10.3 Fixed Income – SE Wholesale Segment ............................................................. 36

3.10.4 Fixed Income Call Segment ............................................................................. 37

3.10.5 Fixed Income ABM Segment ............................................................................ 38

3.10.6 Fixed Income – NO Telephone Segment ............................................................ 39

3.10.7 Fixed Income – SE Telephone Segment ............................................................ 39

3.10.8 Fixed Income Issuing Auction Segment ............................................................. 40

3.10.9 Fixed Income Buy Back Auction Segments ........................................................ 40


3.10.10 Nibor segment ............................................................................................... 40

3.11 Updating Statistics as per Market Segment – Equity ............................................................ 41

3.11.1 Off-Book ....................................................................................................... 41

3.11.2 Normal Book ................................................................................................. 41

3.12 Price Field Interpretation ...................................................................................................... 41

4. Data Loss Detection and Management ......................................................................................... 42

4.1 How to Detect Data Loss ....................................................................................................... 42

4.2 Data Loss Management Using Backup Feed Arbitration ....................................................... 42

4.3 Data Loss Management Using TCP Based Services ............................................................... 42

4.3.1 Usage Limitations........................................................................................... 42

4.3.2 Login and Authentication................................................................................. 42

4.3.3 Passwords ..................................................................................................... 43

4.3.4 Establishing a connection ................................................................................ 43

4.3.5 Termination of the Connection ......................................................................... 44

4.4 The Replay Channel ............................................................................................................... 44

4.4.1 Requesting Missed Messages ........................................................................... 44

4.4.2 Response to a Retransmission Request ............................................................. 45

4.4.3 Cancelling of a Retransmission Request ............................................................ 45

4.5 The Recovery Channel ........................................................................................................... 45

4.5.1 Requesting Instrument ................................................................................... 45

4.5.2 Requesting Snapshot: Order Book and Statistics ................................................ 46

4.5.3 Requesting Missed Trades ............................................................................... 47

4.5.4 Cancelling a Request ...................................................................................... 48

4.6 Handling System Level Failures ............................................................................................. 48

4.6.1 Snapshots on the Real-Time Channel ................................................................ 48

4.6.2 Resetting Sequence Numbers .......................................................................... 48

5. Message Formats and Templates .................................................................................................. 50

5.1 Variations from the FIX Protocol ........................................................................................... 50

5.2 Header ................................................................................................................................... 53

5.2.1 FIX Message .................................................................................................. 53

5.2.2 FAST Template .............................................................................................. 53

5.3 Administrative Messages ...................................................................................................... 54

5.3.1 Logon ........................................................................................................... 54

5.3.2 Logout .......................................................................................................... 55

5.3.3 Heartbeat ..................................................................................................... 55


5.4 Application Messages (Client-Initiated) ................................................................................ 56

5.4.1 Security Definition Request ............................................................................. 56

5.4.2 Market Data Request - Equity .......................................................................... 57

5.4.3 Market Data Request – Fixed Income ............................................................... 60

5.4.4 Application Message Request ........................................................................... 63

5.5 Application Messages (Server-Initiated) ............................................................................... 64

5.5.1 Security Definition - Equity .............................................................................. 64

5.5.2 Security Definition – Fixed Income ................................................................... 67

5.5.3 Security Status - Equity .................................................................................. 70

5.5.4 Security Status – Fixed Income ....................................................................... 72

5.5.5 Market Data Snapshot (Full Refresh) ................................................................ 74

5.5.6 Market Data Incremental Refresh – Fixed Income .............................................. 81

5.5.7 Market Data Incremental Refresh – Equity ........................................................ 89

5.5.8 Market Data Request Reject ............................................................................ 96

5.5.9 Business Message Reject ................................................................................ 97

5.5.10 Application Message Request Ack ..................................................................... 98

5.5.11 Application Message Report ............................................................................. 99

6. Trading Halt Reason Codes .......................................................................................................... 100

7. Reject Codes ................................................................................................................................ 100

7.1 Market Data Request Reject ............................................................................................... 100

7.2 Business Message Reject ..................................................................................................... 100

8. Scenarios ..................................................................................................................................... 101

8.1 Specific Market Data request .............................................................................................. 101

8.1.1 Order Book snapshots for a segment .............................................................. 101

8.1.2 Statistics snapshots for a segment ................................................................. 101

8.1.3 Missed trades for a segment .......................................................................... 102

8.1.4 Order Book Snapshots for an Instrument ........................................................ 102

8.1.5 Statistics snapshots for an Instrument ............................................................ 102

8.1.6 Missed trades for an Instrument .................................................................... 102

8.2 Multiple Market Data request ............................................................................................. 103

8.2.1 Multiple Market Data (Order Book, Trades, Statistics) for a Single Instrument ..... 103

8.2.2 Multiple Market Data (Order Book, Trades, Statistics) for a Segment .................. 103

Appendix 1 – Issue Updates ................................................................................................................ 105

Issue 4.0 – Released 01 December 2014 ......................................................................................... 105

Issue 4.1 – Released 23 February 2014 ........................................................................................... 105


Issue 4.2 – Released 28 April 2015 .................................................................................................. 105

Appendix 2 – References ..................................................................................................................... 106


Book

1. Introduction Since November 2012, the Millennium Exchange trading system has been the trading platform in use for Oslo Børs equity and fixed income markets. Millennium Exchange is a flexible, highly scalable trading platform with ultra-low latency developed by MillenniumIT, a company in the London Stock Exchange Group. Oslo Børs and its market places for equities and fixed income aims at maintaining its competitive position, and is pleased to offer customers an upgraded release of the state-of-the-art trading system as of April 2015. 1.1 Purpose The purpose of this document is to describe the services provided by the FIX/FAST market data gateways available on the Millennium Exchange platform. 1.2 Readership This document describes how to connect to the FIX/FAST market data gateways and the detailed messages and fields used. The reader should be familiar with these documents prior to reading this specification:

• Oslo Børs Market Model Equities • Oslo Børs Market Model Fixed Income • Oslo Børs Market Model Nibor

Messages are highlighted in bold text in this document. Fields within messages are indicated by use of italic letters. References to other documents in the document series are indicated by use of underlined italic letters. 1.3 Document Series This document is a part of a series of documents providing a holistic view of full trading and information services available from Oslo Børs post the migration to the Millennium Exchange platform. The current series of documents are outlined below: General OSLMIT Oslo Børs Market Model Equities OSLMIT Oslo Børs Business Parameters - Equities OSLMIT Oslo Børs and Nordic ABM Market Model Fixed Income OSLMIT Oslo Børs and Nordic ABM Business Parameters – Fixed Income OSLMIT Oslo Børs Market Model Nibor OSLMIT Oslo Børs Business Parameters - NIBOR Trading OSLMIT 201 Guide to New Trading System OSLMIT 202 FIX Trading Gateway (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 MITCH Gateway OSLMIT 306 FIX/FAST News and Indices Gateway OSLMIT 401 Reference Data OSLMIT Derived Information Guidelines Other OSLMIT 501 Guide to Testing Services OSLMIT 502 Guide to Application Certification OSLMIT 504 Guide to Dress Rehearsals (only relevant to migration projects) OSLMIT 505 Guide to Go-live (only relevant to migration projects) OSLMIT 601 Guide to Trading Services Disaster Recovery OSLMIT 602 Network Guide OSLMIT 604 Technical Parameters OSLMIT 605 Live Environment Connectivity OSLMIT 606 CDS Environment Connectivity OSLMIT 808 Reject Codes The latest version of this documentation series can be found on: http://www.oslobors.no/ob_eng/Oslo-Boers/Trading/Trading-systems/Millennium-Exchange/Technical-documentation


1.4 Definitions, Acronyms and Abbreviations Acronyms/ Abbreviations Description MBP(20) Market By Price, 20 levels MBO Market By Order VWAP Volume weighted average price. For equity instruments the VWAP is

based on automatic trades only, while for fixed income instruments the VWAP is based on automatic trades and ordinary Off Book trades, explained in the statistics chapter.

LTP Last traded price. Pre calculated for fixed income instruments only. Nibor Norwegian interbank offered rate IDR Indicative deposit rate. Represents an indicator of the interest rate

that panel bank will demand for loans in NOK to another leading bank which is active in the Norwegian money market and foreign exchange market.

IDR Average Indicative deposit rate average. The calculation is based on indicative deposit rates submitted by the Nibor panel banks and follows the same pattern for inclusion/deletion of orders in the calculation as for Nibor. Separate ticker code from the official fixing rates.

Finans Norge Association representing Norwegian financial organizations and responsible for the Nibor-rules.

Panel bank A market participant enabled to submit orders to the indicative deposit rate instruments in the Nibor market.


2. Overview Oslo Børs offers two protocols for market data within the trading system Millennium Exchange. The more efficient, but slimmer MITCH protocol available for equities only, is described in the OSLMIT 303 MITCH Gateway document, while this document describes the richer FIX/FAST market data gateways available for equities, fixed income and statistics. With exception of MITCH, each Oslo Børs market data feed in Millennium Exchange is a stream of FAST encoded FIX messages which will provide one or more of the following real-time information for each instrument traded on Oslo Børs market:

• Price depth information (MBP20) for the order book as snapshots. The feed provides information on the aggregated displayed quantity and the number of displayed orders per price point for a book depth provided by each market data service. (For equities, warrants and ETPs only).

• Order depth information (MBO full depth) for the order book. The feed provides information on the price and displayed quantity of each order for a book depth provided by each market data service. The order information also includes trading participants. (For fixed income only). Please refer to OSLMIT Oslo Børs and Nordic ABM Market Model Fixed Income for information on to whom this information may be made available.

• Price, volume, trade type and time for each executed trade. • Indicative auction price and the associated trade volume. • Statistics (e.g. high/low, volume, VWAP, etc.). • Trading status.

In addition, each feed enables participants to download the instrument reference data described in OSLMIT 401 Reference Data, available in CSV and XML format. 2.1 FIX/FAST Standard The feed is a multicast service based on the technology and industry standards UDP, TCP, IPv4, FAST and FIX. The application messages are defined using the FIX 5.0 (Service Pack 2) standard and comply with the best practices outlined by the FIX Market Data Working Group. Where the Oslo Børs implementation of FIX/FAST deviates from the FIX standard, this is outlined in a separate chapter of this document. The data feed is transmitted in the FAST v1.1 encoding method to minimize bandwidth and reduce latency and conforms to Level 1 of the FAST 1.1 specification. 2.1.1 Frame Length Encoding Each FIX/FAST message is preceded by a stop bit encoded frame length specifier. The use of the frame length specifier applies to messages published on UDP, as well as messages from the TCP-based replay/recovery services. Clients are also required to include a frame length specifier in messages sent to the server. The frame length is represented using 1 or more bytes. The most significant bit serves as an indicator of the last byte in the sequence of bytes representing the frame length. Example:


00000001 10001011 After removing stop bits, we have: 0000001 0001011 When converted to decimal, we get: 00000010001011 = 139 In this case, the frame size is 139 bytes, meaning that 139 bytes of FIX/FAST encoded message data will now follow. 2.2 Gateway Overview The feed is load balanced by Market Data Group. Each Market Data Group contains the Instruments in one or more of the market segments. For instance, there is one Market Data Group that covers all equities. When launched the Oslo Børs FIX/FAST Gateways will be the following: Equities and related

• Level 2 Equity Snapshot Service – FIX/FAST (MBP 20) • Level 2 Warrants Snapshot Service – FIX/FAST (MBP 20) • Level 2 ETF Snapshot Service – FIX/FAST (MBP 20)

Fixed income:

• Fixed Income Incremental Service (MBO Full Depth)- FIX/FAST • Full Days Recovery - Fixed Income Incremental Service (MBO Full)- FIX/FAST- (file based - no intraday

access to clients) • Full Depth Service Central Bank Gateway (MBO Full) – FIX/FAST • Fixed Income Trade only Gateway – FIX/FAST

There are also some differences in the valid messages and valid enumerations for the message used by the two gateway types. These differences are described in detail later in this document. 2.2.1 Snapshot Services For equity related the FIX/FAST Market Data Feed offers snapshot services with “Market by Price 20 levels” (MBP20). One snapshot based gateway is available per each of the following Market Data Groups; equities, warrants and ETFs. Orders are transmitted via the Market Data Snapshot Full Refresh message, while trades and statistics are transmitted via the Market Data Incremental Refresh message. 2.2.2 Fixed Income Incremental Service For fixed income instruments the FIX/FAST offers an incremental full depth gateway available for order book updates (bid/offers) and a separate incremental trade only gateway available for trade and statistics information. The trades and orders are split into the two separate incremental gateways due to transparency requirements. Both the order book updates, trades and statistics are transmitted via the Market Data Incremental Refresh Message in the incremental services. The incremental full depth gateway does not


contain order book updates for instruments listed in the Issuing and Buy-back segments, as government bond auctions are part of a separate Central Bank gateway service. The Trade Only Gateway offers full day recovery of all trades. 2.2.3 Central Bank Incremental Service Due to special transparency needs in the auctioning of new or existing government bonds and government bills the Central Bank has a separate service available. The Central Bank service offers a full depth incremental service transmitted via the Market Data Incremental Refresh message. This service does not hold any trade or statistics information. 2.2.4 Full Days Incremental Recovery (File Based) During the trading day the activity in the fixed income full depth incremental service is stored on an SFTP server for a full day recovery file. The file is not accessible during the day, but clients can access the file after end of day (EOD) in case of a major data loss. The availability and interface to access these files will be made available in a revised version of this document details prior to the opening of the customer development service environment (CDS). 2.3 IP Addresses and Ports IP addresses and ports for the services provided as part of the market data feed are specified in the following documents:

OSLMIT 605 Live Environment Connectivity OSLMIT 606 CDS Environment Connectivity

2.4 Business parameters for the services Details about opening hours, trading sessions etc. are specified in OSLMIT Oslo Børs and Nordic ABM Market Model Fixed Income and OSLMIT Oslo Børs Market Model Equities. 2.5 Technical parameters for the services There are certain technical parameters that apply to the connection-oriented services provided by the market data feed. Examples include:

• Timeouts • Usage limitations per day • Maximum number of concurrent requests • Cache sizes

The parameter values are included in the OSLMIT 604 Technical Parameters document.


3. Service Description 3.1 Architecture The FIX/FAST Market Data feed is load balanced by Market Data Groups. While each group will contain multiple instruments, each instrument is assigned to just one Market Data Group. While the group an instrument is assigned to may change from day to day, it will not change within a day. Each Market Data Group will use a unique real-time multicast channel for dissemination of real-time market data The Security Definition messages published on the real-time channel of the various Market Data Groups may be utilized by clients to identify the Instruments assigned to each group. Two TCP channels are available per Market Data Group; recovery and replay. While a recipient may connect to the replay channel to recover from a small data loss, it should use the recovery channel after a large data loss (i.e. late joiner, major outage, etc.). 3.1.1 Real-Time Channel The real-time channel is the primary means of disseminating market data. Real-time updates to instruments and all market data supported by the feed are available on this multicast channel. The list of active instruments in the Market Data Group will be broadcast at the start of the trading day via the Security Definition message. Real-time updates of the trading status of instruments will be disseminated via the Security Status message. Real-time updates to order books will be published via the Market Data Incremental Refresh – Fixed Income or the Market Data Snapshot (Full Refresh) message depending on the service which provides the data. Oslo Børs has incremental FIX/FAST services for fixed income instruments, while for equity related instruments Oslo Børs offer snapshot services for order book updates. The message used in the real-time channel will depend on the order book and the statistics update type of the market data service. If the update type is incremental, the data will be published via Market Data Incremental Refresh message while the Market Data Snapshot (Full

Market Data Group (Main Site)

Real-Time Channel A

(UDP)

Recovery Channel (TCP)

Replay Channel (TCP)

Instruments,Order Book Updates,

Trades,Indicative Auction Info,

Statistics Updates,Trading Status,Announcements

Recipients

Order Book,Statistics, Trades,

Trading Status,Instruments

Missedincremental

updates

Market Data Group (Backup Site)

Real-Time Channel B

(UDP)

Recovery Channel (TCP)

Replay Channel (TCP)

Instruments,Order Book Updates,

Trades,Indicative Auction Info,

Statistics Updates,Trading Status,Announcements

Order Book,Statistics, Trades,

Trading Status,Instruments

Missedincrementalupdates andsnapshots

MissedMessagerequest

MissedMessagerequest


Refresh) will disseminate data if the update type is snapshot. Real-time updates disseminated in snapshots will be disseminated every 100 milliseconds given changes have occurred in the relevant data. Real-time updates to trades, statistics and indicative auction information will be published via the Market Data Incremental Refresh – Fixed Income message or the Market Data Incremental Refresh – Equity messages depending on the service which provides the data. Fixed income services will use the Market Data Incremental Refresh – Fixed Income whereas equity/ETF/warrant services will use the Market Data Incremental Refresh – Equity message. While each Market Data Incremental Refresh – Fixed Income, Market Data Incremental Refresh - Equity and Market Data Snapshot (Full Refresh) messages includes a channel specific message sequence number in the field ApplSeqNum(1181), each market data entry in the message includes an instrument specific sequence number in the field RptSeq(83). The channel and instrument level sequence numbers are to reset to “1” at the start of each day. The server will use the Heartbeat message to exercise the communication line during periods of inactivity on the real time channel. The heartbeat frequency is defined in the OSLMIT 604 Technical Parameters document. The Heartbeat message will contain the field ApplNewSeqNum(1399), which will populate the next expected application sequence number to enable recipients to detect gaps on the Real-Time channel. Clients have access to two identically sequenced real-time feeds: one from the main feed (Feed A) and one from the backup feed (Feed B). Clients need to process both feeds and arbitrate between them to minimize the probability of a data loss. Clients should be aware of the fact that there will be some additional latency on Feed B. If arbitration is not used, or if data loss occurs on both feeds, clients may utilize the connection oriented, TCP based data loss management services that are part of this system. Although this service exists the clients should note that there are limitations to the extent of the use of service. The service is described briefly below, and in detail in section 4. 3.1.2 Recovery (Snapshot) Channel The TCP recovery channel permits recipients to request a snapshot of the order book and statistics for any active instrument in the Market Data Group as well as its current trading status. It enables recipients to request the retransmission of the trades published during the last minutes (the applicable number of minutes per gateway are defined in the OSLMIT 604 Technical Parameters document) on the real-time channel. The recovery channel also enables recipients to download the list of active instruments in the Market Data Group. This channel may be used by recipients to recover from a large-scale data loss. All messages sent by the server are transfer encoded in terms of the FAST protocol. While all application messages sent by the server (e.g. Market Data Snapshot (Full Refresh)) are field encoded, the administrative messages it sends (e.g. Logon, Heartbeat, etc.) are not. All messages (i.e. both administrative and application) initiated by the client should be transfer encoded, but not field encoded. While a recovery channel is available from the backup feed, it will only be activated in the unlikely event of an outage at the main site.


3.1.3 Replay Channel The TCP replay channel permits recipients to request the retransmission of a limited number of messages already published on the real-time channel. This channel may be used by recipients to recover from a small data loss. The replay channel supports the retransmission of the last messages published on the real-time channel. The number of messages available is defined in the OSLMIT 604 Technical Parameters document. For fixed income incremental gateway the number of messages is expected to cover the entire trading day, however it is not expected to cover the entire day for the equity related snapshot gateways. The replay channel does not support the retransmission of messages published on the recovery channel or from previous trading days. All messages sent by the server are transfer encoded in terms of the FAST protocol. While all application messages sent by the server (e.g. Market Data Incremental Refresh, Security Definition, etc.) are field encoded, the administrative messages it sends (e.g. Logon, Heartbeat, etc.) are not. All messages (i.e. both administrative and application) initiated by the client should be transfer encoded but not field encoded. For the message types containing fields using the Copy or Tail operators, the first messages in a retransmission will include all necessary values. While a replay channel is available from the backup feed, it will only be activated in the unlikely event of an outage at the main site.


3.2 Message Overview The market data feed utilizes the FIX application messages described below to disseminate instruments, market data, and market announcements. Message

Description Usage (By Channel)

Real-time Recovery Replay Security Definition Used to disseminate details (e.g.

status, ISIN etc.) on all active Instruments. Each message will only contain the details of one Instrument.

√ √ √

Security Status Used to communicate the trading status (e.g. Opening, Regular Trading, Halt, etc.) of Instruments.

√ X √

Market Data Incremental Refresh - Equity

Used to provide the below in equity services: Information on an executed trade. The indicative auction information (e.g. price etc.) Statistics (e.g. low, high, volume, VWAP, etc.). A single message may contain multiple market data entries which may cover one or more instruments

√ √ √

Market Data Incremental Refresh – Fixed Income

Used to provide the below in fixed income services: An update to the order book. Information on an executed on or off-book trade. The indicative auction information (e.g. price etc.). Statistics (e.g. low, high, volume, VWAP, etc.). A single message may contain multiple market data entries which may cover one or more instruments.

√ √ √

Market Data Snapshot (Full refresh)

Used to disseminate a snapshot of the order book for an instrument in equity services.

√ √ √


3.3 Overview of a Trading Day

3.3.1 Trading on the Order Book The regular day for on book trading will, consist of many scheduled sessions: Pre Trading (Start of Trading), Opening Auction Call, Regular (Continuous) Trading, Re-Opening Auction Call, Closing Auction Call, Post Close etc. The start time for each of these sessions may vary from one set of Instruments to another. The hours for when the different types of periods will be active are defined in the OSLMIT Oslo Børs Market Model Equities and OSLMIT Oslo Børs and Nordic ABM Market Model Fixed Income. To indicate the start of the different sessions Security Status messages will be published on the Real-time channel to indicate when a particular session has commenced for an Instrument. However, Security Status message will not be transmitted when an Instrument is reinstated or put back to the same session after ending it manually. The Security Status messages that will be published for on book trading will have MDSubBookType(1173) of On-Book (1). For Bulletin Board, it will have MDSubBookType(1173) of Bulletin Board (9). Security Status messages disseminated with RoutingInst (9303) of Dark Midpoint Order Book(M) indicates that the liquidity pool is the Dark Midpoint Order Book. 3.3.2 Trade Reporting At the start of the reporting period a Security Status message, with a SecurityTradingStatus(326) of Start Trade Reporting(17) and an MDSubBookType(1173) of Off-Book(2), will be broadcast for each instrument for which trade reporting is permitted. At the start of the Post Close session for the trade reporting the system will publish a Security Status message with SecurityTradingStatus (326) of Post Close (26) and an MDSubBookType (1173) of Off-Book (2). Similarly, a Security Status message with a SecurityTradingStatus (326) of End of Post Close (103) and an MDSubBookType (1173) of Off-Book (2) will be broadcast for each instrument at the end of the Post Close period, denoting the end of publication of all delayed trades. A Security Status message, with a SecurityTradingStatus(326) of Market Close (18) and an MDSubBookType(1173) of Off-Book (2), will be broadcasted for each such instrument at the market close. The hours for when the different periods will be active are defined in the OSLMIT Oslo Børs Business Parameters – Equities and OSLMIT Oslo Børs and Nordic ABM Business Parameters – Fixed Income. 3.3.3 List of Instruments A Security Definition message will be broadcast for each active and suspended Instrument on the real-time channel a configurable number minutes after the start of day. The system will publish separate Security Definition messages for the Lit Order Book and the Dark Midpoint Order Book. Recipients can distinguish the books via the field RoutingInst (9303). Please refer to OSLMIT 604 Technical Parameters for more information about when this message is published.


3.3.4 Trading Status Security Status message will disseminate the status changes in the marketplace real-time. Security Status message will also indicate whether the status changes take place in the on book, Dark Midpoint Order Book or off book. 3.3.5 Intra-day Auction Call In some segments, Intra-day Auctions take place at one or more scheduled times during a trading day, in addition to any Opening and Closing Auction Calls. An Intra-day Auction will interrupt the Regular Trading session for the instrument, run for the scheduled duration, uncross, and then move the instrument back to Regular Trading. The uncrossing will take place on a random time from the scheduled end of the auction call, subject to any Price Monitoring or Market Order Extensions see OSLMIT Oslo Børs Market Model Equities for further details. At the start of the Intra-day Auction session the system will publish a Security Status message with SecurityTradingStatus(326) of Intra-day Auction (127) and an MDSubBookType(1173) of On-Book (1). When the instrument uncross at the end of the Intra-day Auction, a Security Status message with SecurityTradingStatus(326) of Regular Trading (17) will be disseminated.


3.3.6 No Active Session If a snapshot of the Trading Session of an Order Book is published, “No Active Session” (199) should be used when a Trading Session is not currently active for the Order Book. The Real-time channel will disseminate snapshot messages with “No Active Session” status when:

a) An Order Book or statistics snapshot is sent on the Real-time channel due to a failover. b) A trading status snapshot is sent on the Real-time channel due to a failover. c) An Order Book or statistics snapshot is sent on the Real-time channel due to a command from

gateway control. d) A trading status snapshot is sent on the Real-time channel due to a command from gateway control.

3.3.7 Trading Halt An Instrument may be halted during the day. Oslo Børs may institute two types of Trading Halts for an Instrument: a temporary halt that will not carry over to the next day or a longer term halt that spans across Trading Days (e.g. regulatory halt). 3.3.7.1 Temporary Halt An Instrument may be temporarily halted manually by Market Supervision. Trading of an Instrument being manually halted could be resumed via re-opening Auction Call for on-book trading and to any desired off-book Trading Session for Trade Reporting. The Security Status message will be published to indicate when a particular Instrument is halted manually. The Security Status message will be published with Halt (2) as the SecurityTradingStatus(326). The reason for the halt and whether it applies to on-book trading or Trade Reporting will be specified in the HaltReason(327) and MDSubBookType(1173)fields respectively. When trading is resumed a Security Status message will be published with the SecurityTradingStatus(326) indicating Re-open Auction Call (104) and MDSubBookType(1173)of On–Book (1) for on book trading. For Bulletin Board, you will receive a SecurityTradingStatus(326) indicating Order Entry (113) and MDSubBookType(1173) of Bulletin Board (9). When trading is resumed for Trade Reporting a Security Status message will be published with the current trading status and MDSubBookType(1173)of Off- Book (2). A temporary Trading Halt may not be carried forward to the next Trading Day. Please note that if HaltReason(327) is received with the value Reference Data Update(6), this means that new reference data files are made available on the SFTP/FTP server. This may happen if, for whatever reason, an instrument is missing from the reference data files, but is available in the trading system. 3.3.7.2 Longer Term Halt A Security Definition message, with a SecurityStatus(965) of Halted (8), will be published if an Instrument is halted across multiple days. A Security Status, with a SecurityTradingStatus(326) of Halt (2), will also be


published for each MDSubBookType(1173)associated with the Instrument (i.e. on-book, off-book, etc.). If, at the start of a Trading Day, an Instrument is still in a halted state it will be included in the Security Definition messages published by the server. A Security Status, with a SecurityTradingStatus(326) of Halt (2), will also be published for each associated MDSubBookType(1173)at the start of the first scheduled session (i.e. Pre-Trading). A Security Definition message, with a SecurityStatus (965) of Active (1), will be published if the halt is lifted during trading hours. Separate Security Status messages will also be published if on-book trading and/or trade reporting are resumed for the instrument. A longer term trading halt may be carried forward to the next trading day. 3.3.8 Instrument Suspension An Instrument may be suspended during or outside trading hours. The suspension may be lifted later in the day or it may be carried forward to subsequent trading days. A Security Definition message with a SecurityStatus(965) of Suspended (9) will be published if an instrument is suspended during the trading day. A suspension applies to on-book trading only. If, at the start of a trading day, an instrument is still in a suspended state it will still be included in the Security Definition message published by the server. A Security Definition message with a SecurityStatus(965) of Active (1), will be published if the suspension is lifted during trading hours. Separate Security Status messages will also be published if on-book trading is enabled for the instrument with the SecuritTradingStatus(326), Regular Trading (17) and MDSubBookType(1173)of On-Book (1). 3.3.9 Intra-Day Session Updates Daily scheduled sessions can be altered by market events, either by extension of an Auction Call or other adjustments by Market Operations at Oslo Børs. 3.3.9.1 Extension of an Auction Call Session An Auction Call session (e.g. Opening auction etc.) may be extended due to a market order imbalance or if the current auction price is significantly different from the last sale, according to the OSLMIT Oslo Børs Market Model Equities. Upon such events, a Security Status message will be broadcast with the value Market Order Extension (1) or Price Monitoring Extension (100) in the field SecurityTradingEvent(1174). This message will indicate the new time at which the auction will take place in the Text(58) field and the current security status in SecurityTradingStatus(326). 3.3.9.2 Adjustment by Market Operations Oslo Børs may extend or shorten a particular trading session. In such a case, a Security Status message will be broadcast with the value Extended by Market Operations (101) or Shortened by Market Operations (102) in the field SecurityTradingEvent(1174). The message will indicate whether the change applies to on-book trading or trade reporting and the new time at which the session will end in the Text(58) field.


3.3.10 New Instruments New instruments may be created during the trading day. In such a case, the server will publish a Security Definition message to notify recipients of the details of the new instrument (instrument ID, segment etc.). Separate Security Status messages will also be published if on-book trading and/or trade reporting is enabled for the instrument. When you receive a Security Status message with HaltReason=Reference data update(6), this means that new reference files are made available on the SFTP/FTP server. The new reference data of the new instrument will be available in the csv and xml change-files described in OSLMIT 401 Reference data. 3.4 Order Book Management (Price Depth) – Equity/ETF/Warrant The Market Data feed provides recipients with a view of the order book, where all orders are aggregated at each price level for 20 price points. The feed provides the aggregate displayed quantity and the number of represented orders at each price level. Market orders (if any) shall contribute as the first price point. The limit orders shall then be ordered based on the price priority. This information is broadcast as a snapshot every 100 milliseconds if there is an update on the real-time channel. 3.4.1 Snapshot Market Data Snapshot (Full Refresh) messages will be used to disseminate the full picture of each order book. The snapshot will include the price, aggregate display quantity, number of orders and display position for each price level. A snapshot will be published even if there are no orders in the order book. In such a case, the Market Data Snapshot (Full Refresh) message will include an MDEntryType(269) of Empty Order Book (J). An order book snapshot may span across multiple Market Data Snapshot (Full Refresh) messages. In such cases, the LastFragment(893) field will be “N” for all but the final message for the instrument. The final message will include a LastFragment(893) of “Y”. 3.4.2 Market Orders The aggregate displayed quantity of market orders, if any, on each side of the order book, along with the number of represented orders, is disseminated during each Auction Call session. Market orders will only reside on the order book during Auction Call sessions. In the case of market orders, the relevant market data entry of a Market Data Snapshot (Full Refresh) message will include an MDEntryType(269) of Market Bid (b) or Market Offer (c). Such entries will not include an MDPriceLevel(1023) or an MDEntryPx(270). However, in case of publishing a limited view of the current order book in Level 2 Snapshot Service (equity, ETF and warrant), market orders will be considered as a separate price level. Hence, if the service is to disseminate a snapshot of 20 price points published market by price, the 20 price points to be disseminated will include the level of market orders as well. Hence, the market will disseminate market orders aggregated and another 19 price levels. 3.5 Order Book Management (Order Depth) – Fixed Income Services The market data feed provides recipients with a view of the full visible depth of the order book for the Oslo Børs fixed income market. The feed provides the price and displayed quantity of each order. This information is


broadcasted as incremental updates on the real-time channel. 3.5.1 Incremental Refresh A Market Data Incremental Refresh – Fixed Income message will be published to update the order book. A message may contain multiple market data entries each of which could add, change or delete an order. A single message may include entries for multiple instruments. Each entry includes an identifier of the order in the field MDEntryID(278). As this identifier is a unique identifier assigned to the order by the matching system, recipients will be able to identify their own orders while ensuring anonymity. MDEntryIDs are unique across all instruments and across trading days. The MDEntryID(278) can be mapped to the order ID on the FIX or Native Trading Gateways by conversion to ASCII, see OSLMIT 604 Technical Parameters for details. 3.5.2 Adding an Order When a new order is added to the order book a Market Data Incremental Refresh – Fixed Income message will be broadcast with an MDUpdateAction(279) of New (0). The message will include the price and displayed quantity of the order. While the field MDPriceLeve(1023) will indicate the display position of the price level the order is added to, the field MDEntryPositionNo(290) will indicate its position within the price level. Price levels are numbered from most to least competitive and start with “1”. Similarly, position numbers within a price level are numbered from most to least competitive and start with “1” for each price level. If the order is added at a new price level, all rows in the order book below the new price level should be pushed down. The recipient’s application should automatically re-number the price levels below the newly added price level. If, in terms of its MDEntryPositionNo(290), an order is added ahead of some existing orders at the price level, these orders should be pushed down. The recipient’s application should automatically re-number the position numbers of orders at the price level if they are below the newly added order. If MDPriceLevel(1023) is set to “1” the message will update the top of the order book. The recipient’s application should ensure that there are no prices better than this price level. Similarly, if MDEntryPositionNo(290) is set to “1” the message will update the top of the price level. The recipient’s application should ensure that there are no orders higher than this order at the price level. 3.5.3 Updating an Order A Market Data Incremental Refresh – Fixed Income message will be broadcast with an MDUpdateAction(279) of Change (1) if an existing order is updated without a loss of priority (e.g. a reduction in order quantity). The field MDEntryID(278) will indicate which order is being updated. The message will include the order’s price and updated display quantity. The relevant MDPriceLevel(1023) and MDEntryPositionNo(290) will also be provided. If the update of an existing order results in a loss of priority (e.g. an increase in order quantity, a change in price, etc.), the update will be communicated via two actions; a delete (as outlined below) followed by an addition.


3.5.4 Deleting an Order If an existing order is removed a Market Data Incremental Refresh – Fixed Income message will be broadcast with an MDUpdateAction(279) of Delete (2). The field MDEntryID(278) will identify the order being removed. Orders at the price level of the deleted order should be pushed up if they were below it. The recipient’s application should automatically re-number the position numbers of such orders. If the order was the only order at the price level, all rows in the order book below the deleted price level should be pushed up. The recipient’s application should automatically re-number the price levels that were below the deleted price level. The server will separately publish updates to add orders at the new price level at the bottom of the order book. 3.5.5 Named Orders The entry of a Market Data Snapshot (Full Refresh) message used to disseminate the details of a named order will include the identity of the submitting firm in the field PartyID(448). 3.6 Trade Management The market data feed provides recipients with the price, volume, trade type and time for each executed trade. Details of trade cancellations will also be broadcast. When a trade is executed a Market Data Incremental Refresh – Fixed Income / Market Data incremental Refresh – Equity (depending on the market and service) message will be broadcast with a MDUpdateAction(279) of New (0) and MDEntryType(269) of Trade (2). Each trade will include a unique trade ID in the field MDEntryID(278) which will be referenced if the trade is cancelled. The recipients will be able to identify their own trades with this Trade ID while ensuring anonymity as the same Trade ID will also be tagged in the trade capture reports (in tag 1003 – TradeID) carrying the relevant trade information in the Post Trade gateway. The trade price, quantity and time will be specified in the fields MDEntryPx(270), MDEntrySize(271) and MDEntryTime(273) respectively. The trade date (the execution date) too will be specified in the field MDEntryDate(272) when off-book trades are published. The side of the aggressor will be specified in the field AggressorSide(5797). For the Oslo Børs equities market, the counterparty details may be specified such as the buying party and the selling party in a trade in the fields MDEntryBuyer (288) and MDEntrySeller (289) respectively. For the Oslo Børs fixed income market the counterparty details will not be included. Trade IDs are unique across all instruments and across trading days. 3.6.1 Auction Trades The Market Data Incremental Refresh –Fixed Income/Market Data Incremental Refresh - Equity messages will contain a MatchType(574) of Auction (5) and a TradeCondition(277) of Opening Price (R), Re-Opening Price (w) or Closing Price (AJ) if the trade was executed in an Opening, Re-Opening or Closing Auction respectively. The auction results are sent out as individual trades through the market data via the Market Data Incremental Refresh – Fixed Income / Market Data Incremental Refresh – Equity for the fixed income and equities markets respectively.


3.6.2 Off-Book Trades In the case of an off-book trade, the trade type will be indicated in the TrdSubType(829) field of the Market Data Incremental Refresh – Fixed Income / Market Data Incremental Refresh – Equity message. The message will also include the date and time the trade was executed on the systems of the counterparties in the fields MDEntryDate(272) and MDEntryTime(273) respectively.

3.6.2.1 Distributing Settlement Date on Market Data Settlement date will be populated only for off book trades. Automatic trades follow the settlement cycle defined per instrument and described in the market models for equities and fixed income, while the settlement for off-book trades can deviate from the standard settlement cycle. The Millennium FIX/FAST protocol disseminates the off book (manual) trade information through the Market Data Incremental Refresh – Fixed Income / Market Data Incremental Refresh – Equity messages (depending on the market and service). In the FIX/FAST Fixed Income Market Data Gateway, if the trade type is not RE or DR (repo trade types) the Market Data Incremental Refresh – Fixed Income / Market Data Incremental Refresh – Equity message (depending on the market and service) should populate the FIX field SettlDate(64).

FIX tag Field Name Req Description

64 SettlDate N Date on which the trade will settle.

In the case of repo trades (OR and DR) two settlement dates must be specified when reporting the trade, StartDate(916), EndDate(917), whereas the StartDate defining the date of the sale and the EndDate defining the date of the repurchase.

FIX tag Field Name Req Description

916 StartDate N Indicates the first settlement date of the repo trade. (Required for repo trades)

917 EndDate N Indicates the second settlement date of the repo trade. (Required for repo trades)

Value specified in EndDate(917) may not be prior to the value specified in StartDate(916). 3.6.3 Pegged Order Trades In all the scenarios which involve pegged order executions, the trades should be disseminated via the FIX/FAST market data feed. When an aggressing order (pegged/non pegged) executes with a passive pegged order or if two passive pegged orders receive executions during pegged order re-evaluation, the trade should be communicated via the FIX/FAST market data feed. In this scenario a Market Data Incremental Refresh – Equity via the FIX/FAST feed should be disseminated. 3.6.4 Trade Cancellation If a trade is cancelled a Market Data Incremental Refresh – Fixed Income / Market Data Incremental Refresh – Equity message (depending on the market and service) will be broadcast with an MDUpdateAction(279) of Delete (2) and an MDEntryType(269) of Trade (2). The message will contain the Trade ID of the cancelled trade and the cancelled time in the fields MDEntryID(278) and MDEntryTime(273) respectively. TradeCondition(277)


field should not be tagged when reporting a cancelled trade. A trade cancellation is final and the trade cannot be reinstated. 3.7 Indicative Auction Information The market data feed provides recipients with the indicative auction price as well as the executable volume. This information will be published each time a change occurs in one of these two pieces of information. Indicative auction information will be published real time during the following Auction Call sessions:

• Opening Auction Call • Re-Opening Auction Call • Closing Auction Call

During the above mentioned Auction Call sessions a Market Data Incremental Refresh – Fixed Income / Market Data Incremental Refresh – Equity message (depending on the market and service) will be broadcasted. The entry will contain an MDUpdateAction(279) of New (0) and an MDEntryType(269) of Auction Clearing Price (Q). The indicative auction price and the executable quantity will be specified in the fields MDEntryPx(270) and MDEntrySize(271) respectively. The entry will not include an MDEntryPx(270) and MDEntrySize(271) if an indicative auction price does not exist (i.e. the order book is not locked or crossed). 3.8 Statistics The market data system will compute statistics based on various configurations that will be applicable for different segments in the Oslo market especially the fixed income segments. Please find below the high level summary of dissemination and publishing of statistics for the equity markets:


No statistics should be updated and disseminated for off-book trades in the Oslo Børs equity market. No Statistics should be updated and disseminated for dark book. Only on-book trades will be contributing when calculating high/low/last/VWAP. Please find below the high level summary of dissemination and publishing of statistics for fixed income markets:


In the fixed income markets off book statistics will only be updated for trades reported on the current day. Bulletin Board (order books without auto match) will not update any statistics as there will be no trades. Therefore for fixed income segments with Bulletin Board, statistics will be updated only based on the off book trades. (For fixed income segments it is either Normal book + Off Book or Bulletin Board + Off Book) Based on the fixed income segments, dissemination of market data statistics will differ from session to session. A single repo trade reported represents two transactions. Therefore when a repo trade is reported or cancelled (repo TradeSubTypes(829) of OR and DR) the following statistics should be doubled and update the overall statistics for the instrument: Volume, Turnover and No. of Trades. The turnover of a repo trade will always be


equal to volume. The following statistics for fixed income markets will be updated and disseminated as a combined statistics (i.e. Normal Book + Off Book):

• High Price • (Converted High) • Low Price • (Converted Low) • VWAP • Last Traded Price • (Converted Last Trade) • Average Price

In the fixed income market, On-Book trades and Off-Book trades with TrdSubTypes(829) of “O” and “OK” will update high/low/last/VWAP/Average Price. The Average Price is the arithmetic average price of automatic trades, uncross trades and off-book trades with TrdSubTypes(829) “O” and “OK” and is calculated as follows: Average Price = (∑price of all eligible trades) / (number of eligible trades) Note that the trade volume is not considered in the calculation. All eligible trades for current trading day should be considered for average price calculation. Average price will be disseminated at the beginning of the post close session of the off- book trade reporting. Trade cancellation during the post close session should update the average price and be disseminated immediately. Where statistics for a particular instrument is disseminated as instrument level (combined book) statistics the system will disseminate the relevant instrument level (Combined book) statistics via Incremental Refresh message – Fixed Income message only through the book specified as primary book with MDSubbooktype(1173) tag indicating the book. It may vary between different fixed income instruments witch book type is specified as primary. The daily instrument reference data described in OSLMIT 401 Reference Data defines the primary book. The table below will depict the dissemination of instrument level (Combine book) statistics on FIX/FAST via Market Data Incremental Refresh – Fixed Income message as per the primary book configuration:


If Primary Book = Normal(On) Book

If Primary Book = Off Book

Co

mbi

ne B

ook

Stat

Upd

ated

by

Nor

mal

boo

k

Upd

ated

by

Off

Book

Stat

istic

s pub

lishe

d in

in

crem

enta

l msg

with

tag

1173

= 1

(Nor

mal

)

Stat

istic

s pub

lishe

d in

in

crem

enta

l msg

with

tag1

173

=

2 (O

ff-B

ook)

Stat

istic

s pub

lishe

d in

in

crem

enta

l msg

with

tag

1173

= 1

(Nor

mal

)

Stat

istic

s pub

lishe

d in

in

crem

enta

l msg

with

tag

1173

=

2 (O

ff Bo

ok)

Highest traded price for the day

Y Y Y Y - - Y

Lowest traded price for the day

Y Y Y Y - - Y

Last traded price Y Y Y Y - - Y Average price

Y Y Y Y - - Y

VWAP of all trades for the day

Y Y Y Y - - Y

Volume of off-book trades for the day

N Y N/A Y N/A Y

Volume of on-book trades for the day

N Y Y N/A Y N/A

Turnover of the off-book trades for the day

N Y N/A Y N/A Y

Turnover of the on-book trades for the day

N Y Y N/A Y N/A

Number of off-book trades for the day

N Y N/A Y N/A Y

Number of on-book trades for the day

N Y Y N/A Y N/A


3.9 Updating Statistics on Trade Cancellations The below statistics should be automatically adjusted if a trade that has previously updated the one or many of the following statistics is cancelled for that instrument:

• High Price • Low Price • Last Traded Price • Last Traded Size • Last Traded Time • Last Trade Movement • Volume • Turnover • Number of Trades • Volume Weighted Average Price • Opening Price • Closing Price • Average Price

The FIX/FAST Market Data Gateways should re-disseminate the above statistics if the re-computed values are different from previously disseminated values. It should be noted that the cancellation of the trades can happen during any session. This may mean that the last traded price / closing price (if equity) needs to be re-published as the trades which participated in closing auction or which were used to compute the closing price are cancelled. When updating statistics after trade cancellation the system shall consider both books (On + Off Book) for the below statistics for the fixed income market, while only On Book for the equities market:

• High Price • Low Price • VWAP • Last Traded Price (only available for the fixed income market) • Converted Last Trade (only available for the fixed income market) • Average Price (only available for the fixed income market)

Only trades that are eligible to update high/low/last shall be taken into consideration when calculating turnover for VWAP calculations. When a repo trade is cancelled the volume, No. of trades and turnover statistics should be reduced by twice.


3.10 Updating and Publishing Statistics as per Market Segment – Fixed Income Manual Trades (Off Book) on the Automatch, ABM and Call Segments will be published on FIX/FAST based on the applicable delay specified by the Trade Type. Statistics should be updated based on the TrdSubType configuration. The High, Low, VWAP and Last Trade statistics are updated from on-book trades as well as the ordinary off-book TrdSubTypes “O” and “OK”. Trades that are reported with a previous Trade date should not update any statistics and should be published immediately. All trade types, both on-book and off-book trades will update Volume, Turnover and No. of Trades. Calculation and statistics updating will be based on time of trade agreement. 3.10.1 Fixed Income Automatch Segment

Off Book

Statistic

Pre-Trade Reporting

Trade Reporting Post Close

08:15 – 09:00 09:00 – 16:00 16:00 – 16:15

High ( & Converted High) No Yes Yes

Low ( & Converted Low) No Yes Yes

VWAP No Yes Yes

Average Price No Yes Yes

Last Trade and Converted Last Price No Yes Yes

Turnover Off Book Yes Yes Yes

Volume Off Book Yes Yes Yes

No.of Trades Off Book Yes Yes Yes


Normal Book

Statistics Start of Trading

Pre Open Entry

Opening Auction

Cont. trading Post close

08:10 – 08:15 08:15 – 08:45 08:45 – 09:00 09:00 – 16:00 16:00 -16:15

High ( & Converted High)

NA NA

Yes Yes

Low ( & Converted Low)

NA NA Yes Yes

VWAP NA NA Yes Yes

Average Price NA NA Yes Yes

Last Trade and Converted Last Price

NA NA Yes Yes

Turnover Normal Book NA NA Yes Yes

Volume Normal Book NA NA Yes Yes

No.of Trades Normal Book

NA NA Yes Yes

Order Book Updates Yes Yes Yes Yes No

Best Bid and Best Offer No No No No


3.10.2 Fixed Income – SE Retail Segment

Off Book

Statistic

Pre-Trade Reporting


08:15 – 09:00 09:00 – 18:00 18:00 – 18:01

High ( & Converted High) No Yes Yes Low ( & Converted Low) No Yes Yes

VWAP No Yes Yes Last Trade and Converted Last Price No Yes Yes

Turnover Off Book Yes Yes Yes Volume Off Book Yes Yes Yes


Normal Book


Pre Open Entry

Opening Auction

Regular trading

Post close

08:10 – 08:15 08:15 – 08:45 08:45 – 09:00 09:00 – 17:30 17:30 -18:00


NA NA

Yes Yes


NA NA Yes Yes

VWAP NA NA Yes Yes Last Trade and Converted Last Price

NA NA Yes Yes

Turnover Normal Book NA NA Yes Yes Volume Normal Book NA NA Yes Yes

No. of Trades Normal Book

NA NA Yes Yes




3.10.3 Fixed Income – SE Wholesale Segment

Manual Trades (Off Book) are not published on Market Data. Trades that are reported with a previous Trade date should not be considered for cumulative statistics send out at the start of Post Close. A cumulative stat message will be disseminated at the start of Post Close.

Off Book

Statistic

Pre-Trade Reporting


08:15 – 09:00 09:00 – 16:30 16:30 – 16:45

High ( & Converted High) No No Yes Low ( & Converted Low) No No Yes

VWAP No No Yes Last Trade and Converted Last Price No No No

Turnover Off Book No No No Volume Off Book No No Yes

No.of Trades Off Book No No No

Normal Book


Pre Open Entry

Opening Auction

Cont. trading Post close

08:10 – 08:15 08:15 – 08:45 08:45 – 09:00 09:00 – 16:00 16:00 -16:45


NA NA

Yes Yes


NA NA Yes Yes

VWAP NA NA Yes Yes Last Trade and Converted Last Price

NA NA Yes Yes

Turnover Normal Book NA NA Yes Yes Volume Normal Book NA NA Yes Yes

No. of Trades Normal Book

NA NA Yes Yes




3.10.4 Fixed Income Call Segment

Off Book

Statistic Pre-Trade Reporting


08:15 – 09:00 09:00 – 16:00 16:00 – 16:15



VWAP No Yes Yes





Normal Book


Pre Open Entry

Opening Auction

Pre Close Entry

Closing Auction

Call

Post Close

08:10 – 08:15

08:15-08:45

08:45 – 09:00

09:00-15:59

15:59 -16:00

16:00 – 16:15

High (& Converted High)

NA NA Yes Yes Yes

Low (& Converted Low) NA NA Yes Yes Yes

VWAP NA NA Yes Yes Yes

Last Trade and Converted Last Price

NA NA Yes Yes Yes

Turnover Normal Book NA NA Yes Yes Yes

Volume Normal Book NA NA Yes Yes Yes

No.of Trades Normal Book

NA NA Yes Yes Yes

Order Book Updates Yes Yes Yes Yes Yes No

Best Bid and Best Offer No No No No No


3.10.5 Fixed Income ABM Segment ABM segment will have the bulletin book and off book. Bulletin book should not update or publish statistics. The order book is published during the order entry period from (09:00 – 16:00) in the bulletin board.

Off Book



08:15 – 09:00 09:00 – 16:00 16:00 – 16:15



VWAP No Yes Yes






3.10.6 Fixed Income – NO Telephone Segment The telephone segment will have the bulletin book and off book. Bulletin book should not update or publish statistics. The order book is published during the order entry period from (9:00 – 16:00) in the bulletin board. Manual Trades (Off Book) are not published on Market Data. Trades that are reported with a previous Trade date should not be considered for cumulative statistics send out at the start of Post Close. A cumulative stat message will be disseminated at the start of Post Close.

3.10.7 Fixed Income – SE Telephone Segment SE Telephone segment will have the bulletin book and off book. Bulletin book should not update or publish statistics. The order book is published during the order entry period from (09:00 – 16:00) in the bulletin board. Manual Trades (Off Book) are not published on Market Data. Trades that are reported with a previous Trade date should not be considered for cumulative statistics send out at the start of Post Close. A cumulative stat message will be disseminated at the start of Post Close.

Off Book



08:15 – 09:00 09:00 – 16:00 16:00 – 16:15

High (& Converted High) No No No

Low (& Converted Low) No No No

VWAP No No Yes

Last Trade and Converted Last Price No No No

Turnover Off Book No No No

Volume Off Book No No Yes

No.of Trades Off Book No No No


Off Book

Statistic

Pre-Trade Reporting


08:15 – 09:00 09:00 – 16:30 16:30 – 16:45

High ( & Converted High) No No Yes Low ( & Converted Low) No No Yes

VWAP No No Yes Last Trade and Converted Last Price No No No

Turnover Off Book No No No Volume Off Book No No Yes

No. of Trades Off Book No No No 3.10.8 Fixed Income Issuing Auction Segment The order book will be published only to the central bank from the Issuing Auction Call till the post close (10:15 – 11:10). The order book will not be made available to other participants other than the Central Bank and Oslo Børs. On the uncrossing the individual trades will be published as market data. The following market data statistics will be published for Normal Book trades on this cycle to the market (to all market participants and the Central Bank).

• Turnover Normal Book Trades • Number of Trades Normal Book • Volume of Trades Normal Book

3.10.9 Fixed Income Buy Back Auction Segments The order book will be published only to the Central Bank from the Buy Back Auction Call till the post close (10:15 – 11:10). The order book will not be made available to other participants other than the central bank and Oslo Børs. On the uncrossing the individual trades will be published as market data. The following market data statistics will be updated for Normal Book trades on this cycle and will be published to the market (to all market participants and the Central Bank).

• Turnover Normal Book Trades • Number of Trades Normal Book • Volume of Trades Normal Book

3.10.10 Nibor segment The indicative deposit rate instruments registered in the Nibor segment will have bulletin books and off books. The bulletin books should not update or publish statistics.


Orderbook updates are published during the entire order entry period from (09:00 – 16:00) in the bulletin books. The off book enters the post close session only. The start of the off book post close session in the off book marks the exact time for Nibor-fixing. On normal days the time of Nibor-fixing is at 12:00. On half days the fixing time is at 10:00. Nibor-fixing values are distributed via the FIX/FAST Indices Gateway and described in OSLMIT306 FIX/FAST News and Indices Gateway document.

3.11 Updating Statistics as per Market Segment – Equity

3.11.1 Off-Book Manual trades (off-book) in the equity Segment should NOT update any market data statistic. MiFID delay models will be applicable to manual trades (off-book) on the equity segment. 3.11.2 Normal Book The order book is published after the start of the trading period till the post close. The following market data statistics will be updated for normal Book trades (Automatic/Uncrossing) on this cycle:

• Turnover Normal Book Trades • Number of Trades Normal Book • Volume of Trades Normal Book • VWAP (Normal Book) • High Price (Normal Book) • Low Price (Normal Book)

3.12 Price Field Interpretation The values specified in the MDEntryPx(270) field of the Market Data Snapshot (Full Refresh) and Market Data Incremental Refresh – Fixed Income messages should, depending on the quotation convention for the instrument, be interpreted as price per share (equity instruments) and percentage of par (fixed income instruments). An exception is for the TrdSubTypes “ER” and “DR” which where the MDEntryPx(270) field should be interpreted as repo rate. The quotation convention for each instrument will be disseminated via the PriceType(423) field of the Security Definition message.


4. Data Loss Detection and Management Data loss can occur for two reasons:

- Network packet loss: The real-time channel used UDP multicast, which lacks support for guaranteed delivery of packets.

- The client was not listening on the UDP multicast channel when the data was published: There is no re-request support on the UDP multicast channel.

This section describes how clients may detect data loss, and how the lost data can be recovered. 4.1 How to Detect Data Loss A message loss can be detected using the ApplSeqNum(1181) included in each message on the real-time channel. If a gap in sequence numbers is detected, the recipient should assume that some or all of the order books and statistics maintained on its systems are incorrect and initiate one of the recovery processes outlined below. Each entry of a Market Data Incremental Refresh – Fixed Income / Market Data Incremental Refresh – Equity or a Market Data Snapshot (Full Refresh) message disseminated on the real-time channel also includes an instrument specific sequence number in the field RptSeq(83). Recipients may use this instrument level sequencing to determine the instruments for which a recovery process should be initiated. 4.2 Data Loss Management Using Backup Feed Arbitration Clients have access to two identically sequenced real-time feeds: one from the main site (Feed A) and one from the backup feed (Feed B). Clients may process both feeds and arbitrate between them to minimize the probability of a data loss. Clients co-located at the main site should be aware of the additional latency of Feed B (in the order of 5-10 ms) introduced by network communication between the two systems. 4.3 Data Loss Management Using TCP Based Services The FIX/FAST Market Data feed has two different TCP based data loss management services:

- Replay channel - Recovery channel

The main and the backup feed both have replay channels. The replay channel on the backup feed will only be activated in the unlikely event of an outage at the main site. Note that the server will not send heartbeats on the TCP channels during periods of inactivity. 4.3.1 Usage Limitations The TCP based data loss management services are subject to usage limitations. The various limitations for each service are specified in OSLMIT 604 Technical Parameters. 4.3.2 Login and Authentication A client is identified by a CompID, an IP address and a password assigned by Oslo Børs.


The CompID and the IP address of each client wishing to connect to the recovery and replay channels must be registered with Oslo Børs before the services can be used. This is done as part of the enablement process. The same CompID could be used to login to recovery and replay channels across Market Data Groups. A client could also use the same CompID to login to the recovery and replay channel. However, a CompID may, at any particular time, only be logged into one TCP channel across all Market Data Groups. 4.3.3 Passwords Each new CompID will be assigned a password on registration. Clients will be required to change the password to one of their choosing via the first Logon message. The new password will, if accepted, be effective for subsequent logins. The status of the new password (i.e whether it is accepted or rejected) will be specified in the SessionStatus(1409) field of the logon message sent by the server to confirm the establishment of a FIX connection. New passwords must adhere to the rules below:

• Minimum length - 8 characters • Maximum length - 14 characters • Minimum numeric characters - 1 character • Minimum alpha characters - 1 character • Minimum special characters - 1 character

Oslo Børs recommends that the passwords are changed at regular intervals.

4.3.4 Establishing a connection The client should use the relevant IP address and port (as outlined in OSLMIT 605 Live Environment Connectivity and OSLMIT 606 CDS Environment Connectivity) to establish a TCP/IP session with the recovery channel. The client should initiate a FIX connection by sending the Logon message. The client should identify itself by specifying its CompID in the Username(553) field. The server will validate the CompID, password and IP address of the client. Once the client is authenticated, the server will respond with a Logon message. The SessionStatus(1409) of this message will be Session Active (0). The client must wait for the server’s Logon before sending additional messages. Messages received from the client before the exchange of Logon messages will be ignored. If a logon attempt fails because of an invalid CompID, IP address, or invalid password or if a message is sent prior to the login being established the server will break the TCP/IP connection with the client without sending a Logout message. If a logon attempt fails because of an expired password, a locked CompID or if logins are not currently permitted, the server will send a Logout and then break the TCP/IP connection with the client. The recovery channel supports only a configurable number of concurrent logins across all clients. In addition, each CompID may login to the recovery channel of a particular Market Data Group up to a configurable number of times each day. If either of these limits is reached, the server will reject a new logon attempt with a Logout and then break the TCP/IP connection with the client. The SessionStatus(1409) of such a Logout message will be Logons Not Allowed (7).


If a Logon message is not received within a configurable number of seconds of the establishment of a TCP/IP connection, the server will break the TCP/IP connection with the client without sending a Logout message. If a Security Definition Request or Market Data Request is not received within a configurable number of seconds of a successful logon, the server will send a Logout message and then break the TCP/IP connection with the client. The Text (58) field of Logout will contain “Logout Due to Inactivity”. Each time the TCP/IP connection is terminated, it will increment the counter of the maximum amount of times each CompID may login to the recovery channel. A second attempt to log in by an already logged in client will be rejected via a Business Message Reject. Please see the OSLMIT 604 Technical Parameters document for all configurable numbers and parameters. 4.3.5 Termination of the Connection If the client does not send a Logout and terminate the connection within a configurable number of seconds of the transmission of the last application message, the server will send a Logout message and then break the TCP/IP connection with the client. The Text(58) field of Logout will contain “Logout Due to Inactivity”. The server will terminate the TCP/IP connection (a Logout will not be sent) if the number of messages that are buffered for a client exceeds a configurable number. Please see the OSLMIT 604 Technical Parameters document for all configurable numbers and parameters. 4.4 The Replay Channel The TCP replay channel should be used by recipients to recover from a small-scale data loss. It permits recipients to request the retransmission of a limited number of messages already published on the real-time channel. 4.4.1 Requesting Missed Messages The client is expected to transmit an Application Message Request within a configurable number of seconds of establishing the FIX connection. The message should include the server identifier of the real-time channel to which the retransmission request applies along with the list of messages to be resent. The ApplBegSeqNum(1182) and ApplEndSeqNum(1183) fields should be used to specify the ApplSeqNum(1181) of the first and last message in the range to be resent. The Application Message Request can be used in three modes:

(i) To request a single message. The ApplBegSeqNum(1182) and ApplEndSeqNum(1183) should both be the message sequence number of the missed message.

(ii) To request a specific range of messages. The ApplBegSeqNum(1182) should be the message sequence number of the first message of the range and the ApplEndSeqNum(1183) should be that of the last message of the range.

(iii) To request all messages after a particular message. The ApplBegSeqNum(1182) should be the message sequence number immediately after that of the last processed message and the ApplEndSeqNum(1183) should be zero (0).

The retransmission request will be serviced from the server’s cache of the last <10,000> (a configurable number which will be configured for different values for different gateways; will be set up to 150,000 for Oslo


Børs) messages published on the Real-time channel. If the retransmission request includes one or more messages that are not in the server’s cache, the entire request will be rejected and no messages will be retransmitted. 4.4.2 Response to a Retransmission Request The server will respond to the Application Message Request with an Application Message Request Ack to indicate whether the retransmission request is successful or not. If the request is unsuccessful, the reason will be specified in the field ApplResponseType(1348). An Application Message Request will be rejected via a Business Message Reject if a conditionally required field is missing or a request limit (for the day or for outstanding requests) is breached. In the case of a successful retransmission request, the server will transmit the requested messages immediately after the Application Message Request Ack. The message sequence number and, where relevant, the Instrument sequence number from the Real-time channel will be included in the ApplSeqNum(1181) and RptSeq(83) fields of each retransmitted message. Once the last of these messages is sent, the server will indicate that the retransmission is complete via an Application Message Report. 4.4.3 Cancelling of a Retransmission Request A client may cancel an outstanding retransmission request via an Application Message Request. Such a message should include an ApplReqType(1347) of Cancel Retransmission (5) and the ApplReqID(1346) of the request to be cancelled. The server will transmit an Application Message Request Ack or a Business Message Reject to confirm or reject the cancellation request respectively. A cancellation request submitted by a client will take priority over all the requests of the client being queued.

4.5 The Recovery Channel The TCP Recovery channel should be used by recipients to recover from a large-scale data loss (i.e. late joiner or major outage). The channel permits recipients to request a snapshot of the Order Book and statistics for the active Instruments in the Market Data Group. In addition, it enables recipients to request the retransmission of the trades published during last configurable number of minutes on the Real-time channel. It also enables recipients to download the list of active Instruments in the Market Data Group. Please see the OSLMIT 604 Technical Parameters document for all configurable numbers and parameters. 4.5.1 Requesting Instrument Once connected to the Recovery channel, clients may use the Security Definition Request message to request the details of all active Instruments in the Market Data Group or those in the group from a particular segment. The Security Definition Request should include a unique SecurityReqID(320) and a SecurityRequestType(321) (i.e. all Instruments or all Instruments for a segment). If the request is successful, the server will disseminate the details of each Instrument via the Security Definition message. Each such message will include a SecurityResponseType(323) of List of Securities Returned (4) and the SecurityReqID(320) of the request. The last message sent in response to the request will include a LastRptRequested(912) of Last Message (Y). The client will not receive the details of any subsequent master file updates.


An invalid Security Definition Request will generally be rejected via a Security Definition message with a SecurityResponseType(323) of Cannot Match Selection Criteria (6). However, a Business Message Reject will be used if a conditionally required field is missing or a request limit (for the day or for outstanding requests) is breached. 4.5.2 Requesting Snapshot: Order Book and Statistics Once connected to the recovery channel, clients may use the Market Data Request message to request a snapshot of the current order book or statistics for one or more instruments in the Market Data Group. Clients may also request snapshots for the instruments in the Market Data Group that are assigned to one or more segments. The Market Data Request should include an MDReqID(262) and at least one SecurityID(48) or ProductComplex(1227). A request for an order book snapshot should include a MDEntryType(269) of Bid (0) and/or Offer (1). An order book snapshot will always contain the details both sides the order book even if the Market Data Request contained just an MDEntryType(269) of Bid (0) or Offer (1). Clients are unable to request just one side (i.e. bid or offer) of an order book. Similarly, a request for a statistics snapshot should include one or more of the relevant entries for MDEntryType(269) (e.g. High Price (7), Low Price (8), Volume (B), etc.). A statistics snapshot will contain all available statistics even if the Market Data Request contained just some of the statistics-related entries for MDEntryType(269). Clients are unable to request for a snapshot of selected statistics (e.g. high price and low price only). A client may request both an order book and statistics snapshot in a single Market Data Request. A single message may also be used to request snapshots for multiple Instruments and/or multiple segments. If the Market Data Request is successful, the server will disseminate a snapshot of the current order book or statistics for each Instrument via a Market Data Snapshot (Full Refresh) message. Each such message will include the MDReqID(262) of the applicable Market Data Request. The order book and statistics snapshot for a particular Instrument will be disseminated via two separate Market Data Snapshot (Full Refresh) messages. A successful Market Data Request for order book will result in disseminating snapshots of all the books maintained for the relevant Instruments. It could be snapshots of either order or even both the books depending on what’s maintained for each instrument. The order book snapshots of order books of a single instrument will also be disseminated via two separate Market Data Snapshot (Full Refresh) messages. Each Market Data Snapshot (Full Refresh) will reflect the order book or statistics for the instrument as per the last update on the real-time channel. The ApplSeqNum(1181) and RptSeq(83) of the applicable Market Data Incremental Refresh or the Market Data Snapshot (Full Refresh) disseminated in the real-time channel will be included in the LastMsgSeqNumProcessed(369) and RptSeq(83) fields of each Market Data Snapshot (Full Refresh) respectively. An order book or statistics snapshot will be published even if there are no orders or statistics for an instrument. In such a case, the Market Data Snapshot (Full Refresh) message will include an MDEntryType(269) of Empty


Order Book (J) or No Statistics (z). However if all trades for a particular instrument are cancelled, cumulative statistics such as Volume, VWAP, Turnover and Number of Trades may be set to zero. Each Market Data Snapshot (Full Refresh) message, whether it is used to provide a snapshot of the order book or statistics in the recovery channel, will include the current status of on-book trading for the Instrument in the field MDSecurityTradingStatus(1682). The last message sent in response to the request will include a LastRptRequested(912) of Last Message (Y). The client will not receive any subsequent order book or statistics updates for the applicable instruments. An invalid Market Data Request will generally be rejected via a Market Data Request Reject message. However, a Business Message Reject will be used if a conditionally required field is missing or a request limit (for the day or for outstanding requests) is breached. 4.5.3 Requesting Missed Trades Once connected to the recovery channel, clients may use the Market Data Request message to request missed trades for one or more instruments in the Market Data Group. Clients may also request missed trades for the instruments in the Market Data Group that are assigned to one or more segments. The Market Data Request should include a MDReqID(262) and at least one SecurityID(48) or ProductComplex(1227). A Market Data Request for missed trades should include an MDEntryType(269) of Trade (2). The request should also include the Sending Time of the last trade on the real-time channel processed by the client in the MDEntryTime(273) field. This should be applied for both on-book trades and off-book trades. When requesting missed trades from the dark order book, the request should include the field RoutingInst(9303) of Dark Midpoint Order Book(M). A client may request missed trades and order book and/or statistics snapshots in a single Market Data Request. A single message may also be used to request missed trades for multiple instruments and/or multiple segments. If the Market Data Request is successful, the server will retransmit all the trades for the specified instruments and/or segments after the specified time. Each missed trade will be published via a Market Data Incremental Refresh message. Each such message will include the MDReqID(262) of the applicable Market Data Request. The corresponding message and instrument sequence numbers from the real-time channel will be included in the ApplSeqNum(1181) and RptSeq(83) fields of each retransmitted trade. The last message sent in response to the request will include a LastRptRequested(912) of Last Message (Y). If the request includes a Sending Time in the MDEntryTime(273) field, which is prior to that of the oldest trade in the server’s cache, all eligible trades in the cache will be retransmitted. Clients are unable to recover trades not in the server’s cache. In a situation where one or more instruments in a segment do not have the requested market data (trades/order book/statistics) (e.g. requesting order book snapshot for a instrument which has only off book definition attached) or a scenario when there are multiple requests sent for a single instrument/multiple instruments via a single message and some cannot be accommodated (e.g. requesting order book and statistics snapshots for instruments of which some only have off book definition attached) the system should send the market data for the instruments that are available with the requested market data and not send any response for the instruments which do not have the requested market data.


The last message sent in response will have LastRptRequested field tagged which will impliedly indicate to the user that some instruments did not have the requested market data. If all the instruments in a segment do not have the requested market data or all the requests sent in a single request message are not available should be rejected with a market data request reject message with the reject reason "Requested Market Data unavailable”. Please refer to section 0 for specific scenarios and system responses. An invalid Market Data Request will generally be rejected via a Market Data Request Reject message. If no trades have been missed the Market Data Request Reject will include an MDReqRejReason(281) of “Z” and the value “102” (i.e. requested Market Data unavailable) in the Text(58) field. A Market Data Request will be rejected via a Business Message Reject if a conditionally required field is missing or a request limit is breached. 4.5.4 Cancelling a Request A client may cancel an outstanding instrument or market data request via the Security Definition Request or Market Data Request messages respectively. Such a message should include a SubscriptionRequestType(263) of Unsubscribe (2) and the SecurityReqID(320) or MDReqID(262) of the request to be cancelled. While the server will not confirm a successful cancellation, it will transmit a Business Message Reject if the request is rejected. A cancellation request submitted by a client will take priority over all the requests of the client being queued. 4.6 Handling System Level Failures 4.6.1 Snapshots on the Real-Time Channel In the unlikely event of an outage of a system at Oslo Børs, recipients may be required to refresh their order book and statistics displays for one or more Instruments. In such a scenario the server will, on the real-time channel, broadcast Market Data Snapshot (Full Refresh) messages for each affected instrument: one with an MDEntryType(269) of Empty Order Book (J) and the other with an MDEntryType(269) of No Statistics (z). In such an event, recipients must discard the contents of their order book and statistic displays. Each Market Data Snapshot (Full Refresh) message will include the current status of on-book trading for the instrument, in the field MDSecurityTradingStatus(1682). The server will then transmit a series of Market Data Incremental Refresh messages to disseminate the current order book and statistics for each affected Instrument, if the gateway is configured with the book update type set to Incremental mode for the Oslo Børs fixed income market. If the gateway is configured with the book update type set to Snapshot mode, as for the Oslo Børs equities market, the server will transmit Market Data Snapshot (Full Refresh) messages to disseminate the current order book for affected instrument per each book. 4.6.2 Resetting Sequence Numbers If the market data feed is, due to the unlikely event of an outage, restarted during a trading day, the message sequence number and instrument level sequence number of the real-time channel will be reset to “1”.


In such a case, messages sent on the real-time channel prior to the resetting of sequence numbers will not be available for retransmission on the replay channel. The trades resent on the recovery channel, if any, will not contain an ApplSeqNum(1181) or RptSeq(83) if there were originally disseminated prior to the resetting of sequence numbers.


5. Message Formats and Templates This section provides details on the three administrative messages and twelve application messages utilized by the market data feed. All messages sent by the server are transfer encoded in terms of the FAST protocol. While all application messages sent by the server (e.g. Market Data Incremental Refresh, Security Definition, etc.) are field encoded, the administrative messages it sends (e.g. Logon, Heartbeat, etc.) are not. All messages (i.e. both administrative and application) initiated by the client1 should be transfer encoded but not field encoded. The FIX format of each is described along with the applicable FAST template. 5.1 Variations from the FIX Protocol The Market Data Feed conforms to the FIX protocol except as follows:

1. The SessionStatus(1409) field of the Logon message includes the custom value Other (100).

2. The Market Data Request message includes the field MDEntryTime(273).

3. The Security Status message includes the field MDQuoteType(1070) to indicate whether the status changes published take place in the Order Book.

4. The Market Data Request message does not include the field MarketDepth(264).

5. The LastRptRequested(912) field is included in the Security Definition, Market Data Snapshot (Full Refresh) and Market Data Incremental Refresh messages.

6. The MDEntryType(269) field of the Market Data Request, Market Data Snapshot (Full Refresh) and

Market Data Incremental Refresh – Equity messages includes the custom value Previous Close (f).

7. The MDEntryType(269) field of the Market Data Snapshot (Full Refresh) and Market Data Incremental Refresh messages includes the values Market Bid (b) and Market Offer (c) which were introduced in Extension Pack 106.

8. The MDEntryType(269) field of the Market Data Snapshot (Full Refresh) message includes the custom value No Statistics (z).

9. The MDEntryType(269) of the Market Data Request, Market Data Snapshot (Full Refresh) and Market Data Incremental Refresh – Fixed Income messages includes the custom value Last Traded Price (g).

10. Closing Bid and Offer Prices will be indicated by the use of the combination of fields MDEntryType(269) and QuoteCondition(276). Closing Bid will be indicated with MDEntryType(269) of Bid (0) and QuoteCondition(276) of Closing (O). Closing Offer will be indicated with MDEntryType(269) of Offer (1) and QuoteCondition(276) of Closing (O). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and Market Data Incremental Refresh messages.

1 Sending Time tagged in the administrative and application messages initiated by the client will not be validated


11. VWAP of automatic trades will be indicated by the use of the combination of fields MDEntryType(269) of VWAP (9). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages.

12. Turnover of on-book trades will be indicated by the combination of the fields MDEntryType(269) of Turnover (d). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages.

13. Turnover of off-book trades will be indicated by the combination of the fields MDEntryType(269) of Turnover (d). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages.

14. Volume of on-book trades will be indicated by the combination of the fields MDEntryType(269) of Volume (B). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages.

15. Volume of off-book trades will be indicated by the combination of the fields MDEntryType(269) of Volume (B). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages.

16. Number of on-book trades will be indicated by the combination of the fields MDEntryType(269) of Number of Trades (e). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages.

17. Number of off-book trades will be indicated by the combination of the fields MDEntryType(269) of Number of Trades (e). This applies to the Market Data Request, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages.

18. The SecurityStatus(965) field of the Security Definition message includes the custom values Halted (8) and Suspended (9).

19. The SecurityTradingStatus(326) of the Security Status message includes the custom values Pre-Trading (100), Closing Auction Call (102), End of Post Close (103), Re-Opening Auction Call (104), Pre Open Entry (106), Pre Closing Entry (107), Buyback Issuing Auction (108), Admin (109), Buyback Issuing Special Entry (110), Pause (111), Order Entry (113), Closing Price Publication (125), Pre Trade Reporting (126), No Active Session (199).

20. The SecurityTradingEvent(1174)of the Security Status message includes the custom values Price Monitoring Extension (100), Extended by Market Operations (101), Shortened by Market Operations (102) and Circuit Breaker Tripped (103).

21. The MDSubBookType(1173)field of the Market Data Request, Security Status, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh – Fixed Income messages includes the custom values On-book (1), Off-Book (2), Bulletin Board (9).

22. The MDSubBookType(1173)field of the Security Status, Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh – Equity messages includes the custom values On-book (1) and Off-Book (2).

23. The Text(58) field of the Security Status message is used to disseminate the time at which a Re-Opening auction will take place. In the event an Auction Call is extended, the updated time for the auction will also be disseminated via this field.

24. The HaltReason(327) field of the Security Status Message contains custom values specific to Oslo Børs. This field is required when SecurityTradingStatus(326) is Halt (2).


25. The Market Data Snapshot (Full Refresh) message includes the fields MDSecurityTradingStatus(1682) and MDHaltReason(1684) which were introduced in Extension Pack 106.

This field will be required when the message is sent in the recovery channel.

26. The NOPartyIDs(453) of the Market Data Snapshot (Full Refresh) and the Market Data Incremental Refresh messages will always include the custom value (1), if specified. Open/ClosePriceIndicator(1759) custom field will be added to indicate the method in which the opening or the closing price is determined. The field will be included in both the Market Data Snapshot (Full Refresh) and Market Data Incremental Refresh messages. The values will be UT (1), AT (2), Mid of BBO after Opening Auction (3), VWAP n minutes (6), Last AT (7), Last UT (8), Previous Close (9), Manual (10), VWAP of Last n Trades (19), Reference Price (20), Best Bid (22), Best Offer (23). This field will be required when the MDEntryType(269) is Opening Price (4) or Closing Price (5). If the MDEntryType(269) is Opening Price (4) the value indicated in this field will be the opening price indicator. If the MDEntryType(269) is Closing Price (5) the value indicated in this field will be the closing price indicator.

27. AggressorSide(5797) custom field will be added to indicate whether the buyer or the seller is the aggressor of the trade. The field will be included in the Market Data Incremental Refresh messages. The values will be Buyer (1) and Seller (2). This field is required when MDEntryType is Trade (2).

28. OriginalPrice (1769) custom field added to indicate the price in the execution currency if the trade was executed in a different currency than the trading currency of the instrument. The field is specific to off-book trades. The field will be Market Data Incremental Refresh messages.

29. The MDReqRejReason(281) field of the Market Data Request Reject message includes the custom value Other (Z).

30. The MDMkt(275) field will also include the custom values SI and XOFF in the Market Data Incremental Refresh messages.

31. TrdSubType(829) is included in the Market Data Incremental Refresh messages. Custom values added as described in the Trade Types reference data file described in OSLMIT 401 Reference Data to the field TrdSubType(829) to support the trade types available in the Millennium Exchange trading system. The trade types are further explained in the OSLMIT Oslo Børs Market Model Equities and OSLMIT Oslo Børs and Nordic ABM Market Model Fixed Income.

32. The custom defined field RoutingInst(9303) will be used in the Market Data Request – Equity, Security Definition – Equity, Security Status – Equity and Market Data Incremental Refresh – Equity messages.


5.2 Header 5.2.1 FIX Message Tag Field Name Req Description 35 MsgType Y Message type.

Value Meaning 0 Heartbeat 5 Logout A Logon B News V Market Data Request W Market Data Snapshot (Full Refresh) X Market Data Incremental Refresh Y Market Data Request Reject BW Application Message Request BX Application Message Request Ack BY Application Message Report c Security Definition Request d Security Definition f Security Status j Business Message Reject

52 SendingTime Y Time the message is transmitted specified in UTC and in the YYYYMMDD-HH:MM:SS.sss format.

5.2.2 FAST Template Administrative Messages and Client-Initiated Application Messages: Tag Field Name Field Type Field Encoding Description 35 MsgType ASCII String None 52 SendingTime ASCII String None

Server-Initiated Application Messages: Tag Field Name Field Type Field Encoding Description 35 MsgType ASCII String None 52 SendingTime ASCII String None


5.3 Administrative Messages

5.3.1 Logon FIX Message: Tag Field Name Req Description 1180 AppllID N Identifier of the server sending the message. Required if the

message is generated by the server. Please see the OSLMIT 605 Live Environment Connectivity and OSLMIT 606 CDS Environment Connectivity documents for details.

108 HeartBtInt N Indicates the heartbeat interval in seconds. 553 Username N CompID of the client. Required if the message is generated by the

client. 554 Password N Password assigned to the CompID. Required if the message is

generated by the client. 925 New

Password N New password for the CompID.

1409 Session Status

N Status of session. Required if message is generated by server.

Value Meaning 0 Session Active 2 Password Due to Expire

FAST Template: Tag Field Name Field Type Field Encoding Description 1180 AppllID ASCII String None 108 HeartBtInt Unsigned Integer None 553 Username ASCII String None 554 Password ASCII String None 925 New

Password ASCII String None

1409 Session Status

Unsigned Integer None


5.3.2 Logout FIX Message Tag Field Name Req Description 1180 AppllID N Identifier of the server sending the message. Required if the

message is generated by the server 1409 SessionStatus N Status of the session. Required if the message is generated by the

server.

Value Meaning 4 Session Logout Complete 6 Account Locked 7 Logons Not Allowed 8 Password Expired 100 Other

58 Text N Reason for the logout.

FAST Template Tag Field Name Field Type Field Encoding Description 1180 AppllID ASCII String None 1409 SessionStatus Unsigned Integer None 58 Text ASCII String None

5.3.3 Heartbeat FIX Message Tag Field Name Req Description 1180 AppllID Y Identifier of the server sending the message. 1399 ApplNewSeqNum Y Sequence number of the next expected

Application Message.

FAST Template Tag Field Name Field Type Field Encoding Description 1180 AppllID ASCII String None 1399 ApplNewSeqNum Unsigned Integer None


5.4 Application Messages (Client-Initiated) 5.4.1 Security Definition Request FIX Message Tag Field Name Req Description 320 SecurityReqID Y Unique identifier of the request sent by the

client. 263 SubscriptionRequestType Y Whether the request is being cancelled.

Value Meaning 0 Snapshot 2 Unsubscribe

321 Security Request Type

N Type of request. Required unless Subscription RequestType(263) is Unsubscribe (2).

Value Meaning 8 All Securities 9 All Securities for a Segment

1300 MarketSegmentID N Indicates the segment. Valid segments are found in OSLMIT Oslo Børs Market Model Fixed Income and OSLMIT Oslo Børs Market Model Equities. Required if SecurityRequestType(321) is All Securities for a Segment (9).

FAST Template Tag Field Name Field Type Field Encoding Description 320 SecurityReqID ASCII String None 263 Subscription

Request Type Unsigned Integer None

321 SecurityRequest Type

Unsigned Integer None

1300 MarketSegment ID

ASCII String None


5.4.2 Market Data Request - Equity FIX Message Tag Field Name Req Description 262 MDReqID Y Unique identifier of the Market Data request sent

by the client. 263 Subscription Request

Type Y Type of subscription requested.


267 NoMD Entry Types

N Number of Market Data types requested. Required if SubscriptionRequestType(263) is Snapshot (0).

269 MDEntryType

N Indicates the type of market data requested. Required if NoMDEntryTypes(267) is specified.

Value

Meaning Available on

0 Bid 1 1 Offer 1 2 Trade 1 4 Opening Price 1 5 Closing Price 1 7 High Price 1 8 Low Price 1 9 VWAP 1 B Volume 1 b Market Bid 1 c Market Offer 1 d Turnover 1 e Number of Trades 1 f Previous Close 1 g Last Traded Price.

Can only be used for FI instruments.

h Average Price Can only be used for FI instruments.

1) Level 2 Equity, ETF and Warrants.


Tag Field Name Req Description 273 MDEntryTime N Sending time of the last processed trade. The time

will be specified in UTC and in the HH:MM:SS.sss format. Required if MDEntryType(269) is Trade (2).

276 QuoteCondition N Will be used to indicate Closing Bid and Offer Price together with MDEntryType(269) of Bid (0) and Offer (1) respectively.

Value Meaning O Closing

146 NoRelatedSym N Number of instruments or segments market data is requested for. Required if SubscriptionRequestType(263) is Snapshot (0).

48 Security ID

N Identification number for the security.

22 Security IDSource

N Type of security identification number used. Required if SecurityID(48) is specified.

Value Meaning 8 Instrument identifier

1227 ProductComplex N Indicates the segment. Please refer to OSLMIT Oslo Børs Market Model Equities and OSLMIT Oslo Børs Market Model Fixed Income for the valid segments. Required if SecurityID(48) is not specified.

1173 MDSubBookType N Type of trading to which the update relates. Absence of this field should be interpreted as all books.

Value Meaning 1 On-Book 2 Off-Book 9 Bulletin Board

9303 RoutingInst2 N Indicate the liquidity pool. Absence of this field should be interpreted as Lit Order book.

Value Meaning I Lit Order Book M Dark Midpoint Order book

2 If RoutingInst is not specified and the MDEntryType(269) is Trade, trades of both dark and lit order books should be provided


FAST Template Tag Field Name Field Type Field Encoding Description 262 MDReqID ASCII String None 263 Subscription

RequestType Unsigned Integer None

267 NoMDEntryTypes Unsigned Integer None 269 MDEntryType ASCII String None 273 MDEntryTime ASCIIString None 276 QuoteCondition ASCIIString None 146 NoRelatedSym Unsigned Integer None 48 SecurityID ASCII String None 22 SecurityID

Source ASCII String None

1227 ProductComplex ASCII String None 1173 MDSubBookType Unsigned Integer None 9303 RoutingInst ASCII String None


5.4.3 Market Data Request – Fixed Income FIX Message Tag Field Name Req Description 262 MDReqID Y Unique identifier of the Market Data request sent

by the client. 263 Subscription Request

Type Y Type of subscription requested.


267 NoMD Entry Types

N Number of Market Data types requested. Required if SubscriptionRequestType(263) is Snapshot (0).

269 MDEntryType

N Indicates the type of market data requested. Required if NoMDEntryTypes(267) is specified.

Value

Meaning Available on

0 Bid 2, 4 1 Offer 2, 4 2 Trade 3, 4 4 Opening Price 5 Closing Price 7 High Price 3 8 Low Price 3 9 VWAP 3 B Volume 3, 4 b Market Bid 2 c Market Offer 2 d Turnover 3, 4 e Number of Trades 3, 4 f Previous Close g Last Traded Price 3 h Average Price 3

2) Fixed Income Incremental Service 3) Fixed Income Trade Only Gateway 4) Full Depth Service Central Bank Gateway


Tag Field Name Req Description 273 MDEntryTime N Sending time of the last processed trade. The time

will be specified in UTC and in the HH:MM:SS.sss format. Required if MDEntryType(269) is Trade (2).



146 NoRelatedSym N Number of instruments or segments market data is requested for. Required if SubscriptionRequestType(263) is Snapshot (0).

48 Security ID

N Identification number for the security.

22 Security IDSource

N Type of security identification number used. Required if SecurityID(48) is specified.


1227 ProductComplex N Indicates the segment. Please refer to OSLMIT Oslo Børs Market Model Fixed Income for the valid segments. Required if SecurityID(48) is not specified.

1173 MDSubBookType N Type of trading to which the update relates. Absence of this field should be interpreted as all books.



FAST Template Tag Field Name Field Type Field Encoding Description 262 MDReqID ASCII String None 263 Subscription

RequestType Unsigned Integer None

267 NoMDEntryTypes Unsigned Integer None 269 MDEntryType ASCII String None 273 MDEntryTime ASCIIString None 276 QuoteCondition ASCIIString None 146 NoRelatedSym Unsigned Integer None 48 SecurityID ASCII String None 22 SecurityID

Source ASCII String None

1227 ProductComplex ASCII String None 1173 MDSubBookType Unsigned Integer None


5.4.4 Application Message Request FIX Message Tag Field Name Req Description 1346 ApplReqID Y Client specified unique identifier of the request. 1347 ApplReqType Y Type of request.

Value Meaning 0 Retransmission of Messages 5 Cancel Retransmission

1351 NoApplIDs N If specified, the value in this field should always be “1”. Required if ApplReqType(1347) is Retransmission of Messages (0).

1355 RefApplID N ApplID of the real-time channel for which the retransmission is requested. Required if NoApplIDs(1351) is specified. Please see the OSLMIT 605 Live Environment Connectivity and OSLMIT 606 CDS Environment Connectivity documents for details about the ApplID.

1182 ApplBegSeqNum N ApplSeqNum(1181) of the first message in the range to be resent from the real-time channel. Required if NoApplIDs(1351) is specified.

1183 ApplEndSeqNum N ApplSeqNum(1181) of the last message in the range to be resent from the Real-time channel. Required if NoApplIDs(1351) is specified.

FAST Template Tag Field Name Field Type Field Encoding Description 1346 ApplReqID ASCII String None 1347 ApplReqType Unsigned Integer None 1351 NoApplIDs Unsigned Integer None 1355 RefApplID ASCII String None 1182 ApplBegSeqNum Unsigned Integer None 1183 ApplEndSeqNum Unsigned Integer None


5.5 Application Messages (Server-Initiated) 5.5.1 Security Definition - Equity FIX Message Tag Field Name Req Description 1180 ApplID Y Identifier of the server sending the message. 1181 ApplSeqNum N Sequence number of the message on the real-time

channel. Required if the message is disseminated via the real-time or replay channel.

320 SecurityReqID N Identifier of the Security Definition Request this message relates to. Required if the message is disseminated via the recovery channel.

323 SecurityResponseType N Type of response. Required if the message is disseminated via the recovery channel.

Value Meaning 4 List of Securities Returned 6 Cannot Match Selection

Criteria

912 LastRptRequested N Indicates the last message sent in response to a request.

Value Meaning Y Last Message

965 SecurityStatus N Status of the instrument.

Value Meaning 1 Active 2 Inactive 8 Halted 9 Suspended

454 NoSecurityAltID N The value in this field will always be “2”. 455 Security AltID N Identification number for the security.


Tag Field Name Req Description 456 SecurityAlt IDSource N Type of security identification number used.

Required if SecurityAltID(455) is specified.

Value Meaning 4 ISIN 8 Instrument identifier

461 CFICode N Indicates the instrument type. Currently not used by Oslo Børs.

167 SecurityType N Indicates the instrument type. Please refer to OSLMIT Oslo Børs Market Model Equities for the valid security types.

423 PriceType N Quotation format for the instrument. Absence of this field should be interpreted as Price Per Unit (2).

Value Meaning 1 Percent of Par 2 Price Per Unit

15 Currency N Trading currency of the instrument 1310 NoMarketSegments N Number of segments the instrument is assigned

to. The value in this field will always be “1”. 1300 Market SegmentID N Indicates the segment. Valid segments are found

in OSLMIT Oslo Børs Market Model Equities. 9303 RoutingInst N Indicate the liquidity pool. Absence of this field

should be interpreted as Lit Order Book (I).

Value Meaning I Lit Order book M Dark Midpoint Order book

27014 Confirmation Interval N Confirmation Interval for the instrument. Will be given in milliseconds. This applies only for the Block trading feature for Dark Book instruments. The Block trading feature is currently not utilized by Oslo Børs.


FAST Template Tag Field Name Field Type Field Encoding Description 1180 ApplID ASCII String Default 1181 ApplSeqNum Unsigned Integer

with NULL support Increment

320 SecurityReqID ASCII String Copy 323 Security

Response Type Unsigned Integer with NULL support

None

912 LastRpt Requested

ASCII String Default N

965 SecurityStatus ASCII String Copy 454 NoSecurityAltID Unsigned Integer

with NULL support Default 3

455 SecurityAltID ASCII String Copy 456 SecurityAltID

Source ASCII String Copy

461 CFICode ASCII String Copy 167 SecurityType ASCII String Copy 423 PriceType Unsigned Integer Copy 15 Currency ASCII String Copy 1310 NoMarket

Segments Unsigned Integer Constant 1

1300 Market SegmentID ASCII String Copy 9303 RoutingInst ASCII String None 27014 Confirmation Interval Unsigned Integer None


5.5.2 Security Definition – Fixed Income FIX Message Tag Field Name Req Description 1180 ApplID Y Identifier of the server sending the message. 1181 ApplSeqNum N Sequence number of the message on the real-time


320 SecurityReqID N Identifier of the Security Definition Request this message relates to. Required if the message is disseminated via the recovery channel.

323 SecurityResponseType N Type of response. Required if the message is disseminated via the recovery channel.

Value Meaning 4 List of Securities Returned 6 Cannot Match Selection

Criteria

912 LastRptRequested N Indicates the last message sent in response to a request.


965 SecurityStatus N Status of the instrument.

Value Meaning 1 Active 2 Inactive 8 Halted 9 Suspended

454 NoSecurityAltID N The value in this field will always be “2”. 455 Security AltID N Identification number for the security.


Tag Field Name Req Description 456 SecurityAlt IDSource N Type of security identification number used.

Required if SecurityAltID(455) is specified.

Value Meaning 4 ISIN 8 Instrument identifier

461 CFICode N Indicates the instrument type. Currently not used by Oslo Børs.

167 SecurityType N Indicates the instrument type. Please refer to OSLMIT Oslo Børs Market Model Fixed Income and for the valid security types.

423 PriceType N Quotation format for the instrument. Absence of this field should be interpreted as Price Per Unit (2).

Value Meaning 1 Percent of Par 2 Price Per Unit 9 Yield

15 Currency N Trading currency of the instrument 1310 NoMarketSegments N Number of segments the instrument is assigned

to. The value in this field will always be “1”. 1300 Market SegmentID N Indicates the segment. Valid segments are found

in OSLMIT Oslo Børs Market Model Fixed Income.


FAST Template Tag Field Name Field Type Field Encoding Description 1180 ApplID ASCII String Default 1181 ApplSeqNum Unsigned Integer with

NULL support Increment

320 SecurityReqID ASCII String Copy 323 Security

Response Type Unsigned Integer with NULL support

None



965 SecurityStatus ASCII String Copy 454 NoSecurityAltID Unsigned Integer with

NULL support Default 3

455 SecurityAltID ASCII String Copy 456 SecurityAltID

Source ASCII String Copy

461 CFICode ASCII String Copy 167 SecurityType ASCII String Copy 423 PriceType Unsigned Integer Copy 15 Currency ASCII String Copy 1310 NoMarket

Segments Unsigned Integer Constant 1

1300 Market SegmentID ASCII String Copy


5.5.3 Security Status - Equity FIX Message Tag Field Name Req Description 1180 ApplID Y Identifier of the server sending the message. 1181 ApplSeqNum Y Sequence number of message on real-time


48 SecurityID N Identification number for the security. 22 SecurityIDSource N Type of security identification number used.

Required if SecurityID(48) is specified.


326 SecurityTradingStatus

Y Indicates the current trading session for the instrument.

Value Meaning 2 Halt 17 Regular Trading/Trade Reporting 18 Market Close 21 Opening Auction Call 26 Post Close 100 Pre-Trading 102 Closing Auction Call 103 End of Post Close 104 Re-Opening Auction Call 106 Pre Open Entry 107 Pre Closing Entry 108 Issuing_Buyback Auction Call 109 Admin 110 Issuing_Buyback Special Entry 111 Pause 113 Order Entry 125 Closing Price Publication 126 Pre-Trade Reporting 127 Intra-day Auction 199 No Active Session

1174 SecurityTradingEvent N Indicates the reason a trading session is extended or shortened.


Tag Field Name Req Description Value Meaning 1 Market Order Extension 100 Price Monitoring Extension 101 Extended by Market Operations 102 Shortened by Market Operations 103 Circuit Breaker Tripped

1173 MDSubBookType N Type of trading to which the update relates. Absence of this field should be interpreted as On-Book (1).


58 Text N Time the Trading Session will end in the case of a session extension or shortening or if available circuit breaker tripped. The time will be specified in the local market time (i.e. not in UTC) and in the HH:MM:SS format.

327 HaltReason N Reason for the trading halt. Please refer to Section 6 for an explanation of the reason codes. Required if SecurityTradingStatus(326) is Halt (2) or Re-Opening Auction Call(104).

9303 RoutingInst N Indicate the liquidity pool. Absence of this field should be interpreted as Lit Order Book (I).

Value Meaning I Lit Order book M Dark Midpoint Order book

FAST Template Tag Field Name Field Type Field Encoding Value 1180 ApplID ASCII String Default 1181 ApplSeqNum Unsigned Integer with


48 SecurityID ASCII String None 22 SecurityIDSource ASCII String None


326 SecurityTrading Status

Unsigned Integer Copy

1174 SecurityTrading Event

Unsigned Integer with NULL support

Copy

1173 MDSubBookType Unsigned Integer Default 1 58 Text ASCII String Copy 327 HaltReason Unsigned Integer with

NULL support Copy

9303 RoutingInst ASCII String Copy

5.5.4 Security Status – Fixed Income FIX Message Tag Field Name Req Description 1180 ApplID Y Identifier of the server sending the message. 1181 ApplSeqNum Y Sequence number of message on real-time





326 SecurityTradingStatus

Y Indicates the current trading session for the instrument.

Value Meaning 2 Halt 17 Regular Trading/Trade Reporting 18 Market Close 21 Opening Auction Call 26 Post Close 100 Pre-Trading 102 Closing Auction Call 103 End of Post Close 104 Re-Opening Auction Call 106 Pre Open Entry 107 Pre Closing Entry 108 Issuing_Buyback Auction Call 109 Admin 110 Issuing_Buyback Special Entry


Tag Field Name Req Description

111 Pause 113 Order Entry 125 Closing Price Publication 126 Pre-Trade Reporting 127 Intra-day Auction 199 No Active Session

1174 SecurityTradingEvent N Indicates the reason a trading session is extended or shortened.

Value Meaning 1 Market Order Extension 100 Price Monitoring Extension 101 Extended by Market Operations 102 Shortened by Market Operations 103 Circuit Breaker Tripped



58 Text N Time the Trading Session will end in the case of a session extension or shortening or if available circuit breaker tripped. The time will be specified in the local market time (i.e. not in UTC) and in the HH:MM:SS format.

327 HaltReason N Reason for the trading halt. Please refer to Section 6 for an explanation of the reason codes. Required if SecurityTradingStatus(326) is Halt (2) or Re-Opening Auction Call(104).


FAST Template Tag Field Name Field Type Field Encoding Value 1180 ApplID ASCII String Default 1181 ApplSeqNum Unsigned Integer with


48 SecurityID ASCII String None 22 SecurityIDSource ASCII String None 326 SecurityTrading

Status Unsigned Integer Copy

1174 SecurityTrading Event


Copy

1173 MDSubBookType Unsigned Integer Default 1 58 Text ASCII String Copy 327 HaltReason Unsigned Integer with

NULL support Copy

5.5.5 Market Data Snapshot (Full Refresh) FIX Message Tag Field Name Req Description 1180 ApplID Y Identifier of the server sending the message. 1181 ApplSeqNum N Sequence number of message on real-time

channel. Required if message is disseminated via the real-time or replay channel.

893 LastFragment N Indicates the last message in a series of Order Book snapshot messages for the instrument.

Value Meaning Y Last Message N Not last Message

If the value does not exist the message will be considered as the last snapshot message.

262 MDReqID N Identifier of the Market Data Request this message relates to. Required if the message is disseminated via the recovery channel.

369 LastMsgSeqNum Processed N ApplSeqNum(1181) of the last incremental update on the real-time channel with which the snapshot is synchronised. Required if the message is disseminated via the recovery channel.


Tag Field Name Req Description 912 LastRptRequested N Indicates the last message sent in response to a

request.







83 RptSeq Y If the message is disseminated via the recovery channel, this field identifies the instrument specific sequence number of the last message on the real-time channel with which the snapshot is synchronized. If the message is disseminated via the real-time or replay channels, this field indicates the instrument specific sequence number of the real-time channel.


Tag Field Name Req Description 1682 MDSecurityTrading Status

N Indicates the trading status of the instrument. Required if the message is sent in the Recovery channel.

Value Meaning 2 Halt 17 Regular Trading/Trade

Reporting 18 Market Close 21 Opening Auction Call 26 Post Close 100 Pre-Trading 101 Suspended 102 Closing Auction Call 104 Re-Opening Auction Call 106 Pre Open Entry 107 Pre Closing Entry 108 Issuing_Buyback Auction Call 109 Admin 110 Issuing_Buyback Special Entry 111 Pause 113 Order Entry 125 Closing Price Publication 126 Pre-Trade Reporting 127 Intra-day Auction 199 No Active Session

1684 MDHaltReason N Reason for the trading halt. Please refer to Section 6 for an explanation of the reason codes. Required if MDSecurityTradingStatus(1682) is Halt (2) ) or Re-Opening Auction Call(104).

268 NoMDEntries Y Number of market data entries in the message.


Tag Field Name Req Description 269 MDEntryType

Y Indicates the type of Market Data being published. This will be the first field in the repeating group.

Value Meaning 0 Bid 1 Offer 4 Opening Price 5 Closing Price 7 High Price 8 Low Price 9 VWAP B Volume J Empty Order Book b Market Bid c Market Offer d Turnover e Number of Trades f Previous Close g Last Traded Price - This should

only be updated if the message is generated for a fixed income instrument

z No Statistics h Average Price

278 MDEntryID N Unique identifier of each order. Required if MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by order depth.

270 MDEntryPx N Price of the bid or offer being published. Required if MDEntryType(269) is not Volume (B), Market Bid (b) or Market Offer (c), number of trades (e), Empty Order Book (J), No Statistics (z).

236 Yield N Converted yield value corresponding to the MDEntryPx(270) field for the following; Bid (0), Offer (1), Last Trade Price (g), High Price (7) and Low Price (8) of MDEntryType(269) field. The yield is disseminated in percent, e.g. a yield of ‘5,496583’ will be disseminated as 0.05496583.


Tag Field Name Req Description 271 MDEntrySize N Quantity of the Market Data entry. Required if

MDEntryType(269) is not Opening Price (4), Closing Price (5), High Price (7), Low Price (8), VWAP (9), Highest Bid Price (N) or Lowest Offer Price (O) or Previous Close (f), Turnover (d), Empty Order Book (J), No Statistics (z).



346 NumberOfOrders N Number of orders represented in the aggregate quantity published for a bid or offer. Required if MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the Order Book is published by price depth.

290 MDEntry PositionNo N Display position of the order in the Order Book within its Price Level. Required if MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by order depth.

1023 MDPriceLevel N Display position of the price level in the order book. Required if MDEntryType(269) is Bid (0) or Offer (1).

453 NoPartyIDs N Number of party identifiers. If specified, the value in this field will always be “1”.

448 PartyID N Identifier of the party. Required if NoPartyIDs(453) is specified.

447 PartyID Source

N Required if PartyID(448) is specified.

Value Meaning D Proprietary/Custom Code

452 Party Role N Role of the specified PartyID(448). Required if PartyID(448) is specified.

Value Meaning 1 Trading Firm


Tag Field Name Req Description 1759 OpenClose

Indicator N Method used to compute the opening or closing

price. Required if MDEntryType(269) is Opening Price (4) or Closing Price (5).

Value Meaning 1 Auction Trade 2 Regular Trade 3 Mid-Point (Mid of BBO after

Opening Auction) 6 VWAP (VWAP n minutes) 7 Last Regular Trade 8 Last Auction Trade 9 Previous Close 10 Manual 19 VWAP of Last n Trades 20 Reference Price 22 Best Bid3 23 Best Offer4

FAST Template Tag Field Name Data Type Field Encoding Value 1180 ApplID ASCII String Default 1181 ApplSeqNum Unsigned Integer with


893 LastFragment ASCII String Copy Y 262 MDReqID ASCII String Copy 369 LastMsgSeqNum

Processed Unsigned Integer None



48 SecurityID ASCII String None 22 SecurityIDSource ASCII String None 83 RptSeq Unsigned Integer with

NULL support None

1682 MDSecurity TradingStatus


Copy

1684 MDHaltReason Unsigned Integer with NULL support

Copy

1173 MDSubBookType Unsigned Integer Default 1 268 NoMDEntries Unsigned Integer Default 1

3 Defines the best bid of the day, and is not a source of the current best bid. 4 Defines the best offer of the day, and is not a source of the current best offer.


Tag Field Name Data Type Field Encoding Value 269 MDEntryType ASCII String Copy 278 MDEntryID ASCII String Copy 270 MDEntryPx Scaled Number Copy 236 Yield Scaled Number Copy 271 MDEntrySize Scaled Number Copy 276 QuoteCondition ASCII String Copy 346 NumberOfOrders Unsigned Integer with

NULL support Copy

290 MDEntry PositionNo Unsigned Integer with NULL support

Copy

1023 MDPriceLevel Unsigned Integer Copy 453 NoPartyIDs Unsigned Integer with

NULL support Constant 1

448 PartyID ASCII String Copy 447 PartyIDSource ASCII String Copy 452 PartyRole Unsigned Integer with

NULL support Copy

1759 OpenClose Indicator


Copy


5.5.6 Market Data Incremental Refresh – Fixed Income FIX Message Tag Field Name Req Description 1180 ApplID Y Identifier of the server sending the message.

1181 ApplSeqNum N Sequence number of message on the real-time channel.

262 MDReqID N Identifier of the Market Data Request this message relates to. Required if the message is disseminated via the recovery channel.

912 LastRptRequested N Indicates the last message sent in response to a retransmission request.


268 NoMDEntries Y Number of Market Data entries in the message.

279 MDUpdateAction Y Indicates the update type.

Value Meaning 0 New 1 Change 2 Delete

1173 MDSubBook Type

N Type of trading to which the update relates. Absence of this field should be interpreted as On-Book (1).




Y Indicates the type of Market Data being published. Only Bid (0) and Offer (1) are applicable for FIX/FAST Gateway. All the values except Bid (0) and Offer (1) are applicable for FIX/FAST Trade Only Gateway.

Value Meaning 0 Bid 1 Offer 2 Trade 7 High Price 8 Low Price 9 VWAP B Volume Q Auction Clearing Price b Market Bid c Market Offer d Turnover e Number of Trades g Last Traded Price h Average Price

278 MDEntryID N Unique identifier of a Market Data entry. Required if MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by order depth. Required if MDEntryType(269) is Trade (2)





Tag Field Name Req Description 270 MDEntryPx

N Applicable price of an order, a price point or a trade. Required if MDUpdateAction(279) is New (0) or Change (1) and if MDEntryType(269) is not Volume (B), Market Bid (b) or Market Offer (c), number of trades (e). Please note that the value in this field may be NULL, if the instrument does not have any price set in the system. High and Low may be disseminated without MDEntryPx(270) field in the scenarios where High or Low is removed (i.e. cancelling all trades).

236 Yield N Converted yield value corresponding to the MDEntryPx(270) field for the following; Trade (2), Bid (0), Offer (1), Last Trade Price (g), High Price (7) and Low Price (8) of the MDEntryType(269) field. The yield is disseminated in percent, e.g. a yield of ‘5,496583’ will be disseminated as 0.05496583.

120 SettlCurrency N Currency in which a trade has occurred other than for the trading currency of the relevant instrument. (Specific for off-book trades).5 The possible values will be the ISO 4217 codes for currency.

271 MDEntrySize N Quantity of the Market Data entry. Required if MDUpdateAction(279) is New (0) or Change (1) and MDEntryType(269) is not High Price (7), Low Price (8), VWAP (9) or Turnover (d).

272 MDEntryDate N Date the off-book trade being published was executed. The date will be specified in UTC and in the YYYYMMDD format. Required if TrdSubType(829) is specified.

273 MDEntryTime N Time the trade being published was executed. The time will be specified in UTC and in the HH:MM:SS.sss format. Required if MDEntryType(269) is Trade (2).

5 If SettlementCurency (120) and OriginalPrice(1769) has been specified in the off book trade entered in to the system, but the SettlementCurency is same as the currency specified on the instrument then the SettlementCurency will not be disseminated for off book trades via FAST Market data gateway. However the OriginalPrice will still be disseminated.


Tag Field Name Req Description 275 MDMkt N The possible values will be the ISO 10383 codes for

Exchange ID. However the following values too will be disseminated.

Value Meaning SI Systematic Internaliser XOFF OTC Trade

276 QuoteCondition N Will be used to indicate closing bid and offer price together with MDEntryType(269) of Bid (0) and Offer (1) respectively.


277 TradeCondition N Indicates the type of auction a trade was executed in.

Value Meaning R Opening Price w Re-Opening Price AJ Closing Price IB Issuing or Buy Back Price

Required if MDEntryType(269) is Trade (2) and MatchType(574) is Auction (5).

828 TrdType N

Value Meaning 30 SP (Special Price)/Bargain

Condition Indicator (Specific for off-book trades)

574 MatchType N Whether a trade was executed in an auction.

Value Meaning 5 Auction

346 NumberOfOrders N Number of orders represented in the aggregate quantity published for a bid or offer. Required if MDUpdateAction(279) is New (0) or Change (1), MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by price depth.


Tag Field Name Req Description 290 MDEntry PositionNo N Display position of an order in the order book

within a price Level. Required if MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by order depth.

1023 MDPriceLevel N Display position of a price level in the order book. Required if MDEntryType(269) is Bid (0) or Offer (1).

1070 MDQuoteType N Value Meaning 0 Indicative

Required if MDEntryType(269) is Auction Clearing Price (Q).

83 RptSeq

N Instrument specific sequence number of update.



447 PartyID Source



452 Party Role

N Role of the specified PartyID(448). Required if PartyID(448) is specified.


829 TrdSubType N Type of off-book trade. Please refer to the Trade Type reference data file described in OSLMIT 401 Reference Data and further description in OSLMIT Oslo Børs Model Equities and OSLMIT Oslo Børs Market Model Fixed Income. This will be tagged when the MDEntryType(269) is Trade (2).


Tag Field Name Req Description 5797 AggressorSide N Aggressor side of a trade.

Value Meaning 1 Buyer 2 Seller

Required when MDEntryType(269) is Trade (2). Will not be indicated for auction trades, off-book trades and off-book trade cancellations.

1769 OriginalPrice N Price in the execution currency. (Specific for off-book trades).

1759 OpenClose Indicator

N N/A

1132 TZTransactTime N Transact time in the local market date-time stamp with a TZ offset to UTC identified. Required for both on book trades and off-book trades

64 SettlDate N Date on which the trade will settle. 916 StartDate N Indicates the first settlement date of the repo

trade. (Required for repo trades)

917 EndDate N Indicates the second settlement date of the repo trade. (Required for repo trades)




262 MDReqID ASCII String Copy 912 LastRpt

Requested ASCII String Default N

1173 MDSubBookType Unsigned Integer Default 1 268 NoMDEntries Unsigned Integer Default 1 279 MDUpdateAction Unsigned Integer Copy 269 MDEntryType ASCII String Copy 278 MDEntryID ASCII String Copy 48 SecurityID ASCII String None 22 SecurityIDSource ASCII String None 270 MDEntryPx Scaled Number Copy 236 Yield Scaled Number Copy 120 SettlCurrency ASCII String Copy 271 MDEntrySize Scaled Number Copy 272 MDEntryDate ASCII String Tail 273 MDEntryTime ASCII String Tail 275 MDMkt ASCII String Copy 276 QuoteCondition ASCII String Copy 277 TradeCondition ASCII String Copy 828 TrdType Unsigned Integer with

NULL support Copy

574 MatchType ASCII String Copy 346 NumberOfOrders Unsigned Integer with

NULL support Copy


Default 1

1023 MDPriceLevel Unsigned Integer Copy 1070 MDQuoteType


Copy

83 RptSeq Unsigned Integer with NULL support

Increment

453 NoPartyIDs Unsigned Integer with NULL support

Constant 1


NULL support Copy

829 TrdSubType Unsigned Integer with NULL support

Copy


Tag Field Name Field Type Field Encoding Description 5797 AggressorSide Unsigned Integer Copy 1769 Original Price Scaled Number Copy 1759 OpenCloseIndicator Unsigned Integer with

NULL support Copy

1132 TZTransactTime ASCII String Copy 64 SettlDate ASCII String Tail 916 StartDate ASCII String Tail 917 EndDate ASCII String Tail


5.5.7 Market Data Incremental Refresh – Equity FIX Message Tag Field Name Req Description 1180 ApplID Y Identifier of the server sending the message. 1181 ApplSeqNum N Sequence number of message on the real-time

channel. 262 MDReqID N Identifier of the Market Data Request this message

relates to. Required if the message is disseminated via the recovery Channel.

912 LastRptRequested N Indicates the last message sent in response to a retransmission request.


268 NoMDEntries Y Number of market data entries in the message. 279 MDUpdate Action Y Indicates the update type.

Value Meaning 0 New 1 Change 2 Delete


Value Meaning 1 On-Book 2 Off-Book



Y Indicates the type of market data being published.

Value Meaning 0 Bid 1 Offer 2 Trade 4 Opening Price 5 Closing Price 7 High Price 8 Low Price 9 VWAP B Volume Q Auction Clearing Price b Market Bid c Market Offer d Turnover e Number of Trades f Previous Close

278 MDEntryID N Unique identifier of a market data entry. Required if MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by order depth. Required if MDEntryType(269) is Trade (2).

48 SecurityID Y Identification number for the security. 22 SecurityIDSource N Type of security identification number used.



270 MDEntryPx N Price of the market data entry. Required if MDUpdateAction(279) is New (0) or Change (1) and MDEntryType(269) is not Volume (B), Market Bid (b) or Market Offer (c), Number of Trades (e). Please note that the value in this field may be NULL, if the instrument does not have any price set in the system. High and Low may be disseminated without MDEntryPx field in the scenarios where High or Low is removed (i.e. cancelling all trades).


Tag Field Name Req Description 120 SettlCurrency N Currency in which a trade has occurred other than

for the trading currency of the relevant instrument. (Specific for off-book trades).6 The possible values will be the ISO 4217 codes for currency.

271 MDEntrySize N Quantity of the market data entry. Required if MDUpdateAction(279) is New (0) or Change (1) and MDEntryType(269) is not Opening Price (4), Closing Price (5), High Price (7), Low Price (8), VWAP (9), Highest Bid Price (N), Lowest Offer Price (O) or Previous Close (f), Turnover (d).

272 MDEntryDate N Date the off-book trade being published was executed. The date will be specified in UTC and in the YYYYMMDD format. Required if TrdSubType(829) is specified.

273 MDEntryTime N Time the trade being published was executed. The time will be specified in UTC and in the HH:MM:SS.sss format. Required if MDEntryType(269) is Trade (2).

275 MDMkt N The possible values will be the ISO 10383 codes for Exchange ID. However the following values too will be disseminated.

Value Meaning SI Systematic Internaliser XOFF OTC Trade

276 QuoteCondition N

Will be used to indicate closing bid and offer price together with MDEntryType(269) of Bid (0) and Offer (1) respectively.


6 If SettlementCurency (120) and OriginalPrice(1769) has been specified in the off book trade entered in to the system, but the SettlementCurency is same as the currency specified on the instrument then the SettlementCurency will not be disseminated for off book trades via FAST Market data gateway. However the OriginalPrice will still be disseminated.


Tag Field Name Req Description 277 TradeCondition N Indicates the type of auction a trade was executed in.

Value Meaning R Opening Price w Re-Opening Price AJ Closing Price

M Late Trade (specific for off-book trades)

IA Intra-day Auction Price If MDEntryType(269) is Trade (2) and MatchType(574) is Auction (5) for on book trades. Also required for off-book trades when the trade reported is a late trade.

828 TrdType N

Value Meaning 30 SP (Special Price)/Bargain

Condition Indicator (Specific for Off Book trades)

574 MatchType N Whether a trade was executed in an auction.

Value Meaning 5 Auction

288 MDEntryBuyer N Buying party (Firm) in a trade. May be populated when MDEntryType(269) is Trade (2) for Oslo Børs.

289 MDEntrySeller N Selling party (Firm) in a trade. May be populated when MDEntryType(269) is Trade (2) for Oslo Børs.

346 NumberOfOrders N Number of orders represented in the aggregate quantity published for a bid or offer. Required if MDUpdateAction(279) is New (0) or Change (1), MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by price depth.

290 MDEntry PositionNo N Display position of an order in the order book within a price level. Required if MDEntryType(269) is Bid (0), Offer (1), Market Bid (b) or Market Offer (c) and the order book is published by order depth.

1023 MDPriceLevel N Display position of a price level in the Order Book. Required if MDEntryType(269) is Bid (0) or Offer (1).


Tag Field Name Req Description 1070 MDQuoteType N

Value Meaning 0 Indicative

Required if MDEntryType(269) is Auction Clearing Price (Q).

83 RptSeq

N Instrument specific sequence number of update.



447 PartyID Source



452 Party Role N Role of the specified PartyID(448). Required if PartyID(448) is specified.


829 TrdSubType N Type of off-book trade. Please refer to the Trade Type reference data file described in OSLMIT 401 Reference Data and further description in OSLMIT Oslo Børs Model Equities and OSLMIT Oslo Børs Market Model Fixed Income. This will be tagged when the MDEntryType(269) is Trade (2).

5797 AggressorSide N Aggressor side of a trade.

Value Meaning 1 Buyer 2 Seller

Required when MDEntryType(269) is Trade (2). Will not be indicated for auction trades, off-book trades and off-book trade cancellations.

1769 OriginalPrice N Price in the execution currency. (Specific for off-book trades)


Tag Field Name Req Description 1759 OpenCloseIndicator N Method used to compute the opening or closing

price. Required if MDEntryType(269) is Opening Price (4) or Closing Price (5).

Value Meaning 1 Auction Trade 2 Regular Trade 3 (Mid-Point) Mid of BBO after

opening auction 6 VWAP (VWAP n mins) 7 Last Regular Trade 8 Last Auction Trade 9 Previous Close 10 Manual 19 VWAP of Last n Trades 20 Reference Price 21 Price Unavailable 22 Best Bid7 23 Best Offer8

9303 RoutingInst N Indicate the liquidity pool. Absence of this field should be interpreted as Lit Order book (I).

Value Meaning I Lit Order book M Dark Midpoint order book

1132 TZTransactTime N Transact time in the local market date-time stamp with a TZ offset to UTC identified. Required for both on book trades and Off Book trades.

7 Defines the best bid of the day, and is not a source of the current best bid. 8 Defines the best offer of the day, and is not a source of the current best offer.




262 MDReqID ASCII String Copy 912 LastRptRequested ASCII String Default N 1173 MDSubBookType Unsigned Integer Default 1 268 NoMDEntries Unsigned Integer Default 1 279 MDUpdateAction Unsigned Integer Copy 269 MDEntryType ASCII String Copy 278 MDEntryID ASCII String Copy 48 SecurityID ASCII String None 22 SecurityIDSource ASCII String None 270 MDEntryPx Scaled Number Copy 120 SettlCurrency ASCII String Copy 271 MDEntrySize Scaled Number Copy 272 MDEntryDate ASCII String Tail 273 MDEntryTime ASCII String Tail 275 MDMkt ASCII String Copy 276 QuoteCondition ASCII String Copy 277 TradeCondition ASCII String Copy 828 TrdType Unsigned Integer with

NULL support Copy

574 MatchType ASCII String Copy 288 MDEntryBuyer ASCII String Copy 289 MDEntrySeller ASCII String Copy 346 NumberOfOrders Unsigned Integer with

NULL support Copy


Default 1

1023 MDPriceLevel Unsigned Integer Copy 1070 MDQuoteType


Copy

83 RptSeq Unsigned Integer with NULL support

Increment

453 NoPartyIDs Unsigned Integer with NULL support

Constant 1


NULL support Copy

829 TrdSubType Unsigned Integer with NULL support

Copy


Tag Field Name Field Type Field Encoding Description 5797 AggressorSide Unsigned Integer Copy 1769 Original Price Scaled Number Copy 1759 OpenCloseIndicator Unsigned Integer with

NULL support Copy

9303 RoutingInst ASCII String None 1132 TZTransactTime ASCII String Copy

5.5.8 Market Data Request Reject FIX Message Tag Field Name Req Description 262 MDReqID Y Identifier of the request being rejected. 281 MDReqRej Reason Y Code specifying the reason for the rejection.

Please refer to Section 7.1 for a list of reject codes.

58 Text N Oslo Børs specific code specifying the reason for the reject. Please refer to Section 7.1 for a list of reject codes.

FAST Template Tag Field Name Field Type Field Encoding Description 262 MDReqID ASCII String None 281 MDReqRejReason ASCII String None 58 Text ASCII String None


5.5.9 Business Message Reject FIX Message Tag Field Name Req Description 379 BusinessRejectRefID N SecurityReqID(320), MDReqID(262) or ApplReqID

(1346) of the rejected message. 371 RefTagID N If a message is rejected due to an issue with a

particular field its tag number will be indicated. 372 RefMsgType N MsgType(35) of the rejected message. 380 BusinessReject Reason Y Code specifying the reason for the reject. Please

refer to Section 7.2 for a list of reject codes. 58 Text N Oslo Børs specific code specifying the reason for

the reject. Please refer to Section 7.2 for a list of reject codes.

FAST Template Tag Field Name Field Type Field Encoding Description 379 BusinessReject RefID ASCII String None 372 RefMsgType ASCII String None 371 RefTagID Unsigned Integer

with NULL support None

380 BusinessReject Reason


None

58 Text ASCII String None


5.5.10 Application Message Request Ack FIX Message Tag Field Name Req Description 1353 ApplResponseID Y Server specified identifier of the

acknowledgement. 1346 ApplReqID Y Identifier of the request being acknowledged. 1347 ApplReqType Y Type of request being acknowledged.

Value Meaning 0 Retransmission of Messages 5 Cancel Retransmission

1348 ApplResponseType Y Whether the request was successful.

Value Meaning 0 Request Successful 1 Unknown ApplID 2 Messages Not Available

FAST Template Tag Field Name Field Type Field Encoding Description 1353 ApplResponseID String None 1346 ApplReqID String None 1347 ApplReqType Unsigned Integer None 1348 ApplResponse Type Unsigned Integer None


5.5.11 Application Message Report FIX Message Tag Field Name Req Description 1356 ApplReportID Y Server specified identifier of the report. 1346 ApplReqID Y Identifier of the Application Message Request the

report relates to. 1426 ApplReportType Y

Value Meaning 3 Retransmission Completed

FAST Template Tag Field Name Field Type Field Encoding Description 1356 ApplReportID String None 1346 ApplReqID String None 1426 ApplReportType Unsigned Integer None


6. Trading Halt Reason Codes Code Reason 1 Price movement 2 Received announcement 3 In anticipation of announcement 4 System problems 5 Other 6 Reference data update 100 Reason not available 101 Instrument-level circuit breaker tripped 9998 Matching partition suspended 9999 System suspended

7. Reject Codes

7.1 Market Data Request Reject MDReqRejReason Text Reason 0 - Unknown instrument 4 - Unsupported SubscriptionRequestType 8 - Unsupported MDEntryType Z - Other Z 101 Unknown segment Z 102 Requested market data unavailable for instrument Z 150 No missed trades

7.2 Business Message Reject Business Reject Reason

Text Reason

0 400 Other 0 403 Incorrect data format for this tag 0 404 Value is invalid for this tag 0 449 Concurrent Request Limit Reached 0 450 Request limit for day reached 1 - Unknown ID 3 - Unsupported message type 5 - Conditionally required field missing


8. Scenarios 8.1 Specific Market Data request The client will only request either order book or statistics or missed trades in the Market Data Request message. Once connected to the recovery channel, client sends a Market Data Request message requesting the following; 8.1.1 Order Book snapshots for a segment Scenario FAST GW All the Market Data are available

A series of Market Data Snapshot (Full Refresh) messages will be sent with the order book snapshots for each instrument and the last message sent in response will have the LastRptRequested field tagged.

One or more instruments have empty on-book

A series of Market Data Snapshot (Full Refresh) messages will be sent with the order book snapshots for each instrument with active orders in the Order Book and Empty Order Book Snapshot messages for the instruments with empty order book and the last message sent in response will have the LastRptRequested field tagged.

One or more instruments do not have on-book trading definition attached

A series of Market Data Snapshot (Full Refresh) messages will be sent with the Order Book snapshots for each instrument with active orders in the order book and the last message sent in response will have the LastRptRequested field tagged, which will impliedly indicate to the user that some instruments did not have the requested market data (due to not having the on-book trading definition attached).

All the instruments in the segment have empty On book

A series of Empty Order Book Market Data Snapshot (Full Refresh) messages will be sent for each instrument and the last message sent in response will have the LastRptRequested field tagged.

All the instruments in the segment doesn’t have On book trading definition attached

The Request should be rejected with a Market Data Request Reject message with the reject reason ‘Requested Market Data unavailable’

8.1.2 Statistics snapshots for a segment Scenario FAST GW All the Market Data are available

A series of Market Data Snapshot (Full Refresh) messages will be sent with the Statistics snapshots for each instrument and the last message sent in response will have the LastRptRequested field tagged.

One or more instruments does not have any updated statistics

A series of Market Data Snapshot (Full Refresh) messages will be sent with the Statistics snapshots for each instrument with updated statistics and ‘No Statistics’ Snapshot messages for the instruments with no updated statistics. The last message sent in response will have the LastRptRequested field tagged.

All the instruments in the segment do not have any updated statistics

A series of ‘No Statistics’ Market Data Snapshot (Full Refresh) messages will be sent for each instrument and the last message sent in response will have the LastRptRequested field tagged.


8.1.3 Missed trades for a segment Scenario FAST GW a. All the Market Data are

available

A series of Market Data Incremental Refresh Messages will be sent with the missed trades for each instrument and the last message sent in response will have the LastRptRequested field tagged.

b. One or more instruments does not have any missed trades

A series of Market Data Incremental Refresh Messages will be sent with the missed trades for each instrument with the relevant missed trades and no messages should be sent for the instruments with no missed trades. The last message sent in response will have the LastRptRequested field tagged.

8.1.4 Order Book Snapshots for an Instrument Scenario FAST GW Instrument has the requested Market Data

A Market Data Snapshot (Full Refresh) Message will be sent with the Order Book snapshot for the instrument and the message will have the LastRptRequested field tagged.

Instrument has an empty Order Book

An Empty Order Book Market Data Snapshot (Full Refresh) message will be sent for the instrument and the last message sent in response will have the LastRptRequested field tagged.

Instrument doesn’t have On book trading definition attached

Request should be rejected with a Market Data request reject message with the reject reason ‘Requested Market Data unavailable’

8.1.5 Statistics snapshots for an Instrument Scenario FAST GW Instrument has the requested Market Data

A Market Data Snapshot (Full Refresh) message will be sent with the Statistics snapshot for the instrument and the last message sent in response will have the LastRptRequested field tagged.

Instrument does not have any updated statistics

A ‘No Statistics’ Market Data Snapshot (Full Refresh) message will be sent for the instrument and the last message sent in response will have the LastRptRequested field tagged.

8.1.6 Missed trades for an Instrument Scenario FAST GW Instrument has the requested Market Data

A series of Market Data Incremental Refresh messages will be sent with the missed trades for the instrument and the last message sent in response will have the LastRptRequested field tagged.

Instrument does not have any missed trades

The Request should be rejected with a Market Data Request Reject message with the reject reason ‘Requested Market Data unavailable’


8.2 Multiple Market Data request The client will request a combination of Market Data Order Book, statistics and missed trades in the Market Data Request message. Once connected to the FIX/FAST Gateway Recovery Channel, client sends a single Market Data Request message requesting the following;

8.2.1 Multiple Market Data (Order Book, Trades, Statistics) for a Single Instrument Scenario FAST GW All the requested Market Data are available

A series of Market Data Incremental Refresh messages and Market Data Snapshot (Full Refresh) messages will be sent with all the market data and the last message sent in response will have the LastRptRequested field tagged

Certain Market Data are not available - due to Empty Order Book, No missed trades etc.

A series of Market Data Incremental Refresh messages and Market Data Snapshot (Full Refresh) messages will be sent with all the available Market Data. Empty Order Book Snapshot messages and ‘No Statistics’ snapshot messages will also be sent for the instruments with empty Order Book and no updated statistics. The last message sent in response will have the LastRptRequested field tagged

Certain Market Data are not available – Instrument not having normal book attached

A series of Market Data Incremental Refresh messages and Market Data Snapshot (Full Refresh) messages will be sent with all the available Market Data and the last message sent in response will have the LastRptRequested field tagged which will imply to the user that some instruments did not have the requested Market Data

None of the Market Data are available - due to Empty Order Book, No missed trades etc.

A series of Empty Order Book Snapshot messages and ‘No Statistics’ snapshot messages will be sent for the instruments with empty Order Book and no updated statistics. The last message sent in response will have the LastRptRequested field tagged.

8.2.2 Multiple Market Data (Order Book, Trades, Statistics) for a Segment Scenario FAST GW All the requested Market Data are available

A series of Market Data Incremental Refresh messages and Market Data Snapshot (Full Refresh) Messages will be sent with all the market data for each instrument and the last message sent in response will have the LastRptRequested field tagged.

Certain Market Data are not available - due to Empty Order Book, No missed trades… etc

A series of Market Data Incremental Refresh messages and Market Data Snapshot (Full Refresh) Messages will be sent with all the available Market Data for each instrument. Empty Order Book Snapshot messages and ‘No Statistics’ snapshot messages will also be sent for the instruments with empty Order Book and no updated statistics. The last message sent in response will have the LastRptRequested field tagged.

Certain Market Data are not available - Instruments not having statistics available

A series of Market Data Incremental Refresh messages and Market Data Snapshot (Full Refresh) Messages will be sent with all the available Market Data and the last message sent in response will have the LastRptRequested field tagged which will imply to the user that some instruments did not have the


requested market data. None of the Market Data are available - due to Empty Order Book, No missed trades…etc

A series of Empty Order Book Snapshot messages and ‘No Statistics’ snapshot messages will be sent for each instrument with empty Order Book and no updated statistics. The last message sent in response will have the LastRptRequested field tagged.


Appendix 1 – Issue Updates This appendix describes the details of the changes made in each issue of this document. Issue 4.0 – Released 01 December 2014 New issue of the document to include all North Sea changes. Changes are made to the following sections: Chapter Description 1. Introduction Updated introduction to reflect introduction of North Sea in April

2015. 3.3.1 Trading on the Book Describes how Security Status messages for the Dark Midpoint

book are identified. 3.3.3 List of Instruments Added description of how Instruments with a Dark Midpoint

book will be published. 3.3.4 Trading Status Security status messages are also sent for the Dark Midpoint

book. 3.8 Statistics Added Dark Book behavior. 4.5.3 Requesting Missed Trades Added Dark Book behavior. 5.1 Variations from the FIX Protocol Added bullet 32. 5.4.2 / 5.4.3 Market data request Split the message into an Equities and a Fixed Income version.

Added field RoutingInst(9303) for the Equities version. 5.5.1 / 5.5.2 Security Definition Split the message into an Equities and a Fixed Income version.

Added fields RoutingInst(9303) and Confirmation Interval(27014) for the Equities version.

5.5.3 / 5.5.4 Security Status Split the message into an Equities and a Fixed Income version. Added field RoutingInst(9303) for the Equities version.

5.5.7 Market Data Incremental Refresh - Equities

Added field RoutingInst(9303).

Issue 4.1 – Released 23 February 2014 Chapter Description 5.5.2 Security Definition – Fixed Income Added Yield(9) as a possible value of the field PriceType(423)

Issue 4.2 – Released 28 April 2015 Removed references to the Burgundy market. In addition changes are made to the following sections: Chapter Description 5.5.3 Security Status – Equities 5.5.4 Security Status – Fixed Income

Updated description of the field HaltReason(327)

5.5.5 Market Data Snapshot (Full Refresh) Updated description of the field MDHaltReason(1684)


Appendix 2 – References For the corresponding Millennium Exchange documentation for Borsa Italiana and London Stock Exchange, please see: http://www.borsaitaliana.it/borsaitaliana/gestione-mercati/migrazionemillenniumit-mit/millenniumitmigration.en.htm http://www.londonstockexchange.com/products-and-services/millennium-exchange/technicalinformation/technicalinformation.htm

http://www.londonstockexchange.com/products-and-services/millennium-exchange/technicalinformation/technicalinformation.htm

http://www.londonstockexchange.com/products-and-services/millennium-exchange/technicalinformation/technicalinformation.htm

Documents

Oslo Børs Holding · This document has been produced by Oslo Børs to assist customers in the use of the Millennium platform on the Oslo Børs market place. Part of the documentation