接下来我们看下个人与企业在这个模型下的应用。先说个人，我们在系统中通过面签或实名方式在系统中建立客户对像，这个对像的业务主键是证件号（如，身份证，假设目前18位证件都不重号），所有相同证件我们都视为同一个客户，不论是不是同一个系统中。
比如：同一个证件号，不论在工行还是中行，开出来的客户，其实都对应着现实中的同一个人。在一个平台体系中，通过系统给客户分配的唯一ID号客户ID来标识客户对像。这里面就有一个关键业务，既然相同证件都会识别成一个客户，那么当相同的证件号进入系统时，系统是如何处理的？当然是合成一个了，这个过程叫做客户归并，即：将相同证件的客户合成同一个客户号的过程，我们称为归并。归并是有风险的，所以要用一些鉴权手段来处理，这个我们后面再说。
在银行体系中一般都是先有客户再有用户，在互联网支付体系中，一般都是通过用户自主注册，先有用户，用户再通过补充身份信息完成客户的建立。最常见的就是通过快捷绑卡，进行实名认证后，会产生客户实体。
用户除了生命周期状态外，还有一个管理状态，比如冻结，从现实模型中来说，这个是不应该放在用户层面的而是放在资金账户层面上的，但互联网模式下，一个用户有多个资金账户，为了用户体验，把这些放在了用户层面上了，就如同支付密码放在用户层面上一样。
客户为什么不能销户，是因为客户是现实生活中活生生的人或组织，即使没有业务了，也有历史业务。
这个模型有一点问题，和用户模型是一样的，也就是将一些本应是资金账户层面上的控制，放在了客户层面上，还是回到那个用户体验，模型所示，因为一个客户有多个用户，一个用户有多个资金账户，如果要对同一个客户下所有资金账户进行控制，有点复杂，所以在客户层面上做了控制，在用户进行操作时，要进行一些客户级的验证，比如：此客户已经被司法冻结了，则此客户下所有账户都应该是止付的。
一些折衷的东西，就是只是策略了，大家在设计时，可以自由发挥了。通过客户、用户、资金账户这三层关系，我们基本上可以支撑起个人客户的支付业务了。
商户本是企业客户的一个业务影子，或是看成资金账户分组的一个手段。商户是客户一个外围业务，如果把它看成用户平级层面也是可以的，即：此商户所有业务产生的资金进入到一个分类资金账户里。不论怎么说，一个企业不论开多少个商户，每个商户又开通多少个资金账户，都改变不了资金账户的归属关系，它是现实客户这个实体的。
所以，不论个人客户，还是企业商户，都脱离不了上面的三户模型。
对客户的处理，在银行系统中是CIF系统或ECIF系统，而在互联网模式下，很多都是基于微服务的体系，如何划分微服务，这块要从客户系统对提供的业务主题来分。
比如：对于个人客户，客户识别就是一个服务主题，对于一个客户有多种多样的识别方式，除了证件外，还包括生物识别，比如画像、指纹等。
这里我列了一些常用到的主题，有些主题可能相同或相近，这是因为这类主题内容比较多，分类可能会更好的管理。用户层面的微服务划分就比较简单了，主要就是用户协议服务、身份鉴权、信息管理这三大类了。微服务的实现离不开数据库的设计，即数据分布与存储形式，这部分就可以自己灵活处理了，可以分库也可以不分，但由于客户信息是一个读写相对不平衡的系统，以读为主要业务，所以在数据库上设计时要考虑读写分离，或缓存技术。
Q：一账通是不是也可以理解为客户的归并啊A：一账通算不上客户归并，只能算是账户打通
Q：张老师，请问账户或账号系统设计时，手机号二次放号有无较好的处理机制呢A：二次放号目前的处理都是个难题，如果原用户已经注销，此手机号可以释放，否则的话，只能做一些人工处理。Q：手机号二次放号问题，再补充下条件，特别针对银行账户和用户账号设计，普通互联网公司与银行的监管需求不在一个级别
Q:商户只能是企业用户吗？
Q：集团企业下有很多个分支机构，集团企业算一个客户，不同的分支机构算不同的用户，这样理解对吗？A：集团下的分支机构，要看是不是具有独立法人，如果是则可以看成客户。Q：OK，明白，对于商户的状态变更是否也是通过用户去管理？A：是的，因为对于商户的管理肯定是通过用户来完成的，不论是管理员还是操作员，都是用户
Q：目前的监管，你们商户下分几个资金账户？A：对于商户，我们不设资金账户，都是平台虚拟账户，直接结算到商户在银行的账户里
Q：有做过实体商户和实体客户关联方面的设计吗？现实中某些个人和某些商家有关系，这个关系有在系统层面支撑的么，A：你说的应该是个人客户与企业客户的这种关系吧Q：嗯A：这个是客户与客户的关系，是没有问题的，
Q：归并的风险主要是确定是否是同意客户把？还有其他风险么A：客户归并的最大的风险就是身份冒用，当然，你不经过用户同意，就去归并，这也是一个风险。
Q：你说的虚拟账户其实也是资金账户吧，比如收单的结算账户，用来做代发业务的一般账户。你们分开的么？还是共用一个虚拟账户？A：分开的
Q：之前那问题，结算账户转一般户新监管算违规的吧？A:应该不违规吧，只是债权晚点偿，只要有协议Q：不开虚拟户，那的按笔结算啊。A:归集走协议代扣S:怎么说？虚拟账户开是为了日终再结算？我们银行也想做跨行代扣，之前去人行说了，没同意哈。三方怎么真么厉害，可以从不同银行拿到对公代扣～Q：不开必须每笔单独结算，按交易每笔结算到银行账户
A:这样啊，如果不只是在线业务，就要走账务总账的账实核对，有个银行日记账A:线下业务也要通过凭证传入会计系统S2:做这东西说白了就是校验银行给的业务明细和资金变动明细是否一致。A:资金变动在会计系统中有S2:银行的S2:业务明细和资金明细A:银行的肯定和你会计系统的实体业务要一致A:银行的要和你的对，不是银行自己和自己对S2:举个例子吧，银行返回失败，实际出款成功，无业务明细，有资金明细A:资金管理平台对账，其实就是账实核对，即你系统的银行日记账和银行记账单核对，你的银行资金明细要和你的会计系统的银行日记账勾兑，对于资金无非就是借贷，这种情况不就是日记账少账了？通过业务补账就行了。
##自由讨论
3、分布式：安排部分IT开发人员，前置到对IT依赖度高的互联网、客服和电销中心等部门。好处：第一线战斗，听得到炮火，效率高。问题是业务部门的领导因对技术掌握有限，无法在专业技术方面进行指导；IT人员进入到某一业务部门后，其流动受到一定限制，容易对未来的职业发展产生困惑。
单纯集中式和分散式都有问题，就好比集中还是民主一样，应该是一个集中下的民主。对于战略，架构，规范一定要集中，而对于实现技术可以自由发挥，以实现灵活的业务支撑总之，精简放权要敏捷，但必须是在章法内，也就是在精益基础上。这和devops是一致的。这种管理模式都是根据理想模型建立的，实际操作中需要根据公司的情况进行调整。毕竟每个公司都有自己的特色。万变不离其宗，现实已经有活生生的例子:中央只提发展纳要，指导意见，监管政策，地方省市可以灵活机动。调整也是对的，世界上没有完全一样的树叶，管理上也是一样。
哪位能给普及下，从银行账户性质（对公对私）上发生的支付行为，各个方面的要求、限制、规定、方式等？1、公对公收付款2、公对私收付款3、私对公收付款4、私对私收付款？公对公收付有柜面传统结算、网银和b2b等，这里指除了票据类的传统结算方式。
“对于加入银联互联互通合作机制的银行客户，只需在任意一个银行拥有一个Ⅰ类户，就可在其他银行手机银行、网络银行等各类渠道随时、随地在开立Ⅱ、Ⅲ类账户”这句话怎么解读如果我在A行开了一类户，在B行手机银行可以直接开立二类户，然后B行通过银联网络去A行鉴权。那这样B行如果有自己的电子账户系统，岂不是浪费了？