Millennium Exchange - Oslo Børs cash equities and fixed income markets. OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2)

Transcription

1 Millennium Exchange - Oslo Børs cash equities and fixed income markets OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) Issue November 2014

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 and Burgundy market places. 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 technicalsupport@oslobors.no Further copies of this document can also be downloaded from the Oslo Børs website 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. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 2

3 Change log This document can be updated at any time, and has been through the following iterations: Issue Date Description February 2012 Initial document release May 2012 First revision, please refer to Appendix 1 for details June 2012 Second revision, please refer to Appendix 1 for details November 2012 New release of the document as the Millennium platform is launched and the migration project is finalized. Minor wording changes to remove references to project and document links updated May 2013 New release of the document to include the Burgundy markets, and a few other amendments. Please refer to Appendix 1 for details February 2014 New release of the document to include all Release 8 changes March 2014 Please refer to Appendix 1 for details April 2014 Please refer to Appendix 1 for details April 2014 Please refer to Appendix 1 for details November 2014 Changed the name of the low latency market data channels and protocol. 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 of the document are described in the appendix. Changes from the previous issue of the document are indicated by a left margin bar. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 3

4 Content Important note... 2 Disclaimer... 2 Change log... 3 Content Introduction Purpose Readership Document series Service Description Services Supported by Trading Gateway Real-Time Connections Non-Real Time Connections Supported Events Open Order Download Execution Reports Order Status Order and Execution Identifiers Client Order IDs Order IDs Private: Public: Execution IDs Trade IDs Instrument Identification Party Identification Price Fields Interpretation Fixed Income Instruments Timestamps and Dates Functional and Implementation Limitations Variations from the FIX Protocol Connectivity CompIDs Passwords Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 4

5 3.2 Partition Identification (AppID) FIX Connections and Sessions Establishing a FIX Connection Simultaneous Logons from Different TCP/IP Connections Simultaneous Logons from the Same TCP/IP Connection Maintaining a FIX Session Message Sequence Numbers Sequence numbers during logon attempt failures Heartbeats Increasing Expected Sequence Number Terminating a FIX Connection Re-Establishing a FIX Session Resetting Sequence Numbers: Starting a New FIX Session Reset Initiated by the Client Reset Initiated by the Server Failover and Recovery Failover Application failover on Primary Data Center Site failover Resend Requests Possible Duplicates Possible Resends Client-Initiated Messages Server-Initiated Messages Transmission of Missed Messages Message Formats Supported Message Types Administrative Messages Application Messages Client-Initiated Server-Initiated Application Messages: Other Server-Initiated Message Header and Trailer Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 5

6 6.3.1 Message Header Message Trailer Administrative Messages Logon Logout Heartbeat Test Request Resend Request Reject Sequence Reset Application Messages Order Mass Status Request Execution Report Application Messages: Others Business Message Reject Reject Codes Reject Execution Report Business Message Reject Appendix 1 Issue updates Issue 1.0 Released 29 February Issue 1.1 Released 07 May Issue 1.2 Released 07 June Issue 2.0 Released 12 November Issue 2.1 Released 03 May Issue 3.0 Released 10 February Issue 3.1 Released 10 February Issue 3.2 Released 30 April Issue 3.3 Released 30 April Issue 3.4 Released 10 November Appendix 2 References Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 6

7 1. Introduction In November 2012, Oslo Børs migrated its equity and fixed income trading from TradElect/Infolect to Millennium Exchange, a flexible, highly scalable trading platform with ultra-low latency from MillenniumIT, a company in the London Stock Exchange Group. The Burgundy Markets were included on the same version of the Millennium platform in June 2013, as part of the completion of the merger between Oslo Børs and the Nordic MTF Burgundy. 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 stateof-the-art trading system as of June Purpose The purpose of this document is to describe the services provided by the Drop Copy Gateway available on the Millennium Exchange platform. The Drop Copy Gateway provides order information through the Execution Report messages, and will provide the information from both the equities and the fixed income markets, as well as for orders entered both through the FIX and Native Trading Gateways. For drop copies of the trades the Post Trade Gateway must be used, see OSLMIT 204 Post Trade Gateway (FIX 5.0 SP2). 1.2 Readership This document describes how to connect to the Drop Copy Gateway and the detailed messages and fields used. 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 series are indicated by use of underlined italic letters. Headers and message definitions are described in detail in section 6. References to FIX fields are given as name(tag), and enumerated values are given as name(value). 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 and Burgundy Market Model Equities OSLMIT Oslo Børs and Burgundy Business Parameters - Equities OSLMIT Oslo Børs and Burgundy Market Model Fixed Income OSLMIT Oslo Børs and Burgundy 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 Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 7

8 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 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 Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 8

9 2. Service Description Oslo Børs offers a drop copy gateway that will enable participants to receive additional copies of the Execution Reports generated by the matching system. This interface may also be used by clients to download the current status of all their active orders in the event of a failure. The drop copy service cannot be used to submit orders or receive market data. The interface is a point-to-point service based on the technology and industry standards TCP/IP, FIXT and FIX. The session and application event models and messages are based on versions 1.1 and 5.0 (Service Pack 2) of the FIXT and FIX protocols respectively. The encryption of messages between the client and server is not supported. 2.1 Services Supported by Trading Gateway A description of the services (e.g. order types, notification of market operations actions, etc.) available via the trading gateway is provided in the FIX specification for this interface, see OSLMIT 202 FIX Trading Gateway (FIX 5.0 SP2), or via the native interface, see OSLMIT 203 Native Trading Gateway, which vendors are encouraged to read together with this specification. 2.2 Real-Time Connections A real-time client will receive a drop copy of each eligible Execution Report immediately after it is published, from orders entered both via the FIX and Native trading gateways. A participant connection will be configured to receive a drop copy of all the Execution Report messages generated for the firm for the events outlined in section 2.4. If required, a firm connection could be configured to only receive drop copies for selected trader groups. For the purpose of redundancy, the service supports the configuration of multiple drop copy connections to send the same information on the activity of the selected firms/trader groups. The identity of the CompID that transmitted the order a particular drop copy relates to will be specified in the header field OnBehalfOfCompID(115). Please refer to section 5.5 for a description of how the Execution Reports published during the time a real-time client is disconnected from the server may be recovered. A real-time client may also use the open order download service (outlined in section 2.5) to recover the status of all active orders in the event of a system failure. 2.3 Non-Real Time Connections Execution Reports will not be streamed to non-real time clients. Such a client may only connect to the server to use the order download service outlined in section 2.5. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 9

10 2.4 Supported Events Clients will receive drop copies of the Execution Reports generated for the following events: (i) Order accepted (ii) Order rejected (iii) Order executed (iv) Order expired (v) Order cancelled (vi) Order cancel/replaced (vii) Trade cancellation (viii) Order Triggered 2.5 Open Order Download Any client may use the Order Mass Status Request message to download the current status of each active order for a: (i) Specified trader group: MassStatusReqType(585) = All open orders for PartyID(8), PartyID(448) = trader group ID (ii) Specified trader group in a specified instrument: MassStatusReqType(585) = All Open Orders for a specific security(1), SecurityID(48) = instrument ID, PartyID(448) = trader group ID (iii) Specified trader group in a specified segment: MassStatusReqType(585) = All open orders for a specified segment(100), MarketSegmentID(1300) = segment ID, PartyID(448) = trader group ID. The total number of Order Mass Status Request that a client may submit each day is limited, see OSLOMIT 604 Technical Parameters for the actual limit. A client may request Oslo Børs to reset its request count. This feature is intended to help manage an emergency situation and should not be relied upon as a normal practice. If a request for a trader group is successful, the server will respond with an Execution Report for each active order for the specified trader group. If a request for a trader group in a specified instrument is successful, the server will respond with an Execution Report for each active order for the specified trader group in the specified instrument. If a request for a trader group in a specified segment is successful, the server will respond with an Execution Report for each active order for the specified trader group in the specified segment. Each such message will include the MassStatusReqID(584) of the request, an ExecID(17) of 0 and an ExecType(150) of Order Status(I). The last Execution Report sent by each partition in response to the request will include a LastRptRequested(912) of Last Message(Y). The server will transmit a single Execution Report if the request is rejected (due to required tags missing or specified values are invalid or insufficient privileges) or if there are no active orders for the specified trader group or for the specified trader group in the specified instrument/segment. Such a message will include the MassStatusReqID(584) of the request, an ExecID(17) of 0, an ExecType(150) of Order Status(I) and an OrdStatus(39) of Rejected(8). The message will not include fields that relate to orderspecific information (e.g. ClOrdID(11), OrderID(37), OrderQty(38), LeavesQty(151), Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 10

11 CumQty(14), OrdType(40) etc.) and TransactTime(60). The reason for the rejection will be specified in the field OrdRejReason(103). A Business Message Reject will be sent to reject an Order Mass Status Request if the server is unable to process it in the unlikely event of a system outage. If the outage occurs before the server has sent all of the messages in response to an Order Mass Status Request, it will terminate the open order download. An Execution Report will be sent if the open order download is terminated. It will include the MassStatusReqID(584) of the request, an ExecID(17) of 0, an ExecType(150) of Order Status(I) and an OrdStatus(39) of Rejected(8). If a client specifies an instrument (in SecurityID(48)) as well as a segment (in MarketSegmentID(1300)) in the Order Mass Status Request, results should be given according to the value specified for the MassStatusReqType(585) field. I.e.: If MassStatusReqType(585) = All Open Orders for a specific security(1), statuses of the orders belonging to the specified instrument should be given If MassStatusReqType(585) = All open orders for a specified segment(100), statuses of the orders belonging to the specified segment should be given If MassStatusReqType(585) = All open orders for PartyID(8), statuses of all orders belonging to the specified trader group should be given 2.6 Execution Reports The Execution Report message is used to communicate many different events to clients. The events are differentiated by the value in the ExecType(150) field as outlined below. ExecType Usage Ord Status 0 Order Accepted Indicates that a new order has been accepted. 8 Order Rejected Indicates that an order has been rejected. The reason for the rejection is specified in the field OrdRejReason(103). F Order Executed Indicates that an order has been partially or fully filled. The execution details (e.g. price and quantity) are specified , 2 Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 11

12 ExecType Usage Ord Status C Order Expired Indicates that an order has expired in terms of its time qualifier or due to an execution limit. This message will also be sent when orders are expired upon entering the order book when the number of orders in the order book is at the maximum allowed level. The reason for the expiration is specified in the Text(58) field. C This message will also be sent when a market order is expired at the point of aggressing the order book during the regular (continuous) trading session due to a circuit breaker is triggered during that aggression. The reason for the expiration is specified in the Text(58) field. This message will also be sent when the remaining orders (except GTC and GTD) are expired at market close. This messages will also be sent when orders are expired based on the auto cancellation on disconnect/log out feature. See OSLMIT 202 Fix Trading Gateway, section Order Cancelled Indicates that an order cancel request has been accepted and successfully processed. This message is also sent if the order is cancelled by market supervision. In such a case the Execution Report will include an ExecRestatementReason(378) of Market Option(8). It will not include an OrigClOrdID(41). 5 Order Cancel/Replaced Indicates that an order cancel/replace request has been accepted and successfully processed. L Triggered Indicates that a parked ATC, GFS or GFA order has been activated and is available for execution. 4 0, 1 0, 1 D Indicates that a pegged order submitted during an auction call has been activated. Restated Indicates that an order has been amended by market supervision. The message will include an ExecRestatementReason(378) of Market Option(8). It will not include an OrigClOrdID(41). 0, 1 Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 12

13 ExecType Usage Ord Status H I I Trade Cancel Indicates that an execution has been cancelled. An ExecRefID(19) to identify the execution being cancelled will be included. Order Status Response Indicates the current status of an order. Order Status Reject Indicates that an order mass status request has been rejected. 0, 1 0, 1, Order Status As specified in the FIX protocol, the OrdStatus(39) field of an Execution Report is used to convey the current state of an order. If an order simultaneously exists in more than one order state, the value with highest precedence is reported as the OrdStatus(39). The relevant order statuses are given below from the highest to lowest precedence. Value Meaning 2 Filled 4 Cancelled C Expired 1 Partially Filled 0 New 8 Rejected 2.7 Order and Execution Identifiers Client Order IDs In the case of orders, the ClOrdID(11) included in each Execution Report will be that specified when the order was submitted. An order s ClOrdID(11) will be updated each time an Order Cancel/Replace Request or an Order Cancel Request is accepted. Note that for orders managed through the Native Trading Gateway, it is optional to specify a client order ID in the Cancel Request, Order Mass cancel Request and Order Modification Request messages which means that the ClOrdID(11) will not be updated Order IDs Private: The server uses the OrderID(37) field to affix the order identification numbers of the matching system. Order IDs are unique across trading days. Unlike ClOrdID(11) which requires a chaining through Cancel/Replace Requests and Cancel Requests, the OrderID(37) of an order will remain constant throughout its life. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 13

14 This will be a 62 base encoded value in ASCII format. By converting this to binary, this can be mapped to the MITCH Order IDs, see OSLMIT 604 Technical Parameters for details. Public: MDEntryID(278) is a secondary order ID that will be maintained by the matching engine, which will be unique for each replenishment of a particular iceberg order. For example, for a single iceberg order, the Order ID will be the same, but a unique new Public Order ID will be generated for each replenishment. This secondary order ID is the one that will be published in the public market data, and is called the Public Order ID Execution IDs The server uses the ExecID(17) field to affix a unique identifier for each Execution Report. ExecIDs(17) are unique across trading days. This will be a 62 base encoded value in ASCII format Trade IDs The server uses the TrdMatchID(880) field to affix a unique identifier for each trade. This identifier is referenced in the Trade Capture Reports published by the post trade system and the trade messages of the FAST and MITCH market data feeds. TrdMatchIDs(880) are unique across trading days. An Execution Report published to notify a client of a trade cancellation includes the TrdMatchID(880) of the trade. This will be a 62 base encoded value in ASCII format. By converting this to binary, this can be mapped to the MITCH Trade IDs, see OSLMIT 604 Technical Parameters for details Instrument Identification Instruments will be identified by the Instrument ID assigned by Oslo Børs to each security, and will be specified by using the Instrument ID in the SecurityID(48) field and with SecurityIDSource(22) set to Exchange Symbol(8). The complete list of instruments traded, including the Instrument IDs, can be obtained from the reference data files, see OSLMIT 401 Reference Data, on MITCH through the Symbol Directory message, see OSLMIT 303 MITCH Gateway and on FIX/FAST through the Security Definition message, see OSLMIT 302 FIX/FAST Gateway. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 14

15 2.7.6 Party Identification ID Description Relevant FIX Tags Executing Firm Trader Group Trader ID Counterparty Firm Client Reference Identifier of the trading firm the interest is submitted under. Identifier of the trader group the message is submitted under. Trading privileges are assigned at the level of trader group. Identifier of the actual trader (within the trader group) the interest is submitted under. Oslo Børs require that order submitted include the trade flow type, but it is optional to specify the identifier of the trader, see OSLMIT 202 FIX Trading Gateway (5.0 SP2) Identifier of the counterparty firm in a trade Client reference (investor on whose behalf the interest is submitted) information applicable to an order PartyRole(452) = 1 PartyID(448) PartyRole(452) = 76 PartyID(448) PartyRole(452) = 12 PartyID(448) PartyRole(452) = 1 PartyID(448) Account(1) If a repeating group is used in a message, the NoXXX field (for example NoPartyIDs(453) field in the trading party repeating group) should be specified first before the repeating group starts. This is applicable for both the messages generated by the client and the server. The messages generated by the server will have the fields within a repeating group in order. The messages generated by a client should have the first field documented in a repeating group as the first field in the message sent to the server. If the first field documented in a repeating group is first in the message, the message generated by a client will be accepted; else the message will be rejected. So for e.g. the NoPartyIDs(453) repeating group, the field PartyID(448) must be the first field in each of the groups specified. 2.8 Price Fields Interpretation The values specified in the price fields will be interpreted as the price per share for equity, warrant and ETN instruments. For fixed income instruments, they will be interpreted as percentage of par. For repo-trades, price will be in repo-yield Fixed Income Instruments The Execution Report may include the implied yield of the order in the ConvertedYield(30005) and trade in the Yield(236) field for some fixed income instruments. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 15

16 2.9 Timestamps and Dates The timestamps SendingTime(52), OrigSendingTime(122) and TransactTime(60) are in UTC and in the YYYYMMDD-HH:MM:SS.sss format. ExpireTime(126) is in UTC and in the YYYYMMDD-HH:MM:SS format. All dates (i.e. MaturityDate(541) and ExpireDate(432)) are in the YYYYMMDD format Functional and Implementation Limitations (i) All the FIX gateways (FIX Trading, FIX Drop Copy and FIX Post Trade) currently use a common library. The system hence accepts all FIX messages defined for all three gateways, and cannot distinguish between them per gateway. It will validate the incoming messages in the following sequence: 1) The system initially does a FIX library level validation 2) The system does a validation for required fields 3) The system finally does the gateway level validation Hence; Scenario 1>> If a message is sent which does not comply with the specific gateway being used (but is defined in a different FIX gateway), it will validate the required fields. If any of the required tags are missing, it will give out a session reject with message "Required tag missing''). Scenario 2>> If a message is sent which does not comply with the specific gateway being used (but is defined in a different FIX gateway), it will validate the required fields. If all required fields are available, a gateway validation gives out a business reject message "Unsupported Message Type". Scenario 3>> If a message is sent which does not comply with any of the FIX gateways used it will then give out a session reject message "Invalid Msg Type. (ii) When an Order Mass Status Request is rejected at its entirety, an Execution Report is generated but it does not carry a client order id as the rejection is not related to a specific order. Hence there is an exception to the fact that ClOrdID(11) is required in the Execution Report. (iii) If an undefined tag is sent along with any of the Administrative messages, then the system will ignore the undefined tags and process the rest of the message Variations from the FIX Protocol The server conforms to the FIX protocol except as follows: (i) In the Order Mass Status Request the field NoPartyIds(453) and the corresponding repeating group are mandatory. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 16

17 3. Connectivity 3.1 CompIDs The CompID of each client must be registered with Oslo Børs before FIX communications can begin. A single client may have multiple connections to the server (i.e. multiple FIX sessions, each with its own CompID). The CompID of the server is documented in the OSLMIT 604 Technical Parameters document. The messages sent to the server should contain the CompID assigned to the client in the field SenderCompID(49) and the CompID of the server in the field TargetCompID(56). The messages sent from the server to the client will contain the CompID of the server in the field SenderCompID(49) and the CompID assigned to the client in the field TargetCompID(56) 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. If the new password is accepted, you will receive a Logon message with SessionStatus(1409) set to Session Active(0). If the new password is not accepted, the session will be closed without any messages. New passwords must adhere to the rules below: Minimum lenght - 8 characters Maximum length - 14 characters Minimum numeric characters - 1 character Minimum alpha characters - 1 character Minimum special characters - 1 character Oslo Børs recommend that the passwords are changed at regular intervals. 3.2 Partition Identification (AppID) The central parts of Millennium Exchange can be partitioned in multiple instances. The number of partitions and the partition IDs will be documented in the OSLMIT 604 Technical Parameters document, and will be transmitted to the client in the field AppID(1180) where appropriate, e.g. in the Execution Report message. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 17

18 4. FIX Connections and Sessions 4.1 Establishing a FIX Connection FIX connections and sessions between the client and server are maintained as specified in the FIXT protocol. Each client will use the assigned IP address and port to establish a TCP/IP session with the server. The client will initiate a FIX session at the start of each trading day by sending the Logon message. The client will identify itself using the SenderCompID(49) 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). If the client s Logon message included the field NewPassword(925) and the client is authenticated, the SessionStatus(1409) of the Logon sent by the server will indicate whether the new password is accepted or rejected. The server will break the TCP/IP connection if messages are received before the exchange of Logon messages. Once a response to the Logon message has been received, a client can start sending additional messages to the server. System will start sending the client any new or missed Application Messages immediately after the Logon reply is sent. If a logon attempt fails because of an invalid SenderCompID(49), TargetCompID(56), Password(554) or IP address, the server will break the TCP/IP connection with the client without sending a Logout or Reject. If a logon attempt fails because of an expired password, a locked/suspended/inactivated CompID or if logins are not currently permitted, the server will send a Logout message and then break the TCP/IP connection with the client. In these scenarios the next inbound sequence number expected from the client will be incremented but the outbound sequence number will not be incremented. In this scenario the message sequence number 1 will be sent with the Logout message. If a logon attempt fails because of a session level failure (e.g. due to invalid EncryptMethod(98) or DefaultApplVerID(1137) etc) the inbound sequence number and the outbound sequence number both will not be incremented. In this scenario the message sequence number 1 will be sent with the Logout message. However if a session level failure occurs due to a message sent by a client which contains a sequence number that is less than what is expected and the PossDupFlag(43) is not set to Yes(Y), then the server will send a Logout message and terminate the FIX connection. In this scenario the inbound sequence number will not be incremented but the outbound sequence number will be incremented. The Logout message will have a MsgSeqNum(34) of the previous outbound sequence number of the server + 1, but will not contain a reference to the next expected inbound sequence number. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 18

19 (Please refer section for a summary of the inbound and outbound sequence number behaviour in different scenarios where a client s logon attempt fails). When the FIX session is not in sync the Business Reject Code(380) and the Text(58) of the Business Reject message should be sent as follows. Business Reject Reason(380)=30 Text(58)=Session not established Simultaneous Logons from Different TCP/IP Connections If during a logon of a SenderCompID(49), the server receives a second connection attempt via a different TCP/IP connection while a valid FIX session is already underway for that same SenderCompID(49), the server will break the TCP/IP connection with the second connection without sending a Logout or Reject message. As the logon attempt failed, the server will not increment the next inbound message sequence number expected from the client Simultaneous Logons from the Same TCP/IP Connection If during a logon of a SenderCompID(49), the server receives a second connection attempt via the same TCP/IP connection while a valid FIX session is already underway for that same SenderCompID(49), the server will immediately break the TCP/IP connection with the client without sending any messages. The server will increment the next inbound message sequence number expected from the client as well as its own outbound message sequence number. If the server receives another connection attempt from the same SenderCompId(49) while a session is already established, the connection attempt will be rejected via a Reject message without breaking the existing TCP/IP connection with the client. 4.2 Maintaining a FIX Session Message Sequence Numbers As outlined in the FIXT protocol, the client and server will each maintain a separate and independent set of incoming and outgoing message sequence numbers. Sequence numbers should be initialized to 1 (one) at the start of the FIX session and be incremented throughout the session. Monitoring sequence numbers will enable parties to identify and react to missed messages and to gracefully synchronize applications when reconnecting during a FIX session. If any message sent by the client contains a sequence number that is less than what is expected and the PossDupFlag(43) is not set to Yes(Y), the server will send a Logout message and terminate the FIX connection. The Logout will contain the next expected sequence number in the Text(58) field. A FIX session will not continue to the next trading day. The server will initialize its sequence numbers at the start of each day. The client is expected to employ the same logic. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 19

20 4.2.2 Sequence numbers during logon attempt failures a. If a logon attempt fails because of an invalid or expired password, a locked/suspended/inactivated CompID or if logins are not currently permitted, the server will send a Logout message and then break the TCP/IP connection with the client. In this scenario the inbound sequence number will be incremented but the outbound sequence number will not be incremented but will be defaulted to 1 (one). b. If a logon attempt fails due to a session level failure (e.g. due to invalid EncryptMethod(98) or DefaultApplVerID(1137) etc.), a Logout message will be sent which will contain the SessionStatus(1409) of Logout due to session level failure(101). In this scenario both the inbound sequence number and the outbound sequence number will not be incremented. In this scenario the sequence number of the Logout message will be defaulted to 1 (one). c. If the login sequence number is less than the expected sequence number a Logout message will be sent which will contain the Session Status(1409) of Logout due to session level failure(101). In this scenario the inbound sequence number will not be incremented but the outbound sequence number will be incremented. Scenario Session status (of Logout) Inbound Sequence Number Outbound Sequence Number a 8 (Password expired) Increment by one does not increase (defaulted to 1) a 6 (Account locked) Increment by one does not increase (defaulted to 1) a b c 7 (logins are not allowed) 101 (logout session level failure) 101 (logout session level failure) Increment by one does not increase does not increase (defaulted to 1) does not increase (defaulted to 1) does not increase Increment by Heartbeats The client and server will use the Heartbeat message to exercise the communication line during periods of inactivity and to verify that the interfaces at each end are available. The heartbeat interval will be the HeartBtInt(108) specified in the client s Logon message. The server will send a Heartbeat anytime it has not transmitted a message for the heartbeat interval. The client is expected to employ the same logic. If the server detects inactivity for a period longer than the heartbeat interval plus a reasonable transmission time, it will send a Test Request message to force a Heartbeat from the client. If a response to the Test Request is not received by a reasonable transmission time, the server will send a Logout and break the TCP/IP connection. The client is expected to employ similar logic if inactivity is detected on the part of the server. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 20

21 4.2.4 Increasing Expected Sequence Number The client or server may use the Sequence Reset message in Gap Fill mode if it wishes to increase the expected incoming sequence number of the other party. The client or server may also use the Sequence Reset message in Sequence Reset mode if it wishes to increase the expected incoming sequence number of the other party. The MsgSeqNum(34) in the header of such a message will be ignored. The Sequence Reset mode should only be used to recover from an emergency situation. It should not be relied upon as a regular practice. 4.3 Terminating a FIX Connection The client is expected to terminate each FIX connection at the end of each trading day before the server shuts down. The client will terminate a connection by sending the Logout message. The server will respond with a Logout to confirm the termination. The client will then break the TCP/IP connection with the server. As recommended in the FIXT protocol, clients are advised to transmit a Test Request, to force a Heartbeat from the server, before initiating the logout process. All open TCP/IP connections will be terminated by the server when it shuts down (a Logout will not be sent). Under exceptional circumstances the server may initiate the termination of a connection during the trading day by sending the Logout message. 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 of messages, see OSLMIT 604 Technical Parameters for the actual number. If, during the exchange of Logout messages, the client or server detects a sequence gap, it should send a Resend Request. 4.4 Re-Establishing a FIX Session If a FIX connection is terminated during the trading day it may be re-established via an exchange of Logon messages. Once the FIX session is re-established, the message sequence numbers will continue from the last message successfully transmitted prior to the termination Resetting Sequence Numbers: Starting a New FIX Session Reset Initiated by the Client If the client requires both parties to initialize (i.e. reset to 1 ) sequence numbers, it may use the ResetSeqNumFlag(141) field of the Logon message. The server will respond with a Logon with the ResetSeqNumFlag(141) field set to Yes(Y) to confirm the initialization of sequence numbers. A client may also manually inform Oslo Børs that it would like the server to initialize its sequence numbers prior to the client s next login attempt. These features are intended to help a client manage an emergency situation. Initializing sequence numbers on a re-login should not be relied upon as a regular practice Reset Initiated by the Server Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 21

22 The system has been designed with fault tolerance and disaster recovery technology that should ensure that the server retains its incoming and outgoing message sequence numbers for each client in the unlikely event of an outage. However, clients are required to support a manual request by Oslo Børs to initialize sequence numbers prior to the next login attempt. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 22

23 5. Failover and Recovery 5.1 Failover Oslo Børs will have a resilient solution at primary site. For all TCP/IP connections clients will be given two pairs of IP addresses, a pair (primary and backup) for the production site and a pair (primary and backup) for the secondary / disaster recovery site, for details see the OSLMIT 605 Live Environment Connectivity and OSLMIT 606 CDS Environment Connectivity documents. Clients should use the production site pair until directed that a site failover has been invoked following this the secondary site pair should be used, see OSLMIT 601 Guide to Trading Services Disaster Recovery for details. On unexpected disconnection from the production site primary gateway a client should try to reconnect to the primary gateway again before trying to connect to the secondary gateway. If no connection can be made to neither to the primary nor the secondary gateway over a period of time, the client should contact Oslo Børs for guidance Application failover on Primary Data Center On re-connection after an application failover (not site failover), the FIX gateways will increment outbound (to the participant) message sequence numbers by a configurable amount to ensure that any messages in-flight at the time of failure can be recovered. You can find this configurable amount in OSLMIT 604 Technical Parameters. Please refer to OSLMIT 601 Guide to Trading Services Disaster Recovery for more information Site failover Participants should re-connect to their designated primary gateways using the same IP addressing as for the primary site. All FIX message sequence numbers will be reset to 1 on the FIX Gateways. Customers must also reset their outgoing sequence numbers to 1 before reconnecting. Oslo Børs cannot guarantee that any re-sent messages from before the disaster will not be processed if customer outgoing sequence numbers are not re-set. Please refer to OSLMIT 601 Guide to Trading Services Disaster Recovery for more information. 5.2 Resend Requests The client may use the Resend Request message to recover lost messages. As outlined in the FIXT protocol, this message may be used in one of three modes: (i) To request a single message. The BeginSeqNo(7) and EndSeqNo(16) should be the same. (ii) To request a specific range of messages. The BeginSeqNo(7) should be the first message of the range and the EndSeqNo(16) should be the last of the range. (iii) To request all messages after a particular message. The BeginSeqNo(7) should be the sequence number immediately after that of the last processed message and the EndSeqNo(16) should be zero (0). Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 23

24 The server caches a limited number of the last messages transmitted to each CompID, see OSLMIT 604 Technical Parameters for the actual limit. Clients are unable to use a Resend Request to recover messages not in the server s cache. If the client requests for a range of messages that have sequence numbers falling outside the cache size, a Sequence Reset message in Gap Fill mode will be sent for the missing messages and will send the available messages as per the request after that. If a client cannot recover all messages it requires due to the limit per Missed Message Request, it is advised to use the Order Mass Status Request to get the current status of all open orders and connect to the FIX Post Trade Gateway to get the details of all relevant trades. 5.3 Possible Duplicates The server handles possible duplicates according to the FIX protocol. The client and server will use the PossDupFlag(43) field to indicate that a message may have been previously transmitted with the same MsgSeqNum(34). 5.4 Possible Resends Client-Initiated Messages The server does not handle possible resends for client-initiated messages and ignores the value in the PossResend(97) field of such messages Server-Initiated Messages The server may, in the circumstances outlined in sections 5.5, use the PossResend(97) field to indicate that an application message may have already been sent under a different MsgSeqNum(34). The client should validate the contents (e.g. ExecID(17)) of such a message against those of messages already received during the current trading day to determine whether the new message should be ignored or processed. If an Execution Report with same ExecID(17) had been processed, the resent message should be ignored. If the same ExecID(17) had not been processed, the Execution Report should be processed. 5.5 Transmission of Missed Messages The Execution Report messages generated during a period when a client is disconnected from the server will be sent to the client when it next reconnects. In the unlikely event the disconnection was due to an outage of the server, all such messages will include a PossResend(97) of Yes(Y). Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 24

25 6. Message Formats This section provides details on the header and trailer, the administrative and application messages utilized by the server. Client-initiated messages not included in this section are rejected by the server via a Reject or Business Message Reject. 6.1 Supported Message Types Administrative Messages All administrative messages may be initiated by either the client or the server. Message MsgType Usage Logon A Allows the client and server to establish a FIX session. Logout 5 Allows the client and server to terminate a FIX session. Heartbeat 0 Allows the client and server to exercise the communication line during periods of inactivity and verify that the interfaces at each end are available. Test Request 1 Allows the client or server to request a response from the other party if inactivity is detected. Resend Request 2 Allows for the recovery of messages lost during a malfunction of the communications layers. Reject 3 Used to reject a message that does not comply with FIXT. Sequence Reset 4 Allows the client or server to increase the expected incoming sequence number of the other party. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 25

26 6.2 Application Messages Client-Initiated Message MsgType Usage Order Mass Status Request AF Allows the client to request the status of all active orders for a particular trader group or a segment or an instrument Server-Initiated Message MsgType Usage Execution Report 8 Indicates one of the following: (i) Order accepted (ii) Order rejected (iii) Order executed (iv) Order expired (v) Order cancelled (vi) Order cancel/replaced (vii) Trade cancelled (viii) Order status (ix) Order mass status request rejected (x) Order suspended (xi) Order triggered (xii) Order restated Application Messages: Other Server-Initiated Message MsgType Usage Business Message Reject j Indicates that an application message could not be processed. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 26

27 6.3 Message Header and Trailer Message Header Tag Field Name Req Description 8 BeginString Y FIXT BodyLength Y Number of characters after this field up to and including the delimiter immediately preceding the CheckSum. 35 MsgType Y Message type. 49 SenderCompID Y CompID of the party sending the message. 56 TargetCompID Y CompID of the party the message is sent to. 34 MsgSeqNum Y Sequence number of the message. 43 PossDupFlag N Whether the message was previously transmitted under the same MsgSeqNum(34). Absence of this field is interpreted as Original Transmission(N). Value Meaning Y N Possible Duplicate Original Transmission 97 PossResend N Whether the message was previously transmitted under a different MsgSeqNum(34). Absence of this field is interpreted as Original Transmission(N). Value Meaning Y N Possible Resend Original Transmission 52 SendingTime N Time the message was transmitted. Not required for incoming messages sent by the clients (even if sent by a client, no validation will be done). Required for outgoing messages sent by the server. Format: YYYYMMDD-HH:MM:SS.sss 122 OrigSending Time N Time the message was originally transmitted. If the original time is not available, this should be the same value as SendingTime(52). Required if PossDupFlag(43) is Possible Duplicate(Y). Format: YYYYMMDD-HH:MM:SS.sss 1128 ApplVerID N Version of FIX used in the message. Required if the message is generated by the server. 115 OnBehalfOf CompID N Value Meaning 9 FIX50SP2 Required for server-initiated application messages. This will be the CompID of the connection that originated the order referenced in the message being drop copied. Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 27

28 Tag Field Name Req Description 128 DeliverToComp ID N The value specified in the OnBehalfOfCompID(115) field will be stamped; will only be used in server initiated messages Message Trailer Tag Field Name Req Description 10 CheckSum Y Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 28

29 6.4 Administrative Messages Logon Tag Field Name Req Description Standard Header 35 MsgType Y A = Logon Message Body 98 EncryptMethod Y Method of encryption. Value Meaning 0 None 108 HeartBtInt Y Indicates the heartbeat interval in seconds. 141 ResetSeqNum Flag N Indicates whether the client and server should reset sequence numbers. Absence of this field is interpreted as Do Not Reset Sequence Numbers(N). Value Y N Meaning Reset Sequence Numbers Do Not Reset Sequence Numbers 554 Password N Password assigned to the CompID. Required if the message is generated by the client. Maximum password length is 20 characters. 925 NewPassword N New password for the CompID. Maximum password length is 20 characters SessionStatus N Status of the FIX session. Required if the message is generated by the server. Value Meaning 0 Session Active 2 Password Due to Expire 1137 DefaultAppl VerID Standard Trailer Y Default version of FIX messages used in this session. Value Meaning 9 FIX50SP2 Oslo Børs OSLMIT 205 Drop Copy Gateway (FIX 5.0 SP2) 29