中国人民银行：开展金融科技应用风险专项摸排工作

近日，人民银行下发《关于开展金融科技应用风险专项摸排工作的通知》（银办发〔2020〕45号）（以下简称“45号文”），要求各地人民银行分支机构及相关监管机构启动金融科技风险专项摸排工作。

金融科技作为行业热点近两年热度丝毫不减，由于行业发展需要，热度甚至不断上升，不断有公司投入其中。其中有政策的倾斜因素也有市场利好原因在其中。此次摸排工作要摸排什么？怎么进行？有一些事情必须要知道。

摸排工作具体安排

此次摸排工作将持续5个月，分为三个阶段。从2020年5月开始，10月结束，在三个阶段有不同的目标任务。

首先，由金融机构根据摸排列表进行逐项自评，并提交报告。针对发现的问题要建立清单管控和动态追踪。后续由人民银行等监管机构对自评情况进行核实，并在10月31日前形成书面报告报送总行。

据移动支付网了解，本次摸排工作主要范围包括移动金融客户端应用软件、应用程序编程接口、信息系统等。涉及人工智能、大数据、区块链、物联网等新技术金融应用风险。

其中包括个人金融信息保护、交易安全、仿冒漏洞、技术使用安全、内控管理等5个方面风险情况，覆盖40个摸排项，共123个摸排要点。参与机构主要为人民银行分支机构，中国支付清算协会、中国互联网金融协会也将参与其中。

此次摸排主要依据《个人金融信息保护技术规范》、《移动金融客户端应用软件安全管理规范》等相关技术规范，以及《金融科技（FinTech）发展规划（2019-2021年）》等金融科技相关文件。

摸排或将帮助规范落地

在去年12月，人民银行下发了《关于发布金融行业标准加强移动金融客户端应用软件安全管理通知》（银发〔2019〕237号），并随通知发布了《移动金融客户端应用软件安全管理规范》。在规范中，对移动客户端的身份认证安全、逻辑安全、安全功能设计、密码算法及密钥管理、数据安全都做出了要求。

随后在今年2月，人民银行又发布了和237号文一脉相承的《个人金融信息保护技术规范》，并在其中再次强调，个人金融信息相关的客户端应用软件及应用软件开发工具包（SDK）应符合《移动金融客户端应用软件安全管理规范》、《网上银行系统信息安全通用规范》客户端应用软件有关安全技术要求。

在此次摸排依据的5个规范标准当中有4个是在半年内发布。有专业人士认为，人民银行此次摸排专项行动将有助于相关规范快速落地，并以此为契机，再次推动移动金融客户端备案工作。

据媒体报道，截至2020年1月13日，已经有53家公司向协会申请了备案，App数量合计70项，且备案状态均处于“已登记”状态，暂无App通过备案。

此次摸排工作或将帮助人民银行了解目前金融科技发展现状，进行查漏补缺，避免再次出现表外业务泛滥、同业业务异化等行业乱像，进行有效监管。当然，摸排情况很有可能会决定新的监管政策动态。

日前，人民银行在上海等6市（区）扩大金融科技创新监管试点，旨在秉持包容审慎并重的理念，探索新型柔性监管方法，建立创新试错容错机制，增强监管部门、创新主体、社会公众之间的信息交流和良性互动。（伟辰）

参考资料：

人行关于金融科技应用风险专项摸排列表

一、此次专项摸依据：

《中华人民共和国网络安全法》

《金融科技发展规划（2019-2021年）》

《市场监管总局人民银行发布金融科技产品认证目录（第一批）》

《金融科技产品认证规则》

《加强移动金融客户端应用软件安全管理通知》237号文

二、内容：

个人金融信息保护
交易安全
仿冒漏洞
技术使用安全
内控管理

一共123点摸排项，供参考

序号	摸排项	摸排要点
序号	摸排项	摸排要点	一、个人金融信息保护
（一）技术防护。
1	收集	应采取技术措施（如弹窗、明显位置URL 链接等），引导个人金融信息主体查阅隐私政策，并获得其明示同意后，开展有关个人金融信息的收集活动。
2		遵循合法、正当、必要的原则，向个人金融信息主体明示收集与使用个人金融信息的目的、方式、范围和规则等，不得收集与所提供服务无关的个人金融信息。
3		通过受理终端、客户端应用软件、浏览器等方式收集C3（用户鉴别信息）类别个人金融信息时，应使用加密等技术措施保证数据的保密性，防止其被未授权的第三方获取。
4		客户端应用软件向移动终端操作系统申请权限时，应遵循最小权限原则。
5		应确保收集个人金融信息来源的可追溯性。
6		不应委托或授权无金融业相关资质的机构收集C3（用户鉴别信息）、C2(可识别主体身份与金融状况的个人金融信息）类别个人金融信息。
7	传输	应根据个人金融信息的不同类别，采用技术手段保证个人金融信息的安全传输，如安全通道、数据加密等技术措施。
8	传输	个人金融信息传输的接收方应对接收的个人金融信息进行完整性校验。
9	存储	受理终端、个人终端及客户端应用软件均不应存储银行卡磁道数据（或芯片等效信息）、银行卡有效期、卡片验证码（CVN 和CVN2）、银行卡密码、网络支付密码等支付敏感信息及个人生物识别信息的样本数据、模板，仅可保存完成当前交易所必需的基本信息要素，并在完成交易后及时予以清除。
10		不应留存非本机构的银行卡磁道数据（或芯片等效信息）、银行卡有效期、卡片验证码（CVN和CVN2）、银行卡密码、网络支付密码等C3（用户鉴别信息）类别个人金融信息。若确有必要留存的，应取得个人金融信息主体及账户管理机构的授权。
11		C3（用户鉴别信息）类别个人金融信息应采用加密措施确保数据存储的保密性。
12		应将个人生物识别信息的样本数据、模板与银行账号或支付账号、身份证号等用户个人隐私信息进行隔离存储。
13	使用	对于银行卡号、手机号码、证件类识别标识或其他识别标识信息等可以直接或组合后确定个人金融信息主体的信息应进行屏蔽展示，或由用户选择是否屏蔽展示，如需完整展示，应进行用户身份验证，并做好此类信息管理，防范此类信息泄露风险。
14		后台系统对支付账号、客户法定名称、支付预留手机号码、证件类或其他类识别标识信息等展示宜进行屏蔽处理，如需完整展示，应做好此类个人金融信息管理，采取有效措施防范未经授权的拷贝。
15		在个人金融信息共享和转让前，应开展个人金融信息接收方信息安全保障能力评估，并与其签署数据保护责任承诺。
16		应向个人金融信息主体告知共享、转让个人金融信息的目的、个人金融信息接收方的类型，并事先征得个人金融信息主体明示同意。
17		支付账号及其等效信息在共享和转让时，除法律法规和行业主管部门另有规定外，应使用支付标记化（按照JR/T 0149—2016）技术进行脱敏处理（因业务需要无法使用支付标记化技术时，应进行加密），防范个人金融信息泄露风险。
18		应执行严格的审核程序，并准确记录和保存个人金融信息共享和转让情况。记录内容应包括但不限于日期、规模、目的、范围，以及个人金融信息接收方基本情况与使用意图等，并应确保对共享和转让的个人金融信息及其过程可被追溯。
19		在个人金融信息共享和转让的过程中，应部署信息防泄露监控工具，监控及报告个人金融信息的违规外发行为。
20		个人金融信息原则上不得公开披露，经法律授权或具备合理事由确需公开披露时，应事先开展个人金融信息安全影响评估，准确记录和保存个人金融信息的公开披露情况，包括公开披露的日期、规模、目的、内容、公开范围等。
21		因金融产品或服务的需要，将收集的个人金融信息委托给第三方机构（包含外包服务机构与外部合作机构）处理时，应采用去标识化（不应仅使用加密技术）等方式进行脱敏处理，降低个人金融信息被泄露、误用、滥用的风险。
22		应对委托行为进行个人金融信息安全影响评估，并确保受委托者具备足够的数据安全能力，且提供了足够的安全保护措施。
23		在个人金融信息加工处理的过程中，应建立个人金融信息防泄露控制规范和机制，防止个人金融信息处理过程中的调试信息、日志记录等因不受控制的输出而泄露受保护的信息。
24		在个人金融信息开发测试过程中，应对开发测试环境与生产环境进行有效隔离。
25		开发环境、测试环境不应使用真实的个人金融信息，应使用虚构的或经过去标识化（不应仅使用加密技术）脱敏处理的个人金融信息，账号、卡号、协议号、支付指令等测试确需个人金融信息除外。
26		汇聚融合的个人金融信息不应超出收集时所声明的使用范围。因业务需要确需超范围使用的，应再次征得个人金融信息主体明示同意。
27	删除	应采取技术手段，在金融产品和服务所涉及的系统中去除个人金融信息，使其保持不可被检索和访问。
28	销毁	应对个人金融信息存储介质销毁过程进行监督与控制，对待销毁介质的登记、审批、介质交接、销毁执行等过程进行监督。
（二）安全管理。
29	安全策略	应建立个人金融信息保护制度体系，明确工作职责，规范工作流程。制度体系的管理范畴应涵盖本机构、外包服务机构与外部合作机构，并确保相关制度发布并传达给本机构员工及外部合作方（包括外包服务机构、外部合作机构）。相关制度应至少包括个人金融信息保护管理规定、日常管理及操作流程、外包服务机构与外部合作机构管理、内外部检查及监督机制、应急处理流程和预案、个人金融信息投诉与申诉处理程序。
30		应明确个人金融信息保护责任人和个人金融信息保护有关责任机构，并明确工作职责及工作流程。
31		应定期（至少每年一次）或在隐私政策发生重大变化时，对个人金融信息处理岗位上的相关人员开展个人金融信息安全专业化培训和考核，确保相关人员熟练掌握隐私政策和相关规程。
32	访问控制	对个人金融信息使用的权限管理应设置权限指派、回收、过期处理等安全功能。
33	访问控制	对于可访问和处理个人金融信息的系统应设置基于角色的访问控制策略，对系统用户个人金融信息的增删改查等操作进行记录，保证操作日志的完备性、可用性及可追溯性，操作日志包括但不限于业务操作日志、系统日志等，并要求系统运维管理类日志不应记录个人金融信息。
34	监测评估	应定期对涉及个人金融信息的信息系统进行安全检查和评估，特别是对于个人金融信息中的支付信息部分，应采取自行评估或委托外部机构进行检查评估，本机构以及与其合作的外部合作方（包括外包服务机构、外部合作机构）应每年至少开展一次支付信息安全合规评估，对评估过程中发现的问题及时采取补救措施并形成报告存档备查。
35	监测评估	应采取技术手段对个人金融信息全生命周期进行安全风险识别和管控，如恶意代码检测、异常流量监测、用户行为分析等。
36	事件处置	应制定个人金融信息安全事件应急预案，明确安全事件处置流程和岗位职责，并定期组织内部相关人员进行个人金融信息保护应急预案相关培训和应急演练。
37	事件处置	应建立投诉与申诉管理机制，包括跟踪流程，并在规定的时间内，对投诉、申诉进行响应。
二、交易安全
（一）电子认证。
38	电子认证与确认	应根据客户意愿，为其提供开通或关闭资金交易服务。
39		客户进行资金交易时，应采取认证强度与交易额度相匹配的技术措施，提高交易的安全性。
40		客户进行智能支付时，应采用支付口令或其他可靠的技术手段（通过国家统一推行的金融科技产品认证）实现本人主动确权，保障用户的知情权、财产安全权等合法权益。
41		电子认证应组合选用下列三类要素： 1.仅客户本人知悉的要素，如静态密码等； 2.仅客户本人持有并特有的，不可复制或者不可重复利用的要素，如经过安全认证的数字证书、电子签名，以及通过安全渠道生成和传输的一次性密码等； 3.客户本人生物特性要素，如指纹等。
42		资金交易完成后，特约商户受理终端和移动终端应显示交易结果。交易失败的，特约商户受理终端和移动终端应显示失败原因。
43		对于资金类交易等高风险业务，应在确保客户联系方式有效的前提下，及时告知客户其资金变化情况。
（二）交易监控。
44	交易监控	应建立交易监控系统，能够甄别并预警潜在风险的交易。
45		应根据交易的风险特征建立风险交易模型，有效监测可疑交易，对可疑交易建立报告、复核、查结机制。
46		应能对监控到的风险交易进行及时分析与处置。
47		应是否采用大数据分析、客户行为建模等手段，建立交易风险监控模型和系统。
48		应通过交易行为分析、机器学习等不断优化风险评估模型。
三、仿冒漏洞
49	仿冒	客户端应用软件安装、启动、更新时应对自身的完整性和真实性进行校验，具备抵御篡改、替换或劫持的能力。
50		客户端应用软件应具备基本的抗攻击能力，能抵御静态分析、动态调试等操作。
51		客户端代码应使用代码加壳、代码混淆、检测调试器等手段对客户端应用软件进行安全保护。
52		应采取渠道监控等措施对仿冒客户端程序进行监测。
53	钓鱼	应具有防网络钓鱼的功能，例如，显示客户预留信息、使用预留信息卡、客户自定义个性化界面等。
54		应采取防钓鱼网站控件、钓鱼网站监控工具、钓鱼网站发现服务等技术措施，及时监测发现钓鱼网站，并建立钓鱼网站案件报告及快速关闭钓鱼网站的处置机制。
55		应加强防钓鱼的应用控制和风险监控措施，例如，增加客户端提交的页面来源地址信息的校验、设置转账白名单等。
56	安全防护	应具备对处理个人金融信息的系统组件进行实时监测的能力，有效识别和阻止来自内外部的非法访问。
57		API和SDK应对常见的网络攻击具有安全防护能力。
58		移动终端应用SDK应具备静态逆向分析防护能力，防范攻击者通过静态反汇编、字符串分析、导入导出函数识别、配置文件分析等手段获得有关SDK实现方式的技术细节。
59		禁止应用方利用商业银行应用程序接口漏洞，进行网络攻击、信息窃取或交易欺诈等非法操作。
60	安全漏洞	对于交易处理功能逻辑设计应充分考虑其合理性，避免逻辑漏洞的出现，保证资金交易安全。
61		对于认证、校验等安全保证功能的流程设计应充分考虑其合理性，避免逻辑漏洞的出现，确保认证流程无法被绕过。
62		客户端代码实现应尽量避免调用存在安全漏洞的函数，避免敏感数据硬编码。
63		客户端程序应保证自身的安全性，避免代码注入、缓冲区溢出、非法提权等漏洞。
64		应对商业银行应用程序接口进行源代码安全审计、渗透测试等技术检查，及时处理安全漏洞，有效控制安全风险。
65		应不定期组织针对开源系统或组件的安全测评，及时进行漏洞修复和加固处理。
66		在应用系统上线前，应对程序代码进行代码复审，识别可能的后门程序、恶意代码、逻辑缺陷和安全漏洞。
67		应定期对系统进行漏洞扫描，及时修补发现的系统安全漏洞。
68	安全漏洞	应建立应用系统紧急补丁（应急方案）的开发、发布流程，以备必要时提供紧急补丁或应急方案进行处理，以修补重要安全漏洞。
69	安全漏洞	应具备对网站页面篡改、网站页面源代码暴露、穷举登录尝试、重放攻击、SQL注入、跨站脚本攻击、钓鱼、木马以及任意文件上传、下载等已知漏洞的防范能力。
四、技术使用安全
（一）安全性。
70	人工智能算法安全	避免人工智能算法目标函数定义错误，导致决策偏离预期甚至出现伤害性结果。
71		避免人工智能算法目标函数运算成本算法过高导致只能在实施层面采用偏离目标函数的手段，从而无法达到预期的效果或对周围环境造成不良影响。
72		避免采用表达能力有限的算法，导致算法在实际使用时面对不同于训练阶段的全新情况可能产生错误的结果。
73		避免应用于金融业务中的人工智能算法存在因设计者和开发者的主观选择造成的偏见的决策结果，保障用户的合法权益。
74		避免应用于金融业务中的人工智能算法存在因客观训练数据造成的偏见的决策结果，保障用户的合法权益。
75		避免算法非公开性、算法复杂性造成的决策结果不可解释问题。
76		避免含有噪声或偏差的训练数据影响算法模型准确性。
77		算法应具备抗逃避攻击能力，避免攻击者通过产生一些可以成功逃避安全系统检测的对抗样本，引导算法作出错误决策。
78		算法应具备抗模仿攻击能力，避免攻击者通过产生特定的对抗样本，使机器学习错误地将人类看起来差距很大的样本错分类为攻击者想要模仿的样本，从而达到获取受模仿者权限的目的。
79	人工智能安全管理	应当根据不同产品投资策略研发对应的人工智能算法或者程序化交易。
80		因算法同质化、编程设计错误、对数据利用深度不够等人工智能算法模型缺陷或者系统异常，导致羊群效应、影响金融市场稳定运行的，金融机构应当及时采取人工干预措施，强制调整或者终止人工智能业务。
81		应考虑人工智能算法存在不确定性，算法黑箱、同质化、模型缺陷等可能造成“算法共振”，引发顺周期高频交易，还可能带来潜在的道德风险。
82	人工智能风险控制	应充分提示人工智能算法的固有缺陷和使用风险，明晰交易流程，强化留痕管理。
83		应严格监控智能管理账户的交易头寸、风险限额、交易种类、价格权限等。
84		因违法违规或者管理不当造成客户损失的，应当依法承担损害赔偿责任。
85	大数据泄露风险高度集中	避免通过抢占入口和渠道，大量汇集信息流、资金流与产品流，成为“数据寡头”,使得信息泄露风险高度集中。
86	大数据数据治理	应根据数据完整性、保密性、可用性等安全属性遭到破坏后的影响对象和影响程度综合对数据进行分级。
87		应全面梳理并按年度或根据数据资源变化情况持续维护数据资源清单。
88		应依法合规开展数据采集工作，采取有效手段确保数据采集安全可靠，避免与履职无关的数据采集。
89		应采用加密、专线传输等手段，保障数据传输的保密性和完整性，防止数据在传输过程中被窃取、篡改、损毁等。
90		按照专事专用原则使用数据。在未经数据管理方批准下，不得直接或以改变数据形式等方式将数据提供给第三方，也不得用于或变相用于其他目的。
91		未经授权的数据禁止擅自留存，授权存储的数据应按照相关规定确定数据保存期限并做好安全防护措施。
92		对于超出数据保存期限的数据，应当及时删除和销毁。数据销毁应采用符合标准的设备和方法，确保数据无法还原。销毁过程应当履行清点、登记、审批等手续。
93	区块链基础环境安全	基础硬件和软件环境应遵循《信息安全技术网络安全等级保护基本要求》（GB/T 22239-2019）中三级及以上的物理安全、网络安全、主机安全、应用安全、数据安全及备份恢复相关要求。
94	区块链密码算法安全	分布式账本系统所使用的具体密码算法应符合密码相关国家标准、行业标准的有关要求，并应使用符合相关国家标准、行业标准的密码模块完成密码算法运算和密钥存储。
95	区块链节点通信安全	应对分布式账本系统采取授权准入的原则，在节点通信过程中应保证数据的完整性和保密性。应采用密码技术对节点通信双方的身份进行验证。
96	区块链账本数据安全	应对账本数据进行冗余，并确保账本数据不被未经授权方获取，保证账本数据的完整性、一致性和保密性。应对账本数据的访问提供安全审计功能。
97	区块链共识协议安全	应根据业务特点选用适宜的共识协议，包括但不限于工作量证明、权益证明、授权股权证明、拜占庭容错等，应满足不同共识协议安全运行所必需的前提要求，且业务激励规则和技术运维安全上的机制设计应保障其自身安全。
98	区块链智能合约安全	可支持非图灵完备智能合约和图灵完备智能合约，交易信息中应明确调用的智能合约版本。
99	区块链身份管理安全	应根据金融业务需求制定身份数据保密性要求，确保数据不暴露给未经授权方。监管信息应至少包括金融监管信息，具体为现工作单位/就读学校、行业类型、居住国家/地区、民族、居民/非居民、出生日期、个人月收入、税务信息等监管数据项和反洗钱特色数据项。
100	区块链安全运维与治理	应符合《信息安全技术网络安全等级保护基本要求》（GB/T 22239-2019）中安全管理制度、管理机构、人员安全、运维管理相关要求，同时还应包括设备管理、节点监控、节点版本升级、漏洞修复、备份与恢复、应急预案管理、权限管理、议案机制等功能。
101	物联网感知节点安全	应保证只有授权的感知节点可以接入。
102		应具有对其连接的网关节点设备（包括读卡器）和其他感知节点设备（包括路由节点）进行身份标识和鉴别的能力。
103		感知节点设备所处的物理环境应不对感知节点设备造成物理破坏，如挤压、强振动。
104		应能够限制与感知节点通信的目标地址，以避免对陌生地址的攻击行为。
105		感知节点应具备抗攻击能力。
106		应对感知节点设备入库、存储、部署、携带、维修、丢失和报废等过程作出明确规定，并进行全程管理。
107	物联网网关节点安全	应具备过滤非法节点和伪造节点所发送的数据的能力。
108		应能够限制与网关节点通信的目标地址，以避免对陌生地址的攻击行为。
109		应对网关节点设备入库、存储、部署、携带、维修、丢失和报废等过程作出明确规定，并进行全程管理。
110	物联网数据安全	是否能够鉴别数据的新鲜性，避免历史数据的重放攻击。
111	物联网数据安全	应对来自传感网的数据进行数据融合处理，使不同种类的数据可以在同一个平台被使用。
112	物联网连接安全	应保证感知节点与网关节点之间的连接安全。
（二）风险补偿。
113	风险拨备资金	应根据新技术与业务融合的潜在风险，制定风险拨备资金管理要求。
114	保险计划	应根据新技术与业务融合的潜在风险，完善保险计划。
115	保险计划	应具备先行赔付、保险补偿等保护金融消费者合法权益的具体措施。
116	应急处置	应根据新技术与业务融合的潜在风险，完善应急处置措施。
117	应急处置	应具备重大突发事件应急处置机制。
五、内控管理
118	战略规划	是否制定金融科技发展战略，结合市场需求及自身禀赋，明确金融科技发展方向、转变发展方式。
119	战略规划	是否制定自身金融科技应用的时间表和路线图，加强顶层设计与总体规划。
120	人才队伍	是否在年报及其他正式渠道中真实、准确、完整地披露科技人员数量与占比。
121	科技投入	是否在年报及其他正式渠道中真实、准确、完整地披露用于创新性研究与应用的科技投入情况。
122	内部审计	是否定期开展金融信息安全内部审计，防止金融信息被泄露和滥用。
123	外部评估	是否定期开展金融信息外部安全评估，并形成报告备查。

中国人民银行：开展金融科技应用风险专项摸排工作

参考资料：

相关推荐

亚马逊科技金融版图初现

珠海华润银行罗伶：构建银行金融科技系统，科技工作要一张蓝图绘到底

某上市公司全套内部控制手册（73份）

深度解析银行系金融科技子公司发展状况及趋势

科技新基建，关注云计算和信息安全

蚂蚁金服副总裁刘伟光：28页长文论述银行数字化转型的“是”与“不是”【附论文下载】