互联网金融涉及的方面有很多,每个都值得细细研究。本文作者从七个角度深度分析集合理财计划,希望对你有帮助。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

互联网金融理财方向涉及的业务场景主要包括如下几个板块:账户、存管、支付、还款、收款、分润、清算、财务、投标、自动投标、智投、红包、风控体系、运营体系、会员、积分商城等。

智投体系是整个理财业务中技术含量最高,最能考验产品经理对金融的理解、对合规的理解、对资金的理解、对资产的理解、对流动性的理解、对投资人的理解、对借款人的理解、对平台风控的理解、对平台运营的理解、对支付的理解、对分润的理解、对财务的理解、对清结算的理解、对数学的理解。

实际上远不止上述14组知识能力的要求,基本上平台原有的所有功能都需要做配套协同。譬如,用户总账体系下的虚拟子账户的处理、投资人收益体系、平台红包体系、电子合同体系(海量债权下的电子合同成本考虑)、提前还款违约金分润逻辑、逾期垫付逻辑等都需要整体考虑。

我们在这方面并无项目经验,但我们用了“2个产品-3个后台研发-1个前端-2个测试”前前后后历时3个月的上线。下面向大家分享一下自认为我们的一些创新和心得,尤其是一个优秀的产品经理在“底层逻辑思维”和“过程方法论”方面的能力要求和这种硬能力对各种复杂问题的杀伤能力。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

1.2.5 “快打”的特殊武器:小组行动

由于智投业务极其复杂,为了解决“快”、为了确保剖析“深”、为了确保考虑面“广”、为了确保结论“客观”、为了规避被“掉链子员工”绑架,我当时采用了小组行动。

我及另外2个产品组员三人分头行动、交差覆盖,最后会审结论,集体review、把有争议的问题再量化分解继续求证。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划-核心业务链路图

3.2.1.1 集合理财计划-核心业务链路图-设计思想

设计思想1:引入计划池概念,计划池作为理财的资金端入口进行资金采集,计划池入口约定进入资金的收益规则、资金站岗规则、退出规则、合规层面的前置法律授权、风险层面的前置提醒等。

设计思想2:引入资金池概念,将用户手动投资资金、自动投标资金、计划未到期借款人还款的代复投资金、超级账户资金纳入队列考虑。这里的资金池不是法律禁止的“资金池”,而是“交易指令池”,在交易发生前,资金依旧在用户账户上,只是处于锁定授权状态,用户不可操作,平台可操作。

设计思想3:引入资产池概念,将借款人的申请待融资资产、投资人赎回释放的债权资产、超级账户调节资产纳入资产池队列,等待清算系统统一征用。

设计思想4:将上述两个池的概念再次拆分为“待匹配池”、“待清算池”子概念。待匹配池可以人工干预调度、有运营动态调控(如需),待清算池是清算前的前奏,是为下一步的财务清算、结算提供物理的时间、空间边界。

设计思想5:将清算概念再次拆分为自动、手动两种模式,自动是每日凌晨自动运行(无人值守),手动是运营随时可手动开启——满足业务放款的高时效性、高灵活性。

备注:底层架构设计到位、研发层面根据项目周期考虑可以自由定夺开发“手动”或“自动”还是两个都开发。实际上只要架构设计合理,两个都开发和开发一个的工作量基本是一样的。

为什么?我们继续进行抽象,自动模式是手动模式中的一种极端场景而已,只是增加一个自动触发器的概念而已。该“手动”场景的置入,配合“合同”的约定及运营规则的市场调整,其灵活性和业务可扩展性的便利程度在我们的集合理财计划的日常运营中充分发挥了其能量。相比市面各互金大厂的产品,此处的创新让我们十分有成就感。

设计思想6:引入事务概念,通过“资金=资产”和“故障回退”,当某笔资金清算失败时,整笔资金回退给用户,禁止部分清算,避免诱发“收益策略”、“合规策略”等问题。

设计思想7:合规考虑1:未清算前,资金永远在用户的账户上;合规考虑2:资产先进入清算池,资金后进入清算池,也即资金找资产链路而非资产找资金链路;合规考虑3:委托服务合同、债权转让合同、风险揭示合同等。

设计思想8:大队列、小队列,自动清算模式下,根据资金/资产属性及进场时间确定其清算优先级。

资金队列优先级:

大队列:复投资金;授权出借资金(含自动出借、预约出借);预约出借资金;

小队列:大队列内部按时间逆序:发生时间越早优先级越高(时间相同按序号,序号越小优先级越高)。

资产队列优先级:

大队列:自动债转(退出策略输出的债权编号);散标;手动债转;

小队列:大队列内部按时间逆序:发生时间越早优先级越高(时间相同按序号,序号越小优先级越高)。

设计思想9:流动性调节(下面的章节详细讲解),通过运营工具、时间锁定、限额、超级账户四级流动性调节工具来引导、干预、化解流动性风险。

3.2.1.2 集合理财计划-配套新概念集合-逻辑推演

为了方便理解上述设计思想及底层的业务原理,也为了与原有的业务概念做区分,我将前述提到的新概念、新名词、新场景等抽象为如下的概念组,通过这些概念组来辅助研发、运营、客服、风控、合规等岗位的兄弟来透彻地理解我们的集合计划的运行原理、合规策略等困惑。

为什么要引入这些新的名词或概念呢?主要是因为这是一个新场景和目标任务的复杂性,我们可以举如下两个例子来帮助我们来理解这种产品思维:

例1:当我们解某个复杂的数学题时,我们引入多个参数、动用不同的数学公式去推导论证。

例2:当我们从功能机时代转到智能机时代,我们要引入很多新的概念来讨论智能手机如何落地,譬如电容屏、电阻屏、滑动手势、指纹解锁、屏幕解锁、显存、系统版本、系统升级、系统补丁、系统皮肤、系统市场、内存管理、应用管理、云端同步、丢失模式、GPS、LBS等一系列新名词、新概念与之配套)。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.2 业务链路图2:资金资产-清算撮合(调度指令)-清算执行

3.2.2.1 资金资产-清算撮合-设计原则

资金量化拆分原则:

设计原则1:相对分散,资金做到相对分散,避免同一人的同一笔大额资金落到同一个债权上;

设计原则2:潜在扩展,现阶段申购资金主要投放到原生债权上,运行起来后要考虑债转场景的小额承载力与编组资金的最大限度自洽;

设计原则3:有限拆分,首投资金不能被无限制拆分;

设计原则4:膨胀约束,复投资金不能被链式再度无限制裂变拆分;

设计原则5:小数收敛,当本息同时回款出现小数时,在不超过原则1的条件下,本息合并投资避免分别投资在未来潜在产生两笔小数;

设计原则6:有限合理,如果可预期内业务扩展能接受,算法设计不易太复杂;

设计原则6:降低错误率:基于上述1~5减少程序计算量;

设计原则7:提升保障速度:基于上述1~6减少故障定位、灾难恢复难度。

债权满标原则:

设计原则1:满标效率:债权满标效率要相对高效,而非所有债权同时被等额消减;

设计原则2:债转友好:投资人到期退出时,债权持有人不至于广而无边,而是有限受众。

3.2.2.2 资金资产-清算撮合-业务链路图

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.2.3 资金资产-清算撮合-设计思想

设计思想1:报名冻结策略,3.2.1中已介绍,申购资金进场是个业务概念,并非将投资人的资金真正的转移了,只有资金在执行清算这一刻,才将投资人的资金用投资人账户划拨到目标账户上(承接人或借款人)。

设计思想2:计算策略与清算策略,计算策略是计算资金池中的哪个用户的多少资金被调拨到资产池中与哪笔债权进行配对,清算执行资金资产匹配的指令。计算策略在前、清算执行在后。

设计思想3:资金编码:每笔资金都进行编码追踪,无论是申购(投资)资金、还是回款(复投)资金,都生成唯一资金编码,也即给资金制作部家谱传代指纹,通过资金编码穿透追踪资金去向。

设计思想4:资产编码:每笔资产都进行编码追踪,无论是申请借款形成的资产、还是赎回释放的转让资产,都生成唯一资产编码,通过资产编码穿透追踪资产的核销去向。

设计思想5:资金找债权,对标示例:学校组织各班去春游,一班的学号1坐1号班车,二班学号1坐2号班车,进行遍历循环。

设计思想6:债权找资金,对标示例:学校组织各班去春游,1号班车到门口,先上一班,一班上完上二班,循环遍历。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.2.4 资金资产-清算撮合-方案设计

在研发团队“无算法工程师”的客观条件和要求“技术开发成本最低,工作量为1天”、“技术方案相对最优”的情况下,基于上述设计思想、设计原则,我整理了如下5套方案,其中方案3(绿色)为相对最优方案。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.2.5 资金资产-清算撮合-收敛推演模拟

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

后期在与行业的朋友和互金协会的律师交流我们这套方案时,给予了高度评价,大团队动用产品总监、产品经理、金融精算师、合规律师、算法工程师、架构师等历时几周讨论、再花几周构思、设计、测算、验证,最后再动用2~3周的研发测试,搞得极其唬人(美其名曰智投或AI算法)和极其复杂(维护困难)。

备注:我们预留了2个决策参数未动用,是因为体量太小,约束条件过多,最后无法完成撮合。两个未动用的参数为:投资人风险偏好、债权风险等级。如果启用这两个参数,其实也很简单,只需要增加两个约束条件即可:约束条件1:风险匹配;约束条件2:比例边界约束。

3.2.3 业务链路图3:资金赎回退出策略

3.2.3.1 赎回退出-业务链路图

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.3.2 赎回退出-关键场景抽象定义

为了很好的理解赎回退出,我们先定义两个概念,也即前面提到的“资产编码”和这里新出现的“转让赎回引擎”。有了这两个概念,下面我们分析处理“赎回”业务时就很容易有个代入感。

资产编码规则:

散标债权场景:“散标债权场景”在 发标进入资产池场景下有存在意义,散标资产编码=项目号。非转让场景:“非转让场景”在用户持有某债权,但又未发起转让场景下有存在意义;资产编码=用户持有本笔债权的交易流水号(直投场景对应直投交易流水号,转让持有对应转让交易流水号)。转让发起场景:“转让发起场景”在用户发起退出,债权按【转让发起引擎】计算对某笔债权进行退出场景下有意义;根据【转让发起引擎】,如果002资产“剩余债权”被全额输送到【资产池】,该笔资产的资产编码=002(历史转让持有交易流水号);根据【转让发起引擎】,如果002资产“剩余债权”未被全额输送到【资产池】,则输送份额的资产编码为“002+年月日8位+12位循环递增,示例:002-20181206-123456123456。

转让发起引擎:

根据上述退出策略计算用户从持有的债权上撤出的时序、撤出金额,也即向【资产池】输送债权,供【资金/资产-配对引擎】执行清算用;【转让发起引擎】每输出一个债权时,都生成一个唯一的编码,具体定义见【资产编码规则】描述;退出释放的债权价值动态变化,如果上述【转让发起引擎】输出的资产未在当日被清算完毕,“资产编码”不变、“资产本金”、“资产价值”做动态更新。

3.2.3.3 赎回退出-方案推演-逻辑提取

方案1:逐笔债权法

用户发起的退出,经过【退出预处理引擎】处理后,输出子债权包单元集,进入【资产待匹配池】,见下图:

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

方案2:债权包整体法

用户发起的退出,经过【退出预处理引擎】进行“余额冲销”预处理后,债权包剩余价值,作为一个整体,进入【资产待匹配池】,见下图:

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

很显然,方案1更合理,原因:其一:方便清算引擎未来在出借诉求T与根债权的剩余T进行函数处理,收敛交易次数;其二:方案2无法有效规避离散问题。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.3.4 赎回退出-设计思想

退出策略1:3种退出方式

    到期自动退出;用户主动退出;监管及客观不可控而有平台代为强制退出。

退出策略2:退出金额控制算法降级策略

    退出金额=出借本金-∑已退出本金,可发起退出;退出金额=当日资产价值时,可发起退出;无论上述1还是2,退出发起金额=退出到款金额(原因是,退出期间债权继续计息);上述1~3确保底层支持,前台用户端是否支持部分赎回有前台根据运营、市场需要自行控制。

退出策略3:清算时效

D+0清算:主动退出场景:退出生效的时间条件是:D+T自动生效,D指发起退出的日期,T是退出申请成功时间后移的生效周期,T=5分钟(本期);自动退出场景:退出生效的时间条件是:D+T自动生效,D指项目到期日,如3天的项目,1号计息,D指的是4号;清算时效价值:流动性吃紧时,运营自行调控T的长短规则,而不用修改程序。

退出策略4:归属原则

    用户发起退出时,退出只对该出借id所在的链条生效,也即用户如果有多个出借时,某一退出只能在限定的出借下发起;基于上述1,用户的可退出金额、退出站岗资金、退出清算等判断条件都是基于该出借id下面的资金、资产链条而定。

退出策略5:站岗资金优先退出

    A类优先级:用户发起退出时,已站岗资金优先发起退出;B类优先级:当日到期应还“总额”部分——当日是否还无法确定,具体见【退出冲销】定义:C类优先级:剩余部分从持有债权中撤出——以资产上配置的本金作为计算逻辑(详见【最接近原则退出】策略;逾期的债权禁止赎回,将风险控制在当前债权人头上,不放大风险;A、B、C顺序执行——具体见【退出执行时序说明】;赎回站岗中发生逾期,清算时自动将该债权提出资产池(回到用户持有债权明细),本债权在撤回转让前已转让部分继续生效)。

备注:如果退出站岗期间,又发生回款资金时,继续执行上述1——后果每天会到一部分。

退出策略6:退出冲销

冲销场景1:本出借下面存在“冻结余额”时自动与本出借下面的“生效退出”进行冲销;冲销场景2:当日发生本出借下面的资产标的回款时,回款金额将优先与本出借下面的“生效退出”进行冲销——也即回款金额直接回到用户可用余额,冲销剩余部分进入“冻结复投”-“复投出借池”序列;冲销场景3:【资金】与【债权】执行清算撮合时,系统自动检测目标资金所对应的用户id在该资金所归属的出借id下面是否存在【退出未清算】的任务,如有该资金与【退出未清算】进行自动冲销,剩余资金执行【撮合清算算法】——具体见【全局说明-资金债权撮合流程】流程图;退出未清算特指:已生效的退出(已满足“D+T”清算条件)但未完全退出的剩余差额部分。

退出策略7:最小本金原则退出(确保大本金剩余,进而确保平台扣服务费有足够盘面)

    退出资金X(部分退出的计算逻辑指本金,全量退出的计算逻辑指资产);站岗资金Y(每日更新值);执行退出Z=X-∑Y;Z从该用户目前持有债权中本金最小的债权先撤出;如果最小本金相同,标的结清日与当前时间段的优先级高;如果4.1中的标的到期日也相同,取债权号,债权号小的优先级高;如果上述最接近的拿回后仍不足以撤回,剩余差值继续执行3~5。

3.2.3.5 赎回退出-流动性干预机制

设计诉求:超级账户作为流动性调节器,其前台申购入口权限同普通用户,可随时进场护盘。为保障超级账户资金的自由调控性,超级账户持有的计划产品可随时发起退出,释放债权,回收本金。

设计策略:

user表增加“超级账户”参数,参数信息为:user表新增字段 super_user 0普通用户, 1超级用户;拥有超级用户身份的用户进入”PC账户中心-轻松智投-计划持有详情页”有独立的“申请退出”入口;在该入口,超级用户可随时发起赎回——赎回操作同正常赎回流程;超级用户的身份有财务部 直接提供账户,有研发人员直接在数据库 配置,不提供独立设置入口(特定有限几个人用,没必要开发独立功能)。

备注:这种方案的好处是底层逻辑通用,入口层面有运营根据市场需要随时可定制,属于典型的中台化思想。譬如后期有客户投诉或平台要清退时,运营或客服可启动该开关,方便客户随时发起赎回而无需动用产品、研发、测试资源。

备注:更多流动性调节工具及机制见第6章节。

3.2.4 业务链路图4:债权转让-资金资产交割-策略

3.2.4.1 债权转让-业务链路图

赎回是业务概念,转让是法律层面个概念,资金资产交割是财务层面概念。先有赎回,后有转让,转让与资金资产交割同时发生。赎回场景相关的服务费扣除或贴息均在清算事物进行。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.4.2 债权转让-方案推演-逻辑提取

如果我们要透彻地了解业务,依然必须把这个业务的子场景全部挖出来,研究其上下文语境及关联关系,如下为我提取整理的“债转场景”的相关概念,并对相关概念做了参数赋值,方便进行数学运算运算策略设计。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.4.2.1 化繁为简-场景切分

通过上图我们可以看出债权转让涉及的计算参数多达28组,如果转让交割方案上考虑有遗漏、设计不科学、不能化繁为简,缺乏可落地价值等,会直接把研发、测试累死。

为此,我们首先把债权价值这个概念给剥离、抽象出来,看下都涉及哪些业务场景。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.4.2.2 角色提取-分润关系推演

通过上图我们将“债权价值”抽象、切割为“本金”、“利息”、“奖励”、“折让系数”以及“还款计划发生逾期的(正常还款、部分还款)”等子部分组成,实现化繁为简,这样我们就跳过公式而讨论对象。

沿着这个思路,我们用下图向大家推演一下转让场景中涉及的角色、及分润关系。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.4.2 债权价值-配套新概念集合-逻辑推演-算法设计

用户甲通过001号收益计划持有债权A持有10天,转给用户乙(通过002号收益计划持有债权A10天)再转给用户丙,每次转让交割时,债权价值是以底层债权A计算还是用出让人的收益计划角度计算呢?

譬如当用了下述计算方案时,会直接导致我们的研发兄弟跳楼。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

当我们换为如下思路来处理债权价值时,将能极大的节省研发资源且对后面的业务维护更友好。

债权价值业务定义:

处于合规和底层清算标准一致性考虑,用户甲转给用户乙的价值以转让对象为分析根本,而不易转让时甲的应得财富计算;从借款项目约定的债权人付息计划、平台项目加息 2个角度出发,计算债权价值;债权价值=债权本金+未结算利息+未结算奖励;债权价值是“广义实时”,说明如下:昨日计算出的债权价值-今日还款变动量。

债权价值计算公式:

债权价值=昨日计算值-今日还款本金-还款利息-还款奖励;昨日计算值=前日计算值+昨日本金*(项目利率+项目加息+加息券加息)/365;昨日本金=当日22:00后持有债权本金;

有了上述“债权价值”的最简单的计算算法之后,我们仍需抽象(发明)出如下“概念组”来辅助我们(研发兄弟)去解决“债权转让-财务分润”这个工程。

尽管又硬生生地提出一撘新概念,但业务的清晰度跃然纸上,且每个概念场景均是独立的,可以解耦开发,也有利于测试校验和后期的维护更新。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.4.2 债权价值-还款核销场景-逻辑推演-算法设计

通过上述新概念的引入,我们就可以通过如下数据报表把用户A将持有的债权B转给C,以及平台的服务费和奖励等所有场景给透视出来,为下一步的资金、资产的往来穿透追踪提供底层支持。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.5 业务链路图5:借款人回款-交割分润-产品设计策略

非计划模式下,借款人还款的分润模型很简单,借款人还的钱有系统按照预先生成好的还款计划进行分润,也即借款人应得本、借款人应得息、平台应得服务费、精度差平台补偿、以及奖励下发。

计划模式下,我们面临如下一系列问题:

计划未到期,某笔持有的债权到期;计划到期持有的债权未到期等问题;复投面临无资产的资金站岗问题或部分站岗部分复投成功;一旦资金站岗,当发生多笔回款时,就出现资金合并问题;如果用户持有多笔计划,都同时发生回款且都站岗,此时我们需要额外的考虑,也即回款要所在各自的申购框架下,为用户的每一笔申购计划单独建账套。否则,无法规避合规问题。

3.2.5.1 借款人回款-交割分润-财务记账-设计原则

回款冻结策略1:归属原则

回款冻结以回款挂靠的计划为原则进行边界统计。

回款冻结策略2:派息扣除原则

回款冻结解冻复投的值是将扣除当月应派息之和后进行处理(如涉及);复投解冻后的资金经过如下三个循环进入【资金待匹配池】,并生成资金编码。利息派息引擎、退出冲销引擎、复投冻结引擎。

回款冻结策略3:连续超长站岗退出原则

复投的站岗资金在100元以上的时间连续累计超过D日(含),D初始值=30,走退出策略;退出时站岗资金全额退出——清算完毕后将剩余的复投资金全额退出(剩余金额=100元,且连续D日=100元,自动触发)。

回款冻结策略4:业务降级策略

回款遵从散标风险匹配策略,具体资金执行时按用户出借计划时的风险进行匹配(写进合同中)——这里进行了业务降级,因为投资人的风险承受能力是动态的。

冻结子场景的逻辑关系:

计划冻结=回款预冻结+出借冻结+冻结监听器+激活复投冻结;全站累计冻结=计划冻结+提现冻结+预约出借冻结。

3.2.5.2 借款人回款-交割分润-财务记账-业务链路图

通过上述冻结策略完成借款人回款的资金锁定,为后续相关流程开展提供前置保障。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.5.3 借款人回款-交割分润-财务记账-冻结复投引擎

前面章节提到,为了防止资金被无限拆分而进一步诱发的“四舍五入”精度问题,我们需要做收敛控制。

最重要的一个收敛节点就是回款收敛,为此我们在“冻结复投引擎”中引入一个“收敛监听器”概念,回款金额与已冻结的金额求和小于阀值时,自动收敛,超过阀值时,激活冻结资金到资金池中等待调用。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.5.4 清算与还款互斥锁定

清算执行时,需要关闭还款,因为还款一旦发生,债权价值发生变化,债转交易基础动摇,清算引擎的执行就会出现问题,详见下图:

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.6 业务链路图6:撤销申购、流标退款、失效退款策略

3.2.6.1 可撤销申购-时效控制-禁止逆向逻辑

资金被部分清算后禁止逆向【撤销申购】;进入【资金清算池】的资金禁止【撤销出借】,除非解冻。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.6.2 可撤销赎回-时效控制-禁止逆向逻辑

退出被部分清算后禁止逆向【撤销退出】;进入【资产清算池】的债权禁止【撤销退出】,除非解冻。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

3.2.6.3 自动流标1:未在承诺期内完成配标

    用户出借(含预约)的资金未在各自的承诺期内完成出借,过24:00,针对未配标部分进行解冻退款;基于上述1,出借退款可能是部分的。

3.2.6.4 自动流标2:承诺期外发生流标

超过承诺期后,用户出借资金中的某一部分如果发生流标了,则流标资金直接执行退款;未超过承诺期的流标,不执行退款,继续在下一轮清算过程中,进行配标;复投资金发生的流标,不执行退款,继续在下一轮清算过程中,进行配标。

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.2 申购记录-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.3 资金待匹配池-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.4 赎回记录-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.5 资产待匹配池-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.6 资金清算池待-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.7 资产清算池待-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.8 资金配标追踪-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.9 还款去向追踪-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.10 资金来源明细-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.11 赎回清算追踪-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

4.12 债权流转追踪-表结构

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

5.2 关联影响梳理、解决方法论

5.2.1 整合困难说明

上述所有关联影响中影响最大的是交易记录,原因如下:

历史交易记录是单式记账法,新的业务场景是按复试记账法,也即每笔交易从借贷两个方向记录;历史交易记录的科目只有一级,新的交易记录的科目是两级;历史交易记录的科目分类方式既有词典库分类又有前台逻辑分类(处于用户展示层考虑,把多个子分类用逻辑处理为一个分类,如各种奖励场景);历史交易记录中基本无中间状态,新的业务场景有大量的中间交易,处于合规需要,这些中间交易记录需要呈现给用户(前台隐式呈现、后台显式)和支持监管随时审查,也为了方便我们测试和分析业务。交易记录调整后必须与用户的财富值、累计收益、代收收益、累计奖励等自洽,不能出现不自洽的情况。集合计划为量化投资,交易记录会呈现指数级放大,这样会导致原有的交易记录表出现性能瓶颈。

5.2.2 涉及诉求及改造目标

本表查看用户的资金每一笔交易流动;本表可区分用户的资金进出明暗两条线:明线展示给用户,暗线不展示给用户;本表可查看用户每笔资金发生前、发生后可用余额、资产、冻结等场景的变动值;本表可查看每笔交易发生的场景、发生时间、交易对手、资金用途等;整行黑色区域为平台账户数据,不出现在交易记录表中,这里仅供方便理解;整行黄色区域为借款人数据,出现在交易记录中,会出现配套的投资人数据、平台数据,这里标记为黄色仅供开发人员理解业务逻辑。

5.2.3 改造策略及方法

数据排序:按交易时间逆序,创建越晚的id号排序越靠上;交易流水:取具体的交易流水,虚拟交易见列表定义,原则上复用交易场景的交易id,如转让交易号、复投资金编码,由于同一笔交易是有多个子项构成或者交易对手双方都出现,交易流水可能会重复出现;基于交易对手、引入参照系、发生额、变动后金额(参照系的可用余额),即每笔交易发生(真实、虚拟)均涉及两组交易,每个系统都记账,也即记录两笔账;进账用+表示,出账用-表示,进出均以参照系为中心,发生额为资金变动额,可用余额为参照系经过变动额(正负方向后)的更新值;单一出借累计冻结是指某出借id下面的所有站岗资金,集合理财累计冻结是前述多个“单一出借累计冻结”之和;数据更新:实时数据;老数据:按扩容后的表结构对号入座(清洗数据);性能处理:默认只展示最近三个自然月的数据,超过三个月走冷数据查询。

5.2.4 改造前

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

5.2.5 改造后

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

集合理财计划:资金资产撮合系统、财务分润清结算产品架构设计

以上是我们在集合理财项目中的一些实践总结,限于文采拙劣和篇幅原因,未能精细呈现,海涵,欢迎大家交流切磋!

不同的行业、不同的业务场景、不同的岗位角色,会面临不同的产品任务。但万变不离其宗,方法相通,只要我们有产品盘感、业务敏感、逻辑严谨、灵通好学、干练带风、狠下功夫,放到哪我们都一样熠熠生辉。

产品之路很艰辛,也更能锻炼人,尤其是中后台、尤其是“中后台+财务”这种大量底层的项目!在此祝广大产品兄弟姐妹们不辱“产品”之title,做出好产品!

本文由 @九天牧人 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议




阻力设计在产品中的应用

阻力设计在产品中的应用

阻力是指物体在流体中相对运动所产生与运动方向相反的力,不仅在自然间中常见,在互联网中也广泛存在。本文作者从五个角度,深入分析阻力设计在产品中的应用,希望对你...

2020-06-18
如何成为一个合格的数据架构师?

如何成为一个合格的数据架构师?

数据架构师在互联网行业中是个很重要的职位,是企业数据资产最重要的“奠基者”。那么,如何成为一个合格的数据架构师呢?本文作者基于自身经历,从三个方面展开介绍,推...

2020-06-18
倒推“抖音短视频”APP产品需求文档

倒推“抖音短视频”APP产品需求文档

文章是倒推“抖音短视频”APP产品需求文档,但由于作者是第一次写需求文档,所以仅对核心需求进行了需求分析与说明。一起来看看~ 目录: 一、文档综述 1.1文档属性 1.2产...

2020-06-18
微信“拍一拍”,真的是一个没什么用的功能吗?

微信“拍一拍”,真的是一个没什么用的功能吗?

昨天微信上线了“拍一拍”功能,用户点击2次头像,会产生头像抖动,震动反馈,且在聊天框中显示“XX拍了拍XX”。 这个功能推出后,很多微信群都在疯狂拍一拍,引起了一波拍...

2020-06-18
数据大屏设计师,我不信你没有这些困惑(上)

数据大屏设计师,我不信你没有这些困惑(上)

从事互联网行业的人,每天都在接收新知识,时常也会有迷惑的时候,尤其是数据大屏这样比较少有人踏足的领域。本文作者以自身经历出发,对数据大屏设计提出了自己的一点...

2020-06-18
客户关系管理的15个模型总结(下)

客户关系管理的15个模型总结(下)

对于ToB产品,仅仅基于用户需求来设计产品架构是远远不够的。B端产品服务的是有着几年,甚至几十年管理积淀的企业,必须依靠一定的理论知识来支撑系统的设计规划。本文...

2020-06-18
B端产品设计:价值主张与需求对应的价值

B端产品设计:价值主张与需求对应的价值

B端产品的需求来源于场景,产品经理通过满足客户需求从而产生价值。因此,SaaS产品经理面对扑面而来的需求时,应当更清晰理解并评判需求的价值。 01 2008年,著名商业...

2020-06-18
以知乎为例,探讨未来产品设计的几大变化

以知乎为例,探讨未来产品设计的几大变化

知乎作为一个典型的问答社区,它本身反映了内容社区产品的很多典型问题。本文以知乎为例,探讨社区类产品未来发展的一些变化,对内容社区感兴趣的童鞋不要错过。 前段...

2020-06-18
如何用产品思维打造线上课程?

如何用产品思维打造线上课程?

如何用产品思维来给自己打造一个线上课程呢?本文从市场调研、课程开发、运营推广、成交这几个方面分享如何打造自己的课程,希望对大家有所帮助~ “地摊经济”重出江湖,...

2020-06-18
「武侠连载」营销中心设计——优惠券

「武侠连载」营销中心设计——优惠券

优惠券是常见的一种营销推广的方式,但是你真的了解它吗?本文作者以武侠故事的形式,对优惠券展开了生动的分析,对优惠券感兴趣的童鞋不要错过哦。 (武侠情节接上文“...

2020-06-18
金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

本文作者从实际工作实践出发,结合案例等分享了电商金融支付财务融合中的基本概念和相关原理解析,包括:订单、账单、交易流水和账知识解构,供大家一同参考和学习。 ...

2020-06-18
关于卡片设计的分析与思考

关于卡片设计的分析与思考

卡片是APP常见的设计形式,它既有好处也有弊端,因此需要根据场景和内容确定展现形式。本文从四个方面对卡片设计展开分析,推荐给对卡片设计感兴趣的童鞋阅读。 卡片是...

2020-06-17
内容型产品中,付费会员功能如何设计?

内容型产品中,付费会员功能如何设计?

付费会员制度让用户预付会员费,将钱留在平台,那么未来一定会有消费行为,那么会员制度要如何设计,才能激励用户付费呢? 01 为什么要做付费会员? 讨论这个问题之前...

2020-06-16
文字社区是否可以拥有弹幕?

文字社区是否可以拥有弹幕?

从社区产品的角度来思考,弹幕功能对于内容生产方,内容消费方以及平台方而言各自有什么意义?图文内容社区是否有机会拥有弹幕呢?如果可以发弹幕,用怎样的形式呢?本...

2020-06-16
FMS财务系统收支结算总结

FMS财务系统收支结算总结

本文按照FMS收支结算划分,结算流程分类及各系统交互,财务系统内部结算基础能力,收支结算整体结构的顺序来依次介绍,总结财务系统收支结算的结构,和一些作者的个人思...

2020-06-16
如何迅速提升用户好评?试试这三种方法

如何迅速提升用户好评?试试这三种方法

小编推荐:如何提高一个产品的用户评分,改变大家对这个产品的印象呢?本文作者给大家介绍了三个概念:用户体验地图、峰终定律和服务蓝图,并详细解释了该如何使用这三...

2020-06-16
对工具型产品易学习与易使用的思考

对工具型产品易学习与易使用的思考

小编推荐:易学习是指怎么让新用户的学习成本降低,能够很快地掌握产品的使用,它的前提是足够简单和容易理解。而易使用是指,如何让用户快速、高效地完成一项任务,达...

2020-06-16
比对象还懂你!推荐算法为啥这么准?

比对象还懂你!推荐算法为啥这么准?

信息过度和广告过多的社会中,推荐算法的使用也就显得理所当然,但是它是如何做到了解用户的呢?本文从用户画像的定义和设计出发,结合实际案例,深入浅出地阐述了基于...

2020-06-15
B端平台产品需要培养的4种意识

B端平台产品需要培养的4种意识

对于许多刚入行不久的产品经理来说,B端平台产品是比较有难度的一项工作。本文作者基于自己的工作经历,提出了四点关于B端平台产品需要培养的4种意识,希望对你有帮助。...

2020-06-15
广告系列:保留价

广告系列:保留价

在一次拍卖中如果所有买家的报价均小于卖家的估价时,则拍卖品不出售由卖家保留,此时卖家的估价就是保留价,也叫底价,全称市场保留价。对于卖家来说,保留价的设置保...

2020-06-15