中国银联银行卡联网联合技术规范V21第2部分报文接口.docx

中国银联股份有限公司 发布
2009-12-30实施
2009-11-15修订
中国银联银行卡联网联合技术规范V2.1
第2部分 报文接口规范
Technical Specifications on Bankcard Interoperability V2.1
Part 2 Specification on Message Interface

Q/CUP 006.2—2009
代替Q/CUP 006.2—2007
Q/CUP
中国银联股份有限公司企业标准

目 次
前 言 IV
1 范围 1
2 报文结构 1
2.1 报文结构说明 1
2.2 报文结构分析 1
3 报文头 2
3.1 报文头位置和基本说明 2
3.2 报文头的基本组成 2
4 报文类型 9
5 位图 9
5.1 第一个位图 10
5.2 第二个位图 10
5.3 程序处理的准则 11
5.4 跨行交易示例 12
6 报文域说明 13
6.1 报文域的属性说明 13
6.2 报文类型标识符 14
6.3 域2 主账号 16
6.4 域3 交易处理码 17
6.5 域4 交易金额 19
6.6 域5 清算金额 20
6.7 域6 持卡人扣账金额 20
6.8 域7 交易传输时间 21
6.9 域9 清算汇率 21
6.10 域10 持卡人扣账汇率 22
6.11 域11 系统跟踪号 22
6.12 域12 受卡方所在地时间 22
6.13 域13 受卡方所在地日期 23
6.14 域14 卡有效期 23
6.15 域15 清算日期 24
6.16 域16 兑换日期 24
6.17 域18 商户类型 24
6.18 域19 受理机构国家代码 25
6.19 域22 服务点输入方式码 25
6.20 域23 卡序列号 26
6.21 域25 服务点条件码 26
6.22 域26 服务点PIN获取码 28
6.23 域28 交易费 28
6.24 域32 受理机构标识码 28
6.25 域33 发送机构标识码 29
6.26 域35 第二磁道数据 29
6.27 域36 第三磁道数据 30
6.28 域37 检索参考号 30
6.29 域38 授权标识应答码 30
6.30 域39 应答码 31
6.31 域41 受卡机终端标识码 31
6.32 域42 受卡方标识码 31
6.33 域43 受卡方名称地址 31
6.34 域44 附加响应数据 32
6.35 域45 第一磁道数据 32
6.36 域48 附加数据－私有 32
6.37 域49 交易货币代码 38
6.38 域50 清算货币代码 38
6.39 域51 持卡人账户货币代码 39
6.40 域52 个人标识码数据 39
6.41 域53 安全控制信息 39
6.42 域54 实际余额 40
6.43 域55 基于PBOC借贷记标准的IC卡数据域 41
6.44 域57 附加交易信息 43
6.45 域58 基于PBOC电子钱包/存折IC卡标准的交易数据 47
6.46 域59 明细查询数据 49
6.47 域60 自定义域 50
6.48 域61 持卡人身份认证信息 58
6.49 域62 交换中心数据 64
6.50 域63 金融网络数据 66
6.51 域70 网络管理信息码 66
6.52 域90 原始数据元 66
6.53 域96 报文安全码 67
6.54 域100 接收机构标识码 68
6.55 域102 账户标识1 68
6.56 域103 账户标识2 68
6.57 域121 CUPS保留 69
6.58 域122 受理方保留 71
6.59 域123 发卡方保留 71
6.60 域128 报文鉴别码 72
7 报文的匹配 72
7.1 关键信息域与报文的关联 72
7.2 关键信息域的匹配 72
8 报文格式说明 75
8.1 说明 75
8.2 联机交易报文接口定义 80
8.3 网络管理及安全控制交易报文接口定义 109
8.4 差错处理报文接口定义 111
8.5 风险控制交易报文接口定义（待定） 115
8.6 外卡收单交易报文接口定义 115
8.7 IC卡交易报文接口定义 125
附　录　A （规范性附录） 标准代码定义 153
A.1 入网机构标识码 153
A.1.1 入网机构标识码定义 153
A.1.2 境内机构（包括境外银行在境内的机构） 153
A.1.3 境外机构（包括境内银行在境外的机构） 153
A.1.4 国际信用卡公司系统标识码 153
A.1.5 国际信用卡公司系统名称简写 154
A.2 应答码 154
A.3 报文原因码 160
A.4 拒绝码 167
A.4.1 拒绝码说明 167
A.4.2 拒绝码表 167
附　录　B （资料性附录） 交易种类区分表 172
B.1 单信息交易 172
B.2 双信息交易 175
B.3 应用管理类 175
附　录　C （资料性附录） CUPS对借贷记IC卡交易的支持 176
C.1 CUPS对PBOC借/贷记标准IC卡交易的支持 176
C.1.1 CUPS对PBOC借/贷记标准IC卡转接的支持 176
C.1.2 CUPS对PBOC借/贷记标准IC卡代授权的支持 176
C.1.3 CUPS对PBOC借/贷记标准IC卡代校验的支持 177
参考文献 179

前 言
本标准对入网机构与中国银联信息处理中心系统（CUPS）之间进行联机交易时使用的报文接口，包括联机交易报文的结构、格式以及报文域做了规定。
本标准由中国银联股份有限公司提出。
本标准由中国银联股份有限公司制定。
本标准起草单位：中国银联股份有限公司、国内入网机构。
本标准主要起草人：戚跃民、郭锐、郑澎、徐静雯、李洁、吴金坛、王力斌、苗恒轩、万高峰、陆尔东。

中国银联银行卡联网联合技术规范V2.1
第2部分 报文接口规范
1　 范围
本规范规定了入网机构与中国银联信息处理中心系统（CUPS）之间进行联机交易时使用的报文接口，包括联机交易报文的结构、格式以及报文域。
本规范适用于所有加入中国银联银行卡信息交换网络的入网机构。
2　 报文结构
2.1　 报文结构说明
2.1版联机交易报文包含四个组成部分，依次是：报文头、报文类型标识符、位图和报文域。其结构如图1所示：

报文头
报文类型标识符
位 图
报文域
图1　 报文结构
报文头是报文的第一个数据元素，主要记录了报文的长度、路由、批次号等基本信息。
报文类型标识符是报文的第二个数据元素，是最高级别报文类型定义，定义了报文一般性分类，比如是金融类报文还是管理类报文。
位图定义了哪些报文域会出现在报文中。位图区可以包含一个位图也可以包含两个位图。位图个数的选择根据交易类型而定。磁条卡交易和IC卡交易都能使用位图一和位图二，二者的区别在于IC卡交易将用到55域中定义的IC卡特征信息域。位图一定义域2到域64，位图二定义域66到域128。
报文域构成了报文的主体，其中大部分由ISO 8583定义，其它域由CUPS自定义并由CUPS使用。报文域的具体定义参见第6章内容。
2.2　 报文结构分析
报文结构如图2　所示：

1.报文头描述参见3.2　；
2.报文类型标识描述参见第6　章报文域说明；
3.位图描述参见第5　章；
4.报文总共可以用到前128个报文域。报文域描述参见第6　章内容，关键域要求参见第7　章内容，每种报文的传递要求参见第8　章内容。
图2　 报文具体结构
3　 报文头
本节描述了报文头的产生及其各域的用法。描述中的“b”表示bit；“n”表示十进制数字。另外，本文中所有数字编码均采用ASCII编码方式。报文头在报文中位置如图3所示：
报文头
报文类型标识符
位 图
报文域
图3　 报文头
3.1　 报文头位置和基本说明
报文头与报文类型标识符、位图和报文域一块组成了一个完整的报文。凡符合2.1版报文接口的所有联机报文都必须带有报文头，但符合1.0版标准的不带报文头，二者的区别在于报文的第一个字节：当第一个字节为ASCII码“0”时，CUPS认为该报文为1.0版（1.0版的第一个字节规定为ASCII码“0” ）；当第一个字节不为ASCII码“0”时，CUPS认为该报文为2.1版（2.1版的第一个字节为头长度）。
用于文件传递的8000号系列报文不使用报文头。
3.2　 报文头的基本组成
表1　 报文头的组成
域
域名
长度
（单位：Byte）
Field1
头长度（Header Length）
1
Field2
头标识和版本号（Header Flag and Version）
1
Field3
整个报文长度（Total Message Length）
4
Field4
目的ID（Destination ID）
11
Field5
源ID（Source ID）
11
Field6
保留使用（Reserved for Use）
3
Field7
批次号（Batch Number）
1
Field8
交易信息（Transaction Information）
8
Field9
用户信息（User Information）
1
Field10
拒绝码（Reject Code）
5
共占46个字节。所有域都为必填域。
在入网机构产生的报文头中拒绝码域填“00000”，而当CUPS在检查中发现报文语法错误或报文结构错误时会将错误位置和错误原因填入该域，并将原始报文头和报文内容一起回应给报文的提出方，以通知报文的提出方报文出错，报文的提出方可进行相关处理。入网机构不能产生非全0的拒绝码域，但是它可能将收到这类拒绝码域。因此，入网机构产生的报文头和CUPS在未发现报文错误时产生的报文应如图4所示：

图4　 正常输出报文结构
而CUPS发现报文错误时产生的报文应如图5　所示：

图5　 异常输出报文结构
3.2.1.1　 报文头的构造
当一个入网机构产生一个请求或通知报文时，须根据要发送的报文数据构造一个报文头；而当入网机构接收到一个请求或通知报文时，必须保存报文头里的一些信息，以便在应答的时候返回给发送方。这些必须保存的域有4、5、6、7、8和9。
当入网机构产生应答报文时，应根据从请求报文头中保存下来的信息调整应答报文的报文头，规则如下：
a) 对源ID和目的ID的处理分以下两种情况:
1) 当应答直接由入网机构的总行产生，而不是由其分支机构产生时，其应答报文头的域4和域5的值将分别对应CUPS发送报文头域5（源ID）和域4（目的ID）的值。图例解释如图6　（假设受理方的机构ID为01030000，发卡方的机构ID为01020000，CUPS的机构ID为00010000）：

图6　 报文头的源地址及其目的地址的传递示意图1
2) 当应答不是由入网机构的总行产生，而是由分支机构产生时，其应答报文头域5（源ID）的值是真正发送这个应答的机构ID。图例解释如图7　（假设受理方的机构ID为01030000，发卡方总行机构ID为01020000，发卡方分行机构ID为01026400，CUPS的机构ID为00010000）：

图7　 报文头的源地址及其目的地址的传递示意图2
b) 下列域的值应该原样被返回，不得改动：域7（批次号）、域6(CUPS内部保留码)、域8（交易信息）、域9（用户信息）；入网机构也应根据其它域域值的描述规则相应地创建。
3.2.2　 报文头各域详细说明
本规范将按照表2　所列各个方面全面解释报文头各域的含义。
表2　 域含义
域名
域含义
属性
报文头域的长度和格式
产生者
表明哪个实体可以给报文头域设置非零值
描述
报文头域的可能内容和定义
用法
在对报文头域的处理过程中有用的一些特殊限制
备注
其它说明
域编辑值
报文头域的取值范围和取值规则
拒绝码
拒绝报文头中标识错误意义的代码
3.2.2.1　 域1 报文头长度
Header-Length
—— 属性：8bit二进制数
—— 产生者：入网机构、CUPS
—— 描述：该域存放报文头的字节数。
—— 用法：明确标识报文头的长度。
—— 域编辑值：该域的值必须为46。
—— 拒绝码：00015 ＝ 非法值
3.2.2.2　 域2 头标识和版本号
Header-Flag-and-Version
—— 属性：8bit二进制数
—— 产生者：入网机构、CUPS
—— 描述：该域的第一位代表如下含义：
●　 0表示该报文是一个生产报文；
●　 1表示该报文是一个测试报文。
该位由交易的发起方填写，在报文传输过程中保持不变。
后7位组成的二进制值定义了该报文格式的版本，目前的值由原始取值000 0001更新为000 0010。000 0001适用于2008年以前发布的规范内容，本次新修订的内容用新报文版本号来标识。
—— 拒绝码：00025 ＝ 非法值
3.2.2.3　 域3 报文总长度
Total–Message-Length
—— 属性：n4，4位定长数字字符
—— 产生者：入网机构、CUPS
—— 描述：该域表示报文的总字节数，即从报文头开始到报文结束的总长度。如图8　显示：

图8　 正确报文总长度示例
如果这是一个标识报文有误的报文头，那么其域3反映了整个报文的长度，而原始报文头的域3只反映原始报文的长度，如图9　显示：

图9　 错误报文总长度示例
—— 域编辑值：
●　 在正确的报文中，该域的值必须大于46且小于等于1846字节。
●　 在拒绝的报文中，该域值为：新增报文头长度＋原始发送报文长度，即必须大于46＋46＝92且小于等于1846＋46＝1892。
—— 拒绝码：00035 ＝ 非法值
3.2.2.4　 域4 目的ID
Destination-Station-ID
—— 属性：ans11，11位定长数字字符数据，不足11位后补空格
—— 产生者：入网机构、CUPS
—— 描述：该域表示报文的路由选择。
—— 用法：当入网机构产生请求或通知报文时，该域填CUPS的ID，00010000。当入网机构要对输入报文产生应答时，应在该域填上输入报文的域5（源ID）的值。
—— 域编辑值：入网机构发出的报文中，该域必须为CUPS的ID，00010000；而在CUPS发出的报文中，该域必须包含一个合法的ID。该域值的填写可以参考5.4　的图例解释。本域取值即为入网机构的唯一标识码。
—— 拒绝码：00045 ＝ 非法值
3.2.2.5　 域5 源ID
Source-Station-ID
—— 属性：ans11，11位定长数字字符数据，不足11位后补空格
—— 产生者：入网机构、CUPS
—— 描述：标识报文发送者，但并不一定是原始交易数据的收集者。
—— 用法：一般地，当与CUPS直联的报文接收者（例如：入网机构总行）在对接收到的请求或通知直接进行应答时，原有目的ID将变成应答报文头的源ID。
在请求报文中该域填写与CUPS直接相连的发送机构代码，即使该直联机构不是该请求报文真正的产生者，而仅是该请求报文的转发者（例如：请求报文由入网机构总行的某个分支机构产生）。在应答报文中， 该域填写应答报文真正的产生者的机构代码。
—— 域编辑值：每一个输出报文都必须包含一个有效的源ID。在受理方初始产生的请求和应答中，该域都必须表示一个有效的受理机构。在发卡方初始产生的请求和应答中，该域也必须表示一个有效的发卡机构。该域值的填写可以参考5.4　的图例解释。
本域取值即为入网机构的唯一标识码。
—— 拒绝码：00055 ＝ 非法值
3.2.2.6　 域6 保留使用
Reserved-for-Use
—— 属性：24bit二进制数
—— 产生者：CUPS
—— 描述：由CUPS产生，内部使用。
—— 用法：如果是入网机构发出的请求报文，该域值为0；如果是应答报文，则该域值与请求报文中的值一致。
—— 域编辑值：在入网机构产生的报文中该域必为0。
—— 拒绝码：00065 ＝ 非法值
3.2.2.7　 域7 批次号
Batch-Number
—— 属性：8bit二进制数
—— 产生者：CUPS
—— 描述：该域包含由CUPS为报文分配的批次号。每当CUPS接收到新的请求或通知时，都会把当前的批次号插入到该域。如果CUPS接收到的是以前曾经处理过的报文的关联报文，那么该域的值与以前报文该域的值相同。
—— 用法：如果是入网机构主动发出的请求报文，该域值为0；入网机构向CUPS返回应答时该域的值与其相应的请求报文中的值相同。
—— 域编辑值：在入网机构产生的请求报文中该域必为0。
—— 拒绝码：00075 ＝ 非法值
3.2.2.8　 域8 交易信息
Transaction-Information
—— 属性：ans8，8位字母、数字和特殊字符
—— 产生者：CUPS
—— 描述：由CUPS产生，格式如表3所示：
表3　 交易信息域格式
交易地域标志
通知交易标识
保留使用
ans1
ans1
ans6
—— 用法：交易地域标志取值如下：
●　 0－银联卡境内交易：受理方和发卡方均在中国大陆境内；
●　 1－银联卡跨境交易：受理方和发卡方有且只有一方在中国大陆境内，卡片为银联标识卡；
●　 2－外卡收单交易：受理方为中国大陆境内机构，卡片为其他信用卡组织的卡片；
●　 3－银联卡境外交易：受理方和发卡方都在中国大陆以外（中国大陆境内机构不会收到此类交易）；
通知交易标识用于区分几类特殊的通知类交易，其取值如表4所示：
表4　 通知交易标识
取值
含意
包含的交易
0
缺省值
对于一般的通知类交易（以下三类通知以外的所有通知）和所有的请求交易，本域填写缺省值“0”。
1
无含义
保留使用
2
差错处理通知类
收/付费通知（0220/0230）、贷记调整确认通知/请款确认通知/再请款确认通知/退单通知/二次退单通知报文—发往受理方（0422/0432）、差错例外确认通知报文－发往发起方（0422/0432）、贷记调整通知/请款通知/再请款通知/退单确认通知/二次退单确认通知—发往发卡方（0220/0230）、差错例外通知报文－发往接收方（0220/0230）
3
风险管理通知类
涉嫌卡号通知（0620/0630）、涉嫌交易通知（0620/0630）
—— 域编辑值：在入网机构发出的请求报文中，该域值为全零，入网机构返回银联处理中心的应答报文中必须将该域值原样返回，银联处理中心发出的报文中需要将该域置为有效值。
—— 拒绝码：00085 ＝ 非法值
3.2.2.9　 域9 用户信息
User-Information
—— 属性：8bit二进制数
—— 产生者：入网机构
—— 描述：该域的值由受理方填写，以便于入网机构的处理。例如，其值可以用于识别一个请求的源。该值仅在入网机构内部使用，在网络传输或其它的处理中心里无意义。
—— 用法：在请求报文中，该域需要包含在入网机构选项中由用户定义的值。如果不需要用户信息，该域必须填0值；如果是应答报文，入网机构必须保留请求中的域值并在应答时原封不动地返回。
—— 域编辑值：无
—— 拒绝码：无
3.2.2.10　 域10 拒绝码
Reject-Code
—— 属性：n5，5位定长数字字符
—— 产生者：CUPS
—— 描述：在以下两种情况下，CUPS填写本域表示拒绝该报文的原因：
●　 当CUPS检查发现入网机构发来的报文中存在语法错误时，填写本域以指明发生错误的域。此时本域的第1位为0或1，为0表示报文头域出错，为1表示报文体域出错；2-4位表示出错的域；第5位表示错误的类型。
●　 由于银联处理中心的原因导致报文被拒绝，填写本域以表示报文被拒绝的原因。此时本域的第1位为2，表示由于银联处理中心的原因导致报文被拒绝；2-5位表示错误的类型。
在入网机构产生的报文头中该域填“00000”。
拒绝码的详细定义请参见《附录》部分《附录A 标准代码定义》的拒绝码表部分。
特别说明：CUPS只对其收到的请求报文发送拒绝报文，对收到的应答报文不发拒绝报文。
—— 用法：无
—— 域编辑值：无
—— 拒绝码：无
3.2.3　 报文头在传递过程中的变化
3.2.3.1　 符号约定
本规范的符号约定如表5所示。
表5　 符号约定
符号
含义
发
送
方
AC
受理方(Acquirer)
SW
CUPS（CUPS）
IS
发卡方(Issuer)
SD
报文发送方(Sender)
RC
报文接收方(Receiver)
OB
转账交易的受理方（Original Bank）
CB
转入方或转出方(Cardhold Bank)
符号
含义
数
据
元
数
值
符
号
M
必须填写的域
C
某条件成立时必须填写的域
C+
某条件成立时增加的域
C-
某条件成立时删除的域
M+
必须增加的域
O
受理方和发卡方自选填写的域
®
转发域

必须与先前报文中对应域的值相同的域
00
自定义数据元中须填充0的域

必须去除的域
注： 受理方同时为转入方或转出方，且按照三方转账交易拆分，需要生成三笔差错流水，一笔为受理方差错流水，一笔为转出方差错流水，一笔为转入方差错流水。
3.2.3.2　 报文头的传递
表6　 交易由受理方发起且通过CUPS检查的情况
位
数据元
AC
SW
IS
SW
注释
1
Header Length
M
®
M
®
报文头的长度在传递过程中不变
2
Header Flag and Version
M
M
M
M
根据入网机构的报文接口，版本会发生变化
3
Total Message Length
M
M
M
M
各方根据报文体长度的变化而不同
4
Destination ID
00010000
M
00010000
M
受理方的目的ID必须为CUPS的ID，00010000
5
Source ID
M
00010000
M
00010000

6
Reserved for Use
填0
M
M
®
CUPS会赋值，并且发卡方的应答需与请求报文一致
7
Batch Number
填0
M
M
®
CUPS会赋值，并且发卡方的应答需与请求报文一致
8
Transaction Information
填0
M
M
®
CUPS会赋值，并且发卡方的应答需与请求报文一致
9
User Info
M
®
M
®

10
Reject Code
填0
®
M
®
无错误时继续转发

表7　 交易由受理方发起且未通过CUPS检查时新增报文头的传递情况
位
数据元
AC
SW
注释
1
Header Length
M
®
报文头的长度在传递过程中不变
2
Header Flag and Version
M
M
根据入网机构的报文接口，版本会发生变化
3
Total Message Length
M
M
各方根据报文体长度的变化而不同
4
Destination ID
00010000
M
受理方的目的ID必须为CUPS的ID，00010000
5
Source ID
M
00010000

6
Reserved for Use
填0
M
CUPS会赋值，并且发卡方的应答需与请求报文一致
7
Batch Number
填0
M
CUPS会赋值，并且发卡方的应答需与请求报文一致
8
Transaction Information
填0
M
CUPS会赋值，并且发卡方的应答需与请求报文一致
9
User Info
M
®

10
Reject Code
填0
C＋
发生错误时拒绝码由CUPS产生，且不再继续传递而是退回受理方

表8　 交易由CUPS发起的情况
位
数据元
SD（SW）
RC
注释
1
Header Length
M
M
标准报文头的长度在传递过程中不变
2
Header Flag and Version
M
M
根据入网机构的报文接口，版本会发生变化
3
Total Message Length
M
M
各方根据报文体长度的变化而不同
4
Destination ID
M
00010000
接收方直接响应CUPS，因此目的ID须为CUPS的ID，00010000
5
Source ID
00010000
M
由CUPS发出的报文，源ID须为CUPS的ID，00010000
6
Reserved for Use
M
M
CUPS会赋值，并且发卡方的应答需与请求报文一致
7
Batch Number
M
M
CUPS会赋值，并且发卡方的应答需与请求报文一致
8
Transaction Information
M
M
CUPS会赋值，并且发卡方的应答需与请求报文一致
9
User Info
填0
M

10
Reject Code
填0
M

4　 报文类型
本节描述了报文类型标识符并解释报文类型是怎样使用的。报文类型标识符在报文中的位置如图所示：
报文头
报文类型标识符
位 图
报文域
图10　 报文类型标识符
报文类型标识符长度是四个字节。每个报文都要求有报文类型标识符，并且需要位于主位图之前。
ISO8583-1987版的报文类型主要是根据报文来源和目的地来定义，该标准包括了发往发卡方的受理方报文和发往受理方的发卡方报文。标准并未规定中间机构如交换中心如何使用。本规范规定了在CUPS和入网机构之间转发的报文类型。
详细内容参见报文域说明。

报文类型标识符表示报文类、报文功能和交易发出者。表5 中给出的可能代码的完整清单和分配的代码清单。未分配的代码的用法由双方协商决定。
表 1报文类型标识符
范 围
代 码
说 明
位置1
报文类
0
行业保留使用
1
授权
2
金融请款
3
文件动作
4
冲正/退单
5
对账
6
管理
7
收费
8
网络管理
9
行业保留使用
位置2
报文功能
0
请求
1
请求应答
2
通知
3
通知应答
4-9
行业保留使用
位置3
交易发起方
0
受理方
1
行业保留使用
2
发卡方
3
行业保留使用
4
其他发起方
5-9
行业保留使用

5　 位图
在CUPS交换网络中传输报文的格式是不断变化的，报文中使用位图来标识报文中有哪些域而没有哪些域。一个报文中可以有一个或两个位图位图在报文中位置如图所示：
报文头
报文类型标识符
位 图
报文域
位图1=域2-64
位图2=域66-128
图11　 位图
5.1　 第一个位图
第一个位图又称为主位图，每一个报文都有主位图。它由64个二进制位(8个字节)构成，位于报文类型标识符之后。除了第一位，每一位和一个域相对应，即和域2到域64相对应。其中，需要注意的是，位图一中的55域专用于IC卡交易，即，若位图一中出现了55域，说明这是一个IC卡交易。每位的值指示该域是否出现在报文中：
如果一个位为0，与之对应的域不出现在报文中；
如果一个位为1，与之对应的域出现在报文中。
域号是1的域不存在。主位图的第一位用来指明在主位图后是否还有第二个位图，称为位图二。位图二的说明见下节。
下图说明了位图的位置和功能。在这个例子中，位图第一位是0，表示主位图后没有第二个位图。第2、3、4位是1，表示域2、3、4出现在报文中。第5、6位是0，表示报文中没有域5、6。第7位是1，表示域7出现在报文中，依次类推。

图12　 第一个位图示例
5.2　 第二个位图
主位图的第一位指明了主位图后是否有位图二。和主位图相同，位图二也由64个二进制位(八字节)构成。可以认为位图二是主位图的扩展，和域66到128相对应。报文域65不存在。
只有当报文中包含有域66到域128中的域，位图二才会使用到。位图二紧接着主位图，并在报文域之前。下图显示了位图二的位置和功能。主位图的第一位是1表示位图二的存在。如果位图中的哪一位为1，表示以该位序号为序号的域存在。例如，位图二中的位90是1，表示报文中有域90存在。

图13　 第二个位图示例
图14　
5.3　 程序处理的准则
本节详细说明CUPS处理报文数据时的规则。
5.3.1　 报文的长度
正确的报文最大长度不超过1846字节。
错误的报文最大长度不超过1892字节。
5.3.2　 数据的表示
对于ISO8583报文中的域规定为数字的，CUPS以数字的ASCII码表示。本文中以这种方式表示：
nx，x位定长数字字符
对于ISO 8583报文中的域规定为字符和数字的，CUPS以字符和数字ASCII码表示，本文中以这种方式表示：
anx，x位定长的字母和数字字符
对于一些域，虽然定义为字符和数字，实际内容的取值也可能只是数字，例如域37—检索参考号。
标记为ans的域表示该域除了字母和数字，还允许有特殊字符，比如破折号、斜杠等。
5.3.3　 域的对齐
所有域以字节边界对齐。
5.3.4　 域的长度
ISO标准中规定的可变长度域最长可以达到999个字节。本文中的域描述给出了每个可变长度域的最大长度字节数，这个长度限制适应于整个域，该域中所有子域的长度和应小于等于整个域的长度。
所有的长度值不包括长度子域本身的长度。报文域的长度占位含义依赖于域的属性，可以是字母、数字或二进制位。
此规定可以让其它网络和系统的应用能正确的跳过这些域。
所有的二进制位域，如位图和PIN，它们的位串必须被正确的构造。
5.3.5　 对未使用位置的填充
对于固定长度的报文域有以下填充规则：
—— 如果是数字域，右靠齐，左边多余位填零；
—— 如果不是数字域，左靠齐，右边多余位填空格。
5.3.6　 报文的传送
CUPS使用的报文以ASCII形式编码，所以报文以ASCII码形式传送。
5.3.7　 带有可选择子域的报文域
如果一个域带有子域，并且不是全部子域都要求出现在报文中，那么只要该域的任何一个子域出现在报文中，该域在位图中对应的位就要设为1。

5.4　 跨行交易示例
假设：
交易类型：POS消费
受理方：建设银行济南分行，通过建设银行总行与CUPS相连。
发卡方：中国银行武汉分行，通过中国银行总行与CUPS相连。
跨行交易的流程如图15　所示：

1——建设银行济南分行（受理方分支机构）提交消费请求报文至建设银行总行（受理方总行）
2——建设银行总行（受理方总行）按照CUPS技术规范要求的报文格式将该消费请求发送至CUPS。其中关键信息域如下：
7域（交易传输日期时间）：0222092010（北京时间2月22日9点20分10秒）
11域（系统跟踪号）：666666
32域（受理机构标识码）：01054510
33域（发送机构标识码）：01050000
100域（接收机构标识码）：无此域

3——CUPS转发此消费请求至中国银行总行（发卡方总行）。其中关键信息域如下：
7域（交易传输日期时间）：0222092010（北京时间2月22日9点20分10秒）
11域（系统跟踪号）：666666
32域（受理机构标识码）：01054510
33域（发送机构标识码）：01050000
100域（接收机构标识码）：01040000

4——中国银行总行（发卡方总行）将请求转发至中国银行武汉分行（发卡方分支机构）。
5——中国银行武汉分行（发卡方分支机构）将应答返回中国银行总行（发卡方总行）。
6——中国银行总行（发卡方总行）将应答返回至CUPS。其中关键信息域如下：
7域（交易传输日期时间）：0222092010（北京时间2月22日9点20分10秒）
11域（系统跟踪号）：666666
32域（受理机构标识码）：01054510
33域（发送机构标识码）：01050000
100域（接收机构标识码）：01040000

7——CUPS将应答返回建设银行总行（受理方总行）。其中关键信息域如下：
7域（交易传输日期时间）：0222092010（北京时间2月22日9点20分10秒）
11域（系统跟踪号）：666666
32域（受理机构标识码）：01054510
33域（发送机构标识码）：01050000
100域（接收机构标识码）：01040000

8——建设银行总行（受理方总行）将应答返回建设银行济南分行（受理方分支机构）。
图15　 跨行交易示例
从以上的流程中可以看出：在一个交易周期中，报文中的关键信息域——7、11、32、33的值在入网机构与CUPS进行报文交换的过程中（即在图中虚线框所示的范围内）保持不变，而且这四个值的组合具有全程唯一性，可以明确的标识一笔交易。
6　 报文域说明
6.1　 报文域的属性说明
6.1.1　 符号说明
a) 在CUPS与各入网机构的报文中，各报文域的数据类型、长度属性及格式如下表所示：
表9　 报文域数据类型、长度属性及格式含义表
字符
含义
a
字母字符，A至Z，a至z，向左靠，右边多余位填空格
b
数据的二进制表示，后跟数字表示位（bit）的个数
B
用于表示变长的二进制数，后跟数字表示二进制数据所占字节（Byte）的个数
n
数值，0至9，右靠，首位有效数字前填零。若表示人民币金额，则最右二位为角、分
p
填充字符，如空格
s
特殊符号
an
字母和数字字符，左靠，右边多余位填空格
as
字母和特殊字符，左靠，右边多余位填空格
cn
压缩数字码，即BCD码
ns
数字和特殊字符，左靠，右边多余位填空格
ans
字母、数字和特殊字符，左靠，右边多余位填空格
ansb
字母、数字、特殊字符和二进制数，左靠，右边多余位填空格
MM
月份，01至12
DD
日期，01至31
YY
年份，00至99
hh
时，00至23
mm
分，00至59
ss
秒，00至59
LL
后面跟随数据元的可变长度值，01至99
LLL
后面跟随数据元的可变长度值，001至999
VAR
可变长度数据元
3
3字符的固定长度
..17
最大17个字符的可变长度。所有可变长度字段在数据元的前面应另外包含2个或3个位置，
以表示后面到数据元结束时的位置数。
X
借贷符号，贷记为“C”，借记为“D”，并且总是与一个数字型金额数据元相连，例如，
交易费金额中X+N8含义为前缀“C”或“D”和交易费金额的8位数字。
Z
ISO 4909和ISO 7813中定义的磁卡第二、三