商业银行作为高度依赖信息技术驱动的行业，对数据库、互联网、大数据、云计算等技术的运用正变得广泛和成熟，但也使得风险越来越掩埋于海量数据，通过手工翻凭证、“隔墙扔砖头”的传统审计难以有效揭示。商业银行数据化审计由此应运而生，它作为对传统审计模式的继承和跨越式发展，既是主动顺应大数据时代潮流的需要，更是在业务量日趋庞大、业务日趋复杂、产品交叉特征日愈明显、风险日愈隐蔽等审计环境深刻变化下的必然选择。
一、数据化审计内涵
数据化审计是依托全面的经营管理数据和信息，整合内外部数据，以数据分析工具、信息系统平台等为支撑，对各类数据进行采集、整理、分析、挖掘和展现，实现全面评估风险、精准定位疑点、快捷辅助查证、系统延伸排查等，最大限度地分析内部控制缺陷、揭示业务风险，提升审计价值的系统过程。
数据化审计是对传统审计的继承和发展。从审计的客体、主体、本质看，两者是一致的，前者需借鉴并创新后者的业务检查思路，并基本沿袭后者除数据化外的其他审计方式。主要区别在于，前者对信息技术手段的广泛应用，使得审计对象形式、技术方法、程序发生了较大变化。
数据化审计的重要意义，并非在于掌握了庞大的数据信息，而在于通过对数据进行关联、对比和其他专业化处理，打通数据间的内在联系，让其高效、专业地“开口说话”“说实话”，从而实现数据“增值”，提升审计质量和效率。
二、数据化审计主要特点
（一）面向全量数据
数据化审计能尽可能多地占有各类数据（包括内部数据和外部公共数据），并实现对这些数据的全覆盖分析。这种分析方法有如下优势：一是相比依靠经验所做的抽样审计，可提升抽样准确性，有效降低审计风险；二是能对某一类问题存在的范围、程度进行量化描述，避免模糊个案问题与普遍性问题界限，对被审计对象内控管理状况准确、客观地画像；三是能从业务、管理、机构、流程等不同维度对数据进行分类和整合，在审计人员熟知数据规则和数据间逻辑关系的情形下，除可开展传统业务领域检查外，还能合理关注新业务动向、业务边缘地带、交叉领域、结合部位的风险情况。
（二）以IT技术为支撑
从数据采集、数据整理到数据分析和挖掘，数据化审计几乎全过程涉及IT技术运用。
数据尤其是外部数据的采集和整理运用IT技术较多。审计人员可能需要自行编写批量查询语句以从第三方网站上获取这些外部数据，且因这些数据的格式不一定标准化，获取后需做进一步的清分和转化工作。
数据分析和挖掘作为数据化审计的核心环节，需大量运用IT技术，但目前各行的应用形式与水平不尽相同。两种典型的应用形式为：一是以历史经验和常规技术为基础，开发审计支持系统并嵌入交互式查询模块，供审计人员做简单查询和常规线索获取；二是构建审计数据分析平台，提供数据源和数据仓储分析功能，审计人员根据需要，在线编写数据库语言（如SQL语言等），并获取中间表和最终结果表予以存储和调阅。前者因模块固化，不利于发挥审计人员主观能动性，后者能有效规避前者存在的弊端，但要求审计人员能熟练掌握数据的提取、聚合分组、连接等操作功能。 （参见案例的示例1）
（三）技术与业务有机融合
数据化审计不能脱离业务专业知识而单独存在，没有业务专业知识作支撑，数据化审计必难落地。一方面，开展数据化审计时，若缺少相关业务知识储备，基础数据的取得可能变得困难，表与表间可关联背后的业务逻辑将难以厘清，可能造成没有好的业务思路可供数据分析层面予以转化，技术优势无法发挥作用。另一方面，数据化审计中发现的疑点线索并不必然成其为问题，因为其间往往掺入了审计人员的主观判断和假设前提，直接作为审计结论，有违审计客观性原则，也较难取得被审计单位认同。审计人员应将这些疑点线索回归到业务层面进行查证和定性。
三、数据化审计的主要应用领域
除传统业务领域问题检查外，数据化审计还可应用于全面风险评估、预警系统性风险、揭示隐性和重大的违规舞弊问题、揭示综合性问题、做全行性问题排查等方面。
（一）全面风险评估
确定审计计划时，审计部门可借助数据化审计思维，就哪些机构和业务须纳入重点检查范畴做统筹考量。可根据审计对象的内外部情况，建立评估模型，分析其总体情况和风险分布，进而确定审计事项。此阶段，一般选用聚类和回归等分析方法对审计对象进行预测和分类，降低评价者主观因素对模型评估结果的影响。如采用聚类分析对各对象的信贷风险管理状况进行分层，可从如下四个维度展开：
1. 宏观经济金融维度，包括财政收入、GDP、经济结构、存贷比、贷款规模等；
2. 风险业务及其变化维度，包括关注类和不良贷款规模及增速等；
3. 条线管理维度，包括监察名单客户、条线考核得分等；
4. 检查监督维度，包括重大隐患、一般隐患及内部检查深度等。形成如下将各对象按族群划分的谱系图：
（二）预警系统性风险
集群关联企业套贷、个人虚假按揭贷款等问题，当其所涉客户数众多时，极易形成系统性风险。数据化审计可借鉴既往审计发现中单点的、离散的问题表现形式，从客户关系、资金流、业务流等多角度对这些系统性风险进行揭示。如集群关联企业套贷问题，可能表现为：客户关系层面，多个借款人的关键人（如股东、高管、财务人员）存在交叉；资金流层面，多个借款人的贷款流向同一单位或自然人，多个借款人的还贷资金来源于同一单位或自然人；业务担保层面，多个借款人的贷款由同一保证人或抵押人提供增信措施。上述这些表现形式均可通过数据语言进行转化。
（三）揭示隐性的、重大的违规舞弊问题
随着审计检查的频度、深度不断加大，既往审计揭示的一些显性违规可能走向隐性。但数据化审计通过对“隐性”特征进行梳理，可将其再显性化。以客户经理收取管户授信客户给付“顾问费”为例，因知晓自己的账户必然受到审计人员监测，客户经理可能选择现金交易或要求对方将款项转入自己控制的账户。那么，找出被控制账户即成为数据化审计的关键所在。根据既往审计经验，被控制账户一般为非员工账户且具备如下一个或几个特征：网银签约手机号与客户经理相同；短信通签约手机号与客户经理相同；与多名员工发生资金往来，但与特定客户经理往来最频繁。针对上述特征的数据化审计可借助一定的审计模型，提取相关数据进行关联、转化，最终分析锁定被控制账户。
（四）揭示跨条线综合类问题
随着银行业务的不断深入，营运、个金、授信、财务等板块间的界限已越来越模糊，条线间出现风险交叉和交织日趋普遍。对跨条线业务风险的揭示，数据化审计有着天然优势。以分支行要求授信客户购买基金、保险协助完成指标为例，属监管机构明令禁止的“借贷搭售”问题。该问题从业务角度看涉及授信和个金两个条线，但从数据角度看，仅需找出购买基金和保险的客户及其流水、办理授信业务的客户及其流水，从资金流角度验证购买基金和保险的资金源于贷款即可。
（五）排查全行性问题
由于占有全量数据，数据化审计可将在个别被审计单位审计发现的个案问题做全行性排查，揭示出多个被审计单位甚至全行普遍存在的管理缺陷，有利于更好地引起管理层重视，推动主渠道由上至下整改，最大化发挥审计价值。例如，审计人员在对某行某户不良资产进行岗位责任认定时发现，由于保全人员在该笔资产转让给资产管理公司前未对借款人保证金账户/利息和结算账户予以查找和处置，导致资产转让后不得不将上述账户款项合计20余万元交付资产管理公司。因资产转让定价时未考虑这些账户余额情况，客观上加大了资产损失。随后在全行范围内对此问题进行排查，发现有×家分行存在此情况，涉及×个不良贷款户×万元存款。
四、数据化审计流程
商业银行数据化审计应遵循审计署“总体分析、发现疑点、分散核实、系统研究”的流程要求，即先对被审计单位的业务和经营情况开展整体分析，宏观把握可能存在的问题和区域，再有针对性地对特定领域开展数据筛查，从微观层面获取和查证疑点，最后再综合微观层面的各种表现，整体对被审计对象画像。简言之，应遵循“总-分-总”的工作逻辑，尤其应避免缺乏总体分析，对所有被审计单位采取千篇一律、普遍撒网的审计模式。根据该流程要求，数据化审计大体可划分为如下三个步骤：
（一）审前阶段
1. 对被审计对象开展必要的宏观分析，在此基础上提出可行的、满足审计需要的数据需求, 确定数据采集对象及方式；
2. 全面采集数据，经过清洗、加工等必要程序转化成标准化的、可用的数据；
3. 对前述数据进行总体分析, 初步拟定业务层面审计重点并围绕审计重点，开展数据建模和数据分析，发现审计疑点，形成审计方案。
（二）审中阶段
1. 结合审前确定的审计重点和发现疑点，逐个深入验证和落实，并进行延伸检查；
2. 根据检查情况，灵活调整审计方向和重点，进一步发现新的问题。
（三）审后阶段
1. 对审中查证的问题进行归纳分析，提炼问题特征并参数化，由点及面，再次进行系统性数据分析；
2. 做好审计成果应用和效果评估工作，形成包括数据需求、分析挖掘、核实查证、总结提炼、思路修正等环节的数据审计循环。
为加深读者对此流程的认知理解，案例的示例2给出了一个详细的案例可供参阅。
案例：数据化审计有关工具及实践介绍
示例1：以SQL工具为例介绍常用的数据分析功能
SQL工具的功能较为丰富，但在审计实践中常用的主要包括数据提取、数据分组、数据连接等功能，以下着重对此三种功能进行介绍。
一、提取命令
其作用是从给定的SQL表中分离出特定数据，主要通过where语句实现。如从全部客户交易流水表中分离出个人客户交易流水的语句为：
select * into 个人客户交易流水 from 全部客户交易流水表where个人组织标志='个人’
二、分组命令
其作用是对给定的SQL表中具有相同属性的内容做分类和统计，也可用于剔重，通过group by 语句实现。如从全部客户交易流水表中统计各柜员业务量，可通过两次分组命令实现：
第一步：剔重。由于某特定业务可能因涉及借贷双（多）方而产生多条记录，首先需选择交易日期、柜员号、会计流水号等关键字段分组以去除重复。语句如下，新生成表“第一次分组结果”中的count(*)记载的即为某特定业务（分组字段）借贷双（多）方记录数，通过分组，这种一对多的关系被消除。
select 交易日期,柜员号,会计流水号,count(*) 该业务涉及记录数into第一次分组结果from全部客户交易流水表group by交易日期,柜员号,会计流水号
第二步：分类统计。对表“第一次分组结果”，再以柜员号为关键字段分组，语句如下，新生成表“第二次分组结果”中的count(*)记载的即为某特定柜员办理的业务总笔数（对应交易日期、会计流水号互不相同）。
select 柜员号,count(*) 该柜员办理的业务总笔数 into 第二次分组结果 from第一次分组结果groupby柜员号
三、连接命令
其作用是通过某一或某些共同关键字段将不同的表信息整合到一起。也以全部客户交易流水表为例，该表展示了各柜员办理的业务明细，但不展示柜员总计办理的业务笔数；而“第二次分组结果”则恰好相反。通过将两张表以“柜员号”为关键字进行inner join…on 连接，即可实现既能看到某柜员办理的业务总笔数，又能看到其办理的业务明细。语句如下：
select a.该柜员办理的业务总笔数,b.* into 连接表 from 第二次分组结果a inner join全部客户交易流水表 b on a.柜员号=b.柜员号
示例2：以集群关联客户隐性套贷为例介绍数据化审计实现过程
一、审前阶段
（一）总体分析
在对某行开展内控审计时，审计组初步分析发现，××分行大量开办小微企业贷款，截至检查日有余额的小企业客户数多达×余户，授信余额计×余亿元，而公司类贷款客户和授信余额则分别仅×户和×亿元，此与大多数分行倾向于多做公司类客户、少做小企业客户的展业偏好刚好倒置。分析还发现，少数小企业客户有较明显的集群套贷特征，却被准入，分行在授信调查、审查审批环节对此把关过于宽松。基于此，审计组将集群关联客户套贷问题及分行的管理应对缺陷确立为该次审计重点之一。
（二）数据采集和整理
审计人员对既往的成功审计案例进行梳理发现，集群关联客户多头授信套取贷款从数据层面主要有五种表现形式：一是部分客户申请贷款前股权关系发生变更，以规避银行集团授信管理，但不同客户间的股东、历史股东仍然存在交叉；二是由于银行授信审查时不将财务人员纳入集团授信审查范畴，集群客户往往疏于对财务人员同一性特征进行掩饰，不同客户留存的银企对账用户（财务人员）、企业网银用户（财务人员）存在交叉；三是不同客户间担保措施存在交叉，如抵押人或保证人相同；四是不同客户贷款发放后资金流向特别是贷款受托支付后的资金二次划转流向同一单位或自然人；五是不同客户的还贷、还息资金来源于同一单位或自然人。
基于此，审计人员对商业银行内部的授信客户清单、对公客户网银签约表、对公客户银企对账签约表、授信客户担保信息一览表、对公客户会计流水表进行了采集，同时还通过外部工商红盾系统（付费取得授权）对授信客户的股东、高管人员信息及其变更情况进行了采集。
在数据采集后，对授信客户清单和对公客户网银签约表、对公客户银企对账签约表，使用SQL连接命令，获取了授信客户财务人员信息；通过对工商红盾系统取得数据进行清洗、整理取得了授信客户历任股东、高管信息；将前述二表进行合并整理生成授信客户关系人一览表。
对对公客户会计流水表，通过与授信客户清单进行SQL连接，取得授信客户会计流水表，并在此基础上通过SQL提取功能获取了授信客户贷款发放后5日内资金走向流水表、贷款还款前5日内资金来源流水表。
（三）数据建模和分析
对授信客户关系人一览表，使用SQL分组功能对不同授信客户对应同一关系人情况进行检测分析。
对贷款发放后5日内资金走向流水表、贷款还款前5日内资金来源流水表，分别使用SQL分组功能对不同授信客户贷款资金走向同一、贷款还款来源同一情况进行检测分析。
对授信客户担保信息一览表，亦使用SQL分组功能对不同授信客户对应同一保证人或同一抵押人提供担保物情况进行同一性检测。
对上述几种情况分析得出的疑点进行整理、合并，将符合疑点特征之一的、符合多个疑点特征的情况分别予以列示，形成审计方案。
二、审中阶段
针对疑点客户，在现场审计阶段，采取调阅信贷档案、走访授信客户、访谈经营单位相关当事人等多种方式，逐户予以核验。除问题表象形式列示外，审计人员还需回归业务层面，对被审计单位出现此类问题的原因，从贷前调查、贷时审查、贷后监控等环节存在的疏漏进行揭示，并在审计底稿中指出。
三、审后阶段
综合审中查证的具体各户问题，量化给出问题存在的范围、表现特征，如某某经营单位共有×组×客户涉及多头授信套贷，具体表现特征为×，出现问题的内部原因为×，审计建议为×。最终形成审计报告。
联系客服
