General
Introduction
The FIX5 Trading Gateway enables clients to submit orders and to receive real-time information on executed trades. 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.
Purpose
The purpose of this document is to provide a technical description of the FIX Market Data Gateway. This document outlines the service, its logic, and message types and fields involved.
Key
Usage | Meaning |
Req | Required? |
Y | Yes |
N | No |
C | Conditional |
Log
Nr. | Date | Changes |
1 | 8 Nov 2019 | First Edition |
Service Description
Order Handling
Order Types
Clients may submit the order types outlined below via New Order – Single Message.
Order Type | Description |
Market | An order that will execute at the price not worse than 10% from the best available price. |
Limit | An order that will execute at or better than the specified price. The remainder, if any, is added to the order book or expired by terms of its TimeInForce. |
Stop Market | A market order that remains inactive until the market reaches a specified stop price. |
Stop Limit | A limit order that remains inactive until the market reaches a specified stop price. |
Time in Force
Order Type | Description |
Market | An order that will execute at the price not worse than 10% from the best available price. |
Limit | An order that will execute at or better than the specified price. The remainder, if any, is added to the order book or expired by terms of its TimeInForce. |
Stop Market | A market order that remains inactive until the market reaches a specified stop price. |
Stop Limit | A limit order that remains inactive until the market reaches a specified stop price. |
Order Management
Cancellation
The remainder of a live order may be cancelled via the Order Cancel Request message. The server will respond with an Execution Report or Order Cancel Reject to confirm or reject the cancellation request respectively.
In a scenario where the Order Cancel Request message is submitted under a different SenderCompID (49) than the SenderCompID (49) of the original order, the Execution Report will be sent to the cancelling SenderCompID. If the user cancelling the order does not have permissions to cancel orders, the cancel request will be rejected.
The client should identify the order being cancelled by either its OrigClOrdID (41) or OrderID (37).
If an Order Cancel Request contains values for both OrigClOrdID (41) and OrderID (37), the server will only process the OrderID (37).
If an order submitted by a different user (PartyID (448)) is being cancelled, the Order Cancel Request should include its OrderID (37).
"Post Only" Mode
Orders for which the client has placed 'participateDoNotInitiate' (6) in the ExecInst (18) field of New Order - Single (D) will be in the order book only if they do not trigger a single transaction. Otherwise, two ExecutionReport messages will be returned to the client:
ExecType = New (0)
ExecType = Expired (C)
Amending an order
The following attributes of a live order may be amended via the Order Cancel/Replace Request message:
Order quantity
Price
Stop price
The server will respond with an Execution Report or Order Cancellation Rejection to confirm or reject the amendment request respectively.
In a scenario where the Order Cancel/Replace Request message is submitted by a different SenderCompID (49) than the SenderCompID (49) who submitted the original order, the Execution Report or Order Cancel Reject will be sent to the modifying SenderCompID (49). If the user amending the order does not have permissions to modify orders on behalf of the firm, the amend request will be rejected.
The client should identify the order being amended by either its OrigClOrdID (41) or OrderID (37). If an Order Cancel/Replace Request contains values for both OrigClOrdID (41) and OrderID (37), the server will only process the OrderID (37).
If an order submitted under a different SenderCompID (49) is being amended, the Order Cancel/Replace Request should include its OrderID (37). If the amendment is successful, the order will be treated as one submitted under the SenderCompID (49) that sent the Order Cancel/Replace Request.
The Stop price of a Stop Market / Stop Limit order cannot be amended once the order has been injected into the order book.
If an order receives one or more fills while an amendment request is in flight, the system will not reject the incoming amendment request if its quantity after amending will be greater than the filled quantity. Otherwise the amendment request will be rejected.
An order will lose time priority in the order book if any of its parameters are amended.
Order Execution Report
The ExecutionReport message is used to inform customers of up-to-date information about order status immediately after any occured event. This message contains the fields:
OrdStatus - this field is used to convey the current state of an order
ExecType - the type of occurred event is indicated
The list of order statuses is given in the table below:
OrdStatus
OrdStatus | Value | Description |
New | 0 | Order has been registered. |
PartiallyFilled | 1 | Order has been partially filled. |
Filled | 2 | Order has been fully filled. |
Cancelled | 4 | Order has been fully cancelled. |
Rejected | 8 | Order has been rejected. |
Expired | C | Order has been expired or cannot be placed into the order book (post-only, FOK, IOC) |
Suspended | 9 | Order is awaiting activation. |
The list of event types is given in the table below:
ExecType
ExecType | Value | Description |
New | 0 | Indicates that a new order has been accepted. This message will also be sent when a suspended order is injected and added to the order book. |
Cancelled | 4 | Indicates that an order cancel request has been accepted and successfully processed. This message will also be sent unsolicited if the order was cancelled by the system. |
Replaced | 5 | Indicates that an order cancel/replace request has been accepted and successfully processed. |
Rejected | 8 | Indicates that an order has been rejected. |
Suspended | 9 | Indicates that an order has been parked by the system without adding it to the order book. |
Expired | C | Indicates that an order has expired in terms of its time qualifier; or it is IOC, FOK; or ExecInst (18) contains ParticipateDoNotInitiate (6) |
Trade | F | Indicates that an order has been partially or fully filled. The execution details (e.g. price and quantity) are specified. |
OrderStatus | I | This value is used if the ExecutionReport is sent in response to OrderStatusRequest (H) or OrderMassStatusRequest (AF). |
Order and execution identifiers
Client Order IDs
Clients should comply with the FIX protocol and ensure unique ClOrdIDs across all messages (e.g. New Order – Single, Order Cancel Request, etc.) sent under a particular SenderCompID (49). Given that the server supports GTD orders, clients should also ensure that their ClOrdIDs are unique across trading days (e.g. embed the date within the ClOrdID).
Clients must, in terms of the FIX protocol, specify the ClOrdID (11) when submitting an Order Cancel Request or Order Cancel/Replace Request.
Adding SenderCompID to ClOrdID is recommended.
Example:
SenderCompID=login_00119485 ⇒ ClOrdID=001194853fec1f8430da0ec0247ebc6a
Order IDs
The server will use the OrderID (37) field of the Execution Report to keep track of orders within the matching system. Order IDs will be unique across trading days.
Clients have the option of specifying the OrderID (37) when submitting an Order Cancel Request or Order Cancel/Replace Request.
Execution IDs
The server will use the ExecID (17) field to affix a unique identifier for each Execution Report. ExecIDs will be unique across trading days.
Order ID tag length
The system will accept a maximum length of 32 characters. If the ID is longer than 32 characters then it will be rejected. This is valid for the following:
NewOrderSingle – ClOrdID (11)
OrderCancelRequest – OrigClOrdID (41)
OrderCancel/ReplaceRequest – OrigClOrdID (41)
RequestForPositions (AN) - PosReqID (710)
OrderStatusRequest (H) - OrdStatisReqID (790)
OrderMassStatusRequest (AF) - MassStatusReqID (584)
ClOrdID may contain delimiters as desired by the client.
Example:
0119485 / 3fec1f8430da0ec0247ebc6a
Connectivity
CompIDs
The CompID of each client must be registered 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 ME. The messages sent to the server should contain the CompID assigned to the client in the field SenderCompID (49) and ME in the field TargetCompID (56). The messages sent from the server to the client will contain ME 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 username and a password on registration.
Message Rate Throttling
A scheme for throttling message traffic is implemented, where each CompID is only permitted to submit up to a specified number of messages per second.
Every message which exceeds the maximum rate of a CompID will be rejected via a Business Message Reject (with BusinessRejectReason (380) of ThrottleLimitExceeded (8)).
Please note that client Heartbeat messages, reject messages and any other client-initiated administrative messages are not counted towards the throttling limits.
Mass Cancellation On Disconnect
The client may request to cancel all orders submitted through the FIX session. In the Logon (A) message, the value of the CancelOnDisconnect field (10001) defaults to N.
If it is set to Y, then as soon as the gate detects that the client has disconnected (intentionally or due to a connection loss), it will send requests to cancel working orders. If the connection is lost, the gate can detect a disconnection with a delay of several seconds when Heartbeat messages do not come from the client.
If the CancelOnDisconnect (10001) flag was not set in the Logon (A) message, then cancellation on disconnect can be activated for any new order. To do this, in the New Order - Single (D) message in the ExecInst field (18) add the value "o" (CancelOnConnectionLoss).
FIX connections and sessions
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 by sending the Logon (A) message. The client will identify itself using the SenderCompID (49) field. At each connection MsgSeqNum (34) is reset to 1, the client should set ResetSeqNumFlag (141) to "Y". 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 client must wait for the server’s Logon response before sending additional messages. If the client sends messages prior to sending the Logon message or prior to receiving the Logon response, the server will break the TCP/IP connection with the client without sending any message.
If a logon attempt fails (due to an invalid SenderCompID, invalid TargetCompID, invalid IP address, invalid password or not having the appropriate privileges to login to the gateway, or if the user sends a Logon message with duplicated tags), the server will break the TCP/IP connection with the client without sending a Logout or Reject message.
If during a logon of a SenderCompID, the server receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, the server will break the TCP/IP connection with the second connection without sending a Logout or Reject message.
Maintaining a FIX session
Message sequence numbers
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 initialized to 1 (one) at the start of the FIX session and be incremented throughout the 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 will contain the next expected sequence number as well as the received sequence number in the Text (58) field.
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.
As a safety mechanism, the system will not allow the user to login if the HeartBtInt is set to 0.
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 with the client. The client is expected to employ similar logic if inactivity is detected on the part of the server.
Increasing expected sequence number
The client or server may use the SequenceReset 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 SequenceReset message in SequenceReset mode if it wishes to increase the expected incoming sequence number of the other party. The SequenceReset mode should only be used to recover from an emergency situation. It should not be relied upon as a regular practice.
Terminating a FIX connection
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.
All open TCP/IP connections will be terminated by the server when it shuts down (a Logout will be sent). Under exceptional circumstances the server may initiate the termination of a connection during the trading day by sending the Logout message.
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.
Recovery
Resend requests
Sending and processing ResendRequest is not supported in our current implementation of FIX5. In response to an incoming ResendRequest, you should receive a valid Business Message Reject with BusinessRejectReason = 4.
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).
Message Format
This section provides details on the header and trailer, the seven administrative messages and fourteen 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.
Supported message types
Administrative messages
All administrative messages are 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. |
TestRequest | 1 | Allows the client or server to request a response from the other party if inactivity is detected. |
ResendRequest | 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. |
SequenceReset | 4 | Allows the client or server to increase the expected incoming sequence number of the other party. |
Application messages: order handling
Client Initiated:
Message | MsgType | Usage |
New Order – Single | D | Allows the client to submit a new order.. |
Order Cancel Request | F | Allows the client to cancel a live order. |
Order Cancel/Replace Request | G | Allows the client to cancel/replace a live order. |
OrderStatusRequest | H | Allows the client to request order status for one of his orders. |
OrderMassStatusRequest | AF | Allows the client to request order status for one of his orders. |
RequestForPositions | AN | Allows the client to request order status for one of his orders. |
Server Initiated:
Message | MsgType | Usage |
Execution Report | 8 | Indicates one of the following: |
Order Cancel Reject | 9 | Indicates that an order cancel request or order cancel/replace request has been rejected. |
PositionReport | AP | Comes in response when requesting a balance via RequestForPositions. |
Application messages: other
Server Initiated:
Message | MsgType | Usage |
Business Message Reject | J | Indicates that an application message could not be processed. |
Message Header and Trailer
| Tag | Field Name | Req | Description |
Header | 8 | BeginString | Y | FIXT.1.1 |
9 | 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). ('Y' = Possible Duplicate). | |
52 | SendingTime | Y | Time the message was transmitted. | |
122 | OrigSendingTime | C | 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'). | |
Trailer | 10 | CheckSum | Y | CheckSum |
Administrative Messages
Logon
The Logon message authenticates the client establishing a connection to the FIX Server. In addition to the standard fields, clients will need to populate two additional fields – Username (tag 553) and Password (tag 554).
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | A = Logon |
Message Body | |||
98 | EncryptMethod | Y | Method of encryption, 0 = None |
108 | HeartBtInt | Y | Indicates the heartbeat interval in seconds, no less than 1. |
141 | ResetSeqNumFlag | Y | Indicates whether the client and server should reset. Should always be set to the value Y = Reset Sequence Numbers, as N is not supported. |
383 | MaxMessageSize | N | The maximum value that can be presented in the BodyLength field. If a message is received from the client, where BodyLength is greater than MaxMessageSize, the connection will be closed. This field is sent by the server; if sent by the client, it will be ignored. п |
553 | Username | C | Username assigned to the CompID. Required if the message is sent by the client. Not sent by the server. |
554 | Password | C | Password assigned to the CompID. Required if the message is sent by the client. Not sent by the server. |
1137 | DefaultApplVerID | Y | Default version of FIX messages used in this session. The server will only validate a value of 9, which means FIX50SP2 |
10001 | CancelOnDisconnect | N | This flag is set to "Y" to enable cancel on disconnect functionality for all orders placed through this session that allows users to have this orders automatically canceled upon an unintentional loss of session connectivity, 'Y'/'N'. It set to 'N' by default. Parameter could be used by the client and isn’t applicable to the server side. |
Standard Trailer |
Logout
The Logout message initiates or confirms the termination of a FIX session. It can optionally contain the Text field (tag 58) which is populated with the reason for the Logout.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 5 = Logout |
Message Body | |||
1409 | SessionStatus | C | Status of the FIX session. Required if the message is generated by the server. |
58 | Text | N | The field will contain the next expected sequence number as well as the received 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 logout. |
Standard Trailer |
Heartbeat
The Heartbeat message monitors the status of the communication link and identifies when the last of a string of messages was not received. A Heartbeat is sent every HeartBtInt seconds, as defined in the Logon message, as well as in response to a TestRequest message.
Inclusion of the optional TestReqID field (tag 112) indicates that this Heartbeat is a response to a TestRequest message.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 0 = Heartbeat |
Message Body | |||
112 | TestReqID | C | 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 |
TestRequest
The TestRequest message forces a heartbeat from the opposing application. It can be initiated both from the client and from the server.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 1 = TestRequest |
Message Body | |||
112 | TestReqID | Y | Identifier for the request. |
Standard Trailer |
ResendRequest
This function is used if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialization process.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 2 = ResendRequest |
Message Body | |||
7 | BeginSeqNo | Y | Sequence number of first message in range. |
16 | EndSeqNo | Y | Sequence number of last message in range. |
Standard Trailer |
Reject
A Reject message is issued when a message is received but cannot be properly processed due to a session-level rule violation. Whenever possible, it is strongly recommended that the cause of the failure be described in the Text (tag 58) field.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 3 = Reject |
Message Body | |||
45 | RefSeqNum | Y | MsgSeqNum (34) of the rejected message. |
372 | RefMsgType | N | MsgType (35) of the rejected message. |
371 | RefTagID | N | If a message is rejected due to an issue with a particular field, its tag number will be indicated. |
373 | SessionRejectReason | N | Code specifying the reason for the reject: |
58 | Text | N | Text specifying the reason for the rejection. |
Standard Trailer |
SequenceReset
A Sequence Reset message instructs the receiving party to set the next expected message sequence number to a new value, which is contained in the FIX message in the NewSeqNo (tag 36) field.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 4 = SequenceReset |
Message Body | |||
36 | NewSeqNo | Y | Sequence number of the next message to be transmitted. |
123 | GapFillFlag | N | Mode in which the message is being used. Absence of this field is interpreted as Sequence Reset ('N' by default). ('Y' = Gap Fill). |
Standard Trailer |
Application messages: order handling
New Order - Single
The New Order message is used by clients wishing to electronically submit orders to the exchange for execution:
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | D = New Order - Single |
Message Body | |||
11 | ClOrdID | Y | Client specified identifier of the order. |
1 | Account | Y | An account number. |
453 | NoPartyIDs | Y | Number of party identifiers. Will be '1'. |
448 | PartyID | Y | Name of a user. |
447 | PartyIDSource | Y | 'D' = Proprietary |
452 | PartyRole | Y | Role of the specified PartyID. '3' = Client ID |
55 | Symbol | Y | Symbol |
40 | OrdType | Y | Type of the order. |
59 | TimeInForce | Y | Time qualifier of the order. 0 = Day |
126 | ExpireTime | C | Date and time the order expires. For GTD only. |
54 | Side | Y | Side of the order. |
38 | OrderQty | Y | Total order quantity in lots. |
44 | Price | C | Limit price. Required if OrderType (40) is Limit (2) or Stop Limit (4). |
99 | StopPx | C | Stop price. Required if OrderType (40) is Stop Market (3) or Stop Limit (4). |
18 | ExecInst | N | 6 = ParticipateDoNotInitiate |
544 | CashMargin | N | 1 = Cash (default) |
60 | TransactTime | N | Ignored. |
168 | EffectiveTime | N | Time required for processing of an order, the order will be declined when processing run out of time. There is no default value. |
Standard Trailer |
Order Cancel Request
The Order Cancel Request message requests the cancellation of all of the remaining quantity of an existing order.
Each Cancel Request is assigned a unique ID in the ClOrdID (tag 11) field, and is subsequently treated as a separate entity. If rejected, the ClOrdID (tag 11) of the cancel request will be sent in the Order Cancel Reject (9) message ClOrdID (tag 11) field, whereas the ClOrdID (tag 11) of the actual order in the OrigClOrdID (tag 41) field.
The ClOrdID (tag 11) assigned to the cancel request must be unique amongst the ClOrdID (tag 11) fields assigned to regular orders and replacement orders.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | F = Order Cancel Request |
Message Body | |||
11 | ClOrdID | Y | Client specified identifier of the cancel request. |
41 | OrigClOrdID | C | ClOrdID (11) of the order being cancelled. Required if OrderID (37) is not specified. |
37 | OrderID | C | Server specified identifier of the order being cancelled. Required if OrigClOrdID (41) is not specified. In the case when both parameters were specified, OrderID has priority over OrigClOrdID (41). |
55 | Symbol | Y | Symbol of the order. |
54 | Side | Y | Side of the order. |
1 | Account | Y | An account number. |
453 | NoPartyIDs | Y | Number of party identifiers. Will be '1'. |
448 | PartyID | Y | Name of a user. |
447 | PartyIDSource | Y | 'D' = Proprietary |
452 | PartyRole | Y | Role of the specified PartyID. '3' = Client ID |
60 | TransactTime | N | Ignored. |
Standard Trailer |
Order Cancel/Replace Request
The Order Cancel/Replace Request message can be used to change the details of an existing order.
When processing a Cancel/Replace the existing order is cancelled and a new order is placed on the order book. This is executed as a single atomic transaction. However, the newly-placed order loses its order book time priority. Hence, if the intention is to increase the quantity of an existing order, it is recommended that clients send a New Order message for the increased quantity rather than a Cancel/Replace.
Clients should not use this message to cancel the remaining quantity of an outstanding order. Instead, they should send an Order Cancel Request message.
The Cancel/Replace Request will only be accepted if the order can successfully be pulled back from the exchange without executing. Requests which cannot be processed will be rejected using the Cancel Reject message.
Each Cancel/Replace Request is assigned a unique ID in the ClOrdID (tag 11) field, and is subsequently treated as a separate entity. If rejected, the ClOrdID (tag 11) of the cancel request will be sent in the Order Cancel Reject (9) message ClOrdID (tag 11) field, whereas the ClOrdID (tag 11) of the actual order in the OrigClOrdID (tag 41) field. The ClOrdID (tag 11) assigned to the Order Cancel/Replace Request must be unique amongst the ClOrdID (tag 11) fields assigned to regular orders and replacement orders.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | G = Order Cancel/Replace Request |
Message Body | |||
11 | ClOrdID | Y | Client specified identifier of the cancel/replace request. |
41 | OrigClOrdID | Y | ClOrdID (11) of the order being amended. |
37 | OrderID | N | Unsupported. |
1 | Account | Y | Account associated with the order that the client is requesting to cancel/replace. |
453 | NoPartyIDs | Y | Number of party identifiers. Will be '1'. |
448 | PartyID | Y | Username. |
447 | PartyIDSource | Y | 'D' = Proprietary |
452 | PartyRole | Y | Role of the specified PartyID. '3' = Client ID |
55 | Symbol | Y | Symbol of the order. |
40 | OrdType | N | Ignored. |
54 | Side | Y | Side of the order. |
38 | OrderQty | Y | Total order quantity in lots. |
44 | Price | C | Limit price. Required if OrderType (40) is Limit (2) or Stop Limit (4). |
99 | StopPx | C | Stop price. Required if OrderType (40) is Stop Market (3) or Stop Limit (4). |
126 | ExpireTime | C | Date and time the order expires. For GTD only. Required only if TimeInForce (59) is GTD (6). |
60 | TransactTime | N | Ignored. |
168 | EffectiveTime | N | Time required for processing of an order, the order will be declined when processing run out of time. There is no default value. |
Standard Trailer |
Order Cancel Reject
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 9 = Order Cancel Reject |
Message Body | |||
11 | ClOrdID | Y | ClOrdID (11) that was submitted with the order cancel or cancel/replace request being rejected. |
41 | OrigClOrdID | Y | Value of the parameter is equal to the value of OrigClOrdID (41) of the cancel request preceding. |
37 | OrderID | N | Unsupported. |
39 | OrdStatus | Y | Status of the order. The current implementation of this message always returns '8' = Rejected. |
434 | CxlRejResponseTo | Y | Type of request being rejected. |
102 | ClxRejReason | Y | Code specifying the reason for the rejection. |
58 | Text | N | Text specifying the reason for the rejection. |
Standard Trailer |
Execution Report
The Execution Report message is used to:
confirm the receipt of an order
confirm changes to an existing order (i.e. accept cancel and replace requests)
relay order status information
relay fill information on working orders
reject orders
Each execution report contains two fields which are used to communicate both the current state of the order as understood by the broker - OrdStatus (tag 39) - and the purpose of the message - ExecType (tag 150).
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | 8 = Execution Report |
Message Body | |||
11 | CIOrdID | Y | Client specified identifier of the order. |
41 | OrigClOrdID | C | Will be filled with the actual original client order id of the order regardless of whether or not OrigClOrdID was specified (valid or invalid value) in the order cancel or cancel/replace request. |
37 | OrderID | Y | Server specified identifier of the order. |
17 | ExecID | Y | Unique identifier of execution message. |
790 | OrdStatusReqID | C | Required if this is is sent in reply to an OrderStatusRequest message. |
584 | MassStatusReqID | C | Required if this message is sent in reply to an OrderMassStatusRequest message. |
911 | TotNumReports | C | Required if this message is sent in reply to an OrderMassStatusRequest message. |
912 | LastRptRequested | C | Required if this message is sent in reply to an OrderMassStatusRequest message. |
150 | ExecType | Y | Reason the execution report was generated. |
39 | OrdStatus | Y | Current status of the order. |
103 | OrdRejReason | C | Code specifying the reason for the reject. Required if ExecType (150) is '8' = Rejected or 'C' = Expired. |
58 | Text | N | Text specifying the reason for the rejection, cancellation or expiration. |
151 | LeavesQty | Y | Quantity available for further execution. Will be: |
14 | CumQty | Y | Total cumulative quantity filled. |
55 | Symbol | C | Could be absent in the case where ExecType (150) is '8' = Rejected, i.e. if there is no order found to the OrderStatusRequest (H) request. |
1 | Account | Y | An account number. |
453 | NoPartyIDs | Y | Number of party identifiers. Will be '1'. |
448 | PartyID | Y | Name of user. |
447 | PartyIDSource | Y | 'D' = Proprietary |
452 | PartyRole | Y | Role of the specified PartyID. '3' = Client ID |
40 | OrdType | C | Value submitted with the order. |
59 | TimeInForce | N | Time qualifier of the order. |
126 | ExpireTime | C | Value submitted with the order. It is required TimeInForce (59) is '6' = GTD |
54 | Side | C | Value submitted with the order. It could be absent if ExecType (150) is '8' = Rejected. |
38 | OrderQty | Y | Value submitted with the order in lots. |
44 | Price | C | Value submitted with the order. Required only if OrdType (40) is Limit (2) or Stop Limit (4). |
99 | StopPx | C | Value submitted with the order. Required only if OrdType (40) is '3' = Stop Market or '4' = Stop Limit. |
18 | ExecInst | N | 6 = ParticipateDoNotInitiate |
60 | TransactTime | N | Time the transaction represented by the Execution Report occurred. It could be absent if ExecType (150) is '8' = Rejected. |
851 | LastLiquidityInd | C | Whether the order added or removed liquidity. |
880 | TrdMatchID | C | The unique ID of the trade. It's required for ExecType (150) if 'F' = Trade. |
6 | AvgPx | C | Calculated average price of all fills on this order. |
31 | LastPx | C | Price of this fill. It's required for ExecType (150) if 'F' = Trade. |
32 | LastQty | C | Quantity executed in this fill. It’s required for ExecType (150) if 'F' = Trade. |
136 | NoMiscFees | C | Required for ExecType (150) if 'F' = Trade. |
137 | MiscFeeAmt | Y | Fee value. |
138 | MiscFeeCurr | Y | Fee currency. |
139 | MistFeeType | Y | Fee type. It will be '4' = ExchangeFees. |
544 | CashMargin | N | 1 = Cash (default) |
2618 | PositionID | C | Unique position identifier. Required if CashMargin = 2 |
Standard Trailer |
OrderStatusRequest
The OrderStatusRequest message is used by clients to request order status for one of their orders. Server will respond with an Execution Report message with ExecType (150) = I - Order Status.
In case of any errors for example if the Order is not found, server will respond with an ExecutionReport, where ExecType (150) = I - OrderStatus, OrdStatus (39) = 8 - Rejected, OrdRejReason (103) and Text (58) will contain the error code and its description.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | H = OrderStatusRequest |
Message Body | |||
790 | OrdStatisReqID | Y | Client specified identifier of the status request. |
11 | ClOrdID | C | ClOrdID (11) of the order that status is being requested. Required if OrderID (37) is not specified. |
37 | OrderID | C | Server specified identifier of the order that status is being requested. Required if ClOrdID (11) is not specified. In the case when both parameters were specified, OrderID has priority over ClOrdID (11). |
453 | NoPartyIDs | C | Number of party identifiers. Will be '1'. |
448 | PartyID | C | Name of a user. Required if ClOrdID (11) was specified. |
447 | PartyIDSource | C | 'D' = Proprietary |
452 | PartyRole | C | Role of the specified PartyID. '3' = Client ID. |
54 | Side | N | Side of the order. |
55 | Symbol | N | Symbol of the order. |
Standard Trailer |
OrderMassStatusRequest
The OrderMassStatusRequest message requests the status for all orders of the client.
A mass status request is assigned a ClOrdID (tag 11) and is treated as a separate entity.
Execution Reports with ExecType (150) = I - Order Status are returned for all orders matching the criteria provided on the request (i.e. for the Client). Such an Execution Report will have the MassStatusReqID (tag 584) field filled in, and the very last one will have the LastRptRequested (912) flag populated.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | AF = OrderMassStatusRequest |
Message Body | |||
584 | MassStatusReqID | Y | Value assigned by issuer of Mass Status Request to uniquely identify the request. |
585 | MassStatusReqType | Y | '8' = StatusForOrdersForAPartyID. All active orders information by user will returned. |
453 | NoPartyIDs | Y | Number of party identifiers. Will be '1'. |
448 | PartyID | Y | Name of a user. |
447 | PartyIDSource | Y | 'D' = Proprietary. |
452 | PartyRole | Y | Role of the specified PartyID. '3' = Client ID. |
Standard Trailer |
RequestForPositions
The value of the PosReqType (tag 724) field will be either 0 = Positions or 101 = Balance (custom, non-standard, does not allow subscription, only snapshot). PositionReport (AP) is sent as a reply to the Balance request type.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | AN = RequestForPositions |
Message Body | |||
710 | PosReqID | Y | Unique identifier for the position maintenance request as assigned by the submitter. |
724 | PosReqType | Y | 0 = Positions 101 = Balance |
263 | SubscriptionRequestType | N | 0 = Snapshot (default) |
1 | Account | Y | An account number. |
453 | NoPartyIDs | Y | Number of party identifiers. Will be '1'. |
448 | PartyID | Y | Name of a user. |
447 | PartyIDSource | Y | 'D' = Proprietary. |
452 | PartyRole | Y | Role of the specified PartyID. '3' = Client ID. |
15 | Currency | C | Required if PosReqType (724) is '101' = Balance. |
55 | Symbol | C | Required if PosReqType (724) is '102' = MarginPositions. |
715 | ClearingBusinessDate | N | The current date. Ignored |
60 | TransactTime | N | Ignored. |
Standard Trailer |
PositionReport
Comes in response to requesting a balance via RequestForPositions. The currency field will contain the currency for which the balance was requested. The Position repeating group will contain 2 elements (NoPosAmt = 2):
PosAmtType = CASH
PosAmtType = CRES
In case of a balance request error, a PositionReport is sent with NoPosAmt = 0.
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | AP = PositionReport |
Message Body | |||
721 | PosMaintRptID | Y | Unique report ID |
710 | PosReqID | Y | Unique identifier for the position maintenance request as assigned by the submitter. Value is taken from the request. |
724 | PosReqType | Y | 0 = Positions |
325 | UnsolicitedIndicator | Y | Always is 'false'. |
728 | PosReqResult | Y | 0 = ValidRequest |
58 | Text | N | Text specifying the reason for the rejection. |
715 | ClearingBusinessDate | Y | The current date. |
1 | Account | Y | Client reference information. |
453 | NoPartyIDs | Y | Number of party identifiers. Will be '1'. |
448 | PartyID | Y | Name of a user. |
447 | PartyIDSource | Y | 'D' = Proprietary |
452 | PartyRole | Y | Role of the specified PartyID. '3' = Client ID |
15 | Currency | C | Currency for which a balance was requested. Required if PosReqType (724) is '101' = Balance. |
55 | Symbol | C | Instrument associated with position, which is the case when PosReqType (724) is '0' = Positions. |
702 | NoPositions | C | Number of position entries (0). |
703 | PosType | Y | Type of quantity being returned. |
704 | LongQty | C | Long quantity. |
705 | ShortQty | C | Short quantity. |
753 | NoPosAmt | Y | Number of position amount entries (0 or 2). |
707 | PosAmtType | Y | Type of position amount.One of two values: |
708 | PosAmt | Y | Position amount |
Standard Trailer |
MarginPositionReport
Tag | Field Name | Req | Description |
Standard Header | |||
35 | MsgType | Y | UMPR = MarginPositionReport |
Message Body | |||
2618 | PositionID | Y | Unique position identifier |
710 | PosReqID | Y | PosReqID from RequestForPositions (AN) |
11 | ClOrdID | C | Unique client-provided identifier for the order led to position update |
10002 | MPExecType | Y | 1 = Created |
453 | NoPartyIDs | Y | 2 elements: User name, Central Counter-party Account |
448 | PartyID | Y | User name (if PartyRole (452) = 3) or central counter-party account (if PartyRole (452) = 4) |
447 | PartyIDSource | Y | D = Proprietary |
452 | PartyRole | Y | 3 = ClientID |
55 | Symbol | Y | Trading symbol |
10003 | MPStatus | Y | 1 = Normal (Default status of a margin position) |
10004 | MarginMode | Y | 1 = Isolated |
10005 | Leverage | Y | Position leverage |
1703 | NoCollateralAmounts | Y | 3 elements: Margin, Required Margin, Orders Margin |
1704 | CurrentCollateralAmount | Y | Current collateral amount |
1705 | CollateralCurrency | Y | Collateral currency |
2632 | CollateralAmountType | Y | 101 = Margin |
14 | CumQty | Y | Position quantity (it will be a negative value for short positions) |
6 | AvgPx | C | Weighted average price of opening trades. None if CumQty (14) = 0 |
10006 | EntryValue | C | Position value. None if CumQty (14) = 0 |
10007 | CloseOnlyPx | C | None if CumQty (14) = 0 |
10008 | LiquidationPx | C | None if CumQty (14) = 0 |
10009 | BankruptcyPx | C | None if CumQty (14) = 0 |
10010 | RealisedPnL | C | Realised profit/loss |
42 | OrigTime | Y | Date/time of position creation with nanosec precision |
779 | LastUpdateTime | Y | Date/time of position update with nanosec precision |
10011 | MPRejectReason | N | Rejection code |
58 | Text | N | Text specifying the reason for the rejection |
Standard Trailer |
Application messages: other
Business Message Reject
A Business Message Reject message is sent when a client message cannot be processed.
Tag | Field Name | Req | Description |
Standard Header |
|
|
|
35 | MsgType | Y | j = Business Message Reject |
Message Body |
|
|
|
379 | BusinessRejectRefID | N | Client specified identifier (e.g. ClOrdID, OrdStatusReqID, etc.) of the rejected message if it is available. |
45 | RefSeqNum | N | MsgSeqNum (34) of the rejected message. |
371 | RefTagID | N | If a message is rejected to due to an issue with a particular field its tag number will be indicated. |
372 | RefMsgType | Y | MsgType (35) of the rejected message. |
380 | BusinessRejectReason | Y | Code specifying the reason for the reject. |
58 | Text | N | Text specifying the reason for the rejection (not including TagID. See RefTagID for this information). |
Standard Trailer |
|
|
|
Hidden Orders
To create a new hidden order. in a (D) New Order - Single set (1138) DisplayQtytag to zero.
Set (40) OrdType tag to one of the following values:
2-limits
4-stop limit
W-take profit limit
(59) TimeinForce tag must be set to one of the following values:
0-Day
1-GTC
6-GTD
Message tags:
Tag | Field name | Desctiption |
|
| The visible part of hidden order quantity (the only valid value is |
DisplayQty (1138) field will be returned in an Execution report accordingly (it never returns for a regular order) if the request was successful.
Exceptions
Error response is returned in the following cases:
DisplayQty (1138)is not0: Reject (Msg type = 3) message with SessionRejectReason = value_is_incorrect (5) and Text = Invalid DisplayQtyInvalid value in the (40)
OrdTypeor (59)TimeinForcetag: Execution report with:ExecType = Rejected (8)
OrdRejReason = UnsupportedOrderCharacteristic (11)