CMDS-Client-API-IMIX开发指引-V2.9

CFETS/K04382015CFETS IMIX Protocol Development GuideCFETS/K04382015CMDS Client API IMIXDevelopment GUIDE(Version 2.9)Protocol Version 1.111.3CMDS Client APIPublish by CFETSContentsPrefaceIVForewordVRevision HistoryVI1 Scope12 IMIX Protocol Introduction12.1 Scope of Application12.2 IMIX Message Structure12.2.1 Standard Message Header22.2.2 Standard Message Trailer62.2.3 Standard Message Body62.2.4 Repeating Groups62.2.5 Component Block73 Key Field and Group73.1 MsgType73.2 MarketIndicator73.3 UniqueOutputKey83.4 SecurityID83.5 LiquidProviderGrp83.6 MDTypeGrp83.7 Rule of RIC Code94 Business Scene Introduction104.1 Data Type104.1.1 Update data104.1.2 Snapshot data104.1.3 Refresh data104.2 Data Content104.2.1 Mid-price data104.2.2 Best quote data114.2.3 Market statistics data124.3 Message Flow125 Business Scene Sample135.1 Logon135.2 Logout145.3 Broadcast Request145.4 Broadcast Data145.4.1 Mid-price Data155.4.1.1 Content of Mid-price Data155.4.1.2 Example of Mid-price Data155.4.2 Best Quote Data165.4.2.1 For Spot, Forward and NDF Market165.4.2.1.1 Content of Best Quote Data165.4.2.1.2 Example of Best Quote Data175.4.2.2 For Swap Market185.4.2.2.1 Content of Best Quote Data185.4.2.2.2 Example of Near Leg Data195.4.2.2.3 Example of Far Leg Data205.4.3 Market Statistics Data225.4.3.1 For Spot, Forward and NDF Market225.4.3.1.1 Content of Market Statistics Data225.4.3.1.2 Example of Market Statistics Data235.4.3.2 For Swap Market255.4.3.2.1 Content of Market Statistics Data255.4.3.2.2 Example of Near Leg Data265.4.3.2.3 Example of Far Leg Data285.5 Refresh Request295.6 Refresh Data305.6.1 For Spot, Forward and NDF Market305.6.1.1 Content of Refresh Data305.6.1.2 Example of Refresh Data325.6.2 For Swap Market355.6.2.1 Content of Refresh Data355.6.2.2 Example of Near Leg Data375.6.2.3 Example of Far Leg Data395.7 Historical Data Retransmission Request425.8 Historical data436 Develop Guide436.1 Notice of Development436.2 Logon and Logout sample456.3 Send MarketDataRequest466.4 Deal with MarketDataSnapshotFullRefresh486.5 Exception Handing507 CNY CMDS API517.1 SenderSubID517.2 Market Configure527.3 Business Message527.4 Data Type in CNY Market527.5 Request type in CNY Market527.6 Business Scene in CNY Market52Reference53Diagram 1 architecture of system1Diagram2 IMIX Message Structure2Diagram 3 workflow of system13Table 1 Standard Message Header2Table 2 Standard Message Trailer6Table 3 Example Of a Repeating Group7Table 4 Example Of Component Block7Table 5 Example Of LiquidProviderGrp8Table 6 Example Of MDTypeGrp8Table 7 Example Of Mid-price Data11Table 8 Example of Best Quote Data11Table 9 Example Of Liquid Provider11Table 10 Content of Broadcast Request14Table 11 Example of Broadcast Request14Table 12 Content of Mid-price Data15Table 13 Example of Mid-price Data15Table 14 Content of Best Quote Data in Spot, Forward and NDF Market16Table 15 Example of Spot, Forward and NDF Market17Table 16 Content of Best Quote Data in Swap Market18Table 17 Example of Near Leg Data19Table 18 Example of Far Leg Data21Table 19 Content of Market Statistics Data in Spot, Forward and NDF Market22Table 20 Example of Spot, Forward and NDF Market23Table 21 Content of Market Statistics Data in Swap Market25Table 22 Example of Near Leg Data27Table 23 Example of Far Leg Data28Table 24 Content of Refresh Request29Table 25 Example of Refresh Request29Table 26 Content of Refresh Data in Spot, Forward and NDF Market30Table 27 Example of Spot, Forward and NDF Market32Table 29 Example of Near Leg Data37Table 30 Example of Far Leg Data39Table 31 Content of Historical Data Retransmission Request42Table 32 Example of Historical Data Retransmission Request (By Data Time)42Table 33 Example of Historical Data Retransmission Request (By Unique Output Key)43Table 34 MarketDataRequest Structure46PrefaceCMDS is a market data broadcasting system, CFETS wants to get the market data from CMDS, CMDS Client API is designed for that purpose, it can communicate with CMDS system, and the message provided to API user is IMIX message, and the users can develop their own application based on this API.This file is managed by CFETS.This file is provided by CFETS.CFETS is responsible to draft the file.ForewordWith the continously deepen the financial reform in our country, the unceasingly enhanced informationization in interbank market, financial standards gradually penentrated into all aspects of marketing activities. As a team leader of Interbank Market Standard Working Group, CFETS has actively implemented the strategy of the Peoples Bank of China, continously contributed to the interbank market standardization construction, taken the lead in drafting JR/T 0065-2011 Interbank Market Basis Data Source, JR/T 0066-2011Interbank Market Business Data Exchange Protocol, JR/T 0078-2014 Interbank Data Interfaceand other financial industry standards. Based on these standards, CFETS provides straight-through processing interface, market data interface, quote interface, trade transaction interface and other interface service, and introduces including normative guidance documents, application programming interface (API), and data interface development service system to support technical and business requirements. IMIX protocol as a guidance document plays an important role to standardize the delvelopment of data interface. Therefore, this document pays more attention to our interbank makret self characteristics and standardization, further plays as a guidance of financial system construction, builds solid foundation for unifying interbank makret business data exchange system.Revision HistoryAuthorAuditorUser Guide VersionProtocol VersionDateRevision CommentsShuxin Li1.12008-08-251.Create the documentShuxin Li1.22008-10-101.Add business sceneLei Wang1.32008-10-171.Add examples in chapter 7Shuxin Li1.42008-10-201.Add example programsShuxin Li1.52008-10-281.Add key group example and business elements for each sceneLei Wang1.62008-10-301.Update business elements for each scene;2.Add Field 10462 for each example;3.Add Field 34 and 52 for each Request message exampleShuxin Li1.72008-10-301.Add related documents to development guideShuxin Li 1.82008-11-181.Add Field 10483(SnapshotInterval) into each related example;2.Remove field 22 (SecurityIDSource) andfield 603 (LegSecurityIDSource) from message;Lei WangShuxin Li1.92008-11-201.Remove field 272(MDEntryDate) and 273(MDEntryTime) from Mid-price data example.2.Remove field 10462(DelayPeriod) from refresh messagesLei Wang2.02008-11-271.Add last ask dealt rate data to refresh data examples;2.Add “dealt date, dealt time, last dealt rate, last allin, deal side” to refresh data;3.Review all the examples and modified some details(All changes are tracked in the document);4.Add comments in some examples;Shuxin LiWang Lei2.12008-12-311.Change NoLegss field number from 146 to 555;2.Adjust the order of field 10360 and 10359 in LiquidProviderGrp to fit IMIX protocol format;3.Update some fields value in Refresh data examples.Shuxin Li2.22009-5-131.All versions before 2.2 are about FX CMDS API, now API can receive messages from CNY CMDS, so add new chapter 8 to introduce the improvements of API and differences between two markets.Weina He2.32012-8-81.Replace 269 MDEntryType =d to 269 MDEntryType =1 in versions 6.4.2.1.1 and versions 6.4.2.2.1 Weina He2.42013-1-211.Add section 6.7: CFETS Cross Currency Swap CurvesTingkai Yan2.52013-12-31.Add section 6.8 Fx option delta curves of chapter sixTingkai Yan2.62013-12-61.Change the message header of 6.8.2Tingkai Yan2.72013-12-171.Change the values of 10164 and 10337 which located at 6.8.2Tingkai Yan2.82014-2-111.Delete 6.7 CFETS Cross Currency Swap Curves and 6.8 FX OPTION DELTA CURVESYujiaoXia2.91.111.32015-1-191.Add chapter 3.7 to illustrate rule of RIC code2.Add comments of tag 602(LegSecurityID) in chapter 5.4.2.2.2, 5.4.2.2.3, 5.4.3.2.2, 5.4.3.2.3, 5.6.2.2 and 5.6.2.3VIICMDS Client API IMIX Development Guide1 ScopeCMDS Client API is designed for users who want to connect and communicate with CMDS. Before introducing API details, we firstly introduce the architecture of whole systems.Diagram 1 architecture of systemThe above diagram indicates that client should send request to CMDS before receiving data. The request message from Client to CMDS is represented by MarketDataRequest (MsgType=V), and all the business data from CMDS to client is transmitted by MarketDataSnapshotFullRefresh (MsgType=W).This document mainly has two parts: the first part is the specification of IMIX protocol, and the second part is to introduce the IMIX messages used in CMDS Client according to business scene.2 IMIX Protocol Introduction2.1 Scope of ApplicationIMIX protocol covers business of chinese makret trasnactions, quotes and downloading market data, and parts of foreign exchange transactions.2.2 IMIX Message StructureIMIX message structure is illustrated in diagram 2. Diagram2 IMIX Message StructureThe general format of an IMIX message is a standard header followed by the message body fields and terminated with a standard trailer.2.2.1 Standard Message HeaderEach session or application message has a header. Header defines message type, message body length, target destination, message sequence number, sender and sending time.Format of message header is shown in Table 1.Table 1 Standard Message HeaderTagFieldReqdComments8BeginStringYIMIX.1.0 (Must be first field in message)9BodyLengthY(Must be second field in message)35MsgTypeY(Must be third field in message)49SenderCompIDY56TargetCompIDY115OnBehalfOfCompIDNTrading partner company ID used when sending messages via a third party.128DeliverToCompIDNTrading partner company ID used when sending messages via a third party.90SecureDataLenNRequired to identify length of encrypted section of message.91SecureDataNRequired when message body is encrypted. Always immediately follows SecureDataLen field.34MsgSeqNumY50SenderSubIDN142SenderLocationIDNSenders LocationID (i.e. geographic location and/or desk).57TargetSubIDN“ADMIN” reserved for administrative messages not intended for a specific user.143TargetLocationIDNTrading partner LocationID (i.e. geographic location and/or desk)116OnBehalfOfSubIDNTrading partner SubID used when delivering messages via a third party144OnBehalfOfLocationIDNTrading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party.129DeliverToSubIDNTrading partner SubID used when delivering messages via a third party.145DeliverToLocationIDNTrading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party.43PossDupFlagNAlways required for retransmitted messages, whether prompted by the sending system or as the result of a resend request.97PossResendNRequired when message may be duplicate of another message sent under a different sequence number.52SendingTimeY122OrigSendingTimeNRequired for message resent as a result of a ResendRequest. If data is not available set to same value as SendingTime212XmlDataLenNRequired when specifying XmlData to identify the length of an XmlData message block.213XmlDataNCan contain a XML formatted message block347MessageEncodingNType of message encoding (non-ASCII characters) used in a messages “Encoded” fields. Required if any “Encoding” fields are used.369LastMsgSeqNumProcessedNThe last MsgSeqNum value received by the IMIX engine and processed by downstream application, such as trading system or order routing system. Can be specified on every message sent. Useful for detecting a backlog with counterparty.627NoHopsNNumber of repeating groups of historical “hop” information. Only applicable if OnBehalfOfCompID is used, however, its use is optional. Note that some market regulations or counterparties may require tracking of message hops.628HopCompIDNThird party firm which delivered a specific message either from the firm which originated the message or from another third party (if multiple “hops” are performed). It is recommended that this value be the SenderCompID (49) of the third party.629HopSendingTimeNTime that HopCompID (628) sent the message. It is recommended that this value be the SendingTime (52) of the message sent by the third party.630HopRefIDNReference identifier assigned by HopCompID (628) associated with the message sent. It is recommended that this value be the MsgSeqNum (34) of the message sent by the third party.2.2.2 Standard Message TrailerEach session message or application message has a trailer to termiante the message.Message trailer is used to separate messages, includes three byte checksum.The format of message trailer is as follows in Table 2.Table 2 Standard Message TrailerTagFieldReqdComments93SignatureLengthNRequired when trailer contains signature. Note: Not to be included within SecureData field89SignatureNNote: Not to be included within SecureData field10CheckSumY(Always unencrypted, always last field in message)2.2.3 Standard Message BodyMessage body is mainly used to describe business information in application layers. Application messages share many common fields setscomponent. For example, most application message has adopted a set of fixed income defined fields, such as Symbol, Security ID, Security IDSource. In order to avoid replication, the protocol also defines some key components which is included in application messages. In practical message definition and usage, these compoents should be explored to corresponent fields sets.2.2.4 Repeating GroupsIt is permissible for fields to be repeated within a repeating group (e.g.384=2372=6385=R372=7385=R represents a repeating group with two repeating instances “delimited” by tag 372 (first field in the repeating group). If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a delimiter indicating a new repeating group entry. The first field listed after the NoXXX, then becomes conditionally required if the NoXXX field is greater than zero. The NoXXX field (for example: NoTradingSessions, NoAllocs) which specifies the number of repeating group instances occurs once for a repeating group and must immediately precede the repeating group contents. The NoXXX field is required if one of the fields in the repeating group is required. If all members of a repeating group are optional, then the NoXXX field should also be optional. If a repeating group field is listed as required, then it must appear in every repeated instance of that repeating group. Repeating groups are designated within the message definition via indentation and the symbol.Some repeating groups are nested within another repeating group (potentially more than one level of nesting). Nested repeating groups are designated within the message definition via indentation and the symbol followed by another symbol. If a nested repeating group is used, then the outer repeating group must be specifiedThe following is an example of a repeating group.Table 3 Example Of a Repeating GroupTagFieldReqdComments454NoSecurityAltIDNNo of Securities455SecurityAltIDNSecurity ID456SecurityAltIDSourceNSecurity ID Source2.2.5 Component BlockIMIX component blocks are a logical concept. They are used to represent sets of related data fileds. Each component is refered with a name. It is better to understand message structure and business application scenarios. In pratical messages transmission, names of component blocks do not apprear in meassages. The creation of component allows users better understand IMIX message structrure.The following is an example of the component block.Table 4 Example Of Component BlockTagFieldReqdComments10128MarginAccountAmtYmargin account balance10129FrozenAmtfrozen amount in margin account10130PendingAmtpending amount in margin account10131AvailableAmtavailable amount in margin account10344CollateralTypethe type of margin account3 Key Field and Group3.1 MsgType is used to define message type, the field number is 35. For example: represents the message is a request to CMDS, represents the business data received from CMDS, you can find more details in the IMIX dictionary document.3.2 MarketIndicator is the indicator of different market; its field number is 10176. In different market, the same type message has different meanings, so users should deal with the business message according to message type together with the market i