-前文-
所谓“估值”，顾名思义是按照公允价值计量原则，合理的估计资产真实价值。与前面系列文章中提到的减值，两者根本目的均是准确计量金融资产的真实价值，殊途也同归。
使用摊余成本（AC）计量的金融资产需要进行减值，资产负债表中体现资产标的及其对应的减值准备，从而反映资产真实价值；
使用公允价值则需要用公允价值波动结合账面价值进行调整，使其公允价值能够及时反映真实价值。
在传统商业银行，一般的金融资产包括现金资产、信贷资产、同业资产、投资资产等。
其中资产价值相对稳定，且业务模式和持有目的主要是获得利息收入，计量方式以AC为主的，需纳入减值范围；
而一些投资类资产价值变动较大的，或持有资产是为了交易（for Trading）采用公允价值计量的，需纳入估值范围。
【估值计量模型】
估值方法有很多种，本文重点提到的是现金流折现模型。
经典算法：
现金流折现模型（discounted cash flow model，DCF 模型）是通过将所有未来的现金流折成现值来求得资产内在价值，下面的公式中这个折扣率（discount factor）= 无风险收益率 + 风险溢价。公式中和时间系数有关的类似永续年金的计算方法，学习这个我也把无穷级数的知识翻了翻。
系统算法：
利用上面的公式原型，系统开始计算公允价值，将参数一个个代入。整理下来，可以按三步走，走不通再说。
估计未来所有的自由现金流；
确定一个合理的折扣率；
将所有未来的现金流折现到现值。
现金流即票面金额，分母的t就是估值时点到票据到期日的累计。这里折扣率使用的是无风险收益率，即数据日期当日的shibor利率，另外风险溢价此时还是个未知数，走不通，那就还需要另外求解。
同样还是这个经典公式，反过来以贴入金额作为现值，t对应的就是起息日到到期日，未来现金流依然是票面金额，换算出这个风险溢价参数。把计算的参数带回去即可得到当前估值时点的公允价值。
（后记：在刚刚接触学习的时候，为了逻辑连贯的理解，也翻阅了很多资料，其实还是相当高深莫测的，有一些参数如折扣率也蕴含了行业专家经验性的主观判断；这些经典公式，以及其他很多的复杂的数理公式在很多金融场景也多有应用，需要学习的还有很多，想要深入理解还是需要系统性的学习。）
【技术方案】
1) 分布式任务调度平台
IFRS9 系统目前可以实现完全自动化调动，产品是基于分布式任务调度平台XXL-JOB开发的；Github有源码下载，对Mysql兼容，感兴趣的同学也可以自行体验。
这个开源工具一些设计还是挺实用的，比如：支持Web页面对任务进行CRUD操作，动态修改参数(语法按Cron表达式)，中心式的调度中心和分布式的执行器，还可以支持Rolling实时日志查看。还蛮方便的，如果要想各任务之间状态依赖，日志更加直接明了，还是需要做一些二次开发的。
2）Shibor利率获取
在前文中提到的模型中，计算依赖Shibor利率（上海银行间同业拆放利率Shanghai Interbank Offered Rate，简称Shibor）。系统利用自定义的调度任务去获取固定格式的数据并进行解析，行情发布数据如下图，供参考。
数据来源：中国外汇交易中心官网公开数据
系统解析后拿到的是离散的数据，需要利用插值法，在离散数据的基础上补插连续函数，使得这条连续曲线通过全部给定的离散数据点。那么程序需要在已知的两点数据之间拟合曲线上得到这两点之间的期望数据。下图是我在excel 中利用TREND函数计算的结果，基于已知X集合{1,7}，已知Y集合{2.09,2.17}得到的X=2,3,4,5,6对应的shibor值。
JAVA实现这个算法的方案有很多，插值法也有很多数理理论的方案，诸如拉格朗日插值法，分段线性插值法等，Python也已经支持很多成熟封装函数，例如splreph、splev函数都可以达到类似的目的。按照这个方法，最终就可以得到1~365天及其对应shibor的数据了。
3）估值任务解耦
IFRS9系统最早的设计实现是将减值、估值计量任务合二为一的。因报送需求，估值需要当日进行真实的账务体现。基于此方案，系统需要最大程度的解耦减值和估值任务，系统设计上在数据库的表做了拆分，模型表，接口表，测算计量中间表实现了完全独立，程序上也是独立的调度任务。因为外围系统的数据交互式文件的方式，好处是在数据处理上完全互不影响，甚至可以并行，也避免了减值数据转历史带来的冗余时间。
这里值得一提的是外围系统的数据文件是一个统一的标准，接口并没有区分减值和估值。那么在数据分组任务上，系统会通过一些执行条件的配置筛选业务上需要估值的交易，命中执行条件后执行相应的程序类。
现金折现模型计算公允价值波动，最终的公允价值就等于账面价值-公允价值波动，因为系统采用发生额的方案（上一篇文章对发生额，余额方案做过介绍），逻辑整理如下：
存量交易的发生额等于当前公允价值余额减去上期公允价值余额；
新增交易的发生额就等于余额；
已结清交易的发生额就是上期余额的相反数；
系统在处理已结清交易是需要mark特殊标记，这些已结清交易的估值余额，账面余额均不能再参与计算了。这些发生额正是生成账务文件的依据和来源，需要严肃对待，一点儿也错不得！！!
本节中谈到系统的配置化功能，多说两句个人对SAAS产品的一些思考。现在很多SAAS产品追求实施成本降低，思想上都参考解耦性的参数化改造。我曾直接参与设计过SAAS产品并投产，追求极致的参数化，产品思维自然会设计成多层级配置的逻辑。粗暴的方式解释就是，功能不是一个菜单里可以直接配置的，而是一级一级的配置，最终达到你想要的效果。其结果是两面性的，一方面确实带来了实施成本的降低，无需开发人员，取而代之的找一个逻辑性强的非开发人员也可以独立完成；但是也带来了一定程度的维护和学习成本。因为这个商业产品隐藏逻辑就是：如果配置化程度低了，开发人员就需要定制化开发，成本就下不来；如果大多数功能都可以通过配置实现，其参数化配置相对复杂，相关人员的学习成本就很高，后期的问题排查难度比翻代码还难。
4 ）账务文件解耦
各模型计量结果最终都将以交易流水文件并进总账系统，目前系统是需要全部计量完成后生成账务文件，我们正在考虑进一步优化这个设计，充分解耦，理想的情况是分批次生成账务文件，各模型计量测算完成后就生成送给总账系统。如此一来，系统的灵活性达到最大。
【项目管理心得】
现在日常工作中，我始终要去面对和思考的一个问题就是数据治理。
1）数据检查shibor利率的获取及处理；
定时任务去获取数据，是会出现各种原因拿不到的数据的，就需要检查特定数据日期的数据是否存在，通过增加SQL监控，及时发现每一个环节的数据问题，确保必须要在测算任务前获取正确的数据。
2）数据检查业务数据
和计量模型强相关的贴入金额，账面价值，起息日，到期日等业务数据需要前置数据检查任务，在导数就需要做数据合法性检查，做非空校验。另外还有合理性校验，曾发生过一次账面价值送了个0，公允价值余额直接等于公允价值波动，数字得有5.6个亿，幸亏是测试环境，否则将直接体现在权益科目。正常连续每日波动在万元级别，系统也考虑增加短信提醒功能，若数字波动超出正常范围，做一个提醒关注，我们做这种系统的人，需要对数字足够的敏感。
致谢曾请教过的每一位技术老师，业务专家，诚挚感谢您的指导。
更多金融科技的思考与实践，烦请关注公众号：Qiannianyhj