ICS 03.060
A11
Filing No.
JR
Standard of the Financial Industry of the People's Republic of China
JR/T 0087—2012
Data Exchange Protocol for Stock Index Futures between Funds and Futures
Promulgated on December 26, 2012
Issued by t he Chi na Secur i t ies Regul at or y Co mmi ssi on
Effective on December 26, 2012
JR/T 0087—2012
Table of Contents
Forward .......................................................................................................................................................III
Introduction ................................................................................................................................................ IV
1. Scope .........................................................................................................................................................1
2. Inclusion by References ............................................................................................................................1
3. Terms and Definitions ...............................................................................................................................1
4. Methods of Communication ......................................................................................................................2
5. Message Format ........................................................................................................................................2
6. Safety and Encryption ...............................................................................................................................6
7. Data Integrity.............................................................................................................................................7
8. Mode of Expansion ...................................................................................................................................7
9. Definition of Message ...............................................................................................................................8
10. Field Definitions ....................................................................................................................................48
11. Format of Settlement Data Files ............................................................................................................98
Schedule A ................................................................................................................................................111
Schedule B.................................................................................................................................................113
B.1 Logon for FIX Session........................................................................................................................113
B.2 Logout .................................................................................................................................................114
B.3 Resend ................................................................................................................................................114
B.4 Resend Request...................................................................................................................................115
B.5 Heartbeat and Test Request ................................................................................................................117
Schedule C.................................................................................................................................................118
C.1 New Order-Single Scenario Graph .....................................................................................................118
C.2 Order Cancel Scenario Graph .............................................................................................................119
Schedule D ................................................................................................................................................120
Schedule E .................................................................................................................................................121
E.1 FIX Session .........................................................................................................................................121
E.2 Connection ..........................................................................................................................................122
E.3 FIX Session Messages ........................................................................................................................126
JR/T 0087—2012
Forward
This standard (“Standard”) is drafted in accordance with the rules set out in GB/T1.1-2009.
The China Finance Standardization Technical Committee Securities Sub-Committee has proposed the
Standard.
The China Finance Standardization Technical Committee is responsible for the administration of the
Standard.
The Standard is drafted by : Asset Management Association of China, Securities Association of China,
China Futures Association, China Futures Margin Monitoring Center Co., Ltd. , Shenzhen Securities
Communication Co., Ltd., Bosera Asset Management Company Limited, Dacheng Fund Management
Co., Ltd., Bank of Communications Schroders Fund Management Co., Ltd ,Wanjia Asset Management
Co., Ltd., CITIC-Prudential Fund Management Co., Ltd., ICBC Credit Suisse Asset Management Co.,
Ltd., Harvest Fund Management Co., Ltd., Guo Tai JunAn Futures Co., Ltd., Shanghai Orient Futures
Co., Ltd., Shanghai Futures Information Technology Co., Ltd., Sungard Co., Ltd, and Handsome
Electronics Co., Ltd.
Main drafters include: Zhong Rongsa, Zheng Fushi, Zhang Zhe, Liu Tiebin, Xie Wenhai, Xie Chen,Wang
Shusong, Chen Jiaju, Zhang Shaolian, Lv Bin, Chen Zongyan, Chen Yixin, Wan Xiaoying, Xiao Junwei,
Wu Lejian, Fan Jingwu, Mou Jianfeng, Zhang Yi, Gao Qian, Lin Qi, Gao Xiang, Yao Xudong, Sheng
Minghao, Deng Tingxun, and Zhou Changshun.
III
Introduction
In the Standard, the part relating to transaction data exchange protocol is drafted with reference to the
Financial Information Exchange Protocol (FIX4.2) and the Securities Trading Exchange Protocol (STEP)
and the part relating to settlement data exchange protocol is drafted with reference to the Requirements of
the Futures Margin Safekeeping System for the Data Submission of Clearing Members and Non-clearing
Members (Version 3.1) issued by the China Futures Margin Monitoring Center Co., Ltd.
The Standard will be revised in due course to keep pace with the development of the business and
technologies.
IV
JR/T 0087—2012
Data Exchange Protocol for Stock Index Futures between Funds and Futures
1. Scope
The Standard provides for the transaction and settlement data exchange protocol between fund management
companies, custodian banks and futures companies when fund management companies participate in the
stock index futures business. The transaction data exchange protocol consists of application environment,
format of message, safety and encryption, data integrity, mode of expansion, definition of message, field
definitions and others. The settlement data exchange protocol specifies the formats of 7 files, including the
customer fund file, the customer fund change file, the trading data file, the holding data file, the liquid
details file, the holding details file and the delivering details file.
The Standard is applicable to the exchange of transaction and settlement data between futures companies,
fund management companies, custodian banks and other relevant financial institutions when fund
management companies participate in the stock index futures business.
2. Inclusion by References
The following documents are necessary to the application of the Standard. Where any such document is
referred to in this Standard with a specific date, only the dated version thereof shall be applicable to the
Standard. In the case of any undated reference, the current version thereof (including a list of all
modifications made thereto) shall be applicable to the Standard.
GB/T 2659-2000 Codes for Names of Countries and Regions in the World
GB/T 12406-2008 Codes for the Representation of Currencies and Funds
GB/T 23696-2009 Securities and Related Financial Instruments-Exchange and Market Identifier Codes
3. Terms and Definitions
For the purposes of the Standard, the following definitions shall apply:
3.1 New order-single
The term “new order-single” refers to any new order from a client.
3.2 Execution Report
The term “execution report” refers to any report given to a service provider in response to the request of a
client and mainly used to confirm the receipt of an order, confirm any change in the status of an existing
order (e.g. confirmation of order cancellation), relay order status information and reject an order.
3.3 Client Orders Identity
The term “client orders identity” refers to an identifier of order assigned by a client, the uniqueness of
1
JR/T 0087—2012
which must be guaranteed within a valid trading day.
3.4 Order Identity
The term “order identity” refers to an identifier for order assigned by a futures company, the uniqueness of
which must be guaranteed within a single trading day.
3.5 Executive Identity
The term “executive identity” refers to an identifier of execution message assigned by a futures company,
the uniqueness of which must be guaranteed within a valid trading day and which is mainly used to
correspond to a specific execution report message. In the response to the request for the status of an order,
the value of the executive identity is “0”.
3.6 Declaration Identity
The term “declaration identity” refers to an identifier of declaration assigned by an exchange
3.7 Trade Identity
The term “trade identity” refers to an identifier of trade assigned by an exchange.
3.8Client Identity
The term “client identity” refers to a capital account opened by a client with a futures company.
3.9Account
The term “account” refers to a trading code assigned by an exchange for a client.
4. Methods of Communication
The two parties involved in a transaction may, at their discretion, choose any method of communication.
For FIX session-level messages, see Schedule E.
If the two parties involved in a transaction use the FIX session-level messaging as the method of
communication, see Schedule A for the handling of FIX session deficiencies and see Schedule B for FIX
session connection scenarios.
5. Message Format
5.1 Data Type
Data type is used to define value type in the data field. This protocol consists of several fundamental data
types (int, float, char, string and binary data block) and data types extended on their basis. Data types, with
the exception of those of type “data”, are mapped to ASCII strings as follows.
5.1.1 Int
Int refers to the sequence of digits without commas or decimals and optional positive or negative sign
2
JR/T 0087—2012
character (ASCII characters “-” and “0” - “9”). The sign character utilizes one byte. int values may contain
leading zeros (e.g. “00023” = “23”)
Extended definition of int type:
a)
Length: the length of data expressed in bytes is indicated with a positive int.
b)
NumInGroup: the number of repeating group is expressed in a positive int.
c)
SeqNum: the message sequence number is expressed in a positive int.
d)
TagNum: the field (also known as tag) number is expressed in a positive int, but the first character
cannot be zero.
e)
Day-of-month: the day of a month is expressed in an int the value of which ranges from 1 to 31.
5.1.2 Float
Float refers to the sequence of digits with optional decimal point and sign character (ASCII characters “-”,
“0” - “9” and “.”). All float fields must accommodate up to 15 significant digits. Float values may contain
leading zeros (e.g. “00023” = “23”)
. Float values may contain or omit trailing zeros after the decimal point (e.g. “23.0”=“23.0000”=“23”).
Extended definition of float type (except as stated in particular, float types may be positive or negative):
a)
Qty: the number of shares ordered, etc. capable of storing a decimal value.
b)
Price: the number of decimal places may vary.
c)
PriceOffeset: float field representing a price offset.
d)
Amt: float field (see definition of “float” above) typically representing a Price times a Qty, e.g. the
turnover.
e)
Percentage: it is expressed in decimals: .05 represents 5%
Number (m, n)(used in settlement documents): m indicates the maximum number of all significant digits
(excluding the decimal point and the negative and positive signs) and n represents the decimal places.
5.1.3 Char
Char refers to any alphanumeric character or punctuation except for the delimiter. All char fields are case
sensitive.
Extended definition of character type:
Boolean: a char field containing one of two values (‘Y’=True/Yes, ‘N’=False/No).
5.1.4 String
3
JR/T 0087—2012
String fields are case-sensitive
Extended definition of string type:
a)
Multiple Vvalue String: String field containing one or more space delimited values.
b)
Currency: see GB/T 12406-2008.
c)
Exchange: for their strings, see GB/T 23696-2009.
d)
Char (n) (used in settlement documents): it represents a string containing less than n characters.
e)
month-year, with the following format:
YYYYMM, YYYYMMDD, or YYYYMMWW.
YYYY = 0000-9999, MM = 01-12，DD = 01-31，WW = w1, w2, w3, w4, or w5.
f)
day-of-month (used in the settlement documents), its format is as follows:
YYYY-MM-DD
g)
UTCTimestamp, with the following format:
YYYYMMDD-HH: MM: SS (second) or
YYYYMMDD-HH: MM: SS.sss (millisecond)，
YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (second),
sss=000-999 (millisecond).
h)
UTC Time Only or time (used in the settlement documents), with the following format:
HH:MM:SS or HH: MM: SS.sss，
HH = 00-23, MM = 00-59, SS = 00-60 (second), sss=000-999 (millisecond).
i)
UTCDate, with the following format:
YYYYMMDD, YYYY = 0000-9999, MM = 01-12, DD = 01-31.
j)
LocalMktDate, with the following format:
YYYYMMDD, YYYY = 0000-9999, MM = 01-12, DD = 01-31.
5.1.5 Data
Original data not subject to limitation on format and contents and consisting of length field and data field.
Data included in the data field may contain numerical value 0x01 and the length field indicates the number
of characters contained in the data field.
5.2 Field
4
JR/T 0087—2012
5.2.1 Definition of Field
Field is a fundamental data element. Each field has its tag number, business definition and defined valid
values. Tag number, which is assigned in a centralized manner to different fields, is the distinctive mark of
a field. In messages, different fields are identified through the tag number. The data type of a field
determines its value type. The valid values of a field may be a set and any value other than such set is
deemed as illegal value. The business definition, data type and valid values of all fields are defined in detail
in the field definition section.
5.2.2 Use of Field
Each message is comprised of required, optional and conditionally required (fields which are required
based on the presence or value of other fields) fields. The required and conditionally required fields must
be contained in a complete message.
5.2.3 User Defined Field
If fields defined in this protocol is insufficient, market participants may expand the scope of defined fields,
that is, create user defined fields.
5.2.4 Field Chinese Character Encoding
If the value of a field is Chinese characters, the Chinese Internal Code Specification (GBK) shall be
followed.
5.2.5 Field Delimiter
All fields (including those of data type data) in a message are terminated by a delimiter character. The
non-printing, ASCII “SOH” (#001, hex: 0x01, referred to in the Standard as <SOH>), is used for field
termination. Therefore, All messages begin with the “8=FIX.x.y<SOH>”string and terminate with
“10=nnn<SOH>”.
There shall be no embedded delimiter character <SOH> within fields except for data type data.
5.2.6 Syntax
Any message is strictly constructed of a stream of <tag>=<value> fields with a field delimiter between
fields in the stream. The “tag=value” basic structure is delimited with the field separator <SOH>. The
composition structure of message is shown in Table 1:
tag=value
tag=value
tag=value
tag=value
Table 1: Message Format
A message is made up of a header, the message body fields and a trailer. Each message is constructed of a
stream of <tag>=<value> fields and such <tag>=<value> fields can be defined in any sequence by
5
JR/T 0087—2012
complying with the following rules:
a)
The general format of a message is a header followed by the message body fields and terminated
with a trailer.
b)
The first three fields in the header which cannot be changed are BeginString (tag =8) followed by
BodyLength (tag =9) followed by MsgType (tag =35)
c)
The last field in the trailer is the CheckSum (Tag =10).
d)
Fields within repeating groups shall be specified in the order that the fields are specified in the
message definition.
e)
In a message, except for those of repeating groups, no other field can be repeated.
5.2.7 Repeating Group
It is permissible for fields to be repeated within a repeating group in order to transmit array type data.
Generally, the character ‘No’ which initializes the name of a field indicates the times of repetition and is
placed at the beginning of a repeating group. The definition of repeating group in the Standard is indicated
via the indentation symbol. Some repeating groups may also be nested within another repeating group. If a
nested repeating group is used, then the outer repeating group must be specified
6. Safety and Encryption
The transmission and exchange of sensitive data across public carrier networks or unsafe networks may
make it advisable to employ data encryption techniques to mask the application messages. The choice of
encryption method will be determined by mutual agreement of the two parties involved in the connection.
Any field within a message can be encrypted and included in the SecureData field; however, certain
explicitly identified fields must be transmitted unencrypted. Of course, the clear text representation may
also be maintained for these encrypted fields. When encryption is employed, it is recommended but not
required that all fields within the message body be encrypted. If repeating groups are used within a message
and encryption is applied to part of the repeating group, then the entire repeating group must be encrypted.
Embedded in the protocol are fields, which enable the implementation of such safety techniques as digital
signature, key exchange and text encryption.
There are three text encryption schemes which are as follows:
a)
Safe and sensitive data is encrypted and transferred to the SecureData field.
b)
All fields which are allowed to be encrypted are encrypted and transferred to the SecureData field.
c)
All fields which are allowed to be encrypted are encrypted and transferred to the SecureData field
and these fields repeat in a message in clear text.
6
JR/T 0087—2012
7. Data Integrity
The integrity of message data content can be verified in two ways: verification of message length and
checksum.
The message length is indicated in the BodyLength field and is verified by counting the number of
characters in the message following the BodyLength field up to, and including, the delimiter SOH
immediately preceding the CheckSum tag (“10=”) .
The CheckSum integrity check is calculated by summing the binary value of each character from the “8” of
“8=”up to and including the field delimiter immediately preceding the CheckSum field “10=” and
transforming the result into a modulo 256 number.
The checksum field is the last field in a message. The checksum is calculated after all encryption is
completed. For C language code segment for checksum calculation, see Schedule D.
8. Mode of Expansion
8.1 Categories of Expansion
Expansion is divided into two parts: message definition expansion and field definition expansion.
Message definition expansion may be made through adding message types, but the priority is to define new
businesses through field definition or value expansion in the existing messages. Businesses represented by
the existing messages cannot be changed when the expansion is made.
Field definition expansion may be made through adding fields, but the priority is to expand the definition of
field by expanding the field value. The required field which has been defined in a message cannot be
transformed into an optional one and its definition cannot be abolished.
8.2 Expansion Rules
The initial character of the message type value of user defined messages is ‘UF’. The module sequence of a
message cannot be changed when its definition is expanded, but the sequence of fields and repeating
groups may be changed.
The definitions and positions of the first three fields in a header cannot be changed, but the optional fields
in the header may be expanded
The definition and position of the final field in a trailer cannot be changed, but the optional fields in the
trailer may be expanded.
8.3 Version Management
The version management right with respect to this protocol is vested with the Securities Association of
China.
7
JR/T 0087—2012
The format of version No. is X.Y.Z starting from 1.0.0. When a new version is completely compatible with
the previous version, only Z in the version No. can be replaced.
9. Definition of Message
9.1 Message Header
Each session or application message is preceded by a header. The header identifies the message type,
length, destination, sequence number, origination point and time.
Two fields are used to resend messages. The PossDupFlag is set to Y when resending a message as the
result of a session level event (i.e. the retransmission of a message reusing a sequence number). The
PossResend is set to Y when reissuing a message with a new sequence number. The receiving application
shall process these messages as follows:
PossDupFlag: if a message with this sequence number has been previously received, ignore the message, if
not, process the message normally. (Support the FIX session-level need)
PossResend: forward a message to the application and determine if the message has been previously
received (i.e. verify order ID or relevant parameters).
See Table 1 for the format of message header:
Table 1 Message Header
Tag
Field Name
Required
Comments
First string. Valid values:FIX.4.2 (Always
8
BeginString
Y
unencrypted,
must
be
first
field
in
message)
9
BodyLength
Y
35
MsgType
Y
Message length (Always unencrypted,
must be second field in message)
Message type(Always unencrypted, must
be third field in message)
Identifier of message sender (Always
49
SenderCompID
Y
unencrypted, must be third field in
message)
56
8
TargetCompID
Y
Identifier of message receiver (Always
unencrypted)
JR/T 0087—2012
Tag
Field Name
Required
Comments
Identifier of message originator (Can be
115
OnBehalfOfCompID
N
embedded within encrypted data section.).
Required if the message was delivered by a
third party
Identifier of message recipient (Can be
128
DeliverToCompID
N
embedded within encrypted data section.).
Required if the message is delivered by a
third party
90
SecureDataLen
N
91
SecureData
N
Length of encrypted data
Encrypted
data
(Always
immediately
follows SecureDataLen field)
Message
sequence
number
(Can
be
embedded within encrypted data section.).
34
MsgSeqNum
Y
A fixed value may be set for this tag (e.g.
0) if the two parties involved in a
transaction do not use the FIX session
mechanism.
Identifier of specific message originator
50
SenderSubID
N
(Can be embedded within encrypted data
section.)
Identifier of specific message originator’s
142
SenderLocationID
N
location
(Can
be
embedded
within
encrypted data section)
Identifier of specific message receiver
57
TargetSubID
N
(Can be embedded within encrypted data
section)
Identifier of specific message destination’s
143
TargetLocationID
N
location
(Can
be
embedded
within
encrypted data section)
Identifier of specific message originator
116
OnBehalfOfSubID
N
(Can be embedded within encrypted data
section)
9
JR/T 0087—2012
Tag
Field Name
Required
Comments
Identifier of specific message originator’s
144
OnBehalfOfLocationID
N
location
(Can
be
embedded
within
encrypted data section)
Assigned value used to identify specific
129
DeliverToSubID
N
message recipient if the message is
delivered by a third party (Can be
embedded within encrypted data section)
Identifier of specific message recipient's
145
DeliverToLocationID
N
location
(Can
be
embedded
within
encrypted data section)
Possible duplicate flag. Indicates possible
43
PossDupFlag
N
retransmission
of
message.
(Can
be
embedded within encrypted data section)
97
PossResend
N
52
SendingTime
Y
122
OrigSendingTime
N
Possible resend flag. (Can be embedded
within encrypted data section)
Time of transmission (Can be embedded
within encrypted data section)
Time of original transmission (Can be
embedded within encrypted data section)
Type of message encoding (non-ASCII
347
MessageEncoding
N
characters) used in a message’s “Encoded”
fields
The last MsgSeqNum value received and
369
LastMsgSeqNumProcessed
N
processed (Can be embedded within
encrypted data section)
370
OnBehalfOfSendingTime
N
Time of initial transmission (always
expressed in UTC)
9.2 Message Trailer
Each message, session or application, is terminated by a trailer. The trailer is used to segregate messages
and contains the three digit character representation of the Checksum value.
See Table 2 for the format of message trailer:
10
JR/T 0087—2012
Table 2 Message Trailer
Tag
Field Name
Required
93
SignatureLength
N
89
Signature
N
10
CheckSum
Y
Comments
Length
of
electronic
signature
(Always
unencrypted)
Electronic signature(Always unencrypted)
Checksum. Always last field in message (Always
unencrypted).
9.3 Session Messages
9.3.1 User Logon Management Messages
9.3.1.1 Notes on User Logon Management Messages
User logon messages primarily include, among others, messages which support client logon and logout and
other client management practices. The two parties involved in a transaction may, depending on their own
business need, choose transactions which supports or does not support logon and logout practices.
9.3.1.2 User Logon Request (MsgType=UF001)
It is the request of a user to log into the system of a futures company a session-level connection is
established.
See Table 3 for the format of User Logon Request:
Table 3 User Logon Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
98
EncryptMethod
Y
Method of encryption (Always unencrypted)
8001
LogonPasswd
Y
Transaction password
95
RawDataLength
N
MsgType=UF001
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Length of unformatted raw data. Required for
authentication purpose
Unformatted raw data (Can be used to represent a
96
RawData
N
private key). Required for some authentication
methods
8096
MacNetInfo
N
Computer network information of client
8105
ClientSoftName
N
Name of client software
8106
ClientSoftVersion
N
Version of client software
Standard trailer
Y
11
JR/T 0087—2012
9.3.1.3 User Logon Response (MsgType=UF002)
It is the response returned by a futures company after a user requests to log into the system of the futures
company.
See Table 4 for the format of User Logon Response:
Table 4 User Logon Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8002
LogonStatus
Y
Status of logon
8031
UserRespType
Y
Type of response to user
8003
AccountName
N
Account name
8004
RiskLevel
N
Level of risk posed by client
8005
AdditionalMargin
N
Additional margin
8006
ClientSecuType
N
Type of client security
8011
Riskratio
N
Risk ratio of client
8007
LastLogonIP
N
IP address for the last logon
8008
LastLogonTime
N
Date and time when the last logon was made
MsgType=UF002
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Reason for rejecting logon request. Optionally
8032
LongonRejReason
N
employed when UserRespType (8031)=1
(representing rejection)
Describes the reason for rejecting logon request.
58
Text
N
Optionally employed when the
UserRespType(8031)=1(representing rejection)
Standard trailer
Y
9.3.1.4 User Logout Request (MsgType=UF003)
It is the request of a user to log out of the system of a future company after the business time terminates.
12
JR/T 0087—2012
See Table 5 for the format of User Logout Request:
Table 5 User Logout Request
Tag
Field Name
Required
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Standard trailer
Y
Comments
MsgType=UF003
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Capital account of client
9.3.1.5 User Logout Response (MsgType=UF004)
It is the response made by a futures company to the request of a user to log out of the system of the future
company.
See Table 6 for the format of User Logout Response:
Table 6 User Logout Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8002
LogonStatus
Y
Status of logon
8031
UserRespType
Y
Type of response to user
MsgType=UF004
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Reason for rejecting logout request. Optionally
8033
LogoutRejReason
N
employed when the
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting logon request.
58
Text
N
Optionally employed when the
UserRespType(8031)=1(representing rejection)
Standard trailer
Y
13
JR/T 0087—2012
9.3.1.6 User Change PassWd Request (MsgType=UF005)
It is the request of a user to change the password.
See Table 7 for the format of User Change PassWd Request:
Table 7 User Change PassWd Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8089
PassWdType
Y
Type of password
8090
OldPassWd
Y
Old password of user
8091
NewPassWd
Y
New password of user
58
Text
N
Standard trailer
Y
MsgType=UF005
Identifier of user request. Its uniqueness must
be guaranteed within a single trading day.
9.3.1.7 User Change PassWd Response (MsgType=UF006)
It is the response made by a futures company with respect to the request of a user to change the password.
See table 8 for the format of User Change PassWd Response
Table 8 User Change PassWd Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8031
UserRespType
Y
Type of response to user
MsgType=UF006
Identifier of user request. Its uniqueness must
be guaranteed within a single trading day.
Reason for rejecting password change request.
8034
ChangePWRejReason
N
Optionally
employed
when
THE
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting password
58
Text
N
change request. Optionally employed when the
UserRespType(8031)=1(representing rejection)
Standard trailer
14
Y
JR/T 0087—2012
9.3.2 Order Messages
9.3.2.1 Notes on Order Messages
Order messages primarily include those which provide support to daily real-time transactions. See Schedule
C for main scenarios for the application of order messages.
9.3.2.2 New Order Messages (MsgType=D)
New order messages received with the PossResend flag set in the header shall be validated by the ClOrdID.
Implementations shall also consider checking order parameters (side, symbol, quantity, etc.) to determine if
the order had been previously submitted. If such order has previously been received, the order shall be
acknowledged back to the client via an execution report message. If the order has not been received, the
order shall be processed as a new order and acknowledged via an execution report message.
The origination time specified in the TransactTime field shall allow the receiver of the order to apply
business rules to determine if the order is potentially “stale”.
See Table 9 for the format of New Order-Single Message:
Table 9 New Order-Single
Tag
Field Name
Required
Comments
Standard header
Y
11
ClOrdID
Y
109
ClientID
Y
Capital account of client
1
Account
Y
Trading code for client
110
MinQty
N
Minimum quantity of an order to be executed
55
Symbol
Y
Contract code
167
SecurityType
N
FUT = futures
200
MaturityMonthYear
N
MsgType=D
Identifier of client order. Its uniqueness must be
guaranteed within a valid trading day.
Can be used to specify month and year of
maturity
Can
205
MaturityDay
N
be
used
in
conjunction
with
MaturityMonthYear to specify a particular
maturity date
207
SecurityExchange
Y
Can be used to identify the exchange
15
JR/T 0087—2012
Tag
Field Name
Required
Comments
77
OpenClose
Y
Indicates opening or closing a position
8009
HedgeFlag
Y
Flag of speculation or hedge
8010
TouchCondition
N
Trigger condition
54
Side
Y
Side of order
38
OrderQty
N
Number of shares ordered
60
TransactTime
Y
Time of order creation
40
OrdType
Y
Type of order
44
Price
N
Price (Required to specify a limit order)
423
PriceType
N
Price type
99
StopPx
N
Stop price
15
Currency
N
Type of currency
59
TimeInForce
N
168
EffectiveTime
N
432
ExpireDate
N
126
ExpireTime
N
8096
MacNetInfo
N
58
Text
N
Standard trailer
Y
Time at which a new order becomes effective.
Absence of this field indicates Day
Can be used to specify the time during which
the order remains in effect
Conditionally required if TimeInForce = GTD
and ExpireTime is not specified.
Conditionally required if TimeInForce = GTD
and ExpireDate is not specified.
Computer network information of client
9.3.2.3 Execution Reports (MsgType=8)
Execution reports may be used to:
a)
confirm the receipt of an order
b)
confirm any change in the status of an existing order (e.g. accept order cancel requests),
c)
16
relay order status information and
JR/T 0087—2012
d)
reject orders
Each execution report includes two fields: OrdStatus (the status of order) and ExecType (the type of
execution).
The OrdStatus convey the current status of an order.
The ExecType field identifies the execution type of an execution report. In an execution report, both the
OrdStatus and the ExecType indicate any change in the status of an order.
Execution information (e.g. partial fill or complete fill) shall not be communicated in the same report as
one which communicates other state changes (such as pending cancel, canceled, accepted, done for day
etc.)
Requests to cancel an order are only acted upon when there is an outstanding order quantity.
The general rule is: OrderQty = CumQty + LeavesQty
There can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, DoneForTheDay,
Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0
The ClOrdID is provided for futures companies to affix an identification number to a client order and is
unique within their internal systems. The field OrderID is populated with the futures company-generated
order number. In an order cancellation, the ClOrdID needs to be connected with the OrigClOrdID.
Push notification messages relating to forced liquidation are supported and the OpenClose is set to “Q”.
For counters which do not return the AvgPx, the AvgPx can be set to “0”.
See Table 10 for the format of Execution Report Message:
Table 10 Execution Report
Tag
Field Name
Required
Standard header
Y
Comments
MsgType=8
Identifier for order as assigned by a futures
37
OrderID
Y
company. Its uniqueness must be guaranteed
within a single trading day.
Identifier of client order. In the case of
11
ClOrdID
N
information on forced liquidation, the value is
the identity of the sole string initialized with
“NONE” appearing on the trading day.
41
OrigClOrdID
N
ClOrdID of the previous order used to identify
the previous order in the cancel requests.
17
JR/T 0087—2012
Identifier of execution message as assigned by a
17
ExecID
Y
futures company. Its uniqueness must be
guaranteed within a valid trading day.
18
150
ExecType
Y
Type of execution
39
OrdStatus
Y
Status of order
103
OrdRejReason
N
Required when rejecting an order
109
ClientID
Y
Capital account of client
1
Account
Y
Trading code for client
55
Symbol
Y
Contract code
167
SecurityType
N
FUT＝futures
200
MaturityMonthYear
N
Month and year of maturity
205
MaturityDay
N
Day of maturity
207
SecurityExchange
Y
Can be used to identify the exchange
77
OpenClose
N
Indicates opening or closing a position
54
Side
Y
Side of order
38
OrderQty
Y
Number of shares ordered
40
OrdType
N
Type of order
44
Price
N
Price of order
99
StopPx
N
Stop price
59
TimeInForce
N
15
Currency
N
32
LastShares
N
31
LastPx
N
Price of last fill (price of the most recent fill)
30
LastMkt
N
Market of execution for last fill
151
LeavesQty
Y
Remaining quantity of an existing order
Time at which a new order becomes effective.
Absence of this field indicates Day
The type of currency
Quantity of shares traded on last fill (quantity of
shares traded on the most recent fill )
JR/T 0087—2012
14
CumQty
Y
Total number of shares filled
6
AvgPx
Y
Average price
60
TransactTime
N
Time of execution report
381
GrossTradeAmt
N
Total amount traded
110
MinQty
N
Minimum quantity of an order to be executed
8500
OrderEntryTime
N
Time at which an order was entered
8093
DeclarationID
N
Identifier of declaration
8094
TradeID
N
Identifier of trade
Standard trailer
Y
9.3.2.4 Order Status Request (MsgType=H)
The order status request is used to ask for information on the status of a specific order with a service
provider which gives information on the status of the order through an execution report message.
See Table 11 for the format of Order Status Request Message:
Table 11 Order Status Request
Tag
Field Name
Required
Standard header
Y
Comments
MsgType=H
Identifier for order as assigned by a futures
37
OrderID
Y
company. Its uniqueness must be guaranteed
within a single trading day.
11
ClOrdID
Y
Identifier of client order
109
ClientID
Y
Capital account of client
1
Account
Y
Trading code for client
55
Symbol
Y
Contract code
207
SecurityExchange
Y
Can be used to identify the exchange
167
SecurityType
N
FUT＝futures
200
MaturityMonthYear
N
Can be used to specify month and year of
maturity
Can
205
MaturityDay
N
be
used
in
conjunction
with
MaturityMonthYear to specify a particular
maturity date
54
Side
Y
Standard trailer
Y
Side of order
19
JR/T 0087—2012
9.3.2.5 Order Cancel Request (MsgType=F)
The order cancel request is used to cancel all of the remaining quantity of an existing order.
The order cancel request will only be accepted if the order can successfully be pulled back from the
exchange floor without being executed or partially executed.
A cancel request is assigned a ClOrdID and is treated as a separate order. If rejected, the ClOrdID of the
cancel request will be sent in the Cancel Reject message, as well as the ClOrdID of the actual order in the
OrigClOrdID field. The ClOrdID assigned to the cancel request must be unique.
An immediate response to the order cancel request is required. It is recommended that an ExecutionRpt
with ExecType=Pending Cancel be sent unless the Order Cancel Request can be immediately accepted or
rejected.
See Table 12 for the format of Order Cancel Request:
Table 12 Order Cancel Request
Tag
41
Field Name
Required
Standard header
Y
OrigClOrdID
Y
Comments
MsgType=F
ClOrdID of the previous order used to identify the
previous order in the cancel requests.
Identifier for order as assigned by a futures
37
OrderID
Y
company. Its uniqueness must be guaranteed
within a single trading day.
20
11
ClOrdID
Y
Identifier of client order
109
ClientID
Y
Capital account of client
1
Account
Y
Trading code for client
55
Symbol
Y
Contract code
167
SecurityType
N
Security code source
200
MaturityMonthYear
N
FUT＝futures
205
MaturityDay
N
Month and year of maturity
207
SecurityExchange
Y
Day of maturity
54
Side
Y
Side of order
60
TransactTime
Y
Time of order creation
40
OrdType
Y
Type of order
38
OrderQty
Y
Number of shares ordered
8093
DeclarationID
N
Identifier of declaration
58
Text
N
Standard trailer
Y
JR/T 0087—2012
9.3.2.6 Order Cancel Reject (MsgType=9)
The order cancel reject message is used to reject an order cancel request.
When a service provider who has received an order cancel request discovers that such request cannot be
executed (e.g. the impossibility to change any filled order etc.), it will send an order cancel reject message
When rejecting an order cancel request, the order cancel reject message shall provide the ClOrdID and
OrigClOrdID values which were specified on the order cancel request message for identification (unless
CxlRejReason= “Unknown order”).
See Table 13 for the format of Order Cancel Reject:
Table 13 Order Cancel Reject
Tag
Field Name
Required
Standard header
Y
Comments
MsgType=9
Identifier for order as assigned by a futures
37
OrderID
Y
company. Its uniqueness must be guaranteed
within a single trading day.
11
ClOrdID
Y
Identifier of client order
41
OrigClOrdID
Y
39
OrdStatus
Y
Status of order
109
ClientID
Y
Capital account of client
1
Account
Y
Trading code for client
60
TransactTime
N
Time of order creation
434
CxlRejResponseTo
N
102
CxlRejReason
N
58
Text
N
Standard trailer
Y
ClOrdID of the previous order used to identify
the previous order in the cancel requests.
Type of request that a Cancel Reject is in
response to
Reason for rejecting order cancel request
9.3.3 Business Status Messages
9.3.3.1 Notes on Business Status Messages
Business status messages are primarily those which provide support to status-related requests.
21
JR/T 0087—2012
9.3.3.2 Position Status Request (MsgType=UF201)
It is the request by clients for information on the status of positions they currently hold.
Clients may request for information on the status of positions they hold through all exchanges; information
on the status of all positions held through a particular exchange; information on the status of all positions
they hold through a specific exchange; and information relating to the status of positions held on a certain
contract.
See Table 14 for the format of Current /Previous Position Status Request:
Table 14 Position Status Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8035
PosStatReqType
Y
Type of position status request
1
Account
N
Trading code for client
55
Symbol
N
Contract code
207
SecurityExchange
N
Can be used to identify the exchange
54
Side
N
Identifies the side of order for a position
MsgType=UF201
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Beginning time of a previous position status
8101
BeginDate
C
request. Required when PosStatReqType(8035)=1
(representing previous position status request)
Ending time of a previous position status request.
8102
EndDate
C
Required
when
PosStatReqType(8035)=1
(representing previous position status request)
Standard trailer
Y
9.3.3.3 Position Status Response (MsgType=UF202)
It is the response made to the request of clients for information on the status of positions they hold. It is
also the response to any position status response gap.
If a futures company receives a previous position status request during trading hours, it does not need to
return a response.
22
JR/T 0087—2012
See Table 15 for the format of Position Status Response:
Table 15 Position Status Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
8031
UserRespType
Y
Type of response to user
8026
TotalRetNum
N
Number of responses returned
8027
PresentRetNum
N
8095
NextFlag
N
109
ClientID
Y
Capital account of client
1
Account
N
Trading code for client
55
Symbol
Y
Contract code
207
SecurityExchange
Y
Can be used to identify the exchange
8012
LatestPx
N
The latest price
54
Side
Y
Side of order
MsgType=UF202
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Sequence number of the present response
returned
Whether there is any flag for subsequent data
packets
Flag of speculation or hedge. Required when
8009
HedgeFlag
C
PosStatRespType (8507)=0 (representing
acceptance)
Total positions (total number of shares filled).
14
CumQty
C
Required when PosStatRespType (8507)=0
(representing acceptance)
Today positions. Required when
8015
TdPosition
C
PosStatRespType (8507)=0 (representing
acceptance)
8016
YDPosition
N
Yesterday positions
8017
FrozenPosition
N
Number of positions frozen
8018
FrozenAmt
N
Amount frozen
8019
PositionDate
N
Date on which a positions was held
6
AvgPx
N
Holding cost (average price)
12
Commission
N
Commission
8021
PositionProfit
N
Profit or loss from the positions
8022
PositionPrice
N
Average price of the positions
8075
OneLotQty
N
Number of shares in one lot
8036
PosStatRejReason
N
Reason for rejecting position status request.
23
JR/T 0087—2012
Optionally employed when the UserRespType
(8031)=1(representing rejection)
Describes the reason for rejecting position status
58
Text
N
request. Optionally employed when the
UserRespType (8031)=1(representing rejection)
Standard trailer
Y
9.3.3.4 Max Operation Position Status Request (MsgType=UF203)
It is the request sent by a client for information on the status of maximum amount of positions it can open
or close.
See Table 16 for the format of Max Operation Position Status Request:
Table 16 Max Operation Position Status Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
1
Account
N
Trading code for client
55
Symbol
Y
Contract code
207
SecurityExchange
Y
Can be used to identify the exchange
77
OpenClose
Y
Indicates opening or closing a position
54
Side
Y
Side of order
MsgType=UF203
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Price. Required when requesting the status of the
44
Price
N
maximum amount of positions allowed to be
opened
8009
HedgeFlag
Y
Standard trailer
Y
Flag of speculation or hedge
9.3.3.5 Max Operation Position Status Response (MsgType=UF204)
It is the response made to the request of a client for information on the status of maximum amount of
positions it has opened or closed.
See Table 17 for the format of Max Operation Position Status Response:
24
JR/T 0087—2012
Table 17 Max Operation Position Status Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8031
UserRespType
Y
Type of response to user
1
Account
N
Trading code for client
55
Symbol
Y
Contract code
207
SecurityExchange
Y
Can be used to identify the exchange
77
OpenClose
Y
Indicates opening or closing a position
54
Side
Y
Side of order
MsgType=UF204
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Maximum amount of positions opened. Required
8023
MaxOpenPosition
N
when requesting the status of the opened
positions.
Maximum amount of positions closed. Required
when requesting the status of the closed
8024
MaxClosePosition
N
positions. If the closing of positions opened
today or yesterday is supported, the value is the
maximum amount of yesterday opened positions
closed
Maximum amount of today opened positions
8025
MaxCloseTdPosition
N
closed. Required when requesting the status of
positions closed and if the closing of toady or
yesterday opened positions is supported.
8009
8037
HedgeFlag
MaxOpPosStatRejReaso
n
Y
Flag of speculation or hedge
Reason for rejecting position status request.
N
Optionally
employed
when
the
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting position status
58
Text
N
request.
Optionally
employed
when
the
UserRespType(8031)=1(representing rejection)
Standard trailer
Y
9.3.3.6 All Orders Status Request (MsgType=UF205)
It is the request sent by a client for the status of all of its orders. The all orders status request is also used to
request the status of orders in a particular exchange.
See Table 18 for the format of All Orders Status Request:
25
JR/T 0087—2012
Table 18 All Orders Status Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8038
AllOrdStatReqType
Y
Type of all orders status request
207
SecurityExchange
N
Can be used to identify the exchange
8101
BeginDate
C
8102
EndDate
C
Standard trailer
Y
MsgType=UF205
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Beginning time of an all previous orders status
request
Ending time of an all previous orders status
request
9.3.3.7 All Orders Status Response (MsgType=UF206)
It is the response made to the request of a client for the status of all of its orders. It is also the response to
any response gap with respect to the request of a client for resending the status of all orders.
If a futures company receives an all previous orders position status request during trading hours, it does not
need to return a response.
See Table 19 for the format of All Orders Status Response:
26
JR/T 0087—2012
Table 19 All Orders Status Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
8031
UserRespType
Y
Type of response to user
8026
TotalRetNum
N
Number of responses returned
8027
PresentRetNum
N
8095
NextFlag
N
109
ClientID
Y
MsgType=UF206
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Sequence number of the present response
returned
Whether there is any flag for subsequent data
packets
Capital account of client
Trading code for client. Required when
1
Account
C
AllOrdStatRespType (8512)=0 (representing
acceptance)
Contract code. Required when
55
Symbol
C
AllOrdStatRespType (8512)=0 (representing
acceptance)
Can be used to identify the exchange. Required
207
SecurityExchange
C
when AllOrdStatRespType (8512)=0
(representing acceptance)
Identifier of client order. Required when
11
ClOrdID
C
AllOrdStatRespType (8512)=0 (representing
acceptance)
Status of order. Required when
39
OrdStatus
C
AllOrdStatRespType (8512)=0 (representing
acceptance)
Indicates opening or closing a position.
77
OpenClose
C
Required when AllOrdStatRespType (8512)=0
(representing acceptance)
Side of order. Required when
54
Side
C
AllOrdStatRespType (8512)=0 (representing
acceptance)
Number of shares ordered. Required when
38
OrderQty
C
AllOrdStatRespType (8512)=0 (representing
acceptance)
40
OrdType
C
Type of order. Required when
AllOrdStatRespType (8512)=0 (representing
27
JR/T 0087—2012
acceptance)
44
Price
N
Price of order
99
StopPx
N
Stop price
59
TimeInForce
N
Time at which a new order becomes effective.
Absence of this field indicates Day
15
Currency
N
Type of currency
151
LeavesQty
Y
Remaining quantity of an existing order
14
CumQty
Y
Total number of shares filled
6
AvgPx
Y
Average price
60
TransactTime
N
Time of execution report
381
GrossTradeAmt
N
Total amount traded
110
MinQty
N
Minimum quantity of an order to be executed
8500
OrderEntryTime
N
Time at which an order was entered
Reason for rejecting all orders status request.
8039
AllOrdStatRejReason
N
Optionally employed when the
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting position status
58
Text
N
request. Optionally employed when the
UserRespType(8031)=1(representing rejection)
Standard trailer
Y
9.3.3.8 Settlement Result Status Request (MsgType=UF207)
It is the request of a client for the status of settlement results.
See Table 20 for the format of Settlement Result Status Request:
Table 20 Settlement Result Status Request
Tag
Field Name
Required
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8028
SettlementDate
Y
Date of settlement results
207
SecurityExchange
Y
Can be used to identify the exchange
Standard trailer
Y
28
Comments
MsgType=UF207
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
JR/T 0087—2012
9.3.3.9 Settlement Result Status Response (MsgType=UF208)
It is the response returned by a futures company to the request of a client for the status of settlement results.
It is also the response to response gap with respect to the request of a client for the status of settlement
results.
See Table 21 for the format of Settlement Result Status Response:
Table 21 Settlement Result Status Response
Tag
Field Name
Required
Standard header
Y
8088
RequestID
Y
8031
UserRespType
Y
Type of response to user
8028
SettlementDate
Y
Date of settlement results
207
SecurityExchange
Y
Can be used to identify the exchange
8026
TotalRetNum
N
Number of responses returned
8027
PresentRetNum
N
Sequence number of the present response returned
8095
NextFlag
N
8040
SettlementResultStatRej
Reason
Comments
MsgType=UF208
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Whether there is any flag for subsequent data
packets
Reason for rejecting settlement result status request.
N
Optionally employed when the
UserRespType(8031)=1(representing rejection)
Required
when
when
UserRespType(8031)=0
(representing acceptance). Specifies the contents of
the settlement result;
58
Text
C
Optionally employed when the
UserRespType(8031)=1(representing rejection).
Describes the reason for rejecting settlement result
status request.
Standard trailer
Y
29
JR/T 0087—2012
9.3.3.10 Settlement Result Comfirm Request (MsgType=UF209)
It is the request of a client for the confirmation of settlement results.
See Table 22 for the format of Settlement Result Comfirm Request:
Table 22 Settlement Result Comfirm Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8028
SettlementDate
N
Date of settlement results
8029
SettlementConfirm
Y
Confirmation of settlement results
207
SecurityExchange
Y
Can be used to identify the exchange
Standard trailer
Y
MsgType=UF209
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
9.3.3.11 Settlement Result Confirm Response (MsgType=UF209)
It is the response returned by a futures company to the request of a client for the confirmation of settlement
results. It is also the response to any response gap to the request of a client for the confirmation of
settlement results.
See Table 23 for the format of Settlement Result Comfirm Response:
Table 23 Settlement Result Comfirm Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
8031
UserRespType
Y
Type of response to user
8028
SettlementDate
N
Date of settlement results
MsgType=UF210
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Result
8030
SettlementConfirmResult
C
Required
of
settlement
when
result
UserRespType(8031)=0
(representing acceptance).
30
confirmation.
JR/T 0087—2012
207
8041
SecurityExchange
SettlementResultConfirm
RejReason
Y
Can be used to identify the exchange
Reason for rejecting settlement result confirm
N
request.
Optionally
employed
when
the
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting settlement
58
Text
N
result confirm request. Optionally employed
when the UserRespType(8031)=1(representing
rejection)
Standard trailer
Y
9.3.3.12 Settlement Result Comfirm Status Request (MsgType=UF211)
It is the request of a client for the status of settlement result confirmation.
See Table 24 for the format of Settlement Result Comfirm Status Request:
Table 24 Settlement Result Comfirm Status Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8028
SettlementDate
N
Date of settlement results
207
SecurityExchange
Y
Can be used to identify the exchange
Standard trailer
Y
MsgType=UF211
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
9.3.3.13 Settlement Result Comfirm Status Response
It is the response returned by a futures company to the request of a client for the status of settlement result
confirmation. Settlement Result Confirm Response messages can be used as reference.
9.3.3.14 Margin Rate Status Request (MsgType=UF212)
It is the request of a client for the status of margin rates. Clients may request for either the status of margin
rate of a particular variety or the status of margin rates of varieties with a specified date of delivery
See Table 25 for the format of Margin Rate Status Request:
31
JR/T 0087—2012
Table 25 Margin Rate Status Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
1
Account
N
Trading code for client
8078
VarietyCode
Y
Variety code
55
Symbol
N
Contract code
200
MaturityMonthYear
N
207
SecurityExchange
Y
Standard trailer
Y
MsgType=UF212
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Can be used to specify month and year of
maturity
Can be used to identify the exchange
9.3.3.15 Margin Rate Status Response (MsgType=UF213)
It is the response returned by a futures company to the request of a client for the status of margin rates.
A futures company may voluntarily transmit such message in the case of any intra-day change in the
margin rate.
See Table 26 for the format of Margin Rate Status Response:
Table 26 MarginRate Status Response
Tag
Field Name
Required
Standard header
Y
Comments
MsgType=UF213
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day. If a
8088
RequestID
Y
futures company voluntarily transmits the margin
rate to a client, the value is the identity of the sole
string initialized with “NONE” appearing on the
trading day
109
32
ClientID
Y
Capital account of client
JR/T 0087—2012
Tag
Field Name
Required
Comments
8031
UserRespType
Y
Type of response to user
1
Account
N
Trading code for client
55
Symbol
N
Contract code
200
MaturityMonthYear
N
Can be used to specify month and year of
maturity
Number of margin entries. Required when
8054
NoMarginEntries
C
UserRespType(8031)=0 (representing
acceptance).

8055
MarginType
N
Type of margin

8056
MarginRate
N
Margin rate

8057
MaginAmt
N
Margin amount
207
SecurityExchange
Y
Can be used to identify the exchange
8042
MarginRateStatRejReas
on
Reason for rejecting position status request.
N
Optionally employed when the
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting marginrate
58
Text
N
status request. Optionally employed when the
UserRespType(8031)=1(representing rejection)
Standard trailer
Y
9.3.3.16 Commission Rate Status Request (MsgType=UF214)
It is the request of a client for the status of commission rates.
See Table 27 for the format of Commission Rate Status Request:
Table 27 Commission Rate Status Request
Tag
8088
Field Name
Required
Standard header
Y
RequestID
Y
Comments
MsgType=UF214
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
33
JR/T 0087—2012
109
ClientID
Y
Capital account of client
8078
VarietyCode
N
Variety code
55
Symbol
N
Contract code
200
MaturityMonthYear
N
207
SecurityExchange
Y
Standard trailer
Y
Can be used to specify month and year of
maturity
Can be used to identify the exchange
9.3.3.17 Commission Rate Status Response (MsgType=UF215)
It is the response returned by a futures company to the request of a client for the status of commission rates.
See Table 28 for the format of Commission Rate Status Response:
Table 28 Commission Rate Status Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
8031
UserRespType
Y
Type of response to user
8026
TotalRetNum
N
Number of responses returned
8027
PresentRetNum
N
8095
NextFlag
N
8078
VarietyCode
N
Variety code
55
Symbol
N
Contract code
200
MaturityMonthYear
N
MsgType=UF215
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Sequence number of the present response
returned
Whether there is any flag for subsequent data
packets
Can be used to specify month and year of
maturity
Number of commission entries. Required when
8058
NoCommissionEntries
C
UserRespType(8031)=0 (representing
acceptance).
34
JR/T 0087—2012
Tag
Field Name
Required

8059 CommissionType
N
Type of commission

8070
CommissionRate
N
Commission rate

8071
CommssionAmt
N
Commission
8092
SettleFee
N
Settlement fees
207
SecurityExchange
Y
Can be used to identify the exchange
8043
CommissionRateStatRejR
eason
Comments
Reason for rejecting position status request.
N
Optionally employed when the
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting commission
58
Text
N
rate status request. Optionally employed when the
UserRespType (8031)=1(representing rejection)
Standard trailer
Y
9.3.3.18 Customer Capital Status Request (MsgType=UF216)
It is the request by clients for the status of their capital.
See Table 29 for the format of Customer Capital Status Request:
Table 29 Customer Capital Status Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
15
Currency
N
Type of currency
Standard trailer
Y
MsgType=UF216
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
9.3.3.19 Customer Capital Status Response (MsgType=UF217)
It is the response returned by a futures company to the request of a client for the status of its capital. A
futures company may voluntarily transmit such message for the purpose of issuing a margin call to a client.
See Table 30 for the format of Customer Capital Status Response:
35
JR/T 0087—2012
Table 30 Customer Capital Status Response
Tag
Field Name
Required
Standard header22
Y
Comments
MsgType=UF217
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day. In the case of
8088
RequestID
Y
a margin call, the value is the identity of the sole
string initialized with “NONE” appearing on the
trading day.
109
ClientID
Y
Capital account of client
8031
UserRespType
Y
Type of response to user
8045
BuyMarginAmt
C
8046
SellMarginAmt
C
Margin
buying.
Required
UserRespType(8031)=0 (representing acceptance).
Margin selling. Required when
UserRespType(8031)=0 (representing acceptance).
Supplementary margin. Required when
8047 SupplementalMarginAmt
C
8048
OccupyMarginAmt
C
8049
TotalMarginAmt
C
8014
TotalExMarginAmt
N
8081
YesterdayStlAmt
C
8082
BuyFrozenAmt
C
8083
SellFrozenAmt
C
8020
FrozenCommision
N
Commission for freezing the position
8074
TotalFrozenAmt
N
Total frozen amount
8084
UseableAmt
C
Usable
36
when
UserRespType(8031)=0 (representing acceptance).
Margin occupied. Required when
UserRespType(8031)=0 (representing acceptance).
Total margin. Required when UserRespType(8031)=0
(representing acceptance).
Total margin of exchange
Amount settled yesterday. Required when
UserRespType(8031)=0 (representing acceptance).
Buy frozen amount. Required when
UserRespType(8031)=0 (representing acceptance).
Sell frozen amount. Required when
UserRespType(8031)=0 (representing acceptance).
capital.
Required
when
JR/T 0087—2012
Tag
Field Name
Required
Comments
UserRespType(8031)=0 (representing acceptance).
8098
FetchAmt
N
Capital available for withdrawal
12
Commission
N
Commission
8085
FloatProfit
N
Floating profit or loss
8086
CloseProfit
N
Profit or loss from the closing of positions
8087
DayFolatProfit
N
Outgoing and incoming payments on the day
8099
DayPaymentAmt
N
Outgoing payments on the day
8100
DayIncomeAmt
N
Incoming payments on the day
8004
RiskLevel
C
8006
ClientSecuType
C
8011
Riskratio
C
15
Currency
N
8044
CustomerCapitalStatRejR
eason
Level of risk posed by client. Required when
UserRespType(8031)=0 (representing acceptance).
Type
of
client
security.
Required
when
UserRespType (8031)=0 (representing acceptance).
Risk ratio of client. Required when UserRespType
(8031)=0 (representing acceptance).
Type of currency
Reason for rejecting customer capital status request.
N
Optionally
employed
when
the
UserRespType
(8031)=1(representing rejection)
Describes the reason for rejecting customer capital
58
Text
N
status request. Optionally employed when the
UserRespType (8031)=1(representing rejection)
Standard trailer
Y
9.3.3.20 Agreement Status Request (MsgType=UF218)
It is the request of a client for the status of contracts. The agreement status request may be used to request
for the status of all contracts or a specific contract.
See Table 31 for the format of Agreement Status Request:
37
JR/T 0087—2012
Table 31 Agreement Status Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
55
Symbol
N
Contract code
207
SecurityExchange
N
Can be used to identify the exchange
Standard trailer
Y
MsgType=UF218
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
9.3.3.21 Agreement Status Response (MsgType=UF219)
It is the response made to the request of a client for the status of contracts.
See Table 32 for the format of Agreement Status Response:
Table 32 Agreement Status Response
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
8031
UserRespType
Y
Type of response to user
8026
TotalRetNum
N
Number of responses returned
8027
PresentRetNum
N
Sequence number of the present response returned
8095
NextFlag
N
Whether there is any flag for subsequent data packets
MsgType=UF219
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
Can be used to identify the exchange. Required when
207
SecurityExchange
C
AllOrdStatRespType
(8031)=0
(representing
acceptance)
8073
ExchangeName
N
55
Symbol
C
65
SymbolSfx
N
Name of contract
8075
OneLotQty
C
Number of shares in one lot. Required when
38
Name of exchange
Contract code. Required when AllOrdStatRespType
(8031)=0 (representing acceptance)
JR/T 0087—2012
Tag
Field Name
Required
Comments
UserRespType(8031)=0 (representing acceptance).
200
MaturityMonthYear
N
8076
MaxLotQty
C
8077
MaxHoldPosition
C
8078
VarietyCode
C
8079
VarietyName
C
8080
MinPxAlterUnit
C
8050
AgreementStatRejReas
on
Can be used to specify month and year of maturity
Maximum
of
lots.
Required
when
UserRespType(8031)=0 (representing acceptance).
Maximum
holding
positions.
Required
when
UserRespType(8031)=0 (representing acceptance).
Variety code. Required when AllOrdStatRespType
(8031)=0 (representing acceptance)
Variety name. Required when UserRespType(8031)=0
(representing acceptance).
Minimum unit of price change. Required when
UserRespType(8031)=0 (representing acceptance).
Reason
N
number
for
Optionally
rejecting
agreement
employed
status
when
request.
the
UserRespType(8031)=1(representing rejection)
Describes the reason for rejecting agreement status
58
Text
N
request.
Optionally
employed
when
the
UserRespType(8031)=1(representing rejection)
Standard trailer
Y
9.3.4 Market Data Messages
9.3.4.1 Notes on Market Data Messages
Market data messages mainly include those which provide support to market quotations
9.3.4.2 Market Data Status Request (MsgType=UF301)
It is the request of a client to obtain market data.
Clients may request for the market data of either all exchanges or a certain exchange, or request for the
market data of a particular contract code.
See Table 33 for the format of Market Data Status Request:
39
JR/T 0087—2012
Table 33 Market Data Status Request
Tag
Field Name
Required
Comments
Standard header
Y
262
MDReqID
Y
263
SubscriptionRequestType
Y
Type of subscription request
55
Symbol
N
Contract code
207
SecurityExchange
N
Can be used to identify the exchange
Standard trailer
Y
MsgType=301
Identifier of market data request. Its uniqueness
must be guaranteed within a single trading day.
9.3.4.3 Market Data Status Response (MsgType=UF302)
It is the response returned by a futures company to the request of a client for market data.
A futures company may voluntarily transmit market data to clients.
See Table 34 for the format of Market Data Status Response:
Table 34 Market Data Status Response
Tag
Field Name
Required
Standard header
Y
Comments
MsgType=UF302
Identifier of market data request. Its uniqueness
must be guaranteed within a single trading day.
262
MDReqID
Y
When a futures company voluntarily transmits
market data to a client, the value is the identity of
the sole string initialized with “NONE” appearing
on the trading day
iI
SubscriptionRequestType
Y
Type of subscription request
8031
UserRespType
Y
Type of response to user
Contact
code.
Required
when
SubscriptionRequestType(263)=0(snapshot) and
55
Symbol
C
UserRespType(8031)=0(representing
acceptance).
Required when
SubscriptionRequestType(263)=1 ( snapshot +
40
JR/T 0087—2012
Tag
Field Name
Required
Comments
updates) and
UserRespType(8031)=0(representing
acceptance).
Required when SubscriptionRequestType(263)=2
(canceled snapshot+ updates) and clients request
to cancel the subscription of a single contract
code.
Date of trade. Required when
SubscriptionRequestType(263)=0(snapshot) and
UserRespType(8031)=0 (representing
acceptance).
75
TradeDate
C
Required when SubscriptionRequestType(263)=1
( snapshot + updates) and
UserRespType(8031)=0(representing
acceptance).
Can be used to identify the exchange. Required
when SubscriptionRequestType(263)=0(snapshot)
and
UserRespType(8031)=0
(representing
acceptance).
207
SecurityExchange
C
Required when SubscriptionRequestType(263)=1
(snapshot + updates) and
UserRespType(8031)=0(representing
acceptance).
Number of market data price entries. Required
when SubscriptionRequestType(263)=0(snapshot)
and UserRespType(8031)=0 (representing
acceptance)
8072
NoMDPxEntries
C
Required when SubscriptionRequestType(263)=1
( snapshot + updates) and
UserRespType(8031)=0(representing
acceptance).

8103
MDPxEntryType
N
Type of market data price entry

8104
MDEntryPx
N
Market data price entry
41
JR/T 0087—2012
Tag
Field Name
Required
Comments
Previously
held
positions.
Required
when
SubscriptionRequestType (263)=0(snapshot) and
UserRespType(8031)=0
8052
PreHoldPosition
C
(representing
acceptance)
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).
Total number of shares filled. Required when
SubscriptionRequestType (263)=0(snapshot) and
UserRespType (8031)=0 (representing
14
CumQty
C
acceptance).
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).
Total amount traded. Required when
SubscriptionRequestType (263)=0(snapshot) and
UserRespType (8031)=0 (representing
381
GrossTradeAmt
C
acceptance).
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).
Average price. Required when
SubscriptionRequestType (263)=0(snapshot) and
UserRespType (8031)=0 (representing
6
AvgPx
C
acceptance).
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).
Holding positions. Required when
SubscriptionRequestType (263)=0(snapshot) and
8060
HoldPosition
C
UserRespType (8031)=0 (representing
acceptance).
Required when SubscriptionRequestType (263)=1
42
JR/T 0087—2012
Tag
Field Name
Required
Comments
( snapshot + updates) and
UserRespType(8031)=0(representing
acceptance).
8061
BidQty
N
Number of bids
8062
AskQty
N
Number of offers
Update time. Required when
SubscriptionRequestType (263)=0(snapshot) and
UserRespType (8031)=0 (representing
8063
UpdateTime
C
acceptance).
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).
Update millisecond. Required when
SubscriptionRequestType (263)=0(snapshot) and
UserRespType (8031)=0 (representing
8064
UpdateMillisec
C
acceptance).
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).
Number of offer price levels (in a descending
order). Required when SubscriptionRequestType
(263)=0(snapshot) and UserRespType (8031)=0
8065
NoOfferPriceLevel
C
(representing acceptance)
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).

133
OfferPx
N
Offer price with three decimal places

135
OfferSize
N
Quantity of offer
Number of bid price levels (in a descending
8066
NoBidPriceLevel
C
order). Required when SubscriptionRequestType
(263)=0(snapshot) and UserRespType (8031)=0
(representing acceptance)
43
JR/T 0087—2012
Tag
Field Name
Required
Comments
Required when SubscriptionRequestType (263)=1
( snapshot + updates) and UserRespType
(8031)=0(representing acceptance).

132
BidPx
N
Bid price with three decimal places

134
BidSize
N
Quantity of bid
200
MaturityMonthYear
N
Can be used to specify month and year of
maturity
Can
205
MaturityDay
N
be
used
MaturityMonthYear
in
to
conjunction
specify
a
with
particular
maturity date
Reason for rejecting market data status request.
8051
MarketDataStatRejReason
N
Optionally employed when the UserRespType
(8031)=1(representing rejection)
Describes the reason for rejecting market data
58
Text
N
status request. Optionally employed when the
UserRespType (8031)=1(representing rejection)
Standard trailer
Y
9.3.5 Transaction-assisting Messages
9.3.5.1 Notes on Transaction-assisting Messages
Transaction-assisting Messages are primarily those with some auxiliary functions which provide support to
transactions.
9.3.5.2 Response Gap Fill Resend Request (MsgType=UF801)
When a client accepts a number of responses from a futures company, if there is a possible gap in any of
the responses, the client may request the futures company to fill the gap.
See Table 35 Response Gap Fill Resend Request:
44
JR/T 0087—2012
Table 35 Response Gap Fill Resend Request
Tag
Field Name
Required
Comments
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
Capital account of client
8067
GapMessageType
Y
Type of gap message
8068
GapStartNum
Y
Starting number of gap
8069
GapEndNum
Y
Ending number of gap
Standard trailer
Y
MsgType=UF801
Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.
9.3.5.3 Response Gap Fill Resend Rejected (MsgType=UF802)
If a response gap fill request sent by a client is correct, the response made to such request will correspond
to each type of message. Otherwise, the response gap fill resend rejected will be used to respond to the
client.
See Table 36 Response Gap Fill Resend Rejected:
45
JR/T 0087—2012
Table 36 Response Gap Fill Resend Rejected
Tag
Field Name
Required
Standard header
Y
8088
RequestID
Y
109
ClientID
Y
8053
58
RespGapFillResendRejRea
son
N
Text
N
Standard trailer
Y
Comments
MsgType=UF802
Identifier of user request. Its uniqueness must
be guaranteed within a single trading day.
Capital account of client
Reason for rejecting response gap fill resend
request
Describe the reason for rejecting response gap
fill resend request
9.3.5.4 Information Issue Request (MsgType=UF803)
If necessary, a futures company may issue information to clients. When a futures company communicates
information on the opening and closing of the market or the first or last transaction to clients without
specifying a particular exchange, it means such information concerns all exchanges.
See Table 37 for the format of Information Issue Request:
Table 37 Information Issue Request
Tag
Field Name
Required
Comments
Standard header
Y
MsgType=UF803
8013
InformationID
Y
Identifier of information
8097
InfomationType
Y
Type of information
58
Text
N
Contents of information issued
207
SecurityExchange
N
Can be used to identify the exchange
Standard trailer
Y
9.3.5.5 Information Issue Response (MsgType=UF804)
It is the response returned by a client after the client has received the information issued by a futures
company
See Table 38 for the format of Information Issue Response:
46
JR/T 0087—2012
Table 38 Information Issue Response
Tag
8013
Field Name
Required
Comments
Standard header
Y
MsgType=UF804
InformationID
Y
Identifier of information
Standard trailer
Y
47
JR/T 0087—2012
10. Field Definitions
Refer to Table 39 for the field definitions of data fields used in application-level messages and the session-level messages of Schedule E and for the format of
data type definitions, see the “comments” section of data type definitions (5.1).
Table 39 Field Definitions
Chinese Name of
Tag
Field Name
1
Account
6
AvgPx
7
BeginSeqNo
8
BeginString
First string
String
9
BodyLength
Message length
Length
Message length. Always unencrypted. Always second field in message
10
CheckSum
Checksum
String
Checksum. Always unencrypted. Always last field in message
11
ClOrdID
Field
Trading code for
client
Average price
Sequence number of
first message
Identifier of client
order
Data Type
String
Price
SeqNum
Comments
Trading code assigned by an exchange for a client.
Calculated average price of all fills on an order
Message sequence number of first message in range to be resent
First string. Identifies beginning of protocol version. Always unencrypted. Always
first field in message. Valid values: FIX.4.2
Identifier of order assigned by a client. Its uniqueness must be guaranteed within a
String
valid trading day. With respect to a multi-day order, the date of trade may be
embedded within the ClOrdID field. In the case of information on forced liquidation,
48
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
the value is the identity of the sole string initialized with “NONE” appearing on the
trading day
12
Commission
14
CumQty
Commission
Total number of
shares filled
Amt
Qty
Commissions charged by a futures company
Total number of shares filled or positions held
Identifies the unit of currency used for price. Absence of this field is interpreted as
15
Currency
Type of currency
Currency
the default value. It is recommended that the currency value is provided whenever
possible
Message sequence number of last message in range to be resent
16
EndSeqNo
Sequence number of
last message
SeqNum
If request is for the resending of a single message, BeginSeqNo = EndSeqNo
If request is for the resending of all messages subsequent to BeginSeqNo, EndSeqNo
= “0”
Identifier of execution message assigned by a futures company. Its uniqueness must
17
ExecID
Identifier of execution
message
String
be guaranteed within a valid trading day. Mainly used to correspond to specific
messages contained in an execution report. In the response to any request for the
status of an order, the value is “0”.
49
JR/T 0087—2012
Tag
Field Name
30
LastMkt
31
LastPx
32
LastShares
34
MsgSeqNum
Chinese Name of
Field
Market of execution
for last fill
Price of last fill
Quantity of shares
traded on last fill
Message sequence
number
Data Type
Comments
Exchange
Price
Qty
SeqNum
Price of the most recent fill on an order
Quantity of shares traded on the most recent fill of an order
Message sequence number. A fixed value may be set for this tag (e.g. 0) if the two
parties involved in a transaction do not use the FIX session mechanism.
Message type. Always unencrypted. Always third field in message. A “U” as the first
character in the MsgType field indicates that the message format is privately defined
between the sender and receiver. Valid values:
0=Heartbeat
35
MsgType
Message type
String
1=Test Request
2=Resend Request
3=Reject
4=Sequence Reset
50
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
5=Logout
8=Execution Report
9=Order Cancel Reject
A=Logon
D=Order – Single
F=Order Cancel Request
H=Order Status Request
UF001=User Logon Reques
UF002=User Logon Response
UF003=User Logout Request
UF004=User Logout Response
UF005=User Change PassWd Request
UF006=User Change PassWd Response
UF201=Position Status Request
51
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
UF202=Position Status Response
UF203=Max Operation Position Status Request
UF204=Max Operation Position Status Response
UF205=All Orders Status Request
UF206＝All Orders Status Response
UF207=Settlement Result Status Request
UF208=Settlement Result Status Response
UF209=Settlement Result Comfirm Request
UF210=Settlement Result Comfirm Response
UF211=Settlement Result Comfirm Status Request
UF212=Margin Rate Status Request
UF213=Margin Rate Status Response
UF214=Commission Rate Status Request
UF215=Commission Rate Status Response
52
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
UF216=Customer Capital Status Request
UF217=Customer Capital Status Response
UF218=Agreement Status Request
UF219=Agreement Status Response
UF301=Market Data Status Request
UF302=Market Data Status Response
UF801=Response Gap Resend Request
UF802=Response Gap Fill Resend Rejected
UF803=Information Issue Request
UF804=Information Issue Response
36
NewSeqNo
37
OrderID
Sequence number of
new message
Identifier for order as
assigned by a futures
SeqNum
String
Sequence number of new message
Identifier for order as assigned by a futures company. Its uniqueness must be
guaranteed within a single trading day.
53
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
company
38
OrderQty
Number of orders
Qty
Number of orders
Identifies current status of order. Valid values:
0=New
1=Partially filled
2=Filled
4=Canceled
6=Pending Cancel
39
OrdStatus
Status of order
char
7=Stopped
8=Rejected
9=Suspended
A=Pending New
B=Calculated
C=Expired
54
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
Order type. Valid values:
1=Market
2=Limit
a=Best price
b=Newest price
c=Newest price up one tick
d= Newest price up two ticks
40
OrdType
Order type
char
e=Newest price up three ticks
f=Lowest selling price
g= Lowest selling price up one tick
h=Lowest selling price up two ticks
i=Lowest selling price up three ticks
j=Highest buying price
k=Highest buying price up one tick
55
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
l=Highest buying price up two ticks
m=Highest buying price up three ticks
41
OrigClOrdID
ClOrdID of the
previous order
String
ClOrdID of the previous order when canceling an order
Indicates possible retransmission of message with this sequence number. Valid
values:
43
PossDupFlag
Possible duplicate flag
Boolean
Y = Possible duplicate
N = Original transmission
44
Price
45
RefSeqNum
49
SenderCompID
50
SenderSubID
56
Price
Sequence number of
reference message
Identifier of message
sender.
Identifier of specific
message originator
Price
SeqNum
String
String
Price
Sequence number of the reference message in connection with a message
Assigned value used to identify firm sending message.
Assigned value used to identify specific message originator (e.g. trader)
JR/T 0087—2012
Tag
Field Name
52
SendingTime
Chinese Name of
Field
Data Type
Time of transmission UTCTimestamp
Comments
Time of message transmission
Side of order. Valid values:
54
Side
Side of order
char
1=Buy
2=Sell
55
Symbol
56
TargetCompID
57
TargetSubID
58
Text
Contract code
Identifier of message
receiver
Identifier of specific
message receiver
Text
String
String
String
String
Assigned value used to identify receiving firm
Assigned value used to identify specific individual intended to receive message
Free format text string
Specifies the time when the order becomes effective. Valid values:
0=Day
59
TimeInForce
Time of effectiveness
char
1= Good Till Cancel
2=Good during This Section
57
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
3=Immediate or Cancel
6=Good Till Date
7=Good by Call Auction
60
TransactTime
Transaction time
UTCTimestamp
65
SymbolSfx
Contract name
String
75
TradeDate
Date of trade
LocalMktDate
Time of order or execution creation
Flag of opening or closing a position. Valid values:
O=Open
77
OpenClose
Flag of opening or
closing a position
C=Close
char
Y=Yesterday position closed
T=Today position closed
Q= Liquidation forced
89
Signature
Electronic signature
data
90
SecureDataLen
Length of encrypted
Length
58
Electronic signature
Length of encrypted data block
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
data
91
SecureData
93
SignatureLength
95
RawDataLength
96
RawData
Encrypted data
Length of electronic
signature
Length of unformatted
raw data
Unformatted raw data
data
Length
Length
data
Encrypted data block
Number of bytes in electronic signature field
Number of bytes in raw data field
Unformatted raw data, can include bitmaps, word processor documents, etc.
Indicates that message may contain information that has been sent under another
sequence number. Valid values:
97
PossResend
Possible resend flag
Boolean
Y = Possible resend
N = Original transmission
Method of encryption. Valid values:
0=None / other
98
EncryptMethod
Method of encryption
int
1=PKCS(proprietary)
2=DES(ECB mode)
59
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
3=PKCS/DES(proprietary)
4=PGP/DES
5=PGP/DES-MD5
6=PEM/DES-MD5
99
StopPx
Stop price
Price
Code to identify reason for rejecting order cancel request. Valid values:
0=Too late to cancel
1=Unknown order
2=Broker / Exchange Option
102
CxlRejReason
Reason for rejecting
order cancel request
int
3=Order already in Pending Cancel or Pending Replace status
4=Unable to process Order Mass Cancel Request
5=OrigOrdModTime did not match last TransactTime of order
6=Duplicate ClOrdID received
7=Parked cancel not found
60
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
8=Parked cancel has been sent
9=Parked cancel has been deleted
10=Broker did not have enough number of available conditional orders
11=Investor did not have enough number of available conditional orders
12=Broker did not support conditional order
99=Other
Code to identify reason for order rejection. Valid values:
0=Broker / Exchange option
1=Unknown symbol
103
OrdRejReason
Reason for order
rejection
2=Exchange closed
int
3=Order exceeds limit
4=Too late to enter
5=Unknown Order
6=Duplicate Order (e.g. dupe ClOrdID))
61
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
7=Duplicate of a verbally communicated order
8=Stale Order
9=Trade Along required
10=Invalid Investor ID
11=Unsupported order characteristic
12=Surveillance Option
13=Incorrect quantity
14=Incorrect allocated quantity
15=Unknown account(s)
16=Over close position
17=Insufficient money
18=Parked order not found
19=Parked order has been sent
20=Parked order has been deleted
62
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
21=Over close today position
22=Over close yesterday position
23=Broker did not have enough number of available conditional orders
24=Investor did not have enough number of available conditional orders
25=Broker did not support conditional order
99=Other
107
SecurityDesc
Securities description
String
108
HeartBtInt
Heartbeat interval
int
109
ClientID
Capital account of
String
Descriptive information on securities. An English abbreviation used to describe
securities in FIX protocol.
Heartbeat interval (seconds)
Capital account opened by a client with a futures company.
client
Minimum quantity of
110
MinQty
an order to be
Qty
executed
Maximum number of
111
MaxFloor
shares within an order
Maximum number of shares within an order to be shown on the exchange floor at
Qty
any given time.
to be shown on the
63
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
exchange floor at any
given time.
112
115
TestReqID
OnBehalfOfCompID
116
OnBehalfOfSubID
122
OrigSendingTime
Test request identifier
Identifier of message
originator
Identifier of specific
message originator
Time of original
transmission
String
Identifier included in Test Request message to be returned in resulting Heartbeat
Assigned value used to identify firm originating message if the message was
String
delivered by a third party i.e. the third party firm identifier would be delivered in the
SenderCompID field.
String
UTCTimestamp
Assigned value used to identify specific message originator (i.e. trader) if the
message was delivered by a third party
Time of original message transmission recorded when transmitting orders as the
result of a resend request
Indicates that the Sequence Reset message is replacing messages which will not be
resent. Valid values:
123
GapFillFlag
Gap fill flag
Boolean
Y= Sequence Reset -Gap Fill message, MsgSeqNum field valid
N=Sequence Reset-Reset Message, ignore MsgSeqNum
126
64
ExpireTime
Time of order
expiration
UTCTimestamp
Conditionally required if TimeInForce = GTD and ExpireDate is not specified.
JR/T 0087—2012
Tag
128
Field Name
DeliverToCompID
Chinese Name of
Field
Identifier of message
recipient
Identifier of specific
Data Type
Assigned value used to identify the firm targeted to receive the message if the
String
DeliverToSubID
132
BidPx
133
OfferPx
134
BidSize
Quantity of bid
Qty
135
OfferSize
Quantity of offer
Qty
136
NoMiscFees
137
MiscFeeAmt
139
MiscFeeType
Bid price with three
decimal places
Offer price with three
decimal places
Number of types of
miscellaneous fees
Amount of
miscellaneous fees
Type of miscellaneous
message is delivered by a third party i.e. the third party firm identifier would be
delivered in the TargetCompID field
129
message recipient
Comments
String
Assigned value used to identify specific message recipient if the message is delivered
by a third party.
Price
Price
NumInGroup
Amt
String
Number of repeating groups of miscellaneous fees
Amount of miscellaneous fees
Indicates type of miscellaneous fee. Valid values:
65
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
fee
Comments
1=Regulatory (e.g. SEC)
2=Tax
3=Local Commission
4=Exchange Fees
5=Stamp
6=Levy
7=Other
8=Markup
9=Consumption Tax
10=Per transaction
11=Conversion
12=Agent
13=TransferFee
140
66
PreClosePx
Previous closing price
Price
Previous closing price
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
Indicates whether the both sides of the session should reset sequence numbers. Valid
141
ResetSeqNumFlag
Sequence number
reset flag
values:
Boolean
Y=Yes, reset sequence numbers
N=No
Assigned value used to identify specific message sender’s location
Identifier of specific
142
SenderLocationID
message sender's
String
location
Assigned value used to identify specific message receiver’s location
Identifier of specific
143
TargetLocationID
message receiver's
String
location
144
OnBehalfOfLocation
ID
Assigned value used to identify specific message originator’s location if the message
Identifier of specific
message originator's
String
location
Assigned value used to identify specific message recipient’s location if the message
Identifier of specific
145 DeliverToLocationID
was delivered by a third party
message recipient's
String
was delivered by a third party
location
150
ExecType
Type of execution
char
Type of execution report, used in conjunction with OrdStatus. Valid values:
67
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
0=New
4=Canceled
6=Pending Cancel
7=Stopped
8=Rejected
9=Suspended
A=Pending New
B=Calculated
C=Expired
F=Trade (partial fill or fill))
I=Order Status
151
LeavesQty
167
SecurityType
68
Remaining quantity of
an existing order
Type of securities
Qty
String
Amount of shares open (matchable) for further execution.
Indicates type of securities. FUT＝futures
JR/T 0087—2012
Chinese Name of
Tag
Field Name
168
EffectiveTime
200
MaturityMonthYear
205
MaturityDay
Date of maturity
day-of-month
207
SecurityExchange
Exchange code
Exchange
Field
Time during which an
order remains in effect
Month and year of
maturity
Data Type
Comments
UTCTimestamp
month-year
Format: YYYYMM (e.g.201010)
Used in conjunction with Maturity Month Year. Valid values: 1-31
ISO10383Standard in which
CCFX=China Financial Futures Exchange
Type of subscription request. Valid values:
263
SubscriptionRequest
Type of subscription
Type
request
0=Snapshot, subscribe only for the up-to-date market data
char
1=Snapshot + Updates, subscribe for ongoing market data
2=Disable previous Snapshot + Update Request , unsubscribe
Type of message encoding (non-ASCII characters) used in a message’s “Encoded”
347
MessageEncoding
Type of message
encoding
fields. Valid values:
String
ISO-2022-CN
UTF-8 (for using Unicode)
69
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
GBK (the Chinese Internal Code Specification applicable to the Mainland of China
and Singapore)
GB2312(Chinese character encoding of the People's Republic of China used for
information exchange )
354
EncodedTextLen
Length of encoded
text
Length
Number of bytes in the Encoded Text field
Encoded representation of the Text field in the encoded format specified via the
355
EncodedText
Encoded text
data
Message Encoding field. If used, the ASCII representation must also be specified in
the Text field
369
370
LastMsgSeqNumPro
cessed
last message
Time of initial
Sending Time
transmission
RefTagID
372
RefMsgType
The last MsgSeqNum value received and processed. Can be specified on every
SeqNum
message sent. Useful for detecting a backlog with the counterparty.
processed
On Behalf Of
371
70
Sequence number of
Number of relevant
tag
Type of relevant
UTCTimestamp
int
String
Indicates the tag being referenced
Type of the message being referenced
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
message
Code to identify reason for a session-level Reject message. Valid values:
0=Invalid tag number
1=Required tag missing
2=Tag not defined for this message type
3=Undefined Tag number
4=Tag specified without a value
Reason for a
373 SessionRejectReason session-level Reject
message
int
5=Value is incorrect (out of range) for this tag
6=Incorrect data format for value
7=Decryption problem
8=Signature problem
9=CompID problem
10=SendingTime accuracy problem
11=Invalid MsgType
71
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
12=XML Validation error
13=Repeating within a tag(not a repeating group)
1 =Error in the sequence of fields with a sequence number
15=Error in the sequence of repeating group fields
16= Error in the number of repetition for the repeating group
17=Appearance of the field delimiter <SOH> in a data field other than that of data
Code to identify reason for a voluntary execution given in the execution report
voluntarily sent by a service provider. Valid values:
0=GT Corporate action
378
ExecRestatementRea
son
1=GT renewal / restatement (no corporate action)
Restatement reason
int
2=Verbal change
3=Repricing of order
4=Broker option
5=Partial decline of OrderQty (e.g. exchange-initiated partial cancel))
72
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
6=Cancel on Trading Halt
7=Cancel on System Failure
8=Market (Exchange) Option
101=Repurchase Settlement
381
GrossTradeAmt
383
MaxMessageSize
384
NoMsgTypes
Total amount traded
Maximum length of
message
Number of message
types
Amt
Length
NumInGroup
Total amount traded: CumQty * AvgPx (expressed in units of currency)
Maximum number of bytes in a single message
Number of message types in a repeating group
Specifies the direction of the message. Valid values:
385
MsgDirection
Direction of message
char
S=Send
R=Receive
Code to represent the price type. Valid values:
423
PriceType
Price type
int
1= Percentage
2=Per unit (i.e. per share or contract)
73
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
3=Fixed Amount (absolute value)
4=Discount – percentage points below par
5=Premium – percentage points over par
6=Basis points relative to benchmark
7=TED price
8=TED yield
432
ExpireDate
Date of order
expiration
LocalMktDate
Type of request that a
434
CxlRejResponseTo
Cancel Reject is in
Conditionally required if TimeInForce = GTD and ExpireTime is not specified.
Identifies the type of request that a Cancel Reject is in response to. Valid values:
char
1=Order Cancel Request
response to
8001
LogonPasswd
Transaction password
String
Status of client logon. Valid values:
8002
LogonStatus
Status of logon
char
0=Logon
1=Logout
74
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
9=Other
8003
AccountName
Account name
String
Level of risk posed by the account. Valid values:
0=Normal
1=Additional margin
8004
RiskLevel
Level of risk
char
2=Forced liquidation
3=Warning
4= Margin call liquidation
5=Abnormal
8005
AdditionalMargin
Additional margin
Amt
Type of client security. Valid values:
0= Safe client
8006
ClientSecuType
Type of client security
char
1=Low-risk client
2=Risky client
75
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
3=Frozen client
4=Client deserving attention
8007
LastLogonIP
IP address for the last
logon
String
Date and time when
8008
LastLogonTime
the last logon was
IP address which was used by a client to make the last logon
Date and time when a client made the last logon
UTCTimestamp
made
Flag of speculation or hedge. Valid values:
8009
HedgeFlag
Flag of speculation or
hedge
0=Speculation
char
1=Hedge
2=Arbitrage
Trigger condition for order. Valid values:
1=Immediate
8010
TouchCondition
Trigger condition
char
2=Stop loss
3=Stop profit
76
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
4=Parked order
5=Conditional price > newest price
6= Conditional price≥ newest price
7=Conditional price < newest price
8=Conditional price ≤ newest price
9=Conditional price > lowest selling price
A=Conditional price ≥ lowest selling price
B=Conditional price < lowest selling price
C=Conditional price ≤ lowest selling price
D=Conditional price > highest buying price
E=Conditional price ≥ highest buying price
F=Conditional price < highest buying price
H=Conditional price ≤ highest buying price
8011
Riskratio
Risk ratio of client
float
Risk ratio of client= margin occupied/ client equity
77
JR/T 0087—2012
Chinese Name of
Tag
Field Name
8012
LatestPx
8013
InformationID
8014
TotalExMarginAmt
8015
TdPosition
Today positions
Qty
8016
YDPosition
Yesterday positions
Qty
8017
FrozenPosition
8018
FrozenAmt
8019
PositionDate
8020
FrozenCommision
8021
PositionProfit
78
Field
The latest price
Identifier of
information
Total margin of
exchange
Number of positions
frozen
Amount frozen
Date on which a
positions was held
Commission for
freezing the position
Profit or loss from the
positions
Data Type
Price
String
Amt
Qty
Amt
LocalMktDate
Amt
Amt
Comments
JR/T 0087—2012
Tag
Field Name
8022
PositionPrice
8023
MaxOpenPosition
8024
MaxClosePosition
8025 MaxCloseTdPosition
8026
TotalRetNum
Chinese Name of
Field
Average price of the
positions
Maximum number of
positions opened
Maximum number of
positions closed
Maximum number of
today positions closed
Number of responses
returned
Data Type
Comments
Amt
Qty
Qty
Qty
int
Sequence number of
8027
PresentRetNum
the present response
int
returned
8028
SettlementDate
8029
SettlementConfirm
Date of settlement
results
Confirmation of
settlement results
LocalMktDate
char
Valid values:
79
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
0＝Confirm settlement results
Valid values:
8030
SettlementConfirmR Results of settlement
esult
result confirmation
char
0＝Settlement results confirmed
1＝Settlement results not confirmed
Type of response made to the request of a client. Valid values:
Type of response
8031
UserRespType
made to the request of
int
a client
0=Acceptance
1＝Rejection
Reason for rejecting logon request. Valid values:
0= Repeating RequestID
1= Invalid ClientID
8032
LogonRejReason
Reason for rejecting
logon request
int
2=Password error
3=Repeating logon request
4= Lower version of client computer
99=Other
80
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
Reason for rejecting logout request. Valid values:
0= Repeating RequestID
8033
LogoutRejReason
Reason for rejecting
logout request
int
1= Invalid ClientID
2=No logon
99=Other
Reason for rejecting password change request. Valid values:
0= Repeating RequestID
8034
ChangePWRejReaso
n
1= Invalid ClientID
Reason for rejecting
password change
int
request
2=Wrong PassWdType
3=OldPassWd error
4=Unqualified NewPassWd
99=Other
8035
PosStatReqType
Type of position status
request
Type of position status request. Valid values:
int
0=Current position status request
81
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
1=Previous position status request
Reason for rejecting position status request. Valid values:
0= Repeating RequestID
1= Invalid ClientID
2=Wrong RequestType
8036
PosStatRejReason
Reason for rejecting
position status request
int
3=Wrong Account
4=Wrong Symbol
5=Wrong SecurityExchange
6=Wrong date range
99=Other
Reason for rejecting max operation position status request. Valid values:
8037
MaxOpPosStatRejRe
ason
Reason for rejecting
max operation
position status request
0= Repeating RequestID
int
1= Invalid ClientID
2=Wrong Account
82
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
3=Wrong Symbol
4=Wrong SecurityExchange
5=Positions opened without specifying the price
99=Other
Type of all orders status request. Valid values:
8038
AllOrdStatReqType
Type of all orders
status request
int
0=Type of all current orders status request
1=Type of all previous orders status request
Reason for rejecting all orders status request. Valid values:
0= Repeating RequestID
1= Invalid ClientID
Reason for rejecting
8039 AllOrdStatRejReason
all orders status
request
int
2=Wrong RequestType
3=Wrong SecurityExchange
4=Wrong date range
99=Other
83
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
Reason for rejecting settlement result status request. Valid values:
0= Repeating RequestID
8040
SettlementResultStat
RejReason
Reason for rejecting
settlement result status
1= Invalid ClientID
int
2=Wrong SettlementDate
request
3=Wrong SecurityExchange
99=Other
Reason for rejecting settlement result confirm request. Valid values:
0= Repeating RequestID
8041
SettlementResultCon
firmRejReason
1= Invalid ClientID
Reason for rejecting
settlement result
int
confirm request
2=Wrong SettlementDate
3=Wrong SettlementConfirm
4=Wrong SecurityExchange
99=Other
8042 MarginRateStatRejR
84
Reason for rejecting
margin rate status
int
Reason for rejecting margin rate status request. Valid values:
JR/T 0087—2012
Tag
Field Name
eason
Chinese Name of
Field
Data Type
request
Comments
0= Repeating RequestID
1= Invalid ClientID
2=Wrong Account
3=Wrong VarietyCode
4=Wrong Symbol
5=Wrong MaturityMonthYear
6=Wrong SecurityExchange
99=Other
Reason for rejecting commission rate status request. Valid values:
0= Repeating RequestID
8043
CommissionRateStat
RejReason
Reason for rejecting
commission rate status
request
1= Invalid ClientID
int
2=Wrong VarietyCode
3=Wrong Symbol
4=Wrong MaturityMonthYear
85
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
5=Wrong SecurityExchange
99=Other
Reason for rejecting customer capital status request. Valid values:
8044
CustomerCapitalStat
RejReason
0= Repeating RequestID
Reason for rejecting
customer capital status
int
request
1= Invalid ClientID
2=Wrong Currency
99=Other
8045
BuyMarginAmt
Margin buying
Amt
8046
SellMarginAmt
Margin selling
Amt
Additional margin
Amt
8047
SupplementalMargin
Amt
8048
OccupyMarginAmt
Margin occupied
Amt
8049
TotalMarginAmt
Total margin
Amt
8050 AgreementStatRejRe Reason for rejecting
agreement status
86
int
Reason for rejecting agreement status request. Valid values:
JR/T 0087—2012
Tag
Field Name
ason
Chinese Name of
Field
Data Type
request
Comments
0= Repeating RequestID
1=Wrong Symbol
2=Wrong SecurityExchange
99=Other
Reason for rejecting password change request. Valid values:
0= Repeating MDReqID
8051
MarketDataStatRejR
eason
Reason for rejecting
market data status
1=SubscriptionRequestType error
int
2=Symbol error
request
3=SecurityExchange error
99=Other
8052
8053
PreHoldPosition
RespGapFillResendR
ejReason
Previously held
positions
Qty
Reason for rejecting
response gap fill
Reason for rejecting response gap fill resend request. Valid values:
int
0= Repeating RequestID
resend request
87
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
1= Invalid ClientID
2= Wrong GapMessageType
3=Wrong gap number
99=Other
8054
NoMarginEntries
Number of margin
entries
int
Type of margin. Valid values:
0=Bull speculation
1=Bear speculation
2=Long hedge
8055
MarginType
Type of margin
int
3=Short hedge
4=Long arbitrage
5=Short arbitrage
99=Other
88
JR/T 0087—2012
Chinese Name of
Tag
Field Name
8056
MarginRate
Margin rate
float
8057
MaginAmt
Margin amount
Amt
NoCommissionEntrie
Number of
s
commission entries
8058
Field
Data Type
Comments
int
Type of margin. Valid values:
0=Open
8059
CommissionType
Type of commission
int
1=Close
2= Today positions closed
99=Other
8060
HoldPosition
Holding positions
Qty
8061
BidQty
Number of bids
Qty
8062
AskQty
Number of offers
Qty
8063
UpdateTime
Update time
LocalMktDate
8064
UpdateMillisec
Update millisecond
String
89
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
Number of offer price
8065
NoOfferPriceLevel
levels (in a
NumInGroup
descending order)
Number of bid price
8066
NoBidPriceLevel
levels (in a
NumInGroup
descending order)
Valid values:
0＝Response gap with respect to current/previous position status request
1＝Response gap with respect to all current/previous orders position status request
8067
GapMessageType
Type of gap message
char
2＝Response gap with respect to settlement result status request
3＝Response gap with respect to commission rate status request
4＝Response gap with respect to agreement status request
8068
GapStartNum
8069
GapEndNum
90
Starting number of
gap
Ending number of gap
SeqNum
SeqNum
JR/T 0087—2012
Chinese Name of
Tag
Field Name
8070
CommissionRate
Commission rate
float
8071
CommssionAmt
Commission
Amt
8072
NoMDPxEntries
8073
ExchangeName
Name of exchange
String
8074
TotalFrozenAmt
Total frozen amount
Amt
8075
OneLotQty
8076
MaxLotQty
8077
MaxHoldPosition
8078
VarietyCode
Variety code
String
8079
VarietyName
Variety name
String
8080
MinPxAlterUnit
Minimum unit of
Amt
Field
Number of market
data price entries
Number of shares in
one lot
Maximum number of
lots
Maximum holding
positions
Data Type
Comments
int
Qty
Qty
Qty
91
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
price change
Amount settled
8081
YesterdayStlAmt
8082
BuyFrozenAmt
Buy frozen amount
Amt
8083
SellFrozenAmt
Sell frozen amount
Amt
8084
UsableAmt
Usable capital
Amt
8085
FloatProfit
Floating profit or loss
Amt
8086
CloseProfit
yesterday
Profit or loss from the
closing of positions
Amt
Amt
Outgoing and
8087
DayFolatProfit
incoming payments on
Amt
the day
If a futures company voluntarily transmits messages to a client, the value is the
Identifier of user
8088
RequestID
request. Its uniqueness
must be guaranteed
within a single trading
92
String
identity of the sole string initialized with “NONE” appearing on the trading day The
RequestID is issued by a requester and the responder shall, in giving a response,
align such RequestID with the corresponding requester.
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
day.
Valid values:
0＝Trading password
8089
PassWdType
Type of password
char
1＝Capital password
2＝Order password
8090
OldPassWd
Old password of user
String
8091
NewPassWd
New password of user
String
8092
SettleFee
Settlement fees
Amt
8093
DeclarationID
8094
TradeID
Identifier of
declaration
Identifier of trade
String
String
Identifier of declaration assigned by an exchange.
Identifier of trade assigned by an exchange.
Whether there is any
8095
NextFlag
flag for subsequent
Boolean
data packets
8096
MacNetInfo
Computer network
String
Computer network information. The format is “information number: value|
93
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
information number: value…” and the valid values of the information number:
information
0=IP address
1＝MAC address
2＝ Motherboard number
3＝CPU number
4＝ Hard disk number
Type of information issued by a futures company. Valid values:
0=General notice
1＝Opening
8097
InfomationType
Type of information
char
2＝Closing
3＝First transaction
4＝Last transaction
5＝Suspension of trading on an exchange (used at the centralized cross-matching
phase after the call auction or used for some special situation)
94
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
6＝Trading tips
7＝Market information
8＝Advisory information
Capital available for
8098
FetchAmt
8099
DayPaymentAmt
8100
DayIncomeAmt
8101
BeginDate
Beginning date
LocalMktDate
8102
EndDate
Ending date
LocalMktDate
withdrawal
Outgoing payments on
the day
Incoming payments
on the day
Amt
Amt
Amt
Type of market data price. Valid values:
8103
MDPxEntryType
Type of market data
price entry
0=Newest price
int
1=Yesterday's settlement price
2=Yesterday's closing price
95
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
3=Opening price
4=Highest price
5=Lowest price
6=Today's closing price
7=Settlement price
8=Limit-up price
9=Limit-down price
99=Other
8104
MDEntryPx
8105
ClientSoftName
8106
ClientSoftVersion
8500
OrderEntryTime
96
Market data price
entry
Name of client
software
Version of client
software
Time at which an
Price
String
String
UTCTimestamp
JR/T 0087—2012
Tag
Field Name
Chinese Name of
Field
Data Type
Comments
order was entered
97
JR/T 0087—2012
11. Format of Settlement Data Files
A settlement data sender transmits each day in the following way to fund management
companies and custodian banks respectively the customer fund file, the customer fund change
file, the trading data file, the holding data file, the liquid details file, the holding details file and
the delivering details file: homogeneous data concerning all fund products under a fund
management company or custodian bank is merged into one file and an empty file shall be
transmitted in the absence of such data. Therefore, a settlement data sender each day needs to
transmit 7 text files to fund management companies or custodian banks. These files are
respectively the customer fund file, the customer fund change file, the trading data file, the
holding data file, the liquid details file, the holding details file and the delivering details file.
The naming rules for these files are as follows:
Uniform identifier of sender+ name of file type + date + organization code of recipient (fund
management company or custodian bank).text
For the identifier of sender (number (4), hereinafter represented with XXXX), the encoding
method of China Futures Margin Monitoring Center, Co., Ltd is adopted and, for the fund
management company or custodian bank, the organization code (char (40), hereinafter
represented with Y) is used.
11.1 Customer Fund File
The name of a customer fund file a sender (with the uniform identifier XXXX) transmits to a
fund management company or custodian bank (organization code certificate Y):
XXXXcusfund+date_Y.txt
For example, the name of a customer fund file which is transmitted on October 8, 2005 by a
futures company with the identifier of 0001 to a fund management company with the
organization code of710685288 is 0001cusfund20051008_710685288.txt.
A sender each day needs to transmit to a fund management company or custodian bank a
customer fund file with the corresponding name. A corresponding entry is entered for each
CliendID. For the field and data type of each entry, see Table 40:
Table 40 Customer Fund File
Field
Data type
Blank or not
Date
date
N
Internal ClientID
char(18)
N
Total Equity
number(14,2)
N
98
Comments
Format: yyyy-mm-dd
Client equity on the day
JR/T 0087—2012
Field
Data type
Blank or not
Comments
Usable capital calculated based on
the
mark-to-market
accounting
method. In addition, under the
transaction-by-transaction
offsetting approach, the amount of
UsableAmt
number(14,2)
N
floating profit or loss shall, after
being included in the usable
capital, equal to the usable capital
calculated
based
mark-to-market
on
the
accounting
method.
Additional Margin
Required
RiskLevel
number(14,2)
N
number(14,2)
N
number(14,2)
N
number(14,2)
Y
number(14,2)
N
number(14,2)
Y
The percent sign % is omitted. For
example, 46 represents 46%
YesterdayStlAmt
(based on mark to
market)
YesterdayStlAmt
(based on
transaction-by-transact
ion offsetting)
TodayStlAmt (based
on mark to market)
TodayStlAmt (based
on
transaction-by-transact
ion offsetting)
Today total profit or loss based on
the mark to market accounting
TodayTotalProfit
(based on mark to
market)
number(14,2)
N
method. The calculation formula:
today position profit or loss+
profit or loss on closed positions+
profit or loss from delivery and
99
JR/T 0087—2012
Field
Data type
Blank or not
Comments
matching
TodayTotalProfit
(based on
transaction-by-transact
Profit or loss on closed positions
number(14,2)
Y
ion offsetting)
transaction-by-transaction
offsetting approach
Floating profit or loss calculated
FloatProfit (based on
transaction-by-transact
based on the
number(14,2)
Y
ion offsetting)
based on the
transaction-by-transaction
offsetting approach
Pledged capital provided by a
PledgedAmt
number(14,2)
N
futures company on the statement
of account for a client
Non-settlement
char
N
char(10)
N
char(10)
N
Member or Not
Uniform Identifier of
Settlement Member
Uniform Identifier of
Exchange Member
None
Encoding method of China Futures
Margin Monitoring Center
Encoding method of China Futures
Margin Monitoring Center
For example:
2004-12-15@[email protected]@[email protected]@[email protected]@510000.00@5000
[email protected]@[email protected]@[email protected]@N@0001@0001
11.2 Customer Fund Change File
The name of a customer fund change file a sender (with the uniform identifier XXXX)
transmits to a fund management company or custodian bank (organization code certificate Y):
XXXXfundchg+date_Y.txt
For example, the name of a customer fund change file which is transmitted on October 8, 2005
by a futures company with the identifier of 0001 to a fund management company with the
organization code of710685288 is 0001fundchg20051008_710685288.txt.
A sender each day needs to transmit to a fund management company or custodian bank a
customer fund change file with the corresponding name. A fund management company enters
an entry for each outgoing or incoming payment. For the field and data type of each entry, see
100
JR/T 0087—2012
Table 41:
Table 41 Customer Fund Change File
Contents
Data type
Blank or not
Comments
Date
date
N
Format: yyyy-mm-dd
Internal ClientID
char(18)
N
Outgoing payments are
Payment and
IncomeAmt
number(14,2)
N
recorded
as
negative.
Incoming payments are
recorded as positive.
Uniform Identifier
Assigned by Bank to
Client Futures
For
char(2)
Y
Settlement Account
Settlement Account
and
incoming payments not
transferred
by
banks,
such field can be empty.
For
Client Futures
outgoing
char(22)
Y
outgoing
and
incoming payments not
transferred
by
banks,
such field can be empty.
For
Uniform Identifier
Assigned by Bank to
char(2)
Y
Firm Margin Account
and
incoming payments not
transferred
by
banks,
such field can be empty.
For
Firm Margin Account
outgoing
char(22)
Y
outgoing
and
incoming payments not
transferred
by
banks,
such field can be empty.
Comments
Non-settlement member
or not
Uniform Identifier of
Settlement Member
Uniform Identifier of
char(40)
Y
char
N
None
Encoding
char(10)
N
method
of
China Futures Margin
Monitoring Center
char(10)
N
Encoding
method
of
101
JR/T 0087—2012
Exchange Member
China Futures Margin
Monitoring Center
For example:
2005-12-15@[email protected]@01@1234567890123@02@8888888888888@@N@0001
@0001
2005-12-15@[email protected]@05@9999999999999@03@777777777777@@N@0001
@0001
11.3 Trading Data File
The name of a trading data file a sender (with the uniform identifier XXXX) transmits to a fund
management
company
or
custodian
bank
(organization
code
certificate
Y):
XXXXtrddata+date_Y.txt
For example, the name of a customer fund file which is transmitted on October 8, 2005 by a
futures company with the identifier of 0001 to a fund management company with the
organization code of710685288 is 0001trddata20051008_710685288.txt.
A sender each day needs to transmit to a fund management company or custodian bank a
trading data file with the corresponding name. For the field and data type of each entry, see
Table 42:
Table 42 Trading Data File
Field
Data type
Blank or not
Date
date
N
Internal ClientID
char(18)
N
Deal Serial Number
char(8)
N
Contract Variety
char(6)
N
Trade Flag
char
N
Buy-B. Sell-S
Trading Volume
number(10)
N
Unit: lot
Trading Price
number(14,2)
N
Trading Turnover
number(14,2)
N
Deal Time
time
N
102
Comments
Format: yyyy-mm-dd
Deal Serial Number issued
by an exchange
Format: hh: mm :ss
JR/T 0087—2012
Field
Data type
Blank or not
OpenClose
char
N
HedgeFlag
char
N
number(14,2)
N
CloseProfit (based on
mark to market)
Comments
Opened position-O. Closed
position-L
Speculation-S.
Hedge-H.
Arbitrage-A.
In the case of opening a
position, such field is 0.
Profit or loss on closed
positions based on the
CloseProfit (based on
transaction-by-transacti number(14,2)
Y
on offsetting)
transaction-by-transaction
offsetting approach. In the
case of opening a position,
the field is 0.
Commission
number(14,2)
N
Trading
Account
char(10)
N
code
of
an
exchange to which the
trade corresponds
Dalian Commodity
Exchange-D. Zhengzhou
Uniform Identifier of
Exchange
Commodity Exchange-Z.
char
N
Shanghai Futures
Exchange-S. China
Financial Futures
Exchange -J.
Non-settlement
member or not
char
N
None
Identifier of declaration in
DeclarationID
char(12)
N
the contract note of an
exchange
Seat Number
Uniform Identifier of
Settlement Member
char(15)
N
Encoding method of China
char(10)
N
Futures Margin Monitoring
Center
103
JR/T 0087—2012
Field
Data type
Blank or not
Comments
Encoding method of China
Uniform Identifier of
char(10)
Exchange Member
N
Futures Margin Monitoring
Center
For example:
2005-01-21@000001@00038331@WT501@B@[email protected]@1560000.00@09:30:55@O@
[email protected]@[email protected]@00171401@Z@N@000001000001@200801@0001@0001
11.4 Holding Data File
The name of a holding data file a sender (with the uniform identifier XXXX) transmits to a
fund management company or custodian bank (organization code certificate Y):
XXXXholddata+date_Y.txt
For example, the name of a holding data file which is transmitted on October 8, 2005 by a
futures company with the identifier of 0001 to a fund management company with the
organization code of710685288 is 0001holddata20051008_710685288.txt.
A sender each day needs to transmit to a fund management company or custodian bank a
holding data file with the corresponding name. For the field and data type of each entry, see
Table 43:
Table 43 Holding Data File
Field
Data type
Blank or not
Date
date
N
Internal ClientID
char(18)
N
Contract Variety
char(6)
N
Trade Flag
char
N
HedgeFlag
char
N
HoldPosition
number(10)
N
Margin
number(14,2)
N
(based on mark to number(14,2)
N
PositionProfit
market)
104
Comments
Format: yyyy-mm-dd
Speculation-S. Hedge-H.
Arbitrage-A.
Unit: lot
JR/T 0087—2012
Field
Data type
Blank or not
PositionProfit
Comments
Position profit or loss based on the
(based on
transaction-by-transaction
transaction-by-tra number(14,2)
Y
offsetting approach
nsaction
offsetting)
PositionPrice
Yesterday
Settlement Price
Today Settlement
Price
Account
number(14,2)
N
number(14,2)
N
number(14,2)
N
char(10)
N
Trading code of an exchange to
which the trade corresponds
Dalian Commodity Exchange-D.
Zhengzhou
Uniform Identifier
char
of Exchange
N
Commodity
Exchange-Z.
Shanghai
Exchange-S.
China
Futures
Financial
Futures Exchange -J.
Non-settlement
char
member or not
N
Uniform Identifier
of Settlement
None
Encoding method of China Futures
char(10)
N
Margin Monitoring Center
Member
Uniform Identifier
of Exchange
Encoding method of China Futures
char(10)
N
Margin Monitoring Center
Member
For example:
2005-01-25@000008@WT502@B@S@[email protected]@[email protected]@11200.00@1200
[email protected]@00171401@Z@N@0001@0001
2005-01-25@000009@WT505@S@H@[email protected]@[email protected]@10200.00@1
[email protected]@00579246@Z@N@0001@0001
11.5 Liquid Details File
105
JR/T 0087—2012
The name of a liquid details file a sender (with the uniform identifier XXXX) transmits to a
fund management company or custodian bank (organization code certificate Y):
XXXXliquiddetails +date_Y.txt
For example, the name of a liquid details file which is transmitted on October 8, 2005 by a
futures company with the identifier of 0001 to a fund management company with the
organization code of710685288 is 0001holddata20051008_710685288.txt.
A sender each day needs to transmit to a fund management company or custodian bank a liquid
details file with the corresponding name. For the field and data type of each entry, see Table 44:
Table 44 Liquid Details File
Field
Data type
Blank or not
Date
date
N
Internal ClientID
char(18)
N
Contract Variety
char(6)
N
Deal Serial Number
char(8)
N
Trade Flag
char
N
Trading Price
number(14,2)
N
OpenPrice
n
N
Trading Volume
number(10)
N
Yesterday Settlement Price
number(14,2)
N
Today Settlement Price
number(14,2)
N
number(14,2)
N
CloseProfit (based on
mark to market)
offsetting)
106
Format: yyyy-mm-dd
Deal serial number issued by
an exchange
Buy-B. Sell-S
Trading price when closing a
position
Trading price when opening a
position
Number of positions closed.
Unit: lot
Profit
CloseProfit (based on
transaction-by-transaction
Comments
number(14,2)
Y
or
positions
loss
based
on
closed
on
transaction-by-transaction
offsetting approach
the
JR/T 0087—2012
Field
Original Deal Serial
Number
Account
Uniform Identifier of
Settlement Member
Uniform Identifier of
Exchange Member
Data type
Blank or not
Comments
Deal serial number issued by
char(8)
Y
an exchange when a client
opened a position.
char(10)
N
Encoding method of China
char(10)
N
Futures Margin Monitoring
Center
Encoding method of China
char(10)
N
Futures Margin Monitoring
Center
For example:
2005-01-26@2565@m0505@00013914@[email protected]@2147.00@[email protected]@2145.00@60.
[email protected]@00002140@20000003@0001@0001
11.6 Holding Details File
The name of a holding details file a sender (with the uniform identifier XXXX) transmits to a
fund management company or custodian bank (organization code certificate Y):
XXXXholddetails+date_Y.txt
For example, the name of a holding details file which is transmitted on October 8, 2005 by a
futures company with the identifier of 0001 to a fund management company with the
organization code of710685288 is 0001holddetails20051008_710685288.txt.
A sender each day needs to transmit to a fund management company or custodian bank a
holding details file with the corresponding name. For the field and data type of each entry, see
Table 45:
107
JR/T 0087—2012
Table 45 Holding Details File
Field
Data type
Blank or not
Date
date
N
Internal ClientID
char(18)
N
Contract Variety
char(6)
N
Deal Serial Number
char(8)
N
Trade Flag
char
N
HedgeFlag
char
N
HoldPosition
number(10)
N
OpenPrice
number(14,2)
N
Yesterday Settlement Price
number(14,2)
N
Today Settlement Price
number(14,2)
N
number(14,2)
N
PositionProfit (based on
mark to market)
PositionProfit (based on
transaction-by-transaction
Uniform Identifier of
Settlement Member
Uniform Identifier of
Exchange Member
108
Format: yyyy-mm-dd
Deal serial number issued by
an exchange
Buy-B. Sell-S
Speculation-S.
Hedge-H.
Arbitrage-A.
Unit: lot
Position profit or loss based on
number(14,2)
Y
offsetting)
Account
Comments
the transaction-by-transaction
offsetting approach
char(10)
N
Trading code of an exchange
to which the trade corresponds
Encoding method of China
char(10)
N
Futures Margin Monitoring
Center
Encoding method of China
char(10)
N
Futures Margin Monitoring
Center
JR/T 0087—2012
For example:
2005-01-26@2565@m0505@00005968@B@S@[email protected]@[email protected]@50.00@-1
50.00 @00171401@0001@0001
11.7 Delivering Details File
The name of a delivering details file a sender (with the uniform identifier XXXX) transmits to a
fund management company or custodian bank (organization code certificate Y):
XXXXdelivdetails+date_Y.txt
For example, the name of a delivering details file which is transmitted on October 8, 2005 by a
futures company with the identifier of 0001 to a fund management company with the
organization code of710685288 is 0001delivdetails20051008_710685288.txt.
A sender each day needs to transmit to a fund management company or custodian bank a
delivering details file with the corresponding name. For the field and data type of each entry,
see Table 46:
Table 46 Delivering Details File
Field
Data type
Blank or not
Date
date
N
Internal ClientID
char(18)
N
Contract Variety
char(6)
N
Trade Flag
char
N
Comments
Date
of
number(14,2)
N
Format:
yyyy-mm-dd
Number of contract to be
delivered
Buy-B. Sell-S
Average
AvgPx
delivery.
trading
price
by
client, variety and trade when
opening a position
Trading Turnover
number(14,2)
N
Final Settlement Price
number(14,2)
N
Delivery Payment
number(14,2)
N
number(10)
N
number(14,2)
N
Number of Lots
Delivered
SettleFee
Total turnover
Unit: lot
109
JR/T 0087—2012
Field
Data type
Blank or not
number(14,2)
N
char(10)
N
Comments
Profit or Loss from
Delivery and
Matching
Account
Uniform Identifier of
Settlement Member
Uniform Identifier of
Exchange Member
Encoding method of China
char(10)
N
Futures Margin Monitoring
Center
Encoding method of China
char(10)
N
Futures Margin Monitoring
Center
For example:
2006-04-19@00100008@cu0604@[email protected]@[email protected]@781000.00@2@10
[email protected]@20000003@0001@0001
110
JR/T 0087—2012
Schedule A
(Informative Schedule)
FIX Session Gap Fill Options
In the middle of a FIX session, after detecting the missing of a message (or discovering a
message gap), the acceptor has the following options to deal with the gap: 1. after discovering
the missing of a message, the acceptor may request for the transmission of the missed
message and all messages subsequent to such message from the initiator, see Graph A.1; and
2. the acceptor may, after detecting the missing of a message, maintain a list of all messages
received and request for the missed message from the initiator, see Graph A.2:
System of Fund
Management
Company
System of Futures
Company
Message 1
Message 1
Message 2
Message 2
Message 3
Missed message 3
Detected the gap
Message 4
Message 5
Message 4
Ignored
Message 5
Ignored
Resend request (from message 3)
Received a resend
request
Message 3
Message 3
Message 4
Message 4
Message 5
Message 5
Graph A.1 Gap Fill Option 1
111
JR/T 0087—2012
System of Fund
Management
Company
System of Futures
Company
Message 1
Message 1
Message 2
Message 2
Message 3
Missed message 3
Detected the gap
Message 4
Message 4
Message 5
Maintained
Missed message 5
Resend request (from Message 3)
Received a
resend request
Message 3
Message 3
Message 6
Message 4
Detected the gap
Received a
resend request
Resend request (from Message 5)
Graph A.2 Gap Fill Option 2
112
Message 6
Maintained
JR/T 0087—2012
Schedule B
(Informative Schedule)
FIX Session Connection Scenarios
B.1 Logon for FIX Session
Graph B.1shows a scenario for connection logon in which the initiator sends a logon message
to the acceptor. As the first message is invalid, the acceptor rejects the logon request by
sending a logout message. The second message is a valid one and the acceptor responds with
a confirming logon message.
System of Fund
Management Company
System of Futures
Company
TCP/IP connection
Established connection
Sent logon message 1
Invalid logon message
Sent logout message1
Received logout
message 1
Text=invalid logon
Received logon message 2
Sent logon message 2
HeartBtInt=XXX
ResetSeqNumFlag=N
Receive logon message 2
Sent logon message 2
Graph B.1 Logon
113
JR/T 0087—2012
B.2 Logout
Graph B.2 shows a scenario for logout session in which, before actually closing the session,
the logout imitator waits for the acceptor to respond with a confirming logout message.
System of Fund
Management Company
System of Futures
Company
Sent a logout message 100
Received a logout
message 100
Received a logout
message 200
Sent a logout message 200
Shut down the connection
Shut down the connection
Graph B.2 Logout
B.3 Resend
Graph B.3shows a scenario for the resending of message in the case of termination of the
session. Under the scenario, the TCP/IP link is unexpectedly disconnected at any time after
the initiator sends some application messages to the acceptor. Thereafter, the initiator does not
detect the telecommunication failure until sending message number 104 and waits for
reestablishing the communication link. After the communication link is reestablished, the
initiator sends logon message number 105 to reestablish the connection. After the connection
is made, the acceptor sends a resend request message to the initiator, asking for the
retransmission of message number 103 and messages subsequent to it. The initiator responds
to such request and uses a sequence reset message to mark the place of message number 105.
114
JR/T 0087—2012
System of Fund
Management Company
System of Futures
Company
Sent message 100
Received message 100
Sent message 101
Received message 101
Sent message 102
Received message 102
Sent logon message 105
Received logon message 105
HeartBtInt=XXX
ResetSeqNumFlag
Received logon message 30
Received logon message 30
Sent resend request 31
BeginSeqNo=103
Received resend request 31
EndSeqNo=0
Sent message 103
Received message 103
Sent message 104
Received message 104
Received Sequence
Sent Sequence Reset-Gap
Fill 105
Reset-Gap Fill105
MsgType=4
GapFillFlag=Y
NewSeqNo=106
Graph B.3 Resend
B.4 Resend Request
Graph B.4shows a resend scenario in which the resend message contains a session message.
Under the scenario, after sending some application and heartbeat messages to the acceptor, the
initiator receives a resend request number 30(the sequence number of a message the acceptor
currently sends). Consequently, the initiator resends the application messages to the acceptor
and the heartbeat messages are marked or skipped by a sequence reset message, maintaining
115
JR/T 0087—2012
the consistency and continuity of the message sequence numbers. Generally, the initiator
should keep a certain range of messages to fill gaps and these messages include application
and session messages, i.e. all messages which have been sent.
System of Fund
Management Company
System of Futures
Company
Sent message 100
Received message 100
Sent message 101
Received message 101
Sent heartbeat message 102
Received heartbeat message
102
Sent heartbeat message103
Received heartbeat message
103
Sent message 104
Received message 104
Sent resend request 30
BeginSeqNo=100
Received resend request 30
EndSeqNo=0
Sent message 100
Received message 100
Sent message 101
Received message 101
Sent Sequence Reset-Gap
Received Sequence
Fill 102
Reset-Gap Fill 102
Msg Type =4
Gap Fill Flag =Y
NewSeqNo=104
Received message 104
Sent message 104
Graph B.4 Resend Request
116
JR/T 0087—2012
B.5 Heartbeat and Test Request
Graph B.5shows a scenario for heartbeat and test request where during the period of message
inactivity, the two sides involved in the connection may send heartbeat or test request at
specified time intervals in accordance with the applicable rules.
System of Fund
Management Company
System of Futures
Company
Sent heartbeat message 100
Received heartbeat message
100
Sent test request 101
Received test request 101
TestReqID=101
Received heartbeat message
30
Sent heartbeat message 30
Received heartbeat message
31
Sent heartbeat message 31
TestReqID=101
Sent test request 32
Received test request 32
TestReqID=32
Sent heartbeat message 102
Received heartbeat message
102
TestReqID=32
Graph B.5 Heartbeat and Test Request
117
JR/T 0087—2012
Schedule C
(Informative Schedule)
Application Scenario
C.1 New Order-Single Scenario Graph
See Graph C.1 for New Order-Single Scenario.
System of Futures
Company
System of Fund
Management Company
ClOrdID=1896
(Identifier of client order
assigned by the fund
management company)
CiOrdID=1896
OrderID=4569
(Identifier for order assigned
by the futures company)
ExecID=1357
(Identifier of execution)
ClOrdID=1896
OrderID=4569
ExecID=1400
DeclarationID=1799
(Identifier of declaration
assigned by the exchange)
ClOrdID=1896
OrderID=4569
ExecID=1403
DeclarationID=1799
TradeID=33522
(Identifier of trade assigned
by the exchange)
LastShares=400
LeavesQty=600
ClOrdID=1896
OrderID=4569
ExceID=1420
DeclarationID=1799
TradeID=33533
LastShares=600
LeavesQty=0
ClOrdID=1896
New Order-Single
Execution Report-Pending New
Execution Report-New
Execution Report-Partially Filled
Execution Report-Filled
Graph C.1 New Order-Single Scenario
118
(Identifier of client order
assigned by the fund
management company to
the client order)
ClOrdID=1896
OrderID=4569
(Identifier for order assigned
by the futures company)
ExecID=1357
(Identifier of execution)
ClOrdID=1896
OrderID=4569
ExecID=1400
DeclarationID=1799
(Identifier of declaration
assigned by the exchange)
ClOrdID=1896
OrderID=4569
ExecID=1403
DeclarationID=1799
TradeID=33533
(Identifier of trade assigned
by the exchange)
LastShares=400
LeavesQty=600
CoOrdID=1896
OrderID=4569
ExecID=1420
DeclarationID=1799
TradeID=33533
LastShares=600
LeavesQty=0
JR/T 0087—2012
C.2 Order Cancel Scenario Graph
See Graph C.2 for Order Cancel Scenario.
System of Fund
Management Company
System of Futures
Company
ClOrdID=1896
(Identifier of client order
assigned by the fund
management company)
CiOrdID=1896
OrderID=4569
(Identifier for order
assigned by the futures
company)
ExecID=1357
(Identifier of execution)
ClOrdID=1896
OrderID=4569
ExecID=1400
DeclarationID=1799
(Identifier of declaration
assigned the exchange)
ClOrdID=1896
OrderID=4569
ExecID=1403
DeclarationID=1799
TradeID=33522
(Identifier of trade
assigned by the
exchange)LastShares=400
LeavesQty=600
ClOrdID=1896
New Order-Single
Execution Report-Pending New
Execution Report-New
Execution Report-Partially Filled
CiOrdID=1896
OrderID=4569
(Identifier for order
assigned by the futures
company)
ExecID=1357
(Identifier of execution)
ClOrdID=1896
OrderID=4569
ExecID=1400
DeclarationID=1799
(Identifier of declaration
assigned the exchange)
ClOrdID=1896
OrderID=4569
ExecID=1403
DeclarationID=1799
TradeID=33522
(Identifier of trade
assigned by the exchange)
LastShares=400
LeavesQty=600
ClOrdID=1900
ClOrdID=1900
OrigClOrdID=1896
(Identifier of client order
assigned by fund
management company)
Order Cancel Request
OrigClOrdID=1896
(Order in Pending Cancel
status)
(Order in Pending Cancel
status)
ClOrdID=1900
ClOrdID=1900
OrigClOrdID=1896
Execution Report-Pending Cancel
OrigClOrdID=1896
OrderID=4569
OrderID=4569
ExceID=1420
ExceID=1420
ClOrdID=1900
ClOrdID=1900
OrigClOrdID=1896
OrigClOrdID=1896
OrderID=4569
Execution Report-Canceled
OrderID=4569
ExecID=1425
ExecID=1425
LeavesQty=0
LeavesQty=0
Graph C.2 Order Cancel Scenario
119
JR/T 0087—2012
Schedule D
(Informative Schedule)
Checksum Calculation
A code segment to calculate the checksum is as follows:
char *GenerateCheckSum( char *buf, long bufLen )
{
static char tmpBuf[ 4 ];
long idx;
unsigned int cks;
for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );
sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) );
return( tmpBuf );
}
120
JR/T 0087—2012
Schedule E
(Informative Schedule)
FIX Session
E.1 FIX Session
E.1.1 Sequence Numbers
All messages are identified by a unique sequence number. Sequence numbers are initialized at
the start of each FIX session starting at 1 (one) and increment throughout the session until the
termination of the session. Monitoring sequence numbers will enable parties to identify and
react to missed messages and to synchronize applications when reconnecting during a FIX
session.
Each session will establish an independent incoming and outgoing sequence series.
Participants will maintain a sequence series to assign to outgoing messages and a separate
series to monitor for sequence gaps on incoming messages.
E.1.2 Heartbeats
During periods of message inactivity, the two sides involved in the connection will generate
Heartbeat messages at regular time intervals. The heartbeat monitors the status of the
communication link. The Heartbeat Interval is declared by the session initiator using the
HeartBtInt field in the Logon message. The heartbeat interval timer should be reset after every
message is transmitted. The HeartBtInt value should be agreed upon by the two sides involved
in the connection and specified by the Logon initiator and echoed back by the Logon acceptor.
The same HeartBtInt value is used by both sides.
E.1.3 Gap Fill
AS FIX session protocol is based on an optimistic message transmission model, it is possible
to miss a message in the course of transmission. Considering that the initiator is unable to
detect the missed message, it is the responsibility of the acceptor to detect and deal with any
message gap. There are two options to address this issue: after detecting the missing of any
message, the acceptor requests for the missed message and all messages subsequent to the
missed message from the initiator; and, after detecting any gap, the acceptor maintains a list
of al messages received and asks for the resending of the missed message by the initiator.
E.1.4 Possible Duplicates
When a message is retransmitted in response to a resend request or when a message is
retransmitted if it is unsure whether the message has been successfully received at its intended
destination, the PossDupFlag (Possible Duplicate=Y) is required to be included in the
121
JR/T 0087—2012
message. It is the receiving application's responsibility to handle the message. Even if the
original sequence number is used when a message with the PossDupFlag field is generated,
considering that some fields are likely to change, such as OrigSendingTime, SendingTime,
BodyLength and PossDupFlag, it is necessary to recalculate the CheckSum value.
E.1.5 Possible Resends
Ambiguous application level messages may be resent with the PossResend flag set (Possible
Resend=Y) and new sequence numbers. This is useful when an order remains
unacknowledged for an inordinate length of time and it is suspected that the order had never
been sent. The receiving application must recognize this flag and interrogate internal fields
(order number, etc.) to determine if this order has been previously received. The possible
resend message will contain exactly the same body data. Likewise, as some fields are likely to
change, it is necessary to recalculate the CheckSum value.
E.1.6 Message Acknowledgment
As the FIX session protocol is based on an optimistic message transmission model and
message gaps are identified by monitoring message sequence numbers, the FIX protocol does
not support individual message acknowledgment. However, the acknowledgement of a large
number of messages can be defined at the application level. It is permissible to accept or
reject these messages at the application level, such as acknowledgement of order.
E.2 Connection
A FIX session is defined as a bi-directional stream of ordered messages between two parties
within a continuous sequence number series. Parties can connect and disconnect multiple
times while maintaining a single FIX session. Disconnection can be caused by external
factors. Connecting parties can bi-laterally agree as to when sessions are to be started/stopped
based upon individual system. Generally, a new FIX session is established once within each
24 hour period. If it is necessary to maintain 24 hour connectivity, it is required to establish a
new set of sequence numbers by sending a Logon message with the ResetSeqNumFlag set.
A FIX session is comprised of three parts: logon, message exchange and logout.
E.2.1 Logon
Establishing a FIX connection involves three distinct operations: creation of a
telecommunications level link, authentication/acceptance of the initiator by the acceptor and
message synchronization (initialization). The sequence of connection is as follows：
E.2.1.1 Link
The session initiator establishes a telecommunication link with the session acceptor.
122
JR/T 0087—2012
E.2.1.2 Authentication
The initiator sends a Logon message. The acceptor will authenticate the identity of the
initiator by examining the Logon message. The Logon message should contain the necessary
data such as user name and password. If the initiator is successfully authenticated, the
acceptor responds with a Logon message. If authentication fails, the session acceptor should
shut down the connection after optionally sending a Logout message to indicate the reason of
failure. Sending a Logout in this case is not required because doing so in some cases may be
problematic. The initiator must wait for the confirming Logon message from the acceptor
before declaring the session fully established. The session initiator may begin to send other
messages immediately following the Logon message.
It is recommended to wait a short period of time following the Logon or to send a Test
Request and wait for a response to it before sending new messages in order to allow both
sides to handle resend request processing. Failure to do this could result in a Resend Request
message being issued by one’s counterparty for each new message sent.
E.2.1.3 Initialization
After authentication, the initiator and acceptor should synchronize their messages sequence
numbers before sending any new messages. The message sequence numbers are synchronized
through interrogation of the MsgSeqNum field. A comparison of the MsgSeqNum in the
Logon message to the internally monitored next expected sequence number will indicate any
message gaps. Likewise, the initiator can detect gaps by comparing the acknowledgment
Logon message MsgSeqNum to the next expected value.
E.2.2 Message Exchange
After completion of the initialization process, normal message exchange begins. The formats
for all valid messages are detailed in the sections 'Session Messages' and 'Application
Messages'.
E.2.3 Logout
Normal termination of the message exchange session will be completed via the exchange of
Logout messages. Session termination without receiving a Logout should treat the
counterparty as logged out. Termination by other means should be considered an abnormal
condition and dealt with as an error.
It is recommended that before sending the Logout message, a TestRequest should be issued to
force a Heartbeat from the other side. This helps to ensure that there are no sequence number
gaps.
Before actually closing the session, the Logout initiator should wait for the opposite side to
123
JR/T 0087—2012
respond with a confirming Logout message. This gives the acceptor a chance to perform any
Gap Fill operations. Once the messages from the ResendRequest have been received, the
acceptor should issue the Logout. The session may be terminated immediately if the acceptor
does not respond in an appropriate timeframe.
Note: Logging out does not affect the state of any orders. All active orders will continue to be
eligible for execution after logout.
E.2.4 Message Recovery
The following section provides details on how to recover messages.
Each FIX participant must maintain two sequence numbers for each FIX session, one each for
incoming and outgoing messages.
When the incoming sequence number does not match the expected number, corrective
processing is required. Note that the SeqReset-Reset messageis an exception to this rule as it
should be processed without regards to its MsgSeqNum. If the incoming message has a
sequence number less than expected and the PossDupFlag is not set, it indicates a serious
error. It is strongly recommended that the session be terminated and manual intervention be
initiated. If the incoming sequence number is greater than expected, it indicates that messages
were missed and retransmission of the messages should be requested via the Resend Request.
Upon receipt of a Resend Request, the resender can respond in one of three ways：(note①)
a)
As a normal response, the resender transmits the requested messages in order
with the original sequence numbers and PossDupFlag set to “Y”.
b)
As a normal response, the resender issues a SeqReset-GapFill with
PossDupFlag set to “Y” to indicate the deletion of old or redundant message.
c)
As an abnormal response, the resender issues a SeqReset-Reset with
PossDupFlag set to “Y” to force sequence number synchronization.
During the gap fill process, certain session messages are not required to be retransmitted.
Instead, a special SeqReset-GapFill message is generated. The session messages which are
not to be resent are: Logon, Logout, ResendRequest, Heartbeat, TestRequest and
SeqReset-Reset and SeqReset-GapFill. This leaves Reject as the only session message which
can be resent.
All FIX implementations must monitor incoming messages to detect inadvertently
retransmitted session messages (PossDupFlag flag set indicating a resend). When received,
these messages should be processed for sequence number integrity only; the
Note①：In this section, requester refers to the party requesting the resend and resender refers to the party responding to the
request.
124
JR/T 0087—2012
business/application processing of these messages should be skipped.
If there are consecutive session messages to be resent, it is suggested that only one
SeqReset-GapFill message be sent in their place. The sequence number of the
SeqReset-GapFill message is the next expected outbound sequence number. The NewSeqNo
field of the GapFill message contains the sequence number of the highest session message in
this group plus 1. (Note②)
An engine should store out of sequence messages in a temporary queue and process them in
order when the gap is closed. This prevents generating resend requests for n->m, n->m+1,
n->m+2, ... which can result in many resent PossDupFlag=Y messages.
Sequence number checking is a vital part of FIX session management. However, a
discrepancy in the sequence number stream is handled differently for certain classes of FIX
messages. The following Table E.1 lists the actions to be taken when the incoming sequence
number is greater than the expected incoming sequence number.
(Note③)
Note②:For example, during a Resend operation there are 7 sequential administrative messages waiting to be resent.
They start with sequence number 9 and end with sequence number 15. Instead of transmitting 7 Gap Fill messages
(which is perfectly legal, but not network friendly), a SeqReset-GapFill message may be sent. The sequence
number of the Gap Fill message is set to 9 because the remote side is expecting that as the next next sequence
number. The NewSeqNo field of the GapFill message contains the number 16, because that will be the sequence
number of the next message to be transmitted.
Note③:In all cases except the Sequence Reset - Reset message, the FIX session should be terminated immediately
if the incoming sequence number is less than expected and the PossDupFlag is not set. A Logout message with
some descriptive text should be sent to the other side before closing the session.
125
JR/T 0087—2012
Table E.1 Sequence Number Error Handling
Message Type
Action to Be Taken against Sequence Number
Error
Logon
Must always be the first message transmitted.
Authenticate and accept the connection. After
sending a Logon confirmation back, send a
ResendRequest if a message gap was detected in the
Logon sequence number.
Logout
If a message gap was detected, issue a
ResendRequest to retrieve all missing messages
followed by a Logout message which serves as a
confirmation of the logout request. DO NOT
terminate the session. The initiator of the Logout
sequence has responsibility to terminate the session.
This allows the Logout initiator to respond to any
ResendRequest message.
ResendRequest
Perform the Resend processing first, followed by a
ResendRequest of your own in order to fill the
incoming message gap.
SeqReset-Reset
Ignore the incoming sequence number. The
NewSeqNo field of the SeqReset message will
contain the sequence number of the next message to
be transmitted.
SeqReset-GapFill
Send a ResendRequest back immediately. However,
it is important to insure that no messages have been
inadvertently skipped over. This means that GapFill
messages must be received in sequence. An out of
sequence GapFill is an abnormal condition.
All Other Messages
Perform normal Gap Fill operations.
E.3 FIX Session Messages
The FIX session messages address the utility needs of the protocol. The following sections
describe each message and provide the message layout.
Session messages will be generated from both sides of the connection.
E.3.1 Heartbeat (MsgType=0)
The Heartbeat monitors the status of the communication link and identifies when the last of a
string of messages was not received.
When either end of a FIX connection has not sent any data for [HeartBtInt] (Heartbeat
interval) seconds, it will generate and transmit a Heartbeat message. When either end of the
connection has not received any data for (HeartBtInt + “some reasonable transmission time”)
126
JR/T 0087—2012
seconds, it will generate and transmit a Test Request message. If there is still no Heartbeat
message received after (HeartBtInt + “some reasonable transmission time”) seconds then the
connection should be considered lost and corrective action be initiated. If HeartBtInt is set to
zero then no regular heartbeat messages will be generated. A test request message can still be
sent independent of the value of the HeartBtInt, which will force a Heartbeat message.
Heartbeats issued as the result of Test Request must contain the TestReqID transmitted in the
Test Request message. This is useful to verify that the Heartbeat is the result of the Test
Request and not as the result of a regular timeout.
The following Table E2 describes the heartbeat format:
Table E.2 Heartbeat
Tag
112
Field Name
Required
Comments
Standard Header
Y
MsgType = 0
TestReqID
N
Identifier of test request. Required when the
heartbeat is the result of a Test Request message
Standard Trailer
Y
E.3.2 Logon (MsgType=A)
The logon message authenticates a user establishing a connection to a remote system. The
logon message must be the first message sent by the application requesting to initiate a FIX
session.
The HeartBtInt field is used to declare the timeout interval for generating heartbeats (same
value used by both sides). The HeartBtInt value should be agreed upon by the two sides and
specified by the Logon initiator and echoed back by the Logon acceptor.
Upon receipt of a Logon message, the session acceptor will authenticate the party requesting
connection and issue a Logon message as acknowledgment that the connection request has
been accepted. The acknowledgment Logon can also be used by the initiator to validate that
the connection was established with the correct party.
The session acceptor should be prepared to immediately begin processing messages after
receipt of the Logon. The session initiator can choose to begin transmission of FIX messages
before receipt of the confirmation Logon. However, this protocol provides that normal
message delivery wait until after the return Logon is received to accommodate encryption key
negotiation.
The confirmation Logon can be used for encryption key negotiation. If a session key is
deemed to be weak, a stronger session key can be suggested by returning a Logon message
with a new key. This is only valid for encryption protocols that allow for key negotiation.
The Logon message can be used to specify the MaxMessageSize supported. It can also be
127
JR/T 0087—2012
used to specify the MsgTypes supported for both sending and receiving.
The following Table E3 describes the logon format:
Table E.3 Logon
Tag
Field Name
Required
Comments
Standard Header
Y
MsgType = A
98
EncryptMethod
Y
Method of encryption (Always unencrypted)
108
HeartBtInt
Y
Heartbeat interval
95
RawDataLength
N
Length of unformatted raw data. Required for
authentication purpose
96
RawData
N
Unformatted raw data.
authentication purpose
141
ResetSeqNumFlag
N
Sequence number reset flag
383
MaxMessageSize
N
Maximum length of message. Maximum
number of bytes in a single message
384
NoMsgTypes
N
Number of message types

372
RefMsgType
N
Type of message

385
MsgDirection
N
Direction of message
Standard Trailer
Required
for
Y
E.3.3 Test Request (MsgType=1)
The test request message forces a heartbeat from the opposing application. The test request
message checks sequence numbers or verifies communication line status. The opposite
application responds to the Test Request with a Heartbeat containing the TestReqID.
The TestReqID verifies that the opposite application is generating the heartbeat as the result
of Test Request and not a normal timeout. The opposite application includes the TestReqID in
the resulting Heartbeat. Any string can be used as the TestReqID (one suggestion is to use a
timestamp string).
The following Table E4 describes the test request format:
Table E.4 Test Request
Tag
112
Field Name
Required
Comments
Standard Header
Y
MsgType = 1
TestReqID
Y
Identifier of test request
Standard Trailer
Y
E.3.4 Resend Request (MsgType=2)
The resend request is sent by the receiving application to initiate the retransmission of
messages. This function is utilized if a sequence number gap is detected, if the receiving
application lost a message, or as a function of the initialization process.
128
JR/T 0087—2012
The resend request can be used to request a single message, a range of messages or all
messages subsequent to a particular message.
The sending application may wish to consider the message type when resending messages;
e.g. if a session message is in the resend series and becomes invalid as a result of the elapse of
a significant time period since its original inception, the sender may not wish to retransmit the
message. The Sequence Reset-GapFill message is used to skip messages that a sender does
not wish to resend. (Note④)
The resend request can be used to:
a)
request a single message: BeginSeqNo = EndSeqNo;
b)
request a range of messages: BeginSeqNo = first message of range, EndSeqNo =
last message of range; or
c)
request all messages subsequent to a particular message: BeginSeqNo = first
message of range, EndSeqNo = 0 (represents infinity).
The following Table E5 describes the resend request format:
Table E.5 Resend Request
Tag
Field Name
Required
Comments
Standard Header
Y
MsgType = 2
7
BeginSeqNo
Y
Sequence number of first message
16
EndSeqNo
Y
Sequence number of last message
Standard Trailer
Y
E.3.5 Reject (session-level) (MsgType=3)
The reject message should be issued when a message is received but cannot be properly
processed due to a session-level rule violation. An example of when a reject may be
appropriate would be the receipt of a message with invalid basic data (e.g. MsgType=&)
which successfully passes de-encryption, CheckSum and BodyLength checks.
Rejected messages should be logged.
The receiving application should disregard any message that is garbled, cannot be parsed or
fails a data integrity check. Processing of the next valid FIX message will cause detection of a
sequence gap and a Resend Request will be generated. Logic should be included in the FIX
Note④: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and
8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This
latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery when both
sides are simultaneously attempting to recover a gap.
129
JR/T 0087—2012
engine to recognize the possible infinite resend loop, which may be encountered in this
situation.
Generation and receipt of a Reject message indicates a serious error that may be the result of
faulty logic in either the sending or receiving application.
If the sending application chooses to retransmit the rejected message, it should be assigned a
new sequence number and sent with PossResend=Y.
Whenever possible, this protocol provides that the cause of the failure be described in the Text
field.
If an application-level message received fulfills session-level rules, it should then be
processed at a business message-level. If this processing detects a rule violation, a
business-level reject should be issued. Many business-level messages have specific “reject”
messages, which should be used. All others can be rejected at a business-level via the
Business Message Reject message.
The following Table E6 describes the reject format:
Table E.6 Reject
Tag
Field Name
Required
Comments
Standard Header
Y
MsgType = 3
45
RefSeqNum
Y
Sequence number of the message being
referenced, i.e. sequence number of the rejected
message
371
RefTagID
N
Tag number of the FIX field being referenced.
372
RefMsgType
N
MsgType of the FIX message being referenced
373
SessionRejectReason
N
Code to identify reason for a session-level
Reject message
58
Text
N
Text. Message to explain reason for rejection
354
EncodedTextLen
N
Length of encoded text
355
EncodedText
N
Encoded text (non-ASCII characters)
Standard Trailer
Y
The following Table 7 lists the reasons for session-level Reject:
130
JR/T 0087—2012
Table E.7
Session Reject Reason (English)
Session Reject Reason
0 = Invalid tag number
1 = Required tag missing
2 = Tag not defined for this message type
3 = Undefined Tag
4 = Tag specified without a value
5 = Value is incorrect (out of range) for this tag
6 = Incorrect data format for value
7 = Decryption problem
8 = Signature problem
9 = CompID problem
10 = SendingTime accuracy problem
11 = Invalid MsgType
12 =XML Validation error
13 = Repeating within a tag(not a repeating group)
14 = Error in the sequence of fields with a sequence number
15 = Error in the sequence of repeating group fields
16 = Error in the number of repetition for the repeating group
17 = Appearance of the field delimiter <SOH> in a data field
other than that of data
E.3.6 Sequence Reset (MsgType=4)
The sequence reset message is used by the sending application to reset the incoming sequence
number on the opposing side. This message has two modes: “Sequence Reset-Gap Fill” and
“Sequence Reset-Reset”. The “Sequence Reset-Reset” mode is usually used to recover from a
disaster situation.
When using the ResetSeqNumFlag to maintain 24 hour connectivity and establish a new set
of sequence numbers, both sides should agree upon a reset time and the party that will be the
initiator of the process, but the initiator of the ResetSeqNum process may be different than the
initiator of the Logon process. The process should be as follows: One side will initiate the
process by sending a TestRequest and wait for a Heartbeat in response to ensure of no
sequence number gaps. Once the Heartbeat has been received, the initiator should send a
Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The acceptor should
respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. At this
131
JR/T 0087—2012
point new messages from either side should continue with MsgSeqNum of 2. It should be
noted that once the initiator sends the Logon with the ResetSeqNumFlag set, the acceptor
should obey this request and the message with the last sequence number transmitted
“yesterday” may no longer be available. The connection should be shut down and manual
intervention taken, if this process is initiated but not followed properly.
The sequence reset message has two modes:
The message is SeqReset-Gap Fill when GapFillFlag =Y, and the message isequence
Reset-Reset when GapFillFlag＝N.
The sequence reset message can be used in the following situations:
a)
During normal resend processing, the sending application may choose not to send a
message (e.g. a session message). The Sequence Reset – Gap Fill can be used to
mark the place of that message.
b)
During normal resend processing, a number of session messages are not resent and
the Sequence Reset – Gap Fill message is used to fill the sequence gap created as a
result thereof.
c)
In the event of an application failure, it may be necessary to force synchronization of
sequence numbers on the sending and receiving sides via the use of Sequence Reset
– Reset.
The sequence reset message in all situations specifies NewSeqNo to reset as the value of the
sequence number of the next message to be transmitted.。
If the GapFillFlag field is set to Y), the MsgSeqNum should conform to message sequencing
rules, i.e. the MsgSeqNum of the Sequence Reset-GapFill message should represent the
beginning MsgSeqNum in the GapFill range because the remote side is expecting a message
with this MsgSeqNum .
The SeqReset-Gap Fill can only increase the sequence number. If the SeqReset-Gap Fill is
received attempting to decrease the next expected sequence number the message should be
rejected and treated as a serious error. (Note⑤)
Note⑤：It is possible to have multiple ResendRequests issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8,
10, and 11 represent application messages while the 5-7 and 9 represent session messages, the series of messages as result of the
Resend Request may appear as SeqReset-GapFill with NewSeqNo of 8, message 8 and SeqReset-GapFill with NewSeqNo of 10,
message 10. This could then be followed by SeqReset-GapFill with NewSeqNo of 8, message 8(with a lesser sequence number),
SeqReset-GapFill with NewSeqNo of 10, message 10, and message 11. One must be careful to ignore the duplicate
SeqReset-GapFill which is attempting to lower the next expected sequence number This can be detected by checking to see if its
MsgSeqNum is less than expected. If so, the SeqReset-GapFill is a duplicate and should be discarded.
132
JR/T 0087—2012
If the GapFillFlag field is not present (or set to N), the sequence reset message is
SeqReset-Reset. It is possible that the purpose of the SeqReset-Reset is to recover from an
out-of-sequence condition. The MsgSeqNum in the header should be ignored. Sequence Reset
– Reset should NOT be used as a normal response to a Resend Request (use Sequence Reset –
Gap Fill). The Sequence Reset – Reset should only be used to recover from a disaster
situation which cannot be recovered via the use of Sequence Reset – Gap Fill. Note that the
use of Sequence Reset -Reset may result in the possibility of lost messages.
The following Table E8 describes the sequence reset format:
Table E.8 Sequence Reset
Tag
Field Name
Required
Comments
Standard Header
Y
MsgType = 4
123
GapFillFlag
N
Gap fill flag
36
NewSeqNo
Y
New sequence number
Standard Trailer
Y
E.3.7 Logout (MsgType=5)
The logout message initiates or confirms the termination of a FIX session. Disconnection
without the exchange of logout messages should be interpreted as an abnormal condition.
Before actually closing the session, the logout initiator should wait for the opposite side to
respond with a confirming logout message. This gives the remote end a chance to perform any
Gap Fill operations that may be necessary. The session may be terminated if the remote side
does not respond in an appropriate timeframe.
After sending the Logout message, the logout initiator should not send any messages unless
requested to do so by the logout acceptor via a ResendRequest.
The following Table E9 describes the logout format:
Table E.9 Logout
Tag
Field Name
Required
Comments
Standard Header
Y
MsgType = 5
58
Text
N
Text
354
EncodedTextLen
N
Length of encoded text
355
EncodedText
N
Encoded text (non- ASCII characters)
Standard Trailer
Y
133