《证券交易数据交换协议》.docx
- 文档编号:7470878
- 上传时间:2023-01-24
- 格式:DOCX
- 页数:139
- 大小:507.24KB
《证券交易数据交换协议》.docx
《《证券交易数据交换协议》.docx》由会员分享,可在线阅读,更多相关《《证券交易数据交换协议》.docx(139页珍藏版)》请在冰豆网上搜索。
《证券交易数据交换协议》
目次
前言III
证券交易数据交换协议1
1范围1
2规范性引用文件1
3术语和定义1
4应用环境2
5会话机制2
5.1STEP会话2
5.1.1消息序号2
5.1.2心跳2
5.1.3缺口填补2
5.1.4消息重复发送2
5.1.5消息重新发送2
5.1.6消息确认3
5.2STEP连接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整数int5
6.1.2浮点数float6
6.1.3单个字符char6
6.1.4字符串String6
6.1.5数据Data6
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扩展规则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重发请求消息(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订单业务类18
10.4.3注册类25
10.4.4行情26
10.4.5市场控制30
11数据字典32
附 录 A应用环境参考实例61
附 录 B重复组实例62
附 录 C缺口填补方式63
附 录 D会话连接场景64
附 录 E应用消息场景68
附 录 F计算校验和74
1
2
3
4
5前言
本标准部分内容参照了金融信息交换协议(FIX4.4)。
本标准的附录A、B、C、D、E、F为资料性附录。
本标准由证券交易标准化小组提出。
本标准由全国金融标准化技术委员会归口。
本标准起草单位:
中国证券监督管理委员会信息中心承担,上海证券交易所负责起草,深圳证券交易所、上海期货交易所、国信证券公司、泰阳证券公司、华夏证券公司参与制订。
本标准的主要起草人:
杨淑琴、许强、陈忠苏、丁桦、吴韶平、黄寅飞、喻华丽、万春波、王海、黄宾、刘汉西、汤玉龙、李大鹏。
证券交易数据交换协议
51 范围
本标准规定了证券交易所交易系统与市场参与者系统之间进行证券交易所需的数据交换协议(SecuritiesTradingExchangeProtocol,简称STEP),规定了应用环境、会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息定义、数据字典等内容。
本标准适用于证券交易所与市场参与者和相关金融机构间的业务数据交换。
本标准提供了市场参与者内部系统与市场参与者协议转换接口的连接标准以及市场参与者内部系统通过开放接口与证券交易所间连接标准。
本标准也可支持证券交易所与其他外部交易所间连接。
52 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注明日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注明日期的引用文件,其最新版本适用于本标准。
GB/T2659世界各国和地区名称代码
GB/T12406表示货币和资金的代码
ISO10383交易所和市场代码标志识别码(MIC)[Codesforexchangesandregulatedmarkets-MarkedidentifierCodes(MIC)]
ISO10962证券金融票据的分类(CFI代码)[Securities-ClassificationofFinancialInstruments(CFIcode)]
53 术语和定义
下列术语和定义适用于本标准。
53.1
组件块Componentblock
消息中具有一定业务相关的数据域集合,如证券品种定义,主要用于更直观描述消息的业务含义。
53.2
新订单NewOrder-Single
交易客户方新产生的订单。
53.3
执行报告ExecutionReport
交易服务方响应交易客户方的消息,主要用于:
订单确认、订单状态变化确认(如撤单确认和修改单确认)、发送订单的成交回报、订单拒绝。
53.4
指定交易DesignatedTrading
将证券账号与某一证券营业部所属的参与者业务单元(如席位号)相联系,从而限定该证券账号的交易应在该参与者业务单元下进行的交易方式。
53.5
转托管DesignationTransfer
投资者将其托管在某一券商处的证券转到另一券商处托管的行为,并且投资者只能将证券在其托管的券商处卖出。
53.6
公司行为CorporateAction
上市公司的非交易类业务,如新股配售、配股认购、可转债转股、回售等。
53.7
PBU(参与者业务单元)ParticipantBusinessUnit
市场参与者行使交易权利,获取交易服务的唯一逻辑通道。
53.8
市场参与者MarketParticipants
参与证券交易的客户方,如券商、证券公司、证券营业部、交易所会员等。
54 应用环境
证券交易数据交换协议应用环境请参考附录A应用环境参考实例。
55 会话机制
55.1 STEP会话
55.1.1 消息序号
任何一条消息都被分配有一个消息序号来唯一标识,消息序号在每次会话过程中从1开始,在整个会话过程中连续递增,直到该会话过程全部结束。
通过监视消息序号的连续性可以知道交换中的消息缺口,并做出反应,使得连接双方数据同步。
连接双方都明确确定相互独立的消息序号,参与连接的任何一方负责维护自己发送的消息序号,并监视接收的消息序号以保证消息缺口的发现和处理。
55.1.2 心跳
在消息交换的空闲期间,连接双方将会产生有规则的心跳消息。
通过心跳消息可以监控通讯连接的状态。
心跳间隔时间由会话发起人在登录时确定。
在发送任何消息后,应立即重新设置心跳间隔计时器。
心跳间隔时间应该得到连接双方的确认,由登录发起人给出并得到登录接受方的确认。
连接双方使用相同心跳间隔时间。
55.1.3 缺口填补
由于协议是基于乐观的消息传输模式,消息在传输过程中可能存在丢失,而这种消息丢失发送方不能检测,因此接收方应负责检测消息的缺口并处理。
有两种处理方法:
接收方发现缺口后向发送方请求发送缺口消息及其后的所有消息;接收方发现缺口后,保存已收到消息,并向发送方请求重复发送缺口消息。
55.1.4 消息重复发送
响应一个重发请求而重复发送消息时,或者不确定对方是否收到某消息而重复发送该消息时,要求在该消息内加上可能重复标志(PossibleDuplicate=Y)。
如何处理该消息则是接收方的事情。
由于当生成有此类可能重复发送的消息时,仍使用该消息的原来序号,但某些信息可能会改变,如原始时间、发送时间、正文长度、可能重复标志等,所以应重新计算校验和。
55.1.5 消息重新发送
基于应用层的可能重发,如发送的订单在相当长的时间内没有确认,或者怀疑其根本未曾发送过,可以通过设置可能重新发送标志来重新发送(PossibleResend=Y),并使用新的消息序号。
接收方应用层收到该类消息后,应通过查询消息内的域(如订单编号等)来确定此前是否收到此条消息。
该类消息应确定包含相同的正文数据,同样,由于某些信息可能会改变,所以应重新计算校验和。
55.1.6 消息确认
由于协议是基于乐观的消息传输模式,通过监视消息序号发现缺口,不支持对每个消息收发的确认。
但大量消息收发的确认可在应用层定义。
在应用层接受和拒绝是允许的,如订单的确认。
55.2 STEP连接
会话过程的数据交换可以这样描述:
连接双方各有一个连续的消息序号随消息传送,而交易期间可以多次断开并重新连接,其断开的原因可以是外因引起,也可以是连接双方根据系统来统一制定何时断开并重新连接。
一次会话连接通常不应超过24小时,当然,如需要保持24小时以上的连接,则需要发送一条含有序号重设标志的登录消息来建立新的起始消息序号。
STEP连接分为三个部分:
登录、消息交换、注销。
STEP会话包含一个或多个STEP连接,即一个STEP会话可以跨越多个登录。
55.2.1 登录
登录连接包含三个步骤:
建立电信通讯连接、连接双方的确认/认证、消息传输同步的初始化。
主要有以下几点:
55.2.1.1 连接
会话的发起方与接收方建立电信通讯连接。
55.2.1.2 认证
发起方发送登录消息(Logon),接收方认证发起方身份的合法性。
登录消息应包括认证的必要数据,如用户名、密码等。
如果发起方身份通过认证,则接收方发送一个登录消息作回应。
如果认证失败,会话接收方则在发送一个含失败说明的注销消息(Logout)后关闭连接。
不过发送注销消息并非是必须的,因为在某些情况下往往会引起其他问题。
在发起方收到接收方的登录消息之后即可认为会话连接建立完成。
会话发起方可以紧随登录消息之后开始发送其他消息。
通常在登录后或者刚发送完测试请求消息(TestRequest)时延迟等待一段时间,然后再发送新的消息,使得连接双方能有效控制重发请求。
否则可能会导致一方会针对对方的每一条新消息发出重发请求。
55.2.1.3 初始化
在身份通过认证之后,发起方和接收方应首先同步消息序号,然后才能相互发送新的信息。
同步消息序号通过消息序号域(MsgSeqNum)来确定,将登录消息里的消息序号(MsgSeqNum)与内部监控的下一个预期的消息序号进行比较就能发现消息的消息序号缺口。
同样,发起方通过将接收方发送的登录消息里的消息序号(MsgSeqNum)与下一个预期的消息序号进行比较也能发现消息的缺口。
55.2.2 消息交换
在以上初始化完成之后,可以开始进行信息交换。
所有有效消息的格式将在“会话消息”和“应用消息”部分中详细叙述。
55.2.3 注销
会话的正常结束是通过连接双方互相发送注销消息(Logout)完成的。
若结束时没有收到回送的注销消息(Logout),则把对方视作已注销。
除此之外的其它方式的会话结束视为非正常,并应按错误来处理。
在发送注销消息(Logout)之前,应发送测试请求消息(TestRequest)以要求对方的心跳信息,这有助于保证不出现消息序号缺口。
在结束会话之前,注销消息(Logout)的发起方应该等待对方回送的注销消息(Logout),这样给接收方一个填补缺口的机会。
待重发请求的信息全部收到后,接收方才可发送应答的注销消息(Logout)。
如果接收方在一定时间内没有答复,那么会话就可以立即中断。
(注)
55.2.4 消息恢复
以下描述了有关恢复消息的具体方法。
每一方必须维护两个消息序号,一个为了发送,一个为了接收。
当接收进来的消息序号与预期的消息序号不相符合时,需进行修正处理。
但需要注意的是,如果接收进来的是序号重设-重设(SeqReset-Reset)消息则不需要修正处理,因为处理该消息时不必考虑它的消息序号。
如果接收的消息的消息序号比预期的消息序号小,而且没有设置可能重复标志(PossDupFlag),那么表明发生了严重的错误。
因此必须立即结束会话,并开始进行人工干预。
如果接收进来的消息序号比预期的大,那么表明有消息被遗漏,应通过发送重发请求申请填补缺口。
当收到重发请求时,重发人可以作出回应为以下三种之一:
(注)
a)作为正常回应,重发人按顺序发送被请求的消息,这些消息的消息序号仍为原消息序号,并且将可能重复的标志(PossDupFlag)置位为“Y”。
b)作为正常回应,重发人发送序号重设-缺口填补(SeqReset-GapFill)消息,可能重复标志(PossDupFlag)置位为“Y”,以表示删除过时或多余的消息。
c)作为非正常回应,重发人发送序号重设-重设(SeqReset-Reset)消息,可能重复的标志(PossDupFlag)置位为“Y”,以强制消息序号同步。
在缺口填补过程中,不需要重新发送某些会话消息。
取而代之的是一种特殊的序号重设-缺口填补(SeqReset-GapFill)消息。
不需要重新发送的会话消息是:
登录、注销、重发请求、心跳、测试请求、序号重设-重设(SeqReset-Reset)和序号重设-缺口填补(SeqReset-GapFill)。
这样会话拒绝消息便成为了唯一可能被重新发送的会话消息。
会话过程中应监视接收进来的消息以便发现由于疏漏而被对方重新发送了的会话消息(设置了可能重复标志(PossDupFlag)的)。
当收到这些消息以后,处理时,只要确保它们具有消息序号的完整性即可,而忽略对它们的业务或应用的处理。
如果碰到多个连续的不需要重发的会话消息,则只需发送一个序号重设-缺口填补(SeqReset-GapFill)消息取而代之。
该序号重设-缺口填补消息的消息序号是下一个预期的消息序号。
序号重设-缺口填补(SeqReset-GapFill)消息的新消息序号(NewSeqNo)为本连续会话消息段中最大消息序号+1。
(注)
在缺口被填补完成之后,交换引擎应将无序的消息暂时保存为有序的排列并按顺序对它们进行处理。
这样防止出现对n->m,n->m+1,n->m+2,…的重发请求,从而导致了大量的可能重复(PossDupFlag=’Y’)标记。
检验消息序号的连续在会话过程管理中是必不可少的部分。
不过,针对消息类型的不同,处理消息序号流的差异也就不同。
下列的表1列出了当进来的消息序号大于预期消息序号时而应采取的措施。
(注)
表1
消息类型
针对消息序号错误所采取的措施
登录
永远是连接双方发送的第一条消息,用于认证和连接。
如果发现登录消息中有缺口,则应在回送登录确认消息之后立即发送重发请求
注销
如果发现有缺口,应发送重发请求消息以重新接收所有丢失的消息,然后再发送注销消息作为对注销请求的确认。
注意严禁在有缺口情况下结束会话。
并由注销的最初发起人负责结束会话,因此注销发起人有责任回应所有的重发请求
重发请求
首先处理完对方的重发请求,随后发送自己的重发请求以填补消息序号错误而发现的消息缺口。
序号重设-重设
可以忽略消息序号错误。
因为在序号重设-重设(SeqReset-Reset)消息中的新消息序号(NewSeqNo)强制为下一发送消息的消息序号。
序号重设-缺口填补
应立即向对方发送重发请求。
但是,重要的是要确保没有无意间跳过任何消息,这意味着缺口填补消息应按次序被接收到,如果次序不对,那么表示出现了非正常的情况
所有其它信息
执行正常的缺口填补。
56 消息格式
56.1 数据类型
数据类型用于定义数据域的取值类型,本标准由几个基本的数据类型(整数、浮点数、单字符、字符串、二进制数据块)和在此基础上扩展的数据类型组成。
除“data”数据类型外,其他数据类型均以ASCII码字符串表示。
56.1.1 整数int
无逗号和小数位的序号,可表示正负(ASCII码字符‘-’,‘0’至‘9’组成)。
符号占据一个字符位置。
允许前置字符零(例:
“00023”=“23”)。
整数类型的扩展定义:
长度Length:
以整数表示字节为单位的数据长度,正数。
重复数NumInGroup:
以整数表示重复组的个数,正数。
消息序号SeqNum:
以整数表示消息序号,正数。
域号TagNum:
以整数表示的域号(或称Tag),正数,首位不能为零。
月日期号DayOfMonth:
以整数表示的月份中第几天,取值1至31。
56.1.2 浮点数float
含有可选的小数部分,可表示正负(ASCII码字符‘-’,‘0’至‘9’和‘.’组成)。
最多15位有效数字。
允许前置字符零(例:
“00023”=“23”)。
允许小数部分后置字符零(例:
“23.0”=“23.0000”=“23”)。
浮点数类型的扩展定义:
除非特别声明,浮点数类型均有正负。
量Qty:
股份数量、资产数量等,可以有小数部分。
价格Price:
小数位数可变。
价格偏移量PriceOffset:
代表价格偏移量的浮点域。
金额Amt:
典型的价格与数量相乘结果,如成交金额。
百分比Percentage:
小数表示方法:
.05代表5%。
56.1.3 单个字符char
指除界定符外所有字母字符和标点字符,区分字母大小写。
字符类型的扩展定义:
布尔Boolean:
该域取值于两个字符,(’Y’=True/Yes,’N’=False/No)
56.1.4 字符串String
区分字母大小写。
字符串类型的扩展定义:
多元值字符串MultipleValueString:
用空格分隔。
国家Country:
参见GB/T2659。
字符串货币类型Currency:
参见GB/T12406。
交易所或市场编号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。
56.1.5 数据Data
无格式和内容限制的原始数据,包含长度域和数据域两个部分,数据域数据可以包含数值0x01,长度域指明数据域的字节数。
56.2 域
域是基本的数据元素,每个域有其域号、业务含义和确定的取值范围,域号统一分配给不同的域,是域的区分标志,在消息中,通过域号来确定不同的域。
域的数据类型决定了其取值类型,域的取值范围可以是一个集合,任何在此集合外的取值被认为是非法取值。
数据字典部份详细定义了所有域的业务定义、数据类型和取值范围。
56.2.1 域的使用
在消息中,域的使用有三种方式:
必须的,可选的,条件限制选择(即根据其他相关域的存在与否或取值来决定)。
作为一个完整的消息,必须域和条件限制选择域是需要包含的。
56.2.2 自定义域
如本标准中定义的域不够使用时,证券交易所或市场参与者可以扩展定义新的域,即自定义域。
56.2.3 域汉字编码
域取值为汉字时需要使用统一的GBK汉字编码标准,。
56.2.4 域界定
消息中所有的域(包含data类型数据域)都有一个分隔符来界定分隔,该分隔符就是不可打印字符ASCII码“SOH”(#001,hex:
0x01,本文档中以
因此,所有消息以“8=STEP.x.y.z
除data数据类型域外,其他数据域内容都不应包含域界定符
56.2.5 语法
任何消息都严格由多个“域号=值”的基本结构组成,“域号=值”基本结构用域界定符
消息组成结构如图1:
图1:
消息格式
消息由消息头、消息的正文和消息尾组成。
同样,每个组成部份都由一系列“域号=值”组成,并且在遵循以下规则前提下“域号=值”基本结构可以是任意的次序:
a)开始部分应是消息头,随后是正文,最后是消息尾;
b)消息头的前3个域的次序不能改变:
起始串(Tag=8)、消息体长度(Tag=9)、消息类型(Tag=35);
c)消息尾的最后一个域应是校验和域(Tag=10);
d)重复组中,域出现的顺序应遵循该重复组在消息或组件中定义时的次序。
e)在一条消息中,除重复组域外任何其他域不能重复出现。
(消息格式的例子见注)
56.2.6 重复组
域可以在重复组里多次重复,用以传输数组类的数据。
通常域名起始为’No’字符的域指明重复的次数,并位于重复组的开始处。
本文档中重复组的定义通过缩进的符号表示,重复组也可嵌套。
使用子重复组时不能省略父重复组。
具体可参考附录B重复组实例。
57 安全与加密
由于消息有可能在公网或不安全的网络上传输交换,因此需要对相关的敏感数据加密处理。
具体加密的方法由连接双方达成的协议而定。
消息内除某些需要公开识别的域以明文传输外其他任何域都可以加密放置密文数据域(SecureData)内。
当然,这些被加密的域也可以同时保留明文的表示方式。
当决定使用加密方案时,可以对消息正文内所有的域加密。
如果消息的重复组内有部分需要加密的,那么要求对整个重复组加密。
本协议还提供的一些域用以支持数字签名、密钥交换和正文加密等安全技术。
正文加密方案有三种:
a)将安全敏感的域加密后移至SecureData域。
b)将所有允许加密的域加密后移至SecureData域。
c)将所有允许加密的域加密后移至SecureData域,同时这些域以明文在消息中重复出现。
58 数据完整性
数据的完整性通过两个方法保证:
消息体长度和校验和的验证。
消息体长度是以BodyLength域来表示,其值是计算出的消息长度域后面的字符数,包含紧靠校验和域标志‘10=’之前的界定符SOH。
校验和是把每个字符的二进制值从消息开头‘8=’中的‘8’开始相加,一直加到紧靠在校验和域‘10=’之前的域界定符,然后取按256取模得到的结果。
校验和域位于消息的最末一个,校验和的计算是在加密之后进行的。
计算校验和的代码段可参考附录F计算校验和。
59 扩展方式
59.1 扩展分类
扩展分为两个部分:
消息定义扩展和域定义扩展。
消息定义扩展可以通过新增消息类型来实现,但尽量在已有消息中通过域定义或取值扩展来定义新业务。
已有消息所代表的业务在扩展时不能改变。
域定义扩展可以通过新增域来实现,但尽量通过扩展域值来扩展域的定义。
消息中已定义的必须的域不能取消定义,也不能改变成可选域。
59.2 扩展规则
自定义消息的消息类型值首字符为‘U’。
其他类型的消息由全国金融标准化技术委员会根据国际相关标准的变化统一定义并发布。
消息和域临时定义原则:
上海证券交易所临时定义消息的消息类型值首两位字符为‘UA’,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 证券交易数据交换协议 证券交易 数据 交换 协议