渤海银行操作风险管理系统(一期)建设项目 用户需求说明书终稿1210评审.doc
-
资源ID:4185594
资源大小:6.31MB
全文页数:206页
- 资源格式: DOC
下载积分:8金币
友情提示
2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
|
渤海银行操作风险管理系统(一期)建设项目 用户需求说明书终稿1210评审.doc
本资料仅供内部使用!操作风险管理系统(一期)建设项目用户需求说明书修改记录制定日期生效日期制定 / 修订 内容摘要页数版本拟稿审查批准2008-11-13建立用户需求说明书的文档结构0.1彭泽飞2008-11-29完成各分部分内容初稿0.2魏永超、王胜、迟睿、刘田林、罗强2008-12-1合并文档初稿0.3彭泽飞2008-12-4合并文档修改稿0.7彭泽飞2008-12-9完成文档终稿1.0彭泽飞目 录1文档简介11.1用户需求说明书目的11.2说明书范围11.3缩略语解释21.4参考文件22本系统概述32.1系统建设背景32.2系统目标32.3系统使用者42.4本期系统范围43本行操作风险管理业务描述53.1操作风险管理组织结构53.2渤海银行操作风险管理主要活动介绍74渤海银行操作风险管理系统整体描述104.1系统层次结构104.1.1应用层114.1.2引擎层124.1.3应用数据层124.1.4基础数据层134.1.5操作风险管理高端数据流144.2渤海银行操作风险(一期)的核心业务需求简述164.2.13K基础数据库164.2.2风险及控制评估184.2.3风险上报204.2.4风险处置行动计划214.2.5统计报表214.2.6管理层声明225操作风险管理系统功能(一期)需求说明245.1系统基础数据管理245.1.1管理维度数据维护245.1.2操作风险组织结构维护305.23K标准库维护325.2.1规章制度资料库的维护325.2.2KCS标准库维护415.2.3KCSA标准库维护515.2.4KRI标准库维护615.3评估与检查模块715.3.1一线自我评估715.3.2指定日评估905.3.3二线检查1095.3.4专项检查1235.3.5评估与检查查询1385.4风险事件上报模块1415.4.1处理流程描述1415.4.2风险事件基本页面及数据项说明1465.4.3风险事件任务列表1545.4.4风险事件维护1565.4.5风险事件审核1625.4.6重启已结束报告1655.4.7突发风险事件上报1665.4.8风险事件查询1695.5风险事件跟踪与行动计划管理1735.5.1行动计划制定1745.5.2实施结果录入1775.5.3行动计划延后1795.5.4风险事件关闭1805.6管理层声明1815.6.1管理层声明问题设置1815.6.2发起管理层声明1845.6.3查询管理层声明1855.7报表统计模块1875.7.1操作风险管理人员统计1875.7.2操作风险管理工具统计1885.7.3一线检查总体情况1905.7.4二线检查总体情况1915.7.5全行操作风险损失报告1935.7.6十大操作风险1955.7.7操作风险解决情况1965.7.814类操作风险的状态1976银监会指引相关要求1986.1操作风险损失事件类型1986.2商业银行业务条线归类202附录A 术语2041 文档简介本章将简要地说明用户需求说明书(以下简称本需求)的目的、范围、名词定义和参考文件。1.1 用户需求说明书目的本需求的目的在于阐明渤海银行操作风险管理系统(以下简称本系统)的各项需求,并给出本系统的总体设计。本需求为编制如下文档提供基本依据:l “软件概要设计规格”l “软件开发计划”l “软件详细设计规格”l “软件测试计划”l “软件测试说明”l “软件操作手册”l “系统安装手册”l “系统运行维护手册”本需求与“软件详细设计规格”一起,为编程、元件测试、组件测试及软件集成测试提供基本依据;本需求为编制其它有关文件提供基本依据本需求为软件质量保证人员提供工作依据本需求将作为日后软件确认测试和系统验收之准则本需求与“软件详细设计规格”一起,将作为日后系统维护工作基准文件1.2 说明书范围本需求的内容涵盖了本系统的业务描述的、系统整体描述、功能需求。本需求的阅读、使用者包括:1. 项目管理人员2. 业务人员3. 软件设计人员4. 编程人员5. 软件测试人员6. 软件质量控制人员7. 软件维护人员1.3 缩略语解释1. RP:Responsible Person,一线检查人员;2. BORM:Business Operational Risk Manager,总行的操作风险经理,负责条线;或分行的操作风险经理,负责分行部门;3. UORM:Unit Operational Risk Manager,单位操作风险经理,比RP高一层级;4. CRO:Chief Risk Operator首席风险官;5. KCS:Key Control Standard,关键控制标准;6. KCSA:Key Control Standard Assess,关键控制标准检查指标;7. KRI:Key Risk indicator,关键风险指标;8. 3K标准:包括KCS、KCSA、KRI检查标准简称,又叫3K检查指标。1.4 参考文件标题文件号发布日期出版单位渤海银行操作风险管理政策2008-4-11渤海银行商业银行操作风险管理指引2007-5-14中国银监会商业银行操作风险监管资本计量指引2008-10-1中国银监会巴塞尔新资本协议2004年巴塞尔银行监管委员会2 本系统概述2.1 系统建设背景2004年出台的新巴塞尔资本协议,对银行业提出了资本充足率、监督检查和市场约束三大要求,并且添加了操作风险和测算操作风险的方法。新巴塞尔资本协议传递了一种先进银行经营管理的理念,该协议为全球银行优化银行资本、提高风险抵御能力提出了新的指引,已逐步成为国际银行业普遍认可的业内协议。推行或达到新巴塞尔资本协议的要求,对于国内银行参与国际竞争,具有非常重要的意义。如何提升操作风险的管理理念,如何健全操作风险的管理框架,以及如何利用信息化电子化的管理手段对操作风险进行量化和控制,是商业银行必须解决的问题。渤海银行自开业之初,就引进了国际银行在操作风险管理上的先进理论和经验,并参考战略投资者渣打银行的操作风险管理模式,在本行组织架构中设置了操作风险管理的专门机构,在日常工作中逐步推广国际化银行操作风险管理的理念和方法,以实现风险计量与管控并重的管理目标。目前经过2年多的有效工作,其管理理念、管理工具和管理经验等均在国内属于领先地位。2.2 系统目标该系统是基于渤海银行操作风险管理体系的框架,参考西方商业银行操作风险管理系统的设计特点建立的,总体目标在于实现有效的精细化的操作风险控制,实现银行操作风险管理的信息化,规范化,使风险数据便于统计汇总和分析,并能监督化解风险所采取的行动的结果。该系统能够在参考巴塞尔协议有关操作风险规定的基础上,使我行逐步建立相关的历史风险数据库,并建立操作风险损失计量的模型。为提高未来本系统的使用灵活性和便利性,本系统的建设时将以实现参数化管理、并保证系统的可扩展性为重要使用目标。在使用过程中,根据操作风险管理体系的不断完善、风险控管水平和精细度的不断提高,渤海银行可以在系统基础框架内,方便地通过调整参数设置来适应业务管理要求的变化。各级用户在使用本系统时,能够充分利用系统的这一特性,实现风险管理规范化、录入信息便利化,统计查询多样化,业务操作便利化。2.3 系统使用者该系统的使用者为总行高管、操作风险部成员、各机构主要负责人以及遍布全行各部门、机构的专职或兼职的操作风险管理人员。目前总用户数量达到200人以上,已经累计了2年半的风险报告,记录风险近千条,未来将根据分支机构建设进度用户将有所增加,规划中使用操作风险管理系统的人员应达到员工总数的80-90。系统使用者包括如下:1、 系统使用者包括操作风险管理体系内的各层级人员,包括CRO、操作风险管理部总经理、BORM、UORM、风险主任、RP等。2、 系统使用者还包括:高级管理层、总行各部门总经理(以及下属部门或业务团队的负责人(高级经理)、分行行级领导、支行行长等各级机构的负责人。2.4 本期系统范围操作风险管理系统分成多期建设,一期主要建设内容包括:1、 建立操作风险管理系统的基础框架建立起操作风险管理所需要的基础系统框架,包括权限管理、安全控制、流程控制等基础功能,还包括建立起全行的组织结构、操作风险管理的组织结构、业务线结构,以及其他基础参数维护功能。同时一期的系统建设应该能满足系统后续建设灵活扩展的需要,同时系统一期的功能能够与后续实现的功能有效衔接。2、 实现操作风险报告管理功能a) 操作风险报告报送的流程控制b) 操作风险报告的处理过程跟踪3、 实现3K标准管理和自我评估功能a) 3K标准库维护功能b) KCSA和KRI的一线自我评估管理功能c) 二线评估管理功能d) 专项报告管理功能4、 相关风险报告和3K评估内容的统计查询功能a) 针对风险事件报告和3K评估内容进行统计汇总和查询3 本行操作风险管理业务描述3.1 操作风险管理组织结构渤海银行建立了全行的操作风险管理的组织结构。具体的组织结构体系如下:结构图说明:本结构图包括了渤海银行目前的组织结构(见实框部分)和未来的规划的组织结构(见虚框部分)。1、 董事会渤海银行董事会应将操作风险作为渤海银行面对的一项主要风险,并对监控操作风险管理的有效性承担最终责任,主要职责是:a) 制定与本行战略目标相一致且适用于全行的操作风险管理战略和总体政策;b) 通过审批及检查高级管理层有关操作风险的职责、权限及报告制度,确保全行的操作风险管理决策体系的有效性,并尽可能地确保将本行从事的各项业务面临的操作风险控制在可以承受的范围内;c) 定期审阅高级管理层提交的操作风险报告,充分了解本行操作风险管理的总体情况、高级管理层处理重大操作风险事件的有效性以及监控和评价日常操作风险管理的有效性;d) 确保高级管理层采取必要的措施,有效地识别、评估、监测和控制/缓释操作风险;e) 确保本行操作风险管理体系接受内审部门的有效审查与监督;f) 制定适当的奖惩制度,在全行范围有效地推动操作风险管理体系的建设。2、 CEO(高级管理层):负责执行董事会批准的操作风险管理战略、总体政策及体系;根据董事会制定的操作风险管理战略及总体政策,负责制定、定期审查和监督执行操作风险管理的政策、程序和具体的操作规程,并定期向董事会提交操作风险总体情况的报告。高级管理层的具体职责见渤海银行操作风险管理政策第八条。3、 法律合规与操作风险委员会:是高级管理层下设的专业风险管理委员会,主要负责管理本行法律合规及操作风险,确保本行经营管理符合中国法律、监管要求和本行的规章制度。该委员会对高级管理层负责,代理行使高级管理层在操作风险管理方面的职责。法律合规与操作风险委员会的具体职责见渤海银行操作风险管理政策第九条。4、 CRO(首席风险官):负责全行的风险管理,包括市场风险、信用风险、操作风险,负责向高级管理层和法律合规与风险委员会汇报工作。5、 操作风险工作委员会:是法律合规及操作风险委员会下设的专门委员会,根据法律合规及操作风险委员会授权管理本行的操作风险,并对法律合规及操作风险委员会负责和报告。操作风险工作委员会的具体职责见渤海银行操作风险管理政策第十条。6、 分行操作风险委员会:是法律合规及操作风险委员会下设的专门委员会,根据法律合规及操作风险委员会授权管理本分行的操作风险,并对法律合规及操作风险委员会负责和报告。7、 操作风险部总经理:负责操作风险部的全面工作。操作风险部独立于业务线设置,承担独立的操作风险管理职能,主要负责建立全行的风险管理标准,独立审批和评估业务单元的风险管理框架、工具方法、流程和信息系统,对业务单元的风险承担活动提供支持。8、 高级BORM:总行操作风险高级经理,负责某一个或几个业务条线的操作风险管理工作,或负责某几个分行的操作风险管理工作。9、 BORM(操作风险经理):根据负责的业务条线或分行的不同,分为总行业务条线BORM和分行BORM。负责本业务条线或本分行操作风险的识别、风险事件的上报、风险行动计划的制定和实施;具体描述如下:a) 总行部门BORM:负责总行业务条线各部门操作风险管理或者某一特定操作风险管理领域(如BCP、FCR)的工作;指导所分管的总行部门UORM的工作;向操作风险部总经理(或高级BORM)汇报工作。b) 分行BORM:负责分行及其下属各部门和支行的操作风险管理。指导下属分行UORM的工作;向操作风险部总经理(或高级BORM)汇报工作。10、 操作风险主任:协助总行或分行的BORM进行操作风险管理工作。11、 UORM:单位操作风险经理i. 总行部门UORM:负责总行某一个部门的操作风险管理;向总行BORM(或操作风险主任)上报操作风险报告和评估结果。ii. 分行部门UORM:负责分行某一个部门的操作风险管理;负责向分行BORM或分行操作风险主任上报操作风险报告和评估结果。iii. 支行UORM:负责支行的操作风险管理;负责向所属分行BORM或操作风险主任上报操作风险报告和评估结果。12、 RP:一线检查员负责本单位风险的识别,风险事件的上报,按照3K标准对本机构的风险控制情况进行评估,并向所属UORM上报评估结果。13、 业务线检查员操作风险组织结构中规划的业务线检查员是属于具体的业务人员,负责收集和上报本机构在业务运行过程中的生产数据和过程数据。目前考虑对每个机构的业务线检查员分成三个角色:业务员、业务主管、业务经理。3.2 渤海银行操作风险管理主要活动介绍1. 建立操作风险管理标准和操作风险管理业务资料知识库a) 3K检查标准:渤海银行建立起了KCS、KCSA、KRI的操作风险控制标准,作为各级机构和部门操作风险控制的检查标准,未来还会增加CS控制标准。总行会制定全行的3K标准,各个分行和部门可以在总行的3K基础上制定适用于本机构的3K标准,最后通过总行的统一确认后施行。b) 业务资料知识库:是渤海银行操作风险管理人员逐步积累、完善的知识库,包括外部规章制度、内部规章制度、业务流程要点记录、业务系统控管措施记录等内容,是建立、维护3K标准,进行专项检查等工作的基础,同时为全行内控管理措施的制定、业务流程关键环节的确认等提供帮助。2. 操作风险识别和评估a) 零线检查:零线检查是由业务人员收集关键业务数据,通过对这些关键业务数据的计算分析,来发现业务活动中可能存在的操作风险。当然这些关键业务数据需要进行业务部门主管或其他审核人员确认。b) 一线自我评估:一线检查是操作风险管理和控制的一项重要工具,是一项按照不同检查周期定期进行操作风险检查的业务活动。具体过程是:利用3K检查标准,RP对各个部门的操作风险控制现状进行检查,检查完的结果发送到单位操作风险经理进行审核。通过定期的一线检查,来发现业务管理控制环节可能存在的操作风险。c) 一线指定日评估:一线指定日评估又叫一线抽查。全行维护一份统一的指定日评估单,检查单的内容是来自于KCSA指标。总行可以指定某一个单位执行指定日评估,则相应的RP在结束指定日评估内容后,将检查结果录入到系统中。一线指定日评估的结果归集到该机构的一线检查内容中。d) 二线检查:二线检查是针对某种现象或特定的目的而发起的,不定期的检查活动。二线检查的检查内容可以是来自于3K标准,也可以是来自于非3K标准。通常情况下,二线检查是由BORM发起,由多人参与具体检查过程。专项检查是一种针对特定目而发起的检查活动,比如金融犯罪调查、开业检查等活动,也可以认为是二线检查的一种。e) 三线检查:三线检查是由一线、二线以外的调查人员开展的审计和检查活动,例如:内部审计、外部审计、监管机构检查等。3. 操作风险报告:基于定期或实时方式,通过对各类风险事件的统计、分析,及时产生各种形式的操作风险管理报告/报表,向管理层通报操作风险管理的状况。a) 3K检查结果报告:一线操作风险人员对本机构、条线等周期性检查的结果报告。b) KRI监控:通过KRI监控指标的计算标准,对指定的关键业务数据进行记录,并按照一定的规则进行统计、分析,将结果与阀值进行比较,从而发现、预警各类操作风险,并记录风险变化的规律和趋势。c) 风险上报:通过风险上报流程对一线检查、二线检查、三线检查、专项检查等方式发现的风险隐患、潜在风险事件,或已经发生的风险损失事件进行逐级上报。操作风险管理体系内部人员(未来应可以包括行内任何人)发现需要上报的风险事件后,都可以进行上报,由上级进行审核确认,同时发送给相应的业务线主管。d) 突发风险事件上报:当任何人(系统使用者)发现突发风险事件或者其他需要紧急报告的操作风险后,可以将该事件直接报告给一人或多人。收到突发风险事件上报的人,可以查看相应的报告内容。e) 管理层声明:各级部门的主管(总行部门总经理、分行行长、分行部门经理、支行行长)等管理者,作为一线业务的负责人,应当对本机构的操作风险管理承担主要责任,为此,需要定期了解了本部门的整体操作风险现状,并通过签署“管理层声明”的形式体现。f) 风险评级:通过对各个部门操作风险检查结果,包括一线检查、二线检查,风险事件上报情况、行动计划执行情况、操作风险损失情况等进行数据统计分析,根据某种计算模型对各个部门的操作风险现状进行风险评级。模型的指标和权重可以根据机构不同进行调整。4. 操作风险化解与控制a) 行动计划管理:对于潜在的操作风险隐患,或已经发生的操作风险损失,需要制定相应行动计划来使得风险消除,或者使之处于受控状态。操作风险部要对行动计划的实施过程进行跟踪,以确保计划能够被有效执行,同时保证行动计划的执行效果。b) 风险处理情况跟踪:对于在3K标准维护、风险评估与检查、各类事件上报与审批、行动计划处理等各个管理环节,风险管理人员通过对相关系统日志信息的查询和统计,跟踪在风险管理各个阶段各级相关人员的处理动作、风险状态等,实现对操作风险生命周期的全过程的跟踪。5. 操作风险损失管理:a) 计量模型。通过标准法、替代标准法、高级法对本行的操作风险进行计量,从而得出操作风险经济资本需求。由于采用高级法是一个长期的趋势和目标,因此还需要建立起本行的内部操作风险损失数据库和外部操作风险损失数据库。b) 情景分析和压力测试:通过建立操作风险的情景数据和压力测试环境,利用情景分析模型分析本行在各种情况下的操作风险损失,从而针对各种潜在损失情况提前采取行动计划。c) 风险损失数据整理:根据积累的内外部风险事件,按照模型计算的要求建立风险损失库,并对其中的数据可以进行整理。风险损失的数据来源可以是风险事件、FCR报告、检查结果、人工录入并经过审批的风险损失等等。d) 风险损失审批流程:根据风险事件报告的情况,建立风险损失的管理流程,包括损失上报、审核、确认等,并能够与财务系统、核心系统等业务系统的有关业务数据相关联。6. 其他工作a) 业务应急预案:各个部门需要根据本部门可能存在的操作风险损失事件,根据估计的严重程度,建立起相应的业务应急预案库,并且需要对应急预案进行演练。操作风险部需要对业务应急预案库和预案的演练情况进行管理。b) 预防金融犯罪管理(FCR):对本行发生的各种涉嫌金融犯罪及违规信息进行管理,包括预防金融犯罪管理的数据收集、数据处理、数据发布、处理过程、处理结果、档案管理。c)4 渤海银行操作风险管理系统整体描述4.1 系统层次结构架构图说明:本架构图包括渤海银行操作风险管理系统的整体规划,包括一期实现的功能(分界线左边深色区域)和一期以后可能实现的功能(分界线右边灰色区域)。系统的应用层次分成四层:1. 最底层是基础数据层,作为操作风险管理的基础维度数据;2. 在基础数据层之上是应用数据层,包括各种与应用相关的数据;3. 引擎层,是为在应用数据层之上,为应用提供各种计算服务、流转控制功能;4. 应用层,为用户提供的各种应用功能模块。4.1.1 应用层在“渤海银行操作风险管理系统应用架构”中,其应用层描述的内容是面向最终用户使用的应用功能,涵盖了目前正在开展的操作风险管理业务,也包括了规划中的操作风险管理业务。在一期的功能中,重点实现了3K的管理、一线检查、二线检查、风险上报、行动计划和报表功能,简介如下:1. 3K检查标准维护:在一期的功能中会实现对KCS、KCSA、KRI的操作风险控制标准进行维护,和规章制度资料数据库的维护。未来会增加CS控制标准维护功能。2. 一线检查:一线检查是操作风险管理和控制的一项重要工具,具体过程是:利用3K检查标准,RP对各个部门的操作风险控制现状进行检查,检查完的结果发送到UORM进行审核。3. 二线检查:BORM发起二线检查任务,制定检查项(可以来自与3K标准和非3K标准),指定相应的检查人,各个检查人完成检查后,将结果录入到系统中。系统对检查结果、检查的过程文件、相关附件进行管理。4. 风险事件上报:操作风险管理体系中的任何人通过风险上报模块进行上报,由上级进行审核确认,同时还要发送给相应的业务线主管。5. 管理层声明:各级部门的主管(总行部门总经理、分行行长、分行部门经理、支行行长)每个月了解了本部门的操作风险现状以后,通过签署“管理层声明”来确认本部门的操作风险状况。6. 风险处置行动方案管理:对于潜在的操作风险隐患,或已经发生的操作风险损失,需要确定风险管理策略,制定相应行动计划来使得风险消除,或者处于受控状态。系统提供对行动计划实施过程的跟踪,可以记录行动计划的执行过程信息和最终的效果信息。7. 统计汇总和查询:系统提供各种详细数据的查询和统计汇总功能。以下模块是一期以后实现的应用:1. 零线检查:零线检查是由业务人员收集关键业务数据,可以通过对这些关键业务数据的计算分析,来发现业务活动中可能存在的操作风险。当然这些关键业务数据需要进行业务部门主管或其他审核人员确认。2. 三线检查:三线检查是由外部调查人员开展的外部审计活动。3. KRI监控与预警:通过KRI监控指标的计算标准,可以对业务数据进行计算分析,将计算结果与KRI的阀值进行比较,从而发现潜在的操作风险。4. 风险评级:通过对各个部门操作风险检查结果,包括一线检查、二线检查,风险事件上报情况,行动计划执行情况进行数据统计分析,根据某种计算模型对各个部门的操作风险现状进行风险评级。模型的指标和权重可以根据机构不同进行调整。5. 业务应急预案:各个部门需要根据本部门可能存在的突发事件,根据估计的严重程度,建立起相应的业务应急预案库,并且需要对应急预案进行演练。操作风险部需要对业务应急预案库和预案的演练情况进行管理。6. 预防金融犯罪管理(FCR):对本行发生的各种金融犯罪信息进行管理,包括预防金融犯罪管理的数据收集、数据处理、数据发布、处理过程、处理结果、档案管理。7. 操作风险计量:通过标准法、替代标准法、高级法对本行的操作风险进行计量,从而得出操作风险经济资本需求。由于采用高级法是一个长期的趋势和目标,因此还需要建立起本行的内部操作风险损失数据库和外部操作风险损失数据库。8. 情景分析:建立操作风险的情景数据和极端的压力测试模型,利用情景分析模型,来分析本行在各种情况下的操作风险损失。4.1.2 引擎层引擎层是给系统运行、数据复杂计算、数据分析等功能提供底层运算支持。引擎层包括:数据分析引擎,流程引擎,情景分析引擎,资本计量引擎。根据系统实现功能的需要,引擎层的建设也将分成多期实现。具体描述如下:数据分析引擎:为数据的统计汇总提供计算支持,包括汇总统计和灵活查询、分析、报告、仪表盘显示等;流程引擎:为操作风险管理过程中的流程控制提供支持,包括进行组织建模、应用接口、任务分配和任务推送,从而实现流程的驱动和控制;情景分析引擎:为操作风险的压力测试和情景模拟的建模和模拟分析提供计算支持,功能包括情景建模和情景分析;该引擎将在一期以后进行实现;资本计量引擎:为操作风险的经济资本计算提供支持,该引擎当中,应该能够对操作风险计算常用计算方法提供支持,包括巴塞尔协议建议的基础法、标准法、高级计量法的损失分步法和极值理论。4.1.3 应用数据层系统将针对各种应用需求,建立起相对应的应用数据库结构,来存储操作风险管理的各种业务数据。具体内容如下:1. 3K基础数据库:用于存储KCS、KCSA、KRI的操作风险控制标准库和规章制度资料数据库;2. 一线评估数据:用于存储一线RP检查人员根据KCSA、KRI的检查评估结果数据和指定日评估数据;3. 二线评估数据:用于存储二线评估的数据和专项评估的数据;4. 风险上报数据:用于存储各级机构上报上来的风险数据;5. 风险跟踪数据:用于存储风险处理过程中的过程跟踪数据;6. 统计汇总数据:用于存储各种统计汇总数据。根据操作风险管理业务发展和系统建设需要,未来在应用数据层还会增加如下的数据库:1. 零线检查数据:用于存储零线检查录入的数据;2. KRI业务监控数据:用于存储KRI对业务数据的分析结果数据;3. 三线检查数据:用于存储三线检查的数据;4. 应急预案库:用于存储各个业务条线、分支机构制定的针对各种突发事件的处理应急预案信息,以及应急预案的演练信息;5. 金融犯罪及违规库:用于存储本行的各种金融犯罪信息、黑名单等信息。6. 情景库:用于存储操作风险情景模拟和压力测试场景的数据库;7. 内部损失数据库:用于存储本行发生的操作风险损失事件数据信息;8. 外部损失数据库:用于存储其它银行发生的操作风险损失事件信息;9. 资本计量数据:用于存储本行操作风险经济资本计量所需要的基础数据、计算过程数据和计算结果数据。4.1.4 基础数据层基础数据层是构成操作风险运行的核心基础结构数据,能够支持本系统在一期的应用和未来的应用需求。基础数据层包括的内容如下:a) 全行组织结构:用于描述全行业务单元的组织结构,采用树形结构表示。b) 操作风险组织结构:用于描述本行操作风险管理的组织结构,采用树形结构表示。c) 业务线数据:用于描述本行业务线划分的层级结构,用于树形结构表示。d) 业务流程数据:用于描述本行的业务活动中,各业务的流程信息,采用树形结构表示。e) 产品线数据:用于描述本行的各条产品线的划分信息,采用树形结构表示。f) IT系统:包括应用软件、网络、硬件等信息资产。以上描述的基础数据结构将在一期建设中实现,这些结构将应用于各个功能模块中,建立起各个功能模块与全行管理维度的属性关系。以下的业务运行基础数据将主要用于二期的KRI风险监控,具体描述如下:g) 业务运行基础数据:在基础数据层中,还包括业务运行基础数据,它的用途和来源描述如下:i. 用途:可以利用KRI的监控指标,通过KRI计算公式对业务系统的运行数据进行分析,来发现业务运行中的操作风险;ii. 来源:从业务基础数据的来源方式上,分成两种:一种是通过接口从其它业务系统中自动获得数据;一种是由业务人员录入到系统中。4.1.5 操作风险管理高端数据流上图为操作风险管理的高端数据流,描述了主要的操作风险管理数据的产生和流转过程。图中深色区域是在一期建设中将实现的数据流,浅色区域是在一期以后逐步实现的内容。下面对几个主要的数据流进行说明:1. 3K检查数据流a) 通过CS维护、KCS维护、KCSA维护、KRI维护,建立起控制标准库;b) 控制标准库中的每一条标准,与管理制度库进行关联,表示每一条控制标准的来源或控制依据;2. 风险控制评估数据流a) 一线评估:利用3K控制标准进行一线评估,评估的结果存储到KCSA评估数据库;b) 二线检查:利用3K标准或非3K标准进行二线评估,存储到二线评估数据库;c) 专项检查:专项检查的结果,存储到专项检查数据库;3. KRI监控数据流a) 通过零线检查或其它业务系统的接口,建立业务基础数据库;b) 利用KRI指标,对业务基础数据进行监控,将分析结果存入到KRI监控数据库。4. 风险事件上报a) 风险事件(包括潜在风险)的来源是:一线检查、二线检查、专项检查、KRI检查的检查结果中发现的风险,或其它途径发现的风险;b) 风险上报以后,形成风险事件数据库和行动计划数据;c) 通过行动计划的执行,会形成本行的操作风险缓释数据。5. 经济资本计量数据流a) 从风险事件数据库中的损失事件中,进行分析后形成内部风险损失数据;b) 通过获取外部损失事件建立外部风险损失数据;c) 在内部损失数据、外部损失数据、3K检查结果、KRI监控数据基础上构造情景数据;d) 通过内部损失数据、外部损失数据、情景数据库,形成损失分布曲线,利用操作风险的高级计量法(例如:损失分布法和极值理论法),进行操作风险经济资本的计算。4.2 渤海银行操作风险(一期)的核心业务需求简述4.2.1 3K基础数据库渤海银行3K基础数据库是全行操作风险识别和控制的基础指标。3k标准包括:KCS、KCSA、KRI。KCS(关键控制标准)是一个定性标准,由管理层用来强调需要遵守的最低控制(与风险状况相适应)标准,确保在相关的业务/职能部门内有效地控制主要风险。关键控制标准包括:基本控制标准(GKCS)和专有控制标准(BKCS)两类。目前有数百条,未来会有大量增加。KCSA(关键控制自我评估指标)是在KCS的定性标准上建立的一系列细化指标。按照提问回答的形式,评估KCS是否被遵守和执行。一般是按照约定的频率和比例抽取业务、交易文件,作为检查样本。根据KCSA的回答判定风险控制的有效性。KCSA条目的数量以千条计,未来会有大量增长。KRI是从定量的角度衡量操作风险,指出业务、职能或流程的特定领域中的风险水平。操作风险管理人员在使用KRI量化风险水平的同时,还可以对KRI指标进行注释性说明。该指标目前有百余条,均由手工录入,未来将会实现手工录入和自动获取两种风险数据获取方式,并按照参数化设置的阀值进行自动预警。根据3k标准适用范围的不同,分为G3K(基本控制标准)和B3K(专有控制标准)。G3K标准是适用于全行的操作风险控制指标,B3K是适用于某一个部门或分支机构的操作风险控制指标。1、 G3K:G3K标准是适用于全行的操作风险控制指标体系,由GKCS、GKCSA、GKRI构成。a) GKCS:是操作风险主政策,属于指导性的政策,它的适用面广,没有指定特定的部门和业务线。GKCS由总行操作风险部进行统一管理和维护。b) GKCSA:各个业务部门或分行根据总行的GKCS,将每一条落实为本部门具体的检查指标,称为GKCSA。GKCSA的制定完后,需要各机构与总行操作风险部进行审核确认,确认完后由总行操作风险部统一维护到系统中。c) GKRI:各个业务部门或分行根据总行的GKCS,制定本机构的GKRI。GKRI的制定完后,需要各机构与总行操作风险部进行审核确认,确认完后由总行操作风险部统一维护到系统中。2、 B3K:B3K标准是适用于某一个业务线、部门或分行的操作风险控制指标体系,由BKCS、BKCSA、BKRI构成。a) BKCS:是适用于某一个业务线、部门或分行的关键控制指标。由各业务条线、分行在总行操作风险部的指导下自行制定,制定完后由总行操作风险部审核后生效。b) BKCSA:是适用于某一个业务线、部门或分行的关键控制检查标准。由各业务条线在总行操作风险部的指导下自行制定,制定完后由总行操作风险部审核确认后生效。c) BKRI:是适用于某一个业务线、部门或分行的定量控制标准。由各业务条线在总行操作风险部的指导下自行制定,制定完后由总行操作风险部审核确认后生效。3、 规章制度库:用于存储本行的各种管理规章制度。作为一个简单的文档管理模块,对规章制度采用附件的方式进行上传管理,同时添加对该规章制度的说明属性。在一期的实现中,本模块不提供对规章制度的全文检索等功能。4、 CS基础库:控制标准库,CS基础库的管理在二期提供,在本文不做详细描述。5、 3K标准的产生过程a) G3K的产生过程:总行操作风险部维护GKCS。各机构在制定本机构GKCSA和GKRI的时候,原则上需要完全根据总行操作风险部的GKCS,细化为本机构的GKCSA,同时还可以根据本机构的具体情况,制定适用于本机构的KCSA检查项。KCSA制定完成后,由总行操作风险部BORM审核以后生效。b) B3K的产生过程:各业务条线在总行操作风险部的指导下,制定本业务条线的BKCS、BKCSA、BKRI,分支行条线的B3K也是总行操作风险部来制定完成。制定完成后,上报给各条线BORM,各条线BORM审核以后生效。6、 系统对3K标准库维护的支持需求3K标准形成过程的交流、讨论、确认工作在系统外进行,最后形成总行操作风险部确认的Excel标准文档,系统提供批量导入;a) 录入总行3K标准:系统提供对总行KCS、KCSA、KRI标准的单条录入和批量导入功能,每一条3K标准都有自己的“适用范围”:适用范围根据全行业务组织架构的层级进行设定,基本层级包括全行、总行、分行、支行,未来可以根据操作风险管理境况将其细化到业务组或者岗位一级。;b) 录入分行和业务条线3K标准:系统提供对分行或业务条线KCS、KCSA、KRI标准的单条录入和批量导入功能;c) 跟踪:系统提供对3K标准修改过程的历史记录跟踪;d) 修改:对于3K的修改,系统提供根据查询条件批量导出到Excel,在Excel中修改以后,系统提供将修改后的内容批量导入;e) 生效控制:某个3K标准,修改以后可以设定暂时不生效,在评估过程中仍然使用旧的3K标准。当需要对指标生效的时候,系统提供“生效”设定功能。f) 检查指标分配:UORM在系统中,可以将本机构范围内的KCSA、KRI检查项给具体的某一个RP。根据检查频率,系统就能够自动为RP生成其应该进行的检查内容。4.2.2 风险及控制评估风险及控制评估是根据3K标准库的检查标准,对某个机构的风险控制情况进行检查,然后将检查内容进行逐级上报的过程。评估有五种形式:零线检查、一线检查、二线检查、专项检查、三线检查。1、 零线