市场风险管理与中国银行案例

ZDNET至顶网CIO与应用频道 07月22日 北京消息：随着中国金融市场的快速发展，金融行业竞争形态的持续演化，以及监管力度的不断加强，IT咨询服务公司对金融企业的商业智能解决方案，也面临着不断的创新。

在主题为“乘数据之舟，达价值彼岸”的文思海辉商业智能解决方案研讨会上，文思海辉高级应用咨询顾问张宁在风险管理之道分论坛分享了市场风险管理与中国银行案例。

以下为演讲实录：

今天会跟大家分享实施重点和我们遇到的困难和解决思路。这是市场风险集市项目，这个项目中最直接的项目建设的原因是因为他要上一个新一代资金业务系统，这是一个新系统替代老系统的过程。随之而来的必须有一些辅助性的配套项目来完成接口升级。这是最直接的导致项目产生的背景原因。在此之上还有一些锦上添花或者是更高的要求。分别是：首先它是一个全球性的国际性银行，在这个银行里要实现集团市场风险管控的要求，风险计量这方面，我希望能够得到更灵活的VaR引擎，并实现基本的回归分析和模型和风险收益分析功能。这个行希望把现在分布在各个风险数据集市的数据，将来想从构架上有一个想法，有这样一个理念，他希望做一个整体的风险数据集市。

上述项目背景之下我们目前的IMA系统的功能分为数据整合、数据处理等方面。技术部门对我们的支持非常重要，事实上在风险集市类的项目中，特别重要的一个感觉是，在这种项目中，业务部门对你的支撑也是非常委员重要的。所有的报表需求要跟业务部门达成一个非常好的沟通和让他们最终确认的需求。项目中，跟我们直接有工作上的交互的业务需求，对我们有支持的有十多个系统。我们的数据源来自于具体的业务系统。逻辑上会有一些数据引擎，前端支持报表的访问。数据架构我们还是追求经典四层数据结构。一开始从ODS层开始，还是存储业务数据，中间是面向整合，提供主题设计，提供规范和共享的整合数据。汇总单元层提供数据共性访问。最后应用展现层是面对应用定制多样化展现。

整个项目的实施路径有三个阶段逐步推进。首先完成总体设计，之后进行总行投产，这个阶段对外满足应用需求方面集中在报表开发工作上。对内部整个数据层我们会建设主要以ODS层建设和汇总层建设为主。项目第二个阶段实现海外投产，海外投产过程中会对海外需求进行调研，并且满足更多的报表开发需要。内部数据架构层面上，我们会完善整合模型层，并且完善汇总架构层。最后一个阶段是项目功能提升，这时候会实现计算引擎的实践，并且优化数据架构和完善报表功能。

第一个阶段的需求还是以报表加工为主。在整个大需求背景下，我们最重要的工作还是面向数据的整合。提到数据的整合，现在看到的是需求的整合，第一步要做业务访谈。我们面临着许许多多业务部门他们提出的各种各样业务需求，这些需求中要对共性需求进行提炼加工，分别面对不同的业务主题确定实施表的设计。我们看到了需求整合部分，需求整合工作完成之后我们会看数据整合，然后把所有报表需求放在这里面，最后个交叉图反应了整个实施表对不同的业务需求的元素的满足程度。基于这种分析方式，最后提出报表设计。

方法和经验是基于我们的项目的实际工作，在这里选取两个例子跟大家进行交流。首先它是我们实际工作中最重要的一部分，其次这两个例子很有代表性。首先是损益加工，它难是难在整个需求的整合和数据整合的过程当中如何去分析它。

第二个例子是交易性外汇敞口。提到敞口大家觉得这个事情非常简单，但是事实上面临的一个特定应用，面对一个特定需求的时候，会发现原本设想出来一个很间的加工数据的时候其实还是很复杂的。先看损益加工首先对损益进行整理，很多部门都关心损益，包括前台、一部分中台和一部分后台。损益就是赚钱了还是赔钱了现在赚了多少钱或者亏了多少钱？有的人说已实现损益或未实现损益，其实这是损益的一部分，还有人说我要看市场预期，这些提法中一般什么人会提这样损益需求呢？是前台。对于中台和后台他不讲损益了，他讲的是收入，我看利润，我看FTP，其实都是损益的一部分。我们在需求收集过程中会发现不同的人对待损益整个业务视角是很不一样的。

再看看我的纬度，换一个角度来说怎么提损益。有些人说我要年损益，时间纬度上不同的业务部门，不同的人看到损益是不一样的。从业务单元上或者数据力度上也不一样。交易员要看这笔交易到底是赚了还是亏了？有些人会看一个帐户上损益的情况。还有Desk为和一个业务模块的。这些业务需求是非常宏观的。所以数据力度上不同的客户想要去关心的视角也不一样。

当客户给我们提出损益类需求的时候是非常不一样的，不能说五花八门也差不多是千姿百态了。在一个非常冗杂的损益需求中要提出加工目标，提损益的时候一定要确定我们在谈什么。不同的业务用不同的名词跟你谈损益，你一定想想看他们两个业务部门描述的是不是一件事？比如谈某一个具体需求的时候，我们谈的业务含义是不是一致的？当你谈的业务含义是一支的，作为数据加工人员，我是提供数据的人员，那么就应该跟客户保证，当你要一个数的时候，我从一个地方给你加工出来，加工时候的数据来源应该是一致的。也就是说当我给你们两个不同德部门加工同一个东西，从一个地方来的时候，我的加工逻辑是一致的。如果我满足上述这三个目标的时候，其实就是整合我的业务需求。我提供一份损益，我确保它们是一致的。

我们刚才看到很多业务部门对损益的提法，我们整合再整合，分析再分析，最后结论是一套损益是满足不了他们的。那么我们怎么办？我们提两套损益。一套损益叫交易损失，一套损益叫会计损益。这两种损益基本能覆盖损益需求90%以上。剩下10%就单独加工。这就是整个损益求整合和加工的逻辑。

从需求覆盖来看，谈交易损益的时候，普遍上是符合覆盖我的前台相关的需求。前台我们谈的交易层面已实现和未实现损益，这部分需求可以满足他们。从数据源来讲，可以用资金业务系统交易表实现，最后加工力度首先是交易层面，然后在交易层面实现按各种不同德纬度进行汇总加工，不同力度下的损益就有了。最后是计算逻辑。交易损益这块逻辑上还是有点复杂，后面会慢慢介绍。交易损失有三部分构成：CASH-MARKET和PVEFFECT。会计损益很简单，就是跟总章保持一致的损益，中台会看它。加工逻辑也非常简单，看的就是会计流水和会计余额表。数据源会看资金业务会计流水表、会计系统会计余额表，也可以看总帐会计余额表。粒度方面，因为会计损益都是算好的，它天然的支持汇总，就是会计流水。会计损益这块也由两部分组成，一部分是当日流水统计出来的另一部分是会计调整项，把会计调整项加一起就原则了会计损益计算。

交易损益构成这方面，我们认为损益是两方面构成的。一方面是Market Value就是今天的市值，看当日市场报价，也可以对未来现金流折折算Market Value。

当你发现它是由几部分构成的时候还不能看到损益的全貌为什么？其实一个月以前的1块钱和今天的1块钱和未来的1块钱价值不一样。过去的1块钱价值放大，未来1块钱价值是放小的，我们考虑从过去到现在它的主现率都是不一样的，这是业务不同曲线不同而形成的。

交易损失就是先去把损益组成部分加起来，然后再看Finacing Cost+PV Effect=CP&L。

典型业务示例：比如说我有一笔黄金交易，它的整个损益会体现在过去的现金流这一块。对于一个外汇远期的交易，这些都是未交割的，未交割的部分会把它的损益纳入到Market value这部分。期权这块，现在还未交割，会放到未来现金流这块。这就是整个交易损的流程。

讲到这儿可以回答一开始需求梳理的问题，如果一个前台用户温文化你总的损益是多少，你可以回答他，他如果问你整个损益这块的一部分，我的市值是什么，你也可以用这种方式回答他。

会计损益是覆盖中台的需求，按照加工力度不同分别使用不同的数据源。如果想看特定产品系列下交易汇总的损益，那么就用交易流水。如果我想看加以对手比较粗力度的交易，就看会计余额表。在总帐这块，税费的信息并没有在资金业务里面提供。在资金业务系统里面找不到那部分的损益数据，就用总帐会计余额表支撑。损益数据间关系，会计流水加会计调整项等于资金系统会计流水。损益相关数据表设计，会计损益事实表和M&M损益事实表。

交易性外汇敞口案例：先介绍一下什么叫外汇敞口及外汇长的计算。外汇敞口是某一个外币下有多少敞口，外汇敞口一定是包括不同的业务类型下的交易。在我算总敞口的时候也很简单，无非就是三种类型，就是所有的头寸加空投，加起来，这种方法偏保守。或者采取多投减空头，还有一种方法是各种币种多头和各币的空头加起来。这么简单的东西当你放到一个实际背景下的时候会发现它非常复杂。

第一个背景：我现在面临的不利全行的需求，而是一个部门级需求，是市场风险管理部的一个需求。首先敞口轴他认为一部分，又明确指出另一部分他是不认的，这时候考虑敞口的时候要考虑这部分的需求。

第二部分需求，面临一个国际性银行，当我看敞口的时候不看本币，看各种外币的分析头寸结果。各分行各PORTFOLIO存在不同的本位币种，如何全行的外汇敞口如何计量？首先把交割分两部分，已交割和未交割。已交割部分要看每日重估估值，未交割部分按帐户，按币种和核算方剔除估值损益。

统计范围包括外汇、黄金、期权。帐户范围是集团层面考虑，包括总行、分行和各业务模块。加工方案：第一步看一个Portfolio外恢头寸计算，然后看已交割交易和未交割头寸。第一步把头寸算出来，按照各外币头寸重估本币头寸。

未交割部分首先现金流汇总加工头寸，剔除估值损益，用会计余额表损益类的故值核算法剔除估值损益。最后算除了结果已经考虑了损益的影响。这样已交割和未交割的部分，在PORTFOLIO情况下两部分都算完了，然后每个PORTFOLIO把这两部分加起来，做完这件事情之后，把它合计到集团层面。在这个时候，我现在是不看本货币的，是把所有币种头寸加起来。最后一步整个集团下开始认谁是本币，然后看多头头，USD。