MidChains FIX API

Introduction

The information in this MidChains FIX document describes the adaptation of the standard FIX 4.2 for vendors and subscribers to communicate with the MidChains quotation and execution platform. FIX 4.2 tags, as described in detail on the Financial Information Exchange Protocol Committee website, www.fixprotocol.org as well as custom tags are used extensively in this document and the reader should familiarize themselves with the latest updates to this release. If an application message in Financial Information Exchange Protocol version 4.2, or previous FIX versions, is not included in this document, the message is ignored.

Connectivity

To connect to MidChains over the FIX API clients must establish a secure connection to the FIX gateway. The connectivity details such as the IP Address and Port Number will be assigned by the MidChains trade support team. To request these details, clients can contact support@midchains.com or raise a request via the support portal through the www.midchains.com website.

Messages

This section outlines the FIX messages, how they are supported, and to what extent the business data is translated within the FIX Gateway.
More details available in the FIX API Documentation

Message Header

Tag

Field Name

Required

Note

8

BeginString

Yes

"FIX.4.2"

9

BodyLength

Yes

​

35

MsgType

Yes

​

49

SenderCompID

Yes

Provided by MidChains

56

TargetCompID

Yes

Provided by MidChains

34

MsgSeqNum

Yes

​

52

SendingTime

Yes

​

Message Trailer

Tag

Field Name

Required

Note

10

CheckSum

Yes

​

​

Login (MsgType = A)

The logon message identifies and authenticates the user or member and establishes a connection to the FIX Gateway.

The FIX gateway accepts Logon messages as per the FIX specification. Further, the FIX gateway supports the logon sequence required for session authentication.

After a successful logon as described in the specification the FIX gateway will:

  1. Initiate retransmission processing via a resend request if the Logon sequence number is greater than the value expected

  2. Initiate logout processing via a Logout message with an appropriate error message, then wait for a confirming Logout before disconnecting if the Logon sequence number is less than expected. If the confirming Logout has not been received within a short period of time the session will be disconnected.

  3. Handle retransmission requests.

  4. Initiate a Logon using the SenderCompID in the message header.

  5. Will forward to the FIX client messages that are waiting in the outbound queue

  6. Begin regular message communication.

Tag

Field Name

Required

Note

​

StandardHeader

Yes

MsgType = A

108

HeartBtInt

Yes

Heartbeat interval in seconds

​

StandardTrailer

Yes

​

​

Logout (MsgType = 5)

The Logout message initiates or confirms the termination of a FIX session.

The FIX gateway will receive and generate logout messages as required by the FIX Protocol. The gateway follows the prescribed sequence of messages for the proper termination of the session.

Messages received by the gateway after the client logs out are stored in a log file for transmission to the client once the client logs in again within the same trading day. The messages to be transmitted are dependent on the sequence number reconciliation that occurs on a logon handshake.

Upon receipt of a Logout message:

  1. A confirming logout message will be sent by the gateway to the client; then,

  2. The session will be disconnected. The FIX gateway should never initiate a logoff except when a severe error has occurred.

Tag

Field Name

Required

Note

​

StandardHeader

Yes

MsgType = 5

58

Text

No

Free format text string (Note: this field does not have a specified maximum length) If the Logout message has been sent by the the FIX gateway, then this field will contain the text “Session closed”.

​

StandardTrailer

Yes

​

​

New Order - Single (MsgType = D)

This message is used to submit an order to the trading system for processing

Tag

Field Name

Required

Note

​

StandardHeader

Yes

MsgType = D

11

ClOrdId

Yes

Unique identifier of the order. Must be unique for each session, max 32 chars.

1

Account

No

Optional identifier from customer, will be passed back in Execution Report.

55

Symbol

Yes

Common, “human understood” representation of the security, bitcoins US Dollar – BTCUSD, etc.

54

Side

Yes

'1' = Buy

'2' = Sell

38

OrderQty

Yes

Size of the order. E.G. 10

43229

FractionBase

Yes

If FractionBase is 100 and OrderQty field = 1, that means the Order Qty sent to the platform is 0.01.

40

OrdType

Yes

'1' = Market

'2' = Limit

44

Price

No

Required for limit Ordtypes

59

TimeInForce

No

'3' = IOC (Immediate-Or-Cancel)

126

ExpireTime

No

Required if TimeInForce = GTD (GMT Time)

​

StandardTrailer

Yes

​

​

Order Cancel Request (MsgType = F)

Tag

Field Name

Required

Note

​

StandardHeader

Yes

MsgType = F

41

OrigClOrdId

Yes

ClOrdID of the previous order

37

OrderID

No

Unique Identifier of order assigned by the platform.

11

ClOrdId

Yes

Unique ID of cancel request as assigned by the institution.

55

Symbol

Yes

Common, “human understood” representation of the security, bitcoins US Dollar – BTCUSD, etc.

54

Side

No

'1' = Buy

'2' = Sell

38

OrderQty

No

Size of the order. E.G. 10

58

Text

No

​

​

StandardTrailer

Yes

​

​

Order Cancel/Replace Request (MsgType = G)

Tag

Field Name

Required

Note

​

StandardHeader

Yes

MsgType = g

41

OrigClOrdId

Yes

ClOrdID of the previous order

37

OrderID

No

Unique Identifier of order assigned by the platform.

11

ClOrdId

Yes

Unique ID of cancel request as assigned by the institution.

1

Account

No

Optional identifier from customer, will be passed back in Execution Report.

55

Symbol

Yes

Must match original order

54

Side

Yes

Must match original order

38

OrderQty

Yes

Size of the order. E.G. 10

44

Price

No

Required for limit OrdTypes.

59

TimeInForce

Yes

"Needs definition"

126

ExpireTime

No

Required if TimeInForce=

​

StandardTrailer

Yes

​