银行接口及系统改造方案1.docVIP

银行接口及系统改造方案 2012-3-30 鉴于交易所艺术品网络报价交易系统的实际业务中，要求能够完成交易所保证金账户中的资金到账验证、后续业务退款、成交款项结转和佣金扣除等业务流程，现将银行提供的【大宗三方存管平台】接口情况和报价系统的相关改造情况介绍如下： 银行大宗三方存管平台简介 该平台运行在基于请求/响应的模式下；采用HTTPS 1.0/1.1作为交易市场交易系统与大宗三方存管平台之间的通信协议，采用双向数字证书认证确保通讯的安全；传输XML信息格式符合XML 1.0规范，采用数字签名技术确保通信数据的安全性。 交换信息格式采用自定义的XML报文格式，具体采用层次化结构的XML数据块作为请求与响应的数据内容。 XML块结构 HXBB2B ---------- XML块顶层 MessageData ---------- xml信息消息体 SignData ---------- 数据签名块（对报文头和报文体的签名） 说明： 报文的标记均采用大写字母开头，后续单词也大写的方式描述。 每个请求都包含请求报文头和报文体。 每个响应都包含响应报文头和报文体。 报文头部分描述请求/响应的交易相关系统信息。 报文体部分描述具体的交换数据部分。 数据签名块是对报文头和报文体的签名，只有当HXBB2B的signflag属性指明已签名，并且系统需要验证签名时才进行签名验证。 整体结构 请求报文整体结构 B2B报文块：{报文基本信息 | 请求头信息 | 报文体 | 签名块} 响应报文整体结构 B2B报文块：{报文基本信息 | 响应头信息 | 报文体 | 签名块} 报文基本信息 报文基本信息的结构如下： {版本号 | 签名标志 | } 报文体信息 DataBody是交易报文的工作单元，每一个请求和响应都包括DataBody，DataBody描述交易中交换数据需要的信息。其中每个交易都包括MerTxSerNo、BankTxSerNo、TrnxCode。 MerTxSerNo是交易市场流水号，BankTxSerNo是银行流水号，一个交易对应一个MerTxSerNo和一个BankTxSerNo，如果是交易市场主动发起的交易，则交易市场在请求报文中必须给出MerTxSerNo，银行对交易响应时必须返回银行端流水号BankTxSerNo；反之，如果是银行主动发起的交易，则银行在请求报文中必须给出BankTxSerNo，交易市场对交易响应时必须返回交易市场端流水号MerTxSerNo。 BankTxSerNo银行流水号为20位长度=8位年月日(yyyymmdd)+3位随机数+8位毫秒数(距离当日00:00:00到现在为止逝去的毫秒数，不足8位高位补0)+1位转账标示。 MerTxSerNo交易市场流水号长度由交易市场确定，原则上不超过30位。 TrnxCode是交易请求类型代码，对于不同的交易不同，服务器对不同的交易有特定的数据要求和处理方式和响应方式。 信息同步 对于大宗三方存管平台数据交换，同步主要是在报价系统系统发出交易指令请求时使用。考虑下面的情况：报价系统发出转账请求，大宗三方存管平台也成功处理，并发出了表示转账成功的响应消息，由于通信故障等原因，报价系统未能正确收到响应。如果是仅仅是查询，由于可以执行多次，报价系统在故障排除后重新发出请求获得结果即可，但对于不可重复执行的转账类型的请求，就要求在未收到执行成功的转账指令再次提交之前，从大宗三方存管平台取得同步标记，以确定该笔交易的处理结果。 针对转账同步逻辑的实现有两种方法，第一种为显性同步，报价系统在生成指令的时候即生成一个唯一的指令ID，大宗三方存管平台保留此ID及执行结果，报价系统在发出转账请求并未能收到结果时下一轮操作首先会针对此ID发起查询，大宗三方存管平台返回明确的处理结果。第二种是隐性同步，报价系统仅发起转账交易，在未收到大宗三方存管平台响应的时认为状态错误，下一轮仍发起转账请求而ID不变，大宗三方存管平台收到请求后首先做ID判断，如果ID曾收到过，则返回此ID指令的结果，如未收到过，则执行并返回结果。 本着简化操作、明确功能分工，减少不必要的误解，本系统使用第一种同步方式，即在报价系统未知银行大宗三方存管平台处理结果的情况下，必须先发起查询交易；银行大宗三方存管平台不接受非查询类的重复ID交易。 系统开发步骤 1）银行与交易所达成合作意向，并签署相关协议； 2）银行把通讯协议、报文格式、交易类型、数据交换内容、安全措施以书面或者电子文档提供给交易所； 3）交易所根据数据交换方式进行相应开发； 4）如果采用专线方式，银行和交易所进行专线的开通和调试； 5）开发完成后，交易所在银行测试环境进行联调测试（如果银行无测试环境，则直接在生产环境进行模拟测试）