前段时间，终于完成了两个 P2P 平台的银行存管设计，总算可以歇一下了。今天对工作做一个复盘，对P2P 流程设计进行一个梳理。
「流程分析」主要分为「业务流程」和「页面流程」。「业务流程」（Transaction Flow）是通过产品经理在业务调研的基础上，对相关业务点进行梳理并链接呈现的过程，更多用来与后端开发同事对接业务逻辑。「页面流程」（Page Flow）则是前端用户界面跳转的展现，更多用来与 UI 设计师、前端工程师沟通。本文的「流程分析」主要从「业务流程」这个方面对 P2P理财端核心流程进行分析。
P2P 理财端业务的核心流程
应该这么说，对于 P2P 平台来说，功能模块并不复杂（如果你非要在 P2P 平台上加一个社交/电商/即时通讯，这就不在我们讨论的范围内了）。其核心是「投资赚收益」，核心业务就是「投资」和「资产管理」。我们就主要从「投资」的角度去梳理下其在银行存管系统下的业务流程。
在设计业务流程的时候，一般有两种展示方式：1.是单纯的用户操作行为流程图，这种图一般只涉及用户角色，不涉及跨部门或者跨功能的业务展示。2.是泳道图，这种图按照职责或功能将活动进行组织，可以直观的描述整个系统中的各个子系统或者各活动之间的逻辑关系，便于使用者理解业务逻辑，适合跨部门或跨功能的业务展示。本文将主要以泳道图来为大家展示。
设计基于银行存管系统的 P2P 平台时，有一个作弊码：信息流在平台，资金流在存管。记住小璋的这「十二字真经」（不知道是不是原创，如有雷同，纯属巧合）理论上可以应对各家银行的存管系统。不多说先上图：
本流程主要以投资用户在平台的操作流程（「用户注册并实名开户」-「充值」-「投资」-「提现」）作为分析的重点，这个流程也是整个平台对接存管系统变动最大的地方。
用户注册并实名开户：
这里需要关注的有三点：
- 用户需要在业务系统（即平台）和存管系统（即银行）分别开立账户，开立存管系统账户的活动可以隐藏在实名绑卡的步骤中来完成，一般情况下，这一步骤需要跳转银行的页面来完成。也有部分银行彻底将所有业务的步骤均隐藏在平台的页面内，全部数据通过接口方式传递（平台—>银行），在一定程度上提升了体验，可以做到用户的「无感知」，但是也容易引起用户的怀疑：你究竟做没做存管？不同的银行有不同的考虑，这一点上来看，并没有绝对的优劣。
- 实名信息的认证，同样，不同银行有不同的认证方式。有的银行依托公安机关的户籍系统（比如使用「国政通」），仅需进行身份认证即可完成开户，开户完成后在由用户进行出入金借记卡的绑定。另外一些银行直接利用合作的支付通道来通过银行卡四要素（或三要素）认证，来完成出入金借记卡的绑定。
- 途中将返回结果合并成一个（实名开户和绑卡结果一起返回），但在实际业务中，可能有多种情况，甚至还有需要平台主动查询的可能，需要产品经理根据存管系统接口实际来设计。
充值
说完开户，用户就该充钱了。这是一个平台运营者最激动的时刻（满眼的小钱钱），毕竟只有用户资金进入，这个平台才能真正的运转起来。
这里需要关注的有两点：
- 判断是否绑卡的步骤需要根据存管系统要求来设计，我遇到过有的银行并不会给平台返回用户是否绑卡（对，你没看错）的信息，那么这一步就会有存管系统来判断，业务系统只需要进行「充值转发」就可以了。当然如果提前在业务系统里进行判断，用户没有绑卡直接跳转绑卡页面，或提示用户绑卡。这样的流程比较流程，体验上也比较好。
- 大家可以看到，在流程图中，不管充值成功还是失败，业务系统都会进行记录，这一点也需要注意，不但可以为用户提供更详实的展示外，一旦出现账务处理异常也可以很方便的去排查。
投资
用户开完户，充完钱，我们一定要让他花出去！那就涉及到「投资」流程了。这也是整个业务中「核心中的核心」（张老师敲小黑板，注意听讲啦）！
这里有一点注意：
- 标的可投的校验：为了防止出现溢标（就是投资额超出实际需要募集的金额）的状况，一般情况下，需要两次以上的校验——前端根据可投额度校验一次，对大于可投金额的资金直接提示；后端在收到前端传过来的值后，在进行一次校验。双保险，更安全！之所以说是两次以上，是因为存管系统可能还会对标的实际募集金额进行校验，有的银行不允许溢标，有的银行又允许溢标。不过从实操和法律规定上来看，不溢标会好一些。其实在未收到结果时先减少可投余额，再根据结果反馈进行调整和最后当「可投金额=0」时变更标的状态，同样也是为了防止溢标。
提现
用户投完资，标的也到期正常还款了。理论上就应该进行下一步了，也是作为产品和运营最不想看到的一件事（你们看到我的泪了么？每天就想着怎么不给用户钱，呸，怎么能不给钱呢。我们是想让用户复投，不提现……）。但是最终用户还是要提现的，真不让提现那不是诈骗或者抢劫了么，张小璋一直是遵纪守法的好公民！
这里需要说明的两点：
- 因为我们的系统经历了「支付通道」—>「第三方支付托管」—>「银行存管」的变更，所以在提现审核之后立刻就减少用户资金记录后期在根据反馈结果进行调整的做法是个历史遗留的问题，主要是在支付通道的时候防止用户在操作之后结果反馈之前的时间内（可能很短，也可能很长），利用时间差不断提现，造成不必要的资金损失。其实大家可以理解成在没有记过之前先冻结掉提现金额。
- 业务系统的提现审核，这一步其实在存管体系下的作用越来越小，毕竟资金在银行。不过为了用户安全，还是可以根据业务需要由平台相关业务人员或者业务系统进行一次提现审核。还是那句话：双保险，更安全！
另外两个重要的地方
上边的四个步骤基本涵盖了用户的在平台的「全生命」流程，但是对于平台来说，参与到这个流程中还需要两个重要的步骤：「标的管理」和「还款」
标的管理
「标的管理」又分为「标的发布」和「标的成立和出账」两块。一般情况下，「标的发布」时，存管系统介入较少，仅需要「业务系统」将标的的信息传递给「存管系统」进行存储。而「标的成立和出账」因为涉及到资金操作，所以会较多的涉及存管系统。废话少说，上图：
这里需要说明的两点：
- 流标流程是一个单独的流程，但是一般平台上用的几率不是很大。在这里不细说，其实就是解冻用户资金，并原路返还，这标的废掉的一个流程。
- 开始计息的时间：这一点大家可以根据自己的业务实习来处理。有投资后计息、标满后计息和图中表示的出账后计息多种。
标的还款
回款会涉及到正常还款、提前还款、垫付和逾期。以正常还款为例。
这里有一点需要注意：
- 借款人还款的时间：因为银行清结算需要时间，所以借款人还款时间一定要早于最晚的标的还款时间，不然会有极大的可能造成因银行清结算延误造成标的逾期。
最后要说的话
不知道大家有没有注意到，我画的流程图中反复用到一句话：记录结果并返回给用户。这可不是我偷懒，在「存管系统」中业务平台仅仅作为信息流的记录者，并不实际操控资金流。甚至你完全依赖银行存管系统的记录也是可以的（比如我就这么干过……）。但是平台最好还是有一份记录，不但可以帮助运营同事通过数据去分析用户，更重要的是这些数据是账务系统中用来对账重要数据。
嗯嗯嗯，我现在正在想之后写什么？不过现在已经有了选题。写点湿货，大（zhuang）气（bi）一点，不在这么局限于业务层。也是最近和一个朋友在一起讨论一件很复杂很费脑筋的事后的一点想法。欢迎大家继续关注。没事点个赞啥的。