2019-02-05：金融风控系统设计 - 外汇管理风控系统

无际致力于金融科技对银行、融担、互联网金融行业的基于供应链金融为核心的互联网化金融风控技术的输出。涵盖了互联网信贷核心的系统建设，基于Spark[Spark ML, Spark Streaming(Flink 替换中)，Spark Graphx]技术体系的信贷风控系统建设，以及长期为合作伙伴提供有效的低风险资产的流量业务。在经历了从银行到互联网金融公司到科技输出行金融科技公司的历程后，笔者希望能够将对行业及系统设计的理解做以分享。

本文共分为三部分（外资银行的外汇交易系统风险建设，互联网金融个人风控系统建设，供应链金融中小企业风控系统建设）

外资银行的风险系统建设

该部分更多介绍一下外汇交易系统风险控制的业务层面，技术上的确无创新之处，加上大量使用三方厂商的系统，在此感谢IBM MQ、Webmethod跟Oracle为该行提供大量的便利，在这家银行里，我们看不到Tomcat, Jetty, 看不到Spring Cloud，Dubbo，ZooKeeper，没有人理会微服务，大家连Yarn跟Hadoop啥关系都不知道。从技术角度到也单纯，能买的就不做。特别是竟然拿着ITIL去指导DevOps，搞个Jenkins就叫做CI， CD了（我都没见到过一个正经能跑的自动化Test Case），系统跑批几乎都是各种存储过程（不得不说，银行的确交易信息多流水大，加上以前对数据平台的构建不完善，国内银行很多也是如此，这些批处理无非就是业务型的处理统计、补账、代收付、息费计算、清结算等等的工作，围绕着银行的核心业务：存贷款、资金资产管理、理财及卡业务、中间业务来完成不论日终还是日间），这里的JVM调优靠的是买硬件（似乎印证了笔者17年前工作的一家公司的老总说过，别看咱软件做的不行，咱有钱，硬件补...賊豪）另外，最不习惯的就是在用SVN，不知道Git为何物，再小的小工具，也不会去尝试JHipster。笔者曾做过一个基于Nodejs的小工具，被别的组的人嘲笑半天，说js还能做生产环境的工具.....但是做Quants的人在用Haskell包个计算引擎，也做了一些DSL的实践，有机会把我了解到的再跟大家分享。在这里的三年半时间，让我学会了扯皮，更加体会到不做不错的道理。

2012年底有机会进入一家非常有名的外资银行从事系统建设工作，当时主要的工作是完成Murex2000到Murex3.1的升级项目，该项目很大，大到项目的需求及前期讨论花了1年多的时间，最终产物除了各级海外高层领导的审批之外，建立了TOM文档。（TOM: Target Of Model）也就是这个项目最终要达成的目的，对现有业务的影响，对现有系统的改造。说实话，这个项目也让我见识了为啥外资行的系统如此庞大，如此复杂，当然除了必须符合KYC，GAAC，Anti-Laundry 及银行的监管特性外，以互联网化视角看到的很多系统都冗余的不行，加上极大的人员浪费（一个项目2Program Manager，4-5个Project Manager，一大堆BA，当然还有一帮没啥用的Technical BA - 没人知道为啥弄这么个职位，他们的确不是架构师，最多懂一些系统的配置和流程的改动及垂直领域业务；真正干活的几本都是国人；的确不懂为啥，动不动就弄一大帮人跑到新加坡出差，上线都跑到伦敦去上 - 这个倒是有点道理，毕竟很多Trader在英国）。整个系统建设初步估算4-5年，当然包含了系统迁移，数据迁移，各种UAT， UVT， Rollout等。回到项目本身，Murex可以说是外汇交易管理系统Vendor中的绝对老大，公司名气大，系统大，订单金额大，Consultant的架子大。做过资金、外汇交易管理的人都知道Summit/Murex/Calypso 三家公司，说实话，如果从技术角度选个合适的中台，我会选Calypso（可能因为对Java框架情有独钟）；如果选大而全的，不论从支持的产品角度（能想到的Option的，Vanilla的，衍生品，押品，Fx的各种），还是从功能角度：能MSL（Murex Script Language），各种Pre-Trade，Post-Trade的Setup，定价，Curve & PnL，又能出策略，算各种VaR，又能录交易看Cash， PV， NPV还能跟后台操作不管Paper Confirmation， Electronic Confirmation（Swift）还是各种结算，审计， 财务，对账等等我只会选Murex，虽然贵。

由于当时更多的接触的是基于外汇系统的风险系统建设工作，简单说说外汇交易系统的风险管理，笔者接触过的银行有一点是一样的，就都是风险厌恶型实体，基本上对风险容忍度都不高。从风险的角度，银行无非关注：

a). Liquidity Risk【可能因为笔者参与很多ALM的项目建设，对银行的表跟流动性关注颇多，才把流动性风险放在首位】就这么一句话，靠控制存量，调节流量，尽量保持负债的稳定性和资产的高流动性来应对Liquidity Risk。笔者曾经在某Top 10互金P2P公司任职技术管理，顺便提一句，P2P在完全取消资金池及错配后，流动性成为是否能活下去的关键，当然如果你在资本市场上有极强的融资能力另议，但融资如果融来的是运营资金，那就只能再找通道洗成兑付资金喽。

关于错配所谓的借端放长，因为你的负债大量的都是短期的定期存款或者活期存款，但你的资产，很多是来自于中长期的贷款，的债券投资等等，这些都是表内业务，而且还有大量的表外业务，比如说担保、承诺、银行承兑汇票、理财产品，这都会对流动性产生影响。外汇交易也是一样，根源是到底有没有钱。

b). Credit Risk：交易对手风险或履约风险，指交易对方不履行到期债务的风险。由于结算方式的不同，场内衍生交易和场外衍生交易各自所涉的信用风险也有所不同。

c). Operation Risk：操作型风险，这个最好理解，为啥Murex提供了OSP

d). Market Risk：没有比这个链接讲的更好的了 市场风险 ，汇率风险，利率风险，大宗商品等等都涵盖了。说到Market Risk，我们说一下VaR （Value At Risk）我真不知道咋翻译，这里面在系统设计时的确考虑大量运算，Historical 方法，蒙特卡洛法等等，都是需要对PnL， PPL等进行大量的计算才能完成的，说实话，Map-Reduce的思路可以做些改进，我也尝试过把10几年的数据Load到MongoDB里，然后用它自带的Map-Reduce函数做了实验，由于毕竟单线程的JS函数，效率提升很小。

而针对外汇的交易风险，来源几本就三方面：

1）经济主体自身持有外汇头寸，发生不同货币间进行兑换或折算产生的

2）汇率的不确定因素

3）并因汇率变动而给经济主体带来的经济损失的可能性【仔细想想，就是因为货币和时间两个维度的因素导致了风险的存在】而变数在于，各个国家汇率制度不同（金本位或固定汇率下，波动小；浮动汇率下加上波动率上下限不一，容易大起大落）、货币政策（基本起决定性作用，汇率的波动在购买力和利率平价理论下，汇率由两国的通胀率和利率决定的）、会计制度（科目划分、会计方法选择、会计核算差异，什么货币/非货币法什么流动/非流动法，还有时间度量法啥的）说到会计制度突然想起来下图，呵呵一下。当然还有国际收支，国家政局状况等。

考虑的风险因素基本上的就这些，作为整体的外汇交易系统的设计，主要的就是算，比如上面提到的VaR的计算，算成一个如下图的结果

整体系统的架构设计，不难在功能，银行里面懂业务的专家有的是，特别是这种外资银行，设计系统的时候最复杂的外部的业务对接，这也是为什么文章开端也提到很多互联网化的技术并没有用，除了风险的角度外，的确系统的外部对接是个问题，当然，为了更好的让系统能和外部业务系统对接，当时也有一个专门做协议转化的项目，双方大量使用XML定义好自己的格式用于交换数据，特别是跟MxML的转换工作。这也是开篇感谢IBM的原因。最后，给个整体的功能图，方便大家理解外汇交易系统到底啥样，

从业务功能上讲，无非前中后台，之所以说Murex是外汇交易管理平台，也是因为他们不做直接的交易系统，一般来说交易系统都是外采或自己开发的，毕竟没这么复杂。特别是如果外汇实盘交易，针对的产品大都是Fx Spot， Fx Forward， Fx Swap（不算衍生品的话），虚盘交易无非加入保证金的管理。实际上的

前台管理功能无非：交易录入、实时行情、头寸、损益、交易前分析、策略试算、情景分析、模拟、客户管理、外部远程交易管理等；

中台：信用管理，市场限额（敞口、止损位控制、VaR、期限限额、合规管控）、各种计算（VaR，资本充足状况、压力测试、Back Testing）；

后台：工作流配置，各种日常任务管控，报表，报文管理，抵押品，会计管理（交易头寸估值、外汇头寸的计算、报表、必须支持多实体，多币种，全资产多套会计体系的计算）。

系统所有功能都来自对业务的支持，十几年前我的导师，Des Greer 就跟我说过，银行的系统多，各司其职，看上去复杂，复杂在Data Model和系统所属的业务线上，本身并不复杂，设计工业化软件还是高内聚低耦合以最小的成本完成最基础的功能，不要按照自己的想法增加功能。当然也许说的不全对，但有一定道理。大年初一，啰哩啰嗦写了这么多，读的人希望不太晦涩。下面的两个部分，争取少些业务内容，多写一些跟技术相关的东东，毕竟我是个程序员。

祝大家新春快乐 - Leon 2019-2-5