资管运营BAND原创 | 如何给估值流程上一道风控保险？浅谈基金估值业务风险管控思路

积募重磅推出全新栏目——《资管运营BAND》，深耕资管运营，挖掘专业知识，逼你深度思考。

BAND成员均来自于大型金融机构，十余年从业经验，深谙基金运营流程要点。

每周一耕，不见不散。

这是一篇迟来的分享

——有观点的响哥——

得贵人相助，在十一长假归来之后，有幸约见到了魔都资管运营界的两位大佬。两位在经验丰富、功力深厚之余，还有着平易近人、知无不言、言无不尽的优点，加之风趣幽默，令我等除了在专业领域受益良多之外，也在一阵阵的爆笑中彻底治愈了假期综合症。

当然了，做运营的人见面，难免会聊一些工作中的糟心事，吐一吐心中的苦水，相互表达一下理解和支持。大佬Z就说了这么一档子事，乍一听到，令人惊讶于此事处理方式之原始和低效，然而在说出背后的原因后，大家又在表示理解之余，体会到一丝无奈。

事情是这样的：大家知道，每天基金产品对外公布的净值，都是依靠估值岗一系列的计算得到的。在通用的流程里面，每天估值岗把净值计算出来，同托管进行复核，然后再传给份额登记岗，份额登记岗再把净值传给中登，完成发布。

整个过程都是在运营系统中完成的。净值在估值系统中完成计算，核对完成后，一键导出成净值文件，然后TA系统再读取净值文件。然而，就是这么一小步，Z总却要求团队多做了这么一步：在同托管核对净值的时候，把核对一致的净值手工记录在一张纸上，然后同上面图中第三步系统导出的净值再次进行核对；核对一致后，才把净值文件交给TA。

为什么在可以做到纯系统数据交互的情况下，要多此一举呢？对此，Z总道出了背后的苦衷。在之前，Z总的团队本来是没有这道工序的，净值核对完之后就直接导出来给TA系统，可后来发现，有时候系统里导出来的净值，和原先核对时的不一样；也就是说，净值变了！

为什么会这样呢？是有人在核对完成后进行了误操作？是有人改了估值数据然后没通知其他人？鉴于事发现场已不可考，Z总决定先上一道保险：每次核对上净值之后，在系统里面把净值进行锁定。在这种情况下，理论上可以把误操作的可能性排除在外。误操作排除之后，只需要盯着真实的需要修改净值的场景，加一些复核流程就可以了。

可万万没想到，在加上一道锁之后，情况并没有得到改善，系统导出的净值与核对时看到的净值，还是有不一致的情况！经过排查，原来是系统有个bug，会导致对某支产品进行操作的时候，影响到另外一支产品的数据，即便是净值锁定了，还是可以影响到。这个跟系统操作、工作流程一点关系都没有，只能等着厂商去解决bug；但大家也都知道，与其等着厂商去解决bug，还是自己想个应对的法子比较实际。Z总实在是没办法了，思来想去，只好采用看起来最笨的，但也是最有效的办法：用手记。于是便出现了上面所提到的，手工记录净值人工核对的流程。虽然耗时耗力，但总好过报一个错误的净值出去。

所以，这里就是一个用风控手段弥补系统缺陷的例子。不得不说，这个缺陷很要命，因为这种缺陷，它冲击的是数据传递和处理的逻辑一致性，导致了所见非所得，直接的结果就是降低了用户对系统的信任感。

熟悉笔者的朋友们可能知道，笔者把基金估值业务中的数据风险管控归纳为三类：逻辑一致性、数据准确性和数据完整性。这次是借花献佛，借着大佬吐槽的机会，把这三类管控给大家掰一掰。

一、逻辑一致性

目前业内通行的基金估值流程多为线性流程，就像条流水线。如果出现了某个流程节点数据处理逻辑不一致，就会意味着无论该节点前的数据质量有多高，风险控制的多好，到了这个节点之后，一切都得从零开始从头来过。因此，逻辑一致性的校验，在运营风险管控中，有着无可比拟的重要性。

逻辑一致性的校验，通常采用的是另起一个平行流程的方式，即在数据交互的节点，使用同样的业务逻辑设定和同样的输入值，通过输出结果来反查处理过程是否符合预期。由于现在大部分的业务逻辑基本上都已经固化在业务系统中了（别告诉我还有自己手工处理的，愿上帝保佑你们），所以这个校验越来越多的是通过系统体外的手工流程，去校验、弥补系统的逻辑缺陷。

在当前人工智能、深度学习火热的舆论环境下，很多机构越来越倾向于通过机器去完成一些流程化的东西，目前市面上也的确看到一些系统厂商，搭建业务系统的思路逐渐向“一键完成XX操作”靠拢。但是需要警惕的是，在系统逻辑缺陷没有得以解决（至少解决绝大部分）的情况下，单纯的追求自动化，反而会造成业务下游承载所有上游过来的错误数据。大家知道，发生数据错误时，最好的解决时机就是在当下，而再向后传递的话，会给解决问题带来更长的分析路径，分析的难度以指数级上升。因此，笔者在这里反倒是建议，在自动化、智能化的道路上，先实现一个小目标：解决系统内部逻辑一致性的问题，为后续的自动化提供空间，为效率提升铺平道路。

二、数据准确性

数据的准确性指的是数据源在输入至业务流程节点的过程中，是否能准确反映业务实质。这里的数据除了业务流数据之外，还包括一些业务逻辑的设置参数。直接这么提出来太抽象，我举个例子大家就知道了：

单子录错了、系统设置有问题，其实都是业务语言转换为流程语言时出现了“翻译”的错误。在实务上，对于数据的准确性，多依靠双人复核进行保证；双人复核，国外的说法是四眼复核，我想他们显然没调查过我国高发的近视眼普及率。在双人复核中，岗位A负责业务数据的录入，岗位B则直接对照原始单据，查看岗位A录入数据的准确性。与上面所说的逻辑一致性检验相比，数据准确性复核往往是一步到位，不会涉及到计算、判断等逻辑运算步骤。

问题来了，双人复核，费时费力，还是事后检查，有着诸多缺陷。那么，在数据准确性检验的效率层面，有什么可以提升的空间吗？答案很简单：用机器录。

用机器录，其实一直是基金运营数据录入方式的主流和持续努力方向，君不见市面上有众多的运营系统和平台、财务机器人，干的都是这个事儿。但如果统计一下系统对业务场景的覆盖率，会发现并没有达到应有的高度。据笔者观察，主要受两个要素制约：

1、系统逻辑一致性。这个上面已经说过了，不再赘述。另外这点也是很多系统厂商应该反思并加强的地方。

2、标准化数据接口。

说到标准化数据接口，大家第一印象应该是交易所、登记公司的标准化数据接口了。不得不说，咱们国家的交易所和登记公司，为市场参与的机构做了很多很多事情，服务的范围和质量，在世界上绝对是居于前列。但这也造成了基金运营中的一个怪现象：运营数据过分依赖交易所和登记公司，缺乏内部数据的提炼和使用。

说怪，是因为从逻辑上来说，尤其在管理人端看来，交易室才是所有交易数据的源头，运营端放着原生数据不用，舍近求远去使用交易所和登记公司的数据，便利是便利，但也因此放弃了很多信息：资金来源、策略、交易员、质押状态……在粗放式管理的时代，这些信息就像埋在地底下的金子一样无人问津；而现在，越来越多的管理人希望利用这些数据，做精细化管理了，然而一看运营模式下的数据流向……好吧，我再想想办法……

过分依赖交易所和登记公司的数据，还带来另外一个问题，就是非交易数据、场外数据和非标数据一直没有在格式上得以很好的规范。但这个是个先有鸡还是先有蛋的问题：是先有标准，再有接口？还是先做接口，再逐步完善标准呢？但无论如何，事实就是，这些交易所之外的数据，因为没有标准接口，做不到电子数据交互，很大程度上还是依赖人工录入，因此成为了数据准确性风险事件高发区。

对此，笔者的建议倒是可以先从管理人端入手，至少在机构内部实现全量交易和非交易数据的电子化交互，提高业务数据传递的准确性。因此，业务系统构架需要做出如下的转变：

简言之，就是打通前中后台系统，改变后台系统孤立的局面。

三、数据完整性

如果对估值业务中所出现的风险事件，按照发生频次进行一个排序的话，我相信占第一位的一定是因为漏交易所导致的净值错误。之前碰到的太多了，现在闭着眼睛都能列出来有哪些常见情况：

1、被动发起的划款、付费未能记录：常见于银行汇划费、账户维护费等被遗漏的情况，通常是因为估值人员没有查银行头寸，或者查询时间过早。

2、银行间交易遗漏：常见于交易完成时间较晚，估值人员已经完成估值并且认为当日再无新的交易，或者估值人员漏了成交单，并且日末未能核对银行头寸；但无论是哪种情况，基本可以确定估值人员没有同交易系统进行日末持仓核对。

3、开放式基金赎回确认交易遗漏：基本上就是估值人员遗漏了赎回确认单，并且没有同交易系统或者基金公司对账单进行持仓核对。

4、转债转股交易遗漏：有可能是系统缺陷导致交易未能读出，但必然是没有做中登对账。

5、大宗交易失败未删除：未能检查结算结果，但必然是没有做中登对账。

6、……

其实从上面的例子中可以看出，对付数据不完整的风险，往往需要依靠事后的第三方资金和持仓核对。最常见的，莫过于针对日末头寸的银行资金调节表核对、针对场内持仓的中登对账、核对场外开放式基金的基金对账单核对、针对银行间持仓的中债/上清所持仓核对等等。利用这些第三方，尤其是登记机构的数据进行事后核对，基本上可以确保万无一失，所以深受运营人员的喜爱。

但是，问题来了，这些数据拿不到的时候，该怎么办？比如开放式基金的对账单，不一定每天都发的，或者有些场外的标的，管理人甚至有可能都拿不到对账单。面对这种情况，笔者认为，解决的思路依然是打通前中后台，最大限度的利用管理人自身产生的数据，至少保证主动发起的业务不会遭到遗漏。至于被动类型的业务，涉及到资金的，比如扣费之类，应该有调节表可以覆盖；不涉及资金的，大多数应该是权益行为，可以利用资讯信息，结合持仓数据，产生公司行为日程表去对照、复核。通过这种方式，即便不能做到百分之百覆盖，但聊胜于无，总归是比单纯的依靠第三方数据要好。

以上就是笔者所总结的基金估值业务风险管控的三个要点。当然了，各个机构之间，对于估值岗位的职责、定位也不尽相同，估值业务覆盖的范围也有大有小，所面对的风险也有可能超出本文所讨论的范围（比如估值岗同时承担交易支持的）；但无论如何，依笔者看来，在系统自动化程度逐步提高的情况下，风险管控将逐渐成为基金运营的业务核心和价值所在，运营流程的设计也逐渐将从业务流导向转变为风险导向。所以，各位做估值的同行们，你们准备好了吗？