上海支付结算综合业务系统银行接口规范

版本号：1.05

二○○八年十一月

深圳市雁联计算系统有限公司

分发

版本控制

批阅意见

第1章 概述

1.1 目的

本文旨在描述上海支付结算综合业务系统与商业银行行内系统之间的接口规范，同时说明商业银行需要配合参与的工作。

各商业银行可以依据本接口规范进行接口设计和银行部分的开发工作。

1.2 系统概述

上海支付结算综合业务系统是应用现代计算机技术、网络通讯和安全保密技术，改造并取代传统的处理模式，将各类跨行借、贷方票据业务及转账业务信息转为电子信息流，通过网络互联等手段实现同行内有关部门、国有商业银行、其他金融机构的联结，加速资金周转，实现柜面票据及转账业务的实时发起、实时入客户账，为社会提供优质的支付结算服务。

1.3 系统总体结构

系统总体结构如上图所示，对于直联银行，当发生跨行业务时，通过接口API发往中心进行业务处理。对于间联银行，通过客户端将业务发往中心进行业务处理。

1.4 接口概述

商业银行行内系统与上海市支付结算综合业务系统的联接可以分为两种方式：一种是直联模式，另一种是非直联模式。

本接口规范主要描述直联模式接口。

1.4.1 非直联模式

通过中心提供的客户端，实现与上海市支付结算综合业务系统的联接。

1.4.2 直联模式

通过接口调用接口API实现与上海市支付结算综合业务系统的联接。

1.5 定义、缩写词和术语

第2章 业务范围

采用直联模式的商业银行主要有以下业务：

本行发起的业务包括：

1) 贷记业务

2) 贷记退汇业务

3) 借记业务

4) 借记冲正业务

5) 票据影像业务

6) 专用内部账户调拨

7) 查询查复业务

8) 交易明细查询

9) 账户信息变更

10) 网点信息变更

11) 账户余额查询

本行接收的业务包括：

1) 贷记业务

2) 贷记退汇业务

3) 借记业务

4) 借记冲正业务

5) 票据影像业务

6) 专用内部账户调拨

7) 查询查复业务

8) 手续费明细

9) 行号信息变更

10) 网点信息变更

11) 账户余额查询

12) 银行资金清算报文

第3章 接口主要业务流描述

本节流程图主要是为了说明业务处理过程中的报文交互，图中报文的发起和接收，并不是说明处理是同步模式进行的，其实我们提供的API的消息处理模式是异步的，关于异步转同步的处理机制由商行自己决定。

3.1 系统工作日和状态

综合业务系统有工作日期和清算日两个时间概念。工作日期是对外提供服务的工作时间；清算日是在人行会计核算系统（ABS）上完成最终资金清算的当日，可能和工作日期一致，也可能较工作日期延迟。

综合业务系统提供7*24小时服务。

综合业务系统每日16：30下发“日切通知”，日切后系统进入下一工作日期，日切时间可调整。

3.2 业务种类

综合业务系统的主要业务包括以下几类：支付类业务、信息类业务、资金类业务和管理类业务。

 支付类业务主要包括：贷记业务、贷记退汇业务、借记业务、业务冲正；

 信息类业务主要包括：查询/查复业务、交易明细查询、自由格式信息、账户信息变更、专用内部账户调拨、票据影像业务、账户余额查询业务；

 资金类业务主要包括：资金对账、资金清算。

 管理类业务主要包括：系统登陆/退出、日切通知、场次变更通知、系统状态变更、通讯状态检查等；

3.3 支付业务描述

3.3.1 贷记业务-网银（自助渠道）

【 参与者 】: 业务处理中心、入网银行机构。

【 功能描述 】: 商业银行同城网上银行跨行转账业务，通过完成与综合业务系统的接口开发，实现实时进行跨行贷记转账。

考虑到一些特殊情况，商业银行也可以在柜面按照网银的业务流程发起贷记业务。

【 流程图 】:

【 流程 】:

1. 网银客户向发起行发起网银转账业务，发起行通过合法性检查后，如果发起行为直联银行，则直接向业务处理中心系统发起网银贷记业务（SMP001，业务标志为02-网银，下同）；如果发起行为间联银行，业务落地后，通过中心提供的银行客户端，向业务处理中心系统发起网银贷记业务。

2. 业务处理中心系统审核收到的网银贷记业务，并将审核结果（“已转发”或者“已拒绝”）以支付业务回执（SMP009，下同）的方式返回给发起行；

发起行收到“已转发”的支付业务回执：继续等待业务处理中心系统转发来的接收行返回的支付业务回执；

发起行收到“已拒绝”的支付业务回执：结束该笔贷记业务。

发起行可对网银业务进行处理后再次发起一笔新的贷记业务（生成新的流水号）。

所有业务均在处理中心转发接收行后，才将业务处理回执“已转发”返回发起行（下同）。

3. 业务处理中心系统保存审核通过的网银贷记业务。

4. 业务处理中心系统将审核通过的网银贷记业务转发到接收行；

5. 接收行收到业务处理中心转发来的网银贷记来账业务，并进行处理；

6. 接收行将处理结果以支付业务回执的方式返回给业务处理中心系统，对于间联银行可以以手工方式通过中心提供的银行客户端返回给业务处理中心；

7. 业务处理中心系统收到接收行返回的支付业务回执后进行审核，如果审核不通过，将审核结果（拒绝）以支付业务回执的方式返回给接收行；如果审核通过，则修改该笔贷记交易状态；

8. 业务处理中心系统将收到的接收行返回的支付业务回执转发给发起行；

9. 发起行收到业务处理中心转发来的支付业务回执进行相应账务处理。

【 说明 】:

1. 支付业务回执的发起行为业务处理中心时，表明是该回执由业务处理中心主动发起，否则表明该回执是商业银行主动发起。

2. 支付业务回执中的附言中应注明处理结果的说明。（返回码说明详见5.3.5，下同）

3. 当集团客户通过网银发起贷记业务有特殊用途时，发起行应该将该笔业务按照柜面业务方式处理。

4. 贷记退汇时间原则上应不超过T+1，系统不接受当天发起退汇业务。

5. 发起行发起网银贷记业务有两种方式：

发起行行内系统与业务处理中心直联：所有业务均通过行内系统直接转发到业务处理中心；

发起行行内系统与业务处理中心间联：所有业务均在业务处理中心提供的银行客户端直接录入，并提交给业务处理中心系统；

6. 第（2）步业务处理中心对收到的网银贷记业务进行审核主要包括以下内容：发起行状态、发起行登录状态、密押验证、是否重票（按交易流水号、清算行行号、工作日期检查）。

7. 网银业务对接收行状态、接收行登陆状态不做控制，如果发生接收行存在通讯异常、未登录等状态，业务处理中心依然将该业务转发，对于接收行未返回支付业务回执的业务依然纳入清算。

8. 第（7）步业务处理中心对收到的网银贷记业务进行审核主要包括以下内容：工作日期。

9. 对于间联的商业银行，通过业务处理中心提供的银行客户端录入网银贷记业务时，应该进行复核。

【 异常处理 】:

1. 业务处理中心端异常处理

1) 业务处理中心系统如果无法转发网银贷记业务时，则该笔贷记业务不纳入清算，以支付业务回执方式（SMP009）退回给发起行。

2) 业务处理中心如果收到往账时发现收到的某笔往账重票（按流水号、工作日期、发起清算行行号检查），以支付业务回执的方式返回“该笔业务重票”的拒绝信息给发起行。

2. 发起行异常处理

1) 发起行发起网银贷记业务后如果未收到业务处理中心系统返回的支付业务回执报文，则默认该笔业务“已转发”；

2) 发起行如果在T+0日内收到“已转发”的支付业务回执报文后未收到业务处理中心转发回来的“已成功”的支付业务回执报文（SMP009），则默认该笔业务成功。在日终对账时，发现对账不符，根据业务处理中心下载的对账明细报文，对该笔业务进行撤消或确认成功。

3) 对于网银业务，发起行可以不做超时检查，但是在交易状态不明的清况下可以发起交易明细查询业务（SMP207），进一步查询该笔交易在业务处理中心的状态。

3. 接收行异常处理

1) 如果接收行“成功”的支付业务回执报文（在规定时间T+0内未发送到业务处理中心系统，则该笔业务将被纳入当天日终清算，如果接收行场终对账不平，由接收行下载明细调账，调账不成功则可发起贷记退汇业务。

2) 接收行不应在下一工作日期返回支付业务回执报文，如果返回回执也将被业务处理中心拒绝，被业务处理中心拒绝后应检查原交易状态，如“已成功”或“已退票”则不作任何处理,“已拒绝”则发起退汇业务。

3) 如果接收行出现通讯异常、系统故障等情况在日终清算后仍然无法接收交易及对账，可向业务处理中心申请以人工方式打印和导出交易数据及对账文件，并做相应账务处理。（中心负责导出，数据格式见附录。）

【 业务状态变迁 】:

● 业务处理中心业务状态变迁

说明：

1. 业务处理中心收到发起行发起的网银贷记业务，审核该网银贷记业务，并根据审核结果将收到的贷记业务的状态分别置为“已转发”或者“已拒绝”；对审核通过的业务，将其转发给接收行，并等待接收行回应。同时将审核结果通过支付业务回执报文发送发起行。

2. 业务处理中心收到接收行对贷记来账业务的支付业务回执，根据支付业务回执的状态将对应贷记业务的状态更新为“已成功”或“已失败”；

● 发起行业务状态变迁

说明：

1. 网银客户发起网银贷记业务，此时业务状态为“待发送”。

2. 对于直联银行，行内系统发现有待发送业务，则发送该笔贷记业务到业务处理中心，并将该笔业务状态更新为“待回应”；对于间联银行，该笔业务在客户端录入后，将该笔业务更新为“待回应”。

3. 对于直联银行，“待回应”状态的贷记往账业务接收业务处理中心系统返回的支付业务回执，根据支付业务回执的结果（被拒绝或者已转发）分别将状态置为“被拒绝”或者“已转发”；对于间联银行，可以人工将行内业务状态更新为“被拒绝”或者“已转发”。

4. 对于状态为“已转发”的贷记往账业务，在接收到由业务处理中心系统转发的接收行返回的支付业务回执后，将状态修改为“已成功”或者“已失败”。

● 接收行业务状态变迁

说明：

1. 接收行如果对接收到的来账入账失败，可以发起贷记退汇业务。并在贷记退汇业务报文的附言中注明拒绝\退票理由。

3.3.2 贷记业务-普通

【 参与者 】: 业务处理中心、入网银行机构。

【 功能描述 】: 实时进行跨行贷记转账业务（网银业务除外）。商业银行柜面发起实时贷记业务，接收行实时入客户账并发起回执。

【 流程图 】:

【 流程 】:

1. 发起行向业务处理中心系统发起账户信息查询请求业务（SMP101），查询接收方账户信息；

2. 业务处理中心系统接收账户信息查询请求业务（SMP101），并通过账户信息查询回执（SMP102）返回接收方账户信息；

3. 发起行接收账户信息查询回执（SMP102），并根据回执内容填写接收方账户信息。

4. 根据规定，发起行可依据账户信息和有关业务要素，如账号、金额、委托日期等，验证客户委托凭证真实性。

5. 发起行向业务处理中心系统发起贷记业务（SMP001，业务标志02-网银除外），其中交易流水需要沿用账户信息查询请求业务交易流水；

6. 业务处理中心系统审核收到的贷记业务，如果审核通过，保存贷记业务（SMP001），并转发到接收行。

7. 同时将审核结果（“已转发”或者“已拒绝”）以支付业务回执（SMP009）的方式返回给发起行；

发起行收到“已转发”的支付业务回执：继续等待业务处理中心系统转发来的接收行返回的支付业务回执；

发起行收到“已拒绝”的支付业务回执：结束该笔贷记业务。

8. 接收行收到业务处理中心转发来的贷记来账业务（SMP001），并进行处理；

9. 接收行将处理结果以支付业务回执（SMP009）的方式返回给业务处理中心系统；

10. 业务处理中心系统收到接收行返回的支付业务回执（SMP009）后进行审核，如果审核不通过，将审核结果（拒绝）以支付业务回执（SMP009）的方式返回给接收行；如果审核通过，则修改该笔贷记交易状态；业务处理中心系统将收到的接收行返回的支付业务回执（SMP009）转发给发起行；

11. 发起行收到业务处理中心转发来的支付业务回执（SMP009）进行相应账务处理。

【 说明 】:

1. 因私账户当天开户可发起贷记业务，不可接收实时贷记业务。

2. 商业银行核验客户委托凭证真实性，可根据需要自行决定（采用验印或核验支付密码）。

3. 发起行在发起联机查询账户信息交易时，可以只输入账号信息，凭账号信息到业务处理中心查询其他账户相关信息，如果业务处理中心返回该账号重复，则发起行可以再次发起凭账号和接收清算行行号的账户信息查询请求。

4. 同时，由于柜面实时业务处理时间要求较高，发起行应在发起交易时，根据客户账号通过行内预留的账户信息生成账户名称、发起清算行行号、发起行机构号、发起行机构名称等相关信息返回给柜员。

5. 发起行发起贷记业务有两种方式：

发起行行内系统与业务处理中心直联：所有业务均由银行网点发起并通过行内系统直接转发到业务处理中心；

发起行行内系统与业务处理中心间联：所有业务均在业务处理中心提供的银行客户端直接录入，并提交给业务处理中心系统；

6. 第（6）步业务处理中心对收到的贷记业务进行审核主要包括以下内容：发起行状态、接收行状态、发起行登录状态、接收行登录状态、密押验证，按照业务种类检查是否要求查询、是否重票（按交易流水号、清算行行号、工作日期检查）。

7. 第（10）步业务处理中心对收到的贷记业务进行审核主要包括以下内容：工作日期。

8. 贷记业务的发起，必须经过录入、复核两个阶段。对直联的商业银行，录入、复核由行内系统控制；对间联的商业银行，由业务处理中心提供的银行客户端控制录入、复核。

9. 业务处理中心系统将对间联银行客户端登陆数量予以控制。

10. 支付业务回执在T+0时间有效。

【 异常处理 】:

1. 业务处理中心端异常处理

1) 业务处理中心系统如果转发失败，则该笔贷记业务不纳入清算，并退回给发起行。

2) 业务处理中心如果收到往账时发现收到的某笔往账重复发送（按流水号、工作日期、发起清算行行号检查），以支付业务回执的方式返回返回“该笔业务重票”的拒绝信息给发起行。对不同流水号，但其他相关要素相同的业务不做控制。

2. 发起行异常处理

1) 发起行发起贷记业务后如果未收到业务处理中心系统返回的支付业务回执报文（已转发），则默认该笔贷记业务“已转发”且 “已成功”；柜员可以发起交易明细查询业务（SMP207），进一步查询该笔交易在业务处理中心的状态。

2) 发起行如果收到“已转发”的支付业务回执报文（SMP009）后未收到业务处理中心转发回来的“已成功”的支付业务回执报文（SMP009），则可默认该笔业务成功。柜员可以发起交易明细查询业务（SMP207），进一步查询该笔交易在业务处理中心的状态。在日终对账时，如果发现业务处理中心该笔业务为“失败”则撤消行内系统该笔业务，并于下一工作日重新发起该笔贷记业务。

3) 发起行对此类业务应设置超时检查，超时时间可设为N+10s，其中N为中心超时时间，N为参数化设置，在上线之前公布的业务规范中定义（目前初步定义为60s）。如果接收行是直联银行，发起行在超时时间内未接收到接收行返回的“已成功”或者“已失败”回应，则发起业务的商业银行交易状态应更新为“待确认”，通知客户交易已转发，当前交易状态不明。柜员可以发起交易明细查询业务（SMP207），进一步查询该笔交易在业务处理中心的状态。

4) 如发生贷记业务交易状态不明的情况，建议柜面人员告知付款客户协调收款客户，收款客户可要求开户行查明原因。

3. 接收行异常处理

1) 如果接收行“成功”的支付业务回执报文（SMP009）未发送到业务处理中心系统，则该笔业务将被纳入当天日终清算，如果接收行日终对账不平，由接收行下载明细调账，调账不成功则发起贷记退汇业务。

2) 接收行不应在下一工作日期返回的支付业务回执报文，如回执也将被业务处理中心拒绝，如被业务处理中心拒绝后应检查原交易状态，如“已成功”或“已退票”则不作任何处理,如“已拒绝”则发起退汇业务。

3) 如果接收行出现通讯异常、系统故障等情况在日终清算后仍然无法接收交易及对账，可向业务处理中心申请以人工方式打印和导出交易数据及对账文件，并做相应账务处理。

3.3.3 贷记退汇业务

贷记退汇业务处理模式同贷记业务相同。但贷记退汇业务只能针对收到的贷记业务发起，在发起前应该先匹配收到的贷记业务。贷记退汇业务不要求作账户信息查询。

【 参与者 】: 业务处理中心、入网银行机构。

【 功能描述 】: 实时进行跨行贷记退汇转账的业务。原发起的流水号、原发起清算行行号、原工作日期为发起贷记退汇业务的唯一标准。

【 流程图 】:

【 流程 】:

1. 发起行向业务处理中心系统发起贷记退汇业务（SMP003）；

2. 业务处理中心系统审核收到的贷记退汇业务，并将审核结果（“已转发”或者“已拒绝”）以支付业务回执（SMP009）的方式返回给发起行；如果拒绝，则结束后面处理；

发起行收到“已转发”的支付业务回执：继续等待业务处理中心系统转发来的接收行返回的支付业务回执；

发起行收到“已拒绝”的支付业务回执：结束该笔贷记退汇业务。

3. 业务处理中心系统保存审核通过的贷记退汇业务。

4. 业务处理中心系统将审核通过的贷记退汇回执业务（SMP003）转发到接收行；

5. 接收行收到业务处理中心转发来的贷记退汇来账业务（SMP003），并进行处理，接收行不应拒绝贷记退汇业务；

6. 接收行将处理结果以支付业务回执（SMP009）的方式返回给业务处理中心系统；

7. 业务处理中心系统收到接收行返回的支付业务回执（SMP009）后进行审核，如果审核不通过，将审核结果（拒绝：已清算）以支付业务回执（SMP009）的方式返回给接收行；如果审核通过，则修改该笔贷记交易状态；

8. 业务处理中心系统将收到的接收行返回的支付业务回执（SMP009）转发给发起行；

9. 发起行收到业务处理中心转发来的支付业务回执（SMP009）进行相应账务处理。

【 说明 】:

1. 发起行可以通过两种连接方式（直联/间联）发起贷记退汇业务，无论通过哪一种连接方式发起的贷记退汇业务，只要业务处理中心转发后，则不允许发起行再做“失败”处理。

发起行行内系统与业务处理中心直联：所有业务均由银行网点发起并通过行内系统直接转发到业务处理中心；

发起行行内系统与业务处理中心间联：所有业务均在业务处理中心提供的银行客户端直接录入，并提交给业务处理中心系统；

2. 第（2）步业务处理中心对收到的贷记退汇业务进行审核主要包括以下内容：发起行状态、接收行状态、发起行登录状态、接收行登录状态、密押验证、是否与原交易匹配、是否重票、退汇日期（必须是T+1）。

3. 第（7）步业务处理中心对收到的贷记退汇业务进行审核主要包括以下内容：工作日期。

4. 贷记业务的发起，必须经过录入、复核两个阶段。对直联的商业银行，录入、复核由行内系统控制；对间联的商业银行，由业务处理中心提供的银行客户端控制录入、复核。

【 异常处理 】:

1. 业务处理中心端异常处理

1) 业务处理中心系统如果处理失败，则该笔贷记退汇业务不纳入清算，并退回给发起行。如贷记退汇失败，则原接收行发起普通贷记业务，并在附言中说明。

2) 业务处理中心如果收到往账时发现收到的某笔往账重票（按流水号、工作日期、发起清算行行号检查），以支付业务回执的方式返回返回“该笔业务重票”的拒绝信息给发起行。

2. 发起行异常处理

1) 发起行发起贷记退汇业务后如果未收到业务处理中心系统返回的支付业务回执报文（SMP009），则默认该笔贷记业务“已成功”；

2) 发起行如果收到“已转发”的支付业务回执报文（SMP009）后未收到业务处理中心转发回来的“已成功”的支付业务回执报文（SMP009），则默认该笔业务成功。

3. 接收行异常处理

1) 如果接收行“已成功”的支付业务回执报文（SMP009）未发送到业务处理中心系统，则该笔业务纳入当场清算，如果接收行场终对账不平，由接收行下载明细调账。

3.3.4 借记业务

【 参与者 】: 业务处理中心、入网银行机构。

【 功能描述 】:实时进行跨行借记转账的业务。实时借记业务的发起行可以是间联的商业银行，但接收行为必需是直联银行。

【 流程图 】:

【 流程 】:

1. 发起行向业务处理中心系统发起账户信息查询请求业务（SMP101），查询接收方账户信息；

2. 业务处理中心系统接收账户信息查询请求业务（SMP101），并通过账户信息查询回执（SMP102）返回接收方账户信息；

3. 发起行接收账户信息查询回执（SMP102），根据回执判断接收行是否是直联银行，如果不是直联银行则终止业务办理，如果是直联银行，则并根据回执内容填写接收方账户（相关）信息。

4. 发起行向业务处理中心系统发起借记业务（SMP002），其中交易流水需要沿用账户信息查询请求业务交易流水；

5. 业务处理中心系统审核收到的借记业务，如果审核通过，保存借记业务，并将借记业务（SMP002）转发到接收行。

6. 同时将审核结果（ “已发送”或者“已拒绝”）以支付业务回执（SMP009）的方式返回给发起行；

发起行收到 “已发送”的支付业务回执：继续等待业务处理中心系统转发来的接收行返回的支付业务回执；

发起行收到 “已拒绝”的支付业务回执：结束该笔借记业务。

7. 接收行收到业务处理中心转发来的借记来账业务（SMP002），根据相关信息自动核验支付密码，支付密码正确则记账处理，不正确则不记账；处理完毕后生成记账处理结果；

8. 接收行将处理结果以支付业务回执（SMP009）的方式返回给业务处理中心系统；

9. 业务处理中心系统收到接收行返回的支付业务回执（SMP009）后进行审核，如果审核不通过，将审核结果（拒绝：已冲正等）以支付业务回执（SMP009）的方式返回给接收行；如果审核通过，则修改该笔交易状态；

10. 业务处理中心系统将收到的接收行返回的支付业务回执（SMP009）转发给发起行；

11. 发起行收到业务处理中心转发来的支付业务回执（SMP009）进行相应账务处理。

【 说明 】:

1. 发起行发起借记业务有两种方式：

发起行行内系统与业务处理中心直联：所有业务均由银行网点发起并通过行内系统直接转发到业务处理中心；

发起行行内系统与业务处理中心间联：所有业务均在业务处理中心提供的银行客户端直接录入，并提交给业务处理中心系统；

2. 第（5）步业务处理中心对收到的借记业务进行审核主要包括以下内容：发起行状态、接收行状态、发起行登录状态、接收行登录状态、密押验证、按照业务种类检查是否要求查询、是否重票（根据交易流水、工作日期、发起清算行行号，不根据票号）。

3. 第（9）步业务处理中心对收到的借记业务进行审核主要包括以下内容：工作日期、是否已冲正。

4. 借记业务的发起，必须经过录入、复核两个阶段。对直联的商业银行，录入、复核由行内系统控制；对间联的商业银行，由业务处理中心提供的银行客户端控制录入、复核。

【 异常处理 】:

1. 业务处理中心端异常处理

1) 业务处理中心系统收到接收行返回的借记确认指令，如果处理失败，则该笔借记业务不纳入清算，并通过支付业务回执报文（SMP009）将处理结果分别转发发起行和接收行。

2. 发起行异常处理

1) 发起行发起借记业务后如果在规定业务时间内未收到业务处理中心系统返回“已转发”、“已拒绝”或 “已成功”的支付业务回执报文，则发起行可以通过柜面发起交易明细查询（SMP207）查询该笔交易目前在业务处理中心的交易状态，如果返回的交易状态为 “已失败”则中止该笔交易，如果为“已成功”发起行应修改该笔业务状态，变为已成功，如果为“已转发”，则再次发起查询，如果 “已拒绝”，则可以重新发起该笔交易。

2) 同时，发起行发起借记业务后如果在规定业务时间内未收到业务处理中心系统返回“已转发”、“已拒绝”或 “已成功”的支付业务回执报文，发起行也可以通过柜面发起冲正交易。

3) 发起行在发起冲正业务后，要将原交易置为“已冲正”，在极其特殊的情况下（冲正在前，交易在后），如果在冲正后仍然收到“已成功”的返回报文，需要再次发起冲正交易。

3. 接收行异常处理

1) 如果接收行“已成功”的支付业务回执报文（SMP009）未发送到业务处理中心系统，则该笔业务不纳入当场清算，如果接收行场终对账不平，由接收行下载明细对账，并冲回付款人账户。

2) 接收行在超过系统规定业务响应时间返回的支付业务回执报文（SMP009）被业务处理中心拒绝（拒绝：已冲正）后，检查原交易状态，如“已失败”则不作任何处理，如“已成功”则由接收行冲回付款人账户。

【 业务状态变迁 】:

● 业务处理中心业务状态变迁

说明：

1. 业务处理中心收到发起行发起的借记业务，将状态记为“已收妥”，并将借记业务转发到接收行，转发后将状态记为“已转发”；

2. 业务处理中心根据收到的接收行的返回结果将借记业务分别登记为“已成功”或者“已失败”；

3. 系统场终将成功业务纳入清算，将状态记为“已清算”

4. 业务处理中心收到发起行冲正交易将状态标记为“已冲正”。

● 发起行业务状态变迁

1. 发起行在同城客户端录入一笔借记业务，起状态登记为“待复核”；

2. 另一操作员对“待复核”状态的借记业务进行复核，并更新状态为“待发送”；

3. 行内系统将“待发送”状态的借记业务发送到业务处理中心，并更新状态为“待回应”；

4. 行内系统收到业务处理中心返回的确认接收信息后将状态修改为“已转发”

5. 在“已转发”状态下行内系统收到业务处理中心返回的接收行确认信息或者超时后分别将借记业务状态更新为“拒绝”/“成功”/“超时”。

● 接收行业务状态变迁

1. 接收行收到业务处理中心转发来的借记业务后将状态登记为“已收妥”，并转到行内进行处理；

2. 根据行内处理结果将状态修改为“成功”或者“拒绝”；

3. 如果在行内返回处理结果前收到发起行发起的冲正/撤消报文则将该借记业务登记为“被拒绝”；

行内冲正/撤消成功后将该借记业务登记为“已冲正/撤消”；

3.3.5 借记冲正业务

【 参与者 】: 业务处理中心、入网银行机构。

【 功能描述 】: 对于实时借记业务，如果接收行响应超时，则发起行可以主动发起冲正业务（SMP006）。中心接收到借记冲正业务后，如已收到接收行返回的支付业务回执，则通知发起行冲正失败，如未收到接收行返回的支付业务回执，则返回发起行冲正成功，之后将借记冲正指令转发接收行。

【 流程图 】:

【 流程 】:

1. 发起行向业务处理中心发起借记冲正业务（SMP006）。

2. 业务处理中心接收借记冲正业务（SMP006），中心检查原业务信息（原业务的关键要素是否一致，是否为发起方），如果原业务接收行已经返回支付业务回执，该业务的状态为“已成功”或“已失败”，则直接返回“冲正失败”的支付业务回执报文（SMP009）；如果原业务接收行未返回支付业务回执，该业务的状态为“已转发”，则标记该业务“已冲正”，返回“冲正成功”的支付业务回执报文（SMP009）给发起行，之后转发借记冲正报文给接收行。

3. 接收行收到借记冲正报文（SMP006）后，检查原业务信息（原业务的关键要素是否一致，是否为接收行），对原业务进行冲正处理。

3.4 信息业务描述

3.4.1 票据影像业务

【 参与者 】: 业务处理中心、参与银行机构

【 功能描述 】: 票据影像业务是在综合业务系统实现票据截流后，由发起行向接收行报送票据原始影像的业务，仅涉及借记业务。

尽量在下午17：00以后23：00之前。

【 流程图 】:

【 流程 】:

1. 发起行发起票据影像业务（SMP206），后台系统自动将票据影像业务发往业务处理中心系统；

2. 业务处理中心系统收到发起行发起的票据影像业务（SMP206），并转发到接收行；

3. 接收行收到业务处理中心系统转发来的票据影像业务（SMP206）后，根据SMP206报文中记录的相关借记业务的发起流水、委托日期以及票据号码，将票据影像与原借记业务匹配后进行存档处理，并将处理结果通过通用返回报文（SMP999）返回给业务处理中心系统；

4. 业务处理中心系统收到接收行返回的通用返回报文（SMP999）以后，将通用返回报文（SMP999）返回给发起行。

【 说明 】:

1. 票据影响业务主要用于商业银行事后监督，业务处理中心系统仅转发，不作任何账务处理。

3.4.2 专用内部账户调拨

【 参与者 】: 业务处理中心、参与银行机构

【 功能描述 】: 专用内部账户调拨业务是基于双方银行原有的相关协议，在协议指定的账户中付款的业务，该业务由发起行（付款银行）发出，经综合业务系统转发至接收行。接收行收到专用内部账户调拨报文后，依据专用内部账户调拨报文中指定的发起行在接收行行内开立的专用账户中直接扣款，并将款项转入专用内部账户调拨业务报文指定的收款人账户。接收行完成行内转账处理后，以专用内部账户业务回执包的形式将转账处理结果返回发起行。（设用途域，当标记为“特殊”业务时，填写“真实付款人账号，真实付款人名称”）

对于专用内部账户调拨业务，综合业务系统仅做业务报文的登记和转发，不做收、发报行间的轧差清算。

【 流程图 】:

【 流程 】:

1. 发起行发起专用内部账户调拨业务（SMP203），后台系统自动将专用内部账户调拨业务发往业务处理中心系统；

2. 业务处理中心系统收到发起行发起的专用内部账户调拨业务（SMP203），转发接收行并通过通用返回报文（SMP999）返回“已转发”响应给发起行；

3. 接收行收到业务处理中心系统转发来的专用内部账户调拨业务（SMP203），检查付款人账户合法性，合法则进行账务处理，并将处理结果通过专用内部账户调拨回执业务报文（SMP204）返回给业务处理中心系统；

4. 业务处理中心系统收到接收行返回的内部账户调拨回执业务报文（SMP204）以后，将内部账户调拨回执业务报文（SMP204）信息返回给发起行。

【 说明 】:

1. 发起行需设置权限管理，只有有权限的操作人员才可以发起该业务。

2. 付款账户根据发起行与接收行行协议捆绑，接收行收到专用内部账户调拨业务（SMP203）要检查付款账户合法性。

3. 发起行未收到业务处理中心通用返回报文（SMP999）“已转发”回执，可向业务处理中心发起查询报文。

4. 发起行收到业务处理中心通用返回报文（SMP999）“已转发”回执，未收到内部账户调拨回执业务报文（SMP204），可向接收行发起查询报文。

3.4.3 交易明细查询

【 参与者 】: 业务处理中心、参与银行机构

【 功能描述 】: 支付业务发起行可以向业务处理中心发起交易明细查询请求，查询某笔交易的当前状态。

【 流程图 】:

【 流程 】:

1. 发起清算行针对某笔同城清算业务发起交易明细查询业务（SMP207），后台系统自动将查询指令发往业务处理中心系统；

2. 业务处理中心系统收到发起行发起的交易明细查询业务（SMP207），并将查询该笔交易当前交易状态，并将查询结果通过交易明细查询回执（SMP208）返回发起行；

3.4.4 查询查复业务

【 参与者 】: 业务处理中心、参与银行机构

【 功能描述 】: 当某个银行对发起和接收到的某笔支付业务不明确，可以向接收或者发起行发起查询，接收或者发起行收到查询后对收到的查询进行查复。

【 流程图 】:

【 流程 】:

1. 发起清算行针对某笔同城清算业务发起查询业务（SMP201），后台系统自动将查询指令发往业务处理中心系统；

2. 业务处理中心系统收到发起行发起的查询业务（SMP201），并将查询业务（SMP201）转到接收行；

3. 接收行收到业务处理中心系统转发来的查询业务（SMP201），进行查复，并将查复业务（SMP202）返回给业务处理中心系统；

4. 业务处理中心系统收到接收行返回的查复业务（SMP202）以后，将查复业务（SMP202）信息返回给发起行。

【 说明 】:

1. 查询查复都是针对交易（支付业务）的查询查复；

2. 支付业务包括：贷记业务、贷记退汇业务、借记业务。

3.4.5 账户信息变更

【 参与者 】: 业务处理中心、参与银行机构

【 功能描述 】: 各商业银行向业务处理中心系统提交客户账户信息变更，该业务支持批量处理，建议各商业银行在日间（上午9：00至当日最后一次场切）业务截止后发送。

尽量在下午17：00以后23：00之前。

【 流程图 】:

【 流程 】:

1. 发起行发起账户变更业务（SMP205），后台系统自动将账户变更业务（SMP205）发往业务处理中心系统；

2. 业务处理中心系统收到发起行发起的账户变更业务（SMP205），进行账户变更处理；

3. 业务处理中心系统对账户信息变更处理完毕后，发送账户变更处理结果（SMP305）给发起行。

4. 发起行根据返回的处理结果决定是否再次发起账户变更业务（SMP205）。

【 说明 】:

1. 为避免对实时业务造成影响，各商业银行日间（上午9：00至当日最后一次场切）提交的批量业务不超过10笔。

3.4.6 账户余额查询业务

【 参与者 】: 业务处理中心、参与银行机构

【 功能描述 】:账户余额查询是基于协议的基础上进行。主要用于集团用户查询其他商业银行子公司账户的账户余额。

【 流程图 】:

【 流程 】:

1. 客户提出账户余额查询请求，发起清算行根据协议发起账户余查询业务（SMP301），并发往业务处理中心；

2. 业务处理中心收到发起行发起的账户余查询业务（SMP301），并将账户余查询业务（SMP301）转到接收行；

3. 接收行收到业务处理中心系统转发来的账户余查询业务（SMP301），根据协议号进行检查，并将查询结果（SMP302）返回给业务处理中心；

4. 业务处理中心收到接收行返回的查询结果（SMP302）以后，将查询结果（SMP302）信息返回给发起行。

【 说明 】:

1. 账户余额查询都是根据集团公司、子公司、发起清算行、接收清算行签订的四方协议发起。

3.4.7 自由格式信息

【 参与者 】: 业务处理中心、参与银行机构

【 功能描述 】: 各参与节点之间可以发送自由格式信息交换各类消息。对于业务处理中心发起的要求个节点返回回执的自由格式信息，各节点相关业务人员在收到并确认后，各节点系统需自动返回收妥回执。

【 流程图 】:

【 流程 】:（以业务处理中心发起要求回执的自由格式信息为例）

1. 业务处理中心系统发送自由格式信息（SMP209）给接收行；

2. 接收收到自由格式信息（SMP209）后判断是否为需要回执业务，如需要回执，提示相关操作人员确认，操作人员确认后，系统自动发起通用信息返回报文（SMP999）返回业务处理中心。

3. 业务处理中心系统收妥通用信息返回报文（SMP999）后修改相应标记。

3.5 资金业务描述

3.5.1 轧差清算

支付结算综合业务系统在清算日进行多场轧差清算（场次数以参数化设置），并将每场轧差结果及时提交ABS系统进行资金清算。

在每场轧差并向ABS系统提交资金清算报表的同时，系统分别向各参与清算行下发银行资金清算报文（SMP706）。

说明：

1. 法定节假日发生的业务，纳入节假日结束后第一个清算日第一场轧差清算。

3.5.2 日终处理

在到达规定的系统日切时间点，业务处理中心立即将工作日期修改为下一工作日期，进行当日最后一场轧差清算处理，并将当天的各行接收和发送的业务汇总信息下发。银行在接收到对账信息后进行对账处理，如对账不符可向业务处理中心申请明细下载。

日切后，业务处理中心、银行仍可继续受理业务。日切后业务处理中心收到的业务不再纳入当日清算，自动纳入次日清算。

对于借记业务，在日切时点后，预留于（超时时间+5秒）作为系统保留时间，在系统保留时间，系统接收接收行返回的支付业务回执，不接收发起行发起的借记业务。

3.5.3 系统对账

【 参与者 】: 业务处理中心、入网银行机构。

【 功能描述 】: 入网银行与业务处理中心就当天发生的支付业务进行对账。

【 流程图 】:

【 流程 】:

1. 业务处理中心在每天日切后发送本天的对账指令（SMP713）到银行。

2. 银行收到对账信息后进行相应的对账处理，并根据汇总对账结果返回汇总对账返回报报文（SMP714）。

3. 银行根据对账交易指令中的按业务的汇总对账信息与银行行内系统中交易数据进行对账，对账不平时，向业务处理中心发起明细下载申请指令（SMP613）；对账平时也可以向业务处理中心发起明细下载申请指令，也可以不申请，不申请时业务流程结束

4. 业务处理中心收到明细下载申请后根据明细下载申请信息生成明细下载指令（SMP614）发给银行。

5. 银行行内系统根据明细下载指令逐笔对账，找出不平的交易，然后根据具体情况给客户入账或进行手工调账。

6. 接收行根据明细对账结果返回汇总对账返回报报文（SMP714）。

【 说明 】:

1. 对账业务在每日日切后进行。

2. 参与对账的业务：所有处理成功的支付业务。

3. 系统每个工作日日切后均会下发对账报文，商业银行可以根据本行的工作时间进行账务处理。

3.6 管理业务描述

3.6.1 系统登陆

商业银行可以向业务处理中心发出登陆申请报文（SMP501），无论登陆成功与否，返回登陆返回报文（SMP502）。

商行银行登陆不成功，无法进行同城业务。

3.6.2 系统退出

商业银行可以向业务处理中心发出退出申请报文（SMP503），无论退出成功与否，返回退出返回报文（SMP504）。

商业银行根据退出返回报文，决定是否再次发出退出申请报文。

3.6.3 系统强制退出通知

当业务处理中心强制商业银行退出时，向该商业银行发出强制退出通知报文（SMP505）。商业银行将被强制退出系统，系统不再接收该商业银行发出的报文。

3.6.4 系统状态变更通知

当系统状态发生变更时，业务处理中心向各商业银行发出系统状态发生变更通知（SMP418）。各商业银行根据系统当前状态进行相关业务处理。

目前两个值域：00：日间处理；01业务截止；日终时变更，间隔时间为超时间60s。

3.6.5 场次变更通知

当系统场次发生变更时，业务处理中心向各商业银行发出场次变更通知（SMP418）。

3.6.6 日切通知

当系统从当前工作日切换到下一工作日时，业务处理中心向各商业银行发出日切通知（SMP702），商业银行随业务处理中心进行日期，并进行日终处理，如对账等。

3.6.7 通讯检查

系统定时向各商业银行发出通讯检查报文（SMP751），检查业务处理中心与各商业银行之间的通讯状态，各商业银行接收到通讯检查报文返回通讯检查返回报文（SMP752）。

第4章 接口系统结构

4.1 物理连接

商业银行行内系统与支付结算综合业务系统具体如何连接需要各商业行根据自身需要决定；

4.2 应用连接

商业银行行内系统与支付结算综合业务系统之间的应用连接方式由商业行自身决定，即商业行行内系统与支付结算综合业务系统之间的通讯程序由各参与行自行开发，通过调用支付结算综合业务系统提供的API 来帮助实现行内系统与支付结算综合业务系统之间的信息交换。

本系统为直联银行提供AIX和openSUSE linux版本接口API。

4.2.1 示意图

说明：

1、商业行行内系统的发送通讯程序负责把行内系统的业务信息通过调用发送API把业务信息发送到支付结算综合业务系统。

2、商业行行内系统的接收通讯程序通过调用接收API从支付结算综合业务系统接收业务信息，然后发送到行内系统处理，同时调用确认API从MQ中删除该业务信息。

3、商业行行内系统的通讯程序由商业行自行开发，发送API和接收API由支付结算综合业务系统提供。

4.2.2 API说明

商业银行行内系统与支付结算综合业务系统之间的通讯采用消息中间件MQ，因此在编译商业银行端的通讯程序时，将通讯程序、支付结算综合业务系统提供的静态库和MQ的静态库一起编译后便可调用API。

4.2.2.1 连接API

1) API函数的形式

void * MB_CONNECT(char * pQMRName， char *pRetCode , char *pRetInfo)

2) API使用方法说明

通讯程序中首先包含头文件“API.hpp”，然后只需要将通讯程序、支付结算综合业务系统提供的静态库和MQ的静态库一起编译后便可调用该函数。

3) API调用参数说明

pQMRName: MQ队列管理器名称。

pRetCode：3位返回码，表示调用该API的处理结果。

其中：000 表示正常

102 系统错误，商业银行检查故障后可重发

pRetInfo：表示调用该API的详细返回结果描述

4) API返回说明

该API函数返回与支付结算综合业务系统连接ID。

4.2.2.2 断开连接API

1) API函数的形式

void MB_DISCONNECT（void *pID）

2) API使用方法说明

通讯程序中首先包含头文件“API.hpp”，然后只需要将通讯程序、支付结算综合业务系统提供的静态库和MQ的静态库一起编译后便可调用该函数。

3) API调用参数说明

pID： 与支付结算综合业务系统连接ID，调用连接API MB_CONNECT()的返回值。

4) API返回说明

该API函数无返回值。

4.2.2.3 发送API

1) API函数的形式

void MB_SEND(void *pID, char *pQLName,char *pInPutMsg, char *pInPath ，char *pRetCode, char *pRetInfo)

2) API使用方法说明

通讯程序中首先包含头文件“API.hpp”，然后只需要将通讯程序、支付结算综合业务系统提供的静态库和MQ的静态库一起编译后便可调用该函数。

3) API调用参数说明

pID： 与支付结算综合业务系统连接ID，调用连接API MB_CONNECT()的返回值。

pQLName： MQ发送队列名。

pInPutMsg：大小限定为20K，表示由商业行行内系统形成的待发送报文。其格式为待发送报文的报头 + 报文正文 + 报文尾,该报文为支付结算综合业务系统支持的所有业务的信息。

如果该报文>20K，那么报文使用文件的方式发送，文件名放在报文体中。

pInPath： 当报文使用文件的方式发送，调用者指明文件保存路径。

pRetCode： 表示调用该API的处理结果，由三位返回码和六十位返回描述组成。

返回码含义说明：

000 正常

102 系统错误，商业银行检查故障后可重发。

PRetInfo： 表示调用该API的详细返回结果描述。

4) API返回说明

该API函数无返回值。

4.2.2.4 接收API

1) API函数的形式

void MB_RECEIVE（void *pID, char *pQLName, char *pOutPutMsg, char *pOutPath,int &nFileFlg, char *pRetCode , char *pRetInfo）

2) API使用方法说明

通讯程序中首先包含头文件“API.hpp”，然后只需要将通讯程序、支付结算综合业务系统提供的静态库和MQ的静态库一起编译后便可调用该函数。

3) API调用参数说明

pID： 与综合金融服务平台连接ID。

pQLName： MQ接收队列名。

pOutPutMsg：大小限定为20K，表示由支付结算综合业务系统形成的返回报文，对于返回报文，其格式为返回报文的报头 + 业务信息 + 报文尾，该业务信息为支付结算综合业务系统支持的所有业务的信息；若接收失败无内容。

如果该报文>20K，那么报文使用文件的方式接收，文件名放在报文体中。

pOutPath： 当报文使用文件的方式接收，调用者指明文件保存路径。

nFileFlg： 文件报文标识，0 表示pOutPutMsg的内容为普通报文， 非0表示pOutPutMsg的内容为长报文（报文体是文件名）。

pRetCode： 3位返回码，表示调用该API的处理结果。若返回码为000，则需要处理参数pOutPutMsg；否则不需处理参数pOutPutMsg。

返回码含义说明：

000 正常

102 系统错误，商业银行检查故障后可重新接收。

201 系统没有任何报文可被提取。

pRetInfo：表示调用该API的详细返回结果描述

4) API返回说明

该API函数无返回值。

4.2.2.5 确认API

1) API函数的形式

void * MB_CONFIRM (void *pID，char *szProcFlag,char *pRetCode , char *pRetInfo )

2) API使用方法说明

通讯程序中首先包含头文件“API.hpp”，然后只需要将通讯程序、支付结算综合业务系统提供的静态库和MQ的静态库一起编译后便可调用该函数。

3) API调用参数说明

pID： 与支付结算综合业务系统连接ID，调用连接API MB_CONNECT()的返回值。

szProcFlag： 标志该笔业务是成功处理还是处理失败。

含义：0 表示成功处理

1 表示处理失败

pRetCode：3位返回码，表示调用该API的处理结果。

其中：000 表示正常

102 系统错误，商业银行检查故障后可重发confirm

pRetInfo：表示调用该API的详细返回结果描述

4) API返回说明

该API函数无返回值。

第5章 接口信息处理说明

5.1 接口信息处理模式

5.1.1 发送处理模式

具体流程见下图：

说明：

1) 行内系统把业务信息发送到商业行端发送通讯程序。

2) 商业行端发送通讯程序通过调用发送API把业务信息发给中心端接收通讯程序。

3) 中心端接收通讯程序把业务信息发给支付结算综合业务系统处理。

4) 中心端通讯程序通知商业行端通讯程序是否发送成功。

5.1.2 接收处理模式

商业银行接收报文的处理流程如下：

说明：

1) 支付结算综合业务系统把业务信息发送到中心端发送通讯程序。

2) 商业银行端通讯程序通过调用接收API从中心端发送通讯程序收到业务信息。

3) 商业行端通讯程序把该业务信息转发给行内系统，同时调用确认API从MQ中删除该业务信息。

4) 商业行端通讯程序通知中心端通讯程序是否发送成功。

5.2 接口报文说明

5.2.1 字符集说明

5.2.1.1 属性符号

报文中可能出现的符号包括以下类型：

对于特定的域，如账号，在数字与字母混合使用时，不得大小写混用，不得使用字母O和o，I和i，以避免与数字0和1混淆。

5.2.1.2 x-字符集

x-字符集由以下85个字符组成

a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9

。 ， - （ ） / = ＇ + ？ ！ ” % & * < > ; @ #

（cr） （lf） （space）

对于使用TCP/IP协议的银行系统，x-字符集的编码（字符的二进制编码）适用于ISO-2022（ASCII）。

x字符集不包括“：”、“{”、“}”。

5.2.2 报文结构

“综合业务”系统采用与中国现代化支付系统（cnaps）相类似的SMP报文。报文包括报文头、报文体、报文尾三部分。其中报文头和报文尾两个部分为固定长度部分，报文体为带TAG的可变长度部分。

报文结构如下表：

5.2.2.1 报文头

报文头的格式如下：

说明：

 报文长度：报文长度是指报文所有长度，即报文头、报文正文、报文尾长度的总和。

 业务交易码：

子系统识别：发起方子系统识别标志，定义如下：S-业务处理中心后台子系统、B-商业银行、W-WEB子系统

SMP号码：3位SMP号码

位置：为空

序号：为空

 源/目的地址：发起方和接收方的编号。本系统的发起方和接收方的编号即为发起清算行行号和接收清算行行号，接收方编号是该报文最终接收方编号。

 报文用途：为空

 输出识别：为空

 报文标识号：可以用报文标识号唯一标识一笔报文。报文标识号为“行号或业务处理中心编号（12位）+顺序号（8位）”。对于不需要业务返回的报文，报文标识号可以为空。

不可根据报文标识号判断业务唯一性。

 报文参考号：当为请求报文的时候，报文参考号为空，为回应报文的时候报文参考号为原报文报文标识号

 工作日期：填写当前工作日

 发送时间：填当前系统时间

 有效日期：为空

 提交日期：为空

 信息优先级： 5:加急；9：普通

 预留：20位空格

5.2.2.2 报文正文

5.2.2.2.1 短报文正文

报文体是短报文（即是非文件报文）的，其正文中存放业务信息，格式如下：

说明：正文块的各个域采用TAG符标记定位法，一般格式如下：

{2:

:tag:(域内容)

:tag:(域内容)

……

:tag:(域内容)

}

注：上面格式中换行是为了清晰显示，其真实格式为：

{2::tag:(域内容):tag:(域内容)……:tag:(域内容)}

5.2.2.2.2 长报文正文

报文体是长报文（即是文件报文）的，其正文中存放业务信息，格式如下：

说明：当报文体是长报文的时候，报文体以“{F：”开始，以“}”结束，中间是带路径的文件名，该文件存放报文体的内容。格式为：

{F:/smp/msg/bodyfile/filename}

5.2.2.3 报文尾

报文尾格式如下：

5.3 业务报文

5.3.1 支付报文

5.3.1.1 实时贷记业务报文（SMP001）

报文编号:SMP001

附加域根据业务种类不同分别定义，具体内容待定。

当退汇失败，需要用贷记业务退回原交易时，附言格式建议为：

“退汇：原发起清算行行号：12n；原工作日期：8n；原交易流水：32x；”

票据种类：01-电汇凭证，02-业务委托书，03-贷记凭证，04-其他

5.3.1.2 实时借记业务报文（SMP002）

报文编号：SMP002

附加域根据业务种类不同分别定义，具体内容待定。

票据种类：01-支票，02-其他

5.3.1.3 贷记退汇报文（SMP003）

报文编号：SMP003

5.3.1.4 借记冲正业务报文（SMP006）

报文编号：SMP006

5.3.1.5 支付业务回执报文（SMP009）

报文编号：SMP009

5.3.1.6 账户信息查询请求业务报文（SMP101）

报文编号：SMP101

5.3.1.7 账户信息查询回执业务报文（SMP102）

报文编号：SMP102

5.3.2 信息报文

5.3.2.1 查询报文（SMP201）

报文编号：SMP201

5.3.2.2 查复报文（SMP202）

报文编号：SMP202

5.3.2.3 专用内部账户调拨报文（SMP203）

报文编号：SMP203

5.3.2.4 专用内部账户回执报文（SMP204）

报文编号：SMP204

5.3.2.5 账户信息变更报文（SMP205）

报文编号：SMP205

变更记录明细内容：

行业分类：

A ：农、林、牧、渔业； B ：采矿业； C ：制造业； D ：电力、燃气及水的生产供应业； E ：建筑业； F ：交通运输、仓储和邮政业； G ：信息传输、计算机服务及软件业； H ：批发和零售业； I ：住宿和餐饮业； J ：金融业； K ：房地产业； L ：租赁和商务服务业； M ：科学研究、技术服务和地质勘查业； N ：水利、环境和公共设施管理； O ：居民服务和其他服务业； P ：教育业； Q ：卫生、社会保障和社会福利业； R ：文化、教育和娱乐业； S ：公共管理和社会组织； T ：其他行业。

5.3.2.6 票据影像业务报文（SMP206）

报文编号：SMP206