MarksMan FIX API

General information

The MarksMan FIX server 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 about how to connect to a demo FIX server.

Note

The MarksMan FIX API is based on the version 4.4 of the Financial Information eXchange protocol.

It’s assumed that the reader of this document is already familiar with the FIX 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.

Supported message types

The following message types can be assigned to the <35> MsgType field of a Standard header:

Standard header

All FIX messages must start with a Standard header.

The Standard header includes the following fields:

Tag

Name

Required

Datatype

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

int

The message length, in bytes.

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

int

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 server.

52

SendingTime

Y

Timestamp

The date and time when a message was sent, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss.

56

TargetCompID

Y

String

The MarksMan-supplied identifier of a server receiving client messages.

Standard trailer

Along with a Standard Header, all FIX messages must also contain a Standard trailer.

The Standard trailer includes the following fields:

Tag

Name

Required

Datatype

Description

10

CheckSum

Y

int

A three-digit simple checksum indicating the end of a message.

Always the last field in a message.

Session messages

The messages listed in this section are used to maintain any live FIX session with the MarksMan FIX server, including both quoting and trading sessions.

Heartbeat

This message is sent back and forth between the FIX server and the client to check the connection status and in response to Test Request messages.

The Heartbeat message includes the following fields:

Tag

Name

Required

Datatype

Description

Standard header

Y

<35> MsgType = 0

112

TestReqID

N

String

The identifier of a Test Request in response to which this Heartbeat message is sent.

Standard trailer

Y

Test Request

This message is sent back and forth between the FIX server and the client in response to Heartbeat messages as a means of connectivity check.

The Test Request message includes the following fields:

Tag

Name

Required

Datatype

Description

Standard header

Y

<35> MsgType = 1

112

TestReqID

N

String

The identifier of this Test Request in response to which a Heartbeat message will be sent.

Standard trailer

Y

Resend Request

This message is sent by the client or FIX server to initiate the retransmission of messages, which may be required upon detecting a gap in the sequence numbers or losing a particular message.

The Resend Request message includes the following fields:

Tag

Name

Required

Datatype

Description

Standard header

Y

<35> MsgType = 2

7

BeginSeqNo

Y

int

The number of the first message in a sequence to resend.

16

EndSeqNo

Y

int

The number of the last message in a sequence to resend:

  • if <7> BeginSeqNo = <16> EndSeqNo, a single message in a sequence is resent

  • if <16> EndSeqNo = 0, all messages in a sequence following the one defined in <7> BeginSeqNo are resent

Standard trailer

Y

Reject

This message is sent by the FIX server upon receiving a malformed message from the client. The possible reason for rejection is specified in the <373> SessionRejectReason field.

Note

This message is unrelated to a trade-level rejection (Order Cancel Reject) issued when a FIX server is unable to place a requested order.

The Reject message includes the following fields:

Tag

Name

Required

Datatype

Description

Standard header

Y

<35> MsgType = 3

45

RefSeqNum

Y

int

The sequence number of a rejected message (<34> MsgSeqNum).

371

RefTagID

N

int

The tag number of a field that caused message rejection.

372

RefMsgType

N

int

The type of a rejected message (<35> MsgType).

373

SessionRejectReason

N

int

The reason why a message is rejected.

See Possible reasons for a list of possible values.

58

Text

N

String

The detailed information about the rejection reason.

Standard trailer

Y

Possible reasons

When the FIX server sends a Reject notification informing the client that a session-level request has been rejected, the <373> 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 isn’t 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

  • 9 — an issue related to CompID

  • 10 — an accuracy issue related to <52> SendingTime

  • 11 — an invalid <35> 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

  • 17 — a non-“Data” value includes a field delimiter (an SOH character)

  • 99 — other (unspecified) reason

Sequence Reset

This message is sent by the client or FIX server to indicate to the recipient the sequence number of the next message from the sender, immediately following the Sequence Reset message. This may be necessary to recover from a disconnect, in case if some messages were lost or their resending is not desirable.

The Sequence Reset message includes the following fields:

Tag

Name

Required

Datatype

Description

Standard header

Y

<35> MsgType = 4

123

GapFillFlag

N

Boolean

Indicates that this message replaces missing messages that won’t be resent:

  • Y — gap fill, <34> MsgSeqNum is valid and indicates the beginning of the gap fill range

  • N — sequence reset, <34> MsgSeqNum is ignored. As it may lead to losing messages, this mode should only be used in case of a disaster recovery situation.

36

NewSeqNo

Y

int

The new sequence number.

Standard trailer

Y

Logon

This message is sent by the client to initiate a FIX session.

The Logon message includes the following fields:

Tag

Name

Required

Datatype

Description

Standard header

Y

<35> MsgType = A

98

EncryptMethod

Y

int

The message encryption method. This value must always be 0, indicating that no encryption method is used.

108

HeartBtInt

Y

int

The heartbeat interval, in seconds. Indicates how often the FIX server sends messages to the client as part of a 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. It’s recommended to set the flag to Y for Quoting sessions.

553

Username

N

String

The client username. It should be specified if provided as part of the FIX credentials.

554

Password

Y

String

The client password, as provided by MarksMan.

Standard trailer

Y

Logout

This message is sent by the client or FIX server to terminate a session. When terminated, the possible reason is specified in the <58> Text field.

The Logout message includes the following fields:

Tag

Name

Required

Datatype

Description

Standard header

Y

<35> MsgType = 5

58

Text

N

String

The detailed information about the reason for logging out.

Standard trailer

Y

Demo mode

The MarksMan FIX server supports a Demo mode that allows clients to establish a test connection and simulate quoting and trading sessions. Contact your account manager to obtain a set of settings and credentials.

Quoting

After connecting to the FIX server and establishing a live quoting session, the client can send a Market Data Request to subscribe to quote updates streamed by MarksMan.

Note

To subscribe to multiple symbols, the client should send a separate Market Data Request for each symbol.

Upon successful subscription to a selected symbol, the FIX server 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.

If a subscription request can’t be executed for some reason (for example, when a requested symbol isn’t found), the FIX server responds with a Market Data Request Reject message providing detailed information about an error.

To terminate a specific subscription and stop receiving the updates, the client can send a Market Data Request with the <263> 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

This message is sent by the client to start receiving up-to-date quoting data for a specified ticker symbol.

The Market Data Request message includes the following fields:

Tag

Name

Required

Value Type

Description

Standard header

Y

<35> 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 <263> SubscriptionRequestType is set to 2, the <262> MDReqID field indicates the ID of a previous Market Data Request to be discarded.

263

SubscriptionRequestType

Y

int

The type of response expected from the FIX server:

  • 1 — subscribe (to receive updates as the market status changes)

  • 2 — unsubscribe (to stop streaming the market data for the specified ticker symbol)

264

MarketDepth

Y

int

The market depth for an order book snapshot:

  • 0 — to obtain a full order book

  • 1 — to obtain top-of-the-book prices

  • other value greater than zero — to obtain a specific number of price layers

265

MDUpdateType

Y

int

This value must always be 0, indicating that all order book data should be updated every 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).

267

NoMDEntryTypes

Y

int

The number of <269> MDEntryTypes requested. This value must always be 2.

→ 269

MDEntryType

Y

int

The side of a quote:

  • 0 — bid

  • 1 — ask

146

NoRelatedSym

Y

int

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

Instrument

Y

String

The ticker symbol to subscribe to (such as BTC/USDT).

Standard trailer

Y

Market Data Request Reject

This message is sent by the FIX server to reject a Market Data Request with invalid values.

The Market Data Request Reject message includes the following fields:

Tag

Name

Required

Value Type

Description

Standard header

Y

<35> MsgType = Y

262

MDReqID

Y

String

The identifier of a rejected Market Data Request.

281

MDReqRejReason

N

int

The reason why a request is rejected.

See Possible reasons for a list of supported values.

58

Text

N

String

The detailed information about the rejection reason.

Standard trailer

Y

Possible reasons

The <281> MDReqRejReason field can be set to one of the following values specifying the reason for request rejection:

  • 0 — the specified symbol isn’t recognized

  • 1 — a duplicate <262> MDReqID

  • 2 — insufficient bandwidth

  • 3 — insufficient permissions

  • 4 — the specified <263> SubscriptionRequestType isn’t supported

  • 5 — the specified <264> MarketDepth isn’t supported

  • 6 — the specified <265> MDUpdateType isn’t supported

  • 8 — the specified <269> MDEntryType isn’t supported

Market Data — Snapshot/Full Refresh

Such messages are continuously sent by the FIX server after the client subscribes to a ticker symbol. A new message is sent with each market data update.

The Market Data — Snapshot/Full Refresh message includes the following fields:

Tag

Name

Required

Value Type

Description

Standard header

Y

<35> MsgType = W

262

MDReqID

Y

String

The identifier of an originating Market Data Request.

55

Instrument

Y

String

The ticker symbol that’s being quoted (such as BTC/USDT).

268

NoMDEntries

Y

int

The number of market data entries (bids or asks) listed in a request.

→ 269

MDEntryType

Y

int

The side of a quote:

  • 0 — bid

  • 1 — ask

→ 270

MDEntryPx

Y

Price

The price for a market data entry.

→ 271

MDEntrySize

Y

Qty

The tradable volume of a market data entry.

→ 299

QuoteEntryID

N

String

The unique identifier of a quote.

Standard trailer

Y

Trading

Place an order

After establishing a trading session with the FIX server, the client can place a new order by sending a New Order Single message. In response to this, the FIX server sends back an Execution Report with the <150> ExecType field set to A, indicating that the order is placed successfully.

If the order can’t be placed (for example, due to lack of credit funds or other issues), the report is sent with <150> ExecType set to 8.

After placing the order, the FIX server sends a separate report with <150> ExecType set to F each the order status changes:

  • If the order is executed partially, <39> OrdStatus is set to 1.

  • When the order is fully filled, <39> OrdStatus is set to 2.

Cancel an order

To cancel an open order, the client can send an Order Cancel Request.

If the order is canceled (either explicitly by a trader, or automatically due to timeout), the Execution Report is sent with <150> ExecType set to 4. In this case, the <14> CumQty field indicates the amount that has already been filled by the time the order was canceled, and <151> LeavesQty indicates the unfilled amount.

If an order can’t be canceled for any reason, the FIX server sends back an Order Cancel Reject message indicating why the order cancellation failed.

New Order Single

This message is sent by the client to place a new order with specified parameters.

The New Order Single message includes the following fields:

Tag

Name

Required

Value Type

Description

Standard header

Y

<35> MsgType = D

1

Account

N

String

The client-defined account name.

11

ClOrdID

Y

String

The client-provided identifier of an order. This value must be unique across all previous trading sessions.

55

Instrument

Y

String

The ticker symbol (such as BTC/USDT).

54

Side

Y

int

The order side:

  • 1 — buy

  • 2 — sell

38

OrderQty

Y

Qty

The order amount.

40

OrdType

Y

Char

The order type:

  • 1 — market

  • 2 — limit (when choosing this option, the <44> Price field must be specified)

44

Price

C

Price

The order price.

This field is required for limit orders.

58

Text

N

String

The additional comments about an order.

59

TimeInForce

Y

Char

The time-in-force option applied to an order:

  • 1 — GTC (Good till Canceled)

  • 3 — IOC (Immediate or Cancel)

  • 4 — FOK (Fill or Kill)

60

TransactTime

Y

Timestamp

The date and time when an order was created, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss.

21

HandlInst

Y

int

This field is ignored. Execution is always treated as if the supplied value was 1 (Automated execution order, private, no Broker intervention).

Standard trailer

Y

Order Cancel Request

This message is sent by the client to cancel an open order in its entire remaining amount. This request is assigned a unique <11> ClOrdID and is treated as a separate order.

Upon successful cancellation of the order, an Execution Report is sent with the <39> OrdStatus field set to 4. In this case, the <14> CumQty field indicates the amount that has already been filled by the time the order was canceled.

If the order can’t be canceled for some reason, the FIX server sends back an Order Cancel Reject message indicating why the order cancellation failed.

The Order Cancel Request message includes the following fields:

Tag

Name

Required

Value Type

Description

Standard header

Y

<35> MsgType = F

41

OrigClOrdID

Y

String

The <11> ClOrdID of an order to be canceled.

11

ClOrdID

Y

String

The client-provided unique identifier of the Order Cancel Request.

Standard trailer

Y

Order Cancel Reject

This message is sent by the FIX server upon receiving an Order Cancel Request that can’t be fulfilled.

The Order Cancel Reject message includes the following fields:

Tag

Name

Required

Value Type

Description

Standard header

Y

<35> MsgType = 9

37

OrderID

Y

String

The unique identifier assigned to an order by the FIX server.

This value is NONE if <102> CxlRejReason = 1.

41

OrigClOrdID

Y

String

The <11> ClOrdID of an order to be canceled.

11

ClOrdID

Y

String

The client-provided unique identifier of the Order Cancel Request.

39

OrdStatus

Y

Char

The current order status by the moment of message 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 canceled, some part of it may already be filled

  • 8 — the order is rejected, no part of it is filled

102

CxlRejReason

Y

int

The reason why a cancellation request is rejected:

  • 0 — too late to cancel (the order has already been canceled or filled)

  • 1 — order unknown (the order with a specified ID wasn’t found by the FIX server)

434

CxlRejResponseTo

Y

int

The type of a request that’s rejected. This value must always be 1, indicating the Order Cancel Request.

60

TransactTime

Y

Timestamp

The date and time of the last transaction made as part of order processing, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss.

Standard trailer

Y

Execution Report

This message is sent by the FIX server upon successfully placing or cancelling an order, or any change to the order status (such as a complete or partial execution). Among other data, the report indicates:

  • the current order status at the moment of report creation (<39> OrdStatus)

  • the most recent change in the order status, which is being reported (<150> ExecType)

The Execution Report message includes the following fields:

Tag

Name

Required

Value Type

Description

Standard header

Y

<35> 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 the FIX server.

17

ExecID

Y

String

The unique identifier assigned by the FIX server to an individual execution.

An empty string, if <150> ExecType differs from F (Fill).

39

OrdStatus

Y

String

The current order status by the moment of message 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 canceled, some part of it may already be filled

  • 8 — the order is rejected, no part of it is filled

150

ExecType

Y

String

The type of a received report:

  • F — the order is partially or fully filled (the report indicates the complete execution or specifies the part filled)

  • A — the order is placed and awaits execution

  • 4 — the order is canceled, some part of it may already be filled

  • 8 — the order has been rejected, no part of it is filled

55

Instrument

Y

String

The ticker symbol of an instrument listed in the original order request, such as BTC/USDT.

54

Side

Y

int

The order side:

  • 1 — buy

  • 2 — sell

38

OrderQtyData

Y

Qty

The order amount, as indicated in the initial order.

40

OrdType

Y

int

The order type:

  • 1 — a market order

  • 2 — a limit order

44

Price

N

Price

The order bid or ask price.

This field is included in the execution report for limit orders only.

59

TimeInForce

Y

Char

The time-in-force option applied to an order:

  • 1 — GTC (Good till Canceled)

  • 3 — IOC (Immediate or Cancel)

  • 4 — FOK (Fill or Kill)

31

LastPx

N

Price

For reports signaling a trade execution (<150> ExecType = F), indicates the price of the last fill.

32

LastQty

N

Qty

For reports signaling a trade execution (<150> ExecType = F), indicates the amount of the last fill.

151

LeavesQty

Y

Qty

For reports signaling a trade execution (E<150> xecType = F), indicates the remaining order amount awaiting execution, taking into account the amount filled most recently.

14

CumQty

Y

Qty

The total order amount filled so far, including the amount filled most recently.

6

AvgPx

Y

Price

The average price calculated based on all order parts filled so far, taking into account the most recent execution.

This value is 0 for orders that are still awaiting execution (<150> ExecType = A).

64

SettlDate

N

Date

For reports signaling a trade execution (<150> ExecType = F), indicates the UTC date of a trade settlement, in the YYYYMMDD format.

75

TradeDate

N

Date

For reports signaling a trade execution (<150> ExecType = F), indicates the UTC date of a fill, in the YYYYMMDD format.

103

OrdRejReason

N

int

For reports signaling an order rejection (<150> ExecType = F), indicates the rejection reason.

58

Text

N

String

For canceled (<150> ExecType = 8) or rejected (<150> ExecType = 4) orders, provides the reason why an order is discarded.

60

TransactTime

C

Timestamp

The date and time of the most recent change in the order status, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss.

This field is omitted for orders that are still awaiting execution (<150> ExecType = A).

Standard trailer

Y