Rules of Engagement
MATba Order Gateway (FIX 4.4)
The FIX 4.4 Specification for MATba
Version
Date
: 1.22
: 19th Aug 2011
Any requests for further information or clarification of content should be referred
to:
Product Management
Patsystems (UK) Ltd
Riverside House
2a Southwark Bridge Road
London SE1 9HA
Tel: +44 (020) 7940 0490
Fax: +44 (020) 7803 1619
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Contents
1.
2.
Overview ....................................................................................................... 5
1.1
Introduction................................................................................................. 5
1.2
Intended Audience ...................................................................................... 5
FIX Session Guidelines............................................................................... 6
2.1
3.
Session Management ................................................................................. 6
2.1.1
Logon............................................................................................................... 6
2.1.2
Logout.............................................................................................................. 7
2.1.3
Error Recovery – Disconnection from MATba................................................. 7
2.1.4
Reject Messages ............................................................................................. 7
Message Summary ...................................................................................... 8
3.1
Admin Messages ........................................................................................ 8
3.2
Pre-Trade Messages .................................................................................. 8
3.3
Trade Messages ......................................................................................... 9
3.3.1
4.
Example Message Flow .................................................................................. 9
Additional Information on FIX Fields ...................................................... 10
4.1
OrdStatus (39) and ExecType (150) ......................................................... 10
4.2
ClRefID (6209).......................................................................................... 10
4.3
Username (553) and Password (554) ....................................................... 10
4.4
OnBehalfOfCompID (115) and DeliverToCompID (128) ........................... 11
4.5
LegRefID (654) ......................................................................................... 11
4.6
CFICode (461) .......................................................................................... 11
4.6.1
Futures and Options ...................................................................................... 11
4.7
Trade Busts .............................................................................................. 11
4.8
ClientID <parties> ..................................................................................... 13
4.9
Clearing Account <parties>....................................................................... 13
©patsystems
Page 2 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
4.10
Symbology ........................................................................................... 13
4.11
Request Messages Sent from the Client .............................................. 13
4.11.1
5.
4.12
Order Types Matrix .............................................................................. 16
4.13
Persistent vs. Non-Persistent Message States ..................................... 18
4.14
Trade Capture Report Party Role Filtering ........................................... 18
4.15
Timestamps ......................................................................................... 18
4.16
Balance Cancelled Orders/Order Sequencing ...................................... 19
Amendments via FIX ................................................................................. 20
5.1
6.
7.
8.
Reply Messages Sent from the Interface ...................................................... 14
Amendments via FIX ................................................................................ 20
Execution Reports ..................................................................................... 21
6.1
Single-leg Fill Reports............................................................................... 21
6.2
Unsolicited Execution Reports .................................................................. 21
6.3
Orders not Originating from FIX ................................................................ 21
6.4
Triggering Order Types............................................................................. 22
6.5
End of Session ......................................................................................... 22
6.6
Identifying the Counterparty ...................................................................... 22
Pre-Trade Requests .................................................................................. 23
7.1
Security Definitions ................................................................................... 23
7.2
Security Status ......................................................................................... 23
7.3
Security List .............................................................................................. 24
Negotiated Trades ..................................................................................... 25
8.1
One-sided Party Matching Ticket .............................................................. 25
8.1.1
Successful Trade ........................................................................................... 25
8.1.2
Rejected Trade Capture Request (Initiating Party) ....................................... 26
8.1.3
Rejected Trade Capture Request (Counterparty) ......................................... 27
©patsystems
Page 3 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
8.1.4
9.
Cancel Trade Capture Request .................................................................... 28
Example Message Flows of Member Functionality .............................. 29
9.1
Message Flow Summary .......................................................................... 29
9.2
Security Definition ..................................................................................... 29
9.3
Security List .............................................................................................. 30
9.4
Security Status ......................................................................................... 32
9.5
Orders (New, Amend) ............................................................................... 33
9.6
Negotiated Trades .................................................................................... 39
A.
Error Messages and Descriptions .......................................................... 40
B.
Configurable Options................................................................................ 45
C.
Document Control ..................................................................................... 46
©patsystems
Page 4 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
1.
1.1
Overview
Introduction
This document provides the Rules of Engagement (ROE) for FIX 4.4 connectivity
and order entry with MATba. It should be used alongside the corresponding
message definitions document, which provides the message specifications.
The message definitions document also details the data types and field sizes for
each of the FIX Tag=Value pairs.
1.2
Intended Audience
This document is intended for both internal and external use.
The document assumes that the audience has a full understanding of the FIX
protocol as per www.fixprotocol.org.
©patsystems
Page 5 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
2.
FIX Session Guidelines
The Gateway supports FIX 4.4 as defined by the message definitions document.
Only FIX 4.4 sessions will be accepted.
2.1
Session Management
The Gateway:
 Will have a defined start and end time for the FIX session
o A FIX Session can run over midnight
o A FIX Session can run for longer than 24 hours (e.g. 1 week)
 Ensures that sequence numbers are automatically reset at the end of
each FIX session
 Allows sequence numbers to be reset on logon with the use of
ResetSeqNumFlag (141) = Yes (Y)
 Requires that the FIX Server and FIX Client must be time-synched to
avoid fatal time-related errors.
 Will provide all timestamps in UTC
 Is configured as an Acceptor, i.e. the FIX Client must send the initial
Logon request to the Gateway.
2.1.1 Logon
Sessions will be validated against the SenderCompId and TargetCompId stored
in the configuration.
A non-match will result in a disconnection without a logout response.
Authentication of the username and password is required; this is to be provided
in the Logon message (tags 553 and 554).
If logon is not successful a Logout message will be returned indicating the
reason for failure.
If a sequence number is found to be too low, the Gateway will respond with a
Logout message giving the received and expected sequence numbers. The FIX
session will be disconnected.
©patsystems
Page 6 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
2.1.2 Logout
Following successful logon the Gateway will issue a Logout message in the
following circumstances:



On shutdown of the Gateway
At the end of the FIX Session
In response to a Logout message
An appropriate reason will be supplied in the Text (58) field of the Logout
message.
2.1.3 Error Recovery – Disconnection from MATba
On Gateway disconnection:
 The FIX Client will be disconnected
 Sequence numbers will NOT be reset
Logon following a disconnection (Orders connection only):
 Do NOT send a Logon message with ResetSeqNumFlag (141) = Yes
(Y).
 If a transaction has occurred during disconnection on the sell-side:
o The Gateway will have increased the sequence number. On
receiving an increased sequence number the FIX Client must
send a Resend Request for any missed messages, as per FIX
protocol. Messages sent in this manner will have the
PosDupFlag (43) set.
 If a transaction has occurred during disconnection on the buy-side:
o The buy-side must increase sequence numbers for the
transactions that have occurred. The Gateway will send a
Resend Request for these missed transactions
o If the disconnection time was greater than two minutes the
Gateway will reject the messages as stale
o If a message has previously been received the Gateway will
reject the message as duplicate
o If the message has not been previously processed and is not
stale it will be accepted and processed as normal.
2.1.4 Reject Messages
The FIX Client must not respond to any message from the Gateway with a
Session Level Reject (3) or a Business Message Reject (j) message.
©patsystems
Page 7 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
3.
Message Summary
If your application has successfully passed the Patsystems Conformance Test
we would not expect you to receive a Session Level Reject (3) message as a
normal response, however this could also be provided in response to any of the
messages below. This response has not been explicitly listed.
In addition, as per the FIX Protocol, the Business Message Reject (j) message
can reject an application-level message which fulfils session-level rules and
cannot be rejected via any other means. This response has not been explicitly
listed.
Please refer to the message definitions document for details of all messages and
expected responses.
3.1
Admin Messages
Messages sent by the FIX Client and expected responses.
MsgType sent by FIX Client
MsgType response from Gateway
0 – Heartbeat
0 – Heartbeat
Used to confirm connectivity, heartbeat
is not required if an application or pretrade message has been sent instead
0 – Heartbeat
4 – Sequence Reset or
Missed Messages
No Response Required
1 – Test Request
2 – Resend Request
4 – Sequence Reset or
Missed Messages
(in response to 2 – Resend Request)
5 – Logout
A – Logon
3.2
5 – Logout
A - Logon or
5 – Logout
Pre-Trade Messages
Messages sent by the FIX Client and expected responses.
©patsystems
MsgType sent by FIX Client
MsgType response from Gateway
c – Security Definition Request
x – Security List Request
e – Security Status Request
d – Security Definition
y – Security List
f – Security Status
Page 8 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
3.3
Trade Messages
Messages sent by the FIX Client and expected responses.
MsgType sent by FIX Client
MsgType response from Gateway
D – New Order Single
G – Order Cancel/Replace
8 – Execution Report
8 – Execution Report or
9 – Order Cancel Reject
8 – Execution Report
9 – Order Cancel Reject
F – Order Cancel Replace
Request
(used for both single and multi-leg)
AB – New Order Multi-leg
AC – Multi-leg Order
Cancel/Replace
8 – Execution Report
8 – Execution Report
3.3.1 Example Message Flow
Messages sent by the FIX Client and expected responses.
FIX Client
Gateway
New Order Single, 35=D
Execution Report, 35=8
39=0 (New), 150=0 (New)
Execution Report, 35=8
39=1 (Part-Fill), 150=F (Fill)
Execution Report, 35=8
39=E (Pending), 150=E (Pending)
Execution Report, 35=8
39=1 (Part-Fill), 150=5 (Replaced)
Execution Report, 35=8
39=6 (Pending Cancel), 150=6 (Pending
Cancel)
Execution Report, 35=8
39=4 (Cancelled), 150=4 (Cancelled)
Order Cancel/Replace
35=G
Order Cancel
35=F
See FIX Protocol Volume 4 for further message flow examples.
©patsystems
Page 9 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
4.
Additional Information on FIX Fields
This section contains additional information on the use of a number of FIX fields.
4.1
OrdStatus (39) and ExecType (150)
Patsystems does not return Pending New (A) as an OrdStatus (39).
Successful new order messages will be responded to with an Execution Report
showing OrdStatus (39) of New (0).
For multi-leg orders the order status is returned in a single Execution Report
corresponding to the overall strategy.
Patsystems uses standard ExecType (150) values according to the FIX 4.4
specification.
Considering “in flight” modifications, it is worth noting that the marketplace
representation of the state takes precedence.
Please note that for balanced cancelled orders, all partial fills received before the
left over balance is cancelled will have OrderStatus(39) = 4 (Cancelled) and
ExecType(150)=F (partial fill). This is because the overall status of the order is
cancelled as soon as a market order with too much volume gets balance
cancelled.
4.2
ClRefID (6209)
The ClRefID (6209) field is an extension to the FIX Protocol. This field maps to
the Patsystems Reference field which can be viewed from Pro-Mark and JTrader. If a FIX User populates this field this data will be displayed for the order
on the Patsystems GUIs. If a Patsystems GUI populates this field, the data will
be found in ClRefID (6209).
This field can be modified by using an
OrderCancelReplaceRequest.
4.3
Username (553) and Password (554)
If supplying the username and password in the Logon message, Username (553)
needs to be set to the username; and Password (554) needs to be set to the
corresponding password.
©patsystems
Page 10 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
4.4
OnBehalfOfCompID (115) and DeliverToCompID (128)
OnBehalfOfCompID (115) and have DeliverToCompID (128) are not offered with
the gateway standard implementation. They are not required as a router is not
needed for multiple connections into the gateway.
4.5
LegRefID (654)
The LegRefID (654) field holds the value of the leg number that the Execution
Report corresponds to when returning leg fills for strategies.
4.6
CFICode (461)
4.6.1 Futures and Options
The PutOrCall (201) tag has been deprecated as of FIX 4.3 and has been
replaced by the adoption of the CFICode (461), as per the following table:
CFICode (461)
OCXXXX
OPXXXX
FXXXXX
4.7
Description
Standardized Call Option
Standardized Put Option
Standardized Future
Trade Busts
When a trade is busted, depending on whether the original order was fully or part
filled, an execution report message with ExecType (150)=H (Trade Cancel) and
an execution report with ExecType (150)=D (Restated) is sent by the Order
Gateway. If an order is fully filled and then busted, the sender of that order will
receive 2 ER report messages, the first with ExecType (150)=H (Trade Cancel)
and the second message with ExecType (150)=D (Restated) stating that the
cancel is restated (the order is cancelled) because the order was fully filled and
there was no remaining volume for the order. If an order is part-filled and then
busted, the sender of that order will receive 2 ER report messages, the first with
ExecType (150)=H (Trade Cancel) and the second message with ExecType
(150)=D (Restated) stating that the original part fill is reinstated.
©patsystems
Page 11 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
©patsystems
Page 12 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
4.8
ClientID <parties>
The value in PartyID (448) will be stored in the ClientID field:
NoPartyIDs (453) = <Number of repeating parties>
PartyID (448) = <Client identifier>
PartyIDSource (447) = Proprietary/Custom Code (D)
PartyRole (452) = Client ID (3)
4.9
Clearing Account <parties>
The value stored in the Back Office ID for the Trader Account will be returned in
PartyID (448).
NoPartyIDs (453) = <Number of repeating parties>
PartyID (448) = <Patsystems Back Office ID>
PartyIDSource (447) = Proprietary/Custom Code (D)
PartyRole (452) = Clearing Member (4)
It is not possible to set the ClearingAccount (440), attempts to do so will be
rejected.
4.10
Symbology
When referring to a particular contract in any of the message types used in this
interface there is a common symbology adopted for the identification of
contracts. This approach uses the FIX Instrument and Instrument Leg
components.
NOTE: In some message types the interface will support tags 454
(NoSecurityAltID), 455 (SecurityAltID) and 456 (SecurityAltIDSource). The
client does not need to process the values in these tags; Patsystems
recommends that these tags are not used by the client.
4.11
Request Messages Sent from the Client
For any requests sent into the Order Interface from the client, the following
methods for identifying contracts exist. The non-mandatory tags are detailed
from a high level perspective of the interface across all message types, and not
individually for each message type, please refer to the Messages MATba Order
Gateway document for the required tags of each individual message type.
NOTE: For any requests sent to the interface for a strategy contract, the
tags SecurityIDSource (22) and SecurityID (48) must be specified.
Method 1
TAG
146 NoRelatedSym
55 Symbol
©patsystems
Required
For Market Data Request only
Y
Page 13 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
200 MaturityMonthYear
461 CFICode
167 SecurityType
202 StrikePrice
207 SecurityExchange
22 SecurityIDSource
48 SecurityID
555 NoLegs
600 LegSymbol (Repeating Group)
608 LegCFICode (Repeating Group)
609 LegSecurityType (Repeating Group)
610 LegMaturityMonthYear (Repeating Group)
612 LegStrikePrice (Repeating Group)
623 LegRatioQty (Repeating Group)
624 LegSide (Repeating Group)
654 LegRefID (Repeating Group)
Method 2
TAG
146 NoRelatedSym
22 SecurityIDSource
48 SecurityID
Only for FUT and OPT
contracts, not multileg orders
Y
Y
For OPT Contracts only
Y
For strategy contracts only
For strategy contracts only
For Multileg Contracts only
For Multileg Contracts only
For Multileg Contracts only
For Multileg Contracts only
For Multileg Contracts only
For Multileg OPT Contracts
only
For Multileg Contracts only
For Multileg Contracts only
For Multileg Contracts only
Required
For Market Data Request only
Y
Y
NOTE: When using the Method 2 (using tags SecurityIDSource<22> and
SecurityID<48> fields) for request messages, the required Symbol<55>
field have to be set to value “[N/A]”.
4.11.1 Reply Messages Sent from the Interface
The security list (y) and security definition (d) messages will return all supported
tags for each message type as detailed in the Messages External Member
Gateway document as appropriate for each contract type. Note that this is with
the exception of tag ContractMultiplier (231), if this tag is not sent from the Order
Interface clients should assume a value of 1, any other value will result in it being
specified in the message to the client.
The below tables details all supported symbology fields and their description.
Futures
FIX Tag
55 Symbol
461 CFICode
167 SecurityType
200 MaturityMonthYear
541 MaturityDate
231 ContractMultiplier
207 SecurityExchange
©patsystems
Description
Example
(Gold Jun 2010 Contract)
Commodity Code
CFI Code
Security Type
Expiry of Future
Expiry date of the contract
Multiply factor of contract
Exchange ISO Code
55=CMGLD
461=FXXXXX
167=FUT
200=201006
541=20100615
231=1
207=XMTB
Page 14 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
48 SecurityID
22 SecurityIDSource
Unique Reference
Contract
Source of Reference
for
48=MATBA/CMGLD/JUN10
22=102
Options
FIX Tag
55 Symbol
461 CFICode
167 SecurityType
200 MaturityMonthYear
541 MaturityDate
231 ContractMultiplier
202 StrikePrice
207 SecurityExchange
48 SecurityID
22 SecurityIDSource
Description
Example
(Gold Sep 2010 101.25
Call Contract)
Commodity Code
CFI Code
Security Type
Expiry of Future
Expiry date of the contract
Multiply factor of contract
Strike Price
Exchange ISO Code
Unique Reference for
Contract
Source of Reference
55=CMGLD
461=OCXXXX
167=OPT
200=201009
541=20100915
231=1
202=101.25
207=XMTB
48=MATBA/CMGLD/JUN10
100.25 C
22=102
Description
Example
(Gold Jun 2010 Dec 2010
Calendar Spread
Contract)
Commodity Code
CFI Code
Security Type
Expiry date of the contract
Multiply factor of contract
Exchange ISO Code
Unique Reference for
Contract
Source of Reference
No of Legs
Leg Symbol
Leg CFI Code
Leg Security Type
Leg Expiry
Leg Qty Ratio
Leg Side
Leg Ref ID
Leg Symbol
Leg CFI Code
Leg Security Type
Leg Expiry
Leg Qty Ratio
Leg Side
Leg Ref ID
55=CMGLD
461=FXXXXX
167=MLEG
541=20100615
231=1
207=XMTB
48=MATBA/CMGLD/JUN10D
EC10 SPRD
22=102
555=2
600=GLD
608=FXXXXX
609=FUT
610=201006
623=1
624=1
654=1
600=GLD
608=FXXXXX
609=FUT
610=201012
623=1
624=2
654=2
MultiLeg Futures
FIX Tag
55 Symbol
461 CFICode
167 SecurityType
541 MaturityDate
231 ContractMultiplier
207 SecurityExchange
48 SecurityID
22 SecurityIDSource
555 NoLegs
600 LegSymbol
608 LegCFICode
609 LegSecurityType
610 LegMaturityMonthYear
623 LegRatioQty
624 LegSide
654 LegRefID
600 LegSymbol
608 LegCFICode
609 LegSecurityType
610 LegMaturityMonthYear
623 LegRatioQty
624 LegSide
654 LegRefID
©patsystems
Page 15 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
MultiLeg Options
FIX Tag
55 Symbol
461 CFICode
167 SecurityType
541 MaturityDate
231 ContractMultiplier
207 SecurityExchange
48 SecurityID
555 NoLegs
600 LegSymbol
608 LegCFICode
609 LegSecurityType
610 LegMaturityMonthYear
612 LegStrikePrice
623 LegRatioQty
624 LegSide
654 LegRefID
600 LegSymbol
608 LegCFICode
609 LegSecurityType
610 LegMaturityMonthYear
612 LegStrikePrice
623 LegRatioQty
624 LegSide
654 LegRefID
4.12
Description
Example
Gold Sep 2010 101.25 /
104.50 Call Spread
Contract
Commodity Code
CFI Code
Security Type
Expiry date of the contract
Multiply factor of contract
Exchange ISO Code
Unique Reference for
Contract
No of Legs
Leg Symbol
Leg CFI Code
Leg Security Type
Leg Expiry
Leg Strike Price
Leg Qty Ratio
Leg Side
Leg Ref ID
Leg Symbol
Leg CFI Code
Leg Security Type
Leg Expiry
Leg Strike Price
Leg Qty Ratio
Leg Side
Leg Ref ID
55=CMGLD
461=OMXXXX
167=MLEG
541=20100915
231=1
207=XMTB
48=MATBA/CMGLD/JUN10
100.25 100.50 CSPRD
555=2
600=GLD
608=OCXXXX
609=OPT
610=201009
612=101.25
623=1
624=1
654=1
600=GLD
608=OCXXXX
609=OPT
610=201009
610=104.50
623=1
624=2
654=2
Order Types Matrix
The table below details the supported order types and the required FIX Tags and
Values.
©patsystems
Page 16 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
PATS Order Type
Price (44) Stop Price (99) OrdType (40)
Tim eIn
ExpireDate (432)
Force (59)
Market Fill Or Kill
1 (Market )
4 (FillOrKill)
Market At Best Fill or Kill
1 (Market)
4 (FillOrKill)
Market Fill and Kill
1 (Market)
TargetStra
PegLim itT TargetStra
tegyParam
Floor (111) ype (837) tegy (847) eters(848)
Max
0 (At Best)
3 (Immediate
OrCancel)
Market At Best Fill and Kill
1 (Market)
3 (Immediate
0 (At Best)
OrCancel)
K
(MarketWithLeftO 0 (Day)
verLimit)
K
(MarketWithLeftO 0 (Day)
verLimit)
Market to Limit (at w orst)
Market At Best to Limit
StopMarket
Y
3 (Stop)
Stop GTC
Y
3 (Stop)
2 (At
Worst)
0 (At Best)
0 (Day)
1 (GoodTill
Cancel)
Stop GTD
Y
3 (Stop)
6 (GoodTill
Y
Date)
Stop (Market at Best)
Y
3 (Stop)
Stop GTC (Market at Best)
Y
3 (Stop)
0 (Day)
0 (At Best)
1 (GoodTill
0 (At Best)
Cancel)
Stop GTD (Market at Best)
Y
3 (Stop)
6 (GoodTill
Y
0 (At Best)
Date)
Limit FOK
Y
2 (Limit)
Limit FAK
Y
2 (Limit)
Limit
Y
2 (Limit)
Limit GTC
Y
2 (Limit)
4 (FillOrKill)
3 (Immediate
OrCancel)
0 (Day)
1 (GoodTill
Cancel)
Limit GTD
Y
2 (Limit)
6 (GoodTill
Y
Date)
Stop Limit
Y
Y
4 (StopLimit)
Stop Limit GTC
Y
Y
4 (StopLimit)
0 (Day)
1 (GoodTill
Cancel)
Stop Limit GTD
Y
Y
4 (StopLimit)
6 (GoodTill
Y
Date)
Iceberg
Y
Stop Limit Iceberg
Y
On close
Y
2 (Limit)
0 (Day)
Y
Y
Y
4 (StopLimit)
0 (Day)
Y
Y
Y
1 (Market)
7 (at the
Close)
MIF (Market In Fixing)
1 (Market)
at the
Opening (2)
LIF (Limit In Fixing)
Y
2 (Limit)
Y
J (Market If
Touched)
at the
Opening (2)
MIF (Market If Touched)
©patsystems
0 (Day)
Page 17 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
4.13
Persistent vs. Non-Persistent Message States
The table below shows a list of the FIX message types that will be persisted in
the system, all message types not mentioned here will not have a persisted state
in the system.
Message Type
State Persisted
Execution Report (8)
Y
Trade Capture Report Request (AD)
Y
Trade Capture Report (AE)
Based off Execution Reports
New Order Single (D)
4.14
Y
Trade Capture Report Party Role Filtering
The following rules apply to Party Roles received on buyside and sellside
for Trade Capture Reports on the MATba Orders Gateway:
For the buy side, the TCR contains only the Member Buyer:
i.e. (on buy side):
(on sell side):
buy userid, buy account, buy trading firm
only sell trading firm (as contra)
For the sell side, TCR contains only Member Seller:
i.e. (on buy side) only buy trading firm (as contra)
(on sell side) sell userid, sell account, sell trading firm
If an account trades against itself, or with another member in the same TAG, the
TCR contains both Member Seller and Member Buyer:
i.e (on buy side) buy userid, buy account, buy trading firm
(on sell side) sell userid, sell account, sell trading firm
4.15
Timestamps
Section 4.11 aims to explain the sources of the various timestamps received in
FIX messages in the system. Please note that the various components of the
MATba system are not time synchronized. It is possible to receive messages in
the wrong order and these would need to be re-sequenced.
Client timestamps:
©patsystems
Page 18 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Tag 52 represents the local machine time at which the client sends a FIX
message. Tag 52 is usually the same as Tag 60 when coming from the client.
Server Timestamps:
Tag 52 represents the local machine time at which the gateway sends a FIX
message. Tag 52 is not the same as tag 60 in the gateway response. For an
acknowledgement or a reject tag 60 will be the time of the transaction from the
GT core. For fill messages tag 60 will not be the GT core timestamp, but rather
the exchange timestamp when the match was done.
Market Data:
For market data messages, SendingTime (52) is the local machine time when
the gateway sent out the message to the client. TransactTime (60) is the last
timestamp of the Market Data Update received from the PDD. Any market data
update will always update the timestamp within the FIXHub for that market and
this is what is sent out to the client when requested.
4.16
Balance Cancelled Orders/Order Sequencing
For order updates and fills within the system, the final order state will be received
in an ER report with subsequent fills. This final order state ER (e.g. balanced
cancelled) will contain no average price tag and will also contain tag 14 which
will indicate the number of fills received. Each of the fill update messages
individually contains the average price.
Also contained within the messages is an indication of the sequence for each
update produced on the order/fill itself. This is always recorded in tag 17, e.g.
from the messages below 17=546723-2 for Limit Order New message sequence
and 17=546723-3 for the Limit Fill update.
The syntax of the sequence number for tag 17 is as follows:
<PATSOrderNumber>-<OrderSequenceNumberOutput>
The PATSOrderNumber is the Order Number assigned to the particular order
from within GT. This will be the same value as tag 37.
The OrderSequenceNumberOutput number will always begin with the value of 2
for tag 17 as this is the first recorded output update sent to a client.
In conjunction with the contents of tag 17, the execution report should also
continue to contain all the require information relating to the order update or the
fill, e.g. tags 14, 38, 151, 39,150, etc.
©patsystems
Page 19 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
5.
Amendments via FIX
5.1
Amendments via FIX
Amendments via FIX are requested via the OrderCancelReplaceRequest
message, as per FIX Protocol.
MATba supports the amendment of the following fields:
FIX Field
Account (1)
Description
Trader Account
OrderQty (38)
Quantity of the order.
The amendment will be rejected if the OrderQty (38) is
less than the LeavesQty (151)
Amendment of Limit Price, if originally specified on the
order
Amendment of Stop Price, if originally specified on the
order
Amendment of Clip Size, if originally specified on the
order
Amendment of Expiry Date of a GTD, if originally
specified on the order
Amendment of the order trigger time, if originally
specified on the order and if the trigger time has not
passed.
Price (44)
StopPx (99)
MaxFloor (111)
ExpireDate (432)
EffectiveTime (168)
©patsystems
Page 20 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
6.
6.1
Execution Reports
Single-leg Fill Reports
Execution Reports for single leg orders do not contain the
MultiLegReportingType (442) tag. The symbol instrument fields will be returned
as per the original order. The fill price and volume are in the LastPx (31) and
LastQty (32) fields respectively.
6.2
Unsolicited Execution Reports
Transactions that originate from MATba Admin (e.g. Exchange Cancel,
Exchange Trigger) are considered to be ‘unsolicited’.
These transactions are sent with ExecType (150) set to Restated (D). Tag
ExecRestatementReason (378) will also be set, as per FIX Protocol.
6.3
Orders not Originating from FIX
Orders that originate from sources external to the FIX connection will not have
ExecType (150) set to Restated (D).
The ClOrdID (11) will contain a maximum of thirty-five characters made up of the
following:
Data
Type
Size
Default
Configurable Value
PATS Order ID
ALPHANUMERIC
NUMERIC
Up to 5
XMTB
Up to 10
7
Incrementing
Counter
NUMERIC with
leading zeroes
10
Starts at 1
Example:
8=FIX.4.4|9=609|35=8|34=120|49=MATBA|52=2011041910:33:53.304|56=MEMBER|57=USERA|1=ACC1|6=85.1200000000000|11=XMT
B872441|14=5|15=TRY|17=b7754b4ac7d34ee29550e645987f8492|22=102|30=XMTB|3
1=85.12|32=3|37=87244|38=5|39=2|40=2|44=85.12|48=MATBA/CMGLD/JUL11|
54=2|55=CMGLD|58=MATBA 20
20:87244
201104191310|59=0|60=2011041910:33:27.000|77=O|150=F|151=0|167=FUT|198=20:87244|200=201107|207=XM
TB|461=FXXXXX|527=20.3372220447|541=20110702|453=3|448=ACC1|447=D
|452=38|448=ACC1|447=D|452=24|448=USERA|447=D|452=12|454=1|455=F
EXP
20110700
|456=103|10=195
©patsystems
Page 21 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
In order for Notice of Execution systems to identify the order, the ClOrdID (11)
will not change and the OrigClOrdId (41) will not be returned.
Amends and Cancels performed via FIX would require a new unique ClOrdID
(11) and OrigClOrdId (41) would need to refer to the previous successful
ClOrdID (11).
6.4
Triggering Order Types
Orders that trigger, for example StopLimit will be acknowledged with an
Execution Report containing WorkingIndicator (636) set to not working (N). Once
the Order Type has been triggered another Execution Report will be returned,
this time with WorkingIndicator (636) set to working (Y).
6.5
End of Session
At the end of a Session any day orders that have expired will no longer be
working at the Exchange.
It is the FIX Client’s responsibility to ensure that all Day orders have been
expired at the End of Session.
6.6
Identifying the Counterparty
If the exchange returns the Counterparty that the trade occurred with, this will be
notified using the parties block as follows:
NoPartyIDs (453) = <Number of repeating parties>
PartyID (448) = <Counterparty>
PartyIDSource (447) = Proprietary/Custom Code (D)
PartyRole (452) = ContraFirm (17)
©patsystems
Page 22 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
7.
Pre-Trade Requests
7.1
Security Definitions
Contract Dates can be requested using a Security Definition Request
SecurityRequestType (321) must be set to Request List of Securities (3).
Security Definitions can be returned for all Contract Types. Multi-leg contracts
include leg information. LegSide (624) and LegRatioQty (623) are important in
identifying the strategy.
A standard Calendar Spread has a ratio of 1:1, this is the equivalent of
LegRatioQty (623) = 1.
A standard Calendar Spread buys the front month and sells the back month, this
is the equivalent of LegSide (624) = Buy (1) for the first leg in the repeating group
and LegSide (624) = Sell (2) for the second leg in the repeating group.
For strategies the repeating group specifies the strategy, therefore you buy or
sell the strategy using Side (54). Do not modify the LegSide (624) in order to sell
the strategy, instead keep the repeating group leg information the same and set
Side (54) = Sell (2).
7.2
Security Status
The Security Status corresponds to the Market Status sent by the Exchange.
The Security Status Request message provides the ability to request the status
of a security. The Security Status message provides the information regarding a
security and changes in status to a security (if a snapshot+updates subscription
is made). Tag 48 (SecurityID) and tag 22 (SecurityIDSource) can be used to
specify the security.
The Security Status message received upon making a Security Status Request
will contain the mandatory tag 326 (SecurityTradingStatus) which will have the
following possible values indicating the status of the quoted instrument:
2
17
20
21
26
400
©patsystems
Trading Halt (suspended)
Ready to Trade Start of Session (open)
Unknown or Invalid
Pre Open
Closed
Fixing Session
Page 23 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
7.3
Security List
The Security List Request message is used to return a list of securities from the
counterparty that match criteria provided on the request. The Security List
message is used to return a list of securities that matches the criteria specified in
a Security List Request. In the Security List Request message the only allowed
request is for all securities. Tag 559 (SecurityListRequestType) = 4 (All
Securities).
©patsystems
Page 24 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
8.
8.1
Negotiated Trades
One-sided Party Matching Ticket
This method is used to support an initiating party inputting one side of the trade
via a single-sided trade ticket receiving a reference from the exchange, and then
the counterparty submits a single-sided trade ticket including the exchange
reference to obtain a match.
A deal is typically struck between two parties, one of whom has an obligation to
report the trade. The counterparty has an agreement with the reporting party.
The initiating party sends the trade report to the market. The marketplace
accepts the report and responds with a reference. The counterparty sends a
trade report to the market with the reference. The marketplace confirms the
Confirmed Trade to all involved parties.
8.1.1 Successful Trade
1. Trade Capture Report
(New – One-Party Matching)
Initiating
Party
2. Trade Capture Report Ack
(New – One-Party Matching)
4. Trade Capture Report
(Replaced – Trade Confirm)
TurkDEX
3. Trade Capture Report
(New – One-Party Matching)
Counterparty
4. Trade Capture Report
(Replaced – Trade Confirm)
1. Initiating party submits a Trade Capture Report (TCR):
TradeReportID (571) = <New Unique Identifier>
TradeReportType (856) = SUBMIT (0)
OrderID (37) = <Random Value>
©patsystems
Page 25 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
2. On validation, the exchange returns a Trade Capture Report Ack:
TradeReportID (571) = <Unique Identifier from the TCR>
TradeReportTransType (487) = NEW (0)
TradeReportType (856) = SUBMIT (0)
TrdRptStatus (939) = ACCEPT (0)
TradeMatchID (880) = <Exchange Reference>
3. Counterparty submits a Trade Capture Report (TCR):
TradeReportID (571) = <New Unique Identifier>
TradeReportType (856) = SUBMIT (0)
TradeMatchID (880) = <Exchange Reference>
4. If the Exchange accepts and matches the trade, a Trade Capture Report is
returned to both the Initiating Party and the Counterparty:
TradeReportID (571) = <Unique Identifier from the TCR>
TradeReportTransType (487) = REPLACE (2)
TradeReportType (856) = SUBMIT (0)
ExecType (150) = TRADE (F)
8.1.2 Rejected Trade Capture Request (Initiating Party)
1. Trade Capture Report
(New – One-Party Matching)
Initiating
Party
2. Trade Capture Report Ack
(New – Two-Party Report)
TurkDEX
1. Initiating party submits a Trade Capture Report (TCR):
TradeReportID (571) = <New Unique Identifier>
TradeReportType (856) = SUBMIT (0)
OrderID (37) = <Random Value>
2. On rejection, the exchange returns a Trade Capture Report Ack:
TradeReportID (571) = <Unique Identifier from the TCR>
TradeReportTransType (487) = NEW (0)
TradeReportType (856) = SUBMIT (0)
TrdRptStatus (939) = REJECT (1)
The Trade Capture Report has been rejected and if still required must be
resubmitted.
©patsystems
Page 26 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
8.1.3 Rejected Trade Capture Request (Counterparty)
1. Trade Capture Report
(New – One-Party Matching)
Initiating
Party
2. Trade Capture Report Ack
(New – Two-Party Report)
TurkDEX
3. Trade Capture Report
(New – One-Party Matching)
Counterparty
4. Trade Capture Report Ack
(New – Two-Party Report)
1. Initiating party submits a Trade Capture Report (TCR):
TradeReportID (571) = <New Unique Identifier>
TradeReportType (856) = SUBMIT (0)
OrderID (37) = <Random Value>
2. On acknowledgement from the exchange a Trade Capture Report Ack is
returned:
TradeReportID (571) = <Unique Identifier from the TCR>
TradeReportTransType (487) = NEW (0)
TradeReportType (856) = SUBMIT (0)
TrdRptStatus (939) = ACCEPT (0)
TradeMatchID (880) = <Exchange Reference>
3. Counterparty submits a Trade Capture Report (TCR):
TradeReportID (571) = <New Unique Identifier>
TradeReportType (856) = SUBMIT (0)
TradeMatchID (880) = <Exchange Reference>
4. If the Exchange rejects the Counterparty submission, a Rejection Trade
Capture Report Ack will be returned:
TradeReportID (571) = <Unique Identifier from the TCR>
TradeReportTransType (487) = NEW (0)
TradeReportType (856) = SUBMIT (0)
TrdRptStatus (939) = REJECT (1)
The Counterparty may then attempt to submit a matching TCR.
©patsystems
Page 27 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
8.1.4 Cancel Trade Capture Request
It is only possible to cancel the Trade Capture Request from the Initiating Party;
any other cancellations must be done at the Exchange.
1. Trade Capture Report
(New – One-Party Matching)
2. Trade Capture Report Ack
(New – Two-Party Report)
Initiating
Party
TurkDEX
3. Trade Capture Report
(Cancel – One-Party Matching)
4. Trade Capture Report Ack
(Cancel – Two-Party Report)
1. Initiating party submits a Trade Capture Report (TCR):
TradeReportID (571) = <New Unique Identifier>
TradeReportType (856) = SUBMIT (0)
OrderID (37) = <Random Value>
2. An appropriate message is sent to the exchange. On acknowledgement from
the exchange, a Trade Capture Report Ack is received:
TradeReportID (571) = <Unique Identifier from the TCR>
TradeReportTransType (487) = NEW (0)
TradeReportType (856) = SUBMIT (0)
TrdRptStatus (939) = ACCEPT (0)
3. Initiating party submits a Trade Capture Report (TCR) to cancel the trade:
TradeReportID (571) = <New Unique Identifier>
TradeReportRefID (572) = < Unique Identifier from the TCR >
TradeReportType (856) = CANCEL (6)
OrderID (37) = <Random Value>
4. Trade Capture Report Ack:
TradeReportID (571) = <Unique Identifier from the TCR>
TradeReportTransType (487) = CANCEL (1)
TradeReportType (856) = CANCEL (6)
TrdRptStatus (939) = ACCEPT (0) or REJECT (1)
©patsystems
Page 28 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
9.
9.1
Example Message Flows of Member Functionality
Message Flow Summary
This section will show the example message flows that map to Member
functionality. Each example will detail the order flow, sender and receiver of each
message type and the FIX message itself. The list of functional areas where
examples will be provided for are as follows:






Security Definition
Security List
Security Status
Orders
Negotiated Trades
Advertised Orders
Note that only examples of FIX messages will be provided in this document,
some examples will not show all supported FIX Tags or the supported values.
For a full specification on the FIX Order message types, supported tags and the
supported values, please see the MATba Order FIX API Messages document.
9.2
Security Definition
Supported Message Types
Message Type
SecurityDefinitionRequest (c)
SecurityDefinition (d)
Description
Used to request a security definition for a particular
contract or number of contracts based on the criteria
provided in the request message.
Sent in reply to a security definition request message,
the security definition message specifies an individual
contract.
Example Message Flow and FIX Message
Security Definition Request - Snapshot
Steps
1
2
©patsystems
Member
Member Gateway
SecurityDefinitionRequest (c)
Snapshot only
SecurityDefinition (d)
JUN10 Future
Page 29 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
SecurityDefinition (d)
JUN10/DEC10 Spread
3
FIX Message at step 1:
8=FIX.4.4|9=237|35=c|49=MEMBER|50=USERA|56=MATBA|34=192|52=20100
42712:05:21.101|320=1|321=3|55=CMGLD|263=0|10=4
FIX Message at step 2:
8=FIX.4.4|9=237|35=d|49=MATBA|56=MEMBER|34=193|52=2010042712:05:22.
004|320=1|322=912|323=1|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200
=201006|541=20100615|461=FXXXXX|167=FUT|207=XMTB|10=4
FIX Message at step 3:
8=FIX.4.4|9=237|35=d|49=MATBA|56=MEMBER|34=194|52=2010042712:05:22.
004|320=1|322=912|323=1|55=CMGLD|48=MATBA/CMGLD/JUN10DEC10
SPRD|22=102|461=MXXXXX|167=MLEG|541=20100615|207=XMTB|555=2|600
=GLD|602=MATBA/CMGLD/JUN10|603=102|608=FXXXXX|609=FUT|610=2010
06|623=1|624=1|600=GLD|602=MATBA/CMGLD/DEC10|603=102|608=FXXXXX
|609=FUT|610=201012|623=1|624=2|10=4
9.3
Security List
Supported Message Types
Message Type
SecurityListRequest (x)
SecurityList (y)
Description
The Security List Request message is used to return a list
of securities from the counterparty that match criteria
provided on the request
The Security List message is used to return a list of
securities that matches the criteria specified in a Security
List Request.
Example Message Flow and FIX Message
Security List - Snapshot
Steps
1
2
©patsystems
Member
MATba
SecurityListRequest (x)
Snapshot only
SecurityList (y)
Page 30 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
FIX Message at step 1:
8=FIX.4.4|9=237|35=x|49=MEMBER|50=USERA|56=MATBA|34=9|52=2010022
0-09:05:20.123|320=6|559=4|263=0|10=2
FIX Message at step 2:
8=FIX.4.4|9=237|35=y|49=MATBA|56=MEMBER|34=10|52=2010022009:05:20.123|320=6|322=1|560=0|393=2|146=2|55=CMGLD|48=MATBA/CMGL
D/MAR11|22=102|200=201103|461=FXXXXX|167=FUT|207=XMTB|541=201103
15|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200=201006|461=FXXXXX|
167=FUT|207=XMTB|541=20100615|10=2
Note: For security list requests for options, the underlying future contract
details will be returned in in the Underlying Instrument group: tags 711,
311, 463, 313, 542, 316, 308 will be populated in the 35=y message.
Example Message Flow and FIX Message
Security List – Snapshot + Updates
Steps
1
Member
MATba
SecurityListRequest (x)
Snapshot + Updates
2
SecurityList (y)
3
SecurityList (y)
Sent as new contracts are listed
FIX Message at step 1:
8=FIX.4.4|9=237|35=x|49=MEMBER|50=USERA|56=MATBA|34=9|52=2010022
0-09:05:20.123|320=6|559=4|263=1|10=2
FIX Message at step 2:
8=FIX.4.4|9=237|35=y|49=MATBA|56=MEMBER|34=10|52=2010022009:05:20.123|320=6|322=1|560=0|393=2|146=2|55=CMGLD|48=MATBA/CMGL
D/MAR11|22=102|200=201103|461=FXXXXX|167=FUT|207=XMTB|541=201103
15|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200=201006|461=FXXXXX|
167=FUT|207=XMTB|541=20100615|10=2
FIX Message at step 3:
8=FIX.4.4|9=237|35=y|49=MATBA|56=MEMBER|34=11|52=2010022009:06:10.123|320=6|322=2|560=0|393=1|146=1|55=CMGLD|48=MATBA/CMGL
D/JUN11|22=102|200=201106|461=FXXXXX|167=FUT|207=XMTB|541=201106
15|10=2
©patsystems
Page 31 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Note: For security list requests for options, the underlying future contract
details will be returned in in the Underlying Instrument group: tags 711,
311, 463, 313, 542, 316, 308 will be populated in the 35=y message.
9.4
Security Status
Supported Message Types
Message Type
SecurityStatusRequest(e)
SecurityStatus(f)
Description
The Security Status Request message provides for the
ability to request the status of a security.
The Security Status message provides for the ability to
report changes in status to a security
Example Message Flow and FIX Message
Security Status – Snapshot
Steps
1
Member
MATba
SecurityStatusRequest (e)
Snapshot only
SecurityStatus(f)
2
FIX Message at step 1:
8=FIX.4.4|9=237|35=e|49=MEMBER|50=USERA|56=MATBA|34=3|52=2010022
009:05:20.123|324=5|263=0|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200
=201006|461=FXXXXX|167=FUT|207=XMTB|10=2
FIX Message at step 2:
8=FIX.4.4|9=237|35=f|49=MATBA|56=MEMBER|34=4|52=2010022009:05:21.123|324=5|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200=2010
06|461=FXXXXX|167=FUT|207=XMTB|326=17|60=2010022009:05:21.123|10=2
Example Message Flow and FIX Message
Security Status – Snapshot + Updates
Steps
©patsystems
Member
MATba
Page 32 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
1
SecurityStatusRequest(e)
Snapshot + Updates
2
SecurityStatus(f)
3
SecurityStatus(f)
Sent as update occurs
to security status
FIX Message at step 1:
8=FIX.4.4|9=237|35=e|49=MEMBER|50=USERA|56=MATBA|34=3|52=2010022
009:05:20.123|324=5|263=1|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200
=201006|461=FXXXXX|167=FUT|207=XMTB|10=2
FIX Message at step 2:
8=FIX.4.4|9=237|35=f|49=MATBA|56=MEMBER|34=4|52=2010022009:05:21.123|324=5|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200=2010
06|461=FXXXXX|167=FUT|207=XMTB|326=17|60=2010022009:05:21.123|10=2
FIX Message at step 3:
8=FIX.4.4|9=237|35=f|49=MATBA|56=MEMBER|34=5|52=2010022018:00:00.004|324=5|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200=2010
06|461=FXXXXX|167=FUT|207=XMTB|326=26|60=2010022018:00:00.004|10=2
9.5
Orders (New, Amend)
Supported Message Types
Message Type
NewOrderSingle (D)
OrderCancelReplaceRequest
(G)
ExecutionReport (8)
OrderCancelRequest (F)
OrderCancelReject (9)
©patsystems
Description
Used to submit orders for execution.
Used to request modification of an order.
Used to confirm/reject an order, when placed
or amended. It is also used to report fills and
order status changes.
Used to request the cancel of an order
previously placed by the member
Used to reject the OrderCancelRequest
message sent by the member.
Page 33 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
New Order Example Message Flow and FIX Message
Example showing new order entered at the exchange that is not filled
instantly.
Steps
1
Member
Member Gateway
NewOrderSingle (D)
ExecutionReport (8)
Order Status = New
ExecType =New
2
FIX Message at step 1:
8=FIX.4.4|9=219|35=D|49=MEMBER|56=MATBA|34=5|50=USERA|52=2011031
413:54:08.511|11=FIX31714|1=ACCOUNT1|55=[N/A]|48=MATBA/CMWHT/MAR1
1|22=102|461=FXXXXX|207=XMTB|54=1|60=2011031413:54:08.511|38=1|40=2|44=0.7050|59=0|10=121
FIX Message at step 2:
8=FIX.4.4|9=498|35=8|34=5|49=MATBA|52=2011031413:54:08.639|56=MEMBER|57=USERA|1=ACCOUNT1|6=0|11=FIX31714|14=0|
15=TRY|17=31cc35732a324f41a402ae8a028419742|22=102|37=55646|38=1|39
=0|40=2|44=0.705|48=MATBA/CMWHT/MAR11|54=1|55=CMWHT|59=0|60=201
1031413:54:08.613|77=O|150=0|151=1|167=FUT|198=11:55646|200=201103|207=XM
TB|461=FXXXXX|541=20110331|453=3|448=ACCOUNT1|447=D|452=38|448=A
CCOUNT1|447=D|452=24|448=USERA|447=D|452=12|454=1|455=F
WHT
20110300
|456=103|10=096
New Order Example Message Flow and FIX Message
Example showing new order entered, partially filled and then fully filled at
the exchange.
Steps
1
2
©patsystems
Member
Member Gateway
NewOrderSingle (D)
ExecutionReport (8)
Order Status = New
ExecType =New
Page 34 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
3
ExecutionReport (8)
Order Status = Partially Filled
ExecType =Trade (partial fill or fill)
4
ExecutionReport (8)
Order Status = Filled
ExecType =Trade (partial fill or fill)
FIX Message at step 1:
8=FIX.4.4|9=220|35=D|49=MEMBER|56=MATBA|34=14|50=USERA|52=201103
1413:58:24.467|11=FIX31723|1=ACCOUNT1|55=[N/A]|48=MATBA/CMWHT/MAR1
1|22=102|461=FXXXXX|207=XMTB|54=2|60=2011031413:58:24.477|38=4|40=2|44=0.7050|59=0|10=189
FIX Message at step 2:
8=FIX.4.4|9=499|35=8|34=14|49=MATBA|52=2011031413:58:24.502|56=MEMBER|57=USERA|1=ACCOUNT1|6=0|11=FIX31723|14=0|
15=TRY|17=451f52ca84084f519e0f406851e2f06f2|22=102|37=55647|38=4|39=
0|40=2|44=0.705|48=MATBA/CMWHT/MAR11|54=2|55=CMWHT|59=0|60=2011
031413:58:24.477|77=O|150=0|151=4|167=FUT|198=11:55647|200=201103|207=XM
TB|461=FXXXXX|541=20110331|453=3|448=ACCOUNT1|447=D|452=38|448=A
CCOUNT1|447=D|452=24|448=USERA|447=D|452=12|454=1|455=F
WHT
20110300
|456=103|10=240
FIX Message at step 3:
8=FIX.4.4|9=591|35=8|34=16|49=MATBA|52=2011031413:58:24.864|56=MEMBER|57=USERA|1=ACCOUNT1|6=0.705000000000000|1
1=FIX31723|14=1|15=TRY|17=b9412e22652544198b0eb469227b3388|22=102|
31=0.705|32=1|37=55647|38=4|39=1|40=2|44=0.705|48=MATBA/CMWHT/MAR
11|54=2|55=CMWHT|58=MATBA
101
11:55647
201103147|59=0|60=2011031413:58:24.477|77=O|150=F|151=3|167=FUT|198=11:55647|200=201103|207=XM
TB|461=FXXXXX|541=20110331|453=3|448=ACCOUNT1|447=D|452=38|448=A
CCOUNT1|447=D|452=24|448=USERA|447=D|452=12|454=1|455=F
WHT
20110300
|456=103|10=136
FIX Message at step 4:
8=FIX.4.4|9=591|35=8|34=17|49=MATBA|52=2011031413:58:24.909|56=MEMBER|57=USERA|1=ACCOUNT1|6=0.705000000000000|1
1=FIX31723|14=4|15=TRY|17=08e230bdf79e43bf8d34b24a60487994|22=102|3
1=0.705|32=3|37=55647|38=4|39=2|40=2|44=0.705|48=MATBA/CMWHT/MAR1
1|54=2|55=CMWHT|58=MATBA
102
11:55647
201103147|59=0|60=2011031413:58:24.477|77=O|150=F|151=0|167=FUT|198=11:55647|200=201103|207=XM
TB|461=FXXXXX|541=20110331|453=3|448=ACCOUNT1|447=D|452=38|448=A
©patsystems
Page 35 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
CCOUNT1|447=D|452=24|448=USERA|447=D|452=12|454=1|455=F
20110300
|456=103|10=084
WHT
New Iceberg Order Example Message Flow and FIX Message
Example showing new iceberg order entered at the exchange that is not
filled instantly.
Steps
1
Member
Member Gateway
NewOrderSingle (D)
2
ExecutionReport (8)
Order Status = New
Exec Type = New
In order to place an Iceberg Order, Tag 847=1001 and Tag 848
(TargetStrategyParameters) need to be specified in the message.
TargetStrategyParameters (848) Tag contains values for strategy parameters
which are randomize, max clip size, and min clip size.
These are delimited by a ';'.
RAN = N (Randomise) or RAN = Y (Randomise)
MxCS = >0 (Max Clip Size)
MiCS = same as MxCS (Min Clip Size)
FIX Message at step 1:
8=FIX.4.4|9=300|35=D|49=MEMBER|56=MATBA|34=20|50=USERNAME|52=20
11011412:49:21.822|11=Order5265|1=ACCOUNT|55=[N/A]|48=MATBA/CMWHT/MAR1
1|22=102|207=XMTB|54=2|60=2011011412:49:21.822|38=7|40=2|44=0.553|59=0|847=1001|848=957:3;958:MxCS;959:7
;960:4;958:MiCS;959:7;960:4;958:RAN;959:13;960:N;|10=176
FIX Message at step 2:
|8=FIX.4.4|9=594|35=8|34=32|49=MATBA|52=2011011412:49:22.179|56=MEMBER|57=USERNAME|1=ACCOUNT|6=0|11=Order5265|1
4=0|15=TRY|17=7f35495317734ac8ab9622de7bdb3dca2|22=102|37=83115|38=
7|39=0|40=2|44=0.553|48=MATBA/CMWHT/MAR11|54=2|55=CMWHT|59=060=
2011011412:49:22.115|77=O|150=0|151=7|167=FUT|198=9:83115|200=201103|207=XMT
B|461=FXXXXX|541=20110331|847=1001|848=957:3;958:MxCS;959:7;960:4;9
58:MiCS;959:7;960:4;958:RAN;959:13;960:N;|453=3|448=BIM2_HA2|447=D|4
52=38|448=BIM2_HA2|447=D|452=24|448=BIM2_FIX2|447=D|452=12|454=2|45
5=WHTF1103|456=8|455=F
WHT
20110300|456=103|10=036
©patsystems
Page 36 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
In the messages above Tag 848 is expressed as:
957 = 3
958:MxCS;959:7;960:4; (Max Clip Size = 4)
958:MiCS;959:7;960:4
(Min Clip Size = 4)
958:RAN;959:13;960:N (No Randomised clip size)
Tags 957, 958, 959, and 960 are defined in the below table:
Tag
Field
Type
Description
957
NoStrategyParameters
NumIn
Group
Indicates number of strategy
parameters

958
StrategyParameterName
String
Name of parameter

959
StrategyParameterType
Int
Datatype of the parameter

960
StrategyParameterValue
String
Value of the parameter
New Order Example Message Flow and FIX Message
Example showing new order entered and rejected by the Member Interface
for invalid account.
Steps
1
Member
Member Gateway
NewOrderSingle (D)
2
ExecutionReport (8)
Order Status = Rejected
FIX Message at step 1:
8=FIX.4.4|9=237|35=D|49=MEMBER|50=USERA|56=MATBA|34=3|52=2010022
0-09:05:20.123|11=200220100001|1=ACC99|55=CMGLD|48=MATBA/CMGLD/JUN10|22=102|200=201006|4
61=FXXXXX|167=FUT|207=XMTB|54=1|60=2010022009:05:20.123|38=100|44=99.85|40=2|59=0|10=8
FIX Message at step 2:
8=FIX.4.4|9=237|35=8|49=MATBA|56=MEMBER|34=11|52=2010022009:05:20.324||11=200220100001|17=80001|150=8|39=8|1=ACC99|55=CMGLD|48=MATBA/CMGLD/JUN10|
22=102|200=201006|461=FXXXXX|167=FUT|207=XMTB|54=1|38=100|44=99.8
5|40=2|59=0|60=20100220-09:05:20.324|58=Invalid Account|10=16
©patsystems
Page 37 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Cancel Replace (Modify Order) Example Message Flow and FIX Message
Example showing a request to modify an order of 100 lots to 500 lots,
pending replace and successful replacement (new).
Steps
1
Member
Member Gateway
OrderCancelReplaceRequest
(G)
2
ExecutionReport (8)
Order Status = Pending Replace
3
ExecutionReport (8)
Order Status = New
FIX Message at step 1:
8=FIX.4.4|9=200|35=G|49=MEMBER|56=MATBA|34=9|50=USERA|52=2011031
414:06:37|37=55649|41=FIX31728|11=FIX|1=ACCOUNT1|55=[N/A]|48=PTSFIX1
ORDRCID|22=102|54=2|60=2011031414:06:37|38=2|40=2|44=0.71|59=0|10=153
FIX Message at step 2:
8=FIX.4.4|9=501|35=8|34=11|49=MATBA|52=2011031414:06:37.576|56=MEMBER|57=USERA|1=ACCOUNT1|6=0|11=FIX|14=0|15=TR
Y|17=bbcd4f4c67794abea1dd7a5803f295fd3|22=102|37=55649|38=4|39=E|40=
2|41=FIX31728|44=0.705|48=MATBA/CMWHT/MAR11|54=2|55=CMWHT|59=0|
60=2011031414:06:37.485|150=E|151=4|167=FUT|198=11:55649|200=201103|207=XMTB|46
1=FXXXXX|541=20110331|453=3|448=ACCOUNT1|447=D|452=38|448=ACCO
UNT1|447=D|452=24|448=USERA|447=D|452=12|454=1|455=F
WHT
20110300
|456=103|10=000
FIX Message at step 3:
8=FIX.4.4|9=505|35=8|34=12|49=MATBA|52=2011031414:06:37.631|56=MEMBER|57=USERA|1=ACCOUNT1|6=0|11=FIX|14=0|15=TR
Y|17=bbcd4f4c67794abea1dd7a5803f295fd4|22=102|37=55649|38=2|39=0|40=
2|41=FIX31728|44=0.71|48=MATBA/CMWHT/MAR11|54=2|55=CMWHT|59=0|6
0=2011031414:06:37.539|77=O|150=5|151=2|167=FUT|198=11:55649|200=201103|207=XM
TB|461=FXXXXX|541=20110331|453=3|448=ACCOUNT1|447=D|452=38|448=A
CCOUNT1|447=D|452=24|448=USERA|447=D|452=12|454=1|455=F
WHT
20110300
|456=103|10=156
©patsystems
Page 38 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
9.6
Negotiated Trades
Supported Message Types
Message Type
Trade Capture Report (AE)
Trade Capture Report Ack (AR)
Description
Used To Submit Whole Sale Trades. A deal is
typically struck between two parties, one of
whom has an obligation to report the trade.
The counterparty has an agreement with the
reporting party. The reporting party sends the
trade report to the market. The marketplace
accepts the report and confirms the
Confirmed Trade to all involved parties.
Used to acknowledge or reject a
TradeCaptureReport message.
Negotiated Trades Example Message Flow and FIX Message
Example showing Negotiated Block Trade
Steps
1
Member 1
Order Gateway
Member 2
TradeCaptureReport(AE)
Block Trade sent to
Exchange
TradeCaptureReportAck
(AR)
2
TradeCaptureReport(AE)
Block Trade sent to
Exchange
3
TradeCaptureReport(AE)
(Trade Confirm)
4
TradeCaptureReport(AE)
(Trade Confirm)
5
FIX Message at step 1:
8=FIX.4.4|9=220|35=AE|49=MEMBER1|56=MATBA|34=36|50=USER1|52=2011
062711:31:39.568|571=TCR73091|856=0|828=1|880=USER2|570=N|55=[N/A]|48=M
ATBA/501_CMGLD/JUN11|22=102|32=5000|31=50|75=20100709|60=20100709
-16:00:00|552=1|54=1|37=12345|1=ACCOUNT1|10=195
FIX Message at step 2:
8=FIX.4.4|9=358|35=AR|34=37|49=MATBA|52=2011062711:31:39.864|56=MEMBER1|57=USER1|1=ACCOUNT1|17=aa5eba5d78a34f9e
©patsystems
Page 39 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
bbe1055121249aea|22=102|48=MATBA/501_CMGLD/JUN11|55=501_CMGLD|
60=2011062711:31:39.786|150=0|167=FUT|200=201106|207=XMTB|461=FXXXXX|487=0|54
1=20110630|571=TCR73091|828=1|856=0|880=USER1|9611|939=0|454=1|455
=FGLD20110600|456=103|10=250
FIX Message at step 3:
8=FIX.4.4|9=220|35=AE|49=MEMBER2|56=MATBA|34=55|50=USER2|52=2011
062711:32:39.568|571=TCR73092|856=0|828=1|880=USER1|570=N|55=[N/A]|48=M
ATBA/501_CMGLD/JUN11|22=102|32=5000|31=50|75=20100709|60=20100709
-16:00:00|552=1|54=2|37=12345|1=ACCOUNT2|10=199
FIX Message at step 4:
8=FIX.4.4|9=485|35=AE|34=57|49=MATBA|52=2011062711:36:40.188|56=MEMBER1|17=0f74c39ee02a3391a0f717eac67b591c|22=102|
31=50|32=5000|48=MATBA/501_CMGLD/JUN11|55=501_CMGLD|60=2011062
711:36:22.000|75=20110627|150=F|167=FUT|200=201106|207=XMTB|231=100|
461=FXXXXX|487=0|541=20110630|570=Y|571=14539080113640119|828=1|856=0|880=6
|454=1|455=F
GLD
20110600
|456=103|552=2|54=2|37=9613|77=O|54=1|37=9611|453=2|448=USER1|447=D|
452=38|448=USER1|447=D|452=12|1=USER1|77=O|10=057
FIX Message at step 5:
8=FIX.4.4|9=489|35=AE|34=67|49=MATBA|52=2011062711:37:41.288|56=MEMBER2|17=0f74c39ee02a3391a0f717ea1sweqa|22=102|31
=50|32=5000|48=MATBA/501_CMGLD/JUN11|55=501_CMGLD|60=2011062711:36:22.000|75=20110627|150=F|167=FUT|200=201106|207=XMTB|231=100|
461=FXXXXX|487=0|541=20110630|570=Y|571=14539080113640119|828=1|856=0|880=6
|454=1|455=F
GLD
20110600
|456=103|552=2|54=2|37=9613|77=O|54=1|37=9611|453=2|448=USER2|447=D|
452=38|448=USER2|447=D|452=12|1=USER2|77=O|10=053
A. Error Messages and Descriptions
Logon Category
Error Message
Further Information
Internal error in authentication
processing
general authentication system error, check log
files for further details
Invalid User or Password
User is locked out : too many password
failures
User is blocked
©patsystems
Page 40 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Invalid Application or License
System is locked
No default trader account is set
Concurrent logon limit exceeded
Password change not allowed
Password has expired
New password is not valid
Logout Category
Error Message
Internal error in authentication
processing
Further Information
General subscription error, check log files for
further details
User is not logged in on this session
Security Definition Category
Error Message
Further Information
Unsupported Security definition request
type
General subscription error, check log files for
further details
quotedInstruments cannot be null
Property SYMBOL_TYPE is not present
in EPG.xml file
Issue on responding to client
Single instrument too big for max
message size
Unsupported subscription request type
Security List Category
Error Message
Further Information
Unsupported Security List Request Type
General subscription error, check log files for
further details
Property SYMBOL_TYPE is not present
in EPG.xml file
Issue on responding to client
quotedInstruments cannot be null
©patsystems
Page 41 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
General Subscription Error
General subscription error, check log files for
further details
Unsupported CFI Code
Unknown instrument
Unknown exchange
Unsupported subscription request type
Instrument has different exchange to
specified exchange
Security Status Category
Error Message
Further Information
Unsupported subscription request type
General subscription error, check log files for
further details
Missing security status request id
Missing instrument in security status
request
Unsupported CFI Code
Unknown instrument
Unknown exchange
General Subscription Error
General subscription error, check log files for
further details
Property SYMBOL_TYPE is not present
in EPG.xml file
Issue on responding to client
Trading Status Category
Error Message
Further Information
Unsupported subscription request type
General subscription error, check log files for
further details
Missing trading session request id
Missing instrument in market data
request
Order Processing Category
Error Message
©patsystems
Further Information
Page 42 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Unsupported order type
Attempt to retrieve persistent order
state, but no key fields were specified
Order has non-unique ClOrdID
OrigClOrdID does not refer to a
previously specified ClOrdID
OrigClOrdID and OrderID do not relate
to the same order
Order ID not specified
Null keys detected when retrieving order
state by ClOrdID
Null keys detected when retrieving order
state by OrigClOrdID
Error parsing ClOrdID field
Fill price is illegal or not convertible
Unsupported ExecType
OrderQty must be greater than zero
Missing or unsupported
cxlRejResponseTo value
Failed to translate outbound order
Failed to set instrument fields in FIX
message
Unsupported Side field value
LastPx field has an illegal format or is
not convertible
Order side has no FIX counterpart
Strike price has illegal format
Source has illegal leg fill price
Failed to determine parent fill quantity or
leg ratio
LegPx is not a valid price
©patsystems
Page 43 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Can't infer side for leg fill
Fill batches having more than one
strategy fill are not supported
Failed to add to NoLegs repeating group
Unrecognized order state
MaxShow must be greater than zero
General Category
Error Message
Further Information
Unsupported FIX message type
Native message is not a FIX message
Missing mandatory field in FIX message
FIX field is badly formatted
FIX Message rejected
Application message was rejected
General subscription error, check log files for
further details
Failed to derive special FIX 4.4 symbols
Error during search of source symbol
batch
Error occurred processing symbols from
source batch
Message got too large when adding
SecurityAltIDs
©patsystems
Page 44 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
B. Configurable Options
The following session details will be configurable for each FIX session:
Configuration
Name
Promiscuity
Proxied
Authentication User
FIX Hub
FIX Version
Local CompID
Remote CompID
Property Template
Description
Name of the FIX session
Can be User Only, Session Only, or Promiscuous
Yes/No
Username
FIX Hub in use
FIX 4.4 version of each particular gateway
It must be possible to configure the SenderCompID for
each FIX session connecting to the gateway
It must be possible to configure the TargetCompID
for each FIX session connecting to the gateway
FIX 4.4 message template to be used
The following session properties will also be configurable:
Configuration
StartDay
StartTime
DataDictionary
SocketAcceptPort
EndDay
EndTime
Connection type
FileLogPath
©patsystems
Description
Day FIX session begins
Time FIX session begins
FIX 4.4 Data dictionary to be used for the session
It is possible to configure the listening port for each FIX
session connecting to the gateway. Leaving this field
blank will default to the standard port for each gateway
Day FIX session ends
Time FIX session ends
Acceptor or initiator
Used to configure the logging location. Leaving this
field blank will default to the standard logging location
for each gateway
Page 45 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
C. Document Control
Master Location: Sharepoint
Document Name: External Members Gateway (FIX 4.4)
Document Owner: Product Group
Controlled Distribution: yes
Change History / Version Summary
©patsystems
Vers
Date
Author
Description of Changes
Sections
Affected
1.0D
1
1.0D
2
1.0D
3
1.0
1.1
16 Mar 2010
Pete Burley
First Draft
All
23 Mar 2010
Pete Burley
All
23 Mar 2010
Pete Burley
24 Mar 2010
03 June 2010
1.2
18 June 2010
1.3
09 July 2010
1.4
18 Aug 2010
1.6
02
September
2010
01 October
Corrections to Section 7 – replaced
references to ‘MATBA’ with ‘XMTB’
Corrections to Section 7 – replaced
references to ‘MATBA’ with ‘XMTB’
7
1.5
Pete Burley
Simon
Rushworth
Simon
Rushworth
Simon
Rushworth
Simon
Rushworth
Simon
Rushworth
Enhancements following review of
V1.0D1
Enhancements following review of
V1.0D1
Moved to Issue version
Added section 10, Example Message
Flows of Member Functionality
Corrections to Section 7, added
4.12.and 4.13
Corrections to section 7
1.7
05 October
Chris Snell
1.8
1.9
05 October
18 October
2010
Chris Snell
Chris Snell
1.10
02 Nov 2010
Chris Snell
1.14
21 Dec 2010
Chris Snell
1.15
&
1.16
1.17
1.18
1.19
1.20
1.21
1.22
18 Jan 2011
Chris Snell
Corrections to Market data request
messages
No changes - no document published –
this version was to just keep ROE
versions in line with message definition
document versions
Document tidy up and spell check
Change of CFI codes to 6 characters.
Change of orderstatus exectype
definitions and updates to market data
request.
Changed CFI codes, Market Data
Snapshot Message
Numerous changes as per reworking
of ROE
Addition of iceberg order examples
21 Feb 2011
16 Mar 2011
26 Apr 2011
28 Jun 2011
22 Jul 2011
19 Aug 2011
Chris Snell
Chris Snell
Chris Snell
Chris Snell
Chris Snell
Chris Snell
New release of documentation
New release of documentation
New release of documentation
New release of documentation
New release of documentation
New release of documentation
Chris Snell
1.1, 2, 4.1, 4.2,
4.71, 7.1, 7.2, 8
All
10
7, 4.12, 4.13.
7
7
n/a
all
all
10.5
All
All
various
various
4.15
various
Page 46 of 47
TurkDex Order Gateway - FIX.4.4
Rules of Engagement
Document Approval / Review
Version
Purpose of Review
Name
Date
1.0D1
Comment
Martyn Hemmings
1.0D2
Comment
Martyn Hemmings
22 Mar
2010
23 Mar
2010
Related Documents
©patsystems
Title
Version
Author
Date
External Member
Gateway.pdf
1.6
Patsystems
02 September 2010
Page 47 of 47