FRTB当中的ES是否需要进行liquidity horizon的调整,并且如何解决full revaluation 巨大的计算量问题

2016/1/29 posted in  观点

detail about the es in FRTB and a solution of the mass computation problem

Q:
大家好~向大家请教下FRTB中181(c)(d),(c)是说ES计算时基于10天ES,用不同的liquidity horizon做scale up; (d)说要找stressed ES= ES(R,S) * ES (F, C)/ES(R,C). 那么这两点怎么结合呢?
比如在计算(d)时,这里的ES已经是用不同liquidity horizon调整过了吗?还是就是最原始的10天ES?

A:
调整过的。(d)的三项ES都必须先考虑liquidity scaling

Q:
那在计算部分risk factor下的ES时,有说必须用full revaluation,还是可以用Taylor那种方法 ?full的话,计算量算下来很恐怖啊

A:
Full reval的要求已经被去掉了。但是对exotic options估计不用full reval很难被接受。另外Taylor 的问题是不一定可以很好地capture高阶与交叉项,这可能会影响P&L attribution的通过

Q:
嗯 是,太exotic的产品误差会非常大,而这类产品做full reval,performance是个大问题。我最近做家HK银行的VaR,最担心的就是他们的FX TARN这类复杂产品计算效率。function角度没有方案的话,只能技术层面优化DB,及时purge,加CPU

A2:
可以尝试阿里云的DRDS数据库,高吞吐量,高并发的数据库,可以把mysql命令无缝迁移,双十一高峰时候的解决方案

Q:
那家客户的现行方案是开快100个core做并行,全行var基本20分钟
其实主要压力在CPU这方面,DB query暂时还好
好在最近的exotic方面的产品越来越少了

A:
如果是计算压力的话,还是采用GPU的cuda计算应该是一个比较好的解决方案了
比如说很多香港投行做的fx tarn就需要这样