数据应用之道--统一监管报送体系（西安站）
2014-11-28 11:45:46   评论：0 点击：

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

　　在主题为“乘数据之舟，达价值彼岸”的文思海辉商业智能解决方案系列研讨会西安站现场，文思海辉高级技术咨询顾问邱文红做了“数据应用之道--统一监管报送体系”主题演讲。

文思海辉高级技术咨询顾问 邱文红

　　以下为演讲实录：

　　大家好我是文思海辉技术事业部的丘文宏。接下来由我跟大家一起关于统一监管报送平台做一个分享。我相信从九十年代开始，金融监管机构要求银行开始报送监管数据开始，经过这十几年的发展，大家在报送领域来说其实经验都很丰富了。

　　首先我们来看，这个可能跟贾总讲的PPT很像，其实第一部分从监管部门的要求来说，它的要求会越来越严格，而且你可以看到从央行银监会来说，不像以前一样只要求你报数据或者汇总数据，它已经开始要求你在不同的报送体系之间进行数据一致性的校验，第二部分从银行本业务部门管理的需求来说，银行经过十几二十年的发展，它的基础数据已经积累了相对来说很大的基数，银行怎么用这些数据，对你的经营管理客户管理进行分析，为你后续决策做支持，这也成为目前来说银行业务管理部门一个比较迫切的需求，还有一个随着监管要求报送的数据越来越多，我们不可能像以前一样，我一个部门把所有需要报送的报表完成，所以我们在后面怎么明确每一个报送体系当中，每一张报表如何报送的问题。

　　还有从科技部门系统建设来说，也存在着很大的问题，因为我们银行自己本身的信息系统建设其实是早于监管要求的，这个时候就会出现一个问题，监管很多要求的数据，在我们现有的系统当中其实都没有，这一部分我们怎么解决的问题，还有一个由于我们监管系统和应用系统的建设是时间错配，还有我们监管系统是随着监管当局的要求不停的进行建设，这个时候会出现一个问题，因为你不是统一规划你报送的系统，就会出现很多数据重复计算和加工，根据这个情况我们来分析一下，目前我们实现方式能不能随着监管当局和银行本身的需求得到满足。这是目前很多应用系统，包括常见的监管报送系统实现的基本架构，所有的监管系统监管当局要求一个我们就建设一个，每一个其实都是独立的从各个原系推，数据平台仓库或者ODS去抽取数据的，这样的话其实在你抽取的过程当中，对你原系统的压力很大，如果你有十个监管报送系统，你得从原系统抽取十遍。你每一个系统随着技术的发展，每一个报送系统实现方式跟技术架构都是不一样的，所以经常会导致每一个系统从原系统拿数据的规范是不一样的，不统一的。

　　其实在每一个报送体系当中，对于基础类的数据，在每一个系统当中其实都会存在一遍，在本系统当中进行加工然后报送，这种情况实现的时候，其实你所有数据的重复性，这是第一，第二你的数据重复加工，就相当于你数据的复用性很差，我们可以按照这种架构来看一下目前我们监管当局的一些要求是不是能够得到满足。

　　首先看一下银监会的，基本在2011年之前，银监会要求报1104，基本上报送分行和总行，2012年的时候随着新巴塞尔协议的提出，又新增了一个新资本充足力的报送，这些前面的报送基本上都是汇总的，汇总类的数据，后面又新增了两个，一个是新版客户风险统计，这两个报送就不再是汇总类的数据，它要求是你的明细数据，在以前的报送系统当中，一般只要求你进行表内或者表间，每一个报送体系内部表间的校验，在这个地方又新增了两种，一个是数据总量的校验，还有一个余额类的校验，通过这个其实你可以看出它这种监管的发展趋势，第一个是体系切的，交叉的校验会越来越多，而越来越复杂，第二个报送口径的不同，其实这两个在数据加工，如果说以前你做过这种统计报送的话，会发现它的基础类的基础数据其实都是一样的，也就是说这个基础的重复性如果按照以前的架构，会在不停的提升。

　　第二从银行监管的报送来说，在2012年以前基本上两年就会出现一个新的报送体系，最长六年，在2012年到2013年之间，每年都新增了一个报送体系，而且在这个里面，你可以看到跟银监会的报送要求一样，新增了不同的报送体系之间的校验，不再是简简单单的这一个报送体系了，所以从这里可以看出，在人行的报送当中，他的明细数据的报送需求在逐步增加，逐步的在不同的报送体系之间要求你报送数据口径要一致。第三个我们从外管局的报送来说，其实外管局在早期的时候，只要求我们流水数据，你可以理解为明细数据，也就是国际收支外汇帐户还有银行资本项目，通过这些基本的明细数据以后，基本可以监控整个外汇流入到流出一整套的交易过程，在2013年8月份的时候，基本上又提出对外金融资产负债及交易统计的数据报送，这个报送其实就不是明细数据了，是一种汇总，可以参考前面的人行跟银监会报送的数据质量的要求，下一步会不会提出另外一个要求，这个明细跟这个汇总数据，在某些信息项里面进行勾兑。

　　所以从这个我们是不是可以看出，以后一旦监管报送提出新的需求时，你怎么快速的满足监管要求，所以通过目前我们采用的架构，以及监管当局他的需求，我们可以看出按照目前的架构，很难满足我们这些监管当局的需求，如果说继续用这种原来的架构开发的话，会面临很多的挑战，第一个数据共享问题，因为每一个监管报送都自己独立成一份数据，在不同的报送体系之间，很难使数据进行共享，而且这个数据既是加工出来了，它的复用性也不是很高，第二个数据的一致性，因为你的数据它要求在不同的报送体系之间需要相互进行校验，如果还是按照以前的思路建设你的报送系统，大家做技术都很明白，要实现不同库之间的数据校验其实难度还是蛮大，因为大家采用的技术不同，而且每一个报送开发公司都不一样，所以这个相对来说难度比较大。

　　第三个就是你的接口，因为我们的报送包括采集数据内部处理，其实在很多时候，随着技术的发展大家希望采用一些新技术，所以这个时候你可以发现连你每一个应用系统都没有统一的规范，用到某一种模式，数据之间是怎么交换的，可能都不会统一，另外一个从管理角度来说，大家知道在银行做运维的话其实是很累的工作，如果你每一个报送都单独开发一个系统，那么对于运维来说其实是蛮大的压力，要熟悉不同报送系统的架构，不同数据的处理规则，所以如果按照原来的那个，其实对整个报送体系运维人员，大家增加了人力成本跟物力成本，还有一个是业务价值，业务价值前面讲的大家可能很难理解，其实应该是这样，因为从刚才我们第一个PPT里面讲的，在银行来说大量的基础数据，如果说应用的好，可以发现很多的开拓你新的产品，新客户的领域，在这个时候如果按照以前的架构去做，因为你的数据是分散的，你没有做过统一的整合，这个时候其实很难通过数据分析，也很难通过监管当局对你的要求角度看你的数据是不是符合他的要求，我们带着这些问题可以换一种思路。

　　早期的时候包括技术可能达不到我们现在的这种程度，随着科技的发展，技术水平的提高，我们可以换一种思路来建设我们的监管报送，也就是说我们把所有的报送建设到一个平台当中，现在其实每家行都在提数据平台和指标系统建设，如果说我们把这两种系统，这两个内容融合到我们的报送体系来，会是什么样的结果，我们来看一下，首先第一个我们将整个监管报送平台分成两部分，一部分是后台的平台数据区，还有一个应用服务区，他们两个侧重点不一样，这边注重的是整个应用，平台数据区主要注重数据处理，基本这两个之间我们使它的吻合度尽量的低，不要大家都连到一块儿去。

　　首先我们来看一下平台数据区，我们基本上分成两块，一个是数据源区还有一块是报送数据区，数据源区是作为整个报送系统的唯一数据来源，也就是说后面所有都依赖于它，在报送数据区里面又分成两块，一块基础数据区，一块加工数据区，这两个有什么区别，基础数据区基本上是明细，加工数据区我们会按照采用指标的管理模式去管理你所有的数据，应用服务区我们也可以认为是两块，一块是基本功能的，比如你的补录，你的报表定义，你的权限管理这一块，另外一块就是对外报送，按照不同的监管报送体系，产生不同的报表的那一块，针对这些分区我们独立看一下每一个分区的定位跟作用，平台数据区它涵盖的是从原数据的采集到数据报送出去整个的数据。

　　刚才已经说了平台数据有数据源层和报送数据层，数据源层其实说白了如果做过ODS的应该比较清楚，我们采用ODS的方式，通过拉链保留全量的数据，很多人可能会问，为什么要保留全量数据，因为任何一个张报表的跑，可能都会出问题，或者出现其它情况，这个时候我们可以通过保留的全量数据便于后台处理的存跑，如果你错了，其实你可以回溯查询这个数据错在哪里。

　　第二个报送数据层，报送数据层我们基本采用仓库的共性加工理论，共性加工层的那部分建设思路，来建设这个基础数据层，我们会按照你的业务或者分层次的建立每一层的明细数据，这些明细数据它有什么作用，它第一个是用于你报送时明细数据的报送，另外一个对你后面的指标层的共性加工的那一层提供数据。后面的加工数据层，加工数据层在这一块建设时，其实采用的是指标建设的那一套思路，我们把所有的报表非明细类的数据，抽取成指标类的数据，来进行管理，在里面我们总共分成三块，一块是公共指标集，一块是公共数据集，还有一个个性加工集，这三块究竟有什么区别，首先第一个公共指标集，说白了主要是从总站，或者按科目那一条线走的，比如按机构这两个纬度去抽取或者简单加工的数据，其它类的公共数据集就是多维度的一些数据，像我们在人行，或者银监会的报表里面会出现一个报表，比如贷款有行业跟五级分类，包括你填报，其实这两个数据两个纬度在银监会人行都会存在，这个时候我们按照纬度相同，可以通过公共数据集的模式进行加工，后续取数的时候，不需要再去做，只需要再Excel表里面，把指标编号填进去，就可以实现整个数据的抽取过程。

　　个性加工层，这个基本上就是我对一些没有在不同的报送体系当中，没有重复的，我自己很独立，跟别人不一样的这部分数据放到共性加工层，大家可以看出整个报送体系当中，每一层数据的定位跟作用，对于前排应用服务层，我们分成两部分，一部分是应用系统，另外一部分是应用门户，应用系统是实现对外监管报送的功能，主要用于按照不同的报送体系，去生成你的报送文件，在这个时候也可以进行数据的检查或查询，门户数据其实就是一个应用，门户在这个里面我们会涉及很多的基础管理的功能，首先第一个体系管理，它这个里面基本上是定义你的报表体系，比如你的A104报表体系，你的征信报表体系，每一个体系下面有哪些报表都可以在这个里面进行定义，还有它的校验规则。统一认证基本实现角色权限的复制，实现单点登录的功能，数据补录主要针对数据缺失这方面，还有试算，可能会对统计出来的报表需要进行一些调整，调整完之后，肯定想知道这个数据对于你下游其它报表会不会有影响，你可以通过这个试算调整来分析一下，垮体系校验是我两个报表体系根据监管当局的要求，进行比对的那些数据你可以查看一下，这两个数据是不是一样，多维分析其实是针对你的业务管理，因为我们不是把明细数据也拿了，把你同所有需要报送的数据都做成了指标，你可以通过多维分析根据你自己的需要设定，来进行数据的查询。

　　前面讲的架构的每一层作用，接下来我跟大家把一些主要的层次的功能跟实现方式跟大家做一个交流，首先我们看一下基础数据层，也就是刚才我们说的明细层，在这一层里面，我们会按照总站类，分布站类，协议类，交易类，不同层级的数据做一个明细的数据，把这些数据所有详细信息放进去，这样这一部分数据不光提供给你监管报送的需要，其实还提供给你后面你业务分析的需要，在这个里面，每一张明细数据它可以适用于不同的报表系统，并不是我会针对哪一个报送体系做明细，我这个明细是共用的，你任何的报送体系我用的都是同一个报送明细。

　　指标的体系，指标里面我在做的时候，其实不光是站在监管报送的角度，是站在银行全行的业务需求的角度，对全行的指标做分类，比如我们可以把他分成规模类，效益类，结构类，还有效率类，客户类，渠道类，产品类、市场类，风险类，通过这九大分类，我相信能够涵盖行类大部分的指标，应该都能，包括你的监管指标也可以涵盖到里面来，针对每一个九大类，可以根据实际的需要你再去分你的指类，这个加工设定以后，我们会针对他每一个指标里面再进行详细的关于这个指标的管理，比如指标名称，指标的代码，指标的含义，还有指标的计算公式，你的指标计量纬度跟频率，这些都可以通过指标设计里面进行设置，这个就是指标体系的实现方式。

　　还有根据监管当局的发展趋势跟要求，其实我们可以看到它很重要的一步就是校验，在整个统一监管报送平台当中，因为我们的数据在一个平台，所以对交叉校验来说就很容易实现，而且我们的校验可以进行很多类，不光是监管当局要求的那些校验，而且这些校验基本上都是可配置的，并不是我给你固定的，你就可以自己配置。这个是我们的应用架构，在这个里面，其实大家有所了解比如门户管理这一块，我们是管理他的用户，而且角色，我们这个用户其实复全的时候是通过角色，在数据管理这一块，对指标报表可以进行配置，比如银监局或监管当局要求一个新的报表，可以到这个里面进行配置以后，把这个报表复制给你这个角色，具有那个角色的人可以操作，他进来的时候可以使用这张报表，这个里面还有一些补录数据。

　　第三个平台展现这一块，这一块会随着你的报送体系，因为报送体系是设置的，随着你的设置这一块会逐渐增加，自动会产生一个菜单给你，在这个里面其实有两块可能比较特殊的，第一个是指标库的应用，他的目的是对你设计的指标，可以不用通过报表，直接提取出来查看一下，还有一个是报送应用，他的目的如果监管当局提出一个新的报表的需求，你开发或者调试花很多时间，可以暂时先通过这一个，把报表查询出来，快速的相应监管当局的要求，这基本是监管报送平台的应用架构。

　　前面讲了这么多，在我们统一监管报送平台里究竟应该建设什么样的平台，建设的时候其实会有哪些要求，首先我们从数据层来看，你必须要搭建一个基础的比较坚实的基础数据，具有统一的数据来源，第二必须对这些数据进行充分的整合，因为你的数据可能都分布在不同的系统当中，比如你的贷款可能在核心游，在信贷游，而且这些数据质量都不一样，所以做的时候必须对这些数据进行充分整合，还有完善的数据质量的管理，还有高效的数据积累的校验，这是从数据层面来说。

　　第二个从你管理角度来说，你必须制定完备的报送制度，因为这个里面很多指标管理，还有开发规范是需要你制度去约束的，并不是一个程序就能解决问题的，所以从制度管理角度来说，要完备，第三个从展现的门户来说，你必须建立一个统一的报送平台，集中报送管理，还有快速的报送相应，另外一个能够实现灵活的统计分析，从数据、管理制度、应用实现来说，三个层面从内到外进行一体化的管理，通过这样来应对监管当局对银行的需求变更。我的分享基本上到这里，谢谢大家。