新疆银行股份有限公司企业标准

移动金融客户端应用规范

    目 次

1 范围 1

2 规范性引用文件 1

3 术语和定义 1

4 缩略语 2

5 客户端应用软件安全要求 2

6 客户端应用软件管理要求 8

7 客户端应用软件技术要求 9

8 个人金融信息安全 11

9 创新及前瞻性 13

    前  言

本文件按照GB/T 1.1—2020规定起草。

本标准所有内容符合强制性国家标准、行业标准，若与其相抵触，以国家标准、行业标准为准。

本文件由新疆银行股份有限公司提出并归口。

本标准起草单位：新疆银行股份有限公司。

本标准主要起草人：新疆银行股份有限公司科技信息部。


移动金融客户端应用标准

1　范围

本文件规定了新疆银行银行移动金融客户端应用软件安全要求、管理要求、技术要求、个人金融信息安全、创新及前瞻的要求。

本文件适用于新疆银行移动金融客户端应用软件的设计、开发、发布和运维过程。

2　规范性引用文件 

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

GB/T 35273-2020 信息安全技术个人信息安全规范

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

JR/T 0092-2019 移动金融客户端应用软件安全管理规范

JR/T 0149-2016 中国金融移动支付 支付标记化技术规范

3　术语和定义

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

3.1  
移动终端 mobile,device

在移动业务中使用的终端设备，包括智能手机、平板电脑等通用终端和专用终端设备。

3.2
移动金融客户端应用软件 financial mobile application software

在移动终端上为用户提供金融交易服务的应用软件。

注:包括但不限于可执行文件、组件等。

3.3
个人金融信息 personal financial information

金融业机构通过提供金融产品和服务或者其他渠道获取、加工和保存的个人信息。

注: 包括账户信息、鉴别信息、金融交易信息、个人身份信息、财产信息、借贷信息及其他反应特定个人某些情况的信息。

3.4
支付敏感信息 payment sensitive information

支付信息中涉及支付主体隐私和身份识别的重要信息。

注:包括但不限于银行卡磁道或芯片信息、卡片验证码、卡片有效期、银行卡密码、网络支付交易密码等。

    3.5

主体 subject

引起信息在客体之间流动的人、进程或设备等。

3.6

客体 object

信息的载体

3.7

信道 channel

系统内的信息传输路径。

4　缩略语

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

APP：应用程序（Application）

SDK：软件开发工具包（Software Development Kit）

URL：统一资源标识符（Uniform Resource Locator）

TEE 可信执行环境（Trusted Execution Environment）

SE 安全单元（Secure Element）

5　客户端应用软件安全要求

5.1 身份认证安全

5.1.1 认证方式

a) 客户端应用软件登录时应采用适宜的验证要素，包括但不限于口令、短信验证码、生物特征识别等方式。

b) 应确保采用的身份验证要素相互独立,即部分要素的损坏或者泄露不应导致其他要素损坏或者泄露。

c) 客户端应用软件交易时应按照相关业务管理要求对用户身份进行认证。

d) 若采用图形验证码作为验证的辅助要素，图形验证码应具有使用时间限制并仅能使用一次，图形验证码应由服务器生成，客户端源文件中不应包含图形验证码文本内容。

e) 图形验证码不得作为独立的身份验证要素。

5.1.2 认证信息安全

5.1.2.1 安全输入

客户端应用软件应提供客户输入银行卡支付密码和网络支付交易密码的即时防护功能,客户端应提供以下安全控制措施，或其他经攻击测试无法获取明文的安全防护措施。

a) 采取替换输入框原文。

b) 逐字符加密、字符加密。

c) 防范键盘窃听。

d) 采用自定义软键盘。

e) 自定义软键盘界面必须具有防截屏能力，对于可以实现防截屏能力的平台(例如 Android 平台)，字符点按可以实现点按效果，不能实现放大效果，对于无法实现防截屏能力的平台(例如 IOS 平台与 H5)，字符点按不能实现任何点按、放大效果。

5.1.2.2 个人金融信息展示

a) 客户端应用软件的口令框应默认屏蔽显示，屏蔽显示时应使用同一特殊字符(例如*或·)代替。

b) 客户端应用软件不应明文显示银行卡密码和网络支付交易密码。

5.1.3 认证失败处理

a) 客户端应用软件应提供认证失败处理功能，可采取结束会话、限制失败登录次数和自动退出等措施。

b) 在提示客户认证失败时，应模糊错误提示信息，防止错误提示信息中泄露用户全部账号、交易金额等敏感数据。

5.1.4 密码的设定与重置

a) 客户端应用软件应配合服务端提供密码复杂度校验功能，提醒并保证用户设置的密码达到一定的强度,避免采用简单交易密码或与客户个人信息相似度过高的交易密码。

b) 应严格限制使用初始登录密码与初始交易密码，若设置初始密码，应强制用户在首次登录后修改初始密码。

c) 在修改密码前，应对用户身份进行重新验证。

d) 修改密码时应对原密码输入错误次数进行限制。

e) 修改密码时新密码不应与原密码相同。

f) 在密码重置时，应使用短信验证码、用户注册信息校核等方式，对用户身份进行校验。

增强要求:

a) 在进行修改密码或密码重置时，应采用两种或两种以上要素进行身份认证，如: 短信验证、数字证书、生物特征信息等。

b) 应采取有效措施提醒客户避免设置连续或重复数字、生日、证件号、手机号、卡号作为密码，并采取有效措施引导客户设置独立的支付密码。

5.2 逻辑安全

5.2.1 逻辑安全设计

a) 对于认证、校验等安全保证功能的流程设计应充分考虑其合理性，避免逻辑漏洞的出现，确保认证流程无法被绕过。

b) 对于交易处理功能逻辑设计应充分考虑其合理性，避免逻辑漏洞的出现，保证资金交易安全。

c) 客户端代码实现应尽量避免调用存在安全漏洞的函数，避免敏感数据硬编码。

5.2.2 软件权限控制

a) 客户端应用软件向移动终端操作系统申请权限时，应遵循最小权限原则。

b) 针对对客服务的 Android 客户端组件,应严格设置客户端组件的访问权限,并具备防劫持功能。

c) 应根据业务需求获取相关功能必须的系统权限，并通过弹窗提示、页面文字说明等方式告知用户申请权限的目的，文字描述应清晰明确。

d) 应在用户触发功能场景时请求相关权限，申请权限类型和范围不应超出业务功能所需。

e) 客户端应用软件内部使用的类、变量及接口应私有化，防止外部非法调用。

f) 对于安卓客户端应用软件内部使用的组件，应在配置文件中将 exported 属性设置未 false,防止被外部非法调用。

g) 客户端应用软件宜在用户首次使用交易时要求用户绑定可信终端，防止用户账户被盗用。

5.2.3 风险控制

a) 应设计合理的登录风险控制策略，包括但不限于:

l 当用户闲置在线状态超出时限时，应设计合理的账户登录超时控制策略

l 合理的多点登录策咯，如: 提示登录信息或退出先登录的账户等策略。

b) 应设计合理的交易风险控制策咯，包括但不限于:

l 针对不同的资金交易金额，应设计合理的身份认证策路。

l 针对不同的资金交易业务场景，应设计合理的策略，如: 限额度控制策略、时限控制策略。

c) 客户端应用软件应配合业务交易风险控制策略，以安全的方式将相关信息上送至风险控制系

统。

5.2.4 回退处理

交易过程中如遇交易失败或在交易完成前用户进行撤销操作，应返回到交易前的有效状态。

5.2.5 异常处理

a) 客户端应用软件发生故障产生的异常信息，不应泄露用户的敏感数据。

b) 当交易出现异常时，客户端应用软件应向客户提示出错等信息，但不应泄露用户的敏感数据。

5.3 安全功能设计

5.3.1 组件安全

a) 客户端应用软件应避免使用存在已知漏洞的系统组件与第三方组件。

b) 客户端应用软件在使用第三方组件时,应避免第三方组件未经授权收集客户端应用软件信

息和个人信息。

5.3.2 接口安全

a) 客户端应用软件应对软件接口进行保护,防止其他应用对客户端应用软件接口进行非授权调用。

b) 客户端应用软件应对传入的 URL 进行校验与安全处理,防止客户端应用软件运行异常或操作异常。

c) 当客户端应用软件需要与 TEE、SE 结合使用时，应避免使用存在已知漏洞的接口。

5.3.3 抗攻击能力

a) 客户端应用软件应具备基本的抗攻击能力，能抵御静态分析、动态调试等操作。

b) 客户端代码应使用代码加壳、代码混淆等手段对客户端应用软件进行安全保护。

c) 客户端应用软件安装、启动、更新时应对自身的完整性和真实性进行校验，具备抵御篡改、替换或劫持的能力。

d) 客户端应用软件如使用安全输入控件， 该控件应具备抵御一定程度攻击的能力。

e) 客户端应用软件原则上不允许保存密钥,如必须保存应采取有效措施保证所涉及密钥的机密性和完整性。

f) 客户端应用软件应适时更新使用的第三方组件至安全稳定的版本。

5.3.4 客户端应用软件环境检测

a) 客户端应用软件在运行时应具备对运行环境的检查能力，

b) 客户端应用软件在运行时对运行环境进行检查的范围可包括:

l 系统是否被未经授权获取管理员权限；

l 程序运行环境是否可信(如:是否运行在模拟器或虚拟机中)等；

l 能向后台系统反馈设备信息等。

5.4 密码算法及密钥管理

5.4.1 密码算法

a) 客户端应用软件应使用密码算法对资金有关交易或重要业务操作进行保护。

b) 密码算法、密钥长度及密钥管理方式应符合国家密码主管部门的要求

c) 密码算法优先使用国密算法。

5.4.2 密钥管理

a) 密钥在传输过程中应使用密码算法对密钥进行保护。

b) 随机生成的密钥应具有一定的随机性与不可预测性。

c) 密钥应加密存储，并确保密钥储存位置和形式的安全。

d) 针对对称加密算法存储加密密钥: 建议不同应用系统使用不同密钥，原则上不允许多个应用系统共享同一把存储加密密钥。

e) 密钥应按照其用途使用，在进行身份鉴别以及保证数据的完整性和抗抵赖时使用签名密钥，在保证数据的保密性时使用加密密钥。

f) 立确保加密和签名的密钥的不同，并且分离存放;使用加密机、加密卡、智能卡、USB Key 等硬件加密模块产生密钥并进行密码运算，保护密钥和密码的安全。

5.5 数据安全

5.5.1 数据获取

5.5.1.1 数据防窃取

a) 客户端应用软件应保证内存中不应存在完整的银行卡密码和网络支付交易密码明文。

b) 客户端应用软件的临时文件中不应出现支付敏感信息，临时文件包括但不限于 Cookies、本地临时文件等。

c) 客户端应用软件程序应禁止在身份认证结束后存储支付敏感信息，防止支付敏感信息泄露。

d) 客户端应用软件运行日志中不应打印支付敏感信息，不应打印完整的敏感数据原文。

e) 客户端应用软件应实现身证过程的防截屏、录屏，如: 输入手势验证码、登录口令等。

5.5.1.2 数据防篡改

用户输入关键交易数据时，如:收款人信息、交易金额、订单号等，应采取防篡改机制保

证数据不被移动终端的其他程序篡改。

5.5.1.3 数据有效性

客户端应用软件在数据获取时提供有效性校验功能,确保通过人机接口或通信接口输入的数据格式或长度等信息符合系统设定要求。

5.5.2 数据访问控制

a) 应采取措施保护客户端应用软件数据仅能被授权用户或授权应用组件访问。

b) 客户端应用软件在授权范围内，不应访问非业务必需的文件和数据。

5.5.3 数据传输

5.5.3.1 通讯安全

a) 应在客户端应用软件与服务器之间建立安全的信息传输通道,协议版本应及时更新至安全稳定版本。

b) 应确保采用的安全协议不包含已知的公开漏洞。

c) 客户端应用软件与服务器应进行双向认证，可通过密钥、证书等密码技术手段实现服务器与客户端应用软件之间的安全认证。

d) 客户端应用软件应能验证服务器的真是性。如通过 HTTPS 协议链接的站点，客户端应用软件应验证服务器站点证书的真是性，验证步骤包括服务端证书中域名与访问域名的匹配、证书链的合法性校验等。

e) 交易信息在网络传输时，客户端应用软件应使用 HTTPS 等安全协议，对敏感数据在应用层进行加密传输。

5.5.3.2 数据保密性

a) 敏感数据(如: 登录口令、支付敏感信息等)在客户端应用软件与本地其他应用软件间传输时，应采取加密等措施确保其保密性，若本地其他应用软件不能提供与金融客户端软件相应等级的加密接口，则应评估敏感数据调用的风险，并设计补救措施。

b) 敏感数据(如: 登录口令、支付敏感信息等)在通过公共网络传输时，应采取加密等措施确保其保密性)。

c) 客户端与服务端交互时应采用对称加密等密码技术保证敏感数据在传输过程中的保密性。

d) 客户端应采用密码技术保证敏感数据在存储过程中的保密性。

5.5.3.3 数据完整性

a) 关键的交易数据，如:收款人信息、交易金额、订单号等，在客户端应用软件与本地其他应用软件间传输时，应采取措施(如: 数字签名、MAC 等)确保其完整性，若本地其他应用软件不能提供与金融客户端软件相应等级的数据完整性保护措施,则应评估关键数据传输的风险，并设计补救措施。

b) 关键的交易数据、个人身份信息，如: 收款人信息、交易金额、订单号、身份证号码等,在通过公共网络传输时，应采取措施(如: 数字签名、MAC 等)确保其完整性。

5.5.3.4 数据抗抵赖

通过客户端应用软件发起的资金类交易报文，应确保交易报文的不可抵赖性，若有条件的情况下应采用数字证书技术。

5.5.3.5 数据防重放

a) 通过客户端应用软件发起的身份认证或资金类交易报文，应能够防止重放攻击。

b) 对于在转账、贷款等动账功能中，应进行防重复提交设计。一般防重复提交措施:

l loading 防重:交易提交后立刻弹出全屏 loading 遮罩层，直至后端服务处理完交易请求并返可交易结果。

l 按钮置灰防重:点击提交按钮后立刻将按钮设置为失效状态。

l Token 防重: 提交之前应从后端获取防重 token，上送后端验证 token 有效性，token 仅使用次后失效。

5.5.4 数据存储

5.5.4.1 个人金融信息存储

a) 客户端应用软件不应以任何形式存储用户的支付敏感信息与金融业务查询口令。

b) 在满足法律、管理规定的前提下，客户端应用软件应仅保存业务必需的个人金融信息，并限制数据存储量。

c) 客户端应用软件原则上不应保留个人金融信息，必须保留的应加密存储。

5.5.4.2 加密密钥存储

客户端应用软件应确保无法通过逆向工程等手段直接从本地文件系统中恢复完整的密钥明文

5.5.5 数据展示

除交易对账、转账收款方确认等必须由用户确认的情况外，客户端应用软件在显示个人信息，如:银行账号、身份证号码、手机号码、姓名等时应屏蔽关键字段。

5.5.6 数据销毁

5.5.6.1 残余信息保护

a) 客户端应用软件应在敏感数据使用完毕后，对其立即进行清除。

b) 客户端应用软件进程被结束时，应清除非业务功能运行所必需留存的业务数据，保证客户信息的安全性。

c) 客户端应用软件卸载完成后，文件系统中不应残留任何个人金融信息。

d) 客户端应用软件应确保无法通过技术手段恢复已清除的敏感数据。

5.5.6.2 页面返回保护

a) 客户端应用软件应支持页面返回后白动清除银行卡密码、网络支付交易密码、登录口令等支付敏感信息的机制。

b) 客户端应用软件应对后台任务列表中的预览界面采取模糊或其他防护措施。

c) 当客户端应用软件从前台进入后台时， 超过设定时限后应清除页面中已输入的敏感数据。

d) 当客户端应用软件从前台进入后台时，应根据场景对用户进行风险提示。

5.5.6.3 会话失效

a) 客户端应用软件在安全退出登录时，应向服务器发送会话结束请求，使当前会话状态失效。

b) 应用系统应提供会话超时机制，在一定空闲时间后将用户强制退出登录状态，用户再次接入需要强制其重新登录。

6　客户端应用软件管理要求

6.1 设计要求

a) 客户端应用软件设计应遵循安全、可靠、易用、可维护和可扩展等原则，制定用于指导客户端应用软件设计与开发的总体方案。

b) 客户端应用软件应提供易用、风格统一、体验良好的用户界面。

c) 客户端应用软件应遵循合法、正当、必要的原则，不收集与所提供服务无关的个人金融信息。

d) 客户端应用软件收集个人金融信息或用户授权等操作前，要以通俗易懂、简单明了的方式展示个人金融信息收集使用规则，并经个人金融信息主体自主选择同意。

e) 客户端应用软件不得以默认、捆绑、停止安装使用等手段变相强迫用户授权，不得违反与用户的约定收集使用个人金融信息。

f) 客户端应用软件应提供访问、更正个人金融信息，以及授权撤销、账户注销等功能。

6.2 开发要求

a) 客户端应用软件开发过程中应遵守严格的开发流程、项目管理流程和编码安全规范，进行完整的测试，避免在请求、响应、存储、配置等功能中存在漏洞。

b) 客户端应用软件开发过程中应建立并维护开发文档。

c) 客户端应用软件开发完成后，应同步完成产品手册、用户手册或提供在线帮助说明功能。

d) 客户端应用软件的每次重要更新、升级，都必须经过严格归档、源代码扫描、发布审核等步骤。

6.3 发布要求

a) 客户端应用软件应有规范的上线发布流程，由应用软件的所有方对应用软件进行签名和保护，标识应用软件的来源和发布者，提供安全可靠的应用软件下载、发布、升级渠道。

b) 客户端应用软件应当删除调试或测试中存留的敏感数据。

c) 客户端应用软件安装过程中，应拥有独立的安装目录，唯一的应用标识符，明确的版本序号不得篡改、覆盖、删除系统文件和其他软件。

d) 客户端应用软件有新版本时，不能未经用户允许自动安装新版本。

e) 若客户端应用软件支持动态模块更新,应使用加密信道与服务端通信传输更新模块或对更改模块进行签名校验,动态模块更新后不得影响用户使用，不得修改用户已有的安全配置。

6.4 维护要求

a) 应制定科学、合理的管理策略和执行制度，指导各类角色的工作协同、实施步骤、质量管控、安全检测等，规范日常运维流程。

b) 客户端应用软件应具有明确的应用标识符和版本序号，设计合理的更新接口、当某一版本被证明存在安全隐患时，应及时进行修复更新。

c) 以SDK等形式对外提供金融交易类服务时,应记录SDK信息及引用本SDK的外部应用软件信息。

7　客户端应用软件技术要求

7.1兼容性

a) Android APP 端应最低向下兼容 Android 4.4版本，最高向上兼容最新发布的Android版本。

b) Android APP 应横向兼容各大 Android 广商的定制化系统。

c) iOS APP 端应最低向下兼容 iOS 9 版本，最高向上兼容最新发布的iOS版本。

7.2性能

7.2.1数据缓存

7.2.1.1客户端缓存

a) 客户端对更新机率小的数据可进行缓存处理，提高响应速度。

b) 客户端可将图片缓存到本地，减少图片重复下载及网络流量损耗，提升处理效率及体验。

c) 客户端应控制缓存数据量，增加定期清空机制，并重点控制不断累计增加的数据。

7.2.1.2服务端缓存

a) 对每个用户请求返回均一致的公共数据可在服务端进行缓存，减少向后端服务发送请求的次数以及网络传输时间，减轻后端服务的压力。

b) 服务端缓存应制定与数据源的数据同步保鲜机制。

7.2.1.3 Session数据缓存

对于更新几率小的用户数据，可通过 session 进行缓存。

7.2.2内存优化

a) 页面布局应避免冗余，减少内存使用。

b)  应避免使用占用内存较大的静态变量和常量。

c)  创建大量局部变量、加载较大资源文件应及时释放。

d) 图片资源优先使用 webP、SVG 等占用内存低的文件格式。

e) 可通过 CDN图片尺寸、裁剪等图片处理措施，将不同分辨率的图片放到对应的目录，根据场景加载适合大小的图片，提高用户体验。

f) 通过 bitmap 压缩优化时，没有透明要求的图片可用 RGB 565 模式。

7.3版本管理

7.3.1应用更新

7.3.1.1 更新方式

更新方式分为提示更新和强制更新两种:

a) 提示更新: 客户端应提供更新操作提示，可选择是否更新;对于新功能的发布或问题修复，优先通过离线资源更新。

b) 强制更新:移动终端应用应提供强制更新机制。

7.3.1.2 更新控制

a) 移动终端应用可根据客户端版本与最新发布版本差异的大小进行版本更新控制，例如: 提示更新、强制更新。

b) 在发布新版本客户端时，应将离线资源替换到最新发布的客户端包内，减少流量消耗。

c) 应对离线资源进行防篡改校验，防止离线资源在传输过程中被非法篡改。

7.3.2 安装包大小优化

a) 预置离线包应只预置常用模块,在 WIFI 环境下全量更新离线包，非 WIFI 环境下应只更新常用离线包，不常用的离线包在点击进入模块时更新。

b) 应用程序应进行混淆、压缩。

c) 不必要的类、属性、方法等应及时进行清理。

8　个人金融信息安全

8.1 收集

a) 应采取技术措施(如弹窗、明显位置 URL 链接等)，引导个人金融信息主体查阅隐私政策,并获得其明示同意后，开展有关个人金融信息的收集活动。

b) 遵循合法、正当、必要的原则，向个人金融信息主体明示收集与使用个人金融信息的目的、方式、范围和规则等，不得收集与所提供服务无关的个人金融信息。

c) 客户端收集 C3(用户鉴别信息) 类别个人金融信息时，应使用加密等技术措施保证数据的保密性，防止其被未授权的第三方获取。

d) 客户端应用软件向移动终端操作系统申请权限时，应遵循最小权限原则。

e) 应确保收集个人金融信息来源的可追溯性。

f) 各业务功能实际收集的个人信息类型应与用户隐私政策所描述内容一致,避免超范围收集使用个人信息。

g) 应根据用户主动填写、点击、勾选等自主行为，作为相关业务功能开始收集个人信息的条件。

h) 涉及收集使用个人敏感信息的，应通过弹出提示等明显方式向用户明示收集或使用的目的、方式、范围。

i) 在用户使用相关业务功能时申请获取系统权限，应说明使用该权限收集个人信息的目的;对于用户明确拒绝使用、关闭或退出的特定业务功能，应避免反复询问用户是否打开该业务功能或相关系统权限。

8.2 传输

个人信息传输过程应保证信息在传输过程中的机密性、完整性和可用性。

a) 应根据个人金融信息的不同类别，采用技术手段保证个人金融信息的安全传输，如安全通道、数据加密等技术措施。

b) 个人金融信息传输的接收方应对接收的个人金融信息进行完整性校验。

c) 传输个人金融信息前，通信双方应通过有效技术手段进行身份鉴别和认证;

d) 通过公共网络传输时，C2、C3 类别信息应使用加密通道或数据加密的方式进行传输，保障个人金融信息传输过程的安全;对于 C3 类别中的支付敏感信息，其安全传输技术控制措施应符合有关行业技术标准与行业主管部门有关规定要求;

e) 低敏感程度类别的个人金融信息因参与身份鉴别等关键活动导致敏感程度上升的(如，经组合后构成交易授权完整要素的情况)，应提升相应的安全传输保障手段;

f) 应建立有效机制对个人金融信息传输安全策略进行审核、监控和优化，包括对通道安全配置、密码算法配置、密钥管理等保护措施的管理和监控;

g) 应采取有效措施(如个人金融信息传输链路冗余)保证数据传输可靠性和网络传输服务可用性。

8.3 存储

a) 客户端不应存储银行卡磁道数据(或芯片等效信息) 、银行卡有效期、卡片验证码 (CVN 和CVN2) 、银行卡密码、网络支付密码等支付敏感信息及个人生物识别信息的样本数据、模板,仅可保存完成当前交易所必需的基本信息要素，并在完成交易后及时予以清除。

b) 客户端不应留存非本机构的银行卡磁道数据(或芯片等效信息)、银行卡有效期、卡片验证码(CVN 和 CVN2) 、银行卡密码、网络支付密码等 C3(用户鉴别信息) 类别个人金融信息。若确有必要留存的，应取得个人金融信息主体及账户管理机构的授权。

c) C3(用户鉴别信息) 类别个人金融信息应采用加密措施确保数据存储的保密性。

d) 应将个人生物识别信息的样本数据、模板与银行账号或支付账号、身份证号等用户个人隐私信息进行隔离存储。

8.4 使用

a) 对于银行卡号、手机号码、证件类识别标识或其他识别标识信息等可以直接或组合后确定个人金融信息主体的信息应进行屏蔽展示，或由用户选择是否屏蔽展示，如需完整展示，应进行用户身份验证，并做好此类信息管理，防范此类信息泄露风险。

b) 支付账号及其等效信息在共享和转让时，除法律法规和行业主管部门另有规定外，应使用支付标记化(按照JR/T 0149-2016) 技术进行脱敏处理(因业务需要无法使用支付标记化技术时,应进行加密)，防范个人金融信息泄露风险。

c) 因金融产品或服务的需要，将收集的个人金融信息委托给第三方机构(包含外包服务机构与外部合作机构》处理时，应采用去标识化 (不应仅使用加密技术) 等方式进行脱敏处理，降低个人金融信息被泄露、误用、滥用的风险。

d) 在个人金融信息加工处理的过程中，应建立个人金融信息防泄露控制规范和机制，防止个人金融信息处理过程中的调试信息、白志记录等因不受控制的输出而泄露受保护的信息。

e) 开发环境、测试环境不应使用真实的个人金融信息，应使用虚构的或经过去标识化(不应仅使用加密技术)脱敏处理的个人金融信息，账号、卡号、协议号、支付指令等测试确需个人金融信息除外。

8.5 删除

a) 应采取技术手段,在金融产品和服务所涉及的系统中去除个人金融信息,使其保持不可被检索和访问。

b) 个人金融信息主体要求删除个人金融信息时,金融业机构应依据国家法律法规、行业主管部门有关规定以及与个人金融信息主体的约定予以响应。

8.6 销毁

应建立个人金融信息销毁策略和管理制度,明确销毁对象、流程、方式和要求。

9　创新及前瞻性

应根据金融客户端业务场景合理运用生物特征识别、云计算、大数据和人工智能技术提供业务创新能力支持:

a) 对于高风险业务场景，可应用声纹识别、人脸识别等生物特征识别技术，作为多因子身份验证的辅助手段。

b) 对于低风险业务场景，可应用声纹识别、人脸识别等生物特征识别技术，作为身份验证手段,提升用户体验。

c) 利用以语音识别技术构建的语音交互服务，提供智能语音输入、搜索和播报等功能。

d) 利用人工智能和大数据技术，提升对用户的精准刻画能力，并且构建反欺诈安全防控能力。


参 考 文 献

[1] GB/T 25069-2010 信息安全技术 术语

[2] GB/T 35273 2017 信息安全技术 个人信息安全规范

[3] JR/T 0149 2016中国金融移动支付 支付标记化技术规范

[4] JR/T 0156 2017移动终端支付可信环境技术规范

[5] JR/T 0164一2018 移动金融基于声纹识别的安全应用技术规范

[6] 中国人民银行，中国人民银行关于银行业金融机构做好个人金融信息保护工作的通知(银发(2011) 17号) ，2011-1-21

[7] 中国人民银行，中国人民银行关于进一步加强银行卡风险管理的通知(银发(2016) 170号)2016-6-13

[8] 中国人民银行，中国人民银行关于印发《中国人民银行金融消费者权益保护实施办法》的通知(银发(2016) 314号) ，2016-12-14

[9] 中国人民银行，中国人民银行办公厅关于加强条码支付安全管理的通知(银办发(2017) 242号)，2017-12-22