谈谈金融领域的风险分析方向

Jerome 20061207

前一阵大家在谈"金融电信大比拼"，由于对电信行业不熟，一直插不进去话。今天单开一个主题，谈谈金融领域的一些情况。

作为一个工程技术人员，从业务谈起可能会被行家笑话，所以只能从自己做过的项目谈起。这段时间一直在做的项目是银行领域的信用风险分析项目。银行风险应该是银行一个至关重要的主题，要想说明清楚它的目的，我觉得有必要从一个例子开始说起。

以一个卖雪糕的为例，假设他2元钱买进一块雪糕，5元钱卖出，毛利润3元，扣除各种其他成本等内容，净利润1元，投资回报率50％。而对一个银行来说，他2万元买进一笔100万元存款（2％存款利率），5万元卖出（5％贷款利率），扣除各种其他成本等内容，净利润1万元，投资回报率50％。当然，例子举的漏洞百出，只是为了形象的比较一下，其实银行和一个卖雪糕的差别并不大，也做的是倒买倒卖的生意，只是他倒买倒卖的是钱而已。

但是我们仔细看这个例子，可以发现其实银行和卖雪糕的还是有较大的差别。假设卖雪糕的碰到了一个无赖，拿了雪糕不给钱，则卖雪糕的会亏损2元雪糕成本和2元其他成本等内容，投资损失率200％。而银行如果碰到一个无赖，贷款后违约，则银行亏损的是2万元的利息和2万元各种其他成本等内容以及100万的存款，投资损失率5200％。这5200％和200%的差别就是银行和卖雪糕之间本质的差别，而这5200％就是银行面临的巨大风险，也就是我们系统需要解决的问题。

银行贷款给企业，银行面临着企业违约的巨大风险。而大家有没有想过，银行的钱从那里来，人民将人民币存入银行。在银行时刻担心企业违约的同时，人民有没有换一个角度想一想，如果一个银行的贷款客户违约的多的话会发生什么事情。银行收不回贷款，结果就是银行违约。至于银行违约会出现什么样的结果，这里不去多说，反正银行自己和国家都不会让银行违约。

那么银行如何来保证自己不违约（不破产）呢，方法很简单，就是预留出一部分钱来，等某些损失发生时，拿这部分钱去抵御损失。这部分钱比损失大，就没有危险，如果比损失小，银行就会违约。大家知道，银行的钱是要贷款出去才能盈利，放在家里是要付利息的。找出将来可能出现的损失是件相当复杂的事情，所以预留出多少钱来也是一件相当复杂的事情。当然，有很多金融学家在做这件事，他们建立了很多模型和方法去预测将来可能出现的各种损失。

其中最常见的方法就是预测排除极端情况下，银行所能遇到的最大损失是多少，这个最大损失值金融领域的人称之为"哇"（Var，在险价值）。在信用风险领域，这个"哇"分为两部分。一部分是预期损失，也就是说本着"人在江湖漂，谁能不挨刀"的古训，银行在发放贷款时就深深的知道有些肉包子就是用来打狗的。他们在发放贷款时，对自己的贷款客户要有一些预先的估计，如客户可能会有多大的几率发生违约（违约概率，PD），在将来客户发生违约时银行有多少钱在客户那里（风险敞口，EAD），如果客户违约，通过客户的担保和抵押变现后，银行会损失多大的比率（违约损失率，LGD）。这三个值的乘积就是银行的预期损失，银行会通过拨备留出这笔钱来预防损失。"哇"的另一部分是非预期损失，这一部分，金融学家们搞出了更复杂的模型来预测。

当然，国家也不会让银行违约，所以设置了银监会，银监会监视银行的各种指标，从监管的角度对银行的监管资本提出要求，而监管资本的计算同样是一堆复杂的模型。这些模型，金融领域的人称之为"巴塞尔资本协议"。而上面这些所有的数值如何来得到，则是我们系统要实现的主要内容。

罗嗦了这么多，我很知道自己没有精深的业务，也没有优美的文笔，所以上面这段文字一定表达得非常混乱，其实大家不必去看上面写的内容，因为下面才是我要表达的真正内容（希望大家不要拍我，呵呵）。

金融领域的风险分析方向，包括信用风险、市场风险、操作风险等是银行等金融机构的核心。虽然有大量的金融学家霸占着这个方向，但是如果要在IT系统中实现的话，我们还是大有可为的机会的。这些内容不是使用OLAP工具拖拽几下就能解决问题的，也不是用一些数据挖掘工具中提供的数据算法跑一跑就能出结果的，它需要大量的金融知识、统计学知识以及数据仓库和数据挖掘知识。从广义上来说，风险分析也算是商业智能的一部分，是建立在数据仓库之上的分析应用。

Qing 20061207

Jerome这篇文章的内容最后一段得出的一个结论——"但是如果要在IT系统中实现的话，我们还是大有可为的机会的"。

这倒让我从相反的角度想到一个问题，和jerome的乐观态度相比可能是悲观的。

既然在这个风险分析方向，有那么多金融学家在研究这个问题，那么还有BI什么事？最多也就是喝喝剩下的残羹吧。基于研究出来的风险预测模型，设计出来几个KPI，然后在仪表盘上展现，这恐怕就是BI能干的了吧。至于自己用挖掘算法来预测，谁信呢。金融学家研究这些模型用的方法恐怕也是那些方法，只是他们不叫挖掘而已罢了。

还有证券行业，以前曾考虑过相似的问题。挖掘方法不是可以预测吗，你去预测股市走势啊。这是痴人说梦，你看看有多少技术指标和研究方法，那里有挖掘方法的立足之地呢。

这些领域都是利益相关太大的行业。金融不说，都是钱的事情，不敢怠慢，证券也是，涉及到个人利益更猛，所以有那么多"专家"在电视上侃侃而谈。这些人员可以说都是"业务专家"，具体采用什么分析方法，是用基本统计，还是挖掘，还是易经。。。那些都是次要的，是工具而已。重要的是能够解决问题，分析出来的结论能够让人信服。数据分析也仅仅是一种方法而已。

当BI人拔剑四顾两茫然，是不是得想想自己到底是个铸剑的？还是个剑客？

Jerome 20061207

很赞成Qing的分析，却不同意分析的结果。

我觉得我们从同样的事情下得出不同的甚至相反的结果，可能是出于对自己定位的不同。

BI人员到底做什么，在社会分工越来越细的大环境下，那些事情是BI人员要做的？

管理信息系统出来之前，难道企业就不对各种单据进行管理了吗？企业老板不需要看各种报表吗？我们开发出各种企业管理信息系统只是将他们的管理方式改变了一下。或许能使管理更加有效，更加方便，但归根结底我们做的只是管理工具。企业还是要靠管理人员来管理。

对于BI，我觉得差别并不是很大，企业管理人员要对数据进行分析，没有数据仓库，他们手工统计数据也要进行分析。而BI人员所作的一切就是为这些分析人员建立一个完善的分析平台，提供优秀的分析工具，为企业的分析人员分析企业提供支持。企业还是要靠分析人员来分析。

那具体来说，BI人员做什么呢，我觉得不管是操作型系统的开发人员还是BI开发人员，我们开发的都是应用软件，我们没有必要去研究模型和算法。以金融行业为例，既然有金融工程这样一个学科存在，一定会有无数的硕士生、博士生、教授和金融学家在努力的去研究各种金融模型。BI人员就算有再高的水平也不会比这些人在金融工程上强，毕竟人家是专业做这个的，大家的专业分工是不同的。

金融学家会去研究新的金融模型，检验新的金融模型的可用性；数学家和统计学家会去研究新的算法，或者改进旧的算法；而BI人员要做的是理解那些别人已经研究好的模型和算法，并能在IT系统中实现它们，必要时可以在金融工程师和统计工程师的帮助下来理解。

我们不需要去考虑经过怎样的改进可以使主成分分析更优秀，我们只要知道主成分分析是用来降维的，也可以用它的载荷阵来定权重，了解一下如何输入数据，怎样得到输出结果就可以了，这样我们就可以用程序来实现它。至于为什么这么做可以降维，可以定权重，如何来改进它，我们可以不用去理解。

我觉得我们和那些侃侃而谈的"专家"并不是对立的关系，而应该是合作的关系。

真正的分析是离不开业务的，挖掘方法能否预测股市走势，这不是我们要做的事情，这是业务人员、分析人员要做的事情。有"专家"要预测股市走势，我们可以为他们建立数据分析平台，提供友善的挖掘算法界面。我们需要对他们的业务知识进行理解，目的是能更好的为他们提供支持，而不是代替他们来进行分析。

回到金融领域的风险分析方向，金融家和银行家一直在研究各种分析模型和方法，而我们建立数据仓库，开发分析软件只是他们研究方法的实现。以目前来说，国内银行将风险分析做成软件的还很少，几乎没有，都是专人收集数据来手工分析。用计算机来取代手工工作正是我们IT行业要做的事情。

信用风险领域计算"哇"是相当复杂的，需要每一笔贷款、发放、回收数据及其相应的担保、抵押等信息，涉及的数据量非常大，我们软件的目的就是能实现这些复杂的计算过程，给他们分析提供方便。

要实现这些计算过程，是需要对他们的模型进行理解的，而这些理解也就成为我们的行业知识，当他们研究出新的模型，我们就会有新的行业知识。

我倒是希望金融家能不时的研究出新的分析模型来计量风险，我希望他们不光研究"巴塞尔协议"，还能研究"巴黎协议"、"伦敦协议"，这样我们就一直有事情来做。

我之所以得出结论，风险分析方向我们大有可为，一是因为这个方向计算机取代手工的工作才刚刚开始；二是因为这个方向和计算机相差较大，学金融的可能不大会转向计算机，（学电信的到是比较容易转向计算机），这就要求我们IT人员要进入金融领域，对我们来说是个挑战，积累的行业知识可能会更加有用，这样的人可能相对来说会少一些。

hunter 20061208

挖掘方法在股市预测确实有立足之地的，看一篇台湾写的论文，预测LCD产业链，上游涨价之后下游产业股票的反应。整体走势不行，局部赢利点一定能找到（呵呵，这也是我学挖掘的动力：）

goldenfish3 20061208

以前遇到过这个问题。风险分析是个大的课题，基于DW来做有好处。金融模型开发的任务是专业研究者干的事情，这事毫无疑义，但在系统实现时候的分工界面就要有一些考虑。一个蒙特卡罗模拟就需要用专门公式计算很久（相对业务系统的事务而言），对每一笔帐户都可能计算上千次，占用大量的计算资源。这个计算用BI工具计算肯定不行，交给ETL做也办不到，因为可能涉及指数方程求解，用SQL来做顶多是多项式逼近，不能算的很精确。架构上只能这样设计：
源系统->DW->风险系统数据接口->风险分析系统->DW->多维分析集市
与通常的源—>DW->多维分析集市相比，数据到风险分析系统转了一圈，结果回来。风险分析系统运用那些计算模型，算出结果。这是专业系统，且数据依赖于DW整合后的数据（因为模型对输入数据的质量要求很高，如字段不空、取值合理等），而且模型很挑剔，对输入数据的格式也挑三拣四，需要形成专门的风险系统数据接口。这样的数据送给风险系统，计算那些“哇”。哇的结果回流仓库，再送给多维分析集市，去查看这些“哇”的结果。一种考虑是从风险系统能否直接进多维分析集市，这主要看实际情况。

innovate511 20061209

我也没接触过金融行业，不过挺感兴趣的，因为外资银行开放后，在国内金融行业必定会代替电信成为DW/BI第一大市场，而且系统更复杂也更有挑战性。

楼上说的情况我体会过，并不是说所有的DW都是直接流向DM，有的复杂运算需要回炉到DW，再流向数据集市，没想到会在金融领域得到广泛的应用。

就像传说中的实时BI，其实只是针对特殊的BI需求的特殊手段而已。

土包子 20061210

个人感觉以上问题属于咨询顾问和开发实施的问题

对于数据仓库KPI的模型肯定是由咨询顾问完成的事情，需要扎实的行业背景，这个已经超出了开发人员的范围；但是开发人员也应当参与一下相关的需求分析和调研活动，加深对业务的理解。
对于数据仓库的实施是由开发人员完成的，开发人员通过和咨询顾问以及用户的交流以及数据字典的阅读等等，将KPI转换成相应的可处理的数据存储范畴，并加以具体化的工作。