「术小科导读」互联网财富管理平台应该怎么做？（上篇）从“什么样的理财产品才是用户最喜欢的？”问题引出账户，并从支付到支付体验深度推演了得账号者得天下的原因。且例举了不同账号类型财富管理平台对应的发展方向。本篇内容承接上篇，将从四个方面详细阐述系统如何助力业务发展。

系统如何助力业务发展？

天下武功，唯快不破。

按照上面的分析，只有给用户提供了“快”这种核心体验，则可以征服用户的心，从而获得市场。所以问题细分为如下问题：

• 如何得到账户？
• 怎么样构造让用户感觉很快的业务形态？
• 信息系统如何快速的实现目标？
• 信息系统如何稳定的实现目标？

1、如何得到账户？

这个问题是基础，因为有了账户才能建设“快”的账户。前面提到，关键的账户通常掌握在银行等金融机构手中，那么对于互联网机构来说，怎么得到账户呢？他们通常会采用如下一些方法来持有账户：

• 直接持有。通过持有银行牌照、第三方支付牌照来合规持有用户的银行账户或者支付账户。当然这些牌照都是非常昂贵的，例如2016年海立美达30.39亿元收购联动优势。含金量更高的银行牌照当然更加昂贵。
• 账户映射。简单说就是建立一套映射账户，分别映射到用户的真实账户，例如蚂蚁金服和腾讯理财通给用户展示的资产负债，其实后面真实的账户分别存在于各个银行、基金公司、保险公司以及第三方支付公司等。虽然这种账户并不是真实账户，但是通过映射提供跨业务线的统一账户视图，通过垫资提升回款体验，通过对接大量场景获得用户粘性，也在商业上取得了巨大的成功。这种模式的最大优势在于充分利用流量优势，以及支付便捷性以及应用场景粘性可以带来巨大的交易量，缺点在于“资产转移速度”慢，以及垫资成本等，随着银行等机构利用自身优势提供类似服务的时候，其竞争力逐渐丧失。
• 创造账户。基于自身流量优势，创造并持有一种账户，例如Q币，以及各种币，豆，分值。按照上面的定义，它们也可以归属为用户的资产，利用这种方式可以给用户创造各种纷繁复杂的使用场景，但是其最大的缺点在于流动性差，例如不能给他人转账，不能跨公司支付等（不过这应该是一种废话，因为如果具备这些能力的话，就可以等同于货币了，这个央行可是不允许的哦）。这种账户通常被用于营销场景，但是目前看来各种机构提供的这种虚拟账户都存在一个弊端，即账户种类太多，即使在一个体系内部也是并存多种账户，导致账户之间转换存在巨大难度，基于这种账户的场景互相独立，用户体验差。所以整体来说，这种账户距离真正金融账户的距离还很遥远，只能是一种补充。

这里着重描述账户映射，这是一种最常见的做法，但是这种做法却存在天然的弊端。数据库领域有个很著名的CAP定理，意思是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）这三个要素最多只能同时实现两点，不可能三者兼顾。在账户映射上面同样存在类似的情况，我给它取个名，称为合规成本体验不兼容原理，即当机构不持有账户而使用映射账户的时候，不能同时兼顾账户合规、用户体验高以及经营成本低三个诉求。

具体情况是这样的：

• 合规通常包含多个方面的监管条例，以理财业务为例，用户实名是最基本的要求，还有反洗钱、各业务自己的法规（证券、基金等等相关法规）等等。其中以反洗钱为例，遵守反洗钱这个约束通常会要求整个理财流程遵守理财买卖过程遵守同卡进出的原则，即用哪张卡买的理财赎回款就必须回到哪张卡。
• 用户体验通常体现在当用户使用映射账户进行其他理财产品的购买或者赎回的时候。以余额宝为例，因为它是货币基金的映射账户，当用户直接使用它购买其他理财产品的时候，因为要遵守同卡进出原则，用户的货币基金必须赎回到账，然后再发起另外的理财产品的购买，这个过程漫长到用户不能忍受。换言之，“资产转移速度”很慢。
• 如果期望用户体验好，当出现上述问题的时候，互联网机构通常会进行垫资用于提升用户体验，但是垫资对于互联网机构来说就存在经营成本。通常来讲这个成本可能会大于经营业务所带来的收益，以至于业务进展陷入悖论，即越经营越亏损，而转嫁成本到用户身上又会降低用户体验。

2、怎么样构造让用户感觉很快的业务形态？

基于账户，我们要做的是设计并实施若干功能，让用户感觉“资产转移速度”很快，在具体的做法上是有很多的方案的，包含并不限于如下方案。

2.1 垫资

前面提到业务合规和用户体验以及经营成本之间是一个比较复杂的相互牵制的关系，而单说强调“快”的用户体验的话，一个常用的方式就是“垫资”。垫资简单说就是中间方先行垫付给客户，等待客户的赎回到账之后再偿还垫资款，这样可以直接提升用户获得资金的时效，按照不同的维度可以将各种垫资场景简单描述如下：

互联网财富管理系统按照资金流程分为两个过程，第一个是用户的收单过程，狭义理解为用户的支付过程；第二个就是资金结算过程，这个过程按照业务的不同千差万别。垫资本质可以理解为后端资金结算流程中的一部分，或者一种模式，系统典型资金流示例如下：

其中赎回款的垫资可以按照垫资方的不同分成几种垫资方式，但是总体而言，经过垫资的赎回，和普通的赎回是有典型的差别的，经过垫资的赎回，通常可以做到T+0，T+0.5等，而普通的赎回则通常会是T+1或者更长。

资金时效提升之后，对于机构客户，以及个人大客户的直接影响是很大的，以七日年化收益率3%的货币基金为例子，1亿元资金一天的收益就是8219元，间接影响难以评估。

Tips-什么是T+0.5？

什么是T+0.5呢？这个说法不知道是从哪儿出来的，但是很准确表达了时间效率。通常号称的T+1实际到账时间是第二个工作日15:00之后，这样对于赎回来讲，即使用户拿到了钱，但是已经无法在当天再次投入股市或者是基金市场，从而浪费了资金时效，如果能够在当日股市开盘（9:00）之前拿到钱，则对于用户来说，可以选择投资基本上任何一个市场，提高了资金使用效率。所以简单来说，T+0.5就是比T+1“早半天”。

按照上面的分析，可以想象能够实现的垫资场景有：

• 针对普通用户购买货币基金的实时垫资，即普通的货币基金快赎。
• 针对普通用户的购买风险产品的实时垫资，例如股票基金。
• 针对金融机构客户的T+0.5垫资，提升资金运用效率。
• 针对企业客户的T+0垫资。
• ……

当把这个垫资能力广泛运用到各个业务场景的各个客户身上的时候，对于客户而言，整体的资金回笼速度大大加快，整体提升了“资产转移速度”，为客户提供了新的价值。

2.2 账户互通

能够让用户感觉变快的另外一个方式是将用户持有的各种账户进行互联互通，可以想象的有：

• 在银行场景下，将借记卡和信用卡打通，这样可以快速使用借记卡还信用卡，或者用信用卡取现到借记卡；
• 在理财场景下，将用户的理财账户和借记卡之间打通，理财账户和理财账户之间打通，这样可以实现它们之间的快速转换；
• 在其他自建账户场景之下，将用户的资产账户和自建账户打通，可以快速将用户资产转换为卡、券、豆、币、金元宝等等自建账户。

账户之间互通的越广泛，用户会越感觉快，因为每种账户都对应用户的某种使用场景，或者是投资，或者是融资，或者是消费。所以谁能提供更加广泛便捷的账户互通服务，谁就可以获得用户的心，从而占领市场，余额宝就是一个典型的例子。

这里有个有趣的例子，假如现有账户和黄金账户打通是个什么样子？随着互联网渠道的兴起，各种类型的黄金产品已经大行其道，以商业银行的积存金为例，近几年交易额急剧增长，用户也形成了在互联网平台持有黄金账户的习惯，如果用户能够将人民币快速转换成黄金克重，也能将黄金克重快速转换为人民币，那么是不是可以回归到金本位了？互联网统一使用黄金支付？God，想都不敢想。

上图是个典型的黄金业务，其中业务模式简单描述如下：

• 买。指的是用户用资金进行黄金的购买，这里并不是指的黄金实物，而是账户，用户通过购买获得黄金账户，这些账户可以按照不同的种类分为积存金、纸黄金、黄金ETF、黄金期货等等。
• 卖。指的是用户将自己的账户黄金卖出从而回收资金，这个过程是买的逆过程。
• 提。指的是用户将自己的黄金账户提金为实物，依据业务的不同，某些账户是可以进行的，这个主要是满足用户在某些情况之下需要提取实物的需求。
• 存。这个是指的用户将资金手里的实物黄金卖给机构从而获得黄金账户或者资金的过程，可以简单的理解为“提”的逆过程。
• 转。这个恐怕是争议很大的一个特性，它指的是将用户的账面黄金转给其他人。在这方面腾讯进行了很长时间的尝试，但是正如上面所说，这种方式将会给现有支付体系形成较大的冲击，恐怕从监管角度来说不会很快的全面放开。这也从侧面反映出黄金账户的潜在巨大威力。

2.3 场景拓展

以账户为基础，以交易为武器，广泛拓展各种场景，这样可以极大程度的“粘连”用户。例如：

• 广泛开拓各种高频低额的生活场景。例如缴纳水电煤气费，电视电话宽带费，等等，接入范围越广用户会感觉越便捷，整体感觉越“快”，用户粘性会越强，余额宝的生活场景接入就是个典型的例子。
• 基于用户的消费需求而产生的基础账户，继续开拓用户的投资和融资需求，也就是高额低频场景，逐步满足用户的所有金融需求，这样可以形成让用户不愿意离开的金融生态圈，在这个意义上，微信生态圈和余额宝生态圈正在不断接近这个目标。体现在投资需求上，系统需要接入更多品类的更多理财产品。

3、信息系统如何快速的实现目标？

信息系统快速实现功能以及快速迭代升级的根本原因在于系统对各种业务之间的共性进行了合理的抽象表示，从而能够适应各种业务形态；并从工程实施的角度使用了良好的方法来保障实施的效率以及质量，包括系统建设的各种辅助工具，工程实施方法论等。针对账户类系统来说，主要的抽象可以包含账户系统和交易系统，这是业务系统的几个基础系统。

3.1 如何构造合理的账户系统？

了解了账户的本质，也知道了账户的关键特征，那么剩下的问题就是，怎么创建一个完美的账户体系？先从账户的结构说起，逻辑概念上来讲，账户可以简单描述为包含三个方面的信息，如下图所示：

按照前面的表述，账户描述了资产负债的持有和使用情况。其中“帐”表示的是资产的实时状态，“交易明细”描述了“帐”的变化历史，“汇总账”是针对“帐”在不同维度的汇总。这种简单的概念结构可以广泛描述包含金融资产在内的各种资产的情况。按照资产和负债的各种细分，可以用下面的图进行进一步的描述：

看起来是不是很眼熟？是不是很像会计科目？没错，会计层面已经针对资产和负债以及所有者权益进行了标准的分类，在实际操纵中每个公司针对自己的业务有自己的一套细分科目，但是整体逻辑概念是一致的。在记账方式上，会计账通常使用复式记账，其在理论以及实操层面已经形成了相应的系统，而在大部分互联网公司，出于快速记账以及系统快速迭代的需求，通常在用户帐这方面采用单式记账，后端财务处理上使用复式记账。

可不要小看这个用户帐，想要把它记好，也不是一件简单的事情，挑战来源于几个层面：

• 互联网金融公司、金融机构互联网部门通常给用户提供种类多样的账户服务，其对账户的分类通常按照一定的业务线或者说金融工具来进行划分，其在记账需求上存在横向扩展的随意性，信息系统需要考虑支持这种横向扩展。
• 同样出于金融工具自身的特性，其在不同的工具上，存在纵向汇总账户的独特性，例如有的汇总账户需要在用户一级进行汇总，有个需要在金融产品一级进行汇总，甚至还可能存在跨业务线跨业务产品的汇总（例如按照金融产品流动性进行分组汇总）。所以存在记账的纵向扩展的随意性，信息系统需要考虑支持这种纵向扩展。
• 交易明细与帐之间，以及帐和汇总账之间存在不同的一致性需求。按照前面章节描述的数据一致性的不同需求，它们有的需要遵守强一致性，有的需要遵守最终一致性，有的是弱一致性。
• 账户数据既要统一管理，又要支持根据业务线不同的生命周期进行不同的生命周期管理，从而保证账户的既分离又统一的特性。
• 需要系统具备高可用的能力，即在体系结构上需要考虑读写分离，分库分表，负载均衡等等。

能够满足以上特征的账户系统，可以称之为“万能账户”，只有足够灵活以及可扩展的账户系统才能提供超越想象的用户体验的产品形态，例如可以想象的有：

• 建设统一的、跨业务线的、跨资产负债的全面个人账户体系，并基于此提供财富管理服务，投资顾问服务。
• 提供跨越资产种类的“超级转换”，并基于稳定的底层账户，提供灵活高效的资产间交易，即提升“资产转移速度”这个核心能力。
• 提供跨越各个业务线的资产快照服务，资产证明服务等等。

当处于交易环节核心的账户系统已经就绪，那么对业务的提升主要体现在：

• 可以快速高效的建设新类型的业务系统，抢占市场先机，获得用户，提升业务。
• 可以快速高效的针对旧有系统进行升级改造，加快迭代，提升用户体验，从而提升业务。

3.2 如何构造合理的交易系统？

按照上面的分析，账户系统是金融体系的核心，交易系统可以抽象理解为产生和记录账户变动过程的系统，它“解释”了账户为什么变动的具体原因。典型的，以基金交易为例子，整个过程简单表述为：

其中每个过程可以表述如下：

虽然这个过程是基金交易的整个过程，但是它也描述了典型的交易系统的整个执行流程，其他各个业务线可以进行类比，只是产生交易的规则和方式不同而已。从用户角度来看，用一个完整的申购赎回的例子表示其资产变化情况为：

其中有几个点需要注意：

• 对于“在途资金”，主要用于表示用户支付完但是没有获得基金份额确认的状态，以及赎回完毕但是资金未到账的状态，从会计意义上来说，其实不应该算作是用户的资产，但是从用户感知上，需要表示为“自己的资产”，这主要是从用户的体验上考虑的，因为如果不明确表示出来，会给用户造成心里恐慌，感觉自己的钱“失踪了”。
• 资产收益账户主要用于累计每日资产价值变动，对于基金公司来说，是没有“收益”（即每日资产变动）这种说法的，但是从目前主流的互联网机构角度来说，都给用户提供了这种“增值服务”，即用净值导致的资产价值的变化当成是每天的“收益”，这个基金资产收益账户就是用来累计这个收益的。

对整个交易过程进行记录就是交易系统的职责，它记录和描述了整个账户变动的过程。从系统角度来说，挑战在于：

• 每个业务虽然都遵从类似的过程，但是每个业务又都有自己的特征，如交易的确认过程基本是千差万别的。对于基金来说，其主要交易类型包含开户、购/申购、赎回、转换、质押、清盘、销户等，对于黄金来说，主要交易类型有买入、卖出等。
• 描述每种类型交易的信息对于每个业务来说都是有很大的差异的，很难使用统一的方式进行表示。其中基本交易明细具备我们常用的属性，例如交易双方的信息，例如用户信息（身份证号，登录账号），基金公司；还有交易内容，例如SKU，基金编码，交易日，交易账号；还有理论上无限可数的属性，例如是从PC下单还是手机下单，什么牌子手机下单，什么浏览器下单，什么IP下单，什么wifi网络下单，什么地理位置下单，等等。还可以加入新的自定义维度，例如定投策略，基金组合策略等等。所有维度的属性都可以进行笛卡尔积式的组合，得到不同的汇总账，很多的维度可以有不同的用途，例如：

• 如何保持数据的存取高性能。对于小额大量的业务需要系统具备高可用的能力，即在体系结构上需要考虑读写分离，分库分表，负载均衡等等。
• 如何保持数据的安全，例如数据的业务间隔离（防止跨业务间错误修改），尤其是某个业务的数据出现问题的时候，不能影响其他业务的数据。
• 如何保证数据的高可用，例如存储冗余备份机制。这样某些业务数据出现问题的时候，其他业务能够正常运行。
• 如何提供快速和安全的接入，这样新建业务能够简单的通过系统扩展即可获得支持。

能够满足以上特征的交易系统，可以称之为“万能交易”，可以提供支持各种交易模式的基础能力，然后基于此可以衍生很多的增值服务，例如可以想象的有：

• 建设统一的跨业务线的全面交易体系，并基于此提供个人信用管理服务，个人风险管理服务，投资顾问服务。
• 提供全面覆盖各种业务的账单服务，交易证明服务等等。

和账户系统一样，这种交易系统对业务的提升主要体现在：

• 可以快速高效的建设新类型的业务系统，抢占市场先机，获得用户，提升业务。
• 可以快速高效的针对旧有系统进行升级改造，加快迭代，提升用户体验，从而提升业务。

4、信息系统如何稳定的实现目标？

开车开得快，并不能称为老司机，因为谁都可以开快，真正的老司机，开的既快又稳。所以系统“稳”是“快”的前提，没有这个前提，系统也是无法真的助力业务增长。基于账户的系统有很多经典的问题，一般来说，都会直接影响上下游的系统，一直到用户体验。例如如下经典的问题。

4.1 一分钱

这是个简单到很容易忽略的问题，且看下图，用户的操作过程为：

1. 用户支付1000元，进行一只基金的申购。
2. 基金公司确认份额，然后系统对用户进行展示，金额为999.99。
   这个过程很容易让用户感觉很不友好，那就是，购买即损失一分钱。

这种问题怎么办？

一些较大的基金销售机构的做法也是简单粗暴，那就是，直接给用户的账户增加一分钱！当然能够这样做的前提是平台足够大，因为即使这样做平台也不会损失多少钱，然而可以带来的是用户体验的大幅度提升，用户会选择继续留在平台进行交易，从而贡献更多的价值，简单说，羊毛出在羊身上。

如果账户只有一层，那么这种误差是很小的，因为最多只有一分钱，然而如果某种金融产品底层是多层账户的话，那么误差可能会累积。例如某投连险，其产品底层是由多个投资账户构成，每个投资账户分别管理，所以在投资账户上面存在1分钱问题，多个投资账户累加，会将这种误差扩大（当然也可能部分互相抵消），整个投连账户上可能会存在超过1分钱误差的情况。

当这种情况发生，有的机构解决方案也很简单，那就是，承认误差，并且最终以保险公司的为准，对用户的影响简单来说，用户会偶尔看见几分钱的差异。销售平台会告知用户类似这样的解释“最终赎回金额以实际到账为准”，对于大部分用户在大部分情况之下，是不会纠结于这样细微的差异的，尤其是投资金额较大的情况。

4.2 对账

对账也是一个很容易遇到的问题。这个问题如果解决不好对平台方业务的影响其实是很大的，简单说，如果和金融机构的对账不通过，则不能执行结算，这会影响金融机构投资效率；如果和用户赎回对账不通过，则不能执行对用户的赎回打款，用户不能及时收到款项，则会引发大量的客诉，从而降低用户粘性和忠诚度。

这个问题说简单也简单，说复杂也很复杂。如果简单来说，对于同一套账户以及账户的变动明细过程，因为在不同系统之间流转，所以天然存在不同系统之间记录的情况存在差异的情况，把这些差异找出来的过程就是对账。如果说复杂，是因为同一套账户以及账户明细，在不同系统流转的过程很长，在每个系统内部处理的方式也很复杂，导致整体上很复杂。

对于一个典型的货币基金销售系统，其信息流简单示意如下：

如果从账户的角度来看，从用户的整个交易过程开始，一直到基金公司收到申购款，反过来，从用户赎回，一直到用户收到基金公司赎回款，整个过程其实就是账户以及其变动明细在不同的系统之间流转的过程。这个过程带来的挑战有：

• 相邻两个系统之间的信息如何保证一致？解决这个问题通常需要在账户变动的信息上标注同样的标志，一个常用的标志就是业务发生的时间戳。而这个时间戳如果能够在全流程链路中都能体现的话，对账就会变得很简单，但是现实是各个系统的建设时间并不一致，很多系统早已经建成并在生产环境投产正常运行，要保持全局遵循统一的规范基本是不可能的。
• 跨越多个系统之间的信息如何保证一致？这个问题指的是，当一个信息经过多个系统传播，如何知道最初的账户以及其变动是否准确的传播到了另外一个遥远的系统？如果简单来思考，只要保证两两之间相邻两个系统之间的信息保持一致，则全局肯定能够保持一致，但是对于规模较大传播链路很长的系统来说，实现这个基本上不可能。原因是两两对账会导致技术难度和时间成本急剧增加，其中时间成本有的时候会成为该方案能否 执行的关键决定性要素。所以从方法上面来讲需要重新设计，例如使用二分法的思想跨系统对账，还有直接从起点到终点的一步对账，这些都要针对实际情况进行实际分析。

整体而言，解决方案基本上还是要围绕对账展开，其核心问题还是如何针对要解决的问题制定合适的对账方案，通常而言，可以使用如下几种类型的对账工具：

• 日终对账系统。针对系统上下游进行的系统之间的对账，通常是每天执行一次，当然也可以每天多次执行，视系统需要来进行。日终对账一般情况能够解决大部分问题，但是其弊端是不够实时，简单说，就是如果出现账户和账务不一致，通常需要到日终才能发现，从而错过了最佳解决时间。
• 延时对账。通常用于在用户执行交易之后等待一定时间的“准实时对账”，用于解决用户关于展示正确性的的体验问题。这种系统如果做到极致可以变成实时对账，但是会对系统产生较大的压力，也需要视实际情况实际分析。
• 跨系统对账。一般来说，系统之间的两两对账如果比较完善，则整体系统肯定是没有问题的，但是出于遗留系统问题，很多时候并没有完善的对账系统，当数据不一致的时候需要一种跨系统对账工具，用于快速定位问题。

作者：京东数科 邹保威
文章来源：“京东数科技术说”微信公众号
原文链接: https://mp.weixin.qq.com/s/XhHTSbP33WpSh0e5NbU05w
更多技术干货欢迎关注“京东数科技术说”微信公众号，我们只凭技术说话！