八项目验收考核要求.docx

八项目验收考核要求.docx

《八项目验收考核要求.docx》由会员分享，可在线阅读，更多相关《八项目验收考核要求.docx（20页珍藏版）》请在冰豆网上搜索。

八项目验收考核要求

项目需求：

附件1：

大数据平台及风险预警系统采购项目

需求说明书

天津滨海农村商业银行

2018年4月19日

大数据平台及风险预警系统采购项目

需求说明书

一、项目背景

近年来,大数据、人工智能等一批高科技被金融业应用，为银行业风险防控、提升效率等方面起到重要作用。

根据天津滨海农村商业银行股份有限公司（以下简称“本行”）业务的发展趋势，为了加快本行业务转型，风险预警，增值提效，提升本行决策的科学性，支撑本行未来5年的业务发展需要，本行急需建设大数据平台及风险预警系统，建立大数据准入和信用评估机制。

二、项目目标

基于大数据平台和外部数据建立一个范围覆盖授信全部产品、流程贯穿业务始终、监控涉及宏观微观的客户风险管理系统，建立贷前贷中贷后全流程风险预警和大数据准入和信用评估机制，需要实现客户风险视图、信息探索、信息收集、准入验证、反欺诈、信用评分、授信额度、贷后监控、催收管理等功能。

为了使大数据风险预警系统快速见效，与时俱进，稳步提升成效，建议分成二期实现。

一期目标：

完成对公风险预警系统、企业信用评估模型、大数据平台和外部数据管理平台的实施。

第一阶段：

基于大数据平台和外部数据建立风险预警系统，监测对公客户信用风险。

提供实时和批量的对公客户风险预警信号、客户视图、风险报告，包括但不限于企业信用风险预警，集团母公司、子公司、关联企业等关联风险预警，法人、高管、担保人、抵押人、抵押物等关联风险，对接对公信贷系统、柜面系统、ODS等业务系统，在贷前、贷中、贷后提供风险提示，预计2018年10月31日前上线试运行。

第二阶段：

根据客户、产品、行业、机构、区域等维度来监测不良率、逾期情况，对超过违约阈值的产品、行业、机构、区域进行提示，以便支持总行对产品、行业、机构、区域风险的总体把控和科学决策；将预警信号接入核心系统等实时交易系统，根据重大预警信号拦截交易，预计2018年12月31日前上线试运行。

第三阶段：

通过外部数据和行内数据建立小微企业信用评估模型，外部数据包括但不限于全国企业信用信息公示系统数据、天津市市场主体信用公示系统数据、失信被执行人、被执行人、国家税务数据、征信系统数据等，生成企业信用风险报告，辅助审批人员、贷后检查人员、客户经理对客户进行整体的风险评估，使相关人员对客户的决策有据可依，预计2019年3月31日前上线试运行。

二期目标：

完成个人风险预警系统、大数据准入和反欺诈、个人信用评估模型的实施。

建立大数据准入机制，实现准入验证和反欺诈，提供实时和批量的个人风险预警信号、风险视图、风险报告，包括个人信用风险预警，工作单位、担保公司等关联风险预警，担保人、抵押人、抵押物等关联风险，对接零售信贷、联合贷等业务系统，在贷前、贷中、贷后提供风险提示；通过外部数据和行内数据建立个人信用评估模型，外部数据包括但不限于反洗钱黑名单、电信诈骗黑名单、失信被执行人、被执行人、芝麻信用黑名单、公安黑名单、同盾反欺诈、法院涉诉黑名单，生成个人信用风险报告，预计2019年6月30日前上线试运行。

三、项目采购范围

3.1采购内容

1、大数据平台：

所选用的大数据平台系统软件产品，应是当前业内主流的发布版Hadoop产品，TDH5.1及以上版本或FusionInsightHDC70及以上版本；所提供的Hadoop大数据平台不少于4个节点，至少包含2个管理节点，3个数据节点，其中1个数据节点和1个管理节点可复用同1个节点，提供免费无限期测试环境4个及以上节点使用；需包含并不限于以下组件或同等功能组件：

HDFS、YARN、Hbase/Hyberbase、Sqoop、Kafka、Flume、ElasticSearch/Solr、Spark/Discover、Sparkmlib、Hive、HUE/Waterdrop、Oozie/Workflow、Redis、Stream/Flink/Storm、Inceptor企业版及以上。

2、风险预警系统：

提供对公客户和个人客户风险预警规则和信号；提供客户的集团母公司、子公司、关联企业、法人、高管、担保人、抵押人、抵押物等关联风险预警规则和信号；提供客户风险视图、客户风险报告。

3、驾驶舱风险监测：

根据客户、产品、行业、机构、区域等维度来监测不良率、逾期情况。

4、风险历史数据整合：

整合授信风险相关的行内、行外历史数据，形成风险历史数据集市；将数据指标化，指标配置化，为预警规则和模型的应用提供良好数据支持。

5、对接对公信贷、零售信贷、核心、柜面等业务系统，在贷前、贷中、贷后提供风险提示；

6、外部数据管理平台：

将通过API、网页、客户端等各种方式采购的外部数据统一接入大数据平台，以便外部数据落地，接口可配置化，实现外部数据统一管理。

7、建立大数据准入机制：

实现准入验证和反欺诈；生成各类黑名单。

8、个人信用评估模型，个人风险报告：

通过外部数据和行内数据建立个人信用评估模型，外部数据包括但不限于反洗钱黑名单、电信诈骗黑名单、失信被执行人、被执行人、芝麻信用黑名单、公安黑名单、同盾反欺诈、法院涉诉黑名单，生成个人信用风险报告，包括个人基本信息、关联信息、个人风险信息、关联风险信息。

9、小微企业信用评估模型，企业信用风险报告：

通过外部数据和行内数据建立小微企业信用评估模型，外部数据包括但不限于全国企业信用信息公示系统数据、天津市市场主体信用公示系统数据、失信被执行人、被执行人、国家税务数据、征信系统数据等，生成企业信用风险报告，包括企业基本信息、关联信息、企业风险信息、关联风险信息。

3.2采购要求

1、参数化管理：

提供用户可视的前台操作的政策配置管理界面，支持预警指标、预警信号、预警模型、预警参数、预警流程、预警审批授权的参数化配置。

2、对象化管理：

将“风险预警对象”和“风险预警信号”拆分为两个对象进行分开管理，明确预警对象和预警信号之间的关联关系以及风险预警信号触发预警对象的规则：

3、风险预警对象：

以客户为风险预警的基本管理对象；

4、风险预警信号：

选取客户各类风险因素的预警指标而设置的预警信号。

5、精细化管理：

对于不同规模、产品、行业、机构、区域等客户选取合理的预警指标，进行精细化、差异化管理，使预警指标针对性更强。

6、风险传导管理：

建立预警对象风险关联传导机制，对有关联关系的各类客户实现关联方风险传导的预警联动要求。

7、预警评价分析管理：

从产品、行业、机构、区域、客户等多个维度实现风险预警组合监测分析管理，支持预警政策表现后评价分析管理。

8、大数据平台搭建要求大数据厂商原厂实施，并提供至少一年免费的7*24小时技术支持。

四、技术要求

4.1总体要求

1、总体解决方案要求：

包含但不限于技术方案、集成实施方案、建议的Hadoop系统软件产品、交付内容、培训等内容，详细说明系统架构、网络架构和物理架构等设计。

2、实施进度要求：

响应人应保证在2018年10月31日前完成内完成项目第一期内容相关建设工作，应提供实施工作整体计划表，明确主要成员个人工作时间表，明确提供项目各阶段的工作范围、实施团队组织结构、双方成员构成以及成员职责，阶段性项目交付物，确保该项目能够按时完成。

3、项目实施团队要求：

在项目实施阶段，项目实施队伍是以响应人一方的技术力量为主，负责整个项目的设计、实施、进度和质量控制，对整个项目的完成进度和质量负责，项目实施队伍建设具体如下：

（1）项目管理人员应具有系统项目管理的实际经验和金融行业项目实施经验，能根据本项目要求制订出切实可行的项目管理流程和项目实施时间进度计划表，并严格实行，保障项目按进度高质量完成；

（2）响应人须为此项目成立专门的开发实施团队，根据实施计划，明确给出项目各阶段的工作范围、实施团队组织结构、双方成员构成以及成员职责；

（3）为保障系统上线后的平稳运行，在项目验收通过后，响应人应提供应急响应服务；

（4）请响应人给出应对实施团队人员变动风险的防范机制（包含与雇员的特别协定、应急预案等）；

（5）响应人应在响应文件详细说明承诺的实施团队的人力资源配置情况，对实施人员和项目经理的具体实施项目及参与程度应重点阐述；

（6）要求参与项目实施人员的数量应满足工作量和工期要求等实际需求；响应人须提供详细的人员名单（含）项目经理、技术骨干）、经历介绍等详细资料；

（7）采购人将对所提供的人员进行考察，达不到要求的将会被要求进行替换。

4、产品应具有自主知识产权，系统应采用自主知识产权开放式开发平台；

5、产品必须符合安全规范，软件部分必须满足人民银行、银监等相关文件要求；

6、需要技术实现的功能包括但不限于下面步骤：

（1）信用风险预警系统内的各种参数支持人工手动设置，无需通过修改程序或数据库实现；

（2）信用风险预警系统应能够灵活与行内其他系统对接；

（3）信用风险预警系统包括报表、监控、参数、日志和优化管理等；

（4）对于由于监管政策发生变化造成业务需求或者技术实现发生变化时，实施厂商应该负责进行协助修改，保证符合国家的监管要求以及满足业务的需求

7、系统服务端运行环境应支持Linux、Unix（Aix、Solaris、Hp-Unix等）等主流操作系统；支持与主流数据库集成，如Oralce；应用服务器支持Weblogic、Webshpere等中间件；

8、系统与我行其它信息系统具有良好的集成支持。

系统应采用开放式架构，支持多种程序接口方式，能够支持业务规则的动态加载；

9、系统应支持多任务、多进程并发处理，性能优异。

系统性能指标的设计应满足业务量出现跨跃式增长的要求，需要符合先进性、稳定性、安全性、扩展性的系统设计要求。

10、系统应提供7×24小时服务，为了防止系统的单点风险，系统必须能够提供负载均衡策略或者双机互备策略；

11、应保证数据在传输/存储过程中可靠、完整、保密；

12、提供完备的审计追踪功能。

对于业务处理流程，日志文件需要详细记录操作过程，系统需提供业务监控工具和预警工具，能查看业务流程情况，确定瓶颈位置，可进行人工干预；涉及系统的参数表的记录必须记录修改人和修改记录在案，以供事后审查。

4.2功能要求

4.2.1大数据平台及数据整合

搭建大数据平台，基于大数据平台及内外部历史数据建立风险集市，分布式存储结构化/非结构化数据，整合授信风险相关的行内、行外数据，为预警规则和模型的应用提供良好数据支持。

1、建立风险集市，整合授信风险相关的行内、行外历史数据，将数据指标化，指标配置化，为预警规则和模型的应用提供良好数据支持。

2、实现海量数据的低成本高效存储、加工、使用；大数据基础平台软件需要支持海量数据的分布式存储、处理，提供快速的数据查询、分析和处理能力；支持各类结构化、半结构化、非结构化海量数据的低成本存储，快速批处理加工；支持各应用系统的在线数据查询、统计分析、数据挖掘、海量历史数据存储和使用等需求。

3、支持企业数据类应用的迁移和优化重构；大数据基础平台软件需要支持各种应用从关系型数据库往大数据管理平台的平滑和低成本迁移，同时支持ODS应用技术架构优化重构以提供更强的公共数据信息服务能力。

并对应用迁移提供相应的现场技术支持

4、支持实时性强的高并发低延时数据服务需求；本行在移动互联渠道提供的客户服务逐渐丰富，客户点击流量增长快速，客户的体验要求也在提高。

大数据基础平台软件应能较好地支持移动互联业务场景高并发低延时的数据访问需求，包括通过流式计算框架对客户画像、客户个性化场景营销、实时风险监测、银行流动性风险实时预警、IT运维监控预警等需求实现提供技术平台支持。

5、支持本行自主数据探索和业务建模；通过良好可视化支持的工具软件，本行可编写简易的R语言数据处理和可视化程序，自主探索分析业务数据，利用机器学习算法对业务数据建模和验证，利用成熟的量化模型算法支持更科学的经营决策。

6、提供分布式综合搜索平台，满足分布式实时文件存储以及搜索。

7、软件相关支持服务；为更好发挥大数据平台的技术优势，同时确保系统平稳安全运行，需通过现场和非现场形式提供完善的产品业务培训和技术培训、运维支持、产品缺陷修复和产品升级、大数据技术架构咨询、应用开发指导等关联支持服务。

4.2.2风险预警系统

系统将实现对全行对公和个人信贷客户的信用风险预警、提示、拦截和监测，预警可能出现的风险包括工商变更、失信被执行、征信风险等风险，生成客户风险视图、报告。

1、预警生成及介入：

根据相关规则实时或批量生成预警信号、介入到授信贷前贷中贷后各个节点中，达到风险提醒或业务禁止的作用；可根据客户、产品、行业、机构、区域等维度监测预警情况和逾期不良情况。

2、预警处置：

发起、处理、认定、生效等预警信号的流程处理、分级管理、及时处理。

3、后评价体系：

规则评价、指标评价、决策评价、数据评价、信号等级评价。

4、客户风险视图、报告：

根据客户基本信息和客户风险，生成客户风险视图、报告，包括但不限于客户、产品、行业、机构、区域等维度的风险分析日报、月报、季报、半年报、年报。

5、风险信号补录：

除自动生成风险信号外，可通过人工方式补录风险信号。

6、日常管理：

客户基础报告、客户风险报告、驾驶舱、查询统计、分析报告。

7、用户管理、权限管理、机构管理、参数管理、数据源管理、规则库配置管理。

8、系统对接：

将预警信号接入核心、对公信贷、零售信贷、联合贷和柜面等业务系统。

4.2.3外部数据管理平台

1、管理外部数据源及其数据。

能够更方便的接入新的外部数据源；管理现有数据源，查询动作留痕，查询结果留痕；管理数据查询的权限，保证了行内客户等数据的按级别使用，按权限使用；一次查询，多部门使用，避免多部门的数据使用重复付费的浪费。

2、实现外部数据与行内数据融合，将数据指标化。

作为数据模型、策略的最小粒度，在基础指标的基础上配置式的开发衍生指标，使得业务人员既可以感性直观的看到数据指标、客户标签，也可以追溯到理性客观的实际数值数字。

3、实现模型配置化，策略工厂。

支持按不同的贷款产品、客群、场景，匹配不同的进件审核策略，并且将这些策略按照不同版本管理；在WEB页面，业务人员可以方便的拖拽化配置策略，省时省力。

4、接入人行征信、反洗钱黑名单、汇法网、公安黑名单、同盾欺诈数据、鹏元征信、芝麻信用、税务、水电等外部数据。

5、对接对公信贷系统、柜面系统、零售信贷系统，将企业基本信息等外部数据接入，减少人工录入，提高准确性，提高时效性，提升客户体验。

4.2.4准入及反欺诈

1、实现准入验证和反欺诈。

通过风险名单数据、身份数据、社会数据、信贷相关数据、社交数据等外部数据和内部数据，识别伪冒申请、虚假资料、内部欺诈和道德风险。

2、生成各类黑名单，实现准入信息验证，实时监测我行客户准入。

4.2.5个人信用评估模型

基于机器学习、人工智能方法建立个人信用评估模型，生成个人信用风险报告、个人基础信息报告、关联关系等。

根据对客户信息真实性、合法性、一致性校验，通过模型设计、数据准备、数据细分、推断、变量分析与降维、建立模型、模型评估实现自动化评估客户信用，识别高风险客户。

模型通过外部数据和行内数据建立，外部数据包括但不限于反洗钱黑名单、电信诈骗黑名单、失信被执行人、被执行人、芝麻信用黑名单、公安黑名单、同盾反欺诈、法院涉诉黑名单等。

4.2.5小微企业信用评估模型

建立小微企业信用评估模型，生成企业信用风险报告、企业基础信息报告、关联关系等，评估企业财务、经营状况、抵质押物、借新还旧等风险，辅助审批人员、贷后管理人员、客户经理对客户进行整体的风险评估，使相关人员对客户的决策有据可依。

模型通过外部数据和行内数据建立，外部数据包括但不限于全国企业信用信息公示系统数据、天津市市场主体信用公示系统数据、失信被执行人、被执行人、国家税务数据、征信系统数据等。

4.3运行环境要求

系统服务端运行环境应支持Linux、Unix（Aix、Solaris、Hp-Unix等）等主流操作系统；支持与主流数据库集成，如Oralce、DB2；应用服务器支持Weblogic、Webshpere等中间件;应支持Hadoop大数据平台的HDFS、YARN、Hbase、Sqoop、Kafka、Flume、ElasticSearch/Solr、Spark、Sparkmlib、Hive、HUE、Oozie、Redis、Flink/Storm或同等功能组件。

4.4集成要求

集成外部数据平台和报表平台，详细描述系统可集成的外部数据平台（包含数据仓库平台等）和报表平台的种类和集成的实现方式、支持的程度。

支持主流第三方BI、ETL等工具并说明支持的工具列表。

软件升级，详细描述服务器端、客户端软件升级的方法、步骤。

系统监控的要求：

1、提供CPU、内存、硬盘、网卡等硬件状态监控以及告警。

2、提供一键式的信息收集工具，收集系统日志、配置信息以便于快速定位。

3、要实时监控系统运行情况，及时发出故障警告，定位故障点。

4、支持图形界面实现分布式系统资源监控，包括获取存储量、剩余存储量以及存储系统整体情况信息。

5、提供文件系统使用情况、数据库使用空间的监控功能，提供瞬时值和一段时间的变化情况，提供曲线图。

提供根据历史变化情况预测剩余存储空间还能够使用多长时间的功能。

6、提供软件产品服务进程的运行情况监控，发生服务失效或宕机的情况予以告警，并提示不能正常运行的服务或进程。

7、提供消息队列的处理情况监控，发生队列堵塞予以告警，并提示不能正常处理的消息队列。

8、告警管理功能，出现问题节点及时告警，并提供主动诊断功能。

具备对历史告警信息的审计功能。

4.5性能要求

支持高性能计算处理，且性能应能随节点数呈线性增长。

说明具体实现方式、适用场景和使用工具技术等，并说明节点数和性能的关系。

提供平台并行及并发处理能力的实施方案。

详细描述支持多服务器、多CPU、多进程并行、并发处理数据的机制，以及系统解决并行处理方面主要瓶颈和限制因素的措施。

提供具有图形化的性能调优工具，并提供持续调优的策略、方法。

系统应能满足：

●存储数据不少于1PB，常用数据不少于50TB。

在服务器配置为2C8核CPU，128G或以上内存，硬盘为300G*4个SAS硬盘、2T*20个SATA硬盘，2个双口千兆网卡（光口）或以上的条件下，数据检索响应时限要求如下：

●在单个服务器并发1000情况下，按关键字检索单表记录响应时限<=20ms，并提供测试的具体结果；

●在单个服务器并发200情况下，按关键字检索多表关联记录响应时限<=200ms，并提供测试的具体结果；

4.6扩展性要求

支持数据量弹性伸缩，考虑数据量增大或者减小情况，存储容量能够动态不停机扩容，扩容时现有系统可以不间断正常运行，不受扩容影响。

扩容时无需迁移数据，避免硬盘和数据损坏。

详细说明实现方式。

提供灵活的扩展，如复杂数据类型，扩展函数和脚本等。

支持在线的节点变动，单个集群可线性扩展不少于50个计算节点、至少能处理300TB数据量，并能满足系统性能指标要求，在线增加、删除节点时，能支持数据和索引的倾斜探测和自动平衡功能，保证平滑扩展和性能的线性增长，详细说明实施方案。

4.7可靠性和可用性要求

1、可靠性

不允许存在单点故障，应采用高可靠设计架构，任一节点出现故障时，不影响应用的正常运行，并在监控页面上对错误状态进行显示标识。

实现数据的安全与完整保障，平台保证稳定可靠的运行，在平台系统出现问题时，应保证数据的完整、可恢复以及事务的完整性。

2、故障处理

说明任一节点故障后的处理机制，以及各环节处理的延时，同时说明集群允许多少个节点同时发生问题。

发生硬件故障时，系统能够自动检测错误并修复数据，无需人工干预，即使机器未修复，系统仍然能够不间断正常运行；支持细粒度的出错处理，对长时间的查询/分析任务，发生故障后无需重新运行应用，系统只需要单独运行失败的子任务即可，在故障情况下可极大缩短应用处理时间。

对于故障硬盘，支持硬盘热插拔，大数据平台无需人工干预，完成磁盘更换。

3、可用性

系统可用度：

应达到99.9%，系统可用度=系统无故障运行时间/（系统无故障运行时间+系统故障维护时间）。

系统应支持备份与恢复功能（包括主机、操作系统、数据库与应用软件等），数据备份和恢复方案要保证数据的完整性，备份和恢复的有效性。

应用软件恢复时间不超过2小时。

系统采用高可用性集群方案，应能提供7×24持续服务，详细描述应用层和数据层面的集群机制、负载均衡或切换机制，并阐述对主流操作系统和集群方式的支持方式。

4.8开放性和兼容性要求

1、平台开放性：

支持Hadoop发布的多个版本，要求支持部署HDFS、YARN、Hbase、Sqoop、Kafka、Flume、ElasticSearch/Solr、Spark、Sparkmlib、Hive、HUE、Oozie、Redis、Flink/Storm等各种知名的Hadoop开源组件或同等功能组件，提供系统截图，作为证明材料。

支持常见软件产品集成。

2、接口开放性：

应提供标准JDBC（包括JDBCtype4driver）、ODBC驱动，ODBC驱动至少兼容linux、windows（64位）。

3、兼容通用硬件：

应支持运行在X86架构的通用PC服务器上。

4、兼容通用操作系统：

应兼容主流的Linux操作系统（SuSe、RedHat、CentOS）。

5、兼容接口：

大数据平台组件需要兼容对应开源组件开发接口；大数据平台需要兼容标准JDBC、ODBC接口；大数据平台需要兼容标准SQL/存储过程语法，降低迁移成本，方便平滑迁移。

4.9安全性要求

满足访问安全、控制安全、数据安全、网络安全、数据库安全、事后追踪、审计安全要求。

4.9.1安全审计的要求

1、系统应具有完备的审计功能。

2、应具有完备的日志记录和适当的分析功能。

3、对平台软件试图进行的非法操作应能记入日志。

4、平台应保障操作安全性，并有重放检测、抗抵赖机制设计。

4.9.2数据安全性的要求

1、支持根据数据的不同分级分类，采取不同的数据存储、传输方式、访问等审核机制。

2、系统应确保数据正确、完整，对关键数据进行加密存储

4.9.3访问控制的要求

1、提供不同等级的访问策略。

实现业务访问控制和系统访问控制功能。

2、实现统一的权限管理，详细说明实现方式；

3、应用系统对用户角色权限设计和重要角色分配应能够体现职责分离的安全制约原则。

4、平台用户变更、权限变更等重要操作应定义审核流程。

五、服务要求

投标人需在合同期内提供完善的软件产品售后支持服务，包括但不限于如下内容：

5.1现场服务与支持

项目实施：

投标人必须服从招标人的统一协调，在招标人要求的时间内保质保量完成各项工作。

完整合法性：

投标人为招标人提供的产品必须完整，各种介质和文档齐全。

此次项目由采购人与投标人合作，软件所有权归采购人所有。

投标人必须提供平台软件全部源程序及相应开发工具、自有产品及开发平台等，并保证其合法性，由此产生的所有争议和法律问题由投标人负责，由此产生的全部费用由投标人负责。

合理可行性：

投标人必须对项目方案选择的合理性和技术可行性进行确认和保证。

现场支持服务：

项目实施期间如遇到影响进度问题及难题，投标人须按招标人要求提供现场支持服务。

5.2培训服务

1、培训要求：

响应人应确保在系统开发和建设中所提供的培训是全面而系统的，包含了系统的开发、维护和使用等培训内容，培训的主要对象是系统的使用者和技术支持人员，培训地点由本行指定，响应人应为培训提供：

培训教材，中文版、培训计划。

2、培训计划：

（响应人需在响应文件中提供具体培训计划）

培训时间

培训地点

培训内容及要求

培训教员

参加人员

备注