电子银行业务场景及系统架构

电子银行业务是指商业银行等银行业金融机构利用面向社会公众开放的通信通道或开放型公众网络，以及银行为特定自助服务设施或客户建立的专用网络，向客户提供的银行金融服务，主要包括网上银行、电话银行、手机银行、短信银行等。

1.电子银行服务分层设计

近年来，与互联网有关的业务创新和技术创新层出不穷，其应用的触角已深入日常生活的各个领域。面对互联网大潮，无论是坦然面对还是惶惶不安，来自互联网金融的变化和对传统银行业务的冲击，让人震撼。在这个不同以往、时刻变革的时代，国内商业银行选择了拥抱变化、推陈出新，主动去融合互联网基因。传统的电子银行业务因而发生了巨变。在此背景下，国内商业银行不再局限于为客户提供传统的金融服务，开始主动出击。移动终端、客户联络中心、即时通信、电子商务，在互联网金融“渠道为王”、“客户体验至上”的一片喧嚣声中扑面而来。频繁的业务和产品创新为商业银行带来了新的活力，但同时也给电子银行信息系统研发带来了沉重的压力。因而，与银行其他信息系统相比较，为了应对互联网金融和银行间日益激烈的竞争，电子银行信息系统更加强调系统架构的灵活性，强调程序的复用性和系统的安全性。

电子银行领域中，网上银行、手机银行等渠道，服务模式相似度较高，在提供同一产品服务时，关键业务逻辑和目标基本一致，差异主要体现在于不同渠道的UI交互体验的不同。因而电子银行信息系统程序的高度复用成为可能。例如，经分析，PAD版网上银行与PC版网上银行关键业务逻辑基本一致，程序代码相似度大于80%。

按照银行企业架构通用参考模型，电子银行信息系统位于应用架构的渠道接入层。渠道接入层主要具备两项能力，一是作为客户与银行的接触点，整合各渠道提供标准化接入手段。实现渠道接入、界面展现、会话管理等功能；二是统一渠道服务能力，处理来自不同渠道的服务申请，封装和调用银行后台信息系统提供的服务，如图3-24所示。

对于不同的系统处理能力，按照关注点分离设计原则。可以剥离渠道控制和客户服务功能，分层构建电子银行信息系统以提高系统的灵活性。其中，渠道控制层主要负责会话管理、网络安全控制、交易安全验证、交易流量控制等公共服务，不提供与产品处理相关的具体业务逻辑处理功能。而客户服务层主要负责业务逻辑的处理，由流程定义、业务构件和渠道个性化服务组成。

渠道控制层，在客户交易申请提交业务处理前，完成渠道会话检查与更新、渠道安全控制、渠道信息检查、渠道风险上报等渠道控制和渠道管理的逻辑处理。基于渠道的不同差异，渠道控制层可根据实际需要分为渠道共性处理和渠道个性处理等组件。渠道共性组件多渠道部署，渠道个性组件按渠道实际情况差异部署。渠道控制分层和差异化设计，可以较好地支持渠道横向扩展。当新增渠道或渠道控制规则调整时，只需要对该层渠道共性组件配置调整或新增个性渠道组件配置，即可实现对渠道控制和管理的支持。

对于跨渠道互联互通，根据实际业务需要，可以考虑在渠道控制层与客户服务层之间是否建立渠道整合层，完成跨渠道信息的存储、访问与处理。

客户服务层，抽取渠道和终端的公共处理逻辑，调用和封装后台应用暴露的服务，形成共性客户服务。差异化处理可以考虑多种实现模式。例如，形成差异化业务构件，配置实现不同渠道的差异化业务处理步骤。或者，单独剥离在渠道个性化处理组件中实现。通过流程整合和流程定义，组合多个客户服务和业务构件形成完整的电子银行业务处理流程服务。

图3-24 电子银行架构

2.电子银行安全

随着互联网业的蓬勃发展，数据安全和客户的身份认证已经越来越重要。在不同网络安全环境下，电子银行系统需采用差别化的风险模型和策略。

电子银行业务场景主要包括注册、登录、支付、协议签订、信息修改、信息查询、特殊交易等。其中，支付又可根据额度细分，其风险根据数额逐级上升。需注意的是，风险模型越复杂，能够区别对待的交易类型、风险级别越多，网银系统也就复杂，对用户体验也存在影响，开发和维护成本也更高。

对于数据安全传输而言，现有技术主要采用SSL（Secure Socket Layer）协议进行，加密强度已经基本达到了“满意”的程度，而对于如何确认“网络人”的身份就有着各种各样的方法。对于网上银行而言，身份认证尤为重要。只有确认了银行客户的合法身份，才能为客户提供安全、优质、高效的服务。否则无法保证客户和银行自身的资金安全，为客户服务更是无从谈起。如今常见的身份认证方式有口令验证方式、动态密码方式、基于PKI体系的证书验证方式。

（1）通信安全 在互联网环境，客户端到WEB服务器端的通信，在安全设计时需确保通信数据在互联网传输过程中加密处理。采用SSL连接时，可选择服务器端部署密钥长度为1024位的站点证书，和客户建立单向或双向的SSL安全通道。即通过SSL握手形成128位的会话密钥，所有的两端通信数据都使用128位的密钥加密。128位的密钥加密，在短时间难以破解，可以保证数据在互联网传输时端到端的安全要求。

（2）客户端安全 电子银行客户端安全目前商业银行通常使用了以下控制机制：一是，使用客户端安全控件取代普通输入框，采集并提交客户敏感信息，以保证数据在客户端获取和存储的安全性。采用登录验证码机制，网银通过在登录页面和交易确认页面设置验证码输入项，有效控制客户端的暴力破解攻击。验证码使用图片方式显示，内容为通过图形变形和背景混淆的数字或字母。客户必须正确的输入图片显示内容才能够继续交易。在交易过程中，系统将重要交易元素通过图形方式展示给客户，以防范数据在客户端被恶意篡改等风险。同时结合验证码图片，保证图片信息的有效和完整。

（3）安全认证 商业银行推出多种安全认证方式，建立不同安全等级的层次化认证手段，以满足不同业务场景下电子银行安全认证的需要。

1）动态口令卡。动态口令卡使用挑战应答方式进行交易认证。客户每次刷新页面时同步更新挑战，保证密码动态变化，挑战密码验证通过后立即失效。电子银行页面显示客户口令卡中的多个坐标，客户输入坐标对应的码元，系统校验输入的密码是否正确。动态口令卡坐标和码元随机产生，码元池可配置，并设有使用次数和有效期的限制，达到使用次数或超期，需更换口令卡。(www.xing528.com)

2）动态密码器。动态密码器是生成动态密码的终端设备。该产品根据专门的算法，以特定的时间为周期，不断更新生成仅当次、当时有效的随机数字组合，即动态密码。动态密码器从技术来分有三种形式，时间型、事件型、挑战型。目前主流动态令牌技术是时间型和挑战型两种，事件型由于容易引发令牌/服务器次序不同步而较少使用。由于挑战信息有交易要素参与，可防范中间人攻击（如钓鱼），因此安全性较时间型高。纯时间动态密码用于电子银行低风险交易；时间挑战动态密码用于电子银行高风险交易。

3）带外认证。对于符合风险监控模型中定义的高风险交易，电子银行系统可中断交易。并由其他渠道，如电话人工或者自动回拨来确认交易的有效性。在用户确认后，交易才能继续。这种方式成为带外认证。短信认证是带外认证的一种。系统生成一个密码并由短信服务平台发送到客户手机，客户在一定时效内输入该密码进行身份认证。该种认证方式客户无须携带认证工具，通过随身手机就能够完成身份认证，但该认证需要第三方系统实时支持。

4）U盾。U盾认证符合数据保密性、完整性、一致性和不可抵赖性的各种要求。客户公私钥对在U盾中产生，且私钥不出KEY。交易过程中，系统使用客户私钥完成数字签名后，客户将签名包提交服务器进行签名数据和客户信息一致性检查。服务器验证成功后，系统保存客户提交签名信息并继续交易。采用可视化和客户按键确认的新一代U盾，实现“所见即所签”功能，可以有效防范证书窃取、证书劫持、交易篡改等风险。

5）多（双）因子认证。多（双）因子认证是通过组合两种不同条件来证明一个人的身份的技术，因此其安全性较单因子认证有明显提高。考虑到便利性，一般将静态密码或短信认证作为第二因素的认证条件。目前较为常见的双因子认证包括：静态密码+短信认证、动态密码+静态密码、数字证书+静态密码、动态令牌+短信认证、动态口令卡+短信认证，见表3-5。

表3-5 多（双）因子认证

注：安全性、易用性别从A+依次往下递减。其中A为高，B为中，C为低；时表示时间型令牌，挑表示挑战型令牌。

3.对移动银行的架构支持

随着平板电脑、智能手机的普及、3G/4G无线网络的发展，越来越多基于移动通信终端的新型应用大量涌现。其中，即时通信应用由于其具有的强大的多模式聊天功能，支持跨手机系统平台、跨移动通信网络等特点，受到用户的极大追捧，市场前景良好。目前国内商业银行以网上银行、电话银行、手机银行为主的电子银行服务渠道和服务方式，在庞大的客户使用群体和日益增加的业务功能的情况下，其服务的覆盖面和使用的便捷性上略显不足。因此，建立既快捷高效又对于客户的使用门槛要求较低的新服务渠道就显得尤为重要。在此背景下，以平板电脑、手机为基础的移动银行渠道应运而生。

互联网应用，良好的客户体验尤为重要。构建系统，若采用B/S结构，在市场推广、客户体验方面无法满足要求；若采用C/S架构，需要开发大量的客户端程序，客户端程序要实现良好的跨平台支持，技术实现复杂。另外，C/S结构“胖”客户端程序不利于版本的升级和补丁的发布。因而，移动重点应用通常选择了“B+C/S”的架构风格，即“廋”客户端软件研发模式。

B+C/S架构，结合了三层B/S架构和C/S架构的特点，在B/S架构的Brower外封装了一层薄薄的Client，使整个系统具有了四个层次，即客户端层、表现层、业务逻辑层、数据层。客户端层通常是根据目标操作系统定制的客户端程序，该程序的主要功能模块包括：初始化模块，浏览器模块，客户端组件模块，主控制模块。其中，初始化模块负责初始化客户端程序，浏览器模块负责调用表现层程序进行页面显示和交互，客户端组件模块封装了一组本地程序组件供客户端层使用，主控制模块负责客户端层程序的控制和调度。表现层部分与B/S架构相比，主要的区别在于，表现层中增加了客户端交互模块。当表现层程序需要调用客户端程序组件时，通过客户端交互模块与客户端程序进行通信。业务逻辑层和数据层与B/S架构相同，因此不再赘述。

采用B+C/S架构后，移动银行客户端部分的结构包括视图层、控制层和工具层三部分。与C/S架构相比，减少了模型层。同时，其他三层中的模块数量也大幅减少。客户端主要通过内置浏览器模块进行各交易的界面展现和交互，当交易中需要使用本地客户端组件（如日期选择期）时，由视图控制器进行主控，响应客户端组件调用请求，并通过回调Web页面的Javascript方法完成应答，如图3-25所示。

图3-25 移动银行客户端结构

以iPad客户端为例，如下图3-26所示。内置全屏浏览器，通过浏览器与服务器端进行通信，发送请求并接收返回的Web页面数据进行界面展现。

图3-26 iPad客户端示例

作为银行交易系统，移动银行的升级和更新必不可少。采用B+C/S架构后，由于客户端很“瘦”，与业务相关的功能很少。客户端更新的频率和下载所需时间的大幅减少，客户体验好。而且除了客户端部分程序需要根据特定移动设备应用风格调整外（如iPad/Android），其他的程序大部分可以在不同移动银行之间复用。