银行IT应用体系架构最佳实践

年4月19日银行IT应用体系架构最佳实践文档仅供参考TOC\o"1-3"\h\z1 介绍 101.1 文档目的 101.2 目标 101.3 范围 101.4 目标读者 101.5 假设 102 应用体系架构的整体说明 112.1 应用体系架构的定义 112.2 对某银行IT战略的建议 132.2.1 应用服务战略 132.2.2 数据管理战略 132.2.3 基础设施战略 142.2.4 体系架构战略 142.3 应用体系架构设计中的关键点 142.3.1 银行的核心业务系统 142.3.2 客户信息的管理 162.3.3 企业应用系统集成(EAI) 172.3.4 管理信息系统 192.3.5 合理的应用系统功能 202.3.6 数据分布模式 212.3.7 应用分布模式 212.3.8 应引起关注的技术问题和技术管理问题 232.3.9 IT规划的管理机制问题 243 应用体系架构的整体设计 253.1 应用体系架构的整体设计图 253.1.1 应用体系架构中的系统功能和全行的应用需求的对应关系 263.1.2 对核心业务体系系统的说明 283.1.3 总行层面的系统总览 313.1.4 一级分行层面的系统总览 324 建议的转型计划大纲(待项目计划出) 344.1 某银行现有的应用系统和目标模式的差异分析 345 核心业务系统的目标功能模式 365.1 核心业务系统核心层的目标功能 365.1.1 系统的总体功能和特性 365.1.2 客户信息管理功能 365.1.3 帐户管理功能 375.1.4 产品管理功能 405.1.5 帐户交易管理功能 415.1.6 报表管理功能 425.1.7 出纳/分行交易管理功能 435.1.8 管理和监控功能 445.1.9 现金管理功能 445.1.10 总帐功能 455.1.11 应用安全管理功能 465.2 核心业务系统的业务层的目标功能 475.2.1 核算管理及账务体系 475.2.2 内部资金管理 495.2.3 结算管理 495.2.4 银行卡业务的管理 505.2.5 现金管理 505.2.6 凭证管理 505.2.7 国际结算 515.2.8 对各级机构作业的支持 515.2.9 营运风险控制体系 525.3 金融产品提供 555.3.1 公司业务(仅包含帐户处理) 555.3.2 个人业务 555.3.3 银行卡业务 555.3.4 现金业务 565.3.5 资金调度业务 565.3.6 票据清算 565.3.7 外汇买卖业务 565.3.8 中间业务 566 大前置的目标功能模式 586.1 大前置系统的建设目标 586.2 大前置架构说明 606.3 大前置系统功能说明 616.4 前端设备 636.5 技术考虑事项 637 某银行信息总线目标功能模式 647.1 信息总线的整合层 657.1.1 概述 657.1.2 系统接入子层 667.1.3 输出整合 697.1.4 BPM 707.2 门户技术 807.2.1 门户要求 807.2.2 两级门户个性化实现方案 817.2.3 多种前端接入实现方案 837.3 统一的安全认证机制 847.3.1 建立客户信息管理系统 847.3.2 建立认证LDAP服务器 857.3.3 实现单点登录 858 MIS系统目标功能模式 898.1 数据仓库架构 898.1.1 图1数据仓库一般架构源系统 898.1.2 ETL 908.1.3 操作数据存储(ODS) 918.1.4 多维数据存储(数据集市) 918.1.5 OLAP 928.1.6 数据挖掘 938.1.7 表现层 958.2 管理信息系统体系结构 968.2.1 管理信息系统数据仓库体系架构 968.2.2 管理信息系统演进策略 1018.3 分析型客户关系管理应用架构 1038.3.1 分行层面的客户区分 1058.3.2 分行层面的多维利润分析 1068.3.3 分行层面的客户需求分析 1068.3.4 分行层面的客户行为分析 1078.3.5 分行层面的交叉销售分析 1088.3.6 分行层面的客户满意度分析 1088.3.7 总行层面的客户区分 1098.3.8 总行层面的客户需求分析 1098.3.9 总行层面的多维利润分析 1108.3.10 总行层面的市场趋势分析 1118.3.11 总行层面的重大事件分析 1118.3.12 总行层面的客户行为分析 1128.4 管理会计系统应用架构 1138.4.1 全面预算 1148.4.2 多维的成本盈利管理 1158.4.3 帐户的利润贡献度计算 1158.4.4 产品/客户的利润贡献度计算 1198.4.5 渠道的利润贡献度计算 1198.4.6 机构的利润贡献度计算 1198.4.7 业绩考核指标 1198.5 资产负债管理信息系统应用架构 1228.5.1 市场风险分析和预测 1238.5.2 利润分析 1278.5.3 内部资金转移定价(FTP) 1298.5.4 资本管理 1318.6 信贷风险管理信息系统应用架构 1328.6.1 信贷风险管理信息系统数据仓库 1338.6.2 信贷风险模型 1348.6.3 信贷风险管理决策支持 1418.6.4 信贷风险管理监控及报表生成 1429 信贷业务和风险管理系统目标功能模式 1469.1 信贷业务管理系统 1469.1.1 目标模式信贷业务管理系统特性 1469.1.2 信贷业务管理系统所支持的信贷关键业务流程的具体说明 1479.1.3 信贷业务管理系统的数据结构 1599.1.4 信贷业务管理系统的数据流图 1639.1.5 信贷业务管理系统的系统技术体系结构 1649.2 信贷风险管理系统 1679.2.1 信贷风险管理系统的功能模块和整体逻辑视图 1679.2.2 信贷数据集市及数据管理系统 1709.2.3 联机数据分析及报表处理系统 1759.2.4 信贷业务管理系统和信贷风险管理系统的接口 17810 操作型客户信息管理 17910.1 操作型客户信息管理平台的总体目标规划 17910.2 CIF的设计方法 17910.3 操作型客户信息结构模型分析 18010.4 本规划操作型客户信息设计 18310.5 操作型客户信息存放方式 18410.6 操作型客户信息的建立和维护 18611 资金管理系统的目标模式 18711.1 资金管理系统目标模式介绍 18711.2 资金管理系统对资金流程的全线支持 18711.3 资金管理系统功能介绍 18811.4 资金管理系统的数据结构介绍 18911.5 资金管理系统技术体系结构介绍 19012 个人理财系统 19212.1 目标模式的个人理财系统支持的业务: 19212.2 个人理财系统整体应用流程 19312.3 个人理财系统功能模块 19413 ERP系统 19813.1 总帐管理 19913.2 人力资源/薪资管理 20013.2.1 目标模式的人力资源管理系统功能 20013.3 固定资产管理 20313.4 采购管理 20413.5 库存管理 20613.6 合同管理 20813.7 ERP系统与其它系统的接口 20813.7.1 ERP系统与OA(办公自动化)系统的关系 20813.7.2 ERP系统与其它MIS的关系 20813.7.3 ERP系统与业务支持系统的关系 20914办公自动化系统的目标应用体系结构 210企业办公自动化的主要功能模块 210某银行的办公自动化系统的主要基础功能模块 210某银行的办公自动化系统的主要应用功能模块 213对某银行办公自动化系统功能模块的建议 214与其它系统之间的信息交换结构图 215某银行的办公自动化系统的基础平台的选择 21515档案管理的应用体系结构 218档案管理在某银行IT应用体系中的作用与地位 218某银行档案管理系统应具备的特点 218档案管理与其它系统的关系 219档案管理与办公自动化系统的关系 219档案管理与银行业务系统的关系 219档案管理与企业信息站的关系 219档案管理系统的主要功能模块 219数据录入、压缩、转换与存储 220档案检索 221档案信息发布和使用 222档案修改与销毁管理 223系统管理 223档案管理系统的系统流程 223某银行档案管理系统的数据中心建设 22516投资管理、证券、保险和基金业务系统 227投资管理 227投资管理的应用范围 227投资管理的系统架构 227投资管理系统的功能需求 228投资管理系统的主要接口 228证券与基金管理系统 229证券与基金管理系统的业务特征 2291介绍文档目的目标范围目标读者本文档的目标读者为对于某银行当前IT系统有一定了解的IT管理人员及系统管理人员。假设在本文档的制作过程中采用了一些前提和假设,这些假设将作为文中分析与结论的重要依据。所做假设如下:所提供的关于IT系统及其相互间关系的信息是准确的;关于每个系统的目的及功能的描述是准确的;调查及访谈结果符实。应用体系架构的整体说明应用体系架构的定义本文所指的应用体系架构是支持某银行业务体系架构的相关应用系统的体系架构。在<某银行业务体系架构最佳实践>一文中指出,银行的业务活动,能够分为:战略规划、资产负债管理和市场风险管理、信贷风险管理、财务管理、客户关系管理、渠道管理、产品管理、营运管理、人力资源管理共九个方面。银行的各类应用系统,在功能上应该直接针对以上九个方面的业务活动的需求或者为这些业务活动提供相关信息。在应用体系结构上,应该和业务体系结构的要求相适应。银行的大部分应用系统,是为银行的营运服务的。一般零售和批发的银行的营运包括本外币条件下的以下操作,这些操作形成了某银行的应用系统在银行营运方面的基本需求:面向客户,提供各种金融产品和服务,包括零售银行业务、对公银行业务和卡业务等操作型的客户信息管理银行提供金融产品和服务的分销渠道的运作核算和帐务体系营运风险控制体系,包括柜员管理、额度管理、业务处理流程的规范、内部审计等结算处理清算处理现金管理票据管理贷款的审批和管理资金运作柜台业务处理流程对外接口的处理某银行作为一家企业,自然需要有:企业基本资源的管理,包括机构、人力资源、采购、营业性费用等方面的管理办公的自动化档案的电子化管理银行的管理,自有它的专业特色,正如在<某银行业务体系架构最佳实践>一文中指出的:资产负债管理和市场风险管理财务管理中的银行管理会计银行客户关系管理信贷风险管理需要专门的银行管理信息系统的支持。鉴于某银行有决心发展混营业务,逐步建设成为金融集团,就还应该考虑:投资活动的营运和管理个人理财金融产品的管理营运和管理证券业务金融产品的营运和管理保险业务金融产品营运和管理因此,在应用体系架构的规划中,要考虑上述的业务操作和业务管理职能在IT的环境中,如何实现及如何互相交互方面,为这些需求的实现和今后系统功能的扩充建立基本的框架。在解释毕博对某银行近三年的应用体系架构的规划之前,先要阐述毕博对某银行IT战略的建议。对某银行IT战略的建议某银行需要开发稳定的IT战略。在这个过程中,需要将业务战略所需的IT环境与现有的IT环境进行比较,从而识别当前的IT环境多大程度上适应业务战略,然后识别差距、开发能弥补缺陷的IT战略、确定IT的工作方向,以启动IT战略的实施。毕博的方法论认为,完整的IT战略包括以下五个方面:应用服务战略数据管理战略基础设施战略体系架构战略IT组织和IT管制方式的战略其中”IT组织和IT管制方式的战略”不在本项目的范围内。在本项目的进行过程中,随着对某银行业务战略和愿景认识的深入、对某银行IT现状的深入,毕博建议以下的IT战略作为全行的IT战略应用服务战略充分利用现有系统的功能和潜力最大程度地使用自动的工作流管理优化应用系统的客户服务能力和效率在全行逐步实施业务规则管理创造一个稳定、可扩展的开发环境数据管理战略实施管理信息/决策支持提供操作型和分析型的所有客户信息3)逐步形成全行的一致的数据储存技术和数据储存方式基础设施战略将全行IT规划、开发和管理的过程规范化需要开发完整的营运维护方案体系架构战略规划和实施银行应用体系架构规划和实施银行数据体系架构规划和实施银行安全体系架构规划和实施银行技术体系架构应用体系架构设计中的关键点本节所述的关键点,既是某银行IT规划中所应处理的重点业务或技术问题,也是毕博对整个规划的设计的基本起点。在介绍整体的应用体系结构规划前,读者很有必要了解这些关键点。银行的核心业务系统按国际通行惯例,一般银行核心业务系统的分类较专——针对零售银行、批发银行、信用卡(国际贷记卡)、投资银行等提供专用系统,很少有大一统的系统包罗所有的业务。这不但体现在国际上主要银行的系统部署的实践中,也体现在国际上产品化的核心业务系统的分类上。道理很简单,因为业务的性质不同,所需的系统功能和技术架构会有不同的侧重点。举例说,零售银行一般面向的客户是个人和规模较小的商业客户,因此业务重点是临柜、ATM、电话银行、小额支付等。由于此类业务的特点是客户和帐户量大、交易量大、金额小、需要通存通兑和7X24小时服务等,因此在考虑系统效率、数据储存、系统与渠道接合这些方面会是设计的重点。对批发银行而言,客户和帐户量与零售银行比较小,但交易金额是比较大的,因此系统的设计的重点在于交易的安全、交易流程的控管、资金结算的快速、资金管理服务的多元化、信贷风险管理的严谨等方面。从应用来说,范围包括对公存款、贷款、贸易融资、外汇、资金市场等。由于面对对公的客户为主,因此批发银行系统对于”7X24”的需求会稍低一点。至于信用卡系统,一般是独立于核心应用业务系统的。因为信用卡的发行机构不一定是银行,而且以这产品的特点来说,信用卡户的额度完全基于个人的信贷能力,也不一定需要在银行有帐户。一般来说,信用卡系统分为发卡和代理经营两大类,所需的系统是业务代理系统和业务处理系统两大类。某银行的DCC项目规划,将核心业务系统CCBS规划为对私业务、对公业务、卡业务、代理业务、理财业务、证券和保险业务的大一成的系统,这既反映了某银行对建设与数据中心的宗旨相一致的核心业务系统的决心,也反映了某银行对企业应用集成技术(EAI)(EAI技术,请参见本节第三段的论述、本文的正文论述和附件的介绍)的使用尚不熟练。基于此,毕博对某银行的核心业务系统的规划的基本点是:CCBS将本外币的对私和对公金融产品的帐务处理、操作型客户关系的处理、对私金融的业务流程、核算和帐务体系集成为一体是可行的也是合理的。其它类型业务的核心系统,考虑另建或另购系统实现,并经过信息总线连接起来,成为逻辑意义上的大核心业务系统。核心业务系统除了所提供的金融产品外,该系统的核心机制也是很重要的,毕博专门对该机制的国际最佳实践作了介绍,希望对某银行的CCBS系统的开发有所帮助。客户信息的管理

不论是什么类型的系统,银行现在都会相当讲究如何配合客户关系管理的观念、怎样推进”面向客户、面向管理”,以协助银行去管理和挖掘客户和产生新的高盈利的业务。现在国外银行的应用系统都强调支持中央客户信息,每个客户在银行系统内都是一个唯一的个体,而所有客户的信息都是与所有的业务应用子系统共享,确保银行的每一个用户都能够基于自身的权限看到客户的所有资料,从而提供更集中的控管和优质服务。因此一个设计优秀的客户信息系统是现代化的银行系统的一个非常重要的基础。

国外银行的客户信息比较注重怎样支持业务营销、客户关系管理、风险管理等各方面的需求和应用,因此客户信息的定义会根据数据分析(MIS、DSS、CRM等系统)的需要而增加了许多数据项,并让用户在有需要的时候新增自定义字段。这个对于未来的管理信息、决策支持、商业智能等系统来说是一个非常重要的铺垫,没有充分、一致的数据来源,再好的数据挖掘和分析工具都是派不上用场的。而且基于以客户为中心的结构,系统更容易提供综合理财类的新兴业务和综合对帐单等。本规划是完全基于以客户为中心的设计思想,因此必须有CIF系统的支持。从当前银行业的发展趋势来说CIF系统应该是一个独立的统一心系统,其它系统应该只是经过标准接口使用该系统。但某银行的CIF系统的建立已由总行统一规划和实施的DCC项目所包括,是CCBS核心业务系统的一部分,毕博尊重这样的决定。无论CIF系统以何种方式存在,全行其它系统只是经过与CIF系统的接口去访问CIF,而不需要建立自己的CIF系统。以下是我们某银行CIF系统建立的一些建议。考虑到某银行客户规模这么大,客户种类繁多的银行的中央客户信息,如何在总分行的结构下存储和使用,以怎样的步骤进行实施,和其它系统及信息总线的关系是什么,也是本次应用体系结构规划的总要内容。规划的详细内容见第章操作型客户关系管理。企业应用系统集成(EAI)银行的应用系统,无论先期规划得多么有远见、项目执行得多么有出众,终究会出现IT应用及基础设施不能满足日趋迅猛的市场变化的需求的现象。遇到这种情况,国际上最佳实践的银行往往首先奉行整合的技术路线。她们将使用系统整合技术,挖掘现有应用系统的潜力作为第一选择,这就需要使用EAI技术。毕博建议某银行全面、系统地使用EAI技术,来联系横贯整个企业的异构系统、应用、数据源等。EAI是将进程、软件、标准和硬件联合起来,在一个企业内或更多的企业系统之间实现无缝集成,使它们就像一个整体一样。EAI一般表现为对一个商业实体的信息系统进行业务应用集成,或者是为不同公司实体之间的企业系统集成。由于EAI是建立一个灵活的、标准化的企业应用底层架构,能够允许新的基于IT的应用和商业处理能够更容易和更有效的被部署。EAI涉及到结构、硬件、软件以及流程等企业系统的各个层面:业务过程集成应用集成数据集成集成的标准:要实现完全的数据集成,必须首先选择数据的标准格式。集成的标准化促成了信息和业务数据的共享和分布,构成了企业应用集成的核心。平台集成:要实现系统的集成,底层的结构、软件、硬件以及异构网络的特殊需求都必须得到集成。平台集成处理一些过程和工具,以保证这些系统进行快速安全的通信。在EAI技术的支撑下,现有的应用系统在全行的范围内成为了特定的功能模块。例如:对于金融市场上利率和汇率的信息,银行的资金系统、信贷系统、管理信息系统中的ALM管理、财务会计管理等都需要这类信息。银行一旦建立了市场数据汇入接口,就不必为所有需要此信息的系统都安装接口,而能够经过将数据接口视为全行的标准功能模块,将其挂接在今后的信息总线上,供各个系统共用。经过进行EAI,银行能够建立系统整合的基础,从而在业务上获得下列好处:业务流程标准化、自动化、流程化利用EAI产品的自动化能力,确保业务流程管理(BPM)得到清晰的划分,局部的变化不再对企业整体运作造成影响。随着某银行各项业务变革的深入,参照国际先进模式,为提高业务操作的效率和效果,或进行前瞻性业务流程改造,对现行业务流程的变动将越来越频繁。如果对支持这些业务流程的系统直接进行更改,系统开发的周期、成本和风险都是相当可观的,而且会拖延业务变革的步伐。经过EAI的BPM,将原有系统所支持的基本业务操作单元视为全行的通用标准模块(如支付、账单处理等),在标准模块的基础上配置新的业务流程,全行系统的灵活性、有效性将得到极大的改进。集成的,基于WEB的基础设施和通用用户体验银行能够对后台系统的数据传输进行控制,并在基于WEB的企业门户中显示这些信息。降低系统实施和运作的成本EAI架构能够更加灵活地根据战略市场转移添加或者改变业务能力,同时在现有系统中对数据集成进行有效的管理。降低对于多个系统的依赖银行能够对那些功能和数据重复的系统进行有选择的淘汰和整合,从而降低旧有系统的人力操作成本。经过进行EAI,某银行能够在技术上获得下列好处:EAI解决方案带来的技术好处主要是建立在这样的一个事实之上:该架构是能够重复使用的,具有很高的升级性和可配置性。它结合了以下的能力:方便地集成新的组件和系统;高度集成的工作流引擎,能够实时地对面向客户的业务流程中的任何事务进行有效的管理和监控;通用消息总线,在应用系统之间传递消息;经过连接器将分散的应用系统整合为一个单一、有效的事件驱动系统。在数据大集中和大前置建立后,根据所选用的形式不同,这时应该规定哪些数据保存在中心数据库中,并制定相应的交换格式和交换方法。由于这些与所选择的方式以及以后的某银行信息总线有很大的关联性,甚至有可能与未来的某银行信息总线融为一体,因此这里不详细展开讨论,而在下面的信息交换平台中提及其可能用到的技术。在中心数据仓库逐步建立后,我们应该建立与之相配套的各种系统,例如客户信息系统,对中心数据库进行挖掘分析的系统、信贷系统、风险预警、国际结算等等,这些系统的建立与后面的某银行信息总线所采用的技术有很大的相关性,总而言之,必须能够与某银行信息总线很好地互连。管理信息系统某银行使用管理信息系统(MIS)一词,主要指的基于数据仓库技术,面向不同的银行管理主题的,对集中的业务数据和其它银行内/外数据的综合分析、处理和应用的系统。在本规划中,管理信息系统被划分为分析型客户关系管理系统、管理会计系统、信贷风险管理系统、资产负债管理信息等系统。(其中信贷风险管理系统和信贷业务系统的关系紧密,一同在第章中论述)我们对管理信息的这种划分,直接和<某银行业务体系架构最佳实践>相对应。由于总、分行之间的管理职能有所不同,总分行管理信息系统对数据的要求也随着不同的管理需求有所不同。另外,由于越来越多管理决策需要详尽的、多维的支持信息;同时也要求管理信息系统能具备一定的分析预测和知识发现能力。合理的应用系统功能国内银行应用系统的开发经常发生的问题是:或者因为应用系统的需求来自于某个业务部门的业务操作和管理的需要而没有全行视野;或者需求没有前瞻性;或者作为需求的提出者的业务部门和作为需求实现者的技术部门的沟通问题;或者对国际同行同类系统的信息或参考不够,导致应用系统功能不足。对某银行而言,这种案例很多,例如:养老统筹系统、计算机设备管理系统、离休干部信息管理系统、机构信息系统等一批小型的企业资源管理系统,在功能上都属于ERP系统的范畴,不应独立开发、互不关联;信贷审批系统、信贷管理信息系统(CMIS),股票质押信息系统、坏帐核销系统、信贷清分系统、抵债资产系统等,在功能上都归属于全面的信贷业务管理和风险管理系统的范畴(参见)。本次某银行IT规划的重点,在应用功能的规划上。虽然对银行信息总线的规划,是解决某银行系统功能割裂的问题的一个方案。但如何使某银行的各个应用系统的功能逐步具备完备性、前瞻性依然是主体问题。为此,在讨论某银行IT规划主体方案(第三章)的基础上,本规划,从第五章起,详细介绍了国际先进银行的各个应用系统的具体功能要求,供某银行参考。数据分布模式银行保存大量的数据包括业务数据以至统计分析性的数据,也运行很多不同的系统(如业务处理系统、ATM、POS、客户服务中心、各种基于数据仓库技术的MIS系统等)。在毕博建议的IT规划中,不是所有的数据都存放在总行或区域数据中心。某些数据(包括业务数据和统计性数据)可能需要存放在分行以至网点的服务器中。数据存放在分行或网点可能是因为这些数据纯粹是本地的数据而没有存放在总中心或区域数据中心的价值;也可能是为了提高交易处理效率;也能够是为了在系统离线时(与总中心或区域数据中心通讯断掉)进行必须的业务处理。银行的数据从种类能够分为系统数据、业务数据和管理数据;从地域方面能够分为全行数据与本地数据(分行、网点)。在本次规划中,总数据中心或区域数据中心与灾难备份中心保存几乎所有的系统数据、业务数据,也包含总行层面的数据仓库与其它后续系统的数据。在分行层面主要保存系统数据和本地业务数据,部分的本地业务数据也会存放在总数据中心或区域数据中心。在分行层面还保存了部分存放在总数据中心或区域数据中心的业务数据,主要的原因是在于提高交易的预处理能力,减小传送主机的交易量及通讯量。如柜员在柜面终端键入了客户号或帐号时需要马上显示客户或帐户姓名,以方便柜员核正确话,该等数据存放在分行是能够更快的把资料送到柜员终端,也不需要到主机提取。原则上,这些数据是不应该经常改动的。但当这些数据被改动时,分行保存的相关数据也应该同时被改动以保持数据的一致性。但帐户余额等敏感就不应该存放在分行里面,以减低银行所面对财务风险。由于部分系统的静态数据是同时存放在数据中心和各个分行的,因此需要制定一套数据同步的过程,建议是在每天的日终处理后联机交易开始前进行静态数据的同步。这个时间点也是分发新的程序到每个分行的最佳时机。保证数据同步的另一套机制是依靠某银行的信息总线,详细情况能够参看本规划的第章。应用分布模式某银行是经过不同的系统来完成所需的操作(包括业务处理和后续的其它处理)。银行在实施集中以后,不同的应用将会分别运行在总中心,区域数据中心,分行以至网点。决定各个应用运行的地点取决于几个条件:应用的性质(本地应用或全行应用)、使用数据性质、接口系统要求等等。某银行的应用应该是按该应用的特性分布在不同的中心、地方。例如:总数据中心或区域数据中心是运行核心业务系统的环境,也是总行MIS(即数据仓库、决策支持系统和商业智能系统)运行的理想环境,因为这些系统都需要全行的数据。网上银行的用户能够经过互联网来进行操作,也适宜在总数据中心运行。由于手机用户的流动性,手机银行系统也应该在总数据中心运行。因为客户关系管理(CustomerRelationManagement,CRM)系统需要管理分布在不同分行的集团客户,也建议在总数据中心运行。由于一级分行是连接总数据中心的枢纽,其地位非常重要。在大集中模式下分行的角色在起了很大的变化,因此分行需要考虑一个很完善的”大前置”系统来负起与总数据中心、本地系统、支行/网点与本地其它金融机构的通讯连接。在后面会讨论到”大前置”系统的基本功能要求。ATM/POS是比较适合在分行里面运作,主要的原因是这些系统都需要跟本地其它金融机构(如金卡)的系统联系。银证转帐系统也需要跟券商进行通讯而比较适合在分行运作。中间业务平台也是需要很多的本地通讯功能,在分行运作是比较理想的。电话银行和CallCentre系统就比较适合在分行运作,主要的原因是在于中国地方比较大,所使用的方言也比较多,很多时候拨近来的客户不一定很懂普通话,在分行运作对总体操作有好处。操作员也能够更亲切的提供优质的服务。但有些银行倾向把电话银行和CallCentre系统在总数据中心里面运行,这也是能够的,但需要解决了语言方面的问题,譬如电话银行除了提供普通话的服务外,也可能需要提供其它多种常见语言(如广东话、上海话、四川话、潮州话等等)的服务。CallCentre由于是客户与操作员的直接对话,懂得当地的语言与俚语是比较理想的。分行里面的报表生成系统是指在实施了集中处理后在总数据中心或区域数据中心可能会把很多的业务数据下发到各个分行,以便生成所需的运作报表。总数据中心只传送原始数据会减轻网络的传送量,也让分行更有弹性来生成本地报表。如果银行的策略是在总数据中心生成所有报表后发送到分行打印的话,则分行的报表系统只需要具备接收、打印和重打功能。支行、网点当然只需要运行柜面系统,也可能需要接收从分行送过来的报表进行打印。应引起关注的技术问题和技术管理问题本次IT规划的主体是系统的应用体系结构和应用功能规划,不着重于系统的各项技术问题。这里我们简要的强调一下应用体系结构下,个个应用系统在开发和实施过程中应注意的技术问题和技术管理问题。某银行应该努力使得各个应用系统在以下的技术特性上,达到最佳的综合分值:系统的安全性系统的适应性——适用于多种软硬件平台系统的扩展性——模块化和参数化系统的稳定性、可靠性、可用性系统的开放性——相对稳定的核心与不断丰富的外围功能的统一系统的配置灵活性系统吞吐量系统效率系统的可维护性某银行应该努力使得自己在各个应用系统的开发过程中,逐步做到:一致的开发平台和开发工具一致、成熟的软件工程方法一致、成熟的软件过程方法IT规划的管理机制问题要使IT规划能长期的起到反映业务的驱动力、指导IT开发和建设工作的作用,IT规划本身需要得到长期的维护,以反映最新的业务环境的变化、某银行业务操作能力的变化、某银行IT系统的发展所带来的变化等,对全行的应用系统所带来的不同需求。这需要某银行有一套成熟的IT规划的管理机制,这套机制的几个要点是:在IT规划部门和各个业务和技术部门充分沟通的基础上,确保被普遍认同的IT规划,能对全行的IT工作起指导作用跟踪和记录外部业务环境的变化、全行业务战略的变化、全行业务能力的变化和全行的应用系统的变化,及时评估这些变化的影响,特别是对应用系统需求的影响除了定期(建议以一年为单位)审视、修订和完善本行的IT规划外,但发生重大的内外部环境、战略或能力的变化时,适时修订IT规划需要行级领导和IT主管领导的大力支持、适度介入,并给于方向性的指导和合理的资源配置的保证成熟的IT规划方法论合格的IT规划人员和IT规划团队,对团队成员要仔细甄选应用体系架构的整体设计应用体系架构的整体设计图这是毕博对某银行IT应用规划的整体架构。上图中,蓝色代表核心业务体系中的关键应用系统。核心业务体系的范畴和某银行正在进行的以CCBS为核心业务系统的DCC规划的范畴大致相仿。但在局部上的考虑,二者有所不同。红色代表某银行的总行和一级分行的信息总线。绿色代表除核心业务系统以外的,某银行的其它关键应用。这些应用往往有自身的体系结构,其服务器和客户端分布在总分行。黄色代表某银行的对外接口部分,大致分为五类:外联交换型接口、终端驱动型接口、增值服务型接口、中间/特色业务型接口、全国性业务接口。总行的核心业务系统以外的其它关键应用,在物理上存在于某个数据中心里,但在逻辑上属于总行层面。总行和数据中心业务职能的不同决定了它们各自所辖系统的功能的不同。应用体系架构中的系统功能和全行的应用需求的对应关系应用体系架构中所涉及的系统,其功能应该涵盖第一章中总结的某银行的各类应用需求。本规划中,这个对应关系如下表所示:系统名称所实现的业务需求备注核心业务系统体系面向客户提供各种金融产品和服务,包括零售银行业务、对公银行业务和卡业务等大部分对公业务,在核心业务体系只完成账户处理部分。银行提供金融产品和服务的分销渠道的运作核算和帐务体系营运风险控制体系,包括柜员管理、额度管理、业务处理流程的规范、内部审计等结算处理清算处理现金管理票据管理外汇处理柜台业务处理流程对外接口的处理操作型的客户信息管理信贷业务管理信息系统和信贷风险管理系统贷款业务操作和信贷风险管理资金业务系统资金运作全行ERP系统企业基本资源的管理,包括机构、人力资源、采购、营业性费用等方面的管理全行办公自动化系统办公的自动化电子档案管理系统档案的电子化管理MIS系统资产负债管理和市场风险管理财务管理中的银行管理会计客户关系管理系统银行客户关系管理本规划中,将分析型客户关系管理系统归为MIS系统投资管理系统投资活动的营运和管理全行个人理财系统个人理财金融产品的管理营运和管理证券业务系统证券业务金融产品营运和管理保险业务系统保险业务金融产品营运和管理在本章应用体系架构的整体说明中,只阐述这些某银行今后的关键应用系统在应用体系结构中的地位和相互间的主要关系。这些系统的具体功能,是本次规划的主体内容,也是应用体系架构之因此包含这些应用的原因所在,同时也体现着本规划”借鉴国际先进经验,前瞻性、合理的规划应用系统功能”的原则。各个关键应用系统的具体功能规划,从本文的第五章开始,逐个做详细的介绍,我们称之为各个应用系统的目标功能模式。对核心业务系统体系的说明核心业务体系,从逻辑上能够视为一个大的应用系统,并与总行的信息总线相连。核心业务体系中的系统,包括某银行DCC项目规划中所提论述的CCBS、大前置系统、各个前端系统以及设备前置接口。和DCC项目规划的认识一致,毕博认为:在全国所有38个省市分行全部集中以后,北京和上海两个数据中心,以及今后可能会规划的更多的数据中心,在逻辑上可看作是一个数据中心。在数据中心的前置系统中,当前的清算和龙网均已消失,重要客户系统可能保留部分管理信息。某银行系统全国范围内实现通存通兑处理,总行的资金部门可实时理解各个分行的资金头寸的使用状况,实现实时的头寸管理和资金调度。省市分行的大前置机所连接的外挂系统有银联接口、电话银行、ATM/POS等自助设备的前置机。毕博建议的某银行的核心业务体系的架构,在以下几方面和某银行的DCC规划有所不同:1)接口的处理方面引发大量业务交易的接口,即终端驱动型接口、增值服务型接口,因为在当前的情况和实际应用中,由于要保证大前置的效率,因此需要的是快速反应,因此我们应该单独从专有技术例如TPMonitor来实现。其它的接口,即外联交换型接口、中间/特色业务型接口、全国性业务接口,强调的接口的公用性和集成性,应该挂接在总分行的信息总线上。2)对公业务:对公业务的操作流程,如信贷的审批、拟定、放款、管理和不良贷款的清收;票据业务的处理流程等,不在核心业务系统体系中实现。核心业务系统体系只实现对公业务的账户处理部分。3)操作型客户信息:操作型客户信息的各项内容,应该由首先由开户的分行管理,包括客户基本资料、客户组织资料、帐户信息、权限信息、和关联信息等。这里需要指出的是客户帐户信息包含客户交易往来帐户信息,其内容包括客户转帐的对方帐户、客户分公司的帐户等。操作型客户信息采用分布式存储的优势在于客户信息的易维护性,客户的信息修改、更新由开户行完成,不存在数据不一致性的问题。同时,如果在客户登录合法性校验的过程中,如果每次与操作型客户信息相关的请求都要送到数据中心进行客户信息的检查或查询,明显地会加重了网络返回负担。客户信息的同步问题,能够借用信息总线技术实现。具体的实现技术和实现,可参见第七章信息总线中的论述。总行层面的系统总览在业务体系架构中,总行层面的主要业务职能是:业务运作管理、客户关系管理、金融产品的开发营销和管理和信贷级市场风险的管理。相应的,总行层面的系统,包括全行的关键的应用系统的主机。核心业务体系的主机——CCBS核心业务系统,虽然位于各个数据中心,但由于各个数据中心的逻辑上的一体性,实际也是总行层面的系统。总行系统还维护着证券、外汇清算、路透牌价、国际卡、SWIFT、国际合作伙伴接口这些是真正独立于核心业务系统而存在的外挂系统,而这些外挂系统应考虑挂接在总行的信息总线上。一级分行层面的系统总览分行的主要系统是总行个关键业务系统的本地服务器或者客户端。在核心业务系统体系中,分行的大前置系统要负责本地渠道的交易提交和本地特色业务的业务逻辑,并和本地的操作型客户信息交互以使用全行的统一的客户试图管理客户的交易行为。分行信息总线上的外挂接口主要连接分行本地的外联单位,如人行现代化支付系统、证券、企业银行、中间业务的对手单位、本地特色业务的对手单位等。建议的转型计划大纲(待项目计划出)某银行现有的应用系统和目标模式的差异分析这些弊端主要体现在:1、各个系统独立运作,缺乏统一规划和实施,导致各自的软硬件环境差异巨大,系统间的信息共享十分困难。2、各个系统的数据格式没有统一标准,不同系统间的接口没有统一规范,导致各自的信息也就很难被其它系统有效利用。3、各个系统极少有具备快速调整、灵活扩展的能力,这导致系统的生命周期很短,即使不断在更新换代,却很难适应业务的快速发展。4、众多应用系统的软硬件环境的不一致性导致中国某银行的整个应用系统环境异常复杂,管理和维护十分困难。基于以上的分析以及多年和某银行合作的理解和认识,毕博认为,在保证数据集中,强大的企业运算的基础上,中国某银行的应用系统环境需要有一个统一、灵活、简洁、易于扩展的应用基础架构,从而为中国某银行的快速发展注入强大的技术动力。具体而言,毕博公司建议如下:在未来的三年中,中国某银行应尽快建立功能强大的全国数据中心,以实现全国数据的大集中,解决当前信息分立的问题。同时,考虑哪些数据应保存在中心数据库中,制定相应的数据交换格式和交换程序,并建立与核心业务数据相配套的各种系统,如客户信息系统、决策分析系统等等。还需要找到集中和分散的结合点。既要保证数据的有效的统一管理,又要保证各地业务的独立和自主性。然后建立一个中心级和省级两级的以工作流形式驱动的金融信息交换平台,在中心,使用这个平台,实现原有以及将来针对中心核心数据库开发的各种信息应用系统(如客户信息系统、数据挖掘系统等)与全国数据中心的互连通道;而在省级的金融信息交换平台则是各支行各种系统互连的基础平台;两级平台还能够作为总行和各级行的连接通道,能够负责数据的上传和下行,既能够保证数据集中到中心,又能够保证各省的独立性;既保护现有投资,也能够保证总行对各支行的管理和监控能力,还能够经过工作流驱动对现有的各种系统的调用迅速整合金融产品、快速响应市场的需要,从而提高中国某银行的整体竞争能力。核心业务系统的目标功能模式某银行新一代的核心业务系统,是DCC工程数据集中的主体。配合大前置系统、前端系统和各种设备前置,核心业务系统是某银行最大最重要的应用系统。它的功能覆盖了最广泛的业务操作线;它的数据是管理信息系统最主要的数据来源。本章主要强调核心业务系统的,某银行DCC规划称之为”核心层”的功能。”核心层”的功能是DCC规划较少涉及,同时又是核心业务系统最重要的功能。核心业务系统的外围功能,如它所提供的产品、在核心层功能之上的清结算流程、帐务核算体系、操作安全控制体系等,本章从简论述,并尊重某银行DCC的规划结论。核心业务系统核心层的目标功能seqlevel0\h\r0seqlevel1\h\r0seqlevel2\h\r0seqlevel3\h\r0seqlevel4\h\r0seqlevel5\h\r0seqlevel6\h\r0seqlevel7\h\r0系统的总体功能和特性tc\l0"002seqlevel0\h\r0seqlevel1\h\r0seqlevel2\h\r0seqlevel3\h\r0seqlevel4\h\r0seqlevel5\h\r0seqlevel6\h\r0seqlevel7\h\r0seqlevel0\r1\*ROMANI. Overallapplicationsystemsarchitecture" 核心业务系统应该至少包括以下几方面的功能:对客户、帐户、产品、公司客户进行唯一标识记录和维护客户、帐户和产品之间的关系支持多分行、多支行的运营支持多币种的交易和会计核算各应用模块间进行交互;应用可进行自提示这些交互支持对特定的交易或事件的第二用户授权在安全日志文件中,保存完整的审计跟踪信息以文字形式保留客户的建议将建议和报告保存在档案库中,并能够联机获取seqlevel1\h\r0客户信息管理功能这里的客户信息管理是操作型的,关于操作型客户信息管理的详细规划能够参见本规划的第章。某银行已经将CIF的功能规划进CCBS系统,故在此总结核心业务系统的客户信息管理应包含的功能集:tc\l0"002seqlevel0\r5\*ROMANV.seqlevel1\h\r0 Customerandaccountadministration"每个客户在全行范围内有唯一的客户标识号标准的客户数据的定义,灵活的客户标识号的支持机制:将客户号和属于该客户的账号,以客户信息文件(CIF)的方式建立起对应关系。支持全行约定俗成的账号定义规则。客户签名的图形样本应该保存在客户记录中。能够建立客户和银行的,基于交易历史的360度视图关系,包括客户所使用的帐户,所使用的金融产品,客户账户的合计余额和账户限额等。银行能够获得某个客户的所有账户的汇总余额状况能够根据客户类型,汇总余额状况,客户所拥有的帐户类型,客户所进行的交易的类型来区分客户或进行客户分组能够分辨和标识和某个客户有密切关系的其它客户的账号或子账号。能够将账户的拥有者和海外代理机构建立联系。在分辨客户间的关系时,系统支持使用各种自定义的分辨规则。能够灵活运用任何帐户中的参数来搜索和识别客户,能够在客户的相关记录上并入任何的文字评注。将客户记录和该客户和本银行的交互历史联系起来,这些交互历史包括:客户通信、客户投诉、客户在本行的交易历史记录、重大事件等能够将银行的市场和销售活动定向地通知特定的客户和客户组。全面的客户信息存储应该和CallCenter有接口,使得坐席人员能够实时掌握客户的状况,并将客户的反馈实时录入客户信息库中。 帐户管理功能帐户管理功能包括:将帐户号与一组灵活定义的必须录入的信息进行关连,包括:对应帐户存款,客户ID等账户余额能够经过各种交易渠道得到实时更新,而且余额对银行外部用户的显示是一致的,无论她们是使用电话、互联网还是纸质通知获得余额数字系统能够灵活定义账户的维护规则,无论是在账户类别的基础上,还是在个别账户的基础上严格控制账户的状态变更的操作。依据账户状态系统能够将账户进行分组或进行分析系统能够建立一种层次结构来进行账户限额的设定,例如,经过账户的客户属性、金融产品属性、所属的业务单元等,层层进行限额机制的设计有一套严格而定义灵活的机制保证账户在创立、访问、状态变更时的安全性。例如能够将账户密码安全地传递到所有者手中等。有一套灵活的账户结构机制,能够将核心系统的账户信息和其它系统的账户,如资金、投资系统等,联系起来能够累计存贷款利息,根据各种利息计算因素的变化,如到息日等进行自动重算经过和第三方产品的集成,能够实现以电子化形式存储用户签名,以进行账户交易授权的机制。其它账户管理和维护功能包括: 能够统计与一个产品关连的所有帐户 能够计算出清算过的余额,待清算的余额,和累计清算的余额 帐户的层次结构(比如,按客户,帐户类型,产品,分行,业务单元等分类) 能够建立同一客户不同账号之间的相互参照 能够管理信托帐户和其它涉及受益人的帐户 能够锁定或停止特定的帐户 记录帐户特定的警告代码 识别休眠或长期不被使用的帐户 识别”客户经理”或”客户关系经理”联机帐户查询的内容应包括: 帐户状态报告、交易清单、停付指令、完全的利息和费用的明细、自动的帐户关闭处理在帐单生成方面,系统能够: 从生成类型可分为周期性生成、临时生成、当某个特定事件发生时生成,或在给定数量的交易完成以后生成 显示该客户的其它帐户余额 进行帐单的复制和拷贝 记录交易细节的文字描述 提供其它相关的信息给客户生成计提利息和费用的详细通知,包括每个计提帐户利息和费用计算的完整的明细自动或根据用户请求生成用户定义的,预定义格式的帐户报告,包括:标准信函(比如利率更改)、非授权的或超额透支的建议、预先利息/收费通知,及应付日期/应付款通知、基金收取的确认、付款文件的交付、其它临时报告支持单客户的帐户组(包括两个或多个帐户)的计息,收费,和报表功能: 灵活的基于帐户组头寸和活动的其它收费安排 生成帐户组的状态,计提和活动报告记录客户帐户的户籍或法人单位支持支票帐户管理流程,包括: 生成支票簿和存折的打印指令; 记录支票簿和存折的定购和发送; 跟踪和校验当前和以往发行过内容的系列号; 记录客户的停付指令和监视帐户行为以定位”停付嫌疑” 监督和报告帐户活动并突出异常行为seqlevel1\h\r0产品管理功能 核心业务系统在产品管理方面应该至少包括以下功能:tc\l0"002seqlevel0\r3\*ROMANIII.seqlevel1\h\r0 Productmanagement"产品应该是:具有唯一标识的、由可变参数和产品组件来定义的、产品基本数据无需程序员和操作员维护、能够指定产品的起始日和到期日的、只给授权用户访问(除查询外)的、能够支持大量的计息和收费规则(这些规则取决于客户类型、帐户组安排、行业/产业代码、担保关系等)的。应支持的产品清单,见本章第三节。下面强调以下的几个产品:活期性存款账户(DDA),应能够区分有利息或无利息账户、吸引合格的余额进行存款或贷款、能够根据合格的标准(例如余额,活动,或者营业额)吸引费用和佣金、具备适度的透支限制定期存款产品包括固定期限定期存款,可变期限定期存款或在通知期后可赎回的定期存款贷款产品应有固定期限,可变期限或在通知期后可赎回几种类型,标识出附加贷款偿还的基础(即只付利息,本金加利息,只付本金,折扣,利息/附加费用),区分贷款偿还进度的种类,具备对超额,拖欠和过期的处理标准,保存抵押品的安全需求,能生成年度进展报告和报价单产品应该支持灵活的费率输入,能够实时的将市场数据导入核心银行系统支持分层定价,能够根据客户关系参数提出计价点、利率、付款条件、收费和费用减免、服务水平等具备灵活的收费机制,能够根据业务规则来设置产品的收费支持费用减免,能够设置参数以表明何时及多少费用应该免除。费用减免条件应该包括余额、客户类型、促销方式等等支持透支处理,能够收取帐户持有人的透支费和负利息。系统必须能够首先处理最小的名目,以减少透支发生的次数支持手工的收费更新,系统允许管理者、经理为某些客户或基于一些特定的帐户条件更新收费。收费更新应该能够设置为自动过期系统能够在产品粒度的层次上定义收费。包括同一产品大类中的不同产品类型,以及不同的服务水平参数帐户seqlevel1\h\r0交易管理功能tc\l0"002seqlevel0\r7\*ROMANVII.seqlevel1\h\r0 Transactionmanagement"支持存款/取款(包括现金)支持现金流动和分行间的现金管理,包括自动的审计追踪和总帐过帐关于开户/关闭帐户是的操作:开户时必须提供姓名、地址、签名图像、对帐单的发送频率;开户时能够自动地生成帐户号,也能够根据客户的喜好指定帐户号;关闭帐户应该能够标识帐户为关闭状态,而不是从系统中删除该帐户帐户维护时,可履行非金融性的维护任务或不产生日记帐条目的非银行的”静态的”交易支持自动的清结算功能,根据会计标准自动匹配全部的行内和行际的日记帐条目支持余额管理,系统应该为任何接触点提供一致的、实时的余额,而且为系统间的内部调帐提供改进的异常报表/试算表支持”锁定”选择,系统能够将任何帐户或子帐户关联为抵押帐户、指定帐户、欺诈检测和收款系统应该能够处理交易分解,系统接收存款并将存款分解到不同的帐户,系统也能够处理单笔存款、多个记息日的交易系统必须为每个条目提供过帐的功能系统能够设置规则以激活休眠的帐户。帐户只有经过手工处理并经过管理者的批准才能够被激活由于明显的和有意义的原因造成的异常,系统支持产生管理者异常报告在出纳工作站能够生成预打印的收据系统提供在线审阅报表及按需打印报表的功能。报表应该在线保留七年以供备查。所有的交易应该在线实时地被校验和过帐到核心银行系统系统为不同的交易类型提供缺省的交易字段和参数。系统能够灵活地定义每种交易类型的缺省的头寸和信息系统能够设置帐户休眠规则(手工或自动)系统能够创立、修改、删除、更新交易头文件并建立可共享的参数文件支持帐户之间转帐。经过接口,能够转帐到其它银行/由其它银行转入支持发布的/接收的直接借记指令支持撤消交易支持用于自动转帐的扫描设备支持银行支票/汇票的发行支持贷款的提款和到期支持贷款的偿还(预定的/非预定的)支持定期存款的存入和到期支持定期存款的提前支取(全部/部分)支持外汇管理的业务支持伴随性的事务,如利息收取/利息支付,费用和佣金的收取等支持创立和维护交易类型,并将其作为参数放入交易处理的定义支持在线交易的授权管理者或交易者能对大批量的及高风险的交易的必要组件进行检查和编辑,并能够实现多级授权控制。支持旅行支票的发行控制,监督控制和库存控制报表管理功能本系统应该至少包括以下几方面的报表能力:随机生成报表的能力,系统应该支持按非技术人员、多客户和多帐户的灵活的报表输出根据客户的要求提供客户对帐单,并能够以多种格式查看客户的存款和凭单交易系统能够对透支帐户生成收费帐单能够以往来行分组查看当前的余额系统能够定义、生成在线和归档的有效的管理报表。管理报表至少包括资产和负债管理报表、贷款和信用管理报表、现金流预测报表系统应该支持合并的帐户明细表以反映公司的全部帐户情况;设置交付期系统能够自动生成含有高亮度显示的断点和故障点的试算表,具有使会计记帐流线化的潜力系统能够根据参数驱动的方法提供”WHAT－IF”类型的预测支持定制报表,这些报表的范围和生成频率由需要报表的用户组确定,报表涉及的参数可能由其它相关的组设置系统能够生成正确的贷方分录报表并遏制不影响客户余额的行际信贷对人行和其它管制机构的报告出纳/分行交易管理功能当分行与总行间的通讯连接中断时,能够继续处理交易。脱机方式必须有明显的标示,而且能够支持在通讯恢复后的无缝联机系统能够将收款和收益转到受益人的帐户系统能够为其它银行和内部多币种交易处理长期性的指令交易系统能够处理交易回滚系统能够在柜员交易屏幕支持自由格式的,多行的文本注释系统能够将巨额交易或高风险交易的必要细节发送给监督者或原始的交易方以供评审和可能的编辑,系统还应该能够实行多级认证控制。交易的批准过程是经过工作流来实现能够在分行系统支持基于分行的光学字符识别和磁墨水字符识别,以减少账号和其它标识的手工录入系统能够让柜员或客户经理从交易清单中选择具体的描述,或使用自由格式的文本系统能够为取款和取款限额规定签名级别。级别应该是灵活的,分层的。新帐户应该继承规则系统能够建立、修改和删除收据数据管理和监控功能tc\l0"002seqlevel0\r4\*ROMANIV.seqlevel1\h\r0 Product-independentparametersandrules"系统应该在对帐户/帐户组/子帐户进行限额上具有灵活性系统能够根据风险或其它参数监控指定的帐户系统具备登陆和注销的安全机制。这是一套基于用户ID的安全体系,同时用户具备联机和脱机的系统访问能力系统能够在帐户设立后修改帐户细节,受制于双重控制。前台和后台均可对帐户进行更新在系统错误的消息文件维护方面,系统能够建立、修改和删除一条消息在系统帮助文本的维护方面,系统能够建立、修改和删除文本记录seqlevel1\h\r0现金管理功能tc\l0"002seqlevel0\r8\*ROMANVIII.seqlevel1\h\r0 Customers’cashmanagementfacilities"客户/关系经理能够监控/追踪现金余额、投资、绩效等方面的情况由客户或关系经理激活执行交易的指令由客户或关系经理初始化的报表识别,归档和提取全部的交易记录和其它系统输入记录,以进行安全/日志/审计追踪系统能够将银行余额转入非银行的货币帐户(比如,过夜资金市场)与业界会计标准的接口:系统能够灵活地遵守不断变化的国内和国际的标准,并能够经过XML与客户端的应用连接系统能够提供加速付款过程(收据、排序、存款、报表)的业务服务网上银行:系统能够提供以下的联机功能:客户功能、客户档案维护、帐户余额查询、停付指令、支票发行文件维护、支票不合理收费的调整请求客户支持:客户能够联机访问系统从银行查看帐户的预过帐情况seqlevel1\h\r0总帐功能自动过帐,比如从其它核心系统Globus付款系统自动过帐预算:系统能够按交易、客户、帐户或任何它们之间的组合进行报告和分派盈利率系统能够对任何作业的成本分摊到任何帐户或成本/利润中心能够创立帐户间的父子关系,能提供多层帐户关系分类帐应该整合在一起,任何对子帐目的改变能自动反映到父帐目总帐系统必须提供父账目下不同子账目的自动对帐功能系统应该能够在非更新模式下查看变更和条目(特别在利息过帐时)交易分类帐应该能保持开放一天以上而不影响随后的交易系统能够根据需要进行交易的批处理和联机处理系统能够处理回溯和远期的交易系统能够分客户地显示资产和负债的进程,并支持每天的资产负债报表系统能够自动生成所需的外部监管报告系统提供灵活的会计图表和日记帐处理以遵照会计准则的规定和所有权会计的规则系统为风险分担者提供灵活的报表生成能力;报表的修改应该由DBA来完成,而不是由编程人员来实现。管理报表必须与MIS应用相匹配系统能够提供风险模型检测分析、产品开发分析、客户盈利率分析等等系统能够取消/更正任何的交易详情,并自动重新计算利息计提、P/L分配和相应的日记帐逆转系统能够对完成的交易进行实时的更正系统必须能够支持对过去36个月的历史交易进行联机访问,并脱机保存48个月的历史交易根据业务规则,系统能够对结算余额在总额或净利的基础上进行每日的利息计提每日对帐应该提供试算平衡表、未定帐和对帐结束的能力系统能够备份交易日志和总帐余额,并能够将总帐和交易历史恢复至任何时间点系统能够根据可修改的业务规则自动生成支持交易的帐户系统能够根据灵活的参数计算帐户余额系统能够对送往总帐的批量交易使用可追踪的参照号系统在总帐中能够支持分行的实体系统能够将总帐信息导出至表格应用,比如EXCEL等系统能够显示日记帐的总额,打印、扫描日记帐应用seqlevel1\h\r0安全管理功能灵活的安全管理机制,授权用户能够方便地进行安全管理,并能够建立档案、具有审计能力。授权用户能够在总部进行安全管理能够将安全权限基于角色和子集分配给个人。能够在总部或远程进行权限分配能够生成详细的安全审核报告,指出何人、为何、何时和何地进行了安全设置,权限修改或删除能够运用灵活的报表机制,轻松地生成用户档案报告能够汇报和审核交易发生的特定地点系统能够用工作流支持二级安全访问或修改的授权系统能够基于时间参数强制注销。时间参数应该根据工作角色和功能灵活地设置系统应该支持LDAP安全基础架构。包括用户工作站的单点登陆系统应该保证分行按照用户登陆时的身份将操作员记录下来。系统还应该处理原始操作员离开终端但未注销的情况系统能够限制对一些特殊帐户或帐户群的访问。特殊帐户包括VIP帐户和职工帐户系统能够基于终端的物理位置限制对系统和系统功能的访问在连续三次失败操作时锁定用户ID系统能够自动生成违反安全的异常报告系统支持用户口令的自动过期、最小的口令长度、强制口令使用数字和字母、禁止使用容易猜到的口令、禁止口令与用户ID一致、禁止设置口令为词典中的字系统能够根据业界流行的加密方法对口令及客户敏感的数据进行加密系统必须保证单用户单进程,比如一个用户在同一时间只能在一台终端登陆对高风险的应用/交易,强制使用TOKEN和口令,比如安全管理和巨额基金转帐系统能够基于预定的原则对不寻常的作业生成异常报告,以便监测异常的交易对一些高风险的交易,要求用户输入附加的口令或重复的口令,以确保用户未离开交易中的终端核心业务系统的业务层的目标功能核算管理及账务体系核算管理体系根据<中国某银行会计核算制度>(本外币)的规定,结合各一级分行/二级分行的管理体制及考核要求,核心业务系统应采用多级核算体制。营业网点作为系统的营业前端,主要工作是将经济事项录入计算机;分(一级分行或二级分行)支行作为核算主体,具有完整账务体系的基本核算单位。一个核算主体既可定义为多个营业网点组成,也可定义为一个营业网点。各一级分行在总行营业部开设头寸户;各二级分行对应一级分行核算中心开设头寸户;各支行对应二级分行开设头寸户;各营业网点对应支行开设内部往来账户。经过北京数据中心进行全行的头寸管理和资金调拨。数据中心区域内各级行与区域外分行及境外行外汇资金清算,由数据中心经过外汇清算前置与TCS和PCC接口连接。账务体系按本外币统一会计核算制度,将本外币公司业务、本外币储蓄业务、银行卡业务的帐务处理在系统中整合,实现本外币一体化的集中会计核算,账务数据集中存放。会计核算账务数据集中存放于数据中心主机,各营业网点负责采集账务数据向主机传输、提交,数据中心负责对核算账务数据集中存放和加工处理,并向各营业网点反馈相关会计交易。为满足各行内部管理和当地人民银行、地方财政、审计、税务等部门对某银行的各类监管、检查需要。数据中心可按规范统一的标准,定时点向各管理层反馈会计信息。特殊需要时,由数据中心提供数据信息源,各管理层根据需要自行生成数据信息。总账系统使用本外币统一会计核算制度进行核算,科目采用二级科目制。按核算主体分币种设置总账,并按隶属关系分别生成各级机构的科目汇总数据。明细账分为客户明细账和内部明细账两大类。客户明细账包括存款明细账、贷款明细账;内部明细账包括表内内部账明细账、外汇结售明细账、外汇买卖明细账、核销账、表外内部账明细账。流水账由交易驱动方式产生和批处理方式产生两种,每种方式产生一个流水编号。登记簿设置有两种,一是以机构为单位设置,另一种是以柜员为单位设置;登记簿的反映方式能够以纸式形式反映,也能够以数据形式反映。在系统中,交易信息根据系统会计分录表产生交易流水、平行登记明细账和当日科目发生额,登记登记簿;日终批处理根据交易流水登记总账,进行总账、明细账的自身平衡,以及总账与明细账的总分核对,并进行总账与当日科目发生核对。系统支持24小时不间断记账模式。营业网柜员日结时,采用将清点的库存现金、重要空白凭证的结果输入系统,由系统自动核正确柜员主动方式,减少了柜员结账过程中的随意性;系统自动将柜员的当日流水进行借、贷平衡,并打印柜员交易流水清单,柜员科目日结清单,确保交易处理正确。机构日结时,系统自动检查本机构柜员的日结情况,并打印出本机构的交易汇总表、柜员结账时间表等,同时在柜员结账时间表中将各柜员的最后一笔账务性交易流水反映出来,加强柜员日结的管理和监督。核算中心在规定的时间进行日结处理,系统自动检查所辖各点的日结情况,进行账务体系中的各项平衡检查和处理。对于未日结的机构次日打印出营业网点未结账清单;对于流水不平的营业网点系统自动进行宕账处理,同时打印流水不平错误清单;对于系统批处理过程产生的不平账户,打印异常挂账清单;核算中心根据不同清单督促营业网点或有关部门查明原因进行账务处理,起到监督作用。内部资金管理同业拆借中,实行拆借对象信息管理、额度实时控管即:总行统一授信下的各级分行额度周转使用,拆借对象客户信息管理,信息数据集中区域共享。系统内的资金实行实时的头寸资金调度和管理。一级分行/二级分行与各辖内各核算主体行间采用:由核算主体行申请,一级分行/二级分行计财部核准,核算中心入账的调拨方式结算管理银行汇票、银行本票的底卡保留在签发行,结清销卡由签发行处理。汇划采用”一口出,多口进”的方式,即汇出业务由各营业网点处理,以一级分行的一个联行号发送至总行清算系统,汇入能够多个联行号进,由各营业网点进行处理。交换采用分散提出、分散提入方式。也可根据需要采用集中提出和集中提入方式。银行卡业务的管理1．银行卡清算银行卡的资金清算统一由一级分行核算中心对外清算,包括金网、龙网、全国金网、商户款的清算。商户清算信息由各地市的商户开户行自行接收。2．银行卡开卡由一级分行统一生成制卡信息文件,传送至各地市,由各地市根据不同的要求生成制卡文件,并打印卡片。密码文件由主机生成后,下传各地解密打印。3．商户的管理由各地市将商户维护的信息上传至一级分行/二级分行。商户的管理仍实行属地化管理。4．黑名单的管理由各地市卡信控部门人工录入的黑名单信息上送一级分行,一级分行负责向总行上传、接收。现金管理现金管理将现金的内部管理(包括机构调拨、柜员调拨)、柜面管理在系统中进行控制,采用现金出纳机联动账务处理。凭证管理结算类凭证按人行标准;银行内部使用凭证按总行和自定义相结合的标准;客户凭证按总行和行业相结合的标准。系统对会计凭证的使用区分以下情况,分别处理:1．外来原始凭证代记账凭证:系统对可代替记账凭证的原始凭证的过机记录采用在凭证正面或背面打印输出认证方式,以便后台人员稽核。2．银行填制的凭证:银行填制凭证分别以下两种情况:交易驱动模式下:柜员根据原始凭证启动交易,交易完成后系统打印输出机制凭证。分录驱动模式下:柜员根据原始凭证手工填制记账凭证后录入系统。3．批处理业务凭证:银行结息、批量代扣、代付款等批处理业务采用清单式凭证。4．汇总记账凭证:现金、同城票据交换等需要汇总登记明细账户的业务填制汇总记账凭证。重要单证管理将重要单据入库、重要单据调拨、凭证出售、重要单据使用、作废在系统中进行控制。国际结算国际结算中汇出汇款、汇入汇款、光票托收业务移植入主机系统处理;跟单进口、跟单出口、保函业务仍由各分行国际结算系统处理。国际结算系统业务处理后的会计数据由分行前置系统传送主机。对各级机构作业的支持营业网点柜员将所发生业务的经济事项,取得交易资料或填制会计凭证,录入计算机,接受主机反馈信息打印凭证、签发回单等。柜员营业终了办理结账、核对账实、整理并移交凭证(稽核)。营业网点在所辖柜员全部结账后办理机构结账。次日接收系统反馈报表及批处理凭证。一级分行核算中心负责一级分行授权管理的业务参数日常维护。在所辖营业网点结账后办理全辖结账。次日接收系统反馈本辖报表。对系统批处理后反馈的账务异常情况进行后续处理。接受主机报表信息生成报表文件数据中心负责总行统一规定的业务相关参数维护;在一级分行结账后进行主机系统批处理;批量结息处理、年终进行损益结转、账户结转。次日对系统批处理后反馈的异常情况进行后续处理;全行数据集中完成,取消总行清算网。实现由总行(总行营业部)经过北京数据中心直接及时进行全行的头寸管理和资金调拨。账本数据集中贮存和保管。营运风险控制体系参数管理将参数维护分为两个层次,一是数据中心维护,二是一级分行核算中心维护。采用经过交易方式进行业务参数设置,便于根据业务和管理需要灵活进行调整。额度管理额度管理可分为机构额度管理和客户额度管理。机构额度管理可有总行、一级分行、二级分行控制总额度;下属机构在总额度下再进行额度管理。客户额度管理以客户为单位分别控制各类额度。业务操作权限管理系统对科目使用的控管。根据核算办法及各行的管理需要,业务参数维护人员对不同层次的机构(如总行、一级分行、二级分行、支行、营业网点)可使用的会计科目加注标志,规范会计核算。系统对营业网点经办业务的控管。系统将机构划分为:核算中心、国际业务部、龙卡中心、二级分行、支行、营业网点,建立机构业务控管表,选择机构可经办的业务,明确机构的操作权限,防止不同类型机构的柜员对本机构非经办业务的介入。在机构升格时,可调整相应的机构权限。系统对操作柜员的控管。系统将操作柜员划分为A级主管、B级主管、现金柜员和普通柜员四类,建立交易控管表,对每一个操作员根据业务操作的管理要求选择可执行的交易组,明确了其操作权限,由计算机对每个柜员的操作权限进行自动控制,不得越权处理。系统对终端的控管。建立交易控管表,对每一台终端根据业务操作的管理要求选择可执行的交易组,明确了其操作权限,由计算机对每台终端的操作权限进行自动控制,不得越权处理。营业日历管理系统对各营业网点的工作日及营业时间进行管理,设置人行交换营业日历、对公营业日历、全年营业日历等,对非营业日的相应柜面交易以及账号类型进行严格控制,防止账务在非营业时间被非法修改。柜员管理柜员分为操作柜员和虚拟柜员。由一级分行核算中心统一管理全辖各机构的操作员。总行可查询所有操作员信息,各核算中心能够查询所辖所有机构的操作员信息,机构只能查询本机构的操作员信息。操作员以划卡并输入密码方式进入系统,系统为每位操作员提供更改本操作员密码功能;操作员密码具有时效,每隔一段时间必须修改一次密码,否则无法进入