Data Exchange Protocol for Stock Index Futures between Funds and ...

blackstartNetworking and Communications

Oct 26, 2013 (3 years and 8 months ago)

130 views


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 Decembe
r 26, 2012

Effective on December
2
6, 2012

Issued by

t he Chi na Securi t ies Regul at ory Commi ssi on


JR/T 0087

2012


Table of Contents

Forward

................................
................................
................................
................................
.......................
III

I
ntroduction

................................
................................
................................
................................
................

IV

1.
Scope

................................
................................
................................
................................
.........................
1

2. Inclusion by References

................................
................................
................................
............................
1

3. Terms and De
finitions

................................
................................
................................
...............................
1

4. Methods of Communication

................................
................................
................................
......................
2

5. Message Format

................................
................................
................................
................................
........
2

6. Safet
y and Encryption

................................
................................
................................
...............................
6

7. Data Integrity

................................
................................
................................
................................
.............
7

8. Mode of Expansion

................................
................................
................................
................................
...
7

9. Defin
ition 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


III


Forward

Th
is

standard

(“Standa
rd”)

is drafted in accordance with the rules set out in GB/T1.1
-
2009.

The China Finance Standardization Technical Committee Securities Sub
-
Committee

has

propose
d

the
S
tandard.

The China Finance Standardization Technical Committee is responsible for the
adm
inistration

of the
S
tandard.

The
S
tandard 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., Bos
era Asset Management Company Limited, Dacheng
F
und
M
anagement
C
o., 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 Fush
i, 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, Den
g Tingxun, and Zhou Changshun
.


IV


Introduction

In the
S
tandard, 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 (
V
ersion 3.1) issued by the

China Futures Mar
gin Monitoring Center

Co., Ltd.

The
S
tandard will be revised in due course to keep pace with the development of the business and
technologies.


JR/T 0087

2012


1


Data Exchange Protocol for Stock Index Futures between Funds and Futures

1.
Scope

The
S
tandard provides for th
e 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 f
ile, 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
S
tandard is applicable to the exchange of transaction and settlement data between futu
res 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 app
lication 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
R
epresentation of
C
urrencies and
F
unds

GB/T 23696
-
2009 Securities and
R
elated
F
inan
cial
I
nstruments
-
E
xchange and
M
arket
I
dentifier
C
odes

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
R
eport

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
O
rder
s

I
dentity

The term “client orders identity” refers to an

identifier
of order
assigned by a client
, the

uniqueness

of
JR/T 0087

2012

2

which

must be guaranteed within a valid trading day.

3
.4
Order
I
dentity

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
I
dentity

The term “executive identity” refers to an

identifi
er

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 executi
ve

identity is “0”.

3.6
Declaration
I
dentity

The term “declaration identity” refers to a
n identifier

of declaration

assigned by an exchange

3.7
Trade
I
dentity

The term “trade identity” refers to a
n identifier

of trade

assign
ed by an exchange.

3.8
Client
I
dentity

The term “client identity” refers to a
capital account opened by a client with a futures company.

3.9
Account

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 message
s
, see Schedule E.

If the two parties involved in a transaction use the FIX session
-
level messaging as the method of
com
munication, 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
T
ype

Data type is used to define value type in the data field. This protocol consists of several fu
ndamental 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
I
nt

Int refers to the s
equence of digits wi
thout commas or decimals and optional

positive or negative

sign
JR/T 0087

2012


3


character (ASCII character
s


-
” 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 s
equence of digits with optional decimal po
int 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 decima
l 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 decima
l 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
C
har

Char refers to a
ny alphanumeric chara
cter 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

JR/T 0087

2012

4

String fields are case
-
sensitive

Exten
ded 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 repr
esents 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 i
s 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

O
riginal data not subject to limitation on format and contents and
consisting

of length field and data field.
Data included in t
he data field may contain numerical value 0x01 and the length field indicates the number
of characters contained in the data field.

5.2
Field

JR/T 0087

2012


5


5.2.1
Definition of Field

Field is a fundamental data element. Each field has its
tag number
, business definitio
n and defined
valid
value
s. 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 ty
pe. 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 me
ssage 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
D
efin
ed
F
ield

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
C
haracter
E
ncoding

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 i
s 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:


Ta
ble 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
tag=value

tag=value

tag=value

tag=value

JR/T 0087

2012

6

complying with the following rule
s:

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 (ta
g =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
G
roup

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
plac
ed 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 oute
r 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 trans
mitted 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 us
ed 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 exchan
ge 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 SecureDat
a 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.

JR/T 0087

2012


7


7.
Data Integrity

The integrity of message data content can be verified in two ways: verificat
ion 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 th
e 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
E
xpansion

Exp
ansion 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 fi
eld value.
T
he 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 ve
sted with the Securities Association of
China.

JR/T 0087

2012

8

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

H
eader

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 resendi
ng 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

8

BeginString

Y

First string
.

Valid values:FIX.4.2 (Always
unencrypt
ed, must be first field in
message)


9

BodyLength

Y

Message length (Always unencrypted,
must be second field in message)

35

MsgType

Y

Message type(Always unencrypted, must
be third field in message)

49

SenderCompID

Y

Identifier of message sender (Always

unencrypted, must be third field in
message)

56

TargetCompID

Y

Identifier of message receiver (Always
unencrypted)

JR/T 0087

2012


9


Tag

Field Name

Required

Comments

115

OnBehalfOfCompID

N

Identifier of message originator

(Can be
embedded within encrypted data section.)
.

Required if the message was deli
vered by a
third party

128

DeliverToCompID

N

Identifier of message recipient
(Can be
embedded within encrypted data section.)
.
Required if the message is delivered by a
third party

90

SecureDataLen

N

Length of encrypted data

91

SecureData

N

E
ncrypted da
ta (Always immediately
follows SecureDataLen field)

34

MsgSeqNum

Y

M
essage sequence number

(Can be
embedded within encrypted data section.).
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 ses
sion
mechanism.

50

SenderSubID

N

Identifier of specific message originator

(Can be embedded within encrypted data
section.)

142

SenderLocationID

N

Identifier of
specific message originator’s
location (Can be embedded within
encrypted data section)

57

T
argetSubID

N

Identifier of specific message receiver
(Can be embedded within encrypted data
section)

143

TargetLocationID

N

Identifier of

specific message destination’s
location (Can be embedded within
encrypted data section)

116

OnBehalfOfSubID

N

Identi
fier of specific message originator
(Can be embedded within encrypted data
section)

JR/T 0087

2012

10

Tag

Field Name

Required

Comments

144

OnBehalfOfLocationID

N

Identifier of
specific message originator’s
location (Can be embedded within
encrypted data section)

129

DeliverToSubID

N

Assigned value used t
o identify specific
message recipient if the message is
delivered by a third party (Can be
embedded within encrypted data section)

145

DeliverToLocationID

N

Identifier of specific message recipient's
location (Can be embedded within
encrypted data section
)

43

PossDupFlag

N

Possible duplicate flag
.

Indicates possible
retransmission of message
.

(Can be
embedded within encrypted data section)

97

PossResend

N

Possible resend flag. (Can be embedded
within encrypted data section)

52

SendingTime

Y

Time of tran
smission (Can be embedded
within encrypted data section)

122

OrigSendingTime

N

T
ime of
o
riginal transmission (Can be
embedded within encrypted data section)

347

MessageEncoding

N

Type of message encoding (non
-
ASCII
characters) used in a message’s “Encode
d”
fields

369

LastMsgSeqNumProcessed

N

The last MsgSeqNum value received and
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
:

JR/T 0087

2012


11


Table 2

Message Trailer

Tag

Field Nam
e

Required

Comments

93

SignatureLength

N

Length of electronic signature (Always
unencrypted)

89

Signature

N

Electronic signature(Always unencrypted)

10

CheckSum

Y

Checksum. Always last field in message (Always
unencrypted).

9.3
S
ession Messages

9.3.1
User
L
ogon
M
anagement
M
essages

9.3.1.1
Notes on
U
ser
L
ogon
M
anagement
M
essages

User log
o
n messages primarily include, among others, messages
which

support client logon and logout and
other client management

practices
. The two parties
involved
in a transa
ction 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 sessio
n
-
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

MsgType=UF001

8088

RequestID

Y

I
dentifier of user request. Its uniqueness must be
guarant
eed within a single trading day.

109

ClientID

Y

Capital account of client

98

EncryptMethod

Y

Method of encryption (Always unencrypted)

8001

LogonPasswd

Y

Transaction password

95

RawDataLength

N

Length
of
unformatted
raw data. Required for
authenticati
on
purpose

96

RawData

N

Unformatted raw data (
C
an be used to represent a
private key). Required for some authentication
methods

8096

MacNetInfo

N

Computer network information of client

8105

ClientSoftName

N

Name of client software

8106

ClientSoftVersi
on

N

Version of client software


Standard trailer

Y


JR/T 0087

2012

12

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 Lo
gon Response
:

Table 4 User Logon Response

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF002

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

109

ClientID

Y

Capital account of cli
ent

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 securi
ty

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

8032

LongonRejReason

N

Reason for rejecting logon request. Optionally
employed when UserRespType (
8031)=1
(representing rejection)

58

Text

N

Describes the reason for rejecting logon request.
Optionally employed when the
UserRespType(8031)=1(representing rejection)


Standard trailer

Y


9.3.1.4
User Logout Request (MsgType=UF00
3
)

It is the request of
a user to log out of the system of a future company a
fter the business time terminates.

JR/T 0087

2012


13


See Table 5 for the format of User Logout Request
:

Table 5 User Logout Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF00
3

8088

RequestID

Y

Iden
tifier of user request. Its uniqueness must be
guaranteed within a single trading day.

109

ClientID

Y

Capital account of client


Standard trailer

Y


9.3.1.5
User Logout Response (MsgType=UF00
4
)

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

MsgType=UF00
4

8088

RequestID

Y

Identifier of user request. It
s uniqueness must be
guaranteed within a single trading day.

109

ClientID

Y

Capital account of client

8002

LogonStatus

Y

Status of logon

8031

UserRespType

Y

Type of response to user

8033

LogoutRejReason

N

Reason for rejecting logout request. Optionally

employed when the
UserRespType(8031)=1(representing rejection)

58

Text

N

Describes the reason for rejecting logon request.
Optionally employed when the
UserRespType(8031)=1(representing rejection)


Standard trailer

Y



JR/T 0087

2012

14

9.3.1.6
User Change PassWd Reque
st (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

MsgType=UF005

8088

RequestID

Y

Identi
fier of user request. Its uniqueness must
be guaranteed within a single trading day.

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


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 Chang
e PassWd Response

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF006

8088

RequestID

Y

Identifier of user request. Its uniqueness must
be guaranteed within a single trading day.

109

ClientID

Y

Capital account of client

8031

UserRespType

Y

Type of response to user

8034

ChangePWRejReason

N

Reason for rejecting password change request.
Optionally employed when THE
UserRespType(8031)=1(
representing
rejection)

58

Text

N

Describes the reason for rejecting password
change request. Optionally em
ployed when the
UserRespType(8031)=1(representing rejection)


Standard trailer

Y



JR/T 0087

2012


15


9.3.2
Order Messages

9.3.2.1
Notes on
O
rder
M
essages

Order messages primarily include those which provide support to daily real
-
time transactions. See Schedule
C for ma
in 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 paramete
rs (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, t
he
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 “s
tale”
.

See Table 9 for the format of New Order
-
Single Message
:

Table 9 New Order
-
Single

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=D

11

ClOrdID

Y

Identifier of client order. Its uniqueness must be
guaranteed within a valid trading day.

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

Can be used to specify month and
year of
maturity

205

MaturityDay

N

Can be used in conjunction with
MaturityMonthYear to specify a particular
maturity date

207

SecurityExchange

Y

Can be used to identify the exchange

JR/T 0087

2012

16

Tag

Field Name

Required

Comments

77

OpenClose

Y

Indicates opening or closing a position

8009

HedgeFla
g

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 lim
it order)

423

PriceType

N

Price type

99

StopPx

N

Stop price

15

Currency

N

Type of currency

59

TimeInForce

N

T
ime at which a new order becomes effective.
Absence of this field indicates Day

168

EffectiveTime

N

Can
be used to specify

the time
during
which
the order
remains in effect

432

ExpireDate

N

Conditionally required if TimeInForce = GTD
and ExpireTime is not specified.

126

ExpireTime

N

Conditionally required if TimeInForce = GTD
and ExpireDate is not specified.

8096

MacNetInfo

N

Computer netw
ork information of client

58

Text

N



Standard trailer

Y


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)

relay order status information and

JR/T 0087

2012


17


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 execu
tion 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 whi
ch 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 identificat
ion 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 me
ssages 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

Comments


Standard header

Y

MsgType=8

37

OrderID

Y

Identifier for order as assigned by a futures
company. Its uniqueness must be guaranteed
within a single trading day.

11

ClOrdID

N

Identifier of client order. In the case of
information on fo
rced 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.

JR/T 0087

2012

18

17

ExecID

Y

Identifier of exe
cution message as assigned by a
futures company. Its uniqueness must be
guaranteed within a valid trading day.

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 e
xchange

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

T
ime at which a new order be
comes effective.
Absence of this field indicates Day

15

Currency

N

The type of currency

32

LastShares

N

Quantity of shares traded on last fill (quantity of
shares traded on the most recent fill )

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

JR/T 0087

2012


19


14

CumQty

Y

Total number of shares filled

6

AvgPx

Y

Average price

60

TransactTime

N

T
ime

of
execution report

381

GrossTradeAmt

N

Total am
ount 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 give
s

information on the status of the order through an execution report message.

See Table 11 for the format of O
rder Status Request Message
:

Table 11 Order Status Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=H

37

OrderID

Y

Identifier for order as assigned by a futures
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

MaturityMon
thYear

N

Can be used to specify month and year of
maturity

205

MaturityDay

N

Can be used in conjunction with
MaturityMonthYear to specify a particular
maturity date

54

Side

Y

Side of order


Standard trailer

Y


JR/T 0087

2012

20

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 T
able 12 for the format of Order Cancel Request
:


Table 12 Order Cancel Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=F

41

OrigClOrdID

Y

ClOrdID of the previous order used to identify the
previous order in the cancel requests.

37

Or
derID

Y

Identifier for order as assigned by a futures

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

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

O
rdType

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


21


9.3.2.6
Order Cancel Reject

(MsgType=9)

The order cancel reject message is used to reject an order cancel re
quest.

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 req
uest, 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
:

T
able 13 Order Cancel Reject

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=9

37

OrderID

Y

Identifier for order as assigned by a futures
company. Its uniqueness must be guaranteed
within a single trading day.

11

ClOrdID

Y

Identifier of clien
t order

41

OrigClOrdID

Y

ClOrdID of the previous order used to identify
the previous order in the cancel requests.

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 or
der creation

434

CxlRejResponseTo

N

T
ype of request that a Cancel Reject is in
response to

102

CxlRejReason

N

R
eason for
rejecting order cancel request

58

Text

N



Standard trailer

Y


9.3.3
Business Status Messages

9.3.3.1
Notes on
B
usiness
S
tatus
M
es
sages

Business status messages are primarily those which provide support to status
-
related requests.

JR/T 0087

2012

22

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 informa
tion relating to
the status of
positions held on a certain
contract.

See Table 14 for the format of Current /
P
revious Position Status Request
:

Table 14 Position Status Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF201

8088

Reques
tID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

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 co
de

207

SecurityExchange

N

Can be used to identify the exchange

54

Side

N

Identifies the side of order for a position

8101

BeginDate

C

B
eginning time of
a
previous position status
request. Required when PosStatReqType(8035)=1
(representing previous posit
ion status request)

8102

EndDate

C

E
nding time of
a
previous position status request.
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 n
eed to
return a response.

JR/T 0087

2012


23


See Table 15 for the format of Position Status Response
:

Table 15 Position Status Response

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF202

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
gu
aranteed within a single trading day.

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 sub
sequent data
packets

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

8009

H
edgeFlag

C

Flag

of speculation or hedge. Required when
PosStatRespType

(8507)=0 (
representing
acceptance)

14

CumQty

C

Total positions (total number of shares filled).
Required when PosStatRespType

(8507)=0
(representing acceptance)

8015

TdPosition

C

Toda
y positions. Required when
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

position
s


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.
JR/T 0087

2012

24

Optionally employed when the UserRespType

(8031)=1(representing rejection)

58

Text

N

Describes the reason for rejecting position status
request. Optionally employed when the
UserRespType

(8031)=1(representing reject
ion)


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 Pos
ition Status Request
:

Table 16 Max Operation Position Status Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF203

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

109

Client
ID

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

44

Price

N

Price.
Required when requesting the status of the
maximum amount of positions allowed to be
opened

8009

HedgeFlag

Y

Flag of speculation or hedge


Standard trailer

Y


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
:

JR/T 0087

2012


25


Table 17 Max Operation Position Status Response

Tag

Field Name

Required

Commen
ts


Standard header

Y

MsgType=UF204

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

109

ClientID

Y

Capital account of client

8031

UserRespType

Y

Type of response to user

1

Account

N

Trading c
ode 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

8023

MaxOpenPosition

N

Maximum amount of positions opened. Required
whe
n requesting the status of the opened
positions.

8024

MaxClosePosition

N

Maximum amount of positions closed. Required
when requesting the status of the closed
positions. If the closing of positions opened
today or yesterday is supported, the value is the
maximum amount of yesterday opened positions
closed

8025

MaxCloseTdPosition

N

Maximum amount of today opened positions
closed. Required when requesting the status of
positions closed and if the closing of toady or
yesterday opened positions is supported.

8009

HedgeFlag

Y

Flag of speculation or hedge

8037

MaxOpPosStatRejReaso
n

N

Reason for rejecting position status request.
Optionally employed when the
UserRespType(8031)=1(representing rejection)

58

Text

N

Describes the reason for rejecting position sta
tus
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 re
quest is also used to
request the status of orders in a particular exchange.

See Table 18 for the format of All Orders Status Request
:

JR/T 0087

2012

26

Table 18 All Orders Status Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF205

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

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

8
101

BeginDate

C

Beginning time of
an
all

previous

orders status
request

8102

EndDate

C

Ending time of
an

all

previous

orders status
request


Standard trailer

Y


9.3.3.7
All Orders Status Response (MsgType=UF20
6
)

It is the response made to the request o
f 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 a
n 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
:

JR/T 0087

2012


27


Table 19 All Orders Status Response

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF206

8088

RequestID

Y

Identifier of user re
quest. Its uniqueness must be
guaranteed within a single trading day.

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

Whe
ther there is any flag for subsequent data
packets

109

ClientID

Y

Capital account of client

1

Account

C

Trading code for client. Required when
AllOrdStatRespType (8512)=0 (representing
acceptance)

55

Symbol

C

Contract code. Required when
AllOrdStatRespT
ype (8512)=0 (representing
acceptance)

207

SecurityExchange

C

Can be used to identify the exchange. Required
when AllOrdStatRespType (8512)=0
(representing acceptance)

11

ClOrdID

C

Identifier of client order. Required when
AllOrdStatRespType (8512)=0 (re
presenting
acceptance)

39

OrdStatus

C

Status of order. Required when
AllOrdStatRespType (8512)=0 (representing
acceptance)

77

OpenClose

C

Indicates opening or closing a position.
Required when AllOrdStatRespType (8512)=0
(representing acceptance)

54

Sid
e

C

Side of order. Required when
AllOrdStatRespType (8512)=0 (representing
acceptance)

38

OrderQty

C

Number of shares ordered. Required when
AllOrdStatRespType (8512)=0 (representing
acceptance)

40

OrdType

C

Type of order. Required when
AllOrdStatRespTyp
e (8512)=0 (representing
JR/T 0087

2012

28

acceptance)

44

Price

N

Price of order

99

StopPx

N

Stop price

59

TimeInForce

N

T
ime at which a new order becomes effective.
Absence of this field indicates Day

15

Currency

N

Type of currency

151

LeavesQty

Y

Remaining quantity o
f 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

T
ime at which an order
was

entered

8039

AllOrdStatRejReason

N

Reason for rejecting
all orders
status request.
Optionally employed when the
UserRespType(8031)=1(representing rejection)

58

Text

N

Describes the reason for rejecting position status
request. O
ptionally 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 result
s
.

See Table 20 for the format of Sett
lement Result Status Request
:

Table 20 Settlement Result Status Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF207

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

109

Cli
entID

Y

Capital account of client

8028

SettlementDate

Y

Date of settlement result
s


207

SecurityExchange

Y

Can be used to identify the exchange


Standard trailer

Y



JR/T 0087

2012


29


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 S
tatus Response
:

Table 21 Settlement Result Status Response

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF20
8

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

8031

UserRespType

Y

Type of response to user

8028

SettlementDate

Y

Date of settlement result
s

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

Whether there is any flag for subsequent data
packets

8040

SettlementResultStatRej
Reason

N

Reason for rejecting
settlement result

status request.
Optionally employed when the
UserRespType(8031)=1(representing rejection)

58

Text

C

Require
d when when UserRespType(8031)=0
(representing acceptance). Specifies the contents of
the settlement result;

Optionally employed when the
UserRespType(8031)=1(representing rejection).
Describes the reason for rejecting settlement result
status request.


S
tandard trailer

Y



JR/T 0087

2012

30

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

MsgType=UF209

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

109

ClientID

Y

Capital account of client

8028

SettlementDate

N

Date of

settlement result
s

8029

SettlementConfirm

Y

Confirmation of settlement result
s

207

SecurityExchange

Y

Can be used to identify the exchange


Standard trailer

Y


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 Com
firm Response
:

Table 23 Settlement Result Comfirm Response

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF210

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

8031

UserRespType

Y

Type of response to user

8028

SettlementDate

N

Date of settlement result
s

8030

SettlementConfirmResult

C

Result of settlement result confirmation.
Required when UserRespType(8031)=0
(representing acceptance).

JR/T 0087

2012


31


207

SecurityExchange

Y

Can be used to identi
fy the exchange

8041

SettlementResultConfirm
RejReason

N

Reason for rejecting
settlement result confirm

request. Optionally employed when the
UserRespType(8031)=1(representing rejection)

58

Text

N

Describes the reason for rejecting

settlement
result confi
rm

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.

S
ee 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

MsgType=UF211

8088

RequestID

Y

Identifier of user request. Its uniqueness must b
e
guaranteed within a single trading day.

109

ClientID

Y

Capital account of client

8028

SettlementDate

N

Date of settlement result
s

207

SecurityExchange

Y

Can be used to identify the exchange


Standard trailer

Y


9.3.3.13
Settlement Result Comfirm Sta
tus 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=U
F212)

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 o
f Margin

Rate Status Request
:

JR/T 0087

2012

32

Table 25 Margin

Rate Status Request

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF212

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

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

Can be used to specify month and year of
maturity

207

SecurityExchange

Y

Can be used to identify the exc
hange


Standard trailer

Y


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 cas
e 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

Comments


Standard header

Y

MsgType=UF213

8088

RequestID

Y

Identifier of user request.
Its uniqueness must be
guaranteed within a single trading day. If a
futures company voluntarily transmit
s

the margin
rate to a client, the value is the identity of the sole
string initialized with “NONE” appearing on the
trading day

109

ClientID

Y

Capital

account of client

JR/T 0087

2012


33


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

8054

NoMarginEntries

C

Number of margin entries. Re
quired when
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

N

Reason for rejecting position status request.
Optionally employed when the
UserRespType(8031)=1(representing rejection)

58

Text

N

Describes the reason for rejecting
marginrate
status request. Optionally employed when the
UserRespType(8031)=1(representin
g 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 Req
uest

Tag

Field Name

Required

Comments


Standard header

Y

MsgType=UF214

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

JR/T 0087

2012

34

109

ClientID

Y

Capital account of client

8078

VarietyCode

N

Variety code

55

Symbol

N

Contract code

200

MaturityMonthYear

N

Can be used to specify month and year of
maturity

207

SecurityExchange

Y

Can be used to identify the exchange


Standard trailer

Y


9.3.3.17
Commission Rate Status Response (MsgType=UF215)

It is the res
ponse 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

MsgType=UF215

8088

RequestID

Y

Identifier of user request. Its uniqueness must be
guaranteed within a single trading day.

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

8078

VarietyCode

N

Variety code

55

Symbol

N

Contract code

200

MaturityMonthYear

N

Can be used to specify month and year of
maturity

8058

NoCommissi
onEntries

C

Number of commission entries. Required when
UserRespType(8031)=0 (representing
acceptance).

JR/T 0087

2012


35


Tag

Field Name

Required

Comments



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