JR/T 0066-2011Interbank market information exchange protocol - Part 1: Syntax, structure and session layer (English PDF)

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 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...