xx银行授信业务相关的额度管理可以划分为三大类别：对公类授信额度管理、个人类授信额度管理及信用卡额度管理。具体分析如下：
? 对公类授信额度管理
? 额度审批设立 ? 额度控管 ? 额度信息交互
? 个人客户授信额度管理
? 额度审批设立 ? 额度控管
? 信用卡额度管理
? 额度审批设立 ? 额度控管
3.3.3.3.4.2 目标系统架构说明
基于后台处理集中的大趋势，结合对现状的分析，规划的目标是建设一个全行统一的额度管理系统，通过额度管理系统与各业务系统的实时连接，实现以客户为对象的、跨信贷产品的综合授信额度管理。
额度管理系统的主要功能有额度设立/调整、额度占用/串用、额度恢复、额度冻结/解冻、额度查询等。各部分功能说明如下：
? 额度设立/调整 ? 额度恢复 ? 额度冻结/解冻 ? 额度查询
3.3.3.3.5 统一支付平台
本部分所阐述的统一支付平台属于后台集中处理的范畴，通过整合目前各系统中的支付功能搭建一个全行统一的支付平台支持前台跨业务条线、跨交易产品、跨币种业务的货币给付及资金清算，在避免重复建设、实现资源有效利用的同时，通过集中、专业的业务处理提高效率、降低成本并加强管理。
第 21页 /共 38页
本文中的统一支付平台并不包含银行支付结算业务处理从业务操作、账务核算、到资金支付及清算的全过程，仅针对其中的资金支付及清算，处理内容包含有报文接发及转换、路由的选择判断、支付方式、资金清算、流动性管理（头寸计算及检查）、反洗钱检查、风险及欺诈管理（黑名单校验）、例外处理等。 3.3.3.3.5.1 支付相关系统现状分析
由于信用卡业务的独立性与专业性，其支付清算也具有一定的特殊性，现状分析划分为信用卡专题及非信用卡两部分进行。
3.3.3.3.5.1.1.1 支付相关系统现状（不含信用卡）：
基于支付对象、货币、业务产品的不同产生有不同的支付方式/渠道，分别由不同的支付系统给予支持，例如：按照支付对象是否跨系统可以分为系统内支付清算及跨行支付清算；按照支付货币的不同，可以分为人民币支付清算及外币支付清算；按照业务产品的不同独立出专门的卡支付清算。具体可以分为：
? 行内跨机构的资金支付清算 ? 跨行资金支付与清算
? 人民币支付清算 ? 外币支付清算 ? 借记卡支付清算
下面对涉及的主要支付系统（支付模块）进行逐一说明：
? 核心系统中大、小额支付模块
? 大额支付模块主要系统功能有： ? 小额支付模块主要系统功能有：
? 核心系统中同城票交模块
? 核心系统中行内转账/电子汇划模块（含本外币） ? 境内外币支付系统 ? 外汇清算系统 ? SWIFT报文处理系统 ? 借记卡支付清算
? 借记卡下行内跨机构的资金支付与清算
第 22页 /共 38页
? 借记卡下跨行资金支付与清算
3.3.3.3.5.2 统一支付平台目标架构
在支付系统现状分析及未来架构设计中，需要重点关注以下几个问题：
? 支付系统与核心系统的关系
目前各类支付业务有不同的处理方式，涉及不同的系统：
? 人民币支付功能是嵌在核心系统里的，导致每次支付的改变都要修改核心，
不利于核心的稳定性，也会给支付功能的实现带来一定的难度；
? 外汇清算系统目前实现了业务逻辑与核心的分离，但是两个地方都同时记了
支付明细信息；
? 定位最清晰的是境内外币清算系统，所有的支付逻辑及处理功能都在自己系
统实现，核心只是记账；
由于支付相关功能与核心系统的耦合程度较高，支付功能的变化每每牵扯核心系统其他功能的改造。但支付业务面临着日新月异的外部环境（业务变化、监管变化、人行支付系统升级、同业创新），业务变化频繁，建议支付系统未来建设能实现与核心系统的分离。
? 支付平台的业务价值
? 支持支付业务产品化，能够为第三方提供代理支付服务，实现结算运营中心
从成本中心向利润中心的转变
? 利用专业化的集中处理提升支付业务处理效率，降低支付成本
? 提升对支付业务的跟踪监测能力，为业务管理、风险管控及客户服务提供便
利
? 便于应对不断变化的内外部环境，提升xx银行支付业务的灵活性与适应性，
满足市场的需要
未来的支付平台架构清晰、功能明确，主要分为支付Hub（技术层）、支付系统（应用层）及接口三大部分：
? 支付Hub（技术层） ? 支付系统（应用层） ? 接口
第 23页 /共 38页
3.3.3.3.6
档案管理
3.3.3.3.6.1 现状图说明
? 会计档案及相关系统 ? 文书档案及相关系统
? 其他可能积累为业务档案的数据
3.3.3.3.6.2 目标系统架构说明
目前工行等行均成立了独立的部门（档案中心）统一管理业务、公文等各类型档案，由专业人员对各类原始纸质档案进行集中管理，利用电子系统满足各类部门对档案的调用需求。xx银行的档案管理目前仍分散在各个部门，未来业务管理的方向可能逐渐向工行的模式过渡，但时间不能确定。系统的规划应该兼容多种管理模式，保持业务管理的灵活性，同时应考虑到xx银行业务的发展，系统应有足够的可扩展性，可存储未来5-10年业务产生的非结构化数据。未来的档案管理系统将包括如下系统：
? 统一的内容管理平台 ? 会计档案 ? 公司客户档案 ? 零售信贷和信用卡档案 ? 文书和人事档案
3.3.3.3.7 后台集中处理
3.3.3.3.7.1 后台集中处理概念
后台运营的集中和建立后台运营中心是国外银行的先进实践和国内银行运营转型的趋势之一。后台运营的集中根据集中内容的性质和范围不同，可以分为广义后台运营和狭义后台运营，即通常所称的“大后台”和“小后台”。 3.3.3.3.7.2 后台业务集中处理带来的收益
? 提高服务水平，增加核心竞争力 ? 控制操作风险 ? 提高流程操作效率
第 24页 /共 38页
? 设立在正确的地理位置 ? 削减成本
3.4
3.4.1
数据架构设计
数据架构设计的内容和范围
全行级的数据架构设计的内容是：|把银行概念数据模型中的所有实体，根据其属性分类后，以应用架构设计所规划的功能定义为主要参考因素，以全行对数据和信息的使用需求为导向，对全行结构化数据的分布、集成、共享进行规划设计。
数据架构设计的范围是：
? 主数据源的架构规划 ? 数据集成规划
? 基于数据集成的管理分析型应用规划
3.4.2 数据架构设计原则
数据架构设计指导原则是一系列指导数据架构未来设计和决策过程的判断标准。这些指导原则从数据的角度进一步地细化了银行应用系统架构设计的通用原则，是对未来各应用系统在数据方面的分析、设计、开发和实施的判断标准。 3.4.2.1
数据共享原则
数据共享应覆盖所有应用系统并符合不同程度的时效要求，数据的全行统筹是实现数据共享原则的基础。 为实现这一原则：
? 必须实现共享数据的全行集中
? 必须制定统一的、切实可行的全行级数据模型 ? 数据分布规则必须建立并贯彻执行
第 25页 /共 38页