SpecProtocolAndMessage 20110105

The Hochiminh Stock Exchange Trading Protocol Specification
HOSE Trading System
Protocol & Message Specification
For
TP Manager Connectivity
Version 1.0
March 2008
Contents
The Stock Exchange of Thailand Page 1

HOSE Trading System ................................................. 1

Part I : Protocol Specification ............................................. 5
1. Online-trading Protocol (AUTO-t Protocol) .................................. 5
2. Broadcast Protocol (UDP) ................................................ 19
3. Broadcast Retransmission.............................................. 21
Part II : Message Specification 23
1.CTCI Messages Descriptions ...................................... 23
Message 1C - Order Cancellation 23
Message 1D - Order Change 24
Message 1E - Advertisement 25
Message 1F - One-Firm Put-Through Deal 26
Message 1G - Two-Firm Put-Through Deal 27
Message 1I - New Conditioned Order 28
Message 2C - Confirm of Order Cancel 30
Message 2D - Confirm of Order Change 31
Message 2E - Deal Confirmation 32
Message 2F - Put-Through Acknowledgment 33
Message 2G - Reject 34
Message 2I - Crossing Deal Confirm 35
Message 2L - Put-Through Deal Confirmation 36
Message 3A - Admin 37
Message 3B - Put-Through Deal Reply 38
Message 3C - Deal (Put-Through) Cancel Request 39
Message 3D - Deal Cancel Reply 40
Message RN - Retransmission Nack 41
Message RP - Retransmission Reply 42
Message RQ - Retransmission Request 43
2. Broadcast Messages Descriptions ................................ 44
Message AA - Advertisement Announcement 44
Message BS - Broker Status Change 46
Message CO - Cancel Odd Lot 47
Message DC - Deal Cancellation Notice 48
Message GA - General Admin 49
Message IU - Index Update 50
Message LO - Last Odd Lot 51
Message LS - Last Sale 52
Message NH - News Headline 53
Message OL - New Odd Lot 55
Message OS - Market Open Last Sale 56
Message PD - Put-Through Deal Notice 57
Message PO - Projected Open 58
Message SC - System Control 59
Message SI - Sectoral Indices 60
Message SR - Security Reconcile 61
Message SS - Security Status Change 62
Message SS - Security Status Change 62
Message SU - Security Update 63
Message TC - Trader Status Change 65
Message TP - Top Prices 66
Message TR – Foreign Room 67
Message TS - Time Stamp 68
3. Messages Field descriptions .................................... 69
Add/Cancel Flag 69
Advances 69
Benefit 70
Board 70
Board Lot 70
Broker Client Volume, Broker Foreign Volume, Broker Portfolio Volume 70
Cancel Confirm 70

Cancel Shares 72
Ceiling Price 72
Client ID 72
Client ID Required 72
Confirm Number 74
Contact 74
Contra Firm 74
Current Room 74
Deal ID 74
Declines 75
Delist 75
Down Volume 75
Error code 75
Filler 76
Firm 76
Floor Price 77
Halt / Resume Flag 77
Highest Price 77
Index – HOSE 77
Index Time 77
Last Sale Price 78
Lot Volume 78
Lot Volume 1,2,3 78
Lowest Price 78
Market ID 78
Message Type 79
Meeting 79
Mutual Fund Volume 79
No Change 79
No Change Volume 79
Notice 80
Open Price 80
Order Cancel Status 80
Order Entry Date 80
Order Number 81
Original Message Text 81
Par Value 81
Port/Client Flag 81
Price 82
Price 1,2,3 82
Prior Close Date 82
Prior Close Price 82
Projected Open Price 83
Published Volume 83
Reject Reason Code: 83
Reply Code 84
SDC Flag 84
Sector Number 84
Security Name 85
Security Number, Security Number (New) 85
Security Symbol 85
Security Type 85
Side 86
Split 86
Suspension 86
System Control Code 86
Time 87
Timestamp 87
Total Room 87
Total Shares Traded 87
Total Trades 87

Total Values Traded 88

Trader ID 88
Up Volume 88
Volume 88
4. Message Flow Diagrams .......................................... 89
System Control Message Flow Diagram 89
Market Pre-Open to Open Message Flow Diagram 90
Market Pre-Open to Open with ATO/ATC Orders Message Flow Diagram 91
Market Pre-Open to Open with Foreign Bid Message Flow Diagram 92
MP Order Processing Message Flow Diagram 94
Foreign bid Order Processing Message Flow Diagram 95
Change Order Message Flow Diagram 96
Cancel Order Message Flow Diagram 97
One Firm Put-Through Deal Message Flow Diagram 98
Cancel One Firm Put-Through Deal Message Flow Diagram 99
Two Firm Put-Through Deal Message Flow Diagram 100
Cancel Deal (Two Firm Put-through only) Message Flow Diagram 101
Advertisement Message Flow Diagram 102
5. Unit of Value .................................................. 103
Unit in 1000 103
Unit 1/100 point 103
Unit 1/1,000,000 point 103
Summary of Messages by Period ..................................... 104
Summary of Message by Period (continued)........................... 105
Modulo-96 numbers ................................................. 106
Message Flow between Exchange and Broker-firm ...................... 107

Part I : Protocol Specification
1. Online-trading Protocol (AUTO-t Protocol)
1. Introduction
AUTO-t Protocol is a 2-tier application-level protocol used for transferring transactions

between 2 parties, an exchange trading system and a broker trading system. The message used
for communication between the 2 systems contains 2 layers. The first layer will be processed by
the Front-end system and the later will be back-end dependent messages. The main benefit for
having separate layers is to allow the front-end system to be able to support more than one
back-end systems in a scaleable manner, i.e. no inherent dependencies between the front-end
and the back-end system. The protocol described herein is considered from the point of view of
the server or the exchange unless specified.
2. Theory of Operation
The Trading System at an exchange can be divided logically into 2 parts: front-end and back-
end. The back-end system is where trading application resides. The trading transactions are
transferred as messages between the back-end system at the exchange and the broker trading
system. It is the responsibility of the front-end system to handle the message transfer with full
awareness of the underlying transport protocol. The front-end may also act as a message router
when there is more than one back-end system, e.g. each supporting a particular market. The
application protocol is used for the front-end system to transfer trading messages over the
transport protocol in a reliable and manageable manner.
The application protocol is designed with the following criteria:

1. enabling flow control
2. ensuring reliability even with the occurrence of abnormal session breakdown
3. serving existing Front-end functionality
Theoretically, TCP, the underlying transport protocol of AUTO-tP, is a reliable protocol, e.g.
there is no packet loss nor duplication, and no packet is out of sequence. However, the abrupt
session breakdown might cause data loss; thus, making the TCP unreliable in the application
point of view. The reason is that TCP makes use of sliding window. The last unpacked TCP
packets may reach or may not reach the destination during the abnormal session breakdown. If
the new session is intended to continue the previous breakdown, it requires an application to
remember the "state" of the last session. Such state information is any information that enables
an application to differentiate the packets of the current session from those of the previous
session. Typically, the state is the packet sequence. The packet sequence is not required to be
unique throughout the whole session when sliding window is employed but in AUTO-tP, the
packet sequence will be unique for other reference purposes. Considering the state of an
application, there are 3 possible modes (situations) in making a connection:
 mode A (new connection): when an application intentionally forgets the previous state.
 mode C (continued connection): when an application uses the previous state to recover the
session. This is the successful continuing session.
 mode B (blindly continued connection): when an application loses the state but tries to
recover the session with the state information from the partner. The example situation when
an application needs mode B connection is when the host on which an application is
running is down.

There will be no mode B1 if an application does not lose the state; for example, if it saves the
state information on a non-volatile storage. However in the case that an application is moved
from one host to be executed on another host. The application must be able to access the saved
state information from the new host. Therefore the state information has to be stored on the like
of shared disk. Unfortunately, the shared disk approach might not be possible if the two host are
located in different geography.
Both sides have to agree upon the mode connection they will establish in advance, otherwise
the session can not be continued properly. For example, it is impossible if a server expects a
connection in mode A while a client wants to make a connection in mode C. Furthermore, the
data recovery procedure must be immuned to the recurring of possible breakdown during the
current recovery procedure itself.
In AUTO-tP, an exchange will act as a server and a broker will act as a client. The relationship
is one-to-one. Briefly, the application protocol consists of 3 major phases:
1. Connection establishment : In this phase, the client will request a connection to the server.
Before the server accepts the request connection, it will authenticate the requesting client
and do the client-side data recovery if necessary. Upon the connection acceptance from the
server, the client has to check if the server-side data recovery is required and send a
confirmation.
2. Data transfer : Once the connection is legally established, either server or client can send
data packets to each other. This phase is full-duplex but works under the sliding window
flow control. The flow control will limit the number of data packets that each side can send
to another without reception of any response. Other command-response subprotocols can
be implemented in the data transfer phase.
3. Connection termination: When either side prepares to stop the session, if possible, it must
follow the application protocol before closing the transport connection.
Besides the aforementioned reliability issue, the application flow control makes the protocol
manageable in that:
 the number of packets that may be lost during an abnormal breakdown will not be more
than the size of the buffered window; thus, the recovery time can be controlled at the
application level.
 if the application are not ready to receive any more packet for any reason, the data transfer
can be suspended at its will, otherwise the overloaded side may crash after all.
3. AUTO-t Protocol
1For the current front-end system at HOSE, the situation B can happen because the state
information is kept in the memory. Though all messages are logged onto disks, only data
portion of each front-end message which includes packet sequences is logged. For DECnet
protocol, the line handler uses a heuristic to recover data while the line handler for X.25 choose
to accept possible data loss if the case happens. The heuristic used by DECnet line handler is to
send the last N packets, each with a flag indicating possible duplication, where the N is the size
of the output window. (Also see "uncertainties" in the appendix B)

3.1 AUTO-t Message Format
Len Seq AckSeq Opcode Link ID Content ETX

2 bytes 4 bytes 4 bytes 2 bytes 2 bytes N bytes 1 byte
figure 1: Packet Format
As AUTO-tP relies on TCP, a stream protocol, it is a duty of an application program to detect a

message from the stream. Each message will be prepended with the length of the remaining
data and appended with a specific byte, ETX (end of text). In between, each AUTO-t message
consists of the following fields:
Field Name Field Length Field Type Field Description

Length 2 bytes ASCII ( mod96+32) the length of the
whole packet
excluding the field
length itself.
sequence2 4 bytes ASCII (mod96+32) the next sequence of
the sender, e.g it will
send the next packet
with that sequence
number. (the seq no.
must not overflow
within a day)
ack sequence 4 bytes ASCII (mod96+32) the next expected
sequence of the
sender, e.g. it expects
to receive the packet
with that sequence
or the sequence
number that one side
tells the other as a
confirmation of
receiving packets up
to the one with the
sequence =
ack_sequence -1
Opcode 2 bytes alphabet the packet type
which determines
how an application
will handle and
determines the
format and the
meaning of the
remaining fields. For
examples, if the
opcode = NACK,
there are 2 more
fields following the
2With a 4-byte field, the sequence number to grow up to 84,934,656

and it is very unlikely that the number of transactions of each broker
per day can exceed such amount. Thus the existing line handler feature
of resetting the sequence will be omitted.

link-ID: the error-

code and the error-
description.
Link-ID 2 bytes ASCII (mod96+32) the ID of the link is
used for the server to
identify from which
link the client data is
coming
content N bytes the content depends
on the packet type
ETX 1 byte constant end frame marker
(ASCII code 03)
A packet format, the content part in particular, depends on its opcode:
Content
opcode or packet type (2 field-name field-length
chars)
HL (HELLO) mode 1 byte ( alphabet )
A = new connection
B = forced continued
connection
C = continued connection
password N bytes
EOS (End Of String, ASCII 1 byte
code 00)
number of markets 1 byte (mod96+32)
market ID-1 1 byte (alphabet)
A = ASSET
(subjected to change)
firm ID-1 3 bytes (alphabet)
... ...
market ID-n 1 byte (alphabet)
firm ID-n 3 bytes (alphabet)
HR (HELLO_REPLY) mode 1 byte (alphabet)
CF (CONFIRM) - -
DT(DATA), market-ID 1 byte (alphabet)
message-count 1 byte (mod96+32)
data N bytes (if there are more
than one backend messages,
each will be separated with
US character)
LO(LEFTOVER) market-ID 1 byte (alphabet)
LL(LEFTOVER_LAST)
of DT
message-count 1 byte (mod96+32)
data N bytes (if there are more
than one backend messages,
each will be separated with
US character)
LO(LEFTOVER) market-ID 1 byte
LL(LEFTOVER_LAST)
of RP
RP Packet “RP” = 2 bytes

Link id = 2 bytes
Market-ID = 1 byte
Broadcast message = N bytes
RR(RETRAN_REQ) market-ID 1 byte
broadcast request message N bytes
RP(RETRAN_REPLY) market-ID 1 byte
broadcast message N bytes
AK(ACK) - -
NK(NACK) error code 2 bytes ( mod96+32 )
error string N bytes
EOS (ASCII code 00 ) 1 byte
FN(FINISH) - -
AF (ACKFIN) - -
EC (ECHO) - -
ER (ECHO_REPLY) - -
3.2 Connection Establishment
The connection establishment phase includes first-time authentication and data recovery (if
there's any message loss from the last session).
3.2.1 The protocol
The protocol will be:

3.2.1.1 The client sends HELLO:CliSeq:CliAck ( a HELLO packet with its next packet
sequence and next expected sequence. ) This HELLO packet will also contain the password for
being authenticated by the server. If the authentication fails, the server will send NACK with an
error code and description.
3.2.1.2 The server checks if the client needs any recovery:

a) If CliAck+WindowSize >= ServSeq > CliAck then the client missed some messages so
retransmission is required
b) If ServSeq == CliAck then everything is OK. No recovery is required.
c) If ServSeq > CliAck+WindowSize then recovery is impossible.
d) If ServSeq < CliAck then there is something wrong with the server.
For the case (d) It may be either because the server machine had been down or because the
server chose new connection (mode A, see Section 2) while the client chose to continue
connection (mode C). For the later case, the protocol should stop. Note that HOSE has chosen
not to recover missing data if the mode B connection happens but simply to recover sequences.
(See "uncertainties" in App.B). The case (c) should never happen if both applications are
correctly implemented. If it happens somehow, the protocol must stop.
3.2.1.3 Server sends HELLO_REPLY: ServSeq:ServAck
3.2.1.4 The client checks if the server needs any recovery.

a) If ServAck+WindowSize >= CliSeq > ServAck then the server missed some messages so
retransmission is required.
b) If CliSeq == ServAck then everything is OK. No recovery is required.
c) If CliSeq > ServAck+WindowSize then recovery is impossible.

d) If CliSeq < ServAck then there is something wrong with the client.
For the case (d), it maybe either because the client machine had been down or because the
client chose new connection (mode A) while the server chose to continue connection (mode
C). For the later case, the protocol should stop. The case (c) should never happen if both
applications are correctly implemented. If it happens somehow, the protocol must stop.
3.2.1.5 Once the server gets CONFIRM from the client, the connection setup phase is
complete.
All possible connection modes are:
Exchange Broker Action(s)

A A no recovery << HELLO (1,1)
HELLO_REPLY (1,1) >>
<< CONFIRM(1,1)
A B misunderstanding incident << HELLO (any,any)
NACK (any,any)>>
A C misunderstanding incident << HELLO (any,any)
NACK (any,any)>>
B A misunderstanding incident << HELLO (any,any)
NACK (any,any)>>
B B no recovery (nothing left << HELLO(seq1,ackSeq1)
for recovery). The case is HELLO_REPLY (seq1,ackSeq1) >>
the same as both parties <<CONFIRM(seq1,ackSeq1)
initiate new connection.
B C no recovery << HELLO(seq1,ackSeq1)
HELLO_REPLY (ackSeq1,seq1) >>
<<CONFIRM(seq1,ackSeq1)
C A misunderstanding incident << HELLO (any,any)
NACK (any,any)>>
C B no recovery << HELLO(1,1)
HELLO_REPLY (seq1,ackSeq1) >>
<<CONFIRM(ackSeq1,seq1)
C C complete recovery << HELLO(seq1,ackSeq1)
LEFTOVER/LEFTOVER_LAST >>
HELLO_REPLY(seq1,ackSeq1)>>
<<LEFTOVER/LEFTOVER_LAST
<<CONFIRM(seq1,ackSeq1)
table 1: all connection modes
3.2.2 Authentication
The front-end system of the exchange will maintain the following database:

Client’s 1 Lin e H and ler

IP ad dress TC P port
N
1
1
Link ID 1 1 Entran ce
(M em b er ID ) P assw o rd
Perm issible
M arkets
figure 2: authentication database
The link ID is for identifying a broker that connects to an exchange system. In the HELLO
packet, a client will place an entrance password and all (market-ID,firm-ID) tuples it wants to
trade with. Note that this password is for all markets the broker is allowed to trade with.
Password encryption can be employed here. If the password as well as a client’s IP are valid, a
server continues the connection setup process; otherwise, a NACK packet will be sent. Then
during the data transfer state, each data packet from a certain link ID which contains a market-
ID will be checked. If it is a data packet destined to a market where that broker has no
permission to access, the packet will be discarded and an exchange will issue NACK. Note that
the front-end system will no longer check whether a data packet contains a proper firm-ID.
3.3 Data Transfer
Data transfer phase includes Data transfer and Command-Response Service. In the Data
transfer state, the protocol entity will apply sliding window to all data packets. Also in this
state, there can be any command/response sub-protocol. Typically, the client sends a command
to the server and the server responses by sending ACK or NACK. Such sub-protocols are such
as broadcast retransmission request and Echo request, etc. If any data packet is invalid, the
exchange will respond with NACK.
3.3.1 Sliding window
Here at the application level, sliding window is used only to control the data flow between the
sender and the receiver. It is not for reordering incoming data packets nor for detecting message
loss and duplication because the underlying transport protocol has already handled such
problems. Each side can send as many data packets as the size of the output window without
reception of any ACKnowledged packet. The recipient should not send an explicit ACK until its
input window gets full. Each data packet being sent also implies acknowledgement of reception
of data packets of the other side so far, i.e. an ACK packet is piggybacked on an outgoing
DATA packet. Every packet will contain a sequence number and an acknowledged sequence
number and the following condition must always be satisfied:
theirAckSeq < ourNextSeq <= theirAckSeq+WindowSize
3.3.2 Broadcast Retransmission
A broker system can request broadcast data retransmission during the data transfer state with a
packet RETRAN_REQ. The packet carries a broadcast request message. An exchange will
respond with either ACK if the request packet is not invalid or NACK otherwise. Note that the

retransmission request will actually be processed by another process, for example

BCST_RETRAN. In other words, the line handler does not decide whether or not the
retransmission request is allowed. In addition, the retransmission data itself is provided by
BCST_RETRAN and will be encapsulated in an outbound RETRAN_REPLY packet for the
requesting broker by the line handler. The format of the broadcast retransmission request and
reply message will be specified in the CTCI message specification.
RETRAN_REQ Mkt retran request message

ID
RETRAN_REQ
Exchange Broker
ACK/NACK
When a broker wants to request broadcast message retransmission.
RETRAN_REPLY Mkt retran broadcast message

ID
When an exchange wants to send broadcast retransmission data.
figure 3: broadcast retransmission scheme
3.3.3 Echo command
By sending an ECHO packet, either side can check the reachability to the other side or the
readiness of the other side, e.g. whether the other side is staying in the data transfer phase,
ready to transfer DATA packets. To assume the guarantee of reachability or readiness, the
program must receive an ECHO_REPLY packet as a response.
3.4 Connection Termination
The protocol will be:

Any side will send a FINISH packet to show its intention to stop the session.
For the side who requests the termination:
 It sends a FINISH packet as a termination request.
 It waits for an ACKFIN from the other side. The ACKFIN will tell the next expected
sequence (theirAckSeq) of the other side. The condition theirAckSeq < ourNextSeq <=
(theirAckSeq+window_size) must be satisfied, otherwise it will send a NACK packet and
the termination is incomplete. If the termination is incomplete, the recovery will be
required when establishing the future connection. While it is waiting for an ACKFIN, it
could get instead some data packets from the other side, or it could get a FINISH packet in
the case of simultaneous disconnection request. If it gets a DATA packet, it will go back to
the data transfer phase and it has to resend the FINISH packet if it still intends to terminate
the connection.
 As an ACKFIN implies an explicit DATA ACK, it updates its input window and output

window accordingly.
For the side who receives a termination request:

 Upon receiving a FINISH packet, it checks if the condition theirAckSeq < ourNextSeq <=
(theirAckSeq+window_size) satisfies. If the condition doesn't satisfy, it sends a NACK
packet and the termination is incomplete. The program could ignore the FINISH packet if
it is waiting for some response in order to write the next data packet.
 As a FINISH implies a DATA ACK, it updates its output window accordingly.
 It sends an ACKFIN and updates its input window accordingly.
3.5 Protocol State Diagram
START snd: NACK STOP Protocol State Diagram

rcv: HELLO rcv: ACK
1 snd: LEFTOVER 3
2
snd: LEFTOVER
snd: HELLO_REPLY snd: LEFTOVER_LAST
snd: LEFTOVER_LAST
snd: HELLO_REPLY rcv: ACK
6 4
5
snd: ACK
rcv: LEFTOVER
rcv: CONFIRM 7 8
rcv: LEFTOVER_LAST rcv: LEFTOVER
rcv/snd: DATA, rcv: LEFTOVER_LAST
ACK, NACK rcv: CONFIRM snd: ACK
11* 10 9
snd: DATA, ACK

rcv:
FINISH
snd: ACKFIN
STOP
snd: FINISH 14 snd: NACK
rcv: FINISH STOP
rcv: ACKFIN
rcv: DATA, ACK 15 STOP

rcv: NACK
STOP

12
rcv: CONFIRM server
snd: COMAND command
ECHO
rcv/snd: DATA,
ACK, NACK 11 rcv: ACK, NACK,
data ECHO_REPLY
transfer
rcv: COMMAND,
ECHO
snd: ACK, NACK, 13

ECHO_REPLY client
snd: FINISH
command
rcv: FINISH
State Diagram during Data Transfer State
figure 5: Protocol State Diagram
State
1. RCV_HELLO
2. CLI_RECOV_BEGIN
3. CLI_RECOV_CONT
4. CLI_RECOV_END
5. SERV_READY
6. SERV_ACCEPT
7. SERV_RECOV_BEGIN
8. SERV_RECOV_CONT
9. SERV_RECOV_END
10. CLI_READY
11. DATA_TRANSFER (or CLI_ACCEPT)
12. SERV_COMMAND
13. CLI_COMMAND
14. RCV_FIN
15. SND_FIN
In any state of the whole protocol state diagram, if the server receives a new transport
connection request, it will assume the demise of the last session and reset the state to the
starting one, ready for the connection in the continuing mode (mode C).
3.6 Implementation Issues
 An application should stop:

 When an application receives an invalid packet, e.g. wrong format; Implementers
may choose to drop the invalid packet and try to detect a new valid one.
 When a time-out happens during the time an application is waiting for a particular
packet type (opcode); The time-out duration is left to implementers to decide. (It
should not be smaller than the RTT (Round Trip Time) of a packet from an

application3.)
 When the protocol breaks (e.g. it is out of state);
 When a certain packet is out of sequence (.e.g. the sequence of the packet is not
consecutive to the last one);
 The size of an input and output window should be the same. The definite size somehow
cannot be determined at the time when this document is being written since the window
size affects the performance, latency, and recovery time directly.4
 For each DATA packet, it is up to implementers to let it carry single or multiple back-end
dependent messages but both sides must have the same agreement.
 The maximum size of an AUTO-tP packet should not be more than the smallest MTU of all
network equipments with TCP/IP stacks in the whole path5.
3HOSE assumes that the time-out duration is no less than 15 seconds.

4First, both HOSE and vendors will implement the protocol with the
input and output window size of 7.
5According to the TCP/IP standard, the minimal MTU size is 576 bytes.
Since IP header is 20 bytes long and TCP header is 20 bytes long (with
no option), the safest maximum packet size of AUTO-tP is 536 bytes
long including its header.

4. Code Description
NACK Error Code Error Description

2001 CANCELED
2002 "Invalid sequence/ack-sequence"
2003 "Command is not successful"
2004 “Market Closed”
2005 “No authorization”
2006 “Invalid data packet”
2007 “Mismatched connection mode: exchange
mode = X”
Market Code Market Name

'A' "ASSET"
Connection Code Connection Mode

'A' "new connection"
'B' "blindly continued connection"
'C' "continued connection"

Appendix A. Protocol Timing Diagram
Transport Connection
Server HELLO Client

(Exchange) (Broker)
LEFTOVER
ACK
...
LEFTOVER_LAST
ACK
HELLO_REPLY
LEFTOVER
ACK
...
LEFTOVER_LAST
ACK
CONFIRM
DATA/ACK/NACK
Connection Setup
DATA
If an exchange DATA( Piggybacked Ack)

has any data to
send or
(Explicit) ACK
If Input Window
is full or
If a received data NACK
is invalid or
If an exchange FINISH
wants to terminate
the session
Server Client
(Exchange) (Broker)
Data Transfer

Server or FINISH Client

Client or Server
ACKFIN
ACKFIN
or
NACK
Transport Disconnect
Connection Termination

2. Broadcast Protocol (UDP)
1. Introduction
The Broadcast Protocol is a messaging protocol used for market data delivery to all trading
participants.
2. Message Deliver
The Broadcast messages are sent in the Broadcast packet form. One Broadcast packet can
contain multiple Broadcast messages. Broadcast packets are sent via the Universal Datagram
Protocol (UDP).
2.1 Sequence Numbers
Broadcast packets can be identified by their sequence numbers. TP sends Broadcast packets
with a sequence series starts at 1 (one). Receivers use the sequence numbers to detect duplicate
messages or lost messages and issue the proper retransmission process.
In case TP needs to restart the Broadcast packet with sequence at 1 (one). The receivers should
have a utility to reset the received sequence number to 1 (one). And in case of unrecoverable
situation, the receivers should have a utility to skip the lost packet to continue the current
trading session.
2.2 Timestamp
During periods of message inactivity, TP will send Time Stamp message at regular time
intervals, currently used interval is 30 seconds.
The Time Stamp messages is TS message.
2.3 Broadcast Packet Format
The general message format consists of fields as follow:
Field Name Size Format Comments

(bytes)
SeqNum 3 Mod966 Broadcast packet sequence number
MarketID 1 Alpha String ‘A’ for ASSET
MsgCount 1 Mod96 Number of Broadcast messages in the
packed content
PackedContent n See Packed Content Format
2.4 Packed Content Format
6 Mod96: Please see the Appendix A for more details.

The packed content format consists of Broadcast messages separated by US character (ASCII
31 or 0x1F). The grey text is optional fields.
Field Name Size Format Comments

(bytes)
BCMsg1 n1 Broadcast Message
UnitSeparator 1 Control ASCII US character, ASCII 31 (0x1F)
… … … …
BCMsgn nn Broadcast Message

3. Broadcast Retransmission
Because of the nature of UDP, Broadcast packets may be duplicated or may be lost. If
incoming sequence numbers are lower than the receiver’s next expectation, they are duplicated
and the receivers can discard those packets. If a sequence gap occurs, some packets are lost
and the receivers should issue the retransmission process.
3.1 Automatic Retransmission
Receivers can request Broadcast packet retransmission via an Auto-t protocol with a CTCI-RQ
message.
If the request is invalid, TP will respond with a CTCI-RN message.
The followings are the retransmission criteria.
- At most 600 sequences per request.
- The start sequence of the current retransmission request must be more than the end
sequence of the previously successful retransmission request.
If the request is valid, TP will resend Broadcast messages in CTCI-RP messages. The
UnitSeparator characters in the original Broadcast packets are changed to BELL characters.
Timestamp messages (CTCI-TS) are not resent. But the Timestamp message is used for end-
of-retransmission notification. Please note that the Timestamp field in the end–of-
retransmission Timestamp message has the value of Mod96(Retransmission End Sequence),
not Mod96(HHMMSS). The grey messages in the Figure 1 are optional.
The details of the broadcast retransmission request and reply messages (RQ, RP, RN
and TS) are specified in Part “Message Specification”.
Server Client
TP Broker
Broadcast packet lost
detected
CTCI-RQ
Valid request
CTCI-RP
:
:
CTCI-RP
CTCI-RP(TS)
Figure 1: Valid retransmission request and responses

Server Client
TP Broker
Broadcast packet lost
detected
CTCI-RQ
Invalid request
CTCI-RN
Figure 2: Invalid retransmission request and responses
3.2 Manual Retransmission
Receiver system’s operators can request Broadcast packet retransmission by calling to the
Exchange systems’ operators and specifying the packet sequences to be resent.

Part II : Message Specification
1. CTCI Messages Descriptions
Message 1C - Order Cancellation

Field Size Type
1. Message Type 2 "1C"
2. Firm 3 Numeric String
3. Order Number 8 Numeric String
4. Order Entry Date 4 Numeric String
Total 17
This message is used cancel an order in the HOSE’s trading system as

identified by the Order Number and Order Entry Date. A Confirm of
Order Cancellation Message (2C) will be returned to the firm by the
HOSE’s trading system if the order is cancelled. Otherwise, a Reject
Message (2G) will be sent to the firm with a reason code explaining
why it was not accepted.

Message 1D - Order Change

Field Size Type
1. Message Type 2 "1D"
5. Client ID 10 Alphanumeric String
6. Filler 17
Total 44
This message is used change certain modifiable values of a Main Board

(AOM) order that has been previously entered into the HOSE’s trading
system. If a field is filled in it will replace the existing values
in the order record. A Confirm of Order Change message will be sent if
the order change message is valid. Otherwise, a Reject Message will be
sent to the firm with the reason code explaining why the change was
rejected.

Message 1E - Advertisement
Field Size Type
1. Message Type 2 "1E"
3. Trader ID 4 Alphanumeric String
4. Security Symbol 8 Alphanumeric String
5. Side 1 Alpha String
6. Volume 8 Numeric String
7. Price 12 Numeric String
8. Board 1 Alpha String
9. Time 6 Numeric String
10. Add/Cancel Flag 1 Alpha String
11. Contact 20 Alphanumeric String
Total 66
This message is used to add or cancel an advertisement of securities.

Advertisements are not orders; they are committed informational
messages that represent indications of interest to trade a particular
security if the volume and price can be negotiated. A broker responds
to an advertisement by contacting the advertising broker and
negotiating a deal. If the brokers agree to make a deal, a Two Firm
Put-Through Deal is entered by the selling broker. Time should be
assigned by the broker system and sent to trading system when adding
or canceling an Advertisement.

Message 1F - One-Firm Put-Through Deal

Field Size Type
1. Message Type 2 "1F"
4. Client ID (Buyer) 10 Alphanumeric string
5. Client ID (Seller) 10 Alphanumeric String
6. Security Symbol 8 Alphanumeric string
9. Deal ID 5 Numeric String
10. Filler 8
11. Broker Portfolio Volume 8 Numeric String
(Buyer)
12. Broker Client Volume 8 Numeric String
(Buyer)
13. Mutual Fund Volume 8 Numeric String
(Buyer)
14. Broker Foreign Volume 8 Numeric String
(Buyer)
15. Filler 32
(Seller)
(Seller)
(Seller)
(Seller)
20. Filler 32
Total 191
This message will be used when a firm does an internal put-through

deal as allowed by HOSE rules. A One Firm Put-Through results in a
deal where the same firm is both Buyer and Seller.

Message 1G - Two-Firm Put-Through Deal

Field Size Type
1. Message Type 2 "1G"
2. Firm (Seller) 3 Numeric String
3. Trader ID (Seller) 4 Alphanumeric String
4. Client ID (Seller) 10 Alphanumeric String
5. Contra Firm (Buyer) 3 Numeric String
6. Trader ID (Buyer) 4 Alphanumeric String
8 Price 12 Numeric String
9 Board 1 Alpha string
11. Filler 4
(Seller)
(Seller)
(Seller)
(Seller)
16. Filler 32
Total 120
This message will be used when two firms agree to do a put-through

deal as allowed by HOSE rules. After negotiating the deal, the seller
will send a Two Firm Put-through Deal Message to the HOSE. When the
deal is negotiated, the seller must obtain the trader ID of the buyer
and enter this information. The HOSE’s system will then assign a
confirm number to the deal and send a Put-through Acknowledgment
Message to the buyer. The buyer must then send a Put-Through Deal
Reply back to the HOSE’s system. After the buyer approves and if
required, the HOSE’s official approves, a Deal Confirmation Message is
sent to both sides. If either the contra side or the HOSE’s official
disapproves the deal, a Put-through Deal Reply is sent to both firms.

Message 1I - New Conditioned Order

Field Size Type
1. Message Type 2 "1I"
4. Order number 8 Numeric String
7. Side 1 Alpha string
9. Published volume 8 Numeric String
10. Price 6 Alphanumeric String
11. Board 1 Alpha string
12. Filler 5
13. Port/Client Flag 1 Alpha string
14. Filler 5
Total 70
This message will be sent to the HOSE’s trading system by a firm to

enter an order.
remark
Published volume must be equals to Volume

Message 2B - Order Confirmation
Field Size Type

1. Message Type 2 "2B"
Total 17
This message is sent by the HOSE to the broker as a confirmation that

the order has been received. Order number is sent back to identify
the order received.

Message 2C - Confirm of Order Cancel

Field Size Type
3. Cancel Shares 8 Numeric String
6. Order Cancel Status 1 Alpha String
Total 26
For every Order Cancellation Message accepted by the HOSE’s trading

system, a Confirm of Order Cancellation Message will be sent to the
originating firm. The cancelled order will be identified by the Order
Number. This message will also be sent when an order requiring
immediate matching, e.g. MP, cannot be matched upon receipt. This
message will also be sent when an ATO order is cancelled at the open
because it could not be matched or when foreign bids is cancelled
after there is no room left.

Message 2D - Confirm of Order Change

Field Size Type
6. Port/Client Flag 1 Alpha string
7. Published Volume 8 Numeric String
9. Filler 8
Total 50
For every Order Change Message accepted by the HOSE’s trading system,
a Confirm of Order Change Message will be sent to the originating
firm. The Order Number and Order Entry Date will identify the order
that was changed. Other fields in this message will contain the
current values for the order including the new updated order
information. This message will also be used to inform a broker firm of
the limit price assigned to a market price order, which has been
partially filled. (In this MP case, published volume is blank, Price
is changed to limit price.)

Message 2E - Deal Confirmation

Field Size Type
1. Message Type 2 "2E"
6. Filler 2
9. Confirm Number 6 Numeric String
Total 40
A Deal Confirmation is sent to each side when orders from two

different brokers match to create a "non-crossing" deal.

Message 2F - Put-Through Acknowledgment

Field Size Type
1. Message Type 2 "2F"
2. Firm (Buy) 3 Numeric String
3. Trader ID (Buy) 4 Alphanumeric String
4. Side (B) 1 Alpha string
5. Contra Firm (Sell) 3 Numeric String
6. Trader ID (contra side- 4 Alphanumeric String
Sell)
Total 52
This message is sent to the contra broker when a Two Firm Put-through
Deal Message is received by the HOSE. This message is sent to the
contra firm (buyer) so the deal details may be checked. The buyer
must then send a Put-Through Deal Reply to approve or disapprove the
deal details.

Message 2G - Reject
Field Size Type
1. Message Type 2 "2G"
3. Reject Reason Code 2 Numeric String More codes
4. Original Message Text 233 Depend size of
message type
Total 240
A Reject Message will be returned to the originating firm when an

invalid message is received by the HOSE. The Reject reason code
explains why the HOSE’S trading system cannot carry out the request.
In cases where the original message exceeds 234 bytes, only the first
234 bytes are included.

Message 2I - Crossing Deal Confirm

Field Size Type
1. Message Type 2 "2I"
3. Order Number (Buy) 8 Numeric String
4. Order Entry Date (Buy) 4 Numeric String
5. Order Number (Sell) 8 Numeric String
6. Order Entry Date (Sell) 4 Numeric String
Total 49
A Crossing Deal Confirmation is sent to a firm when two orders match

to create a one-firm "Crossing" deal.

Message 2L - Put-Through Deal Confirmation

Field Size Type
1. Message Type 2 "2L"
5. Contra Firm 3 Numeric String
Total 40
This message is sent to confirm a 1 or 2 firm put-through deal.
If Firm is Buying, Side=‘B’. If Firm is Selling Side =’S’. If Firm is

making 1-Firm PT (Both Buy and Sell) Side = ‘X’

Message 3A - Admin
Field Size Type
1. Message Type 2 "3A"
3. Trader ID (sender) 4 AlphaNumeric String
4. Trader ID (receiver) 4 AlphaNumeric String
6. Admin Message Text 66 AlphaNumeric String
Total 82
The Admin Message is a free format message that may be sent from one
firm to another, from one firm to the HOSE, or from the HOSE to a
firm. The Contra Firm field should be filled with zeroes if the
message is to be transmitted to the HOSE. The Contra firm field will
contain zeroes for admin messages transmitted from the HOSE to a
broker. The Trader ID (sender) field is required and must contain the
ID of the user who sent the admin.The Trader ID (receiver) field is
optional and is used to address admins to a specific user at another
broker firm.

Message 3B - Put-Through Deal Reply

Field Size Type
1. Message Type 2 "3B"
3. Confirm number 6 Numeric String
5. Client ID (Buyer) 10 Alphanumeric
String
6. Reply Code 1 Alpha string
7. Filler 4
10. Broker Mutual Fund Volume 8 Numeric String
12. Filler 32
Total 95
This message is sent by the buying firm to indicate approval or

disapproval of a Two-Firm put-through deal after receipt of a Put-
through Acknowledgment Message from HOSE’s trading system. If the
buyer approves the deal a Client ID, Port/Client Flag must be entered.
After the deal is either approved or disapproved by the buyer, HOSE’s
trading system will send this message to the seller. If the deal is
disapproved by the HOSE, HOSE’s trading system will send this message
to both the buyer and the seller.
Reply Code
A = Approve
C = Contra Disapprove
S = HOSE Disapprove

Message 3C - Deal (Put-Through) Cancel Request
Field Size Type

Total 27
This message is sent by the seller to request cancellation of a put-

through deal. It is also used by the HOSE to forward this request to
the buyer. The buyer will then reply with 3D. When this message is
from the seller to the HOSE, field Contra Firm refers to the buyer and
field Trader ID is the trader ID of the seller making the request.
When this message is from the HOSE to the buyer, field Firm is the
Buyer, field Contra Firm is the seller, and the field Trader ID is the
trader ID of the buyer.
HOSE will not check “Side” in message 3C, if other fields is validated
correctly by HOSE system. “Side” in original message by seller will be
forwarded to buyer.

Message 3D - Deal Cancel Reply

Field Size Type
4. Reply Code 1 Alpha string
Total 12
This message will be sent whenever a deal is cancelled. For deals

involving two different brokers, the buyer will send this message to
the HOSE to reply to a Deal Cancel Request message, which was sent by
the seller. The HOSE will send this message to the seller to inform
him of the buyer's and the HOSE's reply to his request for a deal
cancellation. For deals involving only one broker the HOSE will send
this message to that broker to reply to a Deal Cancel Request.

Message RN - Retransmission Nack

Field Size Type
1. Message Type 2 "RN"
2. Firm 2 Mod-96
3. Error code 2 Alpha numeric
4. Original Message Text 478 Alpha string
Total 484
This message will be sent back to the originator including with the
error code and original test when a retransmission request is
incorrected. The rejected reason is described in an error code.

Message RP - Retransmission Reply

Field Size Type
1. Message Type 2 "RP"
2. Firm 2 Mod-96
3. Market ID. 1 Alpha String
4. Previous Sequence Number 3 Mod-96
5. Sequence Number 3 Mod-96
6. Message Count 1 Mod-96
7. Original Broadcast Message 472 Alpha string
Total 484
This message is used to retransmit broadcast messages to a firm upon

request. The market ID. represents the market code. The Sequence
Number field contains the sequence number of the original broadcast
message block. The Previous Sequence Number field will indicate the
broadcast sequence number of the message block which was transmitted
just before the block being retransmitted in this message. The Count
field indicates the number of messages in the block being
retransmitted. For the first message in the retransmission session,
the Previous sequence number field will contain a zero. In order to
maintain the integrity of the retransmission data packet, the Unit-
Separator (US) characters in the original broadcast message will be
replaced by the BELL (BEL) character.

Message RQ - Retransmission Request

Field Size Type
1. Message Type 2 "RQ"
2. Firm 2 Mod-96
3. Market ID. 1 Alpha String
4. Retransmission Start Sequence 3 Mod-96
5. Retransmission End Sequence 3 Mod-96
Total 11
This message allows a firm to request a retransmission, via the CTCI

line of broadcast messages from the Retransmit start sequence number
to the Retransmit end sequence number. The Modulo-96 coding scheme
will be retained for the sequence numbers in this request in order to
expedite retransmission processing.

2. Broadcast Messages Descriptions
Message AA - Advertisement Announcement

Field Size Type
1. Message Type 2 "AA"
2. Security Number 2 Mod-96
3. Volume 4 Mod-96
4. Price 13 AlphaNumeric String
5. Firm 2 MOd-96
6. Trader 3 Mod-96
7. Side 1 Alpha String
9. Time 3 Mod-96
10. Add/Cancel Flag 1 Alpha String
11. Contact 20 AlphaNumeric String
Total 52
An Advertisement Announcement will be broadcast to all brokers

whenever an advertisement is entered or removed from the system.

Message BR - Broker Reconcile

Field Size Type
1. Message Type 2 "BR"
2. Firm 2 Mod-96
3. Market ID 1 Alpha-numeric string
4. Volume Sold 10 Alpha-numeric string
5. Value Sold 14 Alpha-numeric string
6. Volume Bought 10 Alpha-numeric string
7. Value Bought 14 Alpha-numeric string
Total 53
This message is sent during EOD to help broker reconcile their trading
data. It tells each broker how many shares and how much money they
have bought and sold up to that point.
The sequence of the broadcast messages during EOD will be:
SC message (Code G)
SU,...,SU messages (1 for each security)
SC message (Code J)
(about 3 minutes later)
SC message (Code T)
BR,...,BR messages (1 for each broker)
SC message (Code U)
Message "End-of-Day Broadcast Transmissions Complete"
Message "Begin End-of-Day Procedure Now"

Message BS - Broker Status Change

Field Size Type
1. Message Type 2 "BS"
2. Firm 2 Mod-96
3. AutoMatch Halt Flag 1 Alpha string
4. Put through Halt Flag 1 Alpha string
Total 6
This message is sent when a broker is halted or unhalted from trading.

Message CO - Cancel Odd Lot

Field Size Type
1. Message Type 2 "CO"
2. Reference Number 3 Mod-96
Total 5
This message is sent whenever an odd-lot order is cancelled. An odd-

lot order is referred to by its reference number.

Message DC - Deal Cancellation Notice

Field Size Type
1. Message Type 2 "DC"
2. Confirm Number 3 Mod-96
4. Volume 4 Mod-96
5. Price 4 Mod-96
Total 16
A Deal Cancellation Notice is broadcast to notify brokers when a deal

has been cancelled. Only Put-through deals may be cancelled.

Message GA - General Admin

Field Size Type
1. Message Type 2 "GA"
2. Admin message length 1 Mod-96
3. Admin message text 70 AlphaNumeric String
Total 73
A General Admin Message will be used to broadcast administrative

information to all firms from the HOSE.

Message IU - Index Update

Field Size Type
1. Message Type 2 "IU"
2. Index – HOSE 4 Mod-96
3. Total Trades 4 Mod-96
4. Total Shares Traded 5 Mod-96
5. Total Values Traded 5 Mod-96
6. Up Volume 5 Mod-96
7. Down Volume 5 Mod-96
8. No Change Volume 5 Mod-96
9. Advances (no. of stocks) 2 Mod-96
10. Declines (no. of stocks) 2 Mod-96
11. No Change (no. of stocks) 2 Mod-96
12. Filler 4
13. Market ID 1 Alpha String
14. Filler 7
15. Index – Time 3 Mod-96
Total 56
The HOSE index will be broadcast to all brokers at timed intervals.

Currently this is every 1-minute during the trading period and a few Comment [PG1]: Page: 42
minutes after the intermission or the run-off period is entered. This Check with Ruby
message is not sent during the pre-open period.
Comment [PK2]: Page: 42

Message LO - Last Odd Lot

Field Size Type
1. Message Type 2 "LO"
4. Odd Lot Volume 2 Mod-96
5. Price 4 Mod-96
Total 16
This is similar to LS message but it is for odd-lot orders. It is

sent when an odd-lot order is matched and a deal is created.

Message LS - Last Sale

Field Size Type
1. Message Type 2 "LS"
4. Lot Volume 4 Mod-96
5. Price 4 Mod-96
Total 16
A Last Sale Message will be broadcast whenever a match takes place in

the HOSE’s trading system during a trading session. Individual Last
Sale Messages of this type are only used after the opening is complete
for the security. One last sale will be generated for each match.
LS that has been actuated by pre-open market match will be sent out
with Side=‘ ‘. LS that has been actuated by open market match will be
sent with side = contra side ( if buy order make a transaction, LS
will be sent out with side = ‘S’ )

Message NH - News Headline

Field Size Type
1. Message Type 2 "NH"
2. News number 2 Mod-96
3. Security Symbol 8 AlphaNumeric String
4. News headline length 1 Mod-96
5. Total News Story Pages 2 Mod-96
6. News headline text 70 AlphaNumeric String
Total 85
Each news headline and the associated story will be assigned a unique
news story number by the HOSE trading system. If the News relates to
a particular security, This message is sent at the same time as its
related News Story Message. Note: a news headline MUST have a related
news story.

Message NS - News Story
Field Size Type

1. Message Type 2 "NS"
2. News Number 2 Mod-96
3. News Page Number 2 Mod-96
4. News Text Length 2 Mod-96
5. News Text 215 AlphaNumeric String
Total 223
A News Story Message will contain the details of a news story. If a

news story contains more than one page, multiple news story messages
will be sent. A News Story Message is sent at the same time as its
News Headline Message.

Message OL - New Odd Lot

Field Size Type
1. Message Type 2 "OL"
3. Odd Lot Volume 2 Mod-96
4. Price 4 Mod-96
Total 14
This message is sent whenever a new odd-lot order arrives at the HOSE.
It is broadcast to all brokers so they can update their book. Note
that this is different from the way a main board order is handled.

Message OS - Market Open Last Sale

Field Size Type
1. Message Type 2 "OS"
3. Price 4 Mod-96
Total 8
One Market Open Last Sale Message will be broadcast for each issue
during the opening cycle. If no matches take place in a security at
the open, a last sale message will be sent out with the price of zero.
In this case, a later deal in this issue will cause this message to be
sent out to indicate the eventual first last sale (to be considered
the opening price).
A Market Open Last Sale Message will be broadcasted twice a day during
the market open cycle.
 If no security deals are matched at the opening time (both

during the morning or afternoon session), this message will send
blank in price field.
 If there is an opening price of stock in the morning session,

this price is considered to be an opening price of stock in that
day.
 If there is no trading in the morning session but in the

afternoon session has an opening price of stock, this price is
considered to be an opening price of stock.

Message PD - Put-Through Deal Notice

Field Size Type
1. Message Type 2 "PD"
4. Volume 4 Mod-96
5. Price 4 Mod-96
Total 16
A Put-Through Deal Notice is broadcast for each put-through deal that

is accepted and approved.

Message PO - Projected Open

Field Size Type
1. Message Type 2 "PO"
3. Projected Open Price 4 Mod-96
Total 8
Projected Open messages will be broadcast throughout the Preopen

period to inform brokers of changes in the price at which each
security is expected to open based upon the orders currently on the
Main Board. The "PO" message will be sent only for securities that
are expected to have matches at the open.

Message SC - System Control

Field Size Type
1. Message Type 2 "SC"
2. System Control Code 1 Alpha string
3. Timestamp 3 Mod-96
Total 6
This message will be broadcast when a system controlled event occurs

such as when the market opens or breaks.

Message SI - Sectoral Indices

Field Size Type
1. Message Type 2 "SI"
2. Index - Sectoral 1 4 Mod-96
3. Filler 120
4. Index – Time 3 Mod-96
Total 129
The various sectoral indices will be broadcast to all brokers at timed

intervals. (Same as the way IU is sent. See message IU for details.)

Message SR - Security Reconcile

Field Size Type
1. Message Type 2 "SR"
3. Main or Foreign Deal 3 Mod-96
4. Main or Foreign Acc-Volume 5 Mod-96
5. Main or Foreign Acc-Value 5 Mod-96
(in 1,000)
6. Deals in Big Lot Board 2 Mod-96
7. Big Lot Acc-Volume 5 Mod-96
8. Big Lot Acc-Value (in 1,000) 4 Mod-96
9. Deals in Odd Lot Board 2 Mod-96
10. Odd Lot Acc-Volume 3 Mod-96
11. Odd Lot Acc-Value 3 Mod-96
Total 36
This message helps brokers reconcile trading data. It is sent, one

for each security, during the intermission and EOD.

Message SS - Security Status Change

Field Size Type
1. Message Type 2 "SS"
3. Filler 1
4. Sector Number 1 Mod-96
5. Filler 1
6. Halt/Resume Flag 1 Alpha string
7. System Control Code 1 Alpha string
8. Filler 1
9. Suspension 1 Alpha string
10. Delist 1 Alpha string
11. Filler 1
12. Ceiling 4 Mod-96
13. Floor Price 4 Mod-96
14. Security Type 1 Alpha string
15. Prior Close Price 4 Mod-96
16. Filler 4 Mod-96
17. Split 1 Alpha string
18. Benefit 1 Alpha string
19. Meeting 1 Alpha string
20. Notice 1 Alpha string
21. Board Lot 2 Mod-96
22. Filler 1
Total 37
A Security Status Change message will be broadcast during trading

hours to inform members of trading status changes, which may occur.
The Security Number field will identify the security, which has a
status change.
Security Status Change Message will be broadcasted during the trading

hours to inform members on any changes of trading status that may
possibly occur. The Security Number field will indicate whether any
specific security has its status change.

Message SU - Security Update

Field Size Type
1. Message Type 2 "SU"
2. Security Number (Old) 2 Mod-96
3. Security Number (New) 2 Mod-96
4. Filler 1
5. Sector Number 1 Mod-96
6. Filler 1
8. Security Type 1 Alpha string
9. Ceiling Price 4 Mod-96
10. Floor Price 4 Mod-96
11. Last Sale Price 4 Mod-96
12. Market ID 1 Alpha String
13. Filler 3
14. Security Name 25 Alpha string
15. Filler 1
16. Suspension 1 Alpha string
17. Delist 1 Alpha string
18. Halt/Resume Flag 1 Alpha string
19. Split 1 Alpha string
20. Benefit 1 Alpha string
21. Meeting 1 Alpha string
22. Notice 1 Alpha string
23. Client ID Required 1 Alpha string
24. Par Value 4 Mod-96
25. SDC Flag 1 Alpha String
26. Prior Close Price 4 Mod-96
27. Prior Close Date 8 Numeric String
28. Open Price 4 Mod-96

29. Highest Price 4 Mod-96
30. Lowest Price 4 Mod-96
31. Total Shares Traded 5 Mod-96
32. Total Values Traded 5 Mod-96
33. Board Lot 2 Mod-96
34. Filler 1
Total 110
SU messages are sent during EOD to give the closing information of all
securities. This message is never sent during trade.
The sequence of the broadcast messages during EOD will be:
SC message (Code G)
SU,...,SU messages (1 for each security)
SC message (Code J)
For SU message transmitted after market closes, all fields are values
announced to support tomorrow trading. If the security is not traded
on that day, field Last Sale Price will be the same as Prior Close
Price.

If the security has already listed in the HOSE, Field Security Number
and Security Number (New) will be always the same.
In case of new stock, Security Number and Security Number (New) will
be different. The Field: Security Number (New) will contain security
number of new stock and be sent through SU message (after market
closed) 1 day in advance while the Field: Security Number will be
blank.

Message TC - Trader Status Change

Field Size Type
1. Message Type 2 "TC"
2. Firm 2 Mod-96
3. Trader ID 3 Mod-96
4. Trader Status 1 Alpha string
Total 8
This message is sent when a trader is suspended or unsuspended or

allow or not allow trader send Big-lot PT which price is not between
ceiling and floor.

Message TP - Top Prices

Field Size Type
1. Message Type 2 "TP"
4. Price 1 (best) 4 Mod-96
5. Lot Volume 1 4 Mod-96
6. Price 2 (2nd best) 4 Mod-96
8. Price 3 (3rd best) 4 Mod-96
Total 29
This message is sent whenever there are any changes in top three bid /
offer prices or volume of a security. Anyway, from time to time,
this message will be periodically sent out the prices / volume of all
stocks that do not have any changes in their top three prices.
According to the At-The-Open (ATO) and At-The-Close (ATC) orders are
queued for matching prior to “Limit-Price Order”, the bid / ask prices
of ATO and ATC orders will be first transmitted (1st Best Bid/Offer).
Their prices will be transmitted as zero (0) while the volumes will
not be zero (0).
To display the price of ATO and ATC orders on the displayed screens,
the HOSE would like to ask the members a cooperation to display the
price as follows:
 To display the price as “ATO” for all orders sent during Pre-
Open sessions (both morning and afternoon sessions) that specify
price as opening price.
 To display the price as “ATC” for all orders sent during the
Call Market period (in afternoon session) that specify price as
closing price.

Message TR – Foreign Room

Field Size Type
1. Message Type 2 "TR"
3. Total Room 6 Mod-96
4. Current Room 6 Mod-96
Total 16
This Foreign Room Message will be broadcast when

 At the beginning of trading day, sent by operation.
 AOM - After market changes from Pre-open to Open, whenever a
match (foreign bid) is taking place in the trading system.
 AOM - After market open, whenever a match (foreign bid) is
taking place in the trading system.
 Put through - whenever a Put through deal (foreign bid - local
offer) is taking place in the trading system.
 Put through - whenever a cancelled Put through deal (foreign bid
– local offer) is taking place in the trading system.
This message will tell you how many rooms are available for you and it
will be generated for each match.

Message TS - Time Stamp

Field Size Type
1. Message Type 2 "TS"
2. Timestamp 3 Mod-96
Total 5
A Timestamp Message will be broadcast every minute during idle periods

over the broadcast line to assure member firms that the system is up.

3. Messages Field descriptions
Add/Cancel Flag
A 1 character alpha field that indicates whether the transaction
should be added to or removed from the trading data files.
Possible values:
"A" Add
"C" Cancel
CTCI: 1E
Broadcast: AA
Advances
A 2 character numeric field in modulo-96 format that indicates the
number of securities that is up in price for the day. This is
compared against the closing price of the previous trading day.
Possible Values:
0 <= n <= 9,215
CTCI: None
Broadcast: IU

Benefit
A 1 character alphabetic field which indicates that a security is
trading without (Ex) the previous benefit.
Possible values:
" " Not Applicable
"A" Ex-Dividend and Ex-Rights
"D" Ex-Dividend
"R" Ex-Rights
CTCI: None
Broadcast: SU, SS
Board
A 1 character Alpha field that identifies the trading board.
Possible Values:
"B" Big-lot board
"M" Main board
"O" Off-hour board
CTCI: 1E, 1F, 1G, 1I, 2F

Broadcast: AA, PD, DC
Board Lot
board lot size (number of shares required to make one lot) of a
security.
Possible values:
1 <= n <= 9,215
CTCI: None
Broadcast: SS, SU
Broker Client Volume, Broker Foreign Volume, Broker

Portfolio Volume
The number of shares for equity securities and the number of bonds for
debt securities that changed hands by such investor during the trading
period. (See Volume)
Possible values:
1 <= n <= 84,934,655 (encoded integer)
CTCI: 8 bytes 1F, 1G, 3B

Broadcast: None
Cancel Confirm
A 6 character numeric field that identifies the confirm number of a
deal that is to be cancelled or corrected. (see Confirm)
CTCI: 3C, 3D
Broadcast: None


Cancel Shares
An 8 character numeric field used to indicate the number of shares
that were successfully cancelled from the order. If the order has not
been matched, this should be the total volume. If the order has been
partially matched, this should be the remaining leaf.
CTCI: 2C
Broadcast: None
Ceiling Price
A 4 character numeric field in modulo-96 format that contains the
highest price at which a security may trade on the Main board for the
next trading day. Same format as price field. Ceiling price is
represented in units of 1/100 point. Thus the actual ceiling price
value is computed by dividing the value by 100. (see Price)
CTCI: None
Broadcast: SS, SU
Client ID
A 10 character alphanumeric field that will contain the Client Account
ID used internally by the broker firm. This information is required as
defined in the HOSE’s rules.
Possible values:
- The first three Char is broker no or custodian
- The fourth Char is corresponding to pc flag.
- The rest of Char is other value.
- No Space
PC Flag Fourth Char First three Char

P P broker no
C C broker no
M A local custodian symbol
M B custodian symbol
F F custodian symbol or broker
no
F E foreign custodian symbol
CTCI: 1D, 1F, 1G, 1I, 2D, 3B

Broadcast: None
Client ID Required
A 1 character alpha code associated with a security. When this code
is set to "Y", all orders input for this security must contain the
Client ID.
Possible values:
" " Not Applicable (Client ID not required)
"Y" Client ID required on all new orders input for this security
CTCI: None
Broadcast: SS, SU


Confirm Number
A number assigned by the HOSE’s system, which is used to uniquely
identify every deal. All subsequent references to that deal will use
confirm number to identify the deal.
Possible Values:
1 <= n <= 884,735
CTCI: 6 bytes. 2E, 2F, 2I, 2L, 3B, 3C, 3D

Broadcast: 3 bytes (mod-96) DC, LE, PD
Contact
A 20 characters field indicates broker’s contact person and telephone
number.
CTCI: 1E
Broadcast: AA
Contra Firm
A 2 character numeric field that indicates the firm on the opposite
side of a deal or message. (see Firm)
Possible Values:
1 <= n <= 9215 < if 2 bytes Mod-96 >
1 <= n <= 999 < 3 bytes Numeric String >
CTCI: 1G, 2F, 2L, 3C

Broadcast: None
Current Room
A 6-byte numeric field in modulo-96 format that identifies the number
of current room left after executing.
Possible values:
0 <= n <= 782,757,789,695
CTCI: None
Broadcast: TR
Deal ID
A 5 digit numeric field whose value is assigned by the Broker System
when a One or Two Firm Put-Through Deal is entered. HOSE’s trading
system returns the Deal ID on various messages to assist the Broker
System in looking up the original Put-Through record. The HOSE’s
system does not check the Deal ID.
From DCTERM, Deal ID is Blank.
CTCI: 1F, 1G, 2L, 3B

Broadcast: None

Declines
number of securities that are down in price for the day. This is
compared against the closing price of the previous trading day.
Possible Values:
0 <= n <= 9,215
CTCI: none
Broadcast: IU
Delist
A one character Alpha field indicates flag in a security.
Possible values:
" " Not Applicable
"D" Delist Security, the security is delisted (unavailable in
exchange)
CTCI: None
Broadcast: SS, SU
Down Volume
total shares traded so far today in securities which are down in
price. Down volume is represented in units in 1,000. Thus the actual
down volume value is computed by multiplying the value with 1,000.
Possible values:
0 <= n <= 8,153,726,975
CTCI: None
Broadcast: IU
Error code
A 2-byte numeric field that indicates an error of retransmission to
indicate where an error was detected by the HOSE system.
Possible values:
1 <= n <= 99
01 Illegal RQ Length
02 Illegal RXMT message type
03 Illegal Broker No
04 Repetition RXMT request > maximum limit
05 Start Sequence > End Sequence
06 Last RXMT sequence >= Start Sequence
07 No. of RXMT sequence (End - Start) > Maximum Limit
08 Broadcast log file is null
09 End Sequence > Last Sequence of HOSE
10 Not found start sequence
99 Undefined Error

CTCI: RN
Broadcast: none
Filler
A set of blank character contains no information.
CTCI: 1D, 1F, 1G, 1I, 2D, 2E, 3B

Broadcast: AA, IU, SI, SU
Firm
Current firm number assignments (as defined by the HOSE) are used.
This field identifies the firm sending or receiving the message.
Possible values:
1 <= n <= 9215 < if 2 bytes Mod-96 >
1 <= n <= 999 < 3 bytes Numeric String >
CTCI: 2 bytes. all

Broadcast: 1 byte (mod-96). AA

Floor Price
lowest price at which a security may trade on the Main board for the
next trading day. Same format as price field. Floor price is
represented in units of 1/100 point. Thus the actual floor price value
is computed by dividing the value by 100. (See Price)
CTCI: none
Broadcast: SS, SU
Halt / Resume Flag

A 1 character Alpha field that indicates whether a security is being
halted from trading or if trading is being resumed in a security.
Possible values:
" " Not Applicable
"H" Halt in both AOM and PT
“A” Halt in AOM transaction
“P” Halt in PT transaction
CTCI: None
Broadcast: SU, SS
Highest Price
A 4 character numeric in modulo-96 format that contain the highest
price created by auto-matched deal in the Main Board of the security
for the trading day. Highest price is represented in units of 1/100
point. Thus the actual highest price value is computed by dividing the
value by 100.
Possible values:
See Price
CTCI: None
Broadcast: SU
Index – HOSE
value of the corresponding index. Index value is represented in units
of 1/100 point. Thus the actual index value is computed by dividing
the value by 100.
CTCI: None
Broadcast: IU
Index Time
time sending index.
CTCI: None
Broadcast: IU, SI

Last Sale Price

A 4 character numeric field in modulo-96 format indicating the current
last sale price for a security. Last sale price is represented in
units of 1/100 point. Thus the actual last sale price value is
computed by dividing the value by 100.
CTCI: None
Broadcast: SU
Lot Volume
A 4-byte numeric field in mod-96 indicating volume of trading shares
in board lots.
Possible values:
0 <= n <= 84,934,655 (4-byte)
CTCI: None
Broadcast: LS
Lot Volume 1,2,3

A 4-byte numeric field in mod-96 indicating top 3 bid and offer
volumes (in board lots) that the HOSE broadcast to brokers. It is
sent in board lots to make the value fit within 4 bytes.
See price 1,2,3.
Possible values:
0 <= n <= 84,934,655
CTCI: None
Broadcast: TP
Lowest Price
A 4-byte numeric field in mod-96 indicating the lowest price created
by auto-matched deal in the Main Board of the security for the trading
day. Lowest price is represented in units of 1/100 point. Thus the
actual lowest price value is computed by dividing the value by 100.
Possible values:
See Price
CTCI: None
Broadcast: SU
Market ID
A 1-byte alpha string field which identifies a specific type of
market.
Possible values:
"A" SET
CTCI: None
Broadcast: IU, SU

Message Type
A 2-byte alpha string field which identifies a specific type of
message in system.
CTCI: All
Broadcast: All
Meeting
A 1 character alpha string field indicates meeting sign.
Possible values:
“M” Ex-Meeting
“ “ Not Applicable
CTCI: None
Broadcast: SS, SU
Mutual Fund Volume
See Broker Client Volume, Broker Foreign Volume, Broker Portfolio

Volume
No Change
number of securities that are not changed in price for the day. This
is compared against the closing price of the previous trading day.
Possible Values:
0 <= n <= 9,215
CTCI: None
Broadcast: IU
No Change Volume
total shares traded so far today in securities that their prices are
not changed. No change volume is represented in units in 1,000. Thus
the actual no change volume value is computed by mutiplying the value
with 1,000.
Possible values:
0 <= n <= 8,153,726,975
CTCI: None
Broadcast: IU

Notice
A 1 character alphabetic field that indicates that a security has been
asked to provide important information or has responded to a request
for information.
Possible values:
" " Not Applicable
"P" Notice Pending
"R" Notice Received
CTCI: none
Broadcast: SS, SU
Open Price
A 4 character numeric field in modulo-96 format contains the price at
which the security traded of the day. Open price is represented in
units of 1/100 point. Thus the actual open price value is computed by
dividing the value by 100.
Possible values:
see Price
CTCI: None
Broadcast: SU
Order Cancel Status

A one character string field contains the status of the canceling
order at which the security traded of the day.
Possible values:
" " Cancelled by Broker
"S" Cancelled by HOSE
CTCI: 2C
Broadcast: None
Order Entry Date

A 4 character numeric date field in "DDMM" format that indicates the
date an order was first entered into the HOSE system.
CTCI: 1C, 1D, 2B, 2C, 2D, 2E, 2I

Broadcast: None

Order Number
A unique 8 characters number assigned by the firm which is used to
identify each of the firm's orders. This field is not checked by the
HOSE system but is maintained as a way for the firm to internally
identify its orders. (Note that the range of values for this field
is restricted.)
From DCTERM, Order number is generated by system. Order Number format

is
8+ <broker no> + <running no>
<broker no> - 3 characters example 001, 012, 111 etc.
<running no> - 4 characters
Possible values:
1 <= n <= 84,934,655
CTCI: 1C, 1D, 1I, 2B, 2C, 2D, 2E, 2I

Broadcast: None
Original Message Text

A variable length alphanumeric field that will contain the original
message data when a message is returned rejected to the firm.
CTCI: 2G
Broadcast: None
Par Value
A 4 characters numeric in modulo-96 indicates par value of a security.
Par value is represented in units of 1/100 point. Thus the actual par
value is computed by dividing the value by 100.
CTCI: None
Broadcast: SU
Port/Client Flag
A 1 character Alpha field used to indicate whether an order is traded
on behalf of the broker's /sub-broker's portfolio, or for a client.
Possible values:
"C" Broker Client
"F" Broker Foreign
"M" Mutual Fund
"P" Broker Portfolio
CTCI: 1I, 2D (1F, 1G, 3B, 3C)

Broadcast: None

Price
Indicates the price of an order or deal. Prices may be whole numbers
or decimal numbers depending on how the issue involved is traded. For
example, 54.25 is valid as well as 1250. Alpha values are only
allowed in the case of ATO or MP orders.
Possible values:
"ATO" At The Open
OR "ATC" At The Close
OR "MP" Market Price (orders only)
OR 1 <= n <= 849,346 (for Broadcast)
OR 1 <= n <= 999,999.999999(for 1E, 1F, 1G, 2F, 2L,AA)
OR 1 <= n <= 99,999.99 (for 1I)
OR 1 <= n <= 99,999.99 (for 2D, 2E, 2I)
Remark : Price in Put-Through transactions such as 1F,1G are in units

of 1/1,000,000 point.
CTCI: 1E, 1F, 1G, 1I, 2D, 2E, 2F, 2I, 2L

Broadcast: AA, DC, LE, OS, PD
Price 1,2,3
A 4 character numeric field in modulo-96 format that contains top 3
bids and offers prices that the HOSE broadcast to brokers. Price 1 is
the best bid. Price 2 is the second best. And Price 3 is the third
best. Price 1,2,3 price is represented in units of 1/100 point. Thus
the actual price 1,2,3 value is computed by dividing the value by 100.
See lot volume 1,2,3.
Range: See price.
CTCI: None
Broadcast: TP
Prior Close Date

A 6 character numeric field that contains the date of the previous
close price. Format is YYYYMMDD.
Possible values:
20070312
CTCI: None
Broadcast: SU
Prior Close Price

indicates the previous closing price of a security. This price is
represented in the same format as the field "Price". Prior close price
is represented in units of 1/100 point. Thus the actual prior close
price value is computed by dividing the value by 100.
Possible values:

CTCI: None
Broadcast: SS, SU
Projected Open Price
A 4 character numeric field in modulo-96 format that indicates

the price that a security would open at based on the orders
currently in the system. Projected open price is represented in unit
of 1/100 point. Thus the actual projected open price value is
computed by dividing the value by 100.
Projected Open message will be broadcasted three times a day. First

and second transmission will be during the pre-open period (both
morning and afternoon sessions) to inform members regarding the price
of security that is projected to be an opening price, based on the
current orders available on main board.
The third transmission will be during the call market period and the
Message PO will be broadcasted as the ‘projected close price’ instead
of ‘projected open price’
Possible values:
CTCI: None
Broadcast: PO
Published Volume
An 8 character field that indicates how many shares of an order are
available to the market.
Possible values:
CTCI: 8 bytes. 1I, 2D

Broadcast: none
Reject Reason Code:

A 2 character numeric field used to indicate to a firm the reason a
requested action could not take place.
Possible values:
00 “MP order without contra-side”
01 “Illegal price spread”
02 “Incorrect volume for specified board”
03 “Illegal request - Market Closed”
04 “Incorrect Stock Symbol”
05 “Incorrect Firm”
06 “Incorrect Trader ID”
07 “Incorrect confirm number”
08 “Too late to perform requested action”
09 “Incorrect Reference Number”
10 “Incorrect Conditions”
11 “Trading halted in Stock”

12 “Incorrect Board”
13 “Missing Client ID”
14 “Incorrect Order Type”
15 “Incorrect Port / Client flag”
16 “Incorrect Request Code or Reply Code”
17 “Incorrect Side: must be Buy or Sell”
18 “Incorrect Order Number”
19 “Incorrect Time”
20 “Incorrect Date”
24 “Security suspended”
25 “Missing P/C Flag”
27 “No available room for Thai Trust Fund”
28 “Market in Intermission”
29 “Market Halted”
31 “Changing Deal information disallowed”
33 “Trading disallowed for this stock”
34 “Incorrect price - above ceiling”
35 “Incorrect price - below floor”
36 “Put-Through price incorrect format”
37 “Cancel of automatch deal disallowed”
38 “Incorrect Volume for Put-Through deal”
41 “Illegal Market ID”
42 “Illegal Message Type/Header”
43 “Illegal Message Length”
44 “Incorrect Customer ID”
45 “Wrong Filler Value”
99 “Unidentified Error”
CTCI: 2G
Broadcast: None
Reply Code
A 1 character alpha field used to reply to a request for cancellation
or correction of a deal.
Possible values:
"A" Approval
"C" Contra broker disapproval
"S" HOSE disapproval
CTCI: 3B, 3D
Broadcast: None
SDC Flag
A flag to indicate if the security is in SDC. This field was added in
ASSET V3.0.
Possible values:
"Y" Security in SDC
"N" Security not in SDC
CTCI: None
Broadcast: SU
Sector Number


number of one of the HOSE sector groups.
Possible values:
0 <= n <= 95
CTCI: None
Broadcast: SS, SU
Security Name
A 25 character alphanumeric field that contains the full name of
a security. Name must begin with an letter A-Z. Name may include
blank and hyphen (-).
CTCI: None
Broadcast: SU
Security Number, Security Number (New)

A 2 character numeric field in modulo-96 format that identifies a
security. A unique integer value is assigned to each security traded
at the HOSE. This number can change when a security get delisted.
This is done to eliminate the empty gap in the numbering sequence. So
if there is re-sequence security number, the new security number is
generated.
Possible values:
1 <= n <= 4000 (encoded integer)
CTCI: none
Broadcast: AA, DC, LE, OS, PD, PO, SS, SU, TP, TR
Security Symbol
An 8 character alphanumeric field that contains the security symbol
that is used by the HOSE.
CTCI: 1E, 1F, 1G, 1I, 2F, 3C

Broadcast: SU
Security Type
A 1 character alphabetic field that indicates the type of security.
Possible values:
"D" Debenture
"S" Common Stock
"U" Unit Trust
CTCI: None
Broadcast: SS, SU

Side
1 character Alpha field that specifies the buying or selling side of
a transaction. This field is left blank on deal confirmation messages
that result from one firm put-through deals.
Possible values:
"X" Firm is both buyer and seller (for 2L)
"B" Buy
"S" Sell
Any value for “3C” since HOSE system will not validate side in “3C”
message
CTCI: 1E, 1I, 2E, 2F, 2L, 3C

Broadcast: AA, LE, TP
Split
Indicates that the security is trading for the first day after a stock
split has taken place.
Possible values:
" " Not Applicable
"S" Split
CTCI: None
Broadcast: SS, SU
Suspension
A one character string indicates that trading in a security has been
suspended indefinitely.
Possible values:
" " Not Applicable
"S" Security Suspended
CTCI: None
Broadcast: SS, SU
System Control Code
Description of a system controlled event.
Possible values:
" " Not Applicable
"A" Start of Recap stream, Start of Call Market
"C" Market Close, Begin Runoff Period
"F" Finish Intermission Period
"G" Begin EOD Security Update Transmission
"H" Halt all Trading
"I" Begin Intermission Period
"J" End EOD Security Update Transmission
"K" End Runoff Period
"N" Normal Trading resumed for a specified security
"O" Market Open
"P" Start of Preopen period for entire market
"R" Resume all trading
"X" Orders are not being accepted for specified security

CTCI: None
Broadcast: 1 byte. SC, SS
Time
A 6 character numeric field in the format "HHMMSS". Hours are
identified based on a 24 hour clock.
CTCI: 6 bytes. 1E
Broadcast: 3 bytes (Mod-96) AA.
Timestamp
A 3 characters string in modulo-96 indicates the time a message was
sent from the HOSE side. Timestamp format
is "HHMMSS" in 24-hour format.
CTCI: None
Broadcast: SC
Total Room
A 6-byte numeric field in Modulo-96 format that contains the total
room reserved for investor in case of Foreign Room.
Possible values:
0 <= n <= 782,757,789,695
CTCI: None
Broadcast: TR
Total Shares Traded
A 5 character numeric field in Modulo-96 format that contains the

total shares traded so far today. Total shares traded is represented
in units in 1,000. Thus the actual total shares traded value is
computed by multiplying the value with 1,000.
Possible values:
1 <= n <= 8,153,726,975
CTCI: None
Broadcast: IU, SU
Total Trades
A 4 character numeric field in Mod-96 format that contains the total
number of deals made so far today.
Possible values:
(See Confirm Number field which max at 884,735)
CTCI: None
Broadcast: IU

Total Values Traded

A 5 character numeric field in Modulo-96 format that contains the
total value (in thousand Baht) of all trades so far today. Total
values traded is represented in units in 1,000. Thus the actual total
values traded value is computed by mutiplying the value with 1,000.
Possible values:
1 <= n <= 8,153,726,975
CTCI: None
Broadcast: IU, SU
Trader ID
A 4 character field that identifies a specific user. Current Trader
ID number assignments (as defined by the HOSE) are used. This field
identifies the individual trader, as registered with the HOSE,
authorized to use the trading system.
Possible values:
xxxx : x = 0-9
CTCI: 1E, 1F, 1G, 1I, 2F, 3C

Broadcast: None
Up Volume
total shares traded so far today in securities which are up in price.
Up volume is represented in units in 1,000. Thus the actual up volume
value is computed by multiplying the value with 1,000.
Possible values:
0 <= n <= 8,153,726,975
CTCI: None
Broadcast: IU
Volume
The number of shares for equity securities and the number of bonds for
debt securities that changed hands during the trading period.
Possible values:
CTCI: 8 bytes 1E, 1I, 2E, 2F, 2I, 2L (1F, 1G, 3B)
Broadcast: 4 bytes (mod-96) AA, DC, PD

4. Message Flow Diagrams
System Control Message Flow Diagram

HOSE Firm Contra Firm
Pre-Open Period
SC code P ++++++++++>
Market Opens
SC code O ++++++++++>
Intermission
SC code I ++++++++++>
End Intermission
SC code F ++++++++++>
Pre-Open
SC code P ++++++++++>
Market Opens
SC code O ++++++++++>
Call Market
SC code A ++++++++++>
Runoff
SC code C ++++++++++>
Market close
SC code K ++++++++++>
Begin SU msg
SC Code G ++++++++++>
Send SU msg
End SU msg
SC Code J ++++++++++>
In case of
market halt:
Market Halt
SC code H ++++++++++>
Pre-Open
(If market is
halted HOSE will
resume market in
pre-open session)
SC Code P ++++++++++>

Market Pre-Open to Open Message Flow Diagram

Pre-Open
Period
<---------- 1I
2B ---------->
<---------- 1I
2B ---------->
TP ++++++++>
PO ++++++++>
Market Open
OS ++++++++>
2E/2I ---------->
2E/2I ---------->
LS ++++++++>
TP ++++++++>

Market Pre-Open to Open with ATO/ATC Orders Message Flow

Diagram
Pre-Open
Period
<---------- 1I (ATO/ATC)
2B ---------->
<---------- 1I (ATO/ATC)
2B ---------->
TP ++++++++>
PO ++++++++>
Market Open
If match
2E/2I ---------->
2E/2I ---------->
OS (not send ++++++++++>
in case ATC)
LS ++++++++++>
TP ++++++++++>
If can't
match or
something
left over
2C ---------->
2C ---------->
TP ++++++++++>

Market Pre-Open to Open with Foreign Bid Message Flow

Diagram
Pre-Open
Period
<---------- 1I*
2B ---------->
<---------- 1I
2B ---------->
TP ++++++++>
PO ++++++++>
Market Open
If match
2E/2I ---------->
2E/2I ---------->
OS ++++++++++>
LS ++++++++++>
TP ++++++++++>
If can't
match or
something
left over
2C ---------->
2C
TP ++++++++++>
Remark: 1I*-Foreign Bid (Current room is available for matching

process.)

Order Processing Message Flow Diagram

During Trade
<---------- 1I
2B/2E/2I ---------->
If top 3
TP ++++++++>
<---------- 1I
If new order
matched
2E/2I ---------->
2E/2I ---------->
LS ++++++++>
TP ++++++++>
If new order
not matched,
top 3
TP ++++++++>

MP Order Processing Message Flow Diagram

<---------- 1I (MP)
Order not
matchable
2C ---------->
Matchable
2E/2I ---------->
2E/2I ---------->
LS ++++++++>
TP ++++++++>
If remains
2D ---------->
TP ++++++++>

Foreign bid Order Processing Message Flow Diagram

<---------- 1I (Foreign
bid)
If Order
matches
2E/2I ---------->
2E/2I ---------->
LS ++++++++>
TP ++++++++>
If can't
match or
something
left over
2C ---------->

Change Order Message Flow Diagram

<---------- 1I
2B/2E/2I ---------->
<---------- 1D (change)
2D ---------->
If there have any change on the orders (fully match, partially

match or not match), it will effect to both order and deal.
If there have any change on the cancelled order, it will effect
to both order and deal.

Cancel Order Message Flow Diagram

HOSE Firm
<---------- 1I (order)
2B (order confirm) ---------->
<---------- 1C (it can be
cancelled both
remaining order and
fully order)
2C (cancel confirm) ---------->
If affect volume of
top 3 prices
TP ++++++++++>

One Firm Put-Through Deal Message Flow Diagram

HOSE Firm
(Seller=01)
<--------- 1F
2L --------->
PD +++++++++>

Cancel One Firm Put-Through Deal Message Flow Diagram

HOSE Firm
(Seller=01)
<--------- 3C
 If HOSE
disapprove
3D (code S) --------->
 If HOSE
approve
3D (code A) --------->
DC +++++++++>
 If HOSE not No further

approve or not message will
disapprove be sent from
system, it
will be put-
through deal

Two Firm Put-Through Deal Message Flow Diagram

(seller=01) (buyer=02)
<--------- 1G
2F --------->
 If contra
disapprove
<--------- 3B (code C)
3B(C) ---------> --------->
 If contra
approve
<--------- 3B (code A)
2L ---------> --------->
PD +++++++++>
 contra approve
Foreign bid,
but not enough
room
<--------- 3B (code A)
3B (code S) ---------> --------->
 If contra not No further

approve / message will
system, it
will be
pending
approval

Cancel Deal (Two Firm Put-through only) Message Flow

Diagram
(seller=01) (buyer=02)
<--------- 3C
3C --------->
 If contra
disapprove
<--------- 3D (code C)
3D(C) --------->
 If contra approve
<--------- 3D (code A)
- If HOSE
disapprove
3D(S) ---------> --------->
- If HOSE approve
3D(A) ---------> --------->
DC +++++++++>
- If contra No further
approve but HOSE message will
not approve or be sent from
not disapprove system, it
will be put-
through deal
 If contra not No further

approve or not message will
system, it
will be put-
through deal

Advertisement Message Flow Diagram

HOSE Firm
<--------- 1E
AA +++++++++>

5. Unit of Value
Unit in 1000
A 6 character numeric field in modulo-96 format that contains value
divides by 1,000.
Example: the actual value is 100,000
Unit in 1000 is 14 [modulo-96 (100,000/1,000)]
Thus to find the actual value, this field must demodulo-96 first then
multiply with 1,000.
CTCI: None
Broadcast: IU, SU
Unit 1/100 point

A 4 character numeric field in modulo-96 format that contains value
multiplies with 100.
Example: the actual value is 10
Unit 1/100 point is *H [modulo-96 (10*100)]
Thus to find the actual value, this field must demodulo-96 first then
divide by 100.
CTCI: None
Broadcast: DC, IU, LE, OS, PD, PO, SI, SS, SU, TP
Unit 1/1,000,000 point

A 12 character numeric field that contains value multiplies with
1,000,000(6 digit decimal).
Example: the actual value is 1,234.50
Unit 1/1,000,000 point is 1234500000 [1,234.50*1,000,000]
Thus to find the actual value, this field must divide by 1,000,000.
CTCI: 1E, 1F, 1G, 2F, 2L

Broadcast: None

Summary of Messages by Period
Before Pre- Open Break Pre- Open Call Run- Close Begin End Eod
CTCI Messages PreOpen Open Open off SU SU
System Code C P O I p O A C K G J
1C - Order Cancellation Yes Yes Yes Yes Yes
1D - Order Change Yes Yes Yes Yes Yes
1E - Advertisement Yes Yes Yes Yes
Announcement
1F - One Firm Put-Through Yes Yes Yes Yes
Deal
1G - Two Firm Put-Through Yes Yes Yes Yes
Deal
1I – New Order Yes Yes Yes Yes Yes
2B - Order Confirmation Yes Yes Yes Yes Yes

2C - Confirmation of Order Yes Yes Yes Yes Yes
Cancellation
2D - Confirmation of Order Yes Yes Yes Yes Yes Yes
Change
2E - Confirmation of Deal Yes Yes Yes
2F - Put-Through Yes Yes Yes Yes
Acknowledgement
2G - Reject Yes Yes Yes Yes Yes Yes Yes Yes
2I - Confirmation of Crossing Yes Yes Yes
Deal
2L - PT Deal Confirmation Yes Yes Yes Yes
3B - Put-Through Deal Reply Yes Yes Yes Yes

3C - Deal Cancel/Change Yes Yes Yes Yes
Request
3D - Deal Cancel/Change Yes Yes Yes Yes
Reply

Summary of Message by Period (continued)
Before Pre- Open Break Pre- Open Call Run- Close Begin End Eod
Broadcast Messages PreOpen Open Open off SU SU
System Code C P O I P O A C K G J
Advertisement Announcement Yes Yes Yes Yes
(AA)
Deal Cancellation Notice (DC) Yes Yes Yes Yes
Index Update (IU) Yes Yes Yes Yes Yes Yes Yes
Last Sale(LS) Yes Yes Yes
Market Open Last Sale (OS) Yes Yes
Put Through Deal Notice (PD) Yes Yes Yes Yes
Projected Open (PO) Yes Yes Yes
System Control (SC) Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Sectoral Index (SI) Yes Yes Yes Yes Yes Yes Yes
Security Status Change (SS) Yes Yes Yes Yes Yes Yes Yes Yes Yes
Security Update (SU) Yes
Top Prices (TP) Yes Yes Yes Yes Yes Yes Yes
HOSE’s trading system has ability to configure trading session.
Current Market Session Configuration

Preopen -> Open -> Call -> Run-off -> Close
Current Trading Session

Before Pre- Open Call Run- Close Begin End Eod
Broadcast Messages PreOpen Open off SU SU
As a result, Message such as SC Code I will not be sent out from current HOSE’s system since there is no Break Session.

Modulo-96 numbers
Length Maximum Value
1 byte 95
2 bytes 9,215
3 bytes 884,735
4 bytes 84,934,655
5 bytes 8,153,726,975
6 bytes 782,757,789,695

Message Flow between Exchange and Broker-firm
Broker
Front system
A’, B’
Broadcast
Exchange
B system
DCTerm
B’
CTCI(A,A’,B,B’)
CTCI
PRS
PRS
Remark :
 A is Message from broker’s front office system, and A’ is response

message of A.
 B is Message from DCTerm, and B’ is response message of B.

Revision
18-March 2008
1. Modify Summary of Messages by Period (p108)

Detail for HOSE’s system ability to configure trading session.
2. Message flow Diagram (p92-98)

- Add SC code A (Call Market), and remove SC code R (using SC code
P after resume from halt market) (p92)
- Change flow LE _> LS (p93-98)
3. Modify Two Firm Put-Through Deal Message Flow Diagram (p103)
- Add flow when Buyer approve but not enough room
4. Add More detail on Message 2L (p35), side values.
5. Add More detail on Message LS (p51), side values.
6. Validate Message Type ‘RQ’ (p42)
7. Add Diagram of Message flow between Exchange and Broker-firm (p110)
8. Remove remark from Message 3A specification (p36)
19-March 2008
1. Add detail for Side usage in message “3C” (p38)
2. Add detail for Side description (p78)
7-May 2008
1. Change cancel PT flow from 1F->3C (p102)
2. Change order number description to fit 3 chars firm (p82)
9-July 2008
1. Change Type of Deal ID in Message 1F from Alphanumeric String to
Numeric String (p25)
15-July 2008
1. Add Error-code description for RN message(p75)
2. Modify Connection Termination, Protocol State Diagram (p12-p14)
3. Modify Auto-t message format (p8-p9)
05-Jan 2011
1. Change the length of Volume 1,2,3 in TP message from 3 byte to 4
byte (encoded)
2. Change the length of Lot Volume in LS messsage from 3 byte to 4
byte (encoded)
3. Halt / Resume Flag in SS message has these values: blank, “A”, “P”,
“H”

SpecProtocolAndMessage 20110105

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SpecProtocolAndMessage 20110105

Încărcat de

Drepturi de autor:

Formate disponibile

The Hochiminh Stock Exchange Trading Protocol Specification

HOSE Trading System

Protocol & Message Specification

The Stock Exchange of Thailand Page 1

HOSE Trading System ................................................. 1

The Stock Exchange of Thailand Page 2

The Stock Exchange of Thailand Page 3

Total Values Traded 88

The Stock Exchange of Thailand Page 4

Part I : Protocol Specification

1. Online-trading Protocol (AUTO-t Protocol)

AUTO-t Protocol is a 2-tier application-level protocol used for transferring transactions

The application protocol is designed with the following criteria:

The Stock Exchange of Thailand Page 5

The Stock Exchange of Thailand Page 6

3.1 AUTO-t Message Format

Len Seq AckSeq Opcode Link ID Content ETX

As AUTO-tP relies on TCP, a stream protocol, it is a duty of an application program to detect a

Field Name Field Length Field Type Field Description

2With a 4-byte field, the sequence number to grow up to 84,934,656

The Stock Exchange of Thailand Page 7

link-ID: the error-

A packet format, the content part in particular, depends on its opcode:

The Stock Exchange of Thailand Page 8

3.2 Connection Establishment

3.2.1 The protocol

The protocol will be:

3.2.1.2 The server checks if the client needs any recovery:

3.2.1.3 Server sends HELLO_REPLY: ServSeq:ServAck

3.2.1.4 The client checks if the server needs any recovery.

The Stock Exchange of Thailand Page 9

All possible connection modes are:

Exchange Broker Action(s)

The Stock Exchange of Thailand Page 10

Client’s 1 Lin e H and ler

figure 2: authentication database

3.3 Data Transfer

3.3.1 Sliding window

3.3.2 Broadcast Retransmission

The Stock Exchange of Thailand Page 11

retransmission request will actually be processed by another process, for example

RETRAN_REQ Mkt retran request message

When a broker wants to request broadcast message retransmission.

RETRAN_REPLY Mkt retran broadcast message

When an exchange wants to send broadcast retransmission data.

figure 3: broadcast retransmission scheme

3.3.3 Echo command

3.4 Connection Termination

The protocol will be:

The Stock Exchange of Thailand Page 12

For the side who receives a termination request:

3.5 Protocol State Diagram

START snd: NACK STOP Protocol State Diagram

snd: DATA, ACK

rcv: DATA, ACK 15 STOP

The Stock Exchange of Thailand Page 13

snd: ACK, NACK, 13

State Diagram during Data Transfer State

figure 5: Protocol State Diagram

3.6 Implementation Issues

 An application should stop:

The Stock Exchange of Thailand Page 14