新三板部分公司无交易背景票据融资案例总结

随机通过网络检索挂牌股票代码和简称的方式，对430690-830792的挂牌公司是否发生无交易背景的票据融资情况进行检索，检索到5个案例，同时增加天津本地的挂牌公司天房科技案例。总结情况见下表：

根据上述案例，总结共性问题如下：

1、如实披露是最大的共性，哪怕金额仅仅发生数百万元的，公司与主办券商还是选择了如实披露，不为日后的披露问题留遗患；

2、控股股东、实际控制人均选择承诺赔偿兜底，同时保证日后不再发生；

3、均在申报前甚至报告基准日前提前解付，不留风险敞口；

4、无论发生额还是期末余额，违规票据占比比例较高不会构成挂牌障碍。

 

第二篇：fix1金融交易协议总结

金融信息交换协议（FIX）

1 协议简介

1.1 FIX地位及作用

金融信息传输业有多种标准同时并存，为避免混乱及重复使用，FIX协议是一个免费的开放式通信标准，于19xx年由富达投资和所罗门兄弟为推动股票交易双边通信框架而开发。自诞生以来，FIX协议顺应行业不断变化的需求和其他资产类别的要求而取得了长足发展，其使用亦日益普遍。

1.2 FIX国内外使用情况

?

?

?

?

? FPL Member Firms，表态支持并加入FIX的组织，主要有以下几个方面的组织： Buy-side institutions：美国世纪投资公司、高桥资本等26个单位； Sell-side broker/dealers：摩根、国信证券等55个单位； ECNs/Exchanges：上交所、纳斯达克、香港交易所等37个单位； Associations：ISO等14个单位； Vendors：IBM、FIX Solutions等140多个单位。

20xx年《中国FIX电子交易会议》记载，已经有超过10000家机构正在使用FIX协议，其中包括：几乎所有主要证券交易所和投资银行，全球最大的共同基金和货币经理，数千家小型投资公司，领先的期货交易所提供FIX连接，主要的债券交易商已经实施或正在实施FIX连接。

1.3 FIX版本

Fix协议现有的版本应用4.X-5.0sp2。国外投行主要应用4.5-5.0，国内投行处于试用尝试阶段，各种版本均有，但4.2居多。

5.0版本与4.X版本的不同：TI（the transport independence ）特性，即传输无关框架。TI将FIX会话层从应用层协议中分离出来。在TI框架下，应用层协议消息可以通过任意合适的传输技术进行传送，在这里，FIX会话层协议是FIX应用层消息的可选传输传输协议之一。

1.4 FIX协议特点及其优势

FIX协议由于其开放的体系，具有如下四个主要特点：

? 使用简单，各类应用系统可以依据FIX协议规则，编写自身的应用程序，应用于任

何希望自动连接的交易双方，能支持各种商务功能。

? 规则开放透明，具有不断扩充的能力。为了把最大的灵活性给予用户，FIX鼓励用

户自定义域。这些域应在已达成有关共识的交易各方范围内使用，并应小心使用，以避免在各方实施该协议之初的时候容易引发的冲突。FIX由一个非盈利的FIX组织管理维护，公布FIX协议的标准化格式，在鼓励卖主加入该标准的同时，FIX始终保持中立。

? 不受载体的限制，它可通过租用数据线路、数据转接介质或在互联网上使用， ? 安全机制方面，FIX不提供特定的安全机制，它只是一个信息交换平台。但它支持

任何双方允许的加密体系。

由于有上述的四个特点，实施FIX所带来的优势主要表现在：

? 降低整合各种内部操作程序的成本及复杂性

? 降低与新交易伙伴连接的成本及复杂性

? 由于规模经济效应或发掘共享基础设施的潜能，实现自动化处理所需的投入（如软

件和硬件）因而下降

? 因人工重输信息或使用转换引擎所造成的潜在错误减少，市场参与者之间的通讯质

量因此得到了提升

1.5 FIX协议结构

FIX协议的格式存在着两种结构:tag=value结构和 FIXML 结构。目前采用的都是第一种方式来完成数据交换。本报告主要讲述这种格式的消息。

其中FIXML可读性更强，但占用更多的带宽资源。

1.5 FIX消息模式

FIX消息格式：每个FIX消息均由消息头、消息体和消息尾组成。

每个消息均由一系列

的<tag>=<value>字段组成，字段间用分隔符<SOH>(0x01)分割。

消息头开始顺序有如下三个字段：BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).此后还包括有其他字段；消息尾就是一个CheckSum (tag #10)； 所有FIX消息都是以“8=FIX.x.y<SOH>”开始，以“10=nnn<SOH>“结束。

具体的消息格式在《中信证券FIXGW接入说明》中有说明。

2 协议工作原理

2.1 通信模型及基本概念

2.1.1通信模型

Initiator ：发起者，建立通信连路，通过发送初始Logon消息发起会话的参与方。 Acceptor ：接收方 FIX会话的接收方。负责执行第一层次的认证和通过传输Logon消息的确认正式声明连接请求被接受。

原则：先发起者为Initiator ，接受者为Acceptor 。

标准模式以网关为Acceptor，客户端为Initiator做为常用模式。

2.1.2 Fix connection

FIX连接 由3部分组成：logon登录，message exchange消息传输，和logout注销。

2.1.3 Fix session

FIX会话由一个或多个FIX Connection FIX连接组成。一个FIX会话可以有多次登录。

2.1.4 Sequence Num

所有的FIX消息都由一个唯一的序列号进行标示。序列号在每一个FIX会话开始时被初始化为1，并在整个会话期间递增。监控序列号可以使会话参与者识别和处理丢失的消息， 当在一个FIX会话中重新连接时能够快速进行应用程序同步。

每个会话将建立一组互不依赖的接受和发送序列。会话参与者将维护一个赋予发送消息的序列和一个监控接受消息的消息块间隙序列号。

2.1.5 Heartbeats

在消息交互期间，FIX应用程序将周期性产生Heartbeat心跳消息。该心跳消息可以监控通信链路状态及识别接收序列号间隙。发送Heartbeat的周期间隔由会话发起者使用在

Logon消息中HeartBtInt域进行定义。

Heartbeat心跳消息的时间间隔应当在每一个消息发送后复位，即发送一个消息后，在间隔给定的时间内无其它消息发送则发送一个Heartbeat心跳消息。HeartBtInt的值应当被会话双方认同，由会话发起方定义并由会话接收者通过Logon消息进行确认。同一个HeartBtInt被会话双方——登录的发起者和登录的接受者共同使用。

2.1.6 Data integrity和Checksum

消息数据内容的完整性可以参用两种方式来验证：消息长度和效验码检查。

程序通过计算BodyLength域到（并包含）在CheckSum标记（“10=”）后的分界符的字符数与在BodyLength中标示的消息长度进行比较来完成完整性效验。

2.1.6 CheckSum

ChekSum完整性检查，通过计算从域“8=” 中“8”开始，包括紧跟在CheckSum标记域的分界符<SOH>每个字符的2进制和同CheckSum进行比较得到。

一个FIX消息校验和通过计算到ChechSum域（但不包括）的消息的每个字节和得到。然后，校验和被转换为模256的数字用于传送和比较。校验和在所有加密操作之后被计算。

产生校验和的代码示列如下：

char *GenerateCheckSum( char *buf, long bufLen )

{

static char tmpBuf[ 4 ];

long idx;

unsigned int cks;

for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );

sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) );

return( tmpBuf );

}

2.1.7 Message Ack

FIX协议不支持单个消息的确认。采用的是监控消息时隙的方法来进行消息恢复和验证。

普通的数据传送（无单个消息确认）通过消息序列间隙进行错误识别。每个消息由一个唯一的序列号进行标示。接收端应用程序负责监控接收消息序列号以识别消息间隙并产生重传请求。

每个FIX参与方必须为FIX会话维护两个序列号，一个是接收序列号，一个是发送序列号，两者都在建立FIX会话开始时初始化为1。每个消息被赋予一个唯一的序列号值，并在消息发送后递增。此外，每个收到的消息都有一个唯一的序列号，接收序列号计数器在收到每个消息后将会被递增。

当接收序列号与所希望得到的的正确序列号不必配时，必须采取纠错处理。

2.1.8 Encryption

加密算法由连接双方共同协商。

一个消息的任何一个域可以被加密并放在SecureData域中。然而，一些显示的标志域必须采用明文进行传输。为确保完整性，明文域可以在SecureData域中重复。

当使用加密时，建议但不是必须，所有的消息体都进行加密。如果一个消息中的重复组数据中的部分数据要加密，这个重复组必须全部进行加密。

预先协商好的加密算法在Logon消息中进行声明。

2.1.9 User definition field

FIX为给用户提供最大的灵活性，FIX协议允许用户自定义域。这些域在认同的参与者之间实现、应用，并且应注意避免冲突。

Tag数在5000 到9999保留用于用户自定义域。这些tag值用于企业联盟的信息交换。可以通过FIX网站进行注册。

10000以上保留用于单一企业内部使用。不用注册。

2.2 会话层协议

2.2.1 Logon登陆

建立一个FIX连接，分别包含3个操作：

? 创建通信层链路

? 接收者认证/接受发起者

? 消息同步（初始化）。

连接流程如下：

会话发起者同会话接收者建立通信链路，即TCP连接。

发起者发送一个Logon消息。接收者检查Logon消息，认证发起者身份。Logon消息包含支持之前双方协商好的认证方法所必须的数据。如果发起者被成功认证，接收者用一个Logon消息进行响应。如果认证失败，会话接收者将关闭链接，之前可以选择发送一个Logout消息以提示认证失败的原因。这个Logout消息不是必须发送的。

在发起者认证通过之后，接收者立即响应一个Logon确认消息。依据会话使用的加密方法，这个Logon消息可以，也可以不报还同样的会话密钥。发起者方将把接收方返回的Logon确认消息视为一个FIX会话建立的标志。如果会话接收方选择单边会话加密密钥，会话的发起方必须发送一个Logon消息到对方以确认密钥改变请求。这样，能让会话接收者知道发起者何时开始使用新的会话密钥。发起方和接收方必须在发送任何查询或新消息之前通过询问MsgSeqNum域来同步其消息。发起方能通过比较确认Logon消息的MsgSeqNum及下一个期望值来侦测消息的间隙。

2.2.2 Messsage exchange消息交换

初始化过程完成之后，将会进行正常的数据信息交换。主要包括管理消息和应用消息的传送。

2.2.3 Logout注销

正常的消息交换的终止将通过交换Logout消息来完成。一般设计上会发送一个TestRequest消息强制请求从对方获取Heartbeat。这样可以帮助判断没有序列间隙。

在实际的会话关闭前，Logout的发起者应等待对方响应一个Logout确认消息。这种方式给接收者在需要时一个执行任何间隙填充错作的机会。一旦ResendRequest消息被接收，接收者应发起Logout操作，并且接收者在适当的时间表内没有响应，会话可以终止。

2.2.4 重传请求消息

下面四项待补充：

重传请求消息

测试请求消息

重传请求消息

Reject消息

2.3 应用层协议（待补充）

最重要的：委托，查询，撤单，执行回报

3 国内现有应用方案

金证：/soft_market/

? 将Fix协议的请求通过C/C++或XML方式转化成业务系统对应协议，同时转发回处理结果回报。使得在业务系统与FIX接入方系统之间通过FIX协议进行互通连接。

国信：GsApi FPL成员

根网科技：/en1/child.php?id=46

恒生：/fundsjjhy/555.htm

深圳证券通信公司：.cn/main/index.shtml

Bloomberg、恒生、金证、根网、上期技术

4 如何开发FIX程序

4.4.1 开发需求

短期需求： 实现FIX4.2协议的客户端接入。 快速准确的协议解释及翻译。 与恒生柜台高速有效地通讯。 实现路由功能，作为客户端和服务端的适配器，实现星型连接。 实现基本的股票交易查询等功能点。 强大的监控功能。 具备安全性保障。

4.4.2 开发方法

一般情况下，FIX开发中涉及到两方面，一个是会话层和应用层。应用层即业务逻辑相关的层面，在把握好业务逻辑后，相对固定简单。然而对于会话层的实现，涉及太多的方面，因此推荐采用现有的FIX引擎来开发。

/products/1列出了全球很多公司的183种不同FIX engines，当然，还包括一些没有登记上去的FIX engine。国内现有的开发主要采用开源并且跨语种的QuickFIX引擎。

QuickFIX可以灵活的运用在C++、C#、Java、Python、Ruby等编程语言之中。该引擎是目前应用较为广泛的FIX协议应用程序，但关于QuickFIX的文档还不是很多，有关它的技术资料可以登陆查看。

4.4.2 测试方法（待补充）

会话层测试方法 应用层测试方法

参考文献 《FIX-5.0_VOL-X》

《FIX-4.2_VOL-X》

《标准化和FIX协议：建立标准的市场源头》

《中信证券FIX网关接入说明》

《金融数据交换国际标准在证券》

金证《FIX网关解决方案.ppt》 《new order single.pdf》