天津滨海农商银行2doc.docx

天津滨海农商银行2doc.docx

《天津滨海农商银行2doc.docx》由会员分享，可在线阅读，更多相关《天津滨海农商银行2doc.docx（7页珍藏版）》请在冰豆网上搜索。

天津滨海农商银行2doc

天津滨海农商银行

运营操作风险预警系统项目

建设需求方案

——内部文件—-

——注意保密——

1运营操作风险预警系统

1.1项目背景

目前，我行不断推进智能化转型,运营管理改革持续深入，智能设备的普及、远程授权、集中作业、互联网客户自助服务等使银行运营风险的特征发生明显变化，运营风险管理理念、目标、管理体系已经重塑，但在落地执行中还面临几大障碍，如监督检查技术手段不足、缺乏对已收集数据的整合挖掘、风险管理视角单一、效率质量不高、达不到要求致使监控手段大量依赖人工。

1.2建设目标

通过运营操作风险预警系统的建设,可以对互联网交易、自助设备交易、网点传统交易，实时交易数据、历史交易数据、人工数据，自动实时地计算分析可疑事件.达到及时发现风险事件的目的，从而使集中业务处理、后台监督管理能够进一步协调，突破传统运营风险控制主要依赖人工及事后的局限，转变为预警模型驱动的主动方式。

运营操作风险预警系统应具备独立的规则引擎系统，可实现规则的灵活配置,同时具备规则导出的能力,未来可将规则方便快捷的移植到我行统一的规则引擎平台。

同时可以广泛应用流处理和分布式存储技术,可充分运用我行现有的大数据平台的计算及分析能力，使用先进、成熟和可扩展的算法实现模型，具备直观快捷的展示方式。

运营操作风险预警系统的运用可全面统筹检查资源，实现对运营风险管理的覆盖，提升风险管控能力，降低风险水平,节约风控资源、改善服务品质的目的。

1.3建设方式

平台应是供应方先进成熟的框架，供应方负责系统部署,为我行提供完备的数据接入方案以及数据提取工具和提取方法,为我行技术和业务人员提供系统的培训和支持。

我行依据供应方接入方案进行数据收集、清理、规范、模型建立和训练的工作。

供应方的原型系统应用一定数量的风险模型，数据接入后经过适当的调试即可进行正常的运算分析,模型可以计算出正确的结果。

1.4功能模块

1.4.1预警监控模块

主平台的核心功能,是规则模型计算运行、数据收集整理分析的功能模块。

1.要有防范客户欺诈和内部员工作案的模型，重点突出连续性、关联性问题。

模型覆盖员工行为、客户管理、账户交易等。

模型应包含但不限于下列内容:

Ø监控同一客户（包括同一银行卡、手机号码、身份证等）连续开立多个Ⅱ、Ⅲ类银行账户.

Ø监控同一持卡人大量办卡账户。

Ø监控频繁开销户.

Ø可疑类交易模型的监控、预警和报告。

Ø大额交易模型的监控、预警和报告。

Ø欺诈开户的模型要求

Ø短期内资金分散汇入集中转出.

Ø违规交易事件告警和风险事件报送机制。

2。

预警监控方式需支持实时预警、准实时预警、日终预警

（1）、积累数据触发预警（）等。

3.对预警信息处理支持交易阻断、特定交易限制、向客户发送短信、客服外呼等进一步处置。

4。

提供黑、白、灰名单建设模板，帮助我行实现对客户、账户风险分级控制，能对接或导入对账、反洗钱、支付结算、行内信用记录等内部数据和企业信用信息黑名单、不良信用记录等外部数据。

名单要素配置要灵活、能及时生效.

5.关系展示：

能够以客户、账户、联系电话、地址、员工、法人、实际控制人等为节点展示关联关系、资金流。

6。

人员权限设置、模板配置、要素配置等有关参数调整的系统记录需完整,便于查看.

1.4.2监督检查管理模块

实现检查工作标准化线上管理，“自查”、“日常监管问题处理"、“专项检查"三个检查途径汇总处理日常问题并进行整改。

主要功能是多级机构的人工检查任务设立、分发、检查成果记录和收集、数据统计等。

1、统一问题台账登记。

对问题记录要素进行规范，同时可以满足风险预警事件记录、业务监督差错记录、非现场检查问题记录、现场检查问题记录、监管部门检查或行内其他部门检查问题记录。

记录可通过系统对接、单笔录入、批量导入和导出。

2、检查工作管理。

检查方案、检查通知书、工作底稿、事实确认书、整改报告、检查情况通报按机构进行管理。

3、报告管理。

支持下级向上级报送报告,可以对各级报告进行统一管理.

4、通知管理。

可以给下级发送通知的功能.可以按层级控制查看范围。

可以接入邮件系统。

5、电子登记簿。

将工作日志、查库登记簿等进行电子化管理，支持导出打印。

1.4.3考核管理管理模块

对纳入平台管理的运营人员、机构，结合设定的相关考核标准，对照人员业务（工作）量等进行考核管理，在设定的时间对全行运营监管工作按人员、机构进行分类及综合考核并输出结果。

主要功能是依据预警监控模块、监督检查管理模块的结果，对各级机构进行平价的模块。

1.4.4资源库管理模块

分为制度文件库、案例库、试题库、其他学习资料.能够按机构人员限定使用权限，能够灵活地被其他模块引用。

主要功能是为预警监控模块、监督检查管理模块、考核管理管理模块提供法规、制度支持的模块,资源库中保存了各种法规制度条目,应具备法规制度条目的时效控制和更新补充功能。

2实施服务要求

2.1人员要求

1、要求公司方有丰富经验的技术人员，承担项目的总体管理、资源协调、重大事件决策等。

2、质量经理和测试经理,全程负责项目质量管理工作、配置管理工作、测试组织工作；测试工程师，全程参与系统的测试过程。

3、所有人员均需在招标方指定工作地点办公。

4、合作方参与项目实施人员的数量应能够保证项目进度与质量；投标方须提供全体项目组成员的工作简历及客户方证明人联系电话,提供虚假信息的其投标将被视为无效。

投标方要严格按照人员名单及时到位，并保证主要项目人员在项目实施过程中全程在位。

5、所有成员需征得招标方书面同意后才能更换，项目经理、项目组骨干成员在整个项目实施过程中除招标方要求外不得更换。

6、投标方投标时需明确项目组人员名单和简历，简历必须真实.

2.2测试要求

投标方必须提出测试方案,提供相应的测试案例,且在测试方案征得招标方同意后，完成测试。

包括单元测试方案、集成测试方案、用户测试方案、接口测试方案、系统安装测试方案、系统性能及优化测试方案等.投标方在交付测试前需自行完成功能性测试。

2.3文档管理要求

要求使用专门的文档管理工具对项目文档进行管理。

在系统生命周期的各个基线上,都要求有相应交付的文档、数据或程序，需要采用系统的方法以保持不同阶段的软件配置的一致性和完备性。

这里所指的项目文档包括项目建设过程中规定的提交物，包括正式版本、重要的中间版本，会议纪要、测试文档、项目状态报告、沟通登记、问题报告等.

2.4保密义务

投标方将严格遵守招标方关于保密方面的规定，自觉保守招标方的商业秘密.招标方为方便项目实施所提供给投标方的工作流程、管理模式、试验数据、规程、程序等相关资料文档以及开发过程中所产生的资料、文档、数据均属于招标方知识产权，未经招标方授权同意，投标方不得另作他用。

因投标方原因导致上述资料、文档、数据或招标方商业秘密泄露的，招标方有权要求投标方采取措施消除影响，并赔偿招标方损失。

2.5培训要求

1、投标方应负责我方业务、技术人员的培训，培训内容至少包括以下方面：

现场培训:

投标方负责系统管理员进行现场系统的软、硬件配置及安装调测培训。

操作维护培训：

对操作人员进行统一的系统培训:

安装、调试、操作、维护、故障排除等,并使其熟悉系统的使用与维护，以及各种软件均需要提供足够深度的高级培训，保证完成技术移交；并提供全套的培训教材和培训课程计划表。

投标方应免费提供招标方业务人员和技术人员的技术及业务培训。

在项目实施过程中投标方至少需提供以下文档（电子文档）：

系统安装手册：

作为系统安装工作的指南；

系统维护手册：

必须包括安装及准备步骤、说明书、原理及操作，包括维护步骤、故障应急处理流程；

系统用户手册：

必须详细介绍系统全部产品的配置、连接方法、操作方法，提供对系统操作步骤的详细说明，包括可能发生的错误/诊断/报警信息；

2、投标方应负责配合我方完成业务操作人员培训工作。

3、投标方负责提供培训教材,投标方在建议书中应提供培训计划（其中应注明每次培训课程的时间、人员及课时）、培训大纲（其中应注明每次课程的内容和目的）。

4、投标方应保证在现场培训期间，受训人员在投标方的指导下所能做的一切操作均不会对系统构成损害。

否则，所造成的损害由投标方负责。

2.6售后服务要求

1、投标方在完成合同所规定的服务后,需提供一年的免费售后服务。

2、对应用软件及相关自主产品提供至少一年免费保修及系统技术支持服务。

3、投标方须提供至少一年以上的应用系统中所使用的自主软件产品的免费版本升级及功能更新服务。

4、对随系统提供的硬件（如有）须有一年的免费质保及免费上门维修服务。

5、投标方应提供7*24小时技术支持热线电话，在接到报修通知后1小时内响应，2小时内无法解决问题,需于8小时内派人员现场处置,并必须连续进行，直至故障排除完全恢复正常服务为止.在故障解决之后，投标方应将故障现象及原因、处理过程和方法、完成处理及恢复正常的时间和日期等以书面形式报告招标方。

6、解答招标方提出的问题.如出现紧急技术问题，在招标方通过电话或传真通知投标方的情况下，投标方的工程师应在30分钟内予以响应,8小时内赶到现场（如需要），24小时内提出解决方案，并继续与招标方沟通,直至解决问题。

7、维护期内，投标方提供服务所产生的一切费用均由投标方承担,当系统出现故障时，由于投标方人员未在规定时间内赶到现场进行维护而给采购单位造成了经济损失，则投标方有义务通过协商给予采购一定的经济赔偿。

8、投标方应负责解决所供系统出现的任何故障，以及合同或需求分析确认文件中规定的但在运行中证实未满足的功能、性能要求，并需要得到最终用户的签字认可。

9、维护期内的缺陷未解决,维护期应相应延长,具体延长时间由双方协定.

10、投标方组织进行相关的培训、技术交流等方面的活动时，如招标方人员有意愿参加时，安排其参加，并在费用方面给予优惠。

11、方式：

不限次的电话、电子邮件、现场故障排查和问题解决。

12、维护期结束后，投标方应提供不高于合同规定的维护服务价格、服务标准的维保服务，可供招标方选择签订.

2.7系统版权要求

1．招标方拥有在本项目中由投标方提供的应用程序及相关数据和文档的使用权。

2．投标方承诺所涉及第三方产品的知识产权/版权由投标方负责办理,并取得原知识产权/版权人的授权.

3．由于投标方未取得原产权/版权人的授权，造成招标的损失由投标方负责。

2.8项目管理和验收要求

1、项目管理要求:

投标方应提出详细项目实施方案，对项目实施内容、周期、进度计划、测试计划（包括功能性测试、非功能性测试、压力测试等、人员安排等具体要求作出详细说明.根据我行系统实施的时间要求和基本的业务要求，对我行实施的具体业务范围和系统功能范围提出建议，并依据该范围制定相关的系统开发和实施方案。

2、系统验收要求：

1）在项目验收前，将以下资料文档汇集成册交付招标方（含电子文档），招标方只有所要求资料齐全后才予验收。

相关的系统软件，第三方软件及文档，包括:

软件安装盘、安装与配置手册及开发手册.

投标方自主产品软件及文档,包括软件和应用安装介质、安装手册、开发手册、产品维护手册及产品编译手册。

项目文档，应包括项目各阶段的文档，包括但不限于《项目计划书》、《业务需求说明书》、《项目概要设计说明书》、《数据库设计说明书》、《测试计划》、《测试案例》、《测试报告》、《运行维护手册》、《操作手册》等。

2）验收实施阶段，投标方与招标方共同提出验收大纲（验收的具体标准、方法和步骤），该验收大纲经招标方确认后方可作为最终验收标准的依据。

招标方负责本合同服务内容的验收。

3）招标方有权组织由其工作人员或聘请的专家组成的不少于2人的验收小组对投标方进行验收.如验收小组中有50％以上成员认为投标方提供的服务不符合验收标准，则视为投标方提供的技术服务验收不合格。

验收合格的，招标方应出具验收证明交付投标方。

4）验收不合