Taiwan Stock Exchange Corporation
(TWSE)
FIX4.4 Specification
Published by Taiwan Stock Exchange Corporation
1
1、Version revise record
No / Description / Version / Writer / Date1 / Version 1.0
The amendments are due to TWSE New Trading System, which will go-live in May of 2014. / 1.0 / System Development Dept / 2013/08/13
2 / Error Code 50 – No LeavesQty / 1.1 / System
Development
Dept / 2014/12/17
3 / FixedPrice and OddLot / 1.2 / System Development Dept / 2017/02/03
1
Contents
1、Version revise record
2、Introduction
2.1Introduction
2.2Scope of this manual
2.3Written and modification
2.4Download the electronic version of FIX specification
3、Structure of connection
3.1TWSE TCP/IP’s network structure（IP network）
3.2Structure
3.3Brokers FIX Structure
4、Introduction of FIX
4.1FIX Protocol
4.2FIX Session Protocol
4.3FIX Message Type supported
4.4General Message Flow
5、Main difference between FIX 4.4
5.1Order Report and Trade Report
5.2Difference between OrderID(37)
5.3User Defined Fields
6、Standard Header and Trailer
6.1Standard Header
6.2Standard Trailer
7、Session Level Messages
7.1Logon
7.2Heartbeat
7.3Test Request
7.4Resend Request
7.5Reject – Session Level
7.6Sequence Reset
7.7Logout
8、Application Messages
8.1New Order Single
8.2Order Cancel / Replace Request
8.3Order Cancel Request
8.4Order Status Request
8.5Execution Report
8.6Order Cancel Reject
8.7Business Message Reject
9、Error Message
9.1Reject - Session Level: Error Code
9.2TWSE TMP Session Sub System Error Code
9.3TWSE Normal Trade Error Code
10、Appendix
10.1Order State Change Matrices......
10.2Differentiation with FIX4.4
2、
Introduction
2.1Introduction
Taiwan Stock Exchange Corporation keens on improving the efficiency of trading process and enhancing the service quality to connect to the international security market. Taiwan Stock Exchange Corporation (“TWSE”) buildsthe “FIX Protocol platform” in order to provide domestic and international Brokers fast speed. TWSE published this document based on the Financial Information eXchange (FIX)Protocol Version4.4. Brokers need to follow this document for further trading transactions. More information of FIX Specification please refer to The FIX Protocol Organization (
2.2Scope of this manual
This document includes the configuration, the means of sending message and message formats. About the session linkage test please refer to the “session linkage user manual”.
2.3Written and modification
This document is made by TWSE System Development Department.After the execution, actual requirements can be amended and announced by TWSE.
2.4Download the electronic version of FIX specification
Download from the official website of TWSE(
3、Structure of connection
3.1TWSE TCP/IP’s network structure（IP network）
TWSE adopted MPLS(Multi-Protocol Label Switching) constructed by CHT ATM backbone for brokers to establish efficient and high-secured connections under point to point fixed IP virtual circuit(Virtual Circuit). With superior performance and high security features.
3.2Structure
4、
Introduction of FIX
4.1FIX Protocol
(1)FIX Format
FIX Messages format are not fixed length. All the messages are required to follow the protocol to transfer data. Therefore both sides can parse the format correctly. The general format of a FIX message is a standard header followed by the message body fields andterminated with a standard trailer.Each message is constructed of a stream of <tag>=<value> fields with a field delimiter(SOH) between fieldsin the stream. The first three fields in the standard header and the last field in the standard trailer are in order. Others are flexible. Please find more details as follows.
Tag / Field Name / Data Type / Req'dStandard Header / 8 / BeginString / String / Y
9 / BodyLength / String / Y
35 / MsgType / String / Y
The orders of other fields of the Standard Header are flexible.
Body / Orders of body are flexible.
Standard Trailer / 10 / CheckSum / String / Y
(2)Filed Delimiter：(ASCII “SOH”, 0x01)
All fieldsin a FIX message are terminated by a delimiter character. The non-printing, ASCII "SOH" ( hex:0x01, referred to in this document as <SOH>), is used for field termination. Messages are delimited bythe “SOH” character following the CheckSum field. All messages begin with the “8=FIX.4.4<SOH>”string and terminate with “10=nnn<SOH>“.“nnn“ is the result calculated by checksum.
Examples：
8=FIX.4.4<SOH>9=51<SOH>35=0<SOH>49=200201<SOH>56=TWSE<SOH>34=593<SOH>52=20090803-13:37:47<SOH>10=233<SOH>
(3)Data Types:
Data types (with the exception of those of type "data") are mapped to ASCII strings as follows:
(3.1)int: Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. “00023” = “23”)
Examples: 723 in field 16 would be mapped int as |16=723|.
-723 in field16 would be mapped int as |16=-723|
(3.2)float: Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties. Note that float values may contain leading zeros (e.g. “00023.23” = “23.23”) and may contain or omit trailing zeros after the decimal point (e.g. “23.0” = “23.0000” = “23”).
(3.3)Qty: float field.
(3.4)Price: float field.
(3.5)char: Single character value, can include any alphanumeric character or
punctuation except the delimiter. All char fields are case sensitive (i.e. m ≠ M).
(3.6)Boolean: a char field (see definition of “char” above) containing one of two values:
'Y' = True/Yes
'N' = False/No
(3.7)String: Alpha-numeric free format strings, can include any character or punctuation except the delimiter. All char fields are case sensitive (i.e. morstatt ≠ Morstatt).
(3.8)UTCTimestamp: Time/date combination represented in UTC (Universal Time Coordinated, also known as “GMT”) in either YYYYMMDD-HH:MM:SS (whole seconds) or YYYMMDD-HH:MM:SS.sss (milliseconds) format, colons, dash, and period required.
(4)Sequence Numbers
All FIX messages are identified by a unique sequence number. Message sequence number will start at 1 in morning testing and market opening.
In brief, the usage of sequence numbers is designed to ensure message delivery. If either side receives a message sequence higher than expected, it assumes that the other messages have been missed and requests these missing messages from the other end.
If a message with a lower sequence number is received, this is a fatal situation and is not allowed in this FIX protocol. Should drop the connection and exclude the scenario first then reconnect.
(5)Required Fields:
Each message within the protocol is comprised of required, optional and conditionally required (fieldswhich are required based on the presence or value of other fields) fields.
(6)User Defined Fields:
In order to provide maximum flexibility for its users, the FIX protocol accommodates User DefinedFields.The tag numbers 5000 to 9999 have been reserved for use with user defined fields, which are used aspart of inter-firm communication. These tags can be registered/reserved via the FIX website.The tag numbers greater than or equal to 10000 have been reserved for internal use (within a singlefirm) and do not need to be registered/reserved via the FIX website.
4.2FIX Session Protocol
A FIX Session includes: Logon, Messageexchange and Logout.
(1)Logon
Establishing a FIX connection involves three distinct operations: creation of a telecommunicationslevel link, authentication/acceptance of the Session initiator (Brokers) by the Session acceptor (TWSE) and message synchronization(initialization).
(1.1)Establish a telecommunication link
(1.2)Authentication/acceptance of the Session
Establishing the telecommunicationslink, the initiator will send a Logon message. If there’s no Logon message by initiator over 60 seconds, the session acceptor should shut down the connection. Initiator should reconnect again.
Normally, the initiator will send a Logon message to session acceptor.
Session acceptor needs to authenticate the message.
If the initiator is successfully authenticated: theacceptor responds with a Logon message.
If authentication fails: the session acceptor should shutdown the connection and response a Logoutmessage including the reasons cause failure. (Such as KEY-VALUE ERROR)
The initiator should receive a Logonmessage from the session acceptor then send other messages.
(1.3)Message synchronization
The initiator and acceptor must synchronize their messages throughinterrogation of the MsgSeqNum field before sending any messages.Acomparison of the MsgSeqNum in the Logon message to the internally monitored next expectedsequence number will indicate any message gaps. Likewise, the initiator can detect gaps bycomparing the acknowledgment Logon message MsgSeqNum to the next expected value.
It is recommended for Brokers to wait a short period of time following the Logon or to send a TestRequest to the TWSE. After that check the MsgSeqNumof Heartbeat from TWSE. If the sequence number is not synchronized. Brokers need to send the ResendRequest message in order to fill the message gap.
(2)Message exchange
After the Logon procedure, message can exchange between both sites. More details please refer to the Chapter 6 Session Level Messages and Chapter 7 Application Messages.
(3)Logout
Normal termination of the message exchange session will be completed via the exchange of Logoutmessages. Termination by other means should be considered an abnormal condition and dealt with asan error. Session termination without receiving a Logout should treat the counterparty as logged out.
It is recommended that before sending the Logout message, a TestRequest should be issued to force aHeartbeat from the other side. This helps to ensure that there are no sequence number gaps.
A Logout procedure will be as follows.
(2)
(3)
(3.1)Logout initiator sends a Test Request message.
(3.2)Logout acceptor replies a Heartbeat.
(3.3)Logout initiator verifies the message sequence number of Heartbeat to ensure there are no sequence number gaps.
(3.4)If sequence number gaps are founded, send the Resend Request message directly.
(3.5)Logout acceptor ack the messages need to be resent.
(3.6)Logout initiator verifies no sequence number gaps. Send Logout message. Will drop the connection if do not receive the confirming Logout message ack over timeout 5 seconds.
(3.7)Logout acceptor verifies the Logout message sequence number to ensure there are no sequence number gaps.
(3.8)Will send the Resend Request directly if the sequence number gaps are found in Logout acceptor.
(3.9)Logout initiator ack the message need to be resent.
(3.10)Logout acceptor verifies no sequence number gaps. Send a confirming Logout message.
(3.11)Logout initiator drops the connection.
4.3
FIX Message Type supported
FIX Message Type issued by Brokers
MsgType(tag 35) / Message / Comments
Session Level Message
A / Logon
0 / Heartbeat
1 / Test Request
2 / Resend Request
3 / Reject – Session Level
4 / Sequence Reset
5 / Logout
Application Message
D / New Order Single
G / Order Cancel/Replace Request
F / Order Cancel Request
H / Order Status Request
FIX Message Type issued by TWSE
MsgType(Tag 35) / Message / Comments
Session Level Message
A / Logon
0 / Heartbeat
1 / Test Request
2 / Resend Request
3 / Reject – Session Level
4 / Sequence Reset
5 / Logout
Application Message
8 / Execution Report
9 / Order Cancel Reject
j / Business Message Reject
4.4
General Message Flow
In this chapter addresses Brokers send messages to TWSE and the expected message flow. The ExecType(150) is used to identify the purpose of the execution report message. Refer to more details as follows.
0 / 4 / 5 / 8 / F / INew
order-
Success / Canceled
Success to Cancel order/ Reduce quantity / Replace
Reduce quantity / Rejected
New order-Failure / Trade
Partial Fill /Fill / Order Status
Securities Firms / TWSE / Comments
Logon / Logon / Logon-Success
Logout / Logon-Failure
New Order Single / Reject – Session / FIX tag validation error
Exection Report:
ExecType(150) =8 / New order-Failure
Exection Report:
ExecType(150) =0 / New order-Success
Exection Report:
ExecType(150) = 0
OrdRejReason(103)=99
Text(58)=0031-QUANTITY WAS CUT / Partial new orders-Success
Order Cancel/Replace Request / Reject – Session / FIX tag validation error
Cancel Reject / Fail to reduce quantity
Exection Report:
ExecType(150) =5 / Success to Reduce quantity
Order Cancel Request / Reject – Session / FIX tag validation error
Cancel Reject / Fail to Cancel order
Exection Report:
ExecType(150) =4 / Success to Cancel order
Order Status Request / Reject – Session / FIX tag validation error
Exection Report:
ExecType(150)=I / Response to order status query
Receive Exection Report / Exection Report:
ExecType(150) =F / Partial Fill/ Fill
TWSE will send automatically
Business Message Reject / Validate error message
TWSE unsupported message type
Logout / Logout / Logout
5、
Main difference between FIX 4.4
Basically, TWSE FIX based on the Financial Information eXchange (FIX)Protocol Version 4.4. But still have some changes in order to meet the current Trading System. In this chapter addresses the main difference between TWSE FIX and FIX 4.4. For more details of message flow, the value of field and the messages, please refer to the Appendix Order State Change Matrices.
5
5.1Order Report and Trade Report
(1)No Pending message in Order Report
In FIX4.4, Exchange will response Pending message when receive New Order/Cancel/Replace. Yet based on TWSE FIX, TWSE will not reply such messages as Pending New, Pending Cancel and Pending Replace to Brokers. According to current system, the trading system will deal with orders made by Brokers and ack the order report. Brokers will receive messages of order success or order failure. Please find the new order flow as follows.
(2)OrdStatus(39) = ExecType(150), but some exceptions are shown as below.
In normal circumstances, the value of OrdStatus(39) and ExecType(150) are the same. But some exceptions are shown as below:
When Order Cancel/Replace is successful, ExecType(150) = Replace, OrderStatus(39) = New.
When Order Status Request is successful, ExecType(150) = OrderStatus, OrderStatus(39) = New.
In Trade Report, ExecType(150) = Trade, if partial fill, then OrdStatus(39) = Partially Filled, else fill, OrdStatus(39) = Filled.
(3)Fields related to Order Report and Trade Report
The format Execution Report (MsgType=8) will use in both Order Report and Trade Report.
In Order Report, use the actual quantity of successful order OrderQty(38) and the amount of quantity open for further executionLeavesQty(151) to get the valid value. And the quantity of this transactionLastQty(32) will response 0.
In Trade Report, use the executed quantity CumQty(14) and the quantity of this transactionLastQty(32) to get the valid value. And the actual quantity of successful order OrderQty(38) and the amount of quantity open for further executionLeavesQty(151) will response 0.
CumQty(14) / LastQty(32) / OrderQty(38) / LeavesQty(151)Order Acknowledgement / Actual value / 0 / Actual value / Actual value
Execution
Acknowledgement / Actual value / Actual value / 0 / 0
(4)For Execution Report , reply the FIX orders only
The current TWSE TMP System’s Execution Report includes the complete TMP and FIX information. However, the Execution Reports of FIX only reply the new orders trough the FIX platform.
(5)AvgPx(6) = 0
Do not support calculating the average price. This field is always 0.
(6)Only the value 99-Other in both fields CxlRejReason(102) and OrdRejReason(103). The error message in details please refer to Text(58).
5.2Difference between OrderID(37)
In FIX 4.4, Exchange will generate an OrderID(37) in execution report once Brokers make orders. In TWSE FIX, TWSE will use the current way in order to meet the need of Trading System now. Brokers need to generate an non-repeated dailyOrderID(37). Also the usage of this ID is the same with current TWSE TMP System’s [ORDER-NO] and repeated is forbidden as well.
Tag / System Specification / FIX 4.4 SpecificationOrderID(37) / Similar to the current [ORDER-NO]. Brokersneed to generate the OrderID once new order occurs.
This column is required. / This figure will be generated by the Exchange.
5.3User Defined Fields
According to the current TMP Session manual, parts of the fields are not supported by FIX. Hence, in order to meet the need of current Trading System. There will be four User Defined Tags added in TWSE FIX( Tag number over 10,000), please find more information as below:
Tag / Field Name / Data Type / Req’d / Comments10000 / TwseIvacnoFlag / Char / Y / Regular, FixedPrice
Notes of Investors’ Order
Channel [IVACNO-FLAG]
‘1’ Normal(FIX)
‘2’ ATM(FIX)
‘3’ DMA Order(FIX)
‘4’ Internet(FIX)
‘5’ Voice(FIX)
OddLots
Ignored
10001 / TwseOrdType / Char / Y / Regular, FixedPrice
[ORDER-TYPE]
‘0’ Normal
Via Securities Finance
‘1’ Purchase on Margin
‘2’ Short Sell
Via Securities Firms conduct Margin Lending
‘3’ Purchase on Margin
‘4’ Short Sell
‘5’ SBL Short Sell type 5
‘6’ SBL Short Sell type 6
OddLots
‘0’ Normal
Via Securities Finance
10002 / TwseExCode / Char / Y / Regular, FixedPrice
[EXCHANGE-CODE],
‘0’ Regular, FixedPrice
OddLots
[TRADE-KIND]
‘2’ OddLots
10004 / TwseRejStaleOrd
(Reserved) / Boolean / Y / Regular
Checks the TransactTime to verify that it is within a given seconds of the system time.
“Y”if not, reject it.
“N”don’t check TransactTime.
FixedPrice, OddLots
Ignored
6、Standard Header and Trailer
Every message contains standard headers and trailer. Unsupported tags of FIX 4.4 if included in the message format will be rejected (Reject-Session). If a tag follows the FIX4.4 but not supported by TWSE FIX, TWSE will ignore the tag.
6
6.1Standard Header
Tag / Field Name / Data Type / Req’d / Comments8 / BeginString / String / Y / FIX.4.4
9 / BodyLength / String / Y
35 / MsgType / String / Y
34 / MsgSeqNum / int / Y / Max 8 digits
43 / PossDupFlag / Boolean / N
97 / PossResend / Boolean / N
49 / SenderCompID* / String / Y / Market + Broker-ID + FIX Socket ID
Broker who establishes the sessionconnection
Market (T:TWSE O:OTC)
1 char+4char+2char
50 / SenderSubID* / String / N / Broker-ID
Broker-ID who owns this order
Required for New/Replace/Cancel/Query/Execution
4 char
52 / SendingTime / UTCTimestamp / Y / YYYYMMDD-HH:MM:SS.sss
56 / TargetCompID* / String / Y / TWSE : XTAI
OTC : ROCO
57 / TargetSubID* / String / N / Trading session
Required for New/Replace/Cancel/Query/Execution
“0” Regular Trading
“2” Odd Lots
“7” Fixed Price
122 / OrigSendingTime / UTCTimestamp / N / YYYYMMDD-HH:MM:SS.sss
*SenderCompID, SenerSubID, TargetCompID and the TargetSubID based on the Message Sender to decide the transmit data. If Brokers send to TWSE, SenderCompID represents the Brokers’(Market+Broker-ID + FIX Socket ID). TargetCompID represents the TWSE : XTAI(or OTC : ROCO). On the contrary, TWSE send to Brokers, SenderCompID represents the TWSE : XTAI(or OTC : ROCO). TargetCompID represents the Brokers’ (Market + Broker-ID + FIX Socket ID).