谈谈流动性
从前有一个大老板,聘请了一个首席经济学家,然后正在发生一些大家吃瓜的事情....然后这个首席还在写某地房价为啥涨不起来，洋洋洒洒近万字，其实就是流动性管理没学好.
因此，今天要讲的话题就是流动性，您可以很有钱，但是都是不动产 , 而不动产最大的特征就是， 你想动的时候，它一动不动，然后你就惨了...流动性的管理无处不在，例如一不小心就可以让首富变成首负，甚至变成下周回国，而面临流动性紧张的问题， 几乎所有的大佬都选择了造车... 流动性管理通常是金融业风险管理中的一个非常重要的环节，接下来我会从金融机构流动性管理，再结合大家认知里都比较熟悉的股票投资和房地产投资的流动性管理做一些介绍，中间还会涵盖到高频交易中的一些流动性和弹性预测的话题，不过不会太深入，毕竟各个机构都要吃饭的... 最后会谈论到弹性计算及计算流动性的问题， 以及基于流动性管理视角的网络缓存设计和拥塞控制。
其实很多看似跨界的东西，本质上都是相通的，有些事情想不明白，找个生活中的场景类比一下，你会发现其中的荒唐。
流动性的定义
流动性风险是金融风险中非常难控制的一环，至今其实都没有什么很好的办法。流动性风险的体现最直接的就是bid-ask spread(也就是中文常说的买(bid)卖(ask)价差)，例如您去银行看外汇报价，会有一个买入价一个卖出价，中间的差额就是bid-ask spread.同样股票也有类似的差额，买一和卖一之间的差价。通常交易所还可以提供五档或者Level2更深的行情。
高频交易在玩什么?
其实很多高频交易所面临大量的道德风险指控时，都会有一个口头禅：我们在危机时刻提供了流动性，讲到bid-ask spread我们就顺便衍生讲一下这个话题，假设现在一个资产的买卖报价如下：
其中的买卖价差就是 价差很大对吧，也不利于成交吧，于是做市商通常会在这个时候去占据最优的买一和卖一，例如下图：
这样子就缩小了Spread，也就是高频交易商常说的提供流动性，而Spread的减小也降低了交易流东西风险敞口，接下来我们就沿着这个话题展开，来讲一下交易流动性风险，也就是很多高频交易玩家需要处理的问题。
交易流动性风险
通常对于一些大型机构要进行一些大体量交易时，都会面临到这个风险Liquidity Trading Risk，通常一个资产的交易指令下达后，需要以某个中间价成交，中间价的计算方法可以最简单买一、卖一求平均，当然也可根据成交量加权，例如TWAP、VWAP等等，除了价格以外，交易流动性风险还受另外两个因素影响，需要成交的量以及需要完成交易的时间。
潜在的来看，还有一个问题就是交易标的物的弹性(Resiliency)，其实流动性和弹性是伴生在一起，后面我们讲到云计算流动性和弹性的时候还会详细来探讨这个话题。弹性衡量的是交易带来的冲击后返回原样的能力，例如下图:
如果你需要交易的快，那么大的买单下下去，就会导致短暂的价格变动，如果量还不算太大， 可能会渐渐的恢复回来，这个恢复能力就是价格弹性的度量，而很多做期货的同学常说的滑点就是在描述这样的行为。因此有时候看到一个可以实现流动性套利机会的价格，也因为流动性的问题，只能完成一些小单子而不影响系统弹性，这也就是很多高频交易的算法容量问题。
而且从交易来看，当行情从交易所更新发出后，所有的投资者都会关注到这样的机会，然后通过一系列算法进行套利，因此委托成功率很大程度上依赖于低延迟的网络和更快速的交易策略。
那么矛和盾之间的博弈又开始了，真正的大机构(共同基金、ETF等进行调仓时)有可能这一条交易指令可以指定在今天一天内完成交易，交易员可以根据市场的已有流动性动态的拆分订单来降低对Order book的影响，从最早的iceberg交易指令，到后期的各种时间序列分析算法，再到现在根据RNN、LSTM这些神经网络模型来做订单拆分。而另一方围猎流动性的高频交易机构，也同样的会采用这一系列的方法通过计算和预测背后的交易订单.
当然在这里面就涉及到一些违法行为了，例如各类欺诈策略，例如高频的下单撤单，人为的制造流动性紧张.例如Quote Stuffing来塞单，相当于对交易所撮合服务器进行DDoS攻击，或者Quote Spoofing引诱买方涨价，同时引诱卖方降价，这些操作同样的也在房地产交易中出现了，因此国家开始管控挂牌价也是有相应的逻辑的。而针对这个场景，监管层的意见基本上是统一的:
一切不以成交为目的的订单都可以属于欺诈交易的范畴
如果想深入了解这个问题和其中的一些算法，可以去看Kaggle上Optiver最近正在举办的一个波动率预测的竞赛
其中有个作者做了一些详细的解释 ,可以自己点进去看看。
从代码来看，通常针对这样的场景，RNN和LSTM会有一些，毕竟传统的GARCH Model一类的TSA已经完全跟不上了，但是也需要考虑到模型的稳定性和可复现性，因此金融机构更多的还是选择GBDT一类的算法，例如xgboost或者lightGBM一类的模型，然后再将其推理过程实现到GPU或者FPGA上，所以黄教主的大会上你会经常性的看到Citadel的一些分享。
当然我为啥不做这一块呢， 一方面因为国内主要证券交易所的网络设计我都参与过，虽然不算市场禁入的那种，但是作为交易所的设备提供商，也要管好自己，某司的道德规范里最重要的一条就是要保护客户的信息，因此做高频就有明显的内幕交易的嫌疑。所以我更多的是在一个中低频市场上利用风险度量和中长期流动性度量的方法做。今年五月也发过一文，慢牛来了，当然某算法也经历了检验，但是证券从业资格和基金从业资格都讲过不能公开披露业绩，就不多说了。
顺便补充一下，在这一块，通常我们会认为由流动性带来的损失会将其计入为成本，所以很多期货算法上都有问交易成本的估计和滑点估计，而大型金融机构通常会根据标的物的Spread缺口和历史波动率来构建一个置信区间：
并构建相应的加权到VaR中，并成为Liquidity-Adjusted VaR，大概计算如下
当然还有根据清仓时间定义的流动性在险价值,T为清仓时间
融资流动性风险
除了交易流动性风险以外，我们再来看融资流动性风险，通常一个金融机构的融资方式会很多:
持有现金和国债 在交易簿中很容易出售获取流动性的头寸 同业拆借 对于一些大的机构还可以利用高息揽储的方式 资产证券化的方法获得融资 直接从央行借
然后巴塞尔协议III中针对08年次贷危机导致的流动性风险，还规定一些流动性指标，例如LCR
>100%
或者NSFR(Net Stable Fuding Ratio)
> 100%
这这个计算的过程中，针对不同的资产流动性还会乘以一个系数，例如在资产负债表中， 负债表中针对ASF(Available Stable Funding),一级资本和二级资本乘数为100%，而其它一些例如长期定存都会打一些折扣。而针对需求端(Required stable fuding)中， 也需要考虑，资产表中的现金对流动性的需求自然系数为0，而黄金这些看似流动性很好的资产，RSF因子也只有50%，因为银行量大到一定程度要来找到接盘侠还是很困难的。而对于常见的居民住房抵押贷款，该因子也只有65%。
但是某首席所在的房企就没那么多花招了，只会L底、U底上杠杆，自然就出事情了。地产商融资渠道窄了很多，房住不炒是哪一年提出的？万达哪一年开始转型的？万科哪一年喊活下去的，碧桂园为了资金周转率加快出图建设出售整个流程是为了啥？所以有些地产商一出事就到处说国家要搞你？你以为你是在搞艺术，想让国家深入艺术么？
为了便于大家理解融资流动性，我们再来看一个话题，就是居民买房的时候，通常首套二套首付和相应的利率都是不同的， 再加上大城市的一些限购策略构成了一个流动性约束。在这个流动性约束过程中的金融创新就出现了， 当然这是一句黑话， 全称是：“一切金融创新的出发点都是建立在绕监管和上杠杆的基础上的"，所以有某库某理这样的组织出现，然后利用信用卡额度做Roll over融资的，简而言之就是借短投长，以丧失流动性获得风险溢价，具体的手法就不多说了...假结婚假离婚获取流动性，商贷小微贷二押获取流动性等， 这些东西我接下来在流动性管理那一节再来详细说。
接下来要说的一个话题就是流动性黑洞，其实很多炒房的人口头禅都有一句：“哪有卖不出去的资产，只有卖不出去的价格”，只可惜有种东西叫不动产变不动惨
流动性黑洞
针对银行业的流动性黑洞就是：挤兑。当然还有一些流动性黑洞和价格相关，例如当年的保时捷收购案和今年年初发生的Robinhood上的散户和做空基金的拉锯战等。因此任何时候都不要想到资产打个折就能卖出去，因为有一些掠夺性交易会使得你完全丧失流动性。例如某地产公司想低价卖房，然后等你卖了一栋，就开始限制你的预售证，或者通过限贷等手段等。因此获取流动性的一个最重要的方法就是再搞一个国家提倡的重资产行业来负债，显而易见的就是造车。这个是一个非常好讲故事又能获得大量融资流动性的产业，相对于以前地产商常玩的各种非标，这个来钱多快啊..
在主体遇到流动性风险后， 流动性很快被抽干，一方面是债券价格快速下跌，而同时很多负债需要触发一些保证金条款， 然后为了满足保证金缴纳又只能卖资产然后进入一个螺旋下降的过程。
另一方面是以前能够roll-over的借短资金突然也因为主体信用风险而断裂了，例如以前某库玩的多个信用卡之间roll，最后银行为了解决这样的信用风险很容易的做一些联邦学习的模型，大家一起等你这个月还完钱就给你降额了...
流动性管理
流动性管理上，大型金融机构通常会有一个大屏显示早期预警信号(EWI,Early Warning Indicator),例如债务的集中度风险、操作风险事件、核心资本充足率等，而大型金融机构流动性管理上也有很多流程。简而言之就是在流动性的提供方和流动性的消费端做好负载均衡和期限匹配。
对于投资端，通常我们有丰富的投资工具可以选择， 针对金融机构而言，主要分为一些货币市场工具和一些资本市场工具，货币市场工具主要就是一些国债、大额存单、商业票据、承兑汇票、以及一些市政债券等，而资本市场工具就相对较多了， 例如某宝发行的ABS、正在出事的某企业债等。从流动性的角度来看， 这些资产的可变现能力是不同的。
有可能大家认为这些不都针对金融机构么， 对自己关系没那么大。但是例如2020年出的疫情直接导致很多创业企业因为没有流动性管理意识而在业务意外中断两个月后就再也没有活过来，所以红杉等基金都会告诫投资者，你需要将公司的流动资金保持6个月的流动性，这些其实都是过来人的教训。
流动性管理里最重要的基座就是资本充足率，这也是巴塞尔协议一开始就提到的第一支柱，巴塞尔协议III除了对充足率有要求以外，还对资产质量有了更高的要求，例如详细规定了一级核心资本充足率高于4.5%，加上其它一级资本充足率要求高于6%, 包含一级二级资本的充足率高于8%，然后还可以适当的加了一些buffer，例如CCB(Capital Conservation Buffer)，即在一级核心资本上增加2.5%的buffer，要求一级核心资本充足率到4.5%+2.5%， 同时监管机构在经济较好时还会增加一些反周期调节的buffer(CCyB,Counter cyclical Buffer)，这个是监管层动态调节的，系数在0~2.5%并要一级核心资本来覆盖，而针对一些系统性重要银行(G-SIBS, Global Systemically important banks)还需要再增加额外的1%~3.5%的资本金需求。
然后在此基础上，对其资产的风险暴露也做了杠杆率的要求:
> 3%
在这里，还有一个首富说过老年人的当铺，在某动物上市之前说巴塞尔三的监管体系，其实另一个世界首富说的更加清楚: Banking Is Necessary-- Banks Are Not.银行业在多年多次的金融危机中几乎完全丢掉了自己的声誉，所以老年人的当铺理论自然很受大家欢迎。但是老年人为了维持金融系统稳定而付出的代价多么大，以及应对一些不确定的流动性风险需要储备的资金有多少，这些是首富还暂时不能理解的，监管这么做自然不是拍脑袋决定的，后面有大量的逻辑。因此阿里应该庆幸国家没有把你作为金融机构并将其划入G-SIBS让你满足资本充足率的要求已经是对你的爱了。
而地产商或者很多炒房的家庭并没有这样严格的杠杆率控制，特别是很多一般家庭可能就是靠国家首付和按揭审批来监管杠杆率，但是炒房团通过一些金融创新绕过了监管而已。这里给大家分享一些比较实用的流动性管理方法，自己理财也可以使用。
通常我们对于流动性可以从供给端和消费端来进行区分，首先来看消费端。日常生活中我们可以根据金额和时间的不确定性分为四个象限
| 时间确定 | 时间不确定 | |
|---|---|---|
| 金额确定 | 车贷房贷等，日常餐饮等 | 亲朋好友聚会 婚丧开销等 |
| 金额不确定 | 信用卡还款，亲人的生日礼物等 | 生病等天灾人祸 |
那么针对不确定的事件， 从概率上我们可以估计出一个期望值出来，所以很多金融机构流动性管理上都有一个TSECF的指标，全称就是Term structure of expected cash flows，同时还会对它进行一个累积构成TSECCF。其实很多家庭里管钱的那位都会做类似的计算，特别是看到过一些日本的妹子每个月领完薪水就会按照开销来构建多个备用金账户，同样在国内针对金融机构也有法定准备金制度来抵御流动性风险。
而资金的供给端我们按照如下方式进行区分：
| 短期融资 | 长期融资 | |
|---|---|---|
| 压力情况下可以获得 | ||
| 压力情况下无法获得 |
那么在流动性管理的过程中，一般家庭应该如何做呢？有一种极端情况就是交Liquidity-Shy，就是特别杞人忧天的担忧会出一些意外，然后留着大量的现金放活期。针对现在很多大型集团司库其实缺乏管理的，以前和一个某全球企业财务女神也聊到这个问题，其实全球的资金划拨和各国的税制及资本管制都可以很好的统筹一下。
在这个过程中，我们手头过剩的流动性自然有了投资端的需求，通常的做法分为三种:
期限转换(Maturity Transformation)
最简单的解释就是借短投长，然后利用长期的收益率高于短期利率获得收益，例如很多炒房团用的信用卡Rollover就是这样，但是最终会面临Rollover-risk和Cliff-risk，即突发的资金链断裂
流动性转换(Liquidity Transformation)
把流动性好的资产换成流动性差的资产
信用转换(Credit Transformation)
例如将国债换成公司债，将持有的大盘蓝筹股换成小盘股，换取更高的波动率溢价， 而波动率溢价的来源也包含了流动性。
但是最终你的这些投资需要反过来算一个期限结构，Term Structure of Liquidity Generation Capacity(TSLGC),而这些能力要保证你在TSECCF为负时，你有足够的能力去产生流动性。
其实这些都是我们很多一般家庭理财上很不足的地方，房产上了太大的杠杆使得自己无法动弹，而社会保障有限、双方父母医保压力、小孩的读书压力，这一系列问题都产生流动性紧张，所以你会看到为什么最近几年医改、教育改革、房住不炒等根本原因就是需要慢慢的恢复普通家庭的可支配收入比率，可支配的定义其实本质上就是流动性了。
当然针对企业而言，企业的司库部门还需要做好更多的应急流动性预案等...
流动性治理
从家庭的角度来看，你只能听老婆大人的....还想搞什么多条防线？自己不想想家庭地位第三还是第四都取决于养不养狗的还想管流动性？
但是从公司治理的角度来看，业务条线需要管，高级管理层也需要管，而且在金融机构的司库部门中还存在一种LTP的方法，即流动性转移定价的策略，而同时针对自己的负责情况和投资情况，还要考虑一下自己对利率变动的敞口有多大，自己对期限错配的敞口有多大，例如去年我也回答过LPR要不要转的问题。
前几天阿里CTO说自己是帮CEO扫清障碍和风险的， 本质上有对也有错。现代企业ICT技术的应用的确给传统的CEO带来了很大的风险，例如信息安全的风险，信息系统业务系统建设的风险。但是真的全要CTO去做也是不现实的，毕竟CTO最大的缺陷是在Finance上，所以现代企业制度上还是需要一个CRO来从第三方的角度来评估CTO和CFO，通常这样又懂技术又懂金融还懂风控的人几乎不存在(好像又在夸我自己了...真不要脸...)，不懂...就学嘛...
流动性的衍生：技术债务久期
其实一个CTO更应该解决的是其技术债务的久期， 例如一些公司，由于建设的过程可能某个业务条线会有三个到四个重合的团队去管一块业务，各个团队都想为了自己的利益利旧，而HR在管理上也害怕一个团队去跟其它团队抢活打架，于是在这种模式下就形成了技术债务。
软件债务的形成在开发阶段，开发成本和运维成本的长期摊销构成的。另一方面是软件收益。但是软件债务一直没有很好的呈现在公司财务的资产负债表上，因此科技类企业的风险控制在整个管理领域是严重缺失的，而科技类企业财务造假也非常容易就是因为我们还没有完善的软件债务分析模型。相比之下固定资产折旧有一定的摊销年限，过了以后就可以报废了。而软件还有很大程度上需要复用，在复用和重构之间如何取舍，下面提供一些方法。
前几天我在和某司一个资深工程师聊天的时候谈到一个问题， 例如最简单的统计，求方差均值偏度峰度这些，或者各种分位点。统计函数包肯定有现成的开源软件，流计算引擎也有Flink这样的现成的框架，为什么还要重新造轮子呢？其实这里就是一个债务分析流程。
资金流的入方向的收益分析通常各个企业不同，但是Marketing都会做一些标准的估值模型和预测模型，财务报表上的现金流收入预测其实都好弄。接下来要谈的软件开发成本的债务摊销才是关键。
研发阶段架构选择和债务估计
2018年开发某分布式流数据处理平台时，如果使用Flink在嵌入式平台需要对已有的硬件平台重构，加大内存加强CPU。同时Flink在那个时候不支持ARM使得大量的低端边缘路由器节点无法使用。AI模型推理的代码集成到Flink上需要大量的人月，公司投资成本不足以支撑这样的项目。对于这些，可以量化成每一笔开销的现金流，然后贴现到项目初期，贴现利率假设用固定利率就好。当然具体的人月工资开销和硬件开销涉及到公司的一些机密就不列举数据了。而对比如果是采用Go来根据cloud Dataflow算法写一个流计算系统，而且网络遥测数据并不需要Exactly Once语义，部分数据丢弃也可以容忍的情况下，开发一套系统基本上1个人月的时间，Tensorflow有现成的Go的API，而Scikit Learn或者xgboost这样的决策树模型弄到Go上构建推理算子也很简单。统计上那些算法都有C的Code可以抄作业，但是这些统计算子引入CGO可能cross compile会增加复杂度，同时远期增加半个人月的长期维护成本，那么通过债务模型贴现后发现调用c的lib还不如直接抄Code改写成pure Go，而且软件尺寸会小很多，因为我只需要均值/方差/分位点的统计，并不需要为了这么小一点功能引入一个很大的库。
软件维护阶段债务估计
新开始的时候选择架构比较容易，而在一个已经开发了长达数十年的平台上进行债务分析基本上是一笔糊涂帐了，同时你还要面临着开着飞机换引擎的代价。通常你面临的债务分为几个部分：1.软件开发者的知识债务：这是非常重要但是往往被忽视了的，很多人在一个公司工作了十多年，通常也算是某个领域的专家或者骨干了，但是很有可能他的知识体系结构和现代的软件开发框架已经脱节了，因此这样的专家在设计软件架构时会主观的选择复用已有的系统，或者在已有系统上小修小补构建。因为如果采用新的框架可能经验上与一些新人就没有差距了。而上层的经理决策层通常也盲目信任权威，因此Nokia当年那种“我们什么都没有做错，但是还是失败了”这样的事情出现的根本原因在此。通常针对这类问题，管理层和HRBP应该有一定的激励机制，类似于债券中的息票率来缩短债务久期，当然人员的流动也是减小这类债务的另一种处理方式。2. 软件的维护债务：这个比较好衡量，就是根据bug数以及bug平均解决时间根据一个平均人月的开销作为现金流贴现就好了。3.架构更替的风险债务：这个也是需要很好的计算的，当我们根据前两步确定债务现金流最大的模块后，特别是整体摊销到模块的现金流为负数的时候那么就需要考虑模块级的重构了，重构可能带来的潜在业务风险也是需要计算的，这样对于重构软件开发资源的投入有指导性的意义。通常人都是很懒的喜欢重构一些低挂果（好摘的桃子），反正又有工作量又有漂漂亮亮的晋升理由。相反踏踏实实冒着高风险修改关键业务的收益无法很好的衡量。
软件债务久期
久期和凸性是衡量债券风险的重要指标。同样利用久期的计算也可以很好的规划软件债务风险。软件债务久期越短相对风险越小，这样的考量下，并不是简单的降低软件开发cost可以平衡的，因为同时它考虑到了业务后续的风险和潜在故障的贴现，使得企业主有更好的债务衡量工具，是招一堆P6还是一个相对完善的阶梯级的研发团队。一堆新手虽然使得近期的软件开发成本下降了，但是会使得远期维护成本急剧上升，久期的计算便可以放大这样的问题使得管理层能够更好的意识到这样的风险。通过软件债务久期指标便可以获得比较科学的重构规划。
弹性计算和算力网络
你在前文中看到了大量的Buffer、弹性，把它结合到网络上来看，其实就看到了云计算厂商本质上就和交易市场上的做市商一样的，提供流动性。这些问题已经在下面两篇文章中做了详细的阐述了。
Buffer、QoS管理
其实网络中的Buffer和QoS管理都可以借鉴流动性管理的思路， 这些通常在我每次给各个交易所做咨询的时候都会用到，也不用多说了，泄密不好。