车险理赔反欺诈系统方案

车险理赔反欺诈系统需求分析方案
2010年08月24日
目录
车险理赔反欺诈系统需求分析方案 (1)
第 1 章项目概述 (4)
§1.1建设背景 (4)
§1.2建设目标 (4)
第 2 章需求分析 (5)
§2.1数据管理 (5)
§ 2.1.1 数据导入 (5)
§ 2.1.2 数据填充维护 (7)
§2.2综合查询 (9)
§ 2.2.1 信息检索 (9)
§2.3比对分析 (10)
§ 2.3.1 特征库管理 (10)
§ 2.3.2 比对规则配置 (12)
§ 2.3.3 风控名单查询(比对查询) (13)
§2.4案件轨迹分析 (14)
§ 2.4.1 车辆轨迹分析 (14)
§ 2.4.2 人员轨迹分析 (17)
§2.5黑名单管理 (19)
§ 2.5.1 车辆黑名单 (19)
§ 2.5.2 人员黑名单 (19)
§2.6基础信息管理 (20)
§ 2.6.1 保险公司维护 (20)
§ 2.6.2 车型维护 (20)
§ 2.6.3 号牌种类维护 (20)
§ 2.6.4 特殊车牌维护 (20)
§2.7权限管理 (20)
§ 2.7.1 角色管理 (20)
§ 2.7.2 用户管理 (20)
§ 2.7.3 角色权限设置 (21)
第 3 章系统总体架构设计 (22)
§3.1系统设计原则 (22)
§ 3.1.1系统的安全性 (22)
§ 3.1.2系统的稳定性 (22)
§ 3.1.3系统的易用性 (22)
§ 3.1.4系统的扩展性 (22)
§3.2系统架构 (24)
§3.3技术框架图 (25)
§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方式导入数据。

现有保险公司的数据以案件为主进行存储，一条案件记录中有可能包含多车信息，而本系统主要以车辆或是驾驶员为主要分析研究对象，因此需要对案件记录进行拆分，拆分成以车辆的案件信息进行存储，即一条案件记录可能要拆分成多条车辆的案件记录。

一条案件记录拆分后，系统以赔案号做为拆分后的多车辆记录来关联。

数据导入验证：数据导入时对赔案金额做数据格式验证，验证是否为数值型。

由于数据量较大，为了导入效率，其他字段不做校验。

拆分后的字段信息，如下表：
§ 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:00这个字段自动关联的是事故时间。

特征库列表显示效果如下图：
特征库添加页面效果显示如下图：
特征库配置举例：
情景情景描述配置说明
情景1 赔偿金额超过5000 特征名称：赔偿金额超过五千
特征定义：赔偿金额大于等于5000的案件
情景2 碰撞部位是底盘特征名称：碰撞部位-底盘
特征定义：碰撞部位是底盘的
情景3 6个月内出险3次以上特征名称：6个月内出险3次以上
特征定义：6个月内，同一车辆碰撞次数超过3次
以上
情景4 驾驶多车出事故特征名称：驾驶多车出事故
特征定义：一年内，同一个驾驶员驾驶3辆以上不
同的车出事故
§ 2.3.2 比对规则配置
特征库配置完之后，我们就可以根据特征库列表进行一个比对规则的配置。

选择一条或多条特征，组合成一个比对规则，比对规则可以选择以车或者人为分析对象，也可以两者全选。

可以创建多条比对规则，比对规则同样支持增删改操作。

规则配置界面效果如下图：
选中特征库列表中的一条或多条特征，点击保存，就可以创建一条比对规则。

比对规则创建完成后，系统将跟据比对规则，自动检索符合条件的数据，并把结果保存到比对结果表中。

不同的比对规则可能检索到同一车辆记录或者同一个人员记录，对于相同的车辆记录（以车架号为判断准则）或者人员记录（以驾驶证号或身份证号位判断准则），系统将采用叠加的方式，把该车或人记录到风控名单表中，并记录该车或人员被比对的次数，这样可以突出高风险的车辆或人员。

➢比对结果表字段：ID、车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、驾驶员、驾驶证号、车主、车主身份证号、修理厂、赔偿金额、查勘人员、保险公司，比对规则ID，比对规则名称，比对日期。

➢风控名单表字段：类型（1、车辆名单2、人员名单）、车牌号、车架号、车型、人员姓名、证件号、联系方式、比对次数。

§ 2.3.3 风控名单查询(比对查询)
风控名单分为：车辆名单和人员名单。

查询结果支持导出Excel及打印功能。

点击“明细”，可以看到该车或人员比对的详细记录。

➢车辆名单显示字段：比对次数、车牌号、车架号、车型。

➢车明细显示字段：车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、车主、驾驶员、修理厂、查勘员、保险公司、比对规则、比对时间。

➢人员名单显示字段：比对此时、人员姓名、证件号、联系方式。

➢人员明细显示字段：驾驶员、驾驶证号、联系方式、车牌号、车架号、车型、车主、事故角色、事故时间、事故地点、事故经过、修理厂、查勘员、保险公
司、比对规则、比对时间。

页面显示效果如下：
明细页面显示效果：
§ 2.4 案件轨迹分析
案件轨迹分析其实就是对数据进行分析挖掘，通过不同的查询条件来组合，对数据进行层层筛选，根据一定的比对条件和规则，最终检索出具有分析价值的车辆或人员信息，再与某个案件进行关联，实现案件的轨迹分析。

案件轨迹分析分为：车辆轨迹分析和人员轨迹分析；车辆轨迹分析是以车为研究对象，人员轨迹分析是以人（主要是驾驶员和车主）为研究对象。

比如同样的查询条件：一个月内碰撞次数为3次以上，那么以车为研究对象的话，查询的是在一个月内碰撞次数超过3次以上的车辆；以人为研究对象的话，查询的是在一个月内驾驶一辆车或者多车，且碰撞次数超过3次的驾驶员。

§ 2.4.1 车辆轨迹分析
根据车辆的案件记录进行分析，比如该车即是标的车又是第三方车辆且在较短的不合理期内接连发生事故的。

分析结果支持导出Excel、保存结果到数据库以及支持打印功能。

一般分析：
➢一般分析条件：案件号、车牌号、车架号、车型、事故时间（时间段查询）、事故地点、事故角色。

事故地点采用模糊查询。

➢更多分析条件：关键字（关联的是事故经过，采用模糊查询，比如可以填写碰撞部位、
单方全责等等），月份跨度（小于等于，指的是多少个月内），间隔天数（小于等于），碰撞次数（大于等于，并且可选是否是连续碰撞），理赔金额（大于等于），驾驶员是否相同（选择框）。

➢排序：车架号、事故时间（降序）
➢显示字段：案件号、车牌号、车架号、车型、驾驶员、车主、事故角色、事故时间、事故地点、事故经过、修理厂、赔款金额、查勘人员、保险公司。

➢染色：如果分析出来的车辆信息或人员信息有被列入系统黑名单当中，那么要对该车牌号和人员姓名列表框进行染色。

注：对于一些查询条件要做适当的判断，如果数据量大，应该给用户一个操作提醒。

比如只选择事故时间段进行分析，事故时间段如果跨度大的话，那么分析出来的数据将会很大，所以要给用户操作提醒，防止误操作。

页面显示效果如下：
高级分析：
在一般分析的结果上，可以对已经分析出来的数据再次进行分析，这样可以提高分析
的效率。

➢分析条件：关键字（关联的是事故经过，采用模糊查询，比如可以填写碰撞部位、单方全责等等），月份跨度（小于等于，指的是多少个月内）,间隔天数（小于等于），碰撞次数（大于等于，并且可选是否是连续碰撞），理赔金额（大于等于）, 驾
驶员是否相同（选择框）。

➢排序：车架号、事故时间（降序）
➢显示字段：案件号、车牌号、车架号、车型、驾驶员、车主、事故角色、事故时间、事故地点、事故经过、修理厂、赔款金额、查勘人员、保险公司。

➢染色：如果分析出来的车辆信息或人员信息有被列入系统黑名单当中，那么要对该车牌号和人员姓名列表框进行染色。

点击高级分析或更多分析条件时，页面显示效果如下：
以下模拟几种场景做一个说明：
情景情景描述查询条件备注
情景1 碰撞部位是底盘，理关键字：底盘
§ 2.4.2 人员轨迹分析
根据驾驶员记录进行分析，比如该人员驾驶多辆车在较短周期内频繁发生事故的。

分析结果支持导出Excel、保存结果到数据库以及支持打印功能。

一般分析：
➢查询条件：驾驶员、车主、查勘人员、关键字。

➢更多查询条件：事故时间（时间段查询），驾驶车辆数（大于等于），月份跨度（小于等于，指的是多少个月内），间隔天数（小于等于）, 碰撞次数（大于等于，并
且可选是否是连续碰撞），理赔金额（大于等于）。

➢排序：车架号、事故时间(降序)
➢显示字段：驾驶员、驾驶证号、联系方式、车主、车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、修理厂、赔款金额、查勘人员、保
险公司。

➢染色：如果分析出来的车辆信息或人员信息有被列入系统黑名单当中，那么要对该车牌号和人员姓名列表框进行染色。

高级分析：
在一般分析的结果上，可以对已经分析出来的数据再次进行条件过滤和筛选，这样可以提高分析的效率。

➢查询条件：事故时间（时间段查询），驾驶车辆数（大于等于），月份跨度（小于等于，指的是多少个月内），间隔天数（小于等于）, 碰撞次数（大于等于，并且
可选是否是连续碰撞），理赔金额（大于等于）。

➢排序：驾驶证号、事故时间(降序)
➢显示字段：驾驶员、驾驶证号、联系方式、车主、车牌号、车架号、车型、事故角色、事故时间、事故地点、事故经过、修理厂、赔款金额、查勘人员、保
险公司。

➢染色：如果分析出来的车辆信息或人员信息有被列入系统黑名单当中，那么要对该车牌号和人员姓名列表框进行染色。

情景说明：
§ 2.5 黑名单管理
该模块的主要功能：1、黑名单的导入2、黑名单的管理即黑名单的新增、修改、删除以及查询。

黑名单按类型又分为两种：车辆黑名单和人员黑名单。

§ 2.5.1 车辆黑名单
车辆黑名单的字段：车牌号、车架号
1、车辆黑名单的导入：支持以Excel的方式导入
2、黑名单管理：添加车辆黑名单，修改或删除车辆黑名单以及查询车辆黑名单
等几个功能。

查询条件：车牌号、车架号。

查询结果支持导出Excel及打印
功能。

§ 2.5.2 人员黑名单
人员黑名单的字段：姓名、身份证号码
1、人员黑名单的导入：支持以Excel的方式导入
2、黑名单管理：添加人员黑名单，修改或删除人员黑名单以及查询人员黑名单
等几个功能。

查询条件：姓名、证件号。

查询结果支持导出Excel及打印功
能。

§ 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来完成对数据库的操作。

例如，认证服务（Authentication Service）通过访问认证数据库来验证用户口令数据是否正确。

这一层将所有逻辑封装起来，如果逻辑规则发生变化时，只须修改该层相应组件的内容，其他三层无须进行改动。

表示层通过指定接口形式进行调用。

数据层
整个系统中所有对数据库的操作都在这一层中完成，负责实际的数据存储和检索。

数据层是逻辑层与数据库打交道的中间桥梁，通过数据层将与数据库的所有操作封装在一起，更方便进行修改及调用。

采用以上结构，可以避免随着逻辑的变换而引起的档的大量改动，将数据操作与逻辑关系分开，提高系统的可靠性。

同时系统发挥面向对象程序设计中封装性的优点，提高了程序的可重用性，可维护性，而且系统管理简单，可支持多种数据库，有很高的扩展性。

§ 3.3 技术框架图
Struts+Spring+Hibernate体系结构
图：Struts+Spring+Hibernate体系结构
说明:
1、Web服务层采用struts2，struts2居于MVC的模式，很好的把视图展示，控制处理逻辑，数
据模型分开，视图我们采用JSP技术，控制采用struts自带的请求分发器，数据模型使用action，actionform表示，action中调用spring byName注入进来的业务逻辑处理类，进行相关的业务逻辑处理。

2、业务逻辑层使用spring控制数据库事务的bean，调用spring配置文件中注入的hibernate dao
操作类，进行相关业务处理与数据库操作，统一的出错事务回滚机制，很好的保证数据的完整性，一致性。

3、实体层使用hibernate的ORM映射，把数据库表抽象成一个个java类，表中记录映
射成对应的类实例对象，在这基础之上，抽象封装实体类操作dao（线程安全），统一对数据库进行操作，提供给业务逻辑层调用，把对实体类对象的操作映射成对数据库的操作。

§ 3.4 运行环境
应用服务器Weblogic
WebLogic是美国bea公司出品的一个application server确切的说是一个基于Javaee架构的中间件，BEA WebLogic是用于开发、集成、部署和管理大型分布式Web 应用、网络应用和数据库应用的Java应用服务器。

将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。

BEA WebLogic Server具有开发和部署关键任务电子商务Web应用系统所需的多种特色和优势，包括：
1）领先的标准
对业内多种标准的全面支持，包括EJB、JSB、JMS、JDBC、XML和WML，使Web 应用系统的实施更为简单，并且保护了投资，同时也使基于标准的解决方案的开发更加简便。

2）无限的可扩展性
BEA WebLogic Server以其高扩展的架构体系闻名于业内，包括客户机连接的共享、资源pooling以及动态网页和EJB组件群集。

3）快速开发
凭借对EJB和JSP的支持，以及BEA WebLogic Server 的Servlet组件架构体系，可加速投放市场速度。

这些开放性标准与WebGain Studio配合时，可简化开发，并可发挥已有的技能，迅速部署应用系统。

4）部署更趋灵活
BEA WebLogic Server的特点是与领先数据库、操作系统和Web服务器紧密集成。

5）关键任务可靠性。