《證券交易數據交換協(xié)議》SE協(xié)議

《《證券交易數據交換協(xié)議》SE協(xié)議》由會員分享，可在線閱讀，更多相關《《證券交易數據交換協(xié)議》SE協(xié)議（79頁珍藏版）》請在裝配圖網上搜索。

JR/T 0022—2004 目 次 前 言 III 證券交易數據交換協(xié)議 1 1 范圍 1 2 規(guī)范性引用文件 1 3 術語和定義 1 4 應用環(huán)境 2 5 會話機制 2 5.1 STEP會話 2 5.1.1 消息序號 2 5.1.2 心跳 2 5.1.3 缺口填補 2 5.1.4 消息重復發(fā)送 2 5.1.5 消息重新發(fā)送 2 5.1.6 消息確認 3 5.2 STEP連接 3 5.2.1 登錄 3 5.2.2 消息交換 3 5.2.3 注銷 3 5.2.4 消息恢復 4 6 消息格式 5 6.1 數據類型 5 6.1.1 整數int 5 6.1.2 浮點數float 6 6.1.3 單個字符char 6 6.1.4 字符串String 6 6.1.5 數據Data 6 6.2 域 6 6.2.1 域的使用 7 6.2.2 自定義域 7 6.2.3 域漢字編碼 7 6.2.4 域界定 7 6.2.5 語法 7 6.2.6 重復組 7 7 安全與加密 7 8 數據完整性 8 9 擴展方式 8 9.1 擴展分類 8 9.2 擴展規(guī)則 8 9.3 版本管理 8 10 消息定義 9 10.1 消息頭 9 10.2 消息尾 10 10.3 會話消息 10 10.3.1 心跳消息（MsgType=0） 10 10.3.2 登錄消息（MsgType=A） 11 10.3.3 測試請求消息（MsgType=1） 11 10.3.4 重發(fā)請求消息（MsgType=2） 12 10.3.5 會話拒絕消息（MsgType=3） 12 10.3.6 序號重設消息（MsgType=4） 14 10.3.7 注銷消息（MsgType=5） 15 10.4 應用消息 15 10.4.1 應用消息組件 15 10.4.2 訂單業(yè)務類 18 10.4.3 注冊類 25 10.4.4 行情 26 10.4.5 市場控制 30 11 數據字典 32 附　錄　A 應用環(huán)境參考實例 61 附　錄　B 重復組實例 62 附　錄　C 缺口填補方式 63 附　錄　D 會話連接場景 64 附　錄　E 應用消息場景 68 附　錄　F 計算校驗和 74 前 言 本標準部分內容參照了金融信息交換協(xié)議（FIX4.4）。 本標準的附錄A、B、C、D、E、F為資料性附錄。 本標準由證券交易標準化小組提出。 本標準由全國金融標準化技術委員會歸口。 本標準起草單位：中國證券監(jiān)督管理委員會信息中心承擔，上海證券交易所負責起草，深圳證券交易所、上海期貨交易所、國信證券公司、泰陽證券公司、華夏證券公司參與制訂。 本標準的主要起草人：楊淑琴、許強、陳忠蘇、丁樺、吳韶平、黃寅飛、喻華麗、萬春波、王海、黃賓、劉漢西、湯玉龍、李大鵬。 III 證券交易數據交換協(xié)議 1　 范圍 本標準規(guī)定了證券交易所交易系統(tǒng)與市場參與者系統(tǒng)之間進行證券交易所需的數據交換協(xié)議（Securities Trading Exchange Protocol，簡稱STEP），規(guī)定了應用環(huán)境、會話機制、消息格式、安全與加密、數據完整性、擴展方式、消息定義、數據字典等內容。 本標準適用于證券交易所與市場參與者和相關金融機構間的業(yè)務數據交換。 本標準提供了市場參與者內部系統(tǒng)與市場參與者協(xié)議轉換接口的連接標準以及市場參與者內部系統(tǒng)通過開放接口與證券交易所間連接標準。 本標準也可支持證券交易所與其他外部交易所間連接。 2　 規(guī)范性引用文件 下列文件中的條款通過本標準的引用而成為本標準的條款。凡是注明日期的引用文件，其隨后所有的修改單（不包括勘誤的內容）或修訂版均不適用于本標準，然而，鼓勵根據本標準達成協(xié)議的各方研究是否可使用這些文件的最新版本。凡是不注明日期的引用文件，其最新版本適用于本標準。 GB/T 2659 世界各國和地區(qū)名稱代碼 GB/T 12406 表示貨幣和資金的代碼 ISO 10383 交易所和市場代碼標志識別碼(MIC)[Codes for exchanges and regulated markets-Marked identifier Codes(MIC)] ISO 10962 證券金融票據的分類(CFI代碼)[Securities-Classification of Financial Instruments(CFI code)] 3　 術語和定義 下列術語和定義適用于本標準。 3.1　 組件塊 Component block 消息中具有一定業(yè)務相關的數據域集合，如證券品種定義，主要用于更直觀描述消息的業(yè)務含義。 3.2　 新訂單 New Order-Single 交易客戶方新產生的訂單。 3.3　 執(zhí)行報告 Execution Report 交易服務方響應交易客戶方的消息，主要用于：訂單確認、訂單狀態(tài)變化確認（如撤單確認和修改單確認）、發(fā)送訂單的成交回報、訂單拒絕。 3.4　 指定交易 Designated Trading 將證券賬號與某一證券營業(yè)部所屬的參與者業(yè)務單元（如席位號）相聯系，從而限定該證券賬號的交易應在該參與者業(yè)務單元下進行的交易方式。 3.5　 轉托管 Designation Transfer 投資者將其托管在某一券商處的證券轉到另一券商處托管的行為，并且投資者只能將證券在其托管的券商處賣出。 3.6　 公司行為 Corporate Action 上市公司的非交易類業(yè)務，如新股配售、配股認購、可轉債轉股、回售等。 3.7　 PBU（參與者業(yè)務單元） Participant Business Unit 市場參與者行使交易權利，獲取交易服務的唯一邏輯通道。 3.8　 市場參與者 Market Participants 參與證券交易的客戶方，如券商、證券公司、證券營業(yè)部、交易所會員等。 4　 應用環(huán)境 證券交易數據交換協(xié)議應用環(huán)境請參考附錄A應用環(huán)境參考實例。 5　 會話機制 5.1　 STEP會話 5.1.1　 消息序號 任何一條消息都被分配有一個消息序號來唯一標識，消息序號在每次會話過程中從1開始，在整個會話過程中連續(xù)遞增，直到該會話過程全部結束。通過監(jiān)視消息序號的連續(xù)性可以知道交換中的消息缺口，并做出反應，使得連接雙方數據同步。 連接雙方都明確確定相互獨立的消息序號，參與連接的任何一方負責維護自己發(fā)送的消息序號，并監(jiān)視接收的消息序號以保證消息缺口的發(fā)現和處理。 5.1.2　 心跳 在消息交換的空閑期間，連接雙方將會產生有規(guī)則的心跳消息。通過心跳消息可以監(jiān)控通訊連接的狀態(tài)。心跳間隔時間由會話發(fā)起人在登錄時確定。在發(fā)送任何消息后，應立即重新設置心跳間隔計時器。心跳間隔時間應該得到連接雙方的確認，由登錄發(fā)起人給出并得到登錄接受方的確認。連接雙方使用相同心跳間隔時間。 5.1.3　 缺口填補 由于協(xié)議是基于樂觀的消息傳輸模式，消息在傳輸過程中可能存在丟失，而這種消息丟失發(fā)送方不能檢測，因此接收方應負責檢測消息的缺口并處理。有兩種處理方法：接收方發(fā)現缺口后向發(fā)送方請求發(fā)送缺口消息及其后的所有消息；接收方發(fā)現缺口后，保存已收到消息，并向發(fā)送方請求重復發(fā)送缺口消息。 5.1.4　 消息重復發(fā)送 響應一個重發(fā)請求而重復發(fā)送消息時，或者不確定對方是否收到某消息而重復發(fā)送該消息時，要求在該消息內加上可能重復標志（Possible Duplicate=Y）。如何處理該消息則是接收方的事情。由于當生成有此類可能重復發(fā)送的消息時，仍使用該消息的原來序號，但某些信息可能會改變，如原始時間、發(fā)送時間、正文長度、可能重復標志等，所以應重新計算校驗和。 5.1.5　 消息重新發(fā)送 基于應用層的可能重發(fā)，如發(fā)送的訂單在相當長的時間內沒有確認，或者懷疑其根本未曾發(fā)送過，可以通過設置可能重新發(fā)送標志來重新發(fā)送(Possible Resend=Y) ，并使用新的消息序號。接收方應用層收到該類消息后，應通過查詢消息內的域（如訂單編號等）來確定此前是否收到此條消息。該類消息應確定包含相同的正文數據，同樣，由于某些信息可能會改變，所以應重新計算校驗和。 5.1.6　 消息確認 由于協(xié)議是基于樂觀的消息傳輸模式，通過監(jiān)視消息序號發(fā)現缺口，不支持對每個消息收發(fā)的確認。但大量消息收發(fā)的確認可在應用層定義。在應用層接受和拒絕是允許的，如訂單的確認。 5.2　 STEP連接（會話） 會話過程的數據交換可以這樣描述：連接雙方各有一個連續(xù)的消息序號隨消息傳送，而交易期間可以多次斷開并重新連接，其斷開的原因可以是外因引起，也可以是連接雙方根據系統(tǒng)來統(tǒng)一制定何時斷開并重新連接。一次會話連接通常不應超過24小時，當然，如需要保持24小時以上的連接，則需要發(fā)送一條含有序號重設標志的登錄消息來建立新的起始消息序號。 STEP連接分為三個部分：登錄、消息交換、注銷。 STEP會話包含一個或多個STEP連接，即一個STEP會話可以跨越多個登錄。 5.2.1　 登錄 登錄連接包含三個步驟：建立電信通訊連接、連接雙方的確認/認證、消息傳輸同步的初始化。主要有以下幾點： 5.2.1.1　 連接 會話的發(fā)起方與接收方建立電信通訊連接。 5.2.1.2　 認證 發(fā)起方發(fā)送登錄消息（Logon），接收方認證發(fā)起方身份的合法性。登錄消息應包括認證的必要數據，如用戶名、密碼等。如果發(fā)起方身份通過認證，則接收方發(fā)送一個登錄消息作回應。如果認證失敗，會話接收方則在發(fā)送一個含失敗說明的注銷消息（Logout）后關閉連接。不過發(fā)送注銷消息并非是必須的，因為在某些情況下往往會引起其他問題。在發(fā)起方收到接收方的登錄消息之后即可認為會話連接建立完成。會話發(fā)起方可以緊隨登錄消息之后開始發(fā)送其他消息。 通常在登錄后或者剛發(fā)送完測試請求消息（TestRequest）時延遲等待一段時間，然后再發(fā)送新的消息，使得連接雙方能有效控制重發(fā)請求。否則可能會導致一方會針對對方的每一條新消息發(fā)出重發(fā)請求。 5.2.1.3　 初始化 在身份通過認證之后，發(fā)起方和接收方應首先同步消息序號，然后才能相互發(fā)送新的信息。同步消息序號通過消息序號域（MsgSeqNum）來確定，將登錄消息里的消息序號（MsgSeqNum）與內部監(jiān)控的下一個預期的消息序號進行比較就能發(fā)現消息的消息序號缺口。同樣，發(fā)起方通過將接收方發(fā)送的登錄消息里的消息序號（MsgSeqNum）與下一個預期的消息序號進行比較也能發(fā)現消息的缺口。 5.2.2　 消息交換 在以上初始化完成之后，可以開始進行信息交換。所有有效消息的格式將在“會話消息”和“應用消息”部分中詳細敘述。 5.2.3　 注銷 會話的正常結束是通過連接雙方互相發(fā)送注銷消息（Logout）完成的。若結束時沒有收到回送的注銷消息（Logout），則把對方視作已注銷。除此之外的其它方式的會話結束視為非正常，并應按錯誤來處理。 在發(fā)送注銷消息（Logout）之前，應發(fā)送測試請求消息（TestRequest）以要求對方的心跳信息，這有助于保證不出現消息序號缺口。 在結束會話之前，注銷消息（Logout）的發(fā)起方應該等待對方回送的注銷消息（Logout），這樣給接收方一個填補缺口的機會。待重發(fā)請求的信息全部收到后，接收方才可發(fā)送應答的注銷消息（Logout）。如果接收方在一定時間內沒有答復，那么會話就可以立即中斷。（注注：注銷不影響任何訂單的狀況。所有有效的訂單都可在注銷（Logout）之后執(zhí)行。 ） 5.2.4　 消息恢復 以下描述了有關恢復消息的具體方法。 每一方必須維護兩個消息序號，一個為了發(fā)送，一個為了接收。 當接收進來的消息序號與預期的消息序號不相符合時，需進行修正處理。但需要注意的是，如果接收進來的是序號重設-重設（SeqReset-Reset）消息則不需要修正處理，因為處理該消息時不必考慮它的消息序號。如果接收的消息的消息序號比預期的消息序號小，而且沒有設置可能重復標志（PossDupFlag），那么表明發(fā)生了嚴重的錯誤。因此必須立即結束會話，并開始進行人工干預。如果接收進來的消息序號比預期的大，那么表明有消息被遺漏，應通過發(fā)送重發(fā)請求申請?zhí)钛a缺口。 當收到重發(fā)請求時，重發(fā)人可以作出回應為以下三種之一：（注注：本文中請求人指的是提出重發(fā)請求的那一方，重發(fā)人指的是回應重發(fā)請求的那一方。 ） a) 作為正?；貞匕l(fā)人按順序發(fā)送被請求的消息，這些消息的消息序號仍為原消息序號，并且將可能重復的標志（PossDupFlag）置位為“Y”。 b) 作為正?；貞?，重發(fā)人發(fā)送序號重設-缺口填補（SeqReset-GapFill）消息，可能重復標志（PossDupFlag）置位為“Y”，以表示刪除過時或多余的消息。 c) 作為非正?；貞匕l(fā)人發(fā)送序號重設-重設（SeqReset-Reset）消息，可能重復的標志（PossDupFlag）置位為“Y”，以強制消息序號同步。 在缺口填補過程中，不需要重新發(fā)送某些會話消息。取而代之的是一種特殊的序號重設-缺口填補（SeqReset-GapFill）消息。不需要重新發(fā)送的會話消息是：登錄、注銷、重發(fā)請求、心跳、測試請求、序號重設-重設（SeqReset-Reset ）和序號重設-缺口填補（SeqReset-GapFill）。這樣會話拒絕消息便成為了唯一可能被重新發(fā)送的會話消息。 會話過程中應監(jiān)視接收進來的消息以便發(fā)現由于疏漏而被對方重新發(fā)送了的會話消息（設置了可能重復標志（PossDupFlag）的）。當收到這些消息以后，處理時，只要確保它們具有消息序號的完整性即可，而忽略對它們的業(yè)務或應用的處理。 如果碰到多個連續(xù)的不需要重發(fā)的會話消息，則只需發(fā)送一個序號重設-缺口填補（SeqReset-GapFill）消息取而代之。該序號重設-缺口填補消息的消息序號是下一個預期的消息序號。序號重設-缺口填補（SeqReset-GapFill）消息的新消息序號（NewSeqNo）為本連續(xù)會話消息段中最大消息序號+1。（注注：如在重新發(fā)送操作期間，有7條連續(xù)的會話消息等待發(fā)送，他們以消息序號9開始和以消息序號15結束，此時只發(fā)送一個序號重設-缺口填補（SeqReset-GapFill）消息來代替那7條消息，那么該序號重設-缺口填補（SeqReset-GapFill）消息的消息序號是9，這是因為要承接上條消息而保持消息序號的連續(xù)性；其中新消息序號（NewSeqNo）是16，這樣使得對方知道下一消息發(fā)送時的消息序號。 ） 在缺口被填補完成之后，交換引擎應將無序的消息暫時保存為有序的排列并按順序對它們進行處理。這樣防止出現對n->m,n->m+1,n->m+2,…的重發(fā)請求，從而導致了大量的可能重復（PossDupFlag=’Y’）標記。 檢驗消息序號的連續(xù)在會話過程管理中是必不可少的部分。不過，針對消息類型的不同，處理消息序號流的差異也就不同。下列的表１列出了當進來的消息序號大于預期消息序號時而應采取的措施。 （注注：在任何情況下，除了序號重設－重設消息外，如果進來的消息序號比預期的消息序號小，而且可能重復標志（PossDupFlag）沒有被設置，那么應立即終止會話過程。并應在結束會話之前，向對方發(fā)送帶有解釋正文的注銷（Logout）消息。 ） 表１ 消息類型 針對消息序號錯誤所采取的措施 登錄 永遠是連接雙方發(fā)送的第一條消息，用于認證和連接。如果發(fā)現登錄消息中有缺口，則應在回送登錄確認消息之后立即發(fā)送重發(fā)請求 注銷 如果發(fā)現有缺口，應發(fā)送重發(fā)請求消息以重新接收所有丟失的消息，然后再發(fā)送注銷消息作為對注銷請求的確認。注意嚴禁在有缺口情況下結束會話。并由注銷的最初發(fā)起人負責結束會話，因此注銷發(fā)起人有責任回應所有的重發(fā)請求 重發(fā)請求 首先處理完對方的重發(fā)請求，隨后發(fā)送自己的重發(fā)請求以填補消息序號錯誤而發(fā)現的消息缺口。 序號重設-重設 可以忽略消息序號錯誤。因為在序號重設-重設（SeqReset-Reset）消息中的新消息序號（NewSeqNo）強制為下一發(fā)送消息的消息序號。 序號重設-缺口填補 應立即向對方發(fā)送重發(fā)請求。但是，重要的是要確保沒有無意間跳過任何消息，這意味著缺口填補消息應按次序被接收到，如果次序不對，那么表示出現了非正常的情況 所有其它信息 執(zhí)行正常的缺口填補。 6　 消息格式 6.1　 數據類型 數據類型用于定義數據域的取值類型，本標準由幾個基本的數據類型（整數、浮點數、單字符、字符串、二進制數據塊）和在此基礎上擴展的數據類型組成。除“data”數據類型外，其他數據類型均以ASCII碼字符串表示。 6.1.1　 整數int 無逗號和小數位的序號，可表示正負（ASCII碼字符‘-’,‘0’至‘9’組成）。符號占據一個字符位置。允許前置字符零（例：“00023”=“23”）。 整數類型的擴展定義： 長度Length:以整數表示字節(jié)為單位的數據長度，正數。 重復數NumInGroup:以整數表示重復組的個數，正數。 消息序號SeqNum:以整數表示消息序號，正數。 域號TagNum:以整數表示的域號（或稱Ｔａｇ），正數，首位不能為零。 月日期號 DayOfMonth：以整數表示的月份中第幾天，取值1至31。 6.1.2　 浮點數float 含有可選的小數部分，可表示正負（ASCII碼字符‘-’,‘0’至‘9’和‘.’組成）。最多15位有效數字。允許前置字符零（例：“00023”=“23”）。允許小數部分后置字符零（例：“23.0”=“23.0000”=“23”）。 浮點數類型的擴展定義： 除非特別聲明，浮點數類型均有正負。 量Qty: 股份數量、資產數量等，可以有小數部分。 價格Price:小數位數可變。 價格偏移量PriceOffset:代表價格偏移量的浮點域。 金額Amt: 典型的價格與數量相乘結果，如成交金額。 百分比Percentage:小數表示方法：.05代表5%。 6.1.3　 單個字符char 指除界定符外所有字母字符和標點字符，區(qū)分字母大小寫。 字符類型的擴展定義： 布爾Boolean: 該域取值于兩個字符，（’Y’=True/Yes,’N’=False/No） 6.1.4　 字符串String 區(qū)分字母大小寫。 字符串類型的擴展定義： 多元值字符串MultipleValueString: 用空格分隔。 國家Country: 參見GB/T 2659。 字符串貨幣類型Currency: 參見GB/T 12406。 交易所或市場編號Exchange: 字符串，參見ISO10383。 年月日期month-year: 格式YYYYMM或YYYYMMDD或YYYYMMWW，YYYY = 0000-9999, MM = 01-12，DD = 01-31，WW = w1,w2,w3,w4,w5。 國際標準時時間戳UTCTimestamp: 格式 YYYYMMDD-HH:MM:SS(秒)或 YYYYMMDD-HH:MM:SS.sss（毫秒）， YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (秒)，sss=000-999 (毫秒)。 國際標準時時間UTCTimeOnly:格式 HH:MM:SS或HH:MM:SS.sss， HH = 00-23, MM = 00-59, SS = 00-60 (秒)，sss=000-999 (毫秒)。 國際標準時日期UTCDateOnly:格式 YYYYMMDD， YYYY = 0000-9999, MM = 01-12, DD = 01-31。 本地市場日期LocalMktDate: 格式YYYYMMDD，YYYY = 0000-9999, MM = 01-12, DD = 01-31。 6.1.5　 數據Data 無格式和內容限制的原始數據，包含長度域和數據域兩個部分，數據域數據可以包含數值0x01，長度域指明數據域的字節(jié)數。 6.2　 域 域是基本的數據元素，每個域有其域號、業(yè)務含義和確定的取值范圍，域號統(tǒng)一分配給不同的域，是域的區(qū)分標志，在消息中，通過域號來確定不同的域。域的數據類型決定了其取值類型，域的取值范圍可以是一個集合，任何在此集合外的取值被認為是非法取值。數據字典部份詳細定義了所有域的業(yè)務定義、數據類型和取值范圍。 6.2.1　 域的使用 在消息中，域的使用有三種方式：必須的，可選的，條件限制選擇（即根據其他相關域的存在與否或取值來決定）。作為一個完整的消息，必須域和條件限制選擇域是需要包含的。 6.2.2　 自定義域 如本標準中定義的域不夠使用時，證券交易所或市場參與者可以擴展定義新的域，即自定義域。 6.2.3　 域漢字編碼 域取值為漢字時需要使用統(tǒng)一的GBK漢字編碼標準，。 6.2.4　 域界定 消息中所有的域（包含data類型數據域）都有一個分隔符來界定分隔，該分隔符就是不可打印字符ASCII碼“SOH”(#001，hex：0x01，本文檔中以表示)。因此，所有消息以“8=STEP.x.y.z”字符串開始并以“10=nnn”字符串結束。 除data數據類型域外，其他數據域內容都不應包含域界定符。 6.2.5　 語法 任何消息都嚴格由多個“域號=值”的基本結構組成，“域號=值”基本結構用域界定符分隔。消息組成結構如圖１： 圖１：消息格式 消息由消息頭、消息的正文和消息尾組成。同樣，每個組成部份都由一系列“域號=值”組成，并且在遵循以下規(guī)則前提下“域號=值”基本結構可以是任意的次序： a) 開始部分應是消息頭，隨后是正文，最后是消息尾； b) 消息頭的前3個域的次序不能改變：起始串（Tag =8）、消息體長度（Tag =9）、消息類型（Tag =35）； c) 消息尾的最后一個域應是校驗和域（Tag =10）； d) 重復組中，域出現的順序應遵循該重復組在消息或組件中定義時的次序。 e) 在一條消息中，除重復組域外任何其他域不能重復出現。 （消息格式的例子見注注： ８＝ＳＴＥＰ．１．０．０＜ＳＯＨ＞９＝１１２＜ＳＯＨ＞３５＝Ｄ＜ＳＯＨ＞４９＝ＢＲＫＲ＜ＳＯＨ＞５６＝ＩＮＶＭＧＲ＜ＳＯＨ＞３４＝２３５＜ＳＯＨ＞５２＝２００３０６２０－０９：３５：２７＜ＳＯＨ＞１１＝０００００７＜ＳＯＨ＞２１＝２＜ＳＯＨ＞５５＝青島啤酒＜ＳＯＨ＞４８＝６００６００＜ＳＯＨ＞ ５４＝１＜ＳＯＨ＞４４＝８．５２０ ＜ＳＯＨ＞ ３８＝１０００ ＜ＳＯＨ＞ ６０＝２００３０６２０－０９：３５：２８＜ＳＯＨ＞４０＝２＜ＳＯＨ＞１０＝１５７＜ＳＯＨ＞ ） 6.2.6　 重復組 域可以在重復組里多次重復，用以傳輸數組類的數據。通常域名起始為’No’字符的域指明重復的次數，并位于重復組的開始處。本文檔中重復組的定義通過縮進的符號表示，重復組也可嵌套。使用子重復組時不能省略父重復組。 具體可參考附錄B重復組實例。 7　 安全與加密 由于消息有可能在公網或不安全的網絡上傳輸交換，因此需要對相關的敏感數據加密處理。 具體加密的方法由連接雙方達成的協(xié)議而定。 消息內除某些需要公開識別的域以明文傳輸外其他任何域都可以加密放置密文數據域（SecureData）內。當然，這些被加密的域也可以同時保留明文的表示方式。 當決定使用加密方案時，可以對消息正文內所有的域加密。如果消息的重復組內有部分需要加密的，那么要求對整個重復組加密。 本協(xié)議還提供的一些域用以支持數字簽名、密鑰交換和正文加密等安全技術。 正文加密方案有三種： a) 將安全敏感的域加密后移至SecureData域。 b) 將所有允許加密的域加密后移至SecureData域。 c) 將所有允許加密的域加密后移至SecureData域，同時這些域以明文在消息中重復出現。 8　 數據完整性 數據的完整性通過兩個方法保證：消息體長度和校驗和的驗證。 消息體長度是以BodyLength域來表示，其值是計算出的消息長度域后面的字符數，包含緊靠校驗和域標志‘10=’之前的界定符SOH。 校驗和是把每個字符的二進制值從消息開頭‘8=’中的‘8’開始相加，一直加到緊靠在校驗和域‘10=’之前的域界定符，然后取按256取模得到的結果。 校驗和域位于消息的最末 一個，校驗和的計算是在加密之后進行的。計算校驗和的代碼段可參考附錄F計算校驗和。 9　 擴展方式 9.1　 擴展分類 擴展分為兩個部分：消息定義擴展和域定義擴展。 消息定義擴展可以通過新增消息類型來實現，但盡量在已有消息中通過域定義或取值擴展來定義新業(yè)務。已有消息所代表的業(yè)務在擴展時不能改變。 域定義擴展可以通過新增域來實現，但盡量通過擴展域值來擴展域的定義。消息中已定義的必須的域不能取消定義，也不能改變成可選域。 9.2　 擴展規(guī)則 自定義消息的消息類型值首字符為‘U’。其他類型的消息由全國金融標準化技術委員會根據國際相關標準的變化統(tǒng)一定義并發(fā)布。 消息和域臨時定義原則：上海證券交易所臨時定義消息的消息類型值首兩位字符為‘UA’，深圳證券交易所臨時定義消息的消息類型值首兩位字符為‘UB’；消息和域的臨時定義應同時報備至全國金融標準化技術委員會。 域號1-4999由全國金融標準化技術委員會根據國際標準的變化統(tǒng)一定義并發(fā)布，該域區(qū)間只有全國金融標準化技術委員會有權擴展、修改和發(fā)布；域號8500-8999由全國金融標準化技術委員會自行定義，其中8800-8999為臨時定義區(qū)間；臨時定義區(qū)間中域號8800-8899為全國金融標準化技術委員會授權上海證券交易所市場臨時定義區(qū)間，域號8900-8999為全國金融標準化技術委員會授權深圳證券交易所市場臨時定義區(qū)間。域號10000以上由連接雙方自行約定定義。 消息的模塊順序在擴展定義時不能改變，即保持消息頭、消息體和消息尾的順序。而模塊的內部，域和重復組的順序是可以變化的。 消息頭的頭三個域的定義和位置不能改變，但可以擴展增加消息頭的可選域。 消息尾最后一個域的定義和位置不能改變，但可以擴展增加消息尾的可選域。 9.3　 版本管理 本協(xié)議的版本管理權屬于全國金融標準化技術委員會。 版本號格式為X.Y.Z，版本號從1.0.0起始，當新版本完全兼容上一版本時只改變版本號中的Z。 本協(xié)議當前版本的版本號為1.0.0。 全國金融標準化技術委員會定期審核臨時定義，并在新版本中統(tǒng)一定義發(fā)布，同時取消相關臨時定義。 10　 消息定義 10.1　 消息頭 每一個會話或應用消息有一個消息頭，該消息頭指明消息類型、消息體長度、發(fā)送目的地、消息序號、發(fā)送起始點和發(fā)送時間。 其中有兩個域用于消息重發(fā)，對于會話級的事件而重復發(fā)送消息時將可能重復發(fā)送標志(PossDupFlag)設置為Y（發(fā)送時用原來的消息序號），當重新發(fā)送時使用新的消息序號時將可能重新發(fā)送標志（PossResend）設置為Y，接受者應按以下方法處理上述消息： 可能重復發(fā)送：如果帶有該消息序號的消息在以前曾經接受過，則忽略消息，如果未曾收到過，則按正常步驟處理。 可能重新發(fā)送：將消息傳遞給應用層以確定此前是否收到該消息（通過檢查訂單編號或相關參數）。 消息頭格式見表２： 表２　消息頭 Tag 域名 必需 說明 8 BeginString Y 起始串STEP.1.0.0 (不可加密，消息的第一個域) 9 BodyLength Y 消息體長度(不可加密，消息的第二個域) 35 MsgType Y 消息類型(不可加密，消息的第三個域) 49 SenderCompID Y 發(fā)送方代碼(不可加密，發(fā)送方標識符) 56 TargetCompID Y 接收方代碼(不可加密，接收方標識符) 115 OnBehalfOfCompID N 最初發(fā)送方標識符（可加密），用于經第三方發(fā)送。 128 DeliverToCompID N 最終接收方標識符（可加密），用于經第三方發(fā)送。 90 SecureDataLen N 密文數據長度 91 SecureData N 密文數據（緊跟密文數據長度域） 34 MsgSeqNum Y 消息序號（可加密） 50 SenderSubID N 發(fā)送方子標識符（可加密） 142 SenderLocationID N 發(fā)送方方位標識符（可加密） 57 TargetSubID N 接收方子標識符（可加密） 143 TargetLocationID N 接收方方位標識符（可加密） 116 OnBehalfOfSubID N 最初發(fā)送方子標識符（可加密） 144 OnBehalfOfLocationID N 最初發(fā)送方方位標識符（可加密） 129 DeliverToSubID N 最終接收方子標識符（可加密） 145 DeliverToLocationID N 最終接收方方位標識符（可加密） 43 PossDupFlag N 可能重復標志，重復發(fā)送時，作此標記。（可加密） 97 PossResend N 可能重發(fā)標志。（可加密） 52 SendingTime Y 發(fā)送時間（可加密） 122 OrigSendingTime N 原始發(fā)送時間（可加密） 347 MessageEncoding N 消息中Encoded域的字符編碼類型（非ASCII碼） 表２（續(xù)）　消息頭 Tag 域名 必需 說明 369 LastMsgSeqNumProcessed N 最后處理消息序號（可加密） 370 OnBehalfOfSendingTime N 最初發(fā)送時間（用UTC表示時間） 627 NoHops N 歷史跳躍信息重復組，記錄消息經第三方發(fā)送的歷史，每次經第三方發(fā)送為一個跳躍，僅當OnBehalfOfCompID使用時有效，主要用于跟蹤消息的路徑。 628 HopCompID N 取值第三方的SenderCompID 629 HopSendingTime N 取值用第三方的SendingTime 630 HopRefID N 取值第三方的MsgSeqNum 10.2　 消息尾 每一個消息（會話或應用消息）有一個消息尾，并以此終止。消息尾可用于分隔多個消息，包含有3位數的校驗和值。 消息尾格式見表３： 表３　消息尾 Tag 域名 必需 說明 93 SignatureLength N 數字簽名長度（不可加密） 89 Signature N 數字簽名（不可加密） 10 CheckSum Y 校驗和，消息的最末域。（不可加密） 10.3　 會話消息 會話消息涉及標準的使用機制，將在以下各節(jié)中予以介紹，并定義會話消息格式。 連接雙方均可生成會話消息。 10.3.1　 心跳消息（MsgType=0） 心跳消息用于監(jiān)控通信連接的狀況，并可確認是否接收到最后一條消息。 當STEP連接的任何一方在（[HeartBtInt] 秒，心跳間隔）時間內沒有發(fā)送任何數據的時候，將產生一個心跳消息并傳送出去。當連接的任何一方在（[HeartBtInt]＋[合理傳輸時間] ）時間內都沒有收到任何有關的數據的時候，將產生一個測試請求消息并傳送出去。如果在此之后的（[HeartBtInt]＋[合理傳輸時間] ）時間內，仍沒有收到心跳消息，那么可認為此次連接失敗，而且需開始實施修正操作。如果 HeartBtInt 被設置為零，那么將不會定期生成心跳消息。并且不論 HeartBtInt 取值多少，任何一方都可發(fā)送測試請求消息，接收方由此將強行生成心跳消息。 因對方的測試請求消息而產生的心跳（Heartbeats）消息應包括對方測試請求消息中的測試請求標識符（TestReqID）。這有利于確定該心跳消息是響應測試請求而產生的，而不是由于超時而產生的。 心跳消息格式見表４： 表４　心跳（Heartbeat） Tag 域名 必需 說明 標準消息頭 Y MsgType = 0 112 TestReqID N 測試請求標識符，如是對測試請求而響應的心跳消息，則應包含本域。 標準消息尾 Y 10.3.2　 登錄消息（MsgType=A） 登錄消息能證實用戶是否已建立與對方系統(tǒng)的連接。登錄消息應是在STEP會話開始時的連接雙方發(fā)送的第一個消息。 HeartBtInt域用來聲明產生心跳的時間間隔（連接雙方HeartBtInt取相同的值）。連接雙方事先約定取值，由登錄發(fā)起方產生并得到接收方的確認響應。 在接收登錄消息時，接收方將驗證發(fā)起方身份的合法性，并且同樣發(fā)出登錄消息以確認連接請求已被接受。同樣，確認登錄消息也可以被發(fā)起方使用以驗證連接了身份合法的接收方。 接收方應在收到登錄消息之后，立即作好開始消息處理的準備。發(fā)起方可以選擇在接收到確認登錄消息之前開始STEP消息傳輸。不過本標準規(guī)定：在有關密鑰確認的登錄消息收到之后，才實施正常的消息交換。 確認登錄消息還可被用于密鑰相互確定。如果認為當前會話密鑰強度較弱，需要更換密鑰，那么就可通過發(fā)回帶有新密鑰的登錄消息來建議使用更強的會話密鑰。當然，這僅僅對允許密鑰相互確認的加密協(xié)議有意義。 登錄消息還可以用來指明最大消息長度（MaxMessageSize），也可以用來指明發(fā)送和接受時所支持的消息類型。 登錄消息格式見表５： 表５　登錄（Logon） Tag 域名 必需 說明 標準消息頭 Y MsgType = A 98 EncryptMethod Y 加密方法(不可加密) 108 HeartBtInt Y 心跳間隔 95 RawDataLength N 無格式數據長度，用于認證 96 RawData N 無格式數據，用于認證 141 ResetSeqNumFlag N 序號重設標志 383 MaxMessageSize N 最大消息長度，單條消息的最大字節(jié)數 384 NoMsgTypes N 消息類型個數 372 RefMsgType N 消息類型 385 MsgDirection N 消息方向 464 TestMessageIndicator N 測試標志，指明該會話是測試連接或正常運行連接，用于防止意外 553 Username N 用戶名 554 Password N 密碼 標準消息尾 Y 10.3.3　 測試請求消息（MsgType=1） 測試請求消息能強制對方發(fā)出心跳消息。測試請求消息的作用是檢查對方消息序號和檢查通信線路的狀況。對方用帶有測試請求標識符（TestReqID）的心跳作應答。 測試請求標識符（TestReqID）用以指明對方生成心跳消息是響應測試請求而非正常超時引起的。對方發(fā)送心跳消息作為應答時，將測試請求標識符（TestReqID）包括在消息中。任何字符串都可以用作測試請求標識符（TestReqID）（可使用時間戳（timestamp））。 測試請求消息格式見表６： 表６　測試請求（Test Request） Tag 域名 必需 說明 標準消息頭 Y MsgType = 1 112 TestReqID Y 測試請求標識符 標準消息尾 Y 10.3.4　 重發(fā)請求消息（MsgType=2） 重發(fā)請求消息由接收方發(fā)出，目的是向發(fā)送方申請某些消息重復發(fā)送。此功能用于：發(fā)現消息序號缺口、接收方丟失了消息和在初始化過程中也可能使用。 重發(fā)請求消息能被用來請求重新發(fā)送單個消息、一系列的消息或在某一特定消息之后的所有消息。 當重復發(fā)送消息的時候，發(fā)送方將考慮消息類型；如：在重復發(fā)送系列中有一條會話消息，由于過期而不再有效，發(fā)送方不需要重復傳輸這條消息。因此，當發(fā)送方不重復發(fā)送某消息時，序號重設-缺口填補（SeqReset-Gap Fill）消息將被用來跳過消息。（注注：接收方按訂單順序進行消息處理是非常有必要的。例如，如果訂單第7條消息被錯過，而收到第8和第9條，那么應用方將忽略8和9，然后要求重發(fā)送第7-第9，或者要求重新發(fā)送第7-第0（0表現無限）。在順序混亂的狀況中通常用后一方案恢復消息，因為當連接雙方都同時試圖盡快恢復缺口的狀況下，此種方法能更快地進行消息恢復。 ） 重發(fā)請求消息有以下幾種表示方式： l 請求重發(fā)一條消息：起始消息序號（BeginSeqNo）=結束消息序號（EndSeqNo） l 請求重發(fā)某個范圍內的消息：起始消息序號（BeginSeqNo）=該范圍中的第1條消息，結束消息序號（EndSeqNo） =該范圍中的最后一條消息序號 l 請求重發(fā)某一特定消息之后的所有的消息：起始消息序號（BeginSeqNo）=該范圍中的第1條消息，結束消息序號（EndSeqNo） =0（無限大）。 重發(fā)請求消息的格式見表７： 表７　重發(fā)請求（Resend Request） Tag 域名 必需 說明 標準消息頭 Y MsgType = 2 7 BeginSeqNo Y 起始消息序號 16 EndSeqNo Y 結束消息序號 標準消息尾 Y 10.3.5　 會話拒絕消息（MsgType=3） 當接收方收到一條消息時，由于違反了會話機制而造成不能適當地處理該消息時，應該發(fā)出會話拒絕消息。如：當收到一條消息，這條消息雖成功地通過了解密、校驗和和正文長度檢驗，但卻被發(fā)現帶有無效的數據（如：消息類型（MsgType）=&），此時應發(fā)出拒絕消息。 被拒絕的消息應該寫入日志。 接收方應該忽略任何被歪曲，不能被解析，或數據完整性核對失敗的消息。立即對下一個有效的STEP消息進行處理將會發(fā)現消息缺口，并且，將產生重發(fā)請求。在STEP交換引擎內應能夠識別這種無限重發(fā)循環(huán)。 當產生和收到會話拒絕消息意味著出現了嚴重錯誤，可能發(fā)送方或接收方的應用存在邏輯錯誤。 如果要重新傳輸拒絕消息，那么應賦予該消息一個新的消息序號，并設置可能重發(fā)標志（PossResend）為Y。 無論何時，本標準規(guī)定應在正文域里盡可能描述拒絕原因。 如果所收到的應用層消息遵循了會話機制，那么可以開始在業(yè)務層處理該消息。如果在處理過程中，發(fā)現違反業(yè)務規(guī)則，那么應該發(fā)出業(yè)務層的“拒絕”消息。很多業(yè)務層的消息都有指定的“拒絕”消息，此時這些消息可以發(fā)揮作用。其它無對應會話拒絕消息的，則均可通過業(yè)務“拒絕”消息進行拒絕。 會話拒絕消息格式見表８： 表８　會話拒絕（Reject） Tag 域名 必需 說明 標準消息頭 Y MsgType = 3 45 RefSeqNum Y 關聯消息序號，即被拒絕的消息序號 371 RefTagID N 相關錯誤域號 372 RefMsgType N 相關錯誤消息類型 373 SessionRejectReason N 會話拒絕原因編號 58 Text N 文本，可作解釋拒絕的原因 354 EncodedTextLen N 編碼文本長度 355 EncodedText N 編碼文本（非ASCII碼） 標準消息尾 Y 會話拒絕原因見表９： 表９　會話拒絕原因 會話拒絕原因 0 = 存在無效的域號 1 = 該消息中必須的域丟失 2 = 該消息中出現未曾定義的域 3 = 未定義域號 4 = 域未賦值 5 = 域取值錯誤（范圍溢出） 6 = 取值格式錯誤 7 = 解密錯誤 8 = 簽名錯誤 9 = 公司標識符錯誤 10 = 發(fā)送時間精度錯誤 11 = 無效的消息類型 12 = XML驗證錯誤（XML Validation error） 13 = 同一域多次出現（非重復組） 14 = 有序的域出現次序錯誤 15 = 重復組域次序錯誤 16 = 重復組重復次數錯誤 17 = 非data數據域中出現域界定符 10.3.6　 序號重設消息（MsgType=4） 序號重設消息由發(fā)送方發(fā)出，用于告知接收方下一個消息的消息序號。序號重設消息有兩種模式：序號重設-缺口填補（SeqReset-Gap Fill）；序號重設-重設（SeqReset -Reset）。序號重設-重設通常在災難恢復情況下使用。 當需要支持24小時的連接并用序號重設標志（ResetSeqNumFlag）來建立新的一套消息序號的時候，關于連接雙方的序號重設時間和發(fā)起方另行確定，但序號重設的發(fā)起方不同于登錄過程的發(fā)起方。其處理過程如下：其中一方先發(fā)送測試請求（TestRequest）。在收到心跳消息后，確認沒有消息序號缺口后，發(fā)起方發(fā)送一條登錄消息，在該消息中應附有設為Y的序號重設標志（ResetSeqNumFlag），并且它的消息序號（MsgSeqNum）為1。接收方則應該發(fā)送一條登錄消息作回應，其中序號重設標志（ResetSeqNumFlag）為Y，消息序號（MsgSeqNum）為1。此后，連接雙方發(fā)送出的消息的消息序號應從2 開始。需要注意的是一旦發(fā)起方發(fā)送附有序號重設標志（ResetSeqNumFlag）的登錄消息，那么接收人應服從該請求，并且，“昨天”傳送的消息不可能再重發(fā)。如果不遵守以上的處理規(guī)則應立即中斷連接，并手工設置干預。 序號重設消息兩種模式表示： 當GapFillFlag＝Y時，該消息為序號重設-缺口填補（SeqReset-Gap Fill），當GapFillFlag＝N或沒有設置時，該消息為序號重設-重設（SeqReset-Reset）。 序號重設消息能在下列情況下使用： a) 在重新發(fā)送的處理過程中，發(fā)送方可以選擇不發(fā)送某個消息（例如一個會話消息）。序號重設-缺口填補（SeqReset-Gap Fill）能被用來填補那條消息。 b) 在重新發(fā)送的處理過程中，有大量的會話消息不需要發(fā)送，這樣產生的消息序號缺口也可以由序號重設-缺口填補（SeqReset-Gap Fill）消息來填補。 c) 在應用層失敗的情況下，有必要通過發(fā)送序號重設-重設（SeqReset-Reset）在發(fā)送和接收的連接雙方進行強制消息序號同步。 在任何情況下，序號重設消息都指定了NewSeqNo（新的消息序號），并重設該值為下一個將被傳送消息的消息序號。 如果缺口填補標志（GapFillFlag）域被設置為Y，那么消息序號（MsgSeqNum）域取值應該遵循消息序號規(guī)則，即：序號重設-缺口填補（SeqReset-Gap Fill）消息的消息序號（MsgSeqNum）應該對應缺口范圍內第一條消息的消息序號，因為對方正準備接收這個消息序號的消息。 序號重設-缺口填補（SeqReset-Gap Fill）只能增加消息序號。如果收到的序號重設-缺口填補（SeqReset-Gap Fill）消息試圖使下一個預期的消息序號變小，那么此消息應該被拒絕接受，并被視作為錯誤。（注注：如可能存在接收方發(fā)送多個重發(fā)請求（如先請求重發(fā)5～10，隨后請求重發(fā) 5～11）。如果消息序號8，10和11表示應用消息，而5-7和9表示會話消息，那么為響應該重發(fā)請求，有一些應用消息需被重新發(fā)送，首先發(fā)送的SeqReset-GapFill中新消息序號（NewSeqNo）設置為8，即第8條消息；完成重發(fā)應用消息后，發(fā)送SeqReset-GapFill且新消息序號（NewSeqNo）設置為10，即第10條消息，接著完成重發(fā)應用消息。隨后又可能發(fā)送SeqReset-GapFill且新消息序號（NewSeqNo）設置為8，即第8條消息（序號變小）；完成重發(fā)應用消息后，發(fā)送SeqReset-GapFill且新消息序號（NewSeqNo）設置為10，即第10條消息，以及第11條消息，接著完成重發(fā)應用消息。此時接收方通過檢查在序號重設-缺口填補（SeqReset-Gap Fill）中的新消息序號（NewSeqNo）是否比預期的小可發(fā)現此種錯誤。如果發(fā)現有這種錯誤，那么說明該序號重設-缺口填補（SeqReset-Gap Fill）是重復的，應該放棄處理。 ） 如果缺口填補標志（GapFillFlag）域沒有出現（或被設為N），即為序號重設-重設（SeqReset-Reset）消息，那么有可能是此序號重設-重設（SeqReset-Reset）消息的目的是恢復混亂順序的消息。此時消息頭里的消息序號（MsgSeqNum）應該忽略。禁止在重發(fā)請求的正?；貞惺褂眯蛱栔卦O-重設（SeqReset-Reset）（應使用序號重設-缺口填補（SeqReset-Gap Fill））。序號重設-重設（SeqReset-Reset）僅用于無法用序號重設-缺口填補（SeqReset-Gap Fill）進行恢復的災難情況。注意使用序號重設-重設（SeqReset-Reset）可能會造成消息丟失。 序號重設消息格式見表１０： 表１０　序號重設（Sequence Reset） Tag 域名 必需 說明 標準消息頭 Y MsgType = 4 123 GapFillFlag N 缺口填補標志 36 NewSeqNo Y 新消息序號 標準消息尾 Y 10.3.7　 注銷消息（MsgType=5） 注銷消息是發(fā)起或確認STEP會話終止的消息。未經注銷消息交換而斷開連接，一律視為非正常的斷開。 在最后終止會話之前，注銷的發(fā)起人應該等待連接對方確認注銷消息。這使得連接對方有了實施任何有必要的缺口填補的機會。如果連接對方沒有在適當的時間間隔里作回應，那么會話就可以終止。 注銷發(fā)起人在發(fā)送注銷消息之后不應發(fā)送任何消息，除非接收到連接對方發(fā)出的重發(fā)請求消息。 注銷消息格式見表１１： 表１１　注銷（Logout） Tag 域名 必需 說明 標準消息頭 Y MsgType = 5 58 Text N 文本 354 EncodedTextLen N 編碼文本長度 355 EncodedText N 編碼文本（非ASCII碼） 標準消息尾 Y 10.4　 應用消息 10.4.1　 應用消息組件 應用消息中有很多共用的數據域集合——組件。比如說，大多數應用消息都會用到一系列定義證券品種的數據域：Symbol, SecurityIDSource, SecurityID, ……。為避免重復，本標準中定義了一些關鍵組件，在應用消息定義中直接用名稱引用這些組件。實際的消息定義和使用中，則應該將組件擴展開成為相應的數據域集合。 組件可以是重復組的部分，此時組件對應的整組數據域都位于組件所