商业银行风险预警系统整体架构设计目录第1章前言 (3)1.1项目背景 (3)1.2项目目标 (3)1.3建设原则 (4)第3章总体架构设计 (5)3.1风险预警系统整体架构 (5)3.2网络架构 (25)3.3运行环境配置 (27)3.6系统性能指标 (31)第1章前言1.1项目背景随着商业银行业务的不断创新和快速发展以及数据集中程度和核算自动化程度的提高，现有运营监督工作重心、内容等都发生了很大变化，传统的账务监督已愈来愈偏离事后监督设计的初衷，各项会计核算的风险点增多，风险的隐蔽性增强，防范风险的难度也随之加大,且在监督工作中存在着监督技术手段落后、监督时效性不强、监督重点不突出等问题。

商业银行目前运营风险的预警和监控主要依靠事后监督系统，其建设较早，存在预警功能模块存在功能单一、预警模型预警针对性不强、预警模型开发不便利等问题，已经不能充分发挥其在防弊纠错、规范行为、保证资金安全等方面的重要作用。

为加快传统事后监督方式方法转型，运用科学的监督技术和管理手段，建立科学、高效、智能的监督管理架构，迫切需要引入先进的科技手段，建设较完善的风险预警、监测和控制平台, 实现对基础账务数据、会计业务内控、风险预警数据系统化、电子化管理的目标，提高运营管理的质量和效率、加强风险控制水平,实现对风险的事前优化、事中预警阻断、事后监督评估。

1.2项目目标本系统的建设目标为建立独立的、开放的、全行统一的风险监测预警系统，辅助行内实现对重要的网点、柜员、交易、业务的智能、连贯、动态化的监控，实现全渠道风险监测的目标，防范操作风险，消除案件和事故隐患，充分依托先进的科技手段和信息技术，使业务监督从简单操作型的静态事后复审向动态预警分析转变，使操作过程的事中控制前移，加大业务风险的检查、监督以及监控力度。

通过建设该系统，我们期待达到：1.有效利用技术手段强化对运营业务的风险监督和控制，实现运营业务风险监控的科学化管理。

2.提高预警系统的实用性，扩大预警系统的使用范围，实现运营监督检查任务的系统化管理。

3.实现对系统中各个预警规则的灵活配置，提高预警模型配置效率，减少后期技术运维人力。

4.实现按村镇银行进行风险预警的分级、分机构、差异化管理，提升村镇银行的运营业务风险控制水平。

5.实现与事后监督系统功能的整合，促进风险预警、非现场检查、现场检查、监督检查辅助等系统功能的全面提升，提高运营监督检查的系统管理水平。

1.3建设原则该系统的主要目的是整合本行各业务系统数据，利用先进的科学技术方法和经验，进行业务风险预警。

根据本行业务特点以及未来发展要求，借鉴国内外同业成熟的技术和经验，建设一个较完善的风险评估、监测、预警和防范平台，有利于规范日常风险预警监测工作，防范业务风险，改善经营管理水平。

本系统应能满足今后 3－5 年内系统进一步扩充与发展的需要。

系统应具有：开放式原则：该系统的应用主体不仅仅只是风险监测人员使用，而应包括管理风险预警工作的行领导、各被检查对象、各业务管理部门及其他用户。

可扩展原则：系统数据来源应具有可扩展性能，未来根据工作需要，可将新系统数据方便快捷的接入本系统，同时可根据需要进行快捷的二次开发。

易维护原则：各模块之间必须具备很强的定制功能，业务人员可根据业务流程和管理的变化自行对基础参数进行适当维护，使得业务操作、管理模式等可灵活调整。

易操作原则：系统应具有友好的用户操作界面，操作方法方便简单、易学易懂。

可转换原则：系统应具有各模块功能之间能相互快速连接，满足风险预警监测人员各自的操作习惯。

科学管理原则：各功能实现上要具有强大管理功能，不仅要实现作业流程的电子化，更要实现有效的系统管理功能，提高风险预警管理水平。

安全性和可靠性原则：系统应对数据的访问、传输、下载、分析、应用等操作具有加密功能或设置严格的权限控制体系。

第3章总体架构设计3.1风险预警系统整体架构风险地图我的收藏用功能公共控制辑处理服务接口数据存储数据采集3.1.1业务数据层业务数据是本系统的数据来源，包括行内各业务系统数据及第三方数据。

系统利用自主开发的 ETL 工具或者第三方 ETL 工具自动加载各业务系统数据至风险数据库，第三方数据可通过ETL 加载或者通过前台页面功能手工加载。

3.1.1.1业务系统数据◼核心业务系统◼信贷管理系统◼财务管理系统◼银行卡系统◼电子银行系统◼报表系统◼中间业务系统◼对账系统◼..........3.1.1.2第三方数据政府、银监、人行、海关、税务、工商、水气煤电公布的不良信用企业、网上收集的不良信息、黑名单、影子银行、广告（信用卡代办广告）、信用卡套现等3.1.2系统支撑平台3.1.2.1智能引擎组件⚫规则引擎：将业务模型从应用程序代码中脱离出来，形成模型规则库，负责模型规则解析、执行等操作。

⚫计算分析引擎：包括事中模型和批量模型计算分析，负责接收输入数据，调用模型规则引擎，计算出模型结果。

⚫报表工具：负责系统各类报表的设计、修改等功能。

⚫搜索引擎：负责知识管理平台中全文搜索服务。

⚫工作流引擎：负责系统中风险项目流程、问题整改跟踪等作业流程的配置、流转驱动服务。

3.1.2.2公共控制服务⚫批量作业管理：应用于模型批量运行的管理，包括模型批量运行、模型数据查询分析等。

⚫模型配置管理：模型规则的配置，包括模型的添加、修改、删除等操作。

⚫日志管理：系统日志查询、备份和清理。

⚫参数管理：系统运行各类参数的增加、修改、删除等。

⚫权限管理：系统权限、角色权限、用户权限的管理，包括系统权限的新增、修改、删除以及用户权限的新增、修改、删除等操作。

⚫数据管理：负责系统业务数据的转换、加载，备份和清理等操作。

⚫系统监控：包括ETL 运行监控、模型跑批计算监控、系统用户监控等。

3.1.3应用服务平台系统主要为业务人员提供基础管理平台、监测预警平台、风险检查平台、风险评价平台等功能。

3.1.4应用服务接口影像视频接口：系统与行内影像平台、账户档案管理系统、信贷档案管理系统、视频监控平台实现连接，实现业务数据与视频监控、影像档案在风险监管工作中的一体化应用。

短信接口：预警监测产生的信息可以通过短信平台接口发送；另外问题管理与风险评估平台中，下发问题的同时会通过短信平台接口发送至问题整改人。

另外包括统一认证、OA 接口、邮件接口等其他接口。

3.1.5授权用户风险管理系统的用户包括：主管领导、风险管理、风险执行、技术支持等。

◼主管领导主要负责本行风险工作管理、督查及风险资源调配与管控，一般多为行领导、风险委员会成员或风险部门负责人等。

◼风险管理该类用户负责日常风险工作的管理控制，包括风险检查、风险评价、知识管理等核心工作，一般为风险部门的中层或基层管理领导或项目主审人。

◼风险执行该类用户执行风险管理领导层分配的工作任务，执行风险检查、风险评价及知识管理等基层工作，包括预警线索处理、协查分析、风险评价执行、风险质量评估执行、知识管理等多个工作岗位。

◼技术支持该类用户主要对本系统进行日常运维管理，多为信息科技部人员或风险部门内部IT 技术人员。

数据源系统核心系统信贷系统票据系统影像系统网银系统集中运营国际结算财务系统信用卡系统其它系统第三方数据风险预警系统数据架构图交易系统数据架构风险管理系统业务数据从各业务系统中经数据处理区加载到风险基础数据存储区，经计算分析引擎，模型分析工具，后台服务程序以及业务人员分析确认后自动把数据存储于风险数据库中。

ODS层数据核心系统信贷系统票据系统影像系统网银系统集中运营国际结算财务系统信用卡其他系统第三方数据3.1.6数据库规划和设计策略风险管理系统需要海量数据，所以数据库规划尤为关键。

以下是风险基础数据库设计过程中关注的几个设计要点。

3.1.6.1数据压缩策略将表存储在磁盘上时,如果对数据行､空值和系统缺省值使用诸如压缩之类的功能,则表可能占用较少的空间｡通过数据压缩,可以使用较少的数据库页来存储数据,从而节省磁盘公共信息类会计记账授信交易卡片信息类中间层数据公共信息类会计记账客户信息授信交易卡片信息类信贷管理类交易流水统计全科目客户风险统计存储空间｡由于每页可以存储更多的逻辑数据,因此访问同样多的逻辑数据时需要读取的页数将会少一些｡这意味着压缩还可以节省磁盘 I/O｡I/O 速度也会加快,因为可以将更多的逻辑数据高速缓存在缓冲池中｡➢采用压缩技术的优点是：✧使用更少的存储；✧增加 I/O 吞吐量；✧以将更多的数据高速缓存在缓冲池中。

➢采用压缩技术的缺点是：✧有少量的 CPU 消耗。

3.1.6.2表分区策略表分区功能是一种数据组织方案,根据一个或多个表列中的值将表数据划分到多个称为数据分区或范围的存储对象中｡每个数据分区都是单独存储的｡这些存储器对象可位于不同的表空间和/或相同的表空间中｡跨多个存储器对象对表数据进行分区的能力为数据库管理员提供了更高的可伸缩性和灵活性,同时提高了性能和控制能力｡➢采用表分区技术的优点是：✧将大表按照某种关系分成若干个逻辑小表，可以减少数据扫描，提高效率；✧为数据库管理员提供了更高的可伸缩性和灵活性。

➢采用表分区技术的缺点是：✧数据库管理员有较高的要求。

3.1.6.3元数据管理建立风险管理系统一个重要的工作是元数据管理。

元数据管理就是描述业务风险数据信息，用于建立、管理、维护和使用系统。

元数据模块是系统中的关键组件，贯穿于风险管理系统的各个部分。

元数据相关工作大致包括元数据采集、元数据存储和元数据访问几个环节。

➢元数据采集元数据采集是元数据管理流程的第一步。

系统中元数据采集的来源有三个：ETL、业务数据文件、数据导入模块。

➢元数据存储通过元数据库集中存储来自不同系统和环境下的元数据，形成元数据基准，减少元数据访问时对源系统的影响和依赖：✧面向开发人员的在线的数据字典、术语表、代码表；✧面向设计人员的实体关系、数据加工过程、影响分析；✧面向业务人员的业务用户指南，有业务元数据定义和数据使用提示。

➢元数据访问对外提供统一的元数据访问服务，将元数据存储细节以及差异屏蔽在服务内部。

3.1.6.4 系统数据分布数据环境是整个系统的数据存储环境，这个环境分为如下三个区域：➢ ETL 服务器这个区域存放的是从一些从源系统中卸载过来的数据文件：✧ 数据缓冲区（DATAPOOL ）：存放准备处理的数据文件；✧数据处理区（STA ）：存放当前需要处理的数据文件，这些数据文件在下次同类数据处理前被删除。

➢ 数据库服务器✧ 风险基础数据区✓ 业务基础数据，包括客户类、服务渠道类、产品类等数据；✓ 导入数据，通过 ETL 功能组件导入到系统中的外部数据；✓公共数据，由外部获取的公共信息资料，如外汇汇率。

应用服务器 上传临时文件目录 用户导出 文件目录数据库服务器 UIA 数据 指标数据 外部导入 数据 参数表 审计基础数据 元数据 落地数据 文件目录ETL 服务器 DATAPOOL 数据处理目录 数据仓库服 务器 交易 数据✧风险数据区存放风险功能相关的数据资料，包括：✓风险资料库，即风险项目的备份资料以及风险资料；✓风险模型库，即风险模型的脚本；✓UIA 数据，即风险模型的结果数据，存储于数据库表中；✓标签库，即风险数据标签管理；✓归集库，即风险抽样、预警、指标等结果数据的归集管理。