当下，传统银行的国际支付清算业务面临挑战，新的市场进入者以高效和低价优势逐步蚕食传统银行的国际支付市场份额。特别是第三方支付强势进入，与传统银行正激烈争夺国际支付清算市场。
传统银行必须整合银行核心的统一支付业务和现有客户，提高银行的服务水准、支付效率以及客户体验感，因此建设一套适合新时代支付要求的统一支付清算系统迫在眉睫。
1、总体设计
1. 总体需求
外币支付清算系统主要实现以下6种功能。
(1）实现从现有核心系统中的完全剥离，完成外币国际资金清算系统（Society for Worldwide Interbank Financial Telecommunication,SWIFT）支付清算的专业化处理。
(2）支持电子同城和超级网银的支付汇路，并支持对公电子渠道跨行支付接入，实现人民币支付清算的专业化处理。
(3）实现本外币支付清算业务管理的统一视图，建立统一的管理平台。
(4）支持跨渠道、跨业务、跨产品、跨币种的外币支付以及资金清算服务的全新产品系统。
(5）支持与上海市、安徽省合肥市双机热备接入，支持双中心双活架构，高可用解决方案，实现系统稳定运行。
(6）支持日处理10万笔业务报文能力，峰值每秒事务处理数（Transaction Per Second,TPS）达2000个。
实现的功能性需求包括报文核心、集成管理、清算处理、头寸管理、事务管理、支付处理、对账管理、智能汇路、系统管理以及系统监控等。系统功能结构如图1所示。
图1 系统功能结构
2. 物理架构设计
物理架构设计如图2所示。外币支付采用集中式部署架构，通过报文通信服务器消息队列（Message Queue,MQ）与SWIFT系统Alliance直接对接，处理跨境交易。受理各渠道，如柜面FES、单证、离岸、金融市场SUMMIT以及托管系统交易统一，通过企业服务总线（Enterprise Service Bus,ESB）接入外币支付清算系统。
其中，报文通过穿透性简单对象访问协议（Simple Object Access Protocol,SOAP）报文封装。各渠道报文文件推送均使用电子资金转账（Electronic Funds Transfer,EFT）或交易功能表（Transaction Function Table,TFT）通过ESB路由传输。
3. 应用功能架构设计
应用功能架构如图3所示。各分板块对接系统包含渠道、ESB、枢纽层、公共平台系统以及外部交换系统5个模块。
图2 总体架构设计
图3 应用功能架构
(1）渠道。
渠道类系统主要包括网点平台、柜面、自助、网银、电话银行、手机银行以及通知平台等。
(2)ESB。
ESB为新一代服务发布平台，为各应用系统之间的技术集成提供基本的同步/异步通信、路由及协议转换。
(3）枢纽层。
枢纽层主要包括商业创新平台（Business Innovation Platform,BIP）和企业级客户信息整合系统（Enterprise Customer Information Facility,ECIF），提供服务、流程整合以及客户基本信息主数据管理功能。
(4）公共平台系统。
公共平台系统主要包括统一认证和授权管理系统，提供统一用户认证、权限查询和用户管理服务。
(5）外部交换系统。
外部交换系统包括SWIFT系统、境内外币支付系统、二代支付系统前置、人民币跨境支付系统前置、网上支付和跨行清算系统、代理结算平台、外汇数据报送系统、核心系统以及金融制裁系统。
其中：SWIFT系统即SWIFT Alliace系统，用于对接外部SWIFT系统；境内外币支付系统即境内外币支付业务的前置系统，用于对接人行境内外币支付系统的通信；二代支付系统前置用于对接人行二代支付系统；人民币跨境支付系统（Cross-border Interbank Payment System,CIPS）前置用于对接中国人民银行CIPS系统的通信；
网上支付和跨行清算系统用于对接中国人民银行超级网银系统的通信；代理结算平台用于对接代理支付机构的通信；外汇数据报送系统即外汇金宏系统，提供面向外管局的各类监管数据报送；核心系统通过ESB账务交易进行账务查询、记账、抹账、冲正以及对账等操作；金融制裁系统解析SWIFT来报和往报报文，返回命中结果。
4. 技术架构设计
外币支付清算系统技术架构遵循J2EE标准规范，采用面向服务架构（Service Oriented Architecture,SOA）思想和分层设计搭建技术架构。技术架构按照分层架构自上向下分为展现层、控制层、接口层、应用层、基础框架层以及持续层，如图4所示。
图4 技术架构
(1）展现层以Java服务器页面（Java Server Pages,JSP）、intelli UI、超文本标记语言（Hyper Text Markup Language,HTML）、JS以及层叠样式表（Cascading Style Sheets,CSS）为主实现页面展示。前后端以分离的形式实现前端构件库，封装Web应用常用的前端构件。构件通过Web数据交互方式（Asynchronous Javascript And XML,AJAX）与后台进行数据交互，交互格式为JSON。前端构件库主要包含布局类、菜单按钮类、表单类、窗体类、数据类以及工具类6类构件。
(2）控制层采用XXX公司拥有自主知识产权的Web引擎Intelli Web。轻量级框架采用拦截器机制处理用户的请求，无侵入式设计使业务逻辑控制器与Servlet API完全脱离，并支持多种表示层技术，具有线程安全带的特性。
(3）接口层主要提供接口数据通信传输控制、定义接口数据格式、接口数据转换以及通信监控等功能，涉及的技术包括ESB和Web Service（通过CXF开源框架实现）。
(4）应用层主要包括业务处理、业务公共组件和管理监控。
(5）基础层包括系统运行所依赖的基本框架和资源，包括基础模块、基础技术组件以及具体使用的技术选型。
(6）持久层主要包括数据库组件和数据存取服务，具体功能包括数据库连接、数据访问、数据格式转化、数据一致性以及数据持久化等。
5. 用户交互设计
（1）设计原则
统一支付清算系统的界面遵循简洁、易用、一致性以及重点突出等原则，强调在使用的过程中功能明确，具有良好的体验感，并在使用习惯上不冲突。
（2）界面布局
主界面的宽度和长度分别设置成相对值100%（包括View的design Property属性和Page的style属性）。界面区域分为Logo区、标题区、菜单区、登录区、工作区以及帮助区6个区域。主界面布局如图5所示。
图5 主界面布局
系统Logo显示XXX银行标识Logo。标题区显示在主页面的左上角，显示内容为“XXX系统”。帮助区显示在主页面的右上角，有帮助按钮、修改密码、注销等按钮。登录用户信息显示登录过此系统的用户信息。菜单区只显示登录用户有权使用的菜单项。主页面右下方较大的区域为工作区域，可显示数据并能进行相关操作。
（3）界面元素布局
皮肤指一系列界面样式，包括整体色彩、字体和控件的基本颜色等。建议开发阶段选定皮肤，尽量不随意更换。外币支付清算系统界面使用Intelli Platform默认提供的蓝色作为皮肤的主色素，如图6所示。
图6 支付清算系统界面
字体建议采用系统提供的默认字体。由于客户端没有对应的字体文件，使用特殊的字体在页面显示时可能会导致界面显示效果受到影响。
页面控件主要分为可视控件和不可视控件。不可视控件放在e:View标签内部，且在id为“Invisual Controls”的div中；可视控件可放置在e:Page内部的任何地方。此外，按照规则放置各种控件，并保持页面的良好可读性，方便日后维护。控件代码布局如图7和图8所示。
图7 控件代码布局
图8 控件代码布局
（4）浏览器支持
外币支付清算系统支持以IE作为核心的浏览器，如360、腾讯以及百度的浏览器等，推荐使用IE 8以上的浏览器访问统一支付清算系统。WIN操作系统的分辨率支持1280×800及以上。
2、关键技术设计
关键技术设计主要包含报文分拣设计、交易引擎设计以及规则引擎设计。
1. 报文分拣设计
设计自动分拣和人工分拣。自动分拣为后台自动服务，对进入清算平台的报文进行报文内容解析、报文格式校验、登记簿保存、所属模块判断以及调用所属模块提供的接收接口。
执行报文自动分拣时，对因报文信息不完整和格式不正确等问题造成无法正常分拣到具体模块的报文，系统提供“报文人工分拣”功能进行“重分拣”或“废除”处理。报文分拣流程如图9所示。
图9 报文分拣流程
（1）自动分拣设计
自动分拣设计主要包括报文信息解析、报文信息检验、登记簿保存以及调用所属模块接收接口。报文信息解析主要解析报文信息，而不同类型的报文对应不同的解析方法。报文信息检验即对报文信息进行格式检验，不同报文格式（标准SWIFT报文，系统间约定的格式）定义不同的检验规则。
登记簿保存是指将输入的报文信息保存到系统数据库。对于调用所属模块接收接口，在报文分拣判断出所属模块后，调用各模块提供的接收接口，由接口负责接收各自模块。当报文自动分拣出现异常情况时会导致分拣失败，而该笔报文会由人工分拣处理。
（2）人工分拣设计
在报文自动分拣过程中，人工分拣为无法识别所属模块或所属模块接收报文处理过程中出现异常报文，提供重新分拣或废除处理。重新分拣操作，即选择重新分拣，根据所属功能模块，系统自动修改分拣失败状态为待分拣，进而分拣到所选择的归属模块。若分拣成功则提示“成功”，否则提示“失败”。
废除操作，即选择废除，系统修改分拣失败状态为废除状态，提示“废除成功”。
2. 交易引擎
交易引擎框架设计如图10所示。交易引擎处理来自于不同渠道不同类型的交易。交易引擎将交易映射到对应的交易处理服务，通过组件化和流程的封装简化交易处理方式，提高交易开发和处理的效率。
图10 交易引擎设计图
（1）引擎拦截
①交易日志。
不同于一般的日志记录信息，交易引擎根据业务需求（如流水号和交易次数）把交易相关信息集中记录，使维护人员能根据交易查看日志记录，便于快速发现交易处理过程中存在的问题。提供交易日志需要定期的压缩和备份功能，防止记录日志不断增长导致服务器存储空间不够。
②交易拦截。
交易拦截指在交易处理过程中，由于统计或控制等需求，需要在交易进出引擎或交易服务处理时提供切面拦截机制。开发人员可在拦截点植入拦截处理，确保灵活管理这些交易。交易拦截如图11所示。
图11 交易拦截
③引擎拦截。
引擎拦截是指引擎层的服务拦截，即所有进入引擎的交易都要接受拦截操作，便于对所有交易进行监控和集中控制管理。
④服务拦截。
服务层的拦截是对特定服务的所有调用都要接受服务拦截，便于对该服务所有调用进行监控和集中控制管理。
（2）交易映射
交易映射指将一笔交易按照其交易要素映射到对应的交易处理服务的过程。如果根据交易要素没有找到对应的交易处理流程，则按照系统默认的交易处理流程处理。交易映射如图12所示。
图12 交易映射
（3）服务编排
通过配置文件的方式编排服务的组成，包含服务组件的调用、组件执行路由以及数据的映射关系，如处理流程等。服务编排如图13所示。
图13 服务编排
（4）监控管理
交易服务的管理主要包含交易服务的装载、重载以及交易服务的启停等内容。
3. 规则引擎
规则引擎负责解释执行规则表达式。将当前提交给规则的数据对象与加载在规则组件中的规则进行匹配，根据业务规则声明的逻辑进行执行。规则包含一组条件和在此条件下执行的操作，可替代应用程序的一段执行逻辑。规则引擎对规则表达式设置界面如图14所示。
图14 规则引擎设计
（1）规则引擎的优点
规则引擎具有诸多优点：适应业务规则的多变性，提高了可扩展性、灵活性和维护性；判断条件的逻辑组合不受设计限制，提供了最大的灵活性；业务人员可根据业务规则需要，在运行时修改判断规则；无需额外的开发，即可应用新的规则。
（2）规则引擎的应用场景
规则引擎的应用场景包括支付业务类型识别、支付业务归属机构识别、支付业务解付参数判断、往来任务池优先级计算、费用组件的收费规则、汇路组件以及报文路由分发等。
3、系统实施与测试
外币支付清算系统由于关联系统众多、功能覆盖面广、投入人力财力巨大、领导重视程度高以及投产压力大，在开发过程中需求复杂且多变，需要多次细化调整方案，并迭代部署和分期投产。在测试过程中，开发人员进行了多轮次和不同维度的测试和验证。
1. 系统实施
总体实施方案和迭代部署分两期进行。第一期投入180人月，投产内容包括报文平台、集成平台、清算管理、头寸管理、事务管理、对账管理以及系统管理等功能。第二期投入100人月，投产内容主要包括支付管理、报表管理、监控管理、支付功能以及辅助功能。
2. 系统测试
总体测试主要包括SWIFT来报测试、SWIFT往报测试、用户验收测试、REL功能测试、安全性测试、性能测试以及投产验证。SWIFT来报测试的测试场景为50个（含代理），共测试正反案例数1500个。
SWIFT往报测试分3轮进行，第1轮测试正案例数300个和反案例数200个，第2轮测试正案例数300个和反案例数200个，第3轮测试正案例数300个和反案例数200个。用户验收测试（User Acceptance Testing,UAT）的测试场景为50个（含代理），测试正反案例数各500个。
REL功能测试的测试场景为50个（含代理），测试正反案例数各500个。安全性测试结果显示，无SQL注入等常见安全问题。性能测试结果主要显示磁盘I/O状态、CPU利用率以及内存分配等，均满足投产性能指标。
投产试运行，重点验证和观察如下内容：观察交易成功率是否为100%；关联系统文件传输是否正常；日终跑批业务是否正常；SWIFT系统ACK是否为100%；与账户行对账、与核心对账以及与SWIFT对账结果是否平衡。投产验证表明，无生产缺陷，满足投产要求。
通过上述验证安排，确保跨境支付清算交易不受影响，确保系统投产成功。
4、结语
系统总体设计涵盖功能架构设计、部署架构设计、技术总体架构设计、用户交互设计、关键技术设计以及系统实施与测试等内容，属于纲领性设计，符合总体设计要求。该系统实现了集中化、专业化以及批量化的支付申请处理能力，提高了自动化、直通式处理水平以及作业效率，为推动支付业务流程和作业模式的优化升级奠定了基础。
此外，该系统整合了银行内外支付渠道，提高了支付业务方面的创收能力，降低了清算系统建设和运维成本，全面提升了银行支付清算服务水平，满足了客户支付需求，树立了支付业务安全、高效以及灵活的品牌形象。
