开放银行应用系统技术规范-征求意见稿

ICS

团体标准

CESA-2019-2-010

开放银行应用系统技术规范

征求意见稿

TechnicalspecificationforopenBankingapplicationsystem

在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。

2019--发布2019-XX-实施

中国电子工业标准化技术协会发布

CESA-2019-2-010

前言

本标准按照GBT1.1-2009《GBT1.1-2009标准化工作导则第1部分：标准的结构和编写》

给出的规则起草。

本标准由中国电子工业标准化技术协会提出。本标准

由中国电子工业标准化技术协会归口。

本标准起草单位：神州数码融信软件有限公司、南京银行股份有限公司、兰州银行股份有限

公司、广州银行股份有限公司、广东华兴银行股份有限公司、秦皇岛银行股份有限公司。

本标准主要起草人：

III

CESA-2019-2-010

引言

近年来，金融科技发展迅猛，引领金融业不断变革，催生出一系列新产品、新模式，开放式

银行是近年以来广受关注的金融科技新业态，是传统银行经营理念与战略思维的新升级。开放式

银行已成为全球银行业转型的新浪潮，国内有关银行都在探索开放银行。

开放银行在业内如火如荼发展的同时，业内也逐步认识到，我国的开放银行处于发展初期，

实践中存在标准规范不一、数据保护不足、数据安全防护薄弱等问题，而如何解决以上问题，确

定开放的界限，既需要监管层在顶层设计上制定相关标准，也需要银行自身进行资源整合，打破

条块化管理，建立数据安全保护机制，明确风险责任边界。

CESA-2019-2-010

开放银行应用系统技术规范

1范围

本标准提供了一个开放式银行应用系统建设的技术规范，规定了开放式银行应用系统各模块

应具备的能力和关键指标。

本标准适用于银行行业机构、相关金融行业机构、相关信息技术服务机构建设开放式银行应

用系统时使用。

行业其他相关机构可参照本标准进行开放式银行应用系统建设。

2规范性引用文件

本文件没有规范性引用文件。

3术语定义和缩略语

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

3.1术语和定义

3.1

网络安全networksecurity

通过采取必要措施，防范对网络的攻击、侵入、干扰、破坏和非法使用以及意外事故，使

网络处于稳定可靠运行的状态，以及保障网络数据的完整性、保密性、可用性的能力。

3.2

开放门户OpenPortal

开放门户也叫客户中心，是开放式银行对外提供开发者接入的门户网站。

3.3

开发者Developer

开发者是开放式银行系统的使用用户，使用开放式银行系统对外发布的服务进行自身应用

的开发。

1

CESA-2019-2-010

3.4

用户User

用户是指开发者的应用的使用者。

3.2缩略语

SDKSoftwareDevelopmentKit软件开发工具包是应用软

件开发时使用的开发工具的集合。APIApplication

ProgrammingInterface应用程序编程接口。

OCR识别OpticalCharacterRecognition

指电子设备（例如扫描仪或数码相机）检查纸上打印的字符，通过检测暗、亮的模式确定其

形状，然后用字符识别方法将形状翻译成计算机文字的过程。

4数据要求

4.1概述

数据展现、格式、定义、结构的共识。对通过API传输的数据（消息）语义、语法等进行了

统一，为整个开放式银行应用系统提供一种通用的交流语言。数据标准支持数据元素的一致性，

提高可信赖度同时也降低了成本。

4.2数据格式要求

数据传输格式应采用JSON报文格式。

4.3数据长度

单次数据传输长度应不大于20M。

4.4数据传输要求

数据传输应包括公共请求数据、业务数据、数字签名、加密KEY。

4.5数据结构要求

数据结构宜采用如下结构。

CESA-2019-2-010

表1数据结构表

英文名称中文名称类型是否必填说明

version版本号字符串是SDK版本号

appID接入标识字符串是第三方接入标识

SDKType接入方式字符串是JAVA；Android；IOS

reqTime请求时间字符串是YYYY-MM-ddHH:mm:ss

signType签名方式字符串是RSA默认

sign加密签名值字符串是RSA签名值

appAccessTokenToken字符串是认证通过的token

data加密后的业务内容字符串是不同业务接口的参数不同，以json的格式加密

后并base64编码

randomKey随机加密密钥字符串是使用银行端的公钥并通过非对称算法加密后并

base64编码

resourceID请求资源ID字符串是请求网关接口ID

5API/SDK

5.1API/SDK的发布

5.1.1概述

API/SDK发布应具备以下条件：

a)API/SDK经过渗透性安全测试和SDK安全加固；

b)API/SDK遵循数据安全传输规范以及其他安全规范；

c)API/SDK发布前具备相关测试报告，包括UAT测试报告和安全测试报告。

d)UAT测试报告应包括测试案例和测试结果，测试过程应由专业的测试人员进行测试。

e)安全测试报告应由有安全资质的第三方测试公司出具，测试过程应由第三方测试公司的

安全人员执行。

5.1.2API/SDK设计原则

移动端SDK的设计原则应分为没有集成控件的基础移动端SDK和在基础移动端SDK上额外集

成各种安全控件的扩展移动端SDK。例如，将发布集成了OCR识别、人脸识别、活体检测等控件

的扩展移动端SDK。

API的设计原则包括：

a)API的可复用性原则，API的划分应考虑多场景的复用;

b)API的可组合性原则，API的划分应考虑可以被组合为新服务场景;

c)API的完备性原则，API应具备完整的业务功能。

3

CESA-2019-2-010

5.1.3API/SDK开发原则

API/SDK开发应遵循以下原则：

a)API/SDK按照安全规范开发。

b)API/SDK开发应该关注业务流程，避免业务流程安全漏洞。

5.1.4API/SDK维护原则

API/SDK应定期进行优化和维护，通过监控API的使用情况，发现API的优化线索，一般包括：

a)API的响应时间是否达到设计要求；

b)API的调用成功率是否达到业务要求；

c)API的超时时间是否达到业务要求。

5.2API/SDK的使用

5.2.1概述

API/SDK使用时应保证使用者身份是经过认证、且避免不同身份的开发者共用一个接入密钥，

API/SDK使用应该明确身份，开放平台能够严格控制API/SDK使用者身份。

5.2.2API/SDK申请流程

开发者通过开放门户注册、实名认证后申请使用银行的产品服务。主要流程应包括：

a)开发者注册并登陆开放门户；

b)开发者类型应支持个人开发者和企业开发者；

c)银行运营人员审核开发者注册；

d)开发者创建应用，申请服务；

e)银行运营人员审核应用；

f)开发者发布应用，并在沙箱环境测试；

g)开发者应用上线，接入生产环境。

具体流程见下图：

CESA-2019-2-010

图1API/SDK申请流程

5.2.3开发者认证模式

.概述

开放式银行应用系统应支持基于OAuth2.0模式的集中管理授权和认证信息，当某个第三方应

用在使用银行的用户体系进行登录时，需要经过系统的安全模块，进行授权认证，获取临时code，

根据临时code获取token，并通过token交换用户信息，包括头像、昵称等信息。

.认证

开发者在开放门户上申请应用后，开放门户会为该应用生成appKey和appSecKey；开发者可

以在开放门户上进行API的申请，开放式银行系统后台会有相关的审核功能，审核通过后，该开

发者的所有审核通过的应用对这些API均有访问权限，该权限检验基于appKey完成。

开发者应用APP和银行开放平台的认证流程如下图：

5

CESA-2019-2-010

图2应用授权认证流程

在用户发起API请求时，应有如下权限认证：

a)认证appKey的所属开发者是否经过了实名认证和用户签约；

b)认证appKey所对应的应用是否经过了审核；

c)认证appKey所对应的token是否准确，并处于有效期内；

d)认证appKey所对应的开发者，对该API是否具有访问权限。

6安全技术

6.1网络安全

建立安全的网络与内容交换的通道，应包括：

a)网络防火墙：宜采用双层网络防火墙进行保护，分别是互联网区和DMZ区设置一道防火

墙，DMZ区和应用区设置一道防火墙，设置防火墙网络安全策略，确保网络流量的合法

性；

b)网络隔离区：宜使用DMZ网络隔离区，设立一个非安全系统与安全系统之间的缓冲区，

有效保护内部网络区域的应用安全；

c)网络安全设备：借助SSL加速器和防火墙等网络安全设备实现SSL加速、应用攻击过滤

以及拒绝服务(DoS)攻击等安全防御功能；

d)转发代理：基于资源访问路径的负载路由，可以选择性的将内网应用的接口对外进行发

暴露。

CESA-2019-2-010

6.2应用安全

应用系统应提高应用的安全开发设计能力，提升开放式银行应用安全架构能力，在系统架构层

面防护大部分攻击行为，并经严格的代码审核，保证产品的安全性。应用安全主要包括：

a)权限控制，应针对不同的平台用户设定不同的角色和权限，不同的平台用户登录展示不

同的菜单内容；

b)身份验证识别，开放门户应支持身份验证识别；

c)口令加密，应提供加密控件的登录方式，严格保护开发者的密码，防止泄露；

d)登录超时控制，开发者登录开放门户30min内无操作，系统应强制开发者退出，终端用

户会话保持，当开发者再次使用的时候，需要重新登录。

6.3数据安全

6.3.1加签验签

对应用系统的数据请求应经过加密和加签处理，以验证数据是否被篡改，并防止数据被拦截泄

露。通过数字签名技术，可以有效防止数据被非法访问、篡改、丢失。

6.3.2加密解密

应用系统应具备完善的数据加密及传输加密机制，整个系统数据传输的各个环节无明文数据。

为了防止数据在传输过程中被拦截获取，应用系统应提供数据的加密规则和算法。

6.3.3数据脱敏

应用系统与第三方平台在进行数据交互时，涉及到企业内部用户隐私数据的请求，应采用数据

脱敏和脱敏还原机制，保障用户的个人信息安全不被泄露；

脱敏还原方法应采用把需脱敏数据进行加密或者移位置换后加密的方法实现，保证脱敏算法不

被泄露，加密应采用国密算法或者行政主管部门要求的加密处理方法。

6.4业务安全

建立智能风控体系，加强银行合规监管能力。根据合作企业建立准入准出机制防范风险。针对

银行业务流程，业务安全包括：

1)电子账户管理，应遵询行政主管部门对二三类账户的使用和管理要求；

2)交易风险控制，应对各渠道发送的交易进行风险控制；

7

CESA-2019-2-010

3)业务风险监控，应对不同业务建立风控模型，降低业务风险。

7系统功能架构

7.1整体架构

系统由若干功能组件构成，系统功能架构见图3：

图3系统功能架构

7.2客户中心

客户中心应支持在IE11、Firefox、GoogleChrome等主流浏览器上稳定运行，并支持向下兼

容。采用前后端分离开发模式和部署架构，后端支持SpringBoot，前端支持动态编译技术。

客户中心主要用户对象是个人开发者或者合作商户，主要包含开发者相关信息维护、SDK及

其说明、开发者集成流程及指引、产品信息展示、广告和新闻发布、业务场景介绍、金融产品发

布、知识库等内容。向开发者展示产品、业务场景、提供SDK下载功能、产品说明文档展示等。

开发者社区支持合作方完成用户注册、应用创建、产品申请，支持产品业务交易数据统计、业务

订单查询、对账文件下载、开放平台SDK下载、产品API文档查看等功能。

客户中心应提供一系列文档、场景、工具的使用手册，帮助开发者快速熟悉API功能和使用

方法，并提供注册和申请的流程。

7.3API接入网关

API接入网关是开放式银行应用系统中最核心最基础的运行态功能实现平台。应支持方便整

合开源框架。主要包含服务发布、协议转换、安全控制、报文转换、服务路由等技术集成功能，

为API的调度提供安全、稳定、可靠的运行环境。

CESA-2019-2-010

7.4API接出网关

API接出网关应包含两方面功能，首先是用于整合外部合作企业的服务，如整合行外支付宝、

微信支付、QQ钱包等第三方服务完善产品功能；其次是用于行内系统通知第三方企业，具体业务

有异步服务处理完成后通知合作用户结果、以及其他主动通知交易。

API接出网关应支持协议与网络地址的适配和转义功能，支持服务的异步回调通知功能，支持

异常网络请求的记录与处理功能，API接出网关应用可与API接入网关功能一致。

7.5Web服务

Web服务支持加载发布H5静态资源，应提供分目录、分资源进行动态加载，并且实时生效的

功能。

7.6API安全中心

API安全中心应为金融服务业务的发布、开放、运行提供一整套安全解决方案。包括安全管理

控制台功能、APP安全控制功能、OAuth2.0功能、限流管理功能、安全数据服务功能。

a)安全管理控制台功能应包括

1)证书管理,提供证书的生成、存储、下发、更新、上传；

2)秘钥管理,秘钥的上传、生成、重置；

3)开发者权限管理,提供开发者的权限控制管理。

b)APP安全控制功能应包括

1)SDK授权认证,提供SDK的授权认证；

2)SDK信息管理,提供SDK签名、版本管理。

c)OAuth2.0功能应包括

1)授权码,提供授权码的获取和超时管理；

2)token管理,提供token的生成、存储、更新管理；

3)授权,提供基于token的授权管理；

4)认证,提供基于token的认证管理。

d)限流管理功能应包括

1)维度控制,提供多维度的限流维度；

2)令牌管理,提供灵活的令牌管理体系；

3)统计分析,提供在线实施统计分析功能；

4)参数调整,提供在线参数调整并实时生效。

9

CESA-2019-2-010

e)安全数据服务功能应包括

1)国密算法加解密,提供基于国密算法的加密解密；

2)数字信封加解密,提供基于数字信封的加密解密；

3)MD5加签验签,提供基于MD5算法的加签验签；

4)RSA加签验签,提供基于RSA算法的加签验签；

5)HMAC_SHA1加签验签,提供基于HMAC_SHA1算法的加签验签；

6)数据脱敏,提供敏感数据的脱敏传输；

7)数据还原,提供敏感数据的脱敏还原。

7.7运营中心

运营中心应为银行运营人员提供了图像友好、操作便捷、功能强大的管理控制台，并提供了权

限管理功能；基于该平台，运营人员可以对开发者进行身份校验审核、创建应用审核、证书审核、

申请服务调用审核、合作方回调地址审核管理、用户冻结和解冻管理、应用参数管理等功能，对

参数的调整以及动态信息的实时发布、权限管理、日志审计等；并提供了报表分析功能和管理认证

功能。

7.8API治理平台

API治理平台是基于元数据的服务定义、描述、映射、检索治理系统。以提升组织业务能力

为导向的工具。API治理就是一种对所有现有以及将来新增服务所进行的整理、归纳、定义、组

装的方法，并在开发、运行的规范上进行正向引导的一种组织行为。

API治理平台应包括API的定义、发布、审批，对API生命周期的管理、对元数据的管理，应

与客户中心（开发者门户）联动，API治理正式发布的服务可以通过开发者门户进行查询。

7.9API监控平台

API监控平台应对应用系统的资源、应用服务器、数据库服务器、系统运行、服务和产品运

行、业务系统、合作商户进行监控，并提供报表查询和下载。API监控平台监控和提供的内容应

包括：

a)API监控平台应提供系统资源运行情况。

b)API监控平台应提供服务运行监控功能情况。

c)API监控平台应提供各时段服务运行情况的统计报表。

d)API调用流水查询功能包括对所有API网关进行的交易流水进行查询，支持多种查询条

件，如流水号、时间段、时间点、交易状态、交易返回码等。

CESA-2019-2-010

e)支持图形、邮件、短信的告警功能，并支持告警阈值的自定义设置。

7.10API组合

为了进一步整合银行内部资源、减少银行内外的交互次数、提高交互效率，系统应对原始服务

（接口）进行一定程度的组合。应用系统宜支持多种API的组合方式，典型的类型如下：

1)串行组合：成员服务顺序执行；

2)并行组合：成员服务并发执行；

3)服务分发：成员服务根据条件选择执行，多个成员服务选择其中一个执行；

4)条件组合：成员服务根据条件选择执行，多个成员服务可能执行、不执行、执行一部分；

5)并行转串行：两个（或多个）的成员服务存在依赖关系，在不同时参与组合时，可以与

其他成员服务并行执行；但是这两个（或多个）成员服务，同时参与组合时，顺序执行；

6)业务数据查询补填：成员服务的执行需要依赖于其他查询类成员服务的结果；

7)批量转单笔多次：存在依赖关系的成员服务之间，一个是多条数据一次发送，一个一次

仅能处理单条数据；

8)自动冲正：成员服务应搭配相应的冲正服务，有组合服务在异常时调用，保障数据一致

性；

9)存储转发，定时调用：需要存储相关数据，定时调用成员服务。

7.11工具集

开放式银行应用系统在建设过程中，提供配套能够解决系统快速开发，快速集成的管理工具集。

工具集宜包括下列内容：

1)挡板,提供高性能、配置化的挡板供测试使用；

2)发送报文模拟器,提供可以在线测试的发送报文模拟器；

3)回归测试工具,支持在准备好测试报文的情况，通过工具进行自动化测试。支持单个服

务和多个服务的自动化测试。此工具作为开发工具插件，可用来进行回归测试；

4)集成开发平台IDE,提供用于敏捷开发的开发平台IDE；

5)自动化部署工具,提供在线版本发布与部署功能，保证在集群部署的架构模式下，简化

版本部署流程，提升版本部署效率；

6)沙箱环境,沙箱环境提供合作伙伴接入前的联调测试，沙箱环境测试通过后接入正式生

产环境。

11

CESA-2019-2-010

8应用集成技术

8.1API架构风格

API应遵循开放简洁的设计风格，体现出面向资源、面向服务的思想。示例：如使

用RESTFul风格

8.2SDK集成技术

SDK的设计则主要基于HTTPS通讯协议，将通讯、安全、页面以及API等融为一体提供给客

户，大大减轻了客户的开发难度，提高了接入效率。

SDK包应提供在不同操作系统和使用条件下的对应安装包，包括Android-SDK、iOS-SDK、H5-

SDK。

8.3数据描述记录规则

系统应制定通俗易懂、统一规范的API、SDK、元数据命名规则，便于开发者理解使用相关资

源

8.4版本管理技术

系统应采用灰度发布管理模式，提供API的多版本共存的能力，支撑特殊情况的平滑过渡。

8.5API/SDK使用流程

第三方合作者在使用API/SDK之前需要在客户中心完成一系列的申请验证工作，以保障

API/SDK能得到合法合理高效的使用。系统应使用BPM工作流引擎等完成多级审批配置，实现流

程管理。

8.6沙箱技术

使用沙箱为第三方合作者提供沙箱测试环境，提升第三方开发者的使用体验，保障正式环境

的稳定可靠

8.7API网关

主要包含服务发布、协议转换、安全控制、报文转换、服务路由等技术集成功能，为API的

CESA-2019-2-010

调度提供安全、稳定、可靠的运行环境。

8.8API治理

通过API治理平台应有效的对业务服务、接口、元数据等进行管理和控制，使用自动化导入

功能，可以对API进行导入导出，避免了重复的冗余的工作，同时还能将整合后的API下发到

API网关运行态，使得服务的治理、导入、下发一体化、自动化。

9安全管控技术

9.1网络安全

9.1.1DMZ网络隔离区

使用DMZ网络隔离区，设立一个非安全系统与安全系统之间的缓冲区，有效保护内部网络区

域的应用安全。

9.1.2双层防火墙

采用双层网络防火墙进行保护，分别是互联网区和DMZ区设置一道防火墙，DMZ区和应用区设置

一道防火墙，设置防火墙网络安全策略，确保网络流量的合法性。

9.1.3路由负载

开放银行应提供基于资源访问路径的路由和负载均衡，可以选择性的将内网应用的接口对外

进行发暴露。

9.1.4攻击防御

开放银行应借助SSL加速器和防火墙等网络安全设备实现SSL加速、应用攻击过滤以及拒绝

服务(DoS)攻击等安全防御功能。

9.1.5HTTPS

应用系统对外通讯协议应统一采用HTTPS协议，使用HTTPS链路加密的通讯模式，保证链路

安全，支持单向认证，双向认证。

13

CESA-2019-2-010

9.3数据安全

9.2.1故障隔离

故障隔离是当发生故障的时候，可以无损隔离，不影响其他交易正常处理；故障隔离应支持分

路隔离、第三方隔离、服务隔离、服务系统隔离。

a)分路隔离是指系统在多路部署的情况下，当其中某一分路发生故障或者需要重启的时候，

可以对该分路进行隔离，隔离不影响其他交易；

b)第三方隔离是指可以对服务请求方进行隔离，一般隔离的维度是在APP维度将某一个接

入的应用进行隔离；

c)服务隔离是在API和产品维度，针对某一个服务接口或是服务产品进行隔离；

d)服务系统隔离是在服务提供系统维度，针对某一个服务提供系统进行隔离。

9.2.2流量控制

流量控制是指在单位时间内对系统内正在处理的交易量做出控制，避免系统接收超出自身处

理极限的交易请求，而造成系统严重负载，甚至崩溃、瘫痪等严重事故。流量控制应提供多维度

控制，应包括下列维度：

a)开放式银行的总流量控制。

b)第三方开发者流量控制，针对某一个第三方APP的接入的并发数和调用频度控制。

c)服务流量控制，指针对某一个API接口接出调用的并发数和调用频度。

d)服务系统流量控制，指针对某一个服务提供系统接出调用的并发数和调用频度。

9.2.3服务降级

API监控过程中，应对服务质量较低的API进行服务降级。在一段时间内判断服务的处理成功

率，并给予降级或回复。此时间段应可配置。

9.2.4动态扩容

API监控过程中，可以动态增加系统处理能力，增加部署资源，以应对API的高峰使用。

9.2.5服务熔断

API监控过程中，当后台API提供者的成功率达到临界阈值以下时，根据配置规则应启动熔断

机制，自动隔离该服务，避免扩大影响范围。

CESA-2019-2-010

9.2系统安全

9.3.1数据加密解密

数据加密解密方法应选用国际算法或国密算法，例如AES和SM4算法。

9.3.2数据加签验签

数据加签验签方法应选用国际算法或国密算法，例如RSA和SM2算法。

9.3.3数据脱敏还原脱敏还原

的数据应包括：

a)手机号；

b)身份证号码；

c)银行卡号。数据脱敏

处理过程如下图：

互联网应用互联网开放平台行内系统

API请求脱敏还原API请求

API请求脱敏处理API请求

图4数据脱敏处理

互联网请求的数据应做脱敏还原，保证银行内部应用系统拿到的数据是真实有效的用户数据；行

内系统返回的数据应做脱敏处理，保证返回的数据都是经过脱敏处理后的密文信息，避免银行客户信

息的泄露。

9.4业务安全

9.4.1身份核验

系统应对接入的第三方应进行身份核验，包括接入申请阶段业务上的核验以及API调用阶段基于

OAuth2.0、Token的身份认证。

15

CESA-2019-2-010

9.3数据安全

系统应提供基于APPKEY的服务访问权限控制。

9.4.3用户数据授权系统应支持运营人员对不同用户访问的数据进行控制。当设置为不可见时，当用户

访问该数据时，

则不显示。

10Web技术

10.1前后端分离技术

系统应使用前后端分离技术。通过前后端分离设计,实现了前端与后端的解耦，提高了前端的灵活性

和后端的稳定性。

10.2前端框架技术

系统前端框架宜采用HTML5成熟的框架技术。

CESA-2019-2-010

目次

前言..................................................................................................................................................................III

引言.................................................................................................................................................................IV

1范围...............................................................................................................................................................1

2规范性引用文件...........................................................................................................................................1

3术语定义和缩略语.............................................................................................................................................1

3.1术语和定义..................................................................................................................................1

3.2缩略语..........................................................................................................................................2

4数据...............................................................................................................................................................2

4.1概述..............................................................................................................................................2

4.2数据格式......................................................................................................................................2

4.3数据长度......................................................................................................................................2

4.4数据定义......................................................................................................................................2

4.5数据结构......................................................................................................................................2

5API/SDK.......................................................................................................................................................3

5.1API/SDK的发布..........................................................................................................................3

5.1.1概述......................................................................................................................................3

5.1.2API/SDK设计原则.....................................................................................................................3

5.1.3API/SDK开发原则.....................................................................................................................4

5.1.4API/SDK维护原则.....................................................................................................................4

5.2API/SDK的使用..........................................................................................................................4

5.2.1概述......................................................................................................................................4

5.2.2API/SDK申请流程.....................................................................................................................4

5.2.3开发者认证模式..................................................................................................................5

.概述...............................................................................................................................5

.认证...............................................................................................................................5

6安全技术.......................................................................................................................................................6

6.1网络安全......................................................................................................................................6

6.2应用安全......................................................................................................................................7

6.3数据安全......................................................................................................................................7

6.3.1加签验签..............................................................................................................................7

6.3.2加密解密..............................................................................................................................7

6.3.3数据脱敏..............................................................................................................................7

6.4业务安全......................................................................................................................................7

7系统功能架构...............................................................................................................................................8

7.1整体架构......................................................................................................................................8

7.2客户中心......................................................................................................................................8

7.3API接入网关......................................................................................................................................8

7.4API接出网关......................................................................................................................................9

7.5Web服务..............................................................................................................................................9

7.6API安全中心......................................................................................................................................9

7.7运营中心....................................................................................................................................10

7.8API治理平台....................................................................................................................................10

7.9API监控平台....................................................................................................................................10

7.10API组合............................................................................................................................................11

7.11工具集........................................................................................................................................11

8应用集成技术.............................................................................................................................................12

8.1API架构风格.....................................................................