招标公告
1. 招标条件
某保险股份有限公司反洗钱监控报送系统建设项目，招标项目资金来源为企业自筹，该项目已具备招标条件，现对反洗钱监控报送系统进行公开招标。
2. 项目概况与招标范围
2.2 服务内容：为反洗钱业务及规避相关风险所需，计划重建反洗钱系统，以提升数据质量，实现非现场监管报表、执法检查数据提取流程化和自动化，并降低运维、ETL工作人力成本。该项目实施地点为上海市浦东新区，项目周期为7个月。
2.3 服务期：合同签订后七个月内完成并上线使用。
2.4 招标范围及内容：
2.4.1基本要求
本项目主要内容为建设一套符合监管要求及某保险需求的反洗钱系统，以达到如下目的:
(1)实现与数据仓库等周边系统关联，提升数据质量
(2)反洗钱系统可提供接口供各业务系统使用，各业务系统可利用反洗钱风险监测数据进行风险识别控制
(3)实现客户信息稽核功能，降低监管处罚风险
(4)优化可疑模型，提升异常交易精准分析
(5)实现客户身份识别无纸化、电子化，节省人力，提高工作效率
(6)实现按照客户同一性原则管理客户、评定风险等级并与各业务系统实时对接
(7)实现非现场监管报表、执法检查数据提取流程化和自动化
(8)降低运维、ETL工作人力成本
平台要求架构设计合理，采用集群分布式部署，实现系统高可用性，保证用户管理功能稳健运行，完成统一用户数据规范及账号管理规范。使用可视化方式进行应用开发、部署，使系统应用、开发和维护方便，监控功能完善，售后服务优良。
反洗钱监管报送平台项目范围包括：
数据梳理
系统建设
时间要求：
合同签订后七个月内完成并上线使用。
源代码要求：
需要向甲方提供完整源代码。
源代码所有权归甲方所有。
2.4.2 工作范围
投标人应提供满足本招标书要求所必须的系统实施与服务。其中包括（但不限于）下列内容：
（1）按照招标文件和合同进度的要求，按时进行系统的安装、调试，开发、部署、应用集成、数据采集梳理和试运行工作。
（2）根据本项目目标要求，按照招标文件和合同的规定，进行系统的功能扩展及完善工作。
（3）负责本项目所有软件和系统的集成部署及实施工作。
（4）负责系统基础数据批量导入和转接工作。
（5）按照招标文件要求和合同规定，提供系统管理、用户使用、维护等培训。
（6）按照招标文件要求和合同规定，提供系统完整的各类技术文档和开发相关源码。
(7)提供系统验收方案并协助招标方进行系统验收工作。
(8)提供系统试运行期和质量保证期的变更与维护等技术服务。
(9)按照合同规定，在质量保证期内，提供电话技术支持和服务等工作，如招标方要求，必须应在24小时内，向招标方提供现场技术支持和服务。
(10)梳理客户信息数据，对数据进行整理清洗，补全等工作。
2.4.3 需求范围：
|
序号 |
需求名称 |
需求描述/说明（主要包括但不限于） |
|
|
1 |
作业功能 |
||
|
1.1 |
任务管理功能 |
||
|
★1.1.1 |
待办任务 |
能够展示用户各类待办任务，点击可快捷进入任务处理界面。对于即将超时的待办任务邮件提醒。 |
|
|
1.1.2 |
督办任务 |
总公司及分公司管理人员首页同时可以展示督办任务，点击可查看督办任务详情。对于即将超时的督办任务邮件提醒。 |
|
|
★1.1.3 |
已办任务 |
能够展示用户各类已办任务，点击可快捷进入已处理任务界面。已办任务处理时效作为绩效考核依据。 |
|
|
1.1.4 |
展示形式及功能支持 |
该模块下设待办任务、督办任务和已办任务子项。能够以高度可视化的方式展示待办任务、督办任务以及已办任务。实现待办、督办任务超时邮件提醒及待办、督办任务情况报表可导出。 |
|
|
1.2 |
资料库 |
||
|
★1.2.1 |
内控制度库 |
可上传公司反洗钱内控制度及相关部门业务流程，进行版本管理，支持查询、下载、删除等功能。 |
|
|
1.2.2 |
宣传培训 |
可上传、存档各级机构开展反洗钱宣传、培训工作情况，包括培训课件、宣传资料、开展活动照片等证明资料，并根据关键条件索引查询相关资料和信息。 |
|
|
1.2.3 |
反洗钱协查 |
可根据公司协查制度，记录反洗钱协查具体工作情况，存储相关资料。系统录入相关重要信息项，可具备上传、归类、特定维度统计分析、关键字查询搜索等功能。 |
|
|
1.2.4 |
法规及案例知识库 |
可提供人行等监管机关下发的各类法律法规、文件通知、复函、负面新闻报道、解读信息、支持性工具等信息库，可具备上传、归类等功能 |
|
|
1.2.5 |
监管收文 |
可上传、存档各级机构监管收文情况，包括银保监会各级监管局及人行各分支机构发文，如监管现场检查、走访、临时通知等资料，并根据关键条件索引查询相关资料和信息。 |
|
|
1.3 |
客户管理 |
||
|
★1.3.1 |
客户信息管理 |
该模块以客户为单位管理客户，实现全维度的客户视图，客户视图包含客户维度的所有身份及交易信息。可支持客户的基本身份信息、交易信息、历史风险评级情况、可疑交易、客户身份识别情况相关信息的查询、统计与导出功能。 |
|
|
1.3.2 |
展示形式及功能支持 |
客户视图具体内容包含客户基本信息、身份识别轨迹、洗钱风险划分轨迹、保单信息、赔案信息、大额交易数据抓取清单、可疑交易数据抓取清单、影像系统。可支持客户信息录入、修改及修改审核。客户信息与业务系统实时对接。（业务系统客户信息变更后同步至反洗钱系统。）实现客户信息变更历史留痕。客户证件可上传影像或与业务系统影像对接。 |
|
|
1.4 |
客户身份识别及身份资料保存 |
||
|
★1.4.1 |
功能构建基础 |
该模块功能在客户管理基础上，可汇总整理达到识别标准客户。 |
|
|
★1.4.2 |
子功能 |
客户初次识别、持续识别、重新识别、强化识别、受益所有人识别、客户尽职调查、客户身份证明文件到期提醒、客户接纳政策执行。 |
|
|
★1.4.3 |
客户信息稽核 |
根据客户信息校验规则、客户身份识别标准等规则，定期或不定期排查存量和新增客户信息的有效性、完整性、真实性，并作出整改提醒。能够实现整改任务下发及跟踪功能。 |
|
|
1.4.4 |
展示形式及功能支持 |
本模板下设客户初次识别、持续识别、重新识别三个子模块。在反洗钱系统中对核查结果处理、操作记录等情况建立处理工作流程，记录重要节点信息等。能够实现整改任务下发及跟踪功能及客户初次识别、持续识别和重新识别数据统计及清单导出功能。身份识别证明材料可上传影像。（可将信息不全的客户抓取出来，对数据进行阶段性整改补充，下发业务系统补充完毕后，可同步到反洗钱系统，保证各系统数据的一致性，年末或监管现场检查时可快速导出监管所需清单，清单模板要涵盖自然人9要素和非自然人23要素）（在持续识别环节中对客户证件过期的，可导出证件过期时间、更新时间、更新后证件有效期清单等） |
|
|
1.5 |
客户洗钱风险等级划分及分类管理 |
||
|
1.5.1 |
评估指标体系建设 |
根据客户特性（客户信息公开程度、存续时间、客户年龄、是否为监控名单客户等）、客户行业和职业、投保地域、业务风险（业务关系渠道、产品类型、保费金额）、客户风险事件等风险子项设计客户洗钱风险评估指标体系（五级），开发风险等级划分模型或赋值矩阵，可支持招标人实时调整（增加、修改或删除）风险子项以及权重。 |
|
|
★1.5.2 |
系统初评与人工评级 |
系统能够实现自动运算，并进行初步风险赋值，系统可将已完成初步风险赋值的客户自动分配给业务所在机构反洗钱工作人员进行人工初评与复评，可支持多维度批量划分功能。 |
|
|
★1.5.3 |
动态调整 |
系统支持根据客户身份识别、重新识别、持续识别、异常交易、异常行为等情形对客户风险等级进行动态调整。 |
|
|
1.5.4 |
后续控制措施 |
在洗钱风险评估和客户风险等级划分的基础上，系统支持对风险较高的客户采取强化的客户尽职调查和风险控制措施，控制措施指令及任务完成情况由反洗钱系统控制。 |
|
|
★1.5.5 |
定期重审 |
对于已确立过风险等级的客户，可根据其风险等级规划相应的重审期限，系统自动分配给业务所在机构反洗钱工作人员按照规定时限进行人工调整与重审。（首次三年、高半年、中一年、低2年或客户每交易一次，重新划分一次。） |
|
|
1.5.6 |
展示形式及功能支持 |
本模块下设客户风险规则、客户风险等级清单（含初评、复评时间）、客户风险等级调整、客户机构审核、客户总部审核、客户风险等级调整记录清单子模块。能够实现整改任务下发及跟踪功能。实现调整记录及风险等级划分、初评、复评历史留痕及清单导出功能。实现风险等级划分结果与业务系统对接。实现各风险等级之间人工调整、数量统计、任务提醒。 |
|
|
1.6 |
可疑交易管理 |
||
|
1.6.1 |
监测模型 |
根据招标人的业务实际设计开发可疑交易监测模型，模型具有高度扩展性，可支持招标人实时调整。（可疑交易模型，应当避免无效数据，加强模型有效性） |
|
|
★1.6.2 |
系统预警与人工审核 |
依据监测模型对业务数据进行跑批，对符合监测特征的业务进行预警，并触发人工分析与审核流程，经多级人工分析与审核（至少二级审核）后，针对无法排除可疑交易嫌疑的交易进行报文上报，针对可排除洗钱嫌疑的交易以及排除可疑嫌疑的分析过程进行留档。（增加可疑交易三段分析法，第一段身份信息识别简要描述、第二段交易及历史交易简要描述、第三段可疑交易定性） |
|
|
★1.6.3 |
报文管理 |
按照人民银行关于可疑交易的接口规范（V1.0）要求生成可疑交易报文，支持人工录入可疑交易数据，支持报文的增、改、删、补以及下载功能。 |
|
|
★1.6.4 |
回执管理 |
可疑交易报告回执分析、提示与管理。 |
|
|
1.6.5 |
展示形式及功能支持 |
该模块下设可疑交易新增、修改、处理、审核、可疑交易查询、可疑交易注销清单和可疑交易成功上报清单子项。能够实现可疑交易任务处理过程跟踪、系统留痕功能及数据统计及清单导出。上报、排除可疑交易分析过程可上传影像，任务处理完成后影像可查询、导出。能够实现同一客户、同一交易日期、同一可疑特征、同一产品项下所有可疑交易，批量注销、审核及上报。 |
|
|
1.7 |
大额交易管理 |
||
|
1.7.1 |
监测模型 |
根据招标人的业务实际设计开发大额交易监测模型，可支持招标人实时调整。 |
|
|
★1.7.2 |
系统预警与人工审核 |
依据监测模型对业务数据进行跑批，根据预设的大额交易监测标准对交易进行监测与预警，并触发人工分析与审核流程，经多级人工分析与审核（至少二级审核）后，确为大额交易的，应进行报文上报，确定不是大额交易的，应当将分析过程进行留档。 |
|
|
★1.7.3 |
报文管理 |
按照人民银行关于大额交易的接口规范要求生成大额交易报文，支持人工录入大额交易数据，支持报文的增、改、删、补以及下载功能。 |
|
|
★1.7.4 |
回执管理 |
大额交易报告回执分析、提示与管理。 |
|
|
1.7.5 |
展示形式及功能支持 |
该模块下设大额交易新增、删除、修改、处理、审核、大额交易查询、大额交易注销清单和可疑交易成功上报清单子项。能够实现大额交易任务处理过程跟踪、系统留痕功能及数据统计及清单导出。能够实现同一客户、同一交易日期、同一大额交易特征的所有大额交易，集中在同一日期同一大额交易特征下批量报送。 |
|
|
1.8 |
内部洗钱风险评估（产品） |
||
|
1.8.1 |
评估指标体系建设 |
根据招标人保险产品、业务及服务特性、技术手段等风险子项设计内部洗钱风险评估的定量与定性评估指标，可支持招标人实时调整（增加、修改或删除）风险子项以及权重。 |
|
|
★1.8.2 |
风险评估 |
可支持对接产品管理系统，也可支持手工录入产品名称、类型、定性指标等，当招标人报备新保险产品、开展新业务或公司治理结构、技术手段的调整对内部洗钱风险状况可能发生影响的，可通过系统进行内部洗钱风险评估。 |
|
|
1.8.3 |
后续控制措施 |
在内部洗钱风险评估的基础上，系统支持对风险较高的产品或业务采取控制措施，或下达控制措施指令。 |
|
|
★1.8.4 |
定期评估 |
间隔一般不超过三年，系统应支持定期评估规划。 |
|
|
1.8.5 |
展示形式及功能支持 |
本模块下设内部洗钱风险规则、产品风险等级清单、产品风险等级调整、产品风险等级审核、产品风险等级调整记录清单子模块。实现产品风险等级调整记录及风险等级划分、初评、复评历史留痕及清单导出功能。 |
|
|
1.9 |
监控名单管理 |
||
|
★1.9.1 |
黑名单及高风险名单 |
系统支持反洗钱黑名单、高风险名单筛查功能，系统支持命中黑名单业务实时挂起以及审核功能。 |
|
|
★1.9.2 |
名单回溯 |
支持黑名单回溯，及相关处理流程（风险等级调整、报送可疑交易报告等）。 |
|
|
1.9.3 |
白名单 |
支持白名单筛查及分类管理功能。 |
|
|
1.9.4 |
展示形式及功能支持 |
本模块下设黑、白名单人员及组织、黑、白名单国家或地区、失效名单子模块。实现黑、白名单模糊查询、导入、导出、审核和审批功能。 |
|
|
1.10 |
洗钱和恐怖融资风险自评估 |
||
|
1.10.1 |
评估项梳理 |
根据最新反洗钱监管规定梳理定性及定量评估指标，确定评估流程与方法，嵌入系统。根据固有风险指标、控制措施有效性指标开发自评估模型或赋值矩阵，可支持招标人实时调整（增加、修改或删除）评估指标以及权重。（五级） |
|
|
★1.10.2 |
自评估定量数据统计、查询与导出 |
系统支持《固有风险评估表》《控制措施有效性评估表》《剩余风险评估表》以及招标人自定义的自评估数据的统计、查询和导出。 |
|
|
★1.10.3 |
自评估定性数据手工维护 |
系统支持手工录入《固有风险评估表》《控制措施有效性评估表》《剩余风险评估表》以及招标人自定义的自评估定性指标数据。 |
|
|
1.10.4 |
展示形式及功能支持 |
系统支持手工维护数据，能够实现按机构与时间维度统计、提取、导出、审批功能。支持整改及上传证明材料功能。 |
|
|
1.11 |
执法检查数据管理 |
||
|
★1.11.1 |
执法检查数据提取与校验 |
根据《保险机构反洗钱现场检查数据接口规范》要求，提供16张表的文本格式或MYSQL等数据库文件格式。 |
|
|
1.11.2 |
展示形式及功能支持 |
系统支持执法检查数据的提取、校验。能够实现按机构与时间维度统计、提取、导出、审批及关键信息加密功能。 |
|
|
1.12 |
报表管理 |
||
|
★1.12.1 |
报表数据统计与导出 |
系统支持按机构与时间维度统计、提取和导出反洗钱年度报表及各类报表数据。 |
|
|
1.12.2 |
展示形式及功能支持 |
系统支持手工维护数据，系统自动统计汇总。支持机构各类报表个性化设置。（可嵌入年度报告、临时报告模板，随时根据工作进展录入，上报时可随时导出，快速制作报表，保证各监管报送数据的一致性） |
|
|
2 |
模型管理 |
||
|
★2.1.1 |
建模 |
针对可疑交易、客户风险等级划分、产品/业务、机构洗钱风险评估等项目建立参数、技术指标、监测标准并加工形成各类监测模型。 |
|
|
2.1.2 |
模型验证与优化 |
模型经投产与验证，需匹配招标人业务实际。 |
|
|
3 |
系统设置 |
||
|
★3.1.1 |
机构管理 |
系统支持对招标人系统内的机构信息进行维护，可对机构进行查找、新增、修改、删除、操作。 与核心系统机构管理模块对接，可同步机构代码等配置。 |
|
|
★3.1.2 |
用户管理 |
（1）支持包括对系统用户的查询、新增、修改、删除、重置密码功能； （2）支持对用户的停用和锁定功能； （3）支持以时间为维度导出用户清单以及变动情况等。 （4）作业功能各模块均实现业务类型区分产品线，方便不同条线人员处理，权责划分清晰。各级机构分级管理。 |
|
|
★3.1.3 |
菜单管理 |
树形结构显示所有系统功能菜单，可手动维护菜单层级、菜单名称、页面配置、显示顺序。 |
|
|
★3.1.4 |
日志管理 |
以列表形式显示所有功能的监控日志，可根据查询条件检索要查看的日志。 显示信息：监控项、操作人、开始时间、结束时间、处理时长、日志条数、最后目标表插入数据条数、是否正常 |
|
|
4 |
数仓管理 |
||
|
★4.1.1 |
建仓 |
可配合招标人建立反洗钱工作所需数据的数仓（拟与招标人其他系统合用数仓），并预留接口，以供招标人根据业务发展需要扩展其他可接入数据。 |
|
|
4.1.2 |
数据迁移 |
老系统中的存量数据，完整迁移至新系统中，以备监管检查。） |
|
2.4.4技术要求
（一）关键技术需求
根据永诚保险的技术规范和标准，反洗钱监控报送系统的目标系统架构的设计原则如下（包括但不限于）：
实现应用和数据的集中化运行与管理
分层次系统架构模型，表现层、业务逻辑层、持久层良好分离
采用普遍的安全控制机制，通用的可配置的认证体系
模块化设计，各功能模块符合高内聚、低耦合的特征。
（二）数据标准要求
反洗钱监控报送系统的相关数据标准参考行业已有的数据规范，根据永诚保险实际情况制定相应的系统数据标准。
（三）系统性能要求
供应商系统设计方案应能支撑反洗钱监控报送系统所涉及到的业务量，并满足以下性能要求：
|
应用场景 |
操作说明 |
响应时间 |
|
数据时效 |
业务数据展示的数据延迟 |
10秒 |
|
页面响应 |
展示页面的刷新时间 |
30秒 |
（四）系统可用性要求
持续工作时间，本系统为后台数据支持系统，要求7x24小时持续工作，可用性大于99%，若需周期性离线维护，要求供应商递交周期性维护及工作内容设计方案。
（五）系统适应性和灵活性要求
1、解决方案完全满足标书文件具体要求中描述的业务功能需求；
2、解决方案应具备按照用户需求变化，进行系统优化和再配置能力。
（六）系统安全和控制要求
1、供应商需提供系统信息安全设计方案，描述安全措施应在应用程序、传输、存储、数据管理、操作系统等多方面的实现方式。
2、应用系统应具有身份鉴别功能，提供登录认证和密码支持，密码设置要有强度要求和有效要求，特殊权限用户要求提供辅助安全设备。
3、应用系统应对数据的保密性、完整性和抗抵赖性有所保证。在数据输入时应考虑常见的sql注入、命令注入以及跨站脚本攻击等常见攻击的处理，在数据输出时要对用户权限进行验证再返回相应权限数据。数据应进行安全存储，其中敏感信息应进行不可逆的加密存储；
4、供应商应提交详细的报告，阐述系统运行出错时恢复系统的方法；
5、能够提供系统日志，满足审查系统和事务处理的要求；
6、供应商应保证实施结束后，供应商任何人员不具有超级用户权限，不经永诚保险授权，供应商无法操作数据库，否则，由此发生的后果由供应商承担全部法律责任；
（七）用户界面要求
系统的前端系统界面设计应遵循如下原则：
1、显示信息一致性的原则
2、以用户为主导的原则
3、出错信息和警告原则
4、信息显示原则
5、美观与协调性原则
（八）部署工具要求
供应商需要提供部署工具和脚本给永诚保险，以方便反洗钱监控报送系统开发和运维时进行快速部署。
（九）测试要求
系统应按照有关国家和行业标准进行严格的但愿测试、集成测试和用户接受测试等，供应商的项目团队中应有专门的测试团队，应制定详细的测试计划、测试方案并予以执行。
应建立严格的缺陷管理机制，系统上线后需要满足无一级bug；二级bug不超过5个/千行代码；三级以上bug不超过10个/千行代码的保证；四级bug不纳入考核范围内；
软件系统缺陷级别定义:
一级：
系统崩溃（跳出）或无法运行；
所实现的功能与需求完全不符；
核心功能未能提供合理的和可接受的结果以实现用户任务所期望的特定目标；
安装包在执行安装测试过程中异常退出。
二级：
1相同类型的缺陷在很多程序或模块中出现，需要改正每一个缺陷；
功能实现有错误
健壮性不强
实际的操作规程与操作手册上描述的规程不符；
安装包能够被顺利执行，但所需加载的数据不完整，导致系统无法正常运行。
三级：
不影响用户继续前进，但会带来不便
由于不充分的数据引起的不正确或不精确。
四级：
错误是表面化的或微小的，不违反实务，不影响软件产品的性能。
五、其他需求
（一）在项目实施完成后，提供一年免费的驻场维护服务。
（二）一年免费维护期结束后，后续服务费用双方另行议定。
3. 投标人资格要求
3.1 通用条件：
投标人须为公司及所属单位的合格供应商，且不处于供应商暂停投标的期限内（对于已在公司电子商务平台注册成为潜在供应商的，潜在供应商须通过集团公司、各二级单位或各基层企业审核成为合格供应商后方可参加投标。对于未在公司电子商务平台注册的供应商，首先应在公司电子商务平台注册成为潜在供应商，潜在供应商通过集团公司、各二级单位或各基层企业审核成为合格供应商后方可参加投标）。
3.2投标人财务、信誉等方面应具备下列条件：
(1) 没有处于被行政主管部门责令停产、停业或进入破产程序；
(2) 没有处于行政主管部门或公司系统内单位相关文件确认的禁止投标的范围和处罚期间内；
(3) 近三年没有骗取中标或严重违约，没有经有关部门认定的因其服务引起的重大及以上质量事故或重大及以上安全事故；
(4) 未被市场监督管理部门在全国企业信用信息公示系统中列入经营异常名录或者严重违法企业名单；
(5) 未被最高人民法院在“信用中国”网站()或各级信用信息共享平台中列入失信被执行人名单；
(6) 与招标人存在利害关系可能影响招标公正性的法人、其他组织或者个人，不得参加投标；单位负责人为同一人或者存在控股、管理关系的不同单位，不得参加同一标段投标或者未划分标段的同一招标项目投标。
3.3专项条件：投标人还需同时具备下列条件：
3.3.1 资质等级要求：营业执照（注册资金1000万元及以上）。
3.3.2 资格能力要求：企业总人数不少于300人。
3.3.3 投标方需以下资格证书：ISO管理体系证书、软件开发CMMI3以上证书。
3.3.4本次招标不接受联合体投标。
4. 招标文件的获取
获取时间：从2021年12月24日9:00起至2021年12月31日17:00止。
获取方式：【电子招标】www.dlztb.com
5. 投标文件的递交
【电子招标】
5.1 递交截止时间：2022年1月4日16时00分
5.2 递交方式：电子商务平台(www.dlztb.com)上传电子文件递交。
6. 开标时间及地点
开标时间：2022年1月4日16时00分
【电子招标】
开标地点：电子商务平台（www.dlztb.com）。到达开标时间后，在电子商务平台上集中解密。递交过程记录在案，以存档备查。
7. 其他
备注：公告查询以电力招标采购网www.dlztb.com为准！本网站为经营性收费网站。您的权限不能浏览详细内容,非正式会员请联系办理会员入网注册事宜，并缴费成为正式会员后方可下载详细的招标公告、报名表格等！为保证您能够顺利投标，具体要求及购买标书操作流程以公告详细内容为准
注：投标文件递交（提交）的截止时间同投标截止时间。电子投标文件逾期上传或者未成功上传指定信息平台，招标人不予受理。招标人和招标代理机构不对投标人上传投标文件失败负责。温馨提醒：为避免大量投标人同一时间内上传投标文件造成系统拥堵，保证投标文件成功上传指定信息平台，建议投标人至少提前2天开始上传，确保上传成功。