Path:
Home >
MISC >
Page172 > JR/T 0066.1-2019
Price & Delivery
US$969.00 · In stock · Download in 9 secondsJR/T 0066.1-2019: Interbank market information exchange protocol - Part 1: Syntax, structure and session layer
Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See
step-by-step procedureStatus: Valid
JR/T 0066.1: Historical versions
| Std ID | Version | USD | Buy | Deliver [PDF] in | Title (Description) |
| JR/T 0066.1-2019 | English | 969 |
Add to Cart
|
6 days [Need to translate]
|
Interbank market information exchange protocol - Part 1: Syntax, structure and session layer
|
| JR/T 0066-2011 | English | RFQ |
ASK
|
19 days [Need to translate]
|
Inter-bank Market Information Exchange Protocl
|
Click to Preview a similar PDF
Basic data
| Standard ID | JR/T 0066.1-2019 (JR/T0066.1-2019) |
| Description (Translated English) | Interbank market information exchange protocol - Part 1: Syntax, structure and session layer |
| Sector / Industry | Finance Industry Standard (Recommended) |
| Classification of Chinese Standard | A11 |
| Word Count Estimation | 41,493 |
| Date of Issue | 2019-01-08 |
| Date of Implementation | 2019-01-08 |
| Older Standard (superseded by this standard) | JR/T 0066-2011 |
| Regulation (derived from) | Bank-Announcement (2019) No.6 |
| Issuing agency(ies) | People's Bank of China |
JR/T 0066.1-2019: Interbank market information exchange protocol - Part 1: Syntax, structure and session layer
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Interbank market information exchange protocol-Part 1. Syntax, structure and session layer
ICS 35.240.40
A 11
JR
Financial Industry Standards of the People's Republic of China
Replaces JR/T 0066-2011
Interbank Market Business Data Exchange Agreement
Part 1. Syntax, structure, and conversation layers
Interbank market information exchange protocol-
Part 1. Syntax, structure and session layer
Published.2019-01-08
2019-01-08 implementation
Published by the People's Bank of China
Contents
Foreword ... II
1 Scope ... 1
2 Normative references ... 1
3 Terms and definitions ... 1
4 Message syntax and structure ... 2
5 Session Transmission ... 14
6 Session Management ... 15
7 Session Messages and Components ... 24
Appendix A (Normative) Domain Dictionary ... 32
References ... 37
Foreword
JR/T 0066 "Interbank Market Business Data Exchange Agreement" is divided into 3 parts.
-Part 1. Grammar, structure and conversation layers;
-Part 2. Application layer;
-Part 3. The appropriate flow presentation layer.
This part is the first part of JR/T 0066.
This section is drafted in accordance with the rules given in GB/T 1.1-2009.
This section replaces the protocol syntax structure, session mechanism, and session of JR/T 0066-2011 "Interbank Market Business Data Exchange Protocol"
The relevant content of the layer message, the content that is not replaced is included in the second part of JR/T 0066. This part is similar to the replacement part of JR/T 0066-2011
Compared with the editorial changes, the main technical changes are as follows.
-Added normative references (see section 2);
-Revised and added some terms and definitions (see section 3, section 2 of the.2011 edition);
--Modified the contents of the message syntax and structure (see Chapter 4, Chapter 4 of the.2011 edition and 5.1, 5.2, 5.3)
--- Modified the content of session transmission (see section 5,.2011 version sections 3.1, 3.2, 3.3, 3.4, 3.5, 3.6 and 3.7);
--- Modified the content of session management (see section 6,.2011 version 3.8 and 3.9);
--- Modified the contents of session messages and components (see section 7,.2011 version 5.4);
-Added blockchain extension applications to adapt to international technological developments (see 4.7 and 7.2.2).
This section is proposed by China Foreign Exchange Trading Center and National Interbank Funding Center.
This section is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC 180).
This section is responsible for drafting units. China Foreign Exchange Trading Center and National Interbank Funding Center.
Participated in the drafting of this section. Department of Science and Technology of the People's Bank of China.
The main drafters of this section. Xu Zaiyue, Yao Qian, Yang Fuyu, Zhu Rong, Ye Shengguo, Jiang Caikang, Wang Chengyong, Hu Jian, Li Zheng, Chen Bin,
Hu Weiping, Shen Jun, Cui Yan, Wu Yongda, Yu Bo, Qu Weimin, Sun Xiaolin, Shen Weiwei, Mao Ting, Yang Fan, Xia Zhijiang, Sun Yinghao, Bao Xiao
Jing, Zhao Junfeng, Lu Yanmin, Cui Qi, Deng Gangyi, Yan Luyi, and Shen Ye.
JR/T 0066 was first released on June 2,.2011, and this is the first revision.
Interbank Market Business Data Exchange Agreement
Part 1. Syntax, structure, and conversation layers
1 Scope
This part of JR/T 0066 specifies the session layer communication protocol required for inter-bank transactions between participants in the inter-bank market
(Interbank Market Information Exchange Protocol Transport, referred to as IMIXT), including message syntax and results
Architecture, session reliable transmission specifications, session management specifications, session messages and components, etc.
This section applies to basic session communication data exchange between participants in the interbank market. This section applies to the inter-bank market
Business data exchange protocol (Interbank Market Information Exchange Protocol, IMIX) message transmission interaction,
Interbank market institutions include, but are not limited to, intermediary service institutions, member institutions, and other institutions using this section.
2 Normative references
The following documents are essential for the application of this document. For dated references, only the dated version applies to this document.
For undated references, the latest version (including all amendments) applies to this document.
GB/T 2659 countries and regions
GB/T 12406 code for currency and funds
JR/T 0066.2-2019 Interbank Market Business Data Exchange Protocol Part 2. Application Layer
3 terms and definitions
The following terms and definitions apply to this document.
3.1
Field separator
All fields in the message have a delimiter to define the delimitation.
Note. The separator is ASCII code 0x01. The field delimiter in JR/T 0066 starts with \u003cSOH\u003e Means.
3.2
Repeating group
A collection of domains consisting of the number of repetitions and several sets of homogeneous data.
3.3
Component
A set of domains composed of session messages and application messages according to certain business logic.
3.4
Message sequence number
The value used to monitor the continuity of message transmission during message transmission.
Note. Use this value to judge whether the exchange data is lost.
3.5
Heartbeat
In the idle period of message exchange, the initiator and receiver of the message maintain a communication connection by generating regular heartbeat messages.
3.6
Send duplicate
Scenarios in which a packet is repeatedly sent because it responds to a retransmission request or is not sure whether the other party has received a sent packet
Note. The message in this scenario should be set with "Possibly Duplicate Flag" (PossDupFlag = Y).
3.7
Resend possible resend
Scenarios where the sender of the message regenerates and sends the message due to the application needs of the sender or receiver.
Note. The message in this scenario should be set with "possible resend flag" (PossResend = Y).
3.8
Sequence reset
The message used by the sender to set the expected message sequence number. There are two modes of sequence reset message. sequence reset-gap filling
(SeqReset-Gap Fill), serial number reset-reset (SeqReset-Reset).
Note. SeqReset-Reset is only used in disaster recovery situations.
3.9
Valid IMIX message
Messages generated correctly according to the IMIX protocol.
3.10
Initiator
The sender of the login message.
3.11
Receiver
Receiver of the login message.
3.12
Blockchain
A peer-to-peer network environment that uses transparent and trusted rules to construct unforgeable, non-tamperable and traceable blockchain data structures
Construct, implement, and manage transaction processing models.
4 Message syntax and structure
4.1 Data types
4.1.1 Description
The data type is used to define the value type of the data field. The data type used by JR/T 0066 consists of several basic data types (integer,
Floating point numbers, characters, strings, data) and data types extended on this basis. Data other than "data" data type
Types are represented as ASCII strings.
4.1.2 Int
Values without commas and decimal places, which can be positive or negative (ASCII characters "-", "0" to "9"). Symbol occupy a word
Character position. Leading characters can be set to zero (eg "00023" = "23").
Extended definition of integer types.
a) Length. the length of the data in integer bytes, a positive number;
b) Repeat number NumInGroup. the number of repeat groups is represented by an integer, a positive number;
c) message sequence number SeqNum. the message sequence number is represented by an integer, a positive number;
d) Field number TagNum. field number (or tag) expressed as an integer, positive number, the first digit cannot be zero;
e) DayOfMonth. Day of the month as an integer, from 1 to 31.
4.1.3 float
Contains an optional decimal part, which can be positive or negative (ASCII characters "-", "0" to "9" and "."). Leading character
Can be set to zero (for example, "0023" = "23"), and the post-decimal characters can be set to zero (for example, "23.0" = "23.0000" = "23").
Extended definition of floating point type.
a) Quantity Qty. the number of shares, the number of assets, etc., may have a decimal part;
b) Price. variable number of decimal places;
c) Price Offset. a floating point field representing the price offset;
d) Amount Amt. the typical price multiplied by the quantity, such as the transaction amount;
e) Percentage. Decimal representation method. For example, .05 means 5%.
4.1.4 char
All alphabetic and punctuation characters except delimiters are case sensitive.
The extended definition of the character type is Boolean. This field has two characters ("Y" = True/Yes, "N" = False/No).
4.1.5 String
In addition to the delimiter, a string of characters consisting of numbers, letters, and symbols, which is case sensitive.
Extended definition of string type.
a) MultipleValueString. separated by spaces (for example 10243 = D2 M3 Y3);
b) Country. See GB/T 2659 (for example, 470 = CHN) for the value range;
c) Currency of string currency. For the value range, see GB/T 12406 (eg 15 = CNY);
d) Exchange or market number Exchange. string (eg 1301 = 2);
e) Month-year. format YYYYMM, YYYY = 0000-9999, MM = 01-12 (for example,.200 =.201710);
f) UTCTimestamp. format YYYYMMDD-HH. MM. SS (seconds) or YYYYMMDD-HH. MM. SS.sss
(Milliseconds), YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-59 (seconds),
sss = 000-999 (milliseconds) (e.g. 60 =.20171012-11. 40. 00 or.20171012-11. 40. 00.123);
g) UTCTimeOnly. format HH. MM. SS or HH. MM. SS.sss, HH = 00-23, MM = 00-59,
SS = 00-59 (seconds), sss = 000-999 (milliseconds) (for example, 10318 = 11. 40. 00 or 11. 40. 00.123);
h) LocalMktDate. Format YYYYMMDD, YYYY = 0000-9999, MM = 01-12, DD = 01-31 (for example
916 =.20171012);
i) UTCate date. format YYYYMMDD, YYYY = 0000-9999, MM = 01-12, DD = 01-31 (for example
75 =.20171012).
4.1.6 Data
Unformatted and content-restricted raw data includes two parts. the length field and the data field. The data field data can include the domain delimiter < SOH>,
For special symbols, the length field indicates the number of bytes in the data field (note. the calculation of the number of bytes does not take into account the field delimiter < SOH>).
Example. 1401 is the length field and 1402 is the data field.
4.2 Domain
4.2.1 Domain definition
Domains are the basic data elements. During transmission, the domain is composed of domain number, equal sign, and domain value, that is, domain number = domain value. Domain dictionary section details
The data types and value ranges of all fields involved in this section are defined, see Appendix A.
4.2.2 Use of Domains
In the message, there are three ways to use the domain. required, non-essential, conditional selection (that is, based on the existence of other related domains and
No or value to decide).
Examples of conditionally restricted selection fields are shown in Table 1. When the value of 628, 629, 630 exists, 627 should have the value; when 628, 629, 630 does not exist
In the value, 627 can also be empty. 627 is the conditional selection field.
Table 1 Examples of conditionally restricted selection fields
Domain number/nested component name domain name required domain
627 NoHops
- > 628 HopCompID Y
- > 629 HopSendingTime
- > 630 HopRefID
4.2.3 Custom Domain
If the domain defined in JR/T 0066 cannot meet the requirements, a new domain can be defined by extension, that is, a custom domain.
JR/T 0066 users can agree on a custom domain by themselves. The domain number of the custom domain should not duplicate the domain number defined in JR/T 0066.
And it should be greater than 10000.
4.2.4 Domain definition
All fields in the message (including data fields of data type) have a delimiter to define the separation. The delimiter is the ASCII code 0x01.
(To \u003cSOH\u003e Means).
Any message should consist of multiple "domain number = value" basic structures, with domain delimiters \u003cSOH\u003e Separated. The message structure is shown in Figure 1.
\u003cSOH\u003e Field number = field value \u003cSOH\u003e Field number = field value
Figure 1 Message composition structure
4.3 IMIX message composition rules
A message consists of a message header, a message body, and a message tail. Each component consists of a series of "domain number = value", which should follow the rules below
then.
a) the beginning should be the message header, followed by the message body, and finally the message tail;
b) The order of the first 3 fields in the packet header should not be changed. the start string (Tag
0066 Add a nested repeating group name to the repeating group structure to mark the nested repeating group.
4.5 Security and encryption
Because messages may be transmitted and exchanged on public networks or insecure networks, relevant sensitive data should be encrypted. With
The method of volume encryption is determined by the agreement reached between the two parties. At the same time, the encryption method should comply with the regulations of the national password management agency. Excluding a certain message
Except for those domains that need to be publicly identified for transmission in clear text, any other domains can be placed in encrypted data domain (SecureData) encrypted. These are
8 = IMIX1.0 \u003cSOH\u003e 9 = xxx \u003cSOH\u003e 35 = 8 \u003cSOH\u003e 49 = CFETS \u003cSOH\u003e 56 = 290008811000000000000 \u003cSOH\u003e 57 = MHBJ.D
EALER @ MHBJ \u003cSOH\u003e 34 = 13 \u003cSOH\u003e 52 =.20070913-10. 20. 59 \u003cSOH\u003e 347 = UTF-8 \u003cSOH\u003e 11 = MHBJ_ORDER_002 \u003cSOH
> 15 = AUD \u003cSOH\u003e 17 = 5.1.3293 \u003cSOH\u003e 31 = 0.771 \u003cSOH\u003e 32 = 50000 \u003cSOH\u003e 54 = 1 \u003cSOH\u003e 60 =.20061122-10. 21. 34 \u003cS
OH > 63 = 0 \u003cSOH\u003e 64 =.20061124 \u003cSOH\u003e 75 =.20061122 \u003cSOH\u003e 120 = AUD \u003cSOH\u003e 150 = F \u003cSOH\u003e 194 = 0.771 \u003cSOH\u003e 1056 =
38550 \u003cSOH\u003e 10176 = 12 \u003cSOH\u003e 10038 = 22 \u003cSOH\u003e 10042 = MT \u003cSOH\u003e 10317 = 5 \u003cSOH\u003e 10315 = 2 \u003cSOH\u003e 10296 =.200611
twenty four \u003cSOH\u003e 1028438547.5 \u003cSOH\u003e 22 = 5 \u003cSOH\u003e 48 = AUDUSD = CFHA \u003cSOH\u003e 55 = AUD.USD \u003cSOH\u003e 453 = 2 \u003cSOH\u003e 448 = 1190
00043010000000000 \u003cSOH\u003e 452 = I14 \u003cSOH\u003e 802 = 3 \u003cSOH\u003e 523=CCCB.DEALER@CCCB \u003cSOH\u003e 803 = 101 \u003cSOH\u003e 523 =
CCCB \u003cSOH\u003e 803 = 102 \u003cSOH\u003e 523 = ChangshaCityCommercialBank \u003cSOH\u003e 803 = 5 \u003cSOH\u003e 448 = 290008811000000
000000 \u003cSOH\u003e 452 = I13 \u003cSOH\u003e 802 = 3 \u003cSOH\u003e 523=MHBJ.DEALER@MHBJ \u003cSOH\u003e 803 = 101 \u003cSOH\u003e 523 = MHBJ \u003cSOH\u003e 80
Encrypted domains can also retain plaintext representations. If some data in the repeating group of the message needs to be encrypted, the entire repeating group should be treated
encryption. This section also provides domains to support security technologies such as digital signatures, key exchange, and body encryption.
There are three encryption schemes.
a) Encrypt the security-sensitive domain and move it to the SecureData domain;
b) Encrypt all encrypted domains and move them to the SecureData domain;
c) Encrypt all the fields that can be encrypted and move them to the SecureData field. At the same time, these fields repeatedly appear in the message in plain text.
4.6 Data integrity
Data integrity is guaranteed by two methods. the length of the message body and the verification of the checksum.
The length of the message body is represented by the BodyLength field. The value is the number of characters after the calculated message length field, including the checksum field.
Domain delimiter before "10 =" \u003cSOH\u003e . The checksum is to add the binary value of each character starting from "8" in the beginning of the message "8 =".
Add it to the field delimiter immediately before the checksum field "10 =", and then take the result obtained by modulo 256. The checksum field is in the
Finally, the checksum calculation is performed after encryption. To facilitate transmission, checksums should be sent as printable characters, so they should be converted
Three values are encoded in ASCII code.
Example. If the checksum is calculated as 274, then modulo 256 gives 18, (256 18) mod 256 = 18. This value will be transmitted at | 10 = 018 |
Where "10 =" is the flag of the checksum field.
An example code snippet that generates a checksum field is shown in Figure 3.
Figure 3 Sample code snippet for checksum field
4.7 IMIX message structure
For each IMIX message, its message structure breakdown is shown in Figure 4.
char * GenerateCheckSum (char * buf, long bufLen)
{static char tmpBuf [4];
long idx;
unsigned int cks;
for (idx = 0L, cks = 0; idx \u003cbufLen; cks = (unsigned int)buf[ idx ]);
sprintf (tmpBuf, “d”, (unsigned int) (cks% 256));
return (tmpBuf);
};
IMIX Message
IMIX message
Header
Standard header
Trailer
Standard message tail
Body
Message body
Domain 8
Domain 9
Domain 35
Component
Component
Repeating
Group
Repeat group
Domain 10
Group Block1
Block 1
Domain domain
Domain domain
Group Block2
Block 2
Group Block3
Block 3
Explanation.
Domain--represents a domain;
Repeating group-means repeating group, which can be composed of multiple repeating blocks;
Blocks-Represents each repeating part in a repeating group, which is also composed of domain blocks;
Component--Represents a collection of multiple domains, and the meanings represented by these domains are related.
Figure 4 IMIX message structure
The overall structure of the data for the operation of the blockchain technology is shown in Figure 5.
Blockchain
Header
Load body
Block header
Block body
version
Pre-block header hash
Merkel root hash
Time Timestamp
Bits Current target hash value Bits HASH
Nonce
Magic number
Command name
Load size
Check code
Figure 5 Blockchain overall structure
The overall structure of the blockchain includes a message header and a payload. Different load body types can meet the transmission needs of various scenarios, such as obtaining blocks,
Get data, transactions, and more. Figure 5 shows the overall structure of the blockchain when transmitting the block header and the blocks of the transaction order. When the load body has no data definition,
Only the message header can be transmitted.
According to the definition of the data structure of the blockchain, its data types and organization methods do not exceed the scope of the existing IMIX system. As given in Figure 4
IMIX message structure, IMIX message structure using blockchain technology is shown in Figure 6.
Load body components
Blockchain message header component
IMIX Block
Header
Standard header
Trailer
Standard message tail
Body
Message body
Domain 8
Domain 9
Load size
Block header component
Domain 10
version
Pre-block header hash
Magic number
Merkel root hash
Check code
Command name
Block body
Domain 35
Explanation.
Domain--represents a domain;
Component--Represents a collection of multiple domains, and the meanings represented by these domains are related.
Figure 6 IMIX message structure using blockchain technology
Figure 6 shows the IMIX message structure when the block header and transaction order block are transmitted. According to the application requirements of specific scenarios, different load classes can be used
Type of components.
In the IMIX protocol, the.20000-21000 domain number segment is fixedly allocated for the expression of the content of the blockchain data.
4.8 Standard header
4.8.1 Overview
Each session message or application message has a message header, which indicates the message type, message body length, sending destination, message
Document serial number, sending start point and sending time.
4.8.2 Standard Header Format
See Table 2 for standard message headers.
Table 2 Standard packet header
Domain Number/Nested Component Name Domain Name Required Domain Remarks
8 BeginString Y The start string defines the protocol version of the message (it should not be encrypted, the first field of the message).
9 BodyLength Y Body length (should not be encrypted, it should be the second field of the message).
34 MsgSeqNum Y Message sequence number (can be encrypted).
35 MsgType Y Message type (should not be encrypted, it should be the third field of the message).
43 PossDupFlag It is possible to repeat the flag. When sending repeatedly, make this flag (encryptable).
49 SenderCompID Y sender identifier (should not be encrypted).
50 SenderSubID The sender's sub-identifier (encryptable).
52 SendingTime Y (encryptable).
56 TargetCompID Y Receiver identifier (should not be encrypted).
57 TargetSubID Receiver sub-identifier (encryptable).
90 SecureDataLen Required (not to be encrypted) to identify the length of the encrypted portion of the message.
91 Required for SecureData message body encryption. Immediately after the SercureDataLen domain.
97 PossResend may resend flag (encryptable).
115 OnBehalfOfCompID The original sender identifier (encryptable) for sending via a third party.
116 OnBehalfOfSubID The original sender sub-identifier (encryptable).
122 OrigSendingTime Original send time (can be encrypted).
128 DeliverToCompID The final recipient identifier (encryptable) for sending via a third party.
129 DeliverToSubID The final recipient sub-identifier (encryptable).
142 SenderLocationID The sender's LocationID (eg. geographic location and/or desk) (may be
encryption).
143 TargetLocationID Receiver LocationID (eg. geographic location and/or desk) (may be
encryption).
145 DeliverToLocationID LocationID of the final recipient (such as geographic location and/or desk)
(Can be encrypted).
212 XmlDataLen Required (identifiable) when identifying the length of the XmlData message body.
213 XmlData contains XML-formatted message blocks (such as IMIXML); always follows XmlDataLen (can be
Encryption).
347 MessageEncoding The message encoding format (non-ASCII encoding) used in the "Encode" field of the message,
Required when using encoding fields.
369 LastMsgSeqNumProcessed Sequence number of the last processed message (can be encrypted).
1128 ApplVerID uses the SP identification method to indicate the application version, ApplVerID is used for a specific message
Scene.
Domain Number/Nested Component Name Domain Name Required Domain Remarks
1129 CstmApplVerID is used to enable customers to negotiate and agree on features.
1156 AppIExtID
Component \u003cHopGrp\u003e Repeat group for historical hop information, record the history of the message sent by a third party.
Each time it is sent by a third party as a hop, only when OnBehalfOfCompID is used
Valid, mainly used to track the path of packets. Note. Some market regulations or
The hand may require tracking hops.
4.8.3 Application of Standard Message Header in Message Transmission
4.8.3.1 Point-to-point transmission
Tables 3 and 4 show how to use SenderCompID in a single point-to-point IMIX session between two market participants,
TargetCompID, SenderSubID, TargetSubID fields. SenderSubID is a subsidiary of SenderCompID, TargetSubID
Is a child of TargetCompID.
An example of a single point-to-point IMIX session transmission between two main organizations is shown in Table 3. Suppose A is the seller's main body and B is the buyer's main body.
Table 3 Example of point-to-point transmission (between main agencies)
SenderSubID SenderCompID TartgetCompID TargetSubID
A to BAB
B to ABA
An example of a single point-to-point IMIX session transmission between two sub-organizations is shown in Table 4. Suppose A1 is the seller's subsidiary, A is the seller's main organization, and B1
Is the buyer's subsidiary organization, and B is the buyer's main organization.
Table 4 Example of point-to-point transmission (between sub-organizations)
SenderSubID SenderCompID TartgetCompID TargetSubID
A1 to B1 A1 AB B1
B1 to A1 B1 BA A1
4.8.3.2 Message Forwarding
Because the message between the two ends is forwarded by a third party, the third party can connect with other third parties, and
Multi-point chains are formed between the receivers. SenderCompID, SenderSubID, TargetCompID, TargetSubID, DeliverToCompID,
The DeliverToSubID, OnBehalfOfCompID, and OnBehalfOfSubID fields are used for message routing. The use of these fields is shown in Table 5.
Middle A is the seller, B and C are the buyers, and Q is a third party.
Table 5 Example packet forwarding table
SenderCompID OnBehalfOf
CompID
TargetCompID Deliv...
...
