FIX Maker Specification

Version 1.00DRAFTSeptember 17, 2026

Download PDF

1. Introduction

1.1 Purpose

This document describes the FIX Maker API, a FIX 4.4-based channel that enables liquidity providers to offer foreign exchange liquidity to MEX Exchange customers and execute trades. The API provides real-time market data distribution and order execution capabilities through two dedicated FIX sessions.

1.2 Scope

This specification covers:

• Connectivity requirements and session management
• Supported FIX message types and workflows
• Market data distribution mechanisms
• Order submission and execution processes
• Error handling and recovery procedures

1.3 Document Conventions

• Required fields are marked with Y in the Req column
• Optional fields are marked with N in the Req column
• Inbound messages (I) are sent to the Provider (MEX Exchange → Provider)
• Outbound messages (O) are sent from the Provider (Provider → MEX Exchange)
• Bidirectional messages (B) can be sent in either direction

All timestamps are in UTC. Developers should validate incoming messages and use unique identifiers to avoid collisions.

2. Connectivity

2.1 Connection Architecture

The FIX Maker API operates with a dual-session architecture:

• Market Data Session: Distributes real-time market data including live price feeds and market depth
• Orders Session: Handles order submission, execution, and trade reporting

The sessions are paired: MEX Exchange subscribes to and consumes market data only while the Orders session is logged in.

2.2 Acceptor/Initiator Logic

Role Assignment:

• Provider (Maker): Acts as the Initiator — initiates connection to MEX Exchange
• MEX Exchange: Acts as the Acceptor — accepts connections from the provider

Connection Flow:

1. Provider initiates TCP connection to MEX Exchange
2. MEX Exchange accepts the connection and waits for Logon message
3. Provider sends Logon message to establish FIX session
4. MEX Exchange responds with Logon message
5. Sessions become active for message exchange

Connect to each session separately using the same credentials but different SenderCompID indicators.

2.3 Supported Instruments

Instrument Type	Description
SPOT	Immediate settlement FX transactions (standard T+2 settlement).
NDFs	Non-Deliverable Forwards — cash-settled FX derivatives for emerging markets.

Notes: Market data subscriptions currently cover FXSPOT and FXNDF only. Instruments are specified via Symbol (e.g. EUR/USD), SecurityType, and SettlType/SettlDate for tenors.

3. FIX Protocol Information

3.1 Supported FIX Version

The FIX Maker API conforms to FIX 4.4 specifications as defined by the FIX Protocol Organization (http://www.fixprotocol.org).

3.2 Message Structure

All FIX messages consist of three components:

1. Standard Header: Contains routing and identification fields (always first)
2. Message Body: Contains message-specific fields
3. Standard Trailer: Contains integrity check field (always last)

Messages are delimited by SOH (Start of Header, ASCII 01) characters.

3.3 Standard Header Fields

Tag	Name	Req	Type	Notes
8	BeginString	Y	String	Always first field. Must be set to FIX.4.4
9	BodyLength	Y	Int	Always second field. Message length in bytes.
35	MsgType	Y	String	Always third field. Type of message.
34	MsgSeqNum	Y	Int	Sequence number of the message.
52	SendingTime	Y	UTCTimeStamp	Always expressed in UTC: YYYYMMDD-HH:MM:SS.sss
49	SenderCompID	Y	String	CompID of the sender.
56	TargetCompID	Y	String	CompID of the recipient.

Notes: Validate sequence numbers on receipt. SendingTime must be within acceptable skew (e.g. ±120 seconds) or risk rejection.

3.4 Standard Trailer Fields

Tag	Name	Req	Type	Notes
10	CheckSum	Y	String	Three bytes, simple checksum. Always last in message.

3.5 Session Management

3.5.1 Heartbeat Mechanism

• Purpose: Maintains session connectivity and detects communication failures
• Interval: Configurable, maximum 60 seconds
• Behavior: If no messages received within heartbeat interval, Test Request is sent
• Response: Heartbeat message must be sent in response to Test Request

3.5.2 Sequence Number Management

• Recovery: Supported for Orders session only
• Sequence numbers may reset to 1 on logon when ResetSeqNumFlag=Y

3.5.3 Test Request Handling

• Trigger: Sent when no messages received within heartbeat interval
• Response: Must be answered with Heartbeat containing TestReqID
• Timeout: Failure to respond may result in session termination

3.6 Message Length and Field Limitations

• Message Length: No maximum imposed on FIX message length
• String Fields: No length restrictions on undefined String fields (IDs, free text)
• Defined Fields: Limited to longest valid value as per FIX specification
• Character Encoding: UTF-8 encoding recommended for text fields

3.7 Supported Message Types

MsgType	Message Name	Direction
A	Logon	Bidirectional (B)
5	Logout	Bidirectional (B)
0	Heartbeat	Bidirectional (B)
1	Test Request	Bidirectional (B)
3	Reject	Bidirectional (B)
j	Business Message Reject	Bidirectional (B)
V	Market Data Request	Inbound (I)
Y	Market Data Request Reject	Outbound (O)
W	Market Data Snapshot Full Refresh	Outbound (O)
X	Market Data Incremental Refresh	Outbound (O)
D	New Order Single	Inbound (I)
Q	Don't Know Trade	Inbound (I)
8	Execution Report	Bidirectional (B)

Note: Execution Report is bidirectional. The Provider sends last-look responses to MEX Exchange; MEX Exchange may also send Execution Reports back to the Provider to confirm fills (including no-last-look paths). Inbound/Outbound is from client perspective

4. Workflows

4.1 Session Establishment Workflow

MEX Exchange                            Provider
    |                                       |
    |<-- Logon MsgType(35) = A (Market) ----|
    |--- Logon MsgType(35) = A (Market) --->|
    |                                       |
    |<-- Logon MsgType(35) = A (Orders) ----|
    |--- Logon MsgType(35) = A (Orders) --->|
    |                                       |

Steps:

1. Provider initiates TCP connection to MEX Exchange
2. MEX Exchange accepts connection
3. Provider sends Logon message with credentials and session parameters
4. MEX Exchange validates credentials and responds with Logon acknowledgment
5. Both sessions become active for message exchange. Market data subscriptions proceed only while the Orders session remains logged in.

4.2 Market Data Session Workflow

4.2.1 Market Data Request Flow

MEX Exchange                            Provider
    |                                       |
    |--- Market Data Request (V) ---------->|
    |<-- Market Data Snapshot (W) ----------|
    |<-- Incremental Update (X) ------------|
    |<-- Incremental Update (X) ------------|
    |                                       |

Process:

1. Market Data Request: MEX Exchange sends a request per instrument with:
   • Subscription type 1 (snapshot + updates) or 2 (unsubscribe)
   • Symbol and security type (FXSPOT or FXNDF for market data subscriptions)
   • Optional market depth
2. Market Data Response: Provider responds with:
   • Initial snapshot of current market state (35=W)
   • Continuous incremental updates for price changes (35=X)
3. Each W/X message must carry TradingSessionID (336) identifying the liquidity stream.

Note: Market data subscriptions currently cover FXSPOT and FXNDF only. Snapshots are optional when subscribed to incremental updates

4.2.2 Market Data Request Rejection Flow

MEX Exchange                            Provider
    |                                       |
    |--- Market Data Request (V) ---------->|
    |<-- Market Data Request Reject (Y) ----|
    |                                       |

Rejection Reasons (Provider → MEX Exchange via Y):

• Invalid symbol or security type
• Unsupported market depth
• Subscription limit exceeded
• Authentication/authorization issues

MEX Exchange may also send Business Message Reject (j) for application-level problems on inbound W/X (e.g. missing/unknown TradingSessionID, invalid MDEntryID, unknown MDReqID).

4.3 Order Session Workflow

4.3.1 Successful Order Execution Flow (Last Look)

MEX Exchange                            Provider
    |                                       |
    |--- New Order Single (D) ------------->|
    |<-- Execution Report (8) --------------|
    |    (fill: ExecType=F or OrdStatus=2)  |
    |--- Execution Report (8) ------------->|
    |    (confirm: ExecType=2, OrdStatus=2) |
    |                                       |

Process:

1. Order Submission: MEX Exchange sends New Order Single (Limit, FOK) with unique ClOrdID, symbol, side, quantity, and price.
2. Last-look response: Provider returns an Execution Report. MEX Exchange treats the order as accepted when ExecType=F or OrdStatus=2; other terminal statuses are treated as reject.
3. Confirm: MEX Exchange may send an Execution Report back to the Provider to confirm the fill.

4.3.2 Order Rejection Flow

MEX Exchange                            Provider
    |                                       |
    |--- New Order Single (D) ------------->|
    |<-- Execution Report (8) --------------|
    |    (OrdStatus = Rejected / non-fill)  |
    |                                       |

Rejection Reasons:

• Invalid symbol or parameters
• Insufficient liquidity
• Price outside acceptable range
• Risk management constraints
• Provider last-look reject (non-fill Execution Report)

4.3.3 Order Timeout / Don't Know Trade Flow

MEX Exchange                            Provider
    |                                       |
    |--- New Order Single (D) ------------->|
    |         ... (timeout / not done)      |
    |--- Don't Know Trade (Q) ------------->|
    |                                       |

When the Provider does not complete the last-look response in time, or the matching engine signals maker-order-not-done, MEX Exchange sends Don't Know Trade (35=Q) to the Provider.

4.4 Session Termination Workflow

MEX Exchange                            Provider
    |                                       |
    |--- Logout (5) ------------------------>|
    |<-- Logout (5) ------------------------|
    |                                       |

4.5 Error Recovery Workflows

4.5.1 Sequence Gap Recovery

Sequence gap detection and Resend Request recovery are not supported. On sequence problems, reconnect with ResetSeqNumFlag=Y and rebuild state (resubscribe market data; do not expect retransmission of application messages).

4.5.2 Heartbeat and Test Request

MEX Exchange                            Provider
    |                                       |
    |  (No messages received within HB      |
    |   interval)                           |
    |<-- Test Request (1) ------------------|
    |--- Heartbeat (0) (with TestReqID) --->|
    |                                       |

5. FIX Messages

Note: Any FIX tags that are not required are at the client's discretion whether or not the tags are sent/received.

5.1 Session Management Messages

5.1.1 Logon (MsgType = A)

Purpose: Establishes FIX session between counterparties
Direction: Bidirectional
Sender: Initially sent by Provider (Initiator), acknowledged by MEX Exchange (Acceptor)

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = A
98	EncryptMethod	Y	Int	Indicates method of encryption. Valid value = 0
108	HeartBtInt	Y	Int	How often heartbeat is expected. Valid value = < 60
141	ResetSeqNumFlag	N	Char	Forces reset of sequence numbers to 1. Valid values: Y or N. Typically Y.
553	Username	N	String	Required when the session is configured for username/password authentication.
554	Password	N	String	Required when the session is configured for username/password authentication.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=145|35=A|34=1|49=PROVIDER|56=MEXEXCHNG|52=20251007-15:01:22.123|98=0|108=30|141=Y|553=MEX_MAKER|554=SuperSecure123|10=128|

5.1.2 Logout (MsgType = 5)

Purpose: Terminates FIX session gracefully
Direction: Bidirectional
Sender: Either party can initiate logout

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = 5
58	Text	N	String	Reason for logout.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=85|35=5|34=2|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:01:25.555|58=Session terminated normally|10=043|

5.1.3 Heartbeat (MsgType = 0)

Purpose: Maintains session connectivity
Direction: Bidirectional
Sender: Sent periodically or in response to Test Request

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = 0
112	TestReqID	N	String	If responding to a Test Request, contains the value of TestReqID<112> from the associated Test Request.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=72|35=0|34=3|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:01:30.000|112=TEST_HEARTBEAT|10=077|

5.1.4 Test Request (MsgType = 1)

Purpose: Tests session connectivity when no messages received
Direction: Bidirectional
Sender: Either party when heartbeat interval exceeded

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = 1
112	TestReqID	Y	String	Identifier for the test request.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=80|35=1|34=4|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:01:35.111|112=TEST_REQ_001|10=099|

5.1.5 Reject (MsgType = 3)

Purpose: Indicates rejection of received message
Direction: Bidirectional
Sender: Party rejecting malformed or invalid message

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = 3
371	RefTagID	N	Int	The FIX tag of the field which caused the reject.
372	RefMsgType	N	String	The MsgType of the message that caused the reject.
373	SessionRejectReason	N	Int	An enumerated reason for the reject.
45	RefSeqNum	Y	Int	The MsgSeqNum of the message that caused the reject.
58	Text	N	String	Explanation of the reject.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=150|35=3|34=5|49=PROVIDER|56=MEXEXCHNG|52=20251007-15:01:40.321|45=4|371=55|372=D|373=1|58=Invalid Symbol|10=055|

5.1.6 Business Message Reject (MsgType = j)

Purpose: Indicates application-level rejection of a received business message
Direction: Bidirectional
Sender: Party rejecting a business message it cannot process (commonly MEX Exchange rejecting bad W/X)

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = j
45	RefSeqNum	N	Int	The MsgSeqNum of the message that caused the reject.
372	RefMsgType	Y	String	The MsgType of the business message that caused the reject.
379	BusinessRejectRefID	N	String	The business-level ID of the message being rejected.
380	BusinessRejectReason	Y	Int	0 = Other, 1 = Unknown ID, 2 = Unknown Security. MEX Exchange typically sets 372 + 380 only.
—	Standard Trailer	—	—

Common reasons from MEX Exchange:

• 0 — Other (e.g. missing TradingSessionID)
• 1 — Unknown ID / instrument disabled
• 2 — Unknown security / unknown MDReqID

Example:

8=FIX.4.4|9=120|35=j|34=6|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:01:45.000|372=W|380=0|10=066|

5.2 Market Data Messages

5.2.1 Market Data Request (MsgType = V)

Purpose: Subscribes to market data for specified instruments
Direction: Inbound (MEX Exchange → Provider)
Sender: MEX Exchange

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = V
262	MDReqID	Y	String	Unique request id. MEX Exchange sets this to the decimal instrument id.
263	SubscriptionRequestType	Y	Char	1 = Snapshots + Incremental Updates, 2 = Disable Updates. (Snapshot-only 0 is not sent by MEX Exchange.)
264	MarketDepth	N	Int	0 = Full Book, 1 = TOB, N > 1 = N Tiers. Taken from session configuration.
146	NoRelatedSym	Y	Int	Number of symbols (valid value: 1).
> 55	Symbol	Y	String	Currency pair CCY/CCY.
> 167	SecurityType	Y	String	FXSPOT or FXNDF for market data subscriptions.
> 63	SettlType	N	String	Tenor label (e.g. SP, TOM, 1M). Always set when supported.
> 64	SettlDate	N	String	YYYYMMDD. Set for NDFs (value date).
> 541	MaturityDate	N	String	Fixing date YYYYMMDD. Set for NDFs.
—	Standard Trailer	—	—

Notes: One Market Data Request per instrument.

Example:

8=FIX.4.4|9=145|35=V|34=6|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:01:50.456|262=100|263=1|264=5|146=1|55=EUR/USD|167=FXSPOT|63=SP|10=073|

5.2.2 Market Data Request Reject (MsgType = Y)

Purpose: Rejects invalid market data subscription request
Direction: Outbound (Provider → MEX Exchange)
Sender: Provider

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = Y
262	MDReqID	Y	String	The MDReqID of the Market Data Request being rejected.
281	MDReqRejReason	N	Char	An enumerated reason for rejection.
58	Text	N	String	Additional explanation for reject.
—	Standard Trailer	—	—

Notes: MEX Exchange logs Market Data Request Rejects; it does not automatically resubscribe.

Example:

8=FIX.4.4|9=120|35=Y|34=7|49=PROVIDER|56=MEXEXCHNG|52=20251007-15:01:55.789|262=100|281=2|58=Unsupported market depth|10=084|

5.2.3 Market Data Snapshot Full Refresh (MsgType = W)

Purpose: Provides complete market data state for requested instrument
Direction: Outbound (Provider → MEX Exchange)
Sender: Provider

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = W
262	MDReqID	Y	String	Must match an active MEX Exchange subscription (instrument id).
55	Symbol	Y	String	Currency pair CCY/CCY.
336	TradingSessionID	Y	String	Liquidity stream id. Required in practice — missing or unresolved values cause Business Message Reject.
167	SecurityType	N	String	FXSPOT, FXNDF when provided.
63	SettlType	N	String	Tenor / settlement period.
64	SettlDate	N	String	Settlement date YYYYMMDD. Used for NDF value date when present.
541	MaturityDate	N	String	Fixing date YYYYMMDD. NDFs only (fallback for value date when needed).
268	NoMDEntries	Y	Int	Number of market data entries. 0 clears the stream book.
> 269	MDEntryType	Y	Char	0 = Bid, 1 = Offer
> 270	MDEntryPx	Y	Float	Market data entry price (all-in rate). May be derived from spot + forward points when both are present.
> 1026	MDEntrySpotRate	N	Float	Spot rate for NDF entries.
> 1027	MDEntryForwardPoints	N	Float	Forward points relative to spot for all-in rate.
> 271	MDEntrySize	Y	Float	Market data entry size.
> 278	MDEntryID	Y	String	Numeric string in range 0–255. Maps 1:1 to the internal price id. Must be unique per side within the stream.
> 5001	MDExpireMs	N	Int	Milliseconds until this entry expires and is removed.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=280|35=W|34=8|49=PROVIDER|56=MEXEXCHNG|52=20251007-15:02:00.999|262=100|55=EUR/USD|336=STREAM1|167=FXSPOT|63=SP|268=2|269=0|270=1.0650|271=5000000|278=1|5001=1000|269=1|270=1.0652|271=5000000|278=2|5001=1000|10=233|

5.2.4 Market Data Incremental Refresh (MsgType = X)

Purpose: Provides incremental changes to market data
Direction: Outbound (Provider → MEX Exchange)
Sender: Provider

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = X
262	MDReqID	Y	String	Must match an active MEX Exchange subscription.
55	Symbol	Y	String	Currency pair CCY/CCY.
336	TradingSessionID	Y	String	Liquidity stream id. Required in practice.
167	SecurityType	N	String	FXSPOT, FXNDF when provided.
63	SettlType	N	String	Tenor / settlement period.
64	SettlDate	N	String	Settlement date YYYYMMDD.
541	MaturityDate	N	String	Fixing date YYYYMMDD. NDFs only.
268	NoMDEntries	Y	Int	Number of market data entries.
> 279	MDUpdateAction	Y	Char	0 = New, 1 = Change, 2 = Delete
> 278	MDEntryID	Y	String	Numeric string in range 0–255. Same uniqueness rules as snapshot.
> 270	MDEntryPx	Y	Float	Market data entry price (all-in rate).
> 1026	MDEntrySpotRate	N	Float	Spot rate for Forward/NDF.
> 1027	MDEntryForwardPoints	N	Float	Forward points relative to spot.
> 271	MDEntrySize	Y	Float	Market data entry size.
> 269	MDEntryType	Y	Char	0 = Bid, 1 = Offer
> 5001	MDExpireMs	N	Int	Milliseconds until this entry expires. Rescheduled on New/Change; canceled on Delete.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=200|35=X|34=9|49=PROVIDER|56=MEXEXCHNG|52=20251007-15:02:05.111|262=100|55=EUR/USD|336=STREAM1|167=FXSPOT|63=SP|268=1|279=1|278=1|270=1.0648|271=3000000|269=0|5001=1000|10=164|

5.3 Trading Messages

5.3.1 New Order Single (MsgType = D)

Purpose: Submits new order for last-look execution
Direction: Inbound (MEX Exchange → Provider)
Sender: MEX Exchange

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = D
11	ClOrdID	Y	String	Unique order identifier assigned by MEX Exchange.
55	Symbol	Y	String	Order instrument.
54	Side	Y	Char	1 = Buy, 2 = Sell
38	OrderQty	Y	Float	Quantity of order.
40	OrdType	Y	Char	2 = Limit
44	Price	Y	Float	Limit price (all-in price for forwards).
59	TimeInForce	Y	Char	4 = FOK
60	TransactTime	Y	UTCTimeStamp	Order creation time (UTC).
64	SettlDate	N	String	Value date YYYYMMDD.
63	SettlType	N	String	Tenor when available on the instrument.
167	SecurityType	Y	String	FXSPOT, FXNDF from the instrument.
541	MaturityDate	N	String	Set for NDFs (YYYYMMDD).
—	Standard Trailer	—	—

Notes: Optional dictionary fields such as Account (1), Currency (15), MinQty (110), and TradingSessionID (336) are not currently sent by MEX Exchange on New Order Single.

Example:

8=FIX.4.4|9=200|35=D|34=10|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:02:15.222|11=1728311100123456789|55=EUR/USD|54=1|38=1000000|40=2|44=1.0650|59=4|60=20251007-15:02:15.000|64=20251009|63=SP|167=FXSPOT|10=245|

5.3.2 Don't Know Trade (MsgType = Q)

Purpose: Informs the Provider that MEX Exchange does not recognize / will not complete a trade (timeout or maker-order-not-done)
Direction: Inbound (MEX Exchange → Provider)
Sender: MEX Exchange

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = Q
17	ExecID	Y	String	Execution id generated by MEX Exchange for this DK.
37	OrderID	Y	String	ClOrdID of the related New Order Single (not necessarily the Provider's OrderID).
55	Symbol	Y	String	Instrument as CCY/CCY.
127	DKReason	Y	Char	Currently always A (Unknown symbol). Do not rely on D / T values.
—	Standard Trailer	—	—

Example:

8=FIX.4.4|9=120|35=Q|34=11|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:02:20.333|17=9001|37=1728311100123456789|55=EUR/USD|127=A|10=213|

5.3.3 Execution Report (MsgType = 8)

Purpose: Reports order status changes and trade executions
Direction: Bidirectional
Sender: Provider (last-look response) and MEX Exchange (fill confirm / no-last-look)

Tag	Name	Req	Type	Notes
—	Standard Header	—	—	MsgType<35> = 8
11	ClOrdID	Y	String	ClOrdID from the New Order Single.
37	OrderID	Y	String	Order id (Provider-assigned on inbound; MEX Exchange may echo ClOrdID / cpty id on outbound confirm).
17	ExecID	Y	String	Unique id for this execution report.
39	OrdStatus	Y	Char	2 = Filled, 4 = Canceled, 8 = Rejected
150	ExecType	Y	Char	Provider last-look fill: F (Trade) or treat OrdStatus=2 as fill. MEX Exchange confirm uses 2 (Filled). Also 4 = Canceled, 8 = Rejected.
55	Symbol	Y	String	Instrument symbol.
54	Side	Y	Char	1 = Buy, 2 = Sell
38	OrderQty	Y	Float	Original order quantity.
40	OrdType	Y	Char	2 = Limit
44	Price	N	Float	Original order price (not required on MEX Exchange confirm).
59	TimeInForce	Y	Char	4 = FOK
31	LastPx	N	Float	Fill price when present.
32	LastQty	N	Float	Fill quantity when present.
151	LeavesQty	N	Float	Remaining quantity (0 on full fill confirms).
14	CumQty	Y	Float	Cumulative filled quantity.
6	AvgPx	N	Float	Average fill price (set on MEX Exchange confirm).
195	LastForwardPoints	N	Float	Forward points. Optional; not currently set by MEX Exchange on confirm.
64	SettlDate	Y	Date	Settlement date YYYYMMDD.
75	TradeDate	Y	Date	Trade date YYYYMMDD.
60	TransactTime	Y	UTCTimeStamp	Time of this report.
167	SecurityType	Y	String	FXSPOT, FXNDF
541	MaturityDate	N	String	NDFs only; not currently set by MEX Exchange on confirm.
58	Text	N	String	Reject / status text (used on inbound rejects).
—	Standard Trailer	—	—

Provider → MEX Exchange (last look): MEX Exchange accepts the response as a fill when ExecType=F or OrdStatus=2. Other terminal statuses are treated as reject; Text (58) is forwarded when present.

MEX Exchange → Provider (confirm): On fill confirm, MEX Exchange sends ExecType=2, OrdStatus=2, with LastPx/LastQty/CumQty/LeavesQty=0 and AvgPx set.

Example (Provider fill response):

8=FIX.4.4|9=280|35=8|34=12|49=PROVIDER|56=MEXEXCHNG|52=20251007-15:02:25.444|11=1728311100123456789|37=ORD7890|17=EXEC7890|39=2|150=F|55=EUR/USD|54=1|38=1000000|40=2|44=1.0650|59=4|31=1.0650|32=1000000|151=0|14=1000000|64=20251009|75=20251007|60=20251007-15:02:25.000|167=FXSPOT|10=187|

Example (MEX Exchange confirm):

8=FIX.4.4|9=260|35=8|34=13|49=MEXEXCHNG|56=PROVIDER|52=20251007-15:02:25.500|11=1728311100123456789|37=1728311100123456789|17=9002|39=2|150=2|55=EUR/USD|54=1|38=1000000|40=2|59=4|31=1.0650|32=1000000|151=0|14=1000000|6=1.0650|64=20251009|75=20251007|60=20251007-15:02:25.500|167=FXSPOT|10=201|

6. Appendices

6.1 Business Rules Summary

6.1.1 Market Data

• Delivery: Snapshot Full Refresh (W) followed by Incremental Refresh (X)
• Stream IDs: TradingSessionID (336) selects the liquidity stream for each update
• MDEntryID: Numeric 0–255, unique per side within a stream; recycled after delete/expire
• MDExpireMs (5001): Optional per-entry TTL; expired entries are removed
• Asset classes subscribed: FXSPOT and FXNDF only
• Paired sessions: Market data is active only while the Orders session is logged in

6.1.2 Order Management

• Supported Order Types: Limit orders only
• Time In Force: FOK (59=4) only
• Last look: Provider responds with Execution Report; MEX Exchange may confirm with a return Execution Report
• Timeout / not-done: MEX Exchange sends Don't Know Trade (Q) with DKReason=A
• Cancel / Replace / Status Request: Not supported on this API

6.1.3 Order Side and Currency

Orders are Limit FOK only. Quantity and side are interpreted relative to the instrument Symbol as published on the New Order Single. Optional Currency / Account / MinQty tags are not currently sent by MEX Exchange.

6.1.4 Security Types

• FXSPOT: Foreign exchange spot transactions (MD + orders)
• FXNDF: Non-deliverable forwards (MD + orders)

6.1.5 Supported Tenors

Tenor
TOD
TOM
2D
3D
4D
5D
6D
1W
2W
3W
1M
2M
3M
IMM1
IMM2
IMM3
IMM4