MarksMan FIX API

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	BeginString	Y	string	Marks the beginning of a new message and indicates the FIX version (FIX.4.4). Always the first field in a message.
9	BodyLength	Y	integer	The message length (in bytes) to be forwarded to the CheckSum field. Always the second field in a message.
35	MsgType	Y	string	The message type. Always the third field in a message. See Supported message types for a list of supported values.
34	MsgSeqNum	Y	integer	The message sequence number. This value is incremented by 1 for each consecutive message.
49	SenderCompID	Y	string	The MarksMan-supplied identifier of a client sending requests to the FIX engine.
52	SendingTime	Y	string	The date and time when a message was sent, in UTC time with milliseconds precision.
56	TargetCompID	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	Checksum	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
—	Standard Header	Y	component	MsgType = 1
112	TestReqID	N	string	The identifier of a Test Request in response to which a heartbeat message is to be sent.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = 0
112	TestReqID	N	string	The identifier of a Test Request in response to which a Heartbeat message is sent.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = 2
7	BeginSeqNo	Y	integer	The number of the first message in a sequence that is to be resent.
16	EndSeqNo	Y	integer	The number of the last message in a sequence that is to be resent: if BeginSeqNo = EndSeqNo, a single message in a sequence is resent if EndSeqNo = 0, all messages in a sequence following the one defined in BeginSeqNo are resent
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = 3
45	RefSeqNum	Y	integer	The sequence number of a rejected message (MsgSeqNum).
371	RefTagID	N	integer	The tag number of a field that caused message rejection.
372	RefMsgType	N	integer	The type of a rejected message (MsgType).
373	SessionRejectReason	N	integer	The reason why a message has been rejected. See Reject — Possible reasons for a list of possible values.
58	Text	N	string	The detailed information (if available) on why a message has been rejected.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = j
45	RefSeqNum	N	integer	The sequence number of a rejected message (MsgSeqNum).
372	RefMsgType	Y	integer	The type of a rejected message (MsgType).
380	BusinessRejectReason	Y	integer	The reason why a message has been rejected. See Business Message Reject — Possible reasons for a list of supported values.
58	Text	N	string	The detailed information (if available) on why a message has been rejected.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = A
98	EncryptMethod	Y	integer	The message encryption method. Always 0, indicating that no encryption method is used.
108	HeartBtInt	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 60.
141	ResetSeqNumFlag	Y	boolean	Indicates whether both parties of a FIX session should reset the currently used sequence numbers. This value must always be true.
554	Password	Y	string	The client password (as provided by MarksMan).
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = 5
58	Text	N	string	The detailed information (if available) about the reason for logging out.
—	Standard Trailer	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	simplefix.b2broker.com
Port	10987
SenderCompID	user_demo_q
TargetCompID	fix_demo_q
Password	demo

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	simplefix.b2broker.com
Port	10988
SenderCompID	user_demo_t
TargetCompID	fix_demo_t
Password	demo

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
—	Standard Header	Y	component	MsgType = V
262	MDReqID	Y	string	The identifier of a market data request. This value must be unique for the duration of each session. If SubscriptionRequestType = 2, the MDReqID field indicates the ID of a previous Market Data Request to be discarded.
263	SubscriptionRequestType	Y	integer	The type of response expected from the FIX engine: 1 — subscribe (to receive updates as the market status changes) 2 — unsubscribe (to cancel streaming the market data for the specified ticker symbol)
264	MarketDepth	Y	integer	The market depth for an order book snapshot: a zero value to obtain a full order book a value greater than zero to obtain a specific number of price layers (1 for top-of-the-book prices) The data for all of the price layers is updated for each Market Data — Snapshot/Full Refresh message.
265	MDUpdateType	Y	integer	This value must always be 0, indicating that the all of the order book data should be updated each time, in response to any change in the market data (as opposed to incremental updates related only to price levels that have changed at the time).
146	NoRelatedSym	Y	integer	The number of ticker symbols included in a subscription. This value must always be 1. To subscribe to multiple symbols, the client should send a separate Market Data Request for each symbol.
-> 55	Symbol	Y	string	The ticker symbol to subscribe to (such as BTC/USDT). To subscribe to multiple symbols, send a separate Market Data Request for each symbol.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = Y
262	MDReqID	Y	string	The identifier of a Market Data Request that has been rejected.
281	MDReqRejReason	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	Text	N	string	The detailed information (if available) on why a request has been rejected.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = W
262	MDReqID	Y	string	The identifier of an originating market data request (corresponds to the MDReqID field specified in the Market Data Request message).
55	Symbol	Y	string	The ticker symbol that is being quoted (such as BTC/USDT).
268	NoMDEntries	Y	integer	The number of market data entries (bids or offers) listed in a request.
-> 269	MDEntryType	Y	integer	The side of a quote: 0 — bid 1 — ask
-> 270	MDEntryPx	Y	floating	The price for a market data entry.
-> 271	MDEntrySize	Y	floating	The quantity (tradeable volume) of a market data entry.
—	Standard Trailer	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 to 8).

• If an order is executed partially, a separate report is sent upon each execution (with the OrdStatus field set to 1, indicating that the order is filled partially).

• When an order is filled completely, the report is sent with ExecType set to 2.

• If an order is cancelled (either explicitly by a trader, or automatically due to timeout), the report is sent with ExecType set to 4. In this case, the CumQty field indicates the amount that has already been filled by the time the order was cancelled, and LeavesQty 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 to 4.

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
—	Standard Header	Y	component	MsgType = D
11	ClOrdID	Y	string	The unique order identifier provided by the client. This value must be unique across all previous trading sessions.
55	Symbol	Y	string	The ticker symbol of an instrument that is being traded (such as BTC/USDT).
54	Side	Y	integer	The order side: 1 — buy 2 — sell
38	OrderQty	Y	floating	The order amount.
40	OrdType	Y	integer	The order type: 1 — a market order 2 — a limit order (when choosing this option, the Price field must be specified)
44	Price	C	floating	The order bid or ask price. This field is conditional (depending on the OrdType value): it is not required for market orders, and required for limit orders.
59	TimeInForce	Y	integer	The time-in-force rules applied to an order: 1 — GTC (Good till Cancelled) 3 — IOC (Immediate or Cancel) 4 — FOK (Fill or Kill)
58	Text	N	string	The additional comments about an order.
60	TransactTime	Y	date-time	The date and time when an order has been created, in UTC time with milliseconds precision.
—	Standard Trailer	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 to 4. In this case, the CumQty 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
—	Standard Header	Y	component	MsgType = F
41	OrigClOrdID	Y	string	Identifies the order to be cancelled (by its ClOrdID).
11	ClOrdID	Y	string	The unique identifier assigned to an order cancellation request by the client.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = 9
37	OrderID	Y	string	The unique identifier assigned to an order by the FIX engine. This value is NONE if CxlRejReason = 1.
41	OrigClOrdID	Y	string	Identifies the order (by a unique ClOrdID assigned by the client) that is to be cancelled.
11	ClOrdID	Y	string	The unique identifier of an order cancellation request, as provided by the client.
102	CxlRejReason	Y	integer	The reason why a cancellation request has been rejected: 0 — too late to cancel (the order has already been cancelled or filled) 1 — order unknown (the order with a specified ID has not been found by the FIX engine)
434	CxlRejResponseTo	Y	integer	The type of a request that has been rejected. Always 1, indicating the Order Cancel Request.
60	TransactTime	Y	date-time	The date and time of the last transaction made as part of order processing, in UTC time with milliseconds precision.
—	Standard Trailer	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
—	Standard Header	Y	component	MsgType = 8
11	ClOrdID	Y	string	The unique identifier assigned to an order by the client as part of a New Order Single request.
37	OrderID	Y	string	The unique identifier assigned to an order by a FIX engine.
17	ExecID	Y	string	The unique identifier assigned by a FIX engine to an individual execution. An empty string, if ExecType differs from F.
39	OrdStatus	Y	string	The current order status by the moment of report generation: A — the order is open and awaits execution 1 — the order is open, some part of it may already be filled 2 — the order is filled in the full amount 4 — the order is cancelled, some part of it may already be filled 8 — the order is rejected, no part of it has been filled
150	ExecType	Y	string	The type of a received report: F — the order has been partially or fully filled (the report indicates the complete execution or specifies the portion filled) A — the order has been placed and awaits execution 4 — the order has been cancelled (by that time, some part of it could have already been filled) 8 — the order has been rejected (no part of it has ever been filled)
55	Symbol	Y	string	The ticker symbol of an instrument listed in the original order request, such as BTC/USDT.
54	Side	Y	integer	The order side: 1 — buy 2 — sell
38	OrderQty	Y	floating	The order amount, as indicated in the initial order.
40	OrdType	Y	integer	The order type: 1 — a market order 2 — a limit order
44	Price	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 OrdType field).
59	TimeInForce	Y	integer	The time-in-force rules applied to an order: 1 — GTC (Good till Cancelled) 3 — IOC (Immediate or Cancel) 4 — FOK (Fill or Kill)
31	LastPx	C	floating	For reports signaling a trade execution (ExecType = F), indicates the price at which the most recent portion of an order has been filled.
32	LastQty	C	floating	For reports signaling a trade execution (ExecType = F), indicates the amount in which the most recent portion of an order has been filled.
151	LeavesQty	Y	floating	For reports signaling a trade execution (ExecType = F), indicates the remaining order amount awaiting execution, taking into account the amount filled most recently.
14	CumQty	Y	floating	The total order amount filled so far, including the amount filled most recently (when ExecType = F).
6	AvgPx	Y	floating	The average price calculated based on all order portions filled so far, taking into account the most recent execution (when ExecType = F). This value is zero for orders that are still awaiting execution (ExecType = A).
58	Text	N	string	For cancelled (ExecType = 8) or rejected (ExecType = 4) orders, provides information on why an order has been discarded.
60	TransactTime	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 (ExecType = A).
—	Standard Trailer	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 to Signature

• 9 — an issue related to CompID

• 10 — an accuracy issue related to SendingTime

• 11 — an invalid MsgType

• 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 incorrect NumInGroup count for a repeating group

• 17 — a non-“Data” value includes a field delimiter (an SOH 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 duplicate MDReqID

• 2 — insufficient bandwidth

• 3 — insufficient permissions

• 4 — the specified SubscriptionRequestType is not supported

• 5 — the specified MarketDepth is not supported

• 6 — the specified MDUpdateType is not supported

• 7 — the specified AggregatedBook is not supported

• 8 — the specified MDEntryType is not supported

• 9 — the specified TradingSessionID is not supported

• A — the specified Scope is not supported

• B — the specified OpenCloseSettlFlag is not supported

• C — the specified MDImplicitDelete 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

• 9 — Order Cancel Reject

• A — Logon

• D — New Order Single

• F — Order Cancel Request

• V — Market Data Request

• W — Market Data — Snapshot/Full Refresh

• Y — Market Data Request Reject

• j — Business Message Reject