本行应用程序接口服务的参与方主要包括用户、应用方以及本行，本行通过 API 直接连接或 SDK 间接连接方式向应用方和用户提供应用程序接口服务，实现本行服务的对外输出。用户发起本行应用程序接口应用请求，并接收由应用方或本行返回的处理结果。应用方负责接收并处理用户请求，通过应用程序接口向本行提交相关请求、接收返回结果，依照流程进行服务请求处理或反馈用户。

6　接口类型与安全级别

6.1　接口类型

本行应用程序接口按照应用集成方式，分为服务端对服务端集成方式与移动终端对服务端集成方式两种。

对于服务端对服务端集成方式，主要包含两种实现形式：

——应用方服务端直接调用本行应用程序接口（如 REST、SOAP 协议）。

——应用方服务端使用本行提供的服务端 SDK，间接访问本行应用程序接口。

其中，服务端 SDK 主要实现本行通用接入算法的封装，为降低应用方接入开发难度，一般此类SDK 不包含业务逻辑。

对于移动终端对服务端集成方式，主要包含两种实现形式：

——应用方移动终端应用软件直接调用本行应用程序接口。

——应用方移动终端应用软件使用本行提供的移动终端应用 SDK，间接访问本行应用程序接口。

其中，应用方移动终端应用软件直接调用本行应用程序接口的方式，主要以与用户个体无直接关联的金融服务为主，如提供本行公开信息查询、公开服务查询等。

移动终端应用SDK 除封装本行通用接入算法外，还可封装业务逻辑、个人金融信息安全保护（例如密码数据的安全加固）等功能。

在移动终端对服务端模式下，对于仅使用 H5（超文本标记语言版本 5.0）技术，提供银行金融产品和服务访问链接的情况，由于 H5 页面本身并未直接调用（或封装）本行应用程序接口，不将其单独列为本行应用程序接口的一种类型。

6.2　安全级别

按照服务类型将本行应用程序接口安全级别划分为两级，安全保护要求从 A2 至 A1 递减：

——A2：资金交易与账户信息查询应用类，此类金融产品和服务与用户个体直接关联，实施高等级安全保护强度。

对于上述服务，若确需使用 API 直接连接方式进行服务调用，本行应对接入风险进行评估，并制定专门的接口与应用方进行对接，实施高等级的安全保护强度要求。

——A1：金融产品和服务信息查询应用类，此类金融产品和服务与用户个体并无直接关联，实施通用的安全保护强度，此类本行应用程序接口包括但不限于：本行提供银行金融产品和服务的详细信息的“只读”查询服务。

7　安全设计

7.1　设计基本要求

本行应用程序接口安全设计基本要求如下：

——使用的密码算法、技术及产品应符合国家密码管理部门及行业主管部门要求。

——应制定安全编码规范。

——应对开发人员进行安全编码培训，并依照安全编码规范进行开发。

——开发中如需使用第三方应用组件，应对组件进行安全性验证，并持续关注相关平台的信息披露和更新情况，适时更新相关组件。

——应对本行应用程序接口进行代码安全专项审计，审计工作可通过人工或工具自动化方式开展。

——应制定源代码和本行应用程序接口版本管理与控制规程，规范源代码和本行应用程序接口版本管理，并就接口废止、变更等情况与应用方保持信息同步。

——本行向应用方提供的异常与调试信息，不应泄漏服务器、中间件、数据库等软硬件信息或内部网络信息。

7.2　接口安全设计

7.2.1　身份认证安全

a) 接口身份认证安全要求如下：

1) 对于应用方身份认证应使用的验证要素包括：

——App_ID、App_Secret。

——App_ID、数字证书。

——App_ID、公私钥对。

——上述三种方案的组合。

2) 对于 A2 级别接口、应用方身份认证时，应使用包含数字证书或公私钥对的方式进行双向身份认证。

b) 用户身份认证安全要求如下：

1) 本行应结合金融服务场景，对不同安全级别的本行应用程序接口设计不同级别的用户身份认证机制。

2) 用户身份认证应在本行执行，对于 A2 级别接口中的资金交易类服务，用户登录身份认证应至少使用双因子认证的方式来保护账户财产安全。

7.2.2　接口交互安全

本行应用程序接口交互安全要求如下：

——本行应用程序接口应对连通有效性进行验证，如接口版本、参数格式等要素是否与平台设计保持一致。

——应对通过本行应用程序接口进行交互的数据进行完整性保护，对于 A2 级别的接口，本行和应用方应使用数字签名来保证数据的完整性和不可抵赖性。

——对于支付敏感信息等个人金融信息，应采取以下措施进行安全交互：

登录口令、支付密码等支付敏感信息在数据交互过程中应使用包括但不限于替换输入框原文、自定义软键盘、防键盘窃听、防截屏等安全防护措施，保证无法获取支付敏感信息明文；

账号、卡号、卡有效期、姓名、证件号码、手机号码等个人金融信息在传输过程中应使用集成在 SDK 中的加密组件进行加密，或对相关报文进行整体加密处理；若确需使用本行应用程序接口将账号、卡号、姓名向应用方进行反馈，应脱敏或去标识化处理，因清分与清算、差错对账等需求，确需将卡号等支付账号传输至应用方时，应使用加密通道进行传输，并采取措施保证信息的完整性；

对于金融产品持有份额、用户积分等 A2 类只读信息查询，可使用 API 直接连接方式进行查询请求对接，应采取加密等措施保证查询信息的完整性与保密性，查询结果在应用方本地不得保存。

——应在交易认证结束后及时清除用户支付敏感信息，防范攻击者通过读取临时文件、内存数据等方式获得全部或部分用户信息。

7.3　服务安全设计

7.3.1　授权管理

本行应根据不同应用方的服务需求，按照最小授权原则，对其相应接口权限进行授权管理，当服务需求变更时，需及时评估和调整接口权限。

7.3.2　攻击防护

服务安全设计应具备以下攻击防护能力：

——API 和 SDK 应对常见的网络攻击具有安全防护能力。

——移动终端应用SDK 应具备静态逆向分析防护能力，防范攻击者通过静态反汇编、字符串分析、导入导出函数识别、配置文件分析等手段获得有关 SDK 实现方式的技术细节。

——移动终端应用SDK 宜具备动态调试防护能力，包括但不限于：具有防范攻击者通过挂接动态调试器、动态跟踪程序的方式控制程序行为的能力；具有防范攻击者通过篡改文件、动态修改内存代码等方式控制程序行为的能力。

8　安全部署

本行与应用方应遵循本行应用程序接口网络部署逻辑结构示意图，见图2，进行本行应用程序接口的安全部署。本行及应用方都应在互联网边界部署如防火墙、IDS/IPS、DDoS防护等具备访问控制、入侵防范相关安全防护能力的网络安全防护措施。

本行应用程序接口服务层应部署流量控制、监控分析、认证鉴权、报文交换、服务组合等服务，其中认证鉴权、报文交换、服务组合等服务也可部署在银行业务层。本行应用程序接口服务层与银行业务层之间应部署如防火墙等具备相关访问控制、入侵防范安全防护能力的网络安全防护措施。

应用方服务器应部署在应用方互联网接入安全防护设备之后的逻辑隔离区域，通过互联网、移动互联网网络访问本行应用程序接口相关应用服务。

本行的安全控制要求依据 JR/T 0071 部署相应级别的安全控制措施。应用方部署本行应用程序接口有关安全控制措施，应符合国家网络安全等级保护有关标准二级及以上安全要求。

9　安全运维

9.1　安全监测

9.1.1　运维监测

运维监测的要求如下：

——本行应建立本行应用程序接口运维监测平台，或将本行应用程序接口运维监测纳入本行统一监测平台并重点监测。

——运维监测应具备以下监测能力：

监控本行应用程序接口相关服务器运行状态并建立告警机制；

监控本行应用程序接口服务状态（包括耗时、交易量、成功率等参数）并建立告警机制；

本行交易日志应按照国家会计准则要求予以保存，系统日志保存期限不少于 1 年。

——应用方应对其集成本行应用程序接口运行状态进行监测，发现异常应及时处置。

9.1.2　异常监测

异常监测的要求如下：

——本行应具备流量监控、故障隔离、黑名单控制等本行应用程序接口调用控制能力：

应具备本行应用程序接口调用流量控制能力，控制规则包括最大允许本行应用程序接口调用并发数、单位时间最大交易调用量等，控制措施包括告警、暂停、拒绝等；

应建立未授权和冒用本行应用程序接口的监测机制，发现问题及时处置；

应具备故障监测和恢复能力；

应具备应用方黑名单管理能力。

——应用方应具备故障识别与隔离能力：

调用本行应用程序接口应设计熔断机制，熔断规则包括设置失败笔数阈值、本行应用程序接口调用失败阈值等，熔断措施包括拒绝交易、暂停服务调用等；

调用本行应用程序接口应建立异常告警处理机制。

9.2　风险控制

9.2.1　服务风险控制

本行实施服务风险控制的要求如下：

——应建立应用方信息（如运营能力、风控能力等）更新和复审机制。

——应根据应用方调用本行应用程序接口的业务日志等信息，定期评估其金融交易业务的运营情况，并在协议框架内对异常的业务调用进行监控，必要时进行业务限流，并及时通知应用方进行事件调查。

——应评估应用方的风险承受能力，确保用户与应用方相关的账户关联、服务类型、交易额度等与其风险承受能力相匹配。

9.2.2　交易流程控制

交易流程控制的要求如下：

——身份认证服务等授权类服务应充分识别是否经过用户本人授权。

——账户查询、资金交易、金融产品及服务申请类交易，应充分识别交易是否由用户本人发起（或本人授权发起），核实用户本人意愿。

——资金类等高风险金融服务，应提示用户相关的安全风险，充分履行用户告知义务。

9.2.3　交易风险监控

本行交易风险监控的要求如下：

——应将本行应用程序接口纳入银行风险监控范围，对应用方和用户账户资金活动情况进行实时监控。

——资金交易应满足行业监管部门对反洗钱、反欺诈方面的相关要求。

——对大额、异常的资金收付应逐笔监测与核查，及时预警、及时控制。

——对监控到的风险交易应进行及时分析与处置。

9.3　变更控制

接口变更的要求如下：

——本行应用程序接口发生变更时，应及时评估影响并告知应用方，制定变更方案和应急预案，按需进行接口变更发布，并充分履行用户告知义务。

——应用方对本行应用程序接口的使用发生重大变更时，如其交易量预期发生变化、对本行应用程序接口集成方案进行修改等可能对本行系统安全性、业务连续性等造成重大影响的有关事项，应制定变更方案和应急预案，评估变更带来的风险，并及时告知本行，同时充分履行用户告知义务。

——应用方使用本行应用程序接口发生重大变更时，本行应对其变更进行风险和影响评估，并采取相应的处置措施。

9.4　运维巡检

本行应定期对本行应用程序接口进行安全巡检，包括：

——应对本行应用程序接口进行源代码安全审计、渗透测试等技术检查，及时处理安全漏洞，有效控制安全风险。

——应对应用方的本行应用程序接口安全集成情况进行检查。

应用方应定期对本行应用程序接口进行安全巡检，包括：应定期对其调用本行应用程序接口的应用系统进行安全评估，及时处理安全漏洞，确保调用的真实有效。

9.5　事件处理

本行应制定应急处理方案，对运维过程中监测到的异常情况及时告警和处置，及时处理生产事件，并协调应用方配合事件调查。

10　服务终止与系统下线

本行应制定完善的服务终止和系统（接口）下线的相关制度和步骤，以便各参与方有序处理相关服务：

——服务终止前，本行应将服务终止有关事项提前告知相关方，并向相关平台提交有关接口的统一识别码注销申请。

——本行应与应用方就服务终止后相关数据归档、数据删除（或销毁）、个人金融信息保护、用户资金和账户安全、消费者权益保护等问题充分达成一致，明确相关责任，并充分履行用户告知义务。

——系统（接口）下线应在相关服务确认终止之后执行，在下线之前应设置挡板（如服务终止提示信息），明示应用方服务已终止。

——本行在系统（接口）下线之后应将有关数据进行归档处理，数据保留期限应按照国家与行业主管部门、本行相关规定与规则执行。

11　安全管理

11.1　管理制度

本行管理制度要求如下：

——应将本行应用程序接口的管理纳入本行现行管理体系中，对本行应用程序接口进行全生命周期的安全管理。

——应用程序接口应采用统一格式的识别码，并在相关平台进行注册和登记，编码规则详见附录 B。

——应建立信息公告制度，通过官方网站等公开渠道发布其本行应用程序接口内容，并及时更新。

——应建立覆盖本行应用程序接口全生命周期的应用安全管理制度与控制措施，并对管理制度与控制措施的有效性进行验证，以确保本行应用程序接口的一致性和连贯性，保障本行应用程序接口效率及安全性。

——应提供开发手册以指导应用方安全集成本行应用程序接口，开发手册包括但不限于安全集成要求、集成示例，以及测试环境的使用等。

11.2　应用安全责任

本行与应用方应以合同或协议的方式，明确规定本行应用程序接口的信息安全与金融消费者数据保护等方面的安全责任，包括但不限于：

——应用方若出于自身服务需求收集金融消费者个人金融信息，应：

直接获得金融消费者的明示同意，并依据最少够用原则进行信息收集，不应以使用本行应用程序接口为理由不履行明示同意等个人金融信息保护义务；

向金融消费者说明个人信息收集方并非本行，也与本行服务无关。

——明确本行与应用方的信息安全责任。

——应用方不应将通过本行应用程序接口获得的金融服务能力与数据以任何方式转移、共享或分包给其他第三方。

——无论合作关系是否续存，应用方应依据与本行的协议约定，履行用户信息保密责任。