Q∕CUP 006.2-2007 银行卡联网联合技术规范V2.0 第2部分 报文接口规范.pdf

Q/CUP中国银联股份有限公司企业标准Q/CUP 006.22007代替Q/CUP 006.22006银行卡联网联合技术规范V2.0 第2部分报文接口规范Technical Specifications on Bankcard Interoperability V2.0 Part 2 Specification on Message Interface2007-08-10 发布2007-08-10 实施中国银联股份有限公司 发布Q/CUP 006.22006目 次前 言.V1范围.12规范性引用文件.13术语和定义.13.1 CUPS.13.2银联公共服务平台.13.3 受理方 Acquirer.13.4 发卡方 Issuer.13.5 转入方 Transfer-in.23.6 转出方 Transfer-out.23.7 交换中心 Bank Card Switching Center.23.8 预授权 Pre-Authorization.23.9 银行卡 Bank Card.23.10 请求 Request.23.11 响应码 Response Code.23.12 冲正 Reversal.23.13 存储转发 Store and Froward.23.14 清算 Settlement.23.15 交易 Transaction.23.16 单信息 Single Message.23.17 单信息交易 Single Message Transaction.33.18 双信息 Dual Message.33.19 双信息交易 Dual Message Transaction.33.20 通知 Advice.33.21 自 主清算 Self-Determination Settlement.33.22 非自 主清算 Unself-Determination Settlement.33.23 PBOC 标准.33.2 4EMV 标准.33.25 EMV ready.33.26 ARQC(Authorization Request Cryptogram).33.27 ARPC(Authorization Response Cryptogram).33.28 CUPSecure.43.29银联安全输入模式.43.30 路由服务器 Security Route Server；SR.44报文结构.44.1报文的结构.44.2报文头说明.54.3报文类型说明.124.4位图说明.12IQ/CUP 006.220064.5程序处理的准则.135报文的匹配.145.1 关键信息域与报文的关联.145.2关键信息域的匹配.155.3跨行交易示例.176报文域说明.186.1 报文域的属性说明.186.2 CUPS对报文域的使用.196.3报文类型标识符.226.4 域2主账号.246.5 域3交易处理码.256.6 域4交易金额.286.7 域5清算金额.296.8 域6持卡人扣账金额.306.9 域7交易传输时间.306.10域9清算汇率.316.11域10持卡人扣账汇率.316.12域11系统跟踪号.316.13域12受卡方所在地时间.326.14域13受卡方所在地日期.326.15域14卡有效期.326.16域15清算日期.336.17域16兑换日期.336.18域18商户类型.346.19 域19受理机构国家代码.346.20 域22服务点输入方式码.346.21 域23卡序列号.356.22 域25服务点条件码.356.23域26服务点PIN获取码.366.24域28交易费.376.25 域32受理机构标识码.376.26 域33发送机构标识码.376.27 域35第二磁道数据.386.28 域36第三磁道数据.386.29 域37检索参考号.386.30 域38授权标识应答码.396.31 域39应答码.396.32 域41受卡机终端标识码.406.33域42受卡方标识码.406.34 域43受卡方名称地址.406.35 域44附加响应数据.406.36 域45第一磁道数据.416.37 域48附加数据一私有.41IIQ/CUP 006.220066.38 域49交易货币代码.476.39 域50清算货币代码.486.40 域51持卡人账户货币代码.486.41域52个人标识码数据.486.42 域53安全控制信息.486.43 域54实际余额.496.44域55 IC卡数据域.506.45域57附加交易信息.526.46域58基于PBOC电子钱包/存折IC卡标准的交易数据.536.47 域59明细查询数据.566.48 域60自定义域.576.49 域61持卡人身份认证信息.606.50 域62交换中心数据.656.51 域63金融网络数据.676.52 域66清算代码.686.53 域70网络管理信息码.686.54 域74贷记交易笔数.706.55 域75冲正贷记笔数.706.56 域76借记交易笔数.706.57 域77冲正借记笔数.716.58 域78转账笔数.716.59 域79冲正转账笔数.716.60 域80查询笔数.716.61 域81授权笔数.726.62 域82贷记服务费金额.726.63 域84借记服务费金额.726.64 域86贷记交易金额.726.65 域87冲正贷记金额.736.66 域88借记交易金额.736.67 域89冲正借记金额.736.68 域90原始数据元.746.69 域95替换金额.756.70 域96报文安全码.756.71 域97净清算额.756.72 域99清算机构代码.766.73 域100接收机构标识码.766.74 域102账户标识1.766.75 域103账户标识2.776.76域104交易描述.776.77 域 121 CUPS 保留.776.78 域122受理方保留.806.79 域123发卡方保留.806.80 域128报文鉴别码.817报文格式说明.81IIIQ/CUP 006.220067.1说 明.817.2转 接业务报文接口定义.867.3代 授权业务报文接口定义.1127.4差 错处理报文接口定义.1187.5清 分清算和日终批处理业务的报文接口定义.1217.6安 全控制报文接口定义.1247.7管 理业务报文接口定义.1257.8风 险控制交易报文接口定义.1277.9跨 境交易报文接口定义.1277.10 IC卡交易报文接口定义.1517.11网络切换通知报文接口定义.1737.12经由CUPSecure认证的网络交易报文接口定义.173参考文献.177IVQ/CUP 006.22006、/1-刖 百本标准对入网机构与中国银联信息处理中心系统(CUPS)之间进行联机交易时使用的报文接口，包 括联机交易报文的结构、格式以及报文域做了规定。本次标准的修订版本代替Q/CUP 006.1-2005版本C本次标准主要修订内容如下：1.增加支持Cupsecure网上安全支付交易2.增加支持品牌服务费3.增加支持PB0C电子钱包/电子存折交易4.增加支持农民工银行卡特色服务5.其它修订改为由CUPS产生原始币种汇率信息文件；删除与不良信息有关的风险信息共享文件；一为05应答码增加一个适用条件是“CVN验证失败”；更新入网机构标识码，并根据业管委发2006 11号，修改入网机构标识码中地区代码的规 定；根据业管委发【2006】12号，修改43域用法；一增加了对ATM双向代理业务的支持；修改商户类别码的引用标准，规定商户类别代码要符合金融零售业务商户类别代码(GB/T 20548-2006)。本次标准的修订版也对一部分内容进行了勘误。本标准由中国银联股份有限公司提出。本标准由中国银联股份有限公司制定。本标准起草单位：中国银联股份有限公司、国内入网机构。本标准主要起草人：戚跃民、郭锐、郑澎、徐静雯、李洁、吴金坛、王力斌、苗恒轩、万高峰、陆 尔东。vQ/CUP 006.22006银行卡联网联合技术规范V2.0 第2部分报文接口规范1范围本规范规定了入网机构与中国银联信息处埋中心系统(CUPS)之间进行联机交易时使用的报文接口,包括联机交易报文的结构、格式以及报文域。本规范适用于所有加入中国银联银行卡信息交换网络的入网机构。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的 修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究 是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T 2260GB/T 2659-94GB/T 4754-94GB/T 12406-94GB/T 15150-94 GB/T 20548-2006JR/T 0025-2005 全国银行卡办公室:中华人民共和国行政区划代码世界各国和地区名称代码国民经济行业分类与代码表示货币和资金的代码产生报文的银行卡-交换报文规范-金融交易内容(IS08583-1987)金融零售业务商户类别代码中国金融集成电路(IC)卡规范银行卡联网联合技术规范VI.0 2001.1全国银行卡办公室：银行卡联网联合业务规范2001.1银联卡业务运作规章第二卷业务规则银联卡跨行业务地区代码标准(银联业管委2006 11号)EMV2000 Integrated Circuit Card Specification for Payment Systems：BooklBook4 3术语和定义 3.1CUPS中国银联信息处理中心系统，ChinaUnionPay System。3.2银联公共服务平台中国银联提供的面向入网机构的基于Internet的服务平台，该平台能够提供与转接业务相关的差 错、报表服务等功能。3.3受理方 Acquirer指受理交易的一方(即交易终端所在的一方)。受理方负责联机交易信息的产生和转接以及结算数 据的收集、整理和提交等。3.4发卡方 Issuer1Q/CUP 006.22006指持卡人账户所在的一方（即批准授权的一方）。通常将发卡方及其联网的行内中心或区域中心统 称为发卡方。3.5转入方 Transfer-in指转账交易中资金转入的一方。3.6转出方 Transfer-out指转账交易中资金转出的一方。3.7交换中心 Bank Card Switching Center本规范中交换中心是指中国银联信息处理中心。中国银联信息处理中心负责银行卡跨行交易信息的转接以及清算数据的收集、清分和下发等。3.8预授权 Pre-Authorization发卡方给代理方的认可或担保。3.9银行卡 Bank Card商业银行等金融机构及邮政储汇机构向社会发行的，具有消费信用、转账结算、存取现金等全部或 部分功能的信用支付工具。3.10请求 Request产生一系列交互报文的报文。3.11响应码 Response Code也称为应答码，是接收方接收到请求或通知后，返回给发送方表示处理结果的代码。3.12冲正 Reversal一种特殊的交易。由报文的发送方发起，用于通知接收方先前一笔授权类或金融类交易没有按预定 流程完成，应该取消其处理结果。3.13存储转发 Store and Froward发送方将报文存放在存储转发队列中，在一定次数内每隔一段时间重复发送。3.14清算 Settlement指根据清分结果对交易数据进行净额轧差和提交并完成资金划拨的全过程。3.15交易 Transaction用于完成原始信息引入者意图的相关信息的集合，通常以一笔借记或贷记交易结束。随后进行修正 或撤销可视为一个独立的交易集合。3.16单信息 Single Message指受理方将交易信息提交给发卡方，然后由CUPS以日志进行清算，受理方不必提交清算文件的交易 方式。2Q/CUP 006.220063.17单信息交易 Single Message Transaction一笔交易被发送一次，同时用于授权、清分和结算，此类交易也称“全金融交易”。即，授权、清 分和结算全部在线发生。3.18双信息 Dual Message指受理方先将授权请求信息提交给发卡方，在后来的某个时间再集中将清算信息以清算文件的形式 提交给发卡方的交易方式。3.19双信息交易 Dual Message Transaction一笔交易被发送两次，第一次仅用于授权，第二次的附加信息用于清分和结算。即，授权实时处理，清分和结算非实时处理。3.20通知 Advice将已经发生的动作通知有关方的报文，不要求认可。3.21自 主清算 Self-Determination Settlement两个机构之间的一种清算约定，当清算由一方发起并以该方的数据为准时，该方称该类交易为自主 清算。3.22非自主清算 Unself-Determination Settlement两个机构之间的一种清算约定，当清算由一方发起并以该方的数据为准时，另一方称该类交易为非 自主清算。3.23PBOC标准PB0C是People Bank of China的缩略词，在本规范中特指中国人民银行颁发的中国金融集成电 路(IC)卡规范(V2.0)o 3.24EMV标准EMV是EUROPAY、MASTERCARD.VISA三个国际信用卡公司的首字母缩略词，这三个公司联合制定的IC 卡借记/贷记应用标准，简称为EMV标准。3.25EMV ready根据目前的PBOC借/贷记标准草案，支持特殊信息传递、安全认证、交易特征以及代授权时发卡方 部分脚本应用等四大功能。3.26ARQC(Authorization Request Cryptogram)授权请求密文的英文简称，是IC卡为联机处理交易生成的应用密文，发卡方在联机卡片认证过程中 通过验证ARQC来认证当前交易中卡片的有效性。3.27ARPC(Authorization Response Cryptogram)授权响应密文的英文简称，是由发卡方生成并在联机授权报文中返回给终端的应用密文，用于IC 卡验证联机授权响应是否来自真正的发卡方。3Q/CUP 006.220063.28CUPSecure中国银联制定的互联网电子商务领域银行卡交易的安全体系，ChinaUnionPay Secure。3.29银联安全输入模式由银联代为收集安全信息并转发给发卡机构，由发卡机构认证并完成相应支付交易的安全认证模 式。3.30路由服务器 Security Route Server；SR主要功能为提供目录服务，即根据卡号确定卡片所有的发卡行，查找发卡机构选择的模式，并根据 该模式在安全插件和银联安全信息输入服务器之间传递请求和响应消息。4报文结构4.1报文的结构4.1.1报文结构说明2.0版联机交易报文包含四个组成部分，依次是：报文头、报文类型标识符、位图和报文域。其结 构如图1所示：报文头报文类型标识符位图报文域图1报文结构报文头是报文的第一个数据元素，主要记录了报文的长度、路由、批次号等基本信息。报文类型标识符是报文的第二个数据元素，是最高级别报文类型定义，定义了报文一般性分类，比 如是金融类报文还是管理类报文。位图定义了哪些报文域会出现在报文中。位图区可以包含一个位图也可以包含两个位图。位图个数 的选择根据交易类型而定。磁条卡交易和IC卡交易都能使用位图一和位图二，二者的区别在于IC卡交易 将用到55域中定义的IC卡特征信息域。位图一定义域2到域64,位图二定义域66到域128。报文域构成了报文的主体，其中大部分由ISO 8583定义，其它域由CUPS自定义并由CUPS使用。报文 域的具体定义参见第6章内容。4.1.2报文结构分析报文结构如图2所示：4Q/CUP 006.220061.报文头描述参见4.2；2.报文类型标识描述参见第6章报文域说明；3.位图描述参见4.4；4.报文总共可以用到前128个报文域。报文域描述参见第6章内容，每种报文的域要求参见第7章内容，关键域要 求参见第5章内容。图2报文具体结构4.2报文头说明本节描述了报文头的产生及其各域的用法。描述中的“b”表示bit；“n”表示十进制数字。另外,本文中所有数字编码均采用ASCH编码方式。报文头在报文中位置如图3所示：报文头报文类型标识符位图报文域图3报文头4.2.1报文头位置和基本说明报文头与报文类型标识符、位图和报文域一块组成了一个完整的报文。凡符合2.0版报文接口的所 有联机报文都必须带有报文头，但符合1.0版标准的不带报文头，二者的区别在于报文的第一个字节：当第一个字节为ASCH码“0”时，CUPS认为该报文为L0版（1.0版的第一个字节规定为ASCH码“0”）；当第一个字节不为ASCH码“0”时，CUPS认为该报文为2.0版（2.0版的第一个字节为头长度）。用于文件传递的8000号系列报文不使用报文头。4.2.1.1报文头的基本组成表1报文头组成如表1所示：报文头组成域域名长度（单位:Byte）Field 1头长度(Header Length)1Field2头标识和版本号(Header Flag and Version)1Field3整个报文长度(Total Message Length)4Field4目的 ID(Destination ID)11Field5源 ID(Source ID)11Field6保留使用(Reserved for Use)3Field7批次号(BatchNumber)1Field8交易信息(Transaction Information)8Field9用户信息(User Information)1Field 10拒绝码(Reject Code)5共占46个字节。所有域都为必填域。在入网机构产生的报文头中拒绝码域填“00000”，而当CUPS在检查中发现报文语法错误或报文结 构错误时会将错误位置和错误原因填入该域，并将原始报文头和报文内容一起回应给报文的提出方，以 通知报文的提出方报文出错，报文的提出方可进行相关处理。入网机构不能产生非全。的拒绝码域，但 是它可能将收到这类拒绝码域。因此，入网机构产生的报文头和CUPS在未发现报文错误时产生的报文应 如图4所示：-正常输出报文报文头报文类别码位图数据元区图4正常输出报文结构而CUPS发现报文错误时产生的报文应如图5所示:5Q/CUP 006.22006_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 原始输出报文新增报文头（拒绝码 标识错误位置和原 因）原始报文头（拒绝 码为00000）报文类别码位图数据元区转发域必须与先前报文中对应域的值相同的域00自定义数据元中须填充0的域必须去除的域注：受理方同时为转入方或转出方，且按照一方转账交易拆分，需要生成3笔差错流水，一笔为受理方差错流 水，一笔为转出方差错流水，一笔为转入方差错流水。表6交易由受理方发起且通过CUPS检查的情况位数据元ACSWISSW注释1Header LengthMfMf报文头的长度在传递过程 中不变2Header Flag and VersionMMMM根据入网机构的报文接 口，版本会发生变化3Total Message LengthMMMM各方根据报文体长度的变 化而不同4Destination ID00010000M00010000M受理方的目的ID必须为 CUPS的ID,000100005Source IDM00010000M000100006Reserved for Use填。MM-CUPS会赋值，并且发卡方 的应答需与请求报文一致7Batch Number填。MM-CUPS会赋值，并且发卡方 的应答需与请求报文一致8Transaction Information填。MMCUPS会赋值，并且发卡方 的应答需与请求报文一致9User InfoMTMT10Reject Code填0-M-无错误时继续转发表7交易由受理方发起且未通过CUPS检查时新增报文头的传递情况位数据元ACSW注释1Header LengthM-报文头的长度在传递过程中不变2Header Flag and VersionMM根据入网机构的报文接口，版本会发生变化3Total Message LengthMM各方根据报文体长度的变化而不同4Destination ID00010000M受理方的目的ID必须为CUPS的ID,000100005Source IDM000100006Reserved for Use填。MCUPS会赋值，并且发卡方的应答需与请求报文一致7Batch Number填。MCUPS会赋值，并且发卡方的应答需与请求报文一致8Transaction Information填。MCUPS会赋值，并且发卡方的应答需与请求报文一致9User InfoMT10Reject Code填。c+发生错误时拒绝码由CUPS产生，且不再继续传递而 是退回受理方表8交易由CUPS发起的情况位数据元SD(SW)RC注释1Header LengthMM标准报文头的长度在传递过程中不变2Header Flag and VersionMM根据入网机构的报文接口，版本会发生变化3Total Message LengthMM各方根据报文体长度的变化而不同4Destination IDM00010000接收方直接响应CUPS,因此目的ID须为CUPS的ID,0001000011Q/CUP 006.220064.3报文类型说明位数据元SD(SW)RC注释5Source ID000100001由CUPS发出的报文,源ID须为CUPS的ID,000100006Reserved for UseMMCUPS会赋值，并且发卡方的应答需与请求报文一致7Batch NumberMMCUPS会赋值，并且发卡方的应答需与请求报文一致8Transaction InformationMMCUPS会赋值，并且发卡方的应答需与请求报文一致9User Info填0110Reject Code填0M本节描述了报文类型标识符并解释报文类型是怎样使用的。报文类型标识符在报文中的位置如图所 示：报文头报文类型标识符位图报文域图10报文类型标识符报文类型标识符长度是四个字节。每个报文都要求有报文类型标识符，并且需要位于主位图之前。IS08583-1987版的报文类型主要是根据报文来源和目的地来定义,该标准包括了发往发卡方的受理 方报文和发往受理方的发卡方报文。标准并未规定中间机构如交换中心如何使用。本规范规定了在CUPS 和入网机构之间转发的报文类型。详细内容参见报文域说明。4.4位图 说明在CUPS交换网络中传输报文的格式是不断变化的，报文中使用位图来标识报文中有哪些域而没有哪 些域。一个报文中可以有一个或两个位图位图在报文中位置如图所示：位图1=域2-64位图2=域66-128报文头报文类型标识符位图报文域图11 位图4.4.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出现在报文中，依次类推。12Q/CUP 006.220062-主账号3-交易处理码4-交易金额7-交易传输时间14-卡有效期18-商户类型22-服务点输入方式码25-服务点条件码32-代理机构标识码35-第二磁道数据37-检索参考号41-受卡机终端标识码42-受卡方标识码49-交易货币代码60-自定义域图12第一个位图示例4.4.2第二个位图主位图的第一位指明了主位图后是否有位图二。和主位图相同，位图二也由64个二进制位（八字节）构成。可以认为位图二是主位图的扩展，和域66到128相对应。报文域65不存在。只有当报文中包含有域66到域128中的域，位图二才会使用到。位图二紧接着主位图，并在报文域 之前。下图显示了位图二的位置和功能。主位图的第一位是1表示位图二的存在。如果位图中的哪一位 为1,表示以该位序号为序号的域存在。例如，位图二中的位90是1,表示报文中有域90存在。bits 1-641位图10 位图2域 2-64域66-128第1位表示位图 位图二所指的域二存在图13第二个位图示例图144.5程序 处理的准则本节详细说明CUPS处理报文数据时的规则。4.5.1报文的长度正确的报文最大长度不超过1846字节。13Q/CUP 006.22006错误的报文最大长度不超过1892字节。4.5.2 数据的表示对于IS08583报文中的域规定为数字的，CUPS以数字的ASCH码表示。本文中以这种方式表示：nx,x位定长数字字符对于ISO 8583报文中的域规定为字符和数字的，CUPS以字符和数字ASCH码表示，本文中以这种方 式表，j、一 anx,x位定长的字母和数字字符对于一些域，虽然定义为字符和数字，实际内容的取值也可能只是数字，例如域37检索参考号。标记为ans的域表示该域除了字母和数字，还允许有特殊字符，比如破折号、斜杠等。4.5.3域的对齐所有域以字节边界对齐。4.5.4 域的长度ISO标准中规定的可变长度域最长可以达到999个字节。本文中的域描述给出了每个可变长度域的最 大长度字节数，这个长度限制适应于整个域，该域中所有子域的长度和应小于等于整个域的长度。所有的长度值不包括长度子域本身的长度。报文域的长度占位含义依赖于域的属性，可以是字母、数字或二进制位。此规定可以让其它网络和系统的应用能正确的跳过这些域。所有的二进制位域，如位图和PIN,它们的位串必须被正确的构造。4.5.5 对未使用位置的填充对于固定长度的报文域有以下填充规则：如果是数字域，右靠齐，左边多余位填零；如果不是数字域，左靠齐，右边多余位填空格。4.5.6 报文的传送CUPS使用的报文以ASCH形式编码，所以报文以ASCH码形式传送。4.5.7 带有可选择子域的报文域如果一个域带有子域，并且不是全部子域都要求出现在报文中，那么只要该域的任何一个子域出现 在报文中，该域在位图中对应的位就要设为1。5报文的匹配CUPS的联机交易报文一般由一对报文组成：一个请求报文和一个响应报文。CUPS收到一个报文后比 较关键信息域中的信息，从而将报文匹配到一个交易集中。报文的匹配是交换系统中最重要的概念之一。本章提供报文匹配概念的概述，描述了交易集的类型，并给出用于决定处理流程的关键信息域。5.1关键信息域与报文的关联关键信息域(Key Field)被用来识别一笔交易。发卡方、CUPS和受理方必须使用这些关键域匹配交 易的请求(通知)和应答、原始交易和随后的关联交易。当入网机构发现一笔交易处理或传输出错时，可以产生一个用于更正的报文，例如受理方的系统或 POS设备自身可以产生一个冲正。关联交易包括以下几种情况：原始交易与其冲正交易；原始交易与其撤销交易；原始交易与其在规定期限内的贷记调整、请款、退单、差错例外交易；请款交易和贷记调整交易；一退单交易与其针对的请款交易；一再请款交易与其针对的退单交易；14Q/CUP 006.22006 二次退单交易与其针对的再请款交易；一预授权交易与其结算交易；一代授权与其通知交易；基于PB0C电子钱包/存折标准的IC卡圈提交易和其确认交易；存款交易与其存款确认交易；一转入转账交易与其转入转账确认交易；余额查询交易无相关交易产生。5.2关键信息域的匹配以下表格说明了什么情况下关键信息域的值必须匹配前面的报文，什么情况下必须赋予新的值。表 中有阴影的单元表示其取值与其关联交易的对应取值一致。入网机构也可以根据自身判断的需要使用一些其它的信息域来匹配报文，如域2（主账号）、域37（检 索参考号）通常被用来做报文匹配，域90（原始数据元）可以被用来匹配冲正报文。5.2.1 授权、预授权交易表9授权、预授权交易关键信息域交易类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）请求0100交易发起方产生交易时的系统日期时间分配给交易的新值POS代理机构代码提交机构代码应答0110与0100一致与0100一致与0100一致与0100一致5.2.2 授权撤销、预授权撤销交易表10授权撤销、预授权撤销交易关键信息域交易类型（域2）授权标识应答号（域 38）受卡方标识码（域 42）请求0100与原始授权交易的该域值一致原始授权时获得的授权标识应答码与原始授权交易的该域值一致应答0110与0100 一致与0100一致与0100一致5.2.3 代授权通知交易表11代授权通知交易关键信息域交易类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）请求 0120/0220/0420原始代授权 交易产生时间原始代授权交易 系统跟踪号原始代授权交易 受理机构标识码原始代授权交易 发送机构标识码应答 0130/0230/0430与 0120/0220/0420致与 0120/0220/0420一致与 0120/0220/0420致与 0120/0220/0420一致5.2.4 余额查询交易表12余额查询交易关键信息域5.2.5金融交易交易类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）请求0200交易发起方产生交易时 的系统日期时间分配给交易的新值代理机构代码提交机构代码应答0210与0200 一致与0200 一致与0200 一致与0200 一致15Q/CUP 006.22006表13金融交易关键信息域交易类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）请求0200交易发起方产生交易时 的系统日期时间分配给交易的新值ATM/POS 代理机构代码提交机构代码应答0210与0200 一致与0200 一致与0200 一致与0200 一致5.2.6 金融撤销交易表14金融撤销交易关键信息域交易交易传输时间系统跟踪号（域受理机构标识码发送机构标识码原始数据元类型（域7）11）（域 32）（域 33）（域 90）请求0200交易发起方产生交易 时的系统日期时间分配给交易 的新值ATM/POS 代理机构代码提交机构代码从原始交易 中提取应答0210与0200 一致与0200 一致与0200 一致与0200 一致5.2.7 金融通知交易表15金融通知交易关键信息域5.2.8冲正通知交易类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）请求0220交易发起方产生交易 时的系统日期时间分配给交易的新值代理机构编码提交机构编码应答0230与0220 一致与0220 一致与0220 一致与0220 一致表16冲正通知关键信息域交易 类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）原始数据元（域 90）请求0420交易发起方产生交易 时的系统日期时间分配给交 易的值与原始交易一致与原始交易一致从原始交易 中提取应答0430与0420 一致与0420 一致与0420 一致与0420 一致5.2.9 差错处理通知（发卡方）表17差错处理通知（发卡方）关键信息域交易 类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）原始数据元（域 90）请求0220交易发起方产生交易 时的系统日期时间分配给交 易的新值与原始交易一致与原始交易一致从原始交易 中提取应答0230与0220 一致与0220 一致与0220 一致与0220 一致5.2.10差错处理通知（受理方）表18差错处理通知（受理方）关键信息域5.2.11对账交易交易 类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识 码（域32）发送机构标识码（域 33）原始数据元（域 90）请求0422交易发起方产生交易 时的系统日期时间分配给交 易的新值与原始交 易致与原始交易一致从原始交易 中提取应答0432与0422 一致与0422 一致与0422 一致与0422 一致表19对账交易关键信息域交易类型交易传输时间（域7）系统跟踪号（域11）16Q/CUP 006.22006请求052X交易发起方产生交易时的系统日期时间分配给交易的新值应答053X与052X 一致与052X 一致5.2.12网络及风险管理类交易表20网络及风险管理类交易关键信息域交易类型交易传输时间（域7）系统跟踪号（域11）请求0620交易发起方产生交易时的系统日期时间分配给交易的新值应答0630与0620 一致与0620 一致5.2.13网络管理通知交易表21网络管理通知交易关键信息域5.2.14重置密钥交易交易类型交易传输时间（域7）系统跟踪号（域11）请求0820交易发起方产生交易时的系统日期时间分配给交易的新值应答0830与0820 一致与0820 一致表22重置密钥交易关键信息域交易类型交易传输时间（域7）系统跟踪号（域11）请求0800交易发起方产生交易时的系统日期时间分配给交易的新值应答0810与0800 一致与0800 一致5.2.15建立/撤销委托关系交易表23建立/撤销委托关系交易关领E信息域交易类型交易传输时间（域7）系统跟踪号（域 11）受理机构标识码（域 32）发送机构标识码（域 33）请求0100交易发起方产生交易 时的系统日期时间分配给交易的新值代理机构代码提交机构代码应答0110与0100 一致与0100 一致与0100 一致与0100 一致5.3 跨行交易示例假设：交易类型：P0S消费受理方：建设银行济南分行，通过建设银行总行与CUPS相连。发卡方：中国银行武汉分行，通过中国银行总行与CUPS相连。跨行交易的流程如图15所示：1建设银行济南分行（受理方分支机构）提交消费请求报文至建设银行总行（受理方总行）17Q/CUP 006.220062建设银行总行（受理方总行）按照CUPS技术规范要求的报文格式将该消费请求发送至CUPSo其中关键信息 域如下：7域（交易传输日期时间）：0222092010（北京时间2月22 I I 9点20分10秒）11域（系统跟踪号）：66666632域（受理机构标识码）：0105451033域（发送机构标识码）：01050000100域（接收机构标识码）：无此域3CUPS转发此消费请求至中国银行总行（发卡方总行）。其中关键信息域如下；7域（交易传输日期时间）：0222092010（北京时间2月22 I I 9点20分10秒）11域（系统跟踪号）：66666632域（受理机构标识码）：0105451033域（发送机构标识码）：01050000100域（接收机构标识码）：010400004中国银行总行（发卡方总行）将请求转发至中国银行武汉分行（发卡方分支机构）。5中国银行武汉分行（发卡方分支机构）将应答返回中国银行总行（发卡方总行）。6中国银行总行（发卡方总行）将应答返回至CUPS。其中关键信息域如下：7域（交易传输日期时间）：0222092010（北京时间2月22 I I 9点20分10秒）11域（系统跟踪号）：66666632域（受理机构标识码）：0105451033域（发送机构标识码）：01050000100域（接收机构标识码）：010400007CUPS将应答返回建设银行总行（受理方总行）。其中关键信息域如下：7域（交易传输日期时间）：0222092010（北京时间2月22 I I 9点20分10秒）11域（系统跟踪号）：66666632域（受理机构标识码）：010545103