财务知识在互金产品设计中的应用

这是件好事，也是件坏事：好处是，一旦一个技术产品懂了业务，就可以堂而皇之的和金融产品撕逼了，而且以逻辑严密性来看，金融产品几无胜算；而坏处是，业务知识壁垒不低。

当然说壁垒不低，那也不尽然。笔者曾见过好的财务老师，能使用两节课的时间，把完全对金融毫无概念的数学系学生带入门，甚至能做简单的财务报告分析。可见，对于我们大多数人来说，达到对金融有基本的认知，并不是遥不可及。所以，接下来希望对财务知识在互金产品设计中的应用，提供一些自己的经验总结。

1. 以公司的视角看待一只金融产品

互联网金融的资产端系统产品需要解决的问题通常是将基础资产打包成金融产品。"打包”这个概念其实颇有些误导 - 并不完全是把资产当做物件捆绑在一起，就能形成一个金融产品。一只金融产品是一纸合同，一份契约。打个形象的比喻就是有一群志同道合的人（金融产品的持有人）作为股东，把自己的钱拿出来（募集资金）建立一个公司（金融产品），把钱交给公司的管理层（资产管理人），让他们通过投资行为，让钱生钱。因为这种行为，股东的股份价值就越来越高，当然股份的增值并不完全等于公司总价值的增值，因为公司增值的另一部分当做管理层的工资（管理费）和公司运作的成本（托管费和其他费用）了。

在这个行为当中，这笔由股东出的钱所投资的东西，正是我们现在见到的“资产”。作为金融产品来说，既可以买这些资产，也可以买那些资产，但选择资产的依据，必须是符合公司章程（投资协议）的。

由此可见，当我们在做资产管理系统的设计时，重中之重是管理好这些角色到底持有这个产品的何种权益，以及这些权益是如何变更的。管理这些关系，记录这些变更的流程，最好的方式自然是使用会计分录。

之前也遇到过一些疑问，觉得金融系统中一定要使用T型会计账吗？其实我的答案是未必，如果你能找到一种更好的方式来表达各种角色在这场游戏中做的事和花的钱（以及应得的钱）的话。然而截止目前，好像还并没有。

2. 以权责发生制和收付实现制来分离处理信息流和资金流

先来回忆一下什么是权责发生制和收付实现制。（以下解释摘自百度百科）

我们经常见到的一个场景就是金融产品由于估值的变化，投资者权益发生了变更，也就是投资者持有的产品份额更值钱了，从前端看，投资者的个人资产增加了，但是！这并不代表有任何人给投资者钱了，他所拥有的只是账面价值的增加。因此在这个层面，应该明确这个场景为：权益确认或收益确认，而并非收益发放。只有在另一个场景，即投资者进行赎回，且赎回金额到账时，才能认为是真正的收益发放。

笔者在产品设计的实操中，曾经遇到过一个自认为是此类问题中的经典。这个问题是这样的：在余额宝类可支持T+0赎回的产品中，客户要求能够预测自己作为运营方需垫资多少。一开始，大家的思路都集中在：T+0赎回订单一旦创建成功，就意味着发生垫资。围绕着T+0赎回订单的状态变更，大家取数做了垫资金额预测值。但是在实操中，发现这个垫资金额预测值竟然从未预测正确过。后来在一次和公司的财务妹子的聊天中谈到了这个苦恼，妹子一句话劈开脑海：申购过来的钱，虽然还没确认，那也是可以付出去的呀!这样不就不用垫资了！

没错，按照权责发生制，T+0赎回的订单都需要在T+1赎回款到账之前给投资者确认赎回出款，但并不意味着，这笔钱一定是运营方来出，因为，运营方的账上还躺着已经收到但还没付出去的申购款呢！[br]
资金流和信息流，在非单笔实时清结算的场景下，总是有时滞。有时滞，就意味着，决不能凭借订单信息流来预测资金余额。所以，我们调整了算法，对于垫资金额的预测，需要由实际的已入款和必定发生的将出款来双向决定。

以上只是财务知识在互金产品设计中很基本的应用，而我们在工作中遇到的场景远比以上描述的更为复杂。作为“很技术”的产品经理，我们需要时刻铭记“系统绝非凭空捏造，需求一定来自业务”的理念，把金融业务的知识，还原到产品设计中。

关键字：产品设计, 互金产品, 产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！