解析「三户模型」及建立账户模型

正文

　　账户体系是支付系统的基础，它的设计直接影响整个系统的特性。这里探讨如何针对电子商务系统的账户体系设计。我们从一些基本概念开始入手，了解怎么建模。

1 三户模型

　　三户模型最早是在增强型电信运营图（Enhanced Telecom Operations Map，eTOM）中提出，在电信行业中得到广泛使用。 三户指客户（Customer）、用户（User）和账户(Account)。eTOM 引入是电信行业营销模型转向“以客户为中心”的理念而产生的成果。围绕客户建立用户和账户，这三个是相互关联的实体。近年来，金融行业也逐步接受和采用了三户模型。

• 客户，指自然人或者法人。法人一般被称之为企业客户。如无特指，一般客户指个人客户。
• 用户，指通过注册的方式进入系统，使用系统提供的服务的实体，也称为登录账户，即用户在系统中登录凭证和个人信息。对应的，法人客户在系统中注册后，被称之为商户。
• 账户，这里特指支付账户，指用户在支付系统中用于交易的资金所有者权益的凭证。

2 客户

2.1 个人客户

　　在银行体系中，一般是先有客户，再有用户。早期个人客户通过柜台人员操作注册到银行体系中，柜台人员在处理时，先添加客户信息，再注册账户信息。而在互联网系统中， 一般是用户先注册，先有用户，然后补充客户身份信息。也就是客户身份信息是在运行过程中逐步完善的。在银行柜台，操作人员通过面签或实名方式在系统中建立客户对象。这个对象的业务主键是证件号（如，身份证，假设目前 18 位证件都不重号），所有相同证件我们都视为同一个客户，不论是不是同一个系统中。同一个证件号，不论在工行还是中行，开出来的客户，其实都对应着现实中的同一个人。

　　在一个平台体系中，通过系统给客户分配的唯一 ID 号客户 ID 来标识客户对像。这里面就有一个关键业务，既然相同证件都会识别成一个客户，那么当相同的证件号进入系统时，系统是如何处理的？当然是合成一个了，这个过程叫做客户归并，即：将相同证件的客户合成同一个客户号的过程，我们称为归并。归并是有风险的，所以需要一些鉴权手段来处理。在互联网应用中，一个系统中客户的生命周期如下：

注意在这个流程中没有销户的状态。这是为了支持历史业务的处理，客户一般不做销户。此外这个流程和支付账户的流程比较类似，这是为了方便在客户层面做账户控制。以司法协查为例，某个客户被协查以致账户冻结，需要冻结该客户下所有资金账户，这些账户都被止付。

2.2 企业客户

　　企业客户相对个人客户来说比较复杂点，但三户模型仍然适用。同个人客户一样，企业客户在银行或支付平台开设资金账户，资金账户归属于此客户。企业客户是一个组织，其账户必然是组织授权内部人员去操作。但是这个操作人，同个人客户一样，只是系统的使用者，即用户。企业的资金比较大，并且有严格的业务流程，所以在系统使用上，一般是多个用户操作一个或多个资金账户。这种关系本身来说，也是一种授权关系，企业授权相应的用户来操作特定的资金账户，只不过为了管理方便，可以引入角色管理机制来实现。对于支付公司来说，企业客户通常都是发展商户过程中产生的。企业客户的识别同个人客户识别也是一样的，通过企业证件来统一识别。相同的企业证件号归并到同一个企业客户下面。建立企业客户的好处在于：

• 有些企业本身只开通了企业服务业务，而不开通商户服务；
• 一个企业可以开通多个商户，企业客户是这些多个商户的统计口径。

2.3 客户模型

　　对客户的处理，在银行系统中是 CIF 系统或 ECIF 系统，而在互联网模式下，很多都是基于微服务的体系，如何划分微服务，这块要从客户系统对提供的业务主题来分。比如：对于个人客户，客户识别就是一个服务主题，对于一个客户有多种多样的识别方式，除了证件外，还包括生物识别，比如画像、指纹等。

• 基本信息也是一个服务主题：包括客户的最基本的信息，姓名、年令、职业等;
• 管理信息也是一个服务主题：比如这个客户的评级、是否集团员工等；
• 客户标签也是一个服务主题：所谓标签，就是从不同的维度来给客户做个标记，一个客户有多个标签，当然，前提是要对标签做好规划；
• 协议管理也是客户的一个服务主题：这里面有授权协议、委托协议等。

当然，客户还有其它的一些主题，这个要看公司的业务了。

3 用户和商户

3.1 用户

　　用户是账户的操作实体，它是由客户来注册到系统中来的。虽然用户通过客户间接的拥有了资金账户，但这种关系并不是绝对的，比如，一个用户可以授权另一个用户进行账户的余额查询。所以，用户与资金账户之间我们可以抽象出一种授权关系，凡是授权用户，都可以操作资金账户，当然，这种授权包括客户自己的用户。用户的建立比较简单，一般自助注册后就可以生成用户实体了。用户的生命周期如下：

　　如果用户通过简易注册方式生成，这种情况下生成的是个预开户状态的用户，用户需要进一步完善一些信息才能变成正常用户，比如有些平台，在用户第一次登录时要求设置密保问题及答案。如果用户采用标准注册方式注册 的，可以直接成正常状态用户，正常做业务了。

　　如果用户想要销户，收到销户申请后，不能直接销户，前面我们说过了，客户是通过用户来进行资金账户的管理与操作的，没有用户，资金账户就有可能没法玩了（假设客户只授权自己的一个而且只有一个用户来操作资金账户），特别是一些账户还存在债务。所以，此时有个确认过程，要求各业务系统确认此用户下的所有账户是否可以销户，如果没有问题，先销资金账户，当用户下的所有资金账户都销户完毕，再销用户，用户销户完成后，会释放出此用户占用的资源，如注册手机号。

　　用户除了生命周期状态外，还有一个管理状态，比如冻结，从现实模型中来说，这个是不应该放在用户层面的而是放在资金账户层面上的，但互联网模式下，一个用户有多个资金账户，为了用户体验，把这些放在了用户层面上了，就如同支付密码放在用户层面上一样。

3.2 商户

　　商户是企业客户的一个业务影子，或是看成资金账户分组的一个手段。商户是客户一个外围业务，如果把它看成用户平级层面也是可以的，即：此商户所有业务产生的资金进入到一个分类资金账户里。不论怎么说，一个企业不论开多少个商户，每个商户又开通多少个资金账户，都改变不了资金账户的归属关系，它是现实客户这个实体的。对客户的处理，在银行系统中是 CIF 系统或 ECIF 系统，而在互联网模式下，很多都是基于微服务的体系，如何划分微服务，这块要从客户系统对提供的业务主题来分。

4 账户

4.1 基本概念

　　账户设置，一般是从交易开始的。交易的实现必须有账户的支持，账户是交易的基本构成元素。从支付系统的角度，交易中涉及到的资金流是资金从一个账户流向另一个账户。发起交易的一方，被称之为交易主体，他可以是个人，也可以是一个机构。资金从该主体所拥有的账户中流出。而接收交易的一方，被称为交易对手，他也可以是个人，或者机构。和第三方支付或者金融机构的交易不同，电商系统中，交易还会涉及到渠道。由于电商系统本身并无清结算的资质，所有资金从交易主体到交易对手的账户的流动，在大部分情况下，并没有经过电商系统，而是由电商系统调用支付渠道提供的接口，由它来完成真正的支付过程。当然，渠道也不是活雷锋，在这个过程中，渠道要收取费用。所以，在电商系统中，一次交易会涉及到三个账户： 交易主体账户、交易对手账户以及支付渠道账户。

支付账户和登录账户

　　账户体系设计首先要区分两个概念，支付账户和登录账户。这是两个不同业务领域的概念。支付账户指用户在支付系统中用于交易的资金所有者权益的凭证。登录账号指用户在系统中的登录的凭证和个人信息。一个用户可以有多个登录账户，一个登录账户可以有多个支付账户，比如零钱账户，储值卡账户等。 一般来说，支付账户不会在多个登录账户之间共用。如果没有特殊说明，下文中的账户，都默认指支付账户。

会计科目与账户

　　公司的会计需要对每一笔交易都要做详细的记录，即记账。公司每天都产生大量的交易行为，为了便于管理和统计，一个简单的方法是对交易进行分类，比如食品、带宽、办公用品等等。这个分类，按照公司的规模和业务复杂度，可以有一级、二级、三级或者更多级的结构，这被称之为会计科目。记账时，除了交易明细，还需要在每个级别上对交易额进行汇总。 一般来说，一级科目上汇总称为总帐科目，而详细记录称为明细科目。在电商系统中，由于涉及到的参与方较多，记账也相对复杂，但基本方法也是类似的。电商的参与者可以分为商户、买家和渠道，对这三类参与者，都需要分别建立总帐账户和明细账户。

内部账户和外部账户

　　当用户使用银行卡来支付时，电商支付系统需要和银行对接，从用户银行卡所代表的账户上扣除资金。对接了银行，第三方支付等机构的电商支付系统，它需要连接到用户在这些机构的账户来执行扣款或者充值操作，这些账户称为外部账户。对外部账户，支付系统只能记录账户在本系统的明细以及累计消费额，无法得知账户真正余额。不少电商在玩零钱的概念，也就是让用户充值到零钱，使用的时候就直接从零钱中扣除。这就需要零钱账户。这是电商系统中自己设立的账户，所以也叫内部账户，可以知道账户的全部消费明细和余额。当然，除了零钱账户，也可以有储值卡账户、信用账户等。那问题来了，什么时候需要建立账户，比如优惠券，需要账户吗？一次消费的储值卡和可以充值的储值卡，需要建立账户吗？这里先埋个雷。

收款账户和收单账户

　　当电商要对接银行时，往往都会被要求开设一个收款账户。用户通过这个银行来支付时，钱就被转到这个账户上。对第三方支付也是一样。收款账户是开设在银行或者第三方支付这边的，即渠道侧。一般来说，渠道每天都可以提供这个账户的交易流水供电商对账用。这样在电商这边，渠道就成为一个收单机构。所以在电商这边，建立这个收款账户对应的对账用的收单账号，用来记录通过这个渠道进行的各项交易流水。

4.2 三类账户

　　在设计支付账户系统时，合规是第一要求，和账户相关的法规，最重要的是近期央行发布的三个文件。 从 2013 年 3 月起，国家相继制定一系列“互联网+”计划，推动了移动互联网、大数据等与现代制造业、服务业相结合，引导企业转型，促进经济健康发展。在此背景下，央行相继发布了三个文件：

• 「中国人民银行关于改进个人银行账户服务加强账户管理的通知」，银发〔2015〕392 号，2015 年 12 月 25 日发文，正式启动账户分类管理工作。
• 「中国人民银行关于落实个人银行账户分类管理制度的通知」，银发〔2016〕302 号, 2016 年 11 月 25 日发文，明确了同一个人在同一个银行只能有一个I类账户的要求。
• 「中国人民银行关于加强支付结算管理防范电信网络新型违法犯罪有关事项的通知」，银发〔2016〕261 号， 2016 年 9 月 20 日发文，调整并细化了账户分类及使用要求。

在这些文件中，央行明确对账户实施分类管理的要求。 对这三类账户区别，总结如下：

4.3 生命周期

• 账户开立与绑卡：同一个人在同一银行只能开立一个Ⅰ类户，I类户的设立需要面对面审核，电子渠道开立的Ⅱ类户和Ⅲ类户需绑定银行账户进行验证，不得绑定支付机构账户验证，Ⅱ类户需向绑定账户验证5要素（4要素：姓名、身份证号、手机号、银行卡号，额外增加账户等级），Ⅲ类户需验证4要素，银联支持支持Ⅱ、Ⅲ类账户跨行验证绑定账户信息。
• 资金互转：对非面对面开立的Ⅱ、Ⅲ类户，限制非绑定账户转入，允许Ⅱ、Ⅲ类户向绑定账户直接借记资金，银联支持Ⅱ、Ⅲ类账户与绑定账户间通过借记和贷记业务实现灵活便捷的资金划付。
• 账户使用：I类账户、对面核实身份的Ⅱ类户可以发行实体银行卡，其他账户不能使用实体银行卡，Ⅱ、Ⅲ类户可以通过云闪付、二维码等支付工具来完成支付，银联支持Ⅱ、Ⅲ类账户便捷生成基于安全芯片、主机卡模拟或二维码等技术的支付工具。

4.3 账户建模

在支付系统中，账户的建模，主要是从如下几个方面来考虑：

• 交易的需求，比如检查账户是否被锁定、余额是否足够、是否有效等。
• 记账的需求，按照公司会计需求记录账户上的所有行为，包括支出、充值、转账等。
• 对账的需求，包括和支付渠道、商户、个人的对账需求，核对交易和账户余额是否正确。
• 风控的需求，如反洗钱、反欺诈等，都需要依赖于账户体系来提供核心数据。
• 信用的需求，对用户、资产、商户等主体进行信用评估时，也需要依赖账户体系来提供的核心数据。

这五个需求，按照其设计的优先级，也是从支付、记账、对账、风控来进行。 支付系统根据其发展所处的阶段，逐步将新增需求纳入设计中。说了这么多，目的是为了对账户建模。账户模型是和公司业务密切相关的，公司不同规模，发展的不同阶段需要不同的模型。从交易模型中可以衍生出针对各个角色的账户流水，即明细模型，用于支持对账。根据业务需要，可以设置多种账户，如支付账户、预付卡账户、代扣账户、零钱账户、结算账户等。从类别上来说，这里的账户，一般指总账账户。一般来说电商系统中涉及的账户类型有：

• 虚拟币账户：用户和使用虚拟币的商户都需要建立虚拟币账户；
• 代扣账户： 用来支持订阅类型的定期代扣；
• 零钱账户：电商的内部账号，用户、商户、清算单位需要建立零钱账户。
• 第三方支付账户：用户在第三方支付机构建立的账户。
• 银行卡账户：用户的银行卡信息，每个卡对应一个账户。
• 结算账户：用来支持和第三方支付公司、银行进行结算用，第三方支付需要为每个商户号建立结算账户；银行需要为借记卡、贷记卡分别建立结算账户，一般在银行卡直连时使用。
• 代扣代缴账户：用来支持代扣税款业务。

对这些账户，需要设置如下属性，基本属性，包括：

• 账户号或称为账户 ID，一般是系统自动生成。特别注意的是，要事先约定好账户 ID 的规则，比如头三位用来表示账户类型，后几位用来表示账户编号等，务必保证根据账号号能够快速确定账户类型，并且保证账户号是不重复的。
• 账户名称，一般是由用户自己设置的，显示用。
• 账户使用的货币类型，注意虽然一张银行卡可以支持多个币种，实际在内部，还是针对每个币种建立独立的子账户。涉及到多币种的账户，也可以采用类似的建模方案。
• 会计科目代码，一般是一级会计科目的代码。

账户控制相关：

• 是否允许充值；
• 是否允许提现；
• 是否允许透支；
• 是否允许支付；
• 是否允许转账进入；
• 是否允许转账转出；
• 是否有安全保障；
• 是否激活；
• 是否冻结。

资金相关：

• 当前账户余额，等于可用余额+冻结余额；
• 当前账户可用余额；
• 当前账户冻结的余额，冻结余额指在账户上暂不能使用的额度。在支付的时候，往往是先冻结，商品出库后，再实际执行扣款。

银行卡、第三方支付信息：

• 第三方实体的 ID；
• 第三方账号，如银行卡号或者在第三方支付的open_id等；
• 第三方的app_id；
• 账号的失效日期，该账号什么时候失效。

注意，有些第三方信息是不能保存的，如用户的账号密码、信用卡的 CV 号等。为了避免账户信息被爬库或者数据库信息意外泄露，一般还需要对敏感字段，如密码等，进行加密保存，甚至保存到另外的表中。更进一步，为了避免账户信息被意外修改，还可以增加一个校验字段，在写入数据时设置该字段，在读取数据时做校验，一旦发现数据有问题，则关闭该账号。

---

转载声明：本文转自个人博客「凤凰牌老熊」，三户模型。