第二章 业务及需求分析
支付清算系统（payment and clearing system），也称支付系统（payment system），是一个国家或地区对交易者之间的债权债务关系进行清偿的系统。支付清算是银行内部的资金枢纽，是银行的大动脉，它的业务主要有：上下级行间及跨行之间各种资金往来及其清算；各营业网点客户资金的往来清算；营业网点间代收、代付资金（信用卡、汇票等）清算；个人汇款以及其他各种异地结算业务等。
2.1 业务分析
2.1.1 支付工具
支付工具是资金转移的载体。支付工具的使用，对于加快资金周转，提高资金使用效益具有非常重要的作用。在现代经济社会中，除现金支付外，非现金支付工具在市场经济发展中越来越重要，已基本形成了以汇票、支票、本票和银行卡为主体，汇兑、定期借记、直接贷记、网上支付等结算方式为补充的非现金支付工具体系，支付工具使用范围与特点见下表。
| 类别 | 工具名称 | 使用范围与特点 |
| 贷记支付工具 | 汇兑 | 异地、同城；资金划拨、支付。 |
| 委托收款 | 异地、同城；划回业务（凭票据委托收款） | |
| 托收承付 | 异地；划回业务。 | |
| 定期贷记 | 异地、同城。 | |
| 实时贷记 | 异地、同城 | |
| 借记支付工具 | 银行汇票 | 异地 |
| 华东三省一市银行汇票 | 用于票据交换区域 | |
| 银行本票 | 用于票据交换区域 | |
| 国内信用证 | 异地 | |
| 支票 | 用于票据交换区域 | |
| 旅行支票 | 异地 | |
| 定期借记 | 异地、同城 | |
| 实时借记 | 异地、同城 | |
| 其他支付工具 | 商业汇票 | 资金划回 |
| 银行卡 | 异地、同城 | |
| 国际结算工具 | 电汇 | |
| 信用证 | ||
| 托收 | ||
| 保函 | ||
| 网银支付 | 网银支付 |
2.1.2支付业务的特点
支付清算活动涉及银行前台业务、安保、会计、风险管理等部门和外部的客户及支付清算管理部门，支付方式多样化并且实时性要求高，资金流较多且频繁，流经的环节多。因此，支付业务的数据处理具有如下特点：
1、数据量大
银行支付系统的数据大，主要是支付业务量持续快速增长。社会资金交易日趋活跃，资金交易规模持续扩大，交易频繁程度进一步提高。2010年，全国共办理非现金支付业务277.04亿笔，金额905.18万亿元。
2、日常数据处理频繁且实时性要求高
银行支付业务是经常性的业务活动，每天都要及时进行数据处理，实时反映银行存、贷、资金支付、业务量的状况，为后续作业、日常监管和宏观调控提供及时、准确、完整的信息。
3、业务处理复杂且可靠性要求高
银行业务根据不同标准分类很多，最常用的商业银行业务分类有三类：商业银行形成资金来源的负债业务，商业银行运用资金的资产业务，银行不需运用自己的资金，代客户承办支付和其他委托事项而收取手续费的中间业务。支付方式有现金、银行支票、银行汇票、商业汇票、委托收款、异地托收承付和汇兑、网银支付等方式。所有这些业务处理和核算都需要及时记录、正确计算。
4、与银行其他信息系统有较多的数据联系
支付的业务处理流程涉及银行多个部门的业务活动和管理控制活动。它与银行存款、贷款、中间业务、会计核算的数据处理有密切的联系。这些资金流流经银行各业务环节，联机子系统、清算子系统、管理子系统对这些支付过程的事项进行核算、分类汇总。
5、支付的安全性
在支付系统中无论采用哪一种付款工具，都必须具备以下几个条件：安全性、处理成本低、且广为全球金融市场所接受，而安全性是第一位的。所以，保证支付工具的真实与识别该使用者的合法身份就是金融业在网络环境下实现电子支付所面临的问题。
2.1.3 支付清算组织架构
某银行支付清算组织架构如下图所示：
各机构职能及岗位职责如下：
1、清算总中心主要职能：是为中央银行、商业银行和全社会提供支付清算及相关服务的全国性金融服务组织。主要提供实时全额资金清算服务、净额资金清算服务、支付管理信息服务、支票影像归档及交换服务和境内外币清算服务等。
2、全国性清算公司主要职能：
(1)对票据等纸质支付指令进行交换和计算；
(2)办理电子支付指令交换和计算；
(3)办理卡类支付指令的交换和计算；
(4)利用网络平台办理支付指令交换和计算。
3、资金清算中心主要职能：办理成员机构及所属网点间实时电子汇兑、银行汇票等本、异地资金清算业务，以及经中国人民银行批准的其他支付清算业务。
4、省人行清算分中心主要职能：
(1)组织贯彻支付清算的法律、法规和制度、办法，并负责对辖区内各银行贯彻执行有关法规的监督检查；
(2)根据总行制定的支付清算制度、办法，结合辖区内的具体情况，负责制定实施细则，并报总行备案；根据需要可以制定支付清算的单项办法，报经总行批准后实行；
(3)调查研究经济运行新情况，组织推行支付工具的运用；
(4)负责支付结算和联行清算工作的监督和管理，实施现场和非现场的监督检查，处罚违反支付结算和联行清算纪律的行为，维护支付清算秩序；
(5)宣传、培训、组织和协调支付结算和联行清算业务工作，调解、处理辖区内的支付结算和联行清算的纠纷；
(6)根据总行的统一部署，负责实施支付清算系统的建设，组织支付清算系统的正常运行；
(7)负责有关结算机构的审查，组织支付密码的应用，并报总行批准后实施；
(8)负责组织票据凭证和联行清算重要凭证的印制；
(9)负责支付结算和联行清算数据的统计汇总和上报，调查反映支付结算工作的情况。
5、前台经办岗的职责：
(1)审核提出借方支票与进账单金额是否相符；
(2)审核提出借方支票日期、金额大小写、及背书是否符合结算制度规定；
(3)核打借方支票、进账单总金额是否相符，汇总提出借、贷方票据总额及笔数并填写“内部交接登记薄”，在收妥抵用的进账单右上角加盖私章；在提出贷方票据的右上角加盖私章。
(4)审核提出贷方票据的提入行行号是否填写，并在综合业务系统中进行核对
6、事中监督岗的职责：
(1)对提出借方支票、提出贷方进账单进行复核，并在提出票据右上角加盖私章；
(2)对清算提出的票据应配对借、贷方凭证进行审核，如提出借方贷票据应同时审核进账单是否一致，以防止串户；
(3)核对“内部交接登记薄”上借、贷方登记金额。
7、清算复核岗的职责：
(1)核对每张票据金额与打码金额及提入行员是否相符；提出清算行号是否正确，并核对每场提出票据总额及笔数是否相符；
(2)保管“同城清算锁扣”，参照重空管理办法建立表外重空登记薄，根据领用、使用、作废进行逐个销号处理；
(3)与相关部门人员办理好清算包的交接登记工作。
8、清算打码岗的职责：
(1)负责每张提出票据各要素输入的正确性，如果输入有误，要负责自行更正；对每张清算提出的票据加盖“清算章”；
(2)负责每场清算的拒票率在人行的标准以内；
(3)负责审核提出行行号和提入行行号的正确性及信封封面的金额和笔数。
(4)保管“同城清算章”，在每张提出票据、红信封、黄信封上加盖清算。
(5)在每张提出票据打码时，账号均输入本行开户账号，便于日后查账方便。
2.1.4 支付清算业务流程
根据国际支付业务分类标准，结合支付结算方式的分类和各自特点不同，可将支付清算活动基本分为四种业务模式：
1、纸质支付工具即票据是出票人依票据法发行的、无条件支付一定金额或委托他人无条件支付一定金额给受款人或持票人的一种文书凭证。狭义票据专指票据法所规定的汇票、本票和支票等。
（1）汇票是出票人委托他人于到期日无条件支付一定金额给受款人的票。
（2）本票是出票人自己于到期日无条件支付一定金额给受款人的票据。
（3）支票是出票人委托银行或其他法定金融机构于见票时无条件支付一定金额给受款人的票据。
在商业交易中，以票据的转移，代替实际的金钱的转移，可以大大减少交易风险。票据所具的汇兑功能使得大宗交易成为可能。其中根据持票人的不同可以分为两种：
- 收款人持票办理结算的业务流程图如下：
（2）出票人持票委托开户银行将款项划给收款人的结算业务流程图如下：
2、电子资金划拨（Electronic Fund Transfer）
电子资金划拨是通过电子终端、电话、电传设施、计算机、磁盘等命令、指示或委托金融机构向某个账户付款或从某个账户提款；或通过零售商店的电子销售、银行的自动提款机等电子设施进行的直接消费、存款或提款等。
根据发起人的不同，可以分为由债务人发起的贷记划拨和由债权人发起的借记划拨。根据服务对象的不同与支付金额的大小可分为小额电子资金划拨系统和大额电子资金划拨系统。其业务流程图如下：
3、信用卡
信用卡是银行或金融公司发行的，授权持卡人在指定的商店或场所进行记帐消费的信用凭证。
信用卡具有转帐结算、消费借贷、储蓄和汇兑等多种功能。它能为持卡人和特约商户提供简化高效的结算服务，减少现金货币流通量；还可避免随身携带大量现金的不便，为支付提供较好的安全保障。
通过上述业务流程图可以看出，无论采用何种模式，支付清算业务都需要经过付款人（银行客户）申请支付、付款银行办理并审核、付款与收款银行之间结算（或电子资金划拨）、收款银行通知收款人资金到账等基本环节构成。
2.2 存在问题及解决措施
2.2.1 主要问题分析
原有的支付业务在资金清算时采用定时、定点的人工跑票方式，即在指定时间（换场时间），各商业银行的交换员携带要交换的票据到人民银行的清算中心，然后进行票据清分、交换，汇总轧差，将轧差结果在人民银行所开的清算账户上记账。各商业银行的交换员将交换后得到的票据带回本行，在本行的企业账户上记账。为了解决原有支付系统中银行行内及跨行资金传递环节多、结算周期长、占压在途资金大，降低资金的使用效益、严重制约了社会经济的发展等种种不利因素。
2.2.2 解决措施
为实现银行系统内部及跨行之间资金汇划、对帐、资金清算、查询、帐务核算、代理清算以及其他辅助功能，最直接、有效的解决方案就是建立统一共享的支付清算系统，同时统一共享的系统作为社会经济良好运行的基础，经济发展的催化剂，对国家实现价格稳定、市场稳定和金融稳定等宏观调控目标也有十分重要的现实意义。
2.3功能性需求分析
随着中国经济的持续稳定增长，不同经济主体之间联系日益密切，全社会资金交易规模持续扩大，资金交易活跃程度明显提高，非现金支付业务量持续增长。而各类商业银行虽然都能提供快捷的支付服务，但这种服务仅限于系统内的资金转移。对于跨系统的资金清算，由于银行间支付系统未实现互联，造成资金在途时间长，直接影响社会资金使用量的加大、效率较低，进而影响了国民经济的平稳较快增长。同时，随着信息技术网络化、服务化发展，用户对金融服务的要求也越来越高。第三方支付、网上支付等新兴支付方式的出现和发展，不仅开启金融服务创新之门，也为支付业务的发展注入新的元素，它有效地突破了时间和空间的限制，以其特有的随时、随地、随身特点，为用户提供便捷的、个性化的新型支付服务，成为支付业务的新兴表现形式。
2.3.1市场需求
支持多种接入方式：支持银行业金融机构从城市处理中心CCPC或国家处理中心NPC一点接入。管理上需要业务量达到一定规模的参与者通过国家处理中心NPC一点接入，其他参与者通过所在地城市处理中心CCPC一点接入。
支持灵活的清算模式：系统将同时支持“一点清算”和“多点清算” 。
全面的流动性风险管理：在保留原有支付系统排队管理、清算窗口、自动质押融资、小额业务撮合等流动性管理功能的基础上，需要增加大额清算排队业务撮合、“资金池”管理、日终自动拆借、“一揽子”流动性实时查询等功能，为参与者提供更加全面的流动性管理。
2.3.2业务需求
支持新兴电子支付业务处理：需要提供网银转账汇款、投资理财、网上购物、网上缴费等多种支付服务。
支持外汇交易市场同步交收清算：需要系统与境内外币支付系统连接，支持由交易会员双方发起结算指令的询价交易结算或外汇交易中心以即时转账方式从会员指定清算账户扣款的竞价交易结算，以达到人民币与外币的同步交收，提高结算效率，降低结算风险。
支持人民币跨境结算：支持参与者之间办理以电汇、保函、托收、信用证为主要贸易国际结算方式产生的人民币跨境支付业务的信息流转及资金清算。
2.3.3运维需求
运行监控功能：公共管理与系统维护需对大额支付系统、小额支付系统、支票影像交换系统、网银支付系统以及清算账户管理系统等提供统一服务，提高系统整体业务处理效率。
安全管理功能：需要建立纵深防御即MBFE、CCPC、NPC三层安全领域和安全防御体系，满足使用数字签名，做到加密传输。
信息管理功能：运用数据仓库、数据分析和报表工具，对支付系统中蕴藏的大量支付清算交易信息，进行深度挖掘和加工，建立面向客户和管理决策层的应用数据仓库，实现支付业务数据共享，为货币政策、反洗钱、金融稳定等提供信息支持和决策依据。结合业务发展及管理需要，对报表类型和统计功能进一步丰富完善，提供更加全面的数据信息统计报表。
数据存储功能：对采集的各类支付交易信息，按特定规则进行加工与整合，实现按特定对象的数据存储，方便按支付主体（单位或个人）一揽子信息查询。
灾备系统功能：备份形成以北京中心为运行中心，北京主站为同城数据备份中心，上海中心为远程灾备中心，并建有CCPC备份系统的物理架构。采用不同的灾备等级和灾备策略，保证业务的连续处理，进一步提升某银行支付清算系统应对各种突发事件的能力。
2.4非功能性需求
2.4.1系统级需求
整体系统的稳定性：要求系统具有很高的稳定性，不论是在低负荷还是在高负荷的情况下系统都能够长期稳定运行。
高效性：系统具有较高的处理能力，能够处理较多的客户连接，而且系统在进行集中批量处理时也能高效运行，响应时间能够满足今后在一定时期内的业务需要。
成熟性：系统采用的技术一定要非常成熟，有较多的成功案例，技术发展比较稳定，没有出现过重大的安全或者性能问题，包括网络、硬件、系统软件、应用软件等。
开放性：系统要具有较好的开放性，提供完备的开发接口，系统间的连接采用松偶合，并采用通用的符合国际标准的技术。
先进性：系统采用的技术要具有一定的先进性，是目前技术发展的潮流，并能有非常好的发展前景。
可维护性：系统要具有非常好的可维护性，提供良好的运行日志，提供界面友好的管理界面，系统易于扩充和部署。
2.4.2信息安全
网络安全：采用有效的技术和工具，防止非法入侵，并能监测网络安全中的漏洞，排除安全隐患。
系统安全：系统要求具有较高的安全性，系统中的核心技术和产品不能有重大的安全隐患。包括：网络环境、操作系统、应用系统、备份系统、数据安全等。
应用软件安全：对应用软件要求具备完善的检测功能，确保不会因为应用软件的本身问题影响系统效率。同时要求应用软件对业务处理的准确性，一旦发生错误要及时恢复，应用软件要防止消耗过多的系统资源而导致系统瘫痪。
支付清算系统是银行内部的资金枢纽，是银行的大动脉，呈现出承办的业务种类繁多，支付活动涉及的部门和客户多，支付方式多样化并且实时性要求高，资金流多且频繁，流经的环节多等特点。根据国际支付业务分类标准，可将支付清算业务基本分为四种业务模式。
本章通过对支付清算业务现状进行了分析，对业务流程进行了梳理，从管理信息化的角度出发，业务流程分析，结合信息系统建设的体系结构，作为支付清算系统进行了需求分析，指出系统需要满足市场、业务、运维、系统需求及信息安全等功能性和非功能性需求。为下一步的系统设计做了充分的准备。
第三章 系统设计
3.1 设计原则
3.1.1 高安全性
系统提供各种不同接口的安全检查，主要包括操作员登录安全检查、应用服务请求安全检查和数据库连接安全检查三级。
用户可根据操作员的具体情况设置不同的密码强度及密码修改频度，保证应用系统登录的安全；在应用服务端，可根据不同业务特点设置不同用户可访问的对象，保证系统服务调用的安全性；数据库访问密码则采用密码加密和AIX操作系统本身的安全性来保证数据库访问的安全。
为保证系统的安全，用户可要求对前台程序进行严格检查，保证只有符合用户指定版本的程序才能运行。
3.1.2 高可靠性
系统采用基于中间件的群集技术，保证应用服务器稳定可靠运行，保证单点故障不影响系统的使用。
3.1.3 高性能
系统把负荷重的业务放到中间服务器执行，充分利用服务器的处理能力。
3.1.4 系统模块化
系统从灵活性、实用性的角度考虑，各个功能模块的划分黑箱化、封装化，对整个系统可以进行搭积木式的构筑，可以灵活的拆卸和扩充。
3.1.5 实时风险监控
对此系统提供实时的风险检测监控功能，主要包括政策风险、市场风险、交易风险等，在系统检测到风险后，系统可根据用户设置自动进行报警或禁止处理。
3.1.6 数据共享性
系统具有良好的数据共享性。所有的基础数据都充分共享，并具有行之有效的接口进行引入和引出。系统具有良好的用户界面，良好的可操作性。系统所有操作是清晰的、流程化的。
3.2 系统的总体架构
在总体框架设计上，支付清算系统采用面向服务的架构。支付清算系统面向服务的架构将系统中分散的功能组织成基于标准的可互操作的服务，各功能域可以快捷地组合和重用这些业务模块，以满足业务需求。支付清算系统面向服务的架构要求采用组件化设计的核心思想，并将其应用到更广阔的领域。支付清算系统面向服务的架构是一套可重用的网络服务的集合，他们之间通过标准化的、与平台无关的接口进行通信。
支付清算系统将SOA架构策略作为整体技术架构设计的核心。在这种技术架构下，系统国家处理中心、城市处理中心两级和各大商业银行以及它们之间可以方便地实现整合和对接。支付清算系统遵循“一个系统、两级管理、三层应用”的架构设计，以国家处理中心为根节点、各省城市处理中心为子节点的分层业务支撑体系。
在整个银行支付清算系统中，软件架构设计采用三层结构：应用层、业务逻辑层、支撑层。
应用层是业务系统与外部系统进行数据交换的平台，主要包括前端展示层和前端转发层，其中：前端展示层使用ACBS和ATBS技术框架，分别用于开发字符界面和支票截留图形界面。前置转发层在分行大前置上，负责业务数据流的转发。对于系统使用者（内部和外部），提供多样化的接入界面，实现对业务逻辑的接入；对于与系统相联的外部系统，向业务逻辑层提供一组接口服务，业务逻辑层通过接口服务完成与外部系统的数据交换。
业务逻辑层处于应用层和支撑层之间，通过数据层的数据操作对象访问业务数据，向接入层提供统一的业务逻辑过程实现业务逻辑。业务逻辑层由一些功能模块组成，这些功能模块由相应的功能组件组成，是系统进行业务处理的逻辑容器。应用层通过业务逻辑层的相关业务组件访问支撑层，并实现相应的业务功能。
支撑层是系统的基础，支撑层中的数据子层存放系统中用到的所有数据。支撑层的数据操作组件向业务层提供统一、规范的数据操作对象，用于屏蔽业务数据的存储、组织和访问的细节，实现业务数据的充分共享。业务逻辑层必须通过数据操作组件访问业务数据，这些业务数据包括共享数据和私有数据。支撑层中的数据组件组成数据操作组件库。
支付清算系统的总体架构如下图所示。
3.3 系统功能结构
支付清算系统应用功能分布主要由国家处理中心NPC、城市处理中心CCPC、支付系统参与者构成。支付清算系统的主要功能包括小额支付子系统、小额代收代付业务子系统、大额支付子系统、公共控制类子系统、清算账户管理子系统、系统管理子系统。支付清算系统功能结构如下图所示。
3.3.1 大额支付子系统
大额支付子系统主要功能包括：一是提供高效的资金汇划服务；二是畅通货币政策传导渠道；三是支持金融市场资金结算；四是支持人民币国际化发展。大额支付的基本业务种类包括支付类业务和信息类业务。其中：支付类业务分为普通贷记业务和即时转账业务；信息类业务分为查询查复、退回申请及应答、业务撤销及业务状态查询等。
3.3.2 小额支付子系统
小额支付业务种类主要包括：普通贷记业务；定额贷记业务；实时贷记业务；普通借记业务；定额借记业务；中国人民银行规定的其他支付业务。
3.3.3 代收代付子系统
代收代付子系统主要完成批量代收、代付业务及实时代收代付业务的信息传送、查询、管理等。
3.3.4 公共控制子系统
公共控制子系统是某银行管理类系统，主要实现系统状态管理、基础数据变更管理、信息类报文发送的功能。
3.3.5清算账户管理子系统
清算账户管理子系统主要完成清算账户的查询、管理以及资金的管理，包括多场清算和多场轧差。
3.3.6系统管理子系统
数据库是支付清算系统的基础，数据库设计是系统开发的重要组成部分。建设本支付清算系统的数据包括采集自商业银行的基础数据和支付清算系统本身的数据。
3.4.1设计思路与原则
按数据重要性进行区别存储和保护，关键数据应集中在NPC；满足业务处理性能的要求；注重数据的完整性、一致性和可用性，统一数据的定义、变更等管理；建立有效的数据备份和归档机制。
3.4.2设计方案分析
一、字符集与数据编码
为更好的适应国际标准，并适应某银行支付清算系统的国际化趋势，某银行支付清算系统数据交换和存储格式统一采用UTF-8编码集。UTF-8是Unicode的一种最常用的变长字符编码，可以根据不同的符号自动选择编码的长短。在UTF－8中，字符以8位序列来编码，用一个或几个字节来表示一个字符。UTF-8编码集包含全世界所有国家需要用到的字符，字符集大；同时是国际通行的编码方式，得到了几乎所有系统软件的支持，通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显示，而无需下载IE的中文语言支持包。
二、数据交换
数据交换主要包含：一是查询库。联机交易数据库的实时数据镜像库；方便对在线数据实施查询、统计、分析以及采集、监控等功能；简化各个子系统之间的数据关系；减少重要业务系统对数据库的压力。二是主要的数据交换方式。准实时数据复制；准实时数据采集；联机报文类数据交换；批量处理类数据交换；参数数据交换。
三、数据归档与检索
数据归档与检索是指各业务系统中将超过联机数据保存期的数据按照规定的接口要求导出为XML格式的文件，通过网络将归档文件送给归档与检索系统，归档系统对归档数据进行分级存储，建立索引支持检索。归档数据保存期为15年，归档系统应支持数据的分级存储功能，5年内的数据保存在联机存储上，超出5年的数据自动迁移到低速率的存储介质上，以降低存储成本。
3.4.3数据库逻辑结构
数据库的逻辑设计在应用系统中占有相当重要的地位，不仅涉及到应用系统业务实现的流程设计，而且在对数据库物理结构的性能处理和数据安全复杂度上，也起着决定性的作用。
支付清算系统的数据库设计，现以业务明细和用户功能的E-R为例进行说明，如下图所示。
用户功能权限的E-R图如下表所示：
3.4.4数据库物理设计
系统数据库的物理设计具体分为系统控制、业务权限控制、系统参数、清算行行号、功能权限控制、操作用户、用户功能权限、接收报文信息、大小额往账明细、大小额来账明细、客户信息通知、支付业务收费汇总、支付业务收费明细、清算账户日报表等等。其中：1、系统控制表见下表：
| 字段名 | 字段类型 | 是否可空 | 中文标签 |
| parcode | char(2) | not null, | -参数代码- |
| parlname | varchar(40) | not null, | -参数名称- |
| parvalue | varchar(60) | not null, | -参数数值- |
| spardesc | varchar(100) | null, | -参数描述- |
2、业务权限控制表见下表：
| 字段名 | 字段类型 | 是否可空 | 中文标签 |
| cmtno | char(6) | not null, | -报文编号- |
| paytools | char(1) | not null, | -交易种类- |
3、系统参数表见下表：
| 字段名 | 字段类型 | 是否可空 | 中文标签 |
| sabkcode | char(12) | not null, | -清算行号- |
| sabkname | varchar(60) | not null, | -清算行名称- |
| sabksname | varchar(20) | not null, | -清算行简称- |
| sabkstat | char(1) | not null, | -状态- |
| sabkclass | char(2) | not null, | -类别- |
| sbksupr | varchar(70) | null, | -本行上级参与者- |
| blccpc | char(4) | not null, | -所属CCPC- |
| bnkcity | char(4) | null, | -所在城市- |
| sabkaddress | varchar(60) | not null, | -清算行地址- |
| postcode | varchar(6) | null, | -邮编- |
| cnttel | varchar(20) | null, | -联系电话- |
| bkemail | varchar(30) | null, | -email地址- |
| content | varchar(60) | null, | -备注- |
4、清算行行号表见下表：
| 字段名 | 字段类型 | 是否可空 | 中文标签 |
| sabkcode | char(12) | not null, | -清算行号- |
| sabkname | varchar(60) | null, | -清算行名称- |
| sabksname | varchar(20) | null, | -清算行简称- |
| sabkclass | char(2) | null, | -类别- |
| sabkstat | char(1) | null, | -状态- |
| sbksupr | varchar(70) | null, | -本行上级参与者- |
| blccpc | char(4) | null, | -所属ccpc- |
| bnkcity | char(4) | null, | -所在城市- |
| sabkaddress | varchar(60) | null, | -清算行地址- |
| postcode | varchar(6) | null, | -邮编- |
| cnttel | varchar(20) | null, | -联系电话- |
| bkemail | varchar(30) | null, | -email地址- |
| opertype | char(1) | not null, | -操作类型- |
| opereffdate | datetime | not null, | -操作生效日期- |
| content | varchar(60) | null, | -备注- |
5、大额往账明细见下表：
| 字段名 | 字段类型 | 是否可空 | 中文标签 |
| txssno | numeric(8) | not null, | 支付交易序号 |
| cmtno | char(6) | not null, | 报文编号 |
| consigndate | datetime | not null, | 发报日期 |
| moneysymb | char(3) | not null, | 货币符号 |
| amount | numeric(15,2) | not null, | 金额 |
| odficenter | char(4) | not null, | 发报中心 |
| isdficode | char(12) | not null, | 发起清算行行号 |
| 字段名 | 字段类型 | 是否可空 | 中文标签 | |
| odficode | char(12) | not null, | 发起行行号 | |
| cnapsodfi | char(12) | not null, | 支付发起行行号 | |
| payeropenaccbkcode | varchar(12) | null | 付款人开户行行号- | |
| payeracc | varchar(32) | null, | 付款人帐号 | |
| payername | varchar(60) | null, | 付款人名称 | |
| payeraddr | varchar(60) | null | 付款人地址 | |
| rdficenter | char(4) | not null, | 收报中心 | |
| osdficode | char(12) | not null, | 接收清算行行号 | |
| rdficode | char(12) | not null, | 接收行行号 | |
| recipientopenaccbkcode | varchar(12) | null | 收款人开户行行号/银行行号- | |
| recipientacc | varchar(32) | null | 收款人账号 | |
| recipientname | varchar(60) | null, | 收款人名称 | |
| recipientaddr | varchar(60) | null | 收款人地址 | |
| oprttype | char(2) | null | 业务种类3 | |
| warrantdate | datetime | null | 票据日期 | |
| warrantno | varchar(8) | null | 票据号码/拆借期限- | |
| compensationamnt | numeric(18,4) | null | 赔偿金金额/拆借利率- | |
| repudiationamnt | numeric(15,2) | null | 拒付金额 | |
| procstate | char(2) | not null, | 处理状态 | |
| rectime | datetime | null | 收到时间 | |
| sendtime | datetime | null | 发送时间 | |
| settime | datetime | null | 清算时间 | |
| errcode | varchar(8) | null | 错误代码 | |
| errdesc | varchar(60) | null | 错误描述 | |
| prilevel | char(1) | not null, | 优先级别 | |
| putuser | varchar(8) | not null, | 录入用户 | |
| checkuser | varchar(8) | null | 复核用户 | |
| updateuser | varchar(8) | null | 修改用户 | |
| grantuser | varchar(8) | null | 授权用户 | |
| payofxchngseal | varchar(40) | null | 支付密押 | |
| billofxchngseal | varchar(10) | null | 汇票密押 | |
| oprtsource | char(2) | not null, | 业务来源 | |
| checkstate | char(2) | null | 对账状态 | |
| flowno | numeric(8) | not null, | 流水号 | |
| strinfo | varchar(60) | null | 附言 | |
| content | varchar(100) | null | 备注 | |
| printno | int | null | -打印次数- | |
3.5系统网络拓扑设计及分析
3.5.1基本思路
计算机方案采用混合平台方案，基本思路主要是借鉴原有系统的成功经验，根据应用系统设计和数据分布设计的结果，通过区分计算资源，将联机交易系统的核心处理逻辑（例如轧差、记账）、关键业务数据（包括清算账户信息，参与者交换的报文信息等）部署在主机平台，而将计算复杂且对CPU资源消耗过高的处理逻辑，例如XML报文的解析、业务流程的控制、业务数据核对等逻辑部署在开放平台，实现联机交易系统数据集中、应用分布的混合平台架构。统计分析等子系统的应用和数据均部署在开放平台。
在实现上遵循以下原则：一是联机交易系统依赖的业务数据集中存储在主机平台；二是所有对主机平台数据库的更改操作应通过主机核心应用服务完成，分布式平台业务系统通过系统网络体系结构SNA（System Network Architecture）或IPIC以一阶段方式访问主机上对应的子系统核心服务完成数据更新操作。三是开放平台可通过数据库客户端访问主机数据，但仅限于只读操作。
图22 支付清算系统拓扑结构图
3.5.2 NPC逻辑部署
国家处理中心NPC逻辑部署的总体结构包括主机平台核心服务层和开发平台业务处理层。
主机平台核心服务层功能体现在以下几方面：
1、主机上的账务业务处理子系统和各业务处理核心服务层均选择基于成熟的CICS事务管理器和DB2 数据库，维护和管理各自的业务数据；
2、主机平台上存储清算账户管理系统SAPS（Settlement Account Processing System）账务数据、特殊业务数据、小额业务数据、网银业务数据、大额业务数据、公共管理（含计费）数据；
3、主机上的数据采用准实时数据复制技术将数据复制到开放系统存储的查询库中，以避免管理客户端、业务监控、应用监控等对主机业务数据查询带来的压力。
开发平台业务处理层主要体现访问主机核心服务和为继承现有资产，可部署CICS 事务管理器和WMQ来保障应用逻辑内部数据的一致性和完整性。
3.5.3 MBFE物理部署
商业银行前置机MBFE物理部署分为直连参与者与间连参与者，其中直接参与者物理部署如下图所示：
图23 支付清算系统MBFE物理部署图（直接参与者）
3.5.3 网络拓扑设计分析
网络拓扑设计之所以选择混合结构，主要考虑了以下因素：
1、充分利用大型主机的高安全性，将关键业务逻辑部署在主机平台，只有经过主机应用才能修改（增删改）关键业务数据；
2、充分利用IBM大型主机的成熟技术，尽最大限度提高支付系统核心业务系统的高可用性。基于大型主机实施的GDPS/Hyperswap等技术使系统可用性可达到99.999%以上，保证无论是单台主机还是单台存储出现故障时，业务连续性均可以得到很好的保证。目前全球各大银行的关键业务系统大多数都运行在主机平台；国内四大商业银行目前都已采用该技术保障其核心系统的高可用性。
3、原有支付系统就是采用的混合结构，积累了相应的软件开发、工程实施以及运行维护的经验；某银行支付清算系统继续沿用这一结构（在细节方面加以优化），风险相对可控。
4、与在主机上部署全部应用功能相比，采用混合结构能较大程度降低建设运维成本和软件开发难度。
3.6 系统接口设计
系统采用消息中间件与区域网关处理软件连接，负责接收商业银行行内系统向通用报文传输平台提交的各类报文，进行必要的报文格式检查后，自动计算路由策略并选择较优路径，按照通用报文传输平台要求的安全策略，将报文转发至区域网关；同时负责接收区域网关向本接入点发送的报文，并转发至商业银行行内系统。主要通过以下方式进行接口设计：
支付清算系统前端渠道层使用ACBS框架开发字符处理界面，使用ATBS框架开发支票截留业务处理界面，通过CTG和分行AIPS前置连接。分行AIPS前置通过CICS LINK方式和总行支付清算系统连接。
支付清算系统通过TONGLINK/Q通讯中间件向商业银行前置机（MBFE）发送、接收报文，通过CICS LINK向ABIS发起联机交易。
商业银行前置机（MBFE）通过TONGLINK/Q通讯中间件与支付系统国家处理中心（NPC）通讯，发送、接收业务报文。
图24 系统接口设计关系图
支付清算系统为银行业金融机构提供两种接入方式：一是以法人机构为单位一点集中接入，参与者可以根据业务管理需要和行内系统建设情况，选择从支付系统国家处理中心（NPC）或城市处理中心（CCPC）接入；二是以分支机构为单位分散接入所在地CCPC。银行业金融机构采取一点接入方式下，支付清算系统支持灵活选择资金清算模式。既可以开设单一清算账户，所有支付业务均通过该账户进行清算；也可以保留多个清算账户，支付业务分别通过指定账户进行结算，系统为参与者提供所有清算账户资金的集中统一管理。
系统接口设计描述如下表所示：
| 接口描述 | 对端系统 | 发起方 | 调用方式 | 支持业务内容 | 传输协议 | 备注 |
| 影像平台接口 | 影像平台系统 | 支付清算系统客户端、服务端 | API | 影像上传、入库 | HTTP | |
| 电子验印接口 | 电子验印系统 | 支付清算系统客户端、服务端 | API | 获取电子印鉴、批量上传图像 | TCP | |
| 支付密码接口 | 支付密码系统 | 支付清算系统 | CICS LINK | 核验支付密码 | TCP | |
| 贷记卡接口 | 贷记卡系统 | 支付清算系统 | CICS LINK | 核验贷记卡 | TCP | |
| 现金管理接口 | 现金管理系统 | 支付清算系统 | CICS LINK | 跨行汇兑业务 | TCP | |
| 网银/手机银行接口 | 网银/手机银行系统 | 支付清算系统 | CICS LINK | 跨行汇兑业务 | TCP | |
| 国库业务接口 | 国库信息处理系统 | 支付清算系统 | CICS LINK | 国库资金清算业务 | TCP | |
| 集中作业平台接口 | 集中作业平台 | 支付清算系统 | Eci Call | 跨行汇兑业务 | TCP | |
| 托管业务接口 | 托管业务清算管理系统 | 支付清算系统 | CICS LINK | 跨行汇兑业务 | TCP | |
| 清算系统接口 | 清算系统 | 支付清算系统 | TONGLINK/Q通讯中间件 | 资金清算信息、清算中心业务 | TCP | |
| 支票影像接口 | 支票影像交换系统 | 支付清算系统 | Eci Call | 支票影像回执业务 | TCP |
3.7 系统安全性设计
3.7.1安全方案
某银行支付清算系统安全方案主要体现在以下几个方面：一是强化数据传输安全，在传输平台中实现对数据完整性的检查；二是用户集中管理，建设统一的用户认证和授权子系统，实现用户身份认证、访问控制以及用户操作的安全审计；三是建立网络安全体系，建设安全域边界、网络边界；重点保护CCPC与参与者之间的边界，对接入支付系统进行更为严格的控制，确保支付系统边界的完整性；四是注重安全管理，安全审计等，搭建相应的平台。
3.7.2运维管理
（一）、运维管理的设计思路
1、“多中心一体化”的运维管理包括一体化的监控、一体化的运行、一体化的维护管理、一体化的服务支持。
2、运维监控中心与数据中心分离。
3、数据集中与分级管理相适应。
4、具备良好的可扩展性和可用性。
（二）、某银行支付清算系统运维管理的主要变化
1、从未来将形成多中心的格局和提高运维管理和业务连续性管理水平的角度考虑，运维监控系统的建设依照“多中心一体化（多个物理中心协同形成一个大的逻辑中心）”的思路进行设计，支持一体化的监控、运行、维护等；
2、支持运维中心和数据中心分离；严格数据中心的管理，只允许系统维护人员进入核心运行区，运维监控的支持、管理和操作人员通过远程、甚至异地访问和监控系统运行，并执行运维管理流程的各项工作支持分级运维；
3、增加应用监控等运维功能，提供客户服务、技术论坛及服务支持网站等，改进对清算中心和参与者的技术支持。
3.7.3备份系统建设方案
某银行支付清算系统备份系统建设路径分为上海中心投产时的备份系统建设和北京中心建成后的备份系统建设。某银行支付清算系统在上海中心投产时，支付系统北京中心尚未建成，为确保支付系统的备份能力，应以上海中心作为生产中心，无锡主站作为应急备份中心。
北京中心建成后的备份系统建设目标是将生产中心从上海中心切换到北京中心，从而形成北京中心作为生产中心、北京主站作为同城备份中心和上海中心作为远程备份中心的“两地三中心”最终格局。
备份系统建设方案采用两地三中心方案，具体以主机平台数据备份方案图为例，如下图所示：
为实现城市处理中心CCPC集中备份系统，CCP日常需将支付报文传输平台CCPC区域网关处理软件与辖内参与者接入端软件之间配置信息定时（例如每日日终后）通过报文传递至NPC，NPC集中存储各CCPC与辖内参与者中间件连接方式等系统配置信息，在CCPC发生灾难时导入CCPC集中备份系统，保证参与者正常接入。
图28 城市处理中心CCPC系统备份图
某银行支付清算系统直连参与者MBFE仅部署支付报文传输平台接入端软件并支持水平扩展方式部署，参与者可通过多台MBFE同时向支付系统发送业务。其特点是一台MBFE的故障不会影响到参与者的业务连续运行。
MBFE备份分为主用MBFE与备用MBFE。为防范单个NPC/CCPC故障导致从其接入的MBFE业务受到影响，参与者可选择主备MBFE分别接入主备NPC/CCPC的模式；主用MBFE（可以多台）与主用NPC/CCPC接入，正常情况下所有业务从该组MBFE进行收发；备用MBFE与备用NPC/CCPC建立连接，在主用NPC/CCPC出现故障时，改从备用MBFE进行报文收发。
一般而言，主用线路接入NPC的参与者，备用线路宜选择接入备用NPC；对于主用线路从CCPC接入的全国性商业银行，则可选择从其备用数据中心所在地CCPC作为备用接入；对于区域性的城市商业银行或农村信用社，也可以根据自身实际情况来选择是否建立备用接入线路，确有需要的，可以选择从人民银行当地的同城转接中心建立备用接入线路。
本章确定了系统的设计原则，进行了系统的总体架构、功能结构、数据库设计、网络拓扑结构、接口设计及安全性设计。
第四章 系统测试
4.1 测试概述
系统测试的目标在于通过与系统的需求规格说明进行比较，检查软件是否存在与系统规格不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规格说明所指定的要求。
4.1.1测试方案
1、提交测试申请
项目经理在系统设计期间就要提交测试申请，申请测试资源，测试经理根据提交需求的规模和难易程度，决定测试人员，是否有必要在需求设计阶段介入，并反馈测试人员的投入及时间安排，指定测试负责人后，由测试负责人反馈测试内容的详细测试安排。确定后的测试申请放入项目组配置库。
2、搭建测试环境
测试环境一般存在数据库、标准化代码、服务、Ilog规则、应用部署等，由管理员从配置库中获取后更新至测试环境。
3、测试过程管理
（1）测试问题记录和修改
测试期间要修改缺陷，需要测试人员在问题管理系统中上报，并分配统一的问题编号（配置活动号），开发人员根据该编号从配置库中签出代码，在开发环境修改；问题修改完成后提交到配置库中，如果是分支开发，还需要合并到主干及分支目录；配置项的每次变更都必须与活动号关联；进入冻结期测试后，所有修改必须由版本发布负责人审核后才可以提交配置库；
（2）开发环境的更新
测试期间，要求项目组成员保证自测正确后，不定期更新开发环境。
（3）测试环境的更新
测试环境系统管理员更新。若遇到测试环境出现阻断性错误，影响测试进行时，需征得测试组同意后及时更新测试环境。
4. 提交测试报告
测试完成后，完成本次测试的测试评估报告和测试数据采集，提交给开发组进行后续的问题产生原因分析和总结。
4.1.2 测试技术
测试方法有白盒测试和黑盒测试两种。本次测试以黑盒测试为主，测试覆盖某银行支付清算系统的所有子系统的各功能点和主要业务流程。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。黑盒测试法注重于测试软件的功能需求，主要用来发现下列几类错误：
1、功能不正确或遗漏；
2、界面错误；
3、数据库访问错误；
4、性能错误；
5、初始化和终止错误等。
4.2 测试方法
在测试过程中主要采取以下测试方法：因果图法、等价类划分方法、边界值分析方法、错误推测法等手段，经过几轮的回归测试，使被测产品达到预期目的。
（1）因果图法：采用因果图法，以需求设计说明书为依据设计业务测试流程图和测试案例。
（2）等价类划分法：对业务流程进行等价类划分，测试用例应是业务主流程和流程主分支的最小集，所有的判别分支都能被覆盖，在流程覆盖的同时，完成等价功能的测试。
（3）边界值分析法：在功能测试中，针对功能说明中的输入输出域，进行边界值和极限值的设计和测试。
（4）错误推测法：采用逆向思维方式，结合以往测试经验和直觉设计软件在功能和流程上可能存在的各种错误，进行容错性测试。
4.3测试结果与评价
4.3.1 系统测试
通过对系统本身、系统组、用户、逻辑卷及文件系统、系统软件等进行了实际测试，其中系统测试要求见下表：
| 平台 | 名称 | 版本 | 验证命令 |
| AIX | AIX | > 6.1 | oslevel -s |
| LINUX | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 11 | lsb_release -a |
| JAVA | java | > 1.4 | java -version |
4.3.2 系统测试用例
测试从商业银行的角度，检查大额支付系统的运行情况，试图发现系统程序与用户需求存在不一致的过程。现以A银行从B银行拆借一笔大额资金为例，按照下述流程进行：
B银行操作人员a通过支付清算系统录入需求--->操作人员b复核操作人员a的操作--->业务主管领导c授权此笔额度的往账生效--->支付清算系统生成加密报文传输到当地人民银行--->当地人民银行查询B银行资金头寸并转发到人民银行清算总中心--->如果头寸足够则清算此笔往账并发送回执，如果头寸不够则报警并等待。
4.3.2 结果与评价
经过测试，某银行支付清算系统已完全实现预期目标，并能主动适应支付业务的创新和发展，使系统能以较小的代价快速适应业务需求的变更，满足未来发展的基本思路和政策取向。
4.4 小结
系统测试是通过实施预定的测试计划和测试执行活动确认软件的需求是否实现，是一个试图发现程序与用户需求存在不一致的过程。经过测试，某银行支付清算系统已完全实现预期目标，并能主动适应支付业务的创新和发展，使系统能以较小的代价快速适应业务需求的变更，满足未来发展的基本思路和政策取向。
其他的定制服务 下方联系卡片↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 或者私信作者
扫一扫
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
