Post Trade Gateway (FIX 5.0)

Transcription

1 M I T B I T M I L L E I U M E X C H A G E Post Trade Gateway (FIX 5.0) Issue 4.2 June 2012

2 Contents Post Trade Gateway (FIX 5.0) Introduction Purpose Readership Document series Document history Enquiries Service description Connection configuration Real-time connections Query-based service Trade Information Party Identifiers Trade, Execution and Order Identifiers Trade cancels Timestamps and dates Encryption Off book trade reporting FIX Tag s Trade Identifiers Firm Trade ID Trade ID Connectivity CompIDs Passwords Production IP addresses and ports Failover and recovery FIX connections and sessions Establishing a FIX connection Maintaining a FIX session Message Sequence umbers Heartbeats Increasing Expected Sequence umber Terminating a FIX connection Re-establishing a FIX session Resetting Sequence umbers: Starting a new FIX session Recovery Resend Requests Possible duplicates Possible resends Transmission of missed messages Application sequencing and recovery

3 6 Supported message types Administrative Messages Application Messages Trade Feed Trade Feed Client-Initiated Trade Feed Server-Initiated Application Messages Off-Book Trades Off-Book Trades Client-Initiated Off-Book Trades Server-Initiated Application Messages: Other (Server-Initiated) Variations from the FIX Protocol Message formats Message header and trailer Message Header Message Trailer Administrative messages Logon Logout Heartbeat Test Request Resend Request Reject Sequence Reset Application messages: Trade Feed Trade Capture Report Request (Client Initiated) Application Message Request (Client Initiated) Trade Capture Report (Server Initiated) Trade Capture Report Request Ack (Server Initiated) Application Message Request Ack (Server Initiated) Application Messages: Off-Book Trades Trade Capture Report (Client Initiated) Trade Capture Report Ack (Server Initiated) Application Messages: Other Business Message Reject Reject codes Trade Capture Report Ack Business Message Reject

4 Disclaimer The London Stock Exchange Group has taken reasonable efforts to ensure that the information contained in this publication is correct at the time of going to press, but shall not be liable for decisions made in reliance on it. The London Stock Exchange Group will endeavour 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. 4

5 1 Introduction Borsa Italiana has provided a post trade gateway that will enable member firms to receive real-time information on executed trades, to submit an off-book trade. This interface can not be used to submit orders or quotes 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. 1.1 Purpose The purpose of this document is to provide a technical description of the post trade gateway available on the Millennium Exchange platform. 1.2 Readership This document outlines how to connect to the post trade gateway and the detailed message types and fields used. When read in conjunction with the other Millennium Exchange guides, it is intended that these documents provide all of the details directly connected Borsa Italiana customers require to develop to the new services. 1.3 Document series This document is part of a series of documents providing a holistic view of full trading and information services available from the Borsa Italiana post the migration to Millennium Exchange. The current series of documents are set out below: Trading MIT201 BIT Guide to ew Trading System MIT202 BIT FIX Trading Gateway (FIX 5.0) MIT203 BIT ative Trading Gateway Specification MIT204 BIT Post Trade Gateway (FIX 5.0) Specification (this document) MIT205 BIT Drop Copy Gateway (FIX 5.0) Specification Market Data MIT301 BIT - Guide to Market Data Services MIT303 BIT Level 2-ITCH Specification MIT305 BIT Markets Reference Data and FTSE indices constituents MIT306 BIT MOT / EuroMOT Instrument Currency This series principally covers non-regulatory information and does not override or supersede the Rules of Borsa Italiana. The latest version of this document series can be found at the following links: 5

6 Italian Version: English Version: Document history This document has been through the following iterations: Issue Date Description 1.0 August 2011 First issue of this document published via the Borsa Italiana s website and distributed to customers. 2.0 September 2011 Updated version of this document published via the Borsa Italiana s website and distributed to customers. The changes are applied in the following sections: - Section Section Section Section 7.4 Removed the following sections: - Section December 2011 Updated version of this document published via the Borsa Italiana s website and distributed to customers. The changes are applied in the following sections: - Removed the following sections Section 2.5, 2.6 (removed as Order ID and Trade ID conversions are covered via ITCH Specification) - amended sections , 7.2.1, 7.3.3, 7.4.2, February 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. The changes are applied in the following sections: 3.1, 7.3.3, March 2012 Updated version of this document published via the Borsa Italiana s website and distributed to 6

7 customers. The changes are applied in the following sections: , 7.3.3, 7.4.1, March 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. The changes are applied in the following sections: April 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. The changes are applied in the following sections: May 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. The changes are applied in the following sections: 1.3, , June 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. The changes are applied in the following sections: 2.6 In subsequent issues, where amendments have been made to the previous version, these changes will be identified using a series of side bars as illustrated opposite. 1.5 Enquiries Please contact either Client Technology Services or your Technical Account Manager if you have any functional questions about the Millennium Exchange services outlined in this document. Client Technology Services (ITA) can be contacted at: Telephone: Service Desk Free Toll umber: MIT-migration@borsaitaliana.it ; clients-services@borsaitaliana.it 7

8 2 Service description Clients will receive real-time information on the trades executed on the Exchange along with notifications of any trade cancel. The details of trades executed on previous trading days are not available via this service. 2.1 Connection configuration A member firm connection will be configured by the Exchange to receive all of its trades. If required, a member firm could be configured to only receive trades for selected users and securities. For the purpose of redundancy, the service supports the configuration of multiple post trade connections to send the same information on the activity of the selected firms/trader groups Real-time connections A real-time client will receive the details of each eligible trade immediately after it is executed. Please refer to Section 5 for a description of how the trades executed during the time a real-time client is disconnected from the server may be recovered Query-based service A query-based client will not receive any real-time notifications of its eligible trades. Such clients are expected to request the server for the details of trades as and when they are needed as outlined below Trade Capture Report Requests A client may use the Trade Capture Report Request message to request the details of all eligible trades or those that meet certain criteria. The server will respond with a Trade Capture Report Request Ack to indicate, via the TradeRequestStatus (750) and Trade RequestResult (749) fields, whether the request is successful or not. Sometimes if the Trade Capture Report Request message is rejected due to some garbage value validations, a Reject message can also be generated as the response. If a request is accepted, the number of Trade Capture Reports that will be sent in response to the request will be indicated in the TotumTradeReports (748) field of the Trade Capture Report Request Ack. The server will transmit the requested Trade Capture Reports immediately after the Trade Capture Report Request Ack. Each Trade Capture Report will include the TradeRequestID (568) of the request it is sent in response to. The last Trade Capture Report of each partition will include a LastRptRequested (912) of Last Message (Y). If a request is rejected, the reason will be specified in the field TradeRequestResult (749) of the Trade Capture Report Request Ack. The Trade Capture Report Request message can only be used to request a snapshot of the current eligible trades. It can not be used to subscribe to Trade Capture Reports. Request for all Trades The Trade Capture Report Request should include a TradeRequestType (569) of All Trades (0) if the client wishes to request the details of all eligible trades. Request for selected Trades 8

9 The Trade Capture Report Request should include a TradeRequestType (569) of Trades Matching Specified Criteria (1) if the client wishes to request the details of eligible trades for a selected set of instruments or for a specified party, trade type or order. The SecurityID (48) field of the Trade Capture Report Request may be used if the request relates to a single instrument. The ExecType (150) field of the message may be used if the request is limited to cancelled trades or trades that have not been cancelled. If a particular Trade Capture Report Request contains multiple criteria (e.g. SecurityID and Account), the server will treat it as a request for trades that match all of the specified criteria. If no trades match the specified criteria, the server will reject the request with a TradeRequest Result (749) of Cannot Match Selection Criteria (100). 2.2 Trade Information The FIX Trade Capture Report message is utilised by the service to transmit the details of each trade. A separate Trade Capture Report will be sent for each side of a trade. In the case of a trade, TradeHandlingInstr (1123) will be Trade Confirmation (0), ExecType (150) will be Trade (F), MatchStatus (573) will be Matched (0), TradeReportTransType (487) will be ew (0) and TradeReportType (856) will be Submit (0) (In certain cases of off book trade reports, TradeReportTransType(487) may be set to Replace(2)). For example, if an off book trade is submitted which is published immediately, the submitting party first receives a Trade Capture Report Request Ack followed by a Trade Capture Report (where TradeReportTransType(487) set to Replace (2)). o further Trade Capture Report is sent with a TradeReportTransType(487) set to Released(3). A Trade Capture Report with a TradeReportTransType (487) of Released (3) indicates that a previously reported off book trade has been pre-released on the market data feed or if a delayed off book trade is published with the following the initial delay. For example, If an off book trade is submitted which is published with a delay, the submitting party first receives a Trade Capture Report Request Ack followed by a Trade Capture Report (where TradeReportTransType(487) set to Replace(2)). Then when the trade is actually published, it receives another Trade Capture Report with TradeReportTransType(487) set to Released (3). Each message will contain both basic and value added information on the trade (e.g. price quantity, consideration, settlement date, accrued interest, etc.), the security (e.g. ISI) and the parties (e.g. trading firm). It will also contain information related to the computation of execution fees (e.g. maker or taker, trade type, etc.) Party Identifiers ID Description PartyRole (452) Executing Firm Clearing Organization The trading firm the executed order was submitted under. The firm through which the trade will clear

10 Trader Group Trader ID Counterparty Firm 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. Identifier of the counterparty firm in a trade PartyRole (452) = 76 PartyID (448) PartyRole (452) = 12 PartyID (448) PartyRole (452) = Trade, Execution and Order Identifiers Trade Report ID The TradeReportID (571) of each Trade Capture Report is unique across trading days. The Trade Capture Reports published to report the two sides of a trade will contain different TradeReportIDs. A Trade Capture Report published to notify a client of a trade cancel includes the TradeReportID of the message that was published to report the trade in the TradeReportRefID (572) field Trade ID The Trade Capture Reports published to report the two sides of a particular trade will contain the same TradeID (1003). Trade IDs are unique across trading days. A Trade Capture Report published to notify a client of a trade cancel includes the TradeID (1003) of the relevant trade Execution ID A Trade Capture Report will contain the Execution ID of the Execution Report message sent by the Trading Gateway to report the execution of an order to the firm that submitted it. This Execution ID will be specified in the SideExecID (1427) field of the Trade Capture Report. The Execution Reports published to report the two sides of an execution will contain different Execution IDs which are unique across trading days Trade Link ID A Trade Capture Report will contain the Trade Link ID which will be the same for all orders within aggression of an order. All the Trade Capture Reports which were generated from an auction will have the same Trade Link ID Order IDs The matching system s order identification number for the executed order will be included in the OrderID (37) field of the Trade Capture Report. Order IDs are unique across trading days. In terms of the FIX protocol, 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. 10

11 Client Order IDs In the case of orders, the ClOrdID (11) included in the Trade Capture 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. In the case of quotes, the ClOrdID (11) included in the Trade Capture Report will be the QuoteID (117) or QuoteEntryID (299) of the executed quote Trade Type An indication of whether the trade was executed on or off the order book will be specified in the TrdType (828) field of a Trade Capture Report Further Information Each Trade Capture Report will specify the methodology under which a trade was executed (e.g. continuous trading, auction, etc.), the type of interest (e.g. order, quote, etc.) and whether an order was a maker or taker of liquidity via the MatchType (574), OrderCategory (1115) and SideLiquidityInd (1444) fields respectively. In the case of trades executed during an auction, both sides of the trade will be flagged as passive Quotation Conventions The values specified in the field LastPx (31) should, depending on the quotation convention for the instrument, be interpreted as price per share (equity instruments), percentage of par, or yield (fixed income instruments). The quotation convention for an instrument will be specified the PriceType (423) field. The value, if any, specified in the field LastParPx (669) should always be interpreted as percentage of par Fixed Income Instruments In the case of fixed income instruments quoted in yield, the Trade Capture Report will include the traded price expressed as a percentage of par in the field LastParPx (669). In the case of instruments quoted in percentage of par, the notification will include the implied yield of the trade in the field Yield (236). 2.3 Trade cancels Market Supervision may cancel a trade. The server will transmit Trade Capture Reports to the relevant clients to notify them of a trade cancellation. The cancelled trade will be identified in the TradeID (1003), TradeReportRefID (572) and, in the case of an off-book trade, FirmTradeID (1041) fields. The TradeHandlingInstr (1123) of the message will be Trade Confirmation (0), In the case of a trade cancellation, ExecType (150) will be Trade Cancel (H) and MatchStatus (573) will be Unmatched (1). The TradeReportType (856) will be Trade Break (7) if the trade is cancelled by Borsa Italiana. The TradeReportTransType (487) will be Cancel (1) or, in the case of certain off-book trades, Replace (2). 11

12 2.4 Timestamps and dates The timestamps SendingTime (52), OrigSendingTime (122) and TransactTime (60) should be in UTC and in the YYYYMMDD-HH:MM:SS.sss format. All dates (i.e. SettlDate (64), MaturityDate (541) and IssueDate (225)) will be in the YYYYMMDD format and specified in the local date for the server (i.e. not in UTC)). 2.5 Encryption The encryption of messages between the client and server is not supported. 2.6 Off book trade reporting Participants may submit privately negotiated trades for registration. Each such trade is subject to a series of validations (e.g. valid trade type, valid counterparty, etc.) and, if accepted, will be disseminated to the market. A confirmed off-book trade may be disseminated on the market data feed immediately, after a delay or remain unpublished. In the case of a delayed trade, the delay that will apply will be the earlier of the default duration for the instrument or the PublicationDelay, if any, specified when the trade was submitted for registration. A participant may request that a delayed trade report be pre-released (i.e. published immediately on the market data feed). The server supports the following methodology for the reporting of privately negotiated trades: (i) Single-sided trade report The trade is reported by only one of the counterparties. A Trade Capture Report Ack will be used by the server to acknowledge the receipt of or reject a trade report. The server will transmit a Trade Capture Report if the trade is confirmed. Clients can cancel a confirmed trade. Because of the format of the message the reporting counterparty should include both sides of the trade in a single Trade Capture Report. It's important to notice that if a Trader Group (76) is not specified for the side that contains the Executing Firm, the Comp ID will be taken as the Trader Group; if a Trader Group (76) is not specified for the side that contains the Counterparty Firm, then the Default user of the Counterparty firm is taken as the Trader Group FIX Tag s Event Off Book Trade Confirmation If recipient is the reporting party TradeReportType(856) = 0 - Submit TradeReportTransType(487) = 2 - Replace TCR sent from the server If recipient is the counterparty TradeReportType(856) = 0 - Submit TradeReportTransType(487) = 0 - ew Off Book Trade TradeReportType(856) = 6 - Trade TradeReportType(856) = 6 Trade 12

13 Cancellation Off Book Trade Prerelease or publish Reprot Cancel TradeReportTransType(487) = 2 - Replace TradeReportType(856) = 0 - Submit TradeReportTransType(487) = 3 - Release Reprot Cancel TradeReportTransType(487) = 1 - Cancel TradeReportType(856) = 0 - Submit TradeReportTransType(487) = 3 - Release 2.7 Trade Identifiers Firm Trade ID The server does not validate the FirmTradeID (1041) of each trade for uniqueness. However, it is necessary that counterparties assign a unique FirmTradeID to each off book trade. The FirmTradeID (1041) field will be used only to identify the off book trade up until the trade is confirmed by the system, once confirmed, the TradeID (1003) assigned to the trade by the system should be used for cancellation and pre-release requests. Customers should note that Firm Trade ID (1041) is limited to 11 characters. Any Trade Capture Report submitted with a length greater than this will be rejected via a Reject message (35=3) with a Session Reject Reason (373) = 5 and Text (58) = " out of range for this tag." Trade ID The Trade ID (1003) of each trade confirmed by the service is unique across trading days. 13

14 3 Connectivity 3.1 CompIDs The CompID of each client must be registered with the Exchange 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 PTGW. The messages sent to the server should contain the CompID assigned to the client in the field SenderCompID (49) and CompID of the server in the field TargetCompID (56). The messages sent from the server to the client will contain 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 are strongly encouraged to change the password to one of their choosing via the Logon message. 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. The new password will, if accepted, be effective for subsequent logins. 3.2 Production IP addresses and ports The IP addresses and ports for the post trade gateway will be published in a separate configuration document. 3.3 Failover and recovery The server has been designed with fault tolerance and disaster recovery technology that ensures that trading may continue in the unlikely event of a process or site outage. If the client is unexpectedly disconnected from the server, it should attempt to re-connect to primary site within a few seconds. The client should only attempt to connect to the secondary IP address and port if so requested by Borsa Italiana. 14

15 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 FIX 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). The server will break the TCP/IP connection if messages are received before the exchange of Logons. 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, TargetCompID, password or IP address, the server will break the TCP/IP connection with the client without sending a Logout or Reject. As the logon attempt failed, the server will not increment the next inbound message sequence number expected from the client. 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 message and then break the TCP/IP connection with the client. The server will increment the next inbound message sequence number expected from the client as well as its own outbound message sequence number. 4.2 Maintaining a FIX session Message Sequence umbers As outlined in the FIX protocol, the client and server will each maintain a separate and independent set of incoming and outgoing message sequence numbers. Sequence numbers should be initialised 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 Y, the server will send a Logout message and terminate the FIX connection. The Logout message will contain the next expected sequence number. A FIX session may not continue to the next trading day. The server will initialise its sequence numbers at the start of each trading day. The client is expected to employ the same logic. 15

16 4.2.2 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 message 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 HeartBtInt (108) specified in the client s Logon message, it will send a Test Request message to force a Heartbeat message from the client. The server will send a Logout message and break the TCP/IP connection with the client. The client is expected to employ similar logic if inactivity is detected on the part of the server Increasing Expected Sequence umber 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 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 message to confirm the termination. The client will then break the TCP/IP connection with the server. All open TCP/IP connections will be terminated by the server when it shuts down (a Logout message will be sent). Under exceptional circumstances the server may initiate the termination of a connection during the trading day by sending the Logout message. 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 FIX Gateway would also send a Test Request to confirm if the sequence numbers are in sync. Ideally the message sequence numbers should continue from the last message successfully transmitted prior to the termination. If the client responds to the Test Request with a Heartbeat message containing the appropriate Test Request ID and message sequence number, the server can start transmitting the missed messages or new messages in the Gateway. If the client does not respond to the Test Request during the heartbeat interval, the gateway will disconnect the client. If the client ignores the Test Request because the sequence number in the message is higher than the expected sequence number, the Client is expected to send a Resend Request asking for the missed messages. After responding to the Resend Request the FIX 16

17 Gateway would send another Test Request to make sure both the client and server is in sync before sending out any missed or new application messages. If the client sends a Resend Request before the FIX Gateway send a Test Request, then the FIX Gateway will serve the Resend Request first. After responding to the Resend Request the FIX Gateway would send a Test Request to make sure both the client and server are in sync before sending out any missed or new application messages. When the client sends a logon with a sequence number higher than expected by the FIX Gateway, the FIX gateway will send a Resend Request and once the response/s to the Resend Request is processed by the FIX Gateway, the FIX Gateway would send a Test Request to make sure both the client and server is in sync before sending out any missed or new application messages Resetting Sequence umbers: Starting a new FIX session Reset initiated by the client If the client requires both parties to initialise (i.e. reset to 1) sequence numbers, it may use the ResetSequmFlag (141) field of the Logon message. The server will respond with a Logon message with the ResetSequmFlag (141) field set to Y to confirm the initialisation of sequence numbers. A client may also manually inform Borsa Italiana that it would like the server to initialise 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 The Trading 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 a process or site outage. However, in case the sequence numbers needs to be reset, clients are required to support a manual request by the Exchange to initialise sequence numbers prior to the next login attempt. 17

18 5 Recovery 5.1 Resend Requests The client may use the Resend Request message to recover any lost messages. As outlined in the FIX protocol, this message may be used in one of three modes: (i) (ii) (iii) To request a single message. The BeginSeqo (7) and EndSeqo (16) should be the same. To request a specific range of messages. The BeginSeqo (7) should be the first message of the range and the EndSeqo (16) should be the last of the range. To request all messages after a particular message. The BeginSeqo (7) should be the sequence number immediately after that of the last processed message and the EndSeqo (16) should be zero (0). 5.2 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 MsgSequm (34). 5.3 Possible resends The server may, in the circumstances outlined in Sections 5.4, use the PossResend (97) field to indicate that a Trade Capture Report may have already been sent under a different MsgSequm (34). The client should validate the TradeReportID (571) of such a message against that of previous Trade Capture Reports received from the server during the current trading day. If a Trade Capture Report with the same TradeReportID (571) had been processed, the resent Trade Capture Report should be ignored. If the same TradeReportID (571) had not been processed, the message should be processed. The server does not handle possible resends for client-initiated messages and ignores the value in the PossResend (97) field of such messages. 5.4 Transmission of missed messages The Trade Capture Reports 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 Y. 18

19 5.4.1 Application sequencing and recovery The server supports the application sequencing and recovery features introduced in Service Pack 2 for FIX 5.0. A client may use the Application Message Request to recover missed trades in scenarios such as the following: (i) (ii) (iii) Trades are missed due to a late connection or disconnection during the day. Session level recovery via a Resend Request is unavailable due to a sequence number reset initiated by the client or server. All or some of the trades transmitted by the server during the current day are lost due to a failure at the client site Application sequencing by server The matching system consists of a series of parallel partitions each of which provide the matching service for an exclusive set of securities. Each Trade Capture Report transmitted by the server will include the identity of the matching partition that generated the trade and the partition s internal sequence number for the trade in the fields ApplID (1180) and ApplSequm (1181) respectively. As the matching partitions operate in parallel and employ the same application sequencing scheme, an ApplSequm (1181) is only unique per ApplID (1180). The ApplSequm of each ApplID will be initialised to 1 at the start of each trading day. As a client will only receive a subset of the trades executed by each matching partition, the field ApplLastSequm (1350) is also included in each Trade Capture Report. This field will contain the ApplSequm of the last Trade Capture Report generated for client. This will enable clients to distinguish deliberate sequence gaps from application errors by comparing the value of ApplLastSequm (1350) to the ApplSequm (1181) of the last received Trade Capture Report from the same ApplID (1180). Trade Capture Reports sent as a response to Trade Capture Report Request will not contain ApplLastSequm (1350). The Exchange may change the number of partitions and the securities each serves with due notice to clients Detecting an application sequence gap A client can detect a dropped message by comparing the ApplLastSequm (1350) of each new Trade Capture Report against the ApplSequm (1181) of the last trade received from the same ApplID (1180). In the case of a reconnection, the client can either wait for the next Trade Capture Report to determine whether trades have been missed or issue a request for the most current ApplSequm for each ApplID. Requesting the Latest ApplSequm The client may use the Application Message Request to request the latest ApplSequm for one or more ApplIDs. The ApplReqType (1347) of the message should be Request for Last ApplLastSequm (2). Response to Request for Latest ApplSequm The server will respond to the Application Message Request with an Application Message Request Ack. If the request was unsuccessful for a particular ApplID, the reason will be specified in the field ApplResponseError (1354). In the case of a successful request, the ApplSequm of the last trade generated for the client by each ApplID will be specified in the field RefApplLastSequm (1357). 19

20 Requesting retransmission of missed trades The client may use the Application Message Request to recover any lost trades. The ApplReqType (1347) of the message should be Retransmission of Application Messages (0). The message may be used in one of four modes: (i) To request a single trade. The ApplBegSequm (1182) and ApplEndSequm (1183) should be the same. (ii) (iii) (iv) To request a specific range of trades. The ApplBegSequm (1182) should be the first trade of the range and the ApplEndSequm (1183) should be the last of the range. To request all trades after a particular trade. The ApplBegSequm (1182) should be the application sequence number immediately after that of the last processed trade and the ApplEndSequm (1183) should be zero (0). To request all trades for the day. The ApplBegSequm (1182) should be one (1) and the ApplEndSequm (1183) should be zero (0). In all cases, the client should identify the matching partition to which the request relates via the field RefApplID (1355) Response to a trade 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 was unsuccessful for a particular ApplID, the reason will be specified in the field ApplResponseError (1354). In the case of a successful retransmission request, the server will resend the requested Trade Capture Reports and Trade Capture Report Ack immediately after the Application Message Request Ack. Each Trade Capture Report and Trade Capture Report Ack will include an ApplResendFlag (1352) of Y to indicate that it is resent in response to an Application Message Request. The resent messages will not include the field ApplLastSequm (1350). A Trade Capture Report Ack will not be sent if the initial Trade Capture Report is rejected at Gateway level Disconnection prior to completion of Retransmission If the FIX connection is terminated prior to the completion of the Trade Capture Report retransmission, the client should submit a new Application Message Request once it reconnects to the server. 20

21 6 Supported message types This section lists all administrative and application message types supported by the server. Any message not included in this section will be ignored by the server. 6.1 Administrative Messages All administrative messages may be initiated by either the client or the server. Message MsgType Usage 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. Logon A Allows the client and server to establish a FIX session. Test Request Resend Request 1 Allows the client or server to request a response from the other party if inactivity is detected. 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. Logout 5 Allows the client and server to terminate a FIX session. 6.2 Application Messages Trade Feed Trade Feed Client-Initiated Message MsgType Usage (on book trade) Trade Capture Report Request Application Message Request AD BW Allows the client to query/request for a set of Trade Capture Reports from the server Allows a real-time client to request one of the following: (i) Retransmission of missed trades (ii) Latest ApplSequm of each ApplID Trade Feed Server-Initiated Message MsgType Usage (on book trade) Trade Capture Report AE Indicates one of the following: (i) Trade (ii) Trade cancellation 21

22 Trade Capture Report Request Ack Application Message Request Ack AQ BX Acknowledges the receipt of a Trade Capture Report Request message from the client. Indicates whether a request to retransmit trades or for the latest ApplSequm is successful or not. 6.3 Application Messages Off-Book Trades Off-Book Trades Client-Initiated Message MsgType Usage (on book trade) Trade Capture Report AE Allows a client to: (i) Submit an off-book trade for registration (ii) Request the pre-release of a confirmed but unpublished off-book trade Off-Book Trades Server-Initiated Message MsgType Usage (off-book trade) Trade Capture Report Ack Trade Capture Report AR AE Indicates that a request to register or pre-release an off-book trade is acknowledged or rejected. Indicates one of the following: (i) Off-book trade confirmed (ii) Off-book trade pre-released on market data feed (iii) Off-book trade cancelled 6.4 Application Messages: Other (Server-Initiated) Message MsgType Usage Business Message Reject J (a) Indicates that an application message sent by the client could not be processed. 6.5 Variations from the FIX Protocol The server conforms to the FIX protocol except as follows: (i) The Trade Capture Report includes the custom field PublicationDelay. The data type of this field is Int (i.e. integer). 22

23 (ii) The TradeRequestResult (749) field of the Trade Capture Report Request Ack includes custom values. (iii) The Trade Capture Report Request includes the field MatchType (574). 23

24 7 Message formats This section provides details on the header and trailer, the seven administrative messages and seven application messages utilised by the post trade gateway. Client-initiated messages not included in this section are rejected by the server via a Reject or Business Message Reject. All fields are encoded in using printable ASCII. 7.1 Message header and trailer Message Header Tag Field ame Req Description 8 BeginString Y FIXT BodyLength Y umber of characters after this field up to and including the delimiter immediately preceding the CheckSum. 35 MsgType Y The message type. 0 Heartbeat 1 Test Request 2 Resend Request 3 Reject 4 Sequence Reset 5 Logout A AD AE AQ AR BW BX j Logon Trade Capture Report Request Trade Capture Report Trade Capture Report Request Ack Trade Capture Report Ack Application Message Request Application Message Request Ack Business Message Reject 49 SenderCompID Y CompID of the party sending the message. 56 TargetCompID Y CompID of the party the message is sent to. 34 MsgSequm Y The sequence number of the message. 24

25 43 PossDupFlag Whether the message was previously transmitted under the same MsgSequm (34). Absence of this field is interpreted as Original Transmission (). Y Possible Duplicate Original Transmission 97 PossResend Whether the message was previously transmitted under a different MsgSequm (34). Absence of this field is interpreted as Original Transmission (). Y Possible Resend Original Transmission 52 SendingTime Time the message was transmitted. ot 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. 115 OnBehalfOfCompID The ID of the party which the message is on behalf of; will only be used in client initiated messages. 122 OrigSendingTime 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) ApplVerID Version of FIX used in the message. Required if the message is generated by the server. 9 FIX50SP Message Trailer Tag Field ame Req Description 10 CheckSum Y 25

26 7.2 Administrative messages Logon Tag Field ame Req Description Standard Header 35 MsgType Y A = Logon Message Body 98 EncryptMethod Y The method of encryption. 0 one 108 HeartBtInt Y Indicates the heartbeat interval in seconds. 141 ResetSequm Flag Indicates whether the client and server should reset sequence numbers. Absence of this field is interpreted as Do ot Reset Sequence umbers (). Y Reset Sequence umbers Do ot Reset Sequence umbers 554 Password The password assigned to the CompID. Required if the message is generated by the client. 925 ewpassword The new password for the CompID SessionStatus Status of the FIX session or the request to change the password. Required if the message is generated by the server. 0 Session Active 2 Password Due to Expire 1137 DefaultApplVerID Y Default version of FIX messages used in this session. 9 FIX50SP2 Standard Trailer 26

27 7.2.2 Logout Tag Field ame Req Description Standard Header 35 MsgType Y 5 = Logout Message Body 1409 SessionStatus Status of the FIX session. Required if the message is generated by the server. 4 Session logout complete 6 Account locked 7 Logons are not allowed at this time 8 Password expired 100 Other 101 Logout due to session level failure 102 Logout by the Exchange 58 Text The field will contain the next expected sequence number if the server terminated the connection after receiving a sequence number that was less than what was expected. In other cases the field will contain the reason for the logout. Standard Trailer Heartbeat Tag Field ame Req Description Standard Header 35 MsgType Y 0 = Heartbeat Message Body 112 TestReqID Required if the heartbeat is a response to a Test Request. The value in this field should echo the TestReqID (112) received in the Test Request. Standard Trailer 27

28 7.2.4 Test Request Tag Field ame Req Description Standard Header 35 MsgType Y 1 = Test Request Message Body 112 TestReqID Y Identifier for the request. Standard Trailer Resend Request Tag Field ame Req Description Standard Header 35 MsgType Y 2 = Resend Request Message Body 7 BeginSeqo Y Sequence number of first message in range. 16 EndSeqo Y Sequence number of last message in range. Standard Trailer Reject Tag Field ame Req Description Standard Header 35 MsgType Y 3 = Reject Message Body 45 RefSequm Y MsgSequm (34) of the rejected message. 371 RefTagID If a message is rejected due to an issue with a particular field its tag number will be indicated. 372 RefMsgType MsgType (35) of the rejected message. 373 SessionReject Reason Code specifying the reason for the reject. Please refer to Section 8 for a list of reject codes. 58 Text Text specifying the SessionRejectReason(373) Standard Trailer 28

29 7.2.7 Sequence Reset Tag Field ame Req Description Standard Header 35 MsgType Y 4 = Sequence Reset Message Body 36 ewseqo Y Sequence number of the next message to be transmitted. 123 GapFillFlag The mode in which the message is being used. Absence of this field is interpreted as Sequence Reset (). Y Gap Fill Sequence Reset Standard Trailer 29

30 7.3 Application messages: Trade Feed Trade Capture Report Request (Client Initiated) Tag Field ame Req Description Standard Header 35 MsgType Y AD = Trade Capture Report Request Message Body 568 TradeRequestID Y Client specified unique identifier of the request. 569 TradeRequestType Y Type of request. 0 All Trades 1 Trades Matching Specified Criteria If none of the criteria below are specified, this will return all trades for the particular participant. 150 ExecType Type of trade report requested. F H Trade Trade Cancel 574 MatchType Point in matching process trade was matched. 828 TrdType 2 Off-Book Trade (Two-Party Report) 4 Continuous Trading 7 Auction 0 All Regular Trades 54 All Off Book Trades 48 SecurityID Unique Instrument ID assigned to the instrument in the Millennium Exchange. 22 SecurityIDSource Required if SecurityID (48) is specified. 8 Exchange Symbol 30

31 454 osecurityaltid If present, value in this field should always be SecurityAltID Identification number of the instrument. 456 SecurityAltID Source Type of instrument identification used. Required if SecurityAltID (455) is specified. 4 ISI 167 SecurityType Indicates the instrument type ProductComplex Indicates the segment. 711 ounderlyings umber of underlyings. If present, the value in this field should always be Underlying Symbol Symbol of the underlying instrument. Required if ounderlyings (711) is specified. 106 Issuer Issuer of the instrument. 54 Side Side of the executed order. 1 Buy 2 Sell 11 ClOrdID Identifier of the executed order as specified by the entering firm. 37 OrderID Identifier of the executed order as specified by matching system. 453 opartyids umber of party identifiers. 448 PartyID Identifier of the party. 447 PartyIDSource D Proprietary/Custom Code 452 PartyRole Role of the specified PartyID (448). 1 Executing Firm 12 Trader ID 17 Counterparty Firm 76 Trader Group 24 Clearing Organisation 1 Account Client reference for the trade. Standard Trailer 31

32 7.3.2 Application Message Request (Client Initiated) Tag Field ame Req Description Standard Header 35 MsgType Y BW = Application Message Request Message Body 1346 ApplReqID Y Client specified unique identifier of the request ApplReqType Y Type of request. 0 Retransmission of Application Messages 2 Request for Last ApplSequm 1351 oapplids Y umber of ApplIDs to which the request relates RefApplID Y Identifier of the partition ApplBeg Sequm 1183 ApplEnd Sequm Standard Trailer Application sequence number of first message in range to be resent. Required if ApplReqType (1347) is Retransmission of Application Messages (0). Application sequence number of last message in range to be resent. Required if ApplReqType (1347) is Retransmission of Application Messages (0) Trade Capture Report (Server Initiated) Tag Field ame Req Description Standard Header 35 MsgType Y AE = Trade Capture Report Message Body 1180 ApplID Y Identifier of the partition ApplSequm Y Partition s sequence number for trade ApplLastSequm ApplSequm of last trade generated for client. Required if ApplResendFlag (1352) is and TradeRequestID (568) is not present. 32

33 1352 ApplResendFlag Whether the message is sent in response to an Application Message Request. Absence of this field is interpreted as Original Transmission (). Y Response to Application Message Request Original Transmission 568 TradeRequestID Identifier of the Trade Capture Report Request the message is sent in response to. 912 LastRptRequested Indicates the last message sent in response to a Trade Capture Report Request. Y Last Message 571 TradeReportID Y Identifier of the message TradeID Y Identifier of the trade. 820 TradeLinkID Y Identifier of the transaction in which the trade was executed FirmTradeID Identifier assigned to an off-book trade by the counterparties. Required if TrdType (828) is Off-Book Trade (54). 572 TradeReportRefID Reference to trade being cancelled Required if ExecType (150) is Trade Cancel (H) TradeHandlingInstr Y Handling instructions to client. 0 Trade Confirmation 856 TradeReportType Y Type of trade report. 0 Submit 6 Trade Report Cancel 7 Trade Break 150 ExecType Y Type of execution being reported. F H Trade Trade Cancel 33

34 20110 Clearing Type Y Defines whether the particular instrument is cleared or not. 0 ot Cleared 1 Cleared ovated Indicator Y Defines whether the trade needs to be sent to clearing system. 0 o 1 Yes Original Price Used to specify the price of the off book trade if it was carried out in a currency other than the trading currency of the instrument. The value specified is the value in SettlCurrency(120) 120 Settlement Currency 487 TradeReportTrans Type Y Original executing currency of the off book trade, if it is different to the instrument s trading currency. Type of transaction being reported. 0 ew 1 Cancel 2 Replace 3 Release 573 MatchStatus Y Status of the trade. 0 Matched 1 Unmatched 2 Advisory/Error 1124 OrigTradeHandling Instr Model under which off-book trade was confirmed. Required if TrdType (828) is Off- Book Trade (54). 1 Two-Party Report 828 TrdType Type of trade. Absence of this field should be interpreted as Regular Trade (0). 0 Regular Trade 54 Off-Book Trade 34

35 60 TransactTime Y Time trade, cancellation, or pre-release occurred. If an off-book trade is reported this is the date and time it was executed on the participant s system. 32 LastQty Y Traded quantity. 423 PriceType Quotation format for instrument. Absence of this field should be interpreted as Price Per Unit (2). 1 Percent of Par 2 Price Per Unit 9 Yield 31 LastPx Y Traded price. 669 LastParPx Traded price expressed in percent-of-par. Required if PriceType (423) is Yield (9). 236 Yield Implied yield of this trade. This is a percentage field (e.g represents 5%). Required if PriceType (423) is Percentage of Par (1). 64 SettlDate Date on which the trade will settle. 574 MatchType Y Point in matching process trade was matched. 2 Off-Book Trade (Two-Party Report) 4 Continuous Trading 7 Auction 48 SecurityID Y Unique Instrument ID assigned to the instrument in the Millennium Exchange. 22 SecurityIDSource Y 8 Exchange Symbol 454 osecurityaltid If present, value in this field will always be SecurityAltID Identification number of the instrument. 456 SecurityAltID Source Type of instrument identification used. Required if SecurityAltID (455) is specified. 4 ISI 167 SecurityType Indicates the instrument type ProductComplex Segment the instrument belongs to. 35

36 541 MaturityDate Date an instrument expires. Required for fixed income instruments. 711 ounderlyings umber of underlyings for the instrument. If present, the value in this field will always be Underlying Symbol Symbol of the underlying instrument. Required if ounderlyings (711) is specified. 106 Issuer Issuer of the instrument. Required for fixed income instruments. 225 IssueDate Date on which the instrument was issued. Required for fixed income instruments. 548 Cross ID The unique ID of the Cross/BTF Order. 549 Cross Type The type of the Cross/BTF Order CurrentMarketPrice Indicator egotiatedtrade Indicator 5 Internal Cross 6 Internal BTF 7 Committed Cross 8 Committed BTF whether the trade price is outside the current market value or within the current market value The possible values that should be supported should be; 1 Yes 0 o If the field indicates Yes (1), then the submitted off book trade will be considered as within the current market value. If the field indicates o (0), then the submitted off book trade will be considered as outside the current market value. Whether the submitted off book trade is a negotiated trade or a non negotiated trade. The possible values that should be supported should be; 1 Yes 0 o If the field indicates Yes (1), then the submitted off book trade will be considered as a negotiated trade. If the field indicates o (0), then the submitted off book trade will not be considered as a negotiated trade (means it will be considered as a non negotiated trade). 36

37 27004 ExceededTheMinim um SizeIndicator RequestotToPubli sh QuantityIndicator Whether the consideration of the trade is greater than 500,000 Euros The possible values that should be supported should be; 1 Yes 0 o This field should be tagged Yes (1), if the client believes that the consideration has exceeded 500,000 Euros, for the instruments of type non-share. This field should be tagged o (0), if the client believes that the consideration has not exceeded 500,000 Euros, for the instruments of type non-share. This is the field that is used by the user which communicates whether the quantity of the trade should not be published via market data feed since the consideration of the trade is greater than 500,000 Euros. This field should only be tagged for non-share instruments and if specified Yes the quantity should not be disseminated via market data feeds when the trade is published. The possible values that should be supported should be; 1 Yes 0 o 37

38 27006 This field should be tagged only if the TCR is sent to the client for Off Book Trades which will be published delayed. Delay Mode If a trade that is reported today and it is delayed, such that the delayed trade is published at a specified time, then the Intended Publish Time should indicate the date and the intended publish time with the Delay Mode set to Time Based Delay (0). If a trade that is reported today and it is delayed, such that the delayed trade is published on a future date at a specific event (EOD, SOD or OO), then the Intended Publish Time should indicate the future date (with no time) and the Delay Mode field should contain the event at which the trade is published. If a trade is reported today and it is immediately published, then the Intended Publish Time should indicate the date and the intended publish time with the Delay Mode set to Time Based Delay (0). 0 Time Based Delay 1 SOD 2 EOD 3 OO For delayed off book trades, currently the TCR is published twice. I.e. a TCR is published when the delayed off book trade is initially submitted (with the status set to 'pending publication') and also another TCR is published when the off book trade is actually published (with the status 'Published'). It is necessary to include the "Delay Mode" and the "Intended Publish Time" data in both these TCR messages Intended Publish Time The Trade Publish Date and Time in UTC VenueIdentification Code This will communicate the venue outside the system which involved in the off-book trade. 552 osides Y umber of sides which will always be 1. 38

39 54 Side Y Side of the executed order. 1 Buy 2 Sell 1427 SideExecID Identifier of the execution received by the order. 453 opartyids Y umber of party identifiers. 448 Party ID 447 Party ID Sour ce 452 Party Role 625 Trading SessionSub ID 1115 OrderCateg ory 1444 SideLiquidit y Ind Y Y Identifier of the party. D Proprietary/Custom Code Y Role of the specified PartyID (448). Y 1 Executing Firm 17 Contra Firm 12 Trader ID 76 Trader Group 24 Clearing Organization Type of auction trade was executed in. Required if MatchType (574) is Auction (7), 2 Opening Auction 4 Closing Auction 6 Re-Opening Auction Type of interest behind trade. 1 Order 2 Quote 3 Off-Book Trade Whether the order added or removed liquidity. 1 Added Liquidity 2 Removed Liquidity 4 Auction 37 OrderID Identifier of the executed order as specified by the matching system. 39

40 11 ClOrdID Identifier of the executed order as specified by the entering firm. 528 OrderCapac ity Y Capacity of the firm that placed the order. A P Agency Principal 1 Account Client Reference specified at order entry 581 Account Type Clearing account type. 1 Client 3 House For Off Book trades, the field can be optionally set for the side block that contains Executing Firm (1) Party Role (452). It should be omitted from the side block that contains Counterparty Firm (17) Party Role (452). Standard Trailer For On Book trades, the field will not be populated Trade Capture Report Request Ack (Server Initiated) Tag Field ame Req Description Standard Header 35 MsgType Y AQ = Trade Capture Report Request Ack Message Body 568 TradeRequestID Y Identifier of the request being acknowledged. 569 TradeRequestType Y specified in the request. 750 TradeRequestStatus Y Whether the request is accepted or rejected. 0 Accepted 2 Rejected 40

41 749 TradeRequestResult Y Reason the request is rejected. 0 Successful 9 ot Authorized 100 Cannot Match Selection Criteria 200 Request Limit for Day Reached 748 TotumTradeReports umber of Trade Capture Reports that will be sent in response to the request. Required if TradeRequestStatus (750) is Accepted (0). Standard Trailer Application Message Request Ack (Server Initiated) Tag Field ame Req Description Standard Header 35 MsgType Y BX = Application Message Request Ack Message Body 1353 ApplResponseID Y Server specified identifier of the acknowledgement ApplReqID Y Identifier of the request being acknowledged ApplReqType Y specified in the request being acknowledged oapplids Y umber of ApplIDs to which the request relates RefApplID Y Identifier of the partition ApplBeg Sequm 1183 ApplEnd Sequm 1357 RefAppl LastSeq um 1354 Appl Response Error Application sequence number of first message in range to be resent. Required if ApplReqType (1347) is Retransmission of Application Messages (0). Application sequence number of last message in range to be resent. Required if ApplReqType (1347) is Retransmission of Application Messages (0). ApplSequm of the last trade generated for the client. Required if ApplReqType (1347) is Request for Last ApplSequm (2) and ApplResponseError (1354) is not specified. Reason request is rejected. 0 ApplID Does ot Exist 1 Requested Trades are ot Available 2 Client ot Authorised 58 Text Text specifying the reason for the rejection. 41

42 Standard Trailer 7.4 Application Messages: Off-Book Trades Trade Capture Report (Client Initiated) Tag Field ame Req Description Standard Header 35 MsgType Y AE = Trade Capture Report Message Body 571 TradeReportID Message identifier assigned by the client FirmTradeID Identifier assigned to the trade by the counterparties. Required if an off-book trade is being submitted for registration. Required if TrdType (828) is Off-Book Trade (54). This field is not validated on pre-release requests TradeID Server-assigned identifier of the trade. Required for a pre-release or cancel request. Required if a request to register pre-release or cancel a trade is being accepted a trade is being accepted or declined TradeHandlingInstr Y Model under which the trade, pre-release or cancel request should be confirmed. 1 Two-Party Report 856 TradeReportType Y Type of trade report. 487 TradeReportTrans Type Y 0 Submit 6 Trade Report Cancel Type of request. 0 ew 3 Release 42

43 828 TrdType Y Type of the trade. 54 Off-Book Trade 60 TransactTime Date and time the trade was executed on the participant s system. Required if an off-book trade is being submitted for registration. 32 LastQty Traded quantity. Required if an off-book trade is being submitted for registration. 31 LastPx Traded price. Required if an off-book trade is being submitted for registration. 64 SettlDate Y Date on which the trade will settle. It is not possible for an off book trade to be submitted without a settlement date TradePublishIndicat or When the trade should be published on the market data feed. If an off book trade for the Instrument Type of on Share is reported to the system which is requested to be Immediately Published (value 1 below), the particular off book trade will be rejected by the system upon injection 1 Publish Immediately 2 Delayed Publication 43

44 27002 CurrentMarketPrice Indicator egotiatedtrade Indicator whether the trade price is outside the current market value or within the current market value The system should only accept the values 1 or 0 as stated below and the system should not do any further validations upon receiving this value. The possible values that should be supported should be; 1 Yes 0 o If the field indicates Yes (1), then the submitted off book trade will be considered as within the current market value. If the field indicates o (0), then the submitted off book trade will be considered as outside the current market value. If a value has not been specified, then the submitted off book trade will be considered as outside the current market value. (I.e. Default value = o (0)) Whether the submitted off book trade is a negotiated trade or a non negotiated trade. The system should only accept the values 1 or 0 as stated below and the system should not do any further validations upon receiving this value. The possible values that should be supported should be; 1 Yes 0 o If the field indicates Yes (1), then the submitted off book trade will be considered as a negotiated trade. If the field indicates o (0), then the submitted off book trade will not be considered as a negotiated trade (means it will be considered as a non negotiated trade). If a value has not been specified, then the submitted off book trade will be considered as a non negotiated trade. (I.e. Default value = o (0)) 44

45 27004 ExceededTheMinim um SizeIndicator Whether the consideration of the trade is greater than 500,000 Euros. The system should do the following validations upon receiving the value 1 or 0 (indicating that the consideration of the trade is greater than 500,000 Euros or not) for this field. The system will accept the off book trades when this field is tagged with 1 or 0 for instruments of type non-share only. If this field is tagged with value 0 for instruments of type share, the off book trade message will be accepted; if this field is tagged with value 1 for instruments of type share, the off book trade should be rejected by the system. However, the system will not do any validations upon the actual consideration of the trade being greater than 500,000 Euros or not. I.e. the client should be responsible for using this field. (E.g. the client should ensure that he will tag this field to indicate that it has exceeded the minimum consideration, only if he has actually exceeded 500,000 Euros. The system will not perform any validation on this). The possible values that should be supported should be: 1 Yes 0 o This field should be tagged Yes (1), if the client believes that the consideration has exceeded 500,000 Euros, for the instruments of type non-share. This field should be tagged o (0), if the client believes that the consideration has not exceeded 500,000 Euros, for the instruments of type non-share. 45

46 27005 RequestotToPubli sh QuantityIndicator This is the field that is used by the user which communicates whether the quantity of the trade should not be published via market data feed since the consideration of the trade is greater than 500,000 Euros. 1 Yes 0 o The system should do the following validations upon receiving any value 1 or 0, (do not publish the quantity or publish the quantity) for this field. The system will accept any off book trade when this field is tagged with value 1 or 0 for instruments of type non-share. If this field is tagged with value 0 for instruments of type share, the off book trade message will be accepted; if this field is tagged with value 1 for instruments of type share, the off book trade should be rejected by the system. As stated above if this field is tagged for non-share instruments with the value 1 (Yes), the quantity should not be disseminated via market data feeds when the trade is published. If this field is tagged for share and non-share instruments with the value 0 (o), the quantity should be disseminated via market data feeds when the trade is published. The value submitted in a pre-release request will override the value submitted with the original off book trade (if changed). Also if a value is not submitted with a pre-release request, value 0 will be used as the default value and will override any value submitted with the original off book trade. 46

47 27008 VenueIdentification Code This will communicate the venue outside the system which involved in the off-book trade. This will be submitted to the system together with the off-book trade. This will have a length of 11 characters. The system should accept the value that will be submitted by the client and the system should not do any further validations upon receiving this value. 48 SecurityID Y Unique Instrument ID assigned to the instrument in the Millennium Exchange. 22 SecurityIDSource Y 8 Exchange Symbol OriginalPrice Used to specify the price of the off book trade if it was carried out in a currency other than the trading currency of the instrument. The value specified is the value in SettlCurrency(120) 120 SettlCurrency Original executing currency of the off book trade, if it is different to the instrument s trading currency. For example GBX ZAC ITL GB Pennies South African Cents (1/100 th of a Rand) Italian Lira 552 osides Y umber of sides which should always be Side Y Side of the pre-negotiated trade. 453 opartyid s Y 1 Buy 2 Sell umber of party identifiers Part yid Y Identifier of the party Part yid Sour ce Y D Proprietary/Custom Code 47

48 45 2 Part y Role 528 OrderCap acity Y Role of the specified PartyID (448). 1 Executing Firm 17 Contra Firm 12 Trader ID 24 Clearing Organisation 76 Trader Group Capacity of the firm that executed the off book trade. Required if TradeHandlingInstr (1123) is Two-Party Report (1). For Off Book trades, the field is required for the side block that contains Executing Firm (1) Party Role (452). It should be omitted from the side block that contains Counterparty Firm (17) Party Role (452) If this is not specified for side block that contains the Executing Firm(1) PartyRole (452) when submitting off book trades the trade will be rejected with reject code 99 and reason Capacity not specified for Executing Firm 581 AccountT ype Standard Trailer Valu e A P Agency Principal Clearing account type. 1 Client 3 House For Off Book trades, the field can be optionally set for the side block that contains Executing Firm (1) Party Role (452). It should be omitted from the side block that contains Counterparty Firm (17) Party Role (452) Trade Capture Report Ack (Server Initiated) Tag Field ame Req Description 48

49 Standard Header 35 MsgType Y AR = Trade Capture Report Ack Message Body 571 TradeReportID submitted in trade report FirmTradeID submitted in trade report TradeID Server-assigned identifier of the trade TradeHandlingInstr Y submitted in trade report ApplResendFlag Whether the message is sent in response to an Error! Reference source not found.. Absence of this field is interpreted as Original Transmission (). Y Response to Application Message Request Original Transmission 939 TrdRptStatus Y Whether the trade report is accepted or rejected. 751 TradeReportReject Reason 0 Accepted 1 Rejected Code specifying the reason for rejection. Please refer to Section 8.1 for a list of reject codes. Required if TrdRptStatus (939) is Rejected (1). 58 Text Text specifying the reason for the rejection. 856 TradeReportType Y submitted in trade report. 487 TradeReportTrans Type Y submitted in trade report. 573 MatchStatus Y Status of the off-book trade. 0 Matched 1 Unmatched 32 LastQty submitted in trade report. 31 LastPx submitted in trade report. 64 SettlDate submitted in trade report TradePublishIndicator submitted in trade report. 48 SecurityID Y Unique Instrument ID assigned to the instrument in the Millennium Exchange. 49

50 22 SecurityIDSource Y 8 Exchange Symbol 828 TrdType submitted with the trade report. 60 TransactTime Y This has to be the time specified by the user on the submitted TCR in case of acknowledgement of off book trades. 552 osides Y submitted in trade report. 54 Side Y submitted in trade report. 453 opartyids Y umber of party identifiers. 448 PartyID Y Identifier of the party 447 PartyID Source 452 Party Role Y D Proprietary/Custom Code Y Role of the specified PartyID (448). 1 Executing Firm 17 Contra Firm 76 Trader Group 528 OrderCapacity submitted in trade report. 581 AccountType submitted in trade report. Will not be stamped on Contra party side block Standard Trailer 7.5 Application Messages: Other Business Message Reject Tag Field ame Req Description Standard Header 35 MsgType Y j = Business Message Reject Message Body 45 RefSequm Y MsgSequm (34) of the rejected message. 372 RefMsgType Y MsgType (35) of the rejected message. 371 RefTagID If a message is rejected due to an issue with a particular field its tag number will be indicated. 50

51 379 BusinessReject RefID 380 BusinessReject Reason Y Client specified identifier (e.g. Firm Trade ID) of the rejected message if it is available. Code specifying the reason for the reject. Please refer to Section 8.2 for a list of reject codes. 58 Text Text specifying the reason for the rejection. Standard Trailer 51

52 8 Reject codes Session Reject Reason 1 Required tag missing 2 Tag not defined for this message type 4 Tag specified without a value 5 is incorrect (out of range) for this tag 6 Incorrect data format for value 9 CompID problem 11 Invalid MsgType 13 Tag appears more than once 14 Tag specified out of required order 15 Repeating group fields out of order 16 Incorrect umingroup count for repeating group 18 Invalid or unsupported application version 99 Other 8.1 Trade Capture Report Ack Trade Report Reject Reason 2 Unknown instrument 4 Invalid TrdType (828) 8.2 Business Message Reject Business Reject Reason 0 Message Rate Exceeded 3 Unsupported message type 4 Application not available 5 Conditionally required field missing 52

53 53

54 Copyright June 2012 London Stock Exchange plc. Registered in England and Wales o London Stock Exchange plc has used all reasonable efforts to ensure that the information contained in this publication is correct at the time of going to press, but shall not be liable for decisions made in reliance on it. London Stock Exchange and the coat of arms device are registered trade marks of London Stock Exchange plc. London Stock Exchange 10 Paternoster Square London EC4M 7LS Telephone: +44 (0) V4.2