数据分析之道--全面风险管理及风险集市构建（西安站）
2014-11-28 11:51:06   评论：0 点击：

　　随着中国金融市场的快速发展，互联网金融对传统金融行业的竞争，以及监管力度的不断加强，IT咨询服务公司对金融企业的商业智能方案也面临不断创新。如何提升金融机构在管理、盈利、风险控等多方位的能力？如何将国际经验更好的为中国市场服务？如何通过解决方案将海量数据转化为对经营决策有价值的信息之路？如何将客户智能分析成果行之有效地运用于服务渠道，并最终转换为销售业绩？为解决中国金融机构在发展中所面临的新问题，文思海辉在西安、苏州、北京、成都、深圳五地举办了6场“乘数据之舟，达价值彼岸”系列活动。

　　在主题为“乘数据之舟，达价值彼岸”的文思海辉商业智能解决方案系列研讨会西安站现场，文思海辉商业智能部风险咨询顾问宋杨做了“数据分析之道--全面风险管理及风险集市构建”主题演讲。

 

文思海辉商业智能部风险咨询顾问 宋杨

　　以下为演讲实录：

　　接下来大概十五到二十分钟时间，我想跟大家快速分享一下关于金融行业的风险数据集市的构建。为什么分享这个议题，因为这也是我们BUBI这个部门认为，未来的三到五年搭建好了基础数据平台之后，我们会大力推广的一个应用产品之一，就是风险的数据集市。

　　今天快速过的几个内容，一个是为什么我们会认为风险集市这个产品或者这个应用，未来的三到五年在银行之间会被大量的做广泛的推广和使用，对我们来说也是一种商机呢？就是因为银监会2013面的1月1号颁发了一个商业银行资本管理办法，这个办法是要求各家银行都要满足的，而且在2018年达标的，风险集市的构建最初的基本需求就来自于银监会的资本充足率的管理办法要求，所以今天我们从数据需求角度来解读一下商业银行资本管理办法的要求，看一下银行必须具备哪些数据才能够做到这样计算的要求，这也是我们建设风险数据集市的需求之一。另外一个跟大家分享构建风险数据集市或者构建风险应用，目前在各家银行里现在的主要三种架构，看一下这三种架构的优劣点，这也是我们为什么会一直推广，还是有必要建设风险数据集市，然后建设各种风险类的应用。

　　风险集市产品的构建，其实它的很多理念跟刚才讲的统一监管报送平台的理念是很类似的东西，从商业银行资本管理办法的要求里面，你可以看到大家对数据的需求是很类似的，我们可以看到他们共性的数据需求，在这个办法里面，它满足的整个是巴塞尔协议的一二三的要求，整个办法里面是十个章节，最重要看数据需求，都体现在十七个业务附件里面，附件里面明确讲了每一种信用风险，市场风险和操作风险的计量方法，从计量方法里面我们看待计量方法时，我们更多看今天如果我要满足你这样的计量方法，银行都要有哪些基础数据，这些基础数据都要有多长时间的历史，这样我才能支持你做这样一种计量。

　　整个办法为什么要做系统风险，市场风险和操作风险，其实根本目的是算风险加权资产，算银行的资本充足率这个要求，在这个资本充足率要求里面，你看资产分母是包含了系统风险、市场风险和操作风险，就是说三大风险都要含在里面，但是对每种风险的计量方法上，可以说是从粗到细或者从初级到高级有不同的要求，最基本的来说，每家银行都要满足权重法，所谓的标准法做计量，再往上你就可以用类评法，或者用一些高级法，这两个之间大概的差别在于标准法一般是最粗暴，最简单的分类方式，如果银行用这种分类方式来计算你的系统风险或者市场风险时，带来的影响是可能监管资本的要求会更高，如果你具备了足够多的数据，又具备了足够多的建模过程，以及数据模型的运行经验，你可以用类评法，模型法做计量，带来的直接结果就是可以大量节约资本。

　　所以几个大行和股份制银行因为他们很早年就已经开始在做风险领域的应用，所以现在这些银行大部分都已经开始用内评的初级法来做，但是对于城商行刚起步阶段，可能大家一开始还会做权重法做，但是未来慢慢一定会逐步过渡到内评法和建模的方式。

　　我们接下来简单看一下三大类的风险应用所要的数据都是哪些方面的内容，最重要考虑的东西是系统风险，系统风险这一块，在第一阶段你可以最初始的用权重法来算，权重法规则非常简单，就是把所有表内资产按照十三大分类，针对每种分类固定一种权重值，你只需要把我的所有表类的业务资产能够把每种资产的记题明确下来，我把我的资产余额减掉这个记题之后，再按照产品分类或客户分类能够把它对应到十三大分类的权重上去，就可以很快算出我的资产，如果满足权重法的要求，因为它里面涉及到一个表内资产，一个表外资产，还有一部分属于交易对手的系统风险，从这个角度满足权重法的要求数据需求是什么？其实数据需求非常简单，大部分银行都会满足，我只需要知道我所有贷款，信贷的业务，个人对工的合同和借据，每一个合同借据下关联的合格的抵押物，还有每一笔借据能够做到的记题是什么，基本上我就能够做到权重法的剂量要求。

　　而且用权重法做计量时也没有什么历史数据的储存要求，这个里面还有一个，权重法会有讲到合格风险饰品，所以在这块对每一个借据对应的风险饰品也能够记到借据层面，基本算出来的风险加权资产就会比较准确的，这是第一个权重法。

　　但是权重法里面最大的问题，它只有十三种分类，这十三种分类实际很粗暴的把所有的对工，一般的公司业务全部都是100%的加权资产，只有对小微银监有一个新规定可以到75%计量，你可以认定这个企业是小微企业客户的话，他所有的资产风险权重算到75%，所以它的分类方式比较简单，现在大部分银行一上来在系统风险这块，已经开始做内评初级法了，内评初级法说白了就是算每个客户的违约概率，我不再根据简单的一般企业100%的权重算资产，我把一般企业按照每个客户违约概率然后根据这个违约概率不同算他对应的风险敞口类型，所以采用内评初级法主要算PD，算PD有两种做法，一种对对工客户，这种算PD很简单，就是算到每一个对工企业的客户，对零售算PD麻烦一点，因为零售客户量太大，所以大部分采用方法是ABC卡，先对零售客户做评分，用评分模型做分池，所谓的零售客户分池概念，就是分群，他把每一个分池去设定统一的PD值，对应统一的LGD和EAD来计量它的风险，内评初级法在2006、2007年时，很多股份制银行和四大行已经开始用这些方法，所以目前这个内评初级法本身模型的构建方法都是比较成熟的方式。

　　所以大部分的银行一上来可能都会先去开始用内评初级法的方式来做，如果你今天用内评初级法相较于权重法来说，它在数据需求上我觉得唯一区别的地方，因为它要算违约概率，所以除了上面算资产所必须要的资产的明细项目之外，还有需要用跑PD模型所需要的客户行为的特征类的数据，就包括客户的交易数据，对工客户来讲最重要算PD的条件是企业的财报数据。如果算内评初级法的话对上面来说，要的主要是这一类的信息，另外一方面如果实施内评初级法还有一个要求，会要求你的模型，建模所基于的历史数据必须要求保存五年，所以这种情况下，我在建风险数据集市也好，或者是我今天为了零售的内评，或者对工内评构建它的风险应用来说，至少都要求有五年的历史数据累计才能构件这个模型，而且当你做达标评审时，要求这个模型必须要稳定运行三年。

　　所以换句话说如果我们今天想申请内评法的话，应该是在明年至少把这个模型做出来，有三年的时间保证它运行，到2018年才有可能跟银监申请，我用内评法算资本充足率。内评初级法要的数据，从各家银行来看，基本上大家也都能够满足，没有什么太大的问题，接下来有一些人还算内评高级法，内评高级法和内评初级法最根本的差别在于比它更近的一步，我不仅算PD，我连每个PD客户下的LGB它的违约概率和违约概率希望对应的敞口也要算出来，换句话说LGD和EAD就不是银监的规定来算了，直接也是根据把每一种客户的不同情况通过模型跑出来。

　　如果你想要算每一个客户的LGD或者EAD时，你必须要有大量的历史数据的累计知道对我以前的一些以违约的客户，他们在过去违约时，我能够从它的抵押物里面做保全清收，我能够收回来的资产到底有多少，换句话说我们所有的抵押物的东西，不仅要关联到借据，而且每个抵押物的资产价值必须要分配到每一个借据层面，另外当你做保全签收时，必须得清楚知道我回收回来的抵押物的价值能够拆分到各个不同的借据上面。如果今天用内评高级法的话，这块的数据对各家银行来说都是很重要的东西，目前看大部分银行，或者很多银行！在这一块的拆分上面，基本上目前的数据来说是不支持的，因为很多银行的保全签收虽然在抵押物时，很多银行能够把它区分到这个抵押物摊到每个借据层面上，它到底担保的金额是多少，但是当你做保全签收时，很少有银行能够把我真正保全签收回来的钱，也能够摊到各个借据上，没有这部分数据支持，当你做内评高级法时就有一些困难。

　　我们现在做华夏银行时，他们同步就会起一个项目从现在开始，把它的保全签收的数据拆分到各个借据上开始做这种数据的累计，而且如果用内评高级法的话，你的数据累计期比初级法要求还高，要求有七年的历史数据支持你做这样的建模。所以从这块来看，如果做信用风险加权资产的话，大部分银行满足内评初级法数据是可以满足的，而且需要有五年的历史数据积累。

　　市场风险这块，其实市场风险主要是算交易帐户下的预期的损失，市场风险算法虽然很复杂，但是有很多成熟的工具和产品，我们支持市场风险做计量的数据其实是很简单的，市场风险加权资产这块，也是分了两种方法做计量，一种用标准法，标准法也是一样的，银监针对四大类不同的市场风险给出了不同的权重值，利率、股票，外汇、商品交易期权，所以如果我满足标准法的方式，标准法里面唯一差别是我算风险时，按九期算还是按十期的到期日方法算，这块问题也不是很大，这块计量时，我们对他满足的数据需求，所有的资金业务系统，它都能够提供交易明细数据，我的每一种交易、每种产品每天的投寸还有每天实际估值都是可以算的，有了这些东西之后，按照标准法算市场风险，其实很容易，基本上往这些固定的产品放数据就好了。

　　市场风险的内模法也很简单，内模法主要是算VR，在内模法算VR时不仅要求算一般风险的值，还需要算一下压力测试下的值，这两种方法在计量的时候，他们对基础数据的需求其实基本都是类似的，没有太大的差别，只不过你用内模法的话，一般至少要求一年交易数据累计，而市场风险这一块，因为它的中后台有很多成熟的产品，所以基本上我们计算时，是从市场资金系统的前台业务系统里面，把所有交易信息、投寸信息给到风险系统里面，就会帮你跑出这些东西，所以相对比较容易，也比较容易实现。大部分银行上市场风险时，主要也都用内评法的方式做，只是看你选择什么样的产品。

　　操作风险这块，其实操作风险对数据的需求是比较难的东西，因为操作风险很多关注的是业务流程的东西，所以有很多数据伴随业务流程的东西做收集，目前在操作风险的资产计量上面，因为它的资产计量即便指标法我们现在不用了，主要用标准法，标准法在计量操作风险时，因为很多操作风险很难评估，所以这种情况就很简单的把你的总帐拆成八加一的业务条线，只要把所有收入按照八加一的业务条线拆分以后，八加一里面每一个都对应一个操作风险的权重值，我直接可以算出操作风险的加权资产，这块我们要提供数据的话，主要提供一些总帐类的数据，这是比较简单，但是操作风险在做评估的过程中，有可能会提出凯尔指标的东西，这些凯尔指标有可能也是要求你加工计算后得到的东西，目前我们看到的很多凯尔指标在数据需求上，大部分银行不见得能够满足，因为有些指标要求算员工的离职率，特别是重要岗位上的员工的离职率而带来的操作风险的影响。

　　所以很多情况下这种数据计算对操作风险来说都是靠手工做收集和统计，这块是操作风险对资本计量目前的要求，如果满足银监的要求，你只需要把总帐数据收集好，业务总帐明细总帐数据能够按照八加一条线做归类基本就可以满足要求。我们站在数据上对办法的解读你可以看到，其实建风险应用，无论怎么建，它所需要的基础数据层面其实是共性的，它要的基础数据无非是这些东西，你的所有信贷类的合同，授信合同，借据，个人抵押物的信息，包括抵押物跟每一笔集聚之间的关联信息，如果你今天要算PD可能需要一些交易行为类的信息，客户类属性的信息，资金市场风险这块，需要一些资金业务系统的信息等等，所以你会看到这些术语之间是有些共性要求的，这些数据里面，如果我今天算权重法的数据，和我今天用零售，用PD算零售内评的数据，其实这两个之间是有很多共性需求摆在这里的。

　　所以我觉得为什么我们认为建风险数据集市很有必要呢？因为这些数据是有共性的，而且同样有保存历史的需求，而且从商业银行来说，第一步我构建风险集市或者风险应用，第一阶段就是为了满足银监会的要求，但是从长期来看，其实银行的风险管理一定会贯穿到银行整个日常运营过程中，为什么？因为银监发布的这些强制性规定，其实就是约束各家银行，希望大家从过去的粗放式的经营模式，转向精细化的，风险与收益相均衡的正常的盈利模式里面，如果我今天能够准确的计量每一个客户的信用风险，计量这个风险给我带来的损失，你想我所有定价策略就不一定针对所有客户采用同一个定价策略，很可能我对高风险客户采用高定价，低风险客户采用低定价策略，所以最终也是银行最后满足股东价值最大化最终的目标需求。

　　所以银行构建风险类的项目，一定不是短期内看起来像是满足银监的要求，但是从长期发展来说，我觉得一定是银行未来的业务分析或者业务发展的大趋势之一。

　　目前各家银行建风险应用，基本上是典型的三种建设方法，为什么会有这三种建设方法，就是因为跟每家银行现在做集成数据平台，或者建数据仓库的平台的建设步骤有关系的，另外一个也跟建数据仓库的数据模型设计和应用的数据模型设计本身之间的差异性也是有一些关联关系的，所以才会有这三种不同的建设方案。

　　第一种方案很多银行在刚开始如果为了快速部属各种风险类的应用，我又没有及时把我的数据仓库平台构建起来，很多银行刚开始就是从原系统，针对每一种风险应用项目针对这个项目自己从原系统里面抽取数据，自己做数据清洗加工转换，自己做数据整合，做历史数据积累，这是一种建法，这种建法其实从刚才看到数据需求的共性来看，你会看到优劣也会显而易见，好处当然就是建的很快，你上哪个应用，就建哪个风险应用，直接从原系统把你要的数据取过去就好了。但是劣势也很明显，建每一个应用时，都要自己做同样的数据清洗，可能重复做一遍，最简单的RW，如果今天我几个项目做权重计算风险加权资产，同时我又起这个项目做零售内评法，为了满足PD模型，用PD的方式算加权资产。RW用权重法我要的数据也是要个人借据，对工的借据，而且我一条借据就要当一条借据来算，对于零售算内评时，也要个人的借据，个人的合同，唯一比他多的可能就是我需要一些个人的行为数据跑模型而已。如果用方案一这种方式建的话，大家各自独立去建，独立做数据的清洗。

　　方案二这种方式，很多时候因为很多银行建了集成数据平台，特别是建了数据仓库以后，首先要考虑让数据仓库发挥价值，数仓发挥的第一个价值是报表和管理价值仓，剩下一个很有用的业务价值就是做风险应用，所以有些银行起的比较早的银行，他们建了数仓之后，直接去支持各种风险类的应用项目建设，这个有一个好处，数仓至少帮他做了第一步的数据清洗加工转换，做了一些历史数据的积累，为什么现在我们又出现了RDM，风险数据集市的概念呢？其实这个最大的原因在于数据仓库的模型构建方法和构建理念，和风险集市的模型的构建方法和构建理念是不太一样的。

　　其实原系统的数据模型还有数据仓库的模型和以后的数据集市的模型，他们的方法构建理念是不太一样的，所以用途上面也是有一些差别，对原系统来说，这是最基本的生产系统上构建数据模型，基本都是以业务流程来设计，所以他们这种表和表在业务系统之间流转时，很可能造成一些重复，重复最典型的是现在银行都搞大外围小核心，通过一条借据或者同样一个授信合同，在信贷系统里面先做生成，再传到核心系统里面去，这样一条借据在你的生产系统里一定存在两条，因为在信贷这边存在一条借据，在核心这边存在一条借据，借据存在两条，可是当我算风险应用时，我看两条吗？不会按两条看，一定按一条看，如果从原系统取数的话，我这条借据一定要做整合，整合时就要知道哪些东西从哪里来取数。这是原系统的数据模型，到了数据仓库模型时又不一样了，因为数据仓库从一开始建，是希望支持全部的应用，满足领导问的任何一个业务问题，所以从一开始仓库模型的构建上就要考虑它的灵活性和扩展性，所以会用3NF的方式来做，会尽量容纳各种各样不同类型的数据在一个这样的数据模型里面，比如刚才讲的所有借据都能存下来，我直接存到协议里面。

　　我为了保证拓展性，这边有一堆协议金额，那边有一堆借据金额，这么多金额我怎么存呢？我做一个协议金额历史，我把各种各样的金额都可以摆进去，仓储模型的设计理念好处是灵活拓展稳定，保证了历史，但是它反过来带来的问题是让它整个数据模型丧失了一些业务可读性，换句话说这样的数据模型如果今天直接拿给业务人员用，业务人员是不懂怎么用的，因为他们看不懂这样的数据模型。

　　集市的模型又不一样了，集市模型在构建时，其实是把某一类的应用，把这一类的应用他们是如何看待这个数据和如何使用这个数据角度做的模型设计，所以在构建风险集市的数据模型时，我们会看大部分人因为看待借据时，都看一条借据，我们大多数人都会认为，借据里面跟金额类日期类，利率类相关的信息，我都应该以核心的数据为准，所以利率的业务属性的信息，比如它的贷款头像，用途这些我应该以流程类，管理类系统为准，在这种情况下，在集市一定会帮上面的风险做数据整合，然后我一定确定唯一的取数来源，这样整合后的数据到上层去，首先业务人员是很明细能看懂这样的数据模型，不管是RW用这个数据还是对工的内评法用这个数据也好，取到的数据都是一致的，刚才讲到了数据质量和数据管控的问题，有可能我们可以在这一层面做一些统一处理，保证上层各个应用上面使用到的数据是一致的。

　　所以从这个角度出发，构建风险的数据集市短期看可能有些银行为了快速上项目，你觉得这种建法被摒弃掉，但是长期来看还是会推荐大家去构建，以大的风险应用为基准，逐步去构建风险的数据集市，未来去支持上面所有的全面风险应用。

　　风险数据集市因为未来我们也有计划，现在平安银行和华夏银行在做构建，我们也计划把这样的东西包装成一套快速做部属和实施的风险集市产品，这样可以到其它银行做快速部属。在这样风险集市模型架构里面，我们考虑的就是整合层，刚才讲的会把基础的，按照风险应用所需要的数据，它的整合需求在这一层做完，做完了之后，另外要满足各种风险的计量应用，这些计量里面的计量变量有一些可能是风险集市帮你计量好的，比如客户的评分加工变量等等，也有一些计量变量是来自于风险用回流的，比如你零售内评算完PD，这个PD一定要回到集市来，再给下一次RW的项目做内评法计量资本时会用其它的PD值来做垮风险应用之间的数据共享。另外一个专门为上面风险应用项目时，为他们提供专门的数据交互接口。

　　所以风险集市的主题与模型设计，如果大家见过数仓的主题与模型，这两个之间是有差别的，虽然大家整合层都是十大主题，但是这个主题会更偏重于风险应用，或者风险的业务人员他们日常会关注或者使用到的一些名称或者术语来设计整合层的主题模型，最简单的这边会把担保款式拎出来，但是在仓库的基数层里面，所有的申请、和约、帐户这些东西都放在一个协议，一个大的主题里面融合起来，所以这个主题模型可能也跟仓库有些设计的不一样的地方。

　　所以这个就是我们以后会逐步完善或包装的风险集市的产品，设计理念就不说了，未来推风险类应用时，我们会把风险类整个分成三大类看，刚才讲的是风险集市的产品，因为风险集市之上要支持零售内评、对工内评或者市场风险，我们有一些风险应用实施的团队，他们更熟悉市场风险的产品工具，比如零售系统风险更熟悉工具，实施团队主要负责风险应用跟咨询厂商的对接，或者本身具有业务咨询能力，可以在产品上做快速部属实施，风险集市最重要的是为风险应用提供整合好的加工的历史数据，另外我们还有一个挖掘团队，来拌前面的风险应用，做风险数据挖掘模型构建。我的差不多完了，谢谢。