首页 > 金融行业标准(JR) > JR/T 0022-2014 证券交易数据交换协议
JR/T 0022-2014

基本信息

标准号: JR/T 0022-2014

中文名称:证券交易数据交换协议

标准类别:金融行业标准(JR)

标准状态:现行

出版语种:简体中文

下载格式:.zip .pdf

下载大小:2071532

相关标签: 数据交换 协议

标准分类号

关联标准

出版信息

相关单位信息

标准简介

标准号:JR/T 0022-2014
标准名称:证券交易数据交换协议
英文名称:Securities trading exchange protocol
标准格式:PDF
发布时间:2014-02-10
实施时间:2014-02-10
标准大小:2M
标准介绍:本标准规定了证券交易所交易系统与市场参与者系统之间进行证券交易所需的数据交换协议( Securities Trading Exchange Protocol,简称SIEP),规定了应用环境、会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息定义、数据字典等内容。
本标准适用于证券交易所与市场参与者和相关金融机构间的业务数据交换。
本标准提供了市场参与者内部系统与市场参与者协议转换接口的连接标准以及市场参与者内部系统通过开放接口与证券交易所间连接标准。
本标准也可支持证券期货行业各机构系统间连接。
本标准按照GBT1.1-209给出的规则起草
由全国金融标准化技术委员会证券分技术委员会( SAC/TO68SC4)提出。
由全国金融标准化技术委员会( SACTC68)归口
历史版本有:
JR/T0022-2004《证券交易数据交换协议》,2004年发布。
本标准本次版本主要技术变化如下:
修改了规范性引用文件中部分已有国家标准的国际化标准(见第2章,2004年版的第2章)
修改了术语“组件块”的术语和定义(见3.1,2004年版的3.1
修改了术语“PBU”的定义(见3.7,2004年版的3.7);
修改了术语“市场参与者”的定义(见3.8,2004年版的3.8)

标准图片预览






标准内容

ICS03.060
备案号
中华人民共和国金融行业标准
JR/T0022——2014
代替JR/T0022-2004
证券交易数据交换协议
Securities trading exchange protocol2014-02-10发布
中国证券监督管理委员会
2014-02-10实施
1范围
2规范性引用文件
3术语和定义
4应用环境,
5会话机制,
5.1STEP会话..
5.1.1消息序号
5.1.2心跳,
5.1.3缺口填补
5.1.4消息重复发送
5.1.5消息重新发送
5.1.6消息确认
5.2STEP连接,
5.2.1STEP连接概述
5.2.2登录..
5.2.3消息交换
5.2.4注销
5.2.5消息恢复
6消息格式..
6.1数据类型
6.1.1数据类型概述
6.1.2 整数 int.
6.1.3浮点数float
6.1.4单个字符char
6.1.5字符串String.
6.1.6数据Data,
6.2.1域概述
6.2.2域的使用
6.2.3自定义域
6.2.4域汉字编码
6.2.5域界定
6.2.6语法.
6.2.7重复组
7安全与加密
JR/T0022-2014
JR/T0022-2014
8数据完整性
9扩展方式,
9.1扩展分类
9.2扩展规则
9.3版本管理
10消息定义
10.1消息头
10.2消息尾..
10.3会话消息:
10.3.1会话消息概述
10.3.2心跳消息(MsgType=0)
10.3.3登录消息(MsgType=A)
10.3.4测试请求消息(MsgType=1)10.3.5重发请求消息(MsgType=2)10.3.6会话拒绝消息(MsgType=3)10.3.7序号重设消息(MsgType=4)10.3.8注销消息(MsgType=5)
10.4应用消息。
10.4.1应用消息组件
10.4.2订单业务类
10.4.3投票业务类
10.4.4注册业务类,
10.4.5行情,
10.4.6市场控制
11数据字典
(资料性附录)
(资料性附录)
(资料性附录)
(资料性附录)
(资料性附录)
应用环境参考实例:.
重复组实例
缺口填补方式
会话连接场景
应用消息场景www.bzxz.net
附录F
(资料性附录)
计算校验和
本标准按照GB/T1.1-2009给出的规则起草。言
JR/T0022-2014
本标准由全国金融标准化技术委员会证券分技术委员会(SAC/TC68SC4)提出。本标准由全国金融标准化技术委员会(SAC/TC68)归口。本标准的附录A、B、C、D、E、F为资料性附录本标准历史版本有:
JR/T0022-2004《证券交易数据交换协议》,2004年发布本标准本次版本主要技术变化如下:修改了规范性引用文件中部分已有国家标准的国际化标准(见第2章,2004年版的第2章);修改了术语“组件块”的术语和定义(见3.1,2004年版的3.1);修改了术语“PBU”的定义(见3.7,2004年版的3.7):修改了术语“市场参与者”的定义(见3.8,2004年版的3.8);修改了“消息定义”中易混淆的字段,增加了市场字段中“创业板”与“国际板”市场的取值(见第10章,2004年版的第10章);-增加了应用消息组件中的证券品种(见10.4.1.2);修改了应用消息组件中的证券品种名称(见10.4.1.2,2004年版的10.4.1.1);增加了应用消息中的业务类别(见10.4.3)。本标准起草单位:中国证券监督管理委员会信息中心,上海证券交易所,上证所信息网络有限公司,深圳证券交易所,深圳证券通信有限公司,海通证券,长江证券,华夏基金。本标准主要起草人:郑刚、吴韶平、徐广斌、黄寅飞、黄越、喻华丽、主海、巫禄芳、王洪涛、付运林、齐琼
1范围
证券交易数据交换协议
JR/T0022-2014
本标准规定了证券交易所交易系统与市场参与者系统之间进行证券交易所需的数据交换协议(SecuritiesTradingExchangeProtocol,简称STEP),规定了应用环境、会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息定义、数据字典等内容。本标准适用于证券交易所与市场参与者和相关金融机构间的业务数据交换本标准提供了市场参与者内部系统与市场参与者协议转换接口的连接标准以及市场参与者内部系统通过开放接口与证券交易所间连接标准。本标准也可支持证券期货行业各机构系统间连接。规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注明日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注明日期的引用文件,其最新版本适用于本文件。GB/T2659世界各国和地区名称代码GB/T12406表示货币和资金的代码GB/T23696-2009证券和相关金融工具交易所和市场识别码ISO10962证券及相关金融工具一金融工具分类编码(CFI代码)[Securitiesandrelatedfinancialinstruments.Classificationoffinancialinstruments(cficode)3术语和定义
下列术语和定义适用于本文件。3.1
组件component
消息中具有一定业务相关的数据域集合,如证券品种定义,主要用于更直观描述消息的业务含义3.2
新订单neworder-single
交易客户方新产生的订单。
执行报告
executionreports
交易服务方响应交易客户方的消息,主要用于:订单确认、订单状态变化确认(如撤单确认和修改单确认)、发送订单的成交回报、订单拒绝1
JR/T0022-2014
指定交易designatedtrading
将证券账号与某一证券营业部所属的参与者业务单元(如席位号)相联系,从而限定该证券账号的交易应在该参与者业务单元下进行的交易方式。3.5
转托管designationtransfer
投资者将其托管在某一券商处的证券转到另一券商处托管的行为,并且投资者只能将证券在其托管的券商处卖出。
公司行为corporateaction
上市公司的非交易类业务,如新股配售、配股认购、可转债转股、回售等。3.7
PBU(参与者业务单元)participantbusinessunit市场参与者行使交易权利,获取交易服务的逻辑通道。3.8
市场参与者marketparticipants参与证券交易的客户方,如券商、证券营业部、交易所会员等。4应用环境
证券交易数据交换协议应用环境请参见附录A、附录D、附录E应用环境参考实例5会话机制
5.1STEP会话
5.1.1消息序号
任何一条消息都被分配有一个消息序号来唯一标识,消息序号在每次会话过程中从1开始,在整个会话过程中连续递增,直到该会话过程全部结束。通过监视消息序号的连续性可以知道交换中的消息缺口,并做出反应,使得连接双方数据同步连接双方都明确确定相互独立的消息序号,参与连接的任何一方负责维护自已发送的消息序号,并监视接收的消息序号以保证消息缺口的发现和处理。5.1.2心跳
在消息交换的空闲期间,连接双方将会产生有规则的心跳消息。通过心跳消息可以监控通讯连接的状态。心跳间隔时间由会话发起人在登录时确定。在发送任何消息后,应立即重新设置心跳间隔计时器。2
JR/T0022-2014
心跳间隔时间应该得到连接双方的确认,由登录发起人给出并得到登录接受方的确认。连接双方使用相同心跳间隔时间。
5.1.3缺口填补
由于协议是基于乐观的消息传输模式,消息在传输过程中可能存在丢失,而这种消息丢失发送方不能检测,因此接收方应负责检测消息的缺口并处理。有两种处理方法:接收方发现缺口后向发送方请求发送缺口消息及其后的所有消息;接收方发现缺口后,保存已收到消息,并向发送方请求重复发送缺口消息。
5.1.4消息重复发送
响应一个重发请求而重复发送消息时,或者不确定对方是否收到某消息而重复发送该消息时,要求在该消息内加上可能重复标志(PossDupFlag=Y)。如何处理该消息则是接收方的事情。由于当生成有此类可能重复发送的消息时,仍使用该消息的原来序号,但某些信息可能会改变,如原始时间、发送时间、正文长度、可能重复标志等,所以应重新计算校验和。5.1.5消息重新发送
基于应用层的可能重发,如发送的订单在相当长的时间内没有确认,或者怀疑其根本未曾发送过,可以通过设置可能重新发送标志来重新发送(PossibleResend-Y),并使用新的消息序号。接收方应用层收到该类消息后,应通过查询消息内的域(如订单编号等)来确定此前是否收到此条消息。该类消息应确定包含相同的正文数据,同样,由于某些信息可能会改变,所以应重新计算校验和。5.1.6消息确认
由于协议是基于乐观的消息传输模式,通过监视消息序号发现缺口,不支持对每个消息收发的确认。但大量消息收发的确认可在应用层定义。在应用层接受和拒绝是允许的,如订单的确认。5.2STEP连接
5.2.1STEP连接概述
会话过程的数据交换可以这样描述:连接双方各有一个连续的消息序号随消息传送,而交易期间可以多次断开并重新连接,其断开的原因可以是外因引起,也可以是连接双方根据系统来统一制定何时断开并重新连接。一次会话连接通常不应超过24小时,当然,如需要保持24小时以上的连接,则需要发送一条含有序号重设标志的登录消息来建立新的起始消息序号。STEP连接分为三个部分:登录、消息交换、注销。STEP会话包含一个或多个STEP连接,即一个STEP会话可以跨越多个登录。5.2.2登录
5.2.2.1登陆步骤
登录连接包含三个步骤:建立电信通讯连接、连接双方的确认/认证、消息传输同步的初始化。5.2.2.2连接
会话的发起方与接收方建立电信通讯连接。5.2.2.3认证
JR/T0022-2014
发起方发送登录消息(Logon),接收方认证发起方身份的合法性。登录消息应包括认证的必要数据,如用户名、密码等。如果发起方身份通过认证,则接收方发送一个登录消息作回应。如果认证失败,会话接收方则在发送一个含失败说明的注销消息(Logout)后关闭连接。不过发送注销消息并非是必须的,因为在某些情况下往往会引起其他问题。在发起方收到接收方的登录消息之后即可认为会话连接建立完成。会话发起方可以紧随登录消息之后开始发送其他消息。通常在登录后或者刚发送完测试请求消息(TestRequest)时延迟等待一段时间,然后再发送新的消息,使得连接双方能有效控制重发请求。否则可能会导致一方会针对对方的每一条新消息发出重发请求。5.2.2.4初始化
在身份通过认证之后,发起方和接收方应首先同步消息序号,然后才能相互发送新的信息。同步消息序号通过消息序号域(MsgSeqNum)来确定,将登录消息里的消息序号(MsgSeqNum)与内部监控的下一个预期的消息序号进行比较就能发现消息的消息序号缺口。同样,发起方通过将接收方发送的登录消息里的消息序号(MsgSeqNum)与下一个预期的消息序号进行比较也能发现消息的缺口。5.2.3消息交换
在以上初始化完成之后,可以开始进行信息交换。所有有效消息的格式将在“会话消息”和“应用消息”部分中详细叙述。
5.2.4注销
会话的正常结束是通过连接双方互相发送注销消息(Logout)完成的。若结束时没有收到回送的注销消息(Logout),则把对方视作已注销。除此之外的其它方式的会话结束视为非正常,并应按错误来处理。
在发送注销消息(Logout)之前,应发送测试请求消息(TestRequest)以要求对方的心跳信息,这有助于保证不出现消息序号缺口。在结束会话之前,注销消息(Logout)的发起方应该等待对方回送的注销消息(Logout),这样给接收方一个填补缺口的机会。待重发请求的信息全部收到后,接收方才可发送应答的注销消息(Logout)。如果接收方在一定时间内没有答复,那么会话就可以立即中断。(注1)5.2.5消息恢复
以下描述了有关恢复消息的具体方法。每一方必须维护两个消息序号,一个为了发送,一个为了接收。当接收进来的消息序号与预期的消息序号不相符合时,需进行修正处理。但需要注意的是,如果接收进来的是序号重设-重设(SeqReset-Reset)消息则不需要修正处理,因为处理该消息时不必考虑它的消息序号。如果接收的消息的消息序号比预期的消息序号小,而且没有设置可能重复标志(PossDupFlag),那么表明发生了严重的错误。因此必须立即结束会话,并开始进行人工干预。如果接收进来的消息序号比预期的大,那么表明有消息被遗漏,应通过发送重发请求申请填补缺口。当收到重发请求时,重发人可以作出回应为以下三种之一:(注2)a)作为正常回应,重发人按顺序发送被请求的消息,这些消息的消息序号仍为原消息序号,并且将可能重复的标志(PossDupFlag)置位为“Y”。作为正常回应,重发人发送序号重设-缺口填补(SeqReset-GapFill)消息,可能重复标志b)
(PossDupFlag)置位为“Y”,以表示删除过时或多余的消息。注1:注销不影响任何订单的状况。所有有效的订单都可在注销(Logout)之后执行。注2:本文中请求人指的是提出重发请求的那一方,重发人指的是回应重发请求的那一方。4
JR/T0022-2014
c)作为非正常回应,重发人发送序号重设-重设(SeqReset-Reset)消息,可能重复的标志(PossDupFlag)置位为“Y”,以强制消息序号同步。在缺口填补过程中,不需要重新发送某些会话消息。取而代之的是一种特殊的序号重设一缺口填补(SeqReset-GapFill)消息。不需要重新发送的会话消息是:登录、注销、重发请求、心跳、测试请求、序号重设-重设(SeqReset-Reset)和序号重设-缺口填补(SeqReset-GapFill)。这样会话拒绝消息便成为了唯一可能被重新发送的会话消息。会话过程中应监视接收进来的消息以便发现由于疏漏而被对方重新发送了的会话消息(设置了可能重复标志(PossDupFlag)的)。当收到这些消息以后,处理时,只要确保它们具有消息序号的完整性即可,而忽略对它们的业务或应用的处理。如果碰到多个连续的不需要重发的会话消息,则只需发送一个序号重设一缺口填补(SeqReset-GapFill)消息取而代之。该序号重设-缺口填补消息的消息序号是下一个预期的消息序号。序号重设-缺口填补(SeqReset-GapFill)消息的新消息序号(NewSeqNo)为本连续会话消息段中最大消息序号+1。(注3)
在缺口被填补完成之后,交换引擎应将无序的消息暂时保存为有序的排列并按顺序对它们进行处理。这样防止出现对n->m,n->m+1,n->m+2,的重发请求,从而导致了大量的可能重复(PossDupFlag=“Y\)标记。
检验消息序号的连续在会话过程管理中是必不可少的部分。不过,针对消息类型的不同,处理消息序号流的差异也就不同。表1列出了当进来的消息序号大于预期消息序号时而应采取的措施。(注4)
表1缺口填补处理措施
消息类型
重发请求
序号重设-重设
序号重设-缺口填补
所有其它信息
针对消息序号错误所采取的措施永远是连接双方发送的第一条消息,用于认证和连接。如果发现登录消息中有缺口,则应在回送登录确认消息之后立即发送重发请求。如果发现有缺口,应发送重发请求消息以重新接收所有丢失的消息,然后再发送注销消息作为对注销请求的确认。注意严禁在有缺口情况下结束会话。并由注销的最初发起人负责结束会话,因此注销发起人有责任回应所有的重发请求。首先处理完对方的重发请求,随后发送自己的重发请求以填补消息序号错误而发现的消息缺口。
可以忽略消息序号错误。因为在序号重设-重设(SeqReset-Reset)消息中的新消息序号(NewSeqNo)强制为下一发送消息的消息序号。应立即向对方发送重发请求。但是,重要的是要确保没有无意间跳过任何消息,这意味着缺口填补消息应按次序被接收到,如果次序不对,那么表示出现了非正常的情况。
执行正常的缺口填补
注3:如在重新发送操作期间,有7条连续的会话消息等待发送,他们以消息序号9开始和以消息序号15结束,此时只发送一个序号重设-缺口填补(SeqReset-GapFill)消息来代替那7条消息,那么该序号重设-缺口填补(SeqReset-GapFill)消息的消息序号是9,这是因为要承接上条消息而保持消息序号的连续性;其中新消息序号(NewSeqNo)是16,这样使得对方知道下一消息发送时的消息序号。注4:在任何情况下,除了序号重设一重设消息外,如果进来的消息序号比预期的消息序号小,而且可能重复标志(PossDupFlag)没有被设置,那么应立即终止会话过程。并应在结束会话之前,向对方发送带有解释正文的注销(Logout)消息。
JR/T0022-2014
6消息格式
6.1数据类型
6.1.1数据类型概述
数据类型用于定义数据域的取值类型,本标准由几个基本的数据类型(整数、浮点数、单字符、字符串、二进制数据块)和在此基础上扩展的数据类型组成。除“data”数据类型外,其他数据类型均以ASCI码字符串表示。
6.1.2整数int
无逗号和小数位的序号,可表示正负(ASCII码字符“,“0’至‘9组成)。符号占据一个字符位置。允许前置字符零(例:“00023”=“23\。整数类型的扩展定义:
长度Length:以整数表示字节为单位的数据长度,正数。重复数NumlnGroup:以整数表示重复组的个数,正数。消息序号SeqNum:以整数表示消息序号,正数。域号TagNum:以整数表示的域号(或称Tag),正数,首位不能为零。月日期号DayOfMonth:以整数表示的月份中第几天,取值1至31。6.1.3浮点数float
含有可选的小数部分,可表示正负(ASCII码字符“”,“0”至9’和‘’组成)。最多15位有效数字。允许前置字符零(例:“00023”=“23\)。允许小数部分后置字符零(例:“23.0”=“23.0000”=“23\)。
浮点数类型的扩展定义:
除非特别声明,浮点数类型均有正负。量Qty:股份数量、资产数量等,可以有小数部分。价格Price:小数位数可变。
价格偏移量PriceOffset:代表价格偏移量的浮点域。金额Amt:典型的价格与数量相乘结果,如成交金额。百分比Percentage:小数表示方法:如“.05”代表5%6.1.4单个字符char
指除界定符外所有字母字符和标点字符,区分字母大小写。字符类型的扩展定义:
布尔Boolean:该域取值于两个字符,(\Y'=True/YesN'=False/No)6.1.5字符串String
区分字母大小写。
字符串类型的扩展定义:
多元值字符串MultipleValueString:用空格分隔。国家Country:参见GB/T2659。
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。