FIX engine supports 2 types of FIX connections (sessions): trading connections and drop copy connections.

Trading connection accepts all client requests defined in FIX specification and sends responses only to requests received via this particular connection.

Drop copy connection does not accept order requests but instead sends copies of execution reports created for predefined source trading connections. Drop copy connection is to be configured upon request. The configuration of drop copy connection provides options to specify list of source trading connections which executions must be reported as drop copies.

All drop copy messages contains FIX field DropCopy(797)=Y as well as custom field OrigOrdId(9945) with dx client order id

Drop copy connection reports exchange events, i.e. new orders and cancels/replaces rejected by FIX gate itself, are not reported. Also, it may report allocations.

Following execution types ExecType(150) are reported: OrderStatus(only before individual trade reports), New, Replaced, Trade, Cancelled, Expired, Done for Day (for algorithmic orders only).

Session protocol assures client identification, sequential request processing, session state control and ability to restore the session after downtime.

In the scope of session all FIX messages are identified by unique integer sequence number and processed in that order. When incoming sequence number does not match expected one, the session must be recovered. If incoming sequence number is less than expected and PossDuplFlag is not set to Y, it is considered a fatal error, and the connection is dropped by the server. If sequence number of incoming message is greater than next expected number, the Resend Request is issued for missed messages.

The server does not reset session sequences after client disconnect or on daily basis. Sequence reset may be initiated by client sending Logon message with ResetSeqNumFlag = Y.

Client and server use following administrative messages

• Logon - Initiates (client) or approves (server) session opening.
• Logout - Initiates or approves session closing.
• Resend Request - Requests missed fix messages.
• Sequence Reset - Gap Fill, must be used instead of resend of administrative messages.
• Test Request - Used to control session state. For reply requires Heartbeat message with properly filled TestReqID (112) field.
• Heartbeat - Used to control session connection state.
• Reject - Administrative message reject.

All FIX messages either administrative or business require standard header and trailer.

Initiates connection from client side and approves connection if sent by the server. ResetSeqNumFlag allows clients to start the new session (reset session sequence numbers).

The server does not support automatic order cancellation on logout. All orders issued by the client will remain working on the exchange upon logout or disconnect.

The message is used to recover inbound session sequence if some message was missed.

The message may be used in two modes

• Reset Mode forces counterparty to adjust inbound message sequence, FillGapFlag=N or omitted
• Fill Gap Mode is used during retransmission of messages missed by counterparty. Administrative messages and rejected business messages are not to be retransmitted. Instead Sequence Reset message with FillGapFlag=Y must be used

Issued by party if incoming FIX message is unsupported or not property formed. Rejected messages must not be resend if Resend Request is received; instead SequenceReset with FillGapFlag=Y is expected.

Client messages and server messages are application messages. Each application message has a set of common component fields which must be present in messages. Application messages refer to common components as <Standard Header>.

The Parties component block is used to identify and convey information on the entities both central and peripheral to the financial transaction represented by the FIX message containing the Parties Block. The Parties block allows many different types of entities to be expressed through use of the PartyRole field and identifies the source of the PartyID through the the PartyIDSource. The standard 'Parties' component is supported in incoming messages: NewOrderSingle, OrderCancelRequest and OrderCancelReplaceRequest. Outgoing messages: ExecutionReport and OrderCancelReject, should contain the same Parties information - this information is opaque for DX platform.

DxCore system supports the following client-originated messages:

• NewOrderSingle - message to submit new order / to close some opened position;
• NewOrderMultileg - message to submit new multileg order;
• NewOrderList - message to submit OCO, If-Then, If-Then-OCO orders;
• OrderCancelRequest - message to cancel order;
• OrderCancel/ReplaceRequest - message to edit order parameters (price and quantity);
• OrderStatusRequest - message to receive specified order status.

Market order

A market order is a type of order that is filled with current market price.

Limit, Stop and StopLimit orders

Limit, Stop and StopLimit orders are orders filled when market reaches price specified by the client. For StopLimit after StopPx price is reached, order starts behaving like Limit with Price specified.

Market Fill or Kill (FOK) order

FOK order is a type of order that is either filled with price specified by client or rejected.

Orders can be issued on behalf of an existing user session. If the trading party is aware of the existing session, it can include the session token with any trading request - and the trade will be issued on behalf of the user

The token is sent in the 50: SenderSubID tag. If the token is not valid or session is expired, request will be rejected with the 99=OTHER reason. Such reject will have rejected request's token in 57: TargetSubID tag.

MARKET order example:

|8=FIX.4.4|9=133|35=D|49=SENDER_ID|56=TARGET_ID|34=1|52=20250912-00:00:00|11=uniqueClOrdId|1=account|38=1|40=1|54=1|55=AAPL|60=20250912-00:00:00|77=O|10=007|

LIMIT order example:

|8=FIX.4.4|9=142|35=D|49=SENDER_ID|56=TARGET_ID|34=2|52=20250912-00:00:00|11=uniqueClOrdId|1=account|38=1|40=2|59=1|54=1|55=AAPL|60=20250912-00:00:00|77=O|44=500|10=155|

Closing LIMIT order example:

|8=FIX.4.4|9=142|35=D|49=SENDER_ID|56=TARGET_ID|34=3|52=20250912-00:00:00|11=uniqueClOrdId|1=account|38=1|40=2|59=1|54=2|55=AAPL|60=20250912-00:00:00|77=C|44=100|10=142|

STOP order example:

|8=FIX.4.4|9=142|35=D|49=SENDER_ID|56=TARGET_ID|34=4|52=20250912-00:00:00|11=uniqueClOrdId|1=account|38=1|40=3|59=1|54=1|55=AAPL|60=20250912-00:00:00|77=C|99=100|10=159|

FOK order example:

|8=FIX.4.4|9=147|35=D|49=SENDER_ID|56=TARGET_ID|34=5|52=20250912-00:00:00|11=uniqueClOrdId|1=account|38=1|40=2|59=4|54=1|55=AAPL|60=20250912-00:00:00|77=O|44=100|10=144|

This repeating group is used in NewOrderMultileg to specify the order legs

Market multileg order example:

|8=FIX.4.2|9=200|35=AB|49=SENDER_ID|56=TARGET_ID|34=9|52=20250912-00:00:00|11=uniqueClOrdId|1=account|54=1|38=1|40=1|59=1|555=2|600=AAPL|564=O|623=100|624=1|600=.AAPL260116C140|564=O|623=1|624=1|60=20250912-00:00:00|10=156|

Accepted NewOrderList requests will result in two or three execution reports, depending on ContingencyType of request. It's not guaranteed that first of reports will relate to first order in list. Client must consult value of ClOrdID field in execution report to understand to which order of NewOrderList request it relates.

For PnC FIX messages, first order in ListOrdGrp is parent, all others are contingents.

Across all orders in NewOrderList message following fields must have same value, otherwise request will be rejected: Account, Symbol, TIF. Additionally, if trading non-FX instruments, SecurityType, BookingType or CFICode values specified in message, taken together with Symbol field, must resolve to the same instrument inside DxCore system, otherwise request will be rejected.

Currently, NewOrderList allows following combinations of ContingencyType with values of OrderQty and PositionEffect of individual orders in list:

Entry OCOs: ContingencyType set to 1. Individual orders must not have PositionId field and their PositionEffect must be set to OPEN("O"). Attached or closing OCOs are not supported.

If-Then or If-Then-OCO: ContingencyType set to 101/102. Parent order must have its PositionEffect set to OPEN. There may be one or two contingent orders, and they must have PositionEffect set to CLOSE. For Equities and options, you must specify valid quantity in OrderQty field of individual contingent orders.

OcO request example:

|8=FIX.4.4|9=253|35=E|49=SENDER_ID|56=TARGET_ID|34=230|52=20250912-00:00:00|66=uniqueListId|1385=1|68=2|73=2|11=uniqueClOrdId1|1=account|55=AAPL|38=1|40=2|54=1|77=O|44=100|60=20250912-00:00:00|11=uniqueClOrdId2|1=account|55=AAPL|38=1|40=3|54=1|77=O|99=500|60=20250912-00:00:00|10=222|

If-Then request example with one child:

|8=FIX.4.4|9=255|35=E|49=SENDER_ID|56=TARGET_ID|34=250|52=20250912-00:00:00|66=uniqueListId|1385=101|68=2|73=2|11=uniqueClOrdId1|1=account|55=AAPL|38=1|40=2|54=1|77=O|44=100|60=20250912-00:00:00|11=uniqueClOrdId2|1=account|55=AAPL|38=0|40=3|54=2|77=C|99=100|60=20250912-00:00:00|10=063|

If-Then-OCO request example with two children:

|8=FIX.4.4|9=335|35=E|49=SENDER_ID|56=TARGET_ID|34=276|52=20250912-00:00:00|66=uniqueListId|1385=102|68=3|73=3|11=uniqueClOrdId1|1=account|55=AAPL|38=1|40=2|54=1|77=O|44=100|60=20250912-00:00:00|11=uniqueClOrdId2|1=account|55=AAPL|38=1|40=3|54=2|77=C|99=100|60=20250912-00:00:00|11=uniqueClOrdId3|1=account|55=AAPL|38=1|40=2|54=2|77=C|44=100|60=20250912-00:00:00|10=243|

Notes:

• it is impossible to cancel a cancel order request, only full order cancellation is supported
• any orders can be canceled. It's possible to cancel non-final orders which participate in OcO, PnC groups. Group will be modified:
  • OcO - both OCO orders cancelled in case of one OCO order cancellation
  • PnC - Cancel group when cancel Parent order, remove contingency order from group when cancelling contingency order

Cancel order request example:

|8=FIX.4.4|9=135|35=F|49=SENDER_ID|56=TARGET_ID|34=10|52=20250912-00:00:00|1=account|11=uniqueClOrdId|38=1|54=1|55=AAPL|60=20250912-00:00:00|41=ClOrdIdToCancel|10=242|

Notes:

• only LIMIT, STOP and STOPLIMIT orders in NEW/WORKING/PARTIAL_FILLED state (not filled yet) can be replaced
• only price(s) and quantity may be replaced
• It's allowed to replace order which participate in OcO/PnC order group. Note that in case of order group modification execution reports for other group orders can be sent.

Cancel/Replace request of LIMIT order example:

|8=FIX.4.4|9=158|35=G|49=SENDER_ID|56=TARGET_ID|34=26|52=20250912-00:00:00|11=uniqueClOrdId|1=account|41=clOrdIdToReplace|55=AAPL|38=1|40=2|54=1|60=20250912-00:00:00|77=O|44=300|59=1|10=115|

Cancel/Replace request of STOP order example:

|8=FIX.4.4|9=158|35=G|49=SENDER_ID|56=TARGET_ID|34=26|52=20250912-00:00:00|11=uniqueClOrdId|1=account|41=clOrdIdToReplace|55=AAPL|38=1|40=3|54=1|60=20250912-00:00:00|77=O|99=100|59=1|10=115|

Example:

|8=FIX.4.2|9=220|35=AC|49=SENDER_ID|56=TARGET_ID|34=103|52=20250912-00:00:00|11=uniqueClOrdId|41=clOrdIdToReplace|1=account|54=1|38=1|40=2|59=1|555=2|600=AAPL|564=O|623=100|624=1|600=.AAPL260116C140|564=O|623=1|624=1|60=20250912-00:00:00|44=500|10=022|

The server will reject the request if account and / or instrument don't match account / instrument of the order.

Order Status Request example:

|8=FIX.4.4|9=107|35=H|49=SENDER_ID|56=TARGET_ID|34=34|52=20250912-00:00:00|1=account|11=clOrdIdToCheck|55=AAPL|54=1|790=uniqueStatusRequestId|10=166|

Server will send following messages to update client with the events in corresponding accounts.

• Execution Report about order execution status /reject reason (received as reply to NewOrderSingle, NewOrderList)

• Cancel Reject message notifies that cancel/replace could not be processed (received as reply to Order Cancel/Replace Request)

This repeating group is used in Execution Report to specify the order leg

Reports example for single leg order:

|8=FIX.4.2|9=202|35=8|49=TARGET_ID|56=SENDER_ID|34=37|52=20250912-00:00:00|37=orderId|11=clOrdId|17=execId|150=0|39=0|1=account|55=AAPL|461=EXXXXX|54=1|38=1|40=1|59=1|151=1|14=0|6=0|60=20250912-00:00:00|77=O|10=002|

|8=FIX.4.2|9=222|35=8|49=TARGET_ID|56=SENDER_ID|34=38|52=20250912-00:00:00|37=orderId|11=clOrdId|17=execId|150=F|39=2|1=account|55=AAPL|461=EXXXXX|54=1|38=1|40=1|59=1|32=1|31=226.79|151=0|14=1|6=226.79|60=20250912-00:00:00|77=O|10=217|

Reports example for multileg order:

|8=FIX.4.2|9=304|35=8|49=TARGET_ID|56=SENDER_ID|34=7|52=20250912-00:00:00|37=orderId|11=clOrdId|17=execId|150=0|39=0|1=account|167=MLEG|54=1|38=1|40=1|59=1|151=1|14=0|6=0|60=20250912-00:00:00|555=2|600=AAPL|608=EXXXXX|623=100|624=1|564=O|600=.AAPL260116C140|608=OCAXXX|611=20260115|612=140.0|623=1|624=1|564=O|10=023|

|8=FIX.4.2|9=356|35=8|49=TARGET_ID|56=SENDER_ID|34=8|52=20250912-00:00:00|37=orderId|11=clOrdId|17=execId|150=F|39=0|1=account|167=MLEG|54=1|38=1|40=1|59=1|32=1|151=1|14=0|6=0|60=20250912-00:00:00|442=3|555=2|600=AAPL|608=EXXXXX|623=100|624=1|566=226.79|564=O|637=226.79|1418=100|600=.AAPL260116C140|608=OCAXXX|611=20260115|612=140.0|623=1|624=1|566=89.75|564=O|10=207|

|8=FIX.4.2|9=358|35=8|49=TARGET_ID|56=SENDER_ID|34=9|52=20250912-00:00:00|37=orderId|11=clOrdId|17=execId|150=F|39=2|1=account|167=MLEG|54=1|38=1|40=1|59=1|32=1|151=0|14=1|6=316.54|60=20250912-00:00:00|442=3|555=2|600=AAPL|608=EXXXXX|623=100|624=1|566=226.79|564=O|600=.AAPL260116C140|608=OCAXXX|611=20260115|612=140.0|623=1|624=1|566=89.75|564=O|637=89.75|1418=1|10=073|

Rejected report example:

|8=FIX.4.4|9=300|35=8|49=TARGET_ID|56=SENDER_ID|34=51|52=20250912-00:00:00|37=orderId|11=clOrderId|17=execId|150=8|39=8|103=99|1=account|55=AAPL|461=EXXXXX|54=1|38=1|40=3|99=100.0|59=1|151=0|14=0|6=0|60=20250912-00:00:00|77=O|58=STOP_ORDER_IN_THE_MARKET: Stop price surpassed. Please adjust your stop price.|10=231|

Canceled report example:

|8=FIX.4.2|9=225|35=8|49=TARGET_ID|56=SENDER_ID|34=47|52=20250912-00:00:00|37=orderId|11=clOrdId|41=origClOrdId|17=execId|150=4|39=4|1=account|55=AAPL|461=EXXXXX|54=1|38=1|40=2|44=100.0|59=1|151=0|14=0|6=0|60=20250912-00:00:00|77=O|10=086|

Example:

|8=FIX.4.2|9=209|35=8|49=TARGET_ID|56=SENDER_ID|34=54|52=20250912-00:00:00|37=orderId|11=clOrdId|790=requestId|17=execId|150=I|39=2|1=account|55=AAPL|461=EXXXXX|54=1|38=1|59=1|151=0|14=1|6=226.79|60=20250912-00:00:00|77=O|10=238|

Example for single leg order:

|8=FIX.4.2|9=222|35=8|49=TARGET_ID|56=SENDER_ID|34=63|52=20250912-00:00:00|37=orderId|11=clOrdId|41=origClOrdId|17=execId|150=E|39=E|1=account|55=AAPL|461=EXXXXX|54=1|38=1|40=2|44=100.0|59=1|151=1|14=0|6=0|60=20250912-00:00:00|77=O|10=182|

|8=FIX.4.2|9=222|35=8|49=TARGET_ID|56=SENDER_ID|34=64|52=20250912-00:00:00|37=orderId|11=clOrdId|41=origClOrdId|17=execId|150=5|39=0|1=account|55=AAPL|461=EXXXXX|54=1|38=1|40=2|44=300.0|59=1|151=1|14=0|6=0|60=20250912-00:00:00|77=O|10=153|

Example for multileg leg order:

|8=FIX.4.2|9=326|35=8|49=TARGET_ID|56=SENDER_ID|34=100|52=20250912-00:00:00|37=orderId|11=clOrdId|41=origClOrdId|17=execId|150=E|39=E|1=account|167=MLEG|54=1|38=1|40=2|44=100.0|59=1|151=1|14=0|6=0|60=20250912-00:00:00|555=2|600=AAPL|608=EXXXXX|623=100|624=1|564=O|600=.AAPL260116C140|608=OCAXXX|611=20260115|612=140.0|623=1|624=1|564=O|10=025|

|8=FIX.4.2|9=326|35=8|49=TARGET_ID|56=SENDER_ID|34=101|52=20250912-00:00:00|37=orderId|11=clOrdId|41=origClOrdId|17=execId|150=5|39=0|1=account|167=MLEG|54=1|38=1|40=2|44=500.0|59=1|151=1|14=0|6=0|60=20250912-00:00:00|555=2|600=AAPL|608=EXXXXX|623=100|624=1|564=O|600=.AAPL260116C140|608=OCAXXX|611=20260115|612=140.0|623=1|624=1|564=O|10=254|

ExecutionReport sent as Drop Copy contains all FIX tags regular ExecutionReport contains and some additional tags. See examples above to check how regular ExecutionReport looks.

Additional tags of Drop Copy ExecutionReport:

• 9945(OrigOrdID) -- used to send ID of Client order (ID of order client or dealer observes in DxTrade or WebBroker UIs)
• 797(CopyMsgIndicator)=Y -- marks the message is a Drop Copy

Drop Copy ExecutionReport

Drop Copy ExecutionReport examples:

Example 1:

Preconditions:

• Сlient issued a Market order for AAPL instrument with Quantity=20. Order Was filled with 4 separate fills with quantities: 2, 5, 7, 6 shares accordingly.

Fix messages counterparty can observe in Drop Copy FIX session:

1. Order was accepted in DX platform.

   |8=FIX.4.2|9=221|35=8|49=TARGET_ID|56=SENDER_ID|34=38|43=N|52=20250912-00:00:00|37=orderId|11=clOrdId|17=execId|150=0|39=0|1=account|55=AAPL|461=EXXXXX|54=1|38=20|40=1|59=0|151=20|14=0|6=0|60=20250912-00:00:00|77=O|797=Y|9945=origOrdId|10=085|
   

2. Drop Copy with partial with 2 shares.

   |8=FIX.4.2|9=241|35=8|49=TARGET_ID|56=SENDER_ID|34=39|43=N|52=20250912-00:00:01|37=orderId|11=clOrdId|17=execId|150=F|39=1|1=account|55=AAPL|461=EXXXXX|54=1|38=20|40=1|59=0|32=2|31=234.07|151=18|14=2|6=234.07|60=20250912-00:00:01|77=O|797=Y|9945=origOrdId|10=024|
   

3. Drop Copy with partial with 5 shares.

   |8=FIX.4.2|9=241|35=8|49=TARGET_ID|56=SENDER_ID|34=40|43=N|52=20250912-00:00:02|37=orderId|11=clOrdId|17=execId|150=F|39=1|1=account|55=AAPL|461=EXXXXX|54=1|38=20|40=1|59=0|32=5|31=234.07|151=13|14=7|6=234.07|60=20250912-00:00:02|77=O|797=Y|9945=origOrdId|10=022|
   

4. Drop Copy with partial with 7 shares.

   |8=FIX.4.2|9=241|35=8|49=TARGET_ID|56=SENDER_ID|34=41|43=N|52=20250912-00:00:03|37=orderId|11=clOrdId|17=execId|150=F|39=1|1=account|55=AAPL|461=EXXXXX|54=1|38=20|40=1|59=0|32=7|31=234.07|151=6|14=14|6=234.07|60=20250912-00:00:03|77=O|797=Y|9945=origOrdId|10=028|
   

5. Drop Copy with final partial with 6 shares.

   |8=FIX.4.2|9=241|35=8|49=TARGET_ID|56=SENDER_ID|34=42|43=N|52=20250912-00:00:04|37=orderId|11=clOrdId|17=execId|150=F|39=2|1=account|55=AAPL|461=EXXXXX|54=1|38=20|40=1|59=0|32=6|31=234.07|151=0|14=20|6=234.07|60=20250912-00:00:04|77=O|797=Y|9945=origOrdId|10=014|
   

Platform supports special Allocation Orders Information. Such orders can also be reported via Fix DropCopy session.

OrdAllocGrp

AllocGrp

AllocationReport FIX message:

Text values for business rejects (not for FIX-level errors) are of following format: Error_Code: Descriptive_Text. For example, "INTERNAL_ERROR: Internal error. Please contact your account manager".

Following table shows some possible values for error codes, which are constant, and corresponding texts, which can be changed. Additionally, business meaning of error is elaborated in "Comments" column.

X means symbols specific for the given instrument (currently DX server disregards any values placed at X positions received from client) or symbol 'X' itself for values written by DX server side.