车险理赔反欺诈系统方案文档格式.doc
《车险理赔反欺诈系统方案文档格式.doc》由会员分享，可在线阅读，更多相关《车险理赔反欺诈系统方案文档格式.doc（32页珍藏版）》请在冰点文库上搜索。
3.2系统架构 24
3.3技术框架图 26
3.4运行环境 27
第4章售后服务 30
4.1维护责任期 30
4.2服务方式 30
4.3服务内容 31
4.4项目维护小组 32
4.5项目技术培训 32
第1章项目概述
1.1建设背景
近年来，车险欺诈问题日益突出，严重影响了保险公司车险业务的健康发展。
那么如何来判断一起理赔案件是否属于欺诈行为？
如何来遏制和减少这种欺诈理赔案件的发生呢？
如何给办案人员提供一个判案的依据呢？
对于以往来说，各保险公司只能看到自己公司受保的车辆信息，看不到其他保险公司相关的车辆信息，这样看到的信息具有很大的片面性，影响了判案的依据。
为此提出车险理赔反欺诈系统的建设方案，其目的是为了实现各保险公司车险信息部分共享，通过对案件及车辆的分析、比对、筛选，列出风控名单，以便对理赔案件作一个更好更直观的判断。
1.2建设目标
通过反欺诈系统，办案人员可以通过比对规则的设置，系统根据这些设置好的规则，进行数据的分析，最后列出符合规则的风控名单。
案件轨迹分析分别以车和人为研究对象，根据限定的条件，对数据进行分析。
这些名单及数据分析的结果具有一定的案件分析价值，可以给办案人员一个判案的依据，同时避免了办案人员查看大量的数据，从而提高了工作效率。
第2章需求分析
2.1数据管理
本模块主要是数据的导入及维护。
2.1.1数据导入
本模块主要是实现数据导入接口，支持以Excel方式导入数据。
现有保险公司的数据以案件为主进行存储，一条案件记录中有可能包含多车信息，而本系统主要以车辆或是驾驶员为主要分析研究对象，因此需要对案件记录进行拆分，拆分成以车辆的案件信息进行存储，即一条案件记录可能要拆分成多条车辆的案件记录。
一条案件记录拆分后，系统以赔案号做为拆分后的多车辆记录来关联。
数据导入验证：
数据导入时对赔案金额做数据格式验证，验证是否为数值型。
由于数据量较大，为了导入效率，其他字段不做校验。
拆分后的字段信息，如下表：
字段中文名称
类型
长度
说明
案件号
字符型
100
保险公司
车牌号
20
车架号
50
车型
10
事故角色
分为两种：
1、标的车
2、三者车
事故时间
日期型
30
格式：
yyyy-m-d
事故地点
200
事故经过
2000
修理厂
驾驶员
驾驶证号
驾驶员联系方式
车主姓名
身份证号
车主联系方式
结案时间
赔偿金额
数值型
14，2（保留小数点后两位）
查勘员
查勘员身份证号
备注
1000
导入时间
系统时间
修改人ID
系统自动记录操作人ID
报案人
预留字段
报案电话
报案时间
案件类型
案件状态
起保日期
终保日期
险种类型
号牌种类
2.1.2数据填充维护
1、自动填充
一条案件记录拆分后，三者车的信息不够全面，需要对该车案件信息进行填充。
Ø
填充时间：
每天执行一次，只填充三者车信息不全的数据。
填充的字段：
保险公司、驾驶员、驾驶证号、驾驶员联系方式、车主、车主身份证号、车主联系方式。
2、自动删除重复记录
对于一个具体的案件，有可能出现数据多次录入的情况，比如平责、主次责的事故案件，各家保险公司可能都录入这个案件，这样就会导致车辆记录重复的问题。
如果把这个功能放在数据导入的时候验证的话，将会影响导入的效率。
所以系统将设定在一个比较空闲的时间段，自动对导进来的数据进行检验判断，对于冗余的数据将删除到临时表中，临时表支持恢复数据的功能。
校验时间：
每天执行一次，只校验当天导入的数据。
校验规则：
案件记录会重复的情况只会出现在两车以上事故，所以以某条案件记录的标的车的车架号、事故时间，以及其对应的三者车车架号进行分析检索。
分析检索时如果出现另外案件号，其标的车车架号刚好是该检索条件记录的三者车车架号，其三者车车架号又刚好是该检索条件记录的标的车车架号，也就是说事故角色刚好反过来，而且事故时间相吻合，拆分后的车辆数也吻合，那么说明这两条案件记录是一样，可以删除其中的一条。
其中事故时间各保险公司填写上可能会有出入，所以要求精确到日即可。
删除的记录可以在回收站中找到。
回收站有数据还原的功能。
3、手动维护
导入的数据可能出现数据不全或出错的地方，本模块的功能就是可以对导入的数据，进行修改或删除。
查询条件：
保险公司、导入日期、事故时间、车牌号。
显示字段：
案件号、保险公司、车牌号、车架号、事故时间、事故地点、导入时间、修改人。
2.2综合查询
根据查询条件对车辆或案件等信息进行检索。
2.2.1信息检索
通过输入查询条件，可以检索到案件相关的车辆信息。
查询结果支持导出Excel及打印功能。
案件号、车牌号、车架号、车型、碰撞部位，驾驶员，车主、事故角色，事故地点，事故时间、保险公司、修理厂。
其中碰撞部位、事故地点采用模糊搜索。
排序：
信息显示以案件号和车架号来排序。
查询出来的结果，点击列表表头支持排序。
显示的字段：
案件号、车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、修理厂、驾驶员、车主、保险公司、理赔金额、查勘人员、备注。
染色：
如果检索出来的车辆信息或人员信息有被列入系统黑名单当中，那么要对该车牌号和人员姓名列表框进行染色。
页面显示效果如下：
2.3比对分析
根据系统定义的特征库进行规则匹配设置，再由系统根据这些规则自动分析检索出具有分析价值的风控名单，包括车辆和人员信息等。
2.3.1特征库管理
在定义特征库的时候，需要定义下面一下信息：
1、特征库名称（必填），
2、特征定义:
选择一条特征，并对这条特征进行定义，定义完之后可以保存。
注：
1、时间段：
时间段采用24小时制，比如20:
00:
00到6:
00这个字段自动关联的是事故时间。
特征库列表显示效果如下图：
特征库添加页面效果显示如下图：
特征库配置举例：
情景
情景描述
配置说明
情景1
赔偿金额超过5000
特征名称：
赔偿金额超过五千
特征定义：
赔偿金额大于等于5000的案件
情景2
碰撞部位是底盘
碰撞部位-底盘
碰撞部位是底盘的
情景3
6个月内出险3次以上
6个月内，同一车辆碰撞次数超过3次以上
情景4
驾驶多车出事故
一年内，同一个驾驶员驾驶3辆以上不同的车出事故
2.3.2比对规则配置
特征库配置完之后，我们就可以根据特征库列表进行一个比对规则的配置。
选择一条或多条特征，组合成一个比对规则，比对规则可以选择以车或者人为分析对象，也可以两者全选。
可以创建多条比对规则，比对规则同样支持增删改操作。
规则配置界面效果如下图：
选中特征库列表中的一条或多条特征，点击保存，就可以创建一条比对规则。
比对规则创建完成后，系统将跟据比对规则，自动检索符合条件的数据，并把结果保存到比对结果表中。
不同的比对规则可能检索到同一车辆记录或者同一个人员记录，对于相同的车辆记录（以车架号为判断准则）或者人员记录（以驾驶证号或身份证号位判断准则），系统将采用叠加的方式，把该车或人记录到风控名单表中，并记录该车或人员被比对的次数，这样可以突出高风险的车辆或人员。
比对结果表字段：
ID、车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、驾驶员、驾驶证号、车主、车主身份证号、修理厂、赔偿金额、查勘人员、保险公司，比对规则ID，比对规则名称，比对日期。
风控名单表字段：
类型（1、车辆名单2、人员名单）、车牌号、车架号、车型、人员姓名、证件号、联系方式、比对次数。
2.3.3风控名单查询（比对查询）
风控名单分为：
车辆名单和人员名单。
点击“明细”，可以看到该车或人员比对的详细记录。
车辆名单显示字段：
比对次数、车牌号、车架号、车型。
车明细显示字段：
车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、车主、驾驶员、修理厂、查勘员、保险公司、比对规则、比对时间。
人员名单显示字段：
比对此时、人员姓名、证件号、联系方式。
人员明细显示字段：
驾驶员、驾驶证号、联系方式、车牌号、车架号、车型、车主、事故角色、事故时间、事故地点、事故经过、修理厂、查勘员、保险公司、比对规则、比对时间。
明细页面显示效果：
2.4案件轨迹分析
案件轨迹分析其实就是对数据进行分析挖掘，通过不同的查询条件来组合，对数据进行层层筛选，根据一定的比对条件和规则，最终检索出具有分析价值的车辆或人员信息，再与某个案件进行关联，实现案件的轨迹分析。
案件轨迹分析分为：
车辆轨迹分析和人员轨迹分析；
车辆轨迹分析是以车为研究对象，人员轨迹分析是以人（主要是驾驶员和车主）为研究对象。
比如同样的查询条件：
一个月内碰撞次数为3次以上，那么以车为研究对象的话，查询的是在一个月内碰撞次数超过3次以上的车辆；
以人为研究对象的话，查询的是在一个月内驾驶一辆车或者多车，且碰撞次数超过3次的驾驶员。
2.4.1车辆轨迹分析
根据车辆的案件记录进行分析，比如该车即是标的车又是第三方车辆且在较短的不合理期内接连发生事故的。
分析结果支持导出Excel、保存结果到数据库以及支持打印功能。
一般分析：
一般分析条件：
案件号、车牌号、车架号、车型、事故时间（时间段查询）、事故地点、事故角色。
事故地点采用模糊查询。
更多分析条件：
关键字（关联的是事故经过，采用模糊查询，比如可以填写碰撞部位、单方全责等等），月份跨度（小于等于，指的是多少个月内），间隔天数（小于等于），碰撞次数（大于等于，并且可选是否是连续碰撞），理赔金额（大于等于），驾驶员是否相同（选择框）。
车架号、事故时间（降序）
案件号、车牌号、车架号、车型、驾驶员、车主、事故角色、事故时间、事故地点、事故经过、修理厂、赔款金额、查勘人员、保险公司。
如果分析出来的车辆信息或人员信息有被列入系统黑名单当中，那么要对该车牌号和人员姓名列表框进行染色。
对于一些查询条件要做适当的判断，如果数据量大，应该给用户一个操作提醒。
比如只选择事故时间段进行分析，事故时间段如果跨度大的话，那么分析出来的数据将会很大，所以要给用户操作提醒，防止误操作。
高级分析：
在一般分析的结果上，可以对已经分析出来的数据再次进行分析，这样可以提高分析的效率。
分析条件：
关键字（关联的是事故经过，采用模糊查询，比如可以填写碰撞部位、单方全责等等），月份跨度（小于等于，指的是多少个月内）,间隔天数（小于等于），碰撞次数（大于等于，并且可选是否是连续碰撞），理赔金额（大于等于）,驾驶员是否相同（选择框）。
点击高级分析或更多分析条件时，页面显示效果如下：
以下模拟几种场景做一个说明：
查询条件
碰撞部位是底盘，理赔金额超过3000
关键字：
底盘
理赔金额：
3000
6个月内，3次以上被撞，金额超过2000
事故角色：
三者车
月份跨度：
6
一年内事故地点是在仙岳路，碰撞次数超过3次的车辆
事故地点：
仙岳路
12
碰撞次数：
3
间隔10天内出现2次以上事故的车辆
间隔天数：
2
情景5
连续3次出险且驾驶员都不一样
3并且选中“连续”选择框
驾驶员是否相同：
选择“否”
2.4.2人员轨迹分析
根据驾驶员记录进行分析，比如该人员驾驶多辆车在较短周期内频繁发生事故的。
一般分析：
驾驶员、车主、查勘人员、关键字。
更多查询条件：
事故时间（时间段查询），驾驶车辆数（大于等于），月份跨度（小于等于，指的是多少个月内），间隔天数（小于等于）,碰撞次数（大于等于，并且可选是否是连续碰撞），理赔金额（大于等于）。
驾驶员、驾驶证号、联系方式、车主、车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、修理厂、赔款金额、查勘人员、保险公司。
在一般分析的结果上，可以对已经分析出来的数据再次进行条件过滤和筛选，这样可以提高分析的效率。
驾驶证号、事故时间（降序）
情景说明：
一年内，一个驾驶员驾驶多辆车出事故
驾驶车辆数：
1个月内，出事故超过2次的驾驶员
2.5黑名单管理
该模块的主要功能：
1、黑名单的导入2、黑名单的管理即黑名单的新增、修改、删除以及查询。
黑名单按类型又分为两种：
车辆黑名单和人员黑名单。
2.5.1车辆黑名单
车辆黑名单的字段：
车牌号、车架号
1、车辆黑名单的导入：
支持以Excel的方式导入
2、黑名单管理：
添加车辆黑名单，修改或删除车辆黑名单以及查询车辆黑名单等几个功能。
查询条件：
车牌号、车架号。
2.5.2人员黑名单
人员黑名单的字段：
姓名、身份证号码
1、人员黑名单的导入：
添加人员黑名单，修改或删除人员黑名单以及查询人员黑名单等几个功能。
姓名、证件号。
2.6基础信息管理
2.6.1保险公司维护
保险公司机构信息的录入、修改、查询、删除等功能。
字段信息：
ID、保险公司编号、简称、全称、备注说明
2.6.2车型维护
车型信息录入、修改、查询、删除等功能。
ID、编号、名称、说明。
2.6.3号牌种类维护
号牌种类信息录入、修改、查询、删除等功能。
ID、编号、名称、说明
2.6.4特殊车牌维护
特殊车牌信息录入、修改、查询、删除等功能。
特殊车牌将不会被列入黑名单中。
ID、车牌号、车架号、备注说明
2.7权限管理
2.7.1角色管理
系统角色信息录入、修改、查询、删除等功能。
2.7.2用户管理
提供系统用户信息录入、修改、查询、删除以及用户的角色分配等功能。
2.7.3角色权限设置
对角色进行权限分配设置。
第3章系统总体架构设计
3.1系统设计原则
3.1.1系统的安全性
整个平台涉及大量业务数据，这些数据非常重要，因此保障系统的软硬件安全也是系统的重要原则。
包括以下几个方面的安全要求：
网络的安全性
系统部署于外网和防火墙内，系统对一些数据采用加密解密方法，同时配置拦截器功能，防止恶意攻击。
应用系统与数据库分开部署，隐藏内部数据，增加数据的安全性
应用系统的安全性
严格的权限认证，单点登录，严格的代码编写规范和部署要求，确保应用系统不易受外部入侵。
数据的安全性
数据库与应用服务器分离，数据库部署时在软硬件上制定完善的管理和备份方案，确保数据不泄露且因不可抗力损毁时可以快速恢复。
3.1.2系统的稳定性
通过程序缓存、数据库分区、错时运行等策略合理控制系统负载，达到运行速度、性能稳定的平衡。
3.1.3系统的易用性
本系统的易用性主要体现在以下几点：
信息展示的全面、直观
各个信息实体的内容相互链接，以便信息追踪。
3.1.4系统的扩展性
1、性能的可扩展性
系统在性能设计上，充分考虑了系统的在性能上的可扩展性，主要体现在以下几个方面：
硬设备：
硬设备如服务器的CPU、内存、磁盘空间等均为可扩展的设计，在仅需要小规模的性能扩容时，通过增加CPU、内存、磁盘空间就可以实现性能扩容。
负载均衡：
系统在架构设计上，无论从数据层、业务逻辑中间件、MVC表现层均采用的是可多机进行Active-Active的性能分摊。
当前使用基本以双机的负载均衡的方式，在性能需要较大规模的升级扩容时，只需要在需要扩容的部分（如：
业务逻辑层）增加服务器，进行扩容部署就可以实现多台服务器的Active-Active的扩容。
2、功能模块的可扩展性
由三个方面决定的本系统的高度可扩展性，使系统在增加新的业务功能模块时就像新增加一个插件一样，只需要功能开发完成、部署到测试环境中进行测试，测试通过后按系统更新的管理流程进行系统的升级，并可进入商业试用。
2.1系统采用多层的系统架构，系统由以下3层组成
数据层：
数据操作层、接口适配层组成
业务逻辑层：
以中间件的方式处理分布式事务的业务逻辑
表现层：
采用先进的MVC模型进行业务展示与输入的人机界面
2.2松耦合模块关联架构
模块与模块之间采用的是逻辑相对独立的松耦合结构，以功能模块的插件方式进行组合。
2.3数据总线式信息交换框架
系统以EAI的思想结合系统的中间件特点，对系统中的信息流、数据流、业务流程进行组合，使系统在功能扩展时不会形成信息的孤岛，能够与现有系统充分的进行信息交互，流程触发。
3.2系统架构
根据系统的开发目标和原则，以系统的设计思想和软件策略为准则，结合不同业务部门应用的特点，考虑到实际方面的需求特性以及部署、维护、升级和扩展的方便，整体方案采用B/S（浏览器/服务器）模式及三级分布式体系结构来满足客户目前和以后的业务需求。
基于Web技术的Internet/Intranet近年来已经得到了广泛的应用，Intranet是以TCP/IP协议为基础、以Web为核心的企业内部网，本系统采用浏览器/服务器（Browser/Server）的方式，使用者通过低成本、简单易用的客户浏览器就能随时随地（电信网内）通过请求管理系统Web服务器从而得到响应，查阅并管理自己所需的数据，或进行业务流程的处理工作。
系统具体体系结构如下图所示：
整个系统在逻辑上分为三层，第一层为表示层，提供用户和系统之间的交互；
第二层为逻辑层，利用应用服务器实现具体的业务逻辑；
第三层为数据层，利用数据库服务器实现数据的存储、访问及其优化。
表示层
表示层通常向用户提供应用的接口，它是一个图形用户界面。
主要负责处理用户的输入和向用户的输出。
表示层不需要完成任何重要的业务逻辑，也不以任何方式直接和数据库交互，同时也不保存任何本地的状态信息，它只提供与用户交互的功能，提供一个良好的人机界面。
客户无须安装任何客户端，通过浏览器访问该系统，这样就保证了系统中的客户机是一个真正的"
瘦"
客户机。
逻辑层
逻辑层是多层结构中最重要的一层，负责提供系统的核心功能，提供所有的业务逻辑处理功能，封装各类应用逻辑，形成组件。
逻辑层只是完成所有业务逻辑处理功能，不进行数据库的具体操作，数据库的具体操作将通过逻辑层与数据层打交道来完成。
逻辑层包括完成业务逻辑处理所需要的各种服务，这些服务以API的方式提供，客户层通过调用这些API来完成对数据库的操作。
例如，认证服务（AuthenticationService）通过访问认证数据库来验证用户口令数据是否正确。
这一层将所有逻辑封装起来，如果逻辑规则发生变化时，只须修改该层相应组件的内容，其他三层无须进行改动。
表示层通过指定接口形式进行调用。
数据层
整个系统中所有对数据库的操作都在这一层中完成，负责实际的数据存储和检索。
数据层是逻辑层与数据库打交道的中间桥梁，通过数据层将与数据库的所有操作封装在一起，更方便进行修改及调用。
采用以上结构，可以避免随着逻辑的变换而引起的档的大量改动，将数据操作与逻辑关系分开，提高系统的可靠性。
同时系统发挥面向对象程序设计中封装性的优点，提高了程序的可重用性，可维护性，而且系统管理简单，可支持多种数据库，有很高的扩展性。
3.3技术框架图
升级会员 