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

银行接口及系统改造方案2012-3-30鉴于交易所艺术品网络报价交易系统的实际业务中，要求能够完成交易所保 证金账户中的资金到账验证、后续业务退款、成交款项结转和佣金扣除等业务流 程，现将银行提供的【大宗三方存管平台】接口情况和报价系统的相关改造情况 介绍如下：1. 银行大宗三方存管平台简介该平台运行在基于请求/响应的模式下；采用HTTPS 1.0/1.1作为交易市场 交易系统与大宗三方存管平台之间的通信协议，采用双向数字证书认证确保通讯 的安全；传输XML信息格式符合XML 1.0规范，采用数字签名技术确保通信数据 的安全性系统结构HTTPS交换信息格式采用自定义的 XML 报文格式，具体采用层次化结构的 XML 数据块作为请求与响应的数据内容1.1 XML块结构vHXBB2B> XML 块顶层 xml 信息消息体 数据签名块(对报文头和报文体的签名)说明：1) 报文的标记均采用大写字母开头，后续单词也大写的方式描述2) 每个请求都包含请求报文头和报文体3) 每个响应都包含响应报文头和报文体4) 报文头部分描述请求 /响应的交易相关系统信息。

5) 报文体部分描述具体的交换数据部分6）数据签名块是对报文头和报文体的签名，只有当HXBB2B的signflag属 性指明已签名，并且系统需要验证签名时才进行签名验证1.2 整体结构1.2.1 请求报文整体结构B2B 报文块：｛报文基本信息 | 请求头信息 | 报文体 | 签名块｝1.2.2 响应报文整体结构B2B 报文块：｛报文基本信息 | 响应头信息 | 报文体 | 签名块｝1.3 报文基本信息 报文基本信息的结构如下： ｛版本号 | 签名标志 | ｝1.4 报文体信息DataBody 是交易报文的工作单元， 每一个请求和响应都包括 DataBody ， DataBody 描述交易中交换数据需要的信息其中每个交易都包括 MerTxSerNo、 B ankTxSerNo、TrnxCode MerTxSerNo 是交易市场流水号， BankTxSerNo 是银行流水号，一个交易 对应一个 MerTxSerNo和一个BankTxSerNo,如果是交易市场主动发起的交 易，则交易市场在请求报文中必须给出 MerTxSerN o,银行对交易响应时必须 返回银行端流水号BankTxSerNo；反之，如果是银行主动发起的交易，则银行 在请求报文中必须给出BankTxSerNo，交易市场对交易响应时必须返回交易市 场端流水号 MerTxSerNo。

BankTxSerNo银行流水号为20位长度=8位年月日（yyyymmdd）+3位随机数 +8位毫秒数（距离当日 00:00:00到现在为止逝去的毫秒数，不足8位高位补0）+1 位转账标示MerTxSerNo交易市场流水号长度由交易市场确定，原则上不超过30位TrnxCode 是交易请求类型代码，对于不同的交易不同，服务器对不同 的交易有特定的数据要求和处理方式和响应方式1.5 信息同步对于大宗三方存管平台数据交换，同步主要是在报价系统系统发出交易指令 请求时使用考虑下面的情况：报价系统发出转账请求，大宗三方存管平台也成 功处理，并发出了表示转账成功的响应消息，由于通信故障等原因，报价系统未 能正确收到响应如果是仅仅是查询，由于可以执行多次，报价系统在故障排除 后重新发出请求获得结果即可，但对于不可重复执行的转账类型的请求，就要求 在未收到执行成功的转账指令再次提交之前，从大宗三方存管平台取得同步标 记，以确定该笔交易的处理结果针对转账同步逻辑的实现有两种方法，第一种为显性同步，报价系统在生成 指令的时候即生成一个唯一的指令ID,大宗三方存管平台保留此ID及执行结果， 报价系统在发出转账请求并未能收到结果时下一轮操作首先会针对此ID发起查 询，大宗三方存管平台返回明确的处理结果。

第二种是隐性同步，报价系统仅发 起转账交易，在未收到大宗三方存管平台响应的时认为状态错误，下一轮仍发起 转账请求而ID不变，大宗三方存管平台收到请求后首先做ID判断，如果ID曾 收到过，则返回此ID指令的结果，如未收到过，则执行并返回结果本着简化操作、明确功能分工，减少不必要的误解，本系统使用第一种同步 方式，即在报价系统未知银行大宗三方存管平台处理结果的情况下，必须先发起 查询交易；银行大宗三方存管平台不接受非查询类的重复ID交易1.6 系统开发步骤1） 银行与交易所达成合作意向，并签署相关协议；2） 银行把通讯协议、报文格式、交易类型、数据交换内容、安全措施以书面或 者电子文档提供给交易所；3） 交易所根据数据交换方式进行相应开发；4） 如果采用专线方式，银行和交易所进行专线的开通和调试；5） 开发完成后，交易所在银行测试环境进行联调测试（如果银行无测试环境， 则直接在生产环境进行模拟测试）；6） 测试通过后，将报价系统安装在生产环境并与银行的生产环境进行模拟测试；7） 报价系统在生产环境中试运行，如果试运行成功则正式运行，否则重新进行 测试2. 报价系统的接口设计与相关变更2.1 流程变更描述1）系统用户在注册时，需要提交有效的银行卡号在报价系统和第三方存管平台 进行绑定签约（如果客户持有的是银行账号，则需要到银行网点进行签约，不能 通过系统直接绑定签约）；2）用户在进行艺术品委卖或者报价后，根据系统提示，到银行网点或者通过网 银对交易所保证金账户进行保证金交纳转账；3）报价系统通过接口实时（或每 10 分钟）从银行获取资金到账明细信息；4）在获取有效的到账信息后，报价系统通过既定规则（或者由客户确认）来判 断用户对应艺术品的保证金是否缴纳以及用户报价是否有效；5）在交易结束后，通过报价系统和银行接口中已有的客户账号数据，对未成交 客户进行退款，成交双方进行扣缴款的操作。

2.2 艺术品保证金到账验证的两种方式：通过华夏接口，均为线下缴纳保证金方式在客户银行卡号已经签约绑定的 情况下，通过华夏第三方存管平台接口，能够实时（或每10 分钟）获取入账资 金的来源账户信息，并反馈回报价系统签约的对应用户虚拟账号再根据系统中 用户信息进行比对，识别是由哪个用户进行的转账汇款然后可以通过以下两种方式，将用户的保证金到账信息与艺术品进行对应：2.2.1 用户手动确认1）报价系统从银行端获取对应账户缴费明细，并计入系统用户的“保证金可用 余额”，此时保证金为【可用状态】；2）客户选定艺术品进行保证金支付确认；3）报价系统将客户的虚拟账户中对应金额划转为【冻结状态】；4）系统将客户保证金与实际报价的艺术品进行对应，判定该用户报价为有效状 态，并进行公布2.2.2 既定规则自动对应1）报价系统从银行端获取对应账户缴费明细，并计入系统用户的“保证金可用 余额”，此时保证金为【可用状态】；2）根据系统中对艺术品保证金扣缴次序设定的规则（如根据艺术品发布时间和 编码，报价的先后次序等），进行保证金的自动扣缴与用户提示，扣缴后的保证 金划为【冻结状态】；3）同时，对扣缴过保证金的艺术品报价，设定为有效状态，并进行公布。

注：一旦客户在系统中选定一个或者多个艺术品进行报价，那么只要用户“保证金可用余额” 中还有款项，就会自动由系统即时（或每10 分钟）按照既定扣缴规则，对艺术品进行保证 金的扣款处理2.3 保证金退还 对于不符合交易系统条件的银行到账，将采取自动原路退还的方式进行处 理对于未成交用户的保证金，将在艺术品交易结束后，按照艺术品批次自动进 行批量退款对于系统中自动退款的条件包含但不限于以下： 到账的客户银行账号在交易系统中不存在； 退款的银行账号在交易系统中不存在； 人民币账号格式不正确；查询时间不正确；字符集输入不正确； 允许查询的时间段不正确； 查询过程异常，请稍后再试； 签名字符串不匹配，您无权查询； 查询结果超出能允许的文件范围2.4 数据字典 证件类型：1 -个人身份证2 -军人证3 -护照4 -组织机构代码5 -其他2.5 待确认内容 后续与银行需要再次讨论确认的内容，包括但不限于以下：1、客户转账的手续费率 银行账户不收取手续费；他行账户按照人民银行网关的费率，区分为大、小额进 行收费，其中柜面转账最高每笔 200 元，网银支付每笔 7 折最高 140 元2、交易所退款的手续费率 需要后期与华夏协商。

3、签约方式，以及签约的对应接口协议（交易商信息同步中“子账号”字段） 签约的卡号同时还要记录在存管平台，需要提示客户真实填写，否则影响保证金 验证与退款等后续业务4、银行端需要能够进行资金冻结操作5、关于接口文档中，各类流程业务名称的约定： 入金、出金、子账户、摊位号等2.6 接口交易的定义：报价系统在实现银行接口信息交互的过程中，主要采取由报价系统发起查 询，银行端提供接口服务反馈数据的方式包含如下接口动作：1、子账户同步2、签到3、签退4、客户入金查询5、客户信息同步 客户在银行【签约】、【修改】或【解约】信息的报文规范解约客户的银行账户 中对应余额必须为06、客户解约7、出金审核结果发送8、报价系统出金9、出入金明细核对10、清算11、对账12、子账户签约13、入金申请14、入金等级申请15、银行子账户余额查询2.7 银行平台端需要提供或者记录的数据包含但不限于以下：1、子账号2、子账号银行账户3、子账户名称4、性质（个人/企业）5、银行当前总余额6、可用余额。