远程审计体系建设战略

远程审计体系 建设 2 1.体系框架 建设 2.数据平台 调研 3.流程风险 梳理 4.审计规则 设计 5.指标体系 建设 6.项目增值 服务 项目进度概览 1.1 现状调研 已完成部分 正在进行部分 完成总体进度的 30%，基本与计划相 符。 1.2 差异分析 1.3 框架设计 1.4 流程详 细设计 2.1 业务信 息梳理 2.2 重要性 评级 2.3 数据质 量验证 3 业务流程风险点梳理 4.1 远程审计规则设计 4.2 远程审计规则验证与优化 5 预警指标设计与验证 6.1 利率市场 化分析 6.2 客户分群 及渠道分析 6.3 偿二代探 索 尚未开始部分 造房子 打基础 2014年 1月 2014年 9月我们在这里 3 内容 . 下一阶段工作重点 远程审计体系 建设 3 1 远程审计规则 设计2 领导要求4 4 1. 远程审计体系建设 5 鉴它业，观自身， 远程审 计的领先实践 非现场与现场稽核部室分离 ; 审计情报收集与生成机制； 支持对分支机构评级； 建立平台整合远程审计分析与现场作业； 多维度精细化组织架构与岗位 角色； 建立非现场与现场稽查整合 平台； 专家系统 机制， 与 SAS平台整合； 实现异构非格式化数据源的 整合（如影像、音频）； 构建大数据平台，多种模式匹配与关联分析的数据模型； 实时预警与事后监控结合； 强调持续审计模型对风险的查实率的提升； 建立数据规范，构建两级数据 平台； 在线监控与在线审计两个模块，相互映射并协同工作； 数据集中并建立数据标准； 2 3 4 5 6 7 总部、分中心 层面形成 “ 非现场审计两级架构 ” ； 非现场审计职能包括：现场审计支持、远程指标监 测、常规远程审计、现场 突击 审计 1 6 鉴它业，观自身， 远程审 计的领先实践 非现场与现场稽核部室分离 ; 审计情报收集与生成机制 ； 支持对分支机构评级 ； 建立平台整合远程审计分析与现场作业 ； 多维度精细化组织架构与岗位 角色； 建立非现场与现场稽查整合 平台 ； 专家系统 机制， 与 SAS平台整合 ； 实现异构非格式化数据源的 整合（如影像、音频） ； 构建大数据平台，多种模式匹配与关联分析的数据模型 ； 实时预警与事后监控结合 ； 强调持续审计模型对风险的查实率的提升 ； 建立数据规范，构建两级数据 平台 ； 在线监控 与在线审计两个模块，相互映射并协同工作 ； 数据集中并建立数据标准 ； 2 3 4 5 6 7 总部、分中心 层面形成 “ 非现场审计两级架构 ” ； 非现场审计职能包括： 现场审计支持 、 远程指标监 测 、 常规远程审计 、 现场 突击 审计 1 2.现场与非现场 协同工作 特点汇总 3.指标预警与监 控 4.系统平台支持 远程审计 5.支持对特定目 的的审计 6.审计与咨询并 重 1.独立的远程审 计职能部门 7 定位 设计 定位设计原则 它业案例研究与借鉴 远程审计定位 设计的整体思路 适应内外部环境的变化 实现相关者要求与期望 风险预警 远程常规 现场支持 舞弊专项 1. 多 家监管机构建立了远程监管平台 ； 2. 中保 信启动行业数据整合 ； 3. 大 数据的发展使远程进行审计成为可能 ； 4. 舞弊 、欺诈行为日趋隐蔽，危害也在 增大 ； 外部环境分析 1. 中心确立 “ 监督与服务并重 ” 战略转型目标 ； 2. 内 审精专化发展趋势； 3. 业务 迅速发展的同时内审团队规模相对稳定 ； 4. 中心 对审计效能的要求； 5. 中心 对审计广度、深度与精度的要求； 6. 新 业务带来新的舞弊风险； 7. 业务 信息化程度提升，操作可追溯 内部环境分析 8 基于规则库，建立远程审计风险预警体系，实施远程审计预警监测， 评估与识别集团公司本部及各子公司的风险状况， 并提供审计增值服 务 对具备数据基础的集团公司 本部及各子公司 各项 经营管理活动和财务 活动的 真实性与合 规 性实施常规远程审计 监督 ，确认审计发现，生成 远程审计报告 为审计业务部、各区域审计部实施的现场 审计提供技术支持，配合现 场审计定位审计发现、量化影响范围与程度、提高现场审计精度 对 集团公司本部及各 子公司的关键岗位实施舞弊远程专项审计，确认 审计 发现 ， 生成舞弊审计报告 风险预警 远程常规 现场 支持 舞弊专项 远程审计定位设计 注 1 注 1: 远程审计的风险预警将重点实现审计中心作为 “ 第三道防线 ” 的预警功能，而非对业务的实时干预。 9 体系框架模型 目标层 保障层 基础层系统 /数据 绩效管理 流程 职能 组织 定位 做什么 是否做到 谁来做 怎样做 实现基础 1 2 3 4 5 远程审计体系架构 10 后台前台 审计中心 审计业务部 7大区 审计部 专建办 审计技术部 审计管理部 中台 布局： 根据远程审计部的定位，以及工作更加贴近一线业务的特点，建议将远程审 计部定位在审计中心的 前台 。 远程审计部 远程审计体系 组织 为什么建议将远程审计部设置于前台？ 1. 专业契合方面 实施远程常规审计、舞 弊专项审计的人员需要丰富的业务与审 计知识，与目前审计中心前台人员匹配 度最高 2. 工作流程方面 远程审计团队需要与审 计中心前台现场人员以及一线业务人员 有非常紧密的联动，以提高沟通效率与 效果；同时工作绩效评价标准也更接近 于前台 3. 数据获取方面 通过数据发现问题的审 计方式要求远程审计团队对业务数据流 非常熟悉，因此设置于前台可以使对业 务数据，尤其是新业务的信息了解更准 确与有效 11 注 1 规则设计组 应用功能区 模型 功能区 综合功能区 数据管理组 大区 集团 风险预警组 现场支持组舞弊专项组远程常规组 模型研发组 系统管理组 远程审计部 应用功能区 远程常规组 舞弊专项组 现场支持组风险预警组 现场数据支持、验证、确认 远程支持、优化、设计、管理、维护 将 需要现场的 “ 数据支持、验证 、确认 ” 工作 ， 划分至七 个大区 。更 适合审计业务的迅速、及时、针对性的 执行。 对技术、分析、规划 要求较高 的职能和 岗位，均 放在 集团 总部统一管理 。可以 大幅减少重复性职能和岗位的设置 。 注 1：应用功能区包含现场工作和分析管理工作，因此将数据支持、验证、确认工作划分至 7个大区，剩余工作则在集团统一开 展。 远程审计体系 组织 (续 ) 分布 ： 采用 总分结合 的方式划分远程审计部的工作 12 远程审计体系 （ 1）组织：位置 互 动 关系 审计业务部审计技术部 大区审计业务部 远程审计部 现场支持 远程审计结果查实 远程工作指导 现场支持 计划报送 报告递交 审计业务部审计技术部 大区审计业务部 远 程 审 计 部 分析 内容申请 执行情况反馈 新风险点及经验 规则提供 现场数据支持、验证、反馈 新风险点及经验规则提供 计划发放 审计方案审核 报告复核 技术支持 专建办 审计管理部 人员专业化管理 远程审计总 体规划 与审计中心 外部沟通 交互 ： 远程审计部与审计中心其他部门需要互动， 互相提供输入、输出 ，只有与 其他部门协同工作，才能更有效率的完成远程审计工作。 远程审计部门提供输出 其他部门提供输入 远程审计体系 组织 (续 ) 13 结构： 远程审计部包含 3个 功能区、 8大 功能组。 远程 审计部 应用功能区 模型功能区 综合功能区 风险预警组 现场支持组 远程常规组 舞弊专项组 模型研发组 系统管理组 数据管理组规则设计组 审计总监 7人8人 2人 应用 功能 区： 与 业务部门关系更为密切 ， 应 符合 审计业务的快速 响应的 特 点 。 建模功能 区： 为 应用功能区的 “ 软件支撑 ” ，通过建模技术的不断提高、 模型规则的不断完善、分析方 法的不断优化 ，使得应用功能 区的发现更为精准。 综合功能 区： 为 整个远程审计提供基础 服 务。 17 人 远程审计体系 组织 (续 ) 注 1 注 1：不包含大区部的远程审计相关岗位人员 14 应 用 功 能 区 风险预警组： 监控 风险预警指标 ，处理并应对指标 报警 设计并优化风险预 警指标及其预警 值 根据风险预警运行 结果，定期统计分 析预警规则的准确 性和有效性 为 整体审计风险评 估、年度审计计划 提供数据分析 结果 根据 其他需求提供 数据与增值分析 远程常规组： 根据审计计划，执 行常规的远程审计 数据分析，及时发 现审计 线索 通过 现场验证或远 程影像验证，查实 常规审计发现，编 制审计 报告 设计 并优化远程常 规审计相关的远程 审计分析 规则 根据模型运行 结果 ，定期 统计分析规 则 的准确性和 有效 性 定期 牵头组织对远 程审计风险库与规 则库的更新与优化 现场支持组： 提供现场审计审前 支持 分析风险分 布，计量风险程度 ，并推送审计 线索 提供 现场审计审中 支持 接受现场审 计需求，缩小抽样 范围，并进一步推 送审计 线索 提供 现场审计审后 支持 量化分析审 计发现的影响 程度 设计 并优化现场审 计支持相关的远程 审计分析规则 舞弊 专项 组 ： 收集舞弊情报，执 行舞弊专项远程审 计数据分析，及时 发现舞弊 线索 通过 现场验证或远 程影像验证，查实 舞弊审计发现，编 制审计 报告 设计 并优化舞弊专 项审计相关的远程 审计分析规则 1. 远程审计体系 职能 15 模 型 功 能 区 模型研发组： 提供 模型的 全生命 周期 管理 优化及维护模型， 参数、阀值等 确认的新增模型的 开发需求，评估可 行性和实现难度 实施新增需求的开 发、测试、验证、 上线工作 定期收集模型运行 结果，评估模型是 否有效、是否需要 调整或下线 系统 管理组： 维护远程审计平台 的硬件、软件功能 的正常使用 维护远程审计系统 与其他平台及系统 的接口的可用性及 安全性 监控系统日常使用 情况，对关键运行 指标进行预警 对批处理作业和脚 本（应用 功能区和 建模功能 区）进行 监控 对系统使用人员账 号申请、权限分配 等进行管理 数据管理组： 提供数据的全生命 周期管理（数据分 析除外） 管理远程审计数据 的来源、采集、清 洗、存储、备份、 销毁等流程 制定并 优化审计数 据质量体系，提供 数据结构化 标准、 规范和模板 制定并维护数据字 典 构建 并 优化 数据 安 全体系，保证数据 对适当的人员权限 规则设计组： 定期 收集应用功能 区的新增需求，总 结业务特征，识别 风险事件和异常场 景，设计规则 根据现场支持和远 程审计的反馈，对 规则进行完善和调 整 不断完善规则库， 拓展对业务领域的 覆盖 综 合 管 理 区2. 3. 远程审计体系 职能 (续 ) 16 功能区 分组 岗位能力要求 初期阶段 人员规模 成熟阶段 人员规模 初期阶段 人数小计 应 用 功 能 区 风险预警组 产寿险业务人员： 熟悉保险业务流程与内部外部风险因素； 能有效识别审计关注点、风险场景以及风险 特征； 设计业务规则，并能熟练设计指标预警应对 措施。 1 + 1（ 0） 2 8 - 15 现场支持组 3 + 1（ 0） 4 远程常规组 2 + 1（ 0） 4 舞弊专项组 2 + 1（ 0） 3 建 模 功 能 区 建模组 数据分析人员 + 产寿险业务人员： 熟悉数据结构、系统数据分布； 熟练运用统计、建模与数据分析能力； 建立远程审计规则、预警指标以及分析模 型 。 3 5 7 规则组 4 5 综 合 管 理 区 系统管理 IT人员： 远程审计相关系统平台的运维管理 。 1 1 2 数据管理 IT人员： 数据生命周期管理以及数据安全与质量管 理 。 1 1 合计 17 - 24 根据功能区和分组的岗位能力要求，以及初期阶段模型规则和风险点的个数，设 定各岗位需求人员。 注 1：人员规模中 1+1（ 0）表示集团 1名成员，大区 1名成员；括号中 0表示由大区现任审计人员兼职 注 1 远程审计体系 职能 (续 ) 17 远 程 审计 体系 （3）流程远程审计体系 流程 预警 监控流程 流程谱系 远程常规流程 现场支持流程 舞弊专项流程 预警需求分析 预警指标调度 预警指标监控 警报分析及应对 规则设计与开发 审计数据管理 远程常规审计计划 远程常规方案设计 规则调度与分析 分析结果验证 现场支持需求分析 现场支持数据分析 分析结果确认 舞弊信息收集 舞弊审计方案设计 规则设计与分析 系统平台管理 分析结果验证 舞弊专项报告编制远程常规报告编制 规则评价与优化 主流程 子流程 支持流程 18 远程审计体系 绩效考核 人员评价标准 部门负责人 功能区负责人 各岗位人员 审计中心外部评价 1. 审计委员会关注程度2. 被审计单位满意程度 3. 审计发现追回的损失 4. 审计发现整改实施率 5. 增值建议获得的效果 不适用 不适用 审计中心内部评价 1. 中心其他部门满意程度2. 有效减少的审计成本 3. 审计工作被其他部门利 用程度 1. 远程审计其他功能区满 意程度 2. 有效减少的审计成本 1. 投诉率 目标完成情况 1. 部门计划工作完成率2. 重大审计发现数量 3. 预算管理情况 4. 审计报告出错率 5. 项目投入产出率 1. 功能区计划工作完成率 2. 重大审计发现数量 3. 工作质量总体评价 4. 预算管理情况 5. 功能区整体工作差错率 1. 个人计划工作完成率 2. 个人项目评价 3. 重大审计发现数量 4. 个人工作差错率 5. 项目完成周期 团队建设评价 1. 团队专业资质数量2. 团队培训数量 1. 团队专业资质数量 2. 团队培训数量 1. 个人专业资政 2. 个人培训时间 个人能力评价 1. 团队管理能力2. 沟通能力 1. 团队管理能力 2. 沟通能力 1. 工作核心技能评价 2. 沟通能力 19 远程审计体系 绩效考核 (续 ) 规则评价标准 规则 /指标 有效性 1. 案件查实率 2. 指标预警有效性 3. 风险覆盖率 4. 样本萃取率 效率性 1. 规则执行效率 2. 数据抽取效率 可靠性 1. 指标运行稳定性 2. 数据质量评价 3. 数据安全评价 经济性 1. 平均现场时间减少率 2. 开发投入成本产出率 增值性 1. 咨询成果量 2. 损失挽回量 20 审计数据集市 远程审计 模型及规则应用 结果展现 经过清洗的审计数据，来自于 EDW、手工输入以及外部数据 ； 具有良好的数据结构和质量； 作为用户远程审计分析的输入 数据分析 结果展示 报告生成 多维查询 自定义报表 远程审计系统应当涵盖数据 应用 展现 3大功能。每个功能内部又分为不同的 模块，各个模块及功能间协同工作，保障远程审计工作的顺利开展 。 远程审计体系 系统功能架构 规则设计 模型建设 参数 调整 数据分析 数据挖掘 报表运行 智能建模 自定义接口 数据封装 21 功能分类 功能模块 远程审计平台 与其他平台协同工作 平台外应用工具 模型预警及 数据分析区 风险预警 支持 数据分析软件 /工 具：例如 SAS数据分析 支持 自定义查询、展现 支持 报告生成 支持 模型建立及 规则优化区 自定义模型建立及验证 支持 数据分析软件 /工 具：例如 SAS已有模型及规则参数 调整、优化 支持 作业执行及 综合管理区 预警及分析结果推送 支持 与作业平台接口 现场验证、确认结果反馈 及后续跟进 支持 与作业平台接口 绩效考核及管理 支持 与管理平台接口 知识库 支持 与管理平台接口 审计人员权限、账号管理 支持 与管理平台接口 数据存储及管理 支持 与数据集市接口 需求管理及 系统维护 支持 远程审计系统应当涵盖前台的 “ 模型预警及数据分析功能 ” 、中台的 “ 模型建立 及优化功能 ” 以及后台的 “ 作业执行及综合管理功能 ” 。每个功能内部又分为不 同的模块，各个模块及功能间协同工作，保障远程审计工作的顺利开展 。 远程审计体系 系统功能架构（续） 22 1. 数据来源： 现有业务系统及数据集市（已有） 体外数据，对标使用 （缺失） 手工输入补充数据 （缺失） 2. 数据 范围 产、寿数据（已有） 集团、资管 （缺失） 3. 数据获取： 已 有数据 ETL定期抓取 缺失数据购买 缺失数据通过互联网 开放接口等抓取采集 1. 数据采集 2. 数据清洗 3. 数据 质量管理 4. 数据存储 5. 数据分析 6. 数据安全 数据汇总及整理 （缺失） 校验数据值的有效性，关键数 据是否缺失，数据是否重复 等。 对无法使用的数据计算其最终 结果的影响程度，判定数据是 否可用 （缺失） 1. 数据结构化 将非结构化的数据按照 一定标准结构化处理， 形成可以进行分析的基 础数据 （部分缺失） 2. 数据字典 对系统中已经清理完毕 的表、数据形成数据字 典，良好的保存表和数 据结构、定义等 及时更新及维护数据字 典 建立数据安全机制，制定不 同岗位对系统中数据的访问 及操作权限 建立敏感操作（如敏感信息 导出、全表更新等）监控机 制 数据管理是远程审计有效运行 的基础， 是全生命周期的闭环管理流程 。 远程审计体系 数据平台 23 机构汇总 产品汇总时间汇总客户汇总 行业汇总 审计数据集市 数据 汇总层 审计事件汇总 数据整合 风险 损失 汇总 数据轻度 汇总层 保单 信息 汇总 客户 信息 汇总 保单 关键 信息 批单 汇总 信息 赔付 汇总 信息 其他 信息 客户 号 客户 关键 信息 承保 汇总 信息 理赔 汇总 信息 还未进入 EDW的系统 影像系 统 源系统层 风险系 统 审计管 理平台 数据转换数据抽取 数据清理 数据整合 审计作 业平台 EDW系统 内部系统 手工录入 完整的审计数据集市，不仅是存储数据的工具，更加是对数据的整理、分类、汇 总、初步分析等，明确数据关系和结构，形成有效并有序的数据体系。 远程审计体系 数据平台 (续 ) 审计实验室 LAB 数据现状 预期 建设 24 远程审计体系发展阶段 远程审计体系的发展 1 起步探索阶段 单兵作战 方式： “ 偶发式 ” 发现问题 数据：依赖 财务 数据 手段：简单条件查询 定位：为 审计抽样 服务 4 智能优化阶段 - 立体化 作战 方式：三道防线一体化风险联动 数据：审计 数据集市与业务变化同步 工具：智能 风险识别与建模 定位：风险 与业务预测提升审计 价值 2 离散发展阶段 - 游击队作战 方式：以 “ 点 ” 覆盖审计风险 数据：拓展至业务数据 手段：手工编制规则 定位：仅设立专职岗位 3 全面整合阶段 - 集团军 作战 方式：以 “ 面 ” 覆盖审计风险 数据：整合审计数据 手段：利用成熟工具构建多维度复杂模型 定位：贯彻远程审计定位 审计中心目前所处阶段 25 远程 审计体系三年发展规划 Design 2014 2015 2016 里程碑 初步建立远程审计框 架体系； 组建远程审计团队 并正式运作； 17个审计领域风险 库并规则库上线运 行； 远程审计发挥风险预 测作用，突显增值职 能； 审计数据质量达到 良好状态； 远程常规与舞弊专项 深入化、常态化运作 ； 持续完善 构建体系、团队与系统 搭建体系 优化已有领域、拓展全领域 远程审计各职能全面运作 拓展全面 远程审计覆盖所有审 计领域，并主动适应 新业务 ； 建立远程审计数据 标准，提升远程审 计数据集市质量； 远程常规审计正式 运作并发挥作用； 26 远程审计 体系实施路径 实施路径 组织 /人员 流程 系统 /数据 启动内外部人才 选用机制，成立专业化 团队 确立远程审计部与其他部门的协同工作机制 明确远程审计部的前台职能和地位 明确 八 大职能 的运行流程，并推广应用 提升单项流程的沟通和效率 缩短流程间交互的沟通成本 建立 ETL自动化机制，形成数据的自动化采集、获取 建设及优化审计 数据 集市，分类及汇总核心业务数据 与现有审计系统形成有效接口和推送机制，形成审计作业 -远程审计 -审计管理的闭环管理 27 2. 远程审计规则 设计 28 风险资 料收集 4大来 源 审计业 务访谈 审计风 险点讨 论 生成远 程审计 风险库 识别业 务特征 设计审 计业务 规则 定位业 务数据 项 匹配审 计实验 室数据 项 设计远 程审计 分析规 则 验证规 则分析 结果 优化规 则 提交远 程审计 规则说 明 风险梳理与规则设计 风险梳理阶段 规则设计阶段 注 1 注 1: 目前只开放审计数据实验室环境中的数据用于远程审计规则设计， EDW数据正在同步中 ; 注 2: 目前只在审计中心通过业务系统查询来进行分析结果的验证，尚未通过与业务部门沟通进行确认； 注 2 信息点 与信息 源梳理 信息重 要性评 级 数据质 量分析 评估数 据获取 过程 平台调研阶段 29 风险梳理 成果 产险承 保 产险再 保 产险单 证 产险 日常费 用 资产管 理 场内交 易 寿险承 保 寿险理 赔 寿险 日常费 用 集团采 购 集团 会计核 算 73 适用于远程审计 102 探索引入远程审计 26 初步判断由于数据原因暂不适用于远程审计 总计： 201个风险点 30 风险梳理成果（续） 31 审计规则 设计 成果举例 规则一 风险描述 “ 已身故理赔的客户 ” 投保或续保，并再次出险骗取理赔金 风险领域 寿险承保 风险主体 销售人员、客户 风险编号 LIUN03 风险事件特征 保单被保险人身份信息（姓名、身份证号）与过往身故理赔人员身份信息一致，并存在理赔支 付记录 业务规则 1. 过往理赔支付的结案原因为被保险人死亡 2. 第二次投保日期（或续保日期）晚于第一次理赔的事故日期 3. 第二次承保的保单发生出险并理赔支付 4. 两次理赔被保险人与保单中被保险人的身份证号一致，且无被保险人修改的保全记录 5. 两次投保均为各险，且赔付金额均超过 5000元人民币 业务数据项 保单信息：保单号，团单号，投保日期，保单生效日期，险种，投保人身份证号，被保险人身 份证号，续保日期，投被保人关系； 理赔信息：事故日期，结案原因 32 审计规则 设计 成果举例 规则一（续） EDW数据项 L_AGT_INDIVIDUAL_AGMT: EGIONAL_OFFICE_CODE, EXTERNAL_REFERENCE, GPOLICYNO, NB_REQ_DATE, OPDATE, CLASSCODE, APID, PID, RENEWAL, RENEWAL_DATE, PRELNAME L_CLM_CLAIM_FOLDER: ACCIDENT_DATE, CLOSING_REASON 规则脚本 select distinct a.*, b.regional_office_code as regional_office_code_2, b.policyno as policyno_2, b.gpolicyno as gpolicyno_2, b.classcode as classcode_2, b.apid as apid_2, b.agt_pid as agt_pid_2, b.nb_req_date as nb_req_date_2, b.opdate as opdate_2, b.claimno as claimno_2, b.pid as pid_2, b.accident_date as accident_date_2, b.opening_date as opening_date_2, b.closing_reason as closing_reason_2, b.realamt as realamt_2, b.amt as amt_2, b.payment_date as payment_date_2, b.pay_pid as pay_pid_2 from temp_death_claim a, temp_death_claim b where a.pid=b.pid and a.policyno b.claimno and (a.closing_reason like %死亡 % or a.closing_reason like %身故 % or a.closing_reason like %去世 %) and a.accident_date b.nb_req_date 33 初步结果验证 初步发现疑似案例 17笔，涉及人民币金额 351,500元 案例一： 2004年，持证件号为 “ 的崔某在山西分公司购买 “ 太平盛 世 长泰安康保险 B款 ” ，并于 2008年车祸身故，同年获得两万元赔偿； 2010年持相同身份证 件的胡某在山西分公司购买 “ 金泰人生（ A款）终身寿险（分红型） ” ，并于同年由于 “ 胰腺 癌 ” 获得两万零三百元 的赔偿。已确认与业务生产环境数据一致。 案例二： 2006年，持证件号为 “ 的李某在青岛分公司购买 “ 太平如 意卡 ” ，并于 2007年 3月车祸身故，获得赔偿； 2007年 4月， “ 李某 ” 又在深圳分公司投保 “ 太平如意卡 ” ，并在 2008年车祸身故，获得 5万元赔偿。两次理赔描述均为简单的 “ 车祸死亡 ” ，并无其他详细时间、地点说明。已确认与业务生产环境数据一致。 审计规则 设计 成果举例 规则一（续） 34 对结果进行场景分析 我们分析了造成上述结果的可能场景： 1. 保险客户持假身份证件进行投保，并伪造出险证明骗保 2. 被保险人死亡后，其亲属使用其证件再次投保，并通过修改出险证明骗保 3. 被保险人死亡后，受益人对赔偿不满意，在与保险公司协商后，再次购买保险产品，并出 险获得协商的理赔金额，即以 “ 倒签单 ” 的形式进行 “ 通融赔付 ” 4. 业务人员在保单信息录入或理赔信息录入过程中存在错误输入，并未能及时发现纠正 5. 极小的可能性存在两个被保险人身份证一致 6. 数据质量问题或规则设计不严谨形成有偏差的结果 进一步分析验证方案 与分公司确认是否是通融赔付情形 场景 3 查看业务原始资料，确定业务办理时使用的身份证件及其他证明文件真伪 场景 1、 2、 5 查看业务原始资料，确定业务数据与审计数据的一致性 场景 4 优化数据质量或规则脚本 场景 6 对疑似是身份证或其他文件造假的案例，进行业务员集中度分析 审计规则 设计 成果举例 规则一（续） 35 审计规则 设计 成果举例 规则二 风险描述 投保时保费缴纳账户与退保时账户不一致，违反监管规定的同一账户退保 风险领域 寿险承保 风险主体 销售人员、客户 风险编号 LIUN15 风险事件特征 投保时缴纳保费的账户与退保时退付保费的账户不一致 业务规则 1. 财务应付信息中财务交易类型为退保 2. 对应的银行账户与投保时系统记录的保费缴纳账户不一致 3. 排除保单保全银行账户变更的情况 业务数据项 1）保单信息：保单号，团单号，投保日期，保单生效日期，险种，投保人身份证号，被保险 人身份证号，投被保人关系立案信息 2）账户信息：保单号，账户号，账户所属人身份证号 3）财务应付信息：保单号、保单号、险种、领款账户号、责任代码、责任子码、交易生效日 期、领款金额、领款人 4）财务实付信息：保单号、保单号、险种、责任代码、责任子码、交易生效日期、领款金 额、领款人 36 审计规则 设计 成果举例 规则二（续） EDW数据项 L_AGT_INDIVIDUAL_AGMT: EXTERNAL_REFERENCE, GPOLICYNO, NB_REQ_DATE, OPDATE, CLASSCODE, APID, PID, RENEWAL, RENEWAL_DATE, PRELNAME L_FIN_PAYMENT_DUE_OUT: POLICYNO,CLASSCODE,ACCO_NO,REASON,TYPENO,PAYMENT_DATE,AMT,PID L_FIN_PAYMENT_OUT: POLICYNO,CLASSCODE,REASON,TYPENO,PAYMENT_DATE,AMT,PID L_AGT_ACCOUNT_AGMT: EXTERNAL_REFERENCE,POLICYNO,OWNERID 规则脚本 SELECT T1.APID, T1.GPOLICYNO, T1.RENEWAL, T1.RENEWAL_DATE, T1.EXTERNAL_REFERENCE, T1.APPNO, T1.CUR_SELECTION, T1.PIECES,T1.NB_ACCEPTANCE_DATE, T1.OPERNO, T1.EMPNO, T1.CSRNO, T1.CLASSCODE,T1.NB_REQ_DATE, T1.NUM_OF_INSURED, T1.PID, T1.INSURED_OCCUPATION_NAME,T1.PRELNAME, T1.BENEFICIARY, T1.APP_AGE, T1.REGIONAL_OFFICE_CODE, T2.EXTERNAL_REFERENCE AS ACCO_IN, T2.USAGE, T2.STATUS AS ACCO_STATUS, T2.OWNERID, T2.CUR_SELECTION AS CUR, T3.AMT, T3.ACCO_NO AS ACCO_OUT, T3.CUR_CODE, T3.P