JR-T 0149—2016 中国金融移动支付 支付标记化技术规范.pdf
- 文档编号:14661440
- 上传时间:2023-06-25
- 格式:PDF
- 页数:26
- 大小:624.87KB
JR-T 0149—2016 中国金融移动支付 支付标记化技术规范.pdf
《JR-T 0149—2016 中国金融移动支付 支付标记化技术规范.pdf》由会员分享,可在线阅读,更多相关《JR-T 0149—2016 中国金融移动支付 支付标记化技术规范.pdf(26页珍藏版)》请在冰点文库上搜索。
ICS35.240.40A11JR中华人民共和国金融行业标准JR/T01492016中国金融移动支付支付标记化技术规范ChinafinancialmobilepaymentPaymenttokenizationspecification2016-11-09发布2016-11-09实施中国人民银行发布JR/T01492016I目次前言.II引言.III1范围.12规范性引用文件.13术语和定义.14符号和缩略语.25系统实现.26支付标记申请.47支付标记使用.68支付标记生命周期管理.79风险控制要求.710安全要求.8附录A(资料性附录)交易要素.14参考文献.20JR/T01492016II前言本标准按照GB/T1.12009给出的规则起草。
本标准由中国人民银行提出。
本标准由全国金融标准化技术委员会(SAC/TC180)归口。
本标准负责起草单位:
中国人民银行科技司、中国金融电子化公司。
本标准参加起草单位:
中国工商银行、中国农业银行、中国银行、中国建设银行、招商银行、中信银行、中国银联股份有限公司、蚂蚁金融服务集团、财付通支付科技有限公司、京东金融、中移电子商务有限公司、北京中金国盛认证有限公司、中金金融认证中心有限公司、银行卡检测中心、工业和信息化部计算机与微电子发展研究中心(中国软件评测中心)、信息产业信息安全测评中心。
本标准主要起草人:
李伟、王永红、陆书春、李兴锋、曲维民、邬向阳、杨倩、王禄禄、周皓、蒋慧科、吴永强、黄本涛、王欢、赵哲、汤沁莹、贾铮、刘运、王兆国、罗鹏飞、卢婷、连宾雄、杨明、范俐捷、盛莹、同勇、王晓月、陈泽智、李明婕、戚小朝、李斌、刘栋、落红卫、方海峰、张谦、周缅、李茂材、付博、孙霄、丁晓强、阮森灵、罗乐、姜名峰、刘婧雯、黄江、许自强、叶强林、高志民、高强裔、白阳、郑晓娟、孙茂增、魏博锴、宋铮、黄晓培、王冠华。
JR/T01492016III引言近年来,国内商业银行、非银行支付机构等为保护支付敏感信息、提升支付安全,防范信息泄露和欺诈交易,在移动支付业务中逐步引入了支付标记化(PaymentTokenization)技术,通过支付标记(Token)代替银行卡卡号、非银行支付机构支付账户等支付要素进行交易,并对标记的应用范围加以限定,从源头遏制信息泄露,最大程度上保障用户交易安全。
为落实中国人民银行关于进一步加强银行卡风险管理的通知(银发2016170号)要求,引导和规范各机构应用支付标记化技术,特制定本标准。
JR/T014920161中国金融移动支付支付标记化技术规范1范围本标准提出了支付标记化技术的基本架构,规定了应用支付标记化技术的系统接口、安全、风险控制等要求。
本标准适用于从事支付标记化系统建设或服务运营的商业银行、非银行支付机构、支付转接清算机构、商户等机构。
2规范性引用文件下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件,仅所注日期的版本适用于本文件。
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
JR/T00712012金融行业信息系统信息安全等级保护实施指引中国人民银行关于进一步加强银行卡风险管理的通知(银发2016170号,2016年6月15日)3术语和定义下列术语和定义适用于本文件。
3.1支付账号paymentaccount具有金融交易功能的银行账户、非银行支付机构支付账户的编码,及银行卡卡号。
3.2支付标记paymenttoken(Token)作为支付账号等原始交易要素的替代值,用于完成特定场景支付交易。
3.3支付标记化paymenttokenization用支付标记替换支付账号等原始交易要素的过程。
3.4去标记化de-tokenization标记服务提供方根据当前交易场景验证支付标记有效性后,将其还原为支付账号等原始交易要素的过程。
3.5标记服务提供方tokenserviceproviderJR/T014920162支付标记的发行机构,负责支付标记生命周期管理,提供支付标记化、去标记化等服务。
3.6标记有效期tokenexpirydate支付标记使用的有效时间,应小于或等于支付账号等原始交易要素有效期。
3.7支付标记发行机构识别码tokenissueridentificationnumber唯一标识支付标记发行机构的编码。
3.8标记请求方tokenrequestor向标记服务提供方提交标记申请的机构。
3.9域控tokendomainrestrictioncontrols标记服务提供方在生成标记时预设的一组参数,用于确定标记的使用范围,如交易类型、交易金额、使用次数、支付渠道等。
4符号和缩略语下列符号和缩略语适用于本文件。
C有条件的选择项M必选项O可选项R应答中应返回VAR可变长度域a字母azn数字09s特殊字符an字母和数字字符ans字母、数字和特殊字符as字母和特殊字符ns数字和特殊字符ARQC授权请求密文(AuthorizationRequestCryptogram)ID&V身份识别和验证(IdentificationandVerification)PA支付账号(PaymentAccount)TIN支付标记发行机构识别码(TokenIssuerIdentificationNumber)TR标记请求方(TokenRequestor)TSP标记服务提供方(TokenServiceProvider)5系统实现JR/T0149201635.1体系架构支付标记化体系架构描述了支付标记化的主要角色,规定了标记请求方(TR)、标记服务提供方(TSP)与传统支付流程的关系和数据交互接口,明确了各角色如何共同为用户提供标记服务。
图1描述了支付标记化体系架构。
标记服务提供方TSP收单方标记请求方TR商户用户转接清算方PA发行方提供支付账号等原始交易要素信息和PA发行方信息标记请求方请求Token去标记化根据识别的PA发行方,发送至PA发行方进行身份验证出示Token(如非接、扫描等方式)传递Token传递Token传递PA或Token标记交易过程标记交易过程标记申请过程标记申请过程传递Token图1支付标记化体系架构其中,TSP是该标记化框架的核心角色,提供Token的生成、管理、去标记化等功能,负责TR的注册和管理。
TSP对PA发行方信息进行维护,确保PA发行方信息的真实性和有效性,并向标记请求方、业务需求方提供数据接口。
TSP角色的实体可由商业银行、非银行支付机构、支付转接清算机构等承担。
TR向TSP申请Token,并提供支付账号等原始交易要素和PA发行方信息。
同一主体可承担TSP、TR、PA发行方、收单方等多个角色。
5.2TSP系统功能TSP系统应具备以下功能:
标记库的持续运行和维护;Token的生成与发布;Token生命周期管理,包括属性更新和状态管理等;去标记化处理;判断Token状态是否正常,正确应答关联方请求;安全应用和控制,保证信息存储、传输和处理的安全性;域控处理,包括交易金额、交易渠道、商户范围等,具体域控要素可参考附录A表A.1、A.2、A.3中“是否为域控要素”中的说明;TR的管理,包括TR合法性验证、注册、注销、业务风险通知等;建立及管理与TR、业务需求方的数据接口;欺诈信息共享,TSP与PA发行方、TSP间共享欺诈信息。
JR/T0149201645.3TR管理5.3.1TR注册TSP应根据业务需要制定TR的申请和注册流程,图2描述了TR注册流程。
标记服务提供方TSPTR信息Token的域控限制标记请求方TRTRID图2TR注册流程TR向TSP提交注册信息,由TSP进行审核。
审核通过后,TSP为TR分配唯一的ID(TRID),并记录该TRID对应的标记域控参数,用于后续的交易验证。
TR注册信息包括TR身份信息、标记域控信息,具体内容可参照附录A。
5.3.2TR注销TR可主动向TSP提出注销申请。
如TR存在违反TSP管理要求的情况,TSP有权对TR予以强制注销。
TR注销后,TSP回收TRID,将该TR及其申请的Token做失效处理,TR应及时告知业务相关方,并对系统中存储的所有相关信息应进行脱密、销毁处理。
6支付标记申请6.1申请流程图3描述了支付标记的申请流程。
标记服务提供方TSP2、请求Token(PA、身份验证信息)5、返回Token3、账户验证4.验证结果标记请求方TRPA发行方1、PA、有效期用户6、返回Token图3支付标记申请流程具体申请流程步骤说明如下:
步骤1:
用户向TR提交支付账号等原始交易要素信息;JR/T014920165步骤2:
TR向TSP申请Token;步骤3:
TSP向PA发行方验证账户信息及用户身份信息;步骤4:
PA发行方将验证结果返回至TSP;步骤5:
TSP生成Token,并返回给TR;步骤6:
TR向用户返回Token。
6.2申请要素TR提交的信息至少应包括:
标记请求方标识码(即TRID),支付账号等原始交易要素(包括账号、有效期等),标记属性(域控属性、存储位置等)。
相关申请要素参见附录A。
6.3标记格式6.3.1Token编码规则Token长度范围为13至34位。
Token由三部分组成:
TIN、TSP自定义位、校验码。
不同的TSP应使用不同的TIN。
TIN长度为6至12位。
应确保TIN在支付网络内的唯一性。
Token的最后n位是校验码(n由TSP自定义)。
TIN与校验码之间为TSP自定义位,由TSP自行赋值。
6.3.2唯一性要求TSP应确保Token的唯一性。
TSP应确保Token在失效或注销之日起,在有可能影响后续关联交易的时间周期内不得重复被分配给其他用户。
6.4标记属性6.4.1有效期在Token生成过程中,由TSP根据TR申请的有效期、TR域控属性中允许的有效期、PA有效期等因素综合确定Token有效期,Token有效期应为以上三者中的最小值。
6.4.2存储位置TSP需要定义Token的存储位置,并且负责对相关TR申请Token的存储位置执行检查。
存储类型包括但不限于:
远程服务器存储,如商户的服务器;本地安全芯片存储,例如移动设备中的SE;本地安全环境存储,例如TEE;远程安全环境存储,例如云SE(HCE模式);本地软件环境存储,例如移动设备中的客户端软件。
TSP应根据Token在用户端本地存储位置的差异为Token确定不同的有效期和使用次数。
6.5身份验证用户向TR申请Token后,TR将必要的用户身份验证信息上送TSP,TSP向PA发行方发起身份验证请求,验证用户身份。
应按照中国人民银行关于进一步加强银行卡风险管理的通知关于业务开通、交易安全等方面要求,采取必要的安全验证方式。
JR/T0149201666.6域控设置Token申请时TSP应根据交易渠道、商户范围、身份验证强度等进行风险评估及交易权限控制,根据风险评估结果对Token的有效期、交易次数和交易金额等信息进行限制。
TR应综合设备标识、软件环境、设备保护能力等判断当前Token申请的风险程度,并根据风险程度级别为Token定义不同的申请授权时长和授权金额。
TR向TSP提出Token申请时,申请的Token域控属性应在TR域控属性范围内,且Token有效期应小于或等于PA有效期。
TR可在Token失效前,根据具体应用场景,主动发起Token的延期或更新操作。
7支付标记使用7.1标记交易图4描述了收单方直联PA发行方的支付标记交易流程。
标记服务提供方TSP收单方TokenToken去标记化PA发行方PATokenToken用户商户图4支付标记的交易流程(收单方直连PA发行方)图5描述了经转接清算方转接的支付标记交易流程。
转接清算方标记服务提供方TSP收单方TokenToken去标记化PA发行方PAToken或PA验证授权结果TokenToken用户商户图5支付标记的交易流程(经过转接清算方转接)支付标记交易的处理流程与现有基于PA的交易处理流程一致,仅在去标记化操作时需要TSP完成标记的验证和还原。
用户发起交易,商户将交易信息(包含用于识别交易的电子凭证信息,该凭证信息应与本次交易使用的Token一一对应)发送给收单方,收单方将交易信息发送至转接清算方(或直接发送到PA发行方),最后由PA发行方完成交易。
在交易过程中可由PA发行方或转接清算方向TSP发起去标记化过程。
而Token交易路由与PA的交易路由一致。
TSP作为标记服务处理系统,完成Token与原PA的转换操作。
JR/T014920167去标记化交易处理具体如下:
去标记化过程中,需要对Token的有效性(有效期、标记状态等)进行验证,如果Token无效,应拒绝交易;TRID(标记请求方ID)是一个控制数据元,应在交易中进行校验。
如果交易报文中的TRID与TSP标记库中存储的该支付标记对应的TRID不匹配时,应拒绝交易;从交易报文中提取域控相关的数据元,并与TSP标记库中定义的交易域控元素比对,若不匹配,应拒绝交易;TSP应根据交易类型进行交易数据验证(验磁、验ARQC授权请求密文等),确保交易信息安全可信。
退款处理具体如下:
对于用户可以提供支付所用Token信息且该Token未失效的情况,商户直接使用Token发起退款交易。
该退款交易传递到TSP进行去标记化处理,将该Token退款还原为PA的退款交易,并到PA发行方完成入账;对于用户无法提供Token信息或Token已失效的情况,用户提交支付过程中得到的交易电子凭证信息,由商户或收单方根据该电子凭证查询获取用于本次支付的Token,并以该Token发起退款交易。
TSP通过去标记化处理转换为PA的退款交易,由PA发行方完成入账;对于用户否认标记支付行为的情况,由TSP和PA发行方协商处理。
7.2交易要素去标记化过程中,申请方向TSP提交的信息至少应包括标记属性(Token号、Token长度、有效期、TRID)、交易数据(交易时间、交易金额)等。
TSP向申请方返回交易结果、Token关联的PA。
相关交易要素参见附录A。
8支付标记生命周期管理8.1状态管理TR、PA发行方可作为直接发起方,向TSP发起Token状态管理类请求。
Token状态管理包括:
激活,将未激活状态的Token变更为已激活状态。
锁定,由于设备遗失或被盗等原因,将Token与PA的映射关系临时失效。
解锁,将锁定的Token的状态恢复正常,该Token与PA的映射关系被重新激活。
注销,将Token与PA的映射关系解除,对应关系废止。
具体场景包括但不限于设备遗失或被盗、PA遗失或被盗、PA欺诈警告、Token欺诈警告。
8.2属性管理由于PA发行方更新PA及PA的属性信息,TSP应同步更新PA及标记相关属性信息,以及Token与该PA的映射关系。
9风险控制要求9.1TSP风险控制要求TSP风险控制要求如下:
应建立相关的风险管理制度,包括风险识别与分析、风控规则管理、风险事件处置等;JR/T014920168应提供一段时间内的风险事件报表,或提供查询一段时间内的风险事件报表功能;应结合域控策略实现风险识别与防范;应对支付标记请求、去标记化等标记活动进行记录,用于审计;应对服务对象进行风险管理,服务对象包括商业银行、非银行支付机构、支付转接清算机构等;应建立服务对象风险识别标准和方法,识别和评估不同服务对象的风险状况;应开展持续的动态风险管理,如采取分渠道采集信息、加权测评、综合评价的方式,对服务对象的信用情况及对业务风险的持续管理能力定期开展审查与评估;应定期检查服务对象的风险评估报告,根据服务对象不同的风险等级,对其申请所开展业务的种类、范围进行区分和管理;应对服务对象接入设施的标准符合性进行核验,保证接入设施符合国家相关政策及标准要求。
9.2TR风险控制要求TR风险控制要求如下:
应面向用户提供欺诈防范咨询服务和紧急援助服务;应通过编写风险防范指引等材料,协同银行、非银行支付机构、支付转接清算机构等相关机构向用户或商户提供风险管理业务培训;信息采集的终端设备应具备相应安全防护措施。
10安全要求10.1物理安全应符合JR/T00712012,6.2.1.1中的要求。
10.2网络安全应符合JR/T00712012,6.2.1.2中的要求。
10.3主机安全应符合JR/T00712012,6.2.1.3中的要求。
10.4应用安全10.4.1身份鉴别应符合JR/T00712012,6.2.1.4中列项1)要求。
10.4.2访问控制应符合JR/T00712012,6.2.1.4中列项2)要求。
10.4.3安全审计应符合JR/T00712012,6.2.1.4中列项3)要求。
10.4.4剩余信息保护应符合JR/T00712012,6.2.1.4中列项4)要求。
JR/T01492016910.4.5通信完整性应符合JR/T00712012,6.2.1.4中列项5)要求。
10.4.6通信保密性应符合JR/T00712012,6.2.1.4中列项6)要求。
10.4.7抗抵赖应符合JR/T00712012,6.2.1.4中列项7)要求。
10.4.8应用容错应符合JR/T00712012,6.2.1.4中列项8)要求。
10.4.9资源控制应符合JR/T00712012,6.2.1.4中列项9)要求。
10.4.10会话安全会话安全要求如下:
会话标识应唯一,并具有随机性;会话过程中应维持认证状态,防止信息未经授权访问;会话结束后,应及时清除会话信息;应采取措施防止会话令牌在传输、存储过程中被窃取;应用审计日志应记录暴力破解会话令牌的事件。
10.4.11常见攻击防范常见攻击防范要求如下:
应在服务器端对用户提交的数据进行有效性检查(如对提交的表单、参数等进行合法性判断和非法字符过滤等),或对输出进行安全处理;应进行代码审查,防范应用程序中不可信数据被解析为命令或查询语句等;应开发安全的接口,如通过避免语句的完全解释或采用参数化接口等方式实现;应采取有效措施防范服务器端的拒绝服务攻击;应对文件的上传和下载进行访问控制,避免执行恶意文件或未授权访问;数据库应使用存储过程或参数化查询,并严格定义数据库用户的角色和权限;应通过自动化工具(如弱点扫描工具、静态代码检测工具等)对应用程序进行检查;应使用安全控件、安全插件等措施以降低恶意软件窃取敏感信息的风险;应定期进行漏洞扫描和渗透性测试,并对已知漏洞及时进行修补。
10.4.12WEB页面安全WEB页面安全要求如下:
应提供登录防穷举的措施,如图片验证码等;登录应使用安全控件;应使用服务器证书,并在整个生命周期保障Token的安全;网站页面应采取防范SQL注入、Path注入和LDAP注入等风险的措施;JR/T0149201610网站页面应采取防范跨站脚本攻击风险的措施;网站页面应采取防范源代码暴露的措施;应采取防范网站页面黑客挂马的机制和措施;应部署防篡改措施或设备;网站页面应提供防钓鱼网站的防伪信息验证。
10.4.13客户端程序安全客户端程序安全要求如下:
移动终端客户端程序发布前应进行严格的代码安全测试,防止存在SQL注入、后门等漏洞;移动终端客户端程序应具有抗逆向分析、抗反汇编等安全性防护措施,防范攻击者对移动终端客户端程序的调试、分析和篡改;移动终端客户端程序应具备完整性校验功能防止程序文件被非授权篡改;移动客户端程序安装及卸载功能应满足安全需求;应对客户端应用软件敏感数据留存情况进行检查,防止客户敏感信息泄露;应对客户端配置文件进行保护,严格控制对其的访问、修改等操作;用户口令等敏感信息在本地不应明文存储;禁止明文显示密码,应使用相同位数的同一特殊字符(例如*或#)代替;应建立客户端程序的安全检测机制,每年至少全面检测一次,通过程序升级等方式及时修补漏洞;客户端应具备客户端环境安全检测能力,在检测到运行环境处于ROOT或已越狱等非安全环境时,向客户进行必要的安全警示,必要时可停止运行客户端;客户端对用户登录应采取限定连续登录失败次数等措施;当客户端检测到移动终端交易出现异常时应向用户提示出错信息;客户端在使用过身份认证、交易等敏感信息后,应及时清除敏感数据;客户端宜提供数据有效性校验功能,保证通过人机接口或通信接口输入的数据格式或长度等信息符合系统设定要求,如输入的资金金额、账户等信息应不含特殊字符;客户端宜具备页面回退清除敏感信息的机制;用户输入敏感数据时,宜采取安全措施保证敏感数据不被移动终端的其他设备或程序非授权获取;用户输入敏感数据时,宜采取防篡改机制保证数据不被移动终端的其他设备或程序篡改。
10.4.14用户与TR系统间安全要求用户与TR系统间安全要求如下:
用户通过互联网连接TR传输数据时,应采用数字证书保证数据的机密性、完整性和不可抵赖性。
应使用足够强度的加密算法和安全协议保护客户端与服务器之间的连接;采集账户敏感信息时,TR应使用符合要求的安全控件对敏感信息进行保护;TR不得留存账户敏感信息。
TR存储Token时,应对Token实施有效的安全保护。
10.4.15TR与TSP系统间安全要求TR与TSP系统间安全要求如下:
所有TR与TSP系统之间的报文中的敏感信息应加密传输;TR通过互联网连接TSP传输数据时,应采用数字证书保证数据的机密性、完整性和不可抵赖性。
应使用安全算法和安全协议保护客户端与服务器之间的连接。
JR/T014920161110.5数据安全10.5.1数据完整性应符合JR/T00712012,6.2.1.5中列项1)要求。
10.5.2数据保密性应符合JR/T00712012,6.2.1.5中列项2)要求。
在申请Token的过程中对于敏感数据要进行加密处理。
申请过程包括用户信息采集、信息传递、信息存储。
敏感数据主要包括PA及验证要素。
10.5.3备份和恢复应符合JR/T00712012,6.2.1.5中列项3)要求。
10.5.4报文安全报文安全要求如下:
应对报文完整性进行验证;应保证报文保密性。
10.5.5安全算法应使用经国家密码管理机构认可的商用密码产品。
10.6运维安全10.6.1环境管理应符合JR/T00712012,6.2.2.5中列项1)要求。
10.6.2资产管理应符合JR/T00712012,6.2.2.5中列项2)要求。
10.6.3介质管理应符合JR/T00712012,6.2.2.5中列项3)要求。
10.6.4设备管理应符合JR/T00712012,6.2.2.5中列项4)要求。
10.6.5监控管理应符合JR/T00712012,6.2.2.5中列项5)要求。
10.6.6网络安全管理应符合JR/T00712012,6.2.2.5中列项6)要求。
应至少每半年对网络系统进行一次漏洞扫描,并保存扫描记录。
应对扫描发现的漏洞进行处理。
10.6.7系统安全管理JR/T0149201612应符合JR/T00712012,6.2.2.5中列项7)要求。
10.6.8恶意代码防范管理应符合JR/T00712012,6.2.2.5中列项8)要求。
10.6.9密码管理应符合JR/T00712012,6.2.2.5中列项9)要求。
1
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- JR-T 01492016 中国金融移动支付 支付标记化技术规范 JR 0149 2016 中国金融 移动 支付 标记 技术规范