银行电子凭证技术规范

1  范围

本文件规定了银行电子凭证的文件、数据与样式、系统逻辑框架、生成、通信传输和安全要求，以 及验证方法。

本文件适用于银行电子凭证数据实例与版式文件的开具、传输、接收和应用。

2  规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。

GB/T 25500（所有部分）  可扩展商业报告语言（XBRL）技术规范

GB/T 27910  金融服务  信息安全指南

GB/T 32010.1  文献管理  可移植文档格式  第1部分：PDF 1.7

GB/T 33190  电子文件存储与交换格式  版式文档

GB/T 35275  信息安全技术  SM2密码算法加密签名消息语法规范

GB/T 38540  信息安全技术  安全电子签章密码技术规范

GB/T 38674  信息安全技术  应用软件安全编程指南

JR/T 0071（所有部分）  金融行业网络安全等级保护实施指引

JR/T 0124  金融机构编码规范

JR/T 0171  个人金融信息保护技术规范

IEC 61966-2-1:1999  多媒体系统与设备  色彩测量和管理  第2-1部分：色彩管理  缺省RGB色彩 空间  sRGB（Multimedia systems and equipment—Colour measurement and management—Part

2-1:Colour management—Default RGB colour space—sRGB）

3  术语和定义

下列术语和定义适用于本文件。

3.1

电子凭证  electronic voucher

记录经济活动信息并作为记账凭证附件，具有安全保护机制的各类电子文件。

注：1.电子凭证包括发票、财政票据、客票、行程单、海关专用缴款书、银行回单和对账单等。

2.本文件中的电子凭证指银行电子凭证，例如银行回单、对账单、存款证明、转账凭证等，用于证明金融交易 的合法性和有效性。

3.2

银行回单  bank receipt

由银行提供、反映用户银行账户资金往来变动情况的一种文件。

3.3

银行对账单  bank statement

由银行提供、反映一段时期内用户银行账户资金往来变动明细的一种文件。

3.4

银行电子凭证开具端  bank electronic voucher issuer

开具银行电子凭证的银行。

3.5

银行电子凭证接收端  bank electronic voucher receiver

接收银行电子凭证的单位。

3.6

版式  fixed layout

将文本、图形、图像等多种数字内容对象按照一定规则进行版面固化呈现的一种文件格式。

3.7

电子印章  electronic seal

一种由电子印章制章者数字签名的安全数据。

注： 电子印章包括电子印章所有者信息和图形化内容的数据，用于安全签署电子文件。

[来源：GB/T 38540，3.1]

3.8

电子签章  electronic seal signature

使用电子印章签署电子文件的过程。

注：电子签章可实现与纸质文件盖章操作相似的可视效果，可保障数据来源的真实性、数据完整性以及签名人行为 的不可否认性。

[来源：GB/T 38540，3.2]

3.9

电子签章数据  electronic seal signature data

电子签章过程产生的包含电子印章、原文信息和数字签名等信息的数据。

[来源：GB/T 38540，3.4]

3.10

数字签名  dig ital signature

签名者使用私钥对待签名的杂凑值做密码运算得到的结果。

注：该结果只能用签名者的公钥进行验证，用于确认待签名数据的完整性、签名者身份的真实性和签名行为的抗抵 赖性。

[来源：GM/T 0054，3.10]

4  缩略语

下列缩略语适用于本文件。

API：应用程序接口（Application Programming Interface）

HTTPS：安全的超文本传输协议（Hypertext Transfer Protocol Secure）

OFD：开放式版式文档格式（Open Fixed-layout Document format）

PDF：便携式文档格式（Portable Document Format）

XBRL：可扩展商业报告语言（eXtensible Business Reporting Language）

5  电子凭证文件要求

5.1  通用要求

银行电子凭证的通用要求包括以下内容。

a） 以版式文档形态交付、接收和归档。

b） 同时包含便于计算机识别处理的结构化数据，且能够独立于软硬件平台进行显示或打印。

c）包含银行电子凭证开具端（以下简称开具端）或其委托方的签名或签章，签名或签章应作用于 所在的版式文档。

d）采用可靠的技术处理保障机读与人读数据的一致性。

5.2  文件格式要求

银行电子凭证应选用公开的通用文档格式，在此基础上，根据银行电子凭证业务特点进行约束和裁 剪，消除冗余并易于实现业务目标，具体要求如下。

a）宜采用GB/T 33190规定的格式（即OFD格式）。

b）采用OFD格式的银行电子凭证文件，除外观应符合本文件指导的样式外，还应包含元数据、XBRL 会计数据、电子签章或数字签名。

c）1个文件内只包含1份银行电子凭证，不应使用文档组合功能。

d）宜包含该凭证的报文内容标引。

e）除文件格式规定的豁免内容之外，显示和打印所需的全部信息应包含在文件中。 f）不应使用加密选项。

g）不应使用版式文件的大纲、书签等导航功能。

h）不应使用动态元素，例如动画、音视频等。

5.3  数字签名和电子签章要求

数字签名和电子签章应符合GB/T 33190中的相关要求，保证银行电子凭证版式文件全部内容的真实 性、完整性，且应满足如下要求。

a）应用的电子签章或数字签名应满足如下要求。

—— 电子签章数据结构应符合GB/T 38540的规定。

——数字签名数据结构应符合GB/T 35275的规定。

b） 电子印章区域应为银行电子凭证的验签触发区域。

c）数字签名和电子签章验签后应采用便于用户识别和校验的方式显示验证结果及重点细节。 d）应用的密码算法和技术必须符合国家密码主管部门的相关要求。

5.4  附件要求

银行电子凭证的会计数据（XBRL实例文件）应作为不可见附件嵌入到版式文档中。

银行对账单的会计数据附件文件名称固定为“bkr s_issuer_ {日期}_ {对账单唯一标识}.xml ”。其 中“ {日期} ”取值于表2中的“签发日期 ”，格式为“yyyymmdd ”， {对账单唯一标识}由各签发机构自 行编制。

银行回单的会计数据附件文件名称固定为“bker_issuer_ {日期}_ {回单唯一标识}.xml ”。其中“{日 期} ”取值于表3中的“签发日期 ”，格式为“yyyymmdd ”， {回单唯一标识}取值于表3中的“校验码 ”。

采用OFD的银行电子凭证，在主入口文件（OFD.xml）中应包含附件文件夹（Attachs），会计数据 附件及附件列表（Attachments.xml）应包含在Attachs内。采用OFD的银行电子凭证的包内组织方式如 图1所示。

注：1.方框表示文件夹，圆角矩形表示包内文件，实线边框表示必选（必须存在），虚线边框表示可选。 2.斜线底纹表示该文件除OFD外，还应遵循其他标准。

图 1  采用 OFD 的银行电子凭证的包内组织方式

采用PDF格式的银行电子凭证，应采用附件（attachment）的方式将会计数据嵌入到文件中。会计 数据嵌入PDF文件时，应对该文件使用压缩，压缩算法仅限Deflate算法。

注：Deflate算法是一种无损压缩算法，该算法将输入数据流分为多个块，并对每个块分别进行压缩。每个块都由1 个3字节的头部和1个压缩数据块组成。头部包含了块的类型和块的长度信息。

6  数据与样式要求

6.1  数据类型

若无特殊说明的，开具端和银行电子凭证接收端（以下简称接收端）的数据描述所对应的数据类型 如表1所示。

表 1  数据类型说明

6.2  银行对账单

6.2.1  通用信息项要求

银行对账单通用信息项的名称及约束见表 2。

各信息项的描述必须遵循国家或行业主管部门的规定。

表 2  银行对账单通用信息项的名称及约束

表 2  银行对账单通用信息项的名称及约束（续）

表 2  银行对账单通用信息项的名称及约束（续）

6.2.2  版面显示要求

银行可根据交易内容对银行对账单样式进行调整，但应确保版面上展现接收端人工处理时必要的数 据元素，具体要求如下。

a）银行对账单的版面规格为A4幅面尺寸或A5幅面尺寸。

b）单页最多包含30条交易数据。

c）银行对账单各元素名称可使用11磅（pt）的“宋体 ”字型。

d）文字颜色为黑色（RGB值为#000000）。

e）具有明显代表银行电子凭证开具端的名称或标识。

注：RGB颜色是一种用于电子设备中的加色模式，其标准由国际电工委员会（International Electrotechnical Commission，IEC）定义和维护。IEC在IEC 61966-2-1-1999中定义了基于RGB颜色空间的标准色彩规范。通过 对红（R）、绿（G）、蓝（B）3个颜色通道的变化以及相互之间的叠加来得到各式各样的颜色。

图 2  典型银行电子对账单样式

6.3  银行回单

6.3.1  通用信息项要求

银行回单通用信息项的名称及约束见表3。各信息项的描述必须遵循国家或行业主管部门的规定。

表 3  银行回单通用信息项的名称及约束

表3  银行回单通用信息项的名称及约束（续）

表 3  银行回单通用信息项的名称及约束（续）

6.3.2  扩展信息项要求

对通用信息项进行扩展应符合如下要求。

a）新增的信息项不应与通用信息项重名或含义相同，其在XBRL文件和版式文件中应遵循统一的命 名方式。

b）对于新增的信息项，应定义其标识符、信息项名称、数据类型、长度、是否为必填项和说明等。 c）使用新增信息项时不应排除已定义的通用信息项。

d）XBRL文件扩展必须遵循相关管理部门关于会计信息化的要求及GB/T 25500（所有部分）的相关 要求。

6.3.3  版面显示要求

各银行可根据交易内容对银行回单样式进行调整，但应确保版面上展现接收端人工处理时必要的数 据元素，具体要求如下。

a）银行回单的版面规格为A4幅面尺寸或A5幅面尺寸。

b）银行回单中各元素名称可使用11磅（pt）的“宋体 ”字型。

c）文字颜色为黑色（RGB值为#000000）。

d）有明显的代表开具银行的名称或标识。

7  系统逻辑框架

7.1  定义和描述

本文件规范银行电子凭证开具和接收系统、银行电子凭证互联互通平台的逻辑框架。银行电子凭证 开具和接收系统实现电子凭证开具、接收、管理等功能。银行电子凭证互联互通平台为行业级公共服务 系统，按照“共建、共享、共用 ”原则打造，是连接开具端与接收端的电子凭证转接枢纽和交换通道。

7.2  银行电子凭证开具和接收系统逻辑框架

银行电子凭证开具和接收系统逻辑框架见图3。

图 3  银行电子凭证开具和接收系统逻辑框架

银行电子凭证开具和接收系统逻辑框架中，各组成部分的要求如下。

a）银行电子凭证开具和接收系统应在数据、 日志、访问、接口、灾备、审计等方面具备本文件要 求的安全管理功能。

b）银行电子凭证开具和接收系统应具有系统监控、证书管理、影像控制等辅助模块。

c）银行电子凭证开具和接收系统的物理层应包括计算设备、网络设备、存储设备、安全设备等。 d）银行电子凭证开具和接收系统的数据层应同时支持对结构化数据和非结构化数据的管理。

f）银行电子凭证开具和接收系统的应用层应实现凭证开具、接收入库、查询统计、状态管理等功 能。

7.3  银行电子凭证互联互通平台逻辑框架

银行电子凭证互联互通平台提供银行电子凭证系统互联、凭证流转、真伪核验、业务协同等功能， 有利于避免各金融机构尤其是中小银行重复开发银行电子凭证传输接口，减少机构多头连接，降低信息 系统建设运维成本。

银行电子凭证互联互通平台作为行业级公共服务系统，可开具的银行电子凭证范围包括银行对账单 与银行回单，后续还可增加开具其他符合相关管理部门关于电子凭证会计数据要求的电子凭证。银行回 单、对账单等银行凭证电子化后，开具端与接收端经由银行电子凭证互联互通平台统一进行信息交互。 该系统实现银行电子凭证开具转接、查询转接、查验转接等功能。银行电子凭证互联互通平台逻辑框架 见图4。

图 4  银行电子凭证互联互通平台逻辑框架

银行电子凭证互联互通平台逻辑框架说明如下。

a）银行电子凭证互联互通平台支持开具端和接收端进行电子凭证信息交互。

b）银行电子凭证互联互通平台应提供查询凭证开具转接、查询转接、查验转接等功能。

8  生成要求

8.1  凭证生成

银行电子凭证中的会计数据及其版式文件应由各银行生成，或由其受委托方代理生成。

8.2  生成处理

银行电子凭证中应包含 5.4 规定的会计数据，且会计数据应以不可见（Visible=false）附件方式 嵌入银行电子凭证中。

9  通信传输要求

开具端应支持专线、虚拟专用网络（VPN）等接入方式，通过API接口或其他形式完成银行电子凭证 的交付。其中，API接口应基于HTTPS安全协议且满足令牌（token）鉴权保证可信源等安全设计要求。

传输的银行电子凭证应按照统一的命名规则命名，支持按行别在客户端自动建立目录，具体命名规 则如下。

a）单个银行电子凭证文件命名规则为“行别+业务种类+凭证编号+账号+币种+凭证生成时间+自定 义内容 ”。

b）批量银行电子凭证压缩包文件命名规则为“行别+业务种类+账号+币种+凭证生成时间+自定义内 容 ”。

银行电子凭证网络传输文件命名规则说明见表4。

表 4  银行电子凭证网络传输文件命名规则说明

10  安全要求

10.1  安全技术要求

10.1.1  数据安全

银行电子凭证开具和接收系统及银行电子凭证互联互通平台应从电子凭证会计数据采集、传输、存 储、使用、删除、销毁等方面建立全生命周期防护措施，包括但不限于以下内容。

a）符合GB/T 27910和JR/T 0171的相关要求，确保电子凭证会计数据流转过程中的隐私数据安全。

b）建立健全数据安全组织架构，明确信息传输、数据流转过程中的数据安全要求，保障银行电子 凭证开具和接收系统及银行电子凭证互联互通平台的数据安全。

10.1.2  接口安全

银行电子凭证开具和接收系统及银行电子凭证互联互通平台的接口安全要求应满足以下要求。 a）采用安全的接口协议，保证接口之间交互数据的完整性。

b）采用国家密码管理部门认可的密码算法和加密技术，实现接口之间交互数据的保密性。 c）各接口之间进行通信时，应通过身份验证机制相互验证对方的可信性，确保可信连接。

d）接入银行电子凭证互联互通平台的开具端和接收端必须符合国家或行业管理部门关于接口的相 关要求并遵循GB/T 38674关于代码编写安全的相关要求。

10.1.3  数字签名

银行电子凭证开具和接收系统及银行电子凭证互联互通平台应使用数字签名技术和（或）电子印章 技术查验银行电子凭证真实性，建立完整可控的签名和验签机制，包括但不限于以下内容。

a）开具端在输出银行电子凭证时应添加数字签名及电子签章，防止银行电子凭证被篡改。

b）多方填制的银行电子凭证应按照“一次填制，一次签名 ”操作方式，确保签名人在签名时实质 控制签名本身及被签名的内容，在填制后立刻签名，防范数据在传输和签名过程中被篡改。

c）使用数字签名要保证证书信任链完整，其中公钥所有者应通过第三方专业机构等签发的证书证 明公钥真实性。

10.1.4  环境安全

银行电子凭证开具和接收系统及银行电子凭证互联互通平台应实施环境安全管理，措施包括但不限 于以下内容。

a）保障银行电子凭证开具和接收系统及银行电子凭证互联互通平台全流程运行环境安全，例如银 行电子凭证签名验证、数字证书信任链等环境。

b）运行环境应符合JR/T 0071（所有部分）的相关要求。

c）定期检查运行环境的第三方接口、第三方依赖库，保障银行电子凭证开具、接收所依赖框架和 库函数的安全。

d）保障运行环境相关配置信息的数据安全，防止泄露或恶意修改。

10.2  安全管理要求

10.2.1  运维安全

银行电子凭证开具和接收系统及银行电子凭证互联互通平台应实施运维安全管理，应符合JR/T 0071（所有部分）的相关要求，具体措施包括但不限于以下内容。

a）银行电子凭证开具和接收系统及银行电子凭证互联互通平台能对运维管理过程中的重要活动及 其责任人进行记录。

b）对银行电子凭证开具和接收系统及银行电子凭证互联互通平台开发过程中的计划、交付、关键 路径、风险及其相关人进行记录。

10.2.2  访问安全

银行电子凭证开具和接收系统及银行电子凭证互联互通平台应实施访问管理，规范主客体间的访问 行为，具体措施包括但不限于以下内容。

a）银行电子凭证开具和接收系统及银行电子凭证互联互通平台的网络、主机、应用访问控制管理， 应符合JR/T 0071（所有部分）的相关要求。

b）结合业务需求定义银行电子凭证开具和接收系统及银行电子凭证互联互通平台的用户访问控制 策略，具体策略包括但不限于以下内容。

——根据用户权限对银行电子凭证开具和接收系统及银行电子凭证互联互通平台的数据资源进 行访问控制，和对计算资源进行分配。

——用户身份鉴别机制，银行电子凭证开具和接收系统及银行电子凭证互联互通平台具有用户 身份验证功能，有效辨识用户角色，防止恶意用户窃取或篡改数据和签名证书。

——重要事件的记录，例如签名证书使用、银行电子凭证开具等，银行电子凭证开具和接收系 统及银行电子凭证互联互通平台根据用户的唯一标识对其访问、写入数据等行为进行记录。

10.2.3  灾备安全

银行电子凭证开具和接收系统及银行电子凭证互联互通平台应符合JR/T 0071（所有部分）的相关 要求并实施灾备管理，提供合理的保障措施，确保银行电子凭证开具和接收系统及银行电子凭证互联互 通平台发生灾难或者系统错误时操作的连续性。

10.2.4  过程审计

银行电子凭证开具和接收系统及银行电子凭证互联互通平台应在技术实施过程中按照JR/T 0071 （所有部分）的相关要求实施内部过程审计，保留运行数据，配合审计工作，开展定期审查。

10.2.5  日志安全

银行电子凭证开具和接收系统及银行电子凭证互联互通平台实施日志管理，提供审计依据，包括但 不限于以下内容。

a）银行电子凭证开具和接收系统及银行电子凭证互联互通平台记录系统运行日志，包括但不限于 以下内容。

——记录系统信息，包含会计数据、证书信息、信息流转过程、所操作的软硬件环境信息、使 用者的名字等。

——记录事件日志，包含日期和时间、类型、源（终端、端口、地点、客户等）、 日志等级等 信息。

b）银行电子凭证开具和接收系统及银行电子凭证互联互通平台的日志定期进行归档，采用加密等

方式进行存储，周期性审查日志的完整性，并对异常、未授权或可疑活动进行识别和跟踪。

11  验证方法

11.1  电子文件要求的验证

11.1.1  通用要求

按照被验证系统的操作手册或其他材料， 以取值范围内外的各参数调用并下载开具的银行电子凭 证。调用参数在取值范围内应获取成功，调用参数在取值范围外应作合理提示。获取成功后按照11.1.2 至11.1.4的要求进行验证。

11.1.2  文件格式要求

宜使用GB/T 25500、GB/T 32010.1、GB/T 33190等标准对应的电子文件验证工具确认格式及内容是 否满足要求，不应仅凭文件后缀名进行判断。

11.1.3  数字签名和电子签章要求

宜使用GB/T 35275、GB/T 38540等标准对应的电子文件验证工具验证银行电子凭证中的数字签名 和电子签章数据格式及内容是否满足要求。

11.1.4  附件要求

若银行电子凭证使用OFD格式，宜使用GB/T 33190对应的文件验证工具验证其是否包含符合5.4且设 置为不可见的附件，提取附件并核对其内容是否符合5.4中相应的要求。

若银行电子凭证使用PDF格式，宜使用专业版PDF阅读器验证其附件列表中是否包含符合5.4要求名 称的附件，提取附件并核对其内容是否符合5.4中相应的要求。

11.2  数据与样式要求的验证

11.2.1  银行对帐单

按照11.1.4提取银行电子凭证的附件内容，验证其内容中出现的节点名称及取值是否符合6.2.1中 表2的要求。

用取得GB/T 33190符合性测试报告的版式文档阅读软件打开银行电子凭证，验证其显示、打印预览 和打印后是否符合6.2.2的要求。

11.2.2  银行回单

按照11.1.4提取银行电子凭证的附件内容，验证其内容中出现的节点名称及取值是否符合6.3.1中 表3的要求。若节点名称在表3中未出现，验证其是否按照6.3.2中不应与已有信息项重复定义、不排除 已有信息项等要求。

用取得GB/T 33190符合性测试报告的版式文档阅读软件打开银行电子凭证，验证其显示、打印预览 和打印后是否符合6.3.3的要求。

11.3  框架要求的验证

11.3.1  业务架构

审查银行电子凭证开具和接收系统及银行电子凭证互联互通平台的设计文档、用户应用报告等。设 计文档应详细说明银行电子凭证开具、接收、转接等的实现方式和查验方法，报告中的结论应佐证设计 文档中说明的情况。

11.3.2  技术架构

审查银行电子凭证开具和接收系统及银行电子凭证互联互通平台的设计文档、采购合同、验收报告、 评级报告等相关资料。对照技术架构要求逐项检查设计文档中是否有描述，以及其他材料中的内容是否 可提供佐证。

示例：针对7.2中e）项的要求，可进行如下检查。

a）设计文档中是否存在关于XBRL服务、签名签章服务、文档转换服务、文档阅读服务、模板设计服务、应用接口 服务的组件或模块描述。

b）系统中电子凭证开具、校验功能的实现方案中是否存在对支撑层组件的关联描述。

c）验收报告中是否确认关联了支撑层组件的功能运行正常。

d）支撑层组件如采用外部协作方式，是否有采购合同或合作协议支持，被采购产品是否具有标准符合性检测报告 或提供单位是否具有该项能力证明。

e）支撑层组件如自行研制，相关软件模块是否取得软件登记证书、标准符合性检测报告等。

11.4  生成要求的验证

11.4.1  凭证生成

验证银行电子凭证中数字签名和电子签章关联的证书是否是银行或者是受银行委托方的证书。

11.4.2  生成处理

按照11.1.4规定的方法验证，并通过随机抽样法验证附件中内容与凭证的显示效果或打印效果中内 容的一致性，抽样数不少于100例。