MarksMan FIX API¶
General information¶
The MarksMan FIX engine provides all the functionality necessary for real-time trading and receiving up-to-date market information via the Financial Information eXchange protocol.
In this document, you can find a detailed description of the MarksMan FIX API, including the information on how to connect to a demo FIX engine.
Note
The MarksMan FIX API is based on the version 4.4 of the Financial Information eXchange protocol.
To learn more about the protocol specification, see the FIX Trading Community website.
If your trading engine is powered by Go, take a minute to learn about SimpleFix Go — this open-source library is provided by the MarksMan team to help you quickly integrate FIX messaging into your environment. The library is entirely written in Go and supports any FIX API version.
Messaging¶
The messages listed in this section are used to maintain any live FIX session with the MarksMan FIX engine, including both quoting and trading sessions.
Standard Header¶
All FIX messages sent or received by the FIX engine include a Standard Header.
The Standard Header includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
8 |
|
Y |
string |
Marks the beginning of a new message and indicates the FIX version ( Always the first field in a message. |
9 |
|
Y |
integer |
The message length (in bytes) to be forwarded to the Always the second field in a message. |
35 |
|
Y |
string |
The message type. Always the third field in a message. See Supported message types for a list of supported values. |
34 |
|
Y |
integer |
The message sequence number. This value is incremented by 1 for each consecutive message. |
49 |
|
Y |
string |
The MarksMan-supplied identifier of a client sending requests to the FIX engine. |
52 |
|
Y |
string |
The date and time when a message was sent, in UTC time with milliseconds precision. |
56 |
|
Y |
string |
The MarksMan-supplied identifier of a server receiving client messages. |
Standard Trailer¶
All FIX messages sent or received by the FIX engine include a Standard Trailer.
The Standard Trailer includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
10 |
|
Y |
integer |
A three-digit simple checksum indicating the end of a message. Always the last field in a message. |
Test Request¶
A Test Request is sent to the client by the FIX engine, or back to it by the client, to receive a Heartbeat message and ensure that the connection is alive.
The Test Request message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
112 |
|
N |
string |
The identifier of a Test Request in response to which a heartbeat message is to be sent. |
|
Y |
component |
|
Heartbeat¶
In response to a Test Request, a Heartbeat message is sent to the client by the FIX engine, or back to it by the client, to ensure that the connection is alive.
The Heartbeat message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
112 |
|
N |
string |
The identifier of a Test Request in response to which a Heartbeat message is sent. |
|
Y |
component |
|
Resend Request¶
A Resend Request is sent by the client to initiate retransmission of messages, which can be done upon detecting a gap in a sequence number or losing a particular message.
The Resend Request message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
7 |
|
Y |
integer |
The number of the first message in a sequence that is to be resent. |
16 |
|
Y |
integer |
The number of the last message in a sequence that is to be resent:
|
|
Y |
component |
|
Reject¶
A Reject message is sent by the FIX engine upon receiving an improperly constructed message from the client. The reason for message rejection is specified when possible (in the SessionRejectReason
field).
Note
This message is unrelated to a trade-level rejection (Order Cancel Reject) issued when a FIX engine is unable to place a requested order.
The Reject message is similar to Business Message Reject in that both of them are used to keep track of rejections resulting from errors related to parsing incorrect FIX messages.
The Reject message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
45 |
|
Y |
integer |
The sequence number of a rejected message ( |
371 |
|
N |
integer |
The tag number of a field that caused message rejection. |
372 |
|
N |
integer |
The type of a rejected message ( |
373 |
|
N |
integer |
The reason why a message has been rejected. See Reject — Possible reasons for a list of possible values. |
58 |
|
N |
string |
The detailed information (if available) on why a message has been rejected. |
|
Y |
component |
|
Business Message Reject¶
A Business Message Reject message is sent by the FIX engine if a message received from the client contains any invalid values. The reason for message rejection is specified when possible (in the BusinessRejectReason
and Text
fields).
Note
This message is unrelated to a trade-level rejection (Order Cancel Reject) issued when a FIX engine is unable to place a requested order.
The Business Message Reject is similar to the Reject message in that both of them are used to keep track of rejections resulting from errors related to parsing incorrect FIX messages.
The Business Message Reject message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
45 |
|
N |
integer |
The sequence number of a rejected message ( |
372 |
|
Y |
integer |
The type of a rejected message ( |
380 |
|
Y |
integer |
The reason why a message has been rejected. See Business Message Reject — Possible reasons for a list of supported values. |
58 |
|
N |
string |
The detailed information (if available) on why a message has been rejected. |
|
Y |
component |
|
Logon¶
A Logon message is sent by the client to initiate a FIX session. The session is authenticated by sending a valid Password
provided by MarksMan.
The Logon message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
98 |
|
Y |
integer |
The message encryption method. Always |
108 |
|
Y |
integer |
The heartbeat interval (in seconds) indicating how often the FIX engine will send messages to the client as part of connection health check. The maximum value is |
141 |
|
Y |
boolean |
Indicates whether both parties of a FIX session should reset the currently used sequence numbers. This value must always be |
554 |
|
Y |
string |
The client password (as provided by MarksMan). |
|
Y |
component |
|
Logout¶
A Logout message is sent to the client by the FIX engine, or back to it by the client, to terminate a FIX session. If a session is terminated by the FIX engine, the reason for this is specified when possible (in the Text
field).
The Logout message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
58 |
|
N |
string |
The detailed information (if available) about the reason for logging out. |
|
Y |
component |
|
Session¶
To maintain quoting and trading sessions, separate connections must be established, each using different credentials. Each set of credentials can only be used to establish a single session at a time
Demo mode¶
A special Demo mode is provided so that clients can establish a test connection with the MarksMan FIX engine.
Demo quoting session
To start receiving demo quoting data, connect to the FIX engine using the following settings and credentials:
Parameter |
Value |
---|---|
Host |
|
Port |
|
|
|
|
|
Password |
|
Demo trading session
Use another set of credentials and settings to start a simulated trading session and place orders on the demo platform:
Parameter |
Value |
---|---|
Host |
|
Port |
|
|
|
|
|
Password |
|
Quoting¶
After connecting to a FIX engine and establishing a live quoting session, the client can send a Market Data Request and subscribe to quote updates streamed by MarksMan and providing up-to-date quoting data related to a specified ticker symbol.
Note
To subscribe to multiple symbols, the client should send a separate Market Data Request for each symbol.
If a subscription request cannot be executed for some reason (for example, when a requested symbol is not found), the FIX engine responds with a Market Data Request Reject message providing detailed information about an error.
Upon successful subscription to a selected symbol, the FIX engine starts streaming market data updates by sending Market Data — Snapshot/Full Refresh messages each time the market data is updated. The quote updates are streamed continuously for the entire duration of a FIX session.
To terminate a specific subscription and stop receiving the corresponding updates, the client can send a Market Data Request with the SubscriptionRequestType
set to 2
(standing for Unsubscribe
). Upon sending a Logout request, the current session is closed and subscriptions to all ticker symbols are terminated.
Market Data Request¶
A client can send a Market Data Request to the FIX engine to start receiving up-to-date quoting data related to a specified ticker symbol. This message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
262 |
|
Y |
string |
The identifier of a market data request. This value must be unique for the duration of each session. If |
263 |
|
Y |
integer |
The type of response expected from the FIX engine:
|
264 |
|
Y |
integer |
The market depth for an order book snapshot:
The data for all of the price layers is updated for each Market Data — Snapshot/Full Refresh message. |
265 |
|
Y |
integer |
This value must always be |
146 |
|
Y |
integer |
The number of ticker symbols included in a subscription. This value must always be To subscribe to multiple symbols, the client should send a separate Market Data Request for each symbol. |
-> 55 |
|
Y |
string |
The ticker symbol to subscribe to (such as To subscribe to multiple symbols, send a separate Market Data Request for each symbol. |
|
Y |
component |
|
Market Data Request Reject¶
A Market Data Request Reject message is sent by a FIX engine upon receiving a Market Data Request that contains any invalid values. This message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
262 |
|
Y |
string |
The identifier of a Market Data Request that has been rejected. |
281 |
|
N |
integer |
Indicates the reason why a request has been rejected. See Market Data Request Reject — Possible reasons for a list of supported values. |
58 |
|
N |
string |
The detailed information (if available) on why a request has been rejected. |
|
Y |
component |
|
Market Data — Snapshot/Full Refresh¶
Market Data — Snapshot/Full Refresh messages are continuously sent by the FIX engine after the client subscribes to a certain ticker symbol. A new message is sent each time the market data is updated, providing up-to-date information related to a corresponding symbol.
The Market Data — Snapshot/Full Refresh message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
262 |
|
Y |
string |
The identifier of an originating market data request (corresponds to the |
55 |
|
Y |
string |
The ticker symbol that is being quoted (such as |
268 |
|
Y |
integer |
The number of market data entries (bids or offers) listed in a request. |
-> 269 |
|
Y |
integer |
The side of a quote:
|
-> 270 |
|
Y |
floating |
The price for a market data entry. |
-> 271 |
|
Y |
floating |
The quantity (tradeable volume) of a market data entry. |
|
Y |
component |
|
Trading¶
After establishing a trading session via the FIX engine, the client can place a new order by sending a New Order Single message. In response to this, the FIX engine will immediately send back an Execution Report with the ExecType
field set to A
, indicating that the order has been placed and is awaiting execution. Other changes to an order status are indicated in the report as follows:
If an order cannot be placed (for example, due to lack of credit funds or other issues), it is rejected (
ExecType
is set to8
).If an order is executed partially, a separate report is sent upon each execution (with the
OrdStatus
field set to1
, indicating that the order is filled partially).When an order is filled completely, the report is sent with
ExecType
set to2
.If an order is cancelled (either explicitly by a trader, or automatically due to timeout), the report is sent with
ExecType
set to4
. In this case, theCumQty
field indicates the amount that has already been filled by the time the order was cancelled, andLeavesQty
indicates the unfilled amount.
To cancel an open order, the client can send an Order Cancel Request. The message that is sent back by the FIX engine depends on whether the cancellation has been successful:
If an order cannot be cancelled for any reason, the FIX engine sends back an Order Cancel Reject message indicating why the order cancellation has failed.
Upon successful cancellation of an order, an Execution Report is sent with the
OrdStatus
field set to4
.
New Order Single¶
A New Order Single message is sent by the client to place a new order with specified parameters. This message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
11 |
|
Y |
string |
The unique order identifier provided by the client. This value must be unique across all previous trading sessions. |
55 |
|
Y |
string |
The ticker symbol of an instrument that is being traded (such as |
54 |
|
Y |
integer |
The order side:
|
38 |
|
Y |
floating |
The order amount. |
40 |
|
Y |
integer |
The order type:
|
44 |
|
C |
floating |
The order bid or ask price. This field is conditional (depending on the |
59 |
|
Y |
integer |
The time-in-force rules applied to an order:
|
58 |
|
N |
string |
The additional comments about an order. |
60 |
|
Y |
date-time |
The date and time when an order has been created, in UTC time with milliseconds precision. |
|
Y |
component |
|
Order Cancel Request¶
An Order Cancel Request message requests cancellation of all of the remaining amount of an open order. This request is assigned a unique ClOrdID
and is treated as a separate entity.
If such request is rejected, an Order Cancel Reject message is sent back to the client, indicating the ClOrdID
of the Order Cancel Request along with the ClOrdID
of the actual order, as defined in OrigClOrdID
.
The ClOrdID
value assigned to the Order Cancel Request must be unique amongst the ClOrdID
values assigned to orders.
Depending on whether the cancellation has been successful, one of the following messages is sent back to the client:
If an order cannot be cancelled for some reason, the FIX engine sends back an Order Cancel Reject message indicating why the order cancellation has failed.
Upon successful cancellation of an order, an Execution Report is sent with the
OrdStatus
field set to4
. In this case, theCumQty
field indicates the amount that has already been filled by the time the order was cancelled.
The Order Cancel Request message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
41 |
|
Y |
string |
Identifies the order to be cancelled (by its |
11 |
|
Y |
string |
The unique identifier assigned to an order cancellation request by the client. |
|
Y |
component |
|
Order Cancel Reject¶
An Order Cancel Reject message is sent by the FIX engine upon receiving an Order Cancel Request that cannot be fulfilled. This message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
37 |
|
Y |
string |
The unique identifier assigned to an order by the FIX engine. This value is |
41 |
|
Y |
string |
Identifies the order (by a unique |
11 |
|
Y |
string |
The unique identifier of an order cancellation request, as provided by the client. |
102 |
|
Y |
integer |
The reason why a cancellation request has been rejected:
|
434 |
|
Y |
integer |
The type of a request that has been rejected. Always |
60 |
|
Y |
date-time |
The date and time of the last transaction made as part of order processing, in UTC time with milliseconds precision. |
|
Y |
component |
|
Execution Report¶
An Execution Report is sent to the client by the FIX engine upon successfully placing or cancelling an order, or any change to the order status (such as a complete or partial execution). In particular, the report indicates:
the current order status at the moment of report creation (
OrdStatus
)the most recent change in the order status, which is being reported (
ExecType
)
The Execution Report message includes the following fields:
Tag |
Name |
Req-d? |
Value Type |
Description |
---|---|---|---|---|
|
Y |
component |
|
|
11 |
|
Y |
string |
The unique identifier assigned to an order by the client as part of a New Order Single request. |
37 |
|
Y |
string |
The unique identifier assigned to an order by a FIX engine. |
17 |
|
Y |
string |
The unique identifier assigned by a FIX engine to an individual execution. An empty string, if |
39 |
|
Y |
string |
The current order status by the moment of report generation:
|
150 |
|
Y |
string |
The type of a received report:
|
55 |
|
Y |
string |
The ticker symbol of an instrument listed in the original order request, such as |
54 |
|
Y |
integer |
The order side:
|
38 |
|
Y |
floating |
The order amount, as indicated in the initial order. |
40 |
|
Y |
integer |
The order type:
|
44 |
|
C |
floating |
The order bid or ask price. This field is included in the execution report only for limit orders, and may not be included for market orders (as indicated in the |
59 |
|
Y |
integer |
The time-in-force rules applied to an order:
|
31 |
|
C |
floating |
For reports signaling a trade execution ( |
32 |
|
C |
floating |
For reports signaling a trade execution ( |
151 |
|
Y |
floating |
For reports signaling a trade execution ( |
14 |
|
Y |
floating |
The total order amount filled so far, including the amount filled most recently (when |
6 |
|
Y |
floating |
The average price calculated based on all order portions filled so far, taking into account the most recent execution (when This value is zero for orders that are still awaiting execution ( |
58 |
|
N |
string |
For cancelled ( |
60 |
|
C |
date-time |
The date and time of the most recent change in the order status, in UTC time with milliseconds precision. This field is omitted if a report is sent on behalf of an order that still awaits execution ( |
|
Y |
component |
|
Order Execution Flow¶
In this section, you can learn about the Execution Report fields indicating the current order status.
An order has been successfully executed in full or in part¶
The following table illustrates which of the Execution Report fields indicate successful execution of an order:
OrdStatus |
ExecType |
Description |
---|---|---|
A |
A |
A New Order Single request has been received, the order is open and awaits execution. |
1 |
F |
Some (but not all) portions of an order have been filled. |
2 |
F |
An order has been filled in the full amount. |
An order has been rejected¶
The following table illustrates which of the Execution Report fields indicate that an order has been rejected:
OrdStatus |
ExecType |
Description |
---|---|---|
A |
A |
A New Order Single request has been received, the order is open and awaits execution. |
8 |
8 |
An order has been rejected, no portions of it have been filled. |
An order has been cancelled¶
The following table illustrates which of the Execution Report fields indicate that an order has been cancelled:
OrdStatus |
ExecType |
Description |
---|---|---|
A |
A |
A New Order Single request has been received, the order is open and awaits execution. |
1 |
F |
Some (but not all) portions of an order have been filled. |
4 |
4 |
An order has been cancelled, some portions of it could have been filled by that time. |
Message rejection reasons¶
In this document section, you can find information about possible reasons for rejection of a session- or business-level message.
Reject — Possible reasons¶
When the FIX engine sends a Reject notification informing the client that a session-level request has been rejected, the SessionRejectReason
field can be set to one of the following values specifying the reason for message rejection:
0
— an invalid tag number
1
— a required tag is missing
2
— a tag is not defined for this message type
3
— a tag is undefined
4
— a tag has no value assigned
5
— an assigned value is incorrect (out of range) for this tag
6
— an incorrect value data format
7
— an issue related to decryption
8
— an issue related toSignature
9
— an issue related toCompID
10
— an accuracy issue related toSendingTime
11
— an invalidMsgType
12
— an XML validation error
13
— the same tag appears more than once
14
— a tag is specified not in the required order
15
— a wrong order of repeating group fields
16
— an incorrectNumInGroup
count for a repeating group
17
— a non-“Data” value includes a field delimiter (anSOH
character)
99
— other (unspecified) reason
Business Message Reject — Possible reasons¶
When the FIX engine sends a Business Message Reject notification informing the client that a business-level request has been rejected, the BusinessRejectReason
field can be set to one of the following values specifying the reason for message rejection:
0
— other (unspecified) reason
1
— the specified ID is not found
2
— the specified instrument is not recognized
3
— the specified message type is not supported
4
— the application is not available
5
— a conditionally required field is missing
6
— the request is not authorized
7
— the service processing client requests is not available at the time
Market Data Request Reject — Possible reasons¶
When the FIX engine sends a Market Data Request Reject notification informing the client that a market data request has been rejected, the MDReqRejReason
field can be set to one of the following values specifying the reason for request rejection:
0
— the specified symbol is not recognized
1
— a duplicateMDReqID
2
— insufficient bandwidth
3
— insufficient permissions
4
— the specifiedSubscriptionRequestType
is not supported
5
— the specifiedMarketDepth
is not supported
6
— the specifiedMDUpdateType
is not supported
7
— the specifiedAggregatedBook
is not supported
8
— the specifiedMDEntryType
is not supported
9
— the specifiedTradingSessionID
is not supported
A
— the specifiedScope
is not supported
B
— the specifiedOpenCloseSettlFlag
is not supported
C
— the specifiedMDImplicitDelete
is not supported
Supported message types¶
The following message types can be assigned to the MsgType
field of a Standard Header:
0
— Heartbeat
1
— Test Request
2
— Resend Request
3
— Reject
5
— Logout
8
— Execution Report
A
— Logon
D
— New Order Single