主题分享：支付清结算流程简介
我们开始吧，先介绍一下自己，主要做第三方支付，支付做了五年，以前在联通支付做架构。现在民生金服负责基础架构，下面正式开始：先说一下这三个的概念：
客户其实就是一个活生生的人或组织，用户可以看成客户在系统中的一个使用者影子。它们之间的关系如下图所示：
一个客户可以拥有多个用户，比如，我有多个手机号，可以用手机注册多个账号，这里的手机号只是用户的一个标识，并不是用户。我们前面说过，客户是现实中的人或组织，那么资金账户也是归属于现实中的人或组织，所就是所有权属于客户，在图中我们标识一个客户可以拥有多个资金账户。用户是账户的操作实体，虽然用户通过客户间接的拥有了资金账户，但这种关系并不是绝对的，比如，一个用户可以授权另一个用户进行账户的余额查询。所以，用户与资金账户之间我们可以抽象出一种授权关系，凡是授权用户，都可以操作资金账户，当然，这种授权包括客户自己的用户。
接下来我们看下个人与企业在这个模型下的应用。先说个人，我们在系统中通过面签或实名方式在系统中建立客户对像，这个对像的业务主键是证件号（如，身份证，假设目前18位证件都不重号），所有相同证件我们都视为同一个客户，不论是不是同一个系统中。
比如：同一个证件号，不论在工行还是中行，开出来的客户，其实都对应着现实中的同一个人。在一个平台体系中，通过系统给客户分配的唯一ID号客户ID来标识客户对像。这里面就有一个关键业务，既然相同证件都会识别成一个客户，那么当相同的证件号进入系统时，系统是如何处理的？当然是合成一个了，这个过程叫做客户归并，即：将相同证件的客户合成同一个客户号的过程，我们称为归并。归并是有风险的，所以要用一些鉴权手段来处理，这个我们后面再说。
在银行体系中一般都是先有客户再有用户，在互联网支付体系中，一般都是通过用户自主注册，先有用户，用户再通过补充身份信息完成客户的建立。最常见的就是通过快捷绑卡，进行实名认证后，会产生客户实体。
用户的建立比较简单，一般自助注册后就可以生成用户实体了。我们先看看一个用户在系统中的生命周期
如果用户通过简易注册方式生成，这种情况下生成的是个预开户状态的用户，用户需要进一步完善一些信息才能变成正常用户，比如有些平台，在用户第一次登录时要求设置密保问题及答案。如果用户采用标准注册方式注册 的，可以直接成正常状态用户，正常做业务了。
如果用户想要销户，收到销户申请后，不能直接销户，前面我们说过了，客户是通过用户来进行资金账户的管理与操作的，没有用户，资金账户就有可能没法玩了（假设客户只授权自己的一个而且只有一个用户来操作资金账户），特别是一些账户还存在债务。所以，此时有个确认过程，要求各业务系统确认此用户下的所有账户是否可以销户，如果没有问题，先销资金账户，当用户下 的所有资金账户都销户完毕，再销用户，用户销户完成后，会释放出此用户占用的资源，如注册手机号。
用户除了生命周期状态外，还有一个管理状态，比如冻结，从现实模型中来说，这个是不应该放在用户层面的而是放在资金账户层面上的，但互联网模式下，一个用户有多个资金账户，为了用户体验，把这些放在了用户层面上了，就如同支付密码放在用户层面上一样。
账户就比较复杂了，各种账户，我们这里一直在说资金账户，是为了简化模型，原理都是一样的。客户也是有生命周期的，我们只说一下互联网方式下，由用户实名创建客户的流程。
客户为什么不能销户，是因为客户是现实生活中活生生的人或组织，即使没有业务了，也有历史业务。
这个模型有一点问题，和用户模型是一样的，也就是将一些本应是资金账户层面上的控制，放在了客户层面上，还是回到那个用户体验，模型所示，因为一个客户有多个用户，一个用户有多个资金账户，如果要对同一个客户下所有资金账户进行控制，有点复杂，所以在客户层面上做了控制，在用户进行操作时，要进行一些客户级的验证，比如：此客户已经被司法冻结了，则此客户下所有账户都应该是止付的。
一些折衷的东西，就是只是策略了，大家在设计时，可以自由发挥了。通过客户、用户、资金账户这三层关系，我们基本上可以支撑起个人客户的支付业务了。
下面说一下企业客户，企业客户相对来说比较复杂点，但三户模型仍然适用。同个人客户一样，企业客户在银行或支付平台开设资金账户，资金账户归属于此客户。企业客户是一个组织，其账户必然是组织授权组只内有人去操作，但是这个操作人，同个人客户一样，只是系统的使用者，即：用户。企业的资金比较大，并且有严格的业务流程，所以在系统使用上，肯定是多个用户操作一个或多个资金账户。这种关系本身来说，也是一种授权关系，企业授权相应的用户来操作特定的资金账户，只不过为了管理方便，可以引入角色管理机制（RBAC模型）来实现。对于支付公司来说，企业客户通常都是发展商户过程中产生的。企业客户的识别同个人客户识别也是一样的，通过企业证件来统一识别。相同的企业证件号归并到同一个企业客户下面。建立企业客户的好处是什么？一是因为有些企业本身只开通了企业服务业务，而不开通商户服务，二是，一个企业可以开通多个商户，企业客户是这些多个商户的统计口径。那么商户与三户之间有什么关系呢？我们看下图
商户本是企业客户的一个业务影子，或是看成资金账户分组的一个手段。商户是客户一个外围业务，如果把它看成用户平级层面也是可以的，即：此商户所有业务产生的资金进入到一个分类资金账户里。不论怎么说，一个企业不论开多少个商户，每个商户又开通多少个资金账户，都改变不了资金账户的归属关系，它是现实客户这个实体的。
所以，不论个人客户，还是企业商户，都脱离不了上面的三户模型。
对客户的处理，在银行系统中是CIF系统或ECIF系统，而在互联网模式下，很多都是基于微服务的体系，如何划分微服务，这块要从客户系统对提供的业务主题来分。
比如：对于个人客户，客户识别就是一个服务主题，对于一个客户有多种多样的识别方式，除了证件外，还包括生物识别，比如画像、指纹等。
基本信息也是一个服务主题：包括客户的最基本的信息，姓名、年令、职业等
管理信息也是一个服务主题：比如这个客户的评级、是否集团员工等。
客户标签也是一个服务主题：所谓标签，就是从不同的维度来给客户做个标记，一个客户有多个标签，当然，前提是要对标签做好规划。
协议管理也是客户的一个服务主题：这里面有授权协议、委托协议等。
当然，客户还有其它的一些主题，这个要看公司的业务了。
这里我列了一些常用到的主题，有些主题可能相同或相近，这是因为这类主题内容比较多，分类可能会更好的管理。
用户层面的微服务划分就比较简单了，主要就是用户协议服务、身份鉴权、信息管理这三大类了。微服务的实现离不开数据库的设计，即数据分布与存储形式，这部分就可以自己灵活处理了，可以分库也可以不分，但由于客户信息是一个读写相对不平衡的系统，以读为主要业务，所以在数据库上设计时要考虑读写分离，或缓存技术。
很多公司都在做一账通，其本质就是是用户层面互相授权的一个场景。关于三户模型，就说这些吧，大家有什么疑问可以提出来，我们共同交流，下次再给大家分享支付清算流程吧，谢谢大家！
Q&A
注意：
Q为问题， S为其他人的回答，A为分享人的回答。
Q: 这里我有个问题，对于用户请求只是注销平台用户，为何需要去注销资金账户呢？我理解是基于客户注册请求，产生的用户信息，然后绑定或者加挂的账户信息，这个时候，账户为何不能作为一个虚拟银行卡下挂在该客户下面呢？类似于我手机银行绑定多个银行卡一样，我注销手机银行，不会去把我的银行卡注销掉。
S: 我的理解为什么要注销资金账户是因为资金账户必须要有归属一个人,注销了，按理说应该把钱和债务关系厘清楚了。
Q：如果是这样理解的，那可能我的理解是偏差，首先我理解的是这个平台是一个独立的用户系统，里面是不会涉及到任何账户管理的内容，所以我理解这里账户是作为一个附加性质的银行卡加挂到客户下面的。如果这个系统就是一个账户系统，那就可能存在债权问题。
A：这个可能我没有说清楚，因为在互联网模式下，有些账户是归归属关系。是客户的，但业务却是用户级的，随着用户的开而开，随着用户的关而关。这里指的是这些账户
Q：明白了，和架构无关，和业务相关。就类似于P2P公司给客户开了个投资账户，客户在P2P公司注销了，连带把这个投资账户一并注销。
Q: 请问下三户模型里面，客户与商户，商户与用户的关系。商户只是客户一个业务影子，用户与商户并没有关系，只是客户授权用户去管理商户下的业务。 如果一个营业执照下面有多个商户，清算需求要到每个商户，这个场景需要怎么处理呢？
商户只是客户一个业务影子，用户与商户并没有关系，只是客户授权用户去管理商户下的业务。 如果一个营业执照下面有多个商户，清算需求要到每个商户，这个场景需要怎么处理呢？?
A：一个客户有多个商户，清算到每个商户，其实不是清算到商户，商户只是一个标识，而是按清算到账户
S：我觉得商户对于统计有意义，对于账务没意义，账务只认账户
S：但有可能会统计一个商户的下属账户的流水
Q：一账通是不是也可以理解为客户的归并啊?
A：一账通算不上客户归并，只能算是账户打通
Q：张老师，请问账户或账号系统设计时，手机号二次放号有无较好的处理机制呢
A：二次放号目前的处理都是个难题，如果原用户已经注销，此手机号可以释放，否则的话，只能做一些人工处理。
Q：手机号二次放号问题，再补充下条件，特别针对银行账户和用户账号设计，普通互联网公司与银行的监管需求不在一个级别
Q: 商户只能是企业用户吗？
Q：多谢分享! 请教两个问题 手机丢失甚至被冒领了怎么办? 归并时碰到哪些问题呢?
S：手机丢失了一般是要对银行卡号进行补全的
Q：不太理解 我是觉得会涉及安全问题 怎么避免和解开 好像进了房子(产生业务数据)把自己锁在里面了(还未来得及认证而失去合法证明)
S：手机号找回密码一般会让你做很多验证 最多的就是输入你的银行卡号
Q：丢失是发生在没实名前但产生了业务之后 可能银行卡还没有身份(客户)也没有 不说这个了
A：关于手机号这块我说一下，这里面事情还是比较多的，对于一个系统来说，即使手机号被新用户使用了，也要保证存量用户的权益，这里面是有协议或合同约束的
Q： 所以这种手机号也好 邮件地址也好 或者随便什么用户名 这些和账户硬关联造成很多不灵活和隐患 实际上就是出问题时这些”用户”是负不起责的
A：是的，是这样的，所以在这方面我们也是尽量去收集用户更多的联系信息，以给用户更多的通知，特别是在银行，有可能通知不到位就是违约问题
Q：总之 数据产生要有源头以避免无主或者被拐 呵呵呵 尤其对钱有关的业务数据 没产生业务前怎么玩都没关系 人-业务之间可以有很多关系 但需要有一条可靠的路径连接两头 有点抽象了
Q：感谢分享，我有两个问题：1,一个企业客户在一个第三方支付平台上可以开多个商户吗？2,您说个人一般是先有用户、资金账户、再有客户。对企业来说，也是这个顺序吗？
Q： 集团企业下有很多个分支机构，集团企业算一个客户，不同的分支机构算不同的用户，这样理解对吗？
A：集团下的分支机构，要看是不是具有独立法人，如果是则可以看成客户。
Q：OK，明白，对于商户的状态变更是否也是通过用户去管理？
A：是的，因为对于商户的管理肯定是通过用户来完成的，不论是管理员还是操作员，都是用户
Q： 目前的监管，你们商户下分几个资金账户？
A：对于商户，我们不设资金账户，都是平台虚拟账户，直接结算到商户在银行的账户里
Q： 账户跟客户、用户是怎样关联的关系。
A： 账户与客户是归属关系，账户与用户是授权关系
Q：这边有两个问题：1、相对2C而言，B2B电商平台上的用户体系复杂些，当用户完成实名认证后，客户信息包括企业和个人信息，登录帐号区分管理员和子帐号，对吗？
A： 其实，只有企业才需要管理员和操作员，因为企业的流程有要求，特别是双岗
S：我们开户的时候必须开两个以上的管理员或者操作员，因为存在双人复核的情况
Q：商户的理解有些偏差，从支付平台的视角来看，目前有 A 电商平台（XX电子商务有限公司）和 B电商平台（ZXY电子商务有限公司）的接入，通我的支付通道完成会员在平台上的交易，对于支付平台来说，A和B就是商户。
Q：有做过实体商户和实体客户关联方面的设计吗？现实中某些个人和某些商家有关系，这个关系有在系统层面支撑的么，
A： 你说的应该是个人客户与企业客户的这种关系吧
Q： 嗯
A： 这个是客户与客户的关系，是没有问题的，
Q：归并的风险主要是确定是否是同意客户把？还有其他风险么
A： 客户归并的最大的风险就是身份冒用，当然，你不经过用户同意，就去归并，这也是一个风险。
Q：你说的虚拟账户其实也是资金账户吧，比如收单的结算账户，用来做代发业务的一般账户。你们分开的么？还是共用一个虚拟账户？
A： 分开的
Q：银行中客户产生后，这个客户开通不同商户号，这个时候按照您之前介绍的，这些商户号其实就是归属于客户，而银行为其创建的用户与商户关系是什么呢？用户是归属商户？
S：这个理解为商户的操作员，有角色区分的
A： 用户也是这个客户下的，不是商户下的，可以理解为开了一个默认的用户，而这个用户已经被客户授权来管理对应的商户
S：管理员、经办、复核 一个商户下有这些角色的用户（操作员），初始一般就一个管理员，可以创建其他的。
Q：恩，那就是商户在这个层面上意味着是另一个独立的业务场景客户，银行为企业客户开立了不同角色用户。这个商户号可以开立多个，也可以对应客户下的多个资金账户。
A：是的
Q：企业客户，面对着用户必须多层级，授权 复核是必须的。但是有碰到过客户说使用某个平台支付，经办在平台下单后就直接支付成功了～有这种不需要后续复核，授权的企业支付嘛？我银行这边都是要授权 复核的流程～只有协议支付这种可以后续不需要复核～
S：通过网管接口操作都会省掉符合的，不然那多麻烦。平台上的操作商户要不要设置复核，商户自己决定的，正规一般都有。
A：其实，正规流程是要有协议的，免审协议，系统自动走后续流程
A：问题是，银行给的b2b接口必须指定了下单是平台页面产生订单号，再去银行客户端操作复核 授权。
A：商户自己定，其实，也是后台有协议的
A：三方如果调用银行接口也应该遵循吧？除非用的是三方自己充值账户，可以像个人一样一键支付？
S：和银行签协议免复核。
A：账户下挂是需要授权，一是同意下挂账户，二是同意该账户在这体系内进行划转，查阅，扣费等操作
A：有可能的，这个客户在开户行将授权，复核都关闭了，经办支付就出去了～
Q：对于集团企业，下面的不同加盟店，这些加盟店都是不同的法人，与集团法人也不一样，这个时候如何建立集团和这些分支机构的关系？?
S: 你这个问题，从银行账户体系而言。集团作为主账户，下面不管独立 非独立的，其他加盟的都是可以下挂的。
Q：从三户模型上怎么看，银行那里我不懂??客户下挂客户？
S: 一样哈，客户是集团和其他企业。账户就是这些企业的银行资金账户.用户就是你给这些企业开立的对账户有操作等权限的角色。我是这么理解的
A：客户是有层次关系的，商户也是，这种关系可能是组织关系也可能是资金关系
S: 在银行，这种账户企业架构就是现金管理中的集团账户资金架构，可以多层级
A：是的，一般资金关系可以和组织关系相同也可以不同，如代理商
S: 可能三方还会需要为其建立虚拟账户，用于及时更新账户余额，毕竟银行资金账户是不同开户行的。不可能像同一银行那样实时收付更新吧？同时允许这些企业客户的用户进行查询，上收下拨
A：组织是组织，资金是资金，分別各自维护各自的层次关系?
S: 银行中是使用银企互联通过前置机方式，将企业系统与银行系统打通，实现企业对各个账户的操作。
Q： 明白了，收获很多，得好好消化下，万分感谢
S: 希望能够多反馈点交流点，我对于三方做这种银行类现金管理挺好奇的～
A：第三方其实和银行体系差不多，只是大部分资金在内部流转
Q：可能三方还会需要为其建立虚拟账户，用于及时更新账户余额，毕竟银行资金账户是不同开户行的。不可能像同一银行那样实时收付更新吧？——-我们现在是实时更新的
A：第三方其实做的是信息流，资金流都在银行
S: 那就是信息流上可以实时更新？也不用开虚拟账户？
S: 那实现资金归集是对公代扣还是主动支付呢？
A：开，更新以信息流为依据
Q：之前那问题，结算账户转一般户 新监管算违规的吧？
A: 应该不违规吧，只是债权晚点偿，只要有协议
Q：不开虚拟户，那的按笔结算啊。
A: 归集走协议代扣
S:怎么说？虚拟账户开是为了日终再结算？我们银行也想做跨行代扣，之前去人行说了，没同意哈。三方怎么真么厉害，可以从不同银行拿到对公代扣～
Q：不开必须每笔单独结算，按交易每笔结算到银行账户
Q: 张老师，你分享的客户、用户、账户三户体系，其实比较符合金融体系业务需求，比如银行或第三方的类金融机构
Q: 普通的互联网公司，一般用户、账户两层就够了
A: 普通互联网是弱化了客户，即此用户所代表的客户
Q: 是的，大家参考借鉴时，建议还要结合实际业务需求
Q: 建议描述场景，II类户的功能对比I类户也是受限的，尤其是额度方面
A: 我的理解就是一个托管账户，账户直接开在了银行
S1：我理解也是这样，听说开发周期比较长，还没搞明白
S2：银行二类账户好像买理财没限额的？查法规看看吧
S1：额度有哪些限制呢
Q: 目前个人账户在I II III类户的分级外，还有一套大账户+小账户模式，比如网贷存管账户
A: 主要是银行侧的，跨机构了都
Q: 请教下银行二类户怎么搞，听说过一个解决个人户大额资金的解决方案，比如超20万的情况下，可以开银行二类户解决。没懂怎么搞[抱拳]
S1:
S1: 银行二类日1万，累计20万可以投资消费。
S2：网贷存管账户可以解决部分大额资金问题，但用途和场景是受限
Q: 这么低额度，应该不是这个
S1: 这个就是银行2/3类账户哈
S2：就是它，但理财和绑定账户出金没有额度限制
S1: 这个理财指的应该是同一银行吧，他行或者银行外的其实就是转账了
S2：另外，面核过的II类户还可以非绑定账户入金，但额度限制与消费一致
S2：@中行 互联网金融?自有理财或代销理财
S1: @S2 是指不管本他行都可以无限额投资理财？
S1: 这个每笔结还是有点没明白，虚拟账户开了，是为了让客户看到资金情况，跟结算有何关系？请赐教
S1: 恩，对的。理财是可以无限额的，但对外投资是不行的，比如我2类账户买京东金融的理财，就得受限了
S1；第三方钱最终还是要结算到银行去的，不弄虚拟账户的话，每笔结算相对简单，假如还是汇总一笔结算，那就用虚拟账户。
Q: 内部户好像可以转账给ii类户？
S2：这个问题太敏感[捂脸]
A: 大家有没有相弄一类账户的？有没有思路？
S2：央妈高抬贵手，或者面签
S2：现在好像真没啥办法
S1: 像POS收单，实时结算的可以不过虚拟户每笔直接结算到商户银行卡
S2：不会的，否则支付机构的备付金账户就成了热点账户，特别是巨头的备付金账户，银行系统支持不了
S1: 入款入账没必要实时啊
A: D0就是这个场景
S2：银行账户出金实时，入金是日终清算，一笔结算
S1: 受教了。这个虚拟账户作用就是银行日终汇总批量结算概念～
S2：D0是垫资，一般走的是其他账户
S2：@中行 互联网金融?有关系，但不完全一致
S1: 将当日所有汇入并成一笔，最后结算
S1: 不一致在？
A: D0垫资是肯定的，原因就是银行是日终才结的
S2：商户其实看到资金已经到了其支付机构账户上，虽然是信息流，但这个账户的资金还是可以在T日在支付机构系统内再次使用的
A: 有没有和银行签T0的？
S1: 有的 很少
S2：只要不出其体系，它就是真钱，要提现才是假的
A: 商户看到的也是未清算的吧，除非实时清分
S1: 有T0一天结算3次的[憨笑]
A: T0手续弗高吧
S2：支付宝现在一般是走即时到账通道，也就是实时清分
S1: 这靠商务去谈的
A: 走实时清分是可以的，但应是清分到待结算资金账户的的，如果此时变成余额，又成了垫资了
S1: 控制商户T1出款
S2：实时清和实时结还是有差距的，各机构处理方式有些差异
S2：支付宝是实时清分到企业账户上，但T日资金提现需要额外支付费用，T+1提现免费
A: 那就是垫资，自有资金
S2：微信此前是统一先到待结算账户，T+1满500自动清算到对公户
S2：现在好像有些变化，有不当的地方大家指正哈
S1: T0手续费 不亏的
A: 都差不多，清分和打款的周期不同而已
S2：其实模式都差不多，T+1结算是标准，毕竟依赖于上游的银行结算周期
A: 这种模式最显著特点是结算到银行卡，依赖于真实资金
S2：是的，资金溯源都在银行
S1: 商户多个选择也好的
S1: 系统资金对账，这块有做的么，上午问没人回啊
A: 啥意思？
A: 你得拿到银行的对账单
A: 再 和你的清算结果去勾兑
S1: 对帐单那是业务对账
S3: 是和清算结果对吗？不和交易流水勾兑？
S1: 资金对备付金资金变动明细
A: 不是，是银行的，你说的是通道的
S3: 清算结果和银行账单对不了
A: 备付金上的钱是通道清算也就是轧差后入的账
S3: 我们清算明细有很多，银行给的明细只有一笔结果
A: 汇总下清算明细就可以了
A: 按银行汇总
S1: 资金变动明细作清分汇总在和业务对完的结果汇总核对是否一致
S3: 这样只能核对总账，明细账核不了
S3: 如果有差异，而且金额是相同的，就很难知道是拿笔清算结果有问题
A: 总账对上就行了，你的清算结果和通道，银行都对上了就是没问题了
A: 明细你已经和通道对过了
S1: 清分很挺麻烦的，各种类型
S3: 目前有没有做分布式清分的？
A: 我说的是通道侧的清分清算
A: 定时清分就可以了
S1: 银行资金变动明细，你们清分出来多少种？
A: 对不上的，记入余额调节表
S1: 只弄一部分，还是所有明细都清分？
A: 清分完，先和通道对账，里面有本金，手续费。
A: 银行资金变动，要看变动原因，理论上全对
S1: 有清分规则这块的设计么？就是这个变化原因不好识别，结算资金、出款资金、调拨资金、线下入款、利息结转等等，
S1: 现在配置每个银行通过一些字段值组合成一条规则，多条规则有优先级。用流水去适配规则，匹配就清分成功，匹配不上的人工识别。
A: 这样啊，如果不只是在线业务，就要走账务总账的账实核对，有个银行日记账
A: 线下业务也要通过凭证传入会计系统
S2: 做这东西说白了就是校验银行给的业务明细和资金变动明细是否一致。
A: 资金变动在会计系统中有
S2: 银行的
S2: 业务明细和资金明细
A: 银行的肯定和你会计系统的实体业务要一致
A: 银行的要和你的对，不是银行自己和自己对
S2: 举个例子吧，银行返回失败，实际出款成功，无业务明细，有资金明细
A: 资金管理平台对账，其实就是账实核对，即你系统的银行日记账和银行记账单核对，你的银行资金明细要和你的会计系统的银行日记账勾兑，对于资金无非就是借贷， 这种情况不就是日记账少账了？通过业务补账就行了。
## 自由讨论
金融IT组织架构
内容来源： 金融企业竞争需要IT队伍前置 很多人都在讨论，阳光集团助理总裁苏文力，在《央行观察》讲述的IT人员前置的实践。自己在银行，目前还是集中式，就像文章说的，只是上线的进度压力，和稳定的运维压力；而和蚂蚁金服、腾讯支付、京东金融的人聊天，他们承受了更大的业务压力。
分散式：多年前很多公司开展IT应用的初期，容许有IT需求的职能部门自己建立IT队伍，快速部署IT应用整体公司IT架构的不统一，企业内各应用相互之间分隔独立。
集中式：各个公司逐渐采取了集中式的IT管理模式，成立了专门的IT部门，负责整个公司的IT服务。好处是集中管理，统一规划。问题是IT人员容易形成封闭的专业集体意识，只关心自己开发进度和生产运行稳定的专业目标，容易忽视所服务企业业务目标的达成。
3、分布式： 安排部分IT开发人员，前置到对IT依赖度高的互联网、客服和电销中心等部门。好处：第一线战斗，听得到炮火，效率高。问题是业务部门的领导因对技术掌握有限，无法在专业技术方面进行指导；IT人员进入到某一业务部门后，其流动受到一定限制，容易对未来的职业发展产生困惑。
单纯集中式和分散式都有问题，就好比集中还是民主一样，应该是一个集中下的民主。 对于战略，架构，规范一定要集中，而对于实现技术可以自由发挥，以实现灵活的业务支撑 总之，精简放权要敏捷，但必须是在章法内，也就是在精益基础上。这和devops是一致的。这种管理模式都是根据理想模型建立的，实际操作中需要根据公司的情况进行调整。毕竟每个公司都有自己的特色。万变不离其宗，现实已经有活生生的例子: 中央只提发展纳要，指导意见，监管政策，地方省市可以灵活机动。 调整也是对的，世界上没有完全一样的树叶，管理上也是一样。
关于提现
据了解中金，连连支付的提现到账时间有限制，比如周五3点后提现，只能下周一到账。但是宝付的可以做到实时。这个是怎么做到的，背后接入的系统不一样吗？
银行和央行系统之前也一样。非工作日的对公账户（即：商户类的提现、结算），大额都周末关闭，没法处理，而且对公通道也少。对私的没有问题，对私周末都开的，小额支付。
支付公司的提现可以通过银行走大小额系统，或者央行的超级网银。 大额系统周末关闭，超网是可以用的。但是支付公司都不能直接对接大小额系统，需要使用银行包装的接口。由银行包装的时候，银行会通过路由的方式去选择出款的通道。比如5w以下，走超网，5w以上走大额，然后判断用户绑定卡的信息是否完整，不完整就弹出页面要求用户补充银行卡开户行信息，这个流程就通了。通道是实时的，但交易什么时间提交通道进行处理是支付公司自己控制的。当然只有通道实时，支付公司才能做到实时。
除了银行外，特许机构可以连接人行二代支付系统（超网）。银联和网联都是经过大额系统来给各银行做清算的。超网7*24通道，现在只有对公这块存在时间问题，这个就看商户了，大多数城商行都是独占本地市场，所以对公结算户都是要求本行账户，目前在他行对公结算户结算、提现的时候，才会出现周末不出款的情况。而行内异地走账一般不会经过人行系统，内部搞定，可以根据时间要求定制。
银联贷记渠道也可以实时到账，而且是7*24的。 但是手续费高。
支付宝一开始的卡通架构， 就是在各家银行都有账户，提现就是一个公对私的代发，日终的时候，支付宝会走自己的资金调拨，其实是从他的账户打到顾客账户 信息流动但是资金并未流动。这种方式，本身就可以绕过大小额。
支付机构如果要做到实时提现，也可以这么搞。 去每家银行，去开一个结算户，这样，不管商户是哪个，对于机构来说，只要做行内转账就好了。银企直连 一般没啥时间限制，直连每一家银行，在每个银行内开结算户，后续所有交易走行内转账。这样就不存在时间、金额的问题，但是对于机构来说，各行的账户存款余额就需要进行调拨调配。跨行的走存管账户，同行的走收付账户就可以了，这两个都属于备付金账户。 连接超级网银通道，好像是有限制的，不是所有的备付金合作银行都能连接超网。
通过备付金调拨来实现实时提现，需要对接大量的银行，留头寸。宝付这个，目前银行列表里面有20家合作银行。支付公司直连大行跟股份制商业银行 基本可以覆盖95%以上的交易了 其他走跨行即可。头寸管理才是核心。
银行的汇缴、收付、存管账户，同行转账不花钱。 支付机构打款，关心的是手续费，这直接决定了他们的打款渠道或方式，很多机构都是批量付款，流程也比较复杂。出款是有风险的，在流程上一般都比较谨慎，这也是慢的原因之一。出款也不可能是实时的，只能是准实时，也就是定时小批量。定时出款就简单了，可以批次去校验一次银行余额，不够钱挂起不出，并发控制容易。
实时提现要么是垫付，要么就是拆借其它客户备付金。
银行账户支付行为
哪位能给普及下，从银行账户性质（对公对私）上发生的支付行为，各个方面的要求、限制、规定、方式等？ 1、公对公收付款 2、公对私收付款 3、私对公收付款 4、私对私收付款 ？公对公收付有柜面传统结算、网银和b2b等，这里指除了票据类的传统结算方式。
观点1：我的理解，这个最终还是要落到通道上，比如公对公代扣，例如支付公司进行的对公代扣，一般是本行代扣，这就看银行提供的通道规则。跨行代扣我的了解也是有的，但是支付机构应该很难拿到，基本用在特定场景，比如保险公司的保费收缴，电力公司的电费收缴，当然更多是用在清算中心或者政策性银行进行的对公代扣。这个基本用的是大小额系统的借记业务。具体银行在这个基础上设计的业务规则（包括要求，限制，规定什么的），是基于银行自己的风控、业务要求等进行的，各银行肯定有差异。即使本行的对公代扣，也是落到银行提供的通道规则上，给小公司的单笔额度，单日额度，跟提供给大公司的额度就有可能不同，限制也不同。
观点2：我感觉和通道关系不大，所谓的收款付款，本质上都是资金的转移或是资金账户金额的借贷，这种变动是由业务驱动的，所以还要跑到业务层面上。 资金是客户的，银行只是保管方，忠实按客户指令去实现收付。 所以，除了政策监管外，更多的是客户授权，如协议合同等，我认为差异应该是授权上的差异了
关于中国银联账户互联互通
这个需求各行都收到，在开始分析了。【重磅必读】中国银联建立银行Ⅱ、Ⅲ类账户互联互通合作机制
“对于加入银联互联互通合作机制的银行客户，只需在任意一个银行拥有一个Ⅰ类户，就可在其他银行手机银行、网络银行等各类渠道随时、随地在开立Ⅱ、Ⅲ类账户” 这句话怎么解读? 如果我在A行开了一类户，在B行手机银行可以直接开立二类户，然后B行通过银联网络去A行鉴权。那这样B行如果有自己的电子账户系统，岂不是浪费了？
通过I类户，线上实名鉴权开立II、III类户，大部分是II类户，鉴权通道估计是银联的。其实二类户鉴权，如果银联有提供最好了。银联在现在这个各行都在建电子账户的时候，来一个电子账户的互联互通，这个切入点抓的真不错。
现在小额那个鉴权接口，只能鉴权一类户，二类户现在功能越来越多了。II类户可以作为支付账户的鉴权方式。 二三类账户有两种 一种是银行的，一种是非银机构的。
[银联内部观点]银联不做账户吧，推出二三类账户主要还是为了银行的需求。银联钱包，更多是为了提供支付场景吧。 如果真是为了账户的话，银联主打的apple pay、小米pay，都是没有银联账户的。这些pay的本质还是银行账户。其实银联也不打算和支付宝、微信对标，如果支付宝微信走的是银联通道的话，也是平台上的好玩家。个人感觉银联并没有想把C端用户抓到手里，更多是希望提供消费场景，让大家来用银行卡 。二三类账户的推出，更多的是希望让银行有能力在账户体系上，和三方对标。
[其他人观点]银联想做账户，否则每年62活动大营销做啥。银联对标的是支付宝、微信、V/M，不是银行，看时总15周年的分享就知道了，但银联的四方体系放在当下，太重了。银联一直坚持做平台，既然是平台，就要保证平台上的所有玩家都有钱赚.银联钱包只是一个栗子，银联想做C端用户，但是路子反了，我觉得买银联买东莞通这步尝试还不错的
在没有二三类账户之前，在银行开设一个账户，是非常麻烦的。
AT（阿里和腾讯）的本质上是三类账户。并不是银联设立了账户分类，是人行要求。银联现在做的是各行的二三类账户和各支付机构三类账户的互联互通。基本上对各个银行和机构都是刚需，不然他们也得想办法走人行或者直连银行（网联）。
工行比银联做的还早。记得当时账户分类管理办法出来不久，工行就在拉其他银行组联盟。不知道工行有没有意思拿银行卡清算牌照？个人觉得就算工行有意应该也很难，央行控制的网联到现在也没清算牌照。网联毕竟是央行直属的，不会和银联抢这个牌照。 不过网联好像能直连央行的系统还能借记各个银行的账户？
其他
关于民生易贷： 民生易贷是民生电商的，民生电商是民生银行的兄弟。
美团收购了一个第三方支付公司，钱袋宝，并和合众成立了一个互联网银行亿联，【亿欧】亿联银行在吉林开业，中发金控、美团点评打造智能网络银行 。美团目前没有计划开发支付业务，以服务内部业务为主， 2B和2C业务都做。 现在支付不好做 很多都是靠集团养。
央行又注销6家支付牌照 通联和杉德违反央行公告已经严重逾期 另一篇报道 央行官网更新：多家支付牌照有变，新增6家注销机构！
结论： 小编们没底线,搞标题党,模棱两可的。富友牌照有好几个，这个是在合并牌照。
感谢您对本文的关注，如需要及时收到来自“支付产品技术交流群”的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。
文中的链接无效，请点击“查看原文”来正常查看。
